Bonjour,
depuis le 31/10 sans actions de ma part, le déploiement de mon application click once ne veux plus se télécharger avec une erreur "+ Le serveur distant a retourné une erreur : (403) Interdit.".
première constation, l'application appel un fichier php sur mon site.
Via un navigateur, pas de soucis. Par contre via l'application, erreur 403 également.
Après ajout d'un header avec un user agent dans la requête, j'ai maintenant un retour du fichier php dans l'application (1er problème résolu).
Second test : j'ai copier mon application sur un autre compte OVH et là tout fonctionne parfaitement.
Troisième test : en remettant l'application sur mon site, erreur 403 au lancement d'un programme clickonce, même le plus simple, sans de fichier .htaccess, les droits de dossiers et fichiers sont identique au site qui fonctionne… J'ai même testé avec un dossier à la racine du site…
Il y donc eu deux modifications le 31/10 :
-plus possible d'interroger un fichier php via une application sans un HttpRequestHeader.UserAgent. Pourquoi pas par rapport à la sécurité et bonne pratiques…
-plus possible de lancer une application click-once sur mon espace (Perso) alors que cela fonctionne sur un autre compte perso également.
Dans les logs, rien d'anormal.
Je n'ai plus trop d'idée pour résoudre mon problème sauf créer un autre compte OVH.
En tout cas, merci pour vos retours.
Cordialement
plus possible d'interroger un fichier php via une application sans un HttpRequestHeader.UserAgent. Pourquoi pas par rapport à la sécurité et bonne pratiques...
Bonjour,
Avez-vous une différence dans Hébergement > multisite > colonne "Firewall" ou "Pare-feu" ?
Je soupçonne celui-ci.
Bonjour Fritz2cat,
Je n'ai pas de différences au niveau de la colonne "Firewall".
Par contre, je remarque que le sous domaine incriminé (4ème ligne sur l'image jointe) avait une entrée DNS AAA valide en IP V6 contrairement aux autres sous domaines. Je l'ai donc désactivé l'IPV6 au niveau DNS (diffusion 24h)
mes deux problèmes sont peut-être liés:
-plus possible d'interroger un fichier php via une application sans un HttpRequestHeader.UserAgent.
>Ce problème est résolu (contourné) au niveau de l'application
-plus possible de lancer une application click-once sur mon espace (Perso) alors que cela fonctionne sur un autre compte perso également.
>Une application click-once est télécharger dans un premier temps puis fais appel au manifeste sur le serveur. Et c'est là que cela doit coincer car l'application n'intègre pas de UserAgent à ce niveau.
la piste du firewall est tout de même intéressante. mais dans mon cas, tout était désactivé.
la piste du firewall
On a effectivement un 403 avec un User-Agent comme wget.
Bonjour Fritz2cat,
il y a donc bien quelque chose au niveau du firewall. Pensez-vous que c'est possible de corriger ce problème ? Malheureusement, je n'ai pas la main sur ce type de paramétrage pour autoriser cette règle.
Merci pour votre implication.
Cordialement
Merci pour votre implication.
Sans connaître vos domaines, on ne peut pas s'impliquer plus.
Je confirme ce probleme,
Sur mon domaine (www.simhubdash.com) depuis 11h45 environ, plus aucun appels sans user agent ne fonctionnent.
Bonjour Fritz2cat,
je vous ai envoyé les domaines en privé.
Cordialement
je vous ai envoyé les domaines en privé.
J'ai répondu en privé, je n'ai malheureusement pas pu reproduire avec wget.
Bonsoir à tous.
Même soucis de chargement d'une page PHP depuis une application DotNet avec un WebClient sans UserAgent. Cela fonctionne si j'ajoute un UserAgent.
Impossible de contourner ceci, ni avec le .ovhconfig, ni avec .htaccess.
Ce nouveau comportement qui date de ce matin est très gênant.
AltiFab.
J'ai le meme probleme depuis le 30 octobre a 11h32.
sans user agent, on a un HTTP 302 avec setCookie:ovh_challenge_cookie qui renvoi sur la meme page.
curl daspower.fr -H User-Agent:
302 Found
302 Found
nginx
Bonjour,
question con : c'est quoi vos cas d'usage ou vos requêtes non pas de User-Agent ?
Cordialement, janus57
moi c'est une station meteo, mais ca peut aussi bien etre des call back d'API diverses, ou n'importe quel equipement electronique avec des firmwares propriétaires sur les quels ont a pas forcément la main.
Bonjour Fritz2cat,
il y a bien un problème de firewall côté backbone chez OVH.
ci dessous 2 tests afin que vous puissiez constater le problème dans vos logs:
1- avec agent https://teleftech.fr/test_api.php?test=123
(avec agent car nous appelons la requête dans le navigateur)
2- test sans agent (résultat page banche) https://teleftech.fr/test.php
(sans agent car c'est le script qui génère la demande)
=>J'en déduis une erreur 403 sur ce second script car pas d'agent, appellation directe du script, ce qui est confirmer par mon application
détail du test :
fichier test.php (sans agent)
include ('./test_api.php?test=123');
?>
fichier test_api.php
$test=stripslashes($_GET['test']);
if ($test=='123'){
echo 'test réussi avec agent';
} else{
echo 'test non réussi sans agent';
}
?>
@ANTHONYG38, je suis tout à fait d'accord avec vous. plus aucuns appareils connecté, API… ne peuvent maintenant se connecter sur le site OVH sans un UserAgent.
@Fritz2cat
Une modification au niveau des firewalls OVH a été planifié depuis le 31/10/2024 et à pour conséquence ce topic.
M. Fritz2cat, merci pour votre retour.
Cela est très problématique et commence à toucher toute la communauté (le temps que la mise à jour du 31/10 se termine…)
Pour information, j'ai dû héberger mon application at home ;(
, le temps que le problème se résolve
Cordialement
Bonjour à tous,
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.
La navigation passant avec des user-agent légitimes n'est pas bloquées (wget dans l'exemple de @Fritz2cat par exemple, qui doit plutôt être bloqué par le firewall applicatif, en ayant le domaine, nous pourrions aisément confirmer)
celle sans user-agent passe par un challenge facile à suivre pour tout navigateur bien configuré.
@ANTHONYG38 pouvez-vous me fournir en privé l'hébergement concerné que l'on regarde les logs ?
La 302 avec le cookie doit être suivie par tout navigateur normalement configuré. Nous avons besoin de plus détails pour regarder.
@DavidP62 dans les logs pour le premier lien, je n'ai que des 200 et 500 dans les logs. Pour le second lien, c'est uniquement du 200 et 404.
Donc pas de blocage sur ces deux liens.
@FabriceS25 avez vous des détails sur le webclient concerné ? le usecase ?
Effectivement ce comportement n'est pas configurable et situé en frontal des infrastructures.
Bruno B.
Bonjour,
mon hébergement :
tzhiwwm.cluster030.hosting.ovh.net
dans les log de hier par exemple, j'ai aucune ligne pour weather.daspower.fr
Vous ne prévennez pas quand vous changez des choses du genre qui peuvent impacter les utilisateurs ?
Je trouve ca assez limite que votre collegue Jérémie E. dans mon ticket de support CS10351013 me dise que le problème vient de mon site et me laisse chercher tout seul alors qu'il savait d'ou vient le probleme…
Sinon comment peut ont faire pour débloquer nos problèmes ?
Des appels API rest typiquement, le user agent est une norme des navigateurs. Une requête (embedded, API, client lourd etc…) n'en dispose pas par défaut. Je ne comprends pas qu'un tel changement ai pu être fait sans aucun préavis (confirmé par un ticket au support). Un hébergement ne veux pas dire nécessairement site web, il y a une multitude d'autres usages légitimes comme les API
Wget spécifie un user agent par défaut. Des qu'il est présent tout fonctionne. Mais en cas d'appel http simple sans user agent (par exemple en .net) toutes les requêtes sont rejetées. Cote serveur aucune trace dans les logs elles sont rejetées "en amont"
Bonjour,
Nous avons le même problème de requêtes sans user-agent qui finissent en 403. Nous sommes dans le contexte d'une application C#. Nous n'avons pas été prévenu à l'avance et n'avons pas pu demander à nos clients de mettre à jour leurs versions et nous avons du découvrir par nous-même que c'était ce header qui manquait. L'erreur n'étant pas très explicite…
Nos clients se retrouvent bloqués par ce changement et tous les appels vers notre serveur échouent. C'est extrêmement gênant pour notre business et nos clients.
@BrunoB-OVHCloud, quelles solutions sont possibles ? J'apprécierai fortement une réponse rapide de la part d'OVH à ce sujet pour pouvoir permettre à nos clients d'utiliser notre application qui ne fonctionne plus depuis le 5 novembre matin.
Nous avons constaté également que c'était depuis 11h45 comme indiqué par @2f9e37cb726af0c38578 dans un message au dessus.