wazuh / wazuh

Wazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.
https://wazuh.com/
Other
10.4k stars 1.6k forks source link

New Wazuh directory layout #9175

Open TomasTurina opened 3 years ago

TomasTurina commented 3 years ago
Wazuh version Component Install type Install method Platform
5.0 All Manager/Agent Packages/Sources All

Description

The idea of this epic is to reorganize the Wazuh installation directories in order to make them more understandable. It should also follow the name convention of common programs and directories. This reorganization applies to all the OS that Wazuh supports.

Manager

The manager directory layout, at a high level, should be as follows:

wazuh-manager/
     ├─ bin/
     │    ├─ daemons/
     │    │    ├─ ...
     │    └─ tools/
     │         ├─ ...
     ├─ etc/
     │    ├─ config/
     │    │    ├─ ...
     │    ├─ ruleset/
     │    │    ├─ ...
     │    └─ ssl/
     │         ├─ ...
     ├─ lib/
     │    ├─ ...
     ├─ usr/
     │    ├─ bin/
     │    │    ├─ ...
     │    └─ shared/
     │         ├─ api/
     │         │    ├─ ...
     │         ├─ config/
     │         │    ├─ ...
     │         ├─ framework/
     │         │    ├─ ...
     │         └─ ruleset/
     │              ├─ ...
     ├─ tmp/
     └─ var/
          ├─ backup/
          │    ├─ ...
          ├─ daemons/
          │    ├─ ...
          ├─ db/
          │    ├─ ...
          ├─ log/
          │    ├─ ...
          ├─ outcoming/
          │    ├─ ...
          └─ run/
               ├─ ...

Agent

The agent directory layout, at a high level, should be as follows:

wazuh-agent/
     ├─ bin/
     │    ├─ daemons/
     │    │    ├─ ...
     │    └─ tools/
     │         ├─ ...
     ├─ etc/
     │    ├─ config/
     │    │    ├─ ...
     │    ├─ ruleset/
     │    │    ├─ ...
     │    └─ ssl/
     │         ├─ ...
     ├─ lib/
     │    ├─ ...
     ├─ usr/
     │    ├─ bin/
     │    │    ├─ ...
     │    └─ shared/
     │         ├─ config/
     │         │    ├─ ...
     │         └─ ruleset/
     │              ├─ ...
     ├─ tmp/
     └─ var/
          ├─ backup/
          │    ├─ ...
          ├─ daemons/
          │    ├─ ...
          ├─ db/
          │    ├─ ...
          ├─ incoming/
          │    ├─ ...
          ├─ log/
          │    ├─ ...
          └─ run/
               ├─ ...

Subtasks

Validation of the requirements by the Product Owners

The design stage is blocked until the Product Owners sign off the requirements.

jsegitz commented 3 years ago

From a security POV I would highly recommend to structure the directory layout in a way that doesn't require any root process to modify/read files in paths that can be influenced by the runtime user. Otherwise you will have to do a complicated and error prone dance to ensure you do this securely, which can be really tough especially on older systems where kernel support is limited.

zbalkan commented 1 year ago

Keeping Wazuh under /var/ossec/ folder forced us to make a risk analysis and accept the risk based on the results but face possible incompliant reports. Because CIS and STIG baselines require /var as a separate mount point with noexec set.

The proper way to handle this is probably to comply with the Linux Filesystem Hierarchy Standard (FHS). As it is not fully implemented by some distros, implementing the most commonly used subset of it would be more realistic.

A scenario like below would make more sense: Current Proposed
/var/ossec/etc/ /etc/wazuh/
/var/ossec/logs/ /var/log/wazuh/
/var/ossec/bin/ /usr/local/bin/wazuh/
/var/ossec/queue/ /tmp/wazuh/queue/ or /run/wazuh/queue/
/var/ossec/tmp/ /tmp/wazuh/ and /var/tmp/wazuh/ for temporary files needed to be preserved between reboots

This would highly improve the maintenance and hardening in general. It would reduce the cognitive load of sysadmins. Also, it would allow implementing hardening baselines without exceptions.

vikman90 commented 1 year ago

@zbalkan gotcha and agree. In fact, we intend this structure to be compatible with the UNIX hierarchy and a possible "portable" installation.

This means we could build and run the code immediately or copy the entire folder to another directory. On another hand, packages would install the agent or the manager on the root (/), thus having the system installed according to the standard hierarchy.

Best regards.

zbalkan commented 1 year ago

Hi @vikman90,

Thank you for the information. What was the use case for a portable installation? Migration to a new cluster?

vikman90 commented 1 year ago

Hi @zbalkan,

We know that some users need to install their agent in a specific location, according to their environment (partitions or company restrictions). When I say "portable installation" I mean that the user would have the freedom to choose in which folder he wants to install it. Thus, the base installation folder would have the defined hierarchy.

Best regards.

ochurlaud commented 10 months ago

Hi,

reading the proposition, I find it great for portable installation but not for system deployment (RPM/DEB). Indeed, if you would remove the top folder (containing the name of the application: wazuh-agent, wazuh-manager), it creates a mess in the /var , /etc , /usr/share and /bin folders as nothing recalls wazuh-agent or wazuh-manager.

zbalkan commented 10 months ago

@ochurlaud , as a user of Wazuh for a while, I agree with the issues on the proposal. Just like I discussed above I believe implementation of FHS or XDG Base Directory Specification would help more to the sysadmins as these are the most commonly used specifications. It would create less cognitive load. It would be compatible with many other applications by convention. It would allow us to use noexec on /var.

@vikman90, would it be reasonable for me to create a separate issue for FHS or XDG compliant folder hierarchy discussion?

GioMac commented 2 months ago

@ochurlaud @zbalkan package managers (especially with RPM) are designed in way that it forces software vendors to package applications to comply with HFS/XDG as much as possible and solves any issues related to configuration updates, file inclusion, executable detection etc... reason of use of wazuh is security, but not using "noexec" for /var/ defeats that reason.

/usr/local/bin/ is usually reserved for "overrides" of official packages, /usr/bin shall be used instead of /usr/local/bin/wazuh/. Note that /wazuh/ is also removed as it won't be included in typical PATH and any additional manipulation in that part is not a wise option.

/tmp should NOT be used for files that are NEEDED