Thrudigital

Today, I noticed an attempt to hack one of my websites. The attack wasn’t successful, but however it revealed a few minor places to improve. In order to help you secure your website from hackers, I am writing this step-by-step guide to protecting your site. Let’s start from beginning. I’m also attaching a few snapshots to help you understand better what happened to me.

The easiest way to hack a website is by sending a large volume of random requests. To maximise the potential success, invalid URLs are used as well. Invalid URLs are URLs that include characters that try to break MySQL queries (and eventually querys through other database systems). In general, this technique is useless if your website doesn’t send/receive parameters via URLs. However, for any website which is really dynamic, parameters are necessary to let a visitor communicate with the server. For example, imagine a simple search query: if there is a form that allows one to type search terms, then even this one form can be potentially a gateway to hacking a website. In PHP there is a simple way to avoid such vulnerabilities. All MySQL queries must be protected, thus using -

$variable = addslashes(htmlspecialchars($_REQUEST['something']));

is more than necessary. It is a must! What do these functions do to help you? The addslashes function transforms all variables’ values that contain quotes into friendly format, as you probably know if you use this to excecute MySQL queries.

mysql_query($query,$link);

Then the $query variable must contain only two ordinary quotes. Others must be in a friendly MySQL format (“….\”…“ for instance). The htmlspecialchars function helps you to prevent PHP scripts and MySQL data from attempting to insert vulnerable code into data fields or break the scripts and reveal information used by website’s core. In such a way it is possible to find all files, usually to modify them, delete them, or add vulnerable PHP/HTML code to the website. So in the first instance, always protect scripts from queries that can be sent by anyone at any time.

The next very important protection is login area protection. There are bots that try various combinations of logins and passwords. If any user uses a weak password, it is very possible that their account will break under such an attack! This is why you must use two ways of prevention (preferably 3):

1) Use strong passwords;
2) If a login attempt has been unsuccessful (say) 5 times within (say) 1 minute or less, block the account for another (say) 30 minutes and block the originating IP addresses;
3) For important accounts, use an IP-based + password protection (a login attempt must come from predefined IP addresses)

The login process can be additionally secured with CAPTCHA protection (the same applies to the registration areas!)

OK, you’re almost done. Now it is needed to track attempts to hack your website. Every attempt must be recorded for further analysis or to take further action against hackers. I recommend these information to be stored in a log: timestamp, IP address, etc. This data is necessary to stop the attack in the shortest possible space of time after it started. How can we do this? On your server you should have a folder where the script saves log files as text files. For example, only those logs which ended as a failure (disallowed characters within URLs; say that something.php?u=1 can contain only u=1 or u=2, so u cannot be anything else, and if it is, then it is considered as an attempt to hack) should be stored. The script should save these logs immediately after such a script is called. After saving, a function that compares logs should be called. The result of our imaginary function can be “Allow”, or “Disallow”. If the disallow option is the result, the document is redirected to an error page where you explain all reasons of doing this redirect. You must not use MySQL for storing logs because if your server returns a MySQL error “too many connections“, then the scripts won’t be able to thwart any potential attack! Also, any filesystem is faster than a database system.

As I indicated above, there could be a problem with too many connections. This happens when too many requests are sent to a server. The only working strategy how to thwart these attacks is denying requests from same IP addresses. A human visitor WILL not send more than 1 request per second (consider the period of 10 seconds to be the average, measure requests per 10 seconds; a human user will not send more than 10 queries to your server during these 10 seconds!). Actually, a human visitor will hardly make 5 requests during 10 seconds. I recommend you to block everyone who sends more than 10 requests during 10 seconds. Except Google. Google can send more than 2-3 requests per second, thus resolving the hostname is necessary too.

Apart from hacking attempts, sending too many requests doesn’t have to reveal potential vulnerabilities. Do not forget to turn off the error reporting in PHP. Below is a very handy function that don’t show the MySQL error. Instead of using

mysql_query("...",$link)
or die("..." . mysql_error());

use

mysql_query("...",$link)
or some_die_function(__FILE__,__LINE__);

Where the some_die_function sends you an email and terminates the script showing some error message to the visitor. This way you assure that no details are shown to the visitors and hackers!

This system may sound too complicated, but it really helps. At least make sure that no error is shown to the user. Even if your website is down, you still control everything. Checking your logs can help you find out what happened. The function that reports errors tells you exactly what happened. Next time you can be better prepared. Look at the snapshot below: The attack lasted only 5 minutes (the snapshot is just a small section of the report), and then subsided. If it happens again, everything will be secure.

The IP ending with .166 was one of the attackers.

By the way: always use strong passwords. And use Linux!

Sponsored links