Jaderné noviny – 10. 1. 2013: Náhrada iptables - Xtables2, nebo nftables?

28. 1. 2013 | Luboš Doležel

Články - Jaderné noviny – 10. 1. 2013: Náhrada iptables - Xtables2, nebo nftables?  

Aktuální vývojová verze: 3.8-rc2. Citáty týdne: Casey Schaufler, Frederic Weisbecker. Xtables2 vs. nftables.

Obsah

• Aktuální vývojová verze: 3.8-rc2
• Citáty týdne: Casey Schaufler, Frederic Weisbecker
• Xtables2 vs. nftables

Aktuální vývojová verze: 3.8-rc2

Aktuální vývojová verze je nadále 3.8-rc2; žádné další předverze za uplynulý týden nevyšly.

Stabilní aktualizace: verze 3.2.36 vyšla 4. ledna.

V době psaní tohoto textu se verze 2.6.34.14, 3.0.58, 3.4.25 a 3.7.2 revidují; jejich vydání lze očekávat po 11. lednu.

Citáty týdne: Casey Schaufler, Frederic Weisbecker

Dříve jsem věřil v jediný integrovaný bezpečnostní modul, který řešil všechny problémy. Teď, když Linux podporuje všechno od real-time ukazatelů tlaku pneumatik u tříkolek až po seznam teroristů, co nesmí do letadel, už to nevypadá rozumně. Měli bychom změnit své rozhodnutí ohledně dodatečných mechanismů. To znamená sadu menších, jednodušších LSM místo monolitů, které dokáže správně nastavit jen skupinka vyvolených jedinců nebo firem.

-- Casey Schaufler

No, aspoň to padá bezpečně.

-- Frederic Weisbecker

Xtables2 vs. nftables

Podpora firewallu a filtrování paketů v linuxovém jádře doznala za uplynulá léta mnoho změn. V roce 2009 se zdálo, že nový filrovací mechanismus nftables bude pro Linux řešením přístí generace. Na Jaderném summitu 2010 bylo zmiňováno jako řešení, které by mohlo mít uplatnění i jinde než v netfilteru. Jenže vývoj nftables ustal a až v roce 2012 byl vzkříšen správcem netfilteru Pablem Neirem Ayusem. V mezičase ale vznikala jiná, postupná úprava kódu netfilteru; v polovině prosince pak bylo Janem Engelhardtem k začlenění navrženo Xtables2. Mnoho problémů ve stávajícím kódu se řešit shodně snaží obě tato řešení, proto je pravděpodobné, že začleněno bude jen jedno z nich – a o tom se právě debatuje.

Na Xtables2 se pracuje přibližně od roku 2010; na workshopu Netfilteru měl o tomto Engelhardt přednášku. Během uplynulých let příležitostně posílal informace o průběhu práce, ale tempo jak těchto informací, tak vývoje se zrychlilo poté, co Neira v říjnu zveřejnil svůj záměr obnovit vývoj nftables. Kvůli tomu bude obtížné – ne-li nemožné – aby oba projekty měly úspěch, buď se budou muset sloučit, nebo jeden z nich prostě zvítězí.

Alespoň prozatím se Neira a Engelhardt neshodli na tom, jakým směrem by se netfilter měl vydat. Po říjnovém oznámení o nftables Engelhardt poukázal na to, že jedna z chybějících funkcí v nftables, co Neira zmiňoval, v Xtables2 už je: atomická výměna tabulky a atomický dump. Neirův návrh, že by se Engelhardt mohl podívat na to, jak funkci přidat do nftables, byl odmítnut. Neira také řekl, že by bylo *extrémně těžké* odůvodnit začlenění Xtables2 do hlavní řady. To Engelhardtovi a snad i jiným znělo jako předsudek namířený proti začlenění Xtables2, které by bylo opravdu neveselé, jak Neira řekl. Pokračoval tedy výčtem užitečných funkcí v Xtables2 včetně podpory síťových jmenných prostorů, rozhraní netlink, podpory RCU, atomických chainů, nahrazování tabulek a tak dále.

Velká část Neirova oznámení se týkala „vrstvy pro kompatibilitu“, která by byla při náhradě stávajícího kódu nezbytná. iptables jednoduše používá příliš mnoho lidí, aby bylo možné se na ně vykašlat – navíc je tu pravidlo nerozbíjet jaderné ABI. Proto po určitou dobu bude muset v jádře být jak stávající kód, tak nějaké nové řešení. Časem pak bude starý kód odstraněn.

Jedním problémem, který nftables i Xtables2 řeší, je duplikace kódu, jenž je ve stávající implementaci netfilteru (často se jí říká „xtables“) přítomen. Protože se v tomto kódu pracuje s protokoly, bylo nutné udělat čtyři kopie, aby se řešily různé případy: IPv4, IPv6, ARP a síťové mosty (bridge). To určitě není optimální. Xtables2 i nftables to řeší, rozdíl je ale v tom jak. V Xtables2 se používá jediná tabulka nezávislá na protokolu pro každý síťový jmenný prostor, kdežto nftables definují nový virtuální stroj pro zpracování paketů. V podstatě jde o to, že (jak název napovídá) Xtables2 je rozvojem stávajícího kódu, kdežto nftables je hlubším přepisem.

