Erreur 403 récurrentes sur wordpress, dokuwiki, prestashop, etc...

#1
Bonjour,

Comme la team planethoster n'a pas eu l'idée de prévenir les clients des nouvelles restrictions suite à l'implémentation de modsecurity (une cochonnerie pas possible), certains d'entre vous auront donc le plaisir de voir apparaitre des belles 403 sur certaines pages de leur site (voir le site bloqué au passage).
Il s'agit d'un firewall (modsecurity) qui est trop sensible sur les scripts php qui utilisent soit des pages normées avec des noms pouvant être associé à de la requete sql (from, select, where) soit sur des urls de type /lib/exe/tata.php, lib/ex/tonton.php
Bref pour résoudre le problème :

Sous CPANEL: il faut désactiver dans le panel : cpanel>modsecurity choisir son domaine ou son sous domaine, et désactivé la protection.

Sous NOC: il faut désactiver la règle spécifique à votre erreur. Vous trouverez la procédure décrite par PH-Saber (Procédure ici)

C'est magique tout marche normalement...

@Team planethoster: Peut être prévoir une liste d'exclusion à la disposition du client pour éviter de devoir désactiver ce genre d'outil parce que la configuration est inadaptée et trop restrictive.
 
Dernière édition:

Carlton2001

New Member
#3
Bonjour,

Merci pour ton post marckisscool, j'ai désactivé modsecurity sur mes domaines comme ça mes utilisateurs peuvent de nouveau poster un message contenant le mot "poker" sur les forums sans tomber sur un 403...

En plus j'avais une latence de quelques milisecondes avant d'arriver sur ces mêmes forums. Ce problème là est résolu aussi.
 

PH-Saber

Administrator
Membre du personnel
#4
Bonjour,

Merci pour ton post marckisscool, j'ai désactivé modsecurity sur mes domaines comme ça mes utilisateurs peuvent de nouveau poster un message contenant le mot "poker" sur les forums sans tomber sur un 403...

En plus j'avais une latence de quelques milisecondes avant d'arriver sur ces mêmes forums. Ce problème là est résolu aussi.
Bonjour,

Il ne faut pas désactiver le WAF (mod_security) au complet mais simplement désactiver la règle concernée. Sinon, vous êtes vulnérable au bruteforce cms, sql injection etc..
 
#5
@PH-Saber il y a approximativement 24960 règles dans le WAF, c'est impensable de devoir les vérifier une à une pour voir ce que ce WAF va bloquer ou non sur le site... Perso, je le désactive systématiquement, car les blocages sont très restrictifs.
 
#6
Bonjour Marc,

Sur N0C, il est possible d'ajuster les règles et de voir l'historique détaillé du WAF afin de le personnaliser à son goût: https://blog.planethoster.com/nouveautes-2021-bienvenue-a-la-plateforme-dhebergement-n0c/ .
Bonjour,

Encore faut il être éligible ce qui n'est pas le cas de bon nombre d'hébergement PH, et pour une raison obscure, cette possibilité n'est pas accessible dans cpanel.
En étudiant la question de plus près, lorsque l'on a plusieurs sous domaine avec le waf d'activité, c'est une vrai calamité en terme de gestion. Et pour ma part ayant un profil admin système, j'aime la gestion utile, 50 sous domaines avec autant de règles WAF, j'ai le sentiment de faire un retour en arrière.
Comme je l'ai dit y'avait de l'idée, mais se résoudre à bloquer bêtement un produit parce que les règles ont été posées sans concertation et sans possibilité de customiser, cela se résout directement à le désactiver.
C'est d'autant plus incompréhensible de ne pas avoir testé l'ensemble de la gamme de produits en installation automatique avec le waf de PH, y'a t'il un challenge de ticket prévu pour des problèmes 403?
Et quand on voit le changelog sur NOC, c'est pas très encourageant de le voir déjà en production et non sur un panel beta testeur. On peut pas reprocher la volonté de PH de sécuriser les plateformes, mais vous manquez de process industriel pour assurer une mise en production efficace. ;-)
 
