Protocol analyzers allow administrators to peer into the actual packets traveling on a network. This is very useful when trying to troubleshoot network issues or investigate security incidents. Learn how cybersecurity professionals use protocol analyzers, such as Wireshark, to examine network activity.
- [Instructor] Protocol analyzers are an important tool available to both network and security professionals. Protocol analyzers allow administrators to peer into the actual packets travelling 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 also 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 on a 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's 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 being 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 RDP to the server, it captures it, that packet capture thing 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 the same server. And I'm going to go ahead and just visit a website. I'm going to go to ESPN.com. And that page begins to load, and as you may know, when you load a webpage that 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 web page 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 communications 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 a 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 the source port is 80, indicating that is 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 actual 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 gobbledygook to me because I'm just looking at one piece of an image file.
Now notice that this is packet number 11,289 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 in 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 ad for Samsung communications. So we can really use Wireshark to peer deeply inside network communications. And as you've seen Wireshark and other protocol analyzers are powerful tools that allow us to peer deep into network communications for troubleshooting and investigative purposes.
Learn about communication and networking best practices, including TCP/IP networking, network security devices, and secure network design and management. Instructor and cybersecurity expert Mike Chapple also includes coverage of converged protocols, network encryption, and wireless networking. You can find Mike's companion study books for this series at the Sybex test prep site and review the complete CISSP Body of Knowledge at https://www.isc2.org/cissp-domains/default.aspx.
- IP addressing
- Switches and routers
- Content distribution networks
- Designing secure networks
- Specialized networking
- Managing secure networks
- Working with virtualized networks like SDNs
- Detecting and preventing network attaches
- Transport encryption
- Wireless networking
- Host security