SNMP Community String의 보안

네트워크 장비를 운영하다 보면 SNMP는 너무 익숙한 프로토콜이다. 스위치나 라우터의 CPU 사용률을 확인하고, 인터페이스 트래픽을 수집하고, 장비 상태를 모니터링하기 위해 많은 네트워크 관리 시스템(NMS)이 SNMP를 사용한다.

그러다 보니 SNMP를 단순한 모니터링용 프로토콜 정도로 생각하기 쉽다.

하지만 SNMPv1이나 SNMPv2c를 사용하고 있다면 이야기가 조금 달라진다. 이 환경에서 사용하는 community string은 사실상 SNMP 접근을 허용하는 공유 비밀번호에 가깝다. 특히 이 값이 노출되거나 추측하기 쉽고, 접근 제어까지 제대로 되어 있지 않다면 공격자가 장비 정보와 내부 연결 관계를 파악하는 데 이용할 수 있다.

더 위험한 것은 RW(Read-Write) 권한까지 열려 있는 경우다.

Community String의 역할

SNMPv1과 SNMPv2c에서는 별도의 사용자 계정 대신 community string을 이용해 접근을 제어한다.

예를 들어 다음과 같은 설정이 있다고 가정해 보자.

예시 설정의 community string은 monitoring_ro이고, 권한은 읽기 전용(RO)이다. NMS는 요청에 monitoring_ro를 포함하고, 장비는 문자열과 접근 권한을 확인해 응답 여부를 결정한다. 여기서 사용한 값은 역할을 설명하기 위한 예시이며 실제 운영용 비밀값이 아니다.

문제는 이 방식이 우리가 일반적으로 생각하는 로그인 인증과는 다르다는 것이다. 사용자별 인증도 없고, SNMPv1/v2c에서는 community string과 관리 데이터가 암호화되어 보호되지 않는다. Cisco 역시 SNMPv1/v2c의 community string을 공유 비밀번호와 비슷한 것으로 설명하며, 평문 전송과 사용자별 인증 부재를 주요 보안 한계로 지적한다. (Cisco SNMP Security)

그래서 문자열 하나가 유출되면 그 값을 알고 있는 사람이 누구인지를 장비 입장에서는 구분하기 어렵다.

취약해지는 조건

상황	위험
public, private 같은 알려진 문자열 사용	가장 먼저 추측되는 값이므로 매우 취약
회사명, 장비명 기반의 단순한 문자열	사전 추측 가능성이 높음
여러 장비에서 동일한 문자열 사용	유출된 값의 재사용과 접근 허용 범위에 따라 피해 확대
SNMP 접근 Source IP 제한 없음	장비의 SNMP 포트에 도달 가능한 시스템에서 요청 가능
SNMPv1/v2c 사용	인증정보와 관리 데이터에 암호화 보호가 없음
RW Community 사용	쓰기가 허용된 MIB 객체 변경 가능
관리망과 사용자망 미분리	내부 시스템 침해 후 SNMP 접근 가능성이 높아짐
NMS 설정·스크립트·백업 파일에 평문 저장	서버 침해를 통해 community string이 유출될 수 있음

특히 public, private가 위험하다는 이야기는 오래전부터 나온 내용이다. 그렇다고 요즘 장비가 무조건 이 값을 기본 설정한다는 의미는 아니다. 문제는 오래된 장비나 예전에 구축된 환경에서 이런 문자열이 그대로 남아 있거나, 운영 편의를 위해 비슷한 수준의 단순한 값을 사용하는 경우다. Cisco 역시 잘 알려진 문자열을 사용하지 말고, SNMPv1/v2c를 유지해야 한다면 ACL과 함께 사용하는 것을 권고하고 있다.

정보 유출 경로

인터넷에 UDP 161 포트가 직접 노출된 상황도 문제지만, 실제 사내 환경에서는 조금 다른 시나리오가 더 현실적이다.

예를 들어 공격자가 사용자 PC나 일반 서버 한 대를 먼저 장악했다고 가정해 보자.

SNMP 자체가 최초 침투 수단이 아닐 수도 있다. 오히려 이미 내부에 들어온 공격자가 네트워크를 이해하기 위한 정보 수집 수단으로 SNMP를 사용하는 상황을 생각해볼 필요가 있다.

RO의 정보 노출

운영자 입장에서는 이런 생각을 할 수 있다.

RW가 아니라 RO니까 괜찮지 않을까?

물론 RW에 비하면 위험은 낮다. 하지만 RO도 보안적으로 무시할 수준은 아니다.

정상적인 관리 환경에서 다음과 같이 SNMP 정보를 조회할 수 있다.

