DNS résout la mauvaise adresse IP dans un pays

Un de mes amis a un site eLearning basé sur Claroline. Il y a deux jours, seuls les utilisateurs suisses ont commencé à obtenir une redirection "au hasard" sur une autre adresse IP lors de l'accès au domaine du site Web.

Si je force le serveur DNS à 8.8.8.8 ou 9.9.9.9 sur le PC des étudiants, le domaine est résolu correctement. Mais si je reste avec le serveur DNS suisse local, il se résout en une mauvaise adresse IP (sur liste noire).

La partie étrange est: ce n'est pas seulement ce client et son propre ordinateur. Chaque étudiant basé en Suisse est également concerné. Mais pas les français.

La deuxième partie étrange est: Une page répond de cette fausse adresse IP avec le contenu correct. Comme l'eLearning a été dupliqué sur un autre serveur OU mis en cache quelque part.

Le serveur est un ancien Ubuntu 10.04.4 LTS, et il n'est probablement pas correctement protégé / configuré. J'ai un accès complet sur ce serveur, mais je ne l'ai pas géré, donc je ne sais pas quoi chercher ni même quoi faire.

Voici ce que j'ai regardé / essayé jusqu'à présent:

Vérifié tous Apache 2 vhost conf.
Iptables vérifiés (vide) et /etc/hostset /etc/resolv.conf(sûr)
A demandé à Swisscom (principal opérateur de télécommunications suisse) s'ils avaient mis le domaine sur liste noire ou quelque chose comme ça: Non. Base de code claroline vérifiée: ça a l'air sûr, mais c'est énorme. Je ne peux pas vérifier tous les fichiers.

Voici un nslookup sur l'un des ordinateurs Windows des étudiants:

C:\WINDOWS\system32>nslookup
Serveur par défaut :   UnKnown
Address:  fe80::8e59:c3ff:fecf:8d9b

> elearning.redacted-domain.ch
Serveur :   UnKnown
Address:  fe80::8e59:c3ff:fecf:8d9b

Réponse ne faisant pas autorité :
Nom :    elearning.redacted-domain.ch
Address:  195.186.210.161

Et bien sûr, 195.186.210.161 n'est pas l'adresse IP correcte du serveur.

Je ne suis pas administrateur système. J'aide juste un ami, donc je ne sais pas quoi regarder ensuite.

domain-name-system

— iizno
source

Il est peut-être possible que le FAI de ces étudiants tente d'effectuer une mise en cache intelligente et interfère donc avec le DNS. Sont-ils tous dans la même université par exemple? Si vous utilisez HTTPS pour votre serveur, il peut toujours modifier le DNS, mais l'utilisateur final verrait une erreur de certificat si le résultat DNS pointe vers un serveur autre que le vôtre car il ne serait pas en possession de la clé privée.

— David

De plus, êtes-vous sûr que l'adresse IP du serveur est statique? Par exemple, si vous changez fréquemment ou avez récemment changé dans le TTL de l'enregistrement DNS, il est possible que le DNS soit résolu en un ancien (une fois IP valide) - bien que cela n'explique pas parfaitement pourquoi ils voient du contenu en miroir. Si vous utilisez un outil tel que mxtoolbox.com/DNSLookup.aspx, vous pourrez peut-être voir le TTL de l'enregistrement A ou de l'enregistrement CNAME attaché au domaine.

— David

@DavidGoate C'est la partie amusante, les étudiants sont à la maison, partout en France et en Suisse. Le français n'a pas de problème.

— iizno

@DavidGoate Server IP est fixe et n'a jamais changé. dnschecker.org/#A/elearning.affis.ch ne montre aucune erreur.

— iizno

Salut, une autre chose qui peut arriver, comme j'ai vu une erreur comme ça dans le passé, ce peut être un serveur DNS mal entretenu par le FAI. J'ai vu une zone DNS qui a été transférée mais jamais effacée au niveau du FAI, conduisant ainsi à une étrange erreur.

— yagmoth555

Réponses:

Comme l'a écrit MadHatter , il s'agit du FAI des utilisateurs finaux (Swisscom) réacheminant votre site via un proxy de filtrage. Il est fort probable que tous les utilisateurs qui s'abonnent à leur service Internet Guard soient effectivement mandatés par ce biais, et pas seulement votre site.

Ils disent que le filtre est contre les logiciels malveillants, le phishing et les virus, donc ce ne devrait pas être un problème de "classification", mais un problème de sécurité.

Votre première étape devrait donc être de vérifier que le site n'a pas été infecté. Les sites PHP ont tendance à être assez vulnérables (si quelqu'un trouve un moyen de télécharger un fichier .php quelque part dans la hiérarchie visible, il peut ensuite être exécuté à distance pour faire tout ce qu'il veut). Il existe également de nombreuses autres façons de nuire (injections SQL, XSS stockés ...).

Votre page d'accueil n'est pas bloquée, ou du moins pas tout le temps, alors soit:

seules certaines pages sont infectées
l'infection ne s'affiche qu'une fraction du temps sur les demandes des utilisateurs (une stratégie courante pour voler sous le radar)
ou il y a autre chose sur certaines pages qui déclenche un faux positif

