Disclaimer: This information is posted as-is and the content should be referenced at your own risk

Security Design

Although UTM does not have the concept of security zones, the concept is still useful for planning a security strategy.   In a complex environment, one can assume these different security levels, ordered from least-trusted to most-trusted

1. Intranet
2. Guest WiFi
3. Extranet / VPN Tunnels
4. DMZ for internet-facing servers
5. Intranet

“Incoming” traffic involves a web client in a less trusted zone connecting to a web server in a more trusted zone.   “Outgoing” traffic involves a web client in a more trusted zone connecting to a web server in a less-trusted zone.

The following security design should result:

• Incoming traffic must be protected by Webserver Protection (also called WAF), or be blocked.
• Outgoing traffic should be protected by Web Proxy wherever possible, may be blocked, and may be left unprotected upon approval of an exception.
• If a configuration dilemma occurs, the chosen solution should maximize protection for the more trusted zone.
• Within a security zone, UTM should be unnecessary, and the traffic should bypass UTM filtering to avoid performance bottlenecks. If it does flow through UTM, it may invoke Web Proxy, WAF, both, or neither.
• Web Admin is a special variant of a WAF site, and should only be accessible from the most-trusted zone.
• User Portal is a special variant of a WAF site, and is intended to be accessible from all zones.

For the purposes of this document, Web Traffic includes the following:

• http on port 80
• https on port 443
• ftp on port 21
• any of the above protocols on a non-standard port

Proxy Concepts

Proxy Modes can be Transparent or Standard, and UTM provides both HTTP(S) and FTP proxies using both Standard and Transparent modes.

• In Transparent Proxy mode, UTM intercepts traffic as it flows through it, even though the packet is destined for a non-UTM address. Consequently, transparent proxy is only possible if UTM is the internet firewall or is on the network path to the internet firewall.   Any traffic for a UTM address will bypass the transparent proxy.   The client browser has no knowledge of UTM’s presence on the network.  The client browser translates DNS names to IP address before generating the outbound packet.  If “pharming protection” is enabled, UTM will repeat the DNS lookup to ensure that that target IP is the same as the one in the received packet.  Transparent proxies can only evaluate traffic on standard ports: the transparent web proxy intercepts traffic destined for ports 80 and 443, and the transparent ftp proxy intercepts traffic destined for port 21.  Any web or ftp traffic on non-standard ports is ignored and therefore evaluated by firewall rules only.
• In Standard Proxy mode, the client browser or application is configured to forward web traffic to a specific IP address and port on UTM. By default, UTM listens for Standard Proxy connections on all of its IP Addresses.   The listening port can be configured by the system administrator, but the supplied default is port 8080.  Because the client asks UTM to “fetch this web page for me,” DNS resolution occurs only on UTM.   The Standard Web Proxy handles http, https, and ftp traffic on any destination port, although non-standard ports are blocked until access to those ports is enabled by the system administrator.

A secure configuration should typically implement both types of proxy.   The Standard Mode proxy is preferred, because it provides protection for non-standard ports, and permits a better implementation of https inspection.  The Transparent Mode proxy is needed to protect devices and applications that cannot or will not honor Standard Proxy configuration, including infected devices that are deliberately trying to bypass the proxy.   Transparent Mode is also useful for detecting devices that have not yet been configured for Standard Proxy.

In most firewall products, Access Control Entries are used to evaluate source and destination together.   In UTM, any traffic handled by the proxies will bypass any firewall rules, so source-destination restrictions must be enforced in the proxy configuration.   This requires extra care because the proxies implement source filtering and destination filter at different stages of the filtering process.   When planning an implementation, consider that traffic can be blocked in multiple ways:

• The packet can be evaluated by the proxy, then blocked by proxy configuration.
• The packet can be ignored by the proxy, then blocked by an explicit or default-deny firewall rule.
• The packet can be ignored by the proxy, allowed by the firewall rules, but blocked if no public-to-private IP NAT rule is applicable.

Proxy Bypass

A few sites will be identified for proxy bypass, typically for performance benefits and risk reduction related to traffic with highly-trusted business partners.   Some websites will use custom protocols, such as Citrix ICA, and these may need a proxy bypass for technical reasons.

