IP reputation tools for fraud and bot decisions

Monday morning, you are looking through the weekend’s sign-ups, and hundreds of new accounts came from a small set of addresses. Some of those same addresses also tried to log in to existing accounts. A colleague has already put the addresses into a free lookup site: one is marked as reported many times, one is a Tor exit, and one shows nothing at all. The accounts are waiting in one queue and the login attempts in another, but the addresses connect them. You have to decide what those answers should mean for the next sign-up or login. Where does that decision sit?

One IP reputation source cannot answer every question

The lookup results from the addresses in your weekend queue answer different questions. We ran the lookups on 22 October 2026. Of the 50 addresses reported for server attacks in the previous 48 hours, 42 were absent from both Barracuda and Project Honey Pot. The five addresses AbuseIPDB scored 100 were absent from both as well.

A service that never saw an address cannot clear it. The lists reflect different sensors, so the decision has to use evidence from more than one source.

Choose sources by the activity they observe

Choose a source for the abuse it is built to see. AbuseIPDB collects reports about attacks on servers and web apps. Project Honey Pot’s traps collect information about visitors such as comment spammers and harvesters. Barracuda’s Reputation Block List is a mail list. Blocklist.de lists addresses reported attacking its members’ servers in the previous 48 hours.

Those different sources help explain the overlap result. Project Honey Pot knew 26 of the 50 Tor exits in our sample, and five of the 50 recently reported server attackers. Its trap network is evidence of the activity its traps catch.

The services return different kinds of evidence and use different ways to query them:

AbuseIPDB’s confidence score reflects user reports, and AbuseIPDB says report weights decay over time. Project Honey Pot’s http:BL lookup returns visitor type, threat score and days since last seen. MaxMind’s Anonymous IP database identifies network types, and minFraud scores payment transactions.

Separate network type from reported activity

Use network type and reported activity as separate inputs. A Tor exit, VPN, mobile carrier gateway or office network can carry traffic for many people. Cloud servers and home connections can change hands. A report tells you about activity associated with an address, while a network label describes the kind of connection.

Our lookups illustrate the difference. Project Honey Pot labelled Google’s public DNS a “Bad Web Host” and Cloudflare’s public DNS a “Search Engine.” AbuseIPDB scored both zero and whitelisted them. These labels describe the addresses and the services’ data, not the intent of the person making a particular request.

At login, device information from browser fingerprinting can add another view of the request.

Put these checks into a decision flow

Create rules for credit, fraud or collections, then run them on live decisions.

Start free See pricing

Combine lookup sources and weigh reports by age

Call the sources needed for a request together in one decision step. They run at the same time, and the step waits for the slowest answer. A successful answer can be stored in a cache your organisation owns for a set age, such as a day. Later requests can reuse it, and the rules can read how old it is. Errors are returned to the decision rather than stored.

Use a paid source when its particular evidence could change the action. At checkout, minFraud assesses the transaction, including its IP, email, billing and shipping addresses, card issuer prefix and order. For an address whose network type matters, the Anonymous IP database provides flags from a file read on your server. If the existing evidence already leads to the same action, another paid response adds cost but does not affect the decision.

Give recent activity more weight than stale activity. http:BL returns the days since an address was last seen, and AbuseIPDB says its report weights decay over time. Read the age information each source provides when you decide how much weight a listing carries.

Give failed lookups an explicit outcome

Route a failed, refused or timed-out lookup to an unknown rule. A missing answer carries uncertainty into the decision, so it must not become a clean result by default.

Spamhaus’s notice on public resolvers explains that 127.255.255.254 is its refusal response when a query comes through a public resolver it does not allow. Use its free Data Query Service with a key for those lookups. In our tests, queries through Cloudflare’s resolver returned that distinct refusal code. Queries through Google’s resolver returned either a listed answer or no record, and a no-record answer looked the same as an unlisted address.

Choose the unknown outcome by the failure and the request. Retry when the failure is transient, the request can wait within the source’s timeout, and another attempt could return useful evidence. Route a refusal to the unknown rule and correct the resolver or query method. If the request is low-risk on its other evidence, allow it to proceed with the unknown recorded. If other signals raise concern, challenge it or send it for review. A missing number in a decision table can be read as zero, so make the missing-answer case explicit.

Choose friction from request context and combined evidence

For the Monday queue, a single report should change the next step in proportion to the rest of the request. Challenge a sign-up with many reports, then use the Tor result as a network signal and check it against the request. Send an address with no result through the unknown rule, then use the other available evidence to decide whether the person can proceed, needs a challenge or needs review. For linked logins, include the repeated attempts as evidence from your own traffic.

