IPv64 blocklists explained: which lists exist and what they block

IPv64.net provides free IP blocklists: proven public lists such as Spamhaus DROP, FireHOL and blocklist.de, its own v64 Blocklist from the community's Honeypot64 network, country lists and lists for special cases such as DoH servers, cloud networks and AI crawlers. This page explains what each list contains, where it comes from, how risky it is and which one fits your purpose.

What blocklists are for: first-level protection

An IP blocklist is a list of addresses and networks known to attack, scan, send spam or control botnets. Your firewall, router or reverse proxy drops connections from these addresses before they reach your services. IPv64.net calls this first-level protection: the first line of defence right at the edge of your network.

• Smaller attack surface: brute force on SSH, mail and login pages, known exploits and mass scans never reach you.
• Less load and noise: your services answer fewer unwanted requests and write fewer logs.
• Ready to use: IPv64.net downloads the source lists, cleans them and provides them in consistent formats. You add one address; the list keeps itself up to date.

All lists with their current size and age are on ipv64.net/v64_blocklists. How to add them to pfSense, OPNsense, MikroTik, nftables and other systems is described under Use blocklists.

Limits and risks of blocklists

Blocklists are a useful filter, but not complete protection. Before you switch on a list, know its limits:

• False positives: many addresses are shared or reassigned – mobile networks, CGNAT, VPN providers, Tor, public Wi-Fi, dynamic connections. If such an address is listed, you lock out harmless users as well, in the worst case yourself.
• Inbound by source: most lists are meant to drop connections from the Internet by source address. Only some lists are explicitly meant for outbound traffic: Spamhaus DROP (inbound and outbound), Feodo Tracker (outbound, so infected devices cannot reach their control servers) and the DoH server list (outbound only). If you block an address, the firewall also drops its replies to connections you open yourself.
• Not real time: the lists are renewed several times a day, the free daily state of the v64 Blocklist once a day. New attackers are still missing, and attackers change their addresses.
• No replacement for updates, strong passwords, two-factor login and keeping only the ports open that you need. IPv64.net explicitly asks you not to rely on the lists alone.
• Size: large lists (countries, continents, cloud networks) can exceed the table limits of small routers or firewalls. Check how many entries your device can handle.
• Terms of the sources: the entries come from the respective projects, and their licence still applies (see overview). DShield, for example, is licensed under CC BY-NC-SA 2.5, so not for commercial use.

All lists at a glance

Every list has an ID; it is part of the file name and of the index.json. “In all” means the list is part of the combined list all. Size is the number of entries (addresses and networks) according to index.json as of 26 October 2026; it changes all the time.

The false-positive ratings come from the IPv64.net integration guide. “By design” means the list hits exactly the group it describes (e.g. all Tor users) – whether that is a false positive depends on your use case.

The lists in detail

IPv64.net takes the entries from the source projects and prepares them (see formats). What is on a list is decided by the respective project.

Spamhaus DROP (spamhaus_drop)

Source: Spamhaus “Don't Route Or Peer”, IPv4 and IPv6. Content: networks that Spamhaus lists as controlled or hijacked by criminals. Use: for everyone, inbound and outbound – the list with the fewest false positives and the best starting point. Risk: very low.

FireHOL Level 1 (firehole_l1)

Source: FireHOL Level 1, a curated collection of several lists (including Spamhaus DROP and Feodo). Content: IPv4 only. IPv64.net removes the reserved networks that FireHOL also includes (see formats). Use: a good default for routers and servers. Risk: low. The ID is spelled firehole_l1 (with an “e”).

DShield (dshield1)

Source: DShield / SANS Internet Storm Center. Content: the 20 most active attacking /24 networks, IPv4 only. Use: in addition to another list. Risk: low. Licence: CC BY-NC-SA 2.5 – not for commercial purposes.

blocklist.de All (blocklistde_all)

Source: blocklist.de. Content: addresses that attacked SSH, mail, web and other services in the last 48 hours, IPv4 and IPv6 – the largest single list in all. Use: servers reachable from the Internet. Risk: medium; it often contains infected home connections with changing addresses.

Emerging Threats Compromised (et_compromised)

Source: Emerging Threats (Proofpoint). Content: known compromised hosts, IPv4 only. Use: in addition to another list. Risk: low.

abuse.ch Feodo Tracker (feodo)

Source: abuse.ch Feodo Tracker. Content: command and control servers of botnets such as Emotet, Dridex and QakBot. The list is almost empty at the moment but gets entries again as soon as new botnets appear. Use: mainly outbound, so infected devices cannot reach their servers. Risk: very low.

