Wazuh training for security engineers

CDB Lists

Wazuh CDB Lists

• Classic types of CDB lists:

  • Usernames
  • IP addresses
  • Domain names
  • File hashes

CDB Rule Example

• Here is an example of a custom rule that could be used for threat intel lookups of the queried domains in DNS requests sent to your DNS server.

CDB rule:

<rule id="100334" level="10">
  <!-- child rule of rule 100330 which matches the DNS query log from your
               corporate DNS server -->
  <if_sid>100330</if_sid>
  <list field="domain" lookup="match_key">lists/baddomains</list>
  <description>DNS query for malicious domain!</description>
</rule>

Lab Exercise

CDB Lists with Values

We are not limited to only checking fields for their presence or absence in a given list. CDB Lists can contain both a key (the part to look up) and a value (the part to return). The looked up values can then be used as criteria in rules.

• The possibilities are endless:
  • Account names with department name
    • Alert when user not in finance department logs into finance server.
• IP addresses with threat level
  • Take escalated action if a web connection is seen going to an IP with a threat reputation level of “critical”

Lab Exercise

Wazuh Active Response

Active Response Flow

Wazuh Active Response

• Configured primarily on manager in:

  • /var/ossec/etc/ossec.conf

• On agents, AR can be enabled/disabled in:

  • /var/ossec/etc/ossec.conf

• AR has its own log (on manager and agents):

  • /var/ossec/logs/active-responses.log

• A number of useful AR scripts are included in Wazuh.

• Handle with care!

Wazuh Active Response

• An active response will invoke a command when an alert matches one of the following types of criteria:

  • The alert’s rule ID is specified in <rules_id>.
  • Rule severity being at or above the level specified in <level>.
  • Alert’s groups include one of the groups specified in <rules_group>.

• An active response has several parts:

  • The criteria that triggers the response.
  • The command that we want to execute as the response.
  • The location(s) where to execute the command.
  • The length of time until the action is optionally undone (like unblocking an attacking IP)

Wazuh Active Response

• firewall-drop: adds an IP to the iptables deny list (Linux, Solaris, FreeBSD, AIX only)
• firewalld-drop: adds an IP to the iptables deny list via firewall-cmd (Redhat/CentOS Linux)
• netsh.exe: blocks an IP with native Windows firewall (works on Windows)
• disable-account: disables an account by setting “passwd -l” (Linux, Solaris, AIX only)
• wazuh-slack: posts a message to a Slack channel
• kaspersky: runs an on-demand scan with Kaspersky AV
• More included, plus room for you to build your own!

Uses for Active Response

AR is more than just for reacting to attacks or abuse. Use it wherever you want to take a custom action in response to events that trigger specific Wazuh rules.

• Security countermeasures: block attacking IPs, disable abused account names, etc…
• Custom alerting: collect and assemble detailed information for an email alert about a specific situation
• Recovery actions: respond to certain error logs with automated action to fix the problem

Commands Configuration

Commands Configuration Example:

<command>
       <name>firewall-drop</name>
       <executable>firewall-drop</executable>
       <timeout_allowed>yes</timeout_allowed>
</command>

Response Configuration

Response Configuration example:

<active-response>
       <command>firewall-drop</command>
       <location>local</location>
       <rules_id>5712</rules_id>
       <timeout>600</timeout>
</active-response>

Lab Exercise

Wazuh Integrations

Wazuh Integrations

• Wazuh integrations are run exclusively on the Wazuh Managers
• They are not built to have a timeout or “undo” mechanism
• Simpler to code because all input is done via an temporary alert file
• Built in integrations include: Slack, Virustotal and PagerDuty
• Configuration includes a criteria for running and optional parameters

<integration>
    <name> </name>
    <hook_url> </hook_url> <!-- Required for Slack -->
    <api_key> </api_key> <!-- Required for PagerDuty and VirusTotal -->

    <!-- Optional filters -->
    <rule_id> </rule_id>
    <level> </level>
    <group> </group>
    <event_location> </event_location>
</integration>

Troubleshooting Wazuh

Tools for diagnosis

• tcpdump

  • For troubleshooting network connectivity

• lsof

  • For troubleshooting when files are actually accessed

• strace

  • Advanced analysis of inter-process messages

• ss (formerly netstat)

  • For determining which ports are open and established connections

SCA

Security Configuration Assessment

• Continuous vs cyclical/episodic auditing

  • automated rather than manual
  • very current results
  • all systems checked rather than a sample set

• Policy-based security compliance self-scans

  • numerous SCA policies available
  • most SCA policies aligned with CIS industry benchmarks
  • feature-rich scanning engine
  • policies can be centrally distributed
  • custom policies can augment or replace stock policies.

SCA Engine

• Wazuh built the SCA scanner as a major refactor of the legacy OSSEC rootcheck policy scanning module, vastly improving it.

• The SCA scanning engine can look for patterns in:

  • registry keys, values, and data
  • text files
  • directories
  • the list of running processes
  • output of custom commands
  • compound, regex, & numeric value comparisons supported

Osquery

Lab Exercise

Sysmon

Lab Exercise

Docker

Lab Exercise

Cloud monitoring

Cloud monitoring

• Wazuh is capable of monitoring the accounts of cloud based services such as AWS, GCP, Azure, Office 365 and GitHub.
• Privilege separation is highly encouraged, so a dedicated account with only the powers needed to collect the logs should be created.
• Wazuh periodically collect the logs and analyze them.
• Monitoring cloud based assets and security alerts is crucial.

Wazuh Manager Cluster

Wazuh cluster

Questions

Certificates

Share your Certificate!