Étiquette : WordPress

Apache, WordPress et redirections

Pour bien commencer l’année 2017, j’ai décidé de remettre le nez dans la configuration Apache du site. Lorsque j’avais installé WordPress pour créer Unicoda en 2012, j’avais renseigné les deux paramètres « Adresse web de WordPress (URL) » et « Adresse web du site (URL) » dans les réglages généraux avec « http://www.unicoda.com ». Du côté de la conf Apache, j’avais indiqué que le serveur répondrai avec le contenu du WordPress pour unicoda.com et www.unicoda.com bien entendu.

Un beau jour, j’ai fini par remarquer qu’en tentant d’accéder au site via unicoda.com, j’étais redirigé vers www.unicoda.com. Cette redirection étant effectuée par WordPress lorsque celui-ci constate que l’url ne correspond pas à l’adresse configurée. Autant vous dire que celle-ci n’était pas des plus rapides. J’ai donc décidé en ce début d’année d’améliorer le processus de redirection en l’effectuant directement au niveau d’Apache.

En modifiant mes fichiers de configuration, j’ai donc ajouté une redirection de unicoda.com vers www.unicoda.com sur les deux protocoles http et https. Désormais, j’ai donc un virtualhost spécifique pour unicoda.com, en lieu et place d’une déclaration comme « ServerAlias » de www.unicoda.com dans un seul fichier de configuration. Le résultat est sans appel puisque la redirection prend désormais 100 ms environ alors qu’elle était de l’ordre de la seconde avant. Si je me base sur un test effectué via gtmetrix, on passe de 2,57 s à 325 ms, presque un facteur 8 (7,9) ! Le gain en rapidité n’est donc pas négligeable.

Pour ce qui est de la redirection http, la configuration est relativement simple :

<VirtualHost *:80>
    ServerName unicoda.com
    Redirect permanent / http://www.unicoda.com
</VirtualHost>

Et enfin, cerise sur le gâteau, l’opération s’est déroulé sans accro après rechargement de la nouvelle configuration par le processus Apache. En  somme, c’est donc une année 2017 qui commence plutôt bien.

Bloquer une IP avec iptables

Depuis deux jours, un petit malin (quarante-six point cent soixante-douze point quatre-vingt-onze point quinze) tente sans succès des injections SQL sur le serveur via WordPress. Félicitations à lui, il gagne un blocage IP!

Pour bloquer une IP avec iptables, on utilisera donc la commande suivante:

iptables -A INPUT -s xxx.xxx.xxx.xxx -j DROP

Dans ce cas-là, c’est un blocage total qui sera effectué. Il est possible d’être plus précis pour ne bloquer qu’un port particulier pour un protocole spécifique avec les options, respectivement, --destination-port et -p. Ce qui nous donne par exemple pour le port 80 sur tcp :

iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port 80 -j DROP

Enfin, si éventuellement, on se décide à débloquer l’adresse IP, l’option -D à la place de -A fera l’affaire :

iptables -D INPUT -s xxx.xxx.xxx.xxx -j DROP

À noter également la commande permettant de visualiser les règles iptables configurées :

iptables -L

Bloquer une IP est une solution facile à mettre en œuvre et (très) efficace. Si de telles attaques devaient reprendre depuis une autre IP, je me verrais dans l’obligation de créer une règle fail2ban afin de bloquer dynamiquement les nouvelles tentatives d’attaque.

 

WordPress, xmlrpc et déni de service

Certains d’entre vous l’ont peut-être constaté, il était plutôt compliqué d’accéder à unicoda.com durant les dernières 48h. En effet, il se trouve que le site a été la cible d’une attaque de type brute force qui l’a mis à mal. Résultat, un processus apache qui décolle et accapare toutes les ressources de la machine jusqu’au déni de service. Retour sur la folle vie d’un serveur attaqué.

Tout commence le 25 août 2016 aux alentours de 19h, la première requête de la série apparaît à 18 heures 46 minutes et 25 secondes pour être précis.

191.96.249.54 - - [25/Aug/2016:18:46:25 +0200] "POST /xmlrpc.php HTTP/1.0" 200 579 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
191.96.249.54 - - [25/Aug/2016:18:46:25 +0200] "POST /xmlrpc.php HTTP/1.0" 200 579 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
191.96.249.54 - - [25/Aug/2016:18:46:25 +0200] "POST /xmlrpc.php HTTP/1.0" 200 579 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

À cette heure-là, pas de problème, le serveur fonctionne correctement. La première alerte sera levée par le système de monitoring d’OVH à 22h54 ce même jour. Le serveur a déclaré forfait et ne répond plus au ping. Quelques minutes plus tard, le support intervient et redémarre le serveur. Une nouvelle alerte sera levée vers 4h du matin, avec intervention du support. En découvrant les mails le matin, je ne flaire pas immédiatement l’attaque. Le support est intervenu, il n’y a pas de précision indiquant si le problème vient du logiciel ou du matériel côté hébergeur, le site ne s’affichant pas, j’effectue à mon tour un redémarrage du serveur et m’assure que les différents services sont bien repartis. Tout semble fonctionner… Pourtant, même scénario dans la nuit de vendredi à samedi avec deux interventions du support. Quelque chose cloche, je continue de vaquer à mes occupations lorsque le serveur devient une nouvelle fois inaccessible samedi vers midi. Pas doute il y a un problème, je vais devoir effectuer des vérifications dès que possible.

Continuer la lecture de « WordPress, xmlrpc et déni de service »

Combattre le spam

