OSSEC Manual

1 - Getting started

Welcome to the OSSEC HIDS manual! Hopefully it will help you install, configure and use the OSSEC HIDS in a way that best fits your needs. This manual is maintained by Daniel Cid . If you find any errors or think that something is missing, please contact us and we will update it. Questions should be submitted to one of our Mailing lists.
Last modification on 06/Aug/2007 for the Version 1.3.
1.1 - OSSEC HIDS Overview
OSSEC HIDS is an Open Source Host-based Intrusion Detection System. It performs log analysis, file integrity checking, Windows registry monitoring, rootkit detection, time-based alerting and active response.If you have one system to monitor, you can install the OSSEC HIDS locally on that box and do everything from there. However, if you are administering a few systems, you can select one to be your OSSEC server and the others to be OSSEC agents, forwarding events to the server for analysis. One of the greatest benefits of the OSSEC HIDS is its scalability, allowing you to monitor multiple systems from a central point.
1.2 - Understanding the installation “types”
Remember that the OSSEC HIDS is a Host-based IDS (Intrusion Detection System), so you need to install it on every system that you want to monitor. If you have only one machine, like a personal computer or a small server, you will be performing a “local” installation. This type of installation is simpler and customized for just one system. However, if you are administering some kind of network where you have at least a few systems to secure and monitor, you should NOT choose the “local” installation. The best option is to select one of your machines to be the OSSEC server and perform the “server” installation on it. Then, choose the “agent” installation for the others. With this approach, the OSSEC server will receive events from the “agents”, analyze and correlate them and if necessary, generate alerts. Everything from a centralized point. Your IDS and rootkit rules will be just in one box, making it much easier to administer and configure.
1.3 - Installation order
The “installation order” only matters if you are doing a server/agents installation. If you want a “local” installation, just ignore this part. If you don’t know what kind of installation to choose, read the information about it: Installation types. In the server/agents approach, you first need to install the server. On the server, you also need to authorize each agent that you want to send information/events/logs to it. The authorization step is really easy and you just need to run once for each agent. For more information look at Managing the agents.
After the server is done, you need to go to each machine that is going to be an “agent” and perform an “agent installation”. This installation is much simpler and basically will just want to know the IP address of the “server”. Every “agent” will need to have an authentication credential that is generated by the server (when you authorize the agent).

2 - Installation

The installation of the OSSEC HIDS is very simple. Just follow these few steps to have it working.Please make sure that you understand the “type” of installation you are choosing and are also aware of the order. If you don’t know what I’m talking about, it’s a good idea to scroll up your page a little bit and take a look at the Getting started part.
Remember that when following this installation the commands only start after the “#”. Everything before that is just the information about the prompt.

**If you have experience with Unix, just download the latest version, uncompress it and run the “./install.sh” script.

**If you want a step by step guide, you can use one of the many step by step install guides from here.

2.1. Download the latest version and verify its checksum.

**Note that on some systems, the command md5, sha1 or wget may not exist, so try md5sum, sha1sum or lynx respectively instead.

[root@ossec ~]# wget http://www.ossec.net/files/ossec-hids-latest.tar.gz
[root@ossec ~]# wget http://www.ossec.net/files/ossec-hids-latest_sum.txt
[root@ossec ~]# cat ossec-hids-latest_sum.txt
MD5 (ossec-hids-latest.tar.gz) = XXXXXXX
SHA1 (ossec-hids-latest.tar.gz) = YYYYYYYY
[root@ossec ~]# md5 ossec-hids-latest.tar.gz
MD5 (ossec-hids-latest.tar.gz) = XXXXXXX
[root@ossec ~]# sha1 ossec-hids-latest.tar.gz

SHA1 (ossec-hids-latest.tar.gz) = YYYYYYYY


2.2. Extract the compressed package and run the “./install.sh” script (It will guide you through the installation).

