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

패킷별 색상을 이용한 분석효율 높이기 두번째 이야기!

패킷 색깔 입히기에 추가로 몇 가지 기능들을 다뤄보겠다.

View -> Colorize Conversation 을 보면 Ctrl + 1 부터 Ctrl + 0 까지의 색깔이 있다. 말 그대로 패킷간 어떤 대화가 이뤄진 부분 즉, 통신이 이뤄진 (Request , Response) 부분에 대해서 색깔을 지정할 수 있다. 분석을 하다 패킷을 세부적으로 본다든가 연관된 패킷을 본다 할때 색상를 적용해 놓으면 패킷 중 어떤 것이 같은 형태의 대화인지도 쉽게 파악이 된다. 기본 Color 룰이 적용되어 있는 상태에서는 다른 색상의 것들과 혼돈되어 헷갈릴 수도 있기는 하다. 하지만 Coloring Rule 이 적용되어 있지 않은 경우라면 대화내용에 색깔을 적용하여 쉽게 파악이 가능하다. 또는 자기만의 Coloring Rule 을 만들어 최소화 시켜 놓은 상태에서 Colorize Conversation 을 사용해도 그 효과가 더욱 높아질 것이다.

초기화 시킬 때는 Reset Coloring 을 클릭하면 된다.

나만의 컬러를 적용하거나 또는 남들이 만들어 놓은 컬러를 적용하고 싶다면 Coloring Rules 에서 Manage 에 Import 와 Export 를 이용하면 된다. Export 는 현재의 컬러에 대해서 파일로 설정을 저장해 놓는 것이고, Import 는 다른 컬러 파일을 로드하는 것이다.  다음의 URL 에는 컬러설정 샘플 파일들이 있다.

http://wiki.wireshark.org/ColoringRules

Jay's_Coloring_Rules 를 적용해 보면 아래와 같은 색상을 얻을 수 있다.

[출처 : 와이어샤크 위키]

저장된 룰 파일을 열어 보면 아래와 같이 구성되어 있는데, 라인만 보면 대충 의미가 파악 될 것이다.

지정된 이름과 필터 그리고 색상 정보이다. (Foreground, Background)

# DO NOT EDIT THIS FILE!  It was created by Wireshark

!@Bad TCP@tcp.analysis.flags@[0,0,0][65535,24383,24383]

!@HTTP@http || tcp.port == 80@[36107,65535,32590][0,0,0]

기능은 본인이 계속 사용하면서 나만의 것으로 만들어 나가야 도구의 기능을 효율적으로 쓸 수 있는 법이다. 이 기능을 이용하여 어떻게 분석을 효과적으로 할 수 있을지, 또 만들어 나갈 수 있을지 고민하면 도구는 점점 나의 것으로 다가올 것이다.

/Rigel

와이어샤크 패킷에 색깔을 입혀보자

다음 이미지는 와이어샤크에서 패킷파일을 읽어들인 것이다. 그런데 평소 와이어샤크에서 보던 것과 다르지 않던가? 먼가 다양한 색깔로 표시되어 있던 것과는 사뭇 다른 느낌이다. 그만큼 각 패킷 별로 색깔을 주어 표시를 해주면 보기에도 쉽고 여러가지 면에서 도움이 많이 된다. 아래 그림은 일부러 와이어샤크의 Coloring Rule 기능을 제거해 본 것으로, 한눈에 쉽게 잘 들어와 보이지가 않는다. 어쩌면 우리는 이미 와이어샤크의 기능에 너무 익숙해져 있는 것일지도 모른다. :-)

와이어샤크의 View -> Coloring Rules 을 클릭해 보면 다음그림을 볼 수 있다. 이것은 기본으로 지정되어 있는 Default 칼러이다. 이것을 보면, 아! 왜 와이어샤크에서 패킷마다 색깔이 입혀져 있었는지 알겠구나 하고 생각이 들 것이다. 필터 부분을 보면 Name, String 으로 구분되어 있는데, Name 은 말 그대로 대표 이름을 지정한 것이고 String 에 표시된 부분은 필터 구문을 나타내고 있다. 즉, 해당 필터에 맞는 것은 그림과 같은 색상대로 패킷이 표시되는 것이다. 색상은 글자색과 바탕화면으로 나누어 지정할 수 있다.  Edit 를 선택하면 설정되어 있는 색상을 변경할 수 있고, 디폴트로 Enable 되어 있다. 만약 필요치 않은 룰은 Disable 하여 색상을 제거할 수도 있다. 또, 우측의 Order 는 각 색상 필터별로 우선순위를 지정한 것이다.

