httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Testuser <>
Subject Re: [users@httpd] How to prevent from simple DoS?
Date Thu, 22 Nov 2007 09:35:09 GMT
On Wed, Nov 21, 2007 at 02:53:11PM -0500, Joshua Slive wrote: 
> DDoS is a read herring as far as I'm concerned.  
> If you have an attacker with a significant DDoS network there is 
> NOTHING you can do to stop them. They can simply send junk down the 
> line to tie up your network connection. No tool can prevent that.

Now this sounds a bit too fatalistic in my ears. 

It's not that you are completely wrong. But there ARE things that you
can do and it does not help it, if you give up immediately. And it is 
not what I would like to tell my boss, when things get stiff.

Application level DoS/DDoS is nasty and I think there is little knowledge
to be found. Or if there is know-how, then it is well hidden or I am
stupid. I have cited Mirkovic/Dietrich et. al, Internet DoS before. It's
a 2005 book of about 350 pages and within this book half a page deals
with application level attacks. Most of the rest is about network level
attacks. I might be exaggerating here, but I think my point is basically
valid: There is not enough knowledge on application level DoS/DDoS and
the best defense strategies.

Defending boils down to analysis and locking the attackers out. So you
need to know _that_ you are attacked and _who_ is attacking you. Then
you need to _lock the attackers out_.

Let's start with the simple part: As with many attacks, locking the
attackers out should be done as far from your server as possible. On a
proxy, an IDS/IPS, a firewall, a router or - if you are really important -
on the ISP level, the carrier or where the traffic hits your continent.
Think of blacklists, blackbox routing, tarpit routing, etc. And set up a
desaster plan, where you whitelist your most important clients and lock
out every body else. GeoIP!

This is a lot of work and it might cost a lot of money.  The more
determined the attacker, the bigger his means, the more difficult
 locking him out will be.

Back to the difficult part: How to know that you are attacked? If you
 are flooded with requests, then it's a matter of monitoring your logfiles
and alarming accordingly. But if you are facing the attack pattern,
that stood at the beginning of this thread, then the regular logfiles
will leave you in the dark. You can tell from looking at netstat, but
that is not very elegant. I wish apache would tell me.  I wish I could
push a button and apache would tell me when he accepts a connection
and when a change in the lifecycle of a request occurs. Calculate the
difference of accepted connections and finished connections (access
 log) over a given period and you know you are being attacked. (mod_forensic 
is close to this, but not quite.)

So now you have made up your mind: you are being attacked. But how to
tell friend from foe? Again, you lack the reconnaissance with Apache.
 You are blind as to which clients are fast and which ones seem to slow down
the requests. You do not see if an ssl handshake takes longer than it
usually does. There is no way to tell if an attacker slows down a file
upload with trickling TCP packets coming in at the rate of your
 timeout, etc.

To tell friend from foe in such a situation takes an awful lot of
information and apache does not give a sysadmin this information. Maybe
the attacker will be stronger in the end. But I would like to sell my
skin at the best price possible. It's better to try and keep up and
running than it is to give up immediately.  And assuming that there is
a trend towards application level DoS, then it would be an advantage for
apache if it would help the defender more than competing products. In
 my eyes, apache is the most flexible webserver around. Successful defense
has a lot to do with flexibility and reconnaissance. Even for apache,
there is room for improvement in this regard.

No I do not want to sound like I am complaining about apache. The code
 is there, it's open and I can go and write the patch/module it takes. But
I know I am a weak coder and there is no lack of projects I am running
in parallel. So I am trying to raise the awareness.

I would be happy to contribute thoughts (there are some more) and
a casual line of code here and there. I would love to enter a long
discussion and many hours in a lab to find out more about the defense
strategies. There are things you can do. Most won't help, but some will
give you an advantage over immediate death.

 For ideas on reducing your carbon footprint visit Yahoo! For Good this month.
View raw message