Sunday, 21 July 2013

HOW TO HACK-PROOF YOUR WEBSITE, BASICS FOR NON-EXPERTS

Why Protect your Server?
SoR was hacked early 2009. Cleaning out the hack, figuring out why it happened, and hardening the SoR server to keep it from happening again wasted a full week of labor. It exposed visitors of my site to spam redirects and a trojan virus. It also potentially opened me up to full site deletion, password theft, database corruption, being blocked by search engines for malware distribution, and a host of more bad-ness I don’t want to clue hackers into.


I can never be 100% sure, but evidence leads to my server control panel that had a known security hole. From there, the hacker gained ftp access to my site, and then ran a whole list of bad scripts. Was it my fault? Well, there was a whole host of things I *should* have done since day one to harden my server that most likely would have blocked the hacker. This article is to share what I learned the hard way.
Now I know what you are thinking, because I thought it too: “I’m a noob at web security and don’t want to spend years studying web security to defend myself. My website is about [insert non-IT interest here], not IT related!” This website is about making robotics – I’d rather spend years studying robots, not defending myself against fat loser hackers who still live in their parents basement and can’t get a real job (rant rant rant).
So this page is how to defend yourself against 95% of all hacks on your site, and to help you protect yourself from your noobness.
Don’t Give Hackers a Target
A hacker can’t install evil CGI scripts on your server if your server doesn’t have CGI scripts enabled. Make sense? Turn off *everything* on your server that you don’t use, such as but not limited to:

php
ruby on rails
cgi
webmail (just use redirects to your gmail, etc.)
perl
asp
etc.
The other major advantage to turning everything off is that you don’t need to constantly make sure that each are fully patched and updated against the most recent exploits. Simply turn off and forget.
Keep Software Up-To-Date
This is fairly obvious – organizations [should] release updates to their software to patch against the latest exploits. These exploits are often made public around the same time. If a hacker sees you don’t have the latest version installed, he knows exactly how to exploit your server!

Now it’s not reasonable to check for updates *every day*, so there are other methods. Some software has ‘auto-update’ or ‘auto check for update’ features. Turn on ‘auto check for updates’, but be wary of ‘auto-update’ as you don’t want it to break anything without your knowledge. Also, sign up for any software mailing lists that notify users of newer versions . . . and pray they don’t spam you with promotions in the mean time.
Hide software version numbers from public facing pages if at all possible.
There are also automated methods to update your server, such as Yum andUp2Date. These programs make it easy to check for new versions of software and to upgrade them without much hassle.
And DO NOT trust your webhost to do this for you!
Assume That You Will Be Hacked
Shakespeare taught us that overconfidence is our downfall. Always assume that one day your server will somehow be hacked, and act as so.

Make sure you backup everything, and do it often. Automate your backups, because it’s annoying to do it manually in my opinion. Verify that your backups actually work. And don’t delete your old backups, keep them all and date them appropriately. I once discovered a backup of mine was corrupted after corrupting the most recent version . . . and I only had that one backup. That was a sucky day for me . . . Assume that maybe one day your house will have a fire, flood, burglary, tornado, or some other ‘wrath of god,’ and any backups stored in your house will be destroyed/lost along with it. Keep a copy of your backups with a trusted friend/relative or in a safety deposit box at a bank.
Also assume that people are trying to hack you, but haven’t succeeded yet. They’ll occasionally test your system for any flaws that come up. You’ll probably see these attempts in your server error log. They’ll be pretty obvious, like attempts from a single IP address trying to access many non-existent files on your server, such as yoursite.com/admin. Don’t ignore them, they may one day ‘pwn joo’. Learn how to use a .htaccess file and IP block those basement dwelling losers cold.
You probably already know this, but don’t use simple passwords, or any password that can be found in a dictionary (heard of the dictionary attack, yet?). And don’t store those passwords on your laptop/PC as it can be physically stolen.
Use a firewall. You [should] know exactly what programs are running on your server, and your firewall should only allow those programs access to the net. A backdoor would probably use a non-approved port number, so a firewall would quickly block it. Be careful when you first turn your firewall on, making sure you allowed valid programs access *first*. If you don’t you’ll end up blocking your own ftp, shell access, control panel, etc. If you don’t know what you are doing, set your firewall up to ‘allow all’. It won’t block anything, but it’ll at least log rogue programs.
Turn off anonymous ftp so a hacker doesn’t have access to your code for potential exploit perusal.
Assume That You Have Already Been Hacked
I went a month before I realized I was hacked. Users started reporting that their virus software would go crazy when they visited my site. Going through my FTP I quickly found files that obviously shouldn’t have been there, but I just didn’t think to stay alert for this. If I paid more attention I would have found them out much sooner.

As soon as you realize you were hacked, try to find out when. Look at the file dates and go through your error logs and ftp access logs. If you have a low traffic site, even go through your normal access logs. It’s always good to at least skim through your error logs once a month to see any failed hack attempts (the successful ones won’t get recorded there). Skim through your ftp access log occasionally for IP address that aren’t yours. You can even block ftp access to any IP that isn’t yours.
Finding that you were hacked, don’t immediately delete all the hack files in a wave of frantic paranoia – save them first on your PC locally for later analysis. Save log files and everything else.
Try to determine if it was a non-directed automated attack (favorite method for spammers), or an intense directed attack specifically at you. The latter is scarier, because the hack will be much better hidden and customized to fool specifically you. If it’s directed at you, they’ll definitely try again. Those that use automated methods wouldn’t think you are worth their time to hack again if their automated attack fails.
The most recommended course of action after being hacked is to simply erase your server and start over again, as there is no real way of knowing if any hidden backdoors were installed. But don’t do this yet – figure out how they got in first. If you don’t, you’ll just reinstall the same security holes and get hacked again. Browsing Google for exploits on the software you used will definitely help you find that hole(s).

0 comments:

Post a Comment