VKernel.co.uk – Your interface to the world

Packet Capture – Size manipulation

Splitting a very large packet capture

If a packet capture is over a certain file size, i.e. 300Mb+, it may be beneficial for processing / distribution purposes to split it into smaller chunks. You can do this using the “editcap” Wireshark command.

(For Windows) – Firstly, copy the packet capture to your “C:\Program files\Wireshark” folder. Then use the “capinfos -c” command on the packet capture to find out how many packets it contains, as below:

C:\Program Files\Wireshark>capinfos -c samplepacketcapture.cap
File name: samplepacketcapture.cap
Number of packets: 1070031

As we have 1,070,031 packets, it may be beneficial to split them into pcaps of 50,000 each:

C:\Program Files\Wireshark>editcap -c 50000 samplepacketcapture.cap

When the command has completed succesfully, there will be an amount of small .cap files in the same directory of 50,000 packets each.

Merging lots of packet captures into a single Pcap

Sometimes we may wish to merge multiple packet captures i.e. 4-5 100Mb Packet Captures into a single one for analysis and to remove errors such as “Ack received for unknown packet” etc. To do this, (For Windows) – Firstly, copy the packet capture to your “C:\Program files\Wireshark” folder. Then, we can use the “mergecap.exe” program, similar to how editcap works.

C:\Program Files\Wireshark\mergecap.exe -w master-cap.cap subcap1.cap
subcap2.cap subcap3.cap

In this command, we are merging subcap1 – subcap3 into a few file, called master-cap.cap.

Thats all there is to it. For references, some useful operators are:

Usage: mergecap [options] -w <outfile>|- <infile> ...
Output:
 -a                concatenate rather than merge files.
                   default is to merge based on frame timestamps.
 -s <snaplen>      truncate packets to <snaplen> bytes of data.
 -w <outfile>|-    set the output filename to <outfile> or '-' for stdout.
 -F <capture type> set the output file type; default is libpcap.
                   an empty "-F" option will list the file types.
 -T <encap type>   set the output file encapsulation type;
                   default is the same as the first input file.
                   an empty "-T" option will list the encapsulation types.
 -h                display this help and exit.
 -v                verbose output.

Tcpdump – Usage and operators

“tcpdump”: Installation and Options

TCPDump is a de facto packet capturing tool for Linux, Unix etc. Its usage is outlined below.

Installation is very often not required as it is bundled with most operating systems; if not then there are various ways to install using apt-get install, yum install, etc or you can download the source and compile accordingly.

To run tcpdump, you simple need to run the command “tcpdump” from CLI as such:

root@SRM-TAC-2010:~# tcpdump

There are many TCP dump flags which are useful operators; a list of which can be found here [13].

Normal usage would be:

1. List all interfaces we are able to listen on, using the command:

root@SRM-TAC-2010:~# tcpdump -D

This will give you an output such as:

root@SRM-TAC-2010:~# tcpdump -D
1.eth0
2.any (Pseudo-device that captures on all interfaces)
3.lo

As above, the NIC we want to listen to is “eth0″ as the other 2 are “all NIC’s” and the loopback interface. As such, we will note the integer on the far left, in this example “1″.

2. Now we know we want to listen on interface “1″, we run the command:

root@SRM-TAC-2010:~# tcpdump -i 1

This will kick off the windump capture on interface 3, giving an output like so:

root@SRM-TAC-2010:~# tcpdump -i 1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

[traffic removed for blog]

10 packets captured
13 packets received by filter
0 packets dropped by kernel

3. Obviously, we dont want to output it to CMD as its very hard to process in tools such as Wireshark and we dont want to be copying and pasting etc. So we run the command using the -w switch which tells the program to write (-w) to the file specified directly after (parameter), as such:

root@SRM-TAC-2010:~# tcpdump -i 1 -w outputfile.txt

This will write the packets to the file “outputfile.txt” to where you are running the program FROM i.e. in my example here, i am in the directory /root running the command “tcpdump” therefore my “outputfile.txt” is saved in /root/outputfile.txt. If i wanted to, i could create “/root/files/”, change directory there “cd /root/files/” and then run the command and the logs would be saved there.

