Seit dem 21. Juni haben wir erhöhte Lasten auf dem Discourse-Forum von freeCodeCamp.org festgestellt. Die durchschnittliche CPU-Last stieg so stark an, dass das gesamte Forum nicht mehr ansprechbar war.
Unsere erste Untersuchung
Wir haben Discourse von der stabilen Version auf die neueste „Tests-Passed“-Version (Beta) aktualisiert, wie empfohlen, um alle neuesten Leistungsverbesserungen zu erhalten. Dies scheint jedoch kaum einen Unterschied gemacht zu haben.
Wir haben einige alte Plugins entfernt, um das Problem einzugrenzen. Es scheint jedoch nicht an diesen Plugins zu liegen.
Um Fehlkonfigurationen auszuschließen, haben wir das Forum mit dem Standardthema getestet und die Protokolldateien unter /logs überprüft. Dabei fanden wir einige Ausnahmen:
Job exception: could not obtain connection from the pool within 5.000 seconds (awaited 5.006 seconds); all pooled connections were in use
Dies scheint darauf zurückzuführen zu sein, dass die Instanz möglicherweise bereits durch viele langlaufende Aufgaben stark belastet ist.
Der Discourse-Container (Upstream) läuft auf Digital Ocean und nutzt alle 6 vCPUs stark. Aktuell läuft er in der Version: 2.5.0.beta7
Weitere Untersuchungen
Heute Morgen teilten uns unsere Moderatoren mit, dass die Anzahl der Spam-Konten erheblich angestiegen ist. Dies ließ uns vermuten, dass es sich um einen gezielten Angriff handeln könnte.
Um das Problem einzudämmen, haben wir das Forum in den Schreibgeschützten Modus versetzt. Trotz dessen bleibt die Ressourcennutzung mit über 60 % weiterhin sehr hoch.
Soweit wir feststellen können: Seit Beginn des Problems verzeichnen wir auf unserem Proxy weniger Anfragen pro Sekunde, aber eine höhere aktuelle Anzahl gleichzeitiger Anfragen:
Keine der anderen Anwendungen auf demselben Proxy scheint betroffen zu sein. Unsere Plattformen /news und /learn funktionieren normal.
Wir haben versucht, zusätzliche Ratenbegrenzungen auf dem Proxy einzurichten, was jedoch kaum einen Unterschied bewirkte. Daher haben wir diese wieder entfernt, damit normale Nutzer weiterhin unsere Seite erreichen können.
Außerdem haben wir die Weiterleitungen von unserem alten Forum unter forum.freecodecamp.com weg vom .org-Forum verschoben, da wir festgestellt haben, dass diese alte Subdomain (die wir seit 2,5 Jahren nicht mehr nutzen) vor einigen Tagen einen starken Anstieg des Datenverkehrs verzeichnete.
Momentan, bei etwa 400 gleichzeitigen Nutzern, sehen die Statistiken wie folgt aus:
Die Spammer scheinen ein Skript zu verwenden, das neue Konten auf einer Discourse-Instanz erstellt und diese mehrere Tage inaktiv lässt. Plötzlich werden diese Konten aktiv und beginnen, neue Threads mit Links zu einer Website zu posten. (Vielleicht, um Backlinks aufzubauen?)
Einige dieser Konten wurden bereits im März erstellt.
So sieht einer ihrer Spam-Beiträge aus, obwohl es viele Varianten gibt, die auf zahlreiche Websites verlinken:
Ich glaube nicht, dass die hohe Auslastung hauptsächlich durch Spammer verursacht wird.
Hier ist der Grund:
Die normale Nutzung von Discourse (ohne API) funktioniert nur mit modernen Browsern, da sie stark auf JavaScript angewiesen ist. Google Analytics verwendet ebenfalls JavaScript, um verschiedene Benutzerinformationen zu sammeln (und benötigt keine moderne JavaScript-Unterstützung, um den Analysecode auszuführen). Wenn Google Analytics die Benutzeraktivität nicht erfassen kann, sollte Discourse seine Inhalte und Funktionen ebenfalls nicht bereitstellen können.
Hier ist ein Bot-Capture, als ich eine alte Headless-Browser-Bibliothek (PhantomJS) verwendet habe, um auf die Discourse-Seite zuzugreifen:
Es ist einfach seltsam, wenn jemand in der Lage ist, Antworten auf Discourse zu posten (ohne API), während Google Analytics sie nicht erfasst.
Normalerweise verwenden Spammer öffentliche Proxies, um ihre schmutzigen Dinge zu erledigen, und ich denke, Ihr Cloudflare ist intelligent genug, um “böswillige Besucher” zu stoppen, bevor sie Ihre App wirklich erreichen.
Haben Sie eine hohe Warteschlange von Jobs im Sidekiq-Prozess festgestellt?
Dies ignoriert die Tatsache, dass mehr als die Hälfte der Nutzer in Tech-Communities irgendeine Art von Ad-Blocker-Erweiterung verwenden, die Google Analytics standardmäßig blockiert.
Ich sehe nicht, warum es seltsam ist, wenn Anfragen gestellt werden können, ohne dass JavaScript-basierte Analysen etwas anzeigen.
Der Spammer kann dieselben Endpunkte wie das JavaScript nutzen, ohne JavaScript. Keine JavaScript-basierte Analyse würde ausgelöst werden.
Dies ist viel wahrscheinlicher auf eine Plug-in-Interaktion oder eine fehlerhafte Proxy-Konfiguration zurückzuführen. Bei unseren Hosting-Diensten verzeichnen wir bei „Spammern
Ja, ich tendiere dazu, dass es entweder an der Konfiguration (schlechte Plugin- oder Proxy-Einrichtung) oder daran liegt, dass jemand das Forum manipuliert. Letzteres ist aufgrund aller Muster wahrscheinlicher.
Meiner Beobachtung nach wurden die Spam-Konten über einen längeren Zeitraum erstellt, und die Nutzer versuchen, Links (zur Gewinnung von Backlinks??) in ihren Biografien und allerlei seltsame Dinge einzufügen.
Außerdem könnte ein Scraping im Spiel sein, da wir die Seite auf Nur-Lese-Modus gestellt haben, einen Cache auf dem Proxy eingerichtet haben und zudem eine Ratenbegrenzung aktiviert ist. Die Ressourcennutzung scheint trotzdem hoch zu sein, unabhängig vom Upstream-Container.
Allerdings würde ich nicht ausschließen, dass unsere Konfiguration ebenfalls fehlerhaft sein könnte. Wir verwenden Subpfade und Cloudflare vor unserem Reverse-Proxy, was traditionell nicht die effizienteste Einrichtung ist, die Discourse empfiehlt.
42,5 % Steal ist wirklich hoch, selbst wenn du derjenige bist, der die Probleme auf diesem Hypervisor verursacht. Das sieht für mich nach einem „noisy neighbour“ aus. Wenn ich du wäre, würde ich DO kontaktieren und bitten, den Droplet auf einen anderen Hypervisor zu verschieben.
Ich bin mir sicher, dass du das wahrscheinlich bereits tust, aber zur Sicherheit würde ich empfehlen, offene TCP-/UDP-Verbindungen auf Betriebssystemebene nach IP zusammengefasst zu überwachen. Bei hoher CPU-Last sollte sich eine enorme Anzahl offener Verbindungen zum Webserver zeigen.
Lass uns kurz einen Schritt zurücktreten und das Ganze aus einer professionellen Cybersecurity-Perspektive betrachten – ohne Spekulationen und ohne den Ansatz, „an Strohhalmchen zu klammern".
Das Schlüsselkonzept bei allen Cybersecurity-Aufgaben ist das der „situational awareness
Discourse hostet nun https://forum.freecodecamp.org/. Die Seite ist extrem schnell, Spam-Skripte verursachen nicht einmal mehr eine Störung. Wir sind immer noch etwas unklar darüber, welches Problem es bei Digital Ocean gab; es könnte ein lauter Nachbar gewesen sein, die Maschine war möglicherweise unterdimensioniert, oder es gab Maschinengremlins – wir sind uns nicht sicher. Aber das ursprüngliche Problem ist jetzt zu 100 % gelöst, und die Community ist sehr zufrieden.
Symbolleiste