웹사이트 검색

SNMP(Simple Network Management Protocol) 소개

소개

시스템 관리자의 역할 중 상당 부분은 서버 및 인프라에 대한 정확한 정보를 수집하는 것입니다. 이러한 유형의 정보를 수집하고 처리하기 위한 다양한 도구와 옵션이 있습니다. 그들 중 다수는 SNMP라는 기술을 기반으로 합니다.

SNMP는 단순 네트워크 관리 프로토콜을 나타냅니다. 이는 서버가 현재 상태에 대한 정보를 공유할 수 있는 방법이며 관리자가 미리 정의된 값을 수정할 수 있는 채널이기도 합니다. 프로토콜 자체는 매우 단순하지만 SNMP를 구현하는 프로그램의 구조는 매우 복잡할 수 있습니다.

이 가이드에서는 SNMP 프로토콜의 기본 사항을 소개합니다. 프로토콜의 용도, 네트워크에서 프로토콜이 일반적으로 사용되는 방식, 프로토콜 버전의 차이점 등에 대해 살펴보겠습니다.

기본 개념

SNMP는 네트워킹 스택의 애플리케이션 계층에서 구현되는 프로토콜입니다(네트워킹 계층에 대해 알아보려면 여기를 클릭하십시오). 프로토콜은 일관된 방식으로 매우 다른 시스템에서 정보를 수집하는 방법으로 만들어졌습니다. 다양한 시스템과 연계하여 사용할 수 있지만 정보를 조회하는 방법과 해당 정보에 대한 경로가 표준화되어 있습니다.

여러 버전의 SNMP 프로토콜이 있으며 많은 네트워크 하드웨어 장치가 일종의 SNMP 액세스를 구현합니다. 가장 널리 사용되는 버전은 SNMPv1이지만 여러 면에서 안전하지 않습니다. 그것의 인기는 주로 야생에서의 편재성과 오랜 시간에 기인합니다. 특별한 이유가 없다면 고급 보안 기능을 제공하는 SNMPv3를 사용하는 것이 좋습니다.

일반적으로 SNMP에 의해 프로파일링되는 네트워크는 주로 SNMP 에이전트를 포함하는 장치로 구성됩니다. 에이전트는 하드웨어에 대한 정보를 수집하고 미리 정의된 항목으로 구성하고 SNMP 프로토콜을 사용하여 쿼리에 응답할 수 있는 프로그램입니다.

정보에 대해 에이전트를 쿼리하는 이 모델의 구성 요소를 SNMP 관리자라고 합니다. 이러한 시스템은 일반적으로 네트워크에 있는 모든 SNMP 지원 장치에 대한 데이터를 가지고 있으며 정보를 수집하고 특정 속성을 설정하기 위한 요청을 발행할 수 있습니다.

SNMP 관리자

SNMP 관리자는 SNMP 에이전트에서 정보를 폴링하도록 구성된 컴퓨터입니다. 핵심 기능에 대해서만 논의할 때 관리 구성 요소는 단순히 데이터를 요청하기 때문에 실제로 클라이언트 구성보다 훨씬 덜 복잡합니다.

관리자는 올바른 자격 증명을 사용하여 SNMP 에이전트에 쿼리 요청을 보낼 수 있는 모든 시스템일 수 있습니다. 때때로 이것은 모니터링 제품군의 일부로 구현되는 반면 다른 경우에는 관리자가 몇 가지 간단한 유틸리티를 사용하여 빠른 요청을 작성합니다.

SNMP 프로토콜에 정의된 거의 모든 명령(나중에 이에 대해 자세히 살펴보겠습니다)은 관리자 구성 요소에서 보내도록 설계되었습니다. 여기에는 GetRequest, GetNextRequest, GetBulkRequest, SetRequest, InformRequest 및 응답. 이 외에도 관리자는 Trap 및 Response 메시지에 응답하도록 설계되었습니다.

SNMP 에이전트

SNMP 에이전트가 대부분의 작업을 수행합니다. 그들은 로컬 시스템에 대한 정보를 수집하고 이를 쿼리할 수 있는 형식으로 저장하고 \관리 정보 베이스\ 또는 MIB라는 데이터베이스를 업데이트하는 일을 담당합니다.

MIB는 쿼리하거나 설정할 수 있는 정보를 저장하는 미리 정의된 계층 구조입니다. 이는 올바른 자격 증명으로 인증된 호스트(SNMP 관리자)에서 발생하는 올바른 형식의 SNMP 요청에 사용할 수 있습니다.

에이전트 컴퓨터는 정보에 액세스할 수 있는 관리자를 구성합니다. 또한 SNMP 트래픽에 대해 구성되지 않은 연결할 수 있는 장치에 대한 정보를 보고하는 중개자 역할을 할 수 있습니다. 이는 구성 요소를 온라인으로 전환하고 SNMP에 액세스할 수 있는 많은 유연성을 제공합니다.

