Cool. Thanks a lot.

On Friday, November 7, 2014 5:00:31 AM UTC-8, dan (ddpbsd) wrote:
>
> On Thu, Nov 6, 2014 at 7:29 PM,  <[email protected] <javascript:>> 
> wrote: 
> > Dan, could you please also tell me how to set the interval time for 
> OSSEC 
> > executing the command? When target value is beyond the threshold setting 
> I 
> > hope the alert could be triggered ASAP therefore I may need to reduce 
> the 
> > default interval time in my system. Thanks a lot. 
> > 
>
> <frequency>SECONDS</frequency> 
>
>
> https://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.localfile.html?highlight=frequency#element-frequency
>  
>
> > On Thursday, November 6, 2014 11:33:57 AM UTC-8, dan (ddpbsd) wrote: 
> >> 
> >> On Thu, Nov 6, 2014 at 1:16 PM,  <[email protected]> wrote: 
> >> > Hi all, 
> >> > 
> >> > Ossec online documents offers three examples for the Process 
> Monitoring 
> >> > feature. 
> >> > 
> >> > So far I did see output of a command change example working on my 
> >> > environment (rule_id=533). 
> >> > 
> >> > I am really interested in load average (uptime) Example and want to 
> get 
> >> > it 
> >> > working and understand the underlying logic. But I didn't find out 
> any 
> >> > successful story online but only the failure situation similar as my 
> >> > case 
> >> > (http://osdir.com/ml/ossec-list/2009-12/msg00153.html). 
> >> > 
> >> > I set up my system as follows by following the online instruction: 
> >> > 
> >> > 1, make sure to include the following setting in the file 
> >> > /var/ossec/etc/ossec.conf which means we want to monitor the load 
> >> > average 
> >> > 
> >> >   <localfile> 
> >> >     <log_format>command</log_format> 
> >> >     <command>uptime</command> 
> >> >   </localfile> 
> >> > 
> >> 
> >> Is OSSEC running the command? 
> >> I usually find it easier to use aliases. 
> >> 
> >> > 2, add the following setting in the rule file 
> >> > /var/ossec/rules/local_rules.xml 
> >> > 
> >> > <group name="ossec,"> 
> >> >   <rule id="100101" level="7" ignore="7200"> 
> >> >     <if_sid>530</if_sid> 
> >> >     <match>ossec: output: 'uptime': </match> 
> >> >     <regex>load averages: 1.</regex> 
> >> >     <options>alert_by_email</options> 
> >> >     <description>Load average reached 1..</description> 
> >> >   </rule> 
> >> > </group> 
> >> > 
> >> 
> >> I'd probably break this into 2 rules myself. 
> >> Rule 1: 
> >> 
> >> level="1" 
> >> <match>uptime_command</match> <!-- or whatever the alias would end up 
> >> looking like--> 
> >> 
> >> Rule 2: 
> >> <match>load average: 1.</match> <!-- My system has "load average" not 
> >> "load averages" --> 
> >> 
> >> > Comments: 
> >> > #1: For debug convenience, I decrease the threshold value from 2 to 
> 1. 
> >> > #2: I guess we also need a group name for the rule so that I pick up 
> >> > "ossec" 
> >> > here. 
> >> 
> >> Nope, if you include the rule inside of the <group></group> already in 
> >> local_rules, you don't need one. 
> >> 
> >> > 
> >> > My understanding is that Ossec would execute uptime every several 
> >> > minutes by 
> >> > default and send out an alert once the load is high than the setting 
> (1 
> >> > in 
> >> > my test case) but I didn't see any alert. 
> >> > 
> >> 
> >> The load average would have to be "1." Anything over 1.9 or under 1.0 
> >> would not cause an alert. 
> >> 
> >> > What is the underlying logic for this rule? The document says "alert 
> >> > when it 
> >> > is higher than 2 (for <regex>load averages: 2.</regex> case)" 
> therefore 
> >> > I 
> >> 
> >> That would alert when the load average is 2.0-2.9. 3.0+ would not 
> >> cause an alert. 
> >> 
> >> > guess there is a hidden comparison logic here. Is it a integer 
> >> > comparison or 
> >> > float comparison? Can we change value 2 to 0.5? Does the ending point 
> >> 
> >> It's a string comparison. The string your rule is looking for is 'load 
> >> averages: 1.' If that exact string is not found, the alert will not be 
> >> triggered. 
> >> 
> >> > character matter in the expression (<regex>load averages: 
> 1.</regex>)? 
> >> > 
> >> 
> >> Yes, it matters. If there is no "." in that place in the log message, 
> >> the alert will not be triggered. 
> >> 
> >> > Could you please share your experience if you have this feature 
> working 
> >> > in 
> >> > your system? Thanks a lot. 
> >> > 
> >> > 
> >> > Best Regards, 
> >> > Yongzhi 
> >> > 
> >> > -- 
> >> > 
> >> > --- 
> >> > 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 [email protected]. 
> >> > For more options, visit https://groups.google.com/d/optout. 
> > 
> > -- 
> > 
> > --- 
> > 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 [email protected] <javascript:>. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 

--- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to