1day/원데이/하루/일용직/호스팅/서버호스팅/자료실/강좌/커뮤니티
웹호스팅    |  도메인등록    |  홈페이지 관리 서비스    |   문의하기    |  강좌    |  서비스 안내 및 가격
HOME
회원로그인
ID:
PW:

     0 분
     16 분
 
웹호스팅
서비스이용안내
웹호스팅 신청방법
서비스이용약관
호스팅 신청하기
입금내용 알리기
신청리스트 *
입금리스트 *
도메인신청리스트
고객지원 FAQ
문의하기
고객지원
파일질라설정(ftp)
pop3란?
SMTP란?
아웃룩세팅법
네임서버
   1차 : ns1.1day.co.kr
..........222.234.223.31
   2차 : ns2.1day.co.kr
..........222.234.223.32
계좌번호 안내
....우리은행(원데이)
....1005-902-808446
이메일 문의
.... 1day@1day.co.kr
전화번호안내
   고객지원
   T. 050-6447-2515
자료실/강좌
HTML 태그
자바스크립트강좌
리눅스기초강좌
리눅스중급강좌
 


네트워크 스니핑 기술 및 방지대책
 1day  | 2004·02·01 20:03 | HIT : 20,945 | VOTE : 6,074 |

 

네트워크 스니핑 기술 및 방지대책

CERTCC-KR

cert@certcc.or.kr, http://www.certcc.or.kr
박현미 연구원, hmpark@certcc.or.kr
신은경 연구원, sek@certcc.or.kr
이현우 연구원, lotus@certcc.or.kr



[목 차]

I. 스니핑이란?

II. 스니핑의 원리

III. 스위칭 환경에서의 스니핑 기법

1. Switch Jamming
2. ARP Redirect
3. ARP spoofing
4. ICMP Redirect

5. 스위치의 span/monitor port를 이용한 스니핑

IV. 스니핑 방지 대책

1. 암호화
2. 스위칭 환경의 네트워크 구성

3. 스니퍼 탐지
4. 네트워크 관리




I. 스니핑이란?

스니퍼(sniffer)는 원래 Network Associate사의 등록상표였으나 현재는 PC나 kleenex처럼 일반적인 용어로 사용되고 있다. "sniff"라는 단어의 의미(냄새를 맡다, 코를 킁킁거리다)에서도 알 수 있듯이 스니퍼는 "컴퓨터 네트워크상에 흘러다니는 트래픽을 엿듣는 도청장치"라고 말할 수 있다. 그리고 "스니핑"이란 이러한 스니퍼를 이용하여 네트워크상의 데이터를 도청하는 행위를 말한다.

이러한 스니핑 공격은 웹호스팅, 인터넷데이터센터(IDC) 등과 같이 여러 업체가 같은 네트워크를 공유하는 환경에서는 매우 위협적인 공격이 될 수 있다. 하나의 시스템이 공격 당하게 되면 그 시스템을 이용하여 네트워크를 도청하게되고, 다른 시스템의 User ID/Passwd를 알아내게 된다. 비록 스위칭 환경의 네트워크를 구축하여 스니핑을 어렵게 할 수는 있지만 이를 우회할 수 있는 많은 공격방법이 존재한다.

본 문서는 스위칭 환경에서의 스니핑 공격 기법과 그리고 이에 대한 대책을 설명한다.

II. 스니핑의 원리

LAN 상에서 개별 호스트를 구별하기 위한 방법으로 이더넷 인터페이스는 MAC(Media Access Control) 주소를 갖게 되며, 모든 이더넷 인터페이스의 MAC 주소는 서로 다른 값을 갖는다. 따라서 로컬 네트워크상에서 각 각의 호스트는 유일하게 구별될 수 있다.

다음은 이더넷(ethernet) 프레임의 포맷을 나타낸다.

destination MAC addr

6 byte

source MAC addr

6 byte

type

2

data

46-1500 byte

CRC

4

<표 1> 이더넷의 포맷(RFC 894)

그리고 위의 이더넷 포맷은 type에 따라 다음과 같은 3가지 포맷으로 구성된다.

   

type

0800

IP datagram

46-1500

 
   

type

0806

ARP request/reply

28

PAD

18

   
   

type

8035

RARP request/reply

28

PAD

18

   



이더넷은 로컬 네트워크내의 모든 호스트가 같은 선(wire)을 공유하도록 되어 있다. 따라서 같은 네트워크내의 컴퓨터는 다른 컴퓨터가 통신하는 모든 트래픽을 볼 수 있다. 하지만 이더넷을 지나는 모든 트래픽을 받아들이면 관계없는 트래픽까지 처리해야 하므로 효율적이지 못하고 네트워크의 성능도 저하될 수 있다. 그래서 이더넷 인터페이스(LAN 카드)는 자신의 MAC address를 갖지 않는 트래픽을 무시하는 필터링 기능을 가지고 있다. 이 필터링 기능은 자신의 MAC address를 가진 트래픽만을 보도록 한다.

