Resurrecting this one from the dead. This rule is a problem for me. I am seeing many false positives (FP). Here is one such example:
Mar 18 06:49:17 linuxhost tac_plus[97654]: login failure: root 192.168.1.50 >> (192.168.1.50) 52209 > > Mar 18 06:49:17 linuxhost tac_plus[97654]: login failure: root >> 192.168.1.50 (192.168.1.50) 52209 > > 2016 Mar 17 09:49:15 WinEvtLog: Security: AUDIT_SUCCESS(4722): >> Microsoft-Windows-Security-Auditing: (no user): no domain: >> WINDOWSHOST.domain-internal.com.internal: A user account was enabled. >> Subject: Security ID: S-1-5-XX-XXXSIDXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXXX >> Account Name: username Account Domain: DOMAIN-INTERNAL Logon ID: 0x2xxXXXX >> Target Account: Security ID: >> S-1-5-XX-XXXSIDXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXXX Account Name: >> VM01XXXX-XXXXXX$ Account Domain: DOMAIN-INTERNAL > > As you can see this is an obvious FP. Can someone weigh in here on how we can remediate these issues? Some days we see 100+ FP's. Thanks in advance, Dustin On Wednesday, November 16, 2011 at 9:52:38 AM UTC-8, Franky4fngrs wrote: > > Hello, > > I have an ossec deployment with a little over 700 agents > communicating. The issue I am having is that rules such as 40501 > report a large number of false positives. There are a large number > of brute force attacks across the environment at any given time. > Whenever a legitimate user logs in the alert is triggered. I have not > seen an obvious (to me) way to modify the rules, or groups to address > this issue. Has anyone tackled this issue before? > > Thanks > > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
