Protegendo servidores Linux: iptables vs fail2ban

Question

Eu gostaria de escolher o cérebro da comunidade em relação à segurança do servidor linux, especificamente com relação aos ataques de força bruta e usando fail2ban vs iptables personalizados .

Existem algumas perguntas semelhantes, mas nenhuma delas aborda o tópico para minha satisfação. Resumindo, estou tentando determinar a melhor solução para proteger os servidores Linux expostos à Internet (executando os serviços usuais, ssh, web, correio) contra ataques de força bruta.

Eu tenho um controle decente sobre a segurança do servidor, ou seja, bloquear o ssh não permitindo logins root ou de senha, alterando a porta padrão, garantindo que o software esteja atualizado, verificando arquivos de log, permitindo que determinados hosts acessem o servidor e uso de ferramentas de auditoria de segurança, como Lynis ( link ), para conformidade geral de segurança, portanto, essa pergunta não é necessariamente em relação a isso, embora a contribuição e conselho seja sempre bem-vinda .

Minha pergunta é qual solução devo usar (fail2ban ou iptables), e como devo configurá-la, ou devo usar uma combinação de ambos para proteger contra ataques de força bruta?

Existe uma resposta interessante em relação ao tópico ( Denyhosts vs fail2ban vs iptables- melhor maneira de prevenir logons de força bruta? ). A resposta mais interessante para mim foi pessoalmente ( link ), e esse roteamento iptables ocorre no kernel como oposta a fail2ban que faz uso de ferramentas de modo de usuário para analisar arquivos de log. O Fail2ban usa o iptables, é claro, mas ainda precisa analisar os arquivos de log e corresponder a um padrão até executar uma ação.

Faz sentido usar o iptables e usar limitador de taxa ( link ) para descartar solicitações de um IP por um período que faz muitas tentativas de conexão durante um período específico, independentemente de qual protocolo ele estava tentando se conectar? Em caso afirmativo, existem alguns pensamentos interessantes sobre o uso de drop vs reject para esses pacotes aqui ( link ), algum pensamento sobre isso?

O Fail2ban permite uma configuração personalizada na forma de gravar ' regras ' personalizadas para serviços que podem não ser atendidos na configuração padrão. É fácil de instalar e configurar e é poderoso, mas poderia ser um exagero se tudo o que eu estou tentando alcançar é ' bloquear ' um IP do servidor se eles fizerem 2 tentativas de acesso falhas em qualquer serviço / protocolo durante um período x ?

O objetivo aqui é abrir relatórios de logwatch diários e não precisar percorrer as páginas de tentativas de conexões com falha para o servidor.

Obrigado por dedicar seu tempo.

    

Answer 1

should I use fail2ban or iptables?

Você usa o fail2ban além de uma solução de firewall, para estender sob demanda as regras de firewall existentes com regras para bloquear o ip específico -endereços de sistemas que realizam ações indesejáveis em outros serviços públicos. Eles trabalham em conjunto uns com os outros.

Simplificado: um firewall só vê conexões e pacotes de rede e pode ter alguma noção dos padrões, mas não tem a percepção do nível do aplicativo para distinguir solicitações válidas e desejadas de solicitações mal-intencionadas, mal-formadas e indesejadas. Por exemplo, seu firewall não pode dizer a diferença entre um monte de solicitações HTTP API e um número incorreto de tentativas de login causadas por adivinhação de senha de força bruta na sua página de administração do Wordpress, para o firewall ambas são conexões TCP para a porta 80 ou 443.

O Fail2ban é uma abordagem genérica e extensível para fornecer esse insight de nível de aplicativo ao seu firewall, embora de maneira indireta.
Frequentemente, os aplicativos registram e registram solicitações mal-intencionadas, mal-intencionadas e indesejáveis, mas raramente têm a capacidade nativa de evitar mais abusos. Embora seja ligeiramente dissociado, o Fail2ban pode, então, agir sobre esses eventos maliciosos registrados e limitar os danos e evitar mais abusos, geralmente reconfigurando dinamicamente seu firewall para negar acesso adicional. Em outras palavras, o Fail2ban fornece aos seus aplicativos existentes, sem modificá-los, os meios para se defender do abuso.

Um método diferente para fornecer aos firewalls informações sobre o nível do aplicativo seria por meio de um sistema de detecção / prevenção de invasões .

Por exemplo, um servidor da Web é um serviço público comum e, no seu firewall, as portas TCP 80 e 443 estão abertas para a Internet como um todo. Normalmente, você não tem nenhuma limitação de taxa nas portas HTTP / HTTPS porque vários usuários válidos podem ter uma única origem quando estão, por exemplo, atrás de um gateway NAT ou de um proxy da web.

Quando você detecta ações indesejáveis e / ou mal-intencionadas em seu servidor da Web, usa o fail2ban para automatizar o bloqueio desse ofensor (bloqueia-os completamente ou bloqueia apenas o acesso deles às portas 80 e 443).