[root@ossec ~]# tar -zxvf ossec-hids-*.tar.gz (or gunzip -d; tar -xvf)
[root@ossec ~]# cd ossec-hids-* 

[root@ossec ~]# ./install.sh
..
..


2.3. Remember to open the port 1514 (UDP) if there is a firewall between the server and the agents (if you didn’t choose the local installation).

2.4. In case you are installing the server or the agent, remember to follow the Managing the agents section .


2.5. Start the OSSEC HIDS.

[root@ossec ~]# /var/ossec/bin/ossec-control start

3 - Configuration options

The OSSEC HIDS configuration is mostly done inside the ossec.conf
file (by default at /var/ossec/etc/ossec.conf).
This file must always start with the root element of ossec_config, followed by one of the following configuration sections:

  • global - default options used everywhere in the system.
  • email_alerts - granular e-mail alerting options.
  • rules - list of rules files to be included.
  • syscheck - configuration related to the syscheck - integrity check.
  • rootcheck - configuration related to the rootcheck - rootkit detection.
  • alerts - e-mail and log alerting options.
  • localfile - options related to the log files to be monitored.
  • remote - configuration related to remote connections.
  • client - agent related options.
  • database_output - Database output options.
  • command - active-response configuration.
  • active-response - active-response configuration.

Some of these options should only be used by the “agent” installation and some should only
be used on the “server” or “local” installations. The list bellow shows each installation type and their options:

  • server: global, email_alerts, rules, syscheck, rootcheck, alerts, localfile, remote, command and active-response.
  • local: global, email_alerts, rules, syscheck, rootcheck, alerts, localfile, command and active-response.
  • agent: client, syscheck, rootcheck and localfile.

Global options (”server” and “local” installations):

Inside the “global” element, you can have the following options (example at global_example):

Table 3.1: Global options
Option Default value Allowed values Description
email_notification no yes or no Enable or disable e-mail alerting.
email_to none Any valid e-mail address E-mail recipient of the alerts.
email_from none Any valid e-mail address E-mail “source” of the alerts.
smtp_server none Any valid hostname or IP address SMTP server.
email_maxperhour 12 Any number from 1 to 9999 Specifies the maximum number of e-mails to be sent per hour. It will store the extra ones and send them together if this number is reached.
stats 8 Any level (from 0 to 16) Alerting level for the events generated by the statistical analysis.
logall no yes or no States if we should store all the events received.
memory_size 1024 Any size (from 16 to 5096) Sets the memory size for the event correlation.
white_list none Any IP address or network List of IP addresses that should never be blocked by the active response (one per element).
host_information 8 Any level (from 0 to 16) Alerting level for the events generated by the host change monitor.
prelude_output no yes or no Enables or disables prelude output.

Granular E-mail alerting options (”server” and “local” installations):

Inside the “email_alerts” element, you can have the following options (multiple examples at the wiki entry for Granular Emails):

Table 3.2: Granular Email alerting options
Option Default value Allowed values Description
email_to none Any valid e-mail address E-mail recipient of the alerts.
level none Any level (severity) Minimum alerting level to forward the e-mails.
group none Any group (category) The alert that must match this group to be forwarded.
event_location none Any agent name, ip address or log file The alert must match this event location to be forwarded.
format full Full or SMS Specifies the format of the e-mail (full for normal e-mails or sms for reduced).
do_not_delay not set Set or not set Option to send the e-mail right away (no delay).
do_not_group not set set or not set Option to do not group this e-mail (send by itself).

Rules options (”server” and “local” installations):
Inside the “rules” element, you can have the following options (example at rules_example.xml):

Table 3.2: Rules options
Option Default value Allowed values Description
include syslog_rules.xml Any filename with rules in the XML format Add rules files to be read by the analysis server. They must be inside ‘/var/ossec/rules’ and be one entry per element.

Syscheck options (”server”, “local” and “agent” installations):

More information about syscheck at the FAQ.
Inside the “syscheck” element, you can have the following options (example at syscheck_examples.xml):

