Libpcap 1.2, Tcpdump 4.2 베타 버전 릴리즈

Libpcap 이 2010년 8월 1.1.2 버전을 나온이후로 오랜만에 새로운 버전이 릴리즈가 되었다.
앞 버전 번호를 크게 바꾼 1.2 버전으로 나타났다. 이번 버전에는 1.1.1 과 1.1.2 에서 변경된 모든 코드들이 다 포함되어 있고, pcap_findalldevs() 에 대한 에러핸들링도 변경되었다. 이에 몇가지 링크 레이어 타입이 추가되고 memory-mapped 캡쳐의 프레임 사이즈 계산도 수정되었다.

이외 tcpdump 버전도 4.2 로 릴리즈 되었으니, 이번기회에 libpcap 과 tcpdump 가 오래된 버전이라면 한번 업데이트 하는 것도 좋을것 같다. 다만, 아직 libpcap 1.2 , tcpdump 4.2 는 베타 릴리즈 상태이다.

[다운로드]

http://www.tcpdump.org/beta/libpcap-1.2.0rc1.tar.gz
http://www.tcpdump.org/release/tcpdump-4.1.1.tar.gz

패킷 데이터 문자열을 인덱스화하여 빠르게 검색하기

패킷 캡쳐파일을 다루다 보면, 큰 패킷파일을 도대체 어떻게 다뤄야 할까 하는 고민이 들게 마련이다. 이럴때 조금은 유용하게 사용할 수 있는 것이 있다. 패킷 데이터의 문자열을 인덱스 하여 빠르게 검색할 수 있도록 도와주는 것이다. 사용하려는 목적에 따라 다르겠지만, 이것을 응용해서 여러분들에게 딱 맞는 소프트웨어로도 변신할 수 있다.

일단, 프로그램 이름은 'tcpindex' 이다. 문자열들을 인덱스하여 빠르게 검색할 수 있도록 도와준다. Pcap 라이브러리가 기본적으로 사용되고, 텍스트 검색 기능을 위해 CLucene 가 사용되었다. CLucene 는 Lucene 의 C++ 로 포팅된 라이브러리로 빠른 성능의 검색 기능을 제공한다.

윈도우에서도 사용가능하며, 다운로드는 다음 경로를 통해서 할 수 있다.

• 윈도우 커맨드라인 버전 1.0
• tcpindex 소스코드 

윈도우 버전은 위 경로에서 바로 받아 사용하면 되고, 리눅스의 경우는 간단히

# ./configure
# make
# make install

과정을 거쳐서 사용하면 된다.

Tip!
나의 경우는 컴파일을 하다 아래와 같은 에러가 나타났다.

# make

stream_packet.h: In member function ‘void

stream_packet_t::read_bytes(uchar*, uint)’:

stream_packet.h:72: error: ‘memcpy’ was not declared in this scope

In file included from tcpindex.h:52,

                from main.cpp:20:

session.h: In constructor ‘session_t::session_t(uint, uint, uchar,

ushort, ushort)’:

session.h:61: warning: deprecated conversion from string constant to ‘char*’

In file included from main.cpp:20:

tcpindex.h: In constructor ‘options::options()’:

tcpindex.h:83: warning: deprecated conversion from string constant to ‘char*’

이런 경우는,

stream_packet.h 에 ' #include <string.h> '를 삽입하고 컴파일을 하면 무리없이 컴파일이 된다.

컴파일을 하고 사용방법을 보면 아래와 같다. 사용 설명은 리눅스 기준이지만, 윈도우의 바이너리 형태도 같다고 보면 된다.

# tcpindex -h
Usage: tcpindex [OPTIONS] [QUERY STRING]
Capture packets on a network interface and index packets containingso they
can be rapidly searched for keywords.

 -D, --list-interfaces  list the available network interfaces
 -i, --interface=INDEX  specify index of the interface to capture packets on
 -l, --index-dir=DIR    specify the directory for the search index (default is
                        'index_data')
 -h, --help             give this help
 -q, --query            specify a keyword query to perform against the index
 -s, --save-data        whether to save session data to individual files as
                        well as the index
 -v, --verbose          output verbose debugging messages

