How I Secured My Linux Server Using Effective Firewall Rules

Threat model

Identifying potential threats

I started by listing who might attack the server and why. Script kiddies scanning common ports. Automated bots probing SSH and web services. Targeted attackers after data or persistence. For a linux admin, that list frames every rule I add. I ignored fanciful threats and focused on realistic ones against my services: SSH, web, and some management endpoints. That kept the scope tight and the rules simple.

I ran basic checks for open ports and outdated services. I checked service versions and looked for exposed admin interfaces. Where I could not prove a vulnerability, I treated the service as risky until I tightened access. This is not paranoia. It is practical risk reduction. The inventory from that assessment became the basis for the firewall policy.

Common vectors were brute force on SSH, vulnerable web apps, and unauthenticated services on internal networks. I mapped inbound, outbound and east-west traffic. Mapping showed me which interfaces needed strict rules and which could be permissive. That mapping kept the firewall rules minimal and focused on blocking obvious abuse while allowing legitimate traffic.

Baseline configuration

Default firewall settings

I checked the distro default. On modern Debian/Ubuntu systems nftables or firewalld can be present; on minimal installs nothing may be active. I verified the active backend with commands like sudo nft list ruleset or sudo iptables -L -n -v. I never assumed defaults were safe. I recorded the pre-change state so I could revert if I broke something.

I ensured the server had a static IP or a reserved DHCP lease. I created a separate unprivileged account for daily work and disabled root SSH login. I hardened SSH by moving it off port 22 when feasible and restricting auth to keys. Those steps reduce the blast radius that the firewall needs to handle.

I documented interfaces, public and private networks, and any VPN endpoints. If the server sat behind a cloud provider load balancer I noted the health check ports. That network map dictated which ports I exposed and which I kept behind stricter filters. The map also showed where to place logging and monitoring collectors.

Hardening steps

I implemented a default-deny posture. My nftables base looked like: allow established, allow loopback, allow specific service ports, drop everything else. For example:

1. sudo nft add table inet filter
2. sudo nft add chain inet filter input { type filter hook input priority 0; policy drop; }
3. allow SSH from admin IPs, allow web from 0.0.0.0/0 if public.
   I limited SSH to my home office and VPN subnets. I avoided complex one-liners. Simpler rules are easier to audit.

I paired network rules with service-level access. SSH forced keys and a specific user. Web admin panels were bound to local interfaces or a VPN only. I used TCP wrappers and service configs where possible to add a second check beyond the firewall.

I tested from allowed and blocked networks. I used nc and nmap to confirm ports closed from the internet but open from allowed hosts. I ran sudo nft list ruleset after changes to verify the rules existed. If a rule did not behave as expected I rolled back immediately and adjusted.

Every change went into a small changelog: date, file, command used, reason and verification step. I stored the changelog in the server’s repo and kept a local copy. That made it easy to audit why a rule existed and who added it.

Validation checks

I verified rules with command checks and live tests. Commands included sudo nft list ruleset, sudo iptables -L -n -v where relevant, and sudo ufw status numbered if using UFW. I tested both permitted and denied paths and recorded the results. Verification is how you avoid accidental lockouts.

I ran low-effort scans from an external host: nmap for port discovery and basic vulnerability checks on versions. I limited intensity to avoid tripping provider abuse policies. For a deeper look I used an internal Kali VM to simulate lateral movement. The goal was to validate that blocked vectors stayed blocked.

I reviewed auth logs, firewall logs and web server logs for failed attempts and odd patterns. I added short-term rules to block noisy offenders and then decided whether to make those blocks permanent. Logs revealed brute force attempts and random scans within hours, which reinforced the value of the strict default policy.

Monitoring and alerts

I configured simple alerts for spikes in dropped packets and repeated failed logins. I used a lightweight stack: a local log forwarder and a remote collector that notifies me via email or a chat webhook. Alerts tell me when the rules are working and when they need review.

I scheduled weekly checks and an automated daily summary of the previous 24 hours. The summary included top blocked IPs and unusual destination ports. Regular review catches configuration drift and emerging threats before they build up.

I treated rule updates like code changes. I tested them on a staging host, ran the verification steps, and committed them with the changelog entry. When a service required a new port I added a limited rule and monitored for any misuse. Rules are living; they must be reviewed and pruned.

Rollback considerations

Creating backup configurations

Before any change I saved the active ruleset to a file.

For nftables:

 sudo nft list ruleset > /root/nftables-backup-YYYYMMDD.conf.

For UFW I exported the rules. Backups are the fastest way to recover when a change breaks services.

I rehearsed the revert: load the backup with

 sudo nft -f /root/nftables-backup-YYYYMMDD.conf

or restore UFW from its backup. I kept an out-of-band access method, such as a serial console or provider console, in case I locked myself out. Revert steps were part of the changelog entry.

I stored rollback steps alongside the change notes. Each entry included the expected impact and a contact if escalation was needed. Documentation lowered stress and cut mean time to recovery.

References to standards

I followed basic principles: default deny, least privilege, defence in depth and logging. Those principles guide choices without forcing a single toolset. They are practical and actionable for a linux admin managing a single server.

I mapped the firewall posture to the server’s compliance needs. For personal homelabs this is overkill. For production systems I ensured logging and retention met the relevant standard. The firewall was one control among many.

I keep a small shelf of practical guides. Read the nftables and iptables manuals. Follow distro security notes. I also watch community threads for straight answers and real-world fixes.

If you need to harden a server, start with a clear threat model, then apply rules that match that model.