Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 27 subscribers
  • Views 957 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos XG v18 MR3 - Malware and content scanning issues

eriikooz

Hi,

In my test Environment i saw when i run apt-get update && upgrade on my two linux servers (Debian and Ubuntu) that the malware and content scanning was blocking the sources.list urls:

deb http://ftp.debian.org/debian buster main contrib non-free

deb http://ftp.debian.org/debian/ buster-updates main contrib non-free

deb http://security.debian.org/ buster/updates main contrib non-free

deb archive.ubuntu.com/.../ focal main restricted

deb security.ubuntu.com/.../ focal-security main restricted

This is a new behavior for the XG v18 and must have come with MR3 update. I remember that this was working in MR1.

My workaround was to manually create web exeptions for those URLs but i cannot se why the sophos v18 MR3 detects those apt sources as malware by default. This will be a problem for all linux servers when they need to update. I have opened all the urls from sources.list in a webbrowser, and the site loads, but just shows a blank page with no message.

My webfilter is not strict and i have tried to disable that webfilter, but it will return with the same error/false positive. The thing is that malware and content scanning in blocking.

The only way to fix this is to disable the Malware and content scanning under the firwall rule OR create an web exeption for those url's above. I can see some blocks in the webfilter firewall for security... logs, but most are allowed to thoese URL's. The thing is that the apt-get update start to loop on GET1, GET2, GET3, GET1, GET2, GET3.... And the only way to see this error is to surf to the site and get a blank page or disable things and it starts to works again. Strange error :(

I can see that this is a false positive (badly). 

Anyone else who have had this? Any ideas how to fix this without exeptions?

Regards,



This thread was automatically locked due to age.
  • 0

    I guess that debian is not trusting the certificate of your proxy when the traffic is beeing scanned. Are you using DPI or Proxy?

    We have several apps or services that simply don't work when SSL Interception and Malware scanning are not excluded for the URLs.

    Latest example from today: Jabra Direct app for Headphones: it did not work to attach and use a new headset that has never been attached to the PC - the app needs to call home and report telemetry data to jabra.com could servers on several sub domains. Nothing was blocked in the logs it just did not work. Skipping jabra.com and sub domains from the scanning in webproxy and everything worked immediately again.

    Funny fact: this worked for month and years before - they changed something in their app and probably are only excepting hard coded SSL certificates from jabra.

    As the webproxy is resigning with its own cert, the app does'nt trust the connection.

  • 0 in reply to LHerzog

    Does that make sense, when im not using HTTPS-decryption in the test enviorment? Or maybe i missunderstood something. :)

    Firewall rule:

    Source: LAN

    Destination: WAN

    NAT-link: MASQ

    Web policy: Default Webpolicy

    Malware and content scanning: Scan HTTP and decrypted HTTPS and Scan FTP for malware. NOTE here: I have not enabled SSL/TLS (The rules below won't be applied because SSL/TLS inspection is switched off.)

    Filtering common web ports: Use web proxy instead of DPI engine

    I have tried both Proxy and DPI, when testing with DPI, I do in fact get sometime 443/SSL errors output from apt-get. 

  • 0 in reply to eriikooz

    I would suggest you leave general SSL scanning enabled of course but test with an exception rule in webfilter for the URLs you have written above. And unselect FTP filtering on that rule. You can select the Repository Servers as destination of this rule and leave FTP scanning enabled on an other, more general rule below.  If it works you're on the right path.

    Something like this:

    Web Exception example: