On Thu, Jan 15, 2015 at 11:53 AM, Dan Garthwaite <[email protected]> wrote: > I never, ever, thought I would one day read a 250 line SMTP protocol > implementation in C: src/os_maild/sendcustomemail.c >
Is that good or bad? > What would be needed templeted emails to be implemented? What is step 1? > > 1) A way for admins to configure OSSEC to match templates to alerts. > > There are many ways to do this. > > a) filename convention in a dir > I would prefer a filename convention in a certain directory path but OSSEC > has many facets to an alert that could be matched - so this isn't a good > fit. > > b) template file convention itself containing matches > Might be better. A single template could enumerate which rules to match > against. This is like duplicating the on-board effort of weeding out rules > to alert on, and then building up the alerts for those that do to use the > new template. Ugh. > > c) Have email snippets or sections that get bolted on to outgoing emails if > certain conditions are met. > This is pretty good. If the alert has the host name, then add a section > to that email's message body. Then you can have a nagios section, a > graphite section, a munin section, an intranet wiki sections, all containing > templated strings: > "https://munin.example.com/{hostname}/index.html#firewall.html"; > "https://nagios.example.com/cgi-bin/nagios/status.cgi?host={hostname}"; > > So "c)" could possibly be done with the least amount of effort. Allow for > injecting text strings into the body of outgoing alert emails. This is the > lowest common denominator and least satisfying. > > d) Allow for a one time config option to override all emails with a > tokenized template file. > > Possibly better than C) and ought to be easier. But without some > conditional logic you would have to accept that some types alerts will > result in nonsensical output. (For example, links to nagios on a ossec > server restart alert) > > e) Allow for a config option to use arbitrary scripts to process alert > emails. > > Pass along context via a json string in stdin, or via environment variables. > Either way, offload email processing to an admin provided script of their > preferred language. > > f) Do none of the above, use the syslog output already present in ossec. > > Thinking this through - I guess we already have the ability to write 3rd > party programs to listen for syslog or zeromq submissions and react to them > by sending emails. That might actually be the best of all. xinetd makes > this really easy, you don't have to write socket code. > If someone were going to implement something like this, I'd suggest using the zeromq support instead of parsing alerts.log. It's a heck of a lot easier. > That is enough navel gazing for one email. Sorry for the "yeah me too" > email that triggered this. > > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
