The biggest failure of security software is the volume of unactionable alerts. Silencing alerts and investigating false positives robs an organization's valuable hours that it could use to enhance its security posture. OSSEC provides its users with options to fine-tune alerting to keep from becoming the boy who cried "Wolf!".
Armed with knowledge on how to write rules, we could just toggle alerting levels for all rules individually. This would be tedious, unless we used a generic catchall. However, that would destroy the granularity and precision of OSSEC analysis. It would be better to combine the two to maintain granularity and get e-mail alerting down to reasonable levels.
Every rule must set a level. The higher the level, the more severe the alert is considered. Alert levels are integers from 0 (ignore) to 15 (certain high-level security event). The official documentation has the definitive list of levels and their meanings and can be found via the following link:
http://www.ossec.net/doc/manual/rules-decoders/rule-levels.html
Rules can also append groups to the alert metadata. OSSEC ships with a number of defaults, and you're able to create your own. Here are a few interesting groups from the default rule set: invalid_login, authentication_success, authentication_failed, connection_attempt, and attacks.
Using just the level and group of an alert, you can configure a vast amount of alerts in a few lines of configuration.
Perform the following steps to configure alerts:
To do this, start with configuring the default log and the e-mail level for the alerts as follows:
<alerts> <log_alert_level>1</log_alert_level> <email_alert_level>7</email_alert_level> </alerts>
To increase the default level to
9, change a single character in theossec.conffile as follows:<alerts> <log_alert_level>1</log_alert_level> <email_alert_level>9</email_alert_level> </alerts>
OSSEC reports feature provides a flexible way to send condensed reports to give you daily insight into alerts that are interesting, though not actionable as individual events. To configure a report of successful logins, add this to your
ossec.conffile:<reports> <category>authentication_success</category> <user type="relation">srcip</user> <title>OSSEC: Authentication Report</title> <email_to>[email protected]</email_to> </reports>
The e-mail alerting defaults on large networks may inundate administrators in the alerts for the log lines containing the word error. Log level 8 is reserved for first-time events, and you may not want to know the first time every administrator logs into every server in the network. Given that, we can reasonably adjust the level of the e-mail alerts to level 9 that is reserved for Errors from Invalid Sources.
This single-digit change may dramatically improve the volume of the alerts. You may wish to still receive periodic reports on the events not generating e-mails. The use of reports, alerts matching the source IDs, groups, or levels that are specified is summed up and broken down by key elements in the events: usernames, source IPs, event source hosts, levels, and groups.
Our sample report generates a daily report of authentication history for all installed and active OSSEC agents. This happens to be a common requirement for PCI-DSS, SOX, FISMA, or FERPA. The report will contain an aggregation of various categories; here's a sampling of some interesting data:
Report 'OSSEC: Authentication Report' completed. ------------------------------------------------ ->Processed alerts: 1293 ->Post-filtering alerts: 120 ->First alert: 2013 May 10 02:00:02 ->Last alert: 2013 May 10 22:05:25 Top entries for 'Source ip': ------------------------------------------------ 192.168.0.1 |100 127.0.0.1 |19 1.2.3.4 |1 Top entries for 'Username': ------------------------------------------------ compliance_scanner |100 root |19 mallory |1 Related entries for 'Username': ------------------------------------------------ compliance_scanner |120 srcip: '192.168.0.1' root |19 srcip: '127.0.0.1' mallory |1 srcip: '1.2.3.4'
This report uses the relation attribute to aggregate users by source IP to generate the last stanza of the report. It provides some clarity on the Username and Source ip sections to let us know where particular users originated. Each report requires an email_to attribute to be set to valid.
Another option that is often useful for very specific reports referencing a particular rule, or set of rules, is the showlogs option. Using this option, you can include a complete history of every log message that generated the alerts in the report. This option may generate large e-mails. To use it, add this to your report declaration:
<showlogs>yes</showlogs>
These basic tweaks provide a lot of value, but there are a few additional tweaks we can use to clear up a few noisy alerts and integrate OSSEC with existing security workflows.
Even when toggling the default alert level, you will notice that they occasionally receive alerts below the threshold set in the ossec.conf file. This is because some rules override this setting by explicitly setting the e-mail alert flag. The "bad words" rule, ID 1002, is another example that overrides the default e-mail behavior. The rule is defined as follows:
<!-- Slightly modified for simplicity --> <rule id="1002" level="2"> <match>failure|error|attack|bad |illegal|denied|refused|unauthorized</match> <options>alert_by_email</options> <description>Unknown problem somewhere in the system.</description> </rule>
This rule uses the alert_by_email option, which always alerts you regardless of the settings of the alert levels. Another set of rules that uses this override detects a restart of the OSSEC process. Rules that detect the start or stop of the OSSEC daemon also use this option to ensure that an e-mail alert is always sent. If you're not interested in these alerts, you can overwrite the rule and change its behavior using the overwrite attribute. This rule should be created in the local_rules.xml file as follows:
<rule id="1002" level="2" overwrite="yes"> <match>failure|error|attack|bad |illegal|denied|refused|unauthorized</match> <options>no_email_alerts</options> <description>Unknown problem somewhere on the system (no_email_alert)</description> </rule>
We need to redefine the rule with our modifications because the overwrite flag replaces the existing rule of that source ID entirely. The purpose of this method in creating a new source ID is so other rules dependent on this rule will not need to also be rewritten to accommodate the change. The downside is that if an improvement to the default rule is made in an OSSEC release, you will need to manually upgrade your local_rules.xml file with that update.
Once at a larger scale, it may become more useful to integrate OSSEC's alert logs into a larger Security Information and Event Manager (SIEM) such as Splunk or ArcSight. Luckily, OSSEC also supports the logging of events via syslog. Any event that OSSEC logs, which is level 1 and above by default, is also written to syslog. OSSEC supports multiple logging formats, including the following:
default: This is the default full syslog output that can be used in hybrid modeCEF: This refers to ArcSight's Common Event Formatsplunk: This is the key-value outputjson: This refers to JSON-encoded events; it is most useful for LogStash or Graylog2
To enable one or more syslog outputs, you just need to declare the server and port values. OSSEC uses UDP for all syslog events as follows:
<syslog_output> <server>logserver.example.com</server> <port>514</port> <format>json</format> </syslog_output>
This is plain syslog traffic and will not be encrypted. You can change the level for which a certain syslog server receives events by setting the log level in the syslog definition:
<syslog_output>
<level>10</level>
<server>critical-events.example.com</server>
<port>514</port>
<format>json</format>
</syslog_output>You can also route certain events by rule group as follows:
<syslog_output>
<group>authentication_success</group>
<server>authenticationlogs.example.com</server>
<port>514</port>
<format>json</format>
</syslog_output>Or, you can also route specific events by the source ID directly:
<syslog_output>
<rule_id>1002</rule_id>
<server>errors.example.com</server>
<port>514</port>
<format>json</format>
</syslog_output>You may choose to completely disable e-mail alerting from OSSEC and use this syslog mechanism to work within your existing SIEM workflow.