You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.

To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.

Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.

Please contact us at <copyright@packtpub.com> with a link to the suspected pirated material.

We appreciate your help in protecting our authors and our ability to bring you valuable content.

If you have a problem with any aspect of this book, you can contact us at <questions@packtpub.com>, and we will do our best to address the problem.

We will see some of the important features that are available in Wireshark in the following figure:

Wireshark has the following cool built-in features, few of them are listed as follows:

The Wireshark installation provides some command-line tools such as dumpcap and tshark. Wireshark and tshark rely on dumpcap to capture traffic; more advanced functionality is performed by tshark. Also note that dumpcap can be run as its own standalone utility. tshark is a command-line version of Wireshark and can be used in the remote terminal.

The user must be aware of where Wireshark is installed and it should be obliged with your organization policy before start capturing on the TAP (Test Access Point) or Switch Port Analyzer (SPAN) port.

Usually developers install Wireshark on their personal laptop/desktop and capture packets, which goes in-out from the box.

Certain guidelines should be followed to perform this:

Wireshark is not available on mobile platforms such as Android, iOS, or Windows. In order to capture mobile traffic the following tools are suggested based on the platform:

Various other techniques are used to capture mobile traffic using Wireshark. One such technique is creating a Wi-Fi hotspot on the laptop, allowing the mobile phone to use this Wi-Fi, and sniffing traffic on your Wi-Fi interface using Wireshark.

The Wireshark display filter displays packets with its available coloring options. Wireshark display filters are used to change the view of a capture file by providing the full dissection of all packets, which helps analyzing a network tracefile efficiently. For example, if a user is interested in only HTTP packets, the user can set the display filter to http, as shown in the next screenshot.

The steps to apply display filters are as follows:

Once the filter is applied, the Packet List pane will display only HTTP protocol-related packets:

Wireshark display filter can be applied or prepared from the column displayed in the Packet List pane by selecting the column, then right-clicking and going to Apply as Filter | Selected (as shown in the following screenshot) to create the filter from the source IP address 122.167.102.21:

Wireshark provides the flexibility to apply filters from the Details pane; the steps remain the same.

Wireshark also provides the option to clear the filter. To do this click on Clear (available in the Filter toolbar) to display the entire captured packet.

Filtering techniques

Capturing and displaying packets properly will help you with packet captures. For example, to track a packet exchanged between two hosts: HOSTA (10.0.0.221) and HOSTB (122.167.99.148), open the SampleCapture01.pcap file and apply the filter ip.src == 10.0.0.221 as shown:

Let's see what the highlighted sections depict:

Item	Description
1	Apply filter ip.src == 10.0.0.221.
2	The Packet List pane displays the traffic from source to destination. The source shows the constant IP address 10.0.0.221. There is no evidence as to which packet is sent from host 122.167.99.148 to host 10.0.0.221.

Now modify the filter (ip.src == 10.0.0.221) && (ip.dst == 122.167.99.148) to (ip.src == 10.0.0.221) or (ip.dst == 122.167.99.148). This will give the result shown in the following screenshot:

The highlighted sections in the preceding screenshot are explained as follows:

Item	Description
1	Applied filter (ip.src == 10.0.0.221) && (ip.dst == 122.167.99.148)
2	The source IP address (10.0.0.221) is not changed
3	The destination IP address (122.167.99.148) is not changed

Again the Packet List pane is not displaying the conversation between the two hosts.

Now modify the filter ip.addr == 122.167.99.148. The ip.addr field will match the IP header for both the source and destination address and display the conversation between the hosts. Remember to choose the destination IP address as shown:

Let's see what the highlighted sections depict:

Item	Description
1	Applied filter ip.addr == 122.167.99.148
2	The source IP is not constant; it shows the conversation between the two hosts
3	The destination IP is not constant; it shows the conversation between the two hosts

The same conversation is captured by choosing the destination MAC address using the display filter eth.addr == 06:73:7a:4c:2f:85.

Filter examples

Some common filter examples are as follows:

Filter/capture name	Filter value
Packet on a given port	tcp.port == 443
Packet on the source port	tcp.srcport=2222
SYN packet on port 443	(tcp.port == 443) && (tcp.flags == 0x0010)
The HTTP protocol	http
Based on the HTTP get method	http.request.method == "GET"
Using &&, tcp, and http	tcp && http
Checking the tcp window size	tcp.window_size <2000
No Arp used for normal traffic	!arp
The MAC address filter	eth.dst == 06:43:7b:4c:4f:85
Filter out TCP ACK	tcp.flags.ack==0
Check only RST and ACK packets	(tcp.flags.ack == 1) && (tcp.flags.reset == 1)
Filter all SNMP	Snmp
HTTP or DNS or SSL	http || dns | ssl

