Essential Kali Linux Tools for DevOps Engineers

Kali Linux ships with hundreds of tools, and the marketing usually frames them as “hacking” utilities. For a DevOps engineer, most of the ones you will reach for every day are simply excellent infrastructure diagnostic tools: they help you answer questions like “is the port open?”, “why is DNS resolving to the wrong address?”, “is this certificate about to expire?”, and “what is actually going over the wire?”. This lesson walks through the tools worth putting in your muscle memory, what each does, why it matters operationally, and a realistic troubleshooting scenario for each.

💡 Note — Everything below runs the same on a stock Ubuntu/Debian box. Kali just bundles these tools (and their more advanced siblings) preinstalled and up to date, which makes it a convenient diagnostic workstation.

A word on scope before we start

Every scanning, probing, or packet-capture example in this lesson is meant to be run against infrastructure you own or are explicitly authorized to test — your own servers, your lab VMs, your cluster, or public endpoints that exist for testing (like example.com or the 1.1.1.1 resolver). Port-scanning or capturing traffic on systems you do not control can be illegal and will get you into trouble. I will not repeat this on every command, so treat it as a standing rule for the whole lesson.

The toolkit at a glance

Here is the shortlist. Each row is a tool you can justify having on any DevOps troubleshooting box.

Tool	DevOps Use
Nmap	Service discovery and port/health checks
tcpdump	Packet inspection on the CLI
Wireshark	Deep packet analysis with a GUI
dig	DNS troubleshooting and resolution tracing
curl	HTTP/API testing and endpoint probing
OpenSSL	TLS/certificate troubleshooting
traceroute	Network path and latency diagnosis
netcat	Socket/port connectivity testing
whois	Domain and IP ownership/registration lookups
ss	Socket and listening-port inspection
jq	Parsing and querying JSON output
grep	Filtering logs and command output
awk	Column extraction and field reporting
sed	Stream editing and config rewriting

The rest of the lesson goes tool by tool.

Network reachability and service discovery

Nmap — what is actually listening?

Nmap maps hosts and the services running on them. As a DevOps engineer you use it to confirm that a service is bound and reachable, to verify a firewall change did what you expected, and to inventory what a host is exposing.

# Scan the common ports on a host you own and grab service/version banners
nmap -sV -T4 10.0.5.20

-sV asks Nmap to probe for the software and version behind each open port, and -T4 speeds up timing on a responsive local network.

🔎 Troubleshooting Tip — Deployed a service but the client can’t connect? Run nmap -p 8080 <host> from where the client lives. open means the app is bound and the firewall allows it; filtered almost always means a firewall or security group is dropping the packet; closed means nothing is listening on that port.

⛔ Production Warning — Aggressive scans (-A, high -T5 timing, full -p- sweeps) can generate real load and trip intrusion-detection alarms. Against production, scope tightly (-p a single port) and coordinate with whoever owns the box. There is a full lesson on this in Nmap for DevOps.

traceroute — where does the path break?

traceroute shows each network hop between you and a destination, with the latency at each step. It is the tool for “the service is up, but it’s slow or unreachable from one region.”

# Trace the path to a host, using ICMP probes
traceroute example.com

🔎 Troubleshooting Tip — When latency spikes, read the hop where round-trip times jump and stay high — that is usually where the problem lives. A run that stalls with * * * for the last several hops often means a firewall is silently dropping the probes near the destination, not that the whole path is down.

netcat — is this single port reachable?

netcat (nc) is the Swiss-army knife for raw TCP/UDP connections. For diagnostics it is the fastest way to answer “can I open a socket to this port right now?” without pulling in a whole client.

# Test whether a TCP port on your own host is accepting connections
nc -vz db.internal 5432

-v is verbose, -z does a zero-I/O scan (connect and report, send nothing).

🧪 Try It — On a lab host, start a listener with nc -l 9000 in one terminal, then from another machine run nc -vz <lab-host> 9000. Watch the “succeeded” message. Now stop the listener and rerun it to see a “connection refused” — that contrast is exactly what you look for when a real service is or isn’t bound.

ss — what is my own host listening on?

ss (the modern replacement for netstat) inspects sockets on the local machine: what is listening, on which address, and which process owns it. This is your first stop when a service “isn’t reachable” — before you blame the network, confirm the process is actually bound.

# Show all listening TCP sockets with the owning process
ss -ltnp

-l listening, -t TCP, -n numeric ports, -p show the process.