만약 자기가 지정한 색깔이 실제 반영되지 않는다면, 다른 색상 필터에 의해 순서가 뒤에 있지는 않은지 확인해 보면 된다.

다음은 New 를 눌러 색상 필터를 추가로 만들어 본 것으로 TCP 포트가 5555 이고 TCP 플래그가 PUSH 상태이며 데이터가 1 이상인 것에 대해서 색상을 지정한 것이다.

기본으로 지정되어 있는 색상만 사용하지 말고, 여러분들이 주로 분석에 이용하는 포트나, 기타 특별한 경우라면 자기가 좋아하는 색상으로 꾸며보는 것은 어떨까 한다. 눈에 더 쉽게 들어와 분석이 쉬워지지 않겠는가.

리눅스에서 와이어샤크(WireShark) 설치하기

윈도우 환경에서의 와이어샤크는 다운로드 받아 GUI 환경에서 쉽게 설치가 가능하다. 그렇다면 리눅스는 어떠한가? 이미 많이들 알고 있지만, 그래도 필자는 가급적 모든 부분에 대해서 한번 언급을 하고 넘어가는 것이 좋을것 같아 간단히 소개하도록 한다.

옛날에는 소스파일을 가져다 다 컴파일을 하고 필요한 라이브러리를 설치하고 많은 작업들이 필요로 했었으나, 요새는 리눅스가 윈도우 사용하기 만큼이나 많이 쉬워졌다. 필요한 소프트웨어가 있으면 간단한 명령어로도 쉽게 설치할 수 있으니 말이다. 많이 사용하는 우분투나 데비안 계열에서는 apt-get 이라는 명령어가 있다. 이 명령어를 통해 아래와 같이만 하면 바로 와이어샤크 설치가 가능하다. 만약 yum 이라는 것이 있다면 그걸 사용해도 된다. (yum install wireshark)

debian:/home/debian# apt-get install wireshark
Reading package lists... Done
Building dependency tree      
Reading state information... Done
The following extra packages will be installed:
  libadns1 libfreebob0 libjack0 libpcap0.8 libportaudio2 wireshark-common
Suggested packages:
  adns-tools jackd
The following NEW packages will be installed:
  libadns1 libfreebob0 libjack0 libpcap0.8 libportaudio2 wireshark
  wireshark-common
0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 11.2MB of archives.
After this operation, 42.2MB of additional disk space will be used.
Do you want to continue [Y/n]?

와이어샤크는 기본적으로 libpcap 을 이용하는데, 설치되어 있지 않아도 걱정할 필요가 없다. 관련된 추가 패키지를 알아서 설치해 주기 때문이다.  이런 바이너리 설치가 싫다면, 직접 소스코드를 받아와서 컴파일을 할 수 있다.

$ cd /home/[UserName]/temp
$ wget http://www.wireshark.org/download/src/wireshark-1.2.5.tar.bz2
$ bzip -d wireshark-1.2.5.tar.bz2
$ tar -xvf wireshark-1.2.5.tar 
$ cd wireshark-1.2.5
$ ./configure
$ make
$ make install

configure 시에는 다양한 옵션을 줄 수가 있는데, 사용할 수 있는 옵션은 ./configure --help 를 보면 된다. 예를 들어, 와이어샤크에서 스레드를 사용하기 원한다면 --enable-threads 를 넣어주면 된다. 이 옵션은 기본적으로 포함되어 있지는 않다.

만약 리눅스 환경에 익숙하지 않는 사용자라면 일단 바이너리를 설치하여 사용하길 바란다. 컴파일에는 라이브러리 및 기타 패키지들이 필요하기 때문에 처음 접해보는 사용자에겐 어렵게 느껴질 수 있다.

일단, 와이어샤크를 설치하고 함께 패킷 분석의 세계에 빠져보는 것이 마음 편할 것이다.
복잡한 것은 다 잊고 말이다.

pcap-util 을 이용한 또 다른 패킷 분할 방법

패킷파일이 큰 경우 Editcap 과 tcpslice 를 이용하여 패킷을 분할하는 방법에 대해서 알아보았는데, 추가로 다른 유용한 툴 한가지를 더 소개하고자 한다. 펄(Perl)로 만들어진 것으로, 사용법도 간단하고 오히려 쉽게 사용할 수 있는 부분이 있는거 같아 유용할 것이다.

