Securing Apache
Set up apache2 for https
This article describes how to secure your webpage running on apache2 with https. You create demo-certificates yourself for this. Find out your distribution, then proceed accordingly:
SUSE Linux
This article assumes you know about SSL, https and certificates.
- set up your Certification authority and create dummy-certificates /usr/bin/gensslcert
- get your SSL Configuration from the given template cd /etc/apache2/vhosts.d cp vhost-ssl.template vhost-ssl.conf
- change your SSL Configuration have apache2 start per default with SSL. To do this, edit /etc/sysconfig/apache2: replace APACHE_SERVER_FLAGS="" with APACHE_SERVER_FLAGS="SSL"
- restart apache2 /etc/init.d/apache2 restart
- make sure you have content to show echo "this is a test" >> /srv/www/htdocs/index.html
- test your configuration wget --no-check-certificate --no-proxy https://localhost
Ubuntu Linux
Follow https://help.ubuntu.com/8.04/serverguide/C/httpd.html. If you use name-based virtual hosts, your apache configuration will look like this afterwards:
<VirtualHost *:443> ServerName foo.org DocumentRoot /var/www/foo SSLEngine on SSLOptions +StrictRequire SSLCertificateFile /etc/ssl/certs/server.crt SSLCertificateKeyFile /etc/ssl/private/server.key </VirtualHost>
Only allow trusted users
To get your apache2 protect a webpage with a password:
- have an unprotected webpage that shows up in your browser (I assume it is stored in /home/httpd/prot)
- create a .htpasswd file with htpasswd2
- create a file named .htaccess in /home/httpd/prot:
AuthType Basic AuthName "Restricted Files" AuthUserFile /home/httpd/prot/.htpasswd Require valid-user
- in your httpd.conf, replace all AllowOverride none with AllowOverride all.
Disable clients from writing and deleting via HTTP methods
It is possible for an internet user to upload and delete files on your web server using the http methods put and delete. This chapter explains how to disable it.
Benign HTTP
Web browsers typically ask for web pages by sending a specially formed request. At the beginning of each request is the method, such as GET. When an HTML form is used, CGI scripts are typically launched by sending GET or POST methods. Sometimes you may see a HEAD request in your logs; this is something asking about a page, but not requesting the actual content of the page. All of these are safe types of requests (of course, in the case of HTML forms, you are responsible for seeing that your CGI script behaves well!)
Dangerous HTTP
Other methods exist under HTTP 1.1 that can cause you harm under certain circumstances. The two that are by far the most dangerous are the PUT and DELETE methods.
PUT allows users to upload files to your server. Since files may in some cases contain scripting, this is dangerous in the most profound sense -- if you don't have your permissions set exactly right, this can lead to complete takeover of your server. Even if you do have your permissions set so nothing outside the server HTML documents directory can be accessed, people can still take up disk space and so on by uploading documents you don't want there.
DELETE allows the obvious -- the user can delete files in the HTML documents directory.
Disabling PUT and DELETE
Apache has a pair of directives, <Limit METHODTYPELIST> and </Limit>, that allow you to disable various methods based on directives that are defined between them. They must be used in the scope of a <Directory PATH> and </Directory> directive pair. So for instance, you might have something like the following in a virtual server definition or your main definition:
<Directory /usr/apache/www/myserver.com/htdocs>
...bunch of useful stuff
</Directory>
If you change it to this...
<Directory /usr/apache/www/myserver.com/htdocs>
...bunch of useful stuff
<Limit PUT DELETE>
Require user pumba6snif8gleep4
</Limit>
</Directory>
...then unless someone can guess the silly username (you're responsible for coming up with a ridiculous, unguessable username -- do NOT use my example usernames!) then no one will be able to upload files or delete the files that are there.
Editor's note: This is technically security through obscurity -- it is better to use an actual authentication mechanism.
Inheritance and Virtual Server Protection
Inheritance can work for you, if you've been clever about how you built your server directories. For instance, let's say you have three domains up and running using virtual server directives. They're located in the filesystem in these locations:
/usr/apache/www/boogieserver.com (htdocs... logs... cgi-bin...) /usr/apache/www/hooohaserver.com (htdocs... logs... cgi-bin...) /usr/apache/www/bleeposerver.com (htdocs... logs... cgi-bin...)
You can protect all of these at once by putting this outside all virtual server directive scopes...
<Directory /usr/apache/www>
...bunch of useful stuff
<Limit PUT DELETE>
Require user sweeble2plope3guzza9
</Limit>
</Directory>
...all three server directories, and all the subdirectories under them, are protected from any HTTP PUT or DELETE request.
Limit public information from Apache
Somewhere in the global section of your httpd.conf file, there is probably a directive that looks like this:
Servertokens [keyword]
Possible keywords include Full, OS and Prod, as well as a few others (check the Apache documentation if you're really curious, but what you really need to know is right here.) Many times, the keyword used is Full, which is a security issue. Here's why.
Full causes Apache to send out what operating system you're running, the version of Apache you're running, and even what modules you have loaded. Basically, you're telling a hacker everything they need to select the appropriate tool(s) to cause you to have a very bad day indeed. Here's an example of what Full produces:
HTTP/1.1 200 OK Date: Mon, 3 Jan 2005 12:13:14 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_ssl/2.8.12 OpenSSL/0.9.6b PHP/4.1.2 Last-Modified: Sun, 2 Jan 2005 11:12:13 GMT Accept-Ranges: bytes Content-Length: 12204 Connection: close Content-Type: text/html
Look at all that way-too-detailed information. Mmmmm-m. Just what a hacker wants!
What you want to do (in my opinion as a paranoid person) is make sure your configuration is set this way...
Servertokens Prod
...now all your server tells them is that it is running Apache. Not even which version of Apache. Not a word about modules or your OS. It's kind of fun to see lame attack attempts in your logs obviously aimed at Windows systems... when you're not even running Windows. Now your HTTP responses look like this instead...
HTTP/1.1 200 OK Date: Mon, 3 Jan 2005 12:13:14 GMT Server: Apache Last-Modified: Sun, 2 Jan 2005 11:12:13 GMT Accept-Ranges: bytes Content-Length: 12204 Connection: close Content-Type: text/html
...since Apache runs on numerous platforms and comes in many versions, having the server emit "Apache" isn't telling anyone much of anything, however, it still exists (on Apache httpd 2.x) some other ways to completely hide this information, firstly by editing source code, secondly by installing third-party module such as mod_security (on http://www.modsecurity.org/ ) or mod_sesehe (on http://modules.apache.org/search?id=962 ).