Tento rozdíl v přístupu je zjevný z debaty kolem žádosti o začlenění, kterou Engelhardt podal. Neira není nabízenými funkcemi ohromen, ale stěžuje si i na to, že Xtables2 dědí po iptables spoustu návrhových rozhodnutí, která pocházejí z devadesátých let. Překvapení se nekoná, Engelhardt na to má jiný názor:

nf_tables také zachovává některá rozhodnutí z „pozdních devadesátých let“.

Dle mého názoru není nic špatného na zachování určitých konceptů. Od vývojáře se přece nečeká, že bude přehodnocovat a předělávat každý koncept jen z principu. (Staré pravidlo „evoluce místo revoluce“.) V dnešní době není všechno zahodit dobrým rozhodnutím.

Neira ale říká, že nftables je stěží revoluce, protože implementuje zpětnou kompatibilitu: revoluce nikdy zpětně kompatibilní nejsou. Debata se dále točila kolem podobností těchto dvou přístupů; obě strany tvrdily, že jejich řešení zvládne to samé, co to druhé.

Přesto jsou mezi nimi rozdíly. Xtables2 se zdá být dále jak co se týče kódu, tak dokumentace a plánu vývoje. Jak Neira poznamenal, odmlka ve vývoji projekt v různých směrech zbrzdila, ale zatím nedokáže poskytnout podrobnosti:

Chápu, že byste o budoucnosti nftables rádi věděli více, ale já už jsem takový, že nedám na plané řeči a spíš se o tom pobavíme, až to bude napsané.

Proto bych vás chtěl požádat o trpělivost. Jakmile budou hlavní funkce hotové, tak se pokusím dodat co nejvíce informací.

Máme tu tedy dva soupeřící návrhy, kam dále posunout netfilter, jeden z nich je podle Engelhardta už z větší části hotov (ale jistě není hotový) a ten druhý je stále v aktivním vývoji hlavních věcí. Ačkoliv dříve bylo nftables vnímáno jako nástupce, utrpělo nedostatkem zájmu po dobu několika let, zatímco Xtables2 se sunulo kupředu.

Je jasné, že Engelhardt a Neira upřednostňují své vlastní řešení a nevypadá to, že by se jeden chtěl spojit s tím druhým. Engelhardt naznačil že není zastáncem zahození nftables, ale spíše se zaměřuje na to, jak dostat Xtables2 k lidem:

Je třeba si přiznat, že jsem nikdy neříkal nic o zahození nftables. Zaměřuji se na xt2, jeho začlenění a následnou údržbu, protože to řeší nedostatky ipt způsobem, který podle mě zaujme uživatele nejvíce.

Neira navrhl, aby na letošním workshopu Netfilter (bude se konat v polovině roku) proběhla diskuze, kde by se spor měl rozřešit. Ačkoliv Engelhardtovi tak dlouhé čekání trochu vadí, pár měsíců na to může být potřeba, jak řekl Jozsef Kadlecsik: Nftables i xtables2 mají hezké funkce, takže není snadné rozhodnout. David Miller, správce síťového subsystému, s Neirovým návrhem souhlasí.

I když může být technicky možné začlenit Xtables2, pak postupně odstraňovat staré rozhraní a přejít na nftables, až bude hotové, spíš to tak nedopadne. Pokud jsou vývojáři (a údržbáři) netfilteru přesvědčeni, že nftables je správnou cestou vpřed, pak přeskočení mezikroku s Xtables2 bude dávat smysl. To sice může znamenat, že si na řešení dlouhotrvajících problémů počkáme déle, ale určitě se nehrozí, že by se v jádře udržovaly tři různé mechanismy.

Diskuse k tomuto článku

[Peto_MiG]

Keď sa začalo hovoriť o nástupcovi iptables, povedal som si, že ešte počkám a nebudem hneď prepisovať svoje skripty. Zdá sa, že som sa rozhodol správne. Predpokladám, že než sa definitívne ukončí podpora pre iptables, bude aspoň konečne jasné, akým smerom sa pobrať. Nechcem sa každých 5 rokov učiť nový systém ktorý vie +- to isté ako ten starý.

[petr_p]

Mám pocit, že nftables fungují úplně jinak: V uživatelském prostoru se pravidla zkompilují do automatu, který se pak nahraje do jádra, kde jej interpretuje virtuální stroj. Takže na rozdíl od současného netfilteru je možné vytvořit zcela nová „pravidla“, která vůbec nemají, protože nepotřebují, podporu v jádře. V tomto smyslu jsou nftables obecnější.

[Petr Tomasek]

Daji se do toho jadra nahrat taky viry?

Aneb at zije bytecode

[j]

Ja sem si o tom onehda taky celkem pocet, nejdriv sem se vydesil a pak celkem uklidnil ... 1) bude nejspis trvat cely roky, nez se vubec pripadne rozhodne o nejaky zmene (takze zatim sem klidnej s iptables) 2) umi to spoustu ficur, ktery "nikdo" nanic nepotrebuje (Def: nikdo budiz infinitezimalni mnoztvi silenych adminu - tedy ti, kterych by se i dr Chocholousek zrekl) 3) i pro iptables existujou zcela obecny filtry, ktery umouznujou definovat celkem libovolny pravidlo, ovsem samo za cenu ... vykonu

