Rule IDs serve several important roles in OSSEC. Every rule has a unique rule ID and dependent rules refer to the parent rule IDs. In OSSEC verbiage, rule IDs are referred to as “sid”s.
Although it is common and permissible to reuse rule IDs within the local rules space, there are at least three reasons why this may not be a good idea:
- Parent/dependent rules may break. Let’s say you have two rules in the local rule ID space. They were meant to be temporary rules after an application upgrade on multiple systems caused things to become noisy. You don’t want to get 100 alerts a day, but you do need to be notified about the main web server. The rules might look something like this:
- Database queries will lose their meaning. Perhaps you have enabled database output and are running some custom queries against the database. You want to know how many times the application errors occurred, when they started and when they stopped. A simple query might look something like this
- Granular alerts may not work properly. Granular e-mail alerts allow us to send specific messages to specific e-mail addresses based on rules and other criteria. If you had a granular alert in etc/ossec.conf that looks like this the example below, then changing the rule will send the wrong alerts to the pager.
<rule id=”100003″ level=”2″>
<description>No alert on application errors</description>
<rule id=”100004″ level=”7″>
<description>Main web server application error</description>
If rule 100003 is changed to something completely different, then rule 100004 won’t trigger under the right conditions and maybe even not at all.
SELECT rule_id from ALERT where rule_id = ‘100004’;
If you change the rule ID above, the query would now also include those results with whatever the new rule is designed to catch.
Rule IDs can be reused, however it’s important to consider what else may be depending on them. As always, do what works best for you.