간이 네트워크 관리 프로토콜

Simple Network Management Protocol
SNMPv3 STD0062
통신 프로토콜
포트161, 162 (트랩)
RFC3411–3418
시큐어 SNMP
통신 프로토콜
포트10161, 10162(트랩)
RFC6353
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

SNMP(Simple Network Management Protocol)는 IP 네트워크상의 관리 대상 디바이스에 관한 정보를 수집 및 정리하여 디바이스 동작을 변경하기 위한 인터넷 표준 프로토콜입니다.일반적으로 SNMP를 지원하는 디바이스에는 케이블모뎀, 라우터, 스위치, 서버, 워크스테이션, 프린터 [1]등이 있습니다.

SNMP 는, 네트워크 감시용으로 네트워크 관리에 널리 사용됩니다.SNMP 는 관리 대상 시스템의 변수 형식으로 관리 데이터를 공개합니다.MIB(Management Information Base)는 시스템 상태와 구성을 나타냅니다.그런 다음 응용 프로그램을 관리하여 이러한 변수를 원격으로 쿼리할 수 있습니다(경우에 따라서는 조작할 수도 있습니다.

SNMP 의 3 개의 중요한 버전이 개발되어 전개되고 있습니다.SNMPv1은 프로토콜의 원래 버전입니다.최신 버전인 SNMPv2c 및 SNMPv3에서는 성능, 유연성 및 보안이 향상되었습니다.

SNMP는 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)에서 정의한 Internet Protocol Suite의 컴포넌트입니다.애플리케이션 계층 프로토콜, 데이터베이스 스키마 및 데이터 [2]개체 집합을 포함한 네트워크 관리 표준 집합으로 구성됩니다.

개요 및 기본 개념

SNMP 통신의 원리

SNMP 의 일반적인 사용에서는, 매니저라고 불리는 1 대 이상의 관리 컴퓨터에는, 컴퓨터 네트워크상의 호스트 또는 디바이스의 그룹을 감시 또는 관리하는 태스크가 있습니다.각 관리 대상 시스템은 SNMP를 통해 정보를 매니저에게 보고하는 에이전트라는 소프트웨어 컴포넌트를 실행합니다.

SNMP 관리 네트워크는 다음 3가지 주요 컴포넌트로 구성됩니다.

  • 관리 대상 디바이스
  • 에이전트 – 관리 대상 디바이스에서 실행되는 소프트웨어
  • Network Management Station(NMS; 네트워크 관리 스테이션)– 매니저 상에서 실행되는 소프트웨어

관리 대상 디바이스는 노드 고유의 정보에 대한 단방향(읽기 전용) 또는 양방향(읽기와 쓰기) 액세스를 허용하는 SNMP 인터페이스를 구현하는 네트워크 노드입니다.관리 대상 디바이스는 NMS와 노드 고유의 정보를 교환합니다.관리 대상 디바이스는 라우터, 액세스서버, 스위치, 케이블모뎀, 브리지, 허브, IP전화, IP비디오카메라, 컴퓨터 호스트, 프린터를 포함한 모든 종류의 디바이스가 될 수 있습니다.

에이전트는 관리되는 장치에 있는 네트워크 관리 소프트웨어 모듈입니다.에이전트는 관리 정보에 대한 로컬 지식을 가지고 있으며 SNMP 고유의 형식으로 또는 SNMP 고유의 형식으로 변환합니다.

네트워크 관리 스테이션은 관리 대상 디바이스를 감시 및 제어하는 애플리케이션을 실행합니다.NMS는 네트워크 관리에 필요한 처리 및 메모리 자원의 대부분을 제공합니다.1개 이상의 NMS가 임의의 관리 대상 네트워크에 존재할 수 있습니다.

경영정보 베이스

주요 기사: 관리 정보 베이스

SNMP 에이전트는 관리되는 시스템의 관리 데이터를 변수로 표시합니다.또한 이 프로토콜은 이러한 변수를 원격으로 수정하여 구성 변경과 같은 활성 관리 작업을 허용합니다.SNMP를 통해 접근할 수 있는 변수는 계층 구조로 구성됩니다.SNMP 자체는 관리 대상 시스템에서 제공해야 하는 변수를 정의하지 않습니다.SNMP 는, 애플리케이션이 독자적인 계층을 정의할 수 있는 확장 가능한 설계를 사용합니다.이러한 계층은 Management Information Base(MIB; 관리정보 기반)라고 불립니다.MIB는 디바이스 서브시스템의 관리 데이터 구조를 기술합니다.OID를 포함하는 계층형 네임스페이스를 사용합니다.각 OID는 SNMP를 통해 읽거나 설정할 수 있는 변수를 식별합니다.MIB는 Structure of Management Information Version 2.0(SMIv2)에서 정의된 표기법을 사용합니다. RFC2578)의 서브셋입니다.

프로토콜 세부 정보

SNMP는 인터넷 프로토콜 스위트의 응용 프로그램 계층에서 작동합니다.모든 SNMP 메시지는 UDP를 통해 전송됩니다.SNMP 에이전트는 UDP 포트 161에서 요구를 수신합니다.매니저는 사용 가능한 소스 포트에서 에이전트 포트 161로 요청을 전송할 수 있습니다.에이전트 응답은 매니저의 송신원포트로 반송됩니다.매니저는 포트 162에서 알림(Traps 및 InformRequests)을 수신합니다.에이전트는 사용 가능한 모든 포트에서 알림을 생성할 수 있습니다.Transport Layer Security 또는 Datagram Transport Layer Security와 함께 사용하면 포트 10161에서 요구가 수신되고 포트 10162로 [3]알림이 전송됩니다.

