보안


	② 네트워크 모니터링		06.10.02 14:09

‘네트워크 보안’과 관련하여 관리자가 접근하여야 할 화두는 크게 두 가지로 요약할 수 있는데, 첫 번째는 네트워크 자체의 취약성 및 이를 악용한 공격에 대한 이해이다.

우리가 일상적으로 사용하는 인터넷 자체가 TCP/IP라고 할 수 있을 만큼 인터넷의 표준 프로토콜인 TCP/IP는 시스템이나 네트워크 분야에서 너무나 익숙하게 사용하고 있다. 하지만 그 내부를 조금만 들여다보면 TCP/IP는 자체적으로 많은 취약성을 가지고 있다는 것을 알 수 있는데, 이러한 취약성은 아무리 시스템을 패치하고 보안 설정을 한다고 하더라도 네트워크 자체의 취약성은 여전히 유효하므로 근본적인 대응에는 한계가 있다.

따라서 이를 악용한 공격 역시 끊이지 않고 있다. 더군다나 이러한 공격은 특별한 로그도 남지 않고 마땅한 모니터링 방법도 없어 인지하기가 쉽지 않아 관리자에게 여간 부담되는 것이 아닐 수 없다.

네트워크 취약성과 트래픽 모니터링
다음으로 네트워크 보안의 두 번째 화두는 비정상적인 네트워크 트래픽에 대한 모니터링 방안이다. 지금까지는 흔히 네트워크 모니터링이라면 mrtg 프로그램으로 전체 트래픽(bps) 정도를 모니터링한 것이 전부일 것이다.

물론 한 대나 소수의 서버만을 운영한다면 관계없겠지만 여러 대의 서버를 운영한다면, 더군다나 그 규모가 조금씩 커진다면 만약 내부나 외부에서 비정상적인 트래픽이 유발되었을 때 문제를 인지하고 대처하기까지 많은 노력과 시간이 필요하게 된다.

이러한 경우 이 비정상 트래픽의 정체(프로토콜, 포트번호 등)가 무엇이고 트래픽의 소스가 어디인지 어떻게 찾을 것인가? 그리고 프로토콜이나 포트별 트래픽 등과 같은 정보에 대한 상시적인 네트워크 모니터링은 어떻게 할 것인가? 아마도 mrtg만으로는 이 물음에 답할 수 없을 것이다.

따라서 이번 글에서는 네트워크의 취약성을 이용한 공격 중 가장 치명적이면서도 지금까지도 자주 악용되는, 그래서 필자 역시 이로 인하여 고생한 적이 있는 스니핑을 중심으로 이 공격의 원리와 대처 방법에 대해 알아보고, 다음으로 효율적인 네트워크 트래픽 모니터링 도구인 넷플로우(netflow)를 활용하여 비정상적인 트래픽을 감지할 수 있는 방안에 대해 알아보도록 하겠다.

스니핑 공격
가끔 서버를 운영하다 보면 시스템의 모든 취약성을 패치하여 안정한 상태이고, 암호를 어렵게 설정하였는데도 불구하고 누군가 시스템에 침입한 흔적을 발견할 경우가 있다. 아마도 한두 번씩은 이러한 경험을 해보았을 텐데, 어떻게 들어왔을까 의구심이 드는 경우가 있다.

이럴 때 가장 먼저 의심해 보아야 할 것 중 하나는 바로 스니핑(Sniffing)을 통해 아이디/암호가 유출된 것은 아닌지 확인해야 한다. 이제는 네트워크에 연결된 이상 자신의 시스템 하나만 보안을 강화하는 것만으로는 완벽한 보안 시스템/네트워크를 구축할 수 없으며 주위의 시스템도 고려하여야 한다.

왜냐하면 주위의 다른 시스템을 해킹한 후 공격자가 스니핑을 실행한다면 통신하는 트래픽을 캡처하여 시스템 내부에 침입하지 않고도 같은 네트워크에 있는 다른 시스템의 아이디/암호 등의 유용한 정보를 손쉽게 획득할 수 있기 때문이다.

