Contao 5.3 SQL-Abfrage an tl_message_queue erzeugt ernorme Last

[Spooky]

Dieser Cron Prozess wird ja nicht durch Web Prozesse gestartet.

[neelix]

Wenn kein echter Cron eingerichtet ist, dann starten die Arbeiten doch nach dem Ausliefern der Seite an den Besucher und laufen dann solange, bis der Webserver den Prozess killt.
So verstehe ich das zumindest aus der Doku.

Und wenn ich die Liste hier richtig interpretiere, dann sind das u.a. Cache Invalidation und Indexer:

Registered Listeners for "kernel.terminate" Event
=================================================

 ------- ----------------------------------------------------------------------------- ----------
  Order   Callable                                                                      Priority
 ------- ----------------------------------------------------------------------------- ----------
  #1      Contao\CoreBundle\EventListener\CommandSchedulerListener::__invoke()          0
  #2      Contao\CoreBundle\EventListener\SearchIndexListener::__invoke()               0
  #3      FOS\HttpCacheBundle\EventListener\InvalidationListener::onKernelTerminate()   0
  #4      Contao\CoreBundle\Messenger\WebWorker::onKernelTerminate()                    -2048
 ------- ----------------------------------------------------------------------------- ----------

PHP läuft bei MANITU als FPM/FastCGI, max_execution_time steht auf 60 und memory_limit auf 256M.

[Spooky]

Das sind nicht die Prozesse aus deinem vorherigen Post.

Wenn du keinen Cronjob eingerichtet hast, dann kümmert sich der Webworker um etwaige Messages in den Queues.

[tab]

Habe mir das jetzt in der Doku nochmal durchgelesen, muss ich wohl noch ein paar Mal machen, im Moment qualmt erst mal der Kopf. Morgen (heute) soll es ja kühler werden, vielleicht klappt es dann. Im Moment bin ich mir immer noch nicht sicher, wieviele Webworker es geben kann. Insgesamt einen oder doch eher einen pro Web-Request. Ich tendiere zum letzteren, aber .

Man kann das natürlich auch anders rum aufzäumen. Wäre es nur einer, egal wieviele Requests auf den armen Webserver einprasseln, dann wäre es wahrscheinlich kein Problem. Also sind es eher mehrere Wenn es mehrere gibt, existiert dann auch ein Limit dafür wie bei den cron Workern? Bzw greift das selbe Limit auch für Webworker? Ansonsten könnte man da evetuell in diverse Limits des MySQL-Servers reinlaufen.

So, Schluss jetzt für mich. Später wieder.

[tab]

So, die ersten Tests habe ich heute gemacht. Queries werden geloggt. Meine Güte, ich wusste ja gar nicht, wieviele Queries der arme MySQL Server bearbeiten muss. Entsprechend ist auch die Größe der Logs, ich schalte das Logging nur beim Testen an. Es laufen jetzt zwei Installationen, einmal die ursprüngliche Version der Website mit dem Load-Problem und ein Klon davon mit Update auf 5.3.34 und einem 5-minütlichen Cronjob. Also das, was auch bei Manitu möglich wäre.

Der Webworker ist komplett deaktiviert nach der Anleitung von Spooky. Das funktioniert auch, soweit ich das beurteilen kann. Komplett habe ich das aber immer noch nicht verstanden. Z.B.die maximale Laufzeit der vom Cronjob erzeugten Worker. Ich gehe aber mal davon aus, dass die wahrscheinlich nicht länger als eine Minute laufen werden und eine Pause von ca vier Minuten bei der Abarbeitung der Message Queues entsteht, da der nächste Cronjob erst nach fünf Minuten startet und neue Worker erzeugt.

Ich habe bei beiden Installationen alle 100+ Seiten der Website per bash-Skript nacheinander aufgerufen von einem anderen Server aus, das haben auch beide Installationen mühelos verkraftet. Wenn ich mir das Access-Log im ersten Beitrag anschaue, bin ich mit der Methode auch viel zu gemütlich unterwegs, das gibt gerade mal circa 3 Aufrufe pro Sekunde. Im Access-Log sehe ich ein Vielfaches davon, da laufen wohl die Aufrufe asynchron. Das ist aus meiner Sicht ein klarer Fall einer DOS Attacke. Welchen Sinn sollte es für einen normalen Crawler machen, zig-Mal pro Sekunde die Startseite aufzurufen? Das hat für das Shared Webhosting wohl gereicht, zumal die Seite auch nicht aus dem Public Cache ausgeliefert wird, also jedes Mal neu erzeugt werden muss.

[mlweb]

Eine solche Attacke sollte doch der Hoster aus den Logs auch erkennen können oder sehe ich das völlig falsch?

[tab]

