Nin­ja Firewall

Un pare-feu léger pour votre WordPress

Autant vous l’avouer tout de suite, je n’ai jamais été très chaud pour ins­tal­ler un pare-feu (fire­wall) sur mes sites, trop angois­sé à me retrou­ver blo­qué à l’extérieur ou plan­ter le site sans pou­voir le récu­pé­rer. Et puis je disais la même chose des plu­gins de cache et fina­le­ment j’en ai ins­tal­lé un. Et le plu­gin de pro­tec­tion du fichier wp-login.php n’arrêtait pas de me lan­cer des mes­sages d’alerte comme quoi le site subis­sait une attaque. J’ai fini par me dire que je ne ris­quais pas grand chose à faire un test.

Nin­ja­Fi­re­wall n’est pas le plus connu des pare-feu Word­Press – le plus popu­laire étant pro­ba­ble­ment Word­fence – mais en tom­bant sur un com­pa­ra­tif ou je ne sais quoi, j’ai été séduit par la mise en avant du fait qu’il n’alourdissait par Word­Press lui-même.

Nin­ja­Fi­re­wall est en effet un pare-feu géné­rique conçu pour pro­té­ger tout script PHP. Il va donc s’interfacer entre les visi­teurs et le site lui-même, rédui­sant les effets néga­tifs des attaques contre votre Word­Press puisque les méchants n’arrivent même pas aux fichiers Word­Press. Enfin, c’est ce que j’ai cru comprendre…

Il est un peu dif­fi­cile de lis­ter toutes les pos­si­bi­li­tés de ce genre de plu­gin aus­si vais-je com­men­ter les options.

Ins­tal­la­tion et lancement

L’installation est assez stres­sante. J’ai conser­vé les réglages par défaut dans un pre­mier temps.

Pour la der­nière étape, le plu­gin pro­pose la créa­tion d’un fichier php.ini qui lan­ce­ra le script lui-même. En cas d’échec, le plu­gin ne pour­ra pas fonctionner.

ninja-firewall-installation04

Il se trouve que de nom­breux héber­geurs ne per­mettent pas l’utilisation de plu­sieurs php.ini sur leur ins­tal­la­tion ( et il y en a un qui tourne déjà par défaut ). Il est alors conseillé de pas­ser le réglage à .user.ini. C’est d’ailleurs le réglage qui fonc­tionne chez mon héber­geur et chez OVH.

Vous allez obli­ga­toi­re­ment voir ce mes­sage qui annonce que le pare-feu ne fonc­tionne pas. Il faut en effet que le fichier ini défi­nit pré­cé­dem­ment soit pris en charge par votre héber­ge­ment. Et cela ne se fait qu’en relan­çant PHP sur votre ser­veur. Cer­tains héber­geurs per­mettent à leurs uti­li­sa­teurs de le faire manuel­le­ment sinon il vous fau­dra attendre cinq minutes pour que ce soit pris en compte (c’est bien le cas sur OVH).

ninja-firewall-installation05

Au moment de l’installation, le plu­gin génère un mail qui vous liste toutes les adresses utiles en cas de pro­blème. Pratique.

ninja-firewall-installation06

Options

Vous remar­que­rez que vous pou­vez per­son­na­li­ser un mes­sage qui s’affichera pour un visi­teur sus­pect mais néan­moins blo­qué qui est invi­té à vous contac­ter avec un numé­ro de sui­vi. Le numé­ro d’incident per­met de cibler quelle règle du plu­gin est en cause et vous pou­vez la désac­ti­ver éven­tuel­le­ment – cf. plus loin.

ninja-firewall-options

Réglages

J’ai tout lais­sé en réglages par défaut. SAUF la règle sur l’API XML-RCP que j’ai blo­quée – cible de nombres d’attaques. Si vous n’en avez pas l’usage – vous n’envoyez pas vos billets par mail ou avec un autre logi­ciel externe, je vous conseille de la pro­té­ger. Atten­tion : la fonc­tion peut être utile pour cer­taine fonc­tion­na­li­tés Jet­pack.

Pro­tec­tion de fichier

Vous pré­vient si un script PHP a été ins­tal­lé et utilisé.

ninja-firewall-guard

Créa­tion d’une sauvegarde

Le plu­gin crée une sau­ve­garde de TOUS vos fichiers pour véri­fier si ils sont modi­fiés sans votre consen­te­ment. C’est une tâche très gour­mande à n’utiliser que si votre héber­ge­ment est cos­taud. J’ai pré­fé­ré m’en passer.

