라우터 보안 정책

라우터는 종종 네트워크 가장자리에서 인터넷 접속이나 다른 사이트와의 연결에 사용됩니다. 인터넷은 위험한 곳이라 라우터는 여러 공격에 취약합니다.

이러한 공격을 완화하려면 이를 어떻게 다루고 라우터를 어떻게 보호할지 설명하는 (공식) 문서가 있어야 합니다. 이 문서를 라우터 보안 정책(router security policy) 이라고 합니다. 보안 정책을 사용하는 장점은 모든 라우터가 동일한 일관된 구성을 가질 수 있다는 점입니다.

라우터 보안 정책에 어떤 내용이 있을지는 조직과 라우터의 사용 목적에 따라 달라집니다. 자체 라우터 보안 정책을 만들고 싶다면 고려해야 할 몇 가지 사항을 알려드리겠습니다.

고려 사항

비밀번호 (Passwords)

구성에서 평문 비밀번호를 허용하나요, 아니면 암호화된 비밀번호만 허용하나요?
비밀번호는 얼마나 복잡해야 하나요?
비밀번호는 얼마나 자주 변경해야 하나요?

인증 (Authentication)

라우터에서 로컬 인증을 허용하나요, 아니면 원격 RADIUS나 TACACS+ 서버를 통해 인증해야 하나요?
원격 인증을 사용한다면, 모든 로그인 및 로그아웃 이벤트를 로그해야 하나요?
라우터에 로그인하려는 사용자에게 어떤 배너를 표시하나요?

원격 접속 (Remote Access)

원격 접속에 어떤 프로토콜을 허용하나요? Telnet?
CCP(Cisco Configuration Protocol) 같은 GUI를 허용하나요?

서비스 (Services)

라우터에서 실행 중이지만 필요하지 않은 서비스가 있나요? 비활성화해야 하나요? CDP, HTTP, IP redirect 같은 것들 말입니다.

필터링 (Filtering)

“외부” 인터페이스의 access-list는 어떻게 보여야 하나요? 사설 IP 주소를 차단하나요?
스푸핑을 방지하기 위해 uRPF 같은 다른 필터링 메커니즘을 사용하나요?

라우팅 프로토콜 (Routing Protocols)

라우팅 프로토콜에 인증을 사용하나요? 비밀번호를 변경하나요?

백업 (Backups)

running-configuration의 백업이 있나요?
이러한 백업을 라우터의 플래시 메모리에 저장하나요, (TFTP) 서버에 저장하나요?
오프사이트 위치에 백업을 저장하나요?
구성의 리비전을 가지고 있나요?

이중화 (Redundancy)

라우터가 실패할 경우 백업 계획이 있나요?
HSRP, VRRP, GLBP 같은 이중화 프로토콜을 사용하나요?
교체 하드웨어가 있나요?

문서화 (Documentation)

문서가 최신 상태로 유지되도록 보장하는 절차가 있나요?

물리적 보안 (Physical)

누가 라우터에 물리적으로 접근할 수 있나요?
콘솔 포트에 대한 접근을 방지하기 위해 무엇이 구현되었나요?

모니터링 (Monitoring)

SNMP 같은 모니터링 프로토콜을 사용하나요?
무엇을 모니터링하나요? CPU 부하? 메모리 사용량? 인터페이스 통계?
SNMP 커뮤니티에 access-list를 사용하나요?

트래픽 가시성 — NetFlow / IPFIX / Syslog / SIEM

“탐지 없는 보안은 반쪽짜리”라는 말처럼, 보안 정책은 사건이 발생했을 때 증거를 남기고 탐지할 수 있어야 완성됩니다. 라우터·스위치에서 수집할 수 있는 대표적인 가시성 데이터와 도구:

NetFlow / IPFIX

트래픽 “대화 기록”을 내보내는 기능. 각 flow(5-tuple)마다 바이트/패킷/지속시간/TCP 플래그 등 메타데이터를 집계해 collector로 전송.


R1(config)# flow record RECORD_V4
R1(config-flow-record)# match ipv4 source address
R1(config-flow-record)# match ipv4 destination address
R1(config-flow-record)# match transport source-port
R1(config-flow-record)# match transport destination-port
R1(config-flow-record)# match ipv4 protocol
R1(config-flow-record)# collect counter bytes
R1(config-flow-record)# collect counter packets