Vous pouvez voir le résultat vous-même en pointant l'adresse du site Web vers l'adresse IP du proxy. Vous pouvez le faire en modifiant votre /etc/hostsfichier (les détails varient en fonction de la plate-forme) et en ajoutant une ligne:

195.186.210.161        elearning.affis.ch

Vous pouvez ensuite visiter le site en tant que l'un de ces utilisateurs et voir quelles pages sont bloquées ou non.

Une fois que vous aurez une meilleure idée des pages bloquées ou non, il sera peut-être plus facile d'identifier le problème réel. Ensuite, corrigez-le, et soit il passera soudainement tout de suite, soit vous devrez peut-être signaler un faux positif (il y a un lien pour cela au bas de la page "bloqué").

Notez qu'essayer de signaler un faux positif avant de rechercher une infection serait probablement contre-productif. Essayez très fort de trouver et de résoudre le problème en premier.

Éditer

Notez que la version de Claroline que vous exécutez (1.11.9) possède plusieurs vulnérabilités XSS connues depuis 2014:

Plusieurs vulnérabilités de script intersite (XSS) dans Claroline 1.11.9 et versions antérieures permettent aux utilisateurs authentifiés à distance d'injecter un script Web arbitraire ou du HTML via (1) le champ Rechercher dans une action de boîte de réception vers messaging / messagebox.php, (2) le " Champ "First name" à auth / profile.php, ou (3) le champ Speakers dans une action rqAdd à calendar / agenda.php

Si le problème est en effet une attaque XSS stockée, prenez le dernier vidage de votre base de données et vérifiez s'il contient quelque chose comme une <scriptbalise (n'oubliez pas de rechercher en respectant la casse).

— jcaron
source

Si vous pointez un navigateur sur l'adresse IP renvoyée, http://195.186.210.161/ , vous obtenez le message "Site Web dangereux bloqué" de Swisscom. Je suppose que leur système de blocage de contenu "Internet sûr" fonctionne, au moins en partie, en mentant en réponse aux demandes DNS, et que votre site Web en est victime, pour une raison quelconque.

Je comprends que vous leur avez demandé s'ils vous bloquaient, mais d'après mon expérience, même le support technique de première ligne des FAI n'a pas la moindre idée de ce qui se passe à l'arrière. Il est fort possible que l'ensemble du système de nounou soit externalisé (ou effectué par un produit commercial tiers) et que personne chez Swisscom ne sache à quel moment les sites sont bloqués. Demander à votre élève s'il possède des paramètres de «nounou Internet» peut être plus productif.

En fin de compte, ce n'est peut-être pas un problème que vous pouvez résoudre, car vous n'êtes pas le client de ce FAI et il ne vous doit rien. Le fait que les parents de l'élève appellent le support de leur FAI, se plaignent fortement d'une mauvaise résolution DNS et menacent de changer de FAI s'il n'est pas résolu est probablement la seule chose qui ait un effet.

Edit : ce fil suggère que le moteur de blocage de sites de Swisscom peut être un peu trop enthousiaste, et qu'il n'est pas toujours facile d'obtenir une résolution positive de leur part. Il suggère également qu'il ne s'agit pas d'un filtre opt-in, mais qu'il s'applique à tous les clients de Swisscom, qu'ils le veuillent ou non, il peut donc s'avérer difficile de le désactiver.

— Chapelier Fou
source

C'est pourquoi je pense aussi, mais pourquoi certaines pages affichent-elles le contenu correct et d'autres viennent-elles de se terminer. ? C'est comme s'ils dupliquaient certaines pages.

— iizno

Nous ne savons pas ce qu'ils utilisent, nous ne pouvons donc pas savoir comment cela fonctionne. Peut-être que la décision de première ligne est prise au moment de la résolution DNS, mais le système à 195.186.201.161 implémente une décision de deuxième ligne en fonction de l'URL demandée, en procurant un proxy au serveur réel si et seulement s'il décide que le contenu est "sûr" ". Une fois que les gens commencent à essayer de contourner les protocoles Internet à la recherche d'une vision (inaccessible) d'un Internet «sûr», presque tout peut mal tourner.

— MadHatter

Cela semble être un problème qui pourrait être résolu avec un avocat dans la bonne juridiction ...

— R .. GitHub STOP STOPINGING ICE

S'il est en fait proxy et analysé, forcer HTTPS pourrait aider (ou blesser). Le FAI aurait au moins le choix de bloquer l'ensemble du site ou pas du tout plutôt que de bloquer certaines pages et pas d'autres. Cela peut rendre les choses moins déroutantes pour les utilisateurs.

— Joshua Dwire

Il est fort possible que l'ensemble du système de nounou soit externalisé (ou effectué par un produit commercial tiers) et que personne chez Swisscom ne sache à quel moment les sites sont bloqués. J'ai travaillé avec un grand opérateur télécom qui fait exactement cela, donc je peux le confirmer. Le support technique du FAI n'a probablement tout simplement aucun moyen de le savoir, mais il devrait être en mesure d'ouvrir un ticket à quiconque gère réellement le système de classification en cas de problème.

— Bakuriu