Enabling SEC rules
To enable the forwarder for SEC, follow the same process as outlined in Section 11. Specifically, after adding the forwarder.json, you must enable the forwarder and restart the container(s).
Sample Forwarder rule for SEC
1because we don't want events deduplicated, they will just get forwarded as they come into the system.
The SEC forwarding rule syntax uses the same syntax as our Forwarding Rules
NOTE: it is much more efficient to create a forwarding rule to match specific event types rather than trying to match on a lot of events you may not need. In the example above, we're looking to match on BGP events as opposed to matching all Cisco events.
A sample rule is included in LogZilla.
You can edit this file in the following directory.
LogZilla comes pre-installed with a few sample rules to help users get started. Others may be found on our GitHub repository.
The included sample rules are located on this server in the
lz_sec container at
/etc/sec/logzilla/ to help get you started.
.sec file is a set of rules which tell the correlator how to match and process incoming events, as noted in the Rule Types section of this guide.
# ----- Process reload and restart events ----- # Looks for a reload # type=single continue=takeNext ptype=regexp pattern=(\S+) .?SYS-5-RELOAD: (.*) desc=(WARNING) reload requested for $1 action=pipe '%s details:$2' mail -s '[LogZilla] Cisco Alert on $1' root@localhost # Looks for a reload followed by a restart event # type=pairWithWindow ptype=regexp pattern=(\S+) .?SYS-5-RELOAD: desc=(CRITICAL) $1 RELOAD_PROBLEM action=pipe '%s' mail -s '[LogZilla] Cisco Alert on $1' root@localhost ptype2=regexp pattern2=($1) .?%SYS-5-RESTART: desc2=(NOTICE) $1 RELOAD_OK action2=pipe '%s' mail -s '[LogZilla] Cisco Alert on $1' root@localhost window=300 # Looks for a restart without reload command # type=single ptype=regexp pattern=(\S+) .?%SYS-5-RESTART: desc=(CRITICAL) $1 restart without reload command action=pipe '%s' mail -s '[LogZilla] Cisco Alert on $1' root@localhost
These three rules all share the same "flow", meaning that they work together to form a full Correlation.
Referencing the Rule Types help page, we see that the rules used here are
The first rule waits for a reload event sent by your devices. The pattern used here is easy because we only need to send the Host and Message from the LogZilla forwarder in order to get the rule to trigger.
The next rule,
pairWithWindow, tells the event correlator to wait for 5 minutes (300 seconds), to receive a
RELOAD event followed by a
RESTART event. If it does not arrive within 5 minutes, send an email.
The last rule tells the EC to check for a
RESTART event in case no prior
RELOAD event has been seen.