Re: [PATCH] bridge: make bridge-nf-call-*tables default configurable
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2009-07-01 01:15:28
Also in:
netfilter-devel
Possibly related (same subject, not in this thread)
- 2009-07-01 · Re: [PATCH] bridge: make bridge-nf-call-*tables default configurable · Mark Smith <hidden>
- 2009-07-01 · Re: [PATCH] bridge: make bridge-nf-call-*tables default configurable · Herbert Xu <herbert@gondor.apana.org.au>
- 2009-07-01 · Re: [PATCH] bridge: make bridge-nf-call-*tables default configurable · David Miller <davem@davemloft.net>
- 2009-07-01 · Re: [PATCH] bridge: make bridge-nf-call-*tables default configurable · Patrick McHardy <hidden>
- 2009-07-01 · Re: [PATCH] bridge: make bridge-nf-call-*tables default configurable · David Miller <davem@davemloft.net>
On Tue, Jun 30, 2009 at 10:16:35PM +0200, Jan Engelhardt wrote:
It makes sense absolutely. Consider: * packet enters bridge * NF_HOOK(PF_INET6, NF_INET_PRE_ROUTING, ...) is called by nr_netfilter.c * (connection tracking entry is set up) * let bridging decision be "local delivery"
No, my question is does it ever make sense to use conntrack as part of bridge netfilter. That is, do you ever want to test it in your rules that are run as part of bridge netfilter. conntrack is inherently a security hole when used as part of bridging, because it ignores the Ethernet header so two unrelated connections can be tracked as one. It used to be an even bigger security hole when we ignored VLAN and PPPOE headers but at least that's now off by default. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} [off-list ref] Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt