DNS resuelve una dirección IP incorrecta en un país

14

Uno de mis amigos tiene un sitio web de eLearning basado en Claroline. Hace dos días, solo los usuarios de Suiza comenzaron a redirigirse "al azar" en otra dirección IP al acceder al dominio del sitio web.

Si fuerzo el servidor DNS a 8.8.8.8 o 9.9.9.9 en la PC de los estudiantes, el dominio se resuelve correctamente. Pero si me quedo con el Servidor DNS suizo local, se resuelve en una dirección IP incorrecta (en la lista negra).

La parte extraña es: no es solo este cliente y su propia computadora. Todos los estudiantes con sede en Suiza también se ven afectados. Pero no los franceses.

La segunda parte extraña es: alguna página responde desde esta dirección IP falsa con el contenido correcto. Al igual que el eLearning se duplicó en otro servidor O se almacenó en caché en alguna parte.

El servidor es un antiguo Ubuntu 10.04.4 LTS, y probablemente no esté correctamente protegido / configurado. Tengo acceso completo a este servidor, pero no lo logré, así que no estoy seguro de qué buscar o incluso qué hacer.

Esto es lo que miré / probé hasta ahora:

  • Comprobado todo Apache 2 vhost conf.
  • Iptables controladas (vacío) y /etc/hostsy /etc/resolv.conf(seguro)
  • Le pregunté a Swisscom (telecomunicaciones suizas principales) si pusieron en la lista negra el dominio o algo así: Nope Comprobó la base del código claroline: parece seguro, pero es enorme. No puedo verificar todos los archivos.

Aquí hay un nslookup en una de las computadoras Windows de los estudiantes:

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

Y, por supuesto, 195.186.210.161 no es la dirección IP correcta del servidor.

No soy administrador del sistema. Solo estoy ayudando a un amigo, así que no estoy seguro de qué mirar a continuación.

iizno
fuente
1
Tal vez sea posible que el ISP de esos estudiantes intente realizar un almacenamiento en caché inteligente y, por lo tanto, interfiera con el DNS. ¿Están todos en la misma universidad, por ejemplo? Si utiliza HTTPS para su servidor, aún pueden modificar el DNS, pero el usuario final vería un error de certificado si el resultado del DNS apunta a un servidor diferente al suyo, ya que no estaría en posesión de la clave privada.
David
1
Además, ¿está seguro de que la dirección IP del servidor es estática? Por ejemplo, si cambias con frecuencia o cambiaste recientemente dentro del TTL del registro DNS, entonces es posible que el DNS se resuelva a una IP antigua (una vez válida), aunque eso no explicaría perfectamente por qué ven contenido reflejado. Si usa una herramienta como mxtoolbox.com/DNSLookup.aspx , puede ver el TTL del registro A o el registro CNAME adjunto al dominio.
David
1
@DavidGoate Esa es la parte divertida, los estudiantes están en casa, en toda Francia y Suiza. El francés no tiene ningún problema.
iizno
1
@DavidGoate Server IP es fijo y nunca ha cambiado. dnschecker.org/#A/elearning.affis.ch no muestra ningún error.
iizno
1
Hola, otra cosa que puede suceder, ya que vi un error como ese en el pasado, puede ser un servidor DNS mal mantenido por el ISP. Vi la zona DNS que se transfirió pero nunca se borró a nivel de ISP, lo que condujo a un error extraño.
yagmoth555

Respuestas:

11

Como escribió MadHatter , este es el ISP de los usuarios finales (Swisscom) que redirige su sitio a través de un proxy de filtrado. Es muy probable que todos los usuarios que se suscriban a su servicio de Internet Guard estén en realidad representados allí, no solo su sitio.

Dicen que el filtro es contra malware, phishing y virus, por lo que no debería ser un problema de "clasificación", sino de seguridad.

Por lo tanto, su primer paso debería ser verificar que el sitio no haya sido infectado. Los sitios PHP tienden a ser bastante vulnerables (si alguien encuentra la manera de cargar un archivo .php en algún lugar de la jerarquía visible, se puede ejecutar de forma remota para hacer lo que quiera). También hay muchas otras formas de hacer daño (inyecciones SQL, XSS almacenadas ...).

Su página de inicio no está bloqueada, o al menos no todo el tiempo, así que:

  • solo algunas de las páginas están infectadas
  • la infección solo aparece una fracción del tiempo en las solicitudes de los usuarios (una estrategia común para volar bajo el radar)
  • o hay algo más en algunas páginas que desencadena un falso positivo

Puede ver el resultado usted mismo señalando la dirección del sitio web a la dirección IP del proxy. Puede hacerlo editando su /etc/hostsarchivo (los detalles varían según la plataforma) y agregando una línea:

