Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Attack On a Significant Flaw In Apache Released

kdawson posted more than 5 years ago | from the take-it-slow dept.

Security 203

Zerimar points out a significant flaw in Apache that can lead to a fairly trivial DoS attack is in the wild. Apache 1.x, 2.x, dhttpd, GoAhead WebServer, and Squid are confirmed vulnerable, while IIS6.0, IIS7.0, and lighttpd are confirmed not vulnerable. As of this writing, Apache Foundation does not have a patch available. From Rsnake's introduction to the attack tool: "In considering the ramifications of a slow denial of service attack against particular services, rather than flooding networks, a concept emerged that would allow a single machine to take down another machine's web server with minimal bandwidth and side effects on unrelated services and ports. The ideal situation for many denial of service attacks is where all other services remain intact but the webserver itself is completely inaccessible. Slowloris was born from this concept, and is therefore relatively very stealthy compared to most flooding tools."

Sorry! There are no comments related to the filter you selected.

So slashdot... (5, Funny)

santax (1541065) | more than 5 years ago | (#28389621)

be prepared to feel the slashdot-effect yourself for once!

Re:So slashdot... (4, Informative)

jamie (78724) | more than 5 years ago | (#28390369)

We have a hardware load-balancer and a software reverse proxy (varnish) in front of our apache.

I kinda doubt this would work on us.

Note, I am not inviting anyone to try. It might work great for all I know :(

Re:So slashdot... (1)

Deagol (323173) | more than 5 years ago | (#28390543)

I was wondering the same thing as well. I run a small site with varnish on the front end. Anyone know how attacks like this work against servers behind a forward proxy?

Here it comes... (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28390431)

Only 40 comments? OK, I will do my nerd duty and get the flame war started:

This event is proof that proprietary software is more secure that open source.

Next up: Emacs: better than vi or way better than vi?

Re:Here it comes... (0)

Anonymous Coward | more than 5 years ago | (#28390503)

Next up: Emacs: better than vi or way better than vi?

Better than vi (c'mon, what decade is this?), waaaay worse than vim.

Am i the only one who thinks that it's retarded... (0, Offtopic)

Anonymous Coward | more than 5 years ago | (#28390547)

that I should have to reboot my MacBook for a freaking web browser update? And a minor release, at that. I just rebooted last week for a damned QuickTime update (also ridiculous). Come on, Apple engineers. Get your freaking head in the game!

Re:Am i the only one who thinks that it's retarded (0, Offtopic)

knavel (1155875) | more than 5 years ago | (#28390607)

Apple, you can't bring that weak ass stuff up in this humpy bumpy! And you know this, baby! WOOOO!

Well its not just Apache (-1)

Chrisq (894406) | more than 5 years ago | (#28389637)

It is clear that this is not an Apache but web servers in general, with IIS also being affected. Now I wonder which will issue a security patch first

Re:Well its not just Apache (0)

santax (1541065) | more than 5 years ago | (#28389659)

I thought IIS wasn't affected by this? At least the current versions. But I sure hope there will be a fix very soon, cause this really is a big deal.

Re:Well its not just Apache (3, Funny)

sys.stdout.write (1551563) | more than 5 years ago | (#28389963)

I'm just waiting for a "Get The Facts" campaign for "IIS vs Apache" on the Microsoft website, along with a completely accurate comparison chart!

Re:Not *such* a big deal (1)

jginspace (678908) | more than 5 years ago | (#28390285)

Correct, IIS is not affected. The good news is that it's difficult to get much milage attacking from a Windows box. From TFA:

Windows users: You probably will not be able to successfuly execute a Slowloris denial of service from Windows even if you use Cygwin. I have not had any luck getting Slowloris to successfuly deny service from within Windows, because Slowloris requires more than a few hundred sockets to work (sometimes a thousand or more), and Windows limits sockets to around 130, from what I've seen. I highly suggest you use a *NIX operating system to execute Slowloris from for the best results, and not from within a virtual machine, as that could have unexpected results based on the parent operating system.

Re:Well its not just Apache (3, Informative)

The End Of Days (1243248) | more than 5 years ago | (#28389665)

You may have missed the 'not' in the summary there.

Re:Well its not just Apache (1)

El_Muerte_TDS (592157) | more than 5 years ago | (#28389859)

Wait, you mean the summary on /. is finally correct!?
So... I did see a pig fly past the windows.

Re:Well its not just Apache (1)

Kokuyo (549451) | more than 5 years ago | (#28390071)

Tjat would have been your screen saver.

Re:Well its not just Apache (1)

Mister Whirly (964219) | more than 5 years ago | (#28390725)

No, that's just the Swine Flu.

Re:Well its not just Apache (1)

Critical Facilities (850111) | more than 5 years ago | (#28391399)

Wait, you mean the summary on /. is finally correct!?

No. Here [sans.org] is the link to the article. Not sure what to tell ya about the pig, though. Maybe check the dosage on your meds? ;-)

Re:Well its not just Apache (0)

Anonymous Coward | more than 5 years ago | (#28389671)

while IIS6.0, IIS7.0, and lighttpd are confirmed not vulnerable
You didnt even read the summary?! Wow...

Re:Well its not just Apache (-1, Redundant)

Satanicolas (1374761) | more than 5 years ago | (#28389679)

IIS not affected
learn to read

Re:Well its not just Apache (1)

McNihil (612243) | more than 5 years ago | (#28390471)

Just tested on www.microsoft.com and I sat there in the header negotiating part for over 3 minutes before the pipe broke on remote end (I didn't do anything.) Slight change in that slowloris makes IIS* vulnerable too.

Heck one could even make it so that the header requests go out at 8 bit/s or less and just whallop any server with a lot of these requests... and have the requests FULLY valid.

Its simple for an admin to block the IP so its not that big of an issue unless it is employed as a DDoS.

Re:Well its not just Apache (0)

Anonymous Coward | more than 5 years ago | (#28390797)

Its just ironic that not so long ago, the Microsoft website was running on a set of Sun Web servers under Solaris. :)

Re:Well its not just Apache (2, Interesting)

nxtw (866177) | more than 5 years ago | (#28390881)

Just tested on www.microsoft.com and I sat there in the header negotiating part for over 3 minutes before the pipe broke on remote end (I didn't do anything.) Slight change in that slowloris makes IIS* vulnerable too.

Keeping idle sessions open on the server for some period of time is not the flaw. The flaw is that some servers (in default configurations) only handles so many of these idle sessions open before reaching a limit and refusing to accept any new sessions, and that this limit is sufficiently low, and that one client can easily reach this limit.

This particularly affects web servers that fork separate processes to service multiple requests at the same time - and this includes the default configuration of Apache 2 on many systems. (Last I checked, PHP's Apache module implementation only works well with the forking proces model because of thread safety issues.)

IIS does not use this antiquated process model - it's threaded. Apache can be configured to use a threaded model too. Unfortunately, thread-unsafe code is still common.

Re:Well its not just Apache (1)

McNihil (612243) | more than 5 years ago | (#28391323)

What are you talking about? There is settings in IIS regarding max connections as well and presumably would be effected in the same manner if these are set too low. This has nothing to do with fork (process) or non forked (lightweight process) method of serving.... or are you telling me that IIS is currently completely on Fiber level instead of their "Threads" ?

Either way at some point you still need to do some poll on the master socket to peek if there is some requests coming your way so you can relegate it to one of the threads in the pool. Thread pool starvation and all that... you can't really fully escape this (there I even got a pun included.)

Re:Well its not just Apache (1)

segedunum (883035) | more than 5 years ago | (#28389685)

IIS is not vulnerable, as confirmed in TFAs and the summary. Seems as though a DoS attack has affected some peoples' eyes.

Re:Well its not just Apache (0)

Anonymous Coward | more than 5 years ago | (#28389693)

RTFS

"while IIS6.0, IIS7.0, and lighttpd are confirmed not vulnerable"

HTTP, not apache (1)

CarpetShark (865376) | more than 5 years ago | (#28390553)

The article states that this is like a syn flood, but on the HTTP level, rather than the TCP level. So essentially, it sounds like a flaw in previous understanding of HTTP, which will now be rectified by patching servers INCLUDING Apache.

It's a pity the reports of affected servers wasn't more comprehensive though; I'd like to know where Cherokee and nginx stand.

What about ... (2, Funny)

Anonymous Coward | more than 5 years ago | (#28389691)

Opera Unite?

WTH? This is an absolutely trivial attack (3, Insightful)

Rogerborg (306625) | more than 5 years ago | (#28389703)

It's just holding sockets open; that's the "Hello, world!" of DOS attacks.

I'm finding it hard to believe that Apache is genuinely vulnerable to this. Did nobody see it coming? For real?

Re:WTH? This is an absolutely trivial attack (2, Informative)

Lord Ender (156273) | more than 5 years ago | (#28390239)

No, it's not. It's holding an HTTP session open. That is not the same thing as a TCP socket.

Re:WTH? This is an absolutely trivial attack (4, Informative)

dword (735428) | more than 5 years ago | (#28390455)

Let me make this clearer for those that aren't very technical: It's holding an HTTP session open and Apache has a limited number of simultaneous HTTP sessions.
All someone has to do is send about 100 requests to your website and leave them open without sending any further information. Nobody else will be able to connect to your web server for a long time. The weekend is coming, so I'm expecting lots of downtime for government sites in the next couple of days...

Re:WTH? This is an absolutely trivial attack (3, Informative)

Xeriar (456730) | more than 5 years ago | (#28391289)

A simple connlimit declaration in IPTables shuts this down fairly easily...

Re:WTH? This is an absolutely trivial attack (0)

Anonymous Coward | more than 5 years ago | (#28390329)

I'm finding it hard to believe that Apache is genuinely vulnerable to this. Did nobody see it coming? For real?

10.4.9 408 Request Timeout

      The client did not produce a request within the time that the server
      was prepared to wait. The client MAY repeat the request without
      modifications at any later time.

It makes no mention of a default or required timeout.
This is just a case of the specs being written long (10 years this month) before people started adding protection measures into the specs. Luckily, unlike SMTP specs, this is easy to fix without breaking t'internet.

Attack of a 1000 snails. (2, Informative)

leuk_he (194174) | more than 5 years ago | (#28390651)

This type is already known as "attack by a 1000 snails" type attack. It is harder to defned against than you would think. A user can be slow, but coders are hesitant to drop users that ar too slow or too fast.

A user kan just keep the TCP/IP alive by sending one byte every x seconds. If this is patched at http header level, you will see you can do the same kind of attack on the application, that can have limited php or perl sessions.

Re:WTH? This is an absolutely trivial attack (2, Interesting)

suso (153703) | more than 5 years ago | (#28391283)

Yes, I agree. I've seen a handful of attacks like this over the years. Maybe not exactly this one, but Apache has been vulnerable to this for years and I thought all webservers were. And I thought people just knew about it already. This one is a tough one to fix, its not like Apache can just patch something. It sounds like an architectural change is needed.

Proof Of Concept (-1, Offtopic)

calcio (1580609) | more than 5 years ago | (#28389705)

We have a proof of concept exploit for this vulnerability at http://security.precor-incorporated.com/ [precor-incorporated.com]

Why not IIS? (3, Interesting)

MBCook (132727) | more than 5 years ago | (#28389711)

Why isn't IIS vulnerable? Does it just assume the headers are done after some amount of time? Does it have a limit to the number of headers it accepts?

Can this even be fixed without technically breaking the protocol (since it sounds like what's going on is correct behavior, theoretically)?

Re:Why not IIS? (2, Interesting)

nicolas.kassis (875270) | more than 5 years ago | (#28389929)

What I'm thinking, is this basically another time where those not vulnerable were actually not respecting the spec?

Re:Why not IIS? (0, Troll)

Rogerborg (306625) | more than 5 years ago | (#28390081)

Yup. I'm further thinking that since this is such a stupidly trivial attack, that it was all that MS could think to defend against, and that no Apache developer believed that any self respecting attacker would stoop so low.

Re:Why not IIS? (5, Insightful)

Malc (1751) | more than 5 years ago | (#28390307)

Does the HTTP spec say anything about the server application timing out the connection? Seems like reasonable behaviour to me. I would be surprised if this isn't a configurable option in Apache too.

People love to hate it, but IIS has matured in to a very good web server. It's my choice over Apache.

Re:Why not IIS? (1)

CarpetShark (865376) | more than 5 years ago | (#28390587)

IIS has matured in to a very good web server.

Yes, but which one?

Re:Why not IIS? (4, Funny)

Opportunist (166417) | more than 5 years ago | (#28390041)

If the vulnerability is based on correct, standard conform behaviour of the server, I can see why IIS isn't susceptible to it.

Re:Why not IIS? (2, Informative)

Anonymous Coward | more than 5 years ago | (#28390263)

More likely IIS survives because it uses a worker pool threading model (no thread/process is dedicated to a connection, so a connection only takes up memory for the state, not for the thread).

Apache had, and probably still has, a process/thread-per-connection model.

So with all due respect, it looks like a proper design decision is what is protecting IIS here:
http://www.kegel.com/c10k.html
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a63ee1c2-04d6-44dc-b4d6-678eb3117bf9.mspx?mfr=true

Re:Why not IIS? (5, Informative)

Amouth (879122) | more than 5 years ago | (#28390209)

unless you are using Session()'s in asp in IIS then one thread in IIS handles multiple connections.

what this is doing is opening a connection (getting a thread to work it) and holding it open (keeping the thread busy) and just keep asking for new ones.

it is very common (always i think) for Apache and allot of web servers to have a max thread's so that the site under heavy traffic doesn't open more connections than it can handle.

where IIS also has a worker thread limit - there is no limit *(you can set one - but not on by default) on how many concurrent connections can be managed by a thread (and new incoming connections are passed to the thread with the lowest current work load - not always the one with less connections)..

if you do what they are doing here i can see IIS behavior would be to slowly pile all these slow - no work connections into one thread and the others would happily go about doing actual work..

where apache would slowly lose access to workable threads as this keeps them busy.

this isn't an exploit on the http or tcp protocol - it is an exploit based on the behavior of the web server based on it's best practices for managing it.

Re:Why not IIS? (1)

MBCook (132727) | more than 5 years ago | (#28390347)

Makes sense.

But wouldn't you run into the connection limit of the OS at some point? Or is that just way too high to be a practical problem (say 16 million)?

Re:Why not IIS? (1)

Amouth (879122) | more than 5 years ago | (#28390627)

well the connection limit for a single host is the number of available ports for outbound traffic (to return data to the client)

by default (from memory here) i want to say IIS is set up to use ~4k ports for outbound - i do know that can be changed to allow ports 1024+ to be used meaning the number of avaliable ports would be ~64.5k

and that is per host ip - and unless you have the site bound to a specific host ip address (instead of using site headers - iis will respond on an alternate ip (if it has one) when another is out of ports (infact i think it round robbins - i can't remember)

Where this could be a problem for iis is with SSL as SSL has to be bound to an IP and the max amount of ports for that IP is going to be less than the number of ports that the client can send from. So yes this type of exploit could cause an outage in IIS - it is much less likely (based on default config) than apache - and is only realistically likely when trying to attack an SSL supporting site. (like they are hard to find)

About the only IIS server that this is going to bring down is the small personal or single server setups used by small biz. any type of clustered hosting or even virtual hosting - the worst case is that someone can block SSL connections to a site (unless the whole server is horridly configured - which we never ever can leave out of the equation - but even then with IIS6+ it would take effort to make your server very vulnerable to this)

Re:Why not IIS? (1)

raju1kabir (251972) | more than 5 years ago | (#28390959)

unless you have the site bound to a specific host ip address (instead of using site headers - iis will respond on an alternate ip (if it has one) when another is out of ports

How would that be of any use? The client on the far end is directing incoming traffic based on source IP (among other characteristics). TCP packets that arrive from random IPs are discarded.

Re:Why not IIS? (1)

Amouth (879122) | more than 5 years ago | (#28391293)

the incoming traffic is always going to IP:80

the return traffic from IIS is going coming from avaliable Ips':port

if you bind a website in IIS to an ip instead of "any avaliable ip" then the return tcp connection is forced to be sorced from the ip that is also the reciving

if you have it set to "any avaliable ip" and the box has 2 ip's your client may request data on IPA:80 and get a reply from IPB:port

there for your avaliable ports for reply (limiting the max connection's) would be MaxPorts* Available IP's.

give a Host 2 ip's and it has more ports than the attacking client (assuming a single attacker) bind the site to an ip and now the attacker has more ports than the host so it will work (this is going to be a given for SSL sites as they don't support host headers)

Re:Why not IIS? (-1, Offtopic)

cyberfr0g (2812) | more than 5 years ago | (#28390493)

Butthurt much?

Re:Why not IIS? (5, Funny)

Bemopolis (698691) | more than 5 years ago | (#28391121)

Why isn't IIS vulnerable

My guess is that the DoS attack is so slow that, by the time it would have completed, the server has already crashed for a different reason.

Why isn't IIS affected? (0)

Anonymous Coward | more than 5 years ago | (#28389713)

Does it timeout the HTTP header from the initial open or what?

Boring (5, Insightful)

Anonymous Coward | more than 5 years ago | (#28389719)

Talk about a boring exploit: no chance for expanding the attack into anything other than a DOS, and if it becomes widespread enough, fairly trivial to fix... (just kill the oldest waiting client that does not have a full header when the last client is taken.) I'd be embarrassed to publish something like this....

Re:Boring (1)

42forty-two42 (532340) | more than 5 years ago | (#28389961)

Surely it's far more embarrassing for the person on the receiving end of the attack.

Re:Boring (0)

Anonymous Coward | more than 5 years ago | (#28390559)

Meh, slightly. It's a minor design bug, and one that will be negated by the smarter firewalls out there. Allowing hundreds of open TCP connections from one source to a web server is very rarely a good idea.

Re:Boring (0)

Anonymous Coward | more than 5 years ago | (#28390785)

Unless the source is AOL. Lots of sites would lose a lot of revenue if the army of AOL users couldn't access their site. Their super proxies throw a wrench into this concept. Of course there are tons of sites that couldn't care less about AOL users too, so for them that's a perfectly reasonable solution.

Re:Boring (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28390017)

Of course it's boring to the /. crowd. It affects an open source product, so it must be boring. However, if the roles had been reversed and IIS was affected, everyone would be up in arms screaming defective by design etc. You people make me sick.

Re:Boring (1)

aztektum (170569) | more than 5 years ago | (#28390269)

I'd be embarrassed to publish something like this....

Says the Anonymous Coward

iptables helps (4, Informative)

samjam (256347) | more than 5 years ago | (#28389733)

You can have perlbal or any reverse proxy on the same machine but listening on a different port and then use iptables to redirect like this

# iptables -t nat -A -PREROUTING -d ! 127.0.0.1 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80

and then you don't need to change your apache configuration - and having apache listen on a different port to what users see can break some scripted sites if they read the port number from the apache config.

Seems to be a general problem. (4, Insightful)

Z00L00K (682162) | more than 5 years ago | (#28389737)

And the only resolution right now that I can see is to have a connection timeout.

At least the problem is a denial of service problem and not a problem with intrusion so the damage is easily rectified - restart the web server. Not that you really want to restart it.

And I suspect that other services can be vulnerable to this type of attack too, not only web servers.

Re:Seems to be a general problem. (1)

Rogerborg (306625) | more than 5 years ago | (#28390023)

the damage is easily rectified - restart the web server

And you get raped again as soon as it comes back up. How does restarting it help?

Re:Seems to be a general problem. (1)

TheLinuxSRC (683475) | more than 5 years ago | (#28390483)

It will take some time to ramp up the used connections again (assuming that, as the article states, this exploit is fairly slow). While certainly not a real fix, this could be an effective temporary solution until a better solution is available.

Re:Seems to be a general problem. (1)

micheas (231635) | more than 5 years ago | (#28390901)

Fairly slow has been under a minute on most of the servers I tested it on.

Fortunately my servers are configured to be able to run either lighttpd or apache. (in case I have a problem with one.)

So I can pick my poison.

Re:Seems to be a general problem. (2, Interesting)

sjames (1099) | more than 5 years ago | (#28390043)

A connection timeout should be fine. Just start the clock upon accept(). Give the client a generous but limited amount of time to send headers. If the timer expires before the empty line is received, close the connection.

Bonus points for not getting the thread pool involved until the header is complete.

Extra credit for a config option to send a flood of junk to the client and THEN close the socket. That could make attackers considerably more visible to their upstream provider.

Re:Seems to be a general problem. (2, Interesting)

sjames (1099) | more than 5 years ago | (#28390125)

Nothing like replyoing to yourself.

Double extra credit if the junk you send back looks enough like downloading music that the RIAA accidentally joins the forces of good and comes down on the attacker due to ISP snooping but not enough like downloaded music to get you actually busted.

Re:Seems to be a general problem. (0)

Anonymous Coward | more than 5 years ago | (#28390791)

At least the problem is a denial of service problem and not a problem with intrusion so the damage is easily rectified

That's not necessarily true. As another blog post [ckers.org] (linked to from TFA) points out, DoS attacks can be used to facilitate intrusions in cases where timing is of importance or used as a diversion.

Other Web Servers....Proxies......? (1)

segedunum (883035) | more than 5 years ago | (#28389783)

Could you potentially get around this if you're proxying to another web server, say lighttpd or Mongrel, or will this just blanketly affected Apache if you have it in front? I'm gathering the latter from the article:

At the moment I'm not sure what can be done in Apache's configuration to prevent this attack - increasing MaxClients will just increase requirements for the attacker as well but will not protect the server completely. One of our readers, Tomasz Miklas said that he was able to prevent the attack by using a reverse proxy called Perlbal in front of an Apache server.

Nginx is a threaded web server and the new darling on the block for people on VPSs and looking for a fast an low resource web server. I wonder how that fares?

Re:[Sounds Stupid] (2, Interesting)

segedunum (883035) | more than 5 years ago | (#28389885)

Having read this more this just strikes me as incredibly stupid. Did they publish this? Surely we're just talking about a timeout implementation here where the web server will say "Ahhhh, well you didn't complete that header, bye, bye"?

Re:Other Web Servers....Proxies......? (2, Informative)

natbudin (577028) | more than 5 years ago | (#28390073)

I just tried it against nginx 0.6.37. The attack appears to work there as well.

Possible work-around (3, Interesting)

Norsefire (1494323) | more than 5 years ago | (#28389809)

From the source:

if ( $delay < 166 ) {
print <<EOSUCKS2BU;
Since the timeout ended up being so small ($delay seconds) and it generally
takes between 200-500 threads for most servers and assuming any latency at
all... you might have trouble using Slowloris against this target. You can
tweak the -tcpto flag down to 1 second but it still may not build the sockets
in time.
EOSUCKS2BU
}

Lower Apache's timeout to below 166 seconds.

Re:Possible work-around (5, Funny)

Bootvis (913169) | more than 5 years ago | (#28389993)

The thing that is really amazing about this hack: Human readable perl!

Re:Possible work-around (1)

dword (735428) | more than 5 years ago | (#28390499)

If you understand "EOSUCKS2BU", you need to get laid.

Re:Possible work-around (2, Funny)

Anonymous Coward | more than 5 years ago | (#28390691)

Sex makes people stupid?

OpenBSD's pf has some mitigation features (2, Informative)

possible (123857) | more than 5 years ago | (#28389877)

OpenBSD's pf [openbsd.org] firewall has some options that can help mitigate the "single attacker, single source IP" version of this attack. Of course if the attackers decide to spread the attack out over multiple source IPs like a DDoS, this becomes much harder to deal with until Apache has a patch.

Filter rules that create state entries can specify various options to control the behavior of the resulting state entry. The following options are available:

max number
Limit the maximum number of state entries the rule can create to
number.
If the maximum is reached, packets that would normally create state
fail to match this rule until the number of existing states decreases
below the limit.
no state
Prevents the rule from automatically creating a state entry.
source-track
This option enables the tracking of number of states created per
source IP address.

The total number of source IP addresses tracked globally can be
controlled via the

src-nodes runtime option [slashdot.org] .

max-src-nodes number
When the source-track option is used,
max-src-nodes will limit the number of source IP addresses that
can simultaneously create state.
This option can only be used with source-track rule.
max-src-states number
When the source-track option is used,
max-src-states will limit the number of simultaneous state
entries that can be created per source IP address.
The scope of this limit (i.e., states created by this rule only or
states created by all rules that use source-track) is dependent
on the source-track option specified.

Re:OpenBSD's pf has some mitigation features (0)

Anonymous Coward | more than 5 years ago | (#28389925)

How about something useful like iptables instructions.

Re:OpenBSD's pf has some mitigation features (1)

santax (1541065) | more than 5 years ago | (#28390025)

Why don't you go ask that on the openbsd maillist? Be sure to use the Anonymous Cowardon name though, for extra lulz.

Re:OpenBSD's pf has some mitigation features (2, Informative)

El_Muerte_TDS (592157) | more than 5 years ago | (#28390051)

Something like:

iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j DROP

limits to 5 new connections per 60 seconds

Re:OpenBSD's pf has some mitigation features (3, Interesting)

raju1kabir (251972) | more than 5 years ago | (#28390201)

Many browsers will open more connections than this, resulting in "broken" image links on pages. I've tried all kinds of connection limits to protect against simple DOS attacks, but always have problems with corpororations whose standard desktop configs include IE/Firefox set to open way more connections than would be polite.

It becomes politically challenging to cause those users to have a problem, especially since they don't see it with other sites. The perception is always that my server has a problem, and it doesn't matter how clearly I explain what's actually happening and how inappropriate it is to have 1000 PCs all set to open 30 connections to each web site they visit.

Re:OpenBSD's pf has some mitigation features (0)

Anonymous Coward | more than 5 years ago | (#28390937)

I thought browsers were limited (by default) to 2 connections.

Re:OpenBSD's pf has some mitigation features (0)

Anonymous Coward | more than 5 years ago | (#28391275)

Why would you think that?

Re:OpenBSD's pf has some mitigation features (1)

garaged (579941) | more than 5 years ago | (#28390843)

a standard HTTP page this days makes something around 20 connections per page

Than would break a lot of pages, most of them

Re:OpenBSD's pf has some mitigation features (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28390337)

Since OpenBSD's version of httpd is basically a fork of regular Apache, has anyone tested this against OpenBSD's httpd?

Our system may be safe (3, Interesting)

cjb-nc (887319) | more than 5 years ago | (#28389991)

Obviously need to verify this, but we already run mod_cband [sourceforge.net] with a per-IP connection limit of 5. This is in place to stop the over-zealous "download accelerators" from taking all our connections and DOS'ing us. I expect it would stop a single attacker using this attack, but we'd still be vulnerable to a concerted attack by MaxChildren/5 IPs.

Lingering connections handling (3, Insightful)

moon3 (1530265) | more than 5 years ago | (#28390057)

If you keep lingerers for more then 160 seconds then no wonder this is possible.

It should be non-issues on better designed servers that keep an eye on connections anyway. Any single IP spawning lots of unfinished connections gets flagged fast and remembered for the future, so it will get limited access and bandwidth, marked as abuser etc. This is serving 101.

Re:Lingering connections handling (1)

FrozenGeek (1219968) | more than 5 years ago | (#28391377)

That creates the possibility of a new form of attack. Consider a website for a local business (pizza joint, etc). I have DHCP from the main ISP in the area. I attack the business's server using the attack from the article. The business flags my IP. I request a new IP from the ISP and do it all over again. Repeat ad nauseum. All those IPs that the business flagged because of me now get limited access at that server. But I'm not using those IPs. Other customers of the ISP (and the local business) are using them - with limited access.

Not a flaw, easily configured around (3, Informative)

Anonymous Coward | more than 5 years ago | (#28390091)

http://httpd.apache.org/docs/2.2/mod/core.html#timeout

The issue is that the default configuration waits 5 minutes for the full request, which is painfully to long a period of time. Drop that from 300 to 5, and the "attack" goes away. If you are running the default Apache config in production, you shouldn't be.

Re:Not a flaw, easily configured around (3, Informative)

ID000001 (753578) | more than 5 years ago | (#28390433)

http://httpd.apache.org/docs/2.2/mod/core.html#timeout

The issue is that the default configuration waits 5 minutes for the full request, which is painfully to long a period of time. Drop that from 300 to 5, and the "attack" goes away. If you are running the default Apache config in production, you shouldn't be.

seem like a potential fix, can anyone confirm?

Re:Not a flaw, easily configured around (2, Insightful)

TheLinuxSRC (683475) | more than 5 years ago | (#28390681)

From the article:

"...the server will open the connection and wait for the complete header to be received. However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated."

In other words.. the connection is not allowed to "timeout" as there is (bogus) traffic on the connection.

Re:Not a flaw, easily configured around (0)

Anonymous Coward | more than 5 years ago | (#28390763)

The timeout starts when the client initiates the connection. It isn't reset on each character received from the client.

Re:Not a flaw, easily configured around (2, Insightful)

dlgeek (1065796) | more than 5 years ago | (#28390921)

The problem with that is it will break nontrivial uploads using POST since they won't complete in 5 seconds. The real solution is to not count threads or connections below a certain utilization threashold towards the capped max and kill them once you hit real starvation.

Re:Not a flaw, easily configured around (1)

Cajun Hell (725246) | more than 5 years ago | (#28391309)

If you are running the default Apache config in production, you shouldn't be.

That's one of the most damning things you can say about a package.

HTTP hints at a solution (5, Informative)

greed (112493) | more than 5 years ago | (#28390101)

HTTP 1.1 [rfc-editor.org] specifies a status code for "Request Timeout" (408) and "Gateway Timeout" (504).

What is needed, therefore, is a timer running for receiving the complete header, and a second one for accepting the body. The timer for the body can be controlled by the type of request and the Content-Length header. (With, of course, a specific cap.)

Currently, Apache 2.2 [apache.org] has a single timeout value for all types of requests, but it is interpreted differently for the different types.

If your server only handles GETs, the obvious thing is to crank that number down. Unfortunately, for PUTs, the TimeOut value affects inter-packet time in the request, not overall request time.

Strangely, the timeout doesn't seem to run in 2.2.10 and 2.2.11 before data is received. Oh dear. That's an even simpler DoS.

#!/usr/bin/env perl

use IO::Socket::INET;
use strict;
use constant DEFAULT_PORT => "http";

MAIN: {
if(@ARGV<1 or @ARGV>2) {
die "Usage: $0 host [port]\n";
}
my($host)=shift;
my($port)=@ARGV?shift:DEFAULT_PORT;

my(@sockets);

for(my $cnt=0;$cnt<1000;++$cnt) {
my $socket=new IO::Socket::INET(PeerAddr=>$host,
PeerPort=>$port,
Proto=>"tcp");
unless(defined($socket)) {
die "Cannot create socket to $host:$port--$!\n";
}
$socket->print("\r\n");
push(@sockets,$socket);
print " Have ".@sockets." open.\n";
}
}

Not quite as stealthy, though. At least as above.

Re:HTTP hints at a solution (5, Funny)

greed (112493) | more than 5 years ago | (#28390823)

BTW, is there a self-mod value for "I'm not sure I should have posted that"?

Re:HTTP hints at a solution (1)

arjennienhuis (159927) | more than 5 years ago | (#28391433)

A HTTP response can not start until the whole request has finished. So sending a status code is impossible.

The same problem happens if you try to POST a file that is too large. The webserver knows this after the Content-Length header but cannot respond until after you send the whole file. The only thing the webserver can do is to close the connection.

Why wouldn't the following setting (1)

McNihil (612243) | more than 5 years ago | (#28390165)

mitigate it somewhat:

In httpd.conf

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 120

Unless of course this timeout is for after the header is received only... which I don't think it is... but as they say... assumption is the mother of all f*ckups.

Re:Why wouldn't the following setting (1)

The MAZZTer (911996) | more than 5 years ago | (#28390833)

When in doubt, pull out PuTTY and test it!

What a timely posting (not) (1)

BuhDuh (1102769) | more than 5 years ago | (#28390253)

2009-06-18 15:25:37 New Apache DOS Tool (Index,The Internet) (pending)

I can just hear the words... (1)

petrus4 (213815) | more than 5 years ago | (#28390319)

...of one of the 14 year olds who uses this, as she runs the script.

"Dodge this." ;)

It dont want to work for me (0)

Anonymous Coward | more than 5 years ago | (#28390457)

Apache 2.2.10 mpm_worker, anyone know how to set up that lil script to DoS it ? ive tried setting 10000 connections and its still dont want to stop working

DDOS! (1)

GNUPublicLicense (1242094) | more than 5 years ago | (#28390835)

Oh God! Apache web server having a security hole! Better write this day down. The others web servers have already an endless list of days written down, and they are not deployed like apache...

Ideal Fix (0, Redundant)

physburn (1095481) | more than 5 years ago | (#28390837)

The ideal fix, would be to have a variable timeout on open connection, depending on how many open ones there are. A simple thing like auto timing out the oldest connection once the a near maximum number of connections are open should be enough. Apache should also be limit the number of connections from any one IP address, to a small number. Hope these go in Apache soon.

Many othere services are probably vulnerable (1)

karl.auerbach (157250) | more than 5 years ago | (#28391103)

Sendmail and other servers are probably vulnerable to this kind of thing. And it is not necessarily the server application itself may not be where the core of the server slowdown occurs. For example, if one were to spread this kind of attack across several different types of TCP-based protocols (SMTP/SMTPS, IMAP(S), HTTP(S), DNS(tcp version), etc then the operating system's TCP engine might start suffer from too many TCP control blocks. (And it isn't just the memory occupied - some silly implementation might do a sequential scan rather than hash lookups when matching incoming packets to TCP connection blocks.)

There is another version of this kind of attack in which rather than sending incomplete data the attacker simply is extremely lazy about sending TCP ACKs - it does so only enough to keep the connection alive. Yet another alternative is that the attacker maintains a TCP receive window that is just a tad too small to contain what the attacked machine is trying to send back.

There is a flip side of this - one can build an email server that is closely integrated with the TCP stack so that incoming mail is validated while the TCP connection is open. Then if the incoming mail is bogus the machine can go into slow ACK/small receive window mode and try to constipate the TCP stack of the spamming machine. Unfortunatly that technique was more useful before hordes of bots were used as spam amplifiers.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?