Sign in
Insights

How to install and configure OSSEC to monitor the integrity of your website/server

Ryan Sechrest

• 22 min read
Laptop keyboard with a padlock on top.
OSSEC is better than a padlock.

OSSEC is a lightweight, but powerful piece of software that you can install on your server to monitor its integrity. On the official website, OSSEC is defined as:

[…] an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.

I’m going to go through the installation of OSSEC with a focus on how to configure the file integrity checking to monitor your web accessible files and alert you when something has changed. In addition, I’ll touch on OSSEC’s configuration file and what it’s comprised of, so you can tweak the settings to match your needs.

Before we get started though, let’s briefly talk about the idea of file integrity monitoring and why it might be useful on your website.

Most of the time the files on your server that power your website don’t change very often. All of the data is usually stored in a database, so what’s left are the core files of your content management system, for example. The only time those files should change, is if either you or someone authorized is performing an update.

When a website is compromised through a vulnerability, there is a pretty high chance that a successful attack will either add or change at least one or two files on your website, so that the attacker can either execute additional attacks or perform malicious activity.

In a perfect world, you’d be immediately alerted when a file’s or directory’s contents, permissions or owner changes. This is exactly what OSSEC’s file monitoring system does. It provides you with the ability to monitor certain directories on your server, exclude folders that you expect to change frequently, such as caching or upload folders, and allows you to be alerted in real-time when something is added, removed or updated.

Let’s get started with getting OSSEC up and running.

Connect to your server via SSH

COMPUTERNAME:~ ryansechrest$ ssh [email protected]
[email protected]'s password: 
Last login: Thu Aug 23 12:41:24 2012 from 111.22.333.44
[email protected] [~]#

If you’re not using the default port of 22, use option p followed by your custom port number.

ssh [email protected] -p 18423

Switch over to the root user

Normally you’d have limited permissions at this point. You will need root privileges to install and configure OSSEC. If you already have root permissions, you can skip this step, otherwise, use the su command to switch over to the root user.

[email protected] [~]# su
Password: 
root@vps [/home/user]#

Create the directory OSSEC will be installed in

The OSSEC documentation says to install OSSEC in the var directory, but since it’s an optional add-on to Linux, I’m going to install it in the opt directory. Let’s go there and create a folder for OSSEC.

root@vps [/home/user]# cd /opt
root@vps [/opt]# mkdir ossec
root@vps [/opt]# cd ossec
root@vps [/opt/ossec]#

Download OSSEC and the checksum file

Make sure you get the latest version from the official website.

root@vps [/opt/ossec]# wget http://www.ossec.net/files/ossec-hids-2.6.tar.gz
root@vps [/opt/ossec]# wget http://www.ossec.net/files/ossec-hids-2.6_checksum.txt
root@vps [/opt/ossec]#

Verify the integrity of the download

root@vps [/opt/ossec]# cat ossec-hids-2.6_checksum.txt 
MD5 (ossec-hids-2.6.tar.gz) = f4140ecf25724b8e6bdcaceaf735138a
SHA1 (ossec-hids-2.6.tar.gz) = 258b9a24936e6b61e0478b638e8a3bfd3882d91e
MD5 (ossec-agent-win32-2.6.exe) = 7d2392459aeab7490f28a10bba07d8b5
SHA1 (ossec-agent-win32-2.6.exe) = fdb5225ac0ef631d10e5110c1c1a8aa473e62ab4

root@vps [/opt/ossec]# md5sum ossec-hids-2.6.tar.gz 
f4140ecf25724b8e6bdcaceaf735138a  ossec-hids-2.6.tar.gz
root@vps [/opt/ossec]# sha1sum ossec-hids-2.6.tar.gz 
258b9a24936e6b61e0478b638e8a3bfd3882d91e  ossec-hids-2.6.tar.gz
root@vps [/opt/ossec]#

