Audit which network ports are used by a Linux process

Auditing Processes and Network Services

Most network related services have to open up a network socket, so they can start listening for incoming network requests. It is common to find the TCP or UDP being used as the main communication protocol. In this article, we start auditing what kind of network communications are relevant to a particular Linux process, or a set of processes.

Find out what process is listening to a port

Only one process can actively listen to a TCP or UDP port. We usually only discover this when another process is already running on a specific port, while we try to start another service:

[emerg] 9400#0: bind() to 0.0.0.0:80 failed (98: Address already in use)

or something like:

nc: Address already in use

The easiest way to determine what processes are running and what port they listen to, is using the netstat utility. It is available to most systems by default.

# netstat -nlp

The result might be looking something like this:

Screenshot of netstat showing processes and network ports

Output of netstat with listening ports

If you don’t have the netstat utility available, it might be replaced with a newer toolkit. In that case, you usually have the ss utility available (iproute2 package).

To use the ss tool to show the network ports and related processes:

# ss -lpntu

This will show a similar output. It shows all the listening ports, limited to UDP/TCP only, not translated to hostnames to speed up the results.

Last but not least, there is the LSOF utility. Not always installed by default, but still a very common utility.

# lsof -Pni | egrep “(UDP|LISTEN)”

This includes all UDP ports and for TCP only the ports which are actually in “LISTEN” state:

Screenshot of LSOF used UDP and TCP ports

LSOF displaying UDP ports and TCP ports in LISTEN state

Detecting network ports for new processes

Sometimes you might be running a new process and not aware of any network ports being opened. This might occur when it just quickly happens, or due a port listening conflict. Also when running services in containers, it might be harder to know what ports needs to be opened, to get it fully functioning.

In these cases the strace utility is of great help. It can track a running or new process and alert for any events of your interest. To track the open request of a network port, we can monitor the related system call (syscall), which is ‘bind’.

# strace -f -e trace=bind nc -l 80

With this command we will see quickly after execution the following line:

bind(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr(“0.0.0.0”)}, 16) = 0

This means it tried to open a network socket with port 80. Unfortunately it does not show if it opens a TCP or UDP port. If we broaden the system calls a little bit, this information becomes available:

# strace -f -e trace=network nc -lu 80
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr(“0.0.0.0”)}, 16) = 0

That’s it for today. Linux systems are very versatile, yet sometimes need the right tool to dig into the details you want to know. With tools like lsof, netstat, ss, strace, we can find exactly that network information we are looking for.

Lynis Enterprise

Lynis Enterprise screenshot to help with system hardening

This blog post is part of our Linux security series and the mission to get Linux and Unix-based systems more secure.

Does system hardening take a lot of time, or do you have any compliance in your company? Have a look at Lynis Enterprise.

Or start today with the open source security scanner Lynis (GitHub)


Leave a Reply

Your email address will not be published. Required fields are marked *