네트워크취약성과대책 #1 : 스니핑(sniffing)공격과 대책 4편(원격지서버 스니핑 모니터링 프로그램)

원격지 서버의 스니핑 모니터링 프로그램

특정 서버에서 스니핑이 작동하고 있는지 확인하기 위해서 리눅스에서는 ifconfig가 변조되지 않았다는 전제하에 ifconfig를 실행하였을 때 PROMISC가 설정 되었는지 여부로 확인할 수 있다고 하였다. 그런데, 관리하는 서버가 여러 대라면 매번 로그인하여 ifconfig로 PROMISC 설정 여부를 확인하겠는가? 게다가 만약 ifconfig 실행파일 자체가 변조되어 ifconfig 결과를 신뢰할 수 없다면 이는 아무런 의미가 없을 것이다.

이를 위해 원격에서도 특정 서버의 스니핑 작동 여부를 체크할 수 있는 Sentinel과 sniffdet이라는 프로그램을 소개하고자 한다.

Sentinel과 sniffdet을 설치하려면 미리 패킷 캡처 라이브러리인 Libnet과 libpcap이 설치되어 있어야 하는데, 각각

http://www.packetfactory.net/Projects/libnet 와 ftp://ftp.ee.lbl.gov/libpcap-0.4.tar.Z 에서 다운로드 받아 압축 해제 후 압축이 풀린 디렉토리에서 ./configure; make; make install로 설치하면 된다.

또는 http://rpmfind.net/에서 rpm으로 설치해도 된다.

* Sentinel

Sentinel은 매우 오래된 프로그램으로 현재는 업데이트되고 있지는 않은데,

http://www.packetfactory.net/Projects/sentinel/에서 다운로드 할 수 있으며 다운로드 후 압축 해제를 하고 압축이 풀린 디렉토리에서 make all로 컴파일 하여 설치하면 된다.

현재 Sentinel이나 뒤에서 살펴볼 sniffdet 등의 다른 프로그램에서 원격지 시스템에서의 스니핑 여부를 감지하는 방법은 3가지가 있는데, 각각 DNS test, Etherping test, ARP test 등이 있다.

참고로 이 방법은 ARP를 이용한 방법이므로 같은 네트워크 세그먼트 정확하게 이야기하면 동일한 Vlan에 속해 있어야만 탐지의 의미가 있다는 점을 다시 한 번 양지하기 바란다. 즉, Sentinel이 설치된 네트워크와 다른 네트워크에 있는 시스템은 스니핑 여부에 대한 확인이 불가능하다는 것이다.

먼저 각각의 방법이 가능한 원리에 대해 간단히 살펴보자.

첫 번째 “DNS test”의 경우 스니핑이 작동하는지의 여부를 확인하고자하는 목적지 서버에 존재하지 않는 위조된 연결요청을 보내어, 일부 스니핑 프로그램이 요청한 시스템의 IP주소를 역리졸브(Inverse DNS lookup)한다는 특징을 이용하여 DNS 트래픽을 감시함으로써 스니핑 여부를 감지하는 방법인데, 주로 오래되고 수준이 낮은 스니핑 프로그램의 작동을 감지할 수 있다.

실제로는 의미가 없는 방법이라고 할 수 있다.

두 번째 “Etherping test”는 주로 오래된 리눅스 커널 버전에 적용되는 방법으로 목적지에 ping 패킷을 보낼 때 목적지의 IP는 맞지만 목적지의 MAC 주소는 존재하지 않는 정보로 위조하여 icmp echo 패킷을 보내어 응답이 오는지 여부를 감시하는 방법으로 대부분의 정상적인 시스템에서는 존재하지 않는 MAC 정보이기 때문에 위조된 해당 패킷에 대해 무시하고 응답하지 않지만 promisc 모드가 설정된 시스템에서는 이에 관계없이 응답을 한다는 특징을 이용하여 감시하는 방법이다.

물론 숙련된 공격자는 이러한 사실을 미리 알고 스니핑을 하면서도 관련 패킷에 응답하지 않도록 할 것이다.

세 번째 “arp test” 역시 윈도우 NT등 윈도우 계열에 주로 적용되는 방법으로 IP는 목적지의 IP로 설정하지만 목적지의 MAC 주소를 다르게 하여 icmp 대신 arp 요구를 보내는 방법으로서 promisc 모드가 아닌 경우에는 패킷이 목적지까지 갈 수 없기 때문에 목적지에서는 응답하지 않지만 promisc 모드인 경우에는 모든 패킷을 받아들이므로 결국 응답한다는 특징을 이용하여 스니핑 여부를 감시하는 방법이다.

각각의 방식에 대한 Sentinel의 실행 예는 아래와 같다.

위와 같이 실행하였을 때 아래와 같이 탐지 결과가 “positive”라고 나왔다면