또한 이더넷 인터페이스에서 모든 트래픽을 볼 수 있도록 하는 기능을 설정할 수도 있는데 이를 "promiscuous mode"라 한다. 스니퍼는 이더넷 인터페이스를 이러한 "promiscuous mode"로 설정하여 로컬 네트워크를 지나는 모든 트래픽을 도청할 수 있게 된다.



III. 스위칭 환경에서의 스니핑 기법

일반적으로 앞서 설명한 스니핑을 방지하는 방법으로 스위칭 허브를 사용하게 된다. 스위칭 허브는 로컬 네트워크를 여러개의 세크먼트로 나누어 쓸 수 있도록 하는데, 각 세그먼트내의 트래픽은 다른 세그먼트로 전달되지 않는다. 따라서 스위칭 허브를 이용하여 업무별로 또는 독립적인 사이트별로 네트워크를 나누어 놓으면 다른 네트워크 세그먼트내의 네트워크 트래픽을 도청할 수 없게 된다. 하지만 Switch Jamming, ARP Redirct나 ICMP Redirct 등의 기법을 이용하여 다른 네트워크 세그먼트의 데이터를 스니핑 할 수 있는 방법도 있다.

1. Switch Jamming

많은 종류의 스위치들은 주소 테이블이 가득차게 되면(Full) 모든 네트워크 세그먼트로 트레픽을 브로드케스팅하게 된다. 따라서 공격자는 위조된 MAC 주소를 지속적으로 네트워크에 흘림으로서 스위칭 허브의 주소 테이블을 오버플로우 시켜 다른 네트워크 세그먼트의 데이터를 스니핑 할 수 있게 된다. 이는 보안 원리의 하나인 "Fail close(시스템에 이상이 있을 경우 보안기능이 무력화되는 것을 방지하는 원리)"를 따르지 않기 때문에 발생한다. 스위치들은 사실상 보안보다는 기능과 성능 위주로 디자인 되어 있다.

다음은 arp flooding 공격을 할 때 발생하는 임의의 arp 패킷을 tcpdump를 이용하여 잡은것이다. 공격자가 만들어낸 이러한 임의의 arp 패킷의 MAC 주소는 스위치의 주소 테이블을 오버플로우 시키게 된다.

[root@consult /root]# tcpdump -e arp

tcpdump: listening on eth0

07:44:23.898915 79:94:74:11:d7:dc bc:47:d8:7b:31:51 arp 42: arp reply 82.195.6.82 is-at 79:94:74:11:d7:dc
07:44:23.898954 b8:29:3:9c:9e:5c 3f:cf:9b:70:fa:14 arp 42: arp reply 204.227.135.56 is-at b8:29:3:9c:9e:5c
07:44:23.898991 5:6f:25:db:4b:76 97:a0:d6:c7:f1:8f arp 42: arp reply 158.81.199.91 is-at 5:6f:25:db:4b:76
07:44:23.899027 f0:f4:2c:8f:50:f7 a6:ca:21:a1:dd:26 arp 42: arp reply 114.215.48.176 is-at f0:f4:2c:8f:50:f7
07:44:23.899063 10:3:1:5b:78:9f de:d0:b:d0:60:fa arp 42: arp reply 171.63.250.67 is-at 10:3:1:5b:78:9f
07:44:23.899099 c4:8c:89:15:83:fb 7d:cc:32:5b:f2:42 arp 42: arp reply 235.178.172.145 is-at c4:8c:89:15:83:fb
07:44:23.899136 5d:f2:9d:d4:92:49 5d:95:c2:bd:8f:86 arp 42: arp reply 19.140.139.241 is-at 5d:f2:9d:d4:92:49
07:44:23.899172 49:19:9a:cc:14:85 8c:49:56:7e:8b:b2 arp 42: arp reply 127.191.23.251 is-at 49:19:9a:cc:14:85
07:44:23.899209 71:28:86:3:70:99 90:4e:aa:20:d3:f2 arp 42: arp reply 143.251.139.236 is-at 71:28:86:3:70:99
...


2. ARP Redirect 공격

먼저 정상적인 ARP Protocol에 대하여 설명한다. IP 데이터 그램에서 IP 주소는 32 bit 구조로 되어 있고 이더넷 주소(MAC 주소)는 48 bit의 크기를 갖는다. 다른 호스트로 ftp나 telnet 등과 같은 네트워크 연결을 하기 위해서는 상대방 호스트의 이더넷 주소를 알아야 한다. 즉, 사용자는 IP 주소를 이용하여 연결을 하지만 이더넷상에서는 이더넷 주소를 이용하게 된다. 이를 위하여 IP주소를 이더넷 주소로 변환시켜 주어야 하는데 이를 ARP(Address Resolution Protocol)라 한다. 그리고 그 역 과정을 RARP(Reverse Address Resolution Protocol)라 한다. ARP를 이용하여 상대 호스트의 이더넷 주소를 알아내는 과정은 다음과 같다.

① 먼저 네트워크내의 모든 호스트에 "ARP Request"라고 불리는 이더넷 프레임을 보낸다. 연결하고자 하는 호스트의 IP 주소를 포함한 ARP Request는 이더넷상의 모든 다른 호스트들에게 "이 IP 주소를 사용하는 호스트는 나에게 하드웨어 주소(이더넷 주소)를 알려주시오"라는 의미를 갖는다.

