# Proteger logins de administração contra brute force: proteção para qualquer login

> Proteção contra brute force para logins: rate limiting, Fail2ban, autenticação de dois fatores e armazenamento seguro de palavras-passe com password_hash.

Fonte: https://phpsos.de/pt/ratgeber/brute-force-login-schutz/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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](https://phpsos.de/pt/ratgeber/zwei-faktor-admin/).
- **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.

```nginx
# 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:

```apache
<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:

```ini
# /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
<?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](https://phpsos.de/pt/ratgeber/logfiles-auswerten/).

## 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.php` també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](https://phpsos.de/pt/plattformen/wordpress/) 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](https://phpsos.de/pt/leistungen/server-haertung/) 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](https://phpsos.de/pt/leistungen/security-monitoring/), 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.

## Fontes

- [OWASP Cheat Sheet Series (Authentication)](https://cheatsheetseries.owasp.org/)
- [BSI (Serviço Federal Alemão para a Segurança da Informação): recomendações sobre palavras-passe seguras e autenticação de dois fatores](https://www.bsi.bund.de/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)