Office as IaC
Fully containerized enterprise-network simulation with 7 security zones, 6 firewalls, IPSec IKEv2 site-to-site VPN, Suricata IDS, SIEM, EDR, and Tenable Nessus — entirely declared as code with Docker Compose and validated by 20+ automated E2E tests.
Overview
A production-grade Infrastructure-as-Code implementation demonstrating hands-on network security engineering through a realistic multi-zone office network simulation. The architecture models an enterprise environment with 7 isolated security zones (Gateway DMZ, Service-X, Security Infrastructure, DMZ #2, Green zone, Red zone, Remote Office) orchestrated entirely in Docker Compose. Features 6 iptables-based firewalls enforcing inter-zone routing and policy enforcement, IPSec IKEv2 site-to-site VPN using strongSwan connecting the main office to a remote branch office with aes256-sha384-modp2048 encryption, dual Suricata NIDS deployments monitoring gateway DMZ and service-X zone for intrusion detection, BIND9 recursive DNS resolvers per zone, centralized SIEM (rsyslog UDP/514) collecting logs from all security infrastructure, EDR stub with auditd for endpoint monitoring, log aggregator forwarding to SIEM, and Tenable Nessus vulnerability scanner with web UI. Every firewall rule, network segment, routing policy, and security control is version-controlled and reproducible via declarative configuration. The project includes 20+ automated end-to-end tests (tests/e2e.sh) validating connectivity policies, firewall rules, DNS resolution, and service availability using docker exec from inside running containers. Demonstrates modern DevSecOps practices by treating network infrastructure as testable, reviewable code with one-command deployment. Perfect for security professionals learning network segmentation, network engineers prototyping firewall policies, compliance teams requiring auditable network configurations, and anyone studying defense-in-depth architecture. All containers based on ubuntu:20.04 with NET_ADMIN and NET_RAW capabilities for iptables manipulation. The IPSec pre-shared key and Nessus credentials are externalized to .env file (never committed to version control) for secure secret management. Ideal for hands-on practice with enterprise network security concepts in a safe, repeatable lab environment.
Key Highlights
- ✓7 isolated security zones: Gateway DMZ, Service-X, Security Infra, DMZ #2, Green, Red, Remote Office
- ✓IPSec IKEv2 site-to-site VPN (strongSwan) with aes256-sha384-modp2048 encryption
- ✓6 iptables firewalls enforcing inter-zone routing and policy enforcement
- ✓Dual Suricata NIDS deployments monitoring gateway and service zones
- ✓Centralized SIEM (rsyslog) with EDR, log collector, and Nessus scanner
- ✓20+ automated E2E tests validating connectivity and firewall policies
- ✓Version-controlled network configuration: every rule declared as code
- ✓One-command deployment: docker compose up -d --build
Technical Deep Dive
Multi-Zone Network Architecture
The architecture simulates a realistic enterprise network with 7 distinct security zones connected through a hierarchy of firewalls. The Gateway DMZ (10.1.0.0/24) serves as the internet-facing perimeter hosting the gateway_firewall (NAT + IPSec VPN endpoint), gateway_nids (Suricata IDS), and gateway_dns (BIND9 recursive resolver). The main_firewall (10.2.0.3) acts as the core inter-zone router, enforcing strict policy between internal zones: Service-X (10.2.0.0/24) for internal application servers, Security Infrastructure (10.2.1.0/24) hosting SIEM, EDR, log collector, and vulnerability scanner, DMZ #2 (10.2.2.0/24) with VPN controller and secondary web-facing services, Green zone (10.3.0.0/24) for trusted internal workstations, and Red zone (10.4.0.0/24) for isolated/untrusted segments. The Remote Office (192.168.0.0/24) connects via IPSec IKEv2 site-to-site VPN through ro_firewall, simulating branch office connectivity. Each zone has dedicated firewalls, DNS resolvers, and where applicable, NIDS sensors, creating a defense-in-depth architecture that mirrors real-world enterprise deployments.
Firewall Policy & Zero-Trust Segmentation
The firewall policy implements zero-trust principles where traffic is explicitly allowed rather than implicitly permitted. Gateway DMZ can reach Service-X on HTTP/HTTPS (ports 80/443) and Security Infrastructure for syslog (UDP 514), but is blocked from accessing Green/Red zones. Service-X zone can communicate with Green zone for HTTP/HTTPS web services and with Security Infrastructure for logging, but is isolated from Red zone. Security Infrastructure has administrative access to all zones via SSH (port 22), HIDS (port 1514), and Nessus scanning. Internet-facing gateway permits HTTPS (443), IPSec (500/4500), and OpenVPN (1194). All inter-zone routing passes through main_firewall which enforces these policies via iptables rules. Each firewall container runs with NET_ADMIN and NET_RAW capabilities (or privileged: true) to manipulate iptables and routing tables. The strict segmentation ensures that compromise of one zone doesn't automatically grant access to others, requiring attackers to pivot through multiple security boundaries — each with its own monitoring and policy enforcement.
IPSec VPN & Encrypted Site-to-Site Connectivity
The gateway_firewall ↔ ro_firewall tunnel implements an IKEv2 site-to-site VPN using strongSwan, connecting the main office (10.x.x.x subnets) with the Remote Office (192.168.0.0/24). The VPN uses industry-standard encryption: aes256-sha384-modp2048 for both IKE (key exchange) and ESP (data encryption). The pre-shared key (PSK) is read at container start-up from the IPSEC_PSK environment variable defined in .env (git-ignored), ensuring secrets are never baked into Docker images or committed to version control. This design demonstrates secure credential management and allows the VPN to be deployed in production-like scenarios where branch offices need encrypted connectivity to headquarters. The tunnel enables remote_office hosts (ro_host1 at 192.168.0.100) to securely communicate with main office zones as if they were on the same physical network, while maintaining encryption for all inter-site traffic.
Security Monitoring & Intrusion Detection
The environment includes comprehensive security monitoring through multiple systems: Suricata NIDS deployments on gateway_nids (10.1.0.20) and service_x_nids monitor network traffic for known attack signatures, protocol anomalies, and suspicious patterns. The centralized SIEM at 10.2.1.30 collects syslog events (UDP 514) from all firewalls, DNS servers, and security infrastructure, enabling correlation of security events across the entire network. The EDR stub (10.2.1.10) demonstrates endpoint monitoring with auditd collecting system call traces and process execution logs. The log_collector (10.2.1.20) aggregates logs before forwarding to SIEM, simulating a typical enterprise logging pipeline. Tenable Nessus vulnerability_scanner (10.2.1.50) provides web-based vulnerability assessment accessible at https://localhost:8834, enabling security teams to identify misconfigurations, missing patches, and exploitable weaknesses across all zones. This multi-layered monitoring approach demonstrates defense-in-depth where network, host, and application layers all contribute to the overall security posture.
Infrastructure-as-Code & Automated Testing
The entire network is declared in docker-compose.yml with supporting configurations in services/ directory, demonstrating true Infrastructure-as-Code principles. Every firewall rule, routing policy, DNS configuration, and NIDS signature is version-controlled, enabling audit trails, change review processes, and repeatable deployments. The 20+ automated end-to-end tests in tests/e2e.sh validate the infrastructure by executing connectivity tests from inside running containers using docker exec. Tests verify: firewall containers are running, routing between zones works as expected, firewall policies correctly permit allowed traffic, firewall policies correctly block prohibited traffic, DNS resolution functions properly, and security services are accessible. Each test outputs [PASS] or [FAIL] with a final summary (e.g., 'Tests passed: 20 / 20'), ensuring infrastructure changes don't break security policies. The one-command deployment (docker compose up -d --build) spins up the entire 23-container stack in minutes, making it ideal for hands-on learning, policy prototyping, and demonstrating enterprise network security concepts in interviews, training, or compliance audits.