An article at this URI https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-firewalls-iptables_and_connection_tracking

RELATED — A packet that is requesting a new connection but is part of an existing connection. For example, FTP uses port 21 to establish a connection, but data is transferred on a different port (typically port 20).

states that netfilter connection tracking mechanism is able to tag the ftp's out-of-band data-connection traffic to be in RELATED state with the ftp's control-connection. I have the following questions.

1) Can it do a similar tracking operation when data-connection is setup with non-default ports ?

2) If yes, Does it go through the FTP messages to find out the data-connection tuple (dst_ip, dst_prt, src_ip, src_prt) ? I know that is way too impractical to implement. So how does netfliter really achieves this ?


Does it go through the FTP messages to find out the data-connection tuple (dst_ip, dst_prt, src_ip, src_prt) ? I know that is way too impractical to implement.

Yes, that is exactly what it does. Why do you think it's too impractical?

You can look at the code yourself here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/net/netfilter/nf_conntrack_ftp.c

Edit: OK, after your later comments I think I now understand what you meant.

The kernel would only need to analyze the beginning of the first few data packets of every TCP connection to see if it looks like a FTP control connection or not, and only mark the actual FTP control connections for further analysis. Only the connections that look like FTP would be monitored for data-connection tuples.

But a few years ago, it turned out that such fully-automatic tracking could be abused for malicious purposes. So with modern kernels, you now need to explicitly set up iptables connection tracking helper rules for protocols that need them, and that means if you use a non-default destination port for the FTP connection, you'll need a custom rule for that. But now you can fully control which interfaces, ports and connection destinations/directions will get the tracking helpers and which will not.

The connection tracking helper rule for FTP in regular should look like this:

iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp

If you have a firewall that only accepts connections to specific inbound ports, you might also need a rule like this in your INPUT and/or FORWARD chain to accept the inbound active FTP connections:

iptables -A FORWARD -m conntrack --ctstate RELATED -m helper --helper ftp -p tcp --dport 1024: -j ACCEPT

For data connections of control connections using a non-default port, you'll need a slightly modified rule, e.g. to accept data connections belonging to a control connection in port 2121:

iptables -A FORWARD -m conntrack --ctstate RELATED -m helper --helper ftp-2121 -p tcp --dport 1024: -j ACCEPT

By the way, there are several connection tracking helper modules available:

  • ftp for FTP protocol, obviously.
  • irc for the Internet Relay Chat protocol. Port numbers will vary.
  • netbios-ns which you should not need for anything any more, since the WannaCry worm proved the SMB 1.0 protocol (that was used with the old NetBIOS style Windows filesharing) has a fatal flaw. Standard port for this would be 137/UDP.
  • snmp for the Simple Network Management Protocol, standard port 161/UDP.
  • RAS and Q.931 for h.323 video-conferencing sub-protocols (the old Microsoft NetMeeting etc). Ports 1719/UDP and 1720/TCP respectively.
  • sip for the SIP internet telephony protocol. Standard port 5060, both TCP and UDP supported.
  • sane for the network protocol of the SANE scanner software, standard port 6566/TCP.
  • pptp for the RFC2637 Point-to-Point Tunneling Protocol, a form of VPN.
  • tftp if you need to pass TFTP connections across a NAT.
  • amanda for the network protocol of Amanda backup software.
  • 1
    Also the FTP protocol mandates that each command should wait for its matching reply (rfc 959 chap 5.4) : multiple commands won't be pipelined (like is possible in say IMAP4). This helps the kernel implementation to stay simple. – A.B May 20 '20 at 22:00
  • Thanks for the information. I was thinking it will be an overhead to analyze the information in every packet. So in that case even if ftp when ran on non-default ports should get tracked ! And for that kernel analyze every packet that pass through ! Knowing this, I am in search of disabling netfilter as a whole , lol :) . Is it not an extra over head ? Are there any comparison graphs in that direction ? – m0hithreddy May 21 '20 at 3:14
  • @telcom Thanks ! That is very informative. – m0hithreddy May 22 '20 at 5:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.