What you’re looking for here is that the MD5 and SHA1 from the checksum file match the MD5 and SHA1 from your files. This tells you that you have the full software and that it wasn’t altered during the transmission.

Extract OSSEC from the tar.gz

root@vps [/opt/ossec]# tar -zxvf ossec-hids-2.6.tar.gz
root@vps [/opt/ossec]#

If you were wondering what those options are:

  • z: filter the archive through gzip
  • x: extract files from an archive
  • v: verbosely list files processed
  • f: use archive file or device

Install OSSEC on the server

root@vps [/opt/ossec]# ossec-hids-2.6/install.sh

OSSEC will prompt you to choose a language. Hit ENTER to accept English as the default or enter one of the available two-character language codes.

OSSEC will display a welcome screen. Hit ENTER to get started.

Answer the following questions as follows:

  1. What kind of installation do you want (server, agent, local or help)? local
  2. Choose where to install the OSSEC HIDS [/var/ossec]: /opt/ossec
  3. Configuring the OSSEC HIDS.
  4. -- Do you want e-mail notification? (y/n) [y]: y
  5. -- -- What’s your e-mail address? [email protected]
  6. -- -- What’s your SMTP server ip/host? localhost
  7. -- Do you want to run the integrity check daemon? (y/n) [y]: y
  8. -- Do you want to run the rootkit detection engine? (y/n) [y]: y
  9. -- Do you want to enable active response? (y/n) [y]: y
  10. -- Do you want to enable the firewall-drop response? (y/n) [y]: y
  11. -- Do you want to add more IPs to the white list? (y/n)? [n]: n

Press ENTER to continue and then after a moment, ENTER again to finish.

Congratulations, OSSEC is now installed. Before we turn it on, let’s look at how to configure it next.

Changing OSSEC’s configuration file permissions

The configuration file is located within /opt/ossec/etc. Since we should still be within the ossec folder, let’s view the contents of the etc folder from there.

root@vps [/opt/ossec]# ls -al etc
total 114
dr-xr-x---  3 root ossec  2048 Aug 23 14:46 ./
dr-xr-x--- 14 root ossec  2048 Aug 23 14:46 ../
-r--r-----  1 root ossec 88975 Jul 11  2011 decoder.xml
-r--r-----  1 root ossec  2673 Jul 11  2011 internal_options.conf
-r-xr-xr-x  1 root ossec  3543 Jul 20 00:45 localtime*
-rw-r--r--  1 root root     87 Aug 23 14:46 ossec-init.conf
-r--r-----  1 root ossec  7345 Aug 23 14:45 ossec.conf
drwxrwx---  2 root ossec  2048 Aug 23 14:46 shared/
root@vps [/opt/ossec]#

The ls command is for viewing files in a folder and the options a and l specify that I want all entries with details, such as permissions and owners.

As you can see, ossec.conf is set to read-only (-r--r-----), which translates to 440.

Before we make any changes to the configuration, let’s make a back-up of those settings. We’re going to copy that file.

root@vps [/opt/ossec]# cp etc/ossec.conf etc/ossec-backup.conf
root@vps [/opt/ossec]# ls -al etc
total 122
dr-xr-x---  3 root ossec  2048 Aug 23 15:17 ./
dr-xr-x--- 14 root ossec  2048 Aug 23 14:46 ../
-r--r-----  1 root ossec 88975 Jul 11  2011 decoder.xml
-r--r-----  1 root ossec  2673 Jul 11  2011 internal_options.conf
-r-xr-xr-x  1 root ossec  3543 Jul 20 00:45 localtime*
-r--r-----  1 root root   7345 Aug 23 15:17 ossec-backup.conf
-rw-r--r--  1 root root     87 Aug 23 14:46 ossec-init.conf
-r--r-----  1 root ossec  7345 Aug 23 14:45 ossec.conf
drwxrwx---  2 root ossec  2048 Aug 23 14:46 shared/
root@vps [/opt/ossec]#

