From this question Statistics /proc/net/stat/nf_conntrack is missing on Linux server I recognized that /proc/net/stat/nf_conntrack has an alternative conntrack -S.
In /proc/net/stat/nf_conntrack there is NEW counter, based on which the one can calculate CPS (connections per second) metric. But in conntrack -S I see no such a counter.
How can I obtain the NEW conntrack counter without /proc/net/stat/nf_conntrack? Is there a way to obtain it from conntrack -S?
For some reason I have no such file on my server..
root@serv:~# uname -a
Linux serv 5.4.0-87-generic #98~18.04.1-Ubuntu SMP Wed Sep 22 10:45:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
root@serv:~# cat /proc/net/stat/nf_conntrack
cat: /proc/net/stat/nf_conntrack: No such file or directory
But my conntrack is definitely enabled:
root@serv:~# lsmod | grep conntr
xt_conntrack 16384 1
nf_conntrack_netlink 45056 0
nf_conntrack 139264 2 xt_conntrack,nf_conntrack_netlink
nf_defrag_ipv6 24576 1 nf_conntrack
nf_defrag_ipv4 16384 1 nf_conntrack
libcrc32c 16384 1 nf_conntrack
nfnetlink 16384 1 nf_conntrack_netlink
x_tables 45056 3 xt_conntrack,iptable_filter,ip_tables
And conntrack -L works perfectly.
But lnstat -f ip_conntrack also shows the empty output.
What is the reason? Should I insert some kernel module for this file to appear in procfs?
For a public file archive with an anonymous ftp server (vsftpd) I need to restore passive ftp, which ceased to work after upgrading Ubuntu 16 LTS to 18 LTS some time ago (with 20 to follow). Previous answers around the SE network indicate that in addition to configuring connection tracking in the kernel and firewall, nf_conntrack_helper should be enabled in the kernel settings or a sysctl config.
However, this oft-referenced article on using helpers points out "this is not optimal and is even a security risk". This is reiterated in this answer, yet no other answers I found in this context have such reservations about setting net.netfilter.nf_conntrack_helper=1.
So I am not sure: is this safe to use or a risk?
Passive ftp is blocked by UFW unless I enable nf_conntrack_helper. Or is there another oversight in the conntrack configuration?
Background
Kernel 4.15.x with ftp modules:
$ lsmod | grep ftp
nf_nat_ftp 16384 0
nf_nat 28672 1 nf_nat_ftp
nf_conntrack_ftp 16384 1 nf_nat_ftp
nf_conntrack 110592 9 nf_conntrack_ipv6,nf_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_broadcast,nf_nat_ftp,nf_conntrack_netbios_ns,xt_CT,xt_conntrack,nf_nat
vsftpd with restricted pasv port range:
pasv_min_port=49152
pasv_max_port=60999
UFW with relevant configuration lines in before.rules:
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
In user.rules:
### tuple ### allow tcp 21 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 21 -j ACCEPT
In after.rules:
*raw
-A PREROUTING -p tcp --dport ftp -j CT -helper ftp
COMMIT
*filter
:ufw-after-input - [0:0]
:ufw-after-output - [0:0]
:ufw-after-forward - [0:0]
-A ufw-after-input -m conntrack --ctstate RELATED -m helper --helper ftp -p tcp -d <IP-address> --dport 49152:60999 -j ACCEPT
My setup consists of two apache servers like in this diagram:
|Apache | >==Reverse Proxy Connection====> |Apache |
|Server1| <==Response through conntrack==< |Server2|
After a successful HTTP connection from Server 1 to Server 2, the latter sends a TCP [FIN,ACK] packet.
This packet is properly acknowledged by Server 1 with a TCP [ACK] packet. The connection is now in the CLOSE-WAIT state.
Then, almost 600 Seconds later, Server 1 sends TCP [FIN,ACK] to Server 2, which responds with TCP [RST].
This packet is marked by conntack as 'invalid' and never makes it to Server 1 (due to an iptables rule), resulting in Server 1 retransmitting the TCP [FIN,ACK] packet more than 20 times. This is because nf_conntrack has a timeout of 60 seconds for a TCP connection in the CLOSE-WAIT state.
Is there any way to learn the port range of "Passive" FTP Server which is not in my authority. It is possible to set the range within configuration file. For example within vsftpd.conf :
pasv_min_port=25000
pasv_max_port=25500
#pasv_min_port=0
#pasv_max_port=0 (any port)
Since I want to apply a very restricted OUTPUT firewall (iptables) on my Linux Terminal Server, i need to know remote server's port range. Is FTP supports expose of port-range information, that clients can use of?
I am also open for any other possible solutions except the following one where i assume the server IP address as 10.1.1.1 :
-A OUTPUT -d 10.1.1.1 -j ACCEPT
Thanks for your interest...
Regards
EDIT
Thanks for @aaron-copley, @martin-prikryl, @user3590719
Answer for main question, FTP doesn't expose passive port range to the clients.
Solution of need is loading netfilter connection tracking module for FTP.
ip_conntrack_ftp (Module alias for CentOS/Red Hat : nf_conntrack_ftp)
Working example config for Red Hat 7:
/etc/sysconfig/iptables-config
IPTABLES_MODULES="nf_conntrack_ftp"
iptables rules
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -d 10.1.1.1/32 -p tcp -m tcp --dport 21 -j ACCEPT
-A OUTPUT -j DROP
Finally, manualy load module or restart iptables.service.