Sophos SFOS v18: New features at a glance
The Sophos Firewalls (with SFOS) will get a major update with SFOS v18 soon. We have already installed the beta and I’ll show you in this article what features the new version has to offer.
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 in the productive environment. But that’s not all. We also test the beta at selected customers with over 650 users, in order to gather as much information as possible about the new version. So I’m not just copying the texts from Sophos’s documentation here, but reporting on the new SFOS v18 EAP1 and EAP2 with several weeks of experience. This is of course reflected in the length of this article, in which I will go into many features in more detail. So let’s get started with the Xstream architecture.
A special highlight of v18 is the new package processing architecture. This offers more performance, security and more visibility for encrypted traffic. With v18, however, a lot has happened.
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 covered SSL Inspection, or often referred to as “SSL Scanning” or “HTTPS Scanning”: HTTPS-Scanning: Why it should be enabled on Sophos
Briefly summarized: HTTP traffic can easily be scanned by the Firewall because it is unencrypted. The HTTPS traffic has to be broken first. Only then is the Firewall able to scan it. The problem up to 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 ready for the latest technologies and can check both SSL and TLS 1.3 traffic. It doesn’t matter which ports or protocols the traffic goes through. 🤩 But under the hood (architecture) a lot had to change, which the Firewall administrator fortunately doesn’t have to suffer from.
On the one hand it needs a Decryption Profile, which in turn is attached to a SSL/TLS Inspection Rule. This rule then defines which traffic should be checked.
This allows you 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. These exception rules include a list maintained by Sophos to prevent websites and applications that cause problems from being scanned.
The following Sophos video 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 the SSL/TLS inspection. Once the traffic has been decrypted, it also scans it for Web Policy rules, Content Scanning (AV), App Control and IPS.
Here it is important to understand that the new DPI Engine competes with the previously used Web Proxy. So the Web Proxyor the new DPI engine takes care of the HTTP / HTTPS traffic, web policy and content scanning.
If you update from version 17.5 to 18.0, the Web Proxy settings will of course be applied. But if you want to use the DPI engine, you have to rebuild it first. You have to create an SSL/TLS Inspection Rule and deactivate the Web Proxy in the Firewall settings.
There are only a few reasons why you should not rely on the new DPI engine. Nevertheless, there are functions that the Web Proxy offers and the DPI Engine does not. Among them are SafeSearch for search engines or YouTube, as well as Caching or Pharming Protection. On all Firewalls that we manage, however, we can do without these features with no problems, which is why the DPI engine will be used by us safely.
The following Sophos video will give you a brief introduction to the Xstream DPI engine and help you decide when to use the DPI engine compared to the outdated web proxy:
Xstream Network Flow FastPath
You probably know the problem that the Firewall slows down the traffic a bit. Certain processes will feel a bit slower. Due to the new architecture there is a so-called FastPath. This helps the Firewall to outsource harmless traffic directly to the kernel and thus keep performance extremely high.
Traffic initially goes through the Firewall stack. Here it is checked whether a corresponding Firewall rule exists and whether the traffic is allowed at all. If the traffic is checked e.g. by the IPS, it still runs through the DPI engine. If the IPS Engine decides that the traffic is harmless, it is transferred to the FastPath and routed directly via the kernel.
When I looked at this graphic, I wanted to test in practice how exactly this works. If the traffic is allowed or not, you know really soon and this process doesn’t have to be checked for every package from this source and port. But how does the system in the DPI engine know when the traffic can be transferred to FastPath? If e.g. SSL/TSL scanning is activated, this is not possible. Otherwise the traffic would no longer be checked. With IPS or application control, on the other hand, known lists are used and a decision can be made as to 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 will be checked for certain criteria before downloading. If you would like to learn more about Sophos Sandstorm, you can also take a look at Sophos Sandstorm PDF with FAQs. Thanks to SSL/TLS inspection, the Firewall can see more of the traffic and take a closer look at web downloads. In the final analysis, however, the endpoint protection would still be in place to stop a threat.
With v18 the Threat Intelligence Analysis is added to Sandstorm. While scanning web downloads or email attachments on Sophos Sandstorm, threat intelligence scans files with Machine Learning. This also includes SophosLabs analysis, which is used by Sophos Intercept X with EDR.
As known from EDR, a detailed report is then prepared for analysis. For Sophos Firewall with SFOS v18 EAP2, a report looks like this:
The somewhat prettier report is only available from EAP3 onwards.
Apart from the xStream architecture, the NAT rules also experienced a major change. 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 also define the outgoing interface / IP for the traffic.
Neu mit v18 sind die NAT-Regeln in einem eigenen TAB gelistet.
As a result, updating from v17.5 to v18 migrates the NAT rules. This looks a bit messy at first, because for every Firewall rule where
NAT & routing was enabled, a rule
linked NAT Rule is created. These few automatically created NAT rules, however, can be replaced relatively quickly.
Now there is not only one Firewall rule, which also does NAT. There is a NAT rule and you need a Firewall rule that allows traffic. But this change 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 on 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 explained here also in a video:
Firewall Rule Management
From major to major version the handling of Firewall rules gets a bit better. You can now select multiple Firewall rules to delete, enable/disable, add to a group, or detach from a group. In addition, the Firewall rules are now numbered so that you know how many there are at all. However, the rule ID remains the same. The menu item
Firewall has also been renamed to
Rules and policies.
Filters can now be added, which greatly simplifies searching for specific rules. The filter remains even if you switch to another menu item and back again.
For those of you who now think that Sophos may now leave Firewall groups open after saving a rule, I am sorry to disappoint. Nothing has changed about that. 😖
A really often requested feature is finally available. The counter how much traffic was processed by a Firewall rule can be reset to zero.
When you create a new Firewall rule, you can now disable the rule immediately.
It is now possible to define exclusions in a Firewall rule. This is extremely helpful to avoid inflating the whole rule construct unnecessarily.
Who has read the article 7 reasons why the XG Firewall (SFOS) is better than the UTM knows how helpful the Log Viewer is. Also in the new version the tool gets some new helpful functions.
By clicking on an entry in the Log Viewer, you can set a filter, define SSL/TSL exceptions, or change IPS, Application Control, or Web Filter guidelines.
Alerts und Notifications
Notifications settings you could only activate two options for an email notification:
- IPsec tunnel up/down
- Email alert notifications
If a RED was not available or if a user entered the wrong password too often, there was no possibility to be notified about it.
Under v18 you can find the list in the menu under
System Services >
Notification list. From now on there are 36 actions available, about which you can be notified via email or SNMP.
Currently you don’t really see much on the Firewall about the live connections and the data isn’t real-time either. Also, in my opinion, it’s not really appealing. With v18 there is now a great view which shows the active IPs, users and applications with corresponding bandwidth usage in real time. Connections can also be blocked or prioritized.
I cannot test this feature myself, because it is only finished 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 hint that the menu item has been renamed in 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 using a different interface, you can do so now. Many applications are recognized thanks to Synchronized Security and the Synchronized Application Control.
Email Protection - DKIM & BATV
The following two solutions are now also supported for the fight against spam:
- DKIM (DomainKeys Identified Mail)
- BATV (Bounce Address Tag Validation)
- It is no longer necessary to define how often the WAN IP should be updated. The value is now fixed at 5 minutes.
- The Sophos service, which had 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. Newly added: DNS-O-Static, FreeDNS, Google DNS, Namecheap, No-IP
- High Availability (HA) improvements: The appliances can now be connected to a cluster faster and easier. The firmware can also be rolled back.
- SNMPv3 Support: Better security compared to SNMPv1 and SNMPv2, if one could even speak of “security” 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. IPsec, IPS, wireless networks etc. still cannot be adapted.
- 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
You’re really excited now and can’t wait to update to v18? If you already have an XG Firewall or an SG with SFOS, you must have 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 SFOS. We have created a tutorial for this: Install Sophos XG Firewall OS on a SG Appliance
If you need help with the migration, please contact us. We have already retired a lot of UTMs. 😎
XG 85 to XG 105
To install the v18 you need at least 4GB RAM. Therefore, the future SFOS version will not run on an XG 85 or XG 105 firewall. If you use your own hardware and still have 2GB RAM installed, you face the same problem. Cyberoam is also no longer supported.
Owners of an XG 85 or XG 105 should take a look at the successor models: XG 86 and XG 106. At the moment we have a Sophos Promo until March 31, 2020, where you can save 50% on the new hardware by renewing.
Sophos Central Firewall Reporting and Management
I have written a separate blog post about this topic: Sophos Central Firewall Management - Features with SFOS v18
- When will the GA (Final Version) be available? If everything goes according to plan and the betas don’t cause any major problems, we can expect v18 in Q1 2020.
- What about the new hardware? We have already reported several times on the hardware successor of the XG Firewall in this blog, which is no longer a secret. At the moment there is no release date planned and I would expect it in the second half of 2020 at the earliest
- Is Let’s Encrypt coming? No 😖, at least not yet in v18.