NuFW: a következő generációs tűzfal

Szerszám

A legújabb Mandriva hírlevélben mutatták be a NuFW-t, mint következő generációs, vállalati szintű tűzfal megoldást. A NuFW a Linux kernel netfilter rendszerén alapul. A HOWTO-ja szerint egy vállalati szintű tűzfal, amely authentikál minden egyes kapcsolatot, amely keresztülhalad az IP filter-en. A felhasználó számára transzparens módon lekéri annak jogosultságait, még mielőtt bármilyen csomagszűrési feladatot végrehajtana.
Ez azt jelenti, hogy felhasználókhoz rendelhető biztonsági házirend integráltható a címtárba, azaz nem a forrás IP címhez, portokhoz, stb. hanem felhasználókhoz rendelhetünk szabályokat.

A szabályokat ezentúl nem IP címre, hanem felhasználókra, felhasználói csoportokra adhatjuk meg. Mivel minden egyes kapcsolathoz tartozik egy név, egyszerűbb a felhasználókat követni, logolni, kimutatásokat készíteni, szabályozni (pl. felhasználóra QoS szabályok). A NuFW adatbázis-szerverbe (PgSQL, MySQL) logoltatható. A NuFW két részből áll: egy daemon-ból, amely a tűzfalon fut, és kliens programból, amely a tűzfal kliensekre települ. A deamon program csak Linuxon fut (mivel a netfilter-t használja), a kliens programok viszont Linux, Windows, FreeBSD és Mac OS X operációs rendszereken is futnak.

Mire képes a NuFW?

  • Authenticate any connection that goes through your gateway or only from/to a chosen subset or a specific protocol (iptables is used to select the connections to authenticate).
  • Perform accounting, routing and quality of service based on users and not simply on IPs.
  • Filter packets with criterium such as application and OS used by distant users.
  • Be the key of a secure and simple Single Sign On system.

A NuFW használatát segítheti a NuFace névre hallgató webes felületű szabálygenerátor is (képek). Ha valaki kipróbálná, elérhető egy online demo.

A NuFW elérhető forrásban, és a nagyobb Linux disztribúciókhoz (Debian, Gentoo, Mandriva, stb.) csomagban is.

Ha valaki ilyesmi megoldást keres, érdemes lehet szemügyre venni. Aki nem akarja maga összerakni a stuffot, annak lehetősége van előre legyártott berendezést venni EdenWall néven.

A projekt honlapja itt. A NuFW GPL-es projekt. Nemrég jelent meg a stabil 2.0.13 és a fejlesztői 2.1.1-es verziója.

( Tron | 2007. 01. 07., v – 09:51 )

Ígéretesnek tűnik! Ez tényleg egy új és könnyedebb alternatívát biztosít, a többi jelenlegi megoldásokhoz képest.
Viszont kiváncsi leszek, mennyi lesz a bug, és egyéb kezdeti probléma, tekintve, hogy még nagyon friss keletű a rendszer.

------------------------------------
[Debian Sarge; ASUS P4T533-4; 2.4GHz CPU; 512MB RAM; XFree86; FluxBox]

( wildy | 2007. 01. 07., v – 10:01 )

Nem hiszem, hogy manapsag egy nem proxy tuzfal vallalati szintu lehet (legalabbis ott, ahol a szakmai szempontok dominalnak), elso ranezesre legfeljebb a PIX-ek retteghetnek a NuFW-tol. A conntrack modulok szuksegessege miatt szerintem onmagaban szinte hasznalhatatlan vallalati celra - legalabb egy SIP proxy kellene melle.

Arra celoztam, hogy mar reg tulhaladott a csomagszuresen a vallalati szfera igenye. Proxy alapu, protokoll elemekre lebonthato szabalyozas manapsag a kovetelmeny. A csomagszurok pedig meg mint eloszuro is elbuknak, ha nincs conntrack moduljuk a macerasabb protokollokhoz (erre hoztam fel peldanak a SIP-et, bar a 2.6.20 kornyeken mar erkezik ilyen conntrack modul, kerdes, mit tud).

( Hunger | 2007. 01. 07., v – 15:23 )

Igazán tovább gondolhatták volna kicsit ezt a srácok... Pl. hogy egy nagyvállalatnál ne kelljen a több ezer kliensre feltelepítgetni a kliens programjukat, hanem felrakja az ember a domain controllerekre és azok hitelesítik a klienseket és azok forgalmát is.

Ez az OpenLDAP PostgreSQL backenddel hogy jön ide?
Egyáltalán -ha már idehoztad- belegondoltál már, hogy kb. milyen sebességre lehet képes az amúgy is lassú OpenLDAP egy általános adatbázisszerver háttérrel?
Azon kívül, hogy bármelyik pénzért kapható (de némelyik ingyenes, sőt nyílt forráskódú) LDAP szerver is többet nyújt sebességben és tudásban?

Te mennyire számítasz?