SNMPv1은 5개의 핵심 프로토콜 데이터 유닛(PDU)을 지정합니다.GetBulkRequest와 InformRequest의 2개의 PDU가 SNMPv2에 추가되어 Report PDU가 SNMPv3에 추가되었습니다.모든 SNMP PDU 는 다음과 같이 구성됩니다.

IP 헤더 UDP 헤더 버전 지역 사회 PDU 타입 요구 ID 에러 상태 에러 인덱스 변수 바인딩

PDU 타입 필드에서 식별되는7개의 SNMP PDU 타입은 다음과 같습니다.

Get Request(GetRequest)
변수 값 또는 변수 목록을 가져오는 관리자 간 요청입니다.원하는 변수는 변수 바인딩으로 지정됩니다(값 필드는 사용되지 않음).지정된 변수 값의 취득은 에이전트에 의한 원자적인 조작으로 이루어집니다.현재 값이 포함된 응답이 반환됩니다.
SetRequest(설정요구)
변수 또는 변수 목록의 값을 변경하기 위한 관리자 간 요청입니다.변수 바인딩은 요청 본문에 지정됩니다.지정된 모든 변수에 대한 변경은 에이전트에 의한 원자적인 조작으로 이루어집니다.변수에 대한 (현재) 새 값이 포함된 반응이 반환됩니다.
GetNextRequest(다음 요구 취득)
사용 가능한 변수와 그 값을 검출하기 위한 매니저 대 에이전트 요청.MIB의 사전 편집상 다음 변수에 대한 변수 바인딩이 포함된 응답을 반환합니다.에이전트의 MIB 전체를 OID 0부터 시작하는 GetNextRequest를 반복 적용하면 워크할 수 있습니다.요구의 변수 바인딩에 열 OID를 지정하여 테이블의 행을 읽을 수 있습니다.
GetBulkRequest(GetBulkRequest)
GetNextRequest를 여러 번 반복하기 위한 관리자 간 요청입니다.GetNextRequest의 최적화된 버전.요청 변수 바인딩 또는 바인딩에서 걸어온 여러 변수 바인딩이 포함된 응답을 반환합니다.PDU 고유의 비반복 필드 및 max-repetitions 필드는 응답 동작을 제어하기 위해 사용됩니다.GetBulkRequest가 SNMPv2에서 도입되었습니다.
대답
GetRequest, SetRequest, GetNextRequest, GetBulkRequest 및 InformRequest에 대한 변수 바인딩 및 확인을 에이전트에서 매니저로 반환합니다.오류 보고서는 error-status 필드와 error-index 필드로 제공됩니다.get과 set 모두에 대한 응답으로 사용되었지만 SNMPv1에서는 이 PDU를 GetResponse라고 불렀습니다.
트랩
에이전트에서 매니저로의 비동기 통지.다른 SNMP 통신에서는 매니저가 에이전트에 정보를 적극적으로 요구합니다.이러한 PDU는 명시적으로 요구되지 않고 에이전트에서 매니저로 전송됩니다.SNMP 트랩을 사용하면 에이전트는 비송신 요청 SNMP 메시지를 통해 중요한 이벤트를 관리 스테이션에 알릴 수 있습니다.트랩 PDU에는 현재 sysUpTime 값, 트랩 유형을 식별하는 OID 및 옵션 변수바인딩이 포함됩니다.트랩의 행선지 어드레싱은, 통상은 MIB 의 트랩 설정 변수에 의해서 애플리케이션 고유의 방법으로 결정됩니다.SNMPv2에서 트랩메시지 형식이 변경되어 PDU의 이름이 SNMPv2-Trap으로 변경되었습니다.
InformRequest(정보요구)
확인 응답된 비동기 통지.이 PDU는 SNMPv2에서 도입되어 매니저 대 매니저 [4]통신으로 정의되었습니다.이후 구현에서는 원래 정의가 느슨해져 에이전트와 매니저 간의 [5][6][7]통신이 가능해졌습니다.SNMPv1에서는 트랩을 사용하여 매니저 간 통지가 이미 가능했지만 SNMP는 일반적으로 전달이 보증되지 않고 폐기된 패킷이 보고되지 않는 UDP를 통해 실행되므로 트랩 전달이 보증되지 않았습니다.InformRequest는 수신 [6]시 확인 응답이 반환되므로 이 문제를 해결합니다.

RFC 1157 에서는, SNMP 실장에서는 길이가 484 바이트 이상인 메시지를 받아들일 필요가 있다고 규정되어 있습니다.실제로는 SNMP 실장에서는 보다 긴 [8]: 1870 메시지를 받아들입니다.올바르게 실장되어 있는 경우, 메시지의 디코딩이 실패하면 SNMP 메시지는 폐기되어 부정한 형식의 SNMP 요구가 무시됩니다.정상적으로 디코딩된 SNMP 요구는 커뮤니티 스트링을 사용하여 인증됩니다.인증에 실패하면 인증 실패를 나타내는 트랩이 생성되고 메시지가 [8]: 1871 폐기됩니다.

