[zorp-hu] =?iso-8859-2?Q?T=FBzfal?= MAC

[Magosányi Árpád]

Hi!

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 m=
eg 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:

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
a hostok több umbrella zónában helyezkednek el. Vagy felírod
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 zónához szubjektumként (amikor onnan indul ki a kapcsolat) é=
s
> >  objektumként (amikor oda megy be a kapcsolat) lehet különböz=
õ
> >  biztonsági attribútumokat rendelni
> 
> Jelenleg megmondhatom, hogy az adott zonaba milyen protokollon
> kapcsolodhat valaki (sok egyeb korlatozas mellett), es ellenorizhetem,
> hogy milyen parancsok juthatnak be a zonaba. Ekkor tudnom kell azt is,
> hogy egy adott parancsra milyen valasz johet, es ha nem felel meg,
> akkor nem engedem ki. Megprobalnad elmagyarazni, hogy milyen elonyoket
> remelsz a "biztonsagi attributumok" bevezetesetol, es milyen proxyk
> eseten latod, hogy lehet ezeknek szerepuk?

Fentebb elmagyaráztam. Mindegyik proxy esetén van szerepe. Ha tudod,
hogy melyik mûvelet melyik kategóriába tartozik (rwcf), akkor alkalmazni
tudod rá a szabályokat.

> > -a döntési réteg a kapcsolat engedélyezésérõl az inform=
ációáramlási
> >  attribútumok alapján a
> > http://www.lme.hu/rendezvenyek/konferencia/2000/anyagok/magosanyi_a.pdf
> >  elõadásban leírtak szerint.
> 
> Elolvastam (es volt szerencsem eloben is meghallgatni az eloadast).
> De ismet az jutott eszembe, mint amit fentebb kerdeztem: milyen elonyok
> szarmaznanak ebbol? Kerlek, hogy valami kezzelfoghato peldan keresztul
> probald meg elmagyarazni, ne a matematika "egyszeru" nyelven :)

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ó

Végignézhetjük a fenti pontokat.

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.

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
jár, hogy a védelmi politika kikényszerítése és a biztonsági
attribútumok ismerete nem egy fejben összpontosul. Ez a probléma jóval
akutabb annál, mint amilyennek látszik: a biztonsági attribútumokat a
rendszer felhasználója és fejlesztõje/integrátora közösen határozzák
meg, és a legtöbb esetben implicit módon, nem is tudva arról, hogy
éppen ezt teszik. A tûzfal admin ezek után próbálkozhat azzal, hogy
kiszedi belõlük az információt, de nehéz dolga van. Ezért segít az,
ha a biztonsági attribútumok meghatározása egy explicit tevékenység,
ami nélkül a rendszer nem funkcionál.

3. Amikor az ember bicskával próbál faházat építeni, nem túl egyszerû
a dolga. A tûzfalak és a csomagszûrõ routerek mindegyike bizonyos nagyon
alapvetõ problémákat képes megoldani. Az információáramlási modell
kikényszerítéséhez viszont pl rejtett csatorna redukciót kell végezni.
A jelenlegi hálózati protokollok mellett erre a tûzfalnak úgy is kevés
esélye van, ha minden protokollelemet képes kezelni. Ennek a célnak
a Zorp sem jár a közelében, a többiek pedig nem is esélyesek rá.
É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,
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.

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.

-- 
GNU GPL: csak tiszta forrásból