Subject: ftp-gw on dmz zone of Checkpoint Firewall

From: Ted Keller <[email-masked]>
Date: Mon, 19 Feb 2001 20:18:10 -0500 (EST)

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

Hello,

I am trying to implement the ftp-gw process within a DMZ zone of a
checkpoint firewall.  All other proxies seem to work there - but the
ftp-gw appears, in conjunction with checkpoint, drops the connections to
the remote host.

The configuation is as follows.....

client --->checkpoint -->ftp server
             |  ^
             v  |
            ftp-gw

I see the connection made to the ftp server from the client (via the
ftp-gw) - but as soon as the connection is made (command connection)
someone hangs up - the ftp server complains - the ftp-gw doesn't record
any errors - just terminates the connction.

Has anyone tried to implement this or a similiar process?  Looking to do
this to eliminate inbound data connections from external ftp servers (or
whatever replies....).

Any help is appreciated.

ted keller

---

From: "List User" <[email-masked]>
Date: Mon, 19 Feb 2001 20:44:56 -0600

Yes, we were attempting that at a point (when we were changing
over from FWTK to checkpoint).  There some problems with the
checkpoint security servers that we keep running into.  The main
work-around that we were able to do was to not use any of the checkpoint
security servers at all.  (They would keep grabbing connections and wouldn't
follow through properly).

If it's not this simple then you'll need to track it with the fw monitor
commands or call up your vendor.

Steve

---

From: Ted Keller <[email-masked]>
Date: Tue, 20 Feb 2001 17:04:56 -0500 (EST)

This problem seems to now be solved.  My Checkpoint wizard made the
following fixes to the checkpoint base file - not this is 4.0 sp7...

 I placed the following fix in the base.def file
  
  1) FIX 1: Remove the PASV newline check:
  
  --Comment out (with // marks) the following line:
  
       #define FTPPORT(match)        (call KFUNC_FTPPORT <0x1|(match)>)
  
  --Uncomment out the following line:
  
       //#define FTPPORT(match)  (call KFUNC_FTPPORT <(match)>)
  
  =====================================================================
  2) FIX 2: Remove the FTP control port newline check:
  
  --Comment out the following line:
       #define FTP_ENFORCE_NL

tek

---

From: Ted Keller <[email-masked]>
Date: Tue, 20 Feb 2001 21:30:00 -0500 (EST)

Rick,

You force me to think!  I suspect fix 1 did actually resolve my problem.
It may not be the best general solution...

If you remember the picture - my inside client connected to port 21 of the
ftp-gw proxy server - through the checkpoint firewall.  That consumed port
21.  The proxy server then connected - again through the same checkpoint
firewall to the destination computer on port 21.  This, if I understand
things correctly, would match your description of source port and target
port being the same and consumed.  Therefore, this probably did resolve my
issue as far as the ftp-gw is concerned.  Now, what I have to think about
is if I permit general internal clients to make direct ftp connections
through the firewall without using the ftp-gw proxy server.  Do I open up
any issues there?

Seems as if the newline thing was something they added "becaused it fixed
other clients with similar problems".  They talked about a server at
compaq that required these fixes.  I wonder if that part of the fix was
to resolve a site specific issue.

Can you point me to some information regarding the Dug Song findings?

Many thanks.

tek

On Tue, 20 Feb 2001, Rick Murphy wrote:

> At 05:04 PM 2/20/01 -0500, Ted Keller wrote:
> That's not a newline check - changing this allows active FTP to use a 
> destination port for the control connection that's assigned to an existing 
> service. Since some of the high ports have service definitions, there's 
> some chance of collision; of course, that leaves you open to FTP bounce 
> attacks. Actually, this change probably had no effect on fixing your problem.
> 
> This is a newline check; commenting that out leaves you wide open to the 
> exploit that Dug Song and gang found and publicised at the Black Hat 
> briefings.
> 
> It seems to me that these recommendations should have come with some 
> warnings of the possible side-effects.. do you consider the possible 
> security risks reasonable?
>          -Rick
>

---

From: Rick Murphy <[email-masked]>
Date: Tue, 20 Feb 2001 23:52:46 -0500

>It may not be the best general solution...

Now that you point out the picture, that's a good possibility - that fix is 
much lower risk.

 >Can you point me to some information regarding the Dug Song findings?

I'll see if I can dig up a reference off securityfocus.com; basically, with 
Firewall-1 you could arrange a FTP server to send text containing an 
embedded newline followed by the text "PORT ....." - that would cause the 
firewall to open the port mentioned in the banner string. All you've got to 
do is own a FTP server someone's going to through a FW-1 box.

My basic problem is that this change removes a fix for a security hole in 
the firewall. There should be some warnings about the consequences of 
turning this off.
(The Compaq problem actually is a limitation of the newline patch - any FTP 
site with a long banner message won't work unless you turn the fix off.)
          -Rick

---

From: Rick Murphy <[email-masked]>
Date: Tue, 20 Feb 2001 20:10:30 -0500