Re: [ossec-list] Re: I'm unclear why my rule is not matching...

[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. 


On Friday, July 7, 2017 at 2:49:39 AM UTC+2, dan (ddpbsd) wrote:
>
> On Wed, Jul 5, 2017 at 10:41 PM, Ian Brown  > 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. 
>
> > 
> > On 7/5/2017 6:45 PM, dan (ddp) wrote: 
> >> 
> >> On Mon, Jul 3, 2017 at 11:28 AM, Ian Brown  > 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(0x02A9): 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 (0x02A9) 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 '.'. 
> >> 
> >>> -- 
> >>> 
> >>> --- 
> >>> 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. 
> > 
> > 
> > 
> > -- 
> > 
> > --- 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. 
>

-- 

--- 
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.

Re: [ossec-list] Re: I'm unclear why my rule is not matching...

[dan (ddp)]

On Wed, Jul 5, 2017 at 10:41 PM, Ian Brown  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.

>
> On 7/5/2017 6:45 PM, dan (ddp) wrote:
>>
>> On Mon, Jul 3, 2017 at 11:28 AM, Ian Brown  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(0x02A9): 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 (0x02A9) 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 '.'.
>>
>>> --
>>>
>>> ---
>>> 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.
>
>
>
> --
>
> --- 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.

-- 

--- 
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.

Re: [ossec-list] Re: I'm unclear why my rule is not matching...

[dan (ddp)]

On Mon, Jul 3, 2017 at 11:28 AM, Ian Brown  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(0x02A9): 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 (0x02A9) 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 '.'.

> --
>
> ---
> 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.

-- 

--- 
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.

[ossec-list] Re: I'm unclear why my rule is not matching...

[Jesus Linares]

Hi Ian,

try this rule:


  

  
18105
192.168.1.120
ignore 192.168.1.120.
  



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: '11'
   Level: '0'
   Description: 'ignore 192.168.1.120.'


I hope it helps.


On Monday, July 3, 2017 at 5:28:04 PM UTC+2, Ian Brown 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(0x02A9): 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 (0x02A9) 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+)\): (.+):
>

-- 

--- 
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.

[ossec-list] Re: I'm unclear why my rule is not matching...

[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(0x02A9): 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 (0x02A9) 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+)\): (.+):

-- 

--- 
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.

[ossec-list] Re: I'm unclear why my rule is not matching...

[Ian Brown]

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


  windows
  ^\d\d\d\d \w\w\w \d\d \d\d:\d\d:\d\d WinEvtLog: |^WinEvtLog: 

  ^\.+: (\w+)\((\d+)\): (\.+): 
  (\.+): \.+: (\S+): 
  status, id, extra_data, user, system_name
  name, location, user, system_name


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?

On Monday, July 3, 2017 at 5:43:39 AM UTC-7, Fredrik Hilmersson wrote:
>
> What happens if you change  using 192.168.1.255?
>
>>
>>

-- 

--- 
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.

[ossec-list] Re: I'm unclear why my rule is not matching...

[Fredrik Hilmersson]

What happens if you change  using 192.168.1.255?

Den måndag 3 juli 2017 kl. 14:29:48 UTC+2 skrev 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:
>
>   
>> 18105
>> 192.168.1.255
>>  Ignore firewall dropped packets for broadcast 
>> address
>>   
>
>
> 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: 14 -  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.
>
>
>

-- 

--- 
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.