Practice in Security - Hardened LAMP Environment
CASE-02The setup
I built a LAMP stack (Linux, Apache, MySQL, PHP) in an Ubuntu VM, then attacked it from a Kali Linux VM to see what an attacker could learn, and hardened it afterward using OWASP Top 10, DISA STIG, and NIST SP 800-53 controls.
Recon from Kali
- Nmap: found the hosts on the network, and OS detection on the LAMP VM showed ports 22 and 80 open, plus the MAC address and Linux version. Those are useful for spoofing or for looking up known vulnerabilities.
- Wireshark: captured the VM's DHCP request and acknowledgement as it joined the network.
- Nikto (via Legion): revealed the Apache version and OS, missing anti-clickjacking and X-Content-Type-Options headers, and a server that answered junk HTTP methods.
- Skipfish: crawled the site and flagged 74 higher-risk findings, along with hidden files and directories.
Hardening
I worked through DISA STIG rules for Ubuntu (v1r2) and the database, checking each one, fixing it, and re-checking:
- Required at least one uppercase letter, lowercase letter, and number in passwords (
ucredit,lcredit,dcreditset to -1 in/etc/security/pwquality.conf). - Required at least 8 characters to change when a password is changed (
difok=8). - Limited the database to 2 concurrent sessions per user (
max_user_connections=2).
What I took away
Tightening a password rule doesn't protect existing accounts until everyone resets their password. And after testing with password-cracking simulators, I found length matters more than complexity. A long passphrase with a mix of characters beats a short complex password, so a high minimum length should come with the complexity rules.