Malwarebytes - Cybersecurity for Everyone

Linux Networking Commands Cheat Sheet: ip, ss, nmap (2026)

byShubham Chaudhary •October 31, 2026

0

Linux terminal showing ip, ss, dig, curl and nmap networking commands in a SOC analyst security cheat sheet

Linux Networking Commands Cheat Sheet: ip, ss, curl, dig and nmap for Security Investigations

Last verified: October 31, 2026

Picture a 3 a.m. alert on a Linux build server. The monitoring dashboard says outbound traffic is "a little high," and nothing else. No malware alert, no failed logins, no obvious red flag. The analyst on shift has no time to wait for a full forensic image. She has a terminal, SSH access, and about ten commands she knows by heart. Within five minutes she knows which process owns the odd connection, where it is going, and whether DNS has been behaving strangely.

Quick Reference Table

Command	Primary Use	Security Value
ip	Interfaces, addresses, routes, neighbors	Spot rogue routes, promiscuous mode, unexpected interfaces
ifconfig	Legacy interface info	Still seen on older hosts; replaced by ip
ping	ICMP reachability and MTU tests	Confirm isolation, test segmentation
traceroute	Hop-by-hop path	Find where traffic is filtered or rerouted
netstat	Legacy socket listing	Quick look on older systems
ss	Modern socket listing	Map connections to processes
curl	HTTP/HTTPS requests	Inspect headers, redirects, TLS behavior
wget	File and header retrieval	Fetch artifacts for analysis in a safe environment
scp	Copy files over SSH	Collect evidence; watch for misuse
rsync	Efficient sync over SSH	Preserve evidence, detect bulk copying
dig	Detailed DNS queries	Check records, resolvers, suspicious domains
nslookup	Simple DNS lookups	Quick checks, also available on Windows
nmap	Port and service discovery	Audit your own exposure and baseline changes

Interfaces and Routing: ip and ifconfig

The ip command comes from the iproute2 suite and is the modern replacement for the older net-tools utilities. If you are still typing ifconfig out of habit, that is fine for reading output, but plan to move on. Many current distributions no longer install net-tools by default.

ip -br addr
ip -br link
ip route
ip neigh
ip route get 1.1.1.1

What they do: The first two give a compact list of addresses and link states. ip route shows the routing table. ip neigh shows the neighbor (ARP) cache. ip route get tells you exactly which interface and gateway the kernel will use to reach a destination.

When to use them: At the start of any investigation. A server with an unexpected extra interface, a surprise default route, or a static route pointing to an unfamiliar gateway deserves a closer look. In ip link output, a PROMISC flag on an interface means it is capturing traffic not addressed to it. That is legitimate on a monitoring sensor and suspicious on a web server.

Expected output: A short list such as eth0 UP 10.0.4.15/24, plus a default route line beginning with default via. Compare it against what your configuration management says the host should look like.

For legacy systems, ifconfig -a lists all interfaces, including ones that are down. The information overlaps with ip addr, but the output format is older and less detailed.

Reachability and Path Analysis: ping and traceroute

ping -c 4 10.0.4.1
ping -c 4 -s 1472 -M do 10.0.4.1
traceroute -n 203.0.113.10
sudo traceroute -T -p 443 -n 203.0.113.10

What they do: ping -c 4 sends four ICMP echo requests. The second form sends a 1472-byte payload with fragmentation prohibited, which tests whether a standard 1500-byte MTU path works end to end. traceroute -n maps hops without DNS lookups, which is faster and avoids leaking queries. The -T -p 443 variant uses TCP SYN probes to port 443, which often gets through where ICMP and UDP probes are filtered. It needs root.

When to use them: After you isolate a host with firewall rules or a VLAN change, ping confirms the isolation actually worked. During network segmentation reviews, traceroute shows whether traffic from a user subnet can reach a restricted zone and where it stops. Keep in mind that a failed ping does not prove a host is down. Many hardened systems drop ICMP by design.

Connection Visibility: ss and netstat

If you only memorize one command from this article, make it ss. It reads socket information directly from the kernel, runs faster than netstat on busy systems, and supports rich filtering. SANS has published guidance on using ss for Linux incident response because it connects network activity to process IDs quickly.

sudo ss -tulpn
sudo ss -tnp state established
ss -s

What they do: -t and -u select TCP and UDP, -l shows listening sockets, -p shows the owning process, and -n keeps numeric addresses and ports. The second command lists only established TCP connections. ss -s prints summary counts.

When to use them: The first command answers "what is this machine offering to the network?" Run it and ask whether every listener is expected. The second answers "who is this machine talking to right now?" Look for established connections from processes that have no business talking to the internet, such as a database daemon connecting to an unfamiliar external address. Run these as root, otherwise process information for other users is hidden.

