DMZ Security Monitoring and Hardening

CY376: Network Monitoring, Security and Auditing — End-of-Semester Project Blue Team | University of Mines and Technology, Tarkwa

Author: Kennedy Kumi Holomah Index number: FCM.41.018.148.23 Student ID: 9013004623

Overview

This project builds, secures, and monitors a demilitarised zone (DMZ) hosting a public-facing Ubuntu/Apache web server behind a pfSense firewall, entirely within an isolated VMware Workstation lab. It was built as a Blue Team exercise for CY376 (Network Monitoring, Security and Auditing) at the University of Mines and Technology, Tarkwa, and demonstrates a full defensive lifecycle rather than a single control in isolation: a segmented network boundary, inline detection at that boundary, a real exploitation attempt against a named CVE, automated remediation, and re-validation that the fix actually closed the gap.

The project deliberately pairs each defensive layer with evidence rather than just a configuration screenshot: Suricata's detection is shown catching a live Shellshock exploit attempt in real time, the same payload is shown failing outright after hardening is applied, and the non-obvious infrastructure problems encountered along the way (hardware offload settings silently blocking packet capture, default HOME_NET scoping silently breaking directional signatures, a hardening script's own permission lockdown breaking the server it was meant to protect) are documented as findings in their own right, not edited out.

• Detect: Suricata runs inline (IPS mode) on the DMZ interface using the Emerging Threats (ET) Open ruleset, with HOME_NET correctly scoped to the DMZ subnet so that LAN-originated attack traffic is treated as external.
• Exploit and validate: A real, CVE-mapped exploit (CVE-2014-6271, "Shellshock") is launched from a Kali attacker against the DMZ host. Suricata detects it (SID 2022028) and can actively block it via a custom drop rule.
• Harden: An idempotent Bash script (scripts/dmz_web_hardening.sh) patches Bash, disables the CGI handler Shellshock relies on, restricts SSH to the LAN, enables a host firewall (UFW) and fail2ban, and locks down web-root permissions.
• Re-validate: The identical Shellshock payload is re-run post-hardening and returns HTTP 404 instead of executing, confirming the vulnerability is closed.
• Monitor: A Wazuh manager (OVA appliance) is deployed on the LAN for centralised log and file-integrity monitoring, with DMZ agent enrolment as an in-progress next step.

Full write-up, evidence screenshots, and analysis: docs/CY376_DMZ_Report_Kennedy_Kumi_Holomah.pdf.

Tools used

• VMware Workstation — isolated host-only lab (WAN/LAN/DMZ VMnets)
• pfSense (Community Edition) — firewall, routing, WAN/LAN/DMZ segmentation
• Suricata (pfSense package) — inline IDS/IPS on the DMZ interface
• Emerging Threats (ET) Open ruleset — signature coverage
• Kali Linux — attacker host (Nmap, curl-based exploitation)
• Ubuntu Server + Apache — DMZ web server (target / protected asset)
• Wazuh (OVA appliance) — centralised log collection and file-integrity monitoring
• UFW, fail2ban, unattended-upgrades — host-level hardening on the DMZ server

Lab topology

All inter-segment traffic passes exclusively through pfSense; no path bypasses the firewall.

Repository structure

.
├── README.md
├── .gitignore
├── scripts/
│   └── dmz_web_hardening.sh   # Host hardening script for the DMZ web server
├── docs/
│   └── CY376_DMZ_Report_Kennedy_Kumi_Holomah.pdf   # Full project report
└── evidence/
    └── figure01_lab_topology.png ... figure11_wazuh_dashboard.png
        # The 11 captioned screenshots from the report, numbered to match
        # the figure numbers used throughout docs/CY376_DMZ_Report_*.pdf

Using the hardening script

scripts/dmz_web_hardening.sh targets the DMZ Ubuntu/Apache host. It is written to be safe to re-run: every configuration file it touches is backed up first (.bak-YYYYmmdd-HHMMSS suffix), and all actions are logged to a timestamped file under /var/log.

# On the DMZ web server
sudo bash scripts/dmz_web_hardening.sh

Before running, review the CONFIG section at the top of the script (LAN subnet, HTTP/HTTPS ports) to match your own topology.

What it does:

1. Updates system packages and explicitly patches Bash (the actual fix for CVE-2014-6271).
2. Hardens SSH, if present (disables root login and password auth, restricts to the LAN subnet).
3. Configures UFW: default-deny inbound, HTTP/HTTPS open, SSH restricted to the LAN.
4. Hardens Apache: hides version banners, disables directory listing, prompts to disable mod_cgi/mod_cgid (removing the Shellshock attack surface outright), and locks down web-root ownership/permissions.
5. Installs and configures fail2ban for SSH and Apache-specific jails.
6. Enables unattended security upgrades.
7. Purges legacy, high-risk services (telnet, ftp, rsh) if present.

A completion summary is printed at the end, and full details of each step are in the report.

Key results

Known limitations

• Suricata's SID Management change (converting SID 2022028 from alert-only to an active drop) did not persist through a rule rebuild in the pfSense GUI — recorded as an open issue.
• Wazuh agent enrolment against the DMZ host was initiated but not yet confirmed reporting at time of writing.
• Detection was validated against one well-documented CVE; the ET Open ruleset's coverage of novel/application-specific vulnerabilities is not addressed by this lab.

See Section 6 (Analysis and Recommendations) of the report for the full discussion.

References

• MITRE ATT&CK T1190 — Exploit Public-Facing Application
• NVD — CVE-2014-6271
• pfSense Documentation
• Suricata User Guide
• Emerging Threats Open Ruleset
• Wazuh Documentation