[ 11. NMS/SNMP/TFTP ] - SNMP 개론

SNMP(Simple Network Management Protocol)

 

과거
CMIP, SGMP 등으로 섞여 있다가, 프로토콜의 표준화가 1988년에 진행.
복잡함 -> 간소화(SGMP) -> SNMP 로 발전.
TCP/IP -> UDP

- 실제로 심플(간단한)한 프로토콜이 아닙니다.

 기존에 사용되던 프로토콜들보다 보다 간소화되었을 뿐. ( 혼동하지 말 것 )

 

 네트워크 관리 프레임워크 ( Network Management Framework )

->  NMS ( Network Management SYSTEM ) 
 
 명령 직접 전달이 아닌, 정보를 직접 전달하는 관리시스템
 = 변수를 객채마다 설정 후(MIB) 관리시스템에 체계적 전달.

 - 네트워크 관리 프레임워크에서는 SMI 로 변수를 만들어내고 이를 하나의 객채로 취급함

= MIB 
 

 -  MIB 에 의해 공용의 틀이 갖춰지기 때문에, 다른 시스템(에이전트)끼리라도,

상위의 관리 시스템에선 처리가 가능해 집니다. =>  SNMP Protocol

 

 

 

 

 
 NMS의 관리시스템 체계

 
 [ 하나의 관리시스템 체계 구성 ]

 

 1. 관리되는 노드
 2. 관리해주는 시스템
 3. 정보 공유 및 처리를 가능케 하는 공통 변수 ( MIB ) 필요.
 4. 이를 전달해주는 SNMP 프로토콜이 필요.

 
 을 모두 갖추고 있어야 합니다.
 
 
 편의상 SNMP 시스템을 = NMS 라고 부르고 있기도 합니다.

 
 
 SNMP 
 

 

 

 

[ MIB ]

 SMI ( 관리 정보 구조 )
= 데이터 설명 언어
= MIB 정보가 어떻게 정의되어야 하는지를 기술.
= 여러 장비의 호환성을 제공하면서 정의해야 하므로 공통된 방식으로 표현
= MIB 객체와 모듈이 구성될 때 지켜야 할 규칙을 정의하며, ISO 추상표기법(ASN.1, Abstract Syntax Notation) 이라고 하는 데이터 설명 언어를 기반으로 한다

 

 

 MIB
= 한 장비가 가지는 정보 객체의 집합
= MIB 객체는 주로, MIB 모듈이라고 불리는 집합으로 묶여 있음
= 모듈 형태로 구성되기 때문에 필요한 경우 추가해서 이용 가능하므로 확장성, 유연성이 높다.

 

 

 • SMI로 MIB 객체 생성 : 3단계 추상화
 - SNMP 프로토콜이 네트워크 장비의 현 상태를 나타내는 변수를 옮긴다.
 - MIB 는 이 변수의 의미를 정의
 - SMI가 MIB 내의 변수들이 어떻게 정의되는지 규정.

 

 
 • MIB 객체 속성 : 필수 5가지

 1) 객체명

 - 객체 서술명 : 문자로 된 이름
 - MIB객체가 속해있는 그룹에 따라 정해진다.
 - 객체 ID(=)OID=Object ID 
 -  * MIB 계층 안에서 해당 객체의 위치를 나타내는 숫자 이름
 -  * 현재 1만개 이상의 MIB 객체를 모두 다른 이름으로 관리하기 어려우므로 DNS 표기법과 같은 형식으로 구조화하여 최상위부터 점을 찍어서 표시하는 방법이다.

 
 최상위 ROOT 는 OID 표기를 하지 않는다.
 • ROOT { } : 별도의 이름이 없으며, 자식 노드 3개를 가지고 있는 역할만 하고 있다.
 • ccitt(0) : ITU(T) 를 위한 계층
 • iso(1) : iso 표준을 위한 계층
 • joit-iso-ccitt(2) : 위 두 개를 같이 쓰는 장비에서 지정한 표준을 위한 계층
 • 1.org(3) : 다른 조직을 위한 계층
 • 1.3.dod(6) :  미 국방성을 위한 계층
 • 1.3.6.internet(1) : 인터넷을 위한 계층
 -> 우리가 사용하고 있는 모든 객체는 1.3.6.1 에 소속된다.
  • 1.3.6.1.directory(1) : iso가 추후에 사용하기 위해 예약
  • 1.3.6.1.mgmt(2) : 대부분의 표준 MIB 객체가 속한 위치
  • 1.3.6.1.experimemtral(3) : 실험적 객체를 위한 공간
  • 1.3.6.1.private(4) : 사설 기업들을 위해 정의
  • 1.3.6.1.security(5) : 보안을 위해 예약
  • 1.3.6.1.snmpv2(6) : v2 만을 위한 객체 정의
  -> 일반객체(1.3.6.1.2.min(1)) , 사설객체(1.3.6.4.enterprise(1))
 ( 예제 cisco : 1.3.6.1.4.1 )

 

