Overriding a rule

[--[ UxBoD ]--]

Require some help please with overriding a standard rule. I have created the following in local_rules.xml:

<rule id="10044" level="10" frequency="24" timeframe="180">
<if_matched_sid>5720</if_matched_sid>
<same_source_ip />
<description>Multiple SSHD authentication failures (Local)</description>
<group>authentication_failures,</group>
</rule>

but finding that 5720 is still hitting and this one never does. I thought if the matched sid was referenced then a local rule would take precedence ?

--
Thanks, Phil

[dan (ddp)]

I think your rule says that if you see 25 "5720 events" within 180
seconds, fire rule 10044.

This wouldn't stop 5720 from firing.

What are you trying to do exactly?

[--[ UxBoD ]--]

Argh, okay. What we want is exactly that; to see that rule when it hits 25 events within 180 seconds but at the same time disable rule 5720 from firing :)

[--[ UxBoD ]--]

Dan,

I think I see what I did wrong and have changed it now to use two rules:

<rule id="10044" level="0">
<if_sid>5720</if_sid>

<same_source_ip />
<description>Multiple SSHD authentication failures (Local)</description>
<group>authentication_failures,</group>
</rule>

<rule id="10044" level="10" frequency="24" timeframe="180">
if_matched_sid>10044</if_matched_sid>

<same_source_ip />
<description>Multiple SSHD authentication failures (Local)</description>
<group>authentication_failures,</group>
</rule>

So the first rule stops it from reporting and if that has been hit the second correlates them again the frequency.

Is that the correct understanding ?

Thanks.

[dan (ddp)]

Hi Phil,

On Tue, Feb 8, 2011 at 7:23 AM, --[ UxBoD ]-- <ux...@splatnix.net> wrote:
> Dan,
>
> I think I see what I did wrong and have changed it now to use two rules:
>
> <rule id="10044" level="0">
>   <if_sid>5720</if_sid>
>    <same_source_ip />
>    <description>Multiple SSHD authentication failures (Local)</description>
>    <group>authentication_failures,</group>
> </rule>
>

You don't need the same_source_ip option. That only really matters
when you're looking for multiple events from the same IP.
You may need to raise the level to 1, I don't know. I've never tried
this with a level 0 event.

> <rule id="10044" level="10" frequency="24" timeframe="180">
>   if_matched_sid>10044</if_matched_sid>
>   <same_source_ip />
>   <description>Multiple SSHD authentication failures (Local)</description>
>   <group>authentication_failures,</group>
> </rule>
>

You duplicated the rule id, this one should be 10045. Other than that
it looks good.

> So the first rule stops it from reporting and if that has been hit the second correlates them again the frequency.
>
> Is that the correct understanding ?
>
> Thanks.
>

That looks correct to me.

[--[ UxBoD ]--]

Thanks Dan. Yeah I copied and pasted my thoughts hence the rule id dupe :) Are okay so for the first rule I remove same_source_ip and then use it in the correlated rule. That makes perfect sense.

[--[ UxBoD ]--]

Hmmm, this is still not working. Here are the rules I am testing with:

<rule id="10044" level="1">
<if_sid>5720</if_sid>
<description>Multiple SSHD authentication failures (Override Generic)</description>
<group>authentication_failures,</group>
</rule>

<rule id="10061" level="10" frequency="4" timeframe="180">

<if_matched_sid>10044</if_matched_sid>
<same_source_ip />

<description>Multiple SSHD authentication failures - GLPI #493</description>
<group>authentication_failures,</group>
</rule>

Rule 5720 has a frequency of 6 set against it so my understand is that if somebody got their password wrong that number of times then the rule should fire. It would then be suppressed by my local rule 10044 and finally matched by 10061. That would only trigger the level 10 active response alert if it was to receive 4 alerts matching rule 10044; which is 24 wrong password entries within 3 minutes.

I entered my password wrong 40 times within three minutes and rule 10061 next fired.

What am I missing ? Is it possible to test correlated rules with ossec-logtest ?

Thanks, Phil

[--[ UxBoD ]--]

<SNIP>

Okay have been doing quite a bit of testing with all this; and now I am checking the *correct* rule to start with am seeing some interesting results. Here are the two rules defined in local_rules.xml:

<rule id="10044" level="1">

<if_sid>5551</if_sid>
<description>Multiple SSHD authentication failures (Override Generic)</description>
<group>authentication_failures,</group>
</rule>

<rule id="10061" level="10" frequency="3" timeframe="180">