Example usage to capture and index data:
 tcpindex -i 1
Example usage to query:
 tcpindex -q +referer +aol

옵션은 많지 않고, 대충 보아도 사용방법을 눈치챌 수 있을 것이다. -i 는 인터페이스를 지정하고 -l 은 인덱스 경로 그리고 -q 는 쿼리를 뜻한다. -D 는 사용가능한 인터페이스 목록을 보여준다.

# tcpindex -D
1: eth0
   (null)
2: any
   Pseudo-device that captures on all interfaces
3: lo
   (null)
No interface specified.

일단, -i 로 인터페이스를 지정하고 실행해 보자. 인덱스 경로를 따로 지정하지 않으면 프로그램을 실행한 경로 기준으로 인덱스 파일이 생성된다.

# tcpindex -i eth0

중지는 Ctrl+C 를 눌러서 하면 된다. 이후, ls 로 목록을 살펴보면 아래와 같다:

# ls
index_data

TCP-192.168.0.203_39551-174.37.113.144_80

TCP-192.168.0.203_39552-174.37.113.144_80

TCP-192.168.0.203_39553-174.37.113.144_80

TCP-192.168.0.203_40924-74.125.127.128_80

TCP-192.168.0.203_42525-74.125.224.249_80

TCP-192.168.0.203_42530-74.125.224.249_80

TCP-192.168.0.203_44927-74.125.224.235_80

TCP-192.168.0.203_45103-74.125.127.121_80

TCP-192.168.0.203_47094-74.125.127.132_80

TCP-192.168.0.203_49501-74.125.224.243_80

TCP-192.168.0.203_57709-208.70.196.59_80

TCP-192.168.0.203_57710-208.70.196.59_80

TCP-192.168.0.203_57714-208.70.196.59_80

TCP-192.168.0.203_58132-74.125.127.95_80

TCP-192.168.0.203_60412-74.125.224.159_80

TCP 로 처음 시작하며 IP 주소와 포트 번호가 있는 것은 실제 데이터의 문자열 정보가 담겨 있는 것이다. 그리고 index_data 디렉토리 안에 인덱스가 있다.

인덱스를 이용한 검색을 하기 위해서는 -q 옵션을 사용한다. packetinside.com 으로 검색해 보았다.

# tcpindex -q packetinside.com
Searching for: packetinside.com

1. TCP-192.168.0.203_36292-74.125.127.191_80 - 0.18340063
 ; __utmz=150635877.1310986907.36.22.utmcsr=<B>packetinside.com</B>|utmccn=(referral)|utmcmd=referral|utmcct...=<B>packetinside.com</B>|utmccn=(referral)|utmcmd=referral|utmcct=/2011/05/nix.html
If-Modified-Since: Mon.
2. TCP-192.168.0.203_36351-74.125.127.191_80 - 0.16210480
 =150635877.1.10.1310986907; __utmc=150635877;
__utmz=150635877.1310986907.36.22.utmcsr=<B>packetinside.com</B>|utmccn.


Search took: 0 ms.

와우, 빠른 속도로 검색되어 나타난다. * 과 같은 와일드카드 형태도 사용 가능한데 아래와 같이 결과가 보인다.

# tcpindex -q packet*inside
Searching for: packet*inside

1. TCP-192.168.0.203_36292-74.125.127.191_80 - 0.12968384
 .
2. TCP-192.168.0.203_44927-74.125.224.235_80 - 0.12968384
 .

Search took: 0 ms.

~는 Fuzzy 서치 형태인데 알고리즘에 따른 검색이라 그런지, 시간은 조금 더 소요된다.

# tcpindex -q packet~
Searching for: packet~0.5

1. TCP-192.168.0.203_57709-208.70.196.59_80 - 0.22925079
 .
2. TCP-192.168.0.203_57713-208.70.196.59_80 - 0.18340063
 .

