When your website earns enough money and when its traffic cannot be handled by shared webhosting, it is usually the right time to buy/rent a dedicated server. This can be, however, very unpredictable and this article is going to show you some of the most important changes which you will face naturally.



The first thing you must consider is security. Since shared hostings are usually secured very well, on a dedicated server you're responsible for all actions yourself. Security can be divided into a couple of groups, and these can be called: Filesystem security, Database security, Access security. Filesystem must be secured from attacks by several handling procedures. The fist is very simple; Never use attributes of 777 or 666 for directories or files. Such attributes would mean that these files or directories can be modified by anyone from outside. Instead, use 755 for directories and 644 for files. If your scripts need access to files and directories, modify their owner. This can be done easily by typing this command when you're logged to your server via SSH:

chown apache file_name

This command will change the owner of file/directory to apache. You will not be able to modify such files from your ordinary account any more, however you will be able to do so from your root account. It's possible to play with users groups in order to grant some ordinary users access like apache, but if you're not experienced enough, leave it for now.

The second security risk is enabled directory listing. Enabled directory listing means that a user types http://yourdomain.tld/images into the browser and he/she gets all files or directories which are present in that folder. Of course, it can be something else than ?images? and it may be eventually dangerous to access such directories. Dangerous for you, not for a hacker. For this purpose, it is necessary to modify your .htaccess file. It is localed in the root folder of your website. Adding this into your .htaccess will ensure all directories won't return directory listing:

Options -Indexes

In additon, define pages which are returned in case of some error. These errors can be 404, 500 or any which may occur. Add these lines into the .htaccess file:

ErrorDocument 401 /some_url

ErrorDocument 403 /some_url

ErrorDocument 404 /some_url

ErrorDocument 500 /some_url

?some_url? should be a document available on your website. For example, ?ErrorDocument 401 /errors/error.html?.

If you're using PHP scripts, make sure that error_reporting is configured properly. Basically, the Apache server can be configured to ignore errors and not to save them in the error_log files. However, the error_reporting() function should be called at the beginning of each script. It's purpose is essential; It will prevent your server from being clogged up with unnecessary error_log data. Add this line to your scripts:

error_reporting(E_ALL ^ E_NOTICE);

After this improvement, you will notice only a few lines in the error_log files. Something like this:

[Sun Aug 24 07:42:25 2008] [error] [client 66.249.70.122] File does not exist: /home/server/public_html/google

[Sun Aug 24 07:55:25 2008] [error] [client 68.196.186.232] File does not exist: /home/server/public_html/entry.point, referer: some_url

[Sun Aug 24 09:06:09 2008] [error] [client 71.126.173.185] File does not exist: /home/server/public_html/_vti_bin

[Sun Aug 24 09:06:10 2008] [error] [client 71.126.173.185] File does not exist: /home/server/public_html/MSOffice

Of course, paths can be different and also files which don't exist will differ. These requests are usually made by bots, mainly bots which try to find weak places on your server. Such random attempts may lead to hacking attempts. Or these attacks can be focused to send email spam; This activity can be recognized by seeing such lines in your error_log:

[Mon Aug 18 07:11:11 2008] [error] [client 71.181.242.135] script not found or unable to stat: /var/www/cgi-bin/formmail.pl

Naturally, this attempt was not successful. If you're aware of what's behind these queries, you can still block IP addresses from accessing your server. There are various methods how to achieve it, from .htaccess modification to configuring your external (hardware) firewall.

The database security means that you should not use root access for your websites. Many webmasters do this mistake and it means nothing but allowing dangerous actions to be done in MySQL. For example, imagine that someone broke your website's security and is able to run some MySQL commands on your server through some form available on your website. Picture a situation that your website uses root access to MySQL; All commands can be executed. Now picture a different situation when you allow only SELECT and eventually INSERT, DELETE, MODIFY within one database. OK, it's still possible to delete or modify records, or even delete them, but only within 1 database. If you configured a script to do daily backups of databases, then it's possible to restore all tables within a few seconds.

In addition, you can use allow a user to perform only the SELECT command. Other sensitive scripts may be using another user who can perform the INSERT, DELETE and MODIFY, but these scripts may be secured much better than ordinary not tested yet.

Another way how to secure MySQL from being attacked is to avoid usage of ?or die (mysql_error ());? because it does nothing else but showing potentially dangerous MySQL syntax to hackers and all visitors. Instead, use some general message and send yourself an email automatically from the script including all details about line and error which occurred; ?or warn_webmaster(__line__,__file__);? for instance, where the warn_webmaster function would email you with the __line__ and __file__ variables along with the mysql_error() message. The function would end like die(); which would immediately terminate the script.

The third part of securing your server from dangerous activities is based on secure passwords. Never use same passwords for two server accounts, never use password which you used somewhere else. Never use short passwords, never use passwords without mixing uppercase, lowercase and numbers together. Never login from internet cafe or other public computers/networks.