BTW, jak se nftables chová při aktualizaci tabulky pravidel?
V jednom projektu mám úkol, kdy bych potřeboval průběžně měnit seznam asi 500-900 whitelistovaných IP adres.
Cca co vteřinu.
V principu mám jak kompletní seznam IP, tak i to, co se má přidat a odebrat.
Ale jak se k tomu postavit?
Jde o to, aby se to necukalo/nepřerušoval se tok dat navázaných spojení, aby aktualizace pravidel co vteřinu nedělala paseku.
Berte mě spíš s rezervou, reálně spíš používám hotové nadstavby nad nftables, jako firewalld nebo filtruji někde před servery. Ale kdybych měl řešit něco podobného, tak bych se na to snažil využít pojmenované sety, případně mapy (vmaps) v nftables. K nim by pak byla přiřazena pravidla, která bych neměnil. Tzn. programem na manipulaci bych jen přidával nebo odebíral z těch setů.. (add element, delete element).
Počítám, že při takhle časté manupulaci by program běžel pořád.. Po startu bych si vylistoval aktuální obsah toho setu z nftables a uložil do nějakého pole, seznamu v programu, pak bych si získal seznam adres z nějakého externího zdroje, porovnal a udělal nějaké dva další seznamy adres na přidání a odebrání elementů.
Ty bych nacpal do nftables a pokud by to proběhlo bez chyby, zaktualizoval bych si také ten vnitřní seznam s aktuálním stavem. Pak bych čekal až se případně změní ty externí adresy.. (nevím nějaký polling, nebo asynchornně) a jen bych to celé zopakoval. S tím, že už bych ten aktuální stav nemusel vytahovat, protože by byl v tom seznamu s aktuálním stavem.
Mělo by to jít implementovat třeba v Pythonu, kde je modul python-nftables, co používá třeba FirewallD. V podstatě je to wrapper okolo libnftables. Příkazy jsou víceméně stejné jako u nft, akorát se musí zabalit do JSON struktury.. podobně i výstupy z příkazu to vrací jako JSON.
Ale to je jen takový výkop, jak bych to zkusil sám. Možná zjistíte, že to zpracování je tak rychlé, že ty optimalizace s nějakými rozdílovými daty nemají smysl a můžete to sypat celé. Já jen vetšinou raději počítám s nějakou minimální zátěží a tím, že když mi někdo řekne, bude toho x, tak rovnou přemýšlím co se stane, až toho bude 5x
Jinak to jak jste se ptal, co jsem si kdysi zkoušel (klasicky seznam zdroj. adres, pravidlo na nová příchozí spojení), navázaná spojení a related by měla zůstat běžet i když odeberete hosta, další navázaní spojení už neprojde (klasifikace paketu nevyhoví). Jinak aktualizace rulesetu v nftables můžou být s optionem atomické (jako option -f u nft), tzn. není tam ten problém, že by třeba komplikovaný ruleset, který se nějakou dobu zpracovává (bambilion řádků) nechal filtr v mezistavu, kdy tam jsou chvíli nová i stará pravidla zároveň. Nemusí se explicitně dávat flush (který to typ. nechá neprůchozí, než se tam naládují nová pravidla).
43 Odpovědí
7173 Zhlédnutí