If you export the data in PCAP format, you will lose your tags. I’m a big fan of Moloch but, with this kind of tools, added tags are stored in the ElasticSearch database.
![reading wireshark packet capture reading wireshark packet capture](https://www.howtogeek.com/wp-content/uploads/2017/06/img_593afb8ec1b55.png)
Tags are helpful to assign some flows to a case being investigated or to categorize them (“suspicious”, “exfiltration”, “exploitation”, etc). Later, you can search for them to find back interesting traffic: Some tools, like Moloch, allow you to “tag” some conversations. Many security tools can record samples of network traffic or you can maybe need a full-packet capture. Just keep in mind: it must be properly performed if your notes will be used as evidence later… With investigations, there are also chances to you will have to deal with packet captures. There is no “best” way to take notes, some people use electronic solutions while others are using good old paper and pencil. There are two more parts to read while we're on this topic, part 2 which shows examples from the real world and part 3 which will cover IPv6.Īny comments? Contact me via Twitter or e-mail.When you are investigating a security incident, a key element is to take notes and to document as much as possible. But I sure hope it was of some use to you - let me know in the comments below. If there's something you don't understand, ask away in the comments below. There a lot more to discover by poking around yourself, so here's the packet capture - open it in Wireshark and have a go at it.
![reading wireshark packet capture reading wireshark packet capture](http://1.bp.blogspot.com/_BaDa34raY3I/TJekZKJzjEI/AAAAAAAAAA0/ODd2pQJfR4k/s1600/Capture01c.png)
It's nowhere to be seen in the following fragments, as expected. You can check by taking the next 8 bytes after the IP header in the reassembled frame ( 08 00 25 f1 00 03 00 00) and looking for them in the first fragment. This means that the ICMP header will only be present in the first fragment ( offset=0). In the fragmentation process, everything coming after the IP header will be split up - in this case the ICMP header ( 8 bytes) and the data ( 8972 bytes). The ICMP header is there and the 8972 bytes of garbage that come with it for you to analyze. On the flip side, it does tell you that the packet has been reassembled from 7 fragments and it gives you the sizes and links to the fragments themselves. To make matters worse, the IP header shown inside the reassembled packet is the one from the last fragment (notice Fragment offset is 8880 and MF is 0). They key to that is noticing the tab that appears at the bottom which says Reassembled IPv4 (8980 bytes). It shows a combination of the contents (and size) of the last fragment to arrive ( 134 bytes), but it also shows the reassembled packet in all its glory ( 8980 bytes). The most important information is in the last entry ( #7 for the request and #14 for the reply).
#Reading wireshark packet capture windows#
The ping command on Linux or Windows will put 9000 Bytes inside the ICMP packet, resulting in a 9028 Byte IP packet. One tiny bit of information: a ping command in IOS with a size of 9000 will calculate the ICMP payload so that the total IP packet is 9000 Bytes in length. As the link between those two routers runs a 1500 MTU, this bad boy has to be fragmented. Errr, what? Worry not, it shall all be explained below! What's the capture about?įirst thing's first, the screenshot above shows a capture of a ping between two routers in GNS3 with a size of 9000. You can see a bunch of fragments, which it says are Reassembled in #7, but packet number 7 has a size of 134.
![reading wireshark packet capture reading wireshark packet capture](http://2.bp.blogspot.com/-NcB-jyamEnk/TzeQE7H17kI/AAAAAAAAEzg/dhLNxlcsYsg/w1200-h630-p-k-no-nu/test.cap.png)
It always looked dodgy to me and I didn't make the effort to make some sense out of it.
#Reading wireshark packet capture how to#
Up until recently, I have to shamefully admit, I had no idea how to read a Wireshark capture of fragmented packets. It also might cause engineers to lose their sanity while troubleshooting weird problems. It's what happens when a big packet spawns a lot of smaller baby packets because the MTU is not big enough, be it anywhere in transit (IPv4) or only at the source (IPv6).