I think Checkpoint may have added additional "rules" for the packet
containing the "PORT" command. A couple of months ago there was a security
issue with almost any packet-level firewall related to the "PORT" command
and FTP. I'm not sure of the details but I think the problem was that if you
could cause a packet to be made with an arbitrary PORT command sequence, the
firewall would honor it and open a bogus port. As I recall, one option was
to try to open a non-existent file called "PORT aaa.bbb.ccc.ddd..." and pad
that so the error message would position the PORT command at the start of a
packet. I believe Checkpoint "closed" this by additional rules regarding the
PORT packet.
Since Checkpoint (I don't know about the other packet firewalls, but I'm
assuming they work the same) don't/didn't remember any/much state, forcing
the use of PORT 20 is the only way they to trigger the check for validity of
the packet. If both ends floated, then they'd need to be able to validate a
connection where neither source or destination is a well-known port making
it very difficult to know which validation rule to apply. My understanding
is that there is limited state information kept so that they know that there
is an FTP command stream running so that they know to start looking for a
PORT command but I don't know this for sure.
The requirement of having the PORT command completely exist in 1 packet is a
real bend since you are now dictating that the lower levels of the stack
need to behave in a specific manner in order to convey application
information. But, if you are not assembling packets (which is exactly what a
packet-level firewall doesn't want to do), then you need to get all the
necessary information to make the go/nogo decision in one packet. Also,
assembling packets is impossible if you are allowing packets to shift
between multiple firewalls for load balancing.
Can anyone answer the question if Checkpoint allows both a PORT and PASV
command to be used when setting up the data socket?
> -----Original Message-----
> From: Marcus J. Ranum [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, October 16, 2000 9:44 AM
> To: Rick Murphy; Mordechai T. Abzug
> Cc: [EMAIL PROTECTED]
> Subject: Re: gauntlet 5.0, active FTP, and port 20
>
> Rick Murphy wrote:
> >Gauntlet bug, so we eventually gave up and added the option. We had
> similar problems with Checkpoint requiring all of the "PORT" command -
> including the line terminator - be in one TCP packet.
>
> Yeah, I remember that "feature" of the checkpoint. When
> I saw that, I realized immediately that "stateful multi-level
> packet inspection" doesn't mean anything like TCP reassembly
> and/or state tracking. Which means that checkpoint was/is
> basically not doing a whole lot...
>
> > -Rick (glad I'm not doing firewalls any longer)
>
> I'm also a charter member of the "glad I'm not doing firewalls
> any longer" club. :)
>
> mjr.
>
> -----
> Marcus J. Ranum
> Chief Technology Officer, Network Flight Recorder, Inc.
> Work: http://www.nfr.net
> Personal: http://www.ranum.com
>
> -
> [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.]
