Monitoring
Network Feedback
- ECN (Explicit Congestion Notification): Router set up ECN flag
- ICMP (Internet Control Management Protocols): ping/traceroute 등으로 사용
- TCP ACK: sequence number 로 알아차리는거
Simple Network Management Protocol (SNMP)
We want to….
- Reach everywhere: 모든 타입, 종료의 기기들 (스위치, 라우터, ap, IoT 등등)
- Lightweight: 기기의 성능에 영향 가지 않도록 (no interference on device)
- No rates, no calculation, no history
- No absolute clock: 정해진 클록이 존재하지 않음 (즉 다양한 클록 스피드로 통화가능)
- 단지 Counters/gauage, Time since start-up, strings/identifiers 만 존재
- 시간은 1/100 sec 단위이다
- command/control 은 변수 셋팅을 통해 이루어진다
- Operate when under stress: 부하가 걸린 상태에서도 작동 가능하게
- 뭐가 문제인지 알아내고 고칠수 있도록 도움을 주기위해서
- Scale to large num of device: 글로벌 네이밍, delegated, 제조사-독립적, 추가적
- 즉 누가 만들고 이런거를 떠나서 다양하게 많은 수의 기기들을 포함할수 있도록
- Provide both queries/response and command/control: 질문/답변, 명령/조종 모두 가능하게
- security and upgrade later
말 그대로 간단한 네트워크 조절 프로토콜로, 네트워크에 수많이 존재하는 모든 기기들 (무슨 타입 종류건 상관없이) 에 대해 문제가 생기면 고칠수 있고, 해당 기기와 교류 할 수 있는 (질문답변…) 것을 제공하는 것.
이는 곧 해당 네트워크 기기에 문제가 생기면 경로를 탐색할 필요 없이 걔만 고치면됨.
따라서 부담을 줄이기 위해 UDP 161 (서버), 162 (에이전트) 포트를 사용한다.
여기서 에이전트는 (서버) 클라이언트는 (매니저) 이다.
SNMP
- 어플리케이션 프레임워크
- 네트워크 리소스의 관리 및 모니터링 담당
- SNMP 구성요소로는 다음과 같다
- SNMP agents: 각 기기에 존재하는 소프트웨어
- 설정및 데이터베이스 상태 관리
- Proxies: 혹은 non-SNMP (IoT 등등 얘를 거쳐야만 그 기기랑 대화 가능) 기기와 대화 가능한 프록시 역할해주는 agent
- Proxy agent 와 Proxied Agent가 존재한다.
- SNMP managers: agent와 대화하는 어플리케이션
- 해당 에이전트의 데이터베이스를 쿼리 혹은 수정하는 역할
- 또한 네트워크 장치의 이벤트를 인식함 (에이전트가 전송함)
- Network management system 의 일부이다
- Management Information Bases (MIB)
- 다양한 데이터 베이스 구조가 존재함
- Structure of management Information (SMI) 는 MIB에 존재하는 관련된 오브젝트를 정의함
- 즉 관리 장치에 대한 정보가 집합되어 있는 데이터베이스
- SNMP protocol
- 여러 버전 존재함 1, 2, 3
- SNMP agents: 각 기기에 존재하는 소프트웨어
SNMP Messages
- SNMP/UDP is connectionless
- request ID 를 이용하여 세션을 유지한다
- SNMP messages use “protocol data units” - PDUs
- 다양한 버전의 SNMP는 같은 PDU를 다른 메세지로 사용한다 (그래서 지금 문제되고 있음)
- 또한 각 다양한 메세지 form은 이 PDU의 전체 맥락에서 조금씩 바꿔서 사용하는것
Trap : 에이전트가 무슨일이 있다고 (이벤트) 매니저에게 알리는것 (비동기적 - 일방적으로 알리는것)
- 링크 다운/업, 스타트 콜드/웜 (급작스러운 재시작 혹은 예정된 재시작)
- 인증실패, egpNeighbourLoss (링크는 켜졌는데 이웃이 사라짐)
과 같은 6가지 기본 상태와 벤더에 따른 여러 trap 상태가 존재한다 2^32 개수까지 존재 가능
SNMP Community - 어디 소속인지
- SNMP1 의 경우
- 특정 변수 셋트에 대해 특정한 액세스를 정의함
- read-write, read only, none 등의 세가지 타입이 있음
- 각각의 SNMP 는 community name 이
- 패스워드 같고, 암호화 되어 있지 않음
- 이게 무슨말이냐면 read-only: Public, read-write: Private 가 비밀번호임 ㅋㅋㅋㅋ
- 따라서 보안적으로 하나하나 새로 설정해 주지 않으면 위가 기본 비밀번호
- 에이전트가 특정 IP 주소를 저장해서 해당 아이피의 매니저만 데이터베이스 건드릴수 있도록 하는것도 가능
SNMP Versions
- v2c
- 벌크 기능 추가, 매니저간 대화 기능 추가, TCP 기능 추가, 64 비트 카운터 추가
- v3
- 보안 추가 (v2c 의 기능은 없음)
보통 다들 v1,2,3 모두 지원함
SNMP Security
- v1 - community string 을 인증 방법으로 이용함 (아까 그 public, private) - 암호화 전무
- v2 - 위 문제 고쳤어야 하는데 안고침 ㅋㅋ
- v3
- Integrity - 패킷이 tampered 되지 않음을 분명히 함
- authentication - 정당한 소스로부터 해당 메세지가 왔음을 분명히 함
- privacy - 메세지가 읽히지 않음을 분명히 함
- 다향한 보안 단계를 가지고 있으며, 단계에 따라 접근 권한이 다르다
- noAuthNoPriv: 유저네임 매칭을 통한 인증 방법
- authNoPriv: 메세지 digest를 이용한 인증 방법
- authPriv: message digest 를 통한 인증과 암호화 사용
MIB 안에 값들이 저장되어 있는데, SMI 를 통해 정보가 수집된다 (통계 자료 등등)
예를 들어 값들이 어느 디렉토리 안에 저장되면, 해당 디렉토리까지 가는데 SMI 을 통해서 지나간다. 이 지나가는 와중에 해당 정보들을 structure 하게 수집해서, 몇개의 패킷이 지나갔는지, 지금 전송율이 어떤지 등등을 모집하는것이 바로 Structure for Management Information (SMI) 이다.
물론 에이전트가 직접 계산하는게 아니라, 단지 자료를 모음으로써 위의 계산들을 가능하게 해주는 형식
Counter / Gauages
- 위 두가지가 현재를 가장 잘 알려줌
- Counter: 현 인터페이스에 존재하는 패킷들 (can wrap)
- Gauge: 메모리/디스크 공간 (0부터 맥시멈까지)
- 에이전트는, 다시 말하지만, history를 가지지 않으며 계산도 하지 않음
- 단지 켜진 순간부터 얼마나 시간이 지났나만 알고 있음
- 따라서 매니저는 계속해서 물어보면 다음과 같은 가정들을 세워야함
- Counter 가 바뀌지 않았다 (패킷 수가 똑같다) → 이전과 같은 상태
- Gauge가 바뀌지 않았다 → 이전과 같을수도 다를수도 있다 (메모리/디스크 소비량은 같은데 값은 바뀔수 있으니까)
- MIB 디자이너는 해당 정보를 위해 여러 필드/타입이 필요 할 수 있다 (즉 어느 정보를 유추하기 위해서는 여러가지 필드들을 참조해야 할 수 있다)
ASN
데이터들은 ASN 이라는 Abstract Syntax Notation One 규격에 따라서 저장된다
string 예시로는
- Access: Read only, read-write, write-only, not-accessible
- Status: mandatory, current, optional, obsolete
이 존재한다
가장 중요한것은 Object Identifier 이다
- 정보 오브젝트와 레퍼런스를 알려주는 identifier로 international 한 수준에서 관리된다.
- globally unique → MIB에서 무조건 unique 함
OID (Object Identifier)
- 나무 계층적이다 (DNS처럼) - 각 OID 는 나무의 노드에 해당한다
- 1.3.6.1.2.1 의 경우 루트에서부터 각 계층의 OID를 타고 내려오는것
- 제조사는 각자 이 OID에 특정한 object를 만들수 있음
즉 MIB 1.3.6.1.2.1.2 의 디렉토리에 ifNumber 라는 오브젝트를 만드는것. 해당 오브젝트는 Integer를 (읽기만 가능하며) 값으로 가지며 필수적인 오브젝트.
OID 의 필요성?
OID 가 왜 필요하느냐 하면
- gloabl uniqueness 와 extensibility를 가지고 있다
- human-readable-names를 나무-위치-identifier 형식으로 가지고 있다
- ASN1 은 테이블 (사람이 쉽게 읽을수 있는) 을 제공하지 않는데, 사람이 관리상 필요함
Table and GetNext
Get-Next : 예를 들어 IP 관련 데이터를 받으려면, 하나 받고 그다음꺼로 계속 요청해야함
즉 같은 형식의 정보를 얻으려면 GetNext를 계속 반복해야 하는거 → 당연히 GetNext를 반복하면 트래픽도 생기고, 관리하기도 힘들다
버전2 에서 이를 위한 벌크 형식이 등장했는데 다음과 같이 작동한다
- Get bulkt(“interface”) - every row every column 을 넘기는 형식
- ONLY ONE UDP 로만 반응한다. 만약 이 64kb의 UDP 제한을 넘기면 tooBig 이라는 오류가 발생한다.
- 즉 트래픽 최소화를 위해 한 UDP로 교환이 가능하도록 만들어둔것.
SNMP를 내 도메인 이후로 넓히는것은 현명하지 않은 선택이다.
- 에이전트들을 바깥에 보여주는것은 옳지 않으며 (보안상인듯) - 특히 보안이 약한 1,2
- 이로 인해 많은 트래픽이 생성되고
- 남들이 해당 네트워크를 쉽게 스캔, 맵핑할수 있기 때문.
이로 인해 타 도메인과의 확장은 사람간의 문제가 된다.
