Olá a todos,

Desde que me lembro ter servidores expostos na internet, que me lembro de sofrer ataques por brute force.
De ataques contra ssh, a brute force logins no wp-login.php, a ataques de dicionário ao saslauthd, já sofri de tudo.

Nestes casos, e infelizmente o que a maior parte das pessoas faz quando deteta o ataque, é colocar uma regra na firewall de perímetro a negar o acesso, ou simplesmente ignora (por desconhecimento ou wishfull thinking).

Isto é precisamente o que não se deve fazer. Se o ataque for de um ip dinâmico, um atacante realmente interessado irá voltar assim que o seu ip mudar. Não vou sequer referir o erro que é ignorar por completo o ataque a espera que o atacante vá embora.

Não se trata só e apenas de conseguirem o acesso aos dados, mas igualmente na lentidão de resposta que um ataque de brute force causa a um serviço.

Portanto, se houver necessidade real de ter um serviço exposto a internet (ou a redes inseguras) o melhor mesmo é ter um watchdog a trabalhar 24×7 mesmo quando não estamos no teclado.

No meu caso especifico, alem de um IDS ligado á firewall de perímetro que por si já debela alguns dos ataques, tenho em todos os servidores publicados na internet instalado o fail2ban.

É fail2ban é um log parser que lê em tempo real os logs que lhe sejam disponibilizados, e mediante o positivo ou não de um padrão de ataque definido (uma expressão regular) toma as ações pré definidas.

Embora pareça complexa é uma ferramenta extremamente simples de configurar e usar, e que irá poupar ao IT manager muita dor de cabeça.

Para começar, é necessário como sempre instalar o software (no meu caso a usar um openSuSE 13.2):

# zypper install fail2ban

Após a instalação, é necessário configurar o produto, estando os seus ficheiros de configuração em /etc/fail2ban:

xServer01:/etc/fail2ban # ll
total 36
drwxr-xr-x 2 root root  4096 Jun 17 12:26 action.d
-rw-r–r– 1 root root  1525 Jun 19 15:05 fail2ban.conf
drwxr-xr-x 2 root root  4096 Jul 17 21:15 filter.d
-rw-r–r– 1 root root 19641 Jul 28 06:41 jail.conf
xServer01:/etc/fail2ban #

Para já o ficheiro que nos interessa por se comportar como gatilho das ações é o jail.conf e la dentro iremos procurar a secção de ssh e alterar para a seguinte configuração:

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=[email protected], sender=[email protected], sendername=”Fail2Ban”]
logpath  = /var/log/messages
maxretry = 5
bantime  = 3600

O que foi feito: Colocado o enabled em true para que o fail2ban esteja a processar o log, desde o /var/log/messages, e à 5ª tentativa de acesso falhada do mesmo endereço irá colocar esse ip em blacklist através das iptables durante 3600 segundos.

Em seguida, como esta máquina é igualmente um servidor de email que envia emails autenticados usando o saslauthd é necessário igualmente proteger este componente:

[sasl-iptables]

enabled  = true
filter   = postfix-sasl
backend  = polling
action   = iptables[name=sasl, port=smtp, protocol=tcp]
sendmail-whois[name=sasl, dest=[email protected]]
logpath  = /var/log/mail
maxretry = 5
bantime = 7200

O que foi feito: Colocado o enabled em true para que o fail2ban esteja a processar o log, desde o /var/log/mail e à 5ª tentativa de acesso falhada do mesmo endereço irá colocar esse ip em blacklist através das iptables durante 7200 segundos.

Esta ação e a anterior são despoletadas pela secção filter que contem a expressão regular a filtrar nos logs.
Por exemplo no caso do postfix-sasl:

xServer01:/etc/fail2ban/filter.d # cat postfix-sasl.conf
# Fail2Ban filter for postfix authentication failures
#

[INCLUDES]
before = common.conf
[Definition]
_daemon = postfix/smtpd
failregex = ^%(__prefix_line)swarning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [ A-Za-z0-9+/]*={0,2})?\s*$
# Author: Yaroslav Halchenko

O fail2ban, utilizando o failregex procura uma expressão de SASL (com ou sem login, plain e referencia a cram, digest ou md5) pela expressão de falha na autenticação.
Caso a encontre, irá incrementar o mecanismo de defesa, ate atingir 5, altura em que o bloqueio automático será feito.

Uma das outras vantagens do fail2ban, é a possibilidade de que sejam construidas expressões para procurar eventos em logs, por exemplo de SQL injection ou outros.

Como tal, e como o wordpress onde está este blog é alvo preferencial de ataques, construi um template e jail para defesa do mesmo.
No jail.conf adicionei:

[wp-login]
enabled = true
filter = apache-wp-login
action = iptables-multiport[name=wp-login, port=”http,https”]
sendmail[dest=”[email protected]”, sendername=”Fail2Ban”, sender=”fail2ban”, name=”wp-login”]
logpath = /var/log/http/blog.nuneshiggs.com/access.log
maxretry = 5
bantime = 1200

Traduzindo: Colocado o enabled em true para que o fail2ban esteja a processar o log /var/log/http/blog.nuneshiggs.com/access.log, e à 5ª tentativa de acesso falhada do mesmo endereço irá colocar esse ip em blacklist através das iptables durante 1200 segundos.

É necessário claro colocar o próprio filtro no seu correto diretório -/etc/fail2ban/filter.d

# cat apache-wp-login.conf
# Create a filter called ‘apache-wp-login’
[Definition]
failregex = ^<HOST>.*] “POST /wp-login.php HTTP/.*” 200
# the above failregex will only find wp-login.php installed in the web root, use
# the following for instances where WordPress may be installed in a subdirectory
# failregex = ^<HOST>.*] “POST .*/wp-login.php HTTP/.*” 200
ignoreregex =
 
[INCLUDES]
before = apache-common.conf

Este filtro irá procurar eventos de wp-login.php (os mais comuns em brute force attack contra wordpress) e informar o mecanismo do fail2ban da sua ocorrência, causando que o mesmo seja debelado.

Finalmente, reiniciei o fail2ban para que ele carregasse as novas definições:

xServer01:# systemctl restart fail2ban
xServer01:# systemctl status fail2ban
fail2ban.service – Bans IPs with too many authentication failures
Oct 03 18:18:06 xServer01 fail2ban-client[15853]: 2015-10-03 18:18:06,526 fail2ban.server [15856]: INFO    Starting Fail2ban v0.8.14
Oct 03 18:18:06 xServer01 fail2ban-client[15853]: 2015-10-03 18:18:06,527 fail2ban.server [15856]: INFO    Starting in daemon mode

Como conclusão deste artigo, aponto a extrema versatilidade do fail2ban que pode ser alterado e acrescentado sem dificuldade para suportar praticamente todas as aplicações que comuniquem via TCP e tenham logs que sejam visualizáveis em texto.
Desde que o descobri tenho o usado em todos os meus servidores em que fechar as portas não é solução tendo em conta que tem *mesmo* de prestar serviço na internet.

Até a próxima, e já sabem, se tiverem duvidas estou sempre contactável através do email nuno at nuneshiggs.com.

Abraço.
Nuno

Bibliografia: http://www.fail2ban.org/wiki/index.php/Main_Page