How I Turned a $300 Mini PC into a Detection Engineering Lab
A used HP EliteDesk became a Proxmox lab for running Windows and Linux systems, learning how networks behave, collecting security logs, testing detections, and automating response with n8n.
The hardware
I found an HP EliteDesk 800 G6 on Facebook Marketplace for about $300. It came with a 10th-generation Intel i5-10500, 40 GB of RAM, and a 1 TB NVMe drive.
Those specs gave me enough room to run several virtual machines on one small system. I could build, break, reset, and retest things without touching a production environment.
After picking it up, I installed Proxmox VE and created a mix of Windows Server 2022 and Linux virtual machines. I use them to represent endpoints, services, and an attacker foothold.
How the lab works
I designed the lab around a repeatable detection and response loop:
- Generate controlled activity from a VM representing an attacker foothold.
- Collect logs from the affected endpoints and services.
- Send the telemetry to a central location for analysis.
- Run detection rules against the activity.
- Pass the alert to n8n for enrichment and response actions.
- Adjust the telemetry, rule, or workflow and run the scenario again.
Repeatability matters. If every test uses different activity, it becomes difficult to tell whether a detection improved or the test conditions changed. Running the same scenario gives me a baseline. I know what activity occurred, which logs should appear, what the rule should detect, and what response should follow.
How the lab taught me networking
Networking became one of the most valuable parts of this project.
Working with Proxmox made concepts such as virtual bridges, IP addressing, routing, ports, and network segmentation practical. Every VM needed a way to communicate with the systems around it while still staying inside a controlled lab.
I had to understand which machines could reach one another, where traffic was supposed to go, and what needed to be allowed for logs and alerts to move through the environment.
That became especially useful when something failed. A missing alert did not always mean the detection rule was wrong. The endpoint might not have reached the log collector, a required port might have been blocked, or the service receiving the data might not have been listening.
Troubleshooting those problems taught me to follow the full network path instead of guessing. I could start at the source, check connectivity between systems, confirm that the traffic reached its destination, and then inspect the application or detection logic.
The lab helped connect networking concepts directly to security work. Understanding normal communication between systems makes it easier to recognize unusual traffic, isolate problems, and design better controls.
Where the detection work happens
Writing a detection rule is only one part of the job. The rule still depends on the logs reaching the SIEM with the right fields and enough context.
If the source system does not record the activity, there is nothing to detect. If the logs arrive incomplete or inconsistently formatted, the rule may miss the event. If the rule is too broad, normal activity can generate unnecessary alerts.
The lab lets me work through that entire chain. I can inspect the source telemetry, test the rule, review what fired, and adjust the logic before running the scenario again.
That process changed how I think about detection engineering. I would rather have a small set of rules tied to known behavior and tested against repeatable scenarios than a large collection of rules I have never validated.
Adding automation with n8n
Once a detection produces a useful alert, I can send it to n8n.
The workflow can add context to the alert and trigger a response action. The important decision is how much authority to give the automation. An alert should carry enough information about the source, affected system, matched behavior, and severity before a workflow takes action.
I treat guardrails as part of the workflow design. Low-confidence alerts should not trigger the same response as activity with stronger evidence. That keeps a noisy rule from becoming a noisy or disruptive automation.
The lab gives me a safe place to change the workflow, replay the scenario, and see how the response behaves before trusting it with anything important.
What this project demonstrates
- Installing and administering a Proxmox virtualization host
- Running and managing Windows Server and Linux systems
- Configuring virtual networking and connectivity between VMs
- Working with IP addressing, ports, routing, and segmentation
- Troubleshooting the path between endpoints, log collectors, and automations
- Centralizing and reviewing endpoint and service telemetry
- Translating known behavior into detection logic
- Testing rules against repeatable scenarios
- Using n8n to connect alerts with response actions
- Adding context and guardrails before automating a response
It also forces me to troubleshoot across layers. A failed detection could come from the endpoint, the network path, the logging configuration, the collection pipeline, the rule, or the automation handling the alert. Finding the failure means following the event from its source to the final response.
What I'm adding next
The next step is to document each scenario with the activity performed, expected telemetry, network path, detection logic, and response result. I also want to map the scenarios to MITRE ATT&CK and track measurements such as detection time, false positives, and response time.
For about $300, I now have a lab where I can run the same activity, follow it across the network, watch the logs arrive, tune the detection, and test the response from end to end.