Latest revision as of 05:30, 23 January 2016

http://www.wireshark.org/

Take advantage of the fact that it's legal in every country to profile protocols and products.

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.

Filtering Captures: Syntax

To filter out packets at the wireless card level to reduce the CPU load during a capture, you can use packet filters with the Berkeley packet filter (BPF) syntax.

The BPF syntax consists of primitives and operators.

Primitives consist of qualifiers and an ID.

Examples

Hree's an example that would only look for packets to a certain host and port (port 80 is HTTP traffic):

dst host 192.168.0.10 && tcp port 80

The syntax consists of primitives and operators.

A primitive is something like dst host 192.168.0.10 or tcp port 80.

An operator is something like &&.

The primitive itself consists of qualifiers and IDs.

The primitive dst host 192.168.0.10 has the qualifiers dst and host and the 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

Related Pages

Advanced Wireshark Stuff: Wireshark/Advanced

Examples:

Wireshark can be used to analyze network traffic in detail: Wireshark/Traffic Analysis

Wireshark can be used to sniff HTTPS traffic: Wireshark/HTTPS

@@ Line 1: / Line 1: @@
 http://www.wireshark.org/
+Take advantage of the fact that it's legal in every country to ''profile'' protocols and products.
 =The Basics=
@@ Line 21: / Line 23: @@
 You can also load multiple capture files simultaneously.
-==Capture Syntax==
+==Filtering Captures: Syntax==
-The filters use BPF (berkeley packet filter) syntax.
+To filter out packets at the wireless card level to reduce the CPU load during a capture, you can use packet filters with the Berkeley packet filter (BPF) syntax.
 The BPF syntax consists of primitives and operators.
@@ Line 29: / Line 31: @@
 Primitives consist of qualifiers and an ID.
-Example:
+===Examples===
+Hree's an example that would only look for packets to a certain host and port (port 80 is HTTP traffic):
 <pre>
@@ Line 35: / Line 39: @@
 </pre>
-First, the primitives and the operators:
+The syntax consists of primitives and 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
+A primitive is something like <code>dst host 192.168.0.10</code> or <code>tcp port 80</code>.
-qualifier: dst
+An operator is something like <code>&&</code>.
-qualifier: host
+The primitive itself consists of qualifiers and IDs.
-id: 192.168.0.10
+The primitive <code>dst host 192.168.0.10</code> has the qualifiers <code>dst</code> and <code>host</code> and the ID <code>192.168.0.10</code>.
 =Filtering Packets=
-It is usually better to capture everything and hide packets using display filters, instead of applying capture filters on the capture level.
+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.
@@ Line 77: / Line 73: @@
 * not
-=Advanced Stuff=
+=Related Pages=
-==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".
-[[Image:WiresharkHTTPSTraffic.png|500px]]
-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.
-[[Image:WiresharkServerHelloCertificate.png|500px]]
-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.
+Advanced Wireshark Stuff: [[Wireshark/Advanced]]
-So HTTPS traffic will protect the contents, but NOT the destination, of your traffic.
+Examples:
-Not to mention, HTTPS can be beat during a man-in-the-middle attack using [[SSLStrip]].
+Wireshark can be used to analyze network traffic in detail: [[Wireshark/Traffic Analysis]]
-===Sometimes Destinations are More Obvious===
+Wireshark can be used to sniff HTTPS traffic: [[Wireshark/HTTPS]]
-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: Difference between revisions

From charlesreid1