Forem: Evan Dolatowski

Building CloudSentinel: A Multi-Cloud Security Scanner

Evan Dolatowski — Tue, 24 Mar 2026 16:49:34 +0000

Building CloudSentinel: A Multi-Cloud Security Scanner

As a cybersecurity enthusiast and developer, I wanted to build a tool that could deploy vulnerable cloud infrastructure, scan for misconfigurations, and report findings across AWS, Azure, and GCP. The goal was to simulate real-world security risks and demonstrate automation, planning, and multi-cloud proficiency.

This blog post walks through the planning, development, and implementation of CloudSentinel — highlighting how I structured the project, solved problems, and implemented cloud-agnostic scanning.

Project Motivation

Many cloud security tutorials focus on a single provider, and most security tools are either too high-level or not hands-on. I wanted a system that could:

Deploy test infrastructure with intentional vulnerabilities
Scan for misconfigurations automatically
Aggregate findings and calculate risk scores
Work consistently across AWS, Azure, and GCP

The resulting tool, CloudSentinel, achieves all of this with a modular Python CLI and Terraform-backed infrastructure.

Planning & Project Structure

I started with a clear step-by-step plan:

mkdir cloudsentinel
cd cloudsentinel
git init
mkdir terraform scanner cli reports docs
touch README.md .gitignore

Key design decisions:

CLI layer (cli/): handles user commands (deploy, scan, report, destroy, status)
Scanner engine (scanner/): modular checks per cloud provider
Terraform directories (terraform/aws, terraform/azure, terraform/gcp): separate deployments for each cloud
Reports (reports/): structured JSON and CSV outputs

This separation of concerns ensures scalability and maintainability.

AWS Implementation Highlights

I began with AWS to prove the concept:

Terraform deployment:
- EC2 instance with SSH open to the world Security group vulnerabilities
Scanner checks:
- SSH open to 0.0.0.0/0
- Open ports
- Public S3 buckets
- Over-permissive IAM roles
- CloudTrail misconfigurations
- Unencrypted EBS volumes

Example Python scanner module:

def scan_open_ssh():
    result = subprocess.run(
        ["aws", "ec2", "describe-security-groups", "--query", "SecurityGroups[*].IpPermissions", "--output", "json"],
        capture_output=True, text=True
    )
    permissions = json.loads(result.stdout)
    findings = []
    for group in permissions:
        for rule in group:
            if rule.get("FromPort") == 22:
                for ip_range in rule.get("IpRanges", []):
                    if ip_range.get("CidrIp") == "0.0.0.0/0":
                        findings.append({"issue": "SSH open to internet", "severity": "HIGH"})
    return findings

Scanner Engine & Modular Architecture

To handle multiple checks without clutter, I refactored the scanner into a modular engine:

scanner/
├── engine.py       # orchestrator
├── aws_scanner.py
├── azure_scanner.py
├── gcp_scanner.py
└── checks/
    ├── open_ssh.py
    ├── open_ports.py
    └── public_storage.py

The engine runs all checks and aggregates findings:

def run_all_checks():
    findings = []
    findings.extend(run_aws_checks())
    findings.extend(run_azure_checks())
    findings.extend(run_gcp_checks())
    return findings

This design allows scalable expansion to new checks or cloud providers.

Azure Integration

Azure required service principal authentication:

az login --service-principal -u <appId> -p <password> --tenant <tenantId>

Terraform resources included:

Resource Group
Virtual Network and Subnet
Vulnerable Network Security Group (open to all inbound traffic)
Storage Account with public blob access

Scanner modules for Azure:

nsg_open_ssh.py → detects insecure NSG rules
public_storage.py → detects public blobs

Status and report functions were updated to include Azure:

[CloudSentinel] Checking Azure resources...
Resource Groups:    1
Virtual Machines:   0
Network Security Groups: 1
Storage Accounts:   1
Cloud Environment Status: RESOURCES REMAIN ⚠️

Scan results:

[AWS] SSH open to internet (HIGH)
[AZURE] Public blob access enabled (HIGH)
Risk Score (0-10): 6.0
Overall Risk Level: MEDIUM

GCP Integration

For GCP, I used a service account with Terraform:

gcloud iam service-accounts create cloudsentinel-sa
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
    --member="serviceAccount:cloudsentinel-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/editor"
gcloud iam service-accounts keys create ~/cloudsentinel-sa.json \
    --iam-account cloudsentinel-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com

Terraform resources included:

Compute Engine VM with public SSH
GCS bucket with public access
Firewall rules for open ports

Scanner checks mirrored AWS/Azure:

def run_gcp_checks():
    # Check VMs, Storage, and Networks
    ...

CLI fully supports deploy, scan, report, destroy, status for GCP just like AWS and Azure.

