Re: Port triggering

Re: Port triggering

[Stéphane Veyret]

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 <fw@strlen.de> 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 &regs->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

[Florian Westphal]

Stéphane Veyret <sveyret@gmail.com> wrote:
> Le lun. 12 mars 2018 à 16:53, Florian Westphal <fw@strlen.de> 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 &regs->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.

port Triggering.

[samba]

Hi all,
I have been trying to configure port triggering using iptables. Port 
triggering allows opening  of  inbound port for some interval of time 
based on some outbound traffic that originated from internal LAN. This 
is similar to how ftp is handled by ip_conntrack_ftp module. With port 
triggering, there will be no need to parse the control packet for data 
ports that needs to be opened, since the user already specifies the 
ports on which the ftp server will open connection for data.

Is such a feature supported by iptables and the netfilter framework, 
which enables/triggers some user defined  incomming ports based on the 
traffic going through some outgoing ports(user defined) ?

I have seen some discussion regarding this in the archives (June 2003). 
But could not get any conclusions. Please help.

Thanks in advance for any help
-samba