Hello,

Do you plan to check in the Wazuh_elastic and Wazuh_filebeat cookbooks into the Chef Supermarket?

Hi all!

We detected that in some Centos distributions, the actual Nginx recipe nginx.rb is failing due to some non-usual Nginx default configuration. Normally, in the main configuration file of Nginx /etc/nginx/nginx.conf there should be an include statement which loads the sites defined in the path /etc/nginx/sites-enabled/* but as we detected, this statement did not exist.

To solve this issue we simply need to instead of writing the template into /etc/nginx/sites-available/default we write it as a total separated configuration file in /etc/nginx/conf.d/kibana.conf

Tasks to Do

• Change the template file's path
• Verify the changes.

Kr,

Rshad

Hi team,

I noticed that during Kibana installation, sometimes kills Elasticsearch process because of RAM problems derived from the optimize bundles process.

Tasks:

• Fix jvm.options RAM assignation and add a parameter to control it.

• Remove NODE_OPTIONS='--max-old-space-size=4096' parameter from Kibana installation curl.

Best Regards!

Jose

With below configuration, the expected number of feeds are two, but actually it adds only the latest one i.e ubuntu-16

default['ossec']['conf']['server']['wodle'] = [
{ '@name' => 'vulnerability-detector', 'content!' => {
'disabled' => 'no',
'interval' => '1m',
'run_on_start' => 'yes',
'feed' => { '@name' => 'ubuntu-14' , 'content!' =>
{
'disabled' => 'no',
'update_interval' => '1h',
}
},
'feed' => { '@name' => 'ubuntu-16' , 'content!' =>
{
'disabled' => 'no',
'update_interval' => '1h',
}
},
}
},
]

Hi all,

Some of the attributes of Elastic Stack initialize to an invalid value like:

This has been done to prevent unknown misconfigurations when deploying since declaring this attribute and related ones to 127.0.0.1 would set up the stack properly but the user could ignore that configuration.

In an actual way, we ensure the user consciously set his desired IP/domain for every component.

Community, we need you!

It`s important to us to determine which default case is better in your opinion, do you prefer to configure after setup with default parameters or preconfigure variables and then run the setup?

Let us know by commenting below!

Verify variables before run

Regardless of the option, we choose in the previous scenario, it's required to add verification of those parameters.

In order to avoid said problems some, the pre-check of the variables must be done

Tasks

• Implement pre-run verification of the attributes (not null, variable type, etc...)

• Test changes

• Update README.md

Best regards!

Jose

Hi team,

I just checked that following URLs are deprecated:

• https://raw.githubusercontent.com/wazuh/wazuh/3.9/extensions/elasticsearch/wazuh-elastic6-template-alerts.json
• https://raw.githubusercontent.com/wazuh/wazuh/3.9/extensions/logstash/01-wazuh-local.conf
• https://raw.githubusercontent.com/wazuh/wazuh/3.9/extensions/logstash/01-wazuh-remote.conf

They should be fixed to match the new URLs template.

Best Regards!

Jose.

Hi team!

The current code of Chef doesn't properly manage the compatibility with other Centos/RHEL 7. It uses apt packages and offers no support to other os families. Repositories, installation, and configuration need to be properly updated and tested to support Centos/RHEL 7.

Tasks:

• Implement node['platform_family'] when cases to support centos installations.

• Test changes

• Update README's

Best Regards,

Jose

Hi all!

Wazuh is now able to deal with a new Filebeat module which can be found here.

To do so, we have to run the following commands:

curl -s https://packages-dev.wazuh.com/3.x/filebeat/wazuh-filebeat-0.1.tar.gz | tar -xvz -C /usr/share/filebeat/module
mkdir -p /usr/share/filebeat/module/wazuh
chmod 755 -R /usr/share/filebeat/module/wazuh

Taking into account the proper way to do it with Chef

Kind regards,

Rshad

Please, fix syntax JSON errors in cookbooks/wazuh_manager/README.md:

  {
    "name": "wazuh_manager_master",
    "description": "Wazuh Manager master node",
    "json_class": "Chef::Role",
    "default_attributes": {

    },
    "override_attributes": {
      "ossec": {
        "cluster_disabled": "no",
        "conf": {
          "server": {
            "cluster": {
              "node_name": "node01",
              "node_type": "master",
              "disabled": "no",
              "nodes": {
                "node": ["172.16.10.10", "172.16.10.11"]
              "key": "596f6b328c8ca831a03f7c7ca8203e8b"
            }
          }
        }
    },
    "chef_type": "role",
    "run_list": [
      "recipe[wazuh::manager]"
    ],
    "env_run_lists": {

    }
  }
  {
    "name": "wazuh_manager_client",
    "description": "Wazuh Manager client node",
    "json_class": "Chef::Role",
    "default_attributes": {

    },
    "override_attributes": {
      "ossec": {
        "cluster_disabled": "no",
        "conf": {
          "server": {
            "cluster": {
              "node_name": "node02",
              "node_type": "client",
              "disabled": "no",
              "nodes": {
                "node": ["172.16.10.10", "172.16.10.11"]
              "key": "596f6b328c8ca831a03f7c7ca8203e8b"
            }
          }
        }
    },
    "chef_type": "role",
    "run_list": [
      "recipe[wazuh::manager]"
    ],
    "env_run_lists": {

    }
  }

Thanks! BR, Eugene

Hi team,

According to chef standards, all cookbooks are nested under the cookbooks/ folder in branches 3.9.2_6.8.0 and 3.9.1_7.1.1.

But this configuration doesn't fit the required schema by Source Control Manager of Amazon Opsworks (https://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-installingcustom-repo.html)

In order to fix this for AWS compatibility some changes must be done:

• Get cookbooks out of cookbooks directory and remove it.
• Adapt Berksfile and metadata.rb
• Test such changes on Amazon Linux 1 and 2
• Update README.md
• Update CHANGELOG.md

Best regards,

Jose

Wazuh version: 3.9.4
Elastic version: 6.8.2

• Adapt to new versions (3.9.4 - 7.2.0)
• Update changelog
• Tests
• Tag: v3.9.4_7.2.0
• Draft release

Wazuh version: 3.9.3
Elastic version: 6.8.1

• Adapt to new versions (3.9.3 - 6.8.1)
• Update changelog
• Tests
• Tag: v3.9.3_6.8.1
• Draft release

Hi team!

As defined in #17 , current default attributes don't implement the new features added in 3.9.0.
The implementation of new default attributes is required in order to generate an updated ossec.conf file to give support to the new functionalities.

Tasks

• Evaluate and list all differences between old ossec.conf (generated with gyoku) and the ossec.conf file of v.3.9

• Implement new fields as default attributes.

• Test the new features added.

Regards!

Jose

Wazuh version: 3.9.2
Elastic version: 7.1.1

• Adapt to new versions (3.9.2 - 7.1.1)
• Update changelog
• Tests
• Tag: v3.9.2
• Draft release

Hi all!

When adding Elasticsearch testing suite to Kitchen testing suites, and specifically when trying to update the packages repository: apt-get update we got the following error:

“ERROR: The method driver /usr/lib/apt/methods/https could not be found.”

To solve this issue, we need to first install the packages:

• apt-transport-https
• ca-certificates

apt-get install apt-transport-https ca-certificates

Tasks to Do:

• Add the corresponding tasks in the cookbook to install the mentioned packages.
• Test the packages.

Kr,

Rshad

Wazuh version: 3.12.3
Elastic version: 7.6.2

Tasks

• Adapt to new versions (3.12.3 - 7.6.2)

• Update changelog

• Check templates and update them if needed

• Tests

• Tag: v3.12.3_7.6.2

• Update documentation references

• Draft release

As stated in #17, the wazuh cookbook will be split into specific cookbooks for the agent and manager. This issue details the steps needed aswell as the process status in order to give advanced detail about this part of refactoring.

Tasks

• Split agent-specific and manager-specific attributes.
• Divide specific recipes and fix names.
• Fix dependencies
• Separate spec recipes.
• Test Agent and Manager deploy after splitting into two cookbooks.

Wazuh version: 3.11.0
Elastic version: 7.5.1

Tasks

• Adapt to new versions (3.11.0_7.5.1)
• Update changelog
• Tests
• Tag: v3.11.0_7.5.1
• Draft release

Wazuh version: 3.9.0
Elastic version: 6.6.1

• Adapt to new versions (3.9.0 - 6.7.2)
• Update changelog
• Tests
• Tag: v3.9.0
• Draft release

Wazuh version: 3.9.3
Elastic version: 7.2.0

• Adapt to new versions (3.9.3 - 7.2.0)
• Update changelog
• Tests
• Tag: v3.9.3_7.2.0
• Draft release

Wazuh version: 3.12.0
Elastic version: 7.6.1

Tasks

• Adapt to new versions (3.12.0 - 7.6.1)

• Update changelog

• Check templates and update them if needed

• Tests

• Tag: v3.12.0_7.6.1

• Draft release

Wazuh version: 3.12.2
Elastic version: 7.6.2

Tasks

• Adapt to new versions (3.12.2 - 7.6.2)

• Update changelog

• Check templates and update them if needed

• Tests

• Tag: v3.12.2_7.6.2

• Draft release

chocolatey_package 'ossec.wazuh.agent' do
notifies # see description
options String
package_name String, Array # defaults to 'name' if not specified
source String
subscribes # see description
timeout String, Integer
version String, Array
returns Integer, Array of Integers
action Symbol # defaults to :install if not specified
end

need to update choco repo , as well one could add to cookbook to replace stings in config file.
ie ip address.. anyrate , could batch build deploys..
https://github.com/m-dwyer/packer-malware
https://github.com/GoSecure/malboxes
could also add to malboxes to get the sig into the SIEM ...

aswell , also salt , puppet ansible , etc cookbooks can likewise use choco as backend..

https://chocolatey.org/packages/ossec.wazuh.agent/3.5.0.1

Hi team,

Despite the fact that Filebeat is installed by default, the installation of Wazuh with the Cluster configuration has not been tested.

Also, some parameters would make the installation much more customizable like the hosts field in filebeat.yml.

Tasks

• Implement required parameters to customize the Wazuh Cluster

• Test configuration

• Update READMEs to document changes and new attributes.

Regards!

Jose

Wazuh version: 3.9.5
Elastic version: 7.2.0

• Adapt to new versions (3.9.5 - 7.2.0)
• Update changelog
• Tests
• Tag: v3.9.5_7.2.0
• Draft release

Hello team,

I've noticed recipes for Chef are not properly updated.
In many cases they are missing parameters and options like, for example, the ability to add an agent group at registration time.

Regards.

Right now the chef recipes will fail when is needed to download the Oracle JDK:

Like could be seen at the above screenshot the file that is used to install Oracle JDK is missing from the provided url.

Wazuh version: 3.11.1
Elastic version: 7.5.1

Tasks

• Adapt to new versions (3.11.1 - 7.5.1)

• Check templates and update them if needed

• Tests

• Update changelog

• Tag: v3.11.1_7.5.1

• Update documentation references

• Draft release

Hi team,

The ability to install Agents but don't register it is quite useful and requested by the community (see wazuh/wazuh-puppet#106).

Adding that feature would give flexibility to the Agent installation and would ease the installation on cloud environments for example.

Tasks

• Modify code to allow user configure if he wants to register the agent or not

• Test changes with and without the flag enabled

• Update README.md

Best regards

Jose

Description

Starting on 1/1/2020 NodeJS v8 is End Of Life and lost support.

An upgraded is mandatory to ensure up to date security and support. Our Docker images are already shipping with v10.

Tasks

• Upgrade NodeJS to v10
• Test a complete deployment

Hi team!

According to https://documentation.wazuh.com/3.x/installation-guide/optional-configurations/kibana_ssl.html Nginx can be configured to secure the communications with Kibana.

The current installation process does not support it. An approach could be to include a template and declare attributes to customize the Nginx configuration.

Tasks to Do

• Add the corresponding Recipe.
• Add the required dependencies.
• Parameter[ize] the recipe the most possible.
• Test the changes on different OS/platforms
• • Debian based distributions.
• • RPM-based distributions.

Best regards!

Jose

Im going to upload this to the supermarket. if anyone ever wants to take over ownership on the supermarket, email me.

Hi team,

It's possible to test the integration and configuration of Wazuh Installation by using Kitchen for Chef. Kitchen provides a driver-plugin architecture to run cookbooks against different platforms.

This implementation would provide a much easier way to test future changes and updates.

Tasks:

• Design and create tests.
• Run tests against different platforms and verify results.
• Update Readme.md

Best Regards,

Jose

Wazuh version: 3.11.4
Elastic version: 7.6.1

Tasks

• Adapt to new versions (3.11.3 - 7.6.1)

• Check templates and update them if needed

• Tests

• Update changelog

• Tag: v3.11.4_7.6.1

• Draft release

Hi team,

In the Wazuh Agent, the path of rootkit_files and rootkit_trojans is misconfigured.

It should be #{node['ossec']['dir']}/etc/shared/rootkit_files.txt and #{node['ossec']['dir']}/etc/shared/rootkit_trojans.txt respectively.

Tasks

• Reconfigure default agent attributes

• Run installation and check logs for errors

Best regards

Jose

Wazuh version: 3.9.4
Elastic version: 7.2.0

• Adapt to new versions (3.9.4 - 7.2.0)
• Update changelog
• Tests
• Tag: v3.9.4_7.2.0
• Draft release

Whole repository will be refactored in order to follow standard chef-repo structure.

The wazuh cookbooks (Agent, Manager, API) will be split into wazuh_agent (Agent) and wazuh_manager (Manager, API) in order to differentiate roles, attributes, tests, templates and other files.

Tasks:

• Create new folders and restructure.

• Divide Agent and Manager cookbooks.

  • Attributes
  • Recipes
  • Templates
  • Berksfile
  • Metadata

• Adapt default attributes to add v.3.9.0 features

• Adapt Filebeat to v.3.9.0

• Adapt ElasticStack to v.3.9.0

• Rewrite README.md

  • Rewrite Agent README.md
  • Rewrite Manager README.md
  • Rewrite General README.md
  • Rewrite Filebeat README.md
  • Rewrite ElasticStack README.md

Wazuh version: 3.10.2
Elastic version: 7.3.2

• Adapt to new versions (3.10.2 - 7.3.2)
• Update changelog
• Tests
• Tag: v3.10.2_7.3.2
• Draft release

Description

Starting with v3.11 the Wazuh plugin for Kibana has a new behavior when upgrading.

Documented here: wazuh/wazuh-dashboard-plugins#1465

The former config.yml got renamed to wazuh.yml, which brought some internal changes as well, the API settings will no longer be stored in the Elastic index named .wazuh, these settings got migrated to wazuh.yml.

The new behavior is like this:

• The first time booting 3.11 Wazuh plugin detects if there's an .wazuh index and moves it to wazuh.yml, this info gets deleted from Elastic.

• On the following restart cycles there will be no .wazuh index

Proposed workflow

Following a declarative approach we propose to always delete the .wazuh index if exists and write API settings to wazuh.yml. In the case the user updated the password, then the cookbook will override it in both the API and Kibana settings.

Tasks

• Implement required changes to make Chef delete the .wazuh index

• Add required variables to configure the API credentials in the wazuh.yml file

• Create template to render the wazuh.yml file

Tests

The following scenarios should be tested:

• New deployment
• Upgrading from 3.10 to 3.11 (no other changes)
• Upgrading from 3.10 to 3.11 (changing API settings)

When deploying a newer version of Wazuh, there are no checks to verify if an older Wazuh Kibana Plugin exists, this may lead to newer Kibana versions using old plugin versions which leads to the following error:

Dec 31 10:52:38 node-manager-1 kibana[17154]: FATAL  TypeError: Cannot read property 'version' of undefined

Tasks

• Implement required changes to uninstall old Wazuh Kibana Plugin

Tests

• Test Kibana upgrade and verify the plugin is properly removed

• Test Kibana clean installation

Best regards,

Jose

Wazuh version: 3.13.0
Elastic version: 7.7.1

Tasks

• Adapt to new versions (3.13.0 - 7.7.1)

• Update changelog

• Check templates and update them if needed

• Tests

• Tag: v3.13.0_7.7.1

• Update documentation references

• Draft release

Hi all!

The current installation of Wazuh made using wazuh-chef is not a clean-default one. In other words, it does not install a default ossec.conf but a customized one.

For example, when installing wazuh-manager we use parameterized recipes attributes as arguments for the following task:

The same case for wazuh-agent.

As it's parameterized, we set the values for the corresponding variables but we do not take into account the changes made in the default installed ossec.conf as it will always be overwritten.

To Do

• Adapt to the latest installation, the ossec.conf template of:
• • wazuh-manager
• • • RHEL
• • • • Centos7
• • • Debian

• • wazuh-agent
• • • RHEL
• • • • Centos7
• • • Debian

• Verify changes.

• Note: This description may be modified in the future.

Kr,

Rshad

Wazuh version: 3.11.3
Elastic version: 7.5.2

Tasks

• Adapt to new versions (3.11.3 - 7.5.2)

• Check templates and update them if needed

• Tests

• Update changelog

• Tag: v3.11.3_7.5.2

• Generate and publish module on Puppet Forge

• Draft release

In wazhu-api recipe it assumes e=ncrypted databags being used for storing api keys. It will be a neat to give user choice to use chef vault as well.

Wazuh version: 3.11.2
Elastic version: 7.5.1

Tasks

• Adapt to new versions (3.11.2 - 7.5.1)

• Check templates and update them if needed

• Tests

• Update changelog

• Tag: v3.11.2_7.5.1

• Generate and publish module on Puppet Forge

• Draft release

Wazuh version: 3.12.1
Elastic version: 7.6.2

Tasks

• Adapt to new versions (3.12.1 - 7.6.2)

• Update changelog

• Check templates and update them if needed

• Tests

• Tag: v3.12.1_7.6.2

• Draft release

Wazuh version: 3.9.2
Elastic version: 6.8.0

• Adapt to new versions (3.9.2 - 6.8.0)
• Update changelog
• Tests
• Tag: v3.9.2_6.8.0
• Draft release

Wazuh version: 3.9.1
Elastic version: 7.1.0

• Adapt to new versions (3.9.1 - 7.1.0)
• Update changelog
• Tests
• Tag: v3.9.1
• Draft release

This is more just informational for @jm404 since I just stumbled across it myself:
As of chef 12.5.1, you can use verify in the template resource as follows:

include_recipe 'wazuh::manager'

template "#{dir}/etc/shared/default/agent.conf" do
  source 'manager_agent.conf.erb'
  owner 'ossec'
  group 'ossec'
  mode '0644'
  verify '/var/ossec/bin/verify-agent-conf -f %{path}'
end

Hi team,

The current code doesn't allow the user to generate the Agent.conf that is required in a centralized configuration.

Tasks:

• Implement the generation of Agent.conf with Gyoku

• Add configuration of wazuh_command.remote_commands=1 for Wazuh Agent.

• Implement some form of verification of Agent.conf file

• Test changes

• Update README.md