510 likes | 814 Views
Digital Forensics. Wireshark. Author/Revisions. Dr. Randy M. Kaplan Revisions: Created: 11/17/2008. What is Wireshark?. A network packet analyzer Capture network packets Display network packets in as much detail as possible Network Packet Analyzer
E N D
Digital Forensics Wireshark
Author/Revisions • Dr. Randy M. Kaplan • Revisions: • Created: 11/17/2008
What is Wireshark? • A network packet analyzer • Capture network packets • Display network packets in as much detail as possible • Network Packet Analyzer • Network device used to analyze what is going on in a network cable
Intended Purposes • Troubleshoot network problems • Examine security problems • Debug protocol implementations • Learn network protocol internals
Things that Wireshark cannot do • Not an intrusion detection system • Won’t warn you about weird stuff happening on the network • (Can be used to analyze stuff so you can figure out what the weirdness is about)
Things that Wireshark cannot do • Will not manipulate things on the network • Wireshark “measures” what is going on in the network • Wireshark does not send packets
Get Wireshark from ... • http://www.wireshark.org
Using Wireshark • Download and install the Wireshark version for your computer • Run wireshark • MAKE SURE YOU ARE RUNNING WIRESHARK FROM A PRIVILEGED ACCOUNT • (If you don’t you may not see an interface)
First, • Get Wireshark to show you the available capture interfaces • A capture interface is the place from which network traffic can be monitored • Click on the icon to display the capture interfaces
Capture Interfaces • To select an interface, click on the Start button on the line of the interface you wish to monitor
Capture Interfaces • In this case the two active interfaces are lo0 and en1
File Download • When describing the download process at the network level, the process is very basics as a transfer across a network • A client requests a file from a server via HTTP • The server response with the file
File Download • The file download process takes the form of packets into which the file to be downloaded is broken • The packets are sent across the network ti reach its destination • We will look at the downloading process of a file
I/O Graph • The first thing we want to look at is the I/O graph • I/O graph is highly customizable • A good way to visually interpret some of the data that is captured
I/O Graphs • Firing up the I/O graphs • Click on Statistics on the main menu • Click on I O Graphs
I/O Graphs • Change the resolution from packets/tick to bytes/tick
I/O Graphs The capture window from the download
Examining the Capture Data • We want to be able to remove the irrelevant data from the capture • Most of the capture contains normal traffic • We want to be able to look at abnormal traffic • To accomplish this we will use something called the “expert info window"
Examining the Capture Data • To display the expert window, click on Analyze on the main menu and then click on “Expert Info”
Examining the Capture Data The expert info window will show all warning, error, note, and chat communication Chat communication does not constitute abnormal traffic, so we will filter out chat communication
Examining the Capture Data In this excerpt of the packet capture, we see some warnings and then some notes The message “TCP Previous segment lost” means that during data transfer, a packet was dropped The message “Duplicate ACK” is a message sent to the server to request a resend of the dropped packets
Examining the Capture Data The message “TCP Fast retransmission” is an indication that a packet requested for retransmission was re-transmitted
Examining the Capture Data • This graph is called a TCP Stream Graph • This graph is produced by selecting a packet and clicking on statistics and then selecting TCP Stream Graph
TCP Stream Graph The stream graph shows the time it takes for the packet to be captured. At the beginning of the download the times are extremely short. Later there are some tall spikes indicating a momentary slowdown.
Troubleshooting a Slow Router • We’re going to look at a client who is trying to connect to a website • The client is experiencing many kinds of network slowness issues • Looking the file, initially you will notice many ARP broadcast packets • These packets represent attempts to resolve addresses
Troubleshooting • For our purposes we will remove these packets from the display • We can do this by typing !arp in the filter text box
Troubleshooting • The capture display after filtering out the ARP packets
Troubleshooting • Next to each of the packets in the display, there is a time that the packet was received
Troubleshooting • We can change the way that the time is displayed • We want to see the amount of time that went by between packets • To do this we click on - • View • Time Display Format
Troubleshooting • Finding the source of the latency • Now that we have the display using the time format that will assist us, • We look for the first sign of major network activity • We look at packet 18 where client 172.17.8.66 makes an HTTP request
Troubleshooting • In this packet an HTTP request is made to get the website www.packet-level.com
Troubleshooting • The next packet that should be seen is from the DNS servers responding to the client • Now such response is seen • After about a second, another request is made for the webpage
Troubleshooting • Packet 20 shows the response from the DNS server • At this point in the process the client and webserver should begin a standard TCP/IP handshake • The client begins the process
Troubleshooting • You can see that once the client sends the ACK, the server responds in about 1/2 second - a significant amount of time
Troubleshooting • We can see in packet 26 another response from the DNS server • This is actually the response to the second DNS request that was made • The response is about 5 seconds too late • The client no longer needs the data in this packet, so an exception is thrown
Troubleshooting • After the handshake, the client makes the actual request for the web page at packet 25 • Problems begin to show up at this point
Troubleshooting • At packets 29 and 32, there are TCP Retransmission packets • The client waited for a response, no response, so it requests the web page again • Packet 33 finally shows a response
Troubleshooting • If you add up all of the times from when the webpage was initially requested to when the webpage response was sent, 9 seconds has elapsed • 9 seconds is an entirely unacceptable amount of time
Troubleshooting • We know that the client seems to be operating properly so the problem must be upstream from the client • The first thing to check would be the router • Rebooting the router resolve this problem, but ...
Troubleshooting • If the problem was not the router, the next point to check would be the network router for the server • At this point, we usually are not able to affect anything, so it becomes difficult to solve the problem