Diferencia de huellas dactilares SSH

Question

tl, dr:

• El usuario tiene un servidor doméstico al que él y sus compañeros de trabajo acceden a través de SSH. Recientemente, los compañeros de trabajo comenzaron a experimentar problemas de conexión y encontraron claves SSH diferentes a las esperadas.
• El usuario, en la red local, no experimenta estos problemas debido a un posible loopback NAT.
• Descubrieron que los compañeros de trabajo estaban viendo un servidor SSH de Dropbear, no el OpenSSH esperado, lo que sugiere que el módem/enrutador está interfiriendo.
• El módem/enrutador RTF8115VW, suministrado por el ISP, no tiene configuraciones fácilmente ajustables, lo que genera incertidumbre sobre posibles violaciones de seguridad/piratería o problemas de configuración.
• El usuario busca asesoramiento sobre los próximos pasos.

Cosa completa:

Tengo un servidor en casa al que me conecto vía SSH (red local) y mis compañeros de trabajo también acceden vía SSH (internet) directamente a través de mi IP.

Hace unos días mis compañeros de trabajo empezaron a tener problemas de conexión, quejándose el terminal de que la clave pública no era la misma. Empezamos a investigar.

Descubrí que al acceder a través de la red local, veía la misma huella digital que informa el servidor si me conecto directamente a él, comenzando con yury4. Esto sucede incluso si accedo a mi IP externa: parece que el módem/enrutador realiza algún tipo de traducción de bucle invertido NAT y todo funciona. Sin embargo, mis compañeros de trabajo ven otra huella digital, que comienza con XyTk/, constantemente y ya no pueden conectarse.

Observando un poco más, notamos que vieron que se estaba reportando un servidor SSH diferente: Dropbear. Lo que vi fue OpenSSH. Al investigar, descubrí que Dropbear parece ideal para sistemas integrados, lo que me llevó a sospechar del módem/enrutador. Bingo: si le pregunto al módem/router cuál es su huella digital, responde con la que comienza con XyTk/.

El problema es que no puedo identificar lo que está pasando. Mi comprensión básica es que el módem/enrutador no debe alterar los paquetes, simplemente transmitirlos, ¿verdad? Tampoco sé cómo solucionar el problema. El módem/enrutador proviene del proveedor de acceso y algunas configuraciones no parecen accesibles. De hecho, ni siquiera sé si esta pequeña cosa ha sido invadida y si hay un intermediario o si es solo un problema de configuración.

¿Cuál sería el siguiente paso del diagnóstico?

EDITAR: el dispositivo es un RTF8115VW.

Answer 1

Podría ser una buena investigación encontrar las razones. Pero lo que escribes me hace sospechar que posiblemente hayas sido hackeado.

Entonces pregúntese cuáles son las principales cosas que debe hacer en tal caso.

1. Si no tiene nada que perder, puede realizar algunas investigaciones forenses y sobre el cómo y el dónde de los problemas detectados.
2. Si hay algo importante, debería pensar en el aislamiento y la copia de seguridad inmediata, pero sin tocar ningún medio de copia de seguridad existente. — El peor de los casos es que actualmente un ransomware cifra silenciosamente sus archivos y aparecerá en unas horas o días para pedir dinero.
3. Un escenario no tan agresivo es que el enrutador se haya convertido en parte de una botnet y los malos puedan acceder a él con la punta del dedo para hacer algunas cosas desagradables en otros sitios web.

¿Por qué tengo en cuenta un hack?

• El primer indicio notable es que abrió el puerto estándar SSH en el lado de Internet.
  Mi opinión: en un enrutador todo en uno,nunca jamáshaga esto en un puerto estándar para SSH o cualquier otro servicio de red. – Si (dentro de este enrutador o del servidor al que reenvía) hay algún error de implementación o de configuración, lo piratearán. Al menos los puertos estándar son escaneados continuamente por los malos, día y noche, en todo el mundo, de forma totalmente automatizada, como una lluvia interminable.

• El problema surgió algún tiempo después de que funcionara regularmente. Entonces, ¿por qué debería cambiar esta funcionalidad?

• El demonio ssh del enrutador obviamente sirve al lado de Internet. (O el reenvío de puertos no termina en el servidor sino en el enrutador. ¿Pero por qué?) Esto sucedió de repente y ni siquiera sabes cómo habilitar el puerto ssh del enrutador.

Como usted (y su compañero de trabajo) dicen que no cambió nada (¿está seguro?), se debe tener en cuenta una de estas cosas:

1. una actualización del firmware o de la configuración del enrutador podría haber sido errónea.
2. Un técnico de servicio del proveedor de Internet ha configurado algo mal.
3. ha ocurrido un hack.

Yo tomaría el peor de los casos y me alegraría si resultara falso.

¿Qué sigue?

Verifique nuevamente que Dropbear esté realmente alojado en el enrutador. Dependiendo de la veracidad de esta afirmación, todo el escenario puede cambiar.

Si es verdad:

Sospecho que su enrutador y su servidor están comprometidos (al menos) y alguien no autorizado abrió el puerto ssh.

Recopilar información

