Deploy Your SOC with Wazuh

Deploy a Wazuh SIEM on Docker and catch a live brute-force attack.

Introduction

30 Second Summary

Every building has security cameras. Every network needs something similar: a system that watches for suspicious activity and sounds the alarm the moment something goes wrong.

In this project, you will deploy a Security Operations Center for a fictional tribal college inspired by Dine College. You will install a SIEM (Security Information and Event Management system), connect a Linux server to it, and catch your first attacker red-handed.

What You'll Build

You will open your browser, see a dashboard light up with a high-severity alert, and know exactly who tried to break into your college's server, when they did it, and which attack technique they used.

By the end of this project, you'll have:

  • A working Wazuh SIEM stack (manager, indexer, and dashboard) running in Docker containers on your Windows machine, ready to collect security events from any endpoint you connect.
  • A live Ubuntu endpoint representing the Tsaile Campus NOC server, reporting authentication events to your SOC in real-time.
  • A caught brute-force attack visible in your dashboard showing the attacker's IP, the targeted account, the exact timestamp, and the MITRE ATT&CK technique (T1110 Brute Force) mapped automatically.
  • Secret Mission: Write a custom detection rule that alerts when someone attempts to access a fictional student records directory.

Are there any prerequisites?

This project requires Windows 11 with at least 32 GB of RAM, basic comfort with the Linux command line, and an internet connection for downloading Docker images. You should also have prior experience running Docker containers.

This is Project 1 of a 4-part series where you build a complete Security Operations Center from the ground up.

Before We Start

Before any hands-on work begins, let's lock in what you're about to build and why it matters for your growth as a security professional.

Set Up Your SOC Infrastructure

You cannot monitor what you cannot see. Before any detection work happens, you need the infrastructure that collects, indexes, and visualizes security events.

In this step, you will deploy a full Wazuh SIEM stack on your Windows machine using Docker. This gives you a manager to process events, an indexer to store them, and a dashboard to investigate them. Without this foundation, every other blue team skill has nowhere to land.

In this step, get ready to:
  • Enable WSL 2 and verify Docker Desktop is configured with the WSL 2 backend.
  • Clone the Wazuh Docker repository and deploy the full SIEM stack.
  • Access the Wazuh dashboard in your browser and confirm the SOC is online.
Enable WSL 2 and configure Docker Desktop

The Wazuh Docker deployment runs on a Linux kernel. WSL 2 (Windows Subsystem for Linux) provides that kernel on your Windows machine, and Docker Desktop uses it as its backend.

  • Press the Windows key to open your search bar.
  • Type PowerShell, then right-click Windows PowerShell and select Run as administrator.
  • Install WSL 2 by running this command:
wsl --install

✔️ I see help text or a message saying WSL is already installed

WSL 2 is already enabled on your machine. You are ready to move on to the Docker Desktop check below.

ⓧ Installation started

WSL 2 is now being installed along with a default Ubuntu distribution. When the installation completes, restart your computer as prompted.

  • After restarting, open PowerShell as Administrator again and come back to this point.

Seeing a virtualization error?

WSL 2 requires hardware virtualization to be enabled in your BIOS/UEFI settings. Restart your machine, enter BIOS (usually by pressing F2 or Delete during boot), and enable Intel VT-x or AMD-V.

help me enable hardware virtualization for WSL 2

Now verify Docker Desktop is installed and configured with the WSL 2 backend.

  • In the same PowerShell window, check for Docker by running:
docker --version

✔️ I see a version number

Docker Desktop is installed. Now confirm the WSL 2 backend is enabled.

  • Press the Windows key, type Docker Desktop, and press Enter to open it.
  • Click the gear icon (Settings) in the top-right area.
  • Select General in the left sidebar.
  • Confirm Use the WSL 2 based engine is checked. If it is not, check it and click Apply & Restart.

ⓧ Command not found

Docker Desktop is not installed yet.

  • Open your browser and go to the Docker Desktop download page at docker.com/products/docker-desktop.
  • Download the Windows installer and run it.
  • During installation, make sure Use WSL 2 instead of Hyper-V is checked.
  • Once installation finishes, Docker Desktop opens automatically. Sign in or skip if prompted.
  • Verify the WSL 2 backend: click Settings (gear icon), select General, and confirm Use the WSL 2 based engine is checked.

