Earl, On Jan 22, 2008, at 4:19 PM, Earl wrote:
Sounds like we need to decide exactly how it should work before I or anyone mucks with it :)
Yup
The current "automated" rule update process offers the option to restart snort/snort-inline IF changes are made to rules on a rule update run. So, according to what you say below, by offering this option, we are setting people (that choose not to do the restart) up for failure. That being said, should we force the restart IF rules are updated? FYI: the update process only takes action of rules are modified... i.e. no unnecessary restarts occur in the case of no changes for a give update run.
The important thing is that the sid-msg.map file snort is using is the same one that is in the walleye db. Otherwise, snort could be putting alerts in the unified file with an id that walleye thinks is for something else. So if during the process of updating the rules, the sid-msg.map that snort uses is modified, we need to reload the ids_sig db like I explained in the previous email to Steve. If the sid- msg.map is not modified during the rule update process, then we are good.
I'll give you a ring tomorrow so we can chat about this. There a good time?
Rob _______________________________________________ Honeywall mailing list [email protected] https://public.honeynet.org/mailman/listinfo/honeywall
