Em resumo: uma proteção eficaz contra brute force num login é feita de várias camadas: autenticação de dois fatores para todos os administradores, um travão para as tentativas de login no servidor web, bloqueios automáticos ao nível da rede e um armazenamento seguro das palavras-passe no código. Sempre que possível, a área de administração deve ainda ser acessível apenas a partir de redes conhecidas.
Como decorrem os ataques de brute force a logins
Qualquer página de login acessível publicamente é atacada, mais cedo ou mais tarde, de forma automatizada. Isto afeta logins de CMS, backends de lojas, painéis de alojamento, webmail e SSH. Os atacantes não precisam de saber a quem pertence o site; as suas ferramentas vasculham a Internet à procura de endereços de login conhecidos.
Há três variantes comuns. No brute force clássico, são experimentadas muitas palavras-passe contra uma conta. No password spraying, uma palavra-passe comum é testada contra muitas contas, para contornar bloqueios. No credential stuffing, são usadas credenciais roubadas noutros serviços.
Para a gestão e os proprietários, a situação resume-se facilmente: uma conta de administrador assumida é tão perigosa como uma vulnerabilidade de segurança no servidor. Quem é administrador pode instalar extensões, alterar código e exportar dados.
Estes ataques reconhecem-se por uma acumulação de inícios de sessão falhados, por pedidos POST ao endereço de login a partir de muitos endereços IP diferentes e por tentativas de login com nomes de utilizador como “admin” ou nomes que constam do aviso legal. Uma carga do servidor claramente mais alta a horas invulgares também pode indicá-lo, porque cada login custa tempo de computação para a verificação da palavra-passe.
Proteção contra brute force no login: as medidas mais eficazes
Nem todas as medidas se adequam a todos os sistemas. A sequência seguinte tem-se revelado eficaz, porque os primeiros pontos combinam o maior efeito com pouco esforço:
- Autenticação de dois fatores para todas as contas com permissões de administrador. Mesmo uma palavra-passe adivinhada deixa então de bastar. Pormenores no guia Autenticação de dois fatores para acessos de administração.
- Palavras-passe únicas e longas de um gestor de palavras-passe, sem contas partilhadas.
- Rate limiting no servidor web, para que por endereço sejam possíveis poucas tentativas por minuto.
- Bloqueios automáticos de endereços repetidamente suspeitos ao nível da rede, por exemplo com o Fail2ban.
- Reduzir a área de administração: acesso apenas a partir da rede da empresa ou por VPN, desativar as interfaces desnecessárias.
- Mensagens de erro uniformes, que não revelem se o nome de utilizador existe.
- Monitorização dos inícios de sessão falhados e notificação em caso de anomalias.
Rate limiting no servidor web
Com o Nginx, é possível limitar por endereço IP o número de pedidos a um endereço de login. O exemplo mostra uma página de login do WordPress; adapte o caminho e a passagem para o PHP ao seu sistema.
# no bloco http
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
# no bloco server
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
# incluir aqui a passagem habitual para o PHP do seu servidor
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
No Apache, restringir a área de administração a endereços conhecidos oferece uma proteção simples e eficaz:
<Location "/admin">
Require ip 192.0.2.0/24
</Location>
O endereço 192.0.2.0/24 é um marcador do intervalo reservado para documentação; indique a rede da sua empresa ou o endereço da sua VPN. Se o seu site estiver atrás de um proxy ou CDN, o servidor tem de conhecer o endereço real do visitante, caso contrário a regra não funciona como desejado.
Fail2ban e bloqueios ao nível da rede
O Fail2ban lê ficheiros de registo e bloqueia na firewall, durante um tempo definido, os endereços que se tornam repetidamente suspeitos. Para o rate limiting do Nginx, o Fail2ban já traz um filtro adequado:
# /etc/fail2ban/jail.local
[nginx-limit-req]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 10
findtime = 10m
bantime = 1h
[sshd]
enabled = true
maxretry = 5
bantime = 1h
Após o reinício, verifique com fail2ban-client status se as jails estão ativas. Tenha o cuidado de excluir os seus próprios endereços fixos através de ignoreip, para não se bloquear a si próprio. Para as páginas de login de CMS individuais são possíveis filtros próprios, mas têm de se adequar ao formato real do registo e ser testados antes.
Se à frente do servidor estiver um CDN ou proxy, o Fail2ban, sem mais definições, só vê os endereços deste. Um bloqueio atingiria então todos os visitantes. Neste caso, o servidor web tem de assumir o endereço real do visitante a partir do cabeçalho do serviço intermédio, e os bloqueios são preferencialmente definidos diretamente no CDN.
Os bloqueios ao nível da rede são uma ferramenta contra a massa, não contra ataques dirigidos. Ataques distribuídos a partir de muitíssimos endereços, com poucas tentativas por endereço, furam qualquer limiar. Por isso, o segundo fator continua a ser a camada mais importante, e o Fail2ban reduz sobretudo a carga e o ruído nos registos.
Guardar corretamente as palavras-passe em software próprio
Quem programa logins próprios nunca deve guardar palavras-passe em texto simples ou com funções de hash rápidas como MD5 ou SHA-1. O PHP traz, com o password_hash(), uma solução segura, que gere automaticamente o salt e o algoritmo.
<?php
declare(strict_types=1);
// No registo ou na alteração da palavra-passe
$hash = password_hash($passwort, PASSWORD_DEFAULT);
// No login
if (password_verify($eingabe, $hashAusDatenbank)) {
if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
$neu = password_hash($eingabe, PASSWORD_DEFAULT);
// guardar $neu na base de dados
}
// Login com êxito, renovar o ID de sessão
} else {
usleep(random_int(200000, 400000)); // tempo de resposta uniforme
// devolver uma mensagem de erro uniforme
}
O password_needs_rehash() faz com que hashes mais antigos sejam convertidos automaticamente para o algoritmo atual no login seguinte. Registe as tentativas falhadas com hora, conta e endereço, para que os padrões se notem. Indicações sobre a análise estão no guia Analisar os registos do servidor web após um ataque.
Particularidades de CMS, lojas e painéis
Muitos sistemas têm, além da página de login visível, outros caminhos através dos quais as credenciais são verificadas. Estas entradas laterais são muitas vezes esquecidas na proteção.
- WordPress: a interface
xmlrpc.phptambém aceita logins. Se não for necessária, por exemplo para aplicações mais antigas, bloqueie-a no servidor web. Verifique ainda se os nomes de utilizador são visíveis através das páginas de autor ou da interface REST e use para os administradores nomes que não apareçam publicamente. - Lojas: além da área de administração, as contas de clientes são um alvo, sobretudo para credential stuffing. Aqui ajudam o rate limiting, as notificações de novos logins e um segundo fator opcional para os clientes.
- Painéis de alojamento e webmail: estas interfaces são muitas vezes acessíveis em todo o mundo e protegem o servidor inteiro. Só devem ser acessíveis a partir de redes conhecidas ou por VPN.
- SSH: o login com chave em vez de palavra-passe torna ineficaz a adivinhação clássica.
Que funções de proteção o seu sistema traz por si, consta da documentação do fabricante. As extensões de terceiros devem ser ativamente mantidas, caso contrário tornam-se elas próprias um risco. Para os operadores de WordPress, a página WordPress e PHP2Shell resume as prioridades atuais.
Como ajuda concretamente a PHP SOS?
- Registamos todas as páginas de login acessíveis dos seus servidores, do CMS ao painel de alojamento, e avaliamos a sua proteção.
- Configuramos rate limiting, Fail2ban e restrições de acesso no âmbito do reforço de segurança do servidor e testamo-los.
- Acompanhamos a introdução da autenticação de dois fatores para administradores e documentamos os acessos de emergência.
- Com a monitorização de segurança, mantemos permanentemente sob vigilância os inícios de sessão falhados e as novas contas de administrador.
Perguntas frequentes
Como reconheço um ataque de brute force?
Típicos são muitos inícios de sessão falhados em pouco tempo, muitas vezes contra a mesma página de login e com nomes de utilizador variáveis. No registo de acessos, isto aparece como acumulação de pedidos POST ao endereço de login, frequentemente de muitos endereços IP diferentes.
Uma conta deve ser bloqueada após várias tentativas falhadas?
Cuidado: os bloqueios rígidos podem ser usados pelos atacantes para deixar utilizadores legítimos de fora. Melhores são atrasos crescentes, bloqueios temporários por endereço IP e uma notificação ao titular da conta.
Ajuda mudar o nome do endereço de login?
Reduz o ruído automatizado nos registos, mas não é uma proteção real. Quem conhecer ou encontrar o endereço pode continuar a atacar. São eficazes a autenticação de dois fatores, o rate limiting e uma restrição da área de administração.
O que é o credential stuffing?
Os atacantes experimentam combinações de e-mail e palavra-passe roubadas noutros serviços. Funciona quando os utilizadores usam a mesma palavra-passe em vários sítios. Palavras-passe únicas e um segundo fator retiram a base a este método.