Vulnerabilidade do Wordpress - CRITICO

[LucianoZ]

Saudações Senhores, estão sentido os efeitos de uma nova vulnerabilidade do wordpress?
Já vem decorrendo alguns dias um problema que esta afetando globalmente, visto em servidores dentro e fora do Brasil, não somente comigo mas com muitas outras pessoas que não há qualquer relação próxima.
O erro decorre de um flood excessivo sobre o wp-login.php na porta 80 que ocasiona altas cargas de load sobre o apache/mysql.
Mas alguem esta passando por isso?

Estarei postando já já a solução baseada em NGINX, pois até mesmo com cachewall não foi possível segurar, somente com NGINX.

[caiocaz]

Mesma coisa aqui.

Analisando soluções...

[Fernando Rafs]

Saudações Senhores, estão sentido os efeitos de uma nova vulnerabilidade do wordpress?
Já vem decorrendo alguns dias um problema que esta afetando globalmente, visto em servidores dentro e fora do Brasil, não somente comigo mas com muitas outras pessoas que não há qualquer relação próxima.
O erro decorre de um flood excessivo sobre o wp-login.php na porta 80 que ocasiona altas cargas de load sobre o apache/mysql.
Mas alguem esta passando por isso?

Estarei postando já já a solução baseada em NGINX, pois até mesmo com cachewall não foi possível segurar, somente com NGINX.

Todos os servidores aqui com WordPress, estão com o mesmo problema relatado, mesmo utilizando NGINX, não chega a derrubar os serviços, porém a carga aumentou bastante, mesmo com NGINX e para a porta seja ela 80 ou 8080.

Com todos que conversei, relataram a mesma coisa, sobre o tráfego anormal para o WordPress, alguns com pouca carga, outros com cargas altíssimas.

[LucianoZ]

Solução

 

Para resolver galera é bem simples, sabendo que:
- Todo trafego malicioso esta partindo para a porta 80 direcionada ao wp-login.php de todos sites
- Maioria dos wordpress hoje usam SSL( se não usam deveriam rs)
- Fazer uma camada de bloqueia sobre a porta 80 no wp-login.php

Estou aqui agora apresentando como eliminar esse problema, mas terão que usar Engintron, só consigo informar para regex de NGINX.

Necessário:
- Engintron
- PHP Open Base Dir(off)
- Porta 8080 e 8443 liberadas

Após instalar o Engintron siga os passos:

• Menu NGINX
• Edit default.conf
• Acrescente o código abaixo após a linha 40

#Bloquear WP-LOGIN
location = /wp-login.php {
	deny all;
}

Por padrão as regras aplicadas nesse arquivos só valem para a porta 80.
Retirando assim todo tráfego malicioso negando o acesso ao wp-login.php

Espero que seja útil a todos isso.

[sabenada]

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.

 

[Fernando Rafs]

18 minutos atrás, LucianoZ disse:

Solução

 

Para resolver galera é bem simples, sabendo que:
- Todo trafego malicioso esta partindo para a porta 80 direcionada ao wp-login.php de todos sites
- Maioria dos wordpress hoje usam SSL( se não usam deveriam rs)
- Fazer uma camada de bloqueia sobre a porta 80 no wp-login.php

Estou aqui agora apresentando como eliminar esse problema, mas terão que usar Engintron, só consigo informar para regex de NGINX.

Necessário:
- Engintron
- PHP Open Base Dir(off)
- Porta 8080 e 8443 liberadas

Após instalar o Engintron siga os passos:

• Menu NGINX
• Edit default.conf
• Acrescente o código abaixo após a linha 40

#Bloquear WP-LOGIN
location = /wp-login.php {
	deny all;
}

Por padrão as regras aplicadas nesse arquivos só valem para a porta 80.
Retirando assim todo tráfego malicioso negando o acesso ao wp-login.php

Espero que seja útil a todos isso.

Primeiramente, simples porém ótima contribuição.

Apenas uma dúvida.

O seu default ficou assim:

}
    }

    location = /whm-server-status {
        proxy_pass http://127.0.0.1:8080; # Apache Status Page
        # Comment the following 2 lines to make the Apache status page public
        allow 127.0.0.1;
        deny all;
    }
    #Bloquear WP-LOGIN
    location = /wp-login.php {
	deny all;
    }
}

 

[LucianoZ]

2 minutos atrás, sabenada disse:

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.

 

é uma boa, mas acho que negar o acesso totalmente seria mais viável.
No Engintron acabou que resolveu 100% o problema.

Agora, Fernando Rafs disse:

Primeiramente, simples porém ótima contribuição.

Apenas uma dúvida.

O seu default ficou assim:

}
    }

    location = /whm-server-status {
        proxy_pass http://127.0.0.1:8080; # Apache Status Page
        # Comment the following 2 lines to make the Apache status page public
        allow 127.0.0.1;
        deny all;
    }
    #Bloquear WP-LOGIN
    location = /wp-login.php {
	deny all;
    }
}

 

Correto é assim mesmo.

[caiocaz]

1 minuto atrás, sabenada disse:

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.

 

Sim são do Brasil mesmo, mas o padrão de horário pra mim é diferente, cada servidor sofre em um horário diferente, temos servidores em várias localidades e todos estão apresentando o problema. Como o @LucianoZ e vc disse.

[Fernando Rafs]

Aqui a mesma coisa, sem padrão de horário.

Já tentamos com Regras ModSecurity + Antimalware com Brute Force Ativo + Nginx, segura bastante, porém mesmo assim a carga vai nas alturas, não derruba os serviços, mas é uma carga atípica.

Agora irei testar a dica e solução do nosso amigo @LucianoZ que contribuiu conosco sua solução.

8 minutos atrás, LucianoZ disse:

é uma boa, mas acho que negar o acesso totalmente seria mais viável.
No Engintron acabou que resolveu 100% o problema.

Correto é assim mesmo.

Obrigado @LucianoZ

[LucianoZ]

Agora, Fernando Rafs disse:

Aqui a mesma coisa, sem padrão de horário.

Já tentamos com Regras ModSecurity + Antimalware com Brute Force Ativo + Nginx, segura bastante, porém mesmo assim a carga vai nas alturas, não derruba os serviços, mas é uma carga atípica.

Agora irei testar a dica e solução do nosso amigo @LucianoZ que contribuiu conosco sua solução.

Sim modSecurity também não resolve, unica coisa que resolveu foi o regex.
Depois deixe seu feedback se resolveu totalmente.