August 2008 – OSSEC

OSSEC mailing list in portuguese

Posted on August 28, 2008July 2, 2020 by Daniel Cid

Rodrigo Montoro created an OSSEC mailing list in Portuguese. More info: http://tech.groups.yahoo.com/group/ossecbr/

Thanks!

v1.6 BETA2 begins

Posted on August 28, 2008July 2, 2020 by Daniel Cid

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:

support for VMware ESX logs.
support for McAfee AV.
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!

Active response on Windows

Posted on August 20, 2008July 2, 2020 by Daniel Cid

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,

Multi-server architecture

Posted on August 18, 2008July 2, 2020 by Daniel Cid

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!

New tool: syscheck_control

Posted on August 7, 2008July 2, 2020 by Daniel Cid

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