SNMP 에이전트는 프로토콜에 의해 정의된 대부분의 명령에 응답합니다. 여기에는 GetRequest, GetNextRequest, GetBulkRequest, SetRequest 및 InformRequest가 포함됩니다. 또한 에이전트는 Trap 메시지를 보내도록 설계되었습니다.

경영 정보 베이스의 이해

SNMP 시스템에서 가장 이해하기 어려운 부분은 아마도 MIB 또는 관리 정보 기반일 것입니다. MIB는 관리자와 에이전트가 준수하는 표준을 따르는 데이터베이스입니다. 이것은 많은 영역에서 전 세계적으로 표준화된 계층 구조이지만 벤더별 추가를 허용할 만큼 충분히 유연합니다.

MIB 구조는 하향식 계층 트리로 가장 잘 이해됩니다. 분기되는 각 분기에는 식별 번호(1부터 시작)와 해당 계층 수준에 대해 고유한 식별 문자열로 레이블이 지정됩니다. 문자열과 숫자를 서로 바꾸어 사용할 수 있습니다.

트리의 특정 노드를 참조하려면 트리의 이름 없는 루트에서 해당 노드까지의 경로를 추적해야 합니다. 상위 ID의 계보(숫자 또는 문자열)는 가장 일반적인 것부터 시작하여 함께 연결되어 주소를 형성합니다. 계층 구조의 각 교차점은 이 표기법에서 점으로 표시되므로 주소는 점으로 구분된 일련의 ID 문자열 또는 숫자가 됩니다. 이 전체 주소를 개체 식별자 또는 OID라고 합니다.

장치에 SNMP 에이전트를 포함하는 하드웨어 공급업체는 때때로 자체 필드 및 데이터 포인트를 사용하여 사용자 지정 분기를 구현합니다. 그러나 잘 정의되어 있고 모든 장치에서 사용할 수 있는 표준 MIB 분기가 있습니다.

우리가 논의할 표준 분기는 모두 동일한 상위 분기 구조 아래에 있습니다. 이 분기는 준수 장치에 대한 수정된 표준인 MIB-2 사양을 준수하는 정보를 정의합니다.

이 분기의 기본 경로는 다음과 같습니다.

1.3.6.1.2.1

다음과 같은 문자열로도 나타낼 수 있습니다.

iso.org.dod.internet.mgmt.mib-2

섹션 1.3.6.1 또는 iso.org.dod.internet은 인터넷 리소스를 정의하는 OID입니다. 기본 경로에서 뒤따르는 2 또는 mgmt는 관리 하위 범주에 대한 것입니다. MIB-2 사양을 정의하는 1 또는 mib-2입니다.

이것은 MIB 트리에 익숙해지는 데 유용한 리소스입니다. 이 특정 페이지는 우리가 이야기해 온 교차점의 연결 노드를 나타냅니다. "superior\ 및 "subsidiary\ 참조를 각각 확인하여 트리의 위 아래에 무엇이 있는지 확인할 수 있습니다.

또 다른 유사한 도구는 SolarWinds에서 제공하는 유사한 트리입니다.

기본적으로 장치에 정보를 쿼리하려는 경우 대부분의 경로는 1.3.6.1.2.1로 시작합니다. 쿼리 및 설정에 사용할 수 있는 정보의 종류를 알아보기 위해 트리 인터페이스를 탐색할 수 있습니다.

SNMP 프로토콜 명령

SNMP가 이처럼 많이 채택된 이유 중 하나는 사용 가능한 명령의 단순성입니다. 구현하거나 기억해야 할 작업이 거의 없지만 프로토콜의 유틸리티 요구 사항을 해결할 수 있을 만큼 유연합니다.