Root Manage 가 Agent 의 IP 에 도달하는 값은 큰 용량이 아닌 OID 의 단순한 1.3.6.1.1.1.4 의 값으로 정의되어 집니다.

   
 2) 형식 : MUB 객체의 자료형과 구조 정의

 • 일반 자료형
 - 정수, 문자열과 같이 정보 하나를 나타냄
 - v1 : 원시/정의 자료형
 - v2 : 기본 자료형

 

 
 • 도표형 자료형
 - 기본형 목록, 기본형을 표로 만든 경우
 - v1 : 생성자 자료형
 - v2 : 개념 자료형

 
 3) 접근 권한( vs : 최대 접근 권한 )

 v1 : 읽기/쓰기/읽고쓰기/접근 금지
 v2 : 계층적 5단계 구조, 상위 계층은 하위 계층 권한을 포함.
  * 5단계 : 생성 읽기(읽기/쓰기/생성)
  * 4단계 : 읽고 쓰기(읽기/쓰기)
  * 3단계 : 읽기(읽기만)
  * 2단계 : 통지 전용(통지, 트랩일 경우만)
  * 1단계 : 접근금지(특수 용도)

 

 

 4) 상태

  * 객체에 관한 필요 유무
  * v1 : 필수/선택/대체
  * v2 : 현재 사용(=v1의 필수)/대체/권장안함

 

 
 5) 정의
  * MIB 객체에 대해 글로 서술.

 

 
 6) 선택적 속성(v2)
  * 단위(Unit) : MIB 객체와 관련된 단위를 글로 서술.
  * 참조(reference) : 관련 문서나 기타 자료에 대한 내용을 추가할 때 사용
  * 인덱스 ( index ) : 여러 MIB 객체들로 이뤄진 객체들을 정의할 때
  * 증분(Augments) : 인덱스 대신 쓸 수 있는 속성
  * 기본 값 (DefVal) : 객체의 기본값 정의
 

 기타 정보 사이트  : http://www.iana.org/assignments/smi-numbers

 
  * 모듈 형식
  - SNMPv2에서 정의
  - 모듈명 : 모듈의 이름(서술형(문자)/숫자형(ID))
  - 마지막 갱신 : 모듈의 마지막 갱신 날짜, 시간
  - 조직 : 모듈을 개발한 조직의 이름
  - 연락처 : 모듈 담당자 이름, 주소, 전화번호, 이메일
  - 서술 : 모듈에 대한 요약 정보
  - 개정 요약/개정 번호 : 모듈 개발 과정을 기록하기 위해 개정될 때마다 개정 항목이 하나씩 추가되며 각 항목마다 개정 내역에 대한 설명을 덧붙임
 

 

 

