Ajouter les adresses IP de Jetpack à une liste d’autorisation

Contrôlez qui peut (ou ne peut pas) accéder à votre site en autorisant des adresses IP dans WordPress.

Assurez-vous que Jetpack peut accéder à votre site afin que nous puissions effectuer des sauvegardes, des analyses de sécurité et restaurer votre site dans une version précédente.

Autoriser toutes les communications entre Jetpack et WordPress.comMD

Si vous souhaitez vous assurer que Jetpack peut communiquer avec votre site, ou si notre équipe d’assistance vous a conseillé d’ajouter nos adresses IP à une liste d’autorisation, veuillez autoriser ces plages d’adresses IP :

Adresses IP de JetpackMD

• 122.248.245.244/32
• 54.217.201.243/32
• 54.232.116.4/32
• 192.0.80.0/20
• 192.0.96.0/20
• 192.0.112.0/20
• 195.234.108.0/22
• 192.0.64.0/18

Important : Ces adresses IP peuvent changer. Si vous définissez des règles de pare-feu fondées sur des adresses IP, vous devrez les mettre à jour chaque fois que les adresses changent. Nous proposons également des versions lisibles par machine de ces plages d’adresses IP aux formats JSON et texte brut que vous pouvez utiliser pour automatiser les modifications de configuration sur vos systèmes.

Accès à Jetpack et XMLRPC.phpMD

Jetpack utilise xmlrpc.php pour communiquer avec WordPress.com. Si xmlrpc.php est bloqué pour tout le monde, la connexion de votre Jetpack cessera de fonctionner.

Vous n’avez pas besoin de bloquer complètement xmlrpc.php pour protéger votre site. Autorisez plutôt les requêtes vers xmlrpc.php provenant des plages d’adresses IP Jetpack ci-dessus et bloquez les requêtes provenant de partout ailleurs. La section ci-dessous explique comment distinguer le trafic authentique de Jetpack du trafic qui prétend seulement être celui de Jetpack, et comment configurer cette règle.

Distinguer le trafic authentique de Jetpack du faux trafic de JetpackMD

Comme Jetpack fonctionne sur des millions de sites, les robots envoient souvent des requêtes à xmlrpc.php avec un agent utilisateur indiquant « Jetpack » ou « WordPress.com », afin que le trafic paraisse légitime. Un agent utilisateur est un texte choisi par l’expéditeur ; il ne prouve donc pas l’origine de la requête. Des chercheurs en sécurité ont trouvé des sites où la plupart des requêtes prétendant provenir de Jetpack venaient de l’extérieur du réseau d’Automattic.

Une requête authentique de WordPress.com vers votre site présente toutes les caractéristiques suivantes :

• Elle provient de l’une des plages d’adresses IP répertoriées ci-dessus. Il s’agit du seul contrôle fiable. La liste est tenue à jour à https://jetpack.com/ips-v4.txt et https://jetpack.com/ips-v4.json. WordPress.com se connecte à votre site uniquement via IPv4 ; il n’existe donc pas de liste IPv6, et le domaine de votre site doit avoir un enregistrement A pour que Jetpack puisse se connecter.
• Elle inclut for=jetpack dans la chaîne de requête, ainsi que token, timestamp, nonce, body-hash et signature qui sont les paramètres. Jetpack vérifie cette signature avant toute exécution. Une requête vers /xmlrpc.php sans rien après n’est pas une requête de Jetpack, quel que soit son agent utilisateur.

Une fausse requête échoue à la vérification de signature de Jetpack, mais WordPress est déjà chargé à ce stade ; chacune coûte donc toujours à votre serveur une requête PHP complète. Pour éviter ce coût, bloquez les fausses requêtes au niveau du serveur web avant le démarrage de WordPress.

Autoriser xmlrpc.php uniquement depuis JetpackMD

Les règles ci-dessous autorisent xmlrpc.php depuis les plages d’adresses IP de Jetpack et renvoient une erreur 403 à tous les autres. Si vous utilisez les applications mobiles de WordPress, un outil de publication sur ordinateur ou un autre service qui se connecte via XML-RPC, ajoutez également ses adresses IP.

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

Un bloc location distinct pour xmlrpc.php remplace le traitement habituel de ce fichier par PHP sur le site ; le bloc doit donc transmettre lui-même la requête à PHP. Copiez la ligne fastcgi_pass ainsi que tous les autres paramètres fastcgi de votre bloc location ~ \.php$ existant.

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

Si votre site se trouve derrière Cloudflare ou un autre proxy, votre serveur web voit l’adresse IP du proxy, et non celle du visiteur. Les règles ci-dessus ne fonctionneront donc pas, sauf si votre serveur est configuré pour restaurer l’adresse IP réelle du visiteur. Il est plus simple d’ajouter la règle dans Cloudflare. Créez une règle WAF personnalisée qui bloque les requêtes lorsque :

(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})

N’appliquez pas la liste d’autorisation à l’ensemble du siteMD

