¿Hay muchos procesos sshd/root enumerados por ps, intento de pirateo SSH de fuerza bruta?

¿Hay muchos procesos sshd/root enumerados por ps, intento de pirateo SSH de fuerza bruta?

Al hacer un ps -efHveo muchos de los siguientes, donde 14:24 es básicamente la hora actual del sistema. Estos procesos siguen apareciendo cada minuto.

root      6851     1  0 14:24 ?        00:00:00   sshd: root [priv]
sshd      6852  6851  0 14:24 ?        00:00:00     sshd: root [net]
root      6869  6851  1 14:24 ?        00:00:00     sshd: root [pam]
root      6861     1  0 14:24 ?        00:00:00   sshd: root [priv]
sshd      6863  6861  0 14:24 ?        00:00:00     sshd: root [net]
root      6874  6861  0 14:24 ?        00:00:00     sshd: root [pam]
root      6865     1  0 14:24 ?        00:00:00   sshd: root [priv]
sshd      6866  6865  0 14:24 ?        00:00:00     sshd: root [net]
root      6875  6865  0 14:24 ?        00:00:00     sshd: root [pam]
root      6872     1  1 14:24 ?        00:00:00   sshd: root [priv]
sshd      6873  6872  0 14:24 ?        00:00:00     sshd: root [net]
root      6876  6872  0 14:24 ?        00:00:00     sshd: root [pam]

¿Significa esto que alguien está intentando forzar la contraseña de root en esta máquina a través de SSH? ¿O es algo menos nefasto?

Respuesta1

¿Significa esto que alguien está intentando forzar la contraseña de root en esta máquina a través de SSH? ¿O es algo menos nefasto?

Podrían ser intentos de entrada por fuerza bruta a través de SSH, pero incluso si fuera "nefasto", no me quitaría el sueño. La mayoría de los servidores a los que se puede acceder públicamente en Internet son investigados por atacantes todo el tiempo. Alguien que prácticamente “recubre el porro” no es algo que le quite el sueño; La penetración real del sistema es.

Diablos, acabo de verificar auth.logen un servidor público que administro y cuento más de 2000 intentos de "errores de autenticación" en las últimas 24 horas cuando ejecuto este comando:

sudo grep "authentication failure;" /var/log/auth.log | wc -l

Suena aterrador pero, sinceramente, ¿a quién le importa? Una verificación visual rápida de las entradas del registro auth.logusando una versión ligeramente modificada del comando anterior:

sudo grep "authentication failure;" /var/log/auth.log

...me muestra cosas como esta:

Mar 15 07:02:09 hostname sshd[2213]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.35  user=root
Mar 15 07:02:19 hostname sshd[2236]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.35  user=root
Mar 15 07:02:31 hostname sshd[2355]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.35  user=root

¿Observa que todos los intentos de acceso están en la rootcuenta? En cualquier sistema que configure, rootlo castran de inmediato. Así que en mi caso estos intentos resultaron infructuosos. Entonces, si revisa su cuenta auth.logy ve toneladas de intentos de sshingresar al sistema a través de la rootcuenta, asegúrese de que la rootcuenta de su sistema esté completamente deshabilitada para eliminar esa preocupación de la lista.

Más allá de los rootintentos de cuenta, si ve accesos de nombres de usuario aparentemente aleatorios a su sistema, eso también es otro intento de piratear el sistema. Y a menos que esos nombres de usuario equivalgan a algún nombre de usuario en su sistema, tampoco me preocuparía en absoluto por ellos.

Ahora bien, algunos administradores de sistemas dirían que la mejor solución a este problema es simplemente deshabilitar completamente la autenticación de contraseña desde SSH y usar solo pares de claves SSH, pero tiendo a pensar que eso es excesivo. No digo que los pares de claves SSH sean débiles (no lo son), pero si los métodos de acceso de un sistema se configuran de manera sensata y segura desde el primer día, y las contraseñas son lo suficientemente sólidas como para no ser pirateadas fácilmente, entonces el sistema es bastante seguro. Esto se debe a que la mayor vulnerabilidad en los servidores web modernos es la aplicación web frontal que realmente se ejecuta en el servidor y no cosas como SSH.

Al final del día, no me preocuparía por este tipo de intentos aleatorios de “marcación de guerra”, sino que sería preventivamente racional al asegurarme de que el servidor tenga la rootcuenta de usuario deshabilitada. Si todavía opera un servidor público en 2015 con la rootcuenta habilitada, básicamente estará sufriendo dolores de cabeza a largo plazo.

información relacionada