GNU/Linux >> Tutoriales Linux >  >> Linux

Extraño SSH, seguridad del servidor, podría haber sido pirateado

Solución 1:

La firma de ClamAV para Unix.Trojan.Mirai-5607459-1 es definitivamente demasiado amplia, por lo que es probable que sea un falso positivo, como señalaron J Rock y cayleaf.

Por ejemplo, cualquier archivo que tenga todas las siguientes propiedades coincidirá con la firma:

  • es un archivo ELF;
  • contiene la cadena "perro guardián" exactamente dos veces;
  • contiene la cadena "/proc/self" al menos una vez;
  • contiene la cadena "busybox" al menos una vez.

(Toda la firma es un poco más complicada, pero las condiciones anteriores son suficientes para una coincidencia).

Por ejemplo, puede crear un archivo de este tipo con:

$ echo 'main() {printf("watchdog watchdog /proc/self busybox");}' > innocent.c
$ gcc -o innocent innocent.c
$ clamscan --no-summary innocent
innocent: Unix.Trojan.Mirai-5607459-1 FOUND

Cualquier compilación de busybox (en Linux) generalmente coincidirá con las cuatro propiedades que enumeré anteriormente. Obviamente es un archivo ELF y definitivamente contendrá la cadena "busybox" muchas veces. Ejecuta "/proc/self/exe" para ejecutar ciertos applets. Finalmente, "perro guardián" aparece dos veces:una como nombre de subprograma y otra dentro de la cadena "/var/run/watchdog.pid".

Solución 2:

Al igual que J Rock, creo que esto es un falso positivo. Yo tuve la misma experiencia.

Recibí una alarma de 6 servidores diferentes, dispares y separados geográficamente en un corto período de tiempo. 4 de estos servidores solo existían en una red privada. Lo único que tenían en común era una actualización reciente de daily.cld.

Entonces, después de verificar algunas de las heurísticas típicas de este troyano sin éxito, inicié una caja vagabunda con mi línea de base limpia conocida y ejecuté freshclam. Esto agarró

"daily.cld está actualizado (versión:22950, ​​firmas:1465879, nivel f:63, constructor:neo)"

Un clamav /bin/busybox posterior devolvió la misma alerta "/bin/busybox Unix.Trojan.Mirai-5607459-1 FOUND" en los servidores originales.

Finalmente, en buena medida, también hice una caja vagabunda de la caja oficial de Ubuntu y también obtuve el mismo "/bin/busybox Unix.Trojan.Mirai-5607459-1 FOUND" (Nota, tuve que aumentar la memoria en esta caja vagabunda desde sus 512 MB predeterminados o clamscan falló con 'matado')

Salida completa de la nueva caja vagabunda de Ubuntu 14.04.5.

[email protected]:~# freshclam
ClamAV update process started at Fri Jan 27 03:28:30 2017
main.cvd is up to date (version: 57, sigs: 4218790, f-level: 60, builder: amishhammer)
daily.cvd is up to date (version: 22950, sigs: 1465879, f-level: 63, builder: neo)
bytecode.cvd is up to date (version: 290, sigs: 55, f-level: 63, builder: neo)
[email protected]:~# clamscan /bin/busybox
/bin/busybox: Unix.Trojan.Mirai-5607459-1 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 5679215
Engine version: 0.99.2
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 1.84 MB
Data read: 1.83 MB (ratio 1.01:1)
Time: 7.556 sec (0 m 7 s)
[email protected]:~#

Entonces, también creo que es probable que sea un falso positivo.

Diré que rkhunter no dame la referencia:"/usr/bin/lwp-request Warning", así que tal vez PhysiOS Quantum tenga más de un problema.

EDITAR:acabo de notar que nunca dije explícitamente que todos estos servidores son Ubuntu 14.04. ¿Otras versiones pueden variar?

Solución 3:

Esto también me apareció hoy en mi escaneo ClamAV para /bin/busybox. Me pregunto si la base de datos actualizada tiene un error.

Solución 4:

Intenté iniciar sesión a través de SSH y no aceptaba mi contraseña. El inicio de sesión raíz está deshabilitado, así que fui a rescatar y encendí el inicio de sesión raíz y pude iniciar sesión como raíz. Como root, intenté cambiar la contraseña de la cuenta afectada con la misma contraseña con la que había intentado iniciar sesión antes, passwd respondió con "contraseña sin cambios". Luego cambié la contraseña a otra y pude iniciar sesión, luego cambié la contraseña a la contraseña original y pude iniciar sesión nuevamente.

Esto suena como una contraseña caducada. Establecer la contraseña (con éxito) por root restablece el reloj de vencimiento de la contraseña. Tú podrías compruebe /var/log/secure (o el equivalente de Ubuntu) y descubra por qué se rechazó su contraseña.


Linux
  1. SSHPass:cómo acceder a un servidor mediante SSH mediante un script sin contraseña (no de forma interactiva)

  2. [Linux]:¡Las 12 principales funciones de seguridad para habilitar en el servidor SSH!

  3. Ssh:¿script de shell para iniciar sesión en un servidor Ssh?

  4. ¿Cómo restablecer la contraseña de administrador de Plesk usando SSH en el servidor Linux?

  5. Configuración de seguridad IP en IIS

Tunelización y proxy SSH

Servidor SSH

Cómo SSH al servidor a través de Linux

¿Cómo copiar archivos de forma remota a través de SSH sin ingresar su contraseña?

Configurar la seguridad básica

Nombre de usuario y contraseña en la línea de comandos con sshfs