Join Mike Chapple for an in-depth discussion in this video Protocol analyzers, part of CompTIA Security+ (SY0-501) Cert Prep: 2 Technologies and Tools.
- [Narrator] Protocol analyzers are an important tool, available to both network and security professionals. Protocol analyzers allow administrators to peer into the actual packets traveling on a network and inspect them in deep detail. This is very useful when trying to troubleshoot network issues or investigate security incidents. Protocol analyzers must be used carefully however, because they can always jeopardize the confidentiality of sensitive information.
When they're used in the wrong hands. Let's take a look at a protocol analyzer in use. We're going to use Wireshark. The most common and free protocol analyzer. Right here I'm running Wireshark on a server that runs in the cloud. And I have an RDP session open to the system from my laptop that's running over port 3389. I'm going to go here and just click start, to initiate the packet capture. And immediately the screen begins filling up with lines of communication.
Each one of these lines on the screen and you can see it started scrolling already, there's so many of these. Each one of these lines on the screen represents a single TCP packet that's being sent over the network. And we can see some basic information here. The time elapsed from the start of the capture until this packet was received. The source and destination IP addresses. The protocol that was used. The length of the packet. And then some high level summary information about that packet. Now the reason this is filling up so quickly and I'm getting so many packets, is because this Wireshark session is actually capturing the RDP data that's been sent back and forth between my laptop and the server.
So we have a little bit of a vicious cycle going here where each time I send a packet via RPD to the server, it captures it. That packet capture then causes another packet to be captured because the screen update is sending traffic back and forth. So what I'm going to do is go ahead and add a filter to Wireshark. That's going to remove all of the RDP conversations from the screen. So I'm going to go up here to the filter section of Wireshark and type in my filter. Which is anything with a TCP destination port of 3389 should be removed.
That's the port that RDP uses. And then I also want anything that has a TCP source port of 3389 to be removed. I go ahead and apply this filter and now the traffic is down to a manageable level. What I'm going to do now, is switch over to a web browser that's also running on this same server and I'm going to go ahead and just visit a website. I'm going to go to ESPN dot com. And that page begins to load and as you may know, when you load a webpage, there are actually many individual files being transferred.
Each chunk of text is probably a file, each one of these advertisements and videos that's appearing is also a file. And all of this is being captured in Wireshark behind the scenes. This very simple loading of a webpage is actually very complicated when you look at it from a network perspective. So I'm going to now switch back to Wireshark. The first thing I'm going to do in Wireshark is I'm going to stop the capture so we don't get any new information added. And now I'm going to scroll down to the bottom of this communication stream and you can see all of this information that's being sent back and forth while we were doing the capture.
I'm just going to grab one of these. I'm going to click on this line here. And you can see this is a packet that was being sent from the remote system to my server and it looks like it's part of an HTTP communication. Wireshark allows me to see a little bit more detail about this packet, as well. Up on this portion of the screen remember each line represents a packet. When I click a packet as I've done here, the next two portions of the screen below it start to show very specific information about that packet. I'm going to go ahead and expand this section a little bit here.
And what you're looking at now are the details of that packet. Each of the headers involved, you can see the frame that's wrapped around the ethernet header. Also the IP header, TCP header and then down into the application layer. I'm going to open up here the ethernet layer first. And you can see within this as you might expect, we see MAC addresses that are used for transmission over ethernet. If I go and expand the IP header, you see of course the IP addresses that were the source and destination of the communication.
As well as the flags and other information that's part of the internet protocol header. I'm going to close these so we get a little more screen real estate here. And then expand the TCP header. And inside the TCP header we see that this source port is 80, indicating that its traffic coming from an HTTP web server which runs on port 80. And it's headed to this ephemeral port on my machine. 65315, which was just randomly chosen by my system for the communication. And then we see more details that are included in the TCP header.
When we look down at the bottom portion of the screen and I'll resize to make that a little bigger. We see the actually payload of the packet. This is the data that's being sent back and forth. And in this case, we're seeing it in two different formats. This is hexadecimal and then this is represented in what should be a more human readable form in ASCII. The issue here though, is if you look back up at the summary, notice that this packet we've picked is part of a .JPEG communication. So this is actually an image file being sent from ESPN to my system.
So the plain text contents of the packet are actually gobbledy gooked to me because I'm just looking at one piece of an image file. Now notice that this is packet number 11289 that was captured and it was captured about 157 seconds into the communication. So lots of data going back and forth during this communication. What Wireshark allows you to do is reassemble some of these communications and each of these packets that was part of an individual file being transmitted. I can do that by right clicking on it and then clicking the Follow TCP Stream option.
And what happens now is you see the entire communication that was going back and forth. The request that came from my server, this looks like it was an ad for Samsung televisions. And then the response that came from the web server. Including the add for Samsung communications. So we can really use Wireshark to peer deeply inside network communications. Wireshark is widely used because it's free and provides a clean graphical interface. But there's another sniffer that you should also be aware of. tcpdump is a command line packet sniffing tool that is also available as open source software and can be used programmatically.
Let's take a look at the use of tcpdump on a Linux system. Versions of tcpdump are available for other major operating systems, as well. I'm here in a Linux command line and I'm going to go ahead and type the command, tcpdump and then with a few arguments. First I'm going to tell it that I would like to see just IP addresses, I don't want it to try to resolve host names. And then I'm going to tell it using the minus I flag, the network interface that I'd like to do the sniffing on. And in this case I'd like to use ethernet zero, eth0. So I'm going to go ahead and hit enter.
And immediately the tcpdump begins displaying all the records that it's capturing on the screen. Each on of these lines that's scrolling by very quickly, is a single network packet. Now of course, I'm not going to look at it this way. But what I could do, is redirect the output of tcpdump to a file and then load it into another tool for analysis. Let me go ahead and stop this capture and it tells me that during that time that we were talking it captured almost half a million packets. I can also give tcpdump filters.
I'm going to go ahead and recall that same command we entered earlier. And now at the end of it, in single quotes, I'm going to type in a filter. Let's say I only want to see SSH traffic. That happens on TCP port 22. So I'm just going to type in the filter, TCP port 22, close the quotes and hit enter. And now the only traffic that's being captured, is traffic that matches that filter, using the SSH protocol over port 22. The language that you use to write tcpdump filters, is the same as the language used for Wireshark filters.
The reason for that is that both tcpdump and Wireshark are built upon the same code base. They both use a library called libpcap, short for packet capture library. To obtain and filter network traffic. Wireshark and tcpdump are the two most commonly used sniffers, because they are free open source products that work across a wide variety of platforms. There are also many commercial products available that fulfill the same functions.
For example, a company named Network General produced one of the earliest protocol analyzers. After a series of acquisitions that company is now known as NETSCOUT and continues to offer commercial sniffer products. Whatever protocol analyzer you choose, these tools play an important role in the cyber security toolkit.
- IP addresses
- Routers, switches, and bridges
- VPNs and VPN concentrators
- Network intrusion detection and prevention
- Managing secure networks
- Tuning and configuring SIEMs
- Troubleshooting digital certificates
- Personnel, host, and mobile device security
- Mobile device management and tracking
- Securing common protocols