SNMP Protocol Version History

 
 • SNMPv1
 - 1988년초 개발
 - 구성요소 : SMI, MIB, SNMP 프로토콜
 - 인증 : Community String(비밀번호)에만 의존. 공격에 매우 취약
 - 트래픽을 암호화하지 않으며 보안기능이 없음
 
 

 • SNMPsec
 - 1992년
 - party 라고 불리는 논리 식별자를 이용한 새로운 보안방식 정의
 = 네트워크의 과부하로 인한 속도 및 처리효율이 떨어짐.
 - 사(死)장됨.
 

 • SMNPv2
 
 1) SNMPv2 classic, SNMPv2p

  - SNMPsec의 party 개념을 그대로 이어옴
  - party 기반의 보안 모델이 복잡하다는 이유로 사장됨

  
 2) SNMPv1.5

  - SNMPv2의 내용 중 기능 향상 부분만 가져오고, v1의 Community String 인증을 계속 이용하는 형태
  - 상업적 실패

  
 3) SNMPv2c(community)

  - v2에서 복잡한 보안기능을 제거 

( v2 의 향상된 기능만 채용하고 보안 방식은 v1 의 Community String 을 그대로 채용하여 사용법도 간편 )

  - SNMPv 1.5와 같지만 상업적으로 성공. 
  - 실험적 표준 : RFC 1902 ~ 1908

  
  
 4) SNMPv2u(user)

  - 사용자 기반의 새로운 보안 모델 사용
  - Community String 보다는 보안성이 높고 Party 보다는 단순한 모델
  - RFC 1909 ~ 1910

  
 5) SNMPv2* = SNMPv2p 와 SNMPv2u 가 합쳐진 형태. 거의 사용하지 않음
 
 
 = 변종에 의한 혼란 때문에 많은 네트워크 관리자들이 SNMPv2 의 사용을 포기하고 SNMPv1 또는 SNMPv2c 를 이용.

 

 
 • SNMPv3

 - 1998년에 발표
 - SNMPv2 기능을 모두 포함하고 보안 모델을 SNMPv2u에서 사용된 사용자 기반 보안 모델, View 보안 모델 등 다양한 모안 모델을 지원.
 
 v3 부터는 에이전트 <-> 매니지먼트의 설정값 변경에 의해 역할 체인지 가능
 
 - SNMP 관리에 유옹한 각중 툴 정의
 - Manager 역할과 agent 역할이 호환(설정변경으로 역할을 서로 <-> 교체 가능)

 

 

 

 

 
 • SNMP 프로토콜 버전 별 RFC 문서 :
 http://www.rfc-editor.org/rfc-index.html
  

 • V2 에서는 표준 문서를 프로토콜 동작, 전송 매핑 2가지로 정의

 1) 프로토콜 동작
  - MIB 객체가 SNMP 메시지를 사용하여 실제로 전송하는 방법을 정의

 

 2) 전송 매핑
  - 여러 네트워크 환경에서 실제 전송되는 방법 정의
  가장 흔히 사용하는 전송 매핑 = IP

 

 • 통신 방식

 1) 기본 : 매니저가 요청하면(서버-------> 클라이언트) agent 가 응답
 2) polling 방식
  - 정보를 얻고자 하는 쪽에서 먼저 요청 
  - 기본 통신 방식

 3) 인터럽트 방식(=trap) 

= 문제,이벤트 등의 상황시 반대로 agent가 manager 에게 전달

  - 매니져의 요청이 없더라도 agent 가 정보를 전달
  - 긴급상황 발생 시 trap 을 통해 인터럽트 활성화.

 

  
 • SNMP PDU(=data)

 - 3가지 클래스로 구분
 1) Internal(내부형) : 내부 SNMP통신을 위한 report 메시지 
 2) Confirmed(확인형) : GetRequest, GetNextRequest, GetBulkRequest , SetRequest
 
 3) Unconfirmed(비확인형) :  (v1) (Get)response, Trap, InformRequest(v3)

 

 
 • SNMP 기본 동작

 1) 매니저가 GetRequest 생성.
  - 사용자/프로그램의 요청에 따라서 필요로 하는 정보를 구성
  - 메시지 = 매니저가 원하는 MIB 객체의 이름
  
 2) 매니저에서 GetRequest 메시지 전달 ( 매니저의 랜덤포트로 출발 )
 3) agent 에서 요청 메시지 수신 후 처리. ( agent의 161번 포트에 도착 )
  - 요청 받은 MIB 객체명의 목록이 agent 가 가지고 있는 MIB객체가 맞는지 확인 후 , 변수의 값을 읽어서 처리.
 4) agent 가 Respose 메시지 생성 ( 받은 161번 포트로 응답 전송 )
  - 요청 받은 MIB 객체의 값과 에러 코드를 포함
 5) agent 가 Response 전달 ( 매니저의 랜덤포트로 들어감 )
 6) 매니저에서 Resonse 수신 후 처리

 
 agent 가 발신한 Trap 메시지의 경우는 도착지가 매니저 쪽의 랜덤포트가 아닌 162번 포트로 들어간다.

 

 

 

 

 

 

 