BTW: Jinak sem to pochopil tak, ze by to i s novym "backendem" melo umet pouzit stavajici pravidla. BTW2: Zacina me linux(obecne) cim dal vic srat tim, ze se ze vseho delaj binarni sracky ala widle ... v XP jeste slo editovat boot menu upravou textaku, ve Vistach uz ne ... grub1 vs grub2 ... initd vs systemd ... takze to co si clovek moh opravit pokud umel cist a psat ted bude resit s nejakym kompilatorem ... a kdyz se neco podela, tak bye bye konfigurace ... (zrovna nedavno sem zachranoval konfiguraci z poskozeneho disku, diky textakum se povedlo temer vse)

[Luboš Doležel (Doli)]

grub2 si může člověk plně upravovat stejně jako grub1.

[Pavel 'TIGER' Růžička]

Ano může, ale jaksi tomu chybí už ona jednoduchost. Nicméně dá se na to zvyknout. Stejně jako LILO --> Grub. Je však otázkou, jestli je správné staré zvyky zahodit a zvykat si na nové, když by všechny ty fičury šli udělat pomocí nějakého rozšíření, které by buď člověk chtěl použít, nebo ne. Pravda, u zavaděče to není asi nejlepší příklad. Nicméně souhlasím s tí, že jednoduchost se nám ze systému nějak vytrácí, hlavně, že máme omalovánky. Jak důležité .....

[pavlix]

Ano může, ale jaksi tomu chybí už ona jednoduchost.

Ani jsem si nestačil za ty roky všimnout.

[j]

Takze tvrdis, ze kdyz si z libovolny placky primontuju boot a zmenim jeden textak, bude to fungovat?

[stativ]

Samozřejmě. Nebo si myslíš, že Grub2 má nějakou binární konfiguraci či co?

[Jendа]

Ano.

[Jendа]

Při přechodu z GRUBu na GRUB2 jsem si nevšiml žádného zásadního rozdílu. V čem je problém? Co ti tam jde nastavit moc složitě?

[j]

Problem je presne v okamziku, kdy nastane ten problem - trebas ze z nejakyho duvodu ten system nenastartuje. V pripade grubu1 v 99% pripadu stacilo lehce postelovat jeden textovej soubor, ze ... a nemusel k tomu clovek ani ten grub mit.

[stativ]

A co ti v tom u Grubu2 brání?

[Jendа]

A v případě GRUB2 není konfigurace v jednom souboru (/boot/grub/grub.cfg)?

[djz.88]

V debianu jsem tuhle musel menit 2-3 soubory v /etc/grub.d a jeden /etc/default/grub.

[Honza Jaroš]

To ovšem, pokud se nepletu, musíte v Debianu dělat i při použití grub-legacy. Rozdíl je jen v tom, že 'dpkg-reconfigure grub-legacy' vám vygeneruje soubor /boot/grub/grub.conf, zatímco z 'dpkg-reconfigure grup-pc' vyleze soubor /boot/grub/grub.cfg. V obou případech můžete výsledný soubor editovat podle chuti...

[Honza Jaroš]

s/grup-pc/grub-pc/

[Jendа]

GRUB1 AFAIK generoval menu.lst, a to podle pravidel zadaných v menu.lst :).

[Honza Jaroš]

Nojo, já už mám všude na Debianu GRUB2 a u Gentoo/CentOS je menu.lst symlink vedoucí na grub.conf. Jestli to měl u GRUBu1 Debian opačně, tak se omlouvám za mystifikaci.

Nicméně to co jsem psal původně stále platí, výsledkem je u starého i nového GRUBu stále ten jeden texťák, který je možné upravovat nebo i komplet od nuly napsat ručně.

[trekker.dk]

V obou případech můžete výsledný soubor editovat podle chuti...

Do příští aktualizace balíku s grubem, která ten soubor přepíše podle těch konfiguráků...

[Honza Jaroš]

To je ovšem problém té distribuce, ne GRUBu - ostatně jak jsem psal, Debian se tak chová se starým i s novým GRUBem, takže si vcelku nemají co vyčítat.

V každém případě stále navazujem na výše zmíněný výrok

V pripade grubu1 v 99% pripadu stacilo lehce postelovat jeden textovej soubor, ze ... a nemusel k tomu clovek ani ten grub mit.

který lze ve skutečnosti naprosto stejně aplikovat na obě verze. Rozdíl je jen v syntaxi daného souboru (já mám radši tu původní, přijde mi jednodušší a přehlednější, ale to už je na jinou diskusi).

[trekker.dk]

Debian se tak chová se starým i s novým GRUBem

To není pravda. Konfigurace pro starý grub obsahovala jasně vymezenou pozici, kam smí automatismy sahat.

[Honza Jaroš]

Tak jsem si nakonec do virtuálu rychle nahodil testovacího Debiana a máte pravdu, grub-legacy se chová jinak a pamatoval jsem si to blbě. Moje chyba.

Nicméně stále platí to, co tu s pavlixem opakujeme pořád kolem dokola: tohle není záležitost GRUBu, nýbrž konfigurace Debianu. A výsledkem je stále jeden textový konfigurák lišící se pouze syntaxí.

