I'm unclear why my rule is not matching...

[Ian Brown]

I've got this event log in windows:

2017 Jul 02 22:38:47 WinEvtLog: Security: AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): no domain: leaf-1: The Windows Filtering Platform blocked a packet. Application Information: Process ID: 0 Application Name: - Network Information: Direction: %%14592 Source Address: 192.168.1.120 Source Port: 39740 Destination Address: 192.168.1.255 Destination Port: 32414 Protocol: 17 Filter Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer Run-Time ID: 13

I'd like to ignore entries that contain the broadcast address 192.168.1.255.

If I fire up "ossec-logtest -v" and feed that log line into the app, I see that it matches against the sid 18105:

    Trying rule: 18105 - Windows audit failure event.
       *Rule 18105 matched.
       *Trying child rules.
    Trying rule: 18120 - Windows login attempt (ignored). Duplicated.
    Trying rule: 18153 - Multiple Windows audit failure events.
    Trying rule: 18106 - Windows Logon Failure.
    Trying rule: 18139 - Windows DC Logon Failure.
    Trying rule: 18180 - MS SQL Server Logon Failure.
    Trying rule: 18108 - Failed attempt to perform a privileged operation.
**Phase 3: Completed filtering (rules).
       Rule id: '18105'
       Level: '4'
       Description: 'Windows audit failure event.'
**Alert to be generated.

So I've added this rule to my local_rules.xml file:

  <rule id="100004" level="0">
    <if_sid>18105</if_sid>
    <match>192.168.1.255</match>
    <description> Ignore firewall dropped packets for broadcast address</description>
  </rule>

However, after restarting the ossec-hids-server and re-run "ossec-logtest -v", I see that it tries my rule but somehow doesn't match -- what have I done wrong?

    Trying rule: 18105 - Windows audit failure event.
       *Rule 18105 matched.
       *Trying child rules.
    Trying rule: 18120 - Windows login attempt (ignored). Duplicated.
    Trying rule: 100004 -  Ignore firewall dropped packets for broadcast address
    Trying rule: 18153 - Multiple Windows audit failure events.
    Trying rule: 18106 - Windows Logon Failure.
    Trying rule: 18139 - Windows DC Logon Failure.
    Trying rule: 18180 - MS SQL Server Logon Failure.
    Trying rule: 18108 - Failed attempt to perform a privileged operation.
**Phase 3: Completed filtering (rules).
       Rule id: '18105'
       Level: '4'
       Description: 'Windows audit failure event.'
**Alert to be generated.

[Fredrik Hilmersson]

What happens if you change <match> using <srcip>192.168.1.255</srcip>?

[Ian Brown]

No effect.  I tried dstip too, but I don't think either of those tags contain data due to the decoder used?

<decoder name="windows">

  <type>windows</type>

  <prematch>^\d\d\d\d \w\w\w \d\d \d\d:\d\d:\d\d WinEvtLog: |^WinEvtLog: </prematch>

  <regex offset="after_prematch">^\.+: (\w+)\((\d+)\): (\.+): </regex>

  <regex>(\.+): \.+: (\S+): </regex>

  <order>status, id, extra_data, user, system_name</order>

  <fts>name, location, user, system_name</fts>

</decoder>

This means the only tags that contain data is status, id, extra_data, user, and system_name, right?

Is there a way to dump the data that my rule would have processed? Is the decoder stripping what I'm trying to search for?

[Ian Brown]

I believe I've figured it out -- I think the decoder isn't matching the full log string and is thus stripping the ip address information.  Also after looking at the regex in the decoder, I've discovered that it doesn't even match against the first three example strings provided:

Here's an example from the comments (After prematch):

Security: AUDIT_FAILURE(0x000002A9): Security: SYSTEM: NT AUTHORITY: The logon to account: xyz by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 from workstation: la failed. The error code was: 3221225572

yet, the regex is:

^\.+: (\w+)\((\d+)\): (\.+): 

The second (\d+) will only match against numbers, so (0x000002A9) will never match.  It should be ([0-9A-Fx]+)

