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.

[fab44]

Uff danke für die Beschäftigung mit der Thematik!
Dass die Anfragegeschwindigkeit für einen Crawler sehr hoch ist konnte ich nicht beurteilen. Wahrscheinlich wird der aktuell dann auch auf die statische Variante losgelassen, da kann ich mal die access-logs durchschauen und blockieren. Bin aktuell noch ausgelastet mit Prüfungen und Notenbildung, mal sehen wann ich dazu komme!

@Tab: D.h. einfach Update auf 5.3.34 und Umstellung von webworker/cronjob bringt da vsl. keine Besserung?

LG

fab44

[Spooky]

Wenn du die Web Worker deaktivierst, kann das schon eine Besserung bringen. Aber der Web Server könnte dennoch überlastet werden. Davor bist du bei solchen Shared Hostings (oder generell) nie gefeit.

[Spooky]

Ja, minütlich oder auch 5-minütlich

Nein, ich meinte dass ein Crawler "unbound" auf eine Website losgelassen wird. Ob da mehrmals in der Sekunde die Startseite aufgerufen wird oder sonst eine URL aufgerufen wird, ist dabei ja unerheblich.

[tab]

Wenn du die Web Worker deaktivierst, kann das schon eine Besserung bringen.

Soweit ich derzeit die Doku verstanden und mich durch die MySQL Query-Logs gewühlt habe ist es wohl so, dass die in den Queues vorhandenen Messages auch während eines solchen - absichtlichen oder unabsichtlchen - Angriffs von den Webworkern noch zusätzlich abgearbeitet werden müssen. Die Web-Prozesse haben also etwas mehr zu tun und laufen deshalb pro Aufruf länger, als es mit deaktiviertem Web Worker der Fall wäre. Die Cron Worker dagegen können die Messages von den Seitenaufrufen entkoppelt abarbeiten.

Dass die Bearbeitung von Messages nicht trotzdem auch während des "Angriffs" passieren kann, kannst du zwar als Kunde nicht garantieren. Aber es lässt zumindest dem Hoster die Chance, die Last besser zu verteilen. Eventuell werden Cronjobs auch mit niedrigerer Priorität gestartet als die Webprozesse, damit kann das dann das OS des Servers auch selbst regulieren. Und der Webserver, also Apache, nginx oder was auch immer, ist zumindest nicht mehr damit belastet. Der MySQL-Server wird um die Queries zur Abarbeitung der Messages zwar früher oder später nicht herumkommen, aber es besteht zumindest die Chance, dass sich das besser verteilt und nicht alles während des "Angriffs" passieren muss.

Also sehe ich die Benutzung eines Cronjobs und die Deaktivierung des Web Workers schon als hilfreich an. Dabei wäre im Sinne der Lastverteilung ein minütlicher noch besser als nur alle 5 Minuten. Bei 5-minütigem Cron gibt es Zeiträume, während denen kein Worker vorhanden ist. Es sammeln sich also die dann anfallenden Messages an und können erst bearbeitet werden, wenn wieder Cron Worker gestartet sind. Aber es ist nun mal wie es ist, mehr als 5-minütig geht halt nicht.

... Aber der Web Server könnte dennoch überlastet werden. Davor bist du bei solchen Shared Hostings (oder generell) nie gefeit.

Insofern kannst du wohl im Hinblick auf das Risiko der Deaktivierung des Webhosting-Pakets nie völlig sicher sein, nachdem das schon "angedroht" wurde. Vielleicht ist es ja auch als Wink mit dem Zaunpfahl gemeint, dass es auch größere und teurere Webhosting-Pakete gibt, wo die hohe Last dann eventuell kein Problem mehr wäre
Man kann IPs blocken, von denen solches Verhalten bekannt ist. Trotzdem kann es jederzeit nochmal passieren von einer anderen IP aus, die eben (noch) nicht geblockt ist. Zu dem Thema gibt es ja mittlerweile auch einige Tipps im Thread.

Helfen würde natürlich auch die Aktivierung des Public Cache, der scheint derzeit nicht aktiviert zu sein oder darf die Seiten nicht cachen. Jeder Aufruf einer Seite zeigt

cache-control
	no-cache, no-store, private
contao-cache
	miss

Das sollte man auch mal versuchen zu ändern, der Public Cache könnte bei solchen Angriffen eine große Hilfe sein. Der Browser-Cache natürlich auch, sofern der Angreifer überhaupt einen hat.

[Toflar]

Soweit ich derzeit die Doku verstanden und mich durch die MySQL Query-Logs gewühlt habe ist es wohl so, dass die in den Queues vorhandenen Messages auch während eines solchen - absichtlichen oder unabsichtlchen - Angriffs von den Webworkern noch zusätzlich abgearbeitet werden müssen. Die Web-Prozesse haben also etwas mehr zu tun und laufen deshalb pro Aufruf länger, als es mit deaktiviertem Web Worker der Fall wäre. Die Cron Worker dagegen können die Messages von den Seitenaufrufen entkoppelt abarbeiten.

Korrekt. Das tun sie aber nur so lange, wie es noch Messages auf der Queue gibt. Sobald nix mehr da ist, wird der Prozess freigegeben. Ausserdem berücksichtigen wir auch die verschiedenen SAPIs. Also diejenigen, die das Senden der Response vor dem Beenden des Prozesses unterstützen (primär php-fpm, litespeed, frankenphp), senden die Response und arbeiten danach noch für eine gewisse Zeit Messages ab (mit einem Zeitlimit, das wir aufgrund von max_execution_time berechnen). Bei den anderen (bspw. mod_php) machen wir das nicht, weil das ja die Antwortzeit für den Kunden negativ beeinflussen würde. Auf den Einsatz dieser SAPIs sollte man aber verzichten.

[tab]

Da habe ich ja gleich den richtigen Ansprechpartner hier. Du hast ja den Cache von Contao entwickelt , ich hätte da ein paar Fragen.

1. Gehe ich Recht in der Annahme, dass für eine Seite, die aus dem Shared-Cache ausgeliefert wird, keine Datenbankanfragen entstehen?
2. Gibt es eine Möglichkeit für potenzielle Angreifer, den Cache zu umgehen. Also trotz "fresh" eine Rückfrage des Caches beim Webserver zu erreichen? Stichwort Cache-Control Header mit no-cache.

Eigentlich sollte ja durch die Cache-Tags der Cache-Status schon klar sein und keiner Nachfrage beim Webserver mehr bedürfen. Zumindest würde ich davon ausgehen, dass trotzdem die Seite in der Regel nicht neu erzeugt werden müsste.

Hintergrund: Die betroffene Seite lief bisher ohne Cache, jetzt ist er aktiviert und sollte eigentlich solche Angriffe wie aus dem Log deutlich abmildern. Das wäre jedenfalls meine Hoffnung. Müsste man halt dafür sorgen, dass alle Seiten regelmäßig aufgerufen werden, so dass nicht zu viele Seiten gleichzeitig ihre Cachezeit überschritten haben. Bei einem Aufruf gibt es jetzt jedenfalls ein "Miss/Store" und danach "Fresh".

[Toflar]

Da habe ich ja gleich den richtigen Ansprechpartner hier. Du hast ja den Cache von Contao entwickelt

Mhm, die Messenger-Integration geht auch auf meine Kappe

Gehe ich Recht in der Annahme, dass für eine Seite, die aus dem Shared-Cache ausgeliefert wird, keine Datenbankanfragen entstehen?

Wenn die Antwort aus dem Cache kommt und "fresh" enthält, dann ja. Zumindest in der Standard Contao Managed Edition. Extensions können sich ja auch in den Proxy reinhängen und beliebigen Code ausführen. Aber generell ist es so, dass die Applikation nicht gebootet wird (also du hast keinen Container, keine Konfiguration etc. zur Verfügung). Es wäre also eine separate Verbindung zur DB (die auch separat über Umgebungsvariabeln konfiguriert werden müsste) und nicht die gleiche, wie die in der App. Es ist also wirklich komplett getrennt, genau so wie es eben auch wäre, wenn der Proxy auf einem anderen Server vorgelagert eingesetzt würde

