netbsd-help: Re: ports for ftp

Subject: Re: ports for ftp
To: None <Timothy.Musson@zin-tech.com>
From: Daniel R. Killoran,Ph.D. <drkilloran@speakeasy.net>
List: netbsd-help
Date: 08/01/2005 19:15:43

On Aug 1, 2005, at 5:39 PM, Timothy A. Musson wrote:
> Daniel R. Killoran,Ph.D. wrote:
>
>> On Aug 1, 2005, at 11:18 AM, Timothy A. Musson wrote:
>>
>>> I believe the term you want to search for in your firewall 
>>> documentation is "keep state".
>>>
>
My firewall is hardware - an Asante FR3004LC to be exact, and has no 
provision for such stuff. I also use my OS-X software firewall as 
well, as an additional obstacle, but it doesn't interfere with the FTP.
>> Thanks all! A little "sniffing" revealed that ftp had grabbed a 
>> port in the 5100 range and insisted on using it for data transfer 
>> or something like that. Odd - I thought it used port 20 for 
>> that. Anyway, I have to open up that range to get ftp to work.
>> Dan Killoran
>>
>
> No, you really need to enable "keep state", "connection tracking", 
> or "session tracking" in your firewall. Why? The short story is 
> that FTP just doesn't work through a firewall without it. There are 
> caveats, explained in the the long story below. Here's what happens:
> (Approximately; if I'm too far off I'm sure someone will enlighten 
> us both. I'm leaving out source port numbers to keep things simple.)
>
> FTP Client -- Connection request to port 20 --> FTP Server
> FTP Client <-- "Yeah, I'm here. I'll connect back to you on port 
> 12345." -- FTP Server
> Connection on Server port 20 is closed.
> FTP Client opens port 12345.
> FTP Server spawns a child.
> FTP Client <-- Connection request on port 12345 -- FTP Server 
> (child process)
> FTP SESSION over client-side port 12345 (put/get requests, data 
> transfer, et. all)
>
> Now, IIRC, that client-side port (12345 in this example) is random 
> and can be any of the non-privilege ports, meaning you'd have to 
> allow public access to essentially all of the ports on your 
> computer. That's not much of a firewall, obviously. What this means 
> for your current configuration is that the next time you try an 
> FTP, you are likely to have more problems. How often you have 
> problems depends on the percentage of the public ports that you've 
> already opened up.
>
> Most firewalls nowadays have been made smart enough to watch for an 
> outgoing connection request and then dynamically open a single port 
> for a short amount of time in order to allow the back-connection 
> that standard FTP requires. This is what terms like "connection 
> tracking" refer to.
>
> If you're having problems with a dedicated firewall unit (like a D- 
> Link or Linksys, etc.) that you configure through a web page, the 
> option you're looking for might be under a page labeled 
> "Applications" or some such. You don't want one for "allow incoming 
> FTP requests" (unless you want to run an FTP server). You want 
> something that allows Active FTP sessions.
>
Aha! Then that's what I will do! The FR3004LC DOES have provision for 
that, and probably includes FTP.
> The Passive FTP stuff that Theo Borm was talking about is where the 
> FTP Server does not make a back-connection to the client. This mode 
> of FTP works fine with older and/or simpler firewalls, but many 
> large FTP sites do not allow that type of connection due to 
> performance issues (all traffic happens over port 20, as you said 
> earlier; meaning that only one client can connect at a time). Your 
> FTP client likely attempted passive mode by default and got 
> rejected, but you can go ahead and try to force it anyway (with -p ?).
>
I do, in fact. There is a checkbox in the OS-X firewall software for 
this. That's probably why that firewall gives no trouble.
Thanks to all!
Dan Killoran