Understanding OSSEC
●OSSEC two working models
➔Local (useful when you have only one system to monitor)
➔Agent/Server (recommended!)
●By default installed at /var/ossec
●Main configuration file at /var/ossec/etc/ossec.conf
●Decoders stored at /var/ossec/etc/decoders.xml
●Binaries at /var/ossec/bin/
●All rules at /var/ossec/rules/*.xml
●Alerts are stored at /var/ossec/logs/alerts.log
●Composed of multiple processes (all controlled by ossec-control)
●ossec-control manages the start and stop of all of them
➔Analysisd – Does all the analysis (main process)
➔Remoted – Receives remote logs from agents
➔Logcollector – Reads log files (syslog, Flat files, Windows event log, IIS, etc)
➔Agentd – Forwards logs to the server
➔Maild – Sends e-mail alerts
➔Execd – Executes the active responses
➔Monitord – Monitors agent status, compresses and signs log files, etc
兩種工作模式：
Agent/Server network communication
➔Compressed (zlib)
➔Encrypted using pre-shared keys with blowfish
➔By default uses UDP port 1514
➔Multi-platform (Windows, Solaris, Linux, etc)
●Log flow inside analysisd
●Three main parts:
➔Pre-decoding (extracts known fields, like time, etc)
➔Decoding (using user-defined expressions)
➔Signatures (using user-defined rules)
Pre-decodeing：
●Extracts generic information from logs
➔Hostname, program name and time from syslog header
➔Logs must be well formated
Log Decoding：
●Process to identify key information from logs
➔OSSEC comes with hundreds of decoders by default
➔Generally we want to extract source ip, user name, id ,etc
➔User-defined list (XML) at decoders.xml
➔Tree structure inside OSSEC
Writing decoders：
●Writing a decoder. What it requires?
➔Decoders are all stored at etc/decoders.xml
➔Choose a meaningful name so they can be referenced in the rules
➔Extract any relevant information that you may use in the rules
<decoder name="sshd-success">
<program_name>sshd</program_name>
<regex>^Accepted \S+ for (\S+) from (\S+) port </regex>
<order>user, srcip</order>
</decoder>
●Decoders guidelines
➔Decoders must have either prematch or program_name
➔regex is used to extract the fields
➔order is used to specify what each field means
➔Order can be: id, srcip, dstip, srcport, dstport, url, action, status, user, location, etc
➔Offset can be: “after_prematch” or “after_parent”
Vsftpd example:
Sun Jun 4 22:08:39 2006 [pid 21611] [dcid] OK LOGIN: Client "192.168.2.10"
<decoder name="vsftpd">
<prematch>^\w\w\w \w\w\w\s+\d+ \S+ \d+ [pid \d+] </prematch>
<regex offset="after_prematch">Client "(\d+.\d+.\d+.\d+)"$</regex>
<order>srcip</order>
</decoder>
●Grouping multiple decoders under one parent
➔Use parent tag to specify the parent of the decoder
➔Will create a tree structure, where the sub-decoders are only evaluated if their parent matched.
Log Rules：
●Internally stored in a tree structure
●Two types of rules:
➔Atomic (based on a single event)
➔Composite (based on patterns across multiple logs)
●Writing your first rule. What it requires?
➔A Rule id (any integer)
➔A Level - from 0 (lowest) to 15 (highest)
➔Level 0 is ignored, not alerted at all
➔Pattern - anything from “regex”, to “srcip”, “id”, “user”, etc
<rule id=”122” level=”7”>
<if_sid>111</if_sid>
<match>^Failed password</match>
<description>Failed password attempt</description>
</rule>
<rule id=”133” level=”13”>
<if_sid>122</if_sid>
<hostname>^mainserver</hostname>
<srcip>!192.168.2.0/24</srcip>
<description>Higher severity! Failure on the main server</description>
</rule>
●A few more advanced rule options
➔Rule for successful sshd logins
➔Policy-based options, based on time, day of the week, etc
➔You can use groups to classify your rules better
<rule id=”154” level=”10”>
<if_sid>153</if_sid>
<time>6 pm - 8:30 am</time>
<description>Alert! Logins outside business hours!</description>
<group>login_ok,policy_violation</group>
</rule>
●Composite rules
➔Rule for multiple failed password attempts
➔We set frequency and timeframe
➔if_matched_sid: If we see this rule more than X times within Y seconds.
➔same_source_ip: If they were decoded from same IP.
<rule id=”1050” level=”11” frequency=”5” timeframe=”120”>
<if_matched_sid>133</if_matched_sid>
<same_source_ip />
<description>Multiple failed attempts from same IP!</description>
</rule>
Rules in real world
●Do not modify default rules
➔They are overwritten on every upgrade
➔Use local_rules.xml instead (not modified during upgrade)
➔Use and abuse of if_sid, if_group (remember, classify your rules under groups), etc
➔Use an ID within the range 100000-109999 (user assigned)
●Alerting on every authentication success outside business hours
➔Every authentication message is classified as “authentication success” (why we use if_group)
➔Add to local_rules.xml:
<rule id="100005" level="10">
<if_group>authentication_success</if_group>
<time>6 pm - 7:30 am</time>
<description>Login during non-business hours.</description>
</rule>
●Changing frequency or severity of a specific rule
➔Rule 5712 alerts on SSHD brute forces after 6 failed attempts
➔To increase the frequency, just overwrite this rule with a higher value. Same applies to severity (level).
➔You can change any value from the original rule by overwriting it
➔Add to local_rules.xml:
<rule id="5712" level="10" frequency="20" overwrite=”yes”>
<if_matched_sid>5710</if_matched_sid>
<description>SSHD brute force trying to get access to </description>
<description>the system.</description>
<group>authentication_failures,</group>
</rule>
參考：Log Analysis using OSSEC.pdf