Blocking IP Addresses in a Firewall: Best Practices

Blocking is appropriate for clear abuse from infrastructure that exists to produce it: repeated scanning, brute-force attempts, exploit traffic, or unwanted automation from a dedicated server. It is far less safe for residential, mobile, school, office and carrier addresses, because many people stand behind each of those and none of them can see your firewall rule.

NIST's firewall guidance (SP 800-41 Rev. 1) recommends a default-deny posture, rules derived from a written policy and risk analysis, and regular review of the rule set. IP blocking fits inside that: each rule should answer to a reason, an owner and a review date, not to the mood of the moment an alert fired.

Start with the single address. Widen to a CIDR range, written in the notation RFC 4632 defines, only when your logs show the abuse spread across that range rather than one host inside it; a /24 holds up to 254 other machines, and a /16 holds tens of thousands. Widen to an autonomous system only when the whole network is one you never expect to serve, such as a hosting provider sending traffic to a consumer login page, and never for a residential or mobile network, where an ASN block is a block on a city.

Before widening, check what else lives in the range: reverse DNS, the RDAP registration and a sample of the addresses' reputation. If the range belongs to a provider with an abuse desk, a report to that desk removes the source; a firewall rule only removes your view of it.

Make rules temporary by default. The address an attacker used this week returns to a pool and is handed to a customer next week; a permanent rule then punishes that customer for someone else's history. Attach an expiry to every block created during an incident, keep the permanent list short and deliberate, and review it on a schedule. A rule nobody can explain should be removed, not kept out of caution.

Record a reason code, the incident reference and the author with each rule. The record is what lets the next person decide whether the rule still earns its place.

One public IPv4 address rarely equals one person. Carriers and some ISPs place subscribers behind carrier-grade NAT in the 100.64.0.0/10 space that RFC 6598 reserved for it, so a single address can represent thousands of mobile or broadband customers; the CGNAT guide explains the mechanics. Phones exit through regional carrier gateways far from the handset, covered in the mobile carrier guide. Companies route entire offices through a few egress addresses, and VPN exits carry legitimate users alongside whoever abused the same exit an hour earlier.

For those addresses a hard block is a blunt tool. Prefer a rate limit, a challenge or an account-level control, and if a block is unavoidable, make it short and monitor support channels for the people it caught.

Geo blocking uses IP location to allow, deny or alter access by country or region. It has legitimate uses in licensing, regulatory compliance, fraud controls and content delivery, and it works well enough at the country level to be worth having for those purposes. It is weak as a security control on its own, because location is an estimate and an attacker chooses where to appear from.

The estimate is imperfect in predictable ways. Travelers and expatriates appear where they are, not where their account was opened. VPN and proxy users appear at the exit server. Businesses that route traffic through a central office or a cloud region appear there. Databases lag behind address reassignments, and some ranges are placed at a registry country that has nothing to do with the users; operators can publish corrections in the geolocation feed format described in RFC 8805, and MaxMind's own accuracy statements show how much the city-level figure varies by country and network. The accuracy guide goes through each cause.

Over-blocking has a cost that rarely appears in the security dashboard: lost customers, frustrated travelers and support tickets that a single verification step would have avoided. Use country for broad routing and as one input to risk scoring, combine it with account and transaction context before enforcing anything, and give blocked users an appeal or fallback path where access matters. The geolocation service guide describes how the underlying data is produced.

A block is the last rung of a ladder, not the first. Rate limits cap what an address can do without denying it. Challenges such as a CAPTCHA or an email confirmation filter automation while letting people through. Multi-factor authentication and step-up prompts protect the accounts an attacker actually wants. Read-only or reduced-function modes let a suspicious session continue without doing harm. Each of these fails more gracefully than a firewall rule when the address turns out to be shared.

Allowlists invert the problem for the surfaces that should never be public. Administrative panels, deployment endpoints, database ports and webhook receivers can be restricted to known addresses, an office range, a VPN concentrator or a partner's published egress, so that the question is no longer who to block but who is permitted. Keep allowlists as tightly documented as blocklists; a forgotten entry is an open door.

Log the hits on every block rule. A rule that never matches is dead weight; a rule that matches thousands of times a day from a residential range is probably hurting customers. Review the logs alongside support tickets, and treat a spike in tickets from one region as evidence about a rule, not only about the region.

Curated threat feeds can replace hand-built lists for the worst infrastructure. Spamhaus's DROP list, for example, names netblocks that its analysts assess as controlled by spam and cybercrime operations and recommends that they not be routed at all. Feeds age like every other list: automate their refresh, log what they block, and be ready to explain an entry that catches a legitimate customer.

Do not block on a single event, on a shared address, on a partner's or your own scanner, or when the evidence is still developing and a narrower control would hold the line. Do not block a country to solve a fraud problem that account controls would solve. Do not add a rule you would not be able to justify to the customer it eventually catches. The incident response triage guide covers the decision sequence for a live incident, and the IP reputation checker shows the current signals for an address before a rule is written.