파일은 다음의 경로에서 받을 수 있다.

http://www.badpenguin.co.uk/files/pcap-util

일단, pcap-util 을 실행해 보면 옵션은 크게 split, time, filter 로 나뉘어져 있다.

tmp# ./pcap-util

This utility will take a pcap file from a packet capture program like tcpdump

and split it into smaller parts to aid analysis. There are three options.

 1. You can split the file into several smaller ones of x bytes in length

 2. You can extract packets that fall within a specified time period

 3. You can extract packets that match a libpcap filter string.

Split into smaller files

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

./pcap-util split <infile> <outfile prefix> <size in MB>

Extract packets from time period

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

./pcap-util time <infile> <outfile> <Start time> <End time>

Extract packets using libpcap filter language

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

./pcap-util filter <infile> <outfile> "libpcap filter string"

** Time format should be YYYY-MM-DD:hh:mm:ss **

자, 그럼 일단면 옵션은 크게 split, time, filter 로 나뉘어져 있다. split 는 말 그대로 파일을 분할 하는 것인데 MB 단위로 분할하게 된다. 아래 예 같이 1을 넣게 되면 1 메가 단위로 output.pcap 으로 생성하는 것이다.

/tmp# ./pcap-util split rigel.pcap output.pcap 1
Writing file output.pcap.0.tcpdump
Writing file output.pcap.1.tcpdump
Writing file output.pcap.2.tcpdump
Writing file output.pcap.3.tcpdump
Writing file output.pcap.4.tcpdump
Writing file output.pcap.5.tcpdump
Writing file output.pcap.6.tcpdump
Writing file output.pcap.7.tcpdump
Writing file output.pcap.8.tcpdump

====> Done <====
/tmp# ls -l
total 93368

-rw-r--r-- 1 root    root     1023460 2010-01-19 08:54 output.pcap.0.tcpdump
-rw-r--r-- 1 root    root     1023472 2010-01-19 08:54 output.pcap.1.tcpdump
-rw-r--r-- 1 root    root     1023490 2010-01-19 08:54 output.pcap.2.tcpdump
-rw-r--r-- 1 root    root     1023466 2010-01-19 08:54 output.pcap.3.tcpdump
-rw-r--r-- 1 root    root     1023498 2010-01-19 08:54 output.pcap.4.tcpdump
-rw-r--r-- 1 root    root     1023676 2010-01-19 08:54 output.pcap.5.tcpdump
-rw-r--r-- 1 root    root     1023570 2010-01-19 08:54 output.pcap.6.tcpdump
-rw-r--r-- 1 root    root     1023559 2010-01-19 08:54 output.pcap.7.tcpdump
-rw-r--r-- 1 root    root       83061 2010-01-19 08:54 output.pcap.8.tcpdump
-rwxr-xr-x 1 root    root        8736 2009-08-30 18:16 pcap-util
-rw-r--r-- 1 root    root     8271060 2010-01-18 09:25 rigel.pcap

타임은 "YYYY-MM-DD:hh:mm:ss" 와 같은 포맷으로 시간을 지정하여 사용하면 된다. filter 는 걸러진 파일에 대해서만 추출하여 저장한다. 아래 예제는 cl.exe.pcap 에서 TCP 이며 목적지 포트가 80 번 인것을 대상으로 output.pcap 에 저장하고 있다.

/tmp# ./pcap-util filter cl.exe.pcap output.pcap "tcp and dst port 80"
Writing packets matching "tcp and dst port 80" to output.pcap

====> Done <====
/tmp# ls -l
total 88948
-rw-r--r-- 1 root    root     2334504 2010-01-19 09:01 cl.exe.pcap
-rw-r--r-- 1 root    root     1442126 2010-01-19 09:02 output.pcap

cl.exe.pcap 이 2.3 메가 정도 였는데, 80 번포트로 걸러낸 것은 1.4 메가 정도 나온다. 이 외에 유용한 것이 있으면 알려주세요.

분석할 패킷 데이터 크기가 큰 경우는 이렇게 하자!

요새는 고속의 네트워크로 연결되어 있고, 전송되는 데이터의 크기도 커지고 많아지다 보니 패킷 데이터 캡쳐시 패킷 파일 크기 또한 상당히 커지게 된다. 50M 이상의 크기를 읽어 들이기 시작하면 컴퓨터의 메모리 또한 많이 차지하고 분석하기에도 여간 불편해 지는 것이 아니다.

필터를 한번 적용하거나, 기타 작업을 수행할 때 속도가 느려지는 것은 당연하다.

