Bloquer des IP par .htaccess ou laisser faire le pare-feu ?

[RobertG]

Bonjour,

Sur le pare-feu de serveurs World chez PlanetHoster, je constate de très nombreux blocages de tentatives d'ouvertures de pages inexistantes par des robots ou individus indésirables, avec la même IP cherchant à accéder à toute une série d'adresses (WP en général), et bien sûr toute une série d'IP en cause.

Je me demande qui du pare-feu ou d'instructions dans le .htaccess intercepte ces adresses en premier, et si donc ajouter les IP en question dans le .htaccess pour les bloquer éviterait ensuite au pare-feu d'analyser ces tentatives d'accès.

Merci de vos conseils

[Fred2FR3]

Salut Robert,
Il faut comprendre le cheminement et dans ta question, si le serveur bloque avant ton site, c'est bon

[RobertG]

Bonsoir Fred,

C'est bien la question : comment savoir lequel est le premier à voir passer l'adresse.
Je pourrais récupérer quelques adresses, puis voir si elles apparaissent encore dans le pare-feu, mais rien ne permet de savoir à quel rythme ces IP reviendront.

[pjuignet]

Bonsoir Robert,

Selon moi, c'est le pare-feu de PlanetHoster qui fait le travail en premier. J'ai regardé leurs logs il y a quelque temps et ils indiquaient des blocages que mon .htaccess n'aurait pas pu faire. Du coup, je l'ai renforcé, mais je pense que le .htaccess vient en second. Quant au pare-feu de CloudFlare en version gratuite, il est très insuffisant.

[RobertG]

Bonjour,

En attendant d'autres avis (j'ai aussi posé la question sur le forum PH), je viens de bloquer dans le .htaccess plusieurs IP récupérées dans le pare-feu.
J'essaierai ensuite de surveiller si elles reviennent ou non dans le pare-feu.
Le site étant protégé des robots par CG Secure, je suis étonné d'une erreur 403 en warning dans le pare-feu sur l'adresse

/plugins/system/cgsecure/htaccess.php?e=21&t=e&m=adminer&sec=xxxxxxxx

PS : aïe, la série ajoutée dans la partie Joomla! du .htaccess est supprimée lorsque CG Secure régénère son fichier .htaccess
Il faut donc éviter d'utiliser le bouton "Régénérer le .htaccess" et ne faire qu'enregistrer pour ne pas remplacer cette partie par le contenu standard, si on a personnalisé la partie Joomla! de base.

[pmleconte]

Bonjour,

L'erreur 403 est normale, elle est générée par CG Secure. Dans l'exemple donné, un message a été intercepté qui contenait le mot interdit 'adminer'.

Cependant, que le message soit dans le pare-feu me semble bizarre car, d'après mes recherches, le pare-feu est avant l'accès au .htaccess et il ne devrait pas voir ce message.

Lorsque l'on utilise le bouton "Regénerer le HTAccess', CG Secure regénère le htaccess avec les informations dont il dispose. Donc, il fait ce qu'on lui demande.

Si tu veux ajouter des lignes au fichier .htaccess généré par CG Secure, dans l'onglet HTAccess, il faut l'ajouter dans l'édit 'Code spécifique du htaccess'. Ce code sera intégré au nouveau fichier lorsque tu cliqueras sur "Regénérer".

Bon dimanche,

Pascal

[RobertG]

Bonjour et merci Pascal,

J'ai en effet vu cette adresse dans le .htaccess

Pour ce qui est de la régénération du .htaccess, je pensais que ce n'était qu'un forçage du remplacement de toute la partie CG Secure, en conservant le reste, mais plusieurs essais ont fait disparaître la série de "deny" ajoutée dans la partie Joomla! (après les commentaires de "@package Joomla")

Dans cette partie 'Code spécifique du htaccess' ce sont les lignes type "deny from" suivi de l'IP qu'il faut ajouter ?
Je viens d'essayer, et non seulement mon ajout dans le .htaccess a été supprimé, mais le code ajouté dans CG Secure n'a pas été intégré au nouveau .htaccess après régénération. Il est cependant toujours présent dans le paramétrage de CG Secure.

Bon dimanche !

[RobertG]

J'ai interrogé PlanetHoster et eu une réponse très rapide, comme d'habitude, dont je donne l'essentiel

