GithubHelp home page GithubHelp logo

wazuh-qa's Introduction

Wazuh

Slack Email Documentation Documentation Coverity Twitter YouTube

Wazuh is a free and open source platform used for threat prevention, detection, and response. It is capable of protecting workloads across on-premises, virtualized, containerized, and cloud-based environments.

Wazuh solution consists of an endpoint security agent, deployed to the monitored systems, and a management server, which collects and analyzes data gathered by the agents. Besides, Wazuh has been fully integrated with the Elastic Stack, providing a search engine and data visualization tool that allows users to navigate through their security alerts.

Wazuh capabilities

A brief presentation of some of the more common use cases of the Wazuh solution.

Intrusion detection

Wazuh agents scan the monitored systems looking for malware, rootkits and suspicious anomalies. They can detect hidden files, cloaked processes or unregistered network listeners, as well as inconsistencies in system call responses.

In addition to agent capabilities, the server component uses a signature-based approach to intrusion detection, using its regular expression engine to analyze collected log data and look for indicators of compromise.

Log data analysis

Wazuh agents read operating system and application logs, and securely forward them to a central manager for rule-based analysis and storage. When no agent is deployed, the server can also receive data via syslog from network devices or applications.

The Wazuh rules help make you aware of application or system errors, misconfigurations, attempted and/or successful malicious activities, policy violations and a variety of other security and operational issues.

File integrity monitoring

Wazuh monitors the file system, identifying changes in content, permissions, ownership, and attributes of files that you need to keep an eye on. In addition, it natively identifies users and applications used to create or modify files.

File integrity monitoring capabilities can be used in combination with threat intelligence to identify threats or compromised hosts. In addition, several regulatory compliance standards, such as PCI DSS, require it.

Vulnerability detection

Wazuh agents pull software inventory data and send this information to the server, where it is correlated with continuously updated CVE (Common Vulnerabilities and Exposure) databases, in order to identify well-known vulnerable software.

Automated vulnerability assessment helps you find the weak spots in your critical assets and take corrective action before attackers exploit them to sabotage your business or steal confidential data.

Configuration assessment

Wazuh monitors system and application configuration settings to ensure they are compliant with your security policies, standards and/or hardening guides. Agents perform periodic scans to detect applications that are known to be vulnerable, unpatched, or insecurely configured.

Additionally, configuration checks can be customized, tailoring them to properly align with your organization. Alerts include recommendations for better configuration, references and mapping with regulatory compliance.

Incident response

Wazuh provides out-of-the-box active responses to perform various countermeasures to address active threats, such as blocking access to a system from the threat source when certain criteria are met.

In addition, Wazuh can be used to remotely run commands or system queries, identifying indicators of compromise (IOCs) and helping perform other live forensics or incident response tasks.

Regulatory compliance

Wazuh provides some of the necessary security controls to become compliant with industry standards and regulations. These features, combined with its scalability and multi-platform support help organizations meet technical compliance requirements.

Wazuh is widely used by payment processing companies and financial institutions to meet PCI DSS (Payment Card Industry Data Security Standard) requirements. Its web user interface provides reports and dashboards that can help with this and other regulations (e.g. GPG13 or GDPR).

Cloud security

Wazuh helps monitoring cloud infrastructure at an API level, using integration modules that are able to pull security data from well known cloud providers, such as Amazon AWS, Azure or Google Cloud. In addition, Wazuh provides rules to assess the configuration of your cloud environment, easily spotting weaknesses.

In addition, Wazuh light-weight and multi-platform agents are commonly used to monitor cloud environments at the instance level.

Containers security

Wazuh provides security visibility into your Docker hosts and containers, monitoring their behavior and detecting threats, vulnerabilities and anomalies. The Wazuh agent has native integration with the Docker engine allowing users to monitor images, volumes, network settings, and running containers.

Wazuh continuously collects and analyzes detailed runtime information. For example, alerting for containers running in privileged mode, vulnerable applications, a shell running in a container, changes to persistent volumes or images, and other possible threats.

WUI

The Wazuh WUI provides a powerful user interface for data visualization and analysis. This interface can also be used to manage Wazuh configuration and to monitor its status.

Modules overview

Modules overview

Security events

Overview

Integrity monitoring

Overview

Vulnerability detection

Overview

Regulatory compliance

Overview

Agents overview

Overview

Agent summary

Overview

Orchestration

Here you can find all the automation tools maintained by the Wazuh team.

Branches

  • master branch contains the latest code, be aware of possible bugs on this branch.
  • stable branch on correspond to the last Wazuh stable version.

Software and libraries used

Software Version Author License
bzip2 1.0.8 Julian Seward BSD License
cJSON 1.7.12 Dave Gamble MIT License
cPython 3.10.13 Guido van Rossum Python Software Foundation License version 2
cURL 8.5.0 Daniel Stenberg MIT License
Flatbuffers 23.5.26 Google Inc. Apache 2.0 License
GoogleTest 1.11.0 Google Inc. 3-Clause "New" BSD License
jemalloc 5.2.1 Jason Evans 2-Clause "Simplified" BSD License
Lua 5.3.6 PUC-Rio MIT License
libarchive 3.7.2 Tim Kientzle 3-Clause "New" BSD License
libdb 18.1.40 Oracle Corporation Affero GPL v3
libffi 3.2.1 Anthony Green MIT License
libpcre2 10.42.0 Philip Hazel BSD License
libplist 2.2.0 Aaron Burghardt et al. GNU Lesser General Public License version 2.1
libYAML 0.1.7 Kirill Simonov MIT License
liblzma 5.4.2 Lasse Collin, Jia Tan et al. GNU Public License version 3
Linux Audit userspace 2.8.4 Rik Faith LGPL (copyleft)
msgpack 3.1.1 Sadayuki Furuhashi Boost Software License version 1.0
nlohmann 3.7.3 Niels Lohmann MIT License
OpenSSL 3.0.12 OpenSSL Software Foundation Apache 2.0 License
pacman 5.2.2 Judd Vinet GNU Public License version 2 (copyleft)
popt 1.16 Jeff Johnson & Erik Troan MIT License
procps 2.8.3 Brian Edmonds et al. LGPL (copyleft)
RocksDB 8.3.2 Facebook Inc. Apache 2.0 License
rpm 4.18.2 Marc Ewing & Erik Troan GNU Public License version 2 (copyleft)
sqlite 3.45.0 D. Richard Hipp Public Domain (no restrictions)
zlib 1.3.1 Jean-loup Gailly & Mark Adler zlib/libpng License

Documentation

Get involved

Become part of the Wazuh's community to learn from other users, participate in discussions, talk to our developers and contribute to the project.

If you want to contribute to our project please don’t hesitate to make pull-requests, submit issues or send commits, we will review all your questions.

You can also join our Slack community channel and mailing list by sending an email to [email protected], to ask questions and participate in discussions.

Stay up to date on news, releases, engineering articles and more.

Authors

Wazuh Copyright (C) 2015-2023 Wazuh Inc. (License GPLv2)

Based on the OSSEC project started by Daniel Cid.

wazuh-qa's People

Contributors

adriiiprodri avatar belenvaldivia avatar brauliov avatar camiromero avatar crd1985 avatar damarisg avatar danimegar avatar davidjiglesias avatar deblintrake09 avatar dfolcha avatar fedepacher avatar jesusjimsa avatar jmv74211 avatar joseantoniomherrera avatar jotacarma90 avatar juliamagan avatar mauromalara avatar mcarmona99 avatar mdengra avatar miguelazods avatar nicogp avatar nmkoremblum avatar pereyra-m avatar pro-akim avatar rauldpm avatar rebits avatar selutario avatar snaow avatar vicferpoy avatar vikman90 avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

benhe119 muharihar adampielak spothound savobit kargil-thakur mauceballos bijaysenihang jmv74211 jason-weise isabella232 s-bryce jestemrobotem rework2020 centenera mar171 mariodv95 u16052642 derkodex rakhithjk canuenal victoriastarova panrein-dev zxc1221 githubceomichael jay-anonymous aetesyindan arvindkelvin rrader26 lanaenre

wazuh-qa's Issues

Test: Rootcheck

Testing: Rootcheck

Version Revision Branch
3.9.0 3902 3.9

Rootkit

