레이블이 libpcap인 게시물을 표시합니다. 모든 게시물 표시
레이블이 libpcap인 게시물을 표시합니다. 모든 게시물 표시

2013년 7월 25일 목요일

차세대 패킷 포맷, Pcap-NG 를 알고싶다 _ 첫번째 이야기

저번 포스팅에서 pcap-ng 를 pcap 으로 그리고 pcap 을 pcap-ng 로 변환하는 방법에 대해서 소개했습니다. 오늘은 말씀드렸던것과 같이 차세대 패킷 저장 포맷인 pcap-ng 를 자세히 알아보고자 합니다. 첫번째로, pcap-ng 의 주요한 특징/기능 에 대해서 말씀드리겠습니다.

차세대 패킷 저장 포맷을 만들시 고려사항, 즉 최종 목표는 다음과 같습니다.

- Extensibility
- Portability
- Merge/Append data

확장성도 좋아야 하고 패킷 파일을 덤프한 곳에 대한 최대한 많은 정보를 포함시키고 데이터를 통합하거나 추가하기도 유연해야 했습니다. 이렇게 해서 디자인 된 것이 pcap-ng 입니다.

주요한 사항들에 대해서 아래와 같이 적어보았습니다.

- 와이어샤크 1.8 에서 기본 파일 포맷이 Pcap-NG 로 변경됨
- Tcpdump 버전 4.1.1 이상에서 Pcap-NG 를 지원
- NTAR(Network Trace Archival and Retrieval) 로 불리기도 함
- Pcap-NG 에서 메타 데이터를 포함할 수 있음 (운영체제, 패킷 캡쳐 프로그램, 캡쳐 필터 등)

<주요특징>

- 한개의 파일에 여러개의 인터페이스 트래픽이 캡쳐되어 저장될 수 있습니다. 인터페이스가 다른 형태의 데이터 링크 타입이라도 가능합니다. 예를들어 802.11, PPP 를 동시에 저장하는 것이 가능하게 되었습니다.

- 메타데이터 정보 기록이 가능합니다. 어떤 운영체제, 하드웨어 인지, 캡쳐 프로그램에 사용한 패킷 캡쳐 프로그램과 같은 정보로 와이어샤크와 dumpcap 은 Pcap-NG로 저장할때 자동생성합니다.

- 패킷 시간 기록 한계가 해결되었습니다. 현재 10^6 의 마이크로세컨드를 이용하여 표현을 하다보니 초당 999,999 개 이상의 패킷 시간 기록에 한계가 있습니다. 오늘날과 같은 1기가 이상의 고속 네트워크에서는 이 비율을 쉽게 초과하므로 문제가 있죠. pcapng 에서는 64비트 시간을 이용하여 표현하게 되어 이런 문제를 해결할 수 있습니다. 아래 화면은 10g 구간에서 패킷 덤프를 한 것으로 같은 타임스탬프가 찍히는 것을 볼 수 있습니다. 바로 이런 문제가 극복된 것이죠.
[Image]
[Image Source] CESNET

- 각 개별 프레임마다 코멘트가 기록되어 저장될 수 있습니다. 와이어샤크에서 필터이름 "pkt_comment" 로 출력이 가능합니다. 예를들어, tshark -r test.pcapng -T fields -e pkt_comment -R pkt_comment 로 사용하면 코멘트를 출력할 수 있습니다.

- 유연한 파일포맷을 제공하여 해당 포맷을 이용하는 소프트웨어에서 유연하게 사용할 수 있게 되었습니다. 포맷 형태가 블럭별로 되어 있어 필요치 않은 블럭은 제외되어도 패킷 포맷을 처리하는데 문제가 없게 되었고 이것은 도구에서 제공하는 기능상황에 따라 유연한 포맷형태로 사용가능하다는 뜻입니다.

- 각 인터페이스에 대한 메타 정보가 기록되어 있습니다. 이런 정보는 인터페이스 이름, 손실된 패킷, 캡쳐 필터 정보가 해당됩니다.

너무 길게 설명하면 지루하니 오늘은 pcap-ng 의 특징들 까지만 알아보고 다음번에 포맷에 대해서 좀더 알아보겠습니다.

[참고]
[1] PCAPNG 파일 포맷
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
[2] 차세대 패킷 포맷 PCAP-NG 를 PCAP 으로 쉽게 변환하기
http://www.packetinside.com/2013/07/pcap-ng-pcap.html

2013년 3월 8일 금요일

DaemonLogger 로 패킷 덤프를 쉽게 해보자

간단한 패킷 로그 데몬인 DaemonLogger 를 소개합니다. 다운로드는 Snort 사이트에서 받을 수 있고 현재 버전은 1.2.1 입니다. (예전에 소개한거 같은데 기억이 안나네요. 아무리 찾아도 쓰여졌던 기록은 없네요 ^^)

http://www.snort.org/snort-downloads/additional-downloads#daemonlogger

libpcap 기반으로 만들어져 있으며 크게 2가지 기능을 가지고 있습니다. 첫번째는 일반적으로 패킷을 스니핑 해서 디스크에 기록을 하며,  1G 가 되면 파일을 새롭게 만듭니다. 두번째는 패킷을 다시 Rewrite 하여 다른 인터페이스로 보내는 기능으로 소프트웨어적인 Tapping 과 같다고 할 수 있습니다.

나온지는 사실 오래되었긴 한데, 패킷 덤프만 필요로 하거나 공부할 목적으로 보신다면 괜챦습니다. 설치는 libpcap 과 libdnet 이 있으면 컴파일에 큰 문제가 없습니다.

# ./configure
# make

기본 도움말은 다음과 같습니다.

# ./daemonlogger -h
USAGE: daemonlogger [-options] <bpf filter>
        -c <count>      Log <count> packets and exit
        -d              Daemonize at startup
        -f <bpf file>   Load BPF filter from <bpf file>
        -F              Flush the pcap buffer for each packet
        -g <group name> Set group ID to <group name>
        -h              Show this usage statement
        -i <intf>       Grab packets from interface <intf>
        -l <path>       Log to directory <path>
        -m <count>      Generate <count> log files and quit
        -M <pct>        In ringbuffer mode log data to <pct> of
                        volume capacity
        -n <name>       Set output filename prefix to <name>
        -o <outf>       Disable logging, retransmit data from
                        <intf> to <outf>
        -p <pidfile>    Use <pidfile> for PID filename
        -P <pidpath>    Use <pidpath> for PID directory
        -r              Activate ringbuffer mode
        -R <pcap file>  Read packets from <pcap file>
        -s <bytes>      Rollover the log file every <bytes>
        -S <snaplen>    Capture <snaplen> bytes per packet
        -t <time>       Rollover the log file on time intervals
        -u <user name>  Set user ID to <user name>
        -v              Show daemonlogger version