[pavlix]

Nicméně stále platí to, co tu s pavlixem opakujeme pořád kolem dokola: tohle není záležitost GRUBu, nýbrž konfigurace Debianu. A výsledkem je stále jeden textový konfigurák lišící se pouze syntaxí.

+1

Navíc například v Gentoo se mi nic nepřepsalo, dokud jsem to neudělal ručně, takže skutečně existují distribuce, které tu automatiku nespouštění v rámci práce s balíčky.

Ohledně Gentoo to navíc platí i o mnoha dalších balících.

[pavlix]

Do příští aktualizace balíku s grubem, která ten soubor přepíše podle těch konfiguráků...

Jak už se výše psalo, svádíš problémy distribuce na GRUB, který za to nemůže.

[Luboš Doležel (Doli)]

To ale nejsou soubory s konfigurací GRUBu. To jsou soubory, které se používají pro sestavení této konfigurace. Vy je používat nemusíte, pokud nechcete, a můžete si to spravovat zcela sám.

[Jendа]

To je ale problém tvé distribuce, nikoli GRUB2.

[Michal Vyskočil]

Zacina me linux(obecne) cim dal vic srat tim, ze se ze vseho delaj binarni sracky ala widle ... v XP jeste slo editovat boot menu upravou textaku, ve Vistach uz ne ... grub1 vs grub2 ... initd vs systemd ... takze to co si clovek moh opravit pokud umel cist a psat ted bude resit s nejakym kompilatorem

Až na drobnost, že je to právě initd/sysvinit, kde se konfigurace musí řešit poměrně záludným kompilátorem - shellem. V systemd je naopak všechna konfigurace v triviálním ini-like textovém formátu, anebo triviálním proměnná=hodnota. V porovnání s DSL různých unixových věcí je textové rozhraní systemd až neskutečně triviální.

Pokud ovšem znáte kus systemd, který se konfiguruje binárně, sem s ním, jinak viz číslo 17.

[j]

Az na tu drobnost, ze k tomu scriptu si sednu, a pripadne jej prepisu k obrazu svemu, tudiz to bude delat presne to, co JA chci a JAK ja chci. A predevsim se resi neexistujici problem.

"trivialni" promenna=hodnota = dela to pouze to, co si myslel autor ty binarky ze by to delat melo. Jakmile potrebuju nejakou netrivialni inicializaci, testy pred spustenim, ... tak si na to stejne musim napsat ten script, ze ...

[pavlix]

tak si na to stejne musim napsat ten script, ze ...

Pak ale nechápu v čem je problém.

[Petr Ježek]

Od toho snad rozšiřující skripty jsou, ne? Vám vadí sako, na které normálně nejde zavěsit lehký kulomet...

[j]

Ne, me vadi ze misto kolecka mi nekdo vnucuje nakladak na vozeni zrnka pisku. Navic jeste s elektronickym vstrikovanim, ktery kdyz se podela, tak to nikdo neumi spravit. A rovnou mi do toho integrujou i vodotrysk a jeste mi tvrdej, ze jinak to prece nejde. A abych si jo nemoh vybrat, tak mi z toho kolecka vytrhnou loziska (udev), a tvrdej, ze tahle je to vporadku..

BTW: Kterej debil vymyslel, ze v udev-197 nepujde eth pojmenovat eth ... ten by zaslouzil za koule povesit (a to bych na nej byl hodnej) ... fakt miluju kdyz se rozbiji neco, co proste funguje jen proto, aby to bylo politicky spravne ...

http://bugs.gentoo.org/453494

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

[little.owl]

Kterej debil vymyslel, ze v udev-197 nepujde eth pojmenovat eth ... ten by zaslouzil za koule povesit (a to bych na nej byl hodnej) ... fakt miluju kdyz se rozbiji neco, co proste funguje jen proto, aby to bylo politicky spravne ...

http://bugs.gentoo.org/453494

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

Mohl byste si o tom promluvit s K.S.*, ale zkuste si prichystat lepsi argumenty nez jste predvedl zde.

* a hint - ne byvaly kandidat na prezidenta

[Michal Vyskočil]

No, pokud začne - kdyz se rozbiji neco, co proste funguje, Kay na něj pošle Lennarta

[little.owl]

Kay na něj pošle Lennarta

Az tak? Posle vetsiho bratricka.

[Michal Vyskočil]

Kay na něj pošle Lennarta

Az tak? Posle vetsiho bratricka.

No pořád lepší, než Grega . Ale jinak bych si měl objednat větší smajlíky.

[Jendа]

GRUB2 je v pohodě, ale init systém na Debianu je dost hrůza. Obzvláště když potřebuju něco dohackovat do initramdisku.

[Jakub Lucký]

můžeš zkusit upstart

[Mrkva]

aptitude install system:D

[cronin]

Odpustite mi možno blbú otázku, hard-core sieťovaniu houby rozumiem, ale je problém mať viacero implementácíí a použiť jednu podľa preferencií? Som rozmaznaný BéeSDéčkar, a tam je možné používať pf, ipfw alebo ipf a je dokonca možné používať ich súčasne.

[pavlix]

Linux se snaží být se síťováním trochu jinde než BSD. Sice není problém mít alternativní implementace, ale pak je potřeba mít jednu hlavní, co je podporovaná a reálně používaná.

Faktem je, že pak stejně bude potřeba, aby se o firewall staral nějaký démon a od jiných nástrojů dostával maximálně tak požadavky, co jak má být. Takový démon pak může mít více backendů. Ale tam je to zbytečné tím spíš, pokud se stejně musí zajistit, aby byly všechny stejně funkční.

[cita]

spis si myslim, ze se jadernym vyvojarum nechce z principu stepit sily do udrzovani vice implementaci toho stejneho.

[Petr Ježek]

Nějak se vytratila zásadní otázka: V čem iptables nevyhovují a jak široce to dopadá na uživatele a správce? Pokud se na toto po řádné analýze odpoví, hoši snadno pochopí, čí práce řeší požadavky doby.

[pavlix]

A máš k tomu nějaké relevantní informace?

[j]

Co sem se kdesi docet, tak "zasadni" novinkou by mela byt (napr) moznost mit vicero sad pravidel zaroven ... ale nejak sem neprisel na to, k cemu by to bylo asi tak dobry.

Z myho pohledu by mozna spis nebylo od veci sloucit IPv4/6 do jednoho (sak 4 je podmnozinou 6tky, takze by to melo vpohode fungovat). Aspon bych pak spoustu veci nemusel psat 2x.

[David Jaša]

Nějak se vytratila zásadní otázka: V čem iptables nevyhovují

1) dynamická konfigurace (zásahy do existujících pravidel) je opruz, který může dělat jen člověk, nebo právě jeden program

2) programy, které potřebují úpravy firewallu, nemohou obsahovat kusy konfigurace firewallu, které by stačilo jen někam zkopírovat a nechat firewall, aby si je přebral

3) výkon v případě dlouhých chainů s mnoha nesouvisejícími pravidly (minimálně donedávna)

Všechno způsobeno použitím chainů všude (přestože se hodí jen málo). nftables by tohle mohly změnit.

[pavlix]

A teď mi vyjmenuj, co z toho se změní.

[David Jaša]

Popis pravidel nftables se tváří, že chainy musíš explicitně vytvořit, pokud je chceš vytvořit - viz {} a možnost, že ti vysype při dumpu jednodušší konfiguraci, než kterou jsi mu nacpal.

[j]

Hm ... takze se vymejsli, jak dovolit aplikacim menit zabezpeceni stroje pod rukama admina, aniz by ten tusil, co se tam odkud vzalo ... mno nevim, ale to vnimam spis jako zcela kritickej bezpecnostni problem. Stejne tak bych rek, ze "nekam skopirovat kus pravidel" nemuze fungovat v zadnym pripade, protoze proste nevim, co a proc admin zakazal/povolil. Takze flaknout "nekam necoi aby si to FW prebral" je proste hovadina.

[Martin Mareš]

Já vidím problémy trochu jinde:

1. nemožnost atomické změny konfigurace;
2. ukrutný zápis složitějších podmínek – místo abych použil booleovské operátory a vnořené bloky jako v normálním programovacím jazyce, musím ručně vytvářet spoustu naprosto umělých chainů, což je otravné a nepřehledné;
3. pravidla pro průchod packetů chainy jsou značně obskurní a nedokumentovaná, zejména to platí pro interakci s conntrackem a IPSECem – některé chainy mohou být v závislosti na kontextu přeskočeny (třeba pokud packet patří ke známému spojení), naopak třeba chybí chain, kterým by šlo filtrovat packety těsně předtím, než odejdou ze stroje;
4. zpracování IPv4 a IPv6 je striktkně odděleno, přestože v mnoha případech správce chce spojení přícházející po obou protokolech posuzovat stejně.

Naopak o to, aby mi programy samy zasahovaly do konfigurace firewallu, vůbec nestojím, byť připouštím, že o to někdo stát může. Proto taková funkce nepatří do jádra, ale spíš do nějakého user-spacového daemonka, který bude podle správcem nastavených pravidel rozhodovat, kterému požadavku aplikace vyhoví.

[David Jaša]

1. a 2. opět souvisí s přístupem "všechno je chain"

na 4. jsem zapomněl, ale taky jsem kvůli tomu nedávno ztratil nějaký ten čas...

Naopak o to, aby mi programy samy zasahovaly do konfigurace firewallu, vůbec nestojím

Pokud máš v pravidlech někde na začátku --state RELATED -j ACCEPT, dělají to iptables samy o sobě (hezčí příklad než ftp je podle mě dlna server + upnp/ssdp server).

Další hezký jůs kejs navazuje na dlna: to chceš mít typicky přístupné doma, ale venku jen tehdy, pokud ho explicitně zapneš, tedy můžeš chtít, aby se v jinak manuální konfiguraci děla automatická změna.

Nicméně mě nešlo hlavně o úplně automatickou konfiguraci, ale mít možnost složitější nastavení někde přibalit tak, aby se dalo upravit jen např. čísla portů a přidat do /etc a nechat firewall vyrobit správnou konfiguraci sám.

[j]

