WordPress attaque XML-RPC
Hier, j'ai subi une attaque par DDoS sur un site WordPress. J'ai eu 21 443 hits avec le code d'état HTTP 404 et une bande passante de 711,85 Mo . En outre, l'utilisation du processeur est allé à 100%.
Les journaux montrent beaucoup de ces entrées:
...
119.71.5.44 - - [03/Sep/2014:18:34:57 -0700] "POST /xmlrpc.php HTTP/1.1" 404 34826 "-" "-"
197.149.17.195 - - [03/Sep/2014:18:35:01 -0700] "POST /xmlrpc.php HTTP/1.0" 404 34826 "-" "-"
210.206.226.130 - - [03/Sep/2014:18:35:04 -0700] "POST /xmlrpc.php HTTP/1.1" 404 34826 "-" "-"
...
J'essaie de comprendre ce journal.
- Ce n'était qu'une attaque DDoS ou ils essayaient de pirater mon site?
- Étais-je attaqué ou ont-ils utilisé mon site pour attaquer d'autres personnes? (toutes les entrées IP sont différentes)
- Quel est le meilleur moyen d'arrêter cela? Modifier le fichier .htaccess ou Ajouter un filtre dans functions.php
Mise à jour: informations de base
- J'avais WordPress 3.9.2. Maintenant, j'ai mis à jour WordPress vers la dernière version (4.0).
- Le site est sur un hébergement partagé (avec cPanel X).
- L'attaque a commencé le 02/Sep/2014 18:06:57 -0700 et s'est terminée le 03/Sep/2014 21:22:24 -0700
En outre, une heure avant l'attaque, le journal montre ceci:
82.27.195.149 - - [02/Sep/2014:16:50:52 -0700] "GET /xmlrpc.php HTTP/1.1" 200 42 "-" "Mozilla/5.0 (Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20100101 Firefox/8.0"
82.27.195.149 - - [02/Sep/2014:16:50:54 -0700] "GET /wp-login.php HTTP/1.1" 200 2663 "-" "Mozilla/5.0 (Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20100101 Firefox/8.0"
Et deux heures après le début, j'ai trouvé ceci:
184.176.42.181 - - [02/Sep/2014:19:58:18 -0700] "GET /wp-login.php HTTP/1.1" 200 2663 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:18 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:18 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:19 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:19 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:20 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:20 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:20 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:21 -0700] "GET /blog/wp-login.php HTTP/1.1" 404 34107 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
Donc, je suppose qu'ils essayaient de pirater mon compte via XML-RPC.
J'étudie et recherche des processus avancés pour la défense et la détection de telles choses La réponse de Rarst est techniquement correcte. Pas de question. Cependant, cela sent ce qui est extrêmement typique, laissez-moi vous expliquer.
Un certain nombre de systèmes ont été compromis et Wordpress sites ont probablement été attaqués en masse et ciblent maintenant les vulnérabilités connues de manière presque aléatoire. Peu importe que les sites aient Wordpress installé ou non. Souvent, ces attaques tentent de tirer parti de la même vulnérabilité qui a réussi sur le système compromis, mais peuvent également utiliser une base de données dictionnaire de vulnérabilités pour rechercher des systèmes plus compromis.
L'application web PHP la plus attaquée est Wordpress. Il y a deux raisons à cela. La popularité et l'installation de base, le succès de deux pirates informatiques dans le passé et les vulnérabilités présentes dans le logiciel rendent très probable la réussite d'un pirate informatique. Ce n'est pas que Wordpress soit mal codé. C'est bien codé. C’est plus que Wordpress est compliqué et que le code en cause et que des vulnérabilités existent et peuvent continuer à exister.
Ce n'est pas un DDoS ou un DoS. Juste script-Kiddies faire ce qu'ils font. Bloquez simplement les attaques pour l'instant. Ils finiront par s'arrêter. Il est préférable d’arrêter ces accès à l’endroit le plus éloigné du serveur, si possible. Il s’agit souvent d’un pare-feu ou d’un routeur configurable. Si ceux-ci ne sont pas disponibles, je suggère d'utiliser ModSecurity à l'adresse https://www.modsecurity.org/ . C'est un logiciel de type pare-feu très efficace conçu pour fonctionner sur le serveur Web et s'intégrer à Apache et IIS.
Assurez-vous que vous utilisez une version stabilisée de Wordpress. Il est important de vérifier périodiquement pour vous assurer que vous utilisez un logiciel mis à jour. De même, assurez-vous que les plug-ins que vous utilisez sont également sécurisés.
Il peut être difficile de retrouver ces informations, mais je peux recommander un centre d’échange des avis de sécurité. C’est l’endroit de facto où aller alors que d’autres sites avec les mêmes données existent. Vous pouvez rechercher les vulnérabilités ici https://www.us-cert.gov/ncas et vous tenir au courant des notifications par courrier électronique. Je recommande vivement à chaque webmaster de s'inscrire à ces avis ou de consulter ce site souvent.
Vous pouvez également suivre ce groupe en utilisant Twitter: https://Twitter.com/uscert_gov
Voici le top Tweet dans la liste au moment de l'écriture:
Mise à jour de sécurité pour WordPress: Date de publication initiale: le 04 septembre 2014 WordPress 3.9.2 a été publié ... http://1.usa.gov/1ryt7bZ
Ce n'était qu'une attaque DDoS ou ils essayaient de pirater mon site?
Il n’ya aucun moyen de connaître l’aspect fonctionnel de celui-ci sans consulter la charge utile POST. Puisqu'il visait interactif endpoint, je suppose que cela avait un but, autre que le simple épuisement de vos ressources. Bien qu'ils aient peut-être essayé (sans succès - aucun moyen de le savoir sans voir les charges utiles) d'utiliser ce point de terminaison spécifique pour augmenter la charge produite.
Étais-je attaqué ou ont-ils utilisé mon site pour attaquer d'autres personnes? (toutes les entrées IP sont différentes)
Il existe un certain nombre de techniques qui "rebondissent" de site pour le faire participer involontairement à des attaques. Je ne suis pas en sécurité pour dire si XML-RPC est approprié, mais ce ne serait pas ma première pensée.
Quel est le meilleur moyen d'arrêter cela? Modifier le fichier .htaccess ou Ajouter un filtre dans functions.php
Plus le niveau est bas, mieux c'est. Donc, le bloquer au niveau du serveur Web vaut mieux que le niveau PHP. Le bloquer au niveau du réseau est préférable au niveau du serveur Web (mais va plus loin dans le domaine de l'hébergement en prenant soin de cela et/ou de solutions coûteuses).
XML-RPC est utilisé pour les mots de passe en force brute
Outre les problèmes de sécurité mentionnés dans les autres réponses, il y a eu une augmentation des attaques par force brute contre xmlrpc.php. Ces attaques tentent de gagner des mots de passe. Sucuri a de la documentation de Nice à ce sujet.
Ce n'est pas un bug dans le logiciel. L'implémentation XML-RPC de WP inclut des routines d'authentification. Les attaquants ont opté pour cette technique car elle n’est souvent pas bloquée par divers plug-ins de force brute et est plus rapide.
Si vous n'utilisez aucun service nécessitant XML-RPC, vous pouvez simplement le désactiver. Je recommande de définir les autorisations de fichier sur 000.
De cette façon, vous pouvez facilement annuler le changement s'il provoque des problèmes. Notez que les pingbacks utilisent xml-rpc, donc cela les cassera si vous les avez activés.
Nous avons vu cette attaque augmenter et tomber sur les serveurs que nous gérons La plupart du temps, ils ne sont pas détectés sur les systèmes d'hébergement partagé sans aucun type de pare-feu d'application Web. Nous ne constatons l'impact réel sur les serveurs que lorsque plusieurs sites sont touchés en même temps et/ou que les fournisseurs d'hébergement utilisent CloudLinux pour contrôler les ressources compte par compte.
Mise à jour:
Problème XML-RPC DOS ou force brute?
Par coïncidence, nous venons de recevoir une alerte du serveur du client pour les problèmes de charge. L'enquête a révélé qu'un WP site était attaqué. J'ai fait une petite analyse supplémentaire et suis venu avec cette vérification pour déterminer si vous souffrez d'un problème XML-RPC DOS ou d'une attaque par mot de passe.
Il y a deux signes évidents d'un exploit DoS XML-RPC:
- Plusieurs connexions sortantes vers des sites Web distants.
- Taux de trafic élevé vers xmlrpc.php
Avec une attaque par force brute, vous ne verriez pas ces requêtes sortantes adressées à un serveur Web distant.
En regardant la page Statut Apache, nous voyons:
7-0 17954 0/11/11 _ 0.96 2 16149 0.0 0.01 0.01 attacker.com localhost POST /xmlrpc.php HTTP/1.0
8-0 17962 0/10/10 _ 1.14 0 0 0.0 0.00 0.00 attacker.com localhost POST /xmlrpc.php HTTP/1.0
9-0 17968 0/10/10 _ 0.77 3 0 0.0 0.00 0.00 attacker.com localhost POST /xmlrpc.php HTTP/1.0
localhost est l'hôte attaqué.
attacker.com est un système distant inondant les demandes adressées à xmlrpc.php.
En regardant netstat (adresses IP nettoyées pour des raisons de confidentialité):
tcp 0 0 localhost:39254 remotehost:80 TIME_WAIT -
tcp 0 0 localhost:39248 remotehost:80 TIME_WAIT -
tcp 0 0 localhost:39251 remotehost:80 TIME_WAIT -
tcp 0 0 localhost:39250 remotehost:80 TIME_WAIT -
tcp 0 1 localhost:39260 remotehost:80 FIN_WAIT1 -
tcp 0 0 localhost:39257 remotehost:80 TIME_WAIT -
tcp 0 0 localhost:39258 remotehost:80 TIME_WAIT -
tcp 0 0 localhost:39237 remotehost:80 TIME_WAIT -
remotehost est la victime de l'attaque DoS.
Généralement, votre localhost ne devrait pas appeler un serveur Web distant à moins d'utiliser une sorte d'API distante. Même alors, voir des centaines de telles connexions est hautement suspect. Notez que nous avons vu les deux ports 80 et 443 sous attaque.
Pour confirmer le type d'attaque, nous avons capturé du trafic et trouvé cette charge utile:
POST /xmlrpc.php HTTP/1.0
Host: localhost
Content-type: text/xml
Content-length: 268
User-agent: Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)
Connection: close
<?xmlversion="1.0"?><methodCall><methodName>pingback.ping</methodName><params><param><value><string>http://victim.com</string></value></param><param><value><string>http://localhost/blog/just-another-post/</string></value></param></params></methodCall>
Dans ce cas, localhost était en fait une adresse IP et non un nom de domaine. Je ne suis pas sûr qu'une adresse IP soit requise pour cette attaque, mais je dirais que cela élimine le besoin de recherches DNS à la fois pour attaquer et pour scanner.
Sucuri a une bonne écriture attaque de type WP XMLRPC aussi bien que Incapsula .