Also, why is it escaping the period at the beginning and at the end?  shouldn't the regex be:

^.+: (\w+)\((\d+)\): (.+):

[Jesus Linares]

Hi Ian,

try this rule:

<group name="test,">

  <!--

  2017 Jul 02 22:38:47 WinEvtLog: Security: AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): no domain: leaf-1: The Windows Filtering Platform blocked a packet. Application Information: Process ID: 0 Application Name: - Network Information: Direction: %%14592 Source Address: 192.168.1.120 Source Port: 39740 Destination Address: 192.168.1.255 Destination Port: 32414 Protocol: 17 Filter Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer Run-Time ID: 13

  -->

  <rule id="100001" level="0">
    <if_sid>18105</if_sid>
    <match>192.168.1.120</match>
    <description>ignore 192.168.1.120.</description>
  </rule>

</group>

ossec-logtest:

2017 Jul 02 22:38:47 WinEvtLog: Security: AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): no domain: leaf-1: The Windows Filtering Platform blocked a packet. Application Information: Process ID: 0 Application Name: - Network Information: Direction: %%14592 Source Address: 192.168.1.120 Source Port: 39740 Destination Address: 192.168.1.255 Destination Port: 32414 Protocol: 17 Filter Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer Run-Time ID: 13

**Phase 1: Completed pre-decoding.
       full event: '2017 Jul 02 22:38:47 WinEvtLog: Security: AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): no domain: leaf-1: The Windows Filtering Platform blocked a packet. Application Information: Process ID: 0 Application Name: - Network Information: Direction: %%14592 Source Address: 192.168.1.120 Source Port: 39740 Destination Address: 192.168.1.255 Destination Port: 32414 Protocol: 17 Filter Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer Run-Time ID: 13'
       hostname: 'ip-10-0-0-10'
       program_name: 'WinEvtLog'
       log: 'Security: AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user): no domain: leaf-1: The Windows Filtering Platform blocked a packet. Application Information: Process ID: 0 Application Name: - Network Information: Direction: %%14592 Source Address: 192.168.1.120 Source Port: 39740 Destination Address: 192.168.1.255 Destination Port: 32414 Protocol: 17 Filter Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer Run-Time ID: 13'


**Phase 2: Completed decoding.
       decoder: 'windows'
       status: 'AUDIT_FAILURE'
       id: '5152'
       extra_data: 'Microsoft-Windows-Security-Auditing'
       dstuser: '(no user)'
       system_name: 'leaf-1'

**Phase 3: Completed filtering (rules).

       Rule id: '100001'
       Level: '0'
       Description: 'ignore 192.168.1.120.'

I hope it helps.

[dan (ddp)]

You stripped a lot of interesting bits from the ossec-logtest.

This works for me:
<rule id="410001" level="0">

<if_sid>18105</if_sid>
<match>192.168.1.255</match>

<description>Ignore broadcast</description>
</rule>

2017/07/05 21:40:26 ossec-testrule: INFO: Reading the lists file:
'rules/lists/ossec.block'
2017/07/05 21:40:26 ossec-testrule: INFO: Started (pid: 76232).
ossec-testrule: Type one log per line.



**Phase 1: Completed pre-decoding.
full event: '2017 Jul 02 22:38:47 WinEvtLog: Security:

AUDIT_FAILURE(5152): Microsoft-Windows-Security-Auditing: (no user):
no domain: leaf-1: The Windows Filtering Platform blocked a packet.
Application Information: Process ID: 0 Application Name: - Network
Information: Direction: %%14592 Source Address: 192.168.1.120 Source
Port: 39740 Destination Address: 192.168.1.255 Destination Port: 32414
Protocol: 17 Filter Information: Filter Run-Time ID: 93069 Layer Name:

%%14597 Layer Run-Time ID: 13'
hostname: 'ix'
program_name: 'WinEvtLog'
log: 'Security: AUDIT_FAILURE(5152):

