ZServer Ftp Active mode through firewall
I believe we discovered a problem with ZServer's ftp server. (Zope 2.1.6) I posted the following to the collector: http://classic.zope.org:8080/Collector/1257/view Has anyone else seen this problem? : ---------------------- It appears that ZServer's active ftp mode may be broken, but probably is only noticed when used in conjunction with a firewall. Ftp Passive mode operates as expected and active mode operates as long as there is no firewall. Observations (Active mode): - client connects, instructs server regarding data port to use. - server appears to never send port 20 reply to client, which is required by the firewall to know that the data port needs to be opened. - client waits on data port. If no firewall, the connection is made. If firewall is blocking high port numbers, the firewall never is instructed to open the data port which is indicated by the server port 20 response (that is never sent), so no connection is made. I saw a number of discussions regarding this topic that indicated that improper DNS configuration was causing the problem. However, this is not the problem in our case. We first noticed that all passive (PASV) mode ftp clients worked correctly, then noticed that all ftp clients on the same subnet or outside the firewall worked correctly, then noticed that active clients inside the firewall were never receiving the port 20 response and that the firewall was blocking the data port from the server. Comments?
Kent, If possible, I'd like you to check whether the FTP server is trying to make the connection from a port other than 20. Then try out a different FTP server that is working through the firewall (on active mode connections) and see if it connects from port 20. If so, we have found the problem. The solution is not obvious to me, however, considering the restriction of allocation of ports below 1024. Guidance is welcome... Shane Kent Polk wrote:
I believe we discovered a problem with ZServer's ftp server. (Zope 2.1.6)
I posted the following to the collector: http://classic.zope.org:8080/Collector/1257/view
Has anyone else seen this problem? :
---------------------- It appears that ZServer's active ftp mode may be broken, but probably is only noticed when used in conjunction with a firewall. Ftp Passive mode operates as expected and active mode operates as long as there is no firewall.
Observations (Active mode): - client connects, instructs server regarding data port to use. - server appears to never send port 20 reply to client, which is required by the firewall to know that the data port needs to be opened. - client waits on data port. If no firewall, the connection is made. If firewall is blocking high port numbers, the firewall never is instructed to open the data port which is indicated by the server port 20 response (that is never sent), so no connection is made.
I saw a number of discussions regarding this topic that indicated that improper DNS configuration was causing the problem. However, this is not the problem in our case. We first noticed that all passive (PASV) mode ftp clients worked correctly, then noticed that all ftp clients on the same subnet or outside the firewall worked correctly, then noticed that active clients inside the firewall were never receiving the port 20 response and that the firewall was blocking the data port from the server.
Comments?
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On 18 May 2000 08:45:02 -0500, Shane Hathaway wrote:
Kent,
If possible, I'd like you to check whether the FTP server is trying to make the connection from a port other than 20. Then try out a
Ahhh! figured it out... 1) ZServer passive mode appears correct. 2) ZServer active mode responds on the *wrong port number* Active mode is supposed to respond from port 20 for the data port but ZServer is using a high port number, similar to passive mode. Passive mode succeeds because the firewall allows outgoing high port#'s, but blocks incoming high port#'s unless it sees a port 20 response from the outside server. Active mode observed behavior with ZServer : - client connects to server port 21, requests (high#) data port - server responds from server high p# to client data port - client receives data port response (unless firewall blocks)
different FTP server that is working through the firewall (on active mode connections) and see if it connects from port 20. If so, we have
Active mode observed behavior with WUFTP server : - client connects to server port 21, requests (high#) data port - server responds from server port 20 to client data port - (firewall recognizes port 20 response, enables data port) - client receives data port response (Note that wuftpd runs as root...)
found the problem. The solution is not obvious to me, however, considering the restriction of allocation of ports below 1024.
Exactly. If ZServer isn't running with root privs, it *can't* respond on port 20.
Guidance is welcome...
What might be the recommended procedure to allow ZServer to open port 20? Possibly detect if running with root privs and use port 20 instead of high port# for active mode? If we could simply solve this problem by replacing our active ftp clients with passive ones, it would be great, but it still doesn't solve the problem of clients *elsewhere* which are running behind a firewall and attempting to contact our server... And here I thought active ftp clients had gone by the wayside years ago, considering the problem they have with firewalls... Solaris, RedHat, and NT still have active ftp clients by default, which are the main clients boxes which will be hitting the server. Thanks Much!
Kent Polk wrote:
If we could simply solve this problem by replacing our active ftp clients with passive ones, it would be great, but it still doesn't solve the problem of clients *elsewhere* which are running behind a firewall and attempting to contact our server...
One possible way to solve this is to use an FTP proxy. A quick search at freshmeat.net yielded: http://www.mcknight.de/jftpgw/
And here I thought active ftp clients had gone by the wayside years ago, considering the problem they have with firewalls... Solaris, RedHat, and NT still have active ftp clients by default, which are the main clients boxes which will be hitting the server.
Passive mode is indeed more compatible--all the browsers I've used make passive connections and don't even provide an "active" option. Shane
Shane Hathaway wrote:
Kent Polk wrote:
If we could simply solve this problem by replacing our active ftp clients with passive ones, it would be great, but it still doesn't solve the problem of clients *elsewhere* which are running behind a firewall and attempting to contact our server...
One possible way to solve this is to use an FTP proxy. A quick search at freshmeat.net yielded:
Now this gets really convoluted... :^( We have it up and running, but user/permissions/role translation quickly turns into a really bad nightmare. Why can't root launch ZServer and have port 20 permissions? jftpgw has to do that to have active ftp work anyway. Why add yet another Point of Entry/Confusion? As I mentioned earlier, why not have it respond on port 20 if it has permissions, otherwise respond via high port#?? What am I missing here?
Kent Polk wrote:
Now this gets really convoluted... :^( We have it up and running, but user/permissions/role translation quickly turns into a really bad nightmare.
Why can't root launch ZServer and have port 20 permissions? jftpgw has to do that to have active ftp work anyway. Why add yet another Point of Entry/Confusion? As I mentioned earlier, why not have it respond on port 20 if it has permissions, otherwise respond via high port#??
What am I missing here?
I did some research into this today. Note that this is actually a problem with the Medusa server used by Zope. 1) Zope will never have root privileges during normal operation (at least, it's not supposed to!) It uses root privileges to create the server sockets then drops them just before entering the main loop (z2.py). 2) wu-ftpd uses seteuid() to bind to the correct port. It has to call seteuid() every time someone makes an active connection. The current version of Python does not provide the seteuid() call, only the setuid() call, which is irreversible. 3) The only remaining solution would be to bind to the data port at startup. However, the accept() call and the connect() call have a very subtle difference: accept() creates a new socket, while connect() uses the socket already created. So it would be possible to use that socket once but it would be necessary to close it at the end of the transfer, leaving subsequent connections in the same situation as before. If connect() created a new socket instead, Medusa would work much better and I bet wu-ftpd could be less convoluted. I don't think there is any alternative to connect(). I'm sorry I don't have a better answer for you. I really thought we could solve this. I'm surprised the proxy acted so strangely for you--there's no reason why it should be dealing with user permissions, etc.; it should only pass the data from the client to the server (with minor re-parsing along the way). Perhaps a different proxy will work better. Shane
Shane Hathaway wrote:
I did some research into this today. Note that this is actually a problem with the Medusa server used by Zope.
Thanks
3) The only remaining solution would be to bind to the data port at startup. However, the accept() call and the connect() call have a very subtle difference: accept() creates a new socket, while connect() uses the socket already created. So it would be possible to use that socket once but it would be necessary to close it at the end of the transfer, leaving subsequent connections in the same situation as before. If connect() created a new socket instead, Medusa would work much better and I bet wu-ftpd could be less convoluted. I don't think there is any alternative to connect().
Yep.
I'm sorry I don't have a better answer for you. I really thought we could solve this. I'm surprised the proxy acted so strangely for you--there's no reason why it should be dealing with user permissions, etc.; it should only pass the data from the client to the server (with minor re-parsing along the way). Perhaps a different proxy will work better.
Part of the problme is that we need to be able to set different 'anonymous' roles based on where one comes from. This is supported by wuftpd and by Zope. When you pass everything through a proxy on the zope server host however, that capability is destroyed as the proxy is now the only client. We tried having the proxy set usernames, but then we need two users for each role; one for http and one for ftp. And we will have to rewrite the proxy code to send remapped usernames in a fashion that Zope can comprehend, as the current proxy name remapping doesn't work with Zope. Couple these problems with having to keep two different authentication schemes synced leads us off a cliff very quickly.
From the number of messages I located on the net regarding this issue it is clear that a number of people have tried this and failed, not discovering the true cause of the problem. The use of firewalls is quickly increasing and the problem will only get worse. Have you considered a C shared module to handle the seteuid issue? Maybe an option for those who really need it? Import only when permissions indicate that seteuid is to be used?
Tahnks
participants (3)
-
Kent Polk -
kent＠tiamat.goathill.org
-
Shane Hathaway