Sehen kann er es so gut wie der Kunde, eher besser. Zeitlich scheint es zu dem vom Hoster angegebenen Zeitpunkt wohl zu passen. Seither ist das Problem ja nochmal aufgetreten. Wenn es da wieder ähnliche, zeitlich passende Log-Einträge gibt, dann wüsste ich nicht auf Anhieb, wie sich der Kunde davor schützen soll. Kein PHP und kein MySQL verwenden? Man könnte evenuell versuchen, selbst die betreffenden IP(s) aussperren, wenn es nicht besser geht eventuell per .htaccess.

Aber das kann man natürlich erst tun, nachdem es bereits passiert ist. Würde ich in so einem Fall dem Hoster mal zeigen. Wenn das tatsächlich die Ursache für die von Manitu monierten hohen Loadwerte ist, wird man sich als Kunde nur schwer präventiv davor schützen können. Da frage ich mich aber schon, wessen Aufgabe das ggf wäre.

[zoglo]

Da frage ich mich aber schon, wessen Aufgabe das ggf wäre.

Die meisten Hoster schreiben so etwas in die AGB. Dort mal nachschauen aber hier "mietest" du den Server und spielst nach den Spielregeln vom Hoster. Der Kunde hat dafür zu sorgen oder bucht ein stärkeres Paket.

[tab]

Die meisten Hoster schreiben so etwas in die AGB. Dort mal nachschauen aber hier "mietest" du den Server und spielst nach den Spielregeln vom Hoster. Der Kunde hat dafür zu sorgen oder bucht ein stärkeres Paket.

Ich habe gewisse Zweifel, ob ein stärkeres Paket etwas grundsätzliches am Problem ändern würde. Dann braucht es halt 50 Aufrufe pro Sekunde statt 20 bis der Server den Geist aufgibt (hier erkennbar am Status 500). Für den Angreifer sicher kein Problem. Der sitzt irgendwo in der Google Cloud. Und dann? Noch stärkeres Paket? Managed Server?

Aber gut, das muss dann wohl @fab44 mit dem Hoster klären, falls sich das so bestätigt. Also ob ein stärkeres Paket nach Einschätzung des Hosters das Problem verhindern oder beheben würde. Die Antwort ist dann vermutlich ja .

Mich persönlich interessiert hier auch, warum das mit einem Fehler 500 endet und nicht mit z.B. 503? Werde nachher mal die Anfragen an meinen Server "etwas" beschleunigen um zu sehen, ob das hier dann ebenso passiert und was genau dann ggf. passiert. Eventuell kann ja @fab44 auch nochmal beim Hoster nachfragen, ob sie das Problem genauer beschreiben (und bezüglich der anfallenden SELECTs quantifizieren) können. Also z.B. wieviele solche Statements sind in welchem Zeitraum beim MySQL-Server aufgeschlagen? Siehe auch den Beitrag von Toflar weiter oben im Thread.

Meine "Arbeitshypothese" ist bis auf Weiteres wie folgt: Jeder Aufruf der Startseite in der Installation mit Webworker erzeugt grundsätzlich immer eine Message für die Indexierung (Suchindex). Bei der sehr schnellen Abfolge der Requests werden wahrscheinlich mehrere Requests gleichzeitig abgearbeitet und am Ende der Bearbeitung des eigentlichen Requests wird diese eine Message in die entsprechende Message Queue (prio_low?) eingetragen. Diese wird dann von den vielen kurz hintereinander gestarteten Webprozessen auch kurz nacheinander von den jeweiligen Webprozessen (Webworker) bearbeitet. Die Bearbeitung startet dann mit den SELECT Queries zur Abfrage der drei Standard Message Queues (prio_high, prio_normal, prio_low). Die kommen dann also auch recht schnell hintereinander, was dann zumindest für das aktuelle Hostingpaket die "Abmahnung" des Hosters nach sich zieht, aus welchen genauen Gründen auch immer.

Ich bin nicht Manitu, es sind eben möglicherweise viele weitgehend oder komplett identische Abfragen in kurzer Zeit, vielleicht triggert das dort irgendwas im Monitoring oder veranlasst den MySQL-Server, die Verbindung zu beenden (MySQL server has gone away...). Das führt dann wiederum - warum auch immer - am Ende zu einem Fehler 500 bei weiteren Aufrufen. Vielleicht triggert dann auch erst das das Monitoring?!?

Ich könnte mir vorstellen, dass die Abarbeitung durch einen oder mehrere Cron-Worker und deaktiviertem Web-Worker solche Bursts von Messages entschärft und sie im Gegensatz zu den Web-Workern eher kontrolliert abarbeitet. Auch wenn der Cron nicht minütlich ist. Jedenfalls wäre das meine Hoffnung. Und die stirbt bekanntlich zuletzt
Schaun mer mal, dann sehn mer scho.

