When you run lsof on a Linux or macOS system, the tool reports every open file descriptor, including network sockets that map to open ports. Understanding lsof open ports helps you see which processes are listening, which established connections exist, and what might be causing conflicts or unexpected exposure.
Each row in the table below summarizes common lsof output columns, what they reveal about a socket, and typical indicators you will see when inspecting open ports in real time.
| Column | Meaning for open ports | Example value | What to look for |
|---|---|---|---|
| COMMAND | Name of the process that opened the socket | nginx, sshd, node | Identify unexpected services listening on sensitive ports |
| PID | Numeric process ID linked to the socket | 1234 | Correlate with process management tools like ps or systemctl |
| USER | Account that owns the process using the port | root, www-data | Check for ports bound by unintended users |
| FD | File descriptor referencing the network file (socket) | 5u | u = IPv4/IPv6 stream or dgram sockets; helps filter listening sockets |
| TYPE DEVICE | Protocol and device info, usually IPv4 or IPv6 | IPv4 0t0 | Confirm whether the port is IPv4 or IPv6 bound |
| DEVICE SIZE | Kernel queue and buffer metrics for the socket | 0t0 0 | Large queues may indicate pending connections |
| NODE | Kernel pointer for the protocol endpoint | tDD3A2BC | Useful for advanced debugging or correlating netstat output |
| NAME | Path for Unix domain sockets or port/service name | :http, /var/run/redis.sock | Quickly see which well-known ports or paths are in use |
How lsof Lists Open Network Ports
lsof builds its listing by querying the kernel for file descriptors across all mounted file systems and active network stacks. For each open socket, it resolves the local and remote addresses along with port numbers when available. This approach makes lsof a broad but precise reporter of open ports without relying on specialized networking-only metadata.
Common Flags for Port Discovery
Use -i to focus lsof on Internet and IPv4/IPv6 sockets, and combine it with -P to prevent port-to-service name resolution for faster output. Adding -n avoids DNS lookups, which keeps results deterministic and faster when you are troubleshooting high-volume connections. These flags filter the open ports view so you only see what matters for a given investigation.
Interpreting LISTEN and ESTABLISHED States
Listening sockets appear with a port number and an address such as 0.0.0.0:80 or [::]:443, indicating that the process is accepting new connections. Established connections show both local and remote endpoints, which helps you understand traffic flows and which remote IPs and ports are currently active. Consistent mapping between PID, port, and command is essential for reliable service diagnostics.
Detecting Hidden or Misconfigured Services
On a production host, unexpected open ports can reveal misconfigured daemons, accidental exposure of admin interfaces, or even persistence mechanisms left by attackers. By cross-referencing lsof results with service inventories, you can quickly identify services that should not be bound to public interfaces. For example, a database process listening on 0.0.0.0 instead of localhost is a risk that lsof with open ports makes immediately visible.
Correlating lsof with Process Metadata
Once you spot an unfamiliar open port, use the PID shown by lsof to pull richer context about the process, including its command line, environment, and user identity. Tools like ps, cat /proc/PID/cmdline, or systemctl status for managed units help determine whether the service is legitimate, patched, and correctly restricted. This correlation step is central to secure hardening and incident response workflows.
Baseline and Change Detection
Regularly capturing a snapshot of lsof open ports and storing it alongside configuration baselines allows you to spot deviations without relying solely on firewall logs. When a new port appears in the lsof output or an expected service disappears, you can investigate root causes such as configuration drift, failed deployments, or unauthorized changes. Automated scripts can diff successive lsof runs and highlight added or removed lines for rapid triage.
Security and Access Control Around Open Ports
Knowing which user owns each open port is essential for enforcing least privilege, because a service running as root on an unnecessary port increases the impact of a compromise. lsof reveals the USER column for every entry, allowing you to verify that daemons drop privileges correctly and that no rogue process is listening as a high-privileged account. Binding management interfaces to 127.0.0.1 instead of 0.0.0.0 is a strong control that lsof can confirm for sensitive ports such as databases and configuration APIs.
Network Segmentation and Firewall Alignment
Firewalls and host-based access controls should reflect the actual set of open ports reported by lsof to avoid gaps caused by forgotten services. When lsof shows a service listening on an unintended interface, update segmentation rules and host ACLs to close the mismatch. For containerized workloads, combine lsof inside the namespace with orchestrator network policies to ensure advertised ports match intended exposure.
Operational Best Practices for lsof Open Ports
- Run scheduled lsof scans with
-iand-Pto maintain an inventory of open ports across hosts - Correlate lsof results with service configuration files to ensure advertised ports match actual bindings
- Restrict binding to localhost for administrative ports and verify with lsof that unintended interfaces are not exposed
- Automate diffing of lsof output over time to detect new or disappeared ports promptly
- Combine lsof with process inspection (ps, /proc) to validate that the correct user, binary, and capabilities are used for each open port
FAQ
Reader questions
Why do I see more ports with lsof than with ss or netstat alone?
lsof reports file descriptors across files, pipes, and sockets, so it may list additional Unix domain sockets or special entries that ss or netstat hide by default. For pure port numbers, combine lsof with -i and -P to align its output with network-focused tools and reduce noise.
Can lsof show the program binary path for each open port?
Yes, by merging lsof output with /proc/PID/exe on Linux or lsof -p PID on macOS you can resolve the exact binary and libraries backing each socket. This helps verify that the process bound to a port matches the expected service release and has not been replaced by a malicious substitute.
How do I filter lsof to only show listening TCP ports?
Use lsof -iTCP -sTCP:LISTEN to restrict results to TCP sockets in the listening state. Add -P to avoid DNS resolution and -n to skip name lookups, which makes it easier to scan large numbers of open ports without delays caused by reverse DNS timeouts.
What does it mean when STATE shows *:port in lsof?
An asterisk in the node column typically indicates that the socket is bound to all available interfaces, equivalent to 0.0.0.0 for IPv4 or :: for IPv6. This usually means the service is accepting connections from any address, which is convenient but can expose the port to unexpected networks if not controlled by firewall rules.