<div>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.  </div>
<div><br></div><div>The only server that had problems with these attacks was the CentOS webserver.</div><div><br></div><div>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.)</div>
<br clear="all"><div>Thanks,<br>~ j.<br><a href="mailto:jwade@userfriendlytech.net">jwade@userfriendlytech.net</a></div>
<br><br><div class="gmail_quote">On Mon, Mar 18, 2013 at 2:39 PM, Billy Crook <span dir="ltr"><<a href="mailto:billycrook@gmail.com" target="_blank">billycrook@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Every time you use a route table as a firewall, God kills a kitten.<br>
<br>
If you want a firewall, use..... a firewall.  iptables is the command.<br>
<br>
If you want something that scales, and won't require your time to<br>
maintain a shitlist of IPs; use fail2ban, and it will manage the list<br>
per your specifications.<br>
<br>
Most likely, your DoS is apache-local.  i.e. they aren't actually<br>
flooding your entire pipe.  If you use fail2ban/iptables, this should<br>
fix you right up.<br>
<br>
If they are flooding your actual pipe, you need to apply the filter on<br>
the far end of your pipe.  i.e. Get your ISP (or a new isp) that will<br>
let you administer an ACL on the router on THEIR side of your line.<br>
Or get a DDoS prevention service.  Blocking on the sonic wall will<br>
have NO affect on a flood if the sonic wall is at the same site as the<br>
targeted server.<br>
<br>
Fail2ban can integrate with this remote filtering too.  You simply<br>
modify fail2ban's 'action' to call a script that adds the IP upstream.<br>
<div class="im HOEnZb"><br>
On Mon, Mar 18, 2013 at 2:27 PM, Andrew Beals <<a href="mailto:andrew.beals@gmail.com">andrew.beals@gmail.com</a>> wrote:<br>
</div><div class="HOEnZb"><div class="h5">> If they're coming from just the single IP, then black-hole'ing their IP is<br>
> easier.  If the address they're coming from is 128.115.1.1, then simply<br>
> paste this at a shell prompt and give it your password when sudo asks for<br>
> it:<br>
><br>
> sudo route add 128.115.1.1 gw 127.0.0.1 lo<br>
><br>
> This will cause all packets destined to go back to them to get dropped on<br>
> the floor and should be sufficient.  You'd really prefer to do this (or just<br>
> add them to the naughty list which is something that I believe the SW can<br>
> do, even with ancient builds of their SW) on your SonicWall box, but you can<br>
> get away with doing it on your server.<br>
><br>
> Adding an IP tables (again, if you can't convince your SW to just drop<br>
> packets from them) is more efficient, of course, but it's hairier to set up.<br>
><br>
><br>
><br>
> On Mon, Mar 18, 2013 at 2:19 PM, J. Wade Michaelis<br>
> <<a href="mailto:jwade@userfriendlytech.net">jwade@userfriendlytech.net</a>> wrote:<br>
>><br>
>> I have a CentOS web server that has recently been brought to a halt on two<br>
>> separate occasions.  Checking the access.log, it appears that it was a<br>
>> Denial of Service (DOS) attack (hundreds of HTTP requests in a very short<br>
>> time, all from a single IP address).<br>
>><br>
>> I want to prevent these types of attacks from bringing the server to its<br>
>> knees.  We have a hardware firewall (SonicWall) in place, but it isn't quite<br>
>> new enough to run the firmware that allows rate-limiting.<br>
>><br>
>> I have found a number of tutorials that show how to do this type of thing<br>
>> with IPTABLES.  Is there a better solution?<br>
>><br>
>> Supposing I go with IPTABLES, do I need to include rules to allow FTP and<br>
>> SSH (the only other services on the server)?<br>
>><br>
>> Would any of you be willing to assist me with this?<br>
>><br>
>> Thanks,<br>
>> ~ j.<br>
>> <a href="mailto:jwade@userfriendlytech.net">jwade@userfriendlytech.net</a><br>
>><br>
>> _______________________________________________<br>
>> KCLUG mailing list<br>
>> <a href="mailto:KCLUG@kclug.org">KCLUG@kclug.org</a><br>
>> <a href="http://kclug.org/mailman/listinfo/kclug" target="_blank">http://kclug.org/mailman/listinfo/kclug</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> KCLUG mailing list<br>
> <a href="mailto:KCLUG@kclug.org">KCLUG@kclug.org</a><br>
> <a href="http://kclug.org/mailman/listinfo/kclug" target="_blank">http://kclug.org/mailman/listinfo/kclug</a><br>
</div></div></blockquote></div><br>