The legacy equivalent is sudo netstat -tulpn. It does the same job and you will still find it in older runbooks and on minimal or embedded systems.

HTTP Inspection: curl and wget

curl -I https://example.com
curl -sS -o /dev/null -w '%{http_code} %{remote_ip} %{time_total}\n' https://example.com
curl -v https://example.com
wget -S --spider https://example.com

What they do: curl -I fetches only response headers. The -w format string prints the status code, the IP address that actually answered, and total time, which is handy for scripting health checks and spotting unexpected redirects or DNS changes. -v shows the TLS handshake and full request and response headers. wget -S --spider checks a URL and prints server headers without downloading the body.

When to use them: When you need to know what a suspicious URL does without opening it in a browser, headers often tell you enough: redirect chains, server banners, and certificate details. Use an isolated analysis machine for this, never a production host.

Safety note: Never pipe the output of curl or wget directly into a shell, and never run a downloaded file on a production system. Save it, hash it with sha256sum, and compare against the vendor's published checksum before doing anything else. Pulling a remote script straight into an interpreter is a common pattern in real-world compromises, so treat it as a detection signal in shell history and process logs.

File Transfer: scp and rsync

scp -p analyst@10.0.4.20:/var/log/auth.log ./evidence/
rsync -avz --dry-run -e ssh analyst@10.0.4.20:/var/log/ ./evidence/logs/

What they do: scp copies files over SSH; -p preserves timestamps and modes. rsync synchronizes directories efficiently, sending only differences. -a preserves attributes, -v is verbose, -z compresses, and --dry-run shows what would happen without copying anything.

When to use them: Collecting logs and artifacts from a suspect host to an analysis workstation. Always run rsync with --dry-run first. Warning: the --delete option removes files at the destination that are missing from the source, so never use it when handling evidence. Also note that recent OpenSSH releases changed scp to use the SFTP protocol under the hood by default, which is worth knowing if an older script behaves differently after an upgrade.

Defender's angle: Because these tools use SSH, they blend into normal admin traffic. Unexpected outbound SSH from a database or application server, especially with large byte counts, is a classic data-staging indicator. Alert on it using flow logs and process auditing.

DNS Investigation: dig and nslookup

dig example.com A +short
dig example.com MX
dig example.com TXT
dig @1.1.1.1 example.com
dig -x 203.0.113.10
dig +trace example.com
nslookup -type=MX example.com

What they do: dig queries DNS in detail. +short trims the output to the answer. @1.1.1.1 asks a specific resolver, so you can compare answers from your internal resolver against a public one. -x performs a reverse lookup. +trace walks the delegation from the root servers down. nslookup is simpler and available on both Linux and Windows, which makes it convenient for quick checks and for cross-platform runbooks.

When to use them: DNS is where many investigations are won. If the answer from your internal resolver differs from a public resolver for a well-known domain, you may have DNS tampering or a poisoned cache. Reverse lookups on unfamiliar destination IPs seen in ss output give you context quickly. TXT and MX records help when reviewing email authentication settings such as SPF and DMARC for domains you manage.

Attack Surface Management with nmap

Authorization first: Only scan systems you own or have written permission to test. Unauthorized scanning can violate policy and, in some jurisdictions, law.

nmap -sn 192.168.1.0/24
nmap -sV -p 22,80,443 192.0.2.10
nmap -sV --top-ports 100 -oN baseline.txt 192.0.2.10
ndiff baseline.txt latest.txt

What they do: -sn performs host discovery without port scanning. -sV probes open ports to identify service versions. --top-ports 100 checks the 100 most common ports. -oN saves normal-format output to a file, and ndiff, which ships with nmap, compares two result files.

When to use them: This is lightweight attack surface management. Scan your own hosts on a schedule, save the output, and diff it against the previous run. A new open port that nobody approved is a finding, whether it is a forgotten test service or something worse. It will not replace a commercial vulnerability management platform, but it is a free, fast way to catch drift between scans.

A 5-Minute Threat Hunting Workflow

Here is how these commands fit together when you are triaging a Linux host. This is the same order the analyst in our opening scenario would follow.

Minute 1 - Orient: ip -br addr and ip route to confirm the host's identity and path.
Minute 2 - Listeners: sudo ss -tulpn to compare listening services against the expected list.
Minute 3 - Active connections: sudo ss -tnp state established, noting remote IPs and owning processes.
Minute 4 - Context: dig -x on unfamiliar remote IPs, then dig against two different resolvers for any suspicious domain names.
Minute 5 - Decide: If something looks wrong, isolate the host through your firewall or EDR console, then collect logs with rsync or scp to your analysis workstation.

These commands give you a snapshot, not a timeline. Pair them with centralized logging so you can see what happened before you logged in. That is where endpoint detection and response tools and a SIEM earn their cost.