Change the permissions from 440 to 640 so we can modify the settings.

root@vps [/opt/ossec]# chmod 640 etc/ossec.conf 
root@vps [/opt/ossec]# ls -al etc
total 122
dr-xr-x---  3 root ossec  2048 Aug 23 15:17 ./
dr-xr-x--- 14 root ossec  2048 Aug 23 14:46 ../
-r--r-----  1 root ossec 88975 Jul 11  2011 decoder.xml
-r--r-----  1 root ossec  2673 Jul 11  2011 internal_options.conf
-r-xr-xr-x  1 root ossec  3543 Jul 20 00:45 localtime*
-r--r-----  1 root root   7345 Aug 23 15:17 ossec-backup.conf
-rw-r--r--  1 root root     87 Aug 23 14:46 ossec-init.conf
-rw-r-----  1 root ossec  7345 Aug 23 14:45 ossec.conf
drwxrwx---  2 root ossec  2048 Aug 23 14:46 shared/
root@vps [/opt/ossec]#

Open the configuration file using vim

root@vps [/opt/ossec]# vim etc/ossec.conf

Once open, you can scroll up and down quickly by using CTRL+U and CTRL+D respectively, or for slower scrolling, simply use your keyboard’s up and down arrow keys.

As you can tell, the configuration file is written in XML. Everything is enclosed within a pair of ossec_config brackets.

<ossec_config>
<!-- stuff -->
</ossec_config>

There are two nodes in this XML that we’re interested in.

The first one is called global, because it contains our email notification settings.

<global>
  <email_notification>yes</email_notification>
  <email_to>[email protected]</email_to>
  <smtp_server>localhost</smtp_server>
  <email_from>[email protected]</email_from>
</global>

The second one is called syscheck and that’s where we’ll setup the directories and files to monitor, in other words, our website or web accessible files.

<syscheck>
  <!-- Frequency that syscheck is executed - default to every 22 hours -->
  <frequency>79200</frequency>

  <!-- Directories to check  (perform all possible verifications) -->
  <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/bin,/sbin</directories>

  <!-- Files/directories to ignore -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/mnttab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore>/etc/mail/statistics</ignore>
  <ignore>/etc/random-seed</ignore>
  <ignore>/etc/adjtime</ignore>
  <ignore>/etc/httpd/logs</ignore>
  <ignore>/etc/utmpx</ignore>
  <ignore>/etc/wtmpx</ignore>
  <ignore>/etc/cups/certs</ignore>
  <ignore>/etc/dumpdates</ignore>
  <ignore>/etc/svc/volatile</ignore>

  <!-- Windows files to ignore -->
  <ignore>C:\WINDOWS/System32/LogFiles</ignore>
  <ignore>C:\WINDOWS/Debug</ignore>
  <ignore>C:\WINDOWS/WindowsUpdate.log</ignore>
  <ignore>C:\WINDOWS/iis6.log</ignore>
  <ignore>C:\WINDOWS/system32/wbem/Logs</ignore>
  <ignore>C:\WINDOWS/system32/wbem/Repository</ignore>
  <ignore>C:\WINDOWS/Prefetch</ignore>
  <ignore>C:\WINDOWS/PCHEALTH/HELPCTR/DataColl</ignore>
  <ignore>C:\WINDOWS/SoftwareDistribution</ignore>
  <ignore>C:\WINDOWS/Temp</ignore>
  <ignore>C:\WINDOWS/system32/config</ignore>
  <ignore>C:\WINDOWS/system32/spool</ignore>
  <ignore>C:\WINDOWS/system32/CatRoot</ignore>
</syscheck>

OSSEC is already setup to alert you on anything suspicious that’s going on with your server. That may include a lot of alerts that won’t be specific to your website. You can setup another email address that will only receive alerts of files or directories that were either changed, added or removed. To do this, we’ll insert the following right underneath the global settings.

