From: Cynthia Dale (silly@redhat.com)
Date: Fri Feb 25 2000 - 01:23:06 PST
On Thu, 24 Feb 2000, Stephen D. Williams wrote:
> 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.
No, that is what I'm saying. Use, say, uhm, slice <?> i think, against
your own box and see what would happen. Oh wait, but then you'd need a
broadcast list. Now, just where could you get one of those? (: I
remember when the kernel was fixed to send out cookies on S"YN attacks,
but this is a mutant outside of what the kernel is capabel of (not really,
this is just my persepctive as a tech; the kernel is the current kernel,
that sort of thing). What you say below is not true. See it.
> If you are truly flooded with traffic, regardless of type, you will have a DDoS.
huh? I can flood you with traffic, of many types, alone, by myself, if I
wished (to lose my jobs -smile-). Lemme know if I'm wrong, but the way I
understand it is that something like a smurf or so would not be a DDoS,
but if we were all linked up, and when i hit smurf command on my box,
other boxes would also do the same, this is DDoS. I studied this on a
small level with botnets. I hubbed a net of 12-512, (but backed the fuck
out of it when they started adding shell ping commands, sus to root, etc)
That's when almost no bots were allowed on EFnet, and ran into probelms
selling shell accounts because of my past involvment with something that
seemed fun and not really harmful. Anyhow, if I misunderstand, lemme
know. (:
> 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.
>
No. They killed nap net. Probly 1 or 2 kids, that's all. They could do
the same shit to yahoo and whatever has been hit with the DDoS attacks,
but it doesn't matter what you have unless you have what I now have, which
is a box on a multi-homed oc3... -beam-
ahem, anyhow, it doesn't metter what kind of line you have unless you have
something SUPER fast!@#
> 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.
> > 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?
maybe.
>
> 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.
If a child climbs your privacy fence and drowns in your pool, you are
liable. You are not paranoid enough about the things that you can be
liable for. I suggest a good dose of Vonnegut (RIP!) and RA Wilson.
drunkenly and happily on vacation,
Cindy
>
> 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
>
>
>
Cynthia J. Dale
Technical Engineer/FAQ maintainer
Red Hat, Inc.
fnord.
This archive was generated by hypermail 2b29 : Fri Feb 25 2000 - 01:26:16 PST