There is no need to memorize the filter; there is an easy way to apply it. The display filter Autocomplete feature lists all dissectors after the first period "." that have been added to the display filter, as shown in the following screenshot:

Note

It's worth checking the following links for a complete display filter reference:

• Check out the TCP display filter reference: https://www.wireshark.org/docs/dfref/t/tcp.html
• Check out this alternative protocol display filter reference: https://www.wireshark.org/docs/dfref/

The Packet List pane displays packets from the .pcap (or accepted Wireshark extensions) file or from live capture, as shown:

Let's discuss the fields shown:

Item	What is it?
	Shows different packets; each row corresponds to a different packet called a frame
1. No.	Number of packets in the current live/offline capture
2. Time	Shows time-stamped information when the packet was captured The Automatic setting for libpcap files is microseconds; all packets will be captured with the time in microseconds, as shown in the next screenshot
3. Source	The IP address of the source from where the packet originates
4. Destination	The IP address of the destination where the packet ends
5. Protocol	Wireshark will display information about the packet protocol based on the standard port
6. Length	The packet length in bytes
7. Info	Shows a high-level summary of the packet and the nature of the packet

To change the time-stamped information of the packet go to View | Time Display Format to view the available presentation formats, as shown:

The Wireshark Set Time Reference feature gives you the ability to view the time reference from the selected packet. Open the capture file http.pcap and set the time reference from packet 38. To do this, select packet 38, right-click, and select Set Time Reference (toggle), as shown in the following screenshot:

After *REF* is set, it becomes the starting point for all subsequent packet time calculations, as shown in the following screenshot:

The Packet Details pane will show the currently selected packet in a more detailed form. In the following screenshot, an HTTP packet is selected and its details are shown in the information labeled with numbers 1 to 5. Let's see what these are:

The frame protocol is only used by Wireshark. All the TCP/IP protocols sits on top of this. The frame shows at what time the packet was captured, as shown in the following screenshot:

Ethernet is the link layer protocol in the TCP/IP stack. It sends network packets from the sending host to one (Unicast) or more (Multicast/Broadcast) receiving hosts, as shown:

Useful filters in Ethernet are:

The packet structure of Ethernet frames is described in the following table:

The preamble (8 bytes) and FCS (4 bytes) are not part of the frame and Wireshark will not capture this field.

So the total Ethernet header is 14 bytes—6 bytes for the destination address, 6 bytes for the source address, and 2 bytes for the EtherType.

The Internet Protocol information relates to how the IP packet is delivered and whether it has used IPv4 or IPv6 to deliver the datagram packets.

The preceding screenshots show that an IPv4 protocol is used to deliver the datagram packet. Useful display filters in the IP protocol are:

The TCP protocol packet contains all TCP-related protocol data. If the communication is over UDP, the TCP will be replaced by the UDP, as shown in the following screenshot. The SEQ/ACK analysis will be done by Wireshark based on the sequence number and expert info will be provided:

The <<APPLICATION-LAYER>> protocol is shown if the packet contains any application protocols. As shown in the following screenshot, the selected packet 36 has HTTP protocol data. Wireshark has the ability to decode the protocol based on the standard port and present this information in the Packet Details pane in a readable (RFC-defined) format.

In the coming chapters we will discuss the application-related protocol in greater detail.

The Packet Bytes pane displays the bytes contained in the frame, with the highlighted area being set to the node selected in the Packet Details pane.

The Decode-As feature allows Wireshark to decode the packet based on the selected protocol. Usually Wireshark will automatically identify and decode incoming packets based on the standard port—for example, port 443 will be decoded as SSL. If the services are running on the non-standard port, for example SSL standard port is 443 and the service is running on 4433, in this case the Decode-As feature can be used to decode this communication using the SSL protocol preference.

Open the sample https.pcap file from. HTTPS traffic is captured when the file is opened in Wireshark. It doesn't show SSL-related data; instead it just shows all TCP communications:

To decode this traffic as SSL, follow these steps:

The protocol preference feature provides the flexibility for you to customize how the Wireshark display is processed, and how packets are analyzed. You can set protocol preferences by one of the following methods:

Wireshark supports a large set of protocols and it's preferences, for example HTTP protocol preferences and their meanings as defined in the following table:

The following screenshot shows HTTP protocol preferences in Wireshark:

Use the IO graph to check client and server interaction data for a meaningful analysis. The Wireshark IO graph measures throughput (the rate is packet-per-tick), where each tick is one second. In this example we will see how to make use of the IO graph. Open the file http_01.pcap in Wireshark and follow the given steps:

There are a lot of use cases for IO graphs. Some of them are as follows:

The following screenshots show the results of the preceding steps:

The TCP stream feature allows users to see the data from a TCP stream. Open the file http_01.pcap in Wireshark and follow the TCP stream to get the first HTTP OK, as shown:

In this example we have located the HTTP OK on packet#35 and then right clicked and selected Follow TCP Stream:

Once the stream is applied, a TCP stream dialog box will open displaying which request is sent and what response is received in this HTTP conversation:

The stream content is available in six formats as shown; the red content in the screenshot is the request, the blue content in the screenshot is the response:

The Export Specified Packets feature allows you to export the filtered packet in different files. For example, open http.pcap in Wireshark and export the HTTP OK packet. The steps for exporting a specified packet are as follows:

Using Wireshark, network administrators can generate ACL rules for firewall products such as:

The steps to generate an ACL rule in Wireshark are as follows:

The three-way handshake is a connection establishment procedure from the client socket to the server socket, as shown in the following image:

Before the start of the TCP three-way handshake, the client will be in the CLOSED state and the server will be in the LISTEN state as shown:

To examine a three-way handshake in Wireshark, open the normal-connection.pcap file provided in the book.

The TCP RST flag resets the connection. It indicates that the receiver should delete the connection. The receiver deletes the connection based on the sequence number and header information. If a connection doesn't exist on the receiver RST is set, and it can come at any time during the TCP connection lifecycle due to abnormal behavior. Let's take one example: a RST packet is sent after receiving SYN/ACK, as shown in the next image.

RST after SYN-ACK

In this example we will see why RST has been set after SYN-ACK instead of ACK:

Open the RST-01.pcap file in the Wireshark:

As you can see in the preceding figure:

• The TCP RST packet should not be seen normally
• The TCP RST is set after the first two handshakes are complete. A possible explanation could be one of the following:
  • The client connection never existed; a RAW packet was send over the TCP server
  • The client aborted its connection
  • The sequence number got changed/forged

RST after SYN

This is the most common use case. Open the RST-02-ServerSocket-CLOSED.pcap file in Wireshark. In this example the server was not started, the client attempted to make a connection, and the connection refused an RST packet:

Often a connection is stuck in the CLOSE_WAIT state. This scenario typically occurs when the receiver is waiting for a connection termination request from the peer.

bash:~ $ netstat -an | grep  CLOSE_WAIT
tcp4       0      0  122.167.127.21.56294    10.0.0.21.9999     CLOSE_WAIT

To demonstrate the CLOSE_WAIT state, open the close_wait.pcap file in Wireshark:

As you can see in the preceding screenshot:

CLOSE_WAIT means there is something wrong with the application code, and in the high-traffic environment if CLOSE_WAIT keeps increasing, it can make your application process slow and can crash it.

The main purpose of the TIME_WAIT state is to close a connection gracefully, when one of ends sits in LAST_ACK or CLOSING retransmitting FIN and one or more of our ACK are lost.

RFC 1122: "When a connection is closed actively, it MUST linger in TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime). However, it MAY accept a new SYN from the remote TCP to reopen the connection directly from TIME-WAIT state, if..."

We ignore the conditions because we are in the TIME_WAIT state anyway.

Identifying the source of latency also plays an important role in TCP troubleshooting. Let's see what the common causes of latency are:

Various network utility tools are available to measure the latency between networks—for example traceroute, tcpping, and ping.

Wireshark can be used effectively to identify whether the network is slow or the application is slow. Open the slow_download.pcap file in Wireshark, and investigate the root cause of why the download is slow.

In this example, 5 MB of data is requested from the HTTP server, and it has taken approx. 4.99 minutes to download, as shown:

The steps to diagnose this issue are as follows:

