Skip to content

Commit edeb6c9

Browse files
committed
Merge remote-tracking branch 'origin/4.12' into 4.13.0
2 parents b1e11cd + b1f1525 commit edeb6c9

File tree

8 files changed

+68
-75
lines changed

8 files changed

+68
-75
lines changed

CHANGELOG.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -44,6 +44,8 @@ All notable changes to this project will be documented in this file.
4444
- **Post-release**: Added a table describing the possible environment statuses in the cloud service documentation. ([#8407](https://github.com/wazuh/wazuh-documentation/pull/8407))
4545
- **Post-release**: Added the Wazuh indexer API reference. ([#8756](https://github.com/wazuh/wazuh-documentation/pull/8756))
4646
- **Post-release**: Added examples of Wazuh tools to the user manual reference. ([#8763](https://github.com/wazuh/wazuh-documentation/pull/8763))
47+
- **Post-release**: Added the `ap-northeast-1` (Tokyo) region. ([#8818](https://github.com/wazuh/wazuh-documentation/pull/8818))
48+
- **Post-release**: Added a Q&A to the Cloud service FAQ section. ([#8832](https://github.com/wazuh/wazuh-documentation/pull/8832))
4749

4850
### Changed
4951

@@ -74,7 +76,8 @@ All notable changes to this project will be documented in this file.
7476
- **Post-release**: Updated the Windows logo in the documentation. ([#8804](https://github.com/wazuh/wazuh-documentation/pull/8804))
7577
- **Post-release**: Updated the offline installation guide. ([#8803](https://github.com/wazuh/wazuh-documentation/pull/8803))
7678
- **Post-release**: Updated the instruction and images in Wazuh server API getting started documentation to reflect the new navigation path (**Server management** > **Dev Tools**). ([#8811](https://github.com/wazuh/wazuh-documentation/pull/8811))
77-
79+
- **Post-release**: Updated the *Getting started with Wazuh - Architecture* documentation. ([#8819](https://github.com/wazuh/wazuh-documentation/pull/8819))
80+
- **Post-release**: Changed Suricata ruleset file permission in POC guide. ([#8821](https://github.com/wazuh/wazuh-documentation/pull/8821))
7881

7982
### Fixed
8083

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
.. Copyright (C) 2015, Wazuh, Inc.
2+
3+
**Asia Pacific**
4+
5+
- Tokyo: ``ap-northeast-1``
6+
- Mumbai: ``ap-south-1``
7+
- Singapore: ``ap-southeast-1``
8+
- Sydney: ``ap-southeast-2``
9+
10+
**Europe**
11+
12+
- Frankfurt: ``eu-central-1``
13+
- London: ``eu-west-2``
14+
15+
**North America**
16+
17+
- Canada: ``ca-central-1``
18+
- North Virginia: ``us-east-1``
19+
- Ohio: ``us-east-2``
20+
21+
.. End of file

source/cloud-service/getting-started/starting-faq.rst

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -104,3 +104,12 @@ Can I cancel at any time?
104104
-------------------------
105105

106106
Yes, you can cancel at any time with no penalty. You can keep using your environment until the end of your :doc:`current billing cycle </cloud-service/account-billing/billing-history>`, and no future charges are incurred after this period.
107+
108+
How do I convert my environment from trial to production?
109+
---------------------------------------------------------
110+
111+
- Login to your Wazuh Cloud Console
112+
- Click **Manage** on the top right corner
113+
- Select **Purchase environment**
114+
- Follow the prompt to provide your billing details which includes your contact details and card details
115+
- Click **Next** to complete your purchase

source/cloud-service/glossary.rst

Lines changed: 1 addition & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -99,21 +99,7 @@ A region is a geographic area where the data center of the cloud provider that h
9999

100100
Available regions:
101101

102-
* North Virginia: ``us-east-1``
103-
104-
* Ohio: ``us-east-2``
105-
106-
* London: ``eu-west-2``
107-
108-
* Frankfurt: ``eu-central-1``
109-
110-
* Mumbai: ``ap-south-1``
111-
112-
* Singapore: ``ap-southeast-1``
113-
114-
* Sydney: ``ap-southeast-2``
115-
116-
* Canada: ``ca-central-1``
102+
.. include:: /_templates/cloud-service-regions.rst
117103

118104
.. _cloud_glossary_wazuh_cloud_api:
119105

source/cloud-service/your-environment/technical-faq.rst

Lines changed: 1 addition & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -150,21 +150,7 @@ What are the available regions?
150150

151151
Available regions:
152152

153-
* North Virginia: ``us-east-1``
154-
155-
* Ohio: ``us-east-2``
156-
157-
* London: ``eu-west-2``
158-
159-
* Frankfurt: ``eu-central-1``
160-
161-
* Mumbai: ``ap-south-1``
162-
163-
* Singapore: ``ap-southeast-1``
164-
165-
* Sydney: ``ap-southeast-2``
166-
167-
* Canada: ``ca-central-1``
153+
.. include:: /_templates/cloud-service-regions.rst
168154

169155
When selecting a region to host your environment, if you are not sure which one is the best option for you, select one that is the closest to your location since this typically reduces latency for indexing and search requests.
170156

source/getting-started/architecture.rst

Lines changed: 31 additions & 43 deletions
Original file line numberDiff line numberDiff line change
@@ -6,49 +6,60 @@
66
Architecture
77
============
88

9-
The Wazuh architecture is based on :doc:`agents <components/wazuh-agent>`, running on the monitored endpoints, that forward security data to a central :doc:`server <components/wazuh-server>`. Agentless devices such as firewalls, switches, routers, and access points are supported and can actively submit log data via Syslog, SSH, or using their API. The central server decodes and analyzes the incoming information and passes the results along to the Wazuh indexer for indexing and storage.
9+
The Wazuh architecture is composed of a multi-platform Wazuh :doc:`agent <components/wazuh-agent>` and three central components: the Wazuh :doc:`server <components/wazuh-server>`, Wazuh :doc:`indexer <components/wazuh-indexer>`, and Wazuh :doc:`dashboard <components/wazuh-dashboard>`. The agent is deployed on endpoints to collect and forward security data to the Wazuh server for analysis. The analyzed data is then forwarded to the Wazuh indexer for indexing and storage, and subsequently to the Wazuh dashboard for alerting and visualization.
1010

11-
The Wazuh indexer cluster is a collection of one or more nodes that communicate with each other to perform read and write operations on indices. Small Wazuh deployments, which do not require processing large amounts of data, can easily be handled by a single-node cluster. Multi-node clusters are recommended when there are many monitored endpoints, when a large volume of data is anticipated, or when high availability is required.
11+
Wazuh also supports agentless monitoring for systems and devices where installing the Wazuh agent is not possible. Network devices such as firewalls, switches, routers, and access points can actively forward log data via Syslog and SSH.
1212

13-
For production environments, it is recommended to deploy the Wazuh server and Wazuh indexer to different hosts. In this scenario, Filebeat is used to securely forward Wazuh alerts and archived events to the Wazuh indexer cluster (single-node or multi-node) using TLS encryption.
13+
The Wazuh central components can be deployed in different ways, depending on scalability and availability needs:
1414

15-
The diagram below represents a Wazuh deployment architecture. It shows the solution components and how the :doc:`Wazuh server <components/wazuh-server>` and the :doc:`Wazuh indexer <components/wazuh-indexer>` nodes can be configured as clusters, providing load balancing and high availability.
15+
- **All-in-one deployment:** All Wazuh components (server, indexer, and dashboard) are installed on a single server. Best suited for labs and small environments with a limited number of monitored endpoints.
16+
17+
- **Single-node deployment:** The Wazuh server, indexer, and dashboard are each deployed on separate servers. Recommended for medium environments that require higher performance than an all-in-one setup.
18+
19+
- **Multi-node deployment:** Typically, one instance of the Wazuh dashboard and multiple instances of the Wazuh server (Wazuh server cluster) and indexer (Wazuh indexer cluster) are deployed on their individual servers, respectively. The number of instances varies depending on your needs. This deployment is recommended for large environments with high event throughput, or when fault tolerance and high availability are required.
20+
21+
Visit the :doc:`installation guide </installation-guide/index>` and :doc:`installation alternatives </deployment-options/index>` documentation to learn about the different ways to deploy Wazuh.
22+
23+
The diagram below represents a Wazuh deployment architecture. It shows how the Wazuh server and the Wazuh indexer nodes can be configured as clusters, providing load balancing and high availability.
1624

1725
.. thumbnail:: /images/getting-started/deployment-architecture.png
1826
:title: Deployment architecture
1927
:alt: Deployment architecture
2028
:align: center
2129
:width: 80%
2230

23-
Wazuh agent - Wazuh server communication
24-
----------------------------------------
31+
Component communication
32+
-----------------------
2533

26-
The :doc:`Wazuh agent <components/wazuh-agent>` continuously sends events to the :doc:`Wazuh server <components/wazuh-server>` for analysis and threat detection. To start shipping this data, the agent establishes a connection with the server service for agent connection, which listens on port 1514 by default (this is configurable). The Wazuh server then decodes and rule-checks the received events, utilizing the analysis engine. Events that trip a rule are augmented with alert data such as rule ID and rule name. Events can be spooled to one or both of the following files, depending on whether or not a rule is tripped:
34+
Wazuh agent - Wazuh server
35+
^^^^^^^^^^^^^^^^^^^^^^^^^^
2736

28-
- The file ``/var/ossec/logs/archives/archives.json`` contains all events whether they tripped a rule or not.
29-
- The file ``/var/ossec/logs/alerts/alerts.json`` contains only events that tripped a rule with high enough priority (the threshold is configurable).
37+
The :doc:`Wazuh agent <components/wazuh-agent>` continuously sends events to the :doc:`Wazuh server <components/wazuh-server>` for analysis and threat detection. To start shipping this data, the agent establishes a connection with the Wazuh server service for agent connection, which listens on TCP port 1514 by default (this is configurable). The Wazuh server then decodes and matches rules against the received events, utilizing the Wazuh Analysis engine.
3038

3139
The Wazuh messages protocol uses AES encryption by default, with 128 bits per block and 256-bit keys. Blowfish encryption is optional.
3240

3341
.. note::
3442

3543
Read the `Benefits of using AES in the Wazuh communications <https://wazuh.com/blog/benefits-of-using-aes-in-our-communications>`_ document for more information.
3644

37-
Wazuh server - Wazuh indexer communication
38-
------------------------------------------
45+
Wazuh server - Wazuh indexer
46+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
47+
48+
The Wazuh server uses Filebeat to send alert and event data to the Wazuh indexer, using TLS encryption. Filebeat reads the Wazuh server output data and sends it to the Wazuh indexer (by default listening on port 9200/TCP). Once the data is indexed by the Wazuh indexer, the Wazuh dashboard is used to query and visualize the security information.
3949

40-
The Wazuh server uses Filebeat to securely transmit alert and event data to the Wazuh indexer via TLS encryption. Filebeat monitors output data from the Wazuh server and forwards it to the Wazuh indexer, which listens on port 9200/TCP by default. Once indexed, you can analyze and visualize the data through the Wazuh dashboard.
50+
Wazuh dashboard - Wazuh dashboard/Wazuh indexer
51+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4152

42-
The Vulnerability Detection module updates the vulnerability inventory. It also generates alerts, providing insights into system vulnerabilities.
53+
The Wazuh dashboard queries the Wazuh server API (by default listening on port 55000/TCP on the Wazuh server) to display configuration and status-related information of the :doc:`Wazuh server <components/wazuh-server>` and :doc:`agents <components/wazuh-agent>`. This communication is encrypted with TLS and authenticated with a username and password.
4354

44-
The Wazuh dashboard queries the Wazuh RESTful API (by default listening on port 55000/TCP on the Wazuh server) to display configuration and status-related information of the :doc:`Wazuh server <components/wazuh-server>` and :doc:`agents <components/wazuh-agent>`. It can also modify agents or server configuration settings through API calls. This communication is encrypted with TLS and authenticated with a username and password.
55+
The Wazuh dashboard visualizes and queries the information indexed on the Wazuh indexer.
4556

4657
.. _default_ports:
47-
58+
4859
Required ports
4960
--------------
5061

51-
Several services are used for the communication of Wazuh components. Below is the list of default ports used by these services. Users can modify these port numbers when necessary.
62+
Wazuh components communicate using several services. The list of default ports used by these services is shown below. Users can modify these port numbers when necessary.
5263

5364
+-----------------+-----------+----------------+------------------------------------------------+
5465
| Component | Port | Protocol | Purpose |
@@ -74,32 +85,9 @@ Several services are used for the communication of Wazuh components. Below is th
7485
| Wazuh dashboard | 443 | TCP | Wazuh web user interface |
7586
+-----------------+-----------+----------------+------------------------------------------------+
7687

77-
Archival data storage
78-
---------------------
79-
80-
Both alerts and non-alert events are stored in files on the Wazuh server, in addition to being sent to the Wazuh indexer. These files can be written in JSON format (``.json``), or plain text format (``.log``). These files are daily compressed and signed using MD5, SHA1, and SHA256 checksums. The directory and filename structure is as follows:
88+
Wazuh CTI
89+
---------
8190

82-
.. code-block:: bash
91+
The Wazuh Cyber Threat Intelligence (CTI) service is a publicly accessible platform that collects, analyzes, and disseminates actionable information on emerging cyber threats and vulnerabilities. This service currently focuses on vulnerability intelligence, delivering timely updates on Common Vulnerabilities and Exposures (CVEs), severity scores, exploitability insights, and mitigation strategies. It aggregates and sanitizes data from trusted sources, including operating system vendors and major vulnerability databases, to ensure high-quality, relevant intelligence.
8392

84-
root@wazuh-manager:/var/ossec/logs/archives/2022/Jan# ls -l
85-
86-
.. code-block:: none
87-
:class: output
88-
89-
total 176
90-
-rw-r----- 1 wazuh wazuh 234350 Jan 2 00:00 ossec-archive-01.json.gz
91-
-rw-r----- 1 wazuh wazuh 350 Jan 2 00:00 ossec-archive-01.json.sum
92-
-rw-r----- 1 wazuh wazuh 176221 Jan 2 00:00 ossec-archive-01.log.gz
93-
-rw-r----- 1 wazuh wazuh 346 Jan 2 00:00 ossec-archive-01.log.sum
94-
-rw-r----- 1 wazuh wazuh 224320 Jan 2 00:00 ossec-archive-02.json.gz
95-
-rw-r----- 1 wazuh wazuh 350 Jan 2 00:00 ossec-archive-02.json.sum
96-
-rw-r----- 1 wazuh wazuh 151642 Jan 2 00:00 ossec-archive-02.log.gz
97-
-rw-r----- 1 wazuh wazuh 346 Jan 2 00:00 ossec-archive-02.log.sum
98-
-rw-r----- 1 wazuh wazuh 315251 Jan 2 00:00 ossec-archive-03.json.gz
99-
-rw-r----- 1 wazuh wazuh 350 Jan 2 00:00 ossec-archive-03.json.sum
100-
-rw-r----- 1 wazuh wazuh 156296 Jan 2 00:00 ossec-archive-03.log.gz
101-
-rw-r----- 1 wazuh wazuh 346 Jan 2 00:00 ossec-archive-03.log.sum
102-
103-
Rotation and backups of archive files are recommended according to the storage capacity of the :doc:`Wazuh server <components/wazuh-server>`. By using cron jobs, you can easily manage to keep only a specific time window of archive files locally on the server, for example, last year or the last three months.
104-
105-
On the other hand, you may choose to dispense with storing archive files and simply rely on the Wazuh indexer for archive storage. This alternative might be preferred if you run periodic Wazuh indexer snapshot backups and/or have a multi-node Wazuh indexer cluster with shard replicas for high availability. You could even use a cron job to move snapshotted indices to a final data storage server and sign them using MD5, SHA1, and SHA256 hashing algorithms.
93+
This service is integrated directly with the Wazuh Vulnerability Detection module, but is also publicly available at the `Wazuh CTI website <https://cti.wazuh.com/>`_.
-17.7 KB
Loading

source/proof-of-concept-guide/integrate-network-ids-suricata.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -38,7 +38,7 @@ Take the following steps to configure Suricata on the Ubuntu endpoint and send t
3838
3939
$ cd /tmp/ && curl -LO https://rules.emergingthreats.net/open/suricata-6.0.8/emerging.rules.tar.gz
4040
$ sudo tar -xvzf emerging.rules.tar.gz && sudo mkdir /etc/suricata/rules && sudo mv rules/*.rules /etc/suricata/rules/
41-
$ sudo chmod 640 /etc/suricata/rules/*.rules
41+
$ sudo chmod 777 /etc/suricata/rules/*.rules
4242
4343
#. Modify Suricata settings in the ``/etc/suricata/suricata.yaml`` file and set the following variables:
4444

0 commit comments

Comments
 (0)