Launching an Ubuntu server on
Amazon EC2 is easy. Keeping that server secure requires more than simply
creating an instance and connecting through SSH.
A newly deployed cloud server can
become an attractive target if unnecessary ports are exposed, software is
outdated, SSH access is poorly configured, or administrative accounts are not
properly protected.
In this guide, we will walk
through 15 practical steps to secure an Ubuntu EC2 server. The examples
use commands that can be performed directly from an Ubuntu terminal.
What You Need Before Starting: For this guide, you need:
- An
AWS account
- An
Ubuntu EC2 instance
- SSH
access to the server
- A
user with sudo privileges
- Basic
Linux command-line knowledge
You can connect to an Ubuntu EC2 instance using SSH:
ssh -i my-key.pem ubuntu@YOUR_PUBLIC_IP
Replace my-key.pem with your actual private key and
YOUR_PUBLIC_IP with the public IP address of your EC2 instance.
Before making security changes, update the system.
1. Update Ubuntu: Keeping the operating system updated is one of the simplest security improvements you can make.
Run:
sudo apt update
sudo apt upgrade -y
su
You can also check whether the system requires a reboot:
sudo needrestart
sudo apt install needrestart -y
Regular updates help ensure that known vulnerabilities in installed packages are patched.
2. Check Which User You Are Using: Before modifying permissions or SSH settings, confirm your current account.
whoami
You can also check your user ID:
id
On a standard Ubuntu EC2 instance, you will commonly connect
using the ubuntu account.
Check which users have administrative privileges:
getent group sudo
Only users who actually need administrative access should have it.
3. Create a Separate Administrative User: Instead of using one account for everything, you can create another administrative user.
For example:
sudo adduser adminuser
Give the user sudo privileges:
sudo usermod -aG sudo adminuser
Verify the account:
id adminuser
This gives you a separate administrative identity while keeping the original account available as a fallback during testing.
4. Protect SSH Private Keys: Your EC2 private key is extremely important. On your local computer, make sure the private key has restrictive permissions.
For Linux or macOS:
chmod 400 my-key.pem
You can check the permissions:
ls -l my-key.pem
Never upload your private SSH key to GitHub or another
public location.
If a private key is exposed, treat it as compromised and
replace the affected access credentials.
5. Review the AWS Security Group
The EC2 Security Group acts as a network-level firewall
around your instance.
For a typical web server, you might need:
SSH TCP 22
HTTP TCP 80
HTTPS TCP 443
Avoid opening unnecessary ports to the entire internet.
For example, this rule:
TCP 22
Source: 0.0.0.0/0
allows SSH connections from anywhere on the internet.
Where possible, restrict SSH access to your known IP address or use a more controlled access method.
6. Check Listening Ports: From inside Ubuntu, check which services are listening for network connections:
sudo ss -tulpn
A simpler version is:
sudo ss -lntp
Look carefully at the output.
For example:
LISTEN 0 128 0.0.0.0:22
LISTEN 0 511 0.0.0.0:80
This indicates that services are listening on ports 22 and
80.
If you find a port you do not recognize, investigate which application is using it before deciding whether it should remain open.
7. Configure the Ubuntu Firewall: Ubuntu includes UFW, the uncomplicated firewall.
Check its status:
sudo ufw status
If you are configuring a remote server, allow SSH before
enabling UFW:
sudo ufw allow OpenSSH
For a web server:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
Then enable the firewall:
sudo ufw enable
Check the rules:
sudo ufw status verbose
Be careful when changing firewall rules on a remote EC2
instance. Incorrect rules can lock you out.
8. Disable Password Authentication for SSH: SSH key authentication is generally preferable to password-based SSH authentication for server administration. Before disabling passwords, make sure key-based authentication works in a second SSH session.
Open the SSH configuration:
sudo nano /etc/ssh/sshd_config
Look for:
PasswordAuthentication yes
Change it to:
PasswordAuthentication no
You may also want:
PermitEmptyPasswords no
After making changes, test the SSH configuration:
sudo sshd -t
If there is no output, the configuration syntax is valid.
Then restart SSH:
sudo systemctl restart ssh
Do not close your existing SSH session until you have successfully tested the new configuration.
9. Disable Direct Root Login: Direct root SSH access is generally unnecessary on an Ubuntu EC2 server. Check your SSH configuration:
sudo nano /etc/ssh/sshd_config
Set:
PermitRootLogin no
Test the configuration:
sudo sshd -t
Then restart SSH:
sudo systemctl restart ssh
Use a normal account with sudo when administrative privileges are required.
10. Install Fail2ban: Fail2ban can monitor authentication-related logs and temporarily block IP addresses associated with repeated failed login attempts.
Install it:
sudo apt update
sudo apt install fail2ban -y
Check the service:
sudo systemctl status fail2ban
Enable it at startup:
sudo systemctl enable fail2ban
Check its status:
sudo fail2ban-client status
Fail2ban should be configured carefully, particularly on servers where legitimate administrators may connect from changing IP addresses.
11. Check SSH Authentication Logs: Linux keeps useful information about authentication activity. On Ubuntu, you can inspect authentication logs with:
sudo tail -f /var/log/auth.log
You can search for failed authentication attempts:
sudo grep "Failed password" /var/log/auth.log
You can also search for successful SSH logins:
sudo grep "Accepted" /var/log/auth.log
These commands can help you identify unusual login activity.
12. Remove Unnecessary Software and Services: Every installed service can potentially increase the attack surface of a server. List enabled services:
systemctl list-unit-files --type=service --state=enabled
Check running services:
systemctl --type=service --state=running
If you discover a service you do not need, investigate it
before disabling or removing it.
For example:
sudo systemctl stop SERVICE_NAME
To prevent it from starting automatically:
sudo systemctl disable SERVICE_NAME
Do not disable services simply because their names are
unfamiliar. First determine what they do and whether Ubuntu or another
application depends on them.
13. Monitor Disk Usage: A full disk can cause unexpected application failures and may interfere with logging. Check disk usage:
df -h
Check which directories are consuming space:
sudo du -sh /var/* 2>/dev/null
For a more detailed view:
sudo du -ah /var | sort -rh | head -20
Pay particular attention to log files, application data, and unexpected large files.
14. Review File Permissions: Linux permissions are an important part of server security.
Check the permissions of sensitive SSH files:
ls -la ~/.ssh/
The SSH directory should normally be accessible only by its
owner.
You can use:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Check ownership:
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys
Incorrect ownership or permissions can prevent SSH authentication from working.
15. Create a Backup and Recovery Plan: Security is not only about preventing attacks. You also need a way to recover when something goes wrong.
For EC2, consider using:
- EBS
snapshots
- AMIs
- Application-level
backups
- S3
for appropriate backup data
- Automated
backup policies
For example, before making major configuration changes, you could create an EC2/EBS backup or snapshot according to your recovery requirements. A backup is only useful if it can actually be restored, so periodically test your recovery process.
Bonus: Create a Simple Security Checklist: After securing your Ubuntu EC2 instance, use this checklist:
[ ] Ubuntu packages updated
[ ] Unnecessary software removed
[ ] Security Group reviewed
[ ] Unnecessary ports closed
[ ] UFW configured
[ ] SSH keys protected
[ ] Password authentication reviewed
[ ] Root SSH login disabled
[ ] Separate administrative account configured
[ ] Authentication logs monitored
[ ] Fail2ban configured where appropriate
[ ] File permissions reviewed
[ ] Disk usage monitored
[ ] Backups configured
[ ] Recovery process tested
How to Check Your Server After Hardening: A useful final check is to review your network listeners:
sudo ss -tulpn
Check firewall rules:
sudo ufw status verbose
Check SSH:
sudo sshd -t
Check running services:
systemctl --type=service --state=running
Check disk space:
df -h
And review recent authentication activity:
sudo grep "Accepted" /var/log/auth.log | tail
These simple commands give you a useful snapshot of the server's current security configuration.
Final Thoughts: Securing an AWS EC2 server is not a one-time task. A secure server needs regular updates, monitoring, controlled access, backups, and periodic configuration reviews.
The most important principle is least privilege:
expose only the services you actually need, give users only the permissions
they require, and avoid unnecessary access from the public internet.
If you are learning AWS or preparing for a junior cloud
engineering or cloud security role, practicing these steps on a test EC2
instance is a useful way to understand how AWS Security Groups, Linux
permissions, SSH, UFW, systemd, logging, and backups work together.
Always test security changes carefully, especially SSH and
firewall changes, because an incorrect configuration can lock you out of your
own server.
Disclosure: The commands in this guide are examples for an Ubuntu EC2 environment. Exact configuration requirements may vary depending on your Ubuntu version, AWS architecture, applications, and security requirements.
0 Comments