Docker Desktop won't start?

Make sure WSL 2 is fully installed (you completed the step above) and your machine has been restarted since the WSL install.

help me troubleshoot Docker Desktop not starting on Windows 11 with WSL 2

With WSL 2 and Docker Desktop ready, you need to configure one kernel parameter that the Wazuh indexer requires.

  • Open a WSL 2 Ubuntu terminal by pressing the Windows key, typing Ubuntu, and pressing Enter.
  • Set the required vm.max_map_count parameter by running:
sysctl -w vm.max_map_count=262144
  • Make this setting permanent so it survives reboots by running:
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
  • Verify the value is set correctly by running:
sysctl vm.max_map_count

You should see vm.max_map_count = 262144 in the output.

What is vm.max_map_count?

The Wazuh indexer (based on OpenSearch) uses memory-mapped files to store its search indices efficiently. The default Linux limit is too low for the indexer to start. Setting it to 262144 gives the indexer enough virtual memory mappings to operate.

Permission denied?

If you see a permission error on the sysctl -w command, prefix it with sudo. The tee -a command already uses sudo so it should work without issues.

help me fix permission errors when setting vm.max_map_count in WSL 2

Clone and deploy the Wazuh Docker stack

The Wazuh project provides a ready-made Docker Compose configuration that deploys the full SIEM stack in one command. You will clone their repository at a specific version tag to ensure a stable deployment.

  • In your WSL 2 Ubuntu terminal, clone the Wazuh Docker repository at the v4.14.7 tag by running:
git clone https://github.com/wazuh/wazuh-docker.git -b v4.14.7
  • Navigate into the single-node deployment directory by running:
cd wazuh-docker/single-node/

Why single-node?

Wazuh supports multi-node clusters for production environments with thousands of endpoints. For a home lab SOC, single-node gives you the same architecture (manager, indexer, dashboard) without the complexity of clustering. The concepts you learn here transfer directly to production deployments.

Before starting the stack, you need to generate TLS certificates that secure communication between the Wazuh components.

  • Generate the required TLS certificates by running:
docker compose -f generate-indexer-certs.yml run --rm generator

You should see output indicating the certificates were created successfully.

Docker daemon not running?

If you see an error about connecting to the Docker daemon, make sure Docker Desktop is running on your Windows machine. Check your taskbar for the Docker whale icon. If it is not there, open Docker Desktop and wait for it to finish starting.

help me fix Docker daemon connection errors in WSL 2

  • Start the full Wazuh stack by running:
docker compose up -d

What does this deploy?

This command starts three containers that form your complete SOC:

  • wazuh.manager processes and correlates security events from enrolled agents.
  • wazuh.indexer stores and indexes alert data for fast searching.
  • wazuh.dashboard provides the web interface where you investigate alerts.

The containers need approximately 60 to 90 seconds to fully initialize.

  • Wait about 90 seconds, then verify all containers are running:
docker compose ps

You should see all three containers (wazuh.manager, wazuh.indexer, wazuh.dashboard) with a status of "running" or "healthy."

A container shows 'exited' or 'restarting'?

The most common cause is insufficient vm.max_map_count. Run sysctl vm.max_map_count and confirm it returns 262144. If the value is wrong, set it again and restart the stack with docker compose down followed by docker compose up -d.

help me fix Wazuh Docker containers that keep restarting

Access and verify the Wazuh dashboard

Your SOC infrastructure is running. Time to confirm you can reach the dashboard and see the empty SOC waiting for its first endpoint.

Before you open the browser, what do you think you will see on the dashboard given that no endpoints have been connected yet?

  • Open your browser and navigate to https://localhost.
  • You will see a browser warning about the self-signed certificate. Click Advanced, then Proceed to localhost (unsafe) to continue.
  • Log in with username admin and password SecretPassword.
  • Once logged in, click the hamburger menu in the upper left and navigate to Agent management, then Summary.

You should see the agent summary showing 0 total agents. This is your empty SOC, live and waiting for endpoints to protect.

