On Thu, 2007-01-18 at 20:19 +0100, Pascal Hambourg wrote: > Hello, > > george a écrit : > > I've seen a few places telling me that you shouldn't filter in the > > mangle table. However, it seems sensible to me to drop junk packets in > > PREROUTING rather than have to duplicate those rules in both INPUT and > > FORWARD. > > > > Having done this, I'm seeing packets dropped as invalid when I would > > expect them to be OK (but most traffic is behaving as expected). Before > > I start digging into this I want to check if filtering in the mangle > > table really is stupid. > > My thoughts about filtering in PREROUTING/mangle. > > Note : > Most of the following also applies to filtering in mangle/OUTPUT, > replacing PREROUTING, INPUT and FORWARD with OUTPUT. > > * Disadvantages : > > - The 'mangle' table was not designed for filtering. The REJECT target > only exists only in the 'filter' table, so it cannot be used in other > tables to do filtering. You can only use DROP. I only want DROP :) The 3 classes of packets I want to drop are: - broadcasts, mostly from Windows boxes which include Grant's netbeui example. These are most frequent and were the trigger for doing this. - spoofed source address (I don't know if I really need these with rp-filter enabled, in particular to catch private addresses if they manage to get in from the Internet. I may be being too paranoid here) - some connection-oriented tests on NEW and INVALID (which is where I started this thread from as I'm seeing packets dropped by the INVALID check which I wouldn't expect and I wanted to find out if this could be simply because I had the check in the wrong table) > > - As pointed out by Grant, in the case of forwarded packets the > PREROUTING chains ignore the output interface. So any filtering rule > relying on the output interface cannot be put in PREROUTING. Not relevant to me > > * Advantages (true or supposed) : > > - Avoid duplicating rules in filter/INPUT and filter/FORWARD. > Wrong : as pointed out by Grant, you can put the common rules in > user-defined chains called from both INPUT and FORWARD. I realise this. > > - Drop "junk" packets (malformed, INVALID state, invalid source or > destination...) as soon as possible and save the CPU overhead in > nat/PREROUTING and the routing decision. It may also save memory space > in the routing cache. That was my thinking. > However, packets in the INVALID state already skip the 'nat' table, and > the routing code can drop some packets with invalid source or > destination on its own (e.g. rp_filter). > > - As Grant and Alexandru pointed out, you can go furthur and drop "junk" > packets in the 'raw' table and save the connection tracking CPU overhead. Can't remember if I had a reason not to do this or if I just didn't realise. Following my continuing education though I now know that I couldn't filter on state in raw so I'd like to think that I found that out before ;) > > Alexandru wrote : > > If you use conntrack, it is even best to do the filtering in raw table > > in PREROUTING, this way your conntrack table is saved from being filled. > > I do not agree : filtering in the 'raw' table would have no effect on > the size of the connection tracking table because these packets would be > dropped later anyway and the connection tracking entry cleared. It would > just save some CPU. However, I agree with Grant : you can save the > conntrack CPU overhead by using the NOTRACK target in the 'raw' table, > which it was designed for. If an attacker wants to fill the conntrack > table, he'd better use "regular" packets. > > - When there is a DNAT rule in nat/PREROUTING redirecting packets from a > publicly visible address to a private hidden address, you may wish to > prevent direct access to the private address and drop such packets in > the 'mangle' table before they reach nat/PREROUTING. > Wrong : You can achieve the same result by just marking packets in the > mangle table and filtering them later in the 'filter' table based on the > mark. And anyway, is it important to drop such packets, how is it a > security issue ? > > My conclusion : > Early filtering in the 'raw' or 'mangle' table may save some CPU used > for the routing decision and the 'nat' table. > It may also save some memory space in the routing cache. > It does not save memory space in the connection tracking table. > It is not needed to save CPU for the connection tracking, use NOTRACK > instead. > It is not needed to avoid rule duplication, use user-defined chains instead. > It does not add security, except when there would be vulnerabilities in > the routing or connection tracking code. These all look good to me. I haven't needed NOTRACK before so I'd have to get that bit straight in my head if I were to go that way. I'm still not sure that I'm doing anything wrong, just unconventional. >From what I've been told via this list I'm thinking that it would be sensible to move my broadcast dropping to raw, state checks to filter and I don't know if I even need the spoofing checks, but if I do I suspect raw is the place for them. I am still slightly nervous that by going against the designers' intentions I might end up with something breaking. I would hope that anything dangerous wouldn't be allowed but "of course I didn't check for that - nobody would do that would they" is a classic reaon for software flaws :)