이럴때는 분석할 패킷을 분할하여 하는 것이 효과적이다. 몇 십,몇 백메가가 되는 파일을 한번에 읽어들이면 속이 타는 것은 분석가들의 마음일 뿐이다. 어떤 방법들이 있는지 한번 알아보도록 하자.

우리가 흔히 유닉스 환경에서 사용하던 split 명령을 기억할 것이다. 이름에서 느껴지는 것과 같이 split 는 파일을 분할해 주는 것이다. 아래 화면은 -l 옵션을 사용해 1000 라인 단위로 inside.pcap 파일을 분할 하였고, 분할된 패킷은 xaa, xab, xac ... 와 같이 차례대로 분리 되었다.

# split -l 1000 inside.pcap

-rw-r--r-- 1 packet packet 39451913 2010-01-18 08:53 inside.pcap

-rw-r--r-- 1 packet packet   312239 2010-01-18 08:54 xaa

-rw-r--r-- 1 packet packet   140544 2010-01-18 08:54 xab

-rw-r--r-- 1 packet packet   218156 2010-01-18 08:54 xac

-rw-r--r-- 1 packet packet   302413 2010-01-18 08:54 xad

-rw-r--r-- 1 packet packet   127430 2010-01-18 08:54 xae

그런데, 이 split 는 우리가 사용하기에 문제가 있다. 정말 그대로 라인별로 잘라서 분할 시켜 주기 때문에, 첫번째 파일인 xaa 는 읽어 들일 수 있지만 두번째 파일인 xab 부터는 읽어들이려고 해도 에러가 발생한다. 이유인 즉, pcap 의 형식인 헤더가 xaa 만 있고 그 후에는 없기 때문이다. split 가 pcap 파일을 인식하고 분할된 파일에 pcap 헤더를 구성해서 만들어주지 않기 때문이다.

그럼 어떻게 해야 할까 ? 사용하기 편한 방법으로는 와이어샤크에 포함되어 있는 editcap 을 추천해 보고자 한다. 패킷 분석에 와이어샤크를 많이 사용하기도 하고, 기본으로 함께 설치되어 있는 파일이니 얼마나 편한가. 유닉스 뿐만 아니라 윈도우에서도 사용이 가능하다는 것도 장점이다.

다음 몇 가지 예제를 통해 사용방법에 대해 설명하겠다.

예제1) input.cap 파일에서 처음부터 100 개까지의 패킷을 output.cap 에 저장

#editcap -r input.cap output.cap 1-100

예제2) input.pcap 에서 output.pcap 파일에 10000 개의 패킷을 저장

# editcap -c 10000 input.pcap output.pcap

# ls

input.pcap                    output.pcap-00011  output.pcap-00024  output.pcap-00037

t.pcap            output.pcap-00012  output.pcap-00025  output.pcap-00038

output.pcap-00000          output.pcap-00013  output.pcap-00026  output.pcap-00039

output.pcap-00001          output.pcap-00014  output.pcap-00027  output.pcap-00040

output.pcap-00002          output.pcap-00015  output.pcap-00028  output.pcap-00041

output.pcap-00003          output.pcap-00016  output.pcap-00029  output.pcap-00042

output.pcap-00004          output.pcap-00017  output.pcap-00030  output.pcap-00043

output.pcap-00005          output.pcap-00018  output.pcap-00031  output.pcap-00044

output.pcap-00006          output.pcap-00019  output.pcap-00032  output.pcap-00045

output.pcap-00007          output.pcap-00020  output.pcap-00033  output.pcap-00046

output.pcap-00008          output.pcap-00021  output.pcap-00034  output.pcap-00047

output.pcap-00009          output.pcap-00022  output.pcap-00035  output.pcap-00048

output.pcap-00010          output.pcap-00023  output.pcap-00036

만약 input.pcap 이 10,000 개 이상인 경우는 10,000 개 단위로 output.pcap 뒤에 숫자가 붙어 만들어 진다.

예제3) -i 옵션을 통해 초 단위로 패킷을 나눈다.

#editcap -i 60 input.pcap output.pcap

예제4) 특정 시간범위를 지정하여 패킷 추출

# editcap -v -A "2010-01-15 14:00:00" -B "2010-01-15 15:00:00"  input.cap output.cap

-v 는 verbose 로 좀더 자세한 정보를 출력해 준다. -A 와 -B 로 시작과 끝을 지정한다.

예제5) 여러개의 범위를 지정하여 패킷 추출 하기

