Re: Port triggering

[Stéphane Veyret]

2018-03-12 16:53 GMT+01:00 Florian Westphal :
>> It may be what I'm looking for. But I couldn't find any documentation
>> about this “ct expectation” command. Or do you mean I should create a
>> conntrack helper module for that?
>
> Right, this doesn't exist yet.
>
> I think we (you) should consider to extend net/netfilter/nft_ct.c, to
> support a new NFT_CT_EXPECT attribute in nft_ct_set_eval() function.
>
> This would then install a new expectation based on what userspace told
> us.
>
> You can look at
> net/netfilter/nf_conntrack_ftp.c
> and search for nf_ct_expect_alloc() to see where the ftp helper installs
> the expectation.
>
> The main difference would be that with nft_ct.c, most properties of
> the new expectation would be determined by netlink attributes which were
> set by the nftables ruleset.

Thank you, I'll do that… :-)

-- 
Bien cordialement, / Plej kore,

Stéphane Veyret
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Port triggering

[Florian Westphal]

Stéphane Veyret  wrote:
> 2018-03-12 12:25 GMT+01:00 Florian Westphal :
> > (Or i still fail to understand what you want to do, it does
> >  sound exactly like expectations, e.g. for ftp data channel in
> >  response to PASV command on ftp control channel).
> 
> No, what I would like to have is more like FTP *active* connexion.

Thats what I meant :-/

(PORT command, not PASV).

> > Something like:
> >
> > chain postrouting {
> > type filter hook postrouting priority 0;
> > # tell kernel to install an expectation
> > # arriving on udp ports 6970-7170
> > # expectation will follow whatever NAT transformation
> > # is active on master connection
> > # expectation is removed after 5 minutes
> > # (we could of course also allow to install an expectation
> > # for 'foreign' addresses as well but I don't think its needed
> > # yet
> > ip dport 554 ct expectation set udp dport 6970-7170 timeout 5m
> > }
> 
> It may be what I'm looking for. But I couldn't find any documentation
> about this “ct expectation” command. Or do you mean I should create a
> conntrack helper module for that?

Right, this doesn't exist yet.

I think we (you) should consider to extend net/netfilter/nft_ct.c, to
support a new NFT_CT_EXPECT attribute in nft_ct_set_eval() function.

This would then install a new expectation based on what userspace told
us.

You can look at
net/netfilter/nf_conntrack_ftp.c
and search for nf_ct_expect_alloc() to see where the ftp helper installs
the expectation.

The main difference would be that with nft_ct.c, most properties of
the new expectation would be determined by netlink attributes which were
set by the nftables ruleset.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Port triggering

[Stéphane Veyret]

Thank you for your help.

2018-03-12 12:25 GMT+01:00 Florian Westphal :
> (Or i still fail to understand what you want to do, it does
>  sound exactly like expectations, e.g. for ftp data channel in
>  response to PASV command on ftp control channel).

No, what I would like to have is more like FTP *active* connexion. The
(in-lan) client is initiating a connection to the server. The server
replies and the initiate a new connection (data connection for FTP) on
a new port. I want this new connection to be associated to the first
one. This is also what we have with rtsp or battle-net protocols.

> Something like:
>
> chain postrouting {
> type filter hook postrouting priority 0;
> # tell kernel to install an expectation
> # arriving on udp ports 6970-7170
> # expectation will follow whatever NAT transformation
> # is active on master connection
> # expectation is removed after 5 minutes
> # (we could of course also allow to install an expectation
> # for 'foreign' addresses as well but I don't think its needed
> # yet
> ip dport 554 ct expectation set udp dport 6970-7170 timeout 5m
> }

It may be what I'm looking for. But I couldn't find any documentation
about this “ct expectation” command. Or do you mean I should create a
conntrack helper module for that ?

-- 
Bien cordialement, / Plej kore,

Stéphane Veyret
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Port triggering

[Florian Westphal]

