Firewall nftables v Linuxu 3.13

Po ipfwadm, ipchains a iptables přichází nftables. Phoronix informuje, že firewall nftables, jehož cílem je (časem) nahradit stávající {ip,ip6,arp,eb}tables se dostal to linuxové vývojové větve net-next a měl byl být začleněn do Linuxu 3.13. [Slashdot]

21.10.2013 13:29 | Ladislav Hagara | Zajímavý software

Komentáře

[Michal Kubeček]

Spíš jsem doufal v xtables2, ale holt bylo asi předem jasné, že to musí dopadnout takhle.

[little.owl]

(a) xtables2 - proc byste je preferoval?

(b) proc to podle vas bylo predem jasne?

[Michal Kubeček]

Ad (a) viz níže, ad (b): poté, co Pablo Neira Ayuso před rokem smetl ze stolu pull request na přidání xtables2 s tím, že to nemá smysl, protože se stejně bude přecházet na nftables, bylo by pro mne velkým překvapením, kdyby to dopadlo jinak.

[jadd]

ntfables

[petr_p]

Tou náhradou si jist nejsem. Současný mechanismus umožňuje úpravy po krocích (přidat, odebrat jedno pravidlo). Nový musí zkompilovat všechna pravidla a nahradit jimi celou konfiguraci. Co to udělá se stavovým firewallem? Co když v překladači bude chyba a vyrobí automat bez koncového stavu? Zavádění takového kódu asi nebude příliš kompatibilní se secure bootem.

[Conscript89]

Tak zrovna tady bych se secure bootu nebal (pokud bude automat jen jako struktura).

[jbohac]

Současný mechanizmus právě neumožňuje úpravy po krocích - to tak jen vypadá. Každý iptables -I nebo iptables -A načte celou tabulku z kernelu, přidá záznam na začátek nebo konec, a pak o jednu položku delší tabulku zase do kernelu naláduje. Takže složitost n^2 jak vyšitá.

Proto je iptables-save/iptables-restore o tolik rychlejší při větším počtu pravidel.

[little.owl]

Zavádění takového kódu asi nebude příliš kompatibilní se secure bootem.

Virualni masina v kernelu je nekompatibilni se SB?

[Michal Kubeček]

Pokud jde o bytecode, tak není. Problém by byl jedině kdyby se do jádra natahoval skutečný spustitelný kód (nebo by se to umožnilo). Bytecode by mohl při chybné implementaci znamenat bezpečnostní problém, ale ne problém z hlediska "Secure Bootu".

[deda.jabko]

Problém by byl jedině kdyby se do jádra natahoval skutečný spustitelný kód

Tusim, ze FreeBSD to tak ma, i kdyz strojovy kod se generuje az v jadre. Uvazovalo se, ze by to tak mohly mit i nftables, ale co jsem videl diskuzi, tak byl problem s knihovnami na generovani kodu, protoze nebyly vhodne pro pouziti v kernel modu.

[little.owl]

Mit netfilter s nejakym JIT/hotspot by byla frajerina.

[chrono]

Keďže pre Berkeley Packet Filter je v jadre JIT, tak predpokladám, že skôr či neskôr bude niečo podobné aj pre nftables.

[hans kohn]

Však my ty backdoors do těch linuxů protlačíme!

[potato]

nsatables?

[j]

No nevim, me to prijde presne na tema ... proc delat veci jednoduse, kdyz to jde slozite. Mrknul sem se lehce na syntax ... a narozdil od iptables mi prijde, ze to ma daleko vetsi prostor pro vsemozny zamotanosti, kdy se v pravidlech nikdo nevyzna.

[Michal Kubeček]

To sice ano, ale omezení současného modelu také způsobují, že jejich obcházení často vede k velmi nepřehledným výsledkům.

[Jiří J.]

Čistě ze zvědavosti - poukažte prosím na pár případů "obcházení".

Já vím třeba o NOTRACK, resp. CT --notrack, což inicializuje v kernelu falešný conntrack záznam, aby se packet mohl tvářit jako UNTRACKED, ale to není zrovna problém *modelu*. Nebo snad výkonnostní problémy s velkým počtem pravidel a "obcházení" ipsetem?

Současný model je spíš problematický v tom, že umí až moc a nedá se proto jednodušše optimalizovat - pravidla se musí procházet jedno po druhém, spousta volání funkcí z různých modulů, ... Na druhou stranu to ale přidává možnosti, které žádný jiný OS nemá - pěkný seznam je v xtables-addons. Nemluvě o velmi snadném způsobu napsat si a zkompilovat vlastní modul.

Tak trochu mi totiž přijde, že vedle většího potenciálu pro optimalizaci vznikly nftables spíš protože "admini mají rádi BSD-like pf".

[Michal Kubeček]

Čistě ze zvědavosti - poukažte prosím na pár případů "obcházení".

