On Wed, Feb 27, 2019 at 1:43 PM <[email protected]> wrote:
>
> Thank you Dan,
>
> Another question, can I have more than 1 match string as shown below
>
> <rule id="181070" level="0">
> <if_sid>18107</if_sid>
> <id>^4624$</id>
> <match>Account Name:  svc_</match>
> <match>Logon Type:   3</match>
> <description>Ignore svc account network logons</description>
> </rule>
>
> This rule isn't firing correctly either. I'm aware that | exists as a logical 
> OR but I'm trying to do a logical AND
>

I think that would just concatenate the matches. You'd need to create
a child rule:
<rule id="181070" level="0">
  <if_sid>18107</if_sid>
  <id>^4624$</id>
  <match>Account Name:  svc_</match>
 <description>Ignore</description>
</rule>
<rule id="181071" level="0">
  <if_sid>181070</if_sid>
...

Or, use <regex>

> On Wednesday, February 27, 2019 at 10:20:00 AM UTC-8, dan (ddpbsd) wrote:
>>
>> On Wed, Feb 27, 2019 at 1:16 PM <[email protected]> wrote:
>> >
>> > I have been trying to write some rules for suppressing service account 
>> > network logons because they cause too much noise and are taking up a large 
>> > portion of our Splunk license.
>> >
>> > Here is the rule I wrote:
>> >
>> >  <rule id="181070" level="0">
>> >     <if_sid>18107</if_sid>
>> >     <id>^4624$</id>
>> >     <user>^svc_</user>
>> >     <match>Logon Type:   3</match>
>> >     <description>Ignore svc account network logons</description>
>> >   </rule>
>> >
>> > This rule has been eliminating most of the logon alerts but not all. so 
>> > when I looked in /var/ossec/logs/alerts/... I saw alerts that looked like: 
>> >     #specific information has been changed for security purposes
>> >
>> > ** Alert 1551290099.295331: - windows,authentication_success,
>> > 2019 Feb 27 09:54:59 (server_name) 172.0.0.0->WinEvtLog
>> > Rule: 18107 (level 3) -> 'Windows Logon Success.'
>> > Src IP: 172.0.0.0
>> > User: -
>> > 2019 Feb 27 09:56:10 WinEvtLog: Security: AUDIT_SUCCESS(4624): 
>> > Microsoft-Windows-Security-Auditing: svc_account: DOMAIN.COMPANY.COM: 
>> > server_name.domain.company.com: An account was successfully logged on. 
>> > Subject:  Security ID:  S-1-0-0  Account Name:  -  Account Domain:  -  
>> > Logon ID:  0x0  Logon Type:   3  New Logon:  Security ID:  
>> > S-1-5-21-601235460-1198158354-314601362-9378  Account Name:  svc_account  
>> > Account Domain:  DOMAIN.COMPANY.COM  Logon ID:  0x22d8656  Logon GUID:  
>> > {6B2C5C06-765A-8520-F93E-34F2752D5A48}  Process Information:  Process ID:  
>> > 0x0  Process Name:  -  Network Information:  Workstation Name: -  Source 
>> > Network Address: 172.0.0.0  Source Port:  12345  Detailed Authentication 
>> > Information:  Logon Process:  Kerberos  Authentication Package: Kerberos  
>> > Transited Services: -  Package Name (NTLM only): -  Key Length:  0  This 
>> > event is generated when a logon session is created. It is generated on the 
>> > computer that was accessed.
>> >
>> > So my initial thought is that because this has no user its not matching 
>> > correctly. I also have another rules for svc account logoffs that's nearly 
>> > identical to the one above and working 100%. I'm trying to understand why 
>> > its not finding a user when above you can see on the 2nd line "Account 
>> > Name:  svc_account". I dug a bit into the windows decoder on the github 
>> > repo:
>> >
>> > <decoder name="windows1">
>> > <type>windows</type>
>> > <parent>windows</parent>
>> > <regex> Account Name:\s+(\w+\.+)\s+Account</regex>
>> > <order>user</order>
>> > </decoder>
>> >
>> > My question is, does the decoder only match the first "Account Name: " 
>> > which is on the first line? Does anyone know a way to work around this and 
>> > still match these service accounts?
>> >
>>
>> Yes, it does. I'm hoping to get a chance to mess with the Windows
>> decoder after the dynamic decoder pull request gets merged, but all of
>> that requires free time.
>> You could try adding:
>> <match> Account Name:  svc_</match>
>> to a rule to see if that catches the rest.
>>
>> > --
>> >
>> > ---
>> > 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 [email protected].
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
>
> ---
> 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 [email protected].
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to