[mlweb]

Die meisten Hoster schreiben so etwas in die AGB. Dort mal nachschauen aber hier "mietest" du den Server und spielst nach den Spielregeln vom Hoster. Der Kunde hat dafür zu sorgen oder bucht ein stärkeres Paket.

Ich würde von einem seriösen Hoster aber schon erwarten, dass er mir nicht nur vor den Latz knallt, dass das

Setup regelmäßig eine erhebliche Systemlast erzeugt und das Paket abgeschaltet werden muss, wenn ich es nicht umgehend behebe.

sondern mir auch einen Hinweis darauf gibt, dass es sich möglicherweise um einen Angriffsversuch auf meine Seite handelt.

Darauf bezog sich eigentlich meine Frage.

Also im Endeffekt zielt die Frage eher darauf ab, ob ein Angriff in diesem Fall tatsächlich wahrscheinlich ist.

[tab]

Also im Endeffekt zielt die Frage eher darauf ab, ob ein Angriff in diesem Fall tatsächlich wahrscheinlich ist.

Als Angriff ist so etwas schon zu werten. Eine normale Nutzung der Website ist das nicht. Auch kein normales Verhalten eines Crawlers.
Es geschieht definitiv skript- oder softwaregesteuert. Soviele Seitenanfragen in so kurzer Zeit bekommst du manuell nicht hin.
Die Frage kann lediglich sein, ob es absichtlich passiert oder ein "Unfall" war. Dass also z.B. jemand vielleicht sein neues Crawler-Spielzeug falsch eingestellt hat und der hat dann mit Höchstgeschwindigkeit zig-Mal die selbe Seite aufgerufen.

Kann also ebenso gut ein russischer Saboteur oder Hacker gewesen sein wie ein amerikanisches Skript-Kiddie, das sein Spielzeug ausprobiert hat. Die IP ist aus dem Bereich der Google-Cloud, also USA. Aber da kann sich ja im Zweifelsfall jeder einmieten, auch du und ich. Auch russische Hacker greifen nicht immer unbedingt mit einer IP aus Moskau zu , eher schon Google, Amazon, OVH oder andere Server-Anbieter auf der ganzen Welt. Muss ja nicht gleich jeder wissen, woher sie kommen. Ob und warum eine Schul-Website für sie ein lohnendes Ziel sein könnte sei mal dahingestellt.

[Spooky]

Dass also z.B. jemand vielleicht sein neues Crawler-Spielzeug falsch eingestellt hat und der hat dann mit Höchstgeschwindigkeit zig-Mal die selbe Seite aufgerufen.

Das passiert in der realen Welt oft.

[tab]

Das passiert in der realen Welt oft.

Ja, minütlich oder auch 5-minütlich
Wahrscheinlich ist die Website der Schule bei dem Crawler die Default-Einstellung

[do_while]

Ich kenne das aber auch, zu den Suchmaschinen, die die Seiten crawlen sind ja jetzt noch die diversen KIs hinzugekommen, die immer denken, dass sie auf den Seiten noch was Neues lernen können.
Wenn dann sehr viele Seiten existieren und zufällig mehrere Crawler alles gleichzeitig durchwühlen, dann ist bei uns schon mal der SQL-Server an seine Grenzen gekommen und konnte keine weiteren Serververbindungen aufbauen. Die Schwelle liegt bei Shared Hosting teilweise sehr niedrig.
Diese Situationen sollte man aber leicht durch die Auswertung der Serverlogs herausfinden können.

Abhilfe ist, durch gezielte Einträge, z.B. in der .htaccess, bestimmte Bots auszuschließen, bzw. einzubremsen, wenn es geht. Bei Plesk gibt es einige Filtereinstellungen, die ggf. Gutes bewirken.

[BugBuster]

https://github.com/ai-robots-txt/ai.robots.txt

[neelix]

Laut dem Log kam hier dieses Tool zum Einsatz:
https://github.com/jimmysawczuk/recon

Das würde sich über den User-Agent blocken lassen in einer .htaccess blocken lassen. Aber im Zweifelsfall ist das ein Katz und Maus Spiel.

Vielleicht es auch einfach nur ein Schüler.

[tab]

Laut dem Log kam hier dieses Tool zum Einsatz:
https://github.com/jimmysawczuk/recon

Das würde sich über den User-Agent blocken lassen in einer .htaccess blocken lassen. Aber im Zweifelsfall ist das ein Katz und Maus Spiel.

Vielleicht es auch einfach nur ein Schüler.

Du meinst, ein Schüler der Schule, um deren Website es hier geht? Daran hatte ich auch schon gedacht. Das kann man jedenfalls nicht ausschliessen.