bookmark_borderCompiled rules

If you ever wanted a bit more flexibility from the OSSEC rules, you can have it now with the C compiled rules.

Compiled rules are an extension to the normal (default) XML rules and should only be used when you need additional functionality not present in there.

**Note that you need at least the snapshot ossec-hids-081030.tar.gz or v1.7 (not yet available) for it to work.

How the compiled rules work?

Inside the OSSEC package you will find the directory src/analysisd/compiled_rules/ , with the default compiled rules.
To see a list of rules, run the command (inside that directory):

  $ pwd
  ../src/analysisd/compiled_rules
  $ ./register_rule.sh list
  *Available functions:
  check_id_size
  comp_mswin_targetuser_calleruser_diff
  comp_srcuser_dstuser

To use any of them inside a rule, just add the <compiled_rule> tag with the function you want to use. Ex:

 <rule id="100155" level="10">
   <if_sid>18111</if_sid>
   <compiled_rule>comp_mswin_targetuser_calleruser_diff</compiled_rule>
   <description>User changed someone else password.</description>
 </rule>

NOTE: To know what each function does you have to look at the source code.

How to write my own rule

To create your own rule, first open a new .c file (don’t use the generic one, since it is modified during upgrades).

  $ touch myownrules.c

And create your function inside of it. In this example here we added a function to check if the url field is longer than 1024:

void *myosrule_check_url_size1024(Eventinfo *lf)
{
    if(!lf->url)
    {
        return(NULL);
    }

    if(strlen(lf->url) >= 1024)
    {
        return(lf);
    }
    return(NULL);
}

Note 1: You must return ‘lf’ (the eventinfo structure) if the function matches or NULL otherwise.
Note 2: Give a good name to your function in a way to make sure it is not used anywhere else (eg: put your company name in it).
After that, register your function:

  $ ./register_rule.sh add myosrule_check_url_size1024

You can also save it (if you have ossec installed) so that during the next upgrade it will reuse them:

  $ ./register_rule.sh save
  *Save completed at /var/ossec/compiled_rules/

bookmark_borderOSSEC presentation at Ottsec

Last month I did a presentation about OSSEC for the Ottawa security group and showed some custom rules that I have been using for a while (to monitor MSN usage, internal http user agents, etc). The core of the presentation starts at slide 11, if you want to skip through the definitions of HIDS, OSSEC, etc.

Link: http://ossec.net/ossec-docs/ossec-ottsec.pdf

bookmark_borderOSSEC v1.6.1 released

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


We are pleased to announce the general availability of OSSEC version 1.6.1. This is a small version with bug fixes for some issues found on v1.6.

For a list of features in the version 1.6, please visit: OSSEC v1.6 released.

For a list of issues that were solved, visit the Changelog.

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

Thanks!

bookmark_borderOSSEC v1.6 released

Direct from: http://www.ossec.net/main/ossec-v16-released


We are pleased to announce the general availability of OSSEC version 1.6.
This new version delivers the most comprehensive update to OSSEC in its history, with numerous new features and bug fixes, including:

  • New multi-server architecture
  • New platform support for Microsoft Vista (and Server 2008)
  • New platform support for VMware ESX
  • Added active response module for Windows
  • CIS benchmarks on Linux (through the policy auditing)
  • Added the VMWare Security hardening guideline to the policy auditing
  • Added support for McAfee VirusScan Enterprise logs
  • Added support for VMware ESX hostd logs
  • Added support for Mac OS FTP server logs
  • New tools to better manage the data stored (syscheck_control, rootcheck_control, log_test)

And much more… Check the changelog to see all changes and contributors.

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

Special thanks to Michael Starks, Chris Buechler and Joachim Vorrath for the contributions and ChuckD (mdmonk), Daniel Medianero and John Ives for beta testing this release.

bookmark_borderv1.6 BETA2 begins

If you would like to contribute to the project and don’t know how, beta testing our version 1.6 might be a good way to get started.

The list of new features, bug fixes and packages to use are all available at: http://www.ossec.net/wiki/index.php/Dev:BetaTesting

From BETA1, very little has changed, but we added:

  1. support for VMware ESX logs.
  2. support for McAfee AV.
  3. Fixed some bugs in the policy scanning and other parts of the system.

If you run into any issues, please let us know. Thanks for testing!

bookmark_borderActive response on Windows

Another big feature that we never got around to implement until now. For version 1.6, OSSEC will come with the route-null.cmd script to block an IP address on Windows by modifying the route to it.