Why 0 agents?

A SIEM only sees what its agents report. Right now, no servers or workstations are enrolled. In the next step, you will connect your first endpoint and watch security events start flowing in.

Cannot reach https://localhost?

Run docker compose ps again in your WSL 2 terminal and confirm the dashboard container is healthy. If it shows "starting," wait another 30 seconds and try again.

Also confirm you are using https (not http). The dashboard only serves traffic over HTTPS.

help me access the Wazuh dashboard at https://localhost

Your SOC infrastructure is live. Next up, you will enroll your first endpoint and watch real security events flow into the dashboard.

Enroll Your First Endpoint

Your SOC is live. You can see the dashboard, the indexer is storing data, and the manager is listening for connections. But right now it is a SIEM with nothing to monitor.

A security platform without endpoints is like a security camera with no lens. In this step, you will connect your first "campus server" to the SOC by installing a Wazuh agent on your WSL 2 Ubuntu instance. Once enrolled, security events will flow from the endpoint to the manager in real-time.

In this step, get ready to:
  • Install the Wazuh agent on your WSL 2 Ubuntu instance and enroll it with the manager.
  • Start the agent service and confirm it is reporting to your SOC dashboard.
Install the Wazuh agent on your WSL 2 Ubuntu instance

The Wazuh agent is a lightweight process that monitors an endpoint for security events and forwards them to the manager. You will install it directly on your WSL 2 Ubuntu instance, which represents the Tsaile Campus NOC server in your fictional college network.

  • Install the prerequisite packages by running this command in your WSL 2 Ubuntu terminal:
sudo apt-get update && sudo apt-get install -y gnupg apt-transport-https

What does this command do?

This installs two packages the Wazuh repository needs. gnupg handles cryptographic signature verification for packages. apt-transport-https allows apt to download packages over HTTPS.

You should see apt download and install both packages, ending with a line like Setting up gnupg....

Seeing 'Unable to locate package'?

Make sure you are in the WSL 2 Ubuntu terminal, not PowerShell or Command Prompt. The apt-get command only works in Linux environments.

If you see network errors, check your internet connection and try running sudo apt-get update on its own first.

help me troubleshoot apt-get errors in WSL 2 Ubuntu

  • Import the Wazuh GPG key so your system trusts packages from the Wazuh repository. Run this command:
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && sudo chmod 644 /usr/share/keyrings/wazuh.gpg

What does this command do?

This downloads Wazuh's public signing key and stores it in a keyring file at /usr/share/keyrings/wazuh.gpg. The chmod 644 ensures apt can read the key when verifying downloaded packages.

  • Confirm the key file was created by running:
ls -la /usr/share/keyrings/wazuh.gpg

You should see the file listed with -rw-r--r-- permissions (644).

  • Add the Wazuh package repository to your system by running:
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee -a /etc/apt/sources.list.d/wazuh.list

What does this command do?

This tells apt where to find Wazuh packages. The signed-by clause links back to the GPG key you just imported, so apt only trusts packages genuinely signed by Wazuh.

  • Confirm the repository file was created by running:
cat /etc/apt/sources.list.d/wazuh.list

You should see the repository line containing packages.wazuh.com/4.x/apt/ printed to your terminal.

  • Install the Wazuh agent and enroll it with your manager in a single command. The manager address is 127.0.0.1 because the Docker container is running on your same machine. Run this:
sudo WAZUH_MANAGER="127.0.0.1" WAZUH_AGENT_NAME="tsaile-noc-srv01" apt-get install wazuh-agent

What does this command do?

The two environment variables tell the agent where to connect (WAZUH_MANAGER) and what to call itself (WAZUH_AGENT_NAME). During installation, the agent automatically registers with the manager using these values.

The name tsaile-noc-srv01 represents the Tsaile Campus Network Operations Center server in your fictional Dine College environment.

You should see apt download and install the wazuh-agent package. The installation output will confirm the agent was configured to connect to 127.0.0.1.

Seeing 'Unable to fetch' or GPG errors?

If apt cannot fetch from the Wazuh repository, verify the repo file is correct by running cat /etc/apt/sources.list.d/wazuh.list and checking it matches the expected URL.

