2009.09_Apache Httpd-Denial of Service Made Easy.pdf

(227 KB) Pobierz

594281800 UNPDF

SYSADMIN

Security Lessons

APACHE HTTPD

A slow death for the default configuration. BY KURT SEIFRIED

sites C through Z aren’t quite sure what

they’re doing. However, the web server

seems to work pretty well, so why worry

about the defaults? The operating system

vendors don’t really want to change the

defaults on all the software they ship un-

less they have a good reason to do so be-

cause it’s one more thing to do. Addi-

tionally, it means your software could

behave unexpectedly, resulting in sup-

port calls that no one wants to deal with,

especially if they’re a volunteer-driven

organization. So you’ll just have to trust

the software project to choose sane de-

faults, which is probably for the best be-

cause they understand the software and

what twiddling the knobs can break.

Therefore, you end up with defaults that

work for most people, assuming nothing

strange happens – like 1,000 or more cli-

ents on really slow network connections

hitting your server at the same time.

not be historically accurate, but is

close enough, you want to build a

web server, so you program a socket-

based server. A client connects, requests

a file, you send the file, the client discon-

nects, and everyone is happy. The total

transaction time is around 300 millisec-

onds. But you get a bug report that some

guy’s web server keeps getting slower

and slower until it eventually dies. What

to do? After diagnosing the problem, you

figure out that some web clients aren’t

handling the connection properly. They

create a connection but then do nothing

with it, leaving it open indefinitely. The

result is that the server slowly runs out

of available connections until it can no

longer service new requests. The fix is

easy: Just stick in a default TimeOut di-

rective so actions that tie up resources

(like a connection) eventually get killed

off if they aren’t actually doing anything.

This works pretty well for a while, but

you start noticing that web pages are

taking lon-

ger and longer to load because they are

no longer a single page but contain im-

ages, CSS files, JavaScript files, and so

on. So being a smart programmer, you

figure to let the client keep the connec-

tion alive and re-use it for additional re-

quests. This solution is good because it

avoids the setup cost of the connection

(a TCP three-way handshake [1] takes

time). Now the second (and third, and

fourth) file request is a lot faster, and ev-

eryone is happy. Because you learned

from your last mistake, you put a Keep-

AliveTimeout directive to prevent prob-

lems. Life is good, people download

your web server, and pretty soon 60% or

so of the web is using the Apache

HTTPD server.

Sane Defaults

Defaults are one of the most annoying

problems because, quite simply, no de-

faults work well for everyone. Site A

could be serving millions of small im-

ages, whereas site B wants to serve

things using a

big applica-

tion frame-

work,

and

So What Happens When …?

If 1,000 clients on really slow network

links (or one client with 1,000 connec-

tions pretending to be on a slow network

link) hit your server all at once, it turns

out that your server stops working.

Rather, it still works, but it is limited by

how many connections it can serve, So

even if serving 1,000 slow connections

doesn’t take a lot of resources, your

server has no more available connec-

tions to serve other legitimate clients. To

the world, your server appears to be

dead. This situation is a problem be-

cause a user with a clever piece of soft-

ware like Slowloris [2] can attack a large

site from a single computer on a rela-

tively small network link (i.e., DSL or a

cable modem).

But shouldn’t this be easy to fix by

simply limiting how many connections a

single IP address or a network block can

create and hold open? If you set this

limit low, you might block users that are

forced to use web proxies. AOL, for ex-

ample, forces all users through web

proxies (which saves them a ton of

money on bandwidth). In many legiti-

mate cases, a single IP address or a

52

ISSUE 106

SEPTEMBER 2009

Denial of service made easy

I n a thought experiment that might

594281800.051.png

594281800.062.png

594281800.073.png

594281800.084.png

594281800.001.png

594281800.002.png

594281800.003.png

594281800.004.png

594281800.005.png

594281800.006.png

594281800.007.png

594281800.008.png

594281800.009.png

594281800.010.png

594281800.011.png

594281800.012.png

594281800.013.png

594281800.014.png

594281800.015.png

594281800.016.png

594281800.017.png

594281800.018.png

594281800.019.png

594281800.020.png

594281800.021.png

594281800.022.png

594281800.023.png

594281800.024.png

594281800.025.png

594281800.026.png

594281800.027.png

594281800.028.png

594281800.029.png

594281800.030.png

594281800.031.png

594281800.032.png

594281800.033.png

594281800.034.png

594281800.035.png

594281800.036.png

594281800.037.png

594281800.038.png

594281800.039.png

594281800.040.png

594281800.041.png

594281800.042.png

Security Lessons

SYSADMIN

group of IP addresses

in a small network

might open a lot of

connections (e.g.,

those IPs might be

every single AOL user

in the American Mid-

west). The problem

here is that you need

to find a limit that will

prevent damage to

your server yet is high

enough that it is un-

likely to block legiti-

mate users. My advice

is to set the limit as

high as possible (i.e.,

where it affects your

server but doesn’t

completely kill it) to

avoid blocking as

many users as possible.

One generic way to rate limit connec-

tions per IP address is to use the iptables

