Sperren von HTTP/1.1-Requests per .htaccess - Versionsgeschichte

Rb am 7. September 2026 um 08:23 Uhr

2026-09-07T08:23:18Z

← 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.

Rb am 20. Juli 2026 um 20:18 Uhr

2026-07-20T20:18:42Z

← Nächstältere Version		Version vom 20. Juli 2026, 22:18 Uhr
Zeile 13:		Zeile 13:
	RewriteRule ^ - [F,L]		RewriteRule ^ - [F,L]
	</pre>		</pre>

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

			<pre>
			RewriteEngine On

			RewriteCond %{THE_REQUEST} HTTP/1\.1$
			RewriteCond %{HTTP_USER_AGENT} !(Googlebot\|bingbot\|Slurp\|DuckDuckBot\|YandexBot\|facebookexternalhit) [NC]
			RewriteRule ^ - [F,L]
			</pre>

			'''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.'''

Rb: Die Seite wurde neu angelegt: „Kategorie:WebhostingKategorie:fertig 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…“

2026-07-20T20:15:35Z

Die Seite wurde neu angelegt: „Kategorie:Webhosting Kategorie:fertig 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…“

Neue Seite

[[Kategorie:Webhosting]][[Kategorie:fertig]]

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

<pre>
RewriteEngine On

RewriteCond %{THE_REQUEST} HTTP/1\.1$
RewriteRule ^ - [F,L]
</pre>