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.
