Test

Regards
Vipin Hooda
Mobile: 9582596577
Sent from my iPhone

> On 04-Jun-2016, at 2:16 PM, [email protected] wrote:
> 
> 
> [email protected]   Google Groups              
> Topic digest 
> View all topics
> Ossec - ping servers with alert on failure - 6 Updates
> ISS 7 + 404/200 error decoders/rules.. - 1 Update
> OSSEC logfile file missing alert - 2 Updates
> New File Alert works "sometimes". Can't seem to get Realtime working. - 2 
> Updates
> Quickest way to test an updated local_rules.xml - 1 Update
> Debugging a rule that fires when tested with ossec-logtest but never fires in 
> production - 1 Update
> Ossec - ping servers with alert on failure           
> Jacob Mcgrath <[email protected]>: Jun 03 07:20AM -0700 
> 
> I got a script at timed intervals pinging out a server list and only 
> writing failures to a log like so: ( this is a test run using unknown 
> machine name )
>  
> PINGSERV PING FAILURE 06/03/2016 8:40:48.35 fail1
> 
>  
> Now I have set up decoders like so:
>  
>  
> <decoder name="pingserv">
> <prematch>^PINGSERV PING </prematch>
> </decoder>
>  
> <decoder name="pingserv-fail">
> <parent>pingserv</parent>
> <regex offset="after_parent">(\w+) (\d\d/\d\d/\d\d\d\d 
> \d:\d\d:\d\d.\d\d) (\w+)</regex>
> <order>action,extra_data,dstip</order>
> </decoder>
>  
>  
> The output is as such ( more and less what I want )
>  
>  
> PINGSERV PING FAILURE 06/03/2016 8:40:48.35 fail1
>  
>  
> **Phase 1: Completed pre-decoding.
> full event: 'PINGSERV PING FAILURE 06/03/2016 8:40:48.35 fail1 '
> hostname: 'alamo'
> program_name: '(null)'
> log: 'PINGSERV PING FAILURE 06/03/2016 8:40:48.35 fail1 '
>  
> **Phase 2: Completed decoding.
> decoder: 'pingserv'
> action: 'FAILURE'
> extra_data: '06/03/2016 8:40:48.35'
> dstip: 'fail1'
>  
> **Phase 3: Completed filtering (rules).
> Rule id: '1002'
> Level: '2'
> Description: 'Unknown problem somewhere in the system.'
> **Alert to be generated.
>  
>  
> The issue is that I am not able to trigger the rule bellow:
>  
>  
> <group name="ping-servers">
> <rule id="100010" level="0">
> <decoded_as>pingserv</decoded_as>
> <description>Grouping For Server Ping Group</description>
> </rule>
> </group>
>  
>  
>  
>  
> On Thursday, June 2, 2016 at 6:48:13 AM UTC-5, Jacob Mcgrath wrote:
> "dan (ddp)" <[email protected]>: Jun 03 10:27AM -0400 
> 
> On Fri, Jun 3, 2016 at 10:20 AM, Jacob Mcgrath
> > <description>Grouping For Server Ping Group</description>
> > </rule>
> > </group>
>  
> Either if_sid 1002, or create a rule with a level.
>  
> <rule id="110011" level="1">
> <if_sid>110010</if_sid>
> <action>FAILURE</action>
> <description> FAILURE</description>
> </rule>
>  
>  
> ossec-testrule: Type one log per line.
>  
> PINGSERV PING FAILURE 06/03/2016 8:40:48.35 fail1
>  
>  
> **Phase 1: Completed pre-decoding.
> full event: 'PINGSERV PING FAILURE 06/03/2016 8:40:48.35 fail1'
> hostname: 'ipyr'
> program_name: '(null)'
> log: 'PINGSERV PING FAILURE 06/03/2016 8:40:48.35 fail1'
>  
> **Phase 2: Completed decoding.
> decoder: 'pingserv'
> action: 'FAILURE'
> extra_data: '06/03/2016 8:40:48.35'
> dstip: 'fail1'
>  
> **Phase 3: Completed filtering (rules).
> Rule id: '110011'
> Level: '1'
> Description: ' FAILURE'
> **Alert to be generated.
>  
>  
> Jacob Mcgrath <[email protected]>: Jun 03 11:20AM -0700 
> 
> With this it still hits the 1002 rule
>  
>  
> <group name="ping-servers">
> <rule id="100010" level="0">
> <decoded_as>pingserv</decoded_as>
> <description>Grouping For Server Ping Group</description>
> </rule>
>  
> <rule id="100011" level="1">
> <if_sid>100010</if_sid>
> <action>FAILURE</action>
> <description> FAILURE</description>
> </rule>
> </group>
>  
>  
>  
> On Thursday, June 2, 2016 at 6:48:13 AM UTC-5, Jacob Mcgrath wrote:
> "dan (ddp)" <[email protected]>: Jun 03 02:28PM -0400 
> 
> On Fri, Jun 3, 2016 at 2:20 PM, Jacob Mcgrath
> > <description> FAILURE</description>
> > </rule>
> > </group>
>  
> if_sid 1002 then. I'm not sure what else to try, except for me to blow
> away my install and install whichever version you're using.
>  
> Jacob Mcgrath <[email protected]>: Jun 03 03:12PM -0700 
> 
> it works on my test system at home which is the same install as at the shop 
> so WTF sry for the crazy &(^*(^%
>  
> On Thursday, June 2, 2016 at 6:48:13 AM UTC-5, Jacob Mcgrath wrote:
> Jacob Mcgrath <[email protected]>: Jun 03 03:13PM -0700 
> 
> Ill post my final decoders & rules + script soon
>  
> On Thursday, June 2, 2016 at 6:48:13 AM UTC-5, Jacob Mcgrath wrote:
> Back to top
> ISS 7 + 404/200 error decoders/rules..           
> Jacob Mcgrath <[email protected]>: Jun 03 07:20AM -0700 
> 
> working with the decoders at the moment
>  
> On Thursday, June 2, 2016 at 6:37:02 AM UTC-5, Jacob Mcgrath wrote:
> Back to top
> OSSEC logfile file missing alert           
> Kumar Mg <[email protected]>: Jun 03 05:44AM -0700 
> 
> Hi Jesus,
>  
> We are getting all other messages being alerted via 1002. All WARN/ERROR/INFO 
> messages from the agent being alerted at level 2 - like the syscheck 
> files/directory not found. 
>  
> About 900 alerts were triggered in small time frame and 30 duplicates. Not 
> sure if we messed the decoding and rules set.
>  
> Thanks
> Kumar
> "dan (ddp)" <[email protected]>: Jun 03 09:50AM -0400 
> 
> > Hi Jesus,
>  
> > We are getting all other messages being alerted via 1002. All 
> > WARN/ERROR/INFO messages from the agent being alerted at level 2 - like the 
> > syscheck files/directory not found.
>  
> > About 900 alerts were triggered in small time frame and 30 duplicates. Not 
> > sure if we messed the decoding and rules set.
>  
> Create rules to ignore the messages you don't want to see.
>  
> Back to top
> New File Alert works "sometimes". Can't seem to get Realtime working.     
> Ferdia O'Brien <[email protected]>: Jun 03 04:45AM -0700 
> 
> Hi all,
>  
> My company has been using OSSEC to monitor logs quite happily for some 
> time. I am trying to get FIM up and running using OSSEC. The system is a 
> Redhat linux server running OSSEC as the server, which connects out to 
> quite a number of Agents installed on Windows.
>  
> We keep all our production material in a particular folder in a particular 
> drive. Let's call it E:/companyfolder/
>  
> I've added the following to the ossec.conf on the agent:
>  
> <directories check_all="yes" realtime="yes" 
> report_changes="yes">E:\companyfolder/websites/web</directories>
>  
> And added the following to local_rules.xml on the server:
>  
> <rule id="554" level="7" overwrite="yes">
> <category>ossec</category>
> <decoded_as>syscheck_new_entry</decoded_as>
> <description>File added to the system.</description>
> <group>syscheck,</group>
> </rule>
>  
> Having restarted both I then go and add an arbitrary file, like 
> "abcdefg.txt", and check the syslog. Repeating the test many times, 
> occasionally something like this pops up:
>  
> 2016-06-03 12:06:49 Local0.Warning 192.168.172.6 Jun 3 12:06:47 DB2 
> ossec: Alert Level: 7; Rule: 554 - File added to the system.; Location: 
> (app5) 192.168.172.105->syscheck; New file 
> 'E:\companyfolder/websites/web/abcdefgh.txt' added to the file system.
>  
> That would be one time in 20 tests however, and certainly not realtime.
>  
> What am I doing wrong?
> "dan (ddp)" <[email protected]>: Jun 03 09:49AM -0400 
> 
> > 'E:\companyfolder/websites/web/abcdefgh.txt' added to the file system.
>  
> > That would be one time in 20 tests however, and certainly not realtime.
>  
> > What am I doing wrong?
>  
> I don't think realtime supports alerting on new files being created. A
> full syscheck scan is required for that.
>  
> Back to top
> Quickest way to test an updated local_rules.xml           
> "dan (ddp)" <[email protected]>: Jun 03 09:45AM -0400 
> 
> I think one of the problems is that this use case was never considered.
> Going back to check old logs might be a good idea, but deleting the
> current alerts to do it seems bad.
> The "-a" flag for ossec-logtest might be useful. It should output the
> results in the same format ossec-analysisd does.
>  
> For example:
> # cat /var/log/messages | /var/ossec/bin/ossec-logtest -a 2>&1 | less
> 2016/06/03 09:44:32 ossec-testrule: INFO: Reading local decoder file.
> 2016/06/03 09:44:33 ossec-testrule: INFO: Started (pid: 57522).
> ** Alert 1464961473.1: - syslog,errors,
> 2016 Jun 03 09:44:33 ipyr->stdin
> Rule: 1005 (level 5) -> 'Syslogd restarted.'
> Jun 3 06:00:01 ipyr syslogd: restart
>  
> ** Alert 1464961473.2: mail - syslog,errors,
> 2016 Jun 03 09:44:33 ipyr->stdin
> Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.'
> Jun 3 06:08:54 ipyr ntpd[44444]: tls connect failed:
> 2607:f8b0:4004:80b::2004 (www.google.com): connect: No route to host
>  
> ** Alert 1464961473.3: mail - syslog,errors,
> 2016 Jun 03 09:44:33 ipyr->stdin
> Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.'
> Jun 3 06:23:55 ipyr ntpd[88218]: tls connect failed:
> 2607:f8b0:4004:80b::2004 (www.google.com): connect: No route to host
>  
> ** Alert 1464961473.4: mail - syslog,errors,
> 2016 Jun 03 09:44:33 ipyr->stdin
> Rule: 1002 (level 2) -> 'Unknown problem somewhere in the system.'
> Jun 3 06:38:56 ipyr ntpd[9184]: tls connect failed:
> 2607:f8b0:4004:80b::2004 (www.google.com): connect: No route to host
> (and on and on, I really need to filter that)
>  
>  
>  
> Back to top
> Debugging a rule that fires when tested with ossec-logtest but never fires in 
> production     
> "dan (ddp)" <[email protected]>: Jun 03 09:40AM -0400 
> 
> On Thu, Jun 2, 2016 at 10:42 PM, Kevin Branch
>  
> > It uses this custom decoder:
>  
> > <decoder name="chromoting">
> > <prematch>: chromoting: \.*chromoting</prematch>
>  
> I don't think regex is allowed in the prematch, the docs only mention sregex:
> https://ossec.github.io/docs/syntax/head_decoders.html?highlight=prematch#element-decoder.prematch
>  
> > can't get it to fire on the real log event, only in ossec-logtest.
>  
> > Please advise. I don't have any idea what kinds of rule writing errors can
> > be glossed over by ossec-logtest while causing rule failures in production.
>  
> Using the decoder and rule above, I get the following output from 
> ossec-logtest:
> **Phase 1: Completed pre-decoding.
> full event: '2016 Jun 02 17:58:36 WinEvtLog: Application:
> INFORMATION(1): chromoting: (no user): no domain: XYZ-O9020: Client
> connected: [email protected]/chromoting754CDB67.'
> hostname: 'ipyr'
> program_name: 'WinEvtLog'
> log: 'Application: INFORMATION(1): chromoting: (no user): no
> domain: XYZ-O9020: Client connected:
> [email protected]/chromoting754CDB67.'
>  
> **Phase 2: Completed decoding.
> No decoder matched.
>  
>  
> Changing the decoder to this:
> <decoder name="chromoting">
> <prematch>: chromoting: </prematch>
> <program_name>^WinEvtLog</program_name>
> </decoder>
>  
> it all starts to work.
>  
> I run this to get the log into syslog (I don't have a way to test it
> any other way that I can think of), so it may not be exactly correct:
> # echo 'Application: INFORMATION(1): chromoting: (no user): no domain:
> XYZ-O9020: Client connected: [email protected]/chromoting754CDB67.' |
> logger -t WinEvtLog
>  
> Here's the entry from alerts.log:
> ** Alert 1464961149.36091: - local,syslog,
> 2016 Jun 03 09:39:09 ipyr->/var/log/messages
> Rule: 100040 (level 3) -> 'Chrome Remote Desktop event - generic'
> Jun 3 09:39:07 ipyr WinEvtLog: Application: INFORMATION(1):
> chromoting: (no user): no domain: XYZ-O9020: Client connected:
> [email protected]/chromoting754CDB67.
>  
>  
> I believe this is with a fairly stock 2.8.3, but I'm not positive.
>  
>  
>  
> Back to top
> You received this digest because you're subscribed to updates for this group. 
> You can change your settings on the group membership page.
> To unsubscribe from this group and stop receiving emails from it send an 
> email to [email protected].

-- 

--- 
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