In this scenario, tcp.window_size was reduced in the sysctl.conf file to demonstrate the slow_download behavior and to give an insight into troubleshooting. After fixing Window_Size, the same download is reduced from 299.816907000 to 2.84 seconds. Open the fast_download.pcap file as shown in the following screenshot; the download time is reduced:

In this example, the TCP handshake process will be used to identify wire latency. Open the slow_client_ack.pcap file as shown in the following screenshot:

As you can see in the preceding screenshot:

TCP makes the transmission of segments reliable via sequence number and acknowledgement. When TCP transmits a segment containing data, it puts a copy on a retransmission queue and starts a timer; when the acknowledgment for that data is received, the segment is deleted from the queue. If the acknowledgment is not received before the timer runs out, the segment is retransmitted. During TCP retransmission, the sequence number is not changed until the retransmission timeout happens.

Open the example tcp-retransmission.pcapng in Wireshark and add a Sequence number column, as shown in the following screenshot:

As you can see in the preceding screenshot:

For another example, open the file syn_sent_timeout_SSH.pcapng in Wireshark, and observe the TCP retransmission flow.

Open the tcp_zero_window.pcapng file in Wireshark and add tcp.window_size_value to the column.

The TCP window size represents how much data a device can handle from its peer at one time before it is passed to the application process.

As shown in the preceding screenshot:

Troubleshoot the ZeroWindow condition:

Wireshark marks a packet as Window Update when the window size has changed. A Window Update is an ACK packet, and only expands the window; this is normal TCP behavior.

Open the tcp_window_update.pcap file in Wireshark and observe that a TCP Window Update event is set, as shown:

Duplicate ACKs are sent when there is fast retransmission. In this scenario the same segment will be seen often. Open duplicate_ack.pcapng and apply the tcp.analysis.duplicate_ack filter, as shown:

As you can see in the previous screenshot:

There are ten types of message, as shown in the following table, and their corresponding Wireshark filters. This is a one-byte field in the Handshake Protocol:

The TLS Handshake Protocol involves the following steps in four phases; the prerequisite is that a TCP connection should be established:

Open the file two-way-handshake.pcap, which is an example demonstrating a SSL mutual authentication procedure:

Client Hello

The TLS handshake starts with the Client Hello message (ssl.handshake.type == 1), as shown in the following screenshot:

Handshake records are identified as hex byte 0x16=22. The structure of the Client Hello message is as follows:

• Message: The Client Hello message 0x01.
• Version: The hex byte 0x0303 means it's TLS 1.2; note 0x300 =SSL3.0.
• Random:
  • gmt_unix_time: The current time and date in standard UNIX 32-bit format
  • Random bytes: 28 bytes generated by the secure random number
• Session ID: The hex byte 0x00 shows the session ID as empty; this means no session is available and generates new security parameters.
• Cipher suites: The client will provide a list of supported cipher suites to the server; the first cipher suite in the list is the client-preferred (the strongest) one. The server will pick the cipher suites based on its preferences, the only condition being that the server must have client-offered cipher suites otherwise the server will raise an alert/fatal message and close the connection:
  
• Compression methods: The client will list the compression methods it supports.
• Extensions: The client makes use of the extension to request extended functionality from the server; in this case the client has requested four extensions, as shown in the following table:

Value	Extension name	Reference
0	elliptic_curve	RFC4492
1	ec_point_formats	RFC4492
3	signature_algorithms	RFC 5246
5	heartbeat	RFC 6520

Note

For a complete list of TLS extensions, visit: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml.

Server Hello

The server will send the Server Hello message (ssl.handshake.type == 2) in response to the Client Hello, as shown in the following screenshot. The message structure of the Client Hello and Server Hello message is the same, with one difference—the server can select only one cipher suite:

Handshake records are identified as hex byte 0x16=22. The structure of the Server Hello message is:

• Handshake Type: The hex byte 0x02=2 shows the Server Hello message
• Version: The hex byte 0x0303 shows TLS 1.2 has been accepted by the server

  Server/client	SSLv2	SSLv3	SSLv23	TLSv1	TLSv1.1	TLSv1.2
  SSLv2	Y	N	Y	N	N	N
  SSLv3	N	Y	Y	N	N	N
  SSLv23	N	Y	Y	Y	Y	Y
  TLSv1	N	N	Y	Y	N	N
  TLSv1.1	N	N	Y	N	Y	N
  TLSv1.2	N	N	Y	N	N	Y

The following table shows which SSL version of the client can connect to which SSL version of the server:

• Session ID: A 32-byte session ID is created for reconnection purposes without a handshake
• Cipher suite: The server has picked Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030), which means use Elliptic curve Diffie-Hellman (ECDHE) key exchange, RSA for authentication, Block cipher Galois/Counter Mode (GCM), AES-256 for encryption, and SHA-384 for digests
• Extensions: A response with extension info is requested in the Client Hello message

Server certificate

After the Server Hello message is sent, the server should send a X.509 server certificate (ssl.handshake.type == 11). The certificate configured on the server are signed by the CA or intermediate CA, or can be self-signed based on your deployment:

If a SSL/TLS server is configured with the certificate chain then the entire chain will be presented to the client along with the server certificate. The client (a browser or any other SSL/TLS client) can then check the highest certificate in the chain with stored CA certificates; typically, modern Web browsers have the root CA installed from the trusted CA provider.

The given certificate is signed with the relevant signature (sha256WithRSAEncryption); in this case, the hash value itself is concatenated into the OID (Algorithm Id: 1.2.840.113549.1.1.11) representing the signing algorithm. The certificate follows the DER encoding format and when encrypted becomes PKCS#7, the Cryptographic Message Syntax Standard (refer to RFC 2315).

Server Key Exchange

From RFC #5246, the server sends the Server Key Exchange message (ssl.handshake.type == 12) only when the Server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret:

As you can see in the preceding screenshot:

• Cipher suites contains key exchange algorithms
• The Server Key Exchange message will be sent for the following key exchange methods: DHE_DSS, DHE_RSA,DH_anon
• In line with RFC#5246, the use of Server Key Exchange is not legal for these key exchange methods: RSA, DH_DSS, DH_RSA

Server Hello Done

The Server Hello Done message means that the server is done sending messages to support the key exchange, and the client can proceed with its phase of the key exchange:

Client certificate

The client will send its certificate (ssl.handshake.type == 11) only in a mutual authentication condition. The server will verify the certificate in its CA chain. If the server fails to verify client_certificate, the server will raise an alert fatal protocol and communication will stop:

Client Key Exchange

In the case of the normal handshake process (one way auth), the Client Key Exchange message is the first message sent by the client after it receives the Server Hello Done message.

This Client Key Exchange message (ssl.handshake.type == 16) will always be sent by the client. When this message is seen, pre_master_secret is set, either by transmission of the RSA-encrypted secret or by the Diffie-Hellman parameters, depending on the key exchange method chosen. The server uses its private key to decrypt premaster_secret:

Change Cipher Spec

The Change Cipher Spec record type (ssl.record.content_type == 20) is different from the handshake record type (ssl.record.content_type == 22) and it's a part of the Change Cipher Spec protocol. The Change Cipher Spec message is sent by both the client and server only when key_exchange is completed and it indicates to the receiving party that subsequent records will be protected under the newly negotiated Change Cipher Spec and keys (master_secret):

Finished

The Finished (ssl.record.content_type == 22) message is encrypted so it will be an encrypted handshake message in Wireshark. This message is sent immediately after a Change Cipher Spec message from both the client and server to verify that the key exchange and authentication processes were successful. This message contain the MD5 hash +SHA hash. When both the client and server have sent the Finished message, the TLS handshake is considered to have finished successfully and now sending and receiving application data over the secure channel can begin:

Application Data

The Application Data message (ssl.record.content_type == 23) is carried by the record layer and fragmented, compressed, and encrypted:

Record layer processing involves the mentioned step as shown in the following screenshot:

Alert Protocol

The Alert Protocol (ssl.record.content_type == 21) describes the severity of the message and the alert. Alert messages are encrypted and compressed and support two alert levels: warning and fatal. In the case of fatal alerts, the connection will be terminated.

Alert descriptions are shown in the following table:

Alert name	Alert type	Description
close_notify(0)	Closure alert	Sender will not send any more messages on this connection
unexpected_message(10)	Fatal	An inappropriate message was received
bad_record_mac(20)	Fatal	Incorrect MAC received
decryption_failed(21)	Fatal	TLS Cipher text decrypted in an invalid way
record_overflow(22)	Fatal	Message size is more than 2^14+2048 bytes
decompression_failure(30)	Fatal	Invalid input received
handshake_failure(40)	Fatal	Sender unable to finalize the handshake
bad_certificate(42)	Fatal	Received corrupted certificate; bad ASN sequence
unsupported_certificate(43)	Fatal	Certificate type is not supported
certificate_revoked(44)	Warning	Signer has revoked the certificate
certificate_expired(45)	Warning	The certificate is not valid
certificate_unknown(46)	Warning	Certificate unknown
illegal_parameter(47)	Fatal	TLV contain invalid parameters
unknown_ca(48)	Fatal	CA chain couldn't be located
access_denied(49)	Fatal	Certificate is valid, the server denied the negotiation
decode_error(50)	Fatal	The TLV received does not have a valid form
decrypt_error(51)	Fatal	Decryption cipher invalid
export_restriction(60)	Fatal	A negotiation not in compliance with export restrictions was detected
protocol_version(70)	Fatal	The selected protocol version is not supported by the server
insufficient_security(71)	Fatal	Strong cipher suite needed
internal_error(80)	Fatal	Server-related issue
user_canceled(90)	Fatal	Client cancelled the operation
no_renegotiation(100)	Fatal	Server is not able to negotiate the handshake

As shown in the following screenshot, the Alert Protocol is generated by the server:

This protocol allows two users to exchange a secret key over an insecure medium without any prior secrets; in this scheme, the example cipher suites will have a naming convention such as:

Cipher suites will have "DH" in their name, not "DHE" or "DH_anon".

Elliptic curve Diffie-Hellman is a modified Diffie-Hellman exchange that uses elliptic curve cryptography instead of the traditional RSA-style large primes. Elliptic curve cryptography (ECC) is a public-key cryptosystem just like RSA, Rabin, and El Gamal. Some important points with this algorithm are:

Note that the Client Hello message exchange process in the Extension elliptic_curves key exchange was offered. The example cipher suites will follow a naming convention such as:

Cipher suites will have "DHE" in their name, not "DH" or "DH_anon".

The server's public key is made available to the client during the Server Key Exchange handshake. The pre_master_secret key is encrypted with the server public RSA key. The example cipher suites in this case will be:

Cipher suites will have "RSA" in their name, not "DH" or "DH_anon" or "DHE".

Decryption of TLS traffic depends upon which cipher suite was chosen by the server in the Server Hello message. Open the file decrypt-ssl-01.pcap and look for the cipher selected by the server. In this case the TLS_RSA_WITH_AES_256_CBC_SHA cipher suite was used; since this is RSA, we can decrypt the packet using our private key.

Now go to Edit | Preferences | Protocol | SSL, add the new RSA key, and configure the following properties of the RSA key dialog box:

After applying these settings, the SSL traffic will be decoded into HTTP traffic for that IP, as shown in the following screenshot:

Once the packet is decrypted, the SSL session can be exported by clicking on File | Export SSL Session Keys. A dialog box will open; save this session key in the file (exported-session-keys). The content of the file looks like this:

RSA Session-ID:af458c9c61675238b74f40b2a9547a0a2a394ada458a1b648e0495ed279d5e2e Master-Key:6c970211a77548811267646a759d0d03bbc532d9b6336f2b656cb0c6bbef8f3a262d845b9abed87d26583a9c4bb9b230

Once the exported-session-keys file is created, use this file to decrypt the SSL/TLS traffic. To do so, go to Edit | Preferences | Protocol | SSL and configure the (Pre)-master-secret log file with the path of the SSL Session Keys. This approach is helpful when the user wants to share the packet without sharing the private keys and still needs to provide the decryption step:

DHE/ECDHE can't be decrypted using this approach even if we have private keys as they are designed to support forward secrecy.

Use the bootp filter to display BOOTP/DHCP traffic and use UDP port 67 to capture the BOOT/DHCP traffic only.

DISCOVER, OFFER, REQUEST, ACK protocol exchanges happen between clients and servers during network address assignment, as shown in the following screenshot. As a mnemonic, refer to this as DORA.

The address assignment can also be done using the Rapid Commit option for DHCPv4. Modeled on DHCPv6, it uses two-message exchanges to quickly configure the DHCPv4 client.

To demonstrate four-message exchange open the DHCPv4.pcap file in the Wireshark, as shown in the following screenshot:

The preceding figure shows a message exchange happening between the DHCPv4 client and DHCPv4 server. This is summarized as follows:

The commands to capture DHCPv4 traffic are as follows:

Wireshark's dns filter is used to display only DNS traffic, and UDP port 53 is used to capture DNS traffic.