# editcap input.cap output.cap 1-100 500-600

1-100 번 까지 그리고 500-600 번 까지의 패킷을 output.cap 에 저장한다.

예제6) -r 옵션의 차이를 정확히 이해하자

1, 10, 200-300, 500-700 을 제외하고 output.cap 에 저장한다.

# editcap input.cap output.cap 1 10 200-300 500-700

1, 10, 200-300, 500-700 만 선택하여 output.cap 에 저장한다.

# editcap -r input.cap output.cap 1 10 200-300 500-700

이외 또 사용 가능한 것으로는 tcpslice 가 있다. 우선 이것도 시작과 끝 시간을 정할 수 있으며, 아래와 같이 +200 으로 시작 시간을 초로 지정할 수 있다. -R 옵션은 타임스탬프(timestamp)로 패킷 파일의 시작과 마지막 시간을 보여주며, -r 은 우리가 보기 쉬운 시간으로 -t 는 y,m,d,h 와 같은 형태로 보여주게 된다.

inside:/tmp# tcpslice -R  +200 +300 1.cap
1.cap   1263374793.063785       1263375147.306405
inside:/tmp# tcpslice -r  +200 +300 1.cap
1.cap   Wed Jan 13 18:26:33 2010        Wed Jan 13 18:32:27 2010
inside:/tmp# tcpslice -t  +200 +300 1.cap
1.cap   2010y01m13d18h26m33s063785u     2010y01m13d18h32m27s306405u

위 시간을 보면 2010년1월13일 18시26분33초 부터 시작하고 있다. 아래는 2010년1월13일 18시30분 부터 18시32분까지 패킷을 1.cap 에서 추출하여 output.cap 에 저장하는 명령어이다.  

inside:/tmp# tcpslice -w output.cap 2010y01m13d18h30m 2010y01m13d18h32m 1.cap

저장된 output.cap 파일을 tcpdump 로 살펴보면 첫 시작이 1월13일 18시30분 부터인 것을 알 수 있다.

inside:/tmp# tcpdump -tttt -r output.cap | more
reading from file output.cap, link-type EN10MB (Ethernet)
2010-01-13 18:30:02.223030 IP 111.x.x.9.1302 > 58.140.x.64.search: S 3807417969:3807417969(0) win
65535 
2010-01-13 18:30:02.223068 IP 58.140.x.64.search > 111.x.x.9.1302: S 3325899008:3325899008(0) ack
3807417970 win 2920 

Editcap 과 tcpslice 를 알았으니, 이제 큰 패킷 파일이라도 두려워하지 말자!

참고로, 저장할 때부터 큰 파일로 만들지 말고, 패킷 캡쳐 시에 저장옵션을 통해 분리하면 이렇게 분리하는 작업을 거치지 않아 편리하다. 참고) 패킷 파일의 크기, 개수등 저장 옵션을 지정해 보자

네트워크 패킷캡쳐 샘플파일 어디 구할데 없나요?

패킷 파일 분석과 관련한 짧은 글을 몇가지 올렸는데, 패킷 분석을 시작하는 입장에서는 어떤 것을 어떻게 분석을 시작해야 할지 막연하다. 분석을 해 보고자 해도 샘플 패킷파일도 없고 말이다. 샘플 패킷파일을 얻고자 하는 분들에게 소개한다. 와이어샤크의 도움말을 보면  샘플들을 얻을 수 있는 경로가 있다는 점.

Help -> Sample Captures 를 눌러보자. 그러면 다음의 사이트로 이동할 것이다.

http://wiki.wireshark.org/SampleCaptures

위 사이트에서 다양한 프로토콜 및 여러가지 샘플 패킷파일을 구할 수 있다. 패킷파일이 있으면

그래도 절반의 시작 아니던가. 한번씩 들여다 보고 어떤 형태인지 살펴보는 것이 도움이 될 것이다.

여기외에 해당 위키에 추가로 다운로드 받을 수 있는 주소도 있으니 그것도 함께 참고하길 바란다.

더불어, 파일을 한번에 다 다운받고 싶다면 다음의 방법을 사용해 볼 수 있다. 위키에도

몇가지 방법이 나와있지만, 필자가 확인한 바에는 아래의 방법이 제일 확실하다.

와이어샤크의 프로토콜 계층별 상태 보기

패킷 분석을 할 때 무작정 패킷 정보 보기 부터가 아니라 기본 정보를 얻고 시작하자고 언급하였다. Summary 정보이외에 프로토콜별 상태를 파악하는 것도 분석의 시작에 큰 도움이 된다.

