Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • +3 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 14 subscribers
  • Views 29882 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

HIGH Alert - Real time protection disabled... and Sophos is always wrong.

plochner

Getting pretty annoyed by these false HIGH ALERTS from Sophos. Here's a log from only a single computer over the past week:

Notice how there's an update that's pushed through which probably takes 2 minutes to actually install on the users computer. Since the update is being applied, most likely the Sophos services have to quickly restart, so Sophos stupidly thinks that REAL TIME PROTECTION HAS BEEN DISABLED, OH MY GOD BETTER SEND AN ALERT! This is pretty idiotic behavior.

The user doesn't have the ability to disable Real Time Protection anyway and based on the log files, it's very clear that the update itself is what's disabling the protection, and it's only disabling it for as long as it takes to apply the update.

Why does this happen?

As far as the alert itself, I'd love to disable these email alerts but as noted in my other thread at:

https://community.sophos.com/products/sophos-central/f/sophos-central/96169/email-notifications-for-different-alerts-to-different-groups---not-possible

Sophos central doesn't give you a way to disable these alerts or send them to different people! These design decisions are baffling and frustrating.



This thread was automatically locked due to age.
Parents
  • 0

    Are these the actual software updates?  Not just the definition ones?  I believe you can control the software updates install schedule.  I am merely suggesting there may be a way to have better control of when they happen to better know which ones you should be aware of.  Also, without the alert a hacker could exploit the code to initialize an update thus stopping the service and then executing their attack.  Personally I see no issue with extra logging or alerts.  But I do agree that there should be an alert to say it has restarted right after that and or some type of notification that would help so you know it is normal.  Maybe even sending one every ten minutes until the alert is cleared so if you see one and then don't see one ten minutes later you would know it is fine.

     

    Respectfully, 

     

    Badrobot

     

Reply
  • 0

    Are these the actual software updates?  Not just the definition ones?  I believe you can control the software updates install schedule.  I am merely suggesting there may be a way to have better control of when they happen to better know which ones you should be aware of.  Also, without the alert a hacker could exploit the code to initialize an update thus stopping the service and then executing their attack.  Personally I see no issue with extra logging or alerts.  But I do agree that there should be an alert to say it has restarted right after that and or some type of notification that would help so you know it is normal.  Maybe even sending one every ten minutes until the alert is cleared so if you see one and then don't see one ten minutes later you would know it is fine.

     

    Respectfully, 

     

    Badrobot

     

Children
  • 0 in reply to Badrobot

    Given that the status gets to Central, I would suggest enabling MCS trails.  That way you will have the history of all status messages sent.  This has to be for the SAV component and it has to be reporting that on-access is false.

    How to enable trails is here:

    https://community.sophos.com/kb/en-us/119608

    Once you see the issue, ideally maybe a couple of times, can you look for the SAV status messages.  What is the scenario when the on-access is reported as disabled?  Is it at startup for example?  Is the message followed up shortly after with a status message where on-access is reported as enabled?

    Regards,
    Jak

  • 0 in reply to jak

    MCS trails are very informative, thanks for sharing this tip, but it really shouldn't be this hard...

    This feature should be an option in the UI, we shouldn't have to dig for it at the workstation, these are your executables and services, so this should be a management option directly from Central like this:

    Michael

  • 0 in reply to Michael McGee

    I concur, this should definitely be a management GUI feature.

  • 0 in reply to Trojan Horse

    I understand via Support access, it is possible to turn on message trails on all computers.  I'm not sure of the scenario where I would want all computers to write/store message trails.

    I would have thought you'd only need to enable it on a couple of computers at a time.  A short PS script to sort out the XML and restart the MCS service.

    Jak

Unfiltered HTML