Wireshark: Analyzing Network Traffic on Linux

Introduction: why analyze network traffic?

Network traffic analysis, also called packet analysis or sniffing, consists of capturing and inspecting the packets that travel across a network. It addresses several fundamental use cases:

• Network debugging: identify TCP retransmissions, timeouts, DNS errors, refused connections.
• Offensive security: detect unencrypted protocols transmitting credentials, analyze the behavior of malware.
• Defensive security: validate firewall rules, verify that TLS encryption is properly in place, detect port scans.
• Forensics: reconstruct an attack after the fact from pcap files, extract files transferred over HTTP or SMB.
• Performance optimization: measure latencies, identify bottlenecks, analyze TCP negotiations.

Wireshark is the reference tool for all of these tasks. It dissects more than 3,000 protocols, integrates with tshark for automation, and can read pcap files produced by tcpdump, Suricata or any other capture tool.

Installation

Debian / Ubuntu

Wireshark is available in the official repositories. During installation, a dialog asks whether non-root users should be allowed to capture: choose Yes to enable the wireshark group.

sudo apt update
sudo apt install -y wireshark wireshark-qt tshark

# Add your user to the wireshark group
sudo usermod -aG wireshark $USER

# Reload the session (or log out / log back in)
newgrp wireshark

CentOS / RHEL / Rocky Linux

sudo dnf install -y wireshark wireshark-cli

# On CentOS 7 with yum
sudo yum install -y wireshark wireshark-gnome

# Add the user to the wireshark group
sudo usermod -aG wireshark $USER

Capturing without root using setcap

