OSSEC基础学习

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

http://www.ossec.net