Comment on Another massive distributed HTTP flood is currently hitting git.friendi.ca a

• utzer@f.utzer.de@f.utzer.de ⁨2⁩ ⁨weeks⁩ ago

  @tom_s Es ist tatsächlich ein neuer dominanter User-Agent nachgerückt:

  Android 6 / Nexus 5 / Chrome 65

  In 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.9
  jetzt: Accept-Language: en-US,en;q=0.5

  Priority: u=0, i ist 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.

  original

  • tom_s@friendica.ambag.es@friendica.ambag.es ⁨2⁩ ⁨weeks⁩ ago

    @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.
    

    log_format tlsinfo '$remote_addr $time_local "$request" $status '
                       'proto=$ssl_protocol cipher=$ssl_cipher curves=$ssl_curves '
                       'ua="$http_user_agent" al="$http_accept_language"';
    access_log /var/log/nginx/access.log tlsinfo;

    nginx -t und 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.

    original

    • utzer@f.utzer.de@f.utzer.de ⁨2⁩ ⁨weeks⁩ ago

      @tom_s Danke für die Hinweise. Ich habe das jetzt in einer kurzen Stichprobe getestet:

      
      

      • UA-Filter vorübergehend deaktiviert
      • Anubis auf DEBUG gestellt
      • separates TLS-Light-Logging in Nginx aktiviert

      
      Ergebnis für den angeblichen Android-6-/Chrome-65-Client:

      Requests:              13
      Unterschiedliche IPs:  13
      Challenges ausgestellt: 11
      Challenges gelöst:       0

      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.

      original

      • tom_s@friendica.ambag.es@friendica.ambag.es ⁨2⁩ ⁨weeks⁩ ago

        @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.

        
        

        /etc/nginx/conf.d/uaold13.conf:
        
        map "$ssl_protocol $http_user_agent" $uaold13 {
            default 0;
            "~^TLSv1\.3 .*Chrome/[0-6][0-9]\."   1;
            "~^TLSv1\.3 .*Chrome/[0-9]\."        1;
            "~^TLSv1\.3 .*Firefox/[0-5][0-9]\."  1;
            "~^TLSv1\.3 .*Edge/1[0-7]\."         1;
        }
        
        Im server-Block:
        
        if ($uaold13) { return 444; }
        
        doas nginx -t && doas /etc/init.d/nginx reload

        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.

        original

        • -> View More Comments
• utzer@f.utzer.de@f.utzer.de ⁨3⁩ ⁨weeks⁩ ago

  @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

  original

  • nick@hhmx.de ⁨2⁩ ⁨weeks⁩ ago

    @utzer@f.utzer.de

    Ich hatte neulich ähnliche Erlebnisse und habe dann begonnen, einige UserAgents via .htaccess zu blocken. Darunter alte Versionen von Chrome, Firefox, etc.

    Nebeneffekt: Man blockt ggf. mehr, als man denkt.

    Zum Beispiel habe ich festgestellt, daß der BingBot aktuell Chrome/116 im UserAgent angibt.

    @tom_s@friendica.ambag.es
    @pasjrwoctx@social.2ndshot.photos

    original

    • tom_s@friendica.ambag.es@friendica.ambag.es ⁨2⁩ ⁨weeks⁩ ago

      @nick @pasjrwoctx @utzer
      Eigentlich blockt man keine UAs und zudem nicht mit .htaccess, das lädt sich pro Request, ist sehr langsam, per-Directory.
      Und wie Du selbst ja festgestellt hast, mit Nebenwirkungen.

      original
  • tom_s@friendica.ambag.es@friendica.ambag.es ⁨3⁩ ⁨weeks⁩ ago

    @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).

    original

    • utzer@f.utzer.de@f.utzer.de ⁨3⁩ ⁨weeks⁩ ago

      @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.

      original

      • tom_s@friendica.ambag.es@friendica.ambag.es ⁨3⁩ ⁨weeks⁩ ago

        @utzer Firewall (vor dem Proxy) Per-IP-Connection-Limits mit hashlimit in nftables, drosselt den Connection-Sturm auf Anubis.
        Ich kenne Deinen Aufbau ja nicht, mag nicht so gerne raten...

        original
      • tom_s@friendica.ambag.es@friendica.ambag.es ⁨3⁩ ⁨weeks⁩ ago

        @utzer Hat der Flood ein leeres Accept-Language? Der schnellste Test: einmal eine Stichprobe aus euren Anubis-Logs ziehen und schauen, ob bei den Top-UAs auch Accept-Language: leer ist. Wenn ja, reicht beim nginx
        if ($http_accept_language = "") { return 444; }
        444 = Verbindung sofort verwerfen, keine Antwort
        Das musst du aus dem Log lesen, nicht raten oder probieren!

        original