To get started, you will need at least the snapshot http://www.ossec.net/files/snapshots/ossec-win32-080820.exe
and the latest snapshot for the management server too.

With that installed, you need to enable active response on Windows (disabled by default). To do that, just add the following to the agent’s ossec.conf:

<active-response>
<disabled>no</disabled>
</active-response>

After that, you need to go to the manager and specify when to run the response. Adding the following to ossec.conf will enable the responses for alerts above level 6:

<command>
<name>win_nullroute</name>
<executable>route-null.cmd</executable>
<expect>srcip</expect>
<timeout_allowed>yes</timeout_allowed>
</command>

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

With the configuration completed (and the manager restarted), you can test the active response by running the agent-control script (in this case, I am running it on agent id 185 to block ip 2.3.4.5):

/var/ossec/bin/agent_control -L

OSSEC HIDS agent_control. Available active responses:

Response name: host-deny600, command: host-deny.sh
Response name: firewall-drop600, command: firewall-drop.sh
Response name: win_nullroute600, command: route-null.cmd

/var/ossec/bin/agent_control -b 2.3.4.5 -f win_nullroute600 -u 185

OSSEC HIDS agent_control: Running active response ‘win_nullroute600′ on: 185

And looking at the agent you should see the new entry in the route table:

C:>route print
..
Active Routes:
Network Destination Netmask Gateway Interface Metric
2.3.4.5 255.255.255.255 x.y.z x.y.z 1
..

If you run into any issues, look at the ossec.log file (on the agent) for any entry for ossec-execd. If you enabled it correctly, you will see:

2008/08/20 11:53:49 ossec-execd: INFO: Started (pid: 3896).

As always, we are very open to suggestions, comments, bug reports, etc.

Thanks,

bookmark_borderMulti-server architecture

This is another feature that has been asked constantly for a long time and just now we got around to implement it.

The idea is to allow one OSSEC server (manager) to parse the alerts from another one, creating a hierarchy of multiple servers being able to forward all their data to a central one.

Something like this:

agent11 -> ossec-server-1 -> ossec-central <- ossec-server2 <- agent21

This bug explain the idea as well: http://www.ossec.net/bugs/show_bug.cgi?id=24

For version 1.6, you will be able to do that by forwarding the OSSEC alerts from one server to another via syslog. In the future, I plan to expand that to use the same communication channel (encrypted, compressed, etc) that we use for the agent communication. However, for now you will need to use syslog (or install an agent in the server itself –both should work).

To have the syslog working, you need to add the following on the “client manager”:

<syslog_output>
<server>142.167.90.213</server>
<port>1515</port>
</syslog_output>

And enable client-syslog:

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

On the central server, you need to enable remote syslog (note that I am using port 1515 instead of 514):

<remote>
<connection>syslog</connection>
<port>1515</port>
<allowed-ips>192.168.2.0/24</allowed-ips>
<allowed-ips>192.168.1.0/24</allowed-ips>
</remote>

When this is done, you should start getting the alerts from all your servers (and agents) into the central one:

** Alert 1219087291.31744: mail – ossec,
2008 Aug 18 16:21:31 QA-XXX-1->1Z.YY.253.226|QA-XXXX-1->ossec-monitord
Rule: 502 (level 3) -> ‘Ossec server started.’
ossec: Ossec started.

Note that the location will be pipe (“|”) separated. If you have any questions or suggestions, please let us know.

Thanks!

bookmark_borderNew tool: syscheck_control

Recently I have been focused on trying to make OSSEC more friendly and easier to manage. Last version (1.5) we added the agent_control tool (to manage the agents remotely), and for the v1.6, one of the new features is the syscheck_control.

Basically, it allows you to manage the integrity checking database that is stored on the server (manager) side. You can list the modified files, get detailed information from each change and even ignore a specific file or zero its auto-ignore counter.

*To test it, you will need to get the latest development package (snapshot) available at: //www.ossec.net/files/snapshots/ossec-hids-080807.tar.gz

How to use it? Let’s look at some examples:

Example 1: Getting help and listing all available agents

Exactly like the agent_control, you can use the “-l” (or -lc) flag to list the agents and the “-h” flag to get the command line help.

/var/ossec/bin/syscheck_control -h

OSSEC HIDS syscheck_control: Manages the integrity checking database.
Available options:
-h This help message.
-l List available (active or not) agents.
-lc List only active agents.
-u <id> Updates (clear) the database for the agent.
-u all Updates (clear) the database for all agents.
-i <id> List modified files for the agent.
-r -i <id> List modified registry entries for the agent (Windows only).
-f <file> Prints information about a modified file.
-z Used with the -f, zeroes the auto-ignore counter.
-d Used with the -f, ignores that file.
-s Changes the output to CSV (comma delimited).

