- Nom de domaine : daspower.fr - OVH CLoud - Performance 1
Sur une station meteo, qui appel un script PHP chaque minute, depuis le 31 octobre je n'ai plus de données qui remontent. la requete est faite en HTTP uniquement ( pas de https), je nai pas la possibilité de changer. J'ai connecté la station a un point d'acces wifi sur mon pc et jai lancé wireshark, et j'ai une reponse http 302, je me suis dit que c'est la redirection vers HTTPS qui lui pose problème.
Jai créé un multisite weather.daspower.fr, qui pointe sur un dossier www2 qui ne contient rien hormis le script PHP, ( pas de htaccess ou quoi que ce soit ) Le script php n'effectue aucune redirection, c'est du simple traitement et stockage de donnée.
J'ai constaté que depuis mon pc l'acces se faisait ne ipv6 et la station meteo etait en ipv4, jai donc retiré le AAAA de la zone dns, flushdns, et jai refais un curl, et ca passe correctement en ipv4 depuis le PC.
Si je compare les deux requete, a part le nombre de parametre get de l'url et le user agent absent sur la requette de la station meteo, sinon jai aucune difference.
par contre dans la reponse il veut me rediriger vers la meme url avec seulement le premier parametre… etrange. si j'affiche la variable $_GET dans mon script, jai bien tout si je l'appel via navigateur, mais je ne sais pas si il m'a redirigé
et j'ai obtenu la reponse 302 ! OVH redirige les requetes sans user agent. y a t'il un moyen de les accepter sans redirection, sans le OVH_CHALLENGE_COOKIE ? :
regardez dans votre hébergement si le firewall est activé, si la réponse est non et que OVH a fait un changement je dirais que vous êtes bloqué si vous ne pouvez pas faire de requêtes avec user-agent custom.
le firewall est bien desactivé, je ne suis pas seul dans ce cas, ca va etre plutot problématique si ovh ne fait rien. sur le ticket que j'ai fais ils persistent a me dire que ca vient de mon code php
théoriquement une requêtes HTTP devrait avoir un UA, donc à qui la faute, aucune idée, mais cela me semble pas spécialement anormale de refuser des requêtes sans UA si derrière cette technique est utilisé pour faire des attaques.
hébergement si le firewall est activé, si la réponse est non et que OVH a fait un changement je dirais
Bonjour Janus57, Vous sous entendez que nos problèmes viennent d'un firewall désactivé suite à une mise à jour d'OVH? cela rejoint le topic https://community.ovhcloud.com/t/3166 Donc comment résoudre ce problème ? cordialement
Après test, avec Firewall activé ou désactivé, le problème est le même… il y a bien un soucis vis à vis de la gestion du UserAgent au niveau de votre firewall depuis le 30/10/204…
Oui je suis d'accord avec vous pour un UA généralisé. Avez vous appelez tous les constructeurs de firmware, applications pour leur avoir annoncé cela ?
Vous sous entendez que nos problèmes viennent d'un firewall désactivé suite à une mise à jour d'OVH?
non je dis que ce comportement était visible avant avec le firewall d'activé
Oui je suis d'accord avec vous pour un UA généralisé. Avez vous appelez tous les constructeurs de firmware, applications pour leur avoir annoncé cela ?
désolé si les constructeurs ne respectent pas les RFC pour les requêtes HTTP, mais c'est au client de râler auprès des constructeur quand celui-ci fait de le merde
avant de le bloquer ??
demander à OVH.
Dans tous les cas comme répondu par un corp de OVH, c'est bien ce que j'avais présenté => protection dans les attaques/requêtes illégitime :
Je vous confirme que nous travaillons régulièrement à l'amélioration des protections de nos infrastructures contre le trafic malveillant à destination de vos sites & applications.
Dans ce but, nous avons fait évolué le filtrage des accès sans user-agent, la pratique étant extrêmement présente dans le trafic illégitime que nous rencontrons actuellement. Ce change a été déployé de manière très progressive sur les infrastructures depuis les 2 dernières semaines avec des phases d'attente et d'analyse pour nous assurer que le trafic légitime n'est pas impacté. Le déploiement est désormais terminé depuis ce mardi matin.
J'ai exactement le même problème depuis 15h ce jour sur tous mes appels PHP file_get_contents et readfile : HTTP 302 / Temporary moved Je n'ai jamais eu besoin de mettre de user-agent sur ces 2 fonctions. Je vais faire un ticket dès demain matin. Donc non, cela ne vient pas de notre code.
alors en effet, depuis hier j'ai ce cookie challenge sur une application native qui ne supporte pas la redirection 302…je pourrais corriger cela, mais l'application utilise justement sa requête pour faire sa mise à jour !
c'est un gros problème si on ne peut pas - ne serait-ce que temporairement- désactiver ce filtrage.
