2015-10-02 0:21 GMT+03:00 Bond Masuda <bond.mas...@jlbond.com>: > Hello! > > I'm relatively new to SEC, and only recently started using it to monitor > the state of security for Linux systems by processing logs. > > However, several of my rules require "transaction"-like procedures where > I use SEC context to maintain state information and when a transaction > is complete, I commit a set of changes. This has raised two issues, and > although I think I have some ideas of how to solve them, I wanted to > reach out to more experienced users of SEC to see if there are better > ideas than my own. The issues are: > > 1. maintaining state information if SEC execution is interrupted. I.e., > if SEC gets shutdown and restarted, the SEC contexts are lost. My first > thought is to use SEC_INTERNAL_EVENT and simply write the various states > during SEC_SHUTDOWN to file, and read the state information during > SEC_STARTUP. Is there a better way? Perhaps a built-in capability? Any > examples of this type of thing anyone can share? >
Your idea about using SEC's internal events is the best way for tackling the problem. You could save the contexts to a disk in several ways, though -- in the simplest case, you could just write the context names to disk, and restore them at sec startup. Unfortunately, this approach would only save and restore context names, losing other context data (such as lifetimes and context event stores). In order to save and restore full context data, one could employ a Perl module (like Storable) for writing the entire context hash table to disk. There is a sec FAQ entry which provides examples of both approaches: http://simple-evcorr.github.io/FAQ.html#15 The FAQ example with Storable module has also been illustrated in the "Perl Integration" section of the sec official documentation ( http://simple-evcorr.github.io/man.html). There is one interesting question which might come up when one uses Storage module example from FAQ -- if the entire SEC context hash table %main::context_list is overwritten with a retrieve() statement, wouldn't it also erase the SEC_INTERNAL_EVENT context which was created for the SEC_STARTUP event? Although retrieve() indeed overwrites the entire context hash table, it has to be kept in mind that storing hash table to disk is triggered by SEC_SHUTDOWN, but at that very moment SEC_INTERNAL_EVENT context exists as well. Therefore, retrieve() is actually able to keep this context around as a side effect. This issue has also been discussed in an old mailing list post from 2004: http://sourceforge.net/p/simple-evcorr/mailman/message/3667663/ > 2. when SEC is shutdown and restarted, it appears to read from the end > of the input log file. So, any new log entries during the period SEC was > not running do not get processed. This is problematic since I may have a > transaction in progress that is waiting for an event that was missed > during the SEC shutdown/restart cycle. Is there a way to have SEC read > the input log where it left off? And I guess, a following problem would > be how to handle if the log file got rotated? Any ideas here? > That would require storing the file read positions into a state file at shutdown, and continue reading from positions in state file at restart. Unfortunately, the current version of sec doesn't have this feature, but it's worth of consideration for further releases. kind regards, risto > > Thanks for any help... > Bond > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Simple-evcorr-users mailing list > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users >
------------------------------------------------------------------------------
_______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
