Showing posts with label packet analysis. Show all posts
Showing posts with label packet analysis. Show all posts
Friday, March 21, 2014
Labels:
packet analysis
,
Wireshark
Since the packet details are structured according to layer-specific information, I can quickly expand a collapsed section related to the target of my search. Pro-tip: this is where understanding networking and application behavior is really helpful. Don't worry if you're not familiar, because this is also what helps you learn how the packets are placed onto the wire. Let's dive into this one layer at a time.
What's funny about this part of the packet view is that if you take away the bracketed lines, there's not much info left! Interface ID, Encapsulation Type, Arrival Time, Epoch Time, Frame Number, Frame Length, and Capture Length. I'm still learning, of course, but what I've found is the most important is the Frame Number. When troubleshooting a network communication issue, it's extremely helpful to guide someone else through the packet capture using the Frame Number as a point of reference.
With or without expanding the Ethernet header, we can see the source MAC address and destination MAC address. This is handy when troubleshooting an outbound packet, because you can see where the packet was destined to reach. Typically, this destination MAC belongs to the default gateway, but it depends on the network topology.
What's nice in troubleshooting as well is that the first six hexadecimal digits are parsed by Wireshark to display the user-friendly NIC identifier, commonly referred to as the manufacturer's registered identification number. If you know your device, then you can easily recognize the packets sent and received by your device based on MAC. Why is this important? Load-balanced clusters that share a virtual IP address.
In the IP header, we see the source and destination IP addresses. When dealing with packets on WAN links, sometimes people utilize the DiffServ Code Point value (DSCP) as a Quality of Service mechanism to classify packets into prioritized buckets. Higher-priority packet buckets get processed first.
Focusing on the highlighted line in blue, we quickly see the source port and destination port. From those numbers, it's typically easy to recognize which is the sender and receiver. When a host sends a packet to another host, the port chosen on the source is a randomized ephemeral port higher than port 1024. The destination host in this case is a webserver, which makes sense since we're looking at an HTTP packet, and the destination port is 80 (the normal server port over which HTTP connections are established).
In the exploded view, we see the Flags section which indicates certain information related to the nature of the connection. For instance, the Push flag is set, which is an indicator that the packet should be processed up to Layer 7 because the source is sending data to the destination. In this packet, that data is the URL in the GET request. It's at this part of the packet attacks like the Christmas Tree attack are initiated against a webserver. This video explains it perfectly:
Expanding the HTTP layer, we see the formation of the GET request. Bonus points on my imaginary scoreboard if anyone can let me know in the comments whether the request is explicit or transparent. In the GET request, I can see the HTTP protocol version used (1.1) and the path of the request. The path in this packet is "/", meaning it was a request for the root web directory.
The Host Header instructs the server to send the root web directory back for www.msn.com. Can anyone guess why the Host Header is important? Think about it for a second, and then you can check your answer.
Below the Host Header, we can see other HTTP Request Headers the browser of the source host sent to the webserver. The ones to discuss are User-Agent, DNT, Accept, Accept-Encoding, and Accept-Language, but head on over to my HTTP Headers post if you're interested. In this here post, we're focusing on the packets!
At the very bottom of the HTTP layer of the packet, you can see some helpful bracketed information Wireshark parsed out for us. We can see the Full request URI, which means the request was observed as http://www.msn.com. And we see that the webserver responds to this packet [Frame 294, see above] in Frame 389. That allows you to scroll through the packet capture to Frame 389 to see what the server sent back.
Read More
Packet Analysis 101 - Wireshark's Packet Details
"The time has come," the Walrus said,You've already seen how to use Wireshark to take a packet capture, how to set capture filters, and how to set display filters. In this post, we're going to talk about Wireshark's Packet Details View.
"To talk of many things:
Of bits-and bytes-and frame headers--
Of trace routes-and pings...
Packet Details
What's nice about Wireshark's Packet Details View is that it parses out the packet in easy to read sections that map to the OSI model:Since the packet details are structured according to layer-specific information, I can quickly expand a collapsed section related to the target of my search. Pro-tip: this is where understanding networking and application behavior is really helpful. Don't worry if you're not familiar, because this is also what helps you learn how the packets are placed onto the wire. Let's dive into this one layer at a time.
Packet Frame Header
Let's expand the Frame Header line and see what we get.
Some important things to note first before we discuss too many details. When you expand a "layer" in the Packet Details View, anything in brackets is something not found in the actual packet, but is inserted by Wireshark during the loading of the packet capture. Fun stuff to note for later includes the time delta and coloring rule.What's funny about this part of the packet view is that if you take away the bracketed lines, there's not much info left! Interface ID, Encapsulation Type, Arrival Time, Epoch Time, Frame Number, Frame Length, and Capture Length. I'm still learning, of course, but what I've found is the most important is the Frame Number. When troubleshooting a network communication issue, it's extremely helpful to guide someone else through the packet capture using the Frame Number as a point of reference.
Ethernet Header (OSI Layer 2 - Datalink)
With or without expanding the Ethernet header, we can see the source MAC address and destination MAC address. This is handy when troubleshooting an outbound packet, because you can see where the packet was destined to reach. Typically, this destination MAC belongs to the default gateway, but it depends on the network topology.
What's nice in troubleshooting as well is that the first six hexadecimal digits are parsed by Wireshark to display the user-friendly NIC identifier, commonly referred to as the manufacturer's registered identification number. If you know your device, then you can easily recognize the packets sent and received by your device based on MAC. Why is this important? Load-balanced clusters that share a virtual IP address.
IP Header (Layer 3 - Network)
TCP Header (Layer 4 - Transport)
Because HTTP is a TCP-based protocol, we have a TCP header present.
Focusing on the highlighted line in blue, we quickly see the source port and destination port. From those numbers, it's typically easy to recognize which is the sender and receiver. When a host sends a packet to another host, the port chosen on the source is a randomized ephemeral port higher than port 1024. The destination host in this case is a webserver, which makes sense since we're looking at an HTTP packet, and the destination port is 80 (the normal server port over which HTTP connections are established).
In the exploded view, we see the Flags section which indicates certain information related to the nature of the connection. For instance, the Push flag is set, which is an indicator that the packet should be processed up to Layer 7 because the source is sending data to the destination. In this packet, that data is the URL in the GET request. It's at this part of the packet attacks like the Christmas Tree attack are initiated against a webserver. This video explains it perfectly:
HTTP (Layer 7 - Application)
At last, we see the application layer! This part of the packet can help us get a measure of what the source did and how the server may respond. In this packet we see HTTP, but in future posts we'll discuss other Layer 7 protocols and the communication involved.
The Host Header instructs the server to send the root web directory back for www.msn.com. Can anyone guess why the Host Header is important? Think about it for a second, and then you can check your answer.
Below the Host Header, we can see other HTTP Request Headers the browser of the source host sent to the webserver. The ones to discuss are User-Agent, DNT, Accept, Accept-Encoding, and Accept-Language, but head on over to my HTTP Headers post if you're interested. In this here post, we're focusing on the packets!
At the very bottom of the HTTP layer of the packet, you can see some helpful bracketed information Wireshark parsed out for us. We can see the Full request URI, which means the request was observed as http://www.msn.com. And we see that the webserver responds to this packet [Frame 294, see above] in Frame 389. That allows you to scroll through the packet capture to Frame 389 to see what the server sent back.
Conclusion
This post focused on a single HTTP packet and explained Wireshark's Packet Details View of that packet. If you have any questions or just want to let me know how awesome it was to read this post, please leave a comment below!
Tuesday, February 18, 2014
Labels:
packet analysis
,
Wireshark
Packet Analysis 101 - Wireshark Display Filters
Now that you're familiar with capture filters, let's discuss display filters.
For another great cheat sheet that prints great and looks good in a binder or on your cube wall, check out PacketLife.net's Wireshark Display Filters.
While you're there, be sure to download the tcpdump cheat sheet as well! We'll be visiting PacketLife.net much more in future posts.
Read More
 |