메시지의 종류
 
 • GetNextRequest / GetBulkRequest
  ( 매니저(주서버)가 만들어내서 에이전트(클라이언트)에게 정보 요청하는 메세지 )

 
 1) MIB 객체 테이블이 구성되어 있는 상황에서만 이용 가능.

 2) Next
  - MIB 테이블의 값을 요청할 때 객체 하나씩을 요청하고 응답 하게 되면 비효율적으로 동작하고 트래픽이 낭비됨
  - 매니저는 에어전트의 테이블에 몇 개의 항목이 있는지 알지 못하기 때문에 몇 번 요청해야 할지 정확하게 구분하지 못한다
  - v1 에서 MIB 테이블의 값을 하나의 요청으로 응답받을 때 사용.
  - 매니저는 테이블 변수의 이름과 테이블 내부의 특정 항목의 이름을 포함해서 요청을 전달하며 에어전트는 지정한 객체의 다음 값을 읽어서 GetResponse 로 응답 ( 테이블은 처음부터 만들어져 있다 )
  - 반복해서 동작 하다가 마지막 값까지 반환하고 다음 테이블의 객체 값을 전송하므로 매니저에게 지정된 테이블의 전송이 완료 됐음을 알려주게 된다. -> 네트워크 부하가 생길 수 있다.

  
 3) Bulk
  - Next 의 동작방식 중 응답을 하나씩 받아와서 트래픽이 낭비되는 문제를 해결하기 위해 사용.
  - v2, v3 에서 사용하며, 테이블 또는 일반 객체를 요청했을 때 하나의 응답 메시지로 정보를 전달. -> 네트워크 부하가 줄어든다.
  - 특별 인자
   § 비반복(Non repeater) : 일반 개체
   § 최대 반복(Max repeater) : 테이블 변수의 항목 개수
  - 주의 : Bulk를 이용 하려면 먼저 테이블의 항목 수를 알아야 함
  아니면 여러 번 물어서 모든 항목을 응답 받음.

 

 

 • SetRequest 

  1) 관리자가 수정해야 할 변수와 값을 지정.
  2) 설정 변경은 시스템에 중요한 내용이므로 에이전트는 요청된 설정 변경 메시지를 분석, 확인한 후 요청을 받아 들임
   - 변경할 객체의 객체명 확인
   - 객체의 접근권한 확인
   - 요청 메시지 값의 자료형( IP 는 숫자형이 아니라 자료형이다 ) 등의 크기가 맞는지 확인

 

   
 • Trap  / InformRequest : 통지 , 알림

  1) 인터럽트 클래스의 메시지 
  2) 긴급 상황이 발생한 경우 에이전트에서 매니저 쪽으로 정보를 먼저 전달할 때 사용 하게 된다.
  3) Trap
   - 모든 에이전트가 사용할 수 있는 기본 내장.
   - 설정 된 트랩 조건이 발생하면 trap 기능이 활성화되면서 trap 메시지를 생성 후 전달.
  4) Inform Request
   - 매니저가 다른 매니저로 정보를 전달하기 위해 사용.
   - 매니저 간 정보를 전달하여 전체 네트워크간 에이전트가 전달한 트랩 메시지를 동기화 하는 목적으로 사용

 

 

   
  
 * SNMP 의 보안 문제 / 보안 정책

 

1) v1 의 보안문제
 - 단 하나의 보안 정책/기술만 이용 -> Community String ( 비밀 번호 )
 - 원래 목적은 관리 영역을 묶어주기 위해 사용

 

