I just finished adding support for Vista/Server 2008 on OSSEC. We had some server(manager)-side changes to understand the new events ids and lots of changes on the agent side. If you have any Vista or Server 2008, please help us test it.

You can download the server at: http://www.ossec.net/files/snapshots/ossec-hids-080721.tar.gz
Agent download at: http://www.ossec.net/files/snapshots/ossec-win32-080721.exe

Make sure to update the server first, before the agent. If you find any issues, or if you test and it works fine, please let me know.

*I would also like to thank Chris Buechler for the remote access to some of his boxes to make this possible.

We just included support in the OSSEC Policy monitor to audit if a system is in compliance with the CIS Security Benchmarks (as of right now, only RHEL2-5, Fedora 1-5 and Debian/Ubuntu are supported - the other versions will be soon).

If you want to try it out manually and provide some feedback to us, please follow the instructions bellow to test:

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-080710.tar.gz
# tar -zxvf ossec-hids-080710.tar.gz
# cd ossec-hids-080710/src/
# make clean
# make libs
# cd rootcheck
# make binary

The binary ossec-rootcheck will be created on the current directory and we can start using it. A simple scan on my Ubuntu box looked like this: (note, that it will do all the normal rootcheck tests plus the CIS scans — just grep for CIS if you don’t want to see the rest):

# ./ossec-rootcheck
..

[INFO]: System Audit: CIS - Testing against the CIS Debian Linux Benchmark v1.0. File: /proc/sys/kernel/ostype. Reference: http://www.ossec.net/wiki/index.php/CIS_DebianLinux .

[INFO]: System Audit: CIS - Debian Linux 1.4 - Robust partition scheme - /tmp is not on its own partition. File: /etc/fstab. Reference: http://www.ossec.net/wiki/index.php/CIS_DebianLinux .

[INFO]: System Audit: CIS - Debian Linux 1.4 - Robust partition scheme - /var is not on its own partition. File: /etc/fstab. Reference: http://www.ossec.net/wiki/index.php/CIS_DebianLinux .

[INFO]: System Audit: CIS - Debian Linux 2.3 - SSH Configuration - Root login allowed. File: /etc/ssh/sshd_config. Reference: http://www.ossec.net/wiki/index.php/CIS_DebianLinux .

[INFO]: System Audit: CIS - Debian Linux 2.4 - System Accounting - Sysstat not enabled. File: /etc/default/sysstat. Reference: http://www.ossec.net/wiki/index.php/CIS_DebianLinux .

[INFO]: System Audit: CIS - Debian Linux 4.18 - Disable standard boot services - Squid Enabled. File: /etc/init.d/squid. Reference: http://www.ossec.net/wiki/index.php/CIS_DebianLinux .

[INFO]: System Audit: CIS - Debian Linux 7.2 - Removable partition /media without ‘nodev’ set. File: /etc/fstab. Reference: http://www.ossec.net/wiki/index.php/CIS_DebianLinux .

[INFO]: System Audit: CIS - Debian Linux 7.2 - Removable partition /media without ‘nosuid’ set. File: /etc/fstab. Reference: http://www.ossec.net/wiki/index.php/CIS_DebianLinux .

[INFO]: System Audit: CIS - Debian Linux 7.3 - User-mounted removable partition /media. File: /etc/fstab. Reference: http://www.ossec.net/wiki/index.php/CIS_DebianLinux .

[INFO]: System Audit: CIS - Debian Linux 8.8 - GRUB Password not set. File: /boot/grub/menu.lst. Reference: http://www.ossec.net/wiki/index.php/CIS_DebianLinux .

..

Anyone here using CIS (or FDCC)? As always, feedback and suggestions are welcome.

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.

A bit of late news, but OSSEC version 1.5.1 was released last week. More information at http://www.ossec.net/main/ossec-v151-released

I have very good news to share. Hope you all like it

First, from now I will be working full time on OSSEC, being fully
sponsored (and paid) by Third Brigade. As some of you know, for the last few years I have been working on OSSEC as a “second job”, during the evenings and at night, so hopefully now with more time we will see some awesome improvements in a short period of time (let’s clear our bugzilla :)).

Plus, the code will remain open source (GPL), and the project will continue running the way it is now (with a few improvements), so there is nothing to worry about.

Secondly, Third Brigade (same company sponsoring me to work full time on it), also acquired the project. That means that they will put more resources to work on the project and help us bring it to the next level. For the average user it will not change anything, but for any company interested in getting an enterprise-level support and additional commercial offerings (training, professional services, etc), it will be a huge benefit.

To clear up any questions you may have:

• Yes, I WILL remain working 100% on the project!
• The code WILL remain open source and community driven!

More information can be found on the FAQ about the acquisition:
http://www.ossec.net/main/acquisition-faq/

Press release:
http://www.thirdbrigade.com/news_events.aspx?id=770

Feel free to ask any questions you may have.

Thanks!

From http://www.ossec.net/main/ossec-v15-released :

We are very pleased to announce the general availability of OSSEC version 1.5. This version comes with lots of bug fixes and new features, including:

-New log formats (info):

• Solaris BSM auditing logs
• Asterisk logs
• Checkpoint and Smart Defense logs
• Debian package (dpkg) install/status/remove messages
• Shorewall logs
• Postfix SASL error messages
• Localized pure-ftpd messages (for 12 different languages)
• DJB multilog