Asi nejtypičtější příklad je, že není možnost přímo udělat logické "or" podmínek a je třeba ho obejít např. tak, že se pomocí pomocného chainu zneguje "and" jejich negací. Je-li to potřeba provést v komplexnější konfiguraci víckrát, přehlednost tím hodně utrpí.

Tak trochu mi totiž přijde, že vedle většího potenciálu pro optimalizaci vznikly nftables spíš protože "admini mají rádi BSD-like pf".

Jak už jsem napsal v první reakci, radši bych tam viděl xtables2, protože si nemyslím, že by stav netfilteru byl tak hrozný, aby ho bylo potřeba zahodit a začít od nuly a úplně jinak. Ale Jan Engelhardt holt není maintainer subsystému.

[little.owl]

aby ho bylo potřeba zahodit a začít od nuly a úplně jinak.

Aha, to je asi castecna odpoved na vyse polozenou otazku.

Naopak, kdyz kopat, tak poradne, je treba protocit mozkove zavity linych adminu ... .

[Michal Kubeček]

Naopak, kdyz kopat, tak poradne, je treba protocit mozkove zavity linych adminu ... .

No, uvidíme, jak pochodím s návrhem vyhodit ifconfig a spol. z defaultní instalace OpenSuSE 13.2 :-)

[lertimir]

už se těším.

[Jendа]

Cože? Vždyť nefunguje teprve 15 let!

[...]

prijemnou zabavu.

jinak teda autorovi iproute2 zprerazet pracky za to lomitko se subnetem. pastnout adresu virtualu je pak radne nasiraci, kdyz to clovek dela po milionte prve tech "par ukonu navic" to uz radsi tahat leasy skriptem z dnsmasqu libvirtu, jenze tam nejsou staticky alokace.

[lertimir]

Čistě ze zvědavosti - poukažte prosím na pár případů "obcházení".

Asi nejtypičtější příklad je, že není možnost přímo udělat logické "or" podmínek a je třeba ho obejít např. tak, že se pomocí pomocného chainu zneguje "and" jejich negací. Je-li to potřeba provést v komplexnější konfiguraci víckrát, přehlednost tím hodně utrpí.

Nikdy jsem to nepotřeboval, ale to se skutečně dělá na tvrdo před de Morganovy zákonay (A OR B)=NON ((NON A) AND (NON B)) ?

[Michal Kubeček]

No, to jsem trochu popletl. Čistý "or" lze samozřejmě většinou obejít sérií pravidel se stejnou akcí, případně proloženou RETURNy pro případ, že se podmínky nevylučují a akci nesmím provést dvakrát (pokud tedy podmínka nemá side-effect, takže se musím vyhnout jejímu opakovanému vyhodnocení), ale také to není nic povznášejícího a oku lahodícího. Jinak jsem se dost často setkával se situacemi, které jsem neuměl řešit jinak než pomocným chainem, do kterého se poslalo všechno a ze kterého se vyhazovaly pakety přes pravidla s akcí RETURN a nakonec se pro zbytek provedlo to, co bylo potřeba. Ale to se hodí spíš na situace, kdy naopak potřebuju provést "and" a ty podmínky nejdou z nějakých důvodů dát do jednoho pravidla.

[mj]

Mě se tedy ta syntaxe líbí podstatně více než iptables, přijde mi mnohem přehlednější. Stejně jako třeba ip vs ifconfig/route/atp. ip je podstatně lepší.

[pavel]

Příkaz "ip link set dev eth0 up" mi také přijde mnohem přehlednější, než "ifconfig eth0 up".

[Michal Kubeček]

Možná tak na první pohled nevypadá, ale na rozdíl od toho druhého opravdu udělá to, co po něm chcete.

[petr_p]

S tím byl bych opatrný. Poslední dobou se v iproute hrabu víc, než mi je milé, a že bych mu zrovna dva krát věřit, to se říci nedá.

[Michal Kubeček]

Ne že by v iproute2 chyby nebyly, zvlášť při tom, co všechno se tam v poslední době přidávalo (a stále přidává). Ale jsou to chyby a jako chyby se opravují. Na rozdíl od historických nástrojů, které místo skutečné konfigurace pracují jen s jakousi aproximací její malé části, takže jejich problémy jsou principiální a neopravitelné.

[Michal Kubeček]

Ale abych nebyl nespravedlivý, netýká se to samozřejmě jen ifconfigu a spol. Nedávno jsem třeba řešil bug v ISC dhcpd (v upstreamu už mezitím opravený), který byl způsoben právě tím, že démon získával informace o lokálních adresách přes zastaralé ioctl rozhraní. A takových případů budou ještě spousty. Koneckonců se stačí podívat na to, kolik serverových aplikací podle dokumentace umožňuje nastavit "rozhraní, na kterém program poslouchá", přestože je to také už dávno nesmysl.

[David Jaša]

Koneckonců se stačí podívat na to, kolik serverových aplikací podle dokumentace umožňuje nastavit "rozhraní, na kterém program poslouchá", přestože je to také už dávno nesmysl.

