Sperren von HTTP/1.1-Requests per .htaccess

Rb — Mon, 07 Sep 2026 08:23:18 GMT

← Nächstältere Version		Version vom 7. September 2026, 10:23 Uhr
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.

Artfiles Support - Letzte Änderungen [de]

Sperren von HTTP/1.1-Requests per .htaccess