lkml.org 
[lkml]   [1996]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: ICMPs & syn flood fix to prevent spoofing (previously "nuke?")
Date
> number from the portion of the packet that is returned in legitamit icmp
> unreacheables, search for it in the queue of recently sent, but
> unacknowledged packets (there IS one of these right? I havent looked

Yes but each retransmit has a different IP packet id - as with BSD because we
issue new window/ack information.

> information lying around somewhere. I think BSD has already done
> something like this. Another portion of the icmp code i have been playing

I've not seen such changes, but I'd be happy to add contributed code that
smart checks the body of ICMP errors to see if they look real. It will stop
the most clueless. At the end of the day only the beating of sense into big
providers to filter fake source addresses coming FROM their networks will
solve these problems for good. Unfortunately it doesn't make them thousands
of dollars so they don't seem to give a shit.

> around with is the icmp redirect section. I have been attempting to add
> routes to my own machine by sending out spoofed icmps, but the test to add
> the route always seems to fail when it comes to the
> ((gw^dev->pa_addr)&dev->pa_mask) test in the ip_rt_redir function of
> net/ipv4/route.c... Does anyone know what the purpose of this test is and
> whether or not it is working correctly? Or even who I should contact (is
> there a maintainer for the icmp section of the linux networking code?)

The check works out if the route being added is sensible. A redirect of
another nondirectly reachable address is nonsense. That line is an optimised
version of

if((dev->pa_addr&dev->pa_mask)==(gw&dev->pa_addr))

> One final thing: I would also think it would greatly help linux's image
> if the syn flood protection patch became a standard feature of the kernel
> (the strong one that uses encryption to generate munged sequence numbers
> instead of dropping random connections from the queue). This would make

The encryption based one doesnt currently work right. It breaks big windows,
TTCP some stacks etc. I've been intentionally avoiding it.

> BSD solved this by separating the syn queue from the syn/ack queue (again
> im not sure about this since i havent looked at the tcp code yet, and plus
> i only heard this secondhand on irc, it may even be a rumor)...

BSD is vulnerable to the SYN attack. Even vendor patched BSD if you do it right.
The two patches around

1. Keeps compact state and long queues with drop (BSDI approach) - works well
2. Encrypted checksum approach - 'mostly works' - but we dont really want weird
errors

Alan


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.125 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site