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.