Setting Up Port Mirroring

Port mirroring is a feature of network devices like routers, switches, and firewalls which helps replicate and redirect packets. Port mirroring can be called a port monitor or Switched Port Analyzer (SPAN) by various networking vendors.

Port mirroring continuously monitors the mirrored source ports, creates a copy of packets seen on the source port, and sends it to the mirror destination port. Both transmit and receive packets on mirrored source ports can be sent to the destination port for capture. The device running Wireshark or any other packet capture application is connected to the mirror destination port.

As shown in Figure 2-1, the requirement is to capture packets traversing between S1 and the firewall. So ports 1 and 2 connecting to these devices are defined as mirror sources, and all these mirrored packets are sent to mirror destination port 3 which connects to the capture point.

A model diagram of port mirroring. It comprises router, firewall, switch that is further connected to server S 2, S 3 and capture point and Wireshark.

The actual configuration of setting up port mirroring on the network device is vendor specific. It is out of the scope of this book.

Remote Port Mirroring

In the previous scenario, the packet source devices which need the packets captured are connected to the same switch where our capture device is connected.

However, this may not be the scenario always when your network is big and spans across a number of devices and geographies. The switch or router where your capture device is connected may be separated by one or many devices. Sometimes, it may not be convenient to send someone to the remote packet source device to connect the capture device locally.

The mirror destination device decapsulates the captured packets if encapsulated and redirects them to the network port where the capture device is connected.

Figure 2-2 illustrates both the remote port mirroring capabilities.

A model diagram of remote port mirroring. It includes components router 1, firewall, router 2, switch 2, switch 1, server S 1, server S 3 and capture point with Wireshark.

Switch-1 mirrors the packets going in and out of port 1 and redirects to the remote switch, Switch-2, over a layer 2 trunk link between the switches.

Similarly, Router-1 mirrors the packets going in and out of port 2 and redirects to the remote switch, Switch-2, over a layer 3 IP network by encapsulating the captured packet in an ERSPAN and GRE header.

Figure 2-3 shows details of the encapsulation headers and how the actual packet was encapsulated and sent to the destination device with IP address 1.1.1.1.

A screenshot of a program for E R SPAN header. It has commands; Frame 3; Ethernet second, Internet Protocol Version 4 with source and destination address; Generic Routing Encapsulation with sub commands, Flags and Version, Protocol type colon E R SPAN and Sequence number; E R SPAN type two.

The actual vendor-specific configuration of the mirroring is out of the scope of this book.

While doing remote mirroring, all your mirrored traffic is carried over the network between source and network devices. This may overwhelm the underlying network if the sufficient capacity doesn’t exist. For example, if you are mirroring ten 1 Gbps ports and sending to the remote device, more than the 10 Gbps traffic may hit the underlying link. Make sure the transport link is of higher capacity than 10 Gbps and sufficient headroom is available to accommodate this. Otherwise, this will affect all other traffic flowing through.

Other Mirroring Options

The main purpose of port mirroring is to redirect capture traffic from the source switch or router to the destination port where the capture device is connected. However, the end hosts or network devices do not always connect to a switch or a router. There can be a direct link between the devices, and we need to capture the packets or errors on the link, etc. In this case, a low-cost solution of TAP or hub may help.

Capture Point Placement

In the previous sections, we learned how we can source traffic from other network devices redirected toward the capture point. The general rule of thumb is to place the capture device or sniffer as close to the suspected network device as possible.

However, as the network size grows, it becomes a challenge to have capture devices at each location. To reduce efforts, we have to decide on what are the optimum points where we can do the packet capture. The approach varies based on different scenarios.

UNIX, Linux, BSD, and macOS

All UNIX-like platforms have tcpdump natively available as a standard package. tcpdump offers a command-line interface which can print the contents of network packets to standard output or a file.

In many cases, it’s more useful and easy to capture packets using tcpdump rather than Wireshark. For example, you might want to do a packet capture remotely and either don’t have your OS GUI access or Wireshark is not installed on the remote device. In such scenarios, you can run tcpdump and capture the packets to a file for viewing through Wireshark on a local machine. Detailed ways of doing remote capture are discussed in the section “Remote Packet Capture with Extcap” of this chapter.

Usage:

