HTTP 트래픽을 캡쳐하는 간단한 도구를 소개해 드립니다. httpry 는 HTTP 트래픽에 대해서만 패킷 캡쳐를 하는 도구로 HTTP 트래픽에 한해 네트워크 정보를 살펴볼 때 사용할 수 있습니다.
HTTP 요청 정보 현황, HTTP 를 통해 다운로드 되는 의심스러운 파일 감시, HTTP 트래픽 사용 패턴 파악, HTTP 통계 정보 등 사용하고자 하는 형태에 따라 사용되는 목적은 다양할 것 같습니다.
다운로드는 다음 사이트에서 받을 수 있습니다.
http://dumpsterventures.com/jason/httpry/
소스 자체가 간결해서 컴파일은 아주 쉽게 할 수 있습니다.
# tar -xvf httpry-0.1.7.tar
# cd httpry-0.1.7
# make
# make install
도움말은 -h 옵션을 사용하면 됩니다. -i 로 덤프할 인터페이스를 지정할 수 있고 -r 로 패킷파일을 읽어들일 수 있습니다.
Usage: httpry [ -dFhpqs ] [-b file ] [ -f format ] [ -i device ] [ -l threshold ]
[ -m methods ] [ -n count ] [ -o file ] [ -P file ] [ -r file ]
[ -t seconds] [ -u user ] [ 'expression' ]
사용방법이 간단해서 도움말 한번 보시면 어떤 기능인지 쉽게 이해하실 수 있습니다. 기본 출력되는 형태는 다음과 같습니다.
# ./httpry -i eth0
httpry version 0.1.7 -- HTTP logging and information retrieval tool
Copyright (c) 2005-2012 Jason Bittel <jason.bittel@gmail.com>
Starting capture on eth0 interface
2013-08-06 08:45:16 192.168.1.1 173.194.72.121 > GET www.packetinside.com / HTTP/1.0 - -
2013-08-06 08:45:16 173.194.72.121 192.168.1.1 < - - -HTTP/1.0 200 OK
2013-08-06 08:45:34 192.168.1.1 74.125.31.121 > GET www.packetinside.com / HTTP/1.0 - -
2013-08-06 08:45:35 74.125.31.121 192.168.1.1 < - - -HTTP/1.0 200 OK
2013-08-06 08:45:49 192.168.1.1 74.125.235.68 > GET google.com / HTTP/1.0 - -
2013-08-06 08:45:50 74.125.235.68 192.168.1.1 < - - -HTTP/1.0 301 Moved Permanently
2013-08-06 08:45:50 192.168.1.1 74.125.235.84 > GET www.google.com / HTTP/1.0 - -
2013-08-06 08:45:50 74.125.235.84 192.168.1.1 < - - -HTTP/1.0 302 Found
2013-08-06 08:45:50 192.168.1.1 74.125.235.159 > GET www.google.co.kr /?gws_rd=cr HTTP/1.0 - -
2013-08-06 08:45:50 74.125.235.159 192.168.1.1 < - - -HTTP/1.0 200 OK
^CCaught SIGINT, shutting down...
484 packets received, 0 packets dropped, 16 http packets parsed
397.8 packets/min, 13.2 http packets/min
HTTP 트래픽에 대해서 모니터링 하실 분들은 참고하세요
2013년 8월 6일 화요일
2012년 1월 19일 목요일
기가비트 환경에서 패킷덤프 손실을 줄여보기 위한 도구, GULP
기가비트 환경에서 손실없이 패킷을 잡아내기 위한 방법들은 무엇이 있을까? 여러가지 것들이 있을 수 있겠지만, 우리가 흔히 사용하고 있는 리눅스 시스템에서 특별한 변경없이 간단하게 사용할 수 있는 도구 하나를 소개해 볼까 한다. 도구 하나만으로 완벽한 손실없이 패킷을 잡아내기에는 여러가지 환경적 제약이 따른다. 그러므로, 최대한 손실을 줄이면서 패킷을 잡아낼 수 있는 방법을 고민해야 하는데, 스레드 기반의 GULP 가 도움이 되지 않을까 한다.
이 도구를 만든 배경 및 세부적인 정보는 다음 URL 에서 얻을 수 있다.
http://staff.washington.edu/corey/gulp/
비교적 작성된지가 오래되었으므로 이점을 감안하기 바란다.
컴파일은 간단히 make 를 하는 것 만으로도 어렵지 않게 결과를 얻어낼 수 있다.
실행해 보면 아래와 같은 도움말 정보를 얻을 수 있다.
$ ./gulp
./gulp: Sending raw pcap data to a terminal is not a good idea.
If you really want to do that, pipe ./gulp through cat but you
probably want to redirect stdout to a file or another program instead.
Perhaps you meant to pipe into 'tcpdump -r-' or 'ngrep -I-' ?
Usage: ./gulp [--help | options]
--help prints this usage summary
supported options include:
-d decapsulate Cisco ERSPAN GRE packets (sets -f value)
-f "..." specify a pcap filter - see manpage and -d
-i eth#|- specify ethernet capture interface or '-' for stdin
-s # specify packet capture "snapshot" length limit
-r # specify ring buffer size in megabytes (1-1024)
-c just buffer stdin to stdout (works with arbitrary data)
-x request exclusive lock (to be the only instance running)
-X run even when locking would forbid it
-v print program version and exit
-Vx...x display packet loss and buffer use - see manpage
-p # specify full/empty polling interval in microseconds
-q suppress buffer full warnings
-z # specify write blocksize (even power of 2, default 65536)
for long-term capture
-o dir redirect pcap output to a collection of files in dir
-C # limit each pcap file in -o dir to # times the (-r #) size
-W # overwrite pcap files in -o dir rather than start #+1
and some of academic interest only:
-B check if select(2) would ever have blocked on write
-Y avoid writes which would block
여러 패킷 덤프 도구들을 사용해 보았다면 옵션만 보아도 어렵지 않게 사용할 수 있다. 참고로 덤프되는 데이터를 바로 터미널에 출력하는 것은 권장 되지 않으므로, 파일로 리다이렉션 하거나 또는 tcpdump, ngrep 과 같은 프로그램으로 리다이렉션 하는 것이 좋다
다음예는 , -i 로 덤프할 인터페이스를 지정하고 '>' 로 파일로 저장하고 있다.
#./gulp -i eth0 > tt
덤프된 파일의 타입을 살펴보면 캡쳐파일임을 알 수 있고 tcpdump 프로그램으로 확인할 수 있다.
# file tt
tt: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)
# tcpdump -r tt
reading from file tt, link-type EN10MB (Ethernet)
다시 패킷을 덤프하는 과정에서 중지하고 살펴보면 12만개 패킷 중 31 개의 패킷이 drop 되었다. 추가로 나오는 정보에서 이런 drop 되는 패킷을 줄이기 위하여 rmem_max 와 rmem_default 값을 늘려주기를 권장하고 있다.
참고로 이전에 작성한 다음 블로그 글을 참고하여 파라미터 값을 조정하면 도움이 될 것이다.
[링크] 커널에서 drop 되는 패킷 수가 많다면...
느낌상으로는 다른 캡쳐 도구에 비해 손실이 적어 보이기도 한다. 그래서 tcpdump 와 gulp 로 테스트를 해 보았다.
# tcpdump -i bond0 -n -s 1514 -w tt
tcpdump: listening on bond0, link-type EN10MB (Ethernet), capture size 1514 bytes
^C207292 packets captured
208468 packets received by filter
1176 packets dropped by kernel
# ./gulp -i bond0 -s 1514 > tt5
^C
240675 packets captured
240674 packets received by filter
0 packets dropped by kernel
ring buffer use: 0.8% of 100 MB
위 결과를 보면 tcpdump 에서는 1176 개의 패킷이 drop 된 것에 비해 gulp 에서는 한개의 패킷도 drop 되지 않았다. 간단한 결과만 보아도 단순 패킷덤프에서는 gulp 가 tcpdump 보다 우수하다.
gulp 에서 패킷이 유실되는 개수 및 RingBuffer 사용률을 같이 볼 수 있는데 -Vx 를 추가로 주고 덤프를 해 보면 된다.
# ./gulp -i bond0 -Vx > tt3
pkts dropped: 0, ring buf: 0.0%, max: 0.1%
pkts dropped: 0, ring buf: 0.0%, max: 0.1%
pkts dropped: 0, ring buf: 0.1%, max: 0.1%
pkts dropped: 0, ring buf: 0.0%, max: 0.1%
pkts dropped: 0, ring buf: 0.0%, max: 0.1%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.1%, max: 0.4%
pkts dropped: 0, ring buf: 0.1%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.1%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.1%, max: 0.4%
^Cpkts dropped: 0, ring buf: 0.1%, max: 0.4%
27455 packets captured
27454 packets received by filter
0 packets dropped by kernel
ring buffer use: 0.4% of 100 MB
패킷 데이터를 바로 파일로 저장하는 것 외에 프로그램으로 리다이렉션 하여 다음과 같이 사용할 수도 있다.
# ./gulp -i bond0 | tcpdump -r - -w tt4
# ./gulp -i bond0 | ngrep -I - www
그럼 어떤면에서 gulp 가 더 우수한 성능을 보여줄까 ? gulp 를 백그라운드로 실행하고 해당 프로세스를 찾아 strace 로 살펴보았다.
# ./gulp -i bond0 -s 1514 > tt5 &
[2] 5798
# ps -ef | grep gulp
root 5798 18450 0 14:32 pts/1 00:00:00 ./gulp -i bond0 -s 1514
root 6749 18450 0 14:33 pts/1 00:00:00 grep gulp
# strace -p 5798
Process 5798 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, ^C <unfinished ...>
Process 5798 detached
nanosleep 만이 계속 보인다. 무엇인가 계속 기록하고 해야 할텐데, nanosleep 만 보인다? 혹시 스레드를 사용하는 것일까? 그렇다. 다음과 같이 스레드 카운트를 확인해 보면 3개로 보인다.
이와 달리 같은 형태로 tcpdump 를 살펴보자.
# tcpdump -i bond0 -n -s 1514 -w tt6 &
[2] 9793
# tcpdump: listening on bond0, link-type EN10MB (Ethernet), capture size 1514 bytes
# ps -ef | grep tt6
root 9793 18450 0 14:35 pts/1 00:00:00 tcpdump -i bond0 -n -s 1514 -w tt6
root 10080 18450 0 14:35 pts/1 00:00:00 grep tt6
# strace -p 9793
write(4, "\245\1(\37\315Y\265\206\207\fa\315\257\26\1771u\265\240\223\30309A0\304\362\\\257\7k>~"..., 4096) = 4096
recvfrom(3, "\0\33!R\3334\0PV\250]5\10\0E\0\0(\v\"@\0\200\6Hzo\3\4\22\314\240g"..., 1514, MSG_TRUNC, {sa_family=AF_PACKET, proto=0x800, if10, pkttype=PACKET_HOST, addr(6)={1, 005056a85d35}, [18]) = 60
ioctl(3, SIOCGSTAMP, 0xbfffec18) = 0
recvfrom(3, "\0PV\250]5\0\33!R\3334\10\0E\0\5\320w+@\0@\6\26\311\314\240g~o\3\4"..., 1514, MSG_TRUNC, {sa_family=AF_PACKET, proto=0x800, if10, pkttype=PACKET_OUTGOING, addr(6)={1, 001b2152db34}, [18]) = 1502
ioctl(3, SIOCGSTAMP, 0xbfffec18) = 0
recvfrom(3, "\0PV\250]5\0\33!R\3334\10\0E\0\5\320w,@\0@\6\26\310\314\240g~o\3\4"..., 1514, MSG_TRUNC, {sa_family=AF_PACKET, proto=0x800, if10, pkttype=PACKET_OUTGOING, addr(6)={1, 001b2152db34}, [18]) = 1502
ioctl(3, SIOCGSTAMP, 0xbfffec18) = 0
write(4, "R\370\377\3627\t\2\275\230\22G\321\27414\0172\0\341\224(\4rb\326\275\322\246\333\270\303e\200"..., 4096) = 4096
recvfrom(3, "\0\33!R\3334\0PV\250]5\10\0E\0\0(\v#@\0\200\6Hyo\3\4\22\314\240g"..., 1514, MSG_TRUNC, {sa_family=AF_PACKET, proto=0x800, if10, pkttype=PACKET_HOST, addr(6)={1, 005056a85d35}, [18]) = 60
ioctl(3, SIOCGSTAMP, 0xbfffec18) = 0
recvfrom(3, ^C <unfinished ...>
무엇인가 아주 바쁘게 기록을 하며 움직이고 있다. 스레드 카운트를 확인 해보면 1 이다.
즉, GULP 는 스레드로 동작하여 파일 기록시에도 별도의 스레드로 처리하여 더 높은 성능을 나타내고 있는 것이다.
기가비트 네트워크에서는 트래픽 양이 워낙 많기 때문에 운영체제의 네트워크 파라미터를 최적화 하고, 적절한 패킷 캡쳐 도구를 선택해야 한다. 사용환경과 패킷캡쳐의 목적에 따라서 달라지겠지만, 자기에게 맞는 적절한 도구를 테스트해보고 선택하여 사용하면 될 것이다.
비교적 작성된지가 오래되었으므로 이점을 감안하기 바란다.
컴파일은 간단히 make 를 하는 것 만으로도 어렵지 않게 결과를 얻어낼 수 있다.
# make
cc -O check64bit.c -o check64bit
./check64bit; rm -f check64bit
If output from Gulp is not compatible with tcpdump or wireshark,
Please see: http://staff.washington.edu/corey/gulp/gulp.html#64bit
cc -g -O gulp.c -o gulp -lpthread -lpcap
cc -O check64bit.c -o check64bit
./check64bit; rm -f check64bit
If output from Gulp is not compatible with tcpdump or wireshark,
Please see: http://staff.washington.edu/corey/gulp/gulp.html#64bit
cc -g -O gulp.c -o gulp -lpthread -lpcap
실행해 보면 아래와 같은 도움말 정보를 얻을 수 있다.
$ ./gulp
./gulp: Sending raw pcap data to a terminal is not a good idea.
If you really want to do that, pipe ./gulp through cat but you
probably want to redirect stdout to a file or another program instead.
Perhaps you meant to pipe into 'tcpdump -r-' or 'ngrep -I-' ?
Usage: ./gulp [--help | options]
--help prints this usage summary
supported options include:
-d decapsulate Cisco ERSPAN GRE packets (sets -f value)
-f "..." specify a pcap filter - see manpage and -d
-i eth#|- specify ethernet capture interface or '-' for stdin
-s # specify packet capture "snapshot" length limit
-r # specify ring buffer size in megabytes (1-1024)
-c just buffer stdin to stdout (works with arbitrary data)
-x request exclusive lock (to be the only instance running)
-X run even when locking would forbid it
-v print program version and exit
-Vx...x display packet loss and buffer use - see manpage
-p # specify full/empty polling interval in microseconds
-q suppress buffer full warnings
-z # specify write blocksize (even power of 2, default 65536)
for long-term capture
-o dir redirect pcap output to a collection of files in dir
-C # limit each pcap file in -o dir to # times the (-r #) size
-W # overwrite pcap files in -o dir rather than start #+1
and some of academic interest only:
-B check if select(2) would ever have blocked on write
-Y avoid writes which would block
다음예는 , -i 로 덤프할 인터페이스를 지정하고 '>' 로 파일로 저장하고 있다.
#./gulp -i eth0 > tt
덤프된 파일의 타입을 살펴보면 캡쳐파일임을 알 수 있고 tcpdump 프로그램으로 확인할 수 있다.
# file tt
tt: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)
# tcpdump -r tt
reading from file tt, link-type EN10MB (Ethernet)
다시 패킷을 덤프하는 과정에서 중지하고 살펴보면 12만개 패킷 중 31 개의 패킷이 drop 되었다. 추가로 나오는 정보에서 이런 drop 되는 패킷을 줄이기 위하여 rmem_max 와 rmem_default 값을 늘려주기를 권장하고 있다.
참고로 이전에 작성한 다음 블로그 글을 참고하여 파라미터 값을 조정하면 도움이 될 것이다.
[링크] 커널에서 drop 되는 패킷 수가 많다면...
# ./gulp -i bond0 > tt2
^C
121313 packets captured
121343 packets received by filter
31 packets dropped by kernel
Note ./gulp may drop fewer packets if you increase:
/proc/sys/net/core/rmem_max and
/proc/sys/net/core/rmem_default
to 4194304 or more
ring buffer use: 1.8% of 100 MB
^C
121313 packets captured
121343 packets received by filter
31 packets dropped by kernel
Note ./gulp may drop fewer packets if you increase:
/proc/sys/net/core/rmem_max and
/proc/sys/net/core/rmem_default
to 4194304 or more
ring buffer use: 1.8% of 100 MB
느낌상으로는 다른 캡쳐 도구에 비해 손실이 적어 보이기도 한다. 그래서 tcpdump 와 gulp 로 테스트를 해 보았다.
# tcpdump -i bond0 -n -s 1514 -w tt
tcpdump: listening on bond0, link-type EN10MB (Ethernet), capture size 1514 bytes
^C207292 packets captured
208468 packets received by filter
1176 packets dropped by kernel
# ./gulp -i bond0 -s 1514 > tt5
^C
240675 packets captured
240674 packets received by filter
0 packets dropped by kernel
ring buffer use: 0.8% of 100 MB
gulp 에서 패킷이 유실되는 개수 및 RingBuffer 사용률을 같이 볼 수 있는데 -Vx 를 추가로 주고 덤프를 해 보면 된다.
# ./gulp -i bond0 -Vx > tt3
pkts dropped: 0, ring buf: 0.0%, max: 0.1%
pkts dropped: 0, ring buf: 0.0%, max: 0.1%
pkts dropped: 0, ring buf: 0.1%, max: 0.1%
pkts dropped: 0, ring buf: 0.0%, max: 0.1%
pkts dropped: 0, ring buf: 0.0%, max: 0.1%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.1%, max: 0.4%
pkts dropped: 0, ring buf: 0.1%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.1%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.0%, max: 0.4%
pkts dropped: 0, ring buf: 0.1%, max: 0.4%
^Cpkts dropped: 0, ring buf: 0.1%, max: 0.4%
27455 packets captured
27454 packets received by filter
0 packets dropped by kernel
ring buffer use: 0.4% of 100 MB
패킷 데이터를 바로 파일로 저장하는 것 외에 프로그램으로 리다이렉션 하여 다음과 같이 사용할 수도 있다.
# ./gulp -i bond0 | tcpdump -r - -w tt4
# ./gulp -i bond0 | ngrep -I - www
# ./gulp -i bond0 -s 1514 > tt5 &
[2] 5798
# ps -ef | grep gulp
root 5798 18450 0 14:32 pts/1 00:00:00 ./gulp -i bond0 -s 1514
root 6749 18450 0 14:33 pts/1 00:00:00 grep gulp
# strace -p 5798
Process 5798 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, NULL) = 0
nanosleep({0, 500000000}, ^C <unfinished ...>
Process 5798 detached
nanosleep 만이 계속 보인다. 무엇인가 계속 기록하고 해야 할텐데, nanosleep 만 보인다? 혹시 스레드를 사용하는 것일까? 그렇다. 다음과 같이 스레드 카운트를 확인해 보면 3개로 보인다.
# ps -o pid,comm,thcount 5798
PID COMMAND THCNT
5798 gulp 3
PID COMMAND THCNT
5798 gulp 3
이와 달리 같은 형태로 tcpdump 를 살펴보자.
# tcpdump -i bond0 -n -s 1514 -w tt6 &
[2] 9793
# tcpdump: listening on bond0, link-type EN10MB (Ethernet), capture size 1514 bytes
# ps -ef | grep tt6
root 9793 18450 0 14:35 pts/1 00:00:00 tcpdump -i bond0 -n -s 1514 -w tt6
root 10080 18450 0 14:35 pts/1 00:00:00 grep tt6
# strace -p 9793
write(4, "\245\1(\37\315Y\265\206\207\fa\315\257\26\1771u\265\240\223\30309A0\304\362\\\257\7k>~"..., 4096) = 4096
recvfrom(3, "\0\33!R\3334\0PV\250]5\10\0E\0\0(\v\"@\0\200\6Hzo\3\4\22\314\240g"..., 1514, MSG_TRUNC, {sa_family=AF_PACKET, proto=0x800, if10, pkttype=PACKET_HOST, addr(6)={1, 005056a85d35}, [18]) = 60
ioctl(3, SIOCGSTAMP, 0xbfffec18) = 0
recvfrom(3, "\0PV\250]5\0\33!R\3334\10\0E\0\5\320w+@\0@\6\26\311\314\240g~o\3\4"..., 1514, MSG_TRUNC, {sa_family=AF_PACKET, proto=0x800, if10, pkttype=PACKET_OUTGOING, addr(6)={1, 001b2152db34}, [18]) = 1502
ioctl(3, SIOCGSTAMP, 0xbfffec18) = 0
recvfrom(3, "\0PV\250]5\0\33!R\3334\10\0E\0\5\320w,@\0@\6\26\310\314\240g~o\3\4"..., 1514, MSG_TRUNC, {sa_family=AF_PACKET, proto=0x800, if10, pkttype=PACKET_OUTGOING, addr(6)={1, 001b2152db34}, [18]) = 1502
ioctl(3, SIOCGSTAMP, 0xbfffec18) = 0
write(4, "R\370\377\3627\t\2\275\230\22G\321\27414\0172\0\341\224(\4rb\326\275\322\246\333\270\303e\200"..., 4096) = 4096
recvfrom(3, "\0\33!R\3334\0PV\250]5\10\0E\0\0(\v#@\0\200\6Hyo\3\4\22\314\240g"..., 1514, MSG_TRUNC, {sa_family=AF_PACKET, proto=0x800, if10, pkttype=PACKET_HOST, addr(6)={1, 005056a85d35}, [18]) = 60
ioctl(3, SIOCGSTAMP, 0xbfffec18) = 0
recvfrom(3, ^C <unfinished ...>
무엇인가 아주 바쁘게 기록을 하며 움직이고 있다. 스레드 카운트를 확인 해보면 1 이다.
# ps -o pid,comm,thcount -p 9793
PID COMMAND THCNT
9793 tcpdump 1
PID COMMAND THCNT
9793 tcpdump 1
즉, GULP 는 스레드로 동작하여 파일 기록시에도 별도의 스레드로 처리하여 더 높은 성능을 나타내고 있는 것이다.
기가비트 네트워크에서는 트래픽 양이 워낙 많기 때문에 운영체제의 네트워크 파라미터를 최적화 하고, 적절한 패킷 캡쳐 도구를 선택해야 한다. 사용환경과 패킷캡쳐의 목적에 따라서 달라지겠지만, 자기에게 맞는 적절한 도구를 테스트해보고 선택하여 사용하면 될 것이다.
2011년 10월 18일 화요일
시스코 IOS 의 EPC(Embedded Packet Capture) 기능
검색하다 Ciscozine 에 소개된 IOS 12.4T 버전부터 지원되는 EPC 기능을 보았다. 이름과 같이 패킷 캡쳐 기능이 Embedded 되어 있다. 라우터 등에서 바로 데이터를 캡쳐할 수 있는 것이다. 시스코 스위치 등에서 이용되는 SPAN 기능과 달리 NVRAM 에 바로 덤프를 뜨도록 허용하는 것으로, 네트워크 장비상에서 문제가 발생했을때 디버그 용도로 유용하게 사용될 수 있을 것이다.
패킷데이터는 PCAP 포맷으로도 Export 될 수 있으며, CLI 상에서도 HEX, ASCII 로 패킷 데이터를 볼 수 있다고 한다. 살짝, 기술되어 있는 사용 예제를 보면 아래와 같다.
세부적으로 이 기능의 스펙을 살펴보지는 않았지만, 생각해 보면 대용량 라우터에서
사용하기란 어려울 것이다. 일부 초기 네트워크를 구성하는 과정에서 디버그 용도에 적합하지 않을까 생각된다. 특히나 라우터에 이런 기능은 오버헤드를 유발할 수 있다. 백본단에서는 Netflow 조차 거는 것도 쉽지 않은 상황이기 때문이다.
실제로 제가 이 기능을 접할 길이 없는데, 혹시나 이 기능을 확인해 줄 수 있는 분이 있다면 '댓글' 부탁드려요.
[참고]
1. EPC: an Embedded Packet Capture
http://www.ciscozine.com/2011/06/22/epc-an-embedded-packet-capture/
패킷데이터는 PCAP 포맷으로도 Export 될 수 있으며, CLI 상에서도 HEX, ASCII 로 패킷 데이터를 볼 수 있다고 한다. 살짝, 기술되어 있는 사용 예제를 보면 아래와 같다.
1. 캡쳐 버퍼를 정의 ( 100KB 로 지정)
Ciscozine#monitor capture buffer buffer-test size 100
2. 캡쳐 포인트를 정의 (모든 인터페이스의 양 방향으로 정의)
Ciscozine#monitor capture point ip cef capture-test all both
3. 지정한 캡쳐 포인트에 버퍼 지정
Ciscozine#monitor capture point associate capture-test buffer-test
4. 캡쳐 시작
Ciscozine#monitor capture point start capture-test
5. 캡쳐 중지
Ciscozine#monitor capture point stop capture-test
6. 캡쳐된 버퍼의 내용 확인
Ciscozine#show monitor capture buffer buffer-test dump
17:59:50.271 UTC Jun 21 2011 : IPv4 CEF Turbo : Fa1/0 None
66BC0070: CA0012C8 001C0050 J..H...P
66BC0080: 56EEFA3A 08004510 01480000 00000F11 Vnz:..E..H......
66BC0090: D7C1C0A8 28FEC0A8 28850043 00440134 WA@((~@((..C.D.4
66BC00A0: F86B0201 06000000 1DBE0000 0000C0A8 xk.......>....@(
66BC00B0: 2885C0A8 2885C0A8 28FE0000 FD (.@((.@((~..}
17:59:50.271 UTC Jun 21 2011 : IPv4 LES CEF : Fa1/0 None
66BC0070: CA0012C8 001C0050 J..H...P
66BC0080: 56EEFA3A 08004510 01480000 00000F11 Vnz:..E..H......
66BC0090: D7C1C0A8 28FEC0A8 28850043 00440134 WA@((~@((..C.D.4
66BC00A0: F86B0201 06000000 1DBE0000 0000C0A8 xk.......>....@(
66BC00B0: 2885C0A8 2885C0A8 28FE0000 FD (.@((.@((~..}
7. 캡쳐된 데이터 PCAP 포맷으로 Export
Ciscozine#$ture buffer buffer-test export tftp://192.168.40.1/ciscozine.pcap
Ciscozine#monitor capture buffer buffer-test size 100
2. 캡쳐 포인트를 정의 (모든 인터페이스의 양 방향으로 정의)
Ciscozine#monitor capture point ip cef capture-test all both
3. 지정한 캡쳐 포인트에 버퍼 지정
Ciscozine#monitor capture point associate capture-test buffer-test
4. 캡쳐 시작
Ciscozine#monitor capture point start capture-test
5. 캡쳐 중지
Ciscozine#monitor capture point stop capture-test
6. 캡쳐된 버퍼의 내용 확인
Ciscozine#show monitor capture buffer buffer-test dump
17:59:50.271 UTC Jun 21 2011 : IPv4 CEF Turbo : Fa1/0 None
66BC0070: CA0012C8 001C0050 J..H...P
66BC0080: 56EEFA3A 08004510 01480000 00000F11 Vnz:..E..H......
66BC0090: D7C1C0A8 28FEC0A8 28850043 00440134 WA@((~@((..C.D.4
66BC00A0: F86B0201 06000000 1DBE0000 0000C0A8 xk.......>....@(
66BC00B0: 2885C0A8 2885C0A8 28FE0000 FD (.@((.@((~..}
17:59:50.271 UTC Jun 21 2011 : IPv4 LES CEF : Fa1/0 None
66BC0070: CA0012C8 001C0050 J..H...P
66BC0080: 56EEFA3A 08004510 01480000 00000F11 Vnz:..E..H......
66BC0090: D7C1C0A8 28FEC0A8 28850043 00440134 WA@((~@((..C.D.4
66BC00A0: F86B0201 06000000 1DBE0000 0000C0A8 xk.......>....@(
66BC00B0: 2885C0A8 2885C0A8 28FE0000 FD (.@((.@((~..}
7. 캡쳐된 데이터 PCAP 포맷으로 Export
Ciscozine#$ture buffer buffer-test export tftp://192.168.40.1/ciscozine.pcap
세부적으로 이 기능의 스펙을 살펴보지는 않았지만, 생각해 보면 대용량 라우터에서
사용하기란 어려울 것이다. 일부 초기 네트워크를 구성하는 과정에서 디버그 용도에 적합하지 않을까 생각된다. 특히나 라우터에 이런 기능은 오버헤드를 유발할 수 있다. 백본단에서는 Netflow 조차 거는 것도 쉽지 않은 상황이기 때문이다.
실제로 제가 이 기능을 접할 길이 없는데, 혹시나 이 기능을 확인해 줄 수 있는 분이 있다면 '댓글' 부탁드려요.
[참고]
1. EPC: an Embedded Packet Capture
http://www.ciscozine.com/2011/06/22/epc-an-embedded-packet-capture/
2011년 4월 4일 월요일
와이어샤크로 USB 디바이스를 모니터링 할 수 있다는 사실!
컴퓨터와 USB 사이의 통신 내용도 패킷을 캡쳐하는 것과 같이 볼 수 없을까? 이에 대한 대답은 '있다' 이다. 그것도 우리가 블로그에서 많이 언급하고 친근한 프로그램 중에 하나인 와이어샤크로 할 수 있다.
자, 그럼 어떻게 USB 트래픽 정보를 볼 수 있을까? 우선 운영체제에서 볼 수 있도록 지원해 주어야 하는데, USB 로우 트래픽 데이터를 패킷 형태로 변환하여 일반적인 네트워크 인터페이스와 같이 인식되어 볼 수 있다. 여기서는 리눅스를 기반으로 하여 설명을 할 것이다. 우선 커널 상에서 DEBUG 파일 시스템이라든지, USB 모니터링 모듈등을 지원해 주어야 한다. 그러므로, 다음과 같은 옵션이 설정되어 커널이 컴파일 되어 있어야 한다.
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_FS=y
CONFIG_USB_MON=y
CONFIG_DEBUG_FS=y
CONFIG_USB_MON=y
USBMON 모듈은 커널 2.6.11 이후에 포함되어 있으며, 최근의 배포판 리눅스에서는 크게 다른 설정 없이 아래의 명령어를 사용할 수 있을 것이다. 일단, lsmod 명령어를 통해 usb 관련한 모듈은 무엇이 올라가 있는지 살펴보았다.
# lsmod | grep usb
rt2800usb 28691 0
rt2x00usb 6829 1 rt2800usb
rt2x00lib 21810 2 rt2800usb,rt2x00usb
mac80211 137340 2 rt2x00usb,rt2x00lib
crc_ccitt 1323 2 rt2870sta,rt2800usb
usb_storage 39625 1
scsi_mod 122149 5 usb_storage,sg,sr_mod,sd_mod,libata
usbcore 122034 6 rt2870sta,rt2800usb,rt2x00usb,usb_storage,ehci_hcd
nls_base 6377 11 isofs,udf,hfsplus,hfs,ntfs,jfs,nls_utf8,nls_cp437,vfat,fat,usbcore
usbmon 은 보이지 않는다. usbmon 모듈은 modprobe 를 통해서 쉽게 모듈을 로드할 수 있다.
# modprobe usbmon
모듈을 올린 후 살펴보니 usbmon 모듈이 올라가 있는 것이 보인다.
# lsmod | grep usb
usbmon 15322 0
rt2800usb 28691 0
rt2x00usb 6829 1 rt2800usb
rt2x00lib 21810 2 rt2800usb,rt2x00usb
mac80211 137340 2 rt2x00usb,rt2x00lib
crc_ccitt 1323 2 rt2870sta,rt2800usb
usb_storage 39625 1
scsi_mod 122149 5 usb_storage,sg,sr_mod,sd_mod,libata
usbcore 122034 7 usbmon,rt2870sta,rt2800usb,rt2x00usb,usb_storage,ehci_hcd
nls_base 6377 11 isofs,udf,hfsplus,hfs,ntfs,jfs,nls_utf8,nls_cp437,vfat,fat,usbcore
그 다음 DebugFS 파일시스템 타입으로 아래와 같이 마운트 해 주면 된다.
# mount -t debugfs / /sys/kernel/debug
# mount
[생략]
/dev/sdb1 on /media/usb0 type vfat (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/ on /sys/kernel/debug type debugfs (rw)
# mount
[생략]
/dev/sdb1 on /media/usb0 type vfat (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/ on /sys/kernel/debug type debugfs (rw)
앞서 설명한 것과 같이 네트워크 인터페이스로 인식을 시켜준다고 하였다. 그럼, tshark 의 -D 옵션을 통해 사용가능한 인터페이스 리스트를 확인할 수 있다.
# tshark -D
1. eth0
2. usbmon1 (USB bus number 1)
3. usbmon2 (USB bus number 2)
4. any (Pseudo-device that captures on all interfaces)
5. lo
1. eth0
2. usbmon1 (USB bus number 1)
3. usbmon2 (USB bus number 2)
4. any (Pseudo-device that captures on all interfaces)
5. lo
기존에는 보이지 않던 usbmon1 과 usbmon2 이 보인다. 그렇다 그럼 이제 이 인터페이스로만 지정해서 패킷 덤프를 해 보면 USB 트래픽을 볼 수 있다는 것이된다. 그런데, 2번과 3번중 어떤것이 올바른 인터페이스일까? 그냥 쉽게는 2번,3번 한번씩 패킷덤프도 해 볼 수 있지만, lsusb 명령어로 usb 정보를 들여다 보자.
# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 026: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
위 화면은 USB 를 연결하기 전이고 다음은 USB 를 연결한 후의 화면이다. 보는 것과 같이 Bus 002 에 새로운 디바이스가 잡혀있는것을 볼 수 있다.
# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 026: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 002 Device 028: ID 090c:1000 Feiya Technology Corp. Flash Drive
그러면, USB 버스 2번이니 위에서 살펴본 인터페이스중 3번인 usbmon2 를 관찰하면 되겠다는 것을 알 수 있다. lsusb 외 usb-devices 명령어를 이용해서도 확인할 수 있다.
# usb-devices
T: Bus=02 Lev=03 Prnt=26 Port=02 Cnt=01 Dev#= 28 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=090c ProdID=1000 Rev=11.00
S: Manufacturer=LG Electronics
S: Product=XTICK
S: SerialNumber=AA04012700015188
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=300mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
tshark 를 통해서 USB 패킷 데이터를 덤프해 보자. -i 옵션을 통해 인터페이스 번호를 지정해 주었다. 와, USB 트래픽 정보가 잡힌다. 참고로, 와이어샤크 1.2.X 버전 이상을 사용하여야 한다.
# tshark -i 3
Running as user "root" and group "root". This could be dangerous.
Capturing on USB bus number 2
0.000000 host -> 28.0 USB GET DESCRIPTOR Request DEVICE
0.000407 28.0 -> host USB GET DESCRIPTOR Response DEVICE
0.000422 host -> 26.0 USB GET DESCRIPTOR Request DEVICE
0.000575 26.0 -> host USB GET DESCRIPTOR Response DEVICE
0.000615 host -> 2.0 USB GET DESCRIPTOR Request DEVICE
0.000658 2.0 -> host USB GET DESCRIPTOR Response DEVICE
0.000677 host -> 1.0 USB GET DESCRIPTOR Request DEVICE
0.000677 1.0 -> host USB GET DESCRIPTOR Response DEVICE
GUI 버전의 와이어샤크에서는 어떻게 나올까? 다음 그림과 같이 GUI 화면에서도 문제없이 깔끔하게 트래픽 정보가 출력된다. 데이터 영역부분도 보인다.
그러면, 여기서 살짝 의문이 생긴다. 와이어샤크로만 데이터를 덤프할 수 있는 것인가 ? 그렇지는 않다. 네트워크 인터페이스로 잡힌 것이기 때문에 tcpdump 프로그램을 통해서도 볼 수 있다. USB 트래픽 데이터를 파싱해서 보여줄 수 있는 것이면 된다.
# tcpdump -i 3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on usbmon2, link-type USB_LINUX_MMAPPED (USB with padded Linux header), capture size 65535 bytes
09:11:09.835197 CONTROL SUBMIT to 2:28:0
09:11:09.835623 CONTROL COMPLETE from 2:28:0
09:11:09.835647 CONTROL SUBMIT to 2:26:0
09:11:09.835720 CONTROL COMPLETE from 2:26:0
09:11:09.835740 CONTROL SUBMIT to 2:2:0
09:11:09.835845 CONTROL COMPLETE from 2:2:0
09:11:09.835859 CONTROL SUBMIT to 2:1:0
09:11:09.835859 CONTROL COMPLETE from 2:1:0
09:11:12.002810 BULK SUBMIT to 2:28:2
09:11:12.002955 BULK COMPLETE from 2:28:2
09:11:12.002963 BULK SUBMIT to 2:28:1
이 외에도 더 로우 방법으로 확인할 수 있는 방법이 있는데, 직접 디버그파일 시스템을 cat 를 통해 볼 수도 있다. 아래와 같이 말이다.
# cat /sys/kernel/debug/usb/usbmon/2u
ffff88021d618540 1982035431 S Bo:2:028:2 -115 31 = 55534243 a8010000 00000000 00000600 00000000 00000000 00000000 000000
ffff88021d618540 1982035468 C Bo:2:028:2 0 31 >
ffff88021d618540 1982035549 S Bi:2:028:1 -115 13 <
ffff88021d618540 1982035856 C Bi:2:028:1 0 13 = 55534253 a8010000 00000000 00
ffff88021d618540 1982035895 S Bo:2:028:2 -115 31 = 55534243 a9010000 00000000 00000600 00000000 00000000 00000000 000000
ffff88021d618540 1982035963 C Bo:2:028:2 0 31 >
ffff88021d618540 1982035969 S Bi:2:028:1 -115 13 <
ffff88021d618540 1982036213 C Bi:2:028:1 0 13 = 55534253 a9010000 00000000 00
ffff88021d618540 1984037715 S Bo:2:028:2 -115 31 = 55534243 aa010000 00000000 00000600 00000000 00000000 00000000 000000
ffff88021d618540 1984037787 C Bo:2:028:2 0 31 >
ffff88021d618540 1984037793 S Bi:2:028:1 -115 13 <
ffff88021d618540 1984038035 C Bi:2:028:1 0 13 = 55534253 aa010000 00000000 00
ffff88021d618540 1984038056 S Bo:2:028:2 -115 31 = 55534243 ab010000 00000000 00000600 00000000 00000000 00000000 000000
ffff88021d618540 1984038192 C Bo:2:028:2 0 31 >
ffff88021d618540 1984038195 S Bi:2:028:1 -115 13 <
ffff88021d618540 1984038410 C Bi:2:028:1 0 13 = 55534253 ab010000 00000000 00
USB 트래픽을 관찰할 일이 있다면, 와이어샤크를 통한 이 방법이 좋은 방법중에 하나가 될 것이다. 윈도우에서는 와이어샤크를 통해 바로 USB 트래픽을 관찰할 수 없다. 리눅스의 가상 머신에 윈도우를 올려서 사용될 수 있는 방법이 아래 [참고] 를 보면 소개되어 있긴 하다.
추후 시간적 여유가 된다면 윈도우 기반에서도 테스트 해 본 후 결과를 공유하도록 하겠다.
[참고]
1. 와이어샤크 USB 캡쳐
http://wiki.wireshark.org/CaptureSetup/USB
2010년 12월 2일 목요일
네트워크 패킷 인젝션,캡쳐 도구 Packit
네트워크 패킷을 인젝션하고 캡쳐할 수 있는 도구 Packit(Packet toolkit) 을 소개한다.
앞서 소개했던 많은 도구들과 같이 인젝션하기에 유용한 도구이다.
TCP,UDP,ICMP,IP,ARP,RARP 그리고 이더넷 헤더등 거의 모든 것을 정의할 수 있어,
방화벽, 침입탐지시스템, 트래픽 테스트와 같은 곳에 이용할 때 유용하게 사용될 수 있을 것이다.
Packit 의 버전은 현재 1.0 이며 설치를 하기 위해서는 libnet 1.1.2 이상의 라이브러리와
libpcap 라이브러리또한 필요하다.
소스파일의 다운로드는 다음의 경로에서 할 수 있다:
APT 패키지 사용자라면,
# apt-get install packit 으로 쉽게 설치도 가능하다.
사용에는 큰 어려움이 없으나, 다만 옵션이 상당히 많다. 이 뜻은 세부적으로
정의할 수 있다는 뜻이된다. 기본 사용방법은 아래와 같다:
usage: packit -m mode [-options] 'expression'
사용할 때 모드가 있다는 것을 주의해야 하는데, 모드에 따라서 옵션이 달라지기 때문이다.
옵션에는 capture, inject, trace 가 있으며 기본모드는 inject 이다.
1. 패킷 캡쳐
자주 사용할 만한 패킷 캡쳐 옵션 몇가지를 정리해 보면 아래와 같다
-c count 캡쳐할 카운트 수를 지정
-e 링크 레이어 헤더 데이터 출력
-i interface 네트워크 인터페이스 지정
-n 호스트 주소를 이름으로 변환하지 않음
-r file 패킷을 읽을 파일 지정
-s snaplen 패킷 캡쳐할 snaplen 데이터 사이즈 정의 (기본:68 바이트)
-w file 패킷 파일 저장
-X 헥사와 아스키로 데이터 출력
사용 옵션들을 보면 패킷인사이드에서 여러번 다뤘던 도구들과 큰 차이는 없다.
특히 tcpdump 에 익숙하다면 더욱 그럴것이다.
사용예제>
#packit -m capture -c 100 -i eth0 -w /data/packetinside.pcap
#packit -m cap -nX 'tcp and port 80'
2. 패킷 인젝션
기본적으로 인젝션 되는 패킷의 옵션은 아래와 같으며, 옵션만 봐도 크게 어렵지는 않다.
-t protocol 인젝트할 프로토콜 타입 지정 : TCP, UDP, ICMP, ARP (기본은 TCP)
-c count 인젝션에 몇 개의 패킷을 사용할 것인지 정의
-i interface 네트워크 인터페이스
-w interval 각 패킷을 보내는 간격 시간 (기본 : 1초)
-h 패킷을 보낸 후, 응답을 프린트 해줌 * 필요에 따라 유용한 기능
-v Verbose 모드로 세부적으로 정보를 출력함
-p payload 인젝션 할 페이로드를 지정, HEX 는 '0x' 로 시작하며 각 값의 구분은 공백으로 함
ASCII : -p 'hello world, packetinside.com'
HEX: -p '0x 40 40 40 90 90 90 0d 0a'
-Z length 인젝트할 패킷의 사이즈 정의
-t 로 프로토콜을 지정한 후 각 프로토콜 마다 사용가능한 옵션을 이용하면 되는데
IP,TCP,UDP,ICMP,ARP,이더넷 헤더 옵션을 가지고 있다.
여기서 각 옵션을 일일이 설명하기는 힘들고, packit 의 간단한 도움말을 보면 쉽게 알 수 있다.
TCP/UDP header options
-a ack Acknowledgement number
-D port Destination port (Range format: start-end)
-F flags Flags (format: -F UAPRSF)
-q seq Sequence number
-S port Source port (Default: Random)
-u urg Urgent pointer
-W size Window size (Default: 65535)
ICMPv4 header options
General:
-C code Code (Default: 0)
-K type Type (Default: 8)
Echo(0) / Echo Reply(8):
-N id ID number
-Q seq Sequence number
Unreachable(3) / Redirect(5) / Time Exceeded(11):
-g gateway Redirect gateway host (ICMP Redirect only)
-j address Original source address
-J port Original source port
-l address Original destination address
-L port Original destination port
-m ttl Original time to live
-M id Original ID number
-O tos Original type of service
-P proto Original protocol (Default: UDP)
Mask Request(17) / Mask Reply(18):
-N id ID number
-Q seq Sequence number
-G mask Address mask
Timestamp Request(13) / Timestamp Reply(14):
-N id ID number
-Q seq Sequence number
-U ts Original timestamp
-k ts Recieved timestamp
-z ts Transmit timestamp
IP header options
-d address Destination address
-f Don't fragment
-n id ID number
-o tos Type of service
-s address Source address
-T ttl Time to live (Default: 128)
-V ipproto IP protocol number (RAWIP only)
ARP header options
-A op Operation type (Default: 1 (ARP request))
-x address Source protocol address
-X hwaddr Source hardware address
-y address Destination protocol address
-Y hwaddr Destination hardware address
Ethernet header options
-e ethaddr Source ethernet address
-E ethaddr Destination ethernet address
옵션은 위와 같으며, 패킷인사이드 블로그를 열심히 보신 분들이라면 옵션을 이해하는데
어려움이 없을 것이다. 몇가지 예제를 보도록 하자.
다음은 출발지 소스는 8.8.1.1 로 하고 목적지는 192.168.0.1 로 보내는데 총 10개의 패킷을
보낸다. -h 옵션은 응답도 출력하도록 한 것이다. -h 옵션이 주어지지 않으면,
단순히 전송하는 정보만 출력할 것이다.
# packit -t icmp -s 8.8.1.1 -d 192.168.0.1 -c 10 -h
Mode: Packet Injection using device: eth1
-| SND 1 |------------------------------------------------------------------
Timestamp: 10:28:54.469954
ICMP header: Type: Echo Request(8) ID: 5854 Seqn: 56577
IP header: Src Address: 8.8.1.1 Dst Address: 192.168.0.1
TTL: 128 ID: 53261 TOS: 0x0 Len: 28
-| No Response From Peer |--------------------------------------------------
아래는 TCP 패킷을 보내는 것으로 목적지 포트 80에 TTL은 111 그리고 페이로드는 0x40 을
보낸 것이다.
# packit -t TCP -s 192.168.0.253 -d 192.168.0.200 -S 403 -D 80 -T 111 -p '0x 40'
Mode: Packet Injection using device: eth1
TCP header: Src Port: 403 Dst Port(s): 80 Flag(s): None
Window: 65535
IP header: Src Address: 192.168.0.253 Dst Address: 192.168.0.200
TTL: 111 ID: 49354 TOS: 0x0 Len: 41
Writing packet(s) (1): .
-| Packet Injection Statistics |--------------------------------------------
Injected: 1 Packets/Sec: 1.0 Bytes/Sec: 41.0 Errors: 0
그리고 다음은 ARP 패킷을 만들어 전송한 것이다. 우선 -t 로 ARP 타입을 지정해 주고
-A 1 은 ARP Request 를 뜻하고 -x 는 보내는 IP 주소 -X 보내는 이더넷 주소를 정의한 것이다.
# packit -t arp -A 1 -x 1.2.3.4 -X 5:4:3:2:1:0
Mode: Packet Injection using device: eth1
ARP header: Type: Request(1)
Sender: Protocol Address: 1.2.3.4 Hardware Address: 5:4:3:2:1:0
Target: Protocol Address: 0.0.0.0 Hardware Address: 0:0:0:0:0:0
Writing packet(s) (1): .
-| Packet Injection Statistics |--------------------------------------------
Injected: 1 Packets/Sec: 1.0 Bytes/Sec: 42.0 Errors: 0
여기서는 간단한 형태로만 만들어 패킷을 전송하지만, 사용하고자 하는 목적에 따라서
다양하게 만들어 볼 수 있다. 옵션을 여러개 사용하여 복잡해 보이지만,
막상 사용해 보면 옵션등이 사용하려는 목적을 대충 추정해 볼 수 있어 심플하게 패킷을 전송할 수 있다.
여기 블로그에서 언급한 많은 도구들 중에서 어떤것이 자기에게 더욱 적합한지는 여러분들이 판단하길 바란다.
From Rigel
2010년 7월 6일 화요일
WinPcap 4.1.2 버전 릴리즈
WinPcap 이 2009년 10월 말 이후로, 최근에 (2010년7월2일) 업데이트 되었다. 참 오랜만의 업데이트 이다.
WinPcap 4.1.2 버전이며 다운로드는 아래의 경로에서 할 수 있다.
이번 릴리즈에서는 몇몇 OS 에서 발생되었던 Crash 의 원인인
드라이버의 버그가 픽스 되었다. 이번 버전의 주요 변경된 내용은
ChangeLog 를 확인해 볼 수 있다.
업데이트가 귀챦으신 분들은 그냥 넘어가도 되겠다. 큰 Major 변화는 있지 않기 때문이다.
2010년 6월 8일 화요일
맥(Mac) OS X 기반의 패킷 분석기, 그 이름은 코코아!
서핑을 하다 맥 기반의 패킷 분석기가 있어 소개한다. 이미 맥(Mac) 을 많이 사용하고 있는 유저라면
벌써 알고있을지도 모른다. 하지만, 여기에 차곡차곡 패킷분석 관련을 글을 소개하고 있으니 빠질 수는 없다.
이름은 귀엽게. 코코아 패킷 분석기이다. 앞서 소개한 것과 같이 Mac OS X 기반에서 동작하고 PCAP 패킷 포맷을 읽고, 캡쳐 및 저장을 할 수 있다. 기본적인 패킷 캡쳐, 필터 기능, 플러그인 기능등이 있다.
와이어샤크에 비하면 분석 기능은 부족해 보인다. 맥 환경이 없어 직접 코코아를 사용해 볼 수는 없어
자세히는 언급할 수 없지만, 제공하는 스크린샷을 통해 통해 보면 대충 기능 파악은 될 것이다.
[CPA 사이트]
http://www.tastycocoabytes.com/cpa/
CPA 는 Cocoa Packet Analyzer 의 약자이다. 맥 환경에서 사용해본 분이 계시다면 살짝 댓글로 의견을
남겨주세요. 또는 맥 기반의 다른 프로그램을 공유해 주셔도 좋습니다 :-)
피드 구독하기:
글 (Atom)