Server crash, possibly due to hacking attempt
This morning, I couldn't reach my web server. Dead. Nothing.
I contacted my server company, who very quickly diagnosed that the server had blue-screened; they rebooted it and all is now well. Looking at my web logs, I think it was down for about an hour -- not disastrous, but definitely inconvenient and not A Good Thing. (Note to self: set up a monitoring service so I know when it's down!)
So I started looking at the system logs to see if I could find what caused it to crash. And there was a big clue, right in front of me.
Yesterday, I installed SSH on the server (see my previous post on deploying via Git). And, 40 minutes later, I started getting login attempts (from Germany, Poland, Thailand, etc.) -- all trying to login to SSH as "root". Over the course of 15 hours, I logged over 4200 failed SSH login attempts.
The attempts stopped several hours before the server crashed, but I can only assume the events are related. I think I've go it more locked down now...
What I've learned... #
Of course, these tips apply to most areas of security, but they do bear repeating!
1. Don't use obvious login names #
You log in with a username and password. If you have a default username, such as "root", the hacker already knows one half of the the combination. (I didn't have "root" as a username, so all their attempts failed at the first hurdle.)
2. Use non-trivial passwords #
If you have a simple password, it's that much easier to brute-force a login. If you don't already, get yourself a password manager (I use 1Password) to generate and store unique, complex passwords. If you have a password made up of 16 random characters, it's going to take a while to crack it.
Update: better still, as recommended in the comments, use key files to authenticate -- and turn off pasword authentication completely. Not only is this more secure, it means you can log in without having to remember a password...
3. Don't run it on the standard port #
Hackers will try to access SSH on its standard port (22). Make it that much more obscure by using a custom port -- for instance 2587 (you can use anything that doesn't clash with other services). This is especially important if you are unable to implement tip 4 below.
4. Restrict access to your SSH port #
Just because you've followed steps 1, 2 and 3, your server is still open to attacks. Hammering away at an SSH login can still affect the running and stability of your server. So, if it's practical, use your firewall to allow access to the SSH port only to specified IP addresses. If they can't get a response on a port, hackers will soon move on to somewhere they can.
I hope these tips are useful -- and please let me know what I've missed or got wrong (I'm by no means a security expert!).