RE: Diff ways to prevent DoS and DDoS

["David Gillett" <gillettdavid () fhda edu>]

Littlefield, Tyler [mailto:tyler () tysdomain com] wrote:

> > What are the different ways to prevent DoS and DDoS other than checking
the frequency or having a CAPTCHA??
> >
> A DOS or DDOS is a denial of service attack, or distributed denial of
service attack. You appear to be on a different wave length here, so I
wanted to throw that out.

  Agreed.  I don't see any way that a CAPTCHA mitigates against DoS/DDoS
attacks, which suggests that the question arises from some confusion...


> DDOS and DOS is done usually by flooding a service or application with
packets.


  The "security triad" (mnemonic CIA) is Confidentiality, Integrity,
Availability.  A DoS attack is against the Availability of the target, no
matter how this is accomplished.
  MANY DoS/DDoS attacks work by starving services of resources they need.
In the most trivial brute-force case, a flood of packets uses up all of the
target's available bandwidth -- but if the attack is sourced from a single
point, there's a risk that it will exhaust the attacker's own bandwidth
first.  In the case of a SYN flood, it's session descriptors that are
exhausted, perhaps leaving plenty of bandwidth unused but unusable.  Other
resources that could be attacked are things like CPU cycles, packet
reassembly buffers, etc.  Theoretically one could try to exhaust or
monopolize any finite resource, although for instance the pool of available
ephemeral port numbers is large enough to make them an impractical
target....
  Cache entries *shouldn't* be a useful target, but I used to work with some
routers where worms scanning for fresh victims would routinely exhaust the
route cache so that no packets could flow until entries managed to age out
(and the worm often consumed the freed entry before legitimate traffic
could...).  This is an example of a DoS attack as an unintended side-effect
of something else.
  Very early in my programming career, I coded my own JCL for a batch job on
an IBM mainframe, and accidentally took exclusive control of a crucial
shared system library.  (The system should not have been configured to
permit me to do that....)  There was no "flood", but there was only one
instance of this critical resource, and until I realized my error and killed
my task, nobody else's jobs could run.

  There have also been examples of network gear or servers that would reboot
themselves when hit with a specially-crafted packet.  Rebooting takes, in
network terms, nearly forever -- a series of packets that nobody would call
a "flood" might be sufficient to render the target unavailable for its
intended purpose -- the definition of a DoS attack.

  SO:  Basic strategies for preventing resource starvation attacks:

1.  Provide more resources than an attack can consume.  (Rarely practical,
especially if the attacker could have access to a botnet or the like...)

2.  Limit the rate at which any single task can consume critical resources.
(Cisco, for instance, has options to rate-limit SYN packets, rendering
SYN-flood attacks much less effective.)

3.  Recognize and block DoS/DDoS traffic before it can reach its target.
(Recall my example of the attacker consuming all of their own bandwidth?  A
"good" DoS attack impacts its target, but not the infrastructure on the way
there.  So if that infrastructure can be the best place to detect and block
the attack -- this is why the key to mitigating many DoS/DDoS attacks is
"Work with your ISP or upstream provider(s)".

David Gillett, CISSP


------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------