SNMPv1과 SNMPv2는 커뮤니티를 사용하여 매니저와 에이전트 간의 신뢰를 확립합니다.대부분의 에이전트는 3개의 커뮤니티 이름(읽기 전용, 읽기/쓰기 및 트랩용)을 지원합니다.이들 3개의 커뮤니티 스트링은 다른 유형의 액티비티를 제어합니다.읽기 전용 커뮤니티는 get 요구에 적용됩니다.읽기/쓰기 커뮤니티 스트링은 설정 요구에 적용됩니다.트랩 커뮤니티 스트링은 트랩 수신에 적용됩니다.SNMPv3는 커뮤니티 스트링도 사용하지만 SNMP 매니저와 에이전트 [9]간의 안전한 인증과 통신을 가능하게 합니다.

프로토콜 버전

실제로 SNMP 실장에서는, 복수의 버전(통상은 SNMPv1, SNMPv2c, [10][11]및 SNMPv3)이 서포트되고 있습니다.

버전 1

SNMP 버전 1(SNMPv1)은 SNMP 프로토콜의 초기 구현입니다.SNMPv1의 설계는 1980년대에 공식적으로 후원된 OSI/IETF/NSF(National Science Foundation)의 노력(HEMS/CMIS/CMIP)을 당대의 컴퓨팅 플랫폼에서는 구현할 수 없을 뿐만 아니라 실행할 수도 없는 것으로 간주한 공동 연구자들에 의해 이루어졌습니다.SNMP는 인터넷의 대규모 전개와 그 상용화에 필요한 잠정적인 프로토콜이라는 믿음에 근거해 승인되었다.

SNMP에 대한 최초의 코멘트 요구(RFC)는 1988년에 등장했습니다.

  • RFC 1065 - TCP/IP 기반 인터넷 관리 정보 구조 및 식별
  • RFC 1066 - TCP/IP 기반 인터넷의 네트워크 관리를 위한 관리 정보 베이스
  • RFC 1067 - 심플한 네트워크 관리

1990년에 이러한 문서는 다음과 같이 대체되었습니다.

  • RFC 1155 - TCP/IP 기반 인터넷 관리 정보 구조 및 식별
  • RFC 1156 - TCP/IP 기반 인터넷의 네트워크 관리를 위한 관리 정보 기반
  • RFC 1157 - 심플한 네트워크 관리 프로토콜

1991년에 RFC 1156(MIB-1)은 보다 자주 사용되는 것으로 대체되었습니다.

  • RFC 1213 - TCP/IP 기반 인터넷의 네트워크 관리를 위한 관리 정보 베이스(MIB-2) 버전2

SNMPv1은 인터넷 [12]커뮤니티에서 널리 사용되며 사실상의 네트워크 관리 프로토콜입니다.

SNMPv1은 UDP(User Datagram Protocol), Internet Protocol(IP), OSI Connectionless-Mode Network Service(CLNS), AppleTalk Datagram Delivery Protocol(DDP), Novell Internetwork Packet Exchange(IPX) 등의 트랜스포트층 프로토콜을 통해 전송할 수 있습니다.

버전 1은 보안이 [13]취약하다는 비판을 받고 있습니다.이 사양에서는, 커스텀 인증을 사용할 수 있는 여지가 있습니다만, 널리 사용되고 있는 실장에서는, 「모든 SNMP 메시지를 진짜 SNMP [14]메시지로 식별하는 간단한 인증 서비스만을 서포트하고 있습니다」.따라서 메시지의 보안은 메시지가 전송되는 채널의 보안에 따라 달라집니다.예를 들어, SNMP 메시지에 암호화가 필요 없을 정도로 내부 네트워크가 충분히 안전하다고 생각할 수 있습니다.이 경우, 명문으로 송신되는 「커뮤니티명」은, 원래의 사양에도 불구하고, 사실상의 패스워드로 간주되는 경향이 있습니다.

버전 2

SNMPv2는 RFC 1441 및 RFC 1452에 의해 정의되어 있으며 버전1을 개정하여 퍼포먼스, 보안 및 매니저 간 통신 영역에서 개선을 포함하고 있습니다.단일 요청으로 대량의 관리 데이터를 검색할 수 있는 반복적인 GetNextRequests의 대안인 GetBulkRequest를 도입했습니다.SNMPv2에서 도입된 새로운 정당 기반 보안 시스템은 많은 사람들에게 지나치게 복잡하다고 여겨졌지만 널리 [13]채택되지 않았습니다.이 버전의 SNMP는 Proposed Standard(표준 제안) 수준에 도달했지만 이후 [15]버전에서는 사용되지 않는 것으로 간주되었습니다.

Community-Based Simple Network Management Protocol 버전2(SNMPv2c)는 RFC 1901-RFC 1908에 정의되어 있습니다.SNMPv2c는 SNMPv1의 단순한 커뮤니티 기반 보안 방식을 사용하여 논란의 여지가 있는 새로운 SNMP v2 보안 모델을 사용하지 않고 SNMPv2로 구성됩니다.이 버전은 IETF의 표준 초안 성숙도 수준을 충족하는 비교적 적은 표준 중 하나이며 사실상의 SNMPv2 [15]표준으로 널리 간주되었습니다.나중에 SNMPv3의 [16]일부로 다시 기술되었습니다.

사용자 기반 Simple Network Management Protocol 버전 2, 즉 SNMPv2u는 RFC 1909에 정의되어 있습니다.RFC 1910.이것은, SNMPv1보다 시큐러티를 강화하려고 하는 타협입니다만, SNMPv2의 높은 복잡성은 발생하지 않습니다.이 메커니즘은 SNMP v2*로 상용화되어 최종적으로 SNMP v3의 [17]2개의 보안 프레임워크 중 하나로 채택되었습니다.

64비트 카운터

SNMP 버전2 에서는, 64비트 데이터 카운터의 옵션이 도입되고 있습니다.버전 1은 0 ~42억9000만(정확히는 4,294,967,295)의 정수값을 저장할 수 있는32비트카운터만으로 설계되어 있습니다.32비트 버전1 카운터는 10기가비트 이상의 인터페이스의 최대 속도(비트/초)를 저장할 수 없습니다.마찬가지로 10기가비트 이상의 인터페이스에 대한 32비트카운터 트래킹 통계 정보는 1분 이내에 다시 제로로 롤오버할 수 있습니다.이는 현재 상태를 읽기 위해 폴링되는 카운터보다 짧은 시간 간격일 수 있습니다.이로 인해 검출되지 않은 값의 롤오버 및 트렌드 추적 데이터의 파손으로 인해 데이터가 손실되거나 비활성화됩니다.

64비트 버전2 카운터는 0 ~18.4조(정확히는 18,446,744,073,709,551,615)의 값을 저장할 수 있기 때문에 현재 폴링 이벤트 간에 카운터 롤오버는 발생하지 않습니다.예를 들어 1.6테라비트이더넷은 2025년까지 사용할 수 있게 될 것으로 예상됩니다.64비트 카운터가 1조6천억 비트/초의 속도로 증가하면 이러한 인터페이스의 정보를 133일 동안 롤오버하지 않고 유지할 수 있습니다.

SNMPv1과 SNMPv2c의 상호 운용성

SNMPv2c는 메시지 형식과 프로토콜 작업이라는 두 가지 주요 영역에서 SNMPv1과 호환되지 않습니다.SNMPv2c 메시지는 SNMPv1 메시지와는 다른 헤더 및 Protocol Data Unit(PDU) 형식을 사용합니다.또한 SNMPv2c는 SNMPv1에 지정되지 않은 두 가지 프로토콜 작업을 사용합니다.비호환성을 극복하기 위해 RFC 3584에서는 2개의 SNMPv1/v2c 공존전략(프록시 에이전트와 이중언어 네트워크 관리 시스템)을 정의하고 있습니다.

프록시 에이전트

SNMPv2 에이전트는 SNMPv1 관리 대상 디바이스를 대신하여 프록시 에이전트로서 동작할 수 있습니다.SNMPv2 NMS는 SNMPv1 에이전트를 대상으로 한 명령어를 발행하면 대신 SNMPv2 프록시 에이전트로 전송합니다.프록시 에이전트가 전송됨Get,GetNext,그리고.SetSNMPv1 에이전트에 메시지를 변경하지 않습니다.GetBulk 메시지는 프록시 에이전트에 의해 변환됩니다.GetNextSNMPv1 에이전트로 전송됩니다.또한 프록시 에이전트는 SNMPv1 트랩메시지를 수신하여 SNMPv2 트랩메시지에 매핑한 후 NMS로 전송합니다.

이중언어 네트워크 관리 시스템

이중 언어 SNMPv2 네트워크 관리 시스템은 SNMPv1과 SNMPv2를 모두 지원합니다.이 이중 관리 환경을 지원하기 위해 관리 응용 프로그램은 로컬 데이터베이스에 저장된 정보를 검사하여 에이전트가 SNMPv1 또는 SNMPv2를 지원하는지 확인합니다.NMS는 데이터베이스의 정보를 기반으로 적절한 버전의 SNMP를 사용하여 에이전트와 통신합니다.

버전 3

SNMPv3는 암호화 보안을 추가하는 것 외에는 프로토콜을 변경하지 않지만 새로운 텍스트 표기법, 개념 및 [1]용어로 인해 매우 다르게 보입니다.가장 눈에 띄는 변경은 SNMP에 [18]보안과 리모트 설정의 확장을 추가하여 SNMP의 안전한 버전을 정의하는 것입니다.보안 측면에서는 프라이버시를 위한 강력한 인증과 데이터 암호화를 모두 제공함으로써 대처합니다.관리 측면에서는 SNMPv3는 통지 발신자와 프록시 포워더의 2가지 부분에 초점을 맞춥니다.또, 변경에 의해서 SNMP 엔티티의 리모트 설정 및 관리가 용이하게 되어, 대규모 전개, 어카운팅, 장해 관리와 관련된 문제에 대처할 수 있게 됩니다.

