{"id":172,"date":"2008-07-04T22:07:00","date_gmt":"2008-07-04T22:07:00","guid":{"rendered":"https:\/\/defragged.org\/ossec\/?p=172"},"modified":"2020-07-02T22:08:36","modified_gmt":"2020-07-02T22:08:36","slug":"testing-ossec-rules","status":"publish","type":"post","link":"https:\/\/defragged.org\/ossec\/2008\/07\/testing-ossec-rules\/","title":{"rendered":"Testing OSSEC rules"},"content":{"rendered":"\n

When you are troubleshooting OSSEC<\/a> 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).<\/p>\n\n\n\n

First, grab the latest CVS snapshot and compile it (it will be included on v1.6 and above):<\/p>\n\n\n\n

# 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<\/p><\/blockquote>\n\n\n\n

The tool ossec-logtest<\/em> 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:<\/p>\n\n\n\n

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

Jul 4 09:42:16 enigma sshd[11990]: Accepted password for dcid from 192.168.2.10 port 35259 ssh2<\/strong><\/p>

**Phase 1: Completed pre-decoding.
full event: \u2018Jul 4 09:42:16 enigma sshd[11990]: Accepted password for dcid from 192.168.2.10 port 35259 ssh2\u2032
hostname: \u2018enigma\u2019
program_name: \u2018sshd\u2019
log: \u2018Accepted password for dcid from 192.168.2.10 port 35259 ssh2\u2032<\/p>

**Phase 2: Completed decoding.
decoder: \u2018sshd\u2019
dstuser: \u2018dcid\u2019
srcip: \u2019192.168.2.10\u2032<\/p>

**Phase 3: Completed filtering (rules).
Rule id: \u201910100\u2032
Level: \u20194\u2032
Description: \u2018First time user logged in.\u2019
**Alert to be generated.<\/p><\/blockquote>\n\n\n\n

So, in the above example, we provided an authentication success log and ossec-testrule<\/em> 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:<\/p>\n\n\n\n

WinEvtLog: Security: AUDIT_SUCCESS(538): Security: lac: OSSEC-HM: OSSEC-HM: User Logoff: User Name: lac Domain: OSSEC-HM Logon ID: (0\u00d70,0xF784D5) Logon Type: 2<\/strong><\/p>

**Phase 1: Completed pre-decoding.
full event: \u2018WinEvtLog: Security: AUDIT_SUCCESS(538): Security: lac: OSSEC-HM: OSSEC-HM: User Logoff: User Name: lac Domain: OSSEC-HM Logon ID: (0\u00d70,0xF784D5) Logon Type: 2\u2032
hostname: \u2018enigma\u2019
program_name: \u2018(null)\u2019
log: \u2018WinEvtLog: Security: AUDIT_SUCCESS(538): Security: lac: OSSEC-HM: OSSEC-HM: User Logoff: User Name: lac Domain: OSSEC-HM Logon ID: (0\u00d70,0xF784D5) Logon Type: 2\u2032<\/p>

**Phase 2: Completed decoding.
decoder: \u2018windows\u2019
status: \u2018AUDIT_SUCCESS\u2019
id: \u2019538\u2032
extra_data: \u2018Security\u2019
dstuser: \u2018lac\u2019
system_name: \u2018OSSEC-HM\u2019<\/p>

**Phase 3: Completed filtering (rules).
Rule id: \u201918149\u2032
Level: \u20193\u2032
Description: \u2018Windows User Logoff.\u2019
**Alert to be generated.<\/p><\/blockquote>\n\n\n\n

In addition to this information, you can run ossec-testrule<\/strong> with the -f<\/strong> flag to get full information on the rule path that the log is following:<\/p>\n\n\n\n

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

Jul 4 10:05:30 enigma sshd[27588]: Failed password for invalid user test2 from 127.0.0.1 port 19130 ssh2<\/strong><\/p>

**Phase 1: Completed pre-decoding.
full event: \u2018Jul 4 10:05:30 enigma sshd[27588]: Failed password for invalid user test2 from 127.0.0.1 port 19130 ssh2\u2032
hostname: \u2018enigma\u2019
program_name: \u2018sshd\u2019
log: \u2018Failed password for invalid user test2 from 127.0.0.1 port 19130 ssh2\u2032<\/p>

**Phase 2: Completed decoding.
decoder: \u2018sshd\u2019
srcip: \u2019127.0.0.1\u2032<\/p>

**Rule debugging:
Trying rule: 1 \u2013 Generic template for all syslog rules.
*Rule 1 matched.
*Trying child rules.
Trying rule: 5500 \u2013 Grouping of the pam_unix rules.
Trying rule: 5700 \u2013 SSHD messages grouped.
*Rule 5700 matched.
*Trying child rules.
Trying rule: 5709 \u2013 Useless SSHD message without an user\/ip.
Trying rule: 5711 \u2013 Useless SSHD message without a user\/ip.
Trying rule: 5707 \u2013 OpenSSH challenge-response exploit.
Trying rule: 5701 \u2013 Possible attack on the ssh server (or version gathering).
Trying rule: 5706 \u2013 SSH insecure connection attempt (scan).
Trying rule: 5713 \u2013 Corrupted bytes on SSHD.
Trying rule: 5702 \u2013 Reverse lookup error (bad ISP or attack).
Trying rule: 5710 \u2013 Attempt to login using a non-existent user
*Rule 5710 matched.
*Trying child rules.
Trying rule: 5712 \u2013 SSHD brute force trying to get access to the system.
<\/em><\/strong>
**Phase 3: Completed filtering (rules).
Rule id: \u20195710\u2032
Level: \u20195\u2032
Description: \u2018Attempt to login using a non-existent user\u2019
**Alert to be generated.<\/p><\/blockquote>\n\n\n\n

As you can see, it show us all the rules that were tried and if it matched or not.<\/p>\n\n\n\n

Hope this little tool can be helpful. Feedback is welcome, as always.<\/p>\n","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5,4],"tags":[10],"_links":{"self":[{"href":"https:\/\/defragged.org\/ossec\/wp-json\/wp\/v2\/posts\/172"}],"collection":[{"href":"https:\/\/defragged.org\/ossec\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/defragged.org\/ossec\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/defragged.org\/ossec\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/defragged.org\/ossec\/wp-json\/wp\/v2\/comments?post=172"}],"version-history":[{"count":1,"href":"https:\/\/defragged.org\/ossec\/wp-json\/wp\/v2\/posts\/172\/revisions"}],"predecessor-version":[{"id":173,"href":"https:\/\/defragged.org\/ossec\/wp-json\/wp\/v2\/posts\/172\/revisions\/173"}],"wp:attachment":[{"href":"https:\/\/defragged.org\/ossec\/wp-json\/wp\/v2\/media?parent=172"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/defragged.org\/ossec\/wp-json\/wp\/v2\/categories?post=172"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/defragged.org\/ossec\/wp-json\/wp\/v2\/tags?post=172"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}