Como proteger o WordPress com o Fail2Ban

English version: How to protect WordPress with Fail2Ban

Juntos, o WP Cerber e o Fail2Ban podem impedir ataques de força bruta antes mesmo que eles atinjam seu WordPress. O WP Cerber detecta tentativas de login malsucedidas no nível do aplicativo; o Fail2Ban age sobre elas no nível do sistema operacional, bloqueando os invasores com o iptables . Essa combinação impede ataques de força bruta e de negação de serviço (DoS) com sobrecarga mínima.

O que é Fail2Ban?

O Fail2Ban é um serviço de monitoramento de logs que roda no seu servidor. Ele observa os arquivos de log em busca de padrões que indiquem um ataque, como falhas repetidas de autenticação do mesmo endereço, e quando um host ultrapassa um limite definido por você, ele bloqueia esse endereço no firewall do sistema por um período determinado. Por si só, ele não sabe nada sobre o WordPress; age puramente com base no que encontra nos logs. É aí que entra o WP Cerber: ele monitora e registra as falhas de login em um formato que o Fail2Ban consegue analisar, fornecendo ao serviço os eventos necessários para agir.

Leia mais sobre ataques: Ataques de força bruta, DoS e DDoS – qual a diferença?

Observação: você precisará de acesso root ao seu servidor Linux para configurar o Fail2Ban.

Com o WP Cerber, você tem três opções para usar o Fail2Ban.

1. Utilize os cabeçalhos de resposta HTTP 403 se desejar monitorar o log de acesso do Apache.
2. Utilizando arquivos syslog para monitorar tentativas de login falhas.
3. Utilizando um arquivo de log personalizado para monitorar tentativas de login falhas.

Monitore o log de acesso do Apache em busca de respostas HTTP 403.

Quando uma tentativa de login falha, o WP Cerber retorna um status 403 no cabeçalho HTTP. O Apache registra essa resposta em seu log de acesso, onde o Fail2Ban pode lê-la. Esse comportamento está habilitado por padrão. A desvantagem é que o Fail2Ban precisa analisar todo o arquivo access.log para encontrar essas tentativas, o que é ineficiente em um site com alto tráfego.

Utilizando o syslog para monitorar tentativas de login falhas.

Por padrão, o WP Cerber registra as tentativas de login falhas no syslog usando a funcionalidade LOG_AUTH . Para usar uma funcionalidade própria, defina a constante CERBER_LOG_FACILITY com um valor inteiro. De qualquer forma, a gravação no syslog ou em um arquivo personalizado (veja abaixo) só ocorrerá depois que você habilitar a opção "Gravar logins com falha em um arquivo de log" nas configurações principais do plugin.

 define('CERBER_LOG_FACILITY', LOG_AUTHPRIV);

Utilizando um arquivo personalizado para monitorar tentativas de login falhas.

Para enviar cada tentativa de login falha para um arquivo de log de sua escolha, defina o caminho absoluto com a constante CERBER_FAIL_LOG . Não se esqueça de conceder permissão de escrita ao seu servidor web na pasta ou arquivo e de habilitar a opção "Gravar logins com falha em um arquivo de log" . O WP Cerber cria o arquivo de log caso ele não exista. Uma vez que CERBER_FAIL_LOG esteja definido, o WP Cerber para de gravar no syslog padrão. Vale ressaltar que um arquivo CERBER_FAIL_LOG personalizado mantém os dados sob seu controle, diferentemente do syslog, onde o armazenamento segue as políticas do servidor ou ambiente de hospedagem.

 define('CERBER_FAIL_LOG','/var/log/wp-cerber-auth.log');

Certifique-se de que o processo PHP do seu servidor web tenha permissão de escrita no arquivo especificado.

Alinhamento dos registros de data e hora com o relógio do servidor

A incompatibilidade de fuso horário é o motivo mais comum para o Fail2Ban registrar tentativas, mas nunca banir ninguém, então vale a pena entender isso mesmo quando tudo o mais estiver configurado corretamente.

O Fail2Ban só age em eventos que ocorrem dentro do seu intervalo findtime , e essa definição é feita comparando o timestamp de cada linha do log com a hora local do seu servidor. O WordPress mantém seu próprio relógio em UTC, independentemente do fuso horário configurado no site. Portanto, em um servidor rodando, digamos, em Europe/Madrid, cada linha que o WordPress escreve parece ter uma ou duas horas de atraso. O Fail2Ban descarta esses eventos como obsoletos e nunca executa um bloqueio, mesmo que as tentativas sejam registradas no log.

O WP Cerber contorna esse problema gravando seus registros de data e hora no fuso horário do sistema do seu servidor, em vez do relógio do WordPress, para que correspondam ao que o Fail2Ban espera por padrão. Na maioria dos servidores, isso é automático e não requer nenhuma configuração da sua parte.

Quando o WP Cerber não conseguir resolver o fuso horário do sistema por conta própria, defina-o você mesmo com a constante CERBER_LOG_TIMEZONE , usando qualquer identificador de fuso horário válido:

 define('CERBER_LOG_TIMEZONE', 'Europe/Madrid');

Este valor sobrepõe-se à detecção automática, sendo assim a forma mais confiável de determinar o fuso horário caso observe alguma discrepância nos registros de data e hora. Qualquer identificador do banco de dados de fusos horários padrão funciona, por exemplo, 'America/New_York' ou 'Asia/Tokyo'. Esta constante está disponível a partir da versão 9.7.4 do WP Cerber .

O que é registrado

Este registo armazena dados pessoais, portanto, se o seu site estiver sujeito a um regime de privacidade como o RGPD, isso diz respeito diretamente a você. Veja a seguir o que ele contém.

Cada tentativa de login falha registra uma linha: o endereço IP de origem, o nome de usuário enviado, o nome do host do servidor, o ID do processo e um registro de data e hora. As senhas nunca são registradas, de nenhuma forma, e nenhum outro dado da conta é gravado.

Dois desses campos são considerados dados pessoais de acordo com o GDPR: o endereço IP (a decisão Breyer estabeleceu que um endereço IP é considerado dado pessoal) e o nome de usuário. Como o WordPress permite logins por e-mail, o nome de usuário também pode ser um endereço de e-mail do usuário . Isso se aplica mesmo a tentativas de acesso malsucedidas, que ainda registram que uma pessoa específica foi alvo do ataque.

Isso faz de você o controlador desses dados, com algumas consequências práticas. Inclua esses registros em sua política de retenção e rotacione-os ou exclua-os em vez de deixá-los crescer indefinidamente. Monitore onde os registros são armazenados e encaminhados: um arquivo CERBER_FAIL_LOG personalizado mantém os dados sob seu controle, enquanto o syslog pode enviar os registros para servidores centralizados ou externos, onde o armazenamento e o processamento seguem políticas de todo o sistema que você pode não ter definido. As solicitações de acesso ou exclusão do titular dos dados também se aplicam a esses registros.

O WP Cerber opta por não oferecer suporte à limpeza desses logs, pois não tem controle sobre o que o syslog faz com os registros ou como o sistema operacional do servidor processa os arquivos de log. Um recurso de limpeza integrado ao WP Cerber cobriria apenas parte do problema e poderia sugerir erroneamente que os dados foram removidos quando, na verdade, não foram.

Este é um resumo prático, não uma consultoria jurídica. Se você lida com dados da UE, do Reino Unido ou de jurisdições semelhantes, trate o endereço IP e o nome de usuário como dados pessoais e verifique suas obrigações junto ao órgão de conformidade da sua empresa.