Search took: 3 ms.

이외 AND 오퍼레이트 사용도 가능하다.

# tcpindex -q +host "packetinside.com" AND GET
Searching for: +host +packetinside.com +get

# tcpindex -q +host +referer| grep packet
<B>Referer</B>:
http://www.packetinside.com...,firstScrollTime.1571,ol.1912 HTTP/1.1
<B>Referer</B>: http://www.packetinside.com...GET
/dyn-css/authorization.css?targetBlogID=4889001868370773649&zx=ad647330-a785-43be-847d-67c0566003e4
HTTP/1.1
<B>Referer</B>: http://www.packetinside.com.
<B>Referer</B>: http://www.packetinside.com/2011/07/cpugpu-durandal.html
<B>Host</B>: www.packetinside.com
<B>Referer</B>: http://www.packetinside.com/
<B>Host</B>: www.packetinside.com
<B>Referer</B>: http://www.packetinside.com/search/label/winpcap

매칭되는 부분은 <B> 와 </B> 로 둘러 쌓인다. 검색 조건과 관련해서는 Lucene 의 문법 형태를 참고해 보기 바란다. 아주 큰 데이터로 테스트 해보지는 않았지만, 문자열 기준으로 의심스러운 패턴을 찾아내거나 기타 패킷 문자열 검색 형태로는 유용하게 사용될 수 있으리라 생각된다.

도구 자체의 순수 기능만 보기 보다는 이것을 활용해서 다양하게 이용할 수 있다는 것을 잊지만 말자!

[참고]
1. TcpIndex 다운로드
http://www.gotomanage.com/open_source_tools/tcpindex_thankyou
2. Lucene 쿼리 파서 문법
http://lucene.apache.org/java/2_3_2/queryparsersyntax.html
3. Clucene
http://clucene.sourceforge.net/

자동화된 패킷분석의 어려움을 이야기 해보자!

패킷분석을 주 업무로 하는 사람이라면, 그들만의 도구를 가지고 있거나 방법이 있을 것이다. 특히나 분석할 패킷파일 대상이 많다면, 더욱 더 자동화된 기능이 필요하다. 하지만, 자동화된 방법으로 개발하여 사용하다 보면 어려움이 많이 발생할 경우가 많다. 대표적인 것이, 주어진 프로토콜 형식에 맞지 않는 패킷파일이다.

이건 보안적인 관점에서 봐도 발생되는 같은 이치인데, 대표적인 SQL Injection 을 생각해 보자.
웹 개발을 할때, 개발자가 생각한 것 이외의 값이 들어오지 않을 것이라 가정하고, 개발하면서 보안적인 문제점이 생긴다. 프로그램 관점에서 정해진 폼에 따라 사용자가 데이터를 입력하면 아무런 문제가 없을 것이다. 하지만, 사용자가 인자값을 직접 수정할 수도 있다는 가정이 되어야 한다. 인자값을 임의로 수정해 전송해 버리면, 프로그램에서는 그 값에 대한 체크가 없는 이상 사용자가 정상적으로 입력한 값으로 인지해 버려 SQL Injection 과 같은 취약점이 발생되어 버린다.

패킷파일도 마찬가지이다. 나 또한 보안적 관점에서 패킷 파일 분석을 수행하다 보면,이 패킷파일들이 별에별 형태로 다양하다는 것이다. 악성코드가 생성한 패킷파일이면 더욱 그러하다. 예를 들어, DNS 는 UDP 53 번을 기본으로 사용한다. 그리고 Zone Transfer 와 같은 상황등에서는 TCP 53 번을 사용하기도 한다. 흔히, UDP 53 번을 사용하면 DNS 데이터라고 가정한다. 그런데, DNS 가 아닌 어뚱하게도 어떤 통신을 위해 사용되는 것이라면 어떨까? DNS 쿼리 데이터의 일정 값을 사용하는데 이상하게도 알수없는 페이로드로 채워져 있다면 말이다.