아무런 옵션없이 실행하면 바로 패킷 덤프가 시작됩니다.

# ./daemonlogger
[-] Log filename set to "daemonlogger.pcap"
[-] Pidfile configured to "daemonlogger.pid"
[-] Pidpath configured to "/var/run"
[-] Rollover size set to 18446744071562067968 bytes
[-] Rollover time configured for 0 seconds
[-] Pruning behavior set to oldest IN DIRECTORY

-*> DaemonLogger <*-
Version 1.2.1
By Martin Roesch
(C) Copyright 2006-2007 Sourcefire Inc., All rights reserved

sniffing on interface eth0
Logging packets to daemonlogger.pcap.1362698542


따로 경로를 지정하지 않았다면 현 경로에 daemonlogger.pcap.[타임스탬프] 형태로 기록이 됩니다. 몇가지 주요 기능들을 한번 보면 다음과 같습니다.

-c 는 몇개의 패킷을 기록하고 빠져나갈것인지 정의합니다. -d 는 백그라운드로 데몬 형태로 동작합니다. -f 를 통해 BPF 필터가 적용된 파일을 로드할 수 있고 -i 로 패킷 덤프할 인터페이스 그리고 -l 로 기록될 로그 파일 경로를 설정합니다. -s 는 얼마 크기로(바이트 단위) 파일을 롤오버할지 지정하고 -t 는 시간 인터벌로 롤오버를 할 수 있습니다. -n 은 파일이름으로 사용할 것을 지정하는데 기본은 damonlogger.pcap 입니다. -n packetinside 라고 지정하면 packetinside.1362698110 과 같이 생성이 됩니다.

그리고 말씀드렸던 두번째 주요기능으로 다른 인터페이스에 재 전달할 수 있다고 드린 기능은 -o 로 인터페이스를 지정하면 됩니다. 즉 이것은 데이터를 기록하지 않고 바로 지정된 인터페이스로 전달합니다.

# ./daemonlogger -i eth0 -o eth2

간단한 도구라서 쉽게 사용할 수 있으니 참고하세요. 참고로 이와 비슷한 도구들을 블로그에서 많이 소개하였으니 다른 것도 살펴보세요.

즐거운 주말 보내세요 ;-)

[참고]
1. Libdnet
http://libdnet.sourceforge.net/

2012년 10월 10일 수요일

내 시스템에 설치된 Libpcap 버전 확인하기

과연 내 시스템에는 어떤 버전의 Libpcap 이 설치되어 있는 것인가? 필요에 따라 PCAP 라이브러리 버전 확인이 필요한 경우가 있다. 이럴때 쉽게 확인할 수 있는 방법 몇 가지를 적어본다.

1) ls 명령어로 라이브러리 디렉토리 살펴보기 

$ ls -l /usr/lib/*pcap*
or
$ ls -l /usr/lib/i386*/*pcap*

/usr/lib/i386-linux-gnu/libpcap.so.0.8
/usr/lib/i386-linux-gnu/libpcap.so
/usr/lib/i386-linux-gnu/libpcap.a
/usr/lib/i386-linux-gnu/libpcap.so.1.1.1

이 상황은 시스템에 따라 많이 달라질 수 있으므로, find 를 이용해 검색해 보아도 된다. 여기 예에서는 1.1.1 버전과 0.8 버전이 있는 것으로 추정할 수 있다.

2) 패키지 프로그램을 이용해 확인하기 

rpm 을 사용한다면 다음과 같이 pcap 문자열로 확인해 본다.


$ rpm -qa | grep pcap

데비안 계열이라면

$ apt-cache pkgnames | grep pcap

를 통해 설치되어 있는 패키지를 확인하고 출력되는 패키지 이름을 보고

$ apt-cache showpkg libpcap-dev

와 같이 세부적으로 살펴볼 수 있다.

3) ldconfig 를 통해 라이브러리 링크 연결을 확인해 본다.

$ ldconfig -p | grep pcap

4) libpcap 라이브러리를 이용해 직접 버전을 출력해 본다.

다음과 같이 pcap_lib_version() 을 이용하면 버전이 확인가능하다. 아래와 같이 간단하게 코딩하여 실행해 볼 수 있다.


#include <pcap/pcap.h>

int main() {

        const char *pcap_v;
        pcap_v = pcap_lib_version();

        printf("Libpcap Version: %s \n", pcap_v);

}

# gcc libpcap_ver.c -lpcap
# ./a.out
Libpcap Version: libpcap version 1.1.1

1.1.1 버전을 사용하고 있음을 확인할 수 있다.

2011년 9월 16일 금요일

네트워크 트래픽 모니터링 도구 - DarkStat


네트워크 트래픽 상태를 살펴볼 수 있는 도구인 'darkstat' 를 소개한다. 기존에 소개하였던 콘솔 기반의 모니터링 도구가 아닌 웹 기반으로 트래픽 상태 정보를 살펴볼 수 있다. 간단하게 실행시켜 놓고, 브라우저를 통해 트래픽 양을 그래프로 쉽게 알 수 있다.

프로그램 자체의 크기도 크지 않고, 작고 안정적이며, 웹 서버 기능을 내장하고 있어서 앞서 언급했듯이 브라우저를 통해 정보를 확인할 수 있는 것이 장점이다. 이외 트래픽 그래프, 호스트별 보고기능, 호스트별 발생한 포트 정보등이 제공된다.

일단, 해당 정보에 대한 것은 다음 사이트를 방문하면 된다.

http://unix4lyfe.org/darkstat/

소스 컴파일도 아래와 같이 configure 를 통해 쉽게 컴파일이 가능하다.

# ./configure
# make
or
# apt-get install darkstat

설치된 후 실행은 네트워크 인터페이스 정도 지정하는 것 정도로 실행할 수 있다.

# darkstat -i eth0

포트번호를 지정한다면,

# darkstat -i eth0 -p 8080 과 같이 하면 된다.

이후, 브라우저를 통해 8080 포트를 접속해 보면 네트워크 상태 정보를 볼 수 있다.

