DOS prevention

[Billy Crook]

On Mon, Mar 18, 2013 at 2:55 PM, J. Wade Michaelis
<jwade at userfriendlytech.net> wrote:
> The SonicWall I mentioned is in front of a lot of servers, and none of the
> other services suffered any interruptions when the attacks occurred.

This demonstrates that your DoS was almost certainly not caused by
bandwidth exhaustion.  Thus is will work fine to address it on the
attacked server.

> They
> are hosted in a datacenter, and we have nice healthy bandwidth there.  Also,
> I would presume they have their own DOS prevention in place on their
> routers.

That is a big assumption.  DoS is a fuzzy thing, and few Colos are
going to risk stepping on legitimate traffic with some algorithm that
can't be perfect.

> The only server that had problems with these attacks was the CentOS
> webserver.
>
> Fail2ban looks interesting.  I hadn't heard of it before.  What settings
> would you recommend to prevent DOS attacks while allowing "normal" access
> for legitimate traffic?  (I can provide additional data on "normal" usage if
> required.)

I have my server tuned rather aggressively   More than three
aggressions in a five minute window, and you're banned for a year.
You may want to re-tune those intervals.

That said, Fail2Ban has 'filters', 'actions', and 'jails'.
Filters specify logfiles to watch, what to watch FOR, and how to
identify the aggressor in the log files.  I have attached my filters
to this message.
Actions are things you want fail2ban to DO in response to finding a match.
Jails specify a filter, action, and timing parameters.  My Jail
configuration is below:

[apache-401s]
enabled  = true
filter   = apache-401s
action   = iptables-allports
           sendmail-whois[name=apache-401s, dest=root,
sender=Zero-fail2ban at BCrook.com]
logpath  = /var/log/httpd/*access_log
maxretry = 3
findtime = 300

[apache-403s]
enabled  = true
filter   = apache-403s
action   = iptables-allports
           sendmail-whois[name=apache-403s, dest=root,
sender=Zero-fail2ban at BCrook.com]
logpath  = /var/log/httpd/*access_log
maxretry = 3
findtime = 300

[apache-404s]
enabled  = true
filter   = apache-404s
action   = iptables-allports
           sendmail-whois[name=apache-404s, dest=root,
sender=Zero-fail2ban at BCrook.com]
logpath  = /var/log/httpd/*access_log
maxretry = 10
findtime = 60

[apache-douchebags]
enabled  = true
filter   = apache-douchebags
action   = iptables-allports
           sendmail-whois[name=apache-douchebags, dest=root,
sender=Zero-fail2ban at BCrook.com]
logpath  = /var/log/httpd/*access_log
maxretry = 1
findtime = 31557600


If you want to test it out, try bcrook.com. Then try a bogus url there
three times in a row.
For extra credit, add some non-existent paths to your robots.txt file,
and tell all engines not to index them.  Then add those paths to
fail2ban's list of auto-ban paths.  When a bad bot uses your
robots.txt file to spider into directories you told it not to (or more
likely when an intelligent aggressor does that), they get banned and
you get emailed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apache-401s.conf
Type: application/octet-stream
Size: 828 bytes
Desc: not available
URL: <http://kclug.org/pipermail/kclug/attachments/20130318/db84e663/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apache-403s.conf
Type: application/octet-stream
Size: 828 bytes
Desc: not available
URL: <http://kclug.org/pipermail/kclug/attachments/20130318/db84e663/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apache-404s.conf
Type: application/octet-stream
Size: 828 bytes
Desc: not available
URL: <http://kclug.org/pipermail/kclug/attachments/20130318/db84e663/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apache-douchebags.conf
Type: application/octet-stream
Size: 2276 bytes
Desc: not available
URL: <http://kclug.org/pipermail/kclug/attachments/20130318/db84e663/attachment-0003.obj>