Hi Daniel.
We are currently running the 1.6 local installs.
Timings are random however roughly around every 20mins between each one.
Suppressing the rule from sending emails solved the problems of the emails.
<rule id="1002" level="2">
<match>$BAD_WORDS</match>
<options>no_email_alert</options>
<description>Unknown problem somewhere in the system.</description>
</rule>
but the error below still shows in /var/log/messages and the questions I
asked still stand.
Thanks.
2008/9/18 Daniel Cid <[EMAIL PROTECTED]>
>
> 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
> >
>
