PeterSee also: Part 2.
First of all, I'd like to wish all FOSSwire readers a very happy new year! Hope it's a good one. Now, the task of keeping a server secure can be a difficult one at times. Getting the compromise and balance between security and convenience right isn't easy to do.
In the first part of this multi-part series, I'm going to show you how to lock down your Linux-based server setup and make it a little bit more secure with a few easy, practical steps that you can take. So without any further ado, let's begin.
In this part, I'm going to focus on steps you can take with your web server software. I'll be focusing specifically on Apache, but many of these steps can be adapted for other software.
1 - Hide your exact version number
By default, Apache throws out the exact version number of itself with every reply to every web request that gets to your server. This isn't necessarily a problem, but it does give the potential attacker lots of information about your setup. If they notice your version is out of date, they might be able to exploit a security hole.
To change what Apache, reports, go to the configuration file httpd.conf and change the line starting with ServerTokens. I recommend setting it to Major, so that only the major version of your server software is reported (e.g. Apache/2):
ServerTokens Major
I know, it's security by obscurity - but every little bit helps. It's more important of course to keep all your software up to date with the latest security fixes as soon as they are available.
2 - Don't enable directory indexes
A directory index is a page that appears when you don't have an index.html or other file set for a directory in your web server's root. The index shows anyone out there on the internet all the files in that directory, and allows them to browse through your web server's contents where you don't have index.html files.
There are some occasions when this behaviour is desirable, for example, a download site, but in most cases it can expose things you don't want exposed, so turn them off.
The default setting for directory indexes is in the Options directive of your main Directory tag in httpd.conf.
What that means is that there will be something starting like this:
<Directory "/var/www/html">
Options Indexes FollowSymLinks
You need to make sure the Options line does not include the word Indexes. Also, if you have manually specified Indexes for any other directories your web server is configured to serve, you will need to check there too.
3 - Make sure backup source files don't get served up
If you work directly on your server with some programs and you are editing things such as PHP scripts or other source code that shouldn't be exposed to your users, you might be unaware that those programs are creating backup files.
Backing up is always a great idea, but it's not so great when those backup files could expose your code, passwords and other information to users, or worse, malicious people.
These files usually end in a ~ symbol. For example, a lot of KDE programs will save index.php~ as a backup when you work on index.php. Aside from cleaning up your backup files at all times, you can also make it so that even if you do leave one of these backup files on the server itself, it will be executed rather than dished out as plain text.
With PHP using mod_php, for example, you can set the AddType directive to parse and execute .php~ files.
AddType application/x-httpd-php .php .phtml .php~ .phtml~
If the worst comes to the worst and you leave a backup file in a live directory, all that will happen if someone browses to it will be - it will execute and run as it should do, not giving your code to everyone in the neighbourhood.
4 - Turn off error reporting
If you use a server-side language, like PHP or Perl or anything else, you've got an added layer of complexity where things can go wrong. If something does go wrong when one of your dynamic scripts runs, it's best not to show the world the details about that error.
It could be that error was caused by a malicious person, and the details from that error message could help them to do more bad stuff on your system. So instead of showing error messages, hide them.
Of course, we don't suppress them completely, or that would mean we wouldn't get notified when something breaks. Instead, have them dumped into your log file, where you can check later and fix things knowing that your users don't know all the details about what went wrong. After all, most of them don't want to know, and some of those that do might not have good intentions.
The steps to do this will vary with what server-side technology you're using. With PHP, you need to go into php.ini and make sure you have the following line set to Off, not On:
display_errors = Off
5 - Remain alert
It's common sense, yes, but it's all too easy to fall into a false sense of security and believe everything is fine. You should be aggressively checking log files for errors and suspicious activity and making sure you know exactly what's going on. If you don't, go through and check that everything is in place and how it should be.
Keep passwords and other authentication mechanisms secure and change them often. Know your server inside and out, so that you know when something is wrong.
