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