Indicators Worth Escalating

What you see	Command	Why it matters
Listener on an unexpected high port owned by an unfamiliar binary	ss -tulpn	Could be a backdoor listener or an unapproved service
Regular outbound connections at fixed intervals	ss -tnp	Pattern consistent with command-and-control beaconing (analyst judgment required)
PROMISC flag on a non-sensor host	ip link	Possible packet capture
Unfamiliar default route or static route	ip route	Traffic may be redirected through an unexpected gateway
Different DNS answers across resolvers for the same domain	dig @resolver	Possible DNS tampering or a misconfigured resolver
New open port compared to last baseline	nmap + ndiff	Configuration drift or unauthorized service
Large outbound SSH transfer from a server that never does that	ss, flow logs	Possible data staging or exfiltration

None of these indicators is proof of compromise on its own. They are leads. Confirm with logs, process trees, and file integrity data before you declare an incident.

Detection and Prevention Tips

Baseline everything. Save the output of ss -tulpn and your nmap results for each server role. Detection starts with knowing what normal looks like.
Close what you do not need. Every listener you can remove is one less thing to patch. Use host firewalls such as nftables, ufw, or firewalld alongside network firewalls.
Restrict outbound traffic. Most servers need to reach a short list of destinations. Egress filtering turns many silent compromises into blocked connections and noisy logs.
Log DNS. Query logs from your resolver give you the history that dig cannot.
Harden SSH. Prefer key-based authentication, disable direct root login, and restrict which accounts may use scp and rsync where practical.
Audit command use. Enable process execution auditing (for example, with auditd) so that unexpected use of curl, wget, or nmap on a production server generates an alert.
Align with frameworks. Regular exposure checks and logging support common compliance expectations, including NIST guidance and cyber insurance questionnaires. Check your own requirements with your compliance team, since details vary by organization.

Expert Tips

Add -n wherever it exists. Reverse DNS lookups slow commands down and can mask what you are actually looking at.
Keep a read-only "investigation toolkit" script that runs the five-minute workflow and writes timestamped output to a file. It saves time and creates consistent notes.
Remember that a compromised host can lie. A rootkit may hide connections from local tools, so compare local output with what your firewall, switch, or flow logs show.
Time-stamp your notes. Commands like ss show a moment in time. Write down when you ran them.
Practice in a lab. Spin up two virtual machines and run each command until the output is familiar before you need it under pressure.

SBI CyRIS Cybersecurity Centre of Excellence: Full Breakdown
Linux pstree Command Cheat Sheet: Spot Suspicious Processes Fast
Linux pgrep Command Cheat Sheet: Find Suspicious Processes Fast
Linux pmap Command Cheat Sheet: 40 Examples for Memory Analysis
Capcom Data Breach: 11.77M Records Exposed – Are You Safe?
VeloCloud Orchestrator Flaw: Read-Only Login Gives Superuser
55 Linux Job Control Commands Every SOC Analyst Should Know
PHP2Shell Patch Guide: Fix CVE-2026-109618 & 109619 Fast

FAQ

Is ifconfig deprecated?

Yes. It belongs to the older net-tools package, which has been superseded by iproute2 (the ip command). Many modern distributions do not install it by default, though you can still add it.

What is the difference between ss and netstat?

Both list sockets. ss is the modern tool, reads directly from the kernel, is generally faster on busy systems, and offers stronger filtering. netstat is the legacy equivalent.

Is it legal to run nmap?

The tool is legal and widely used. Scanning networks or hosts you do not own or have permission to test may violate policy or law depending on where you are. Get written authorization first. This is general information, not legal advice.

Why does ping fail when the server is clearly up?

Many firewalls and hardened hosts block ICMP echo. Test with a TCP-based check instead, such as curl -I against a web service or traceroute -T to a known open port.

When should I use dig instead of nslookup?

Use dig when you need detail, such as choosing a specific resolver, tracing delegation, or scripting with +short. Use nslookup for quick lookups or when you are working across Windows and Linux.

Is it safe to use wget or curl on a suspicious URL?

Fetching headers is generally lower risk than downloading content, but nothing is risk-free. Use an isolated, disposable analysis system, avoid executing anything you download, and hash files before further analysis.

Do these commands replace EDR or a SIEM?

No. They give you quick, direct visibility on one host. EDR and SIEM platforms add history, correlation across systems, and automated response.

Conclusion

You do not need a big budget or a complex platform to start seeing what your Linux systems are doing on the network. A handful of built-in commands, used in a consistent order, will answer most first-response questions: what is this host, what is listening, who is it talking to, and does DNS agree with reality. Learn the commands, build baselines, and pair them with solid logging. When the 3 a.m. alert arrives, you will already know where to look.

Analysis based on SOC monitoring experience and public threat intelligence review.