Introduction: The Critical First Hours of Your VPS

Deploying a new Linux Virtual Private Server (VPS) is an exciting moment, marking the beginning of a new project, application, or service. However, this initial state is one of significant vulnerability. A fresh server, straight from a cloud provider's template, operates with default configurations that are widely known and routinely scanned for by automated attack scripts. Within minutes of an IP address being announced, it will be probed for common weaknesses. Therefore, the period immediately following deployment is not for installation of your primary software, but for establishing a secure fortress. This post outlines the ten fundamental, mandatory steps to transform your new VPS from a soft target into a hardened bastion, providing a secure foundation for all future work.

1. Immediate Root Password Update and SSH Key Authentication

The very first action upon receiving your server credentials must be to change the root password. If your provider supplied a temporary one, replace it immediately with a strong, unique passphrase. More importantly, you should disable password-based authentication for SSH entirely and rely solely on cryptographic key pairs.

This involves generating an SSH key pair on your local machine (if you haven't already) and placing the public key on the server. The process strengthens security in two key ways: it eliminates the risk of brute-force password attacks, and it ties access to a physical file on your computer that is much harder to compromise than a memorized password.

Implementation Steps:

Generate a key pair locally: ssh-keygen -t ed25519 -a 100
Copy the public key to the server: ssh-copy-id root@your_server_ip
Edit /etc/ssh/sshd_config and set: PasswordAuthentication no, PubkeyAuthentication yes
Restart the SSH service: systemctl restart sshd

Before closing your current session, always open a new terminal window and test that you can log in with your key. This prevents accidentally locking yourself out.

2. Create a Dedicated User Account with Sudo Privileges

Operating directly as the root user is a dangerous practice. A single typo in a command can have catastrophic, irreversible consequences. The principle of least privilege dictates that you should work as a standard user and only elevate permissions when absolutely necessary.

Create a new user account for your daily administrative tasks and grant it sudo privileges. This adds a layer of accountability (commands are logged per user) and safety (destructive commands require a conscious sudo prefix).

Security Best Practice: Avoid giving your primary user account a predictable name like "admin" or "ubuntu." Choose a unique, non-obvious username to add another small hurdle for attackers.

3. Configure the Uncomplicated Firewall (UFW)

A firewall is your server's gatekeeper, controlling which network traffic is permitted to enter and leave. On Ubuntu and other Debian-based systems, the Uncomplicated Firewall (UFW) provides a user-friendly interface for managing iptables rules.

Your baseline configuration should be a default-deny policy for incoming connections, explicitly allowing only the ports you need. For most web servers, this means port 22 (SSH), port 80 (HTTP), and port 443 (HTTPS).

Enable UFW: sudo ufw enable
Allow SSH: sudo ufw allow 22/tcp (Consider changing this port later—see step 5)
Allow HTTP/HTTPS: sudo ufw allow 80,443/tcp
Check status: sudo ufw status verbose

4. Keep Your System Updated Relentlessly

Software vulnerabilities are discovered daily. The single most effective defense against known exploits is a consistently updated system. This applies not just to the core operating system, but to every piece of software you install.

Establish a routine. Before installing any new software, update your package lists and upgrade all installed packages. Automate this process with unattended-upgrades for security patches to ensure critical fixes are applied even if you forget.

5. Change the Default SSH Port

While security through obscurity is not a valid standalone strategy, it is an effective supplement. The vast majority of automated SSH brute-force attacks target port 22. Changing the SSH daemon to listen on a non-standard port (e.g., 2222, 4822) will reduce the noise in your authentication logs by over 90%.

Remember to update your firewall rule before changing the port in the sshd_config file, and always test the new connection in a separate session before terminating the old one.

6. Install and Configure Fail2ban

Fail2ban is an intrusion prevention framework that monitors log files for patterns of malicious activity, such as repeated failed SSH login attempts. When it detects an attack from a specific IP address, it automatically updates the firewall rules to ban that IP for a configured duration.

This tool actively defends your server against brute-force attacks. Configuration typically involves setting up "jails" for services like SSH, web server auth failures, and even custom applications. It is a set-and-forget component that provides active, automated defense.

7. Disable Root Login via SSH

Even with key-based authentication, allowing the root user to log in directly via SSH is an unnecessary risk. If an attacker somehow compromises your private key, they would have immediate, unfettered access. By disabling root SSH login, you force all access through a standard user account, requiring the attacker to also know a valid username and then perform a privilege escalation.

In /etc/ssh/sshd_config, set: PermitRootLogin no

8. Set Up Basic Intrusion Detection with Log Monitoring

You cannot defend against what you cannot see. Regularly reviewing system logs is crucial. Tools like logwatch or lnav can help parse and summarize log data. Pay special attention to /var/log/auth.log for authentication attempts and /var/log/syslog for system-wide events.

For more advanced monitoring, consider an agent-based solution that forwards logs to a centralized, secure location (a SIEM). This ensures logs persist even if the server is compromised.

9. Remove Unnecessary Network Services

A fresh server installation often includes services you do not need. Each running service is a potential entry point. Use netstat -tulpn or ss -tulpn to list all listening network ports and the processes behind them.

Identify and uninstall or disable any service that is not essential for your server's role. Common candidates for removal include unused database servers, mail agents, or old-style telnet/rsh services.

10. Configure Automatic Security Updates and Regular Backups

The final step is to plan for continuity. Configure automatic installation of security updates for the OS. On Ubuntu, the unattended-upgrades package handles this. For critical application updates, you may need a more controlled CI/CD pipeline.

Most importantly, implement a robust, automated, and tested backup strategy. Your backups should be frequent, stored off the VPS itself (e.g., in object storage or on a separate server), and encrypted. Regularly test the restoration process. A backup you cannot restore is worthless.

Conclusion: Security as an Ongoing Process

Implementing these ten steps will place your new Linux VPS on a solid security foundation, far ahead of the average deployment. However, it is critical to understand that security is not a one-time checklist, but a continuous process of vigilance, maintenance, and adaptation. New threats emerge, software evolves, and your own server's role may change.

Establish a routine for reviewing logs, updating software, auditing user accounts, and testing your backups. Consider these foundational steps as the beginning of your server's security lifecycle, not the end. By adopting this proactive mindset, you ensure that your VPS remains a reliable and secure platform for your business operations, protecting your data, your users, and your reputation.

Essential Linux VPS Security: 10 Critical Steps After Deploying a New Server