Disclaimer: This information is posted as-is and the content should be referenced at your own risk
UTM provides a large portfolio of security functions at a price that many organizations and home users have found very attractive. However, UTM also has a unique architecture, which is not sufficiently documented in the UTM manual or help system. This leads to unwanted surprises for system administrators, as evidenced by many of the questions in the support forum. Many organizations use UTM as a firewall, and a secure configuration can be achieved, but Sophos does not use the word “firewall” in the product name. After understanding the architecture well, organizations may decide that UTM is better suited to sit immediately behind a traditional firewall. Some portions of UTM are typical of firewalls, including VPN support, NAT translation, session-state tracking and IP routing. The uniqueness is in the other modules, where packet filtering occurs.
The first clue about the uniqueness of the UTM design is that interfaces are not identified as “inside”, “outside”, or “DMZ”. This is because UTM is essentially directionless. Selection rules determine which proxy module will examine a packet, and the proxy module determines whether the packet will be allowed or blocked, but “to Internet” and “from Internet” are not part of the analysis. UTM’s Standard proxies capture packets that are directed to a UTM address, so they select packets based on port, source IP, and either one or all UTM addresses. Transparent proxies capture packets that are passing through, but not addressed to, the UTM. These proxies select packets based on port alone, or port and source IP alone.
Packets are processed by exactly one proxy. System administrators are likely to be surprised to learn that the firewall does not affect all traffic, but is merely the “default proxy” which is invoked if no other proxy selection rule is matched. It is probable that the firewall module operates with the equivalent of a final “Default Allow” rule, to ensure that outbound traffic is allowed in a default configuration. To mimic the behavior of typical firewalls, system administrators should ensure that the last two firewall rules explicitly control this, with rules of the form:
- ALLOW [Internal networks], [Any] port to [Any] host, [Any] port.
- DENY [ANY] host, [Any] port to [Internal Networks], [Any] port
Most organizations will have internal networks based on private IPs, which creates the equivalent of a “Default Block” rule for incoming traffic. But for organizations with internal networks based on public IPs, these final firewall rules will be essential.
If a proxy is not configurable with an input selection list, or is configured with [Any] in the selection list, then it will be available to all traffic on all interfaces. This can lead to some unique configurations, and to some common configuration errors. For example, if Web Prosy has a Filter Profile configured for Standard Mode with Allowed Networks = Any, then the proxy port is available to the internet. Then when an external client sends a web request for http://internalhost.example.local, the proxy could resolve the DNS to an internal address, and proxy the traffic through the firewall to the internal server. OF course, this will only work if the user also authenticates to the proxy or the Filter Profile is configured for authentication “None”. For this reason, the Sophos documentation warns not to use [Any] on proxy input selection rules. On the other hand, a home user could configure a UTM system on a DMZ, and configure Grandma’s PC to proxy through his UTM, to provide high-end web protection without teaching Grandma the complexities the complexities of proxy administration. (This may not be acceptable use in the context of Sophos’ home license. This is merely to illustrate possibilities.)
SMTP is a proxy that does not provide an input selection rule, probably because it is typically needed for both inbound and outbound traffic. However, users with multiple IP addresses will typically expect the SMTP proxy to only listen to the one address intended for SMTP. Since the SMTP proxy does not have an input filter based on either source IP or target IP, all interfaces will open port 25. This is not necessarily a security risk, because the proxy will apply the same spam filtering logic without regard to the received address, but it does raise red flags during PCI DSS vulnerability scans.
Country blocking is the one filter that is applied equally to all proxy methods. To ensure that Country Blocking is applied correctly, DNAT translation is applied before Country Blocking is evaluated. This means that DNAT can be used to discard traffic and provide a filter on proxies, such as SMTP, that would otherwise be enabled. The trick is to reserve an internal network address which will never be used, and then use a DNAT rule to send any unwanted traffic to that destination. The address should be logically near the UTM, so that you don’t expend internal bandwidth trying to find a path to the non-existent address. Assuming you have a DMZ subnet configured on one UTM interface, an unused address in the DMZ seems like a good choice.
Note: It may be desirable to enable country blocking, even if all countries are allowed. When enabled, log file entries will include a “country=name” clause. If it is disabled, the lookup does not occur, saving overhead but also bypassing the opportunity to capture this information.
In summary, you can create a secure configuration using UTM as a firewall with appropriate DNAT entries configured as appropriate. You can also create a secure configuration by placing a traditional firewall in front of UTM's powerful packet filtering engine. The choice is yours, and an understanding of the UTM Architecture should help you implement your choice successfully and securely.