Sophos SFOS v18 – New features at a glance

The Sophos firewalls (with SFOS) will soon receive a major update with SFOS v18. We have already installed the beta and in this article I will show you what features the new version brings with it.

Tests in live operation

In fact, we are not testing the beta on any test device in a Lab environment. We gather our experience right away in productive operation. But that’s not all. We are also testing the beta with select customers with over 650 users to gather as much insight as possible about the new version. So I’m not just copying you the text of Sophos’s info material here, but reporting on the new SFOS v18 EAP1 and EAP2 with several weeks of experience. Of course, this is reflected in the length of this article, where I will go into more detail about many of the features. So let’s get right to work with the Xstream architecture.

Xstream architecture

A particular highlight of v18 is the new packet processing architecture. This provides more performance, security and visibility for encrypted traffic. With v18, however, a lot has really changed.

Info: The “X” in “Xstream” stands for NextGerneation and the ‘Stream’ for the new DPI engine, which is a streaming-based scanning solution.

Xstream SSL/TLS Inspection

We have already reported on SSL Inspection, or often called “SSL Scanning” or “HTTPS Scanning”: HTTPS scanning: why it should be enabled on Sophos

Ina nutshell: HTTP traffic can be checked by the firewall without any problems, since it is unencrypted. The HTTPS traffic, on the other hand, must be broken up first. Only then can the firewall scan it. The problem until now was that the web proxy could only decrypt HTTPS traffic that went through port 443. If the traffic went through another port, e.g. https://www. example.com:8000, the firewall was blind again.

With v18 you are again armed against the latest technologies and can check SSL as well as TLS 1.3 traffic. It does not matter which ports or protocols the traffic goes through. However, a lot had to change under the hood (architecture), which fortunately does not affect the firewall administrator.

On the one hand, it needs a Decryption Profile, which in turn is attached to an SSL/TLS Inspection Rule. This rule then defines which traffic should be checked.

Thus, it is possible to define which traffic is to be checked independently of the firewall rules.

At this point, there are also predefined Decryption Profiles and SSL/TLS Inspection exception rules. In these exception rules, there is a list maintained by Sophos so that websites and applications that cause problems are not scanned.

The following video from Sophos gives you a brief introduction to the Xstream SSL inspection engine in XG Firewall v18:

Xstream DPI Engine

The DPI engine is the part that takes care of SSL/TLS inspection. Once traffic is decrypted, it also scans it for web policy policies, content scanning (AV), app control, and IPS.

Here it is important to understand that the new DPI engine is in competition with the previously used web proxy. So the web proxy takes care of the HTTP / HTTPS traffic, web policy and content scanning or the new DPI engine.

When upgrading from version 17.5 to 18.0, the web proxy settings are of course applied. But if you want to use the DPI engine, you first have to do some modifications. To do this, create an SSL/TLS inspection rule and disable the web proxy in the firewall settings.

There are only a few reasons why you should not use the new DPI engine. Nevertheless, there are features that the Web Proxy offers and the DPI Engine does not. These include, for example, SafeSearch for search engines or YouTube, as well as caching or pharming protection. However, with all the firewalls we manage, we can do without these functions without any problems, which is why the DPI Engine will certainly be used by us.

The following video from Sophos gives you a brief introduction to the Xstream DPI engine and helps you decide when to use the DPI engine versus the outdated web proxy:

Xstream Network Flow FastPath

You probably know the problem that the firewall slows down the traffic a bit. Certain processes then feel a tad slower. Due to the new architecture, there is a so-called FastPath. This helps the firewall to offload harmless traffic directly to the kernel and thus keep performance extremely high.

The traffic goes through the firewall stack at the beginning. Here it is checked whether a corresponding firewall rule exists and whether the traffic is allowed at all. For example, if the traffic is checked by the IPS, it still runs through the DPI engine. If the IPS engine decides that the traffic is harmless, it is offloaded to the FastPath and routed directly through the kernel.

When I looked at this graphic, I also wanted to test out in practice how exactly this works. Whether the traffic is allowed or not is known relatively quickly and this process no longer needs to be checked for each packet from that source and port. But how does the system in the DPI engine know when traffic can be offloaded to the FastPath? For example, if SSL/TSL scanning is enabled, this will not work. Otherwise, the traffic would no longer be checked. IPS or application control, on the other hand, works with known lists and thus can decide whether the traffic is harmless or not.

Threat Intelligence Analysis

If you have licensed the Sophos Sandstrom module for your firewall, files in a sandbox are scanned for certain criteria before being downloaded. If you want to learn more about Sophos Sandstorm, you can also check out the Sophos Sandstorm PDF with FAQs. Thanks to SSL/TLS Inspection, the firewall sees more of the traffic and can scrutinize web downloads even more closely. In the last instance, however, endpoint protection would still be in place to stop a threat after all.

With v18, Threat Intelligence Analysis is added in addition to Sandstorm. While web downloads or email attachments are scanned on Sophos Sandstorm, Threat Intelligence checks the files with Machine Learning . This is also where SophosLabs analysis comes in, which is used in Sophos Intercept X with EDR.

As known from EDR, they then create a detailed report for analysis. For Sophos Firewall with SFOS v18 EAP2, such a report looks like this:

The somewhat prettier report is only available from EAP3.

Enterprise NAT

Apart from the xStream architecture, a major change has also been made to the NAT rules. Up to version 17.5 there was a menu item “Firewall” and here all firewall rules, NAT rules and WAF rules were listed. In a firewall rule you could then define, among other things, the outgoing interface / IP for the traffic.

New with v18 the NAT rules are listed in a separate TAB.

