Bullet proof your server #1 - Apache

See 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.

Apache leaking its version number

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.

PHP~ files

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.

php.ini display_errors directive

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.

See you in Part 2!

Avatar for peter Peter Upfold - http://peter.upfold.org.uk/

Peter Upfold is a technology enthusiast from the UK. Peter’s interest in Linux stems back to 2003, when curiosity got the better of him and he began using SUSE 9.0. Now he runs Linux Mint 9 on the desktop, runs a CentOS-based web server from home for his personal website and dabbles in all sorts of technology things across the Windows, Mac and open source worlds.

Home » Articles »

Discussion: Bullet proof your server #1 - Apache

  1. Yoni (guest)

    # Posted on 02 January 2008 at 01:04 AM

    Some of these advice are useful, but suggesting to serve backup .~ files through apache is wrong in so many ways.



  2. Vidar (guest)

    # Posted on 03 January 2008 at 08:17 AM

    I agree. Serving backup files is a horrible idea!

    Instead, add this bit to your httpd.conf to deny them altogether (along with .ht* files, which may include passwords, etc.):

    Order allow,deny
    Deny from all
    


  3. # Posted on 03 January 2008 at 08:34 AM

    [...] proof your server - Part 1, Part 2 - Some simple ways you can boost your [...]



  4. Randall (guest)

    # Posted on 03 January 2008 at 09:28 AM

    @Vidar: I think part of your comment got filtered out, probably mistaken as HTML. I'm not sure how to keep that from happening, so here's a link for anyone interested in denying access to files based on filename matching. Take a look at the Files and FilesMatch directives ( http://httpd.apache.org/docs/2.0/mod/core.html#files ) and use the "Order allow,deny" and "Deny from all" lines as Vidar mentioned.



  5. emil (guest)

    # Posted on 03 January 2008 at 12:37 PM

    why not rather deny all access to files ending with ~?



  6. # Posted on 03 January 2008 at 03:22 PM

    [...] FOSSwire » Bullet proof your server #1 - Apache (tags: security apache sysadmin) [...]



  7. # Posted on 03 January 2008 at 03:24 PM

    [...] Posted by roger Look what I found: FOSSwire Bullet proof your server #1 - Apache FOSSwire Bullet proof your server #2 - SSH Please remember any changes you make you are [...]



  8. # Posted on 03 January 2008 at 06:26 PM

    [...] FOSSwire » Bullet proof your server #1 - Apache (tags: tips sysadmin tutorial linux server) [...]



  9. # Posted on 06 January 2008 at 10:21 AM

    [...] Bulletproof&nbsp;Apache Filed under: Security, Technology &#8212; 0ddn1x @ 2008-01-06 17:21:45 +0000 http://fosswire.com/2008/01/01/bullet-proof-your-server-1-apache/ [...]



  10. # Posted on 07 January 2008 at 10:05 AM

    [...] Bullet proof your server #1 - Apache [...]



  11. Tim (guest)

    # Posted on 09 January 2008 at 03:04 PM

    What about modsecurity?

    www.modsecurity.org

    This should be included! There was a recent SQL exploit for a common app, that I happen to host for someone. We'd have been compromised, but the modsecurity rules I'd setup caught the exploit.



  12. Andrew (guest)

    # Posted on 11 January 2008 at 09:11 PM

    Thank you for pointing out the backup files visibility problem. I just went to my site and noticed that all my source files were exposed! That could have ended badly...



  13. Karel (guest)

    # Posted on 30 January 2008 at 06:30 AM

    Modsecurity sucks - try installing it, it will mess with everything you have on the server (e.g. phpBB).

    PHP functions should be added, you should at least disable the most obvious exec ().



  14. MTecknology (guest)

    # Posted on 14 September 2010 at 07:20 AM

    You could also ditch Apache entirely and enjoy life once you bring common sense into it.



Home » Articles » Bullet proof your server #1 - Apache