Operation Iron Watch 03

DMZ Pipeline & DDoS Detection Operation

SIEM • DMZ Architecture • Suricata IDS • DDoS Detection Suite • Log Pipeline Engineering

---

Operation Iron Watch 03 is a controlled Blue Team detection operation built on a physical DMZ segment, focused on expanding the detection surface beyond the internal network and validating multi-layer threat detection under real traffic conditions.

Building on the visibility gap identified in Iron Watch 02 — where a full SSH compromise went undetected due to incomplete log ingestion — this operation answers the question directly: can we detect attacks against a public-facing asset before they escalate?

---

• Three-zone network architecture: LAN, DMZ, and internal management segments
• Physical DMZ segment using a dedicated switch, with a Raspberry Pi 3B+ as the exposed web server
• Dual-NIC gateway (sentry-gate01) routing and enforcing traffic between zones
• Full rsyslog forwarding chain: web-arm01 → sentry-gate01 → Graylog (soc-core)
• Suricata IDS on web-arm01 with EVE JSON output parsed via Grok and JSON extractors into structured Graylog fields
• Auth, Apache access, and Suricata alert logs all ingested and structured in Graylog
• SSH hardening on web-arm01: ed25519 keys, locked-down sshd_config, cloud-init override remediated
• UFW enforced on the gateway with explicit allow/deny rules per zone
• DDoS Detection Suite — three Graylog Event Definitions:
  • HTTP Flood — event_type:http, threshold >50 events/min grouped by src_ip
  • SYN Flood — event_type:flow AND proto:TCP, threshold >100 events/min grouped by src_ip
  • ICMP Flood — Suricata custom rule triggering on repeated ICMP to DMZ host, alert forwarded to Graylog

---

Traffic is generated against web-arm01 from a controlled attacker node and observed through the full pipeline: Suricata captures it at the DMZ edge, rsyslog forwards it, and Graylog correlates it into alerts.

Detection focuses on volume and behavioral thresholds per source IP rather than signature matching alone. Each flood type required separate logic tuned to its protocol layer: HTTP at the application layer, SYN at the transport layer, and ICMP at the network layer.

The ICMP detection required a full redesign mid-operation — flow-based counting in Graylog could not reliably distinguish ICMP flood traffic, so the detection was rebuilt as a Suricata rule pushed upstream. This is documented as a key engineering decision.

All three detection rules were validated against live flood traffic and confirmed triggering correctly.

---

• Multi-zone network architecture and physical segmentation
• Firewall rule design and enforcement (UFW, zone-based)
• Log pipeline engineering (rsyslog chain, Grok parsing, JSON extraction)
• IDS deployment and rule authoring (Suricata, EVE JSON)
• Detection rule design and threshold tuning
• Flood detection across L3 / L4 / L7
• Iterative troubleshooting and detection redesign under constraint
• Defensive documentation and lab reporting

---

This operation intentionally scopes the attacker role to external flood simulation against the DMZ host. Lateral movement and internal pivoting are reserved for Iron Watch 04.

The ICMP detection redesign — moving from Graylog-side flow counting to a Suricata upstream rule — reflects the real constraint of SIEM-side detection limits and is documented transparently as part of the operation outcome.

Iron Watch 03 prioritizes pipeline correctness, detection validity, and engineering honesty over coverage breadth.

Full architecture documentation, configuration files, and detection rule references are available in the project repository.