| It's a port scan! |
Display Filters
Display filters can be applied during a live packet capture, as well as when reviewing an old packet capture like the one above (provided for the MDC3 forensics qualifying round).
See the Filter field above? That's where we build our expression to sift through the collected packets to display only those we're interested in reviewing. The syntax for these expressions is different than those discussed in the capture filters post. Here's an example of what I mean:
| Capture Filter | host 192.168.152.150 | |
|---|---|---|
| Display Filter | ip.src==192.168.152.150 |
See how much more specific display filters can be? In the example above, not only are we identifying a host, we're saying we want to view all packets where that host is the source. Using the same port scan pcap above, applying that display filter results in this:
Um, Cheat Sheets Please?
So, where do we go from here? Learn the display filters! Here are some examples to get you started:| Packets with port 443 | tcp.port==443 | |
|---|---|---|
| Packets with destination port 443 | tcp.dstport==443 | |
| HTTP GET requests | http contains GET | |
| 401 authentication challenges | http contains 401 | |
| Java user-agent strings | http.user_agent contains Java | |
| Packets to and from a host | ip.addr==192.168.152.150 | |
| SSL Certificates | ssl.handshake.certificate | |
 |
| PacketLife.net - Wireshark Display Filters |
More on Expression Syntax
In my few examples above, you may notice a pattern or two. The display filter begins with an argument identifier (ip, http, ssl, tcp) and can be used by itself or modified.
Using arguments by themselves is a great way to quickly sift through protocol-specific segments of a pcap. For instance, if I'm troubleshooting a DNS issue, all I have to type is dns in the filter and all other protocols are excluded.
These arguments have tons of modifiers. Take http for example. Open up Wireshark and type http followed by a period "." Wireshark recognizes that you're about to modify the filter argument and will show you a list of what's available.
Using arguments by themselves is a great way to quickly sift through protocol-specific segments of a pcap. For instance, if I'm troubleshooting a DNS issue, all I have to type is dns in the filter and all other protocols are excluded.
These arguments have tons of modifiers. Take http for example. Open up Wireshark and type http followed by a period "." Wireshark recognizes that you're about to modify the filter argument and will show you a list of what's available.
To see a more comprehensive (and intimidating) list of what's available, click on the "Expression..." button. Go ahead, I dare ya.
Switching Display Filters
The last piece to remember when using display filters is that after you apply your expression, you have to clear it out to go back to viewing the previously filter-excluded packets. Give it a shot. Take a packet capture, filter for http and then filter for dns.
Next up, we'll be looking at individual packets! I know you're as excited as I am...
Friday, January 31, 2014
Labels:
packet analysis
,
Wireshark
Packet Analysis 101 - Wireshark Capture Filters
We're going to first discuss one of the two types of filtering available with Wireshark: capture filters. Before I go any further, if you're confused about what filters are and/or what Wireshark is, check out my first blog post to learn how to take a packet capture.
To set a capture filter, look for the Capture Options button on the left side underneath the interface listing. In the pop-up window, look for the Capture Filter option on the left and when you click it you'll see the short list of pre-defined capture filters.
You can select one of the templates and modify it to target the data you're hunting/troubleshooting.
Note the other parameters you can set, such as a time or size limit. When you modify a filter template or enter your own expression (based on those allowed), until it's in the proper syntax, Wireshark will highlight the Capture Filter field in red. Once you set the capture filter and click Start, Wireshark will begin monitoring the chosen interface using that capture criteria.
It's important to note that the capture filters are a different syntax than the display filters, and they're based on tcpdump filters. Check out a list of some sample capture filters.
When you open the capture filter list again, your new entry will be there! As I collect use cases for capture filters, I'll post a page with an index for easy reference.
Next up, we'll be discussing display filters.
Read More
Capture Filters
An often underused (where's the love?) component of Wireshark is the capture filter. Most people fire up Wireshark, select an interface and start capturing everything. That's great unless you have a scenario where you need to leave a capture running for a long period of time and/or have to sift through a huge amount of packets. Side note: This is also extremely handy in the Capture the Packet CTF.
To set a capture filter, look for the Capture Options button on the left side underneath the interface listing. In the pop-up window, look for the Capture Filter option on the left and when you click it you'll see the short list of pre-defined capture filters.
You can select one of the templates and modify it to target the data you're hunting/troubleshooting.
 |
| Selecting the template |
 |
| Changing the default value from "192.168.0.1" to 172.16.90.101 |
It's important to note that the capture filters are a different syntax than the display filters, and they're based on tcpdump filters. Check out a list of some sample capture filters.
Create Your Own Capture Filter
To create your own filter, when you have the Capture Filter pop-up open, click on New. Change the Filter name and Filter string fields to the values you want, and click OK. |
| This example looks for HTTP GET requests, excerpted from the Wireshark Capture Filter wiki page |
Next up, we'll be discussing display filters.
Tuesday, January 28, 2014
Labels:
packet analysis
Ten years ago, when someone couldn't check their email or perform a web-based task, it was always a question of whether the server was actually receiving power. These days, servers have drastically increased their availability so that server-specific outages have become rare. That fact means the blame when an application doesn't work typically falls on a device in the network boundary, and more often than not, the proxy and/or firewall.
So, how do you figure out where to target your efforts if your network looks like this?
Read More
Packet Analysis 101 - Initiating the Capture
Let's Look at the Packets!
How often have you heard, "This application isn't working. Is it the [IPS/IDS/Proxy/Firewall] again?"Ten years ago, when someone couldn't check their email or perform a web-based task, it was always a question of whether the server was actually receiving power. These days, servers have drastically increased their availability so that server-specific outages have become rare. That fact means the blame when an application doesn't work typically falls on a device in the network boundary, and more often than not, the proxy and/or firewall.
So, how do you figure out where to target your efforts if your network looks like this?
 |
| Only a slight exaggeration... |
Obviously there are other elements to troubleshoot, but it's often helpful and sometimes required to take a packet capture.
What is a Packet?
A packet is a binary package (001010101010) of information capable of being transmitted across the network from one device to another. We'll get into some specific examples in later posts. Packets have multiple layers, often referred to in sections as headers and footers. The headers contain transmission-related information with the footer containing the application data.
A common reference for packet header analysis is the SANS TCP/IP and tcpdump cheat sheet. The image below shows excerpts including the Ethernet header (OSI Layer 2), the IP header (OSI Layer 3), and the TCP header (OSI Layer 4).
 |
| TCP/IP headers from SANS, with Ethernet added by me |
Notice how I arranged the header in layers. These layers follow the abstract, but logical, OSI model. It's also helpful to recognize them this way when you analyze packets from a capture.
What is a Packet Capture?
A packet capture is exactly what it sounds like, although some people refer to it as "packet sniffing". It's a collection of network packets transmitted by and/or between any number of combinations of such devices as those in the nightmare diagram above. The next logical question is...
How do I Capture Packets?
People more commonly ask, "How do I take a packet capture?" To do so, we need a tool. For the express purpose of capturing packets, several are available including: Wireshark (my fav), Network Miner, NetWitness Investigator (Direct Download Link), Microsoft Network Monitor, and Capsa. They all have unique attributes and capabilities, so I suggest experimenting with them to find out which one you prefer.
To get you started, our friends over at Hak5's YouTube channel made a great introductory video using Wireshark:
Although there are video tutorials on the other tools, those videos focus more on the use of the tool rather than initiating a capture using the tool. If I find them, I'll post them, but in the mean time check out Wireshark!
Subscribe to:
Posts
(
Atom
)