기능 및 확장 기능:

  • 기존의 SNMP 엔티티 간의 통신만을 용이하게 하기 위한 SNMP 엔티티 식별: 각 SNMP 엔티티에는 SNMPEngine이라는 식별자가 있습니다.ID 및 SNMP 통신은 SNMP 엔티티가 피어 ID를 알고 있는 경우에만 가능합니다.트랩과 통지는 이 규칙의 예외입니다.
  • 보안 모델 지원– 보안 모델은 관리 도메인 또는 인트라넷 내에서 보안 정책을 정의할 수 있습니다.SNMPv3에는 User-Based Security Model(USM; 사용자 기반 보안 모델)의 사양이 포함되어 있습니다.
  • 메시지 인증 서비스의 목표가 다음과 같은 것에 대한 보호를 포함하는 보안 목표의 정의.
    • 정보 변경 – 인증된 주체에서 생성된 전송 중 메시지를 변경하는 일부 부정한 SNMP 엔티티에 대한 보호.
    • 위장 – 적절한 권한을 가진 다른 주체의 신원을 가정하여 일부 주체에 대해 허가되지 않은 관리 작업을 시도하는 것을 방지합니다.
    • 메시지 스트림 변경– 메시지가 악의적으로 재배열, 지연 또는 재생되어 부정한 관리 조작에 영향을 주는 것을 방지합니다.
    • 공개 – SNMP 엔진 간의 교환을 도청하는 것을 방지합니다.
  • USM – USM 사양은 사용 가능한 다음 통신 메커니즘의 일반적인 정의로 구성됩니다.
    • 인증 및 프라이버시를 사용하지 않는 통신(NoAuthNoPriv).
    • 인증과 사생활이 없는 통신(AuthNoPriv).
    • 인증 및 프라이버시(AuthPriv)와의 통신.
  • MD5, SHA 및 HMAC-SHA-2[19] 인증 프로토콜과 CBC_ 등 다양한 인증 및 프라이버시 프로토콜의 정의DES 및 CFB_AES_128 프라이버시 프로토콜은 USM에서 지원됩니다.
  • 디스커버리 절차의 정의– SNMPEngine을 찾습니다.특정 트랜스포트 주소 및 트랜스포트 엔드 포인트주소의 SNMP 엔티티 ID
  • 시각 동기 순서의 정의: SNMP 엔티티간의 인증된 통신을 용이하게 합니다.
  • SNMP 프레임워크 MIB 정의– SNMP 엔티티의 리모트 설정 및 관리를 용이하게 합니다.
  • USM MIB 정의– 보안 모듈의 리모트 설정 및 관리를 용이하게 합니다.
  • View-Based Access Control Model(VACM; 뷰 기반 접근컨트롤 모델) MIB 정의– 접근컨트롤 모듈의 리모트 설정 및 관리를 용이하게 합니다.

보안은 v3까지 SNMP의 가장 큰 약점 중 하나였습니다.SNMP 버전1 및 2에서의 인증은 매니저와 에이전트 [1]간에 클리어 텍스트로 송신되는 패스워드(커뮤니티 스트링)에 지나지 않습니다.각 SNMPv3 메시지에는 옥텟 문자열로 인코딩된 보안 파라미터가 포함되어 있습니다.이러한 보안 파라미터의 의미는 사용되는 [20]보안모델에 따라 달라집니다.v3 [21]타깃 보안 접근법:

  • 기밀성: 부정한 송신원에 의한 스누핑을 방지하기 위한 패킷 암호화.
  • 무결성: 전송 중에 패킷이 변조되지 않았는지 확인하기 위한 메시지 무결성.옵션의 패킷 리플레이 보호 메커니즘을 포함합니다.
  • [Authentication] : 메시지가 유효한 송신원으로부터 송신된 것을 확인합니다.

v3에서는 USM과 VACM도 정의되어 있습니다.이후 SSH를 통한 SNMPv3 및 TLS와 DTLS를 통한SNMPv3를 지원하는 Transport Security Model(TSM; 트랜스포트보안 모델)이 도입되었습니다.

  • USM(User-based Security Model)은 인증 및 프라이버시(암호화) 기능을 제공하며 메시지레벨로 동작합니다
  • VACM(View-based Access Control Model)은 특정 기능을 수행하기 위해 특정 주체가 특정 MIB 개체에 액세스할 수 있는지 여부를 판단하고 PDU 수준에서 작동합니다.
  • TSM(Transport Security Model)은 외부 보안 채널을 통해 메시지를 인증하고 암호화하는 방법을 제공합니다.TSM 사양을 사용하는 SSH 및 TLS/DTLS의 2개의 전송이 정의되어 있습니다.

2004년 현재 IETF는 RFC 3411-RFC 3418[22](STD0062)에서 정의된 Simple Network Management Protocol 버전3을 SNMP의 현재 표준 버전으로서 인식하고 있습니다.IETF는 SNMPv3를 RFC의 최고 성숙도 수준인 완전한 인터넷 [23]표준으로 지정하고 있습니다.이전 버전(다양한 "Historic" 또는 "Obsolete"[15] 지정)은 구식이라고 간주합니다.

구현 문제

네트워크 디바이스의 설정을 가능하게 하는 SNMP의 강력한 기입 기능은, 많은 벤더에 의해서 완전하게 이용되고 있지 않습니다.부분적으로는 SNMPv3 이전의 SNMP 버전에서는 보안이 결여되어 있기 때문입니다.또한 많은 디바이스는 단순히 개개의 MIB 오브젝트 변경을 통해 설정할 수 없기 때문입니다.

일부 SNMP 값(특히 표 형식 값)에는 테이블인덱스 방식에 대한 특정 지식이 필요합니다.이러한 인덱스 값은 플랫폼 간에 반드시 일관성이 있는 것은 아닙니다.이로 인해 동일한 테이블인덱스 방식을 사용하지 않을 수 있는 여러 디바이스에서 정보를 가져올 때(예를 들어 특정 디스크 ID가 플랫폼 간에 다른 디스크 사용률 메트릭을 가져올 때) 상관관계가 발생할 수 있습니다.[24]