If you see a GPG signature error, re-run the key import command from earlier. The key file at /usr/share/keyrings/wazuh.gpg must exist with 644 permissions.

help me fix Wazuh agent installation errors

Start the agent and verify enrollment

The agent is installed but not yet running. You need to start the service so it begins communicating with the manager and sending security events.

  • Enable and start the Wazuh agent service by running:
sudo systemctl daemon-reload && sudo systemctl enable wazuh-agent && sudo systemctl start wazuh-agent

What does this command do?

This chains three actions together. daemon-reload tells systemd about the new service. enable ensures the agent starts automatically on boot. start launches the agent right now.

  • Verify the agent is running locally by checking its service status:
sudo systemctl status wazuh-agent

You should see active (running) in the output. This confirms the agent process is alive on your endpoint.

Seeing 'inactive' or 'failed'?

If the agent shows inactive or failed status, make sure the Wazuh Docker containers are still running. Switch to the ~/wazuh-docker/single-node/ directory and run docker compose ps to confirm all three containers are healthy.

The agent needs to reach the manager on port 1514. Since both are on localhost, network issues are rare. Try restarting the agent with sudo systemctl restart wazuh-agent.

help me troubleshoot why my Wazuh agent won't start

Now for the real test. The agent says it is running locally, but is the manager actually receiving its data?

  • Before you check the dashboard, predict: do you think the agent will appear immediately, or will there be a delay?
  • Return to the Wazuh dashboard in your browser at https://localhost.
  • Click the hamburger menu in the upper left.
  • Navigate to Agent management, then select Summary.

You should see 1 active agent named tsaile-noc-srv01 with status Active. Your SOC now has eyes on its first endpoint.

What if it takes a moment to appear?

The agent may take 10-30 seconds to fully register after starting. If you see 0 agents, wait a moment and refresh the page. The agent sends a keep-alive signal to the manager, and the dashboard updates once it receives the first heartbeat.

  • Click on the tsaile-noc-srv01 agent name to explore its details. You will see its OS information, last keep-alive time, and agent version.

Your campus server is now reporting to the SOC. Next up, you will put this detection pipeline to the test by simulating a real brute-force attack against your server and watching Wazuh catch it in real-time.

Simulate a Brute-Force Attack

Your endpoint is enrolled and reporting to the SOC. But how do you know the detection pipeline actually works? Right now your dashboard is quiet, and that silence could mean "no threats" or it could mean "threats are happening and you cannot see them."

In this step, you will switch roles and become the attacker. You will launch a simulated SSH brute-force attack against your Tsaile Campus server, then flip back to the defender's chair to see whether Wazuh caught it.

In this step, get ready to:
  • Generate rapid failed SSH login attempts against your monitored endpoint.
  • Observe Wazuh correlate individual failures into a high-severity brute-force alert.
  • Identify the attacker IP, targeted account, and rule IDs in the Security events view.
Generate failed SSH authentication attempts

To simulate a brute-force attack, you need an SSH server running on your endpoint. The Wazuh agent monitors /var/log/auth.log by default, so every failed SSH login attempt gets forwarded to the manager as a security event.

  • Install the SSH server and start the service by running this command in your WSL 2 Ubuntu terminal:
sudo apt-get install -y openssh-server && sudo service ssh start
  • Confirm the SSH service is running:
sudo service ssh status

You should see output indicating that the SSH service is active and running.

SSH service not starting?

WSL 2 does not use systemd by default on older builds. If sudo service ssh start fails, try sudo /etc/init.d/ssh start instead.

help me start the SSH service in WSL 2

Now you will automate the attack. A tool called sshpass lets you send a wrong password to SSH non-interactively, which means you can fire off many failed login attempts in rapid succession without typing a password each time.

  • Install sshpass by running:
sudo apt-get install -y sshpass
  • Launch 10 rapid failed login attempts against the fake user account fakeadmin by running this loop:
for i in $(seq 1 10); do sshpass -p 'wrongpassword' ssh -o StrictHostKeyChecking=no fakeadmin@127.0.0.1; done

