Ramin, Tony & Rusty,
What we are experiencing seems to be some "naziness" in the policing of incoming traffic related to FTP connections.
This is exactly where this recent security patch was applied.
The h1,h2,h3,h4 address mentioned before (see below) is the destination of address of the outgoing FTP data stream right? The source address of ftp-data connections is not normally specified in a PORT command because there is normally no need for it.
Normally, a ftp client becomes a 'ftp server' when you start a download and it listens on a port that is stated through the ftp control connection. Normally when there is no NAT running the FTP client takes the first connection on the destination port of the incoming data stream, provided it has the right source port (also specified in the PORT command options). (Did I get this right I'm not a network programmer :-)
Does netfilter take this one step further and check to see that the an incoming connection RELATED to an existing NATted ftp session by applying these checks:
- The incoming connection is to one of it's local external ip's (one specified in port command),
- it comes in from a connection with a certain source port (not sure if netfilter checks this)
- the connection must also come from a specific IP address as well - the ip address of the endpoint of the outgoing FTP control session.
Seeing the ^^^ source ip address is not specified in the PORT command, does netfilter just assume it will be same one
as the endpoint of the outgoing ftp control connection. Assumptions are not good :-( in our case and netfilter doesn't expect the incoming data connection to come in from where it really does. In most cases on the internet the assumption would be right, but with lots of load balencing implementations of FTP out there with different ip addresses for incoming and outgoing connections (not everybody wants to use big FreeBSD boxes like cdrom.com) people may run into this problem with netfilter more often.
FTP doesn't state the source IP of the data connection in a PORT command to expect the incoming connection from, because normally a ftp client checks only for the correct source port - not the 'correct' source IP as well. Does netfilter differ from standard ftp clients and check the source IP matches what it expects? (I'll guess yes for the rest of the email)
Was this change implemented with the recent security patch? IF this change to scrutinize source ip address for ftp data connections has been done, netfilter then breaks ftp RFCs. Standard ftp clients don't scrutinize the ip address of incoming ftp-data connections right? - just the source port.
Can someone confirm that netfilter is doing this source ip check in the ftp_contrac module.
If this is so, could I request that there be a compile time define to not scrutinize the source ip address of incoming ftp data connections, but use source port instead (which is set to 0 or ignored in the current implementation right?).
I read the recent article about the patch http://netfilter.samba.org/security-fix/index.html#desc-ftp-160401. I'll make sure only a fwe services can come in on the ESTABLISHED and RELATED connections - but I want netfilter not to expect a guessed IP for incoming ftp data connections - just a certain source port!
Can there be a compile time option to make netfilter follow RFCs both for the ftp_contrac module as well as the entire project in general? E.g. Squid proxy has a configure option to enforce it to follow all RFCs, could we expect the same from netfilter in the future?
Best Regards,
Luke McKee
[EMAIL PROTECTED]
Network Administrator,
Customer Systems Support
Webtel Pty Ltd
Ph: +61 2 9921 1234
Fax: +61 2 9923 1700
Web: http://www.webpay.com.au
-----Original Message-----
From: Ramin Alidousti [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 11:09 AM
To: Luke McKee
Cc: '[EMAIL PROTECTED]'
Subject: Re: FTP NAT/Conntrack problems
Hi Luke,
On Thu, May 17, 2001 at 10:14:37AM +1000, Luke McKee wrote:
>
> In last post I forgot to give a few details.
>
> Running kernel 2.4.4 latest iptables. No patch-o-matics.
> NAT FTP support compiled into kernel.
>
> Question. When ftp servers esablish outgoing ftp-data connections from a
> different IP address to what a client connected to them, does this break
> RFCs?
With the PORT command you tell the server where to connect, it has the
following structure:
PORT h1,h2,h3,h4,p1,p2
Meaning that the IP to connect to by the server does not have to be the
original IP (where the client set up the control connection). This way
a client can transfer data between two server:
Taken from rfc959:
Control ------------ Control
---------->| User-FTP |<-----------
| | User-PI | |
| | "C" | |
V ------------ V
-------------- --------------
| Server-FTP | Data Connection | Server-FTP |
| "A" |<---------------------->| "B" |
-------------- Port (A) Port (B) --------------
User-PI - Server A User-PI - Server B
------------------ ------------------
C->A : Connect C->B : Connect
C->A : PASV
A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
C->B : PORT A1,A2,A3,A4,a1,a2
B->C : 200 Okay
C->A : STOR C->B : RETR
B->A : Connect to HOST-A, PORT-a
So, as you can see the ftp session between A-B causes a data session between
B-C. This implies that the two end points does not have to be the same for
both control and data connections.
I'm not sure about the implementation of ip_conntrack_ftp, though.
Ramin
>
> The problematic ftp servers are on the other side of the nat box of course
> and may be behind firewalls.
>
> Thanks,
>
> Luke
