--- On Mon, 4/27/09, Hari Sekhon <hpsek...@googlemail.com> wrote:
> From: Hari Sekhon <hpsek...@googlemail.com>
> Subject: Re: [Simple-evcorr-users] Tracking down alert matching
> rules/Color/Bold
> To: "Risto Vaarandi" <risto.vaara...@seb.ee>
> Cc: "'simple-evcorr-users@lists.sourceforge.net'"
> <simple-evcorr-users@lists.sourceforge.net>
> Date: Monday, April 27, 2009, 2:04 PM
> Risto Vaarandi wrote:
> > hi Hari,
> > after reading your mail, my first impression is that
> it shouldn't (and
> > actually, couldn't) be something that is built into
> SEC. SEC output
> > actions are currently very generic ones and they are
> not restricted to
> > doing something with lines that the pattern matched
> (i.e., the value
> > of $0 only). Therefore, I would argue that the best
> place for any
> > coloring scheme is the output script that is invoked
> from SEC.
> > However, let me ask one question -- why are you having
> difficulties
> > with identifying the rule that produced the alert? You
> are not limited
> > to mailing the $0 value only, but you can also send
> any data you want
> > from SEC as an alert.
> You're right, after a second look, it was obvious to me,
> I've grouped
> and aggregated alerts so it could have been any number of
> rules but was
> actually quite easy to find one I dug in to them. It just
> wasn't
> immediately obvious from the email itself which thing had
> triggered it
> so it would have been nice to have the specific bit that
> first triggered
> this rule highlighted... which I think is a nice touch.
Is the problem you are having mainly caused by the fact that input messages are
having an overly complex structure, and it is impossible to distinguish them
from "normal" messages at first glance?
If that's the case, I would recommend the use of ()-operator regexp operators.
Surely, there are certain parts in these complex input messages that establish
them as error messages (otherwise, it would be impossible to recognize them
with regular expressions). If you now use ()-operators in your regexp, you are
able to set $<number> variables which can be used for forming your alert
messages.
>
> The reason I am thinking of tying this in to Sec is because
> only Sec
> knows what matched, so I would need to use a capture and
> then perhaps do
> a replace op on $0 using the capture to mangle it into
> colour/boldness
> to make it immediately obvious what triggered it.
>
> This came through in general Linux Alerts, having %s or $0
> in subjects
> is in my opinion more risky and therefore my email subjects
> are generic
> and not stripped or using any part of the log itself as I
> think this
> opens up more possible issues security-wise in terms of
> command or smtp
> injection (read an interesting anti log-analysis paper on
> this from ossec).
I fully agree with you that having $0 or %s on subject lines introduces many
security problems. However, if you need to set the message priority by certain
parts of a matching line, why not extract parts from the input line with regexp
()-operators? In order to provide you an example, the syslog-ng daemon can be
configured to write the message priority to the log which regular syslogd does
not do. Fortunately, it is easy to extract the message level and use it in the
subject line with the following pattern and action:
pattern=\[daemon\.(crit|alert)\] sshd\[\d+\]:
action=pipe '$0' /bin/mail -s '$1' root
Perhaps it is possible to use a similar alert generation style in your
environment? The above example would create a comprehensible subject line that
describes the severity of the alert, while the whole message line is NOT passed
on the subject line, but rather through standard input of /bin/mail which is
much more secure.
>
> Also when you have more than 10 thousand rules running
> against your
> infrastructure, having unique subjects for each one seems
> fairly
> impractical as I group emails to receive less of them and
> I've also
> written the alerting to be anti-DoS as well so each message
> does not
> arrive in a separate email unless a couple mins of
> inactivity has gone
> by. The real information is in the body, which at a glance
> can look a
> bit flat without something to make the caught bit jump out
> at you, hence
> the wish to add colour and/or boldness to the relevant
> parts.
hmmm... can you provide some examples how your environment looks like? It might
make it somewhat easier to provide an advice.
br,
risto
>
> -h
>
> --
> Hari Sekhon
> Always open to interesting opportunities
> http://www.linkedin.com/in/harisekhon
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables
> unlimited
> royalty-free distribution of the report engine for
> externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
