Ssh – does netstat established mean that someone is ssh’d into the machine

linuxlogsnetstatssh

I ran the command netstat -lat

and I got this output…

...
tcp        0      0 my.machine.ip.add:ssh       116.31.116.48:43270     ESTABLISHED
tcp        0      0 my.machine.ip.add:ssh       my.home.ip.add:55732    ESTABLISHED
...

I looked up the IP and it is definitely not one which should have access to my machine. so does ESTABLISHED mean that they are trying to connect? (I do see a lot of failed attempts from this address in my auth.log) or does it mean they are connected?

Best Answer

"ESTABLISHED" just means that the connection is established at the TCP layer; it doesn't tell you much of anything about whether they've authenticated. The general sequence is:

  1. TCP connection from client (/attacker) to server gets established
  2. Client attempts to authenticate
  3. If the client succeeded in authenticating, the client does ... something over the connection. The TCP connection remains "ESTABLISHED" until they disconnect.
  4. If the client fails to authenticate (usually after 3 tries), the server drops the connection.

If someone's running a password-guessing attack on you, and you happen to check while they're trying passwords, you'll see an "ESTABLISHED" connection. If they don't delay between attempts (i.e. as soon as one connection attempt fails, reconnect and try again), then you'll pretty much always see an "ESTABLISHED" connection.

On the other hand, if you see the same connection stay up for a while (i.e. the same remote IP and port numbers, rather than continuously changing port numbers), then either someone's gotten in, or they're dawdling for an awfully long time between password guesses. In that case, you should worry.

But if you really want to know what's going on, check the logs! (As Ipor Sircer said in a comment.) Unless an attacker has wiped them, they'll be much more informative than just looking at TCP connections.

Also, since you're under attack (which is automatic, since you have ssh exposed on the internet), make sure your ssh service is properly locked down! Disable root login, limit the users that can log in, make sure to use hard-to-guess passwords, and (if possible) disable passwords in favor of public key authentication.

Related Question