🔎 Troubleshooting Tip — A common gotcha: a service bound to 127.0.0.1:8080 shows up in ss but is unreachable from other hosts because it is listening only on loopback, not 0.0.0.0. ss -ltnp makes that bind address obvious at a glance.

Packet-level inspection

tcpdump — what is really on the wire?

When higher-level tools disagree with reality, tcpdump settles the argument by showing the actual packets. It runs anywhere, needs no GUI, and is ideal on a headless server.

# Capture traffic to/from a host on port 443 on interface eth0 (owned host)
sudo tcpdump -i eth0 host 10.0.5.20 and port 443 -n

-n skips DNS resolution so the capture stays fast and readable; the host ... and port ... is a BPF filter that keeps only the traffic you care about.

🔎 Troubleshooting Tip — Seeing repeated SYN packets with no SYN-ACK in reply is the classic signature of a dropped/blocked connection — the client is trying, nothing is answering. That single observation redirects you straight to firewall/security-group rules. Deeper walkthrough in tcpdump for DevOps.

🔐 Security Note — Packet captures can contain credentials, tokens, and personal data. Store .pcap files carefully, avoid capturing more than you need, and delete them when the investigation is done.

Wireshark — the deep-dive GUI

Wireshark opens the same captures with a graphical UI, protocol dissectors, and the ability to “follow a stream” to reconstruct a full conversation. The typical workflow is to capture headlessly with tcpdump on the server, then analyze locally.

# Capture on the server, write a file, then open it in Wireshark on your laptop
sudo tcpdump -i eth0 -w /tmp/debug.pcap host 10.0.5.20
wireshark /tmp/debug.pcap

🛠️ DevOps Perspective — Wireshark’s “Follow TCP Stream” and its per-protocol filters (http.response.code >= 500, tls.handshake) turn a raw capture into a readable story. Use it when tcpdump has confirmed that something is wrong and you need to see what.

DNS diagnostics

dig — why is this name resolving here?

dig queries DNS directly and shows you exactly what the resolver returns, including which server answered and the TTL. It is the correct tool for every “it works on my machine but not in prod” issue that turns out to be DNS.

# Ask a specific resolver for the A record, short output
dig @1.1.1.1 example.com A +short

# See the full authority chain and TTLs
dig example.com A

🔎 Troubleshooting Tip — Just cut over a deployment but half your traffic hits the old server? Compare dig +short results against several resolvers (@1.1.1.1, @8.8.8.8, your internal resolver). Differing answers mean the change hasn’t propagated everywhere yet, and the record’s TTL tells you how long the stragglers will keep the stale value. Full lesson: DNS troubleshooting.

whois — who owns this domain or IP?

whois returns registration data for a domain or the ownership/allocation for an IP block. Operationally it answers “when does this domain expire?” and “which network does this suspicious source IP belong to?”

# Registration details for a domain
whois example.com

# Ownership of an IP address seen in your logs
whois 93.184.216.34

🔎 Troubleshooting Tip — An unexplained outage right at renewal time is worth a whois check — an expired domain registration takes a whole service down and won’t show up in any of your infrastructure dashboards. For an IP hammering your logs, the whois OrgName/netname tells you whether it’s a cloud provider, a partner, or something to block.

HTTP and API testing

curl — is the endpoint behaving?

curl is the universal HTTP client. For DevOps it validates that an endpoint returns the right status, headers, and body — from load balancer health checks to third-party API integration.

# Show only the response status and headers
curl -sSI https://example.com

# Time each phase of the request to find where latency hides
curl -sS -o /dev/null -w "dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

-I fetches headers only; the -w template prints a timing breakdown so you can see whether slowness is DNS, connection setup, or the server thinking.

🧪 Try It — Run the timing command above against one of your own endpoints. If time_namelookup dominates, your DNS is the bottleneck; if time_starttransfer is high, the application is slow to respond. That one line often replaces an hour of guessing. More in HTTP and API troubleshooting.

🔎 Troubleshooting Tip — Chase redirects with -L, and add -v to see the full request/response conversation including the TLS handshake summary. curl -v is frequently the fastest way to prove whether a problem is in DNS, TLS, or the HTTP layer.

TLS and certificates

OpenSSL — is the certificate valid, current, and trusted?

openssl inspects and tests TLS. The s_client subcommand connects to a service and dumps the certificate chain, negotiated protocol, and cipher — everything you need to diagnose an expiry, a missing intermediate, or a hostname mismatch.

# Connect and print the certificate's validity dates
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

The -servername flag sends SNI, which matters when many sites share one IP. Piping into openssl x509 extracts just the human-readable fields.