패킷분석을 수행하는 도구 입장에서는 DNS 로 판별했는데, 실제 데이터가 정확하지 않아 Exception 과 같은 오류가 발생할 수 있다. 이런류의 패킷파일 데이터 판단은 힘들어지는데, 실제 이 패킷 데이터를 알아내기 위해서는 직접 악성코드를 리버싱을 해야 정확한 데이터 의미를 파악할 수 있게된다.

비정상적인 DNS 데이터를 가지고 있는 패킷파일을 Scapy 를 통해서 확인해 보면 아래와 같다.

>>> a=rdpcap("test_dns.pcap")
WARNING: wrong value: DNS.ancount=38440
WARNING: wrong value: DNS.nscount=27668
WARNING: more wrong value: DNS.arcount=45458
WARNING: DNS RR prematured end (ofs=73, len=44)
WARNING: DNS RR prematured end (ofs=77, len=44)
WARNING: more DNS RR prematured end (ofs=81, len=44)

자 일단 읽어 들이는 과정에서도 경고 메시지가 나타난다. DNS 의 ancount 나 nscount 값이 지나치게 크게 나온다는 것이다.

>>> a
<test_dns.pcap: TCP:6 UDP:1115 ICMP:0 Other:28>

다음은 패킷파일 중 정상적인 DNS 패킷 데이터를 본 것이다.

>>> a[1145]
<Ether  dst=[삭제] src=[삭제] type=0x800 |<IP  version=4L ihl=5L tos=0x0 len=68 id=956 flags= frag=0L ttl=128 proto=udp chksum=0x52c9 src=[삭제] dst=[삭제] options=[] |<UDP  sport=1039 dport=domain len=48 chksum=0xfdec |<DNS  id=52467 qr=0L opcode=QUERY aa=0L tc=0L rd=1L ra=0L z=0L rcode=ok qdcount=1 ancount=0 nscount=0 arcount=0 qd=<DNSQR  qname='1.1.1.1.in-addr.arpa.' qtype=PTR qclass=IN |> an=None ns=None ar=None |>>>>

정상적인 형태는 각 필드정보가 정확히 확인이 된다. 그런데, 아래의 경우를 보면 다르다.
몇몇 필드의 데이터 값이 이상하고, Raw 페이로드 값이 존재한다.

>>> a[176]
<Ether  dst=[삭제] src=[삭제] type=0x800 |<IP  version=4L ihl=5L tos=0x0 len=84 id=16541 flags= frag=0L ttl=24 proto=udp chksum=0xfe73 src=[삭제] dst=[삭제] options=[] |<UDP  sport=domain dport=7783 len=64 chksum=0xf167 |<DNS  id=56 qr=0L opcode=QUERY aa=0L tc=1L rd=1L ra=0L z=1L rcode=server-failure qdcount=0 ancount=38440 nscount=27668 arcount=45458 qd=None an='' ns='' ar='' |<Raw  load='$\xabn\x00z\xb6\x0bl\x98Q\xff\x87\xf9\xe2\xd0\xaeu\xa2[삭제]0305rh\x02\xbe\x18\xc0\x00\x00' |>>>>>
>>>

HEX 값을 확인해 보면 아래와 같다.

>>> hexdump(a[176][Raw])
0000   24 AB 6E 00 7A B6 0B 6C  98 51 FF 87 F9 E2 D0 AE   $.n.z..l.Q......
0010   75 A2 [삭제] 3 37 37 42   u..[삭제]C77B
0020   30 33 30 35 72 68 02 BE  18 C0 00 00               0305rh......

ancount, nscount 가 이렇게 큰 데이터를 가질 수 있는가? 즉, 큰 데이터 값만 보고도 조작된 패킷 가능성이 크다고 볼 수 있다. 그러므로 Scapy 에서도 로드할때 경고 메시지가 나타난다. UDP/53 번에 패킷을 전송하니 이것을 DNS 패킷으로 인식하고 그 값 데이터를 필드 값으로 사용하면서 엉뚱하게 이상한 값으로 설정된 것이다.