The default DNS port is 53, and it uses the UDP protocol. Some DNS systems use the TCP protocol also. TCP is used when the response data size exceeds 512 bytes, or for tasks such as zone transfers.

The following format is used by the DNS system:

In this chapter, the dig and nslookup network commands are used to query the DNS server. Open the sample DNS-Packet.pcap file, set the display filter to dns.qry.type==28, and examine the query.

In this example, client (192.168.1.101) is asking the name server (8.8.4.4) to resolve ipv6.google.com by setting these parameters in the query section:

User can use the popular dig or nslookup network utility commands to query different DNS record types. Use a network capture in the background and observe the query and answer section for each command:

Use http to display HTTP packets only. Use TCP port 80 to filter for HTTP traffic only; port 80 is the default HTTP port.

The following example shows different use cases where Wireshark can help to analyze HTTP packets.

Finding sensitive information in a form post

If the form contains sensitive information such as password, Wireshark can easily reveal it as HTTP is an unsecure means of transferring data over the network.

Open the HTTP_FORM_POST.pcap file and filter the traffic to display only the request method POST and locate the password form item, as shown in the following screenshot:

In Layer 2, datagrams are called frames; they show all channel traffic and a count of all the frames received at the measuring STA. There are four types of frame, which are defined in the following table:

Let's take a detailed look at these frames one by one.

Data frames

Data frames carry the packets that can contain the payload (such as files, screenshots, and so on). Type values for data frames used in 802.11 and their corresponding Wireshark display filters are shown in the following table:

Name	Value	Wireshark display filter
data	0x20	wlan.fc.type_subtype == 0x20
data + cf-ack	0x21	wlan.fc.type_subtype == 0x21
data + cf-poll	0x22	wlan.fc.type_subtype == 0x22
data + cf-ack + cf-poll	0x23	wlan.fc.type_subtype == 0x23
null function	0x24	wlan.fc.type_subtype == 0x24
no data cf-ack	0x25	wlan.fc.type_subtype == 0x25
no data cf-poll	0x26	wlan.fc.type_subtype == 0x26
no data cf-ack + cf-poll	0x27	wlan.fc.type_subtype == 0x27
qos data	0x28	wlan.fc.type_subtype == 0x28
qos data + cf-ack	0x29	wlan.fc.type_subtype == 0x29
qos data + cf-poll	0x2a	wlan.fc.type_subtype == 0x2a
qos data + cf-ack + cf-poll	0x2b	wlan.fc.type_subtype == 0x2b
qos null	0x2c	wlan.fc.type_subtype == 0x2c
no data qos cf-poll	0x2e	wlan.fc.type_subtype == 0x2e
qos cf-ack + cf-poll	0x2f	wlan.fc.type_subtype == 0x2f

For example, wlan.fc.type_subtype == 0x2A will display all the packets that contain QoS Data + CF-Poll in the packet capture file 802.11.pcap, as shown in the following screenshot:

The AP advertises its capabilities in a Beacon frame; the client (STA) broadcasts itself, using its own probe request frame, on every channel—typically (channel 11). By doing this, it determines which access points are within range.

Probe response frames contain capability information, supported data rates and so on, of the AP after it receives a probe request frame.

The STA sends an authentication frame containing its identity to the AP. With open system authentication (the default), the access point responds with an authentication frame as a response, indicating acceptance (or rejection).

Shared key authentication requires WEP (64-bit or 128-bit) keys, and the same WEP keys on the client and AP should be used. The STA requests a shared key authentication, which returns unencrypted challenge text (128 bytes of randomly generated text) from the AP. The STA encrypts the text and returns the data to AP, the AP response indicating acceptance (or rejection).

The STA sends an association request frame to the AP containing the necessary information and then that the AP will send an Association response frame that includes acceptance (or rejection). If this is accepted, the STA can utilize AP to access other networks:

IEEE802.1x is based on Extensible Authentication Protocol (EAP), which is an extension of PPP (Point-to-Point Protocol), also known as "EAP over LAN" or EAPOL.

The IEEE 802.11 Working Group passed the 802.1x standard in 2001 to improve upon the security specified in the original 802.11 standard (IEEE, 2001).

Open the 802.11-AUTH-enabled.pcap file in Wireshark and use the display filter eapol to display all the eapol messages only, as shown in the following screenshot. In the eapol packets, the session key of the device and the AP are handled.