In Standard Mode, bypass rules are configured at the client level, using either a proxy script or a static proxy exception.   In Transparent Mode, bypass is configured using the “Transparent Mode Skip List”.   If both proxy modes are enabled, then both exception methods must be used to ensure complete proxy bypass.

Proxy options for FTP Traffic

UTM provides three different methods for filtering FTP traffic, and the issues are slightly different between FTP client programs and web browsers.   Browsers will apply the system proxy settings for ftp traffic, while FTP clients must be configured manually.   Most FTP Client applications will support multiple proxy methods, including FTP, HTTP, SOCKS4, and SOCKS5.   FTP Client applications do not support exceptions, so an automatic configuration (“proxy.pac” or “wpad.dat”) configuration file is not applicable.

Standard mode web proxy provides the best solution for both browser-originated FTP and Client-originated FTP.   It provides complete logging of URL, user, IP address, and action taken.  It provides the most granular control, is the only method that supports non-standard ports, and is the only method that allows user-specific rules.   For browser-originated FTP, my testing indicates that Chrome does not pass NTLM information and does not trigger Basic authentication, so users are prevented from using that browser in FTP mode unless an alternate authentication method is used or an authentication bypass exception is configured.  Of course, if authentication bypass is enabled, then user-specific controls are not possible and proxy logging will not include the user information.

The Transparent Mode FTP proxy provides limited functionality for traffic on port 21, and is the only FTP proxy option for use with Transparent-Mode Web Proxy.  The Transparent Mode FTP proxy protects the Microsoft FTP client and any others that do not permit proxy configuration.    Because the Transparent FTP proxy has limited capabilities, only a single set of actions is configurable, and the settings are applied to all sessions because user authentication is not supported.

The Standard Mode FTP proxy is only supported with FTP clients.  If you configure a web browser to use the standard mode FTP proxy, the browser will hang when FTP traffic is attempted.   Therefore, Standard Mode FTP proxy is only useful for FTP clients, and those products are better protected by configured Standard Mode Web Proxy.   Consequently, I recommend leaving the standard-mode FTP proxy disabled and unused.

To ensure that all FTP traffic is proxied, you will want to use both Standard Mode Web Proxy and Transparent FTP proxy.

Configuring Web Site Block and Allow Policy

UTM uses three primary components to evaluate packets for web filtering, which are evaluated in order:   Filter Profile, Policy, and Filter Action.   This section explains their relationship to each other and how to configure them correctly and securely.

Filter Profile

The first component is the Filter Profile.   If you have web filtering enabled, you must have at least one filter profile to define which traffic is processed by the web filter.   In a simple environment, there will be typically a single Filter Profile, configured for Transparent Mode and accepting traffic from all Internal IP addresses.   You may need additional Filter Profiles for these situations:

• Similar devices but multiple authentication methods: This most often occurs in a network where most, but not all, of the PCs are joined to Active Directory.   If the non-domain PCs have static addresses, then one Filter Profile can be used for the non-Domain PCs to specify browser or agent authentication, while another Filter Profile specifies AD SSO authentication for the others.
• Device in different security zones: Devices in intermediate security zones such as DMZ or Guest WiFi will have a different IP address range and need a different web security configuration.   Consequently, they need a separate Filter Profile, Policy list, and Filter Action list.   The Filter Action for these devices should apply the proxy on traffic outbound to the Internet, but have blocks on all internal IP addresses and DNS names, to prevent zone escalation.  Web traffic from the intermediate zone to the internal zone should go through a WAF site rather than the web proxy.
• Multiple proxy modes: If you use both Standard Mode and Transparent Proxies, as recommended, then you need to configure one Filter Profile for each mode as well as for each required IP Address range.

Filter Profiles are evaluated in order, from top to bottom as displayed in the user interface.  The first match on IP address and mode (IP destination port) determines which Filter Action is used.   Consequently, if you have any overlapping network address ranges, the Filter Profile for the more specific IP address ranges should be positioned high in the list, and the larger ranges should be positioned lower in the list.   Once a Filter Profile is selected, the lower-ranked Filter Profiles are ignored.   If a Filter Profile is matched, firewall rules are bypassed.   If no Filter Profile is matched, then firewall rules are applied.

The Filter Profile determines three things:   The authentication method that will be used to identify users, whether https inspection will be utilized, and the list of Policies which will be evaluated for traffic that matches the Filter Profile.

Policy

