Was deine Logdatei zeigt Die Einträge enthalten fast ausschließlich:
"-" 408 4723 "-" "-" "-" 408 323 "-" "-"
Das bedeutet:
Kein HTTP‑Request (der Request‑String ist „-“ → also leer)
Statuscode 408 → Request Timeout
Response‑Size 4723 oder 4724 Bytes → Apache sendet eine Standard‑Timeout‑Fehlerseite
User‑Agent fehlt → „-“
Kommt von hunderten verschiedenen IPv4/IPv6‑Adressen weltweit
Das ist typisch für:
Viele Bots öffnen eine Verbindung, senden keine Daten → Apache hält die Verbindung offen → PHP‑FPM/Apache‑Worker blockiert → Server wird langsam.
Das Muster passt perfekt zu Slowloris‑Varianten: Viele Verbindungen, keine Daten, nur warten → Apache erzeugt 408.
Manche Scanner testen HTTP‑Ports, senden aber keinen Request → 408.
🧪 Warum deine Webseite langsam wird Apache2 (insbesondere mit mpm_prefork) ist anfällig für Verbindungs‑Floods, weil:
Jeder Client bekommt einen eigenen Prozess/Thread.
Viele halboffene Verbindungen blockieren Worker.
PHP‑FPM wartet ebenfalls auf freie Apache‑Worker.
Das führt zu:
Lange Ladezeiten
Timeouts
Hohe CPU‑Last
MariaDB wirkt langsam, obwohl sie nicht das Problem ist
🛡️ Sofortmaßnahmen (sehr effektiv) 1. Aktiviere mod_reqtimeout Begrenzt die Zeit, die Apache auf Daten wartet.
sudo a2enmod reqtimeout
In /etc/apache2/mods-enabled/reqtimeout.conf:
RequestReadTimeout header=5-10,MinRate=500 body=10,MinRate=500
→ Idle‑Connections sterben schnell.
2. Installiere fail2ban für Apache Blockiert IPs, die viele 408 erzeugen.
Filter /etc/fail2ban/filter.d/apache-408.conf:
[Definition] failregex = ^<HOST> .* 408
Jail:
[apache-408] enabled = true port = http,https filter = apache-408 logpath = /var/log/apache2/access.log maxretry = 20 findtime = 60 bantime = 3600
3. Nutze Cloudflare oder ein Reverse‑Proxy‑Rate‑Limit Cloudflare blockiert Botnet‑Traffic automatisch.
4. Wechsle zu Apache mpm_event Falls du noch mpm_prefork nutzt (typisch bei PHP):
sudo a2dismod mpm_prefork sudo a2enmod mpm_event
Und PHP über php-fpm statt mod_php.
5. Aktiviere mod_evasive Schützt vor Floods:
sudo apt install libapache2-mod-evasive sudo a2enmod evasive
Konfiguration:
DOSHashTableSize 3097 DOSPageCount 20 DOSPageInterval 1 DOSSiteCount 200 DOSSiteInterval 1 DOSBlockingPeriod 10
🧭 Fazit Ja, du wirst sehr wahrscheinlich von einem Botnetz‑Scan oder einem Low‑Rate‑DoS getroffen. Die Logdatei zeigt eindeutig:
Tausende Verbindungen ohne Request
408‑Timeouts
Weltweit verteilte IPs
Apache wird durch Idle‑Connections blockiert
Mit den oben genannten Maßnahmen bekommst du das Problem innerhalb weniger Minuten unter Kontrolle.
nano /etc/apache2/mods-enabled/evasive.conf
<IfModule mod_evasive20.c> DOSHashTableSize 3097 DOSPageCount 100 DOSPageInterval 1 DOSSiteCount 500 DOSSiteInterval 1 DOSBlockingPeriod 5 </IfModule>
mod_evasive für den Shop komplett deaktivieren
Das ist die beste Lösung, weil Shops immer viele Requests erzeugen.
In deinem VirtualHost:
Code <Directory /var/www/webserver/xxx/>
<IfModule mod_evasive20.c>
DOSPageCount 0
DOSSiteCount 0
</IfModule>
</Directory> Das bedeutet:
Optimierte mod_evasive‑Konfiguration für deinen Shop
Diese Werte sind praxisbewährt für Shops mit hohem Bild‑Traffic:
DOSHashTableSize 3097 DOSPageCount 300 DOSPageInterval 1 DOSSiteCount 1000 DOSSiteInterval 1 DOSBlockingPeriod 3
Was bedeutet das? DOSPageCount 300
DOSSiteCount 1000
DOSBlockingPeriod 3
🎯 Noch besser: mod_evasive für den Shop komplett deaktivieren Du kannst mod_evasive global aktiv lassen, aber für deinen Shop ausschalten:
In deinem VirtualHost: Code <Directory /var/www/webserver/shop/>
<IfModule mod_evasive20.c>
DOSPageCount 0
DOSSiteCount 0
</IfModule>
</Directory> Das bedeutet:
mod_evasive schützt alle anderen Domains
aber nicht deinen Shop
keine 403 mehr
keine Blockierungen mehr
keine Probleme mit Bild‑Last
Das ist die beste Lösung, wenn dein Shop extrem viele Requests erzeugt.
🧠 Warum das sicher ist Bots greifen nicht deinen Shop an, sondern:
Dein Shop ist kein Angriffsziel, sondern nur ein Bild‑Last‑Generator.
Deshalb ist es absolut sinnvoll, mod_evasive dort zu deaktivieren.