Hi. I'm reading ipchains-howto and have some questions... - I've compiled 2.2.17 kernel and set the appropiated options for firewall implementation. But.. I couldn't see any "IP: always defragment" option. :-?? I think it's an old option, isn't it?? (it sounds familiar to me when using 2.0.x kernels). - If I choose a default restricting policy (-P deny), which is the more secure one, how could I handle fragmented packets? I mean, let's suppose all packets are denied (my default chain policy), and now I want to permit web access. Apart from adding a normal accept-rule to manage this (-p tcp -d 0/0 80, for example, and the reverse-path), would I have to add a fragment-specific rule (-f) in addition to the first one??? Because it would be a little tedious. Isn't there any tricky way of avoiding this? I've thought of using the above kernel option (which would avoid managing with fragments), but I haven't found on 2.2.17 (maybe it's enabled by default?). Thanks. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ** RoMaN SoFt / LLFB ** roman@madrid.com http://pagina.de/romansoft ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Packet fragments have all the header information. How else would they make it to the target system? It's basically a non issue. Also you shouldn't be seeing to many fragmented packets unless you are on some incredibly old and strange network, or people trying to connect to you are. Kurt Seifried - seifried@securityportal.com SecurityPortal, your focal point for security on the net http://www.securityportal.com/
Hi Kurt,
Packet fragments have all the header information. How else would they make it to the target system? It's basically a non issue. Also you shouldn't be
This is not entirely correct. Making the fragments so small that not even the TCP header fits in used to be a nice way to penetrate packet filters a few years ago. Fragmentation happens in the IP layer, not in the TCP layer (*). Basically, the TCP packet doesn't even know that it never shows up with a full header if the frags are too small. Knowing (*), it is clear to see that only the first fragment (if at all) contains the tcp, udp or icmp header (or whatever is the payload of the IP packet). In order to be able to filter traffic using port numbers, protocols and IP addresses, you must reassemble (defragment) all fragments until you see the full length packet again. So basically it's a tradeoff btw transparency (to see what's in) and performance (it takes time to wait until all frags have arrived and reassemble them).
seeing to many fragmented packets unless you are on some incredibly old and strange network, or people trying to connect to you are.
`ping -s 100 destination.host' usually won't create frags. _Usually_! `ping -s 10000 destination.host' usually _does_ create fragmented packets. Masquerading/NAT without defragmentation of the packets just doesn't work. The former compile time kernel option is a sysctl today, and masquerading enabled turns on defragmentation in net/ipv4/ip_masq.c, too. See /proc/sys/net/ipv4/ip_always_defrag for the number of reasons why it defragments and compare it with the output of `ipchains -L -Mn'.
Kurt Seifried - seifried@securityportal.com
Roman.
--
- -
| Roman Drahtmüller
This is not entirely correct. Making the fragments so small that not even the TCP header fits in used to be a nice way to penetrate packet filters a few years ago. Fragmentation happens in the IP layer, not in the TCP layer (*). Basically, the TCP packet doesn't even know that it never shows up with a full header if the frags are too small.
Is it correct, that this is still an issue when using ipchains? Would be an enabled ip_always_defrag a defense against fragmentation attacks?
participants (4)
-
Kurt Seifried -
Philipp Snizek -
Roman Drahtmueller -
RoMaN SoFt / LLFB!!