The Official Unofficial Zorp project
 
Overview| Examples| Bugs| FAQ | White papers | Download | Help wanted | SourceForge Project page | Filltable utility  
 
 
SourceForge.net: SF.net Project News: Zorp unofficial
  • zorp 2.0.9-6 has been released
  • iptables-utils zorp-unoff version has been released
  • New whitepaper, even more FAQs
  • Zorp whitepapers released, new FAQs
  • New tproxy versions
  • New Zorp version: get the DN
  • The best bughunter
  • Bughunting contest extended
  • Valentine day bughunting contest!
  • Site updates: FAQ, design
  • SourceForge.net: Project File Releases: Zorp unofficial
  • zorp 2.0.9-6 released (Mon, 01 Nov 2004 21:49:58 GMT)
  • zorp 2.0.9-6 released (Mon, 01 Nov 2004 21:40:56 GMT)
  • iptables-utils 1.21-1 released (Mon, 01 Nov 2004 21:19:42 GMT)
  • zorp 2.0.9-1 released (Sat, 12 Jun 2004 00:00:00 GMT)
  • zorplibll 2.0.26.24-1 released (Sat, 12 Jun 2004 00:00:00 GMT)
  • zorp zorp_2.0.8-1 released (Thu, 11 Dec 2003 00:00:00 GMT)
  • zorp zorp_2.0.7-2 released (Wed, 03 Dec 2003 00:00:00 GMT)
  • zorp zorp_2.0.7-1 released (Tue, 11 Nov 2003 00:00:00 GMT)
  • zorplibll zorplibll_2.0.26.23-1 released (Mon, 10 Nov 2003 00:00:00 GMT)
  • download
    
    Tűzfalak és az információáramlási politika
    
    -------------------------------------------------------------------
    
    Ez a dokumentum nem része a "Zorp Anatómia" sorozatnak.
    Nem a Zorp működésével kapcsolatos kérdéseket, hanem általánosabb,
    a tűzfalak használatával kapcsolatos kérdéseket boncolgat.
    
    Köszönet Kósa Attilának a kérdések felvetéséért.
    
    -------------------------------------------------------------------
    
    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.