From LQWiki

Avoiding DOS (Denial Of Service) Attacks

With a fresh install of Apache, you should install mod_dosevasive[1]. To install mod_dosevasive with Apache 2.0, download the latest stable version of mod_dosevasive, currently version 1.8.
Untar it:

# tar -zxf mod_dosevasive.1.8.tar.gz

and cd to the directory:

# cd mod_dosevasive

Run the command:

# path_to_apache_install_root/bin/apxs -i -a -c mod_dosevasive20.c

then restart Apache (typically something like: # /etc/init.d/apache restart).

Configure mod_dosevasive by adding to httpd.conf:

<IfModule mod_dosevasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        2
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10
    DOSEmailNotify      admin@asdf.com
    DOSSystemCommand    "su - someuser -c '/sbin/... %s ...'"
</IfModule>

• DOSHashTableSize is the size of table of URL and IP combined.
• DOSPageCount is the number of the same page requested by the same IP during an interval that will cause the IP to be added to the block list.
• DOSSiteCount is the number of all pages requested by the same IP during the interval to be added to the block list.
• DOSPageInterval is the interval that the hash table for IP's and URL's is erased (in seconds).
• DOSSiteInterval is the interval that the hash table for IP's is erased.
• DOSBlockingPeriod is the time the IP is block (in seconds).
• You can also include DOSEmailNotify to send an email everytime an IP is blocked.
• DOSSystemCommand will execute a command when an IP is blocked. The %s is the IP that is blocked. The command could be configured to block the IP at the router.
• A whitelist can also be included by using the configuration DOSWhiteList 127.0.0.1

Set up apache2 for https

This article describes how you can secure your webpage running on apache2 with https. You create demo-certificates yourself for this. This is for SUSE Linux, for Fedora, I recommend http://www.linux-sxs.org/internet_serving/apache2.html

This article assumes you know about SSL, https and certificates.

1. set up your Certification authority and create dummy-certificates

/usr/bin/gensslcert

2. get your SSL Configuration from the given template

cd /etc/apache2/vhosts.d
cp vhost-ssl.template vhost-ssl.conf

3. 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"

4. restart apache2

/etc/init.d/apache2 restart

5. make sure you have content to show

echo "this is a test" >> /srv/www/htdocs/index.html

6. test your configuration

wget --no-check-certificate --no-proxy https://localhost

Only allow trusted users

To get your apache2 protect a webpage with a password:

1. have an unprotected webpage that shows up in your browser (I assume it is stored in /home/httpd/prot)
2. create a .htpasswd file with htpasswd2
3. create a file named .htaccess in /home/httpd/prot:

AuthType Basic
AuthName "Restricted Files"
AuthUserFile /home/httpd/prot/.htpasswd
Require valid-user

1. in your httpd.conf, replace all AllowOverride none with AllowOverride all.

Disable clients from writing and deleting Via HTTP header commands

Caveat: This security tip will help you if you don't want to allow people to upload files or delete files on your websites. Generally, unless you are performing remote website management via HTTP protocols, you probably don't want to allow these operations. But... if you do want to allow the world to perform file deletes and file uploads on your web sites, you might as well stop reading now. Personally, I think you're out of your mind, but... :)

Benign HTTP

Web browsers typically ask for web pages by sending header commands, such as the GET header. When an HTML form is used, CGI scripts are be launched by sending GET or POST headers. 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 headers 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 headers.

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. I don't think I have to explain why this isn't a great idea.

Disabling PUT and DELETE

Apache has a pair of directives, <Limit HEADERTYPELIST> and </Limit>, that allow you to disable various headers 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.

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.

Apache talks too much. Shut it up!

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