wazuh / wazuh-ansible Goto Github PK

View Code? Open in Web Editor NEW

251.0 43.0 166.0 6.56 MB

Wazuh - Ansible playbook

Home Page: https://wazuh.com

License: Other

Python 3.63% Jinja 92.72% Shell 3.65%

wazuh ansible ossec security loganalyzer compliance monitoring intrusion-detection policy-monitoring elasticsearch

wazuh-ansible's Introduction

Wazuh

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

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

Wazuh capabilities

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

Intrusion detection

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

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

Log data analysis

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

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

File integrity monitoring

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

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

Vulnerability detection

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

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

Configuration assessment

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

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

Incident response

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

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

Regulatory compliance

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

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

Cloud security

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

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

Containers security

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

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

WUI

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

Modules overview

Security events

Integrity monitoring

Vulnerability detection

Regulatory compliance

Agents overview

Agent summary

Orchestration

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

Branches

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

Software and libraries used

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

PyPi packages

Documentation

Get involved

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

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

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

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

Authors

Based on the OSSEC project started by Daniel Cid.

wazuh-ansible's People

Contributors

Stargazers

Watchers

Forkers

jlruizmlg gmarziou nemie calciol rtkjbillo angystardust systeminsights colbyprior madonius zama-software maxverro anishmashankar asir214 habbdt paulcalabro luisgi93 lyy289065406 berez23 saez0pub singuliere tleguern perryk vcjp jjediny gsa mapbased nethp0 dipietro-salvatore dleblanc-vidcruiter joelradon chengjz samjaninf dsroark-dt realazizk jheikki100 sareshgit nicholasmhughes rashz joey1a2b3c gary561 limitup sgargel lreddy563 missioncloud freedbka apohadin rulai-jianfang fixed77 francobep humpalu dyydos manicloudguru lunarthegrey nyomo pchristos pescobar a-devops kdauler xiaoruiguo ketsapiwiq antoinethebuilder switchdin amardrbarbar frank3427 mvandermeulen rchenzheng milanpo dineshkumares atassumer dragospe kravietz swipswaps persianyagami90xs 81denton rogeduardo d-malko ggbg rodri9o erindrian jondecamp auasad savobit jovial jakko10 david-drake devops7o consensus-enterprises stackhpc cagezero ddean1984 zaredan huuzlee git-fork pytoshka lavnayagnana soloradish ghaem51 remedioshu jordan-jarvis zyveslah

wazuh-ansible's Issues

adding molecule tests

It would be convenient to have molecule scenarios to verify the roles works as expected. Such scenarios could run on every pull request via Travis CI and reduce the works required from reviewers.

Create configuration templates based on Operating Systems

Hello team,

Referring to the issue #77,

To complement the quick response solution, but doing a more detailed work, we will proceed to create different configuration templates of the agent depending on the operating system in which it is installed to avoid errors monitoring non-existent directories and to avoid losing events by not monitoring files as for example was the case of /var/logs/auth.log.

Therefore, we should identify the main cases like RPM, DEBIAN and WINDOWS (where we install agents via ansible) and create a specific configuration, adapting it if necessary to specific versions. This work will be useful in the future when we share the configurations from the manager using the groups.

Additionally, we should replicate what we do in a simple installation and keep the configuration shared from the empty manager.

Regards,

Alfonso

