Daniel,
This problem went away and stayed away so is more than likely related
to an errant custom decoder I was working on at the time, as you
surmised.
BTW, I did modify the default sendmail-reject decoder to include the
more inclusive FreeBSD logging to read:
<program_name>^sendmail|^sm-mta|^sm-msp-queue</program_name>
so that it would include all the variants.
Rereading the power-point link reference you provided has been very
helpful.
Right now I am still working my way through syntax and flow, mostly
for analysis of various spam-related log entries that are then used to
redirect spammers to a tarpit or block them outright at the pf
firewall. I have a site that has to reject 30,000 to 60,000 messages
per day to get fewer than 1,500 good ones. Ossec is primarily used to
reduce the load on the various spam/virus scanning processes.
When I get them all functioning and organized, I'll submit them.
Thanks for the help.
On Dec 3 2007, 10:07 pm, "Daniel Cid" <[EMAIL PROTECTED]> wrote:
> Hi Jim,
>
> I am quite lost with your problem in here, since none of these logs
> would be parsed
> by the default sendmail decoder from ossec. I saw you did a few by
> yourself and they
> are probably the ones parsing it... Btw, it would be nice to include
> them by default on
> ossec (if you want to release them, of course).
>
> The following document should help you understand our rules/decoders a bit
> more:
>
> http://www.ossec.net/ossec-docs/auscert-2007-dcid.pdf
>
> Hope it helps.
>
> --
> Daniel B. Cid
> dcid ( at ) ossec.net
>
> On Dec 3, 2007 3:22 AM, Jim Flowers <[EMAIL PROTECTED]> wrote:
>
> > A little more information may help to clear this up: All of the missed
> > srcip occurred at the same time: from 11:52:44 to 14:08:20 on Dec 1 and from
> > 22:13:55 On Dec 1 until now (2 days later) so I think it is fairly likely
> > that I added a custom decoder or rule that has caused this effect. When I
> > get a chance, I'll figure out which one.
>
> > I originally discounted it being a rule as I don't understand how a rule can
> > fire but have it's srcip stolen by another rule. Still have a lot to learn
> > about how rules work.
>
> > I do have a question though. Can more than one decoder reference the same
> > <program_name \>. If so, does each decoder work independently of the other
> > or is there an order of precedence?
>
> > On Dec 1, 2007 6:48 PM,jflowers<[EMAIL PROTECTED]> wrote:
>
> > > I am curious about the consistency of pattern matching in the stock
> > > decoder/rules for sendmail included in v1.4. When I look at rule 3104
> > > the alerts sometimes provide an IP address and at other times do not
> > > (Decoder: sendmail-reject; rule family tree: 3100:3101:3104, no
> > > overwriting). Here are two very similar records. The first does not
> > > provide the srcip in the alert, the second does.
>
> > --
> > Jim Flowers <[EMAIL PROTECTED]>