Reporting & Risk Scoring

CloudSentinel generates structured JSON and CSV reports, including:

Vulnerability list per cloud
Severity counts (CRITICAL, HIGH, MEDIUM, LOW)
Normalized risk score (0–10)
Summary for SOC analysts or auditors

Example summary output:

--- Security Summary ---
CRITICAL: 1
HIGH:     3
MEDIUM:   2
LOW:      0
Risk Score (0-10): 7.33

Lessons Learned

Terraform differs slightly across cloud providers; planning is critical
Modular scanner architecture enables scalable vulnerability detection
Automation with Python CLI unifies multi-cloud operations
Validating destroy operations prevents unintended cloud costs
Structured reporting mirrors real-world SOC workflows

Next Steps

Expand scanner checks for Azure and GCP
Integrate with SIEM tools like Splunk
Build a web dashboard for vulnerability visualization
CI/CD pipeline to automate scans and reports

Conclusion

CloudSentinel demonstrates the full lifecycle of cloud security testing:

Multi-cloud deployment with Terraform
Automated scanning with modular Python
Risk scoring and structured reporting
Cleanup and status verification

This project showcases problem-solving, planning, and hands-on cloud security skills, ready to impress potential employers and security teams.

Check out the project on GitHub: CloudSentinel Git Repo

Building a Virtualized Cybersecurity Lab: Introducing an Adversary with Kali Linux

Evan Dolatowski — Mon, 15 Dec 2025 01:12:37 +0000

This is the Fourth blog post in a series about building my Virtual home lab network as a Cybersecurity Student.

Originally, I planned to integrate a physical Kali Linux system via VPN. After encountering unnecessary operational complexity, I pivoted to deploying a Kali Linux virtual machine directly inside the lab-LAN. This approach improves reproducibility, safety, and visibility while still supporting realistic attack simulation.

This design choice also reflects many real-world incidents, where adversarial activity originates from inside a trusted or semi-trusted network rather than directly from the public internet.

Lab Architecture Reminder

As a recap, this virtualized cybersecurity lab consists of:

pfSense firewall acting as router, DHCP server, and DNS forwarder
Lab-NAT and Lab-LAN virtual networks
Windows Server 2022 (Active Directory Domain Controller)
Windows 11 domain-joined workstation
Ubuntu Desktop (Splunk SIEM)
Ubuntu Server (infrastructure services)
Kali Linux attack VM (internal adversary) At this stage, the environment mirrors a small enterprise network with centralized identity, logging, and segmented routing.

Process Overview

Introducing Kali as an Internal Adversary

The goal of this step is to deploy a controlled attack system that lives entirely inside the lab-LAN and can generate observable activity without exposing the host system or external networks.

Step 1 — Creating the Kali Linux VM

The Kali Linux VM is deployed using the same virt-install and Virt-Manager workflow used throughout the lab:

sudo virt-install \
  --name kali \
  --ram 4096 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/kali.qcow2,size=20,format=qcow2 \
  --cdrom /var/lib/libvirt/boot/kali-linux.iso \
  --network network=lab-lan,model=virtio \
  --os-variant ubuntu22.04 \
  --graphics spice \
  --boot uefi

Notes:

The Kali VM is connected only to the lab-LAN, keeping it isolated from the host and internet.
A static IP is recommended to ensure repeatable attack simulations and predictable logging.

Step 2 — Configure a Static IP (Optional but Recommended)

Manually assigning a static IP simplifies Splunk searches and detection logic.

Step 3 — Integrating Kali with Splunk

With centralized logging already in place, the next step is to ensure activity generated from Kali is observable.

sudo apt install rsyslog
echo '*.* @10.0.0.52:514' | sudo tee /etc/rsyslog.d/60-splunk.conf
sudo systemctl restart rsyslog

Logs are forwarded using UDP syslog to remain consistent with the existing Ubuntu and pfSense log ingestion pipeline.

In a production environment, forwarding logs from an attack system would be carefully scoped. In this lab, full visibility is intentional to support learning and detection validation.

This ensures that authentication attempts, network activity, and simulated attacks from Kali appear in the SIEM alongside logs from Windows, Linux, and pfSense.

Validating Network Connectivity and Routing

A. Full Network Discovery from Kali

From the Kali VM:

ip a
ip route
nmap -sn 10.0.0.0/24

What this proves:

Kali is correctly attached to the lab-LAN
pfSense is routing traffic as designed
All domain members are reachable

📸 Screenshot: Nmap host discovery showing pfSense, DC, Windows 11, and Splunk

SOC Lens:
Internal host discovery is a common reconnaissance technique and often triggers investigation due to unusual scanning behavior.

