🔄 Topic

The Google Cybersecurity Certificate introduced me to tcpdump, a command-line network protocol analyser. I had already used Wireshark to inspect a supplied packet capture, but tcpdump gave me a different perspective: I can begin an investigation from a terminal, collect a bounded sample, filter it, and save the evidence for later analysis.

This was study material rather than a claim that I had captured production traffic. The security lesson was learning which questions the command can answer and how to keep the capture authorised, limited, and reproducible.

🎯 Goal

Understand the basic workflow for inspecting network traffic with tcpdump:

choose the interface deliberately;
limit the capture instead of collecting indefinitely;
make addresses and ports visible as numbers;
save and replay a packet capture;
use protocol, port, address, and Boolean filters to reduce noise.

🛠 What I Studied

The basic structure is:

sudo tcpdump [-i interface] [options] [expression]

The sudo prefix is commonly needed because packet capture requires elevated privileges. The -i option selects the interface. Before capturing, -D can list the interfaces available on the system; -i any can observe all available interfaces, but that broad choice should be intentional because it also increases the amount of traffic to interpret.

The command-line example sudo tcpdump -i any -v -c 1 captures one packet with verbose output. The count matters: a bounded capture is easier to reason about and reduces accidental collection. The timestamp, source and destination addresses, ports, protocol, length, and TCP flags can then be read as pieces of a timeline rather than as an unexplained wall of text.

I also studied the options that make a capture reusable:

sudo tcpdump -i any -w packetcapture.pcap
sudo tcpdump -r packetcapture.pcap -n

The first command writes packets to a pcap file. The second reads that file later. Saving the input makes the analysis repeatable: I can document which capture was used, apply a different filter, and compare the result without relying on the traffic still being present.

🔍 Filtering and Interpreting Evidence

The -n option disables hostname resolution, while -nn disables hostname and port-name resolution. Numeric output is useful during an investigation because it avoids misleading translations such as displaying port 80 as HTTP when the port alone does not prove which application protocol was used. It can also avoid an unnecessary reverse-DNS lookup while examining a potentially hostile address.

Expressions narrow the question further:

sudo tcpdump -r packetcapture.pcap -nn 'ip and port 80'
sudo tcpdump -r packetcapture.pcap -nn 'ip and (port 80 or port 443)'

The first expression selects IPv4 traffic involving port 80. The second groups two port conditions. Other expressions can focus on IPv6, a particular host, or a protocol. Quoting the expression keeps the shell from interpreting the Boolean structure before tcpdump receives it.

The most important habit is to separate observation from conclusion. A timestamp helps place a packet in a sequence. An address and port identify the visible endpoints. TCP flags describe part of the connection behaviour. None of those fields alone proves that a user was compromised or that traffic was malicious. I would still need asset ownership, authentication records, expected service context, and surrounding packets.

🔗 Key Cybersecurity Connections

🔍 Investigation Questions

When using tcpdump in an authorised environment, I would ask:

Which interface and time window are in scope?
Is the capture bounded by packet count or another approved limit?
Which protocol, address, or port question am I trying to answer?
Are names being resolved, and could that make the output ambiguous or reveal that an address is being investigated?
Can another analyst replay the same pcap and reproduce the observation?

🚨 Detection Opportunities

Tcpdump can help with early triage: unusual destinations, unexpected protocols, repeated connection attempts, traffic outside a normal window, or a host communicating with a service it should not use. It is a collection and inspection tool, not a complete detection system. A useful alert still needs a baseline, asset context, and a response path.

🧭 MITRE ATT&CK Techniques

No direct ATT&CK technique mapping is claimed for learning how to operate tcpdump. The tool can support investigations of many behaviours, but seeing a packet does not identify an ATT&CK technique by itself.

⚠️ Challenges and Boundaries

The volume of output is the first challenge. A packet analyser can show far more detail than I need, so interface choice, packet counts, numeric output, and expressions are not cosmetic options; they are ways to control the investigation surface.

The second boundary is authorisation. Packet captures can contain sensitive metadata and sometimes readable application data. I should capture only traffic I am allowed to inspect, store pcaps carefully, and redact identifying endpoints before sharing a write-up. Encrypted traffic may still reveal timing, endpoints, and protocol metadata even when its payload cannot be read.

I studied the course examples and command syntax here. I am not presenting a live capture from someone else's network, and I am not claiming that the optional course activity was completed unless its own result is recorded separately.

📚 What I Learned

Tcpdump makes network analysis feel like an evidence pipeline:

authorised interface → bounded capture → numeric output → saved pcap → focused filter → cautious interpretation

The command line is powerful because each option makes an investigative decision visible. -c says how much evidence I need, -w preserves the input, -r makes the work repeatable, -nn keeps identifiers explicit, and expressions document the question used to reduce noise.

➡ Next Steps

I want to practise this workflow against a deliberately generated local capture, using only owner-controlled traffic and synthetic endpoints. I would record the exact interface, capture limit, filter, pcap hash, and observed result, then compare the terminal view with a graphical analyser such as Wireshark.

🧠 Reflection

My first instinct with packet output is to search for something that looks suspicious. Tcpdump taught me to begin with a narrower question instead: what traffic was observed, how was it collected, and what does the evidence actually prove? That change makes a short terminal capture more useful than a large unexplained dump.

🧩 Lessons Learned

A packet capture should have an explicit scope and an authorised source.
Numeric output reduces ambiguity caused by name and service resolution.
Saving and replaying a pcap makes an investigation reproducible.
Filters reduce noise, but they do not turn one packet into a verdict.
Timestamps, endpoints, ports, and flags become meaningful when correlated with other evidence.

😄 TL;DR

I studied tcpdump as the command-line companion to Wireshark. The useful workflow is to capture only what is authorised and necessary, save the evidence, replay it with numeric output, filter it around a specific question, and keep observations separate from conclusions.