Packet Analysis

Packet capture records traffic visible at a chosen observation point. It can reveal protocol exchanges and timing, but it can also collect credentials, personal data, and unrelated users' traffic. Obtain authorization, minimize scope, protect files, and follow retention policy.

Choosing the Observation Point

Capture on the interface and network namespace through which the affected flow actually passes. Bridges, containers, VPNs, bonds, VLANs, and offload can change what one interface shows. Use ip route get and ip link to identify candidates before capturing.

CheckWhy does capture-interface choice matter?

Every interface automatically mirrors the entire Internet. Only traffic visible at that observation point can be recorded. The interface name decrypts TLS payloads.

Capturing a Bounded Flow

Capture up to 100 packets without name resolution, restricted to a host and TCP port:

$ sudo tcpdump -i enp1s0 -n -c 100 -w incident.pcap \
    'host 192.0.2.25 and tcp port 443'

-i selects the interface, -n keeps numeric names, -c bounds packet count, -w writes pcap data, and the final expression is a capture filter. Also set a time bound externally when traffic may be absent.

CheckWhat does -c 100 do?

Captures only TCP port 100. Compresses the file to 100 bytes. Stops after capturing 100 packets.

Reading Captured Packets

Analyze the saved file without changing it:

$ tcpdump -n -tttt -r incident.pcap

Read timestamps, protocol, source, destination, flags, sequence or acknowledgement data, and length according to the protocol. A capture timestamp marks observation at this host, not necessarily the exact transmit time elsewhere. Clock synchronization matters when correlating captures from several systems.

CheckWhich option reads packets from a saved pcap file?

-r -i -w

Interpreting Absence and Encryption

No captured packet can mean the wrong interface or namespace, capture loss, an overly narrow filter, offload effects, routing elsewhere, or no traffic. Check tcpdump's received and dropped counters and reproduce a known event.

TLS and other encryption normally hide application payloads while leaving useful metadata such as endpoints, timing, sizes, TCP behavior, and parts of handshakes. Do not attempt unauthorized decryption or collect private keys casually.

CheckWhat does an empty filtered capture prove?

The remote application has been permanently deleted. The entire network has zero traffic. Only that no matching packets were recorded at that capture point.

Protecting and Sharing Evidence

Store pcaps with restrictive permissions, record command, host, interface, timezone, filter, and incident window, and hash evidence when integrity matters. Before sharing, minimize or sanitize data with tools and procedures that preserve needed fields; packet payloads and even metadata can identify users and systems.

CheckHow should an incident pcap be handled?

As sensitive evidence with restricted access and documented provenance. As harmless text suitable for public upload without review. By editing bytes in place without preserving the original.

Summary

You can now create a useful packet capture without making it unnecessarily broad or unsafe.

1. Choose the correct interface and network namespace.
2. Bound captures by filter, packet count, and time.
3. Save raw packets and analyze the file read-only.
4. Treat absence and encrypted payloads with proper limits.
5. Protect capture confidentiality, integrity, and provenance.