Table 3.3: Syscheck options
Option Default value Allowed values Description
directories /etc,/usr/bin,/usr/sbin,/bin,/sbin Any directory or file name Use this option to add or remove directories to be monitored (they must be comma separated).
check_all enabled yes or no Attribute of the “directories” element. It specifies to do all possible integrity checks.
check_sum none yes or no Attribute of the “directories” element. It specifies to use the MD5 to check the integrity of the files.
check_size none yes or no Attribute of the “directories” element. It specifies to check for size changes in the files.
check_owner none yes or no Attribute of the “directories” element. It specifies to check for ownership changes in the files.
check_group none yes or no Attribute of the “directories” element. It specifies to check for group changes in the files.
check_perm none yes or no Attribute of the “directories” element. It specifies to check for permission changes in the files.
ignore /etc/mtab Any file or directory List of files or directories to be ignored (one entry per element).
frequency 7200 (2 hours) Time (in seconds) Frequency that the syscheck is going to be executed (in seconds).
auto_ignore yes yes or no Specifies if syscheck will ignore files that change too often (after the third change)
alert_new_files no yes or no Specifies if syscheck should alert on new files created.
windows_registry HKEY_LOCAL_MACHINE\Software Any registry entry (one per element) Use this option to add Windows registry entries to be monitored (Windows-only).
registry_ignore ..Cryptography\RNG Any registry entry (one per element) List of registry entries to be ignored.

Rootcheck options(”server”, “local” and “agent” installations):
More information about rootcheck here.
Inside the “rootcheck” element, you can have the following options (example at rootcheck_example.xml):

Table 3.4: Rootcheck options
Option Default value Allowed values Description
rootkit_files /etc/shared/rootkit_files.txt A file with the rootkit files signatures You should change this file if you want rootcheck to read the signatures from somewhere else.
rootkit_trojans /etc/shared/rootkit_trojans.txt A file with the trojans signatures You should change this file if you want rootcheck to read the signatures from somewhere else.
scanall no yes or no Tells rootcheck to scan the whole system (may lead to some false positives).
frequency 36000 (10 hours) Time (in seconds) Frequency that the rootcheck is going to be executed (in seconds).
disabled no yes or no Disables the execution of rootcheck.

Alerts options (”server” and “local” installations):
Inside the “alerts” element, you can have the following options (example at alerts_example.xml):

Table 3.5: Alerts options
Option Default value Allowed values Description
email_alert_level 7 Any level (from 1 to 16) Minimum alert level to send e-mail notifications.
log_alert_level 1 Any level (from 1 to 16) Minimum alert level to store the log messages.

Localfile options (”server”, “local” and “agent” installations):
Inside the “localfile” element, you can have the following options (example at localfile_examples.xml):

Table 3.6: Localfile options
Option Default value Allowed values Description
location multiple (eg /var/log/messages) Any log file Specify the location of the log to be read.
log_format multiple (eg syslog) syslog, snort-full, snort-fast, squid, iis, eventlog,nmapg or apache The format of the log being read. If the log has one entry per line, use “syslog”.

Remote options (”server” installation only):

Inside the “remote” element, you can have the following options (example at remote_example.xml):

Table 3.7: Remote options
Option Default value Allowed values Description
connection secure syslog or secure Specify the type of connection being enabled: secure or using syslog.
port 1514 for secure or 514 for syslog Any port number (from 1 to 65535) Specifies the port to listen for events.
allowed-ips none Any IP address or network List of IP addresses that are allowed to send syslog messages to the server (one per element).
denied-ips none Any IP address or network List of IP addresses that are not allowed to send syslog messages to the server(one per element).
local_ip none Any internal ip address Local ip address to listen for connections.

Client options (”agent” installation only):
Inside the “client” element, you can have the following options (example at client_example.xml):

