Bloqueando ataques de força bruta SSH no IPv6

Recentemente, tive que trabalhar com alguns servidores com conexão IPv6 e fiquei surpreso ao descobrir que o fail2ban não tem suporte para IPv6, nem denyhosts. Pesquisando no google, descobri que as pessoas geralmente recomendam:

Desativando o login ssh através do IPv6 (não é uma solução para mim)
usando apenas autenticação de chave pública / privada no servidor, sem autenticação de senha (funciona, mas muitos ataques podem custar muito poder de processamento ao servidor ou até torná-lo indisponível por DDoS)
usando ip6tables para bloquear ataques consecutivos do mesmo IP
usando sshguard com suporte a IPv6

Pelo que eu reuni até agora, banir endereços no IPv6 é um pouco diferente do IPv4, porque os ISPs não fornecem ao usuário um único endereço (/ 128), mas uma sub-rede inteira (atualmente tenho um / 48). Assim, a proibição de endereços IPv6 únicos seria ineficaz contra ataques. Eu pesquisei alto e baixo sobre o assunto ip6tables e sub-redes de bloqueio sshguard na detecção de ataques, mas não consegui encontrar nenhuma informação.

Alguém sabe se o sshguard proíbe sub-redes em ataques IPv6?
Alguém sabe como fazer uma configuração de ip6tables para banir sub-redes em ataques IPv6?
Ou alguém conhece uma maneira melhor de mitigar os ataques do que o que eu já encontrei?

PS: Estou usando o CentOS 7 no sistema.

— DarthRevan13
fonte

Para obter mais informações sobre fail2ban, adicionando suporte ao IPv6: github.com/fail2ban/fail2ban/issues/39 . Parece que eles estão enfrentando um problema com o bloqueio de sub - rede , o que atrasa a implementação (parece ficar cada vez mais longe de nós ...).

— John WH Smith

Regras de limitação / proibição de taxa no iptables. Mude sua pergunta para isso e algumas rep-prostitutas devem responder com precisão.

Isso é um problema hipotético? Estive pesquisando logs de tentativas de força bruta de alguns servidores e cada um deles foi tentado pelo IPv4. E eu não vi nenhum servidor ficar com muita carga devido a essas tentativas quando a autenticação de senha está desativada no lado do servidor.

— kasperd

@kasperd Eu tenho alguns milhares de tentativas por dia no IPv6, então, não, não é um problema hipotético. O endereço do servidor é público porque hospeda um site, por isso é um problema real.

— DarthRevan13

@ user123418 Vou deixar o título da pergunta como está por enquanto, eu realmente preferiria algo como sshguard por causa do controle sobre ele vs uma regra no ip6tables. Se ninguém responder na semana seguinte, mudarei minha pergunta.

— DarthRevan13

Respostas:

Para atacar um servidor, o invasor deve primeiro conhecer seu endereço IP. Com o IPv6, você terá tantos endereços para escolher que não é possível encontrar o endereço correto pesquisando o intervalo de IPs.

Isso significa que você pode simplesmente atribuir dois endereços IPv6 diferentes à interface. Você permite que o nome de domínio do seu site continue apontando para o mesmo endereço IP de sempre, e permite que o sshd escute apenas no endereço IP recém-atribuído.

Após essa alteração, o conhecimento do nome do domínio e do endereço IP do seu site não dará ao invasor acesso ao seu sshd.

Obviamente, você precisará de um nome de host secundário para conectar ao usar o ssh. Esse nome de host pode ter muito mais entropia que um endereço IPv6. Alguém adivinhando o nome do host para ssh é inconcebível se você usar 63 caracteres alfanuméricos.

Se alguém descobrir o endereço IPv6 usado para sshd, basta mover o sshd para um novo endereço IPv6 e atualizar o registro AAAA. Então eles têm que começar tudo de novo.

Se você estiver preocupado com a possibilidade de um usuário ssh legítimo vazar o nome do host e / ou os endereços IP, crie um nome de host diferente para cada usuário acessar com o ssh. Inicialmente, CNAME todos eles para um único nome de host, para que haja apenas um único registro AAAA a ser atualizado.

— Kasperd
fonte

Parece melhor do que o que tenho atualmente, mas não é exatamente o que estava procurando. Obrigado mesmo assim.

— DarthRevan13

Boas notícias são que o fail2ban lançou recentemente o suporte para IPv6.

Para servidores Debian IPv6, eu recomendaria seguir este tutorial .

Para servidores CentOS IPv6, eu recomendaria fazer o download aqui e, em seguida, execute estes comandos substituindo o número da versão de acordo:

tar xvfj fail2ban-0.11.0.tar.bz2
cd fail2ban-0.11.0
python setup.py install

Verifique se uma prisão para sshd está ativada em /etc/fail2ban/jail.local , por exemplo:

[sshd]
enabled=1

— ncomputadores
fonte

Embora eu admire o que os caras do fail2ban fizeram, ainda não é suficiente! Nem todos os recursos são suportados pelo protocolo IPv6, de acordo com o changelog github.com/fail2ban/fail2ban/blob/0.10/ChangeLog e ainda não há suporte para banir sub-redes github.com/fail2ban/fail2ban/issues/927, que é crucial para IPv6, pois qualquer ISP não oferecerá apenas um endereço IPv6 para um cliente, mas uma sub-rede inteira. Enquanto isso continuar verdadeiro, nenhuma máquina de produção deve usar o fail2ban agora! Altere sua resposta para refletir isso, porque esta página é visitada por muitas pessoas.

— DarthRevan13