Testing OSSEC rules

When you are troubleshooting OSSEC or trying to write new rules/decoders, the first problem most people have is how to test them. In the past, it would require manually restarting or creating a testing installation for it, but as from the latest CVS snapshot, we built a tool to simplify this task (ossec-testrule).

First, grab the latest CVS snapshot and compile it (it will be included on v1.6 and above):

# wget http://www.ossec.net/files/snapshots/ossec-hids-080704.tar.gz
# tar -zxvf ossec-hids-080704.tar.gz
# cd ossec-hids-080704/src/
# make clean
# make libs
# cd analysisd
# make logtest

The tool ossec-logtest will be created on the current directory and we can start using it. The way it works is that it will read the current rules/decoder (from /var/ossec ) and accept any log from stdin:

# ./ossec-logtest
2008/07/04 09:57:28 ossec-testrule: INFO: Started (pid: 12683).
ossec-testrule: Type one log per line.

Jul 4 09:42:16 enigma sshd[11990]: Accepted password for dcid from 192.168.2.10 port 35259 ssh2

**Phase 1: Completed pre-decoding.
full event: ‘Jul 4 09:42:16 enigma sshd[11990]: Accepted password for dcid from 192.168.2.10 port 35259 ssh2′
hostname: ‘enigma’
program_name: ‘sshd’
log: ‘Accepted password for dcid from 192.168.2.10 port 35259 ssh2′

**Phase 2: Completed decoding.
decoder: ‘sshd’
dstuser: ‘dcid’
srcip: ’192.168.2.10′

**Phase 3: Completed filtering (rules).
Rule id: ’10100′
Level: ’4′
Description: ‘First time user logged in.’
**Alert to be generated.

So, in the above example, we provided an authentication success log and ossec-testrule showed us how it would be decoded, what information was extracted and which rule fired. In the next example, we can see how it would extract a user logoff message from Windows:

WinEvtLog: Security: AUDIT_SUCCESS(538): Security: lac: OSSEC-HM: OSSEC-HM: User Logoff: User Name: lac Domain: OSSEC-HM Logon ID: (0×0,0xF784D5) Logon Type: 2

**Phase 1: Completed pre-decoding.
full event: ‘WinEvtLog: Security: AUDIT_SUCCESS(538): Security: lac: OSSEC-HM: OSSEC-HM: User Logoff: User Name: lac Domain: OSSEC-HM Logon ID: (0×0,0xF784D5) Logon Type: 2′
hostname: ‘enigma’
program_name: ‘(null)’
log: ‘WinEvtLog: Security: AUDIT_SUCCESS(538): Security: lac: OSSEC-HM: OSSEC-HM: User Logoff: User Name: lac Domain: OSSEC-HM Logon ID: (0×0,0xF784D5) Logon Type: 2′

**Phase 2: Completed decoding.
decoder: ‘windows’
status: ‘AUDIT_SUCCESS’
id: ’538′
extra_data: ‘Security’
dstuser: ‘lac’
system_name: ‘OSSEC-HM’

**Phase 3: Completed filtering (rules).
Rule id: ’18149′
Level: ’3′
Description: ‘Windows User Logoff.’
**Alert to be generated.

In addition to this information, you can run ossec-testrule with the -f flag to get full information on the rule path that the log is following:

# ./ossec-logtest -f
2008/07/04 10:05:43 ossec-testrule: INFO: Started (pid: 23007).
ossec-testrule: Type one log per line.

Jul 4 10:05:30 enigma sshd[27588]: Failed password for invalid user test2 from 127.0.0.1 port 19130 ssh2

**Phase 1: Completed pre-decoding.
full event: ‘Jul 4 10:05:30 enigma sshd[27588]: Failed password for invalid user test2 from 127.0.0.1 port 19130 ssh2′
hostname: ‘enigma’
program_name: ‘sshd’
log: ‘Failed password for invalid user test2 from 127.0.0.1 port 19130 ssh2′

**Phase 2: Completed decoding.
decoder: ‘sshd’
srcip: ’127.0.0.1′

**Rule debugging:
Trying rule: 1 – Generic template for all syslog rules.
*Rule 1 matched.
*Trying child rules.
Trying rule: 5500 – Grouping of the pam_unix rules.
Trying rule: 5700 – SSHD messages grouped.
*Rule 5700 matched.
*Trying child rules.
Trying rule: 5709 – Useless SSHD message without an user/ip.
Trying rule: 5711 – Useless SSHD message without a user/ip.
Trying rule: 5707 – OpenSSH challenge-response exploit.
Trying rule: 5701 – Possible attack on the ssh server (or version gathering).
Trying rule: 5706 – SSH insecure connection attempt (scan).
Trying rule: 5713 – Corrupted bytes on SSHD.
Trying rule: 5702 – Reverse lookup error (bad ISP or attack).
Trying rule: 5710 – Attempt to login using a non-existent user
*Rule 5710 matched.
*Trying child rules.
Trying rule: 5712 – SSHD brute force trying to get access to the system.

**Phase 3: Completed filtering (rules).
Rule id: ’5710′
Level: ’5′
Description: ‘Attempt to login using a non-existent user’
**Alert to be generated.

As you can see, it show us all the rules that were tried and if it matched or not.

Hope this little tool can be helpful. Feedback is welcome, as always.

This entry was posted in ossec, v16. Bookmark the permalink.

4 Responses to Testing OSSEC rules

  1. Brownoxford says:

    This is an awesome tool!

  2. JM says:

    Great tool. :-) How about an option to specify a different rule/decoder directory?

  3. Rick McClinton says:

    Note that ossec-testrule does not list the ‘-f’ flag in its help output, but it still works.

  4. Joe says:

    I haven’t tried it out, but I can tell this was what I’ve been missing. Before I created rules I had to guess as to how OSSEC was viewing the decoders/rules and what the problem could be. I gave up in frustration, but I’m going to try again with logtest. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>