🔎 Troubleshooting Tip — Browser or client throwing a certificate error while the site looks fine to you? A frequent cause is a missing intermediate certificate: your machine has it cached, but a fresh client doesn’t. openssl s_client prints the chain the server actually sends — if the intermediate isn’t there, the server config is incomplete. Deep dive in TLS certificate troubleshooting.

🛠️ DevOps Perspective — Wrap the -dates check in a small script and alert when notAfter is within, say, 14 days. Silent certificate expiry is one of the most common and most preventable production outages.

Turning output into answers: the text toolkit

Diagnostic commands produce a lot of text. These four tools turn that firehose into the one fact you need.

jq — query JSON like a database

Modern infrastructure speaks JSON — cloud CLIs, Kubernetes, most APIs. jq filters and reshapes it.

# Pull just the running pod names from kubectl JSON output
kubectl get pods -o json | jq -r '.items[] | select(.status.phase=="Running") | .metadata.name'

🔎 Troubleshooting Tip — When an API returns a wall of JSON and you only care about one field, jq -r '.some.path' beats scrolling. Pair it with curl (curl -sS ... | jq .) to make any API response readable instantly.

grep — find the needle in the log

grep filters lines by pattern. It is the first thing you reach for in any log investigation.

# Show 5xx responses in an access log, with a little surrounding context
grep -E ' 5[0-9]{2} ' /var/log/nginx/access.log | tail -n 20

🔎 Troubleshooting Tip — grep -c counts matches (how many 500s since midnight?), and grep -v inverts to remove noise. Chaining grep -v health | grep error strips out health-check spam before you look for real errors.

awk — extract and summarize columns

awk treats each line as fields, which makes it ideal for pulling one column or aggregating.

# Count requests per client IP in an access log (top talkers)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

🔎 Troubleshooting Tip — During a traffic spike, that one-liner tells you in seconds whether the load is spread across many clients or coming from a handful of IPs — which decides whether you scale up or start rate-limiting.

sed — rewrite streams and configs

sed edits text on the fly. In diagnostics it is handy for normalizing output, and in automation for scripted config edits.

# Redact tokens from a log before sharing it
sed -E 's/(token=)[A-Za-z0-9]+/\1REDACTED/g' app.log > app.log.safe

⛔ Production Warning — sed -i edits files in place. Before running an in-place substitution against a real config, test the expression without -i first (so it prints to stdout) and keep a backup. A greedy regex can quietly corrupt a config file.

Putting it together: a realistic incident

Tools shine when chained. Say an internal API “went down.” A tight diagnostic loop might look like:

1. curl -sSI https://api.internal/health   → hangs / no response
2. dig api.internal +short                 → resolves to 10.0.5.20 (correct)
3. nc -vz 10.0.5.20 443                     → connection refused
4. ss -ltnp  (on 10.0.5.20)                → nothing listening on 443
   → the app process crashed; DNS and network are fine. Restart + investigate.

Four commands, and you have moved from “the API is down” to “the process isn’t bound, and here’s the proof.” That is the DevOps value of these tools: they replace guessing with evidence.

🛠️ DevOps Perspective — Notice the layered approach: name resolution (dig) → reachability (nc) → local bind state (ss). Working the stack from the outside in — or inside out — isolates the failing layer fast, instead of changing five things at once and hoping.

Where to go next

Ready to go deeper on the biggest tools? Start with Nmap for DevOps and tcpdump for DevOps.
For the protocol-specific playbooks, see DNS troubleshooting, HTTP and API troubleshooting, and TLS certificate troubleshooting.
Need a networking refresher first? Review networking fundamentals.
Applying these on containers? The Kali in Docker lesson and the broader Linux admins guides are good follow-ups.

What You Learned

Most of the Kali tools a DevOps engineer needs are diagnostic, not offensive: Nmap, tcpdump, Wireshark, dig, curl, OpenSSL, traceroute, netcat, whois, ss, jq, grep, awk, and sed.
Each tool maps to a specific question — reachability (nc/ss), service discovery (Nmap), packet truth (tcpdump/Wireshark), DNS (dig/whois), HTTP (curl), TLS (OpenSSL), and turning noisy output into answers (jq/grep/awk/sed).
Timing flags (curl -w, traceroute) and bind-address inspection (ss -ltnp) isolate which layer is failing, so you fix the real cause instead of guessing.
Chaining a few commands in a deliberate order — resolve, reach, bind — turns “it’s down” into evidence in under a minute.
These tools carry real power: only ever point them at infrastructure you own or are explicitly authorized to test, and handle captures and logs as sensitive data.