1. Si puede y desea realizar algún análisis de tráfico, hágalo ahora y luego desconecte sus sistemas de Internet.
2. Verifique los registros (enrutador, servidor, clientes) en busca de entradas sospechosas (pero es posible que hayan sido manipuladas), especialmente en el lapso de tiempo en que la funcionalidad cambió.
3. Consulta tus datos e instalaciones.

Eliminar riesgos potenciales

Sería una buena idea consultar algunas herramientas profesionales como comprobadores de malware.

• Si aún no lo has hecho, desconecta Internet.
• Realice una copia de seguridad de emergencia (sin utilizar los medios de copia de seguridad habituales, pero manteniéndolos fuera de línea)
• Reinicie su enrutador y preferiblemente instale (reinstale) el firmware. Difícilmente se puede hacer más contra las puertas traseras.
  Puede copiar la configuración del enrutador, pero NO "guarde la configuración" y después de restablecerla "restaure la configuración por archivo". Es posible que vuelvas a aplicar algunas configuraciones no deseadas.
• Piensa en qué hacer con tu servidor. Mediante el reenvío de puerto, el hacker potencial tenía contacto directo con él, posiblemente hackeándolo primero y luego comprometiendo toda la LAN.
• Piense y decida sobre el posible riesgo de que sus clientes se vean comprometidos (¡incluido el cliente de su compañero de trabajo!).

Después del reinicio, algunas cosas en las que pensar

• Verifique que el enrutador tenga un puerto ssh abierto en el lado de Internet y en el lado de LAN, antes de aplicar su configuración personal. Asegúrese de averiguar cómo se puede habilitar/deshabilitar esto.
• Si necesita acceso ssh externo para su compañero de trabajo, elija un puerto poco común, preferiblemente entre 10000 y 65535, sin utilizar "22" dentro del número.
• Asegúrate de lo que estás configurando. simplemente actuando"oh, resulta que ahora funciona"es una mala idea. — Limpiar con precisión los restos de prueba y error.
• Piense en un firewall real que aísle sus servidores accesibles a Internet de su LAN.
• Refuerza tu servidor ya que está expuesto a Internet
• Si tiene que utilizar un proveedor de DNS dinámico, no elija un servicio proporcionado por el fabricante de su enrutador. Este es un honeypot para hacks específicos de hardware.
• Para desconectarse de la base de datos del hacker, elija un nombre DNS diferente. Si tiene una dirección IP externa fija, opte por cambiarla, si es posible.

Answer 2

El problema es que no puedo identificar lo que está pasando. Mi comprensión básica es que el módem/enrutador no debe alterar los paquetes, simplemente transmitirlos, ¿verdad?

Bueno no exactamente.

Por un lado, si bien es cierto que los enrutadoresnormalmenteno juegue con paquetes en o por encima del nivel IP (aparte de disminuir el TTL de IP), también tiene NAT además del enrutamiento simple, y NAT es literalmente una forma de "jugar con paquetes", ya que implica reescribir tanto L3 (IP) y encabezados L4 (TCP/UDP). (Y eso es incluso antes de entrar en los ALG, también conocidos como "ayudantes de NAT"; por ejemplo, los enrutadores realmente reescriben FTPcomandos y respuestaspara que funcione vía NAT…)

Pero en su caso no se trata de jugar con los paquetes sino defalta del mismoEso está causando las diferencias:

• Recuerde que cuando se conecta desde el exterior, se conecta alenrutadordirección IP pública. Cuando la regla de "redireccionamiento de puerto" está activa (que es básicamente DNAT), el enrutador reescribe el campo "IP de destino" de cada paquete antes de transmitirlos (para que sean enrutados a la dirección IP interna del servidor).

• Cuando la regla de "redireccionamiento de puerto" esnoactivo, sin embargo, no se reescribe nada, por lo que si se conecta a la dirección IP del enrutador, en realidad solo se está conectando a... el enrutador.

Es bastante normal que el enrutador tenga su propio servidor SSH. Sin embargo, por lo general, las conexiones externas son 1) denegadas por las reglas habituales de firewall del enrutador y 2) anuladas por la regla DNAT de "redireccionamiento de puerto" para que el enrutador ni siquiera las considere entrantes. Pero en su caso, parece que ninguna de esas reglas funciona correctamente: la reescritura del DNAT no se está produciendo.yel filtro del firewall no está bloqueando la conexión entrante.

Entonces, si tuviera que adivinar (basado en el hecho de que el "bucle invertido NAT" internohaceparece funcionar), es algún tipo de problema de configuración (tal vez el ISP implementa una nueva configuración durante la noche) lo que hace que tanto el filtro como las reglas NAT esperen una interfaz diferente como "interfaz de entrada". (Por ejemplo, tal vez la interfaz WAN sea eth0.3 pero las reglas esperan que WAN sea eth0.4...)

• Compruebe si desaparece después de reiniciar el enrutador o de eliminar y volver a agregar la regla de redireccionamiento del puerto.
• Compruebe si todavía sucede si configura la redirección de puerto para un puerto diferente al habitual. (No solucionará el problema
• Dado que el ISP bloquea el enrutador, en realidad es problema del ISP; Llame a su soporte técnico, pídales un enrutador de reemplazo o algo así.