As shown in the screenshot, all eapol packets are captured as 1 of 4, 2 of 4, 3 of 4, and 4 of 4.

The eapol packets are needed if you are trying to decrypt 802.11 traffic. The Wireshark wiki link https://wiki.wireshark.org/HowToDecrypt802.11 is an excellent source of information on how to decrypt traffic with the help of Wireshark.

The 802.11 standard specifies a common medium access control (MAC) layer (the data link layer) that supports the operation of 802.11-based wireless LANs. The 802.11 MAC layer uses an 802.11 Physical (PHY) layer, such as 802.11a/b, to perform the tasks of carrier sensing, transmission, and receiving 802.11 frames.

Open the packet capture file 802.11-AUTH-Disabled.pcap in Wireshark and set the display filter to wlan.da==e8:de:27:59:72:06 to view how the data is carried using 802.11 as the transport medium.

The 802.11 QoS data frames shows that the LLC header follows IEEE 802.11; this is what is expected in the monitor mode.

The captured 802.11 looks like an Ethernet packet as the 802.11 adapter will often try to transform data packets into fake Ethernet packets and then supply them to the host.

We learned about the TCP handshake process in Chapter 3, Analyzing the TCP Network. In this handshake process, a connection is established with SYN, SYN-ACK, and ACK between the client and server.

In the SYN flood attack scenario, what is happening is that:

In all these scenarios, the TCP/IP stack file descriptors are consumed, causing the server to slow down and finally crash.

Open the SYN_FLOOD.pcap packet capture file in Wireshark and perform the following steps:

The IO graph statistics show the following summary:

In real scenarios, this data will be mixed up with actual packet flows, but the analysis technique will remain the same. The moment you see an unexpected growth in SYN packets or a spike in SYN packets, it's a SYN flood from DoS or from the multiple-source DDoS.

Internet Control Message Protocol (ICMP) flood is also categorized as a Layer 3 DoS attack or a DDoS attack. It works as follows: an attacker is trying to flood the echo request (ping) packet with a spoofed IP address or the server is flooded with echo requests (ping packets) and not able to process the echo response for each ICMP echo request, resulting in host slowness and denial of service.

Open the ICMP_Flood_01.pcap packet capture file in Wireshark and perform the following steps:

As shown in the screenshot, ICMP flood has the following characteristics:

This kind of attack happens on Layer 7 and it is difficult to detect in the sense that it resembles legitimate website traffic. In Analyzing SSL/TLS, we learned about SSL and the handshake process. The attacker can use the handshake against the system to create a DoS/DDoS attack. As handshake involves larger exchange of message between client and the server, for example, in case of one way auth total number of packet exchanges to established a connection is approximate 12 (that is, 3 packets TCP handshake + 9 packets SSL handshake = 12 packets exchanged).

The attacker can flood the SSL connection and make the server busy, to just establish the connection and try to create the DoS/DDoS scenario.

Wireshark can help in identifying from which IP maximum number of packet has arrived. This feature is called Wireshark Conversations, and can be used in any kind of flood scenario (DoS attack).

Open the ICMP_Flood_01.pcap packet capture file in Wireshark and perform the following steps:

Other categories of Layer 7 attacks are HTTP/HTTPS POST flood and HTTP/HTTPS GET flood.

Host discovery, port scanning, and OS detection are part of vulnerability scanning. During this process, vulnerabilities are identified and addressed with a proper mitigation plan by the security auditor. For example:

Open the host_scan.pcap file in Wireshark; the sample capture shows how the external client is scanning the ports:

During this process, a SYN packet is sent to the all the ports for common services on each host, such as DNS, LDAP, HTTP and many more. If we get the ACK from the host, the host is considered ACTIVE on that port.

The security auditor or hacker can use network scanner tools to get the port, host, and OS information. For example, the nmap network utility command can be used to scan the active/open ports:

The online nmap tool can be found at https://pentest-tools.com/network-vulnerability-scanning/tcp-port-scanner-online-nmap.

SSL scans are done by different users (for example, security auditors and hackers) to achieve their own objectives:

An example using the nmap command to find available ciphers and the supported protocol version in a given server port 636 LDAP is as shown:

[root@ ~]# nmap --script ssl-cert,ssl-enum-ciphers -p 636 10.10.1.3To find available ciphers and the supported protocol version in a given server port 443 HTTPS

[root@ ~]# nmap --script ssl-cert,ssl-enum-ciphers -p 443 10.10.1.3