RE: [cobalt-security] LogCheck Help, Please

["FLHQ" <fultonlyons@xxxxxxxxxxxxxx>]

OK, to anyone interested - the rules files for logcheck, although they
may appear so, are NOT case-sensitive.

The entry:

ATTACK

was matching my attackalert.  So, to anyone scratching their head out
there, trying to make a log entry disappear, now you know!

See, what is confusing is that there are several repeated entries, one
upper and one lower case.  This would LEAD you to believe that case does
matter but it DOES NOT!

Thank you all for listening, you may return to your duties...

~Spanky of the playa

(some gratuitous search keywords for the weary: logcheck.hacking
logcheck.violations logcheck.violations.ignore logcheck.ignore logcheck
case sensitive)

> -----Original Message-----
> From: cobalt-security-admin@xxxxxxxxxxxxxxx
> [mailto:cobalt-security-admin@xxxxxxxxxxxxxxx]On Behalf Of FLHQ
> Sent: Thursday, September 27, 2001 11:50 AM
> To: cobalt-security@xxxxxxxxxxxxxxx
> Subject: RE: [cobalt-security] LogCheck Help, Please
>
>
> David:
>
> Thank you for your help, I have a better understanding of it now, and
> I've eliminated the entries from my "Security Violations" section yet
> they still show up in "Active System Attacks" which seems to
> have a mind
> of its own.
>
> Does anyone know where these violations get triggered from?  I'm going
> to check the code again.  I know it's supposed to come from
> logcheck.hacking, but I have no matching keywords in there.
>
> Oooof,
> ~Spanky
>
> > -----Original Message-----
> > From: cobalt-security-admin@xxxxxxxxxxxxxxx
> > [mailto:cobalt-security-admin@xxxxxxxxxxxxxxx]On Behalf Of
> David Yates
> > Buckley
> > Sent: Thursday, September 27, 2001 6:06 AM
> > To: cobalt-security@xxxxxxxxxxxxxxx
> > Subject: Re: [cobalt-security] LogCheck Help, Please
> >
> >
> > Hello,
> >
> > If you read logcheck.sh it shows that it is using grep
> syntax regexp.
> >
> > It is quite easy to find the right rules if you start from
> > understanding
> > that the program is basically doing something like:
> >  grep -v -f ./logcheck.ignore /var/log/auth
> >
> > So now enter  <portsentry.*is already blocked Ignoring> in a
> > file called
> > boo.tst and try doing a proper grep instead of an exclude grep.
> >
> > grep -f ./boo.tst /var/log/auth
> >
> > If you have the right pattern it will show the strings
> > otherwise it will not,
> > but it is quite easy to test things a bit.
> >
> > With regards to your specific query I believe a good rule
> > would be as follows:
> > portsentry.*: attackalert: Host: .* is already blocked Ignoring
> >
> > Or another one that drove me nuts...
> > sendmail.*NOQUEUE: localhost \[127\.0\.0\.1\] did not issue
> > MAIL\/EXPN\/VRFY\/ETRN during connection to MTA
> >
> > . is not concatenation at all you should read some about regular
> > expressions. There is a decent
> > explanation of them inside the perl documentation and in awk... also
> > something in grep.. man grep.
> > . is any character... * is 0 or more of the previous
> > expression so .* is
> > anything.
> >
> > Hope it helps,
> > Yates Buckley
> > Unit9 Ltd.
> >
> > At 07:00 PM 9/26/01 -0700, you wrote:
> > >OK, I've RTFM, read the groups, surfed the net and tested
> > everything I
> > >can to make the following log entries go away:
> > >
> > >Sep 23 07:48:38 MYSERVER portsentry[10539]: attackalert: Host:
> > >pn137.szczecin.sdi.tpnet.pl/217.98.186.137 is already
> > blocked Ignoring
> > >
> > >I removed all keywords in the entry from logcheck.hacking (like
> > >'attackalert')
> > >
> > >I added ignore rules to the logcheck.ignore file like this:
> > >
> > >portsentry.*is already blocked Ignoring
> > >
> > >I added it to my violations.ignore too!
> > >
> > >Basically what I want is to see the inital catch by
> > portsentry but not
> > >every subsequent hit after that.
> > >
> > >Can someone more savvy than I give me an example that
> would take this
> > >out?
> > >
> > >Also, I have yet to find a reference on what the '.' in
> the logcheck
> > >file rules means, or where it needs to go.  It seems to be a
> > >concatenator?
> > >
> > >would this work?
> > >
> > >portsentry[*]: attackalert: * already blocked Ignoring
> > >
> > >or do things need esacping:
> > >portsentry\[*\]: attackalert: * already blocked Ignoring
> > >
> > >or does the '.' have to go before each wildcard:
> > >portsentry\[.*.\]: attackalert: .*already blocked Ignoring
> > >
> > >See, none of these seems to help, its like portsentry logs
> > are included
> > >automagically.  Well, I need some black magic cuz I'm tired
> > of 500 lines
> > >when I only need 5
> > >
> > >I'm glad to do the research and testing myself if someone'd
> > point me to
> > >a definitive document explaining, in detail, the syntax of
> the rules
> > >files.
> > >
> > >The first person to point my to psionic.com gets flamed
> and the next
> > >person who tells me to read the documentation gets a flamethrower
> > >because those docs are so weak.
> > >
> > >Thanks in advance and sorry for the rant, I've been trying
> different
> > >combos for hours, and that's after surfing most of the
> > morning for the
> > >answer.
> > >
> > >-T
> > >
> > >_______________________________________________
> > >cobalt-security mailing list
> > >cobalt-security@xxxxxxxxxxxxxxx
> > >http://list.cobalt.com/mailman/listinfo/cobalt-security
> > >
> > >
> >
> > _______________________________________________
> > cobalt-security mailing list
> > cobalt-security@xxxxxxxxxxxxxxx
> > http://list.cobalt.com/mailman/listinfo/cobalt-security
>
> _______________________________________________
> cobalt-security mailing list
> cobalt-security@xxxxxxxxxxxxxxx
> http://list.cobalt.com/mailman/listinfo/cobalt-security