해당 시스템의 인터페이스 카드가 promisc 모드로 설정되었을 가능성이 있다는 의미이므로 해당 인터페이스의 promisc 여부를 조사하여야 한다.

그런데, 한 시스템에 대해 각각의 테스트를 동시에 실행했을 때 결과가 각기 다르게 나오는 경우가 있는데, 이는 특정한 인터페이스 카드에 따라 그리고 OS나 시스템의 커널 버전 등에 따라 종종 발생하는 현상으로서 세 가지 방법 중에 어느 하나라도 positive라는 결과가 나온다면 일단 스니핑 작동 여부를 확인하기 바란다.

이외 latency 테스트라는 것도 있는데, 이는 위조된 트래픽을 대량으로 유발시킨 후 해당 서버의 응답시간을 체크하는 것으로 promisc 모드의 경우 모든 트래픽을 받아들여 이 트래픽을 처리하느라 속도가 느려질 것이라 판단하는 것으로 이는 시스템의 CPU나 네트워크, OS 등에 따라 달라질 수 있으므로 그다지 신뢰할 만한 방법은 아니다.

* sniffdet

sniffdet는 앞의 sentinel보다는 최신의 프로그램으로 http://sniffdet.sourceforge.net/에서 다운로드할 수 있으며 압축해제 후 configure; make; make install로 설치하면 된다.

실행 파일은 /usr/local/sbin/sniffdet에, 설정 파일은 /usr/local/etc/sniffdet.conf에 설치되는데, sniffdet -h를 실행하면 사용할 수 있는 옵션을 보여준다. 설정 파일에서는 위조할 IP 및 MAC 주소 등을 지정할 수 있는데, 각각 다음과 같이 실행하면 된다.

여기에서 remote.sniffer.detector은 sniffdet을 실행하는 로컬의 IP이고, 211.47.68.36은 promisc 여부를 확인할 원격지의 IP이다.

- icmp 테스트

먼저 211.47.68.36이 promisc가 아닌 경우(ifconfig eth0 -promisc) 아래와 같이 결과가 NEGATIVE인 것을 알 수 있다.

[그림] arp 테스트 - promisc가 아닌 경우

아래는 이때의 tcpdump 결과이다.

211.47.68.36의 MAC주소를, 위조된 MAC주소인 ff:0:0:0:0:0으로 설정하여 211.47.68.36으로 icmp echo request 패킷을 발송하자 응답이 없는 것을 알 수 있다.

# tcpdump host 211.47.68.36 -e

tcpdump: listening on eth0

0:2:b3:23:47:ca ff:0:0:0:0:0 ip 98 : remote.sniffer.detector > 211.47.68.36: icmp: echo request (DF)

0:2:b3:23:47:ca ff:0:0:0:0:0 ip 98: remote.sniffer.detector > 211.47.68.36: icmp: echo request (DF)

0:2:b3:23:47:ca ff:0:0:0:0:0 ip 98: remote.sniffer.detector > 211.47.68.36: icmp: echo request (DF)

0:2:b3:23:47:ca ff:0:0:0:0:0 ip 98: remote.sniffer.detector > 211.47.68.36: icmp: echo request (DF)

