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

100s of Events (Id 5152) from Sophos Endpoint Protection on Windows desktops and servers (multiple versions)

Robert Praetorius

This is a continuation of Sophos Endpoint Protection generating 100s of Events - Discussions - Intercept X Endpoint - Sophos Community, which is still happening and has never received a satisfactory answer (using auditpol to suppress these message is not a legitimate solution, because it indiscriminately suppresses reports of both valid and invalid 5152 events).

The aspect of the problem I'm reporting here is an apparent bug with the uninstaller.

We are no longer a Sophos customer (not my decision and the decision wasn't made because of this issue), but we are still seeing these events.  Uninstalling Sophos software resolved the issue on most systems, but not all of them.  (You might ask: why do you still think this has anything to do with Sophos?  See the earlier thread for some fairly convincing evidence.)

Note that this was never an issue with Sophos software by itself; rather it's an issue with interaction between Sophos Endpoint Protection and actions taken by Sophos through the Windows firewall API (at least that's the best theory I can come up with given the evidence that's available out there on the internet).  Note also that Sophos is not the only endpoint protection vendor that has this problem with the Windows firewall.

This leaves with me with the theory that, whatever Sophos did to Windows firewall, it was able to undo, in most cases.  In other cases, it left the Windows firewall's internal database in a confused state.  Perhaps Microsoft has most of the responsibility for this bug, but it is quite rare to see the 5152 problem on Windows systems without 3rd party endpoint protection and quite a bit more common to see it on systems that do have 3rd party protection.

It's easy to visualize mutual fingerpointing between the 3rd party vendors and Microsoft in this area, which is perhaps why the problem has continued for more than a decade.

This problem is also reported in https://community.sophos.com/on-premise-endpoint/f/sophos-endpoint-software/104223/100-s-of-logged-events-the-windows-filtering-platform-has-blocked-a-packet-5152-it-appears-that-sophos-end-point-security-is-causing-out-log-files-to-fill-up-with-this-error-and-may-be-generating-unnecessary-network-traffic-a, https://community.sophos.com/intercept-x-endpoint/f/discussions/112965/sophos-endpoint-causing-1000s-of-audit-failures-in-event-viewer and https://ideas.sophos.com/forums/428821-sophos-central/suggestions/34754446-cannot-disable-firewall-monitoring (and in a number of places outside this community)



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

    I was looking into this and found what I believe to be the answer to this issue.

    First Sophos support states that they turned on the monitor for this but its not clear why since they just tell you to turn it off.

    Second Microsoft logging on this event sucks by their own admission.

    This is a response to this question that I found regarding dropped packets from legit sources. In my case I had LDAP 389 for applications running on domain servers that were the source of my initial WTFness (real word look it up).

    "The packet drop events are being generated as part of a set of “built-in” stealth filters. These stealth filters were introduced in Vista/2008 to ward off port-scanning attacks. Their purpose is to prevent outbound responses (such as TCP resets) to inbound packets sent for the purpose of port IP and port discovery. The 5152 events are misleading in this way because from the text they seem to indicate the INBOUND packet was dropped, when really, it was the OUTBOUND packet that was dropped. Our product team concurs that is just an idiosyncrasy of the implementation. When an inbound packet triggers a reset, the stack classifies the packet against the INBOUND_TRANSPORT_V4_DISCARD layers to determine if the reset should be sent. So in this case, “inbound” really means that the drop occurred during the processing of an inbound packet and before the outbound reset was even generated."

    Knowing this and the fact that It will continue to do with with Sophos removed from the device or fully disabled, this is 100% not a Sophos caused event. They just made it visible to you.

    Just turn off the log. It is causing undue stress.

    Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policy\Object Access     

    set it to configured and don't check success or failure to stop the event from getting people spun up because the log is pointless if it does not report properly.

    I found this answer here https://www.mickputley.net/2014/12/windows-firewall-auditing-and-other.html

    I put in a feature request for MSFT to fix the logging.

    NOTE TO SOPHOS:

    DON'T ADJUST THE LOG SETTINGS IF YOU DON'T NEED THEM. YOU ARE MAKING MORE WORK FOR US AND YOURSELF BY DOING THIS FOR NO APPARENT REASON.

  • 0 in reply to MattBowles

    Thanks for your great answer! I whish I would receive such by Support.

Reply Children
No Data
Unfiltered HTML