I've spent a few months fine tuning and correcting problems with a new feature I required to analyze logs from OpenLDAP. I'm now looking for comments and testers as the patch has been running stably and has been invaluable to me.
The write-up is here: http://db0.us/article/2012/11/26/ossec-hids-accumulator.html Patch is here: https://gist.github.com/4150352 My fork of the repository on GitHub: https://github.com/reyjrar/ossec-hids # Overview OpenLDAP logs are multi-line, but also vary in the number and ordering of the lines. Each line contains a connection ID and only the relevant information; connect has IP's and ports, bind has username only, and the status line has only the result of the operation. A requirement of our PCI audit was to be able to see when a single IP fails non-anonymous BINDs more than 10 times. It seemed like a simple task, but I quickly realized this type of log file wasn't easily handled by the current OSSEC feature set. So I figured, if each line has the same ID, I could write a module that used that connection ID as a key to cache that data. This patch does just that. As more data is made available, the accumulator patch stuffs that data into the EventInfo of subsequent identically keyed events. Here's an example of the flow with the decoder setup as in the blog post: Jan 11 09:26:57 hostname slapd[20872]: conn=999999 fd=64 ACCEPT from > IP=10.1.2.37:33957 (IP=10.1.2.2:389) Accumulator Key: "hostname openldap 999999" EventInfo: srcip=10.1.2.37 Jan 11 09:26:57 hostname slapd[20872]: conn=999999 op=0 BIND > dn="uid=example,ou=People,dc=example,dc=com" method=128 > Accumulator Key: "hostname openldap 999999" EventInfo: srcip: 10.1.2.37 username: example Jan 11 09:26:57 hostname slapd[20872]: conn=999999 op=0 RESULT tag=97 > err=49 text= > Accumulator Key: "hostname openldap 999999" EventInfo: srcip: 10.1.2.37 username: example So, at this result event, we have all the data from the previous two log entries and can create a rule: <rule id="100000" level="1"> <decoded_as>openldap</decoded_as> <match> RESULT tag=97 err=49</match> </rule> <rule id="100001" level="10" frequency="5" timeframe="60"> <if_matched_sid>100000</if_matched_sid> <same_source_ip/> <description>Multiple failed-logins from same source IP</description></rule> Which will work just like the OpenSSH rule we already have enabled. Thanks, -- Brad Lhotsky
