FTP connection tracking doesn't work with nftables

FTP connection tracking doesn't work with nftables

[Tomek L]

Hello

Could you have a look at my simple nft firewall script below, I've used
"ct related, established", but it doesnt work with passive mode FTP -
the data session on high ports is dropped by firewall. Does NFTables
have  connection tracking helper for FTP? If not - is it planned in
foreseable future to add it? I have following modules loaded:

nf_nat_ftp              1612  0
nf_conntrack_tftp       3825  0
nf_log_common           2778  0
nf_conntrack_ftp        6687  1 nf_nat_ftp
nf_tables_ipv4          1662  4
nf_tables              44307  323
nf_tables_ipv4,nft_log,nft_ct,nft_hash,nft_meta,nft_rbtree,nft_limit,nft_counter
nf_nat_masquerade_ipv4     1813  1 ipt_MASQUERADE
nf_conntrack_ipv4       7834  32
nf_defrag_ipv4          1251  1 nf_conntrack_ipv4
nf_nat_ipv4             4386  1 iptable_nat
nf_nat                 10869  4
nf_nat_ftp,nf_nat_ipv4,xt_nat,nf_nat_masquerade_ipv4
nf_conntrack           55251  8
nf_nat_ftp,nf_nat,nft_ct,nf_nat_ipv4,nf_nat_masquerade_ipv4,nf_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_tftp
nfnetlink               5157  5 nf_tables,nfnetlink_log,ip_set,nfnetlink_queue

And this is my nft configuration...

table ip filter {
  chain input {
  type filter hook input priority 0;
  dport 21 ct state new accept
  ct state established, related counter accept
  counter limit rate 100/second log group 2 prefix "RULE=Default drop"
  counter drop
  }

  chain output {
  type filter hook output priority 0;
  ct state established, related counter accept
  }

}

The packet for high TCP port is dropped when trying to get FTP folder list...

2015-05-13 23:00:57 XXXX ulogd RULE='Default drop' IN=eno1 OUT=
MAC=00:1e:67:ab:1f:49:b0:c2:9a:e3:27:c2:01:00 SRC=1.1.1.1 DST=2.2.2.2
LEN=64 TOS=00 PREC=0x00 TTL=58 ID=1603 DF PROTO=TCP SPT=57186
DPT=24362 SEQ=3242263100 ACK=0 WINDOW=65535 SYN URGP=0 MARK=0

Re: FTP connection tracking doesn't work with nftables

[Tomek L]

I've found out that plain FTP session works, its only when TLS is
negotiated doesn't trigger FTP helper. Is there any workaround with
NFTables for this? I've seen something for IPTables with --recent, but
is there a way to do it with NFTables?

2015-05-13 23:03 GMT+02:00 Tomek L <tl-netfilter@gazeta.pl>:
> Hello
>
> Could you have a look at my simple nft firewall script below, I've used
> "ct related, established", but it doesnt work with passive mode FTP -
> the data session on high ports is dropped by firewall. Does NFTables
> have  connection tracking helper for FTP? If not - is it planned in
> foreseable future to add it? I have following modules loaded:
>
> nf_nat_ftp              1612  0
> nf_conntrack_tftp       3825  0
> nf_log_common           2778  0
> nf_conntrack_ftp        6687  1 nf_nat_ftp
> nf_tables_ipv4          1662  4
> nf_tables              44307  323
> nf_tables_ipv4,nft_log,nft_ct,nft_hash,nft_meta,nft_rbtree,nft_limit,nft_counter
> nf_nat_masquerade_ipv4     1813  1 ipt_MASQUERADE
> nf_conntrack_ipv4       7834  32
> nf_defrag_ipv4          1251  1 nf_conntrack_ipv4
> nf_nat_ipv4             4386  1 iptable_nat
> nf_nat                 10869  4
> nf_nat_ftp,nf_nat_ipv4,xt_nat,nf_nat_masquerade_ipv4
> nf_conntrack           55251  8
> nf_nat_ftp,nf_nat,nft_ct,nf_nat_ipv4,nf_nat_masquerade_ipv4,nf_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_tftp
> nfnetlink               5157  5 nf_tables,nfnetlink_log,ip_set,nfnetlink_queue
>
> And this is my nft configuration...
>
> table ip filter {
>   chain input {
>   type filter hook input priority 0;
>   dport 21 ct state new accept
>   ct state established, related counter accept
>   counter limit rate 100/second log group 2 prefix "RULE=Default drop"
>   counter drop
>   }
>
>   chain output {
>   type filter hook output priority 0;
>   ct state established, related counter accept
>   }
>
> }
>
> The packet for high TCP port is dropped when trying to get FTP folder list...
>
> 2015-05-13 23:00:57 XXXX ulogd RULE='Default drop' IN=eno1 OUT=
> MAC=00:1e:67:ab:1f:49:b0:c2:9a:e3:27:c2:01:00 SRC=1.1.1.1 DST=2.2.2.2
> LEN=64 TOS=00 PREC=0x00 TTL=58 ID=1603 DF PROTO=TCP SPT=57186
> DPT=24362 SEQ=3242263100 ACK=0 WINDOW=65535 SYN URGP=0 MARK=0

Re: FTP connection tracking doesn't work with nftables

[Tomek L]

Helper doesn't have to look into encrypted payload. It would be enough
if helper assumes that in the next ~3 seconds, netfilter can expect
incoming connection from client on high port, from source port +1
higher than original source port used when initiating connection.
Sorry but opening high port range just to handle ftp connection is
weak advice...
In IPTables it could be done with --recent extension.

