Subject: PORT ftp problem

From: Andreas Priebe <[email-masked]>
Date: Tue, 06 Feb 2001 18:06:04 +0100

[To be removed from this list send the message "unsubscribe fwtk-users" in the
BODY of a mail message to [email-masked].]

Hi,

I use the ftp-gw to allow access from external machines.
Some sites which connect to us experience problems, which I nailed
down to the following scenario:

They connect with PORT, e.g. with

PORT 194,141,101,131,239,255

they request a connection to data port 61439.
The ftp-gw opens a connection from port 4146 (e.g.) -
i.e. not from port 20.
Is this conforming to the RFCs? The admin of the
remote site claims, that the connection should
originate from port 20 in case of the "normal" (non passive)
scenario so they effectivly block my connection attempts
for the data caonnection on their firewall.

Any references? I tried to extract the information
form RFCs 959 and 1123 but without sucess.

Thanx for any information,

Andreas

---

From: Rick Murphy <[email-masked]>
Date: Tue, 06 Feb 2001 17:39:43 -0500

>The ftp-gw opens a connection from port 4146 (e.g.) -

That's right.

>Is this conforming to the RFCs?
Yes.
The recommended default data port is control port - 1 (or port 20).
Some filters allow *anything* with source port 20 to sail through in order 
to allow FTP data connections; sounds like that's what your remote site 
admin wants.
There's a patch for the ftp-gw to permit this, but you really should be 
warning your remote admin that if they're really trusting everything with 
source port 20 to sail through their filters, they're wide open to attack.

Get the patch from <http://www.fwtk.org/fwtk/patches/patches.html#2.9>
         -Rick

---

From: Andreas Priebe <[email-masked]>
Date: Thu, 08 Feb 2001 15:12:42 +0100

Hi Rick,

> The recommended default data port is control port - 1 (or port 20).

Have you any concrete references in some RFC that other data ports
are allowed?
I little bit of digging in Stevens' Vol. I gives me:
"... The server's end of the data connection always uses port 20."

(6th printing, 1985, p. 425 - yes I know its ancient ... :-)

Andreas

---

From: Rick Murphy <[email-masked]>
Date: Thu, 08 Feb 2001 21:49:05 -0500

>Have you any concrete references in some RFC that other data ports

RFC 959 ("FILE TRANSFER PROTOCOL"). The specification of the data port to 
be used (20) calls it the "default data port", and says that the user agent 
can initiate the use of non-default ports (Section 3.3, Data management.)

You can require the use of port 20 only if you remove the word "default".
Whether ftp-gw is a server agent or a user agent, however, is quite debatable.

>"... The server's end of the data connection always uses port 20."

That's an unjustified absolute. "usually" is more accurate.

Basically, there's no way to guarantee that you can always use port 20. 
(Because of a previous connection in close-wait state.) For most ftp 
servers, that's not a big problem, but firewalls occasionally run into 
this. All you can do in that case is to try another source port, or 
generate an error. Using a random port eliminates this problem, but it's 
not in the spirit of RFC 959.
         -Rick

---

From: Andreas Priebe <[email-masked]>
Date: Fri, 09 Feb 2001 11:07:12 +0100

> Whether ftp-gw is a server agent or a user agent, however, is quite debatable.

But in my case I think it is quite clear that ftp-gw is the server
agent,
as we talk about a remote ftp client, who ftp's into my ftp-gw.
So this together with RFC 959 (Sect. 3.3) "and only the User-PI may
initiate
the use of non-default ports." seems to indicate (at least for me),
that the behaviour of ftp-gw is not correct.

I am not sure if I made really clear, what I mean, so just to be
sure:

1. remote client opens ftp control channel from port >1024 to
ftp-gw-port 21.
2. remote client says PORT a,b,c,d,e,f
3. ftp-gw opens data channel from port >1024 to remote client port
e*256+f
4. this fails, because firewall on the side of the remote clients
expects
   "active" ftp (negotiated with PORT) always to come from port 20 (and
   not from random port >1024 as ftp-gw does).

BTW: The fix in http://www.fwtk.org/fwtk/patches/patches.html#2.9 does
not work for me, because It collieds with patch 2.11 which I have
applied.

Andreas

---

