Wazuh-Elastic Training
Lab-Guide - Session 1
Wazuh 4.1.2
Elastic Stack 7.10.0
OpenDistro 1.12.0
Table of Contents
Preliminary
Course goals:
How this Training Course is organized:
Install and Register
Pre-lab
Student Roster
Linux Managers
Linux Agents
Windows Agents
Elastic Systems
Wazuh Server Configuration
Lab 1a
Check and Prepare Wazuh Server Components
Take first look at the Wazuh Web UI
Lab 1b
Agent Registration and Connection to Manager
Lab 1c - Register linux-agent
Create an agent registration password file
Configure the agent to auto-enroll
The manager notices the newly connected agent
Lab 1d - Install the Wazuh Windows agent using deployment variables
Install and Register Wazuh 4.1.2 Windows Agent via the MSI package
Lab 1e - Register your Elastic agent using agent-auth tool.
Pushing Agent Upgrades
Lab 1f - push Wazuh agent upgrade from manager
Agent push upgrades using the Wazuh API
Centralized Agent Configuration
Meet agent.conf
Procedure for changing the shared agent.conf file and deploying it to agents
Enumerating agents connected to the manager
Lab 1g - deploy agent groups and agent.conf files
Mass Deployment Considerations
Copyright © 2021 Wazuh, Inc. All rights reserved.
1
Preliminary
Course goals:
●
Enable you to configure and fine-tune Wazuh to meet your own needs
●
Present tasks that cover the full spectrum of Wazuh’s capabilities:
■
■
■
■
■
■
■
■
■
■
■
●
Log Analysis with rules and CDB lists
File Integrity Monitoring
Compliance/MITRE mapping
Custom decoder & rule development
Anomaly Detection
Active Response
Security Configuration Assessment
Vulnerability Detection
System Inventory
Cloud and Container security monitoring
Rich third-party integration
Provide numerous and meaningful practice opportunities in the Lab Exercises
How this Training Course is organized:
The Wazuh training lab is divided into six sessions of task-focused activities, lab-based
knowledge checks, and facilitative discussions. Lab-exercises consist of deployment and
tuning of Wazuh rules and decoders, practical use-cases, Wazuh architecture and
processes and open format discussion. Students are expected to be familiar with basic UNIX
administration commands, however no prior Wazuh knowledge is necessary.
Copyright © 2021 Wazuh, Inc. All rights reserved.
2
Install and Register
Copyright © 2021 Wazuh, Inc. All rights reserved.
3
Pre-lab
Confirm you can login via ssh into your manager, linux-agent, and elastic systems. Also
confirm you can RDP into your windows-agent as well as web surf to your elastic system.
Once you can reach them all, we are ready to proceed. Each system's name is followed by
your student number, i.e. "linux-agent3.lab.wazuh.info".
Student Roster
The class roster that was emailed to you assigns you a specific student number associated
with your set of lab systems.
Use your student number everywhere you see a bolded blue # in the lab guides.
Linux Managers
User: wazuh
Password: ChangeMe#
ssh wazuh@manager#.lab.wazuh.info or point Putty at manager#.lab.wazuh.info
Linux Agents
User: wazuh
Password: ChangeMe#
ssh wazuh@linux-agent#.lab.wazuh.info or point Putty at linux-agent#.lab.wazuh.info
Windows Agents
User: wazuh
Password: WindowsPassNumber#
rdp windows-agent#.lab.wazuh.info
Elastic Systems
User: wazuh
Password: ChangeMe#
ssh wazuh@elastic#.lab.wazuh.info or point Putty at elastic#.lab.wazuh.info
https://elastic#.lab.wazuh.info (username wazuh and password ChangeMe#)
Copyright © 2021 Wazuh, Inc. All rights reserved.
4
Wazuh Server Configuration
Lab 1a
Check and Prepare Wazuh Server Components
A "Wazuh Server" consists of the following components.
● Wazuh Manager - main package
● Wazuh API - provides RESTful API access to Wazuh Manager, needed by Web UI
● Filebeat - conveys output from Wazuh Manager to the Elastic Stack system
All of the above is already installed on your manager system, with Wazuh Manager and
Wazuh API having default configurations.
Do the following after logging into your Wazuh manager system via ssh.
●
Make yourself root. Always sudo to root when you ssh into any of your lab machines.
sudo su -
●
Open /var/ossec/etc/ossec.conf using a text editor of your choice, such as vi/vim
or nano. In the <alerts> section change the <log_alert_level> from 3 to 1 using. Also
in the <auth> section, change the <use_password> line from no to yes.
●
Create a corresponding self-registration password file.
echo "secret" > /var/ossec/etc/authd.pass
●
Restart wazuh-manager
systemctl restart wazuh-manager
●
Confirm Wazuh manager processes are running
systemctl status wazuh-manager
Copyright © 2021 Wazuh, Inc. All rights reserved.
5
●
Confirm the Wazuh API is responsive. First login to get an API authentication token
via curl, and use the token in a subsequent curl to make a basic request.
APIUSER="wazuh"
APIPASS="wazuh"
TOKEN=$(curl -sS -u $APIUSER:$APIPASS -k -X GET
"https://localhost:55000/security/user/authenticate?raw=true")
curl -sS -k -X GET "https://localhost:55000/" -H "Authorization: Bearer $TOKEN" | jq .
Copyright © 2021 Wazuh, Inc. All rights reserved.
6
Take first look at the Wazuh Web UI
Lab 1b
The Elastic components are preconfigured for this training. Even the Wazuh Web UI is
pre-installed.
1.
Surf to the following, using your student number instead of #:
https://elastic#.lab.wazuh.info
and login to Kibana for the first time (credentials wazuh:ChangeMe#).
2. If prompted, click 'Dismiss' on the "Help us improve the Elastic Stack…" request.
3. The navigation panel will appear on the left when you click on this button:
These navigation items are mostly for native Kibana components that interact with
Wazuh alerts stored in Elasticsearch but otherwise have no access to Wazuh-specific
dashboards or content accessible only via the Wazuh API.
4. Click the "Wazuh" navigation item to invoke the Wazuh Web UI. This app not only
analyzes and presents Wazuh alerts stored in Elasticsearch, but is also tightly
connected to the Wazuh Manager via the Wazuh API. Through the Wazuh API,
Kibana has rich access to the Wazuh manager, agent configuration, and agent state
as well as has the ability to take a variety of management actions on those systems.
Copyright © 2021 Wazuh, Inc. All rights reserved.
7
5. Various Wazuh-specific dashboards can be reached from here, and the other
components of the Wazuh Web UI are accessible via the Wazuh icon:
6. Take some time to explore Wazuh Web UI now. The "Agents" section will be more
interesting once we have agents registered.
7. Click on the Discover navigation link, then click on wazuh-monitoring-* and switch to
wazuh-alerts-*. Now you will be able to poke around in the indexed data using the
standard facilities of Kibana.
Copyright © 2021 Wazuh, Inc. All rights reserved.
8
8. Next ssh into your Elastic system and run this command to see the Wazuh Web UI
config:
less /usr/share/kibana/data/wazuh/config/wazuh.yml
especially noting the end of the file where the API connection is established.
We will be making plenty of use of Kibana and especially the Wazuh Web UI throughout the
rest of the training, so don't try to explore everything now. There will be more to see once
we have registered some agents.
Agent Registration and Connection to Manager
Lab 1c - Register linux-agent
Create linux and windows agent groups to prepare for agent
registrations.
The Wazuh Web UI allows you to manage agent-group memberships. Use it now to
create agent groups that will be referred to as part of registering your agents.
Access the group management section of the Wazuh Web UI at
Wazuh->Management->Groups and add a "linux" and "windows" group as follows:
Click on "Add new group" in the upper left hand side and type in your new group name,
then click "Save new group":
Copyright © 2021 Wazuh, Inc. All rights reserved.
9
A message will appear in the lower left corner indicating successful addition of the
group and the new group will then appear in the list. This new group will start with a
stub agent.conf file where you can later will add configuration sections specific to this
group.
Alternately, agent groups can be added using cli commands on your wazuh-manager as
follows:
# /var/ossec/bin/agent_groups -a -g linux -q
Group 'linux' created.
# /var/ossec/bin/agent_groups -a -g windows -q
Group 'windows' created.
Register linux-agent with your Wazuh manager using auto enrollment.
Create an agent registration password file
(This must match what is in /var/ossec/etc/authd.pass on the master node manager.)
echo "secret" > /var/ossec/etc/agent.pass
Configure the agent to auto-enroll
In /var/ossec/etc/ossec.conf, change the value of the <address> line from MANAGER_IP to
manager#.lab.wazuh.info. This is where the agent will report in after enrolled.
By default, unregistered agents will attempt to auto-enroll with the manager address
specified above, but we have enabled password authentication for enrollment so we must
also insert the following directly before the </client> line in the same file:
<enrollment>
<manager_address>manager#.lab.wazuh.info</manager_address>
<authorization_pass_path>/var/ossec/etc/agent.pass</authorization_pass_path>
<groups>linux</groups>
</enrollment>
This section not only tells the agent to use the password file, but also tells it to member
itself into the linux agent group. Additionally you can optionally specify here which specific
manager to use for self registration when there is a manager node cluster. Only the master
node manager can serve in this role. With a cluster, this would usually be different from the
load balancer name or IP that you would provide in the <address> line.
Copyright © 2021 Wazuh, Inc. All rights reserved.
10
Restart the agent and confirm success of the enrollment by checking the log:
# systemctl restart wazuh-agent
# grep "Requesting a key" /var/ossec/logs/ossec.log -A 5
"Valid key received" confirms it enrolled successfully..
Upon confirmation of successful enrollment, for added security delete the password file.
# rm /var/ossec/etc/agent.pass
Copyright © 2021 Wazuh, Inc. All rights reserved.
11
Check the agent's state file to confirm it is now connected to the manager.
# cat /var/ossec/var/run/ossec-agentd.state
# State file for ossec-agentd
# Agent status:
# - pending:
waiting to get connected.
# - connected:
connection established with manager in the last 10
seconds.
# - disconnected:connection lost or no ACK received in the last 10 seconds.
status='connected'
# Last time a keepalive was sent
last_keepalive='2019-07-01 01:02:43'
# Last time a control message was received
last_ack='2019-07-01 01:02:43'
# Number of generated events
msg_count='0'
# Number of messages (events + control messages) sent to the manager
msg_sent='5'
If it is not connected, then examine /var/ossec/logs/ossec.log for hints about the problem. In
this log, a successful connection to the manager should be accounted for like this:
2017/01/16 06:18:47 ossec-agent(4102): INFO: Connected to the server
(10.0.N.N:1514).
The manager notices the newly connected agent
Use agent_control to ask the manager about the status of registered agents
[root@manager ~]# /var/ossec/bin/agent_control -l
Wazuh agent_control. List of available agents:
ID: 000, Name: manager# (server), IP: 127.0.0.1, Active/Local
ID: 001, Name: linux-agent#, IP: any, Active
List of agentless devices:
Copyright © 2021 Wazuh, Inc. All rights reserved.
12
Lab 1d - Install the Wazuh Windows agent using
deployment variables
Install and Register Wazuh 4.1.2 Windows Agent via the MSI package
Remote desktop into your Windows lab system.
Open Windows PowerShell as administrator, and use it to download the Wazuh installer file.
cd \
Install-PackageProvider -Name NuGet -Force
# This enables the downloader facility in PowerShell.
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.1.2-1.msi -OutFile
wazuh-agent.msi
First uninstall the agent if already present, and then run the MSI installer, providing it with
deployment variables telling it where to register, what password to use for registration, where to
report in post-registration, and what agent group(s) to be membered into. Not that the msi call
below wraps across multiple lines, so make sure to copy that across as one line.
Uninstall-Package -Name "Wazuh Agent" -erroraction 'silentlycontinue' | out-null
.\wazuh-agent.msi /q ADDRESS="manager#.lab.wazuh.info"
AUTHD_SERVER="manager#.lab.wazuh.info" PASSWORD="secret" GROUP="windows"
Check the agent's state file to confirm it is now connected to the manager. You should see
status='connected' in the output.
type 'C:\Program Files (x86)\ossec-agent\ossec-agent.state'
You should also be able to find your windows-agent listed in the Wazuh web UI and listed as
Active.
Copyright © 2021 Wazuh, Inc. All rights reserved.
13
Lastly, open the Windows File Explorer and go to C:\Program Files (x86)\ossec-agent
Find the win32ui executable and drag a shortcut of it to your desktop.
Rename the shortcut to "Manage Wazuh Agent"
This shortcut will be what you run to start the Windows Wazuh Agent Manager in future labs.
Run it now.
It should look something like this.
Copyright © 2021 Wazuh, Inc. All rights reserved.
14
Lab 1e - Register your Elastic agent using agent-auth
tool.
Configure and register the "elastic" machine with agent-auth
In /var/ossec/etc/ossec.conf, change the value of the <address> line from MANAGER_IP to
manager#.lab.wazuh.info.
Also change <protocol> line from udp to tcp if needed.
At the elastic machine prompt (as root), do self registration as follows:
[root@elastic# ~]# /var/ossec/bin/agent-auth -m manager#.lab.wazuh.info -P secret -G linux
2019/07/01 01:36:18 agent-auth: INFO: Started (pid: 1081).
INFO: Connected to 18.237.55.215:1515
INFO: Using agent name as: elastic#
INFO: Send request to manager. Waiting for reply.
INFO: Received response with agent key
INFO: Valid key created. Finished.
INFO: Connection closed.
Then restart the agent with "systemctl restart wazuh-agent".
connect.
It should successfully
Confirm the connection with "cat /var/ossec/var/run/ossec-agentd.state" just as you did
for linux-agent.
From the manager, now confirm all agents are reporting in:
# /var/ossec/bin/agent_control -l
Wazuh agent_control. List of available agents:
ID: 000, Name: manager# (server), IP: 127.0.0.1, Active/Local
ID: 001, Name: linux-agent#, IP: any, Active
ID: 002, Name: windows-agent#, IP: any, Active
ID: 003, Name: elastic#, IP: any, Active
List of agentless devices:
Note that with the introduction of the enrollment feature, the agent-auth tool is now scheduled to be
deprecated in Wazuh 6.x.
Copyright © 2021 Wazuh, Inc. All rights reserved.
15
Pushing Agent
Upgrades
Copyright © 2021 Wazuh, Inc. All rights reserved.
16
Lab 1f - push Wazuh agent upgrade from manager
Our elastic system is still running that older version of Wazuh Agent. Let's upgrade it now by
pushing an upgrade to it from the manager.
Use agent_upgrade to see what agents are eligible for upgrade. Note your ID may differ.
# /var/ossec/bin/agent_upgrade -l
ID
Name
003
elastic#
Version
Wazuh v3.6.1
Total outdated agents: 1
Then initiate the upgrade process for the linux-agent# and confirm it worked:
# /var/ossec/bin/agent_upgrade -a 003
Sending WPK: [=========================] 100%
Upgrade procedure started... Please wait.
Agent upgraded: Wazuh v3.6.1 -> Wazuh v4.1.2
# /var/ossec/bin/agent_control -i 003
Wazuh agent_control. Agent information:
Agent ID:
003
Agent Name: elastic#
IP address: any/any
Status:
Active
Operating system:
Linux |ip-10-0-2-1.us-west-1.compute.internal
|4.14.114-105.126.amzn2.x86_64 |#1 SMP Tue May 7 02:26:40 UTC 2019 |x86_64 [Amazon
Linux|amzn: 2]
Client version:
Wazuh v4.1.2 / ab73af41699f13fdd81903b5f23d8d00
Shared file hash:
c6309ff81a74781f6b55b68129a76738
Last keep alive:
1615321592
Syscheck last started at: Sun Jul 14 18:35:21 2019
Syscheck last ended at: Sun Jul 14 18:36:25 2019
Rootcheck last started at: Sun Jul 14 18:35:21 2019
This same process works for yum/apt-installed or tarball-installed Linux agents, and for
Windows agents. As long as the agent is connected to the manager, the manager should be
able to push an upgrade to it even if the agent is on a different network than the manager and
behind a NAT/firewall device. This is because the upgrade is pushed across the existing
agent-to-manager connection that is present for a connected agent.
Copyright © 2021 Wazuh, Inc. All rights reserved.
17
Note that if wazuh-agent was originally installed on a Linux system via a package manager like
yum or apt, that the package manager will not be aware of Wazuh push upgrades, and a
subsequent "yum update" or "apt upgrade" on an agent system that was previously the target of
a push upgrade, will upgrade the Wazuh agent again (to the same version already installed). It
is recommended if you plan to use the push method for agent upgrades, that you install Linux
agents with an rpm or dpkg command operating on a downloaded rpm or deb package from
Wazuh, taking the package manager out of the equation. Another advantage of doing this is
that a "yum update" or "apt upgrade" on a Wazuh agent system is less likely to inadvertently
move the wazuh-agent version to one newer than what you have on the manager. It is
important to avoid having Wazuh agents running a higher Wazuh version than that of the
manager to which they connect. Compatibility in that case is not assured.
Agent push upgrades using the Wazuh API
The agent_upgrade CLI tool is not usable with the Wazuh manager cloud SIEM offering nor is it
practical to use with Wazuh manager clusters in general, as the initiation of an agent upgrade
can only be commenced on the specific manager to which a specific agent is connected.
Instead it is advisable to use the Wazuh API to push agent upgrades in a way that automatically
routes the upgrade task to the correct manager for the target agent. Let's try that now.
Downgrade the Wazuh agent on the elastic system executing the following there:
# yum -y downgrade wazuh-agent
Initiate the upgrade as follows. Due to a small bug, this always fails the first time it is used on a new
manager. Just repeat the curl statement and it should work and the problem should not recur thereafter.
# TOKEN=$(curl -sS -u wazuh:wazuh -k -X GET
"https://localhost:55000/security/user/authenticate?raw=true" 2>/dev/null)
# curl -k -X PUT "https://localhost:55000/agents/upgrade?agents_list=003&pretty=true"
-H "Authorization: Bearer $TOKEN"
{
"data": {
"affected_items": [
{
"agent": "003",
"task_id": 2
}
],
"total_affected_items": 1,
"total_failed_items": 0,
"failed_items": []
},
"message": "All upgrade tasks have been created",
"error": 0
}
Copyright © 2021 Wazuh, Inc. All rights reserved.
18
After a minute, check the upgrade job status which should return with a success result
# curl -k -X GET
"https://localhost:55000/agents/upgrade_result?agents_list=003&pretty=true" -H
"Authorization: Bearer $TOKEN"
{
"data": {
"affected_items": [
{
"message": "Success",
"agent": "003",
"task_id": 2,
"node": "master",
"module": "upgrade_module",
"command": "upgrade",
"status": "Updated",
"create_time": "2021/03/09 04:26:07",
"update_time": "2021/03/09 04:27:07"
}
],
"total_affected_items": 1,
"total_failed_items": 0,
"failed_items": []
},
"message": "All agents have been updated",
"error": 0
}
The success can be further demonstrated as follows:
# /var/ossec/bin/agent_control -i 003
Wazuh agent_control. Agent information:
Agent ID:
003
Agent Name: elastic#
IP address: any/any
Status:
Active
Operating system:
Linux |elastic1 |4.14.114-105.126.amzn2.x86_64 |#1 SMP Tue May
7 02:26:40 UTC 2019 |x86_64 [Amazon Linux|amzn: 2]
Client version:
Wazuh v4.1.2 / 5054f50a2592af800328737e7b168787
Shared file hash:
f0350bec1df4ae03c8be995f8dc64722
Last keep alive:
1615321592
Copyright © 2021 Wazuh, Inc. All rights reserved.
19
Syscheck last started at:
Syscheck last ended at:
Wed Dec
Wed Dec
4 03:09:05 2019
4 03:09:53 2019
Rootcheck last started at: Wed Dec
4 03:09:05 2019
At present, agent upgrades cannot be initiated from the Wazuh web interface,, nor is there any
provided method for pushing upgrades to groups of outdated agents. This feature is already under
development and will hopefully appear in a new Wazuh release soon. In the meantime you can
script your own solution to use agent_upgrade or the Wazuh API, to upgrade groups of agents.
Copyright © 2021 Wazuh, Inc. All rights reserved.
20
Centralized Agent
Configuration
Copyright © 2021 Wazuh, Inc. All rights reserved.
21
Meet agent.conf
This file contains agent configuration material that would otherwise be located in agents' local
ossec.conf file. Agents can be membered into one or more agent groups, and each agent
group has its own agent.conf file on the manager that is shared with agents in that group. The
path to a particular agent.conf is as follows, where *GROUP* is the name of the relevant agent
group:
/var/ossec/etc/shared/*GROUP*/agent.conf
Each agent is by default assigned to the "default" agent group, which has agent.conf here:
/var/ossec/etc/shared/default/agent.conf
Agents periodically check with the manager for a new version of this file and pull it down to the
local /var/ossec/etc/shared/ directory if there are changes. Agents automatically restart upon
acquiring a new agent.conf so that changes propagate quickly.
Never edit agent.conf on an agent, as it will be automatically overwritten by agent.conf from the
manager.
When Wazuh agent starts or restarts, it scans its local copy of the agent.conf file(s) and merges
it's own ossec.conf file together with all config sections in the agent.conf file(s) that apply to that
agent.
Watch /var/ossec/logs/ossec.log on an agent for evidence that the intended config sections in
agent.conf actually were applied to that agent. By default, syscheck-monitored directories are
listed in the log, as well as items monitored by logcollector. Many other settings in agent.conf
are not reflected in ossec.log unless debugging is turned up.
Copyright © 2021 Wazuh, Inc. All rights reserved.
22
Procedure for changing the shared agent.conf file and
deploying it to agents
●
●
●
●
●
Edit /var/ossec/etc/shared/*GROUP*/agent.conf on the manager
If you edit this file with the Wazuh Web UI, then it will be validated automatically. If you
edited it from the command line with a text editor, then run
/var/ossec/bin/verify-agent-conf on manager to confirm all agent.conf files are valid.
Invalid agent.conf files are not propagated to agents.
Very shortly after an agent.conf is changed on a manager, if it passes automatic
validation, it will be pushed out to all agents connected to that manager. By default
agents will automatically restart their wazuh-agent service to apply the new version of
agent.conf received.
To see if an agent has acquired the revised agent.conf, consult this file on the agent
which is an ordered concatenation of all agent.conf files belonging to the agent groups to
which the agent is membered.
Why might some agents not have the latest yet? Perhaps they are not connected. Use
"agent -l" and "agent_control -i NNN" on the manager to follow up. Is Status "Active"?
When was "Last keep alive"?
Enumerating agents connected to the manager
[root@manager]# /var/ossec/bin/agent_control -lc
Wazuh HIDS agent_control. List of available agents:
ID: 000, Name: manager# (server), IP: 127.0.0.1, Active/Local
ID: 001, Name: linux-agent#, IP: 10.0.0.20, Active
ID: 002, Name: windows-agent#, IP: 10.0.0.15, Active
ID: 003, Name: elastic#, IP: 10.0.0.15, Active
The "c" parameter above limits the list to presently connected agents. Omit the "c" to show
all registered agents whether connected or not.
Copyright © 2021 Wazuh, Inc. All rights reserved.
23
Lab 1g - deploy agent groups and agent.conf files
You already created a "windows" and "linux" agent group, and during registration your agents
were assigned to the appropriate agent group. In future labs, these agents will be added to
additional new groups as well. For now, confirm the group memberships are as intended via
Wazuh web UI or via these commands on the manager:
# /var/ossec/bin/agent_groups -l -g windows
1 agent(s) in group 'windows':
ID: 002 Name: windows-agent#.
# /var/ossec/bin/agent_groups -l -g linux
2 agent(s) in group 'linux':
ID: 001 Name: linux-agent#.
ID: 003 Name: elastic#.
Now, each agent is positioned to fetch its own agent.conf from the manager according to the
group or groups it is a member of. Our next step is to provide a separate agent.conf on the
Wazuh manager for each agent group so that we can start centrally maintaining the vast
majority of agent configuration details on the Wazuh manager in an organized way.
Replace the entire content of the large /var/ossec/etc/ossec.conf files of each agent with
the following small stub configs, and put back your manager’s name in place of
manager#.lab.wazuh.info.
For linux-agent (/var/ossec/etc/ossec.conf):
<ossec_config>
<client>
<server>
<address>manager#.lab.wazuh.info</address>
</server>
<config-profile>ubuntu, ubuntu16, ubuntu16.04</config-profile>
<auto_restart>yes</auto_restart>
</client>
</ossec_config>
For elastic (/var/ossec/etc/ossec.conf):
Copyright © 2021 Wazuh, Inc. All rights reserved.
24
<ossec_config>
<client>
<server>
<address>manager#.lab.wazuh.info</address>
</server>
<config-profile>redhat, amzl2</config-profile>
<auto_restart>yes</auto_restart>
</client>
</ossec_config>
For windows-agent (via Wazuh Agent Manager -> View -> Config)
<ossec_config>
<client>
<server>
<address>manager#.lab.wazuh.info</address>
</server>
<config-profile>windows2019</config-profile>
<auto_restart>yes</auto_restart>
</client>
</ossec_config>
Configure agents to allow commands to be distributed via agent.conf:
On both linux-agent and elastic, enable centralized sharing of commands via agent.conf
echo "logcollector.remote_commands=1" > /var/ossec/etc/local_internal_options.conf
Copyright © 2021 Wazuh, Inc. All rights reserved.
25
In windows-agent, open Windows PowerShell (Run as Administrator) and run this:
echo "logcollector.remote_commands=1" | out-file -encoding ASCII "C:\Program Files
(x86)\ossec-agent\local_internal_options.conf"
A prepared version of agent.conf for both the windows and linux agent groups has already been
deposited in your manager's /tmp directory. Copy them to their production locations.
[root@manager ~]# cp /var/tmp/linux-agent.conf /var/ossec/etc/shared/linux/agent.conf
cp: overwrite ‘/var/ossec/etc/shared/linux/agent.conf’? y
[root@manager ~]# cp /var/tmp/windows-agent.conf /var/ossec/etc/shared/windows/agent.conf
cp: overwrite ‘/var/ossec/etc/shared/windows/agent.conf’? y
At the head of the final agent_config section in /var/ossec/etc/shared/linux/agent.conf file,
replace the # in "linux-agent#" with your student number:
<agent_config name="linux-agent#">
Confirm that the agent.conf files are valid.
[root@manager ~]# /var/ossec/bin/verify-agent-conf
Restart all of your Wazuh agents at this point.
Notice in the linux agent-group's agent.conf file, that in addition to a large global <agent_config>
section that there are also a couple of profile-specific and one name-specific section.
<!-- config sections for specific agent profiles -->
<agent_config profile="redhat">
<localfile>
<log_format>syslog</log_format>
<location>/var/log/messages</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/secure</location>
</localfile>
</agent_config>
Copyright © 2021 Wazuh, Inc. All rights reserved.
26
<agent_config profile="ubuntu">
<localfile>
<log_format>syslog</log_format>
<location>/var/log/syslog</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/auth.log</location>
</localfile>
</agent_config>
<!-- config section for a specific agent -->
<agent_config name="linux-agent#">
<localfile>
<log_format>syslog</log_format>
<location>/var/log/agent-testing.log</location>
</localfile>
</agent_config>
Examine the ossec.log on both agents for evidence that the relevant agent config
sections were applied to the correct members of the linux agent group.
# egrep "/var/log/(messages|syslog)" /var/ossec/logs/ossec.log
Note that only the agent using the "redhat" config profile (elastic#) is analyzing
/var/log/messages and that only the agent using the "ubuntu" config profile (linux-agent#) is
analyzing /var/log/syslog.
Also notice that only on linux-agent# is the agent-testing.log file being analyzed due to the
name-specific config section in agent.conf.
# grep "agent-testing" /var/ossec/logs/ossec.log
2021/02/20 14:26:33 ossec-logcollector: INFO: (1950): Analyzing file: '/var/log/agent-testing.log'.
Directly via the Wazuh API you can get even deeper visibility into and control over agent groups,
memberships, and files. See:.
https://documentation.wazuh.com/4.1/user-manual/api/reference.html#agents
Copyright © 2021 Wazuh, Inc. All rights reserved.
27
Mass Deployment Considerations
While Wazuh agent mass deployment strategies vary widely from one environment to the
next, the basic steps would be
1. Prepare centralized configuration file content at least involving agent.conf files,
across as many agent groups and/or other kinds of agent config sections, as needed
to manage your quantity and diversity of agents.
2. Prepare a stock ossec.conf and possibly also a stock local_internal_options.conf file
to serve at least as a config template on all agents. Also custom active response
scripts.
3. Get the relevant agent installation package to each system and then invoke it with
the right settings to make it self register as part of the install.
4. Push your stock ossec.conf and possibly local_internal_options.conf file to each
agent, possibly with some dynamic changes if config profiles are to be used,
followed by restarting the Wazuh agent service.
To make the process of mass deploying Wazuh agents even more streamlined, the Wazuh
installation packages for Windows, Redhat/Centos, Debian/Ubuntu, and Mac OSX allow
you to control many aspects of the installation via Windows MSI command parameters and
Linux/OSX environment variables, This includes settings to invoke self-registration as part of
the install without need for a separate call to agent-auth. It also includes settings impacting
how agent ossec.conf files will be configured. Read more here:
●
https://documentation.wazuh.com/4.1/installation-guide/wazuh-agent/deployment_variable
s/deployment_variables.html
If you incorporate the new auto-enrollment feature into your mass deployment strategy, please
weigh the security implications of retaining vs deleting the stored enrollment password file on agents
after enrollment has been performed. A bad actor with your shared enrollment password in hand
could do a number of things with it, including a DoS attack against your registration service though
excessive phony registration requests, a DoS attack by excessive sending of phony logs to the
manager, malicious reconnaissance by spying on the files you distribute to various agent groups, and
overwriting legitimate agent registrations with false ones such that those agents are cut off from the
manager. If you wish agents to retain the ability to re-enroll automatically in the future if needed, then
using name-locked certificate based authentication enrollment on your agents would be safer.
Copyright © 2021 Wazuh, Inc. All rights reserved.
28