Control what can reach your system. This guide shows how to configure UFW safely on Debian and how to use a firewall strategy that actually reduces attack surface.
UFW (Uncomplicated Firewall) is a Linux firewall manager for netfilter that provides a simpler, more readable way to control host firewall rules.
This guide treats UFW as a security control layer, not just a list of commands. The goal is to expose only what you truly need, from the sources that actually need access.
• A service is only vulnerable if it is reachable
• Firewalls reduce exposure before authentication is ever attempted
• Many systems expose more than their owners realize
• Good firewalling blocks entire classes of low-effort attacks and noisy scanning
If you are managing the system remotely, allow your access path first before enabling UFW.
That usually means SSH, but it may also mean a VPN path or another known administrative service.
UFW supports a remote-management-safe workflow, but the administrator still has to apply it in the right order.
• Debian system
• sudo access
• a clear idea of which services should be reachable
• a second machine for remote testing if possible
sudo apt install -y ufwWhat this does:
Installs the UFW firewall utility.
Why this matters:
UFW provides a manageable way to control Linux host firewall rules without writing raw rule sets by hand.
What to expect:
Debian installs the package, but the firewall remains disabled until you explicitly enable it.
sudo nano /etc/default/ufwMake sure this line is present:
IPV6=yesWhat this does:
Ensures UFW applies firewalling to IPv6 traffic as well as IPv4.
Why this matters:
A lot of people secure IPv4 and accidentally leave IPv6 exposure in place.
What to expect:
On many Debian-style UFW setups, IPv6 is already enabled, but it is worth checking deliberately.
sudo ufw app list
sudo ufw app info OpenSSHWhat this does:
Lists available application profiles and shows the details of the OpenSSH profile.
Why this matters:
Application profiles reduce mistakes and help you confirm exactly what a named rule will allow.
What to expect:
You should see installed profiles like OpenSSH if the related package provides them.
sudo ufw allow OpenSSHWhat this does:
Creates a rule allowing inbound SSH connections.
Why this matters:
If you are connected over SSH and enable UFW without allowing SSH first, you can lock yourself out.
What to expect:
UFW should confirm that the rule was added.
sudo ufw default deny incoming
sudo ufw default allow outgoingWhat this does:
Blocks new inbound traffic unless you explicitly allow it, while still allowing normal outbound traffic.
Why this matters:
This creates a deny-by-default stance, which is one of the most practical and broadly useful firewall baselines for Linux systems.
What to expect:
Existing allowed rules remain, but the default behavior for new inbound traffic becomes deny.
sudo ufw allow 80/tcp
sudo ufw allow 443/tcpWhat this does:
Allows inbound HTTP and HTTPS traffic.
Why this matters:
A firewall should reflect the real role of the system. A web server may need 80 and 443. A private admin box may not need either.
What to expect:
UFW adds one rule per command.
sudo ufw enableWhat this does:
Activates the firewall and enables it on boot.
Why this matters:
Firewall rules do nothing until UFW is enabled.
What to expect:
UFW warns that enabling it may disrupt existing SSH connections if rules are wrong. That warning is there for a reason.
sudo ufw status verboseWhat this does:
Shows active rules and the default policy.
Why this matters:
You want to confirm that the firewall state matches your intended design, not just that UFW is running.
What to expect:
You should see default deny incoming, default allow outgoing, and only the rules you intentionally added.
Prefer source-restricted admin access whenever possible
sudo ufw allow from YOUR-IP to any port 22 proto tcpWhat this does:
Restricts SSH access to a specific source IP instead of allowing it from anywhere.
Why this matters:
Reducing who can even reach a service is stronger than relying only on the service’s own authentication.
Use interface-specific rules when appropriate
sudo ufw allow in on eth0 to any port 80 proto tcpWhat this does:
Limits a rule to a specific interface.
Why this matters:
Multi-interface systems, lab boxes, and gateway-like setups often need tighter control than global allow rules.
Use rate limiting for exposed SSH where appropriate
sudo ufw limit ssh/tcpWhat this does:
Applies connection rate limiting to SSH.
Why this matters:
UFW can deny connections from an address that attempts too many connections in a short time window, which is useful against noisy brute-force behavior.
Turn on logging intentionally
sudo ufw logging onWhat this does:
Enables firewall logging at UFW’s default level.
Why this matters:
Logging gives you visibility into blocked traffic, scanning, and policy hits.
Use deny or reject deliberately
deny silently drops traffic, while reject tells the sender the traffic was denied.
Why this matters:
For many hardened systems, silent dropping is preferred. In some operational cases, explicit rejection is more useful for clarity and troubleshooting.
• enabling the firewall before allowing the remote admin path
• forgetting IPv6 and assuming IPv4 rules covered everything
• opening ports “temporarily” and never closing them
• allowing broad access when source-restricted rules were possible
• assuming internal networks are automatically safe
• focusing on UFW syntax but not the actual exposure of the system
sudo ufw status numberedWhat this does:
Displays the current rules with numbers.
Why this matters:
This is the easiest way to inspect and remove rules safely on a live system.
sudo ufw delete NUMBERWhat this does:
Removes the selected numbered rule.
Why this matters:
Real systems change. A practical firewall guide must include cleanup as well as creation.
sudo ufw delete allow 22/tcpWhat this does:
Deletes the original rule form directly.
Why this matters:
If IPv6 is enabled and you delete a generic rule only by number, you may remove only one side of the IPv4/IPv6 pair. Deleting by the original rule form is safer when you want both removed.
sudo ufw insert 1 deny from 1.2.3.4What this does:
Places a new rule at a specific point in the ruleset.
Why this matters:
Rule order matters. More specific rules often belong before broader ones so the intended match happens first.
What should be reachable?
Start from the assumption that most ports should not be exposed.
Who should reach it?
If a service is administrative, restrict it by source IP or keep it behind a VPN when practical.
On which interface should it be reachable?
Public, internal, lab, and management interfaces should not automatically share identical firewall policy.
Is public exposure even necessary?
Many systems are safer and simpler when remote administration happens through a VPN instead of a broadly exposed SSH port.
Firewalling is not the whole security model
The firewall controls exposure. The service itself still needs hardening, logging, updates, and authentication security.
sudo ufw status verbose
sudo ss -tulpnWhat to confirm:
• only intended ports are allowed through UFW
• only intended services are actually listening
• listening services and firewall rules match the system’s purpose
• remote administration still works after enabling the firewall
UFW logging uses the kernel logging facility. Depending on your system’s logging configuration, entries may appear in
places such as /var/log/ufw.log, general syslog output, or other journal-backed logging paths.
Useful checks:
sudo tail -f /var/log/ufw.log
sudo journalctl -k -fWhat to watch for:
• repeated blocked connections from the same source
• broad port scanning against exposed interfaces
• traffic hitting services that should not be receiving internet traffic
• policy mismatches between what is listening and what is allowed
• pair SSH exposure with source-restricted rules
• add Fail2Ban for abusive login attempts
• move remote administration behind a VPN
• forward firewall logs into centralized logging or a SIEM
• use interface-specific rules on multi-network systems
• Fail2Ban and brute-force protection
• SSH security and key-based access
• Suricata IDS setup on Debian
• Log centralization and analysis