이와 같은 경우에는 다양한 Exception 처리를 해 주어야 하는데, 어떤 형태가 들어오기 예측하기 쉽지 않다보니 특수한 환경의 패킷 분석에서는 상당한 어려움이 발생할 수 있다. 이러한 이유로 어떤 자동화된 형태로 패킷을 분석 처리하기에는 많은 경험도 필요하고, 각각의 상황에 따라 처리도 해주어야 하다 보니 안정화 되기까지는 시간도 필요하다. 물론, 안정화 후에도 계속 이런 가능성은 존재하게 된다.  사용하려는 목적은 다르겠지만, 완벽하게 패킷 데이터를 분석하여 사용한다는 관점보다는 좀더 쉽게 패킷 분석가를 도와준다는 관점에서 생각하고 사용하면 이런 작업을 진행하는 분들에게는 좀더 마음이 편해지지 않을까?

/Rigel

와이어샤크 1.6.0 버전 공개 - 1.4.X 사용자 분들은 업데이트를 ~

와이어샤크 1.6.0 이 릴리즈 되었다. 그간 보았던 1.5.X 버전은 사라지고, 1.4.X 의 Stable 버전에서 1.6.X Stable 버전이 릴리즈 된 것이다. 이번 버전은 1.6.X 버전대의 첫 번째 릴리즈 이며, 앞으로 Stable 버전인 1.4 버전대를 대체하게 될 것이다.

일단 이번 버전에서는 그간 알려진 버그들이 픽스 되었고, 1.4 와 달리 다음과 같은 새로운 기능 추가 및 변화가 있다.

- 큰 파일(2기가 이상) 지원 기능이 향상
- text2pcap 과 같이 와이어샤크와 Tshark 에서 텍스트 덤프파일 Import
- SSL 세션 키 Export
- 패킷 리스트에서 컬럼 숨기기
- SMB 오브젝트 Export
- dftest, randpkt 맨 페이지 추가 (randpkt 는 패킷 인사이드에 소개되었던 적이 있다)
- 패킷 길이 표시가 기본 컬럼으로 설정
- 그래프 기본 저장 포맷이 PNG 방식으로 변경
- 이외 기타 등등

프로토콜도 새롭게 몇가지 추가 지원하고 있다.

[윈도우 32비트]
http://wiresharkdownloads.riverbed.com/wireshark/win32/wireshark-win32-1.6.0.exe
[윈도우 64 비트]
http://wiresharkdownloads.riverbed.com/wireshark/win64/wireshark-win64-1.6.0.exe

릴리즈 된 세부 정보는 다음 문서를 참고한다.

http://www.wireshark.org/docs/relnotes/wireshark-1.6.0.html

현재 개발버전은 1.6.0rc2 버전이다.

앞으로 패킷인사이드에서도 와이어샤크 기능은 1.6.X 버전에 맞춰서 소개될 것이다. 지금 이 포스팅을 보고 있는 사용자라면, 지금 1.6.0 으로 업데이트 하여 안정된 새로운 버전의 기능을 느껴보기 바란다. : )

WinPcap 4.1.2 버전 릴리즈

WinPcap 이 2009년 10월 말 이후로, 최근에 (2010년7월2일) 업데이트 되었다. 참 오랜만의 업데이트 이다.

WinPcap 4.1.2 버전이며 다운로드는 아래의 경로에서 할 수 있다.

http://www.winpcap.org/install/default.htm#graph_installer4_1_2

이번 릴리즈에서는 몇몇 OS 에서 발생되었던 Crash 의 원인인

드라이버의 버그가 픽스 되었다. 이번 버전의 주요 변경된 내용은

ChangeLog 를 확인해 볼 수 있다.

http://www.winpcap.org/misc/changelog.htm#changelog_4_1_2

업데이트가 귀챦으신 분들은 그냥 넘어가도 되겠다. 큰 Major 변화는 있지 않기 때문이다.

와이어샤크(WireShark)의 그래프 기능 활용하기 - 고급편

