Network Analysis using Tcpdump (with matlab to visualize the results)

1. Network Analysis using Tcpdump(with matlab to visualize the results)

2. Overview • tcpdump is a tool that allows you to capture packet traces. • It’s been around for a while: • http://www.tcpdump.org/ • Available on all platforms (including windows!) • Wireshark is another open source packet trace tool. Think of it as tcpdump with a GUI.

3. Elements involved in capture process

4. man page • TCPDUMP(8) TCPDUMP(8) • NAME • tcpdump - dump traffic on a network • SYNOPSIS • tcpdump [ -AdDeflLnNOpqRStuUvxX ] [ -c count ] • [ -C file_size ] [ -F file ] • [ -i interface ] [ -m module ] [ -M secret ] • [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] • [ -W filecount ] • [ -E spi@ipaddr algo:secret,... ] • [ -y datalinktype ] [ -Z user ] • [ expression ] • DESCRIPTION • Tcpdump prints out the headers of packets on a network interface that match the boolean expression. It can also be run with the -w flag, • which causes it to save the packet data to a file for later analysis, and/or with the -r flag, which causes it to read from a saved packet • file rather than to read packets from a network interface. In all cases, only packets that match expression will be processed by tcpdump. • Tcpdump will, if not run with the -c flag, continue capturing packets until it is interrupted by a SIGINT signal (generated, for example, by • typing your interrupt character, typically control-C) or a SIGTERM signal (typically generated with the kill(1) command); if run with the -c • flag, it will capture packets until it is interrupted by a SIGINT or SIGTERM signal or the specified number of packets have been processed. • When tcpdump finishes capturing packets, it will report counts of: • packets captured (this is the number of packets that tcpdump has received and processed); • packets âreceived by filter (the meaning of this depends on the OS on which youâre running tcpdump, and possibly on the way the OS • was configured - if a filter was specified on the command line, on some OSes it counts packets regardless of whether they were matched • by the filter expression and, even if they were matched by the filter expression, regardless of whether tcpdump has read and processed • them yet, on other OSes it counts only packets that were matched by the filter expression regardless of whether tcpdump has read and • processed them yet, and on other OSes it counts only packets that were matched by the filter expression and were processed by tcpdump);

5. LinuxVM1 LinuxVM3 Ping LinuxVM3 [root@LinuxVM3 ~]# ping -c 3 LinuxVM1 PING LinuxVM1 (172.16.137.128) 56(84) bytes of data. 64 bytes from LinuxVM1 (172.16.137.128): icmp_seq=1 ttl=64 time=0.197 ms 64 bytes from LinuxVM1 (172.16.137.128): icmp_seq=2 ttl=64 time=0.142 ms 64 bytes from LinuxVM1 (172.16.137.128): icmp_seq=3 ttl=64 time=0.174 ms --- LinuxVM1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 0.142/0.171/0.197/0.022 ms jjm@LinuxVM1 ~/traces $ sudo tcpdump 'icmp' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 06:42:26.758147 IP LinuxVM1 > LinuxVM3: ICMP LinuxVM1 udp port 5665 unreachable, length 548 06:42:27.409634 IP LinuxVM3 > LinuxVM1: ICMP LinuxVM3 udp port 6703 unreachable, length 548 06:42:27.476081 IP LinuxVM3 > LinuxVM1: ICMP echo request, id 19459, seq 1, length 64 06:42:27.476105 IP LinuxVM1 > LinuxVM3: ICMP echo reply, id 19459, seq 1, length 64 06:42:27.476304 IP LinuxVM1 > LinuxVM3: ICMP LinuxVM1 udp port sun-as-jmxrmi unreachable, length 548 06:42:28.188721 IP LinuxVM3 > LinuxVM1: ICMP LinuxVM3 udp port 5076 unreachable, length 548 06:42:28.189974 IP LinuxVM1 > LinuxVM3: ICMP LinuxVM1 udp port 5983 unreachable, length 548 06:42:28.476483 IP LinuxVM3 > LinuxVM1: ICMP echo request, id 19459, seq 2, length 64 06:42:28.476504 IP LinuxVM1 > LinuxVM3: ICMP echo reply, id 19459, seq 2, length 64 06:42:29.411229 IP LinuxVM3 > LinuxVM1: ICMP LinuxVM3 udp port 6630 unreachable, length 548 06:42:29.477463 IP LinuxVM3 > LinuxVM1: ICMP echo request, id 19459, seq 3, length 64 06:42:29.477478 IP LinuxVM1 > LinuxVM3: ICMP echo reply, id 19459, seq 3, length 64 06:42:29.760595 IP LinuxVM1 > LinuxVM3: ICMP LinuxVM1 udp port 5665 unreachable, length 548 06:42:30.411830 IP LinuxVM3 > LinuxVM1: ICMP LinuxVM3 udp port 6703 unreachable, length 548 06:42:30.479218 IP LinuxVM1 > LinuxVM3: ICMP LinuxVM1 udp port sun-as-jmxrmi unreachable, length 548 15 packets captured 59 packets received by filter 0 packets dropped by kernel

