bookmark_borderOSSEC on the OLPC

For those looking to install OSSEC on the OLPC (One Laptop per Child), I was able to do it without major issues. Their system is based on the Fedora 7, so I just had to install make, gcc and the libc-headers.
A quick sequence of commands:

# yum -y install gcc make glibc-headers glibc-dev
# wget http://www.ossec.net/files/ossec-hids-1.5.1.tar.gz
# tar -zxvf ossec-hids-1.5.1.tar.gz
# cd ossec-hids-1.5.1
# ./install.sh
..

bookmark_borderSending OSSEC alerts via syslog

This is a feature that was constantly asked and just now I was able to include it. Basically, it allows you to send the OSSEC alerts to one or more syslog servers (granularly).

First, make sure to get the latest snapshot and install it: http://www.ossec.net/files/snapshots/ossec-hids-080725.tar.gz

After that you can configure OSSEC with the syslog servers of your choice. In my example here, I am sending everything to server 192.168.4.1 and only the alerts above level 10 to 10.1.1.1:

<syslog_output>
<server>192.168.4.1</server>
</syslog_output>

<syslog_output>
<level>10</level>
<server>10.1.1.1</server>
</syslog_output>

After that, run the following command and restart OSSEC:

# /var/ossec/bin/ossec-control enable client-syslog
# /var/ossec/bin/ossec-control start

You should see now ossec-csyslog starting:

OSSEC HIDS v1.5.1 Stopped
Starting OSSEC HIDS v1.5.1 (by Third Brigade, Inc.)…
Started ossec-csyslogd…
..

and on the logs:

# tail -n 1000 /var/ossec/logs/ossec.log |grep csyslog
2008/07/25 12:55:16 ossec-csyslogd: INFO: Started (pid: 19412).
2008/07/25 12:55:16 ossec-csyslogd: INFO: Forwarding alerts via syslog to: ’192.168.4.1:514′.
2008/07/25 12:55:16 ossec-csyslogd: INFO: Forwarding alerts via syslog to: ’10.1.1.1:514′.

On the syslog server, this is what you should get (every log separated by level, rule, location and the actual event that generated it):

Jul 25 12:17:41 enigma ossec: Alert Level: 3; Rule: 5715 – SSHD authentication success.; Location: (jul) 192.168.2.0->/var/log/messages; srcip: 192.168.2.190; user: root; Jul 25 13:26:24 slacker sshd[20440]: Accepted password for root from 192.168.2.190 port 49737 ssh2

As always, suggestions and comments are more than welcome. Thanks!

bookmark_borderOSSEC on Microsoft Vista/Server 2008

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.

bookmark_borderCIS benchmark tests

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.

bookmark_borderTesting OSSEC rules

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.

bookmark_borderOSSEC project acquired

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!

bookmark_borderOSSEC v1.5 released

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.

bookmark_borderv1.5 preview – New log rules/decoders

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 🙂

bookmark_borderv1.5 preview – scan_time and scan_day on syscheck

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!