0

this is the situation:

  • vps with debian 8x32 virgin (new template of the provider's repository);
  • exotic "user" and strong "password" ;
  • 30 seconds later: command (apt-get update);
  • 30 seconds later: command (netstat);

  • netstat show :

    • 1 x tcp established sshd connection (my remote ssh client);
    • 1 x tcp sshd connection ESTABLISHED (Chinese ip) (small heart attack);
  • 30 seconds later: command (cat /var/log.auth/);

  • log contains:
  • only my remote connection "Accepted";
  • several attempts to connect invalid (ssh brute force);

  • 30 seconds later:

  • installed fail2ban for ssh and 4 more services;
  • configured permanent ban (value -1);
  • populated hosts.deny with some ip that are attacking;

  • 2 days later: * log revision var / log / auth * | grep [Accepted, invalid, refused, etc];

Everything indicates that no attack has been successful; The ips hosts.deny are ejected perfectly; Fail2ban works perfectly; The attacks by only ip have diminished; Now the logs only show attacks by only ip and not 200 attacks by ip; All the "Accepted" connections of the logs are correct (only I with my remote client have been successful in connecting, apparently);

I know the first thing is to deactivate root, passwords, etc. and use public key and other things, but my question refers to the "ESTABLISHED" status of an SSH connection shown by netstat, that is:

  • Is it possible that a result of netstat ESTABLISHED has been assumed but has not been produced?

  • Does a result of ESTABLISHED nestat definitely and definitely indicate that the machine has been compromised?

  • Is it possible that the attacker is playing with modified SYN or SYN-ACK to simulate a fake STABLISHED connection?

Extra: I have seen ESTABLISHED connections 4 times just after being banned permanently by fail2ban and after 2 seconds re-firing netstat and seeing how nonexion vanished like a ninja;

Thanks in advance.

  • Doesn't ESTABLISHED relate to the TCP state ? A Chinese IP connecting to your server first needs to establish a TCP connection to it before trying to authenticate. ESTABLISHED doesn't mean that the authentication was successful. – Elzo Nov 19 '17 at 15:24
1

An "ESTABLISHED" connection seen in the output of a netstat command reffers only to the TCP connection. If the port was accepting connections from any remote IP, anybody could stablish a TCP session, where the SSH daemon would ask for login and password, but it does not mean a SSH session is stablished.

You could easily try it yourself: login to your machine via SSH and then, from your local PC use telnet, netcat, socat or any other similar tool open a TCP session to your remote machine on port 22. Then in your logged in session, get the output from the netstat: you will see 2 connections from your local PC as stablished, the one with a SSH session and the pure TCP connection from the telnet.

Search into /var/log/auth.log for SSH sessions. Try looking for "session opened", which should only correspond to your connections.

Also, I would recommend doing a few extra configuration steps on your VPS: first, if your local PC has a fixed IP address and you only plan to connect to the VPS from that PC, restrict via iptables to allow connections only from that IP (NOTE: doing it wrong could lock yourself out of your VPS, caution needed). If it is not fixed or you need to connect from other sources, that option is out of the list. Second: to reduce bruteforce (fail2ban is nice, but it relies on logged events to work, so you will always have some attempts from new sources), I would change the SSH port from 22 to something else.

  • Thank you very much @nuttyx, I have already verified that when starting the connection request before entering username and password, a [tcp user: ssh STABLISHED] is generated; Now I will follow your suggestions on improving safety. Thanks again. – vancloud Nov 19 '17 at 17:40

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.