Table 3.8: Client options
Option Default value Allowed values Description
server-ip none Any Valid IP address Specify the IP address of the analysis server.
server-hostname none Any Valid hostname Specify the hostname of the analysis server.
port 1514 Any port number (from 1 to 65535) Specifies the port to send the events (must be the same to the one used by the analysis server).




Database Output options (server/local installations only):
Inside the “database_output” element, you can have the following options (example at database_example.xml):

Table 3.9: Database output options
Option Default value Allowed values Description
hostname none any valid IP address IP Address of the database server.
username none Any Valid username Username to access the database.
password none Any password Password to access the database.
database none Database name Database name to store the alerts.
type none mysql or postgresql Type of the database (Mysql or PostgreSQL).




4 - Log analysis, intrusion detection and correlation rules

The analysis rules are generated in a XML file, where you can dynamically specify what to do with each event received. What really set the OSSEC HIDS engine apart from other tools and makes it really useful is that you can do powerful things with the rules.

  • 4.1 - You can correlate new events with old ones. For example, the rule: 
    <rule id="1608" level="13" timeframe="120">
    <regex>^sshd[d+]: fatal: Local: crc32 compensation attack</regex>
    <if_matched_regex>^sshd[d+]: .+Corrupted check by bytes on</if_matched_regex>

    <comment>SSH CRC-32 Compensation attack</comment>
    <info>http://www.securityfocus.com/bid/2347/info/</info>
</rule>

    will only fire if the “Corrupted check by bytes” log is received within a timeframe of 120 seconds (2 minutes) after the message “crc32 compensation attack” was received.

  • 4.2 - You can extend the above correlation to use groups. For example, the rule 1701 will alert if any rule inside the adduser group is fired within a timeframe of 5 minutes after any rule in the attack group is fired. This rule can detect a possible exploitation followed by the addition of an user.
  • 4.3 - You can create rules based on severities, usernames, ids (snort rules ids), source ips, etc. We have decoders for a variety of log messages and with them we can detect horizontal scans on the network, or a possible attack coming from a specific source ip.
  • 4.4 - You can set the frequency of a specific rule before alerting. For example, only alert if you see 5 missed logins within a period of 5 minutes (or something like that). For web-based logs, for instance, you can setup rules to alert if you see a X number of 404 errors from the same source IP in a timeframe of 2 minutes (probably indicating an web scan).

  • 4.5 - By default, the OSSEC HIDS comes with a large set of rules, so most of your job is simplified. We have rules for IDS correlation, firewalls correlation, web-based logs correlation, spam detection, proxy misuse, brute force attacks, dos attacks, etc.

Take a look at our rule sets for more examples. We are also interested in any help from the community to develop better and stronger rules.

Table 4.1: Signatures options
Option Allowed values Description
level Any number (0 to 16) Attribute. Specifies the level of the rule. Alerts and responses use this value.
id Any number (100 to 99999) Attribute. Specifies the ID of the rule.
accuracy 0 or 1 Attribute. Specifies if the rule is accurate or not (0 is not, 1 is yes).
maxsize Any number (1 to 99999) Attribute. Specifies the maximum size of the event.
frequency Any number (1 to 999) Attribute. Specifies the number of times the rule must have matched before firing it.
timeframe Any number (1 to 9999) Attribute. The timeframe used for the frequency.
ignore Any number (1 to 9999) Attribute. The time to ignore this rule after firing it (to avoid floods).
match Any Pattern Any string to match against the event (log).
regex Any regex Any regex to match against the event(log).
decoded_as Any string Any pre-matched string (see decoders)
category Any category The decoded category to match (ids, syslog, firewall, web-log, squid or windows).
srcip Any srcip Any IP address (decoded as the source ip). Use “!” to negate it.
dstip Any dstip Any IP address (decoded as the dst ip). Use “!” to negate it.
srcport Any srcport Any Source port (match format).
dstport Any dstport Any Destination port (match format).
user Any username Any username (decoded as the username).
program_name Any program_name Program name is decoded from syslog process name.
hostname Any hostname Any hostname (decoded as the syslog hostname).
time Any time range (hh:mm-hh:mm) Time that the event was generated.
weekday Any week day (sunday, monday, weekends, etc) Week day that the event was generated.
id Any ID Any ID (decoded as the ID).
url Any url Any URL (decoded as the URL).
if_sid Any rule id Matches if the ID has matched.
if_group Any group Matches if the group has matched before.
if_level Any level Matches if the level has matched before.
if_matched_sid Any rule id Matches if the ID has matched.
if_matched_group Any group Matches if the group has matched before.
if_matched_level Any level Matches if the level has matched before.
same_source_ip none Used together with frequency. Specifies that the source ip must be the same.
same_source_port none Used together with frequency. Specifies that the source port must be the same.
same_location none Used together with frequency. Specifies that the location must be the same.
description Any string Rule description.
info Any string Extra information about the rule.
cve Any cve CVE related to the rule.
options alert_by_email, no_email_alert, no_log Additional rule options (to do not e-mail/log)

