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]>
