Regra do fail2ban para ajudar nos ataques de GET Flood

Muita gente anda preocupada com alguns ataques de get flood que andam acontecendo em diversos servidores na internet nos últimos tempos. Alguns blogs grandes como sedentario.org , ahnegao.com.br e outros chegaram a ter quedas nos seus servidores devido a este tipo de ataque.

Primeiro, muita gente se perguntará. O que é o GET flood ?

Quando você faz uma requisição a um servidor web via seu navegador ela pode ser de vários tipos, sendo os dois principais POST e GET. A solicitação GET é que é o usada para “links normais”, incluindo imagens, páginas web, que em geral são feitos para recuperar um dado estático ou seja, a url que aponta para os dados. Ou seja, quando você digita um endereço de página no seu navegador é com esta requisição GET que você recebe a resposta e vê a página.

E o GET Flood inunda teu site

E o GET Flood inunda teu site

O GET Flood é especificamente quando um indivíduo utilizando uma botnet começa a enviar diversas requisições a um endereço específico do site visando parar todo o funcionamento dele. Como hoje boa parte dos sites utiliza o WordPress ou outro tipo de CMS cada requisição tende a usar muitos recursos do disco ou então, a utilizar também uma base de dados ou até causar exaustão no servidor web.

Este é o GET Flood. É no fim inundar o seu servidor de requisições e ele não consegue processar tanta gente ao mesmo tempo em cima dele pedindo o mesmo recurso.

Como este tipo de ataque não utiliza nenhum pacote inválido ou até, alguma técnica diferente do que normalmente um servidor web recebe a sua mitigação é muito mais difícil.

Ou seja, o servidor alvo é bombardeado com pedidos básicos de GET. Eles utilizam normalmente alguma requisição no blog que causa exaustão fácil de recursos ( como consultas grandes a base de dados e memória do servidor ).

Em geral nestes ataques são utilizados botnets porque as requisições ficam distribuídas entre um número enorme de ips.

O problema dos ataques de inundação são meio chatos de se descobrir porque no fim são requisições válidas. Como elas podem causar uma ilusão nos IDS no fim temos que ficar igual loucos tentando diferenciar as requisições GET em momentos normais do servidor e em momentos de pico como estes ( que em geral causam queda generalizada do servidor e, no fim, um stress enorme ).

Um método seria a tentativa de detecção de redes Zumbi ( em breve postarei mais sobre isto ) mas há um pequeno hackzinho que foi postado em listas que pode lhe ajudar talvez neste tipo de problema.

O método utiliza o fail2ban e é bem simples de implementar. Adicione no seu arquivo jail.conf as seguintes linhas :

[anti-flood]
enabled = true
port = http,https
action = iptables-multiport[name=flood, port="http,https", protocol=tcp]
sendmail-whois[name=antiflood, [email protected], [email protected]]
filter = anti-flood
logpath = /usr/local/apache/domlogs/*.*
maxretry = 300
findtime = 60
bantime = 86400

 

Depois crie um arquivo no diretorio /etc/fail2ban/conf.d de nome anti-flood.conf com o seguinte conteúdo :

# Fail2Ban configuration file
#
# Author: http://www.go2linux.org
#
[Definition]# Option: failregex
# Note: This regex will match any GET entry in your logs, so basically all valid and not valid entries are a match.
# You should set up in the jail.conf file, the maxretry and findtime carefully in order to avoid false positives.failregex = ^ -.*GET# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =

 

Esta configuração talvez lhe ajude um pouco nos problemas, mas sempre é bom ter um contato bom com o seu provedor para talvez tentar adicionar rotas nulas nos roteadores de borda para evitar esgotamento da sua banda útil.