Objective. Students build and harden the virtualized enterprise environment defined in their architecture plan, configure a SIEM to ingest logs from at least three sources, and deliver a working automation script that detects at least two attack signatures in sample log data.
⚠ Pending professional review
This lesson, its worked examples and its practice questions has not yet been verified by an industry-certified professional or by a certification or approval body. It is a study draft and may contain errors. Do not use it as instructions for work on a job site or on live equipment. Always follow your instructor, your supervising professional, and current official references and regulations.
VoTechWorks program approval and accreditation are still in progress. Credentials are issued only by the certifying bodies named in each program, after their own exams.
Environment Build, Hardening, and Automation
This lab brings together every concept you have studied: network architecture, system hardening, log management, and scripted detection. By the end, you will have a running virtualized enterprise that mirrors a small business network, a SIEM collecting data from multiple sources, and an automation script that catches real attack patterns.
Building the Virtualized Environment
Using VirtualBox (or an equivalent free hypervisor), you will deploy three virtual machines that represent the core of a small enterprise:
Linux server (Ubuntu Server LTS or CentOS Stream) — acts as a file, web, or authentication server.
Windows 10 or 11 endpoint — represents a typical user workstation.
pfSense or OPNsense firewall — controls traffic between network segments.
Configure each VM with at least two network interfaces so the firewall sits between an external (WAN) segment and an internal (LAN) segment. The Linux server and Windows endpoint attach to the LAN. The attacker VM, if used for testing, attaches to the WAN. This segmentation forces all traffic through the firewall, which is the correct architectural principle.
Before you harden anything, snapshot every VM. Snapshots give you a safe rollback point if a configuration change breaks connectivity. Treat each snapshot like a save point — create one before every significant change.
Applying CIS Benchmark Hardening
The Center for Internet Security (CIS) publishes free benchmark documents for Linux and Windows that list specific configuration settings, their default values, and the recommended secure values. You must document every change in a hardening log that records four fields for each control: the setting name, its default value, the value you applied, and the CIS Benchmark control reference number.
Common hardening steps you will apply include:
Linux: disable root SSH login, enforce password complexity via PAM, remove unnecessary services, restrict file permissions on `/etc/passwd` and `/etc/shadow`, enable and configure `ufw` or `firewalld`, and enable auditd logging.
Windows: enable Windows Defender, configure audit policy to log logon events and privilege use, disable the Guest account, set account lockout thresholds, and restrict Remote Desktop access.
Firewall: set a default-deny inbound rule, allow only required ports outbound, and enable logging of blocked packets.
Each of these maps to a numbered CIS control. Recording the control number is not just paperwork — it is the evidence an auditor or certification body uses to confirm compliance.
Configuring the SIEM
A Security Information and Event Management (SIEM) system collects, normalizes, and correlates log data from many sources. You will configure one of the following free options: Splunk Free, Elastic Stack, or Wazuh.
Your SIEM must ingest logs from at least three sources:
1. Syslog from the Linux server
2. Windows Event Log from the Windows endpoint (forwarded via Wazuh agent, Winlogbeat, or Universal Forwarder)
3. Firewall logs from pfSense or OPNsense
Once data flows in, create at least four correlation rules or saved searches targeting these patterns:
Failed authentication brute force (multiple failed logins in a short window)
Port scanning (many connection attempts across different ports from one source IP)
Privilege escalation (Event ID 4672 on Windows; `sudo` or `su` in Linux auth logs)
Outbound connection to a known bad IP (match firewall logs against the provided blocklist)
Test each rule by replaying the instructor-supplied sample log files. A rule that never fires — even against known-bad data — provides no protection.
Writing the Automation Script
Your Python 3 or Bash script must be at least 40 lines of functional code (comments and blank lines do not count). It must:
1. Accept a raw log file as input.
2. Use regular expressions or keyword matching to identify at least two defined attack signatures.
3. Count events per source IP address.
4. Write a formatted plain-text alert report to a specified output file.
Structure your script with clear sections: argument parsing, log reading, pattern matching, counting, and report writing. Use Python's `re` module for regex and `collections.Counter` or a plain dictionary for counting. Always close file handles — use `with open(...)` blocks to prevent resource leaks.
Run your script from the command line before submission and confirm it exits with zero errors. A script that crashes on the test data earns no credit regardless of how well it is written.
Lab Safety and Professional Practices
All attack simulation stays inside the isolated lab network. Never run port scans or exploitation tools against any system outside your hypervisor environment — doing so without written authorization violates the Computer Fraud and Abuse Act and professional ethics codes upheld by CompTIA and ISC2.
Keep credentials used in the lab (even test passwords) out of any code you push to a public repository. Use placeholder variables or environment variables instead. This habit protects you and future employers.
Passing the Lab Check
Your instructor will run a live checklist verification. All three of the following must pass, and your hardening log must document at least ten controls with their CIS reference numbers, to earn the minimum passing score of 80%:
1. The firewall blocks a test scan from the attacker VM.
2. At least four SIEM rules fire correctly against the sample log set.
3. The automation script produces the correct alert report with zero runtime errors.
Key terms8
CIS BenchmarkA free, consensus-based configuration guide published by the Center for Internet Security that lists specific secure settings for operating systems, applications, and network devices, each identified by a control reference number.
SIEM (Security Information and Event Management)A platform that collects, normalizes, and correlates log data from multiple sources to detect security events and generate alerts, providing a unified view of an organization's security posture.
Hardening logA document that records each security configuration change applied to a system, including the setting name, its default value, the applied value, and the reference standard or control number justifying the change.
Correlation ruleA logic expression inside a SIEM that matches patterns across multiple log events — such as many failed logins from one IP within a time window — and triggers an alert when the conditions are met.
Network segmentationThe practice of dividing a network into separate zones (such as WAN and LAN) separated by a firewall or router, so that traffic between zones is controlled and can be inspected or blocked.
Regular expression (regex)A pattern-matching syntax used in scripts and SIEM rules to find specific strings — such as IP addresses or error codes — within text data like log files.
Default-deny policyA firewall or access-control rule set in which all traffic is blocked unless an explicit rule permits it, reducing the attack surface by preventing unexpected or unauthorized connections.
Privilege escalationAn attack or action in which a user or process gains higher permissions than originally assigned, for example a standard user obtaining administrator or root access on a system.
In class: Using VirtualBox or an equivalent free hypervisor, students deploy at minimum a Linux server (Ubuntu Server LTS or CentOS Stream), a Windows 10 or 11 endpoint, and a pfSense or comparable open-source firewall VM; they apply CIS Benchmark hardening steps appropriate to each system, documenting each change in a hardening log that records the setting, its default value, the applied value, and the CIS Benchmark control reference. · Students configure their SIEM instance (Splunk Free, Elastic Stack, or Wazuh) to receive syslog and Windows Event Log data from the Linux server, the Windows endpoint, and the firewall; they create at least four correlation rules or saved searches targeting common attack patterns (failed authentication brute force, port scanning, privilege escalation, and outbound connection to a known bad IP from the provided blocklist) and verify each rule fires correctly against instructor-supplied sample log files. · Students write a Python 3 or Bash script, at least 40 lines of functional code, that parses a provided raw log file, identifies occurrences of two or more defined attack signatures by regular expression or keyword matching, counts events per source IP, and writes a formatted plain-text alert report to a specified output file; the script must execute without errors from the command line on the lab machine. Materials: Lab workstations with virtualization capability, VirtualBox (free), Ubuntu Server LTS ISO, pfSense or OPNsense ISO, Windows evaluation ISO, Splunk Free or Wazuh OVA, Python 3 interpreter, VS Code or nano, CIS Benchmarks for Linux and Windows (free PDF download from CIS), sample log file set provided by instructor, hardening log template Check: Instructor runs a checklist-based live verification: firewall must block a test scan from an attacker VM, at least four SIEM rules must fire correctly against the sample log set, and the automation script must produce the correct alert report with zero runtime errors. All three checks must pass, and the hardening log must document at least ten applied controls with control references, to earn a passing mark of 80% on the lab rubric.
Practice check8
Answer each question, then check it. Nothing is recorded; this is your own practice.
CompTIA Security+: Implementation
1. When building a hardening log, which four pieces of information must be recorded for each CIS Benchmark control you apply?
CompTIA CySA+: Security Operations
2. A student's SIEM brute-force rule is set to alert when more than ten failed logins occur from the same source IP. During testing with the instructor-supplied log file that contains fifteen failed logins from 10.0.0.5, the rule does not fire. What is the most likely cause?
CompTIA CySA+: Threat and Vulnerability Management
3. Which of the following SIEM correlation rules targets privilege escalation activity on a Windows endpoint?
ISC2 CC: Security Principles
4. Why should test passwords and lab credentials never appear as plain text in a script that is pushed to a public code repository?
CompTIA Security+: Operations and Incident Response
5. A student writes a Python script that opens a log file using the pattern `f = open('auth.log', 'r')` and never calls `f.close()`. What is the professional best practice to fix this?
CompTIA Security+: Architecture and Design
6. During live lab verification, the instructor runs a test port scan from the WAN attacker VM toward the student's LAN servers. The firewall must block this scan to pass the check. Which firewall rule configuration achieves this correctly?
CompTIA CySA+: Security Operations
7. A student's automation script is 38 lines long: 20 lines of functional code, 10 comment lines, and 8 blank lines. Does this meet the lab requirement of at least 40 lines of functional code?
ISC2 CC: Security Principles
8. Which ISC2 CC domain is most directly addressed by the requirement that all attack simulation must remain inside the isolated lab network and must not target systems outside the hypervisor environment?
Record this lesson on my transcript.Sign in with your key and enrollment email to record lessons (enroll free if you have no key). This page stays open to read and practise.
A free tech program — complimentary, as our commitment to get America working. Help us build VoTechWorks. Tell us what works, what doesn’t, and what you want to learn.