What does this command do?

  • for i in $(seq 1 10) repeats the command inside the loop 10 times.
  • sshpass -p 'wrongpassword' feeds a deliberately wrong password to ssh so each attempt fails immediately without prompting you.
  • ssh -o StrictHostKeyChecking=no fakeadmin@127.0.0.1 tries to log in as a non-existent user on the local machine. Each failure writes an authentication event to /var/log/auth.log, which the Wazuh agent monitors and forwards.

You will see 10 "Permission denied" messages scroll past. That is the expected result.

  • Confirm the failed login attempts were logged by running:
sudo tail -5 /var/log/auth.log

You should see lines containing Failed password for invalid user fakeadmin with recent timestamps. These are the raw log entries the Wazuh agent is forwarding to the manager right now.

Not seeing failed login entries?

Make sure the SSH service is running before you run the loop. Run sudo service ssh status and confirm it says active.

If /var/log/auth.log does not exist, try checking /var/log/syslog instead. Some Ubuntu configurations on WSL 2 write authentication events there.

help me troubleshoot missing auth.log entries in WSL 2

Observe the attack in your Wazuh dashboard

The Wazuh agent has been forwarding each authentication failure to the manager in real-time. The manager's rule engine correlates individual low-severity failures into a composite high-severity alert when it detects a brute-force pattern.

Before you look at the dashboard, what do you think you will see? Do you expect 10 separate alerts, or something different?

  • Return to the Wazuh dashboard in your browser at https://localhost.
  • Click the hamburger menu icon in the upper left corner.
  • Navigate to Modules, then select Security events.
  • In the filters area, select the agent tsaile-noc-srv01.
  • Set the time range to Last 15 minutes.

You should see a cluster of alerts appearing. Look for three distinct rule IDs firing in sequence:

  • Rule 5710 - "Attempt to login using a non-existent user." One alert for each failed attempt with the unknown username.
  • Rule 5503 - "PAM: User login failed." The PAM module confirming the authentication rejection.
  • Rule 5763 - "SSHD brute force trying to get access to the system." This is the high-severity alert (level 10) where Wazuh correlated the individual failures into a confirmed brute-force pattern.

Why is rule 5763 the important one?

Rules 5710 and 5503 fire for every individual failure. A single typo when someone logs in would trigger them. Rule 5763 only fires when the manager sees a rapid sequence of failures against the same target.

This is the difference between a SIEM and raw log reading. The SIEM correlates low-severity noise into a high-confidence detection that says "this is an attack, not a mistake."

  • Click on one of the Rule 5763 alerts to expand its details.
  • Note the source IP (127.0.0.1 in your simulation), the targeted username (fakeadmin), and the timestamp.

You have just validated your SOC end-to-end. Events flowed from the endpoint log, through the agent, to the manager's correlation engine, and surfaced as actionable alerts in your dashboard.

Not seeing any alerts in the dashboard?

Wait 60-90 seconds after running the brute-force loop. The agent buffers events before sending them, and the indexer needs time to process.

Make sure the time range is set to Last 15 minutes and the agent filter is set to tsaile-noc-srv01. If you still see nothing, check the agent is running with sudo systemctl status wazuh-agent.

help me troubleshoot why Wazuh alerts are not appearing in the dashboard after my brute-force simulation

Your SOC just caught its first attacker. Next up, you will investigate the alert anatomy and document your detection like a real security engineer would.

Investigate and Document Your First Detection

In the previous step, you simulated a brute-force attack and watched your SOC light up with alerts. Catching the alert is satisfying, but it is only half the job.

A real security engineer must read the alert, understand what happened, determine the scope of the attack, and communicate findings clearly. In this step, you will dissect the anatomy of a brute-force alert and write your first incident documentation.

In this step, get ready to:
  • Examine the anatomy of a brute-force alert and map it to the MITRE ATT&CK framework.
  • Document your first detection with a screenshot and a written incident summary.
Examine the alert anatomy

Each alert in Wazuh contains structured data that tells the full story of what happened. Your job is to read that story and translate it into actionable intelligence.

  • In the Wazuh dashboard, locate one of the Rule 5763 alerts you generated in the previous step.
  • Click on the alert row to expand its details.
  • Click the JSON tab to view the full alert payload.

