Question + patch: FTP conntrack fails to recognize a PORT command

Question + patch: FTP conntrack fails to recognize a PORT command

[Peter Parkkali]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

Hi all,

I've found a case where an ftp PORT command is not recognized 
by help() in ip_conntrack_ftp.c. This happens only with one 
particular client, so there could be something wrong w/ the 
client too. Anyway, in this case the address in the PORT command
is not rewritten but instead the 192.168.etc address is let through.

The bug can be avoided by commenting out the "return NF_ACCEPT;"
from line 298 (uhh... 2.4.22 source, not cvs, sorry). This allows
the rest of help() to find the "PORT" string, do NAT etc. 

This works, but since I don't really understand the code, I thought
somebody could advice me on the sanity of this approach? ;) Is it safe
to bypass this check is could the actual bug be somewhere else?


The affected code (patch attached):

        if(!old_seq_aft_nl_set ||
                        (ntohl(tcph->seq) != old_seq_aft_nl)) {
                DEBUGP("ip_conntrack_ftp_help: wrong seq pos %s(%u)\n",
                       old_seq_aft_nl_set ? "":"(UNSET) ",
old_seq_aft_nl);
                return NF_ACCEPT;
        }


   Thanks,
	-peter

-- 
pp / pfp@iki.fi / peter.parkkali@profiz.com / 
040-532 95 80 / +358-40-532 95 80



[-- Attachment #2: ftp_port_cmd.patch --]
[-- Type: text/plain, Size: 474 bytes --]

--- net/ipv4/netfilter/ip_conntrack_ftp.c	2003-11-25 19:47:15.000000000 +0200
+++ net/ipv4/netfilter/ip_conntrack_ftp.c.orig	2003-11-25 19:06:36.000000000 +0200
@@ -295,7 +295,7 @@
 			(ntohl(tcph->seq) != old_seq_aft_nl)) {
 		DEBUGP("ip_conntrack_ftp_help: wrong seq pos %s(%u)\n",
 		       old_seq_aft_nl_set ? "":"(UNSET) ", old_seq_aft_nl);
-		// return NF_ACCEPT;
+		return NF_ACCEPT;
 	}
 
 	/* Initialize IP array to expected address (it's not mentioned

Re: Question + patch: FTP conntrack fails to recognize a PORT command

[Henrik Nordstrom]

On 25 Nov 2003, Peter Parkkali wrote:

> The bug can be avoided by commenting out the "return NF_ACCEPT;"
> from line 298 (uhh... 2.4.22 source, not cvs, sorry). This allows
> the rest of help() to find the "PORT" string, do NAT etc. 
> 
> This works, but since I don't really understand the code, I thought
> somebody could advice me on the sanity of this approach? ;) Is it safe
> to bypass this check is could the actual bug be somewhere else?

It seems iptables makes assumptions on how the PORT command will be sent
which is not true with this client..

Can you please save a "tcpdump -s 1600 -w dump.out host
ip.of.client.station" of the traffic sent by this client, then use ngrep 
to inspect what the client is sending.

Regards
Henrik