NFtables: új "tűzfal" megoldás az iptables leváltására

Kernel

Patrick McHardy - Netfilter fejlesztői csapattag - tegnapelőtt bejelentette az NFtables névre hallgató "tűzfal" megoldás első kiadását. "Végül, sok késlekedés után kiadtam annak az NFtables [névre hallgató] kódom (beleértve a userspace-t is) első teljes körű, nyilvános kiadását, amelynek célja, hogy leváltsa az iptables-t."

Az NFtables "from scratch" íródott, azaz teljesen nulláról, nem felhasználva a már meglévő iptables kódokat. Számos ponton - mind dizájnban, mind szolgáltatásokban - eltér az iptables-től.

A kódot - amelyet jelenleg alpha állapotúnak lehet tekinteni, azaz éles környezetben való felhasználásara semmiképpen, tesztelésre mindenképpen javasolt - ki lehet nyerni a git tárolókból:

git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nft-2.6.git
git://git.netfilter.org/libnl-nft.git
git://git.netfilter.org/nftables.git

"Ennek ellenére az összes alapvető szolgáltatásnak és a fennmaradó dolgok legtöbbjének jól kell(ene) működnie, az utolsó [kernel] összeomlás néhány hónappal ezelőtt volt."

Az NFtables szintaxisa eltér az iptables-étől. Alapvető szintaxis (hacsak tavaly október óta nem változott): 

    
nft rule add filter output tcp dport ssh
nft rule add filter output ip daddr 191.68.0.1 ip protocol tcp

vagy 


nft rule add filter output tcp dport == 22
nft rule add filter output ip daddr == 191.68.0.1 ip protocol == tcp

A bejelentés - benne a bemutatással, példákkal, magyarázatokkal - elolvasható itt. További részletek itt.

( bervi | 2009. 03. 20., p – 17:38 )

hát egy pf-hez hasonlóan kényelmes ruleset syntax-nak tudnék örülni

gyors átfutás után még akár lehet emészthető is lehet

( maniac | 2009. 03. 20., p – 18:25 )

Érdekes lesz, bár nekem az iptables-szel sem volt gondom nagyon, miután elkezdtem utána olvasgatni, meg párat összeállítottam.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

( Replaced | 2009. 03. 20., p – 18:32 )

nocsak

--
When in doubt, use brute force.

( uid_4656 v | 2009. 03. 20., p – 18:48 )

nft rule add filter output tcp dport ssh

Ez akkor azt csinálja, hogy ki tudok ssh-zni a gépről bárhova?

( uid_4656 v | 2009. 03. 20., p – 18:51 )

Próbáltam keresni hozzá (leginkább az userspace részhez) dokumentációt, de a példákon kívül nem találtam semmit...

Továbbá lesz ebben bármi olyasmi, ami többet tud nyújtani, mint az iptables? Leginkább azért kérdezem, mert nem nagyon volt olyasmi, amit nem tudtam eddig iptables-szel megvalósítani...

Számomra a mai napig hiány, hogy nem tudom az applikációkat korlátozni ( a 80as port nyitva, de csak a firefox számára mondjuk ). Bár ha van valakinek erre a problémára megoldási javaslata, az ne tartsa magában..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Én kicsit általánosabbra gondoltam :) Az én nézetemben a legideálisabb az lenne, ha azt mondhatnám, hogy default minden kommunikációt tiltok, majd azokat a portokat nyitottá teszem, amelyek a szolgáltatásokhoz kellenek ( hogy kívülről elérjék ), és minden appot ami ki akar menni a gépről a hálózat felé megmondhassam, hogy kimehet e, és ha igen akkor milyen porton ( esetleg milyen protokollal ).. Így nem lenne az pl, hogy a már kinyitott portot az használja ami szeretné.. Na most minden progihoz külön-külön usert felvenni az eléggé macerás :)) Egyszerűbb lenne akkor már chrootolni/jailezni minden egyes alkalmazást :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Szevasztok

...a 80as port nyitva, de csak a firefox számára mondjuk...

