Anyone using Standard-Mode FTP Proxy?

Here is my understanding of how UTM will behave in different configurations and client actions.   Understanding how a defense technology works seems essential to choosing and implementing a security policy.

FTP using standard port 21

FTP using non-standard port, such as 9999:

General Notes:

FTP proxy provides extraordinarily poor logging.   I indicated earlier that my tests using ftp in a web browser produced a log with source IP but nothing about target host, IP, or action performed.

FTP proxy has the advantage that one can easily implement a whitelist-only configuration, so that users can only ftp to specifically listed internet destinations.   For Web Proxy, this can probably be configured using regular expressions to configure allow and block rules in the Filter Action.    This assumption requires testing, but we can agree that that if it works it is certainly more difficult to configure correctly, and more flexible in how it can be applied.

For non-standard ports, FTP proxy is presumed to allow all ports by default, since there is no configuration related to this possibility.   Web Proxy will block non-standard ports unless they are authorized on the Filtering Options... Misc... tab.

When traffic is processed by firewall rules, the firewall considers IP addresses and ports, but I don't believe there is any attempt to interpret traffic by protocol.   So it cannot actually filter on "FTP" protocol, it can only filter based whether traffic is allowed or blocked to port 21 or 9999. 

What if I want User-Based Policy Rules for FTP?

Web Proxy implements user-based filtering and logging, but as I indicated earlier, Chrome does not pass the HTLM information needed for UTM to apply FTP user filtering on a transparent basis.

FTP Proxy does not seem to implement any user-based filtering or logging.

Firewall Rules can filter on "user network" objects, but my understanding is that they represent the current IP address of a user on a VPN Client connection.  As such, they could be used anywhere an IP address can be used (such as a Source IP filter list for Web Proxy or FTP Proxy), but they are not applicable to non-VPN connections, they will not provide user identity in the FTP logs, and the user must identify himself to Web Proxy by another method.

Conclusions

Based on all of the above, I conclude that Standard Web Proxy is the best of the available options, which can be enforced by using firewall rules to block port 21 and 2121, and disabling both Transparent and Non-Transparent FTP Proxies.

But can I use a non-browser with Standard Web Proxy?

The Microsoft FTP client knows nothing about proxies and has no proxy configuration options.  So probably not.

I reviewed configuration options for two FTP client applications, WinSCP and FTP Voyager.  Both of these products provided options to support multiple proxy technologies, including HTTP.   So if you have the right client application, the answer is yes.

Follow-Up:

This is really two questions for the community:   Do I have my facts straight, and do you agree with my conclusions?

To help understand, there are three seperate modes.  And internally IIRC there at least two seperate FTP mechanisms.


When you are using an FTP client and you are not using a proxy, the traffic goes out on Port 21.  The UTM listens for transparent mode FTP on port 21, and the firewall sends it to the FTP proxy process for processing.  AFAIK the FTP protocol has no concept of authentication with transparent proxy server.  If the traffic is sent out on port 9999 then the UTM won't send it to the FTP Proxy process, however you can create a firewall rule that lets port 9999 through the firewall (unscanned).

When you are using a Web Browser such as Chrome and you are not using a proxy, the traffic goes out on Port 21, the same the FTP client above.

However when you get into standard mode / explicit proxies then it becomes quite different.

When you are using an FTP client and you are using a proxy configured in the FTP client, the traffic goes out on Port 2121.  The UTM listens on port 2121 and passes it to the FTP process.  I'm not sure but I *think* that you can try to connect to a server sitting at port 9999 and the FTP client connects to the UTM on port 2121 and passes in 9999 as part of the request.  I'm not sure if it will work.

When you are using a Web Browser such as Chrome and you are using a proxy, the traffic goes out on Port 8080.  The UTM listen for traffic on port 8080 and sends it to the Web Proxy.  The Web Proxy realizes you are doing FTP-over-HTTP and sends to the a *different* FTP proxy process for processing.  IIRC in this scenario it is the Web Proxy that does AV scanning.  Possibly the Web Proxy can do authentication and other policy I'm not sure.  IIRC if you pass in a port like 9999 it looks at the allowed destination ports configured in Web.

It is possible to configure proxy settings to use different ports for http, ftp, and socks, using either proxy script or staic settings.   I have been using standard mode web proxy with 8080 for all protocols, but wondered if I should be using non-transparent ftp for ftp instead.

I have two proxy-aware clients installed, and both provide a choice of proxy methods, including ftp, http, socks4, socks5, telnet or none.  

Based on my testing, the port 2121 proxy just does not work, although Sophos Support is only in tne early stages of investigating my problem.  The documentation does comfirm your assertion that the ftp proxy does not sttempt user identification.

At best, ftp proxy provides limited features, av and destination filtering, while the http proxy provides av, category + reputation filtering, user identification, flexible exception options, and (with effort) destination filtering.  It seems clear that http proxy is the best option,although I need to either filter or block port 21 traffic that attempts to bypass the web proxy.

It is possible to configure proxy settings to use different ports for http, ftp, and socks, using either proxy script or staic settings.   I have been using standard mode web proxy with 8080 for all protocols, but wondered if I should be using non-transparent ftp for ftp instead.

I have two proxy-aware clients installed, and both provide a choice of proxy methods, including ftp, http, socks4, socks5, telnet or none.  

Based on my testing, the port 2121 proxy just does not work, although Sophos Support is only in tne early stages of investigating my problem.  The documentation does comfirm your assertion that the ftp proxy does not sttempt user identification.

At best, ftp proxy provides limited features, av and destination filtering, while the http proxy provides av, category + reputation filtering, user identification, flexible exception options, and (with effort) destination filtering.  It seems clear that http proxy is the best option,although I need to either filter or block port 21 traffic that attempts to bypass the web proxy.

A final note to summarize this issue after completing conversations with Sophos Support.

• FTP Standard Mode proxy is not supposed to work with web browsers, and does not, per KB 115691.
  
  
• A weak alternative is to use Transparent Web Proxy with Transparent FTP proxy.   FTP proxy controls are very limited.
  
  
• The better alternative is to use Standard Mode web proxy for both http(s) and ftp.   This provides all of the capabilities of the web proxy for both ftp browsing and ftp clients.   The UTM ftp proxy configuration does not apply, so you will want to disable the FTP proxy and block port 21 at the firewall level.  Then obtain FTP client software that supports HTTP proxy, and configure it to use the UTM web proxy (typically port 3128)