Global ossec.conf Settings

OSSEC comes with a server-wide configuration file. Its important to look for and modify this file on the host that runs the server your agents connect to. This configuration will control the alerting and rules used on the server and its agents. Located at /var/ossec/etc/ossec.conf, see the below examples for some changes that can be made within the file -


Change the below appropriately to send emails to yourself. Note that routing mail to localhost IP (Running Postfix IP) allows for forwarding mail through the host as the user defined in our Postfix Configuration



Syscheck is the block that configures the many settings that run various checks on your system. Define these specifically to match your environment, ignoring or adding directories as needed based on alerting. Any rules with the XML tags <group>syscheck</group> within their definition are checked when this test is ran.

    <!-- Frequency that syscheck is executed - default to every 22 hours -->
    <!-- Directories to check  (perform all possible verifications) -->
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
    <directories check_all="yes">/bin,/sbin,/boot</directories>

    <!-- Files/directories to ignore -->

    <!-- Windows files to ignore -->

Command Monitoring

Partition alerts -

  <rule id="530" level="0">
    <match>^ossec: output: </match>
    <description>OSSEC process monitoring rules.</description>

  <rule id="531" level="7" ignore="7200">
    <match>ossec: output: 'df -P': /dev/</match>
    <description>Partition usage reached 100% (disk space monitor).</description> 

Process Monitoring Command Monitoring - Book

Custom Monitoring
<!--- local_rules.xml --->
  <rule id="100004" level="7">
    <description>Ignore snap partition size alerts</description>
<!--- ossec.conf --->

Custom Monitoring


You can see a simple agent status report using the below command

# List agents and status
sudo /var/ossec/bin/agent_control -r -l

agent_control has various other uses, see the output of agent_control -h below -

OSSEC HIDS agent_control: Control remote agents.
Available options:
        -h          This help message.
        -l          List available (active or not) agents.
        -lc         List active agents.
        -i <id>     Extracts information from an agent.
        -R <id>     Restarts agent.
        -r -a       Runs the integrity/rootkit checking on all agents now.
        -r          Runs the integrity/rootkit checking on one agent now.

        -b <ip>     Blocks the specified ip address.
        -f <ar>     Used with -b, specifies which response to run.
        -L          List available active responses.
        -m          Show the limit of agents that can be added.
        -s          Changes the output to CSV (comma delimited).
        -j          Changes the output to JSON .
        -u <id>     Used with -r and -b Specifies the agent to use.

The below rules are used to generate reports on changes made to a system using OSSEC's built in grouping policies.

  <rule id="550" level="7">
    <description>Integrity checksum changed.</description>
  <rule id="551" level="7">
    <description>Integrity checksum changed again (2nd time).</description>
  <rule id="552" level="7">
    <description>Integrity checksum changed again (3rd time).</description>

The above rules and groups can be passed through reporting tools provided by OSSEC. Note that 001 below is our agent ID we want to generate the report for. OSSEC will automatically lookup alerts that have fired related to the rules above.

# Manually run root, syschecks
# This checks the OSSEC server and its agents for any new changes
sudo /var/ossec/bin/agent_control -r -u 001
# Generate integrity check report (for email reporting?)
sudo /var/ossec/bin/syscheck_control -i 001

For example, an integrity check report looks something like the below -

Changes for 2019 Sep 06:
2019 Sep 06 09:18:04,0 - /usr/bin/docker
2019 Sep 06 09:18:13,0 - /usr/bin/docker-proxy
2019 Sep 06 09:18:35,0 - /usr/bin/dockerd
2019 Sep 06 09:21:36,0 - /bin/docker
2019 Sep 06 09:21:44,0 - /bin/docker-proxy
2019 Sep 06 09:22:06,0 - /bin/dockerd
2019 Sep 06 18:44:42,0 - /var/ossec/etc/internal_options.conf
2019 Sep 06 18:46:01,0 - /etc/ossec-init.conf

any of the above commands can be set to run as cronjobs and paired with mail -s to manually schedule a daily report with more specific output. Below, we sent the intergrity check report we manually generated above to a specific E-Mail address.

sudo /var/ossec/bin/syscheck_control -i 001 | mail -s "OSSEC Daily Report: Agent 001 Integrity Check" email@somedomain.com
sudo /var/ossec/bin/agent_control -r -l | mail -s "OSSEC Daily Report: Agent Status" email@somedomain.com

In this way, it is easy to setup a cronjob to send these reports for you on a specified schedule.

Setting up automatic daily reporting (12:01AM) for OSSEC can also be done within the /var/ossec/etc/ossec.conf file on the OSSEC Server by adding the options below -

      <title>Daily report: File changes</title>
      <title>Daily report: Alerts with level higher than 10</title>

This will generate reports for any alerting done within the syscheck group, and another report for any alerts of severity level 10 or greater. These reports are sent to the email addresses based on the settings provided to reports

Alternatively, you can manually generate these reports within the command prompt of your OSSEC Server by running the below commands -

# Example 1: Show Successful Logins
cat /var/ossec/logs/alerts/alerts.log | /var/ossec/bin/ossec-reportd -f group authentication_success
# Example 2: Show Alerts Level 10 and Greater
cat /var/ossec/logs/alerts/alerts.log | /var/ossec/bin/ossec-reportd -f level 10
# Example 3: Show the srcip for all users
cat /var/ossec/logs/alerts/alerts.log | /var/ossec/bin/ossec-reportd -f group authentication -r user srcip
# Example 4: Show Changed files as reported by Syscheck
cat /var/ossec/logs/alerts/alerts.log | /var/ossec/bin/ossec-reportd -f group syscheck -r location filename

Further filtering of alerts can be handled through properties of the XML tags, an example of filtering alerts for recipients based on various settings is seen below -


Note that the above is an example providing different uses in filtering emails in general, but the syntax for reports should be used if the desire is to filter the daily generated report distribution based on various settings. While the properies are the same, the tags are named differently within their blocks - depending on where they are nested, within an <email_alerts> or <reports> XML block.

Custom Local Rules

When running an OSSEC with remote agents, you'll need to configure the alerting and rules specific to the needs of your environment. To do this, edit /var/ossec/rules/local_rules.xml and blocks similar to the format below.

  <!-- This example will ignore NXDOMAIN alerts -->
  <rule id="100002" level="0"> <!--Define the rule ID we are creating-->
   <if_sid>1002</if_sid> <!-- Specify rule ID we are altering -->
   <program_name>systemd-resolved</program_name> <!-- Optional cross check with rule program name  --> 
   <match>Server returned error NXDOMAIN</match> <!-- Match error text --> 
   <description>Usless systemd-resolvd log message</description> <!-- local description --> 
  <!-- This example will ignore ssh failed logins for the user name XYZABC. --
  <rule id="100020" level="0">
    <description>Example of rule that will ignore sshd </description>
    <description>failed logins for user XYZABC.</description>

Above, we use the <rule> xml tag with various values passed to OSSEC to identify our rule. Below, we can see all the available attributes for this tag

rule -
Defines a rule



        Specifies the level of the rule. Alerts and responses use this value.
        Allowed: Any number (0 to 16)


        Specifies the ID of the rule.
        Allowed: Any number from 100 to 99999


        Specifies the maximum size of the event.
        Allowed: Any number from 1 to 99999


        Specifies the number of times the rule must have matched before firing. The number that triggers the rule is actually 2 more than this setting.
        Allowed: Any number from 1 to 999
        Example: frequency=”2” would mean the rule must be matched 4 times


        The timeframe in seconds.
        This option is intended to be used with the frequency option.
        Allowed: Any number from 1 to 9999


        The time (in seconds) to ignore this rule after firing it (to avoid floods).
        Allowed: Any number from 1 to 9999

        Used to supercede an OSSEC rule with local changes.
        This is useful to change the level or other options of rules included with OSSEC.
        Allowed yes

You'll notice that the OSSEC Docs - Rule Syntax will be a great resource when creating these rules as there are many different values you can add or edit, but a few of the important settings can be seen below -

Program name is decoded from syslog process name.
Allowed: any OS_Match/sregex Syntax

Matches if the ID has matched.
Allowed: Any rule id

Matches if the level has matched before.
Allowed: Any level from 1 to 16

Any string to match against the log event.
Allowed: Any OS_Match/sregex Syntax

Any regex to match against the log event.
Allowed: Any OR_Regex/regex Syntax

Complete list of ossec rules within /var/ossec/rules/ -

apache_rules.xml	   ms1016_usbdetect_rules.xml  sendmail_rules.xml
apache_rules.xml~	   ms_dhcp_rules.xml	       sendmail_rules.xml~
apparmor_rules.xml	   ms_dhcp_rules.xml~	       smbd_rules.xml
apparmor_rules.xml~	   ms_firewall_rules.xml       smbd_rules.xml~
arpwatch_rules.xml	   ms_ftpd_rules.xml	       solaris_bsm_rules.xml
arpwatch_rules.xml~	   ms_ftpd_rules.xml~	       solaris_bsm_rules.xml~
asterisk_rules.xml	   ms_ipsec_rules.xml	       sonicwall_rules.xml
asterisk_rules.xml~	   ms_powershell_rules.xml     sonicwall_rules.xml~
attack_rules.xml	   msauth_rules.xml	       spamd_rules.xml
attack_rules.xml~	   msauth_rules.xml~	       spamd_rules.xml~
cimserver_rules.xml	   mysql_rules.xml	       squid_rules.xml
cimserver_rules.xml~	   mysql_rules.xml~	       squid_rules.xml~
cisco-ios_rules.xml	   named_rules.xml	       sshd_rules.xml
cisco-ios_rules.xml~	   named_rules.xml~	       sshd_rules.xml~
clam_av_rules.xml	   netscreenfw_rules.xml       symantec-av_rules.xml
clam_av_rules.xml~	   netscreenfw_rules.xml~      symantec-av_rules.xml~
courier_rules.xml	   nginx_rules.xml	       symantec-ws_rules.xml
courier_rules.xml~	   nginx_rules.xml~	       symantec-ws_rules.xml~
dnsmasq_rules.xml	   nsd_rules.xml	       syslog_rules.xml
dovecot_rules.xml	   openbsd-dhcpd_rules.xml     syslog_rules.xml~
dovecot_rules.xml~	   openbsd_rules.xml	       sysmon_rules.xml
dropbear_rules.xml	   openbsd_rules.xml~	       sysmon_rules.xml~
dropbear_rules.xml~	   opensmtpd_rules.xml	       systemd_rules.xml
exim_rules.xml		   opensmtpd_rules.xml~        systemd_rules.xml~
firewall_rules.xml	   ossec_rules.xml	       telnetd_rules.xml
firewall_rules.xml~	   ossec_rules.xml~	       telnetd_rules.xml~
firewalld_rules.xml	   owncloud_rules.xml	       topleveldomain_rules.xml
firewalld_rules.xml~	   pam_rules.xml	       trend-osce_rules.xml
ftpd_rules.xml		   pam_rules.xml~	       trend-osce_rules.xml~
ftpd_rules.xml~		   php_rules.xml	       unbound_rules.xml
hordeimp_rules.xml	   php_rules.xml~	       unbound_rules.xml~
hordeimp_rules.xml~	   pix_rules.xml	       vmpop3d_rules.xml
ids_rules.xml		   pix_rules.xml~	       vmpop3d_rules.xml~
ids_rules.xml~		   policy_rules.xml	       vmware_rules.xml
imapd_rules.xml		   policy_rules.xml~	       vmware_rules.xml~
imapd_rules.xml~	   postfix_rules.xml	       vpn_concentrator_rules.xml
kesl_rules.xml		   postfix_rules.xml~	       vpn_concentrator_rules.xml~
last_rootlogin_rules.xml   postgresql_rules.xml        vpopmail_rules.xml
linux_usbdetect_rules.xml  postgresql_rules.xml~       vpopmail_rules.xml~
local_rules.xml		   proftpd_rules.xml	       vsftpd_rules.xml
local_rules.xml~	   proftpd_rules.xml~	       vsftpd_rules.xml~
mailscanner_rules.xml	   proxmox-ve_rules.xml        web_appsec_rules.xml
mailscanner_rules.xml~	   psad_rules.xml	       web_appsec_rules.xml~
mcafee_av_rules.xml	   pure-ftpd_rules.xml	       web_rules.xml
mcafee_av_rules.xml~	   pure-ftpd_rules.xml~        web_rules.xml~
mhn_cowrie_rules.xml	   racoon_rules.xml	       wordpress_rules.xml
mhn_dionaea_rules.xml	   racoon_rules.xml~	       wordpress_rules.xml~
ms-exchange_rules.xml	   roundcube_rules.xml	       zeus_rules.xml
ms-exchange_rules.xml~	   roundcube_rules.xml~        zeus_rules.xml~
ms-se_rules.xml		   rules_config.xml
ms-se_rules.xml~	   rules_config.xml~

Debugging OSSEC Rules

If you're having trouble configuring / testing rules, try running the commands below to test your settings on command by causing the alerts to fire.

# Watch for new OSSEC logs within /var/ossec/logs/
tail -f /var/ossec/logs/active-response.log
tail -f /var/ossec/logs/ossec.log
## Test the OSSEC response as if the echo contents were parsed within some monitored logs
logger "Segmentation Fault"
# logger will have no output but will respond as if the rule really happened
# Will give debug info, does not actually carry out any actions
# Shows action that the log represents on the system, as well as OSSEC response if the alert would fire
echo "pam_unix(sudo:auth): conversation failed" | sudo /var/ossec/bin/ossec-logtest
2019/09/07 04:50:59 ossec-testrule: INFO: Reading local decoder file.
2019/09/07 04:50:59 ossec-testrule: INFO: Started (pid: 26407).
ossec-testrule: Type one log per line.

**Phase 1: Completed pre-decoding.
       full event: 'pam_unix(sudo:auth): conversation failed'
       hostname: 'monitor'
       program_name: '(null)'
       log: 'pam_unix(sudo:auth): conversation failed'

**Phase 2: Completed decoding.
       No decoder matched.