와이어샤크의 메뉴에서 Statistics -> Protocol Hierarchy 를 클릭해 보자. 단축키로는 Alt+s 후 p 를 누르면 된다. 각 프로토콜 계층별로 한눈에 보기 쉽게 나열되어 있어, 프로토콜중 어떤 것이 가장 많은 분포를 차지하는지 알 수 있다. 만약 출력필터를 반영한 상태라면 그 출력필터에 맞는 상태 정보가 나오며, 아래 그림의 예제에서는 Display filter:none 로 아무것도 선택되어 있지 않아, 전체 패킷을 대상으로 한 정보이다.

여기 예에서는 IP 프로토콜이 대부분이고 그 중에서도 TCP 가 크게 차지하고 있으며, ICMP 도 높게 나타난 편이다. 해당 프로토콜 위에서 오른쪽 클릭을 해 보면 바로 프로토콜로 필터를 걸 수 있도록 메뉴가 나타난다. 여기서 %Packets 은 이 프로토콜이 얼마나 차지하고 있는지 퍼센트로 보여주는데, 나타나는 각 퍼센트를 더해보면 딱 맞아 떨어지지는 않다. 이것은 해당 프로토콜이 하나라도 포함되어 있으면 그것을 일괄적으로 다 계산한 것이기 때문이므로 100 을 기준으로 딱 맞지가 않는다. Packets 는 개수 그리고 Bytes 는 전송된 트래픽 양을 뜻한다. 그리고 End Packets 가 있는데, 이것은 상위 계층의 프로토콜을 마지막으로 계산한 값이다. 필자도 이 부분에서 혼돈스러웠는데, 이유는 일부 서적에서는 End Packets 을 패킷의 마지막 값으로 표현하기도 하였다. 즉, TCP RST 패킷이 발생한 것과 같이 패킷이 전송 후 마지막이라는 의미로 사용하였던 것이다.

쉽게 이해가 안된다면 그림에서 HTTP 프로토콜을 기준으로 설명해 보겠다.  HTTP 를 보면 375 개의 패킷으로 3.37%를 차지하고 있다. 그 중에 Line-based text data, Compuserve GIF, JPEG File Interchange Format, Media Type 으로 각각 또 나뉘어 있다. 각 값이 21, 104,54, 3을 더한다고 HTTP 의 개수인 375 가 되지는 않는다. 이유는 앞서 언급한 것과 같이 프로토콜에 해당하는 모든 개수를 산출하기 때문이다. 프로토콜 안에는 한개의 프로토콜만 있는 것이 아니라, 그 안에 여러개로 구성될 수 있는 것이다.

HTTP 패킷 건수는 375 건으로 나오지만, 실제는 403 개였다. 하지만 거기에는 SSDP 프로토콜 안에 HTTP 프로토콜이 들어가 있는 것으로 나와 실제 개수는 375 개 였던 것이다. 이걸 출력필터 문법으로 하면 아래와 같다.

http and !(udp.port == 1900)  => SSDP 를 제외한 HTTP

여기에서 HTTP 의 End Packets 을 보면 193 개다. 아니, HTTP 전체는 375 개가 나왔는데 193 개는 도대체 무슨말이던가? 이것은 각 프로토콜의 상위 계층 까지만을 표시한 것이다.

다음 그림을 보면 HTTP 프로토콜 아래에 Line-based text data 가 있다. 그렇다 HTTP End Packets 은 순수하게 HTTP 프로토콜까지 나열된 것을 뜻 하며, Line-based text data 가 포함된 것은 21 건이라는 의미가 된다.

즉, 193 건을 뽑아본다면 출력 필터는 아래와 같은 형식이 된다.

http and !(udp.port == 1900) and !(data-text-lines) and !image-gif and !image-jfif and !media

이제 프로토콜 계층별 상태를 완벽히 이해할 수 있겠죠.

조작된 패킷 전송으로 주니퍼 라우터 크래쉬 또는 리부팅

주니퍼 라우터에 조작된 패킷을 전송할 경우, 라우터가 Crash 되거나 또는 리부팅 될 수 있는 취약점이 보고 되었다. 주니퍼는 자사의 취약점 권고문을 외부로 공개하지 않고, 등록된 사용자만이 볼 수 있으므로 자세한 내용은 알 수 없으나, 알려진 것은 아래와 같다.

