Server Security Best Practices: How to Harden Your VPS

Server security is the practice of protecting a server from unauthorized access, data breaches, malware, and attacks through a combination of configuration hardening, access controls, monitoring, and regular maintenance. Every server connected to the internet is a target. Automated bots scan the entire IPv4 address space continuously, probing for open ports, default credentials, unpatched software, and misconfigured services. A newly deployed server can receive its first brute force attack within minutes of going online.

The good news is that most attacks are automated and unsophisticated. They target the lowest-hanging fruit: default passwords, unpatched vulnerabilities, and open ports running unnecessary services. A properly hardened server blocks the vast majority of these attacks without any ongoing effort. This guide covers every essential security practice for Linux and Windows servers, from initial setup to ongoing maintenance.

Why Server Security Matters

A compromised server can be used to send spam, host phishing pages, mine cryptocurrency, launch DDoS attacks against other targets, or steal sensitive data. The consequences go beyond your own server. If an attacker uses your server to attack others, your IP address gets blacklisted, your hosting provider may suspend your account, and you could face legal liability depending on your jurisdiction.

For businesses, a security breach means downtime, data loss, damaged reputation, and potential regulatory fines. For individuals running personal projects, a compromised server means losing control of your data and potentially having your credentials stolen if you reuse passwords across services.

Server security is not a one-time task. It is an ongoing process of keeping software updated, monitoring for suspicious activity, and adapting your defenses as new threats emerge. The practices in this guide form the foundation that every server should have in place.

SSH Hardening

SSH is the primary way administrators access Linux servers remotely. It is also the most attacked service on any Linux server. Automated bots attempt thousands of SSH login combinations per hour against every public-facing server. Hardening SSH is the single most impactful security step you can take.

Use SSH Key Authentication

Password authentication is vulnerable to brute force attacks. SSH key authentication uses a cryptographic key pair instead of a password. The private key stays on your local machine and the public key is placed on the server. Without the private key, nobody can log in, regardless of how many password combinations they try.

Generate an SSH key pair on your local machine:

ssh-keygen -t ed25519 -C "[email protected]"

Copy the public key to your server:

ssh-copy-id user@your_server_ip

After confirming you can log in with the key, disable password authentication entirely by editing /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes

Restart the SSH service:

sudo systemctl restart sshd

With password authentication disabled, brute force attacks against SSH become completely ineffective. The attacker would need your private key file, which never leaves your local machine.

Change the Default SSH Port

SSH runs on port 22 by default. Every automated scanner targets port 22 first. Changing the SSH port to a non-standard number does not make SSH more secure in a technical sense, but it eliminates the vast majority of automated attacks because most bots only scan port 22.

Edit /etc/ssh/sshd_config and change the port:

Port 2222

Replace 2222 with any unused port number between 1024 and 65535. Update your firewall rules to allow the new port before restarting SSH, or you will lock yourself out.

Disable Root Login

The root user has unlimited access to the entire system. If an attacker gains root access, they own the server completely. Disable direct root login over SSH and use a regular user account with sudo privileges instead.

Edit /etc/ssh/sshd_config:

PermitRootLogin no

This forces attackers to guess both a valid username and a valid credential instead of just targeting the root account that exists on every Linux system.

Set Login Grace Time and Max Attempts

Limit how long a connection can remain unauthenticated and how many authentication attempts are allowed per connection:

LoginGraceTime 30
MaxAuthTries 3

This gives legitimate users 30 seconds to authenticate with a maximum of 3 attempts. Brute force tools that try hundreds of passwords per connection get disconnected after 3 failures.

Firewall Configuration

A firewall controls which network traffic is allowed to reach your server and which traffic is blocked. Without a firewall, every service running on your server is accessible from the internet. A properly configured firewall ensures that only the ports you explicitly need are open.

The principle is simple: deny everything by default, then allow only the specific ports your services require. For a typical web server, that means allowing port 22 for SSH, port 80 for HTTP, and port 443 for HTTPS. Everything else gets dropped.

Linux Firewall with IPtables

IPtables is the built-in firewall on Linux. A basic secure configuration allows SSH, HTTP, HTTPS, and established connections while dropping everything else:

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Allow established connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow HTTP and HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Drop everything else
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Save your rules with iptables-persistent on Ubuntu and Debian or iptables-services on AlmaLinux and Rocky Linux so they survive reboots.

Linux Firewall with UFW

UFW is a simplified firewall frontend available on Ubuntu and Debian. It translates simple commands into iptables rules:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

UFW is easier to manage than raw iptables for basic configurations. For advanced rules like rate limiting and port forwarding, iptables gives you more control.

Windows Firewall

Windows Server includes Windows Defender Firewall with Advanced Security. Open it from Server Manager or by running wf.msc. The default configuration blocks most inbound traffic and allows outbound traffic. Review the inbound rules and disable any rules for services you are not using. Create specific inbound rules for the ports your applications need and set the default inbound action to block.

User Account Security

How you manage user accounts on your server directly impacts its security. Every unnecessary account is a potential entry point for an attacker.

Use Sudo Instead of Root

Never run services or perform daily tasks as the root user. Create a regular user account and add it to the sudo group:

adduser deployer
usermod -aG sudo deployer

Use this account for all server administration. When you need root privileges, use sudo before the command. This creates an audit trail of privileged actions and limits the damage if the account is compromised.

Remove Unnecessary Accounts

Audit the user accounts on your server regularly. Remove any accounts that are no longer needed:

# List all users with login shells
grep -v '/nologin\|/false' /etc/passwd

# Remove an unnecessary user
sudo userdel -r olduser

Every active account is an attack surface. If a former team member's account still exists with their old password, it is a vulnerability waiting to be exploited.

Enforce Strong Passwords

If you must use password authentication for any service, enforce strong password policies. Install the libpam-pwquality module on Linux:

sudo apt install libpam-pwquality

Configure minimum password requirements in /etc/security/pwquality.conf:

minlen = 12
minclass = 3
maxrepeat = 3

This requires passwords to be at least 12 characters long, contain at least 3 character classes (uppercase, lowercase, numbers, symbols), and have no more than 3 consecutive repeated characters.

Software Updates and Patch Management

Unpatched software is one of the most common attack vectors. When a vulnerability is discovered in a software package, the vendor releases a patch. Attackers reverse-engineer the patch to understand the vulnerability and then scan the internet for servers that have not applied the update. The window between a patch release and widespread exploitation can be as short as hours.

Automatic Security Updates on Ubuntu and Debian

Enable unattended upgrades to automatically install security patches:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

This installs security updates automatically as they are released. Your server stays patched without manual intervention. Non-security updates that might break compatibility are not installed automatically.

Automatic Updates on AlmaLinux and Rocky Linux

Use dnf-automatic to enable automatic security updates:

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer

Configure /etc/dnf/automatic.conf to apply only security updates if you want to avoid non-security package changes.

Windows Server Updates

Windows Server Update Services (WSUS) or Windows Update handles patching on Windows servers. Configure automatic updates through Group Policy or Windows Settings. Schedule updates during maintenance windows to avoid unexpected reboots during peak traffic. Critical security updates should be applied as soon as possible regardless of schedule.

Update Your Application Stack

Operating system updates are not enough. Your web server, application server, database, programming language runtime, and application dependencies all need regular updates. Use package managers to keep everything current:

# Update system packages
sudo apt update && sudo apt upgrade -y

# Update Node.js packages
npm audit fix

# Update Python packages
pip install --upgrade -r requirements.txt

# Update PHP Composer packages
composer update

Run dependency audits regularly to identify known vulnerabilities in your application's third-party packages.

Fail2Ban: Automated Intrusion Prevention

Fail2Ban monitors log files for repeated failed authentication attempts and automatically bans the offending IP addresses by adding firewall rules. It is the most effective automated defense against brute force attacks on SSH, web applications, and other services.

Install Fail2Ban:

sudo apt install fail2ban

Create a local configuration file:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Configure the SSH jail in /etc/fail2ban/jail.local:

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

This configuration bans any IP address that fails SSH authentication 3 times within 10 minutes. The ban lasts for 1 hour. Fail2Ban adds an iptables rule that drops all traffic from the banned IP.

Start and enable Fail2Ban:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Check the status and see banned IPs:

sudo fail2ban-client status sshd

Fail2Ban supports jails for Nginx, Apache, Postfix, Dovecot, and many other services. Each jail monitors a specific log file and bans IPs based on patterns you define.

SSL and TLS Encryption

Every connection to your server that transmits data should be encrypted with TLS. Unencrypted HTTP traffic can be intercepted and read by anyone on the network path between the client and your server. This includes login credentials, session cookies, personal data, and API keys.

Install a Free SSL Certificate with Let's Encrypt

Let's Encrypt provides free SSL certificates that are trusted by all major browsers. Certbot automates the certificate installation and renewal process:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot automatically configures Nginx to use the SSL certificate and sets up automatic renewal. Certificates are valid for 90 days and renew automatically 30 days before expiration.

Force HTTPS Redirect

After installing SSL, redirect all HTTP traffic to HTTPS so no unencrypted connections are possible:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$server_name$request_uri;
}

Strong TLS Configuration

Disable outdated TLS versions and weak cipher suites. Only TLS 1.2 and TLS 1.3 should be enabled on modern servers:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

TLS 1.0 and TLS 1.1 have known vulnerabilities and are no longer supported by modern browsers. Disabling them eliminates downgrade attacks.