The correct interface and the name of a file to save into will have to be specified in the preceding command. The interface name can be found from the “ifconfig” or “ip addr” command. In addition, in case you are not mentioning capture size or capture count, the capture can be terminated with ^C when enough packets are captured.

Other tcpdump capture options can be found at the tcpdump man page: www.tcpdump.org/manpages/tcpdump.1-4.99.1.html. We will discuss more on the filters in the “Capture Filtering” section of this chapter.

Windows

Windows has a built-in packet capture component called "ndiscap." This is implemented as an ETW (Event Tracing for Windows) trace provider. This ETW technology allows applications to produce trace messages or events. ndiscap should be preferred compared to other popular packet capture methods (WinPcap, included with older versions of Wireshark) due to performance problems. A capture can be collected as follows.

ndiscap packet capture generates a file in etl format, which cannot be opened by Wireshark. etl files can be opened by ETW-centric tools like Microsoft Message Analyzer, but that may not help here. There is an open source tool available by Microsoft known as etl2pcapng.exe that can convert the etl file to a pcapng file which can be opened with Wireshark. The etl2pcapng can be downloaded from the GitHub link: https://github.com/microsoft/etl2pcapng/.

CLI-Based Capture with Dumpcap or Tshark

Dumpcap and tshark behave the same way, use the same pcap library and have similar flags, and capture filters as tcpdump discussed in the earlier section. In fact, tshark uses dumpcap as its capturing engine. There are some minor differences between dumpcap and tshark.

GUI-Based Capture with Wireshark

In Chapter 1, you have got a good understanding of Wireshark installation, basics of the user interface, etc. In this chapter, we will focus on how to get a simple packet capture started.