5 - Managing the agents

The communication between the server and the agents is secure (encrypted and authenticated). Because of that, for every “agent” that you want to install, you need to create an “authentication key” for it on the server. When the key is generated on the server, you need export it from there an import on the agent.

**It may sound complicated, but it isn’t. Simply follow the steps bellow.

5.1. First, you need to add the agent to the server. You just need to run the “manage_agents” command, provide the IP Address of the agent and choose a name for it (or username). 

(server)# /var/ossec/bin/manage_agents

****************************************
* OSSEC HIDS v0.8 Agent manager.       *
* The following options are available: *
****************************************
   (A)dd an agent (A).
   (E)xtract key for an agent (E).
   (L)ist already added agents (L).
   (R)emove an agent (R).
   (Q)uit.
Choose your actions: A,E,R or Q: a

- Adding a new agent (use ‘q’ to return to main menu).
  Please provide the following:
    * A name for the new agent: linux1
    * The IP Address for the new agent: 192.168.2.32

    * An ID for the new agent[001]:
Agent information:
    ID:001
    Name:linux1
    IP Address:192.168.2.32

Confirm adding it?(y/n): y
Added.

5.2. After your agent is added, you need to extract the authentication key from your server. In the “manage_agents”, just choose the “E” option and provide the ID of the agent. The key to be used by the agent will be printed. Just copy and paste it in the agent side. 

(server)# /var/ossec/bin/manage_agents

****************************************
* OSSEC HIDS v0.8 Agent manager.       *
* The following options are available: *
****************************************
   (A)dd an agent (A).
   (E)xtract key for an agent (E).
   (L)ist already added agents (L).
   (R)emove an agent (R).
   (Q)uit.
Choose your actions: A,E,R or Q: e

Available agents:
    ID: 001, Name: linux1, IP: 192.168.2.32
    ID: 002, Name: obsd1, IP: 192.168.2.10
Provide the ID of the agent you want to extract the key: 001

Agent key information for ‘001′ is:
CDAxIGxpbnX4MSAxOTIuMTY4LjAuMzIgOWM5MENlYzNXXXYYYZZZZZ==

** Press ENTER to continue

5.3. After you key is generated, you need to copy it and paste it on the agent side. You need to run the same “manage_agents” command in the agent (but it will have some different options). 

(agent)# /var/ossec/bin/manage_agents

****************************************
* OSSEC HIDS v0.8 Agent manager.       *
* The following options are available: *
****************************************
   (I)mport key for the server (I).
   (Q)uit.
   Choose your actions: I or Q: i

* Provide the Key generated from the server.
* The best approach is to cut and paste it.
*** OBS: Do not include spaces or new lines.

Paste it here: CDAxIGxpbnX4MSAxOTIuMTY4LjAuMzIgOWM5MENlYzNXXXYYYZZZZZ==