After authentication is completed, the user and his group memberships are used to match the user to a Policy.   The matching Policy determines the Filter Action that will be used.

Any single policy definition can be enabled or disabled independently for each Filter Action.  Consequently, the “IT group” can be configured so that one policy is activated for traffic coming from the “Server” subnet, and a different policy is activated for traffic coming from the “Desktop” subnets.

If a user fails to authenticate by the method specified in the Filter Profile, then his traffic is handled as “Unauthenticated”.   (No attempt is made to authenticate the user with a different method using a different Filter Profile.)   A Policy definition can also specify how unauthenticated users should be handled, either with an explicit block or with an unauthenticated user policy. 

The system-wide “Base” Filter Action is the default when all other configuration options fail.  Consequently, it can be cannot be disabled, but it can be configured to specify any desired behavior.  The Base Filter action is applied in these circumstances:

• If the user is authenticated but none of the enabled policies match his user ID or group memberships.
• If the user is unauthenticated, and none of the enabled policies specify either “Use this policy for unauthenticated users” or “Block unauthenticated users”.

Filter Action

The Filter Action determines whether the web request will be allowed or blocked.  For each Category, the system administrator specifies whether to Allow, Block, or apply a time Quota.   By default, the category and reputation ratings come from a Sophos database, but the Websites tab can be used to create global rules to override the category, the reputation, or both.    Within the Filter Action, local overrides can be defined to block or allow specific websites.

Exceptions Tab

The Exceptions tab can be used to modify what security checks are enforced for a particular website.  These are global rules which apply to all Filter Profiles, Policies, and Filter Actions.   There is no equivalent option within the Filter Action configuration.

Categories

UTM has two types of Categories, which are used ambiguously.   The website rating system applies a Category from a fixed list of possibilities.  In the Websites tab, Category overrides are also chosen from this fixed list.   To avoid confusion, it might be best to call these “Sub-Categories”

UTM groups the sub-categories into groups, which are also called Categories, but these should be called Super-Categories.   The user can create new Super-Categories, and can move Sub-Categories to a different Super-Category.   Unfortunately, the design of the user interface does not ensure that each Sub-Category is assigned to one and only one Super-Category, so the system administrator must be careful.   If a sub-category is assigned to zero Super-Categories, or is assigned to multiple Super-Categories with different action rules, the behavior of UTM is unknown but probably undesirable.

Filter Actions are defined based on Super-Categories.  If you change the mapping of Sub-Categories to Super-Categories, you should review all of your Filter Actions to ensure that the intended behavior of UTM is still accomplished.

Handling Multiple Authentication Methods

Many businesses use a network-based login system based on Windows PCs and Active Directory.   For those devices, the recommended authentication method is Active Directory Single Sign-On (AD SSO).   This reliably authenticates the user to the web request, without any login prompts, because major browsers are able to pass NTLM information within the web request.   (This process breaks down for https with transparent-mode proxy, which is another reason why standard-mode proxy is preferred.)

These organizations will have several possible exceptions to this general pattern:

• Some organizations will have multiple Active Directory domains, yet UTM (or any other device) can only be joined to one domain. This can be solved by using LDAP for the alternate domains.   LDAP with Active Directory is functionally equivalent to AD SSO.
• Some devices will not be Windows operating system. One Filter Profile can specify a different authentication method for each major platform (Windows, Mac OS X, Apple IOS, Android, Linux, Blackberry, Kindle)
• Some Windows devices will not be joined to any Active Directory domain, so NTLM authentication data will not exist. If these devices have known IP addresses, a Filter Action can be created for those addresses to specify an alternate authentication method.
• Some Active Directory member devices may be accessed using a local login rather than an Active Directory login. These situations will be handled as unauthenticated users.

When SSO authentication is expected but unsuccessful, then Basic authentication is invoked.   The user will see a browser pop-up asking for username and password.   These pop-ups tend to confuse users, so use of Basic authentication should be avoided as much as possible.

Summary

Understanding the relationship between Filter Profile, Policy, and Filter Action will help you configure UTM proxies effectively.   Understanding the capabilities of Standard and Transparent modes will help you use both effectively.   Understanding the behavior of these processes will help ensure that you do not create unintended vulnerabilities.   The UTM proxy capabilities are very powerful, and it is hoped that this overview helps you configure them successfully on the first try.