From 32655066a0d3d7bc58fa3bb082dff1abf135d9ca Mon Sep 17 00:00:00 2001 From: Javier Medeot Date: Mon, 21 Oct 2024 12:36:28 -0300 Subject: [PATCH 1/2] Capitalize Active Response module references --- source/compliance/hipaa/active-response.rst | 18 +++++++++--------- source/compliance/nist/active-response.rst | 10 +++++----- source/compliance/pci-dss/active-response.rst | 8 ++++---- .../wazuh-agent-class.rst | 2 +- .../wazuh-manager-class.rst | 2 +- .../use-cases/file-integrity.rst | 8 ++++---- .../block-malicious-actor-ip-reputation.rst | 14 +++++++------- .../detect-malware-yara-integration.rst | 14 +++++++------- .../detect-remove-malware-virustotal.rst | 8 ++++---- .../leveraging-llms-for-alert-enrichment.rst | 8 ++++---- source/user-manual/api/rbac/reference.rst | 2 +- .../active-response/additional-information.rst | 12 ++++++------ .../ar-use-cases/blocking-ssh-brute-force.rst | 16 ++++++++-------- .../ar-use-cases/disabling-user-account.rst | 6 +++--- .../ar-use-cases/restarting-wazuh-agent.rst | 6 +++--- .../custom-active-response-scripts.rst | 8 ++++---- .../active-response/how-to-configure.rst | 6 +++--- .../capabilities/active-response/index.rst | 6 +++--- .../malware-detection/fim-yara.rst | 18 +++++++++--------- source/user-manual/manager/event-logging.rst | 2 +- .../reference/centralized-configuration.rst | 2 +- .../reference/ossec-conf/active-response.rst | 4 ++-- .../reference/ossec-conf/commands.rst | 2 +- .../reference/tools/wazuh-control.rst | 2 +- .../reference/unattended-installation.rst | 2 +- 25 files changed, 93 insertions(+), 93 deletions(-) diff --git a/source/compliance/hipaa/active-response.rst b/source/compliance/hipaa/active-response.rst index a65ea8483d..d2eaa464dd 100644 --- a/source/compliance/hipaa/active-response.rst +++ b/source/compliance/hipaa/active-response.rst @@ -1,23 +1,23 @@ .. Copyright (C) 2015, Wazuh, Inc. .. meta:: - :description: The active response module assists in meeting HIPAA compliance. Learn more about it in this section of the Wazuh documentation. + :description: The Active Response module assists in meeting HIPAA compliance. Learn more about it in this section of the Wazuh documentation. Active response =============== -The Wazuh active response module is configured to automatically execute scripts when events match specified rules in the Wazuh ruleset. These scripts may perform a firewall block or drop, traffic shaping or throttling, account lockout, or any other user defined action. +The Wazuh Active Response module is configured to automatically execute scripts when events match specified rules in the Wazuh ruleset. These scripts may perform a firewall block or drop, traffic shaping or throttling, account lockout, or any other user defined action. -The active response module assists in meeting the following HIPAA section: +The Active Response module assists in meeting the following HIPAA section: - **Security Incident Procedures §164.308(a)(6)(i) - Response and Reporting**: *“Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes.”* - The goal of this section is to make sure that you detect and respond to security incidents in your environment. The active response module assists in meeting this HIPAA section by responding to intrusions and unauthorized file changes. For more information on configuring active response, see the :doc:`active response ` section of our documentation. + The goal of this section is to make sure that you detect and respond to security incidents in your environment. The Active Response module assists in meeting this HIPAA section by responding to intrusions and unauthorized file changes. For more information on configuring Active Response, see the :doc:`Active Response ` section of our documentation. Use case: Block an IP address ----------------------------- -In this use case, you configure the active response module to block an IP address when someone attempts to log in to an Ubuntu 22.04 endpoint with a non-existent user via SSH. To implement this, follow the steps below: +In this use case, you configure the Active Response module to block an IP address when someone attempts to log in to an Ubuntu 22.04 endpoint with a non-existent user via SSH. To implement this, follow the steps below: #. Add the following block to the Wazuh server configuration file (``/var/ossec/etc/ossec.conf``). @@ -30,7 +30,7 @@ In this use case, you configure the active response module to block an IP addres 100 - This configures the active response to execute the ``firewall-drop`` command when there is an attempt to log in to a non-existent user (rule ``5710``). + This configures the Active Response to execute the ``firewall-drop`` command when there is an attempt to log in to a non-existent user (rule ``5710``). .. note:: @@ -40,14 +40,14 @@ In this use case, you configure the active response module to block an IP addres .. include:: /_templates/common/restart_manager.rst - When you attempt to SSH with a non-existent user, rule ``5710`` generates an alert followed by an active response event. + When you attempt to SSH with a non-existent user, rule ``5710`` generates an alert followed by an Active Response event. .. thumbnail:: /images/compliance/hipaa/08-active-response.png - :title: Rule 5710 generates an alert followed by an active response event + :title: Rule 5710 generates an alert followed by an Active Response event :align: center :width: 80% .. thumbnail:: /images/compliance/hipaa/09-active-response.png - :title: Rule 5710 generates an alert followed by an active response event + :title: Rule 5710 generates an alert followed by an Active Response event :align: center :width: 80% \ No newline at end of file diff --git a/source/compliance/nist/active-response.rst b/source/compliance/nist/active-response.rst index c1b3398124..8b5423225f 100644 --- a/source/compliance/nist/active-response.rst +++ b/source/compliance/nist/active-response.rst @@ -1,27 +1,27 @@ .. Copyright (C) 2015, Wazuh, Inc. .. meta:: - :description: The active response module performs autonomous actions on endpoints to mitigate security threats. Learn more about it in this section of the documentation. + :description: The Active Response module performs autonomous actions on endpoints to mitigate security threats. Learn more about it in this section of the documentation. Active response =============== -The Wazuh active response module performs autonomous actions on endpoints to mitigate security threats. You can configure the module to automatically execute scripts when specific alerts trigger. These scripts execute actions, such as a firewall block or drop, traffic shaping or throttling, and account lockout. +The Wazuh Active Response module performs autonomous actions on endpoints to mitigate security threats. You can configure the module to automatically execute scripts when specific alerts trigger. These scripts execute actions, such as a firewall block or drop, traffic shaping or throttling, and account lockout. -The Wazuh :doc:`active response ` module assists in meeting the following NIST 800-53 controls: +The Wazuh :doc:`Active Response ` module assists in meeting the following NIST 800-53 controls: - **AC-7 Unsuccessful logon attempts**: *“The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are usually temporary and automatically released after a predetermined, organization-defined time period. If a delay algorithm is selected, organizations may employ different algorithms for different components of the system based on the capabilities of those components. Responses to unsuccessful logon attempts may be implemented at the operating system and the application levels. Organization-defined actions that may be taken when the number of allowed consecutive invalid logon attempts is exceeded include prompting the user to answer a secret question in addition to the username and password, invoking a lockdown mode with limited user capabilities (instead of full lockout), allowing users to only logon from specified Internet Protocol (IP) addresses, requiring a CAPTCHA to prevent automated attacks, or applying user profiles such as location, time of day, IP address, device, or Media Access Control (MAC) address. If automatic system lockout or execution of a delay algorithm is not implemented in support of the availability objective, organizations consider a combination of other actions to help prevent brute force attacks. In addition to the above, organizations can prompt users to respond to a secret question before the number of allowed unsuccessful logon attempts is exceeded. Automatically unlocking an account after a specified period of time is generally not permitted. However, exceptions may be required based on operational mission or need.”* - **SC-5 Denial-of-service protection**: *“Denial-of-service events may occur due to a variety of internal and external causes, such as an attack by an adversary or a lack of planning to support organizational needs with respect to capacity and bandwidth. Such attacks can occur across a wide range of network protocols (e.g., IPv4, IPv6). A variety of technologies are available to limit or eliminate the origination and effects of denial-of-service events. For example, boundary protection devices can filter certain types of packets to protect system components on internal networks from being directly affected by or the source of denial-of-service attacks. Employing increased network capacity and bandwidth combined with service redundancy also reduces the susceptibility to denial-of-service events.”* -The Wazuh active response module assists in meeting the above controls by responding to brute force and denial of service attacks. Wazuh includes out-of-the-box active response commands that drop traffic from a malicious IP address or disable a user account that is a victim of brute forcing. +The Wazuh Active Response module assists in meeting the above controls by responding to brute force and denial of service attacks. Wazuh includes out-of-the-box active response commands that drop traffic from a malicious IP address or disable a user account that is a victim of brute forcing. Use case: Automatically disable an account ------------------------------------------ This use case shows how Wazuh helps meet the NIST **AC-7 Unsuccessful logon attempts** requirement by identifying and taking precautionary responses to failed login attempts. -In this scenario, the Wazuh active response module automatically disables a user account on a monitored Ubuntu 22.04 endpoint when events analysis detects multiple failed terminal login attempts. You can then track the alerts for these events and actions on the Wazuh dashboard. +In this scenario, the Wazuh Active Response module automatically disables a user account on a monitored Ubuntu 22.04 endpoint when events analysis detects multiple failed terminal login attempts. You can then track the alerts for these events and actions on the Wazuh dashboard. Wazuh server ^^^^^^^^^^^^ diff --git a/source/compliance/pci-dss/active-response.rst b/source/compliance/pci-dss/active-response.rst index b807436f2f..16cf672676 100644 --- a/source/compliance/pci-dss/active-response.rst +++ b/source/compliance/pci-dss/active-response.rst @@ -10,11 +10,11 @@ Active response Active response allows the execution of scripts whenever an event matches certain rules in your Wazuh ruleset. The actions executed could be a firewall block or drop, traffic shaping or throttling, or account lockout, among others. -The active response module helps to meet the following PCI DSS requirement: +The Active Response module helps to meet the following PCI DSS requirement: - **Requirement 11 - Test Security of Systems and Networks Regularly**: Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and bespoke and custom software should be tested frequently to ensure security controls continue to reflect a changing environment. -This requirement aims to ensure that you test your systems and networks regularly. Testing allows you to detect and respond to security status and possible intrusions. With the active response module, you can respond to intrusions and unauthorized file changes. You can find more details on configuring the active response module in the :doc:`active response ` documentation section. +This requirement aims to ensure that you test your systems and networks regularly. Testing allows you to detect and respond to security status and possible intrusions. With the Active Response module, you can respond to intrusions and unauthorized file changes. You can find more details on configuring the Active Response module in the :doc:`Active Response ` documentation section. Use cases @@ -22,9 +22,9 @@ Use cases - PCI DSS 11.5 requires that you detect and respond to network intrusions and unexpected file changes. You can configure scripts to run when specific actions occur to respond to these intrusions. Wazuh comes with preconfigured active response scripts. Refer to the :doc:`Default Active response scripts section ` to access these scripts. - Using the steps below, we configure the active response module to execute an IP block when an attempt to log in with a non-existent user via SSH occurs. + Using the steps below, we configure the Active Response module to execute an IP block when an attempt to log in with a non-existent user via SSH occurs. - #. Configure the active response to execute the ``firewall-drop`` command when the rule for attempts to log in to a non-existent user is triggered (rule 5710) by adding the following block in the manager configuration file (``/var/ossec/etc/ossec.conf``): + #. Configure the Active Response to execute the ``firewall-drop`` command when the rule for attempts to log in to a non-existent user is triggered (rule 5710) by adding the following block in the manager configuration file (``/var/ossec/etc/ossec.conf``): .. code-block:: xml :emphasize-lines: 4 diff --git a/source/deployment-options/deploying-with-puppet/wazuh-puppet-module/reference-wazuh-puppet/wazuh-agent-class.rst b/source/deployment-options/deploying-with-puppet/wazuh-puppet-module/reference-wazuh-puppet/wazuh-agent-class.rst index 953a15baed..b57edce157 100644 --- a/source/deployment-options/deploying-with-puppet/wazuh-puppet-module/reference-wazuh-puppet/wazuh-agent-class.rst +++ b/source/deployment-options/deploying-with-puppet/wazuh-puppet-module/reference-wazuh-puppet/wazuh-agent-class.rst @@ -18,7 +18,7 @@ This contains variables that can be used to configure the Wazuh agent. Active-Response variables ------------------------- $configure_active_response - Enables active response on this host. + Enables Active Response on this host. `Default true` diff --git a/source/deployment-options/deploying-with-puppet/wazuh-puppet-module/reference-wazuh-puppet/wazuh-manager-class.rst b/source/deployment-options/deploying-with-puppet/wazuh-puppet-module/reference-wazuh-puppet/wazuh-manager-class.rst index 17bba0b8cc..fd8e7f33c6 100644 --- a/source/deployment-options/deploying-with-puppet/wazuh-puppet-module/reference-wazuh-puppet/wazuh-manager-class.rst +++ b/source/deployment-options/deploying-with-puppet/wazuh-puppet-module/reference-wazuh-puppet/wazuh-manager-class.rst @@ -1230,7 +1230,7 @@ $active_response_rules_id `Default []` $active_response_timeout - Usually active response blocks for a certain amount of time. + Usually Active Response blocks for a certain amount of time. `Default undef` diff --git a/source/getting-started/use-cases/file-integrity.rst b/source/getting-started/use-cases/file-integrity.rst index 8703abdebf..048737eecc 100644 --- a/source/getting-started/use-cases/file-integrity.rst +++ b/source/getting-started/use-cases/file-integrity.rst @@ -89,13 +89,13 @@ The Wazuh FIM module supports various integrations, including but not limited to - **File integrity monitoring and YARA**: By combining the Wazuh FIM module and the YARA tool, it is possible to detect malware when suspicious file additions or modifications are identified. The YARA rule files contain samples of malware indicators that are downloaded to the monitored endpoints. When the FIM module detects a change in the monitored file or directory, it executes a YARA scan using a script to determine if it is malware. If the YARA rule finds a match with a file, it will send the scan results to the Wazuh server for decoding and alerting. This would be reported according to the custom rule and decoder configurations configured on the Wazuh server. Check this documentation for more information on :doc:`how to integrate the Wazuh FIM module with YARA `. - **File integrity monitoring and VirusTotal**: The Wazuh :doc:`Integrator module ` connects to external APIs and alerting tools such as VirusTotal. The :doc:`VirusTotal integration ` uses the VirusTotal API to detect malicious file hashes within the files and directories monitored by the FIM module. Once enabled, when FIM generates alerts, Wazuh initiates the VirusTotal integration to extract the hash value associated with the flagged file from the alert. The VirusTotal API is then used to compare these hashes against its scanning engines for potentially malicious content. -- **File integrity monitoring and active response**: The :doc:`Wazuh active response ` module automatically responds to threats identified in a timely manner. This combination enables the FIM module to not only detect but also respond to malicious activities. You can configure active response scripts to execute when the FIM module detects file changes in your monitored environment. Additionally, it also generates alerts for the response performed. This reduces the Mean Time To Respond (MTTR) as malicious changes detected are remediated in a timely manner. +- **File integrity monitoring and active response**: The :doc:`Wazuh Active Response ` module automatically responds to threats identified in a timely manner. This combination enables the FIM module to not only detect but also respond to malicious activities. You can configure active response scripts to execute when the FIM module detects file changes in your monitored environment. Additionally, it also generates alerts for the response performed. This reduces the Mean Time To Respond (MTTR) as malicious changes detected are remediated in a timely manner. - In the image below Wazuh triggers when a file is added to the monitored endpoint. The VirusTotal API scans the file and identifies it as malicious content on 55 engines. Then the Wazuh active response module acts immediately to remove the threat from the monitored endpoint. + In the image below Wazuh triggers when a file is added to the monitored endpoint. The VirusTotal API scans the file and identifies it as malicious content on 55 engines. Then the Wazuh Active Response module acts immediately to remove the threat from the monitored endpoint. .. thumbnail:: /images/getting-started/use-cases/fim/fim-ar-virustotal-alerts.png - :title: FIM and active response using VirusTotal alerts - :alt: FIM and active response using VirusTotal alerts + :title: FIM and Active Response using VirusTotal alerts + :alt: FIM and Active Response using VirusTotal alerts :align: center :width: 80% diff --git a/source/proof-of-concept-guide/block-malicious-actor-ip-reputation.rst b/source/proof-of-concept-guide/block-malicious-actor-ip-reputation.rst index ed7daa4cbb..12030cac59 100644 --- a/source/proof-of-concept-guide/block-malicious-actor-ip-reputation.rst +++ b/source/proof-of-concept-guide/block-malicious-actor-ip-reputation.rst @@ -10,7 +10,7 @@ In this use case, we demonstrate how to block malicious IP addresses from access This case uses a public IP reputation database that contains the IP addresses of some malicious actors. An IP reputation database is a collection of IP addresses that have been flagged as malicious. The RHEL endpoint plays the role of the malicious actor here, therefore you add its IP address to the reputation database. Then, configure Wazuh to block the RHEL endpoint from accessing web resources on the Apache web servers for 60 seconds. It’s a way of discouraging attackers from continuing to carry out their malicious activities. -In this use case, you use the Wazuh :doc:`CDB list ` and :doc:`active response ` capabilities. +In this use case, you use the Wazuh :doc:`CDB list ` and :doc:`Active Response ` capabilities. Infrastructure -------------- @@ -20,9 +20,9 @@ Infrastructure +===============+=====================================================================================================================================================================+ | RHEL 9.0 | Attacker endpoint connecting to the victim's web server on which you use Wazuh CDB list capability to flag its IP address as malicious. | +---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Ubuntu 22.04 | Victim endpoint running an Apache 2.4.54 web server. Here, you use the Wazuh active response module to automatically block connections from the attacker endpoint. | +| Ubuntu 22.04 | Victim endpoint running an Apache 2.4.54 web server. Here, you use the Wazuh Active Response module to automatically block connections from the attacker endpoint. | +---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| Windows 11 | Victim endpoint running an Apache 2.4.54 web server. Here, you use the Wazuh active response module to automatically block connections from the attacker endpoint. | +| Windows 11 | Victim endpoint running an Apache 2.4.54 web server. Here, you use the Wazuh Active Response module to automatically block connections from the attacker endpoint. | +---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Configuration @@ -124,7 +124,7 @@ Perform the steps below to configure the Wazuh agent to monitor Apache web serve Wazuh server ^^^^^^^^^^^^ -You need to perform the following steps on the Wazuh server to add the IP address of the RHEL endpoint to a CDB list, and then configure rules and active response. +You need to perform the following steps on the Wazuh server to add the IP address of the RHEL endpoint to a CDB list, and then configure rules and Active Response. Download the utilities and configure the CDB list ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -172,7 +172,7 @@ Download the utilities and configure the CDB list $ sudo chown wazuh:wazuh /var/ossec/etc/lists/blacklist-alienvault -Configure the active response module to block the malicious IP address +Configure the Active Response module to block the malicious IP address ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #. Add a custom rule to trigger a Wazuh :doc:`active response ` script. Do this in the Wazuh server ``/var/ossec/etc/rules/local_rules.xml`` custom ruleset file: @@ -210,7 +210,7 @@ Configure the active response module to block the malicious IP address -#. Add the active response block to the Wazuh server ``/var/ossec/etc/ossec.conf`` file: +#. Add the Active Response block to the Wazuh server ``/var/ossec/etc/ossec.conf`` file: **For the Ubuntu endpoint** @@ -259,7 +259,7 @@ Attack emulation $ curl http:// -The attacker endpoint connects to the victim's web servers the first time. After the first connection, the Wazuh active response module temporarily blocks any successive connection to the web servers for 60 seconds. +The attacker endpoint connects to the victim's web servers the first time. After the first connection, the Wazuh Active Response module temporarily blocks any successive connection to the web servers for 60 seconds. Visualize the alerts -------------------- diff --git a/source/proof-of-concept-guide/detect-malware-yara-integration.rst b/source/proof-of-concept-guide/detect-malware-yara-integration.rst index ad46664c69..7a6bdbc247 100644 --- a/source/proof-of-concept-guide/detect-malware-yara-integration.rst +++ b/source/proof-of-concept-guide/detect-malware-yara-integration.rst @@ -18,9 +18,9 @@ Infrastructure +--------------------------+-----------------------------------------------------------------------------------------------------------------+ | Endpoint | Description | +==========================+=================================================================================================================+ -| Ubuntu 22.04 / RHEL 9.0 | The YARA active response module scans new or modified files whenever the Wazuh FIM module triggers an alert. | +| Ubuntu 22.04 / RHEL 9.0 | The YARA Active Response module scans new or modified files whenever the Wazuh FIM module triggers an alert. | +--------------------------+-----------------------------------------------------------------------------------------------------------------+ -| Windows 11 | The YARA active response module scans new or modified files whenever the Wazuh FIM module triggers an alert. | +| Windows 11 | The YARA Active Response module scans new or modified files whenever the Wazuh FIM module triggers an alert. | +--------------------------+-----------------------------------------------------------------------------------------------------------------+ Configuration for Linux @@ -29,7 +29,7 @@ Configuration for Linux Linux endpoint ^^^^^^^^^^^^^^ -Perform the following steps to install YARA, and configure the active response and FIM modules. +Perform the following steps to install YARA, and configure the Active Response and FIM modules. #. Download, compile and install YARA: @@ -102,7 +102,7 @@ Perform the following steps to install YARA, and configure the active response a --data 'demo=demo&apikey=1111111111111111111111111111111111111111111111111111111111111111&format=text' \ -o /tmp/yara/rules/yara_rules.yar -#. Create a ``yara.sh`` script in the ``/var/ossec/active-response/bin/`` directory. This is necessary for the Wazuh-YARA active response scans: +#. Create a ``yara.sh`` script in the ``/var/ossec/active-response/bin/`` directory. This is necessary for the Wazuh-YARA Active Response scans: .. code-block:: bash @@ -225,7 +225,7 @@ Perform the following steps to configure Wazuh to alert for file changes in the log_type, yara_rule, yara_scanned_file -#. Add the following configuration to the Wazuh server ``/var/ossec/etc/ossec.conf`` configuration file. This configures the active response module to trigger after the rule 100300 and 100301 are fired: +#. Add the following configuration to the Wazuh server ``/var/ossec/etc/ossec.conf`` configuration file. This configures the Active Response module to trigger after the rule 100300 and 100301 are fired: .. code-block:: xml @@ -382,12 +382,12 @@ Perform the following steps to install Python, YARA, and download YARA rules. > mkdir 'C:\Program Files (x86)\ossec-agent\active-response\bin\yara\rules\' > cp yara_rules.yar 'C:\Program Files (x86)\ossec-agent\active-response\bin\yara\rules\' -Configure active response and FIM +Configure Active Response and FIM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Perform the steps below to configure the Wazuh FIM and an active response script for the detection of malicious files on the endpoint. -#. Create the ``yara.bat`` script in the ``C:\Program Files (x86)\ossec-agent\active-response\bin\`` directory. This is necessary for the Wazuh-YARA active response scans: +#. Create the ``yara.bat`` script in the ``C:\Program Files (x86)\ossec-agent\active-response\bin\`` directory. This is necessary for the Wazuh-YARA Active Response scans: .. code-block:: bash diff --git a/source/proof-of-concept-guide/detect-remove-malware-virustotal.rst b/source/proof-of-concept-guide/detect-remove-malware-virustotal.rst index 0d05321fb9..4f39973571 100644 --- a/source/proof-of-concept-guide/detect-remove-malware-virustotal.rst +++ b/source/proof-of-concept-guide/detect-remove-malware-virustotal.rst @@ -145,7 +145,7 @@ Perform the following steps on the Wazuh server to alert for changes in the endp The free VirusTotal API rate limits requests to four per minute. If you have a premium VirusTotal API key, with a high frequency of queries allowed, you can add more rules besides these two. You can also configure Wazuh to monitor more directories. -#. Append the following blocks to the Wazuh server ``/var/ossec/etc/ossec.conf`` file. This enables active response and triggers the ``remove-threat.sh`` script when VirusTotal flags a file as malicious: +#. Append the following blocks to the Wazuh server ``/var/ossec/etc/ossec.conf`` file. This enables Active Response and triggers the ``remove-threat.sh`` script when VirusTotal flags a file as malicious: .. code-block:: xml @@ -164,7 +164,7 @@ Perform the following steps on the Wazuh server to alert for changes in the endp -#. Add the following rules to the Wazuh server ``/var/ossec/etc/rules/local_rules.xml`` file to alert about the active response results: +#. Add the following rules to the Wazuh server ``/var/ossec/etc/rules/local_rules.xml`` file to alert about the Active Response results: .. code-block:: xml @@ -428,7 +428,7 @@ Perform the following steps on the Wazuh server to configure the VirusTotal inte The free VirusTotal API rate limits requests to four per minute. If you have a premium VirusTotal API key, with a high frequency of queries allowed, you can add more rules besides these two. You can configure Wazuh to monitor more directories besides ``C:\Users\\Downloads``. -#. Append the following blocks to the Wazuh server ``/var/ossec/etc/ossec.conf`` file. This enables active response and trigger the ``remove-threat.exe`` executable when the VirusTotal query returns positive matches for threats: +#. Append the following blocks to the Wazuh server ``/var/ossec/etc/ossec.conf`` file. This enables Active Response and trigger the ``remove-threat.exe`` executable when the VirusTotal query returns positive matches for threats: .. code-block:: xml @@ -447,7 +447,7 @@ Perform the following steps on the Wazuh server to configure the VirusTotal inte -#. Add the following rules to the Wazuh server ``/var/ossec/etc/rules/local_rules.xml`` file to alert about the active response results. +#. Add the following rules to the Wazuh server ``/var/ossec/etc/rules/local_rules.xml`` file to alert about the Active Response results. .. code-block:: xml diff --git a/source/proof-of-concept-guide/leveraging-llms-for-alert-enrichment.rst b/source/proof-of-concept-guide/leveraging-llms-for-alert-enrichment.rst index f67c8a050b..3275c34346 100644 --- a/source/proof-of-concept-guide/leveraging-llms-for-alert-enrichment.rst +++ b/source/proof-of-concept-guide/leveraging-llms-for-alert-enrichment.rst @@ -10,7 +10,7 @@ Leveraging LLMs for alert enrichment YARA is a tool that detects and classifies malware artifacts. While YARA can identify known patterns and signatures of malicious activity, human intervention is often required to interpret and contextualize the output of YARA scans. ChatGPT is a generative AI chatbot developed by OpenAI. It provides users with various LLMs to process data. These LLMs can analyze and enrich YARA alerts with additional context, providing security teams with deeper insights into the nature and severity of detected threats. -In this use case, we integrate Wazuh with YARA to detect when a malicious file is added to a monitored endpoint. The integration utilizes the Wazuh :doc:`FIM ` module to monitor a directory for new or modified files. When a file modification or addition is detected, the Wazuh :doc:`active response ` module triggers a YARA scan on the file. The Active response module automatically deletes the malicious file from the endpoint if it has a positive match with a malicious signature. The active response module then queries ChatGPT to enrich the YARA scan result with additional insight into the malicious file that helps security teams understand its nature, potential impact, and remediation. +In this use case, we integrate Wazuh with YARA to detect when a malicious file is added to a monitored endpoint. The integration utilizes the Wazuh :doc:`FIM ` module to monitor a directory for new or modified files. When a file modification or addition is detected, the Wazuh :doc:`Active Response ` module triggers a YARA scan on the file. The Active response module automatically deletes the malicious file from the endpoint if it has a positive match with a malicious signature. The Active Response module then queries ChatGPT to enrich the YARA scan result with additional insight into the malicious file that helps security teams understand its nature, potential impact, and remediation. Infrastructure -------------- @@ -30,7 +30,7 @@ Perform the following steps to set up the YARA and ChatGPT integration. Choose e Ubuntu 22.04 endpoint ^^^^^^^^^^^^^^^^^^^^^ -Perform the following steps to install YARA and configure the active response and FIM modules. +Perform the following steps to install YARA and configure the Active Response and FIM modules. #. Download, compile, and install YARA: @@ -427,7 +427,7 @@ Perform the following steps to install Python, YARA, and download YARA rules. Wazuh server ------------ -Perform the following steps on the Wazuh server to configure custom rules, decoders, and the active response module. +Perform the following steps on the Wazuh server to configure custom rules, decoders, and the Active Response module. #. Add the following decoders to the Wazuh server ``/var/ossec/etc/decoders/local_decoder.xml`` file to parse the data in YARA scan results: @@ -584,7 +584,7 @@ Perform the following steps on the Wazuh server to configure custom rules, decod -#. Add the following configuration to the Wazuh server ``/var/ossec/etc/ossec.conf`` configuration file. This configures the active response module to trigger after the rules with ID ``100300``, ``100301``, ``100302``, and ``100303`` are fired: +#. Add the following configuration to the Wazuh server ``/var/ossec/etc/ossec.conf`` configuration file. This configures the Active Response module to trigger after the rules with ID ``100300``, ``100301``, ``100302``, and ``100303`` are fired: .. code-block:: xml diff --git a/source/user-manual/api/rbac/reference.rst b/source/user-manual/api/rbac/reference.rst index fa18fde223..5fa9f6d1aa 100644 --- a/source/user-manual/api/rbac/reference.rst +++ b/source/user-manual/api/rbac/reference.rst @@ -59,7 +59,7 @@ In each action, the affected endpoints are specified along with the necessary re Active_response ^^^^^^^^^^^^^^^ -The :api-ref:`/active-response ` endpoint of the Wazuh server API allows users to interact with the Wazuh active response module. +The :api-ref:`/active-response ` endpoint of the Wazuh server API allows users to interact with the Wazuh Active Response module. active-response:command ~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/source/user-manual/capabilities/active-response/additional-information.rst b/source/user-manual/capabilities/active-response/additional-information.rst index 6e0b9e8f3c..5c6b29445c 100644 --- a/source/user-manual/capabilities/active-response/additional-information.rst +++ b/source/user-manual/capabilities/active-response/additional-information.rst @@ -1,7 +1,7 @@ .. Copyright (C) 2015, Wazuh, Inc. .. meta:: - :description: Learn how to white-list IP addresses and how to increase the active response blocking time in this section of the documentation. + :description: Learn how to white-list IP addresses and how to increase the Active Response blocking time in this section of the documentation. Additional information ====================== @@ -9,7 +9,7 @@ Additional information White list ---------- -You can set a list of IP addresses that should never be blocked by the active response using the :ref:`white_list ` field. It allows setting one IP address, netblock, or hostname. Although you must specify only one value for each ```` tag, you can use multiple ```` tags to include multiple values. +You can set a list of IP addresses that should never be blocked by the Active Response using the :ref:`white_list ` field. It allows setting one IP address, netblock, or hostname. Although you must specify only one value for each ```` tag, you can use multiple ```` tags to include multiple values. To configure a white list for the endpoint(s), add the related IP address, netblock, or hostname to the ```` field present in the global section of the Wazuh server ``/var/ossec/etc/ossec.conf`` configuration file: @@ -34,7 +34,7 @@ Restart the Wazuh manager service to apply the changes: Increasing blocking time for repeated offenders ----------------------------------------------- -In cases where you need to increase the active response blocking time for :ref:`repeated offenders `, add the following configuration in the ``/var/ossec/etc/ossec.conf`` file of the Wazuh agent: +In cases where you need to increase the Active Response blocking time for :ref:`repeated offenders `, add the following configuration in the ``/var/ossec/etc/ossec.conf`` file of the Wazuh agent: .. code-block:: xml @@ -46,7 +46,7 @@ In cases where you need to increase the active response blocking time for :ref:` .. note:: - This option is currently not available for Wazuh agents running on Windows operating endpoints. The ```` timer is in minutes while the active response ```` is in seconds. Also, it can contain a maximum of 5 entries. + This option is currently not available for Wazuh agents running on Windows operating endpoints. The ```` timer is in minutes while the Active Response ```` is in seconds. Also, it can contain a maximum of 5 entries. Restart the Wazuh agent to apply changes: @@ -54,6 +54,6 @@ Restart the Wazuh agent to apply changes: $ sudo systemctl restart wazuh-agent -The first time the active response triggers, it blocks the IP address for the specified period using the ```` configured on the Wazuh server side. Then, the second time for 10 minutes, the third time for 20 minutes, and the fourth time for 30 minutes using the ```` on the agent side. +The first time the Active Response triggers, it blocks the IP address for the specified period using the ```` configured on the Wazuh server side. Then, the second time for 10 minutes, the third time for 20 minutes, and the fourth time for 30 minutes using the ```` on the agent side. -Using the active response module, you can respond to several scenarios like restricting malicious activities and blocking attacks. Be aware that improperly configured responses can make an endpoint vulnerable, so you have to define your active responses carefully. +Using the Active Response module, you can respond to several scenarios like restricting malicious activities and blocking attacks. Be aware that improperly configured responses can make an endpoint vulnerable, so you have to define your active responses carefully. diff --git a/source/user-manual/capabilities/active-response/ar-use-cases/blocking-ssh-brute-force.rst b/source/user-manual/capabilities/active-response/ar-use-cases/blocking-ssh-brute-force.rst index a66d701203..8490e59a99 100644 --- a/source/user-manual/capabilities/active-response/ar-use-cases/blocking-ssh-brute-force.rst +++ b/source/user-manual/capabilities/active-response/ar-use-cases/blocking-ssh-brute-force.rst @@ -1,12 +1,12 @@ .. Copyright (C) 2015, Wazuh, Inc. .. meta:: - :description: Learn how to use active response to block an SSH brute-force attack in this use case. + :description: Learn how to use Active Response to block an SSH brute-force attack in this use case. -Blocking SSH brute-force attack with active response +Blocking SSH brute-force attack with Active Response ==================================================== -Wazuh uses the active response module to run scripts or executables on a monitored endpoint, taking action on certain triggers. In this use case, we simulate an SSH brute-force attack against a RHEL endpoint and configure the active response module to block the IP address of the attacker endpoint. The goal is to prevent SSH brute force attacks. The active response module executes a script to block the IP address of the attacker when rule ``5763 - SSHD brute force trying to get access to the system`` triggers. +Wazuh uses the Active Response module to run scripts or executables on a monitored endpoint, taking action on certain triggers. In this use case, we simulate an SSH brute-force attack against a RHEL endpoint and configure the Active Response module to block the IP address of the attacker endpoint. The goal is to prevent SSH brute force attacks. The Active Response module executes a script to block the IP address of the attacker when rule ``5763 - SSHD brute force trying to get access to the system`` triggers. Infrastructure -------------- @@ -21,7 +21,7 @@ Endpoint Description Wazuh server ------------ -Wazuh comes with a set of default scripts used in active response. These scripts are located in the ``/var/ossec/active-response/bin/`` directory on Linux/Unix endpoints. The ``firewall-drop`` active response script works with Linux/Unix operating systems. It uses iptables to block malicious IP addresses. +Wazuh comes with a set of default scripts used in Active Response. These scripts are located in the ``/var/ossec/active-response/bin/`` directory on Linux/Unix endpoints. The ``firewall-drop`` active response script works with Linux/Unix operating systems. It uses iptables to block malicious IP addresses. #. Open the Wazuh server ``/var/ossec/etc/ossec.conf`` file and verify that a ```` block called ``firewall-drop`` with the following configuration is present within the ```` block: @@ -58,7 +58,7 @@ Wazuh comes with a set of default scripts used in active response. These scripts - ````: Specifies the command to configure. This is the command name ``firewall-drop`` defined in the previous step. - ````: Specifies where the command executes. Using the ``local`` value means that the command executes on the monitored endpoint where the trigger event occurs. - - ````: The active response module executes the command if rule ID ``5763 - SSHD brute force trying to get access to the system`` fires. + - ````: The Active Response module executes the command if rule ID ``5763 - SSHD brute force trying to get access to the system`` fires. - ````: Specifies how long the active response action must last. In this use case, the module blocks for 180 seconds the IP address of the endpoint carrying out the brute-force attack. #. Restart the Wazuh manager service to apply the changes: @@ -106,7 +106,7 @@ Perform the steps below to perform an SSH brute-force attack against the RHEL en :align: center :width: 80% -#. Ping the victim endpoint from the attacker within 3 minutes of the attack execution to verify that the active response module has blocked the attacker's IP address: +#. Ping the victim endpoint from the attacker within 3 minutes of the attack execution to verify that the Active Response module has blocked the attacker's IP address: .. code-block:: console @@ -124,7 +124,7 @@ Perform the steps below to perform an SSH brute-force attack against the RHEL en Generating an alert when an active response is fired ---------------------------------------------------- -Monitored Linux/Unix endpoints have a log file at ``/var/ossec/logs/active-responses.log`` where Wazuh registers the active response activities. By default, the Wazuh server monitors the active response log file. You can find the relevant section in the Wazuh server ``/var/ossec/etc/ossec.conf`` configuration file as shown below: +Monitored Linux/Unix endpoints have a log file at ``/var/ossec/logs/active-responses.log`` where Wazuh registers the active response activities. By default, the Wazuh server monitors the Active Response log file. You can find the relevant section in the Wazuh server ``/var/ossec/etc/ossec.conf`` configuration file as shown below: .. code-block:: xml @@ -141,4 +141,4 @@ When the active response triggers, a corresponding alert appears on the Wazuh da :align: center :width: 80% -The alert appears because rule ID ``651`` is part of the default ``/var/ossec/ruleset/rules/0015-ossec_rules.xml`` rule file on the Wazuh server. If you create a custom active response script, you must add a proper custom rule to analyze the active response logs that are generated. \ No newline at end of file +The alert appears because rule ID ``651`` is part of the default ``/var/ossec/ruleset/rules/0015-ossec_rules.xml`` rule file on the Wazuh server. If you create a custom active response script, you must add a proper custom rule to analyze the Active Response logs that are generated. \ No newline at end of file diff --git a/source/user-manual/capabilities/active-response/ar-use-cases/disabling-user-account.rst b/source/user-manual/capabilities/active-response/ar-use-cases/disabling-user-account.rst index a378019752..8e11aa428c 100644 --- a/source/user-manual/capabilities/active-response/ar-use-cases/disabling-user-account.rst +++ b/source/user-manual/capabilities/active-response/ar-use-cases/disabling-user-account.rst @@ -1,9 +1,9 @@ .. Copyright (C) 2015, Wazuh, Inc. .. meta:: - :description: Learn how to disable a user account on Linux using active response in this use case. + :description: Learn how to disable a user account on Linux using Active Response in this use case. -Disabling a Linux user account with active response +Disabling a Linux user account with Active Response =================================================== Without knowledge of the password for an account, an adversary might opt to systematically guess the password using a repetitive or iterative mechanism. In this use case, we configure the ``disable-account`` active response to disable a Linux/Unix account subject to brute-force attacks. Wazuh uses the ``disable-account`` active response on Linux/Unix endpoints to disable the account for the user in the ``dstuser`` field of a Wazuh alert. @@ -67,7 +67,7 @@ Wazuh server - ````: Specifies the command to configure. This is the command name ``disable-account`` defined in the previous step. - ````: Specifies where the command executes. Using the ``local`` value here means that the command executes on the monitored endpoint where the trigger event occurs. - - ````: The active response module executes the command if rule ID ``120100``: ``Possible password guess on $(dstuser): 3 failed logins in a short period of time`` fires. + - ````: The Active Response module executes the command if rule ID ``120100``: ``Possible password guess on $(dstuser): 3 failed logins in a short period of time`` fires. - ````: Specifies how long the active response action must last. In this use case, we configure it to last for 300 seconds. After that period, the active response reverts its action and re-enables the account. #. Restart the Wazuh manager service to apply changes: diff --git a/source/user-manual/capabilities/active-response/ar-use-cases/restarting-wazuh-agent.rst b/source/user-manual/capabilities/active-response/ar-use-cases/restarting-wazuh-agent.rst index 77c1553cbc..8f597f5f05 100644 --- a/source/user-manual/capabilities/active-response/ar-use-cases/restarting-wazuh-agent.rst +++ b/source/user-manual/capabilities/active-response/ar-use-cases/restarting-wazuh-agent.rst @@ -1,9 +1,9 @@ .. Copyright (C) 2015, Wazuh, Inc. .. meta:: - :description: Learn how to restart the Wazuh agent to apply configuration changes using active response in this use case. + :description: Learn how to restart the Wazuh agent to apply configuration changes using Active Response in this use case. -Restarting the Wazuh agent with active response +Restarting the Wazuh agent with Active Response =============================================== You can use the ``restart-wazuh`` active response script to restart the Wazuh agent on a monitored endpoint. In this use case, we configure it to restart the Wazuh agent whenever the ``/var/ossec/etc/ossec.conf`` configuration file changes. @@ -49,7 +49,7 @@ Wazuh server - ````: Specifies the command to configure. This is the command name ``restart-wazuh`` defined in the previous step. - ````: Specifies where the command executes. Using the ``local`` value here means that the command executes on the monitored endpoint where the trigger event occurs. - - ````: The active response module executes the command if rule ID ``100009`` fires. + - ````: The Active Response module executes the command if rule ID ``100009`` fires. #. Add the rules below to the Wazuh server ``/var/ossec/etc/rules/local_rules.xml`` configuration file: diff --git a/source/user-manual/capabilities/active-response/custom-active-response-scripts.rst b/source/user-manual/capabilities/active-response/custom-active-response-scripts.rst index 194ef74d38..c7ebec85e9 100644 --- a/source/user-manual/capabilities/active-response/custom-active-response-scripts.rst +++ b/source/user-manual/capabilities/active-response/custom-active-response-scripts.rst @@ -6,7 +6,7 @@ Custom active response scripts ============================== -You can create custom active response scripts that execute when an alert of a specific rule ID, alert level, or rule group triggers. You can create active response scripts in any programming language. A trigger initiates the script using a defined :doc:`command `. An :doc:`active response ` configuration determines when and where the command executes. +You can create custom active response scripts that execute when an alert of a specific rule ID, alert level, or rule group triggers. You can create active response scripts in any programming language. A trigger initiates the script using a defined :doc:`command `. An :doc:`Active Response ` configuration determines when and where the command executes. Programming an active response ------------------------------ @@ -88,7 +88,7 @@ As you can see, the JSON message format that an active response script analyzes } } -The ``parameters`` field of the active response alert corresponds to: +The ``parameters`` field of the Active Response alert corresponds to: - ``extra_args``: The extra arguments required to execute the active response script. - ``alert``: The full alert that triggered the active response script. @@ -556,7 +556,7 @@ With this configuration, Wazuh runs an executable instead of a Python script whe Method 2: Run a Python script through a Batch launcher """""""""""""""""""""""""""""""""""""""""""""""""""""" -In this method, the Wazuh active response module executes the ``launcher.cmd`` script which subsequently executes the ``custom-ar.py`` script. +In this method, the Wazuh Active Response module executes the ``launcher.cmd`` script which subsequently executes the ``custom-ar.py`` script. #. Create a ``launcher.cmd`` file in ``C:\Program Files (x86)\ossec-agent\active-response\bin\`` with the following content. This allows you to run any Windows script through the ``launcher.cmd`` script when triggering an active response. @@ -658,7 +658,7 @@ In this method, the Wazuh active response module executes the ``launcher.cmd`` s > Restart-Service -Name wazuh -#. On the Wazuh server, add the ```` and ```` blocks below to the Wazuh configuration ``/var/ossec/etc/ossec.conf`` file. The active response module runs the ``launcher.cmd`` script which runs the Python script in its ```` option. This action executes for 60 seconds when rule ID 503 is triggered. +#. On the Wazuh server, add the ```` and ```` blocks below to the Wazuh configuration ``/var/ossec/etc/ossec.conf`` file. The Active Response module runs the ``launcher.cmd`` script which runs the Python script in its ```` option. This action executes for 60 seconds when rule ID 503 is triggered. .. code-block:: xml :emphasize-lines: 4, 5 diff --git a/source/user-manual/capabilities/active-response/how-to-configure.rst b/source/user-manual/capabilities/active-response/how-to-configure.rst index cdb3bfbd5c..037186be08 100644 --- a/source/user-manual/capabilities/active-response/how-to-configure.rst +++ b/source/user-manual/capabilities/active-response/how-to-configure.rst @@ -3,10 +3,10 @@ .. meta:: :description: Learn more about how to configure the Active Response capability in this section of the Wazuh documentation. -How to configure active response +How to configure Active Response ================================ -The following steps describe how to configure the active response module to perform an action on a monitored endpoint. +The following steps describe how to configure the Active Response module to perform an action on a monitored endpoint. Configuring the Wazuh server ---------------------------- @@ -69,7 +69,7 @@ Configuring the Wazuh server - ````: Specifies how long the active response action is effective, in seconds. - Refer to the :doc:`active response ` configuration section for more information on the supported options. + Refer to the :doc:`Active Response ` configuration section for more information on the supported options. #. Restart the Wazuh manager to apply all the changes made: diff --git a/source/user-manual/capabilities/active-response/index.rst b/source/user-manual/capabilities/active-response/index.rst index be92990be5..e610b5019e 100644 --- a/source/user-manual/capabilities/active-response/index.rst +++ b/source/user-manual/capabilities/active-response/index.rst @@ -15,15 +15,15 @@ Wazuh SIEM and XDR platform improves incident response by: - Automating response actions to threats. - Providing out-of-the-box response scripts. -Wazuh has an active response module that helps security teams automate response actions based on specific triggers, enabling them to effectively manage security incidents. +Wazuh has an Active Response module that helps security teams automate response actions based on specific triggers, enabling them to effectively manage security incidents. Automating response actions ensures that high-priority incidents are addressed and remediated in a timely and consistent manner. This is especially valuable in environments where security teams are resource constrained and need to prioritize their response efforts. In addition, the module includes a range of out-of-the-box response scripts that help respond to threats and mitigate them. For example, some scripts block malicious network access and delete malicious files on monitored endpoints. These actions reduce the workload on security teams and enable them to effectively manage incidents. -The Wazuh active response module executes these scripts on monitored endpoints when an alert of a specific rule ID, level, or rule group triggers. You can set any number of scripts to initiate in response to a trigger; however, you must consider these responses carefully. Poor implementation of rules and responses might increase the vulnerability of an endpoint. +The Wazuh Active Response module executes these scripts on monitored endpoints when an alert of a specific rule ID, level, or rule group triggers. You can set any number of scripts to initiate in response to a trigger; however, you must consider these responses carefully. Poor implementation of rules and responses might increase the vulnerability of an endpoint. -The image below shows the active response workflow. +The image below shows the Active Response workflow. .. thumbnail:: /images/manual/active-response/active-response-workflow.png :title: Active response workflow diff --git a/source/user-manual/capabilities/malware-detection/fim-yara.rst b/source/user-manual/capabilities/malware-detection/fim-yara.rst index abe556dab2..73771ff1c8 100644 --- a/source/user-manual/capabilities/malware-detection/fim-yara.rst +++ b/source/user-manual/capabilities/malware-detection/fim-yara.rst @@ -15,11 +15,11 @@ This technique detects malware in several stages and is achieved in the followin #. The Wazuh FIM module scans monitored directories on endpoints to detect changes such as file creation and modifications. -#. When FIM detects a change in the monitored directory or file, it triggers a YARA scan active response. The active response module automatically executes YARA using the ``yara.sh`` script. YARA then scans the file that triggered the FIM alert against its ruleset to determine whether it is malware. +#. When FIM detects a change in the monitored directory or file, it triggers a YARA scan active response. The Active Response module automatically executes YARA using the ``yara.sh`` script. YARA then scans the file that triggered the FIM alert against its ruleset to determine whether it is malware. #. When the YARA rules match a file, the scan results are forwarded to the Wazuh manager for decoding, analysis and alerting. These scan results are not decoded out-of-the-box so you have to add the decoders to your Wazuh server. -This implementation of YARA scans with the active response module concentrates the scans on new or recently modified files in monitored directories, thus optimizing resource consumption on the monitored endpoints. +This implementation of YARA scans with the Active Response module concentrates the scans on new or recently modified files in monitored directories, thus optimizing resource consumption on the monitored endpoints. The diagram below illustrates the flow of events between the different components. @@ -41,7 +41,7 @@ Infrastructure ============ =========== Endpoint Description ============ =========== -Ubuntu 22.04 The active response module runs YARA scans on new or modified files whenever the Wazuh FIM module alerts about them. +Ubuntu 22.04 The Active Response module runs YARA scans on new or modified files whenever the Wazuh FIM module alerts about them. ============ =========== Linux endpoint configuration @@ -179,7 +179,7 @@ Perform the following steps to configure YARA and the FIM module on the monitore echo "wazuh-yara: INFO - Scan result: $line" >> ${LOG_FILE} done <<< "$yara_output" - For every line in the output of the YARA scan, the script appends an event to the active response log, ``/var/ossec/logs/active-responses.log``, with the following format: + For every line in the output of the YARA scan, the script appends an event to the Active Response log, ``/var/ossec/logs/active-responses.log``, with the following format: .. code-block:: none @@ -187,7 +187,7 @@ Perform the following steps to configure YARA and the FIM module on the monitore .. note:: - There's no need to configure the Wazuh agent to monitor the active response log as it’s part of the agent default configuration. + There's no need to configure the Wazuh agent to monitor the Active Response log as it’s part of the agent default configuration. #. Change the script ownership and permissions with the following commands: @@ -217,7 +217,7 @@ Perform the following steps to configure YARA and the FIM module on the monitore Wazuh server configuration ^^^^^^^^^^^^^^^^^^^^^^^^^^ -Perform the following steps to configure Wazuh FIM to alert file changes in a monitored directory on the endpoint. Then, configure the active response module to trigger a YARA scan on detection of a new or modified file. +Perform the following steps to configure Wazuh FIM to alert file changes in a monitored directory on the endpoint. Then, configure the Active Response module to trigger a YARA scan on detection of a new or modified file. #. Add the following custom decoders to the ``/var/ossec/etc/decoders/local_decoder.xml`` file. This extracts information from the YARA scan results: @@ -288,7 +288,7 @@ Perform the following steps to configure Wazuh FIM to alert file changes in a mo - ````: This uniquely identifies it as the ``yara_linux`` command. - ````: This specifies the active response script or executable that must execute after a trigger. In this case, ``yara.sh``. - ````: This specifies where the YARA binary and rules are located. - - ````: This specifies if the active response needs to undo an action after a specified period. It is set to ``no``, which represents a stateless active response. + - ````: This specifies if the Active Response needs to undo an action after a specified period. It is set to ``no``, which represents a stateless active response. The ```` block defines the criteria used to execute a specific command: @@ -344,7 +344,7 @@ Infrastructure ========== =========== Endpoint Description ========== =========== -Windows 11 The active response module runs YARA scans on new or modified files whenever the Wazuh FIM module alerts about them. +Windows 11 The Active Response module runs YARA scans on new or modified files whenever the Wazuh FIM module alerts about them. ========== =========== Windows endpoint configuration @@ -404,7 +404,7 @@ Perform the following steps to install Python, and YARA, and download YARA rules > mkdir 'C:\Program Files (x86)\ossec-agent\active-response\bin\yara\rules\' > cp yara_rules.yar 'C:\Program Files (x86)\ossec-agent\active-response\bin\yara\rules\' -Configure active response and FIM +Configure Active Response and FIM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Perform the steps below to configure the Wazuh FIM and a YARA scan active response script for the detection of malicious files on the endpoint. diff --git a/source/user-manual/manager/event-logging.rst b/source/user-manual/manager/event-logging.rst index 6b85408391..eea5c1bd90 100644 --- a/source/user-manual/manager/event-logging.rst +++ b/source/user-manual/manager/event-logging.rst @@ -24,7 +24,7 @@ The table below describes the log files and their storage location on the Wazuh | ``/var/ossec/logs/integrations.log`` | Internal | Stores logs generated by the Wazuh integration module when interfacing with third-party | | | | applications and systems. | +--------------------------------------------+------------+---------------------------------------------------------------------------------------------+ -| ``/var/ossec/logs/active-responses.log`` | Internal | Stores logs generated by the Wazuh active response module. | +| ``/var/ossec/logs/active-responses.log`` | Internal | Stores logs generated by the Wazuh Active Response module. | +--------------------------------------------+------------+---------------------------------------------------------------------------------------------+ | ``/var/ossec/logs/firewall/firewall.log`` | Internal | Stores logs generated by the firewall. | +--------------------------------------------+------------+---------------------------------------------------------------------------------------------+ diff --git a/source/user-manual/reference/centralized-configuration.rst b/source/user-manual/reference/centralized-configuration.rst index 43c7011fac..14899e17da 100644 --- a/source/user-manual/reference/centralized-configuration.rst +++ b/source/user-manual/reference/centralized-configuration.rst @@ -44,7 +44,7 @@ The manager pushes all files included in the group folder to the agents belongin In case an agent is assigned to multiple groups, all the files contained in each group folder will be merged into one, and subsequently sent to the agents, being the last one the group with the highest priority. -The file ``ar.conf`` (active response status) will always be sent to agents even if it is not present in the group folder. +The file ``ar.conf`` (Active Response status) will always be sent to agents even if it is not present in the group folder. The agent will store the shared files in ``/var/ossec/etc/shared``, not in a group folder. diff --git a/source/user-manual/reference/ossec-conf/active-response.rst b/source/user-manual/reference/ossec-conf/active-response.rst index 2d634a1891..44a38c902e 100644 --- a/source/user-manual/reference/ossec-conf/active-response.rst +++ b/source/user-manual/reference/ossec-conf/active-response.rst @@ -1,7 +1,7 @@ .. Copyright (C) 2015, Wazuh, Inc. .. meta:: - :description: Learn about local configuration (ossec.conf) and how to configure the active response. Check out the options and a sample configuration in this section of the Wazuh documentation. + :description: Learn about local configuration (ossec.conf) and how to configure the Active Response. Check out the options and a sample configuration in this section of the Wazuh documentation. .. _reference_ossec_active_response: @@ -15,7 +15,7 @@ active-response -In the active response configuration section, an existing command is bound to one or more rules or rule types along with additional criteria for when to execute the command. There is no limit to the number of active responses that can be used, however, each active response must be configured in its own separate ```` section. +In the Active Response configuration section, an existing command is bound to one or more rules or rule types along with additional criteria for when to execute the command. There is no limit to the number of active responses that can be used, however, each active response must be configured in its own separate ```` section. Options ------- diff --git a/source/user-manual/reference/ossec-conf/commands.rst b/source/user-manual/reference/ossec-conf/commands.rst index fe031c33a1..c363a59353 100644 --- a/source/user-manual/reference/ossec-conf/commands.rst +++ b/source/user-manual/reference/ossec-conf/commands.rst @@ -90,7 +90,7 @@ Allows the user to customize the parameters sent to the active response script l timeout_allowed ^^^^^^^^^^^^^^^ -Specifies whether the command is *stateful* or *stateless*. If yes, the command is stateful, meaning it will undo its original action after the period of time specified in the active response. +Specifies whether the command is *stateful* or *stateless*. If yes, the command is stateful, meaning it will undo its original action after the period of time specified in the Active Response. +--------------------+--------+ | **Default value** | no | diff --git a/source/user-manual/reference/tools/wazuh-control.rst b/source/user-manual/reference/tools/wazuh-control.rst index 87cbfffc1d..fffd4d9b2f 100644 --- a/source/user-manual/reference/tools/wazuh-control.rst +++ b/source/user-manual/reference/tools/wazuh-control.rst @@ -24,7 +24,7 @@ The ``-j`` option is used for enabling JSON output format, but only in Wazuh ser +-------------+---------------------------------------------------------------------------------------------------------+ | **reload** | Restart all Wazuh processes except wazuh-execd. | | | | -| | This allows an agent to reload without losing active response status. | +| | This allows an agent to reload without losing Active Response status. | | | | | | This option is not available on a local Wazuh installation. | +-------------+---------------------------------------------------------------------------------------------------------+ diff --git a/source/user-manual/reference/unattended-installation.rst b/source/user-manual/reference/unattended-installation.rst index 3fbecd8467..433723a295 100644 --- a/source/user-manual/reference/unattended-installation.rst +++ b/source/user-manual/reference/unattended-installation.rst @@ -35,7 +35,7 @@ Global + +-------------------------------------------------------+---------------------------------------------------------------------------------------------------+ | | Allowed values | "y", "n" | +------------------------------------+-------------------------------------------------------+---------------------------------------------------------------------------------------------------+ -| **USER_ENABLE_ACTIVE_RESPONSE** | If it is set to "n", active response will be disabled. | +| **USER_ENABLE_ACTIVE_RESPONSE** | If it is set to "n", Active Response will be disabled. | + +-------------------------------------------------------+---------------------------------------------------------------------------------------------------+ | | Allowed values | "y", "n" | +------------------------------------+-------------------------------------------------------+---------------------------------------------------------------------------------------------------+ From 1ed186c1d2986bf7ce5b8d1c55d6838eb2259e65 Mon Sep 17 00:00:00 2001 From: Javier Medeot Date: Mon, 21 Oct 2024 15:55:23 -0300 Subject: [PATCH 2/2] Add changes from review --- source/compliance/pci-dss/active-response.rst | 6 +++--- source/getting-started/use-cases/file-integrity.rst | 2 +- .../leveraging-llms-for-alert-enrichment.rst | 2 +- .../active-response/ar-use-cases/disabling-user-account.rst | 2 +- source/user-manual/capabilities/active-response/index.rst | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/source/compliance/pci-dss/active-response.rst b/source/compliance/pci-dss/active-response.rst index 16cf672676..06928a4165 100644 --- a/source/compliance/pci-dss/active-response.rst +++ b/source/compliance/pci-dss/active-response.rst @@ -1,14 +1,14 @@ .. Copyright (C) 2015, Wazuh, Inc. .. meta:: - :description: Active response allows the execution of scripts when an event matches certain rules in the Wazuh ruleset. Learn more about it in this section. + :description: Active Response allows the execution of scripts when an event matches certain rules in the Wazuh ruleset. Learn more about it in this section. .. _pci_dss_active_response: -Active response +Active Response =============== -Active response allows the execution of scripts whenever an event matches certain rules in your Wazuh ruleset. The actions executed could be a firewall block or drop, traffic shaping or throttling, or account lockout, among others. +Active Response allows the execution of scripts whenever an event matches certain rules in your Wazuh ruleset. The actions executed could be a firewall block or drop, traffic shaping or throttling, or account lockout, among others. The Active Response module helps to meet the following PCI DSS requirement: diff --git a/source/getting-started/use-cases/file-integrity.rst b/source/getting-started/use-cases/file-integrity.rst index 048737eecc..af1e1b5eb8 100644 --- a/source/getting-started/use-cases/file-integrity.rst +++ b/source/getting-started/use-cases/file-integrity.rst @@ -89,7 +89,7 @@ The Wazuh FIM module supports various integrations, including but not limited to - **File integrity monitoring and YARA**: By combining the Wazuh FIM module and the YARA tool, it is possible to detect malware when suspicious file additions or modifications are identified. The YARA rule files contain samples of malware indicators that are downloaded to the monitored endpoints. When the FIM module detects a change in the monitored file or directory, it executes a YARA scan using a script to determine if it is malware. If the YARA rule finds a match with a file, it will send the scan results to the Wazuh server for decoding and alerting. This would be reported according to the custom rule and decoder configurations configured on the Wazuh server. Check this documentation for more information on :doc:`how to integrate the Wazuh FIM module with YARA `. - **File integrity monitoring and VirusTotal**: The Wazuh :doc:`Integrator module ` connects to external APIs and alerting tools such as VirusTotal. The :doc:`VirusTotal integration ` uses the VirusTotal API to detect malicious file hashes within the files and directories monitored by the FIM module. Once enabled, when FIM generates alerts, Wazuh initiates the VirusTotal integration to extract the hash value associated with the flagged file from the alert. The VirusTotal API is then used to compare these hashes against its scanning engines for potentially malicious content. -- **File integrity monitoring and active response**: The :doc:`Wazuh Active Response ` module automatically responds to threats identified in a timely manner. This combination enables the FIM module to not only detect but also respond to malicious activities. You can configure active response scripts to execute when the FIM module detects file changes in your monitored environment. Additionally, it also generates alerts for the response performed. This reduces the Mean Time To Respond (MTTR) as malicious changes detected are remediated in a timely manner. +- **File integrity monitoring and Active Response**: The :doc:`Wazuh Active Response ` module automatically responds to threats identified in a timely manner. This combination enables the FIM module to not only detect but also respond to malicious activities. You can configure active response scripts to execute when the FIM module detects file changes in your monitored environment. Additionally, it also generates alerts for the response performed. This reduces the Mean Time To Respond (MTTR) as malicious changes detected are remediated in a timely manner. In the image below Wazuh triggers when a file is added to the monitored endpoint. The VirusTotal API scans the file and identifies it as malicious content on 55 engines. Then the Wazuh Active Response module acts immediately to remove the threat from the monitored endpoint. diff --git a/source/proof-of-concept-guide/leveraging-llms-for-alert-enrichment.rst b/source/proof-of-concept-guide/leveraging-llms-for-alert-enrichment.rst index 3275c34346..7d61b5b541 100644 --- a/source/proof-of-concept-guide/leveraging-llms-for-alert-enrichment.rst +++ b/source/proof-of-concept-guide/leveraging-llms-for-alert-enrichment.rst @@ -10,7 +10,7 @@ Leveraging LLMs for alert enrichment YARA is a tool that detects and classifies malware artifacts. While YARA can identify known patterns and signatures of malicious activity, human intervention is often required to interpret and contextualize the output of YARA scans. ChatGPT is a generative AI chatbot developed by OpenAI. It provides users with various LLMs to process data. These LLMs can analyze and enrich YARA alerts with additional context, providing security teams with deeper insights into the nature and severity of detected threats. -In this use case, we integrate Wazuh with YARA to detect when a malicious file is added to a monitored endpoint. The integration utilizes the Wazuh :doc:`FIM ` module to monitor a directory for new or modified files. When a file modification or addition is detected, the Wazuh :doc:`Active Response ` module triggers a YARA scan on the file. The Active response module automatically deletes the malicious file from the endpoint if it has a positive match with a malicious signature. The Active Response module then queries ChatGPT to enrich the YARA scan result with additional insight into the malicious file that helps security teams understand its nature, potential impact, and remediation. +In this use case, we integrate Wazuh with YARA to detect when a malicious file is added to a monitored endpoint. The integration utilizes the Wazuh :doc:`FIM ` module to monitor a directory for new or modified files. When a file modification or addition is detected, the Wazuh :doc:`Active Response ` module triggers a YARA scan on the file. The Active Response module automatically deletes the malicious file from the endpoint if it has a positive match with a malicious signature. The Active Response module then queries ChatGPT to enrich the YARA scan result with additional insight into the malicious file that helps security teams understand its nature, potential impact, and remediation. Infrastructure -------------- diff --git a/source/user-manual/capabilities/active-response/ar-use-cases/disabling-user-account.rst b/source/user-manual/capabilities/active-response/ar-use-cases/disabling-user-account.rst index 8e11aa428c..831bfa7614 100644 --- a/source/user-manual/capabilities/active-response/ar-use-cases/disabling-user-account.rst +++ b/source/user-manual/capabilities/active-response/ar-use-cases/disabling-user-account.rst @@ -68,7 +68,7 @@ Wazuh server - ````: Specifies the command to configure. This is the command name ``disable-account`` defined in the previous step. - ````: Specifies where the command executes. Using the ``local`` value here means that the command executes on the monitored endpoint where the trigger event occurs. - ````: The Active Response module executes the command if rule ID ``120100``: ``Possible password guess on $(dstuser): 3 failed logins in a short period of time`` fires. - - ````: Specifies how long the active response action must last. In this use case, we configure it to last for 300 seconds. After that period, the active response reverts its action and re-enables the account. + - ````: Specifies how long the active response action must last. In this use case, we configure it to last for 300 seconds. After that period, the Active Response reverts its action and re-enables the account. #. Restart the Wazuh manager service to apply changes: diff --git a/source/user-manual/capabilities/active-response/index.rst b/source/user-manual/capabilities/active-response/index.rst index e610b5019e..b345292a99 100644 --- a/source/user-manual/capabilities/active-response/index.rst +++ b/source/user-manual/capabilities/active-response/index.rst @@ -26,7 +26,7 @@ The Wazuh Active Response module executes these scripts on monitored endpoints w The image below shows the Active Response workflow. .. thumbnail:: /images/manual/active-response/active-response-workflow.png - :title: Active response workflow + :title: Active Response workflow :align: center :width: 100%