You should see the complete alert data structured as a JSON object with nested fields.

  • Identify each of the following fields in the expanded alert:
  • rule.id (5763) identifies which detection rule fired.
  • rule.level (10) indicates the severity on Wazuh's 0-15 scale.
  • rule.description tells you what happened in plain language.
  • rule.mitre.id (T1110) maps to the MITRE ATT&CK technique for Brute Force.
  • rule.mitre.tactic (Credential Access) tells you the attacker's goal.
  • data.srcip (127.0.0.1) is the attacker's IP address.
  • data.dstuser (fakeadmin) is the targeted account.
  • timestamp records when the event occurred.

What is the MITRE ATT&CK framework?

MITRE ATT&CK is a public knowledge base of adversary tactics and techniques observed in real-world attacks. T1110 is "Brute Force" under the "Credential Access" tactic.

The Wazuh rule engine correlated multiple individual authentication failure events (each one low severity) into a single high-severity composite alert. This is what a SIEM does that raw log reading cannot: it connects the dots across events.

How does this map to Security+ domains?

In CompTIA Security+ terms, this alert maps to Domain 2.4 (Analyze indicators of malicious activity) and Domain 4.3 (Security operations concepts including monitoring, alerting, and detection).

The CIA triad is also in play here. The attacker targeted the Confidentiality of user credentials through repeated login attempts.

Create your portfolio evidence

Now that you understand what the alert means, you need to capture the evidence and document your findings. This is the difference between someone who saw an alert and someone who investigated a security incident.

  • With the Rule 5763 alert expanded and showing the fields above, take a screenshot of the alert details view.
  • Press Win+Shift+S (Windows) to open the Snipping Tool.
  • Select the area showing the rule ID, severity level, source IP, targeted account, MITRE mapping, and timestamp.
  • Save the screenshot as detection-evidence-bruteforce.png in a location you can find easily.

Capture the full story in one screenshot

Make sure your screenshot includes the rule.id, rule.level, rule.mitre.id, data.srcip, and data.dstuser fields. Scroll the JSON view if needed to fit all key fields into one capture.

Next, you will write a formal detection summary. This is the beginning of your Incident Response documentation.

  • Switch to your WSL 2 Ubuntu terminal.
  • Create your detection summary document by running this command:
cat > ~/detection-summary-001.md << 'EOF'
# Detection Summary - Incident 001

## Date/Time of Detection
[Insert timestamp from the Rule 5763 alert]

## Alert Details
- **Rule ID**: 5763
- **Rule Description**: SSHD brute force trying to get access to the system
- **Severity Level**: 10 (High)

## Attack Details
- **Source IP**: 127.0.0.1
- **Targeted Account(s)**: fakeadmin

## MITRE ATT&CK Mapping
- **Tactic**: Credential Access
- **Technique**: T1110 - Brute Force

## Recommended Next Steps
1. Block the source IP at the firewall
2. Investigate the targeted account for compromise
3. Check other hosts for similar activity from this source IP
EOF

What does this document do?

This is a structured incident summary following common IR documentation practices. It captures the who (source IP), what (brute-force attack), when (timestamp), where (targeted account), and so-what (recommended next steps).

In a real SOC, this document would be attached to a ticket in your incident management system and shared with your team lead. For your portfolio, it proves you can communicate security findings clearly.

  • Open the file to edit in the timestamp by running:
nano ~/detection-summary-001.md
  • Replace [Insert timestamp from the Rule 5763 alert] with the actual timestamp you see in your expanded alert (for example, 2026-07-31T14:23:45.000+0000).
  • Press Ctrl+O to save, then Ctrl+X to exit nano.
  • Verify your document exists and looks correct by running:
cat ~/detection-summary-001.md

You should see your complete detection summary with the timestamp filled in, the rule ID, source IP, targeted account, MITRE mapping, and recommended next steps.

Don't see the file or it looks wrong?

If you get a "No such file or directory" error, the heredoc command may not have completed. Run the full cat > ~/detection-summary-001.md << 'EOF' command again, making sure you copy everything including the closing EOF on its own line.