다음은 211.47.68.36이 promisc인 경우((ifconfig eth0 promisc)를 살펴보면 아래와 같이 결과가 POSITIVE인 것을 알 수 있다.

[그림] arp 테스트 - promisc인 경우

아래는 이때의 tcpdump 결과이다.

211.47.68.36의 MAC주소를 위조된 MAC주소인 ff:0:0:0:0:0으로 설정하여 211.47.68.36으로 icmp echo request 패킷을 발송하자 응답이 오는 것을 알 수 있다.

0:2:b3:23:33:14는 실제 211.47.68.36의 MAC주소이다.

# tcpdump host 211.47.68.36 -e

0:2:b3:23:47:ca ff:0:0:0:0:0 ip 98: remote.sniffer.detector > 211.47.68.36: icmp: echo request (DF)

0:2:b3:23:33:14 0:2:b3:23:47:ca ip 60: 211.47.68.36 > remote.sniffer.detector: icmp: echo reply

0:2:b3:23:47:ca ff:0:0:0:0:0 ip 98: remote.sniffer.detector > 211.47.68.36: icmp: echo request (DF)

0:2:b3:23:33:14 0:2:b3:23:47:ca ip 60: 211.47.68.36 > remote.sniffer.detector: icmp: echo reply

- arp 테스트

arp 테스트 역시 같은 방법으로 확인할 수 있는데, 아래와 같이 실행하면 된다.

# sniffdet -t arp -c ./sniffdet.conf 211.47.68.36

211.47.68.36이 promisc가 아닌 경우((ifconfig eth0 -promisc) 아래와 같이 MAC주소를 ff:0:0:0:0:0으로 위조하여 arp 요청을 하자 응답이 없는 것을 알 수 있다.

# tcpdump host 211.47.68.36 -e

0:0:0:0:0:1 ff:0:0:0:0:0 arp 42: arp who-has 211.47.68.36 (ff:0:0:0:0:0) tell remote.sniffer.detector

0:0:0:0:0:1 ff:0:0:0:0:0 arp 42: arp who-has 211.47.68.36 (ff:0:0:0:0:0) tell remote.sniffer.detector

0:0:0:0:0:1 ff:0:0:0:0:0 arp 42: arp who-has 211.47.68.36 (ff:0:0:0:0:0) tell remote.sniffer.detector

211.47.68.36이 promisc인 경우(ifconfig eth0 promisc) 아래와 같이 MAC주소를 ff:0:0:0:0:0으로 위조하여 arp 요청을 하자 응답이 오는 것을 알 수 있다.

여기에서 0:2:b3:23:33:14는 실제 211.47.68.36의 MAC주소이다.

# tcpdump host 211.47.68.36 -e

0:0:0:0:0:1 ff:0:0:0:0:0 arp 42: arp who-has 211.47.68.36 (ff:0:0:0:0:0) tell remote.sniffer.detector

0:2:b3:23:33:14 0:0:0:0:0:1 arp 60: arp reply 211.47.68.36 is-at 0:2:b3:23:33:14

0:0:0:0:0:1 ff:0:0:0:0:0 arp 42: arp who-has 211.47.68.36 (ff:0:0:0:0:0) tell remote.sniffer.detector

0:2:b3:23:33:14 0:0:0:0:0:1 arp 60: arp reply 211.47.68.36 is-at 0:2:b3:23:33:14

이외, dns와 latency 테스트는 각각 아래와 같이 실행하면 되는데, 이때의 결과에 대해서는 별로 기대하지 않는 것이 좋을 것 같다.

#sniffdet -t dns -c ./sniffdet.conf 211.47.68.36

#sniffdet -t latency -c ./sniffdet.conf 211.47.68.36

???? [필자경험담]

아울러 arp와 관련된 프로그램으로 작지만 강력한 프로그램인 ARPWatch라는 프로그램도 알아두는 것이 좋다. arpwatch는 별도의 홈페이지는 없고

ftp://ftp.ee.lbl.gov/arpwatch.tar.gz에서 직접 다운로드 할 수 있다.

그렇다면, arpwatch의 작동원리는 무엇일까? 실제로 시스템에서 “tcpdump -e arp”를 실행하면 실시간으로 브로드캐스트되는 IP 주소와 MAC정보가 매칭 되어 보이는 것을 확인할 수 있는데, arpwatch는 이러한 arp트래픽을 실시간으로 모니터링하여 만약 현재의 arp 정보가 arpwatch 데이터베이스에 저장되어 있는 정보와 다르거나 새로운 MAC주소가 추가/확인시에는 해당하는 내용을 업데이트 한 후 변경된 내용을 미리 지정된 관리자에게 메일로 통보하게 되는 것이다.

따라서 arpwatch를 활용할 경우 이처럼 arp를 위조하는 형태의 공격을 인지하는데 매우 효과적이라고 할 수 있다.

다만, 여러 개의 Vlan으로 나누어져 있을 경우 해당 서버가 속한 Vlan의 트래픽만 모니터링 할 수 있다는 한계가 있다.

arpwatch 소스파일을 압축해제 한 후에는 addresses.h 파일만 수정하면 되는데, 이 파일에서는 아래와 같이 두 가지 변수를 지정할 수 있다.

WATCHER에는 비정상 MAC정보를 발견했을 때 메일을 발송할 메일 주소(receiver)를 지정하고, WATCHEE는 메일 발송 시 발송자(sender) 이름을 지정하면 된다.

이후 make all로 컴파일하면 arpwacth라는 실행파일이 생성된다.

이후 “arpwatch -d”를 실행하여 초기 arp데이터베이스를 생성한 후 옵션 없이 arpwatch를 실행하기만 하면 된다.

arpwatch를 실행하여 생성된 arp.dat 파일을 보면 다음과 같은 형식으로 보이게 된다.

그리고 이후 변경된 MAC 정보를 확인하였을 때 발송된 메일은 다음과 같은 형식이 된다.

위 메일의 의미는 원래 211.47.65.106의 MAC은 0:48:54:6a:c3:9c이었는데, IP는 그대로 211.47.65.106이면서 MAC주소가 0:0:0:0:0:1인 패킷이 보였다는 의미이다.

이렇듯 arpwatch 프로그램을 이용하면 arp를 이용하는 공격에 대한 모니터링 및 네트워크 관리에 매우 유용하다.