② ARP Request를 받은 호스트 중 해당 IP를 사용하는 호스트는 자신의 하드웨어 주소(이더넷 주소)를 ARP Request를 보낸 호스트에게만 보내주게 되는데 이를 ARP Reply라고 한다.

③ 이후 두 호스트간의 통신(ftp, telnet 등)을 위하여 상대방의 이더넷 주소를 사용하게 되며, IP datagram을 송수신할 수 있게 된다.

다음 그림은 ARP Request와 ARP Reply의 과정을 보여주고 있다.


다음은 실제로 172.16.2.15 번 호스트에서 172.16.2.26번으로 ping을 했을 경우 나타나는 arp 트래픽이다. arp request/reply를 교환한 두 호스트는 상대방의 MAC 주소를 각각의 arp cache에 저장하게 된다. 따라서 마지막 라인에서 172.16.2.26번 호스트가 15번 호스트로 echo reply를 보낼때는 arp request/reply 과정을 거치지 않아도 된다.

[root@consult /root]# tcpdump -e host 172.16.2.26

tcpdump: listening on eth0

18:16:25.880837 0:0:e8:76:e8:bb Broadcast arp 60: arp who-has 172.16.2.26 tell 172.16.2.15
18:16:25.881021 0:c0:26:27:b:1c 0:0:e8:76:e8:bb arp 60: arp reply 172.16.2.26 is-at 0:c0:26:27:b:1c
18:16:25.881243 0:0:e8:76:e8:bb 0:c0:26:27:b:1c ip 74: 172.16.2.15 > 172.16.2.26: icmp: echo request
18:16:25.881407 0:c0:26:27:b:1c 0:0:e8:76:e8:bb ip 74: 172.16.2.26 > 172.16.2.15: icmp: echo reply

"ARP Redirect" 공격은 위조된 arp reply를 보내는 방법을 사용한다. 즉 공격자 호스트가 "나의 MAC 주소가 라우터의 MAC 주소이다"라는 위조된 arp reply를 브로드케스트로 네트워크에 주기적으로 보내어, 스위칭 네트워크상의 다른 모든 호스트들이 공격자 호스트를 라우터로 믿게끔한다. 결국 외부 네트워크와의 모든 트래픽은 공격자 호스트를 통하여 지나가게 되고 공격자는 스니퍼를 통하여 필요한 정보를 도청할 수 있게 된다.

※ ARP Protocol specification에 의하면 이미 cache에 저장하고 있는 IP에 대한 ARP request를 받게되면 호스트는 ARP request를 보낸 호스트의 MAC 주소를 cahe에 업데이트 하게 된다고 나와 있다. 그리고 이러한 cache의 업데이트 기능은 arp reply에도 적용되는 것으로 보이며, 위의 공격이 성공할 수 있는 요인이 된다. 하지만 시스템에 따라 다를 수도 있다.

이때 공격 호스트는 IP Forwarding 기능을 설정하여야 공격 호스트로 오는 모든 트래픽을 원래의 게이트웨이로 Forwarding 해줄 수 있다. 그렇지 않으면 외부로 나가는 모든 네트워크 연결이 끊어지게 된다.

다음은 "arpredirect"라는 공격 프로그램으로 공격했을 때 네트워크상에 나타나는 arp 패킷을 tcpdump를 이용하여 잡은 모습이다. 공격이 끝날때는 원래의 arp 매핑을 복원하여 네트워크 연결이 끊어지지 않도록 하고 있다.

[root@consult dsniff-1.8]# arpredirect 172.16.2.1

intercepting traffic from LAN to 172.16.2.1 (^C to exit)...

restoring original ARP mapping for 172.16.2.1

[root@consult dsniff-1.8]#

[root@consult /root]# tcpdump -e arp

(공격자 호스트가 라우터로 가장하는 공격)
15:29:36.887943
0:50:da:d3:1f:d3
Broadcast arp 60: arp reply
172.16.2.1
is-at 0:50:da:d3:1f:d3
15:29:38.895089
0:50:da:d3:1f:d3
Broadcast arp 60: arp reply
172.16.2.1
is-at 0:50:da:d3:1f:d3
15:30:01.005097
0:50:da:d3:1f:d3
Broadcast arp 60: arp reply
172.16.2.1
is-at 0:50:da:d3:1f:d3
15:30:05.025086
0:50:da:d3:1f:d3
Broadcast arp 60: arp reply
172.16.2.1
is-at 0:50:da:d3:1f:d3
 
(공격자 MAC)
         
(라우터 IP)
  (공격자의 MAC)

...

(공격이 끝날 때 네트워크를 복원하는 과정)
15:52:55.025088
0:60:2f:a3:9a:1c
Broadcast arp 60: arp reply
172.16.2.1
is-at 0:60:2f:a3:9a:1c
15:52:57.035050
0:60:2f:a3:9a:1c
Broadcast arp 60: arp reply
172.16.2.1
is-at 0:60:2f:a3:9a:1c
15:52:59.045050
0:60:2f:a3:9a:1c
Broadcast arp 60: arp reply
172.16.2.1
is-at 0:60:2f:a3:9a:1c
(라우터 MAC)
        (라우터 IP)  