Tie-in to Part 1:
This validates the segmentation and routing configured in the pfSense-based network.

B. Controlled Port Scanning

nmap -sS -p 1-1024 10.0.0.25

Immediately after, search in Splunk:

index=* host=winserver*

This query confirms that scan activity from Kali is generating security-relevant events on the Windows host and that those events are centrally searchable.

What this proves:

Attack traffic is successfully generated
Host firewall behavior is visible
Telemetry is ingested centrally

Tie-in to Part 3:
This confirms that network activity appears in Splunk in near real time.

Observing Identity and Authentication Activity

A. Kerberos Authentication Validation

kinit administrator@LAB.LOCAL
klist

What this proves:

Active Directory is functional
DNS, Kerberos, and time synchronization are working
Cross-platform Linux and Windows identity integration is functioning as expected

In Splunk, search for:

Event ID 4768 (Kerberos TGT request)
Event ID 4624 (successful logon)

Tie-in to Part 2:
Identity remains the primary control plane of the environment.

DNS and Name Resolution Validation

nslookup lab.local
nslookup winserver.lab.local
nslookup google.com

What this proves:

Internal DNS resolution via Active Directory
Name-based attack paths are observable

In Splunk:

Review DNS query logs from the Domain Controller

Tie-in to Parts 2 & 3:
DNS underpins authentication, monitoring, and attack visibility.

Generating Detectable Attack Traffic

Visibility and Detection Validation

nmap -A 10.0.0.0/24

In Splunk:

index=* sourcetype=sysmon EventCode=3

Observed:

Network connections
Process names
Source IP = Kali VM

This confirms the environment is not just functional — it is observable.

Key Takeaways / Lessons Learned

Introducing a Kali Linux attack VM completes the lab by adding an adversarial perspective to an enterprise-style environment
Internal adversaries are often more realistic than external attackers
Identity-based telemetry produces the strongest detection signals
Visibility validates architecture, not just configuration
Meaningful detections do not require exploitation
Correlation across data sources enables true investigation

Next Steps / Learning Opportunities

With networking, identity, visibility, and adversarial simulation in place, future work will focus on detection quality and response workflows.
Planned next steps include:
Building targeted Splunk detections for reconnaissance and authentication abuse
Mapping observed activity to MITRE ATT&CK techniques
Establishing behavioral baselines
Implementing Windows Event Forwarding (WEF)
Expanding pfSense monitoring and alerting
Evaluating alternative SIEM platforms such as Wazuh

Why This Lab Matters

This project demonstrates how networking, identity, logging, and adversarial behavior intersect in real environments. Rather than focusing on exploitation, the lab emphasizes understanding how attacks are detected, investigated, and correlated when proper visibility exists.

The goal is not exploitation — it is comprehension.

Building a Virtualized Cybersecurity Lab: Splunk SIEM Setup and Log Forwarding

Evan Dolatowski — Sat, 13 Dec 2025 03:20:59 +0000

In this third part of my virtualized cybersecurity lab series, I move beyond infrastructure and identity to focus on visibility—installing Splunk, configuring log forwarding, and building the monitoring layer required for SOC-style analysis and detection.

A Need For Robust Logs

With my Active Directory environment fully deployed and all client systems joined to the domain, the next logical step in my homelab journey is establishing visibility. Identity services create the foundation of authentication and access, but without centralized logging, it’s impossible to understand how the environment behaves, detect unusual activity, or analyze the impact of simulated attacks. That’s where a SIEM comes in.

In this third post of the series, I focus on installing and configuring Splunk as my primary SIEM platform, then enabling log forwarding from my Ubuntu Desktop, Windows 11, and Windows Server 2025 VM. My goal is to build a realistic monitoring stack that mirrors what security teams rely on in production environments—capturing authentication logs, system activity, and security-relevant events in one place.

As with all parts of this homelab, I want a system I can continuously modify and learn from. Splunk gives me an excellent starting point for understanding enterprise log ingestion, parsing, and detection logic. In future iterations, I may migrate this VM to Wazuh or run a separate Wazuh deployment alongside Splunk so I can compare SIEM platforms and expand my defensive skill set.

This post represents the beginning of the “visibility” phase of the project—turning raw system activity into actionable insights.

Lab Architecture Reminder

Before diving into configuration, here’s the high-level lab design as of this stage in the project.

Current environment includes:
pfSense (router/firewall)
lab-LAN internal network
Windows Server 2022 (Domain Controller + DNS)
Windows 11 endpoint
Ubuntu Desktop endpoint
With networking complete, the identity layer sits on top of this controlled environment.

Process Overview

For readers who want insight into how I approached the build, I’ve included an overview of the major configuration steps I performed. Readers don't have to read every detail, this is more a summary of the important actions supported by screenshots to document the process.

