OSSEC v2.5 released

OSSEC v2.5 is out. From http://www.ossec.net/main/ossec-v25-released:


We are very happy to announce the availability of OSSEC version 2.5.

This has been a long release cycle (5 months), but it comes out pretty stable and with many new features. We also had many contributors, showing how much our community is growing and getting stronger. In addition to that, our documentation and manual has been moved to http://www.ossec.net/doc/ .

What is new?

  1. Added support for “report_changes” on syscheck to show what was changed in the file modification alert.
  2. Added support for cdb lists inside the rules.
  3. Added support for drop-in rules and decoders directory.
  4. Added a Rule unit testing framework (in python) and inside logtest
  5. Added support for a generic multi-line log reader.
  6. Added granular Windows rules.
  7. Added option to restrict integrity checking to a set of files.
  8. Added alias option to the command monitoring.
  9. Added silent switch for windows installer.
  10. Added variable expansion in command output monitoring.
  11. Fixed several windows installer bugs.

And a lot more. Check the full change log here.

Download the new version from http://www.ossec.net/main/downloads

*Special thanks to Jeremy Rossi, Dan Parriott, Scott R. Shinn and Michael Starks for the many contributions, patches and tests.

Posted in ossec, v2.5 | Leave a comment

OSSEC v2.4 released

Directly from: http://www.ossec.net/main/ossec-v24-released:

The OSSEC team is very happy to announce the general availability of OSSEC version 2.4.

What is new? We have lots of new features and bug fixes, but these are the main changes:

  1. Added daily email summaries/reports. (more info)
  2. Added option to alert when a log or command output changes – check_diff. (more info)
  3. Added rules to ignore crawlers causing 404s (MSN, Google, Yahoo, etc).
  4. Improved ossec-logtest to be used for the forensic analysis of log files (more info)
  5. Added support for Microsoft Security Essentials logs.

And a few important bug fixes:

  • Fixed a memory leak on the Windows agent that was not properly closing the sockets. It would cause a port exhaustion if the manager becames unavailable
    for a long period of time.
  • Fixed performance issue when the FTS queue was too large.

Check out our v2.4 changelog for the complete list of new features and bugs fixed.

Download the new version from http://www.ossec.net/main/downloads

Posted in ossec, v24 | Leave a comment

OSSEC v2.4 BETA available

OSSEC v2.4 BETA is available and we need testers. You can find more information about it and new features in here:

http://www.ossec.net/wiki/Dev:BetaTesting

If you ever wanted to contribute to OSSEC (or to any open source project) that’s the easiest way to get involved. Just download the BETA, check if everything still works, if you have time try out some of the new features and let us know how it goes. You can submit your feedback in here, via the wiki, to the mailing list or personally to me via email.

http://www.ossec.net/wiki/Dev:BetaTesting

We appreciate any feedback.

Posted in ossec, v24 | 1 Comment

Site down last night

Thanks to everyone who sent some notes that our site was down last night. We were switching servers and not everything got migrated on time. I was happy that sucuri notified my on time:

Modifications:
%WARN: Size reduced by more than 50%. – Previous size: 2761. Current size: 984 (in bytes)
%INFO: Server setting changes – > <title>WordPress › Error
%ERROR: Error establishing a database connection
Changes follow:

14,20c14
< <title>
< Welcome to the Home of OSSEC
..
> Error establishing a database connection

They have a nice solution that does integrity checking on web sites, domains, etc. That was the other alert I got:

Sucuri nbim: http://www.ossec.net DNS modified

Modifications:
5d4
< ossec.net has address 75.126.x.z
> ossec.net has address 74.86.x.z

Posted in ossec | Leave a comment

Detecting 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&Rev_0.00

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

Posted in ossec | 1 Comment

Alerting 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…

Posted in ossec | 1 Comment

Daily 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…

Posted in ossec | 2 Comments

Community Updates

Directly from: http://www.ossec.net/main/community-updates:

The OSSEC community is on fire lately! We are very happy to see everyone talking and presenting about OSSEC. Those are some of the newest updates from our community:

Wim Remes spoke about OSSEC at the Fosdem conference. The video of his presentation is on youtube:

 
Iñaki Rodríguez fromvirtualminds.es did a webmeeting about OSSEC in spanish. Slides in PDF:
http://www.virtualminds.es/uploads/charlas/ossec-slides.pdf

 
Wim Remes (yes, he again), wrote about OSSEC for the [IN]SECURE Magazine (2010 February edition):
http://www.net-security.org/insecuremag.php

 
Michael Starks from immutablesecurity.com posted a few interesting blog posts about OSSEC:

Using OSSEC for Encrypted Log Transport
Detecting Sensitive Info with OSSEC

Have you wrote something about OSSEC? Please, let us know and we will add in here.

Posted in ossec, presentation | Leave a comment

New member of the OSSEC team

Priscila

I am happy to announce the arrival of the newest member of the OSSEC team. Priscila Cid joined our team yesterday and even though she is only 50 cm tall, she is already very active and doing very well.

Posted in ossec | Leave a comment

Using 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!

Posted in log analysis, ossec | 1 Comment