<if_matched_sid>10044</if_matched_sid>
<same_source_ip />

<description>Multiple SSHD authentication failures - GLPI #493</description>
<group>authentication_failures,</group>
</rule>

I start by testing with a source file that contains 31 lines of failed password attempts all happening within 3 minutes:

Feb 8 13:05:27 someuser sshd[28052]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:05:28 someuser sshd[29099]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:05:29 someuser sshd[29650]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:05:30 someuser sshd[30431]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:05:31 someuser sshd[31405]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:05:32 someuser sshd[31970]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:05:33 someuser sshd[32337]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:05:34 someuser sshd[32729]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:05:35 someuser sshd[716]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:06 someuser sshd[1138]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:10 someuser sshd[1140]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:11 someuser sshd[1564]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:12 someuser sshd[1945]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:13 someuser sshd[2367]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:14 someuser sshd[2769]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:15 someuser sshd[3151]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:16 someuser sshd[6348]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:17 someuser sshd[6724]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:18 someuser sshd[7138]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:19 someuser sshd[7378]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:20 someuser sshd[7532]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:21 someuser sshd[7895]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:22 someuser sshd[8223]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:23 someuser sshd[8287]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:24 someuser sshd[8662]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:25 someuser sshd[9077]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:26 someuser sshd[9457]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:27 someuser sshd[9851]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:28 someuser sshd[10232]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:29 someuser sshd[10617]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser
Feb 8 13:06:39 someuser sshd[10896]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=123.123.123.123 user=someuser

I run that through ossec-logtest and check for how many times rule 5503 hits:

grep -c "Rule 5503 matched" result
31

That is correct. Now rule 5551 is a standard rule as-well in the pam file and is written as:

<rule id="5551" level="10" frequency="6" timeframe="180">
<if_matched_sid>5503</if_matched_sid>
<same_source_ip />
<description>Multiple failed logins in a small period of time.</description>
<group>authentication_failures,</group>
</rule>

Yet if I check how many times that hits, and I would expect 5 times but I only see:

grep -c "Rule 5551 matched" result
3

I must be missing something really simple here ????

Thanks, Phil

[dan (ddp)]

Doesn't look like you're missing anything.

[--[ UxBoD ]--]

> > <SNIP> >

> > I run that through ossec-logtest and check for how many times rule
> > 5503 hits:
> >
> > grep -c "Rule 5503 matched" result
> > 31
> >
> > That is correct. Now rule 5551 is a standard rule as-well in the
> > pam file and is written as:
> >
> >  <rule id="5551" level="10" frequency="6" timeframe="180">
> >    <if_matched_sid>5503</if_matched_sid>
> >    <same_source_ip />
> >    <description>Multiple failed logins in a small period of
> >    time.</description>
> >    <group>authentication_failures,</group>
> >  </rule>
> >
> > Yet if I check how many times that hits, and I would expect 5 times
> > but I only see:
> >
> > grep -c "Rule 5551 matched" result
> > 3
> >
> > I must be missing something really simple here ????
> >
> > Thanks, Phil
> >
> >
> >
> >
>
> Doesn't look like you're missing anything.
>

Why so Dan ? If the frequency on rule 5551 is 6, and there are 31 events that trigger rule 5503, then I would have expected rule 5551 to have matched 6 times when in fact it only matched 3 times ?

[dan (ddp)]

On Tue, Feb 8, 2011 at 3:28 PM, --[ UxBoD ]-- <ux...@splatnix.net> wrote:
>> Doesn't look like you're missing anything.
>>
>
> Why so Dan ? If the frequency on rule 5551 is 6, and there are 31 events that trigger rule 5503, then I would have expected rule 5551 to have matched 6 times when in fact it only matched 3 times ?
>
>

Don't know. I agree, you should probably see 5 matches.

It looks like it's setup correctly. It looks like a good test. I'm not
in a position to replicate the test, or try it out in a lab
environment, at the moment. I can start digging through the source
code, but I don't have any ideas about what I'm looking for at the
moment.

So I basically, and very poorly, said that I didn't think you missed
anything (your assumptions were correct).

I'll try to look at this more tomorrow.

[--[ UxBoD ]--]

Hi Dan, No problem I understand where you were coming from :) Should note that this is running server/agent 2.5.1. If my configuration all appears okay then this could potentially be a major bug as active response could very well be triggering/or not as the case may be. If I can help with debugging then please let me know.

[Daniel Cid]

Hey,