Dernière édition:
#7
@PH-Saber il y a approximativement 24960 règles dans le WAF, c'est impensable de devoir les vérifier une à une pour voir ce que ce WAF va bloquer ou non sur le site... Perso, je le désactive systématiquement, car les blocages sont très restrictifs.[/QUOTE
Bonjour,

Il ne faut pas désactiver le WAF (mod_security) au complet mais simplement désactiver la règle concernée. Sinon, vous êtes vulnérable au bruteforce cms, sql injection etc..
On a 2 solutions, avoir un site accessible et le monitorer et suivre sa mise à jour régulièrement en se privant de waf avec un risque de bruteforce (bien que pas mal de produit ban l'ip après 5 tentatives), où avoir un site hors service, inutilisable et devoir vérifier les règles waf sauf pour ceux qui ne disposent pas de NOC, qui doivent eux se résoudre à clore leur hébergement.
Le waf n'est pas non plus une solution magique, plus de doc accessible sur les produits et plus d'accompagnement permettent aussi d'éviter une mauvaise gestion d'un hébergement et de ce fait un bruteforce.
 
#8
On a 2 solutions, avoir un site accessible et le monitorer et suivre sa mise à jour régulièrement en se privant de waf avec un risque de bruteforce (bien que pas mal de produit ban l'ip après 5 tentatives), où avoir un site hors service, inutilisable et devoir vérifier les règles waf sauf pour ceux qui ne dispose pas de NOC, qui doivent eux se résoudre à clore leur hébergement.
Le waf n'est pas non plus une solution magique, plus de doc accessible sur les produits et plus d'accompagnement permettent aussi d'éviter une mauvaise gestion d'un hébergement et de ce fait un bruteforce.
Sur WP il y a des extensions pour gérer ça, avec des configurations gérables à minima par import. C'est largement plus entendable qu'un WAF avec des tonnes de blocages imbitables...
 

PH-Saber

Administrator
Membre du personnel
#9
Bonjour Marc et Guillaume,

Avant tout, je tiens à spécifier que le WAF n'est pas présent pour vous "mettre des batons dans les roues" mais bien pour aider. Le WAF est une solution premium développée en partenariat avec les fondateurs de mod_security (Atomicorp). Les 20000+ règles sont le résultat d'années d'expérience. Aussi, bien entendu ce n'est pas gratuit et nous en assumons les frais puisque nous tenons à offrir un service de qualité.

Il est à noter que nous avons une entente de correction de faux-positifs dans la semaine (et au plus tard 2 semaines). Effectivement, lorsque vous remarquez un comportement inadéquat du WAF et que vous pensez que c'est un faux-positif, il suffit d'ouvrir un ticket en nous indiquant comment reproduire le tout et nous soumettrons la demande de correctif de faux-positif.

Sur ce même ordre d'idées, nous utilisons les services que nous offrons. Nos FAQ https://kb.planethoster.com et https://kb.n0c.com sont hébergées sur un World (N0C) avec le WAF actif. C'est basé sur Wordpress et il n'y a aucun souci. Nous remarquons que le WAF fait bien son job, beaucoup d'attaques sont bloquées (bruteforce wp-login, xmlrpc), injections de commentaires etc..


@PH-Saber il y a approximativement 24960 règles dans le WAF, c'est impensable de devoir les vérifier une à une pour voir ce que ce WAF va bloquer ou non sur le site... Perso, je le désactive systématiquement, car les blocages sont très restrictifs.
Je vous invite à aller sur mg.n0c.com , section WAF => Historique de protection et vous verrez comment le WAF vous protège exactement. L'url, le path, le contenu de la requête GET/POST etc.. avec bien sûr le ID de la règle. Si vous jugez qu'une règle ne vous convient pas, notez le ID et dirigez-vous sur WAF => Pare-feu App Web (WAF) et personnalisez les règles du domaine en question en désactivant la règle que vous jugez inadéquate selon votre workload.

marckisscool a dit:
(editer regles..) pour une raison obscure, cette possibilité n'est pas accessible dans cpanel.
La raison de cela est que la gestion des plugins sur cPanel est restrictive. N0C étant développé de A à Z, nous pouvons ajuster la plateforme selon vos retours.

marckisscool a dit:
(Et quand on voit le changelog sur NOC, c'est pas très encourageant de le voir déjà en production et non sur un panel beta testeur. On peut pas reprocher la volonté de PH de sécuriser les plateformes, mais vous manquez de process industriel pour assurer une mise en production efficace. ;-)
Nous suivons un développement de type agile et nous misons sur la transparence. Un programme de BugBounty est disponible pour tester si on fait bien notre job: https://bugcrowd.com/planethosterinc . Vous recevrez une compensation si vous trouvez des failles =)

marckisscool a dit:
On a 2 solutions, avoir un site accessible et le monitorer et suivre sa mise à jour régulièrement en se privant de waf avec un risque de bruteforce (bien que pas mal de produit ban l'ip après 5 tentatives), où avoir un site hors service, inutilisable et devoir vérifier les règles waf sauf pour ceux qui ne disposent pas de NOC, qui doivent eux se résoudre à clore leur hébergement.
Sur mg.n0c.com , section WAF => Historique de protection , vous pouvez voir exactement ce que le WAF fait. On fournit tellement d'infos de façon transparente (contenu de la requête, user agent, etc..) que parfois le client peut lui-même comprendre pourquoi le WAF a agit ainsi. Et souvent c'est une erreur du webmaster qui ne suivait pas les normes du web. Une fois qu'il a corrigé son code et testé le tout en regardant l'Historique de protection, all good =)

Deux options:
cPanel -> Contactez le support en fournissant comment reproduire ce que vous jugez être un faux-positif. Si valide, nous soumettrons la demande de correctif et ça sera en place en moins de 2 semaines.

N0C -> Voyez vous-même l'Historique de protection et tentez de comprendre ce qu'il s'est passé en regardant les infos fournies (contenu requête, user agent, id regle etc..). Si votre code est bon et que c'est une règle que vous ne voulez pas (par exemple celle qui juge que le gambling est risqué), notez le ID de la règle sur l'Historique de protection et désactivez cette dernière. Si vous jugez toujours que c'est un faux-positif contactez le support, nous soumettrons la demande de correctif et ça sera en place en moins de 2 semaines.
 
#10
@PH-Saber Merci pour cette réponse complète et je comprends que le WAF puisse être utile.
Malheureusement, dans certains cas, il fait perdre de l'argent, des prospects ou des clients.
J'ai vu le WAF bloquer des commandes sur Prestashop, bloquer des formulaires légitimes sur WP, ou bloquer des requêtes toutes aussi légitimes sur des candidatures d'étudiants sur un site d'une école.
Les règles étant amenées au fur et à mesure, c'est très difficile de les contrôler.
Il y a une différence entre une KB et des sites marchands, ou générant du business.
Je ne pense pas que vous hébergiez la partie vente de PH sur un World + WAF en risquant de perdre des ventes avec des 403 qui tombent sans prévenir...
 

PH-Saber

Administrator
Membre du personnel
#11
Bonjour Guillaume,

Prestashop est reconnu pour être très personnalisable. Souvent ce sont des plugins customs qui peuvent être à risque. N'hésitez pas à contacter le support afin que l'on voit ce qui peut être faire avec les fondateurs de mod_security (Atomicorp) et ainsi perfectionner le WAF ;) Aussi, il serait bien si vous êtes encore sous cPanel d'être déplacé sur N0C. Ça sera plus performant et on pourra voir exactement où sont les blocages grâce à l'Historique de protection (proactivement).
 
#12
Je suis sous N0C :) Je verrai si je trouve un moment pour me pencher sur le sujet, mais aujourd'hui, le gain est très faible à mon sens.
 

PH-Saber

Administrator
Membre du personnel
#13
Je suis sous N0C :) Je verrai si je trouve un moment pour me pencher sur le sujet, mais aujourd'hui, le gain est très faible à mon sens.
Parfait, dans ce cas, vous pouvez voir aussi le Journal d'accès ( https://kb.n0c.com/knowledge-base/journal-dacces/ ) sur mg et ainsi avoir plus de data pour prendre de meilleures décisions ;)