To allow capturing without becoming root, grant the network capabilities to dumpcap (Wireshark's low-level capture engine):

# Grant the necessary capabilities to dumpcap
sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

# Verify
getcap /usr/bin/dumpcap
# /usr/bin/dumpcap cap_net_raw,cap_net_admin=eip

This method is safer than running Wireshark as root because only the minimal capture process gets elevated privileges.

Verifying the installation

wireshark --version
tshark --version
dumpcap --version

Graphical interface: getting started

Welcome screen

On launch, Wireshark displays the list of available network interfaces with a real-time activity graph. Active interfaces show movement. The main interfaces are:

• eth0 / enp3s0: wired Ethernet interface
• wlan0: Wi-Fi interface
• lo: loopback (local traffic)
• any: capture on all interfaces simultaneously
• docker0, br-xxxxx: Docker interfaces and bridges

Main menus

• File: open/save pcap files, merge captures.
• Capture: start/stop capture, advanced options (buffer, file rotation).
• Analyze: apply filters, Follow Stream, decode protocols.
• Statistics: I/O Graph, Conversations, Endpoints, Protocol Hierarchy.
• Telephony: VoIP analysis (SIP, RTP).
• Tools: key generator, coloring rules.

Default columns

The main view displays packets with these columns: No. (sequential number), Time (timestamp), Source, Destination, Protocol, Length, Info. Each column is customizable via right-click.

Packet capture

Quick start

Double-click an interface on the welcome screen to start capturing immediately. The status bar shows the number of captured packets and the throughput.

Advanced capture options

Via Capture -> Options (or Ctrl+K), you can configure:

• Interface: select one or more interfaces.
• Promiscuous mode: capture all traffic on the segment, not just the traffic destined for your machine.
• Capture Filter: BPF filter applied at the kernel level to reduce the number of captured packets.
• Ring Buffer: automatic file rotation (useful for long captures).
• Stop conditions: stop after N packets, N seconds, or N MB.

Capture filters (BPF syntax)

Capture filters use the BPF (Berkeley Packet Filter) syntax. They are applied in the kernel before packets reach Wireshark, which reduces CPU load and the size of captures.

# Capture only HTTP and HTTPS traffic
port 80 or port 443

# Capture traffic to/from a specific host
host 192.168.1.100

# Capture traffic for an entire network
net 192.168.1.0/24

# Capture TCP only
tcp

# Capture UDP only
udp

# Capture DNS traffic (port 53 UDP and TCP)
port 53

# Capture everything except SSH traffic (avoids capturing your own session)
not port 22

# Combination: TCP to/from a host on specific ports
tcp and host 10.0.0.1 and (port 80 or port 443)

# Capture ICMP (ping)
icmp

# Capture a subnet while excluding one host
net 10.0.0.0/8 and not host 10.0.0.1

Display filters

Wireshark display filters have their own syntax, distinct from BPF. They operate on the fields of dissected protocols and offer far greater granularity.

Filters by protocol

# Show HTTP only
http

# Show DNS only
dns

# Show TLS only
tls

# Show TCP only
tcp

# Show UDP only
udp

# Show ICMP only
icmp

# Show ARP only
arp

# Show DHCP
bootp

# Show NTP
ntp

# Show SMB traffic
smb or smb2

Filters by IP address and port

# By source or destination IP address
ip.addr == 192.168.1.100

# By source IP address only
ip.src == 192.168.1.100

# By destination IP address only
ip.dst == 8.8.8.8

# By subnet
ip.addr == 192.168.1.0/24

# By TCP port (source or destination)
tcp.port == 443

# By destination TCP port only
tcp.dstport == 80

# By source TCP port
tcp.srcport == 443

# By destination UDP port
udp.dstport == 53

# By source or destination UDP port
udp.port == 5353

Operators and combinations

# Logical AND
ip.addr == 192.168.1.1 && tcp.port == 80

# Logical OR
tcp.port == 80 || tcp.port == 443

# Negation
!tcp.port == 22
not dns

# Contains a string (case sensitive)
http.request.uri contains "login"

# Regular expression
http.host matches ".*\.google\.com"

# Range of values
tcp.port >= 1024 && tcp.port <= 65535

# Field present (protocol with a specific flag)
tcp.flags.syn == 1

# Complex combination: HTTP POST to a specific IP
http.request.method == "POST" && ip.dst == 93.184.216.34

Common practical filters

# Show only HTTP GET requests
http.request.method == "GET"

# Show only HTTP responses with 4xx and 5xx errors
http.response.code >= 400

# Show DNS queries of type A
dns.qry.type == 1

# Show TCP packets with the RST flag (reset connections)
tcp.flags.reset == 1

# Show TCP retransmissions
tcp.analysis.retransmission

# Show TCP packets with analyzed problems
tcp.analysis.flags

# Show only TLS Client Hello exchanges
tls.handshake.type == 1

# Exclude loopback traffic
ip.addr != 127.0.0.1

Protocol analysis

HTTP: methods, headers and stream reconstruction

Wireshark fully dissects HTTP/1.x. To see a complete HTTP request:

1. Apply the http filter.
2. Click a request packet. In the dissection pane, expand Hypertext Transfer Protocol to see the method, URI and headers.
3. To reconstruct the full exchange, right-click -> Follow -> HTTP Stream. Wireshark reconstructs the request and the response in a separate window.

# Useful HTTP filters
http.request.method == "POST"          # POST requests (potentially with data)
http.request.uri contains "/admin"     # Access to administration URLs
http.response.code == 200              # OK responses
http.response.code == 401             # Authentication required
http.cookie                            # Packets with cookies
http.authorization                     # Packets with an Authorization header

DNS: queries, responses and records

The DNS protocol is particularly useful for detecting suspicious behavior: DNS exfiltration, the use of malicious domains, or resolution problems.

# All DNS queries
dns

# Queries only (not responses)
dns.flags.response == 0

# Responses only
dns.flags.response == 1

# Type A queries (IPv4)
dns.qry.type == 1

# Type AAAA queries (IPv6)
dns.qry.type == 28

# Type MX queries (email)
dns.qry.type == 15

# Queries for a specific domain
dns.qry.name contains "example.com"

# Responses with a very short TTL (often a sign of fast-flux)
dns.a.ttl < 60

In the dissection pane, a DNS response shows: the question, the Answer Records with the TTL and the resolved address, and the Additional Records. A TTL of 0 indicates that the record should not be cached.

TCP: flags, handshake and retransmissions

Understanding TCP flags is fundamental for diagnosing network problems:

• SYN: connection initiation (start of the 3-way handshake).
• SYN-ACK: the server's response to the SYN.
• ACK: acknowledgment.
• FIN: graceful connection close.
• RST: abrupt reset (connection refused or error).
• PSH: push the data to the application layer immediately.

# View a 3-way TCP handshake
tcp.flags.syn == 1

# Refused connections (RST in response to SYN)
tcp.flags.reset == 1 && tcp.flags.syn == 0

# TCP retransmissions (indicator of packet loss)
tcp.analysis.retransmission

# Duplicate ACK (sign of congestion or loss)
tcp.analysis.duplicate_ack

# Window size at zero (receiver saturated)
tcp.window_size == 0

# Out-of-order packets
tcp.analysis.out_of_order

# Connection closures
tcp.flags.fin == 1

The tcp.analysis.flags filter shows all packets for which Wireshark has detected an anomaly (retransmissions, duplicate ACKs, out-of-order packets). It is an excellent starting point for diagnosing performance problems.

TLS: negotiation and inspection without decryption

Even without decrypting the content, Wireshark lets you analyze the TLS negotiation. The Client Hello is particularly rich in information.

# All TLS exchanges
tls

# Client Hello (start of negotiation)
tls.handshake.type == 1

# Server Hello
tls.handshake.type == 2

# Certificate (the server certificate)
tls.handshake.type == 11

# Finished (end of handshake)
tls.handshake.type == 20

# TLS 1.3 only
tls.record.version == 0x0304

# SNI (Server Name Indication) - reveals the domain even over HTTPS
tls.handshake.extensions_server_name contains "example.com"

The SNI (Server Name Indication) field in the Client Hello reveals the target domain even on an HTTPS connection. This is why it is possible to monitor the domains visited without decrypting the content.

Advanced features

Follow TCP/UDP Stream

The Follow Stream feature reconstructs a complete conversation between two hosts. It is essential for analyzing application-level exchanges.

1. Select a packet belonging to the connection.
2. Right-click -> Follow -> TCP Stream (or UDP Stream, or TLS Stream if you have the keys).
3. The window displays the reconstructed client (red) and server (blue) dialogue.
4. You can filter on this stream only, and save the content in raw or text form.

Statistics: traffic overview

The Statistics menu offers several analytical views:

• Protocol Hierarchy: breakdown of traffic by protocol as a percentage. Ideal for identifying dominant or unexpected protocols.
• Conversations: lists every source/destination pair with the volume of data exchanged. Lets you quickly identify the heavy senders.
• Endpoints: lists all hosts seen in the capture with their traffic statistics.
• I/O Graph: graph of network throughput over time. Overlay several curves with different filters to compare normal vs suspicious traffic.
• Flow Graph: sequence diagram of the exchanges between hosts, ideal for visualizing a handshake or an application protocol.

Export Objects

Wireshark can extract files transferred over the network via certain protocols. Via File -> Export Objects:

• HTTP: extracts downloaded files (images, executables, documents) from HTTP traffic.
• SMB: extracts files shared via SMB/CIFS (Windows shares).
• DICOM: for medical environments.
• TFTP: files transferred via TFTP.

This feature is invaluable in forensics for recovering files exchanged during a security incident.

Coloring rules

Wireshark automatically colors packets according to predefined rules. You can customize them via View -> Coloring Rules. By default:

• Green: standard HTTP traffic.
• Light blue: DNS traffic.
• Black: TCP errors (retransmissions, RST).
• Red: serious errors (incorrect checksum).

Create your own rules to highlight traffic from a particular host, a specific protocol, or a suspicious pattern.

tshark on the command line

tshark is the CLI equivalent of Wireshark. It uses the same dissection engines and the same display filters, but it integrates into scripts and works without a graphical interface.

Basic capture

# List the available interfaces
tshark -D

# Capture on eth0 with output to the terminal
tshark -i eth0

# Capture with a BPF capture filter
tshark -i eth0 -f "port 80 or port 443"

# Capture and save to a pcap file
tshark -i eth0 -w /tmp/capture.pcap

# Capture with file rotation (1 file per 100 MB, keep the last 5)
tshark -i eth0 -b filesize:102400 -b files:5 -w /tmp/capture.pcap

# Capture 1000 packets then stop
tshark -i eth0 -c 1000 -w /tmp/capture.pcap

# Capture for 60 seconds
tshark -i eth0 -a duration:60 -w /tmp/capture.pcap

Reading and filtering pcap files

# Read a pcap file
tshark -r /tmp/capture.pcap

# Read with a display filter
tshark -r /tmp/capture.pcap -Y "http.request.method == POST"

# Extract specific fields
tshark -r /tmp/capture.pcap -Y "dns" -T fields -e frame.time -e ip.src -e dns.qry.name

# Extract HTTP URLs
tshark -r /tmp/capture.pcap -Y "http.request" -T fields -e http.host -e http.request.uri

# Extract source and destination IP addresses
tshark -r /tmp/capture.pcap -T fields -e ip.src -e ip.dst | sort | uniq -c | sort -rn

# Count requests per DNS domain
tshark -r /tmp/capture.pcap -Y "dns.flags.response == 0" -T fields -e dns.qry.name | sort | uniq -c | sort -rn

Exporting to JSON and CSV

# Full export to JSON (very verbose)
tshark -r /tmp/capture.pcap -T json > /tmp/capture.json

# Export to JSON with filters
tshark -r /tmp/capture.pcap -Y "http" -T json > /tmp/http_traffic.json

# Export specific fields to CSV (comma separator)
tshark -r /tmp/capture.pcap -T fields
    -e frame.number
    -e frame.time
    -e ip.src
    -e ip.dst
    -e tcp.srcport
    -e tcp.dstport
    -e frame.len
    -E separator=,
    -E header=y
    > /tmp/traffic.csv

# Export HTTP flows with domains and URIs
tshark -r /tmp/capture.pcap -Y "http.request"
    -T fields
    -e frame.time
    -e ip.src
    -e http.host
    -e http.request.method
    -e http.request.uri
    -E separator=,
    -E header=y
    > /tmp/http_requests.csv

Statistics from the CLI

# TCP conversation statistics
tshark -r /tmp/capture.pcap -q -z conv,tcp

# UDP conversation statistics
tshark -r /tmp/capture.pcap -q -z conv,udp

# Protocol hierarchy
tshark -r /tmp/capture.pcap -q -z io,phs

# DNS statistics
tshark -r /tmp/capture.pcap -q -z dns,tree

# HTTP statistics (response codes, methods)
tshark -r /tmp/capture.pcap -q -z http,tree

# Endpoints (all hosts)
tshark -r /tmp/capture.pcap -q -z endpoints,ip

Practical use cases

Case 1: detecting an Nmap scan

An Nmap SYN scan (half-open) sends SYN packets to many ports. The characteristic pattern is a burst of SYNs from a single source toward many destination ports.

# In Wireshark, apply this filter to see connection attempts
tcp.flags.syn == 1 && tcp.flags.ack == 0

# tshark: count SYN attempts per source
tshark -r /tmp/capture.pcap
    -Y "tcp.flags.syn == 1 && tcp.flags.ack == 0"
    -T fields -e ip.src -e tcp.dstport
    | awk '{print $1}' | sort | uniq -c | sort -rn

# Detect RST/ACK responses (closed ports) that follow the SYNs
tcp.flags.reset == 1 && tcp.flags.ack == 1

# Full pattern of a scan: many SYNs, many RST-ACKs in response
# Statistics -> Conversations (TCP) in Wireshark to visualize

In the Statistics -> Conversations view, an Nmap scan appears as a source host initiating hundreds of TCP connections toward different ports of the same target host, with almost no bytes transferred per connection.

Case 2: analyzing an HTTP connection

# Step 1: filter HTTP traffic
http

# Step 2: identify POST requests (form submissions)
http.request.method == "POST"

# Step 3: Follow HTTP Stream on a suspicious request
# Right-click -> Follow -> HTTP Stream

# Step 4: search for cleartext credentials
http.authorization
# or
http.request contains "password"

# Step 5: export the transferred objects
# File -> Export Objects -> HTTP

Case 3: identifying a TCP problem

# Step 1: display all packets with TCP anomalies
tcp.analysis.flags

# Step 2: focus on retransmissions
tcp.analysis.retransmission || tcp.analysis.fast_retransmission

# Step 3: look for abruptly reset connections
tcp.flags.reset == 1

# Step 4: look for window problems (congestion)
tcp.window_size_value == 0

# Step 5: visualize the Round-Trip Time
# Statistics -> TCP Stream Graphs -> Round Trip Time

# Step 6: analyze with tshark
tshark -r /tmp/capture.pcap -q -z tcp,stat,0

Case 4: analyzing a suspicious DNS resolution

# Display all DNS queries
dns.flags.response == 0

# Look for queries with very long subdomains (DNS exfiltration)
dns.qry.name matches ".{50,}"

# Look for DGA (Domain Generation Algorithm) domains - random names
# Analyze visually in Statistics -> DNS

# tshark: extract all resolved domains
tshark -r /tmp/capture.pcap
    -Y "dns.flags.response == 0"
    -T fields
    -e dns.qry.name
    | sort | uniq -c | sort -rn | head -20

# Detect queries to unauthorized DNS servers (other than 8.8.8.8 for example)
dns && ip.dst != 8.8.8.8 && ip.dst != 1.1.1.1

Legal and GDPR best practices

Fundamental rules

• Explicit authorization: never capture on a network without written authorization from the owner or the responsible administrator.
• Your own network: on your own equipment (lab, test VM, home network), there are no particular constraints.
• Professional environment: a security policy and an IT charter are mandatory. Captures must be documented and justified.
• Personal data: network captures may contain personal data (names, emails, passwords). The GDPR requires minimizing collection, securing storage and limiting the retention period.
• Encrypting captures: a pcap file may contain highly sensitive information. Encrypt them with GPG or VeraCrypt before storage or transfer.

Operational recommendations

• Use capture filters to limit collection to the data strictly necessary for your analysis.
• Delete pcap files after analysis or archive them securely with a defined retention period.
• Document each capture: date, interface, reason, scope, owner.
• In a production environment, prefer passive tools (port mirroring, SPAN) rather than promiscuous mode, which can intercept the traffic of other machines.
• On switched networks, you by default only see the traffic of your own machine and broadcasts. To capture the traffic of other hosts, you need a SPAN port or a hub-based network.

Conclusion

Wireshark is a fundamental tool for any IT professional, from the network developer to the security specialist. Mastering it makes it possible to diagnose complex network problems, validate the security of an infrastructure, and analyze incidents after the fact.

The key takeaways: use BPF capture filters to reduce load right from collection, master Wireshark display filters to navigate your captures efficiently, and use tshark to automate your analyses and integrate them into your security workflows. Finally, always respect the legal framework: traffic analysis is a powerful tool that demands responsible and authorized use.