Posts Tagged ‘Packet Analysis’
Wireshark 3.0 Released
Recently, Wireshark dropped a major release which adds a few cool features (some new and some old). However outside of the new features, there is one major under the hood change this feature introduces. WireShark v3 for Windows now ships with Npcap as opposed to Winpcap that we have been used forever now. Npcap is actually part of the NMAP project which while Npcap is build of Winpcap Npcap gets a little more love in regards to up updates and being actively worked on. A while back I did a look at how Winpcap interacts with the NIC cards and captures packets, Even though Npcap is based off Winpcap I am curious to see if that underlying interaction has changed (more to come on that, or I’ll just update this blog post later on with my findings)
A few other features:
- IP Mapping has returned
- Monitor mode support for Windows wireless analysis. This is a huge one in my book, this functionality was brought over from the Npcap change.
- A few other random tidbit, bootp dissector is getting renamed to dhcp. Similar to SSL getting renamed to TLS.
- ciscodump now supports a proxy connection, I am going to need to check this out, as ciscodump utilizes the Cisco EPC capability. Which apparently I haven’t got to kick the tires on just yet. So, I think I am late to the game on this one, but proxy supports make this easier for some environments.
- There are quite a bit more changes, many new protocols were added and well as even protocols were updated.
For the sake of brevity I don’t to cover everything, just a few of the pieces are find more interesting and useful.
Link to the Wireshark release notes page.
Wireshark tid-bit: Using profiles & Coloring rules
Well, my first draft got lost in the cloud so let’s try this again!
The more you use Wireshark and the more familiar you get with protocols / packet analysis the quicker you realize what you may need to for. Luckily for us, if we know what we are looking for we can configure Wireshark to turn that needle in a haystack into a firework on the middle of Halloween. It does this by giving us the flexibility to control what information Wireshark displays to us and how Wireshark displays that information. The two most useful features we have are profiles and coloring rules, both of these are very powerful features and using both of these features together allows you to take your analyzing skills to the next level.
Profiles – Profiles give us the ability to control what information Wireshark displays to us, and how the information is displayed.
- Affecting the complete layout of the Wireshark display
- What columns are displayed in the Wireshark display
- Which coloring rules are in affect
Now, that we know some of the ways profiles affect Wireshark lets consider a few good use cases for profiles, below are a few profiles I have.
- Wired-VoIP – This profile will call out the DSCP field as specific column to easily keep an eye on QoS marking.
- Remote-Site-VPN – Calls out specific columns for the DF-Bit, IP & TCP length, and more fragment field.
- Wired-Transaction-Time – Contains specific columns for relative time & absolute time, etc.
Those are just a few ways profiles can be leveraged, and remember it is easy enough to flip from one profile to the next. There is no need to even close the current capture or restart Wireshark. This allows to quickly scroll through a single capture looking for key characteristics.
Coloring Rules – These coloring rules define how Wireshark displays the individual packets, it’s these same coloring rules that make re-transmissions show up in red. It’s important to remember that coloring rules are match from top-to-bottom and they will by specific criteria found in the packet. These coloring rules are tied to specific profiles, so you definitely want to keep in mind what profile you are working under.Below are a few of my coloring rules:
- WLAN-RETYU-PACKET – This filter looks to see if the packet is a retransmission of the RF medium. Might be useful if you are troubleshooting a WLAN performance issue.
- FRAG-PACKET – This rule calls out any fragmented packets by keeping an eye out on the ‘More Fragments’ bit. Could be a useful statistics if you working on performance issues in remote IPSec VPN locations.
- Kerberos_MSG – This filter actually picks any kerberos related packets, cause sometimes when Windows says the login failed due a network timeout it might really be due to a kerberos authentication issue. (FYI: Kerberos type 30 messages are errors. So you can be a bit more specific with this filter if desired)
- PC-1500-MTU – This Filter actually matches on two packet fields. First we make sure the packet is a ‘SYN’ packet, and then look to see if the TCP Max Segment Size is at 1460 which ideal for Ethernet networks. Sequentially, there is also a coloring rule for when the PC advertises a MSS that is not 1460. (PCI-NOT-1500-MTU)
Those are just a few examples to show how powerful the coloring rules can be, we can match on any field within the packet regardless of whether it is the Layer 2 MAC address or a piece of data with the application payload. Not mention we can match by multiple fields at the same time, talk about potential! The only thing I want to re-iterate is the matching is top to bottom, so in this example when Wireshark finds a Kerberos message it will hit the first coloring rule and no other even it is a retransmission. That is just something to keep in mind.
You can verify why a coloring rule is in affect by looking at the ‘Frame’ portion of the packet:
From the above, you can see which coloring rule we hit and why we matched this specific coloring. Very useful in the event we ever need to troubleshoot our own coloring rules.
So, now that we spent all this time creating profiles and coloring rules how do we back them up or transfer them to another laptop/desktop? Well, all these configurations can be transferred and backed up by copying only a few folders. If you are running Windows 7, you’ll find this under AppData\Roaming\Wireshark for your specific windows account.
It’s the Profiles folder we really want, once we take a look in there we see our specific profiles. Although you will probably be better off just copying the entire ‘Wireshark’ directory.
Wireshark tid-bit: Quickly gathering the contents of a PCAP.
I don’t know about you but when I find myself performing packet captures and analyzing PCAPs I usually only know the symptoms of the issue I am attempting to troubleshoot. IE: Connection timeouts, slow response, long transfer times, etc. I usually don’t know much more than that, only in rare occasions do I get a heads up and insight into the behaviors of the application I am trying to troubleshoot. For all the other situations I need to rely on the PCAPs and interpret what and how the applications are communicating. Whether or not the application is behaving properly and performance is as it should be or if there is indeed something amiss somewhere.
Now for me the easiest way to do this is by using the reviewing the ‘Summary’ page under the ‘Statistics’ menu. A sample summary page is below:
A few great call-outs from this screen:
- Packet Size Limit -Knowing whether or not the packets within the capture were sliced after the first so many bytes is important to know, as sometimes you might not see the entire TCP header or wireshark will start classifying the packets as malformed. Although you will also see a ‘Truncated’ message within the packet indicating the packet was sliced.
- First Packet, Last Packet, & Elapsed time -Matching up the time of a packet capture with when the particular issue occurred is crucial, after all you don’t want to find yourself analyzing the wrong capture. The Elapsed time is important to make note of as this give you the ability to establish a baseline, knowing how long a process takes can you help you identify an issue or identify expected behavior in the future.
- Avg. Packet Size – Depending on what you are trying to troubleshoot the average packet size can be a quick indicator in regards to whether or not your fully using the MTU an your network. If you are troubleshooting data transfers normally you would expect the Avg. Packet to be quite large. If you see exceptionally small packet sizes data transfers may take a lengthy amount of time due to the increase TCP overload and normal L3 forwarding. Same goes for the Avg Mbit/sec, if you have large packets flowing you can expect to see a higher throughput rate, and the opposite for lower packet size rate.
The next spot that is worth checking out is the ‘Conversations’ which is also found under ‘Statistics’ this quaint little window gives you a brief overview of any Source/Destination devices identified within the capture. From an L2 Ethernet perspective up to a L4 TCP/UDP Perspective allowing you see what end points are really involved with this communication along with how much data was sent, the length of time the connection, etc. It’s not completely unheard of for applications to communicate with other devices (Web Servers, DB Servers, File Servers, Other App Servers) to perform whatever tasks it is trying to perform and it could be very possible this third server may or may not be slowing down the process.
So by using these two windows in Wireshark you’ve identified the following:
- The length of time the process take. – Found in the elapsed time of the capture, as long as the entire process was captured that is.
- The endpoints involved with this communication. – Remember it is important to cut down as much background noise as possible.
- How much data is transferred and at what size & rate. – This can very helpful when working data transfers.
Wireshark Tid-bit: What does the IP Identification field tell us?
There are many different fields in the various headers we get to examine during packet analysis, one of the most overlooked field is the IP Identification field. This simple 16-bit field is displayed in Hex and has a few different uses, most importantly:
- Identifies fragmented packets.
- Identifies the individual packets that the sender transmits.
How does this help us?
- Well, by reviewing the IP Identification numbers you can easily identify which packet was dropped in the conversation, by comparing the packet captures from two different capture points.
- This field can also give us a glimpse at how busy the end-devices are. The IP Identification field will increase by ‘1’ for every packet from the sender. Remember the IP ID Value is specific to each individual and not to a specific conversation. If you are following a specific conversation we may see consecutive IP ID #’s or we could see large jumps in the IP ID # intervals. Depending on the numbers this could tell us if the end-devices could be overloaded, or under-utilized and depending on the situation that could point us to a smoking gun.
- If the packets get fragmented they will have the same IP ID number, the Fragment Offset field will also be set as well. This is helpful in following a conversation over particular link changes.
- Seeing the same IP ID #’s in the same packet capture could also identify switching or routing loops within our network. The IP ID #’s will always increase, seeing the duplicate numbers means were are seeing the same packet more than once. The first thing you want to do is verify your capture point is functioning properly and make sure your capture point is in the right spot. Once you verified that it’s time to go hunting for the loop.
Quick Example:
By reviewing the IP ID numbers of the packets what can we tell about this conversation with Wireshark.org?
- All the IP ID #’s are unique, no routing/switching loops
- The IP ID #’s are pretty consecutive on both sides of the conversation. Showing both endpoints are not being highly utilized at this point in time. In fact there are one or two gaps on the 192.168.1.4 side of the conversation showing that endpoint is a little busier than 162.159.241.165
Let’s look at: 802.11 Beacon Frames.
Probably the most common 802.11 management frame is the beacon frame. This frame is broadcasted from the AP listing the capabilities of the WLAN, but what exactly is listed? Let’s take a quick look.
Beacon frame from a Cisco WLAN
Here we can easily make out some of the capabilities of the WLAN, for example the SSID is probably going to be the first thing you notice TestSSID in this case, this is what provides the name of the WLAN. As you know SSID broadcasting can be disabled (Also called Closed System) at which point the SSID field will be blank.
Beacon frame with SSID broadcasting disabled. The SSID Information is simply excluded from the Beacon frame.
Next we will take a look at the what data rates are supported by this WLAN:
Here you can see the a few supported data rates and the extended supported data rates. This tells us the WLAN is capable of supporting both 802.11b and 802.11g WLAN clients. You’ll notice the Data rate of 5.5 has a (B) next to it, it just so happens 5.5 is set a mandatory data for this WLAN, so if a WLAN client can not support a data rate of 5.5 it will not be able to successfully authenticate and associate to the WLAN.
Next up we are going to at the RSN (Robust Security Network) information for this WLAN.
As you can see from the RSN Information element (IE), this WLAN is 802.11i compliant, showing it’s capable of AES/CCMP which means your WLAN clients will need to support 802.11i/WPA2 with AES in order to successfully communicate with this WLAN.
A few other noticeable features we can find in this beacon frame is the WLAN supports High-Throughput (HT), which is 802.11n (Draft 1 in this case). So this is an 802.11b/b/n WLAN in the 2.4 GHz RF range.
This access point did not have multiple antennas attached to it, which is why the TxBF and ASEL capabilities are currently at 0x0000 and 0x00.
You will also notice in the 6th line down that the WLAN is 802.11e compliant meaning some QoS will be performed, and the line after that states: no non-ERP STA’s, do not use protection this states no 802.11b clients are currently connected only 802.11g WLAN clients are currently connected to this WLAN so protection mechanism’s are not in use.
Now, at the end of the beacon frame you will notice all this Unknown information, as you have probably guessed (or read) this information is vendor specific, which is common for every vendor to have put their own proprietary information within the Beacon frames. The main thing is make sure this extra information does not create its own incompatible issues with older WLAN client devices.
So in conclusion there’s a basic Cisco WLAN beacon frame, it should be a mirror image of the configuration for your WLAN. Looking at the beacon is just a simple way to make sure the WLAN is doing what’s it’s configured to do.
Configuring a SPAN session.
A SPAN session is a way for you to have the traffic that is transmitted and/or received from one port or VLAN and have it forwarded out another port for analysis purposes. It’s very easily configured by a few small statements and the only thing you have to decide on is which port you want to monitor, the traffic flow you want to see from that port (egress, ingress, or both) and the destination port you want the traffic sent to. (See the configuration below)
Note: For this local SPAN session both the source port and destination port must be on the same switch. RSPAN allows SPAN sessions across remote switches, but I will not be covering RSPAN in this post.
Their isn’t much to consider concerning the source port since it will not be effected at all, the destination port however is treated a bit differently. First off the destination port will be put in a “Monitor” mode, meaning traffic received on this port will be dropped. Only traffic from the source port will be transmitted out of the destination port by the switch that’s it.
You can issue the sh monitor session # command to see if their are any active SPAN sessions on the switch, or if you want to see the details of a configured SPAN session. The source port (fa0/1), traffic flow (both), destination port (fa0/2), and the encapsulation, are all shown in the command. To close down a SPAN session simply issue the no monitor session # command.
Now your next question might be, what are you going to use this for or why are you going analyze the traffic? Well, if the station at the destination port is running Wireshark, it’s a real easy way to get a glimpse at the traffic traversing your network. From their you can look through the data and see if anything sticks out. Alternatively you can have a SPAN session provide data to a IDS/IPS system so it can monitor your network for any abnormalities.
CCIE or Null! 