random neuron misfires

Tuesday, October 26th, 2010 at 11:01 am | 9,379 views | trackback url
Tags: Apache, hacking, linux, servers

I’ve been running an Apache server for over a decade, serving up hundreds of websites over the years, and one thing remains constant: abusers attacking Apache, looking for a way in, or a way to DDoS attack your server so others can’t get to the content you’re providing.

We don’t call these people ‘hackers‘, ‘crackers’ nor do we even call them ‘criminals’. They’re just idiots, and they’re easily stopped.

The rest of this post will show quite a few ways to slow or stop these attackers from taking down your Apache web server or abusing it in any way.

If it is a simple SYN style attack, use the following from your standard Linux machine:

sudo echo 1 > /proc/sys/net/ipv4/tcp_syncookies

If the IP address of the external attacking host doesn’t change and you just want to block it, use:

sudo iptables -A INPUT -s {remote_attacker_ipaddr) -p tcp -m tcp --dport 80 -j DROP

If you want to block them on ALL ports (not just 80, as above), use:

sudo iptables -A INPUT -s {remote_attacker_ipaddr) -j DROP

If the attack is more like a SYN attack with HTTP logic, use mod_evasive for apache2. The mod_evasive Apache module will count, “learn” and blocks the specific kind of attack you want to prevent (flooding, DDoS, etc.).

Here are some useful links describing how to use and set it up in your Apache instance:

1. Protecting Apache against DOS attack with mod_evasive
2. Install mod_evasive for Apache to Prevent DDOS Attacks
3. How to Install mod_evasive?
4. Prevent DDoS Attack With mod_evasive in Apache 2

Another solution is to block them using .htaccess (not recommended due to performance concerns) or directly in your VirtualHost block in your Apache instance. Note, this solution below will block the host at the request layer, but not block the TCP connection itself:

<Limit GET HEAD PUT POST DELETE OPTIONS PROPFIND PROPPATCH MKCOL
COPY MOVE LOCK UNLOCK PATCH>
        SetHandler server-status
        order allow,deny
        allow from all
        deny from {remote_attacker_ipaddr}
</Limit>

If you know the remote attacker is using an IP in a known range of IPs (such as someone from within a known ISP’s subnet, in a given xxx.yyy.zzz), you can use pattern matching with Apache’s mod_rewrite module:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} ^xxx\.yyy\.zzz\.(6[4-9]|7[0-9]|8[0-9]|9[0-9])$ [OR]
RewriteCond %{REMOTE_ADDR} ^xxx\.yyy\.zzz\.1([0-1][0-9]|2[0-8])$        
RewriteRule .* – [F]

Or, you could use Apache’s mod_security module. ModSecurity is a web application firewall that can work either embedded or as a reverse proxy. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.

Here’s an example:

SecFilterSelective "REMOTE_ADDR" "^{remote_attacker_ipaddr}$"

There are plenty of references on the web, but I’d suggest starting with the “Introduction to mod-security” as a good starting point.

There are also some default Apache options you can tune to help alleviate any strain on your server instance:

Decrease the Keep-Alive timeout window, and/or disable KeepAlive altogether:
{Ref: KeepAlive, KeepAliveTimeout}

KeepAliveTimeout 10
KeepAlive Off

Limit the amount of time a remote user can stay connected to the server with an existing connection:
{Ref: MaxKeepAliveRequests}

MaxKeepAliveRequests 500

Limit the amount of data a remote user can send in the HTTP request/XML Request body:
{Ref: LimitRequestBody, LimitXMLRequestBody}

LimitRequestBody 102400
LimitXMLRequestBody 102400

Limit the amount of fields and/or parameters a remote user can send in the HTTP request body:
{Ref: LimitRequestFields}

LimitRequestFields 50

Limit the maximum size of each field or parameter a remote user can send in the HTTP request body:
{Ref: LimitRequestFieldSize}

LimitRequestFieldSize 1024

Limit the maximum length allowed for a URI:
{Ref: LimitRequestLine}

LimitRequestLine 2048

If you read your Apache logs and watch the trending in those logs, you’ll quickly see where any abuses may be happening, and adapt to those attacks appropriately.

The above list of techniques (certainly not exhaustive, by any means) should help you secure your Apache server and keep it up and running with minimal downtime.

Last Modified: Sunday, March 6th, 2016 @ 04:07

This entry was posted on Tuesday, October 26th, 2010 at 11:01 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.