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:
- What kind of installation do you want (server, agent, local or help)? local
- Choose where to install the OSSEC HIDS [/var/ossec]: /opt/ossec
- Configuring the OSSEC HIDS.
- -- Do you want e-mail notification? (y/n) [y]: y
- -- -- What’s your e-mail address? [email protected]
- -- -- What’s your SMTP server ip/host? localhost
- -- Do you want to run the integrity check daemon? (y/n) [y]: y
- -- Do you want to run the rootkit detection engine? (y/n) [y]: y
- -- Do you want to enable active response? (y/n) [y]: y
- -- Do you want to enable the firewall-drop response? (y/n) [y]: y
- -- 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]#
ls command is for viewing files in a folder and the options
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
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
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> <!-- 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
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>
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> <!-- 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
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
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
ENTER, then another colon, followed by a
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>184.108.40.206</srcip> <description>Example of rule that will ignore sshd </description> <description>failed logins from IP 220.127.116.11.</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
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.
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.
Previously posted in WordPress and transferred to Ghost.
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!!
June 13, 2013 at 3:03 pm
Great– glad it helped!
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.
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.
April 14, 2014 at 12:08 pm
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…
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
/opt/ossec/etc/shareddirectory 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.logwhether 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
realtimeattribute with a value of
April 14, 2014 at 2:46 pm
Thanks for such a quick reply!!
Actually, I do not have an
agent.confinside 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
./list_agents -cit says there are no agents… but when I do
./manage_agentsand 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.
April 14, 2014 at 3:15 pm
I don’t think using
agent.confis 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
bindirectory, 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-agentdshould 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.logon 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.
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.logfile but the only errors I see are the ones above.
April 14, 2014 at 4:49 pm
OK, so if
./agent_control -lsays 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.logon 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.logon the agent again. It should have logged the restart request.
April 15, 2014 at 1:15 pm
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:
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.
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
realtimeattribute 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.
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:
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:
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.
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
realtimeattribute on the right node. Also, here is a link to the OSSEC documentation that discusses real-time.
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:
Does it have to be on the main server too?
April 16, 2014 at 1:27 pm
Did you set the alert level of rule
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
Also, it does have to be on the main server, because it’s an alerting configuration and the main server is the one alerting.
April 21, 2014 at 11:07 am
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!
April 21, 2014 at 11:20 am
Excellent, happy to hear it!
April 14, 2015 at 10:57 am
Great help – thanks Ryan.
October 13, 2017 at 2:25 pm
As a newby with OSSEC (and file integrity at all) this article was very helpful. Thanks!