Why Bother Securing a Home Server?

Let’s talk about home server security. Maybe you just turned an old PC into a home server and you’re wondering whether someone out there is already trying to get in. The short answer is yes. Bots scan the internet around the clock looking for SSH on port 22, and a fresh server with default settings can get hit within minutes. You can secure your home server in one afternoon with three free tools: an SSH key, a UFW firewall, and Fail2Ban. I’ll show you how to set up a UFW firewall for your home server, use fail2ban for beginners, and disable password SSH login so bots stop knocking.

Your home server is not safe just because it sits behind your router. A compromised laptop or phone on your Wi-Fi can move sideways and try to log in from inside your network. That’s why home server security starts with the basics on the server itself, not just your router. Honeypot data from 2024 through 2026 consistently shows thousands of login attempts per day on exposed SSH ports. Many come from botnets that don’t care who you are; they just try common usernames like root and admin with a list of weak passwords.

Start with SSH Hardening (Disable Password SSH Login)

The first thing I do on any new home server is make SSH key login work, then turn off password login. This one change stops most brute-force attacks cold because bots don’t have your private key.

If you haven’t made an SSH key before, I walk through the whole process in my SSH beginner’s guide. Here’s the short version from your laptop or desktop:

# Generate an ed25519 key pair on your laptop, not the server
ssh-keygen -t ed25519

# Copy your public key to the server (replace 203.0.113.10 with your real server IP)
ssh-copy-id user@203.0.113.10

One warning: after ssh-copy-id, open a second terminal and log in with your key before you change any settings. If key login doesn’t work yet, do not disable passwords or you will lock yourself out.

Now edit the SSH server config:

# Open the SSH daemon configuration
sudo nano /etc/ssh/sshd_config

# Find these lines, uncomment them, and set the values below
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes

PermitRootLogin prohibit-password blocks the root account from using a password but still allows root login with a key. PasswordAuthentication no disables password login for everyone. PubkeyAuthentication yes makes sure key login stays on. After saving, restart SSH:

# Restart the SSH service to apply changes
sudo systemctl restart ssh

From now on, the only way into your server over SSH is with a key that matches a public key in ~/.ssh/authorized_keys. That’s a huge step for home server security. Bots that try password lists get nothing.

Turn On a UFW Firewall for Your Home Server

A firewall is the next thing you need. It blocks everything by default and only lets in what you explicitly allow. UFW is the friendliest firewall tool on Ubuntu and Debian. It stands for Uncomplicated Firewall, and the name fits.

The golden rule with UFW is: allow SSH before you enable the firewall. If you skip that step, you cut off your own remote access and have to plug in a monitor and keyboard to fix it. Here are the commands:

# Allow SSH first so you don’t lock yourself out
sudo ufw allow 22/tcp

# Set the default policy: block all incoming traffic
sudo ufw default deny incoming

# Allow all outgoing traffic (your server can still fetch updates)
sudo ufw default allow outgoing

# If you run a web server, open ports 80 and 443
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Turn the firewall on
sudo ufw enable

# Verify that the rules are active
sudo ufw status

The default deny incoming line is the most important part. It tells UFW: unless I specifically open a port, drop the packet. When you turn on UFW, it writes firewall rules for you and takes over the lower-level iptables rules, which is fine for home use. After running sudo ufw status, you should see Status: active and your allowed ports listed.

This is your ufw firewall for home server. It takes five minutes and closes every door except the ones you choose.

Stop Brute-Force Attacks with Fail2Ban for Beginners

Fail2Ban is like a bouncer that watches your log files. If the same IP address fails to log in too many times, Fail2Ban temporarily bans that IP. For a beginner, that means bots move on after a few tries instead of hammering your server all night.

Install it on Debian or Ubuntu with:

# Update packages and install fail2ban
sudo apt update
sudo apt install fail2ban

On Alpine Linux, use:

sudo apk add fail2ban

Next, create a local config file so your settings don’t get overwritten by package updates:

# Create a local jail configuration
sudo nano /etc/fail2ban/jail.local

Paste these lines into that file:

[sshd]
enabled = true
bantime = 1h
maxretry = 5
findtime = 10m

maxretry = 5 means an IP gets banned after five failed login attempts. findtime = 10m means those five failures need to happen within ten minutes. bantime = 1h means the IP is banned for one hour. After a few hours, the bot has wasted a lot of time for nothing.

Start Fail2Ban and make it run at boot:

