Welcome!

.NET Authors: Pieter Van Heck, Maxime Charlès, Bob Gourley, RealWire News Distribution, Jayaram Krishnaswamy

Related Topics: AJAX & REA, .NET, Security

AJAX & REA: Tutorial

Intruder Detection with tcpdump

tcpdump tool

To capture, parse, and analyze traffic tcpdump is a very powerful tool. To begin a basic capture uses the following syntax.

tcpdump -n –i <interface> -s <snaplen>

-n      tells tcpdump to not resolve IP addresses to domain names and port numbers to service names.
-I       <interface> tells tcpdump which interface to use.
-s      <snaplen> tells tcpdump how much of the packet to record. I used 1515 but 1514 is sufficient for most cases. If you don’t specify a size then it will only capture the first 68 bytes of each packet. A snaplen value of 0 which will use the required length to catch whole packets can be used except for older versions of tcpdump.

Below is an example output of a dump, although it only contains a few lines it holds much information.

12:24:51.517451  IP  10.10.253.34.2400 > 192.5.5.241.53:  54517 A? www.bluecoast.com.  (34)

12:24:51:517451                              represent the time
10.10.253.34.2400                          Source address and port
>                                                          Traffic direction
192.5.5.241.53                                 Destination address and port
54517                                                 ID number that is shared by both the DNS server 192.5.5.241 and 10.10.253.34
A?                                                        10.10.253.34 asks a question regarding the A record for www.bluecoat.com
(34)                                                     The entire packet is 34 bytes long.

More tcpdump capture options

Here are some examples of options to use when capturing data and why to use them:

-I        specify an interface; this will ensure that you are sniffing where you expect to sniff.
-n       tells tcpdump not to resolve IP addresses to domain names and port numbers to service names
-nn    don’t resolve hostnames or port names
-X      Show packet’s contents in both hex and ASCII
-XX    Include Ethernet header
-v       Increase verbose –vv –vvv more info back
-c       Only get x number of packets and stop
-s       tell tcpdump how much of the packet to record
-S       print absolute sequence numbers
-e       get Ethernet header
-q       show less protocol info
-E       Decrypt IPSEC traffic by providing an encryption key

Packet, Segment, and Datagram
TCP accepts data from a data stream, segments it into chucks, and adds a TCP header creating a TCP segment. UDP sends messages referred to as a datagram to other hosts on an Internet Protocol (IP) network without requiring prior communications to set up special transmission channels or data paths. Internet Protocol then creates its own datagram out of what it receives from TCP or UDP. If the TCP segment or UDP datagram plus IP’s headers are small enough to send in a single package on the wire then IP creates a packet. If they are too large and exceed the maximum transmission unit (MTU) of the media, IP will fragment the datagram into smaller packets suitable to the MTU. The fragmented packets are then reassembled by the destination.

Tcpdump read and write to/from a file
Tcpdump allows you to write data to a file using the –w option and to read from a file with the –r option.

$ sudo tcpdump -i wlan0 -w dumpfile001

$ sudo tcpdump -r dumpfile.pcap

Some people like to see the files as they are captured and have them saved to a file. Use the following options: tcpdump –n –I eth1 –s 1515 –l | tee output.txt
This option tells tcpdump to make its output line-buffered, while piping the output to the tee utility sends output to the screen and the output.txt simultaneously. This command will display packets on the screen while writing data to an output file output.txt it will not be in binary libpcap format. The best way to do this is run a second instance of tcpdump.