일부 주요 기기 벤더는 자체 Command Line Interface(CLI; 명령줄 인터페이스) 중심의 구성과 제어 [25][failed verification]시스템을 과도하게 확장하는 경향이 있습니다.

2002년 2월, Oulu University Secure Programming Group이 SNMP 메시지 처리를 철저히 분석한 후, CERT-CC는 [26]SNMPv1에 관한 어드바이스를 발행했습니다.대부분의 SNMP 구현에서는 지원하는 프로토콜의 버전에 관계없이 동일한 프로그램 코드를 사용하여 PDU(Protocol Data Unit)를 디코딩하고 있으며 이 코드에서 문제가 발견되었습니다.SNMP 관리 스테이션이 수신한SNMP 트랩메시지 또는 네트워크 디바이스상의 SNMP 에이전트가 수신한 요구를 디코딩 하는 경우는, 그 외의 문제가 발견되었습니다.많은 벤더가 SNMP [8]: 1875 구현을 위한 패치를 발행해야 했습니다.

보안상의 영향

SNMP를 사용한 네트워크 공격

SNMP 는, 관리자가 네트워크 디바이스를 리모트로 감시 및 설정할 수 있도록 설계되어 있기 때문에, 네트워크에의 침입에도 사용할 수 있습니다.SNMP 를 사용해 네트워크 전체를 스캔 할 수 있는 소프트웨어 툴이 다수 있기 때문에, 읽기/쓰기 모드 설정으로 잘못하면,[27]: 52 네트워크가 공격에 취약하게 되는 일이 있습니다.

2001년에 시스코에서는 읽기 전용 모드에서도 Cisco IOS의 SNMP 실장은 특정 DoS 공격에 취약하다는 것을 나타내는 정보를 발표했습니다.이러한 보안 문제는 IOS 업그레이드를 [28]통해 해결할 수 있습니다.

SNMP 가 네트워크에서 사용되고 있지 않은 경우는, 네트워크 디바이스에서는 무효로 할 필요가 있습니다.SNMP 읽기 전용 모드를 설정하는 경우는, 액세스컨트롤의 설정과 SNMP 메시지의 수신원IP 주소에 주의해 주세요.SNMP 서버가 IP 에 의해서 식별되는 경우, SNMP 는 이러한 IP 에의 응답만이 허가되어 다른 IP 주소로부터의 SNMP 메시지는 거부됩니다.단, IP 주소 스푸핑은 보안상의 문제로 남아 [27]: 54 있습니다.

인증

SNMP 는, 다른 버전으로 사용할 수 있습니다.각각의 시큐러티에는 고유의 문제가 있습니다.SNMP v1 은, 네트워크를 개입시켜 클리어 텍스트로 패스워드를 송신합니다.따라서 패킷 스니핑으로 패스워드를 읽을 수 있습니다.SNMP v2 에서는 MD5와의 패스워드 해시가 가능하지만, 이것은 설정할 필요가 있습니다.거의 모든 네트워크 관리 소프트웨어가 SNMP v1을 지원하지만 반드시 SNMP v2 또는 v3를 지원하지는 않습니다.SNMP v2는 데이터 보안(인증, 프라이버시 및 인가)을 제공하기 위해 특별히 개발되었지만, SNMP 버전 2c만이 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)의 승인을 받은 반면 버전 2u 및 2*는 보안 문제로 인해 IETF 승인을 받지 못했습니다.SNMP v3는 MD5, Secure Hash Algorithm(SHA) 및 키 달린 알고리즘을 사용하여 부정 데이터 변경 및 스푸핑 공격으로부터 보호합니다.고도의 보안이 필요한 경우 Data Encryption Standard(DES; 데이터 암호화 규격)를 암호 블록 체인 모드로 선택적으로 사용할 수 있습니다.SNMP v3 는, 릴리스 12.0(3)[27]: 52 T 이후에 Cisco IOS 에 실장되고 있습니다.

SNMPv3 는, 인증 키 또는 암호 키를 추측하기 위한 무차별 공격이나 사전 공격의 대상이 되는 경우가 있습니다.이러한 키는 사전에 기재되어 있는 쇼트(취약) 패스워드 또는 패스워드에서 생성됩니다.SNMPv3 에서는, 임의의 균등하게 분산된 암호 키를 제공하는 것과 동시에, 유저가 지정한 패스워드로 암호 키를 생성할 수 있습니다.네트워크를 통해 전송된 해시 값에서 인증 문자열을 추측하는 위험은 사용되는 암호화 해시 함수와 해시 값의 길이에 따라 달라집니다.SNMPv3는 USM([29]사용자 기반 보안 모델)에 HMAC-SHA-2 인증 프로토콜을 사용합니다. SNMP는 보다 안전한 챌린지 핸드쉐이크 인증 프로토콜을 사용하지 않습니다.SNMPv3(다른 SNMP 프로토콜 버전과 마찬가지로)는 상태 비저장 프로토콜이며 에이전트와 관리자 간의 상호 작용이 최소화되도록 설계되었습니다.따라서 각 명령어에 대해 챌린지-리스폰스 핸드쉐이크를 도입하는 것은 에이전트(및 네트워크 자체)에게 부담을 줄 수 있으며 프로토콜 설계자는 이를 [citation needed]과도하고 허용할 수 없다고 간주합니다.

