IP reputation: what an address history can and cannot tell you

Three ingredients, combined differently by every provider that sells them.

• Observed behaviour. Traffic seen from the address across many properties: submissions to forms that no person would find, credential attempts against unrelated sites, requests matching known abuse patterns. The value comes from breadth, since one site sees too little to judge.
• What the address is. Whether it belongs to hosting infrastructure, a consumer network, a mobile carrier, or an anonymising service. This is classification rather than behaviour, and it is often the most stable part of a score: a request from a datacentre claiming to be a phone browser is worth noticing regardless of history.
• Age and stability. How long the address has been used for what it is used for, and whether that changed recently. New allocations and recently reassigned ranges carry little evidence in either direction.

Scores are then expressed on some scale, and the scale is a product decision rather than a fact. Two providers scoring the same address differently are not necessarily contradicting each other; they weighted different ingredients.

Four limits, and each one produces a specific kind of mistake.

• Who is behind the address. Mobile carriers and corporate networks place many people behind one address. A score earned by one of them applies to all of them, and the people affected have no way to know why a site treats them oddly.
• Whether the reason still applies. Addresses are reassigned constantly. Evidence collected before a reassignment describes a previous occupant.
• Whether the traffic is automation at all. A poor score frequently means "this address hosts servers", which is true of every legitimate integration that calls you, every monitoring service, and every cloud-based tool your own team uses.
• Whether an attacker chose an address with a good score. Automation running through consumer connections inherits ordinary residential reputation, which is why that arrangement exists.

The two get used interchangeably and behave differently.

• A blacklist is binary and authored. An address is listed or it is not, a policy decides why it was listed, and another policy decides how it gets removed. The mechanism grew out of mail filtering, where a hard yes-or-no suits the problem, and it is typically queried through the naming system rather than through an interface. Its strength is accountability: there is a listing reason and a removal process.
• Reputation is continuous and inferred. No one wrote a decision about a particular address; a score emerged from observations. Its strength is nuance, and its weakness is that nobody can tell you exactly why a number is what it is, which makes disputes hard.

The practical consequence: a blacklist entry is a claim you can appeal, and a reputation score is a weight you can only outweigh. Using a score as if it were a listing produces blocks nobody can explain to the affected visitor.

Checking an address: what a lookup returns

An IP reputation checker takes one address and returns a score, a category, or a list of sources that flagged it. That is a lookup of somebody else's opinion, not an examination of the address.

When you check IP reputation, read three things before the number: which provider answered, what its scale means, and how old the evidence behind it is. An IP reputation test run against two services can return two different answers without either being wrong, because each weighted the ingredients differently.

A lookup is also a snapshot. An IP reputation search describes the history up to the moment of the query, and an address that looks clean today can be reassigned tomorrow. A blacklist lookup is a separate query with a separate answer, listed or not, and it does not replace a score or the other way round.

What a lookup cannot return is a verdict on the request in front of you. IP reputation filtering, meaning refusing or challenging traffic below some threshold, is a second decision on top of the lookup, and the four rules in "Using it without regret" govern it.

A score that only accumulates becomes a permanent block list with extra steps. How to keep address blocks narrow is on IP blocking.

Every piece of evidence has a shelf life, and addresses change hands more often than intuition suggests. Without decay, a range that misbehaved a year ago keeps paying for it while serving somebody new, and the sites using that score never learn what they lost.

This applies equally to lists you maintain yourself: entries added during an incident need an expiry attached at creation, for the same reason.

Modern addressing changes what reputation can mean. Know this before building anything on per-address scores.

Where each device may hold an enormous number of addresses, a score attached to a single one carries almost no information: the next request arrives from a different address at no cost to anyone. Reputation systems therefore work at the level of allocations, which is more accurate and also blunter, since an allocation may cover a whole network of unrelated people.

The practical rule is to know which granularity your data uses before deciding what a score justifies.

Accounts taken over from many addresses are described under account takeover, and responses that spare real people under how to block bad bots without blocking your customers.

The mirror case, and it arrives without warning.

If traffic your systems send starts being refused elsewhere, the cause is often reputation attached to an address you did not choose: a shared hosting range, a cloud allocation whose previous occupant misbehaved, or an office connection someone else on it abused. Nothing on your side changed. Lookups you can run on your own address are collected under security tools.

Two things help. Find out which classification your addresses carry, since that is the part you can sometimes influence by moving traffic to addresses used for one purpose only. And where a specific listing is the cause rather than a score, there is usually a stated reason and a removal process to follow.

Know both before an outbound integration fails, because the diagnosis is unintuitive: your logs show requests leaving normally and answers not coming back.

Four rules, and they follow from the limits above.

• Never let it decide alone. Reputation is a weight in a score, combined with behaviour and consistency, as described on bot detection.
• Weight by address type, not just by score. A poor score from hosting infrastructure means something different from a poor score on a mobile carrier, and treating them identically guarantees the second becomes a customer complaint.
• Respond proportionately. A weak signal deserves a challenge or a limit, not a refusal.
• Exempt what you depend on explicitly. Your monitoring and your partners' systems run on the infrastructure that scores badly.

Bridge WAF does not score addresses. Its bot classification works on declared identity, so nothing on this page describes a capability it has, and a page about reputation is the right place to say so rather than to imply otherwise.

What it offers instead sits alongside reputation rather than replacing it: three modes, off, monitor, and block; rate limiting per domain; and a near-real-time log of flagged requests. Monitor mode is the useful one here, because it lets you see which traffic a rule would have caught before anything is refused, which is the discipline this page argues for whatever your data source. See what the platform offers at Bridge CDN.