Anyone seen this behavior before and managed to resolve it ?
On Sep 16, 10:54 am, "Donald Tabone" <[EMAIL PROTECTED]> wrote: > Whilst we have suppressed the rule <1002> from sending email alerts, we also > noticed the following log entry is /var/log/ossec.log > > 2008/09/16 01:47:50 ossec-remoted: Invalid message from '10.31.19.33' > (strchr \n) > > Has this got anything to do with syslog-ng/ossec generating errors. > > 2008/9/16 Donald Tabone <[EMAIL PROTECTED]> > > > Dear all, > > > We're experiencing this randomly generated error after we fire-up > > ossec. It is tending to flood our email box with alerts. > > > Sep 15 10:03:32 captain syslog-ng[22504]: I/O error occurred while > > reading; fd='69', error='Connection reset by peer (104)' > > > From some research we've done, using lsof the file descriptor (fd) > > number corresponds at any one point in time to a number of other files > > with different permissions. Through logical deduction we think that it > > is possible that when ossec tries to check a file on a particular > > channel, the file would have already been closed and hence the > > connection is reset. Are off track with this line of thinking? > > > We also referenced > >http://www.ossec.net/wiki/index.php/Know_How:Email_Alerts_below_7 > > and tried to tweak a rule as explained in the wiki entry - but this > > did not work. The result atm is that ossec service is stopped. > > > The questions we ask: > > > How can we accurately pinpoint whether ossec is the problem or not? > > Is this a false positive? ie. can it be ignored or is there a > > significant problem in the system we actually need to resolve? > > > We are running ossec 1.6 on a debian4 machine. (same error occured > > with 1.5.1) > > > Can someone assist in finding a solution? > > TY