그래프 기능 활용 기본편에 이어 이번에는 조금더 고급적으로 쓸 수 있는 방법을 소개하겠다. 와이어샤크의

IO Graph 기능을 단순히 와이어샤크로만 한정하지 않고 다른 방법을 통해 그래프도 좀도 이쁘게 만들 수 있는

방법과 그래프 생성시 SUM, MAX 와 같은 함수를 이용한 그래프 생성 방법이다.

자 일단, 아래의 그림을 살펴보자. 이것은 그래프를 생성할때 Y Axis 에서 Unit 을 Advanced 로 선택하면

Calc 라는 추가 입력을 볼 수 있다. 즉, 합을 구하거나 최대, 최소, 평균 값등을 계산할 때,

이 방법을 사용하면 유용하게 이용할 수 있다. 특정 프로토콜에서 계산이 가능한 값이 있을 경우, 함수를 통해

그래프를 생성하면 좀더 의미있는 형태로 만들 수가 있는 것이다. 아래 예제에서는 http.content_length (빨간색)을 바로 표현했고, 프레임 길이를 녹색으로 그리고 IP 프로토콜의 TTL 을 합산으로 사용해 보았다.

frame.len 을 보면 01:50:57 부터 일정하게 높은 수치가 유지되고 있고 있다. 이뜻은 이 시간에 전송한 패킷 프레임의 길이가 일정하게 큰 수준으로 계속 이어졌다는 것이다.

또한 그래프 화면에서 해당 지점을 클릭하면 어떤 패킷을 가르키는지 와이어샤크의 출력화면이 해당 패킷으로 움직이게 된다. 그래프를 보고서 의심스러운 지점을 찾아 쉽게 볼 수 있는 것이다.

위 화면은 여러분들에게 소개를 하기 위해 임의로 계산을 한 것이지만, 여러분들이 분석하고자 하는 데이터에

따라 사용한다면 아주 유용한 그래프가 될 것이다.

자, 다음으로는 앞서 기본편에서 언급한 IO Graph 에서 Copy 명령을 통해 CSV 형태로 저장할 수 있다고 설명하였다. Copy 를 누른 후 보면 각 데이터는 콤마(,) 로 구분되어 나열되어 있다. 이렇게 저장한 CSV 를 어떻게 활용할 수 있을까 ? 그렇다. 바로 CSV 를 지원하는 도구를 이용하면 그래프를 더욱 멋지게 생성할 수 있는 것이다. 우리가 업무에서 많이 활용하고 있는 엑셀(Excel) 을 예로 들어보자. 아래의 그래프 화면은 엑셀을 이용하여 만들어 본것이다. 엑셀에서 해당 파일을 로드할때 CSV 형태로 로드하면서 구분자는 콤마로 지정한다. 그러면 엑셀에서 원하는 영역을 선택하여 그래프로 만들어주면 아래와 같이 멋진 그래프로 탄생한다.

엑셀을 자유롭게 다루는 분이라면 훨씬 멋진 그래프 화면을 만들어 낼 수가 있을 것이다. 또 다른 예제로 오픈오피스를 이용한 그래프 생성에 대해서도 소개하고자 한다. 이 내용은 아래 주소에서 본 슬라이드를 보고서 소개하는 것이다.

http://www.slideshare.net/LoveMyTool/ostu-customized-wireshark-graphics-with-open-office-by-tony-fortunato

필자는 주로 오픈소스를 사용하기를 원하는데, 적절한 소개인것 같다. 이번에도 마찬가지로, 똑같이 CSV 데이터를 이용하는 것이다. CSV 데이터를 이용하는 부분은 와이어샤크의 메인 화면에 출력되는 컬럼을 이용하는 것이다.

와이어샤크 메인의 기본 컬럼 구성은

