Sperren von HTTP/1.1-Requests per .htaccess: Unterschied zwischen den Versionen
Rb (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Rb (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| Zeile 27: | Zeile 27: | ||
'''Wichtig: Der User-Agent-Header wird vom Client mitgesendet und lässt sich beliebig fälschen. Ein Angreifer könnte sich also ebenfalls als einer der genannten Bots ausgeben, um die Sperre zu umgehen. Für eine zuverlässige Verifizierung (z.B. per Reverse-DNS-Lookup) reicht reines mod_rewrite nicht aus. Für eine grobe Absicherung während einer akuten DDoS-Welle ist die User-Agent-Prüfung in der Praxis aber meist ausreichend.''' | '''Wichtig: Der User-Agent-Header wird vom Client mitgesendet und lässt sich beliebig fälschen. Ein Angreifer könnte sich also ebenfalls als einer der genannten Bots ausgeben, um die Sperre zu umgehen. Für eine zuverlässige Verifizierung (z.B. per Reverse-DNS-Lookup) reicht reines mod_rewrite nicht aus. Für eine grobe Absicherung während einer akuten DDoS-Welle ist die User-Agent-Prüfung in der Praxis aber meist ausreichend.''' | ||
=== Ausnahmen für Nextcloud-Sync und Uptime Kuma === | |||
Auch Synchronisations-Clients wie der Nextcloud-Desktop-/Mobile-Client sowie Monitoring-Tools wie Uptime-Kuma greifen häufig über HTTP/1.1 zu und senden dabei einen eigenen User-Agent (z.B. <code>mirall</code> beim Nextcloud-Client bzw. <code>Uptime-Kuma</code> bei Uptime-Kuma). Diese können der Ausnahmeliste ebenfalls hinzugefügt werden: | |||
<pre> | |||
RewriteEngine On | |||
RewriteCond %{THE_REQUEST} HTTP/1\.1$ | |||
RewriteCond %{HTTP_USER_AGENT} !(Googlebot|bingbot|Slurp|DuckDuckBot|YandexBot|Baiduspider|facebookexternalhit|mirall|Uptime-Kuma) [NC] | |||
RewriteRule ^ - [F,L] | |||
</pre> | |||
Falls ein Nextcloud-Android-Client genutzt wird, sollte auch der User-Agent "Nextcloud-android" hinzugefügt werden, da hier auch noch ein eigener genutzt wird. | |||
=== Besonderheit bei Shopsystemen: Zahlungsvorgänge === | |||
Rückmeldungen von Zahlungsdienstleistern (z.B. Webhooks/Callbacks von PayPal, Klarna, Stripe, Mollie o.ä.) laufen ebenfalls häufig über HTTP/1.1 und würden durch die Sperre blockiert werden, mit der Folge, dass Zahlungen nicht mehr korrekt zurückgemeldet werden und Bestellungen im Shop hängen bleiben. | |||
Diese Callbacks senden in der Regel '''keinen''' eindeutigen User-Agent, weshalb eine Ausnahme über <code>HTTP_USER_AGENT</code> hier meist nicht zuverlässig funktioniert. Stattdessen empfiehlt es sich, den betroffenen Pfad direkt von der Regel auszunehmen, z.B.: | |||
<pre> | |||
RewriteEngine On | |||
RewriteCond %{THE_REQUEST} HTTP/1\.1$ | |||
RewriteCond %{REQUEST_URI} !^/zahlungsvorgang [NC] | |||
RewriteRule ^ - [F,L] | |||
</pre> | |||
Der Pfad <code>/payment/callback</code> muss dabei durch den tatsächlichen Callback-/Webhook-Pfad des jeweiligen Shopsystems bzw. Zahlungsdienstleisters ersetzt werden. | |||
Aktuelle Version vom 7. September 2026, 10:23 Uhr
Insbesondere bei DDoS-Attacken werden Anfragen häufig noch über das veraltete Protokoll HTTP/1.1 abgewickelt, während der Großteil legitimer, moderner Clients längst über HTTP/2 kommuniziert. In solchen Fällen kann es sinnvoll sein, HTTP/1.1-Requests pauschal zu sperren. Dies lässt sich mit mod_rewrite bei apache2 in der .htaccess umsetzen. Hierzu reichen wenige Zeilen:
Mithilfe von mod_rewrite in der .htaccess
Blockieren aller HTTP/1.1-Requests
RewriteEngine On
RewriteCond %{THE_REQUEST} HTTP/1\.1$
RewriteRule ^ - [F,L]
Blockieren von HTTP/1.1-Requests unter Ausnahme wichtiger Crawler
Da auch viele Suchmaschinen-Crawler (z.B. Googlebot) noch über HTTP/1.1 arbeiten, würde eine pauschale Sperre auch diese Bots aussperren. Um das zu vermeiden, kann man den User-Agent bekannter Crawler von der Sperre ausnehmen:
RewriteEngine On
RewriteCond %{THE_REQUEST} HTTP/1\.1$
RewriteCond %{HTTP_USER_AGENT} !(Googlebot|bingbot|Slurp|DuckDuckBot|YandexBot|facebookexternalhit) [NC]
RewriteRule ^ - [F,L]
Wichtig: Der User-Agent-Header wird vom Client mitgesendet und lässt sich beliebig fälschen. Ein Angreifer könnte sich also ebenfalls als einer der genannten Bots ausgeben, um die Sperre zu umgehen. Für eine zuverlässige Verifizierung (z.B. per Reverse-DNS-Lookup) reicht reines mod_rewrite nicht aus. Für eine grobe Absicherung während einer akuten DDoS-Welle ist die User-Agent-Prüfung in der Praxis aber meist ausreichend.
Ausnahmen für Nextcloud-Sync und Uptime Kuma
Auch Synchronisations-Clients wie der Nextcloud-Desktop-/Mobile-Client sowie Monitoring-Tools wie Uptime-Kuma greifen häufig über HTTP/1.1 zu und senden dabei einen eigenen User-Agent (z.B. mirall beim Nextcloud-Client bzw. Uptime-Kuma bei Uptime-Kuma). Diese können der Ausnahmeliste ebenfalls hinzugefügt werden:
RewriteEngine On
RewriteCond %{THE_REQUEST} HTTP/1\.1$
RewriteCond %{HTTP_USER_AGENT} !(Googlebot|bingbot|Slurp|DuckDuckBot|YandexBot|Baiduspider|facebookexternalhit|mirall|Uptime-Kuma) [NC]
RewriteRule ^ - [F,L]
Falls ein Nextcloud-Android-Client genutzt wird, sollte auch der User-Agent "Nextcloud-android" hinzugefügt werden, da hier auch noch ein eigener genutzt wird.
Besonderheit bei Shopsystemen: Zahlungsvorgänge
Rückmeldungen von Zahlungsdienstleistern (z.B. Webhooks/Callbacks von PayPal, Klarna, Stripe, Mollie o.ä.) laufen ebenfalls häufig über HTTP/1.1 und würden durch die Sperre blockiert werden, mit der Folge, dass Zahlungen nicht mehr korrekt zurückgemeldet werden und Bestellungen im Shop hängen bleiben.
Diese Callbacks senden in der Regel keinen eindeutigen User-Agent, weshalb eine Ausnahme über HTTP_USER_AGENT hier meist nicht zuverlässig funktioniert. Stattdessen empfiehlt es sich, den betroffenen Pfad direkt von der Regel auszunehmen, z.B.:
RewriteEngine On
RewriteCond %{THE_REQUEST} HTTP/1\.1$
RewriteCond %{REQUEST_URI} !^/zahlungsvorgang [NC]
RewriteRule ^ - [F,L]
Der Pfad /payment/callback muss dabei durch den tatsächlichen Callback-/Webhook-Pfad des jeweiligen Shopsystems bzw. Zahlungsdienstleisters ersetzt werden.