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_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,

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_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 + Snort Active Response

Rodrigo Montoro wrote a very interesting paper on how to execute custom active responses using Snort CVS output and OSSEC. It also shows how to write custom rules and decoders… Good read!

This paper won’t teach you to install or configure snort or OSSEC HIDS, my goal
here is to teach you use snort csv output and build rules at OSSEC for active response.
Ossec must be installed with active-response enabled…

English version: http://www.brc.com.br/artigos/ossec-snort-activeresponse_english.pdf
Portuguese version: http://www.brc.com

bookmark_borderDatabase Logging

Next version of OSSEC will come with support for PostgreSQL logs and MySQL error/query logs. Since database logging is not something widely done (and even hard to find documentation about), I started in the OSSEC wiki some sections about it. If you are interested in database log analysis, please check out the following pages and help us improve them:

If you have information about logging on other databases (Oracle, MS SQL, etc), send some information to us so we can add support for them on ossec.

*This alpha version of 1.4 has the database support enabled for anyone interested to test: http://www.ossec.net/files/snapshots/ossec-hids-070930.tar.gz

bookmark_borderWindows policy monitoring

OSSEC v1.3 will come with support for Windows policy monitoring, allowing you to verify that all your systems conform to a set of policies regarding configuration settings, applications usage, etc. They are configured centrally on the ossec server and pushed down to all your agents.

With the Windows policy monitoring, you can get alerts like the following (detecting Skype and Yahoo):

2007 Jul 22 17:42:57 Rule Id: 514 level: 2
Location: (winhome) 192.168.2.190->rootcheck
Windows application monitor event.

Application Found: Chat/IM – Yahoo.

2007 Jul 22 17:42:57 Rule Id: 514 level: 2
Location: (winhome) 192.168.2.190->rootcheck
Windows application monitor event.

Application Found: Chat/IM/VoIP – Skype.

And compliance alerts like the following:

2007 Jul 23 13:44:54 Rule Id: 512 level: 3
Location: (winhome) 192.168.2.190->rootcheck
Windows Audit event.

Windows Audit: Null sessions allowed.

2007 Jul 23 13:44:54 Rule Id: 512 level: 3
Location: (winhome) 192.168.2.190->rootcheck
Windows Audit event.

Windows Audit: LM authentication allowed (weak passwords).

Interested? Read more how it works here. You can also try our beta version to help us improve it.