모든 SNMP 버전의 보안 결함은 IPsec 인증 [citation needed]및 기밀성 메커니즘에 의해 완화될 수 있습니다.SNMP 는, Datagram Transport Layer Security(DTLS;[10] 데이터그램 트랜스포트층 시큐러티)를 개입시켜 안전하게 전송할 수도 있습니다.

많은 SNMP 실장에는 스위치나 라우터 등의 새로운 네트워크컴포넌트가 자동적으로 검출되어 폴링 되는 자동 검출 타입이 포함되어 있습니다.SNMPv1 및 SNMPv2c 에서는, 이것은 다른 디바이스에 [10]클리어 텍스트로 송신되는 커뮤니티 스트링에 의해서 행해집니다.클리어 텍스트비밀번호는 보안상 중대한 리스크입니다.커뮤니티 스트링이 조직 외부에 인식되면 공격의 타깃이 될 수 있습니다.커뮤니티 스트링을 수집하려는 다른 시도를 관리자에게 경고하기 위해 커뮤니티 이름 인증 실패 [27]: 54 트랩을 통과하도록 SNMP를 설정할 수 있습니다.SNMPv2 를 사용하는 경우는, 네트워크 디바이스의 SNMP 에이전트에서 패스워드 암호화를 유효하게 하는 것으로, 이 문제를 회피할 수 있습니다.

커뮤니티 스트링의 일반적인 디폴트 설정은 읽기 전용 액세스의 경우는 「public」, 읽기와 [8]: 1874 쓰기의 경우는 「private」입니다.잘 알려진 디폴트 때문에 SNMP는 SANS Institute의 일반적인 디폴트 설정 문제 목록에서 1위를 차지했으며,[30] 2000년 SANS의 가장 중요한 인터넷 보안 위협 상위 10위 안에 10위를 차지했습니다.시스템 및 네트워크 관리자는 이러한 [8]: 1874 설정을 자주 변경하지 않습니다.

SNMPv1과 v2는 TCP를 통해 실행되든 UDP를 통해 실행되든 IP 스푸핑 공격에 취약합니다.스푸핑을 사용하면 공격자는 SNMP 액세스를 제한하기 위해 구현된 에이전트에서 디바이스 액세스목록을 바이패스할 수 있습니다.USM이나 TSM등의 SNMPv3 시큐러티 메카니즘에 의해서, 스푸핑의 공격이 정상적으로 행해지지 않게 됩니다.