스니핑이란 무엇일까?
‘스니핑’이라는 용어 자체는 자주 들어보았겠지만 간단히 정의하자면 네트워크를 통과하는 패킷을 도청하여 아이디/패스워드나 입력한 명령어 등 각종 정보를 비정상적인 방법으로 엿보는 행위, 즉 전기적 도청을 의미한다. 현실 세계에서도 마음만 먹는다면 여러 방법을 이용하여 전화나 휴대폰의 통화 내용을 도청할 수 있는 것처럼 네트워크에서도 역시 간단한 원리와 관련 툴 사용법만 알면 어렵지 않게 네트워크 트래픽을 도청할 수 있는 것이 사실이다.

이 때문에 대부분의 공격자들은 시스템의 관리자 권한을 획득한 후 시스템에 스니핑 프로그램을 설치, 실행하여 해당 로컬 서버는 물론이고 같은 네트워크를 사용하는 다른 서버에 접근하는 아이디나 패스워드 정보를 얻으려고 한다.

아무리 스위칭 환경이라 하더라도 대량의 시스템이 모여 있는 환경에서는 한 서버만 해킹 후 스니핑 프로그램을 실행해도 주위에 있는 많은 시스템 접근 정보를 파악할 수 있게 된다. 따라서 시스템의 취약성을 모두 패치했다고 하더라도 다른 시스템에서 스니핑을 실행하여 아이디/암호 등 접속 정보가 보여지게 된다면 쉽게 침입할 수 있는 여지를 주게 되는 것이다.

이처럼 스니핑은 공격자 입장에서 매우 간단하면서 큰 수확을 얻을 수 있지만 반면 서버나 네트워크 관리자 입장에서는 매우 치명적이고 조치하기가 어려운 형태의 공격이라 할 수 있다.

네트워크에서의 스니핑은 크게 두 가지 이유로 가능한데, 이것이 바로 스니핑의 원리가 될 수 있다. 첫 번째로, 단순한 구조에서 주로 사용하는 더미(dummy) 허브와 같이 모든 패킷을 모든 포트에 전달(broadcast)함으로써 직접적인 통신과 관계없는 다른 포트에 연결되어 있는 PC나 서버에서도 다른 시스템의 패킷을 캡처할 수 있게 된다.

두 번째는 인터넷의 표준 프로토콜인 TCP/IP의 전송 방식은 기본적으로 암호화하지 않은 평문(plain text)을 사용한다는 것이다. 그러나 TCP/IP가 평문 방식으로 전송된다고 해서 바로 모든 패킷을 스니핑할 수 있는 것은 아니다. 왜냐하면 기본적으로 패킷의 목적지가 자신의 MAC 주소가 아닌 패킷은 이더넷 카드에서 드롭(drop)하는 특성이 있기 때문이다.

따라서 어떤 시스템에서 스니핑을 하려면 시스템의 인터페이스에서 패킷의 목적지 MAC이 자기 자신이 아닌 패킷도 받아들여야 하는데, 이를 위해서는 인터페이스가 promiscuous(또는 promisc) 모드로 작동하도록 설정하여야 한다.

promisc 모드를 우리말로 번역하면 ‘무차별 모드’라고도 하는데, promisc 모드로 설정되면 자기 자신을 목적지로 하지 않은 패킷도 이더넷 카드에서 패킷을 드롭하지 않고 무차별적으로 모든 패킷을 다 받아들여 스니핑 프로그램까지 전달되고 스니핑이 가능하게 된다.

리눅스에서 인터페이스가 promisc 모드인지의 여부를 알기 위해서는 다음과 같이 인터페이스의 상태를 확인할 수 있는 ifconfig 명령어를 입력하면 된다. 이때 <화면 1>과 같이 PROMISC라는 문자열이 보이면 인터페이스는 promisc 모드로 되어 있는 것인데, 참고로 promisc 모드를 수동으로 설정하려면 ‘# ifconfig eth0 promisc’와 같이 실행하고, 해제하려면 ‘# ifconfig eth0 -promisc’로 실행하면 된다.

<화면 1> PROMISC가 설정된 예

특별한 이유가 없다면 일반적으로 promisc 모드로 설정되어 있을 필요가 없으므로 만약 자신의 시스템이 promisc 모드로 설정되어 있다면 스니핑이 작동하고 있는지 여부를 살펴보아야 할 것이다.