Step 1 - Installing Splunk on Ubuntu

Install Splunk on the VM:

Example for Ubuntu

sudo dpkg -i splunk-9.0.x-linux-x64.deb
sudo /opt/splunk/bin/splunk start --accept-license
sudo /opt/splunk/bin/splunk enable boot-start

Screenshot below I am using the above commands

Access Splunk WebGUI:
Go to https://Splunk_VM_IP:8000
Default admin login: admin / password you set

Screenshot after logging in

Step 2 - Configure Inputs/Listeners in Splunk

Universal Forwarder Input (for Windows & Linux agents):
Go to Settings → Data Inputs → Forwarded Data / UDP / TCP
Set up:
UDP 514 (for Syslog) for Linux and pfSense
TCP 9997 (default for Splunk forwarders)
Enable receiving logs:

sudo /opt/splunk/bin/splunk enable listen 9997

Below you will see a screenshot of the ports being listened to

Logs we plan to collect

Security logs
Sysmon operational logs
Authentication events
DNS logs (from DC)
Linux auth logs
pfSense firewall logs

Step 3 — Forward Windows Logs

Install Splunk Universal Forwarder on Windows 11 & Server
Download the Universal Forwarder from Splunk website

Install on both Windows VMs
Configure Forwarder to send logs to Splunk server:

Example configuration

c:\Program Files\SplunkUniversalForwarder\bin\splunk add forward-server [Splunk_IP]:9997
c:\Program Files\SplunkUniversalForwarder\bin\splunk add monitor "C:\Windows\System32\winevt\Logs\Security.evtx"
c:\Program Files\SplunkUniversalForwarder\bin\splunk add monitor "C:\Windows\System32\winevt\Logs\System.evtx"
c:\Program Files\SplunkUniversalForwarder\bin\splunk start

Below I am listing the forward server and testing the connection to the Ubuntu Server IP

For richer telemetry, I also installed Sysmon using the SwiftOnSecurity configuration.

Step 4 — Forward Linux Logs

On Ubuntu VMs:
Install rsyslog

sudo apt install rsyslog

Configure rsyslog to forward logs to Splunk:

sudo vim /etc/rsyslog.d/60-splunk.conf

Add:
. @@[Splunk_IP]:514
Restart rsyslog:

sudo systemctl restart rsyslog

This is the content after editing the file

Step 5 — Forward pfSense Logs

Log into pfSense WebGUI
Go to Status → System Logs → Settings
Under Remote Syslog Servers, add the Splunk IP and UDP 514
Select all log types we want forwarded

pfSense sends logs in BSD-style syslog format, which Splunk parses differently than Linux logs.

Step 6 — Verify Logs in Splunk

Go to Splunk Web → Search & Reporting
Search for logs:

index=* | stats count by host, sourcetype

we see entries from Ubuntu Desktop, Windows 11, Server 2022, and pfSense in that order

Key Takeaways / Lessons Learned

Implementing Splunk and configuring log forwarding across every layer of the lab marked a major shift from building infrastructure to actively observing and understanding it. Once identity and authentication services were in place, centralized logging quickly became the backbone of the environment. Working through Splunk Forwarders, Sysmon, rsyslog, and pfSense log forwarding reinforced how critical consistent telemetry, accurate timestamps, and structured data inputs are for effective security monitoring. This phase made it clear that visibility is what transforms a functional network into a defensible one.

Visibility starts with identity. Once AD was deployed, it became clear how critical centralized logging is for understanding authentication patterns, user behavior, and privilege boundaries.
Forwarders require careful planning. Splunk Universal Forwarders, Sysmon, and rsyslog each have unique configuration requirements, reinforcing the importance of consistency in log transport and timestamping.
Telemetry sources differ widely. Windows event logs, Sysmon telemetry, Linux auth logs, and pfSense firewall logs each reveal different layers of system and network activity.
Search, filtering, and verification matter. Using Splunk queries like index=* stats count by host or looking for EventCode 4624/4625 helped validate that ingestion was functioning end-to-end.
This stage transforms the lab into a real defensive environment. With logs centralizing into Splunk, the environment has the foundational visibility needed for detection engineering, threat simulation, and SOC-style analysis.

Next Steps / Learning Opportunities

With centralized logging now in place, the lab has reached a point where activity can be observed, recorded, and reviewed across every major system. Rather than immediately expanding detection logic, the next step is to introduce a realistic source of adversarial behavior so that this telemetry has meaningful context.

In the next blog post, I will deploy a Kali Linux virtual machine inside the lab-LAN to act as a controlled attacking system.
This allows attack traffic to be generated safely within the environment while maintaining full visibility across the network, identity, and logging layers. This step completes the foundational loop of the environment: networking, identity, visibility, and now an adversarial perspective to validate the logging and monitoring already in place.