Several agreeing sources and a repeated attack pattern can justify review or a temporary payout hold. Use an edge block only for an address that cannot serve legitimate customers, with your own evidence confirming the attack. Add a confirmed attacker to your own block list with an expiry. For a shared or reassigned address, choose a shorter review period. Extend or renew the entry only when fresh evidence supports it.

At checkout, send the IP as part of the transaction to minFraud and read IP risk and anonymous flags beside the transaction score. In one tested Insights response, a Tor exit had IP risk 22.5 and the otherwise clean order scored 7.61. In another tested order, an anonymous-IP factor appeared while the transaction scored 3.08. MaxMind’s example accept line was 5, so that order was accepted on the score, with the factor still available to the rule. The minFraud transaction score belongs with the rest of the order evidence.

For the sign-ups and logins waiting in your Monday queue, use the signals to choose an action for each request:

1. Choose sources for the activity they observe: AbuseIPDB for server and web-app attack reports, Project Honey Pot for visitor types such as comment spammers and harvesters, a mail list such as Barracuda for mail reputation, blocklist.de for attacks on its members’ servers, MaxMind’s Anonymous IP database for network type, and minFraud for payment transactions.
2. Call the sources needed for a request together in one decision step. Store successful repeat answers for a set age, such as a day, and pay for another call only when its evidence could change the action.
3. Read network type, such as Tor, VPN, hosting or a shared service, separately from reported activity.
4. Use http:BL’s days-since-last-seen value to weigh its listing, and read AbuseIPDB’s score with its stated decay in report weights.
5. Route failed, refused and timed-out lookups to an unknown rule. Retry transient failures when the request can wait and another attempt could help, correct the query method after a refusal, and use a challenge or review when the other evidence raises concern.
6. Use the combined evidence and request context to choose the friction: challenge or review concerning requests, and reserve an edge block for an address that cannot serve legitimate customers when your own evidence confirms the attack.
7. Add confirmed attackers to your own block list with an expiry based on the address and the expected useful life of the evidence. Review shared or reassigned addresses sooner, and renew an entry only when fresh evidence supports it.
8. At checkout, send the IP as part of the transaction to minFraud and read IP risk and anonymous flags beside the transaction score.

Questions about IP reputation lookups

What tools are effective for identifying and blocking malicious IP addresses in real time?

Use services suited to the activity you need to detect, and combine their answers in your decision. AbuseIPDB covers reports about server and web-app attacks, Project Honey Pot returns visitor types such as comment spammers and harvesters, mail lists such as Barracuda provide mail reputation, MaxMind’s Anonymous IP database describes network type, and minFraud scores transactions. Choose the sources that fit your traffic, then set the friction from the combined evidence.

Is there a free alternative to AbuseIPDB?

For scrapers, comment spammers, harvesters and similar bots, use Project Honey Pot’s http:BL as an alternative because its traps observe those visitors. For mail abuse, Barracuda’s Reputation Block List is the relevant alternative because it reflects mail its systems receive. Check each service’s current access terms and query method before adding it to sign-up or login decisions.

Should every IP address on a blocklist be blocked?

No. A listing is evidence about an address, and shared or reassigned addresses can carry traffic for other people. Use the listing to choose proportionate friction, and reserve an edge block for an address that cannot serve legitimate customers when your own evidence confirms the attack.

How fast is an IP reputation lookup inside a login or checkout?

When sources are called together, the decision waits for the slowest response. In our recorded tests, Barracuda DNS-over-HTTPS lookups had median times of 146 to 157 ms. Project Honey Pot’s public page had median times of 279 to 394 ms, and the page is for reading rather than a decision lookup. The actual time in your login or checkout depends on the sources you call and their response times, so use stored answers where appropriate and set a timeout.

Why does a Spamhaus lookup return 127.255.255.254?

Spamhaus uses that response to refuse queries through public resolvers it does not allow. Use its free Data Query Service with a key, and route the refusal through an unknown rule.

What does MaxMind add for card transactions?

minFraud scores the transaction using the IP alongside information such as the email, billing and shipping addresses, card issuer prefix and order. Its response includes IP risk and, in the Insights responses tested, hosting, anonymous and Tor-exit information. Read those details beside the transaction score.

How long does IP reputation data stay accurate?

It depends on the source and the activity. http:BL returns days since the address was last seen, and AbuseIPDB says its report weights decay over time. Give more weight to a listing seen in the last weeks than to one last seen years ago. Our Project Honey Pot lookups showed examples of both.

Put these checks into a decision flow

Create rules for credit, fraud or collections, then run them on live decisions.

Start free See pricing