Agent information:
    ID:001
    Name:linux1
    IP Address:192.168.2.32

Confirm adding it?(y/n): y

Added.
** Press ENTER to continue.

****************************************
* OSSEC HIDS v0.8 Agent manager.       *
* The following options are available: *
****************************************
    (I)mport key for the server (I).
    (Q)uit.
Choose your actions: I or Q: q

manage_agents: Exiting ..

5.4. That’s it. If you have more than one agent, just repeat this process for each one. After that, you can just start the OSSEC HIDS on the server and then on all agents (/var/ossec/bin/ossec-control start).

7 - Active response

Active response allows you to automatically execute “commands” or responses when a specific event or a set of events are triggered. On the OSSEC HIDS, active response is very scalable, allowing you to execute commands on the agent or on the server side.

The benefits of active response are enormous, but there are also risks when using this technology. By default, the OSSEC HIDS tries to minimize some of these risks, but some problems may still arise. Read bellow for an explanation about the risks/advantages of using the active response and also the risk mitigation techniques.

Benefits:

  • - Fast (time-based) response on attacks. If an attack is detected,
    an action can be taken immediately.

  • - Extremely good deterrent against port scans, brute forces and some
    other types of “information gathering” attacks.

Risks:

  • - A false positive may block a legitimate user/host.
  • - An “attacker” may find out that you are using active response
    and try to cause some form of denial of service attack.

Risk mitigation techniques used by the OSSEC HIDS:

  • - Allows you to specify a white list of hosts that should never be blocked.
  • - Comes with granular options, allowing you to only block on rules with low
    false-positive rate.
  • - Allows the specification of timeouts. Even if someone is blocked by mistake,
    after a few minutes he or she will be able to access again.

7.1 Active Response Configuration

The Active response configuration is divided by two parts. In the first one you configure the commands you want to execute. In the second one, you bind the commands to rules or events.

7.1.1 Commands Configuration

In the commands configuration you create new “commands” to be used as responses. You can have as many commands as you want. Each one should be inside their own “command” element. You can see an example here (for the host-deny.sh) and one here (for disable-account.sh). 

<command>
	<name>The name (A-Za-Z0-9)</name>
    	<executable>The command to execute (A-Za-z0-9.-)</executable>
      	<expect>Comma separated list of arguments (A-Za-z0-9)</expect>

        <timeout_allowed>yes/no</timeout_allowed>
</command>

 

  • - name: Used to link the command to the response.
  • - executable: It must be a file (with exec permissions) inside “/var/ossec/active-response/bin”.
    You don’t need to provide the whole path.
  • - expect: The arguments this command is expecting (options are srcip and username).
  • - timeout_allowed: Specifies if this command supports timeout.

7.1.2 Responses Configuration

In the active-response configuration, you bind the commands (created) to events. You can have as many responses as you want. Each one should be inside their own “active-response” element. Examples are here (for blocking based on the severity) and here (for blocking on specific rules). 

<active-response>
    <disabled>Completely disables active response if "yes"</disabled>
    <command>The name of any command already created</command>
    <location>Location to execute the command</location>

    <agent_id>ID of an agent (when using a defined agent) </agent_id>
    <level>The lower level to execute it (0-9)</level>
    <rules_id>Comma separated list of rules id (0-9)</rules_id>
    <rules_group>Comma separated list of groups (A-Za-z0-9)</rules_group>

    <timeout>Time to block</timeout>
</active-response>

 

  • - disabled: Disables active response if set to yes.
  • - command: Used to link the response to the command
  • - location: Where the command should be executed. You have four options:
    • local: on the agent that generated the event,
    • server: on the OSSEC server,
    • defined-agent: on a specific agent (when using this option, you need to set the agent_id to use),
    • all: or everywhere.

  • - agent_id: The ID of the agent to execute the response (when defined-agent is set).

  • - level: The response will be executed on any event with this level or higher.
  • - timeout: How long until the reverse command is executed (IP unblocked, for example).

