Server Hardening Basics: SSH, Firewalls, Automatic Updates, and Secure Defaults

Your Server Is a Target the Moment It Goes Online

The second your server gets a public IP address, automated scanners start probing it. Bots sweep the internet continuously, looking for open ports, default credentials, unpatched software, and misconfigured services. This is not paranoia — it is measurable reality. Check your SSH logs after a fresh server deployment, and you will see hundreds of brute-force login attempts within the first hour.

Server hardening is the process of reducing the attack surface so that the only doors into your server are the ones you deliberately opened, and those doors have proper locks. This guide covers the essentials: SSH configuration, firewall setup, automatic security updates, and secure defaults. It is written for hosting customers who manage their own VPS or dedicated servers and want a solid security baseline without hiring a full-time security engineer.

SSH Hardening: Your Most Important Access Point

SSH is how you manage your server remotely. It is also the single most attacked service on any internet-facing machine. Here is how to lock it down properly.

Disable Password Authentication

Password-based SSH authentication is the most common entry point for attackers. Brute-force tools can try thousands of password combinations per minute. The fix is simple: switch to SSH key-based authentication and disable password login entirely.

Generate an SSH key pair on your local machine. Copy the public key to the server's ~/.ssh/authorized_keys file. Then edit /etc/ssh/sshd_config and set PasswordAuthentication no and ChallengeResponseAuthentication no. Restart the SSH daemon. From this point forward, only someone with the matching private key can log in.

Disable Root Login

Logging in directly as root over SSH is unnecessary and dangerous. Create a regular user account, add it to the sudo group, and set PermitRootLogin no in your SSH configuration. Administrative tasks should be performed using sudo from a named account — this creates an audit trail and limits the blast radius of a compromised session.

Change the Default Port

SSH runs on port 22 by default, and that is exactly where automated scanners look first. Changing the port to something non-standard — say, port 2222 or another high-numbered port — does not make SSH more secure in a technical sense, but it dramatically reduces the volume of automated brute-force noise. Think of it as removing the welcome mat from the front door.

Update the Port directive in sshd_config, then make sure your firewall allows the new port before restarting SSH. Test the new configuration from a separate terminal before closing your current session — locking yourself out is an embarrassing but avoidable mistake.

Use Fail2Ban

Fail2Ban monitors log files for failed authentication attempts and automatically bans offending IP addresses by adding firewall rules. For SSH, a typical configuration bans an IP after five failed login attempts within ten minutes, with a ban duration of one hour. This effectively shuts down brute-force attacks without affecting legitimate users.

Install Fail2Ban, enable the SSH jail, and verify it is running. Check the ban list periodically with fail2ban-client status sshd to confirm it is working as expected.

Firewall Configuration: Allow What You Need, Block Everything Else

A firewall is your server's first line of defense at the network level. The principle is straightforward: deny all incoming traffic by default, then explicitly allow only the ports and protocols your services require.

Essential Rules

For a typical web server, you need to allow:

• SSH on your chosen port (from specific IP ranges if possible)
• HTTP on port 80 (for Let's Encrypt challenges and redirects)
• HTTPS on port 443 (for encrypted web traffic)

Everything else should be blocked. If your server runs additional services — a database, a message queue, an API — those ports should only be open to the specific IP addresses that need access, not to the entire internet. A database port open to the world is an invitation to compromise.

UFW or iptables

UFW (Uncomplicated Firewall) is a user-friendly frontend for iptables that works well for most hosting scenarios. Setting up rules is intuitive: ufw default deny incoming, ufw default allow outgoing, ufw allow 443/tcp, ufw enable. For more granular control, iptables gives you full power over packet filtering, NAT, and connection tracking.

Whichever tool you use, document your firewall rules and review them periodically. Stale rules — ports left open for a service you decommissioned months ago — are a common and unnecessary risk.

Automatic Security Updates

Unpatched software is one of the most exploited vulnerability categories. The gap between a public vulnerability disclosure and active exploitation has shortened to days, sometimes hours. Manual patching workflows are too slow for security-critical updates.

Most Linux distributions offer automatic security update mechanisms. On Debian and Ubuntu, the unattended-upgrades package handles this. Install it, configure it to apply security updates automatically, and enable email notifications so you know when patches are applied.

Automatic updates should cover the operating system and its core packages. Application-level updates — your CMS, frameworks, or custom code — typically need more careful testing and should follow a controlled deployment process. But for OS-level security patches, the risk of not updating far outweighs the risk of an occasional compatibility issue.

Secure Defaults: The Details That Matter

Remove Unnecessary Services

A fresh server installation often includes services you do not need: FTP, Telnet, mail daemons, NFS. Each running service is a potential attack vector. Audit the services running on your server with systemctl list-units --type=service, and disable anything that is not essential. If you are not using FTP, uninstall it. If you are not running a mail server, stop and disable the mail daemon.

File Permissions and Ownership

Ensure that sensitive files — configuration files, private keys, database credentials — have restrictive permissions. A common mistake is leaving configuration files world-readable, which means any user or process on the server can read them. Set permissions to 600 (owner read/write only) for sensitive files and 700 for sensitive directories.

Limit User Accounts

Every user account on your server is a potential entry point. Remove default accounts that are not in use. Ensure that service accounts (for web servers, databases, etc.) have no login shell and cannot be used for interactive sessions. Use strong, unique passwords for any remaining password-authenticated accounts, and prefer SSH keys wherever possible.

Enable Audit Logging

Logging is not a prevention measure — it is a detection and investigation tool. Ensure that authentication events, sudo usage, and service restarts are logged and that logs are rotated to prevent disk space issues. Consider shipping logs to a remote syslog server or logging service so that an attacker who compromises the server cannot easily erase their tracks.

Regular Security Audits

Hardening is not a one-time event. Schedule quarterly security reviews where you check for unused services, stale user accounts, outdated software, and firewall rule drift. Tools like Lynis provide automated security auditing and generate reports with specific recommendations for your configuration.

Run vulnerability scanners against your server's public-facing services periodically. Compare the results against your previous scan to catch regressions. A server that was secure six months ago may not be secure today if new software was installed, configurations were changed, or new vulnerabilities were disclosed.

Wrapping Up

Server hardening is the foundation of hosting security. It is not exciting, and it does not generate revenue directly, but it prevents the kind of incidents that cost far more than the time invested in prevention. Disable password authentication, configure your firewall properly, automate security patches, remove unnecessary services, and review your posture regularly. These are the basics. They are also what separates a professionally managed server from an easy target. Start here, build the habit, and layer on more advanced controls as your environment grows.