bookmark_borderRunning multiple OSSEC decoders on the same event

If you need to run multiple decoders on the same log to extract additional pieces of information (and at the same time do not affect the original decoder), we have a simple way to do so.

Just create multiple child decoders with the same name and no “prematch” and all of them will be evaluated. A good example is for the Microsoft event logs. This is our original decoder for Windows:

<decoder name=”windows-sub1″>
<type>windows</type>
<prematch>^WinEvtLog: </prematch>
<regex offset=”after_prematch”>^\.+: (\w+)\((\d+)\): (\.+): </regex>
<regex>(\.+): \.+: (\S+): </regex>
<order>status, id, extra_data, user, system_name</order>
<fts>name, location, user, system_name</fts>
</decoder>

You will see that we do not extract a soure IP address from there (only user, system name, location, etc). If we wanted to extract the source IP address whenever it is available, we would need to check all the variations (Source Network Address:, Source IP Address:, etc). By using sub-decoders we can check for them without affecting the original:

<decoder name=”windows”>
<type>windows</type>
<prematch>^WinEvtLog: </prematch>
</decoder>

<decoder name=”windows-sub1″>
<type>windows</type>
<parent>windows</parent>
<regex offset=”after_parent”>^\.+: (\w+)\((\d+)\): (\.+): </regex>
<regex>(\.+): \.+: (\S+): </regex>
<order>status, id, extra_data, user, system_name</order>
<fts>name, location, user, system_name</fts>
</decoder>

<decoder name=”windows-sub1″>
<type>windows</type>
<parent>windows</parent>
<regex offset=”after_regex”>Source Network Address: (\S+)</regex>
<order>srcip</order>
</decoder>

<decoder name=”windows-sub1″>
<type>windows</type>
<parent>windows</parent>
<regex offset=”after_regex”>Source IP Address: (\S+)</regex>
<order>srcip</order>
</decoder>

You see that all of them are named “windows-sub1″ and none of them have a prematch. Another option is to use the “after_regex” in the offset so OSSEC won’t check the whole string again…

bookmark_borderBlocking repeated offenders with OSSEC

By default OSSEC has a static timeout on our active response scripts. You specify the action and how long to block the IP Address:

<active-response>
<command>host-deny</command>
<location>local</location>
<level>6</level>
<timeout>600</timeout>
</active-response>

Which works well for most of the time. However, if you need to increase the timeout for repeated offenders (say the same IP trying to brute force your server all the time), you would have to do this manually.

To solve this problem, we added a new option to the active response config (repeated_offenders):

<active-response>
<repeated_offenders>30,60,120</repeated_offenders>
</active-response>

It allows you to specify a comma separated list of timeouts per re-incidence (in minutes). So the first time an IP is blocked it would use the default timeframe (600 seconds). If it gets blocked again, it would use the first entry in the <repeated_offenders> list (30 minutes = 1800 seconds), then 60 minutes and then 120 minutes… Anything above that would use the latest entry.

To use this option, you have to download the latest snapshot from: http://bitbucket.org/dcid/ossec-hids (just click on get source).

bookmark_borderAutomatically creating and setting up the agent keys

The complain I hear more often about OSSEC is related to how hard it is to setup the authentication keys between the agents and the manager. Each agent share a key-pair with the manager, so if you have a thousand agents, you need a thousand keys.

