Re: Port triggering
Stéphane Veyret wrote:
> Le lun. 12 mars 2018 à 16:53, Florian Westphal a écrit :
> > > > 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.
>
> Does this mean I should create a new structure containing expectation
> data, as required by the nf_ct_expect_init function, and that I should
> expect to find this structure at ®s->data[priv->sreg] in
> nft_ct_set_eval?
No, that would be too extreme.
I think all the information should be passed as individual netlink
attributes.
In mean time, we gained ability to set timeout policies and conntrack
helpers via nft_ct, I think you can look at how they are implemented
to get an idea of how to gather the data that gets passed to
nf_ct_expect_init().
1a64edf54f55d7956cf5a0d95898bc1f84f9b818
netfilter: nft_ct: add helper set support
and
7e0b2b57f01d183e1c84114f1f2287737358d748
netfilter: nft_ct: add ct timeout support
table ip filter {
ct timeout customtimeout {
protocol tcp;
l3proto ip
policy = { established: 120, close: 20 }
}
chain output {
type filter hook output priority filter; policy accept;
ct timeout set "customtimeout"
}
}
table inet myhelpers {
ct helper ftp-standard {
type "ftp" protocol tcp
}
chain prerouting {
type filter hook prerouting priority 0;
tcp dport 21 ct helper set "ftp-standard"
}
}
So for expectations this might look like this:
table inet foo {
ct expectation myexp {
protocol udp;
dport 6970-7170;
timeout 5m;
dmask 255.255.255.255;
smask 255.255.255.255;
}
ip dport 554 ct expectation set "myexp"
}
nft_ct object evaluation would call nf_ct_expect_alloc() based
on current pkt->skb->_nfct and it would pass all info that is configured in
'myexp' already to nf_ct_expect_init().
The tuples to expect would be taken from pkt->skb->_nfct one.
I think for initial implementation, smask/dmask isn't needed so we
could just use the full expectet address.
Later on, we could extend this to also allow sport, classes, and so on.
Using the obect infrastructure allows to assign the expectation via maps,
without extra code, for example:
ct helper set tcp dport map {21 : "cthelp1", 2121 : "cthelp1" }
ct expectation set ip protocol map { 6 : "tcpexpect" , ...
> When all this is done, I will have to also update the nftables
> command. Will I also need to update the nftables library?
You will need to touch both libnftables and nftables.
You can look at nft/libnftnl history for the helper and timeout support.
Re: Port triggering
Hello Florian, hello all,
More than a year has past since I asked all those questions about
adding expectation attribute to nf_tables, and I finally have time to
work on it. But I find it difficult to understand the way it is
written, and therefore have questions. Here are the first ones (see
below).
Le lun. 12 mars 2018 à 16:53, Florian Westphal a écrit :
> > > 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.
Does this mean I should create a new structure containing expectation
data, as required by the nf_ct_expect_init function, and that I should
expect to find this structure at ®s->data[priv->sreg] in
nft_ct_set_eval?
When all this is done, I will have to also update the nftables
command. Will I also need to update the nftables library?
Thank you.
Re: Port triggering
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
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
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
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
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
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
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
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
Port triggering
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? 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
