My first hands-on cybersecurity home lab. I set up an Ubuntu VM to practice Linux server hardening, including SSH lockdown, UFW firewall config, and IAM least privilege. This project moves beyond theory to practically apply core security concepts like Least Privilege, Attack Surface Reduction, and Defense in Depth.
- Operating System: Ubuntu 26.04 LTS (VirtualBox)
- Access Control: IAM,
sudo,chmod/chown - Network Defense: UFW (Uncomplicated Firewall)
- Remote Access: OpenSSH
- Auditing: Systemd, Journalctl
Before making any changes, I assessed the default state of the server. I verified the OS details and checked for open ports. As expected, the UFW firewall was completely inactive, leaving default services exposed.
To protect against compromised accounts, I ensured daily administrative tasks wouldn't be done as root. I created a dedicated analyst user and explicitly verified that this account was restricted and not allowed to run sudo commands.
To test internal access controls, I created a mock secure directory. I modified the ownership (chown) and tightened the read/write permissions (chmod 750). When I tested access as my standard user, the system successfully blocked me, proving the permissions were properly hardened.
SSH is a primary target for automated botnets. I edited the /etc/ssh/sshd_config file to explicitly disable PasswordAuthentication and block PermitRootLogin. Now, authentication requires a cryptographic key, effectively stopping brute-force password guessing.
I enabled the Uncomplicated Firewall (UFW) and implemented a strict "deny by default" incoming policy. I explicitly allowed only port 22/tcp for my secure SSH connections, drastically reducing the server's network attack surface.
A secure server should only run necessary applications. I audited the active systemd services to ensure there were no unnecessary background processes running that an attacker could potentially exploit.
Security controls must be tested. I simulated an attack by attempting an unauthorized root login via SSH. The connection was immediately denied. I then queried the system logs (journalctl) and verified that the SSH daemon actively closed the connection during the pre-authentication phase, proving the defenses worked exactly as intended.
This lab solidified my understanding of Defense in Depth. By layering security controls—combining a firewall with strict user permissions and SSH key requirements—I learned that if an attacker manages to bypass one layer, another barrier is waiting for them.