NFTABLES —
Nelle nuove distribuzioni Debian e derivate (ormai è chiaro anche ai sassi che sia a livello personale che aziendale uso Devuan) il programma di default per il packet filtering e’ nftables
Quindi un po perché anche se non immediatamente il supporto a iptables diminuirà e quindi cesserà, un po perché stando alla documentazione nftables è molto più performante del suo predecessore, un po perché sono curioso come una scimmia e, come dicono i miei Amici trentini ho una speciale attitudine a portare il qlo nelle pedate, mi sono messo a studiare nftables.
la logica di creazione su nftables è la seguente:
tabelle che contengono catene che contengono regole
table
|
chains
|
rules
su nftables posso creare tabelle e catene coi nomi che voglio il comando è nft add
nft add table inet noddos
comando oggetto tipo nome
il tipo e’ il namespaces della famiglia indirizzi che sono
arp (era arptables)
bridge (era ebtables)
inet (=ip+ipv6)
ip (ipv4)
ip6 (ipv6)
netdev Consente il filtraggio anticipato del traffico, prima che raggiunga altri filtri (sotto il livello 3 sul modello OSI) e per esempio questo metodo è molto efficiente contro il DDoS
nft add chain inet noddos ingress { tipo filter hook ingress priority 0 \; }
come sopra add chain a noddos(nome tabella) ingress(nome chain)
il tipo puo’ essere
filter
route
nat
lo hook si riferisce a uno stadio specifico del pacchetto mentre attraversa il kernel e puo’ essere:
per le famiglie ip ip6 inet
prerouting
input
forward
output
postrouting
per la famiglia arp puo’ essere:
input
output
per la famiglia bridge sono gli stessi di ip/ip6/inet
per la famiglia netdev l’unico hook è ingress.
Nftables ha una sua grammatica, i creatori di nftables sconsigliano l’uso come in passato per iptables di script in bash perché rompono l’atomicità delle regole.
Detto così non vuole dire un piffero, e ci ho messo un po a capire cosa intendessero poi alla fine ci sono arrivato leggendo attentamente il wiki di cui riporto qui sotto una maccheronica traduzione:
“Con iptables era comune utilizzare uno script bash composto da più comandi iptables per configurare un firewall. Questo non è ottimale perché non è atomico, vale a dire che durante le poche frazioni di secondo che il tuo script bash impiega per eseguire il tuo firewall è in uno stato parzialmente configurato. Nftables introduce la sostituzione atomica delle regole con l’opzione -f. Questo è diverso dagli script bash perché nftables leggerà tutti i file di configurazione inclusi, creerà l’oggetto di configurazione in memoria insieme alla configurazione esistente, e quindi in un’operazione atomica scambia la vecchia configurazione con quella nuova, il che significa che non c’è momento in cui il firewall è parzialmente configurato.”
Onestamente la mia preparazione non è cosi grande da capire appieno e perfettamente le implicazioni di tutto ciò, intuitivamente capisco che uno stato totalmente configurato è preferibile a uno parzialmente configurato, quello che mi sfugge anche perché non ho trovato letteratura in materia è per quanto tempo il sistema resta in condizione di semi configurazione, credo che il fattore tempo sia importante, se sono millisecondi è un conto se sono secondi un altro, però la logica mi dice: se della gente che fa questo di mestiere e che crea degli standard de facto dice che è così tu fai quello che ti dicono che non sbagli mai.
Tra parentesi ho avuto modo di interagire direttamente con Pablo Neira Ayuso capo del team di netfilter sulla ml netfilter e ho trovato una persona squisita a dire poco.
Lo strumento per verificare la correttezza della grammatica e’ nft — (sono 2 meno)check –(sono 2 meno)file /path/nome_del_file
Oltre alle mie configurazioni ho inserito anche uno script in perl che fa download di liste di indirizzi crea dei set e li nega.
parametri del kernel da passare all’avvio
ale401.sh
vars.sh
definitions
ale.nft
ale2.nft
blocklist.pl
logging
Categorised as: firewall | Linux | Networking | Work
Comments are disabled on this post