Quand vous aurez le temps, n'hésitez pas à contacter le support, bonne journée à vous ;)
 
#14
bonjour PH-saber,

cPanel -> Contactez le support en fournissant comment reproduire ce que vous jugez être un faux-positif. Si valide, nous soumettrons la demande de correctif et ça sera en place en moins de 2 semaines.
2 semaines, pour modifier une règle, autant s'auto héberger je gagnerais du temps. Si je paye un hébergement 24/24 c'est bien pour que ça marche 24/24.

Les 20000+ règles sont le résultat d'années d'expérience.
Formidable il m'a fallu 15 minutes pour trouver l'origine du problème, association des mots clé shell python exe bin lib dans l'url en POST ou GET pour avoir une 403. ça se retrouve quasiment dans pas mal de cms mais aussi dans des outils comme cakephp etc... On repassera pour l'expérience.

Nous remarquons que le WAF fait bien son job, beaucoup d'attaques sont bloquées (bruteforce wp-login, xmlrpc), injections de commentaires etc..
On voit sur ce forum et je le constate sur wp aussi, des injections de commentaires. Absolument pas de différence avec avant sauf que l'on a en plus des 403 qui pour le coup posent problème.

La raison de cela est que la gestion des plugins sur cPanel est restrictive. N0C étant développé de A à Z, nous pouvons ajuster la plateforme selon vos retours.
Si la gestion est aussi poussée que sous cpanel je veux bien y passer, lors de ma dernière demande je n'étais pas éligible par rapport à mon utilisation trop experte du produit.

