¿Cómo puedo determinar de dónde provienen los intentos de inicio de sesión de ssh?

1

Habíamos estado probando una instancia de AWS para acceder a un servidor interno de Ubuntu 10.04.3, por lo que habíamos modificado nuestro firewall para permitir que todos los puertos de esa dirección IP específica llegasen al servidor. Luego lanzamos la instancia de AWS, pero se olvidó de eliminar la regla del firewall.

Ayer, alguien notó intentos fallidos de inicio de sesión en auth.log que provenían de varias ubicaciones de China y Corea (según whois.sc). Así que eliminamos la regla de firewall y los intentos de inicio de sesión se detuvieron.

Aquí hay una sección de auth.log que muestra un intento fallido de inicio de sesión:

Feb 23 12:33:15 TestServer1 sshd[18822]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=117.21.226.10  user=root
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): getting password (0x00000388)
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): pam_get_item returned a password
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error message was: No such user
Feb 23 12:33:17 TestServer1 sshd[18822]: Failed password for root from 117.21.226.10 port 2539 ssh2

Obviamente, dado que la regla de firewall todavía estaba en su lugar para la instancia de AWS, estaba permitiendo el tráfico para esa IP, pero me pregunto cómo la IP externa 117.21.226.10 estaba accediendo a nuestro servidor interno. ¿Es posible que sea una IP falsa y no el originador real? Si eso es cierto, ¿no significa que Amazon permite paquetes falsificados en su red?

No soy el tipo de configuración de red aquí, y me pregunto por mi propio beneficio, así que discúlpeme si esta es una pregunta noob.

    
pregunta Alan 26.02.2014 - 19:01
fuente

2 respuestas

1

No, las conexiones TCP no se pueden falsificar [*] . TCP requiere una comunicación bidireccional, por lo que sus paquetes de respuesta deben regresar a la fuente y ser reconocidos antes de que su conexión pueda continuar. Para saber con casi certeza que el tráfico le está siendo enviado por esa dirección.

Dicho esto, no puede garantizar que el tráfico se origine en la dirección en cuestión. Solo sabe que la dirección que encontró es el "último salto" que el tráfico toma antes de llegar a usted. Los atacantes con frecuencia despedirán sus conexiones de servidores comprometidos o utilizarán servidores pirateados en otros centros de datos para realizar ataques automatizados.

Por lo tanto, la dirección que ves generalmente representa a otra víctima del mismo atacante, cuyos recursos ahora se están utilizando para hacer la ubicación del atacante.

icono de la línea de datos> * * * * * Técnicamente, puedes simular paquetes TCP, pero para hacerlo tienes que estar en algún lugar de la ruta que los paquetes TCP hubieran tomado. Por ejemplo, su ISP puede falsificar el tráfico desde cualquier lugar, pero un servidor en Brasil que se comunique con usted en Amsterdam podría tener problemas para falsificar una dirección en China.

    
respondido por el tylerl 27.02.2014 - 23:53
fuente
1

Como dijo Ladadadada, la IP registrada por SSH era de hecho la dirección del sistema atacante.

Hablé con nuestro tipo de red y él configuró una asignación Uno a Uno de la dirección IP de la instancia de AWS a una IP externa en nuestro firewall que apuntaba a nuestro servidor interno.

192.168.30.36 <-- 123.123.123.123 (our external ip) <-- Internet <-- Amazon IP

Él cree que cuando lanzamos la instancia de AWS, alguien más tarde obtuvo una nueva instancia con esa misma IP. Utilizaron la instancia como una puerta de acceso para los robots que probaron la red y encontraron nuestro servidor.

    
respondido por el Alan 26.02.2014 - 20:22
fuente

Lea otras preguntas en las etiquetas