Server Hardening: Essential Tips to Secure Your VPS Against Cyber Threats

SSH is an important administrative entry point on a Linux server. Password authentication is more exposed to automated guessing attacks than properly managed public-key authentication.

Create a normal administrative account, configure its SSH key, and verify that sudo access works before disabling password or root login.

# /etc/ssh/sshd_config

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
X11Forwarding no

# Optional: restrict SSH to approved accounts
AllowUsers sysadmin_user

# Optional: changing the SSH port can reduce scanning noise.
# It should not be treated as a replacement for key authentication.
Port 2222

Validate the SSH configuration before restarting or reloading the service. Depending on your Linux distribution, the service may be named ssh or sshd.

# Check configuration syntax first
sudo sshd -t

# Debian / Ubuntu commonly use:
sudo systemctl reload ssh

# Some distributions use:
sudo systemctl reload sshd

A public server should expose only the network services it actually needs. A default-deny firewall policy makes that rule easier to enforce.

For a typical web server, this may mean allowing SSH, HTTP, and HTTPS while blocking unsolicited connections to other ports.

sudo ufw default deny incoming
sudo ufw default allow outgoing

# Use the actual SSH port configured on your server
sudo ufw allow 2222/tcp

# Web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable
sudo ufw status verbose

Use Fail2Ban for Repeated Authentication Failures

Fail2Ban reads supported service logs and can temporarily block IP addresses that repeatedly trigger configured authentication rules. It is useful as an additional control, especially for internet-facing services.

sudo apt update
sudo apt install -y fail2ban

sudo systemctl enable --now fail2ban
sudo fail2ban-client status

Create local overrides for the jails you need instead of relying on aggressive defaults. Verify the correct SSH port, log backend, retry threshold, and ban duration for your environment.

Server hardening loses value if vulnerable packages remain unpatched. Review security updates regularly and define how production systems will receive them.

On Debian and Ubuntu systems, unattended upgrades can automate selected package updates. Production administrators should still monitor update results and plan for packages that require service restarts or reboots.

sudo apt update
sudo apt install unattended-upgrades

# Review available configuration before enabling
sudo dpkg-reconfigure -plow unattended-upgrades

Linux provides kernel parameters that influence network behavior. Some can help reduce exposure to unwanted routing behavior or malformed traffic. These settings should be reviewed against the server’s actual role.

Do not paste a large collection of performance-oriented sysctl values into production without testing. Routers, VPN gateways, containers, databases, and ordinary web servers can require different settings.

# Review these values for compatibility with your environment

net.ipv4.tcp_syncookies = 1

# Do not accept source-routed packets
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Reverse path filtering can help on suitable single-homed hosts.
# Multi-homed or asymmetric-routing systems need extra care.
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

net.ipv4.icmp_echo_ignore_broadcasts = 1

After reviewing the configuration, load the settings and check for errors.

sudo sysctl --system

Every unnecessary account, package, listening service, and privileged process expands the attack surface. A production VPS should run only the components required for its workload.

Use ss to identify listening network services. Check whether each exposed port is expected before adding a firewall exception.

sudo ss -tulpn

A database that only serves applications on the same VPS usually does not need to accept connections from the public internet.

Review database accounts, remove unnecessary privileges, use strong credentials, and restrict network exposure. Where appropriate, bind the database service to localhost or a private network interface.

sudo mysql_secure_installation

If remote database access is genuinely required, restrict it with firewall rules and database permissions. Avoid exposing a database port globally unless the architecture specifically requires it and additional controls are in place.

Hardening reduces risk, but monitoring helps you see what is happening after the controls are deployed.

Review SSH authentication failures, unexpected privilege changes, unusual network listeners, security update failures, and repeated Fail2Ban events.

# Debian / Ubuntu
sudo journalctl -u ssh

# Systems may also maintain:
sudo less /var/log/auth.log

# RHEL-family systems may use:
sudo less /var/log/secure

The exact log source depends on the distribution and logging configuration. Centralized monitoring is useful when several servers need to be reviewed from one place.

Security controls cannot guarantee that a server will never be compromised or misconfigured. A recovery plan is therefore part of VPS security.

Keep important backups separate from the production VPS. Define retention, encrypt sensitive backup data where appropriate, and test restoration procedures instead of assuming that a successful backup job is recoverable.