In a case of what I’d call security through obscurity, the Linux Poison blog has a posting up on how to hide the PHP information in your web server. The idea is that the less a potential hacker knows about a system, the better. Here, I’m going to take it one step further, and show you the impact of some other options, and what data gets hidden.
The first step is to see what information is displayed without making changes. From my development server, I pull up Firebug, and load a page, and see what the response headers look like…
As you can see from the image of Firebug there is a wealth of information being presented to any would-be hacker. To start, they now know my development server is running Debian Lenny. It also has mod_php, mod_perl, mod_ssl, and mod_python (plus specific version information) installed, and that the instance of apache running is using OpenSSL 0.9.8g. A quick search of any security tracking sites could pull up all kinds of useful information based around that alone. This just made the hackers life easier, because now s/he doesn’t have to brute force1 attack the server.
Lets see what happens when we modify the recommendations by the Linux Poison blog. In Debian the file needed to be modified is in /etc/php5/apache/php.ini, other platforms may store the file elsewhere. Don’t forget to tell your web server to reload after making the changes.
This looks a little better. It no longer displays any PHP related information, but the rest of the data is still there. We need to do something more about that. In my case, that means moving onto the apache configuration. The two important directives in this case are ServerTokens and ServerSignature. These directives are both in /etc/apache2/apache2.conf in Debian2, so may be located in a different file depending on platform. ServerTokens is the most important one. A quick look at the apache documentation shows what the output looks like depending on the options selected…
ServerTokens Prod[uctOnly] Server sends (e.g.): Server: Apache ServerTokens Major Server sends (e.g.): Server: Apache/2 ServerTokens Minor Server sends (e.g.): Server: Apache/2.0 ServerTokens Min[imal] Server sends (e.g.): Server: Apache/2.0.41 ServerTokens OS Server sends (e.g.): Server: Apache/2.0.41 (Unix) ServerTokens Full (or not specified) Server sends (e.g.): Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2
From this list, it’s clear to see that prod is the winner on showing the least amount of information. So a quick change of that setting, and a restart of apache again, lets see what happens to the output now…
As we can see from the Firebug output, it now lists only that I’m running apache, a substantial improvement.
What about the ServerSignature option I mentioned? The apache documentation has this to say about this configuration entry…
The ServerSignature directive allows the configuration of a trailing footer line under server-generated documents (error messages, mod_proxy ftp directory listings, mod_info output, …). The reason why you would want to enable such a footer line is that in a chain of proxies, the user often has no possibility to tell which of the chained servers actually produced a returned error message.
It mentions server-generated documents, so this includes any error pages, but it also includes the pages Apache generates when you don’t have a directory index, and it just lists the file contents. The option, and the ServerTokens option actually play together, so for a test, I’ve reverted the ServerTokens option back to Full so you can see what happens when ServerSignature is set to On.
As you can see from the screenshot, it contains the same information that is contained in the headers, a little easier for somebody to see. So flipping the option ServerTokens back to Prod and all you display is that the server is running apache. Flipping the ServerSignature option to Off does exactly that, there is no longer a signature at the bottom of the pages generated. The other option is Email. This is the same as On but adds a mailto: link where the server name is too. This may be handy if you want to allow people to track down the administrator of the server.
As I mentioned at the start of the post, this to me, falls into the ‘security through obscurity’ category3, and should be one step towards making your server a little more secure, but definitely not the last. The less the person knows about a system, the more they’ll have to work to find out ways in.