Snare logs are not parsed correctly with new filters from r368

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Search for logs containing event ID 5145 or 5140

What is the expected output? What do you see instead?
Exepcted: share_name and share_target contain correct information
Current: share_name contains Success/Failure Audit and share_target contains 
the domain name of the reporting server.

What version of the product are you using? On what operating system?
RHEL 6, r371

Please provide any additional information below.
It may just be Snare logs that have problems with this, looks like your changes 
were written only for Event to Syslog logs?

Original issue reported on code.google.com by sitko.ma...@gmail.com on 7 Aug 2012 at 4:16

[GoogleCodeExporter]

Yep, the parser changes were only for eventlog-to-syslog, so Snare would have 
missed out.  Can you provide a Snare example log so I can fix the Snare parser?

Original comment by mchol...@gmail.com on 7 Aug 2012 at 7:26

[GoogleCodeExporter]

Original comment by mchol...@gmail.com on 7 Aug 2012 at 7:26

[GoogleCodeExporter]

Aug 08 00:01:57 
2012|4776|Microsoft-Windows-Security-Auditing|USERNAME|N/A|Success 
Audit|HOSTNAME|Credential Validation||The computer attempted to validate the 
credentials for an account. Authentication Package: 
MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon Account: USERNAME Source 
Workstation: WORKSTATION Error Code: 0x0|10622153 

host=HOSTIP program=security class=WINDOWS eventid=4776 srcip=0.0.0.0 
source=Microsoft-Windows-Security-Auditing user=USERNAME domain=N/A 
share_name=Success Audit share_target=HOSTNAME category=Credential Validation 

Original comment by sitko.ma...@gmail.com on 8 Aug 2012 at 1:05

[GoogleCodeExporter]

4776 isn't covered by the "share" parser in either yet.  Does this happen with 
5145 or 5140?

Original comment by mchol...@gmail.com on 8 Aug 2012 at 3:53

[GoogleCodeExporter]

Well, I suppose the issue I'm noticing is affecting every new log since the 
update.  At the time I only noticed it with 5145 events after the update.  
Every log I've seen so far has the incorrect info at share_name/target

Original comment by sitko.ma...@gmail.com on 9 Aug 2012 at 3:16

[GoogleCodeExporter]

Yes, share_name/share_target will be incorrect for every log not 5145 or 5140.  
So many parsers to write, so little time!  The canonical solution would be to 
implement a hierarchial class structure so that we can have parent classes and 
subclasses.  This is on the roadmap but will be awhile.  In the meantime, can 
you confirm that 5145 and 5140 look correct for you?

Original comment by mchol...@gmail.com on 9 Aug 2012 at 3:27

[GoogleCodeExporter]

Closing due to inactivity.

Original comment by mchol...@gmail.com on 29 Nov 2012 at 10:39

• Changed state: Done