기본적인 사용은 -i or -p 옵션 정도만 지정하여도 충분하고, 이외 추가적으로 사용 가능한 옵션들이 더욱 많은 아래 기본 사용방법만 보아도 대충 어떤 기능인지 추측이 가능할 것이다. 자세한 것은 'man darkstat' 를 통해 보면 세부적으로 알 수 있다.


# darkstat
darkstat 3.0.713 (built with libpcap 2.4)

usage: darkstat [ -i interface ]
                [ -r file ]
                [ --snaplen bytes ]
                [ --pppoe ]
                [ --syslog ]
                [ --verbose ]
                [ --no-daemon ]
                [ --no-promisc ]
                [ --no-dns ]
                [ --no-macs ]
                [ --no-lastseen ]
                [ -p port ]
                [ -b bindaddr ]
                [ -f filter ]
                [ -l network/netmask ]
                [ --chroot dir ]
                [ --user username ]
                [ --daylog filename ]
                [ --import filename ]
                [ --export filename ]
                [ --pidfile filename ]
                [ --hosts-max count ]
                [ --hosts-keep count ]
                [ --ports-max count ]
                [ --ports-keep count ]
                [ --highest-port port ]
                [ --wait secs ]
                [ --hexdump ]

Please refer to the darkstat(8) manual page for further
documentation and usage examples.

이 도구는 전체적인 트래픽 현황등을 파악하는 용도지, 와이어샤크와 같이 패킷을 분석하는 도구는 아니다. 즉, 이런 형태의 모니터링 도구를 통해 이상상황등을 감지하는데는 유용하게 사용할 수 있다.

2011년 7월 28일 목요일

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 는 베타 릴리즈 상태이다.

[다운로드]

2011년 5월 24일 화요일

PCAP 파일에서 TCP 스트림 정보를 쉽게 다루기

패킷파일에서 스트림 정보를 좀더 쉽게 볼 수 있는 도구가 있다. 'streams' 라는 것으로 pcap 파일에서 TCP 스트림 정보를 브라우징 해서 볼 수 있도록 도와주는 것이다. 각 세션 정보를 Interactive 하게 볼 수 있으며, pipe 를 통해 스트림 정보를 외부로 호출할 수 도 있다.
일단, 다음의 경로에서 다운로드 받을 수 있다.

http://src.carnivore.it/streams/

파일을 받아 압축을 풀고 컴파일을 해야 하는데, 약간은 불편하게 되어 있다. configure 파일을 생성하고 해야 하는데, 에러가 발생하여 바로 src/ 안에서 직접 컴파일을 하였다.

컴파일을 하기 위해서는 Libpcap 이 당연히 설치되어 있어야 하고, Interactive 하게 커맨드 사용이 가능하여야 해서 readline 라이브러리도 필요하다. 이 2가지만 갖춰져 있으면 다음과 같이 컴파일을 하면 된다. (에러가 발생하는데, 소스파일에 VERSION 정보가 define 되어 있지 않아서 발생한다. 소스코드에 define 으로 VERSION 정보만 입력해 준다)

gcc cmd.c hash.c sig.c streams.c strm.c util.c -I/usr/include/readline -lpcap -lreadline

그러면 a.out 파일이 생성된다. -o 옵션을 이용해 바로 streams 로 바이너리를 생성해도 된다.
컴파일된 파일을 실행해 보면 아래 화면과 같이 볼 수 있다.


PCAP 파일을 테스트해 보기 위해 43개의 패킷이 들어있는 임의의 패킷파일을 선정하였다. 패킷 파일의 정보를 보면 아래와 같다. (와이어샤크에서 받을 수 있는 샘플 패킷 데이터를 이용하였는데, 덤프된 시간이 2004 년이다^^ )


File type:           Wireshark/tcpdump/... - libpcap
File encapsulation:  Ethernet
Number of packets:   43
File size:           25803 bytes
Data size:           25091 bytes
Capture duration:    30 seconds
Start time:          Thu May 13 19:17:07 2004
End time:            Thu May 13 19:17:37 2004
Data byte rate:      825.53 bytes/sec
Data bit rate:       6604.26 bits/sec
Average packet size: 583.51 bytes
Average packet rate: 1.41 packets/sec


일단 실행된 상태에서 패킷을 로드하기 위해 analyze 명령어를 사용한다. http.cap 을 로드하였더니 2개의 스트림을 볼 수 있다. list 명령어는 스트림된 화면을 출력한다. 전체 패킷이 42개 였는데, 스트림된 형태로 요약해 보면 아래와 같이 2개라는 것이다. 하나가 479 바이트 나머지는 18,364 바이트다.

streams>
streams> analyze ./http.cap
file processed, 2 streams (2 non-empty and complete).
streams> list
    0:       0.000000      30.063228  145.254.160.237:3372 > 65.208.228.223:80 (479 bytes)
    1:       0.911310      17.905747  65.208.228.223:80 > 145.254.160.237:3372 (18364 bytes)
streams>

패킷내용을 살펴보기 위해 ext 로 외부 기능을 호출해 본다. hd 를 호출하면 되는데 hd 가 무엇인가 해서 util.c 를 보았더니 HEX DUMP 형태로 출력해 주는 기능을 가진 것이다.


void hd(const u_char *data, size_t len) {
        register int i, j;

        if (!data || !len) return;

        for (i = 0; i < len; i += 0x10) {
                printf("0x%08x  ", i);

                for (j = 0; j < 0x10 && i+j<len; j++) {
                        if (j == 0x8) putchar(' ');
                        printf("%02x ", data[i+j]);
                }

                printf("%-*c|", (3 * (0x10 - j)) + (j > 0x8 ? 1 : 2), ' ');

                for (j = 0; j < 0x10 && i + j < len; j++)
                        putchar(isprint(data[i+j]) ? data[i+j] : '.');

                puts("|");
        }
        putchar('\n');

        return;
}


호출하면 pipe 로 그 정보를 넘기는데 0 번째 정보를 보고자 하면 pipe 0 을 한다.

