Hi
I would like to point who ever is in charge of the TCP stack for the linux
kernel at a site which claims to have a method of eliminate denial of service
(DoS) attacks
http://grc.com/r&d/nomoredos.htm
With my limited unstanding of TCP and DoS attacks this would seem to be the
answer, instead of a work around.
Cheers
Mike OConnor
Date: Fri, 22 Dec 2000 13:24:44 +1100 (CST)
From: Mike OConnor <[email protected]>
I would like to point who ever is in charge of the TCP stack for
the linux kernel at a site which claims to have a method of
eliminate denial of service (DoS) attacks
http://grc.com/r&d/nomoredos.htm
With my limited unstanding of TCP and DoS attacks this would seem
to be the answer, instead of a work around.
These people claim that no connection state needs to be saved for the
beginning of the negotiation, and I claim this is unworkable because
it ignores TCP timestamps entirely.
Furthermore, it also cannot work because it makes retransmissions
of the SYN/ACK very non-workable. I suppose his TCP stack just hacks
around this by just waiting for the original client SYN to get
retransmitted or something like this. I question whether that can
even work reliably.
I think not holding onto any state for an incoming SYN is nothing but
a dream in any serious modern TCP implementation. It can be reduced,
but not eliminated. The former is what most modern stacks have done
to fight these problems.
Later,
David S. Miller
[email protected]
This has already been discused here and on slashdot, on 9/25/2000.
On Fri, Dec 22, 2000 at 01:24:44PM +1100, Mike OConnor wrote:
> I would like to point who ever is in charge of the TCP stack for the linux
> kernel at a site which claims to have a method of eliminate denial of service
> (DoS) attacks
>
> http://grc.com/r&d/nomoredos.htm
<snip>
--
Tom Vier <[email protected]>
DSA Key id 0x27371A2C
Not only is this a well written article, and clearer than most other
documents (Even Mine :>) but he is dead on track with his basic concepts..
Exactly what I have been looking into over at our company. (Well, close
enough)
The concept of trusting a SYN packet, has to go.. we have to assume that it
is false/bad, and only after receiving the ACK in reply to our SYN/ACK can we
start assuming that the previous packets were good..
All IMHO.... Nice find and a good read for anyone..
I am CC'ing the netfilter list as they might like the read.. in case they
haven't read it. (Surprised I haven't seen more discussion on this topic)
On Thu, 21 Dec 2000, Mike OConnor wrote:
> Hi
>
> I would like to point who ever is in charge of the TCP stack for the linux
> kernel at a site which claims to have a method of eliminate denial of
> service (DoS) attacks
>
> http://grc.com/r&d/nomoredos.htm
>
> With my limited unstanding of TCP and DoS attacks this would seem to be the
> answer, instead of a work around.
>
--
--------------------------------------------------------
Michael Peddemors - Senior Consultant
Unix?Administration - WebSite Hosting
Network?Services - Programming
Wizard?Internet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)?589-0037 Beautiful British Columbia, Canada
--------------------------------------------------------
> Furthermore, it also cannot work because it makes retransmissions
> of the SYN/ACK very non-workable. I suppose his TCP stack just hacks
> around this by just waiting for the original client SYN to get
> retransmitted or something like this. I question whether that can
> even work reliably.
Be interesting to see his response, but in truth, do we care if it gets
retransmitted?? When it does, it does...
> I think not holding onto any state for an incoming SYN is nothing but
> a dream in any serious modern TCP implementation. It can be reduced,
> but not eliminated. The former is what most modern stacks have done
> to fight these problems.
A dream, maybe .... but hey so were most things that we now take for granted..
Worth kicking around a bit tho...
--------------------------------------------------------
Michael Peddemors - Senior Consultant
Unix?Administration - WebSite Hosting
Network?Services - Programming
Wizard?Internet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)?589-0037 Beautiful British Columbia, Canada
--------------------------------------------------------
On Fri, Dec 22, 2000 at 01:24:44PM +1100, Mike OConnor wrote:
> Hi
> I would like to point who ever is in charge of the TCP stack for the linux
> kernel at a site which claims to have a method of eliminate denial of service
> (DoS) attacks
> http://grc.com/r&d/nomoredos.htm
> With my limited unstanding of TCP and DoS attacks this would seem to be the
> answer, instead of a work around.
Obviously written by someone with no real world experience with
DoS attacks. He seems to think that the majority of DoS attacks are SYN
floods and disregards all the rest by saying this will eliminate
DoS attacks. In fact, SYN floods have been largely ineffective for
some time now and comprise a very small percentage of attacks now.
From all appearances, his approach would have no effect on attacks
like NAPTHA which try to take advantage of more advanced states in the TCP
state machine.
He actually should take a look at the "Cookie Crumbs" attacks
against ISAKMP/IKE (IPSec) which suffer from the same first packet
saved state problem. Those guys haven't solved that problem and that's
even a security protocol! Maybe he could be some help there (or learn
something).
We probably see more incidents of TIES bombing (sending packets
with "\r+++ATH0\r" in payloads) to hang up modems than we see SYN
flooding lately (IMHO). I recently helped and ISP that was virtually
shut down by someone TIES bombing them with ping packets containing the
TIES hangup sequence. Once we got THEIR modems fixed, the TIES bombs
were hanging up their customers modem's (the ICMP Echo Reply) and we
had to design a TIES Bomb packet that would reset the vulnerable
customer modems to a safe S register value... Grrr...
Quite frankly... My favorite DoS attack is NISNuke (which
I researched and documented). His approach would have exactly zero
effect in mitigating an NISNuke attack and I can take out and entire
network with it (all you need is NIS and finger on the same large network).
So he can NOT claim to eliminate DoS attacks since I have a small arsenal
of them which would be untouched by his approach.
While some DDoS (Distributed Denial of Service) attacks do
incorporate SYN flooding, their most profound effect is in the bulk
attack areas such as Smurf flooding (ICMP echo to broadcast addresses
while spoofing the return address as the targeted party) and UDP data
overloads. Those have other solutions (such as router filters which
prevent spoofing) which we can't even get implimented, much less
a tcp stack state machine redesign!
He's got a solution (and an ineffective one at that) that's
really in search of a problem. It's highly unlikely that it would even
make a miniscule dent in the DoS problem. That's even assuming that
it would work (which others such as Dave Miller have stated that it
wouldn't).
He gets a "nice try" but in the long run it boils down to the
expression in the IETF... You vote with working code. Let's see the
code in operation and see how it works and stands up. If it works and
it more robust in the face of ongoing attacks, all hail! Kudos for
all around. If not, then don't tell us how it should be. Demonstrate
with working code. I didn't seen ANYTHING on that site but a description
of how he thought it should work. Vote with working code...
> Cheers
> Mike OConnor
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
From: Michael Peddemors <[email protected]>
Date: Thu, 21 Dec 2000 20:20:06 -0800
> I think not holding onto any state for an incoming SYN is nothing but
> a dream in any serious modern TCP implementation. It can be reduced,
> but not eliminated. The former is what most modern stacks have done
> to fight these problems.
A dream, maybe .... but hey so were most things that we now take for granted..
Worth kicking around a bit tho...
At a minimum you have to remember the MSS value given by the remote
host in the initial SYN, it is impossible to avoid this and provide
a TCP implementation of any level of quality.
The foundations of this person's scheme simply cannot work.
Later,
David S. Miller
[email protected]
Hello!
> http://grc.com/r&d/nomoredos.htm
>
> With my limited unstanding of TCP and DoS attacks this would seem to be the
> answer, instead of a work around.
More elaborated version of this "answer" is used in linux for ages
under name of syncookies. The approach, proposed here, is a bit different
technically of syncookies, but adds nothing new in result.
Moreover, it loses such crucial property of syncookies as mss negotiation
(which can be fixed of course).
Alexey