**Phase 3: Completed filtering (rules).
       Rule id: '1002'
       Level: '2'
       Description: 'Unknown problem somewhere in the system.'
**Alert to be generated.
# Re-scan a log that fired alerts to check what actions might happen if they reoccur
# This will scan syslogs for all events within the log
cat /var/log/syslog | /var/ossec/bin/ossec-logtest -a
# We can build on the above command and scan the ossec alert.log
# Passing this into reportd, we can generate a report on the alerts fired within the given log
cat /var/ossec/logs/alerts/alerts.log | /var/ossec/bin/ossec-logtest -a | /var/ossec/bin/ossec-reportd 
2019/09/07 05:20:57 ossec-reportd: INFO: Started (pid: 26840).
2019/09/07 05:20:57 ossec-testrule: INFO: Reading local decoder file.
2019/09/07 05:20:57 ossec-testrule: INFO: Started (pid: 26839).
Report completed. ==
->Processed alerts: 249
->Post-filtering alerts: 249
->First alert: 2019 Sep 07 05:20:57
->Last alert: 2019 Sep 07 05:20:57
Top entries for 'Source ip':
100.200.300.400                                                                |11      |
200.300.400.100                                                                 |2       |
300.400.100.200                                                                 |2       |
::ffff:400.100.200.300                                                        |1       |
::ffff:500.600.700.800                                                        |1       |
::ffff:600.700.800.500                                                          |1       |
::ffff:700.800.500.600                                                          |1       |
Top entries for 'Username':
user1                                                                      |60      |
user2                                                                         |6       |
root                                                                          |6       |
Top entries for 'Level':
Severity 3                                                                    |230     |
Severity 2                                                                    |5       |
Severity 4                                                                    |5       |
Severity 7                                                                    |5       |
Severity 13                                                                   |2       |
Severity 5                                                                    |2       |
Top entries for 'Group':
syslog                                                                        |244     |
pam                                                                           |153     |
authentication_success                                                        |86      |
sudo                                                                          |57      |
sshd                                                                          |13      |
dpkg                                                                          |8       |
errors                                                                        |7       |
config_changed                                                                |5       |
connection_attempt                                                            |4       |
vsftpd                                                                        |4       |
ossec                                                                         |3       |
apache                                                                        |2       |
fts                                                                           |2       |
Top entries for 'Location':
host3->stdin                                                                  |115     |
host2->stdin                                                                  |82      |
host->stdin                                                                   |50      |
(host)->stdin                                                                 | 2      |
Top entries for 'Rule':
5502 - Login session closed.                                                  |82      |
5501 - Login session opened.                                                  |71      |
5402 - Successful sudo to ROOT executed                                       |54      |
5715 - SSHD authentication success.                                           |13      |
1002 - Unknown problem somewhere in the system.                               |5       |
2902 - New dpkg (Debian Package) installed.                                   |5       |
11401 - FTP session opened.                                                   |4       |
2901 - New dpkg (Debian Package) requested to install.                        |3       |
5403 - First time user executed sudo.                                         |3       |
591 - Log file rotated.                                                       |3       |
1003 - Non standard syslog message (size too large).                          |2       |
10100 - First time user logged in.                                            |2       |
31303 - Nginx critical message.                                               |2       |
# Run a report limited to alerts level 7 and above within the passed log file
#    Filters allowed: group, rule, level, location,
#                     user, srcip, filename
#  Examples:
#     -f group authentication_success (to filter on login success)
#     -f level 10 (to filter on level >= 10)
#     -f group authentication -r user srcip (to show srcip for all users)
cat /var/ossec/logs/alerts/alerts.log | /var/ossec/bin/ossec-logtest -a | /var/ossec/bin/ossec-reportd -f level 7
2019/09/07 05:26:49 ossec-reportd: INFO: Started (pid: 26871).
2019/09/07 05:26:49 ossec-testrule: INFO: Reading local decoder file.
2019/09/07 05:26:49 ossec-testrule: INFO: Started (pid: 26870).
2019/09/07 05:26:54 ossec-reportd: INFO: Report completed. Creating output...
Report completed. ==
->Processed alerts: 249
->Post-filtering alerts: 7
->First alert: 2019 Sep 07 05:26:49
->Last alert: 2019 Sep 07 05:26:49
Top entries for 'Level':
Severity 7                                                                    |5       |
Severity 13                                                                   |2       |
Top entries for 'Group':
syslog                                                                        |7       |
config_changed                                                                |5       |
dpkg                                                                          |5       |
errors                                                                        |2       |
Top entries for 'Location':
monitor->stdin                                                                |7       |
Top entries for 'Rule':
2902 - New dpkg (Debian Package) installed.                                   |5       |
1003 - Non standard syslog message (size too large).                          |2       |