버전별 비교
| 구분 | SNMPv1 | SNMPv2c | SNMPv3 |
|---|---|---|---|
| 관련 RFC | RFC 1155~1157 등 | RFC 1901~1908 | RFC 3411~3418 |
| 접근 통제 | 커뮤니티 문자열 | 커뮤니티 문자열 | 사용자 기반(USM) |
| 인증 | 없음(문자열 일치만) | 없음(문자열 일치만) | 메시지 인증 제공 |
| 암호화 | 없음(평문) | 없음(평문) | 선택적 제공 |
| 특징 | 기본 Get/Set/Trap | GetBulk, 64비트 카운터 추가 | 보안 모델·접근 제어 분리 |
v3의 USM(User-based Security Model, RFC 3414)이 막으려는 위협은 메시지 변조와 사용자 사칭(masquerade)이 주이고, 도청(disclosure)과 메시지 재전송·순서 조작은 제한적으로 다룹니다. 서비스 거부(DoS)와 트래픽 분석은 대상에서 제외한다고 RFC가 밝힙니다. 즉 v3를 써도 "모든 공격이 막힌다"는 뜻은 아닙니다.
실제 사례
사례 1. 2002년 SNMPv1 구현 취약점 (설계가 아닌 구현의 문제)
CERT/CC의 취약점 노트(VU#107186)에 따르면, 핀란드 오울루 대학의 보안 프로그래밍 그룹(OUSPG)이 PROTOS 테스트 도구로 여러 제품의 SNMPv1 처리 코드를 시험해 다수의 결함을 찾았고 2002년 1월에 공개되었습니다. 결함은 서비스 거부, 포맷 스트링, 버퍼 오버플로 등이었고, 일부는 올바른 커뮤니티 문자열 없이도 유발될 수 있었으며 제품에 따라 영향이 달랐습니다. 배울 점은 두 가지입니다. 하나는 프로토콜이 단순해도 구현에서 입력 검증이 허술하면 장비 자체가 위험해진다는 점, 다른 하나는 SNMP 포트를 신뢰할 수 없는 네트워크에 열어 두는 것의 위험이 구현 결함까지 포함한다는 점입니다. 그래서 SNMP는 관리망에서만 접근시키고 장비 펌웨어를 최신으로 유지하는 것이 기본 방어선입니다.
사례 2. 평문 커뮤니티 스트링의 구조적 한계 (설계의 사례)
v1·v2c에서는 커뮤니티 문자열이 평문으로 오가고 IP 위조에도 취약하다고 위키백과가 정리합니다. 읽기용 "public"과 쓰기용 "private" 같은 널리 알려진 기본값이 그대로 남아 있는 경우가 많다는 점도 지적됩니다. 이 사례의 요점은 공격 방법이 아니라 개념입니다. 같은 구간을 지나가는 트래픽을 볼 수 있는 사람은 문자열을 알 수 있고, 문자열을 알면 같은 권한을 얻는다는 구조라서 v3의 사용자별 인증이 필요해졌다는 흐름입니다. 실무에서는 기본값을 바꾸고, 읽기 전용 권한을 쓰고, 관리 서버의 IP로만 접근을 허용하며, 가능하면 v3로 옮기는 순서로 위험을 줄입니다.
사례 3. 가상 예시: 인터페이스 트래픽을 bps로 환산하기
가상 예시입니다. 모니터링 서버가 5분(300초) 간격으로 스위치 포트의 수신 바이트 카운터(MIB-II의 ifInOctets 계열)를 읽었다고 합시다. 첫 값이 4,000,000,000, 다음 값이 200,000,000이면 숫자가 줄어든 것처럼 보이지만, 32비트 카운터는 4,294,967,296에서 0으로 되돌아가므로(래핑) 실제 증가량은 4,294,967,296 − 4,000,000,000 + 200,000,000 = 494,967,296 바이트입니다. 이를 초당 비트로 환산하면 494,967,296 × 8 ÷ 300 ≈ 13,199,128 bps(약 13.2Mbps)입니다. 빠른 링크에서는 32비트 카운터가 금방 한 바퀴를 돌 수 있어 폴링 간격 안에 두 번 이상 래핑되면 값을 알 수 없게 됩니다. v2c에서 64비트 카운터가 추가된 것도 이런 이유와 맞닿아 있습니다.
직접 점검해 보기: 체크리스트
- 장비 설정에서 SNMP가 켜져 있는지, 어느 버전인지 확인한다.
- 커뮤니티 문자열이 기본값(public·private)이 아닌지 확인한다.
- 쓰기 권한이 정말 필요한지 따져 읽기 전용으로 제한한다.
- 접근 허용 IP를 관리 서버로 제한하고, UDP 161·162가 외부에서 열려 있지 않은지 방화벽을 점검한다.
- 지원되는 장비라면 SNMPv3의 인증과 암호화 사용을 검토한다.
흔한 오해와 정정
- 오해: 커뮤니티 문자열은 비밀번호만큼 안전하다. 실제: v1·v2c에서는 평문으로 전송되어 같은 경로를 볼 수 있으면 노출됩니다.
- 오해: SNMP는 조회 전용이라 위험하지 않다. 실제: 쓰기 권한이 열려 있으면 설정이 바뀔 수 있고, 조회만으로도 장비 구성 정보가 드러납니다.
- 오해: v3를 쓰면 SNMP가 완전히 안전하다. 실제: 서비스 거부 같은 위협은 USM의 대상이 아니며, 구현 결함이나 설정 실수는 여전히 위험입니다.
- 오해: 트랩이 있으면 폴링은 필요 없다. 실제: 트랩은 UDP로 전달되어 유실될 수 있으므로 폴링과 함께 쓰는 것이 일반적입니다.
한계와 더 알아볼 점
SNMP는 상태 지표 수집에는 강하지만 대량의 세부 로그나 흐름 단위 분석에는 다른 도구(로그 수집, 플로우 분석)를 함께 쓰는 경우가 많습니다. 최근에는 장비 API나 스트리밍 텔레메트리를 쓰는 환경도 늘고 있어 SNMP의 위치는 환경에 따라 다릅니다. 위키백과는 DTLS·TLS 위의 SNMP가 10161·10162 포트를 쓴다고 정리하는데, 이런 보안 전송 방식의 지원 여부는 장비마다 다르므로 제조사 문서를 확인하세요.
OSI 7계층 어디에 해당할까요
SNMP 같은 응용 계층 프로토콜이 전체 네트워크 구조에서 어디에 위치하는지 궁금하다면OSI 7계층 모델 완전정복도 확인해보세요.
방화벽 정책과 함께 고려하세요
SNMP 포트를 외부에 노출하지 않도록 방화벽 정책을 함께 점검하고 싶다면방화벽(Firewall)이란? 기초 개념 정리도 참고해보세요. 자주 쓰는 포트 번호는 포트 번호 총정리에서 한눈에 볼 수 있습니다.
자주 묻는 질문
SNMP는 일반 가정에서도 쓰이나요?
일부 고급형 공유기나 NAS 장비도 SNMP 모니터링 기능을 지원하지만, 주로 관리해야 할 장비 수가 많은 기업·데이터센터 환경에서 훨씬 폭넓게 활용됩니다.
커뮤니티 스트링을 기본값 그대로 두면 위험한가요?
네, "public"·"private" 같은 기본값을 그대로 두고 SNMP 포트를 외부에 노출하면 누구나 장비 정보를 조회하거나 최악의 경우 설정을 변경할 수 있어 반드시 값을 변경하고 접근을 제한된 IP로만 허용해야 합니다.
폴링과 트랩은 어떻게 나눠 쓰나요?
폴링은 관리 서버가 주기적으로 값을 물어 추이를 쌓는 방식이고, 트랩은 장비가 이상 상황을 먼저 알리는 방식입니다. 추이 그래프는 폴링, 즉각 알림은 트랩이 맡고, 트랩이 유실될 수 있어 둘을 함께 씁니다.
MIB를 모르는 제조사 장비도 조회할 수 있나요?
MIB-II 같은 표준 MIB에 정의된 항목은 제조사와 무관하게 같은 방식으로 읽을 수 있습니다. 제조사 고유 항목은 제조사가 제공하는 MIB 파일을 모니터링 도구에 등록해야 이름으로 해석됩니다.
SNMPv3로 바꾸려면 무엇이 필요한가요?
장비와 관리 서버 양쪽이 v3를 지원해야 하고, 사용자 이름과 인증·암호화 방식, 각각의 비밀값을 정해 양쪽에 같게 등록해야 합니다. 지원 알고리즘은 장비마다 다르므로 제조사 문서를 확인하세요.