OSSEC for Centralizing Security Incidents

by J. Edward Durrett

OSSEC / IDS / Security / FreeBSD

OSSEC is a host based intrusion detection system which centralizes logs and system
information across all of an organizations assets for monitoring, managing and
analyzing. It consists of a server and clients. The clients are cross platform, so
OSSEC is great for mixed operating system environments (Linux, UNIX, BSDS, OS X,
Windows)*.

Although FreeBSD itself contains great security tools, managing the logs and events
across multiple servers becomes very difficult very quickly. By combining and
centralizing information, it is easier for a human to have more complete
operational awareness. In addition, it is possible to configure OSSEC to respond to
a threat automatically with pre-scripted commands, such as adding a pf block rule
or commands you can can script yourself. What can be automated in threat response
is limited only by how well you can shell script.

It must be clearly noted, OSSEC does not replace the need for a network admin or
security engineer to constantly monitor other system metrics, including knowing
what is really going on in the logs. However, as events happen, it is possible to
extend OSSEC through simple xml rules to catch the events found the good old
fashion way – by paying attention to the logs.

As OSSEC can be deployed across all of an organizations assets, it allows for
better monitoring, and quicker reaction to, threats than perimeter monitoring
alone. Deploying OSSEC should not be done with out careful preparation, starting
with a detailed inventory of all systems and services that are running throughout
your organization. This is not simple, as it means not just scanning with a tool
like nmap, but getting up and physically inspecting what you intend to protect. And
it also entails talking to people. As such, the following is not a description of a
full OSSEC installation, but a quick testing set up in a lab environment.

Version 2.8.3 of OSSEC is available in ports to compile or as a package. The
package of both the client and server install with out much issue. They are named
ossec-hids-server and ossec-hids-client.

One issue on both the client and server packages is directory/file permissions.
This generates these these types of errors:


ossec-analysisd(1212): ERROR: Unable to create PID file
ossec-remoted(1212): ERROR: Unable to create PID file.
ossec-maild(1212): ERROR: Unable to create PID file

The files and directories are installed in the /usr/local/ossec-hids directory.
Just make sure everything is owned by the ossec user and those errors go away. One
note, searching for the 1212 error in the documentation does not provide much
results, as that error is actually caused by error 1210, which is just further
towards the top of the ossec.log file.

For a quick setup edit the etc/osssec.conf file on both the client and server. One
look at that file will reveal the defaults won't work on FreeBSD. Set the log files
to what they should be (ie /var/log/messages not /var/logs/syslog).

Setting up the clients and server authentication is very strait forward, and it is
summed up in the documentation, which is quoted directly below:

1. Run manage_agents on the OSSEC server.
2. Add an agent
3. Extract the key for the agent.
4. Copy that key to the agent.
5. Run manage_agents on the agent.
6. Import the key copied from the manager.
7. Restart the manager’s OSSEC processes.
8. Start the agent.**

It is really that simple. Here is what it looks like on the terminal on the server:

# bin/manage_agents

****************************************
* OSSEC HIDS v2.8.3 Agent manager. *
* The following options are available: *
****************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
Choose your action: A,E,L,R or Q:

And on the agent:



# bin/manage_agents

****************************************
* OSSEC HIDS v2.8.3 Agent manager. *
* The following options are available: *
****************************************
(I)mport key from the server (I).
(Q)uit.
Choose your action: I or Q: i

* Provide the Key generated by the server.
* The best approach is to cut and paste it.
*** OBS: Do not include spaces or new lines.

Paste it here (or '\q' to quit):

Agent information:
ID:001
Name:xxxxxxxxx.xxx
IP Address:000.00.000.000

Confirm adding it?(y/n): y
Added.
** Press ENTER to return to the main menu.

****************************************
* OSSEC HIDS v2.8.3 Agent manager. *
* The following options are available: *
****************************************
(I)mport key from the server (I).
(Q)uit.
Choose your action: I or Q: q

Once everything is set up, and both the agent and server are talking to each other,
test it out by mounting an attack. Of course, there is the noisy option of of
Nessus or OpenVAS, or an nmap script, but it is just as fast, and more effective
for the purpose of this article, to write a quick script:

#!/bin/csh
foreach n (a b c d e f g h i j k l m n o p q r s t u v w x y z)
ssh $n@agentxxx -p 22
end

When run, something like this will appear in logs/alerts/alert.log:

** Alert 1468799403.1030242: - syslog,sshd,invalid_login,authentication_failed,
2016 Jul 17 23:50:03 (agent.xxx) 000.000.000.000->/var/log/auth.log
Rule: 5710 (level 5) -> 'Attempt to login using a non-existent user'
Src IP: 00.000.000.000
Jul 17 23:50:01 agent.xxx sshd[54027]: Invalid user v from 000.000.000.000

Special Notes on Jails on OSSEC
Deployment of OSSEC in a multi-host multi-jailed environment does pose some special
consideration which also applies to virtual machines of many kinds, but mainly ones
where the host has access to the guest file system. Should OSSEC be installed on
the host or inside the jail? There is not a strait forward answer to that
question.

One approach would be to install the OSSEC agent in each jail. This gives
reporting from each running system as if it is a self-contained unit. That in turn
makes solving an issue easier. Furthermore, active response rules can be configured
to take a misbehaving jail off line before too much damage has occurred.

Running OSSEC agents inside a jail also makes configuration easier, as a host with
a hundred jails, even with the use of wild cards, would have an unwieldy
configuration file along with a rather cumbersome policy for creating and
destroying jails.





References:

* http://ossec.github.io/
**http://ossec-docs.readthedocs.io/en/latest/manual/agent/agent-management.html







Copyright (c) 2019, Jason Edward Durrett - All content on this site, unless otherwise noted, is subject to this license.

Please contact me if any errors, such as erroneous / misleading content or missing / incomplete attribution, are found.