rate-limiting facility, which can be done

selectively on single ports. Also, you can

specify a block of time and the maxi-

mum number of connections that can be

established in that time frame. The fol-

lowing code creates a 60-second block

with a maximum of five connections. On

the sixth or more, it will simply DROP

the packets, causing the client to retry.

Once an earlier connection closes, the

new one will be allowed.

probably because of Michael Jackson’s

death, but it’s loading the page text so as

not to be completely useless.

An example of this is a third-party

patch from Andreas Krennmair [4]. His

patch adds load percentage monitoring

with the use of the Apache HTTPD

scoreboard. As load increases, the time-

out is adjusted. At 60% load, it halves

the timeout; at 70%, it quarters it; and

so on. Although simplistic, it is a good

example of building some intelligence

and a “survival” instinct into the appli-

cation; unfortunately, it cannot close ex-

isting connections, so with enough re-

sources, an attacker can still cause the

machine to become unresponsive.

Figure 1: Slowloris is named for a slow-moving primate with a

very tight grip.

To Infinity and Beyond!

The true irony of these slow denial of

service attacks that take up connection

handling resources is that they don’t ac-

tually cause the server to run slowly in

most cases. They simply prevent legiti-

mate clients from being able to connect

to the server because no connections are

available. And if any do become avail-

able, the attacker can aggressively at-

tempt to connect to them, beating legiti-

mate clients. The additional benefit to

fixing applications so that they can deal

gracefully with these denial of service at-

tacks is that it will also help them handle

higher loads of legitimate traffic – a win

for everybody. n

cally 300 seconds, or five minutes) to a

much shorter five seconds – or less if

need be. Additionally, to prevent abuse

of http keep-alive, you can simply dis-

able it by setting the KeepAlive directive

to off. Please note that neither of these

workarounds will actually fix the prob-

lem in a very meaningful way, but

against attackers with limited means, it

should help [3]. Also note that this at-

tack doesn’t just affect the Apache

HTTPD server: The Squid web proxy and

a number of other web servers are also

vulnerable to the Slowloris attack.

iptables -I INPUT -p tcp --dport 80 U

-m state --state NEW -m recent --set

iptables -I INPUT -p tcp --dport 80 U

-m state --state NEW -m recent U

--update --seconds 60 --hitcount 6 U

-j DROP

Long-Term Needs

Although you will never be able to com-

pletely mitigate the risk and effect of de-

nial of service attacks (in a worst-case

scenario, a botnet sends legitimate re-

quests that soak up your available re-

sources), you can build systems that can

survive small attacks and force attackers

to spend more resources on attacks,

which you hope will discourage them.

The best long-term solution appears to be

building better rate-limiting functionality

into applications and, most importantly,

allowing these applications to change

their settings as needed if they come

under attack (e.g., reduce the connection

timeout as they become busier and start

kicking off slow hosts if they get maxed

out). In this way, you will give applica-

tions the best chance of surviving not

only denial of service attacks, but heavy

workloads. For example, as I write this,

CNN.com is looking slightly broken,

INFO

[1] TCP three-way handshake:

http://en.wikipedia.org/wiki/

Transmission_Control_Protocol

[2] Slowloris http DoS: http://ha.ckers.

org/slowloris/

[3] Apache Security Tips:

http://httpd.apache.org/docs/trunk/

misc/security_tips.html#dos

[4] Anti-Slowloris patch for Apache

HTTPD: http://synflood.at/tmp/

anti-slowloris.diff

Of course, a determined attacker will

simply use more machines, eventually

saturating your attempt to rate limit, but

you can make their job significantly

harder.

Trading Performance for

Survivability

If you’re unwilling or unable to spend

money and deploy more hardware and

software to soak up denial of service at-

tacks, chances are you can trade perfor-

mance for added survivability. To deal

with the Slowloris attack, the quickest

and somewhat effective action is to set

the TimeOut value from its default (typi-

Kurt Seifried is an

Information Secu-

rity Consultant spe-

cializing in Linux

and networks since

1996. He often won-

ders how it is that technology works

on a large scale but often fails on a

small scale.

SEPTEMBER 2009

ISSUE 106

53

594281800.043.png

594281800.044.png

594281800.045.png

594281800.046.png

594281800.047.png

594281800.048.png

594281800.049.png

594281800.050.png

594281800.052.png

594281800.053.png

594281800.054.png

594281800.055.png

594281800.056.png

594281800.057.png

594281800.058.png

594281800.059.png

594281800.060.png

594281800.061.png

594281800.063.png

594281800.064.png

594281800.065.png

594281800.066.png

594281800.067.png

594281800.068.png

594281800.069.png

594281800.070.png

594281800.071.png

594281800.072.png

594281800.074.png

594281800.075.png

594281800.076.png

594281800.077.png

594281800.078.png

594281800.079.png

594281800.080.png

594281800.081.png

594281800.082.png

594281800.083.png

594281800.085.png

594281800.086.png

594281800.087.png

594281800.088.png

594281800.089.png

594281800.090.png

594281800.091.png

594281800.092.png

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin