====== Bots ======


===== Bots greifen den Webserver an =====



Was deine Logdatei zeigt
Die Einträge enthalten fast ausschließlich:

<code>"-" 408 4723 "-" "-"  
"-" 408 323 "-" "-"</code>

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:

  - Botnetz‑Traffic / Layer‑7‑DoS
Viele Bots öffnen eine Verbindung, senden keine Daten → Apache hält die Verbindung offen → PHP‑FPM/Apache‑Worker blockiert → Server wird langsam.

  - Idle‑Connection‑Flood / Slowloris‑ähnliche Attacke
Das Muster passt perfekt zu Slowloris‑Varianten:
Viele Verbindungen, keine Daten, nur warten → Apache erzeugt 408.

  - Port‑/Service‑Scanner
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.


<code>sudo a2enmod reqtimeout</code>
In /etc/apache2/mods-enabled/reqtimeout.conf:


<code>RequestReadTimeout header=5-10,MinRate=500 body=10,MinRate=500</code>
→ Idle‑Connections sterben schnell.

2. Installiere fail2ban für Apache
Blockiert IPs, die viele 408 erzeugen.

Filter /etc/fail2ban/filter.d/apache-408.conf:

<code>
[Definition]
failregex = ^<HOST> .* 408</code>
Jail:


<code>[apache-408]
enabled = true
port = http,https
filter = apache-408
logpath = /var/log/apache2/access.log
maxretry = 20
findtime = 60
bantime = 3600</code>

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):


<code>sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
</code>
Und PHP über php-fpm statt mod_php.

5. Aktiviere mod_evasive
Schützt vor Floods:


<code>sudo apt install libapache2-mod-evasive
sudo a2enmod evasive</code>
Konfiguration:

<code>
DOSHashTableSize 3097
DOSPageCount 20
DOSPageInterval 1
DOSSiteCount 200
DOSSiteInterval 1
DOSBlockingPeriod 10
</code>
🧭 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.


===== evasive =====

nano /etc/apache2/mods-enabled/evasive.conf


<code>
<IfModule mod_evasive20.c>
	DOSHashTableSize 3097
	DOSPageCount 100
	DOSPageInterval 1
	DOSSiteCount 500
	DOSSiteInterval 1
	DOSBlockingPeriod 5
</IfModule>

</code>

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:

  * Listenpunktmod_evasive ist global aktiv (gut)
  * Listenpunktaber für deinen Shop deaktiviert (perfekt)