Tor exit nodes and all Tor nodes (tor_exit, tor_all)

Source: directly from the Tor Project (Onionoo), IPv4 and IPv6. Content: tor_exit contains the exit nodes – that is where Tor users arrive at your service. tor_all contains all running relays. Use: only if you deliberately want to lock out Tor users. Risk: by design; both lists are part of all, but not of all_notor.

CINS Army (cins_army)

Source: CINS Army from the Sentinel IPS network. Content: up to 15,000 addresses with a poor reputation, IPv4 only. Use: servers that see a lot of scanning. Risk: medium; not in all.

IPsum Level 3 (ipsum_l3)

Source: IPsum. Content: addresses listed on at least three public blocklists, IPv4 only. Use: servers that see a lot of scanning. Risk: medium; not in all.

DoH servers (doh_servers)

Source: DoH-IP-blocklists, IPv4 and IPv6. Content: public DNS over HTTPS servers. Use: outbound only – a LAN rule with destination = list makes sure devices cannot bypass your own DNS filter (e.g. DNS64 in Node64) via DoH. Inbound, the list makes no sense. Not in all.

Cloud networks: Cloudflare, Amazon AWS, Google Cloud (cloudflare, aws, gcp)

Source: the address lists that Cloudflare, AWS and Google Cloud publish themselves, IPv4 and IPv6.

• cloudflare is meant as an allow list: if your server should only be reachable through Cloudflare, you allow only these networks.
• aws (all AWS networks) and gcp (Google Cloud customer networks, without Google services) block data centres that many scanners and bots come from. But you also block every legitimate service running there.

None of the three is in all.

AI crawlers: v64 AI Bots (ai_bots) and user agent list

Source: the official address lists of the operators: OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User), Perplexity (PerplexityBot, Perplexity-User), Common Crawl (CCBot), Mistral (MistralAI-User) and Google-Agent. Content: about 310 networks, including fetches triggered by a user in a chat. Networks shared with normal search (Googlebot, Bingbot, Applebot) are deliberately left out. Which network comes from which source is shown in ipv64_blocklist_ai_bots_sources.txt. If a source fails, its last valid state is kept. Not in all.

There is also a user agent list – not an IP list – mirrored daily from ai.robots.txt (MIT): ipv64_ai_useragents.txt (one token per line), ipv64_ai_useragents.json (with operator, purpose and a flag for fetches on behalf of users) and ipv64_ai_robots.txt (a ready-made robots.txt block). Match the tokens case-insensitively against the User-Agent header in your web server or reverse proxy.

Combined lists: all and all_notor

The combined lists merge all lists marked “in all = yes”, without duplicates: Spamhaus DROP, FireHOL Level 1, DShield, blocklist.de, ET Compromised, Feodo Tracker and – only in all – the two Tor lists.

• all – everything together, including Tor (about 37,800 entries). Tor users are blocked too.
• all_notor – the same without Tor (about 29,400 entries). For servers that should block attackers but not Tor users.

Not included are the large reputation lists (CINS, IPsum), the special lists (DoH, cloud, AI bots) and the v64 Blocklist. Add them separately if you need them. False positives: medium, mainly because of blocklist.de.

The v64 Blocklist from the Honeypot64 network

The v64 Blocklist is IPv64.net's own list. It is built from the reports of the community's Honeypot64 sensors. A honeypot is a trap without a real service: anyone who tries to log in there, exploits a vulnerability or scans its ports has no business there. Honeypot64 runs as a module in Node64, the IPv64.net home network container, and reports its observations to IPv64.net every 10 minutes.

How an address gets onto the list

• IPv64.net evaluates the reports every 30 minutes over a window of 14 days.
• An address is only listed once sensors of at least three independent accounts have reported it. Accounts are counted, not sensors; accounts whose sensors sit in the same network count only once together. When more than 150 accounts report, it is 2 % of them (rounded up, at most ten). The type of attack does not matter for this; new accounts and sensors whose reports are rarely confirmed by others count less. Anonymous sensors (reports without an API key) all count together as one account with half weight: they confirm attackers but never put an address on the list on their own.
• IPv6 per /64: reports for all addresses of a /64 network count together, and the whole /64 is listed – changing the address inside the own network does not escape the list. Releases also apply to the whole /64. IPv4 stays with single addresses.
• Never listed are private and reserved addresses, the sensors themselves, IPv64.net infrastructure, Cloudflare and released addresses. Research scanners (e.g. Shodan, Censys) are not on the list either.
• Every listed address has a confidence score from 0 to 100, shown by the IP lookup. It is for information, and login attempts and exploits weigh more in it than mere scans; whether an address is listed is decided by the threshold.