Timestamps
When tcpdump captures packets in libpcap format, it adds a timestamp entry to the record in each packet in the capture file. We can augment that data with the –tttt flag, which adds a date to the timestamp (See Figure #1).

Figure 1

You can use the –tt flag to report the number of seconds and microseconds since the UNIX epoch of 00:00:00 UTC on January 1, 1970. If you are not sure you understand the time difference and need to be absolutely sure of time use the –tt option to show seconds and microseconds since the UNIX epoch (See Figure #2).

Figure 2

Useful syntax
Being able to cut the amount of traffic down to just what you are looking for is useful. Here are some useful expressions that can be helpful in tcpdump.

Net – This will capture the traffic on a block of IPs ex 192.168.0.0/24
# tcpdump net 192.168.1.1/24
Src, dst – This will only capture packets form a source or destination.
# tcpdump src 192.168.100.234
# tcpdump dst 10.10.24.56

Host – Capture only traffic based on the IP address
# tcpdump host 10.10.253.34
Proto – Capture works for tcp, udp, and icmp
# tcpdump tcp
Port – Capture packets coming from or going to a port.
# tcpdump port 21
Port ranges – capture packets
# tcpdump port 20-25
Using expressions such as AND [&&], OR [||], & EXCEPT [!]
# tcpdump –n –I eth1 host 10.10.253.34 and host 10.10.33.10
# tcpdump –n –I eht1 src net 10.10.253.0/24 and dst net 10.10.33.0/24 or 192.5.5.241
# tcpdump –n –I eth1 src net 10.10.30.0/24 and not icmp

Searching for info on packets with tcpdump
If you want to search for information in the packet you have to know where to look. Tcpdump starts counting bytes of header information at byte 0 and the 13th byte contains the TCP flags shown in Table #1

<----byte12-----------><--------byte13----------><-----------byte14-----><------byte15------->

Talbe #1

Now looking at byte 13 and if the SYN and ACK are set then your binary value would be 00010010 which are the same as decimal 18. We can search for packets looking for this type of data inside byte 13 shown here.


# tcpdump –n –r dumpfile.lpc –c 10 ‘tcp[13] == 18’ and host 172.16.183.2

Here is a sample of what this command will return shown in Figure #3

Figure #3

When capturing data using tcpdump one way to ignore the arp traffic is to put in a filter like so.


# tcpdump –n –s 1515 –c 5 –I eth1 tcp or udp or icmp

This will catch only tcp, udp, or icmp.

If you want to find all the TCP packets with the SYN ACK flag set or other flags set take a look at Table #2 & tcpdump filter syntax shown below.


flag           Binary           Decimal
URG         00100000          32
ACK          00010000          16
PSH          00001000           8
RST          00000100           4
SYN          00000010           2
FIN            00000001           1
SYNACK  00010010         18

Table #2

Tcpdump filter syntax

Show all URGENT (URG) packets
# tcpdump ‘tcp[13] == 32’
Show all ACKNOWLEDGE (ACK) packets
# tcpdump ‘tcp[13] == 16’
Show all PUSH (PSH) packets
# tcpdump ‘tcp[13] == 8’
Show all RESET (RST) packets
# tcpdump ‘tcp[13] == 4’
Show all SYNCHRONIZE (SYN) packets
# tcpdump ‘tcp[13] ==2’
Show all FINISH (FIN) packets
# tcpdump ‘tcp[13] == 1’
Show all SYNCHRONIZE/ACKNOWLEDGE (SYNACK) packets
# tcpdump ‘tcp[13] == 18’

Using tcpdump in Incident Response

When doing analysis on network traffic using a tool like tcpdump is critical. Below are some examples of using tcpdump to view a couple of different dump files to learn more about network problems or possible attack scenarios. The first is a binary dump file of a snort log and we are given the following information. The IP address of the Linux system is 192.168.100.45 and an attacker got in using a WU-FTPD vulnerability and deployed a backdoor. What can we find out about how the attack happened and what he did?

First we will take a look at the file

# tcpdump –xX –r snort001.log
The log appears long at this point you may want to run the file in snort
# snort –r snort001.log –A full –c /etc/snort/snort.conf
This will give you some info like total packets processed, protocol breakdown, any alerts, etc. See Figure #4 & #5

Figure #4                                                                               Figure #5

Next extract the full snort log file for analysis

# tcpdump –nxX –s 1515 –r snort001.log > tcpdump-full.dat

This will give us a readable file to parse through. After looking through it we find ip-proto-11, which is Network Voice Protocol (NVP) traffic. Now we will search through the file looking for ip-proto-11.


# tcpdump –r snort001.log –w NVP-traffic.log proto 11
This command will read the snort001.log file and look for ‘log proto 11’ and writes the contents to the file NVP-traffic.log. Next we need to be able to view the file because it is a binary file.

# tcpdump –nxX –s 1515 –r NVP-traffic.log > nvp-traffic_log.dat
This will be a file of both hex and ASCII, which is nice but we just want the IP address. Try this.

# tcpdump –r NVP-traffic.log > nvp-traffic_log01.dat
This will give us a list of IP address that were communicating using the Network Voice Protocol (NVP) (See Figure #6).

Figure #6

Next we look at another snort dump file from a compromised windows box that was communicating with an IRC server. What IRC servers did the server at 172.16.134.191 communicate with?

Look for TCP connections originating from the server toward the outside and we can use tcpdump with a filtering expression to capture SYN/ACK packets incoming from outside servers.

# tcpdump -n -nn -r snort_log 'tcp and dst host 172.16.134.191 and tcp[13]==18'

This produces a long list of connections going from 172.16.134.191 to outside connections. (see Figure #7).

Figure #7

Now we know that IRC communicate on port 6666 to 6669 so let’s add that and narrow down the search with the following command.
# tcpdump -n -nn -r snort_log 'tcp and dst host 172.134.16.234 and tcp[13]==18' and portrange 6666-6669 (See output in Figure #8 below)

Figure #8

Now we have narrowed the list down to 3 IP’s that were communicating with the server using IRC.


Tcpdump is a wonderful, general-purpose packet sniffer and incident response tool that should be in your tool shed.

More Stories By David Dodd

David J. Dodd is currently in the United States and holds a current 'Top Secret' DoD Clearance and is available for consulting on various Information Assurance projects. A former U.S. Marine with Avionics background in Electronic Countermeasures Systems. David has given talks at the San Diego Regional Security Conference and SDISSA, is a member of InfraGard, and contributes to Secure our eCity http://securingourecity.org. He works for Xerox as Information Security Officer City of San Diego & pbnetworks Inc. http://pbnetworks.net a Service Disabled Veteran Owned Small Business (SDVOSB) located in San Diego, CA and can be contacted by emailing: dave at pbnetworks.net.