- TCP 헤더중 TCP 헤더 옵션에 조작된 패킷을 전송할 경우, JunOS 커널 크래쉬를 일으킬 수 있다.
   (JunOS 는 주니퍼 라우터 제품에서 사용하는 운영체제이다)

- 라우터에서 오픈되어 있는 TCP 포트에 전송하면 된다.

- JunOS 방화벽에서도 이번 이슈와 관련한 패킷을 차단하지 못한다.

이미지출처 : tomdixons.com , TCP 헤더

옵션 헤더 필드는 TCP 헤더에서 가장 마지막에 위치한 것이다. 영향을 받는 것은 2009년1월28일 전의 JunOS 3.x - 10.x 까지 해당된다. 현재 주니퍼 라우터를 운영하는 곳에서는 업그레이드 방법 이외에 임시적으로 이 문제를 해결하기 위한 방법은 없는 것으로 알려져 있다.

다음은 이번 취약점과 관련해 간단한 Concept 을 구현한 화면이다.

hod# ping 169.254.1.1
PING 169.254.1.1 (169.254.1.1): 56 data bytes
64 bytes from 169.254.1.1: icmp_seq=0 ttl=254 time=4.623 ms
64 bytes from 169.254.1.1: icmp_seq=1 ttl=254 time=4.531 ms
64 bytes from 169.254.1.1: icmp_seq=2 ttl=254 time=4.315 ms
^C<...>

hod# ./hod-junos-test 169.254.1.1 22
[*] Target IP: 169.254.1.1, Port: 22
[+] Sending TCP-packets with various crafted TCP options
[+] TCP options bruteforce progress:
[..........................................................
...........................................................
...........................................................
.......................................................]
[+] OK