As a result, by updating from v17.5 to v18, the NAT rules will be migrated. This looks a bit messy at first, because for each firewall rule where “NAT & routing” was enabled, a rule “linked NAT Rule” is created. However, these few automatically created NAT rules, you can replace relatively quickly.

There is also no longer only one firewall rule, which also does NAT. There is a NAT rule and for that you need a firewall rule which also allows the traffic. But this conversion was necessary because now NAT in SFOS (Network Address Translation) has become much more flexible.

What some customers have been waiting for is, for example, the possibility to prevent all DNS or NTP requests to public servers, or to forward them to an internal server. This is therefore also the solution for those who still miss the NTP server on the XG, which was still present on the UTM.

The topic NAT is also explained here in a video:

Firewall rule management

From major to major version the handling of firewall rules gets a bit better. Multiple firewall rules can now be selected to delete, enable/disable, or add to or detach from a group. In addition, the firewall rules are now numbered so that you know how many there are. However, the Rule ID remains the same. Incidentally, the “Firewall” menu item has also been renamed to “Rules and policies”.

Filters can now be added, which massively simplifies the search for certain rules. The filter remains even if you switch to another menu item and back again.

For those of you who think that Sophos might now allow firewall groups to open after you save a rule, I’m sorry to disappoint you. Nothing has changed in this regard. 😖

A really often requested feature is finally available. The counter of how much traffic was processed by a firewall rule can be set back to zero.

When creating a new firewall rule, there is a new option to disable the rule right away.

It is now possible to define exclusions in a firewall rule. This helps extremely not to inflate the whole rule construct unnecessarily.

Log Viewer

If you have read the article 7 reasons why XG Firewall (SFOS) is better than UTM, you know how helpful the Log Viewer is. Also in the new version the tool gets a few new helpful features.

With one click on an entry in the Log Viewer, a filter can be set, SSL/TSL exceptions can be defined or IPS, application control or web filter policies can be changed.

Alerts and notifications

Under “Administration” > “Notifications settings”, one could just activate two options for an email notification:

• IPsec tunnel up/down
• Email alert notifications

If a RED was unavailable or a user entered the password incorrectly too many times, there was no way to be notified about it until now.

Under v18, the list can now be found in the menu under “System Services” > “Notification list”. As of now, there are 36 actions here, about which you can be notified via e-mail or SNMP.

Flow monitoring

Currently, you can’t really see much on the firewall in terms of live connections, and the data isn’t real-time either. Moreover, in my opinion, it is not presented in a very appealing way. With v18 there is now a great view that shows the active IPs, users and applications with corresponding bandwidth usage in real time. Connections can also be blocked or prioritized.

I can not test this function myself, because this is only ready with EAP3. But what I have seen so far is very well implemented! 😍

SD-WAN Policy Routing

Before I tell you more about SD-WAN Policy Routing, first a note that the menu item has been renamed to v18:

• v17.5: Routing > Policy routing
• v18.0: Routing > SD-WAN policy routing

But apart from that, you can now create a routing based on more criteria. For example, if you want to route a user, group, or application through a different interface, you can do so now. Many applications are detected thanks to Synchronized Security and Synchronized Application Control.

Email Protection – DKIM & BATV

For the fight against spam, the following two spam protection solutions are now also supported:

• DKIM (DomainKeys Identified Mail)
• BATV (Bounce Address Tag Validation)

DDNS Support

• It is no longer necessary to define how often an update of the WAN IP should take place. The value is now fixed at 5 minutes.
• The Sophos service, which caused some problems in the past, has been replaced by an open source solution.
• The number of DDNS providers has doubled from 5 to 10. New additions are: DNS-O-Static, FreeDNS, Google DNS, Namecheap, No-IP

Small renewals / improvements

• High Availability (HA) improvements: Appliances can now be connected to form a cluster more quickly and easily. Also a rollback of the firmware is possible.
• SNMPv3 support: Better security compared to SNMPv1 and SNMPv2, if one could speak of “security” at all in the first two versions. The MIB file is of course available for download
• Name change of interfaces: The interfaces were previously named Port1, Port2 etc. and this could not be changed. In v18 this is now possible. However, IPsec, IPS, wireless networks, etc. still cannot be customized, unfortunately.
• GeoIP database updates: The country IP database can now be updated separately from the firmware updates.
• VMware Tools Upgrade: VMware Tools are now pre-installed in version v10.3.10 and Site Recovery Manager (SRM) is also supported.

Upgrade to SFOS v18

Requirements

You’re really hot now and can’t wait to upgrade to v18? If you already have an XG firewall, or even an SG with SFOS, you must have version v17.5 MR6 or higher to upgrade to v18. A rollback is of course supported as always. If something doesn’t work for you with v18, you can go back to the previous version.

SG to XG

If you still have a UTM firewall, you can also switch to the SFOS. We have created a guide for this: Install Sophos XG Firewall OS on an SG Appliance

If you need help with the migration, please contact us. We have already removed a huge number of UTMs from circulation. 😎

XG 85 and XG 105

For v18 to be installed at all, at least 4GB of RAM is required. Therefore, the future SFOS version will also not be able to run on an XG 85 or XG 105 firewall. Those who rely on their own hardware and still have 2GB RAM installed there will face the same problem. Cyberoam is also no longer supported, by the way.

Owners of an XG 85 or XG 105 should take a look at the successor models: Sophos XG 86 and XG 106. Sophos is currently running a promo until 30.09.2020 where you can save 50% on the new hardware when you renew.

Sophos Central Firewall Reporting and Management

I have written a separate blog post about this topic: Sophos Central Firewall Management – Features with SFOS v18

FAQ

---

More information

• XG Firewall: What’s New in v18