Re: [ossec-list] Issue with the Snort decoders
Hi Dan,
The comparative tests are this rule in Snort 2.9.16:
alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"/etc/passwd test
detected"; flow:to_server,established; content:"/etc/passwd";
fast_pattern:only; http_uri; gid:1; sid:1001;)
Which produces this log:
10/20-20:43:32.334621 [**] [1:1001:0] /etc/passwd test detected [**]
[Priority: 0] {TCP} 10.1.4.2:59240 -> 10.1.7.2:80
Versus this rule:
drop tcp any any -> $HOME_NET $HTTP_PORTS (msg:"cmd.exe test detected";
flow:to_server,established; content:"cmd.exe"; fast_pattern:only; http_uri;
gid:1; sid:1002;)
Which produces this log:
10/20-20:43:39.741995 [Drop] [**] [1:1002:0] cmd.exe test detected [**]
[Priority: 0] {TCP} 10.1.4.2:59244 -> 10.1.7.2:80
Note: There are 2 spaces between the end of the timestamp and the first [
that will be consolidated to one in this email message, but both are needed
to test.
After thinking about it a bit, removing the child relationship between
snort and snort2 could cause all sorts of unanticipated problems for people
who rely on this parent / child logic (perhaps even doing workarounds for
this very issue), so I think adding a test to the the prematch_pcre2 logic
in the second “snort” decoder (the one that’s not program_name_pcre2 based)
will allow the Drop events to be picked up and funneled down the same path
as the Alert events are now, catching those erroneously missed log lines,
but not messing up anything else.
So, I’m proposing changing this decoder:
ids
^\[\*\*\] \[\d+:\d+:\d+\]
To this:
ids
^\[\*\*\] \[\d+:\d+:\d+\] |^\[Drop\] \[\*\*\]
\[\d+:\d+:\d+\]
Doing this now makes both drop and alert events appear under the same
decoder.
I’ll post an issue in github hoping someone picks it up to make the change
as I’m not familiar with the use of git itself and I presently don’t know
how to do a pull request. :)
Thanks,
Scott
P.S. Of course, all of this will change with Snort 3, but one thing at a
time, I suppose. :)
On Tuesday, October 20, 2020 at 2:24:03 PM UTC-4 dan (ddpbsd) wrote:
> Hi Scott,
>
> On Sat, Oct 17, 2020 at 6:47 PM saw...@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:1002: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:1002: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:1002: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:1002: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:1002: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:1002: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:1002: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:
> >
> >
> >
> >
> > ^snort
> >
> >
> >
> >
> >
> >
> > ids
> >
> > ^\[\*\*\] \[\d+:\d+:\d+\]
> >
> >
> >
> >
> >
> >
> > snort
> >
> > ids
> >
> > ^\[\*\*\] \[|^\[Drop\] \[\*\*\] \[|^\[
> >
> > (\d+:\d+:\d+)\] .+ (\S+?):?\d* ->
> ([^:]+)
> >
> > id,srcip,dstip
> >
> > name,id,srcip,dstip
> >
> >
> >
> >
> > 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
Re: [ossec-list] Issue with the Snort decoders
Hi Scott,
On Sat, Oct 17, 2020 at 6:47 PM saw...@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:1002: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:1002: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:1002: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:1002: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:1002: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:1002: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:1002: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:
>
>
>
>
> ^snort
>
>
>
>
>
>
> ids
>
> ^\[\*\*\] \[\d+:\d+:\d+\]
>
>
>
>
>
>
> snort
>
> ids
>
> ^\[\*\*\] \[|^\[Drop\] \[\*\*\] \[|^\[
>
> (\d+:\d+:\d+)\] .+ (\S+?):?\d* ->
> ([^:]+)
>
> id,srcip,dstip
>
> name,id,srcip,dstip
>
>
>
>
> 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.
[ossec-list] Issue with the Snort decoders
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:1002: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:1002: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:1002: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:1002: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:1002: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:1002: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:1002: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:
^snort
ids
^\[\*\*\] \[\d+:\d+:\d+\]
snort
ids
^\[\*\*\] \[|^\[Drop\] \[\*\*\] \[|^\[
(\d+:\d+:\d+)\] .+ (\S+?):?\d* ->
([^:]+)
id,srcip,dstip
name,id,srcip,dstip
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.
