Vulnerability Assessment & Patch Lifecycle

A hands-on vulnerability assessment and infrastructure hardening project designed to simulate a real-world security assessment and remediation workflow against an Ubuntu Linux server.

The project follows a complete vulnerability management lifecycle:

Discover → Assess → Prioritise → Remediate → Verify

---

Project Objective

The objective of this project was to build an intentionally vulnerable Ubuntu Server environment and perform a structured security assessment.

The environment was assessed using both network-based and host-based security tools before implementing remediation and hardening measures.

The final stage involved repeating the assessments to verify whether the identified vulnerabilities and security weaknesses had been successfully addressed.

---

Lab Environment

Component	Technology
Virtualisation	Proxmox VE
Target System	Ubuntu Server 24.04
Assessment Platform	Kali Linux
Vulnerability Scanner	Nessus Essentials
Network Scanner	Nmap
Security Auditor	Lynis
Firewall	UFW
Web Server	Nginx
Container Platform	Docker
Web Applications	OWASP Juice Shop, DVWA

---

Assessment Methodology

The assessment followed a structured vulnerability management lifecycle:

1. Deploy vulnerable infrastructure
2. Establish a security baseline
3. Perform network reconnaissance
4. Conduct credentialed vulnerability scanning
5. Perform local host security auditing
6. Identify and prioritise vulnerabilities
7. Apply remediation and security hardening
8. Perform verification scans
9. Compare the before and after results

---

📂 Project Documentation & Detailed Evidence

Click any section below to navigate to the detailed evidence, terminal logs, and technical write-ups:

• 📊 Phase 1: Initial Security Assessment — Nmap reconnaissance, Nessus vulnerability scans, and baseline Lynis audit.
• 🛠️ Phase 2: Remediation & Hardening — UFW configuration, Docker network localhost binding, Nginx security rules, and system patching.
• ✅ Phase 3: Verification Audit — Post-remediation Nmap scans, Nessus rescan analysis, and final Lynis compliance score.

---

Initial Security Assessment

The initial assessment identified several security weaknesses, including:

• Exposed Docker application ports
• Publicly accessible .env configuration file
• Outdated operating system packages
• Missing HTTP security headers
• Nginx version disclosure
• Docker-published ports bypassing the expected UFW restrictions

Tools Used

• Nmap
• Nessus Essentials
• Lynis

---

Remediation & Hardening

The identified weaknesses were addressed through several remediation measures:

System Patching

Ubuntu packages were updated to address identified operating system vulnerabilities.

Firewall Configuration

UFW was configured to restrict inbound access exclusively to required services (22/tcp and 80/tcp).

Docker Network Hardening

The Docker containers were initially published directly to the host, making their ports externally accessible. The containers were subsequently reconfigured to bind only to loopback (127.0.0.1), forcing traffic through the Nginx reverse proxy.

Nginx Hardening

The Nginx configuration was updated to block access to hidden files (.env), prevent directory browsing, inject modern security headers, and suppress server version disclosures.

---

Verification & Impact

Following remediation, the environment was assessed again using Nmap, Nessus, and Lynis. The verification process confirmed that:

• Previously exposed Docker ports (3000 & 8080) were no longer externally accessible.
• The .env file returned an explicit HTTP 403 Forbidden.
• Operating system vulnerabilities were addressed through patching.
• Nginx security configuration was hardened.
• The overall Lynis Hardening Index score increased.

---

📊 Before vs After Summary

Assessment Parameter	Before Remediation	After Remediation
Docker Application Ports	Externally Accessible (3000, 8080)	Restricted strictly to 127.0.0.1
Sensitive .env File	Publicly Accessible	HTTP 403 Forbidden
OS Vulnerabilities	Unpatched CVEs Present	Fully Patched (apt upgrade)
Nginx Configuration	Default / Information Disclosed	Hardened / Security Headers Applied
Lynis Hardening Index	58	63

---

Key Learning

One of the most useful findings during this project was discovering that publishing Docker container ports directly can bypass UFW firewall restrictions due to how Docker manipulates iptables.

Rather than assuming the host firewall configuration was sufficient, network exposure was independently verified using Nmap. The containers were subsequently reconfigured to bind strictly to 127.0.0.1, forcing external traffic through the Nginx reverse proxy.

This highlighted the critical importance of validating security controls through testing rather than relying solely on firewall rules.

---

Technologies & Tools

Security Scanners: Nessus Essentials • Nmap • Lynis
Infrastructure: Ubuntu Server • Proxmox VE • Docker
Network & Web Security: UFW • Nginx Reverse Proxy
Assessment Platform: Kali Linux

---

Full Technical Write-up

A detailed Medium article documenting the full step-by-step lab setup and execution will be linked here once published.

---

Disclaimer

This project was conducted entirely within an isolated laboratory environment using intentionally vulnerable systems and simulated credentials. No production systems or real credentials were involved.