Nous suivons un développement de type agile et nous misons sur la transparence. Un programme de BugBounty est disponible pour tester si on fait bien notre job: https://bugcrowd.com/planethosterinc . Vous recevrez une compensation si vous trouvez des failles
agile est une méthode de travail entre équipe, principalement dans la partie développement, là on est en production et on doit régler des problèmes de base qui n'ont même pas été vérifié durant la phase de recette.
Tout comme le faite de faire une maintenance (planifiée où?) à l'arrache en pleine journée sans en aviser les clients, jamais vu ça encore(voir mon screen).


Bref le waf pour des noobs de l'hébergement et des sites statiques, pourquoi pas, mais comme j'en ai eu l'amère expérience avec votre filtre de spam qui suspend les comptes world, c'est encore une implémentation fait à l'arrache sans un brin de réflexion. Surtout que le principe de cloudlinux os c'est de cloisonner les ressources et les utilisateurs.

Prestashop est reconnu pour être très personnalisable. Souvent ce sont des plugins customs qui peuvent être à risque.
Par expérience c'est plus un problème humain, ou pas de suivi des mises à jour, ou un plateau de dev pas pro. L'évolution de prestashop ne permet pas à un débutant de pouvoir le toucher et encore moins de bidouiller un plugin. Depuis la 1.6, ça devient difficile.

Pour conclure, une fausse bonne idée pour qui veut vraiment exploiter son hébergement, ayant un suivi régulier, si je constate une impossibilité à empêcher du brutusforce je l'activerais peut être le temps de trouver une solution technique pour m'en passer.
 

Fichiers joints

PH-Saber

Administrator
Membre du personnel
#15
Bonjour Marc,

2 semaines, pour modifier une règle, autant s'auto héberger je gagnerais du temps. Si je paye un hébergement 24/24 c'est bien pour que ça marche 24/24.
Une modification de règle nécessite que l'on teste bien le tout. Max 2 semaines c'est pour que l'ensemble de l'infra possède la mise à jour de la règle.

