Hi Marcus, i think it is more clear to use M/Monit in this case as monit supervisor - you can set the alert rules on M/Monit side and if somebody will force-kill Monit, it will send you heartbeat alert (no status update within expected timeframe) - or if monit was stopped by the intruder gracefully, monit will send stop event which can be delivered as alert by M/Monit.
Regards, Martin On Dec 13, 2011, at 1:58 PM, Marcus Mülbüsch wrote: > Hello, > > when I change alert e-mail addresses in /etc/monitrc and then reload monit > all the new addresses get an e-mail; but not the old ones. > > Now, one of the features of monit is that it compares checksums of a lot of > configuration files; so I will get informed if someone changes those files. > > While I realize that someone who gains root-access will have a lot of > options to screw the server, and monit is not (per se) an IDS, I would expect > that I get a mail when monit is killed. > > Unfortunately it is now easiest to change (or remove) alert addresses, > issue a reload and then do whatever you want without monit sending a warning > e-mail. > > It would be a bit more difficult if monit sends the email before re-reading > the configuration, so that monit at least tries to inform the former alert > message receivers. > > Again, it still is possible to circumvent monit alerting you, so monit is > not an IDS. Still, it's a small improvement. > > Marcus > > > -- > To unsubscribe: > https://lists.nongnu.org/mailman/listinfo/monit-general -- To unsubscribe: https://lists.nongnu.org/mailman/listinfo/monit-general
