Como bloquear a força bruta do SSH via Iptables e como funciona?

Question

Estou planejando adicionar as seguintes regras ao iptables para impedir o ataque de força bruta do ssh, que são comuns atualmente.

-A INPUT -i eth0.103 -p tcp -m tcp --dport 4522 -m state --state NEW -m recent --set --name SSH --rsource    
-A INPUT -i eth0.103 -p tcp -m tcp --dport 4522 -m recent --rcheck --seconds 30 --hitcount 4 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset    
-A INPUT -i eth0.103 -p tcp -m tcp --dport 4522 -m recent --rcheck --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j LOG --log-prefix "SSH brute force "    
-A INPUT -i eth0.103 -p tcp -m tcp --dport 4522 -m recent --update --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset    
-A INPUT -i eth0.103 -p tcp -m tcp --dport 4522 -j ACCEPT

Eu entendo que as regras segundo, terceiro e quarto são responsáveis por registrar e bloquear o ataque proveniente do mesmo IP em 30 segundos. intervalo.

Perguntas

1. Quando a documentação diz "registre-a no log do sistema uma vez, depois a rejeite imediatamente e a esqueça", o que eles querem dizer com o esquecimento?
2. Esqueça isso para sempre?
3. Existe uma lista negra que o iptables verifica?
4. Se um IP for rejeitado, mas depois tentar outra conexão uma hora depois, haverá outras 3 tentativas desse IP?
5. Se for esse o caso, isso não está bloqueando, mas diminuindo os ataques, contanto que iptables não tenha uma contagem de listas negras?

Answer 1

Question #1: When the documentation says "log it to the system log once, then immediately reject it and forget about it" what do they mean by forget about it?

Significa que a mensagem aparecerá nos registros, mas apenas uma vez, para que seu registro não seja poluído com um fluxo contínuo de mensagens toda vez que a regra for acionada.

Question #2: Forget about it forever?

Não, não para sempre. Há um período de tempo associado à frequência com que essas mensagens ocorrerão nos registros.

Question #3: Is there a blacklist that iptables check?

Não, não há lista negra que o iptables "cheque". É burro no sentido de que filtrará apenas o que você diz e permitirá que apenas o que você disser é permitido.

Question #4: If an IP is rejected but then tried another connection an hour later, will there be another 3 attempts from that IP?

Depende de qual é o tempo limite de arqueamento excedido. Se ocorrerem tentativas adicionais e o tempo limite original não tiver decorrido das tentativas iniciais, não deverá haver mensagens adicionais nos registros nem conexões permitidas. Se esse tempo limite tiver decorrido, então sim, você verá mensagens adicionais sobre essas tentativas subsequentes.

Recomendamos que você consulte a documentação do módulo recent do Iptable para obter detalhes adicionais sobre como isso funciona.

• regra de correspondência recente do iptables
• Módulo recente do IPTables / Netfilter
• Documentação do IPTables - HOWTO - 3.16 patch recente

Digitalização de portas

O período de tempo que um IP permanece na lista "badguy" seria governado por uma estruturação de suas regras como esta:

iptables -A INPUT -i $OUTS -m recent --name badguys --update --seconds 3600 -j DROP
iptables ...
 .
 .
 .
iptables -A INPUT  -t filter -i $OUTS -j DROP -m recent --set --name badguys

A primeira regra verificaria se um pacote de entrada já estava na lista "badguy". Se fosse, o relógio seria "redefinido" pela opção --update e o IP do badguy permaneceria nessa lista por até 1 hora (3600 segundos). Cada tentativa subseqüente redefiniria essa janela de 1 hora!

NOTA: Com as regras assim estruturadas, os infratores teriam que ficar completamente em silêncio por uma hora para poder se comunicar conosco novamente

SSH

Para conexões SSH, a tática é um pouco diferente. O tempo limite associado à chegada da lista "badguy" do IP ainda é de 1 hora e ainda é redefinido a cada reconexão dentro dessa janela de 1 hora.

Para o SSH, precisamos contar cada conexão --syn . Este é um pacote TCP SYN, no handshake TCP 3 que ocorre. Contando isso, podemos "rastrear" cada tentativa de conexão. Se você tentar se conectar a nós mais do que diz duas vezes em uma janela de 30 segundos, você será desconectado.

Para obter esses IP's que continuamente tentam se conectar na lista "badguy", podemos incorporar outra regra que os adiciona se eles tentarem se conectar a nós, digamos 6 vezes dentro de uma janela de 5 minutos (300 segundos).

Aqui estão as regras correspondentes - sua ordem é crítica! :

iptables -N BADGUY
iptables -t filter -I BADGUY -m recent --set --name badguys

iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --set
iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --rcheck --seconds 300 --hitcount 6 -j BADGUY
iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --rcheck --seconds  30 --hitcount 2 -j DROP

NOTA: você pode ver a lista "badguy" em /proc/net/ipt_recent . Deveria haver um arquivo lá com o nome da lista, badguys .

Question #5: If it is the case then this is not blocking but slowing down the attacks as long as iptables doesn't have some blacklist count?

Acho que você verá que, em geral, existem 3 maneiras de lidar com as tentativas de conexão do ponto de vista do iptable.

1. Permitir tráfego conhecido por ser aceitável
2. Não permitir tráfego que seja inaceitável
3. O tráfego é potencialmente ruim, reduz a velocidade e / ou rejeita indefinidamente ou por um período de "tempo limite". Se o referido comportamento tiver sido tratado usando um "tempo limite", permita-o novamente, após o tempo limite ter expirado.

# 3 é onde a maior parte da complexidade vem da configuração de iptables e / ou firewalls em geral. Como grande parte do tráfego na internet está OK, até certo ponto, e é quando esse tráfego exibe um comportamento "obsessivo", no sentido de que um único IP tenta se conectar ao número de vezes da porta X do seu servidor, tornando-se um problema.

Referências

• Aumentando as conseqüências com o IPTables