Re: ICMPs & syn flood fix to prevent spoofing (previously "nuke?")

Juergen Weber (cowzilla@gwbbs.northeast.net)
Wed, 23 Oct 1996 08:06:01 -0500 (CDT)

I have been modifying my kernel for a while now, playing with the icmp
and route sections.. So far (it wasnt that hard) the changes I have made
were to ignore pings (lessens the effect of ping floods), and ignore all
unreacheable icmp types, except for the defragmentation needed type (type
4), which wont reset your connection anyway, and is probably needed to
maintain a connection with some sites. The modifications succesfully
prevent someone nuking you (when the packets are sent to your machine)...
Of course, the correct way to do this would be to read the sequence
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
closely at the tcp code yet)... If there is a match of the sequence
numbers, then it can be assumed that the icmp is legitamit and the
connection can be terminated. After all, if a host is unreacheable, why
would it be acknowledging our packets? So we should still have that
information lying around somewhere. I think BSD has already done
something like this. Another portion of the icmp code i have been playing
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?)

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
it more difficult for people to spoof to another machine, pretending to be
a linux machine that is currently on the net. It would allow the linux
machine to respond to requests that come from the machine the attacker is
spoofing to, and reset them (because they arent really there). I think
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)...

Thanks to anyone who takes the time to understand this .. :)

-Cowzilla

On Tue, 22 Oct 1996, Zachary Maas wrote:

>
> This may or may not have already been discussed on this
> list but i just recently joined it and have a question
> about linux and "nuke". Is anything being done to prevent
> the ability to "nuke" linux machines, in the sense of lets
> say knocking a user off a irc server sending a spoofed
> ICMP unreachable? Because i know with all Linux versions
> I have used up to and including 2.0.23 i can easily "nuke"
> myself or anyone else off if a irc server or otherwise
> using a program called snuke.c, the only way i have been
> able to prevent the ability of others to "nuke" me is to
> use ipfwadm to deny icmp's to port 3 (-S 0/0 3).
>
> Sorry if i do not have my terminology down pact but i hope
> atleast one person on this list follows me, hehe :)
>
> Thanks,
> Zachary Maas
>
> Ps. once again my apologizes if this subject has already
> been discussed and beaten into the ground on this list.
>