Nufw -vel meg lehet oldani ezeket a dolgokat.
( Nálam legalábbis működik )
Nufw felmegy, beállítod az acl -eket, kliensgépekre szintén nufw ( csak kliens módban indítva ) netfilterrel kiküldöd NFQUEUE -be a bejövő 80 -as portot, ott a nufw elkapja, acl és mark_field alapján eldönti, hogy a user jogosult -e a 80 -ast használni firefox -szal.

A nufw ezek alapján dönt:
- IP cím
- OS ( linux, bsd, windows )
- User
- Alkalmazás

Lehetőséged van pl. egyéni sávszélkorlátozásra szabályzásra user -ek alapján, stb...
Rengeteg dolog van a nufw -ben, ami nagyon hasznos.

...--uid-owner username alapján? és a FF külön user-rel indulna...

Az a gáz, hogy a --uid-owner csak OUTPUT láncon van, ugyanis a netfilternek hozzá kell férni a szülőfolyamat azonosítójához.
Azt meg ugye nem tudja, hogy a belső hálón levő gépen melyik user indította a rogramot.

Egyébként, ha már szóba került a netfilter, akkor szerintem inkább abba az irányba kellene menni, hogy az alkalmazásszintű csomagszűrést fejleszteni, mivel szerintem ez a jövő.
Bár én nem vagyok szakértő és nem vagyok netfilter guru, de pl:
Személy szerint néhány helyen azért használok inkább netfiltert, mint pf -et, mert alkalmazásszinten kell szűrni.
Layer7 -tel, és xtables-addons -szal ( amiben benne van Kadlecsik Józsi ipset -je is ), sokkal nagyobb mozgástere van az embernek.
Pl: Iskolában:
Torrentet nem tudsz portra szűrni, hiába dobod mondjuk a 6881:6889 -es tartományt, átteszik a gyerkőcök a torrentklienst, oszt viszlát ezerrel jön le a cucc.
Layer7, vagy ipp2p megfogja...
Msn fájlküldés:
Msn chat mehet, msn fájlküldést layer7 fogja.
Stb, stb, stb...

Szerintem a nufw -nek nagyon sok jó dolga van, plusz a layer7 xtables-addons nagyon sokat segít.
De ez csak az én szerény véleményem, nem vagyok szakértő.

Szevasztok

Slackwall

Csabi, ha te nem vagy szakértő, akkor én mit mondjak? :-))
Mindenesetre az tény, hogy bár szeretem az OpenBSD-t és a PF-et és kedvencem is marad mindkettő, de egyre többször ütközök olyan problémákba ahol alkalmazásszintű szűrés kell már tűzfal szintjén, és ezt az OpenBSD PF-je nem tudja biztosítani. A netfilter a layer7 filterrel maradéktalanul megoldja amennyire nekem kell (MSN, Skype, torrent, stb.) Több rugalmasság és lehetőség van szerintem a netfilter-ben ebből a szempontból.

--------------------
Tegnap beállított hozzám egy Tyrannosaurus Rex és Hamlet. Volt nagy dinóm, dánom...

Huh.. jól hangzik.. Majd ha lesz időm megpróbálok eljátszani vele ( ahogy nézem van belőle debian csomag is :)) .. Mindenesetre amiket leírtál az alapján eléggé kecsegtető

szerk: elkezdtem ismerkedni az online demo-val, illetve a live cd-vel. .Eddig elég ígéretes :)) Majd ha normálisan sikerül kitapasztalnom ebből is kerítek egy blogot :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

grsec-et anno próbáltam, ahogy néztem sok mindent is tudott, de valahogy indig sikerült eljutnom odáig, hogy inkább visszaálltam, mert tuti, hogy nem sikerült úgy belőnöm a configot, hogy minden működjön, és ne hasaljon el.. Szerverek esetében aláírom, hogy nagyon jól használható, de én az a mazochista vagyok, aki otthoni környezetben is szeretne 1-2 szerver szinten használt dolgot futtatni, ám pont a user dolgok miatt itt nehezebb a dolgom, mert ez a rendszer sokkalta "szabadabb", több mozgásteret kíván..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Hasonló, bár azért ahogy nézem ennek van 1-2 hiányossága ( az alapján amit találtam róla )
- Ahogy nézem konzolból nem lehet konfigurálni ( ez nálam eléggé negatív jellemző )
- Az applikációkat tudja szűrni, de mintha a portszűrést az applikációkhoz képest más szinten végezné ( ahogy néztem olyan, mintha kinyitná a portot, majd az allow listán lévő appokat kiengedné a hálóra, de a már engedélyezett portok közül bármelyiken..

Azért köszönöm szépen a tippet, majd ennek is adok egy esélyt, és eljátszok majd vele, és majd megírom mire jutottam :)

