On 26.11, Pablo Neira Ayuso wrote:
> On Thu, Nov 26, 2015 at 04:02:27PM +0000, Patrick McHardy wrote:
> > On 26.11, Pablo Neira Ayuso wrote:
> > > On Thu, Nov 26, 2015 at 03:24:11PM +0000, Patrick McHardy wrote:
> > > > Consider:
> > > >
> > > > -i eth0 -j CT --track
> > > > -i eth0 -p sctp --dport 1234 -j ACCEPT
> > > > -i eth0 -m state --state ESTABLISHED -j ACCEPT
> [...]
> > > IMO we should skip enabling things by default. When we enable things
> > > by default someone else follow up later on with some scenario we
> > > didn't consider and then we've got problems. I think we should go in
> > > the direction of explicit configurations, we already do this for
> > > conntrack helpers.
> >
> > Well as I already said, it doesn't solve anything regarding this problem,
> > so how is it relevant?
>
> This doesn't sound so complicated to me:
>
> add rule filter prerouting \
> ip protocol { tcp, udp, sctp } track
>
> You just specify what you need for stateful tracking.
Sure, or "filter prerouting track" for everything. Let's stay at that
example because it will be a common case and we don't know anything about
protocols.
> The case above you indicate is enabling conntrack for all packets, the
> -j CT --track is what should govern this IMO.
How does it prevent exactly that case we're talking about - someone is
saying "CT --track" without further qualification and means "track
everything". And the SCTP connection tracking module is not available or
not loaded. The user uses exactly the rules which lead up to this fix.
How does this change *anything*? AFAICS its exactly the situation we have
now.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
