Eu recentemente atualizei meu Raspberry Pi de Raspbian 8 (Jessie) para 9 (Stretch). O Pi acessível na minha LAN via IPv4 e IPv6. Eu apliquei algumas regras do iptables (somente IPv4) para bloquear hosts que não autenticam várias vezes via SSH. Não há regras iptables para o IPv6 (ainda).
Mas agora o iptables (no IPv4) bloqueia conexões SSH da minha estação de trabalho para o Pi se eu tentar conectar mais de uma vez. Especificamente: posso abrir com êxito uma primeira sessão SSH via IPv4, mas quando tento abrir outra sessão simultaneamente, ela me bloqueia. Eu só posso conectar via IPv6, ou tenho que esperar até que o tempo de bloqueio termine (10 minutos).
Até agora não consegui encontrar a causa deste problema. O iptables é configurado de forma a registrar todas as tentativas de conexão com falha no syslog, usando a palavra-chave "iptables denied". Lá eu posso ver as conexões com falha na minha porta SSH, que se parecem com isso:
$ tail -f syslog | grep "iptables denied" | grep "DPT=22"
Mar 29 15:39:45 raspberry kernel: [ 179.988501] iptables denied: IN=wlan0 OUT= MAC=b8:27:eb:16:b3:1d:e4:b3:18:e3:47:f7:08:00 SRC=192.168.133.51 DST=192.168.133.50 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=32145 DF PROTO=TCP SPT=58723 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0
Este é o conjunto de regras para o iptables:
$ cat rules.v4
# Generated by iptables-save v1.6.0 on Mon Mar 26 22:54:58 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:LOG_AND_DROP - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 4 --name DEFAULT --mask 255.255.255.255 --rsource -j LOG_AND_DROP
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -s 192.168.133.0/24 -p igmp -m addrtype --dst-type MULTICAST -j ACCEPT
-A INPUT -s 192.168.133.1/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 192.168.133.0/24 -p udp -m udp --dport 137:138 -m addrtype --dst-type BROADCAST -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -j ACCEPT
-A LOG_AND_DROP -j LOG --log-prefix "iptables denied: " --log-level 7
-A LOG_AND_DROP -j DROP
COMMIT
# Completed on Mon Mar 26 22:54:58 2018
Se vocês quiserem, posso fornecer uma transcrição completa de uma sessão SSH bem-sucedida (com o máximo de verbosidade de depuração "-vvv") e também uma tentativa de conexão com falha (se isso ajudar a depurar).
A partir das regras do ipv4 iptables, você deve permitir 4 conexões por janela de 10 minutos.
Você espera apenas uma conexão, aquela que você mesmo tentou. Mas, outras tentativas de conexão podem ocorrer na porta 22 (este é um alvo bastante comum para verificações de portas!). Seu Raspberry Pi é exposto com um endereço ipv4 público na interface wlan0?
Veja o módulo hashlimit do iptables, ou o google "endereço de origem do limite de taxa do iptables"
Como algo mais concreto, achei isso como um exemplo:
iptables -I INPUT -m hashlimit -m tcp -p tcp --dport 80 --hashlimit-above 20/sec --hashlimit-mode srcip --hashlimit-name http -m state --state NEW -j DROP
Personalize para sua porta, taxa, etc etc.
Ou use o fail2ban, isso pode ser uma boa solução, eu só uso ele para SSH, mas ele pode proteger outros recursos por "contagem de login com falha", para que você não tropece no seu limite de taxa com logons legais. Embora você provavelmente tenha que personalizar a configuração para trabalhar em uma porta não padrão:)