How the FSF sysadmins block botnets with reaction

My personal preference is to 'ip route add blackhole ${net}' as it has the lowest CPU overhead and I can add hundreds of thousands of CIDR blocks with no noticeable impact. The only downside is that it won't stop UDP packets from getting to a UDP listener. There will not be a response but the application will still see it. For my TCP daemons it's great.

    grep -m1 -E ^Tot /proc/net/fib_triestat ;ip route | grep -Fc blackhole
    Total size: 56735  kB
    426951

I also use a couple generalized rules in nftables raw table that keeps a lot of beyond poorly written bots away including hping3 tcp floods and masscan. My rules to port 443 are stateless. One must not taunt the state table.

That's interesting. I haven't used fail2ban for a long time, but reaction is worth evaluating. Unfortunately, that post does not describe their full configuration. Maybe it's on purpose, so that attackers can't adjust to fit.

My experience is that modern web scraping had no obvious pattern, since it is proxied through many IPs. The last time a server was failing to handle the pressure, we decided to temporarily ban IPs from some Asian regions. How does the FSF decide to ban an IP?

Why do they use iptables + ipset instead of nftables? Is there a technical reason or is it just legacy? AFAIK, Nftables is more performant, and IMO simpler. And it has native sets, see https://wiki.nftables.org/wiki-nftables/index.php/Sets

> This software is gay, trans and anticolonialist. If you're uncomfortable with that, please don't use it

Weird message to include in AGPLv3 licensed software (which explicitly allows people to use software however they like, regardless of their beliefs or feelings).

> We placed our regular expressions in fail2ban, and found that we were hitting the maximum rules that could be added to UFW firewall rules on our systems which showed degradation around 65,000 rules

Firewalld had a similar issue up until recently as well.

It's somewhat interesting to see the FSF's approach to this. From what I understand they can't really use something like anubis since they want their websites to be accessible without javascript:

https://www.gnu.org/philosophy/javascript-trap.html

Users can't consent to running a page's javascript the way they can consent to running a program they've intentionally downloaded, so it's effectively "non-free" regardless of license.

"Many sysadmins know about fail2ban..." and many will now know about reaction. But why will the result be any different than fail2ban? It won't.

I identify features (which can be expressed as firewall rules) from log data; I write totals to a temporary store (Redis). I have periodic tasks which scan the temp store for patterns which exceed thresholds. When that occurs, fail2ban creates the appropriate rules. This occurs in depth and in concentric rings.

Et tu?

>Popa botnet

It's no more of a botnet than ProtonVPN for example. Apps intentionally added the Popa SDK to their apps as a monetization method. This allows apps without ads and tracking to be financially viable. I would expect FSF to support apps being able to move off of monetization schemes that depend on tracking people so it is disappointing for them to put such alternative monetization technologies in a negative light.

are scrapers attackers?

I get they're DDoS; but take the mask off, and arn't they just the AI monied interests that fund the FSF? and a lot of them are just active inference, eg, the user is trying to ask about something and the AI monied interests setup a web scraper to go and get that data.

Just seems like no one wants to call out the hand that feeds them in a human centipede that's best described as the torment nexus.