Good evening,
We have just finished rolling out SEP 11.0.5002.333 onto over 85+ Workstations nationwide - everything went swimmingly well (well atleast we thought so) until over the last few days we have began to notice some strange happenings. I first began my research 2 days ago, sifting through over hundreds of websites and forums for an answer, having only come up with ONE relevant link - funnily enough coming from this exact website - but has been over a year since the last comment, and ended with no official statement from Symantec or answer as a whole, the topic can be found here:
http://www.symantec.com/connect/forums/sep-11-security-event-id-599-domain-controller
Moving on.
Soon after installation (the next day for example when users came into the office after the Weekend) they began to receive an error upon trying to log in, stating that 'Their Security Log was full, and needed an Administrator to log on to clear' - obviously this sparked my interest as this hasn't happened over the last 18 months since these workstations went out - and obviously anything to do with Security/Logs is the upmost of importance. Upon further inspection I found that indeed the Security Log had become full, and not from normal entries (one every so often) it had become BOMBARDED (See images below).
Think there had been some 'over the weekend' attempt to hack/gain access to our internal network I went into a fury trying to decipher the cause, going through server/firewall logs for over 5 hours. To my amazement I found the above link, pointing me in the direction of Symantec, and the cause for our issues.. SEP. Upon looking deeper into the entries I found that there are THREE main culprits; CValidateComCaller, LSASS.exe and svchost.exe (See logs below):
Event Type: Failure Audit
Event Source: Security
Event Category: Detailed Tracking
Event ID: 599
Date: 18/02/2010
Time: 11:44:32 AM
User: NT AUTHORITY\SYSTEM
Computer: [PC NAME]
Description:
Unprotection of auditable protected data.
Data Description: CValidateComCaller
Key Identifier: 0df96b2f-0cd9-47c1-8a76-72da5ee2afc0
Protected Data Flags: 0x0
Protection Algorithms: 3DES-168 , SHA1-160
Failure Reason: 0xD
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Event Type: Failure Audit
Event Source: Security
Event Category: Detailed Tracking
Event ID: 861
Date: 18/02/2010
Time: 8:59:50 AM
User: NT AUTHORITY\NETWORK SERVICE
Computer: [PC NAME]
Description:
The Windows Firewall has detected an application listening for incoming traffic.
Name: -
Path: C:\WINDOWS\system32\svchost.exe
Process identifier: 1108
User account: NETWORK SERVICE
User domain: NT AUTHORITY
Service: Yes
RPC server: No
IP version: IPv4
IP protocol: UDP
Port number: 63481
Allowed: No
User notified: No
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
The above are just TWO of the entries, the only differences between the logs are the Event number; either 861 or 599 and the Port Numbers. I have spent the last couple days trying to find a resolution for this, one I have found a QUICK fix, which I am NOT happy with as a final fix - and something Symantec NEEDS to look into. The quick fix applied is setting the option "Overwrite As Needed" under the Security Log settings - also read (over my travels) that the disabling of the GPO or LGPO setting to log 'Failure Audits' is also a fix.
Again the above is NOT a satisfactory resolution as I SHOULDN'T have to be disabling anything, let alone SECURITY related settings!
I anxiously await replies as this is becoming an annoyance that myself and my I.T. Staff do not want to deal with every morning - going around over 85+ Workstations and manually clearing logs is TOTALLY unacceptable!