6. tcpdump • Issue tcpdump and you are likely to see a huge number of packets. • When tracing, usually we • Apply a filter • Save the trace to a file jjm@LinuxVM1 ~/traces $ sudo tcpdump -w trace.dmp 'icmp' Password: tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 38 packets captured 92 packets received by filter 0 packets dropped by kernel jjm@LinuxVM1 ~/traces $ sudo tcpdump -r trace.dmp reading from file trace.dmp, link-type EN10MB (Ethernet) 06:49:20.826373 IP LinuxVM3 > LinuxVM1: ICMP echo request, id 28931, seq 1, length 64 06:49:20.826408 IP LinuxVM1 > LinuxVM3: ICMP echo reply, id 28931, seq 1, length 64 06:49:21.826701 IP LinuxVM3 > LinuxVM1: ICMP echo request, id 28931, seq 2, length 64 06:49:21.826714 IP LinuxVM1 > LinuxVM3: ICMP echo reply, id 28931, seq 2, length 64 06:49:22.826417 IP LinuxVM3 > LinuxVM1: ICMP echo request, id 28931, seq 3, length 64 06:49:22.826449 IP LinuxVM1 > LinuxVM3: ICMP echo reply, id 28931, seq 3, length 64

7. tcpdump • Sometimes we want to see the contents of the packet Step 1: Issue jjm@LinuxVM1 ~/traces $ sudo tcpdump -w trace.dmp -s 1500 'icmp' Step 2: After the network traffic of interest has completed…. jjm@LinuxVM1 ~/traces $ sudo tcpdump -r trace.dmp -XX 'icmp' > trace.out reading from file trace.dmp, link-type EN10MB (Ethernet) Step 3: vi trace.out and you will likely see many traced packets. I am showing just one ICMP Echo request and reply iteration 06:51:56.518865 IP LinuxVM3 > LinuxVM1: ICMP echo request, id 30723, seq 1, length 64 0x0000: 000c 294f 1ee7 000c 2982 1d7e 0800 4500 ..)O....)..~..E. 0x0010: 0054 0000 4000 4001 cf85 ac10 8982 ac10 .T..@.@......... 0x0020: 8980 0800 cd11 7803 0001 fd1f ae4a 1a7c ......x......J.| 0x0030: 0200 0809 0a0b 0c0d 0e0f 1011 1213 1415 ................ 0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$% 0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345 0x0060: 3637 67 06:51:56.518890 IP LinuxVM1 > LinuxVM3: ICMP echo reply, id 30723, seq 1, length 64 0x0000: 000c 2982 1d7e 000c 294f 1ee7 0800 4500 ..)..~..)O....E. 0x0010: 0054 8437 0000 4001 8b4e ac10 8980 ac10 .T.7..@..N...... 0x0020: 8982 0000 d511 7803 0001 fd1f ae4a 1a7c ......x......J.| 0x0030: 0200 0809 0a0b 0c0d 0e0f 1011 1213 1415 ................ 0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$% 0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345 0x0060: 3637 67

8. Libpcap • Libpcap is an open source library that provides a highlevel interface to network packet capture system.

9. Libpcap functions • pcap_t *pcap_open_offline(const char *fname, char *errbuf) • int pcap_dispatch(pcap_t *p, int cnt,         pcap_handler callback, u_char *user) • int pcap_loop(pcap_t *p, int cnt,         pcap_handler callback, u_char *user) • int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize, bpf_u_int32 netmask)

10. Libpcap functions • int pcap_setfilter(pcap_t *p, struct bpf_program *fp) • const u_char *pcap_next(pcap_t *p, struct pcap_pkthdr *h)

11. Related analysis tools • Tcptrace • Timeslice (Clemson project) • tcpdstat • Xgraph

12. Helpful websites • http://sectools.org/tools2.html • http://www.comlab.uni-rostock.de/research/tools.html