Ha jol derengenek a teszt eredmények, maga pg egy ~mai gépen (PC) ~10^3 , bdb -meg anno azért választottam, mert valami teszten 10^6/sec (http://sleepycat2.inetu.net/pdfs/wp_perf_0705c1.pdf) -et olvastam.
Ez csak a DB, ha magába van.

Egy teszt:
http://deb.riseup.net/databases/mysql-openldap-benchmark/#the_results
mgj: az itt látott időkbe beletartozik az is, míg a postfix továbbtolja a leveleket.
szerk:
A tesztek alapján arra saccolnék, hogy ezen a gépen elképzelehető openldap mysql backendel, ~3000 /sec lekérés, ha csak opanldap+mysql fut rajta. pg-sql el nagyságrendben megegyező eredményt saccolnék.
------
gentóhuszár

A millió per másodpercről a hivatkozott tesztben:
Aspects of Berkeley DB Not Measured:
- Out of cache performance
- Deadlock discovery and resolution time
- Effects of concurrency

Szerinted ezek csak marginális mértékben fogják belassítani a BDB-t? Nincs rájuk szükség egy LDAP szervernél?
A cache-sel persze vitatkozhatsz, csak lehet, hogy felesleges. Egyrészt az LDAP szerverek saját cache-sel szoktak rendelkezni, ahol nem futtatják le újból a művelethez tartozó programrészeket, hanem annak "képét" cache-elik és adják meg az előző választ. Tehát ez rögtön nem a BDB cache-e lesz.
Másrészt ha te akkora adatbázissal prüntyögsz, amekkora belefér a géped memóriájába, akkor nyilván jobb helyzetben vagy, mint az, akinél ez nem áll fenn (mert mondjuk pár tíz millió entryt tárol, ne adj isten milliárdot).

A mysql-es tesztről:
- a fenti kérdésben teljesen irreleváns, túl sok egyéb tényező van benne, ami minket nem érdekel
- a teszt számomra nem egyértelmű, egyrészt azt írja, hogy a táblázatban lévő sorrendben indította őket, a szerverek újraindítása nélkül, a cache méreteket pedig (az ő pirinyó adatbázisának méretéhez képest) az egekbe tolta. Ha ugyanarra a 10000 címre küldött levelet és az OpenLDAP cache-e valóban működött, akkor annak a teljesítményét "mérte".
- az eredmények összevissza hullámoznak, én ezt mindennek hívnám, csak mérésnek nem

Szóval nem látom alátámasztva azt, hogy az OpenLDAP PostgreSQL (de felőlem lehet MySQL is) ezres nagyságrendben lenne képes ldapsearcheket (nyilván a legolcsóbb művelet, hiszen nem kell keresni, lockolni, indexet és adatbázist frissíteni, stb) kiszolgálni.

Mennyire számítok: pár százas nagyságrendre, ha az OpenLDAP-nak és az RDBMS-nek kommunikálnia és dolgoznia kell (azaz nem az OpenLDAP, vagy az RDBMS cache-éből jön az adat).

number of messages (one per unique user).
10x1000 means deliver 1000 messages to 1000 users
ten times.
Ezer címre tesztelte. (+ alias ami újabb lekérés) (Céges szinten kb. oké)

Milliárdot e-mail címet a gmail sem éri el szvsz.
Ha egy cache bejegyzés ~1kbyte, 1Gb+ Memóriánál, ~1 milla entry -nél sem kell különösebben disk I/O -ra számítani.
Ha 10 millás+ entry-kre van szükséged, vegyél nagyobb gépet, ennyi bejegyzésnél minden megoldás lassú ~1Gb ramnál , főleg, ha direkt úgy teszteled, hogy ne férjen bele).
Ami a több bejegyzést illeti O(log_2(n)) -es elérést azért elvárnék egy ilyen rendszertöl. (log_2(2^20)=20) (Főleg, hogy gyors olvasás, lassú írás van a propaganda agyagában)

Ha 1.7Ghz/1000kéres = 1,700,000 tick, ha ebből még mindenféle rendszerhívsos, varakozós bizbaszra is megy el az idő, még akkor is bőven van ideje keresni is..

(Felhasználók bejelentkeztetéséhez, azért kell más is, arra én sem számítanék, hogy ezeres nagyságrendű felhasználót léptessen be /sec)

------
gentóhuszár

Van aki adatot is tárol az LDAP szerverben és entryből sem feltétlenül annyi van, mint e-mail címből.
1000 usernél lényegében mindegy, hogy miben tárolod, ha txt fájlból keresel még azt sem fogod észrevenni, csak ha magas a forgalom.

Itt mindenesetre pár ezer qps-ről beszéltél, az meg feltételezi, hogy nem kispályázol, hanem komolyabban használod a rendszert, nyilván ennek megfelelő adatmennyiséggel. Kíváncsian várom a postgreses benchmarkodat mondjuk egy milliós és egy 10 milliós adatbázissal, random, lehetőleg valami életszerűbb filterrel, ne csak mail=geza@gizi.hu.

Lehetőleg olyan helyre tedd, hogy könnyen megtalálható legyen. Mondjuk küldd be cikként, BDB, postgres, mysql összehasonlítás szerintem még érdekelne is valakit.

en most mertem mysqlt, egy tabla, egy mezo, indexelt, random adatokkal feltoltve, es random
querykkel bombaztam. 8 konkurrens kapcsolatnal, kapcsolatonkent 64 ezer keressel
nem tudtam ezer req/s fole menni :-(

pedig most van egy projekt amihez kene nekem legalabb 5-6k keres/s..

valakinek otlet?:)

Az asztali PC-set természetesen viccnek szántam.

Ettől függetlenül a mysql tuningnak számos lehetősége van, ami nagyban függ a használt OS-től is.

Nem tudom mit akarsz, de a legnagyobb teljesítményt értelemszerűen memória (HEAP) táblákkal éred el, írásra és olvasásra is.