Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
People above were talking about running out of memory and socket limitations and things like that...
But I don't understand why Lighttpd and IIS is not affected, but Apache is. Can anybody explain that to me?
If it only seems to affect Apache then the solution to solving the problem should be pretty obvious.. other sorts of web servers are very common and their behavior should be well known!
Apache attacked by a "slow loris"
Posted Jun 24, 2009 17:05 UTC (Wed) by tialaramex (subscriber, #21167)
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.
Posted Jun 24, 2009 17:59 UTC (Wed) by drag (subscriber, #31333)
Which is, generally, a good solution for people with servers that use a lot of server-side scripting anyways.
Posted Jun 25, 2009 4:53 UTC (Thu) by khim (subscriber, #9252)
So the easy solution, I suppose, is just to use Lighttpd or
something like that as a reverse proxy for your Apache
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 -
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.
Posted Jun 28, 2009 20:38 UTC (Sun) by job (guest, #670)
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.
Posted Jun 25, 2009 0:34 UTC (Thu) by JohnDickson (subscriber, #7406)
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)
The event MPM apparently isn't vulnerable to Slowloris (just
lighthttpd, IIS etc.). However, it's apparently incompatible with mod_ssl
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).
one requires response in nanoseconds, second one sometimes take seconds.
when you split these two operations in two threads frontend-backend scheme
becomes quite natural. You can use nginx to handle enormous loads
a single decent server and then safely use as many backend systems as
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...
Posted Jun 25, 2009 9:41 UTC (Thu) by dgm (subscriber, #49227)
But not passionate advocates, it seems.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds