UFW Firewall Rules for Home Servers: Simple Rules That Actually Make Sense

UFW is one of those tools that looks almost too simple.

You type a few commands, allow SSH, deny incoming traffic, enable the firewall, and suddenly your Linux home server feels more serious.

But then the real questions start:

• Should I allow a port from everywhere or only from my LAN?
• Should Docker services be exposed?
• Should outgoing traffic be blocked?
• How do I avoid locking myself out of SSH?
• What rules actually make sense for a home server?

This post is a practical guide to UFW firewall rules for home servers. Not enterprise firewall theory. Not copy-paste paranoia. Just useful rules for a Linux box running at home, probably doing too many things, and hopefully not exposing random ports to the whole internet.

UFW means Uncomplicated Firewall. Ubuntu describes it as the default firewall configuration tool, designed to make host-based firewall management easier. By default, UFW is usually disabled until you enable it.

That last part matters.

Installing Linux does not automatically mean your host firewall is active.

1. Before touching UFW, check what is listening

Do not start by adding firewall rules blindly. First, see what the server is actually exposing.

ss -tulpn

You may see something like:

Netid State  Local Address:Port
tcp   LISTEN 0.0.0.0:22
tcp   LISTEN 0.0.0.0:8080
tcp   LISTEN 127.0.0.1:5432
tcp   LISTEN 0.0.0.0:32400

Now ask:

• Should SSH be reachable?
• Should port 8080 be reachable from the whole LAN?
• Should PostgreSQL only listen locally?
• Should Plex/Jellyfin/whatever be reachable from every device?

A firewall rule should answer a real question. If you do not know what a port is doing, investigate before allowing it.

Useful commands:

sudo ss -tulpn
sudo lsof -i -P -n
systemctl --type=service --state=running

If you find a service you do not need, removing it is better than firewalling around it.

The best firewall rule is the one you do not need because the service is not running.

2. Install UFW

On Ubuntu, Debian, Linux Mint and similar systems:

sudo apt update
sudo apt install ufw

Check status:

sudo ufw status verbose

If it says inactive, that is normal on many systems.

Status: inactive

Do not enable it yet if you are connected over SSH. First, allow SSH.

3. The safe basic setup

This is the classic safe starting point for a home server:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

What this does:

• blocks new incoming connections by default;
• allows the server to make outgoing connections;
• allows SSH so you do not lock yourself out;
• enables the firewall.

For most home servers, this is already a big improvement.

Typical result:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW IN    Anywhere
OpenSSH (v6)               ALLOW IN    Anywhere (v6)

If your SSH runs on a custom port, allow that port before enabling UFW:

sudo ufw allow 2222/tcp

Then enable:

sudo ufw enable

Important: if you are connected by SSH, keep one working SSH session open while testing from another terminal.

4. Better SSH rule: allow SSH only from your LAN

If the server is only used at home, SSH does not need to be available to every possible network.

Instead of this:

sudo ufw allow OpenSSH

Use a LAN-restricted rule:

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

Change 192.168.1.0/24 to your real home network.

Common home LAN ranges:

192.168.1.0/24
192.168.0.0/24
10.0.0.0/24
10.0.1.0/24

You can check your server IP with:

ip a

Or:

hostname -I

If your computer is on 192.168.1.50 and the server is on 192.168.1.20, then 192.168.1.0/24 probably covers your LAN.

After adding the LAN rule, check numbered rules:

sudo ufw status numbered

If you still have the old open SSH rule, remove it carefully.

Example:

sudo ufw delete 1

Always check the number before deleting.

5. Allow a web service only on the LAN

Let’s say your home server runs a dashboard, test app, media service or internal web tool on port 8080.

Bad lazy rule:

sudo ufw allow 8080/tcp

Better home server rule:

sudo ufw allow from 192.168.1.0/24 to any port 8080 proto tcp

This means devices on your local network can access it, but random external traffic cannot.

Another example for a local HTTPS service:

sudo ufw allow from 192.168.1.0/24 to any port 443 proto tcp

And for a local HTTP service:

sudo ufw allow from 192.168.1.0/24 to any port 80 proto tcp

Again, do not allow ports just because a tutorial says so. Allow them because you know what is listening there.

6. Allow access from one trusted machine only

Sometimes the whole LAN does not need access. Maybe only your laptop should SSH into the server.

Example:

sudo ufw allow from 192.168.1.50 to any port 22 proto tcp

This allows SSH only from 192.168.1.50.

This is useful for:

• SSH administration;
• database access;
• admin panels;
• backup jobs;
• monitoring systems.

Example for allowing a backup machine to access rsync or another service:

sudo ufw allow from 192.168.1.60 to any port 873 proto tcp

Specific is better than broad.

7. Allow common home server services

Here are some common examples. Do not paste all of them. Use only what your server actually runs.

SSH

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

HTTP

sudo ufw allow from 192.168.1.0/24 to any port 80 proto tcp

HTTPS

sudo ufw allow from 192.168.1.0/24 to any port 443 proto tcp

Jellyfin default port

sudo ufw allow from 192.168.1.0/24 to any port 8096 proto tcp

Plex default port

sudo ufw allow from 192.168.1.0/24 to any port 32400 proto tcp

Grafana default port

sudo ufw allow from 192.168.1.0/24 to any port 3000 proto tcp

Prometheus default port

sudo ufw allow from 192.168.1.0/24 to any port 9090 proto tcp

Samba / Windows file sharing

For Samba, only allow trusted LAN clients.

sudo ufw allow from 192.168.1.0/24 to any port 137 proto udp
sudo ufw allow from 192.168.1.0/24 to any port 138 proto udp
sudo ufw allow from 192.168.1.0/24 to any port 139 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 445 proto tcp

NFS

NFS can be tricky because it may use multiple services depending on configuration. Keep it LAN-only and avoid exposing it outside your network.

sudo ufw allow from 192.168.1.0/24 to any port 2049 proto tcp

PostgreSQL

Usually this should not be open to the whole LAN unless you really need it.

sudo ufw allow from 192.168.1.50 to any port 5432 proto tcp

MySQL / MariaDB

sudo ufw allow from 192.168.1.50 to any port 3306 proto tcp

If the database is only used by applications on the same server, do not open it with UFW at all. Bind it to localhost instead.

8. Deny a specific IP address

If a device on your LAN is being noisy, weird or compromised, you can block it.

sudo ufw deny from 192.168.1.99

Or block it from a specific service:

sudo ufw deny from 192.168.1.99 to any port 22 proto tcp

Check:

sudo ufw status numbered

Remember that rule order matters. UFW processes rules in order, so a broad allow rule before a deny rule can give you surprising results.

9. Use numbered rules before deleting anything

Never delete firewall rules blindly.

Show numbered rules:

sudo ufw status numbered

Example output:

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    192.168.1.0/24
[ 2] 8080/tcp                   ALLOW IN    192.168.1.0/24
[ 3] 32400/tcp                  ALLOW IN    192.168.1.0/24

Delete a rule by number:

sudo ufw delete 2

Then check again:

sudo ufw status numbered

When deleting multiple rules, delete one at a time and re-check, because rule numbers change after deletion.

10. Rate limit SSH

UFW has a simple rate limit feature.

For SSH:

sudo ufw limit 22/tcp

Or, if using a custom SSH port:

sudo ufw limit 2222/tcp

This can help slow down repeated connection attempts.

However, rate limiting is not a replacement for better SSH hardening. Use SSH keys, disable root login and avoid password authentication when possible.

A better SSH setup usually looks like:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

UFW protects the door. SSH configuration decides how strong the lock is.

11. UFW logging

Logging is useful, but too much logging becomes noise.

Enable basic logging:

sudo ufw logging on

Set low logging:

