<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 style>Apache is great for the feature-list, but I've had much better performance using nginx. </div>
<div style>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">http://en.wikipedia.org/wiki/Nginx</a><br></div></div>
<div class="gmail_extra"><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 class="HOEnZb"><div class="h5"><br>
On Mon, Mar 18, 2013 at 3:45 PM, J. Wade Michaelis<br>
<<a href="mailto:jwade@userfriendlytech.net">jwade@userfriendlytech.net</a>> wrote:<br>
> On Mon, Mar 18, 2013 at 2:58 PM, Mark Hutchings <<a href="mailto:mark.hutchings@gmail.com">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">jwade@userfriendlytech.net</a><br>
><br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
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><br clear="all"><div><br></div>-- <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>
</div>