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

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

Thanks,
~ j.
jwade@userfriendlytech.net


On Mon, Mar 18, 2013 at 2:39 PM, Billy Crook <billycrook@gmail.com> wrote:
Every time you use a route table as a firewall, God kills a kitten.

If you want a firewall, use..... a firewall.  iptables is the command.

If you want something that scales, and won't require your time to
maintain a shitlist of IPs; use fail2ban, and it will manage the list
per your specifications.

Most likely, your DoS is apache-local.  i.e. they aren't actually
flooding your entire pipe.  If you use fail2ban/iptables, this should
fix you right up.

If they are flooding your actual pipe, you need to apply the filter on
the far end of your pipe.  i.e. Get your ISP (or a new isp) that will
let you administer an ACL on the router on THEIR side of your line.
Or get a DDoS prevention service.  Blocking on the sonic wall will
have NO affect on a flood if the sonic wall is at the same site as the
targeted server.

Fail2ban can integrate with this remote filtering too.  You simply
modify fail2ban's 'action' to call a script that adds the IP upstream.

On Mon, Mar 18, 2013 at 2:27 PM, Andrew Beals <andrew.beals@gmail.com> wrote:
> If they're coming from just the single IP, then black-hole'ing their IP is
> easier.  If the address they're coming from is 128.115.1.1, then simply
> paste this at a shell prompt and give it your password when sudo asks for
> it:
>
> sudo route add 128.115.1.1 gw 127.0.0.1 lo
>
> This will cause all packets destined to go back to them to get dropped on
> the floor and should be sufficient.  You'd really prefer to do this (or just
> add them to the naughty list which is something that I believe the SW can
> do, even with ancient builds of their SW) on your SonicWall box, but you can
> get away with doing it on your server.
>
> Adding an IP tables (again, if you can't convince your SW to just drop
> packets from them) is more efficient, of course, but it's hairier to set up.
>
>
>
> On Mon, Mar 18, 2013 at 2:19 PM, J. Wade Michaelis
> <jwade@userfriendlytech.net> wrote:
>>
>> I have a CentOS web server that has recently been brought to a halt on two
>> separate occasions.  Checking the access.log, it appears that it was a
>> Denial of Service (DOS) attack (hundreds of HTTP requests in a very short
>> time, all from a single IP address).
>>
>> I want to prevent these types of attacks from bringing the server to its
>> knees.  We have a hardware firewall (SonicWall) in place, but it isn't quite
>> new enough to run the firmware that allows rate-limiting.
>>
>> I have found a number of tutorials that show how to do this type of thing
>> with IPTABLES.  Is there a better solution?
>>
>> Supposing I go with IPTABLES, do I need to include rules to allow FTP and
>> SSH (the only other services on the server)?
>>
>> Would any of you be willing to assist me with this?
>>
>> Thanks,
>> ~ j.
>> jwade@userfriendlytech.net
>>
>> _______________________________________________
>> KCLUG mailing list
>> KCLUG@kclug.org
>> http://kclug.org/mailman/listinfo/kclug
>
>
>
> _______________________________________________
> KCLUG mailing list
> KCLUG@kclug.org
> http://kclug.org/mailman/listinfo/kclug