Sophos XG Firewall release notes - Release notes Version: 18.0 - Documentation
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Sophos XG Firewall release notes Release notes Version: 18.0
Sophos XG Firewall release notes Supported platforms 1. Supported platforms SFOS 18.0 is supported on all XG and SG appliances with at least 4 GB of RAM. With the new Xstream packet processing architecture, you will enjoy a nice performance boost on your existing hardware. SFOS 18.0 won't be supported on older XG 85/105 and SG 105 models that have 2 GB of RAM but will run perfectly on the newer XG 86/106 models that have 4 GB of RAM. Cyberoam appliances don't support SFOS 18.0. Models that don’t support version 18 will continue to be supported for the foreseeable future on version 17.5. However, you can restore Cyberoam firewall backups on XG Firewall operating on 18.0. For upgrade information, go to Upgrading to SFOS 18.0.1 (page 3). 2 20200908 Copyright © Sophos Limited
Upgrading to SFOS 18.0.1 Sophos XG Firewall release notes
2. Upgrading to SFOS 18.0.1
SFOS 18.0.1 MR1 Build 396
You can upgrade from SFOS 17.5 (MR6 to MR12) to 18.0.1 MR1 (build 396). Currently, you can't
migrate from 17.5 MR13, MR14, and MR14.1 to 18.0. We'll update this page when they can migrate
to 18.0 MR3. For details, see the table below:
The security hotfixes released until now are part of SFOS 18.0.1 MR1 (build 396). So, the hotfixes
referred to in KBA135412, HF051220.1, and HF052220.1 are NOT required for this release.
Migrate from 17.5 Migrate to 18.0
MR1 (Build 396) MR2 MR3
17.5 MR6 to MR12 Yes Yes Planned
• 17.5 MR13 No No Planned
• 17.5 MR14
• 17.5 MR14.1
CAUTION
Do not migrate from 17.5 MR13, MR14, or MR14.1 to 18.0 MR1 or MR2. If you
try to migrate, XG Firewall shows an alert asking you to confirm the migration
before it restarts. If you confirm the migration, XG Firewall restarts with the factory
configuration, and you lose your current configuration.
Note the following upgrade information for SFOS 18.0 and later:
• 18.0 and later versions require a minimum of 4 GB RAM. So, you can't upgrade the following
models to 18.0 and later:
◦ XG 85, XG 85w, XG 105, and XG 105w
◦ SG 105, SG 105w
These models must remain on a 17.x version. See XG Firewall Lifecycle Policy and XG Firewall
retirement calendar.
• Support for RED devices:
◦ Doesn't support RED 10 devices.
◦ Supports SD-RED 20 and 60 devices.
• Cyberoam models don't support 18.0 and later firmware versions. However, you can restore
Cyberoam firewall backups on XG Firewall operating on 18.0 and later.
• Firmware:
Copyright © Sophos Limited 20200908 3Sophos XG Firewall release notes Upgrading to SFOS 18.0.1
◦ Rollback (firmware switch) is supported. You can roll back to 17.5 MRx if you experience
any issues with 18.0 and later. For example, the active firmware on the firewall is 18.0
and the other firmware version is 17.5. You can switch between these two versions. This
doesn't change the configuration on either.
◦ You can't downgrade from 18.0 and later to an older firmware using 17.5 or an earlier
firmware file. The web admin console will show an alert.
18.0 and later use Grub boot loader. The changed bootloader can't recognize 17.x
firmware. You can still use the hardware ISO of 17.5 or earlier to have the firewall on an
older firmware version and restore the downgraded firmware's backup.
◦ In 18.0, we moved to a more secure firmware signing method. The firmware update files
now use the .sig extension and not the earlier .gpg extension.
◦ The web admin console shows the specific reasons for firmware upload failure.
• Backup and restore are supported. You can restore the following on 18.0 and later versions:
◦ SG firewalls running SFOS
◦ Cyberoam firewalls
◦ XG Firewall backups
• HA: SFOS 18.0 moved to SSH tunnel-based secure communication for the HA cluster. If
you're upgrading the HA cluster to 18.0 or later, both the devices in the cluster will reboot
simultaneously once. You'll receive an alert on the UI before you can proceed.
• Quarantined emails: You can only release quarantined emails from the user portal. For details,
see KBA135515.
What's new
• SFOS 18.0 and later versions are available on the Amazon Web Services (AWS) public cloud
infrastructure.
• Supports SD-RED 20 and 60 devices.
• Key information you need to know about how to configure the following:
◦ NAT rules (page 25)
◦ What's new in SD-WAN policy routing (page 47)
◦ SSL/TLS inspection rules (page 8)
4 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
3. New features
The release notes site describes the new features introduced in XG Firewall 18.0.
The left menu gives the key features, their significance, and how to implement them. For detailed
information of XG Firewall, go to the online help.
For an overview of the key features, please read What’s New in v18.
3.1 Xstream architecture
We are introducing the new Xstream architecture for XG Firewall - A new streaming packet
processing architecture that provides extreme levels of protection and performance. The new
architecture includes:
• Xstream SSL inspection: Enable SSL inspection on your network without compromising
network performance or the user experience. It delivers high-performance, high-connection-
capacity support for TLS 1.3 and all modern cipher suites providing extreme SSL inspection
performance across all ports, protocols, and applications. It also comes equipped with
enterprise-grade controls to optimize security, privacy, and performance.
• Xstream DPI engine: Enables comprehensive threat protection in a single high-performance
streaming DPI engine with proxyless scanning of all traffic for AV, IPS, and web threats as well
as providing application control and SSL inspection.
• Xstream network flow FastPath: Provides the ultimate in performance by intelligently offloading
traffic processing to transfer trusted traffic at wire speeds. FastPath offloading can be controlled
through policy to accelerate important cloud application traffic or intelligently by the DPI engine
based on traffic characteristics.
3.1.1 FastPath network flow
Xstream architecture enables the offloading and streaming of packet processing for high levels of
protection and performance.
The architecture contains the DPI (Deep Packet Inspection) engine, SSL/TLS inspection, and the
FastPath network flow.
The DPI engine applies SSL/TLS decryption and inspection, IPS policies, application identification
and control, web policies (including proxyless web filtering), and antivirus scanning in a single
engine. Antivirus scanning includes Sandstorm protection and file reputation analysis.
SSL/TLS inspection decrypts and inspects SSL/TLS connections that use modern cipher suites
across all ports and protocols. For details, go to Rules and policies > SSL/TLS inspection rules.
FastPath network flow offloads (bypasses processing of) trusted traffic. Offloading eliminates
the need to apply full firewall processing to every packet in a connection, minimizing the use of
processing cycles.
Note
Currently, we don't offload VPN, QoS, DoS, RED, and HA traffic to FastPath.
Copyright © Sophos Limited 20200908 5Sophos XG Firewall release notes New features
You can optimize FastPath offloading through rules and policies to accelerate cloud application
traffic or through the DPI engine based on traffic characteristics.
FastPath network flow
The data plane is the core hardware and software component. It works in the FastPath, kernel
(firewall stack), and user space domains, offloading trusted packets throughout a connection's
lifetime. The DPI engine is in the user space.
FastPath provides an efficient, zero-copy path into the DPI engine, eliminating the need to retain
copies in the kernel memory. The data plane caches the classification decisions of the kernel and
user space, and applies them to all the traffic in a connection, lightening the load on the hardware.
This enables FastPath to offload some or all processing of a packet from the CPU.
The firewall stack still requires the CPU to handle the connection rate.
Note
XG Firewall retains firewall stack (slowpath) processing as a fallback path for
functionalities that can’t be processed in FastPath or if FastPath can't function. The
firewall stack continues to process certain protocols, such as IP in IP.
FastPath is software-based and is also available as Virtual FastPath (VFP), enabling us to maintain
a common architecture for XG Firewall devices and the software and virtual platforms of XG
Firewall. The firewall stack can offload to FastPath through VFP or the FastPath API. VFP updates
and features are part of SFOS releases.
Note
Virtual FastPath supports the NIC drivers i40e, e1000, e1000e, igb, ixgbe, and
vmxnet3. VFP won’t load on other drivers, but XG Firewall (including the DPI engine)
still functions fully, but without the FastPath performance enhancements.
Currently, Virtual FastPath supports up to 3500 MTU on e1000 and e1000e NICs.
Note
For virtual deployments, Virtual FastPath supports the VMware ESXi hypervisor. For
other hypervisors, such as KVM, turn off FastPath using the CLI command for firewall
acceleration.
Firewall acceleration
When you turn off firewall acceleration on the CLI console or when FastPath doesn’t load, XG
Firewall continues to function fully, but without the performance enhancements of FastPath.
To turn firewall acceleration on or off through FastPath and to see the status, use the following CLI
commands:
Option CLI command
Show firewall acceleration console> system firewall-
acceleration show
6 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
Option CLI command
Turn on firewall acceleration console> system firewall-
acceleration enable
Turn off firewall acceleration console> system firewall-
acceleration disable
Note
FastPath doesn’t support tcpdump. It’s turned off when you run a tcpdump command.
FastPath
Traffic for a connection flows in the stateful firewall mode initially. The firewall stack processes the
first packet and does the following:
• Applies the firewall rule action.
• Makes layer 2 and layer 3 decisions that include routing, switching, forwarding, and RED traffic-
related decisions.
• Makes decisions related to ingress decapsulation and egress encapsulation, including
decisions for IPsec VPNs.
• Applies DoS (Denial of Service) policies.
• Applies QoS (traffic shaping) policies.
After one packet from each direction passes through XG Firewall, the firewall stack fully classifies
the flow, and programs a connection cache in FastPath. It offloads kernel processing for
subsequent packets in the same connection to FastPath. These packets don’t require further
processing to verify their identity and destination. With stateful tracking of individual connections,
FastPath processes the packets fully, saving CPU cycles and memory bandwidth. FastPath acts
only as directed by the kernel.
DPI engine
For security decisions, the firewall stack delivers the initial packet to the DPI engine through the
Data Acquisition (DAQ) layer. FastPath delivers subsequent packets directly to the DPI engine
through the DAQ layer, which is a high-speed mechanism to move packets into and out of the DPI
engine. The direct delivery eliminates the need to retain copies in the kernel memory.
The DPI engine inspects traffic from layer 4 and higher through streaming processing. Offloading
decisions are taken at each stage of security processing.
SSL/TLS engine: For unencrypted traffic, when SSL/TLS inspection rules are turned on, the
SSL/TLS module directs the DAQ layer to skip SSL/TLS processing for the flow. For encrypted
traffic, when SSL/TLS inspection rules have been set up, the DPI engine continues to modify traffic
throughout the connection lifetime. This ensures that the connection isn't dropped because the SSL/
TLS connection has been modified for inspection.
Intrusion prevention and Application control: With application control turned on, the initial
packets are delivered to IPS for application identification. IPS classifies the application after a
few packets and gives a policy verdict for application control, which may give new forwarding
behavior and QoS parameters. The DAQ layer communicates these decisions to the kernel and the
hardware. From this point onward, the connection may be completely offloaded to FastPath.
Copyright © Sophos Limited 20200908 7Sophos XG Firewall release notes New features
IPS may pass a verdict to stop security processing based on factors, such as a safe signature or
verdict from SophosLabs, a matching IPS policy with bypass action, or based on earlier guidelines.
Antivirus and Web filtering: If the IPS verdict is that the traffic is safe, antivirus scanning
doesn't take place. If web filtering applies, web traffic scanning continues until the end of the flow,
depending on the HTTP responses.
From this point onward, FastPath offloads traffic from the kernel and handles layer 2 and layer 3
processing. The ability to offload some or all processing minimizes load on the CPU.
How to enable FastPath with rules and policies
Here are examples of rules and policies that enable FastPath to handle traffic fully, bypassing the
firewall stack and the DPI engine:
• A firewall rule without IPS, web filtering, antivirus, or application control. Traffic is offloaded to
FastPath after the initial packet passes through XG Firewall on either side of the connection.
• A firewall rule with application control policy. Traffic is offloaded to FastPath after about eight
packets.
• A firewall rule with IPS policy set to the rule action Bypass session. Traffic that matches IPS
policy rules with this action is offloaded to FastPath.
• A firewall rule with the following policies:
◦ An IPS policy containing intelligent offload signatures from SophosLabs.
◦ Web filtering without malware and content scanning or DPI engine settings. For firewall
rules with malware and content scanning and DPI engine settings, FastPath delivers traffic
to the DPI engine directly, bypassing the firewall stack.
• No SSL/TLS inspection rules. For rules with the action set to Decrypt, FastPath delivers traffic
to the DPI engine directly, bypassing the firewall stack.
• SSL/TLS inspection rules with the action set to Don't decrypt. For STARTTLS connections,
traffic is offloaded to FastPath after 15 packets.
3.1.2 SSL/TLS inspection rules
With SSL/TLS inspection rules, you can intercept and decrypt SSL and TLS connections over TCP,
enabling XG Firewall to enforce secure connections between clients and web servers.
SSL/TLS inspection enables the prevention of malware transmitted through encrypted connections.
You can enforce policy-driven connections and decryption for inbound and outbound SSL/TLS
traffic based on the traffic and risk level.
SSL/TLS inspection rules don't affect the decryption of traffic handled by the web proxy. You specify
the method of web filtering (web proxy or the DPI engine) in firewall rules. By default, XG Firewall
uses the DPI engine, applying SSL/TLS inspection rules to traffic matching the firewall rule criteria.
SSL/TLS inspection rules are turned on by default for fresh installations. For deployments migrating
from SFOS 17.5 and earlier, they're turned off by default. You can turn them on or off manually.
8 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
CAUTION
When SSL/TLS inspection rules are turned off, XG Firewall won't apply them to the
connections. The control center and log viewer won't show the SSL/TLS connection
and decryption details.
Warning
Android devices are known to generate SSL/TLS certificate errors, causing decryption
to fail. We recommend creating an SSL/TLS exclusion list for all Android devices.
Rule table actions
• You can filter the rules by the source, destination, and rule ID.
• To reset the rule filter, select Reset filter.
Click More options to specify the following actions:
• To edit or delete a rule, select the action.
• To clone or add a rule next to an existing rule, select the action.
• To turn on or turn off a rule, select the switch.
To change the position of a rule, drag and drop the Rule handle ( ). XG Firewall evaluates rules
from the top down until it finds a match. Once it finds a match for the packet, it doesn’t evaluate
subsequent rules. Position the specific rules above the less specific rules.
SSL/TLS inspection rules
SSL/TLS inspection detects SSL/TLS traffic on any TCP port. Inspection rules apply to detected
SSL/TLS connections. You can specify rules to decrypt traffic based on the source, destination,
users and groups, services, websites, and web categories. To take effect, the rule must find a
match in all criteria.
You need to select a decryption profile for each rule to specify the action for traffic with issues, such
as insecure protocol versions, SSL compression, unrecognized cipher suites, cipher algorithms
to block, certificate errors, or connections that exceed the firewall's decryption capabilities. After
decrypting and inspecting the traffic, XG Firewall re-encrypts the traffic with the re-signing certificate
authority that you specify.
You can use SSL/TLS inspection rules in these cases:
• Implement policy-driven decryption and meet compliance requirements.
• Prevent malware transmission through encrypted traffic.
• Apply web content policies to encrypted traffic to prevent unwanted uploads and downloads
without obstructing general browsing.
Exclusions to SSL/TLS inspection rules
XG Firewall provides a default exclusion rule Exclusions by website or category that prevents
connections to certain websites from being decrypted. The rule has action set to Don't decrypt and
the decryption profile set to Maximum compatibility.
Copyright © Sophos Limited 20200908 9Sophos XG Firewall release notes New features
The rule is permanently positioned at the top of the SSL/TLS inspection rule table. SSL/TLS
inspection rules are evaluated top down in the rule table.
The exclusion rule contains the following default exclusion lists:
• Local TLS exclusion list: The list is empty by default. You can add websites to this list by
troubleshooting in the Control center or Log viewer. To edit this list, go to Web > URL
groups.
Websites and browsers that use certificate pinning block the requested page fully or partially
when SSL/TLS inspection is turned on. If an error message is shown, it may not show an
identifiable reason. If you want to bypass SSL/TLS inspection, you can use the local TLS
exclusion list to allow the domains.
• Managed TLS exclusion list: The list contains websites known to be incompatible with SSL/
TLS inspection and is updated through firmware updates.
Tip
To add websites to the exclusion rule or remove them, edit the rule and add or remove
the web categories or URL groups. Alternatively, go to Web > URL groups and edit
the group Local TLS exclusion list.
You can exclude web categories, URL groups, users, source and destination IP addresses and
networks by creating your own exclusion rules and placing them immediately below the default
rule. Add only connections you don’t want to be decrypted by other SSL/TLS inspection rules to an
exclusion rule.
SSL/TLS inspection rules are applied independently of firewall rules. Inspection rules continue to
enforce the specified exclusions even if you don't select a web policy in firewall rules.
You can use both web exceptions and SSL/TLS exclusion rules to stop connections from being
decrypted. For details of how they differ in enforcing HTTPS decryption-related exceptions, see the
table below:
SSL/TLS exclusion list Web exception
Processes you can exclude HTTPS decryption HTTPS decryption
HTTPS certificate and protocol HTTPS certificate validation
enforcement
Malware and content scanning
Sandstorm
Web policy checks
Applies in this mode DPI mode DPI mode
Proxy mode
Applies to this traffic SSL/TLS connections on any DPI mode: SSL/TLS
port. connections on any port.
Proxy mode: SSL/TLS
connections on port 443.
10 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
SSL/TLS exclusion list Web exception
Matching criteria URL group containing a list URL pattern matches using
of websites (domain names) regular expressions.
in plaintext. Includes the
subdomains of these domains.
Web categories Web categories
Source and destination zones, Source and destination IP
networks, and IP addresses addresses and IP ranges
Services
Users and groups
Where to add the exception Add domains and subdomains Add to Web > Exceptions.
to the Local TLS exclusion
list by troubleshooting in
the Control center or Log
viewer.
Go to Web > URL groups
and add websites to a URL
group being used by an
exclusion rule.
Create or edit SSL/TLS
inspection rules.
SSL/TLS inspection settings
These settings apply to all SSL/TLS inspection rules. You can specify the re-signing certificate
authorities (CAs), action for traffic we don’t decrypt, and the TLS downgrade setting. Inspection
settings also allow you turn off SSL/TLS inspection to troubleshoot errors.
CAUTION
We recommend that you turn it back on after troubleshooting.
The decryption profile that you add to an inspection rule overrides the inspection settings.
Firewall rules and web proxy
XG Firewall applies the firewall rules first and then the SSL/TLS inspection rules. It applies the
inspection rules in transparent mode based on the web proxy selection you make in the firewall rule.
Transparent mode: In the firewall rule, if you’ve selected decryption and scanning by web proxy,
traffic over ports 80 and 443 is decrypted by the web proxy. SSL/TLS inspection rules will then be
implemented only for web traffic over other ports.
Explicit mode: Decryption and scanning is performed by the web proxy.
Copyright © Sophos Limited 20200908 11Sophos XG Firewall release notes New features
Note
The web proxy uses the certificate specified in Web > General settings.
SSL/TLS inspection uses the certificates specified in SSL/TLS inspection settings
and Decryption profiles.
Troubleshooting
To see if SSL/TLS connections have been exceeding the decryption limit, go to Control center and
select the SSL/TLS connections widget.
To troubleshoot SSL/TLS errors, go to Control center, select the SSL/TLS connections widget,
and select Fix errors in the upper-right corner.
If you don't see the connection and decryption details in the control center or the log viewer, make
sure the following are turned on:
• SSL/TLS inspection rules: Go to Rules and policies > SSL/TLS inspection rules and turn the
SSL/TLS inspection switch on.
• SSL/TLS engine: Go to Rules and policies > SSL/TLS inspection rules > SSL/TLS
inspection settings. Under Advanced settings > SSL/TLS engine, select Enabled.
SSL/TLS inspection rules and the SSL/TLS engine
SSL/TLS inspection: You can turn SSL/TLS inspection rules on or off. For deployments migrating
from SFOS 17.5, the inspection rules are turned off by default to prevent potential behavioral
changes during the upgrade.
You must turn SSL/TLS inspection on to enable the new XStream SSL/TLS decryption functionality,
including showing SSL/TLS connection statistics on the Control center.
When SSL/TLS inspection is set to On, XG Firewall works as follows:
• Inspects all traffic and identifies SSL/TLS connections.
• Applies SSL/TLS decryption rules and logs connections as required by the rules.
• Updates SSL/TLS connection statistics and shows them on the Control center.
When SSL/TLS inspection is set to Off, XG Firewall works as follows:
• Doesn't evaluate or apply SSL/TLS decryption rules.
• DPI engine doesn't decrypt SSL/TLS connections. XG Firewall still decrypts connections
handled by the web proxy based on the firewall rule settings.
• Doesn't gather any SSL/TLS statistics. Won't update the statistics shown on the Control
center any longer.
• For traffic matching firewall rules that have a web policy specified, and are not configured to
use the web proxy, the DPI engine still uses SSL/TLS inspection to enforce the policy on non-
decrypted HTTPS connections.
SSL/TLS engine: You can enable or disable the SSL/TLS engine in SSL/TLS inspection settings.
When you disable the engine, XG Firewall won't use the SSL/TLS inspection engine at all. Use this
option only for troubleshooting purposes based on advice from Sophos Support. When the engine is
disabled, XG Firewall does the following:
12 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
• Won't evaluate or apply SSL/TLS decryption rules.
• Decrypts only traffic handled by the web proxy as specified in the firewall rules.
• Won't gather any SSL/TLS connection statistics. Won't update the statistics shown on the
Control center any longer.
• The DPI engine won't apply web policies to any HTTPS traffic. This applies to traffic matching
firewall rules that have a web policy specified, and haven't specified web proxy filtering.
3.1.3 SSL/TLS inspection settings
With SSL/TLS inspection settings, you can specify the default settings to enforce secure protocol
versions and occurrences.
You can specify the re-signing certificate authorities to sign SSL/TLS server certificates after XG
Firewall intercepts, decrypts, and inspects secure traffic. You can specify the settings to drop or
reject non-decryptable traffic, which includes insecure protocol versions and occurrences, such as
SSL compression and connections that exceed the decryption capabilities of the firewall. You can
downgrade TLS 1.3 to TLS 1.2 connections if you face issues using TLS 1.3.
Tip
The settings apply to all SSL/TLS inspection rules. You can override some SSL/TLS
inspection settings by adding individual decryption profiles to inspection rules.
Go to Rules and policies > SSL/TLS inspection rules and select SSL/TLS inspection settings.
Re-signing certificate authorities
Specify the re-signing certificate authority for SSL/TLS connections intercepted by XG Firewall. The
decryption profile attached to an SSL/TLS inspection rule can override these actions for the rule.
Re-signing certificates must be trusted by the endpoint devices. If they aren’t, browsers will show a
warning and may refuse to complete the connection.
Tip
Under most circumstances, this requires the installation of copies of the certificates
in the browsers or the operating system certificate stores of the endpoint devices.
Alternatively, you can create and use signing certificates that are subordinate to an
existing trusted enterprise CA for your organization. It isn’t possible to obtain signing
certificates from CAs that are already trusted by operating systems or browsers.
Most certificate authorities use certificates with either RSA or Elliptic Curve (EC) encryption keys.
In most situations, certificates of one type can be signed by certificate authorities of the other,
allowing you to use the same CA for both. If you encounter problems with applications that expect
certificates of only one type, you can add an EC key and use it for re-signing certificates that were
originally signed by an EC-based authority. If you add a second CA, ensure that it is trusted by all
endpoint devices.
Copyright © Sophos Limited 20200908 13Sophos XG Firewall release notes New features
Name Description
Re-sign RSA with Used when the website’s certificate was signed
using RSA. You can specify an EC or RSA
certificate.
Re-sign EC with Used when the website’s certificate was signed
using EC. You can specify an EC or RSA
certificate.
Non-decryptable traffic
Specify the action for the traffic we won't decrypt, such as insecure protocol versions and
occurrences. The decryption profile attached to an SSL/TLS inspection rule can override these
actions for the rule.
Name Description
SSL 2.0 and SSL 3.0 Allowing these connections lowers security.
SSL compression Compression before encryption has known
vulnerabilities.
When SSL/TLS connections exceed limit Applies to excess traffic when volume exceeds
the decryption capability of the firewall.
To see the decryption limit, go to Control
center and select the SSL/TLS connections
widget.
Select the action for the traffic we won't decrypt:
• Allow without decryption
• Drop: Drops without notifying the source.
• Reject: Drops and sends a connection reset message to the source host.
Note
XG Firewall rejects connections using SSL 2.0 and 3.0, SSL compression, and
Unrecognized cipher suites if you set the action to Decrypt in SSL/TLS inspection
rules.
To allow these connections, create a decryption profile set to Allow without
decryption. Add the profile to an SSL/TLS inspection rule with the action set to Don't
decrypt.
14 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
TLS 1.3 compatibility
TLS 1.3 decryption
Select the action.
• Decrypt as 1.3
• Downgrade to TLS 1.2 and decrypt: Some servers and clients haven’t implemented TLS 1.3
yet. Select this option if you experience issues using TLS 1.3.
CAUTION
Attackers can exploit vulnerabilities during the downgrade. Selecting the downgrade
option applies the setting to all SSL/TLS inspection rules.
For TLS 1.3 connections, you need to set the action to Decrypt in SSL/TLS inspection rules to do
the following:
• Apply the TLS compatibility setting Downgrade to TLS 1.2 and decrypt specified in SSL/TLS
general settings.
• Block certificate errors and apply the minimum RSA key size specified in decryption profiles.
• Apply the block action Reject and notify specified in the decryption profile. If you apply such a
decryption profile to SSL/TLS inspection rules with Don't decrypt or Deny action, XG Firewall
applies the block action Reject.
Advanced settings
SSL/TLS engine: Disable the engine only when you want to troubleshoot. Once you complete
troubleshooting, enable it again.
Warning
When you disable the engine, XG Firewall won't apply SSL/TLS inspection rules, and
the DPI engine won't apply the web policy specified in firewall rules to HTTPS traffic.
However, this does not affect HTTPS decryption by the web proxy when web proxy
filtering is configured in firewall rules.
3.1.4 Add an SSL/TLS inspection rule
You can specify policy-driven inspection rules to establish inbound and outbound SSL and TLS
connections over TCP between clients and web servers and decrypt the traffic.
SSL/TLS inspection detects SSL/TLS traffic on any TCP port. Inspection rules apply to detected
SSL/TLS connections. You can specify rules to decrypt traffic based on the source, destination,
users and groups, services, websites, and web categories. To take effect, the rule must find a
match in all criteria.
You can also add decryption profiles to enforce secure connections.
1. Go to Rules and policies > SSL/TLS inspection rules and click Add.
2. Enter the general details.
Copyright © Sophos Limited 20200908 15Sophos XG Firewall release notes New features
Name Description
Rule name Type a name.
Rule position Specify the position of the rule in the rule
table:
• Top
• Bottom
XG Firewall evaluates rules from the top
down until it finds a match. Once it finds a
match for the packet, it doesn’t evaluate
subsequent rules. To change the order of the
rules later, you can drag and drop the rule in
the rule table.
Action Select the action:
• Decrypt: Establishes connection and
decrypts
• Don't decrypt: Establishes the
connection and doesn’t decrypt. Use this
to create an exclusion rule.
Decryption profile restrictions also apply
to rules with action set to Don't decrypt.
• Deny: Doesn’t establish connection
For TLS 1.3 connections, you need to set
the action to Decrypt in SSL/TLS inspection
rules to do the following:
• Apply the TLS compatibility setting
Downgrade to TLS 1.2 and decrypt
specified in SSL/TLS general settings.
• Block certificate errors and apply the
minimum RSA key size specified in
decryption profiles.
• Apply the block action Reject and
notify specified in the decryption profile.
If you apply such a decryption profile
to SSL/TLS inspection rules with Don't
decrypt or Deny action, XG Firewall
applies the block action Reject.
Log connections Select to log the connections.
16 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
Name Description
Decryption profile Select a decryption profile or create one. You
can't edit the default profiles.
Decryption profiles override the default SSL/
TLS general settings for the re-signing CA
and action for traffic we can't decrypt. They
allow you to specify a policy-driven action for
the rule.
Note
XG Firewall rejects connections using SSL 2.0 and 3.0, SSL compression, and
Unrecognized cipher suites if you set the action to Decrypt in SSL/TLS inspection
rules.
To allow these connections, create a decryption profile set to Allow without
decryption. Add the profile to an SSL/TLS inspection rule with the action set to
Don't decrypt.
3. Select the source matching criteria.
Name Description
Source zones Select the zones from which traffic
originates.
You can select only internal zones, since
SSL/TLS inspection rules apply only to
outbound traffic.
Source networks and devices Select the source networks and devices or
create new ones.
Users or groups Select the source users and groups. The rule
will then apply only to traffic originating from
the specified users.
4. Select the destination and service matching criteria.
Name Description
Destination zones Select the destination zones of traffic.
Destination networks Select the destination networks or create
new ones.
Copyright © Sophos Limited 20200908 17Sophos XG Firewall release notes New features
Name Description
Services Select the services or create a new service.
A service is a combination of protocols and
ports.
SSL/TLS connections aren’t enforced over
UDP.
5. Specify the settings for websites and web categories.
Name Description
Categories and websites Select the web categories and websites.
To add an individual website, go to Web >
URL groups or Categories and add the
website to an existing or new object. You
can then select the object in the SSL/TLS
inspection rule.
XG Firewall identifies web categories and
websites based on the SNI (Server Name
Indication) in the SSL/TLS handshake.
Note
XG Firewall enforces SSL/TLS inspection rules and the URL groups you specify
if you have a Base License. You can configure web categories, but can't enforce
them without a Web Protection license.
6. Click Save.
3.1.5 Decryption profiles
Decryption profiles enable you to enforce decryption settings on SSL/TLS connections.
• To clone a decryption profile, click Clone .
• To edit a decryption profile, click Edit .
You can specify the re-signing certificate authorities to sign SSL/TLS server certificates after XG
Firewall intercepts, decrypts, and inspects secure traffic. You can also specify the action for traffic
that can't be decrypted due to issues such as insecure protocol versions, unrecognized cipher
suites, SSL compression, or connections that exceed the firewall's decryption capabilities.
You can specify the action for certificate validation errors and insecure cipher algorithms. You can
also enforce an RSA key size and SSL/TLS versions to use.
18 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
Tip
When you specify a setting in both the decyption profile and SSL/TLS inspection
settings, the settings in the decryption profile override the settings in SSL/TLS
inspection settings.
Note
You can't edit the default profiles.
The default profiles are as follows:
Maximum compatibility: Decrypts as many connections as possible. Doesn't restrict cipher usage.
Block insecure SSL: Prevents the use of weak ciphers. Allows non-decryptable traffic.
Strict compliance: Implements strict compliance. Use this to meet PCI DSS (Payment Card
Industry Data Security Standard) specifications.
3.1.6 Add a decryption profile
Decryption profiles enable you to enforce decryption settings on SSL/TLS connections.
Warning
Android devices are known to generate SSL/TLS certificate errors, causing decryption
to fail. We recommend creating an SSL/TLS exclusion list for all Android devices.
1. Go to Profiles > Decryption profiles and click Add.
2. Enter a name.
3. Optional Add a description.
4. Specify the re-signing certificate authority for SSL/TLS connections intercepted by XG Firewall.
Re-signing certificates must be trusted by the endpoint devices. If they aren’t, browsers will
show a warning and may refuse to complete the connection.
Tip
Under most circumstances, this requires the installation of copies of the
certificates in the browsers or the operating system certificate stores of the
endpoint devices. Alternatively, you can create and use signing certificates that
are subordinate to an existing trusted enterprise CA for your organization. It
isn’t possible to obtain signing certificates from CAs that are already trusted by
operating systems or browsers.
Most certificate authorities use certificates with either RSA or Elliptic Curve (EC) encryption
keys. In most situations, certificates of one type can be signed by certificate authorities of the
other, allowing you to use the same CA for both. If you encounter problems with applications
that expect certificates of only one type, you can add an EC key and use it for re-signing
certificates that were originally signed by an EC-based authority. If you add a second CA,
ensure that it is trusted by all endpoint devices.
Copyright © Sophos Limited 20200908 19Sophos XG Firewall release notes New features
Name Description
Use CAs defined in SSL/TLS settings Uses the certificate authority specified in
SSL/TLS inspection settings.
Re-sign RSA with Used when the website’s certificate was
signed using RSA.
You can specify an EC or RSA certificate.
Re-sign EC with Used when the website’s certificate was
signed using EC.
You can specify an EC or RSA certificate.
5. Specify the action for non-decryptable traffic, such as insecure protocol versions, occurrences,
and cipher suites.
Name Description
SSL 2.0 and SSL 3.0 Allowing these connections lowers security.
SSL compression Compression before encryption has known
vulnerabilities.
When SSL/TLS connections exceed limit Applies to excess traffic when volume
exceeds the decryption capability of the
firewall.
To see the decryption limit, go to
Control center and select the SSL/TLS
connections widget.
Unrecognized cipher suites Firewalls can’t decrypt traffic using
unrecognized cipher suites. Using
unrecognized cipher suites lowers security.
Action for non-decrytable traffic:
• Use SSL/TLS settings default: Applies the action specified in SSL/TLS inspection settings.
This option doesn’t apply to unrecognized cipher suites.
• Allow without decryption
• Drop: Drops without notifying the source.
• Reject: Drops and sends a connection reset message to the source host.
20 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
Note
XG Firewall rejects connections using SSL 2.0 and 3.0, SSL compression, and
Unrecognized cipher suites if you set the action to Decrypt in SSL/TLS inspection
rules.
To allow these connections, create a decryption profile set to Allow without
decryption. Add the profile to an SSL/TLS inspection rule with the action set to
Don't decrypt.
6. Specify the certificate, protocol, and cipher enforcement details.
Name Description
Certificate errors to block Select the certificate errors. XG Firewall
blocks connections that have the specified
errors.
• Invalid date
• Self-signed
• Untrusted user
• Revoked
• Name mismatch: Checks that the server
name requested in the Client Hello
matches the domain names represented
by the certificate.
• Invalid for other reasons
If you created an exception for HTTPS
decryption in Web > Exceptions, XG
Firewall allows traffic with invalid certificates
if the traffic matches the exception criteria.
Minimum RSA key size Select a minimum key length.
Keys less than 2048 bits are no longer
considered secure. Allow them only if it's
necessary to ensure compatibility with older
servers that can't be upgraded.
Minimum SSL/TLS version Select the minimum protocol version to
allow.
Versions earlier than TLS 1.2 are no longer
considered secure. Allow them only if it's
necessary to ensure compatibility.
Copyright © Sophos Limited 20200908 21Sophos XG Firewall release notes New features
Name Description
Maximum SSL/TLS version Select the maximum protocol version to
enforce.
To implement the latest available version,
select Maximum supported. When a
later protocol version becomes available,
XG Firewall will implement that version
automatically.
Cipher algorithms to block Select the key exchange, authentication
mechanism, bulk ciphers, and hash
algorithms to block.
Block action Select the action to apply.
• Drop: Drops without notifying the
source.
• Reject: Drops and sends a connection
reset message to the source host.
• Reject and notify: Establishes the
connection but prevents any data
transfer with the server. For HTTPS
connections, attempts to display a block
page with the error reason to the user.
For TLS 1.3 connections, you need to set the action to Decrypt in SSL/TLS inspection rules to
do the following:
• Block certificate errors and apply the minimum RSA key size specified in decryption
profiles.
• Apply the block action Reject and notify specified in the decryption profile. If you apply
such a decryption profile to SSL/TLS inspection rules with Don't decrypt or Deny action,
XG Firewall applies the block action Reject.
7. Click Save.
Go to Rules and policies > SSL/TLS inspection rules and add the decryption profile to a rule to
specify the action.
3.2 Sandstorm threat intelligence analysis
Sophos Sandstorm gains an added layer of artificial intelligence protection. All suspicious files are
now subject to threat intelligence analysis in parallel with full sandbox analysis. Files are checked
against the Sophos Labs threat intelligence database and subjected to our industry-leading deep
learning. This identifies new and unknown malware quickly and efficiently, often rendering a verdict
in seconds, to stop the latest zero-day threats before they get on the network.
22 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
3.2.1 Threat intelligence widget improvements
The Threat intelligence, formally shown as Sandstorm, widget on the dashboard now shows
new files, incidents and total scanned files to give a clearer picture of threats seen by Sophos
Sandstorm.
3.2.2 Threat intelligence reporting changes
The Threat intelligence report has been improved to give greater insight into threats seen on the
network.
Threat intelligence uses multiple different analysis techniques and combines these to determine if a
file is likely to be malicious or not. This gives you more information and helps reduce false positive
detections. You can also view the analysis, release status, report details and release files or emails.
• To view details of a scan, hover over the detection status of an entry. This shows a brief
overview detailing the threat result at each stage of Sandstorm processing. To view the full
report, select View report.
• To filter the results, click Filter and specify criteria.
• To view the details of Sandstorm analysis, select the more options button, , and then select
Show report.
• To release a file or email message, click Release now.
When you release a file, users can download it immediately. Only files that are currently being
analyzed or that have been returned with error status are eligible for release. Sandstorm continues
to analyze the file even if you release it.
CAUTION
Releasing an item before the analysis is complete may result in the downloading of
malicious content.
Reports contain the following information:
Download For example, the source, download time, and users who downloaded the file.
details
Analysis Shows the overall Sandstorm result of the file. Files can be classified as clean,
summary likely clean, suspicious, malicious, or PUA (Potentially Unwanted Application). You
can also see an overview of the main file details.
Machine Shows the overall machine learning result, file feature analysis, feature combination
learning analysis and the file structure analysis.
analysis
Reputation The result of this analysis is based on how widely-seen the file is.
analysis
Copyright © Sophos Limited 20200908 23Sophos XG Firewall release notes New features
Sandstorm Shows the activities the file carries out, screenshots of the file being run in
detonation Sandstorm, details of the processes the file uses and the registry activity
results generated.
Full file Shows full details of the file. This section contains details of the file signatures and
analysis any certificates used, the resources called, imports carried out, such as DLLs used
and any export functionality.
VirusTotal Shows how many reports for the specific threat are currently shown in the
report VirusTotal database and the number of malware detection products that currently
detect the file.
3.3 Sophos Central Firewall Reporting and
Management
This release includes support for new firewall reporting and management capabilities being
launched simultaneously on Sophos Central including a rich powerful new reporting suite and group
firewall management tools.
Go to Central synchronization.
Sophos Central services
From XG Firewall, you can turn on centralized reporting, management, and configuration backup in
Sophos Central. To use this feature, register this firewall with Sophos Central.
After turning on the services, a Super admin must take action in Sophos Central to activate these
services.
Name Description
Sophos Central Turn it on to configure centralized reporting, management, and
services configuration backup of this XG Firewall from Sophos Central.
In Sophos Central, select Global settings. Under Administration,
select Registered firewall appliances to see the list of registered
appliances.
Use Sophos Central Select to turn on centralized reporting.
reporting
In Sophos Central, go to Firewall management > Firewalls. Go to the
firewall and select Accept services.
Use Sophos Central Select to turn on centralized management.
management
In Sophos Central, go to Firewall management > Firewalls. Go to the
firewall and select Accept services.
24 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
Name Description
Send configuration If you've selected Use Sophos Central management, select this to
backup to Sophos save configuration backups in Sophos Central.
Central
In Sophos Central, go to Firewall management > Backup. Specify a
backup schedule or generate the backup.
For details of centralized reporting and management, go to Sophos Central help.
3.4 NAT Enhancements
XG Firewall’s NAT configuration receives a major update as NAT rules are now decoupled from
Firewall Rules enabling more powerful and flexible configuration options including Source (SNAT)
and Destination (DNAT) in a single rule. NAT Rules can still be “snapped-in” to a Firewall Rule and
edited in-place similar to other snap-in policies such as IPS and Web policies.
3.4.1 NAT rules
With Network Address Translation (NAT), you can modify the IP addresses and ports of traffic
flowing between networks, generally between a trusted and an untrusted network.
It translates private IP addresses into public IP addresses, allowing private IP networks to connect
to the internet and hiding the internal network behind the public IP address.
You can create source NAT (SNAT) and destination NAT (DNAT) rules to enable traffic flow
between private and public networks by translating non-routable, private IP addresses to routable,
public IP addresses. You can create NAT rules for IPv4 and IPv6 networks.
You can specify loopback and reflexive rules for a destination NAT rule. These rules remain
independent of the original rule from which they’ve been created. Changing or deleting the original
NAT rule doesn’t affect them.
Linked NAT rules are SNAT rules and are created from firewall rules. XG Firewall automatically
adds a linked NAT rule to match traffic for email MTA mode.
To allow traffic flow between overlapping local subnets, you need to configure NAT over policy-
based IPsec VPN on VPN > IPsec connections. For details, go to knowledge base article 123356.
• To add a NAT rule manually, select Add NAT rule and then select New NAT rule.
• To create destination NAT rules and the related firewall rules automatically, select Add NAT
rule and then select Server access assistant (DNAT).
Server access assistant (DNAT)
Use this to create DNAT rules to translate incoming traffic to servers, such as web, mail, SSH, or
other servers, and to access remote desktops. The assistant also creates a reflexive SNAT rule (for
outbound traffic from the servers), a loopback rule (for internal users accessing the servers), and a
firewall rule (to allow inbound traffic to the servers) automatically.
Rule table actions
• To see IPv4 or IPv6 rules in the rule table, select IPv4 or IPv6.
Copyright © Sophos Limited 20200908 25Sophos XG Firewall release notes New features
• To hide or show the rule filter, select Disable filter and Enable filter respectively.
• To reset the rule filter, select Reset filter.
• To turn off rules, select the rules and then select Disable.
• To delete rules, select the rules and then select Delete.
• To change the sequence of a rule, drag and drop the Rule handle button . XG Firewall
evaluates rules from the top down until it finds a match. Once it finds a match for the packet, it
doesn’t evaluate subsequent rules. So, position the specific rules above the less specific rules.
Click More options to specify the following actions:
• To turn on or turn off a rule, select the switch.
• To edit or delete a rule, select the action.
• To add a rule next to an existing rule, select the action.
• To unlink a rule from the firewall rule, select Unlink rule.
• To reset the number of times a rule was in use, select Reset usage count. This is useful when
troubleshooting.
Firewall rules and NAT rules
Firewall rules allow or drop traffic entering and exiting the network. NAT rules translate IP
addresses for traffic the firewall rule allows. So, you must create firewall rules even when you have
NAT rules.
If XG Firewall doesn't find a firewall rule that matches the traffic criteria, it drops the traffic and logs
the event. If it doesn't find a matching NAT rule, it allows the traffic to flow but doesn't translate the
IP address.
For NAT rules, the matching criteria are the original (pre-NAT) source, destination, and service, and
the inbound and outbound interfaces. The order in which XG Firewall looks up and applies NAT and
firewall rules is as follows:
• Outgoing traffic: XG Firewall applies the firewall rule first and then the SNAT rule.
• Incoming traffic: XG Firewall looks up the DNAT rule first to determine the translated (post-
NAT) destination. It then matches the firewall rule based on the source and destination zones,
source and destination networks, services, and schedule. For the destination zone, it uses the
zone to which the translated (post-NAT) destination belongs.
Example: For traffic from the WAN or the LAN zones to your web server in the DMZ, you can
create a DNAT rule to translate your public IP address (original destination) to the web server's
IP address (translated destination).
When packets arrive, XG Firewall looks up the DNAT rule. It identifies the zone containing the
translated destination that you specified. In this example, it identifies DMZ as the destination
zone.
So, to create a firewall rule matching this traffic, you must set the destination zone to DMZ.
For an example of how to create a DNAT rule and the corresponding firewall rule, see the
related link on this page: Create DNAT and firewall rules for internal servers.
26 20200908 Copyright © Sophos LimitedNew features Sophos XG Firewall release notes
Source NAT
You can create source NAT rules for outgoing traffic to enable internal clients and servers to access
external hosts. XG Firewall implements one-to-one, many-to-one, and many-to-many translation.
Some of these involve port address translation.
You can also define interface-specific NAT to translate the IP addresses of one or more internal
hosts to the IP address you specify for an outbound interface.
You can’t create a source NAT rule using a public interface that’s a bridge member because bridge
members don’t belong to a zone. If you configure a public interface as a bridge member, source
NAT rules using the interface are deleted.
Destination NAT
You can create destination NAT rules for incoming traffic to enable external hosts to access internal
clients and servers. You can specify one-to-one, many-to-one, many-to-many, and one-to-many
translation from your public IP addresses to private IP addresses.
You can also specify a load balancing method and health check for the translated destination hosts,
for example, web or email servers.
Service translation
XG Firewall implements port forwarding with service translation. Services are a combination of
protocols and ports. The translated protocol must match the original protocol.
XG Firewall implements one-to-one, many-to-one, and many-to-many translation. For many-to-
many translation, the ports for the original and translated services must be equal in number.
Note
The web admin console of XG Firewall and the user portal are accessible over HTTPS
through the default ports 4444 and 443 respectively. If your public IP addresses are
configured with HTTPS port forwarding to internal web servers, go to Administration
> Admin settings and specify unused ports for the Admin console HTTPS port
and the User portal HTTPS port. Alternatively, specify a different port for your web
servers.
Loopback rules
You can create loopback rules from destination NAT rules to allow internal hosts to communicate
with other internal hosts over the external IP address or the domain name. For example, create a
destination NAT rule to translate incoming traffic to your servers and create a loopback rule.
To create a loopback rule, specify the following destination NAT rule criteria:
• Original source: Any
• Translated source: Original
• Translated destination: Don’t set to original.
Reflexive rules
You can create a mirror NAT rule for destination NAT rules. It reverses the matching criteria of
the destination rule. For example, create a destination NAT rule to translate incoming traffic to
an internal server. The corresponding reflexive rule will allow traffic from the server to the source
specified in the destination NAT rule.
Copyright © Sophos Limited 20200908 27Sophos XG Firewall release notes New features
If the original destination isn’t an IP address or is translated, the translated source is masqueraded.
Linked NAT rules
You can create linked NAT rules when you create firewall rules. These are SNAT rules and appear
in the NAT rule table.
XG Firewall introduced linked NAT rules in 18.0 to ensure a smooth migration from earlier versions
in which the NAT configuration was part of the firewall rule.
All the matching criteria of a firewall rule, including users and schedule, apply to its linked NAT rule.
You can't edit these settings in the NAT rule. You can only specify the translated sources, including
interface-specific translated sources in a linked NAT rule.
XG Firewall matches linked NAT rules only with traffic related to the firewall rule to which it's linked.
However, if it finds a match with a rule above the linked NAT rule, it applies the first rule's settings.
Tip
We recommend that you don't create new linked NAT rules when a generic NAT rule
matches the traffic. Create NAT rules independently to simplify your configuration
because you need fewer NAT rules than firewall rules. For example, you may only
need a single SNAT rule to masquerade outgoing traffic in a simple environment. You
don't need to create an SNAT rule for each firewall rule.
Migrated NAT configurations
When you migrate from an earlier version to SFOS 18.0, XG Firewall migrates the NAT settings of
firewall rules as NAT rules and lists them in the NAT rule table. You can't define a gateway-based
NAT configuration any longer.
Source NAT settings are migrated as linked NAT rules. These rules are linked to the original firewall
rule. You can identify these by the firewall rule ID and name in the NAT rule table.
Destination NAT settings are migrated as independent NAT rules and aren’t linked to a firewall rule.
Pre-migration rules Post-migration rules
User/Network rules Source or destination NAT rules based on the
pre-migration criteria.
Email clients Source NAT rules
DNAT/Full NAT/Load balancing Destination NAT rules with corresponding
firewall rules.
Email servers Destination NAT rules
NAT settings are migrated as follows:
Source NAT (SNAT) rules:
• Masqueraded and translated source addresses are migrated as they are.
28 20200908 Copyright © Sophos LimitedYou can also read