snmpwalk -v2c -c 'EXAMPLE_RO_ONLY' 192.0.2.10 1.3.6.1.2.1.1

자신이 관리하는 장비에서 조회 범위를 설명하기 위한 예시다. 192.0.2.10은 문서용 주소이고, EXAMPLE_RO_ONLY는 실제로 설정할 비밀값이 아니다.

이 명령의 조회 범위는 System MIB(1.3.6.1.2.1.1)다. 장비 이름과 설명, SNMP 관리 기능이 초기화된 이후의 경과 시간 등을 조회하며, 이 명령만으로 인터페이스·IP·MAC 정보까지 조회되는 것은 아니다. (RFC 3418)

Interfaces MIB나 IP 관련 MIB, 제조사 MIB 등까지 접근이 허용되어 있다면 인터페이스 이름·상태, 주소, 라우팅 및 인접 장비 정보도 노출될 수 있다. 실제 범위는 장비가 구현한 MIB와 SNMP View 설정에 따라 달라진다.

공격자 입장에서는 상당히 유용하다.

위 구성은 실제 SNMP 출력이 아니라, 여러 MIB 정보와 인터페이스 설명 등을 조합해 파악할 수 있는 가상의 예시다. 구성 정보가 유출되면 추가 조사의 단서가 될 수 있다. 무작정 IP 대역을 스캔하는 대신 어떤 장비가 코어 스위치인지, 어느 인터페이스가 다른 네트워크와 연결되어 있는지, 어떤 시스템을 먼저 조사해야 하는지를 판단할 단서를 얻을 수 있기 때문이다.

즉 RO SNMP의 주요 위험은 정보 유출과 정찰(Reconnaissance)이라고 볼 수 있다.

RW의 변경 위험

RW Community String은 위험도가 훨씬 높다.

SNMP에는 단순히 값을 읽는 GET뿐 아니라 값을 변경하는 SET 연산도 존재한다.

물론 RW community를 확보했다고 해서 곧바로 모든 장비 설정을 마음대로 바꿀 수 있다는 의미는 아니다. 실제로 변경할 수 있는 항목은 장비와 MIB 구현, 권한 설정에 따라 달라진다.

하지만 쓰기가 허용된 MIB 객체가 있다면 충분히 문제가 될 수 있다.

대표적인 예가 인터페이스 상태다. 표준 Interfaces MIB의 ifAdminStatus는 정의상 read-write 객체이며 인터페이스의 관리 상태를 나타낸다. 다만 실제 장비에서 쓰기를 지원할지는 구현에 따라 다르다. (RFC 2863)

즉 장비가 해당 쓰기 기능을 지원하면서 RW Community까지 노출되어 있다면 공격자가 SNMP SET을 통해 서비스에 직접 영향을 줄 가능성도 생긴다.

그래서 운영 환경에서는 특별한 이유가 없다면 RW Community 자체를 사용하지 않는 것이 좋다.

전송 중 노출

SNMPv1/v2c에서 놓치기 쉬운 또 하나의 문제는 전송 구간이다. 긴 문자열을 사용했다고 해서 안전한 것이 아니다.

예를 들어 긴 문자열에 여러 종류의 문자를 섞었더라도 전송 구간의 보호 여부는 별개의 문제다. 문자열을 길고 예측하기 어렵게 만들면 단순한 추측에 대한 저항성을 높일 수 있다.

하지만 SNMPv2c가 흐르는 네트워크 트래픽을 공격자가 관찰할 수 있다면 이야기가 달라진다. SNMPv1/v2c는 community string과 SNMP 관리 데이터를 암호화하여 보호하지 않기 때문에 네트워크 패킷에서 해당 정보를 확보할 수 있다.

따라서 복잡한 community string은 추측 공격에 대한 방어책일 뿐, 전송 중 노출 문제를 해결하지는 못한다.

다만 같은 VLAN에 있다는 이유만으로 다른 장비의 모든 패킷을 볼 수 있는 것은 아니다. NMS나 경유 장비의 침해 등으로 해당 통신을 관찰할 수 있는 위치를 확보했을 때 전송 중 노출 위험이 생긴다.

NMS의 인증정보

장비 설정만 확인해서 끝나는 문제도 아니다.

SNMP를 사용하는 환경에는 보통 NMS가 존재한다.

NMS에는 수십 대에서 수천 대 장비의 SNMP 인증정보가 저장될 수 있다. 운영 자동화를 위해 별도의 스크립트나 설정 파일에 community string이 들어가는 경우도 있다.