CentOS 7

  • Check running processes
  • Check hidden ports
  • Check unusual files and permissions
  • Check hidden files using system calls
  • Scan the /dev directory
  • Scan network interfaces
  • Rootkit checks (rootkit_files.txt, rootkit_trojans.txt, win_malware_rcl.txt

Ubuntu 16

  • Check running processes
  • Check hidden ports
  • Check unusual files and permissions
  • Check hidden files using system calls
  • Scan the /dev directory
  • Scan network interfaces
  • Rootkit checks (rootkit_files.txt, rootkit_trojans.txt, win_malware_rcl.txt

Policy Monitoring

Windows 10

  • Check Windows audit
  • Check Windows malware
  • Check Windows application

CentOS 5

  • Check Unix audit, system_audit_rcl.txt, system_audit_ssh.txt, cis_rhel5_linux_rcl.txt

CentOS 6

  • Check Unix audit, system_audit_rcl.txt, system_audit_ssh.txt, cis_rhel6_linux_rcl.txt
  • Check Unix audit , cis_rhel_linux_rcl.txt

CentOS 7

  • Check Unix audit, system_audit_rcl.txt, system_audit_ssh.txt, cis_rhel7_linux_rcl.txt
  • Check Unix audit , cis_rhel_linux_rcl.txt

Ubuntu 16

  • Check Unix audit, system_audit_rcl.txt, system_audit_ssh.txt, cis_debian_linux_rcl.txt

Suse 11

  • Check Unix audit, system_audit_rcl.txt, system_audit_ssh.txt, cis_sles11_linux_rcl.txt

Suse 12

  • Check Unix audit, system_audit_rcl.txt, system_audit_ssh.txt, cis_sles12_linux_rcl.txt

Test: Configuration Assessment

Configuration Assessment test

Version Revision Branch
3.9.0 3902 3.9

Checks for every OS

  • Debian based distributions

  • RHEL/CentOS 7

  • RHEL/CentOS 6

  • RHEL/CentOS 5

  • Suse 11/12

  • Windows XP/Server 2003

  • Windows Server 2012

  • Windows > Vista

  • macOS

Agents

  • Fresh installation. Check the correct policies for each OS are installed at ruleset/configuration-assessment.
  • Check the configuration template contains the module block with the correct policies.
  • Check the rootcheck configuration doesn't contain any setting for policy monitoring.
  • Try to run a policy whose requirements fail.
  • Set an absolute path for a policy out of the default directory.
  • Run scans for every available policy.
  • The second scan just sends differences and summaries.
  • Restart the agent. The whole scan should be sent to the manager but no repeated alerts must appear.
  • Disable a policy (use the attribute enabled) and rerun the scan.

Manager

  • Check results of the first scan:

    • The DB has been filled with all the information.
    • Alerts about new checks and summaries appear in the alerts.log and alerts.json.
    • The API returns information about policies and checks.
    • See alerts on the Kibana Discover and information about the whole scan in the Conf. Assessment tab for the agent.

  • Check results of subsequent scans:

    • The DB is updated.
    • Alert about the different state of a check and summary alert (when any difference)
    • When no differences between scans: Check that no alerts are triggered.
    • The Configuration Assessment tab is updated.

  • Check results when a policy is disabled:

    • The DB must purge the policy information and its checks.
    • No alerts about the disabled policy.
    • The Configuration Assessment tab is updated.

  • Check the configuration on demand:

    • API call.
    • Wazuh App.

Integrity

  • Check the scan results are resend in a random interval between 5 seconds and configuration_assessment.request_db_interval when the integrity check fails.
  • No alerts about a resend are shown.
  • Check the database is updated correctly after a recovery.

Upgrade

  • A warning message appears when Rootcheck is configured for policy monitoring.
  • Wazuh DB must upgrade agent databases including the new tables for Configuration Assessment.
  • Check the correct policies for each OS are installed at ruleset/configuration-assessment.
  • The ruleset upgrade script updates the Configuration Assessment policies.

Memory checks

  • Windows agent. Monitor memory usage and run Dr. Memory.
  • Linux agent. Valgrind in wazuh-modulesd and agentd
  • Manager. Valgrind in remoted, analysisd and wazuh-modulesd.

Test: Registration

Registration test

Version Revision Branch
3.9.0 3902 3.9

Auth system

  • Check the auth daemon is running by default. (Since v3.8.0)
  • Check registration with -m.
  • Check registration with -m and -A.
  • Test force insertion to re-register an agent. (1)
  • Check client keys on manager and agent are equal.
  • Check registration with -m wrong-IP. Must fail.
  • Assign agent to an existing group.
  • Get a descriptive error when trying to assign an agent to an non-existing group.
  • Set the agent IP manually by the -I option.
  • Enable the "use source IP" feature by the -i option.
  • Mix incompatible options like -I <IP> and -i to see the error retrieved.
  • Register an agent using on Windows with agent_auth.

(1) https://documentation.wazuh.com/3.x/user-manual/reference/ossec-conf/auth.html#force-insert

Secure methods

  • Register an agent using a password. (2)
  • Register an agent using SSL. (2)

(2) https://documentation.wazuh.com/3.x/user-manual/registering/use-registration-service.html#secure-methods

Tool manage_agents

  • Check same test as using Authd. (3)
  • Use -F option to remove duplicated agents. (3)

(3) https://documentation.wazuh.com/3.x/user-manual/reference/tools/manage_agents.html

Test: Ruleset

Ruleset test

Version Revision Branch
3.9.0 rc3-3907 3.9

Analysisd performance

  • Check the manager starts with an empty ossec.conf.
  • Change the number of threads used by analysisd in the internal options. Check the performance at var/run/ossec-analysisd.state depending on the threads.
  • Change the value of the queues size of analysisd. Check its behavior when flooded.
  • Check the refresh interval of ossec-analysisd.state matches with the defined analysisd.state_interval at internal options.
  • Check every file is written correctly when enabling/disabling alerts_log, jsonout_output, logall and logall_json options.

Ruleset

  • Trigger alerts which depend on frequency, timeframe, ignore.
  • Trigger alerts which depend on same_fields and not_same_fields.
  • Trigger alerts which depend on if_matched_sid, if_matched_group, same_source_ip, etc.
  • Trigger a custom decoder and rule set at etc/decoders/etc/rules.
  • Overwrite a rule.
  • Make the manager fails when starting by setting a duplicated rule ID, as well as other invalid fields.
  • Decode static and dynamic fields and use them into a rule.
  • Trigger a rule depending on a CDB list.
  • Trigger an alert by using ossec-logtest.

https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html

Ruleset unit tests

  • Run unit tests.

update_ruleset

  • Check major.minor.x.
  • From specific branch.
  • Every argument.

Test: Active response

Testing: Active response

Version Revision Branch
3.9.0 3902 3.9

Active response

  • Insert 2 times same config
  • Test active-response from wrong SO
  • Test active-response from correct SO
  • Check that the execution of the active response respects the location
  • Specifies more than one agent_id
  • Check level filter
  • Check rules_group filter
  • Check rules_id filter
  • Check the period of the reverse command (timeout option)
  • Check incremental timeouts (repeated_offenders)
  • Check the exec daemon runs when active-response is disabled.

Command

  • Insert 2 times same config
  • Configure a command that does not exist
  • Same command for multiple active-response
  • Check that the extra_args option works for any field
  • Check that the expect option works for any field
  • Verify that the return command can be enabled and disabled (timeout_allowed)
  • Set the command below the active response that uses it
  • Test firewall-drop command

agent_control

  • Send an active-response to an agent using agent_control

Custom A-R

Automated tests for Modulesd: osquery

osquery test

On Linux

  • Enable / disable daemon.
  • Check invalid configuration. The module should log a warning and continue.
  • Pack file definitions.
  • Pack folder definition: <pack name="*">/usr/share/osquery/packs/*</pack>.
  • Enrich existing decorators with agent labels.
  • Add labels, no previous decorators defined.
  • Combine <add_labels> and <pack> options.
  • Invalid permissions (owner) for osqueryd binary. It should log an error and stop.
  • osqueryd already running when agent is started. It should log a message every minute.
  • If it tries to start osqueryd before the previous dies on restart, t should reattempt to run one minute later.
  • Try an Invalid path for <log_path> or unexisting log file. The module should reattempt up to one minute delay.
  • Truncate results log (echo -n > osquery.results.log). The module should go back to the file begin, no data lost.
  • Remove results log. The module should finish reading the current file and reload the new one, no data lost.
  • Add query pack folder to a shared folder. That folder should appear in the agent.
  • Agent labels with single quotes: <label key="node">Node for 'nginx'</label>. No SQL code injection.
  • Insert C/C++ comments to JSON configuration. The module should be able to insert decorators and packs.
  • Kill osqueryd while being run by the agent. The module should restart it only if it ran during 10 seconds at less.
  • Unexisting folder /var/osquery. The module should report the error and the manager should create an alert.
  • Declaring osquery module multiple times (ossec.conf and another in agent.conf). Only the last one applies
  • Unexisting configuration with <add_labels> disabled and no <pack>. The module should log it, wait 10 minutes and retry.

On Windows

  • Invalid permissions (owner) for osqueryd binary. It should log an error and stop.
  • osqueryd already running when agent is started. It should log a message every minute.
  • If it tries to start osqueryd before the previous dies on restart, t should reattempt to run one minute later.
  • Truncate results log (echo -n > osquery.results.log). The module should go back to the file begin, no data lost.
  • Remove results log. The module should finish reading the current file and reload the new one, no data lost.
  • Add query pack folder to a shared folder. That folder should appear in the agent.
  • Kill osqueryd while being run by the agent. The module should restart it only if it ran during 10 seconds at less.

Test: Agent management

Agent management test

Version Revision Branch
3.9.0 3902 3.9

agent.conf

  • Check if the "verify-agent-conf" tool verifies the agent.conf including all the modules. (1)
  • Set a configuration for a non-existent agent, OS, or profile. Try to send it to agents. (1)
  • Send by the agent.conf an unrecognizable module for the agent.
  • Agents (Linux/Windows) receive the agent.conf, applying the configuration and restarting the agent automatically. (1)
  • Agents ignore agent.conf when it is specified in the internal options. (1)

(1) https://documentation.wazuh.com/3.x/user-manual/reference/centralized-configuration.html

Labels

  • Set nested labels for an agent in the "agent.conf". (2)
  • Show hidden labels with the internal option of analysisd. (2)
  • Use labels in the "localfile" section for a monitored log file in JSON. (3)

(2) https://documentation.wazuh.com/3.x/user-manual/capabilities/labels.html
(3) https://documentation.wazuh.com/3.x/user-manual/reference/ossec-conf/localfile.html#label

Groups / Multiple groups

  • For all the checks, test the consistency between the API and agent_groups results.
  • Create a group, add agents and send them a centralized configuration. (4)
  • Remove a group, remove agents from a group, and check that they are assigned to the default group. (5)
  • Assign several groups to an agent. Check that the agent receives the merged configuration. (6)
  • Remove an agent from a group. It should belongs to the rest of the groups assigned.
  • Check the synchronization of shared files between groups and agents.
  • Remove a group existing in several multigroups, check if is correctly removed and agents affected.
  • Force a replacement of groups for an agent and check that it changed correctly.
  • Try to assign an agent to an invalid group. Registered and in the registration process with agent-auth.
  • Check if an agent is reassigned to its group(s) after registering it with another name or ID. Enable the internal option remoted.guess_agent_group to enable it.

(4) https://documentation.wazuh.com/3.x/user-manual/agents/grouping-agents.html
(5) https://documentation.wazuh.com/3.x/user-manual/reference/tools/agent_groups.html#examples
(6) https://documentation.wazuh.com/current/user-manual/agents/grouping-agents.html#multiple-groups

Leaky bucket

  • Change the buffer parameters (eps and queue size) to trigger alerts of flooding. (6)
  • Change the threshold levels of the buffer and check that alerts are triggered when they have to. (6)
  • Set a less minimum of eps than it is specified in the parameter "agent.min_eps". (7)
  • Test the agent modules anti-flooding. You can write in a monitored log by logcollector with an infinite loop to do this. (8)

(6) https://documentation.wazuh.com/3.x/user-manual/capabilities/antiflooding.html#how-it-works-leaky-bucket
(7) https://documentation.wazuh.com/3.x/user-manual/reference/internal-options.html#agent
(8) https://documentation.wazuh.com/3.x/user-manual/capabilities/antiflooding.html#anti-flooding-in-agent-modules

agent_control

  • Check that "agent_control" shows agent status in real-time (after 30 minutes). (9)
  • Check that the information provided by the API about agents is consistent with the "agent_control" tool. (10)

(9) https://documentation.wazuh.com/3.x/user-manual/reference/tools/agent_control.html
(10) https://documentation.wazuh.com/3.x/user-manual/api/reference.html#get-all-agents

  • Enable debug mode in the internal options file. (11)

(11) https://documentation.wazuh.com/3.x/user-manual/reference/internal-options.html?highlight=debug%20mode

Test: Logcollector

Logcollector test

Version Revision Branch
3.9.0 3909 3.9

Configuration

  • Add log.
  • Delete all localfile entries and start Logcollector.
  • Test Logcollector internal options.
  • Increase both logcollector.max_files and logcollector.rlimit_nofile and check if everything works with the maximum number of files allowed.

Logs

  • Solve the reading of a file when changing its inode.
  • Check that Eventlog/Eventchannel logs are read in all supported versions of Windows.
  • Truncate file.
  • Check for new paths that match a wildcards after starting Logcollector.
  • Check all the tests changing the order of the parameters in combination with normal and daily wildcards.
  • Check that labels are added to JSON files.
  • Check that the multi-line logs are taken correctly.
  • Check that no duplicate files are scanned (entered multiple times).

Performance

  • Monitor the memory wasted by Logcollector in the previous operations.

Sockets

Commands

  • Prevent remote commands, with command or full_command, if logcollector.remote_commands is disabled.
  • Check that the output of a command is captured line by line (with command) and completely (with full_command)
  • Check the correct output of netstat commands.

Test: Docker integration

docker test

Version Revision Branch
3.9.0 rc3-3907 3.9
  • Enable / disable daemon.
  • Check invalid configuration. The module should log a warning and continue.
  • Run the docker integration and fire alerts when:
    • Create/start/stop/pause/resume/destroy/delete containers.
    • Run a command with exec in a container.
    • Open a shell session in a container.
    • Share files between containers and the host.
    • Create/destroy a volume.
    • Export a filesystem.
    • Create/delete a network.
    • Create/delete a service.

Test: Ruleset

Ruleset test

Version Revision Branch
3.9.0 3904 3.9

Analysisd performance

  • Check the manager starts with an empty ossec.conf.
  • Change the number of threads used by analysisd in the internal options. Check the performance at var/run/ossec-analysisd.state depending on the threads.
  • Change the value of the queues size of analysisd. Check its behavior when flooded.
  • Check the refresh interval of ossec-analysisd.state matches with the defined analysisd.state_interval at internal options.
  • Check every file is written correctly when enabling/disabling alerts_log, jsonout_output, logall and logall_json options.

Ruleset

  • Trigger alerts which depend on frequency, timeframe, ignore.
  • Trigger alerts which depend on if_matched_sid, if_matched_group, same_source_ip, etc.
  • Trigger a custom decoder and rule set at etc/decoders/etc/rules.
  • Overwrite a rule.
  • Make the manager fails when starting by setting a duplicated rule ID, as well as other invalid fields.
  • Decode static and dynamic fields and use them into a rule.
  • Trigger a rule depending on a CDB list.
  • Trigger an alert by using ossec-logtest.

https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html

Ruleset unit tests

  • Run unit tests.

update_ruleset

  • Check major.minor.x.
  • From specific branch.
  • Every argument.

Test: Syscollector

Syscollector test

Version Revision Branch
3.9.0 3902 3.9

Scan

Run a complete Syscollector scan:

  • Operating system.
  • Hardware.
  • Packages.
  • Network interfaces.
  • Ports.
  • Processes.

Test on:

  • Debian.
  • RPM.
  • Centos 5.
  • macOS.
  • Windows.
  • Windows XP/2003.

Configuration

  • Check interval option runs as expected more than the very first time.
  • Send a Syscollector configuration by the shared conf (agent.conf).

Database

  • Upgrade from a version older than v3.8.0. The databases at queue/db/ must be updated.
  • Check that Syscollector info has been stored in the DB of the agent (queue/db/xxx.db).
  • Check that a new scan deletes the previous scan from the DB. [Search by scan_id]
  • Delete the DB of an agent (file 001.db for example) and send a new scan. Is the scan received? Is the DB restored when the manager is restarted?

Test: Command

Command test

Version Revision Branch
3.9.0 3902 3.9

Linux

  • Run a command in Linux.
  • Check all options (interval, ignore_output, ...)
  • Run a command that not finish (set a timeout of 0 letting the process to run indefinitely)
  • Run a command that not finish.
    Set a timeout other than 0 killing the process when it is reached.
  • Try to run an alias (e.g. openssl instead of /usr/bin/openssl).
  • Verify checksums of the defined command.
  • Check interval runs as expected more than the very first time.
  • Try to run wodle command with remote_commands=0.

Windows

  • Run a command in Windows.
  • Check all options (interval, ignore_output, ...)
  • Run a command that not finish (set a timeout of 0 letting the process to run indefinitely).
  • Run a command that not finish (set a timeout other than 0 killing the process when it is reached).
  • Try to run an alias (e.g. ipconfig).
  • Verify checksums of the defined command.
  • Check interval runs as expected more than the very first time.
  • Try to run wodle command with remote_commands=0.

Test: Ansible

Testing: Upgrade Wazuh minor version

Version Revision Branch
3.9.0 3902 3.9.0_6.6.0

Basic tests

  • Deployment of the Wazuh-manager in different environments.

    • Ubuntu 18.04.
    • Ubuntu 14.04.
    • CentOS 7.
    • Amazon Linux.

  • Deployment of the Wazuh-agent in different environments.

    • Ubuntu 18.04.
      • Agent registration.
      • Check the flow of the alerts.
    • Ubuntu 14.04.
      • Agent registration.
      • Check the flow of the alerts.
    • CentOS 7.
      • Agent registration.
      • Check the flow of the alerts.
    • Amazon Linux.
      • Agent registration.
      • Check the flow of the alerts.
    • Windows 7.
      • Agent registration.
      • Check the flow of the alerts.

  • Upgrade of the Wazuh-manager in different environments.

    • Ubuntu 18.04.
    • Ubuntu 14.04.
    • CentOS 7.
    • Amazon Linux.

  • Upgrade of the Wazuh-agent in different environments.

    • Ubuntu 18.04.
      • Agent registration.
      • Check the flow of the alerts.
    • Ubuntu 14.04.
      • Agent registration.
      • Check the flow of the alerts.
    • CentOS 7.
      • Agent registration.
      • Check the flow of the alerts.
    • Amazon Linux.
      • Agent registration.
      • Check the flow of the alerts.
    • Windows 7.
      • Agent registration.
      • Check the flow of the alerts.

  • Deployment of the Wazuh app

Test: Agent key polling

Agent key polling test

Version Revision Branch
3.9.0 3902 3.9

Configuration

  • Configure and enable the agent key polling module. (1)
  • Set up a MySQL Database with a table named "agent" and the fields required in the JSON output. (2)
  • Copy the Python script found at (2).
  • Adjust the script path <exec_path> in you ossec.conf file.

Test

  • Make sure Authd daemon is running.
  • Register an agent and connect it to the manager.
  • Insert the client.keys line for the agent into our database required fields.
  • Delete the agent from the manager (You should see the message Message from 'xxx.yyy.zzz.www' not allowed.).
  • The agent should be registered again by the module (check the client.keys file).

(1) https://documentation.wazuh.com/3.x/user-manual/reference/ossec-conf/wodle-agent-key-polling.html
(2) https://documentation.wazuh.com/3.x/user-manual/capabilities/agent-key-polling.html

Test: Elastic Stack

Elastic Stack test

Version Revision Branch
3.9.0 3902 3.9

Ubuntu

  • Check Elasticsearch logs.
  • Check Logstash logs.
  • Check Filebeat logs.

CentOS

  • Check Elasticsearch logs.
  • Check Logstash logs.
  • Check Filebeat logs.

Test: Windows MSI

Windows MSI

Version Revision Branch
3.9.0 rc4 3.9

Installation

To check in every test:

  • Correct version.

  • WUI doesn't show any strange information.

  • Service is running correctly.

  • No errors in ossec.log.

  • Successful installation by UI

  • Unattended installation

  • Unattended installation with registration parameters

  • Check the options "PEM" and "KEY" with absolute paths. (1)

  • Check the options "PEM" and "KEY" with relative paths.

  • Check the option "CERTIFICATE" with absolute paths. (1)

  • Check the option "CERTIFICATE" with relative paths.

Versions

  • Windows XP
  • Windows Server 2003
  • Windows Vista
  • Windows Server 2008
  • Windows 7
  • Windows Server 2012
  • Windows 8/8.1
  • Windows Server 2016
  • Windows 10
  • Windows Server 2019

Uninstall

To check in every test:

  • It only remains the client.keys, ossec.conf and local_internal_options.conf files.

  • The package and service are removed.

  • Successful uninstallation by running the MSI

  • Successful uninstallation by the Windows control panel

Versions

  • Windows XP
  • Windows Server 2003
  • Windows Vista
  • Windows Server 2008
  • Windows 7
  • Windows Server 2012
  • Windows 8/8.1
  • Windows Server 2016
  • Windows 10
  • Windows Server 2019

Upgrade

To check in every test:

  • It does not overwrite the client.keys, ossec.conf and local_internal_options.conf.

  • WUI doesn't show any strange information.

  • Service is restarted correctly.

  • No errors in ossec.log.

  • No duplicated package when upgrading from the EXE.

  • Upgrade MSI from 3.X.X

  • Upgrade from the current MSI

  • Upgrade MSI from EXE installation 2.X.X

  • Upgrade MSI from EXE installation 3.X.X

  • Check an unattended installation with PEM and KEY from a previous version.

  • Check an unattended installation with CERTIFICATE from a previous version.

Versions

  • Windows XP
  • Windows Server 2003
  • Windows Vista
  • Windows Server 2008
  • Windows 7
  • Windows Server 2012
  • Windows 8/8.1
  • Windows Server 2016
  • Windows 10
  • Windows Server 2019

(1) Use MS-DOS scaping form for paths with spaces. ( "C:\Program Files\sslagent.cert" would be "C:\Progra~1\sslagent.cert" and "C:\Program Files x86\sslagent.cert" would be "C:\Progra~2\sslagent.cert")

Test: Agent management

Agent management test

Version Revision Branch
3.9.0 rc4 3.9

agent.conf

  • Check if the "verify-agent-conf" tool verifies the agent.conf including all the modules. (1)
  • Set a configuration for a non-existent agent, OS, or profile. Try to send it to agents. (1)
  • Send by the agent.conf an unrecognizable module for the agent.
  • Agents (Linux/Windows) receive the agent.conf, applying the configuration and restarting the agent automatically. (1)
  • Agents ignore agent.conf when it is specified in the internal options. (1)

(1) https://documentation.wazuh.com/3.x/user-manual/reference/centralized-configuration.html

Labels

  • Set nested labels for an agent in the "agent.conf". (2)
  • Show hidden labels with the internal option of analysisd. (2)
  • Use labels in the "localfile" section for a monitored log file in JSON. (3)

(2) https://documentation.wazuh.com/3.x/user-manual/capabilities/labels.html
(3) https://documentation.wazuh.com/3.x/user-manual/reference/ossec-conf/localfile.html#label

Groups / Multiple groups

  • For all the checks, test the consistency between the API and agent_groups results.
  • Create a group, add agents and send them a centralized configuration. (4)
  • Remove a group, remove agents from a group, and check that they are assigned to the default group. (5)
  • Assign several groups to an agent. Check that the agent receives the merged configuration. (6)
  • Remove an agent from a group. It should belongs to the rest of the groups assigned.
  • Check the synchronization of shared files between groups and agents.
  • Remove a group existing in several multigroups, check if is correctly removed and agents affected.
  • Force a replacement of groups for an agent and check that it changed correctly.
  • Try to assign an agent to an invalid group. Registered and in the registration process with agent-auth.
  • Check if an agent is reassigned to its group(s) after registering it with another name or ID. Enable the internal option remoted.guess_agent_group to enable it.

(4) https://documentation.wazuh.com/3.x/user-manual/agents/grouping-agents.html
(5) https://documentation.wazuh.com/3.x/user-manual/reference/tools/agent_groups.html#examples
(6) https://documentation.wazuh.com/current/user-manual/agents/grouping-agents.html#multiple-groups

Leaky bucket

  • Change the buffer parameters (eps and queue size) to trigger alerts of flooding. (6)
  • Change the threshold levels of the buffer and check that alerts are triggered when they have to. (6)
  • Set a less minimum of eps than it is specified in the parameter "agent.min_eps". (7)
  • Test the agent modules anti-flooding. You can write in a monitored log by logcollector with an infinite loop to do this. (8)

(6) https://documentation.wazuh.com/3.x/user-manual/capabilities/antiflooding.html#how-it-works-leaky-bucket
(7) https://documentation.wazuh.com/3.x/user-manual/reference/internal-options.html#agent
(8) https://documentation.wazuh.com/3.x/user-manual/capabilities/antiflooding.html#anti-flooding-in-agent-modules

agent_control

  • Check that "agent_control" shows agent status in real-time (after 30 minutes). (9)
  • Check that the information provided by the API about agents is consistent with the "agent_control" tool. (10)

(9) https://documentation.wazuh.com/3.x/user-manual/reference/tools/agent_control.html
(10) https://documentation.wazuh.com/3.x/user-manual/api/reference.html#get-all-agents

  • Enable debug mode in the internal options file. (11)

(11) https://documentation.wazuh.com/3.x/user-manual/reference/internal-options.html?highlight=debug%20mode

Automated tests for Modulesd: command

Command test

Linux

  • Run a command in Linux.
  • Check all options (interval, ignore_output, ...)
  • Run a command that not finish (set a timeout of 0 letting the process to run indefinitely)
  • Run a command that not finish.
    Set a timeout other than 0 killing the process when it is reached.
  • Try to run an alias (e.g. openssl instead of /usr/bin/openssl).
  • Verify checksums of the defined command.
  • Check interval runs as expected more than the very first time.
  • Try to run wodle command with remote_commands=0.

Windows

  • Run a command in Windows.
  • Check all options (interval, ignore_output, ...)
  • Run a command that not finish (set a timeout of 0 letting the process to run indefinitely).
  • Run a command that not finish (set a timeout other than 0 killing the process when it is reached).
  • Try to run an alias (e.g. ipconfig).
  • Verify checksums of the defined command.
  • Check interval runs as expected more than the very first time.
  • Try to run wodle command with remote_commands=0.

Test: Remote upgrades

Remote upgrade test (WPK)

Version Revision Branch
3.9.0 rc3-3907 3.9

Remote upgrades (WPK)

  • Upgrade an agent remotely (Linux and Windows) and check the upgrade.log (UDP)
  • Upgrade an agent remotely (Linux and Windows) and check the upgrade.log (TCP)
  • Upgrade an agent whose register IP is different from its reported IP.
  • Send a WPK with different values of chunk_size.
  • Upgrade an agent with a custom WPK (-f option).
  • Downgrade an agent (-F option).
  • Upgrade an agent without CA verification.

Automated tests for Syslog

Syslog test

Output

  • Send alerts using ports other than 514.
  • Send alerts from the minimum level.
  • Send alerts for a specific group.
  • Send alerts for a specific rule.
  • Send alert in json format.
  • Send alert in splunk format.
  • Send alert in cef format.
  • Send alerts for a specific log location.

Side note
If two identical alerts are sent to the syslog server it won't log them in /var/log/syslog. We must change some fields values between alerts in order to get the information properly.

Automated tests for log rotation

Working branch
log-rotation-tests

Log rotation test

This issue is created with the purpose of developing the necessary tests to test the log rotation functionality (monitord and analysisd).

Related PR is wazuh/wazuh#3175. This tests should be updated if the functionality changes.

Checks [Updated 2019 July 25 ]

  • Check rotation by interval (in archives, alerts and ossec logs).
  • Check rotation by size (in archives, alerts and ossec logs).
  • Check rotation compression.
  • Check maximum logs rotation.
  • Check stress tests (memory leaks).

Logs [Outdated from 2019 July 22]

  • Check the daily rotation of logs and their checksums. *
  • Rotate internal logs by size with the internal options available.
  • Rotate alerts and archives (first day, no previous logs).
  • Rotate alerts and archives (second day, having previous logs).
  • Set the JSON output for every logs if possible (archives, internal logs, etc).
  • Check in JSON log every alert content all default fields:
    • timestamp.
    • rules-id.
    • rule level.
    • rule group.
    • agent id.
    • agent name.
    • agent ip.
    • manager.
    • full log.
    • location.
    • manager name.
    • decoders field.
    • data.
  • This functionality may change.

Test: SCAP

SCAP test

Version Revision Branch
3.9.0 3902 3.9

OpenSCAP

  • Launch a scan on Ubuntu 16.
    XCCDF and OVAL. Check the generated alerts. (1)
  • Launch a scan on Fedora 24.
    XCCDF and OVAL. Check the generated alerts. (1)
  • Launch a scan on CentOS 7.
    XCCDF and OVAL. Check the generated alerts. (1)
  • Launch a scan on Debian.
    XCCDF and oval. Check the generated alerts. (1)
  • Set several content sections and launch a scan. (1)
  • Set a non-existent benchmark, incorrect path and wrong type. Must fail (1)

(1) https://documentation.wazuh.com/3.x/user-manual/reference/ossec-conf/wodle-openscap.html#content

CIS-CAT

Linux agent

  • Launch a scan (XCCDF) and check the generated alerts. (2)
  • Set CIS-CAT path, Java path and benchmark path with absolute and relative paths. (2)
  • Launch a scan with incorrect parameters (incorrect benchmarks). Must fail (2)
  • Launch a scan with incorrect parameters (incorrect CIS-CAT path and JAVA path). Must fail (2)
  • Launch a scan with incorrect parameters (incorrect profile). Must fail (2)
  • Set several content sections and launch a scan. (2)

Windows agent

  • Launch a scan (XCCDF) and check the generated alerts. (2)
  • Set CIS-CAT path, Java path and benchmark path with absolute and relative paths. (2)
  • Launch a scan with incorrect parameters (incorrect benchmarks). Must fail (2)
  • Launch a scan with incorrect parameters (incorrect CIS-CAT path and JAVA path). Must fail (2)
  • Launch a scan with incorrect parameters (incorrect profile). Must fail (2)
  • Set several content sections and launch a scan. (2)

Manager

  • Check that main results of the scans are saved into the table ciscat_results of the DB of each agent.

(2) https://documentation.wazuh.com/3.x/user-manual/reference/ossec-conf/wodle-ciscat.html

Test: Wazuh App

Wazuh App test

Version Revision Branch
3.9.0 3902 3.9

Ubuntu

  • Clean install.
  • Clean install with X-Pack.
  • Upgrade install.
  • Upgrade install with X-pack.

CentOS

  • Clean install.
  • Clean install with X-Pack.
  • Upgrade install.
  • Upgrade install with X-pack.

Test: Logcollector

Logcollector test

Version Revision Branch
3.9.0 3902 3.9

Configuration

  • Add log.
  • Delete all localfile entries and start Logcollector.
  • Test Logcollector internal options.
  • Increase both logcollector.max_files and logcollector.rlimit_nofile and check if everything works with the maximum number of files allowed.

Logs

  • Solve the reading of a file when changing its inode.
  • Check that Eventlog/Eventchannel logs are read in all supported versions of Windows.
  • Truncate file.
  • Check for new paths that match a wildcards after starting Logcollector.
  • Check all the tests changing the order of the parameters in combination with normal and daily wildcards.
  • Check that labels are added to JSON files.
  • Check that the multi-line logs are taken correctly.
  • Check that no duplicate files are scanned (entered multiple times).

Performance

  • Monitor the memory wasted by Logcollector in the previous operations.

Sockets

Commands

  • Prevent remote commands, with command or full_command, if logcollector.remote_commands is disabled.
  • Check that the output of a command is captured line by line (with command) and completely (with full_command)
  • Check the correct output of netstat commands.

Test: Puppet

Testing: Upgrade Wazuh minor version

Version Revision Branch
3.9.0 3902 3.9

Basic tests

  • Deployment of the Wazuh-manager in different environments.

    • Ubuntu 16.04.
    • CentOS 7.

  • Deployment of the Wazuh-agent in different environments.

    • Ubuntu 16.04.
    • Debian 7.
    • CentOS 7.
    • Windows Server 2012.
    • Windows Server 2016.

  • Agent registration.

  • Check the flow of the alerts.

Test: Vulnerability Detector

Vulnerability Detector test

Version Revision Branch
3.9.0 3902 3.9

Database update

  • Check that all OVALs of all operating systems are updated correctly. Debug code: 5451
  • Check that an OVAL is not re-downloaded if it is up to date. Debug code: 5457
  • Check that each OVAL is updated according to its update interval.
  • Download Ubuntu 12 and CentOS 5 OVALs.
  • Check the option update_from_year for the Red Hat feed.

Detection

  • Check that version comparisons make sense. To do this, run a vulnerability detection for one agent in each family in debug mode (level 2), and check debug messages 5467, 5468 and 5456.
    Spend at least 5-10 minutes checking logs of vulnerable and non-vulnerable packages.
  • Check that all supported agents are taken into account.
  • Do not see repeated alerts.
  • Check that there are no false positives in Ubuntu.
  • Check that there are no false positives in CentOS.
  • Check that there are no false positives in Red Hat.
  • Check that there are no false positives in Amazon Linux.
  • Check that there are no false positives in Debian.
  • Test that all vulnerabilities are reported according to the period indicated in ignore_time.
  • Verify that no vulnerabilities of wrong architectures are triggered in RedHat/CentOS agents.
  • Verify that the vulnerability databases are deleted when updating.
  • Verify that a 3.2.X configuration is accepted.
  • Verify that OVAL files can be downloaded from alternate addresses.
  • Verify that OVAL files can be used from local paths.
  • Checks that it does not break when checking the version of unsupported systems such as Debian Sid (1) or Windows.

(1) https://hub.docker.com/r/cantara/debian-sid-zulu-jdk9/

Test: Installation

Installation test

Version Revision Branch
3.9.0 rc4 3.9

RPM (Linux)

  • Successful installation
  • Check version
  • Check ruleset version
  • Service is running after installation
  • Service status
  • Running processes
  • No errors in ossec.log
  • CentOS5
  • Check uninstall (services / files / users)
  • /opt

DEB (Linux)

  • Successful installation
  • Check version
  • Check ruleset version
  • Service is running after installation
  • Service status
  • Running processes
  • Check apt-get remove
  • Check apt-get purge
  • Check uninstall (services / files / users)
  • No errors in ossec.log

Mac OS X

  • Successful installation
  • Check version

Solaris (Intel)

  • Successful installation
  • Check version

Solaris (SPARC)

  • Successful installation
  • Check version

(HP-UX)

  • Successful installation
  • Check version

AIX

  • Successful installation
  • Check version

Sources

  • Successful installation
  • Check version
  • Check ruleset version
  • Service is running after installation
  • Service status
  • Running processes
  • No errors in ossec.log

Automated tests for Logcollector

Logcollector test

Configuration

  • Add log.
  • Delete all localfile entries and start Logcollector.
  • Test Logcollector internal options.
  • Increase both logcollector.max_files and logcollector.rlimit_nofile and check if everything works with the maximum number of files allowed.

Logs

  • Solve the reading of a file when changing its inode.
  • Check that Eventlog/Eventchannel logs are read in all supported versions of Windows.
  • Truncate file.
  • Check for new paths that match a wildcards after starting Logcollector.
  • Check all the tests changing the order of the parameters in combination with normal and daily wildcards.
  • Check that labels are added to JSON files.
  • Check that the multi-line logs are taken correctly.
  • Check that no duplicate files are scanned (entered multiple times).

Performance

  • Monitor the memory wasted by Logcollector in the previous operations.

Sockets

Commands

  • Prevent remote commands, with command or full_command, if logcollector.remote_commands is disabled.
  • Check that the output of a command is captured line by line (with command) and completely (with full_command)
  • Check the correct output of netstat commands.

Test: Use case

Testing: Use case

Version Revision Branch
3.9.0 rc4 3.9

Bruteforce Attack - Linux agent

  • Trigger an alert of bruteforce attack (5712) for a Linux agent.

Bruteforce Attack - Windows agent

  • Trigger an alert of bruteforce attack (18152 for eventlog/ 60104 for eventchannel) for a Windows agent.

Audit user actions - Linux agent

  • Trigger an alert about audit events (rules are located at 0365-auditd_rules.xml).
  • Check that values at the CDB list audit-keys are matched correctly (rule 80792).

Netcat- Linux agent

  • Create a localfile command to collect the list of opened processes.
  • Create a custom rule to catch if netcat is running in the previous processes list.

Shellshock detection - Linux agent

  • Detect a shellshock attack with Apache logs.

https://documentation.wazuh.com/current/learning-wazuh/shellshock.html

IP reputation - Linux agent

  • Create a CDB list containing a black list of IP addresses.
  • Create a custom rule to look for malicious IPs in that CDB list.
  • Use the firewall-drop.sh script to block the IP when the rule is generated.

Changing Windows audit policy - Windows agent

  • Check the rule 18113 (< 3.8.0) or 60013 (>= 3.9.0) is triaged when modifying a Windows security policy.

FIM - Windows agent

  • Create, modify, delete and change the attributes of a file monitored by FIM.

FIM - Linux agent

  • Create, modify, delete and change the permissions and owner of a monitored file.

Rootkit detection - Linux agent

  • Use the rootkit Diamorphine to hide a running process.
  • Get the hidden process alert by a Rootcheck scan.

https://github.com/m0nad/Diamorphine

Detecting a trojan - Linux agent

  • Detect a trojan with Rootcheck by scanning the file rootkit_trojans.txt.

OpenSCAP SSG AND CVE - Linux agent (RedHat 7/CentOS 7)

  • Perform an OpenScap scan with the following configuration.
<wodle name="open-scap">
    <disabled>no</disabled>
    <timeout>1800</timeout>
    <interval>1d</interval>
    <scan-on-start>yes</scan-on-start>

    <content type="xccdf" path="ssg-rhel-7-ds.xml">
        <profile>xccdf_org.ssgproject.content_profile_pci-dss</profile>
        <profile>xccdf_org.ssgproject.content_profile_common</profile>
    </content>
    <content type="xccdf" path="cve-redhat-7-ds.xml"/>
</wodle>
  • Check alerts from both scans are generated.

Virustotal integration - Manager

  • Enable the VirusTotal integration.
  • Create a custom rule to detect when a file monitored by FIM is created in /tmp.
  • In the agent side, insert a known malware into the /tmp folder.

API - Manager

Remote upgrades

  • Create a custom WPK with a future version of Wazuh.
  • Upgrade an agent to that version.
  • Downgrade the agent to the current stable version by the official repository.

Here you can find a guide to creating a custom WPK easily:
https://documentation.wazuh.com/current/user-manual/agents/remote-upgrading/create-custom-wpk.html

Anti flooding mechanisms - Linux agent

  • Flood the agent queue and see flooding alerts.

Analysisd performance - Manager

  • Use the script queue.py to test the Analysis daemon performance.

https://github.com/wazuh/wazuh-tools/blob/master/utils/queue.py

Test: API

Ruleset test

Version Revision Branch
3.9.0 3902 3.9

Installation

  • Install API in a cluster of two nodes. One of the nodes must be a custom directory install. All agents must report to the worker node.
  • Check API status is running in both nodes.

Configuration

  • Custom user, password and https working.

Calls

Certificates and HTTPS

  • Install certificates.
  • Run query using HTTPS.

Test mocha

Required tests:

  • Agents.
  • Decoders.
  • Manager.
  • Cluster.
  • Rootcheck.
  • Rules.
  • Syscheck.
  • Syscollector.

Checks:

  • Master node:
    • Ubuntu 18.
    • CentOS 7.
    • CentOS 6.

Test: Configuration Assessment

SCA test

Version Revision Branch
3.9.0 3909 3.9

Checks for every OS

  • Debian based distributions

  • RHEL/CentOS 7

  • RHEL/CentOS 6

  • RHEL/CentOS 5

  • Suse 11/12

  • Windows XP/Server 2003

  • Windows Server 2012

  • Windows > Vista

  • macOS

Agents

  • Fresh installation. Check the correct policies for each OS are installed at ruleset/configuration-assessment.
  • Check the configuration template contains the module block with the correct policies.
  • Check the rootcheck configuration doesn't contain any setting for policy monitoring.
  • Try to run a policy whose requirements fail.
  • Set an absolute path for a policy out of the default directory.
  • Run scans for every available policy.
  • The second scan just sends differences and summaries.
  • Restart the agent. The whole scan should be sent to the manager but no repeated alerts must appear.
  • Disable a policy (use the attribute enabled) and rerun the scan.

Manager

  • Check results of the first scan:

    • The DB has been filled with all the information.
    • Alerts about new checks and summaries appear in the alerts.log and alerts.json.
    • The API returns information about policies and checks.
    • See alerts on the Kibana Discover and information about the whole scan in the Conf. Assessment tab for the agent.

  • Check results of subsequent scans:

    • The DB is updated.
    • Alert about the different state of a check and summary alert (when any difference)
    • When no differences between scans: Check that no alerts are triggered.
    • The Configuration Assessment tab is updated.

  • Check results when a policy is disabled:

    • The DB must purge the policy information and its checks.
    • No alerts about the disabled policy.
    • The Configuration Assessment tab is updated.

  • Check the configuration on demand:

    • API call.
    • Wazuh App.

Integrity

  • Check the scan results are resend in a random interval between 5 seconds and configuration_assessment.request_db_interval when the integrity check fails.
  • No alerts about a resend are shown.
  • Check the database is updated correctly after a recovery.

Upgrade

  • A warning message appears when Rootcheck is configured for policy monitoring.
  • Wazuh DB must upgrade agent databases including the new tables for Configuration Assessment.
  • Check the correct policies for each OS are installed at ruleset/configuration-assessment.
  • The ruleset upgrade script updates the Configuration Assessment policies.

Memory checks

  • Windows agent. Monitor memory usage and run Dr. Memory.
  • Linux agent. Valgrind in wazuh-modulesd and agentd
  • Manager. Valgrind in remoted, analysisd and wazuh-modulesd.

Test: Ruleset

Ruleset test

Version Revision Branch
3.9.0 3909 3.9

Analysisd performance

  • Check the manager starts with an empty ossec.conf.
  • Change the number of threads used by analysisd in the internal options. Check the performance at var/run/ossec-analysisd.state depending on the threads.
  • Change the value of the queues size of analysisd. Check its behavior when flooded.
  • Check the refresh interval of ossec-analysisd.state matches with the defined analysisd.state_interval at internal options.
  • Check every file is written correctly when enabling/disabling alerts_log, jsonout_output, logall and logall_json options.

Ruleset

  • Trigger alerts which depend on frequency, timeframe, ignore.
  • Trigger alerts which depend on same_fields and not_same_fields.
  • Trigger alerts which depend on if_matched_sid, if_matched_group, same_source_ip, same_user, etc.
  • Trigger a custom decoder and rule set at etc/decoders/etc/rules.
  • Overwrite a rule.
  • Make the manager fails when starting by setting a duplicated rule ID, as well as other invalid fields.
  • Decode static and dynamic fields and use them into a rule.
  • Trigger a rule depending on a CDB list.
  • Trigger an alert by using ossec-logtest.

https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html

Ruleset unit tests

  • Run unit tests.

update_ruleset

  • Check major.minor.x.
  • From specific branch.
  • Every argument.

Automated tests for Syscheck

Description

We need to automate integration tests in order to guarantee that syscheckd behaves like expected. These tests will be written from a 'black box' perspective trying to simulate the interaction with a user. A special effort will be done to test limit and non common cases in addition to the basic functionality.

Stress or service tests are out of the scope and will be faced later in a different issue.

Branch

The main development branch is https://github.com/wazuh/wazuh-qa/tree/fim-integration-tests. All finished work will be merge in this branch before the final merge into master.

Implementation

All integration tests will be written using pytest. Avoiding repeating code is a must. To achieve this, a new Python package will support new tests with the following skeleton:

  • wazuh_testing
    • tools.py: module with generic tools such as log parsing and file handling
    • fim.py: specific utilities to test syscheck module
    • data: auxiliary static data, such as a json schema for syscheck events

Subtasks

The features to be tested will be faced from the most basic to the most complex. The important thing here is preserving the good sense and organization of the code, so the testing framework scale as much as needed.

The following subtasks are proposed:

  • Framework foundations to write tests easier and avoid repeating code (#152)
  • Check basic configurations (including scheduled, whodata, realtime). Intended to test how syscheckd works in a simple environment (a single manager or a single agent) playing with one parameter simultaneously:
    • Linux
      • Check events are generated with minimal configurations (#147)
      • Check ignore parameter (#145 )
      • Check recursion_level parameter (#146 )
      • Check check_* parameters (#149)
      • Check report_changes parameter (#150)
      • Check tags parameter (#148)
      • Check restrict parameter (#164)
      • Check follow_symbolic_link parameter
      • Check nodiff parameter (#166)
      • Check scan_* parameter (#167)
      • Check auto_ignore parameter
      • Check alert_new_files parameter
      • Check prefilter_cmd parameter (#171)
      • Check skip_nfs parameter
      • Check whodata options (#173)
      • Check sync_interval and response_timeout (#174)
    • Windows:
      • Check events are generated with minimal configurations
      • Check ignore parameter
      • Check recursion_level parameter
      • Check check_* parameters
      • Check report_changes parameter
      • Check tags parameter
      • Check restrict parameter
      • Check follow_symbolic_link parameter
      • Check nodiff parameter
      • Check scan_* parameter
      • Check auto_ignore parameter
      • Check alert_new_files parameter
      • Check windows_registry and registry_ignore parameters (only Windows)
      • Check prefilter_cmd parameter
      • Check skip_nfs parameter
      • Check windows_audit_interval (only Windows)
      • Check whodata options
      • Check sync_interval and response_timeout
    • Mac:
      • Check events are generated with minimal configurations
      • Check ignore parameter
      • Check recursion_level parameter
      • Check check_* parameters
      • Check report_changes parameter
      • Check tags parameter
      • Check restrict parameter
      • Check follow_symbolic_link parameter
      • Check nodiff parameter
      • Check scan_* parameter
      • Check auto_ignore parameter
      • Check alert_new_files parameter
      • Check prefilter_cmd parameter
      • Check skip_nfs parameter
      • Check whodata options
      • Check sync_interval and response_timeout
  • Check advanced configurations (including scheduled, whodata, realtime). Intended to test how syscheckd works in a simple environment (a single manager or a single agent) playing with several parameter simultaneously:
    • All basic configurations must be tested before studying the advanced ones.

Automated tests for Modulesd: syscollector

Syscollector test

Scan

Run a complete Syscollector scan:

  • Operating system.
  • Hardware.
  • Packages.
  • Network interfaces.
  • Ports.
  • Processes.

Test on:

  • Debian.
  • RPM.
  • Centos 5.
  • macOS.
  • Windows.
  • Windows XP/2003.

Configuration

  • Check interval option runs as expected more than the very first time.
  • Send a Syscollector configuration by the shared conf (agent.conf).

Database

  • Upgrade from a version older than v3.8.0. The databases at queue/db/ must be updated.
  • Check that Syscollector info has been stored in the DB of the agent (queue/db/xxx.db).
  • Check that a new scan deletes the previous scan from the DB. [Search by scan_id]
  • Delete the DB of an agent (file 001.db for example) and send a new scan. Is the scan received? Is the DB restored when the manager is restarted?

Test: Windows MSI

Windows MSI

Version Revision Branch
3.9.0 3902 3.9

Installation

To check in every test:

  • Correct version.

  • WUI doesn't show any strange information.

  • Service is running correctly.

  • No errors in ossec.log.

  • Successful installation by UI

  • Unattended installation

  • Unattended installation with registration parameters

  • Check the options "PEM" and "KEY" with absolute paths. (1)

  • Check the options "PEM" and "KEY" with relative paths.

  • Check the option "CERTIFICATE" with absolute paths. (1)

  • Check the option "CERTIFICATE" with relative paths.

Versions

  • Windows XP
  • Windows Server 2003
  • Windows Vista
  • Windows Server 2008
  • Windows 7
  • Windows Server 2012
  • Windows 8/8.1
  • Windows Server 2016
  • Windows 10
  • Windows Server 2019

Uninstall

To check in every test:

  • It only remains the client.keys, ossec.conf and local_internal_options.conf files.

  • The package and service are removed.

  • Successful uninstallation by running the MSI

  • Successful uninstallation by the Windows control panel

Versions

  • Windows XP
  • Windows Server 2003
  • Windows Vista
  • Windows Server 2008
  • Windows 7
  • Windows Server 2012
  • Windows 8/8.1
  • Windows Server 2016
  • Windows 10
  • Windows Server 2019

Upgrade

To check in every test:

  • It does not overwrite the client.keys, ossec.conf and local_internal_options.conf.

  • WUI doesn't show any strange information.

  • Service is restarted correctly.

  • No errors in ossec.log.

  • No duplicated package when upgrading from the EXE.

  • Upgrade MSI from 3.X.X

  • Upgrade from the current MSI

  • Upgrade MSI from EXE installation 2.X.X

  • Upgrade MSI from EXE installation 3.X.X

  • Check an unattended installation with PEM and KEY from a previous version.

  • Check an unattended installation with CERTIFICATE from a previous version.

Versions

  • Windows XP
  • Windows Server 2003
  • Windows Vista
  • Windows Server 2008
  • Windows 7
  • Windows Server 2012
  • Windows 8/8.1
  • Windows Server 2016
  • Windows 10
  • Windows Server 2019

(1) Use MS-DOS scaping form for paths with spaces. ( "C:\Program Files\sslagent.cert" would be "C:\Progra~1\sslagent.cert" and "C:\Program Files x86\sslagent.cert" would be "C:\Progra~2\sslagent.cert")

Test: Syslog

Syslog test

Version Revision Branch
3.9.0 3902 3.9

Output

  • Send alerts using ports other than 514.
  • Send alerts from the minimum level.
  • Send alerts for a specific group.
  • Send alerts for a specific rule.
  • Send alert in json format.
  • Send alert in splunk format.
  • Send alert in cef format.
  • Send alerts for a specific log location.

Side note
If two identical alerts are sent to the syslog server it won't log them in /var/log/syslog. We must change some fields values between alerts in order to get the information properly.

Test: Integrator

Integrator test

Version Revision Branch
3.9.0 3902 3.9

VirusTotal

Configuration

  • Configure the VirusTotal integration. (1)
  • Get an alert: "Incorrect API credentials". (1)
  • Get the alert: "Rate limit reached". (1)

Scan

  • Monitor a folder in real-time, getting "not found" alerts by VT. (1)
  • Monitor a file and scanning it. (1)
  • Monitor a malicious file getting a "positive" alert found by VT. (1)

(1) https://documentation.wazuh.com/3.x/user-manual/capabilities/virustotal-scan/integration.html?highlight=integrator

Slack

  • Configure the Slack integration and get alerts on Slack.

PagerDuty

  • Configure the PagerDuty integration. (2)
  • Get alerts on the PagerDuty Dashboard. (2)

(2) https://documentation.wazuh.com/3.x/user-manual/manager/manual-integration.html?highlight=integrator

Test: Maild

Maild test

Version Revision Branch
3.9.0 3902 3.9

Send reports

  • Configure the mail alerts and receive an alert in your email.

Configuration

  • Check the typical settings such as email_reply_to.
  • Test the option email_log_source since Wazuh v3.8.0.

Filters

  • Check filters: email_maxperhour, level, group, etc...

Test: Installation

Installation test

Version Revision Branch
3.9.0 3902 3.9

RPM (Linux)

  • Successful installation
  • Check version
  • Check ruleset version
  • Service is running after installation
  • Service status
  • Running processes
  • No errors in ossec.log
  • CentOS5
  • Check uninstall (services / files / users)
  • /opt

DEB (Linux)

  • Successful installation
  • Check version
  • Check ruleset version
  • Service is running after installation
  • Service status
  • Running processes
  • Check apt-get remove
  • Check apt-get purge
  • Check uninstall (services / files / users)
  • No errors in ossec.log

Mac OS X

  • Successful installation
  • Check version

Solaris (Intel)

  • Successful installation
  • Check version

Solaris (SPARC)

  • Successful installation
  • Check version

(HP-UX)

  • Successful installation
  • Check version

AIX

  • Successful installation
  • Check version

Sources

  • Successful installation
  • Check version
  • Check ruleset version
  • Service is running after installation
  • Service status
  • Running processes
  • No errors in ossec.log

Test: Communication

Communication test

Version Revision Branch
3.9.0 3902 3.9

Manager - agent

  • Connect an agent by UDP successfully and verify alerts and services work properly. (1)
  • Connect an agent by TCP successfully and verify alerts and services work properly. (1)
  • Connect an agent with a different port. (1)
  • Agent re-connects succesfully after a manager recovery.
  • Test both crypto methods available (AES and blowfish).
  • Configure several managers to an agent, check if it works. (1)
  • Test large messages (up to 64K) (3).
  • Test large labels (up to 20K).
  • Connect to a manager by resolving its domain with DNS. (1)
  • Use legacy configuration (server-ip, server-hostname, protocol, port).
  • Check statistics files for analysisd, remoted and agentd.

(1) https://documentation.wazuh.com/3.x/user-manual/reference/ossec-conf/client.html
(3) You have to write the alert in a monitorized log, for example: active-response.log

Syslog events

  • Send syslog events from an agent to the manager (UDP/TCP). (2)
  • Deny the IP of an agent and check that is not allowed to send events. (2)
  • Specify a local_ip in the manager for receive syslog events. (2)

(2) https://documentation.wazuh.com/3.x/user-manual/reference/ossec-conf/remote.html

Test: Syscheck

Testing: Syscheck

Version Revision Branch
3.9.0 3909 3.9

Any

  • Check if ignore files and folders using tag and restrict option (string or sregex) in both options.
  • Check if delete content in /var/ossec/queue/diff when deleting any tag
  • Check if delete content in /var/ossec/queue/diff when report_changes option passed yes to no.

Frequency

Linux

  • Check syscheck alert for adding a file
  • Check syscheck alert for adding text to a file
  • Check syscheck alert for deleting text from a file
  • Check syscheck alert with report_changes option
  • Check syscheck alert for changing owner of file
  • Check syscheck alert for changing group of file
  • Check syscheck alert for changing file permissions
  • Check values different values for options 'check_sum', 'check_md5sum', 'check_sha1sum','check_sha256sum'
  • Check syscheck alert for deleting a file
  • Check recursion level option (recursion_level=0, recursion_level=2 check folder level 0, 1, 2 and 3)
  • Check the option follow_symbolic_link (Since v3.8.0)

Windows

  • Check syscheck alert for adding a file
  • Check syscheck alert for adding text to a file
  • Check syscheck alert for deleting text from a file
  • Check syscheck alert with report_changes option and last-entry files are stored compressed.
  • Check syscheck alert for changing owner of file
  • Check syscheck alert for changing file permissions
  • Check values diferent values for options 'check_sum', 'check_md5sum', 'check_sha1sum','check_sha256sum'
  • Check syscheck alert for deleting a file
  • Check recursion level option (recursion_level=0, recursion_level=2 check folder level 0, 1, 2 and 3)

Realtime

Linux

  • Check syscheck alert for adding a file
  • Check syscheck alert for adding text to a file
  • Check syscheck alert for deleting text from a file
  • Check syscheck alert with report_changes option
  • Check the "nodiff" option to don't show the changes of a file
  • Check syscheck flag auto_ignore with attributes "frequency" and "timeframe" (1)
  • Check syscheck alert for changing owner of file
  • Check syscheck alert for changing group of file
  • Check syscheck alert for changing file permissions
  • Check values diferent values for options 'check_sum', 'check_md5sum', 'check_sha1sum','check_sha256sum'
  • Check syscheck alert for deleting a file
  • Check recursion level option (recursion_level=0, recursion_level=2 check folder level 0, 1, 2 and 3)
  • Check the option follow_symbolic_link (Since v3.8.0)

Windows

  • Check syscheck alert for adding a file
  • Check syscheck alert for adding text to a file
  • Check syscheck alert for deleting text from a file
  • Check syscheck alert with report_changes option
  • Check the "nodiff" option to don't show the changes of a file
  • Check syscheck flag auto_ignore with attributes "frequency" and "timeframe" (1)
  • Check syscheck alert for changing attributes of a file
  • Check syscheck alert for changing file permissions
  • Check values diferent values for options 'check_sum', 'check_md5sum', 'check_sha1sum','check_sha256sum'
  • Check syscheck alert for deleting a file
  • Check recursion level option (recursion_level=0, recursion_level=2 check folder level 0, 1, 2 and 3)

(1) wazuh/wazuh#605

Who-data

Linux

  • Check syscheck alert for adding a file
  • Check syscheck alert for moving a file
  • Check syscheck alert for modifying a file
  • Check syscheck alert for deleting a file
  • Check syscheck alert for deleting a folder
  • Check syscheck alert for changing file permissions
  • Check syscheck alert for changing owner of file
  • Check syscheck alert for changing group of file
  • Check recursive commands.
  • Check audit rules added (auditctl -l)
  • Check audit rules removed (auditctl -l)
  • Remove audit rule manually and check if the rule is reloaded. (Auto-reload each 30 seconds)
  • Remove rules 5 times and check if whodata stops and realtime is started. (Check alert)
  • Remove monitored folder and check if the rule is removed and re-add the folder. The rule must be re-added.
  • Add blocking rule in audit and check whodata logs and alert. (auditctl -a never,task)
  • Restart auditd. Check whodata connection retries.
  • Stop auditd. Move to realtime.
  • Check modifications in a file changed from whodata to realtime.
  • Check whodata in Amazon Linux.
  • Check the option follow_symbolic_link only for directories, not files. (Since v3.8.0)

Windows

  • Check syscheck alert for adding a file
  • Check syscheck alert for moving a file
  • Check syscheck alert for modifying a file
  • Check syscheck alert for deleting a file

Test: Monitord

Monitord test

Version Revision Branch
3.9.0 3902 3.9

Logs

  • Check the daily rotation of logs and their checksums.
  • Rotate internal logs by size with the internal options available.
  • Rotate alerts and archives (first day, no previous logs).
  • Rotate alerts and archives (second day, having previous logs).
  • Set the JSON output for every logs if possible (archives, internal logs, etc).
  • Check in JSON log every alert content all default fields:
    • timestamp.
    • rules-id.
    • rule level.
    • rule group.
    • agent id.
    • agent name.
    • agent ip.
    • manager.
    • full log.
    • location.
    • manager name.
    • decoders field.
    • data.

Test: Cluster

Cluster test

Version Revision Branch
3.9.0 3902 3.9

Installation

  • Installation by default: Run /var/ossec/bin/wazuh-clusterd -f
  • Installation by default: Run /var/ossec/bin/wazuh-clusterd -f
  • Installation by default - centos6: Run /var/ossec/bin/wazuh-clusterd -f

Configuration

  • Configure cluster: No key.
  • Configure cluster: Wrong key.
  • Configure cluster: Wrong node type.
  • Configure cluster: Wrong master node IP.

Cluster

  • Start the master before/after the clients.
  • Change path to opt in master and var in clients.
  • Synchronization process when one of the clients is down.
  • Stop master and start it after some time.
  • Disconnect worker node internet connection and check it disconnects after 2 minutes. Check the master node removes that node. Connect the node to the internet again and check itreconnects to the master node without restarting (wazuh/wazuh#1482).
  • Disconnect worker and reconnect it again to the internet in less than 2 minutes. Check it keeps working as usual (wazuh/wazuh#1482).

Cluster control

  • Master
    • check cluster_control -l
    • check cluster_control -a
    • check cluster_control -i
  • Worker
    • check cluster_control -l
    • check cluster_control -a
    • check cluster_control -i

Agents

  • Register an agent in master and point it to a client.
    The client.keys must be propagated and the agent must be reporting. Then, if the agents are listed in the master, it must be Active.
  • cluster-control -a must show the agents information and the manager.
  • Connect the previous agent to a different client and review logs/alerts. It must be transparent for the user.
  • Remove an agent in master. It must be removed in all the clients.

Groups

  • Create a new group.
  • Create a file in a group.
  • Modify a file in a group.
  • Remove a file in a group.
  • Remove group.
  • Re-create a removed group.
  • Assign agent to a group.
  • Unassign agent group.
    • Assign a group in a client using md5. Then, check if it is propagated to the master.

Ruleset

  • Modify a file in the rules/decoders/lists directory.
  • Add a file in the rules/decoders/lists directory.
  • Remove a file in the rules/decoders/lists directory.

Performance

  • 1 master, 10 clients, 100k agent-info and agent-groups.

Test: AWS

Amazon Web Services test

Version Revision Branch
3.9.0 3902 3.9

RPM (Linux)

  • Configure ossec.conf to use different services and check manager logs:
    • CloudTrail.
    • Config.
    • VPC.
    • GuardDuty.
    • Inspector.
    • Macie (custom).
    • KMS (custom).
    • TrustedAdvisor (custom).
  • Check wodle related alerts are being stored in alerts.json.
  • Configure AWS in Wazuh v3.5 and check it correctly upgrades to the latest version.
  • Check configurations of multiple regions.
  • Check pull of logs from CloudTrail.
  • Check pull of logs from Config (AWS doesn't store Config logs by lexicographical order).
  • Check pull of logs from VPC (flow log id makes that logs don't follow lexicographical order).
  • Check pull of logs from KMS (custom).
  • Check databases:
    • s3_cloudtrail.db.
    • aws_services.
  • Wazuh apps tab show the alerts:
    • Kibana.
    • Splunk.
  • Check alerts on Wazuh apps:
    • Kibana.
    • Splunk.

Test: Use case

Testing: Use case

Version Revision Branch
3.9.0 3902 3.9

Bruteforce Attack - Linux agent

  • Trigger an alert of bruteforce attack (5712) for a Linux agent.

Bruteforce Attack - Windows agent

  • Trigger an alert of bruteforce attack (18152) for a Windows agent.

Audit user actions - Linux agent

  • Trigger an alert about audit events (rules are located at 0365-auditd_rules.xml).
  • Check that values at the CDB list audit-keys are matched correctly (rule 80792).

Netcat- Linux agent

  • Create a localfile command to collect the list of opened processes.
  • Create a custom rule to catch if netcat is running in the previous processes list.

Shellshock detection - Linux agent

  • Detect a shellshock attack with Apache logs.

https://documentation.wazuh.com/current/learning-wazuh/shellshock.html

IP reputation - Linux agent

  • Create a CDB list containing a black list of IP addresses.
  • Create a custom rule to look for malicious IPs in that CDB list.
  • Use the firewall-drop.sh script to block the IP when the rule is generated.

Changing Windows audit policy - Windows agent

  • Check the rule 18113 (< 3.8.0) or 20053 (>= 3.8.0) is triaged when modifying a Windows security policy.

FIM - Windows agent

  • Create, modify, delete and change the attributes of a file monitored by FIM.

FIM - Linux agent

  • Create, modify, delete and change the permissions and owner of a monitored file.

Rootkit detection - Linux agent

  • Use the rootkit Diamorphine to hide a running process.
  • Get the hidden process alert by a Rootcheck scan.

https://github.com/m0nad/Diamorphine

Detecting a trojan - Linux agent

  • Detect a trojan with Rootcheck by scanning the file rootkit_trojans.txt.

OpenSCAP SSG AND CVE - Linux agent (RedHat 7/CentOS 7)

  • Perform an OpenScap scan with the following configuration.
<wodle name="open-scap">
    <disabled>no</disabled>
    <timeout>1800</timeout>
    <interval>1d</interval>
    <scan-on-start>yes</scan-on-start>

    <content type="xccdf" path="ssg-rhel-7-ds.xml">
        <profile>xccdf_org.ssgproject.content_profile_pci-dss</profile>
        <profile>xccdf_org.ssgproject.content_profile_common</profile>
    </content>
    <content type="xccdf" path="cve-redhat-7-ds.xml"/>
</wodle>
  • Check alerts from both scans are generated.

Virustotal integration - Manager

  • Enable the VirusTotal integration.
  • Create a custom rule to detect when a file monitored by FIM is created in /tmp.
  • In the agent side, insert a known malware into the /tmp folder.

API - Manager

Remote upgrades

  • Create a custom WPK with a future version of Wazuh.
  • Upgrade an agent to that version.
  • Downgrade the agent to the current stable version by the official repository.

Here you can find a guide to create a custom WPK easily:
https://documentation.wazuh.com/current/user-manual/agents/remote-upgrading/create-custom-wpk.html

Anti flooding mechanisms - Linux agent

  • Flood the agent queue and see flooding alerts.

Analysisd performance - Manager

  • Use the script queue.py to test the Analisys daemon performance.

https://github.com/wazuh/wazuh-tools/blob/master/utils/queue.py

Test: Azure-logs

Azure module

Version Revision Branch
3.9.0 3902 3.9

This module collects logs from three Azure APIs (log analytics, graphs and storage).

Manager (Linux)

  • Configure ossec.conf to request logs from the three available APIs.
  • Check wodle related alerts are being stored in alerts.json.
  • Try to configure the module in agents. It should show a descriptive error message.
  • Configure multiple log analytics and graph APIs with multiple requests.
  • Configure multiple Storage APIs with multiple containers.

Test: osquery

osquery test

Version Revision Branch
3.9.0 3902 3.9

On Linux

  • Enable / disable daemon.
  • Check invalid configuration. The module should log a warning and continue.
  • Pack file definitions.
  • Pack folder definition: <pack name="*">/usr/share/osquery/packs/*</pack>.
  • Enrich existing decorators with agent labels.
  • Add labels, no previous decorators defined.
  • Combine <add_labels> and <pack> options.
  • Invalid permissions (owner) for osqueryd binary. It should log an error and stop.
  • osqueryd already running when agent is started. It should log a message every minute.
  • If it tries to start osqueryd before the previous dies on restart, t should reattempt to run one minute later.
  • Try an Invalid path for <log_path> or unexisting log file. The module should reattempt up to one minute delay.
  • Truncate results log (echo -n > osquery.results.log). The module should go back to the file begin, no data lost.
  • Remove results log. The module should finish reading the current file and reload the new one, no data lost.
  • Add query pack folder to a shared folder. That folder should appear in the agent.
  • Agent labels with single quotes: <label key="node">Node for 'nginx'</label>. No SQL code injection.
  • Insert C/C++ comments to JSON configuration. The module should be able to insert decorators and packs.
  • Kill osqueryd while being run by the agent. The module should restart it only if it ran during 10 seconds at less.
  • Unexisting folder /var/osquery. The module should report the error and the manager should create an alert.
  • Declaring osquery module multiple times (ossec.conf and another in agent.conf). Only the last one applies
  • Unexisting configuration with <add_labels> disabled and no <pack>. The module should log it, wait 10 minutes and retry.

On Windows

  • Invalid permissions (owner) for osqueryd binary. It should log an error and stop.
  • osqueryd already running when agent is started. It should log a message every minute.
  • If it tries to start osqueryd before the previous dies on restart, t should reattempt to run one minute later.
  • Truncate results log (echo -n > osquery.results.log). The module should go back to the file begin, no data lost.
  • Remove results log. The module should finish reading the current file and reload the new one, no data lost.
  • Add query pack folder to a shared folder. That folder should appear in the agent.
  • Kill osqueryd while being run by the agent. The module should restart it only if it ran during 10 seconds at less.

Test: Upgrade

Upgrade test

Version Revision Branch
3.9.0 3902 3.9

RPM (Linux)

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

DEB (Linux)

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

macOS

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

Solaris (Intel)

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

Solaris (SPARC)

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

HP-UX

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

AIX

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

Sources

  • Check the upgrade building the source code.
  • Check that the databases located at queue/db are upgraded.

Remote upgrades (WPK)

  • Upgrade an agent remotely (Linux and Windows) and check the upgrade.log (Use UDP and TCP).
  • Upgrade an agent with a custom WPK.
  • Upgrade an agent without CA verification.
  • Downgrade an agent (option -F).

Test: Syscheck

Testing: Syscheck

Version Revision Branch
3.9.0 3904 3.9

Any

  • Check if ignore files and folders using tag and restrict option (string or sregex) in both options.
  • Check if delete content in /var/ossec/queue/diff when deleting any tag
  • Check if delete content in /var/ossec/queue/diff when report_changes option passed yes to no.

Frequency

Linux

  • Check syscheck alert for adding a file
  • Check syscheck alert for adding text to a file
  • Check syscheck alert for deleting text from a file
  • Check syscheck alert with report_changes option
  • Check syscheck alert for changing owner of file
  • Check syscheck alert for changing group of file
  • Check syscheck alert for changing file permissions
  • Check values different values for options 'check_sum', 'check_md5sum', 'check_sha1sum','check_sha256sum'
  • Check syscheck alert for deleting a file
  • Check recursion level option (recursion_level=0, recursion_level=2 check folder level 0, 1, 2 and 3)
  • Check the option follow_symbolic_link (Since v3.8.0)

Windows

  • Check syscheck alert for adding a file
  • Check syscheck alert for adding text to a file
  • Check syscheck alert for deleting text from a file
  • Check syscheck alert with report_changes option and last-entry files are stored compressed.
  • Check syscheck alert for changing owner of file
  • Check syscheck alert for changing file permissions
  • Check values diferent values for options 'check_sum', 'check_md5sum', 'check_sha1sum','check_sha256sum'
  • Check syscheck alert for deleting a file
  • Check recursion level option (recursion_level=0, recursion_level=2 check folder level 0, 1, 2 and 3)

Realtime

Linux

  • Check syscheck alert for adding a file
  • Check syscheck alert for adding text to a file
  • Check syscheck alert for deleting text from a file
  • Check syscheck alert with report_changes option
  • Check the "nodiff" option to don't show the changes of a file
  • Check syscheck flag auto_ignore with attributes "frequency" and "timeframe" (1)
  • Check syscheck alert for changing owner of file
  • Check syscheck alert for changing group of file
  • Check syscheck alert for changing file permissions
  • Check values diferent values for options 'check_sum', 'check_md5sum', 'check_sha1sum','check_sha256sum'
  • Check syscheck alert for deleting a file
  • Check recursion level option (recursion_level=0, recursion_level=2 check folder level 0, 1, 2 and 3)
  • Check the option follow_symbolic_link (Since v3.8.0)

Windows

  • Check syscheck alert for adding a file
  • Check syscheck alert for adding text to a file
  • Check syscheck alert for deleting text from a file
  • Check syscheck alert with report_changes option
  • Check the "nodiff" option to don't show the changes of a file
  • Check syscheck flag auto_ignore with attributes "frequency" and "timeframe" (1)
  • Check syscheck alert for changing attributes of a file
  • Check syscheck alert for changing file permissions
  • Check values diferent values for options 'check_sum', 'check_md5sum', 'check_sha1sum','check_sha256sum'
  • Check syscheck alert for deleting a file
  • Check recursion level option (recursion_level=0, recursion_level=2 check folder level 0, 1, 2 and 3)

(1) wazuh/wazuh#605

Who-data

Linux

  • Check syscheck alert for adding a file
  • Check syscheck alert for moving a file
  • Check syscheck alert for modifying a file
  • Check syscheck alert for deleting a file
  • Check syscheck alert for deleting a folder
  • Check syscheck alert for changing file permissions
  • Check syscheck alert for changing owner of file
  • Check syscheck alert for changing group of file
  • Check recursive commands.
  • Check audit rules added (auditctl -l)
  • Check audit rules removed (auditctl -l)
  • Remove audit rule manually and check if the rule is reloaded. (Auto-reload each 30 seconds)
  • Remove rules 5 times and check if whodata stops and realtime is started. (Check alert)
  • Remove monitored folder and check if the rule is removed and re-add the folder. The rule must be re-added.
  • Add blocking rule in audit and check whodata logs and alert. (auditctl -a never,task)
  • Restart auditd. Check whodata connection retries.
  • Stop auditd. Move to realtime.
  • Check modifications in a file changed from whodata to realtime.
  • Check whodata in Amazon Linux.
  • Check the option follow_symbolic_link only for directories, not files. (Since v3.8.0)

Windows

  • Check syscheck alert for adding a file
  • Check syscheck alert for moving a file
  • Check syscheck alert for modifying a file
  • Check syscheck alert for deleting a file

Test: Upgrade

Upgrade test

Version Revision Branch
3.9.0 rc4 3.9

RPM (Linux)

  • Install new version.
  • Check_files.
  • Check that the databases are purged.
  • Check that the service are restarted.

DEB (Linux)

  • Install new version.
  • Check_files.
  • Check that the databases are purged.
  • Check that the service are restarted.

macOS

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

Solaris (Intel)

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

Solaris (SPARC)

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

HP-UX

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

AIX

  • Install new version.
  • Check_files.
  • Check that the service are restarted.

Sources

  • Check the upgrade building the source code.
  • Check that the databases located at var/db are purged.
  • Check that the databases located at queue/db are upgraded.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.