Before we start writing rules, we should be aware of some rules to be followed:

Minding these three rules helps to ensure that our installations won't break with upgrades and that we can always get back to a "stock" OSSEC by removing the local_rules.xml file from our configuration.

Every rule must have an ID, a level, a description, and a match condition. The IDs must be unique, and our rules must have an ID over 100000. It's important to note that re-using or reordering rule IDs can cause confusion or inaccuracy in historic data.

Rules in OSSEC have a level from 0 to 15. The higher the level, more certain the analyzer is of an attack. Level 0 is a special level to tell OSSEC to ignore the alerts where no log will be generated and OSSEC will discard the alert and data silently. By default, OSSEC considers anything at or exceeding level 7 to be e-mail worthy, but it is also configurable.

Rules also require a description field to explain what the rule does. This description will be used as the event identifier in the e-mails and log messages that OSSEC generates. As it will be a part of the reporting, it's best to explain the rule professionally and format it consistently. Descriptions like "alerting for this thing" won't be helpful to your colleagues, whereas "Ignore failed login attempts from vulnerability scanners between 4:00 and 7:00" will be clear and informative.

Now that we're well versed with the protocols of the rules, let's process some data from our custom application logging via syslog as follows:

May 4 19:12:03 server custom-app: Startup initiated.
May 4 19:12:07 server custom-app: No error detected during startup!
May 4 19:12:08 server custom-app: Startup completed, processing data.
May 4 19:12:08 server custom-app: Failed login from '4.5.6.7' as testuser

We're receiving an alert about unknown errors and authentication failures from our custom application. We would prefer to silence these unknown error messages and ensure that we don't provide alerts for failed logins from 4.5.6.7, our vulnerability scanner.

In order to figure out the first step, we need to understand what's happening to generate the alerts:

Using these two rules, we've been able to silence the noisiest log entries in our sample environment.

OSSEC rules are processed sequentially. Each rule has a number of conditions and a logical AND is applied to the conditions. The more specific we make the rule, the more accurate it will be. In our example, we filtered events using the program_name attribute for the string, custom-app.

Each rule also specifies an if_sid element, which requires the log message to be flagged with the rule ID we specify. The if_sid parameter can take a comma-separated list of rule IDs, where the rule will match if any of those IDs are matched. Consider that multiple instances of the same element appear in a rule; refer to the following example:

<match>illegal user</match>
<match>unknown user</match>
<match>invalid user</match>

That grouping is surrounded in logical OR. It's important to note that after our rules match, the ID is changed and other rules looking for those lines with the same if_sid parameter, which was originally set, will fail to match. When a new rule matches, it replaces the attributes of the alert with its own values, replacing the ID and level.

While our first rule stopped at eliminating the match based on the rule ID and program name only, the second rule used the match attribute to find a string in the log message itself. In addition to match, there is also a regex attribute to allow more flexible matching of strings.

To see a complete list of fields available, check out the OSSEC documentation on rules' syntax available at the following link:

http://www.ossec.net/doc/syntax/head_rules.html

OSSEC rules are quite capable. We saw how to modify an alert based on the if_sid parameter, which is the rule ID. We saw that we can adjust the rule level using the level of the new rule. Most cases will involve this type of rule-level promotion or demotion depending on the context. We can evaluate events based on a number of fields. We used ossec-logtest to see some of those fields, but we're missing data. In our examples, we saw the following message:

**Phase 2: Completed decoding.
       No decoder matched.

Without a decoder, our event data is limited to simple string matches. Let's take a look at what decoders are and how they work.

**Phase 1: Completed pre-decoding.
     full event: 'May  4 19:12:08 server custom-app: Failed login from '1.2.3.4' as testuser''
     hostname: 'server'
     program_name: 'custom-app'
     log: 'Failed login from '1.2.3.4' as 'testuser'

May  4 19:11:01 ether sshd[3747]: Accepted publickey for brad from 1.2.3.4 port 48801 ssh2

**Phase 1: Completed pre-decoding.
     full event: 'May  4 19:11:01 ether sshd[3747]: Accepted publickey for brad from 1.2.3.4 port 48801 ssh2'
     hostname: 'ether'
     program_name: 'sshd'
     log: 'Accepted publickey for brad from 1.2.3.4 port 48801 ssh2'

**Phase 2: Completed decoding.
     decoder: 'sshd'
     dstuser: 'brad'
     srcip: '1.2.3.4'

**Phase 3: Completed filtering (rules).
     Rule id: '5715'
     Level: '3'
     Description: 'SSHD authentication success.'
**Alert to be generated.