streams> ext hd
streams> pipe 0
479 bytes written (479 in total)
00000000  47 45 54 20 2f 64 6f 77  6e 6c 6f 61 64 2e 68 74  |GET /download.ht|
00000010  6d 6c 20 48 54 54 50 2f  31 2e 31 0d 0a 48 6f 73  |ml HTTP/1.1..Hos|
00000020  74 3a 20 77 77 77 2e 65  74 68 65 72 65 61 6c 2e  |t: www.ethereal.|
00000030  63 6f 6d 0d 0a 55 73 65  72 2d 41 67 65 6e 74 3a  |com..User-Agent:|
00000040  20 4d 6f 7a 69 6c 6c 61  2f 35 2e 30 20 28 57 69  | Mozilla/5.0 (Wi|
00000050  6e 64 6f 77 73 3b 20 55  3b 20 57 69 6e 64 6f 77  |ndows; U; Window|
00000060  73 20 4e 54 20 35 2e 31  3b 20 65 6e 2d 55 53 3b  |s NT 5.1; en-US;|
00000070  20 72 76 3a 31 2e 36 29  20 47 65 63 6b 6f 2f 32  | rv:1.6) Gecko/2|
00000080  30 30 34 30 31 31 33 0d  0a 41 63 63 65 70 74 3a  |0040113..Accept:|
00000090  20 74 65 78 74 2f 78 6d  6c 2c 61 70 70 6c 69 63  | text/xml,applic|
000000a0  61 74 69 6f 6e 2f 78 6d  6c 2c 61 70 70 6c 69 63  |ation/xml,applic|
000000b0  61 74 69 6f 6e 2f 78 68  74 6d 6c 2b 78 6d 6c 2c  |ation/xhtml+xml,|

그러면 0번째의 정보를 볼 수 있는 GET 방식으로 다운로드 하는 헤더 정보를 볼 수 있다.
그리고 이런 정보를 파일로 저장하기 위해서는 outfile 로 저장할 파일 이름을 지정해 주고 , dump 로 저장할 스트림 번호를 지정하면 된다.

streams> outfile ./http.bin
streams> list
    0:       0.000000      30.063228  145.254.160.237:3372 > 65.208.228.223:80 (479 bytes)
    1:       0.911310      17.905747  65.208.228.223:80 > 145.254.160.237:3372 (18364 bytes)
streams> dump 1
18364 bytes written to ./http.bin

저장된 파일을 보면 18,364 바이트를 확인할 수 있으며, 해당 텍스트 내용이 기록되어 있다.


$ ls -l http.bin
-rw-r--r-- 1 rigel rigel 18364 2011-05-20 23:42 http.bin
$ head http.bin
HTTP/1.1 200 OK
Date: Thu, 13 May 2004 10:17:12 GMT
Server: Apache
Last-Modified: Tue, 20 Apr 2004 13:17:00 GMT
ETag: "9a01a-4696-7e354b00"
Accept-Ranges: bytes
Content-Length: 18070
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=ISO-8859-1


다시 streams 로 돌아와서 필터정보를 사용해 보자. match 라는 명령어를 이용하면 되고, 아래 예는 GET 으로 필터를 건 것이다.

streams> match GET
applying new match expression...
streams> list
    0:       0.000000      30.063228  145.254.160.237:3372 > 65.208.228.223:80 (479 bytes)
streams>

그리고 status 정보는 현재의 상태 정보를 보여준다.

streams> status

  trace file:           ./http.cap
  bpf expression:       tcp
  match expression:     GET
  stream filter:        off (list all streams)
  time display mode:    relative
  external program:     hd
  output file:          ./http.bin

사용방법은 간단하며, 스트림화된 정보를 다루는 경우 유용하게 사용될 수 있다. 패킷파일을 다루는 도구는 다양하며, 업무 및 기타 사용목적에 따라서 필요한 도구는 달라진다. 앞으로도 다양한 도구를 소개할 예정이며, 여러분들에게 필요한 도구를 선택해 사용하면 된다.

지금 당장 이런것이 필요없더라도, 이런것이 있구나 하는 정도 알아두고 필요할때 패킷인사이드에서 검색해서 사용해 보자.

2011년 5월 17일 화요일

패킷캡쳐 라이브러리 Libpcap 의 MMAP 방식

오늘은 한번 Libpcap 이야기를 잠깐 꺼내볼까 한다. Libpcap 에서 사용하는 방법중에 하나가 Memory Mapped 방식의 MMAP 방식이다. 패킷이 커널로부터 유저 공간으로 포워딩 되는 방식이 아니라, 링버퍼를 이용한 것이다. 패킷 캡쳐 방식으로 가장 많이 이용하는 Libpcap 은 상위 레벨의 패킷 캡쳐 라이브러리이다. Tcpdump, Snort, Wireshark 등 많은 네트워크 패킷 관련 프로그램이 사용하고 있다.

Libpcap 은 네트워크 인터페이스 카드에 Promiscuous 모드 설정을 허용하며, 네트워크 카드에서 패킷을 커널로 포워드 시킨다. 커널의 패킷은 다시 PF_PACKET 소켓을 거쳐 유저 공간으로 까지 넘어와 사용할 수 있게 되는 것이다. libpcap 1.0.0 이상이면 MMAP 을 지원하고 있고, 리눅스 커널은 정확하지는 않지만 대략 2.6.27 부터인가 기본 설정으로 지원한다. 즉, 컴파일시

CONFIG_PACKET_MMAP=y 라는 것이다. 물론 그 이전 버전에서도 직접 설정하여 컴파일을 하면 사용할 수 있다.

만약, 여러분이 패킷 캡쳐 시스템으로 사용하는 시스템이 리눅스 이며, 오래된 커널 버전을 사용하고 있다면 이 부분도 한번 검토해 볼 필요가 있다. PACKET_MMAP 방식을 사용하지 않는 상태라면 성능이 저하되기 때문이다. 최근, 고속화되고 있는 네트워크 구조에 따라 10,100 메가를 넘어 기가비트는 기본이 되었다. 말은 쉽게 기가비트를 얘기하지만, 이런 네트워크 환경에서 패킷 덤프를 하는게 쉬운일 만은 아니다. 어떻게 하면 고속으로 패킷 손실 없이 패킷을 저장할 수 있을까 하는 연구가 계속되는 것이다. 전문적인 장비도 나오지만, 필자 입장에서는 일반적인 시스템 상에서 커널 파라미터를 어떻게 조정하고 또 어떤 방식을 통해 효율적인 패킷 모니터링을 구현할 수 있을까가 관심사다. 이런 부분은 앞으로도 차차 언급해 보도록 하겠다.

