Life After Being Hacked
I was hacked! That terrible thing finally happened to me. And, it was all my fault. Come learn from my mistake.
Being hacked sucks. Not only do you have to deal with the shame of being hacked but, it's a lot of work to recover from it well. This month my web server was hacked and someone used about 2 TB (2,000 GB) of outgoing bandwidth to do something shady. My best guess is that some site had a DDOS attack courtesy of my shamed server.
Here is an opportunity for my loss to be your gain. As part of my effort to make it hard for something like this to happen again I've been implementing security solutions to my server and habits. The kinds of things you would hope would be implemented by default by a hosting company but rarely are.
Turn Off FTP And Use SFTP Instead
FTP is old and ugly. It should have gone away a long time ago. FTP sends usernames and passwords as clear text. That means someone can sniff your web connection and get your connection info. No decryption or special techniques needed to read them. They are just plain text.
SFTP is entirely different. It uses SSH (with encryption) to transfer the files. Not only do you get encryption but with SFTP you can compress what's being transferred for faster transfers. A double win.
Crazy Passwords and Keys
We were hacked by a brute force attack that guessed a simple and common password. I've seen this type of attack happen numerous times. The simplest way around this is to have a password with no dictionary words, upper and lowercase letters, numbers, and symbols in them. It's a pain to remember these so I recommending using something like 1password to save them.
If you need help creating the terribly long and hard to crack passwords there's the GRC Password generator.
Because I can't remember these terribly long passwords I've setup SSH keys to access the server. That means when I connect, via ssh, I don't have to enter a password. My computer uses a key instead.
Firewall Rules
Back when I used to manage my own servers I had a firewall rule that seemed like a no brainer. If someone failed to enter the password correctly 3 times in a row they were blocked from connecting to the server for 5 minutes. This wouldn't stop someone whose legitimate or anyone really interested in trying to crack the system. But, it would deter (or at least make it difficult) for your standard hacker or bot.
There's a simple explanation and tutorial over at http://kevin.vanzonneveld.net/techblog/article/block_brute_force_attacks... if you'd like to learn more.
These aren't an all inclusive measure or a guarantee to stop a hacker. But, these things will sure make it harder for them.
Great information, Matt. I have a couple other recommendations as well:
1. Use a non-standard ssh port. SSH servers listen on port 22 by default - as such, the brute-force scripts mentioned above always try to connect to your ssh server on that port. If you're managing your own server, it's trivial to move sshd to a non-standard port - you can pick anything really between 10000 and 65535. I used to get many, many brute force attempts on my server when its sshd was listening on port 22. Since changing it to a non-standard port number, though, I've been hit with *zero* attacks.
2. Only allow connections to your ssh port from a couple IP addresses. This may not be feasible for some, but if your home (or work) internet connection has a static IP address, you can create iptables rules that will only allow you to ssh into your server from a few specific IP addresses.
One final clarification - in your "Firewall Rules" section, the solution you linked to (since they're just firewall rules operating within kernel space) actually can't determine whether or not a user has entered a valid password. Rather, it's just rate-limiting connections to SSH from a given IP address. That said, I still think it's a great solution, just wanted to clarify the "valid password" part. If you *do* require a solution that can really tell if a user enters a valid password or not, look into denyhosts or fail2ban. Both of these products will parse your ssh auth log and can tell when there's been a failed authentication attempt.
fail2ban is a great call. I forgot all about that. The other suggestions are good as well.
Thank you for sharing your experience. The way many webhosts handle FTP is a little scary. I have a client that is hosted on siteground.com so I checked into using SFTP. Their knowledgebase article says "SFTP is NOT available on the shared hosting servers because of security reasons."
I really wonder what the security reason is for sftp not being enabled. Did anyone call the support line and probe this? I would just to learn why I'm recommending to the client to switch hosts.
The old issue with SFTP was that openssh did not allow you to give out sftp access without also giving sftp access, they were joined at the hip; the same was also true of many commercial sftp/ssh servers. This has since changed in recent releases (I forget which release added that feature), so now the only excuse is that the webhost doesn't want to upgrade their servers and/or deal with the extra hassle of something they may not fully understand.
Sorry, I should have said "openssh did not allow you to give out sftp access without also giving ssh access". Doh! X-)