File Permissions and Ownership

Incorrect file permissions are a common security vulnerability. If application files are world-writable, any process on the server can modify them. If configuration files containing database passwords are world-readable, any user on the server can read them.

The Principle of Least Privilege

Every file and directory should have the minimum permissions necessary for its function. Web application files should be owned by the application user and readable by the web server user. Configuration files with sensitive data should be readable only by the application user.

Standard permissions for a web application:

# Application files: owner can read/write, group can read, others nothing
chmod 750 /var/www/yourapp
chmod 640 /var/www/yourapp/.env

# Set ownership to the application user
chown -R deployer:www-data /var/www/yourapp

The .env file containing database credentials and API keys should never be readable by other users. Setting it to 640 means only the owner can read and write it, the group can read it, and everyone else has no access.

Secure Temporary Directories

The /tmp directory is world-writable by default, which attackers exploit to store and execute malicious scripts. Mount /tmp with the noexec option to prevent execution of files in the temporary directory:

# Add to /etc/fstab
tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev 0 0

This prevents any file in /tmp from being executed, blocking a common attack technique.

Database Security

Your database contains the most valuable data on your server. A compromised database means stolen user credentials, personal information, financial data, and business records.

Bind to Localhost

Unless your database needs to accept connections from other servers, configure it to listen only on localhost. This means only applications running on the same server can connect to the database. External connections are impossible.

For MySQL, edit /etc/mysql/mysql.conf.d/mysqld.cnf:

bind-address = 127.0.0.1

For PostgreSQL, edit /etc/postgresql/16/main/postgresql.conf:

listen_addresses = 'localhost'

Use Strong Database Passwords

The database root password and application database user passwords should be long, random strings. Never use the same password for the database that you use for SSH or any other service. Generate a random password:

openssl rand -base64 32

Create Application-Specific Database Users

Never connect your application to the database using the root account. Create a dedicated database user with only the permissions your application needs:

CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'strong_random_password';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;

This user can read and write data in the application database but cannot create or drop tables, create other users, or access other databases. If the application is compromised, the attacker's database access is limited to what the application user can do.

Regular Database Backups

Backups are your last line of defense. If everything else fails and your server is compromised, a recent backup lets you restore your data on a clean server. Automate daily backups and store them off-server:

# MySQL backup
mysqldump -u root -p --all-databases | gzip > /backup/mysql_$(date +%Y%m%d).sql.gz

# PostgreSQL backup
pg_dumpall | gzip > /backup/postgres_$(date +%Y%m%d).sql.gz

Transfer backups to a separate server or cloud storage. A backup stored on the same server that gets compromised is not a backup.

Monitoring and Logging

You cannot defend against what you cannot see. Monitoring and logging give you visibility into what is happening on your server so you can detect and respond to security incidents.

Monitor Authentication Logs

Authentication logs record every login attempt, successful or failed. On Linux, these logs are in /var/log/auth.log on Ubuntu and Debian or /var/log/secure on AlmaLinux and Rocky Linux.

Check for failed login attempts:

grep "Failed password" /var/log/auth.log | tail -20

A sudden spike in failed login attempts indicates a brute force attack in progress. If Fail2Ban is configured, it handles this automatically. If not, you need to block the attacking IP manually.

Monitor Disk Usage

Attackers sometimes fill server disks with log files or downloaded data, causing services to crash. Monitor disk usage and set up alerts:

df -h

Set up a cron job that alerts you when disk usage exceeds 80 percent. Running out of disk space can crash your database, prevent logging, and make the server unstable.

Monitor Running Processes

Regularly check what processes are running on your server. Unfamiliar processes could indicate a compromise:

ps aux --sort=-%mem | head -20

Look for processes running as unexpected users, processes with high CPU or memory usage that you do not recognize, and processes listening on ports you did not configure.

Centralized Logging

For servers running critical applications, send logs to a centralized logging service. If an attacker compromises your server, one of the first things they do is delete the local logs to cover their tracks. Logs stored on a separate system cannot be tampered with from the compromised server.

Additional Security Measures

Disable Unnecessary Services

Every running service is a potential attack surface. List all services listening on network ports:

sudo ss -tlnp

If you see services you do not need, disable them:

sudo systemctl disable --now service_name

A minimal server running only SSH, your web server, and your application server has a much smaller attack surface than a server running mail services, FTP, database listeners on public interfaces, and other unnecessary services.

Enable Two-Factor Authentication

For critical servers, add two-factor authentication to SSH using Google Authenticator or a similar TOTP application. This adds a time-based one-time password requirement on top of SSH key authentication, meaning an attacker needs both your private key and physical access to your authenticator device.

Use a VPN for Server Management