One list: v64 (no more sub-lists)

The v64 Blocklist is one list with the ID v64: all listed attackers (logins, exploits, scans), without research scanners. Use: servers reachable from the Internet, in addition to another list. It contains single addresses, is not part of all or all_notor and is licensed under CC BY 4.0 (IPv64.net Honeypot64), provided as is without warranty.

The former sub-lists v64_ssh, v64_web, v64_mail, v64_rdp, v64_scanner and v64_research no longer exist since October 2026; IPv64.net removed their files from the daily state and the live state. If you use one of them, switch to v64, e.g. https://ipv64.net/blocklists/ipv64_blocklist_v64.txt.

How long an address stays on the list

Without new attacks, an address drops off by itself after 14 days. If it keeps attacking, it stays listed.

Daily state and live state

Everyone gets the complete v64 Blocklist free of charge. The only difference is how current they are:

You fetch the live state with a personal list token that you create while logged in at ipv64.net/honeypot/token.php. IPv64.net checks the entitlement on every request; without it, the same address delivers the daily state. Programs fetch the token via API v2 with GET https://ipv64.net/api/v2/honeypot/list-token; in Node64, PROXY64 does this automatically with your API key. Details under Live state with list token.

How large both states currently are and how old is shown by IPv64 Secure (see below).

IP lookup and release (delisting)

Whether and why an address is on the v64 Blocklist is shown by the IP lookup at ipv64.net/honeypot/ip.php: number of reporting accounts, confidence score, type of attacks, lists and period. The same lookup is available via API v2 (GET https://ipv64.net/api/v2/threat/ip/{ip}). The page does not check other lists such as Spamhaus or blocklist.de.

If your address is listed by mistake, request a release there:

1. Submit a request
   Enter a reason (10 to 2000 characters) in the IP lookup. When logged in, the request is valid immediately; without login you confirm it via a link sent by e-mail (valid for 48 hours). At most 3 requests per day and sender (IPv6 per /64).
2. Automatic check
   If the address does not touch any sensor for 24 hours after confirmation, it is released automatically and protected for 30 days. If it keeps attacking, if there are several requests or if it belongs to a provider or cloud network, IPv64.net reviews it manually.
3. Removal from the lists
   The address drops out of the live state with the next evaluation (every 30 minutes) and out of the daily state with the next daily update.

Common causes for a listing are an infected device in your own network (camera, router, NAS), a shared address (mobile network, CGNAT, VPN) or a newly assigned address that someone else used before. For your own networks and DynDNS addresses there is an early warning by e-mail at ipv64.net/honeypot/watch.php. For each address it tells you how often, with which service, port and type of attack it showed up in the last 14 days – never the sensors or their owners. For networks without proof and for DynDNS addresses it only reports addresses that are on the v64 blocklist; for DynDNS addresses without port and rule, and the last sighting only to the day.

IPv64 Secure and live map

The page IPv64 Secure (German: ipv64.net/v64_secure?lang=de) sums up the protection features of IPv64.net. It shows the daily state and the live state of the v64 Blocklist side by side with count and age, how many more attackers are currently listed live and how many sensors reported in the last 24 hours. It also lists the ways to use the list (Node64, list token, Use blocklists) and links to the statistics, the IP lookup and the live map.

The public live map at ipv64.net/honeypot/live.php shows attacks on the Honeypot64 sensors as arcs from the attacker's country to the sensor's country, plus counters and a table of the latest attacks. It replays the last hour with a delay and is rewritten every 2 minutes. Attackers appear only shortened (IPv4 /24, IPv6 /48), sensors only as a country, without credentials.

Text lists from the honeypot

Besides the IP lists, IPv64.net publishes what attackers try on the sensors – for password policies, web servers and WAFs. They are based on the last 30 days and only include what several accounts reported. The lists are rewritten every 6 hours, licence CC BY 4.0:

• ipv64_passwords.txt (up to 10,000 passwords, most used first) and ipv64_passwords_sha1.txt (SHA-1, upper case, sorted),
• ipv64_usernames.txt (up to 10,000 usernames),
• ipv64_bad_useragents.txt (up to 2,000 user agents of attack tools) and ipv64_bad_useragents.nginx.map (nginx map, variable $ipv64_bad_ua),
• ipv64_attack_paths.txt (up to 5,000 requested paths) and ipv64_attack_paths.nginx.conf (nginx location blocks with return 403, only for servers that do not serve these paths themselves).

Whether one of your passwords is on the list can be checked at ipv64.net/honeypot/password.php; only the start of the SHA-1 hash is transmitted. Statistics of all sensors are at ipv64.net/honeypot/stats.php. There, the “v64 Blocklist (live)” tile also shows the percentage of addresses that are on no other attacker list at IPv64.net (categories attack and botnet, including CINS and IPsum) – only the Honeypot64 network knows these attackers.

Country and continent lists

For geoblocking there is one list per country (239 countries) and per continent: Europe, Asia, Africa, North America, South America and Oceania. They are based on the official allocation data of the five regional Internet registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), which IPv64.net downloads daily. If one registry fails, the old data stays in place.