Note: You must keep the global email notification setup, otherwise no email alerts will go out, even if you add the code below.

<!-- 550 changed, 553 deleted, 554 added -->
<email_alerts>
  <email_to>[email protected]</email_to>
  <rule_id>550, 553, 554</rule_id>
  <do_not_delay />
</email_alerts>

Rule 550 is a rule to monitor things that changed, rule 553 monitors things that were deleted and rule 554 checks for things that were added.

Those rules are native to OSSEC and already setup.

Now, to add this code, press the letter i on your keyboard to tell vim you want to insert something. (You should see -- INSERT -- toward the bottom left now).

Move your cursor right below the </global> closing tag and paste the code from the code box above. Then simply change out the email address.

It should look something like this now.

  <!-- stuff before -->
  <email_from>[email protected]</email_from>
</global>

<!-- 550 changed, 553 deleted, 554 added -->
<email_alerts>
  <email_to>[email protected]</email_to>
  <rule_id>550, 553, 554</rule_id>
  <do_not_delay />
</email_alerts>

<rules>
  <include>rules_config.xml</include>
  <include>pam_rules.xml</include>
  <!-- stuff after -->

Now that we have that, let’s look at what we need to add to the syscheck node.

<syscheck>
  <!-- Frequency that syscheck is executed - default to every 22 hours -->
  <frequency>79200</frequency>

  <!-- Monitor when new files are added -->
  <alert_new_files>yes</alert_new_files>

  <!-- Directories to check  (perform all possible verifications) -->
  <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/bin,/sbin</directories>
  <!-- stuff after -->

We need to add a node called alert_new_files with a value of yes, because by default, OSSEC does not report on files that were added — only changed or removed.

I personally chose to exclude media files from being alerted because most of the time they’re legitimate. I’m more worried about PHP and other script files. Now that I revealed this though, I may have to include them. :)

<!-- stuff before -->
<frequency>79200</frequency>

<!-- Monitor when new files are added -->
<alert_new_files>yes</alert_new_files>

<!-- Ignore images and videos globally -->
<ignore type="sregex">.gif$|.jpg$|.jpeg$|.png$|.mp4$|.flv$</ignore>

<!-- Directories to check  (perform all possible verifications) -->
<directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<!-- stuff after -->

The last step is to add the websites/directories you want to monitor on your server.

<!-- stuff before -->
<frequency>79200</frequency>

<!-- Monitor when new files are added -->
<alert_new_files>yes</alert_new_files>

<!-- Ignore images and videos globally -->
<ignore type="sregex">.gif$|.jpg$|.jpeg$|.png$|.mp4$|.flv$</ignore>

<!-- WEBSITES -->
<directories check_all="yes" report_changes="yes" realtime="yes">/home/user/public_html</directories>
<ignore>/home/user/public_html/wp-content/uploads</ignore>

<!-- Directories to check  (perform all possible verifications) -->
<directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<!-- stuff after -->

I think you get the idea. Just repeat the directories and ignore tag for as many items as you want to list. You can comma-separate items in the directories, but I find it cleaner to use a new tag. You cannot comma-separate things in the ignore tag.

Let’s talk about a few of those attributes.

check_all: OSSEC offers several checks such as check_size, check_sum, etc. I want to know if anything changes, but you can opt out of that.

report_changes: OSSEC cannot only tell you that something changed, but what specifically. This is very helpful when text files get altered. Note that in order to report the change, OSSEC copies every single file you want to monitor to a private location. If you have lots of media files that are large in size, take in consideration that however big your website is, you’ll need 2x the space for OSSEC to do its job. That’s another reason I excluded media files. Of course you can also omit report_changes entirely, then you won’t have that problem.

realtime: By default, OSSEC will run a system check every 22 hours (frequency node set to 79200), but if you want to know what happens in real-time, you can add the attribute realtime and set it to yes. OSSEC will now report a change via email within seconds.