Instead of exposing SSH to the public internet, restrict SSH access to a VPN. Only users connected to the VPN can reach the SSH port. This eliminates SSH brute force attacks entirely because the port is not visible from the public internet.

Regular Security Audits

Schedule periodic security audits where you review user accounts, firewall rules, running services, installed packages, file permissions, and log files. Automated tools like Lynis can scan your Linux server and identify security issues:

sudo apt install lynis
sudo lynis audit system

Lynis checks hundreds of security settings and provides a hardening score with specific recommendations for improvement.

Server Security Checklist

Use this checklist when setting up a new server or auditing an existing one. Every item on this list should be completed for a properly secured server.

SSH key authentication enabled. Password authentication disabled in sshd_config. All users authenticate with SSH keys.

Root login disabled. PermitRootLogin set to no. Administration done through sudo.

SSH port changed. SSH moved from port 22 to a non-standard port.

Firewall configured. Default deny policy with only necessary ports open.

Fail2Ban installed. Monitoring SSH and web server logs for brute force attempts.

Automatic security updates enabled. Unattended-upgrades or dnf-automatic configured.

SSL certificates installed. All web traffic encrypted with TLS 1.2 or 1.3.

HTTP redirected to HTTPS. No unencrypted web traffic possible.

Database bound to localhost. No external database connections unless explicitly needed.

Strong passwords everywhere. Database, application, and system passwords are long random strings.

File permissions reviewed. Sensitive files not world-readable. Application files owned by correct user.

Unnecessary services disabled. Only required services running and listening on network ports.

Backups configured. Automated daily backups stored off-server.

Logs monitored. Authentication logs and system logs reviewed regularly or sent to centralized logging.

Securing Your BlastVPS Server

BlastVPS Linux VPS plans include full root access so you can implement every security practice in this guide. You have complete control over SSH configuration, firewall rules, user accounts, and installed software from the moment your server is deployed.

All BlastVPS servers include network-level DDoS protection that filters volumetric attacks before they reach your server. This works alongside your server-level firewall to provide two layers of defense. The network-level protection handles large-scale attacks while your iptables or UFW configuration handles application-level filtering.

For dedicated server deployments, BlastVPS dedicated servers include IPMI and remote console access. If you accidentally lock yourself out with a firewall misconfiguration, you can access the server console directly without SSH to fix the issue.

If you prefer Windows, BlastVPS Windows RDP plans come with Windows Defender Firewall pre-configured and full administrator access for additional security hardening.

Frequently Asked Questions

What is server hardening?

Server hardening is the process of reducing a server's attack surface by disabling unnecessary services, configuring strict access controls, applying security patches, setting up firewalls, and implementing monitoring. A hardened server has the minimum number of services running, the strictest possible access policies, and multiple layers of defense against common attacks. The goal is to make the server as difficult to compromise as possible.

What is the most important server security step?

Enabling SSH key authentication and disabling password authentication is the single most impactful security step for a Linux server. Brute force attacks against SSH are the most common automated attack on the internet. Switching to key-based authentication makes these attacks completely ineffective because there is no password to guess.

How often should I update my server?

Security updates should be applied as soon as they are released. Enable automatic security updates so critical patches are installed without delay. Non-security updates can be applied on a weekly or monthly schedule during maintenance windows. The longer you wait to apply a security patch, the more time attackers have to exploit the vulnerability.

Do I need a firewall if my hosting provider has DDoS protection?

Yes. DDoS protection and a server firewall serve different purposes. DDoS protection filters volumetric network attacks before they reach your server. A server firewall controls which ports and services are accessible and blocks unauthorized access attempts. You need both for comprehensive security. DDoS protection without a firewall leaves your services exposed. A firewall without DDoS protection leaves your server vulnerable to being overwhelmed by traffic.

How do I know if my server has been compromised?

Signs of a compromised server include unfamiliar processes running in the background, unexpected network connections, modified system files, new user accounts you did not create, unusual CPU or memory usage, and gaps in log files where entries have been deleted. Run regular security audits with tools like Lynis, monitor your logs, and investigate any anomalies immediately.

What is the difference between a firewall and Fail2Ban?

A firewall is a static set of rules that allows or blocks traffic based on ports, protocols, and IP addresses. Fail2Ban is a dynamic intrusion prevention system that monitors log files and automatically adds temporary firewall rules to ban IP addresses that show malicious behavior like repeated failed login attempts. A firewall defines your baseline security policy. Fail2Ban enforces it by reacting to attacks in real time.

Should I use a VPN to access my server?

Using a VPN to access your server adds an extra layer of security by hiding your SSH port from the public internet. Only users connected to the VPN can reach the server's management ports. This eliminates automated brute force attacks entirely. For critical production servers handling sensitive data, VPN access is strongly recommended. For personal projects and development servers, SSH key authentication with Fail2Ban provides sufficient security.