R1(config)# flow exporter EXPORT_TO_COLLECTOR
R1(config-flow-exporter)# destination 10.0.0.100
R1(config-flow-exporter)# transport udp 9996

R1(config)# flow monitor MONITOR_V4
R1(config-flow-monitor)# exporter EXPORT_TO_COLLECTOR
R1(config-flow-monitor)# record RECORD_V4

R1(config)# interface gigabitEthernet 0/0
R1(config-if)# ip flow monitor MONITOR_V4 input
R1(config-if)# ip flow monitor MONITOR_V4 output

NetFlow v5: 고정 필드, IPv4만, 레거시
NetFlow v9: 템플릿 기반, IPv6·MPLS·BGP 필드 확장
IPFIX (v10): IETF 표준화된 NetFlow v9, 벤더 독립적

활용: 이상 트래픽 탐지, DDoS 조기 감지, 성능 트러블슈팅, 포렌식 등. Cisco Stealthwatch(현 Secure Network Analytics), Plixer Scrutinizer, ElastiFlow가 대표 collector.

Syslog 구조화

단순히 logging host X 수준을 넘어 심각도별 목적지 분리 + 구조화 파싱이 운영 기본:


R1(config)# logging host 10.0.0.101 transport tcp port 6514
R1(config)# logging trap informational
R1(config)# logging source-interface loopback 0
R1(config)# logging facility local6
R1(config)# logging origin-id hostname
R1(config)# service timestamps log datetime msec localtime show-timezone

로그 레벨 6(informational) 이상 권장 — 그보다 낮으면 브루트포스·ACL 위반·인증 실패 같은 보안 이벤트를 놓칩니다. TLS(6514)로 암호화해 무결성·기밀성 확보.

SIEM 통합

Splunk, Elastic SIEM, IBM QRadar 같은 플랫폼이 Syslog + NetFlow + EDR + 클라우드 로그를 통합. 상관 분석(correlation) 룰로 단일 로그로는 드러나지 않는 공격 패턴을 탐지:

SSH 실패 + 같은 IP의 ACL deny 급증 → 브루트포스 가능성
평소 없던 외부 IP로의 대량 flow → 데이터 유출 조짐
OSPF 인접성 플랩 + syslog 인증 실패 → 라우팅 탈취 시도

무엇을 반드시 로그할 것인가

인증 이벤트: login, login on-failure, aaa accounting exec/commands
설정 변경: archive log config, config change notification
ACL 위반: permit/deny ... log
인터페이스 up/down
라우팅 프로토콜 인접성 변화
CPU/메모리 임계치 초과

로그 보관 정책

최소 90일, 권장 1년+: 침해 사고 발견이 평균 6개월 걸리는 산업 통계 감안
변조 방지: Syslog 서버는 전용 VLAN/방화벽 뒤, append-only 스토리지
법적 요구: 업종(금융, 의료)에 따라 최소 보관 기간 명시되어 있음 — 준수

IDS/IPS·NGFW 로그와의 연계

라우터 Syslog만으론 공격 자체는 보이지 않습니다(라우터는 내용을 안 봄). 페이로드 공격은 IPS·NGFW에서, 엔드포인트 공격은 EDR에서, 정체성 이벤트는 ISE에서 각각 나오며 SIEM에서 합쳐져야 큰 그림이 잡힙니다.

업데이트 (Updates)

새 IOS 버전을 확인하나요?

취약점 스캔 및 침투 테스트 (Vulnerability Scans)

라우터의 설정을 모두 마친 뒤에도 외부 관점에서 실제로 안전한지는 별도로 검증해야 합니다.
내부적으로 Nipper, Nessus 같은 도구로 설정을 감사하거나 대표적인 공격 벡터를 스캔해 볼 수 있습니다.
중요한 경계 라우터라면 주기적으로 외부 침투 테스트(pentest) 를 의뢰해 설정상의 사각지대나 알려지지 않은 취약점을 점검하는 것이 권장됩니다.

이 목록이 라우터 보안 정책에서 다뤄야 할 사항에 대한 아이디어를 드리길 바랍니다. 이 문서는 “모든 라우터에 이대로 붙여넣으면 끝나는 체크리스트”가 아니라, 조직 상황(사용 중인 프로토콜, 감사 요구, 관리 체계 등)에 맞게 다듬어 사용하는 출발점 으로 생각하면 됩니다.

출처: networklessons.com - Router Security Policy

태그: Network Management