Server Security Hardening for Canadian VPS and Dedicated Servers

When a Canadian hosting provider hands you root access to a fresh VPS, the server is a starting point, not a finished product. A default Ubuntu or AlmaLinux installation has open ports, weak default configurations, and no application-level protections. An internet-facing server in this state will be found by automated scanners within hours. This guide covers the essential hardening steps for Canadian business servers before you put any workload on them.

Create a non-root user with sudo access immediately

The first thing to do on any fresh Linux server is create a regular user account with sudo privileges and disable direct root login over SSH. Logging in as root by default is dangerous because every command you run has full system privileges, and any credential compromise gives the attacker immediate complete access. Create a user account, add it to the sudo group, verify you can log in as that user and run sudo commands, then disable root SSH login.

adduser gotekkyuser
usermod -aG sudo gotekkyuser

Verify you can log in as gotekkyuser and execute a sudo command before proceeding. Locking yourself out of root before verifying sudo access works is a common and painful mistake.

SSH hardening: keys, port changes, and disabling passwords

Password-based SSH authentication is vulnerable to brute-force attacks. Automated scanners attempt hundreds of password combinations per second against any server with SSH exposed on port 22. Switch to key-based authentication and disable password login. Generate an SSH key pair on your local machine if you do not have one. Copy the public key to the server's authorized_keys file for your user account. Then edit /etc/ssh/sshd_config and set PasswordAuthentication to no, PermitRootLogin to no, and consider changing the SSH port from 22 to a high-numbered port between 1024 and 65535. Changing the port does not make the server more secure against a determined attacker, but it dramatically reduces the volume of automated scan traffic and the resulting log noise. Reload SSH with systemctl reload sshd after making these changes.

Configure a firewall with UFW

UFW (Uncomplicated Firewall) is the standard firewall management tool for Ubuntu-based servers. AlmaLinux and Rocky Linux use firewalld. Both work well. The principle is the same: block all inbound traffic by default and explicitly allow only the ports your server needs. For a web server, that typically means SSH (on whatever port you chose), HTTP (80), and HTTPS (443). For a mail server, add 25, 587, and 993. For a database server accessible only from your web server, the database port should be accessible only from the web server's IP, not from the public internet.

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp     # or your custom SSH port
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Check the status with ufw status verbose after enabling. Confirm that only the ports you intend to be open are listed as allowed.

Install and configure fail2ban

Fail2ban monitors log files for repeated authentication failures and temporarily blocks the source IP with an iptables rule. Without fail2ban, a brute-force attack against SSH or the WordPress login endpoint runs unimpeded. With fail2ban, an IP that fails authentication five times within ten minutes gets blocked for thirty minutes by default, after which it can try again. This does not stop determined attackers with large IP pools, but it stops the vast majority of automated credential stuffing attacks that run from single IPs or small IP ranges.

Install fail2ban through the system package manager. Create a local configuration file at /etc/fail2ban/jail.local that defines which services to monitor and the action thresholds. At minimum, enable the sshd jail. For WordPress sites, enable the nginx-http-auth or apache-auth jail depending on your web server, and consider a custom jail for WordPress login failures if your web server logs them distinctly.

Enable unattended security updates

The most common vector for server compromise is unpatched software. Security vulnerabilities in the Linux kernel, OpenSSL, and system packages are published regularly. Without automatic updates, your server falls behind on patches the moment you stop actively maintaining it. On Ubuntu-based systems, unattended-upgrades handles this. Configure it to install security updates automatically by enabling the appropriate APT source in /etc/apt/apt.conf.d/50unattended-upgrades. On AlmaLinux, dnf-automatic serves the same purpose. For production servers, automatic updates carry a small risk of breaking compatibility with application dependencies, but this risk is lower than the risk of running an unpatched server. At minimum, configure automatic notification so you know when updates are available even if you review them before applying.

What PIPEDA and Law 25 expect from server security

PIPEDA's safeguards principle requires that personal information be protected with security measures appropriate to its sensitivity. Law 25 requires appropriate administrative, technical, and physical security measures. Neither law specifies exact technical configurations, but both create a standard of reasonableness. A Canadian business server storing personal information that has never been hardened, runs outdated software, and uses password authentication for SSH would have difficulty demonstrating appropriate safeguards following a breach. The hardening steps above are standard practice and their absence is difficult to justify in a compliance context.