Pokud mam nekde na zacatku related ... tak sem to tam dal proto, ze se takovejma paketama dal nehodlam zabejvat, ze ...

Kdyz neco zrovna zapnu ... hmm ... tak si odkomentuju radek v konfiguraku a pustim neco na tema iptables-restore ... ???

"vyrobit spravnou konfiguraci sam" ... lol ... nocni mura kazdyho admina ... (stejne jako vsmozny scripty "zjednodusujici" konfiguraci)

[David Jaša]

Pokud mam nekde na zacatku related ... tak sem to tam dal proto, ze se takovejma paketama dal nehodlam zabejvat, ...

... takže budeš používat dynamickou konfiguraci, kterou ovšem nemůžeš _téměř vůbec_ kontrolovat nebo nastavovat.

Kdyz neco zrovna zapnu ... hmm ... tak si odkomentuju radek v konfiguraku a pustim neco na tema iptables-restore ... ???

To dost závisí na implementaci. Ale i tak se dá, třeba NM dělá něco podobnýho (sleduje změny v konfigurácích a když zapíšeš novou konfiguraci, hned ji změní)

"vyrobit spravnou konfiguraci sam" ... lol ... nocni mura kazdyho admina ... (stejne jako vsmozny scripty "zjednodusujici" konfiguraci)

Jo, právě proto, že vyrobit z requirement-based pravidel ekvivalentní (a efektivní) pravidla do iptables je noční můra pro každýho programátora.

[pavlix]

To dost závisí na implementaci. Ale i tak se dá, třeba NM dělá něco podobnýho (sleduje změny v konfigurácích a když zapíšeš novou konfiguraci, hned ji změní)

A já upřímně doufám, že tohle chování nejpozději do 1.0 zrušíme.

Jo, právě proto, že vyrobit z requirement-based pravidel ekvivalentní (a efektivní) pravidla do iptables je noční můra pro každýho programátora.

Ale může to dělat ten jeden démon.

[David Jaša]

A já upřímně doufám, že tohle chování nejpozději do 1.0 zrušíme.

tak reload příkazem by stačil. Ta automatika je nepřirozená i pro mě, ale když holt nmcli nic jako nmcli reload nemá, tak co s váma.

Ale může to dělat ten jeden démon.

Kterýmu nesmí pod ruce nic sahat, nebo který nesmíš pustit nad vlastní křehká pravidla. Na věci typu vypínání/zapínání pravidel podle lokace fajn, ale to by se schopnějším kernelím firewallem mohl dělat NM rovnou sám.

Když to tak píšu, vybavuje se mi linuxový hal, který lepil nedostatky výše (Xorg) i níž (kernel, udev), jakmile se ty nedostatky zalepily, milý hal šel rychle do kytek.

[pavlix]

Kterýmu nesmí pod ruce nic sahat, nebo který nesmíš pustit nad vlastní křehká pravidla.

Tak to je.

ale to by se schopnějším kernelím firewallem mohl dělat NM rovnou sám.

Apage satanas. Další, kdo nám chce nasrat firewall rovnou do NetworkManageru. Neříkám, že tam nebude, jen že je to podle mě špatný nápad.

A ještě horší nápad mi přijde integrovat přímo do stejného démona i monitoring síťového trafficu.

[David Jaša]

Další, kdo nám chce nasrat firewall rovnou do NetworkManageru.

Ne firewall, jen přepínání profilů. Skutečnou práci už může udělat něco jinýho, ale nejlepší povědomí o poloze v síti má právě tvůj projekt.

[pavlix]

To ale popisuješ současný stav.

[little.owl]

Neříkám, že tam nebude, jen že je to podle mě špatný nápad.

Ano, je to spatny napad.

Spravne reseni: uz pracujes na systemd-network-manager a nebo te jeste LP do teto pozice zatim nedostal?

[pavlix]

Já pracuju jen na věcech, které mi dávají smysl. A zatím mě nevyhodili :).

[Michal Kubeček]

Další, kdo nám chce nasrat firewall rovnou do NetworkManageru. … A ještě horší nápad mi přijde integrovat přímo do stejného démona i monitoring síťového trafficu.

