[4930] in North American Network Operators' Group
Re: New Denial of Service Attack on Panix
daemon@ATHENA.MIT.EDU (Tim Bass)
Wed Oct 2 17:34:10 1996
From: Tim Bass <bass@cais.cais.com>
To: bass@cactus.silkroad.com (Tim Bass)
Date: Wed, 2 Oct 1996 17:19:21 -0400 (EDT)
Cc: kwe@6SigmaNets.com, bass@cactus.silkroad.com, nanog@merit.edu,
iepg@iepg.org
In-Reply-To: <199610022111.RAA01111@cactus.silkroad.com> from "Tim Bass" at Oct 2, 96 05:11:47 pm
Nevermind.....
I've been working on the non-random attack first.... I
apologize for wasting everyones time when the approach
below does nothing for the random() attack.
Staying up too late in the lab, I guess.
Best Regards,
Tim
>
>
> Hi.
>
> I've been testing the SYN attack on with 'the patch'
> with no success of stopping the attack so far with the
> patch (right now, without the patch it is DoA and with the
> patch, the attack panics the kernel :.... but this is more-than
> likely an implementation issue that will be solved.
>
> However, I was thinking (dangerous, admittedly) that since
> the success of the attack is based on using an UNREACHABLE
> source address and the host under attack attempts to
> ACK/SYN with the bogus attacker wouldn't it be easier to:
>
> Just have either (1) a listening daemon; (2) or an internal
> flag in the kernel, (3) or some other better IPC, to notify
> TCP, or better yet, IP to say: "Hey, there is a lot of
> HOST UNREACHABLES going on here, and I don't like it"
> algorithm to either (a) just filter the IP packets
> at in the kernel IP code, (best IMO) (b) or do it
> in the TCP code?
>
> This seems simple, so I must be missing something in this!
>
> Because, it seems to me, since the way to exploit TCP
> is to use bogus, unreachable IP sources, why not use
> this fact to let the kernal just filter itself under
> certain flooding conditions?
>
> Please let me know why this will not work.
>
> Thanks,
>
> Tim
>
>
>
