Define a packet analyzer and describe its use

This week you will examine WireShark, a well-used network-packet analyzer. For this discussion:

• Define a packet analyzer and describe its use
• List commonly used packet analyzers (beyond WireShark)
• List best practices for analyzing packets
• Describe uses (good and bad, ie. hacker) of a packetanalyzer
• Discuss ways you would protect your own network data from being analyzed

Ideally, attach a screen shot showing and discussing an analyzer’s use.

Make sure you respond to at least 2 other learner posts.

Response#1

A packet analyzer is a tool (either software or hardware) used to capture packetized traffic across a network. When the packet is read, some analyzers can provide graphical breakouts of each packet – such as with ‘WireShark’ – where source and destination IPs and protocols are shown, followed by the packet content, flags, frames, etc., and finally the hexadecimal data found in the packet. Other analyzers lack the bells and whistles of ‘WireShark’, but do a good job for basic network troubleshooting, such as ‘TCPDump’.

Beyond ‘WireShark’, as mentioned, ‘TCPDump’ has been my go-to tool for basic packet analysis. It provides a quick look at source and destination IPs and ports, flags, and packet content. While more difficult that ‘WireShark’, one can still follow a TCP conversation by matching up the packets in a conversational sequence. In addition to ‘WireShark’ and ‘TCPDump’, both of which are free, a couple of other free ones that can be found in the Kali Linux distribution are ‘Kismet’ and ‘Cain and Abel’. Additionally, there are a number of costly alternatives, including ‘SolarWinds’ and an all-the-things tool currently called ‘NetWitness’. When I used this tool, it was called ‘RSA Security Analytics’; I would consider it a packet analyzer at its foundation with a ton of features under the hood.

One best practice in packet analysis, from personal experience, is two-fold: first, know where in the network you want to set-up the capture, and two, be familiar with what types of traffic you should and should not be seeing. For example, is FTP permitted across the network segment in question?

Another best practice I have found is to do the packet capture with no filtering and dump it to a pcap file; follow this with doing the packet analysis on the pcap where various filters can be used depending on your needs. This can prevent missing things if analysis is attempted during a live packet stream.

A packet analyzer can be extremely beneficial to network engineers within an organization to help troubleshoot network issues; for example, packets not reaching their destination could be tracked at various points in the network. The analyzer can also be used to test whether various device rules are working as intended – such as firewalls, IDS/IPS, and router ACLs. However, packet analyzers can also be used for nefarious purposes. As one example, a hacker could use a wi-fi packet capture tool to pull packets from the air. The pcap could then be run through password cracking tools to reveal logon credentials.

Protection of a network from snoopers and packet analyzers would include encrypting all network traffic. Additionally, for a wired network, ensure physical protection of network devices, especially switches. I would recommend port security be enabled on switches and any unused or common-area network jacks (building lobby, breakroom, etc.) be disabled. While each of these has its own weaknesses, defense in depth will likely prevail – once a hacker keeps hitting defense walls, he/she is likely to quit and move on to another target.

In the screen capture below of WireShark, the packet number 4259 is highlighted/selected in the top window pane. One can see the source and destination IPs, the protocol is DNS and the basic information about the packet – it was part of a conversation where I did an “nslookup” at the command prompt of my machine. Source IP is in the 10. private range and the destination is a DNS server (75.75.75.75). In the middle pane, one can see expandable sections for the frame, ethernet, IPv4, UDP, and the DNS query. Finally, in the bottom pane, the hex data on the left and the corresponding human-readable data on the right can be found for this particular packet.