Once you have everything setup the way you want it, hit ESC on your keyboard to exit insert mode. Now type a : (colon), followed by a w, hit ENTER, then another colon, followed by a q and ENTER again. You’ve successfully saved and exited the file.

Let’s not forget to change the permissions back.

root@vps [/opt/ossec]# chmod 440 etc/ossec.conf 
root@vps [/opt/ossec]#

Open the local configuration file using vim

Remember when we had to specifically tell OSSEC that we want to be alerted when new files are added? So, we took care of that, and while additions like this will be logged, we won’t actually get an email yet. We have to add a rule to local_rules.xml to do that.

root@vps [/opt/ossec]# chmod 640 rules/local_rules.xml 
root@vps [/opt/ossec]# vim rules/local_rules.xml

Add the second rule (554) underneath the first one.

<rule id="100001" level="0">
  <if_sid>5711</if_sid>
  <srcip>1.1.1.1</srcip>
  <description>Example of rule that will ignore sshd </description>
  <description>failed logins from IP 1.1.1.1.</description>
</rule>

<rule id="554" level="7" overwrite="yes">
  <category>ossec</category>
  <decoded_as>syscheck_new_entry</decoded_as>
  <description>File added to the system.</description>
  <group>syscheck,</group>
</rule>

What we’re doing is telling OSSEC that if rule 554 gets fired, overwrite its level (which by default is 0) to level 7, which is the minimum level for an email to be generated. As a side note, the minimum level for email alerts is set within the ossec.conf file.

After saving and exiting the local_rules.xml file, change the permissions back.

root@vps [/opt/ossec]# chmod 550 rules/local_rules.xml 
root@vps [/opt/ossec]#

Last, but not least, let’s look at starting OSSEC for the first time.

Starting OSSEC

root@vps [/opt/ossec]# bin/ossec-control start
Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
ossec-analysisd: Configuration error. Exiting.
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.
root@vps [/opt/ossec]#

You can see that there’s an error. Happens to the best of us. In essence, there is a path problem in OSSEC (known bug). This is easily solved by creating a link.

root@vps [/opt/ossec]# ln -s /opt/ossec/bin/ossec-logtest /opt/ossec/ossec-logtest
root@vps [/opt/ossec]#

Let’s try starting it again.

root@vps [/opt/ossec]# bin/ossec-control start
Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
ossec-maild already running...
ossec-execd already running...
ossec-analysisd already running...
ossec-logcollector already running...
ossec-syscheckd already running...
ossec-monitord already running...
Completed.
root@vps [/opt/ossec]#

Yup, worked like a charm this time around.

Check OSSEC’s running processes

This tells you what’s running.

root@vps [/opt/ossec]# bin/ossec-control status
ossec-monitord is running...
ossec-logcollector is running...
ossec-syscheckd is running...
ossec-analysisd is running...
ossec-maild is running...
ossec-execd is running...
root@vps [/opt/ossec]#

Check OSSEC’s action log

This tells you everything that OSSEC is doing and whether it was successful or not. It’s great for troubleshooting.

root@vps [/opt/ossec]# tail -100 logs/ossec.log

That command gives you the last 100 log entries. If you want everything, you can use:

root@vps [/opt/ossec]# cat logs/ossec.log

Check OSSEC’s alert log

This is everything OSSEC logged on the server. A subset of those logs were emailed to you in real-time.

root@vps [/opt/ossec]# tail -100 logs/alerts/alerts.log

Check OSSEC’s status

To get some quick information on where things stand with OSSEC, you can use the following command. Note that it will take a while for OSSEC to index all of your real-time directories, so you won’t be getting any alerts for several hours.

root@vps [/opt/ossec]# bin/agent_control -i 000

