3

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?

  • It means that the tcp connection is established. – Ipor Sircer Nov 16 '16 at 4:37
  • does that say anything about whether they are actually authenticated? – deltaskelta Nov 16 '16 at 4:48
  • 1
    look at /var/log/auth.log – Ipor Sircer Nov 16 '16 at 4:55
4

"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.

  • cool, I already had no root password and used ssh with rsa keys. I changed the ssh port to something random and unusual as well. What do you mean y disable root login? – deltaskelta Nov 16 '16 at 6:01
  • @deltaskelta Add "PermitRootLogin no" to /etc/ssh/sshd_config. See the askubuntu question I linked for details and more suggestions. – Gordon Davisson Nov 16 '16 at 7:09
  • For this particular case, some emphasis should be placed on some of the lower-down answers for that other question, which deal with shutting-out such IP addresses with firewalls and source IP access rules in the SSH service. – JdeBP Nov 16 '16 at 8:59
0

ESTABLISHED means the tcp socket is in established state i.e. the connection is currently active.

The tcp socket tuple is:

(my.machine.ip.add:ssh, 116.31.116.48:43270)

where the local endpoint is my.machine.ip.add:ssh, and remote endpoint being 116.31.116.48:43270.

So definitely the ssh client from 116.31.116.48 is connected to the ssh service of your computer.

  • ok, that is what I expected, but does that mean that it is authenticated and that they are actually ssh'd in my machine. or just that the client has connected to the service (maybe trying to authenticate, or maybe connected) – deltaskelta Nov 16 '16 at 4:48
  • @deltaskelta unless there is a bug in sshd this means that they have authenticated as the socket becomes ESTABLISHED (for a longer time) after the user is authenticated. – heemayl Nov 16 '16 at 4:59
  • so....It is possible that it is ESTABLISHED for a short time even if they have not authenticated, right? – deltaskelta Nov 16 '16 at 5:11
  • ESTABLISHED just means that the server is talking to the client. It has nothing to do with authentication. An ssh server can wait for input for a very long time unless configured otherwise. – Ken Sharp Nov 16 '16 at 5:12
  • @KenSharp Yes, thats what i meant too, no? An ssh server can wait for input for a very long time unless configured otherwise seems a bit off putting as unless there is an active request the socket can't be in ESTABLISHED state, and the failure drops the connection quickly so the the connection would not be in ESTABLISHED state for a longer time unless the user is authenticated. – heemayl Nov 16 '16 at 5:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.