Blue Team SIEM Lab

March, 2025

Hmm… the Dark Side, strong it is in young minds, yes. To the Red Team, drawn they are—attack, break, exploit, they wish. But see, the balance they do not. Protect, defend, the ways of the Blue Team, forgotten they have. A path to knowledge, I offer. A SIEM Lab VM, built it I have. Easy to download, simple to use—yes, yes. Learn the ways of the defenders, young ones must. See the full picture, they will. In this article, guide you I shall. The ways of the Blue Side, discover you must. A Jedi of cybersecurity, become you shall!

Stop talking like Yoda, I shall, for the rest of this article.

Knowledge pre-requisites

This lab is intended primarily for cybersecurity students at the end of their first year or during their second year. The lab assumes basic knowledge of Linux (installation, services, iptables, SSH, etc.) and cybersecurity fundamentals, such as types of network scans, firewall operations, brute-force attacks, reverse shells, regexp and SIEM.

However, not having this knowledge is NOT a blocker. You may find it more challenging, but this lab will still help you grow your knowledge in different area. Do not be shy; be bold—but recognize your limits. Stay humble enough to know when it's time to return to books or online resources before continuing.

Technical pre-requisites

This lab was created using VMWare Workstation 16 Player (it's free!). The provided zip file contains all the VMware virtual machines ready to be used directly. If you prefer another virtualization platform (like VirtualBox), you will need to convert the VM images accordingly.

Please adapt the number of CPU and RAM for each machine. Not much should be needed for each machine, it all depends on your patience. The more is usually the best. Note that, once uncompressed, size of each machine is the following:

• Wazuh SIEM: 80Gb (yeah maybe I was a bit too enthusiastic here but you can always change size on your end, real size is less than 30Gb)
• Webserver: 18Gb
• Kali: 9Gb

Download

>>>>>> You can download the whole lab one zip here. (31GB) <<<<<

SHA256: 63E1EC59D69B72ADC7DC6B5550C45D1FFC8650801AFBEEA447D20A887DE3BA0F

In Powershell:

Get-FileHash '.\SIEM_Lab.zip'

What is this lab about ?

This lab provides a minimal but fully functional Wazuh SIEM setup, including a webserver intended to be attacked from a Kali Linux machine. Attacks trigger alerts in Wazuh’s dashboards, offering students hands-on experience with defensive cybersecurity operations (blue teaming—or rather, purple teaming).

I designed this lab as a foundation and inspiration for discovering the defensive side of cybersecurity and the critical functions of a Security Operations Center (SOC). It's aimed at both students and teachers: for teachers to ease preparation and for students to explore and learn practically.

In this lab I have pre-configured the following:

• An Ubuntu 22.04 with Wazuh Manager (SIEM)
• An Ubuntu 22.04 running nginx webserver with Wazuh Agent ready to be attacked
• A Kali Linux with different attack scripts on the desktop

Important: Ubuntu installations are intentionally NOT UPDATED. Please avoid updating until instructed otherwise.

Pre-configured alerts:

The following alerts are configured and visible on the Wazuh dashboards:

• Network port scan
• Network NULL scan
• Network XMAS scan
• Abnormal ICMP ping
• SSH brute-force
• Webserver page scanning
• Reverse shell attack

How does the lab work ?

Wazuh SIEM Machine:

1. Start the Wazuh virtual machine
2. Log in: wazuh / wazuh (Yes, excellent security practice for a cybersecurity lab! 😉)



3. Assign IP address manually: 192.168.74.10 if IP is not set
4. Start Firefox; the default page is the Wazuh SIEM (bookmarked).
5. Credentials are saved in Firefox and stored in a file on the desktop.





6. Go to Dashboards > General Dashboard





7. Get ready, to make it *blink* like a christmas tree!

Webserver Machine:

1. Start the webserver VM
2. Log in : webserver / webserver (it's super safe)²



3. Assign IP address manually: 192.168.74.20 if IP is not set
4. Execute with root script: /home/webserver/firewall_setup.sh (it fill iptables with specific blocking and detection rules)



5. Make sure that the nginx webserver is running (systemctl status nginx)



6. Test local nginx website access using firefox

The Kali machine - Attack and Detection Phase:

1. Start the Kali attacking machine
2. Log in : kali / kali (do what I say, not what I do)
3. Assign IP address manually: 192.168.74.30 if IP is not set
4. Observe on desktop the different attack scripts
5. Run the nmap NULL scan script and observe Wazuh associated dashboard



6. Run the nmap XMAS scan script and observe Wazuh associated dashboard



7. Run the nmap aggressive scanning and observe Wazuh associated dashboard



8. Run the SSH bruteforce attack and observe Wazuh associated dashboard



9. Run the nikto scan attack and observe Wazuh associated dashboard



10. Run the reverse shell listener script and execute the reverse shell binary on the webserver

How is the lab configured?

Having a working lab is good; understanding how it works is even better. That's the exact purpose of this part:

Webserver configuration:

This picture will help you understand how things work on the webserver to monitor firewall rules events detection by the Wazuh Agent:

1. firewall_setup.sh script to automate firewall rule creation for this lab
2. the script define a clear and identifiable log message as that will ease the log parsing and detection later
3. iptables will drop *AND* log the drop event in the OS journal (you can see them by using command: "journalctl -f")
4. these events are isolated by rsyslog into a specific log file
5. Wazuh-agent monitor this file for events and if events appear they will be reported to the SIEM

Concretely, in our case it gives the following:

The script '/home/webserver/firewall_setup.sh' is made to create firewall rules that will generate following message in case of DROP event: [FW-ANTI-....] by iptable.

• [FW-ANTI-NULL-SCAN DROP]: Will trigger when NULL scan packet are received
• [FW-ANTI-XMAS-SCAN DROP]: Will trigger when a XMAS scan is detected
• [FW-ANTI-SCAN DROP]: Will trigger when the most common nmap port are scan detected. In our case it's a webserver and running ssh. So any request attempt outside 22, 80 and 443 are considered suspicious. The number of these events are also a factor to validate threat
• [FW-ANTI-ABNORMAL-PING DROP]: Will trigger if a non-default standard packet size ICMP ping is received.

I know. I don't like these naming tag either. Perfect. It will be a good starting exercice for you to change them.

If these events are detected by rsyslog, then these events are isolated in the following log file: /var/log/iptables.log

Content of the rsyslog file

Finally we need to add monitoring on the file /var/log/ipatables.log into Wazuh-agent. The configuration file to modify is the following: /var/ossec/etc/ossec.conf

Restart rsyslog and Wazuh-Agent services.

Done.

The SIEM: let's ingest our custom firewall config above

Have a look at the following configuration files:

• /var/ossec/ruleset/decoders/0140-kernel_decoders.xml: This configuration is telling to the decoder module (see first image in this article) how to decode and retrieve intereseting information from the firewall log. Make a focus on the custom column I created named "fwfilter" that will contain the above define [FW-ANTI-xxx] tag.


Note that the type is set to syslog and not firewall. This is because currently Wazuh is reworking firewall alerts. Let's see what happens in the future. Here we are interesting in them so I set them as syslog for them to trigger alerts.

• /var/ossec/ruleset/rules/0900-firewall_rules.xml: This file configuration is for triggering alerts and the level of the alerts. Alerts are reported into Wazuh Dashboard, this where you will be able to define filter that will be used for proper detection.

If you add/change/remove rules you MUST restart wazuh-server service or you will have headache for nothing.

Decoder and Rules are setup. Now it's time to have fun with the GUI.

Dashboard time !

Choose one of the attack that triggers firewall events.

Login to Wazuh and go to Discover.

1. Click "Add filter"
2. Type "data.fwfilter" (which is the field we have added above)
3. Select the Operator "is"
4. Select the Value you want

You can also have a look at other parameters like "agent.id", "agent.ip", "data.action" and so on...

Perfect, you are now able to isolate the information you want. You just need to be able to make it a nice dashboard. For this point I would recommend you to simply go to the "Visualize" menu > "FW Null Scan". Review how it's created, the filter behind, the type the Y-axis, the X-axis options.

Now that you have understood how the firewall rules were configured you will have no trouble reversing what I did for the ssh bruteforce and for the reverse shell detection. Look at Wazuh documentation if need me.

Easy Peasy, now you are ready for new adventures.

What's next ?

Imagination is your limit. From now, I recommend you to build more.

You might not be happy with my iptables configuration, great! Change it and the associated message. Go and play with it. I fyou break it. You can always download it again and restart.

Some ideas for you:

• Create a fake website on the configured nginx and attack it with SQL or XSS injection. Develop the associated rules to detect them with Wazuh
• Discover the menu "Security Operations": patch the webserver, harden the OS as much as you can using the PCI DSS, HIPAA, NIST 800-53, CIS controls. Make it as green as possible !
• Add another virtual machine on this lab and enroll a pretty old or completely new Windows server version, attack it, develop detection rules. See how the agents and configuration works on Windows
• Deploy an IDS / IPS on the webserver and use it to detect and report to Wazuh
• Create report of your server for your management
• Why wouldn't you write a python script that exfiltrate data from webserver through ICMP and you would modify iptables rule to detect that ?
• Learn how to manage Wazuh indexes and deal with disk space issue
• Deploy an anti-virus and make it report to Wazuh
• Review the MITRE ATT&CK framework, choose a valid attack, deploy detection and counter measure against it
• Re-create everything from scratch
• ...

Conclusion

I hope you enjoyed this lab and that it made you discover the strength of blue team. Even better I hope it makes you realize the complexity of this part of the force, its own challenges. Now imagine that in a big company with thousands of servers, a growing business, configurations to manages, logs to review, alerts to investigate, false positive to kill, following-up on everyday new vulnerabilities and threats, keeping your rules alive and up to date (writing, testing, deploying), being part of meeting to make sure new projects consider cyber security at the very beginning and not at the end. Close your eyes. Let it sink in your mind. Realize how deep it is and all the possible cyber security roles around it.