OSSEC HIDS agent_control. Agent information:
   Agent ID:   000 (local instance)
   Agent Name: domain.com
   IP address: 127.0.0.1
   Status:     Active/Local

   Operating system:    Linux domain.com 2.6.18-028stab092.1 #1 SM..
   Client version:      OSSEC HIDS v2.6
   Last keep alive:     Not available

   Syscheck last started  at: Thu Aug 23 16:51:11 2012
   Rootcheck last started at: Unknown
root@vps [/opt/ossec]#

Stop or restart OSSEC

You know how to start OSSEC, but what about restarting or stopping it.

root@vps [/opt/ossec]# bin/ossec-control restart
Killing ossec-monitord .. 
Killing ossec-logcollector .. 
Killing ossec-syscheckd .. 
Killing ossec-analysisd .. 
Killing ossec-maild .. 
Killing ossec-execd .. 
OSSEC HIDS v2.6 Stopped
Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.

root@vps [/opt/ossec]# bin/ossec-control stop   
Killing ossec-monitord .. 
Killing ossec-logcollector .. 
Killing ossec-syscheckd .. 
Killing ossec-analysisd .. 
Killing ossec-maild .. 
Killing ossec-execd .. 
OSSEC HIDS v2.6 Stopped
root@vps [/opt/ossec]#

That’s pretty much it. You now have a very basic version of OSSEC running. This software is powerful and can do a lot more, but you’ll have to spend some time learning it. The best resource is definitely the OSSEC manual.

If you have any questions or problems, feel free to leave a comment below.

Featured image by FLY:D.

Comments (20)

Previously posted in WordPress and transferred to Ghost.

Jonas Turner
June 13, 2013 at 2:13 pm

I wanted to let you know…this documentation worked almost flawlessly for 2.7. I wanted to install this on a test box and figured I would use your documentation. Thanks again for writing it!!

Ryan Sechrest
June 13, 2013 at 3:03 pm

Great– glad it helped!

Lee
February 20, 2014 at 12:31 am

I’d like to know if OSSEC can monitory WordPress plugins. It would be nice to create a specific rule to notify me about changes to plugins. A criminal hacker caused a lot of havoc on a client’s vps using plugins as an entry point; as a result, I want to install OSSEC. I have a firewall installed.

Ryan Sechrest
February 20, 2014 at 12:51 am

You can monitor your entire web root or just the plugin folder; that’s up to you. Then whenever a file gets added, removed or updated, you’ll be notified in real-time.

That said, most of my web root, especially the WordPress core and plugins, are read-only. On some sites I temporarily make them writable when I want to perform an update via the UI, on other sites all files are owned by Git and can only by modified by pushing committed (and verified) updates.

Russ Mittler
April 14, 2014 at 12:08 pm

Great article!

In my environment, I am running an OSSEC server however I have agents installed on windows servers to monitor them and not necessarily the OSSEC server itself. The problem that I am having is that after configuring the agents and connecting them to the server, it doesn’t seem that OSSEC is working properly.

I tested this by configuring installing an agent, generating a key for this agent on the server and extracting the key to place in the agent configuration. The agent then connects to the server and runs fine. The agent has its own config file much like the one on the server and by default its just monitoring the system32 directory. So I added a line to this config to monitor a test directory I created. I then added a few text files inside this directory. I restarted the agent to ensure it takes the new config and then I changed the name of the files inside the new test directory I created. Unfortunately, I did not receive any messages from OSSEC.

I’m pretty certain the email are configured properly as I do receive emails when the physical OSSEC server does an update or if I restart the service, etc… but I am not receiving an data pertaining to the agents.

Any ideas? Am I missing something? I know you don’t know my environment, but perhaps there is something I am missing…

Thank you!
Russ

Ryan Sechrest
April 14, 2014 at 12:38 pm

I would also agree that email notifications are working for the reasons you mentioned.

I’m assuming you’re using an agent.conf inside the /opt/ossec/etc/shared directory to set which directories you want to monitor? If so, you need to restart the manager, not the agent, to push the configuration file from the manager to the agent faster than the scheduled time (docs).

