nftables - limita comportamentului ratei (eroare sau utilizare greșită?)

Încerc să configurez un firewall cu nftables, dar nu am reușit să înțeleg și să implementez o limită simplă de rată bazată pe documentația pe care am găsit-o.

• OS: Ubuntu 20.04 LTS
• Versiunea nftables: 0.9.3 (Topsy)
• lansarea nucleului: 5.8.0-53-generic

Am construit paravanul de protecție de testare cu secvența de comenzi de mai jos:

nft „adăugați tabel inet testnetwork”
nft 'add chain inet testnetwork INPUT { tip filter hook priority input 0; scăderea politicii; }'
nft 'adăugați set inet testnetwork SSH { tip ipv4_addr; steaguri dinamice, timeout; marime 65536; }'
nft „adăugare regulă inet testnetwork INPUT ct stare legată, contor stabilit acceptare”
nft „adăugați regulă inet testnetwork INPUT ip saddr @SSH ct state new tcp dport 22 counter drop”
nft „adăugați regulă inet testnetwork INPUT ct state new tcp dport 22 limit rate over 10/minute add @SSH {ip saddr timeout 60s} counter”
nft „adăugați regulă inet testnetwork INPUT ct state new tcp dport 22 tcp sport 1024-65535 counter accept”

Când listez setul de reguli inițial, primesc:

tabel inet testnetwork {
    setați SSH {
        tastați ipv4_addr
        marime 65536
        steaguri dinamice, timeout
    }

    lanț INPUT {
        tip filtru cârlig intrare filtru prioritar; scăderea politicii;
        Starea ct stabilită, pachetele de contor corelate 0 octeți 0 acceptă
        ip saddr @SSH ct stare nou tcp dport 22 contoare pachete 0 octeți 0 picătură
        ct state new tcp dport 22 limit rate peste 10/minut adăugați @SSH { ip saddr timeout 1m } numărătoare de pachete 0 octeți 0
        stare ct nou tcp dport 22 tcp sport 1024-65535 contor pachete 0 octeți 0 accept
    }
}

Cu o astfel de configurație, m-aș aștepta ca un IP să fie adăugat la setul SSH la a 11-a (nouă) încercare de conectare în decurs de 1 minut și să fie blocat (timp de 1 minut) începând cu a 12-a încercare.

Cu toate acestea, când deschid o a doua fereastră de terminal și inițiez secvențial și apoi închid mai puțin de 10 conexiuni ssh la 127.0.0.1, primesc IP-ul adăugat la setul SSH și apoi blocat.

Mai jos starea setului de reguli la a 7-a încercare:

tabel inet testnetwork {
    setați SSH {
        tastați ipv4_addr
        marime 65536
        steaguri dinamice, timeout
        elemente = { 127.0.0.1 timeout 1m expiră 54s564ms }
    }

    lanț INPUT {
        tip filtru cârlig intrare filtru prioritar; scăderea politicii;
        Starea ct stabilită, pachetele de contor corelate 156 octeți 28692 acceptă
        ip saddr @SSH ct state new tcp dport 22 contor pachete 3 octeți 180 drop
        ct state new tcp dport 22 limit rate peste 10/minut add @SSH { ip saddr timeout 1m } contor pachete 1 octet 60
        stare ct nou tcp dport 22 tcp sport 1024-65535 contor pachete 6 octeți 360 accept
    }
}

În acest moment, fie nu înțeleg corect mecanismul ratei limită, fie am făcut o greșeală în altă parte.

Poate cineva să mă ajute, vă rog, subliniind dacă așteptările mele sunt greșite sau de unde ar putea veni greșeala?

Salutări și mulțumiri pentru timpul acordat

Pe VPS-ul meu

sshPort=2222
nft adăugați tabel ip sshGuard
nft add chain ip sshGuard input { tip filter hook input priority 0 \; }
nft add set ip sshGuard denylist { tip ipv4_addr \; steaguri dinamice, timeout \; timeout 5m \; }
nft adăugare regulă ip sshGuard intrare tcp dport $sshPort ct stare nou ip saddr @denylist respingere
nft add rule ip sshGuard input tcp dport $sshPort ct state noua limita rata peste 2/minut burst 3 pachete adauga @denylist { ip saddr } respinge
nft list table ip sshGuard

Testez de câteva ori (fiecare cu nft flush set ip sshGuard denylist), a 4-a conexiune va fi respinsă. Dacă schimb rată limită peste 2/minut burst 3 pachete la rată limită peste 2/minut, o respingere vine după 7-9 conexiuni. Prin urmare, nu cunosc mecanismul exact al rată limită peste 2/minut, dar a sparge 3 pachete pare să facă lucrurile mai sigure.

Implicit izbucni este stabilit de #define NFT_LIMIT_PKT_BURST_DEFAULT 5

Aș dori să îmi cer scuze pentru feedback-ul meu întârziat, am avut alte urgențe pe stivă și, în cele din urmă, am ajuns cu sarcina care necesita această întrebare.

În primul rând, mulțumesc foarte mult @A.B pentru răspunsuri și ajutor.Nu cunoșteam „algoritmul token bucket” și am ajutat la înțelegerea procesului general, în special „rata”, în sensul că nucleul, așa cum ați menționat, nu așteaptă 1 minut pentru a face ceva.

De asemenea, mulțumesc lui @Chen Deng-Ta pentru testele tale.