따라서 공격자는 반드시 네트워크 패킷에서 community string을 찾을 필요가 없다.

특히 같은 community string을 여러 장비에서 공통으로 사용하는 환경이라면 하나의 인증정보 유출이 같은 값을 사용하고 해당 NMS에서 접근 가능한 여러 장비로 확대될 수 있다.

SNMP를 점검할 때 장비 설정뿐 아니라 community string이 어디에 저장되어 있으며 누가 접근할 수 있는지까지 확인해야 하는 이유다.

SNMPv3 보안 수준

신규 구축이나 장비 교체가 가능한 환경이라면 가장 먼저 검토할 것은 SNMPv3이다. SNMPv3에는 다음 세 가지 보안 수준이 있다.

그중 보안 관점에서 권장할 수 있는 것은 인증과 암호화를 모두 사용하는 authPriv이다. SNMPv3의 USM(User-based Security Model)은 사용자 기반 인증과 Privacy 기능을 제공하며, RFC 3411에서도 authPriv를 인증과 Privacy를 모두 사용하는 가장 높은 보안 수준으로 정의한다. (RFC 3411)

장비와 NMS가 함께 지원한다면 SHA-2 기반 인증과 AES 기반 암호화를 우선 검토하는 것이 좋다. SNMPv3 USM용 HMAC-SHA-2는 RFC 7860에, AES-128 Privacy 방식은 RFC 3826에 정의되어 있다. 다만 실제 지원 알고리즘은 장비 제조사와 소프트웨어 버전에 따라 다르므로 적용 전에 반드시 확인해야 한다. (RFC 7860, RFC 3826)

SNMPv3로 전환해도 불필요한 RW 권한 제거, NMS 주소 제한, 필요한 MIB만 허용하는 View 설정과 NMS 자체의 보호는 여전히 필요하다. 전환 후 기존 v1/v2c community를 남겨 두면 그 경로의 위험도 그대로 남는다.

SNMPv2c 접근 제한

현실적으로 모든 장비를 SNMPv3로 바로 전환하기 어려운 환경도 많다. 오래된 네트워크 장비나 NMS 호환성 문제로 SNMPv2c를 계속 사용해야 할 수도 있다.

이 경우에는 community string 하나만 복잡하게 만드는 것으로 끝내서는 안 된다. 가장 중요한 것은 SNMP에 접근할 수 있는 시스템 자체를 제한하는 것이다.

예를 들어 NMS의 주소가 10.10.10.20이라면 장비의 UDP 161 접근을 이 NMS에서만 허용해야 한다.

Community string을 알고 있더라도 장비까지 SNMP 패킷을 보낼 수 없다면 공격 난이도가 크게 올라간다.

관리 VRF나 관리 VLAN을 사용하더라도 구간 사이에 라우팅이 허용되어 있으면 SNMP 접근이 가능할 수 있다. 망 분리와 함께 장비의 SNMP ACL 및 방화벽 정책으로 허용된 NMS만 접근하도록 제한해야 한다.

Cisco 역시 SNMPv1/v2c를 사용해야 하는 경우 community string 변경뿐 아니라 신뢰할 수 있는 관리 시스템으로 접근을 제한하고, 불필요한 RW 권한을 제거하며, 필요한 경우 SNMP View를 이용해 접근 가능한 MIB 범위를 제한하도록 권고하고 있다.

마치며

SNMP는 오래된 프로토콜이고 네트워크 운영 환경에서는 너무 익숙하다.

그래서 오히려 위험성을 잊기 쉽다.

특히 SNMPv2c의 community string을 단순한 모니터링 설정값 정도로 생각하면 안 된다. RO Community가 노출되면 네트워크 구조를 파악할 수 있는 정보가 공격자에게 제공될 수 있고, RW Community까지 노출된다면 장비가 허용하는 writable MIB에 대한 변경 가능성까지 고려해야 한다.

네트워크 환경을 점검한다면 우선순위는 비교적 단순하게 잡을 것 같다. SNMPv3 authPriv를 사용할 수 있으면 전환한다.

당장 전환할 수 없다면 RW를 제거하고, SNMP 접근을 NMS IP로 제한하고, 관리망을 분리한다. 예측하기 어려운 community string과 저장 위치의 접근 통제도 함께 적용한다. 접근 제한이 있더라도 알려진 기본값을 그대로 두어도 된다는 뜻은 아니다.

결국 중요한 것은 문자열 하나를 얼마나 복잡하게 만들었느냐가 아니라, 그 문자열이 노출되더라도 어디까지 접근할 수 있고 무엇을 할 수 있는지를 제한해 두었느냐라고 생각한다.