From: Rick Murphy <[email-masked]>
Date: Fri, 09 Feb 2001 13:53:47 -0500

>But in my case I think it is quite clear that ftp-gw is the server

Not always. It's the user agent when it's talking to the remote FTP server 
at the very least. :-)

>    not from random port >1024 as ftp-gw does).

I know that's the problem; in my opinion, that "expectation" isn't 
guaranteed; however, the patch exists to try to meet the expectations when 
possible.

>not work for me, because It collieds with patch 2.11 which I have

I think patch 2.11 adds a data-port capability already - if not, you should 
be able to add the code from patch 2.9 "by hand" into the callback() 
routine. I might suggest splitting the setting into "pasv-port" and 
"data-port" netperm-entries, though.
         -Rick

---

From: Carson Gaspar <[email-masked]>
Date: Fri, 09 Feb 2001 18:19:07 -0800

> Have you any concrete references in some RFC that other data ports

I really wish that all the ignorant "the RFC says it has to use port 20" 
folks would actually bother reading the RFC themselves. Until then, here is 
Yet Another FTP Data Port Explanation. <sigh>

The RFC states that the default data port SHOULD be one less than the 
control port. So:

- If FTP is on a port 21, the server SHOULD use port 20. But this is a 
SHOULD, not a MUST, therefore other ports are legal.
- Similarly, if you install an FTP server on port 666, it SHOULD use port 
665 as a data port, but it may use a different port.

-- 
Carson Gaspar - [email-masked]
Queen trapped in a butch body

---

From: Tor Perkins <[email-masked]>
Date: Mon, 12 Feb 2001 10:09:25 -0800

> not work for me, because It collieds with patch 2.11 which I have

The 2.9 patch comes with the 2.11 patch; If you've applied 2.11 then
you are covered, you can use:

   ftp-gw: data-port 20

Here's three qoutes from http://www.interhack.net/pubs/fwfaq/:

   The traditional behaviour of FTP servers in active mode is to
   establish the data session FROM port 20, and to the dynamic port on
   the client. FTP servers are steering away from this behaviour
   somewhat due to the need to run as ``root'' on unix systems in
   order to be able to allocate ports below 1024.

and...

   In some cases, if FTP downloads are all you wish to support, you
   might want to consider declaring FTP a ``dead protocol'' and
   letting you users download files via the Web instead.  The user
   interface certainly is nicer, and it gets around the ugly callback
   port problem.

and...

   Checking the source port on incoming FTP data connections is a weak
   security method. It also breaks access to some FTP sites. It makes use
   of the service more difficult for users without preventing bad guys
   from scanning your systems.

-- 
}    __o
}  _(\<._  Tor Perkins           Send me e-mail with subject "get
} (_)/ (_) 981998128@noidDoTnet  pgp key" for automatic response.

---

From: Andreas Priebe <[email-masked]>
Date: Tue, 13 Feb 2001 18:52:04 +0100

> you are covered, you can use:
Indeed? I thougth the 2.9 thing is the source port for "normal" ftp, in
2.11 data-port ist the port given for passive ftp?!?

---

From: Tor Perkins <[email-masked]>
Date: Wed, 14 Feb 2001 09:18:13 -0800

> Indeed? I thought the 2.9 thing is the source port for "normal" ftp,
 > in 2.11 data-port is the port given for passive ftp?!?
  
When I wrote the 2.11 patch, it so happened that I had the 2.9 patch
already applied to my ftp-gw.c.  I liked the way it worked when the
client did a PORT to ftp-gw.  I copied this behavior for when the
ftp-gw does a PASV to a server.  In both cases ftp-gw is initiating
the data connection.  'data-port' (the config option) and 'data_port'
(the C variable) are both being used in these cases.
  
If you do not use the 'pasv true' config option, ftp-gw will still use
'data-port' as per the 2.9 patch when interacting with the client,
it'll just not do PASV when it's talking to a server.  It'll PORT the
server using a random high port.  The server will then initiate the
data connection (the port it picks as it's source port is out of our
control).
   
By the way, PASV is just as "normal" as PORT.  :)

--
}    __o
}  _(\<._  Tor Perkins           Send me e-mail with subject "get
} (_)/ (_) 982166820@noidDoTnet  pgp key" for automatic response.