Move variables found in vars/*.yml files to default/main.yml

Problem: it's not easy to override variables found in vars/*.yml because they have a fairly high precedence. For example, if you use inventory or group vars, a very common practice, you're not able to override these variables. A better place is to use to default/main.yml, which has a lower precedence.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

Playbook Tasks Should Be Idempotent

By this I mean, if you run a playbook twice the first playbook run should bring about the desired state while the second playbook run reports zero changes. This allows for better reporting of things that are actually changing in your environment. Otherwise, it looks like your environment is constantly being updated in reporting consoles. I did a quick scan of the code. I think a few things that would need to be updated are any state checks using execs (you can add params to them so they report correctly based on some test) as well repos (if you pin versions, there's no harm having the repos enabled and not constantly disabled and re-enabled). It's also usually cheaper when tasks are not unnecessarily run every time.

Update changelog

Wrong installation directory for Wazuh agent

Hi team,

The Ansible playbook for deploying a Wazuh agent is not installing it where the documentation currently indicates. According to the official documentation:

By default, all agent files will be found in: C:\Program Files(x86)\ossec-agent.

Instead, it's being installed in the root C:/.

Thanks

How to provide local_rules.xml?

The changelog indicates "allow providing own local_rules.xml template with var ossec_server_… #5 (By pull request: recunius (Thanks!))". But this does not seem to be implemented anywhere. Is this changelog left over from the dj-wasabi version?

- name: Installing the local_rules.xml (default local_rules.xml)
  template: src=var-ossec-rules-local_rules.xml.j2
            dest=/var/ossec/etc/rules/local_rules.xml
            owner=root
            group=ossec
            mode=0640
  notify: restart wazuh-manager
  tags:
    - init
    - config
    - rules

Support all remote connection options.

The existing template only supports a subset of the remote options.

For instance, the syslog connection type should have an allowed_ips option, according to the docs:

It is necessary to list at least one IP address when using the syslog connection type.

Error Ansible wazuh-agen in centos 7

Hello everyone, I have a question, I'm trying to use ansible to install agents, but when I run the scripts I get the following error

error

TASK [ansible-wazuh-agent : RedHat/CentOS 5 | Install Wazuh repo] *********************************
fatal: [192.168.2.207]: FAILED! => {"msg": "The conditional check 'ansible_distribution_major_version|int = 5' failed. The error was: template error while templating string: expected token 'end of statement block', got '='. String: {% if ansible_distribution_major_version|int = 5 %} True {% else %} False {% endif %}\n\nThe error appears to have been in '/etc/ansible/roles/ansible-wazuh-agent/tasks/RedHat.yml': line 12, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: RedHat/CentOS 5 | Install Wazuh repo\n ^ here\n"}
to retry, use: --limit @/etc/ansible/roles/wazuh-agent.retry

PLAY RECAP ****************************************************************************************
192.168.2.200 : ok=0 changed=0 unreachable=1 failed=0
192.168.2.207 : ok=2 changed=0 unreachable=0 failed=1

[root@localhost roles]#

_________my configuration

host file
192.168.2.200 es mi wazuh server
192.168.2.207 es donde quiero instalar agente

This is the default ansible 'hosts' file.

It should live in /etc/ansible/hosts

- Comments begin with the '#' character

- Blank lines are ignored

- Groups of hosts are delimited by [header] elements

- You can enter hostnames or ip addresses

- A hostname/ip can be a member of multiple groups

Ex 1: Ungrouped hosts, specify before any group headers.

192.168.2.200
192.168.2.207

green.example.com

blue.example.com

192.168.100.1

192.168.100.10

Ex 2: A collection of hosts belonging to the 'webservers' group

[webservers]

alpha.example.org

beta.example.org

192.168.1.100

192.168.1.110

wazuh-agent.yml

hosts: all:!wazuh-manager
roles:
- ansible-wazuh-agent
vars:
wazuh_managers:
- address: 192.168.2.200
port: 1514
protocol: udp
api_port: 55000
api_proto: 'http'
api_user: ansible
wazuh_agent_authd:
enable: true
port: 1515
ssl_agent_ca: null
ssl_auto_negotiate: 'no'

Support option to disable active-responses.

The existing template contains a hardcoded <disabled>no</disabled> line. There should be an option to flip this to yes.

Release 3.8.0

Wazuh version: 3.8.0
Elastic version: 6.5.4

Centos7 Wazuh-Agent installation fails to start Wazuh Agent Service ERROR: (1210): Queue

I am trying to use this ansible playbook to install the wazuh-agent on a centos7 minimal virtual machine.

The ansible-playbook gives the following error.

TASK [ansible-wazuh-agent : Linux | Ensure Wazuh Agent service is started and enabled] ***************************************************************************************************************************************
fatal: [wazuh-client01.ipa.home.lab]: FAILED! => {"changed": false, "msg": "Unable to start service wazuh-agent: Job for wazuh-agent.service failed because the control process exited with error code. See \"systemctl status wazuh-agent.service\" and \"journalctl -xe\" for details.\n"}

Feb 10 16:17:37 wazuh-client01.ipa.home.lab systemd[1]: Starting SYSV: Starts and stops Wazuh (Host Intrusion Detection System)...
Feb 10 16:17:37 wazuh-client01.ipa.home.lab wazuh-agent[2229]: Starting Wazuh-agent: 2018/02/10 16:17:37 ossec-agentd: INFO: Using notify time: 10 and max time to reconnect: 60
Feb 10 16:17:40 wazuh-client01.ipa.home.lab wazuh-agent[2229]: 2018/02/10 16:17:40 ossec-syscheckd: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
Feb 10 16:17:40 wazuh-client01.ipa.home.lab wazuh-agent[2229]: 2018/02/10 16:17:40 rootcheck: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
Feb 10 16:17:48 wazuh-client01.ipa.home.lab wazuh-agent[2229]: 2018/02/10 16:17:48 ossec-syscheckd: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
Feb 10 16:17:48 wazuh-client01.ipa.home.lab wazuh-agent[2229]: 2018/02/10 16:17:48 rootcheck: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
Feb 10 16:18:01 wazuh-client01.ipa.home.lab wazuh-agent[2229]: 2018/02/10 16:18:01 ossec-syscheckd: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
Feb 10 16:18:01 wazuh-client01.ipa.home.lab wazuh-agent[2229]: 2018/02/10 16:18:01 rootcheck: CRITICAL: (1211): Unable to access queue: '/var/ossec/queue/ossec/queue'. Giving up..
Feb 10 16:18:01 wazuh-client01.ipa.home.lab wazuh-agent[2229]: [FAILED]
Feb 10 16:18:01 wazuh-client01.ipa.home.lab systemd[1]: wazuh-agent.service: control process exited, code=exited status=1
Feb 10 16:18:01 wazuh-client01.ipa.home.lab systemd[1]: Failed to start SYSV: Starts and stops Wazuh (Host Intrusion Detection System).
Feb 10 16:18:01 wazuh-client01.ipa.home.lab systemd[1]: Unit wazuh-agent.service entered failed state.
Feb 10 16:18:01 wazuh-client01.ipa.home.lab systemd[1]: wazuh-agent.service failed.
Feb 10 17:01:45 wazuh-client01.ipa.home.lab systemd[1]: Starting SYSV: Starts and stops Wazuh (Host Intrusion Detection System)...
Feb 10 17:01:47 wazuh-client01.ipa.home.lab wazuh-agent[2530]: Starting Wazuh-agent: 2018/02/10 17:01:47 ossec-agentd: INFO: Using notify time: 10 and max time to reconnect: 60
Feb 10 17:01:50 wazuh-client01.ipa.home.lab wazuh-agent[2530]: 2018/02/10 17:01:50 ossec-syscheckd: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
Feb 10 17:01:50 wazuh-client01.ipa.home.lab wazuh-agent[2530]: 2018/02/10 17:01:50 rootcheck: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
Feb 10 17:01:58 wazuh-client01.ipa.home.lab wazuh-agent[2530]: 2018/02/10 17:01:58 ossec-syscheckd: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
Feb 10 17:01:58 wazuh-client01.ipa.home.lab wazuh-agent[2530]: 2018/02/10 17:01:58 rootcheck: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
Feb 10 17:02:11 wazuh-client01.ipa.home.lab wazuh-agent[2530]: 2018/02/10 17:02:11 ossec-syscheckd: ERROR: (1210): Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
Feb 10 17:02:11 wazuh-client01.ipa.home.lab wazuh-agent[2530]: 2018/02/10 17:02:11 rootcheck: CRITICAL: (1211): Unable to access queue: '/var/ossec/queue/ossec/queue'. Giving up..
Feb 10 17:02:11 wazuh-client01.ipa.home.lab wazuh-agent[2530]: [FAILED]
Feb 10 17:02:11 wazuh-client01.ipa.home.lab systemd[1]: wazuh-agent.service: control process exited, code=exited status=1
Feb 10 17:02:11 wazuh-client01.ipa.home.lab systemd[1]: Failed to start SYSV: Starts and stops Wazuh (Host Intrusion Detection System).
Feb 10 17:02:11 wazuh-client01.ipa.home.lab systemd[1]: Unit wazuh-agent.service entered failed state.
Feb 10 17:02:11 wazuh-client01.ipa.home.lab systemd[1]: wazuh-agent.service failed.

This is the playbook I am using

- hosts: wazuh-clients
  roles:
    - { role: ansible-wazuh-agent, wazuh_manager_ip: 10.0.5.20, wazuh_register_client: true, wazuh_authd_port: 1515 }

I used the wazuh-elastic_search-single.yml included with this repo.

Wazuh-agent install not working

Set up per https://documentation.wazuh.com/current/deploying-with-ansible/reference.html#wazuh-agent
Agent to be installed on Ubuntu 14.04

Received following error when running ansible-playbook wazuh-agent.yml:

The error appears to have been in '/etc/ansible/roles/ansible-wazuh-agent/tasks/main.yml': line 2, column 3, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

import_tasks: "Windows.yml"
^ here

The error appears to have been in '/etc/ansible/roles/ansible-wazuh-agent/tasks/main.yml': line 2, column 3, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

import_tasks: "Windows.yml"
^ here

Add timeout on yum install

Hello,

On CentOS, I have run into yum install wazuh-agent taking forever because it was waiting for yum.lock held by another process. This was also causing ssh disconnections with ansible yum zombie processes on the host.

I think the role would be more robust by using async and poll:

- name: Linux | Install wazuh-agent
  package: name=wazuh-agent state=latest
  async: 60
  poll: 10
  tags:
    - init

With these settings, when yum does not complete within 60 seconds, the playbook fails as below:

TASK [ansible-wazuh-agent : Linux | Install wazuh-agent] *******************
                                                                            
fatal: [ps-majlnx.example.local]: FAILED! => {                             
    "changed": false                                                        
}                                                                           
                                                                            
MSG:                                                                        
                                                                            
async task did not complete within the requested time

Maybe with a variable for timeout value. I can submit a PR if agreed.

Install agents with ansible, different servers and systems

A question,
can I do an agent installation on solaris machines ?, using ansible

could you guide me in some way to install agents on servers, firewall or systems that do not have an already defined role, using ansible.

Regards
Felipe

RHEL7 $releasever is 7server so, nodejs repos are "broken"

We should fix the ansible RedHat.yml for work with RHEL7

Allow rule exclusions

The existing ossec.conf template hardcodes exclusion of the 0215-policy_rules.xml rules file.

It should be possible to exclude other rules, or to include the above-named rule.

Failed to find required executable systemctl in paths

The role README files state support for Ubuntu, however, they don't state which versions of Ubuntu are supported. That being said, I've come across an issue with Ubuntu 14.04 servers where the following error message occurs:

msg: 'Failed to find required executable systemctl in paths: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin'

This is caused by the following task:

- name: Reload systemd
  systemd: daemon_reload=yes
  ignore_errors: yes
when: not (ansible_distribution == "Amazon" and ansible_distribution_major_version == "NA")

According to this reference:

https://en.wikipedia.org/wiki/Systemd

Systemd wasn't the default service manager until v15.04. You'll probably want to account for that in your conditional logic.

Clean old code.

The line

<directories check_all="yes" realtime="yes" restrict="^C:\wazuh-agent/shared/agent.conf$">C:\wazuh-agent</directories>

is not need it anymore in agents 3.x.

https://github.com/wazuh/wazuh-ansible/blob/master/ansible-wazuh-agent/templates/var-ossec-etc-ossec-agent.conf.j2#L81

logall_json label don't exist

We have notice that the installation of the manager fails because it isn't define logall_json label.

Interval option is no longer available.

Current wazuh code issues a deprecation warning when the cluster.interval option is set:

Detected a deprecated configuration for cluster. Interval option is not longer available.

However, wazuh-ansible code requires cluster.interval and fails with the following error if it is missing:

AnsibleUndefinedVariable: 'dict object' has no attribute 'interval'

At a minimum, the template should be modified to skip the cluster.interval option if it is not defined.

Conflicts of configuration and monitoring of non-existent directories

Hello team,

We are going to proceed with the creation of two issues related to each other.

The problems detected are the following:

Conflict between agent configuration in /var/ossec/etc/ossec.conf and manager pushed configuration in /var/ossec/etc/shared/default/agent.conf.

CONF
- /ansible-wazuh-agent/templates/var-ossec-etc-ossec-agent.conf.j2
  
  https://github.com/wazuh/wazuh-ansible/blob/master/ansible-wazuh-agent/templates/var-ossec-etc-ossec-agent.conf.j2#L94-L99
- /ansible-wazuh-agent/defaults/main.yml
  
  https://github.com/wazuh/wazuh-ansible/blob/master/ansible-wazuh-agent/defaults/main.yml#L49-L53
SHARED
- /ansible-wazuh-manager/templates/var-ossec-etc-shared-agent.conf.j2
  
  https://github.com/wazuh/wazuh-ansible/blob/master/ansible-wazuh-manager/templates/var-ossec-etc-shared-agent.conf.j2#L12-L17
- /ansible-wazuh-manager/defaults/main.yml
  
  https://github.com/wazuh/wazuh-ansible/blob/master/ansible-wazuh-manager/defaults/main.yml#L204-L208
Monitoring of non-existent directories. In operating systems like Ubuntu 16, Ubuntu 18 and other Debian, there are not the following directories to monitor. In CentOS 7 some of they exist.
- location: '/var/log/messages'
- location: '/var/log/secure'
- location: '/var/log/maillog'
- location: '/var/log/httpd/error_log'
- location: '/var/log/httpd/access_log'

The problem is that there are events that we are not collecting, such as those belonging to the /var/logs/auth.log file. Additionally, there are duplicate directories in the shared agent.conf.

As a quick response we need to delete the directories monitored by syscheck duplicates, proceeding to remove the directories from Shared agent.conf.

It is also necessary to remove duplicate localfile entries in the shared configuration, as well as add entries to monitor events such as those stored in /var/logs/auth.log.

Regards,

Alfonso

Packages should be installed concurrently

When installing packages, it's encouraged to provide a list of packages to install, as opposed to iterating over a list one by one. Most modern package managers can install multiple packages concurrently. When you using a loop, you're doing one transaction at a time, consecutively, so it's less performant and it generates warnings such as:

[DEPRECATION WARNING]: Invoking "apt" only once while using a loop via squash_actions is deprecated. Instead of using a loop to supply multiple items and specifying 
`name: {{ item }}`, please use `name: ['apt-transport-https', 'ca-certificates']` and remove the loop. This feature will be removed in version 2.11. Deprecation 
warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Re-register an agent

Hello team,

When we register an agent and then deregister it, Ansible does not have the ability to re-register it due to the conditions of the registration tasks.

check_keys.stat.exists == false or check_keys.stat.size == 0

An option could be to consult the API of Wazuh if it has the agent in question and in case of not having it to enable an additional condition for the tasks of registry.

We can find related information and ideas on how to proceed on this mailing list:

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/wazuh/4-UhadhubEI/z9CLjt0lAQAJ

Regards,

Alfonso

Add support for Amazon Linux

Add support for current playbooks to work with Amazon Linux

Multiple remote connection should be possible

Hello,

If you setup your manager with multiple connection, you have a block like this in ossec.conf :

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.168.1.0/24</allowed-ips>
  <local_ip>192.168.1.5</local_ip>
  <connection>secure</connection>
  <port>1514</port>
  <protocol>udp</protocol>
  <queue_size>16384</queue_size>
</remote>

It can't work.

Exepected configuration :

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.168.1.0/24</allowed-ips>
  <local_ip>192.168.1.5</local_ip>
</remote>

<remote>
  <connection>secure</connection>
  <port>1514</port>
  <protocol>udp</protocol>
  <queue_size>16384</queue_size>
</remote>

change windows agent installer version

Hi,

In the file https://github.com/wazuh/wazuh-ansible/blob/master/roles/wazuh/ansible-wazuh-agent/defaults/main.yml#L20-L25 the version of the wazuh agent installer that is using is obsolete, we have to change it to install the lastest version of the agent in windows.

Regards,
Carlos

Add wazuh-agent /var/ossec/etc/internal_options.conf template

In order to use centralized configuration it would be nice to have a template for the internal_options.conf file.

To use centralized configuration this is a requirement. From the doc:

When setting up remote commands in the shared agent configuration, you must enable remote commands for Agent Modules. This is enabled by adding the following line to the file etc/local_internal_options.conf in the agent:

wazuh_command.remote_commands=1

This would allow to set the logcollector.remote_commands value. With this value set to 1 we could configure the centralized configuration during the installation process.

For additional information see the doc
https://documentation.wazuh.com/3.x/user-manual/reference/internal-options.html?highlight=logcollector%20remote_commands#logcollector
https://documentation.wazuh.com/3.x/user-manual/reference/centralized-configuration.html?highlight=centralized%20configuration

Release 3.9.0

Wazuh version: 3.9.0
Elastic version: 6.7.1

Need Easier Way to Override Select Portions of the Configuration Settings

It would be ideal if the wazuh_manager_config hash was either restructured or the code was modified to allow for easier overriding of smaller chunks of settings:

---
wazuh_manager_config:
  active_responses:
    - command: host-deny
      level: 6
      location: local
      timeout: 600
    - command: restart-ossec
      location: local
      rules_id: '100002'
    - command: win_restart-ossec
      location: local
      rules_id: '100003'
  alerts_log: 'yes'
  api:
    basic_auth: 'yes'
    behind_proxy_server: 'no'
    bind_addr: 0.0.0.0
    ciphers: ''
    drop_privileges: 'true'
    experimental_features: 'false'
    honor_cipher_order: 'true'
    https: 'no'
    https_ca: ''
    https_cert: /var/ossec/etc/sslmanager.cert
    https_key: /var/ossec/etc/sslmanager.key
    https_use_ca: 'no'
    port: 55000
    secure_protocol: TLSv1_2_method
    use_only_authd: 'false'
  authd:
    enable: true
    force_insert: 'yes'
    force_time: 0
    port: 1515
    purge: 'no'
    ssl_agent_ca: null
    ssl_auto_negotiate: 'no'
    ssl_manager_cert: /var/ossec/etc/sslmanager.cert
    ssl_manager_key: /var/ossec/etc/sslmanager.key
    ssl_verify_host: 'no'
    use_password: 'no'
    use_source_ip: 'yes'

...etc. etc. etc.

The reason being is that it's not easy to override individual portions of this config (e.g. cluster settings). It's all or nothing.
In other words, if I want to have most of these variables defined in group_vars/wazuh_managers.yml and override a couple settings using something like host_vars/manager01.yml it's not easily possible w/o modifying the tasks.

Currently, each of my host variables, has a complete copy of this hash in their host variable file with one or two settings changed. Doesn't seem DRY. It would be nice if most of the common settings were in a group variable file and the one or two settings specific to the host were in a host variable file.

Maybe there's a way to leverage the combine filter to allow for easier overrides of portions of the bigger config:

e.g.
{{ {'a':{'foo':1, 'bar':2}, 'b':2} | combine({'a':{'bar':3, 'baz':4}}, recursive=True) }}

Output:
{'a':{'foo':1, 'bar':3, 'baz':4}, 'b':2}

(Source: https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#combining-hashes-dictionaries)

Update Elastic Stack

The version of Wazuh App is outdated. The current version is 3.7 and find 3.6. We should update the files main.yml of each role of Elastic Stack:

wazuh-ansible/roles/elastic-stack/ansible-kibana/defaults/main.yml
wazuh-ansible/roles/elastic-stack/ansible-elasticsearch/defaults/main.yml
wazuh-ansible/roles/elastic-stack/ansible-logstash/defaults/main.yml

Register a single agent with a specific name

Requested by @colbyprior in the following PR: #68.

We should provide a way to register a single agent with a specific name.

Update README.md repository structure

Hello team,

We must adapt to the repository structure shown in README.md due to the new directory and its content:

wazuh-ansible/roles/wazuh/ansible-wazuh-manager/files/custom_ruleset/

https://github.com/wazuh/wazuh-ansible/tree/3.7/roles/wazuh/ansible-wazuh-manager/files/custom_ruleset

Best regards,

Alfonso Ruiz-Bravo

Support all localfile options.

The existing template only supports localfile options log_format, command, frequency and location. It should also support only_future_events, query, label, target, and out_format.

Need the ability to install an agent, but not register it

Sometimes it's necessary to install the Wazuh agent, but not register it with a manager. For example, when working with Amazon Machine Images (AMIs). You want to reduce the time it takes to install the agent by baking the installation into the image, however, you don't want to have duplicate client.keys files by doing registration at the time of image creation. Having the ability to filter these tasks would be useful, perhaps with tags.

Upgrade Wazuh minor version tests

Testing: Upgrade Wazuh minor version

Version	Revision	Branch
3.8.0_6.5.4	3800	3.8.0_6.5.4

Basic tests

Found multiple vulns with Java 8u131

https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19116/version_id-220395/Oracle-JDK-1.8.0.html

Is JDK 8u144 supported?

Installing wazuh manager based on documentation example fails

Hi,

I am following ansible deployment based on documentation and installation of wazuh-manager fails.
It explicitly expects configuration of at least the following:
cis_cat:
disable: 'no'
install_java: 'yes'
openscap:
disable: 'no'

I assume some defaults can be defined.
Then it started failing on email configuration and finally ansible playbook failed on task "Configure ossec.conf".

Provide a means to select the installed version number

There should be a means to select the installed version. For example in ansible-wazuh-manager/agent"latest" is always used.

- name: Install wazuh-manager, wazuh-api and expect
  package: pkg={{ item }} state=latest
  with_items:
    - wazuh-manager
    - wazuh-api
    - expect

Java RPM in elasticsearch RedHat.yml is invalid

Hello,

Just attempted to install this, however was getting an error when trying to install Java, got a 404.

Edited the file:

wazuh-ansible/ansible-role-elasticsearch/tasks/RedHat.yml

Changed the URL to: http://download.oracle.com/otn-pub/java/jdk/8u171-b11/512cd62ec5174c3487ac17c61aaa89e8/jre-8u171-linux-x64.rpm

Then re-ran the playbook, this allowed Java to be installed.

Auth.log not monitorized in managers debian

When we install a manager using Ansible, if the operating systems is Debian based we arent monitoring the file auth.log.

Due this all the alerts of ssh and all are missing.

Syscheck configuration for C:\wazuh-agent consume all 256 Inotify watchers on Windows

Hi,

I am having an issue with one of the templates on Windows. I have not tested if the same thing is happening on Linux.

Issues details

In the var-ossec-etc-ossec-agent.conf the following line is added for Windows machines.
<directories check_all="yes" realtime="yes" restrict="^C:\wazuh-agent/shared/agent.conf$">C:\wazuh-agent</directories>

Having the realtime=yes attribute seems fine but when registering Inotify watchers it ignores the restrict statement. Therefore all 256 Inotify watchers are consumed. 256 seems to be the maximum on Windows. I am not sure what the intended behaviour was here, but I suggest the following modification if the intended behaviour was to provide real-time monitoring for C:\wazuh-agent/shared/agent.conf .

<directories check_all="yes" realtime="yes" restrict="^C:\wazuh-agent/shared/agent.conf$">C:\wazuh-agent/shared</directories>

Logs:

2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../2018041311243011.tox' - Maximum size permitted.
2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../201804131124302.tox' - Maximum size permitted.
2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../201804131124303.tox' - Maximum size permitted.
2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../201804131124304.tox' - Maximum size permitted.
2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../201804131124305.tox' - Maximum size permitted.
2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../201804131124306.tox' - Maximum size permitted.
2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../201804131124307.tox' - Maximum size permitted.
2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../201804131124308.tox' - Maximum size permitted.
2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../201804131124309.tox' - Maximum size permitted.
2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../201804131124311.tox' - Maximum size permitted.
2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../201804131124312.tox' - Maximum size permitted.
2018/07/20 12:00:45 ossec-agent: ERROR: Unable to add directory to real time monitoring: 'C:\wazuh-agent/queue/diff/local/..blankedpath../201804131124313.tox' - Maximum size permitted.

Path to var-ossec-etc-ossec-agent.conf

wazuh-ansible\ansible-wazuh-agent\templates\var-ossec-etc-ossec-agent.conf.j2

The lines causing the issue

    {% if ansible_os_family == "Windows" %}
    <directories check_all="yes" realtime="yes" restrict="^C:\wazuh-agent/shared/agent.conf$">C:\wazuh-agent</directories>
    {% endif %}

    {% if ansible_system == "Linux" %}
    <directories check_all="yes" realtime="yes" restrict="^/var/ossec/etc/shared/agent.conf$">/var/ossec/etc/shared</directories>
    {% endif %}

** Not tested on Linux.

openscap should default to <scan_on_start>no</scan_on_start>

By default openscap is set to scan_on_start. It should be set to no instead because it requires a lot of CPU and RAM and is very likely to cause problems at boot time on production systems, either because the processes timeout or because they run out of memory.

A couple of minor warnings with 3.8

Hi,

I noticed just a couple of minor warnings in the ossec.log file when starting a Manager based upon the defaults when using the 3.8 branch of this and the ansible-wazuh-manager role.

2019/01/20 23:02:56 ossec-analysisd: WARNING: Detected a deprecated configuration for cluster. Interval option is not longer available.
2019/01/20 23:02:56 ossec-remoted: WARNING: Detected a deprecated configuration for cluster. Interval option is not longer available.
2019/01/20 23:02:56 wazuh-modulesd: WARNING: The specific definition of the Red Hat feeds is deprecated. Use only redhat instead.
2019/01/20 23:02:56 ossec-testrule: WARNING: Detected a deprecated configuration for cluster. Interval option is not longer available.
2019/01/20 23:02:56 ossec-authd: WARNING: Detected a deprecated configuration for cluster. Interval option is not longer available.

I can send a PR to resolve this as of my understanding of this if have an alternative fix that is fine too.

Cheers.

Adapt to latest Wazuh

Incorrect Exit Statuses

A new installation of the ansible-wazuh-manager role does not, by default, enable the following daemons:

ossec-maild
wazuh-clusterd

As a result, service wazuh-manager status returns an exit code of 1, which is customarily reserved for failures.

This behavior is caused by the following code, found in /var/ossec/bin/ossec-control :

DAEMONS="wazuh-modulesd ossec-monitord ossec-logcollector ossec-remoted ossec-syscheckd ossec-analysisd ossec-maild ossec-execd wazuh-db ${DB_DAEMON} ${CSYSLOG_DAEMON} ${AGENTLESS_DAEMON} ${INTEGRATOR_DAEMON} ${AUTH_DAEMON

...

if ! is_rhel_le_5
then
    DAEMONS="wazuh-clusterd $DAEMONS"
fi

...

    for i in ${DAEMONS}; do
        if [ $USE_JSON = true ] && [ $first = false ]; then
            echo -n ','
        else
            first=false
        fi
        pstatus ${i};
        if [ $? = 0 ]; then
            if [ $USE_JSON = true ]; then
                echo -n '{"daemon":"'${i}'","status":"stopped"}'
            else
                echo "${i} not running..."
            fi
            RETVAL=1
        else
            if [ $USE_JSON = true ]; then
                echo -n '{"daemon":"'${i}'","status":"running"}'
            else
                echo "${i} is running..."
            fi
        fi
    done

Given that a user might not want clustering nor email email notifications, having those services not enabled is not necessarily indicative of a failure. Having a return code of 1 causes misreporting of playbook executions.

A better test might be: checking the configuration to see if they are configured to be enabled, but are not able to start successfully.

Or, less ideally IMO, configuring a one node cluster with email support by default.

wazuh agent registration must not delegate_to localhost

Context

When the agent registers, the API call to get information about it delegate_to: localhost.

Problem

When the wazuh manager is behind a firewall that does not allow the ansible controller access to the API port 55000, the call will timeout and the registration will fail.

Support multiple Elasticsearch output in ansible-logstash-role

The parameters "elasticsearch_network_host" does not support multiple hosts. It would be nice to support this to benefit from the "LoadBalance" feature of elasticsearch outputs.

The loadbalance option is available for Redis, Logstash, and Elasticsearch outputs. The Kafka output handles load balancing internally.

Please see Logstash documentation:
https://www.elastic.co/guide/en/beats/packetbeat/current/logstash-output.html#loadbalance

Playbooks default configuration

Hello all,
it looks like Wazuh manager and agents configuration is being built using older Wazuh versions tags and behavior assumptions.

We should review how this works and what we want to include as a default configuration, updating it to Wazuh current release.

Regards.

`elasticsearch` and `logstash` roles: condition and parameters to install java

The JRE is being installed automatically by elasticsearch and logstash roles.

Is there a plan to review these two roles to behave like wazuh_agent and wazuh_manager roles as far as java install is concerned? These two roles use the condition wazuh_xxx_config.cis_cat.install_java to install Java and both of them installs the OpenJDK JRE instead of Oracle JRE.

wazuh / wazuh-ansible Goto Github PK

wazuh-ansible's Introduction

Wazuh

Wazuh capabilities

WUI

Orchestration

Branches

Software and libraries used

Documentation

Get involved

Authors

wazuh-ansible's People

Contributors

Stargazers

Watchers

Forkers

wazuh-ansible's Issues

This is the default ansible 'hosts' file.

It should live in /etc/ansible/hosts

- Comments begin with the '#' character

- Blank lines are ignored

- Groups of hosts are delimited by [header] elements

- You can enter hostnames or ip addresses

- A hostname/ip can be a member of multiple groups

Ex 1: Ungrouped hosts, specify before any group headers.

green.example.com

blue.example.com

192.168.100.1

192.168.100.10

Ex 2: A collection of hosts belonging to the 'webservers' group

[webservers]

alpha.example.org

beta.example.org

192.168.1.100

192.168.1.110

Testing: Upgrade Wazuh minor version

Basic tests

Issues details

Path to var-ossec-etc-ossec-agent.conf

The lines causing the issue

Context

Problem

Recommend Projects

Recommend Topics

Recommend Org