어찌되었든 여러분의 시스템에서 MMAP 버전을 사용하는지 확인하고 싶다면, 다음과 같이 알아볼 수 있다.

$ cat /proc/net/ptype
Type Device      Function
ALL  eth3     tpacket_rcv+0x0
ALL  dummy0   tpacket_rcv+0x0
0800          ip_rcv+0x0
0011          llc_rcv+0x0
0004          llc_rcv+0x0
0806          arp_rcv+0x0
86dd          :ipv6:ipv6_rcv+0x0

"tpacket_rcv" 가 보인다면 MMAP 버전을 사용하는 것이다. 만약 앞에 't' 가 없다면 MMAP 버전이 아니라 오래된 버전을 사용하는 것일 것이다. 아주 오래된 시스템만 아니면, 기본적으로는 많이 사용하고 있을 것이다.

[참고]
1. Linux Packet MMAP
http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap

2011년 4월 1일 금요일

와이어샤크의 또 다른 유틸리티, Rawshark 의 사용을 알아보자

와이어샤크를 설치하면 같이 배포되는 프로그램으로 Rawshark 가 있다. 주로 GUI 기반에서 사용한다면, wireshark 만을 실행해서 사용하기 때문 다른 유틸리티는 그냥 지나치는 경우가 많다.
Rawshark 이름만으로 추정해 보면, 로우 데이터를 본다는 의미로 추정된다. 이름과 같이 그 의미가 맞다. 로우 libpcap 데이터를 덤프 및 간단한 분석을 수행할 수 있는 기능을 가지고 있다.

우선, Rawshark 의 도움말을 살펴보면 아래와 같은 옵션 사용이 가능하다:

# rawshark -h
Rawshark 1.2.11
Dump and analyze network traffic.
See http://www.wireshark.org for more information.

Copyright 1998-2010 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Usage: rawshark [options] ...

Input file:
  -r <infile>              set the pipe or file name to read from

Processing:
  -R <read filter>         packet filter in Wireshark display filter syntax
  -F <field>               field to display
  -s                       skip PCAP header on input
  -n                       disable all name resolution (def: all enabled)
  -N <name resolve flags>  enable specific name resolution(s): "mntC"
  -d <encap:dlt>|<proto:protoname>
                           packet encapsulation or protocol
Output:
  -S                       format string for fields (%D - name, %S - stringval, %N numval)
  -t ad|a|r|d|dd|e         output format of time stamps (def: r: rel. to first)
  -l                       flush output after each packet

Miscellaneous:
  -h                       display this help and exit
  -v                       display version info and exit
  -o <name>:<value> ...    override preference setting

Rawshark 는 Tshark 와 달리 입력되는 데이터에 대한 정의가 필요하다. 그래서 무작정 실행해 보면 아래와 같은 로그를 보게된다.

# cat test.pcap | rawshark

rawshark: No valid payload dissector specified.


일반적인 형태의 사용과 약간 다르다 보니 혼돈이 오기도 하는데, 정상적으로 실행하기 위해서는 -d 와 -r 옵션을 사용해서 지정해 주어야 한다. 그리고 출력을 원하는 데이터가 있다면 -F 옵션으로 지정해 주어야 한다. Rawshark 는 기본적으로 다음과 같은 입력 레코드가 들어오는 것으로 판단한다. 많이 보던 레코드 형태일텐데, libpcap 에서 사용하는 pcap_pkthdr 구조와 데이터이다.

    struct rawshark_rec_s {
        uint32_t ts_sec;      /* Time stamp (seconds) */
        uint32_t ts_usec;     /* Time stamp (microseconds) */
        uint32_t caplen;      /* Length of the packet buffer */
        uint32_t len;         /* "On the wire" length of the packet */
        uint8_t data[caplen]; /* Packet data */
    };

libpcap 구조 관련해서는 다음 글을 읽어 보면 도움이 된다.

1) PCAP 파일을 파헤쳐 보자 - 그 첫번째 이야기
2) PCAP 파일을 파헤쳐 보자 - 그 두번째 이야기


일단 실행해보면 다음과 같은 형태로 출력이 가능하다.

# cat test.pcap | rawshark -d encap:EN10MB -r- -s -F ip.dst -F http.host
0 FT_IPv4 BASE_NONE - 1 FT_STRING BASE_NONE -
1 1="[FF02::C" -
2 -
3 -
4 0="168.126.63.1" -
5 0="192.168.0.240" -
6 0="168.126.63.1" -
7 0="192.168.0.240" -
8 0="72.14.213.99" -
9 0="192.168.0.240" -
10 0="72.14.213.99" -
11 1="www.goog" 0="72.14.213.99" -
12 0="192.168.0.240" -

일반적인 tcpdump 나 tshark 와 달리 실행방법이 약간은 복잡해 보인다. rawshark 는 입력을 스트림으로 받아 들이기 때문에 앞에서, cat 을 이용했다. 즉, test.pcap 의 내용이 cat 을 통해 읽어 들이고 이 출력을 rawshark 로 넘긴 것이다. 그러므로 -r 옵션으로 - 를 사용하였다. 앞서 rawshark 를 제대로 사용하기 위해서는 -d 와 -r 을 옵션을 사용한다고 하였는데, -d 를 통해 이 데이터가 어떤 것인지 지정해 주었다.  앞에 encap 이라고 되어 있는것은 캡슐화를 뜻하는 것으로 뒤에 EN10MB 는 이더넷 데이터를 뜻한다. 즉, 이 패킷 데이터는 우리가 흔히 사용하는 이더넷 데이터 이라는 것을 지정해 준 것이다. 이런 데이터로는 PPP, FDDI, IEEE802_11 등이 있다. 데이터 타입은 아래 참고의 URL 을 살펴보기 바란다.

여기서 캡슐화라는 것이 나왔는데, 이 캡슐화에 대한 설명은 이미 앞서 포스팅을 해 놓았으므로 읽어보길 바란다.

[링크] 패킷을 보다 자주 접하는 캡슐화(Encapsulation)는 무엇이지?

