Firewall Wizards mailing list archives
Re: New ftp behavior
From: arager () McGraw-Hill com
Date: Thu, 23 Oct 97 18:21:41 -0500
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
Current thread:
- New ftp behavior dharris (Oct 23)
- Re: New ftp behavior Jyri Kaljundi (Oct 24)
- <Possible follow-ups>
- Re: New ftp behavior arager (Oct 23)
- Re: New ftp behavior Wyllys Ingersoll (Oct 24)
- Re: New ftp behavior Vern Paxson (Oct 23)
- New ftp behavior Petri Virkkula (Oct 27)
- Re: New ftp behavior David Aylesworth (Oct 27)
- RE: New ftp behavior Safier, Adam (GEIS) (Oct 27)
- Re: New ftp behavior Bernd Eckenfels (Oct 30)