OSSEC Agent Installation on RedHat Enterprise and/or CentOS

I consider a HIDS to be one of the very most important security systems in a network. It's very important to know if someone is attempting to brute force his way into one of your servers, but if the attacker breaks in, it's even more important to know what changed. While log monitors and tools like Splunk can detect the former, they're not designed to note changes in binaries. That's where a HIDS (Host-based Intrusion Detection System) comes into play. One of the most popular is OSSEC. It's open sourced and free to deploy. It notes troublesome issues in the logs (like login failures) and can even take proactive measures, such as blocking an attacking host by manipulating the firewall.

OSSEC works on Windows, various flavors of unix and linux, as well as network devices such as switches, routers, and firewalls. It can run stand alone or report to a master server.

Agent installation on RHEL/CentOS

1. Install the Atomic Yum repo:

sudo "wget -q -O - http://www.atomicorp.com/installers/atomic | sh"

2. Install the EPEL repo (We're using 64bit Linux here)

 If RHEL 5/CentOS 5, 

sudo rpm -ivh http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm

If RHEL 6/CentOS 6,

sudo rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

CentOS 6

 3. Install the RPMs from yum (should be about 4 RPMs or so):

sudo yum -y install ossec-hids-client

3a. (optional) Disable the Yum repos for Atomic and EPEL:

sed -i /etc/yum.repos.d/atomic.repo -e 's/enabled = 1/enabled = 0/g'
sed -i /etc/yum.repos.d/epel.repo -e 's/enabled = 1/enabled = 0/g'

4. You'll need to set your server (if you even have a central OSSEC server) in the config file like so:

5. (optional) make an exception for the central server (again, if you even have one):

sudo iptables -A INPUT -p udp --dport 1514 -j ACCEPT

 That's basically it. It's most definitely worth reading up on the documentation and you should definitely test OSSEC out before using the active rules.

 

Java keytool quick tips

Creating a keystore from an SSL key and cert

To store an SSL key for Jetty or other Java based webserver, you usually use keytool. You'll first need to convert the key to pkcs12 (we're calling the output file jetty.pkcs12) format like so (we're assuming your key is generated with openssl or something similar - also, we're in the same directory as the keys):

Convert mykey,key and mykey.crt to a pkcs12  format using openssl

( I highly recommend using a passphrase on the key)


openssl pkcs12 -inkey ./mykey.key -in ./mykey.crt -export -out ./jetty.pkcs12

Let's take that pkcs12 key and convert it into a Java keystore (we're calling the keystore mykeystore)

 

keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype pkcs12 -destkeystore mykeystore

Let's list the contents of this keystore:

keytool -list -storename mykeystore

Add an CA certificate to the default java CA cert keystore

 

Java keeps its own CA cert repo - which can be frustrating if you don't update java on your server frequently. To add a new CA cert (let's assume you just bought an SSL cert online and your cert CA's certificates were created recently)

1. Find cacerts for your installation - note that many commercial java programs like to install their own java. If you're looking at the default java location, try:

find /usr -name cacerts

1b. If you're trying to find the cacerts for an application you installed, figure out where java is being called from:

ps wwaux | grep java

(you'll likely see a path for java - i.e., /opt/java/bin/java  or something similar)

Now, find the cacerts,   

 find /opt -name cacerts

2. Add the CA cert to your cacerts file:

keytool -import -trustcacerts -alias MyCAsName -file /path/to/ca-certificatec -keystore /path/to/keystore

 

 

 

Nagios Group Service Checks and Exclusions

Using hostgroup_name in service checks is very, very useful. However, I find that I often want to include the Nagios server in one of the hostgroups, but don't necessarily want to configure nrpe for the nagios host. An easy way around this is to use Nagios's exclude feature. You can exclude a group (or host) by prefacing it with "!"

For instance:

1. create a group that contains only your nagios host

define hostgroup {

        hostgroup_name localhost-monitor-hosts

        members         mynagiosserver

}

2. create the service:

define service {

        hostgroup_name          unix-hosts,!localhost-monitor-hosts

        use                             critical-service

        service_description             check_disk

        check_command                   check_nrpe!check_disk!80!85

        check_freshness                 1

        register                        1

        }

This will check all hosts in the unix-hosts group, excluding any in localhost-monitor-hosts. You can obviously create multiple groups, each with a different purpose.

Note, you can also define a service with more than one host, and exclude hosts that way:

define service {

         host_name www1, www2, !www3

         use generic-service

         service_description check_ping

         check_command check_ping!100.0,20%!500.0,60%

}

but I find that more taxing, as you have to maintain the host_name... which is kind ignoring the whole point of groups.