hod# ping 169.254.1.1
PING 169.254.1.1 (169.254.1.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
^C

[출처 : http://ptresearch.blogspot.com/2010/01/juniper-junos-remote-kernel-crash-flaw.html]

관련 기사 : pcworld.com (http://www.pcworld.com/businesscenter/article/186244/juniper_patches_routercrashing_bug.html)

라우터는 인터넷 운영에 있어 핵심적인 장비로, ISP(Internet Service Provider) 등에서는 이런 취약점이 치명적이다. 네트워크 운영에서 장비들이 취약점을 갖는 경우 큰 문제를 야기할 수 있어, 네트워크를 관리하는 담당자라면 사용하는 벤더의 보안 권고문을 구독하는등 관리 뿐만 아니라 보안에도 관심을 가져야 할 것이다.

와이어샤크에서 원하는 패킷 내용 찾기

패킷 파일을 분석하는 과정에서 특정 값을 포함하고 있는지 찾아보는 경우, Find Packet 기능을 유용하게 사용할 수 있다. 패킷의 내용을 Hex, String 등으로 검색가능하다. 간단한 기능이면서도, 이 기능을 잘 활용하지 못하는 경우가 많다.

단축키로는 Ctrl+F 이며, 다음과 같은 화면이 나타난다. 필터,Hex,String 중에 조건을 선택하고 해당하는 값을 입력하면 된다. Search In 은 패킷 리스트 화면에서 기준으로 할 것인지, 상세 정보 부분인지, 바이트 단위로 검색할 것인지 검색 대상범위를 지정한다. 특정 HEX 값을 찾고자 하는 경우에는 edd0ff 와 같이 넣어주면 된다.

만약 "00:00" 를 사용하면 2 바이트의 널 값을 찾게 될 것이다. 필자의 경우 Display filter 의 활용성 보다 Hex 와 String 이 분석과정에서 아주 유용했다. 참고로 해당하는 값을 찾은 후 다음 패킷을 찾는 경우에는 Ctrl+N 을 사용하고 이전의 값을 찾는 경우는 Ctrl+B 를 사용하면 된다.

Firebug 를 이용한 HTTP 프로토콜 상태 모니터링

전문적인 네트워크 패킷 분석 프로그램 외에 간단히 웹 브라우저에서 기본적인 정보만을 확인할 때, 유용하게 사용해 볼 수 있는 것으로 Firebug 를 소개해 보고자 한다. Firebug 는 웹 개발 분석 용도로 사용되는 간단한 도구이다. 웹 개발을 주로 하고, 파이어폭스 브라우저를 사용하는 분들이라면 이 도구가 익숙할 것이다.

Firebug 는 CSS, HTML 및 자바스크립트를 분석할 수 있는 기능을 제공해 주고 있다. 그런데 여기에 HTTP 네트워크 상태 모니터링과 HTTP 헤더를 볼 수 있는 기능이 있다.

위 이미지는 Firebug 기능을 On 시키고 구글, 네이버를 각각 접속한 화면이다. 요청한 페이지에서 실제 요청이 일어나는 각각의 정보가 담겨있다. 구글의 경우는 11 번의 요청, 네이버는 104 번의 요청이 있었다. 메인 페이지를 로드하기 위해서 그 안에 담겨있는 컨텐츠는 이미지 및 외부 링크등 다양한 정보가 연결되어 있기 때문에 실제로 우리 눈에는 웹 페이지 한 화면이 나오지만, 패킷 관점에서는 많은 응답이 있다. 요청이 많다면 그 만큼 페이지 로딩 속도에 영향을 줄 수 있기 때문에, 퍼포먼스 테스트 과정에서 활용해 볼 수 도 있는 도구이다.

요청한 각 파일 정보뿐만 아니라, Net 탭을 클릭하면 HTTP 요청/응답 헤더 또한 볼 수 있다. HTTP 프로토콜과 관련해 간단히 확인할 정보가 있다면 전문 패킷 분석 도구 없이 이러한 정보만으로도 도움이 될 것이다.  참고로 Net 탭에서 정보가 나타나지 않는다면 'Enabled' 되어 있는지 확인해 보아야 한다.

Firebug 는 파이어폭스 브라우저에서만 설치되고, 다음 페이지를 참고해 설치하면 된다.

http://getfirebug.com/

네트워크 상태 정보와 관련한 정보는 아래 경로를 확인해 보면 된다.

http://getfirebug.com/net.html

HTTP 프로토콜 분석시 HTML 컨텐츠가 암호화 된것 같이 보이는 경우라면

웹 프로토콜은 HTTP 이고 포트번호는 기본적으로 80 번을 사용하고 있다.

패킷 덤프 프로그램을 통해 분석하다보면 HTML 내용이 제대로 보여야 하는데

이상한 문자열만 잔뜩 나타나는 경우가 있다. 분명 암호화 프로그램을 따로

쓰지도 않는데 말이다. 이런 경우는 HTTP 프로토콜에서 해당 컨텐츠 내용이

압축되어 있는 경우이다. HTTP 프로토콜 에서는 속도 향상을 위해 압축 방식을

지원하고 있는데, 지원 가능한 경우 HTTP 서버는 클라이언트에게 데이터를 보내주는 경우

gzip 으로 압축하여 전달하게 된다.

예를 들어, 일전에 "TCP 통신과정을 한눈에 쉽게 살펴보기" 라는 글에서

와이어샤크 사이트에 접속한 것은 HTML 출력내용이 모두 보였다. 하지만 이것은 필자가

보여주기 위해 수동으로 HTTP Request 를 한 것이므로 정상적으로 HTML 이 나타난 것이다.

만약 브라우저를 통해 요청하였다면 아래와 같이 보였을 것이다.

GET 요청을 하는 부분을 보면 Accept-Encoding 이라는 부분이 보인다. 여기에 gzip 이 나타나 있는데, 브라우저가 압축 방식의 컨텐츠를 지원하기 때문에 이렇게 요청한 것이다.

Accept-Encoding: gzip,deflate,sdch

그러면 HTTP 서버는 아래와 같이 컨텐츠가 gzip 으로 인코딩 되어 있다는 응답 헤더를 보내주고 실제 컨텐츠를 압축하여 전송한다.

Content-Encoding: gzip

실제 전송된 컨텐츠는 다음형태와 같이 압축되어 HTML 형태로 알아볼 수 없는 것이다.

Content-Type: text/html

...........Z.n.6....`. M....$Mj{\8.$5.8n.$-P..H.

m.THj.NQ`.f.l.d./.....v..#^........w.......F?..;F.._..........0<<

?.....A..>..7S*....b.,..\$...p...Y(...b.{.[{.

하지만, 이것은 브라우저의 지원 여부에 따라 달라지므로 요청시 gzip 인코딩을 요청하지 않으면 압축없이 정상적으로 HTML 컨텐츠를 바로 볼 수가 있다. 재밌는 것을 하나 보면 응답 헤더중에

X-Slogan: Be good. You never know who's running Wireshark nearby.

이라는 헤더가 보인다. 응답헤더에 X-Slogan 이라는 헤더를 추가하여 랜덤하게 슬로건 문구를

보여주고 있다. 와이어샤크 사이트! 재치가 있어 보인다 :-)