RFC 레퍼런스

  • RFC 1155 (STD 16) - TCP/IP 기반 인터넷 관리 정보의 구조 및 식별
  • RFC 1156(이력) - TCP/IP 기반 인터페이스 네트워크 관리를 위한 관리 정보 기반
  • RFC 1157(이력) - Simple Network Management Protocol(SNMP)
  • RFC 1213 (STD 17) - TCP/IP 기반 인터페이스 네트워크 관리를 위한 관리 정보 기반: MIB-II
  • RFC 1452(정보) - 인터넷 표준 네트워크 관리 프레임워크 버전1과 버전2의 공존(RFC 1908에 의해 폐지)
  • RFC 1901 (Experimental) : 커뮤니티 기반 SNMPv2의 개요
  • RFC 1902(표준 초안) - SNMPv2 관리정보 구조(RFC 2578에 의해 폐지)
  • RFC 1908(Standards Track) - 인터넷 표준 네트워크 관리 프레임워크 버전1과 버전2의 공존
  • RFC 2570 (정보) - 인터넷 표준 네트워크 관리 프레임워크 버전3의 개요 (RFC 3410에 의해 폐지)
  • RFC 2578 (STD 58) - 관리 정보 버전 2 (SMIv2)의 구조
  • RFC 3410 (정보) - 인터넷 표준 관리 프레임워크의 개요 및 적용 가능성 설명
  • STD 62에는 다음 RFC가 포함되어 있습니다.
    • RFC 3411 - SNMP(Simple Network Management Protocol) 관리 프레임워크를 기술하는 아키텍처
    • RFC 3412 - SNMP(Simple Network Management Protocol) 메시지 처리 및 디스패치
    • RFC 3413 - Simple Network Management Protocol(SNMP) 애플리케이션
    • RFC 3414 - Simple Network Management Protocol(SNMPv3) 버전3의 사용자 기반 보안 모델(USM)
    • RFC 3415 - Simple Network Management Protocol(SNMP)용 View-Based Access Control Model(VACM)
    • RFC 3416 - Simple Network Management Protocol(SNMP)용 Protocol Operations 버전2
    • RFC 3417 - Simple Network Management Protocol(SNMP)의 트랜스포트 매핑
    • RFC 3418 - Simple Network Management Protocol(SNMP)용 관리정보 베이스(MIB)
  • RFC 3430 (실험적) - SNMP over Transmission Control Protocol (TCP) 트랜스포트 맵핑
  • RFC 3584(BCP 74) - 인터넷 표준 네트워크 관리 프레임워크 버전1, 버전2, 버전3의 공존
  • RFC 3826(제안) - SNMP 사용자 기반 보안 모델의 Advanced Encryption Standard(AES; 고도 암호화 표준) 암호 알고리즘
  • RFC 4789 (제안) - IEEE 802 네트워크를 통한 Simple Network Management Protocol (SNMP)
  • RFC 5343(STD 78): Simple Network Management Protocol(SNMP) 컨텍스트엔진ID 검출
  • RFC 5590 (STD 78) - SNMP(Simple Network Management Protocol)용 트랜스포트 서브시스템
  • RFC 5591 (STD 78) - SNMP(Simple Network Management Protocol) 트랜스포트 보안 모델
  • RFC 5592 (제안) - Simple Network Management Protocol (SNMP)용 시큐어 셸 트랜스포트 모델
  • RFC 5608 (제안) : Simple Network Management Protocol(SNMP) 트랜스포트 모델에서의 Remote Authentication Dial-In User Service(RADIUS) 사용.
  • RFC 6353 (STD 78) - SNMP(Simple Network Management Protocol)를 위한 트랜스포트 레이어 보안(TLS) 트랜스포트 모델
  • RFC 7630 (제안) - SNMPv3용 사용자 기반 보안 모델(USM)의 HMAC-SHA-2 인증 프로토콜

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c Douglas R. Mauro & Kevin J. Schmidt. (2001). Essential SNMP (1st ed.). Sebastopol, CA: O'Reilly & Associates.
  2. ^ An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. doi:10.17487/RFC3411. RFC 3411.
  3. ^ RFC 6353 섹션 10
  4. ^ J. Case; K. McCloghrie; M. Rose; S. Waldbusser (April 1993). "RFC 1448 – Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)". Internet Engineering Task Force. doi:10.17487/RFC1448. An InformRequest-PDU is generated and transmitted at the request an application in a SNMPv2 entity acting in a manager role, that wishes to notify another application (in a SNMPv2 entity also acting in a manager role) of information in the MIB View of a party local to the sending application. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  5. ^ D. Levi; P. Meyer; B. Stewart (April 1999). "RFC 2573 – SNMP Applications". Internet Engineering Task Force. doi:10.17487/RFC2573. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  6. ^ a b "SNMP Inform Requests". Cisco. Retrieved 2011-12-09. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  7. ^ "Understanding the SNMP Implementation in JUNOS Software". Juniper Networks. Retrieved 2013-02-11. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  8. ^ a b c d e Harold F. Tipton & Micki Krause (2007). Information Security Management Handbook, Sixth Edition. CRC Press. ISBN 9780849374951.{{cite book}}: CS1 maint: 작성자 파라미터 사용(링크)
  9. ^ Douglas Mauro & Kevin Schmidt (2005). Information Security Management Handbook, Sixth EditioEssential SNMP: Help for System and Network Administrators. O'Reilly Media, Inc. pp. 21–22. ISBN 9780596552770.{{cite book}}: CS1 maint: 작성자 파라미터 사용(링크)
  10. ^ a b c Stuart Jacobs (2015). Engineering Information Security: The Application of Systems Engineering Concepts to Achieve Information Assurance. John Wiley & Sons. p. 367. ISBN 9781119104797.
  11. ^ RFC 3584 "인터넷 표준 네트워크 관리 프레임워크 버전 1, 버전 2, 버전 3의 공존"
  12. ^ Wiley, John (2015-12-01). Engineering Information Security: The Application of Systems Engineering Concepts to Achieve Information Assurance. p. 366. ISBN 9781119104711. Retrieved 2017-09-14.
  13. ^ a b "Security in SNMPv3 versus SNMPv1 or v2c" (PDF). Archived from the original (PDF) on 2013-04-29.
  14. ^ RFC 1157
  15. ^ a b c "RFC Search Detail: Standards Track snmpv2 RFCs". The RFC Editor. Retrieved 2014-02-24.
  16. ^ RFC 3416
  17. ^ SNMPv3 -- User Security Model, Dr. Dobbs, retrieved 2019-03-09
  18. ^ 이번 호: SNMP 버전3 심플 타임즈 ISSN 1060-6084
  19. ^ RFC 7860
  20. ^ David Zeltserman (1999). A Practical Guide to SNMPv3 and Network Management. Upper Saddle River, NJ: Prentice Hall PTR.
  21. ^ "SNMPv3". Cisco Systems. Archived from the original on 2011-07-19.
  22. ^ "SNMP Version 3". Institute of Operating Systems and Computer Networks. Retrieved 2010-05-07.
  23. ^ 현재 인터넷 표준(STD)의 Wayback Machine List of the Current Internet Standards(Wayback Machine)에서 아카이브된 RFC Editor 2007-10-29
  24. ^ "Understanding Table Index Values in SNMP".
  25. ^ "SNMP Research presentations in favor of standards-based management over proprietary CLIs". SNMP Research. Retrieved 2010-10-12.
  26. ^ CERT Advisory CA-2002-03 Multiple Vulnerabilities in Many Implementations
  27. ^ a b c d Andrew G. Mason & Mark J. Newcomb (2001). Cisco Secure Internet Security Solutions. Cisco Press. ISBN 9781587050169.{{cite book}}: CS1 maint: 작성자 파라미터 사용(링크)
  28. ^ Andrew G. Mason & Mark J. Newcomb (2001). Cisco Secure Internet Security Solutions. Cisco Press. pp. 52. ISBN 9781587050169.{{cite book}}: CS1 maint: 작성자 파라미터 사용(링크)
  29. ^ HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3. RFC 7630.
  30. ^ "SANS Institute - CIS Critical Security Controls".

추가 정보

외부 링크

Wikdiversity에는 Simple Network Management Protocol에 대한 학습 리소스가 있습니다.