Hardening a LAMP Web Server on AWS
This project focused on architecting a secure LAMP (Linux, Apache, MySQL, PHP) environment on AWS by implementing a multi-layered Defense in Depth strategy. By hardening the cloud perimeter and the host operating system, the server's attack surface was minimized in alignment with the CIA Triad (Confidentiality, Integrity, and Availability). The project concluded with a validated Lynis Hardening Index of 67, exceeding industry security baselines.
Cloud Computing Overview
Cloud computing provides on-demand access to computing resources such as servers, storage, and networking over the internet. Security in the cloud operates under a shared responsibility model, where the provider protects the underlying infrastructure, while the customer is responsible for securing operating systems, applications, and configurations. This model enables the deployment of secure, hardened systems without relying on physical infrastructure management.
Why AWS?
AWS was chosen for its robust security capabilities, including Identity and Access Management (IAM) for access control, Virtual Private Clouds (VPCs) for network isolation, and Security Groups for configurable firewall rules. These features allow fine-grained management of system access and traffic, supporting the secure deployment and hardening of a Linux-based LAMP server in a controlled cloud environment.
Project Objectives & Scope
The primary goal of this project was to deploy and secure a LAMP server using industry best practices. Key objectives included:
Network Isolation: VPC segmentation with strict ingress/egress filtering.
Host Hardening: Preventing privilege escalation and enforcing key-based authentication.
Service Security: Securing database access and obfuscating application metadata.
Architecture Components and Role in Security
The cloud environment leveraged key AWS components to implement layered security. A Virtual Private Cloud (VPC) provided network isolation, with a public subnet connected via a custom route table and Internet Gateway to manage external traffic. Security Groups acted as stateful firewalls, exposing only essential ports, while an EC2 instance hosted the LAMP stack within an Availability Zone, ensuring both security and high availability.
Cloud Environment Setup and LAMP Deployment Process
The Cloud Infrastructure Provisioning
The cloud infrastructure was provisioned using a custom VPC to provide network isolation. A public subnet was created and connected to an Internet Gateway via a custom route table to enable controlled external access. Security Groups acted as stateful firewalls, restricting inbound traffic to SSH (Port 22) from the administrator’s IP and HTTP/HTTPS (Ports 80/443) for public web access. An Ubuntu-based EC2 instance hosted the LAMP stack, with RSA key-pair authentication ensuring secure, password-free administrative access.
Connecting and updating EC2 Instance
Secure Administrative access to the EC2 instance was established using SSH. Upon first access, the Ubuntu operating system was fully updated to patch known vulnerabilities and eliminate outdated packages. This ensured the base system was secure prior to deploying application services.
Install and Test LAMP Stack
The LAMP stack was deployed using the Ubuntu package manager, installing Apache as the web server, MySQL as the database service, and PHP for server-side scripting. Following installation, all services were verified to be active and correctly integrated, confirming that the web server and database layers were operational prior to security hardening. This ensured a stable baseline environment before applying additional security controls.
Securing the Cloud Environment and LAMP Stack
To ensure a robust security posture, the hardening of the deployment was organized into three distinct layers, following a Defense in Depth methodology. This approach ensures that if one security control fails, others are in place to prevent a total system compromise. The following sections detail the critical steps taken at the Network (Cloud Environment), Operating System (EC2 Instance), and Application layers (LAMP Server) to mitigate risks and enforce the Principle of Least Privilege. All Security measures put in place are explained below:
a. Network-Level Hardening (Cloud Environment)
Network-level hardening was implemented using Security Groups to restrict SSH access to the EC2 Instance and allow only HTTP/HTTPS traffic. Deploying the EC2 instance within a non-default VPC provided logical isolation, and all other ports remained closed. These measures enforce least-privilege access and reduce the system’s external attack surface.
b. Operating System (OS) Hardening
Once the network perimeter was secured, host-level hardening was performed on the Ubuntu instance to prevent privilege escalation and unauthorized local changes.
The first action taken upon deployment was running
sudo apt updateto ensure the system had the latest security metadata andsudo apt upgrade -ywas executed to patch known Common Vulnerabilities and Exposures (CVEs) in the operating system binaries and libraries.
Fail2Ban for Intrusion Prevention: Monitored authentication attempts and banned malicious IPs to prevent unauthorized access.
Auditd for System Accountability: Logged system activity to support accountability and incident response.
c. Application and Database Hardening (The LAMP Stack)
The final hardening layer involved securing the specific services (Apache and MySQL) that host the data and application.
MySQL Secure Installation: The MySQL database service was hardened using the mysql_secure_installation utility to eliminate default insecure configurations. It removed anonymous users, disabled remote root access, and restricted administrative access via auth_socket to prevent unauthorized database access.
Apache Information Obfuscation: Modified ServerTokens and ServerSignature to hide server and OS details, reducing risk of targeted attacks.
Evaluation of Security best practices
The efficacy of the implemented security controls was validated through a series of internal diagnostic audits. By utilizing host-based auditing tools like Lynis and Netstat, the server's configuration was verified against industry benchmarks to ensure that the "attack surface" had been effectively minimized.
a. System Audit with Lynis
The system achieved a Lynis Hardening Index of 67, exceeding standard security baselines and demonstrating improvements in kernel hardening, SSH security, and file system permissions.
b. Network Service Validation with Netstat
Network service validation confirmed that MySQL is bound to localhost only, and only Apache (HTTP/HTTPS) and restricted SSH are active. These results validate the application of the Principle of Least Privilege, minimizing the attack surface and reducing potential exposure to threats.
The Big 5 steps taken in securing the Cloud Environment
S/N | Security Measure | Justification (The "Why") | Critical Analysis |
1. | SSH IP Whitelisting for Cloud environment | Follows the Principle of Least Privilege by denying the entire world access to the management port except allowed IP | Prevents automated botnet scans and credential stuffing attacks before they reach the OS or Server. |
2. | Key-Based Authentication for the OS | Replaces weak, guessable passwords with strong cryptographic key pairs saved on the cloud and the local system for authentication. | Neutralizes the risk of "Brute Force" attacks; even if an attacker has the IP, they lack the physical key file. |
3. | MySQL Secure Installation for the LAMP Server | Applies industry best practices to secure the database, including removing anonymous users, disabling remote root access, and enforcing local authentication via | Prevents unauthorized database access and reduces the risk of lateral movement; even if the web server is compromised, attackers cannot easily access or escalate privileges in MySQL. |
4. | Apache Banner Hiding for the LAMP server | Implements "Security through Obfuscation" by hiding version numbers. | Stops "Reconnaissance"; attackers can't easily identify which specific CVEs (bugs) your server might have. |
5. | Fail2Ban Monitoring for the OS | Adds an "Active Defense" layer that responds to threats in real-time. | While static rules stay the same, this is dynamic—it identifies and blocks a "living" attacker based on their behavior |
Recommendations and Lessons-learnt
Lessons Learnt
The deployment process highlighted several technical insights:
Importance of Infrastructure as Code (IaC): Manual VPC, subnet, and route table configuration is complex; automation ensures consistent and secure deployment.
Internal Auditing: Tools like Lynis and Netstat can validate security without intrusive scanners.
Zero-Trust Mindset: Securing the perimeter alone is insufficient; internal hardening, such as MySQL auth_socket and disabling SSH passwords, is essential.
Recommendations
While the system is at a good security threshold, the following measures are recommended:
SSL/TLS: Deploy certificates (e.g., Let’s Encrypt) to encrypt web traffic.
File Integrity Monitoring (FIM): Deploy AIDE or OSSEC for real-time file integrity monitoring.
Automated Patch Management: Implement scheduled updates to address vulnerabilities promptly.
Conclusion
The project successfully demonstrated a robust deployment of a LAMP server on AWS. By integrating security groups, ssh filtering with host-level hardening and service details obfuscation, the infrastructure adheres to the Defense in Depth philosophy. The final audit score of 67 validates that the server is prepared for a production environment under modern threat conditions.
