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

Migration de WordPress : le G33keries.org nouveau est là !

migration de wordpress

Alors vous n’avez peu être pas remarqué, mais le site est sur un serveur tout nouveau, tout beau ! Presque rien de visuellement notable pour vous, mais sous le capot, il y a eu pas mal de changements pour cette migration de wordpress :

  • Migration du serveur Kimsufi KS-1 au Canada vers une Dedibox® XC 2016 d’Online  aux Pays-Bas. Je vous en avais parlé dans cet article, comme ça c’est fait. Résultat : Bande passante multipliée par dix, 4 CPU au lieu de 2, RAM x 8, espace disque doublé. Je me se sent moins à l’étroit d’un seul coup…
    Et comme je me rapproche de la France, des pings bien meilleurs pour mes lecteurs en métropole :
    • Time to Fisrt Byte de l’ancien serveur depuis Paris : 0.259s
    • Time to Fisrt Byte de du nouveau serveur depuis Paris : 0.094s
  • Changement de la « stack » du site web, notamment pour des raisons de performances, de cache et d’optimisations :
    • Avant, le site fonctionnait avec la pile suivante : mysql + php5 + apache + varnish.
    • Maintenant, c’est mysql + php5-fpm + NGINX + FastCGI-Cache.
  • Des réglages HTTPS aux petits oignons qui est passé du vieux B- que
Lire la suite

Varnish devant WordPress sur Apache

Varnish-Cache

Alors je ne sais pas si vous avez remarqué, mais le blog va (un peu) plus vite à charger ces derniers temps ? Après mon serveur n’est pas monstrueux non plus (1 cœur/2GB RAM : ne vous amusez pas à me faire un DDOS, ça tombera probablement dès la 10ème connexion simultané…)

Bref, j’ai suivi une partie de cet article pour essayer d’améliorer, modestement les performances du blog, j’ai déjà :

  • Mis facilement WP Super Cache en place, et fait les réglages associés ;
  • Ajouté le Plugin WP Smush pour compresser les images sans pertes (toujours ça de gagné) ;
  • Utilisé gtmetrix.com et webpagetest.org pour savoir quoi améliorer sur le site ; et
  • J’ai fait un peu de ménage dans les « grosses » images qui étaient sur la page d’accueil, pour éviter qu’elles ne soient re-sizées par votre navigateur, et vous servir de suite celle à la bonne taille.

Bon après j’ai sauté la partie gestion des commentaires (il n’y en a presque pas pour l’instant), et je n’ai pas encore abordé la partie base SQL. Du coup il me reste le caching avec un reverse-proxy pour continuer d’optimiser.

Optimiser pour quoi faire ?

Alors c’est très simple : … Lire la suite