Formidable il m'a fallu 15 minutes pour trouver l'origine du problème, association des mots clé shell python exe bin lib dans l'url en POST ou GET pour avoir une 403. ça se retrouve quasiment dans pas mal de cms mais aussi dans des outils comme cakephp etc... On repassera pour l'expérience.
Je crois que vous vous basez sur le GUI de cPanel qui n'affiche pratiquement pas d'infos. Sur N0C, l'Historique de protection, vous voyez en LIVE ce que ce le WAF fait ainsi que le ID de la règle qui fait le job. Tel qu'expliqué sur l'autre post, il suffit de noter le ID et de désactiver la règle exacte qui selon vous ne convient pas à votre workload. Ça prend moins de 30 secondes.

On voit sur ce forum et je le constate sur wp aussi, des injections de commentaires. Absolument pas de différence avec avant sauf que l'on a en plus des 403 qui pour le coup posent problème.
Notre forum est encore sur une infra legacy.

agile est une méthode de travail entre équipe, principalement dans la partie développement, là on est en production et on doit régler des problèmes de base qui n'ont même pas été vérifié durant la phase de recette.
Tout comme le faite de faire une maintenance (planifiée où?) à l'arrache en pleine journée sans en aviser les clients, jamais vu ça encore(voir mon screen).
La screenshot concerne une mise à jour de notre portail client (my) qui n'affecte AUCUNEMENT le service d'hébergement fournit à l'hébergé.

Je vous inviterais quand vous aurez le temps de créer un compte sur N0C depuis votre espace client (Mes Services -> The World). Ça fait 3 ans qu'on travaille dessus et ce est uniquement depuis le 24 août dernier que c'est officiellement en production. Vous serez sur une nouvelle infra à Lausanne, DC Tier4, réseau 100G etc..

Si vous avez des commentaires constructifs afin que l'on améliore nos solutions n'hésitez pas.
 
#16
Une modification de règle nécessite que l'on teste bien le tout. Max 2 semaines c'est pour que l'ensemble de l'infra possède la mise à jour de la règle.
D'ou le faite de permettre au client de faire des exclusions, remarque de mon premier message, pas certains que les clients utilisent les mêmes produits et de la même façon que moi.

Je crois que vous vous basez sur le GUI de cPanel qui n'affiche pratiquement pas d'infos. Sur N0C, l'Historique de protection, vous voyez en LIVE ce que ce le WAF fait ainsi que le ID de la règle qui fait le job. Tel qu'expliqué sur l'autre post, il suffit de noter le ID et de désactiver la règle exacte qui selon vous ne convient pas à votre workload. Ça prend moins de 30 secondes.
Ma réponse faisait référence à votre affirmation sur les années d'expériences, je n'ai aucunement besoin de NOC pour savoir que j'ai un problème sur le WAF:
Les 20000+ règles sont le résultat d'années d'expérience.
Notre forum est encore sur une infra legacy.
Au final cela fonctionne plutot bien alors sans waf.

La screenshot concerne une mise à jour de notre portail client (my) qui n'affecte AUCUNEMENT le service d'hébergement fournit à l'hébergé.
Parce que vous pensez que je suis tombé sur ce message en faisant du macramé? Je gère ma db, mes mails, mes fichiers, etc comment?

Je vous inviterais quand vous aurez le temps de créer un compte sur N0C depuis votre espace client (Mes Services -> The World). Ça fait 3 ans qu'on travaille dessus et ce est uniquement depuis le 24 août dernier que c'est officiellement en production. Vous serez sur une nouvelle infra à Lausanne, DC Tier4, réseau 100G etc..

Si vous avez des commentaires constructifs afin que l'on améliore nos solutions n'hésitez pas.
Je suis ça de très près déjà, j'avais fait des précédentes démarches pour migrer, je viens de voir les relance du support sur ce sujet, je vais voir la faisabilité sur un petit hébergement afin de me faire la main dessus (je pense que ça concerne aussi la migration?). J'essayerais de faire un retour.

