Vale la pena sottolineare possibili conseguenze indesiderate dell'uso della funzione LIMIT di ufw.
Supponiamo che uno abbia posto un limite generale sulla porta 22 / tcp come prima regola ufw:
To Action From
-- ------ ----
[ 1] 22/tcp LIMIT IN Anywhere
...
con il presupposto che eventuali connessioni operanti al di sotto del limite potrebbero essere filtrate seguendo le regole uww e infine la politica di default di "deny (incoming)".
Almeno per 0,35, questa ipotesi sarebbe sbagliata. In effetti la logica LIMIT IN accetta immediatamente qualsiasi input non rifiutato dal criterio limite.
In psuedocode, la logica LIMIT è
if CONDITION then DENY else ACCEPT
mentre altre regole ufw sembrano avere una logica:
if CONDITION then (DENY|ACCEPT) else continue to next rule
.
Personalmente ho scoperto che si trattava di un comportamento imprevisto per ufw LIMIT, che ho scoperto solo trovando inaspettatamente molti tentativi di accesso alla porta 22 nel file di registro di sistema che non avrebbero mai dovuto verificarsi a causa del filtraggio di altre regole ufw.
Dettagli della conferma del comportamento
Le righe pertinenti del codice iptables inserite da ufw sono le seguenti:
-A ufw-user-input -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 30 --hitcount 6 --name DEFAULT --mask 255.255.255.255 --rsource -j ufw-user-limit
-A ufw-user-input -p tcp -m tcp --dport 22 -j ufw-user-limit-accept
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
L'elenco sopra può essere creato con
iptables -S | grep ufw-user-limit
Le prime due righe sono consecutive in ufw-user-input
cui è possibile confermare
iptables -S | grep ufw-user-input