
Al hacer un ps -efH
veo 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.log
en 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.log
usando 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 root
cuenta? En cualquier sistema que configure, root
lo castran de inmediato. Así que en mi caso estos intentos resultaron infructuosos. Entonces, si revisa su cuenta auth.log
y ve toneladas de intentos de ssh
ingresar al sistema a través de la root
cuenta, asegúrese de que la root
cuenta de su sistema esté completamente deshabilitada para eliminar esa preocupación de la lista.
Más allá de los root
intentos 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 root
cuenta de usuario deshabilitada. Si todavía opera un servidor público en 2015 con la root
cuenta habilitada, básicamente estará sufriendo dolores de cabeza a largo plazo.