Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #1964

Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited)

Show all headers | View raw

On Thu, 21 Feb 2013 09:46:30 +0100, Pascal Hambourg wrote:

> You know what SNAT rules you have in nat.POSTROUTING. So you know what
> packets in filter.FORWARD will be SNATed or already have a valid source
> address. You can create filtering rules which match the same packets as
> the SNAT rules but with the ACCEPT target instead of SNAT.

I deliberately avoid this right now for a couple of reasons.

First, this means that any given expression that SNAT is occurring must be
implemented twice.  Redundancy of this sort is never a good thing; it
means that two different but effectively identical sets of rules need to
be maintained.

[This might not be so bad were there a way to share rulesets over tables,
but - at least as far as I know - there is not.]

Second, this presumes that the rules are perfect.  That is, if I err
somehow in filter.FORWARD such that a packet that should be either blocked
or SNATed is not, then the duplicated logic in nat.POSTROUTING will have
the same error.  Right now, I avoid this by having as final rules in the
nat.POSTROUTING ruleset some very simple (and therefore tough to get wrong
{8^) logic which blocks anything I might have previously missed.

I usually do pretty well by assuming that I'm less than perfect.  It seems
like a mistake waiting to happen to depend upon always getting something -
even just a little complex - correct.

I'm thinking that the only solution that's really guaranteed to avoid
leaking packets with bad source IPs is to have nat.POSTROUTING SNAT
anything with a bad source IP.  The presumption would be that
filter.FORWARD would have only permitted what's desired.

This avoids the possibility of leaking, but it doesn't provide any check
against errors on my part.

Am I missing something?

	- Andrew

Back to comp.os.linux.networking | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Andrew Gideon <c182driver9@gideon.org> - 2013-02-19 00:00 +0000
  Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2013-02-21 09:46 +0100
    Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Andrew Gideon <c182driver9@gideon.org> - 2013-02-21 20:08 +0000
      Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Ken Sims <ng12207@kensims.#nospam#.net.invalid> - 2013-02-21 20:54 -0800
      Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2013-02-23 10:26 +0100
        Re: Avoiding DROP in iptables nat.POSTROUTING when SNAT is involved (thanks to: The "nat" table is not intended for filtering, the use of DROP is therefore inhibited) Ken Sims <ng12207@kensims.#nospam#.net.invalid> - 2013-02-23 07:17 -0800

csiph-web