When you run services on a Linux host, understanding which ports are in use helps you troubleshoot connectivity issues, avoid conflicts, and secure your system. This overview focuses on practical ways to identify active ports and the processes listening on them.
Below is a quick reference that maps common port states to the tools and fields you care about most when diagnosing Linux networking behavior.
| Port State | Meaning | Command to Inspect | Key Fields to Check |
|---|---|---|---|
| Listening | Service is accepting connections | ss -tlnp / netstat -tlnp | Local Address, PID/Program name |
| Established | Active TCP connection in use | ss -tnp / netstat -tnp | Recv-Q, Send-Q, Process |
| Closed | Port is not open or socket is shut down | lsof -i :PORT | Command, user, FD, type |
| Filtered | No response, possibly blocked by firewall | nmap -sT -p PORT localhost | State (filtered), tool used |
Finding Listening Ports with ss and netstat
The ss utility provides fast, detailed socket information and is the modern replacement for netstat on most Linux distributions. Use options like -t for TCP, -u for UDP, -l for listening sockets, -n to skip name resolution, and -p to show the owning process.
For quick checks, commands such as ss -tlnp reveal which ports your system is actively listening on, along with the program name and PID. If ss is unavailable, netstat -tlnp delivers similar output, though it may be slower on systems with many sockets.
Parsing the output requires attention to the Local Address column, which shows IP and port pairs, and the PID/Program name column, which helps you map services to systemd units or init scripts for further investigation.
Connecting and Established Ports with ss
Established connections appear in ss output when two endpoints are exchanging data. The -t option filters for TCP, while -n avoids delays from DNS lookups, and -p shows the process using the connection for rapid troubleshooting.
Use ss -tnp to see active outbound or inbound connections, focusing on lines labeled ESTAB. Cross-reference the local and foreign addresses with service documentation to verify whether the traffic matches expected behavior.
If you spot unexpected established connections on high ports, investigate the associated PID immediately, as this can indicate covert channels, misconfigured clients, or malicious activity.
UDP Ports and Service Dependencies
Unlike TCP, UDP is connectionless, so there is no established state. To see which services are using UDP ports, combine ss or netstat with the -u flag and scan for LISTEN or partial states depending on the tool.
Critical services such as DNS, DHCP, and SNMP rely on UDP, so unintentional blocking or address mismatches can cause hard-to-diagnose failures. Check that bind addresses and firewall rules align with the intended network topology.
Always correlate the PID shown in the output with systemctl status or process logs to confirm that the service is running under the correct user and chroot context, reducing privilege-related issues.
Firewall Rules and Port Visibility
Firewalls can make a port appear closed or filtered even when a service is listening locally. Tools like nmap, iptables, and nftables must be examined in combination to understand the full picture of port visibility.
Run nmap scans against localhost and external interfaces to compare results, and review nft or iptables rulesets for drops, rejects, or masquerade directives that affect specific port ranges.
For containerized environments, remember that port mappings in Docker or Kubernetes can expose host ports differently, so check both host and overlay networking tables to avoid confusion.
Securing and Managing Ports on Linux
Continuous monitoring, principle of least privilege, and clear service documentation form the foundation of safe port management on Linux.
- Regularly scan localhost with ss or netstat to audit which ports are in use and by which processes
- Restrict bind addresses to the minimum required interfaces and use firewall rules to limit external exposure
- Correlate PID output with systemctl, process arguments, and file ownership to verify service legitimacy
- Document expected ports and protocols for each application to speed up incident response
- Update system and service configurations to patch vulnerabilities and remove deprecated protocols
FAQ
Reader questions
How do I list only the listening TCP ports with the owning program on Linux?
Use ss -tlnp or netstat -tlnp to display TCP listening sockets along with the PID and program name, which lets you map each port to the responsible service.
What does it mean when a port shows as established in ss output?
An established state indicates an active TCP connection with confirmed two-way traffic, and combining ss -tnp with the PID helps you trace the client and server processes.
Why is my service listening on IPv6 only even though I configured it for IPv4? Some daemons bind to [::] by default, which accepts both IPv4 and IPv6 on Linux, but dual-stack behavior or explicit IPv6 settings in config files may override IPv4 listeners. Can a port appear in use by multiple processes, and how should I handle it?
Yes, when multiple instances or SO_REUSEPORT sockets exist, tools may show partial data; review the PIDs, cross-check with systemd, and consolidate or reconfigure services as needed.