The secure architecture behind PEAS.
Behind the public website sits a segmented, monitored and recoverable security architecture — a Cyber Security Operations Centre prototype built for PEAS Pty Ltd. Every control below is live, evidenced, and mapped to recognised frameworks.
Title & Context
PEAS Pty Ltd — Secure Network: Build, Defend & Recover
Problem statement
PEAS Pty Ltd is a fictional Australian SMB whose daily operations depend on its network — authentication, file sharing, internal communication, web services, remote access, monitoring and backup. The brief: design, secure and monitor this network, then prove it can withstand a live attack and recover from failure.
My role
This was an individual build — I designed, secured, monitored and recovery-tested the full environment end to end: network segmentation, the SIEM / detection stack, the honeypot, firewall monitoring, remote-access hardening, and backup & disaster recovery. Every control on this page is my own work, evidenced with live screenshots.
Frameworks applied
NIST CSF (Identify · Protect · Detect · Respond · Recover) · ISO 27001 · ACSC Essential Eight · MITRE ATT&CK for technique mapping. Every control on this page maps back to these.
Network Segmentation
Traffic is split into isolated zones routed by a VyOS Layer-3 core switch, with pfSense as the perimeter firewall. East–west movement is filtered at the core; north–south at the perimeter — defence in depth, least privilege.
- VLAN 10 — Staff (10.10.10.0/24)
- VLAN 20 — Servers (10.10.20.0/24)
- VLAN 30 — Honeypot, isolated (10.10.30.0/24)
- DMZ — 172.16.30.0/24
- VyOS L3 core · pfSense NGFW
DMZ Services
Public services are hosted in a segregated DMZ and published through a Cloudflare Tunnel + Nginx reverse proxy — so the company website is reachable worldwide without ever opening an inbound port on the firewall.
- 116 Reverse Proxy — Nginx + Cloudflare Tunnel
- 107 Web Server — peas2026.com
- No inbound WAN port exposed
- Cloudflare DNS · WAF · zero-trust edge
Wazuh SIEM
A Wazuh SIEM/EDR platform centralises logs from across the estate and runs custom detections. It correlates network, host, firewall, honeypot and database activity into a single pane of glass for the analyst.
- 5 log sources: IDS · firewall · Win11 · honeypot · DB
- Custom rules 100200 / 100300–100304
- Active Response auto-block (rule 5712)
- FIM · SCA · MITRE ATT&CK mapping
Firewall Monitoring
pfSense firewall events are streamed to the SIEM via remote syslog. A custom decoder extracts action, source, destination and ports, so blocked and allowed flows become searchable, alertable security events.
- pfSense filterlog → Wazuh (UDP 514)
- Custom decoder + rule 100200
- Port-scan & cross-zone block detection
- ~2,000+ events/hour ingested
Honeypot
A Cowrie + XVWA decoy lives in its own isolated VLAN 30. The firewall publishes SSH port 22 straight to it, so attackers who probe "SSH" land in the trap. A VyOS isolation firewall contains the decoy — it can reach only the SIEM, never the real network.
- 121 — Cowrie (SSH/Telnet) + XVWA (web)
- VLAN 30 isolated · containment firewall
- WAN:22 → decoy · real admin SSH on 2022
- Every interaction = zero-false-positive alert
Backup & Disaster Recovery
A two-tier, 3-2-1 backup strategy: a local Proxmox Backup Server for fast on-site recovery, synced off-site to Cloudflare R2. Restores are tested and timed — recovery is measured, not assumed.
- Tier 1 — PBS, daily 02:00, 7d/4w/6m retention
- Tier 2 — Cloudflare R2 off-site (rclone 03:00)
- RTO ≈ 32–67 s · RPO 24 h
- Restore VERIFIED · 3-2-1 rule
Remote Access
The environment is administered securely from anywhere over a Tailscale (WireGuard) VPN mesh, with no exposed management ports. On-network access is further protected by RADIUS-backed AAA and multi-factor authentication.
- Tailscale VPN — encrypted WireGuard mesh
- Stable admin path (100.77.102.14) home & on-site
- RADIUS / 802.1X · TOTP MFA
- No management ports exposed to WAN
Attack & Defend Round
A live attack was run against the environment by PEAS's own authorised testing host (internal red-team). This is the end-to-end timeline — what was attempted, what the monitoring observed, what fired automatically, and how it was contained.
External scanning & enumeration
Attacker host 10.10.10.124 probes exposed services and enumerates the web app (port scan / directory brute-force).
SSH brute-force against the exposed "server"
Repeated password guessing on SSH. The published port lands the attacker in the honeypot decoy — not the real host — so every keystroke is recorded.
SIEM raises a high-severity alert
Correlation rule fires (level 10, MITRE T1110 — Brute Force) with the attacker's source IP. Zero false positives: any honeypot touch is hostile by definition.
Attacker blocked at the firewall — automatically
Active Response runs firewall-drop; the source IP is added to the block-list (iptables DROP) with no human in the loop. Confirmed live on the host.
Verified & logged
Block verified, session captured, and evidence retained in the SIEM for the incident record.
Incident Response
The response followed a standard playbook aligned to NIST SP 800-61 (Computer Security Incident Handling). Steps executed during the round:
Identify & scope
SIEM alert confirmed a brute-force from a single external IP; scope limited to the exposed decoy — no lateral movement into the staff or server VLANs.
Contain
Automated firewall-drop blocked the source IP immediately; the decoy was already isolated to SIEM-only egress, so containment was instant.
Eradicate
No persistence possible on the throwaway decoy; verified no real credentials were valid and no production host was touched.
Recover
Services confirmed healthy; decoy reset to a clean snapshot; block-list reviewed and retained.
Lessons learned
Detection-to-block measured in seconds; findings and improvements captured below for the next iteration.
Findings
Honest assessment of the build after the attack/defend round.
Strengths
- Automated detection-to-block, no human in the loop
- Honeypot gives high-fidelity, zero-false-positive alerts
- Segmentation contained the attacker to the decoy zone
- Backups tested and restorable with a measured RTO
Weaknesses
- Single analyst — no 24/7 SIEM coverage
- Auto-block could be abused for DoS via spoofed source IPs
- Alert tuning still needed to cut noise on busy services
Gaps
- Endpoint protection (EDR) not rolled out beyond a sample host
- No voice / VoIP monitoring in scope
- MFA not yet enforced on every admin path
- Off-site restore not yet timed end-to-end
Proposal — What I'd Improve Next
Prioritised, highest security value first, with the reason for each.
| Priority | Improvement | Why |
|---|---|---|
| P1 | Enforce MFA on every administrative & remote path | Turns stolen passwords into dead ends — a core Essential Eight control. |
| P1 | Add rate-limiting / allow-list around the auto-block | Stops the firewall-drop response being weaponised for denial-of-service via spoofed IPs. |
| P2 | Roll out endpoint protection (EDR) to all hosts | Extends detection from the network to the endpoint, where many attacks actually land. |
| P2 | Run & time a full off-site restore drill | Proves the 3-2-1 backup meets the recovery objective in practice, not just on paper. |
| P3 | Tune SIEM rules & add per-zone dashboards | Reduces alert noise and speeds analyst triage. |
| P3 | Add voice/VoIP & IoT monitoring | Closes the remaining un-monitored service categories. |