스니핑에 대한 대책
그렇다면 스니핑에 대한 대책은 무엇인가? 3가지 정도의 방법을 대안으로 제시할 수 있겠다. 첫 번째는 접근제어를 엄격하게 하는 것이다. 이를테면 평문으로 전송되는 FTP 프로토콜을 이용하다가 스니핑에 아이디/암호가 유출되었다 하더라도 방화벽이나 FTP 데몬에서 접근 가능한 IP 주소가 제한되었을 경우 아이디/암호를 알아도 접속할 수 없게 된다. 물론 IP 주소를 위조하여 접속을 시도할 수도 있겠지만 IP를 위조하여 TCP 접속을 하는 것은 사실상 매우 어렵다.

또한 당연한 이야기겠지만 주위의 다른 시스템 보안을 강화하는 것 역시 중요하다. 스니핑은 Root 가 아닌 일반 사용자 권한으로는 실행할 수 없고, 오직 root 또는 관리자 권한으로만 실행할 수 있으므로 누군가가 스니핑을 실행하였다면 이미 root 권한을 빼앗긴 것이라 할 수 있다. 물론 동일 네트워크에 여러 관리자가 있을 경우에는 자신의 서버만 보안을 신경쓴다고 해결될 수는 없는 한계가 있을 것이다.

두 번째는, 기본적으로 모든 포트에 패킷을 포워딩(broadcasting)하는 더미 허브 대신 해당하는 목적지 포트에만 패킷을 전송하는 스위치(switch)를 사용하고, 스위치 환경에서도 가능한 스니핑 기법에 대응하기 위해 스위치의 보안 기능을 이용하는 것이다.

필자가 생각하기에 가장 확실한 대안이라 할 수 있는 세 번째 방법은, 평문으로 전송되는 TCP/IP 대신 암호화 전송 프로토콜을 사용하는 것이다. 이의 대표적인 경우가 텔넷 대신 SSH를, http 대신 https 등을 사용하는 것이 그 예이다. 물론 최근 들어 많이 사용되고 있는 VPN을 사용하면 일일이 각각의 응용 프로그램을 암호화할 필요 없이 VPN 터널을 구성한 구간에서는 모든 프로토콜이 암호화되므로 더 없이 좋은 솔루션이 될 것이다.

여기에서 스니핑에 대한 대책으로 첫 번째의 접근 통제는 각 시스템 레벨에서 구현할 수 있으므로 두 번째와 세 번째 방법에 대해 좀 더 알아보도록 하자.

스위치에서의 스니핑 차단 방법
스위치를 사용할 경우 통신하고자 하는 목적지의 MAC 정보를 알기 위해 arp 요청시에만 모든 포트에 브로드캐스트하고 이후에는 모두 유니캐스트(unicast)로 직접 1:1 통신을 하므로 상대적으로 스니핑에 안전하다고 생각한다. 하지만 과연 스위치를 사용한다면 스니핑에 안전할까? 답은 “이론적으로는 그런 것 같지만 실제로는 결코 그렇지 않다”이다.

왜냐하면 쉽지는 않지만 ‘mac flooding’이나 ‘arp spoofing’, ‘mac duplicating’ 등과 같이 arp 프로토콜의 취약성을 이용하면 스위치 환경에서도 스니핑을 할 수 있는 방법이 있고, 또한 이런 공격을 가능하게 하는 프로그램도 공개되어 있기 때문이다. 그렇다면 스위치 또는 더미 허브 환경에서 스니핑을 차단하기 위해 어떻게 보안 설정을 할 수 있을까? 다음의 몇 가지 방법을 대안으로 제시할 수 있다.

VLAN을 이용하는 방법
스니핑은 동일한 VLAN 내의 트래픽에 대해서만 가능하므로 VLAN을 나누어 관리하는 것이 좋다. 만약 1개의 VLAN으로 통 네트워크를 구성한다면 그만큼 스니핑이 될 수 있는 범위가 넓어질 것이다. 따라서 운영되는 서비스의 특성에 따라 또는 IP 범위에 따라 적절히 VLAN을 나누어 관리하는 것이 보안적인 측면뿐만 아니라 성능(performance)의 관점에서도 권장되는 방법이다.

