Slug PPL,
I thought I would mention this to the slug list. Sorry for the slightly off topic posting earlier that was primarily directed towards netfilter users.
Simply what I am trying to say is some Linux users running NAT in the version in 2.4 kernel can not access some FTP sites that others can access without trouble - because netfilter breaks RFCs. It even affects ftp client running on the nat box itself so if you are running NAT there is nothing you can do apart from login to another machine outside your private network or shut down NAT completely to get to that FTP site.
The ftp servers you can't connect to with NAT running are FTP servers that send file transfers from a different IP to the one you first connected to. Servers that do this are commonly found in High-Availability networks (like those running high-availability Linux clusters - www.linux-ha.org). I just thought I should let you all know this in case anyone else have been having problems with FTP on linux.
I now agree with Cris' comment on the slug home page:
"Unfortunately, whilst everyone was impressed with Netfilter, and Chris's overview of it, no one was willing to entrust a production firewall to Linux 2.4. Perhaps around 2.4.10"
Regs,
Luke McKee
[EMAIL PROTECTED]
Network Administrator,
Customer Systems Support
Webpay, Secure Digital Commerce
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 12:42 PM
To: Tony Pang
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: FTP NAT/Conntrack problems
On Thu, May 17, 2001 at 10:00:41AM +0800, Tony Pang wrote:
> Hi,
>
> I think the case specified in RFC 959 is not the same as which Luke has
> faced. In netfilter, after you have opened a active FTP session to
> 200.249.193.2. If the ftp client has issued the PORT command, e.g. PORT
> 200,249,243,12,4,10,
> you can see that in /proc/net/ip_conntrack,
> EXPECTING: proto=6 src="200.249.193.2" dst=200.249.243.12 sport=0 dport=1034.
There might still be some old ftp servers out there which do not
really care about the security concerns we have when the data connection
comes from a different src as the control data. As you can see sport
is 0 which is a wildcard. To respect the working environment for those
ftp servers, I think that the src could also be 0.0.0.0 to indicate
that the connection may come from anywhere. However, this RFC is the
original protocol and there are other RFC like rfc1579, rfc2428 and
rfc2577 which address some (but not exactly this) security concerns.
I leave the discussion as to accepting the data connection from anywhere
or only from the original ftp server to network security guru's. But I
just wanted to let Luke know that this behavior seems to be old and
correct (I think).
Ramin
> So I think other ftp-data connection will be blocked. I am not familiar
> with RFC 959 so I don't know whether the implementation of netfilter in
> this way is correct or not.
> >
> > 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.
>
> --
> Regards,
> Tony Pang
> Network System Engineer
> DMX Technologies Co. Ltd.
> [EMAIL PROTECTED]
> (852) 25202660
>
--
Ramin Alidousti [EMAIL PROTECTED]
Advanced Development tel +1 703 886 2640
UUNET, A WorldCom Company fax +1 703 886 0536
