Target Audience: Systems Administrators, Network SecOps
Reference Framework: NIST SP 800-123 Section 4.3 (Firewalls and Network Security Contols)

Once administrative access vectors are hardened, the next critical phase of server lifecycle provisioning is locking down the network perimeter. This guide establishes a strict white-list network policy utilizing the Uncomplicated Firewall (UFW) and pairs it with Fail2ban for automated behavioral rate-limiting and dynamic IP ban-jails.

Part 1: Defining a Strict Inbound Firewall Policy

Most default OS distributions ship with wide-open network interfaces. We change this paradigm to a Default Deny posture, explicitly poking holes only for required enterprise applications.

1. Resetting to Baseline Rulesets

Before enabling the firewall, we flush standard rules and enforce a blanket drop policy on incoming connections while permitting all outbound service updates.

sudo ufw default deny incoming

sudo ufw default allow outgoing

2. Provisioning Custom Port Allowances

Because default SSH ports were shifted to reduce automated scan volume, standard UFW application profiles like ufw allow ssh will trap administrators outside their own hardware. We bind explicitly to the non-standard port:

# Authorize hardened SSH access

sudo ufw allow 2222/tcp comment 'Hardened SSH Access Port'

# Open standard secure web ports for downstream local business hosting

sudo ufw allow 80/tcp comment 'HTTP Web Delivery'

sudo ufw allow 443/tcp comment 'HTTPS Encrypted Traffic'

3. Activating Perimeter Rules safely

sudo ufw enable

sudo ufw status verbose

Part 2: Automating Intrusion Isolation with Fail2ban

Firewalls drop unauthorized traffic, but they do not stop bad actors from spamming authorized ports. Fail2ban scans authentication log streams in real-time, matching failed attempts against regex filters to drop malicious IPs at the kernel level via Netfilter.

1. Establishing a Persistent Local Configuration

Never modify the default jail.conf file, as package updates overwrite it. We provision a custom override layout:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

2. Hardening Global Sanction Architectures

Under the [DEFAULT] block, we optimize the ban lifetime parameters to permanently or aggressively flag repeat offending networks:

# Increase ban duration to 24 hours for baseline triggers
bantime = 86400

# Look back window for log file inspections
findtime = 600

# Aggressive max retry cutoff before jail drop triggers
maxretry = 3

3. Customizing the Non-Standard SSH Jail

Scroll down to the [sshd] section and map the engine directly to the modified infrastructure variables:

[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
backend = systemd

Part 3: Deployment Verification & Operational Audits

1. Activating and Verifying Daemon Lifecycles

sudo systemctl restart fail2ban

sudo fail2ban-client status sshd

2. Simulating a Jail Event / Parsing Active Drops

To review logs or manually unban a client ip that locked themselves out of infrastructure during a maintenance window:

# View current jail statistics and drop totals

sudo fail2ban-client status sshd

# Manually clear a whitelisted IP from a ban jail

sudo fail2ban-client set sshd unbanip <target_ip_address>