Wireshark: Difference between revisions
From charlesreid1
| Line 55: | Line 55: | ||
=Filtering Packets= | =Filtering Packets= | ||
It is usually better to capture everything and | If your wireless card and CPU can handle a large amount of traffic, It is usually better to capture everything and use display filters to show different packets, instead of applying capture filters on the capture level. Capture filters are better if you're targeting your capture at a specific range of devices, a specific channel, or particular protocols. | ||
Use filter expression dialogue to create packet display filters. | Use filter expression dialogue to create packet display filters. | ||
Revision as of 04:35, 18 January 2016
The Basics
Wireshark is a packet analysis tool. It allows you to capture packets and analyze them live, or load captures from another session. You can also use its very handy filter functions to look for specific packets - based on destination, target, type, time, payload, etc.
Wireshark has a nice GUI and can show you some amazing things about network traffic. However, Wireshark is also memory-intensive, and is pretty slow on Mac. It's worth it.
Packet Captures
Capturing packets on a network is useful for troubleshooting, but it is also useful for seeing what the network normally looks like.
Take a Capture
Open up Wireshark, pick your network interface, and click the green fin to start the capture.
Capture Settings
You can control many of wireshark's capture options, one nice feature is outputting the capture file in size increments or time increments. As networks get busier, these cap files get pretty large. This is a nice feature to have.
You can also load multiple capture files simultaneously.
Capture Syntax
You can filter packets at the wireless card level, using packet filtering. Specifically, create filters that use the BPF (Berkeley packet filter) syntax.
The BPF syntax consists of primitives and operators.
Primitives consist of qualifiers and an ID.
Example:
dst host 192.168.0.10 && tcp port 80
First, the primitives and the operators:
primitive: dst host 192.168.0.10
operator: &&
primitive: tcp port 80
Now qualifiers and ID portion:
primitive: dst host 192.168.0.10
qualifier: dst
qualifier: host
id: 192.168.0.10
Filtering Packets
If your wireless card and CPU can handle a large amount of traffic, It is usually better to capture everything and use display filters to show different packets, instead of applying capture filters on the capture level. Capture filters are better if you're targeting your capture at a specific range of devices, a specific channel, or particular protocols.
Use filter expression dialogue to create packet display filters.
Operators and Filter Expressions
You can use several comparison operators and logical operators when constructing the display filter.
Comparison Operators:
- equal to
- not equal to
- greater than
- less than
- greater than or equal to
- less than or equal to
Logical Operators:
- and
- or
- xor
- not
Advanced Stuff
Endpoints and Conversations
You can see the network endpoints, or members of a network that initiate/terminate conversation and communication, by picking Statistics > Endpoints. This shows a list of endpoints and statistics.
You can see the conversations between two endpoints by picking Statistics > Conversations, which will show a window with a list of IP address pairs and various statistics of each conversation.
Endpoints/Conversations are useful for troubleshooting lots of traffic, or determining which server is busiest.
Protocol Statistics
You can open Statistics > Protocol Hierarchy to see information about what protocols are used in what amounts.
This can be useful if you are trying to determine "normal" behavior for a network, and then trying to determine if a particular day's traffic is an outlier and why.
By looking at a network's traffic protocol statistics, you can learn a lot about that network. Example: IT department will have admin protocols like ICMP or SNMP. Ordering department will use lots of SMTP. Interns will use WoW.
Name Resolution
To convert from a MAC address to an IP address is name resolution using the ARP protocol.
To convert from IP to Human-readable domain name uses DNS protocol.
Sniffing HTTPS with Wireshark
Over on the Man in the Middle/Wired/ARP Poisoning and Anonymous Browsing pages, I mention the danger of man-in-the-middle attacks and traffic sniffing, and the protection that HTTPS can offer you by encrypting your traffic.
However, it's also important to understand what HTTPS does NOT protect. For example, HTTPS does not protect the destination of the traffic. This is nuanced, however, so a novice unfamiliar with Wireshark might be tricked into thinking that HTTPS is hiding the destination of their HTTPS traffic. It is not.
When you use HTTPS, you prevent a man-in-the-middle attacker from being able to decrypt traffic - that would require your private key.
However, if an attacker had access to your machine, they could steal your private key and use it to decrypt your HTTPS traffic with Wireshark (http://htluo.blogspot.com/2009/01/decrypt-https-traffic-with-wireshark.html and https://support.citrix.com/article/CTX116557 and http://packetpushers.net/using-wireshark-to-decode-ssltls-packets/).
When you use HTTPS and experience a man-in-the-middle attack, you are presented with a warning that the certificate appears invalid.
However, if you accept that certificate, even once, the browser will permanently store it in a database, and it will be very difficult to remove. Once the certificate is accepted and is in your browser's database, the browser will never warn you when that certificate is being used, meaning an attacker can conduct a man-in-the-middle at any time without you being aware. This means accepting phony certificates, which is as easy as a single click of a button of an impatient and confused Sheep, has enormous implications.
Scary, ain't it?
Example HTTPS Traffic in Wireshark
Let's look at an example. I'll fire up a browser and visit https://en.wikipedia.org and I log in with my MediaWiki username and password. An attacker performing a man-in-the-middle attack can sniff my traffic. Mostly, they see traffic passing between my browser and a certificate authority (multiple IP addresses, but all registered under Verisign, a Certificate Authority.) HTTPS packets going to external addresses can't be sniffed because those are going through encrypted HTTPS tunnels that wireshark doesn't "see".
All of those SSL and TCP packets are going between the IP address browsing MediaWiki, and IP addresses belonging to Verisign.com, a Certificate Authority.
Determining HTTPS Traffic Destination
HOWEVER, an attacker can still see the destination of HTTPS traffic!!! While your traffic consists almost entirely of TCP packets between you and a certificate authority (IP addresses owned by Verisign), there is one key packet that an attacker may look at to see the destination of your HTTPS traffic by looking through a Wireshark traffic dump: the "Server Hello, Certificate, Server Hello Done" packet.
When you open this packet, you will see the packet contains a certificate. This is the certificate coming from the server, to whom the request is going to. In the photo above you can see clearly that despite the Sheep's use of HTTPS, someone performing a man-in-the-middle attack can still sniff the Sheep's connection.
So HTTPS traffic will protect the contents, but NOT the destination, of your traffic.
Not to mention, HTTPS can be beat during a man-in-the-middle attack using SSLStrip.
Sometimes Destinations are More Obvious
I guess that SSL certificates differ in how much information gets broadcast, because my cheapie self-signed certificate made it a lot easier to see the destination of HTTPS traffic destined for my website. It was not routed through Verisign.
| Wireshark a Swiss-army knife for analyzing networks, network traffic, and pcap files.
Wireshark · Category:Wireshark Packet Analysis · Wireshark/Advanced Wireshark/HTTPS · Wireshark/Traffic Analysis · Wireshark/Conversation Analysis · Wireshark/Protocol Analysis Working with SSL/TLS/HTTPS: MITM Labs/Decrypting HTTPS Traffic by Obtaining Browser SSL Session Info · MITM Labs/Decrypting HTTPS Traffic with Private Key File
|
| Networking pages and notes about computer networks.
Man in the Middle attack vectors on wired networks: Man in the Middle/Wired Packet analysis with Wireshark: Wireshark Packet Analysis Linux networking: Linux/Networking
Using Aircrack: Aircrack Many Ways to Crack a Wifi: Cracking Wifi
Linux/Networking · Linux/SSH · Linux/File Server
Notes on OpenVPN: OpenVPN Setting Up a Static Key VPN: OpenVPN/Static Key
Domain Name Servers: DNS · Linux/DNS IP Version 6: IPv6
Wireshark · SSH · Stunnel · Tor · Ettercap · Aircrack · Tcpdump
Tunnels · HTTP and HTTPS · SSH Tunnels · Linux/SSH
|