Building a Virtualized Cybersecurity Lab: Active Directory and DNS Integration

Evan Dolatowski — Fri, 12 Dec 2025 01:34:16 +0000

This is the Third blog post in a series about building my Virtual home lab network as a Cybersecurity Student.

Why Identity Services Matter

After establishing the core networking and firewall layer of my homelab, the next major step was to build the identity foundation that real-world organizations rely on: Active Directory. Windows Server 2022 provides me a fully functional domain environment with integrated DNS, centralized authentication, and the ability to manage devices across the network.

This stage was especially important for me because, although I’m comfortable in Linux and the CLI thanks to my development background, I’ve always wanted to deepen my Windows administration and PowerShell skills. Studying for CompTIA A+, Network+, and Security+ made me aware of how heavily enterprises depend on Active Directory, but building it myself inside a real network pushes that knowledge much further. Completing this part of the homelab means I now have the identity infrastructure needed for future projects in security monitoring, detection engineering, and attack simulation.

Lab Architecture Reminder

Before diving into configuration, here’s the high-level lab design as of this stage in the project.
Current environment includes:
pfSense (router/firewall)
lab-LAN internal network
Windows Server 2022 (Domain Controller + DNS)
Windows 11 endpoint
Ubuntu Desktop endpoint
Kali Linux Attack VM (lab-LAN)
With networking complete, the identity layer sits on top of this controlled environment.

Process Overview

Section 1 - Installing Windows Server 2022

Windows Server 2022 required a bit more work due to Secure Boot and TPM expectations. I eventually switched from virt-install to Virt-Manager for easier overrides, but here’s the CLI version I used first:

sudo virt-install \
  --name winserver2022 \
  --ram 8192 \
  --vcpus 4 \
  --disk path=/var/lib/libvirt/images/winserver2022.qcow2,format=qcow2,bus=virtio \
  --cdrom /var/lib/libvirt/boot/WindowsServer2022.iso \
  --network network=lab-lan,model=virtio \
  --os-variant win2k22 \
  --graphics spice \
  --boot uefi

Make sure to attach the VirtIO driver ISO, because Windows will need these drivers to detect storage and network devices during installation.
I also needed to create a LabConfig directory with some Booleans in order to override TPM and Secure boot.

Assigning a Static IP (Required for AD)
Active Directory must run on a server with:
A static IP
DNS pointing to itself
A consistent hostname
Inside Windows Server:
Set IP: 10.0.0.25
Subnet: 255.255.255.0
Gateway: 10.0.0.1 (pfSense)
DNS: 10.0.0.25 (itself)
This is mandatory because AD DNS integrates tightly with the domain.

Section 2 - Promoting the Server to a Domain Controller

Install AD DS
In Server Manager:
Manage → Add Roles and Features
Select Active Directory Domain Services
Install
Click Promote this server to a domain controller
Create Your Domain
Choose Add a new forest
Root domain: lab.local
Set DSRM password
Accept defaults
Install → reboot
After reboot, AD DS and DNS automatically come online.
Verify AD is Working
In PowerShell:
If both return information about lab.local, AD is healthy.

Section 3 - Configuring DNS for Internal and External Name Resolution

AD DNS handles internal queries (lab.local), but you also need a path for external queries (google.com).
Why DNS Forwarding Matters
AD DNS will attempt to resolve everything—even external domains—which will fail unless forwarders are configured. This is expected behavior.
Testing the DNS with a Ping to 8.8.8.8 fails until I configured DNS Forwarding in the pfSense Web GUI
Fixing DNS Forwarding in pfSense
Under Services → DNS Resolver:
Enable Forwarding Mode
Set upstream DNS servers (ex: 8.8.8.8)
Save & apply
This allows pfSense to resolve all external domains.
Fixing DNS Forwarding in Windows Server
Open DNS Manager:
Right-click the server → Properties → Forwarders
Add: 10.0.0.1 (pfSense LAN IP)
This forwards unknown queries to pfSense → which forwards them to upstream DNS → out through NAT.

Testing
nslookup lab.local
nslookup google.com

lab.local resolves internally
google.com resolves externally through pfSense

lab.local → resolves internally (AD DNS) ✅
google.com → resolves externally via pfSense forwarder ✅

Section 4 - Joining Clients to the Domain

A. Joining Windows 11 to the Domain
Requirements:
DNS pointing to 10.0.0.25 (the hard coded IP of the AD server)
confirm Network connectivity to AD server (ping 10.0.0.25)
System clock synchronized (Kerberos relies on accurate time)
Join the domain:
Settings → Accounts → Access work or school → Connect
Choose: Join this device to a local Active Directory domain
Enter: lab.local
Reboot
Verify:

