2010년 1월 27일 수요일

100 기가 가 넘는 패킷 파일이라고 ?

우연챦게 패킷 덤프를 하는 과정에서 잘못되어 100기가가 넘는 패킷파일이 생성되었다. 생각만 해도 엄청나게 큰 패킷파일이다. 그런데 이 100 기가가 넘는 패킷 파일을 어떻게 분석해야 할까? 이걸 한번에 읽어 들이는 것은 말도 안되고, 분석을 하려하면 막막하다.

자 일단 실체를 확인해보자. 127G 의 패킷 파일이다. 놀라울 따름이다.

packet:/pcap# ls -lah *
-rw-r--r-- 1 root root 127G 2009-12-16 15:46 XXXXXX.pcap

capinfos 로 정보를 확인해 보려고 하나, 너무나 큰 나머지 읽어들이지 못한다.

packet:/pcap# capinfos -c XXXXXX.pcap
capinfos: Can't open XXXXXX.pcap: Value too large for defined data type

살짝 패킷파일의 앞 부분을 살펴보니 POST 데이터가 있는 HTTP 프로토콜이 보인다.

packet:/pcap# head XXXXXX.pcap
�ò��|#(K��<<������)�)�E�o       o|#(K��**)�E�ɵɵ�@o)�E�o ~#(K    D
\\������)�EEN��Lo       o����:]��Z FHFAEBEECACACACACACACACACACACAAA ~#(K%�>>ɵ�@)�EE0�@��o       =T*Z�Pv�l�ooɵ�@)�EEa�@�No�E�ɵ�E0@=T*Z�Pv�l�%�P���POST / HTTP/1.0 ý<<┤ý@)ýEE(�@��o        =T*Z�Pv�l�%�P���~#(K
Referer: Mozilla
Accept: */*
Content-Type: application/x-www-form-urlencoded
X-Request-Kind-Code: nodes
User-Agent: Mozilla
Host: 61.84.X.X
Content-Length: 107
Pragma: no-cache

일단 잘라서라도 보기 위해 editcap 을 이용해 처음부터 1천개의 패킷을 out.pcap 에 저장하려고 시도하지만, 역시나 이것도 수행하지 못한다.

packet:/pcap#editcap -r XXXXXX.pcap out.pcap 1-1000
 editcap -r XXXXXX.pcap out.pcap 1-1000
editcap: Can't open XXXXXX.pcap: Value too large for defined data type

tcpslice 를 이용해 패킷을 자르기 위해, tcpslice 를 찾아 시스템에 설치한다.

packet:/pcap# apt-cache search tcpslice
tcpslice - extract pieces of and/or glue together tcpdump files
packet:/pcap# apt-get install tcpslice
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libgstreamer0.10-0 libwxgtk2.8-0 libgconf2-4 libwxbase2.8-0 libidl0 gconf2-common liborbit2
  filezilla-common libgstreamer-plugins-base0.10-0
Use 'apt-get autoremove' to remove them.
The following NEW packages will be installed:
  tcpslice
0 upgraded, 1 newly installed, 0 to remove and 103 not upgraded.
Need to get 17.2kB of archives.
After this operation, 77.8kB of additional disk space will be used.
Get:1 http://http.us.debian.org lenny/main tcpslice 1.2a3-2.1 [17.2kB]
Fetched 17.2kB in 1s (9321B/s)
Selecting previously deselected package tcpslice.
(Reading database ... 48677 files and directories currently installed.)
Unpacking tcpslice (from .../tcpslice_1.2a3-2.1_i386.deb) ...
Processing triggers for man-db ...
Setting up tcpslice (1.2a3-2.1) ...

tcpslice 를 이용해 아래와 같이 5초 동안의 내용을 slice.pcap 에 저장한다.

packet:/pcap# tcpslice -w slice.pcap +0 +5s XXXXXX.pcap

5초동안 저장을 패킷을 capinfos 를 통해 패킷파일의 기본정보를 얻을 수 있다. 시간은 5초 동안이었고, 파일크기가 25 메가 였다. 패킷갯수는 13만개로 역시나 큰 파일이다.

packet:/pcap# capinfos  slice.pcap
File name: slice.pcap
File type: Wireshark/tcpdump/... - libpcap
File encapsulation: Ethernet
Number of packets: 135231
File size: 25973078 bytes
Data size: 23809358 bytes
Capture duration: 59.998932 seconds
Start time: Wed Dec 16 09:02:04 2009
End time: Wed Dec 16 09:03:04 2009
Data rate: 396829.70 bytes/s
Data rate: 3174637.57 bits/s
Average packet size: 176.06 bytes

일단 그래도 이 정도는 읽어들일 수 있으니 tcpdump 로 해당 파일을 읽어들여 아래와 같은 정보를 얻는다. HTTP 프로토콜이 다수의 랜덤 IP 로 통신이 이뤄져 있다.

  3   2.421176    X.X.X.9 -> X.X.255.255 NBNS Name query NB WPAD<00>
  4   2.505428    X.X.X.9 -> 61.84.X.X  TCP caicci > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460
  5   2.505461  61.84.X.X -> X.X.X.9    TCP http > caicci [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1
460
  6   2.505656    X.X.X.9 -> 61.84.X.X  TCP caicci > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
  7   2.505916    X.X.X.9 -> 61.84.X.X  HTTP POST / HTTP/1.0  (application/x-www-form-urlencoded)
  8   2.505954  61.84.X.X -> X.X.X.9    TCP http > caicci [ACK] Seq=1 Ack=314 Win=6432 Len=0
  9   2.506196  61.84.X.X -> X.X.X.9    HTTP HTTP/1.1 200 OK  (text/html)
 10   2.506240    X.X.X.9 -> 124.153.X.77 TCP hks-lm > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460
 11   2.506258  61.84.X.90 -> X.X.X.9    TCP http > caicci [FIN, ACK] Seq=283 Ack=314 Win=6432 Len=0
 12   2.506273 124.153.X.77 -> X.X.X.9    TCP http > hks-lm [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
<일부 IP 는 X 표시>

tshark 를 통해 프로토콜별 상태를 보면, 전체 패킷 13만개중 TCP 가 거의 대다수이고 이중 HTTP 가 11만개임을 볼 수 있다. 즉, 프로토콜별 통계 정보를 보아도 HTTP 가 대다수임을 알 수 있고, 초기 HEAD 를 통해서 본 HTTP  헤더와 같은 것이 랜덤한 목적지 IP 로 발생되고 있는 패킷임을 짐작 할 수 있다.

packet:/pcap# tshark -r slice.pcap -q -z io,phs

===================================================================
Protocol Hierarchy Statistics
Filter: frame

frame                                    frames:135231 bytes:23809358
  eth                                    frames:135231 bytes:23809358
    arp                                  frames:2 bytes:102
    ip                                   frames:135229 bytes:23809256
      udp                                frames:3 bytes:276
        nbns                             frames:3 bytes:276
      tcp                                frames:135226 bytes:23808980
        http                             frames:11270 bytes:3786751
          data-text-lines                frames:11270 bytes:3786751
        tcp.segments                     frames:11268 bytes:11391948
          http                           frames:11268 bytes:11391948
            data-text-lines              frames:11268 bytes:11391948
===================================================================

127 기가의 패킷 파일에서 약 25 메가 정도만을 확인하였지만, 나머지 패킷은 보지 않더라도 대략 이런 형태의 패킷 구성으로 이루어져 있음을 추정할 수 있다. 사실 127 기가의 단일 패킷은 현실적으로 분석이 힘들고, 빠르게 대략 패킷의 구성형태를 파악하고자 한다면 이와 같이 패킷의 일부분만을 뜯어내어 구성 형태가 어떤지 파악해 보면 추정이 가능하다. 물론, 전체에서 아주 미미한 수준만큼만 확인한 것이기 때문에 딱 이것이다 라고 단정지을 수는 없지만, 이게 최선의 방법 아니겠는가. 아니면 엄청난 시간과 노력을 들여서 분석을 한다면 가능하겠지만, 필자로서는 이 정도선에서 끝낸다. 왜냐하면 왜 이런 패킷이 생성되었는지 이미 알고 있기 때문에 사실 더 이상 분석할 가치는 없기 때문이다 :-)

@Rigel


댓글 1개: