<div>I really think that I want to go with a simple set of IPTABLES rules, and here is why:</div><div><br></div><div>The only two occasions that the server has hung up were due to DOS attacks averaging around 8 or 10 requests per second for a minute or more. Also, hosting this server is not profitable enough to do a lot of work installing additional packages and configuring and testing them, or subscribing to additional third-party services.</div>
<div><br></div><div>It appears that limiting the number of connections accepted from a single IP in 10 seconds (or similar) could have prevented the two attacks I have seen from bring down the server.</div><div><br></div>
<div>So, that brings me to the following questions:</div><div><br></div><div>I found this pair of rules at <a href="http://blog.bodhizazen.net/linux/prevent-dos-with-iptables/comment-page-1/#comment-4524">http://blog.bodhizazen.net/linux/prevent-dos-with-iptables/comment-page-1/#comment-4524</a></div>
<div><div><font face="courier new, monospace">iptables -v -A INPUT -i eth0 -p tcp –syn –match multiport –dports 80 -m recent –rcheck –seconds 5 –hitcount 10 –name HTTP -j LOG –log-prefix “HTTP Rate Limit: ”</font></div><div>
<font face="courier new, monospace">iptables -v -A INPUT -i eth0 -p tcp –syn –dport 80 -m recent –update –seconds 5 –hitcount 10 –name HTTP -j DROP</font></div></div><div><br></div><div>Do I need any other rules, or can I use just these two (given that the server is already behind a hardware firewall)? Will they work as is, or will I need to adjust them? Do I need additional rules for HTTPS traffic, or can I change "-dports 80" to "-dports 80,443" to achieve that?</div>
<div><br></div><div>Any other advice?</div><div><br></div><div>Thanks for all of the suggestions!</div><div><br></div><div>~ 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 4:33 PM, Nathan Cerny <span dir="ltr"><<a href="mailto:ncerny@gmail.com" target="_blank">ncerny@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Obviously you want to address the attacks, but you could also look into a more efficient web server.<div><br></div><div>Apache is great for the feature-list, but I've had much better performance using nginx. </div>
<div>Granted, my experience is much smaller scale - 5-10 users on a highly intensive website.</div><div><br></div><div><a href="http://en.wikipedia.org/wiki/Nginx" target="_blank">http://en.wikipedia.org/wiki/Nginx</a><br>
</div></div>
<div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Mon, Mar 18, 2013 at 4:22 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">It's easy to /say/ that any modern server should be able to handle a<br>
few thousand GET requests.<br>
<br>
The reality is that a single URI may affect dozens of scripts that you<br>
didn't write, which might hit some database as many times, and you<br>
can't change them for business or political reasons; even if you are<br>
entirely qualified to fix bugs and do performance tuning.<br>
<br>
When an aggressor, or just some well-intentioned runaway script harps<br>
on one of these URIs, your options as an admin are limited.<br>
<br>
You can throw more hardware at it, put (and maintain) some caching<br>
proxy infront of it; or you can throttle the aggressor Fail2ban will<br>
help you do the latter, and much more. For instance, it becomes<br>
realistic to run ssh on its official port (gasp!) if you use fail2ban<br>
to cut down on riff raff.<br>
<br>
As fail2ban starts blocking the sources of the floods, look over the<br>
list of addresses, and see if you can identify a business partner. If<br>
you can get them to fix their script, all the better.<br>
<div><div><br>
On Mon, Mar 18, 2013 at 3:45 PM, J. Wade Michaelis<br>
<<a href="mailto:jwade@userfriendlytech.net" target="_blank">jwade@userfriendlytech.net</a>> wrote:<br>
> On Mon, Mar 18, 2013 at 2:58 PM, Mark Hutchings <<a href="mailto:mark.hutchings@gmail.com" target="_blank">mark.hutchings@gmail.com</a>><br>
> wrote:<br>
>><br>
>> You sure it was just a http attack? Several hundred requests in a few<br>
>> minutes shouldnt really put it on it's knees, unless the server is a VPS<br>
>> with low memory/CPU usage limits, or the server itself is low on resources.<br>
><br>
><br>
> I've gone over my access logs again, and here are the particulars on the two<br>
> attacks that caused the server to hang:<br>
><br>
> On March 6th, between 4:29:11 and 4:31:40, there were 1453 requests from a<br>
> single IP, and all were 'GET' requests for a single page (one that does<br>
> exist).<br>
><br>
> On March 14th, between 15:15:19 and 15:16:29, there were 575 requests from<br>
> the one IP address. These were all different GET requests, nearly all<br>
> resulting in 404 errors. Some appear to be WordPress URLs. (The website on<br>
> my server is a Magento commerce site.)<br>
><br>
> Here are some other example requests from the attack:<br>
><br>
> GET /?_SERVER[DOCUMENT_ROOT]=<a href="http://google.com/humans.txt" target="_blank">http://google.com/humans.txt</a>? HTTP/1.1<br>
> GET /?npage=1&content_dir=<a href="http://google.com/humans.txt%00&cmd=ls" target="_blank">http://google.com/humans.txt%00&cmd=ls</a> HTTP/1.1<br>
> GET<br>
> /A-Blog/navigation/links.php?navigation_start=<a href="http://google.com/humans.txt" target="_blank">http://google.com/humans.txt</a>?<br>
> HTTP/1.1<br>
> GET<br>
> /Administration/Includes/deleteUser.php?path_prefix=<a href="http://google.com/humans.txt" target="_blank">http://google.com/humans.txt</a><br>
> HTTP/1.1<br>
> GET<br>
> /BetaBlockModules//Module/Module.php?path_prefix=<a href="http://google.com/humans.txt" target="_blank">http://google.com/humans.txt</a><br>
> HTTP/1.1<br>
> GET /admin/header.php?loc=<a href="http://google.com/humans.txt" target="_blank">http://google.com/humans.txt</a> HTTP/1.1<br>
><br>
> I don't recognize most of these, but the pattern indicates to me that these<br>
> are most likely 'standard' URLs in various CMSs.<br>
><br>
> As for the server configuration, it is a dedicated server (only one website)<br>
> running on VMware ESXi 5.0.<br>
><br>
> CentOS 6.3<br>
> 8 virtual CPU cores (2 quad-core CPUs)<br>
> 4096 MB memory<br>
><br>
> Other VMs on the same host appeared to be unaffected by the attack.<br>
><br>
> Thanks,<br>
> ~ j.<br>
> <a href="mailto:jwade@userfriendlytech.net" target="_blank">jwade@userfriendlytech.net</a><br>
><br>
><br>
><br>
><br>
</div></div><div><div>> _______________________________________________<br>
> KCLUG mailing list<br>
> <a href="mailto:KCLUG@kclug.org" target="_blank">KCLUG@kclug.org</a><br>
> <a href="http://kclug.org/mailman/listinfo/kclug" target="_blank">http://kclug.org/mailman/listinfo/kclug</a><br>
_______________________________________________<br>
KCLUG mailing list<br>
<a href="mailto:KCLUG@kclug.org" target="_blank">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><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br>Nathan Cerny<br><br>-------------------------------------------------------------------------------<div>
<div>"I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone."</div>
<div>--Bjarne Stroustrup, Danish computer scientist</div>-------------------------------------------------------------------------------</div>
</font></span></div>
</blockquote></div><br>