whoami
nltest /dsgetdc:lab.local
ipconfig /all

B. Joining Ubuntu Desktop to the Domain
Ubuntu requires packages for Kerberos + SSSD:

sudo apt update
sudo apt install realmd sssd sssd-tools adcli samba-common-bin oddjob oddjob-mkhomedir packagekit

Discover domain:

realm discover lab.local

Join:

sudo realm join --user=administrator lab.local

Verify:

realm list

Allow domain logins:

sudo realm permit --all

Auto-create home directories:
Enable automatic /home creation for domain users:

sudo pam-auth-update --enable mkhomedir

Both Windows 11 and Ubuntu are now fully domain-joined.

Key Takeaways / Lessons Learned

Building out Active Directory as the identity backbone of the lab revealed just how interconnected authentication, DNS, and domain services really are. This stage of the project required careful configuration, validation, and troubleshooting—especially around DNS and domain join workflows. Completing this step gave me a much clearer understanding of how enterprise identity environments operate and why identity services are such a critical point of failure or strength.

Active Directory and DNS are inseparable—if DNS is not functioning properly, AD will fail in unpredictable ways.
Static IPs are mandatory for domain controllers and servers to ensure consistent authentication and name resolution.
DNS forwarding is normal and expected in enterprise environments; AD handles internal zones while forwarding external queries.
Accurate time synchronization is critical, since Kerberos authentication will break if clocks drift too far.
Joining Linux systems to AD highlights how identity must work across multiple OS ecosystems.
Tools like nltest, whoami, realm, and sssd provide invaluable diagnostics for verifying identity behavior.
This phase showed that identity becomes the central dependency for every layer that follows—logging, access control, monitoring, and detection.

Next Steps / Learning Opportunities

With the identity layer fully established and all clients joined to the domain, the next phase of the project shifts toward visibility and event analysis. Now that authentication and DNS are stable, I can begin focusing on the logs, behaviors, and telemetry that will move this lab from a simple AD deployment to a functional security operations environment.

In the next stage of the homelab build, I’ll begin implementing a full monitoring and detection pipeline. This will include:

Creating Organizational Units (OUs) and applying Group Policies (GPOs)
Installing and configuring Sysmon for advanced process and network telemetry
Setting up Windows Event Forwarding (WEF) to centralize Windows logs
Deploying Splunk Universal Forwarders across server and endpoint systems
Aggregating and parsing logs inside the Splunk SIEM
Running simulated attacks from my Kali machine to test identity and authentication monitoring
Beginning SOC-style analysis, including search queries, baselining, and detection logic development

With networking, segmentation, and identity now in place, the environment is ready to evolve into a true security engineering and blue-team practice lab. The next blog post will document the start of this visibility phase as I install Splunk and configure log forwarding across the environment.

Building a Virtualized Cybersecurity Lab: Networking and pfSense Setup

Evan Dolatowski — Fri, 12 Dec 2025 01:33:13 +0000

This is the First of Four blog posts in a series about building my Virtual home lab network as a Cybersecurity Student.

The Reason Why

Over the past year, I’ve used individual virtual machines, Docker containers, and online training platforms like TryHackMe to build hands-on cybersecurity experience. Although these tools are valuable, they don’t provide the realism or complexity of working inside a fully controlled network environment. With the start of my Cyber Security degree at Maryville University—and after moving my main workstation to a Fedora-based Linux distribution when Windows 10 reached end of life—I decided it was the right time to build a proper virtualized homelab. Running Linux as my host OS also let me avoid Windows 11’s hardware requirements such as Secure Boot and TPM, giving me full control over my virtualization stack and allowing me to design an enterprise-style lab tailored specifically for cybersecurity training.

This post is the first entry in a four-part series documenting my homelab build. Here, I cover the foundational architecture choices, explain how I configured the virtualization environment, and walk through the process of deploying pfSense as the core router and firewall for the entire network. Because my workstation runs Linux natively, I chose KVM and QEMU for their performance, flexibility, and deep integration with the OS. Combined with libvirt, virsh, and virt-viewer, this gives me a fast, lightweight, and highly customizable virtualization ecosystem—ideal for learning how real infrastructure operates behind the scenes.

My Lab Is Organized Around Four Primary Components:

Virtual Networks lab-NAT – Provides pfSense with upstream internet access through the Linux host. lab-LAN – A fully isolated internal network where all client and server VMs live.

This separation models a real enterprise network with distinct external and internal segments.

pfSense Firewall/Router pfSense serves as the central security appliance of the lab, providing:
Routing between WAN and LAN
Stateful firewalling
DHCP services
NAT translation
Segmentation and network boundary control

