How do you check which ports are open (`netstat`)?

Fernando

How do you utilize the netstat utility to systematically audit and identify active, listening ports across enterprise-grade network interfaces during real-time troubleshooting? Furthermore, why is combining these specific command-line network statistics flags with operating system-level filtering the absolute best approach to detect unauthorized open ports, isolate rogue local processes, and verify strict firewall rule enforcement?

Isabella

Inspecting Network Listeners and Active Connections via Netstat

During incident triage or routine security audits, systems engineers must verify which network ports are open and listening for incoming traffic. Operating systems maintain an internal network socket table that logs all active connections and protocol bindings. The standard command-line utility netstat (network statistics) serves as a fundamental diagnostic tool across both Linux and Windows environments to inspect these sockets directly.

Core Command Syntax for SRE Triage

To check for open ports, engineers need to filter out transient outbound connections and isolate sockets configured to accept incoming traffic. The most efficient way to achieve this is by executing netstat with a targeted combination of flags.

In Linux environments, the standard diagnostic syntax is:

netstat -tulnp

In Windows environments (PowerShell or CMD), the equivalent diagnostic command is:

netstat -ano | findstr LISTENING

Deconstructing the Diagnostic Flags

Each flag appended to the command alters how the utility parses and displays the kernel's networking table:

-t (TCP) / -u (UDP): These flags restrict the output to specific transport layer protocols. Specifying both ensures the engineer captures standard web traffic (TCP) alongside low-latency streaming or DNS services (UDP).
-l (Listening): This flag is critical for identifying open ports. It instructs the utility to display only the sockets currently in a LISTENING state, filtering out active outbound connections like your current SSH session or web browser tabs.
-n (Numeric): By default, the utility attempts to resolve IP addresses to hostnames and port numbers to service names (e.g., converting 80 to http). Forcing numeric output bypasses these reverse DNS lookups, accelerating command execution and preventing diagnostic delays if local DNS resolution is degraded.
-p (Program): This flag maps each open port to its specific process identifier (PID) and executable name. Identifying what is listening is essential for verifying whether a port was opened by a legitimate application (like Nginx) or an unauthorized process.

Interpreting Network Socket Output

When the command executes, it returns structured columns outlining the real-time state of the host's network interfaces:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name     
tcp        0      0 0.0.0.0:80              0.0.0.0:* LISTENING   1234/nginx: master   
tcp6       0      0 :::443                  :::* LISTENING   5678/node

Local Address Bindings: The IP address preceding the colon dictating how the service listens. A binding of 0.0.0.0:80 (IPv4) or :::443 (IPv6) indicates the service is listening on all available network interfaces, making it accessible from both the local loopback and the external network. Conversely, a binding restricted to 127.0.0.1:3306 means the port (in this case, MySQL) is only accessible from within the local host, shielding it from external network scans.
State Column: For TCP ports, this should explicitly read LISTENING. Because UDP is a stateless protocol, it does not feature a handshake-driven state mechanism, meaning UDP ports will often show a blank state or appear as 0.0.0.0:* while still actively receiving packets.
Process Mapping: The final column provides the exact PID. If an engineer discovers an unexpected open port, they can immediately pass this PID to utilities like ps aux | grep <PID> or kill -9 <PID> to investigate or terminate the underlying process instantly.