| |||||||||||||
Apache attacked by a "slow loris"Apache attacked by a "slow loris"Posted Jun 24, 2009 17:05 UTC (Wed) by tialaramex (subscriber, #21167)In reply to: Apache attacked by a "slow loris" by drag Parent article: Apache attacked by a "slow loris"
Apache is allocating each "slow loris" a process (or at least a thread) in the expectation that it will soon get a complete request, process it, and return the thread / process to the pool. Apache can afford to allow only a few of these to exist at one time (limited by your hardware and/or chosen configuration)
In contrast the design in products like IIS allocates nothing but a socket and a little bit of working space until the "slow loris" has written out a whole request which can be answered. Many, many more such requests can be tolerated on the same hardware.
Thus, a thousand "slow loris" connections to your IIS are merely an annoyance, nothing that needs urgent action, while on Apache they've probably effectively taken your site off the Internet.
(Log in to post comments)
Apache attacked by a "slow loris" Posted Jun 24, 2009 17:59 UTC (Wed) by drag (subscriber, #31333) [Link]
So the easy solution, I suppose, is just to use Lighttpd or something like that as a reverse proxy for your Apache server.
Which is, generally, a good solution for people with servers that use a lot of server-side scripting anyways.
Or something Posted Jun 25, 2009 4:53 UTC (Thu) by khim (subscriber, #9252) [Link] So the easy solution, I suppose, is just to use Lighttpd or something like that as a reverse proxy for your Apache server.If you look on the latest survey you'll find out that millions are already running "something like that". Nginx was designed from ground up to work in such situation - if you know your apache process usually generates page 100K in size you can specify this as buffer size to nginx and then your "real" server will be freed in milliseconds and when occasional long page will be generated nginx will wait for backend. Lighthttpd uses similar architecture, but it's less configurable when used as http-accelerator. And of course when you send static pages it makes perfect sense to use sendfile(2) and forget about everything (nginx does more or less that - just a few small structures to handle "keep alive" connections). That's why I can not see what's so important happened: this is well-known apache problem but while it can not be solved with apache alone it can be solved with additional software - and was solved for years by real admins on millions of systems.
Apache attacked by a "slow loris" Posted Jun 28, 2009 20:38 UTC (Sun) by job (guest, #670) [Link]
Sort of. Not really.
Any simple select-loop (or poll)-based web server would do. But as soon as you serve dynamic content in any way, be it via PHP or any other language, the problem is back again. Most (all?) web site languages are served by worker processes, either built into the web server or stand alone pre-forked.
Disarming the attack only on static file URLs is not really a solution. The attack would probably choose apparent dynamic URLs such as .php if this was a real world attack anyway.
Apache attacked by a "slow loris" Posted Jun 25, 2009 0:34 UTC (Thu) by JohnDickson (subscriber, #7406) [Link]
According to some of the mailing list threads on this issue, Apache has an experimental event-based MPM, in addition to the old prefork (multi-process) and worker (multi-process/multi-thread) MPMs.
The event MPM apparently isn't vulnerable to Slowloris (just like lighthttpd, IIS etc.). However, it's apparently incompatible with mod_ssl and some other input filters, so it's not a solution for us.
This is fundamental problem Posted Jun 25, 2009 5:09 UTC (Thu) by khim (subscriber, #9252) [Link] The event MPM apparently isn't vulnerable to Slowloris (just like lighthttpd, IIS etc.). However, it's apparently incompatible with mod_ssl and some other input filters, so it's not a solution for us. Single thread can not simultaneously handle many thousands connections and do heavy-duty processing (PHP, SQL database requests, etc). First one requires response in nanoseconds, second one sometimes take seconds. And when you split these two operations in two threads frontend-backend scheme becomes quite natural. You can use nginx to handle enormous loads with a single decent server and then safely use as many backend systems as needed. It IS possible to create faster and less resource-hungry server then nginx+apache combo, but if you need to alter existing installation... there are no contest. The only thing nginx really needs is decent documentation...
This is fundamental problem Posted Jun 25, 2009 9:41 UTC (Thu) by dgm (subscriber, #49227) [Link]
> The only thing nginx really needs is decent documentation...
But not passionate advocates, it seems.
|
|||||||||||||