Remote computers are under constant attack by Evil Dudes – that’s especially true for Linux servers. To prevent such attacks by Evil Dudes from Hacker Land, I’ve been relying on the amazing OSSEC Host Intrusion Detection System on all my machines.
Even though the OSSEC website is great, I always forget the simple steps that are involved in getting it up and running on a brand new server. Here are the steps that work for me.
I’ve originally written this article in 2011 for OSSEC 2.6, but I’ve just updated and tested the instructions again with OSSEC 2.8.1 on CentOS 7. It’s my go-to guide on how to get OSSEC up and running. However, by the time you read this it may all be completely out of date – please bear that in mind. Thanks 😉
To the get OSSEC installation script to work, we’ll need a couple of tools on our system: the GCC compiler and the MAKE command. These may already be present, but in case they’re not, let’s install those with
yum install make gcc
Excellent! This should mean OSSEC will install without hiccups.
Next let’s get OSSEC onto the local machine. Let’s download it – perhaps into a temp directory of your choice (the download link will likely have changed by the time you read this – head over to ossec.net to see what the latest version is):
curl -O http://www.ossec.net/files/ossec-hids-2.8.1.tar.gz
Now let’s unTAR it using this command:
tar -zxvf ossec*
Change into the OSSEC directory using cd ossec* and run
Configuration and Setup
We need to decide whether OSSEC runs as the main analysis server (server), an agent that’s being analysed by the server (agent) or if this is a standalone system not attached to a bigger network (local). Note that the server also analyses its own logs as well as the agent’s logs.
The default values are the ones you want to use so just hit enter several times. Have the server’s IP address handy when you’re installing new agents.
Setting up your Agents
This step is optional in case you want to run OSSEC as part of a network of servers. Skip ahead of you’re not using this feature.
You’ll have to tell your Server about new Agents. Run the following command on your Server to do this – have your Agent’s IP addresses ready:
Servers are also known as “Managers” nowadays, I still call them Servers as that’s the way I’ve learnt it back in the days. Select the (A)dd Agent option, give each a catchy name and enter their IP address. Do this for every Agent you have.
Next extract the key for each agent and add them to the relevant agent by running the above command. To do this, have two terminal windows open – one for the Server and one for the Agent.
Once done, make sure the OSSEC demon is restarted using
service ossec restart
Check if the Server can talk to the Agents
Let’s check if all the hard work is paying off by checking the logs:
tail -50 /var/ossec/logs/ossec.log
Pay close attention to the ossec.conf file by checking it here:
Note that for security it is read only by default (chmod 400) and OSSEC will give you a warning if you leave it writable for longer that you need to.
Avoiding Repeat Offenders
OSSEC will block attacks every time they happen, but if a persistent attacker tries something a million times he will eventually succeed. OSSEC has a great feature to avoid this: the ability to remember an Evil Dude’s IP address and block it for longer durations. It’s called Repeated Offenders.
This lets you specify how long an IP is banned for (in minutes) and increase the interval as attacks proceed. Sadly the option is not enabled by default.
To add it manually, open
and find the Active Response section. In those active response tags, add the following:
// don't add this// and don't add this 30,60,120,3600
This will block Evil Dude first for 30 minutes, then for 60, and so forth. The reason you don’t block an offender for 120 years instantly is because there’s always a possibility that a false positive would have to wait said amount of time until he/she/you gets another chance. Once added, restart OSSEC.
Note that you need to add this on every agent. Last time I checked the Repeat Offenders option is not governed by an OSSEC server.
Starting and stopping OSSEC
You can start, stop and restart OSSEC with the following commands:
service ossec start service ossec stop service ossec restart service ossec status
On CentOS 7 you can also use the systemctl command like so:
systemctl start ossec systemctl stop ossec systemctl restart ossec systemctl status ossec
Alternatively you can execute an OSSEC script directly for such actions – handy if none of the above work on your distribution:
/var/ossec/bin/ossec-control start /var/ossec/bin/ossec-control stop /var/ossec/bin/ossec-control restart /var/ossec/bin/ossec-control status
Where are the OSSEC Log Files?
I keep forgetting this time and time again: they’re not in the usual place with all the other logs. Instead, they’re in the OSSEC directory:
For live log output, try tail -f
Troubleshooting and FAQs
The first port of call are the OSSEC log files (see above). These hold vital clues as to why OSSEC can’t do what it promised you. If you don’t see any log files, or if OSSEC isn’t even running (see status), consider checking your installation. Run the installation script again and watch for error messages.
If an installation via yum doesn’t work for you, try installing it from source. I’ve had nothing but bad luck with the yum installation.
If the OSSEC Server can’t communicate with the Agents, chances are that the a receiving firewall is blocking incoming traffic on UDP port 1514. Open it up in both directions so the two can communicate.
Here’s a handy guide on how to fix duplicate errors should this ever be a problem. Also pay close attention to the Server IP address in the ossec.conf file. For some reason mine were pointing to an older server even though I asked OSSEC for a clean install rather than an upgrade.
Other than that there’s the fabulous OSSEC Website for more tips and tricks – plus the best piece of documentation that every been written and dubbed The OSSEC Bible, both for Kindle as well as in print.