195.186.210.161        elearning.affis.ch

Luego puede visitar el sitio como uno de esos usuarios y ver qué páginas están bloqueadas o no.

Una vez que tenga una mejor idea de qué páginas están bloqueadas o no, puede ser más fácil identificar el problema real. Luego corríjalo, y de repente pasará de inmediato, o puede que tenga que informar un falso positivo (hay un enlace para eso en la parte inferior de la página "bloqueada").

Tenga en cuenta que tratar de informar un falso positivo antes de verificar la infección probablemente sería contraproducente. Intenta encontrar y solucionar el problema primero.

Editar

Tenga en cuenta que la versión de Claroline que ejecuta (1.11.9) tiene múltiples vulnerabilidades XSS conocidas desde 2014:

Múltiples vulnerabilidades de scripting entre sitios (XSS) en Claroline 1.11.9 y anteriores permiten a los usuarios autenticados remotos inyectar script web o HTML arbitrario a través de (1) el campo Buscar en una acción de la bandeja de entrada a messaging / messagebox.php, (2) el " Nombre "campo a auth / profile.php, o (3) el campo Speakers en una acción rqAdd a calendar / agenda.php

Si el problema es realmente un ataque XSS almacenado, tome el último volcado de su base de datos y verifique si contiene algo como una <scriptetiqueta (no olvide buscar sin distinción entre mayúsculas y minúsculas).

jcaron
fuente
18

Si señala un navegador a la dirección IP devuelta, http://195.186.210.161/ , recibirá el mensaje de "sitio web peligroso bloqueado" de Swisscom. Mi conjetura es que su sistema de bloqueo de contenido de "Internet seguro" funciona, al menos en parte, mintiendo en respuesta a las solicitudes de DNS, y que su sitio web está fallando por alguna razón.

Entiendo que les preguntaste si te estaban bloqueando, pero en mi experiencia, incluso el soporte técnico de primera línea de los ISP de tamaño mediano no tiene la menor idea de lo que está sucediendo. Es muy posible que todo el sistema de niñeras sea subcontratado (o hecho por un producto comercial de terceros) y que nadie en Swisscom tenga idea de qué sitios están bloqueados en un momento dado. Preguntarle a su estudiante si tiene algún tipo de configuración de "internet de niñera" puede ser más productivo.

Al final del día, esto puede no ser un problema que pueda resolver, ya que no es el cliente de ese ISP y no le deben nada. Es probable que lo único que tenga algún efecto sea que los padres del alumno llamen a su soporte de ISP, se quejen en voz alta por la resolución incorrecta de DNS y amenacen con cambiar el ISP si no se resuelve.

Editar : este hilo sugiere que el motor de bloqueo de sitios de Swisscom puede ser un poco entusiasta, y que no siempre es fácil obtener ningún tipo de resolución positiva de ellos. También sugiere que este no es un filtro opcional, pero que se aplica a todos los clientes de Swisscom, les guste o no, por lo que optar por salir puede ser difícil.

MadHatter
fuente
1
Es por eso que también pienso, pero, ¿por qué algunas páginas muestran el contenido correcto y otras acaban de expirar? ? Es como si duplicaran algunas páginas.
iizno
77
No sabemos qué están usando, por lo que no podemos saber cómo funciona. Tal vez la decisión de primera línea se toma en el momento de la resolución de DNS, pero el sistema en 195.186.201.161 implementa una decisión de segunda línea basada en qué URL se solicita, enviando al servidor real si y solo si decide que el contenido es "seguro" ". Una vez que las personas comienzan a tratar de cambiar los protocolos de internet en busca de una visión (inalcanzable) de un internet "seguro", casi cualquier cosa puede salir mal.
MadHatter
2
Parece un problema que podría resolverse con un abogado en la jurisdicción correcta ...
R .. GitHub DEJA DE AYUDAR AL HIELO
44
Si realmente se está representando y escaneando, forzar HTTPS podría ayudar (o dañar). El ISP al menos solo tendría la opción de bloquear todo el sitio o ninguno en lugar de bloquear algunas páginas y no otras. Esto puede hacer las cosas menos confusas para los usuarios.
Joshua Dwire
3
Es muy posible que todo el sistema de niñeras sea subcontratado (o hecho por un producto comercial de terceros) y que nadie en Swisscom tenga idea de qué sitios están bloqueados en un momento dado. Trabajé con una gran empresa de telecomunicaciones que hace exactamente esto, así que puedo confirmar. El soporte técnico del ISP probablemente simplemente no tiene forma de saberlo, sin embargo, deberían poder abrir un ticket a quien realmente esté ejecutando el sistema de clasificación si hay algún problema.
Bakuriu