[zorp-hu] Tűzfal MAC

[Kosa Attila]

On Mon, Oct 27, 2003 at 10:39:49PM +0100, Magosányi Árpád wrote:
> 2003-10-27, h keltezéssel Kosa Attila ezt írta:
> > > -a zónát nem csak IP cím, hanem IP cím és port alapján is meg lehet adni
> > 
> > Tudnal mondani egy gyakorlati peldat, amikor ennek jelentosege van?
> > Mert erzesem szerint a csomagszurovel tudom korlatozni, hogy mely
> > portokat ne erje el egy adott gep egy adott zonaval kapcsolatban...
> 
> A filozófia egy kicsit más: nem azt adod meg, hogy melyik gép melyik
> portjai egy másik gép melyik portjait érjék el, hanem azt mondod meg,
> hogy a hálózaton melyik objektum/szubjektum milyen biztonsági
> besorolással bír. Az, hogy mi mit hogyan érhet el, az ebből következik,
> és innentől csak technikai részletkérdés. Mondok egy példát:

Az az igazsag, hogy nem igazan erzem a kulonbseget. Mennyiben
konfiguralod maskent a csomagszurot, illetve a Zorpot, ha magasabb
biztonsagi besorolassal biro adatokhoz szeretnel hozzaferest
biztositani? Meg pontosabban: mit konfiguralsz maskent rajtuk?

> Tegyük fel, hogy van néhányszor tíz hostod, amelyek némelyikén
> meghatározott besorolású adatok vannak, de vannak olyanok is,
> amelyeken többféle besorolás létezik, és a processz forrásportja
> szerint meg lehet mondani, hogy milyen besorolású. Mondjuk ezek

Ezzel meginkabb megkavartal :) Melyik processz forrasportja szerint
akarod megallapitani, hogy milyen biztonsagi besorolasba tartozik? A
szerver processzeknek viszonylag jol meghatarozott portszamaik vannak,
a kliensek pedig a legtobb esetben 1023 folul jonnek.

> a hostok több umbrella zónában helyezkednek el. Vagy felírod

Sosem szoktam umbrellat hasznalni, mert nekem atlathatatlanna teszi a
konfiguralast. Sokkal nehezebben kovethetonek tartom a "mindent egy
konfigfajlba" elvet. Inkabb szet szoktam szedni bizonyos szempontok
alapjan a kulonbozo proxykat. Peldaul a dmz-be a net felol tarto
kapcsolatokat egy policy fajlba teszem, a belso halorol a dmz-be
tartoakat pedig egy masikba (es igy tovabb).

> az egész hóbelevanc descartes szorzatát, vagy találsz valami
> értelmes leírási módot, hogy ne megabyte-okra rúgjon a
> policyd mérete. Nem árt ilyenkor, ha a leírási mód tükrözi
> a valós helyzetet. Képzeld el azt a helyzetet, amikor egy újabb
> objektumot veszel fel, vagy módosítasz. Nem mindegy, hogy egy
> helyen vagy n helyen kell átírnod.

A legtobb esetben ket helyen kell atirnom a dolgokat, a csomagszuro
konfigjaban, illetve az adott zona policy fajljaban. Gyakorlatilag nincs
olyan hely, ahol 10-nel tobb lenne a kulonbozo policy fajlok szama.
Persze lehet, hogy tul egyszeru helyekkel foglalkozom :)

> A tűzfal egyik funkciója, hogy az információáramlást szabályozza.
> Másképpen fogalmazva a szervezeti információáramlási politikát kell
> neki kikényszeríteni. Ez egy kötelező hozzáférésvezérlési politika,
> ugyanis jellegéből adódóan a szervezet minden információval foglalkozó
> mechanizmusában (nem csak IT) ki kell kényszeríteni ahhoz, hogy értelme
> legyen. A jelenlegi hálózati határvédelmi megoldások mindegyike (na
> majdnem mindegyik, hiszen létezik a DragonFly) ezt úgy oldja meg, hogy
> többé-kevésbé (kevésbé) hatékony eszközöket ad a tűzfaladminisztrátor
> kezébe, amelyekkel valamilyen választott hozzáférésvezérlési politikát
> lehet kikényszeríteni. A választott hozzáférésvezérlésből pedig úgy lesz
> kötelező hozzáférésvezérlés, hogy reménykedünk benne, hogy a
> tűzfaladminisztrátor
> 1. figyelembe vette az információáramlási modellt
> 2. rendelkezik a szükséges információkkal az egyes objektumok/
> szubjektumok biztonsági tulajdonságairól.
> 3. az általa használt eszköz megfelelő az információáramlási politika
> betartatására
> 4. nem tévedett, vagy ha tévedett, akkor van valamilyen mechanizmus
> aminek segítségével a tévedés detektálható és javítható