When you launch Wireshark, it shows a list of recently opened capture files (in the following image, it's empty and not shown) and also a list of available interfaces.

The traffic rate graph is also shown against each interface. This helps identify quickly which interfaces are active and have traffic flowing.

A screenshot of Wireshark application window demonstrates steps to capture a packet. It involves steps 1. Select the interface. 2. Specify filter optional, 3. Hit the start button.

Capturing Traffic from Multiple Interfaces

Sometimes, we need to correlate data from multiple interfaces. In such cases, we can choose multiple interfaces by pressing the CONTROL key (Windows, Linux) or COMMAND key (macOS) and select desired interfaces by clicking the mouse.

A screenshot of Wireshark application explains steps to capture multiple interfaces. Step 1. Select multiple interfaces on screen, 2. Specify filter which is optional, 3. Hit start button

Stopping Capture

Once the desired data is captured, it can be stopped by hitting the stop button. The capture file can be saved by selecting the save option.

A screenshot of Wireshark application demonstrates steps to capture multiple interfaces. Step 1. Select multiple interfaces on screen, 2. Specify filter which is optional, 3. Hit start button

Promiscuous Mode

Promiscuous mode is related to how a network adapter processes a packet received on its interface. By default, if the destination MAC is not the adapter MAC, the adapter may drop the unicast Ethernet frame. This means the received packet may be destined to a different adapter or device, and the local adapter shouldn’t process.

Promiscuous mode if activated on the adapter allows a network adapter to process all frames whether it's meant for this adapter or not.

In some virtual machines, the adapter settings may need to be tweaked to allow promiscuous mode, but normally we don’t have to change anything for hardware adapters.

Once the network adapter passes the frames not meant for itself for further processing by applications like Wireshark, capture behavior can be controlled at the application level too.

Wireshark by default captures in promiscuous mode. This is very important for capturing packets coming to the capture device redirected by switch port mirroring (SPAN) other device network interfaces. For successful capture of such frames, the network adapter should be operating in promiscuous mode, and Wireshark should have activated promiscuous mode.

This setting can be changed at the Capture ➤ Options window by checking or unchecking the enable promiscuous mode as shown in Figure 2-7.

A screenshot of Wireshark explains options to configure promiscuous mode. 1. Select Promiscuous mode for each interface manually, 2. Click, Enable Promiscuous mode on all interfaces, to auto select all interface.

Pitfalls

Remote Capture with Sshdump

Sshdump is an extcap tool that makes available locally an interface of a device accessible through SSH. This allows running a capture tool remotely and tunneling the captured packets over an SSH connection to the local device running the sshdump extcap plugin.

Requirements

• Some packet capture executables (like tcpdump, wireshark, etc.) must have been installed on the remote device.

• SSH connection is allowed to the remote device.

• The SSH user is allowed to run the capture utility.

The following is the way to trigger sshdump from the Wireshark GUI.

Step 1: From the Wireshark home page, click the gear icon corresponding to the “SSH remote capture: sshdump” interface.

An image of Wireshark home page illustrates the first step to trigger S S H Dump from Wireshark Graphical User Interface. Step 1. Click the gear icon, S S H remote capture colon s s h dump

Step 2: Fill the server IP/hostname, SSH port, and authentication details.

An image of two windows, 1. Server details window, fill Server address and Port I d 2. Authentication details window, fill server user name and password for S S H remote capture interface.

Step 3: Fill the optional interface (name will be specific to the device), sudo, or capture command details and start.

An image of Capture window in S S H remote capture. It requires details of Remote interface, Remote capture command, tick box, Use Sudo on the remote machine and click on Start button to capture.

Mobile Device Traffic Capture

Wireshark supports packet capture on mobile devices. However, it can have a lot of other tool dependencies. In the following section, we have discussed some of the approaches like Wireshark native ways and third-party apps.

Android Devices

Using Native Androiddump Utility

Like sshdump, androiddump is an extcap plugin that makes available a remote-connected Android device interface on the local device for packet captures. The following are some of the requirements:

1. 1.

   You must have installed an Android SDK. Android SDK for various platforms is available at the following:

   https://developer.android.com/sdk/index.html#Other

    
2. 2.

   Add the SDK to the PATH environment variable. The environment PATH specified should contain a directory with tools like "adb" and "android" required for the capture. They come as part of the SDK installation.

   The following is an example in macOS to update the environment PATH:

   export PATH="${HOME}/Library/Android/sdk/tools:${HOME}/Library/Android/sdk/platform-tools:${PATH}"
    
3. 3.

   The Android device must be connected to the device running Android SDK and Wireshark through USB or Wi-Fi pairing. Without this, the androiddump-related extcap interfaces won’t be available on the Wireshark. Figure 2-8 shows the connected devices in the Android Studio.

    

An image of device manager window in Android studio. It has a connected device in physical option tab.

1. 4.

   For network interface packet capture, the Android device must be rooted, and the tcpdump binary should be installed. Binaries can be found at this location: www.androidtcpdump.com/android-tcpdump/downloads.

    
2. 5.

   Some Android devices require on-screen authentication, and hence you must have required (root) permission to the Android device.

    

The following are the supported Android interfaces:

1. 1.

   Logcat Main (binary [<=Jelly Bean] or text)

    
2. 2.

   Logcat System (binary [<=Jelly Bean] or text)

    
3. 3.

   Logcat Events (binary [<=Jelly Bean] or text)

    
4. 4.

   Logcat Radio (binary [<=Jelly Bean] or text)

    
5. 5.

   Logcat Crash (text; from Lollipop)

    
6. 6.

   Bluetooth Hcidump [<=Jelly Bean]

    
7. 7.

   Bluetooth Bluedroid External Parser [Kitkat]

    
8. 8.

   Bluetooth BtsnoopNet [>=Lollipop]

    
9. 9.

   Wi-Fi tcpdump [need tcpdump on phone]

    

Once the preceding requirements are satisfied, the respective androiddump extcap interfaces will be visible on Wireshark on the capture device running Wireshark and Android Studio (Android SDK).

Choose the desired androiddump extcap interface and start the capture with default settings. In the following example, as shown in Figure 2-9, we have used a logcat radio interface.

An image preview of two images. 1. Wireshark window depicts Android Logcat radio interface, 2. Android Logcat radio window has two tabs, Default has server I P address and port I D

This starts the capture, and it can be seen in real time on the Wireshark GUI interface.

An image of Wireshark interface explains Android dump Capture. The second row is selected with destination, Logcat. The bottom of the image Android dump reflects at bottom of the image.

Using Third-Party Android App and Sshdump

There are multiple free and paid Android-based applications available which allow packets to and from the Android-based mobile device to capture packets on the required interface and locally save them to a pcapng file or send remotely to a Wireshark capture device through the sshdump extcap utility.

In this section, we are discussing one such free application called “PCAP Remote,” which captures the packets on a required interface and streams packets to an SSH server interface on the Android device. We can utilize the sshdump extcap utility available on Wireshark running on a remote capture device to open a connection with the Android device SSH server and receive packets in real time.

Step 1: On the Android device

Install the Android app and start capture mode as the SSH server.

An image of P C A P Remote android app settings. Dashboard has; Capturing Mode colon S S H Server; Server address and port I D which auto populate with capture mode S S H Server

Step 2: From the remote device running Wireshark

Start capture on the sshdump extcap interface and use details seen in step 1. Here, the username and password have to be specified. This can be any random text but can’t be left empty.

An image of P C A P Remote Wireshark settings step one. Upon selection of S S H Remote capture, it opens Wireshark interface Server tab. It has server address and server port

An image of two Wireshark S S H remote capture window with authentication and capture tab details. 1. Authentication tab has Server username and password which cannot be empty; 2. Capture tab has remote interface which needs to be specify and hit start

An image of Wireshark interface explains P C A P Remote Android Wireshark S S H Dump capture. A program illustrates, Source port, Destination port, Sequence number, acknowledgement number and details at the bottom

Capture Filter Deep Dive

At first glance, capture filters might seem like the ugly twin of display filters. However, capture filters are not the same as display filters and have a different syntax. If you are used to working with display filters, the syntax can feel less expressive. It may seem as if you are not able to filter for most protocols or expert information, but capture filters are powerful too and can achieve most of the filtering requirements.

Wireshark capture filters follow the libpcap filter syntax documented at the tcpdump man page: www.tcpdump.org/manpages/pcap-filter.7.html.

The filter expressions in turn get converted to the BPF (Berkeley Packet Filter) syntax in the backend. The BPF architecture executes the BPF filter code on the network packets to find a match. This helps in the real-time computation of the network packets for the kernel to decide if it can drop or truncate incoming packets as early as possible. This eliminates user space application involvement for further analysis. BPF can compile the filter expressions to a code that the Linux kernel understands and can act on.

All the libcap-based capture applications like Wireshark, tshark, dumpcap, and tcpdump use the same uniform BPF syntax for capture filters. When you specify the capture filter, the text strings are converted to a set of BPF instructions and compiled automatically by the BPF compiler.

Understanding BPF: What Goes Behind the Capture Filters

If you want to understand the corresponding BPF instructions or want to troubleshoot why sometimes the capture filter string did not work the way expected, it can be easily found as follows:

CLI way

% sudo dumpcap -d -f "tcp"

Capturing on 'Wi-Fi: en0'

(000) ldh      [12]

(001) jeq      #0x86dd          jt 2   jf 7

(002) ldb      [20]

(003) jeq      #0x6             jt 10  jf 4

(004) jeq      #0x2c            jt 5   jf 11

(005) ldb      [54]

(006) jeq      #0x6             jt 10  jf 11

(007) jeq      #0x800           jt 8   jf 11

(008) ldb      [23]

(009) jeq      #0x6             jt 10  jf 11

(010) ret      #524288

(011) ret      #0

GUI way

After specifying the capture filter in the dialogue box, hit the Compile BPFs button. This generates the compiled BPF code.

An image of Wireshark interface explains compiled filter output. It has capture option dialogue box, capture filter for selected interface has T C P; Click on compile B P Fs option for output.

In Table 2-2, we have an explanation of the BPF instructions corresponding to the preceding filter. Details about the BPF syntax can be found here: https://man7.org/linux/man-pages/man8/bpfc.8.html.

Table 2-2

BPF Instructions Explained

BPF Instruction	Meaning
(000) ldh [12]	Load 2 bytes from byte 12. This corresponds to the Ethertype value
(001) jeq #0x86dd jt 2 jf 7	If loaded value, i.e., Ethertype, is 0x86dd (ipv6 packet) is TRUE, go to #2, or if FALSE, go to #7
(002) ldb [20]	Load 1 byte from byte 20 (IPv6 Next Header)
(003) jeq #0x6 jt 10 jf 4	IPv6 Next Header: If TCP, then MATCH, go to #10, else #4
(004) jeq #0x2c jt 5 jf 11	If IPv6 packet has extension header
(005) ldb [54]	Load 1 byte from byte 54 (IPv6 Extension Header)
(006) jeq #0x6 jt 10 jf 11	IPv6 Extension Header: If TCP, then MATCH, go to #10, else #11
(007) jeq #0x800 jt 8 jf 11	If loaded value, i.e., Ethertype, is 0x800 (ipv4 packet) is TRUE, go to #8, or if FALSE, go to #11
(008) ldb [23]	Load 1 byte from byte 23 (IPv4 protocol value)
(009) jeq #0x6 jt 10 jf 11	IPv4 protocol value: If TCP, then MATCH, go to #10, else #11
(010) ret #524288	MATCH. Capture the packet
(011) ret #0	No match. Do not capture

Using the preceding filter, we captured the IPv4 TCP packet shown in Figure 2-16. If we look closely at the preceding BPF instruction set, lines #7, #8, #9, and #10 result in the packet match in Figure 2-16.

An image of B P F example. It has alphanumeric characters illustrates; Zero Six as Protocol, B P F hashtag 8,9 example; 0800 as Ether type, B P F hashtag 7 example.

High Volume Packet Analysis

Let’s take a use case where we need to find a DHCP packet flowing randomly at a very low rate across a service provider core router on multiple 100 Gbps interface. The background data rate can be very high close to the line rate of 100 Gbps where the packet of interest can be flowing at less than one packet per second.

This is like searching a needle in the haystack, and if we don’t use any capture filtering, the capture file will exhaust the disk space very quickly, and postcapture analysis will also be very difficult. The following are some of the approaches that will help in the capture.

When the Packet Characteristics Are Known

If we know that our packet is not going to be encapsulated with any other header and it is always deterministic, then we can deploy a capture filter that completely matches the packet. In this case, as it’s a DHCP packet, we can use the filter in Figure 2-17 which can capture the DHCP packet.

An image of capture filter for D HC P packets. It contains; Tick box to enable promiscuous mode on all interface; Capture filter for selected interface details, port 67 or 68

When the Packet Encapsulations Is Unknown

Sometimes, we are not clear about what additional headers can be added on the packet. Say there may be a vlan tag on the DHCP packet if it’s going across an Ethernet trunk. In case it’s carried across an MPLS layer 2/3 VPN, there can be additional MPLS headers and tags also. There can be scenarios also where the packet may not be given required treatment and missing some of the expected headers. We can use packet size/range-based filter to minimize the overall capture. We may have to do multiple trial runs to fine-tune the range.

The filter in Figure 2-18 considers that the packet is tagged with one or multiple MPLS headers and within 250–400 bytes in size.

An image of capture filter for M P L S packets 250&#x2013;400 bytes. It contains; check box to enable promiscuous mode on all interface; Capture filter for selected interface, m p l s and start expression greater two fifty and less four hundred end expression

When we don’t know if there can be an MPLS tag or any other packet header, but we are sure about the size range, the filter in Figure 2-19 can help.

An image of capture filter for all packets 250&#x2013;400 bytes. It contains; check box to enable Promiscuous mode on all interface; Capture filter for selected interface, great two fifty and less four hundred

Advanced Filters and Deep Packet Filter

Filters based on byte offset

Byte offset notation–based filters can be a bit confusing initially, yet are the most powerful. Once you understand the logic, you can design a filter to capture any kind of packet even though standard protocol expressions are not available for the same.

Protocol = Can be an expression like ip,icmp,icmpv6,tcp,udp

X = Offset in bytes from the start of the specified protocol header

Y = Number of bytes to check

The filter tries to match Y bytes located X bytes from the start of the specified protocol header.

This is simple yet so powerful as any packet can be filtered just by specifying the value of the number of bytes to match and the offset or location of the bytes from the start of the protocol header.

Consider the following Ethernet IPv4 packet:

A table lists the code of I P and T C P header bytes in blue and red colors in four code series 0000, 0010, 0020, 0030, and 0040. Three values are highlighted in 0010, 0030 is 40, 01, and b b.

Example:

In the preceding example, we used the “=” operator. But other logical operators (>, <, >=, <=, =, !=) can be used to form a filter.

Masking with byte offset filters

In many scenarios instead of the whole byte, it is useful to isolate nibbles or a few bits for matching. Bit masking helps in extracting the desired bits.

Using the preceding approach, complex filters can be designed to match packets based on specific TCP flags, IP flags, or for that matter any field inside any packet.