Changed Firewall Rules

A Debian-first guide to detecting unexpected UFW changes, identifying new exposure, and restoring intended firewall protections safely.

What this is

Changed firewall rules can indicate accidental exposure, misconfiguration, rushed troubleshooting, or malicious tampering. On Debian systems using UFW, rule changes can directly affect what ports, services, and sources are allowed or denied.

Unexpected rule changes matter because they can quietly expose services that were meant to stay restricted.

What it looks like

Detect

Review current UFW rules

sudo ufw status numbered

Review more detailed rule output

sudo ufw status verbose

Compare listening ports against firewall policy

sudo ss -tulnp
sudo ufw status numbered

Review recent UFW log activity

sudo grep "UFW" /var/log/ufw.log | tail -n 100

Review shell history or admin activity if available

history | grep ufw
sudo grep -Ei "sudo|COMMAND" /var/log/auth.log

Contain

Delete an unexpected UFW rule by number

sudo ufw status numbered
sudo ufw delete <rule_number>

Re-apply a trusted IP restriction

sudo ufw allow from <trusted_ip> to any port 22
sudo ufw deny 22

Re-close an unexpectedly exposed port

sudo ufw deny 8080
sudo ufw deny 3306
sudo ufw deny 5432

Recover

Review what became exposed during the change

sudo ss -tulnp
sudo ufw status numbered

Review for related service or account changes

sudo systemctl list-units --type=service --state=running
cut -d: -f1 /etc/passwd
getent group sudo

Restore intended firewall posture

# Rebuild rules to match the system's intended exposure and trusted access model

Recovery means understanding whether the firewall change was accidental, operational, or part of broader tampering.

Prevent

Option 1 — Review UFW rules regularly

sudo ufw status numbered
sudo ufw status verbose

Option 2 — Compare firewall rules to actual listening services

sudo ss -tulnp

Option 3 — Keep admin access restricted to trusted IPs

sudo ufw allow from <trusted_ip> to any port 22
sudo ufw deny 22

Option 4 — Avoid leaving temporary troubleshooting rules in place

# Remove temporary allow rules after testing or maintenance

Option 5 — Review auth logs after unexpected rule changes

sudo grep -Ei "sudo|COMMAND|Accepted" /var/log/auth.log

Optional Tools & Hosting

Manual firewall review should come first. Future recommendations may include options that improve rule visibility or simplify restricted access, but the core defense is understanding exactly what your Debian system is exposing and why.

Notes

Environment Note

All commands shown are based on Debian-based systems unless otherwise noted.