Date: Sun, 4 Apr 2004 20:38:31 +0100 (BST) From: Richard Wendland <richard@starburst.demon.co.uk> To: andre@freebsd.org (Andre Oppermann) Cc: freebsd-net@freebsd.org Subject: Re: Fwd: [IPv4 fragmentation --> The Rose Attack] Message-ID: <200404041938.UAA07933@starburst.demon.co.uk> In-Reply-To: <406B3CC0.C277B933@freebsd.org> from "Andre Oppermann" at Mar 31, 2004 11:48:48 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> We have the following sysctl's to withstand such an attack: > > net.inet.ip.maxfragpackets [800] > net.inet.ip.maxfragsperpacket [16] > Of course, when the maxfragpackets limit is reached by malicous > packets we are unable to process legitimate fragmented IP packets > until the malicous ones start to time out. There is nothing else > one can do to fight off such an attack. It would be possible to improve matters somewhat by having per-protocol limits. So for TCP, which with MSS and DF rarely fragments, there could be low limits. But for UDP (eg for NFS) which frequently fragments, there could be generous limits. So systems that only permit TCP and ICMP from non-trusted hosts could in an indirect way limit external attack, without eg hampering local UDP. This idea isn't even much of a layer violation, as the fragmentation id value is per protocol, so IP reassembly already takes account of which higher level protocol is involved. It would be reasonable to argue this is too inelegant for only a small improvement; and not worthwhile. What do you think? Taking this approach further would have packet filter rules controlling fragmentation limits. But that's adding a lot of complexity. NB Strictly shouldn't 'maxfragsperpacket' be 'maxfragsperdatagram' :-) Richard -- Richard Wendland richard@wendland.org.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404041938.UAA07933>