Lab Guide 1
Lab Guide 1
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:
Pre-lab
Student Roster
Linux Managers
Linux Agents
Windows Agents
Elastic Systems
Course goals:
● Enable you to configure and fine-tune Wazuh to meet your own needs
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.
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#)
Lab 1a
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 -
● Restart wazuh-manager
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 .
Lab 1b
The Elastic components are preconfigured for this training. Even the Wazuh Web UI is
pre-installed.
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.
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.
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.
Click on "Add new group" in the upper left hand side and type in your new group name,
then click "Save new 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.
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.
Upon confirmation of successful enrollment, for added security delete the password file.
# rm /var/ossec/etc/agent.pass
# 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'
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:
Install and Register Wazuh 4.1.2 Windows Agent via the MSI package
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.
Check the agent's state file to confirm it is now connected to the manager. You should see
status='connected' in the output.
You should also be able to find your windows-agent listed in the Wazuh web UI and listed as
Active.
Then restart the agent with "systemctl restart wazuh-agent". It should successfully
connect.
From the manager, now confirm all agents are reporting in:
# /var/ossec/bin/agent_control -l
Note that with the introduction of the enrollment feature, the agent-auth tool is now scheduled to be
deprecated in Wazuh 6.x.
Use agent_upgrade to see what agents are eligible for upgrade. Note your ID may differ.
# /var/ossec/bin/agent_upgrade -l
ID Name Version
003 elastic# Wazuh v3.6.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
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.
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
}
# 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
}
# /var/ossec/bin/agent_control -i 003
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.
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.
The "c" parameter above limits the list to presently connected agents. Omit the "c" to show
all registered agents whether connected or not.
# /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 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>
On both linux-agent and elastic, enable centralized sharing of commands via agent.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.
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.
<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>
<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.
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.
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
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.