From: Stephen D. Williams (sdw@insta.com)
Date: Thu Feb 24 2000 - 20:29:48 PST
Cynthia Dale wrote:
> it does not completely eliminate the problem. I have been taken down (my
> chicago box) many times, easy as pie, with the current tcp floods. All
> ICMP and UDP (besides DNS) is filtered at the backbone, but alas, I cannot
> allow anyone on IRC because of being flooded (read: can't offer shell
It is probably worth my looking into this if I come accross a comprehensive
description of what was used recently. I have a fair amount of firewall and
security background (I finished the first Bank Of America firewall and put up their
first web server).
SYN attacks were insidious because a small number of packets could cause severe
indigestion in most OS's at the time: they would stack up pending open connections
until internal limits were reached thereby ignoring new real connections or
dropping dead. The SYN cookie defense just prevents this internal OS problem.
If you are truly flooded with traffic, regardless of type, you will have a DDoS.
This can easily happen if you don't have much of an Internet link or your servers
can't handled high packet rates. Someone with access to one or more high speed
connections can flood a slow connection without even producing noticable traffic.
This will not be preventable easily without network support for auto-squelching,
quotas, or other traffic validation which will be difficult to get in place.
The description of the recent attacks that I noticed were a bit more cryptic. It
may have been a raw data stream, augmented by coming from multiple locations
including cracked sites. It may have been based on some bug that caused cascading
response traffic, as was suggested.
> accounts). AFAIK, the only way to truly fix this is to go to ipv6, which
> does not have the bug that allows spoofing. If I'm misunderstanding this,
Part of the point of SYN cookies is that it makes the sender prove that they are
really receiving the response packets. Maybe pushing SYN cookie spoofing further
into the network's routers would be a possible solution.
> that's okay, I'm used to misunderstanding things. (: However, the only
> real solution to the problem atm is to log, communicate, and prosecute.
Difficult to implement in general.
>
> The problem with this is that there are so many different ways to
> communicate with others about thisproblem, and, because of the spoofing,
> it is very hard to find out who initiates the attack. And then there's
> the issue of responsibility. If I leave my systems all insecure and they
> are hacked and used in a DDoS, am I liable? What if my system/network was
> compromised by a bug not known/patched? Am I still liable? What if I
> don't log all the things needed to catch/prosecute someone? Am I liable?
> And last, but not least, how can I capitalize on this? -wink-
> C
I think this is stretching it. If a villian breaks into my house and shoots my
neighbors am I liable for not shooting the intruder first?
If I leave a shovel laying in the garden and someone steals it to bash my neighbor,
have I provided a deadly weapon in a crime?
What about rocks in my soil? Boards that can be pulled from my house? Paver
stones light enough to lift?
That's stretching negligence a bit too far.
sdw
> On Thu, 24 Feb 2000, Stephen D. Williams wrote:
>
> > Manoj Kasichainula wrote:
> >
> > > On Thu, Feb 24, 2000 at 11:16:04AM -0500, John Klassa wrote:
> > > > Instead, Microsoft suffered what Sohn called a ``syn-flood'' attack
> > > > that disrupts communication between a PC and the Web site server so
> > > > that the server continually sends requests asking for the visiting
> > > > computer's identification, devouring its processing capacity.
> > >
> > > I don't know the technical details (sigh; first step to becoming a
> > > manager), but aren't there already pretty effective workarounds to
> > > work around SYN floods? I know that I was able to enable SYN cookies
> > > and RST cookies to alleviate the problem more than 3 years ago.
> > >
> > > If so, what's the big deal?
> >
> > Yes, Linux for instance supports SYN cookies that completely eliminates the
> > problem. Packets will be responded to once and then forgotten.
> >
> > The other recent attacks were not SYN flood related AFAIK.
> >
> > sdw
> >
> > --
> > Insta.com - Revolutionary E-Business Communication
> > sdw@insta.com Stephen D. Williams Senior Consultant/Architect http://sdw.st
> > 43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax Jan2000
> >
> >
> >
>
> Cynthia J. Dale
> Technical Engineer/FAQ maintainer
> Red Hat, Inc.
>
> fnord.
-- Insta.com - Revolutionary E-Business Communication sdw@insta.com Stephen D. Williams Senior Consultant/Architect http://sdw.st 43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax Jan2000
This archive was generated by hypermail 2b29 : Thu Feb 24 2000 - 20:36:54 PST