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


Optimierte mod_evasive‑Konfiguration für deinen Shop

Diese Werte sind praxisbewährt für Shops mit hohem Bild‑Traffic:

<code>
DOSHashTableSize    3097
DOSPageCount        300
DOSPageInterval     1
DOSSiteCount        1000
DOSSiteInterval     1
DOSBlockingPeriod   3
</code>
Was bedeutet das?
DOSPageCount 300  
  * → Ein Client darf 300 Requests pro Sekunde auf dieselbe Seite machen
  * → perfekt für Bild‑Grids, Lazy‑Load, Preload

DOSSiteCount 1000  
  * → Ein Client darf 1000 Requests pro Sekunde insgesamt machen
  * → schützt trotzdem vor Bots, aber blockiert keine echten Kunden

DOSBlockingPeriod 3  
  * → Falls doch geblockt wird, nur 3 Sekunden
  * → kein echter Kunde merkt das

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

  * /wp-login.php
  * /xmlrpc.php
  * /admin.php
  * /console
  * /login
  * /wp-json
  * /phpmyadmin

Dein Shop ist kein Angriffsziel, sondern nur ein Bild‑Last‑Generator.

Deshalb ist es absolut sinnvoll, mod_evasive dort zu deaktivieren.