7.2 Active Response Tools

By default, the ossec hids comes with the following pre-configured
active-response tools:

  • host-deny.sh - Adds an IP to the /etc/hosts.deny file (most Unix systems).
  • firewall-drop.sh (iptables) - Adds an IP to the iptables deny list (Linux 2.4 and 2.6).
  • firewall-drop.sh (ipfilter) - Adds an IP to the ipfilter deny list (FreeBSD, NetBSD and Solaris).
  • firewall-drop.sh (ipfw) - Adds an IP to the ipfw deny table (FreeBSD).
      • *On IPFW we use the table 1 to add the IPs to be blocked. We also
      set this table as deny in the beginning of the firewall list. If you use the
      table 1 for anything else, please change the script to use a different
      table id.
  • firewall-drop.sh (ipsec) - Adds an IP to the ipsec drop table (AIX).
  • firewall-drop.sh (pf) - Adds an IP to a pre-configured pf deny table (OpenBSD and FreeBSD).

      • *On PF, you need to create a table in your config and deny all the
      traffic to it. Add the following lines at the beginning of your
      rules and reload pf (pfctl -F all && pfctl -f /etc/pf.conf):

      table <ossec_fwtable> persist #ossec_fwtable

      block in quick from <ossec_fwtable> to any
      block out quick from any to <ossec_fwtable>

    8 - Windows Agent

    Starting on version 0.8, the OSSEC HIDS Agent will run on Microsoft Windows (NT, 2000, XP and 2003). Since on Windows we only support the Agent (not the full server), you will need an OSSEC server installed on a Unix system to work as the “analysis server”, receiving and interpreting the events from your Windows Agent.

    The Agent on Windows will monitor the Event log and other desired files (including IIS logs). Every time a log (or event) is generated, it will be forwarded to the server for analysis, correlation and alerting. In addition to that, the ossec agent also perform integrity checking of the files and registry monitoring, so you will be able to know when anything is modified on the system (see syscheck).

    The Agent installation is not complicated and you simply have to execute the auto-installation tool. During the installation, you will be asked to import the authentication key from the server and to set the server IP Address.

    When this is completed, use the Manage Agent UI UI to start/stop the agent.

    *The events are sent compressed, encrypted and authenticated to the server.
    *The rootkit detection is not supported on Windows yet.

    Some of the Windows specific log analysis rules are here - windows_rules.xml.

    8.1 IIS logs
    Support for IIS (5 and 6) is available for the NCSA format (web only) and the W3C extended format (for Web, FTP and SMTP)*. By default, the installation scripts will attempt to configure OSSEC to monitor the first virtual hosts for web (W3SVC1 to W3SVC254), ftp (MSFTPSVC1 to MSFTPSVC254) and smtp (SMTPSVC1 to SMTPSVC254). To monitor any other file you need to add a new entry manually.

    In addition to that, make sure to set the log time period to daily and using the local time for file naming and rollover. In the extended logging properties, configure it to log the Date, Time and all the extended properties.

    Look at the following snapshots for IIS 5 examples: snap1, snap2, snap3 and snap4.
    (Thanks to Rick McClinton for the snapshots and testing).

    The following are snapshots for IIS 6: snap1,
    snap2, snap3, snap4.
    (Thanks to Dale Neufeld for the snapshots).

    The following is an example of configuration to monitor the virtual server 2 of IIS web:

          <localfile>
        <location>%WinDir%System32LogFilesW3SVC3ex%y%m%d.log</location>
        <log_format>iis</log_format>
      </localfile>

    Note that:
        %y - means currently year
        %m - means currently month
        %d - means currently day

    *We can easily add support for other IIS log formats. Contact us if you are interested (we will need some log samples).

    9 - Other documents

    These are some of the documents and presentations about OSSEC HIDS and/or intrusion detection
    that may be useful to all of us.