Also auch der WebWorker läuft nicht, wenn die Antwort "fresh" ist.

Gibt es eine Möglichkeit für potenzielle Angreifer, den Cache zu umgehen. Also trotz "fresh" eine Rückfrage des Caches beim Webserver zu erreichen? Stichwort Cache-Control Header mit no-cache.

Das lässt sich in Symfony konfigurieren. Für Contao ist es deaktiviert. Also nein, man kann keinen Refresh forcieren als Client.

Hintergrund: Die betroffene Seite lief bisher ohne Cache, jetzt ist er aktiviert und sollte eigentlich solche Angriffe wie aus dem Log deutlich abmildern

Den Shared-Cache von Contao zu aktivieren, ist immer sinnvoll. Er ist ein äusserst mächtiges Tool, weil er eben so gebaut ist, dass Symfony/Contao noch nicht mal gebootet werden müssen, wenn eine Antwort ausgeliefert werden kann. Man kann also damit in der Tat bereits sehr viele Ressourcen sparen

Trotzdem bleibt es ein PHP-Prozess. Und in so einem klassischen Setup (Apache/Nginx und php-fpm) ist das Spawnen von neuen PHP-Prozessen oftmals schon vergleichsweise ressourcenintensiv. Dem kann man begegnen, indem man entweder PHP effizienter laufen lässt (namentlich Litespeed-Webserver mit eigener SAPI, frankenphp und Co.) oder - noch besser - dafür sorgt, dass die Requests schon vorher abgefangen werden und PHP gar nicht erst gestartet werden muss: Sprich, nicht den Contao eigenen Cache nutzen sondern etwas Vorgelagertes wie Varnish, Cloudflare etc. pp. - und natürlich Firewalls, die die ganzen Bots etc. am besten schon auf Netzwerk-Ebene blocken.

Oder kurz gesagt: Je weniger Komponenten bemüht werden müssen, um einen Request abzulehnen/abzufertigen, desto geringer die Angriffsfläche für (D)DOS. Ich denke, das leuchtet ein

[Spooky]

Das lässt sich in Symfony konfigurieren. Für Contao ist es deaktiviert. Also nein, man kann keinen Refresh forcieren als Client.

@tab: Man kann aber einfach einen beliebigen Query Parameter für Cache Busting anhängen.

[Toflar]

Genau, das ist bei jeder Caching-Lösung so. Jeder Query-Parameter bedeutet ein neuer Cache-Eintrag. Dem kann man nur begegnen, indem man die erlaubten Parameter seiner App kennt und alle anderen ignoriert.
Ist halt etwas aufwändig, geht aber natürlich auch in Contao (https://docs.contao.org/dev/referenc...ams-allow-list)

[Spooky]

Genau, das ist bei jeder Caching-Lösung so. Jeder Query-Parameter bedeutet ein neuer Cache-Eintrag. Dem kann man nur begegnen, indem man die erlaubten Parameter seiner App kennt und alle anderen ignoriert.
Ist halt etwas aufwändig, geht aber natürlich auch in Contao (https://docs.contao.org/dev/referenc...ams-allow-list)

Ja, wobei man aber leider nicht einfach keine Query Parameter in der Allow List haben kann. In einem Vanilla Contao ohne Paginations bräuchte man ja gar keine.

[Toflar]

Ja, wie gesagt, der Cache ist ein Performance-Tool und kann helfen. (D)DOS begegnet man mit anderen Tools

[tab]

Ja, wobei man aber leider nicht einfach keine Query Parameter in der Allow List haben kann. In einem Vanilla Contao ohne Paginations bräuchte man ja gar keine.

Naja, nimmt man halt irgendeinen längeren Hash als zulässigen Parameter, den dann erst mal jemand finden muss. Wenn es ein Profi-Hacker ist, der ausgerechnet diese Website lahmlegen will, findet er eh immer Möglichkeiten. Da hat es schon ganz andere erwischt. Und Skript Kiddies suchen sich dann wahrscheinlich irgendwann ein leichteres Opfer für ihr Spielzeug.