Thread Info
  • Replies 18 replies
  • Subscribers 9 subscribers
  • Views 7318 views
  • Users 0 members are here
Options
Suggested

EAP2: Please try this IPS scanning enhancement

RichBaldry

Since version 18, Sophos Firewall has been able to do port-agnostic SSL/TLS decryption and web filtering. This extends our inspection for web threats beyond ports 80 and 443. We've used this ability to release IPS signatures that can detect some HTTP attacks in decrypted traffic on any port.

In version 19, we've introduced a feature that will apply a broader range of web-related IPS signatures to decrypted TLS traffic, regardless of the port. Overall this provides a significant enhancement in our ability to protect against attacks that may try to circumvent regular IPS protection.

The feature is not enabled by default yet. We would really like to get some more exposure to a wider range of situations and traffic.

If you're using EAP2 and TLS decryption, it would be great if you could turn this feature on. Here's how to do it:

  • Connect to the device console using SSH, or using the 'Console' option in the drop-down menu in the top-right of the Control Center
  • Enter the admin password, then Select option 4 - Device Console from the Main Menu:
  • Enter the following command at the console> prompt:

console> set ips scan_decrypted_port_agnostic on

  • There will be a small delay while the configuration is changed and the IPS engine reloads

Enabling this feature may lead to an increase in the number of IPS signature events on your Firewall. Each firewall sends telemetry to SophosLabs when IPS signatures fire, enabling us to respond to potential false positives very quickly and update signature sets.

You can disable this feature again if necessary with the following command:

console> set ips scan_decrypted_port_agnostic off

Thanks for your help! Please feel free to tell us about your experiences in responses to this post.



Added tags
[edited by: RichBaldry at 6:10 PM (GMT -8) on 2 Feb 2022]
Parents Reply Children
  • in reply to l0rdraiden

    That's correct. It only has any effect on traffic that is (a) decrypted by the DPI engine due to a TLS rule, and (b) subject to IPS scanning.

  • in reply to RichBaldry

    Hi,

    I have been trying to workout a case for using SSL/TLS decryption on my network and not found any

    1/. does not work with mail protocols

    2/. does not decrypt UDP traffic

    3/. does not provide website blocking as per web policies.

    So, if you use SSL/TLS decrypt you still need a web proxy setting to enforce URL policy management. The devices I thought it might be useful on are not capable of having a CA installed, so scanning will fail.

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • in reply to rfcat_vk

    I think there's a bit of a misunderstanding around 3.

    Since 18.0, there have been two systems for enforcing web policy - DPI Engine and Proxy. Enabling SSL/TLS decryption allows the DPI Engine to enforce Web policy (including malware scanning) on decrypted HTTPS traffic without needing to use the proxy.

    The proxy is only required for web policy enforcement if you want to enforce policies that require modification of allowed traffic e.g. safe search enforcement, Google/Microsoft domain authentication enforcement. All other policy elements, along with file scanning of HTTPS downloads/uploads, are done by the DPI Engine.

    It's true that it doesn't work with mail policies or UDP traffic, and that, as with any inline TLS decryption, you need to be able to install a local CA on the device. But it's a more secure and efficient solution than using the proxy for HTTPS decryption and generally provides better overall performance.

  • in reply to RichBaldry

    Hi Rich,

    thank you for taking the time to respond. The SSL/TLS engine and DPI do not block tunnels because tunnels in a lot of cases will fallback to UDP.

    Still analysis my firewall rules to determine if I can not use the proxy on some functions.

    Then there is the other issue  of not being able move the default rule down the processing order, the only way is clone it, then disable it.

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • in reply to RichBaldry

    Hi Rich,

    this is being a bit picky maybe, but why does the SSL/TLS rule listing show the firewall rule number as the processing order, while the firewall rules and NAT show the processing number down the lefthand side and the rule number towards the righthand side?

    Regards

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • in reply to rfcat_vk

    I take your point. The TLS rule number on the left-hand side is the fixed rule number - if you re-order rules the ID doesn't change. But this is different to the Firewall & NAT rules, which always show the order down the left and put the ID on the right. The simple answer is that the different UI pages are sometimes built and maintained by different teams, the TLS rules design was based on an older version of the Firewall rules table, and since release there have been more important things for the teams to work on. I hope we can find cycles to realign these views soon.

Unfiltered HTML