Re: [PATCH] netfilter: nf_ct_sctp: validate vtag for new conntrack entries

[Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>]

Hi there,

On Wed, Dec 30, 2015 at 01:03:17AM +0100, Pablo Neira Ayuso wrote:
> Hi Marcelo,
> 
> On Thu, Dec 24, 2015 at 10:50:28AM -0200, Marcelo Ricardo Leitner wrote:
> > I can see how it would work for the vtag-tracking scenario, I think. I'm
> > just not seeing the non-tracking one (routers in the middle) yet.
> > It doesn't seem it can fit the helper way because it can't prepare
> > expectations as it doesn't see the packets in the initial path,
> > meaning that we would have to have 2 ways of handling such new
> > entries.
> 
> We assume that conntrack sees all traffic in our existing helpers,
> think of tcp. Otherwise, we may classify packets as invalid if we
> don't all packets that belong to the flow.

Yes, okay.

> > It would work like: if the helper is not present, allow heartbeats with any
> > vtag like it currently is. Otherwise, for validating vtag too, only allow
> > them via expectations.
> 
> I'm starting to think the lazy multihoming support is problematic
> since you can actually allow pushing holes into the firewall, how easy
> would be to push holes with this mode?

Please don't. Currently there is no other way to do it. The check I want
to add only works on a corner case of what we already have, on which we
can do better. It's just that. The way Michal handled the state
transitions is very good and the fact that the conntrack entries are
created as NEW, makes them pass the same user validation rules as a real
new association would do. So there can't be any hitch-hicking...

And for vtag probing, that's not an issue either because SCTP just drops
such heartbeat requests with invalid vtags (at sctp_sf_beat_8_3).

The only vector of attack I can think of that the initial multi-homing
support would allow is a DoS, a flood of incoming heartbeat requests.
Such flood would _not_ end up on the association buffer because if the
transport tuple (src ip, dst ip, src port, dst port) doesn't match a
known association, it's discarded. It's just as any other DoS, but as
they pass the same user validation rules, there should be rules
restricting the rate or IP range or something like that if user is
worried with that. Nothing that could jeopardize the original
association.

Note that the transport validation is performed before the vtag one, and
the stack behavior is to also drop out of the blue packets silently.
Meaning that even if the attacker get a hit at the 32-bit vtag, it will
be discarded by the transport validation firstly.

So what my patch add to it, it pulls/adds this vtag check to an earlier
moment, from the stack itself to the firewall, so that the peer
firewall will be a bit more stateful.

> You can probably achieve the same effect by allowing heartbearts go
> through via NOTRACK and then have some connection pickup from the
> middle feature. That, however, would make the user fully aware of the
> limitations since it would require explicit configuration.

Interesting idea, thanks.