Vidím to v jasných barvách: systemd, networkd, storaged, … :-(

[pavlix]

Tak to vidíš lépe než náš lennart… systemd-network, systemd-storage, systemd-firewall.

[Michal Kubeček]

No, netvrdil jsem, že ta moje vize popisuje konečný stav…

[little.owl]

Mne sice soucasty stav iptables, s ohledem na to co delam, vicemene postacuje, nicmene jsou veci, kde bych uvital zmeny. Krom bodu, ktere jste zminil je to treba moznost lepsi dynamicke introspekce a nejake rozumna library pro manipulaci s firewallem, libiptc je pain.

Naopak o to, aby mi programy samy zasahovaly do konfigurace firewallu, vůbec nestojím, byť připouštím, že o to někdo stát může.

Jenze nebude muset prave ten user-spacovy daemonek nakonec zasahovat sam do konfigurace firewallu? V podstate mi prijde ze popisujete soucasny Fedori firewalld.

[pavlix]

V podstate mi prijde ze popisujete soucasny Fedori firewalld.

To souhlasím. Až na to, že firewalld je relativní novinka a řeší se s ním jen velmi malá podmnožina toho, na co se firewall na linuxu používá.

[David Jaša]

Ještě mě napadla jedna věc: proč nemůžu napsat do tabulky nat něco jako: -A POSTROUTING -i virbr0 -j MASQUERADE, tedy natovat provoz jdoucí z virtuálek bez ohledu na to, kterým rozhraním odchází.

[luky]

Protoze pamatovat si pro kazdej packet, kterym interfacem prisel, je vetsinou zbytecny.

[David Jaša]

Pro dotyčný případ to platí pro veškerý provoz (mimo ten, co jde na lokál, ale ten zas IIRC neprochází POSTROUTINGem).

[luky]

Tak si je na vstupu oznacte pravidlem a pak delejte maskaradu podle ty znacky.

[pavlix]

Ale můžeš. Stačí přesunout test do mangle/PREROUTING a můžeš si paket označit pomocí MARK. V nat/POSTROUTING pak testuješ pouze tu značku a provedeš maškarádu.

[David Jaša]

Nicméně je to další příklad toho, že iptables je příliš imperativní a málo deklarativní. Ale díky za tip.

[luky]

To je IMO dobre, muzete si pravidla radit tak, jak je to nejoptimalnejsi pro vasi konkretni zatez. Problemy iptables vydim stejne jako M. Mares.

[David Jaša]

muzete si pravidla radit tak, jak je to nejoptimalnejsi pro vasi konkretni zatez.

s/muzete/musíte/

tohle vidím jako eufemismus pro "iptables neumí nic efektivnějšího, než procházet pravidla jedno po druhém" - což se pro hodně vzájemně se neovlivňujících pravidel efektivně udělat nedá (nebo dá, ale než třeba binární hledání pro dosažení O(log n) naimplementujete, tak minimálně zešedivíte, takže se radši spokojíte s jedním chainem a O(n)).

Jako příklad si vemte třeba virtualizující stroj s tisícovkou virtuálek a požadavkem na to, aby virtuálka nemohla spoofovat svou zdrojovou IP. (Tento příklad mimochodem ukazuje i to, k čemu je dobrá dynamická konfigurace fw na serveru.)

[luky]

Jako příklad si vemte třeba virtualizující stroj s tisícovkou virtuálek a požadavkem na to, aby virtuálka nemohla spoofovat svou zdrojovou IP. (Tento příklad mimochodem ukazuje i to, k čemu je dobrá dynamická konfigurace fw na serveru.)

Todle mi prijde jako naprosto vzorovej priklad na pouziti ipsetu, takze by se cela kontrola zredukovala na jedno pravidlo pro iptables.

[David Jaša]

Todle mi prijde jako naprosto vzorovej priklad na pouziti ipsetu

pro bridgované sítě stejně musíš použít ebtables (kde nic podobného není), pro routované sítě to stejně musíš vydefinovat dvakrát (vynutit mac/iface a následně ip/mac, přičemž můj ipset (8) se tváří, že umí jen to druhé, to první se stejně musí dělat chainem).

[luky]

Todle mi prijde jako naprosto vzorovej priklad na pouziti ipsetu

pro bridgované sítě stejně musíš použít ebtables (kde nic podobného není)

Po letmem pohledu do man ebtables bych rekl, ze tomu odpovida volba among.:

among

Match a MAC address or MAC/IP address pair versus a list of MAC addresses and MAC/IP address pairs. A list entry has the following format: xx:xx:xx:xx:xx:xx[=ip.ip.ip.ip][,]. Multiple list entries are separated by a comma, specifying an IP address corresponding to the MAC address is optional. Multiple MAC/IP address pairs with the same MAC address but different IP address (and vice versa) can be specified. If the MAC address doesn't match any entry from the list, the frame doesn't match the rule (unless "!" was used).

pro routované sítě to stejně musíš vydefinovat dvakrát (vynutit mac/iface)

To mi prijde zbytecne, pro virtualni stroje mate k dispozici 70368744177664 MAC adres, takze brutalforce utok by trval velmi dlouho a je velmi snadne ho detekovat.

[David Jaša]

Po letmem pohledu do man ebtables bych rekl, ze tomu odpovida volba among

Když se na to dívám ještě jednou, tak to among je až zbytečný, pokud vypustím ochranu proti arp cache poisoning a podobným. Pak by mi stačil ebtables chain s pravidly -i tunXYZ --src-ip ! adresa_z_dhcp -j DROP, nicméně i ty bych prakticky musel mít jak v INPUT, tak ve FORWARD chainu. Pokud bych chtěl ochranu i na L2, už by to bylo pro každou virtuálku po dvou pravidlech v dotyčných chainech.

Takže jsme opět na začátku, na plnou ochranu máme místo 10-11 průchodů optimálním stromem v průměru průchod 1000 ze 2000 pravidel.

To mi prijde zbytecne, pro virtualni stroje mate k dispozici 70368744177664 MAC adres

Tudíž správce virtuálky si může vybrat spoofovanou MAC z 70368744177663 možností. Proto whitelist.

[luky]

To mi prijde zbytecne, pro virtualni stroje mate k dispozici 70368744177664 MAC adres

Tudíž správce virtuálky si může vybrat spoofovanou MAC z 70368744177663 možností. Proto whitelist.

A co vam brani tu virtualku sestrelit pri prvni nezname kombinaci MAC/IP. Pak je pravdepodobnost uspesneho utoku na stroj s 1000 virtualkami naprosto zanedbatelna.

[David Jaša]

A co vam brani tu virtualku sestrelit pri prvni nezname kombinaci MAC/IP.

Třeba to, že nemusí být moje?

Proc to v tom pripade nedate do PREROUTINGu?

Protože ho u ebtables nevidím tabulku mangle, v tabulce filter není a k tabulce nat se píše:

A small note on the naming of chains PREROUTING and POSTROUTING: it would be more accurate to call them PREFORWARDING and POSTFORWARDING, but for all those who come from the iptables world to ebtables it is easier to have the same names.

[luky]

nicméně i ty bych prakticky musel mít jak v INPUT, tak ve FORWARD chainu.

Proc to v tom pripade nedate do PREROUTINGu?

[pavlix]

pro bridgované sítě stejně musíš použít ebtables

Není důvod.

[David Jaša]

Měl jsem za to, že iptables bridgovaný traffic nevidí, tedy pravidlo typu iptables -A FORWARD -i tapX --src ! adresa_z_dhcp -j REJECT nebude mít žádný efekt a virtuálka připojená do tapX si bude moct posílat pakety s jakoukoliv zdrojovou IP.

[pavlix]

Měl jsem za to, že iptables bridgovaný traffic nevidí

Chyba.

tedy pravidlo typu iptables -A FORWARD -i tapX --src ! adresa_z_dhcp -j REJECT nebude mít žádný efekt

Bude mít efekt, jen je v praxi potřeba doplnit ještě o ebtables/arptables pravidla, abys vyřešil non-IP traffic a ip6tables, abys vyřešil IPv6 traffic.

V tomhle je právě škoda, že to není pořešeno jednotněji. Výsledek by měl mnohem lepší bezpečnostní výsledky s ohledem na administrátorské chyby a znalost/neznalost protokolů.

[little.owl]

Kdyz vas tady tak ve threadu sleduji, premyslim nad tim a koukam na souvisejici dokumentaci, uvedomuji si cim dale vice, ze Mares mel nahore pravdu, i kdyz tyhle veci z principu nemohou byt jednoduche.

Ma tady nekdo nejaky nazor na pristup zvoleny v Xtables2 nebo nftables, jako alternativa k iptables?

[pavlix]

Kdyz vas tady tak ve threadu sleduji, premyslim nad tim a koukam na souvisejici dokumentaci, uvedomuji si cim dale vice, ze Mares mel nahore pravdu, i kdyz tyhle veci z principu nemohou byt jednoduche.

Jo to souhlasím.

[little.owl]

Na tu druhou cast, dulezitejsi, jsi se vyflakl.

Tak jake to bylo, prehanej.

[pavlix]

Nevyflákl. Jen mi přišlo hloupé na otázku do pléna, zda má někdo nějaký názor, odpovídat, že názor nemám a nemám ani jednu z těch možností nastudovanou :).

