IPv6 triggers Rule 1002

[joshstoik1]

<rule id="1002" level="2">
    <match>$BAD_WORDS</match>
    <options>alert_by_email</options>
    <description>Unknown problem somewhere in the system.</description>
</rule>

Because <match> matches the whole entry, IPv6 addresses that happen to contain "bad" (e.g. 2222:2222:2222:2222:2222:2222:2222:9bad) result in a false positive alert.

[ddpbsd]

I'm not sure we can do anything about that.

[lostinthetubez]

Do you have a log sample that generates this alert? The current $BAD_WORDS variable has a space after the word "bad", so I'm not sure why it would match an IPv6 address, unless the word occurred at the very end of the address.

We could add another space to the beginning of "bad ", but I'm not sure what the ramifications would be off the top of my head.

Either way, there are tons of logs where rule 1002 generates false positives. This is one of those rules you need to tune and suppress as appropriate to your environment.

[joshstoik1]

The following is an example from an Nginx access log, a few bits altered for anonymity:

2222:2222:2222:2222:2222:2222:2222:9bad - - [10/Dec/2016:10:06:36 -0800] "GET /drink/apple-314/?utm_source=3p_hunterpr&utm_term=d_apple314&utm_campaign=JW&utm_medium=referral HTTP/2.0" 200 15273 "http://m.facebook.com/" "Mozilla/5.0 (Linux; Android 6.0; LG-H811 Build/MRA58K; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/52.0.2743.98 Mobile Safari/537.36 [FB_IAB/FB4A;FBAV;]"

I've implemented the following override rule for my own use, but it is pretty clumsy given the limited regex support:

<rule id="100041" level="0">
	<if_sid>1002</if_sid>
	<regex>:\wbad|:bad\w|\wbad:|bad\w:</regex>
	<description>Ignore :bad: IPv6</description>
</rule>

[lostinthetubez]

Yep, that's the one fringe case where this would trigger 1002. I would change $BAD_WORDS to use " bad " instead of "bad ". How many times is the word bad going to be surrounded by punctuation or exist at the beginning or end of a string? Even in those cases, what are you really losing out on? Probably not much.

I'm certainly not an expert, but I'm of the opinion that modifying $BAD_WORDS is the better approach, because allowing OSSEC to match against rule 1002, then setting the alert to level 0 is going to prevent you from further matching against other rules. If a web attack were present in the log that contains this theoretical IPv6 address, you would want it to match against web_attack rules and alert on it.