What goes on a list, and how it leaves.

Each list also has a stricter -high version. It is a subset with fewer entries. By default it needs at least 10 sensors, sightings on three different days, and a check against an outside reputation source.

Formats

• Plain text, one address per line. Separate IPv4 and IPv6 files are also published.
• nftables, ipset and MikroTik RouterOS scripts, for the common firewalls.
• CSV and JSON with the dates: first seen, last seen and expiry.
• STIX 2.1 bundles for the outbound lists.
• Domain lists come as text, CSV and JSON only.

Signed with minisign

Every file has a minisign signature, a small .minisig file next to it. minisign uses Ed25519 keys. The feed signing key is separate from the key that signs network messages. A leak of one key cannot forge the other. The public key is in the README.txt file next to the lists. Check a file like this:

minisign -Vm inbound.txt -P <public key>

A firewall that loads the plain URL does not check signatures. Use a verified mirror, or check the file yourself first.

A defensive aid, not a verdict

A listing is a factual observation. It is not an accusation against the person who holds the address. Many listed devices are themselves compromised, for example a router or a NAS that someone else controls. The lists help you decide what to block on your own network. What you do with them is your choice.

The rules

These are the default values. The hub can change them, and the live values are published at hub.suckerpot.selfhostr.io/v1/info.

• At least five member sensors saw the address. Each one is established: enrolled at least 14 days ago, and it reported on at least 7 of the last 14 days.
• The sightings are on at least two different days, or come from at least ten sensors.
• One enrolment week cannot supply more than half of the evidence. A group of sensors that joined at the same time cannot list an address alone.
• If no outside reputation source knows an address, ten sensors are needed instead of five. The operator sets these sources.
• A scan or a bare connection never lists an address. An inbound entry needs a login, a command, a download, an exploit attempt, or many password guesses.
• A malware host needs a downloaded file that matches a known malware family or is an executable program or script, seen by at least two sensors. A URL that appears in a command is not enough on its own.
• A command server needs high confidence from the network, and at least two different malware samples from at least two sensors that point to it.

Never listed

• Tor exit relays. Thousands of people share each one, so the attacker is not the exit.
• Large CDN and cloud front-end address ranges. One address can serve thousands of sites.
• Public DNS resolvers and root servers. Blocking them breaks networks.
• Shared hosting and software-as-a-service host names. Blocking them breaks work.
• Private and reserved addresses, such as your own local network.
• Research scanners, which announce themselves.
• Addresses on the allow-list, for example after an accepted removal request.

Ordinary cloud servers are not excluded, because malware often lives there. Short expiry times and removal after a takedown limit the harm when an address is reused. The number of excluded addresses is published in the public statistics. The addresses themselves are not.

Emergency brake

If one update would add or remove more than half of a list, and at least 200 entries change, nothing is published. The previous files stay online. An operator checks the change before it goes out. This stops a bad batch of data, or a bug, from changing what your firewall blocks overnight.

A new entry waits six hours after it is confirmed before it appears. The lists are rebuilt once an hour.

An address that comes back is listed again only after a new sighting. An old sighting does not put it back.

• No member IP addresses. The lists hold attacker addresses, not the addresses of sensors.
• No member names, pseudonyms, node IDs or fingerprints.
• No exact time of a sighting. Sightings are shown by day only.
• No URLs, malware samples or free text in the lists.
• No logs of who downloads a list. The feed site keeps no access log.
• No cookies, no analytics and no third-party requests on the feed site.
• No account and no token. Anyone can download the lists.

How to ask

1. Open the request form at https://feeds.suckerpot.selfhostr.io/v1/delist.html.
2. Enter the address or host name, choose a reason, and add details if you want. Details are plain text, at most 2,000 characters.
3. The form solves a small proof-of-work puzzle first. It takes about a second. This replaces a login and limits floods of requests.
4. You get a request number and a status code. The status code is shown once. Keep it to check the status later on the same page.

Reasons you can give

• I operate this address and it was not attacking anyone.
• It is shared infrastructure, such as a CDN, a proxy or a resolver.
• The problem is fixed or cleaned up.
• The address now belongs to someone else.
• Something else. Explain it in the details.

Check a value

You can check any address or host name without sending a request. Use the lookup box on the request page, or call the lookup directly. The answer names each list that holds the value, with its dates. The lookup is rate-limited.

GET https://feeds.suckerpot.selfhostr.io/v1/lookup?value=192.0.2.10

What happens next

• We aim to decide every request within 72 hours.
• An inbound entry is hidden while its request is open. It stays hidden until the decision.
• An outbound entry stays listed until a person has reviewed the request. These entries protect the most, so we do not remove them on a claim alone.

Your data in a request

• The form does not store your IP address.
• Details and your contact address are used only to answer. They are deleted 30 days after the decision.
• If a request is still open after 180 days, its details and contact address are deleted then. The request record itself is deleted 180 days after it was made.

• Only confirmed entries are reported. A scan or a bare connection is never reported.
• By default, an operator reviews each report before it is sent.
• Reports go to the abuse contact of the network owner. We find that contact through the public registry data (RDAP).
• A report carries facts only: days, services, counts in ranges, and how many sensors saw it. It never names a member.
• Reports leave through a VPN. An identity check refuses any text that names the project or its operator.
• One report per target and recipient. The same target is not reported again within 30 days.

abuse.ch

Confirmed malware hosts and command servers can also go to abuse.ch, where URLhaus and ThreatFox list them for everyone. Submission to abuse.ch is optional and off by default. Today a person reviews every submission before it is sent, and command servers are only ever submitted after an operator approves them. The record of a finished submission is kept for 365 days.

Legal basis

IP addresses can be personal data under the EU General Data Protection Regulation (GDPR) and the Swiss Federal Act on Data Protection (revFADP). We process them on the basis of legitimate interest in network and information security, under GDPR Article 6(1)(f), see Recital 49. Protecting networks from attacks and malware is that interest.

Your rights

If you hold a listed address, you can object to its listing and ask for its erasure. Use the request form described in the removal section. Objections are handled through that form.

How long we keep data

• Entries leave the lists on the schedule in the expiry section.
• Removed entries stay in the removed.json file for 30 days.
• Sensor observations behind the lists are kept for 14 days, by day only.
• Removal requests follow the timing in the removal section.

Privacy contact

For privacy requests, write to [email protected].

The lists are provided as they are, with no warranty. A listing is a factual observation, not an accusation.