Port security를 이용하는 방법
만약 스위치에서 Port security 기능을 지원할 경우 MAC Flood나 MAC 스푸핑을 예방하거나 피해를 최소화할 수 있는 방법으로, 각각의 포트에 물리적인 MAC 주소를 정적(static)으로 설정하는 것이다. port security는 대부분의 스위치에서 제공하는 기능으로, 스위치의 각 포트별로 MAC 주소를 static하게 설정하여, 설정된 MAC 주소만 해당 포트를 통해 통신을 허용하거나 반대로 필터링하고자 할 때 사용할 수 있다.

이 기능을 이용할 경우 스위치 환경에서 arp를 위조하여 스니핑하거나 네트워크를 다운시키는 서비스 거부(DoS)와 같은 형태의 공격을 차단하는 데 효과적이다. port security를 이용하면 다음과 같은 기능을 구현할 수 있다.

▲ 스위치의 각 포트별로 허용된 MAC 주소를 지정할 수 있다.
▲ 특정한 MAC 주소를 가진 트래픽을 스위치에서 차단할 수 있다.
▲ 각 포트별로 허용 가능한 MAC 수를 지정하여 이 수치를 초과할 경우 초과된 MAC 주소는 더 이상 통신이 되지 않도록 차단 설정하거나 해당 포트를 아예 일정 시간 동안 또는 영원히 shutdown하도록 설정할 수 있다.

시스코 계열의 CatOS 스위치에서의 설정 방법에 대해 간단히 알아보자.

[1] CatOS> (enable) set port security 3/1 enable
기본적으로 port security 기능은 disable되어 있는데, 이 명령어는 3/1 포트에 port security 설정을 enable하는 것을 보여준다.
[2] CatOS> (enable) set port security 3/1 enable 01-02-03-04-05-06
이는 3/1 포트에 특정 MAC을 수작업으로 지정해 주는 명령어이다. 이와 같이 설정하면 3/1 포트에는 앞의 MAC 외에 다른 MAC 주소는 통신할 수 없게 된다. 이때 여기에서 지정한 MAC 주소를 secure mac 주소라 한다.
[3] CatOS> (enable) set port security 3/2 enable maximum 5 violation shutdown 60
이는 3/2 포트에 대해 최대 5개까지의 MAC 주소만이 사용될 수 있도록 하고, 만약 보안 설정을 위배(violation)하여 MAC 주소가 초과되는 경우 해당 포트 전체는 60분 동안 다운(shutdown)되도록 한다. 만약 포트에 연결되어 있는 하위 스위치에 최대 5대의 서버만 설치된다면 최대 5개의 MAC만 인식하면 될 것이다. 그리고 별도로 시간을 지정하지 않을 경우에는 port security를 해제하기 전까지 영원히 다운되도록 하는 것이며, port security 정책을 위배하면 다음과 같은 로그가 발생한다.

2004 May 03 15:40:32 %SECURITY-1-PORTSHUTDOWN:
Port 3/2 shutdown due to no space

또한 포트 내 모든 통신이 다운되는 shutdown 대신 다음과 같이 restrictive를 설정하였을 경우에는 스위치의 해당 포트에서 인식된 5개까지의 MAC은 secure mac으로 통신이 가능하지만 5개를 초과한 이후의 MAC은 통신이 되지 않게 된다

CatOS> (enable)set port security 3/2 enable maximum 5 violation restrict
Port security violation on port 3/2 will cause insecure packets to be dropped.
CatOS> (enable)

지금까지 살펴본 port security에 대한 더 자세한 내용은 http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5_4/
config/sec_port.htm 에서 찾아보기 바란다.

암호화 전송 프로토콜 사용방법
앞에서 언급한 대로 암호화 프로토콜을 사용하는 것은 스니핑에 가장 확실한 대안이 될 수 있을 것이다. 그래서 최근에는 telnet 대신 ssh를, http 대신 https를 사용하고 있다.

그렇다면 ftp나 smtp, pop3 등 다른 서비스들은 어떻게 암호화할 것인가? 만약 telnet만 사용한다면 단순히 텔넷를 사용하기만 하면 되겠지만 한 서버에서 하나의 공통된 계정으로 텔넷과 ftp, POP3 등을 함께 사용한다면 어느 하나의 서비스만 암호화하는 것은 그리 큰 의미가 없을 것이다.

