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

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.

1
2
3
4
5
6
7
8
9
10
11
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]#
[email protected] [/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/
[email protected] [/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.

1
2
3
4
5
6
7
8
9
10
11
12
13
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]#
[email protected] [/opt/ossec]# cp etc/ossec.conf etc/ossec-backup.conf
[email protected] [/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/
[email protected] [/opt/ossec]#

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

1
2
3
4
5
6
7
8
9
10
11
12
13
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]#
[email protected] [/opt/ossec]# chmod 640 etc/ossec.conf 
[email protected] [/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/
[email protected] [/opt/ossec]#

Open the configuration file using vim

1
root@vps [/opt/ossec]# vim etc/ossec.conf
[email protected] [/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.

1
2
3
<ossec_config>
...
</ossec_config>
<ossec_config>
...
</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.

1
2
3
4
5
6
<global>
  <email_notification>yes</email_notification>
  <email_to>[email protected]</email_to>
  <smtp_server>localhost</smtp_server>
  <email_from>[email protected]</email_from>
</global>
<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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
<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>
<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.

1
2
3
4
5
6
<!-- 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>
<!-- 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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
...
  <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>
  ...
...
  <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>
  ...

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

1
2
3
4
5
6
7
8
9
10
11
<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>
  ...
<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>
  ...

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 🙂

1
2
3
4
5
6
7
8
9
10
11
12
...
<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>
...
...
<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>
...

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
...
<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>
...
...
<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>
...

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.

1
2
root@vps [/opt/ossec]# chmod 440 etc/ossec.conf 
root@vps [/opt/ossec]#
[email protected] [/opt/ossec]# chmod 440 etc/ossec.conf 
[email protected] [/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.

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
<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>
<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.

1
2
root@vps [/opt/ossec]# chmod 550 rules/local_rules.xml 
root@vps [/opt/ossec]#
[email protected] [/opt/ossec]# chmod 550 rules/local_rules.xml 
[email protected] [/opt/ossec]#

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

20 thoughts on “How to install and configure OSSEC to monitor the integrity of your website/server

  1. Jonas Turner

    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!!

    Reply
  2. Lee

    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.

    Reply
    1. Ryan Sechrest Post author

      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.

      Reply
  3. Russ Mittler

    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

    Reply
    1. Ryan Sechrest Post author

      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.

      Reply
      1. Russ Mittler

        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

        Reply
        1. Ryan Sechrest Post author

          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.

          Reply
  4. Russ Mittler

    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

    Reply
    1. Ryan Sechrest Post author

      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.

      Reply
      1. Russ Mittler

        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

        Reply
        1. Ryan Sechrest Post author

          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.

          Reply
  5. Russ Mittler

    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:

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

    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:

    <!-- 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>

    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!

    Reply
      1. Russ Mittler

        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:

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

        Does it have to be on the main server too?

        Reply
        1. Ryan Sechrest Post author

          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.

          Reply
          1. Russ Mittler

            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

Leave a Reply

Your email address will not be published. Required fields are marked *