Re: New ftp behavior

[arager () McGraw-Hill com]

     Delmer,
     
     I doubt this is caused by a load balancing system -- load balancing 
     would probably keep the session and data ports at the same host for a 
     FTP session.
     
     
     I've seen this exact message from an ANS Interlock firewall [a quick 
     WHOIS shows that you use ANS for name services] communicating with a 
     host behind a SCC Sidewinder firewall.
     
     
     This can happen if someone has a NATing firewall sitting in front of 
     their DMZ that allows internet connections into the DMZ via 
     transparent proxies...[or perhaps even with packet filters and NAT]  
     
     Here's a quick picture:
     
     
     client----[internet]----firewall--[dmz]--firewall--[internal network]
                                        |
                                    FTP Server
     
     A more common version might be:
     
     client----[internet]----firewall---[internal network]
                               |
                             [dmz]--FTP server
     
     The FTP client requests a connection to a destination host that is 
     actually in the DMZ, and the remote firewall intercepts the request 
     and passes it thru to the DMZ host.  The DMZ host replies back, but 
     the remote firewall is NATing the response so it appears that the 
     reply is coming from another host [the remote firewall] instead of the 
     FTP server.  Sometimes this is accepted by a client firewall -- What 
     normally causes a problem is when the FTP server opens a data port 
     back to the client.....the source IP gets NATed and the client 
     firewall has a fit.  If there's not a firewall at the client site, the 
     client normally won't complain at all.
     
     
     I have seen this with a Sidewinder firewall in particular. Probably 
     happens with others as well if you are NATing and doing some passthru. 
     The funny thing is that many HTTP firewalls normally won't complain 
     about this type of activity when similar things occur with HTTP. [ie 
     -- allow a request to one ip address, reply from another]  I have 
     often thought this to be a potential hole with some firewall 
     implementations....but haven't taken the time to try to break it yet.
     
     
     
     Is this a common implementation?  Others have any other feedback?
     
     
     Anton Rager
     Network Engineer
     Standard&Poor's Compustat
     arager () McGraw-Hill com


______________________________ Reply Separator _________________________________
Subject: New ftp behavior
Author:  <dharris () kcp com> at ccnode
Date:    10/23/97 11:18 AM


This one is new to me so I don't know what to do about it.
     
I had a customer trying to use Netscape Navigator to download a file 
through an ftp:// URL on a Web page at a vendor site. They received the 
error
     
   FTP File Transfer Failed: The FTP request could not be completed because 
   the server is responding in an insecure manner. 
     
I checked the logs and discovered that, although the original ftp 
connection was made to xxx.xxx.xxx.yyy, the response was coming from 
xxx.xxx.xxx.zzz.  The firewall very properly considered this an attempt to 
hijack an open port and closed the ftp transaction.
     
What causes the remote site to behave this way?  It looks like the command 
portion of the ftp transaction is done with xxx.xxx.xxx.yyy while the data 
portion is done with xxx.xxx.xxx.zzz. Maybe this is done for load-sharing, 
but it sure doesn't get past MY firewall.
     
                                Delmer