[David Jaša]

Chyba.

Která ale stejně nic nemění na prvním a druhém odstavci #83, nebo se pletu?

V tomhle je právě škoda, že to není pořešeno jednotněji. Výsledek by měl mnohem lepší bezpečnostní výsledky s ohledem na administrátorské chyby a znalost/neznalost protokolů.

To už mi přijde jako třešnička na dortu.

[pavlix]

Která ale stejně nic nemění na prvním a druhém odstavci #83, nebo se pletu?

To záleží na tom, jestli se skutečně chceš vzdát filtrování non-IP paketů.

[vencour]

Otázka ohledně chainů a pravidel ... jedná se o větvení pravidel a sekvenční procházení, jak ho udělat rychleji?

[j]

Nijak, ale je pri tom treba pouzivat mozek, coz je vetsinou celkem problem ... videl sem peknych par konfiguraci, kde nejobecnejsi pravidlo bylo az na konci => drtiva vetsina paketu prochazela pres vsechna pravidla.

[vencour]

Jj, tomu rozumim ... že se to může stát, předpokládam, že stačí občas sledovat počet hitů a takové pravidlo dát dopředu, ne?

[j]

Tj, ale k tomu je treba toho mozku ... ;D Jinak podle me by idealni firewall vypadal nejak takto:

ac398bfeca8213caeb2ba23231
ac38bfa82cae2a2231fea235ce
ac3bfec83cab2ba23186ffeaec

Idealne srozumitelne, trivilani ... neniliz pravda?

[xx]

wut?

[Jendа]

Nejspíš se snaží ukázat, že když z jádra vydumpuje bytecode pravidel, bude to nečitelné. Že si může zdroják držet někde bokem ho asi nenapadlo.

[vencour]

Některé profi firewally mají tutéž filozofii, samotné krabice jsou v jistém smyslu tupé a vše dělá jejich management = tak jako zde něco dalšího.

[vencour]

To už je věc filozofie, zda má být firewall spravovatelný nativně přes čitelná pravidla nebo přes něco zkompilovaného, jako to, co zde citujete.