-Greek translation of the install.

-Added agent_control tool to manage the agents directly from the server (info).

-New options to syscheckd/rootcheckd to better schedule the scans (info).

-Performance improvements to the Windows Agent, specially when dealing with
large event logs.

-Added new options to Rootcheck to look for common web exploits installed
on the system (used to attack others).

Check the v1.5 Changelog to see all the changes and contributors.

Download it from: http://www.ossec.net/main/downloads .

Special thanks to Martin West, Sebastien Tricaud, Giannis Vrentzos, Sandro Gauci, Michael Starks, Cedric Bleimling, Dean Takemori and Dennis Golden for the contributions and John Lewis, Daniel Medianero, John Ives and Derek Morris for beta testing this release.

Version 1.5 comes with lot of additions to our log analysis (or LIDS - Log-based IDS) capabilities. Some of the new log formats we now support are:

• Solaris BSM auditing logs
• Asterisk logs
• Checkpoint and Smart Defense logs
• Debian package (dpkg) install/status/remove messages
• Shorewall logs
• Postfix SASL error messages
• Localized pure-ftpd messages (for 12 different languages)

In addition to that, we can now properly read DJB multilog files and read them with our decoders. To read it, just add to the configuration (in this example to read sshd logs):

<localfile>
<log_format>djb-multilog</log_format>
<location>/var/log/sshd/current</location>
</localfile>

Hope you enjoy OSSEC v1.5 when it is out

This is a feature that have been requested for a while and now is finally available. In the past, the only way to specify when rootcheck/syscheck was supposed to run was based on the frequency (every 10 hours or every 2 days, for example).

The default configuration would always look like:

<syscheck>
..
<frequency>86000</frequency>
..
</syscheck>

On version 1.5, we have two additional options: scan_time and scan_day. They allow you to run the scans on specific times or days of the week.

Example 1: Running syscheck/rootcheck every day at 11pm:

<syscheck>
..
<scan_time>23:00</scan_time>
..
</syscheck>

Example 2: Running syscheck/rootcheck tuesday, thursday and saturday at 9:30pm:

<syscheck>
..
<scan_time>9:30pm</scan_time>
<scan_day>tuesday, thursday, saturday</scan_day>
..
</syscheck>

Note that when you use scan_time and scan_day, the frequency is not going to be used. Hope you enjoy!

Version 1.5 will come with a new utility binary, called agent_control (by default located at /var/ossec/bin/agent_control ).

Basically, it allows you to query and get information from any agent you have configured on your server and it also allows you to restart (run now) the syscheck/rootcheck scan on any agent.

How it works? The first interesting command is “-lc”, to list the connected (active agents). To list all of them, use “-l” only.

Example 1: Listing all active agents:

# /var/ossec/bin/agent_control -lc
OSSEC HIDS agent_control. List of available agents:
ID: 000, Name: enigma.ossec.net (server), IP: 127.0.0.1, Active/Local
ID: 002, Name: winhome, IP: 192.168.2.190, Active
ID: 005, Name: jul, IP: 192.168.2.0/24, Active
ID: 165, Name: esqueleto2, IP: 192.168.2.99, Active
ID: 174, Name: lili3win, IP: 192.168.2.0/24, Active

To query an agent, just use the “-i” option followed by the agent id.

Example 2: Querying information from agent 002:

# /var/ossec/bin/agent_control -i 002

OSSEC HIDS agent_control. Agent information:
Agent ID: 002
Agent Name: winhome
IP address: 192.168.2.190
Status: Active

Operating system: Microsoft Windows XP Professional (Build 2600)
Client version: OSSEC HIDS v1.5-SNP-080412
Last keep alive: Fri Apr 25 14:33:03 2008

Syscheck last started at: Fri Apr 25 05:07:13 2008
Rootcheck last started at: Fri Apr 25 09:04:12 2008

To execute the syscheck/rootcheck scan immediately, use the “-r” option followed by the “-u” and the agent id.

Example 3: Executing syscheck and rootcheck scan immediately:

# /var/ossec/bin/agent_control -r -u 000

OSSEC HIDS agent_control: Restarting Syscheck/Rootcheck locally.

For more information, just run it with the “-h” option:

# /var/ossec/bin/agent_control -h

OSSEC HIDS agent_control: Control remote agents.
Available options:
-h This help message.
-l List available (active or not) agents.
-lc List active agents.
-i Extracts information from an agent.
-r -a Runs the integrity/rootkit checking on all agents now.
-r -u Runs the integrity/rootkit checking on one agent now.

-s Changed the output to CSV (comma delimited).

OSSEC is part of the Hackontest, a 24-hour programming marathon
and we are looking for contributions…

First, you can register to request features that we would develop during this 24-hour period. I already added a couple, but the more the better. Second, you can vote on the submitted features and the one that receives more votes is going to be chosen.

Our page is at:
http://www.hackontest.org/index.php?action=Root-projectDetail(32)

If you are a developer, you can click on a feature and choose to help to implement it… If we are chosen, our team (whosoever registers to implement it) is going to Switzerland for the contest!

So, votes, features, ideas and developers are welcome..