The frequency of 6, actually means 8 events for it to alert. It makes
sense when you think of the rule in these terms:

if_matched_sid -> Alert me if the rule XYZ fired in the last ABC
seconds more than 6 times (not including the current event).

So in your case, the rule 5551 will check if in the last few minutes
the rule 5503 was set more than 6 times... So out of the 31
events, you would get 3 alerts from the rule 5551.

So why is that? Because you can write rules like this one:

<if_group>authentication_success</if_group>
<if_matched_group>authentication_failure</if_matched_group>

So the current event is not tied to the list when searching on the
if_matched_* signatures....

Hope it made some sense :)

Thanks,

--
Daniel B. Cid
dcid ( at ) ossec.net

[--[ UxBoD ]--]

----- Original Message -----
> Hey,
>
> The frequency of 6, actually means 8 events for it to alert. It makes
> sense when you think of the rule in these terms:
>
> if_matched_sid -> Alert me if the rule XYZ fired in the last ABC
> seconds more than 6 times (not including the current event).
>
> So in your case, the rule 5551 will check if in the last few minutes
> the rule 5503 was set more than 6 times... So out of the 31
> events, you would get 3 alerts from the rule 5551.
>
> So why is that? Because you can write rules like this one:
>
> <if_group>authentication_success</if_group>
> <if_matched_group>authentication_failure</if_matched_group>
>
> So the current event is not tied to the list when searching on the
> if_matched_* signatures....
>
> Hope it made some sense :)
>
> Thanks,
>

Hi Daniel,

Thank you very much for taking the time to respond it is appreciated.

Would it not be 7 events then ? If 6 had come through, and one discards the current, then you would be alerting on the seventh.

Long day so trying to get my head around the logic :)

Thanks,

P.

[Castle, Shane]

Seems to me that there is also an interpretation that, once the rule has fired and six more firings have occurred, there will be a frequency alert for each subsequent firing until the events per time interval is no longer operative. I realize that most "frequency warning systems" don't do this but instead reset to zero after each event/interval firing has occurred.

I have problems with the nomenclature for this: the word "frequency" really (in the real world) means some number of events per unit of time, but in the OSSEC rule definition it really means more like "count", and "timeframe" really means "interval". This confused me for a fair while at first until I saw some examples and read their explanations. I think that changing these to "count" and "interval", instead of "frequency" and "timeframe", would go a long way to improving understanding of this kind of rule.

--
Shane Castle
Data Security Mgr, Boulder County IT
CISSP GSEC GCIH

[dan (ddp)]

On Thu, Feb 10, 2011 at 3:50 PM, --[ UxBoD ]-- <ux...@splatnix.net> wrote:
>
> Hi Shane,
>
> I kind of agree with that and the change in the names would be good IMHO.
>

Patches will be looked at. Personally I don't think the names are bad,
but maybe it's my ignorance of the English language.

> Would be interested to hear from Daniel in which FAQ/Doc this is in as I must have missed it! I even have the book :)
>

See above. ;)

> Will need to go back and re-write a lot of our local rules based on this information as they will not be triggering as we expected; especially compound rules.
>
> Very useful discussion and very appreciative of all those who have posted.
>
> Thanks.
>
> P.
>

[Daniel Cid]

It is all on this doc:

https://bitbucket.org/dcid/ossec-hids/src/002e73da1e46/src/analysisd/eventinfo.c
:)

Joking aside, I don't think this is documented anywhere. Since english
is not my main language,
those keywords always made sense to me, but changing them right now
would create more issues
than by improving the docs and explaining well what they do.

Thanks,

On Thu, Feb 10, 2011 at 4:50 PM, --[ UxBoD ]-- <ux...@splatnix.net> wrote:

> Hi Shane,
>
> I kind of agree with that and the change in the names would be good IMHO.
>

> Would be interested to hear from Daniel in which FAQ/Doc this is in as I must have missed it! I even have the book :)
>

[dan (ddp)]

I've created an issue on my bitbucket to correct/enhance the documentation:
https://bitbucket.org/ddpbsd/ossec-rules/issue/6/frequency-really-means-frequency-1

I'll try to get to it tonight or tomorrow.

Anyone else can create documentation issues there as well...

[--[ UxBoD ]--]

Hi Shane,

[--[ UxBoD ]--]

:) Daniel, how feasible would it be for it to check '>=' instead of '>' as then it would probably make more sense; 6 alerts and then trigger on the seventh ?

[--[ UxBoD ]--]

> > >> SNIP

