Re: Filtering in PREROUTING

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

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.

- 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.

* 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.

- 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.
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.

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.