ninja-firewall-check

Alertes

Poli­tique d’alerte par email pour chaque cas listé.

ninja-firewall-notif

Pro­tec­tion du login et du XMLRPC

C’est la cible pré­fé­rée des pirates qui cherchent à cra­cker vos iden­ti­fiants d’administrateurs. Nin­ja­Fi­re­wall bloque l’accès aux fichiers en ques­tion en cas d’attaque – vous pré­ci­sez les condi­tions – et les pro­tège par un nou­vel iden­ti­fiant et mot de passe qu’il vous fau­dra entrer en cas de ten­ta­tive de connexion de votre part durant une attaque. Notez-les donc soi­gneu­se­ment puisqu’ils peuvent/doivent être dif­fé­rents de vos login de connexion à l’administration !
Atten­tion : la fonc­tion XMLRPC peut être utile pour cer­taine fonc­tion­na­li­tés Jet­pack.

ninja-firewall-login

ATTENTION : le plu­gin sou­ligne bien le fait que cette pro­tec­tion ne sera pas désac­ti­vée si vous désac­ti­vez le plu­gin. Il fau­dra pas­ser par cette option pour sup­pri­mer ce réglage avant de désac­ti­ver le plu­gin ! Depuis sa der­nière ver­sion, la pro­tec­tion est désac­ti­vée auto­ma­ti­que­ment si vous désac­ti­vez le plugin.

Mise à jour de la ver­sion 3.3.0 : cette fonc­tion­na­li­té peut être rem­pla­cé par un capt­cha, bien pra­tique pour ceux qui oublient leurs mots de passe.

Log des attaques

Le plu­gin liste les attaques que vous subis­sez et sup­prime régu­liè­re­ment les logs.

ninja-firewall-log

Sur­veillance en direct

Vous pou­vez suivre en direct l’activité blo­quée sur le site.

ninja-firewall-live-log

Réglages et mises à jour

Nin­ja­Fi­re­wall a une liste de réglages qu’il vous pro­pose de mettre à jour régu­liè­re­ment sui­vant l’actualité des failles WordPress.

ninja-firewall-update

ninja-firewall-rules

Log en accueil et en résumé

ninja-firewall-accueil

ninja-firewall-stats

Dés­ins­tal­la­tion

Le plu­gin ne peut pas être désac­ti­vé en sup­pri­mant juste son réper­toire par exemple puisque le fichier ini qui le lance existe tou­jours. Il faut donc le désactiver/supprimer à par­tir de l’administration.
En cas de pro­blème, refe­rez-vous à la docu­men­ta­tion offi­cielle : https://​nin​tech​net​.com/​n​i​n​j​a​f​i​r​e​w​a​l​l​/​w​p​-​e​d​i​t​i​o​n​/​h​e​lp/

Consé­quence inat­ten­due et conclusion

J’ai tou­jours eu une admi­nis­tra­tion un peu fai­néante et j’ai tou­jours mis cela sur le compte du nombre assez impor­tant de plu­gins que j’utilise côté admi­nis­tra­tion. Après ins­tal­la­tion de Nin­ja­Fi­re­wall, j’ai consta­té une nette amé­lio­ra­tion de ce côté-là. Coïn­ci­dence ou réalité ?

J’aime beau­coup la phi­lo­so­phie du plu­gin qui cherche à allé­ger votre ins­tal­la­tion Word­Press des attaques exté­rieures mais, en contre­par­tie, la ges­tion de pro­blème ou la dés­ins­tal­la­tion néces­site un peu de connais­sances et de doig­té. Mais il me semble que c’est le cas pour la plu­part des plu­gins de ce type.

Il existe une ver­sion payante – abon­ne­ment annuel – du plu­gin qui per­met une ges­tion plus fine et une meilleure ges­tion des attaques.


site WP du plu­gin : https://​word​press​.org/​p​l​u​g​i​n​s​/​n​i​n​j​a​f​i​r​e​w​a​ll/ ‑ ver­sion tes­tée : 1.4

Par­ta­gez

Si vous avez trou­vé une faute d’orthographe, infor­mez-nous en sélec­tion­nant le texte en ques­tion et en appuyant sur Ctrl + Entrée s’il vous plaît,.

