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
●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"
●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
●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
●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.
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:
●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:
参考：Log Analysis using OSSEC.pdf
http://www.ossec.net