How long has it been since you’ve installed the agent? I ask, because it usually takes several hours before the machine has been indexed to report changes. You can also check on the server running the agent in /opt/ossec/logs/ossec.log whether the directories are being monitored as intended.

Lastly, by default, the standard system folders are only evaluated every 22 hours, so if you’re expecting real-time results, make sure the directories node within syscheck has a realtime attribute with a value of yes.

Russ Mittler
April 14, 2014 at 2:46 pm

Thanks for such a quick reply!!

Actually, I do not have an agent.conf inside that directory… should I?

I installed the agents last week and initially I figured it would take some time to index – so I gave it the weekend. When I go to /var/ossec/bin and run ./list_agents -c it says there are no agents… but when I do ./manage_agents and the L to list them – it does show the agent I created.

Now what I did notice is that there is a service called ossec-agentd – it looks like this is a service that aids in the communication but its not running. When I try to run this I get the following error:
ERROR: No valid server IP found.
ERROR: No client configured. Exiting.
Thanks!
Russ

Ryan Sechrest
April 14, 2014 at 3:15 pm

I don’t think using agent.conf is required, but it does allow you to centrally manage both your agent configurations, which is helpful.

OSSEC agents and master talk to each other over port 1514. Make sure that this port is open and that the servers can communicate with each other. First, I’d make sure they can ping each other, then I’d check to make sure the port is accepting traffic both ways i.e. no firewall intercepting, on the same subnet or necessary routes created.

On the OSSEC master, from the bin directory, go ahead and run ./agent_control -l (lowercase L) to see if the agents have ever connected to your OSSEC master. It should read ID, name, IP, and Active.

ossec-agentd should not be running on the master. This daemon only runs on the agents… it’s the service that communicates with the master.

Lastly, restart the agent and then immediately review the ossec.log on the agent. If there is a communications problem, it will tell you. For example, you might see:
ossec-agentd: INFO: Trying to connect to server (master.ossec.vps/192.168.10.1:1514).
ossec-agentd(4101): WARN: Waiting for server reply (not started). Tried: 'master.ossec.vps/192.168.10.1'
Then you know what the problem is.

Russ Mittler
April 14, 2014 at 4:20 pm

I understand with the agent.conf – I will look into this once I get things working.

I have ensured that the port is open at both ends and the servers can communicate. What is interesting, when I run ./agent_control -l – I can see my web server there! It shows the name, IP and ID number. When I run ./agent_control -i 007 (the ID of the box) it shows the information with no problem. To test, I try and run ./agent_control -R 007 (this will restart the agent remotely) and I get the following 2 errors:
ERROR: Queue '/queue/alerts/er' not accessible: 'Connection refused'.
ERROR: Unable to connect to active response queue.
So I restarted the agent as suggested and immediately looked in the ossec.log file but the only errors I see are the ones above.

Thanks!
Russ

Ryan Sechrest
April 14, 2014 at 4:49 pm

OK, so if ./agent_control -l says the server is Active, and there are no connection errors in the agent’s ossec.log, then it’s not a connection issue.

The next step is to then check the alert log at /opt/ossec/logs/alerts/alert.log on the OSSEC master. First, look for any alerts from one of your agents. If you see one, that’s good. Second, observe the level of the alert. It must be set to 7 or higher for an email to be generated, unless you’ve changed the default.

To confirm, the two errors you mentioned, do you see those on the agent or the master?

As a side note, if you restart an agent from the master, check the ossec.log on the agent again. It should have logged the restart request.

Russ Mittler
April 15, 2014 at 1:15 pm

Hello Ryan,

I believe I corrected the problem! There seems to have been some issues with the config files. I got everything communicating now and I see all the agents I have installed and connected.

Within the agent config on the windows side there is a default config that is set up to watch some system32 directories. Here is an example of a line:

%WINDIR%/System32/drivers/etc/test