SO_BINDTODEVICE je už dávno nesmysl?

[Michal Kubeček]

Není, ale kolik z těch programů používá SO_BINDTODEVICE? Pochybuji, že to bude aspoň 10 procent, zvlášť když většina má jako argument příslušné konfigurační direktivy adresu.

[msk]

Příkaz "ip link set dev eth0 up" mi také přijde mnohem přehlednější, než "ifconfig eth0 up".

Mne tiez. A desim sa, ked ifconfig z distribucii vypadne, pretoze potom som v prdeli. Syntax 'ip' sa totiz zarucene nikdy nenaucim.

[petr_p]

A co teprve příkaz na přidání dvojice veth zařízení! To nejsem schopen dát dohromady ani s pomoci ip link help, ani man ip-link.

[Michal Kubeček]

Zatímco pomocí ifconfig to dáte z hlavy?

[petr_p]

Narážím na bídnou dokumentaci iproute2. Chápu, že se vývojáři nechtějí zdržovat s dokumentací, ale z hlediska uživatele je to tragédie. Třeba věci kolem bridge jsou taky lahůdka. A to není žádný historický kód, ale věci, které se začleňují právě teď. Kdo bys si pomyslel, že v dnešní pokrokové době někdo vezme patch bez dokumentace.

[Michal Kubeček]

A já zase narážel na to, že jste si jako příklad vybral zrovna něco, co pomocí historických nástrojů udělat AFAIK nejde.

Dokumentace iproute2 je nepochybně nedostatečná. Ale IMHO to je spíš argument pro práci na jejím zlepšení než pro zatracování iproute2 a propagaci obsolentních nástrojů, které čím dál víc zaostávají za možnostmi, které jádro nabízí, a v některých případech nedělají správně ani to, co se tváří že umějí.

[Michal Kubeček]

Tak to byste se měl obávat už teď, protože už teď to silně omezuje vaši kvalifikaci coby správce linuxových systémů. Vezměme si namátkou pár jednoduchých příkladů:

  ip link add mv1 link eth1 type macvlan mode bridge
  ip link set mv1 netns abc
  ip link add veth0 type veth peer veth1
  ip addrlabel show
  ip route show table local
  ip route add unreachable 1.2.3.4
  ip rule show
  ip rule add priority 1000 fwmark 1 table 100
  ip netns add test
  ip netns exec test /bin/bash
  ip tunnel add sit1 mode sit local 1.2.3.4 remote 5.6.7.8

Jak vypadají ekvivalenty pomocí vámi používaných příkazů? Jsou také přehlednější?

[Jendа]

Vezměme si namátkou pár jednoduchých příkladů:

Já bych zkusil začít s mnohem kratšími a snad nejčastěji používanými příkazy:

ip a a 1.2.3.4/24 dev eth0 # ifconfig nejspíš nezvládne provést pro dvě adresy
ip a # ifconfig nezobrazí některé adresy

[Michal Kubeček]

Jistě, ale na to se dá namítnout, že když se to bude konfigurovat výhradně pomocí ifconfig a fiktivních virtuálních rozhraní (a doufat, že mu do toho nezasáhne někdo jiný, např. distribuční init skripty), tak se na problém nenarazí (tedy aspoň do chvíle, kdy se těm fiktivním rozhraním pokusí něco nastavit), a do této diskuse jsem tentokrát zabřednout nechtěl. Proto jsem také v příkladech nepoužil nic kolem VLAN, bridge nebo bondingu, protože na to existují alternativní nástroje (vconfig, brctl, ifenslave).

[Jendа]

Mne tiez.

Hlavně je to nesmysl, stačí ip l s eth0 up. Pro porovnání délky vypsáno pod sebou:

ip l s eth0 up
ifconfig eth0 up
ifco eth0 up # s použitím tab completion shellu

Přijde mi, že to vyjde nastejno.

Syntax 'ip' sa totiz zarucene nikdy nenaucim.

Zajímavé, mně naopak pro často používané věci (typu přidání a odstranění adresy a routy) přijde zapamatování snazší u ip. A ty složitější věci stejně hledám v manuálu nebo googlím.

[little.owl]

přijde zapamatování snazší u ip

Mne take.

[bigBRAMBOR]

jsem na tom podobne, nechci řikat co je lepší nebo horší syntaxe, to je věc názoru, a pocitu každého jedince zvlášť, a nemám na to patent, tem tady má někdo jinej. Ocenuju moznost psat pravidla pro IPv4 i IPv6 zaroven, i zvlast na jednom miste, ale jinak je to tak jak rikas, tenhle typ syntaxe nemám rád. Lépe se mi letmým pohledem očí hledá -d než daddr, a násobení IP při více podmínkách, no..... bude to krása - ip filter output ip protocol icmp ip daddr

[little.owl]

Pokud se nekdo pta proc nftables, projdete si slidy a video z nedavne prednasky Eric Leblond zde.