List open ports and listening services

 If you're looking for a way to discover which ports are standing wide open on network machines, read about a powerful cross-platform solution that will do the trick.

Image: iStock

Editor's note on June 4, 2015: Chad Perrin's April 2008 article about tools for listing active services and open ports is still one of our most popular articles, so we asked Jack Wallen to write a 2015 update on the topic. Chad's original article appears directly after Jack's update.

One of the biggest headaches for network administrators is open ports on devices. Unless you manually installed the operating system on every device on your network, ensuring to close down all unessential ports, you run the risk of attack.

If you’re troubleshooting a service that you know is running normally, the next step is to ensure it’s listening on the correct network port.

The netstat command shows the services listening to ports on a Linux server and the details of any connections currently made to them. The connection details to consider during basic network daemon troubleshooting are the addresses that the daemon is listening on (including the port number), the daemon’s process identifier (PID), and the program name.

You need to run netstat on the server that is running the service. Netstat is not affected by your firewall configuration.

Note: You can also use the lsof and ss commands to check ports. Many of the command flags contained in this article are the same when you run the lsof and ss commands. However, the output returned when you use these commands might not resemble the output of the netstat tool. For more information about both commands, see the lsof and ss command manuals.

Also notice that, unlike the output of netstat on Linux, we don’t get the PIDs of the daemons themselves. You might also notice that no UDP ports were listed for DNS. This is because UDP sockets do not have a LISTEN state in the same sense that TCP sockets do. In order to display UDP sockets, you must add udp4 to the argument for egrep, thus making it 'Proto|LISTEN|udp4‘. However, due to the way UDP works, not all UDP sockets will necessarily be associated with a daemon process.

Under FreeBSD, there is another command that will give us just what we want. The sockstat command performs only a small subset of what netstat can do, and is limited to just listing information on both Unix domain sockets and Inet sockets.

To get a list of listening ports and their owning processes with sockstat, run this command: