ToolkitNetwork Forensics

Practical documentation · Authorized use only

tcpdump

tcpdump captures and filters network packets for authorized troubleshooting, incident response, and protocol validation. It is most effective with narrow Berkeley Packet Filter expressions, protected capture files, explicit interface choice, and a preservation plan for sensitive traffic.

Packet CaptureNetwork ForensicsBlue TeamCLI

Start safely and get useful results

Best for

  • • Network troubleshooting
  • • Incident-response packet evidence

Not for

  • • Indiscriminate capture
  • • Capturing sensitive traffic without retention controls

Before you run anything

  • • Document the authorized target, time window, success criteria, data-handling rules, and a named stop contact before you begin.
  • • Confirm the installed version with the tool’s version or help command, then compare its documented behavior with the linked upstream project before relying on any option.

Practical workflows

Beginner

Inspect DNS traffic on one interface

Scenario: Troubleshoot a local lab resolver without storing full payloads.

sudo tcpdump -ni eth0 udp port 53

Capture DNS packet metadata on the chosen interface without name resolution; replace eth0 with the approved interface.

Expected use: Expect queries and responses; stop promptly and record the time window.

Intermediate

Create a bounded capture file

Scenario: Preserve a short packet trace for a reproducible lab issue.

sudo tcpdump -ni eth0 -c 200 -w dns-lab.pcapng udp port 53

Limit capture to 200 packets and write a protected evidence file for later analysis.

Expected use: Hash and restrict access to the file because packet data can contain identifiers and content.

Advanced

Use precise filters for service validation

Scenario: Confirm a local TLS handshake reaches the intended host.

sudo tcpdump -ni eth0 host 192.0.2.10 and tcp port 443

Narrow capture by approved host and port to reduce unnecessary collection.

Expected use: Correlate timestamps with application and firewall logs before diagnosing an issue.

Interpret results like an analyst

  • • Packet capture reveals observed traffic, not application intent or user identity by itself.
  • • Dropped packets, offloading, encryption, and asymmetric paths can change what the interface sees.

Common mistakes and operating tips

Avoid

  • • Capturing on the wrong interface or forgetting a capture limit.
  • • Sharing PCAPs without redaction, access control, or chain-of-custody details.

Operational discipline

  • • Treat command output as evidence, not a conclusion: retain the command, version, scope, timestamp, and a redacted result in the engagement record.
  • • Start with the smallest safe scope, validate expected behavior in a lab or pilot, then expand only when the authorization and monitoring plan support it.

Verify against the current upstream

Tool behavior and release syntax can change. Treat this guide as practical operating context, then verify version-specific details against the upstream project before an assessment.

Open authoritative upstream documentation