15

I'm freaking out a little bit at the moment. I am SSHing into a remote server that I have recently commissioned. I'm doing this as root. I have installed fail2ban and had a massive amount of banned IPs in the log.

The last time I logged in i noticed my terminal being really laggy then my internet connection went down. When I bought it back up after about 5 min i logged back into the server and did a 'who' and realised there were two root users logged in. I would have thought that if my connection terminated the process from the last session would have been stopped on the server?

The connection ended with a 'Write failed: Broken pipe' when i first got disconnected. I killed the bash session with the other root. I don't know much about ssh security however could sessions be hijacked? is there a way of checking this? I need to continue logging in via ssh what precautions should I take? If I was somehow going through a proxy to reach my server (like a man in the middle attack) could they hijack my ssh session?

MarMan29
  • 343
  • 3
  • 7

1 Answers1

42

The root logins are probably dangling shell sessions that once were you. Your server is also probably getting dDOS'd with all the attempted logins hammering it.

Lock down SSH. Don't allow root login, and those requests that are trying to brute force this machine will fail immediately (taking far fewer resources). Log in as a normal user and elevate permissions via sudo, a practice you should be doing anyways. Also restrict SSH login to a list of client IPs so that the unsavory machines can't even try to log in.

Use SSH keys instead of passwords for user login. They're easier to deal with, and can be password protected themselves in case you accidentally give a private key out to the wrong place (giving you time to replace them and invalidate the old one). As @EEAA mentioned in the comments, you must also disable password based authentication if you wish to restrict clients to using only keys instead of both passwords and keys.

If the mongol clans continue to batter your city wall, maybe move SSH to a different high port (under 1024, as @AustinBurke pointed out - so as to use a privileged port) instead of 22. This will reduce traffic on that port if this is a problem for you (and most bots aren't very graceful, so they'll only attempt on 22). It won't stop things from trying port 22 or even scanning your machine to see what port is listening on SSH, and in most cases is a needless inconvenience. But it may help.

Others might be able to provide more tips, but these are pretty generic security measures for a publicly facing SSH server.

Spooler
  • 7,046
  • 18
  • 29
  • 23
    **Using** keys isn't enough. One must *disable* password authentication as well. – EEAA Apr 03 '17 at 00:42
  • ok thanks guys i'm going to setup keys and disable passwd access now – MarMan29 Apr 03 '17 at 00:49
  • EEAA thanks for the comment. I'm just wondering disabling password authentication would be to prevent brute force attacks, is that right? I have installed fail2ban. I believe this should mitigate brute force attacks. I'd like to know your thoughts though. Thanks – MarMan29 Apr 03 '17 at 02:22
  • 1
    Disabling password based authentication and using something like fail2ban are both methods of mitigating brute force attacks of different kinds. It's a lot easier to invalidate a single user's public key when a private one has been compromised than it is to change a root password and then have to send that password out to everybody (not that we should be using root with ssh in an ideal situation anyways). – Spooler Apr 03 '17 at 03:04
  • 2
    _"Your server is also probably getting dDOS'd with all the attempted logins hammering it."_ - There is no reason to conclude that with the provided information. In particular: dangling server-side sessions indicate network problems such as packet loss, not CPU-bound or connection-count problems as would be caused by too many SSH login attempts. – marcelm Apr 03 '17 at 08:52
  • 4
    @marcelm Does "_massive amount of banned IPs in the log_" not hint that this may be happening? – TripeHound Apr 03 '17 at 09:00
  • 4
    @tripehound No it doesn't. It says nothing about the relative resources consumed. – marcelm Apr 03 '17 at 11:42
  • 3
    It _is_ a hint to that effect though, @marcelm. – Lightness Races in Orbit Apr 03 '17 at 11:50
  • 3
    @MarMan29 Bots performing brute force attacks do not seem to be very thoughtfully designed. They tend to keep connecting to the server for every password they want to try, even if the server has completely disabled support for password authentication. But it is still helpful to disable password authentication. In my experience it does reduce the load on the server when you disable password authentication. It is much less work for the server to tell the client password authentication is not permitted than it is for the server to validate a password and tell the client it is incorrect. – kasperd Apr 03 '17 at 12:55
  • Thanks everyone for their comments. I set "PasswordAuthentication no" although failed attempts slowed down I'm still getting a fair few unwanted requests. I may consider changing the port. What I have noticed is that some of the bots seem to have 'learned' the number of requests they can try before fail2ban steps in. They backoff and retry later as not to be banned. I was never really worried that a brute force attack would work. Even if i left bots hammer away relentlessly. However something that is still on my mind that hasn't been fully answered yet is **can ssh sessions be hijacked?** – MarMan29 Apr 03 '17 at 15:03
  • 5
    While that is feasible in this universe, ssh is pretty damn secure. You can of course grab that traffic in-flight and store it in its encrypted state, but a Diffie–Hellman key exchange is used to establish an encrypted channel. Cracking this ain't even possible if you have both the private and public ssh key that was used for authentication, since the stream key was never communicated during the session. By the time someone has cracked that stream, we'll all be dead. – Spooler Apr 03 '17 at 16:13
  • 3
    For an alternate SSH port, I would suggest using a port _under_ 1024, as anything above it is technically considered an unprivileged port. In a scenario in which your server is compromised, an attacker could wait for SSH to restart and bind itself to the port before sshd can, in order to obtain root or other credentials. – Austin Burk Apr 03 '17 at 21:11