Microsoft-Windows-Security-Auditing: (no user): no domain: leaf-1: The
Windows Filtering Platform blocked a packet. Application Information:
Process ID: 0 Application Name: - Network Information: Direction:
%%14592 Source Address: 192.168.1.120 Source Port: 39740 Destination
Address: 192.168.1.255 Destination Port: 32414 Protocol: 17 Filter
Information: Filter Run-Time ID: 93069 Layer Name: %%14597 Layer

Run-Time ID: 13'

**Phase 2: Completed decoding.
decoder: 'windows'
status: 'AUDIT_FAILURE'
id: '5152'
extra_data: 'Microsoft-Windows-Security-Auditing'
dstuser: '(no user)'
system_name: 'leaf-1'

srcip: '192.168.1.120'

**Phase 3: Completed filtering (rules).

Rule id: '410001'
Level: '0'
Description: 'Ignore broadcast'



>
> --
>
> ---
> 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+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[dan (ddp)]

On Mon, Jul 3, 2017 at 11:28 AM, Ian Brown <zest...@gmail.com> wrote:
> I believe I've figured it out -- I think the decoder isn't matching the full
> log string and is thus stripping the ip address information. Also after
> looking at the regex in the decoder, I've discovered that it doesn't even
> match against the first three example strings provided:
>
> Here's an example from the comments (After prematch):
> Security: AUDIT_FAILURE(0x000002A9): Security: SYSTEM: NT AUTHORITY: The
> logon to account: xyz by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 from
> workstation: la failed. The error code was: 3221225572
>
> yet, the regex is:
> ^\.+: (\w+)\((\d+)\): (\.+):
>
> The second (\d+) will only match against numbers, so (0x000002A9) will never
> match. It should be ([0-9A-Fx]+)

I don't think this does what you want it to. But dealing with the hex
might be an issue we'll have to look into.

>
> Also, why is it escaping the period at the beginning and at the end?
> shouldn't the regex be:
> ^.+: (\w+)\((\d+)\): (.+):
>

Not if you want to match any character, that should only match '.'.

[Ian Brown]

Dan, eventually my rule started working -- it was after I modified that
windows decoder by swapping the /S for a /. I thought that there might
have been a space in the AUDIT_FAILURE log string that was truncating
the pattern matching too soon.

However, after swapping the /. back to /S my rule continued to work so
I'll just assume I make some mistake somewhere and managed to somehow
accidentally fix it.

Thanks for your reply.

[Ian Brown]

Dan,

All my regex experience comes from Perl. It's clear this regex does
things a bit differently than how I expected. In Perl \.+ means only
match 1 or more periods.

Another difference I've discovered is that Perl's regex is greedy --
it'll match all it can. It looks like this regex will only match the
least number of characters it can. If I understand the difference
correctly, \.+ in this regex would be .+? in Perl.

In Perl, [0-9A-Fx]+ means match one or more from the following set: 0
through 9, A through F and x. I guess that's done differently here. :)

Thanks for helping me understand this better.

[dan (ddp)]

On Wed, Jul 5, 2017 at 10:41 PM, Ian Brown <zest...@gmail.com> wrote:
> Dan,
>
> All my regex experience comes from Perl. It's clear this regex does things
> a bit differently than how I expected. In Perl \.+ means only match 1 or
> more periods.
>
> Another difference I've discovered is that Perl's regex is greedy -- it'll
> match all it can. It looks like this regex will only match the least number
> of characters it can. If I understand the difference correctly, \.+ in this
> regex would be .+? in Perl.
>
> In Perl, [0-9A-Fx]+ means match one or more from the following set: 0
> through 9, A through F and x. I guess that's done differently here. :)
>
> Thanks for helping me understand this better.
>

Our regex is weird.

[Jesus Linares]

Hi Ian,

Here you have the syntax of the OSSEC regexs: https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html

 Another difference I've discovered is that Perl's regex is greedy -- 
it'll match all it can. It looks like this regex will only match the 
least number of characters it can

I think OSSEC regexs are greedy too, at least sometimes.

Our regex is weird. 

Totally agree.

Regards.