(라우터 MAC)

※ 위조된 패킷을 주기적으로 보내는 이유는 다른 호스트의 arp cache를 지속적으로 위조하기 위해서 이다.

위와 같은 공격을 하게되면 다른 모든 호스트들은 공격자 호스트를 라우터로 인식하고 외부로 연결되는 모든 트래픽을 공격 호스트로 보내게 되는데 이때 공격자는 다음과 같이 IP Forwarding 기능을 이용하여 원래의 목적지로 패킷을 Forwarding 해야만 네트워크가 끊어지지 않게되고, 공격자는 지나가는 패킷을 스니핑할 수 있다.

[root@consult fragrouter-1.6]# ./fragrouter -B1

fragrouter: base-1: normal IP forwarding

172.16.2.15.1297 > 203.233.150.11.23: . ack 390289256 win 7636 (DF)
172.16.2.142.1287 > 203.233.150.11.53: udp 36
172.16.2.142.1288 > 210.116.114.147.80: S 13774318:13774318(0) win 8192 <mss 1460,nop,nop,sackOK> (DF)
172.16.2.15.1297 > 203.233.150.11.23: . ack 390289317 win 7575 (DF)
172.16.2.15.1300 > 203.233.150.39.23: . ack 1685228460 win 7865 (DF)
172.16.2.142.1288 > 210.116.114.147.80: . ack 97085742 win 8760 (DF)
172.16.2.142.1288 > 210.116.114.147.80: P 13774319:13774505(186) ack 97085742 win 8760 (DF)
...

3. ARP spoofing 공격

ARP redirect와 비슷한 공격 방법으로 다른 세그먼트에 존재하는 호스트간의 트래픽을 스니핑하고자 할 때 사용된다. 공격자는 자신의 MAC 주소를 스니핑하고자 하는 두 호스트의 MAC 주소로 위장하는 arp reply(또는 request) 패킷을 네트워크에 뿌린다. 즉 "나의(공격자의) MAC 주소가 스니핑하고자 하는 호스트의 MAC 주소이다"라는 arp reply를 각 각의 호스트에게 보내게 된다.

이러한 arp reply를 받은 두 호스트는 자신의 arp cache를 업데이트 하게 되고, 두 호스트간에 연결이 일어날 때 공격자 호스트의 MAC 주소를 사용하게 된다. 결국 두 호스트간의 모든 트랙픽은 공격자가 위치한 세그먼트로 들어오게 된다.

이러한 경우 arp redirect 공격과 마찬가지로 공격자 호스트로 넘어오는 트래픽을 본래의 호스트로 relay 해주어야만 두 호스트 간에 정상적인 연결을 할 수 있게 되고 스니핑도 할 수 있다. 그렇지 않으면 두 호스간의 연결은 이루어 질 수 없게 되고 결국 스니핑도 할 수 없게 된다.

다음은 "arpmitm"이라는 공격 프로그램을 이용하여 172.16.2.15와 172.16.2.18번 호스트간의 트래픽을 스니핑 하기 위한 공격했을 때 네트워크상에 나타나는 arp 패킷을 tcpdump를 이용하여 잡은 모습이다.


Usage: ./arpmitm <ip1> <mac1> <ip2> <mac2> <attacker's mac>

[root@consult]# ./arpmitm 172.16.2.15
00:00:E8:76:E8:BB
172.16.2.18
00:C0:26:28:F9:C7
00:50:DA:D3:1F:D3
(15번의 MAC)
(18번의 MAC)
(공격자의 MAC)

/*
* ARP MITM attack tool. (c) xdr 2000
* $Id: arpmitm.c,v 1.2 2000/03/28 21:26:48 xdr Exp $
*/

--- Starting ARP MITM ---

endpoint-1 (172.16.2.15) at 00:00:E8:76:E8:BB [ether] on eth0
endpoint-2 (172.16.2.18) at 00:C0:26:28:F9:C7 [ether] on eth0

-------------------------

[0x0]: Sending mitm to: endpoint-1 endpoint-2
[0x1]: Sending mitm to: endpoint-1 endpoint-2
...


[root@consult tools]# tcpdump -e arp

tcpdump: listening on eth0

(공격자 호스트가 Target 호스트로 가장하는 공격)

([0x0]: Sending mitm to: endpoint-1 endpoint-2에 해당하는 패킷)
16:38:30.915146 0:50:da:d3:1f:d3 0:c0:26:28:f9:c7 arp 42: arp reply 172.16.2.15 is-at 0:50:da:d3:1f:d3
16:38:31.225158 0:50:da:d3:1f:d3 0:0:e8:76:e8:bb arp 42: arp reply 172.16.2.18 is-at 0:50:da:d3:1f:d3

([0x1]: Sending mitm to: endpoint-1 endpoint-2에 해당하는 패킷)
16:38:41.545139 0:50:da:d3:1f:d3 0:c0:26:28:f9:c7 arp 42: arp reply 172.16.2.15 is-at 0:50:da:d3:1f:d3
  (공격자 MAC) (18번 호스트 MAC)     (공격자 MAC)
