Another massive distributed HTTP flood is currently hitting git.friendi.ca and causing slow responses. Operationally, this has to be treated as an application-layer DDoS attack, although we cannot determine from the logs whether disruption or aggressive scraping is the original intent.
In a fresh five-minute sample, Anubis saw 56,457 requests carrying client IPs from 50,470 different addresses:
- 48,519 requests via IPv4
- 7,938 requests via IPv6
- 43,621 unique IPv4 addresses
- 7,407 unique IPv6 addresses
We compared all addresses against the Tor Project’s official, target-specific exit list for our server on port 443. There were zero Tor exit nodes in the sample.
The traffic is spread across many networks and regions and appears more consistent with a large residential-proxy or compromised-device network than with Tor. We are investigating additional capacity protection that does not lock out legitimate users.
utzer
in reply to utzer • • •utzer
in reply to utzer • • •Update: The flood is still ongoing and intensified again today.
Between approximately 17:50 and 22:03 CEST, Anubis recorded at least 141,090 challenges from 136,393 different IP addresses, peaking at roughly 35,800 challenges per hour.
Most of the current traffic is still targeting the friendica-addons pull-request list. Our temporary rate limit is successfully keeping this traffic away from the backend: the rest of git.friendi.ca remains fast and accessible, normal Git access works, and server load is currently back to normal.
The affected pull-request page may continue to return “Too Many Requests” while the flood persists.
utzer
in reply to utzer • • •pasjrwoctx👽
in reply to utzer • • •did I make any sense
utzer
in reply to pasjrwoctx👽 • • •@pasjrwoctx👽 Thanks, I checked the user agents. The pattern looks highly coordinated.
Out of 164,435 Anubis challenge requests, there were only 160 distinct user-agent strings. The top ten account for 96.79% of all requests and were used almost perfectly evenly:
These are old browser versions from around 2023. Combined with almost one IP per request, this looks like a single coordinated tool rotating through a fixed list of spoofed browser identities and a very large residential/proxy network. It does not prove whether the objective is scraping or disruption, but it is clearly not ordinary independent crawling.
utzer
in reply to utzer • • •@pasjrwoctx👽
More details regarding user-agent distribution
Retained log window: 2026-08-14 17:50–22:42 CEST
Challenge requests: 164,435
Distinct user-agent strings: 160
Share represented by the top ten: 96.79%
The almost perfectly even distribution among the first ten identities is particularly striking.
tom s
in reply to utzer • • •pasjrwoctx👽
in reply to utzer • • •@utzer ok so you could block those user agents I have something like # Fake browser detection
RewriteCond %{HTTP_USER_AGENT} (Chrome/[0-9]{3}|Chrome/1[3-9][0-9]|Chrome/150|Firefox/1[3-9][0-9]|Safari/60[0-9]|Version/17)
[NC]RewriteCond %{HTTP_ACCEPT_LANGUAGE} ^$
RewriteRule ^ - [G,L]
RewriteCond %{THE_REQUEST} "GET\shttp"
[NC]RewriteRule ^ - [G,L] and then # 1. BLOCK BAD BROWSER NAMES / BOT FRAMEWORKS
RewriteCond %{HTTP_USER_AGENT} (CCBot|SearchEngineBot|Pandalytics|UCBrowser|ZoneProjectBot|Embarcadero\sURI\sClient|Xenu\sLink\sSleuth|siteradar|SignalsBot|fun-cert-watch|SERankingBacklinksBot|Pinterestbot|CMS-Checker|HeadlessChrome|Puppeteer|SeznamBot|Sogou|8LEGS|HTTrack|cherrypicker|AhrefsBot|BLEXBot|DotBot|MJ12bot|PetalBot|SemrushBot|BuiltWith|Viewer/99|Python|aiohttp|curl|Wget|libwww|Go-http-client|GeedoShopProductFinder|DuckDuckBot|node|IMJ-CompanyPage-Scraper|baidu|RootEvidence|NetAPI\sv1|Scrapy|Bingbot|SummalyBot|got|HUNT-Bot|CibraxScanner|SalesOS-CompanyVerifier|RecordedFuture|SurdotlyBot|panscient\.com|Xiaomi|Android.*Firefox|GPTBot|ClaudeBot|BardBot|LLMScraper|Firecrawl|Crawl4AI|ia_archiver|archive\.org_bot|Google|wp2shell|okhttp|Cortex-Xpanse|Mozilla\.5\.0\.compatible;\.MSIE\.10\.0;\.Windows\.NT\.6\.1;\.Trident/6\.0|facebookexternalhit|facebookexternalua|Version\.13\.0\.3\.Mobile\.15E148\.Safari\.604\.1|iPhone.*Version/13\.0\.3|Safari/604\.1|cms-scanner|OAI-SearchBot|ChatGPT-User|PerplexityBot|Perplexity-User|Amazonbot|Applebot-Extended|Meta-ExternalAgent|Meta-ExternalFetcher|cohere-ai|DeepSeek|Bytespider|Diffbot|Omgilibot|Omgili|Google-Extended|Google-CloudVertex|MistralAI-User|OAI-AdsBot|YouBot|anthropic-ai|NosibleBot) [NC,OR]
RewriteCond %{THE_REQUEST} "^[A-Z]{3,9}\s+https?://"
[NC]RewriteRule ^.*$ - [G,L]
# 2. BLOCK SPAM WEBSITES (REFERRERS)
RewriteCond %{HTTP_REFERER} (baidu\.com|bsky\.(net|com|app)|facebook\.com|meta\.com|threads\.(com|net)|instagram\.com|google\.com|googleusercontent\.com|youtube\.com|x\.com|t\.co|twitter\.com|x\.ai|bing\.com|yahoo\.com|yandex\.com|duckduckgo\.com|microsoft\.com|amazon\.com|brave\.com|semalt\.com|buttons-for-website\.com|darodar\.com|blackhatworth\.com|ilovevitaly\.com|priceg\.com|ranksonic\.com)
[NC]RewriteRule ^.*$ - [G,L]
###############################################
# SAFE BOT & SCRAPER KILLER (FRIENDICA-COMPATIBLE)
###############################################
# Kill obvious scanners by User-Agent
RewriteCond %{HTTP_USER_AGENT} (nmap|nikto|acunetix|sqlmap|fimap|nessus|openvas|arachni|wpscan|dirbuster|fuzzer)
[NC]RewriteRule ^ - [G,L]
# Kill requests with directory traversal attempts
RewriteCond %{QUERY_STRING} (\.\./|\.\.\\|%2e%2e|%5c)
[NC]RewriteRule ^ - [G,L]
# Kill malformed absolute URLs
RewriteCond %{THE_REQUEST} "^[A-Z]{3,9}\s+https?://"
[NC]RewriteRule ^ - [G,L]
# Kill empty User-Agent ONLY if NOT federation
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteCond %{REQUEST_URI} !^/\.well-known/
[NC]RewriteRule ^ - [G,L] which has cut down a lot of bad traffic from getting 200, and getting hit with a 410 when it knocks on my door, I would start there, because blocking ips is fun and easy, but if they are being spoofed, they will just spoof more, and worse when they get recycled to actual valid users then you lose traffic, I have found the agent blocking is more effective, they are not willing to rewrite every script to adjust for that so for now it seems to be the fastest block, and if it is getting that hard, run it through cloudflare on the free side proxied for a while anyways to help slowdown and divert the bad traffic, it will keep your server happier, I know not everyone is a fan of that, but somtimes you have to change the route to stay on the road
utzer
in reply to pasjrwoctx👽 • • •utzer
in reply to utzer • • •tom s
in reply to utzer • • •@utzer @pasjrwoctx👽
Das hat einige Begleiterscheinungen, die man nicht möchte.
Prüf aus dem Log das tatsächliche Header-Profil des Floods (Accept-Language leer/nicht leer, Anzahl eindeutiger Sec-CH-UA/Accept-Kombinationen). Wenn da ein konstanter Unterschied zu echten Browsern ist, kann ich dir eine gezielte Regel bauen, die genau diesen Header-Set blockt statt der UA-Version. Das ist der einzige UA-nahe Filter, der hier sauber zwischen Flood und echten Nutzern trennt.
utzer
in reply to tom s • • •@tom s aber sind das nicht alles echt alte UA, also wenn ich die blocke was kann das für Nebeneffekte haben? Firefox 119 oder 120 ist doch echt alt.
Aber ich schaue morgen nochmal ob ich es weiter optimieren kann.
@pasjrwoctx👽
tom s
in reply to utzer • • •@utzer @pasjrwoctx👽 Der Flood rotiert UAs bewusst gleichverteilt durch 160 Identitäten – das ist ein Tool, das darauf gebaut ist, dass man es am UA erkennt. Hier wirst du also mit UA-Blocking nur die nächste der 160 Identitäten sehen, nicht weniger Traffic.
Was helfen kann ist TLS-Fingerprint und die Challenge-Ökonomie (Anubis-PoW-Difficulty).
utzer
in reply to tom s • • •@tom s Anubis hält dem Ansturm gar nicht Stand. Das Setup ist so, dass der Reverse Proxy das aufiltern muss, Anubis kommt erst danach, dann der Dienst.
Ich schau mal es dann neue UA gibt.
tom s
in reply to utzer • • •if ($http_accept_language = "") { return 444; }444 = Verbindung sofort verwerfen, keine Antwort
Das musst du aus dem Log lesen, nicht raten oder probieren!
tom s
in reply to utzer • • •Ich kenne Deinen Aufbau ja nicht, mag nicht so gerne raten...
utzer
in reply to tom s • • •@tom s Es ist tatsächlich ein neuer dominanter User-Agent nachgerückt:
Android 6 / Nexus 5 / Chrome 65In einer Stunde kamen damit 527 Requests von 526 unterschiedlichen IPv4-Adressen. Das sieht also weiterhin nach demselben rotierenden Proxy-Netz aus.
Das Headerprofil hat sich allerdings geändert:
vorher:
Accept-Language: en-US,en;q=0.9jetzt:
Accept-Language: en-US,en;q=0.5Priority:
u=0, iist gleich geblieben, wird aber auch von echten Browsern verwendet. Darauf kann ich daher nicht sauber filtern.TLS wird bereits im Reverse-Proxy-Nginx terminiert. Anubis sitzt dahinter und erhält nur noch normales HTTP. Anubis kann in diesem Aufbau deshalb keine TLS-/JA3-Fingerprints ermitteln. Dafür müsste ich den ClientHello vor der TLS-Terminierung am Nginx separat erfassen.
tom s
in reply to utzer • • •@utzer tja, q=0.9 -> q=0.5 Das bedeutet meist, dass der Betreiber beobachtet und anpasst. Egal auf was an dieser Stelle.
nginx kann euch einen groben TLS-Fingerprint direkt ins Access-Log schreiben, das ist mehr als nix.
nginx -tund reload.Mein Chatfenster mach das leider ein wenig kaputt.
Chrome 65 ist gut gewählt, aber so kannst Du rausfinden, ob es überhaupt einer ist.
Eins noch, löst das Ding die Anubis-Challenges?
Im SLOG_LEVEL=DEBUG-Log von Anubis siehst Du das. Wenn er sie nicht löst, verbrennt er nur Anubis-CPU und es kann weg.
utzer
in reply to tom s • • •@tom s Danke für die Hinweise. Ich habe das jetzt in einer kurzen Stichprobe getestet:
Ergebnis für den angeblichen Android-6-/Chrome-65-Client:
Die 13 Verbindungen ergaben zunächst zwölf verschiedene TLS-Profile. Die Unterschiede bestanden allerdings ausschließlich aus zufälligen GREASE-Werten. Nach deren Normalisierung hatten alle Verbindungen exakt dasselbe TLS-Profil.
Der TLS-Fingerprint allein eignet sich trotzdem nicht für eine sichere Sperre: Dasselbe normalisierte Profil wurde in der Stichprobe auch von aktuellen Chrome-142-, Chrome-148- und Chrome-149-Clients verwendet.
Die Kombination ist jedoch eindeutig verdächtig: Der User-Agent behauptet
Android 6 / Chrome 65, verwendet aber einen modernen TLS-1.3-/HTTP/2-Stack und über alle IP-Adressen hinweg dasselbe vollständige HTTP-Headerprofil.Auch der User-Agent
Mozilla/5.0 (compatible; crawler)löste keine seiner zwölf Challenges.Der aktuelle Flood verbraucht in dieser Stichprobe also hauptsächlich Anubis-Ressourcen und gelangt nicht bis zu Forgejo.
UA-Filter und normales Anubis-Logging sind inzwischen wieder aktiv.
tom s
in reply to utzer • • •@utzer hmm, der Zeitraum ist eigentlich viel zu kurz.
Warum Der Anubis bei diesem bisschen Rauschen schon umfallen soll, ist sehr merkwürdig. Irgendwo ne Fehlconfig am Werk.
ca. 10 Challenges/s, das ist kein Flood im wirklichen Sinne.
DEBUG-Logs und METRICS_BIND-Metriken suchen -> Speicher-Anstieg, offene Verbindungen, OOM? Irgendwas hakt da.
Das könntest Du als temporäre Spielerei aufnehmen. Würde halt nicht lange halten. Am besten erst eine Stunde oder Zwei nur loggen statt 444, um zu sehen, wen Du triffst!
Das ist also hier vermutlich nur ein Vorspiel.
Werden zukünftig Challanges gelöst, hat der Schlingel auf eine JS-Version umgeschwenkt. Erst dann wirds lustig. Bis dahin musst Du das Anubis genauer durchschauen.
Eindeutiges könntest Du auf DENY statt CHALLENGE stellen, das kann ich aus der Ferne nicht beurteilen.
utzer
in reply to tom s • • •tom s
in reply to utzer • • •@utzer guter Punkt. Für nginx sind ca. 185/s zwar ok, aber dahinter kann das enger werden.
Ok, würde vorschlagen, den uaold13 scharf stellen und zudem noch:
Damit fällt schon mal Last ab.
Nun gilt es den Zähler von gelösten Challenges im Auge zu behalten.
Für das Beurteilen von Verbindungen, einfach mal nen Tag lang anschauen, was so passiert, z.B.
Wäre ein Anfang.
tom s
in reply to tom s • • •@utzer
hab das zuvor ein wenig unglücklich ausgedrückt. ich meinte die input rule mal in ruhigen, normalen Zeiten laufen lassen. so 4x am Tag für jeweils ne Stunde. Aber vielleicht kennst Du die normale Auslastung ja selber schon.
Je nachdem, was Deine Messung ergibt, könnte man sowas beispielsweise einbauen: Rate: 50/s und Burst: 150
Ist nur ne Idee, um den Traffic zu deckeln.
tom s
in reply to utzer • • •tcpdump oder tshark, Anubis kann JA3 selbst berechnen, wenn man es dort als Log-Feld ergänzt
utzer
in reply to tom s • • •tom s
in reply to utzer • • •@utzer
Nein. Fast.
50.000 weltweit gestreute IPs mit identischen Signaturen = eine einzige Software, die durch ein rotierendes Proxy-Netz sendet.
gleicher TLS-/JA3-Fingerprint
dieselbe feste UA-Liste, perfekt gleichverteilt rotiert
dasselbe Ziel
....
utzer
in reply to utzer • • •Further update: I have replaced the temporary path-specific rate limit with an exact User-Agent filter.
The ten evenly rotated browser identities responsible for 96.79% of the Anubis challenges, plus the explicit `Mozilla/5.0 (compatible; crawler)` identity, are now rejected by Nginx before reaching Anubis or Forgejo.
The pull-request and issue pages are available normally again, regular web and Git access remain unaffected, and backend load is close to zero.
The crawler has since introduced a new identity:
Android 6 / Nexus 5 / Chrome 65This identity produced 527 requests from 526 different IPv4 addresses within one hour, confirming the rotating proxy-network pattern. However, the overall volume reaching Anubis has dropped from roughly 35,800 challenges per hour at the peak to about 1,000 per hour, so the exact filtering is currently working very well.
This remains a temporary mitigation because User-Agent strings can be changed at any time.
pasjrwoctx👽
in reply to utzer • • •which has cut down a lot of bad traffic from getting 200, and getting hit with a 410 when it knocks on my door, I would start there, because blocking ips is fun and easy, but if they are being spoofed, they will just spoof more, and worse when they get recycled to actual valid users then you lose traffic, I have found the agent blocking is more effective, they are not willing to rewrite every script to adjust for that so for now it seems to be the fastest block, and if it is getting that hard, run it through cloudflare on the free side proxied for a while anyways to help slowdown and divert the bad traffic, it will keep your server happier, I know not everyone is a fan of that, but somtimes you have to change the route to stay on the road
Jonathan Lamothe
in reply to utzer • •Friendica Support reshared this.