Encore merci de vos réponses, même si mes réponses peuvent paraître sèches, en tant que client je suis quand même content d'avoir une réponse de la team et le support est très réactif dans l'ensemble, je tenais à le souligner ;-) .
 
#17
@PHP-Saber, j'ai, dans l'historique du WAP, 3324 pages de 50 items, sans possibilité de trier.
Je me vois mal faire le tri là dedans, pour voir si ce sont de vrais alertes qui posent des vrais soucis pour mes internautes lors d'un paiement ou autre.
1631263477567.png

aucune action ou filtre possible ici :
1631263595467.png

Peut-être avez vous une suggestion ?
 
#18
@PH-Saber : après quelques tests WAF est incompatible avec:
os ticket (user)
smf (administration)
wordpress (admin et user)
prestashop (admin)
dokuwiki (admin)
joomla (admin)
drupal (admin)
piwigo (admin)
mediawiki (admin)

A noter les grosses lenteurs des cages pour consulter les logs apaches ou les logs d'erreurs sur cpanel, je sais pas si sur NOC les clients ont les mêmes soucis, si je passe par un terminal zéro problème.

@GuillaumeAA est ce que la log complète est disponible dans un fichier sur l'hébergement, parce que avec un petit script python vite fait pour faire une synthèse ça peut être intéressant à condition d'avoir le fichier source de ces logs?
 
#19
@GuillaumeAA est ce que la log complète est disponible dans un fichier sur l'hébergement, parce que avec un petit script python vite fait pour faire une synthèse ça peut être intéressant à condition d'avoir le fichier source de ces logs?
et non... sinon même Excel aurait aidé déjà
 

PH-Saber

Administrator
Membre du personnel
#20
Hello Guillaume et Marc,

@PHP-Saber, j'ai, dans l'historique du WAP, 3324 pages de 50 items, sans possibilité de trier.
Je me vois mal faire le tri là dedans, pour voir si ce sont de vrais alertes qui posent des vrais soucis pour mes internautes lors d'un paiement ou autre.
Il faut savoir que les bots malveillants font des requêtes aléatoirement. Parfois, à titre d'exemple, vous hébergez un Joomla et les bots tentent de bruteforcer le wp-login... Pour faire un tri, vous pouvez utiliser le Journal d'accès: https://kb.n0c.com/knowledge-base/journal-dacces/ . Nous ajouterons prochainement un filtre similaire sur la section WAF aussi.


@PH-Saber : après quelques tests WAF est incompatible avec:
os ticket (user)
smf (administration)
wordpress (admin et user)
prestashop (admin)
dokuwiki (admin)
joomla (admin)
drupal (admin)
piwigo (admin)
mediawiki (admin)

A noter les grosses lenteurs des cages pour consulter les logs apaches ou les logs d'erreurs sur cpanel, je sais pas si sur NOC les clients ont les mêmes soucis, si je passe par un terminal zéro problème.
J'aimerais bien savoir comment vous jugez que c'est incompatible. Je peux témoigner personnellement que WordPress et Joomla sont 100% compatibles. Et de ce que je vois sur les logs de l'infra, ces autres CMS ne montrent pas de soucis également.. Tel qu'expliqué sur un autre post ci-dessus, https://kb.planethoster.com et https://kb.n0c.com qui sont du WP, sont hébergés sur un World avec le WAF actif et pas de soucis sur admin, user, public etc.. À noter néanmoins, que la job du WAF est de protéger l'accès public pour éviter par exemple d'escalader des privilèges et d'avoir un accès admin. Normalement, si authentifié en tant qu'admin déjà, le WAF n'est pas supposé faire quoi que ce soit...