16:38:41.855131 0:50:da:d3:1f:d3 0:0:e8:76:e8:bb arp 42: arp reply 172.16.2.18 is-at 0:50:da:d3:1f:d3
  (공격자 MAC) (15번 호스트 MAC)     (공격자 MAC)

...

※ 위조된 패킷을 주기적으로 보내는 이유는 Target 호스트의 arp cache를 지속적으로 위조하기 위해서 이다.

4. ICMP Redirect 공격

ICMP(Internet Control Message Protocol)는 네트워크 에러 메시지를 전송하거나 네트워크 흐름을 통제하기 위한 프로토콜인데 ICMP Redirect를 이용해서 스니핑 할 수 있는 방법이 존재한다.

ICMP Redirect 메시지는 하나의 네트워크에 여러개의 라우터가 있을 경우, 호스트가 패킷을 올바른 라우터에게 보내도록 알려주는 역할을 한다. 공격자는 이를 악용하여 다른 세그먼트에 있는 호스트에게 위조된 ICMP Redirect 메시지를 보내 공격자의 호스트로 패킷을 보내도록하여 패킷을 스니핑하는 방법이다.

5. 스위치의 span/monitor port를 이용한 스니핑

이 방법은 스위치에 있는 monitor 포트를 이용하여 스니핑 하는 방법이다. monitor 포트란 스위치를 통과하는 모든 트래픽을 볼 수 있는 포트로 네트워크 관리를 위해 만들어 놓은 것이지만 공격자가 트래픽들을 스니핑하는 좋은 장소를 제공한다.

 



IV. 스니핑 방지 대책

네트워크 설정을 통하여 스니핑을 어렵게 하는 많은 방법이 있으나 가장 좋은 방법은 데이터를 암호화 하는 것이다. 데이터를 암호화 하게되면 스니핑을 하더라도 내용을 볼 수 없게 된다. SSL, PGP 등 인터넷 보안을 위한 많은 암호화 프로토콜이 존재한다.

하지만, 일관된 암호 프로토콜의 부재, 사용의 어려움, 암호 어플리케이션의 부재로 인하여 암호화를 사용할 수 없는 경우가 많이 있으며, 이러한 경우 가능한한 스니핑 공격을 어렵도록 네트워크를 설정하고 관리하여야 한다. 특히, 웹호스팅, 인터넷데이터센터(IDC) 등과 같이 여러 업체가 같은 네트워크를 공유하는 환경에서는 스니핑으로부터의 보안 대책이 마련 되어야 한다.

스니핑 방지를 위한 대책으로 먼저 네트워크를 스니핑하는 호스트를 주기적으로 점검하는 방법이 있다. 이러한 점검을 통하여 누가 네트워크를 도청하는지 탐지하여 조치하여야 한다. 몇 몇 침입탐지시스템(IDS)은 이러한 스니핑 공격을 탐지할 수 있다. 또한 스위칭 환경의 네트워크를 구성하여(비록 스니핑이 가능하기는 하지만) 되도록 스니핑이 어렵도록 하여야 한다.

1. 암호화

1.1 SSL

암호화된 웹서핑을 가능하게 해주는 SSL(Secure Sockets Layer)은 많은 웹서버와 브라우저에 구현되어 있다. 그리고 대부분의 전자상거래 사이트에 접속하여 신용카드 정보를 보낼 때 사용된다.

참고 사이트 : http://www.modssl.org/

1.2 PGP and S/MIME

전자메일(E-mail) 또한 많은 방법으로 스니핑되고 있다. 인터넷상으 여러곳에서 모니터링될 수도 있으며, 잘못 전달될 수도 있다. 전자메일을 보호하기 위한 가장 안전한 방법은 메일을 암호화 하는 방법이며, 가장 대표적인 방법은 PGP와 S/MIME을 사용한다. PGP는 add-on 제품으로 사용되고 있으며, S/MIME은 전자메일 프로그램에 구현되어 있다.

1.3 ssh

ssh(Secure Shell)은 유닉스 시스템에 암호화된 로그인을 제공하는 사실상 표준으로 사용되고 있다. telnet 대신에 반듯이 ssh을 사용하여야 한다. ssh을 제공하는 많은 공개된 도구들이 존재 한다.

1.4 VPN

VPN(Virtual Private Networks)은 인터넷상에서 암호화된 트래픽을 제공한다. 하지만 VPN을 제공하는 시스템이 해킹당할 경우에는 암호화 되기 이전의 데이터가 스니핑 당할 수 있다.

2. 스위칭 환경의 네트워크 구성

스위치를 이용하여 업무 성격에 따라 그리고 처리하는 데이터에 따라 세그먼트를 구분하여 네트워크를 구성할 수 있다. 스위치는 트래픽을 전달할 때 모든 세그먼트로 브로드케스트 하지 않고 해당 세그먼트에만 전달하므로 일반 허브를 사용하는 것보다 안전하다. 하지만 앞서 설명한 "스위칭 환경에서의 스니핑 기법"과 같은 공격을 할 수 있다. 또한 같은 세그먼트내에서의 스니핑은 막을 수 없다.