I added this line to the config file to monitor the test directory as a test. In this directory, I have placed a copy of the host file just as a test. I then restarted the agent (which I received an email) and then restarted the server just to be sure the new config took place.

Is there a certain amount of time I need to wait for this directory specifically to be monitored? Reason I ask is because if I understand correctly, this directory and all of its contents will be monitored so in theory if I modify this file or even delete it, I should receive a notification, correct? I created this test directory to do just that. I deleted the file and modified it but I am not receiving any emails regarding the change or delete… am I missing a step? Do I need to give OSSEC some time to index the system files?

Thanks again for all your help, I really appreciate it. I really like this project therefore I would like to get it functioning 100% so we can use it in production.

Russ

Ryan Sechrest
April 15, 2014 at 2:21 pm

Great, glad to hear it’s working for you!

With regard to alerts…

* You are correct that you should be getting an email anytime something changes within the directories you’re monitoring. Make sure you’re using the realtime attribute to get alerts faster than the set alert frequency in the main OSSEC configuration file.

* It will take several hours to index all the files you’re monitoring. The time largely depends on the amount of files within the directory.

* Note that OSSEC doesn’t alert on new files by default; only changed and deleted. In my article though, I describe how to set it up for new files as well.

* You can always check the OSSEC logs to see what it’s doing and what it is detecting (before you get an email), just to double check yourself that OSSEC is logging the things you want to log.

Russ Mittler
April 15, 2014 at 2:40 pm

Again, thank you so much Ryan!

I will give it a little more time to index the files and directories. Then I will test changing a file name within one of the directories it is monitoring.

Now I went ahead and added the following for new files:
yes
With regards to the realtime attribute, do I need to remove the frequency tag and replace it with the realtime tag or have both? Right now I have it set up like this:
79200


yes
I wouldn’t think I would need both but just want to make sure.

Now when I restart the OSSEC server, I am receiving an error message regarding the realtime tag.
2014/04/15 12:37:37 ossec-config(1230): ERROR: Invalid element in the configuration: 'realtime'.
2014/04/15 12:37:37 ossec-config(1202): ERROR: Configuration error at '/var/ossec/etc/ossec.conf'. Exiting.
2014/04/15 12:37:37 ossec-syscheckd(1202): ERROR: Configuration error at '/var/ossec/etc/ossec.conf'. Exiting.
I removed the tag for now and it started just fine.

Thanks!

Ryan Sechrest
April 15, 2014 at 3:01 pm

Yes, you do need both, because not everything will be checked in real-time — only certain directories you specify. Take another look at page 3 of my article and verify you’re using the realtime attribute on the right node. Also, here is a link to the OSSEC documentation that discusses real-time.

Russ Mittler
April 16, 2014 at 11:57 am

Yes – I had it the wrong spot!

I think I got it working pretty well at this point! The only thing I am not seeing is for example when I am monitoring a directory – and files are added into this directory. I do not get an email.

I have this added into the config of the agent:
yes
Does it have to be on the main server too?

Ryan Sechrest
April 16, 2014 at 1:27 pm

Did you set the alert level of rule 554 to 7 (also described on page three)? By default, new files are now being logged, but in order for an email to go out, the alert level has to be raised to the minimum level defined for emails to go out, which, by default, is 7.

Also, it does have to be on the main server, because it’s an alerting configuration and the main server is the one alerting.

Russ Mittler
April 21, 2014 at 11:07 am

Hi Ryan!

I just wanted to again thank you for the help! The article really helped along with the questions you answered.

I got everything working 100% and am happy to say we are happy with the results!

Thank you so much!
Russ

Ryan Sechrest
April 21, 2014 at 11:20 am

Russ,

Excellent, happy to hear it!

Emmett Brosnan
April 14, 2015 at 10:57 am

Great help – thanks Ryan.

Julia V.
October 13, 2017 at 2:25 pm

As a newby with OSSEC (and file integrity at all) this article was very helpful. Thanks!