sudo ufw logging low

Check logs with:

sudo journalctl -k | grep UFW

Or:

sudo grep UFW /var/log/syslog

Depending on your distribution, logs may appear in different places.

Disable logging if it becomes too noisy:

sudo ufw logging off

For a normal home server, I usually keep logging low or only enable it temporarily while testing.

12. Docker warning: UFW may not protect what you think

This is important.

If you use Docker, be careful. Docker can publish ports using its own iptables rules, and that can bypass the simple mental model of “UFW blocks incoming traffic”.

Example:

docker run -p 8080:80 nginx

You may think UFW is blocking port 8080, but Docker may have made it reachable depending on your setup.

Check what Docker exposes:

docker ps --format "table {{.Names}}\t{{.Ports}}"

Safer Docker binding for LAN or local-only use:

ports:
  - "127.0.0.1:8080:80"

This binds the container to localhost only.

For LAN-only, you can bind to the server’s LAN IP:

ports:
  - "192.168.1.20:8080:80"

Then control access with a reverse proxy or firewall design you actually understand.

The main point: after starting Docker containers, test from another machine.

nmap -p 1-10000 server-ip

Or at least:

nc -vz server-ip 8080

Do not assume. Test.

13. Should you block outgoing traffic?

By default, many UFW setups use:

sudo ufw default allow outgoing

For a home server, that is usually practical.

Blocking outgoing traffic can improve control, but it also creates maintenance work. You may need to allow DNS, HTTP, HTTPS, NTP, package updates, email, backup traffic and more.

If you want a stricter setup, you could do:

sudo ufw default deny outgoing

Then allow basics:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

But be careful. If you block outgoing traffic without planning, you can break updates, DNS, time sync, containers and monitoring.

My home server recommendation:

• keep outgoing allowed for general-purpose home servers;
• deny outgoing only for special locked-down machines;
• use logs and monitoring if you are worried about suspicious outbound traffic.

14. IPv6: do not forget it exists

If your network has IPv6, your server may be reachable in ways you did not expect.

Check UFW IPv6 support:

sudo nano /etc/default/ufw

Look for:

IPV6=yes

If IPv6 is enabled on your network, UFW should manage IPv6 rules too.

Check status:

sudo ufw status verbose

You may see rules ending with:

(v6)

Example:

OpenSSH (v6) ALLOW IN Anywhere (v6)

If you do not understand your IPv6 exposure, do not ignore it. Either configure it properly or disable it deliberately at the network/system level after understanding the impact.

15. A simple UFW ruleset for a typical home server

Let’s say the server does this:

• SSH admin from LAN;
• Jellyfin from LAN;
• Grafana from one admin laptop;
• no public internet services.

Example rules:

sudo ufw reset

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 8096 proto tcp
sudo ufw allow from 192.168.1.50 to any port 3000 proto tcp

sudo ufw logging low
sudo ufw enable
sudo ufw status verbose

This is a clean home server firewall:

• SSH is LAN-only;
• Jellyfin is LAN-only;
• Grafana is admin-laptop-only;
• everything else incoming is blocked.

Simple. Understandable. Easy to audit later.

16. A UFW ruleset for a public web server

If your home server really needs to expose a public website, the rules change.

Example:

sudo ufw reset

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable
sudo ufw status verbose

This allows:

• SSH only from LAN;
• HTTP from anywhere;
• HTTPS from anywhere.

If you expose something publicly, keep it patched. Use HTTPS. Avoid exposing admin panels. Do not expose databases. Do not expose random Docker ports. Do not expose “temporary” test services and then forget them for two years.

Temporary firewall rules have a magical ability to become permanent.

17. A UFW ruleset for a private VPN-style home server

A nicer setup is to avoid exposing many services publicly and use a VPN instead.

For example, expose only WireGuard:

sudo ufw reset

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow 51820/udp
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

sudo ufw enable
sudo ufw status verbose

Then access internal services through the VPN.

