시스템 모니터링의 세계에는 두 가지 커다란 기둥이 있습니다. 바로 시스템 로그를 분석하는 것, 그리고 **SNMP(Simple Network Management Protocol)**를 이용해 시스템의 상태와 설정값을 확인하는 것이죠.
보안 관제 초기에는 리소스 사용량(Resource Usage) 모니터링이 핵심이었습니다. 특정 명령어가 실행된 후 CPU 사용률이 치솟거나, 방화벽의 아웃바운드 트래픽이 비정상적으로 급증하는 것은 침해 사고의 중요한 징후입니다. 우리는 이러한 지표들을 여러 장비와 교차 분석(Correlation)함으로써 보안 사고를 식별하고 대응해 왔습니다.
SNMP의 보안적 진화와 취약점
최근 현대적 환경에서는 에이전트 기반의 SIEM을 주로 사용하지만, 서버와 네트워크 장비들은 여전히 SNMP를 기본적으로 지원합니다.
- SNMP v3: 현재 표준으로, 인증(Authentication)과 암호화(Encryption)를 통해 강력한 보안을 제공합니다.
- SNMP v2c: ‘Community String’이라는 단순 키값에 의존합니다.
- SNMP v1: 보안에 매우 취약합니다. Community String이 **평문(Plaintext)**으로 전송되어 스니핑에 노출될 수 있으며, 공격자가 이 키만 알면 시스템 정보를 탈취하거나 장비를 리부팅할 수도 있습니다.
OID와 MIB: 시스템의 주소록
snmpget, snmpwalk 같은 도구로 **OID(Object Identifier)**를 지정하면 시스템 메모리의 값을 직접 가져올 수 있습니다. 구조는 매우 직관적입니다.
- OID
1.3.6.1.2.1.1.3.0(sysUpTime.0): 장비 가동 시간 확인 - OID
1.3.6.1.2.1.1.5.0(sysName.0): 장비 호스트 네임 확인
실무의 교훈: 32-bit Rollover 버그 사례
실무에서 SNMP는 어떻게 활용될까요? 5분마다 트래픽량(Octets)을 수집하는 스크립트만으로도 실시간 대역폭(bps)을 계산해 DDoS 공격을 효과적으로 탐지할 수 있습니다.
실제 장애 해결 에피소드: 과거 유명 L4 스위치가 3개월마다 멈춰버리는 고질적인 문제가 있었습니다. 당시 제조사의 권고는 “정기적 리부팅"뿐이었죠.
저는 SNMP 분석을 통해 인터페이스 트래픽 카운터인
ifOutOctets값이 **32-bit 한계치($2^{32}-1$)**에 도달해 0으로 돌아가는 ‘Rollover(Overflow)’ 현상이 발생할 때 시스템이 다운된다는 것을 찾아냈습니다. 이 기술적 근거 덕분에 제조사의 정식 수정을 이끌어낼 수 있었습니다. (이후 v2c부터 64-bit 카운터가 표준화되었습니다.)
우리가 여전히 SNMP를 이해해야 하는 이유
SNMP를 이해한다는 것은 시스템의 **‘심장박동’**을 읽는 법을 배우는 것과 같습니다. 보안 실무자로서 세 가지 핵심 포인트를 강조하고 싶습니다.
- Pull vs Push의 진화: 서버가 묻는 ‘Pull’ 방식에서, 최근에는 장비가 데이터를 직접 스트리밍하는 Telemetry(Push) 방식으로 진화하고 있습니다.
- SNMP Trap의 가치: 장애 발생 시 장비가 즉시 신호를 보내는 Trap 설정은 실시간 보안 관제의 핵심입니다.
- ‘Write’ 권한의 위험성: 설정 변경이 가능한 Write(Private) 권한이 노출되면 인프라 전체가 장악당할 수 있습니다. 보안 점검 시 반드시 체크해야 할 요소입니다.
SNMP는 단순히 오래된 프로토콜이 아닙니다. 시스템의 깊은 곳(Gut)을 들여다볼 수 있게 해주는 강력한 도구입니다. 그 취약점과 활용 가능성을 정확히 이해하는 것이야말로 진정한 기술적 통찰(Insight)이라 할 수 있습니다.