All traffic entering or leaving the internal network passes through pfSense, mirroring the design of most corporate environments.

Internal Systems These are the systems that make up the “enterprise network” inside the lab: Windows Server 2022 (Active Directory + DNS) Windows 11 workstation Ubuntu Desktop running Splunk Additional Linux servers for testing and future projects

This provides a functional identity, endpoint, and logging ecosystem that represents a realistic enterprise environment.

Kali Linux Attack VM (lab-LAN) A Kali Linux virtual machine deployed inside the lab-LAN to simulate adversarial behavior from a controlled internal or semi-trusted network position.

This setup allows me to perform penetration testing, vulnerability discovery, and attack simulations against the isolated lab-LAN—while keeping everything safely contained and segmented from my real devices.

Process Overview

Section 1 — Preparing the Virtualization Stack

Installing KVM/QEMU and Tools

sudo rpm-ostree install @virtualization virt-manager libvirt libvirt-daemon-kvm qemu-kvm bridge-utils --allow-inactive

What this stack provides:

KVM/QEMU: hardware-accelerated virtualization
libvirt: management layer for VMs
virsh: CLI tool for creating and controlling VMs
virt-manager / virt-viewer: optional GUI tools

Enable and Start libvirt

sudo systemctl enable --now libvirtd

Verify:

sudo systemctl status libvirtd

Verify KVM Support

egrep -c '(vmx|svm)' /proc/cpuinfo

Section 2 — Creating the Virtual Networks

My homelab will use two networks:
lab-NAT (WAN side)
Connects pfSense to the internet
Uses NAT from the Linux host
lab-LAN (internal network)
Hosts all internal machines
Completely isolated from the host
pfSense handles all routing and DHCP

Example XML for lab-LAN and lab-NAT:

Define and start the lab-lan after creating its XML file:

sudo virsh net-define /etc/libvirt/qemu/networks/lab-lan.xml
sudo virsh net-start lab-lan
sudo virsh net-autostart lab-lan

this process is mostly the same for creating the lab-nat

Verify by listing all networks running:

Section 3 — Deploying pfSense (The Core of the Lab)

pfSense is the heart of the homelab and acts as:
Router
Firewall
DHCP server
Gateway for the lab-lan virtual network
Segmentation control
This mirrors what most corporate networks use.

Creating the pfSense VM with Virt Install

sudo virt-install \
  --name pfSense \
  --ram 2048 \
  --vcpus 2 \
  --os-variant freebsd13.0 \
  --disk path=/var/lib/libvirt/images/pfSense.qcow2,size=10,format=qcow2 \
  --cdrom /var/lib/libvirt/boot/pfsense.iso \
  --network network=lab-nat,model=virtio \
  --network network=lab-lan,model=virtio \
  --graphics spice \
  --boot uefi

Open installer:

sudo virt-viewer pfSense

pfSense Interface Assignment
pfSense will detect and ask you to confirm the LAN and WAN:
vtnet0 → WAN (lab-NAT)
vtnet1 → LAN (lab-LAN)
Set the LAN IP
I assigned a memorable static IP to the pfSense LAN interface for easier VM configuration and future reference:
Class A starting with 10.0.0.1
and a subnet mask of 255.255.255.0 gives me plenty of room for my small network
LAN IP: 10.0.0.1/24
DHCP range: 10.0.0.50–10.0.0.200
After this point, pfSense becomes the router and firewall.
Every VM ill attach to lab-lan receives:
IP: 10.0.0.x
Gateway: 10.0.0.1
DNS: 10.0.0.1
Internet routed through pfSense

This completes the initial network segmentation and routing.

Key Takeaways / Lessons Learned

Building the firewall and virtual networking foundation for my homelab significantly improved my confidence with virsh, virt-viewer, and KVM-based virtualization. This phase reinforced key infrastructure concepts such as defining virtual networks, bridging interfaces, configuring routing, and assigning DHCP at the firewall layer. Deploying pfSense helped deepen my understanding of segmentation, NAT behavior, and multi-interface design. Altogether, these steps gave me hands-on experience creating a network architecture that mirrors what real-world IT and security teams use in production.

Next Steps / Learning Opportunities

With the core networking and firewall components complete, my next goal is to expand pfSense’s capabilities and shift toward a more security-focused environment. I plan to explore advanced firewall rules, VLAN segmentation, DNS resolver tuning, and static DHCP mappings for key hosts. I also want to evaluate pfSense packages including pfBlockerNG for threat intelligence and Suricata for IDS/IPS functionality, adding deeper traffic inspection and detection capability.

In the next post, I’ll move into the identity layer by installing Windows Server 2022, promoting it to a Domain Controller, configuring DNS, and integrating it with pfSense. I will join both Windows and Linux clients to the domain and verify authentication across the environment. This will establish the Active Directory foundation that future posts will build on—covering SOC workflows, blue-team tooling, detection engineering, and attack simulations.

