Blocking Malicious IPs: fail2ban, nftables, and Edge Firewalls

Repeated failed logins, port scans, and exploit probes in your logs make blocking the address the obvious reflex. Whether it actually helps depends on where you block, for how long, and how widely.

Which layer should block?

• Edge / CDN — stops traffic before it ever reaches your server; for volumetric attacks it is the only realistic option.
• Host firewall (nftables/iptables) — fast and cheap for machine-specific decisions; the packet is dropped before the application sees it.
• Application layer — the most expensive place, because the request has already been processed, but the only layer with account, session, and behavioural context.

Rule of thumb: stop brute force and scanning at the firewall, and business-logic abuse (fake signups, coupon abuse) in the application.

fail2ban: automatic bans driven by behaviour

fail2ban reads logs and adds an address to the firewall once a pattern repeats often enough inside a time window. A typical SSH configuration:

The recidive jail keeps addresses that collect short bans out for weeks. Do add your own office and monitoring addresses to ignoreip — otherwise you will lock yourself out eventually.

Large lists: ipset and nftables sets

Writing one rule per address for thousands of entries slows the firewall down. The right structure is a single set matched by a single rule:

This stays constant-cost even at hundreds of thousands of entries; a cron job simply repopulates the set from current feed data.

How wide, how long?

• Make time-boxed bans the default. Permanent lists rot: addresses change hands, and yesterday's attacker is tomorrow's customer.
• Be careful with /24 and wider. Closing a whole block over one bad server also hits the legitimate users inside it.
• Be especially cautious with CGNAT and mobile ranges. Thousands of subscribers can sit behind one address.
• Whitelist your own infrastructure — monitoring, backups, and payment provider callback addresses included.

Don't block search engines by accident

Not every aggressively crawling bot is malicious. Before blocking an address claiming to be a search engine bot, resolve its reverse DNS record and re-query the returned name forward; if the name and IP don't match, the bot is forged. The User-Agent header alone proves nothing.

Feed the list from IP-DB

Verifying addresses pulled from your own logs before blocking them cuts unnecessary bans sharply. The IP-DB.com API returns an address's blacklist records, ASN, and community reports; placed in front of your firewall automation, only genuinely bad-reputation addresses make it into the set. Use the bulk lookup for spot checks and the API for a continuous feed.