4 réponses sur “ Nin­ja Firewall ”
  1. Bon­soir,
    jamais mis de plu­gin de sécu­ri­té, je trouve que c’est un truc à la mode, déjà si on main­tient à jour son site, on dimi­nue les risques, puis quelques codes dans le fichier .htac­cess pour pro­té­ger, ne pas uti­li­ser l“identifiant Admin, en créé un autre, créer aus­si un autre compte niveau Edi­teur, pour écrire ses articles et ses pages.
    Désac­ti­ver l’éditeur de thème, enfin quelques trucs, et votre site sera qua­si­ment sûr, sans plu­gin de sécurité.

  2. Mal­heu­reu­se­ment, mettre à jour ne signi­fie pas une pro­tec­tion assu­rée (par exemple une exten­sion aban­don­née sur laquelle on trouve une faille). L’extension de sécu­ri­té per­met d’avertir le pro­prié­taire quand il se passe des choses sus­pectes en cas de faille. Et elle a le grand avan­tage à mes yeux d’alléger le site en limi­tant les requêtes malveillantes.
    Avec un WP tout nu, je serais d’accord avec vous mais dès que l’on ins­talle des choses exté­rieures, il faut se méfier. Sans comp­ter qu’un nombre impor­tants de pira­tages ne sont pas dûs aux com­po­sants du site (héber­geurs, ordi local…). Je vois trop de gens pira­tés sur le forum pour ne pas conseiller une exten­sion de sécu­ri­té puisqu’en géné­ral, ce sont jus­te­ment les gens qui ne font pas atten­tion à la main­te­nance qui se font avoir. Il vaut mieux pré­ve­nir que guérir.

  3. Bon­jour,
    Excu­sez-moi, mais une exten­sion aban­don­née, n’est pas une exten­sion à jour, c’est bien ce que je dis, il faut main­te­nir à jour son site à 100%, là nous sommes en 2017, je n’ai que des plu­gins mis à jour en 2017, je ne garde pas les plu­gins donc la der­nière mise à jour date de 2016.

    Je vois aus­si le nombre de per­sonnes sur le forum qui ont leurs sites de pira­té, mais par­don, vous le dites, ils ne font pas atten­tion à la main­te­nance de leurs sites, donc cela est bien d’une négli­gence de leur part.
    Sur le forum, j’ai vu aus­si des mes­sages de per­sonnes qui avaient “cas­sé” leurs sites avec les plu­gins de sécu­ri­té, sou­vent quand ils modi­fient les pré­fixes des tables, ou le lien pour se connec­ter, etc.

    Je n’ai pas dit que la mise à jour garan­tis­sait la pro­tec­tion, j’ai dit que cela dimi­nuer les risques, n’est-ce pas ,

    Si je com­prends le plu­gin de sécu­ri­té est là pour faire le “bou­lot ” du webmaster.
    Oui mieux vaut pré­ve­nir que gué­rir, d’où ma pru­dence des mises à jour.
    Les failles de sécu­ri­té peuvent être pré­sentes aus­si dans un plu­gin de sécurité.
    Le risque 0 n’existe pas, l’hébergeur pira­té, virus sur son ordi­na­teur, etc..

    Je com­prends votre point de vue, je crains juste que les gens au lieu de prendre les bonnes habi­tudes de main­te­nance d’un site, se reposent sur un plu­gin de sécurité.
    Avant ces plu­gins sur le forum, vous deviez dire, mettre à jour votre site, non ?
    Main­te­nant vous dites, ins­tal­ler un plu­gin de sécu­ri­té, n’est-ce pas ?

    Com­pre­nez-moi, je ne suis pas contre le plu­gin de sécu­ri­té, mais celui-ci doit être vu en com­plé­ment et non de repla­ce­ment du rôle du web­mas­ter, on peut conseiller l’installation d’un plu­gin de sécu­ri­té, mais on doit rap­pe­ler, à l’occasion, l’important des mises à jour, de ne pas gar­der des plu­gins “obso­lètes”, ne pas juste les désac­ti­ver, mais les sup­pri­mer et mettre les codes néces­saires dans .htac­cess.

    Bien à vous

  4. Bon, je ne conteste pas votre point de vue mais, comme je l’ai dit, une exten­sion de sécu­ri­té peut allé­ger la charge du ser­veur et sim­pli­fie la ges­tion de la sécu­ri­té. Et ceci n’est pas un billet sur la sécu­ri­té en géné­ral mais sur cette exten­sion en par­ti­cu­lier. La sécu­ri­té en géné­ral aura droit à son petit billet, j’y songe.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Notifiez-moi les commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.

Aucun support n’est fourni pour les extensions testées. Vous pouvez utiliser Markdown pour les commentaires.