Hi Donald, Which version of OSSEC are you using (on the agent and server)? If this message is appearing at the sever side, can you show us the output of /var/ossec/queue/shared ? It means that the agent is sending an improper formated message (not \n terminated), which might be caused by a truncated output (I only saw this in the past when the shared directory had a very large amount of files).
*btw, how often are you seeing those? **is your first issue resolved? Thanks, -- Daniel B. Cid dcid ( at ) ossec.net On Wed, Sep 17, 2008 at 4:13 AM, Donald Tabone <[EMAIL PROTECTED]> wrote: > > 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 >