다음 PDU 또는 프로토콜 데이터 단위는 프로토콜에서 허용하는 정확한 메시징 유형을 설명합니다.

  • Get: 특정 OID의 값을 요청하기 위해 관리자가 에이전트에게 Get 메시지를 보냅니다. 이 요청은 데이터와 함께 관리자에게 다시 전송되는 응답 메시지로 응답됩니다.
  • GetNext: GetNext 메시지를 통해 관리자는 MIB에서 다음 순차 개체를 요청할 수 있습니다. 이것은 쿼리할 OID에 대해 걱정하지 않고 MIB의 구조를 순회할 수 있는 방법입니다.
  • 설정: 에이전트의 변수가 보유한 값을 변경하기 위해 관리자가 에이전트에 설정 메시지를 보냅니다. 이는 구성 정보를 제어하거나 원격 호스트의 상태를 수정하는 데 사용할 수 있습니다. 이것은 프로토콜에 의해 정의된 유일한 쓰기 작업입니다.
  • GetBulk: 이 관리자-에이전트 요청 기능은 여러 GetNext 요청이 이루어진 것처럼 작동합니다. 관리자에게 회신하는 회신에는 패킷이 허용하는 한 가능한 한 많은 데이터가 포함됩니다(요청에 의해 설정된 제약 내에서).
  • 응답: 상담원이 보낸 이 메시지는 요청된 정보를 다시 관리자에게 보내는 데 사용됩니다. 이것은 요청된 데이터의 전송 및 요청 수신 확인의 역할을 모두 수행합니다. 요청한 데이터를 반환할 수 없는 경우 응답에는 추가 정보로 설정할 수 있는 오류 필드가 포함됩니다. 위의 모든 요청과 알림 메시지에 대한 응답 메시지가 반환되어야 합니다.
  • 트랩: 트랩 메시지는 일반적으로 에이전트가 관리자에게 보냅니다. 트랩은 이를 수신하는 관리자가 요청하지 않는다는 점에서 비동기 알림입니다. 관리 장치에서 발생하는 이벤트를 관리자에게 알리기 위해 에이전트가 주로 사용합니다.
  • 알림: 트랩 수신을 확인하기 위해 관리자는 에이전트에게 다시 알림 메시지를 보냅니다. 에이전트가 이 메시지를 받지 못하면 트랩 메시지를 계속해서 다시 보낼 수 있습니다.

이러한 7가지 데이터 단위 유형을 통해 SNMP는 네트워크 장치에 대한 정보를 쿼리하고 보낼 수 있습니다.

프로토콜 버전

SNMP 프로토콜은 처음 도입된 이후 많은 변화를 겪었습니다. 초기 사양은 1988년에 RFC 1065, 1066 및 1067로 공식화되었습니다. 이 버전이 오랫동안 사용되었다는 단순한 사실에 의해 이 버전은 여전히 널리 지원됩니다. 그러나 일반 텍스트 인증을 포함하여 프로토콜에는 많은 보안 문제가 있으므로 특히 보호되지 않은 네트워크에서 사용하는 경우 사용을 권장하지 않습니다.

프로토콜 버전 2에 대한 작업은 1993년에 시작되었으며 이전 표준에 대한 몇 가지 실질적인 개선 사항을 제공합니다. 이 버전에는 이전 버전에 내재된 보안 문제를 해결하기 위한 새로운 "파티 기반\ 보안 모델이 포함되어 있습니다. 그러나 새 모델은 이해하고 구현하기 어렵기 때문에 그다지 인기가 없었습니다.

이로 인해 버전 2의 몇 가지 "스핀오프\가 생성되었으며, 각각은 버전 2 개선 사항의 대부분을 유지했지만 보안 모델을 교체했습니다. 커뮤니티 기반 인증인 SNMPv2c에서는 동일한 모델이 v1이 다시 도입되었습니다. 이것은 v2 프로토콜의 가장 인기 있는 버전이었습니다.SNMPv2u라고 하는 또 다른 구현은 사용자 기반 보안을 사용합니다.이것은 결코 대중적이지 않았지만 이것은 사용자별 인증 설정을 허용했습니다.

1998년에 SNMP 프로토콜의 세 번째(및 현재) 버전이 사양 제안으로 입력되었습니다. 사용자 입장에서 가장 의미 있는 변화는 사용자 기반 보안 시스템의 도입이었다. 사용자의 인증 요구 사항을 다음 모델 중 하나로 설정할 수 있습니다.

  • NoAuthNoPriv: 이 수준으로 연결하는 사용자는 인증이 없으며 보내고 받는 메시지에 대한 개인 정보가 없습니다.
  • AuthNoPriv: 이 모델을 사용하는 연결은 인증을 받아야 하지만 메시지는 암호화 없이 전송됩니다.
  • AuthPriv: 인증이 필요하며 메시지가 암호화됩니다.

인증 외에도 사용자가 액세스할 수 있는 분기에 대한 세분화된 제어를 제공하기 위해 액세스 제어 메커니즘이 구현되었습니다. 또한 버전 3에는 SSH 또는 TLS와 같은 전송 프로토콜에서 제공하는 보안을 활용할 수 있는 기능이 있습니다.

결론

이제 프로토콜이 작동하는 방식에 대해 잘 알고 있으므로 자체 인프라에서 SNMP를 구현하는 데 필요한 기반을 갖추었습니다.

다음 가이드에서는 시스템에서 SNMP를 활용하는 데 필요한 구성 요소를 설치하고 구성하는 방법에 대해 설명합니다.