> Gauntlet floats port 20 because it makes FTP work reliably.
>
> If you read the RFC (snippet follows), you will find that there are issues
> with port reuse if you force port 20. Specifically, if you do things like
> MGET * where the data port is closed and reopened rapidly, you may
> encounter that the previous data port connection has been disconnected
> from FTP but that TCP/IP hasn't completed the disconnect. As a result, the
> subsequent open will fail since the source/destination port combination is
> still active. This problem is clearly stated in the RFC; especially if you
> use the "STREAM" transfer mode since the end-of-transfer is indicated by
> disconnecting the socket. Since many FTP implementations only support
> STREAM, this is the de-facto mode.
>
> To make matters worse, if you have multiple processes doing FTP transfers
> between 2 systems (or firewalls, if the IP addresses are reset to those of
> the firewall), then one processes ability to open an FTP data socket can
> be refused because another process has the FTP data socket already open.
> That is, your FTP can fail because another FTP (that you don't know about)
> is active. Sounds unlikely but we've seen it.
>
> This is partly since the default client port is 21 and the default server
> port is 20. Hence, if you use the defaults (no PORT or PASV commands), the
> data connection ALWAYS uses the same 2 port numbers. If you use PORT, then
> the server opens the connection using the port that you specify (which
> some systems uses again once the socket has been disconnected) while the
> server uses a source port of 20 (this is the only case that I know of
> where the originator's source port is not allowed to float). In theory,
> one could use PORT to float the client and PASV to float the server - I
> don't know of any implementation which does both commands. It IS allowed
> in the RFC (see snippet). As a result, if Gauntlet (or other FTP
> implementations which want to float off port 20) used the PASV command,
> Checkpoint would be required (per RFC) to allow this. The comment in the
> RFC about "either of these actions is enough to get a different data
> connection" is weak since many systems recycle port numbers following a
> disconnect.
>
> There is no security ramifications that I know of. There are operational
> problems in that you may find that your data transfers fail. We lived for
> years without any data transfer failures until we had to force port 20 for
> Checkpoint. Now, they are commonplace.
>
> Subsequent RFCs dealing with security (dealing with guessing ports for
> hacking) say that you shouldn't force port 20. I've been told that
> Checkpoint says that the FTP RFC requires that you use port 20; others say
> that its only a recommendation. To my knowledge, the only vendor which
> requires port 20 is Checkpoint (maybe other packet level firewalls). Using
> both PORT and PASV would eliminate any issues (unless Checkpoint doesn't
> support PASV which I don't know).
>
> Note: The problems with port 20 isn't really a Gauntlet or Checkpoint
> problem; its a known design flaw in the FTP RFC. Gauntlet's solution is to
> float the port (but without issuing PASV commands which they really
> should). Checkpoint's solution is to simply pass only packets which use
> port 20 and say that its not their problem (since they are only passing
> packets and aren't either endpoint, this is a nice "head in the sand"
> approach).
>
> Personally, I think that the only reliable solution (which Gauntlet and
> others could do) is to use both PORT and PASV commands for ALL connections
> (which is clearly permitted by the RFC). Gauntlet could, when it sees one
> of its protected systems asking for a data socket to be opened, could
> assure that both a PORT and PASV command was issued for the connection
> between Gauntlet and the other end. (Naturally, it can only insert
> commands on the outbound direction of the command stream.) This, however,
> might cause problem with security systems which don't like PASV commands
> but those systems can't argue that using both PORT and PASV commands goes
> against the RFC.
>
> [snippet follows]
>
> Negotiating Non-Default Data Ports: The User-PI may specify a non-default
> user side data port with the PORT command. The User-PI may request the
> server side to identify a non-default server side data port with the PASV
> command. Since a connection is defined by the pair of addresses, either of
> these actions is enough to get a different data connection, still it is
> permitted to do both commands to use new ports on both ends of the data
> connection.
> Reuse of the Data Connection: When using the stream mode of data transfer
> the end of the file must be indicated by closing the connection. This
> causes a problem if multiple files are to be transfered in the session,
> due to need for TCP to hold the connection record for a time out period to
> guarantee the reliable communication. Thus the connection can not be
> reopened at once.
> There are two solutions to this problem. The first is to negotiate a
> non-default port. The second is to use another transfer mode.
> A comment on transfer modes. The stream transfer mode is inherently
> unreliable, since one can not determine if the connection closed
> prematurely or not. The other transfer modes (Block, Compressed) do not
> close the connection to indicate the end of file. They have enough FTP
> encoding that the data connection can be parsed to determine the end of
> the file. Thus using these modes one can leave the data connection open
> for multiple file transfers.
>
> -----Original Message-----
> From: Mordechai T. Abzug [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, October 13, 2000 5:05 AM
> To: [EMAIL PROTECTED]
> Subject: gauntlet 5.0, active FTP, and port 20
>
>
> We had a problem with gauntlet 5.0 (Solaris, no transparency) where
> active FTP users from behind Checkpoint firewalls, ftping through our
> Gauntlet firewall were having trouble with the data portion of
> commands. In particular, checkpoint didn't like that gauntlet used
> anonymous ports for the data sockets instead of port 20. Looking
> through the manual, there's a way to change this -- but are there
> security implications? Why was it set differently to begin with? I
> called Gauntlet tech support, and so far, they can't tell me why
> Gauntlet defaults this way.
>
> [I know that there are problems with blanket rules allowing port 20
> through, but I would think that wouldn't be an issue here.]
>
> --
> Mordechai T. Abzug
> [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
> Linux red-sonja 2.4.0-test9-morty2 #4 Mon Oct 9 03:16:59 EDT 2000 i686
> unknown
> "I believe OS/2...to be the most important OS...of all time" Gates '87
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
