Hi Scott,
On Sat, Oct 17, 2020 at 6:47 PM saw...@gmail.com <sawo...@gmail.com> wrote:
>
> 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?
>
Which snort output are you using? It's been a long time since I've looked at it.
I think I like #1 the best, but I haven't had a chance to look into it
very much. You could create a pull request or an issue on github.
I'll try to install snort and get a better idea of what it all looks like again.
>
> 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.
--
---
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/CAMyQvMoNoQSzD%2Bciukg7M1EE7%3D3oGZToTsyC_s5CgoARFEQVrQ%40mail.gmail.com.