To make life easier, we added a new daemon on the manager, called ossec-authd. To get that working, you need the latest snapshot (just get from here:https://bitbucket.org/dcid/ossec-hids (click on get source)).

Once you have the new version running, you need to create the certificate / private key for SSL (note that OSSEC will look at /var/ossec/etc/sslmanager.cert and /var/ossec/etc/sslmanager.key for them).

# openssl genrsa -out /var/ossec/etc/sslmanager.key 2048
# openssl req -new -x509 -key /var/ossec/etc/sslmanager.key -out /var/ossec/etc/sslmanager.cert -days 365

*note that you only need to run this command on the manager (not on the agents)

Once the keys are created, you can start the ossec-authd:

# /var/ossec/bin/ossec-authd -p 1515 >/dev/null 2>&1 &

Setting up the agents

On the agents, the work is minimal. All you have to do is to run the following command:

# /var/ossec/bin/agent-auth -m 192.168.1.1 -p 1515

INFO: Connected to 192.168.1.1:1515
INFO: Using agent name as: melancia
INFO: Send request to manager. Waiting for reply.
INFO: Received response with agent key
INFO: Valid key created. Finished.
INFO: Connection closed.

Where 192.168.1.1 is your manager IP address. Inside the manager, you will also see the logs:

2011/01/19 15:04:40 ossec-authd: INFO: New connection from 192.168.10.5
2011/01/19 15:04:41 ossec-authd: INFO: Received request for a new agent (melancia) from: 192.168.10.5
2011/01/19 15:04:41 ossec-authd: INFO: Agent key generated for melancia (requested by 192.168.10.5)
2011/01/19 15:04:41 ossec-authd: INFO: Agent key created for melancia (requested by 192.168.10.5)

That’s it. The keys are now exchanged and you can start your agent. Note that I don’t recommend to keep the ossec-authd running during “normal” operations, only when you are setting up your agents.

The code is still in alpha/beta mode, so let us know if you find any issues (I have been using for a little while, so should be stable).

bookmark_borderProcess monitoring with OSSEC

We love logs. Inside OSSEC we treat everything as if it was a log and parse it appropriately with our rules. However, some information is not available in log files but we still want to monitor them. To solve that gap, we added the ability to monitor the output of commands via OSSEC and treat those just like they were log files.

For example, if you wanted to monitor the disk space utilization, you would need to setup a cron job to dump the output of “df -h” to a log file (maybe /var/log/df.log) and configure OSSEC to look at it.

*use the latest snapshot if you want to try it out: http://www.ossec.net/files/snapshots/ossec-hids-091105.tar.gz

Now, with the new version of OSSEC you can do it directly in there with the following configuration:

<localfile>
<log_format>command</log_format>
<command>df -h</command>
</localfile>

Since we already have a sample rule for df -h included into OSSEC you would see the following when any partition reached 100%:

** Alert 1257451341.28290: mail – ossec,low_diskspace,
2009 Nov 05 16:02:21 (home-ubuntu) 192.168.0.0->df -h
Rule: 531 (level 7) -> ‘Partition usage reached 100% (disk space monitor).’
Src IP: (none)
User: (none)
ossec: output: ‘df -h’: /dev/sdb1 24G 12G 11G 100% /var/backup

Another example, if you want to monitor the load average, you can configure OSSEC to monitor the “uptime” command and alert when it is higher than 2, for example:

<localfile>
<log_format>command</log_format>
<command>uptime</command>
</localfile>

And in the rule:

<rule id=”100101″ level=”7″ ignore=”7200″>
<if_sid>530</if_sid>
<match>ossec: output: ‘uptime’: </match>
<regex>load averages: 2.</regex>
<description>Load average reached 2..</description>
</rule>

Lots of possibilities with this feature. If you have ideas of commands to monitor and rules, please comment.

bookmark_borderDetecting USB Storage Usage with OSSEC

Xavier wrote a very interesting article on Detecting USB Storage Usage with OSSEC. He used our policy auditing module for that, but I think USB monitoring can be done in a much easier way with our new check_diff feature. You need our latest snapshot for it to work (or wait until v2.4 is out).

To get started, first configure your Windows agents to monitor the USBSTOR registry entry using the reg command:

<agent_config os="windows">
  <localfile>
    <log_format>full_command</log_format>
    <command>reg QUERY HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR</command>
  </localfile>

</agent_config>

Next create a local rule for that command:

<rule id="140125" level="7">
    <if_sid>530</if_sid>
    <match>ossec: output: 'reg QUERY</match>
    <check_diff />
    <description>New USB device connected</description>
  </rule>

Now after a few minutes you will see a directory at /var/ossec/queue/diff/[agent_name]/[rule_id] with the current snapshot of this command. Once someone adds a new USB device you will get this alert:

** Alert 1268687754.35062: mail  - local,syslog,
2010 Mar 15 18:15:54 (xx-netbook) any->reg QUERY HKLMSYSTEMCurrentControlSetEnumUSBSTOR
Rule: 140125 (level 7) -> 'New USB device connected'
Src IP: (none)
User: (none)
ossec: output: 'reg QUERY HKLMSYSTEMCurrentControlSetEnumUSBSTOR':! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTOR
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_&Prod_USB_Flash_Memory&Rev_5.00
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Generic&Prod_Flash_Disk&Rev_8.0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Hitachi&Prod_HTS543225L9A300&Rev_
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_LEXAR&Prod_JD_FIREFLY&Rev_1100
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_SAMSUNG&Prod_HM160JC&Rev_0000
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Sony&Prod_DSC&Rev_1.00
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_TomTom&Prod_ONE_XXL_IQ_Rts
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_USB_2.0&Prod_USB_Flash_Drive&Rev_0.00

Previous output:

ossec: output: 'reg QUERY HKLMSYSTEMCurrentControlSetEnumUSBSTOR':
! REG.EXE VERSION 3.0
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTOR
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_&Prod_USB_Flash_Memory&Rev_5.00
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Generic&Prod_Flash_Disk&Rev_8.07
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Hitachi&Prod_HTS543225L9A300&Rev_
HKEY_LOCAL_ACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_SAMSUNG&Prod_HM160JC&Rev_0000
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_Sony&Prod_DSC&Rev_1.00
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_TomTom&Prod_ONE_XXL_IQ_Rts
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSBSTORDisk&Ven_USB_2.0&Prod_USB_Flash_Drive&R

I think we can expand this to create all sort of nice rules…

bookmark_borderAlerting when a log or output of a command changes

If you want to create alerts when a log or the output of a command changes, take a look at the new <check_diff /> option in the rules (available on the latest snapshot).

To demonstrate with an example, we will create a rule to alert when there is a new port open in listening mode on our server.

First, we configure OSSEC to run the ‘netstat -tan |grep LISTEN’ command by adding the following to ossec.conf:

<localfile>
  <log_format>full_command</log_format>
  <command>netstat -tan |grep LISTEN|grep -v 127.0.0.1</command>
</localfile>

After that, I add a rule to alert when its output changes:

<rule id="140123" level="7">
  <if_sid>530</if_sid>
  <match>ossec: output: 'netstat -tan |grep LISTEN</match>
  <check_diff />
  <description>Listened ports have changed.</description>
</rule>

Note that we use the <check_diff /> option. The first time it receives the event, it will store in an internal database. Every time it receives the same event, it will compare against what we have store and only alert if the output changes.

In our example, after configuring OSSEC, I started netcat to listen on port 23456 and that’s the alert I got:

OSSEC HIDS Notification.
2010 Mar 11 19:56:30

Received From: XYZ->netstat -tan |grep LISTEN|grep -v 127.0.0.1
Rule: 140123 fired (level 7) -> "Listened ports have changed."
Portion of the log(s):

ossec: output: 'netstat -tan |grep LISTEN|grep -v 127.0.0.1':
tcp4       0      0 *.23456           *.*               LISTEN
tcp4       0      0 *.3306            *.*               LISTEN
tcp4       0      0 *.25              *.*               LISTEN
Previous output:
ossec: output: 'netstat -tan |grep LISTEN|grep -v 127.0.0.1':
tcp4       0      0 *.3306            *.*               LISTEN
tcp4       0      0 *.25              *.*               LISTEN

What do you think? We can probably extend this idea to create very interesting rules…

bookmark_borderDaily email reports

If you want to receive daily email reports (summaries) of your OSSEC alerts, you will like this new feature.

First, start off by downloading the latest snapshot: http://www.ossec.net/files/snapshots/ (get the latest file from there).

Then you will be able to use the “reports” option to configure what alerts do you want to receive summarized by the end of the day (instead of in realtime). You can use the following options:

group: Filter by group
categories: Filter by group (alias to the above)
rule: Filter by rule id
level: Filter by severity
location: Filter by the log location or agent name
srcip: Filter by a source ip
user: Filter by an user name

You can also use the same options with the ‘type=”relation” specified to get the relation between fields. For example <srcip type=”relation”>user</srcip> will get you a list of users per source ip.

Every report must have a <title> specified and as many “email_to” as you want.

Example 1: Receive summary of all the authentication success:

<ossec_config>
<reports>
<category>authentication_success</category>
<user type=”relation”>srcip</user>
<title>Daily report: Successful logins</title>
<email_to>me@myemail .com</email_to>
</reports>
</ossec_config>

Example 2: Receive summary of all File integrity monitoring (syscheck) alerts:

<ossec_config>
<reports>
<category>syscheck</category>
<title>Daily report: File changes</title>
<email_to>me@myemail .com</email_to>
</reports>
</ossec_config>

Please try it out and let us know if you have suggestions or find any bugs…

bookmark_borderUsing OSSEC for the forensic analysis of log files

OSSEC works well for real time analysis of log files. However, if you have one old log file that you want to check or if you are doing a forensics analysis of a box and wants to check the logs with OSSEC, we now have a solution too.

*the feature mentioned in here is only available on latest snapshots

Let’s say you have a file /var/log/secure that you want to analyze with OSSEC. You need to use the ossec-logtest tool with the “-a” flag to reproduce the alerts:

# cat /var/log/secure | /var/ossec/bin/ossec-logtest -a

** Alert 1264788284.11: – syslog,sshd,authentication_success,
2010 Jan 29 14:04:44 enigma->stdin
Rule: 5715 (level 3) -> ‘SSHD authentication success.’
Src IP: a.b.2.15
User: dcid
Jan 15 10:25:01 enigma sshd[17594]: Accepted password for dcid from a.b.2.15 port 47526 ssh2

** Alert 1264788284.12: – syslog,sshd,authentication_success,
2010 Jan 29 14:04:44 enigma->stdin
Rule: 5715 (level 3) -> ‘SSHD authentication success.’
Src IP: 127.0.0.1
User: dcid
Jan 15 11:19:20 enigma sshd[18853]: Accepted publickey for dcid from 127.0.0.1 port 6725 ssh2

You will get the alerts just like you would at /var/ossec/logs/alerts.log. The benefit now is that you can pipe this output to ossec-reported to get a better view of what is going on:

# cat /var/log/secure | /var/ossec/bin/ossec-logtest -a |/var/ossec/bin/ossec-reported
Report completed. ==
————————————————
->Processed alerts: 522
->Post-filtering alerts: 522

Top entries for ‘Source ip’:
————————————————
89.200.169.170 |41 |
127.0.0.1 |33 |
83.170.106.142 |20 |
204.232.206.109 |16 |
..

Top entries for ‘Username’:
————————————————
root |247 |

Top entries for ‘Level’:
————————————————
Severity 5 |406 |
Severity 3 |41 |
Severity 10 |32 |

Top entries for ‘Group’:
————————————————
syslog |522 |
sshd |509 |
authentication_failed |369 |
invalid_login |146 |

Top entries for ‘Rule’:
————————————————
5716 – SSHD authentication failed. |223 |
5710 – Attempt to login using a non-existent.. |146 |
5715 – SSHD authentication success. |41 |
5702 – Reverse lookup error (bad ISP or atta.. |37 |

To get a report of all brute force attacks (for example) that scanned my box:

# cat /var/log/secure | /var/ossec/bin/ossec-logtest -a |/var/ossec/bin/ossec-reported -f group authentication_failures

Report completed. ==
————————————————
->Processed alerts: 522
->Post-filtering alerts: 25

Top entries for ‘Source ip’:
————————————————
83.170.106.142 |2 |
89.200.169.170 |2 |
114.255.100.163 |1 |
117.135.138.183 |1 |
124.205.62.36 |1 |
173.45.108.230 |1 |
200.182.99.59 |1 |
202.63.160.50 |1 |
210.21.225.202 |1 |
211.151.64.220 |1 |
213.229.70.12 |1 |
218.30.19.48 |1 |
221.12.12.3 |1 |
59.3.239.114 |1 |
61.168.227.12 |1 |
61.233.42.47 |1 |
67.43.61.80 |1 |
72.52.75.228 |1 |
77.245.148.196 |1 |
79.125.35.214 |1 |
85.21.83.170 |1 |
92.240.75.6 |1 |
94.198.49.185 |1 |

Top entries for ‘Username’:
————————————————
root |24 |

Top entries for ‘Level’:
————————————————
Severity 10 |25 |

Top entries for ‘Group’:
————————————————
authentication_failures |25 |
sshd |25 |
syslog |25 |

Top entries for ‘Location’:
————————————————
enigma->stdin |25 |

Top entries for ‘Rule’:
————————————————
5720 – Multiple SSHD authentication failures. |24 |
5712 – SSHD brute force trying to get access.. |1 |

Thanks!

bookmark_borderLearning OSSEC’s agentless monitoring

JD McCloud from Praetorian Prefect wrote two articles that explain very well how the agentless monitoring works on OSSEC.

The first one, OSSEC: Agentless to save the day, explains how to setup and use agentless to monitor any remote device via ssh.

The second one, OSSEC: Agentless scripts, goes a bit deeper and explains how they work internally and how you can make your own scripts for agentless monitoring.

Recommended read for every OSSEC user.

bookmark_borderCreating a separated directory for testing OSSEC rules/config

A question that I often hear is how to use a separated directory for testing OSSEC rules and the configuration.

The easiest way is by doing the follow:

1. Choose the new directory to use as a test-base. In my case it is going to be /tmp/ossectest

2. Create that directory and a few important sub-directories.

# mkdir /tmp/ossectest
# mkdir /tmp/ossectest/etc
# mkdir /tmp/ossectest/queue/
# mkdir /tmp/ossectest/queue/fts
# mkdir /tmp/ossectest/rules

3. Move over your configuration files, rules and decoders

# cp -pr /var/ossec/etc/decoder.xml /tmp/ossectest/etc
# cp -pr /var/ossec/etc/ossec.conf /tmp/ossectest/etc
# cp -pr /var/ossec/rules/* /tmp/ossectest/rules/

4. Run ossec-logtest using the new configuration and rules

# /var/ossec/bin/ossec-logtest -D /tmp/ossectest/ -c /tmp/ossectest/etc/ossec.conf

5. Now you can modify the rules and configuration at /tmp/ossectest before moving over to the real running directory

If there is any error in the rules or in the configuration you will get the message:

# /var/ossec/bin/ossec-logtest -D /tmp/ossectest/ -c /tmp/ossectest/etc/ossec.conf
2009/10/28 12:40:27 ossec-config(1226): ERROR: Error reading XML file ‘/tmp/ossectest/etc/ossec.conf’: XML ERR: Element not closed: globalaa (line 7).
2009/10/28 12:40:27 ossec-testrule(1202): ERROR: Configuration error at ‘/tmp/ossectest/etc/ossec.conf’. Exiting.

Otherwise you will be able to send any logs to logtest to test your rules.