Our vision

Attackers share everything: wordlists, exploit kits, lists of vulnerable hosts. Defenders mostly share nothing. We would like to even that up a bit.

The problem

Look at any internet-facing server and you will find the same thing in the logs: a steady background hum of automated attacks. SSH password guessing. Requests for wp-login.php on sites that have never run WordPress. Probes for a Log4j bug that was patched years ago. Spam relays. Port scans from the same few hosting networks, every day.

None of it is clever. It works because it is cheap and because every target faces it alone. The address that hammered your mail server at 3am will hit thousands of others before lunch, and each of them will discover that independently.

What we want

A world where the hundredth server to see an attacker already knows about it. Where a small company with one VPS gets the same early warning as a bank with a security operations centre. Where reporting abuse is so easy that it happens by default, as a side effect of the tools people already run.

Concretely, that means:

1. Reporting has to be effortless. One line in fail2ban, one curl command, and a free account created with nothing but an email. If it takes more than a minute to set up, most people never will.
2. The data has to be trustworthy. That means weighting independent, recent, accountable reports over noise, and making it easy to fix mistakes. A blocklist that blocks innocent people is worse than none.
3. The data has to be open. Free to look up, free to use on your own servers, in formats that drop straight into the tools people use, from iptables to a SIEM.
4. It has to work everywhere. IPv6 as a first-class citizen. Location and network context for every address. Plain language, documentation that works on a phone, an API that does not need an SDK.

Where we are going

The core is here today: lookups, reports, scores, the blocklist and the API. Things we are working towards:

• Verified reporters: organisations that prove they run the networks they report from, whose reports carry extra weight.
• Network owner tools, so a hosting provider can see what is being reported in its ranges and act on it.
• Ready-made plugins for more tools, contributed by the people who use them.
• Translations of the site and documentation, starting with the languages our reporters actually use.

If any of this matters to you, the most useful thing you can do is send us what your servers see. The second most useful is to tell us what is missing.