• Country (ISO code, upper case): https://ipv64.net/blocklists/countries/ipv64_blocklist_DE.txt, IPv4 only …/countries/ipv64_blocklist_v4_DE.txt, IPv6 only …/countries/ipv64_blocklist_v6_DE.txt
• Continent: europe, asia, africa, north_america, south_america, oceania, e.g. https://ipv64.net/blocklists/countries/ipv64_blocklist_europe.txt

Which countries belong to a continent is listed in the index.json under regions. There are no MikroTik files for countries and continents.

For your own tools there is also country_ranges.txt.gz: a compressed text file with one line <country> <first IP> <last IP> each (ISO code), IPv4 first, then IPv6, sorted ascending, adjacent ranges merged. Honeypot64 and Node64 use it to determine the origin of attackers – for the statistics, the world map and the live map.

• Source: unlike the country lists, this file gives the location of an address, not the country of its holder. It is based on DB-IP “IP to Country Lite”, which IPv64.net downloads once a month; addresses without a country at DB-IP are filled from the registry data. Without a valid DB-IP file it contains only the registry data, as before. The header lines of the file and the geo field of the index.json name source and licence.
• Licence: the DB-IP location data is licensed under CC BY 4.0. If you use the file, credit the source, e.g. “IP country data by DB-IP.com (https://db-ip.com)”.
• The country and continent lists above stay with the registry data.

Formats and addresses

All files are under https://ipv64.net/blocklists/. Every list comes in several variants; <id> is the ID from the overview:

This also applies to the combined lists (all, all_notor) and the v64 Blocklist. Example: https://ipv64.net/blocklists/ipv64_blocklist_v4_firehole_l1.txt.

Text format

• One address or network in CIDR notation per line, without comments or headers. Single addresses are written as /32 or /128.
• Duplicates and networks contained in a larger network of the same file are removed; entries are sorted numerically.
• Non-routable ranges are removed: private networks, CGNAT (100.64.0.0/10), loopback, link-local, multicast and documentation networks. Private addresses of your home network are therefore never on a list.
• A file can be empty, e.g. the IPv6 variant of a pure IPv4 list.

192.0.2.0/24
198.51.100.17/32
2001:db8:1234::/48

MikroTik format

The .rsc files are ready-made RouterOS scripts. Each file first removes its own old entries and then adds the current ones to the address list IPv64-<id> (e.g. IPv64-firehole_l1). This lets you import several lists side by side.

# IPv64.net Blocklist - 2026-10-26 18:06 UTC - https://ipv64.net/v64_blocklists
/ip firewall address-list
remove [find list=IPv64-dshield1 comment="IPv64 Blocklist"]
add list=IPv64-dshield1 address=192.0.2.0/24 comment="IPv64 Blocklist"

index.json: all lists in machine-readable form

For scripts and tools, https://ipv64.net/blocklists/index.json describes all lists. The generator rewrites the file on every run; Node64 builds its selection from it. All file names are relative to base.

Every entry in lists has these fields:

Example with jq: print all lists with count and update time.

curl -s https://ipv64.net/blocklists/index.json \
  | jq -r '.lists[] | "\(.id)\t\(.count)\t\(.in_all)\t\(.updated)"'

The user agent list of the AI crawlers is meant to be listed under data, but currently is not. Its files can still be downloaded (see AI crawlers).

Updates and fair use

If the download of a source fails, the previous list stays in place. The age of each list is shown in the updated field of the index.json; the list page marks lists older than two days as “Outdated”.

Which list for whom?

How to add the lists is described under Use blocklists. Answers to common questions are in the FAQ. You can suggest a missing list in the v64.tech forum, ideally together with its source.

Found a mistake or missing something? Tell us in the v64.tech forum. · Updated: 2026-11-02