어차피 스니핑 문제는 telnet에 한정된 것이 아닌 TCP/IP 자체가 평문으로 전송되어 취약한 것이므로 암호화 전송 프로토콜을 사용하려면 아이디/암호가 유출될 수 있는 모든 서비스에 대해 암호화 전송 프로토콜을 사용해야 하기 때문이다.

그래서 이를 위해 몇 가지 방법을 대안으로 제시할 수 있는데, ssh나 https처럼 전용 암호화 프로토콜로 대체를 하거나 기존의 TCP/IP 기반의 서비스를 그대로 유지하면서 stunnel과 같은 별도의 암호화 모듈 프로그램을 활용하여 각 응용 프로그램별로 암호화하는 방법이 있고, 또한 VPN과 같이 암호화된 별도의 전용터널을 구성하여 사용하는 방법이 있을 것이다.

먼저 stunnel은 POP3나 Telnet, FTP, imap, smtp 등의 TCP 서비스를 보안 모듈로 감싸 SSL이 지원되지 않는 모든 TCP 데이터 전송을 SSL 암호화하는 간단한 서비스로서, 기존의 서비스를 다시 설치할 필요 없이 스탠드얼론 형태로 또는 xinetd(또는 inetd)나 tcpserver와 함께 사용할 수 있다. stunnel은 http://www.stunnel.org/에서 다운로드하거나 또는 http://rpmfind.net/에서 stunnel로 검색하여 rpm을 다운로드해도 된다.

<화면 2> stunnel 홈페이지

이렇듯 stunnel은 필요한 각 응용 프로그램별로 간단히 암호화할 수 있다는 장점이 있지만 TCP만 지원하여 UDP나 ICMP에 대한 암호화는 지원하지 않는다는 단점이 있다. 또한 stunnel을 이용하여 서버 측에 암호화가 지원되는 데몬을 설치하였다면 클라이언트도 암호화를 지원하는 프로그램을 이용하여야 하는데, 만약 암호화를 지원하지 않는 프로그램이라면 암호화를 사용할 수 없다는 치명적인 한계가 있다.

이를테면 stunnel을 이용하여 FTP 서버를 암호화 설정하였다 하더라도 알FTP와 같이 암호화를 지원하지 않는 클라이언트 프로그램을 사용한다면 이 기능을 사용할 수 없는 것이다. 이렇듯 호환성의 한계를 극복하기 위해서는 VPN이 그 대안이 될 수 있다.

VPN을 이용하여 특정 네트워크와 특정 네트워크 구간, 서버와 서버 구간 또는 네트워크와 서버 구간에 마치 사설 네트워크와 같이 가상의 암호화된 터널을 구성하면 그 구간 내부에서는 모든 트래픽이 암호화되므로 일일이 암호화된 프로토콜을 사용할 필요도 없고 따라서 호환성의 문제도 걱정할 필요가 없게 된다. 물론 이를 위해 상용 VPN 솔루션을 이용한다면 막대한 비용이 부담될 수 있지만 상용 수준의 성능이나 기능을 제공하면서도 오픈소스로 개발 중인 솔루션도 많이 나와 있다.

