Terminal and Network Tools Cheatsheet#

Tool knowledge matters in security work, but the real value is knowing when to use which tool. This cheatsheet summarizes the tool categories often used in a daily workflow within a safe and orderly framework.

The point of the cheatsheet is to be a worksheet an operator can consult while getting their morning coffee, a reminder of scope, speed, and logging discipline.

Threat Model: What Is an Operator Responsible For?#

A security operator is responsible for three mistakes:

1. Traffic to the wrong target: accidentally sending packets to an out-of-scope IP.
2. Clogging your own network: taking a service down with a high-speed scan.
3. A finding without evidence: putting an unreproducible claim in a report.

So every command should carry three things: scope, speed, output path.

nmap -sV --top-ports 100 -T3 -oA scans/target-$(date +%F) target
#        ^^^^ speed: T3                 ^^^ scope: top-ports 100
#                                   ^^^ output path: scans/

Trust Boundaries: What Runs on Which Network?#

[your device] --(1)--> [internet] --(2)--> [target]
       |
       |--(3)--> [internal network / local services behind a VPN]

Three boundaries; three rules:

1. Traffic going to the public internet: explicitly authorized, permitted, short-lived.
2. The target's response: don't treat it as trustworthy; sanitize it.
3. Scanning the internal network: only within an explicitly approved range and agreed test window, with owners informed, rate limits, and monitoring.

Before a cross-boundary command, verify the active interface and route with ip addr/ip route, confirm the current VPN/account and written scope, and remember that local network output does not establish authorization.

1. Discovery and Inventory#

The first goal is to understand which assets exist. At this stage the aim is not to stress the system but to document the visible surface.

Use cases:

• Domain and subdomain inventory
• Listing open services
• Checking certificates and DNS records
• Mapping ownership of cloud assets

The output must always return to a table. Scattered terminal output makes decisions harder in the next steps.

Typical commands:

: "${AUTHORIZED_DOMAIN:?Set a domain included in the written scope}"
: "${AUTHORIZED_HOST:?Set a host included in the written scope}"
: "${AUTHORIZED_CIDR:?Set an explicitly approved IP range}"
 
# Passive source lookups; verify every result is in scope before probing it.
subfinder -d "$AUTHORIZED_DOMAIN" -silent -o subs.txt
 
# ProjectDiscovery httpx sends active HTTP requests; probe only an explicitly approved host.
httpx -u "$AUTHORIZED_HOST" -status-code -title -tech-detect -o live.txt
 
# Narrow, low-rate lab example; a rate cap does not replace approval.
masscan -p80,443 --rate 10 "$AUTHORIZED_CIDR" -oG masscan.txt
 
# Active version and default-script probes; confirm host and ports are authorized.
nmap -sV -sC -p80,443 "$AUTHORIZED_HOST" -oN nmap-example.txt

Standardize output formats like -oN, -oX, -oG from day one; they can be combined with grep and jq in later reporting.

In Nmap, open describes that a listener was seen at that point; filtered describes that the response couldn't be determined because of a filter. Neither is a vulnerability on its own. -sV sends active application probes, and -sC sends default NSE scripts; the name "inventory" doesn't make them passive or harmless on every device. -T3 is not a fixed packets-per-second limit either. Nmap's own man page separates these states and timing options. The authorized IP, source network, and scan time should be recorded within scope; a hostname resolving to CDN/shared infrastructure doesn't automatically bring the IP into scope.

2. Traffic Observation#

Traffic observation helps you understand how the application or network talks. Wireshark, tcpdump, and proxy-based tools are used at this stage.

What to note:

Minimal capture with tcpdump:

sudo tcpdump -i eth0 -nn -s0 -w capture.pcap host example.com and port 443

Don't leave capture files open; their contents may contain sensitive data. Store the PCAP on an encrypted channel and keep an access log. Extracting a summary with tshark makes the follow-up easier:

tshark -r capture.pcap -Y "tls.handshake.type == 1" \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name | sort | uniq -c

Seeing port 443 doesn't mean the application body can be read. Without a TLS key, a capture mostly gives stream and handshake metadata; with ECH, even the SNI may not be visible. This filter catches not only TCP/443 but also UDP/443 QUIC, yet the TLS ClientHello filter above doesn't report every QUIC conversation the same way. Don't conclude "all visited sites" from an SNI list. Check that the capture was made on the right interface and that there was no packet loss; eth0 doesn't exist on every machine.

3. Daily and Evidence Management#

A finding's value increases with its reproducible evidence. Rather than copying terminal output at random, date, command, scope, and result should be stored together.

Simple format:

Date:
Scope:
Command/tool:
Purpose:
Summary result:
Screenshot or output path:

This order makes both report writing and finding verification easier.

Three rules for the chain of custody:

1. Note the sha256sum value of each evidence file.
2. Separate the working copy; chmod 444 reduces accidental writes but the file owner can reopen the permission. An immutable archive or an access-controlled evidence store is a separate control.
3. Keep the changes between the first finding and the report in a single "evidence log" file.

4. Safe Automation#

Automation saves time but causes harm if it runs uncontrolled. When writing a script, use low speed, clear scope, and open logging by default.

Good automation carries these properties:

• Requires the scope file explicitly
• Stops on error
• Produces output in a structured format
• Doesn't send excessive requests to the same target
• Records the run time and version

Reading a scope file is only the first step for safe scan automation. In this post, rather than a skeleton that sends no network request, define the contract of the tool to be run: don't start with an empty scope, error on an invalid target, an explicit speed cap, a record of command/version, and a separate output per target. Reading a file doesn't verify that the input is an authorized target or that the DNS result stays in scope. Before adding a live target, inspect the tool's target preview with only your own lab IP list; don't consider it safe just because there's a parameter named --scope.

