Un firewall stateful pe Linux nu se limitează la a bloca porturi. El ține minte starea conexiunilor, acceptă răspunsurile legitime și respinge traficul care nu se potrivește cu politica ta. nftables, componenta modernă din Netfilter, permite această logică într-un singur ruleset pentru IPv4 și IPv6, prin familia inet. Pentru un server mic, un VPS sau un gateway de birou, combinația dintre ct state, politici implicite de tip drop, seturi dinamice și rate limiting acoperă mult din zona practică de apărare.
Punctul de plecare trebuie să fie o consolă de recuperare sau acces fizic, mai ales dacă lucrezi prin SSH. O regulă greșită te poate scoate din server. Testează întâi într-o mașină virtuală sau programează o revenire automată, de exemplu printr-un job care restaurează configurația veche după câteva minute dacă nu îl anulezi manual.
Un schelet defensiv arată astfel:
flush ruleset
table inet filter {
set ssh_recent {
type ipv4_addr
flags dynamic, timeout
timeout 10m
size 65535
}
chain input {
type filter hook input priority filter; policy drop;
iif “lo” accept
ct state invalid drop
ct state established,related accept
ip protocol icmp limit rate 10/second accept
ip6 nexthdr icmpv6 limit rate 10/second accept
tcp dport 22 ct state new update @ssh_recent { ip saddr limit rate 3/minute burst 5 packets } accept
tcp dport { 80, 443 } ct state new limit rate 50/second burst 100 packets accept
counter drop
}
chain forward {
type filter hook forward priority filter; policy drop;
}
chain output {
type filter hook output priority filter; policy accept;
}
}
Regula cea mai importantă este ct state established,related accept. Ea permite pachetele care aparțin unei conexiuni deja acceptate și traficul asociat legitim, fără să deschizi manual porturi pentru răspunsuri. Înaintea ei merită păstrat ct state invalid drop, pentru pachete pe care connection tracking nu le poate asocia coerent cu o conexiune.
Politica implicită drop pe input și forward reduce suprafața expusă: ceea ce nu este permis explicit nu intră. Pe output, multe stații și servere mici folosesc accept, dar organizațiile cu cerințe stricte pot trece la reguli mai restrictive, cu o listă clară de DNS, NTP, update-uri și servicii interne. Nu copia această decizie mecanic. Un firewall prea dur, dar netestat, ajunge repede să blocheze backupuri sau actualizări.
Seturile dinamice sunt partea care face nftables interesant pentru abuzuri repetitive. În exemplu, ssh_recent reține adrese IPv4 care încearcă sesiuni noi SSH și atașează un limitator per sursă. Sintaxa update @set { ip saddr limit rate … } folosește infrastructura de seturi dinamice și expresii stateful documentată de nftables. Timeout-ul curăță automat intrările vechi, iar size limitează memoria folosită. Pentru IPv6 ai nevoie de un set separat cu type ipv6_addr și reguli echivalente pe ip6 saddr.
Rate limiting-ul nu este o soluție anti-DDoS. Dacă linia ta de internet este saturată, firewallul local vede traficul prea târziu. Este însă util pentru zgomot, scanări banale, încercări repetate de autentificare și protejarea serviciilor care nu trebuie să accepte un volum mare de conexiuni noi. Pentru servicii publice reale, valorile trebuie ajustate după trafic, loguri și capacitatea aplicației.
Înainte să încarci configurația, verifică sintaxa cu nft -c -f /etc/nftables.conf. Dacă trece, aplică nft -f /etc/nftables.conf și verifică prin nft list ruleset. Persistența diferă între distribuții: Debian și Ubuntu folosesc de obicei serviciul nftables cu /etc/nftables.conf, Arch documentează systemd și fișierul nftables.conf, iar distribuțiile enterprise pot integra reguli prin firewalld sau politici proprii. Nu amesteca reguli generate de firewalld cu fișiere editate manual fără să înțelegi cine le suprascrie.
Pentru operare zilnică, logarea trebuie folosită cu măsură. Un counter drop este sigur și discret. Logarea fiecărui pachet respins poate umple discuri și poate ascunde evenimentele importante. Dacă ai nevoie de jurnalizare, aplică limit rate și prefixe clare.
Un firewall bun cu nftables este mic, citibil și testat. Începe cu politici implicite, păstrează connection tracking-ul în centru, folosește seturi dinamice doar unde ai o problemă repetitivă și verifică regulile după fiecare modificare. Securitatea reală vine din configurații pe care le poți explica și reface, nu din ruleset-uri copiate la întâmplare.
