Vulnerabilidade do Wordpress - CRITICO

[NullRoute]

1 hora atrás, Jorge Marcelino disse:

Você só irá amenizar o problema com WAF e ajustes diretamente no servidor. Não há mágica, ontem foram mais de 8 mil IPs bloqueados em nossa proteção na nuvem. Os IPs que estão atacando (agents python) são detectados e descartados a conexão, então é capturado os IPs e enviados para a nuvem, assim o WAF já bloqueia antes mesmo de chegar no servidor e não ocorre sobrecarga alguma.

O maior problema de grande maioria é que não possuem um Firewall de Hardware e/ou um WAF externo que filtra a solicitação antes de chegar ao servidor.

1 hora atrás, brasilwebhost disse:

Como fez seu bloqueio? compartilha conosco, estou tendo o mesmo problema.

Você pode utilizar a regra do ModSec enviada pelo @sabenada e/ou também pode fazer uma configuração no seu Apache (caso o utilize) que foi a dica enviada pelo Delta Servers
 

SetEnvIfNoCase User-Agent "python-requests" bad_user
Deny from env=bad_user

 

[Jorge Marcelino]

53 minutos atrás, owsbr disse:

Você pode utilizar a regra do ModSec enviada pelo @sabenada e/ou também pode fazer uma configuração no seu Apache (caso o utilize) que foi a dica enviada pelo Delta Servers
 

SetEnvIfNoCase User-Agent "python-requests" bad_user
Deny from env=bad_user

 

Mas essas regras não vão causar sobrecarga do mesmo jeito? Você já testou?

[NullRoute]

4 minutos atrás, Jorge Marcelino disse:

Mas essas regras não vão causar sobrecarga do mesmo jeito? Você já testou?

Geram uma pequena sobrecarga sim! O problema é que nesse tipo de ataque ao travar o wp-login o ataque se volta "contra" a index do mesmo domínio causando sobrecarga do mesmo jeito.

O correto seria fazer como você, travar antes de chegar no servidor MAS essa possibilidade é para poucos.
 

SE tivesse como jogar tudo atrás do CloudFlare então seria possível ativar o Ratelimit deixando um valor extremamente baixo (2 tentativas) e também aplicar bloqueio de User-Agent (que é bem eficaz).

Editado Setembro 6, 2018 por owsbr
Informação adicional.

[LucianoZ]

2 horas atrás, owsbr disse:

Geram uma pequena sobrecarga sim! O problema é que nesse tipo de ataque ao travar o wp-login o ataque se volta "contra" a index do mesmo domínio causando sobrecarga do mesmo jeito.

O correto seria fazer como você, travar antes de chegar no servidor MAS essa possibilidade é para poucos.
 

SE tivesse como jogar tudo atrás do CloudFlare então seria possível ativar o Ratelimit deixando um valor extremamente baixo (2 tentativas) e também aplicar bloqueio de User-Agent (que é bem eficaz).

Sim, porque é muito acesso, o ideal é bloquear e exibir página default do Apache no lugar, evitar de isso chegar ate o WP, imagina ir mandando 300 a 400 conexões de uma só vez pra index, vai ir sobre carregando.
Quando você só nega o acesso ele redireciona para pagina 404 do wordpress o que não é tão bom.

[sabenada]

38 minutes ago, LucianoZ said:

Sim, porque é muito acesso, o ideal é bloquear e exibir página default do Apache no lugar, evitar de isso chegar ate o WP, imagina ir mandando 300 a 400 conexões de uma só vez pra index, vai ir sobre carregando.
Quando você só nega o acesso ele redireciona para pagina 404 do wordpress o que não é tão bom.

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.

 

 

[NullRoute]

1 hora atrás, LucianoZ disse:

Sim, porque é muito acesso, o ideal é bloquear e exibir página default do Apache no lugar, evitar de isso chegar ate o WP, imagina ir mandando 300 a 400 conexões de uma só vez pra index, vai ir sobre carregando.
Quando você só nega o acesso ele redireciona para pagina 404 do wordpress o que não é tão bom.

Perdoe minha ignorância, mas como seria feito isso?

Aqui por exemplo adicionei no httpd.conf as regras (Para Apache/2.4.6) para recusar as conexões..

No caso tudo que vier como python-request ele exibirá um erro 403 (até o momento).

 

<Directory "/home">
 SetEnvIfNoCase User-Agent "python-requests" bad_agent
  <RequireAll>
     Require all granted
     Require not env bad_agent
  </RequireAll>

 

[sabenada]

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)

 

[caiocaz]

Aqui

1 hora atrás, sabenada disse:

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)

 

Aqui também mesma coisa, atacou vários de nossos servidores. FTP (21), cPanel (2082) e MySQL (3306). tive que bloquear tudo.

O problema que ocorreu foi que usando o Engintron, o IP do próprio servidor acabada tendo milhares de conexões no apache, alguem saberia me dizer o que pode ser?

[NullRoute]

12 horas atrás, sabenada disse:

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)

 

Uma medida que tomei aqui foi alterar a porta de conexão do FTP para uma outra, como ele ataca de maneira automatizada então continuará tentando na 21 (que não há nada rodando) enquanto meus clientes (notificados) continuam com o serviço de FTP rodando sem grandes problemas.

 

[Jorge Marcelino]

12 horas atrás, brasilwebhost disse:

Aqui

Aqui também mesma coisa, atacou vários de nossos servidores. FTP (21), cPanel (2082) e MySQL (3306). tive que bloquear tudo.

O problema que ocorreu foi que usando o Engintron, o IP do próprio servidor acabada tendo milhares de conexões no apache, alguem saberia me dizer o que pode ser?

Um Firewall de borda resolve esse tipo de ataque e inclusive outros. Geralmente, os data centers possuem por um preço melhor.