그리고 -s 는 입력으로 표준 pcap 파일임을 뜻하고, -F 옵션으로 출력할 내용을 지정할 수 있는데, 와이어샤크에서 사용하던 필터를 그대로 사용하면 되므로 어렵지 않게 쓸수 있다. 출력 되어 나오는 것을 보면 아주 심플하다. 다양한 분석기능이 갖춰진 wireshark 와는 다르게 말이다. 말 그대로 로우 데이터를 덤프해서 분석하기 위한 용도이므로 이점은 기억해 두자.  맨앞에 숫자는 패킷의 넘버를 뜻하는 것이고, 그 뒤로 숫자 1 또는 0 이 보인다. 출력 필터로 지정한 것에 대한 필드의 매치 여부를 나타내는 것으로 1이면 매치가 되었다는 것이다. 11번을 보면 HTTP 호스트 정보가 매칭되어서 1 로 표시된것을 볼 수 있다.

마지막으로 앞서 cat 을 통해 출력 시켰는데, 이외에도 tcpdump 를 통해서도 할 수 있고, wireshark 를 통해서도 할 수 있다. 출력을 rawshark 로 넘겨줄수만 있으면 된다.

# tcpdump -r test.pcap -n -w - | rawshark -d encap:EN10MB -r- -s -F ip.dst -F http.host

다음은 eth1 인터페이스를 실시간으로 rawshark 로 넘기는 것이다. 이때 rawshark 옵션으로 -l 옵션을 추가로 사용하였다. 바로바로 실시간으로 데이터가 넘어오기 때문에 바로 Flush 시키도록 한 것이다.

# tcpdump -i eth1 -s 1514 -w - | rawshark -d encap:EN10MB -l -r- -s -F ip.dst -F http.host

[참고]
1. Libpcap 데이터 링크레이어 타입
http://www.tcpdump.org/pcap3_man.html
2. Rawshark 공식 메뉴얼
http://www.wireshark.org/docs/man-pages/rawshark.html
3. 패킷인사이드 libpcap 관련 태그 보기
http://www.packetinside.com/search/label/libpcap

2010년 10월 5일 화요일

오래 간만에 접속해본 tcpdump 사이트 바뀌었네..

오래간만에 tcpdump 사이트를 방문하였더니 홈페이지가 새롭게 리뉴얼 되었다. 근 몇년간 한번도
바뀐적 없이 운영된 것으로 기억하는데, 새로운 화면이 머랄까 신선하게 다가온다. ;-)
패킷 분석을 하는 분들에겐 tcpdump 와 libpcap 을 빼 놓을 수 없을 것이다.

앞으로도 꾸준히 발전하는 모습을 기대하며....
I love libpcap :-)

2010년 8월 21일 토요일