2) v2 / v3

 1) Party 기반 보안 모델 ( 장비 자체에 고정세팅 )

  - SNMPv2p에서 채택한 보안 모델
  - 특정 인증 프로토콜과 암호화 프로토콜을 미리 정의하는 파티라는 논리적인 실체를 정의
  - 파티에 정의 된 인증 프로토콜에 의해 인증하며 메시지를 전송하는 양 쪽이 같은 암호화 방식을 사용한다는 것을 보장. 

 

  
 2) 사용자 기반 보안 모듈(USM, User-Based Security Model)

  - SNMPv2u 에서 개발되었으며 SNMPv2* 에서도 채택
  - SNMPv3 에서도 채택
  - 장비별로 보안 정책을 수립하지 않고 사용자별로 보안 정책을 수립
  - 다양한 인증 방식과 암호화 프로토콜을 통해 접근권한을 지키고 메시지 보호.
  - 타임스탬프, 클럭 동기화 등의 기술을 사용해서 공격에 대비.

 

  
 3) 뷰 기반 접근 통제 모델(VACM, View-Based Access Control Model)

  - SNMPv3 에서 개발
  - 한 장비의 각종 MIB 객체의 접근 권한을 개별적으로 정밀하게 정의.
  - 뷰 = 특정 상황에서 특정 그룹에 속한 사람들의 접근이 허용된 MIB 객체를 가상의 테이블에 정의 후, 접근을 구별하여 암호화.
  - 뷰를 생성, 통제하므로 관리자는 누가 어떤 정보에 접근할 수 있는지 정의.

 

 

 

  
  
 SNMP PDU
 
 • 일반 PDU형식

 • PDU 제어 필드 - PUD 타입을 설명하며 정보를 한 SNMP에서 다른 SNMP로 전송하는 필드 모음

 • PDU 변수 바인딩 : PDU 내의 MIB 객체 설명 모음이며 각 객체는 이름을 값에 바인딩한 구조
 

 

 SNMPv1 일반 메시지 형식

 버전 번호 = 0 | 커뮤니티 스트링 | PDU 제어 필드           |

= PDU 변수 바인딩        |   ---> 메시지 본문(PDU)
  ㄴ ( 실제 요청 객체의 정보 등이 들어있다 )

 

SMNPv2p 일반 메시지 형식

v1과 흡사

버전 번호 = 1 | 커뮤니티 스트링 | PDU 제어 필드(PDU 변수 바인딩)

 
 Trap 일반 메시지 형식

 

PDU 종류 | 엔터프라이즈(회사명) | 에이전트 주소 | 트랩 일반 코드 | 세부 트랩 코드
  | 타임 스탬프 ( 시간값 확인 )  -  PDU 변수 바인딩 

 

트랩 PDU Type : 특정 상황의 발생을 매니져에게 알린다.

 
 

 v2 형식 ( 커지고, 사장된 클래스풀 방식 )
 
 버전 번호 = 2
 받는 측
 보내는 측
 컨텍스트
 PDU 제어 필드
 PDU 변수 바인딩
 
  

 

 

 

 

 
 
 주로 사용되는 SNMP(NMS) 관리 프로그램

=> 아주 간단하게 말해서, SNMP 라는 규약하에 속한다면, 윈도우즈, 리눅스 어느 시스템이건 간에, SNMP 패키지, 프로그램을 설치하여, 환경설정을 해 주고, 통합 관리 프로그램에서 정상적인 모니터링을 수행할 수 있게 됩니다.

 
 주로 사용되는 기업의 장비
 
 1. 중규모 ( 몇 백대 이하 ) : opmanager
 http://www.manageengine.com/network-monitoring/
 -> 10대까지 무료 , what's up gold, solawinds 등
 
 2. 대기업 : MC, CA(spectrum), HP, IBM 등
 
 3. 기타 : EM7 , 인프라니스 시스마스터(국산), operview
 
 4. 장비별 성능 비교 :
 http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems
 
 
 
 
 
 [ 테스트 #01 ]

 http://www.solarwinds.com/network-performance-monitor.aspx
 
 [ test drive demo ] 를 클릭하여 preview 가능.