Monitoring network connections with ss
I did not plan this succession of events. Just days ago I wrote an article about gathering statistics on your network to make smart guesses on where would communication issues happen, and now I found this nice tool called ss.
If mtr allowed you to see ping faults across a whole route, ss allows you to see connections and listening ports on your computer. If you just run ss with no parameters you will see all established socket connections to and from your computer. They are many, especially considering Unix stream sockets. Unix streams represent internal communication within your Linux system. They are not network related so we won’t talk about them this time. To get a more network focused view, we need to use two important parameters: -t to see only TCP sockets and -u for UDP sockets. We can use -ut to see both:
We can see in the above screenshot the following columns: netid which shows the socket type: UDP or TCP, state showing if the socket is listening, if it’s connected (ESTAB) or if the connection is just closing (CLOSE-WAIT), then we have two columns: recv-q and send-q meaning the number of received and sent packets, then local address:port and peer address:port showing the local and remote IP and port for the connection. Last column is process and it’s filled only if you specify the -p parameter:
The processes that are not filled are running outside of the current user’s permissions. We can see those too if we use sudo:
Unfortunately, ss will only offer a snapshot of your network activity. It’s not an interactive tool and you have to keep running it to see ongoing changes in your network. But if you notice network slowdowns or if you think your home network is compromised, this tool will show you all the TCP and UDP activity that is currently happening.
If we look at the output above, we see many established connections. This is normal because I have Firefox open with some tabs in it, one of them being Medium itself which does a lot of traffic by saving my article. But let’s see the clean output with Firefox closed:
Ok, it’s a bit clearer now. We see that there are a few services going on here on my desktop: IMAP handled by Evolution, NFS handled by Gnome’s GVFS of which we talked a bit in a previous article and DHCP handled by Network Manager. I also have a time synchronization service running on my desktop but that one probably opens connections only when updating the time.
But let’s close Evolution:
And let’s eject our network shares from Gnome Files:
See? Take a look at that ss output. That’s how a clean system and a clean network should look like. Don’t mind the three lingering HTTPS results: they are just waiting for the TCP connection termination acknowledgement. And what about the first bootps line? That’s the DHCP connection to my router, that’s fine and it will always be there.
Ok so no ongoing connections that I am not aware of. But I don’t trust it! I may not have ongoing established connection but what if some processes are listening for connections? Let’s see the listening sockets by adding the -l parameter to the ss command:
We have some UDP sockets in the UNCONN state and a few TCP sockets in the LISTEN state. UDP is a connectionless protocol so it cannot wait for connections. It just waits for messages. It’s open, but it has no concept of a connection that’s why it appears in the list but it’s not in the LISTEN state.
So what to we learn? We have some avahi sockets which are discovering the network services, we have the DNS resolve socket that handles IP name resolution, we finally see the NTP time synchronization process chronyd and we see the printing process cupsd. Everything is legit and clean and I know about every running process because I explicitly configured it when installing my Fedora workstation. Let’s check the Raspberry PI server too:
If we look, there’s only the DHCP connection and my ssh connection. This is perfect. And listening sockets?
Well the output is certainly heavier then the workstation, but if we look at each line we simply see the running services that the Raspberry PI is providing to the network: email client, contacts and calendar client, NFS shares, media services, SSH, it’s own time synchronization and network discovery service. All good.
How do we use ss?
If we look at the screenshots, you can see the usefulness of ss. Of course it’s only a snapshot, ss is not interactive and you won’t see connections as they are happening. I am still searching for a good tool that would do that. Something like top but for network connections.
But on the other hand, if you get into the habit of running ss from time to time to see active connections, run through them and understand them, and running ss again to see listening sockets and keep records of them, at some point you will get acquainted with the services running on your system and you will be able to detect abnormalities. This has to be a habit to work.
Of course, there may be situations when it’s better to monitor the logs to catch connections and network transfers and there’s a better tool for that: fail2ban. We’ll talk about it in a future article. That’s a great tool to catch connections and trap them, log them or ban the IP altogether. But that tool is much more involved and sometimes you just want a simple checkup: that’s the perfect job for ss.
As an anecdote, I used to run Windows on my main system a long time ago and there was a tool I kept using called tcpview. It was an interactive tool and it would show you connections as they are happening and I liked to sit and watch and imagine malicious behaviors and how would they look in the app. But let me tell you something: off the bat the application with no browser running and no email client, it would show many connections that back then I thought normal. They were normal, they were tons of network and time services. But when I went to Linux and ran netstat (the older brother of ss), I saw nothing. Ok? No connections whatsoever. It was such a revealing moment, I immediately loved Linux. Why would there be open sockets when I configured none?
Ok, that’s all for today. I will make an article about fail2ban soon because it’s a nice tool to know and master and it’s a life saver especially when opening ports to the Internet. Thanks for reading, don’t hesitate to use the comments for anything, even anecdotes like mine and see you in the next article!
