IP-Adressen von Jetpack zur Allowlist hinzufügen
Zuletzt aktualisiert:
Steuern Sie, wer auf Ihre Website zugreifen kann (oder nicht), indem Sie IP-Adressen in WordPress zulassen.
Stellen Sie sicher, dass Jetpack auf Ihre Website zugreifen kann, damit wir Backups durchführen, Sicherheitsprüfungen ausführen und sie auf eine frühere Version zurücksetzen können.
Jegliche Kommunikation zwischen Jetpack und WordPress.com zulassen
Wenn Sie sicherstellen möchten, dass Jetpack mit Ihrer Website kommunizieren kann, oder wenn Sie vom Support angewiesen wurden, unsere IPs zur Allowlist hinzuzufügen, lassen Sie bitte diese IP-Bereiche zu:
IP-Adressen von Jetpack
122.248.245.244/3254.217.201.243/3254.232.116.4/32192.0.80.0/20192.0.96.0/20192.0.112.0/20195.234.108.0/22192.0.64.0/18
Wichtig: Diese IP-Adressen können sich ändern. Wenn Sie IP-basierte Firewall-Regeln erstellen, müssen Sie diese Regeln jedes Mal aktualisieren, wenn sich die Adressen ändern. Wir stellen diese IP-Bereiche außerdem in maschinenlesbaren Versionen im JSON und im Klartext format zur Verfügung, die Sie verwenden können, um Konfigurationsänderungen auf Ihren Systemen zu automatisieren.
Zugriff durch Jetpack und XMLRPC.php
Jetpack verwendet xmlrpc.php, um mit WordPress.com zu kommunizieren. Wenn xmlrpc.php für alle blockiert wird, funktioniert die Verbindung von Jetpack nicht mehr.
Sie müssen xmlrpc.php nicht vollständig blockieren, um Ihre Website zu schützen. Erlauben Sie stattdessen Anfragen an xmlrpc.php aus den oben aufgeführten IP-Bereichen von Jetpack und blockieren Sie Anfragen aus allen anderen Quellen. Im folgenden Abschnitt wird erklärt, wie Sie Datenverkehr, der tatsächlich von Jetpack stammt, von Datenverkehr unterscheiden, der nur vorgibt, von Jetpack zu stammen, und wie Sie diese Regel einrichten.
Datenverkehr, der tatsächlich von Jetpack stammt, von Datenverkehr unterscheiden, der fälschlich Jetpack zugerechnet wird
Da Jetpack auf Millionen von Websites läuft, senden Bots häufig Anfragen an xmlrpc.php mit einem User-Agent, der „Jetpack“ oder „WordPress.com“ angibt, damit der Datenverkehr legitim aussieht. Ein User-Agent ist Text, den der Absender selbst festlegt, und beweist daher nicht, woher eine Anfrage stammt. Sicherheitsforscher haben Websites gefunden, bei denen die meisten Anfragen, die vorgaben, von Jetpack zu stammen, außerhalb des Netzwerks von Automattic kamen.
Eine echte Anfrage von WordPress.com an Ihre Website weist alle folgenden Merkmale auf:
- Sie stammt aus einem der oben aufgeführten IP-Bereiche. Dies ist die einzige zuverlässige Prüfung. Die Liste wird unter https://jetpack.com/ips-v4.txt und https://jetpack.com/ips-v4.json aktuell gehalten. WordPress.com verbindet sich ausschließlich über IPv4 mit Ihrer Website. Daher gibt es keine IPv6-Liste, und die Domain Ihrer Website benötigt einen A-Eintrag, damit Jetpack eine Verbindung herstellen kann.
- Sie enthält
for=jetpackin der Abfragezeichenfolge, zusammen mittoken,timestamp,nonce,body-hashundsignatureParametern. Jetpack überprüft diese Signatur, bevor irgendetwas ausgeführt wird. Eine Anfrage an ein reines /xmlrpc.php ohne weitere Angaben stammt nicht von Jetpack, unabhängig davon, was der User-Agent angibt.
Eine gefälschte Anfrage besteht die Signaturprüfung von Jetpack nicht, aber WordPress wurde bis dahin bereits geladen, sodass jede Anfrage Ihren Server trotzdem eine vollständige Anfrage an PHP kostet. Um diese Belastung zu vermeiden, blockieren Sie gefälschte Anfragen auf dem Webserver, bevor WordPress gestartet wird.
xmlrpc.php ausschließlich von Jetpack zulassen
Die folgenden Regeln lassen xmlrpc.php aus den IP-Bereichen von Jetpack zu und geben allen anderen eine 403-Antwort zurück. Wenn Sie die mobilen Apps von WordPress, ein Desktop-Publishing-Tool oder einen anderen Dienst verwenden, der über XML-RPC eine Verbindung herstellt, fügen Sie auch dessen IP-Adressen hinzu.
Apache (.htaccess)
<Files "xmlrpc.php"> Require ip 122.248.245.244 54.217.201.243 54.232.116.4 192.0.64.0/18 192.0.80.0/20 192.0.96.0/20 192.0.112.0/20 195.234.108.0/22</Files>
nginx
Ein separater location-Block für xmlrpc.php ersetzt für diese Datei die normale Verarbeitung von PHP auf der Website, daher muss der Block die Anfrage selbst an PHP weiterleiten. Kopieren Sie die Zeile fastcgi_pass sowie alle anderen FastCGI-Einstellungen aus Ihrem vorhandenen location ~ \.php$ Block.
location = /xmlrpc.php { allow 122.248.245.244; allow 54.217.201.243; allow 54.232.116.4; allow 192.0.64.0/18; allow 192.0.80.0/20; allow 192.0.96.0/20; allow 192.0.112.0/20; allow 195.234.108.0/22; deny all; # Same PHP handling as the rest of the site. Match these lines to your existing PHP location block. include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/run/php/php-fpm.sock;}
Cloudflare
Wenn sich Ihre Website hinter Cloudflare oder einem anderen Proxy befindet, sieht Ihr Webserver die IP-Adresse des Proxys und nicht die des Besuchers. Daher funktionieren die oben genannten Regeln nur, wenn Ihr Server so konfiguriert ist, dass er die echte Besucher-IP wiederherstellt. Es ist einfacher, die Regel stattdessen in Cloudflare hinzuzufügen. Erstellen Sie eine benutzerdefinierte WAF-Regel, die Anfragen blockiert, bei denen:
(http.request.uri.path contains "xmlrpc.php" and not ip.src in {122.248.245.244 54.217.201.243 54.232.116.4 192.0.64.0/18 192.0.80.0/20 192.0.96.0/20 192.0.112.0/20 195.234.108.0/22})
Wenden Sie die Zulassungsliste nicht auf die gesamte Website an
Beschränken Sie die Regel auf xmlrpc.php. Andere Funktionen von Jetpack erreichen Ihre Website über andere Netzwerke. Beispielsweise erzeugt Jetpack Boost kritisches CSS über die im folgenden Abschnitt von Jetpack Boost aufgeführten Hosting-Anbieter, und das CDN für Bilder von Jetpack ruft Ihre Bilder von eigenen Servern ab. Eine standortweite IP-Zulassungsliste würde diese Funktionen beeinträchtigen.
Testen Sie die Änderung
- Öffnen Sie Jetpack → Dashboard im Administrationsbereich Ihrer Website und bestätigen Sie, dass die Verbindung noch aktiv ist. Sie können Ihre Website auch über das Debugging-Tool von Jetpack.
- Senden Sie von einem Computer außerhalb der IP-Bereiche von Jetpack eine Anfrage an xmlrpc.php und bestätigen Sie, dass Sie eine 403 erhalten:
curl -s -o /dev/null -w "%{http_code}\n" -X POST https://example.com/xmlrpc.php
- Prüfen Sie Ihre Zugriffsprotokolle auf
//xmlrpc.phpmit doppeltem Schrägstrich. Einige Bots verwenden ihn, und manche Protokolltools zählen ihn als eine andere URL. Die Regeln für nginx, Apache und Cloudflare oben stimmen damit überein. Wenn Sie eine eigene Regel erstellt haben, achten Sie darauf, dass sie dies ebenfalls tut.
Die IP-Bereiche können sich ändern. Wenn Sie diese Regel manuell erstellen, prüfen Sie die veröffentlichte Liste von Zeit zu Zeit oder automatisieren Sie sie anhand der Klartext- oder JSON-Liste, damit sie sich selbstständig aktualisiert.
Verwenden Sie Jetpack mit Cloudflare (keine zusätzlichen Sicherheitsregeln)
Standardmäßig sollten Cloudflare und Jetpack keine zusätzliche Konfiguration benötigen, um zusammen zu funktionieren, sofern mit Cloudflare keine zusätzlichen Sicherheitseinstellungen festgelegt wurden.
Jetpack mit Cloudflare verwenden (zusätzliche Sicherheitsregeln) und Sucuri
Wenn Sie Cloudflare (mit zusätzlichen Sicherheitsregeln) oder Sucuri verwenden, fügen Sie bitte die IP-Adressen von Jetpack manuell hinzu.
Wenn Sie Cloudflare nutzen, wird dort außerdem nur Datenverkehr von Servern mit einer bestimmten ASN (Autonomous System Number) zugelassen. Um dies zu konfigurieren, können Sie den Zugriff auf 2635.
192.0.64.0/24192.0.65.0/24192.0.66.0/24192.0.67.0/24192.0.68.0/24192.0.69.0/24192.0.70.0/24192.0.71.0/24192.0.72.0/24192.0.73.0/24192.0.74.0/24192.0.75.0/24192.0.76.0/24192.0.77.0/24192.0.78.0/24192.0.79.0/24192.0.80.0/24192.0.81.0/24192.0.82.0/24192.0.83.0/24192.0.84.0/24192.0.85.0/24192.0.86.0/24192.0.87.0/24192.0.88.0/24192.0.89.0/24192.0.90.0/24192.0.91.0/24192.0.92.0/24192.0.93.0/24192.0.94.0/24192.0.95.0/24192.0.96.0/24192.0.97.0/24192.0.98.0/24192.0.99.0/24192.0.100.0/24192.0.101.0/24192.0.102.0/24192.0.103.0/24192.0.104.0/24192.0.105.0/24192.0.106.0/24192.0.107.0/24192.0.108.0/24192.0.109.0/24192.0.110.0/24192.0.111.0/24192.0.112.0/24192.0.113.0/24192.0.114.0/24192.0.115.0/24192.0.116.0/24192.0.117.0/24192.0.118.0/24192.0.119.0/24192.0.120.0/24192.0.121.0/24192.0.122.0/24192.0.123.0/24192.0.124.0/24192.0.125.0/24192.0.126.0/24192.0.127.0/24
Strenge Firewall-Konfigurationen und Jetpack Boost
Wenn Sie Funktionen von Jetpack Boost zusammen mit strengen Firewall-Regeln verwenden, müssen Sie Ausnahmen für Unterauftragsverarbeiter der Fly.io-Hosting-Provider gewähren. Um alle Funktionen von Jetpack Boost optimal zu nutzen, stellen Sie sicher, dass die ASNs aller Hosting-Provider von Fly.io zur Allowlist hinzugefügt werden. Dazu gehören derzeit CacheNetworks, Equinax, NetActuate und OVH. Wenn Fly.io neue Hosting-Provider hinzufügt, können Sie PeeringDB.com verwenden, um die ASNs zu finden, die zur Allowlist hinzugefügt werden müssen.
Still need help?
Please contact support. We’re happy to advise.
