Messages in this thread |  | | Date | Wed, 23 Oct 1996 08:06:01 -0500 (CDT) | From | <> | Subject | Re: ICMPs & syn flood fix to prevent spoofing (previously "nuke?") |
| |
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. >
|  |