tcpdump 컴파일 오류 - undefined reference to `pcap_parse'

앞서 소개한 포스팅에서 최신 버전의 tcpdump 로 확인하기 위하여 컴파일을 수행하다 발생한 에러에 대해 공유하고자 한다. 아마 개발 환경이 다 갖춰진 환경에서 컴파일이 되었다면 문제가 없었을 수도 있는 상황이었는데, 새로운 시스템에서 컴파일을 진행하다 보니 가벼운 문제가 있었다.

일단, libpcap 1.1.1 최신버전을 컴파일을 한후 다시 tcpdump 를 컴파일 하는 과정에서 아래와 같은 에러가 발생하였다.

./../libpcap-1.1.1/libpcap.a(gencode.o): In function `.L154':
gencode.c:(.text+0x7a4): undefined reference to `pcap_parse'
collect2: ld returned 1 exit status

pcap_parse 가 undefined 라고 나오는데, 오브젝트 파일에서 심볼을 확인해 보았더니 문제가 없었다. config.log 를 살펴보니

configure:9759: gcc -o conftest -DINET6 -g -O2   conftest.c ./../libpcap-1.1.1/libpcap.a   >&5
./../libpcap-1.1.1/libpcap.a(gencode.o): In function `.L154':
gencode.c:(.text+0x7a4): undefined reference to `pcap_parse'
collect2: ld returned 1 exit status
configure:9765: $? = 1
configure: failed program was:

확실히 에러를 확인할 수 있었다. 일단, pcap 라이브러리의 문제가 의심되어 모두 싹 지우고 새롭게 컴파일을 하고 tcpdump 컴파일을 다시 하니, 깔끔하게 된다. 아니, 특별히 건드린 부분도 없는데 말이다.

이전에 컴파일 상황은 bison, flex 같은것이 설치되어 있지 않아, configure 를 해 보고 없는 것이나 make 에서 없는 것을 그때그때마다 설치해 진행한 상황이었다. 그래서 이 부분이 꼬였었나 보다.

문제를 해결하고 보니 참 허무하다. 다시 쏵 지우고 컴파일을 한 것 밖에 없는데 말이다. 처음에는 이것저것 다 뒤져보느라 약간 시간을 허비했는데, 역시나 처음으로 부터 다시 돌아가 시작하는 것이 정답이었던 것인가 -.-

이런 에러를 똑같이 경험하실 분들을 위해 기록을 남겨놓으니 참고하길 바란다. 컴파일 전에 다음과 같은 부분이 설치 되어 있는지 먼저 확인하고 진행하면 큰 무리 없을 것이다.

flex
bison

우분투/데비안 계열 사용자라면 다음과 같은 형태면 문제 없을 것이다.

# apt-get install build-essential flex bison
그럼, 같은 에러를 겪은 분들에게 도움이 되기를 바라며.

P.S 구글링 해보면 비슷한 에러메시지가 나오기에 도움이 되지 않을까 생각한다.

2010년 8월 18일 수요일

패킷덤프시 프로그램에 따라 캡쳐 사이즈가 달라진다.

패킷 덤프시 가끔 Snaplen 과 관련하여 착각하는 분들이 있어 소개하고자 한다. 일전에도 포스팅된
글에서 잠깐 소개를 하였던 것 같은데, 다시한번 보도록 하자!

패킷덤프를 하였는데, 이상하게 Payload 가 다 포함되어 있지 않고, 어딘가 짤려 있는듯한 패킷파일을
봤다면 패킷 덤프시의 길이가 제대로 정의되어 있는지 확인이 필요하다.

와이어샤크는 기본적으로 덤프 길이가 Length 길이의 최대치인 65535 로 지정되어 있어서, 따로
작게 지정하지 않는 한 이슈가 없다. 그런데 유닉스 환경에서 tcpdump 를 이용하는 경우 미처 깜빡하고
넘어갈 수 있다. 다음의 경우를 보자.

아래버전은 3.9.8 버전이다.
# tcpdump -V
tcpdump version 3.9.8
libpcap version 0.9.8

-c 옵션을 통해 10 개의 패킷만 덤프해 보았는데, capture size 가 96 바이트로 나온다.
# tcpdump -c 10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

하지만 -s 옵션을 통해 지정하면 해당 크기만큼 덤프가 가능하다.
# tcpdump -c 10 -s 1514
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 1514 bytes

바로 이런 차이로 덤프는 제대로 되었는데, 페이로드가 완벽하게 기록되지 않는 이유가 여기에 있는 것이다.
하지만, tcpdump 최신 버전에서는 변경되었다.

# ./tcpdump -V
tcpdump version 4.1.1
libpcap version 1.1.1

# ./tcpdump -c 10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

위와 같이 따로 지정하지도 않았는데, 기본 사이즈가 65535 바이트로 지정되어 있다. 최신 버전을 이용하는
경우 신경 안 써도 되지만, 이전 버전을 사용하는 사용자라면 이점 주의하길 바란다!

2010년 8월 12일 목요일

패킷덤프중 프로세스 강제종료는 일부 데이터손실을 가져올 수 있다.

tcpdump 를 이용하여 패킷을 여러개 기록한 경우가 있다. 이상하게도 이전 포스팅에서 소개한 것과 같이 패킷파일을 열어보려고 하면 'appears to have been cut short in the middle of a packet' 메시지가 나타났지만, 어떤 경우는 아예 데이터가 없거나 일부분만 있는 경우가 나타났다.

일부는 기록이 되었는데, 100% 완벽하게 기록이 되지 못했던 것이다. 이유인즉, kill -9 로 프로세스를 kill 하면서 발생하는 문제였다. tcpdump 옵션을 찾아보니 이를 해결할 옵션이 보인다. 바로 -U 옵션이다.

-U 옵션은 Output 버퍼에 기록되어 기록되기 보다는 바로 디스크에 기록이 된다는 점이다. 데이터를 바로바로 기록할 수 있으므로, 내용 하나하나가 중요한 경우에는 필요한 옵션이다.

       -U     Make  output  saved  via  the  -w  option ``packet-buffered``; i.e., as each packet is
              saved, it will be written to the output file, rather than being written only when  the
              output buffer fills.

              The  -U flag will not be supported if tcpdump was built with an older version of libpcap
              that lacks the pcap_dump_flush() function.

다만, 디스크에 바로 기록하기 때문에 디스크 IO 요청은 늘어난다. 이런점은 고려하여 사용여부를 결정해야 한다.

이 -U 옵션을 좀더 살펴보기 위해 tcpdump 소스코드를 살펴보았다. 일반적인 기록에는 pcap_dump 가 사용되는데 -U 옵션은 pcap_dump_flush 가 사용되고 있다.

    pcap_dump((u_char *)dump_info->p, h, sp);
#ifdef HAVE_PCAP_DUMP_FLUSH
    if (Uflag)
        pcap_dump_flush(dump_info->p);
#endif

    --infodelay;
    if (infoprint)
        info(0);
}

사용되는 libpcap 의 소스코드를 살펴보면 pcap_dump_flush 에는 fflush 로 기록을 하고 있고 , pcap_dump 는 fwrite 를 통해 기록을 하고 있다는 차이점이 있다.


[fflush 이용]

int
pcap_dump_flush(pcap_dumper_t *p)
{

    if (fflush((FILE *)p) == EOF)
        return (-1);
    else
        return (0);
}

[fwrite 이용]

void
pcap_dump(u_char *user, const struct pcap_pkthdr *h, const u_char *sp)
{
    register FILE *f;
    struct pcap_sf_pkthdr sf_hdr;

    f = (FILE *)user;
    sf_hdr.ts.tv_sec  = h->ts.tv_sec;
    sf_hdr.ts.tv_usec = h->ts.tv_usec;
    sf_hdr.caplen     = h->caplen;
    sf_hdr.len        = h->len;
    /* XXX we should check the return status */
    (void)fwrite(&sf_hdr, sizeof(sf_hdr), 1, f);
    (void)fwrite(sp, h->caplen, 1, f);
}

그렇기 때문에 kill 로 그냥 프로세스를 종료할 시에는 버퍼 내용이 다 기록된 반면 -9 옵션을 통해 kill 하는 경우 버퍼내용이 기록되지 않으면서 데이터가 완벽하게 기록이 안되는 경우가 발생한 것이다.

패킷 데이터를 덤프하는 경우, 그리고 데이터 내용이 중요한 경우에는 이점을 참고하기 바란다. 정말 패킷이 흘러간 내용이 없는 것으로 판단 착오를 할수도 있기 때문이다. libpcap 을 이용하는 패킷 덤프 프로그램에서는 이런 경우가 있을 수 있으므로 머리속에 기억해 놓자!


2010년 2월 23일 화요일

PCAP 파일을 파헤쳐 보자 - 그 두번째 이야기


PCAP 파일 포맷 구조는 복잡한 부분이 크게 없다. 물론, 직접 바이너리 파일을 들여다 볼 일도 드물다. 단순히 패킷 파일을 분석하는 분석가 입장이라면, 와이어샤크 같은 분석기를 통해서 보면 되기 때문에 어려운 부분은 없다. 하지만, 패킷 분석 전문가를 꿈꾸는 당신이라는 PCAP 파일 포맷 정도는 익혀야 하지 않을까?

그렇다면 pcap 파일 포맷을 좀더 쉽게 볼 수 있는 방법은 없을까? 010 에디터(http://www.010editor.com)
의 기능중 템플리트 기능을 사용하면 바이너리 데이터를 템플리트 형식에 맞게 파싱해 준다.

사용하기 위해서는 다음의 사이트에서 PCAP 템플리트를 받아서 프로그램에 등록하자.

그리고 PCAP 데이터를 읽어들이면 아래 그림과 같이 PCAP 헤더 정보와 다수의 레코드를 볼 수 있다.
와이어샤크와 같이 각 패킷 정보를 세부적으로 보여주는 것이 아니라 PCAP 파일 포맷의 관점에서
보여주는 것이므로 포맷 형태를 이해하는데 참고하면 될 것이다.


워낙 포맷 자체가 간단하기 때문에, 이러한 구조로 만들어져 있고 한번 경험 삼아서 살펴보면 될 것이다.

2010년 2월 22일 월요일

PCAP 파일을 파헤쳐 보자 - 그 첫번째 이야기


패킷 분석을 하면서 가장 많이 듣는 단어중의 하나가 PCAP 이 아닐까 생각한다.
네트웍을 분석하다, 문제가 있다면 흔히 "그러면 PCAP 파일좀 전송해 달라고 한다"
PCAP 은 Packet Capture 의미로 네트워크 트래픽을 캡쳐하기 위한
API 로 구성이 되어 있다. 윈도우로 포팅되어 있는 것은 WinPcap 이며, 유닉스 환경에서는
libpcap 이다.

libpcap 과 winpcap 라이브러리를 이용하여 캡쳐된 패킷을 파일로 저장하거나,
저장된 패킷을 읽고 또는 다른 프로그램에서 라이브러리를 이용해 패킷파일을
분석/편집 등을 할 수 있다. 이를 이용한 대표적인 패킷 캡쳐 프로그램이 tcpdump 나
wireshark 이다.  

자 그럼, 여기서 자주 다루고 있는 패킷파일의 내부를 깊게 살펴 보자.

패킷파일은 크게 다음과 같은 포맷 형태로 구성이 되어 있다.

PCAP 파일헤더 | 패킷 헤더 | 패킷 데이터 | 패킷 헤더 | 패킷 데이터 | 패킷 헤더 | 패킷 데이터 | ... | ...

제일 처음에 PCAP 포맷을 뜻하는 헤더가 오고 이후 각 패킷의 헤더와 데이터 정보가
쌓이게 된다. 헤더 구조체는 아래와 같으며,

struct pcap_file_header {
        bpf_u_int32 magic;
        u_short version_major;
        u_short version_minor;
        bpf_int32 thiszone;     /* gmt to local correction */
        bpf_u_int32 sigfigs;    /* accuracy of timestamps */
        bpf_u_int32 snaplen;    /* max length saved portion of each pkt */
        bpf_u_int32 linktype;   /* data link type (LINKTYPE_*) */
};

매직넘버는 고정된 값으로 0xa1b2c3d4 이다. 버전 Major, Minor 는 패킷 파일 포맷 버전을
뜻하며,  thiszone, sigfigs 는 시간과 관련한 것이고 snaplen 은 캡쳐된 패킷의 길이 network 은
데이터 링크 타입이다.  패킷 헤더 레코드는 아래와 같다.

typedef struct pcaprec_hdr_s {
        guint32 ts_sec;         /* timestamp seconds */
        guint32 ts_usec;        /* timestamp microseconds */
        guint32 incl_len;       /* number of octets of packet saved in file */
        guint32 orig_len;       /* actual length of packet */
} pcaprec_hdr_t;

좀더 쉽게 설명하기 위해 아래 예제 화면을 보자. 제일 처음에 패킷파일 헤더인 매직넘버가 나오고, 패킷 헤더 시작부분과 실제 패킷 데이터 시작 부분을 볼 수 있다. 캡쳐된 패킷의 길이가 66 bytes 나오는데 패킷 데이터 시작 전 4바이트는 실제 패킷의 길이다. 0x00000042 를 계산해보면 66 값을 얻을 수 있다. 단지 위 구조체에 값을 맞춰보기만 하면 된다.

[그림] PCAP 파일 포맷 형태 예제

이 헤더가 끝난 다음 에 또 패킷 헤더와 데이터가 붙으며 계속 이런 구조로 저장이 되는 것이다. 알고보면 구조는 상당히 간단한 형태로 구성이 되어 있다. 파일의 첫 4 바이트만 보아도 아 ~ 패킷 파일인가 보다 하고 추측해 볼 수 있을 것이다. 더불어 외우기도 쉽지 않은가요. 1234 와 ABCD :-)

2009년 12월 17일 목요일

패킷 파일에도 다양한 포맷 타입이 존재한다고!

보통 우리가 흔히 분석에 이용할때 패킷 파일을 CAP 파일 또는 PCAP 이라고들 많이 부른다.
하지만 이것은 하나의 포맷 타입일 뿐 이것말고도 다양한 포맷이 존재한다는 사실. Libpcap 을 이용한
프로그램들이 많아지다 보니 유명세를 탔고, 대표적인 프로그램이 바로 tcpdump, WireShark 다.

아래 목록은 이 글을 작성하는 시점에서 와이어샤크가 지원하는 포맷으로 다양한 것이 있음을
알 수 있다. 패킷 프로그램이 모두다 패킷 데이터를 읽을 수 있는 것은 아니니 이점 유의하도록 하자.
하지만, 대표적으로 libpcap 포맷 형태를 많이 따르고 있으므로, 대중적인 것이라 하면 파일을
읽는데 큰 문제는 없을 것이다.

  • libpcap, tcpdump and various other tools using tcpdump's capture format

  • Sun snoop and atmsnoop

  • Shomiti/Finisar Surveyor captures

  • Novell LANalyzer captures

  • Microsoft Network Monitor captures

  • AIX's iptrace captures

  • Cinco Networks NetXray captures

  • Network Associates Windows-based Sniffer and Sniffer Pro captures

  • Network General/Network Associates DOS-based Sniffer (compressed or uncompressed) captures

  • AG Group/WildPackets EtherPeek/TokenPeek/AiroPeek/EtherHelp/ PacketGrabber captures

  • RADCOM's WAN/LAN Analyzer captures

  • Network Instruments Observer version 9 captures

  • Lucent/Ascend router debug output

  • HP-UX's nettl

  • Toshiba's ISDN routers dump output

  • ISDN4BSD i4btrace utility

  • traces from the EyeSDN USB S0

  • IPLog format from the Cisco Secure Intrusion Detection System

  • pppd logs (pppdump format)

  • the output from VMS's TCPIPtrace/TCPtrace/UCX$TRACE utilities

  • the text output from the DBS Etherwatch VMS utility

  • Visual Networks' Visual UpTime traffic capture

  • the output from CoSine L2 debug

  • the output from Accellent's 5Views LAN agents

  • Endace Measurement Systems' ERF format captures

  • Linux Bluez Bluetooth stack hcidump -w traces

  • Catapult DCT2000 .out files

  • Gammu generated text output from Nokia DCT3 phones in Netmonitor mode

  • IBM Series (OS/400) Comm traces (ASCII & UNICODE)

  • Juniper Netscreen snoop captures

  • Symbian OS btsnoop captures

  • Tamosoft CommView captures

  • Textronix K12xx 32bit .rf5 format captures

  • Textronix K12 text file format captures

  • Wireshark .pcapng captures (Experimental)