스위치를 설정할 경우, 스위치의 주소 테이블을 static하게 설정하여 "스위칭 환경에서의 스니핑"을 막을 수 있는 방법이 있다. 아래와 같이 스위치의 각 포트에 대하여 MAC 주소를 static(permanent)하게 대응시키면 ARP spoofing, ARP redirect 등의 공격을 막을 수 있다. 이러한 방법은 보안관리에 많은 시간을 소모하게 되지만 매우 효과적인 대응방법 이다.

포트

MAC 주소

permanence

1

0:60:2f:a3:9a:16

Yes

2

0:60:97:c4:f:3e

Yes

3

8:0:20:79:c9:ea

Yes

4

0:60:97:c4:f:3e

Yes

5

0:a0:24:28:c4:47

Yes

...

...

...

<표 5> Switch Table을 Static으로 설정

3. 스니퍼 탐지

모든 스니퍼는 네트워크 인터페이스를 "promiscuous mode"로 설정하여 네트워크를 도청하게 된다. 따라서 호스트가 "promiscuous mode"로 설정되어 있는지 주기적으로 점검하여 스니퍼가 실행되고 있는 시스템을 탐지하여야 한다. 스니핑 기술과 마찬가지로 스니퍼를 탐지하는 방법도 고도화 되고 있다. 다음은 "promiscuous mode"로 설정된 시스템을 탐지하는 방법에 대하여 설명한다. 아래의 대부분의 방법들은 주로 로컬 네트워크내에서 탐지가능한 방법이다.

3.1 ping을 이용하는 방법

대부분의 스니퍼는 일반 TCP/IP 스택상에서 동작하기 때문에 request를 받으면 그에 해당하는 response를 전달하게된다. ping을 이용한 스니퍼 탐지 방법은 의심이 가는 시스템에게 ping을 보내는데 MAC 주소를 위장하여 보내는 방법이다.

① MAC 주소를 위조하여(로컬 네트워크에 존재하지 않는 MAC 주소 사용)하여 ping(ICMP Echo Request)을 다른 시스템에게 보낸다.

②③ 만약 ping reply(ICMP Echo Reply)를 받게되면, 해당 호스트가 스니핑을 하고 있는 것이다. 왜냐하면 존재하지 않는 MAC 주소를 사용했기 때문에 스니핑을 하지 않는 호스트는 누구도 ping request를 볼 수 없게되며, reply를 하지 않게 된다.

다음은 "sentinel" 이라는 스니퍼 탐지도구를 이용하여 33번 호스트에 대하여 ping 테스트를 하는 과정이다. 테스트 결과가 "positive"라고 나오며 이는 33번 호스트가 "promiscuous mode"로 설정되어 있음을 의미한다.

Usage:

./sentinel [method] [-t <target ip>] [options]

Methods:

[ -a ARP test ]

