* FTP connection tracking doesn't work with nftables
@ 2015-05-13 21:03 Tomek L
2015-05-16 11:47 ` Tomek L
0 siblings, 1 reply; 8+ messages in thread
From: Tomek L @ 2015-05-13 21:03 UTC (permalink / raw
To: netfilter
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: FTP connection tracking doesn't work with nftables
2015-05-13 21:03 FTP connection tracking doesn't work with nftables Tomek L
@ 2015-05-16 11:47 ` Tomek L
[not found] ` <CAJO99Tm9G3H+jMibWBj2pkAgg1SdFTVS_pqEQ6P=COMqe7Ppcg@mail.gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Tomek L @ 2015-05-16 11:47 UTC (permalink / raw
Cc: netfilter
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: FTP connection tracking doesn't work with nftables
[not found] ` <CAJO99Tm9G3H+jMibWBj2pkAgg1SdFTVS_pqEQ6P=COMqe7Ppcg@mail.gmail.com>
@ 2015-05-16 15:34 ` Tomek L
[not found] ` <CAJO99Tko6zWC8hH64vGJ6cXXNg3rfLQBo+DL-XuF=b8j82OtOA@mail.gmail.com>
2015-05-17 13:32 ` Pascal Hambourg
0 siblings, 2 replies; 8+ messages in thread
From: Tomek L @ 2015-05-16 15:34 UTC (permalink / raw
To: Bjørnar Ness; +Cc: Tomek L, netfilter
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: FTP connection tracking doesn't work with nftables
[not found] ` <CAJO99Tko6zWC8hH64vGJ6cXXNg3rfLQBo+DL-XuF=b8j82OtOA@mail.gmail.com>
@ 2015-05-17 5:48 ` Tomek L
0 siblings, 0 replies; 8+ messages in thread
From: Tomek L @ 2015-05-17 5:48 UTC (permalink / raw
To: Bjørnar Ness; +Cc: netfilter
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: FTP connection tracking doesn't work with nftables
2015-05-16 15:34 ` Tomek L
[not found] ` <CAJO99Tko6zWC8hH64vGJ6cXXNg3rfLQBo+DL-XuF=b8j82OtOA@mail.gmail.com>
@ 2015-05-17 13:32 ` Pascal Hambourg
2015-05-17 16:53 ` Tomek L
1 sibling, 1 reply; 8+ messages in thread
From: Pascal Hambourg @ 2015-05-17 13:32 UTC (permalink / raw
To: Tomek L; +Cc: netfilter
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: FTP connection tracking doesn't work with nftables
2015-05-17 13:32 ` Pascal Hambourg
@ 2015-05-17 16:53 ` Tomek L
2015-05-17 20:59 ` Pascal Hambourg
0 siblings, 1 reply; 8+ messages in thread
From: Tomek L @ 2015-05-17 16:53 UTC (permalink / raw
To: Pascal Hambourg; +Cc: Tomek L, netfilter
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: FTP connection tracking doesn't work with nftables
2015-05-17 16:53 ` Tomek L
@ 2015-05-17 20:59 ` Pascal Hambourg
2015-05-18 5:58 ` Tomek L
0 siblings, 1 reply; 8+ messages in thread
From: Pascal Hambourg @ 2015-05-17 20:59 UTC (permalink / raw
To: Tomek L; +Cc: netfilter
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: FTP connection tracking doesn't work with nftables
2015-05-17 20:59 ` Pascal Hambourg
@ 2015-05-18 5:58 ` Tomek L
0 siblings, 0 replies; 8+ messages in thread
From: Tomek L @ 2015-05-18 5:58 UTC (permalink / raw
To: Pascal Hambourg; +Cc: Tomek L, netfilter
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-05-18 5:58 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-13 21:03 FTP connection tracking doesn't work with nftables Tomek L
2015-05-16 11:47 ` Tomek L
[not found] ` <CAJO99Tm9G3H+jMibWBj2pkAgg1SdFTVS_pqEQ6P=COMqe7Ppcg@mail.gmail.com>
2015-05-16 15:34 ` Tomek L
[not found] ` <CAJO99Tko6zWC8hH64vGJ6cXXNg3rfLQBo+DL-XuF=b8j82OtOA@mail.gmail.com>
2015-05-17 5:48 ` Tomek L
2015-05-17 13:32 ` Pascal Hambourg
2015-05-17 16:53 ` Tomek L
2015-05-17 20:59 ` Pascal Hambourg
2015-05-18 5:58 ` Tomek L
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.