sabenada
Membro-
Postagens
11 -
Registro em
-
Última visita
-
bom, o malandro voltou desde ontem. agora ele só faz o brute-force em cima do wordpress, desistiu do brute-force no cpanel e ftp. mas o modo é o mesmo: - todos IP's do Brasil - script com agent python-request 2.8 - centenas de acessos por segundo, só no wordpress em nossos servidores hoje ele chegou com força em 6 sites. o mod_security está bloqueando tudo, a botnet dele chega é bloqueada no mod_security - mas como é um ataque bem mal feito, o cara perde tempo fazendo brute-force mas não verifica o retorno - fica lá batendo cabeça tomando 403 do mod_security. menos mal.
-
Não é CSF bugado não, o ataque desta botnet é 100% com IP's do Brasil. E vai em cima do wordpress + ftp + cpanel + mysql, muitas vezes tudo ao mesmo tempo - outras vezes só no wordpress. Observar que a botnet não sabe o login de FTP/CPANEL, se voce olhar os logs de FTP, verá que a botnet escolhe um domínio hospedado mas fica tentando vários logins comuns ao domínio, exemplo se o domínio é fulano.com.br, a botnet tenta logar no FTP com "fulano" e "fulanocombr" e "wwwfulano" etc. Enfim, vamos ver até onde o manolo vai com esta brincadeira.
-
boa noite colegas, após ficar sem agir desde quinta-feira, o desocupado voltou do feriadão e já começou a trabalhar. a botnet agora a noite voltou a agir, atacou um dos meus servidores, tudo IP do Brasil, mas agora mudou a tática: desistiu do wordpress e fica fazendo brute-force no FTP E CPANEL ao mesmo tempo. acho que o desocupado percebeu que é infrutífero o brute-force no wordpress (devido ao mod-security e outras medidas). bom, comigo ele se lasca, porque eu simplesmente fechei a porta do FTP e CPANEL - nem ele e nem ninguém vai logar. meus clientes que quiserem usar o CPANEL e FTP me informam o IP e eu abro no firewall - uma medida chata, mas que garante a segurança e estabilidade do servidor, até a botnet desistir - o que normalmente ocorre em poucas horas. enfim vamos em frente, observem seus logs de FTP e de acesso ao CPANEL (/usr/local/cpanel/logs/access_log)
-
Depende como está bloqueando o ataque. No meu mod_security se a botnet não é redirecioanda para index.php, a resposta do apache é erro 302, que é uma página de erro html pura do apache, e não php do site do cliente.
-
Bom dia. O problema de ataque a brute-force no wordpress já tem muitos anos. Este tipo de ataque é comum, lidamos com ele diariamente. A diferença agora, é que existe uma botnet brasileira, fazendo ataques diários e com muitos IP's de origem. A técnica é a mesma de anos atrás. Como fiz: WHM como root -> mod_security tools -> RULES LIST -> ADD RULE no campo RULE TEXT SecRule REQUEST_HEADERS:User-Agent "(python-requests)" \ "id:123457,phase:1,t:none,t:lowercase,block,tag:BOT,msg:'botnetBR blocked'" Abaixo marque as duas caixas "Enable Rule" e "Deploy and Restart Apache" A partir disso o mod_security vai impedir que esta botnet acesse arquivos no servidor. Mas isso não bloqueia o acesso da botnet ao servidor, a carga vai continuar alta. Porém ajuda a proteger seus clientes e desestimula a botnet.
-
Josuel, é verdade, o agent é sempre o python-requests/2.18.4 foi o que bloqueamos via mod_security e com isso não dá retorno a botnet. e sim, são muitos IP's, chego a pensar se o desocupado não achou uma forma de fazer spoof dos IP's de origem, usando vários ranges brasileiros.
-
Colega, vou dizer... no início deste ataque, coisa de 30 dias atrás, esta botnet fazia bruteforce no WORDPRESS + FTP + CPANEL. Quando o ataque iniciava em um site, a botnet simultaneamente tentava login no FTP e no CPANEL. A carga explodia. Depois de 5 ou 6 dias o desocupado mudou a tática, desistiu do FTP+CPANEL, provavelmente porque o firewall bloqueia após X tentativas, e focou somente no WORDPRESS. O que me impressiona é como o cara tem inteligência para fazer isso, tem tempo livre - porque não faz algo produtivo? Porque não cria algo para ele? Mesmo que seja um script-kid (bem provável), o cara tem algum neurônio funcionando, podia trabalhar e ganhar algum dinheiro sem encher o saco dos outros. O pior é que o ataque dele é meio inútil, aqui eu uso mod_security que está bloqueando todos os hits dele, ou seja a botnet dele não consegue acesso ao wp-login.php. O cara tá lá perdendo tempo. Enfim, vamos ver até onde ele vai.
-
Exato colega, chama atenção é isso, uma botnet 100% BR. E vou te dizer, eu venho coletando todos os IP's da botnet - eliminando os duplicados já tenho 21.000 IP's. Claro que a maioria é IP dinamico, mas mesmo assim é muita máquina infectada, mesmo que seja só 10% disso o cara tem uma botnet de 2.000 máquinas. Outra informação: hoje a botnet saiu do padrão do horário, já não atacou "somente após as 14hs" - hoje iniciou o ataque as 06h.
-
Aqui o mod_security "apenas" devolve a botnet erro http, não deixando a botnet acessar o wp-login.php. Ou seja, a botnet perde tempo - e desestimula a botnet continuar - mas é claro, o mod_security não vai impedir da botnet sobrecarregar o servidor. Além disso o mod_security está impedindo que a botnet tenha sucesso, porque se algum cliente colocar senha "abc123" iria ter o site hackeado. Mas pelo visto cada caso é um caso.
-
Eu agradeço a dica do LucianoZ porém aqui o ataque chega na porta 80 e 443, ou seja com ou sem SSL. Se fosse só na porta 80 uma regra no apache/nginx etc resolvia o problema, mas não é. Não está fácil bloquear de vez.
-
Pessoal, vou compartilhar minha experiência sobre o que vem ocorrendo. Nas últimas 3 ou 4 semanas, algum desocupado montou uma botnet 100% baseada em máquinas brasileiras, todas tem IP do Brasil. Todos os dias úteis, após as 14hs (brasilia/df) a botnet começa o ataque, sempre fazendo brute-force em cima do wp-login.php. Não há um padrão, tem diz que recebemos ataque em cima de 1 site, mas tem dia que é em cima de 10 ou 12 sites (distribuídos em nossos servidores). Eu fiz uma regra via mod_security que detecta o padrão de acesso da botnet e faz o bloqueio, retornando 302 para ele, mas mesmo assim a botnet é meia burrinha, fica tentando o brute-force mesmo recebendo erro de retorno. Passa algumas horas e a botnet desiste. Mas a carga é elevada, 1 ou 2 sites, sem problemas - mas quando calha da botnet pegar 8, 10 sites no mesmo servidor a carga vai lá em cima, só não cai tudo porque o cloudlinux limita bem, sem deixar a máquina sobrecarregar ao extremo. Aqui o burro da botnet se lasca, só perde tempo, porque o mod_security segura tudo. Reparei que o desocupado não ativa a botnet aos sábados e domingos, é somente dia útil e após as 14hs. Reparem nos logs de vocês, verifiquem os IPs - vejam se os IP's são do Brasil.