Accueil › Publications taguées Wordpress

Wordpress

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

Posté le de — Aucun commentaire ↓
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

Posté le de — 2 commentaires ↓
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

Posté le de — Aucun commentaire ↓
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à !

Posté le de — Aucun commentaire ↓
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