패킷파일의 캡쳐시간이 비이상적으로 큰 경우

일전에 포스팅 한 글에서 PCAP 파일을 오픈하는데 65535 값 보다 큰 경우에 대해서
이야기 한 적이 있다.  아직 이 글을 보지 못했다면 다음 링크를 참고하길 바란다:

[LINK] 패킷파일이 깨진 경우는 언제? 65535 보다 큰 값의 헤더가 있다면...

추가적으로 한가지 더 덧붙이고자 한다. 패킷 파일을 보다 보니 시간이 아주 크게 나오는 경우를 보았다. 역시나 이 경우도, 패킷파일이 잘못 저장되어 올바르지 않은 형태로 볼 수 있는데, 결과는 다음과 같다

[Error] (pcap: File has 110080-byte packet, bigger than maximum of 65535)
File type:           Wireshark/tcpdump/... - libpcap
File encapsulation:  Ethernet
Number of packets:   3484
File size:           1559852 bytes
Data size:           2114979 bytes
Capture duration:    1293540784 seconds  -> 엄청나게 큰 패킷 저장 시간
Start time:          Thu Jan  1 09:00:00 1970
End time:            Tue Dec 28 21:53:03 2010
Data byte rate:      0.00 bytes/sec
Data bit rate:       0.01 bits/sec
Average packet size: 607.05 bytes
Average packet rate: 0.00 packets/sec

이렇게 패킷파일의 캡쳐 시간이 비 이상적으로 큰 경우에는 잘못된 형태임을 대충 짐작할 수 있다.  프로그램을 통해 자동으로 분석을 하는 경우와 같은 때는 이런 류는 제외 시켜도 무난한다. 아, 참고로 와이어샤크를 통해 패킷파일을 열어보면 아래 같이 정상적으로 잘 나오는 부분이 있는 반면 Malformed Packet 이라고 제대로 표현하지 못해 보여주지 못하게 되므로 이럴때는 패킷파일이 손상되지 않았나 의심해 볼 수 있다.

패킷파일이 깨진 경우는 언제? 65535 보다 큰 값의 헤더가 있다면...

capinfo, tshak 등을 실행하다 아래와 같은 에러를 얻은 경우가 있다.

[Error] (pcap: File has 1279743227-byte packet, bigger than maximum of 65535)

[Error] (pcap: File has 1174099712-byte packet, bigger than maximum of 65535)

[Error] (pcap: File has 808345964-byte packet, bigger than maximum of 65535)                        

패킷 사이즈만 보면 엄청난 크기이다. 그런데 잘 생각해 보면 이상하다고 생각되는 부분이 있을 것이다.

아래 관련한 소스를 찾아보면 한번 살펴보자.

wireshark1.2.9/wiretap/libpcap.c 를 한번 들여다 본 것이다.

    if (hdr->hdr.incl_len > WTAP_MAX_PACKET_SIZE) {

        /*

         * Probably a corrupt capture file; return an error,

         * so that our caller doesn't blow up trying to allocate

         * space for an immensely-large packet, and so that

         * the code to try to guess what type of libpcap file

         * this is can tell when it's not the type we're guessing

         * it is.

         */

        *err = WTAP_ERR_BAD_RECORD;

        if (err_info != NULL) {

            *err_info = g_strdup_printf("pcap: File has %u-byte packet, bigger than maximum of %u",

                hdr->hdr.incl_len, WTAP_MAX_PACKET_SIZE);

        }

        return -1;

    }

일단, 위에서 발생한 에러의 문구를 볼 수 있다. hdr->hdr.incl_len 이 WTAP_MAX_PACKET_SIZE 보다 큰 경우에 발생한 것인데 WTAP_MAX_PACKET_SIZE 값 또한 찾아보자.

이 값은 wtap.h 에 아래와 같이 정의되어 있다.

/*

 * Maximum packet size we'll support.

 * It must be at least 65535.

 */

#define WTAP_MAX_PACKET_SIZE            65535

최대 패킷 사이즈라고 정의되어 있다. 즉 헤더의 패킷 사이즈를 생각해보면 2 바이트로 최대 65535 까지

가능한 것이다. 그러므로 이론적으로 이 값을 초과할수는 없는 것이기에 패킷 파일이 깨졌을 가능성이 높은 것이다.

한번 테스트용 파일을 tcpdump 를 통해서 오픈 해 봤다. bogus savefile header 라는 문구가 보인다.

# tcpdump -n -r test.cap | wc -l

reading from file test.cap, link-type EN10MB (Ethernet)

tcpdump: pcap_loop: bogus savefile header

1407

이번에는 tshark 를 통해 파일을 읽어 보겠다.

tshark: "test.cap" appears to be damaged or corrupt.

(pcap: File has 781876-byte packet, bigger than maximum of 65535)

781876 바이트를 가지고 있다고 에러가 발생한다. 그리하여 781876 을 HEX 로 변환하여 해당 값을

찾아보니 나타난다.

# hexdump -C test.cap | grep "34 ee 0b"

00072eb0  34 ee 0b 00 66 00 00 00  66 00 00 00 01 00 5e 00  |4...f...f.....^.|

결국은 헤더파일에 잘못된 값이 들어가 있었기 때문에 발생한 것이다. 이렇게 파일이 깨지는 경우도 있으니, 이와 같은 메시지를 얻는 다면 참고하기 바란다.

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

패킷 덤프시 가끔 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 바이트로 지정되어 있다. 최신 버전을 이용하는

경우 신경 안 써도 되지만, 이전 버전을 사용하는 사용자라면 이점 주의하길 바란다!