szerk: Adtam neki egy esélyt.. tapasztalatok itt: http://hup.hu/node/68668
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( siposa v | 2009. 03. 20., p – 21:03 )

Akkor már a tc(filter)-t is megpiszkálhatnák, hogy egy szintaxissal menjen mindkettő.

( Som-Som | 2009. 03. 20., p – 21:13 )

Itt úgy is sok okos ember megfordul, felteszem hát a NAT-os kérdésemet, hátha valaki meg tudja válaszolni. Sok NAT-tal kapcsolatos RFC van. Ezek közül az RFC4787 feszeget számos kérdést, amire nem igazán találtam meg a választ.

Mennyire igazak pl. az iptables-re a következő tulajdonságok: port paritás megőrzés, port contignity megőrzés? UDP használatakor milyen feltételek miatt hagy nyitva egy portot? Gondolom, hogy mindenféle conntrack modultól is függ, de első körben csak úgy általánosságban érdekel.

Az RFC4787 követelményeire a következőket tudom írni:

REQ 1. A netfilter a cím és port független mappeléshez áll a legközelebb. Ha a "random" kapcsoló be van kapcsolva a NAT targeteknél, akkor mindíg. Ha nincs, akkor csak abban az esetben, ha az egyértelmű mappelés azt megköveteli (egyébként végpont független). Pl. az RFC4787 jelölését használva, amikor két kapcsolatról van szó (X1,x1) -> (Y, y) és (X2,x1) -> (Y, y) paraméterekkel, azaz két kliens ugyanahhoz a szerverhez, ugyanazon forrásporttal akar kapcsolódni: az egyértelműség érdekében az egyiket át kell mappelni és ezért csak a cím és port független mappelés jöhet szóba, az is történik.

REQ 2. Ha a NAT-nál egy poolból lehet válogatni, akkor SNAT/DNAT esetén a "least load" alapján történik a címkiválasztás, ami inkább "random", és semmi esetre sem "paired". A NETMAP target esetében egyértelműen fix IP címre történik a NAT-olás, vagyis "paired".

REQ 3. Nincs port overloading, és a netfilter megpróbálja a 0-512, 513-1023, 1024-65535 tartományokban tartani a mappelt portot.

REQ 4. Nem őrzi meg a port paritást és nincs port kontinuitás.

REQ 5. Az UDP timeout default három perc (az RFC4787 legalább két percet követel meg és öt percet javasol), konfigurálható.

REQ 6. A NAT mappelés időzítője frissül, akár kifelé, akár befelé megy csomag.

REQ 7. Az ütköző külső-belső IP címek elkerülése nem a netfilter dolga, hanem azé, aki/ami konfigurája.

REQ 8. Cím és port függő a válaszcsomagok elfogadása.

REQ 9. Nincs hairpinning, semmilyen formában.

REQ 10. A protokoll helperek modulként nem töltődnek be automatikusan.

REQ 11. A netfilterben implementált NAT nem determinisztikus az RFC4787 terminológiája szerint (azaz, ha szükséges, elkerüli az ütközést és átmappeli a forrás portot). Megjegyzem, roppant vicces, hogy az RFC semmit nem mond arról, ugyan mit kellen tenni az ütközések elkerülése érdekében. Inkább utasítsa vissza a kapcsolatot a tűzfal?

REQ 12. Ha úgy van konfigurálva (RELATED), akkor a netfilter átengedni a kapcsolatoknak megfelelő ICMP hibaüzeneteket.

REQ 13. Ez nem a NAT, hanem az IP stack dolga és a Linux rendben küld ICMP Frag needed csomagot UDP esetén is.

