Optimiser WordPress : Pnwy sous Stéroide !

La licorne Geekeries allège une page WordPress en retirant une police et des fichiers inutiles

Salut à tous, j’ai profité d’une maintenance récente pour enfin (ré)optimiser le WordPress de Geekeries.org. Pas en installant un énième plugin miracle, mais en regardant ce que le navigateur chargeait vraiment.

Le site n’était pas à genoux. Il fonctionnait, les pages s’ouvraient, et personne ne m’avait signalé de catastrophe. PageSpeed lui me scorait pourtant à 72 sur mobile et 73 sur ordinateur. Le plus visible était le décalage de mise en page : le logo arrivait sans dimensions réservées et poussait le contenu pendant le chargement.

J’ai donc repris la chaîne complète, du reverse proxy jusqu’au navigateur, avec deux règles assez simples : une modification à la fois, et un retour arrière prêt avant de toucher à la production. Pwny m’a aidé à faire l’inventaire et à préparer les contrôles, et les appliquer mais chacun autorisé et vérifié manuellement.

Le serveur n’était pas le principal coupable

Une requête sur le site suit ce chemin : visiteur → Nginx Proxy Manager → Nginx et PHP → WordPress → MariaDB et Redis. Mon premier réflexe aurait pu être de régler PHP-FPM ou d’ajouter encore du cache. Les mesures racontaient autre chose.

Une fois la page anonyme servie à chaud, le TTFB… Lire la suite

Fail2ban, xmlrpc et nginx – Créer sa règle fail2ban maison

Fail2ban xmlrpc et nginx

Salut à tous, je vous propose un nouveau TP sur fail2ban, xmlrpc & nginx. Ceux qui n’ont pas suivi ou qui débutent avec fail2ban sur WordPress devraient commencer par lire cet article qui fait parfaitement le boulot contre 99% des attaques. Néanmoins, ma supervision Splunk m’a permis de repérer une IP qui arrivait à contourner mes protections en créant des codes d’erreurs 499 sur le serveur web via des requêtes foireuses.

Vu que la fonctionnalité XMLRPC est désactivée sur le site, il y a peu de chance que celui-ci arrive à faire quoi que ce soit. Ce n’est pas une raison pour le laisser faire en saturant le serveur de requêtes inutiles…

Pour ceux qui ont lu mon article sur Splunk et Nginx, la requête Splunk qui m’a permis de générer le graphique pour cet article est la suivante :

index=nginx xmlrpc  | timechart count by src

Fail2ban, xmlrpc et nginx

Pour votre culture, les protections en place ne fonctionnaient pas puisque la requête HTTP en code 499 n’arrivait jamais jusqu’à WordPress qui n’avait donc pas la chance d’écrire une ligne de log sur le sujet. Seul le serveur Web traitait la requête, pour rien donc.

Alors j’aurai pu … Lire la suite

Fail2ban pour wordpress pour se protéger des bruteforce

Fail2ban

Salut à tous, aujourd’hui on va voir comment mettre en place Fail2ban pour WordPress.

En fait, je gratte mes logs dans Splunk de Nginx depuis quelque temps et je me suis rendu compte que mon site se faisait bruteforcer dans les règles depuis un bon mois par quelques IP… Du coup, d’une part, j’ai désactivé ou blindé quelques services du site dont je ne me servais pas (xmlrpc, API REST), ce qui a bien limité les tentatives. Mais ça ne protège pas des attaques classique contre la page « wp-login.php« . Du coup, j’ai regardé comment on pouvait sécuriser ça (dans la doc de WordPress). Et j’ai retenu la solution avec fail2ban dont je vous avait déjà parlé précédemment, d’ailleurs. Je vous montre donc ci-dessous comment on peut activer Fail2ban pour WordPress.… Lire la suite

Réinstaller WordPress sur MySQL, PHP5-FPM et NGINX

Wordpress sur MySQL, PHP5-FPM et NGINX

Salut a tous, c’est parti pour la série de TP lié à la migration du site. Et donc pour bien commencer on va voir comment on peut backuper et restaurer le site pour réinstaller WordPress sur MySQL, PHP5-FPM et NGINX. En effet comme je l’annonçais dans ce premier billet j’ai changé le serveur web pour voir si l’herbe est plus verte chez nos amis russes que chez les indiens d’amérique chez NGINX que chez Apache. On verra plus tard pourquoi j’en ai profité utiliser la version FPM de PHP5 et pas le module intégré comme pour apache.

Tout ça se passe entre une Debian 7 et une 8, c’est pas très compliqué mais c’est assez long donc accrochez-vous.

Sauvegarde de l’ancien site

Avant de faire de tout ça et comme je changais de serveur, la première étape était de backuper l’ancien site. La bonne nouvelle c’est WordPress se sauvegarde très bien, j’avais scripté ça et mis le tout dans une crontab. Du coup le script de backup de wordpress est en 3 étapes :

# 1 - Nettoyer le répertoire de sauvegarde
 rm -f /path/to/backup/dir/backup_wordpress.tar.gz

# 2 - sauvegarde des la base mysql
 mysqldump --opt -u <root_ou_userayantlesdroits> -p'<unGrosMot...dePasse>' '<nomDBMySQLWordPress>' 
… Lire la suite