If the timestamp placeholder is still there, open the file again with nano ~/detection-summary-001.md and replace it with your alert's timestamp value.

Need more help? Ask: Why can't I find my detection-summary-001.md file in WSL 2?

Before you finish, take a moment to articulate what happened in one sentence. Can you explain: who attacked, what they did, and how your SIEM caught it?

Secret mission

Write a Custom Detection Rule

Built-in rules catch common attacks, but Dine College's student records are the crown jewel. Can you write your own detection rule from scratch to protect them? This mission requires editing Wazuh XML configuration files, understanding rule syntax, and working with File Integrity Monitoring. You are operating as a detection engineer now, not just an operator.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally using Docker and WSL 2, so there are no ongoing cloud costs.

Resources you used:

  • Wazuh Docker containers (wazuh.manager, wazuh.indexer, wazuh.dashboard) consuming approximately 4-6 GB RAM total.
  • Wazuh agent service (tsaile-noc-srv01) running on WSL 2 Ubuntu.
  • Cloned repository at ~/wazuh-docker.
  • openssh-server and sshpass packages installed on WSL 2 Ubuntu.

Keep everything running

No action needed. Choose this if you are still actively building or plan to continue to Project 2 soon.

  • Your SOC stays active and continues collecting security logs from the tsaile-noc-srv01 agent.
  • The three Docker containers will keep using approximately 4-6 GB of RAM while running.
  • Your portfolio files (detection-evidence-bruteforce.png and detection-summary-001.md) remain wherever you saved them.

Pause - I'll come back to this later

Shut down running containers to free up RAM while keeping your data intact in Docker volumes.

  • Open your WSL 2 Ubuntu terminal and navigate to the deployment directory by running:
cd ~/wazuh-docker/single-node/
  • Stop all Wazuh containers by running:
docker compose down
  • Stop the Wazuh agent service by running:
sudo systemctl stop wazuh-agent
  • Your data persists in Docker volumes. When you are ready to resume, navigate back to ~/wazuh-docker/single-node/ and run:
docker compose up -d
sudo systemctl start wazuh-agent

Delete - I don't want to use this again

Remove all project resources and start fresh. Save your portfolio files (detection-evidence-bruteforce.png and detection-summary-001.md) somewhere safe before proceeding.

  • Open your WSL 2 Ubuntu terminal and navigate to the deployment directory by running:
cd ~/wazuh-docker/single-node/
  • Stop all containers and delete all stored data (Docker volumes) by running:
docker compose down -v
  • Remove the cloned Wazuh Docker repository by running:
cd ~
rm -rf ~/wazuh-docker
  • Stop and uninstall the Wazuh agent by running:
sudo systemctl stop wazuh-agent
sudo systemctl disable wazuh-agent
sudo apt-get remove --purge wazuh-agent
  • Remove the Wazuh APT repository and GPG key by running:
sudo rm /etc/apt/sources.list.d/wazuh.list
sudo rm /usr/share/keyrings/wazuh.gpg
  • Remove the openssh-server and sshpass packages by running:
sudo apt-get remove --purge openssh-server sshpass
  • Remove the student records directory created during the Secret Mission by running:
sudo rm -rf /var/ossec/data/student-records/

Nice Work!

Nice Work!

You just stood up a fully operational Security Operations Center for Dine College. From an empty Docker host to a live SIEM catching attackers in real-time, you built the detection foundation that every blue team career starts with.

You learned how to:

  • Deploy a production-grade Wazuh SIEM stack (manager, indexer, dashboard) using Docker on Windows/WSL 2 and enroll a Linux endpoint as a monitored agent representing the Tsaile Campus NOC server.
  • Simulate a realistic SSH brute-force attack and watch individual authentication failures escalate into a correlated high-severity alert (rule 5763, level 10).
  • Investigate the alert anatomy end-to-end: rule ID, severity level, MITRE ATT&CK mapping (T1110 Brute Force), source IP, targeted account, and timestamp.
  • Secret Mission: Wrote a custom File Integrity Monitoring rule protecting fictional student records, operating as a detection engineer for your college.

Ready to quiz yourself?