/var/ossec/bin/syscheck_control -lc

OSSEC HIDS syscheck_control. List of available agents:
ID: 000, Name: enigma.ossec.net (server), IP: 127.0.0.1, Active/Local
ID: 165, Name: esqueleto2, IP: 192.168.2.99, Active
ID: 174, Name: lili3win, IP: 192.168.2.0/24, Active
ID: 185, Name: winhome2, IP: 192.168.2.0/24, Active

Example 2: Getting a list of modified files

To get a list of the modified files, just run the command with the “-i” flag followed by the agent id you want:

/var/ossec/bin/syscheck_control -i 165

Integrity changes for agent ‘esqueleto2 (165) – 192.168.2.190′:

Changes for 2007 Sep 12:
2007 Sep 12 21:54:37,0 – /var/ossec/etc/ossec.conf
2007 Sep 12 21:54:37,0 – /var/ossec/etc/internal_options.conf
2007 Sep 12 22:01:36,0 – /etc/group-
2007 Sep 12 22:01:40,0 – /etc/ld.so.cache
2007 Sep 12 22:01:47,0 – /etc/passwd-
2007 Sep 12 22:01:48,0 – /etc/syslog.conf

Changes for 2007 Sep 13:
2007 Sep 13 00:15:17,0 – /etc/postgresql/8.1/main/log

..

Changes for 2008 Jul 24:
2008 Jul 24 12:47:55,0 – /etc/syslog.conf
2008 Jul 24 12:47:57,0 – /etc/resolv.conf
2008 Jul 24 15:03:27,3 – /etc/ld.so.cache

Example 3: Getting more information about a file change

To get a more detailed view of the changes on a specific file, run the same command as above plus the “-f” flag. In the following example we are looking at the resolv.conf file changes:

/var/ossec/bin/syscheck_control -i 165 -f resolv

Integrity changes for agent ‘esqueleto2 (165) – 192.168.2.190′:
Detailed information for entries matching: ‘resolv’

2007 Sep 12 22:01:48,0 – /etc/resolv.conf
File added to the database.
Integrity checking values:
Size: 53
Perm: rw-r–r–
Uid: 0
Gid: 0
Md5: 14f49f5a229b80d555100ddab80e42ab
Sha1: 0aa08a3fba0b0b8bb926cdb8ee5f2af27c947cbf

2008 Jul 24 12:47:57,0 – /etc/resolv.conf
File changed. – 1st time modified.
Integrity checking values:
Size: >54
Perm: rw-r–r–
Uid: 0
Gid: 0
Md5: >ba9ce771e9d760f58ffd30e4ecda669a
Sha1: >ce9dbec2368e8e35dea76df9b623824628045dcb

Example 4: Ignoring or clearing the auto-ignore flags

OSSEC by default will ignore files that change too often. You can disable this feature by setting <auto_ignore> to “no” in the main config, but sometimes you may want to keep this feature on and deal with each file separately.

In this example, the file squid.conf is being auto-ignored. To remote this flag, just run the same command as above with the “-z” flag:

/var/ossec/bin/syscheck_control -i 165 -f “/squid.conf”

2008 Jun 26 22:48:26,4 – /etc/squid/squid.conf
File changed. – Being ignored (3 or more changes).
Integrity checking values:
Size: 120362
Perm: rw——-
Uid: 0
Gid: 0
Md5: >a0038eaf46f13cdbbc09c4c1e4994374
Sha1: >3e732bcee538f20f02a602b0aec36bbe2fd3617b

/var/ossec/bin/syscheck_control -i 165 -f “/squid.conf” -z

Integrity changes for agent ‘esqueleto2 (165) – 192.168.2.190′:
Detailed information for entries matching: ‘/squid.conf’

**Counter updated for file ‘/etc/squid/squid.conf’

# /var/ossec/bin/syscheck_control -i 165 -f “/squid.conf”

2008 Jun 26 22:48:26,0 – /etc/squid/squid.conf
File changed. – 1st time modified.
Integrity checking values:
Size: 120362
Perm: rw——-
Uid: 0
Gid: 0
Md5: >a0038eaf46f13cdbbc09c4c1e4994374
Sha1: >3e732bcee538f20f02a602b0aec36bbe2fd3617b

If you are dealing with the registry files on Windows, make sure to add the “-r” flag to all these commands.

As always, suggestions, bug reports and comments are more than welcome!

Thanks,