2015-05-16 14:12 GMT+02:00 Bj√∏rnar Ness <bjornar.ness@gmail.com>:
> It is not possible for helper to look inside encrypted packets. Only option
> is to open a portrange.

Re: FTP connection tracking doesn't work with nftables

[Tomek L]

Hello,

After client connection initiation, the helper should temporarily
allow for new TCP connection from client, with source port set to
source port used for first connection + 1, and destination port >1024.
Below is the snapshot from log. But this should be handled by FTP
helper no matter if its TLS or plain session. Start of TLS negotiation
is plaintext ("TLS AUTH....") - so I think it could be handled by
helper safely (so we are sure before opening high ports, we are really
in FTP session).

2015-05-17 07:40:36 Golem ulogd ACTION=Accept STATE=New RULE='FTP
incoming' IN=eno1 OUT= MAC=00:1e:67:ab:1f:49:b0:c6:9a:e3:27:c2:08:00
SRC=x.x.x.215 DST=212.x.x.242 LEN=64 TOS=00 PREC=0x00 TTL=58 ID=64588
DF PROTO=TCP SPT=49458 DPT=21 SEQ=1085504279 ACK=0 WINDOW=65535 SYN
URGP=0 MARK=0

2015-05-17 07:40:36 Golem ulogd ACTION=Drop RULE='Default drop'
IN=eno1 OUT= MAC=00:1e:67:ab:1f:49:b0:c6:9a:e3:27:c2:08:00
SRC=x.x.x.215 DST=212.x.x.242 LEN=64 TOS=00 PREC=0x00 TTL=58 ID=50205
DF PROTO=TCP SPT=49459 DPT=47244 SEQ=3549983851 ACK=0 WINDOW=65535 SYN
URGP=0 MARK=0




2015-05-16 17:36 GMT+02:00 Bj√∏rnar Ness <bjornar.ness@gmail.com>:
> What port should it open, then?

Re: FTP connection tracking doesn't work with nftables

[Pascal Hambourg]

Tomek L a écrit :
> Helper doesn't have to look into encrypted payload.

The helper needs to look into the control connection.

> It would be enough
> if helper assumes that in the next ~3 seconds, netfilter can expect
> incoming connection from client on high port, from source port +1
> higher than original source port used when initiating connection.

This assumption is wrong. AFAIK there is no requirement in the RFCs that
the source port for a data connection be +1 higher than the original
source port used for the control connection. I checked my FTP client
(tnftp), it uses random source ports for each data connection. Besides,
source ports may be mangled by any NAT device in the path.

The only requirement is for active mode, the server should use the
control port -1 (usually 21-1 = 20) as the source port for data connections.

Re: FTP connection tracking doesn't work with nftables

[Tomek L]

I agree on source port issue, but I don't think that in case of TLS
there is nothing that can be done with FTP helper. Still we can assume
that just after TLS AUTH negotiation, client will connect on high port
with new connection to server. Now we are in situation, where if TLS
is used, high ports on server side must be open all the time. With
IPTables it was at least possible to make workaround with "recent"
extension, with NFTables we have nothing.

2015-05-17 15:32 GMT+02:00 Pascal Hambourg <pascal@plouf.fr.eu.org>:
> Tomek L a écrit :
>> Helper doesn't have to look into encrypted payload.
>
> The helper needs to look into the control connection.
>
>> It would be enough
>> if helper assumes that in the next ~3 seconds, netfilter can expect
>> incoming connection from client on high port, from source port +1
>> higher than original source port used when initiating connection.
>
> This assumption is wrong. AFAIK there is no requirement in the RFCs that
> the source port for a data connection be +1 higher than the original
> source port used for the control connection. I checked my FTP client
> (tnftp), it uses random source ports for each data connection. Besides,
> source ports may be mangled by any NAT device in the path.
>
> The only requirement is for active mode, the server should use the
> control port -1 (usually 21-1 = 20) as the source port for data connections.

Re: FTP connection tracking doesn't work with nftables

[Pascal Hambourg]

Tomek L a écrit :
> I agree on source port issue, but I don't think that in case of TLS
> there is nothing that can be done with FTP helper. Still we can assume
> that just after TLS AUTH negotiation, client will connect on high port
> with new connection to server. Now we are in situation, where if TLS
> is used, high ports on server side must be open all the time.

IMO, it is not much better to open all passive ports to any host which
has established a connection to port 21 regardless of whether a
PASV/EPSV command was acknowledged by the server.

Re: FTP connection tracking doesn't work with nftables

[Tomek L]

I would say it is better to have high ports open on demand (after AUTH
TLS) than have them open all the time. NFTables are now useless to me,
as their FTP/TLS passive mode is not supported neither by helper or by
"recent" extension.

2015-05-17 22:59 GMT+02:00 Pascal Hambourg <pascal@plouf.fr.eu.org>:
> Tomek L a écrit :
>> I agree on source port issue, but I don't think that in case of TLS
>> there is nothing that can be done with FTP helper. Still we can assume
>> that just after TLS AUTH negotiation, client will connect on high port
>> with new connection to server. Now we are in situation, where if TLS
>> is used, high ports on server side must be open all the time.
>
> IMO, it is not much better to open all passive ports to any host which
> has established a connection to port 21 regardless of whether a
> PASV/EPSV command was acknowledged by the server.