Ismet csak azt kell mondanom, hogy nem ertem. Amikor nekem kell csinalni
egy tuzfalat, akkor a legelso feladat az, hogy meg kell hatarozni,
milyen adatokat szeretnenek elerni a tuzfalon keresztul, illetve ezek az
adatok hol helyezkednek el. Ezt felrajzolva eleg jol lathatova valik,
hogy honnan, merre, es milyen iranyu kapcsolatokat kell engedelyezni.
Innentol pedig az egyes programok sajatossagainak megfeleloen zajlik a
konfiguralas (peldaul spop3-hoz csak a 995-os portra kell odaengedni az
1023 folul erkezo klienst). Attol, hogy borzasztoan fontos adatok vannak
a pop3 szerveren, meg nem tudom maskepp konfiguralni...

> 1. Elég ritka az, hogy létezik egyáltalán megfogalmazása az
> információáramlási modellnek olyan pontatlan kijelentéseken felül, mint
> hogy "a szervezet bizalmas adatait meg kell őrizni", vagy "a szervezet
> erőforrásait védeni kell az illetéktelen hozzáféréstől". Ezekből a
> kijelentésekből persze lehet több-kevesebb nehézséggel egy használható
> információáramlási politikát csinálni, de ritkán szoktak erre a szintre
> eljutni. A tűzfaladminisztrátorok ezért általában megérzésre szokták a
> szabályokat beállítani, és elég nehéz dolguk van akkor, ha egy szabály
> logikus voltát kell elmagyarázniuk valakinek, akit nem is érdekel a
> biztonság.

Munkambol adodoan ezt mindig meg kell csinalnom, egyszeruen nem tudom
kihagyni ezt a lepest.

> 2. Amint egy rendszer túlnövi azt a méretet, hogy egyetlen ember képes
> legyen minden üzemeltetési és biztonsági aspektusát átlátni (tudok
> olyan példát mondani, ahol ez egyetlen PC-n sikerült:), ideális esetben
> a feladatok valamilyen elhatárolása fog megtörténni. Ez gyakran azzal

Nem talalkoztam meg olyan esettel, ahol a megfelelo dokumentalas ne
oldotta volna meg ezt a helyzetet.

> És akkor vedd ennek a konfigurációs overhead-jét. Nézzük meg, hogy
> a választott hozzáférésvezérlési politikára épülő konfigurációnál
> hol tartunk: N=hostok száma, K=védelmi szintek átlagos száma hostonként,

Probald mar meg korulirni, hogy mit ertesz vedelmi szinten egy gepen,
legy szives.

> P=protokollok száma, Q=protokollelemek átlagos száma protokollonként.
> A konfigurálandó dolgok hozzávetőleges száma:
> (N*K)*(N*K-1)/2*(P*Q)
> Itt a Q nagyjából 30 körül lehet, az első két tag pedig nagyjából a
> hostok négyzetével arányos. 10 hostnál és 5 protokollnál valami 7500
> konfigurálandó dolgot kapunk elméleti értékként, de ez a gyakorlatban
> is lenne kb 3000.  Ezt persze tudod különféle konfigurációs trükkökkel
> csökkenteni. Kb addig, amíg eljutsz ahhoz a koncepcióhoz, hogy ne a
> kapcsolatok leírására kelljen fókuszálni, hanem az
> objektumok/szubjektumok leírására. Hiszen a többi ennek függvénye.

Lehet, hogy ugyanarrol beszelunk, csak en nem tudomanyosan fogalmazom
meg :)

> 4. Mindenki téved (nagy ritkán még én is szoktam;). Főleg ha 3000 dolgot
> kell bekonfigurálnia egy délután alatt. Ilyenkor segít az, ha kevés
> lehetőséget hagyunk a tévedésre. Pl a rendszer failsafe. Úgy tűnik, hogy
> valamely kapcsolat nem felel meg az információáramlási politikának?
> Tiltsa le a programlogika. A tűzfaladminnak így aránylag jó
> visszajelzése van: a felhasználó sírni fog, ha a kapcsolatra szükség
> van. A biztonsági attribútumok pedig kevesebben vannak, mint a
> tűzfalszabályok DAC esetén, így azokat átnézni sem bonyolult, sőt a
> zónahierarchiára épülő egyszerű szabályok (ilyenek a mostani Zorp
> kódban lévő öröklési szabályok is) egyszerűbbé teszik a hiba kiszűrését,
> vagy az átnézendő attribútumok számát csökkentik drasztikusan.
> Még egy előny: ha a feladatelhatárolás úgy szól, az attribútumok
> megfelelősége nem is a tűzfaladminisztrátor dolga. Egy gonddal kevesebb.

Ezt a bekezdest teljesen ertettem, bar nekem nem egyszerubb a
zonahierarchia a kulonallo zonaknal, illetve policy fajloknal :)

-- 
		Udvozlettel
				    Zsiga