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

Connect to your server via SSH

1
2
3
4
COMPUTERNAME:~ ryansechrest$ ssh user@123.45.678.90
user@123.45.678.90's password: 
Last login: Thu Aug 23 12:41:24 2012 from 111.22.333.44
[email protected] [~]#
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.

1
ssh user@123.45.678.90 -p 18423
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.

1
2
3
user@123.45.678.90 [~]# su
Password: 
root@vps [/home/user]#
[email protected] [~]# su
Password: 
[email protected] [/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.

1
2
3
4
root@vps [/home/user]# cd /opt
root@vps [/opt]# mkdir ossec
root@vps [/opt]# cd ossec
root@vps [/opt/ossec]#
[email protected] [/home/user]# cd /opt
[email protected] [/opt]# mkdir ossec
[email protected] [/opt]# cd ossec
[email protected] [/opt/ossec]#

Download OSSEC and the checksum file

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

1
2
3
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]#
[email protected] [/opt/ossec]# wget http://www.ossec.net/files/ossec-hids-2.6.tar.gz
[email protected] [/opt/ossec]# wget http://www.ossec.net/files/ossec-hids-2.6_checksum.txt
[email protected] [/opt/ossec]#

Verify the integrity of the download

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

[email protected] [/opt/ossec]# md5sum ossec-hids-2.6.tar.gz 
f4140ecf25724b8e6bdcaceaf735138a  ossec-hids-2.6.tar.gz
[email protected] [/opt/ossec]# sha1sum ossec-hids-2.6.tar.gz 
258b9a24936e6b61e0478b638e8a3bfd3882d91e  ossec-hids-2.6.tar.gz
[email protected] [/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

1
2
root@vps [/opt/ossec]# tar -zxvf ossec-hids-2.6.tar.gz
root@vps [/opt/ossec]#
[email protected] [/opt/ossec]# tar -zxvf ossec-hids-2.6.tar.gz
[email protected] [/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

1
root@vps [/opt/ossec]# ossec-hids-2.6/install.sh
[email protected] [/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.
    1. Do you want e-mail notification? (y/n) [y]: y
      1. What’s your e-mail address? [email protected]
      2. What’s your SMTP server ip/host? localhost
    2. Do you want to run the integrity check daemon? (y/n) [y]: y
    3. Do you want to run the rootkit detection engine? (y/n) [y]: y
    4. Do you want to enable active response? (y/n) [y]: y
    5. Do you want to enable the firewall-drop response? (y/n) [y]: y
    6. 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.

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 *