If you try and open the “outputfile.txt” in vi, cat, etc you will see something along the lines of:

Ôò¡???*?½?E :#&à–›#P?úð€`

However, if you change it from “outputfile.txt” to “outputfile.cap” – you can then open it in Wireshark no problem at all for analysis.

4. However, in Wireshark if you run the command above, you may see the following packet header errors:

14	0.001629	10.1.1.102	10.1.3.42
SMB	NT Trans Response, <unknown>[Packet size limited during capture]

This is regarding the “Snarf” (-s) operator for the program. If the packet size is left at default (96) it should be ok for IP/TCP/ICMP/UDP, but may provide errors on things such as SMB, etc. You may need to increase the snarf (snaplen) to avoid seeing this error message; using “-s 150″ i havent ran into any errors so far. To use the -s flag, use the following:

root@SRM-TAC-2010:~# tcpdump -i 1 -s 150 -w outputfile.txt

This will result in packet captures being actually usable in Wireshark as below:

14	0.001500	10.1.1.102	10.1.3.42
SMB	NT Trans Response, NT NOTIFY

5. We may be inclined to use the option “-vvv” (“even more, even more verbose”) – this will give us more in-depth information in the packets i.e. printing telnet options in Hex etc – the command syntax as below:

root@SRM-TAC-2010:~# tcpdump -i 1 -s 150 -w outputfile.txt -vvv

This should give a very readable, useful packet capture. Finally, we may wish to limit the amount of packets we capture, we can do this using the -c (small c) flag, as such:

root@SRM-TAC-2010:~# tcpdump -i 1 -s 150 -w outputfile.txt -vvv -c 15000

This will limit the # of packets captured to 15000.

Hope this helps!

Sam

Tags: tcpdump

Path MTU Discovery

Path MTU  Discover (PMTUD) from herein is a technique for determining the MTU size on a network path beetween 2 IP addresses; the source IP and the destination IP (reference the previous blog post on TCP flows).

The network path is the path in which the packets/datagrams have to traverse in order get from sourceip:port to destinationip:port. This path can include router interfaces, firewall interfaces, switch interfaces, etc. All of which will have an MTU value (Maximum Transmission Unit). This MTU value is simply a filter, which if the packet exceed it will be dropped. Say for example, the router interface we are going via has an MTU of 1422 (this is in bytes). If we transmit packets with a size of 1522, the packets will either be dropped if the sending TCP stack has the DF (Dont Fragment) bit set; or the packet will be fragmented which does affect network performance.

Now the problem is you need to either set all MTU’s to a fixed value on your ethernet LAN (1500, for example) and then ensure all packets transmitted comply with this, accept that fragmentation will happen – for example when using an MTU of 9000 with jumbo frames, or use PMTUD.

PMTUD is relatively simple in its complexity. If enabled, the packet will be sent out with a size of 1522. When it hits the interface with a MTU 1422, which it cannot pass through, the packet is dropped and a message is sent back to the sender saying “It was too big, the MTU of the interface was 1422″. The sender will then update their MTU to 1422, and re-send. It will now pass through the first interface as its size is now =< 1422.

It does this repeatedly until it reaches the destination IP; once it can achieve such a path it can be said the path MTU is 1422 (if no further interfaces with lower MTU’s are found).

Delving a little more into the details, the way this “It was too big, the MTU of the interface was 1422″ message is relayed back to the source IP is via ICMP. The router will send an ICMP “Fragmentation Needed” message back to the source IP, containing the MTU value in question (1422). The ICMP “Fragmentation Needed” message, for reference, is Type 3, Code 4.

The problem with such a feature is the fact that ICMP is often misunderstood and misconfigured. Some security personnel see it as the devil and as such block all ICMP. If this happens, the connections will complete at a TCP level (SYN, SYNACK, ACK) and establish a flow, however the connection will “hang” when the data begins transfer. This state is often referred to as a “black hole connection”. Therefore i stress that if you are indeed going to use PMTUD, ensure that the ICMP path beetween hosts is also clear and alive.

Sam

Tags: ICMP, PMTUD