번호, 시간, 출발지, 목적지, 프로토콜, 정보 로 구성된다. 이 화면에 출력된 내용을 CSV 로 저장할 수 있는 것이다. 그런데 기본 컬럼을 바꿀 수 있다는 사실을 알고 있을 것이다. Edit->Preference 를 선택하고 Columns 를 보면 된다. 바로 여기에서 아래 부분의 필드타입을 Packet length (bytes) 를 선택하고 Add 를 눌러보자. (컬럼 이름은 Length 라고 정의하였다)그러면 컬럼에 패킷의 길이가 추가된다. 여기 예에서는 패킷 길이를 선택하였지만, 원하는 형태로 선택할 수 있다.

자, 그리고 CSV 데이터를 얻기 위해 File -> Export -> File 을 선택해 보자. 아래 화면과 같이 파일 형식을 CSV 로 선택하고 저장할 파일이름을 적고 저장을 누른다.

이제, 우리가 사용할 데이터를 얻었으니 오픈오피스를 통해 그래프를 생성해 주는 일만 남았다. 오픈오피스 Calc 를 일단 실행하고 파일오픈을 선택하자. * 오픈오피스는 openoffice.org 에서 받을 수 있다.

파일 오픈시 읽어들일 데이터를 CSV 로 선택후 오픈하면 CSV 로 파싱할 화면이 나타난다. 그리고 구분자로 Comma 로 선택하면 필드가 제대로 나뉘어 진다.

그러면 엑셀 형태와 같이 데이터가 기록이 된다. 그래프를 생성해 내고자 하는 형태는 시간별로 얼마나

많은 패킷 데이터가 전송되었는지를 표현하기 위해서이다. 그래서, 앞서 와이어샤크에서 컬럼을 추가해

각 패킷 길이 컬럼을 추가한 것이다.

필요한 컬럼은 시간과 패킷 길이(바이트) 이다. 그런데 라인수가 엄청나다. 아무래도 시간대 별로 한개씩

다 기록되어 있으니 말이다. 그래서 활용하는 방법이 Subtotals 기능을 이용하는 것이다. 시간 컬럼을 기준으로

Length 의 합을 구하는 것이다. 아래 화면과 같이 Group by 에서 Time 을 선택하고 Subtotals 대상인 Length 를 선택후 사용할 기능으로 Sum 을 선택한다.

그러면 화면의 왼쪽 부분에 선 같은 것이 생길것이다. 거기서 2번을 눌러보면 아래 그림과 같이 만들어 진다. 이 화면에서는 불필요한 컬럼은 다 삭제하였고, 시간 부분에 합산을 하고 나면 12시36분27초 Sum 과 같이 생긴다. 이때는 Edit 기능에 있는 Find & Replace 기능을 활용해 변경할 문자열을 Sum 을 선택하고 대상 문자열을 공백으로 두고 Replace 를 눌러버리면 말끔하게 삭제할 수 있다.

이제 마지막까지 왔다. 드디어 그래프를 생성하기 위해 열을 선택하고 Insert 메뉴에서 Chart 를 선택하거나, 메인 화면의 차트 아이콘을 클릭하면 된다. 그리고서 생성을 하면 멋진 그래프가 만들어진다.

비록 하나의 그래프를 생성하기 위해 많은 사전 작업을 거쳤지만, 모든걸 무료로 사용할 수 있다는 점이 매력적이지 않은가? 와이어샤크의 그래프 생성이 비주얼 적으로 이쁘지는 않지만, 데이터를 CSV 로 저장하여 활용한다면 어느 프로그램보다도 멋지게 그래프를 생성할 수 있다.  여기서는 여러분들에게 소개하기 위해서 그래프가 볼품이 없을지도 모르지만, 그건 여러분들이 그래프 생성하는데 얼마나 시간을 쏟느냐에 따라 달려있는 것이다.

와이어샤크의 수 많은 데이터를 이용해서 멋진 그래프를 이제 생성할 수 있다는 사실 !

이제 여러분도 와이어샤크 만으로도 멋진 패킷 분석 보고서를 만들어 낼 수 있을 것이다.

멋진 그래프를 생성한다면 댓글을 달아주세요. 다른 분들과 공유할 수 있도록 예제로 소개해 드리겠습니다.

Good Luck to you!