nft synproxy integration

nft synproxy integration

[Patrick McHardy]

We've talked about how to integrate synproxy in nft and agreed that it would
be preferrable to have a nicer way to use it.

The reason why the use is quite complicated right now is actually not because
of synproxy, but because of the desire to avoid creating conntracks for
spoofed connection requests. I don't see any way to avoid this, but we might
be able to make use a bit easier at some slightly higher cost. This applies
to both iptables and nft.

Basically the idea is:

* don't mark the first SYN untracked and have it create a conntrack as normal
* direct that SYN to synproxy
* mark the connection as proxied, which will avoid setting the ASSURED bit when
  receiving our spoofed reply
* only set assured once we have the connection fully established

This would create a conntrack, but keep it evictable under pressure. So the
cost would be ct set up, but we could tear it down at any point when we're
under pressure. The synproxy target can handle both connections with and
without a conntrack.

Usage would basically be:

nft filter input tcp dport 80 ct state INVALID,SYNPROXY synproxy ...

The ct state rule could actually be created automatically since it is a
dependency.

Iff we evict a connection before it is fully established, the final ACK will
be INVALID as it is now with untracked. This makes use less complex since a
single rule with suffice, but at the cost of potentially unnecessarily creating
conntracks. The method of using notrack would of course still be possible.

Any thoughts about this?

Fwd: nft synproxy integration

[Bjørnar Ness]

2015-11-09 17:30 GMT+01:00 Patrick McHardy <kaber@trash.net>:
>

[ ... ]

> Any thoughts about this?

Could it be possible to automagically insert an "hiden notrack" for the same
packets the synproxy target matches when adding it?

Ofcorse depends on what this cost really is in terms of performance, but I dont
like the idea of sacrificing performance for a little easier use.
Atleast not for this
module, where the whole point of it beeing able to deal with big pps numbers

-- 
Bj(/)rnar

Re: Fwd: nft synproxy integration

[Patrick McHardy]

On 09.11, Bjørnar Ness wrote:
> 2015-11-09 17:30 GMT+01:00 Patrick McHardy <kaber@trash.net>:
> >
> 
> [ ... ]
> 
> > Any thoughts about this?
> 
> Could it be possible to automagically insert an "hiden notrack" for the same
> packets the synproxy target matches when adding it?
> 
> Ofcorse depends on what this cost really is in terms of performance, but I dont
> like the idea of sacrificing performance for a little easier use.
> Atleast not for this
> module, where the whole point of it beeing able to deal with big pps numbers

Problem is that the rule would need to apply to exactly the same packets and
its in a different table, its hard to make sure that among updates and other
changes to the ruleset. So right now, no. As I mentioned, you could still
manually notrack packets.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: nft synproxy integration

[Jozsef Kadlecsik]

On Mon, 9 Nov 2015, Patrick McHardy wrote:

> Basically the idea is:
> 
> * don't mark the first SYN untracked and have it create a conntrack as normal
> * direct that SYN to synproxy
> * mark the connection as proxied, which will avoid setting the ASSURED bit when
>   receiving our spoofed reply
> * only set assured once we have the connection fully established
> 
> This would create a conntrack, but keep it evictable under pressure. So the
> cost would be ct set up, but we could tear it down at any point when we're
> under pressure. The synproxy target can handle both connections with and
> without a conntrack.
[...] 
> The ct state rule could actually be created automatically since it is a
> dependency.
[...]
> The method of using notrack would of course still be possible.

I like the idea: the notrack method would still be supported and the "do 
conntrack but with safety-net" way would be possible too. Looks cool!

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: nft synproxy integration

[Patrick McHardy]

Am 9. November 2015 19:36:06 GMT+00:00, schrieb Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>:
>On Mon, 9 Nov 2015, Patrick McHardy wrote:
>
>> Basically the idea is:
>> 
>> * don't mark the first SYN untracked and have it create a conntrack
>as normal
>> * direct that SYN to synproxy
>> * mark the connection as proxied, which will avoid setting the
>ASSURED bit when
>>   receiving our spoofed reply
>> * only set assured once we have the connection fully established
>> 
>> This would create a conntrack, but keep it evictable under pressure.
>So the
>> cost would be ct set up, but we could tear it down at any point when
>we're
>> under pressure. The synproxy target can handle both connections with
>and
>> without a conntrack.
>[...] 
>> The ct state rule could actually be created automatically since it is
>a
>> dependency.
>[...]
>> The method of using notrack would of course still be possible.
>
>I like the idea: the notrack method would still be supported and the
>"do 
>conntrack but with safety-net" way would be possible too. Looks cool!

Thanks Jozsef. I'm thinking it's the best of both worlds myself. Implementation should be quite easy, I'll give it a try.


>
>Best regards,
>Jozsef
>-
>E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
>PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
>Address : Wigner Research Centre for Physics, Hungarian Academy of
>Sciences
>          H-1525 Budapest 114, POB. 49, Hungary


-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: nft synproxy integration

[Florian Westphal]

Patrick McHardy <kaber@trash.net> wrote:
> Am 9. November 2015 19:36:06 GMT+00:00, schrieb Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>:
> >On Mon, 9 Nov 2015, Patrick McHardy wrote:
> >> The method of using notrack would of course still be possible.
> >
> >I like the idea: the notrack method would still be supported and the
> >"do 
> >conntrack but with safety-net" way would be possible too. Looks cool!
> 
> Thanks Jozsef. I'm thinking it's the best of both worlds myself. Implementation should be quite easy, I'll give it a try.

I'm fine with the suggestion, but, pardon the heretic question:

Why do we need synproxy after the recent listen lock removal from Eric?

Re: nft synproxy integration

[Patrick McHardy]

On 09.11, Florian Westphal wrote:
> Patrick McHardy <kaber@trash.net> wrote:
> > Am 9. November 2015 19:36:06 GMT+00:00, schrieb Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>:
> > >On Mon, 9 Nov 2015, Patrick McHardy wrote:
> > >> The method of using notrack would of course still be possible.
> > >
> > >I like the idea: the notrack method would still be supported and the
> > >"do 
> > >conntrack but with safety-net" way would be possible too. Looks cool!
> > 
> > Thanks Jozsef. I'm thinking it's the best of both worlds myself. Implementation should be quite easy, I'll give it a try.
> 
> I'm fine with the suggestion, but, pardon the heretic question:
> 
> Why do we need synproxy after the recent listen lock removal from Eric?

Simple answer is - its for the network, not for the host :)

Re: nft synproxy integration

[Alexander Meinhardt]

Any news about that?

Kind regards
Alex