Hardening Checklist — DVWA Lab Environment

Scope: Baseline hardening actions for the Baobab Bay Lodge assessment lab Standard: Derived from CIS benchmarks and least-privilege principles

H-1: Disable Default Credentials

Action: Change the DVWA administrative login from admin / password to a strong credential.

Why it matters: Default credentials are the first thing an attacker tries. Automated scanners test common username/password combinations. If the administrative interface is accessible with default credentials, an attacker gains full control of the application without exploiting a single vulnerability.

Verification: Log out and attempt to log in with admin / password. The login should fail. Log in with the new credentials to confirm they work.

H-2: Close Exposed Database Port

Action: Restrict MySQL (port 3306) so it is not accessible from outside the application container. Modify the Docker Compose configuration to remove the host port mapping for 3306, or bind it to 127.0.0.1 within the container network only.

Why it matters: A database port exposed to the network allows direct connection attempts from any host that can reach the server. An attacker who discovers MySQL on port 3306 can attempt authentication, brute-force credentials, or exploit database-level vulnerabilities — bypassing the web application entirely. The principle of least privilege: the database should only be accessible to the application that needs it.

Verification: Run Nmap against the target host after the change. Port 3306 should appear as closed or filtered, not open. Compare with the initial Nmap scan from reconnaissance.

H-3: Remove Unnecessary Services

Action: Check whether DVWA exposes any services beyond HTTP that are not required for the booking application. Disable or restrict any unnecessary network listeners.

Why it matters: Every exposed service is an additional attack surface. A service the application does not need is risk without benefit. Reducing the number of exposed services reduces the number of entry points an attacker can target.

Verification: Run Nmap with service detection. Compare the list of open ports against the application's requirements. Only ports required for the booking functionality should remain accessible.

H-4: Verify Security Level Configuration

Action: Document the current DVWA security level setting (set to "low" for the assessment). Note that in a production environment, the application would not have a configurable security level — this is a lab artifact that exposes additional vulnerabilities when set to lower values.

Why it matters: The security level setting controls the application's built-in protections. At "low," input validation and output encoding are minimal or absent. Understanding this setting helps distinguish between vulnerabilities that exist because the application is poorly coded and vulnerabilities that exist because a lab setting disabled protections.

Verification: Check the DVWA security settings page. Document the current level and note the implications for the assessment findings.

H-5: Review File Permissions

Action: Check that the web application files inside the container are not world-writable. Application source files, configuration files, and upload directories should be owned by the web server user with restrictive permissions.

Why it matters: If an attacker gains code execution through a vulnerability, world-writable files let them modify the application — inject backdoors, alter configuration, or plant persistent access. Restrictive file permissions limit what an attacker can change after initial access, containing the impact of a compromise.