REQ 14. A netfilter conntrack defragmentál, vagyis a fragmentek érkezési sorrendje érdektelen a NAT számára.

Az RFC4787-t láthatóan az alkalmazásírók szemszögéből fogalmazták meg. És csak megerősít abban, hogy teljesen igazunk van amikor azt mondjuk, hogy sosem fogunk IPv6 NAT-ot implementálni.

Köszi szépen a válaszodat! Nagyon sokat segített. De honnan tudod mindezt?

Én IPv6 esetén is alkalmaznék NAT-ot. Nyilván a címtartomány elégséges. De topológia elrejtés és bizonyos fokú anonimizálás jól jöhet néha. Erre jön még az rá, hogy esetleg a DHCP szerver IPv6 esetén adott MAC-re mindig ugyanazt a címet adja, ami más hibákkal párosulva veszély forrása lehet.

Úgy könnyű. :)

Most leginkább a SIP kliensek NAT mögötti viselkedése érdekel. Nekem az a gyanúm, hogy STUN segítségével összeszedik a saját control és RTP címüket és portjukat. RTCP használatra viszont esélyük sincs a port kiosztás miatt. Vagy ennél azért jobb a helyzet?

Ha a SIP helpert használod, akkor szerintem igen: bár a netfilter NAT core nem törődik vele, de ha a NAT SIP helpert használod, az a port kontinuitás betartásával változtatja meg az RTP/RTCP portokat. (A port paritás megőrzésével viszont a helperek sem foglalkoznak.)

A H.323 helper szintén betartja a port kontinuitást.

( Esc | 2009. 03. 21., szo – 09:44 )

Szerintem ilyen idióták miatt szopik a legtöbb rendszergazda, mert mi a francnak kell megváltoztatni egy már bejáratott és ismert szintaktikát? 5 év és jön egy másik segg*fej aki meg majd már xml-be akarja majd írni a config-ot, megint 5 év és jön a Linux registry.
Nekem az ilyenektől hányni támad kedvem, mert nem elég, hogy egy rendszergazdának manapság már 120 és 1 dolgot kell ismernie, de már lassan azok XX variánsát is. Nagyon rossz irányban halad a linux.. igaz már évek óta.
Ilyen alapon már igazán megcsinálhatnák "egyfajta" objektum szeruen, hogy elválasszák a rétegeket, hogy ne kelljen 5 évente újra tanulni a szintaxist.

+1
Nekem az IPtablessel semmi bajom nincs, nem is volt. Amire nekem szükségem volt mindent teljes körűen el tud, és el is lát a mai napig már majdnem 2. éve. Nem lett volna egyszerűbb ezt fejleszteni? Mondjuk implementálhatnának bele még néhány új opciót, és ha találnak benne hibát kijavítanák, tökéletesítenék.

Update:
Persze, nem akarom szapulni, a fejlesztőket/fejlesztéseket! Ha ez az új filter (nft) jobban fog működni, mint az eddigiek, állok elébe, jöhet a váltás.:)

1. A hozzászólásomban több mint 10 év tapasztalat van, nem csak en kopkodok a linux-ra, hanem sokan masok es joggal. Kerdes akkor miert hasznalom?: nincs igazan alternativaja.
2. Egy életen át tanulás rendben van, de az hogy szopsz egy fejlesztő miatt, aki feltalálja a spanyol viaszt az már nem. Egyébként meg nincs olyan akinek nincs sokszor csomore az ámítástechnikától X év után.. foleg ilyen elcseszett dolgok miatt.
3. Nincsennek ilyen sűrűn fejlesztések:
Sorolom:
ipchains
iptables
most meg nftables
Mindegyiknek más és más a szintaktikája, azaz 5-6 évente változik. Ha Neked ez a "tudomany", a fejlődés, az baj.

"megint 5 év és jön a Linux registry"

Abszolút nem követem a desktop-trendet (nem próbálom megérteni, mert nem érdekel), de határozottan olyan érzésem van, hogy a "nem akarok hozzápiszkálni, mert csak annyit szeretnék tőle, hogy működjön" Ubuntuban egyre több minden dolog a "Linux registry"-ben van.