Stéphane Veyret  wrote:
> A few words on the specs I imagined for the port triggering:
> 
> table ip trigger {
>  chain postrouting {
>   type filter hook postrouting priority 0;
>   ip dport 554 trigger open rtsp timeout 300 # Open the
> trigger named rtsp if packet arrives for port 554 - trigger will close
> in 300s if not refreshed. This will record source (client) and target
> (server) address
>  }
> }
> 
> table ip nat {
>  chain prerouting {
>   type nat hook prerouting priority 0;
>   ip dport 6970-7170 trigger dnat rtsp # If trigger is open
> and source is recorded server address, DNAT the packet to recorded
> client address
>  }
> }

You might already be able to do this with maps, however it looks
like it might be better to just allow to set conntrack expectations from
nftables rules/packet path instead.

(Or i still fail to understand what you want to do, it does
 sound exactly like expectations, e.g. for ftp data channel in
 response to PASV command on ftp control channel).

Something like:

chain postrouting {
type filter hook postrouting priority 0;
# tell kernel to install an expectation
# arriving on udp ports 6970-7170
# expectation will follow whatever NAT transformation
# is active on master connection
# expectation is removed after 5 minutes
# (we could of course also allow to install an expectation
# for 'foreign' addresses as well but I don't think its needed
# yet
ip dport 554 ct expectation set udp dport 6970-7170 timeout 5m
}

table ip filter {
  chain forward {
   ip dport 6970-7170 ct status expected accept
  }
}

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Port triggering

[Stéphane Veyret]

Partially answering to myself : here is a good starting point for
nftables dev ->
https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Port triggering

[Stéphane Veyret]

Hi,

Sorry for previous answer, Florian, I didn't see I was answering to
your own address and not to the full list.

Port triggering is a basic feature that we can find in most hardware
routers. Unfortunately, people wanting to build their own software
router on Linux, mostly using netfilter, do not have easy solution for
that.

> It should be possible to replicate pknock-like function via
> ipset or nftables.
>
> (If not, would be interesting to learn what we're missing on nftables
>  side plumbing).

After reading docs on nftables and ipset, I think that there is a
missing feature indeed:
* it is possible to store source and destination address when packet
arrive to the router and is targeted to a given port ;
* it is possible to match an incoming packet if it is coming from the
recorded destination address ;
* it does not seem easily possible to DNAT this packet to the recorded
source address taken from ipset (at least, I didn't find how to do
it).

Anyway, even if it would be possible, I would personally see it as a
workaround for a missing feature. So I think that such a basic thing
as is port triggering should be implemented in netfilter. But, as I
said in my previous e-mail (sent only to Florian), I was years late
with my add-on on Xtables. So I suggest that I create a new module for
netfilter/nftables instead. In order to create it I would like to find
an up to date doc as there is for Xtables-addon
(http://inai.de/documents/Netfilter_Modules.pdf). Can someone tell me
what I should start reading for that?

A few words on the specs I imagined for the port triggering:

table ip trigger {
 chain postrouting {
  type filter hook postrouting priority 0;
  ip dport 554 trigger open rtsp timeout 300 # Open the
trigger named rtsp if packet arrives for port 554 - trigger will close
in 300s if not refreshed. This will record source (client) and target
(server) address
 }
}

table ip nat {
 chain prerouting {
  type nat hook prerouting priority 0;
  ip dport 6970-7170 trigger dnat rtsp # If trigger is open
and source is recorded server address, DNAT the packet to recorded
client address
 }
}

table ip filter {
 chain forward {
  type filter hook forward priority 0;
  ip dport 6970-7170 trigger filter rtsp # If trigger is open
and source is recorded server address, accept the packet, continue
otherwise
  drop
 }
}

Regards,

-- 
Bien cordialement, / Plej kore,

Stéphane Veyret
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Port triggering

[Florian Westphal]

Stéphane Veyret  wrote:
> Hi,
> 
> I saw that patches have been written some years ago for port
> triggering in Netfilter, but no such feature is currently available in
> the kernel. Is there any reason for that? If I write and submit such a
> patch as Xtables-addons module, would it have chances to be accepted?

Xtables-addons has pknock module, last time i checked.

It should be possible to replicate pknock-like function via
ipset or nftables.

(If not, would be interesting to learn what we're missing on nftables
 side plumbing).
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Port triggering

[Stéphane Veyret]

Hi,

Please tell me if my message was posted in the wrong place, or if I
don't use the right title convention…

Thank you,


-- 
Bien cordialement, / Plej kore,

Stéphane Veyret
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html