How to clean TCP Established state sockets?

I’m experiencing an issue with my rented VDS server, which is running Ubuntu 22.04. To secure my server, I have enabled ufw (Uncomplicated Firewall) and allowed access only to two TCP ports: 2222 for the SSH server and 8080 for a proxy server.

As part of monitoring incoming connections, I have installed the tcptrack application. Initially, everything seemed to be working fine. However, I have noticed a considerable number of irrelevant TCP connection requests originating from IP addresses unknown to me. While most of these requests are properly rejected and closed within a reasonable timeframe, some connections remain in an ESTABLISHED state indefinitely. Unfortunately, this list of persistent connections continues to grow unless I restart my server.

To investigate, I have checked the SSH server logs located at /var/log/auth.log, and I have not found any instances of successful authentication, apart from my own (only publickey authentication is supported).

I am concerned about the connections that remain in the ESTABLISHED state and persistently appear on the tcptrack list. I expected these connections to be terminated after a certain period of inactivity. Why do they remain in this state indefinitely, and what impact does the growing list have on my server’s functionality? Lastly, is there a way to configure Linux or sshd to automatically terminate established connections if there is no activity?

tcptrack output

Asked By: Mehmet Fide

||

I’ve skimmed the tcptrack source code, and came to the conclusion that tcptrack does indeed do it’s own connection state tracking. What you see is not the same as the state the TCP state machine¹ inside the Linux kernel.

In other words, we don’t know whether this display is a bug inside the Linux kernel, which literally powers billions of internet-connected devices, or whether it’s just tcptrack misinterpreting packets and coming to the conclusion that a connection that’s long been in a non-ESTABLISHED state is ESTABLISHED.

I’d assume this is tcptrack being wrong, unless profiling your actual kernel network stack tells you you’re losing compute cycles to connection tracking. You can test that – stop tcptrack and start it anew. Does the same number of ESTABLISHED, but idle for hours, connections still appear?


¹ If you want to even call it that – things are complicated.

Answered By: Marcus Müller
Categories: Answers Tags: , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.