S’il y a bien une chose de désagréable lorsqu’un met en place un site web, avec des formulaires de commentaires à la disposition des visiteurs, c’est vous l’avez deviné… le spam. Ça commence par un commentaire de temps en temps, puis un commentaire par jour, puis deux, puis trois et leur nombre augmente encore.

Pour lutter, j’avais donc mis en place le plugin Akismet, qui fait du bon travail, il faut bien le reconnaître. Néanmoins, je préfèrerais me passer de 251 commentaires classés indésirables en moins d’une journée. C’est pourquoi, après quelques recherches, j’ai trouvé le plugin GrowMap Anti-Spambot. Ce plugin ajoute une case à cocher pour confirmer que le visiteur n’est pas un spammeur, si la case n’est pas coché, le commentaire n’est pas sauvegardé. GrowMap ajoute également un champ de formulaire invisible pour les visiteurs mais visible pour un bot lisant le code source de la page. Le bot de spam va donc compléter le champ et identifier ainsi le commentaire comme étant du spam.

Je viens donc de désactiver Askimet pour tester GrowMap pendant quelques jours afin de juger son efficacité. Curieux de voir le résultat.

Migrer son WordPress

C’est effectif depuis jeudi soir, Unicoda dispose maintenant d’un serveur tout neuf. Effectuer une migration de WordPress est en fait relativement simple pour peu qu’un terminal ne vous fasse pas peur et sinon, des interfaces graphiques et autres plugins peuvent parfois vous simplifier encore le travail. Le nom de domaine ne changeant pas, la procédure en est encore simplifiée.

On arrive donc sur un serveur vierge de tout paquets, les paquets de base et c’est tout. Quelques installations s’impose donc, à coup d’aptitude ou de apt-get si vous préférez. Avant toute chose, on met à jour les informations concernant les paquets avec aptitude update, puis mise à jour via aptitude safe-upgrade. Suite à ces manipulations, un petit dpkg-reconfigure tzdata s’impose, histoire d’avoir une heure correcte sur le serveur. L’heure de Moscou, c’est bien beau, mais pour avoir des logs lisibles, une heure française c’est mieux (Bonjour à nos amies russes et biélorusses au passage). Arrive donc la phase d’installation à proprement parler. Via aptitude install, on installe donc les paquets suivants: php5, mysql-server, php5-mysql, php5-gd, vsftp.

Vient ensuite la configuration de vsftp, serveur FTP comme vous avez pu le deviner. On édite le fichier /etc/vsftpd.conf et on relance avec /etc/init.d/vsftpd restart pour que les modifications soient prises en compte.

On s’attaque ensuite à la partie MySQL pour préparer la nouvelle base de données de notre site à accueillir celle provenant de l’autre serveur : mysql -p. Puis dans votre invite de commande MySQL:

>CREATE DATABASE nomBaseDeDonnees;

>GRANT ALL PRIVILEGES ON nomBaseDeDonnees.* TO "NomUtilisateur"@"hostname" IDENTIFIED BY "motDePasse";

>FLUSH PRIVILEGES;

>EXIT;

Concernant les différents paramètres, nomBaseDeDonnes correspond au nom que vous donnez à votre base de données, nomUtilisateur parle de lui-même, hostname est généralement à remplacer par localhost et motDePasse c’est limpide. Votre base de données est donc prête à accueillir vos anciennes informations relatives à vos articles, utilisateurs, commentaires, etc…

Il faut également récupérer le contenu de votre dossier wp-content qui contient toutes les images que vous avez pu héberger sur votre site, les thèmes et les plugins. Un téléchargement du dossier via un client FTP fonctionnera très bien. Compresser le dossier avant envoi vous permettra de patienter moins longtemps pendant le téléchargement de vos données et surtout, pendant leur upload à venir. Une fois le dossier téléchargé, on l’upload justement vers le nouveau serveur; cette étape prend du temps surtout si votre dossier n’est pas compressé et que votre upload se résume à du 36Ko/s. On peut ensuite remplacer le dossier wp-content de notre installation toute fraîche de WordPress par celui de notre ancien site.

Il faut également transférer les données de  l’ancien base de données et les injecter dans la nouvelle. La commande suivante vous permet de récupérer les anciennes données dans un fichier:

mysqldump --add-drop-table -h mysqlhostserver -u mysqlusername -p databasename | bzip2 -c > fichier.bak.sql.bz2.

Au niveau des paramètres, localhost pour mysqlhostserver, votre nom d’utilisateur pour mysqlusername, le nom de l’ancienne base de données à la place de databasename et remplacer fichier par le nom que vous voulez pour votre sauvegarde des données. On récupère ensuite le fichier via notre ftp, on l’upload à son tour vers le nouveau serveur, on décompresse au préalable le fichier: bzip2 -d fichier.bak.sql.bz2 et on injecte les données dans notre nouvelle base de données:

mysql -h mysqlhostserver -u mysqlusername -p databasename < fichier.bak.sql

Avec localhost pour mysqlhostserver, votre nom d’utilisateur mysql pour mysqlusername et le nom de votre nouvelle base de données en lieu et place de databasename. A ce stade, votre nouveau site est presque opérationnel, il ne reste plus qu’à faire pointer le nom de domaine vers le nouveau serveur, configurer apache (Doc Ubuntu) et éditer le fichier wp-config.php de votre nouveau WordPress avec les paramètres utilisés pour la création de la nouvelle base de données.

On trouve la plupart des informations dont on a besoin sur le web, et notamment sur le site de WordPress. Quelques heures suffisent donc à effectuer la migration d’un site WordPress vers un nouveau serveur si on conserve le même nom de domaine, le plus long étant à mon sens, l’upload du dossier wp-content.