Por outro lado, o acesso SSH não é um serviço público, mas se você não estiver em condições de restringir o acesso SSH em seu firewall apenas a intervalos de endereço IP listados em branco, as conexões de entrada limitadoras de taxa serão uma maneira de desacelerar ataques de força bruta. Mas o seu firewall ainda não consegue distinguir entre o usuário bob fazendo o login com sucesso 5 vezes porque ele está executando ansiosos playbooks e 5 tentativas fracassadas de fazer login como root por um bot.

    

Answer 2

should I use fail2ban or iptables?

Isso é um pouco semelhante a perguntar "devo usar um cinto de segurança ou um carro?".

Em primeiro lugar, lembre-se de que o fail2ban realmente é apenas uma ferramenta para detectar automaticamente entradas recorrentes em arquivos de texto e executar algum comando quando elas atendem a um limite especificado.

Nós geralmente o usamos para bloquear hosts que violam alguma política, como evidenciado por entradas de log recorrentes que indicam uma violação de política, mas não é a única coisa que você pode usar para isso.

Você pode usar o fail2ban para adicionar (e remover) as regras do iptables sob demanda. Você também pode adicionar e remover as regras do iptables manualmente ou usar o fail2ban para fazer algo totalmente diferente em resposta. Isso é tudo sobre como você o configura.

Você deve ter um firewall geral, independentemente de estar executando o fail2ban ou não. Esse firewall seria, por exemplo, bloquear o tráfego (recebido ou enviado) que você sabe que é nunca vai ser legítimo. Por exemplo, esse servidor de banco de dados realmente precisa lidar com conexões de entrada na porta 25 de toda a Internet?

Além disso, fazer com que o fail2ban responda às violações da política, cortando o (s) IP (s) ofensivo (s) por algum tempo não fará muito para proteger seu servidor per se (uma boa exploração só precisa para passar pelo firewall uma vez), mas isso reduzirá o nível de ruído do seu sistema, incluindo, entre outros, os logs do sistema. A maneira simples de fazer isso é fazer com que o fail2ban execute o iptables para configurar o kernel para descartar os pacotes por algum tempo. Se você puder reconfigurar o seu firewall de perímetro em vez de apenas o firewall do host, então só melhor.

Em outras palavras, na medida em que eles podem ser facilmente separados em primeiro lugar, você quer os dois.

could it be an overkill if all I am trying to achieve is to 'block' an IP from the server if they make 2 failed access attempts on any service/protocol over a x amount of time?

Isso é exatamente o caso de uso que o fail2ban foi projetado para resolver. Usar uma ferramenta para o propósito pretendido é quase nunca um exagero.

The goal here is to open daily logwatch reports and not have to scroll through pages of attempted failed connections to the server.

Um aparte, não diretamente relacionado à sua pergunta: sempre que você estiver filtrando registros para análise, considere o que você fará com relação a uma entrada em particular. Se tudo o que você vai fazer sobre uma entrada é dizer "meh" e seguir em frente, então provavelmente você quer filtrá-la. Certifique-se de salvar os logs completos para revisão, caso seja necessário, mas apenas insira em seu fluxo de trabalho de monitoramento regular as coisas com as quais você realmente irá fazer algo ao ser exibido. Se você configurar o fail2ban para bloquear um host depois de algumas tentativas de conexão com falha, é muito provável que você não precise revisá-las manualmente e descartá-las nas notificações de monitoramento. Se um usuário legítimo reclamar de perda de acesso, basta retirar os registros completos e dar uma olhada.

    

Answer 3

Eu resolvi a mesma pergunta há alguns anos. Eu decidi usar o iptables com modul recente por causa do desempenho e facilidade de configuração. Eu tive que proteger um monte de contêineres virtuais em hosts. Apenas tenha em mente não abrir nenhum vetor DOS com suas regras. Também use o ipset para corresponder listas de rede ou listas de ip em regras. Eu uso para listas brancas. Todas as redes de um país em uma lista são ótimas para ajuste fino. E é muito fácil proteger um outro serviço com o mesmo conjunto de regras, adicionando mais uma porta para corresponder. Então, eu não gosto de mudar com o fail2ban, mas talvez alguém com outras necessidades fique feliz com o fail2ban.

Aqui está uma amostra:

  #
  # SSH tracking sample
  #
  #################################################################################
  iptables -X IN_SSH
  iptables -N IN_SSH
  iptables -A IN_SSH -m set --match-set net_blacklist src -p tcp -j REJECT
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp --match limit --limit 5/second -j LOG --log-prefix whitelist_de_prefix
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp -j ACCEPT
  # filter update
  iptables -A IN_SSH -m recent --name sshbf --set --rsource
  # connlimit
  iptables -A IN_SSH -m connlimit --connlimit-above 4 --match limit --limit 5/second -j LOG --log-prefix ssh_connlimit_per_ip_above_4
  iptables -A IN_SSH -m connlimit --connlimit-above 4 -j REJECT
  # filter
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 --match limit --limit 5/second -j LOG --log-prefix ssh_filtered_13in60sec
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 -j REJECT
  iptables -A IN_SSH -j ACCEPT

iptables -A FORWARD -p tcp --dport ssh --syn --jump IN_SSH
# iptables -A INPUT -p tcp --dport ssh --syn --jump IN_SSH

A saída de suas mensagens de log pode ser combinada com o fail2ban. Você também pode usá-lo para as regras INPUT.