Cloud Resume Challenge

Evan Dolatowski — Tue, 23 Apr 2024 00:45:03 +0000

Transitioning to the Cloud: My Journey with Azure

Hey everyone! My name is Evan Dolatowski from Houston, Texas, and I’m a Full Stack developer. I'm currently working towards transitioning to the Cloud industry. The realization of an important gap in my knowledge and the adventure of educating myself more deeply about Cloud technologies began when I ended up hosting my full stack portfolio project using Netlify, Heroku, and Amazon S3 buckets. I didn’t expect to use Amazon S3 Buckets, but it was needed to solve an issue Heroku has with persistent file storage caused by the free hosting. As soon as I realized I needed this third hosting account for my application, I knew my use of the cloud was far from optimized. I needed to learn how to use one of the three large cloud providers: AWS, GCP, or Azure, and I wanted to make sure I knew how to use it well.

After researching jobs in my local area, I found Azure jobs are by far more common than AWS or GCP. So I knew my Cloud platform, familiarized myself with the Certifications available and got the AZ-900 Azure Fundamentals. My next goal was the AZ-104. Once I felt confident in the material and almost ready to take the Exam, I wanted to get some real hands-on experience using Azure services for a difficult project. This is where I discovered The Cloud Resume Challenge.

The Objectives

The Az-900 Azure Fundamentals certification was a prerequisite to the challenge (luckily I already had it).
Your Resume needs to written in HTML, styled with CSS, and hosted on a Azure Storage static website.
The Azure Storage website URL should use HTTPS for security Using Azure CDN and Point a custom DNS domain name to the Azure CDN endpoint.
On the website there needs to be a visitor counter using Javascript request to a Database containing the count.
This Database would be Azure Cosmos DB account.
The Front End should not speak directly to the DB, an API written and tested in Python will accept the request and send SQL queries to the Database. (Azure Functions with an HTTP trigger).
The backend portion of the project should be defined using an ARM template on a Consumption plan and not manually in the Azure Portal.
The Git Repo needs to use CI/CD for both front and back end set up through Github actions for quick automated deployment.

And the final step, write a short blog post describing some things you learned while working on this project.

Frontend

Creating the front end and deploying it to the Azure Storage static website wasn’t nearly as difficult as getting my custom domain set up. Setting up a CDN Profile, DNS Zone, and Purchasing a Custom Domain were all very new tasks for me. A lot of trial and error went into this, but probably more trial and error than I needed. I think if I had updated the DNS settings and patiently waited before I tested it would have worked out for me, but in the end, I probably deleted and recreated all my frontend resources in my resource group over a dozen times, sometimes with the Azure CLI and sometimes with the Portal. I spent a lot of time interacting with the Azure CLI and portal which was the reason I wanted to do the challenge so I'm kind of glad it didn’t just work right away.

DB/Serverless Python API

Next, I needed to make the DB and the Azure Serverless function using Python. This is something silly but I think Azure Cosmos DB is so cool. It’s so quick to create a SQL DB with Azure and quickly connect a Python script to it using The Azure Cosmos DB SQL API library and start using queries. I was excited the challenge already recommends using Serverless functions because its cost-effective for a small project as well as a relatively new technology because I had already wanted to learn more about Serverless Functions. Initializing, creating the template, and testing this function was easy enough thanks to the Azure-CLI. Big thanks to the func init, func new and func start commands.

CI/CD

Finally, we have CI/CD. I love the end result of this step. I think it’s literally so cool that 1 minute after I type ‘git push’ in the terminal the new update is deployed to my custom URL. (If my code passes the tests of course). I've used CI/CD before but I wanted to get more practice with it so I was excited it's included in the challenge. A ton of trial and error went into my frontend YAML file dealing with Node versions and dependencies, as well as my code runs a build script and the build is put into a directory called ‘src’ this src directory contains the files that will then be served in my Azure Storage static site. The backend was much less of a headache but both were a much-welcomed challenge. It’s nice to have the slow progress tackle one small problem at a time until it finally deploys with no errors.

Conclusion

I feel great about using Azure. I spent a lot of time using the Azure CLI and Portal to create update and delete many kinds of resources while doing this challenge which was a very important part of this challenge to me. I'm excited to spend a bit more time studying and get my second Certification, the AZ-104.

Thank you Forrest Brazeal for creating this challenge, and thank you for creating the opportunity to meet the other takers of this challenge and network with like-minded individuals.

EvanDolatowski.com

Link to frontend code
Link to backend code
Feel free to reach out on LinkedIn if you’ve got any questions.