Bots, Crawlers und Spiders (werden im weiteren Verlauf dieses Artikels als Bots zusammengefasst) durchstöbern alle Seiten, um z.B. die Auffindbarkeit in Suchmaschinen zu gewährleisten. Diese Zugriffe sind größtenteils sinnvoll und normal. Dennoch können zu viele Zugriffe von Bots, besonders in Stoßzeiten, zu einer hohen Serverauslastung führen und sogar zu kritischen Zuständen wie sehr lange Ladezeiten oder sogar einem Serverausfall führen. In solchen Situationen ist es dann besonders wichtig, die Webseiten für menschliche Besucher schnell wieder erreichbar zu machen.
Das EGOCMS bietet mehrere Maßnahmen, um die Zugriffe von Bots gezielt zu steuern.
Inhaltsverzeichnis
Einschränkungen über robots.txt
Sie können auf dem Server eine robots.txt Datei hinterlegen und hier Richtlinien für Bots definieren. Die Inhalte dieser Datei können Sie aber auch dynamisch über den EGOCMS Adminbereich verwalten. Erfahren Sie dazu hier mehr.
Einschränkungen über Meta Einstellungen
Pro Seite kann eingestellt werden, wie Bots mit dieser Seite umgehen sollen. Erfahren Sie dazu hier mehr.
Beachten Sie, dass die Auswertung der Einschränkungen über eine robots.txt und den Meta Einstellungen grundsätzlich von den meisten Bots berücksichtigt wird, aber es auch Bots geben kann, die diese ignorieren.
Bots bei hoher Serverauslastung blockieren
Das EGOCMS verwendet bei der Ausgabe einer Seite zwei Arten von Cache, um beim Zugriff unnötige Datenbankzugriffe zu vermeiden und die Ausgabe zu beschleunigen: die eigene Smarty Cache und den Nginx Cache (sofern als Webserver Nginx verwendet wird und dieser entsprechend konfiguriert ist).
Wenn Bots alle möglichen Seiten durchstöbern, besteht eine sehr hohe Wahrscheinlichkeit, dass dabei viele Seiten aufgerufen werden, die noch nicht/nicht mehr im Cache liegen (z. B. weil URLs mit unterschiedlichen Parametern aufgerufen werden, die jeweils ein eigener Eintrag in der Cache bedeuten). Dies kann je nach der Menge an Bot Zugriffen und den zeitlichen Abständen dieser Zugriffe zu einer hohen Serverauslastung führen.
Das EGOCMS erkennt in solchen Fällen, dass die Serverauslastung sehr hoch ist und der Zugriff über einen Bot passiert, und blockiert diesen Zugriff (auch "Botbremse" genannt). Dabei wird der HTTP Status Code 429 Too Many Requests und der Header Retry-After: 300 gesendet (falls der Bot diesen Header auswertet, erfolgt der nächste Zugriff erst in 5 Minuten).
Die Serverauslastung muss standardmäßig über 50% betragen, damit die Blockade ausgelöst wird. Über Verwaltung > System > Sicherheit > Bots blockieren bei hoher Serverlast kann diese Obergrenze angepasst werden.
Die Serverauslastung berechnet sich in Abhängigkeit der verfügbaren logischen Prozessoren auf dem Server, bzw. des Containers, falls eine Docker oder Kubernetes Umgebung verwendet wird. Diese Anzahl wird automatisch ermittelt.
Der EGOCMS Systemdienst, welcher minütlich über einen Cronjob ausgeführt wird, führt automatisch das Bash-Skript bin/tool/linux/top.sh aus. Dieses Skript sollte deshalb auch auf dem Dateisystem für die Ausführung berechtigt sein. Hier findet die Berechnung der Serverauslastung statt.
Dabei läuft das Skript endlos im Hintergrund auf dem Server und berechnet spätestens alle 5 Sekunden die aktuelle Serverlast neu. Das Berechnen der Serverlast in sehr kurzen Intervallen unterstützt die Botbremse dabei rechtzeitig einzugreifen.
Das Skript wird nicht erneut ausgeführt, wenn es bereits im Hintergrund läuft. Der minütliche Systemdienst sorgt dafür, dass das Skript automatisch gestartet wird, falls es nicht mehr oder noch nicht läuft.
Bitte beachten Sie die Einrichtung des Systemdienstes. Sollte der Systemdienst nicht minütlich eingestellt sein, kann die Berechnung der Serverauslastung unter Umständen ungenau sein.
Die Ausführung dieser Bash-Skript für die Berechnung der Serverlast erfordert, dass das Tool jq installiert ist. Ist das Tool nicht installiert, für das Skript keine Berechnung aus.
Wird ein Standard EGOCMS Image verwendet, ist jq bereits vorinstalliert.
Die Ausführung der top.sh Datei legt standardmäßig die Datei var/log/top an (ausgehend von Ihrem EGOCMS Installationsverzeichnis). In dieser Datei steht die berechnete Serverauslastung des Containers der letzten vollen Minute und kann im Desklet Systemcheck eingesehen werden. Diese Datei manuell zu löschen ist unproblematisch.
Zusätzlich wird die Datei var/log/top.graph angelegt, welche die Daten für die Erstellung den Graphen im Systemcheck-Desklet beinhaltet. Die Daten enthalten alle Messpunkte der letzten Stunde. Diese Datei manuell zu löschen ist unproblematisch.
Dass das top.sh Skript bereits läuft, wird über die Sperrdatei var/log/TOP.LOCK ermittelt. Diese wird automatisch freigegeben, wenn das Skript nicht läuft oder z. B. wegen eines Fehlers abbricht. Sollte die Sperrdatei manuell gelöscht werden, muss sichergestellt werden, dass das top.sh Skript nicht mehrmals im Hintergrund läuft. Denn der minütliche Systemdienst ruft dieses automatisch auf, womit das Skript wieder von selbst startet.
Es wird empfohlen beim Serverstart das top.sh Skript automatisch im Hintergrund auszuführen. Sollte der Server wegen zu hoher Serverlast neustarten, ist die aktuelle Serverlast sofort bekannt, wenn die Zugriffe auf der Webseite wieder möglich sind und Bots werden sofort ausgebremst. Ansonsten muss bis zur Ausführung des minütlichen Systemdiensts gewartet werden. Die Ausführung im Hintergrund kann wie folgt eingeleitet werden.
bash /usr/share/nginx/egocms/bin/tool/linux/top.sh > /dev/null 2>&1 &
Die Ausführbarkeit des Bash-Skripts wurde für Ubuntu 22.04, 24.04 und SLES 15 getestet. Falls Ihre Serverumgebung die Ausführung des Skripts verhindert, können Sie die Berechnung der Serverauslastung über Verwaltung > System > Sicherheit deaktivieren. Beachten Sie, dass dann auch das Blockieren von Bots bei hoher Serverauslastung und die Begrenzung der erlaubten parallelen Bot Zugriffe nicht funktioniert.
Gleichzeitige Zugriffe beschränken
Das EGOCMS Image wird mit Nginx und einem aktivierten Rate Limit ausgeliefert. Hier wird festgelegt, dass nur maximal 5 Seitenaufrufe pro Sekunde von der selben IP erfolgen dürfen. Werden mehr Zugriffe erkannt, wird mit einem 429 Too Many Requests Status Code und einem Retry-After: 300 Header geantwortet.
Falls Sie auf Ihrem Server nicht das EGOCMS Image verwenden, Nginx einsetzen und ebenfalls das Rate Limit einsetzen, finden Sie hier die grundlegende Konfiguration (z. B. in der Datei /etc/nginx/nginx.conf):
http {
# rate limit requests: only for HTML pages (with or without extension)
# note: change ".html", if EGOCMS uses individual URL extensions
map $uri $limit_bots {
default "";
"/" $binary_remote_addr;
~*\.html$ $binary_remote_addr;
~*/[^.]*$ $binary_remote_addr;
}
# rate limit responds with 429 status code
limit_req_zone $limit_bots zone=flexible_limit:10m rate=5r/s;
limit_req_status 429;
# set retry-after duration (5 minutes)
map $status $retry_after_value {
default "";
429 "300";
}
# if rate limit exceeded, send additional reason header
map $retry_after_value $reason_value {
default "";
~.+ RATE;
}
server {
location / {
# rate limit requests and send retry-after header on 429 status code
limit_req zone=flexible_limit burst=10 nodelay;
add_header Retry-After $retry_after_value always;
add_header X-EGOCMS-REASON $reason_value always;
index rewrite.php index.php index.html;
try_files $uri $uri/ /rewrite.php?_url=$uri&$args;
expires 24h;
}
}
}