Re: [ossec-list] Re: Log Retention with Ossec
On Mon, Apr 30, 2018, 7:31 PM wrote: > Hi Dan, Florian > > This entry mentions OSSEC has been configured to keep logs as long as 13 > months. May I ask how to achieve that? I don't know the configuration file > I need to edit to let OSSEC know it must not rotate logs until the 13th > month. > > Best regards, Sebatian. > > Ossec doesn't delete logs. > > On Thursday, May 31, 2012 at 5:15:57 AM UTC-5, sculptu...@yahoo.co.uk > wrote: >> >> Hi all >> >> Currently considering an Ossec deployment, could I please check my >> understanding of the following; >> >> Ossec alerts - can be logged to syslog, file, database and sent as emails. >> >> Original log lines received from agents - can be logged to archive.log >> file with the "logall" directive for retention (doesn't cause these to be >> added to a configured db and they don't appear to be sent to syslog either >> should this be enabled, presuming these aren't options?). >> >> And a slightly off topic question if I may. >> >> I'd be interested in hearing what others are doing with regards log >> retention / enabling rich searching of the archive log, having taken a >> quick look at elsa as an example this appears to import everything as >> ossec-archive which doesn't appear ideal for utilising the search functions. >> >> It would be plausible in our case to actually junk a good portion of >> what's in the archive (ossec keepalives, log lines considered irrelevant >> for retention) but I'm not sure exactly where to begin (regex not being a >> strong point) and am wondering what others have done who have used the >> archive as a basis for log retention. >> >> Many thanks in advance >> >> >> -- > > --- > 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. > 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: Log Retention with Ossec
Hi Dan, Florian This entry mentions OSSEC has been configured to keep logs as long as 13 months. May I ask how to achieve that? I don't know the configuration file I need to edit to let OSSEC know it must not rotate logs until the 13th month. Best regards, Sebatian. On Thursday, May 31, 2012 at 5:15:57 AM UTC-5, sculptu...@yahoo.co.uk wrote: > > Hi all > > Currently considering an Ossec deployment, could I please check my > understanding of the following; > > Ossec alerts - can be logged to syslog, file, database and sent as emails. > > Original log lines received from agents - can be logged to archive.log > file with the "logall" directive for retention (doesn't cause these to be > added to a configured db and they don't appear to be sent to syslog either > should this be enabled, presuming these aren't options?). > > And a slightly off topic question if I may. > > I'd be interested in hearing what others are doing with regards log > retention / enabling rich searching of the archive log, having taken a > quick look at elsa as an example this appears to import everything as > ossec-archive which doesn't appear ideal for utilising the search functions. > > It would be plausible in our case to actually junk a good portion of > what's in the archive (ossec keepalives, log lines considered irrelevant > for retention) but I'm not sure exactly where to begin (regex not being a > strong point) and am wondering what others have done who have used the > archive as a basis for log retention. > > Many thanks in advance > > > -- --- 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. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: custom decoder kernelmon syslog-ng
Here is what I have created so far log test works waiting for real world ( i have a disk on Buffalo NAS that is dying ). Thought it may help others. Put I will post real world results. *Decoders:* errormon ^Error situation detected! \w+ \d+ \d+:\d+\d+:\d+ \w+ \w+ \d+\p\p \w+ \w+ \w+\p (\w+) \w+ \w+ \w+ \w+ status iptables true ^cmd= ^cmd=\S+\s(\S+)\s\w+\s\d+\s(\d) extra_data,status *Rules:* TS5400R33A nas-101-sector Buffalo NAS - Bad Sector Count! 810001 Buffalo NAS - Repeated Bad Sector Count! TS5400R33A nas-101-broken Buffalo NAS - Disk Failure! 810003 Buffalo NAS - Repeated Disk Failure! Logtest Out: Jun 21 03:27:36 TS5400R33A errormon[2761]: Error situation detected! HD4 Broken E30Replace the DISK **Phase 1: Completed pre-decoding. full event: 'Jun 21 03:27:36 TS5400R33A errormon[2761]: Error situation detected! HD4 Broken E30Replace the DISK' hostname: 'TS5400R33A' program_name: 'errormon' log: 'Error situation detected! HD4 Broken E30Replace the DISK' **Phase 2: Completed decoding. decoder: 'nas-101-broken' **Phase 3: Completed filtering (rules). Rule id: '810004' Level: '16' Description: 'Buffalo NAS - Repeated Disk Failure!' **Alert to be generated. Jun 13 09:40:56 TS5400R33A kernelmon: cmd=ioerr sdc READ 33661712 1 **Phase 1: Completed pre-decoding. full event: 'Jun 13 09:40:56 TS5400R33A kernelmon: cmd=ioerr sdc READ 33661712 1' hostname: 'TS5400R33A' program_name: 'kernelmon' log: 'cmd=ioerr sdc READ 33661712 1' **Phase 2: Completed decoding. decoder: 'iptables' extra_data: 'sdc' status: '1' **Phase 3: Completed filtering (rules). Rule id: '810002' Level: '16' Description: 'Buffalo NAS - Repeated Bad Sector Count!' **Alert to be generated. On Wednesday, April 25, 2018 at 11:34:07 AM UTC-5, Jacob Mcgrath wrote: > > This is the log sent to ossec: > > Apr 24 03:21:41 TS5400R33A kernelmon: cmd=ioerr sdc READ 50030496 1 > > If I run threw logtest i get iptables as the final decoder: > > **Phase 1: Completed pre-decoding. >full event: 'Apr 24 03:21:41 TS5400R33A kernelmon: cmd=ioerr sdc > READ 50030496 1' >hostname: 'TS5400R33A' >program_name: 'kernelmon' >log: 'cmd=ioerr sdc READ 50030496 1' > > **Phase 2: Completed decoding. >decoder: 'iptables' > > > I tried to make other custom decoders using iptables as the parent and or > totally new decoders for this log but it always decodes the same. > -- --- 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. For more options, visit https://groups.google.com/d/optout.
[ossec-list] Re: custom decoder kernelmon syslog-ng
Here is what I have created so far log test works waiting for real world ( i have a disk on Buffalo NAS that is dying ). Thought it may help others. Put I will post real world results. *Decoders:* errormon ^Error situation detected! \w+ \d+ \d+:\d+\d+:\d+ \w+ \w+ \d+\p\p \w+ \w+ \w+\p (\w+) \w+ \w+ \w+ \w+ status iptables true ^cmd= ^cmd=\S+\s(\S+)\s\w+\s\d+\s(\d) extra_data,status *Rules:* TS5400R33A nas-101-sector Buffalo NAS - Bad Sector Count! 810001 Buffalo NAS - Repeated Bad Sector Count! TS5400R33A nas-101-broken Buffalo NAS - Disk Failure! 810003 Buffalo NAS - Repeated Disk Failure! Logtest Out: Jun 13 09:40:56 TS5400R33A kernelmon: cmd=ioerr sdc READ 33661712 1 **Phase 1: Completed pre-decoding. full event: 'Jun 13 09:40:56 TS5400R33A kernelmon: cmd=ioerr sdc READ 33661712 1' hostname: 'TS5400R33A' program_name: 'kernelmon' log: 'cmd=ioerr sdc READ 33661712 1' **Phase 2: Completed decoding. decoder: 'iptables' extra_data: 'sdc' status: '1' **Phase 3: Completed filtering (rules). Rule id: '810001' Level: '10' Description: 'Buffalo NAS - Bad Sector Count!' **Alert to be generated. Jun 13 09:40:56 TS5400R33A kernelmon: cmd=ioerr sdc READ 33661712 1 **Phase 1: Completed pre-decoding. full event: 'Jun 13 09:40:56 TS5400R33A kernelmon: cmd=ioerr sdc READ 33661712 1' hostname: 'TS5400R33A' program_name: 'kernelmon' log: 'cmd=ioerr sdc READ 33661712 1' **Phase 2: Completed decoding. decoder: 'iptables' extra_data: 'sdc' status: '1' **Phase 3: Completed filtering (rules). Rule id: '810002' Level: '16' Description: 'Buffalo NAS - Repeated Bad Sector Count!' **Alert to be generated. On Wednesday, April 25, 2018 at 11:34:07 AM UTC-5, Jacob Mcgrath wrote: > > This is the log sent to ossec: > > Apr 24 03:21:41 TS5400R33A kernelmon: cmd=ioerr sdc READ 50030496 1 > > If I run threw logtest i get iptables as the final decoder: > > **Phase 1: Completed pre-decoding. >full event: 'Apr 24 03:21:41 TS5400R33A kernelmon: cmd=ioerr sdc > READ 50030496 1' >hostname: 'TS5400R33A' >program_name: 'kernelmon' >log: 'cmd=ioerr sdc READ 50030496 1' > > **Phase 2: Completed decoding. >decoder: 'iptables' > > > I tried to make other custom decoders using iptables as the parent and or > totally new decoders for this log but it always decodes the same. > -- --- 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. For more options, visit https://groups.google.com/d/optout.