@GuillaumeAA est ce que la log complète est disponible dans un fichier sur l'hébergement, parce que avec un petit script python vite fait pour faire une synthèse ça peut être intéressant à condition d'avoir le fichier source de ces logs?
Plutôt que de devoir filter les logs à l'ancienne avec un "grep" ou un script custom.. sur des GB de data, le Journal d'accès ( https://kb.n0c.com/knowledge-base/journal-dacces/ ) permet de filtrer directement avec des regex elastic. Voir screenshot.

et non... sinon même Excel aurait aidé déjà
Pas sûr que Excel peut tenir plusieurs GB de data ;)

--

Cette discussion s'en va nulle part. Merci d'ouvrir un ticket (en mentionnant ce thread) et nous fournir des informations précises sur comment reproduire le tout afin que l'on puisse corriger la situation si il y a lieu.
 

Fichiers joints

solsol69

New Member
#21
Bonjour a tous
Merci a vous @marckisscool et a tous ceux qui ont réagi sur ce sujet.
Travaillant sur PrestaShop j'ai eu des erreurs 403 du jour au lendemain sans raison apparente.
ca faisait quelques jours que je m'arrachais les cheveux pour comprendre d'où venait le problème j'étais a 2 doigts de tous formater et je suis tombé par hasard sur votre post.
Pourtant j'avais contacter planethoster par telephone en leur signalant des erreurs 403 pour avoir peut être une piste mais il ne m'ont pas parlé de ce fameux parefeu.
Dans l'Ideal une notification par mail des actions de ce parfeu aurait été je pense bien utile.
PS : J'ai résolu mon soucis en repérant le numéro de l'" ID RÈGLE " dans l'historique du pare feu et j''ai ensuite désactivé cette règle dans les paramétrages du parefeu.
 

PH-Marc-André.B.

Administrator
Membre du personnel
#22
Bonjour,

Des notifications par email pour le N0C représente très certainement une bonne suggestion!

Serait-ce possible de nous en faire part sur le portail suivant qui est prévu?

https://features.planethoster.com


C'est là que notre équipe au développement traite les suggestions pour améliorer le Panneau N0C.
 
#23
Bonjour,

Je rajoute l'incompatibilité avec les forums en php de simplemachine forum toutes branches, on ne peut ni modifier ni poster sur les forums à partir du moment ou le titre contient ".." ou "." ou "..." ou la particule "ex" ou des espaces dans l'url " " bref, la suppression de la protection règle le problème.

Je rajoute l'incompatibilité avec le plugin strip sur prestashop (probleme de retour avec les tokens pour la validation côté prestashop) + google console search (problème d'indexage des pages, nombreuses pages 403) + le suivi des visiteurs dans la partie admin pour le tracking.

Bon courage
 

PH-Marc-André.B.

Administrator
Membre du personnel
#24
Bonjour,

Je tiens à vous rappeler que toute l'équipe au soutien technique est disponible pour vous aider à analyser les problèmes provoqués par la protection WAF.

Comme PH-Saber l'a indiqué déjà nous offrons la possibilité de corriger les faux positifs s'il y avait lieu car la protection WAF que nous offrons est couverte par une entente de correction pour ces soucis là.
 
#25
Bonjour,

Je tiens à vous rappeler que toute l'équipe au soutien technique est disponible pour vous aider à analyser les problèmes provoqués par la protection WAF.

Comme PH-Saber l'a indiqué déjà nous offrons la possibilité de corriger les faux positifs s'il y avait lieu car la protection WAF que nous offrons est couverte par une entente de correction pour ces soucis là.
Bonjour,

Malheureusement dans les faits il n'y a aucune analyse chez PH, dans le genre démerdez vous, j'avais encore jamais eu, voici la réponse du support pour faire corriger une régle waf qui bloque les scripts des forums smf:
Merci de contacter PlanetHoster.
Nous recommandons de basculer vers le panneau de gestion N0C.
Il est possible de planifier une migration sans frais.
Vous pourrez gérer les règles du WAF.
C'est un grand avantage par rapport a cPanel.
N0C est une solution propriétaire de PlanetHoster.
 
Haut