Summary
Most security systems do not suffer from a lack of data. They suffer from a lack of context.
This week, ip.wayscloud.services passed 400,170,995 analysed and classified reports. The number is worth marking, but the interesting part is not how much data can be stored. It is whether that data is reliable enough to influence a real decision without creating more noise than it removes.
Threat intelligence is often presented as a collection problem. Gather enough feeds, ingest enough logs, attach enough labels, and eventually the system will know which addresses are dangerous.
That sounds plausible until the same address appears hundreds of times in automated feeds, an old report is treated as current, or a shared VPN endpoint is classified as malicious because a few of its users behaved badly. A large database can look impressive while remaining almost useless in production.
The difficult part is not recording that an IP address was observed. The difficult part is deciding what that observation should mean.
An address may have generated thousands of SSH login attempts yesterday. It may have participated in a distributed scan six months ago. It may belong to a cloud provider, a mobile carrier, a residential ISP or a commercial VPN used by perfectly legitimate people. Two reports from independent and trusted sources within five minutes should not be treated like two duplicates copied through the same feed. A manually verified incident should not carry the same weight as an automated rule that occasionally fires incorrectly.
This is the engineering problem behind IP reputation. It is less about building a blacklist and more about handling uncertainty without pretending it has disappeared.
A report is not a verdict
The platform behind ip.wayscloud.services now contains more than 400 million analysed and classified reports. I deliberately avoid describing these as simply stored reports, because storage is the easy part.
Each observation has to be considered in context. How recent is it? Which category does it belong to? Has the same event been submitted repeatedly? How confident is the source? Has the address appeared across several independent sources? Is it a residential address, a datacenter host, a proxy, a VPN endpoint or a Tor exit node? When was the activity first and last seen? The answer should rarely be a binary good or bad.
The API therefore returns a threat score from 0 to 100, a human-readable risk level, report counts, categories, first-seen and last-seen timestamps, and detection flags. A full lookup can also include reverse DNS, geolocation, ASN, ISP, organisation and connection type. The application using the data still decides what to do with it.
That separation matters. A mail server, a login flow and an internal admin panel do not have the same tolerance for risk. A score that justifies additional verification in one system may justify a temporary block in another. Central threat intelligence should provide context, not silently become the security policy of every application that consumes it.
A complete lookup is a single request:
curl -s \
-H "X-API-Key: <API_KEY>" \
https://api.wayscloud.services/v1/ip/203.0.113.10
The result can contain the network identity, geographic context, threat score and flags in one response. When only the security assessment is needed, the smaller threat endpoint avoids retrieving the rest:
curl -s \
-H "X-API-Key: <API_KEY>" \
https://api.wayscloud.services/v1/ip/203.0.113.10/threat
A typical threat response contains the total number of reports, observed categories, timestamps and flags for VPN, proxy, Tor and datacenter use. None of those fields should be treated as proof on its own. Together, they provide a much better basis for a decision than a static blocklist entry.
The useful integration is usually not a hard block
The simplest use case is authentication. Before accepting a registration, password reset, API token request or other sensitive operation, an application can look up the client address and combine the result with its existing signals.
A clean residential address with normal behaviour may proceed without friction. A newly created account connecting through a high-risk proxy that was recently associated with credential stuffing may receive an additional verification step. A medium-risk address may be rate-limited rather than blocked. This is usually more effective than treating every flagged address as equally hostile.
The same model can be used in reverse proxies and API gateways. Critical scores can be rejected, medium scores can be throttled, and low scores can be logged for later correlation. The exact thresholds belong to the operator, because the operator understands the service being protected.
WAYSCloud Verify also accepts an optional client IP when starting or checking an SMS, voice or email verification session. When supplied, the response can include an IP risk assessment with the score and flags for VPN, proxy, Tor and datacenter traffic. This makes it possible to add scrutiny to suspicious verification attempts without adding friction to every user.
For security operations, the live threat feed exposes the most recently reported addresses with score, level, categories, country and last-seen time. That can be consumed by a SIEM, a SOC dashboard, a firewall synchronisation job or an internal enrichment pipeline.
The API also provides aggregated country and ASN intelligence. Country data includes total threats, threat density and common categories. ASN data includes the network name, observed address count, report count and abuse concentration. These views are useful when an incident is not isolated to one host but appears to be part of a broader pattern inside a network or hosting provider.
None of this replaces local telemetry. It gives local telemetry more context.
Consuming intelligence is only half of the system
A reputation platform that only consumes external feeds eventually becomes a mirror of other people's assumptions. It also misses the observations happening inside the infrastructure it is supposed to protect.
The IP Intelligence API therefore supports reporting as well as lookups. Fail2ban, honeypots, intrusion detection systems, mail infrastructure and internal abuse tooling can submit observations directly.
A report can include an IP address, category, severity, confidence, a short comment and a session identifier used for deduplication. Common categories include SSH brute force, port scans, HTTP floods, SIP attacks, RDP brute force, web attacks, spam and phishing.
A Fail2ban integration can submit an event like this:
curl -s -X POST \
-H "X-API-Key: <API_KEY>" \
-H "Content-Type: application/json" \
https://api.wayscloud.services/v1/ip/report \
-d '{
"ip": "203.0.113.10",
"category": "ssh_bruteforce",
"severity": "high",
"confidence": 0.9,
"comment": "Repeated SSH attempts over 24 hours",
"session_id": "fail2ban-ssh-2030011310"
}'
Duplicate reports for the same address and category within a short period are deduplicated. That is a small but important detail. Counting the same event ten times does not make it ten times more true.
The source also matters. An automated Fail2ban rule should not automatically have the same influence as a manually reviewed incident from a verified security team. Reporter registrations therefore have trust levels. Automated, hybrid and manual reporters start with different weights, and ownership of a reporting domain can be verified through DNS to reach the highest trust score.
Without source weighting, collaborative threat intelligence quickly becomes a contest in who can submit the most data. That is not intelligence. It is volume.
False positives need an exit
Reputation data cannot be permanent by default. Servers are compromised and later cleaned. Addresses change owners. Shared infrastructure creates ambiguous signals. Classification errors happen.
The platform therefore includes a delisting process based on both IP and DNS verification. The requester provides the affected address, a hostname that resolves to it, an explanation of what happened and what was remediated, and a contact address. A DNS TXT record is then used to prove control before the request is reviewed.
This does not mean every request should be accepted. It means there is a documented way to challenge a classification and prove ownership. Security infrastructure should be strict, but it should not be arbitrary.
More data does not automatically make the system better
The number 400,170,995 is satisfying because it represents a lot of observed activity. It is also a reminder of how much automated abuse now happens as a normal background condition on the internet.
Still, the next hundred million reports are not useful merely because they increase the counter.
They are useful when duplicates are removed, old observations lose weight, independent sources reinforce each other, reporter confidence is preserved and the resulting score remains understandable to the system consuming it. They are useful when a developer can inspect the categories and timestamps instead of being handed an unexplained verdict.
The goal is not to label as much of the internet as dangerous as possible. The goal is to help systems make fewer bad decisions.
That is also why the barrier to trying the API has been kept low. The free tier is provisioned automatically on first use and includes 1,000 requests per day. For many applications, open-source projects and smaller infrastructure environments, that is enough to add useful context without a procurement process or a sales conversation.
You can inspect addresses and recent threat activity at ip.wayscloud.services, and the complete request formats, response schemas and integration endpoints are documented in the IP Intelligence API reference.
Four hundred million reports is a milestone. The real work is making the next observation more useful than the previous one.