In testing snort 2.9 inline operation logs against OSSEC (3.6.0), I have 
found something weird.


This “alert” event gets caught by the decoder:


10/17-21:23:32.374062 [**] [1:10000002:0] /etc/passwd test detected [**] 
[Priority: 0] {TCP} 10.1.4.2:59240 -> 10.1.7.2:80


**Phase 1: Completed pre-decoding.

full event: '10/17-21:23:32.374062 [**] [1:10000002:0] /etc/passwd test 
detected [**] [Priority: 0] {TCP} 10.1.4.2:59240 -> 10.1.7.2:80'

hostname: 'ossec'

program_name: '(null)'

log: '[**] [1:10000002:0] /etc/passwd test detected [**] [Priority: 0] 
{TCP} 10.1.4.2:59240 -> 10.1.7.2:80'


**Phase 2: Completed decoding.

decoder: 'snort'

id: '1:10000002:0'

srcip: '10.1.4.2'

dstip: '10.1.7.2'


**Phase 3: Completed filtering (rules).

Rule id: '20101'

Level: '6'

Description: 'IDS event.'

**Alert to be generated.



This “drop” event, however, does not.


10/17-21:24:32.944406 [Drop] [**] [1:10000002:0] cmd.exe test detected [**] 
[Priority: 0] {TCP} 10.1.4.2:59244 -> 10.1.7.2:80



**Phase 1: Completed pre-decoding.

full event: '10/17-21:24:32.944406 [Drop] [**] [1:10000002:0] cmd.exe test 
detected [**] [Priority: 0] {TCP} 10.1.4.2:59244 -> 10.1.7.2:80'

hostname: 'ossec'

program_name: '(null)'

log: '[Drop] [**] [1:10000002:0] cmd.exe test detected [**] [Priority: 0] 
{TCP} 10.1.4.2:59244 -> 10.1.7.2:80'


**Phase 2: Completed decoding.

No decoder matched.


For your reference here are the Snort decoder lines from 
/var/ossec/etc/decoder.xml:


<decoder name="snort">

<program_name_pcre2>^snort</program_name_pcre2>

</decoder>


<decoder name="snort">

<type>ids</type>

<prematch_pcre2>^\[\*\*\] \[\d+:\d+:\d+\] </prematch_pcre2>

</decoder>


<decoder name="snort2">

<parent>snort</parent>

<type>ids</type>

<prematch_pcre2>^\[\*\*\] \[|^\[Drop\] \[\*\*\] \[|^\[</prematch_pcre2>

<pcre2 offset="after_prematch">(\d+:\d+:\d+)\] .+ (\S+?):?\d* -> 
([^:]+)</pcre2>

<order>id,srcip,dstip</order>

<fts>name,id,srcip,dstip</fts>

</decoder>


So what’s happening is that the alert event that starts with the timestamp 
then [**] [#:########:#] matches the second “snort” decoder and then gets 
further tested against the “snort2” decoder.


However, the drop event that starts with the timestamp then [Drop] [**] 
[#:#######:#] only matches the “snort2” decoder. This decoder catches 
strings that start with [**] OR [Drop] [**] OR [ and then sorts out the ID 
and IP info after the prematch. The problem is that since “snort2” declares 
“snort” as it’s parent, and the “snort” decoder only catches events which 
starts with [**] [#:########:#] only alert events make it to “snort2” for 
further decoding.


I have 3 proposed solutions:


1) Remove the “snort” parent requirement from the “snort2” decoder. I don’t 
see any value added by making it contingent on a prematch_pcre2 that would 
ALSO be caught by the child decoder’s prematch_pcre2 but I may be missing 
something. If this is OK, this could also allow for the complete removal of 
the second “snort” decoder since both would catch log lines starting with 
[**] [#:#######:#].


2) Change the second “snort” decoder’s prematch_pcre2 to: ^\[\*\*\] 
\[\d+:\d+:\d+\]|^\[Drop\] \[\*\*\] \[\d+:\d+:\d+\] so it will match both 
alert and drop events and allow access to the “snort2” decoder.


3) Add a third “snort” decoder with a prematch_pcre2 of ^\[Drop\] \[\*\*\] 
\[\d+:\d+:\d+\]


Does anyone see any superiority between these approaches? Also, how does 
one propose a change to the built-in decoder.xml?


Thanks,


Scott

-- 

--- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ossec-list/44af6fbc-8aa4-481f-9d5f-6b0520b9eab5n%40googlegroups.com.

Reply via email to