[ -d DNS test ] (requires -f (non-existent host) option

[ -i ICMP Ping Latency test ]

[ -e ICMP Etherping test ]

[root@consult sentinel-0.8]# ./sentinel -e -t 172.16.2.33

[ The Sentinel Project: Remote promiscuous detection ]

[ Subterrain Security Group (c) 2000 ]

Running on: 'consult' running on Linux 2.2.12-4 on a(n) i686

Device: eth0

Source IP Address: 172.16.2.31

Source Hardware Address: 0:50:da:d3:1f:d3

Target: 172.16.2.33

Performing ICMP etherping test

Sending out 10 bogus ICMP ECHO packets..

Results: 172.16.2.33 tested positive to etherping test.

다음은 sentinel이 실행될 때 네트워크에 나타나는 트래픽을 보여준다. 6, 8번 라인에서 "icmp: echo reply"가 회신되는 것을 볼 수 있다.

1: [root@consult Sniffer]# tcpdump -e host 172.16.2.33

2: tcpdump: listening on eth0

3: 07:35:59.985065 0:50:da:d3:1f:d3
ff:0:0:0:0:0
ip 42: consult.certcc.or.kr > 172.16.2.33: icmp: echo request
(위조된 MAC)

4: 07:35:59.985716 0:80:c7:33:16:c2 Broadcast arp 60: arp who-has consult.certcc.or.kr tell 172.16.2.33

5: 07:35:59.985761 0:50:da:d3:1f:d3 0:80:c7:33:16:c2 arp 42: arp reply consult.certcc.or.kr is-at 0:50:da:d3:1f:d3

6: 07:35:59.986172 0:80:c7:33:16:c2 0:50:da:d3:1f:d3 ip 60: 172.16.2.33 > consult.certcc.or.kr: icmp: echo reply

7: 07:36:00.995056 0:50:da:d3:1f:d3 ff:0:0:0:0:0 ip 42: consult.certcc.or.kr > 172.16.2.33: icmp: echo request

8: 07:36:00.995571 0:80:c7:33:16:c2 0:50:da:d3:1f:d3 ip 60: 172.16.2.33 > consult.certcc.or.kr: icmp: echo reply

3.2 ARP를 이용하는 방법

ping 방법과 유사한 방법으로 non-broadcast로 위조된 ARP request를 보냈을 때 ARP response가 오면 상대방 호스트가 "promiscuous mode"로 설정되어 있는 것이다.

다음은 33번 호스트에게 위조된 ARP request를 보내어 ARP reply가 오는지를 테스트하는 과정이다. 마찬가지로 결과가 "positive"로 나오게 되면 이는 33번 호스트가 "promiscuous mode"로 설정되어 있음을 의미한다.

 

[root@consult sentinel-0.8]# ./sentinel -a -t 172.16.2.33

[ The Sentinel Project: Remote promiscuous detection ]

[ Subterrain Security Group (c) 2000 ]

Running on: 'consult' running on Linux 2.2.12-4 on a(n) i686

Device: eth0

Source IP Address: 172.16.2.31

Source Hardware Address: 0:50:da:d3:1f:d3

Target: 172.16.2.33

Performing ARP test

Sending out 10 bogus ARP requests..

Results: 172.16.2.33 tested positive to arp test.

다음은 sentinel이 실행될 때 네트워크에 나타나는 트래픽을 보여준다. 4, 6번 라인에서 arp reply가 회신되는 것을 볼 수 있다.

1: [root@consult Sniffer]# tcpdump -e arp
2: tcpdump: listening on eth0

3: 07:34:03.485066
ff:0:0:0:0:0 ff:0:0:0:0:0
arp 42: arp who-has 172.16.2.33 tell consult.certcc.or.kr (0:50:da:d3:1f:d3)
(위조된 MAC)

4: 07:34:03.485549 0:80:c7:33:16:c2 0:50:da:d3:1f:d3 arp 60: arp reply 172.16.2.33 is-at 0:80:c7:33:16:c2

5: 07:34:04.495057 ff:0:0:0:0:0 ff:0:0:0:0:0 arp 42: arp who-has 172.16.2.33 tell consult.certcc.or.kr (0:50:da:d3:1f:d3)
  (위조된 MAC)  

6: 07:34:04.495968 0:80:c7:33:16:c2 0:50:da:d3:1f:d3 arp 60: arp reply 172.16.2.33 is-at 0:80:c7:33:16:c2

3.3 DNS 방법

일반적으로 스니핑 프로그램은 사용자의 편의를 위하여 스니핑한 시스템의 IP 주소를 보여주지 않고 도메인 네임을 보여주기 위하여 Inverse-DNS lookup을 수행하게 된다. 따라서 DNS 트래픽을 감시하여 스니퍼를 탐지할 수도 있다.

이 방법은 원격 또는 로컬 네트워크 모두에서 할 수 있는 방법이다. 원격에서 테스트 대상 네트워크로 Ping sweep을 보내고, 들어오는 Inverse-DNS lookup을 감시하여 스니퍼를 탐지할 수 있다. 로컬에서 할 경우에는 위조된 IP 주소로 IP datagram을 보내고 이에 대한 DNS lookup이 있는지 감시하여 스니퍼를 탐지할 수 있다.

3.4 유인(decoy) 방법

스니퍼를 실행하는 공격자는 일반적으로 사용자 ID와 패스워드를 도청한다. 그리고 도청한 ID와 패스워드를 이용하여 다른 시스템을 공격하게 된다. 따라서 네트워크상에 클라이언트/서버를 설정하여 미리설정된 사용자 ID와 패스워드를 지속적으로 흘려 공격자가 이 패스워드를 사용하게 끔한다. 관리자는 IDS 또는 네트워크 감시 프로그램을 이용하여 이러한 미리설정된 ID와 패스워드를 사용하는 시스템을 탐지함으로서 스니퍼를 탐지할 수 있다.

http://www.zurich.ibm.com/Technology/Security/extern/gsal/sniffer_detector.html

3.5 host method

호스트 단위에서 "promiscuous mode"를 확인하는 방법으로 "ifconfig -a" 명령을 이용하여 확인할 수 있다. 다음의 결과에서 "PROMISC" 부분을 보고 "promiscuous mode"가 설정되어 있음을 알 수 있다.

[root@lotus]# ifconfig -a

eth0 Link encap:Ethernet HWaddr 00:50:DA:50:1C:D3
inet addr:172.16.2.31 Bcast:172.16.2.255 Mask:255.255.255.0

UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:538138 errors:0 dropped:0 overruns:0 frame:0
TX packets:317739 errors:0 dropped:0 overruns:0 carrier:2

collisions:251 txqueuelen:100
Interrupt:3 Base address:0x300

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:40 errors:0 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0

4. 네트워크 관리

앞서 설명바와 같이 스니퍼를 탐지할 수 있는 많은 방법이 존재하며 또한 이를 구현한 공개용 도구가 있다. 네트워크 관리자는 이러한 도구를 이용하여 주기적으로 스니퍼의 설치 여부를 감시함으로서 외부로부터의 공격자를 포함하여 악의의 내부 사용자를 탐지할 수 있다. 다음은 앞서 설명한 공격을 탐지하는데 사용할 수 있는 공개용 도구에 대하여 설명한다.

4.1 ARPwatch

ARP 트래픽을 모니터링하여 MAC/IP 매칭을 감시하는 프로그램으로 초기에 설정된 ARP 엔트리(ethernet/ip addr)가 변하게 되면 이를 탐지하여 관리자에게 메일로 통보해 주는 도구이다. 대부분의 공격기법이 위조된 ARP를 사용하기 때문에 이를 쉽게 탐지할 수 있다. 다음은 "arpwatch -d"를 실행하여 초기 ethernet/ip 쌍에 대한 데이터베이스를 만든 것이다. 이후 "arpwatch"를 실행하게 되면 추가되거나 변경되는 ethernet/ip 쌍에 대하여 메일을 통하여 경고를 주게된다. 관리자는 메일을 통하여 ARP를 이용한 공격을 탐지하고 대응할 수 있다.

0:x:x:a3:x:6a

0:x:x:c4:x:3e

8:x:x:79:x:ea

0:x:x:c4:x:3e

0:x:x:28:x:47

8:x:x:b7:x:72

...

172.x.x.1

172.x.x.1

172.x.x.71

172.x.x.80

172.x.x.82

172.x.x.45

...

963475326

963473482

963465559

963474080

963469967

963475326

...

arp.dat 파일("arpwatch -d"로 모니터링한 결과)


ARPwatch 다운로드 사이트 : ftp://ftp.ee.lbl.gov/

4.2 Sentinel

Sentinel은 앞서 설명한 스니퍼를 탐지하는 방법을 구현한 도구이다. 4가지 방법으로 스니퍼를 탐지할 수 있는데 이중 "ICMP Ping Latency test(-i 옵션)"는 아직 구현되지 않았다. 네트워크 관리자는 내부 네트워크의 모든 호스트에 대하여 이와 같은 도구를 사용하여 주기적으로 스니퍼가 설치되어 있는지 점검해 보아야 한다. 그리고 스니퍼가 설치된 것으로 의심이 가는 호스트는 철저한 분석를 수행하고 만약 침입을 당하였을 경우에는 복구를 하도록 하여야 한다. 시스템 분석 및 복구에 대해서는 다른 기술문서에서 다루도록 한다.

Methods:

[ -a ARP test ]
[ -d DNS test ] (requires -f (non-existent host) option
[ -i ICMP Ping Latency test ]
[ -e ICMP Etherping test ]

다음은 sentinel을 이용하여 스니퍼를 탐지하는 예이다.

# ./sentinel -t 192.168.1.2 -a ; arp test against 192.168.1.2
# ./sentinel -t 192.168.1.2 -e ; etherping test against 192.168.1.2
# ./sentinel -t 192.168.1.2 -f 1.1.1.1 -d ; dns test against 192.168.1.2
# ./sentinel -t 192.168.1.2 -f 1.1.1.1 -d -a -e ; all of promisc detection tests against 192.168.1.2

Sentinel 다운로드 사이트 : http://www.packetfactory.net/projects/sentinel/

[참고문헌 및 참고사이트]

1. TCP/IP Illustrated, Volume1, The Protocols, W.Richard Stevens, ADDISON-WESLEY
2. dsniff, http://www.monkey.org/~dugsong/dsniff/
3. arpwatch, ftp://ftp.ee.lbl.gov/
4. Sentinel Project, http://www.subterrain.net/projects/sentinel
5. The Hunt Project, http://www.cri.cz/kra/index.html
6. arpmitm, http://teso.scene.at/releases.php3
7. Sniffing FAQ, http://www.securitymap.net/docs/faq/sniffing-faq.htm






출처 : cert
     
15   MySQL 에러코드별 에러메세지 입니다.  1day 05·08·16 393232
14   인터넷의 뿌리 TCP/IP 네트워크 바로알기  1day 04·02·12 20159
13   레드햇 시스템 최신으로 유지하기  1day 04·02·03 19849
12   Sendmail 메일서버의 스팸릴레이 대응방법  1day 04·02·01 20756
11   침해사고 대응방법 및 절차  1day 04·02·01 19878
  네트워크 스니핑 기술 및 방지대책  1day 04·02·01 20945
9   윈도우 NT서버 및 IIS 보안 관리  1day 04·02·01 25113
8   Solaris Network Kernel Tunning for Security  1day 04·01·31 23350
7   안전한 유닉스 프로그래밍을 위한 지침서 V.0.7  1day 04·01·30 21523
6   Abnormal IP Packets  1day 04·01·28 22566
5   DNS 안전운용가이드  1day 04·01·20 22115
4   MTX 웜바이러스 분석 보고서  1day 04·01·17 20482
3   IP Fragmentation을 이용한 공격기술들  1day 04·01·14 21419
2   리눅스 시스템 관리자를 위한 보안 지침Ⅰ  1day 04·01·14 19905
1   운영체제와 커널 차원에서의 튜닝 및 보..  1day 04·01·11 20089
1
Copyright 1999-2018 Zeroboard / skin by GGAMBO
Copyright (c) 2003~2004 by 1day all rights reserved.