많은 공개 VPN 프로젝트가 있는데, 이전에는 공개 VPN이라면 누구나 freeswan(http://www.freeswan.org/)을 이야기하곤 하였지만 설치 및 설정이 매우 복잡하고 호환성에 문제가 있으며 더군다나 현재는 개발이 중단된 상태이다. 반면에 새롭게 등장한 OpenVPN 프로젝트(http://openvpn.sourceforge.net/)는 여러 면에서 장점을 가지고 있어 활발하게 개발 및 이용되고 있다.

OpenVPN을 이용하면 하나의 UDP 또는 TCP 포트를 통해 IP 서브넷이나 가상의 이더넷을 터널링할 수 있으며 Openssl이 지원하는 많은 암호화, 인증 기능을 이용할 수 있다. OpenVPN은 인증이 취약하거나 NAT에서 구현이 어렵고 복잡한 PPTP나 L2TP/IPSec에 비해 데몬 형태로 작동하기 때문에 복잡한 커널 패치나 커널 모듈이 필요하지 않으며 설치 방법이 매우 쉽고 리눅스뿐만 아니라 솔라리스, FreeBSD, 맥OS X, 윈도우 2000/XP 등 여러 OS 에서 이용할 수 있는데, 이용에 대한 자세한 안내는 http://openvpn.sourceforge.net를 참고하기 바란다.

네트워크 모니터링 방안
굳이 MS SQL 웜으로 인한 1.25 대란을 예로 들지 않더라도 필자가 경험한 바에 의하면 해킹을 당한 어떤 시스템의 경우 한 대의 시스템에서 초당 100Mbps에 가까운 트래픽을 유발하거나 초당 1만개 이상의 패킷을 유발하며 다른 시스템을 서비스 거부 공격한 경우가 있었다.

이러한 경우 단순히 해당 서버의 정상적인 서비스가 불가능한 것은 물론 같은 네트워크를 사용하는 다른 시스템에도 패킷 로스나 접속 불능 등 심각한 영향을 미치게 될 것이다. 특히 초당 1만개 정도의 패킷이 유발될 때는 해당 트래픽을 처리하는 중간 스위치나 라우터와 같은 네트워크 장비가 간헐적으로 다운되는 현상도 발생할 것이다.

만약 여러분의 네트워크에 이러한 현상이 발생한다면 어떻게 대응할 것인가? 아마 대부분의 관리자가 제일 먼저 할 수 있는 조처는 mrtg 그래프를 살펴보든가 그것도 아니면 스위치에 물려 있는 LAN 케이블을 하나씩 뽑아 보아 문제가 있는 서버를 찾으려 할 것이다.

그러나 mrtg가 제대로 설치되어 있지 않거나 일부 서버나 장비에 mrtg가 누락되어 있다면, 그리고 서버가 매우 많다면 어떻게 할 것인가? 아마도 별도의 네트워크 모니터링 시스템이 구축되어 있지 않은 경우라면 대부분 이 질문에 시원한 답을 하지 못할 것이다. 이처럼 네트워크 트래픽 모니터링은 네트워크는 물론이고 시스템의 문제를 인지하고 문제의 원인을 발견하여 신속한 대처를 하기 위해서 반드시 필요한 절차라 할 수 있을 것이다.

네트워크 모니터링의 개요
이 글을 읽는 독자 중 여러 시스템이나 네트워크 관리자라면, 설사 그렇지 않더라도 그 역할을 하고 있다면 다음의 질문에 답해 보기 바란다.

[1] 대부분 전체 트래픽은 라우터나 스위치에 mrtg를 걸어 쉽게 알 수 있을 것이다. 그렇다면 가장 많은 트래픽을 유발하는 IP를 소트(sort)하여 실시간으로 모니터링이 가능한가?
[2] 여러분의 네트워크가 유발하는 정상적인 트래픽 중 TCP는 어느 정도인지, UDP나 ICMP 트래픽은 어느 정도인지 알고 있는가?
[3] TCP의 경우 웹 트래픽은 어느 정도이고, SMTP, https, POP3 등의 트래픽은 얼마인가?
[4] bps뿐만 아니라 전체 트래픽의 pps(초당 패킷 수), fps(초당 flow 수)는 얼마인가?

사실상 이러한 질문은 관리자라면 많이 궁금해 하는 내용이지만 mrtg에 의존하여 모니터링을 하고 있는 대부분의 관리자에게는 답하기 곤란한 것이 사실이다. 여기에서는 이러한 질문에 답할 수 있는 방법을 찾아보도록 할 것이다.

netflow와 flowscan 활용
자신이 관리하는 네트워크의 전체 트래픽에 대하여 이와 같이 상세한 모니터링을 하려면 규모에 관계없이 모든 트래픽이 통과하는 백본 스위치나 라우터에서 직접 모니터링하거나 그렇지 않더라도 백본 구간에서 모니터링하여야 할 것이다. 그러나 이러한 모니터링을 제공하는 솔루션들은 대부분 대량의 트래픽을 빠르게 처리하여야 하므로 매우 고가이고 만약의 사소한 장비 오류시에도 치명적인 서비스 장애가 될 수 있어 실제로 도입하여 사용하는 것이 쉽지는 않다.

그러나 별도의 장비나 솔루션을 사용하지 않고도 기존의 스위치나 라우터가 제공하는 기능 중 netflow라는 모니터링 기능을 이용하면 네트워크 장비에 영향을 주지 않고 안전하면서도 상용 수준의 네트워크 트래픽 모니터링 기능을 이용할 수 있다. 이는 장비에 넷플로우 기능을 설정하면 성능에 크게 영향을 주지 않으면서도 장비를 통과하는 모든 트래픽에 대해 유용한 결과(패킷의 소스 IP, 목적지 IP, 포트, 프로토콜 등 7가지 정보)를 제공하기 때문이다.

그러나 넷플로우 자체는 이러한 정보만 제공할 뿐 넷플로우를 설정했다고 해서 mrtg와 같이 바로 웹 인터페이스로 트래픽을 모니터링할 수 있는 것은 아니다. 이를 위해서는 라우터나 스위치에서 넷플로우 정보를 실시간으로 원격지 호스트에 보내고, 호스트에서는 이 데이터를 받아 가공하여 그래프로 보여주어야 하는데, 이처럼 넷플로우의 데이터를 모아 웹이나 응용 프로그램을 통해 모니터링할 수 있는 프로그램으로는 플로우스캔(Flowscan)이라는 프로그램이 가장 대표적이다.

플로우스캔을 이용하면 <화면 3>과 같이 라우터에서 모아진 넷플로우의 결과 데이터를 리눅스 등 유닉스 호스트에 설치된 플로우컬렉터(flowcollector)로 전송하고, 플로우컬렉터는 이 데이터를 가공하여 플로우스캔과 같은 GUI 또는 CLI 환경의 인터페이스로 모니터링할 수 있도록 제공한다. 쉽게 생각하면 넷플로우의 다양한 결과를 mrtg와 같은 그래프로 본다고 생각하면 된다.

<화면 3> Flowscan의 개념도

플로우스캔은 라우터에서 보내는 UDP flow data를 분석하여 필요로 하는 유용한 정보를 모니터링할 수 있도록 제공하는 툴로서 크게 세 가지의 프로그램으로 구성되어 있다. 먼저 flow 정보를 수집할 때 사용하는 cflowd나 flow-tools가 있는데, 이는 UDP 데이터그램인 flow 패킷을 수신하여 공유 메모리 버퍼에 쓰고, 공유 메모리에 씌어 패킷을 읽어서 로컬 테이블에 저장하는 역할을 한다.

그리고 두 번째로 RRD(Round Robin Database)가 있는데, 이는 cflowd나 flow-tools에서 기록된 flow dump 파일을 분석하여 데이터베이스로 기록하는 역할을 한다. 그리고 마지막으로 데이터베이스의 정보를 이용해 시간대별로 적절한 그래프를 그리기 위해 이용되는 RRDtool이 있는데, RRDtool은 여러 개의 RRD 파일을 사용해 flow의 통계 정보를 저장하는 역할을 하며 RRDtool과 RRGrapher는 gif나 png 형식의 포맷으로 그래프를 작성한다.

보안 관리자의 보안 이슈 : 봇과 봇넷

올 하반기의 보안 이슈라면 단연 봇(bot)과 봇넷(botnet)의 창궐이라 할 수 있다. 봇은 웜 바이러스와 같이 주로 윈도우의 시스템 취약성을 이용하여 무작위로 스캔 및 공격을 하여 백도어를 생성하지만 일단 봇에 감염되면 공격자가 만들어 놓은 사설 irc 채널에 자동 결합하여 공격자의 명령을 기다리게 된다.

이렇게 irc 채널 소유자인 공격자 서버에 연결된 호스트를 봇이라 하고, 각각의 봇을 연결해 주는 irc 채널을 봇넷이라 하는데, 이러한 봇넷을 통해 DDOS 공격이나 대량의 스팸 메일 발송 등 공격자가 원하는 대로 여러 가지로 악용될 수 있는 여지가 있다.

따라서 여기에서 설명하는 플로우스캔 등을 활용하여 각종 스캔이나 6667/TCP 등과 같은 irc 트래픽을 모니터링하면 각종 봇이나 봇넷 트래픽을 사전에 감지하여 차단하거나 대처할 수도 있을 것이다. 그리고 라우터나 스위치 등을 통과하는 모든 패킷에 대한 헤더 정보를 저장하게 되므로 각종 보안사고 발생 후 사후분석(포렌식)에도 유용하게 활용될 수 있을 것이다.

라우터나 스위치에 netflow을 설정하고 Flowscan을 설치하는 방법은 http://net.doit.wisc.edu/~plonka/FlowScan/ 을 참고하기 바란다.
앞의 사이트에서 소개한 대로 플로우스캔을 설정하여 넷플로우 데이터를 가공하면 <화면 4>와 같은 그래프가 생성되는데, 각각 시간대별로 프로토콜별 bps, fps, pps를 보여주고 있음을 알 수 있다.

<화면 4> 프로토콜별 bps

<화면 4>의 그림은 TCP, UDP, ICMP 등 프로토콜별로 bps가 어떻게 변화하는지 보여주는데 대부분이 TCP임을 알 수 있다. 만약 짧은 시간에 bps가 증가한다면 와레즈나 서비스 거부 공격일 가능성이 높다.

<화면 5> 프로토콜별 fps

<화면 5>의 그림은 프로토콜별로 fps가 어떻게 변화하는지 보여주는데, fps는 초당 전송되는 flow의 수를 뜻한다. 만약 fps가 갑자기 증가한다면 해당 트래픽에 대한 포트 스캔이나 IP 스캔이 발생하게 된다.

<화면 6> 프로토콜별 pps

<화면 6>의 그림은 프로토콜별로 pps(packets per second)가 어떻게 변화하는지 보여주는데, pps는 초당 전송되는 패킷의 개수를 뜻한다. bps와 마찬가지로 대부분이 TCP임을 알 수 있다. 만약 pps 수치가 갑자기 늘어난다면 웜이나 서비스 거부 공격일 가능성이 높으므로 주의하여야 한다.

앞에서 살펴보았던 <화면 4, 5, 6>의 그래프가 TCP, UDP, ICMP 등 프로토콜별 그래프였다면 <화면 7>의 그래프는 HTTP, FTP, SMTP 등 세분화된 서비스별 그래프를 보여주고 있다. 플로우스캔 설정 파일에서는 범례에 보이게 될 서비스명을 지정할 수 있게 되는데, 만약 별도로 지정하지 않은 서비스의 경우 other로 분류되며 흰색으로 표시된다.

DNS 트래픽의 경우 TCP도 있고, UDP도 있으므로 실제 네트워크 모니터링시에는 프로토콜별, 서비스별로 각각의 그래프를 종합하여 분석할 필요가 있다. 즉 포트 5000번의 트래픽이 급상승하였다면 같은 시각 프로토콜 그래프에서 이것이 TCP인지 UDP인지 확인하여야 한다는 것이다.

<화면 7> 서비스별 bps

<화면 8> 서비스별 fps

<화면 9> 서비스별 pps

다음으로는 bps, fps, pps가 유발되는 순서대로 가장 많은 트래픽을 유발하는 IP 주소별로 분류한 것을 보여주고 있다. 이 정보 역시 매 5분마다 자동 업데이트가 되어 분류되는데, 특정 시간대에 비정상 트래픽이 유발된다면 이 정보를 살펴보아 어떤 IP에서 유발된 트래픽인지 직관적으로 알 수 있게 될 것이다.

<화면 10> IP별 트래픽 유발 정보

보안 대처 능력을 향상시키기 바라며
지금까지 효율적인 네트워크 모니터링 솔루션으로서 넷플로우를 활용한 플로우스캔의 기능에 대해 살펴보았는데, 이외에도 CLI 환경에서 더 세부적인 모니터링 기능을 할 수 있는 등 추가적인 기능도 있고 메일링 리스트 등을 통해 새로운 기능이 계속적으로 공유되고 있으므로 각자의 환경에서 적절히 응용한다면 굳이 전문적인 지식이 없더라도 네트워크 차원에서 발생할 수 있는 여러 장애 등을 사전에 예방하고 대처할 수 있게 될 것이다. 다음 글에는 여러 환경에서 손쉽게 사용할 수 있는 유용한 보안 소프트웨어의 활용 방안에 대해 알아보도록 하겠다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.