> :) Daniel, how feasible would it be for it to check '>=' instead of
> '>' as then it would probably make more sense; 6 alerts and then
> trigger on the seventh ?
>

Still no further forward with getting the rule to work :( Have taken a fresh look based on the information and help that has been given. I have 31 alerts in my test file that I am passing through ossec-logtest. Here are my local rules:

<rule id="10044" level="1">
<if_sid>5551</if_sid>
<description>Multiple SSHD authentication failures (Override Generic)</description>
<group>authentication_failures,</group>
</rule>

<rule id="10061" level="10" frequency="3" timeframe="180">
<if_matched_sid>10044</if_matched_sid>
<same_source_ip />
<description>Multiple SSHD authentication failures - GLPI #493</description>
<group>authentication_failures,</group>
</rule>

The first one triggers three times, as Daniel said it would, based on 31 / 8. So how would one get rule 10061 to fire ? if we wanted it to alert when 10044 had hit three times do we set the frequency to be one ? I am guessing that the granularity we are trying to achieve by using compound rules is not possible ?

[jeff jennings]

I got the forum site up and running for ossec and snort and I suppose
whatever else people want to talk about.

please take a look and let me know if you think it's missing any sections
etc.

It has forums, blogs, a links directory, an upload area for people to share
files/rules. You can link your own blog into the blogs section, login
through your twitter or facebook account and more.

I think it's pretty nice.

I also grabbed the rss feeds from the ossec and snort mailing lists and
publish those also along with security news from a few online sources.

It would be great if you could start using it to share your knowledge. I
don't mind spending the money on it if something good comes of it.

The mailing lists to me are tough to keep togethjer in my mind which if why
I love forums. It's also got a facebook interface in case people want to
post links to threads from the site on their facebook pages.

it's called Intrusion-alert

and of course I'm using ossec to monitor the system its running on.

www.intrusion-alert.com

Jeff

[--[ UxBoD ]--]

Any thoughts on this please ? if compound based rules are not possible due to how frequency works we need to know as we shall write as single ones instead. Sorry, we just really need to know what action to take in helping secure our servers.

Thanks,

Phil

[Daniel Cid]

Just set the frequency to one, so it will catch after 3 events....

thanks,

[--[ UxBoD ]--]

----- Original Message -----
> Just set the frequency to one, so it will catch after 3 events....
>
> thanks,
>

Sorry Daniel that does not work :(

[root@hids01 ~]# grep -c "10044 matched" output.txt
3
[root@hids01 ~]# grep -c "10061 matched" output.txt
0

10061 is the correlated rule and it never fires. I have set the parameters as:

<rule id="10061" level="10" frequency="1" timeframe="180">

<if_matched_sid>10044</if_matched_sid>
<same_source_ip />
<description>Multiple SSHD authentication failures - GLPI #493</description>
<group>authentication_failures,</group>
</rule>

Am I missing something still ?

--
Thanks, Phil

[dan (ddp)]

What happens if 10044 is triggered 4 times in 180 seconds?

I'm guessing frequency rules that watch frequency rules isn't going to
work well.
dan

[--[ UxBoD ]--]

Why ? I cannot see why compound rules should not work as ossec-logtest appears to parse them okay. Rule 10044 is there to suppress a default role:

<rule id="10044" level="1">
<if_sid>5551</if_sid>

<description>Multiple SSHD authentication failures (Override Generic)</description>
<group>authentication_failures,</group>
</rule>

that triggers three times so why would 10061 not trigger if the frequency has been set to 1 as Daniel (CID) mentioned ?

--
Thanks, Phil

[--[ UxBoD ]--]

Any thoughts on this as it does not appear to be working as described ?
--
Thanks, Phil

[dan (ddp)]

On Tue, Mar 22, 2011 at 7:20 AM, --[ UxBoD ]-- <ux...@splatnix.net> wrote:
>> Why ? I cannot see why compound rules should not work as
>> ossec-logtest appears to parse them okay. Rule 10044 is there to
>> suppress a default role:
>>
>>   <rule id="10044" level="1">
>>    <if_sid>5551</if_sid>
>>     <description>Multiple SSHD authentication failures (Override
>>     Generic)</description>
>>     <group>authentication_failures,</group>
>>   </rule>
>>
>> that triggers three times so why would 10061 not trigger if the
>> frequency has been set to 1 as Daniel (CID) mentioned ?
>>
>
> Any thoughts on this as it does not appear to be working as described ?
> --
> Thanks, Phil

What happens if 10044 is triggered 4 times?