5. Proxy and Handy Tools#

A few tools often used in daily work:

• curl: under almost everything for understanding HTTP. -i headers, -v verbose, --resolve DNS override.
• ffuf/gobuster: directory and vhost fuzzing. In ffuf, -w takes a wordlist, not a scope or target list; -u names the authorized URL and uses a FUZZ marker. Filter the URL/host list against written scope before sending requests.
• jq: transforms JSON API responses in the pipeline; powerful with httpx -json.
• dig/nslookup: DNS inventory; +short for quick greps.
• openssl s_client: certificate chain and TLS version check; s_client -connect example.com:443 -servername example.com.

Read the --help output for each tool once; write the two frequently used flags as an alias in ~/.zshrc or ~/.bashrc.

6. Observation -> Finding -> Report Flow#

[pcap / nmap / screenshot]
         |
         v
   evidence.log (sha256 + explanation)
         |
         v
   finding file: markdown
         |
         v
   report: executive summary + technical detail

Every arrow is a "handoff"; an arrow whose owner and time aren't noted leaves a break in the report.

Version Differences: Important Version Differences#

• nmap 7.x: -sV version detection, -sC default scripts; new NSE scripts with 7.80+.
• masscan: fast port discovery; if --rate is set wrong, local firewalls automatically fight back.
• tshark 4.x: output format changes often after Wireshark 4.0; in old 3.x scripts the -T json output structure stays the same but some field names may change.
• curl 8.x: HTTP/3 support depends on the build. --http3 may fall back to an older HTTP; a successful response alone isn't HTTP/3 proof. Inspect curl --version features and the actually negotiated protocol together.
• OpenSSL 3.x: legacy algorithms (RC4, old ciphers) are off by default; don't be surprised to get an error when talking to an old target.
• tcpdump: in modern versions -nn turns off host/port resolution; with older habits -n can be left out, use -nn.

Always note the command version: nmap --version, tshark --version, curl --version. Pasting it at the top of the output clarifies what was looked at in the report.

Detection and Mitigation Workflow#

When closing a discovery finding, follow this order:

[Finding] -> [Verify] -> [Threat?] -> [Fix plan] -> [Re-test] -> [Close]
                                       |
                                       +-- [Interim measure: log / alert]

• Verify: reproduce with the same command, if possible by another operator.
• Threat?: from the internal network or the outside, does it need a precondition?
• Fix plan: the smallest change, with rollback steps.
• Re-test: if not the same, a regression test with a broader scope.
• Close: archive the evidence, write the commit hash.

Conclusion#

Terminal tools alone don't create a security program. The real value emerges when you tie discovery, observation, evidence, and automation into a repeatable workflow. Write three pieces of information next to every command: why, where, and how it was verified. This habit lets you understand your own finding even six months later.

Version Notes: Quick Reference#

Copy this table to the top of your own cheatsheet; update the right column when you install a new version.

Command Templates#

# TLS version check
openssl s_client -connect example.com:443 -tls1_2 </dev/null 2>&1 | grep -i cipher
 
# Query record types explicitly; ANY is not a reliable "dump all DNS" operation.
dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig example.com MX +noall +answer
dig example.com TXT +noall +answer
 
# Certificate summary
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer
 
# JSON API quick smoke
curl -sS -H 'Accept: application/json' https://example.com/api/health | jq .
 
# Authorized lab URL only; use a wordlist approved for this target.
: "${AUTHORIZED_LAB_URL:?Set an authorized lab URL before probing}"
 
ffuf -u "${AUTHORIZED_LAB_URL%/}/FUZZ" -w common.txt -mc 200,301,302 -t 5 -rate 2 -o out.json -of json

This is an active request example for an authorized lab only. -rate caps request rate, but does not establish permission or guarantee safety; confirm the owner-defined limit and stop conditions first.

DNS ANY responses may be minimal or policy-dependent; query record types explicitly (RFC 8482).

Log and Alert Loop#

The backbone of operational discipline is this:

[command] -> [output] -> [evidence file] -> [note] -> [finding?] -> [report]

Every arrow is a discipline; if one arrow is missed, the evidence chain breaks. No operator working with a "I'll save it later" approach produces reliable findings in the long run.

Example Daily Flow#

09:00  check the scope file, was a new target added
09:15  passive recon: subfinder + crt.sh
10:00  live HTTP inventory: httpx
11:00  nmap -sV top 100 ports, T3 speed
12:00  noon: review the log, tell apart the unnecessary alerts
14:00  directory discovery with ffuf (in scope)
15:00  capture the interesting flow with tcpdump -> summarize with tshark
16:00  finding form: date, command, evidence, impact
17:00  end of day: write the report skeleton, leave a note for tomorrow

This flow is a template; you don't have to apply it identically every day. But try not to spend a day without a flow.

Conclusion: Don't Keep the Cheatsheet Fixed#

The cheatsheet itself is a living file. Add every new command you learn, delete what you don't use. Read the file top to bottom every three months; if you've forgotten part of it, it was either forgotten or not valuable. What's valuable deserves to stay in your memory; what's not should be deleted from command history.

Quick Version-Check Commands#

nmap --version | head -1
tshark --version | head -1
curl --version
ffuf -V
httpx -version
openssl version
tcpdump --version

Paste the output under evidence/YYYY-MM-DD/env.txt; later the question "which version produced that finding" is answered in a single line.

Related Research & Internal References#

• Safe Lab Work with Burp Suite - the proxy counterpart to network-level capture.
• Shadow API Asset Inventory - turning the discovery stage into a tracked inventory.
• Security Finding Scoring - scoring the findings this workflow produces.