Saltar para o conteúdo 
Fail2Ban Plesk traz uma proteção eficaz contra ataques de força bruta ao seu ambiente de servidor Plesk com apenas alguns cliques e bloqueia automaticamente IPs suspeitos. Vou mostrar-lhe passo a passo como instalar o Fail2Ban, ativar cadeias, personalizar regras e configurar notificações para que o seu Servidor permanece permanentemente limpo.
Pontos centrais
Os seguintes pontos-chave dar-lhe-ão uma visão geral compacta antes de eu entrar em pormenores e mostrar-lhe como implementá-los no painel. Como definir o correto Prioridades desde o início.
- Instalação através de Ferramentas e Definições e ativação imediata
- Prisões Utilizar especificamente para SSH, correio, painel Plesk e WordPress
- Parâmetros como o tempo de proibição, a janela de deteção e as tentativas falhadas
- Lista branca Manutenção de IPs confiáveis e verificação de bloqueios
- Monitorização dos registos para um ajuste fino e menos alarmes falsos
O que faz o Fail2Ban - explicação sucinta
Análises Fail2Ban Protocolos de serviços como SSH, correio, servidor Web ou o painel Plesk e reconhece tentativas falhadas recorrentes. Se um IP exceder os limites definidos, bloqueio-o automaticamente durante um determinado período de tempo. Desta forma, previno de forma fiável a força bruta, os ataques de dicionário e as verificações automáticas com um esforço mínimo. Despesas. O Plesk fornece uma interface clara na qual posso ativar ou desativar as jails e ajustar os parâmetros. Para servidores produtivos, esta proteção é uma das medidas mais rápidas com um efeito percetível.
Instalação no Plesk: Pré-requisitos e início
Utilizo um servidor Plesk atual em Linuxidealmente Obsidian, e primeiro verifico se o componente Fail2Ban já está presente. Se estiver em falta, abro Ferramentas e Definições no Plesk, vou a Actualizações e actualizações e selecciono Adicionar/Remover componentes. Aí ativo a entrada Fail2Ban e inicio o Instalação. Após a conclusão, aparece a secção Bloquear endereços IP (Fail2Ban), na qual eu ligo e monitorizo a função. Para uma configuração completa, eu combino o Fail2Ban com um firewall bem configurado; os detalhes podem ser encontrados em Configurar a Firewall do Plesk.
Configuração básica: selecionar valores predefinidos sensatos
Depois de o ligar, verifico os parâmetros globais que determinam o efeito e os falsos alarmes. Com um Tempo de proibição Mantenho os atacantes afastados sem bloquear permanentemente os utilizadores legítimos. A janela de deteção controla o tempo durante o qual o Fail2Ban recolhe tentativas falhadas e o número máximo de tentativas falhadas define o limite para o bloqueio. Também introduzo um endereço de correio eletrónico para as notificações, de modo a poder ver imediatamente os eventos críticos. A tabela seguinte mostra valores iniciais comuns que se revelaram eficazes em muitas configurações e que podem ser aperfeiçoados em qualquer altura.
| Parâmetros | Recomendação | Efeito |
|---|---|---|
| Tempo de proibição | 600-1800 segundos | Bloqueia visivelmente os atacantes sem bloquear permanentemente os utilizadores |
| Janela de reconhecimento | 300-600 segundos | Agrega testes num período de tempo razoável |
| Máximo. Tentativas falhadas | 3-5 | Reduz os falsos positivos e continua a ser rigoroso |
| Notificação | Ativar o correio eletrónico | Avisos para confinamentos e eventos importantes |
Além disso, logo no início, defino um Ignorar lista (lista branca) a nível global. Em Ferramentas e definições > Bloquear endereços IP, introduzo endereços IP estáticos do escritório, pontos finais VPN ou redes de gestão. Para o IPv6, utilizo prefixos consistentes (por exemplo, /64) com cuidado e mantenho a lista reduzida para que a proteção não seja prejudicada. Para os causadores de problemas recorrentes, um Tempo de interdição incremental comprovada: Com parâmetros como bantime.increment = true, bantime.fator e hora de início Prolongo automaticamente os bloqueios se forem repetidos, garantindo assim um efeito duradouro.
Prisões: proteção específica dos serviços
No separador Cadeias, ativo as regras de proteção para as mais importantes Serviços: sshd, dovecot, proftpd, plesk-apache, plesk-panel e plesk-wordpress. Cada cadeia monitoriza os ficheiros de registo correspondentes, reconhece padrões e bloqueia IPs conspícuos. Para servidores com instâncias do WordPress, eu ligo o plesk-wordpress para bloquear ataques de login no wp-login e xmlrpc. Se não estiver a ser executado nenhum FTP, desativo a cadeia associada para que o servidor não faça verificações desnecessárias. Em seguida, verifico se os bloqueios funcionam de forma fiável e ajusto os valores limite se houver demasiados falsos positivos.
Para orientação: o sshd normalmente lê a partir de /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL/Alma/Rocky), os logins de correio acabam em /var/log/maillog respectivamente /var/log/mail.logo painel inicia a sessão /var/log/plesk/panel.log. Para ataques à Web, as jails do Plesk acedem aos registos de anfitriões virtuais em /var/www/vhosts/sistema//logs/ para. Se estiver a executar apenas o NGINX ou uma configuração Apache+NGINX, os filtros Plesk continuarão a funcionar, uma vez que os caminhos apropriados já estão armazenados.
Crie as suas próprias cadeias e filtros de forma limpa
Preciso de mais Proteção para uma aplicação, crio uma nova cadeia e consulto os registos associados. Defino uma janela de tempo livre, estabeleço o limite de falhas e determino o tempo de banimento desejado. Para aplicações especiais, escrevo filtros com expressões regulares que reconhecem mensagens de erro específicas. Depois de ativar a regra, testo-a simulando uma tentativa falhada e depois verifico os registos. Se notar um padrão que os atacantes podem contornar, refino o filtro e registo a alteração para o meu Documentação.
Para garantir que as personalizações permanecem à prova de atualização, crio Configurações próprias em /etc/fail2ban/jail.d/ como ficheiros separados (por exemplo custom-wordpress.local) em vez de alterar os ficheiros padrão. Desta forma, uma atualização do Plesk ou do pacote não substitui as minhas regras. Eu testo as regras de filtragem com fail2ban-regex contra logs de amostra antes de mudar uma cadeia para produtiva. Após as alterações, um systemctl reload fail2banpara as tornar activas sem ter de reiniciar o sistema.
Colocação na lista branca, desbloqueio e compreensão de IPs bloqueados
Se eu me bloquear a mim próprio ou a um membro da equipa, abro a lista de endereços IP bloqueados e desbloqueio o endereço novamente. Para fontes permanentemente fiáveis, utilizo a lista branca e, assim, evito futuros Bloqueios. Na vista geral, posso ver qual a cadeia que bloqueou um IP e para que regra foi detectado. Esta informação ajuda-me a reconhecer aplicações mal configuradas ou bots. Mantenho a lista branca enxuta e só mantenho entradas se houver uma boa razão para o fazer. Motivo ali.
Trabalha atrás de um Proxy/CDNEu presto especial atenção à lista branca: Se os logins e os acessos à Web estiverem por detrás dos IPs do proxy invertido do ponto de vista do servidor, uma cadeia configurada de forma descuidada irá, no pior dos casos, bloquear o proxy em vez do verdadeiro atacante. Neste caso, certifico-me de que o servidor Web escreve corretamente o IP "real" do cliente nos registos (mecanismo X-Forwarded-For/Atual Real-IP) e mantenho as redes proxy como sendo de confiança. Isto garante que os bloqueios permanecem exactos.
Evitar erros: afinação sensata a partir da prática
Começo com uma dose moderada Limiares e só aperto os valores quando conheço os perfis típicos de carga e utilização. Para anfitriões partilhados com muitos utilizadores, o risco de falsos bloqueios aumenta, pelo que defino um MaxRetry mais elevado e monitorizo os registos mais de perto. Se os bots chegarem aos seus formulários, vale a pena dar uma vista de olhos aos registos do servidor Web e às regras adicionais na cadeia plesk-apache. Configurei o 2FA para logins de administrador e, assim, aliviei o Fail2Ban porque menos tentativas de login chegam ao painel. Uma consulta regular da lista de bloqueios mostra-me se um indivíduo Fonte é particularmente visível e requer mais medidas.
Combinação de firewall e reforço do WordPress
O Fail2Ban bloqueia os atacantes após tentativas falhadas, enquanto a firewall reduz antecipadamente a superfície de ataque. Ambos em conjunto fornecem visivelmente mais Segurançaespecialmente com portas SSH ou de correio expostas. Para o WordPress, eu restrinjo o xmlrpc, defino um limite de taxa de login no nível do aplicativo e deixo o plesk-wordpress fazer o resto do trabalho. Isto dá-lhe uma defesa em profundidade em vez de uma única barreira. Pode encontrar uma comparação mais aprofundada neste artigo: Fail2Ban e firewall em comparaçãoque o ajudará a coordenar as medidas.
Verificação prática para administradores do Plesk
Uma vez configurado, verifico se os bloqueios ocorrem dentro do período de tempo esperado e se as notificações por correio eletrónico chegam. Em seguida, testo o SSH com palavras-passe deliberadamente incorrectas e verifico os registos para verificar a eficácia do Prisões para confirmar. Para o painel Plesk, simulo vários inícios de sessão falhados e observo se o IP é bloqueado de imediato. Se aparecerem demasiados bloqueios legítimos, aumento o MaxRetry passo a passo e alargo moderadamente a janela de deteção. Esta abordagem consistente mantém os falsos alarmes num nível mínimo e garante um Funcionamento.
Integração de alojamento: o que procuro
Uma configuração de alojamento sólida fornece Fail2Ban, firewall, cópias de segurança e monitorização de uma forma coerente. Presto atenção à integração direta com o Plesk, aos tempos de resposta curtos do suporte e à clareza Documentação. com contentores de serviços isolados e actualizações consistentes do kernel oferecem-me segurança adicional. Para projectos produtivos, também confio em cópias de segurança externas para poder voltar a estar online rapidamente em caso de emergência. Isto cria um nível de segurança que torna os ataques muito mais difíceis e pode ser realizado com um nível razoável de segurança. Despesas pode ser mantido.
Monitorização e resolução de problemas: como manter-se a par de tudo
Analiso regularmente a visão geral do Fail2Ban, verifico os bloqueios Endereços e reconhecer fontes recorrentes. Se encontrar padrões, ajusto as regras de filtragem e documento as alterações para as poder seguir mais tarde. Se os registos mostrarem picos de carga pesados, estabeleço limites adicionais no servidor Web e reforço a firewall. Ao mesmo tempo, mantenho o Plesk, os pacotes do sistema e os plugins actualizados para minimizar as superfícies de ataque; pode encontrar dicas testadas e comprovadas neste guia para Colmatar as lacunas de segurança no Plesk. Isto mantém a sua proteção actualizada e o Fail2Ban precisa de menos Trabalho atuar.
Backends e caminhos de protocolo no Plesk
Para uma deteção fiável, é crucial que o Fail2Ban tenha a Fontes de protocolo lê. No Linux, utilizo registos de ficheiros ou o backend systemd, dependendo da distribuição. As configurações modernas beneficiam de backend = systemdpois o Fail2Ban lê o diário diretamente e gera menos I/O nos ficheiros de registo. O Plesk já tem definições por defeito sensatas para isto. No entanto, verifico aleatoriamente se os caminhos de registo nas jails correspondem à realidade: SSH em /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL/Alma/Rocky), correio eletrónico em /var/log/maillog ou /var/log/mail.logPainel Plesk em /var/log/plesk/panel.logWeb nos diretórios vhost. Se os caminhos ou os nomes dos diários não estiverem corretos, corrijo as entradas numa .local-ficheiro. Desta forma, evito pontos cegos onde os ataques não são detectados.
IPv6, banaction e firewall backend
Muitas instalações já não filtram apenas IPv4. Certifico-me de que o Banimentos são adequados para IPv6 (por exemplo, variantes multiportas para iptables/firewalld). Se o sistema utiliza o Firewalld, presto atenção a acções como firewallcmd-multiportpara configurações clássicas do iptables para iptables-multiporta ou ações baseadas em ipset para um melhor desempenho. É importante que a ação utilizada no Fail2Ban corresponda à firewall Plesk ativa - caso contrário, os bloqueios acabam na cadeia errada ou não têm qualquer efeito. Após as alterações, faço um teste específico: tentativas falhadas simuladas a partir de um IP de teste, consulta do estado da cadeia e, em seguida, um teste de ligação. Se os bloqueios IPv6 funcionarem de forma fiável, eliminei uma lacuna significativa que é frequentemente ignorada em redes mistas.
Aumento dos confinamentos e bloqueios a longo prazo (reincidência)
Com atacantes recorrentes, aumento a pressão: com tempos de interdição progressivos (bantime.increment) são automaticamente alargados - aproximadamente o dobro de bantime.fator = 2 - até um máximo sensível (hora de início). Também utilizo prisão recidiva que detecta IPs que aparecem várias vezes em prisões diferentes numa janela mais longa. Uma configuração com tempo de procura O nível de proibição de acesso a utilizadores legítimos é de horas a dias e um período de proibição de vários dias provou ser eficaz. Este nível tem um efeito duradouro contra os bots que regressam regularmente sem excluir permanentemente os utilizadores legítimos. Continua a ser importante utilizar redes fiáveis através de ignoreip e para controlar os efeitos através da lista negra.
Fluxo de trabalho CLI: verificar, recarregar, desbloquear
Embora o Plesk ofereça uma interface conveniente, resolvo muitos rápido através da consola. Com estado do cliente fail2ban Vejo prisões activas, fail2ban-client status lista os IPs bloqueados e os contadores. Carrego novas regras com systemctl reload fail2banSe necessário, reinicio o serviço. Elimino IPs individuais (fail2ban-client set unbanip) sem afetar todo o sistema. Para a resolução de problemas journalctl -u fail2banpara ler os últimos acontecimentos, incluindo informações sobre filtros defeituosos. Isto permite-me manter as operações reduzidas, documentar brevemente as intervenções e introduzir as conclusões nas regras.
Operação por trás de proxy/CDN, ModSecurity e detalhes do WordPress
Atualmente, muitos sítios Web ficam para trás Proxies inversos ou CDNs. Para garantir que o Fail2Ban avalia o cliente real, certifico-me de que o servidor Web regista o IP correto no registo e que as redes proxy estão na lista branca. Caso contrário, corro o risco de bloquear involuntariamente redes de borda inteiras. No Plesk, também utilizo ModSecurity (WAF): o ModSecurity bloqueia padrões de ataque conhecidos a nível HTTP, enquanto o Fail2Ban sanciona tentativas de início de sessão falhadas ou padrões 4xx/5xx repetidos. Para o WordPress, adoto uma abordagem em duas vertentes: restringir ou proteger o xmlrpc, definir limites de taxa de login no nível do aplicativo e usar o plesk-wordpress-jail active. Desta forma, elimino o ruído no registo e deixo que o Fail2Ban se concentre nos casos difíceis.
Manutenção, cópias de segurança e estratégia de atualização
Para garantir que os ajustamentos se mantêm a longo prazo, guardo todos os regras próprias em ficheiros separados sob /etc/fail2ban/jail.d/ e documentar as alterações de versão. Antes de grandes actualizações do plesk ou do sistema, crio um snapshot/backup e depois verifico aleatoriamente se as jails ainda estão activas e se os caminhos estão corretos. Também tenho em conta as rotações de registos: após uma rotação (novo ficheiro de registo), o backend deve continuar a ler de forma fiável - com o systemd-Journal, esta preocupação é largamente eliminada. Estabeleço pequenos SOPs para as equipas: como os IPs são desbanidos, os limites são ajustados e as notificações são verificadas. Isto garante que o tratamento permanece consistente, mesmo quando as responsabilidades mudam.
Decisão judicial: protocolos e armazenamento
A segurança também precisa de Dimensão. Guardo apenas as informações necessárias para a defesa e o diagnóstico, defino períodos de retenção claros e elimino regularmente os dados antigos. O Fail2Ban em si não armazena quaisquer dados a longo prazo; a base é o seu sistema e os registos da Web. Um nível de registo reduzido na operação regular (por exemplo, INFO) mantém a quantidade de dados gerível, enquanto eu o aumento temporariamente para DEBUG para análises e depois volto a mudar. É assim que combino uma proteção eficaz com um rasto de dados simples e rastreável.
Em resumo: implementação segura em apenas alguns cliques
Activei o Fail2Ban através do Plesk, defini parâmetros equilibrados, liguei o Prisões e mantenho uma lista de permissões simples. Com uma firewall complementar, 2FA e actualizações limpas, obtenho um elevado nível de proteção sem lastro. Os filtros personalizados dão-me controlo sobre casos especiais, enquanto as notificações e os registos simplificam o meu trabalho diário. Se seguir estes passos à risca, reduzirá visivelmente as tentativas de força bruta e protegerá eficazmente os logins de administrador, o correio e o SSH. Como manter o seu servidor Plesk seguro com Fail2Ban permanentemente resistente e fácil de administrar.
