How many IPs should actually be on your blocklist?

Every evaluation reaches the same question within about ten minutes: how many addresses are on the list? It is a reasonable thing to ask and a poor thing to optimise for. A list of forty thousand addresses that were scanning last week is worth less than four hundred that are scanning right now, and it costs you more.

Two separate limits decide the answer. One is what your platform can physically hold. The other, more interesting one, is how much wrongness you can absorb.

What your platform can hold

Check this before you tune anything, because a list that exceeds capacity does not always fail loudly.

On PAN-OS, external dynamic list capacity depends on the firewall model, and lists are committed in order until that capacity is used up. If you already run several large EDLs, the one you add today may be the one that does not fit, and the only sign is a System log entry saying entries were skipped. Palo Alto's own interface lets you reorder lists for exactly this reason, so the important ones commit first.

On pfSense, the answer depends on the alias type. A URL alias, the type our blocklist documentation points to, reads at most 3,000 entries from each URL. That is the limit our docs mean when they suggest the rows parameter for pfSense.

A URL Table alias can hold many thousands. Its ceiling is Firewall Maximum Table Entries, which defaults to 400000, and Netgate's guidance is that all aliases and tables together should fit in roughly half of that, because the firewall loads a new copy of a table next to the old one before dropping the old one. So about two hundred thousand entries across everything, not per list. If they do not fit, the firewall may fail to load the ruleset. Raising the limit costs memory, about a kilobyte per entry by Netgate's conservative estimate, on hardware that may not have much to spare. And whichever type you use, check how often it fetches the list again: a URL Table alias does it on an interval set in days.

OPNsense behaves similarly through its own alias handling. In all three cases the useful move is to look at the current counts before adding a feed, not after someone reports a commit failure.

The cost of being wrong scales with size

Here is the part capacity planning misses.

Assume a small error rate, whatever your threshold produces. The number of addresses that are wrongly on your list grows with the size of the list, and so does the chance that one of them is a customer, a partner's API gateway, a payment provider callback or a monitoring probe from a region you have never thought about.

Worse, the damage is uneven. A wrong entry on a list feeding a log only rule costs you nothing but a line in a report. The same entry on an inline deny rule at your perimeter costs you an outage that nobody will diagnose quickly, because nobody debugging a failed webhook starts by suspecting a threat feed.

So the useful question is not how many addresses you can hold. It is how many addresses you can afford to be wrong about at the point where this list is enforced.

Trimming on purpose

Two dials control size, and they do different things.

The score threshold decides what qualifies. Raising it is a quality filter: fewer addresses, stronger evidence behind each one. This is the dial to reach for first, because it improves the list rather than just shortening it.

The rows parameter on the blocklist URL decides how much of the list a given consumer receives:

https://limes.nxtfireguard.de/blocklist/your-blocklist-id?rows=500

The cap applies to the response only. Addresses stay on the internal list and keep getting re scored on the check interval. You are choosing how many entries this particular firewall receives, not which addresses qualify. That distinction matters: the cap is a delivery decision, the threshold is a confidence decision, and using the cap to paper over a badly chosen threshold gives you a short list of mediocre entries.

The pattern that works: two lists, not one

The setup I recommend to almost everyone splits the job in two.

A tight enforcement list with a high threshold, capped with rows to a few hundred, feeding an inline drop rule. Small, high confidence, low blast radius. This is the one that actually protects the perimeter.

A wide observation list with a lower threshold and no cap, feeding a rule that allows and logs. Place it below the enforcement rule, because with a lower threshold the wide list will usually hold everything the tight one does, and above the enforcement rule it would catch the addresses the drop rule is there for. Scope it to the destinations and services your permit rules already allow, so it lets in nothing that would not have got in anyway. Nothing is blocked. You get a continuous, free answer to the question "what would a more aggressive policy have cost me", using your own traffic instead of a vendor's benchmark.

Once a month, read the observation log. If it contains nothing you recognise, move the enforcement threshold down a step. If it contains a partner, you just avoided an incident and you know which whitelist entry to add. The Starter tier and up give you five or more blocklists, which is plenty for this pattern plus a lab list.

A sizing recipe

If you want a starting point rather than a principle: cap the enforcement list at five hundred entries, set the public threshold high enough that the list sits comfortably below that cap on its own, and set the check interval to twelve hours. Then leave it alone for two weeks and look at three numbers.

How often the deny rule fires, because a quiet rule means the threshold is too high or retrieval is broken. How many entries the list actually holds against the cap, because a list permanently at the cap is telling you the threshold is too low. And how many whitelist entries you have had to add, because more than two or three in a fortnight means the threshold is doing more work than the evidence supports.

Those three numbers will tell you more about the right size for your environment than any number a vendor, us included, can put in a datasheet.

The uncomfortable summary

A blocklist is not a database of bad addresses. It is a bet about the next few hours, priced against what a wrong bet costs you at the point of enforcement. Size follows from that, and it is usually smaller than people expect.

If you want to try the two list pattern, the free Basic tier covers two lists, which is exactly enough. Start with the blocklist documentation and set the observation list up first.