Si vous parlez du Parefeu Applicatif (le WAF) cela est en temps réel, dans la plupart des cas ça va être après les instructions dans le .htaccess.

Une des exceptions est que certaines IP sont en liste noire chez Atomicorp, le service que l'on utilise pour le pare-feu, donc va être bloquée avant même de faire une requête.

Donc sauf IP déjà bloquées par la liste noire, le .htaccess passe avant le WAF de PlanetHoster.

[ManuelVoileux]

Bonjour,
j'ai ajouté au htaccess Joomla, les instructions 8G firewall + celles pour bloquer les AI crawler, de Perishable press, + admin exile. Chaque jour, une dizaine de visites automatiques et provoquant une erreur 404 arrivent à passer, contre des centaines avant.

[pmleconte]

Bonjour Robert,

Merci d'avoir signalé ces anomalies.

Je viens de mettre en ligne la version 3.3.1 de CG Secure.

Elle corrige la prise en compte du code spécifique et j'ai ajouté la possibilité de saisir tes propres IP : c'est sur la page Logs (qu'il faudra que je renomme un jour....) où un bouton +Nouveau affiche une page sur laquelle tu peux saisir ta nouvelle IP ainsi que vérifier si elle est déjà répertoriée dans AbuseIPDB.

Remarque : après avoir saisi une nouvelle IP, ne pas oublier de regénérer le fichier htaccess (bouton sur la page config. CG Secure) pour y inclure tes nouvelles IP.

Merci de me dire si cela solutionne tes problèmes.

Bonne journée,

Pascal

[pmleconte]

Bonjour,
j'ai ajouté au htaccess Joomla, les instructions 8G firewall + celles pour bloquer les AI crawler, de Perishable press, + admin exile. Chaque jour, une dizaine de visites automatiques et provoquant une erreur 404 arrivent à passer, contre des centaines avant.

Bonjour Manuel,

Attention le firewall 8G est un peu trop violent et a tendance à bloquer systématiquement l'accès, par exemple, au fichier robots.txt.

Comme écrit dans leur doc, il faut vérifier si tout fonctionne correctement après sa mise en place.

Au niveau de l'AI, certains robots ont été supprimés dans la version du mois d'avril. Personnellement, je les ai remis.

Pascal

[RobertG]

Bonjour et merci à vous deux,

Je testerai cette nouvelle version de CG Secure dès que possible.

Pour avoir vérifié ce matin l'historique du pare-feu PlanetHoster sur quelques sites, j'ai l'impression qu'on est devant un trou sans fin, avec l'apparition de nombreuses nouvelles IP chaque jour. On en bloque une et parfois on a l'impression que c'est toute une plage qu'utilisent les indésirables.

L'avantage de PlanetHoster est qu'on connaît ces IP, alors que d'autres hébergeurs ne permettent pas d'y avoir accès. Mais les récupérer pour les mettre dans le .htaccess de multiples sites ma paraît maintenant utopique...

[RobertG]

Je viens de tester après avoir eu un gros incident : Akeeba backup sur le site à tester ne déclenchait plus la sauvegarde, pas même l'assistant de configuration. Puis je me suis retrouvé sans CSS dans l'administration. Il m'a fallu supprimer le .htaccess dans l'administration (sans effet) puis à la racine, pour accéder correctement à cette administration.

J'ai fait la mise à jour de CG Secure et recréé un .htaccess standard puis je l'ai régénéré depuis CG Secure. Tout va bien, et j'ajoute dans ce .htaccess mes anciennes lignes de blocage, je régénère, elles disparaissent.
Comment cette régénération se fait-elle ? Ne remplaces-tu pas seulement la partie "CG Secure" pour conserver les personnalisations de l'ancien contenu ?

[pmleconte]

Au niveau de la re-génération, je prends le fichier .htaccess fourni par Joomla et j'y fusionne mes définitions + les adresses IP + le code de personnalisation éventuel défini dans le composant.

Pascal

[RobertG]

L'inconvénient est que si on a ajouté dans le .htaccess de base des instructions comme une redirection www/non-www par exemple (ou l'inverse), ces modifications sont perdues. C'est ce qui m'est arrivé sur plusieurs sites.