# Start fail2ban now and enable it to start automatically
sudo systemctl enable --now fail2ban

# Check that the sshd jail is running
sudo fail2ban-client status sshd

The status output should show Currently banned: 0 right after setup. When a bot starts trying passwords, that number goes up. For fail2ban for beginners, that’s the quickest feedback loop.

Keep Everything Updated

Old software with known holes is one of the easiest ways for an attacker to get in. Updates close those holes, so I run them every week. On Debian or Ubuntu, update and upgrade like this:

# Update package lists and upgrade installed packages
sudo apt update && sudo apt upgrade

On Alpine Linux:

sudo apk update && sudo apk upgrade

You can also install unattended-upgrades on Debian and Ubuntu to handle security updates automatically. I still like to check manually once a week, so I set a reminder for Sunday at 9:00 AM America/New_York. For a broader look at keeping your box healthy, see my home server maintenance and monitoring guide.

Don't Open Ports Unless You Must

Every port you open on your router is another door for bots to rattle. The fewer open ports, the smaller your attack surface. Start by logging into your home router and turning off UPnP if it’s on. UPnP lets apps open ports automatically, which sounds convenient but means you don’t always know what’s exposed.

Then limit port forwarding to the absolute minimum. If you only need SSH, forward only port 22. If you run a web server, forward 80 and 443. Do not forward a range like 1000-2000 “just in case.” That’s asking for trouble.

Better yet, avoid port forwarding altogether for remote access. I now use Tailscale for almost everything. It gives you an encrypted connection to your server without opening any ports on your router, and it works like a private network for your own devices. I explain the whole setup in my Tailscale beginner’s guide. Once Tailscale is running, you can close the SSH port forward on your router and still log in from your phone or laptop anywhere.

A Simple Checklist for Home Server Security

Here’s the whole home server security checklist you can work through. Once everything is checked, your box is in much better shape than most home servers on the internet.

Task Done?
SSH key login works and password login is disabled
UFW is active with default deny incoming and only needed ports allowed
Fail2Ban sshd jail is running and shows a status
System updates run weekly or unattended-upgrades is installed
Router UPnP is off and port forwarding is minimal (or replaced by Tailscale)

Before I leave you, here’s a quick summary of the three tools and what they do for you:

Tool What it does Why it matters
SSH keys Replace passwords with encrypted key pairs Stops password guessing and password login attacks
UFW Simple firewall that blocks incoming traffic by default Only lets in traffic you explicitly allowed
Fail2Ban Watches logs and bans IPs after repeated failures Reduces brute-force attempts to noise

FAQ

Is my home server really at risk?

Yes, even in 2026. Any device with an internet-facing port gets scanned constantly. Bots don’t care that you’re a person running a home server; they just see an IP address with SSH on port 22 and start trying passwords. I’ve watched fresh servers receive hundreds of login attempts in the first hour after going online. The risk is not theoretical: weak passwords and default settings are how most home boxes get compromised.

Do I need a firewall if my server is behind my router?

Yes. Your router probably already blocks some incoming traffic with NAT, but that’s not a complete firewall for your server. If any device on your local network gets infected—say a laptop or a smart TV—it can try to log in to your server from inside. A host firewall like UFW limits what the server itself will accept from any source, including other devices on your Wi-Fi.

Will UFW lock me out of my server?

It can, but only if you forget to allow SSH before you enable it. That’s why I always run sudo ufw allow 22/tcp first, then sudo ufw default deny incoming, then sudo ufw enable. If you do make a mistake and lock yourself out, you can still plug in a monitor and keyboard, log in locally, and run sudo ufw allow 22/tcp to fix it. I’ve done that once, and it’s annoying but recoverable.

What does fail2ban actually do?

Fail2Ban watches your authentication logs, like /var/log/auth.log on Debian and Ubuntu. When it sees too many failed login attempts from the same IP address within a set time, it adds a firewall rule to ban that IP for a while. For example, with maxretry = 5 and bantime = 1h, a bot that fails five times gets blocked for an hour. It doesn’t replace good passwords or SSH keys, but it cuts down the noise.

Is it safe to open ports for a home server?

It can be safe if you open only what you need and protect the services behind those ports. The safest approach is to open zero ports and use Tailscale for remote access. If you must open a port, make it specific (like 22 for SSH, or 80/443 for a web server), use SSH keys, run Fail2Ban, and close the port when you no longer need it. The more ports you open, the more doors you have to watch.

Next Steps