HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
firehol
blocklist-ipsets
Shell2018–2026
firehol / blocklist-ipsets

blocklist-ipsets

ipsets dynamically updated with firehol's update-ipsets.sh script

2Distinct people
26Mentions
0Explicit recommenders
4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

ipsets dynamically updated with firehol's update-ipsets.sh script

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:01:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year26 dated mentions

Observed mentions: 2018-08-08 17:08:51 UTC to 2026-09-11 12:05:20 UTC.

0123452018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC321
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC211
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC505
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC404
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC303
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC303
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC303

What Hacker News says

3 sources
Do you have a list of the addresses that were hammering your site? Have you tried any of the techniques I list here? [1] Do sets of the IP's show up in here [2]? Are the bots mostly residential, VPS, Tor? What is the HTTP protocol breakdown? HTTP/1.1, 2.0, 3.0? Are they missing any expected client headers? Have you tried blackhole routing any of them from an out of band management console? # only useful if not behind a CDN for Ip in $(cat /dev/shm/list-of-attackers.ipset);do ip route add blackhole "${Ip}" 2>/dev/null;done [Edit] appears you are behind Cloudflare so the blackhole would be up to them. One could still return a 429 or 525 to the attackers. [1] - https://nochan.net/b/Internet-Crap/20260606-How-To-Block-Som... [2] - https://github.com/firehol/blocklist-ipsets/
In Understanding the recent DDoS attack against Read the Docs
Usually the IPs are 80% or so in one country (e.g. Brazil, US, Vietnam or India) It sounds like there is the option to at least reduce the load by up to 80%. That's at least a start. This repo [1] is not perfect but it's a start. I would disable IPv6 access to the site after removing the IPv6 DNS records and waiting a day so that attackers are forced onto IPv4 and clone this repo [1] or use one of the GeoIP databases to limit access from specific countries. That repo also contains known proxies. That may account for another percentage of that remaining 20%. As the content is academic in nature I don't know how your team feels about blocking Tor, but there is also a list of many (not all) of the last 30 days of Tor exit nodes in that repo. The blocks would not have to be permanent, just enabled during the storms if your team so desired.
Read the rest
# verify you have console access to the server before doing things like this: for BadIP in $(grep -Ev ^# ipip_country_br.netset); do ip route add blackhole "${BadIP}" 2>/dev/null;done Example of country IP addresses for Brazil [2] As this is academia I don't know if there is a concept of service level agreement or a promise of availability, but during attacks the requests to specific URL's could be redirected to a static pre-compressed landing page served out of memory that says "Access to these documents limited during AI bot attacks, here is where to request a full download instead: " I forgot to mention, many of the AI bots are limited to HTTP/1.1. During an attack your server could redirect those request to a static page as well. Curious if you can tell by your access logs if the majority of the attack is HTTP/1.1 or HTTP/2.0. Most botters are too lazy to implement HTTP/2.0. Real browser clients use HTTP/2.0. Example of using HTTP/1.1 and HTTP/2.0 # Fist use HTTP/2.0 with headers I expect. curl -i --http2 \ -A "Mozilla/5.0 (X11; Linux x86_64; rv:151.0) Gecko/20100101 Firefox/151.0" \ -H "sec-fetch-mode: navigate" \ -H "accept-language: en-US,en;q=0.9" \ --url 'https://blawg.nochan.net/.env' # Then HTTP/1.1 for the lulz, pay attention to the Location redirect curl -i --http1.1 \ -A "Mozilla/5.0 (X11; Linux x86_64; rv:151.0) Gecko/20100101 Firefox/151.0" \ -H "sec-fetch-mode: navigate" \ -H "accept-language: en-US,en;q=0.9" \ --url 'https://blawg.nochan.net/.env' Some bots also do not hide that they are bots in that they say they are bot in their user-agent client header. That would be too easy so I doubt that is the case. [1] - https://github.com/firehol/blocklist-ipsets/ [2] - https://github.com/firehol/blocklist-ipsets/blob/master/ipip...
In Cloudflare CEO is lying to you about the bot traffic jump
One of the places to look it up would be bgp.tools [1] The IP is purported to belong to Amazon and the ASN has some interesting tags. [2] Any form of forwarded-for can be spoofed and should only be considered from expected up-stream proxies such as a CDN and they should have a CDN specific IP header that would be listed in their documentation. Typically the first column in access logs will be the REMOTE_ADDR which is the actual network connection but if using a CDN that would be the CDN IP. If a CDN does not have an option to block cloud and Tor CIDR blocks then that should be a feature request. 44.210.204.255 is included in 44.192.0.0/10 which is listed in the AWS CIDR ranges. Use one of the online subnet calculators to find IP ranges of CIDR blocks. This is likely a Tor exit node. Blocking the CIDR blocks I listed in the thread wou
Read the rest
ld have included this node as well. Here [3] are a few shell functions for getting some of the cloud CIDR blocks. I must have been inebriated when I wrote those. This site may not be reachable during blood moons or when the nanosecond is divisible by zero. Here [4a][4b] are a couple decent subnet calculators. There are some command line tools for playing with CIDR blocks and IP addresses to see if an IP is included in a CIDR block but this varies by Linux distribution so perhaps look for a generic python script. To get a list of Tor exit nodes to blackhole route, look at [5]. This updates often. Just clone the entire repo. Unless your site is related to government dissent or anonymous porn then most traffic from Tor exit nodes will likely just be bots and thus riff-raff. Seconds after I linked realhackers bots showed up and got a zero byte response. Poor lil HN servers must get a lot of trash non stop. I hope I get some delicious bots today. [1] - https://bgp.tools/ [2] - https://bgp.tools/as/14618 [3] - https://ai.realhackers.org/_get_cloud_cidr.txt [4a] - https://mxtoolbox.com/subnetcalculator.aspx [4b] - https://www.vultr.com/resources/subnet-calculator/ [5] - https://github.com/firehol/blocklist-ipsets/blob/master/clea...
In Amazonbot is finally respecting robots.txt

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.