This is usually better than exposing SSH, dashboards, file shares and admin tools directly to the internet.

18. Check UFW status properly

Basic status:

sudo ufw status

Verbose status:

sudo ufw status verbose

Numbered rules:

sudo ufw status numbered

Raw rules:

sudo ufw show raw

Listening ports:

sudo ss -tulpn

The firewall status alone is not enough. Always compare:

• what is listening;
• what UFW allows;
• what another machine can actually reach.

19. Test from another machine

Testing locally can lie to you because localhost is not the network.

From another Linux machine:

nc -vz 192.168.1.20 22
nc -vz 192.168.1.20 8080
nc -vz 192.168.1.20 3000

Or scan known ports:

nmap -p 22,80,443,3000,8096,9090,32400 192.168.1.20

If something is reachable that should not be reachable, fix it.

If something is blocked that should work, check:

• UFW rules;
• service bind address;
• Docker port publishing;
• router firewall;
• VLAN rules;
• IPv6 exposure.

20. Reset UFW if things get messy

If your rules become a disaster, you can reset UFW.

Warning: this removes existing UFW rules.

sudo ufw reset

Then rebuild carefully:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

Resetting is not failure. Sometimes it is cleaner than trying to understand three years of random firewall experiments.

21. My recommended UFW checklist for home servers

Here is the short version.

# Check listening services
sudo ss -tulpn

# Install UFW
sudo apt update
sudo apt install ufw

# Safe defaults
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH from LAN only
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

# Allow only the services you really need
sudo ufw allow from 192.168.1.0/24 to any port 8096 proto tcp

# Enable logging
sudo ufw logging low

# Enable firewall
sudo ufw enable

# Check rules
sudo ufw status verbose
sudo ufw status numbered

Replace the network and ports with your real setup.

22. Common mistakes

Allowing too much

sudo ufw allow 8080

This may allow access from anywhere that can reach the server. Prefer LAN-restricted rules where possible.

Forgetting Docker

Docker can expose ports in ways that do not match your expectations. Always check with docker ps and test from another machine.

Locking yourself out of SSH

Always allow SSH before enabling UFW, and keep a working session open while testing.

Ignoring IPv6

If IPv6 is active, make sure your firewall policy covers it too.

Never reviewing old rules

A firewall rule added for a temporary test in 2022 should not still be there in 2026 unless it is still needed.

Final thoughts

UFW is simple, but simple does not mean useless.

For a Linux home server, a good UFW setup usually means:

• deny incoming by default;
• allow outgoing by default;
• allow SSH only from trusted networks;
• allow services only from the devices that need them;
• avoid exposing admin panels to the internet;
• test from another machine;
• review rules occasionally;
• watch out for Docker.

You do not need a complicated firewall to improve a home server.

You need rules that are boring, obvious and easy to understand six months later.

That is the real goal.

Because when something breaks at midnight, you do not want to reverse-engineer your own firewall like it was left behind by an ancient civilization.

FAQ

Is UFW enough for a home server?

For many Linux home servers, yes. UFW is a practical host firewall for allowing and blocking traffic. It is not a replacement for updates, strong SSH settings, backups or good network design.

Should I allow SSH from anywhere?

Usually no. If the server is at home, allow SSH only from your LAN or from a VPN. If SSH must be exposed publicly, use SSH keys, disable root login, disable password login and consider rate limiting.

Should I block outgoing traffic with UFW?

For most home servers, allowing outgoing traffic is simpler and more practical. Blocking outgoing traffic can be useful for locked-down systems, but it requires more maintenance and can break updates, DNS, time sync and containers.

Does UFW work with Docker?

Docker can create its own firewall rules and publish ports in ways that may not match your UFW expectations. Always check exposed Docker ports and test access from another machine.

What is the safest basic UFW setup?

A good basic setup is deny incoming, allow outgoing, allow SSH from your LAN, then allow only the specific ports your server actually needs.