SSH MITM ataque en curso

4

ACTUALIZACIÓN: afortunadamente, la fuente de este problema ha resultado ser un cliente SSH móvil con errores que se utiliza en 2 dispositivos diferentes, no en un ataque MITM. Sin embargo, todavía agradecería una respuesta completa a la pregunta original: a saber, en el caso de un ataque MITM genuino , ¿qué pasos debe tomar un administrador después de detectarlo ? ¿La presencia de un atacante MITM genuino hace que el acceso SSH a ese servidor sea imposible en la medida en que intente interceptar el tráfico? ¿Está cambiando el puerto sshd como respuesta?

PREGUNTA ORIGINAL: Apreciaría algunos consejos sobre qué pasos debo tomar para lidiar con esto.

Al intentar conectarme hoy a mi servidor doméstico a través de SSH mediante la autenticación de clave de pub (el acceso con contraseña está desactivado), recibí el mensaje "la huella digital ha cambiado". Como tengo una copia de la huella digital de la clave pública del servidor, puedo ver que no coinciden.

¿Esto significa que no puedo conectarme al servidor a través de SSH indefinidamente sin poner en peligro la seguridad? ¿Puedo combatir el ataque de alguna manera? Si bien siempre he estado al tanto del potencial de los ataques MITM con SSH y hay un montón de lecturas disponibles en detectar tal ataque, no puedo encontrar ningún consejo sobre contrarrestarlo / lidiar con él una vez que esté en marcha.

Gracias de antemano.

ACTUALIZACIÓN: La clave pública del host SSH y la copia que tengo son idénticas. Pero cuando se conecta de forma remota (utilizando DDNS o IP directa), el mensaje "No se puede establecer la autenticidad del host" muestra una huella digital diferente a la del servidor. De ahora en adelante, necesito consejos sobre cómo me conecto al servidor a través de SSH a la luz de que alguien puede estar haciendo algo nefasto. ¿Simplemente cambio el puerto del servidor SSH? ¿Debo generar nuevas claves?

    
pregunta py4on 17.05.2014 - 13:29
fuente

1 respuesta

2

Si tiene acceso físico al servidor, inicie sesión en su consola y vea si la clave pública del servidor ha cambiado. Si ha cambiado, intente averiguar por qué; si no lo ha hecho, esto significa que cuando intenta conectarse a su servidor con SSH, en realidad está hablando con otra máquina, posiblemente debido a un intento de ataque continuo, pero más probablemente debido a alguna configuración incorrecta del enrutamiento o DNS.

Para los servidores alojados, el proveedor debe ofrecer algún KVM basado en IP o un sistema de rescate que sea equivalente al acceso físico (en ese contexto).

    
respondido por el Tom Leek 17.05.2014 - 15:04
fuente

Lea otras preguntas en las etiquetas