Limitez la règle à xmlrpc.php. D’autres fonctionnalités de Jetpack accèdent à votre site depuis d’autres réseaux. Par exemple, Jetpack Boost génère du CSS critique à partir des hébergeurs répertoriés dans la section Jetpack Boost ci-dessous, et le CDN d’images Jetpack récupère vos images depuis ses propres serveurs. Une liste d’adresses IP autorisées à l’échelle du site empêcherait ces fonctionnalités de fonctionner.

Tester après avoir effectué la modificationMD

1. Ouvrez Jetpack → Tableau de bord dans l’administration de votre site et confirmez que la connexion est toujours active. Vous pouvez également vérifier votre site à l’aide de l’outil de débogage de Jetpack.
2. Depuis un ordinateur situé en dehors des plages d’adresses IP de Jetpack, envoyez une requête à xmlrpc.php et vérifiez que vous obtenez une erreur 403 :

curl -s -o /dev/null -w "%{http_code}\n" -X POST https://example.com/xmlrpc.php

3. Consultez vos journaux d’accès pour //xmlrpc.php avec une double barre oblique. Certains robots l’utilisent, et certains outils de journalisation la comptent comme une autre adresse URL. Les règles nginx, Apache et Cloudflare ci-dessus la prennent en compte, mais si vous avez créé votre propre règle, assurez-vous qu’elle en fasse autant.

Les plages d’adresses IP peuvent changer. Si vous créez cette règle manuellement, consultez régulièrement la liste publiée ou automatisez sa mise à jour à partir de la liste en texte brut ou au format JSON.

Utiliser Jetpack avec Cloudflare (aucune règle de sécurité supplémentaire)MD

Par défaut, Cloudflare et Jetpack ne devraient nécessiter aucune configuration supplémentaire pour fonctionner ensemble si aucune configuration de sécurité supplémentaire n’est spécifiée avec Cloudflare.

Utiliser Jetpack avec Cloudflare (règles de sécurité supplémentaires) et SucuriMD

Si vous utilisez Cloudflare (avec des règles de sécurité supplémentaires) ou Sucuri, veuillez ajouter manuellement les adresses IP de Jetpack.

Si vous utilisez Cloudflare, celui-ci prend également en charge l’autorisation exclusive du trafic provenant de serveurs possédant un ASN spécifique (numéro de système autonome). Pour le configurer, vous pouvez autoriser l’accès à 2635.

• 192.0.64.0/24
• 192.0.65.0/24
• 192.0.66.0/24
• 192.0.67.0/24
• 192.0.68.0/24
• 192.0.69.0/24
• 192.0.70.0/24
• 192.0.71.0/24
• 192.0.72.0/24
• 192.0.73.0/24
• 192.0.74.0/24
• 192.0.75.0/24
• 192.0.76.0/24
• 192.0.77.0/24
• 192.0.78.0/24
• 192.0.79.0/24
• 192.0.80.0/24
• 192.0.81.0/24
• 192.0.82.0/24
• 192.0.83.0/24
• 192.0.84.0/24
• 192.0.85.0/24
• 192.0.86.0/24
• 192.0.87.0/24
• 192.0.88.0/24
• 192.0.89.0/24
• 192.0.90.0/24
• 192.0.91.0/24
• 192.0.92.0/24
• 192.0.93.0/24
• 192.0.94.0/24
• 192.0.95.0/24
• 192.0.96.0/24
• 192.0.97.0/24
• 192.0.98.0/24
• 192.0.99.0/24
• 192.0.100.0/24
• 192.0.101.0/24
• 192.0.102.0/24
• 192.0.103.0/24
• 192.0.104.0/24
• 192.0.105.0/24
• 192.0.106.0/24
• 192.0.107.0/24
• 192.0.108.0/24
• 192.0.109.0/24
• 192.0.110.0/24
• 192.0.111.0/24
• 192.0.112.0/24
• 192.0.113.0/24
• 192.0.114.0/24
• 192.0.115.0/24
• 192.0.116.0/24
• 192.0.117.0/24
• 192.0.118.0/24
• 192.0.119.0/24
• 192.0.120.0/24
• 192.0.121.0/24
• 192.0.122.0/24
• 192.0.123.0/24
• 192.0.124.0/24
• 192.0.125.0/24
• 192.0.126.0/24
• 192.0.127.0/24

Configurations strictes du pare-feu et Jetpack BoostMD

Si vous utilisez les fonctionnalités de Jetpack Boost avec des règles de pare-feu strictes, vous devrez accorder des exceptions pour les sous-traitants des fournisseurs d’hébergement de Fly.io. Pour tirer pleinement parti de toutes les fonctionnalités de Jetpack Boost, assurez-vous que l’ASN de chacun des hébergeurs de Fly.io est ajouté à une liste d’autorisation. À l’heure actuelle, cela inclut CacheNetworks, Equinax, NetActuate, et OVH. Si Fly.io ajoute de nouveaux hébergeurs, vous pouvez utiliser PeeringDB.com pour localiser les ASN à ajouter à la liste d’autorisation.