Mire jó a Zorp?

Ha már egy korábbi fórum bejegyzés kapcsán felmerült, hogy mire is lenne jó voltaképpen a Zorp, itt olvasható egy blog post, ami állítja; "a Zorp közel sem mindennek a teteje, viszont minden funkcióban segítségünkre lehet, ami a mély protokollelemző proxy tűzfal varázsos meghatározás alapján elvérható".

Hozzászólások

te Szilard, ha lehetne, kevesebb PR threadet kernenk.

több példa, illetve úgy egyátalán dokumentáció is
Bár nem követem a Zorp életét, de az egész biztos, hogy az egyik garancia arra, hogy egy szoftvert (főleg OSS-t) kevesen fognak használni az a kevés, rosszul érthető, hiányos, stb. dokumentáció.
Kivétel ez alól a kényszer illetve alternatíva hiánya.

Régebben olvasgattam egy írást arról, hogy melyik a legkedveltebb, legelterjedtebb Python web framework.
Ott azt írta a srác, hogy szerinte azért a Django a legkedveltebb/legelterjedtebb (nem emlékszem már) mert az van a legjobban ledokumentálva.
Akkor jól elgondolkodtam ezen és beláttam, hogy ez valószínűleg nagyban szerepet játszik a Django és bármilyen más szoftver elterjedtségében.

Szóval azt a tippet tudom adni a Balabit-nak, ha felhasználók táborát akarja építeni/növelni, hogy átlag üzemeltető számára használható dokumentációval nyerje meg őket.
Bár nem használtam még a Zorp-ot, de afelől annyira nincs kétségem, hogy maga a szoftver jó.

Még az olyanok, mint Ubuntu/Debian/RHEL repó friss csomagokkal, használható alap telepítéssel és konfigurációval szintén hasznosak tudnak lenni.

Nem tudom a fent említett dolgok léteznek-e, de ha a sysadmin úgy érzi, hogy a fél életét rá kell szánnia egy szoftver megtanulására, telepítésére, beüzemelésére, akkor az marad a "cool stuff" kategória legtöbb esetben.

ufw-ről lehet példát venni, hogy hogyan kell egyszerűen beüzemelhető tűzfal szoftvert csinálni. :)
Nyilván a Zorp nem ez a kategória, de az irány az lehet hasonló.

A következő 3.9-es release-ben tovább egyszerűsödik a konfiguráció mikéntje (már ami kifejezetten a szabályok felvételét és nem a proxyk tesztre szabását illeti), ami nem pótolhatja a dokumentációt, ugyanakkor igaz, hogy sokakat ennek bonyolult mivolta már első látásra elrettentett.

Ami a kész csomagokat illeti, ebben az irányban mindenképp kell lépéseket tenni (lásd itt), ez elvitathatatlan. Főként, hogy az újdonságok kihasználásához saját kernel modul (KZorp) szükségeltetik.

Egy sysadmin életét talán legjobban a kész, érthető példák (nyilván a jól működő szoftveren túl) tudják megkönnyíteni, ezekkel mielőbb szeretnénk szolgálni.

A kzorp-al kapcsolatban is jó lenne, ha kizárólag külső modulként lefordulna és nem csak egy adott kernelhez lenne hozzáfaragva. Tudom, hogy ez jelenleg nem megoldható, mert a mainline kernelben nincs benne minden ami a kzorp-hoz kellene, de hát a tproxy is bekerült 6 év alatt :) és tudtommal a kzorp jelentős részben a tproxy-ra épít. A GPL verziót én tproxy-val használom, csak hát az UDP-vel nem nagyon működik....

Valóban. Sajnos azonban technikai limitációk miatt (amik a kernelben és nem a KZorp-ban vannak) ez egyelőre nem lehetséges, pedig a TProxy az upstream disztribúciókban lévő kernelek mellett nem jelentene problémát. Próbálunk lobbyzni érte a kernel fejlesztőknél, hogy javuljon a helyzet a mi szempontunkból, de félő, hogy ez rövid távon nem vezet eredményre. Marad tehát az a verzió, hogy a Zorp mellett kernelből is adjunk bináris csomagokat.

Nem olyan siman. Ott is patchelni kellene a kernelt, igy a default kernelbe kb biztosan nem kerulne bele, mert a Zorp az egyetlen usere, es upstream kernelbe sincs benne, es nem is varhato rovid idon belul. Igy nem sok haszna lenne ott, es a debianos kernel maintainerek nem szeretik az ilyet.

Szoval kulon kernelt lehetne tolni, ami meg... nem egy egyszeru feladat, plane nem Debianon belul. Kivul sokkal egyszerubb.

--
|8]

Kulon modulkent nem megy, ha jol remlik azert, mert valami olyan stuffot hasznal, amihez a klienseket (etekintetben KZorp kliens) build-time kell regisztralni. Igy leforgatott kernelhez nem lehet olyan modult forgatni, ami ezt a bizonyos dolgot hasznalna. Hogy ez micsoda, arra mar nem emlekszem.

A Xen pedig a linux-2.6 csomagbol jon - kulon binaris, de a forrasa a linux-2.6. Ez KZorp eseteben nem megoldhato.

--
|8]

> A Xen pedig a linux-2.6 csomagbol jon - kulon binaris, de a forrasa a linux-2.6. Ez KZorp eseteben nem megoldhato.

Miert nem? Ahhoz a kernelhez azokat az opciokat, patcheket bekapcsolja build script es kesz. Vagy ebbe mar nem megy bele a debian policy szinten?

Mindenz persze annyira nem lenyeges, csak elgondolkoztam rajta.

10x

tompos

A 3.9.3-ban sajnos nincs benne az IPv6 támogatás, viszont a következő verzióban - aminek a kiadása igencsak időszerű - terveink szerint benne lesz.

A ChangeLog, dokumentáció, mintapéldák tekintetében egyet kell értsek veled. Vannak komoly elmaradásaink, amiket szeretnénk is folyamatosan pótolni, de az már most is látszik, hogy ez nem fog sem napok sem hetek alatt megtörténni. Addig is néhány dolog, amit már most hasznosítani lehet:

* virtuális gépek, egy teljes kliens-tűzfal-szerver architektúrával, amin számos mintapélda működik és a sajátok ötleteket is könnyedén ki lehet próbálni
* a virtuális gépeken is meglévő mintapéldák egy git repóban, ami remélhetőleg folyamatosan bővül nem csak a saját, de mások ötleteivel is,
* a Zorp hivatalos dokumentációja, amiből a proxyk (nyilván azoknál, mik a GPL-ben is benne vannak) konfigurálásához megvan minden információ (egyéb tekintetekben hozott változást a 3.9, lásd a példákat),
* számos fórum, ahol értesülni lehet a hírekről, újdonságokról (levelező lista, Facebook, LinkedIn, Twitter),
* néhány prezentáció (egy részletesebb, egy rövidebb), amiknek a végét is érdemes megnézni,
* némi demó anyag egyelőre kommentárok nélkül (remélhetőleg ez sem várat túl soká magára)

Amit elsősorban szeretnénk a közeljövőben, az az, hogy minél könnyebb legyen a Zorp kipróbálása (lásd virtuális gépek) feltelepítése (amihez leginkább kész bináris csomagok kellenek), valamint használata, ami jelentékeny részben dokumentációs kérdés.

Aki már most szeretne némi anyaghoz hozzájutni, annak a tavalyi Linux Akadémia Zorp GPL kurzusáról készült videóanyagot tudom ajánlani (már amennyiben ez nem minősül reklámnak).

Nagyon alaposan lehet ellenőrizni vele a forgalmat és rengeteget lehet vele vacakolni amíg mindenkinek mindene rendesen menni fog. Viszont nem véd pl egy 0day flash bug és hack ellen, minden https forgalom szabálytalan lesz, a stream folyamokat típusonként kell definiálni.

A szál korábban jó volt, atomfegyver, nagyon jó olyan helyekre ahol a maximális biztonság a fő cél.

Valóban ez a megoldás, sőt ezen keresztül gyakorlatilag magad tudod megszabni, mit tekintesz megbízható certnek és mit nem. Az általad megbízhatónak tekintettekre (még akkor is, ha az amúgy self signed, de te megbízol benne) továbbadsz egy x CA-val aláírt certet, míg a nem megbízhatónak ítéltekre egy y CA-val aláírt certet és a kliensekbe (böngésző) csak az x CA-t importálod.

Van-e HW-vel együtt szállított és támogatott zorp? Van-e zorp distro? A magas rendelkezésre állást klasszikus linux HA-val lehet megoldani?

Igen, van kereskedelmi Zorp, aminek része a grafikus menedzsment, több protokollproxy (pl. ssh és rdp) és opcióként autentikáció, integrált spam- és vírusszűrés. Kapható szoftvercsomagként (OS+Zorp komponensek), illetve az integrátor (a háttérben a gyártóval) tud ajánlani biztosan helyesen működő hardvert és segít az adott forgalomra történő méretezésben is. A magas rendelkezésre állást valóban a klasszikus eszközökkel tudod megoldani. A kereskedelmi Zorp esetében ez legtöbbször heartbeat, régi stílusú konfigurációval, a GPL esetében bármi lehet, ami szimpatikus (keepalived, CRM-es heartbeat, corosync, stb.), csak az IP címek és a tűzfalfunkcióhoz kapcsolódó démonok (pl. dns, ntp szerver) billegtetését kell megoldani.