Z ORP GPL UHU F ELHASZNÁLÓI K ÉZIKÖNYV
1.0b kiadás, a kézirat lezárva 2003. december 1-én. Copyright © 2002, 2003, 2004, BalaBit IT Kft. A kiadvány tartalmának, illetve részeinek sokszorosítása abban az esetben engedélyezett, ha jelen licencet minden másolt példány tartalmazza. Jelen kiadványt más kiadvány részeként vagy egyéb termék kiegészít˝ojeként csak az UHU-Linux Kft el˝ozetes engedélyével lehet forgalomba hozni. Utóbbi esetben az UHU-Linux Kft írásos hozzájárulásának másolatát a kiadványnak/terméknek tartalmaznia kell. A kiadványban szerepl˝o információkat a szerz˝ok legjobb tudásuk szerint állították össze, ennek ellenére hiba el˝ofordulása nem kizárható. A szerz˝ok és az UHU-Linux Kft. semmiféle felel˝osséget nem vállalnak és semmilyen anyagi kárért nem felel˝osek, amely bármilyen vélt, vagy valós módon a kiadványban leírtak alkalmazásából eredhet. A kiadvánnyal kapcsolatos javaslatokat, megjegyzéseket a következ˝o e-mail címre kérjük elküldeni:
[email protected] A kiadvány készítésekor kizárólag szabad szoftverek kerültek felhasználásra. A nyomdai el˝okészítést a LATEX tördel˝oprogram végezte. A teljes folyamat szabad felhasználású Linux operációs rendszer alatt zajlott le. Szerz˝ok: a BalaBit IT Kft munkatársai Szerkesztette és kiegészítette: Hazai Géza
[email protected]
Szedés: LATEX2e 3.14159 verzió A kiadvány a Magyar Linux Alapítvány
(http://www.linuxalapitvany.hu) szervezésében készült
Tartalomjegyzék El˝ oszó Az ismertet˝or˝ol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tartalmi összefoglaló . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix xi xi
Termékengedély xv A termékengedély magyar fordítása . . . . . . . . . . . . . . . . . . . . . xxii 1. Bevezetés 1.1. A tuzfalakról ˝ általában . . . . . . . . . 1.2. A termék áttekintése . . . . . . . . . . 1.2.1. A Zorp jellemz˝oi . . . . . . . . . 1.3. Zorp biztonsági architektúra . . . . . 1.4. Az adatkezelés áttekintése . . . . . . . 1.5. Fontosabb fogalmak . . . . . . . . . . 1.6. A program alapértelmezett muködése ˝
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
1 1 3 3 5 7 9 10
2. Telepítés el˝ okészítése 2.1. A tuzfal ˝ policyjának el˝okészítése . . . . . . . . . . . . 2.1.1. Elméleti tervezés . . . . . . . . . . . . . . . . . 2.1.2. Tervezés és dokumentálás a gyakorlatban . . . 2.2. Rendszerkövetelmények . . . . . . . . . . . . . . . . . 2.2.1. Hardver követelmények . . . . . . . . . . . . . 2.2.2. Szoftver követelmények . . . . . . . . . . . . . 2.3. A hálózati tartomány el˝okészítése a Zorp telepítésére 2.3.1. A tuzfal ˝ helye a hálózati architektúrában . . . 2.3.2. A hálózati eszközök . . . . . . . . . . . . . . . . 2.3.3. IP címváltás . . . . . . . . . . . . . . . . . . . . 2.3.4. DNS szerver . . . . . . . . . . . . . . . . . . . . 2.3.5. E-mail szolgáltatás . . . . . . . . . . . . . . . . 2.3.6. Web hozzáférés . . . . . . . . . . . . . . . . . . 2.3.7. SOCKS . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
13 13 13 19 20 20 22 22 22 23 23 24 24 25 26
iii
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
iv 3. Telepítés 3.1. A Zorp disztribúciós CD-ROM . . . 3.2. Indítás és az els˝o lépések . . . . . 3.3. Ha az egér nem muködik. ˝ .. . . . 3.4. A merevlemez formázása . . . . . 3.5. A telepítend˝o csomagok . . . . . . 3.6. A grub telepítése, rendszerbetöltés 3.7. Felhasználók létrehozása . . . . . 3.7.1. Root jelszó megadása . . . . 3.7.2. Új felhasználó létrehozása . 3.8. Hálózati kártyák beállítása . . . . 3.9. Hálózati beállítások . . . . . . . . 3.9.1. Névkiszolgáló megadása . . 3.9.2. Keresési tartományok . . . 3.9.3. Hoszt nevek . . . . . . . . .
TARTALOMJEGYZÉK
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
27 27 27 29 30 33 33 35 36 37 37 38 38 39 39
4. Beállítás 4.1. Template beállítások használata . . . . 4.1.1. Az uzi muködése ˝ . . . . . . . . . 4.2. Az operációs rendszer konfigurálása . . 4.2.1. Modulok . . . . . . . . . . . . . . 4.2.2. Er˝oforrás korlátozások . . . . . . 4.2.3. Kernel korlátozások . . . . . . . 4.2.4. Alkalmazások korlátozásai . . . . 4.2.5. Helyi port tartomány . . . . . . . 4.2.6. IP forwarding . . . . . . . . . . . 4.2.7. IP cím spoofolás . . . . . . . . . . 4.2.8. TCP paraméterek . . . . . . . . . 4.3. Natív proxyk . . . . . . . . . . . . . . . . 4.4. A csomagszur˝ ˝ o konfigurálása . . . . . . 4.5. Zorp elemek . . . . . . . . . . . . . . . . 4.5.1. Konfiguráció . . . . . . . . . . . . 4.5.2. példányok leírása . . . . . . . . . 4.5.3. A Python alkalmazások osztályai 4.5.4. A Zorp bináris verziója . . . . . . 4.5.5. A zorpctl script . . . . . . . . . 4.6. A Zorp konfigurálása a zui segítségével
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
41 41 41 45 45 45 46 46 47 47 47 47 47 48 50 50 50 51 51 51 51
5. Beállítások haladóknak 5.1. A Python áttekintése . . . . . . . . 5.1.1. Modulok és Csomagok . . . 5.1.2. Parancsok . . . . . . . . . . 5.1.3. Változók . . . . . . . . . . . 5.1.4. Függvények meghatározása 5.1.5. Kivételek/hibák . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
63 63 63 64 65 65 66
. . . . . . . . . . . . . .
. . . . . .
. . . . . . . . . . . . . .
. . . . . .
. . . . . .
v
TARTALOMJEGYZÉK 5.1.6. Python osztályok . . . . . . . . . . . . . 5.2. A Zorp osztályainak áttekintése . . . . . . . . 5.3. Minta Policy készítése . . . . . . . . . . . . . . 5.3.1. A hozzáférés ellen˝orzés alapjai: a zónák 5.3.2. A Zorp alkalmazásokat indító funkciók 5.3.3. Szolgáltatás meghatározása . . . . . . . 5.3.4. Listener létesítése . . . . . . . . . . . . . 5.3.5. Proxyk személyreszabása . . . . . . . . 5.3.6. UDP szolgáltatás felállítása . . . . . . . 6. Üzemeltetés és karbantartás 6.1. Futtatható alkalmazások . . . . . . . . 6.2. A telepítés tesztje . . . . . . . . . . . . . 6.3. Integritás ellen˝orzése . . . . . . . . . . . 6.4. A rendszernapló ellen˝orzése . . . . . . . 6.5. Szolgáltatásaink követése . . . . . . . . 6.6. A biztonságtechnika sebezhet˝o pontjai .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
66 66 68 68 69 69 70 70 71
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
73 73 74 75 75 75 76
A. Kernel patchek
77
B. Szolgáltatás mátrix példa
79
C. IPTables beállítás példa
81
D. Zorp beállítás példa
85
E. El˝ ore meghatározott proxyk listája
89
F. A disztribúciós CD-n lév˝ o csomagok G. Installálás karakteres képerny˝ ovel G.1. A cél-merevlemez el˝okészítése . . . . . G.2. A disztribúció másolása . . . . . . . . G.3. Konfigurálás . . . . . . . . . . . . . . . G.4. A root jelszó beállítása . . . . . . . . . G.5. Az installálás befejezése . . . . . . . . G.5.1. Csomagok installálása . . . . . G.5.2. További szoftverek hozzáadása
105
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
117 120 122 123 125 125 125 126
vi
TARTALOMJEGYZÉK
Ábrák jegyzéke . . . . . . . . . . . . . . . . . . . .
xiii
1.1. A Zorp biztonsági felépítése . . . . . . . . . . . . . . . . . . . . . . . 1.2. A Zorp kezelésének áttekintése . . . . . . . . . . . . . . . . . . . . . 1.3. Outband autentikáció . . . . . . . . . . . . . . . . . . . . . . . . . .
5 7 11
2.1. Példa a hálózati topológiára . . . . . . . . . . . . . . . . . . . . . . .
22
3.1. Üdvözl˝o képerny˝o . . . . . . . . . . . . . . . . . . . . . . 3.2. Segítség a telepítés mód kiválasztásához . . . . . . . . 3.3. UHU-Linux licenc . . . . . . . . . . . . . . . . . . . . . . 3.4. Egér protokolljának és csatlakoztatásának kiválasztása 3.5. A merevlemez formázásának el˝okészítése . . . . . . . . 3.6. A csomagok felmásolása . . . . . . . . . . . . . . . . . . 3.7. A csomagok beállítása . . . . . . . . . . . . . . . . . . . 3.8. Rendszerbetöltés kiválasztása . . . . . . . . . . . . . . 3.9. Hálózati kártyák beállítása . . . . . . . . . . . . . . . . 3.10.Névkiszolgálók, tartományok, hosztok . . . . . . . . . . 3.11.A telepítés befejezése . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
28 29 30 31 32 34 35 36 37 38 40
4.1. UZI DMZ menü . . . . . . . . . . . . . . . . . 4.2. Szolgáltatások menü . . . . . . . . . . . . . . 4.3. SMTP domain-ek . . . . . . . . . . . . . . . . 4.4. DMZ szerver . . . . . . . . . . . . . . . . . . . 4.5. ZUI f˝omenü . . . . . . . . . . . . . . . . . . . 4.6. Új policy készítése . . . . . . . . . . . . . . . 4.7. Policy szerkesztés . . . . . . . . . . . . . . . . 4.8. Zóna létrehozása . . . . . . . . . . . . . . . . 4.9. Egy zóna címtartományának meghatározása 4.10.Alkalmazás szerkesztése . . . . . . . . . . . . 4.11.Példány szerkesztése . . . . . . . . . . . . . . 4.12.Szolgáltatás készítése . . . . . . . . . . . . . 4.13.Szolgáltatás szerkesztése . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
42 43 45 46 52 53 53 55 55 56 57 58 59
1.
Egy hipotetikus hálózati modell
vii
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
viii
ÁBRÁK JEGYZÉKE
4.14.Listener készítése . . . . . . . . . . . . . . . . 4.15.Egy el˝ore meghatározott proxy beillesztése . 4.16.El˝ore meghatározott proxyk részletes leírása 4.17.El˝ore meghatározott proxy készítése . . . . .
. . . .
60 61 61 62
B.1. Szabály-mátrix minta . . . . . . . . . . . . . . . . . . . . . . . . . .
80
G.1. Üdvözl˝o képerny˝o . . . . . . . . . . . . G.2. Szakért˝oi menü . . . . . . . . . . . . . G.3. Eszköz kiválasztása particionáláshoz G.4. A root partíció felcsatolása . . . . . . G.5. Partíció választás felcsatoláshoz . . . G.6. Csatolási pont megadása . . . . . . . G.7. Partíció lecsatolása installálás közben G.8. Az installálás befejezése . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . .
. . . . . . . .
. . . . . . . .
117 119 120 121 122 123 124 125
El˝ oszó Alkalmazási terület Ezt a könyvet az UHU-Linux Tuzfal ˝ verzióval most ismerked˝o rendszergazdáknak készítettük. Feltételezzük, hogy az olvasó gyakorlati tudással rendelkezik a hálózatok és a hálózati adminisztráció terén.
Kiknek szól ez a füzet? Az ismertet˝ot olyan rendszergazdáknak ajánljuk, akik még nem használták a Zorpot, és hálózatok kiépítéséért, azok karbantartásáért felel˝osek.
Védjegyek – A Zorp név és a Zorp logó, a BalaBit név és a BalaBit logó a BalaBit IT Kft. regisztrált védjegye. – A Linux Linus Torvalds regisztrált védjegye. – A Debian a Software in the Public Interest Inc. regisztrált védjegye. – A Windows 95, 98, NT, 2000 a Microsoft Corporation regisztrált védjegyei. – Az UHU-Linux név az UHU-Linux Kft. regisztrált névjegye.
Termékverzió, CD-n található anyagok A ZorpGPL UHU aktuális verziója: 2.0.3. A DOC könyvtárban található az „UHU Felhasználói kézikönyv” 2003. április 14-én lezárt változata, valamint e dokumentáció el˝oz˝o, 2003. szeptember 2-án lezárt verziója. A CD-n található csomagok felsorolását az F. függelék tartalmazza.
ix
˝ ELOSZÓ
x
Kapcsolatteremtés A ZorpGPL-t fejleszti és karbantartja BalaBit IT Biztonságtechnikai Kft. Csurgói út 20/b Budapest H-1116 Hungary Tel.: +36 1 371-0540 Fax: +36 1 208-0875
[email protected] A ZorpGPL-t terjeszti UHU-Linux Kft Tolnai u. 6 8000 Székesfehérvár Tel.: +36 1 433 1878 Fax: +36 1 433 1890
[email protected]
Kereskedelmi információk A Zorp kereskedelmi változata a Balabit IT Kft-tól és viszonteladóitól szerezhet˝o be. Értékesítési kérdésekkel kapcsolatban keresse a BalaBit IT Kft munkatársait közvetlenül a
[email protected] e-mail címen.
Támogatás A termékkel kapcsolatban technikai támogatás elérhet˝o: Nyilvános levelezési lista: http://lists.balabit.hu/mailman/listinfo/zorp-hu Hivatalos támogatás információ: A ZorpGPL támogatására az UHU-Linux Kft levelezési listát üzemeltet, ami a
[email protected] címen érhet˝o el. A listára a https://lists.uhulinux.hu/info/tuzfal címen lehet feliratkozni.
Tanfolyamok A BalaBit rendszeresen tart hálózati határvédelemmel foglalkozó tanfolyamokat haladó GNU/Linux rendszeradminisztrátorok számára. További információkat a BalaBit honlapján talál: http://www.balabit.hu/training/
˝ ELOSZÓ
xi
Az ismertet˝ or˝ ol Az ismertet˝ot olyan rendszergazdáknak készítettük, akik tisztában vannak a tuzfalak ˝ és a hálózati biztonságtechnika fontosságával. A Zorp egy olyan eszköz, amely teljes köru ˝ ellen˝orzést biztosít a tranzit hálózati forgalom felett, és mindent megtesz annak érdekében, hogy a védett hálózat sértetlen maradjon az Internetr˝ol jöv˝o támadásokkal szemben.
Tartalmi összefoglaló – az 1. fejezetben ismertetjük a tuzfalnál ˝ felhasznált technológiákat, a Zorp tulajdonságait és a telepítéséhez szükséges média csomagot. – a 2. fejezetben leírjuk, milyen tennivalóink vannak a Zorp Professional telepítése el˝ott, illetve a biztonsági rendszertervezés és -kivitelezés alapszabályainak ismertetésén keresztül bemutatjuk, hogyan érdemes megtervezni egy informatikai biztonsági rendszert. – a 3. fejezetben a Zorp Professional verzió telepítésér˝ol és a ZUI használatáról lesz szó. – a 4. fejezetben bemutatjuk, hogyan konfigurálhatjuk a tuzfalat ˝ a Zorp Felhasználói Interfészének (Zorp User Interface, továbbiakban ZUI) segítségével, mellette kitérünk a natív proxyk és a csomagszur˝ ˝ ok javasolt konfigurációjára is – az 5. fejezetben beszélünk a Zorp haladó szintu ˝ konfigurálásáról és a Pythonról. – a 6. fejezetben szó lesz azokról a feladatokról, melyeket rendszeresen el kell végeznünk mint karbantartást. – az A függelékben az ajánlott kernel patchek listáját és hozzáférhet˝oségüket találjuk. – a B függelék tartalmazza a könyvben használt fiktív tuzfal ˝ policy mátrixát. – a C függelék a B függelékben bemutatásra került tuzfal ˝ policyjához igazodó csomagszurési ˝ beállításokat ismerteti. – a D függelékben találjuk a B függelékben ismertetett mátrix alapján felépített policy.py-t – E függelék: a ZUI-ba beépítettünk néhány el˝ore megadott mintát, hogy egyszerubb ˝ legyen a tuzfal ˝ policyjának kialakítása. Itt ezeket a mintákat soroljuk fel és fejtjük ki. – az F függelékben felsoroljuk a Zorp Professional disztribúciós CD-n kínált programcsomag tartalmát.
˝ ELOSZÓ
xii
Feltételezett tudásanyag A könyv olvasóiról a tuzfalak ˝ alapszintu ˝ ismeretén kívül feltételezzük: – A Linux rendszeradminisztráció fels˝o fokú ismeretét. – Az IP alapú hálózati adminisztráció fels˝o fokú ismeretét. – A csomagszurés ˝ (iptables) fels˝o fokú ismeretét. Továbbá feltételezzük, hogy olvasónk rendszerének felépítése nagyban hasonlít az alábbiakhoz: – Hálózati szerkezet: telepíteni tud egy Linux szervert legalább két interfésszel, melyek közül az egyik internet-, a másik a privát hálózatra van kötve. Ajánljuk egy harmadik hálózati interfész használatát a DMZ (Demilitarized Zone) kialakításához. – Feltételezzük, hogy rendelkezik regisztrált domain-névvel (pl.: mydomain.com), a szolgáltatást egy saját DNS (Domain Name System) szerver vagy az ISP biztosítja. – Feltételezzük, hogy a mail szerver a DMZ-ben, a bels˝o hálózaton található, vagy az ISP biztosít küls˝o hozzáférést az elektronikus postához (pl. pop3 szerveren keresztül). – Feltételezzük, hogy rendelkezik router IP-vel vagy egy olyan IP címmel, amely alapértelmezett átjáróként (gateway) muködik. ˝ – Feltételezzük, hogy legalább két publikus IP címmel rendelkezik, az egyik az alapértelmezett átjáró, a másik a tuzfal ˝ publikus (küls˝o) interfésze. Továbbá feltételezzük, hogy a privát hálózat és a demilitarizált zónában (DMZ) található hálózat el˝ore megadott privát IP címekkel rendelkezik. (A címek kijelölését a privát bels˝o hálón az RFC1918 szabvány tartalmazza.) Amennyiben olvasónk publikus hálózattal dolgozik, az IP-MASQUERADEHOWTO-ban és IPCHAINS-HOWTO-ban találhat információt a privát hálózat konfigurálásáról. Könyvünkben a xiii. oldalon látható hipotetikus hálózati modellt vesszük alapul a magyarázatokhoz.
˝ ELOSZÓ
xiii
1. ábra. Egy hipotetikus hálózati modell
xiv
˝ ELOSZÓ
Termékengedély GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software–to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation’s software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
xv
xvi
TERMÉKENGEDÉLY
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author’s protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors’ reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone’s free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such
TERMÉKENGEDÉLY
xvii
modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically
xviii
TERMÉKENGEDÉLY performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
TERMÉKENGEDÉLY
xix
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
xx
TERMÉKENGEDÉLY
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the ”copyright” line and a pointer to where the full notice is found.
xxi
TERMÉKENGEDÉLY Copyright (C)
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA
Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type ‘show w’. This is free software, and you are welcome to redistribute it under certain conditions; type ‘show c’ for details.
The hypothetical commands show w’ and show c’ should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than show w’ and show c’; they could even be mouse-clicks or menu items–whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program ‘Gnomovision’ (which makes passes at compilers) written by James Hacker. <signature of Ty Coon>, 1 April 1989 Ty Coon, President of Vice
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.
xxii
TERMÉKENGEDÉLY
A termékengedély magyar fordítása GNU GPL Magyar fordítás A 2. Verzió (1991. június) fordítása Copyright 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Bárki terjesztheti, másolhatja a dokumentumot, de a módosítása nem megengedett. A fordítás csak tájékoztató jellegu ˝ és jogi szempontból csakis az angol eredeti a mérvadó. El˝oszó A legtöbb program felhasználói jogosultságai azzal a szándékkal készültek, hogy minél kevesebb lehet˝oséget adjanak a terjesztéshez illetve a szoftver megváltoztatásához. A GNU GPL ezzel szemben minél több jogot kíván biztosítani a szabad szoftverek terjesztéséhez és módosításához, hogy a szoftver ingyenes lehessen az összes felhasználója számára. Az Általános Közreadási Feltételek szabályai vonatkoznak a Szabad Szoftver Alapítvány legtöbb szoftverére, illetve minden olyan programra, melynek szerz˝oje úgy dönt, hogy ezt használja a szerz˝oi jog megjelölésekor. (A szabad szoftver alapítvány egyes szoftvereire a GNU LGPL vonatkozik - Library GPL.) Bárki használhatja a programjaiban a GPL-t a szerz˝oi jogi megjegyzésnél. A szabad szoftver megjelölés nem jelenti azt, hogy a szoftvernek nem lehet ára. A GPL dokumentumok úgy készültek, hogy biztosítsák a szabad szoftverek terjeszthet˝oségét (pénzért ha úgy tetszik), illetve a forráskód hozzáférhet˝oséget, hogy bárki szabadon módosíthassa azt, ha akarja mindenképpen tudjon err˝ol a lehet˝oségr˝ol. A szerz˝o jogainak védelmében korlátozásokat kell hozni, melyek megtiltják, hogy bárki megtagadja e jogokat másoktól, vagy ezekr˝ol való lemondásra kényszerítene valakit. Ezek a korlátozások bizonyos kötelezettségeket jelentenek azok számára akik a terjesztik vagy módosítják a szoftvert. Ha valaki ilyen programot terjeszt, akár ingyen akár egy bizonyos összeg fejében, a szoftverre vonatkozó minden jogát tovább kell adnia az ügyfeleinek. Biztosítani kell továbbá, hogy mindenki megkapja, vagy lehet˝osége legyen hozzájutni a forráskódhoz. Ezen kívül el kell juttatni ezen szabályokat tartalmazó dokumentumot is, hogy mindenki értesülhessen a jogairól. A jogvédelem két eszköze: (1) a szoftver szerz˝oi jogainak biztosítása (2) ezen szabályok alapján jogok biztosítása a másoláshoz, terjesztéshez és/vagy a szoftver módosításához. Az egyes szerz˝ok és a magunk védelmében biztosítani akarjuk, hogy mindenki megértse: nincs garancia az ilyen szoftverekre. Ha a szoftvert mások módosították és továbbterjesztették, mindenkinek, aki a módosított változatot kapja, tudnia kell, hogy az nem eredeti. Így a mások által okozott hibáknak nem lehet semmiféle hatása az eredeti szerz˝o hírnevére.
TERMÉKENGEDÉLY
xxiii
Végül, mivel a szabad szoftver létét fenyegetik a szoftverszabadalmak, el szeretnénk kerülni annak veszélyét, hogy a szabad szoftver terjeszt˝oi szabadalmat jegyezhessenek be a szoftverre, így tulajdonukká téve azt. Ennek megel˝ozéséhez tisztázni kívánjuk: szabadalom szabad szoftverrel kapcsolatban csak mindenki által szabad használatra jegyezhet˝o be, vagy egyáltalán nem jegyezhet˝o be. A pontos szabályok és a másolásra, terjesztésre, módosításra vonatkozó feltételek következnek. GNU ÁLTALÁNOS KÖZREADÁSI FELTÉTELEK A MÁSOLÁSRA, TERJESZTÉSRE ÉS MÓDOSÍTÁSRA VONATKOZÓ FELTÉTELEK ÉS SZABÁLYOK 0. Ezek a jogok vonatkoznak bármely olyan programra vagy munkára, melynek a szerz˝oi jogi megjegyzésében a jog tulajdonosa a következ˝o szöveget helyezte el: Terjeszthet˝o a GNU GPL-ben foglaltak alapján. A következ˝okben a "Program" megjelölés vonatkozik bármely programra, vagy munkára, a "Programon alapuló munka" pedig magát a Programot, vagy a Programot felhasználó szerz˝oi joggal védett munkát jelenti, vagyis olyan munkát, mely tartalmazza a Programot, vagy annak egy részletét, módosítottan vagy módosítatlanul és/vagy más nyelvre fordítva. (Ezentúl a fordítás minden egyéb megkötés nélkül beletartozik a „módosítás” fogalmába.) A másoláson, terjesztésen és módosításon kívül más tevékenységgel nem foglalkozik ez a dokumentum, azokat hatályon kívülinek tekinti. A Program futtatása nincs korlátozva, illetve a Program kimenetére is csak abban az esetben vonatkozik ez a szabályozás, ha az tartalmazza a Programon alapuló munka egy részletét (attól függetlenül, hogy ez a Program futtatásával jött-e létre). Ez tehát a Program muködését˝ ˝ ol függ. 1. A Program forráskódja másolható és terjeszthet˝o módosítás nélkül bármely adathordozón, feltéve, hogy minden egyes példányon pontosan szerepel a megfelel˝o szerz˝oi jogi megjegyzés, illetve a garanciavállalás elutasítása. Érintetlenül kell hagyni minden erre a szabályozásra és a garancia teljes hiányára utaló szöveget, és ezt a dokumentumot is el kell juttatni mindazokhoz, akik a Programot kapják. Kérhet˝o pénz az adatok fizikai továbbítása fejében, illetve díjazás fejében lehet garanciás támogatást adni a Programhoz. 2. A Program, vagy egy darabja módosítható, mely így az egy, a Programon alapuló munkát alkot, a módosítás ezután tovább terjeszthet˝o az 1. részben adott feltételek szerint, ha az alábbi feltételek is teljesülnek: a) A módosított fájlokat el kell látni olyan megjegyzéssel, mely feltünteti a módosítást végz˝o nevét és a módosítások dátumát. b) Minden olyan munkát vagy programot, mely részben vagy egészben tartalmazza a Programot vagy a Programon alapul, olyan szabályokkal kell kiadni, hogy annak használati joga harmadik személy részére ingyenesen hozzáférhet˝o legyen, ezen dokumentumban található szabályok alapján.
xxiv
TERMÉKENGEDÉLY c) Ha a módosított Program interaktív bemenetet használ, akkor azt úgy kell elkészíteni, hogy a megszokott módon történ˝o indításkor megjelenítsen egy üzenetet a megfelel˝o szerz˝oi jogi megjegyzéssel és a garancia hiányára utaló közléssel (vagy éppen azzal az információval, hogy minként juthat valaki garanciához), illetve azzal az információval, hogy bárki terjesztheti a Programot eme feltételek alapján. Ezen kívül utalást kell tenni rá, hogy miként olvashatja el a felhasználó ezt a dokumentumot. (Kivétel: ha a Program interaktív ugyan, de nem jelenít meg hasonló üzenetet, akkor a Programon alapuló munkának sem kell ezt tennie.)
Ezek a feltételek a módosított munkára, mint egészre vonatkoznak. Ha a munka egy azonosítható részei nem a Programon alapulnak, függetlenként elkülönülten azonosíthatók, akkor ez a szabályozás nem vonatkozik ezekre a részekre, ha azok külön munkaként vannak terjesztve. Viszont, ha ugyanez a rész az egész részeként kerül terjesztésre, és az egész a Programon alapuló munka, akkor az egész terjesztése csak ezen dokumentum alapján lehetséges, mely ebben az esetben a jogokat minden egyes felhasználó számára kiterjeszti az egészre tekintet nélkül arra, hogy mely részt ki írta. Ezen szövegrésznek nem az a célja, hogy a mások jogait elvegye vagy korlátozza a kizárólag saját maga által írt munkákra. A cél, hogy a jogok gyakorlása szabályozva legyen a Programon alapuló, illetve a gyujteményes ˝ munkák terjesztése esetében is. Ezen kívül más munkák, melyek nem a Programon alapulnak, a Programmal (vagy a Programon alapuló munkával) közös adathordozón vagy adattárolón szereplése nem jelenti ezen szabályok érvényességét azokra is. 3. A program (vagy a programon alapuló munka a 2. szakasz alapján) másolható és terjeszthet˝o tárgykódú vagy végrehajtható kódú formájában az 1. és 2. szakaszban foglaltak szerint, amennyiben az alábbi feltételek is teljesülnek: a) A teljes, gép által értelmezhet˝o forráskód kíséri az anyagot, melynek terjesztése az 1. és 2. szakaszban foglaltak szerint történik, szoftverterjesztésre használt hordozón; vagy b) Egy legalább három évre szóló írásos ajánlat kíséri az anyagot, mely szerint bármely küls˝o személynek rendelkezésre áll a teljes gép által értelmezhet˝o forráskód, a fizikai továbbítást fedez˝o összegnél nem nagyobb díjért az 1. és 2. szakaszban foglaltak szerint szoftverterjesztésre használt adathordozón; vagy c) Olyan tájékoztatás kíséri az anyagot, mely tartalmazza az írásos ajánlat szövegét a forráskód biztosítására. (Ez az alternatíva csak nem kereskedelmi terjesztés esetén alkalmazható, abban az esetben, ha a terjeszt˝o a Programhoz a tárgykódú vagy forráskódú formájában jutott hozzá az ajánlattal együtt a b. cikkelynek megfelel˝oen.) Egy munka forráskódja a munkának azt a formáját jelenti, melyben a módosításokat szokás végezni. Egy végrehajtható program esetében a teljes
TERMÉKENGEDÉLY
xxv
forráskód jelenti a modulok forráskódját, a kapcsolódó felületkezel˝o definíciós fájlokat, és a fordítást vezérl˝o parancsfájlokat. Egy speciális kivételként a forráskódnak nem kell tartalmaznia az operációs rendszer f˝obb részeit (kernel fordítóprogram stb.), melyen a végrehajtható kód fut, hacsak nem tartozik ehhez maga a program is. Ha a végrehajtható program vagy tárgykód terjesztése a forráskód hozzáférését egy megadott helyen biztosító ajánlattal történik, ez az ajánlat egyenértéku ˝ a forráskód terjesztésével, még akkor is, ha másoknak így nem kell a forrást lemásolniuk a tárgykóddal együtt. 4. A Programot csak ebben a dokumentumban leírtaknak megfelel˝oen lehet lemásolni, terjeszteni, módosítani, rá jogokat bejegyezni. Az egyéb módon való másolás, módosítás, terjesztés, jogok bejegyzése semmisé teszi a dokumentumban közzétett jogosultságokat. Akik azonban a jogaikat ennek a szerz˝oi jogi szabályozás keretei között kapták, azok joga mindaddig megmarad, amíg teljesen megfelelnek a leírtaknak. 5. Nem kell elfogadni ezt a szabályozást, mivel aláírni sem kell. Ezen kívül viszont semmi más nem adhat jogokat a Program továbbterjesztésére és módosítására. Ezeket a cselekedeteket a törvény bünteti, ha nem ennek a szerz˝oi jogi szabályozásnak a keretei között történnek. Mindezek miatt a Program (vagy a Programon alapuló munka) terjesztése vagy módosítása ezen dokumentum szabályinak elfogadását jelenti. 6. Minden alkalommal, amikor a Program (vagy azon alapuló munka) továbbadása történik, a Program "vev˝oje" automatikusan hozzájut a Program eredeti tulajdonosának szerz˝oi jogait tartalmazó dokumentumhoz, mely biztosítja a Program másolását és terjesztését eme szabályok szerint. Nem lehet semmi módon további korlátozásokat hozni a "vev˝o" számára ezen szabályok betartása céljából. Más szavakkal: a Program továbbadója nem felel˝os más személyekkel betartatni ezeket a szabályokat. 7. Ha bírósági határozat vagy más szabadalmi kötöttségek miatt olyan feltételek állnak el˝o, melyek ellentétesek e szabályozással, ezek nem mentik fel a terjeszt˝ot a feltételek figyelembevétele alól. Ha a terjesztés nem lehetséges ezen szabályozás szerint, akkor egyáltalán nem lehetséges. Például, ha egy szabadalmi szerz˝odés nem engedi meg egy program tiszteletdíj nélküli terjesztését, akkor az egyetlen módja, hogy eleget tegyen valaki mindkét szabályozásnak az, hogy eláll a továbbfejlesztett program terjesztését˝ol. Ha ennek a szakasznak bármely része nem érvényesül, vagy nem érvényesíthet˝o valamely körülmény folytán, akkor a szakaszt kell mérlegelni, egyéb esetekben a szakasz, mint egész alkalmazandó. Ennek a szakasznak nem az a célja, hogy a szabadalmak vagy egyéb hasonló jogok elutasítására bírjon bárkit is. Mindössze meg szeretné védeni a szabad szoftver terjesztés rendszerének egységét, melyet a szabad közreadást szabályozó feltételrendszerek teremtenek meg. Sok ember nagylelku ˝ közremuködése ˝ folytán igen nagyszámú és változatos szoftver terjesztése
xxvi
TERMÉKENGEDÉLY történik ezen a módon, mely nagyban függ ennek a feltétel-rendszernek állandó betartásán. Minden esetben a szerz˝o/adományozó dönti el, hogy muvét ˝ mely rendszer szerint teszi közzé. Ezt a döntést a jogok felhasználója nem befolyásolhatja. Ez a szakasz pontosan szeretné tisztázni a szabályozás hátralev˝o részének lehetséges következményeit. Ha a Program terjesztése és/vagy használata egyes országokban nem lehetséges szabadalmak vagy szer˝oi jogokkal védett kapcsolódási felületek miatt, akkor a Program szerz˝oi jogainak eredeti tulajdonosa, aki a Programot ezen szabályozás alapján adja közre, egy földrajzi megkötést adhat a terjesztésre, és egyes országokat kizárhat. Ekkor a terjesztés csak azokban az országokban lehetséges, amelyek nem lettek ilyen módon kizárva. Ebben az esetben ennek a szabályozásnak kell tartalmazni az ilyen megkötéseket is.
8. A Szabad Szoftver Alapítvány id˝onként a dokumentum felülvizsgált illetve újabb változatait adja ki. Ezek az újabb dokumentumok az el˝oz˝oek szellemében készülnek, de részletekben különböznek, hogy új problémákat kezelhessenek. A dokumentum minden változata egy meghatározott verziószámmal ellátva jelenik meg. Ha a program szerz˝oi jogi megjegyzésében egy bizonyos vagy annál újabb verzió van megjelölve, akkor lehet˝oség van akár a megjelölt, vagy a Szabad Szoftver Alapítvány által kiadott kés˝obbi verzióban leírt feltételek követésére. Ha nincs ilyen megjelölt verzió, akkor a Szabad Szoftver Alapítvány által valaha kibocsátott bármelyik dokumentum alkalmazására lehet˝oség van. 9. A Programot más szabad szoftverbe, melynek szerz˝oi jogi szabályozása különbözik a GPL-t˝ol, akkor lehet beépíteni, ha a szerz˝ot˝ol erre engedélyt lehet szerezni. Abban az esetben, ha a program szerz˝oi jogainak tulajdonosa a Szabad Szoftver Alapítvány, akkor a Szabad Szoftver Alapítvány címére kell írni. Az alapítvány egyes esetekben ezt engedélyezi. A döntés a következ˝o két cél szem el˝ott tartásával fog megtörténni: Megmaradjon a Programon alapuló munkák szabad státusa; segítse el˝o a szoftver újrafelhasználását és megosztását. NINCS GARANCIAVÁLLALÁS 10. MIVEL A PROGRAM HASZNÁLATI JOGA DÍJMENTES, A PROGRAMHOZ NEM JÁR GARANCIA AZ IDEVONATKOZÓ JOGSZABÁLYNAK MEGFELE˝ ˝ JOGOK TULAJDONOSAI ÍRÁSBAN MÁSLOEN. AMENNYIBEN A SZERZOI KÉNT NEM NYILATKOZNAK, A PROGRAM "ÚGY AHOGY VAN" KERÜL KIADÁSRA MINDENFÉLE GARANCIAVÁLLALÁS NÉLKÜL. A PROGRAMMAL KAPCSOLATBAN NINCS SEM SZÁRMAZTATOTT, SEM EGYÉB GARANCIAVÁLLALÁS, BELEÉRTVE DE NEM KIZÁRÓLAGOSAN A FORGALOMBAHOZHATÓSÁGRA VAGY ALKALMAZHATÓSÁGRA VONAT˝ ˝ ÉS MUKÖDÉSÉB ˝ ˝ KOZÓ GARANCIÁKAT. A PROGRAM MINOSÉGÉB OL OL
TERMÉKENGEDÉLY
xxvii
FAKADÓ ÖSSZES KOCKÁZAT A FELHASZNÁLÓT TERHELI. HA A PROG˝ RAM HIBÁSAN MUKÖDIK, A FELHASZNÁLÓNAK MAGÁNAK KELL VÁLLALNIA A JAVÍTÁSHOZ SZÜKSÉGES MINDEN KÖLTSÉGET. ˝ JOGOK 11. AMENNYIBEN A HATÁLYOS JOGSZABÁLYOK, VAGY A SZERZOI TULAJDONOSAI ÍRÁSOS MEGÁLLAPODÁSBAN MÁSKÉNT NEM RENDEL˝ KEZNEK, SEM A PROGRAM SZERZOJE SEM MÁSOK, AKIK MÓDOSÍTOTTÁK ÉS/VAGY TERJESZTETTÉK A PROGRAMOT A FENTIEKNEK MEGFE˝ ˝ FELELOSSÉ ˝ LELOEN, NEM TEHETOK KÁROKÉRT, MELYEK LEHETNEK VÉLETLENEK, VAGY MEGHATÁROZOTT KÖRÜLMÉNYEK MIATT TÖRTÉNTEK (BELEÉRTVE DE NEM KIZÁRÓLAGOSAN AZ ADATVESZTÉST ÉS A HELYTELEN ADATFELDOLGOZÁST, VALAMINT A MÁS PROGRAMOK˝ KAL VALÓ HIBÁS EGYÜTTMUKÖDÉST), AKKOR SEM, HA EZEN FELEK ˝ TUDATÁBAN VOLTAK ILYEN KÁROK KELETKEZÉSÉNEK LEHETOSÉGÉNEK. FELTÉTELEK ÉS SZABÁLYOK VÉGE Hogyan alkalmazhatóak ezek a szabályok egy új programra Ha valaki egy új programot készít és szeretné hogy az a többi ember számára a lehet˝o leginkább hasznos legyen, annak az a legjobb módja, hogy szabad szoftverré teszi azt, megengedve bárki számára a szabad másolást és módosítást ezen szabályok alapján. Ehhez a következ˝o megjegyzést kell csatolni a programhoz. A legbiztosabb ezt minden egyes forrásfájl elejére beírni, így közölve leghatásosabban a garancia visszautasítását. Minden fájl ezen kívül kell, hogy tartalmazzon egy „copyright” sort és egy utalást arra helyre, ahol a teljes szöveg található. <egy sor mely megadja a program nevét, és leírja, hogy mit csinál.> Copyright (C) <év> Ez egy szabad szoftver; terjeszthet˝ o illetve módosítható a GNU Általános Közreadási Feltételek dokumentumában leírtak szerint -- 2. vagy kés˝ obbi verzió --, melyet a Szabad Szoftver Alapítvány ad ki. Ez a program abban a reményben kerül közreadásra, hogy hasznos lesz, de minden egyéb GARANCIA NÉLKÜL, az ELADHATÓSÁGRA VAGY VALAMELY CÉLRA VALÓ ALKALMAZHATÓSÁGRA VALÓ SZÁRMAZTATOTT garanciát is beleértve. További részletekért lásd a GNU Általános Közreadási Feltételek dokumentumát. A programmal együtt kellett, hogy érkezzen egy példány a GNU Általános Közreadási Feltételek dokumentumából is. Ha mégsem akkor ezt a Szabad Szoftver Alapítványnak küldött levélben jelezni kell. A szabad szoftver alapítvány címe: Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
A programhoz csatolni kell azt is, hogy miként lehet kapcsolatba lépni a szerz˝ovel, elektronikus vagy hagyományos levél küldésével.
xxviii
TERMÉKENGEDÉLY
Ha a program interaktív, a következ˝ohöz hasonló üzenettel lehet ezt megtenni a program indulásakor: Gnomovision version 69, Copyright (C) év a szerz˝ o neve A Gnomovision programhoz SEMMIFÉLE GARANCIA NEM JÁR; A részletes tájékoztatáshoz ezt kell begépelni: ,,show w’’. Ez egy szabad szoftver; bizonyos feltételek mellett terjeszthet˝ o illetve módosítható. A részletes tájékoztatáshoz ezt kell begépelni: ‘show c’.
A „show w” és „show c” képzeletbeli parancsok, és a GNU Általános Közreadási Feltételek megfelel˝o szakaszát kell megjeleníteniük. Természetesen a valódi parancsok lehetnek a „show w” és a „show c”-t˝ol különböz˝oek is, lehetnek akár egérkattintások vagy menüpontok is a programnak megfelel˝oen. Ha szükséges, meg kell szerezni a munkáltatótól (programozó esetében) vagy iskolától a program szerz˝oi jogairól való lemondás igazolását. Erre itt egy példa: Az Adócsaló BT ezennel lemond minden szerz˝ oi jogi érdekeltségér˝ ol a ‘Gnomovision’ programmal kapcsolatban, melyet Krekker Jani írt. <Maffy Jocó aláírása>, 1987. április 1. Maffy Jocó alelnök
A GPL általános közreadási feltételek dokumentuma nem engedi meg, hogy szabad szoftver része legyen szabadalommal védett programnak. Ha a program egy eljáráskönyvtár akkor inkább a más programokkal való összefuzését ˝ célszeru ˝ megengedni. Ha ez a cél akkor a GNU LGPL dokumentumot lehet alkalmazni, mely ilyen eljáráskönyvtárak közreadását szabályozza.
1. fejezet
Bevezetés Ebben a fejezetben bemutatjuk a tuzfal ˝ fogalmát és a Zorp Professional legfontosabb tulajdonságait. Mivel ez a bemutatkozó fejezet, ezért csak alapvet˝o információkat tartalmaz, a részletekkel a kés˝obbi fejezetekben foglalkozunk.
1.1. A tuzfalakról ˝ általában A tuzfal ˝ arra szolgál, hogy ellen˝orizze a hálózati forgalmat és betartassa a vállalat Informatikai Biztonsági Szabályzat hálózati határvédelemre vonatkozó el˝oírásait. A következ˝okben megismerhetjük az egyes tuzfal ˝ programok közötti különbséget. Bastion host: egy védett szerver vagy munkaállomás, ami védett (privát) hálózatunkhoz és az internethez egyaránt kapcsolódik (dual homed). Mivel nincs közvetlen kapcsolat a hálózatok között (nincsen csomagtovábbítás), ezért ahhoz, hogy privát hálózatunkról elérjünk egy internetes szolgáltatást, be kell jelentkeznünk a bastion hostra, és onnan kell futtatnunk a telepített kliens programot, munkaállomásunkat mintegy terminálként használva. Ez a fajta védekezés elégséges, ha megbízunk felhasználóinkban és minden bastion hoston található kliens programban. csomagszurés: ˝ Mint ahogy a név is utal rá, segítségével a hálózati rétegen (a TCP/IP rendszerben az IP réteg) meg tudjuk szurni ˝ a hálózati forgalmat. Ez azt jelenti, hogy a csomag további sorsáról a csomagszur˝ ˝ o dönt a csomag fejlécében található információ alapján (IP, UDP és TCP fejlécek). Ez az információ nem elégséges egy olyan környezetben, ahol fontos szempont a biztonság, mivel az áthaladó csomag tartalma (az adott protokoll parancsai) nem kerül ellen˝orzés alá. Egy TCP kapcsolat irányát (azaz, hogy az adott kapcsolatot kifelé vagy befelé kezdeményeztük) megállapíthatjuk az
1
2
1. FEJEZET. BEVEZETÉS alapján, hogy szerepel-e az ACK rész a TCP fejlécben, így bármilyen csomag, amely tartalmazza az ACK részt, átjut a csomagszurésen, ˝ még akkor is, ha nem része egyetlen él˝o kapcsolatnak sem.
stateful packet filtering (SPF): a csomagszurés ˝ továbbfejlesztett változata, amelyb˝ol kimaradtak az egyszeru ˝ csomagszur˝ ˝ o programok gyengéi. Ezek a tuzfalak ˝ megpróbálják követni a társított csomagokat (pl. a TCP kapcsolatok) és megszabadulnak az összes olyan csomagtól, melyek nem tartoznak egyetlen létez˝o kapcsolathoz sem. Míg könnyu ˝ olyan csomagot alkotni, ami átjut egy egyszeru ˝ szur˝ ˝ on, addig ezt jóval nehezebb megtenni az er˝osített szur˝ ˝ o használata esetén. Az SPF tuzfalak ˝ az adatmez˝o tartalmát is ellen˝orzik, azonban igen alacsony szinten. Az SPF tuzfalak ˝ felépítési hibái a csomag alapú adatkezelésnek tudhatók be. Alkalmazás szintu ˝ átjáró (proxy) tuzfal: ˝ olyan speciális programok összessége (alkalmazás szintu ˝ átjárók, proxyk), melyek egy adott protokollt felhasználva közvetítenek a kliensek és a szerverek közt. A proxy tuzfal ˝ nem kezel, még csak nem is továbbít csomagokat, a kapcsolatot inkább adatfolyamként értelmezi, a szerverrel pedig önálló kapcsolatot létesít. Elolvassa, majd értelmezi és ellen˝orzi a protokoll részeit és amennyiben a fogadó fél biztonsági beállításai engedélyezik a kérést, továbbítja az adatokat a szervernek. A legfontosabb különbség a proxy tuzfal ˝ és a csomagszurés ˝ között az, hogy a proxy esetében a két kapcsolat (a klienst˝ol a proxyig illetve a proxytól a szerverig) tökéletesen független egymástól, és részletesebben vizsgálható az adatfolyam tartalma. Moduláris alkalmazás szintu ˝ tuzfal: ˝ egy új technológia, mely kitágítja a proxy tuzfal ˝ fogalmát. Míg az egyszeru ˝ proxy tuzfal ˝ egy id˝oben csak egyetlen alkalmazott protokollt kezel, addig a modular gateway-ek képesek arra, hogy a szül˝o-protokoll mellett megvizsgálják az abban foglalt alprotokollt is. Ez annyit jelent, hogy ha rendelkezünk egy alap-protokollal, aminek van egy azonosítható alprotokollja (gondoljunk az SSL-be ágyazott HTTP protokollra), akkor proxyt kapcsolhatunk a beágyazott részhez. Ez oldja meg az adatforgalom vizsgálatánál a titoktartás érdekében feláldozott irányíthatóság problémáját. Vegyünk egy példát: több vállalati tuzfal ˝ nem engedélyezi a HTTPS használatát (a biztonságos hálózati hozzáférés érdekében) a titoktartás védelmében, ugyanis ezt a védelmet könnyu ˝ megkerülni, mert a HTTPS-ben kódolt anyag egyáltalán nem kerül ellen˝orzésre. Ennek ellenére az SSL teljes tiltása komoly hátrányokkal jár, például azzal, hogy elvesztjük az SSL protokoll által biztosított hálózati kódolást, ami pedig szükséges lenne a jelszó küld˝o protokollok használatához. Éppen ezért a Zorpot úgy fejlesztettük, hogy változtatható legyen a védelmi intenzitás szintje. A proxykat beágyazhatjuk egymásba, abban az esetben, ha az alap protokoll az adott protokoll vagy adat esetében engedélyezi ezt. Az SSL proxy lehet˝ové teszi, hogy HTTP proxyt csatolhassunk a zárt TCP kapcsolathoz, így egyszerre engedélyezhetjük a kifelé haladó HTTPS-t, és tarthatjuk ellen˝orzés alatt a kódolt tartalmat.
1.2. A TERMÉK ÁTTEKINTÉSE
3
1.2. A termék áttekintése Ebben a részben áttekintjük a Zorp Professional jellemz˝oit, a rendelkezésünkre álló protokoll kapukat és a CD tartalmának telepítését.
1.2.1. A Zorp jellemz˝ oi A Zorp egy több részb˝ol álló, az adott szituációra szabható, célorientált, moduláris proxy tuzfal ˝ készlet, mellyel lehet˝oségünk nyílik a proxy döntések finomított beállítására is beépített programnyelvével. A Zorp segítségével az összetett protokollokat is megvizsgálhatjuk (mint például az SSL-be ágyazott HTTP kapcsolat) és használhatjuk az outband authentikációs technikákat is. Meger˝osített OS: Különlegesen meger˝osített Debian GNU/Linux alapú disztribúció, csak a legszükségesebb szolgáltatásokkal telepítve, így elérhetjük a maximális biztonságosságot. Modularitás és proxy halmozás: a Zorp proxy-k bármilyen módon kapcsolhatók, ami azt jelenti, hogy amennyiben egy protokoll rendelkezik alprotokollal (pl. SSL-be ágyazott HTTP protokoll), úgy hozzákapcsolhatjuk a beágyazott protokollhoz a megfelel˝o proxyt is. Rugalmas policy: a Zorp által kínált magasabb szintu ˝ funkciókat beépített programnyelvének segítségével tovább finomíthatjuk. Megváltoztathatjuk alapértelmezett viselkedését, és személyre szabhatjuk a proxyk bizonyos protokoll elemekkel szembeni reakcióit. Célorientáció: Annak ellenére, hogy egy rendszer részekb˝ol való felépítése is OOP1 megközelítés, a valódi er˝o a nyelvben rejlik, aminek segítségével meghatározhatjuk a döntéseket. A szóban forgó nyelv a Python, ami egy világos, könnyen érthet˝o és jól hasznosítható, cél orientált nyelv. B˝ovíthet˝oség: a rendszergazda használhatja a Zorppal együtt kínált kategóriákat, de akár meghatározhat újakat is. Eseti döntéseken alapuló döntéshozás: bizonyos protokolloknál egy esemény eljuthat a policy rétegig, ahol megszületik a végs˝o döntés az adott szituációra. Ez a döntés iránymutató a proxykra nézve, mivel a proxyk ezentúl e döntés alapján fognak viselkedni az adott protokoll elemmel szemben. Transzparencia: A bels˝o felhasználóknak nem kell tudniuk róla, hogy minden kérésük átmegy a tuzfalon, ˝ ha azok nem ellenkeznek a tuzfal ˝ által betartatott helyi policyval. A transzparencia funkcióhoz nincs szükség semmilyen kliensprogramra vagy beállításra. Integrált csomagszurés ˝ vezérlés: csomagszurési ˝ szabályokat tetszésünk szerint adhatunk hozzá vagy módosíthatunk a beépített eszközök segítségével. 1
Object Oriented Programming – objektum orientált programozás
4
1. FEJEZET. BEVEZETÉS
Továbbfejlesztett naplóvezetés (logolás): a Zorp megkönnyíti a bennünket érdekl˝o üzenetek kiválasztását a naplóállományból, ami el˝osegíti a tárhelykapacitás hatékonyabb kihasználását. A naplóállomány utólagos feldolgozását a syslog-ng végzi, ami egy opcionálisan telepíthet˝o továbbfejlesztett syslogd beültetés. Native proxyk: DNS-sel és NTP-vel meger˝osített mail alkalmazások (SMTP). URL-szurés ˝ és megfigyelés: ennek segítségével megakadályozhatjuk a nem kívánatos weboldalak látogatását. Az ilyen oldalakról feketelistát készíthetünk, aminek alapján a Zorp automatikusan blokkolja a klienseknek ezekre az oldalakra irányuló kéréseit. Inband autentikáció: segítségével azonosíthatjuk a felhasználókat privát hálózatunkon, bármilyen küls˝o alkalmazás futtatása nélkül. Így egy HTTP kapcsolatban a felhasználónak autentikálnia kell magát el˝oször a tuzfal ˝ majd a HTTP szerver felé, míg el nem hagyja a HTTP protokollt. Outband authentikáció: felismerhetjük az olyan protokollokat is, melyeknek nincsenek ismertet˝ojegyeik, vagy ezek a jegyek túl gyengék ahhoz, hogy felismerhet˝ové tegyenek egy adott protokollt. Az outband autentikáció önálló azonosító csatornán muködik, ˝ mintha egy hitelesít˝o programot futtatnánk a kliens munkaállomáson (az outband autentikáció manapság egyetlen támogatott módja) vagy a VPN key-exchange által szolgáltatott információt használnánk. Satyrd támogatás: a Satyr egy alkalmi authentikációs program, amely az outband authentikáció egy formáját vette át. A Satyr futtatható Linux, Windows 95, 98, Me, NT 4.0, illetve 2000-es platformok alatt. XP? *** fixme BalaBit *** Központosított hitelesítés irányítás : az azonosítást és hitelesítést rögzít˝o anyagot központilag tárolja a ZAS (Zorp AuthServ program) adatbázis. A Zorp AuthServ program akár többször, párhuzamosan is futtatható a ZAS különböz˝o adatbázisaival együtt, így biztosíthatunk magunknak particionált hozzáférés ellen˝orzést. VPN: a VPN biztosítja a titoktartást és a hálózati forgalom integritásának védelmét privát hálózatunk és az egyéb, küls˝o honlapok, hálózatok között. Egy IPSEC barát VPN beültetést használunk e célra, mely 128 bit feletti kódolásának köszönhet˝oen kimagaslóan biztonságos. Magas szintu ˝ rendelkezésre állás, High Availablity (HA): Ezzel a modullal két egymástól független tuzfalat ˝ fürtbe köthetünk, ezzel megvalósítva a magas szintu ˝ rendelkezésre állás követelményét. Behatolás észlelése: - azzal, hogy rákapcsolódhatunk a protokoll kérések kezelésére, lehet˝oségünk nyílik egy listát készíteni a gyanús mintákról és a kés˝obbiek során ezek észlelése alapján lehet riadóztatni. Egyszeru ˝ telepítés: a Zorp Professional önálló, könnyen használható telepítési rendszerrel rendelkezik, ami telepíti az operációs rendszert, és saját magát is
5
1.3. ZORP BIZTONSÁGI ARCHITEKTÚRA Operating System syslog-ng
Application level
Z o r p
policy decision level protocol proxies
native proxies
HA module
packet filtering Kernel level IPSEC - VPN
1.1. ábra. A Zorp biztonsági felépítése Zorp User Interface: a ZUI segítségünkre van a tuzfal ˝ beállításánál, és megkönnyíti az egyszerubb ˝ beállítások végrehajtását. Lehet˝oségünk nyílik el˝ore elkészített beállítások használatára a leggyakoribb protokollok esetében. Terméktámogatás: támogatás kérhet˝o közvetlenül a BalaBit IT Kft.-t˝ol vagy megbízott partnerei egyikét˝ol. Minden eladott termék 30 napos, telefonon vagy e-mailen igénybe vehet˝o, ingyenes támogatást tartalmaz, garantált válaszadási határid˝ovel és a bug-ok ingyenes kijavításával. További, a terméktámogatással kapcsolatos lehet˝oségekr˝ol részletesen a http://www.balabit.hu/hu/partners/ weboldalon kapható felvilágosítás. *** fixme UHU és BalaBit *** - ez igaz a GPL-es esetekre is? Nem kell ezért regisztrálni? Bugfixek: Regisztrált felhasználóink ingyenes hozzáférést kapnak weboldalunkhoz, ahonnan letölthet˝ok a Zorp adott verziójához a bugfixek.
1.3. Zorp biztonsági architektúra A Zorp Professional szorosan együttmuködik ˝ a GNU/Linux operációs rendszerrel, ahogy ezt az 1.1. ábra bemutatja. Az operációs rendszer és a natív proxyk: A Zorp az UHU-Linux 1.0 egy meger˝osített verzióján fut, ami tartalmaz egy személyre szabott kernelt is, ez utóbbi több patch-csel is b˝ovítve van. A kernel patch-ek listája az A függelékben található. A mi UHU-Linux verziónk a Debian disztribúció egy alváltozata, ami csak a legszükségesebb programcsomagokat tartalmazza.
6
1. FEJEZET. BEVEZETÉS A hálózati szolgáltatásokat a Zorp és bizonyos protokollok (natív proxyk) választott alkalmazása biztosítja. Els˝o indításkor minden rendszerkomponens alapértelmezetten le van tiltva (ez a tuzfalaknál ˝ általános szabály) .
A csomagszur˝ ˝ o szerepe: A csomagszur˝ ˝ o érintkezik el˝oször a bejöv˝o adatforgalommal, így ennek a dolga, hogy kiválassza és továbbítsa az engedélyezett csomagokat a tuzfal ˝ alkalmazott szintu ˝ részei felé (a Zorp és a natív proxyk). Amellett, hogy a csomagszur˝ ˝ o nem engedi tovább a nem engedélyezett csomagokat, a tuzfal ˝ transzparenciáját is el˝osegíti azáltal, hogy a kapcsolatokat átirányítja a Zorphoz. Alkalmazás szintu ˝ átjárók: Az alkalmazás szintu ˝ átjárók a Zorp magba integrálódva natív programnyelven íródtak (C). Minden proxy együttmuködik ˝ a döntési algoritmussal, így minden oldalról megvizsgálják a protokoll parancsait (az RFC2 -kben meghatározott módon), az egyes protokollok részleteit pedig a rendszergazda dolgozhatja ki. A syslog-ng szerepe: A syslog-ng, mint azt a neve is mutatja, a syslogd új generációja, és mint ilyen, új szerepkört kapott. Míg az eredeti syslogd csak prioritás alapján szortírozta az üzeneteket, addig a syslog-ng lehet˝oséget ad az üzenetek tartalom alapján való szurésére ˝ a gyakori kifejezésekre építve. Ez az új modell rendkívül hatékony. A syslog-ng segítségével képesek vagyunk a naplóállomány továbbítására is TCP-n keresztül, úgy hogy az emlékszik a továbbítás egyes szakaszaira, ami ideálissá teszi alkalmazását tuzfallal ˝ védett környezet esetében. Mivel a tuzfal ˝ kritikus pontja hálózatunknak, ezért még fontosabbá válik a naplóállomány meg˝orzése és rendszeres frissítése. A natív proxyk szerepe: A natív proxykat ott használjuk, ahol egy proxy nem tudná betölteni a szerepét (pl.: ntpd, ahol fontos a sebesség). A különlegesen kialakított natív proxyk úgy muködnek, ˝ ahogy azt egy Zorp proxy modul is tenné. A HA modul szerepe: A HA3 modul a Zorppal egy szinten muködik. ˝ Ezzel a modullal két Zorp tuzfal ˝ „figyelheti” egymást, és abban az esetben, ha az egyik nem tudja ellátni a feladatát, a másik átveszi a helyét. Fontos megjegyezni, hogy ez a rendszer nem osztja meg a terhelést a gépek között, csak az egyikük végzi a tényleges feladatokat, a másik másodlagos (tartalék) szerverként muködik. ˝ Az IPSec szerepe a kernelben: Az IPSec biztonságot nyújt a Virtual Private Network4 használatához IP szinten, ezen kívül az IPSec-kel lehet˝oségünk van 2 Requests for comments – szószerint „hozzászólásra, megvitatásra készített anyag”, ténylegesen az Interneten folyó, különböz˝o operációs rendszeru ˝ gépek közötti kommunikáció közös szabványai 3 High Aviability – magas rendelkezésre állás 4 látszólagos magánhálózat
7
1.4. AZ ADATKEZELÉS ÁTTEKINTÉSE
Firewall Python proxies and policy
Listen
Packet filter
Proxy
Connect
Packet filter
1.2. ábra. A Zorp kezelésének áttekintése
tuzfalunk ˝ és hálózatunk elérésére egy idegen zónából. Az IPSec a Linux kernellel dolgozik.
1.4. Az adatkezelés áttekintése Ebben a részben körvonalazzuk egy kapcsolat útját a tuzfal ˝ szempontjából (1.2. ábra). Csomagszur˝ ˝ o: Mikor a tuzfalon ˝ keresztül egy kapcsolatot létesítünk, a csomagok, amelyek ezt a kapcsolatot használják, el˝oször a csomagszur˝ ˝ on haladnak át, amennyiben megfelelnek szabályainak. A csomagszur˝ ˝ o döntései a következ˝ok lehetnek: 1. megtagadhatja a csomagtól a belépést, ezzel a kapcsolatot is kizárva, 2. elfogadhatja a csomagot, ilyenkor továbbítja azt a nem transzparens szolgáltatásokhoz, 3. átirányíthatja a csomagot; ilyenkor a csomag további kezelése helyileg történik, még akkor is, ha a cím, ahova küldték, nem tartozik a tuz˝ falhoz. Az utóbbi esetben lehet˝oség nyílik a transzparens proxy használatra: a Zorp a választott porton figyeli a forgalmat, ahová minden kapcsolatlétesítési kérés át van irányítva, így a Zorp listener-je végzi a további adatkezelést. Zorp listener: A listener el˝oször eldönti, melyik proxyt indítsa, mikor hozzákerül egy TCP kapcsolat. A kiválasztott proxy azzal kezdi a munkáját, hogy
8
1. FEJEZET. BEVEZETÉS a listenert a kapcsolatát szolgáló kommunikációs csatornának használja, majd kapcsolatot létesít a célszerverrel. Az így létesített két kapcsolat révén az adatforgalom egyenesen a proxy modulhoz fut be, bármely másik adatkezel˝o egység közremuködése ˝ nélkül. Természetesen a szerverrel és a klienssel való kommunikációt megint csak szuri ˝ a csomagszur˝ ˝ o, mivel a hálózati forgalom csomagokra osztva folyik
Döntéshozási szintek: Az adatforgalommal kapcsolatos döntéshozás három szinten történik: I. a csomagszur˝ ˝ o szintje, ahol a csomagokat a fejlécük alapján szurjük, ˝ II. a proxy szint, ahol a használt protokoll hitelességét vizsgáljuk, összevetve a vonatkozó RFC-vel, III. a policy szint, ami a helyi biztonsági szabályokat tartalmazza. A csomagszur˝ ˝ o kizárólag a bejöv˝o csomag fejléce alapján hoz döntéseket. Ez az információ általában elég ahhoz, hogy megszurje ˝ a meghamisított (spoofolt) címr˝ol érkez˝o csomagokat, és hogy átirányítsa a különböz˝o szolgáltatásokra irányuló kéréseket (melyek különböz˝o portok felé tartanak) az adott protokoll specifikus proxykhoz. A csomagszur˝ ˝ o kiejt a forgalomból minden, explicite nem engedélyezett csomagot. A Zorp alkalmazói szintu ˝ átjáróinak általában nagyon szigorúak az alapbeállításaik, képesek a protokollok elemeinek kezelésére és vizsgálatára, de további beállítás hiányában mindent kiejtenek a forgalomból. Annak érdekében, hogy meghatározhassuk, mely protokoll elemek megengedettek, használhatunk normatív irányelveket és/vagy hook funkciókat. A normatív irányelvek protokoll specifikus segédelvekként muködnek ˝ a proxy esetében, hogy az megváltoztathassa alapértelmezett viselkedését. Az egyszerubb ˝ cselekvések végrehajtása, mint egy parancs engedélyezése, vagy mint kérések automatikus újraírása általában normatív direktívákkal lehetséges anélkül, hogy parancsot kéne írni a megfelel˝o funkció végrehajtására. Továbbá a segédelveket az alap proxy modul kezeli egy szerkesztett programnyelv segítségével, így az adatkezelés sokkal gyorsabb, mintha be kéne írnunk a megfelel˝o funkciókat a Pythonba. A policy szintnek két f˝o szerepe van: tartalmazza a tuzfal ˝ beállításait (policy.py) illetve itt tudjuk személyre szabni a proxykat normatív irányelvek hozzáadásával vagy egyéni Python funkciók megírásával. Proxy halmozás: A változtatható proxy tuzfal ˝ legnagyobb el˝onye, hogy proxykat halmozhatunk egymásra (kapcsolhatunk össze). Ezzel a módszerrel proxy hierarchiát hozhatunk létre a protokollok számára, amire eddig még nem volt lehet˝oségünk. Példaképpen az SSL/TLS protokoll titoktartást biztosít, és integritási védelmet nyújt az adatforgalmi rétegen, ezért gyakran beleágyazzuk az önmagukban nem biztonságos HTTP vagy POP3 protokollokat. Mint láthatjuk, az utóbbi id˝oben a beültetett protokollok kezdenek divatba jönni, így a proxyknak is követniük kell ezt az irányt, szükség van
1.5. FONTOSABB FOGALMAK
9
a protokoll halmozás mintájára felépül˝o proxy hierarchiára is. Pontosan ez az, amir˝ol a proxy halmozásnál szó van, itt ugyanis lehetséges minden proxyt egy szül˝o-proxyhoz csatolni, ahol a szül˝o-proxy ellen˝orzi a bennfoglaló protokollt, és amit nem tud értelmezni, azt továbbküldi az alproxyjához, további értelmezésre.
1.5. Fontosabb fogalmak Alkalmazás: a Zorp egy alkalmazása, annak hozzárendelt beállításaival. Lehet˝oségünk van egynél több, akár teljesen eltér˝oen beállított Zorp alkalmazás futtatására is egy tuzfalon. ˝ Minden alkalmazás megkülönböztethet˝o a neve alapján, ezek a nevek, illetve a hozzájuk rendelt beállítások a /etc/zorp/instances.conf-ban adhatók meg. Általában minden zónának megvan a saját Zorp alkalmazása, amely csak a szóban forgó zónába irányuló kéréseket szolgálja ki. Zóna: a host-ok egy olyan csoportja, melyek azonos biztonsági domain-hoz tartoznak. Azt, hogy egy host melyik zónába tartozik, az IP cím dönti el. Amennyiben ez a kritérium nem elégséges, akkor vagy szét kell bontanunk hálózatunkat több, fizikailag elkülönül˝o részre, vagy hatékony hitelesítést kell alkalmaznunk. Listener: a Zorp egy olyan része, ami fogadja a protokollkéréseket és elindítja a megfelel˝o szolgáltatást az elfogadott kérések esetében. Receiver: szintén a Zorp egyik része, ez fogadja a datagram alapú protokollok kapcsolatait és indítja a megfelel˝o szolgáltatást az elfogadott kapcsolatoknál. Service: a Zorp új része, segítségével megismerhetjük a nyílt hálózaton muköd˝ ˝ o host-ok szolgáltatásainak tulajdonságait. A Service információkkal rendelkezik a proxy modul indításáról, illetve bizonyos, a proxyval kapcsolatos paraméterekr˝ol. Mikor a listener elindítja a szolgáltatást, a szóban forgó proxy modul is elindul, és a kapcsolt paraméterek alkalmazásra kerülnek. Router: ez szabja meg a célcím címmeghatározásának módszerét. A rendelkezésünkre álló routerek: transzparens, irányított (directed) és inband. A TransparentRouter láthatatlanul kapcsolódik a célszerverhez, a DirectedRouter mindig az el˝ore meghatározott szerverhez kapcsolódik, végül az InbandRouter protokoll logikát követve jut el a célcím meghatározásához (ld. a nem transzparens HTTP és FTP). Proxy osztályok: képviselnek egy adott proxy modult annak hozzárendelt beállításaival. Mint korábban is említettük, a proxy modulnak lehet normatív és helyben beágyazott irányelve is, ezekkel együtt alkot a proxy modul egy proxy osztályt. El˝ore megállapított proxy beállítások: El˝ore megállapított proxy beállításokat mellékeltünk (E függelék), hogy egyszerubb ˝ legyen a Zorp Professional telepítése és konfigurálása. A ZUI felhasználói interfész el˝ore megállapított
10
1. FEJEZET. BEVEZETÉS beállítások sorát kínálja, melyek egy proxy osztályból állnak, tartalmazva a szükséges adatokat, a hozzárendelt port számokat, és egy leírást, hogy könnyebben kiválaszthassuk a megfelel˝o beállítást. Amennyiben az el˝ore megállapított beállítások egyike megfelel szükségleteinknek, akkor nincs is szükség további finomításra, de fontos megjegyezni, hogy lehet˝oségünk van az el˝ore meghatározott beállítások személyre szabására is
SNAT és DNAT: a hálózati címfordítás a Zorpnál egy kicsit mást jelent, mint azt a routereknél megszokhattuk. Mivel a Zorp proxy tuzfal, ˝ és mint ilyen, teljesen önálló kapcsolatot létesít a szerverrel, ezért a szerver úgy érzékeli, mintha a kapcsolat a tuzfalból ˝ indulna. Ez azonban nem megfelel˝o abban az esetben, ha például a kliens országokon alapuló statisztikát akarunk készíteni, mert a web szerver a DMZ-nkben mindig csak a tuzfal ˝ IP címét látná. Ebben az esetben a kimen˝o szerver fel˝oli forráscímet meg kellene változtatnunk, és ez az SNAT segéd feladata, egyszeruen ˝ újraírja a forráscímet, miel˝ott a kapcsolat elkezd˝odne. A DNAT ehhez hasonlóan muködik, ˝ megváltoztatja a célcímet a kapcsolat kezdete el˝ott. Outband és inband authentication: Egyes protokollok nem támogatják a hitelesítést a protokollon belül, vagy hitelesít˝o programjuk nem elég hatékony. Ahhoz, hogy hatékonyabbá tegyük autentikációnkat, telepítsük a Zorp Pro Authservert a tuzfalra ˝ vagy egy megfelel˝o autentikációs szerverre és a Satyrd-t a kliensre (ami technikailag egy daemon). Amikor 1. lépés: a kliens kapcsolatot létesít a szerverrel, 2. lépés: a tuzfal ˝ felszólítja, hogy autentikálja magát. A hitelesítés egy, az eredetit˝ol teljesen független, SSL-lel védett kapcsolaton történik jelszóval, CRYPTOCard vagy SKey használatával. 3. lépés: Amint a kliens válaszol, 4. – 5. lépés: a tuzfal ˝ az authserveren keresztül ellen˝orzi a kliens „személyazonosságát”. Amennyiben megbízható a kliens, 6. lépés: kommunikálhat a szerverrel. A hitelesítés során a kliens kizárólag a tuzfallal ˝ kommunikál. A folyamatot az 1.3. ábra szemlélteti.
1.6. A program alapértelmezett muködése ˝ Mivel egy hibabiztos programról van szó, ezért alapértelmezésben minden funkció le van tiltva, melyek nem kimondottan engedélyezettek.
˝ 1.6. A PROGRAM ALAPÉRTELMEZETT MUKÖDÉSE
outband authentication
Target server 6
4
firewall 5
Authserver
3
1 2 satyr daemon
Client
1.3. ábra. Outband autentikáció
11
12
1. FEJEZET. BEVEZETÉS
2. fejezet
Telepítés el˝ okészítése Ebben fejezetben azokról a teend˝okr˝ol lesz szó amelyeket a telepítés el˝ott érdemes megtennünk végiggondolnunk.
2.1. A tuzfal ˝ policyjának el˝ okészítése Ebben a részben a rendszer szintu ˝ információs biztonsági policy azon részére koncentrálunk, mely a tuzfalakkal ˝ foglalkozik. Feltételezzük, hogy a vállalat muködési ˝ szabályzata rendelkezik err˝ol. Az els˝o dolgunk, miel˝ott telepítenénk a tuzfalat, ˝ a mindenre kiterjedo, ˝ gondos tervezés.
2.1.1. Elméleti tervezés A tuzfal ˝ policy megfogalmazása a legösszetettebb és egyben a legérdekesebb feladat is a hálózati határvédelem tervezése során. Számos különböz˝o és egymásnak gyakran ellentmondó szempontot kell figyelembe vennünk és ezeket egyensúlyba hoznunk ahhoz, hogy egy jó policyt készítsünk, ami háttérül szolgálhat tuzfalunk ˝ személyre szabásakor. Nem hangsúlyozhatjuk eléggé a feladat fontosságát és nehézségét. Gondoskodjunk róla, hogy rendelkezésünkre álljon a kell˝o id˝o és er˝oforrás! Ha nem vagyunk biztosak abban, hogy saját tudásanyagunk elégséges az el˝ottünk álló feladathoz, keressünk inkább egy szakért˝ot, ahelyett, hogy olyan hibákat kövessünk el, amelyeket sokkal nehezebb lesz kés˝obb kijavítani. Policy alkotásakor minimum a következ˝o szempontokat kell figyelembe vennünk: – vállalati biztonsági policy; – IT biztonsági infrastruktúra és stratégia; – hálózati biztonsági policy;
13
˝ 2. FEJEZET. TELEPÍTÉS ELOKÉSZÍTÉSE
14
– hálózati biztonsági elvek és hasznos gyakorlati megoldások; – azon rendszer üzletben betöltött szerepe, melynek védelmét ki kell építenünk; – a rendszer technikai tulajdonságai; – a különböz˝o hálózati protokollok ismerete; – a szoftverek gyakoribb biztonsági hibáinak ismerete; – a rendszer különböz˝o részei által állított korlátozások: · LAN; · WAN; · fizikai és infrastrukturális megkötések; · a szofter részeinek muködése ˝ és kialakítása; – az emberi tényez˝o: · a felhasználók és a rendszer képességei és tudatossága; · a rendszergazda szervezési készsége, különös tekintettel a biztonsági kérdésekhez való hozzáállásra, a fejlesztésre, a rendszerintegrációra illetve a szabályozásra; – a rendelkezésre álló id˝o és er˝oforrások; A vállalati biztonságpolitika (policy) megfogalmazása a legfontosabb a biztonsági rendszer megszervezéséhez. A vállalati biztonságpolitika meghatározza a f˝obb veszélyforrások osztályainak fontossági sorrendjét (az integritás hiánya, a titkosság (bizalmasság), a rendelkezésre állás, a hitelesség, és a funkcionalitás elvesztése a leggyakrabban felmerül˝o veszélyforrások), a szervezeti struktúra azon alapvet˝o elemeit, melyek a biztonságért felel˝osek, továbbá az IT rendszerek biztonsági osztályait és végül a besorolás elveit. A vállalati stratégia szintén szabályozza az IT biztonsági stratégiával kapcsolatos kérdéseket, ilyen például az autentikáció vagy az engedélyezési szabályok, a tartalékegységekkel kapcsolatos intézkedések, a hozzáférés felügyeletének szabályai, és több más, szintén a biztonsággal kapcsolatos alkalmazás. Igen fontos, a vállalati biztonságpolitikához szorosan kapcsolódó fejezet, a vállalat biztonsági infrastruktúrája. A vállalati biztonsági policyt összefoglaló dokumentumnak tartalmaznia kell a végfelhasználóknak szánt információt, így azt is, hogy mire alkalmazhatják, és mire nem az IT rendszereket, mit kell tenniük, ha valami gyanús dolgot észlelnek, továbbá tudomásukra kell hozni, hogy megfigyelés alatt állnak, és felel˝ossé tehet˝ok rosszakaratú tevékenységükért. Jól jöhet, ha összeállítunk egy biztonsági kézikönyvet, amely a végfelhasználóknak röviden, de tisztán és érthet˝oen összefoglalja policynk legfontosabb pontjait. Ennek a dokumentációnak ismertetnie kell több kikötést is, melyeket figyelembe kell vennünk a rendszerfejlesztés során. Ezeket a kikötéseket be kell építenünk IT stratégiánkba és a vállalatfejlesztési módszertanba is.
˝ ˝ 2.1. A TUZFAL POLICYJÁNAK ELOKÉSZÍTÉSE
15
Az IT rendszerek folyamataival foglalkozó rész a legfontosabb a rendszergazdák számára, ezek a szervezeti policyból levezetett, a rendszer különböz˝o szintjeinek policy-jaiban vannak b˝ovebben kifejtve. Sajnálatos módon gyakran találkozunk olyan esettel, ahol egy szervezetnek nincs írásba foglalva a szervezeti politikája, az IT biztonsági stratégiája (néha még IT stratégiája sem), vagy a már létez˝o biztonsági infrastruktúrája. Ilyen esetben a legfontosabb elemeket be kell illeszteni a hálózati biztonságpolitikába, és a menedzsmentet rá kell ébreszteni a helyzet tarthatatlanságára. A legsúlyosabb probléma a vállalati biztonságpolitika hiányával nem a szabályozás nélkülözésében rejlik - annak ellenére, hogy a biztonsági policy-ra lehetne építeni a rendszerfejlesztés során (ez a probléma komolysága ellenére megoldható a gyakorlatban jól muköd˝ ˝ o megoldások ismeretével és a helyzet gondos áttekintésével) -, hanem a vele járó tudatlanságban és járatlanságban a biztonságtechnika területén. A tények azt mutatják, hogy az olyan vállatoknál, ahol nem fordítanak kell˝o figyelmet a biztonságtechnika fontosságának tudatosítására és ismertetésére, a vállalati kultúra gyakran negatívan viszonyul a biztonsági kérdésekhez. Ezt a helyzetet tovább súlyosbíthatja, ha hiányoznak a vezet˝oség által lefektetett elvek, melyekre támaszkodni lehetne egy esetleges véleménykülönbség esetén. A hálózati biztonságpolitika elveinek kidolgozása nélkülözhetetlen a tuzfal ˝ policy kialakításához. A hálózati biztonságpolitikát a vállalati biztonságpolitikából vezethetjük le. Abban az esetben, ha ez hiányzik, a hálózati biztonságpolitika kell, hogy irányadó legyen a legfontosabb kérdésekben. Amennyiben hálózati biztonságpolitika sincs, a tuzfal ˝ policy kialakításával párhuzamosan kell egyet kidolgoznunk. A policy megalkotásakor az a legfontosabb feladatunk, hogy a policy tartalmazza a vállalati IT rendszereken zajló információs forgalom kezelésének - a hálózati periféria biztonságának - és a hálózati biztonsághoz kapcsolódó folyamatoknak az alapszabályait. A policy-nak szabályoznia kell a LAN és WAN fejlesztésével és kezelésével kapcsolatban felmerül˝o biztonsági kérdéseket, a küls˝o hozzáférés lehet˝oségeit, és a tuzfallal ˝ kapcsolatos problémákat. Ügyeljünk rá, hogy a szövegnek tisztán és világosan tartalmaznia kell a hálózati biztonságtechnika legfontosabb elveit. Miel˝ott rátérnénk a fent említett elvekre, életbe vágóan fontos, hogy megértsük a többszintu ˝ osztott rendszerek biztonsági kérdéseinek alapjait. A többszintu ˝ rendszer egy olyan IT rendszer, melyben az adatokat osztályozás útján több szintre soroljuk be. A vállalatok IT rendszerei leggyakoribb ilyen jellegu ˝ rendszerek. Az osztályozás szintjeit, és szabályait a vállalati biztonságpolitikában találhatjuk meg, ezek együtt alkotják az információforgalom irányításának policy-ját. Az információ áramlás szabályainak betartatása a vállalati biztonsági infrastruktúra feladata. Az infrastruktúra alapvet˝o részei, a központi hitelesítéssel-, és authorizációval foglalkozó programok, a tuzfal, ˝ a naplóanalizáló központ stb. Vannak továbbá az infrastruktúrába már beépített biztonsági részek, ilyen például a "middleware" vagy a különböz˝o rendszerek üzleti logikája. Az említett komponensek megbízhatósági foka, illetve hasznosságuk mértéke nagyban különbözhet, és ezt a különbséget tovább növelheti az a tény, hogy az említett mellékkomponensek nem tudják kezelni a különböz˝o besorolási szinteket. Ezt a problémát oldja
16
˝ 2. FEJEZET. TELEPÍTÉS ELOKÉSZÍTÉSE
meg az Orange Book sorozat 1987. július 31-i 5. számában ismertetett módszer: Trusted Network Interpretation of the TNSEC (TNI) (Red Book - nscs-tg-005). A módszernek az a lényege, hogy a biztonsági végrehajtást négy részre bontja: ’M’: kötelez˝o (mandatory) hozzáférési vizsgálat, ’D’: diszkréciós (discretionary) hozzáférési vizsgálat, ’I’: azonosítás (identification) és hitelesítés (authentication) ’A’: audit. Kevert komponensekkel is találkozhatunk, mint ’DA’, ’IA’ vagy ’MDIA’. A módszer olyan osztott rendszer kiépítését mutatja be, mely többszintu ˝ adatokat, illetve különböz˝o típusú és megbízhatóságú biztonsági elemeket tartalmaz oly módon, hogy a rendszer mind biztonsági, mind megbízhatósági szempontból jól muködjön. ˝ Ezt úgy érhetjük el, hogy er˝os bázis-infrastruktúrát építünk ki, mely egyrészt magas megbízhatósági szinten tartalmazza mind a négy alapelemet, másrészt tartalmazza a kisebb fontosságú és megbízhatóságú alrendszereket is, utóbbiakat az ’M’ elem határolja el. Az ’M’ a gyakorlatban a tuzfal. ˝ További problémát jelent, hogy a tervez˝ok és rendszerszervez˝ok közül a legtöbben még csak nem is hallottak a biztonságos rendszerek kiépítésének alapelveir˝ol, vagy egyszeruen ˝ nem tör˝odnek velük. Éppen ezért ritkán találkozunk olyan esettel, hogy a funkcionalitás túlzott szem el˝ott tartása ne menne az adatforgalmi szabályok betartatásának kárára. A hálózati határvédelem alapelvei a következ˝ok: Minimalizálás: Az elv a tervez˝ok által jól ismert „a kevesebb több” elvét fedi. Az elv lényege, hogy a rendszer csak a legszükségesebb funkciókat tartalmazza, melyekre valóban szükségünk van. Minden funkciót és szolgáltatást, melyet nem használunk, állítsunk le. Ezzel a módszerrel kisebb felületet hagyunk potenciális támadónknak a szoftverek gyengeségeinek kihasználásra. Crystal box: Az ötlet Marcus J. Ranum (MJR), a hálózati biztonság egyik legnagyobb gurujának nevéhez köthet˝o, o˝ írta az els˝o tuzfal ˝ programot. MJR szerint egy készülék, ha jók a biztonsági beállításai, hatékony marad akkor is, ha a támadó a rendszer minden részletét ismeri. A lényeg az, hogy nem jelent megfelel˝o védelmet a titkolózás vagy az ismeretlenség, mivel a támadó (társadalmi úton1 , vagy találgatással) megtalálhatja gyenge pontjainkat, így az a feladatunk, hogy ne hagyjunk gyenge pontokat. Az információ elrejtésével nyert védelem akadályának leküzdése nem jelent akkora nehézséget a támadónak, mint gondolnánk, ráadásul a biztonság hamis érzetét nyújthatja. 1 Err˝ ol érdekes részleteket ismerhetünk meg Kevin D. Mitnick & William L. Simon: „The Art of Deception – Controlling the Human Element of Security” c. könyvéb˝ol (kiadó: John Wiley and Sons, magyar fordítás: „A legendás hacker - a megtévesztés muvészete” ˝ PerfactPro Kft, fordította Lénárt Szabolcs)
˝ ˝ 2.1. A TUZFAL POLICYJÁNAK ELOKÉSZÍTÉSE
17
Csak a legszükségesebb információ legyen hozzáférhet˝o: Minden felhasználó csak olyan információhoz illetve azokhoz a funkcióhoz férjen hozzá, ami szükséges a munkájához. Ez védelmet jelent az elégedetlen, félrevezetett vagy trójai faló programot használó alkalmazottakkal szemben. Feladatok szétválasztása: A fontos alkalmazások feladatait szét kell bontani különböz˝o mozzanatokra. Az eljárás el˝onye, hogy amennyiben sikeresen osztottuk fel a teend˝oket, úgy önmagában senki sem veszélyeztetheti a biztonságot, hiszen senki sincs tisztában a folyamat egészének muködésével. ˝ Belülr˝ol történ˝o ellen˝orzés, felfelé haladó adatforgalom: Ez a két elv a legfontosabb az információ forgalom és a tuzfal ˝ policy megtervezésekor. Egy hálózati protokollnak logikusan két csatornája van, az egyik a vezér csatorna, ahonnan a kapcsolat kezdeményez˝oje kiadja az utasításait, a másik az egy adatcsatorna, ahol az információ közlekedik. A „belülr˝ol történ˝o ellen˝orzés” (control from inside) elve alapján a kommunikációt a legfels˝o (védett, bels˝o) zónából érdemes kezdeményeznünk. Amennyiben ezt tesszük, a támadónak sokkal kevesebb ideje van, hogy kihasználja a kapcsolat gyengéit, így a támadás valószínusíthet˝ ˝ oen passzív lesz, szemben az aktív támadás lehet˝oségével, amikor a támadó a kapcsolat kezdeményez˝oje. A belülr˝ol történ˝o ellen˝orzés szabálya segít rendszerünk integritásának védelmében A „felfelé haladó adatforgalom” elve (flow up) a Bell-LaPadula modell legfontosabb része: amennyiben meg tudjuk oldani, hogy a két különböz˝o biztonsági szint között haladó információ mindig az alacsonyabb szintut˝ ˝ ol a magasabb szintu ˝ irányába haladjon, akkor biztonságban érezhetjük magunkat adattitkossági kérdésekben (feltéve, hogy az integritással minden rendben van). A gyakorlatban ezeket a szabályokat a legnehezebb alkalmazni. Az ellen˝orzés-elv két dolog miatt is problémás: legtöbbször nem úgy lett megtervezve a rendszerek felépítése, hogy több rendszer összeköttetése esetén is meg lehessen valósítani egy megfelel˝o ellen˝orzési policy-t. Nyomást kell gyakorolnunk a rendszertervez˝okre, hogy gondosabban mérlegeljék döntéseiket a különböz˝o rendszerek összekapcsolásának kérdésében. Problémánkat azzal lehetne kezelni, hogy leszukítik ˝ a kommunikációs csatornákon használt kód típusát, és egyszersmind védik is a kódot. A másik probléma abból adódik, hogy a kliensek legnagyobb része védelem nélküli hálózatokról csatlakozik, és a többszintu ˝ munkaállomásokat még nagyon ritkán alkalmazzák. Ezt a problémát egy hatékony, a klienseket elleno˝ rz˝o biztonsági programmal enyhíthetjük, oly módon, hogy egy autentikációs klienssel kib˝ovítjük a hálózati periféria biztonságát felügyel˝o programot, illetve a rendszereken csupán rejtett, minimálisra csökkentett kliens interfészeket hagyunk. Nagyon fontos, hogy amennyiben alkura kényszerülünk, alaposan mérlegeljük a megoldás nyújtotta el˝onyöket és hátrányokat egyaránt! Például magas fenyegetettség esetén (ilyen az internet) ne vállaljunk szükségtelen kockázatot azzal, hogy engedélyezzük az adatforgalmat rendszereinken. Több módszerrel is minimálisra csökkenthetjük a kockázatot az ilyen esetekben: technikai módon, demilitarizált zóna alkalmazásával, drop-boxokkal, terminál szerverekkel stb.
18
˝ 2. FEJEZET. TELEPÍTÉS ELOKÉSZÍTÉSE
Magas fokú ellen˝orzöttség: A manapság használatos tuzfalrendszerekkel ˝ az a legnagyobb gond, hogy nem tudjuk velük megfelel˝oen ellen˝orizni az áthaladó információ forgalmat. Pedig nagy szükség lenne a megfelel˝o ellen˝orzésre a jó biztonsági felépítés hiánya és a végrendszerek alkalmazása miatt. Az ideális tuzfal ˝ az integritás meg˝orzésének érdekében az input információt akár többször is ellen˝orzi, a bizalmas információ védelmében pedig minimalizálja a titkosított csatornák számát. A Zorp brillírozik ezen a területen. Míg a csomagszur˝ ˝ ok csak a 3-as OSI rétegen tudnak dolgozni, és a legtöbb, a felhasználói rétegen muköd˝ ˝ o tuzfal ˝ csupán minimális ellen˝orzést biztosít a 4-es réteg feletti szinteken, a Zorp a protokollok minden részletét kezeli. S˝ot, a Zorp teljes eszköztárral bír rugalmas döntéshozási rétegének köszönhet˝oen, amivel a rendszert˝ol függ˝oen az OSI minden szintjén intézkedéseket vezethetünk be. Többszintu ˝ védekezés: A jó védelmi rendszerek a biztonsági intézkedések több szintjét alkalmazzák. Erre azért van szükség, hogy a támadónak több ellen˝orzésen kelljen átjutnia ahhoz, hogy elérje célját, egyetlen ellen˝orzés helyett. A tipikus hálózati periféria több zónából áll, ahol minden zóna különböz˝o biztonsági szintu ˝ rendszereket tartalmaz, és itt a rendszerek több ellen˝orzést hajtanak végre. Például egy alkalmazott otthonról (ami „public” szintu ˝ hozzáférésnek számít, mivel kívül esik a vállalat menedzsment domainján) egy fontosabb rendszert csak több ellen˝orzésen átesve (er˝osen kódolt, vagy challange-response típusú hitelesít˝o rendszer és többszöri protokoll ellen˝orzés) és két tuzfalon ˝ keresztül érhet el (az egyik a küls˝o hozzáférési pontnál található, a másik a fontos rendszert védi). A tuzfal ˝ policy a rendszer aktuális beállításaiból és a hálózati biztonsági policyból vonható le. Elvileg, ideális esetben a rendszert a hálózati biztonság figyelembe vételével és információforgalmi korlátozásokkal fejlesztették. A gyakorlatban tuzfallal ˝ tesszük biztonságosabbá a rendszert, mivel a rendszer távol van attól, amit biztonságosnak nevezhetnénk. A policy kialakításakor az els˝o dolgunk, hogy információt gyujtsünk ˝ a megvédend˝o rendszerr˝ol. Ez gyakran nehéz és fárasztó munkával jár, nemcsak azért, mert több helyr˝ol kell összegyujtenünk ˝ a kell˝o információt, hanem azért is, mert a rendszerfejleszt˝ok és rendszergazdák nem tudnak eleget rendszerük muködésér˝ ˝ ol. Ha összegyujtöttük ˝ a szükséges információt, meg kell terveznünk a rendszer biztonsági felépítését. Els˝o feladatunk a kés˝obb használatos zónák meghatározása, majd a zónákon belül az alrendszereké, végül az alrendszerek abszolút és relatív besorolási szintjeinek kialakítása. Amennyiben sikerült dönteni a rendszer integritását illet˝oen, elkezdhetjük kiválogatni az ezzel kapcsolatos kérdéseket. Ehhez a feladathoz szükség van a LAN és WAN szolgáltatásokért felel˝os emberekkel való szoros együttmuködésre. ˝ Miután kész a hálózati infrastruktúra terve, a tuzfalon ˝ áthaladó információforgalom kérdésével kell foglalkoznunk. Ebben a fázisban szükség van némi rendszerfejlesztési és -integrációs munkára, mint a legproblémásabb információs csatornák átalakítása, az outband autentikáció kiépítése, stb. Az információgyujtési ˝ szakasznál abban állt a nehézség, hogy meg kellett találnunk azokat
˝ ˝ 2.1. A TUZFAL POLICYJÁNAK ELOKÉSZÍTÉSE
19
az embereket, akik rendelkeznek a szükséges információval, és azt ki is kellett bel˝olük szedni (ennek legtöbbször az a vége, hogy felcsatlakoztatjuk a laptopot, és megnézzük magunknak). Ebben a fázisban gy˝ozködnünk kell környezetünket, hogy megkapjuk a további fejlesztési és integrációs munkához szükséges er˝oforrásokat a vállalatvezetést˝ol. Az említett két tevékenység az, ami a nagy tárgyi tudást és intenzív munkát kívánó tuzfalrendszer ˝ szervez˝o tevékenységét muvészetté ˝ avatja. Amennyiben sikerült megállapodni a szükséges konfiguráción, azt fel kell venni a firewall policy-ba. Nem árt, ha a policy-ba belevesszük a kapcsolódó hálózatok és rendszerek konfigurációjának legfontosabb pontjait is, és összeállítunk egy listát a kapcsolódó elemekr˝ol, ez megkönnyíti az esetleges hibák megtalálását és kijavítását. A kívánt tevékenységeket érdemes el˝ore megtervezni. Ebbe tartoznak a tervezett rendszerleállítások, hogy a végrendszereket a megállapított konfigurációnak megfelel˝oen állíthassuk be és a szoftvereket frissíthessük. Nagyon pontosan kell terveznünk, megfelel˝o id˝ot hagyva minden feladatra. Nagyon fontos az is, hogy végiggonduljuk, mire lehet szükségünk a munka során, mert pl. egy kifelejtett kereszt UTP kábel beszerzése hajnali háromkor nehézségekbe ütközhet. . . Ha kész vagyunk az ütemtervvel és a policy-val is, elkezdhetünk dolgozni vadonatúj Zorpunk konfigurációján.
2.1.2. Tervezés és dokumentálás a gyakorlatban Ebben a részben néhány technikai tanácsot gyujtöttünk ˝ össze, ami jól jöhet az IT biztonság policy készítésénél. Ebben a szakaszban kizárólag a hálózati biztonságtechnikával foglalkozunk. El˝oször készítenünk kell egy ésszeru ˝ felépítési tervet. Próbáljuk a biztonsági veszélyeknek megfelel˝oen megosztani a hálózatot, zónáinkat pedig fizikailag független interfészekre kapcsolni, hogy a csomagokat csak a tuzfal ˝ felügyelete alatt lehessen továbbítani. Soroljuk szervereinket és klienseinket zónákba. A biztonságpolitika készítésénél ki kell jelölnünk az engedélyezett protokollokat, és a protokollok zónákra vonatkozó parancsait. Például engedélyezhetjük az SQLNet forgalmat a DMZ-b˝ol az Intranetre, míg az Intranetb˝ol a DMZ-be tilthatjuk ugyanazt. Természetesen csak a tuzfalon ˝ áthaladó forgalmat irányíthatjuk. Érdemes külön IP címtartományt megadni minden zónának, így majd egyszerubben ˝ meg tudjuk o˝ ket különböztetni. Próbáljuk megoldani, hogy csak azok a protokollok muködjenek, ˝ melyek nélkülözhetetlenek a munka során. Ez persze konfliktusforrás lehet a felhasználók és tuzfal ˝ adminisztrátor között, de a vállalati biztonság policy úgyis gondoskodik az ilyen jellegu ˝ problémák megoldásáról. Minimalizáljuk az UDP-n, és az UDP és TCP Plugokon keresztülmen˝o forgalmat. Habár ezek a proxyk biztonságosabbak, mint az egyszeru ˝ csomagszur˝ ˝ ok, de nem képesek úgy ellen˝orizni a protokollokat, ahogy egy igazi proxy modul. A dokumentálás létfontosságú! Igyekezzünk a policyval kapcsolatos dokumentációnkat napra készen tartani!
20
˝ 2. FEJEZET. TELEPÍTÉS ELOKÉSZÍTÉSE
Egy protokoll engedélyezésének eldöntésekor gondoljuk végig a vele járó kockázatot! Minimalizáljuk az UDP forgalmat, amennyire lehetséges, alacsony biztonsági szintje miatt. Sose felejtsük el dokumentálni policynkat. A B függelékben található egy példa a policy mátrixra. A mátrix sorai és oszlopai szimbolizálják a zónákat, és a köztük megengedett protokollokat. A sor szimbolizálja az egy adott zónából jöv˝o forgalmat, az oszlop pedig a célzónát jelenti. Példaként mi ezeket a zónákat különítettük el Intranet: Az intranet (bels˝o hálózat) klienseit tartalmazó zóna, privát címtartománya: (10.0.0.0/24). Menedzsment Zóna (MGMT): A bels˝ohálózat kiemelt csoportja a rendszergazdák, akiknek a karbantartási feladatok miatt több jogosultságra van szükségük. A kés˝obbi példában ez abban nyilvánul meg, hogy o˝ k a tuzfalon ˝ át igénybe vehetik az SSH szolgáltatást. A zónának privát címtartománya van (10.0.0.244/28), és logikai alzónája az intranetnek. Demilitarizált Zóna (DMZ): A publikus, internetr˝ol elérhet˝o szolgáltatásokat nyújtó szerverek zónája. (fizikailag is külön ethernet interfészen.) A példa szerint hozzáférhet˝o szolgáltatások: http, https és anonim, csak letöltésre szolgáló ftp. Annak ellenére, hogy ezek a gépek bárkinek elérhet˝o szolgáltatásokat nyújtanak, a zónának privát címtartománya van (192.168.0.0/24). Tuzfal: ˝ Ez a zóna jelenti azokat a szolgáltatásokat, amelyek magán a tuzfalon ˝ elérhet˝ok. IP címek csak az adott interfészekhez tartoznak. Internet: Ez a zóna magában foglal minden IP-t amelyet eddig nem deifiniáltunk. Az Internet zóna az, amelyet a legmegbízhatatlanabbnak tekintünk. (0.0.0.0/0).
2.2. Rendszerkövetelmények Ebben a részben a Zorp futtatásához szükséges hardver és szoftver követelményeket tárgyaljuk.
2.2.1. Hardver követelmények Minimális hardver követelmény: A ZorpGPL UHU hardver platform igénye megegyezik az UHULinux-éval. A minimális követelmény legalább 233Mhz Pentium szintu ˝ processzor, és 64Mb memória. Az operációs rendszer telepítéséhez és a virtuális memóriához 300 400 MB szabad helyre van szükség a merevlemezen. A tuzfalon ˝ keresztül lebonyolított forgalom mértékének megfelel˝oen kell még hely a várakoztatott leveleknek és a rendszernapló fájloknak. Fokozott teljesítmény elérésére használjunk gyors SCSI merevlemezeket, lehet˝oleg külön lemezt használva a rendszer illetve a különböz˝o adatok tárolásához.
2.2. RENDSZERKÖVETELMÉNYEK
21
A hardver méretezése nehéz feladat. Egy muköd˝ ˝ o rendszer hardver követelménye sok mindenen múlik, és szinte lehetetlen minden tényez˝ot számításba venni. A megoldáshoz határozzuk meg a forgalom lebonyolításához szükséges három legnagyobb hardver igényu ˝ tényez˝ot, melyek: – a párhuzamos kapcsolatok száma, – kiszolgált sávszélesség (WAN oldalon), – a naplózás elvárt részletessége. A párhuzamos kapcsolatok száma közvetlenül meghatározza a felhasznált memória mennyiségét. Az operációs rendszer memóriakövetelménye mellett a Zorp minden kapcsolathoz memóriát használ fel. 64MB memória elég az OS mu˝ ködéséhez, és mellette a Zorp kb. 20 párhuzamos kapcsolatot tud fenntartani. Minden további kapcsolathoz körülbelül 200kB memóriára van szükség (kernel socket bufferek, thread specifikus adatok, dinamikus változók a Zorpban, állapotjelentések a proxykról). Egy 500 kapcsolatot kezel˝o tuzfal ˝ esetében a Zorp és az operációs rendszer memóriaigénye kb. 500*200kB = 100MB RAM, a már korábban említett 64MB mellett. Ennek megfelel˝oen 192 vagy 256MB memória elég kell, hogy legyen. Így a kérdés leszukült ˝ arra, hogy adott számú kliens hány kapcsolatot generál. Általában a tuzfalakon ˝ a HTTP forgalomból adódik a legnagyobb terhelés, mivel manapság ez a legnépszerubb ˝ internetes szolgáltatás a World Wide Web protokollja. A világhálón található tartalom minden darabja külön HTTP kapcsolaton keresztül jut el hozzánk, és ezekb˝ol egy egyszeru ˝ weboldalon is több van, gondoljunk arra, hogy minden kép ilyen darabnak számít. Egy böngész˝o kb. négy kapcsolatot indít egyszerre, hogy letöltsön egy oldalt és annak grafikai elemeit. 100-120 az interneten böngész˝o klienssel számolva, a tuzfalnak ˝ 400480 kapcsolatot kellene maximum kezelnie párhuzamosan. Így egy 100-120 alkalmazottat foglalkoztató vállalat esetében elég lenne a már kiszámított 192MB RAM. A kiszolgálandó sávszélesség a következ˝o szempont, amely leginkább a CPU méretezésre van hatással, viszont igen nehezen becsülhet˝o. Egy 133Mhz-es Pentium szintu ˝ komputerrel egy párhuzamos kapcsolat esetén 10Mbit/sec-os WAN kapcsolat kiszolgálható. A Zorp alapértelmezett napló beállításai körülbelül 3-400 byte-nyi log üzenetet generálnak egy kapcsolat során. Ez egy naponta 100000 kapcsolatot kezel˝o tuzfal ˝ esetében napi 30-40MB naplóállományt jelent. Amennyiben emeljük a jelentések részletességének (verbosity) szintjét, a fájlok mérete n˝oni fog, 10-es verbosity szinten ez már 10-15kB-os üzeneteket jelent. Úgy kell finomítanunk a logoló alrendszerek beállításait, hogy kiválasszák azokat az üzeneteket, melyek valóban érdekelnek, ezzel csökkentve a processzor- és tárkapacitás igényt. A tuzfalhoz ˝ érdemes megbízható/márkás hardvert használni duálredundáns tápegységgel és/vagy szünetmentes áramellátást biztosító UPS-sel. Hardver kompatibilitás: A ZorpGPL UHU UHULinuxon fut, ezért bármilyen hardver, amit az UHULinux támogat, a Zorpnak is megfelel.
˝ 2. FEJEZET. TELEPÍTÉS ELOKÉSZÍTÉSE
22
2.2.2. Szoftver követelmények A ZorpGPL UHU az UHULinux tuzfal ˝ operációs rendszerrel muködik ˝ a legjobban együtt. E mellett a BalaBit honlapjáról (http://www.balabit.hu) letölthet˝ok a Debian operációs rendszerhez tartozó csomagok, és a forráskódok is, melyek más Linux/Unix-okra is lefordíthatók.
2.3. A hálózati tartomány el˝ okészítése a Zorp telepítésére Ebben a részben arról lesz szó, hogyan készíthetjük fel hálózatunkat a tuz˝ fallal való együttmuködésre. ˝
2.3.1. A tuzfal ˝ helye a hálózati architektúrában Ha tuzfalat ˝ akarunk telepíteni, valószínuleg ˝ meg kell változtatnunk a hálózatunk felépítését, mivel a befelé jöv˝o és a kifelé men˝o hálózati forgalomnak is át kell haladnia a tuzfalon. ˝ Át kell állítanunk a klienseket, hogy a tuzfal ˝ bels˝o címét használják alapértelmezett átjárónak az internet irányába. A 2.1. sz. ábrán láthatunk egy példát a felépítésre, kiosztott példa IP címekkel. A további fejezetek az ábra alapján magyarázzák a tuzfal ˝ kiépítését. IP: 1.2.3.254 Netmask: 255.255.255.0 Broadcast: 1.2.3.255 Gateway: 1.2.3.254 Network: 1.2.3.0
IP: 10.0.0.254 Netmask: 255.0.0.0 Broadcast: 10.0.0.255 Gateway: 10.0.0.254 Network: 10.0.0.0 Interface: eth1
OUTSIDE (ethernet)
PPP/SLIP etc.
INTRANET (ethernet)
Intranet Network: IP: 10.0.0.1/24 Netmask: 255.0.0.0 Broadcast: 10.0.0.255 Gateway: 10.0.0.254 Network: 10.0.0.0
IP: 1.2.3.5 Netmask: 255.255.255.0 Broadcast: 1.2.3.255 Gateway: 1.2.3.254 Network: 1.2.3.0 Interface: eth2 Default gateway: 1.2.3.254
IP: 192.168.0.254 Netmask: 255.255.255.0 Broadcast: 192.168.0.255 Gateway: 192.168.0.254 Network: 192.168.0.0 Interface: eth0
Demilitarizet Zone (DMZ) (ethernet)
DMZ Network: IP: 192.168.0.1/24 Netmask: 255.255.255.0 Broadcast: 192.168.0.255 Gateway: 192.168.0.254 Network: 192.168.0.0
2.1. ábra. Példa a hálózati topológiára
INTERNET
˝ 2.3. A HÁLÓZATI TARTOMÁNY ELOKÉSZÍTÉSE A ZORP TELEPÍTÉSÉRE23
2.3.2. A hálózati eszközök A router (útvonalválasztó) egy speciális hardver, amit hálózatok összekapcsolására használunk az ISO/OSI hálózati rétegén. A router segítségével összeköthetünk különböz˝o típusú hálózatokat, mint az ethernet, a token ring, a token bus, az ATM, az FDDI, a pont-pont kapcsolatok, és így tovább. A tuzfal ˝ egy segédeszköz, ami egy szervert vagy hálózati szegmenset (zónát) véd a lehetséges támadásoktól, és ellen˝orzi az interfészein keresztülfutó adatforgalmat. A szerver szolgáltatásokat nyújt a helyi hálózaton lév˝o kliensek számára. Az említett szolgáltatások az egyszeru ˝ fájl- és nyomtató megosztástól az összetettebb alkalmazásokig bármit jelenthetnek. Hub és switch A hub a telefonos parti-vonalak vagy konferencia beszélgetések mintájára muködik. ˝ Egyszerre csak egy komputer küldhet adatot, és az üzenet a hálózat összes többi gépéhez eljut, így a hálózati forgalom lehallgatható, „sniffelhet˝o”. A hubbal szemben a switch csak azon a porton küld ki csomagot, amelyen keresztül a címzett komputer közvetlenül elérhet˝o. Ez megnehezíti ugyan, de nem teszi lehetetlenné a lehallgatást.
2.3.3. IP címváltás Amennyiben hálózatunk publikus, routolható IP címeket használ, jobb, ha áttérünk privát IP címek használatára. Mindenek el˝ott válasszunk egy privát IP címtartományt a bels˝o hálózatunknak, (pl.: 10.0.0.0/8, mert ez könnyen megjegyezhet˝o és elég nagy címtartomány), és a választott tartományból jelöljünk ki címeket kliensgépeink számára. Lehet˝oségünk van dinamikus és fix IP címek használatára. A privát címtartományok kijelölését az RFC1918 szabvány tartalmazza. Abban az esetben, ha már korábban is privát IP címeket használtunk, és router végezte a címfordítást2 , a továbbiakban NAT), sokkal kevesebbet kell módosítanunk a konfiguráción. Router használatakor a NAT-olás annyit jelent, hogy a kimen˝o csomagnak megváltozik a forráscíme, a visszaérkez˝o válaszcsomagnak pedig automatikusan az eredeti forráscímre módosul a célcíme. Gyakran használjuk a NAT-ot a cég border routerén a bels˝o címtartomány kifelé történ˝o maszkolására. Ha telepítettük a Zorpot, a tuzfal ˝ rögtön átveszi a router szerepét. A Zorp proxy tuzfalként ˝ külön kapcsolatot kezdeményez a szerverrel, automatikusan a küls˝o interfész IP címét használva. A gyakorlatban - bár nincs semmiféle technikai akadálya - nem ajánljuk publikus IP cím használatát a bels˝ o hálózaton. Az intranetes kliensek számára az alapértelmezett átjáró legyen a tuzfal, ˝ a tuzfalnak ˝ pedig a border router bels˝o lába. Így az információáramlás egyetlen lehetséges útja a tuzfalon ˝ keresztül vezet. 2
Network Address Translation (NAT) – hálózati címfordítás
24
˝ 2. FEJEZET. TELEPÍTÉS ELOKÉSZÍTÉSE
2.3.4. DNS szerver A Domain Name System3 (továbbiakban DNS) felel˝os a host nevek (pl.: www.balabit.hu) IP címmé való átalakításáért. Biztonsági okokból más nevet érdemes használni az intraneten (ami nem is látható az interneten), mint az interneten (ami viszont látható az intreneten is). Például egy gép privát neve: gep.belso.domain, míg ugyanez a gép az intranetr˝ol gep.cegnev.hu néven jelenik meg. Ahhoz, hogy ezt megtehessük, szükségünk van egy az intranet zóna beállításait tartalmazó DNS szerverre, amely minden nem az intranetre vonatkozó kérést továbbít a tuzfalhoz. ˝ A következ˝o néhány bekezdésben ismertetjük a DNS felhasználás leggyakoribb területeit és azt, hogy a tuzfal ˝ telepítése után miként kell (érdemes) ezeket megváltoztatni. Harmadik fél által biztosított DNS szolgáltatás Ha a DNS szolgáltatást az internet szolgáltatónk biztosítja, és az összes domainünket az o˝ DNS szervere hosztolja, akkor csak egy caching-only DNS szerverre van szükség a tuzfalon, ˝ amely a bels˝o DNS szerver kéréseit a nagyvilág felé továbbítja. Ez a bels˝o szerver lesz a master a bels˝ohálózaton míg a tuzfalon ˝ lév˝o pedig slave-ként fog muködni. ˝ A védett zónákban lév˝o kliensek a tuzfalat ˝ használják név szerverként, azonban a küls˝o DNS lekéréseket nem fogadjuk (akár úgy, hogy kijelölünk kimondottan csak listen-on címeket, vagy a csomagszur˝ ˝ ot használjuk az ilyen csomagok tiltására). Saját DNS szolgáltatás Ha saját DNS szolgáltatást kell üzemeltetnünk, két megosztott DNS konfigurációjú név szervert kell a tuzfalon ˝ futtatnunk. Ez azt jelenti, hogy a DNS szerverek egyike a bels˝o interfészekkel foglalkozik, a másik pedig a küls˝o interfészre kapcsolódik. A védett zónákat szolgáló DNS szerver forwarder-nek használja a másikat, így aki lekér valamit a bels˝o szerverr˝ol, annak internetes és intranetes nevek is megjelennek, a küls˝o lekéréseknél viszont nem jelenik meg intranetes zónáinkra vonatkozó információ.
2.3.5. E-mail szolgáltatás Biztonsági szempontból érzékeny információnak számítanak az e-mail üzenetek, ezért érdemes védett zónában tartani o˝ ket. Két protokoll kezeli mailünket: az SMTP-t (Simple Mail Transfer Protocol) levélküldésre, a POP3-t (Post Office Protocol 3) levelek letöltésére használjuk. A továbbiakban a mail szolgáltatás általános beállításit ismertetjük, és a tuz˝ fal telepítése után a szükséges módosításukat. Mail szerver az intraneten Ha saját mail szerverrel rendelkezünk, azt érdemes a tuzfal ˝ mögé helyezni, a védett zónák egyikébe, az intranet jó megoldás 3 DNS – névkiszolgáló rendszer; ugyanezt a rövidítést használják a névkiszolgáló szerverekre is (S: server)
˝ 2.3. A HÁLÓZATI TARTOMÁNY ELOKÉSZÍTÉSE A ZORP TELEPÍTÉSÉRE25 erre. Úgy állítsuk be a mail szervert, hogy használjon smarthostot, amit irányítsunk a tuzfal ˝ bels˝o lábára. Most már tudunk üzenetet küldeni. A bejöv˝o levélforgalom kezeléséhez szükségünk van egy MX record bejegyzésre amelynek a tuzfal ˝ küls˝o lábára kell mutatnia. A tuzfal ˝ saját segédprogramot használ levelezés lebonyolítására, ezért be kell állítanunk, hogy a bejöv˝o üzeneteket az intranetes mail szervernek továbbítsa. Harmadik fél által nyújtott mail szolgáltatás Amennyiben a mail szolgáltatást ISP-nk biztosítja, érdemes megfontolni biztonsági okokból egy saját mail szerver telepítését. Ha ez nem lehetséges, letölthetjük az üzeneteket POP3mal vagy IMAP-pal, de mivel ezek a protokollok nem elég biztonságosak, ezért érdemes egy VPN hálózatot létesíteni rendszerünk és a szolgáltató között, vagy SSL/TLS-be ágyazhatjuk a POP3 vagy IMAP protokollokat. A TLS-be ágyazáshoz vagy be kell állítanunk az összes mail klienst, hogy ezt tegye, vagy használhatjuk a Zorp PSSL proxyját.
2.3.6. Web hozzáférés A World Wide Web (www) az internet legkedveltebb szolgáltatása, így szinte elkerülhetetlen, hogy engedélyezzük a HTTP forgalmat. A HTTP-t rendkívül rugalmasra tervezték, ami sajnos magában hordozza a visszaélések lehet˝oségét is. Ennek ellenére a HTTP nagyon hasznos, és biztonságossá tehet˝o a megfelel˝o korlátozásokkal. Web-cache szerver nélküli intranet A Zorp a HTTP kérések átvitelére transzparens (amikor a kliensek kérésükkel a célszervert címezik meg) és nemtranszparens (klienseink kérésükkel a tuzfalat ˝ címezik meg, és arra kérik, hogy az o˝ nevükben kapcsolódjon a címszerverre) módon képes. Az el˝obbi esetben nincs szükség a kliens oldali beállítások változtatására, a második esetben azonban módosítani kell minden kliens konfigurációját (proxy beállítások). A Zorp önmagában nem végez forgalom cache-elést, csupán biztonsági szempontból felülvizsgálja a kéréseket. Intranet web-cache proxyval A cache-el˝o HTTP proxy bizalmas információt tartalmazhat logfájljaiban, az ezekben tárolt információ segítségével könnyen feltérképezhet˝ok az egyes felhasználók szokásai (például a leggyakrabban látogatott site-ok listája alapján). Éppen ezért a web-cache-nek egy védett zónában kell elhelyezkednie. Abban az esetben, ha web-cache szerverünk a privát hálózaton belül található, a kliens munkaállomásokat úgy érdemes beállítani, hogy azt használják HTTP proxyként. A Zorp-ot pedig úgy, hogy kizárólag a bels˝o proxy vehesse igénybe a HTTP szolgáltatást. Amennyiben web-cache szerverünk a privát hálózaton kívül található, klienseinket a következ˝o módokon lehet beállítani: 1. Használják a Zorpot proxy-ként (nem-transzparens üzemmódban)
˝ 2. FEJEZET. TELEPÍTÉS ELOKÉSZÍTÉSE
26
2. Használják a küls˝o web-cache-t proxy-ként, a Zorpot pedig transzparens üzemmódban a proxy kérések továbbítására 3. Használják klienseiket anélkül, hogy módosítanánk a beállításokon (proxi beállítás nélkül), a Zorpot pedig transzparens üzemmódban, úgy konfigurálva, hogy a kliensek kéréseit proxy kérésekké átalakítva továbbítsa a cache-nek.
2.3.7. SOCKS A SOCKS egy olyan hálózati proxy protokoll, melynek segítségével a SOCKS szerver egyik oldaláról direkt IP hozzáférés nélkül elérhetjük a szerver másik oldalán található összes hostot. Mivel nincs közvetlen routolás a megbízható és a nem megbízható hálózat között, ez a megoldás némileg biztonságosabb az egyszeru ˝ csomagszurésnél. ˝ A SOCKS alkalmazás szintu ˝ protokoll szurést ˝ nem végez. A Zorp interfészként nem, csak transzparens üzemmódban támogatja a SOCKS-ot.
3. fejezet
Telepítés Ez a rész lépésr˝ol lépésre bemutatja, hogyan lehet installálni a Zorp-ot az installációs CD-r˝ol.
3.1. A Zorp disztribúciós CD-ROM Az installációs média egy boot-olható CD-ROM, ami a Zorpot, a Zorphoz tartozó modulokat és egy GNU/Linux alapú operációs rendszert tartalmaz. F IGYELEM ! A Zorp dedikált számítógépet igényel, ezért az installációs eljárás a merevlemez teljes tartalmát felülírja!
3.2. Indítás és az els˝ o lépések Mivel a Zorp saját operációs rendszerrel rendelkezik, installálása tiszta rendszert igényel, így a disztribúciós CD-ROM-ról kell a számítógépet indítani. Ennek érdekében a CMOS beállításokban az els˝odleges indító eszköznek a CD-ROM-ot kell beállítani, majd úgy kell a gépet indítani, hogy a telepít˝o CD a CD meghajtóban legyen. A tuzfal ˝ telepít˝o CD-nek még forgalomban van olyan változata, amelynek karakteres installáló felülete van. Azok számára, akik ilyen változatról telepítenek a G. függelékben ismertetjük a követend˝o eljárást. Ahogy az operációs rendszer betölt˝odik, megjelenik az üdvözl˝o képerny˝o, ami csak színeiben és némi feliratban különbözik az UHU-Linux általános telepít˝ojét˝ol (3.1. sz. ábra)
27
28
3. FEJEZET. TELEPÍTÉS
3.1. ábra. Üdvözl˝o képerny˝o
Természetesen az F1 lenyomására segít˝oképerny˝o jelenik meg (3.2. sz. ábra). Ez különösen akkor hasznos, ha az alapértelmezett telepítés valamiért nem muködik ˝ megfelel˝oen. A megfelel˝o üzemmód kiválasztásához a képerny˝o alján a boot prompt látható. Ide kell bebillentyuzni ˝ a megfelel˝o üzemmód kulcsszavát. Külön felhívjuk a fegyelmet arra, hogy egyes régebbi videokártyák a VESA üzemmódot nem támogatják. Ilyenkor A VGA üzemmódot lehet választani, ami ugyan szegényesebb színválasztékot ad, de a telepítés menetét nem befolyásolja.
É RDEMES MEGJEGYEZNI ! A teljes telepítési folyamat során a OK gombot csak akkor szabad megnyomni, ha biztosak vagyunk abban, minden lényeges lépést az adott ponton megtettünk! Nem mindenütt van visszatérési lehet˝oség a megel˝oz˝o ponthoz, így esetleg hibásan installáljuk tuzfalunkat! ˝ A telepítés els˝o lépéseként meg kell ismerkedni a szoftver használatának jogi feltételeivel. Ezt a következ˝o képerny˝on végig lehet olvasni (3.3), de érdemes is megtenni ezt a kés˝obbi esetleges jogi problémák elkerülésére.
˝ 3.3. HA AZ EGÉR NEM MUKÖDIK. ..
29
3.2. ábra. Segítség a telepítés mód kiválasztásához
Ha minden rendben van, akkor a MEHET gombra kattintással indul a tényleges telepítés, de a KILÉPÉS gombra kattintva ki lehet lépni a telepít˝ob˝ol anélkül, hogy a merevlemez tartalma érdemben megváltozott volna. Kattintani? Ha nem muködik ˝ az egér?
3.3. Ha az egér nem muködik. ˝ .. Gyakorlati tapasztalat az, hogy a telepít˝o az esetek nagy részében felismeri a számítógéphez csatlakoztatott egeret, de nem minden esetben! Ez elég hamar kiderül, mert a 3.3. sz. ábrán latható képerny˝o megjelenésekor érdemes kísérletet tenni az egérkurzor mozgatására. Ha ez sikertelen, a Tab billentyut ˝ addig kell nyomogatni, amíg a fókusz az Egér beállítása gombra nem kerül. Ha az egér eredetileg muködik, ˝ ne használja ezt a lehet˝oséget! Az egér meghajtójának elállítása az egér muködésképtelenségé˝ hez vezethet, ami nehézkessé teszi a telepítést (bár az eredményt nem befolyásolja)!
Az Enter lenyomására a 3.4. sz. ábrán látható képerny˝o jelenik meg.
30
3. FEJEZET. TELEPÍTÉS
3.3. ábra. UHU-Linux licenc
Az ábrán jól látható, hogy a soros portok DOS alatt megszokott nevei is szerepelnek a Unixban szokásos nevek mellett. A megfelel˝o beállítás kipróbálható a Teszt lenyomása után. Ha az egérkurzor reagál az egér mozgatására, az OK gomb lenyomására vissza lehet térni a 3.3. sz. ábrán látható képerny˝ohöz, ahol a Mehet gombra kattintva a telepítés els˝o lépésének végrehajtásához lehet eljutni.
3.4. A merevlemez formázása A 3.5. sz. ábra bemutatja a merevlemez formázását el˝okészít˝o képerny˝ot. Itt két lehet˝oség között lehet választani: – A teljes merevlemez megformázása, – Meglév˝o vagy üres partícióra telepítés. Az els˝o esetben a rendelkezésre álló teljes lemezterületet a program egyben fogja kezelni, azaz nem keletkeznek külön partíciók az egyes területekre. A második esetben lehet˝oség nyílik a winchester külön egységekre, partíciókra bontására.
3.4. A MEREVLEMEZ FORMÁZÁSA
31
3.4. ábra. Egér protokolljának és csatlakoztatásának kiválasztása
Az, hogy melyik megoldást választjuk, nem csak „divat kérdés”. A tuzfal ˝ üzemeltetése során felmerül az adatbiztonság kérdése: pl. a kés˝obb kiválasztandó archiválási megoldás1 . Szintén befolyásoló tényez˝o a rendelkezésre álló winchester mérete: az egybefügg˝o területeken a nagy méretu ˝ fájlok „terjeszkedése” kevesebb problémát vet fel - ugyanakkor ez a kézben tarthatóságot csökkentheti. Alapvet˝o és lényeges az, amivel ez a fejezet kezd˝odik, hogy a tuzfal ˝ funkciót ellátó számítógép más feladatot ne lásson el! Ennek megfelel˝oen a második megoldás kiválasztása a rendelkezésre álló winchester teljes területének a particionálásra kell használni! A telepít˝o program lehet˝oséget ad a tuzfal ˝ egy adott partícióra való telepítésére, ez azonban nem kívánatos, biztonsági kockázatot jelent. Amennyiben a particionálás mellett döntünk, a következ˝oket érdemes figyelembe venni: – A tuzfal ˝ programjai, statikus adatai számára 250 – 300 Mb. terület szükséges, – A naplófájlok mérete függ a naplózott forgalomtól és a naplózási szintt˝ol. A meglepetések elkerülésére célszeru ˝ a /var könyvtárat külön partícióra helyezni, 1 Ez a téma meghaladja jelen dokumentáció kereteit, de érdemes gondolni rá még a tuzfal ˝ tervezése során.
32
3. FEJEZET. TELEPÍTÉS
3.5. ábra. A merevlemez formázásának el˝okészítése
– Szokás - és különösebb problémát nem okoz - a /boot könyvtárat is külön partícióra helyezni. Ennek elég néhány tíz Mb.2 . Bármelyik megoldást is választjuk, a lapozó partíció méretét meg kell adni. Erre általános szabályként azt szokták megadni, hogy az operatív memória kétszerese legyen 128 Mb-ig, e felett elegend˝o az operatív memóriával egyez˝o méret3 . Ha a számítógépben több winchester van, a program lehet˝oséget nyújt a winchester kiválasztásához. Itt is megemlítjük, hogy a tuzfal ˝ gép csak tuzfal ˝ feladatot lásson el, így a több winchester csak akkor indokolt, ha ez adatbiztonsági célok miatt van igy! A program figyelmeztet arra, hogy az adott winchesteren minden adat el fog veszni, majd az OK gomb lenyomásával megkezd˝odik a winchester formázása. Ennek befejeztéig a textttA merevlemez el˝okészítése formázása folyamatban. . . felirat látható a képerny˝on. 2 Én általában 50 Mb-t szoktam megadni, aminek kihasználtsága ritkán lépi túl a 25 %-ot. Ekkora területre akkor van szükség, ha több kernel verzió is fent van egyidejuleg ˝ (janu). 3 Én még 256 Mb. operatív tár esetén is a kétszeresét szoktam meghatározni. Egyes alkalmazások miatt nagyobb lapozó terület kijelölése is szükséges lehet, bár a Zorp tuzfalon ˝ ilyen nincs - (janu).
˝ CSOMAGOK 3.5. A TELEPÍTENDO
33
3.5. A telepítend˝ o csomagok Az UHU-Linux Office változatától eltér˝oen nincs lehet˝oség a feltelepítend˝o csomagok között válogatásra. Ennek az az oka, hogy a ZorpGPL egységes rendszert képez, ami úgy lett kialakítva, hogy csak a legszükségesebb, de a megfelel˝o csomagok kerüljenek a merevlemezre. A folyamat során egy el˝orehaladási jelz˝o látható a képerny˝on. Folyamatosan követhet˝o – az eltelt id˝o, – a becsült hátralév˝o id˝o, – a becsült összes id˝o, – a felmásolt csomagok összmérete, – az összes telepítend˝o csomag összmérete, – a másolás sebessége, – az éppen másolás alatt áló csomag · neve, · verziószáma, · mérete, · rövid leírása. A 3.6. sz. ábra a csomagok felmásolásának befejezésekor látható képerny˝ot mutatja. Külön felhívjuk a figyelmet arra, hogy a telepítend˝o csomagok összmérete kisebb, mint a felmásolt csomagok összmérete. Ez nem hiba. Következ˝o lépésként a telepít˝o beállítja a csomagokat. Ezt a folyamatot a 3.7. sz. ábra szemlélteti, itt az el˝orehaladás jelz˝o felett az éppen beállítás alatt álló csomag neve látható. Ennek a résznek a befejezésével a csomagok telepítése is befejez˝odik.
3.6. A grub telepítése, rendszerbetöltés A következ˝o lépés a rendszerbetölt˝o telepítése. Az UHU-Linux (nemcsak a tuzfal ˝ változat) alapértelmezésben a grub4 -ot használja. Ennek beállítása nem igényel különösebb felkészültséget, b˝ovebbet a http://www.gnu.org/ software/grub/grub.html oldalon lehet olvasni. A 3.8. sz. ábrán látható képerny˝o választási lehet˝oségeket nyújt a rendszerbetölt˝o telepítésére: – a szokásos és ajánlott MBR5 területre – az UHU-Linux tuzfal ˝ változatot tartalmazó partíció boot szektorába, – a rendszerbetölt˝o elhagyása – nem ajánlott
34
3. FEJEZET. TELEPÍTÉS
3.6. ábra. A csomagok felmásolása
Ahogy a képerny˝on is szerepel, az els˝o változatot tartjuk célszerunek. ˝ Azt kell figyelembe venni, amit folyamatosan hangsúlyozunk, nevezetesen a tuzfal ˝ – dedikált számítógép, ezért semmi nem indokolja más rendszerek mellettí való muködését, ˝ ez biztonsági kockázatot jelentene. A rendszerbetölt˝o elhagyása nagyon nem ajánlott, ugyanis ebben az esetben rendszerbetölt˝o floppy-val indítható csak a rendszer. Bár ez bizonyos értelemben biztonságosnak mondható, a rendszer újraindítása csak a floppy-val lenne lehetséges, hiánya, megsérülése muködésképtelenséghez ˝ is vezethet. OK Amennyiben az els˝o (vagy a második) lehet˝oség lett kiválasztva, még az gomb lenyomása el˝ott érdemes indítólemezt készíteni. Ez nemcsak grub helyett alkalmazható, hanem fatális helyzetben is lehet˝oséget ad a rendszer betöltéséhez, hibajavításhoz. Ehhez a képerny˝o jobb alsó részén látható Készít gombot kell megnyomni. Ehhez persze el˝otte egy erre alkalmas – formázott, üres – floppy-t kell odakészíteni. Akkor sincs probléma, ha közben meggondoltuk magunkat: a képerny˝o közepén megjelenik egy kisebb ablak, ami a bekér a floppy meghajtóba egy lemezt. Itt az Mégsem gomb megnyomásával vissza lehet térni a 3.8. sz. képerny˝ohöz. 4 5
GRand Unified Bootloader Master Boot Record
3.7. FELHASZNÁLÓK LÉTREHOZÁSA
35
3.7. ábra. A csomagok beállítása
A floppy készítésére kés˝obb is van lehet˝oség a make-bootfloppy paranccsal.
3.7. Felhasználók létrehozása A következ˝o lépés tulajdonképpen 2 elemb˝ol áll: – root jelszó megadása, – felhasználó(k) létrehozása. Mindkét lépés során jelszót kell megadni. A jelszóra vonatkozóan természetesen nem tudunk, és nem is akarunk konkrét ötleteket adni, de álljon itt néhány jótanács (ezek egy része a képerny˝on is olvasható): – A jelszó hossza legalább 6 karakter legyen, – Ne tartalmazzon ékezetes betüket, szóközt, – Tartalmazzon nagybetut, ˝ számot, különleges karaktert (pl. „(”, „{”, „@” stb), – Célszeru ˝ kerülni a „0”, „y”, „z”, „!”, „§”, „"” karaktereket, általában azokat, amelyek a különböz˝o billentyuzeteken ˝ máshol találhatóak, – A jelszónak használt kifejezés ne legyen keresztnév, a kutyád neve, vagy az a szó, ami a képerny˝o mellett ki van írva :-),
36
3. FEJEZET. TELEPÍTÉS
3.8. ábra. Rendszerbetöltés kiválasztása
– Érdemes másoknak értelmetlennek látszó szavakat alkalmazni, pl. „N@t4@n” - nem valószínu, ˝ hogy hamar kitalálod: ez a Nathan név kissé „kódolva”. Ezek a tanácsok azonban semmit nem érnek akkor, ha majd a használat során nem cseréled sur ˝ un ˝ a jelszót. Erre is csak kialakult szokások vannak, a célszeru ˝ határid˝o maximum 14 nap.
3.7.1. Root jelszó megadása Ezen a képerny˝on a jelszót ketszer kell megadni biztonsági okokból. Ha az ellen˝orz˝o bevitel nem felel meg az els˝o bevitelnek, a rendszer figyelmeztet - természetesen az OK gomb megnyomását követ˝oen. Ha az új felhasználó bevitele jelenik meg, a jelszó megadása sikeres volt. A „root” jelszót nagyon fontos megjegyezni! Amennyiben elfelejti, a telepít˝o CD-r˝ol csak nagyon bonyolultan lehet a rendszerbe bejutni (ennek leírása meghaladja e dokumentáció kereteit). Jó megoldás az, ha a jelszót egy nem átlátszó boritékba zárjuk, és biztonságos helyre elhelyezzük. Persze, ha a boriték elvész, vagy elfelejtetted, hová tetted. . .
3.8. HÁLÓZATI KÁRTYÁK BEÁLLÍTÁSA
37
3.7.2. Új felhasználó létrehozása Néhány speciális esett˝ol eltekintev nem szerencsés root felhasználóként belépni a rendszerbe. Az meg végképp komoly biztonsági kockázat, ha a root távoli bejelentkezése engedélyezve van. Ezt lehet némiképp csökkenteni azzal, ha még a telepítés során egy vagy több felhasználót hozunk létre. Erre szolgál a következ˝o képerny˝o. A felhasználónévvel kapcsolatban lényegében csak két megkötés van: – csak az angol ABC kisbetuit ˝ és szamokat tartalmazhat, – legfeljebb 8 karakter hosszú lehet. A jelszóra vonatkozó ajánlásokat, megkötéseket már korábban említettük. Itt egy nagyon fontos dolgot említenénk meg: a felhasználónév és a jelszó megadását követ˝oen a Hozzáadás gombot kell megnyomni, és csak akkor az OK -t, ha más több felhasználót nem akarunk a rendszerbe felvenni.
3.8. Hálózati kártyák beállítása A 3.9. sz. ábra azt a képerny˝oképet mutatja, amelyen a számítógép hálózati kártyáit lehet beállítani.
3.9. ábra. Hálózati kártyák beállítása
38
3. FEJEZET. TELEPÍTÉS
Miel˝ott telepíteni kezdtük a tuzfalat, ˝ meg kellett terveznünk a hálózati kapcsolatokat. Most kell beállítanunk az akkor elhatározott beállításokat. Itt is figyelni kell arra, hogy csak akkor nyomjuk meg az OK gombot, ha már minden kártya adatát beállítottuk, azaz minden kártyát (egyesével) jelöljünk ki a fénycsíkkal (a program megjegyzi a beállításokat).
3.9. Hálózati beállítások A 3.10. sz. ábra a hálózati beállításokat mutatja. Ez egy 3 panelt tartalmazó felület (az ábra az utolsó panelt mutatja). Lényeges, hogy az OK gombot csak akkor szabad megnyomni, ha mindhárom panel adatát megadtuk!
3.10. ábra. Névkiszolgálók, tartományok, hosztok
3.9.1. Névkiszolgáló megadása A „Névkiszolgálók” jelu ˝ panelen lehet a meglév˝o névkiszolgáló IP címét megadni. Fontos azt tudni, hogy egyrészt csak 3 névkiszolgáló adható meg, másrészt azokról van szó, amit a tuzfal ˝ lát! Ebb˝ol ered˝oen nem célszeru ˝ az interneten lév˝o szerver címét megadni, csak ha elkerülhetetlen.
3.9. HÁLÓZATI BEÁLLÍTÁSOK
39
Az IP cím megadása után a Hozzáad gomb megnyomására kerül a táblázatba. Több szerver megadása esetén a Mozgatás fel , illetve a Mozgatás le gombokkal van lehet˝oség a sorrend megváltoztatására.
3.9.2. Keresési tartományok Ezen a panelen lehet megadni azokat a tartományokat, amelyben a tuzfal ˝ számára a névfeloldás, illetve a számítógép keresése alapértelmezett. Ugyanúgy, mint az el˝oz˝o panelen, itt is a szöveg beírása után a Hozzáad gombbal lehet felvenni az egyes tartományokat, a Mozgatás fel és Mozgatás le gombokkal lehet a sorrendet módosítani.
3.9.3. Hoszt nevek Az utolsó panelen (amit a 3.10. sz. ábra is mutat) a tuzfal ˝ hosztnevét lehet megadni. Egy érték már szerepel itt: a localhost. Ezt nem szabad kitörölni, hanem ehhez kell a további IP cím – név párost megadni. A kitöltésnél szem el˝ott kell tartani azt, hogy az IP cím alatt lév˝o beviteli mez˝obe be kell írni az ún. nicket (másként: a gép rövid/hoszt nevét). A „Más nevek” ablakba annak az IP cím/hosztnév párosnak lehet az alternatív nevét (általában a teljes hoszt.domain) megadni, amin a fénycsík áll.
Ezzel lényegében be is fejez˝odött maga a telepítés. A záróképerny˝o lesz látható, amin a fejleszt˝ok és segít˝ok neve, elérhet˝osége látható. Még egy plusz szolgáltatás is megjelenik: a Juhhú! megnyomására még egy figyelmeztetés is megjelenik (a 3.11. sz. ábra): a rendszer újraindulását kövt˝oen az „uzi” programot kell elindítani (err˝ol a 4. sz fejezet szól). Távolítsuk el a telepít˝o CD-t a meghajtóból, miel˝ott a számítógép újraindul.
40
3. FEJEZET. TELEPÍTÉS
3.11. ábra. A telepítés befejezése
4. fejezet
Beállítás Ebben a fejezetben a ZorpGPL UHU tuzfal ˝ beállítási lehet˝oségeivel foglalkozunk, és bemutatunk néhány ezzel kapcsolatos egyszerubb ˝ muveletet. ˝ A fejezetben ismertetett példákhoz a D. függelékben található policy modellt vettük alapul.
4.1. Template beállítások használata az uzi program segítségével. A ZorpGPL UHU tuzfal ˝ telepítése után automatikusan elindul az uzi program melynek segítségével el˝ore elkészített template beállításokat hozhatunk létre. Ezzel a módszerrel könnyedén, néhány szükséges mez˝o kitöltése után már muköd˝ ˝ o és biztonságos tuzfalat ˝ hozhatunk létre.
4.1.1. Az uzi muködése ˝ Az uzi egy teljes képerny˝os karakter-grafikus alkalmazás, amely szekvenciális logikára épül. A képerny˝o mez˝oi és a gombok között a Tab billentyu ˝ segítségével válthatunk. A program bizonyos szükséges kérdések feltétele után legenerálja a tuzfal ˝ muködéséhez ˝ szükséges konfigurációs állományokat, úgymint: – natív proxy-k konfigurációs állománya, – csomagszur˝ ˝ o beállítások és – Zorp beállítások. A létrehozott konfigurációs állományok ezek után még természetesen testre szabhatók. Vállalkozó kedvu, ˝ hozzáért˝obb felhasználóknak ebben segítenek a
41
42
4. FEJEZET. BEÁLLÍTÁS
4.1. ábra. UZI DMZ menü
kés˝obbi fejezetek, amelyek részletesen leírják az operációs rendszer, a csomagszur˝ ˝ o, a natív proxy-k és a Zorp további beállítási lehet˝oségeit (a Zorp ZUI-val és konfigurációs állomány szinten elérhet˝o funkcióit is.). A ZorpGPL UHU tuzfal ˝ - template beállításai segítségével - 1 DMZ1 kezelésére alkalmas (a tuzfalszoftver ˝ alkalmas több DMZ kezelésére is, ennek módját a kés˝obbi fejezetek mutatják meg). Amennyiben a tuzfal ˝ DMZ-t is védeni fog, a 4.1. sz ábrán látható képerny˝on válassza az „Igen”-t. Jelen esetben a 2.1. sz ábrán (22) bemutatott példa topológia alapján konfiguráljuk be a tuzfalat, ˝ azaz az „Igen”-t választjuk. A konfiguráció megkönnyítése érdekében az uzi tartalmaz három, az engedélyezett szolgáltatások függvényében különböz˝o védettséget nyújtó alapbeállítást (l. 4.2. sz. ábra). Ezek a következ˝ok (mindháromnál a DMZ-vel rendelkez˝o esetet soroltuk fel; értelemszeruen, ˝ amikor nincs DMZ, akkor az azt érint˝o szolgáltatások nem engedélyezettek): – Minimális: Intranet-Internet http, anonymous ftp 1
Demilitarized Zone - demilitarizált zóna
4.1. TEMPLATE BEÁLLÍTÁSOK HASZNÁLATA
4.2. ábra. Szolgáltatások menü
Intranet-Dmz http, ssh(plug) Internet-Dmz http – Optimális Intranet-Internet http, https(plug), readonly-ftp, pop3(plug) Intranet-Dmz http, https(plug), ssh(plug) Internet-Dmz http, https(plug) – Teljes Intranet-Internet http, https(plug), ftp, pop3(plug), whois, finger, telnet Intranet-Dmz http, https(plug), ssh(plug) Internet-Dmz http, https(plug)
43
44
4. FEJEZET. BEÁLLÍTÁS
Az alap kérdések után a tuzfal ˝ hálózati beállításaira vonatkozó kérdések következnek. interfész azonosítójának beállítása. El˝oször az intranet interfészének azonosítóját kell megadni (esetünkben eth1, majd ennek hálózati címét. Ezt IP cím/CIDR2 formátumban várja a program, azaz esetünkben: 10.0.0.0/83 Ezután meg kell adni a tuzfal ˝ intranet oldali interfészének az IP címét (esetünkben 10.0.0.254). Ha a DMZ-re vonatkozó kérdésre Igen -nel válaszoltunk, ugyanezeket a kérdéseket kell megválaszolni a DMZ-re vonatkozóan is. Ezután az Internet oldali interfész adatai következnek. Miután beállítottuk az interfészeket, a névkiszolgáló (DNS szerver) IP címét kell megadnunk (általában ezt az Internet szolgáltató határozza meg). A következ˝o lépés az NTP4 szerver IP címének megadása. A tuzfal ˝ a saját óráját ehhez fogja igazítani. A bels˝o hálózaton lév˝o eszközök óraszinkronizálásához a tuzfal ˝ bels˝o lábát kell NTP forrásként megjelölni. Mivel a tuzfal ˝ lokális e-mail kiszolgálást nem végez, szükséges, hogy ismerje a bels˝o hálózaton lév˝o mail szerver (pl.: UHU Szerver verzió) IP címét, amelynek a bejöv˝o leveleket továbbítja. A következ˝o lépésben ezt kell megadni. A tuzfalnak ˝ ismernie kell a bels˝o hálózatról az Internet irányába küldött levelek továbbításához a megfelel˝o SMTP szerver IP címét (Általában az Internet szolgáltató adja meg).Ez a következ˝o megadandó információ. A tuzfalnak ˝ ismernie kell a cég mail domain nevét, amelyre érkez˝o leveleket elfogadja és továbbküldi a bels˝o mail szervernek. (Más domain-re jöv˝oket nem engedélyezi.) A beállításban a cég e-mail címének „@” utáni részét kell megadni, ahogy ez a 4.3. sz ábrán látható. A 4.4. ábrának megfelel˝o mez˝obe a DMZ-ben lév˝o publikus szolgáltatásokat nyújtó szerver IP címét kell megadni (ha van ilyen). A tuzfal ˝ template beállításainak értelmében a DMZ-ben lév˝o szervernek nem kell publikus IP címének lennie, elég ha a tuzfalnak ˝ az van5 . Az uzi e kérdés megválaszolása után a megfelel˝o konfigurációs állományokat elmenti. A beállítások testre szabását, valamint az zui használatát a kés˝obbi fejezetek mutatják be.
2 CIDR: Classless Inter-Domain Routing - osztály nélküli domain-ok közötti útvonalválasztás; segítségével egyszerusíthet˝ ˝ oek a routolási táblák. Gyakorlatilag azt mutatja, hogy hány hosztot tud kiszolgálni az így jellemzett hálózat. Ennek kiszámítása: 2(32−CIDRmaszk) , pl. 24 CIDR maszk esetén 256 (28 ). 3 Ebben az esetben alhálózati maszknak elegend˝ o lenne 24, ahogy az a 22. oldalon lév˝o ábrából is kiderül. Mivel a 10.0.0.0 egy „A” osztályú (privát) IP cím, ezért szokás 8-at adni. 4 Network Time Protocoll - hálózati id˝ o szinkronizáló szolgáltatás 5 Jelen dokumentáció tárgyalási körét meghaladja az a helyzet, amikor a DMZ-ben több kívülr˝ol azonosítható szerver van, de természetesen a Zorp ezt a helyzetet is tudja kezelni.
4.2. AZ OPERÁCIÓS RENDSZER KONFIGURÁLÁSA
45
4.3. ábra. SMTP domain-ek
4.2. Az operációs rendszer konfigurálása A Zorp telepítése után szükség lehet az operációs rendszer alapértelmezett beállításainak finomítására. A következ˝o felsorolás segítségével tökéletesen konfigurálhatjuk operációs rendszerünket.
4.2.1. Modulok A Zorp-pal installált kernel modulokat használ a támogatott driver-ekhez, azonban nem indítja o˝ ket automatikusan. A telepített hardverhez tartozó driver elindításához használhatjuk a modconf programot, ami az els˝o rendszerindítás után automatikusan elindul, vagy saját kezuleg ˝ is indíthatjuk, ha átírjuk az /etc/modules fájlt.
4.2.2. Er˝ oforrás korlátozások A kernel limitálja a futó programok által felhasználható er˝oforrásokat, hogy egyetlen program se tudja lekötni a rendszer teljes kapacitását. Ha túl alacsonyan határozzuk meg a fájlkezelés vagy a memória által leköthet˝o kapacitást, az problémákat okozhat. A beépített ulimit parancs segítségével megváltoztat-
46
4. FEJEZET. BEÁLLÍTÁS
4.4. ábra. DMZ szerver
hatjuk a határértékeket. További részletek a témával kapcsolatban az ulimit(1) kézikönyvében találhatók. Ha a Zorpnak több fájl descriptorra van szüksége, vagy nem tudunk új threadeket indítani, át kell állítani az ulimit beállításokat.
4.2.3. Kernel korlátozások A Linux kernel az ulimitt˝ol függetlenül önmagát is korlátozza. A korlátozások lehetnek konstansok, vagy módosítható értékek. Az utóbbiakat a /proc/sys alatt módosíthatjuk, a többi korlátozást megtalálhatjuk a -ban, de fontos, hogy a fájl megváltoztatásával újra kell fordítani a kernelt is! A két legfontosabb korlátozás azt szabályozza, hogy hány fájl descriptort, illetve alkalmazást nyithatunk meg párhuzamosan.
4.2.4. Alkalmazások korlátozásai Az egyszerre futtatható processzek száma korlátozott. A Linux 2.2-ben ez az érték egy konstans, amit a tasks.h-ban találunk. A neve NR_TASKS, alapértel-
4.3. NATÍV PROXYK
47
mezett értéke 512. A Zorppal terjesztett kernelben a limitet 4090-re emeltük, ez jelenleg a Linux kernel által nyújtható maximum.
4.2.5. Helyi port tartomány A Zorp külön kapcsolatot létesít a kliensekkel és a szerverekkel, és a Linux kernelt használja új portok meghatározására a kimen˝o kapcsolatokhoz. A Linux biztosítja, hogy a hozzárendelt socketek a /proc/sys/net/ipv4/ip_local_port_range-ben meghatározott tartományból kapjanak port számot. Ha az adott tartományban minden port használatban van, a kapcsolatteremtési kérelem sikertelen lesz. Az alapértelmezett tartomány 1024-4999, így körülbelül 4000 kimen˝o kapcsolat engedélyezett.
4.2.6. IP forwarding Az IP csomagok továbbítását engedélyeznünk kell ahhoz, hogy a transzparens proxy alkalmazás muködjön ˝ (/proc/sys/net/ipv4/ipforward). Valójában ehhez a csomagok valódi forwardolására azonban nincs szükség, ezért azt le kell tiltanunk a csomagszur˝ ˝ oben azzal, hogy a forwarding láncba beiktatunk egy DENY szabályt.
4.2.7. IP cím spoofolás A Linux rpfilter szolgáltatásának feladata az IP spoofing6 megakadályozása. Úgy kell beállítanunk csomagszur˝ ˝ onket, hogy az akadályozza a spoofolást, az rpfiltert pedig le kell tiltanunk minden interfészen, mivel nem kompatibilis a Zorp néhány szolgáltatásával.
4.2.8. TCP paraméterek Számos TCP paraméter megváltoztatható a /proc/sys/net/ipv4-ben. Ezek közül fontos átállítani a kapcsolat „keepalive” id˝obeli korlátait, így az RST, vagy FIN nélkül lezárt kapcsolatokat gyorsabban bezárhatja a tuzfal ˝ (jobban ellenállva ezzel bizonyos DOS jellegu ˝ támadásoknak).
4.3. Natív proxyk Vannak protokollok, melyek megvalósítása szinte proxyként viselkedik. Jó példa erre a DNS, amely a nevek IP címmé alakításáért (és vica versa) felel˝os. A DNS szervert beállíthatjuk úgy, hogy fogadja a rekurzív kéréseket (az adott névszerver adatbázisán kívül es˝o adatokat lekér˝o kérések), majd a megfelel˝o névszerver felé irányítsa o˝ ket. 6
forrás IP cím megváltoztatása - általában ártó szándékkal
48
4. FEJEZET. BEÁLLÍTÁS Protocol SMTP DNS NTP
Implementation Postfix ISC bind ntpd
Homepage http://www.postfix.org/ http://www.isc.org/ http://www.ntp.org/
4.1. táblázat. Natív proxy alkalmazások
Mivel ehhez szükség van a kérések alkalmazás szintu ˝ elemzésére, a névkiszolgálót alkalmazás szintu ˝ proxynak tekinthetjük. Az NTP protokoll is ezek közé tartozik. Ezzel az internetre kapcsolt gépek óráit lehet egyeztetni. Az ntpd-t, ami az NTP alkalmazása, a tuzfal ˝ órájának szinkronban tartására használhatjuk, illetve az NTP funkciót elérhet˝ové tehetjük a bels˝o hálózaton. Így könnyu ˝ belátnunk, hogy az ntpd is proxy funkciót tölt be. Az említett alkalmazásokat jogosultságmentes környezetbe telepítjük a minimálisan szükséges beállításokkal, ezzel is csökkentve a natív proxy-k használata jelentette kockázatot. jailer: megkönnyíti az alkalmazások chrooted jail-ben történ˝o karbantartását. A debian csomagokat a függ˝oségeivel együtt egy alkönyvtárba másolja, szükségességük alapján szelektálva a fájlok között. restrict: korlátozhatjuk vele az alkalmazások tevékenységét, megváltoztathatjuk az uid/gid-et és chrootolhatunk egy programot az adott jail-ben. A DNS, SMTP és NTP alkalmazásokat a table 4.1 táblázatban leírt módon használjuk.
4.4. A csomagszur˝ ˝ o konfigurálása A Zorp a csomagszurés ˝ mellett alkalmazásszintu ˝ proxykat is használ. A Zorppal terjesztett csomagszur˝ ˝ o alkalmazás az IPTables, ami a 2.4-es Linux kernel standard csomagszur˝ ˝ o alkalmazása. Ahogy az 1.2. sz. ábra is mutatja, a csomagszurés ˝ a hálózati szinten, a kernelben történik, a csomag rendszerbe lépése után rögtön, miel˝ott az IP verem feldolgozza. Az IPTables a standard Linux kerneleken alapértelmezetten elfogad minden csomagot, így azt sem tudhatjuk, hogy egyáltalán létezik-e. Éppen ezért megváltoztattuk az alapbeállításait, úgy, hogy alapértelmezetten mindent tiltson. Az IPTables táblákból épül fel, az egyes táblák más-más funkciók ellátására alkalmasak. Mindegyik tábla tartalmaz alapértelmezett szabályláncokat, amelyeken a csomagok végighaladnak. A táblákban lehet˝oség van ezen szabályláncok, illetve saját láncok összeállítására. Minden szabály egy feltételb˝ol és egy célb˝ol
˝ KONFIGURÁLÁSA ˝ O 4.4. A CSOMAGSZUR
49
áll. A feltétel szabja meg, hogy mely csomagokat kell figyelni, a cél pedig megadja, hogy mi legyen a feltételben megszabottal egyez˝o csomaggal. Táblánként lehet˝oség van különleges, tábla-specifikus célok megadására. A Netfilter/IPTables rendszer képes az egyes kapcsolatok követésére, azaz arra, hogy egy adott csomag melyik kapcsolathoz tartozik, illetve, hogy az adott kapcsolatnak mi az aktuális állapota. Ezáltal könnyebben lehet összeállítani a tuzfal ˝ szabályrendszerét, mivel a csomagok közötti kapcsolat nyomon követhet˝o. Az IPTables a következ˝o táblákat tartalmazza: – filter: Ebben a táblában van lehet˝oségünk a hosztnak jöv˝o, rajta átmen˝o, vagy a hosztról kimen˝o csomagok szurésére. ˝ Alapértelmezés szerint a következ˝o szabályláncokat tartalmazza: INPUT, FORWARD, OUTPUT. – nat: Ebben a táblában lehet megadni a NAT-olási szabályokat. Alkalmazásszintu ˝ tuzfalnál, ˝ azaz a Zorp esetén is, ezt a táblát nem használjuk. – mangle: Ebben a táblában lehet a csomagok tulajdonságait megváltoztatni (FWMARK, TOS, stb.), Zorp esetében nincs rá szükség. – tproxy: A Zorp szempontjából a legfontosabb tábla. Itt kell az áthaladó kapcsolatokat, csomagokat átirányítani a Zorphoz, ezzel elérve a transzparens proxy muködést. ˝ A tábla a következ˝o láncokat tartalmazza: PREROUTING, OUTPUT. A szabályláncoknál a következ˝o szabályokat adhatjuk meg célként: ACCEPT: Ez a szabály elfogadja az egyez˝o csomagot, a csomag tovább haladhat. REJECT: Visszautasítja az egyez˝o csomagot, és értesíti err˝ol a küld˝ot. DENY: Csendben kiszuri ˝ a csomagot. TPROXY: Átirányítja az egyez˝o csomagot egy helyi proxyhoz, és gondoskodik a kapcsolat további csomagjainak a célba juttatásáról. Felhasználó által meghatározott lánc: Ez a szabály a csomag további kezelését a felhasználó által meghatározott láncra adja át, a lánc hozhat saját döntéseket, vagy visszatérhet az alapszituációhoz. RETURN: Ez a szabály visszatér a lánctól az átadás szabályához. A feltétellel az IP datagram következ˝o területein fogalmazhatunk meg megkötéseket: – forrás/célcím (-s és -d paraméterek) – forrás és célport az UDP/TCP protokollok esetében (az IP cím után -s és -d paraméterekkel meghatározva, IP cím hiányában a –destination-port és a –source-port által) – forgalmi réteg protokoll (-p paraméter [tcp/udp/icmp]) – TCP flag-ek (–syn paraméter) – az interface neve ahol a csomag bejött (-i), illetve ahol távozni fog (-o)
50
4. FEJEZET. BEÁLLÍTÁS – egyéb „match” paraméter (-m), például: -m tproxy
Minden további, az IPTables-szel kapcsolatos információ megtalálható a Linux Documentation Project honlapján: http://www.linuxdoc.org/, az IPTables-HOWTO-ban, valamint a Netfilter/IPTables honlapján a http://www. netfilter.org/ címen. A Zorppal forgalmazott iptables-utils csomag tartalmaz néhány hasznos szöveget, ami jól jöhet az iptables konfigurálásához és karbantartásához. Az iptables-utils használatakor konfigurációnk két részre oszlik: 1. iptables.conf.var - ez tartalmazza a változó részeket, mint az IP címek, hálózati interfészek nevei a C függelékben látható példában bemutatott C stílusú #define utasítások formájában. 2. iptables.conf.in - a szabályokat tartalmazza, az iptables.conf.var-ban definiált szimbolikus konstansokra való utalásokkal együtt. A fenti két fájl kitöltése után már használhatjuk az iptables-gent, amellyel új szabályrendszert generálhatunk. Az új rendszer az /etc/iptables.conf.new fájlban található. Az új szabályrendszert az iptables-test [seconds] scripttel tesztelhetjük. A script betölti az új szabályrendszert majd az általunk megadott másodpercnyi id˝ot vár (ha nem adtuk meg, akkor 10 másodpercet) végül újratölti a régit. Ez lehet˝ové teszi az iptables szabályok fenntartását önmagunk kizárásának veszélye nélkül akkor is, ha a hálózatról vagyunk bejelentkezve. Ahhoz, hogy érvényesítsük a változtatásainkat, másoljuk át a /etc/iptables.conf.new fájlt /etc/iptables.conf néven (felülírva az esetleg ott lév˝ot), így az iptables szabályok már az utóbbi fájlból fognak betölt˝odni a legközelebbi rendszerindítástól kezdve. A C függelékben található példában további részletek vannak az iptables konfigurálásáról.
4.5. Zorp elemek Jelen részben felsoroljuk milyen konfigurációs elemekb˝ol áll a Zorp tuzfal. ˝
4.5.1. Konfiguráció A beállítások és a tuzfal ˝ policy a /etc/zorp/policy.py fájlban találhatók. A fájl egy Python modul, amely importálja és felhasználja a Zorphoz rendelt osztályok által kínált lehet˝oségeket.
4.5.2. példányok leírása Lehet˝oség van a Zorp több példányban való futtatására is egyazon tuzfalon. ˝ A példányok neveit és az indítási paramétereiket a /etc/zorp/instances.conf
4.6. A ZORP KONFIGURÁLÁSA A ZUI SEGÍTSÉGÉVEL
51
állomány tartalmazza. Ezeket a beállításokat a zorpctl parancs értelmezi amelyet a 4.5.5 pontban írunk le.
4.5.3. A Python alkalmazások osztályai A Zorp C nyelven megírt magja tartalmaz egy interfészt a Python felé. Ez az interfész már tartalmazza a Pythonba beültetett alkalmazások osztályait is. Az osztályok a Zorp python csomagban találhatók meg, a /usr/share/zorp/pylib könyvtárban. A Pythonról és a csomagokról az 5.1 részb˝ol tudhatunk meg többet.
4.5.4. A Zorp bináris verziója A Zorp binárist a /usr/lib/zorp könyvtárban találjuk. Ne futtassuk közvetlenül, használjuk inkább a zorpctl -t.
4.5.5. A zorpctl script A zorpctl-lel kezelhetjük a legkönnyebben a Zorpot. Segítségével elindíthatjuk, megállíthatjuk és újraindíthatjuk a Zorp alkalmazásokat.
4.6. A Zorp konfigurálása a zui segítségével A Zorp a /etc/zorp/policy.py-t használja helyi policy adatbázisának, amely tartalmazza a Python konfigurációját és helyi döntéseit. A modult saját magunk is összeállíthatjuk, de használhatjuk a zui programot is a generáláshoz. A Zorp konfigurálása el˝ott érdemes újra végigfutni a definíciókon a 1.3 részben leírtaknak megfelel˝oen, illetve az alapvet˝o Zorp jellemz˝okön, mint az egyes instance, zone, service vagy listener. A zui csak TCP kapcsolat esetén használható. Ha UDP kapcsolatot használunk, kénytelenek leszünk azt kézzel beállítani. A téma részleteivel az 5 fejezetben és a Zorp Referenciakönyvben foglalkozunk. A zui egy teljes képerny˝os, karakter-grafikus program. A Tab billentyuvel ˝ mozoghatunk a felhasználói interfész különböz˝o elemei között, az Enter -el fo gadjuk el a mutatott értéket, és az Esc megnyomásával térünk vissza az el˝oz˝o menühöz, anélkül, hogy elfogadnánk egy értéket. A zui több tuzfal ˝ policy-jának kezelésére is képes, fájlban tárolva azokat. A kezd˝o ablakban megtalálhatjuk az összes eddigi tuzfal ˝ policy-t a funkciókat jelöl˝o menügombok mellett (l. 4.5. ábra). Add menügombbal adhatunk új tuzfal ˝ policyt az eddig meglév˝ok mellé,
52
4. FEJEZET. BEÁLLÍTÁS
4.5. ábra. ZUI f˝omenü
Edit segítségével megnyithatjuk a kiválasztott policyt, és beletekinthetünk a policy szerkeszt˝o ablak segítségével. Delete paranccsal törölhetjük a kiválasztott policyt. Save elmenti a ZUI adatbázist a /etc/zorp/zui.db fájlba. Fontos megjegyeznünk, hogy a policy-kat csak a bináris ZUI adatbázisban lehet megtekinteni, a policy.py fájl generálása után már nem lehet importálni azokat! Exit kilépés a ZUI-ból, és visszatérés az operációs rendszerhez. Új tuzfal ˝ policy hozzáadásához nyomjuk le az Add gombot, ekkor jelenik meg a 4.6 ábrán bemutatott ablak. El˝oször adjuk meg a tuzfal ˝ nevét. Ez a név lesz a cég tuzfalának ˝ egyedi ismertet˝oje. Az ajánlott forma a következ˝o firewall-id@company-id. Ez a név szerepel majd a rendszernapló üzenetekben, így az összevont napló fájlokban is könnyebb lesz megtalálni ezeket az üzeneteket. Ha kész vagyunk a tuzfal ˝ bejegyzésével, az Edit gomb megnyomásával rögtön hozzá is kezdhetünk a megfelel˝o policy szerkesztéséhez. Megnyílik a 4.7 ábrán látható ablak. Az ablakban található két lista közül a fels˝o a meghatározott zónákat, az alsó a Zorp példányokat sorolja fel. Az ugyanazon policy keretein belül muköd˝ ˝ o Zorp alkalmazások azonos zónákat használnak. Az egyes listák tartalmát a mellettük lév˝o menügombokkal változtathatjuk. Az ablak jobb oldalán további két gombot láthatunk, ezek: Generate és Close .
4.6. A ZORP KONFIGURÁLÁSA A ZUI SEGÍTSÉGÉVEL
4.6. ábra. Új policy készítése
4.7. ábra. Policy szerkesztés
53
54
4. FEJEZET. BEÁLLÍTÁS
Zónák: itt a tuzfal ˝ által értelmezend˝o zónákat szerkeszthetjük, törölhetjük, vagy adhatunk hozzájuk újakat. A zóna több IP cím együttesének egyedi névvel ellátott összessége. A tuzfal ˝ a zónákra határozza meg az abból induló és abba érkez˝o szolgáltatásokat. Minden zónának egyedi címtartománya kell, hogy legyen, így pontosan egyeztethetjük az IP címeket a tartománnyal (a 10.0.0.0/24. és a 10.0.0.0/25 különböz˝o címtartománynak számítanak ebben az értelemben, és adott IP esetén a rá leginkább illeszked˝o szerint kezeljük). Instances, alkalmazások: itt példányokat szerkeszthetünk, adhatunk hozzá a többihez, vagy törölhetünk. A példány egy futó Zorp program, amely a policy-ban meghatározott feladatait hajtja végre. Ajánlatos minden fizikailag külön lábon lév˝o zónához egy példányt rendelni, ami az adott zónából jöv˝o kéréseket kezelheti. Például egy olyan hálózat esetében, ami három zónát tartalmaz: intranetet, internetet és DMZ-t, érdemes három, a zónáknak megfelel˝o példányt létrehozni, melyek csak a hozzájuk rendelt interfészeken figyelik a kéréseket. További szeparációra ad lehet˝oséget, ha adott zónán belül szolgáltatásokra is külön példányt futtatunk. A példányra bontás el˝onye a logikai szeparációban (bonyolult konfiguráció esetén átláthatóbb), illetve extrém terhelések kiszolgálása esetén jelentkezik. Generate gombbal készül el ZUI beállításainknak megfelel˝oen /etc/zorp/policy.py és az /etc/zorp/instances.conf fájlok.
az
Close gombbal fejezhetjük be a szerkesztést és térhetünk vissza a f˝o ablakhoz. Hozzuk létre a következ˝o zónákat (a 4.8. ábra ezt a tevékenységet szemlélteti): intra (intranet), mgmt (menedzsment zóna), dmz (demilitarizált zóna) és internet a következ˝o tulajdonságokkal: – intra - címtartomány: 10.0.0.0/24 – mgmt - címtartomány: 10.0.0.224/28, szül˝o zónája az ’intra’ – dmz - címtartomány: 192.168.0.1 – inter - címtartomány 0.0.0.0/0 A 4.9. ábra a címtartományok meghatározását mutatja be. A hozzáférés ellen˝orzése a Zorpon belül a zónákon alapul. Egy kérés érkezésekor elkezd˝odik a kérésnek megfelel˝o privát zóna keresése. Ha nincs ilyen zóna, a Zorp elutasítja a kérést. Amennyiben talál a kéréssel egyez˝o zónát, a Zorp még ellen˝orzi, hogy a kért szolgáltatás engedélyezett-e az adott zónából (az outbound_services listájának vizsgálatával), és folytatja a kérés feldolgozását. Hasonlóan muködik ˝ a keresés a szerver oldalán is, azzal a különbséggel, hogy a szerver az inbound_services listáját ellen˝orzi. Minden zóna örökölhet a többi biztonsági jellemz˝oib˝ol, ezt hívjuk szül˝ogyermek viszonynak, amit úgy érhetünk el, hogy a zónának beállítunk egy másik zónát mint szül˝ot (parent). Példánkban az „mgmt” az „intra”-tól vesz át ilyen jellemz˝oket, így minden, ami engedélyezett az „intra”-ban, az engedélyezve van az „mgmt”-ben is.
4.6. A ZORP KONFIGURÁLÁSA A ZUI SEGÍTSÉGÉVEL
4.8. ábra. Zóna létrehozása
4.9. ábra. Egy zóna címtartományának meghatározása
55
56
4. FEJEZET. BEÁLLÍTÁS
4.10. ábra. Alkalmazás szerkesztése
A zónák egy másik tulajdonsága az úgynevezett „eserny˝o” (umbrella). Ez az eserny˝o a valódiak mintájára muködik, ˝ csak nem az es˝ot, hanem a biztonsági jellemz˝ok átvételét állítja meg. Például ha egy zónának adminisztratív „szül˝oje” van, és az „eserny˝o” TRUE-ra van állítva (be van „pipálva”, akkor az említett zóna még átveszi a szül˝o tulajdonságait, de már nem örökíti tovább. A tuzfalak ˝ több Zorp példányt futtathatnak egyszerre, melyeket egyedi névvel kell ellátni. Mivel a példánkban négy zóna szerepel, ennek megfelel˝oen készítsünk 4 példányt. Új példányokat az "Instances" lista mellett található "Add" gomb megnyomásával hozhatunk létre. – „intra” az intranet zónából induló forgalom kezelésére – „mgmt” a menedzsment zónából induló forgalom kezelésére – „dmz” a demilitarizált zónából induló forgalom kezelésére – „internet” az internetr˝ol érkez˝o induló forgalom kezelésére A példányok paramétereit megváltoztathatjuk az /etc/zorp/instances.conf fájlban, miután generáltunk már ilyet a ZUIval. Miután elkészültek Zorp példányaink, szolgáltatásokat (service-eket) is kapcsolhatunk hozzájuk, az „Instances” lista mellett található ( Edit) gomb megnyomása után megnyíló ablakban (4.11. ábra) A Zorp minden példánya számos service-t - szolgáltatást - és listenert tartalmazhat. Szolgáltatás az, amit a klienseknek nyújtunk, pl. egy kéréseket közvetít˝o protokoll proxy. A listener az interfészhez kapcsolódik, fogadja a kapcsolatteremtési kéréseket, és ennek megfelel˝oen elindítja a szolgáltatásokat.
4.6. A ZORP KONFIGURÁLÁSA A ZUI SEGÍTSÉGÉVEL
57
4.11. ábra. Példány szerkesztése
Kétféle módon hozhatunk létre „Listener” és „Service” eszközöket, vagy egyénileg beütjük a szükséges paramétereket, vagy automatikusan az el˝ore meghatározott minták egyikének segítségével. Egyéni szolgáltatás készítéséhez nyomjuk meg a „Services” lista mellett található menuelemAdd gombot, ekkor a 4.12 ábrán látható ablak jelenik meg. Következetesen adjunk nevet szolgáltatásainknak, hogy könnyen érthet˝o legyen, melyik tuzfal ˝ és kinek biztosítja az adott szolgáltatást. A 4.12 ábrán is látható módon három részb˝ol álló neveket javasolt adni, az egyes részeket aláhúzással elválasztva egymástól. A különböz˝o részek jelentései: 1. A forrászóna neve; ez az a zóna, ahonnan a szolgáltatásra irányuló kérés származik (pl.: intra vagy dmz) 2. A szolgáltatás által használt protokoll neve (pl.: HTTP vagy FTP) 3. Ez a rész tetszés szerint kitölthet˝o vagy szabadon hagyható, attól függ˝oen, hogy egyértelmu ˝ a szolgáltatás céliránya vagy sem. A transzparens szolgáltatások célja rendszerint nem egyértelmu, ˝ mivel a valódi cél csak a cél-hosttal való kapcsolat kezdeményezésekor derül ki. A kérelmez˝o kliens eredeti céljától függetlenül mindig egy adott hostra kapcsolódó szolgáltatások egyértelmu ˝ céllal rendelkeznek, így ebben az esetben kitölthetjük az említett részt. Példaként néhány szolgáltatás neve, és a hozzájuk tartozó leírás: intra_HTTP - az intranet számára biztosított transzparens szolgáltatás, amely a HTTP protokollt használja, célja lehet a DMZ vagy az Internet is. inter_HTTP_dmz - az interneten lév˝o klienseknek biztosított szolgáltatás, célja a dmz-ben található. (Az intra zónába nem fogjuk beengedni.)
58
4. FEJEZET. BEÁLLÍTÁS
4.12. ábra. Szolgáltatás készítése
A szolgáltatások tulajdonságainak beállításához válasszuk ki a kívánt szolgáltatást a listán, majd nyomjuk meg az Edit gombot. Ekkor a 4.13. ábrán látható ablak jelenik meg. Ebben a menüben a szolgáltatások különböz˝o tulajdonságait állíthatjuk be. A következ˝o lehet˝oségek közül választhatunk: proxy: az a proxy osztály, melyet a kapcsolat indulása után a szolgáltatás kéréseinek kezelésére használunk. router: a router határozza meg a célcímet, miel˝ott rákapcsolódna a szerverre. A különböz˝o típusú kapcsolatokhoz különböz˝o routerek használhatók. auth: egy autentikációs módszer, melyet a szolgáltatáshoz való hozzáférés el˝ott alkalmazunk. Ezt a beállítást nem módosíthatjuk a ZUI-ból. snat: a forráscím fordítás (SNAT - Source Network Address Translation) a célszerverrel való kapcsolatlétesítés el˝ott, a kimen˝o forráscímen történik. Ez a beállítás sem változtatható a ZUI-ból. dnat: a célcím fordítás (DNAT - Destination Network Address Translation) a megcélzott szerverrel való kapcsolatlétesítés el˝ott, a célcímen történik. A beállítás nem változtatható a ZUI-ból. A fentiek mellett itt állítható be az is, hogy a szolgáltatásokat mely zónákból lehet igénybe venni, illetve, mely zónákba léphetnek be. (inbound, outbound) Tehetjük mindezt úgy, hogy a megfelel˝o listához a megfelel˝o zóna neveket hozzáadjuk az Add gomb segítségével. Source Zones (forrászónák): itt adhatjuk a listához az összes zónát, ahol a klienseknek engedélyezett az adott szolgáltatás használata.
4.6. A ZORP KONFIGURÁLÁSA A ZUI SEGÍTSÉGÉVEL
59
4.13. ábra. Szolgáltatás szerkesztése
Destination Zones (célzónák): itt adhatjuk hozzá az összes engedélyezett célzónát a listánkhoz. Az ablak alján két menügomb található, az Import és a Globals . A gomboknak csak akkor van funkciója, ha a szolgáltatás minták segítségével már el˝oz˝oleg megalkottuk ezeket a szolgáltatásokat. Import: kijelöli azokat a részeket, melyeket a szolgáltatás minta hozzáad a policy.py import részéhez. Globals: kijelöli azokat a részeket, melyeket a szolgáltatás minta hozzáad a policy.py global részéhez. Példánkban felállítottuk az intra_HTTP szolgáltatást , ami egy HttpProxy-t használ a kérések közvetítésére. A szolgáltatás transzparens, így a kérés valódi célja egyezni fog a kliens eredeti kérésének céljával, miel˝ott az a proxyhoz került volna. A TransparentRouter tökéletesen ellátja ezt a feladatot, így nem kell változtatnunk az alapértelmezett beállításokon. A fent említett szolgáltatással kéréseket továbbíthatunk az intranetr˝ol az internetre és a DMZ-be, így az utóbbi két zónát célként engedélyezhetjük a Zorppal. A szolgáltatás nem kezdi el automatikusan figyelni a forgalmat a hálózati interfészen, mivel ezt a feladatot a „Listener” nevu ˝ Zorp komponens végzi. Egy listenernek két fontos jellemz˝oje van: a hálózati cím, amin a forgalmat figyeli és egy szolgáltatás, amit minden kapcsolat létesítéskor el kell indítania. Hozzunk létre egy új listenert, ami a 10.0.0.254 IP címhez van rendelve az 50080 porton, és a 4.14. ábrán látott módon küldi át a kapcsolatot az intra_HTTP szolgáltatásnak.
60
4. FEJEZET. BEÁLLÍTÁS
4.14. ábra. Listener készítése
Az el˝obb manuálisan hoztunk létre egy szolgáltatást, és a hozzá tartozó listenert. Most megnézzük, hogyan lehet ezt egyszerubben ˝ megoldani, a kész szolgáltatás minták segítségével. A szolgáltatás minta könnyen felhasználható formában tartalmazza egy szolgáltatás gerincét, így annyi marad a feladatunk, hogy kiegészítsük a legszükségesebb információkkal, a többir˝ol a zui gondoskodik. Az el˝ore meghatározott szolgáltatás minták eléréséhez meg kell nyomnunk a Predefined gombot amit az Instance szerkeszt˝o ablakban találunk (4.15. ábra). Az el˝ore meghatározott proxyk listáját és leírásukat a E függelék tartalmazza. A listán szerepl˝o elemekhez tartozik egy rövid leírás, és a Súgó menü (4.16. ábra) alatt részletesebb leírásukhoz is hozzáférhetünk. Ha kiválasztottunk egy szolgáltatást, a zui kérni fogja, hogy adjuk meg a szolgáltatás nevét, illetve egy IP címet, amihez kötheti (4.17 ábra). Ezután a zui befejezi a szolgáltatás készítését, és listener eszközöket rendel hozzá, melyek a szolgáltatást a szokásos porthoz kötik. Készítsük el az zónáinknak szánt szolgáltatásokat, majd ha végeztünk, ˝ szerkeszt˝o ablakában. A zui ekkor nyomjuk meg a Generate gombot a tuzfal két fájlnevet fog kérni, melyekbe elmentheti az el˝obb generált konfigurációkat: ezek az instances.conf és a policy.py. Ha a Generate gomb megnyomása után megnyomjuk az Enter -t a commandZUI alapértelmezetten ezekbe a fájlokba menti a konfigurációkat. Miután mindkét fájlt elmentettük, a zorpctl start paranccsal elindíthatjuk Zorp alkalmazásainkat. A zui eredeti bináris formájában is megtartja policynkat, a /etc/zorp/zui.db fájlban. Elmenthetjük a beállításokat a Save gomb
4.6. A ZORP KONFIGURÁLÁSA A ZUI SEGÍTSÉGÉVEL
4.15. ábra. Egy el˝ore meghatározott proxy beillesztése
4.16. ábra. El˝ore meghatározott proxyk részletes leírása
61
62
4. FEJEZET. BEÁLLÍTÁS
4.17. ábra. El˝ore meghatározott proxy készítése
megnyomásával, de a program automatikusan elmenti o˝ ket a zui-ból való kilépéskor is.
5. fejezet
Beállítások haladóknak Most, hogy már ismerjük a zui-t, áttekintjük a zui által generált konfigurációt, és igényeinknek megfelel˝oen finomítjuk a beállításokat. A Zorp konfigurációs állománya, a policy, standard Python parancsokból áll, melyek a Zorp mag és az alkalmazási osztályok szolgáltatásait veszik igénybe. Ebben a fejezetben röviden áttekintjük a Python nyelvet, majd lépésr˝ol-lépésre átvesszük a policy struktúra felépítését.
5.1. A Python áttekintése A Python egy objektumorientált, jól alkalmazható programozási nyelv, ami letisztult szintakszisáról és következetes kialakításáról ismert. Ebben a részben a policy létrehozásával foglalkozunk, így aki kimerít˝obben akar a Pythonnal foglalkozni, az a http://www.python.org/ oldalon találhat további részleteket.
5.1.1. Modulok és Csomagok A python kód egyes részei (változók, funkciók, osztályok) modulokba rendezhet˝oek. Ahhoz, hogy a modulból használhassunk valamit, az import kulcsszóval importálnunk kell azt.
import HttpProxy 5.1. Mintaátvétel parancs A fenti import parancs hivatkozást hoz létre a HttpProxy modulra. A modul részeihez a következ˝o formában férhetünk hozzá: HttpProxy.HTTP_REQ_POLICY (a modul neve után egy pont, majd a megfelel˝o attribútum).
63
64
5. FEJEZET. BEÁLLÍTÁSOK HALADÓKNAK
A modulokat csomagokba csoportosíthatjuk, ami tulajdonképpen egy modulokból álló modul lesz. A csomagban egy almodulhoz a következ˝o paranccsal férhetünk hozzá: Zorp.HttpProxy, feltéve, hogy van Zorp.Http nevu ˝ csomagunk, és abban egy HttpProxy nevu ˝ almodul. A Zorp osztályokat a Zorp nevu ˝ csomag tartalmazza. A csomagnak több almodulja is van: Core: a Zorp közös változóit tartalmazza, minden core szimbólumot importálhatunk a from Zorp.Core import * paranccsal. Proxyk: minden proxy modulhoz létezik egy hozzárendelt Python modul, ami exportál egy interfészt a policy rétegre. A modulok általában a támogatott protokoll után vannak elnevezve (a név els˝o betujét ˝ nagy betuvel ˝ írjuk). Például a HTTP proxy modulja a Http. A HTTP-hez kapcsolódó összes szimbólum importálásához használjuk a from from Zorp.Http import * parancsot. Egyéb core modulok: - a Core modul csak helyet biztosít a core szimbólumok importálásához, bár a gyakorlatban a szimbólumok a megfelel˝o core modulokban vannak definiálva. Minden router osztály például a Router modulban van definiálva. A standard Zorp modulokról és osztályokról a "Python reference" fejezetben olvashatunk, a Zorp Referenciakönyvben. Hogy elkerüljük a teljes hivatkozások alkalmazását változók esetében (amikor minden modulnév szerepel a változók hivatkozásaihoz), használjunk nevesített importokat. Egy nevesített import nemcsak változóként importálja a modul nevét, hanem a helyi névtérbe1 helyezi az összes - az adott modul által meghatározott - szimbólumot is. A nevesített importokhoz használt parancsot az 5.2. példában találhatjuk meg .
from Zorp.Http import HttpProxy 5.2. Nevesített import Így a HttpProxy változó a helyi névtérbe importálódik, azaz ezentúl írhatunk egyszeruen ˝ HttpProxyt a policy-nkba, a hosszú Zorp.HttpProxy helyett.
5.1.2. Parancsok A pythonban nem pontosvessz˝ovel kell befejezni egy parancsot, itt általában a sor befejezése zárja azt le. A parancsot folytathatjuk a következ˝o sorban, ha az els˝o sor végére beiktatunk egy „ ” karaktert. 1
namespace
5.1. A PYTHON ÁTTEKINTÉSE
65
Az összetett parancsoknál, mint a while vagy az if, használjuk az 5.3 példában látható indentálást a beágyazott parancs jelölésére.
if self.request_url == "http://www.balabit.hu/": return Z_ACCEPT return Z_REJECT 5.3. Beágyazott parancs A bels˝o block kezdetét az els˝o sor végén található kett˝ospont, míg a befejezését bekezdés indentálásának egy szinttel feljebb lépése jelzi.
5.1.3. Változók A Pythonban a változókat nem kell el˝ore deklarálni, típusuk dinamikusan a használat során, egy érték-hozzárendelés elvégzése után d˝ol el. Ha a kód egy nem létez˝o változóra próbál hivatkozni, megjelenik a NameError hibaüzenet (exception).
5.1.4. Függvények meghatározása Függvényeket a def kulcsszóval határozhatunk meg (5.4. sz. példa).
def filterURL(self, method, url, version): return Z_ACCEPT 5.4. Minta egy függvény meghatározására A filterURL függvény végrehajtása során a self, method, url és version helyi változók lesznek meghatározva. Az ismertetett függvényt két formában írhatjuk le: – Kötött sorrendu ˝ állapot argumentumokkal: filterURL(self, ’GET’, ’http://www.balabit.hu/’, ’http/1.1’) – Vagy kulcsszó argumentumokként: filterURL(self, url=’http://www.balabit.hu/’, version=’http/1.1’,method=’GET’) Mindkét megoldás ugyanazokat az argumentumokat adja át a filterURL függvénynek.
66
5. FEJEZET. BEÁLLÍTÁSOK HALADÓKNAK
5.1.5. Kivételek/hibák A kivétel (exception) valamilyen hiba létét jelöli. Ha hiba történik, az exception felfüggeszti a kód végrehajtását, a program átugrik a kivételt kezel˝o blokkhoz. Ha a kivétel nem kezelhet˝o, a program leáll. A Zorp mindig kezeli a kivételeket, még akkor is, ha a Python része nem. A rendszernaplóban rögzíti a kivételeket, és visszakeres oda, ahol a hiba történt, így könnyebbé teszi a hibakeresést
5.1.6. Python osztályok A Python osztályai más nyelvek osztályaihoz hasonlóan attribútumokat (állapot/state) és függvényeket (módszerek/method) használnak, hogy beavatkozhassanak az állapot információba.
class MyHttp(HttpProxy): def config(self): HttpProxy.config(self) self.transparent_mode = TRUE 5.5. Minta Python osztály Az 5.5 példa demonstrálja az osztályok és metódusok használatát Pythonon belül. Ahogy a példában is láthatjuk, a self paramétert ki kell tennünk, a C++ -szal ellentétben, ahol a this megjelölés implicit átkerül a funkciókhoz. Az alaposztályokat az adott osztály neve után, zárójelben határozhatjuk meg. Argumentumokként megadott konstruktor paraméterekkel meghatározva, az osztályok különböz˝o példányait hozhatjuk létre. Egy osztály konstruktorának neve __init__, a destruktoré __del__.
5.2. A Zorp osztályainak áttekintése A policy megírása általában a megfelel˝o paraméterek átadását jelenti az el˝ore meghatározott Zorp osztályoknak, így el˝oször át kell néznünk, mi micsoda a Zorpban. Listener: a hálózati interfészen való figyelésért, és elfogadott kapcsolat esetén a kért szolgáltatás elindításáért felel˝os. Receiver: ez határozza meg a datagram alapú protokollok legf˝obb hozzáférési pontját. Ez az osztály Receive-vel felszerelt datagram socketeken hallgatózik, és a megfelel˝o kapcsolat követ˝o modulnak (Connection Tracking Module) adja át o˝ ket.
5.2. A ZORP OSZTÁLYAINAK ÁTTEKINTÉSE
67
Service: olyan osztály, mely a tuzfal ˝ által a klienseknek kínált szolgáltatást tömörít magába. A szolgáltatás egy egyedi névb˝ol (amit a log üzenetekben és a hozzáférés ellen˝orzés során használ), egy, a szolgáltatás kezdetekor alkalmazott proxy osztályból, a szerverrel való kapcsolatért felel˝os routerb˝ol és a felhasználó hitelesítésére használt authentikációs programból áll. Router: felel˝os azért, hogy megállapítsa, melyik szerver címre kapcsolódjunk. Számos különböz˝o fajta router létezik, mindegyik más módszert használ a szerver cím meghatározására. A TransparentRouter az eredeti célra kapcsolódik (f˝oleg a transzparens proxyknál használjuk), a DirectedRouter egy el˝ore meghatározott fix címre kapcsolódik (kívülr˝ol nem meghatározható címu ˝ hostok irányába tartó közvetlen forgalom esetén). A routerekr˝ol b˝ovebben olvashatunk a Zorp Referenciakönyv Router.py részében. Chainer: a Zorp egyik bels˝o osztálya, proxy stackeléskor a proxykat szül˝ojükhöz kapcsolja, a fels˝o szinteken muköd˝ ˝ o proxyknak pedig kapcsolatot nyit a szerverrel. A chainerekr˝ol további információt a Zorp Referenciakönyvben Chainer.py alatt olvashatunk. Proxy osztály: A proxy osztályok segítségével lehet beállítani ill. használni a C-ben írt protokoll proxy-kat. Mint általában az OOP nyelvekben, itt is kialakíthatjuk személyre szabott osztályainkat az el˝ore megadott mintákból, továbbá kib˝ovíthetjük funkcióikat és átalakíthatjuk viselkedésüket. Zóna: és részei szolgálnak alapul a kapcsolat szinten történ˝o hozzáférés elleno˝ rzésnek. Minden zóna IP címek csoportjából áll, a tuzfallal ˝ kapcsolatban álló minden végpont (kliens vagy szerver) pontosan egy zóna eleme. (A rá legjobban illeszked˝o IP címtartománnyal rendelkez˝o zónáé.)
def http(): # the next line defines a new service named "intra_HTTP" # using HttpProxy, and connecting to the client’s original # destination (TransparentRouter). Service("intra_HTTP", HttpProxy, router=TransparentRouter()) # The following line binds the intra_HTTP service to a listener # bound to 10.0.0.1:50080, where the packet filter redirects # sessions. Listener(SockAddrInet("10.0.0.1", 50080), "intra_HTTP") 5.6. Egy szolgáltatás, és a hozzá tartozó listener létesítése
68
5. FEJEZET. BEÁLLÍTÁSOK HALADÓKNAK
5.3. Minta Policy készítése Ebben a részben egy fiktív cég policy mintáját határozzuk meg. A példában szerepl˝o cégnek a következ˝o a hálózati felépítése: – intranet nem routolható IP címekkel (10.0.0.0/8); egy MGMT nevu ˝ alzónával. Ezt a címtartományt a hálózati- és rendszeradminisztrátorok használják, így innen több szolgáltatás érhet˝o el. – A küls˝o hostoknak HTTP és FTP szolgáltatást nyújtó DMZ nem routolható IP címekkel. (192.168.0.0/24) – Internet hozzáférés bérelt vonalról, a küls˝o IP cím 1.2.3.5 (természetesen ez sem routolható, csak a példa kedvéért tettük ide). A bérelt vonal összekapcsolja a tuzfalat ˝ az internet szolgáltatóval, közvetlen IP eléréssel. Az intranet és a DMZ a kiválasztott interfészeken keresztül kapcsolódnak be, a 2.1. ábrán (22. oldal) bemutatott módon.
5.3.1. A hozzáférés ellen˝ orzés alapjai: a zónák A tuzfal ˝ környezetét InetZone parancsokkal határozhatjuk meg, ahogy azt az 5.7. példa is mutatja.
InetZone(’intranet’, ’10.0.0.0/8’, inbound_services=["*"], outbound_services=["*"]) InetZone(’mgmt’, ’10.0.0.224/28’, inbound_services=["*"], outbound_services=["*"], admin_parent=’intranet’) InetZone(’DMZ’, ’192.168.0.0/24’, inbound_services=["*"], outbound_services=["*"]) InetZone(’internet’, ’0.0.0.0/0’, inbound_services=["*"], outbound_services=["*"]) 5.7. Zónák kialakítása Ebben a példában 4 zónát határoztunk meg: 1. Intranet 10.0.0.0/8 címtartománnyal,
5.3. MINTA POLICY KÉSZÍTÉSE
69
2. MGMT, az intranet alzónája. Az „admin parent” reláció azt jelenti, hogy az alzóna átveszi szül˝ojének biztonsági tulajdonságait (példánkban inbound_services és outbound_services). 3. DMZ 192.168.0.0/24 címtartománnyal 4. internet 0.0.0.0/0. A példában csillagot használtunk a kifelé és befelé irányuló szolgáltatásoknál, ez az összes szolgáltatást jelenti. Általában a csillagok helyére csak az engedélyezni kívánt szolgáltatások neveit írjuk. Az 5.8. példában http és ftp hozzáférést engedélyezünk az internet és a DMZ között.
InetZone(’DMZ’, ’192.168.0.0/24’, inbound_services=[ ’inter_HTTP_dmz", ’inter_FTP_dmz’ ], outbound_services=["*"]) InetZone(’internet’, ’0.0.0.0/0’, inbound_services=["*"], outbound_services=[ ’inter_HTTP_dmz’, ’inter_FTP_dmz’]) 5.8. Zónák kialakítása
5.3.2. A Zorp alkalmazásokat indító funkciók Használhatjuk ugyanazt a policy fájlt minden Zorp példányunkhoz. Minden példány azonos import parancsokat, zónákat és proxy osztályokat használ. Az egyetlen különbség, a különböz˝o indító (init) függvényben rejlik. Az init függvény feladata a „Service” definíciók felállítása és a „Listener”-ek elindítása, így a különböz˝o példányok az általuk nyújtott szolgáltatások és listenerek csoportjában különböznek. Az init függvény neve megegyezik a példány nevével. Ennek megfelel˝oen, ha van egy intra_http nevu ˝ példányunk, a Zorp core az intra_http nevu ˝ funkciót fogja lekérni (5.9. példa).
5.3.3. Szolgáltatás meghatározása Szolgáltatás az, amit a Zorp nyújt a kapcsolódó hálózatoknak. Egy kapcsolat elfogadásakor a szolgáltatás rögtön elindul.
70
5. FEJEZET. BEÁLLÍTÁSOK HALADÓKNAK
def http(): Service("http", HttpProxy) Listener(SockAddrInet(’192.168.0.1’, 50080), "http") 5.9. Példa az init függvényre def intra_http(): Service("intra_http", HttpProxyNonTransparent, InbandRouter()) 5.10. Szolgáltatás létrehozása Az 5.10. példa az intra_http nevu ˝ Zorp példány init függvényét mutatja be. A szolgáltatás ID-je intra_http, és a HttpProxyNonTransparent proxy modult indítja el.
5.3.4. Listener létesítése A listener egy adott címen figyel és elfogadott kapcsolat esetén egy bizonyos szolgáltatás elindításáért felel˝os. Az 5.11 példában láthatjuk, hogyan állítsuk fel az intra_http szolgáltatást indító listener-t a 10.0.0.1:50080-n.
def intra_http(): Service("intra_http", HttpProxyNonTransparent, InbandRouter()) Listener(SockAddrInet(’10.0.0.1’, 50080), "intra_http") 5.11. Listener létesítése
5.3.5. Proxyk személyreszabása Egy proxy feladatait úgy terjeszthetjük ki, hogy egy egyénileg kialakított proxy osztályt csinálunk az eredetib˝ol.
5.3. MINTA POLICY KÉSZÍTÉSE
71
Az 5.12. példában egy MyHttp nevu ˝ új proxy osztályt készítettünk, a HttpProxy alapján, felülírva az alapbeállításokat, és átállítva több HTTP specifikus tulajdonságát. Arról, hogy az egyes proxyk milyen tulajdonságaikat exportálják, a „Python reference” részben olvashatunk a Zorp Referenciakönyvben.
class MyHttp(HttpProxy): def config(self): HttpProxy.config(self) self.transparent_mode = FALSE self.request["PUT"] = (HTTP_REQ_ACCEPT) 5.12. Proxy osztályok személyre szabása
5.3.6. UDP szolgáltatás felállítása A TCP és UDP szolgáltatások között annyi a különbség, hogy az UDP esetében „Listener” helyett „Receiver”-re van szükség, és olyan proxy modult kell használnunk, ami támogatja datagram alapú kapcsolatokat (ilyen a PlugProxy vagy a RadiusProxy).
72
5. FEJEZET. BEÁLLÍTÁSOK HALADÓKNAK
6. fejezet
Üzemeltetés és karbantartás Ebben a fejezetben néhány általános tippet adunk a tuzfal ˝ kezelésével és karbantartásával kapcsolatban.
6.1. Futtatható alkalmazások Mivel a tuzfal ˝ esetében a hoszt- és a hálózat biztonsága is fontos, ezért nagyon lényeges, hogy csak a legszükségesebb programokat futtassuk. Ez az útmutató segítséget nyújt a telepített program meger˝osítésére. A következ˝o listában felsorolt szolgáltatásokat érdemes els˝ore leállítani: portmap: A portmap daemon feltérképezi a Sun RPC szolgáltatásokat, majd ezekhez dinamikus port számokat rendel. Ha elindul egy RPC-t engedélyez˝o daemon, rögtön regisztrálja magát a portmapen, ami cserébe hozzárendel egy port számot a szolgáltatáshoz. Mivel gyakoriak a biztonsági problémák a portmappel, ezért határozottan nem ajánljuk a használatát. inetd: A inetd daemon egy internetes szuperszerver, ami figyeli a forgalmat a kijelölt portokon és szerver programokat indít, ha kapcsolatlétesítési kérelem fut be a figyelt portok egyikére. Az inetd támogatja a TCP, UDP és RPC alapú szolgáltatásokat. Az inetd-re az esetek többségében nincs szükség, azok a szolgáltatások, melyekre a tuzfalnak ˝ szüksége van, általában önálló daemonokként futnak. daemonok: daemonok - azokat a programokat, melyek folyamatosan futva hálózati socketeken figyelik a forgalmat, daemonoknak nevezzük. Nincs szükségük a portmapre vagy az inetd-re a feladatukhoz, ezért bonyolultabbak is. A Zorp tuzfal ˝ legtöbb programja ilyen önálló daemon, mindegyik önmagának határozza meg a címet, ahova köt˝odik.
73
74
6. FEJEZET. ÜZEMELTETÉS ÉS KARBANTARTÁS
Program named ntpd postfix syslog-ng sshd zorp
Description ISC name szerver. Network Time Protocol Daemon. Jól konfigurálható mail kezel˝o program. a syslogd egy lehetséges alkalmazása, továbbfejlesztett szurési ˝ kapacitással. a Secure Shell protokoll egy alkalmazása, küls˝o, kódolt belépéshez használjuk. a tuzfal. ˝ 6.1. táblázat. A tuzfalhoz ˝ szükséges szoftverek.
Ahhoz, hogy ellen˝orizzük, mely portok vannak nyitva, használhatunk egy hálózati auditáló eszközt, mint az nmap (http://www.nmap.org), vagy megnézhetjük a netstat parancs outputját (ld. 6.1. példa). Starting nmap V. 2.12 by Fyodor ([email protected], www.insecure.org/nmap/) Interesting ports on www.example.com (xxx.xxx.xxx.xxx): Port State Protocol Service 21 open tcp ftp 22 open tcp ssh 25 open tcp smtp 80 open tcp http 110 open tcp pop-3 443 open tcp https 444 open tcp snpp 873 open tcp unknown 3128 open tcp squid-http 4557 open tcp fax 4559 open tcp hylafax Nmap run completed -- 1 IP address (1 host up) scanned in 33 seconds
6.1. Netstat output minta A tuzfalon ˝ általában futtatott daemonok felsorolását a 6.1. sz. táblázat tartalmazza.
6.2. A telepítés tesztje Ha befejeztük a tuzfal ˝ konfigurálását, ellen˝oriznünk kell az eredeti rendszerterv alapján, hogy valóban engedélyeztük-e a szükséges szolgáltatásokat, de azt is tesztelnünk kell, hogy az engedélyezetteken kívül felesleges szolgáltatások
˝ 6.3. INTEGRITÁS ELLENORZÉSE
75
nincsenek-e? Ebben az olyan hálózati auditáló segédeszközök, mint az nmap1 tudnak segíteni.
6.3. Integritás ellen˝ orzése Egy behatolás után általában módosított fájlok maradnak a rendszerünkön (trójai faló programok, megváltoztatott jelszavak, stb.), így rendszeresen elleno˝ riznünk kell, hogy a telepített fájlok változtak-e. Számos programmal tudjuk fájl alapon ellen˝orizni a rendszer integritását, ezek közül az egyik legismertebb a tripwire2 (http://www.tripwire.org/).
6.4. A rendszernapló ellen˝ orzése Érdemes rendszeresen ellen˝orizni a rendszernaplót, mert fontos információkat tartalmazhat a rendszer állapotáról (a merevlemez megtelt, kernel üzenetek alacsony szintu ˝ driver problémákról stb.) vagy egy behatolásról (elutasított csomagok, elutasított szolgáltatásra irányuló kérések, protokoll hibák, stb.). A megterhelt tuzfalak ˝ rendszernaplói hatalmasra dagadhatnak, ami lehetetlenné teszi a logok kézi ellen˝orzését. Használjunk inkább egy olyan programot, ami automatikusan el˝ore feldolgozza az anyagot, és csak a fontos üzeneteket hagyja meg. Az ember csak az így keletkezett anyagot nézi át. Az el˝ozetes feldolgozáshoz jól használható eszköz a logcheck (http://www.psionic.com/ abacus/logcheck/). Amellett, hogy a naplófájlokat tároló rendszer a tuzfalon ˝ logol, a log üzeneteket továbbítsuk egy hostra az egyik védett zónában (a syslog-ng segítségével), így ha a rendszerbe sikerült is behatolnia a crackernek, a logfájlokat nem módosíthatja (eltüntetve ezzel behatolásának nyomait).
6.5. Szolgáltatásaink követése Ahogy a tuzfalnak ˝ is muködnie ˝ kell a nap 24 órájában, a hét minden napján, úgy a szolgáltatások elérhet˝oségét is figyelemmel kell követnünk. Sok ingyenes, jól használható megoldás létezik erre, mint Netsaint (http://www.netsaint. org/) vagy a BigBrother3 (http://www.bb4.com/). 1 Az nmap csomag nem része a Z ORP GPL UHU-nak. Természetesen lehet˝ oség van az utólagos telepítésre, ahogy ez a G.5.2. pontban szerepel is, de felhívjuk a figyelmet az ugyanitt szerepl˝o figyelmeztetésre: bármilyen csomag telepítése el˝ott meg kell gy˝oz˝odni arról, hogy az adott program(ok) nem hordoz(nak)-e biztonsági kockázatot! 2 A tripwire szintén nem része a Z ORP GPL UHU-nak 3 Egyik program sem része a Z ORP GPL UHU-nak.
76
6. FEJEZET. ÜZEMELTETÉS ÉS KARBANTARTÁS
6.6. A biztonságtechnika sebezhet˝ o pontjai Mivel minden szoftver csomag tartalmazhat bugokat, nagyon fontos, hogy kövessük figyelemmel a biztonságtechnikai kérdésekkel foglalkozó fórumokat, a programterjeszt˝ok híreit, és telepítsük az ezekben ajánlott patcheket, melyek kijavítják a sebezhet˝o pontokat. Itt is nyomatékosan felhívjuk a figyelmet: egy-egy kiegészítés, javítás telepítése el˝ott gy˝oz˝odjünk meg arr˝ol, hogy a tuzfal ˝ biztonsága nem szenved-e csorbát! A következ˝o listán a legjobb biztonságtechnikai kérdésekkel foglalkozó fórumokat, és elérhet˝oségüket soroljuk fel: SecurityFocus.com: minden elképzelhet˝o sebezhet˝o pontról találunk itt információt, patchekkel vagy értekezésekkel a témában. bugtraq levelezési lista: a SecurityFocus.com-nál hostolt biztonságtechnikai levelezési lista, a témával kapcsolatos tanácsok, közleményeket ide szokták postázni. A lista címe [email protected]. Terjeszt˝o szerinti fórumok: a legtöbb terjeszt˝onek van egy közlemény és bugfix archívuma. Látogassuk meg az adott terjeszt˝o honlapját további részletekért. A teljes biztonság eléréséhez fontos, hogy telepítsük a tuzfal ˝ mögötti szoftvereink biztonsági frissítéseit. Ennek figyeléséhez segítséget nyújt az F. függelékben szerepl˝o felsorolás.
A. Függelék
Kernel patchek A függelékben összefoglaljuk a Linux kernelhez alkalmazott patch-eket, ezek segítségével jobb teljesítményt és nagyobb biztonságot érhetünk el. TProxy - a patch segítségével Transparent Proxy támogatással egészíthetjük ki a 2.4-es Linux kerneleket. http://www.balabit.hu. GRSecurity - a patch segítségével megnövelhetjük a kernel által nyújtott biztonsági funkciókat. (pl: programindítások naplózása). http://www. grsecurity.net/. FreeSWAN - IPSec implementáció a Linux kernel számára, segítségével lehet˝oség nyílik virtuális magánhálózatok(VPN) létrehozására. http://www. freeswan.org/
77
78
A. FÜGGELÉK. KERNEL PATCHEK
B. Függelék
Szolgáltatás mátrix példa A B.1. sz. ábrán látható mátrix a zónákat és a közöttük engedélyezett forgalmat illusztrálja. Ha a szül˝o és gyermek zónája fizikailag azonos hálózaton vannak, nincs értelme köztük szabályokat meghatározni, mivel a forgalmuk nem keresztezi a tuzfalat. ˝ Megjegyezzük, hogy két zóna között fennállhat a szül˝o-gyermek viszony akkor is, ha fizikailag két külön hálózaton vannak. A zárójelekben azok a portok vannak megadva, ahol a szolgáltatás rákapcsolódik a tuzfalra. ˝
79
80
B. FÜGGELÉK. SZOLGÁLTATÁS MÁTRIX PÉLDA
TO FROM
IntraNet
MGMT Zone
DMZ
10.0.0.0/24
10.0.0.244/28
192.168.0.1/24
eth0
eth0
eth1
IntraNet child: MGMT MGMT Zone
InterNet Firewall 0.0.0.0/0 eth2
10.0.0.254 192.168.0.254 1.2.3.4
http (50080) https (50443) ftp full (50020, 50021, 40000-41000)
http (51080) https (51443) pop3 (51110)* pop3s (51995) ftp download-only (51020, 51021, 40000-41000) irc(51667) nntp(51119)
dns (53) smtp (25) ntp(123)
+ssh (50022)
+ssh (51022)
+ssh (22)
http (52080)
smtp (25) dns (53) syslog (514)
parent: IntraNet DMZ
smtp (25) dns (53)
http (53080) https (52443) ftp anonymous only download only (53020, 53021, 40000-41000)
InterNet
syslog (514)
dns zonetransfer (53)
smtp (25) dns (53)
Firewall
B.1. ábra. Szabály-mátrix minta
C. Függelék
IPTables beállítás példa A függelékben látható példa a csomagszur˝ ˝ o konfigurációs fájlokat tartalmazza. El˝oször a iptables.conf.var fájlt mutatjuk be. Ez tartalmazza a iptables.conf.in fájlban használt makrókat. Az alkalmazott szintakszis a „C” programozási nyelvnek felel meg: // // // // // // // // //
Copyright (c) 2000-2001 BalaBit IT Ltd. All rights reserved. $Id: appendix_iptables.tex,v 1.3 2003/01/07 15:26:01 attila Exp $ Sample ipchains.var file. You can include C-like #define statements here to define symbolic names for IP addresses, ports and such.
#define #define #define #define
IF_INTRA eth0 IP_INTRA 10.0.0.254/32 NET_INTRA 10.0.0.0/8 BC_INTRA 10.0.0.255/32
#define #define #define #define
IF_DMZ eth1 IP_DMZ 192.168.0.254/32 NET_DMZ 192.168.0.0/24 BC_DMZ 192.168.0.255/32
#define #define #define #define
IF_INTER eth2 IP_INTER 1.2.3.4/32 NET_INTER 1.2.3.4/24 BC_INTER 1.2.3.4.255/32
81
82
C. FÜGGELÉK. IPTABLES BEÁLLÍTÁS PÉLDA
#define NET_MGMT 10.0.0.224/28 A következ˝oben látható a példa iptables.conf.in fájl. Megértéséhez segítséget nyújt a 4.4. sz. részben leírtak. *tproxy :PREROUTING ACCEPT :OUTPUT ACCEPT :PRinter :PRintra :PRdmz -A PREROUTING -p tcp ! --syn -j DROP -A PREROUTING -i IF_INTRA -d ! IP_INTRA -j PRintra -A PREROUTING -i IF_DMZ -d ! IP_DMZ -j PRdmz //PRintra -A PRintra -d NET_DMZ 80 -p tcp -j TPROXY --on-port 50080 -A PRintra -d 0/0 80 -p tcp -j TPROXY --on-port 51080 -A PRintra -d NET_DMZ 443 -p tcp -j TPROXY --on-port 50443 -A PRintra -d 0/0 443 -p tcp -j TPROXY --on-port 51443 -A PRintra -d 0/0 110 -p tcp -j TPROXY --on-port 51110 -A PRintra -d 0/0 995 -p tcp -j TPROXY --on-port 51995 -A PRintra -d 0/0 6667 -p tcp -j TPROXY --on-port 51667 -A PRintra -d 0/0 119 -p tcp -j TPROXY --on-port 51119 -A PRintra -d NET_DMZ 21 -p tcp -j TPROXY --on-port 50021 -A PRintra -d 0/0 22 -s NET_MGMT -p tcp -j TPROXY --on-port 50022 -A PRintra -d NET_DMZ 22 -s NET_MGMT -p tcp -j TPROXY --on-port 51022 //PRdmz -A INdmz -d 0/0 80 -p tcp -j TPROXY --on-port 52080 COMMIT *filter :INPUT DROP :FORWARD DROP :OUTPUT ACCEPT :junk :spoof :LOter :LOtra :LOdmz
83 :LOlo -A forward -j DENY -l -A -A -A -A -A -A -A -A
input input input input input input input input
-j spoof -j junk -i lo -j LOlo ! -y -p tcp -j ACCEPT -i IF_INTRA -d IP_INTRA -j LOtra -i IF_DMZ -d IP_DMZ -j LOdmz -i IF_INTER -d IP_INTER -j LOter -j DENY -l
-A -A -A -A -A -A -A
spoof spoof spoof spoof spoof spoof spoof
-i IF_INTRA ! -s NET_INTRA -j DENY -l ! -i IF_INTRA -s NET_INTRA -j DENY -l -i IF_DMZ ! -s NET_DMZ -j DENY -l ! -i IF_DMZ -s NET_DMZ -j DENY -l ! -i IF_INTER -s NET_INTER -j DENY -l ! -i lo -s 127.0.0.0/8 -j DENY -l -j RETURN
-A -A -A -A -A
junk junk junk junk junk
-i -i -d -d -j
IF_INTRA -d BC_INTRA 137:139 -p udp -j DENY IF_DMZ -d BC_DMZ 137:139 -p udp -j DENY 255.255.255.255/32 68 -s 0.0.0.0/32 67 -p udp -j DENY 224.0.0.0/10 -j DENY RETURN
-A LOlo -j LOlo -l -A -A -A -A
LOtra LOtra LOtra LOtra
--dport --dport --dport -j DENY
53 -p udp -j ACCEPT 25 -p tcp -j ACCEPT 123 -p tcp -j ACCEPT -l
-A -A -A -A
LOdmz LOdmz LOdmz LOdmz
--dport --dport --dport -j DENY
53 -p udp -j ACCEPT 25 -p tcp -j ACCEPT 514 -p udp -j ACCEPT -l
-A -A -A -A
LOter LOter LOter LOter
--dport --dport --dport --dport
80 -p tcp -j REDIRECT 53080 443 -p tcp -j REDIRECT 52443 21 -p tcp -j REDIRECT 53021 53 -p udp -j ACCEPT
84
C. FÜGGELÉK. IPTABLES BEÁLLÍTÁS PÉLDA
-A LOter --dport 53 -p tcp -j ACCEPT -A LOter --dport 25 -p tcp -j ACCEPT -A LOter -j DENY -l
D. Függelék
Zorp beállítás példa Ez a rész a B függelékben található policy alapján összeállított policy.py-t ismerteti. A fájlt a zui generálja, aminek alkalmazását a 4.6. sz. rész írja le. Az 5.3. sz. részben találhatók azok az információk, megfontolások, amelyek a végleges policy.py kialakításának alapját képezi. # Zorp policy, automatically generated by zui 1.4.0 # import section from Zorp.Core import * from Zorp.Plug import * from Zorp.Ftp import * from Zorp.Http import * from Zorp.Pssl import * from Zorp.Pop3 import * from Zorp.Nntp import * # end of import section # start of global section Zorp.firewall_name = ’zorp@firewall’ InetZone("mgmt", "10.0.0.224/28", inbound_services=[], outbound_services=[’intra_SSH_dmz’, ’mgmt_SSH_inter’, ’mgmt_SSH_dmz’]) InetZone("internet", "0.0.0.0/0", inbound_services=[’mgmt_SSH_inter’, ’intra_HTTP_inter’, ’intra_POP3_inter’, ’intra_POP3S_inter’, ’intra_IRC_inter’, ’intra_HTTPS_inter’,
85
86
D. FÜGGELÉK. ZORP BEÁLLÍTÁS PÉLDA
’intra_FTP_inter’, ’dmz_HTTP_inter’, ’intra_NNTP_inter’], outbound_services=[’inter_HTTP_dmz’, ’inter_FTP_dmz’, ’inter_HTTPS_dmz’]) InetZone("dmz", "192.168.0.0/24", inbound_services=[’intra_FTP_dmz’, ’intra_HTTP_dmz’, ’mgmt_SSH_dmz’, ’intra_HTTPS_dmz’, ’inter_HTTP_dmz’, ’inter_HTTPS_dmz’, ’inter_FTP_dmz’], outbound_services=[’dmz_HTTP_inter’]) InetZone("intranet", "10.0.0.0/24", inbound_services=[], outbound_services=[’intra_FTP_dmz’, ’intra_HTTP_dmz’, ’intra_HTTP_inter’, ’intra_HTTPS_dmz’, ’intra_POP3S_inter’, ’intra_IRC_inter’, ’intra_HTTPS_inter’, ’intra_FTP_inter’, ’intra_POP3_inter’, ’intra_NNTP_inter’]) class HttpsProxy(PsslProxy): class EmbeddedHttpProxy(HttpProxy): def config(self): HttpProxy.config(self) def config(self): PsslProxy.config(self) self.client_need_ssl = TRUE self.client_key = ’/etc/zorp/https/zorp.key’ self.client_cert = ’/etc/zorp/https/zorp.crt’ self.server_need_ssl = TRUE self.server_ca_directory = ’/etc/zorp/https/ca.crt’ self.server_crl_directory = ’/etc/zorp/https/ca.crl’ self.server_verify_type = SSL_VERIFY_REQUIRED_TRUSTED self.stack_proxy = self.EmbeddedHttpProxy # end of global section # start of instance section def mgmt(): Service("mgmt_SSH_inter", PlugProxy, router=TransparentRouter()) Service("mgmt_SSH_dmz", PlugProxy, router=TransparentRouter())
87
Listener(SockAddrInet(’10.0.0.254’, 50022), "mgmt_SSH_dmz") Listener(SockAddrInet(’10.0.0.254’, 51022), "mgmt_SSH_inter") def intra(): Service("intra_FTP_dmz", FtpProxyAllow, router=TransparentRouter()) Service("intra_HTTP_dmz", HttpProxy, router=TransparentRouter()) Service("intra_HTTP_inter", HttpProxy, router=TransparentRouter()) Service("intra_HTTPS_dmz", HttpsProxy, router=TransparentRouter()) Service("intra_POP3_inter", Pop3Proxy, router=TransparentRouter()) Service("intra_IRC_inter", PlugProxy, router=TransparentRouter()) Service("intra_HTTPS_inter", HttpsProxy, router=TransparentRouter()) Service("intra_FTP_inter", FtpProxyMinimal, router=TransparentRouter()) Service("intra_POP3S_inter", PlugProxy, router=TransparentRouter()) Service("intra_NNTP_inter", NntpProxy, router=TransparentRouter()) Listener(SockAddrInet("10.0.0.254", Listener(SockAddrInet("10.0.0.254", Listener(SockAddrInet("10.0.0.254", Listener(SockAddrInet("10.0.0.254", Listener(SockAddrInet("10.0.0.254", Listener(SockAddrInet("10.0.0.254", Listener(SockAddrInet("10.0.0.254", Listener(SockAddrInet("10.0.0.254", Listener(SockAddrInet("10.0.0.254", Listener(SockAddrInet("10.0.0.254",
50443), 51443), 50080), 50021), 51080), 51110), 51995), 51020), 51667), 51119),
def inter(): Service("inter_HTTP_dmz", HttpProxy, router=TransparentRouter()) Service("inter_FTP_dmz", FtpProxyMinimal, router=TransparentRouter()) Service("inter_HTTPS_dmz", HttpsProxy,
"intra_HTTPS_dmz") "intra_HTTPS_inter") "intra_HTTP_dmz") "intra_FTP_dmz") "intra_HTTP_inter") "intra_POP3_inter") "intra_POP3S_inter") "intra_FTP_inter") "intra_IRC_inter") "intra_NNTP_inter")
88
D. FÜGGELÉK. ZORP BEÁLLÍTÁS PÉLDA router=TransparentRouter())
Listener(SockAddrInet("1.2.3.4", 52443), "inter_HTTPS_dmz") Listener(SockAddrInet(’1.2.3.4’, 53021), "inter_FTP_dmz") Listener(SockAddrInet("1.2.3.4", 53080), "inter_HTTP_dmz") def dmz(): Service("dmz_HTTP_inter", HttpProxy, router=TransparentRouter()) Listener(SockAddrInet(’192.168.0.254’, 50080), "dmz_HTTP_inter") # end of instance section
E. Függelék
El˝ ore meghatározott proxyk listája AIM: AOL Instant Messenger proxy neve: AIMProxy port: 5190 proxy port: 55190 Az AOL Instant Messenger egy interaktív rendszer üzenetváltásra, és fájlmegosztásra. Az AIM az 5190/TCP portot használja a kliens-szerver kommunikációhoz. Megjegyzés: ez a beállítás egy egyszeru ˝ plugot használ a forgalom továbbítására, ezért a tuzfal ˝ nem tudja analizálni a stream tartalmát.
Compuserve: Compuserve protokoll proxy neve: CopmuserveProxy port: 4144 proxy port: 54144 A Compuserve egy független hálózati szolgáltatás, amely a kliens-szerver kapcsolathoz a 4144/TCP portot használja. A proxy alapbeállítása csak a gateway.compuserve.com-ra való csatlakozást engedélyezi. Megjegyzés: ez a beállítás egy egyszeru ˝ plugot használ a forgalom továbbítására, ezért a tuzfal ˝ nem tudja analizálni a stream tartalmát.
89
90
˝ E. FÜGGELÉK. ELORE MEGHATÁROZOTT PROXYK LISTÁJA Cvs: Current Versioning System protokoll proxy neve: CVSProxy port: 2401 proxy port: 52401 A Current Versioning System egy olyan segédeszköz, amely az elosztott, több szerepl˝os szoftver fejlesztésben van segítségünkre. A CVS a 2410/TCP portot használja kommunikációra. Megjegyzés: ez a beállítás egy egyszeru ˝ plugot használ, így a firewall nem tudja analizálni a stream tartalmát. Finger: A felhasználók adatainak keresése proxy neve: FingerProxy port: 79 proxy port: 50079 A Finger a felhasználók adatainak lekérését teszi lehet˝ové Unix rendszereknél. A Finger a 79/TCP portot használja kommunikációra. Jelen beállítás Finger alkalmazás szintu ˝ proxyt használ. FtpAnonRO: Anonymous FTP, csak letöltésre proxy neve: FtpProxyAnonRO port: 21 proxy port: 50021 A File Transfer Protokoll többféle felhasználási módot támogat. Ez a beállítás FTP protokoll proxy-t használ, kizárolag anonymous felhasználót, valamint csak letöltést engedélyez. FtpAnonRW: Anonymous FTP, fel és letöltésre proxy neve: FtpProxyAnonRW port: 21 proxy port: 50021 A File Transfer Protokoll többféle felhasználási módot támogat. Ez a beállítás FTP protokoll proxy-t használ, kizárolag anonymous felhasználót, valamint le és feltöltést egyaránt engedélyez. FtpRO: FullFtp, csak letöltésre proxy neve: FtpProxyRO port: 21 proxy port: 50021 A File Transfer Protokoll többféle felhasználási módot támogat. Ez a beállítás FTP protokoll proxy-t használ, anonymous és valós felhasználót egyaránt, viszont csak letöltést engedélyez.
91 FtpRW: Full Ftp, fel- és letöltésre proxy neve: FtpProxyRW port: 21 proxy port: 50021 A File Transfer Protokoll többféle felhasználási módot támogat. Ez a beállítás FTP protokoll proxy-t használ, anonymous és valós felhasználót, valamint le és feltöltést egyaránt engedélyez.
Gopher: adatkeres˝o szolgáltatás proxy neve: GopherProxy port: 70 proxy port: 50070 A Gopher infoszerver szöveg, grafika, audio és multimédia szolgáltatást biztosít a klienseknek. A Gopher 70/TCP portot használja a kommunikációra. Megjegyzés: ez a beállítás egy egyszeru ˝ plugot használ a forgalom lebonyolítására, ezért a tuzfal ˝ nem tudja analizálni a stream tartalmát.
GWiseClt: Novell Groupwise protokoll proxy neve: GroupwiseClientProxy port: 1677 proxy port: 51677 Groupwise a Novell összevont e-mail-, naptár-, határid˝onapló-, és szövegkezel˝o alkalmazás csoportja. A Groupwise az 1677/TCP portot használja kliens-szerver kommunikációra. Megjegyzés: ez a beállítás egy egyszeru ˝ plugot használ a forgalom lebonyolítására, ezért a tuzfal ˝ nem tudja analizálni a tartalmát.
GWiseSrv: Novell Groupwise protokoll proxy neve: GroupwiseServerproxy port: 7100 proxy port: 57100 Groupwise a Novell összevont e-mail-, naptár-, határid˝onapló-, és szövegkezel˝o alkalmazás csoportja. A Groupwise az 7100/TCP portot használja szerver-szerver kommunikációra. Megjegyzés: ez a beállítás egy egyszeru ˝ plugot használ a forgalom lebonyolítására, ezért a tuzfal ˝ nem tudja analizálni a tartalmát.
92
˝ E. FÜGGELÉK. ELORE MEGHATÁROZOTT PROXYK LISTÁJA HttpTrans: transzparens HTTP proxy neve: HttpProxy port: 80 proxy port: 50080 HTTP proxy a transzparens web eléréshez, alapbeállításokkal. (Transzparens, azaz a klienseken extra beállítást nem igényel.)
HttpNonTrans: nem transzparens HTTP proxy neve: HttpProxyNonTransparent router: InbandRouter nport: 80 proxy port: 50080 Jelen beállítás kizárólag nem transzparens web kéréseket engedélyez HTTP proxy-n. Ennek használatához a klienseket úgy kell konfigurálni, hogy azok a tuzfalat ˝ mint proxy-t használják.
HttpFilterTrans: Transzparens URL filtrált HTTP proxy neve: MyHttpURIFilterProxy port: 80 proxy port: 50080 Jelen beállítás HTTP proxy-t használ a web kérések transzparens közvetítéséhez. A proxy minden bejöv˝o web kérésben szerepl˝o URL-t egy "fekete listához" elleno˝ riz és ez alapján dönti el, hogy a kapcsolat engedélyezet vagy sem. Hozzon létre egy blacklist-http nevu ˝ szöveges állományt, ahol sorolja fel a tiltott URL-eket. (Reguláris kijefezések használhat.) Amennyiben tiltana minden URL-t amelyben a sex szó szerepel, írja be a szót a blacklist állományba. Viszont ha a www.essex.com oldalt ennek ellenére engedélyezni szeretné, hozzon létre egy blacklist-http.ignore állományt és írja bele a www.essex.com URL-t.
93 HttpFilterNonTran: Nem transzparens URL filtrált HTTP proxy neve: MyNontransHttpURIFilterProxy router: InbandRouter nport: 80 proxy port: 50080 Jelen beállítás HTTP proxy-t használ a web kérések nem transzparens közvetítéséhez. A proxy minden bejöv˝o web kérésben szerepl˝o URL-t egy "fekete listához" elleno˝ riz és ez alapján dönti el, hogy a kapcsolat engedélyezet vagy sem. Hozzon létre egy blacklist-http nevu ˝ szöveges állományt, ahol sorolja fel a tiltott URL-eket. (Reguláris kijefezések használhat.) Amennyiben tiltana minden URL-t amelyben a sex szó szerepel, írja be a szót a blacklist állományba. Viszont ha a www.essex.com oldalt ennek ellenére engedélyezni szeretné, hozzon létre egy blacklist-http.ignore állományt és írja bele a www.essex.com URL-t. Megjegyzés: A proxy használatához a kliensek megfelel˝o beállítása szükséges (használják a tuzfalat ˝ mint HTTP proxy-t).
HttpWebdavTrans: transzparens HTTP, WebDAV-al proxy neve: MyHttpWebdavProxy port: 80 proxy port: 50080 Jelen beállítás transzparens web hozzáférést és a WebDAV b˝ovítmények használatát engedélyezi. A WebDAV HTTP protokoll b˝ovítmény segítségével felhasználók tudják szerkeszteni/karbantartani távoli web kiszolgálójukon lév˝o tartalmat.
HttpWebdavNonTrans: nem transzparens HTTP WebDAV-al proxy neve: MyNontransWebdavHttpProxy router: InbandRouter nport: 80 proxy port: 50080 Jelen beállítás nem transzparens web hozzáférést és a WebDAV b˝ovítmények használatát engedélyezi. A WebDAV HTTP protokoll b˝ovítmény segítségével felhasználók tudják szerkeszteni/karbantartani távoli web kiszolgálójukon lév˝o tartalmat. Megjegyzés: A proxy használatához a kliensek megfelel˝o beállítása szükséges (használják a tuzfalat ˝ mint HTTP proxy-t).
94
˝ E. FÜGGELÉK. ELORE MEGHATÁROZOTT PROXYK LISTÁJA Https: HTTPS protokoll proxy-kal proxy neve: HttpsProxy port: 443 proxy port: 50443 A HTTPS a "HTTP az SSL-en belül" rövidítése. A HTTP a web elérés protokollja, az SSL pedig egy adatszállító szolgáltatás, amely biztosítja a bizalmasságot, és hitelességet. A leggyakrabban a bizalmas információt tartalmazó weblapoknál használatos. Jelen beállítás a Pssl protokoll proxy-t, továbbá egy beágyazott HttpProxy-t használ. Az SSL miatt az alábbi plusz állományok szükségesek: – /etc/zorp/https/zorp.crtcertificate és ennek megfelel˝o privát kulcs – egy lista a megbízható CA tanúsítványokról, amit egy index könyvtár /etc/zorp/https/ca.crt tartalmaz – /etc/zorp/https/ca.crl amely a visszavont tanúsítványok listája A certificate-ekr˝ol és a szükséges kulcsokról a PSSL proxy dokumentációjában olvashatunk többet.
95 HttpsFilter: URL filtrált HTTPS proxy neve: HttpsProxyURIFilter port: 443 proxy port: 50443 A HTTPS a "HTTP az SSL-en belül" rövidítése. A HTTP a web elérés protokollja, az SSL pedig egy adatszállító szolgáltatás, amely biztosítja a bizalmasságot, és hitelességet. A leggyakrabban a bizalmas információt tartalmazó weblapoknál használatos. Jelen beállítás a Pssl protokoll proxy-t, továbbá egy beágyazott HttpProxy-t használ. Az SSL miatt az alábbi plusz állományok szükségesek: – /etc/zorp/https/zorp.crtcertificate és ennek megfelel˝o privát kulcs – egy lista a megbízható CA tanúsítványokról, amit egy index könyvtár /etc/zorp/https/ca.crt tartalmaz – /etc/zorp/https/ca.crl amely a visszavont tanúsítványok listája A certificate-ekr˝ol és a szükséges kulcsokról a PSSL proxy dokumentációjában olvashatunk többet. A beágyazott HHTP proxy minden bejöv˝o web kérésben szerepl˝o URL-t egy "fekete listához" ellen˝oriz és ez alapján dönti el, hogy a kapcsolat engedélyezet vagy sem. Hozzon létre egy blacklist-http nevu ˝ szöveges állományt, ahol sorolja fel a tiltott URL-eket. (Reguláris kijefezések használhat.) Amennyiben tiltana minden URL-t amelyben a sex szó szerepel, írja be a szót a blacklist állományba. Viszont ha a www.essex.com oldalt ennek ellenére engedélyezni szeretné, hozzon létre egy blacklist-http.ignore állományt és írja bele a www.essex.com URL-t.
96
˝ E. FÜGGELÉK. ELORE MEGHATÁROZOTT PROXYK LISTÁJA HttpsWebdav: transzparens HTTPS, WebDAV b˝ovítménnyel proxy neve: HttpsWebdavProxy port: 443 proxy port: 50443 A HTTPS a "HTTP az SSL-en belül" rövidítése. A HTTP a web elérés protokollja, az SSL pedig egy adatszállító szolgáltatás, amely biztosítja a bizalmasságot, és hitelességet. A leggyakrabban a bizalmas információt tartalmazó weblapoknál használatos. Jelen beállítás a Pssl protokoll proxy-t, továbbá egy beágyazott HttpProxy-t használ. Az SSL miatt az alábbi plusz állományok szükségesek: – /etc/zorp/https/zorp.crtcertificate és ennek megfelel˝o privát kulcs – egy lista a megbízható CA tanúsítványokról, amit egy index könyvtár /etc/zorp/https/ca.crt tartalmaz – /etc/zorp/https/ca.crl amely a visszavont tanúsítványok listája A certificate-ekr˝ol és a szükséges kulcsokról a PSSL proxy dokumentációjában olvashatunk többet. Jelen beállításban a beágyazott HTTP proxy engedélyezi a WebDAV b˝ovítmények használatát, amelyek segítségével a felhasználó a megfel˝oen beállított távoli web szerver tartalmát szerkeszteni/módosítani tudja. HttpsPlug: HTTPS Plug proxy-val proxy neve: HttpsPlug port: 443 proxy port: 50443 A HTTPS a "HTTP az SSL-en belül" rövidítése. A HTTP a web elérés protokollja, az SSL pedig egy adatszállító szolgáltatás, amely biztosítja a bizalmasságot, és hitelességet. A leggyakrabban a bizalmas információt tartalmazó weblapoknál használatos. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG proxy-t használ a kapcsolathoz, így a tuzfal ˝ a stream tartalmát nem képes ellen˝orizni. Icq2000: ICQ protokoll proxy neve: ICQProxy port: 5190 proxy port: 55190 Az ICQ kommunikációs és üzenetközvetít˝o protokoll átvitele PLUG proxy-val. Az ICQ a 5190/TCP portot használja a kliens-szerver kommunikációra. Megjegyzés: A beállítás egyszeru ˝ PLUG proxy-t használ az adatforgalom átivetére, ezért a tuzfal ˝ nem képes a stream tartalmát ellen˝orizni.
97 Imap: Internet Message Access Protokoll proxy neve: ImapProxy port: 143 proxy port: 50143 Az IMAP protokoll lehet˝ové teszi kliensek számára, hogy a levelez˝o szerveren email üzeneteket kezeljen, töltsön le stb. A protokoll megengedi távoli mailbox-ok kezelését, helyi mailboxokkal analóg módon. Az IMAP a 143/TCP portot használja a kliens-szerver kommunikációhoz. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG proxy-t használ, ezért a tuzfal ˝ nem képes az adatforgalom tartalmának ellen˝orzésére.
Irc: Internet Relay Chat Protokoll proxy neve: IrcProxy router: TransparentRouter nport: 6667 proxy port: 56667 Az IRC az Internet Relay Chat rövidÍtése. Általában egy TCP csatornán mukö˝ dik, opcionálisan használhatók másodlagos csatornák DCC kapcsolatokhoz. Ez a beállÍtás kizárólag az els˝odleges csatornát támogatja, másodlagos csatornák használata nem engedélyezett. Az IRC kommunikáció általában a TCP/6667-es porton zajlik, de elfogadott 6666-6669-es port tartomány is. Megjegyzés: Jelen beállÍtás egy egyszeru ˝ PLUG-ot használ az adatforgalom átviteléhez, ezért a tuzfal ˝ nem képes ellen˝orizni a stream tartalmát.
Ldap: Lightweight Directory Access Protokoll proxy neve: LdapProxy port: 389 proxy port: 50389 Az LDAP megoldást biztosít központosított felhasználó azonosításra, hitelesítésre. Jelen beállítás az LDAP kliens-szerver kommunikációt engedélyezi. Az LDAP adatforgalom a 389/TCP porton folyik. Megjegyzés: A beállítás egyszeru ˝ PLUG proxy-t használ, ezért a tuzfal ˝ nem képes a stream tartalmának elemzésére.
98
˝ E. FÜGGELÉK. ELORE MEGHATÁROZOTT PROXYK LISTÁJA Ldaps: LDAPS - Titkosított LDAP forgalom proxy neve: LdapsProxy port: 636 proxy port: 50636 Az LDAP megoldást biztosít központosított felhasználó azonosításra, hitelesítésre. Jelen beállítás az LDAP SSL-el tikosított kliens-szerver kommunikációt engedélyezi. Az SSL miatt az alábbi plusz állományok szükségesek: – /etc/zorp/https/zorp.crtcertificate és ennek megfelel˝o privát kulcs – egy lista a megbízható CA tanúsítványokról, amit egy index könyvtár /etc/zorp/https/ca.crt tartalmaz – /etc/zorp/https/ca.crl amely a visszavont tanúsítványok listája A certificate-ekr˝ol és a szükséges kulcsokról a PSSL proxy dokumentációjában olvashatunk többet. Az LDAP adatforgalom a 636/TCP porton folyik. Megjegyzés: A beállítás egyszeru ˝ PLUG proxy-t használ, ezért a tuzfal ˝ nem képes a stream tartalmának elemzésére.
Ldaps: LDAPS Plug proxy-val proxy neve: LdapsProxyPlug port: 636 proxy port: 50636 Az LDAPS titkosított megoldást biztosít központosított felhasználó azonosításra, hitelesítésre. Jelen beállítás az LDAPS kliens-szerver kommunikációt engedélyezi. Az LDAPS adatforgalom a 636/TCP porton folyik. Megjegyzés: A beállítás egyszeru ˝ PLUG proxy-t használ, ezért a tuzfal ˝ nem képes a stream tartalmának elemzésére.
NntpProxy: NNTP PLUG proxy-val proxy neve: NntpProxy port: 119 proxy port: 50119 Az NNTP a Usenet News System használatához szükséges protokoll.
99 NntpsRW: NTTPS SSL-Plug proxy-val proxy neve: NntpProxyRW port: 563 proxy port: 50563 Az NNTPS a Usenet News System használatához szükséges protokoll SSL-be ágyazott változata. Az SSL miatt az alábbi plusz állományok szükségesek: – /etc/zorp/https/zorp.crtcertificate és ennek megfelel˝o privát kulcs – egy lista a megbízható CA tanúsítványokról, amit egy index könyvtár /etc/zorp/https/ca.crt tartalmaz – /etc/zorp/https/ca.crl amely a visszavont tanúsítványok listája Az NNTPS alapbeállítása a 653/TCP port. Megjegyzés: Jelen beállítás csak az SSL réteget vizsgálja alkalmazás szinten, míg az NNTP adatforgalom tartalmát nem ellen˝orzi.
NntpsPlug: NNTPS Plug proxy-val proxy neve: NNTPsProxy port: 563 proxy port: 50563 Az NNTPS a Usenet News System használatához szükséges protokoll SSL-be ágyazott változata. Az NNTPS alapbeállítása az 653/TCP port. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG-ot használ, így a tuzfal ˝ nem képes ellen˝orizni az adatforgalom tartalmát.
LotusNotes: csoportmunka támogató rendszer protokoll proxy neve: LotusNotesProxy port: 1352 proxy port: 51352 LotusNotes E-mail, határid˝onapló, csoport munka, webböngész˝o és információ menedzsment kliens protokoll. A LotusNotes a 1352/TCP portot használja a kliens-szerver kommunikációhoz. Megjegyzés: A beállítás egyszeru ˝ PLUG proxy-t használ, így a tuzfal ˝ nem képes az adatforgalom tartalmának ellen˝orzésére.
100
˝ E. FÜGGELÉK. ELORE MEGHATÁROZOTT PROXYK LISTÁJA Pop3: POP3 protokoll
proxy neve: Pop3Proxy port: 110 proxy port: 50110 Post Office Protocol a levelez˝o szerverekr˝ol való e-mail letöltés elterjedt módja. A Pop3 a szükséges jelszavakat titkosítás nélkül küldi a hálózaton, és alapesetben a 110/TCP portot használja. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG-ot használ, így a tuzfal ˝ nem képes az adatforgalom tartalmának ellen˝orzésére.
Pop3sPlug: titkosított (SSL-be ágyazott) POP3 protokoll (PLUG-on) proxy neve: Pop3sPlugProxy port: 995 proxy port: 50995 A POP3s az adatok bizalmasságát biztosítva teszi lehet˝ové az e-mailek letöltését távoli mail szerverekr˝ol. Pop3s SSL-be ágyazott POP3 alapesetben a 955/TCP portot használja a kommunikációra. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG-ot használ, amely a kommunikáció tartalmát nem vizsgálja.
Pop3s: titkosított (SSL-be ágyazott) POP3 protokoll (SSL proxy-n) proxy neve: Pop3sProxy port: 955 proxy port: 50955 A POP3s az adatok bizalmasságát biztosítva teszi lehet˝ové az e-mailek letöltését távoli mail szerverekr˝ol. Pop3s SSL-be ágyazott POP3 alapesetben a 955/TCP portot használja a kommunikációra. Az SSL miatt az alábbi plusz állományok szükségesek: – /etc/zorp/https/zorp.crtcertificate és ennek megfelel˝o privát kulcs – egy lista a megbízható CA tanúsítványokról, amit egy index könyvtár /etc/zorp/https/ca.crt tartalmaz – /etc/zorp/https/ca.crl amely a visszavont tanúsítványok listája A certificate-ekr˝ol és a szükséges kulcsokról a PSSL proxy dokumentációjában olvashatunk többet. Megjegyzés: Jelen beállítás csak az SSL réteget vizsgálja alkalmazás szinten, míg a POP3 adaforgalmaz nem ellen˝orzi.
101 Pop3sConvert: POP3s -> POP3 konvertálás a szerver oldalon proxy neve: Pop3sConvertProxy port: 955 proxy port: 50955 A POP3s az adatok bizalmasságát biztosítva teszi lehet˝ové az e-mailek letöltését távoli mail szerverekr˝ol. Pop3s SSL-be ágyazott POP3 alapesetben a 955/TCP portot használja a kommunikációra. Az SSL miatt az alábbi plusz állományok szükségesek: – /etc/zorp/https/zorp.crtcertificate és ennek megfelel˝o privát kulcs – egy lista a megbízható CA tanúsítványokról, amit egy index könyvtár /etc/zorp/https/ca.crt tartalmaz – /etc/zorp/https/ca.crl amely a visszavont tanúsítványok listája Jelen beállítás a klienssel POP3s-en, a szerverrel POP3-on engedélyezi a kommunikációt. A certificate-ekr˝ol és a szükséges kulcsokról a PSSL proxy dokumentációjában olvashatunk többet. Megjegyzés: Jelen beállítás csak az SSL réteget vizsgálja alkalmazás szinten, míg a POP3 adaforgalmaz nem ellen˝orzi.
Printer: LPD protokoll proxy neve: LpProxy port: 515 proxy port: 50515 UNIX printer szerverek standard protokollja. Az Lpd alapbeállítása az 515/TCP port. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG-ot használ, így a tuzfal ˝ nem képes az adatforgalom tartalmának ellen˝orzésére.
RTSP: RealMedia Protokoll proxy neve: RTSPProxy port: 554 proxy port: 50554 Real Audio, Real Media (G2) szolgáltatások a Real-Time Streaming Protokoll-on (RTSP) érhet˝ok el. Az RTSP kommunikáció az 544/TCP porton történik. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG-ot használ, így a tuzfal ˝ nem képes ellen˝orizni az adatforgalom tartalmát.
102
˝ E. FÜGGELÉK. ELORE MEGHATÁROZOTT PROXYK LISTÁJA ShoutCast: Média szolgáltatás közvetít˝o protokoll
proxy neve: ShoutCastProxy port: 8000 proxy port: 58000 SHOUTcast a Nullsoft ingyenes Winamp alapú audió közvetít˝o rendszere. A Shoutcast a 8000/TCP portot használja a kommunikációhoz. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG-ot használ, így a tuzfal ˝ nem képes ellen˝orizni az adatforgalom tartalmát. Samba: netbios alapú fájl megosztó rendszer protokoll proxy neve: NetbiosSSNProxy port: 137 proxy port: 50137 A Samba egy platform független alkalmazás, amely egyebek mellett lehet˝ové teszi a fájlok megosztását Microsoft és POSIX operációs rendszerek között. Jelen beállítás engedélyezi a netbios kapcsolatot kliens és szerver között, direkt netbios név megadásával. (A browsing nem támogatott.) A Netbios-ssn a 139/TCP portot használja a kommunikációhoz. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG proxy-t használ, így a tuzfal ˝ nem képes az adafrogalom tartalmának ellen˝orzésére. Pgsql: PostgreSQL adatbázis kapcsolat proxy neve: PgsqlProxy port: 5432 proxy port: 55432 PostgreSQL egy szabad szoftveres relációs adatbázis szerver. A PostgreSQL kliens-szerver kommunikáció alapbeálításban 5432/TCP porton zajlik. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG-ot használ, így a tuzfal ˝ nem képes ellen˝orizni az adatforgalom tartalmát. ORA: Oracle adatbázis szerver kapcsolat proxy neve: OraProxy port: 1521 proxy port: 51521 Oracle relációs adatbázis kliens-szerver kapcsolat. Jelen beállítás csak a megfelel˝oen beállított egy porton kommunikáló Oracle szerverrel muködik ˝ együtt. Az Oracle kliens-szerver kommunikáció alapbeállítása a 1521/TCP port. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG-ot használ, így a tuzfal ˝ nem képes ellen˝orizni az adatforgalom tartalmát.
103 Mysql: MySQL adatbázis kapcsolat proxy neve: MySQLProxy port: 3306 proxy port: 53306 A MySQL egy szabadszoftveres relációs adatbázis szerver. A MySQL kliens-szerver kapcsolat alapbeállítása a 3306/TCP port. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG-ot használ, így a tuzfal ˝ nem képes ellen˝orizni az adatforgalom tartalmát. Mssql: Microsoft SQL adatbázis kapcsolat proxy neve: MSSQLProxy port: 1433 proxy port: 51433 MSSQL relaációs adatbázis kliens szerver kapcsolat. Az MSSQL kommunikáció alapbeállítása a 1433/TCP port. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG-ot használ, így a tuzfal ˝ nem képes ellen˝orizni az adatforgalom tartalmát. SSH: SSH Remote Login protokoll proxy neve: SSHProxy port: 22 proxy port: 50022 Secure-Shell Remote Login Protokoll lehet˝oséget biztosít UNIX rendszerek távoli adminisztrációjára (shell hozzáférésre) úgy, hogy a hálózati forgalom bizalmassága, integritása biztosított. Az SSH alapbeállítása a 22/TCP port. Megjegyzés: Jelen beállítás egyszeru ˝ PLUG-ot használ, így a tuzfal ˝ nem képes az adatforgalom tartalmának ellen˝orzésére. Telnet: hagyományos távoli shell hozzáférés proxy neve: TelnetProxy port: 25 proxy port: 50025 A telnet lehet˝oséget biztosít UNIX rendszerek adminisztrációjára távoli shell hozzáférésen át. A protokoll nem titkosítja sem a csatornát, sem a hozzáféréshez szükséges jelszót, így az adatforgalom könnyen lehallgatható. (Lehet˝oség szerint e-helyett az SSH használata javasolt.) A Telnet alapbeállítása a 25/TCP port.
104
˝ E. FÜGGELÉK. ELORE MEGHATÁROZOTT PROXYK LISTÁJA Whois: RFC-812 adatbázis lekérdezés
proxy neve: WhoisProxy port: 43 proxy port: 50043 Whois az RFC-812 adabázisok (IP címek) lekérdezésére szolgáló protokoll. A Whois protokoll alapbeállítása a 43/TCP port. További információkat keresse a Zorp Reference Guide vonatkozó fejezetében.
F. Függelék
A disztribúciós CD-n lév˝ o csomagok Csomag neve verziószám Rövid leírás adduser 3.50 Add and remove users and groups apt
0.5.8 Advanced front-end for dpkg
apt-utils APT utility programs at
0.5.8
3.1.8-11 Delayed job execution and batch processing
base-config 1.67 Debian base configuration package base-files 3.0.9 Debian base system miscellaneous files base-passwd 3.5.4 Debian base system master password and group files bash
2.05b-8.1 The GNU Bourne Again SHell
bsdmainutils 5.20030320-1 collection of more utilities from FreeBSD bsdutils 1 Basic utilities from 4.4BSD-Lite.
105
˝ CSOMAGOK F. FÜGGELÉK. A DISZTRIBÚCIÓS CD-N LÉVO
106
Csomag neve verziószám Rövid leírás bzip2 1.0.2-1 A high-quality block-sorting file compressor - utilities chrpath 0.10-2 Tool to edit the rpath in ELF binaries console-common 0.7.22 Basic infrastructure for text console configuration console-data 2002.12.04dbs-14 Keymaps, fonts, charset maps, fallback tables for console-tools console-tools 1 Linux console and font utilities coreutils 5.0-5 The GNU core utilities cpio
2.5-1 GNU cpio – a program to manage archives of files.
cramfsprogs 1.1-4 Tools for CramFs (Compressed ROM File System). cron
3.0pl1-74 management of regular background processing
dash
0.4.17 The Debian Almquist Shell
debconf 1.3.8 Debian configuration management system debconf-i18n 1.3.8 full internationalization support for debconf debianutils 2.5.4 Miscellaneous utilities specific to Debian devfsd 1.3.25-15 Daemon for the device filesystem dhcp-client DHCP Client
2.0pl5-15
dialog
0.9b-20030720-1 Displays user-friendly dialog boxes from shell scripts
diff
2.8.1-2 File comparison utilities
dpatch 1.22 patch maintenance system for Debian source packages dpkg
1.10.10 Package maintenance system for Debian
107 Csomag neve verziószám Rövid leírás dselect 1.10.10 a user tool to manage Debian packages e2fsprogs 1.33+1.34-WIP-2003.05.21-2 The EXT2 file system utilities and libraries ed
0.2-20 The classic unix line editor
fdutils Linux floppy utilities file
5.4-20030528-1
4.02-4 Determines file type using "magic" numbers
findutils 4.1.20-1 utilities for finding files–find, xargs, and locate gcc-3.2-base 1 The GNU Compiler Collection (base package) gcc-3.3-base 1 The GNU Compiler Collection (base package) gettext-base 0.12.1-3 GNU Internationalization utilities for the base system grep
2.5.1-5 GNU grep, egrep and fgrep
groff-base 1.18.1-9 GNU troff text-formatting system (base system components) grub
0.92-1 GRand Unified Bootloader
gzip
1.3.5-7 The GNU compression utility
hostname 2.10 A utility to set/show the host name or domain name ifupdown 0.6.4-4.4 High level tools to configure network interfaces info
4.6-1 Standalone GNU Info documentation browser
initrd-tools 0.1.51 Tools to generate an initrd image. initscripts 2.85-4.1 Standard scripts needed for booting and shutting down iptables 1.2.8-4 IP packet filter administration tools for 2.4.4+ kernels
˝ CSOMAGOK F. FÜGGELÉK. A DISZTRIBÚCIÓS CD-N LÉVO
108
Csomag neve verziószám Rövid leírás kernel-image-2.4.20-3-586 2.4.20-9 Linux kernel image for version 2.4.20 on Pentium-Classic. klogd
1.4.1-10 Kernel Logging Daemon
less
381-2 A file pager program, similar to more(1)
libasn1-6-heimdal 0.5.2-2 Libraries for Heimdal Kerberos libauthen-pam-perl 0.13-3 This module provides a Perl interface to the PAM library. libblkid1 1.33+1.34-WIP-2003.05.21-2 Block device id library libbz2-1.0 1.0.2-1 A high-quality block-sorting file compressor library - runtime libc6
2.3.1-16 GNU C Library
libcap1 1 support for getting/setting POSIX.1e capabilities libcomerr1-kerberos4kth 1.2.2-2 ComErr Libraries for Kerberos4 From KTH libconsole 1 Shared libraries for Linux console and font manipulation libconvert-asn1-perl 0.16-1 Replacement for Convert libdb1-compat 2.1.3-7 The Berkeley database routines [glibc 2.0/2.1 compatibility] libdb2 2 The Berkeley database routines (run-time files). libdb3 3.2.9-19 Berkeley v3 Database Libraries [runtime] libdb4.0 4.0.14-1.2 Berkeley v4.0 Database Libraries [runtime] libdb4.1 4.1.25-6 Berkeley v4.1 Database Libraries [runtime] libexpat1 1.95.6-4 XML parsing C library - runtime library libgcc1 GCC support library
1
109 Csomag neve verziószám Rövid leírás libgcrypt1 1.1.12-3 LGPL Crypto library - runtime library libgdbm3 1.8.3-1 GNU dbm database routines (runtime version) libgdbmg1 1.7.3-28 GNU dbm database routines (runtime version) libglib1.2 1.2.10-9 The GLib library of C routines libglib2.0-0 2.2.2-1 The GLib library of C routines libglib2.0-data 2.2.2-1 Common files for GLib library libgpmg1 1.19.6-12.1 General Purpose Mouse Library [libc6] libgssapi1-heimdal 0.5.2-2 Libraries for Heimdal Kerberos libhtml-parser-perl 3.28-3 A collection of modules that parse HTML text documents libhtml-tagset-perl 3.03-2 Data tables pertaining to HTML libident 0.22-2 simple RFC1413 client library - runtime libkrb-1-kerberos4kth 1.2.2-2 Kerberos Libraries for Kerberos4 From KTH libkrb5-17-heimdal 0.5.2-2 Libraries for Heimdal Kerberos liblocale-gettext-perl 1.01-17 Using libc functions for internationalization in Perl liblockfile1 1.05 NFS-safe locking library, includes dotlockfile program libltdl3 1.4.3-10 A system independent dlopen wrapper for GNU libtool liblzo1 1.08-1 A real-time data compression library libncurses5 5.3.20030719-1 Shared libraries for terminal handling libpam-modules 0.76-13 Pluggable Authentication Modules for PAM
˝ CSOMAGOK F. FÜGGELÉK. A DISZTRIBÚCIÓS CD-N LÉVO
110
Csomag neve verziószám Rövid leírás libpam-runtime 0.76-13 Runtime support for the PAM library libpam-smbpass 3.0.0beta2-1 pluggable authentication module for SMB password database libpam0g 0.76-13 Pluggable Authentication Modules library libpcap0.7 0.7.2-1 System interface for user-level packet capture. libpcre3 4.3-3 Philip Hazel’s Perl 5 Compatible Regular Expression library libperl-dev Perl library
5.8.0-19
libperl5.8 Shared Perl library.
5.8.0-19
libpng12-0 1.2.5.0-4 PNG library - runtime libreadline4 4.3-5 GNU readline and history libraries, run-time libraries libroken16-kerberos4kth 1.2.2-2 Roken Libraries for Kerberos4 From KTH libsasl2 2.1.12-1 Authentication abstraction library libsasl7 1.5.27-3.5 Authentication abstraction library. libslp1 OpenSLP libraries libsp1
1.0.11-2
1.3.4-1.2.1-35 Runtime library for James Clark’s SP suite
libssl0.9.7 SSL shared libraries
0.9.7b-2
libstdc++2.10-glibc2.2 1 The GNU stdc++ library libstdc++5 1 The GNU Standard C++ Library v3 libtasn1-0 0.1.2-1 Manage ASN.1 structures (runtime) libtext-charwidth-perl 0.04-1 get display widths of characters on the terminal
111 Csomag neve verziószám Rövid leírás libtext-iconv-perl 1.2-2 Convert between character sets in Perl libtext-wrapi18n-perl 0.06-1 internationalized substitute of Text libwrap0 7.6-ipv6.1-3 Wietse Venema’s TCP wrappers library libxml2 GNOME XML library
2.5.7-1
libxmltok1 1.1-12 XML Parser Toolkit, runtime libraries libzorpll 2.0.26.4-1 Low level library functions for Zorp libzorpll-dbg 2.0.26.4-1 Low level library functions for Zorp, debug version libzorpll-dev 2.0.26.4-1 Low level library functions for Zorp, development files logrotate Log rotation utility
3.6.5-2
makedev 2.3.1-62 Creates device files in /dev. man-db 2.4.1-10 The on-line manual pager manpages 1.48-2 Manual pages about using a GNU/Linux system mawk
1.3.3-11 a pattern scanning and text processing language
mbr
1.1.5-1 Master Boot Record for IBM-PC compatible computers.
mc
1 Midnight Commander - a powerful file manager
mime-support 3.23-1 MIME files ’mime.types’ & ’mailcap’, and support programs modconf 0.2.44 Device Driver Configuration module-init-tools 0.9.13-pre-1 tools for managing Linux kernel modules modutils 2.4.21-2.1 Linux module utilities
˝ CSOMAGOK F. FÜGGELÉK. A DISZTRIBÚCIÓS CD-N LÉVO
112
Csomag neve verziószám Rövid leírás mount 2.11z-1 Tools for mounting and manipulating filesystems. nano
1.2.1-2 free Pico clone with some new features
ncurses-base 5.3.20030719-1 Descriptions of common terminal types ncurses-bin 5.3.20030719-1 Terminal-related programs and man pages ncurses-term 5.3.20030719-1 Additional terminal type definitions net-tools 1.60-8 The NET-3 networking toolkit netbase 4.10 Basic TCP/IP networking system netkit-inetd 0.10-9 The Internet Superserver netkit-ping 0.10-9 The ping utility from netkit openssl 0.9.7b-2 Secure Socket Layer (SSL) binary and related cryptographic tools pciutils 1 Linux PCI Utilities (for 2.[12345].x kernels) perl
5.8.0-19 Larry Wall’s Practical Extraction and Report Language.
perl-base 5.8.0-19 The Pathologically Eclectic Rubbish Lister. perl-modules Core Perl modules.
5.8.0-19
postfix 2.0.13-4 A high-performance mail transport agent ppp
2.4.1.uus-5 Point-to-Point Protocol (PPP) daemon.
pppconfig 2.2.0 A text menu based utility for configuring ppp pppoe
3.5-1 PPP over Ethernet driver
pppoeconf 0.9.10.9 configures PPPoE/ADSL connections
113 Csomag neve verziószám Rövid leírás procps 1 The /proc file system utilities psmisc 21.3-1 Utilities that use the proc filesystem python 2.2.3-3 An interactive high-level object-oriented language (default version) python2.2 2.2.3-3 An interactive high-level object-oriented language (version 2.2) python2.2-extclass 1.2.0zope-2.5.1-1.2 Improves integration between Python and C++ classes (Python 2.2) raidtools2 1.00.3-2 Utilities to support ’new-style’ RAID disks sed
4.0.7-1 The GNU sed stream editor
setserial 2.17-33 Controls configuration of serial ports slang1 1.4.5-2.1 The S-Lang programming library - runtime version. slang1a-utf8 1.4.5-2.1 The S-Lang programming library with utf8 support ssh
1 Secure rlogin/rsh/rcp replacement (OpenSSH)
sysklogd 1.4.1-10 System Logging Daemon syslinux 2.04-1 Bootloader for Linux/i386 using MS-DOS floppies sysv-rc 2.85-4.1 Standard boot mechanism using symlinks in /etc/rc?.d sysvinit System-V like init.
2.85-4.1
tar
1.13.25-5 GNU tar
tasksel 1.25 Tool for selecting tasks for installation on Debian system tcpd
7.6-ipv6.1-3 Wietse Venema’s TCP wrapper utilities
telnet
0.17-20 The telnet client.
˝ CSOMAGOK F. FÜGGELÉK. A DISZTRIBÚCIÓS CD-N LÉVO
114
Csomag neve verziószám Rövid leírás ucf 0.17 Update Configuration File util-linux 2.11z-1 Miscellaneous system utilities. vim
1 Vi IMproved - enhanced vi editor
zlib1g
1 compression library - runtime
zorp
2.0.3.4-1 An advanced protocol analyzing firewall
zorp-doc Zorp documentation.
2.0.3.4-1
zorp-modules 2.0.3.4-1 Default proxy modules for Zorp defoma 0.11.3 Debian Font Manager – automatic font configuration framework grub-disk 0.92-1 GRUB bootable disk image grub-doc 0.92-1 Documentation for GRand Unified Bootloader libcupsimage2 1.1.19final-1 Common UNIX Printing System(tm) - image libs libgnutls5 0.8.8-2 GNU TLS library - runtime library libgnutls7 0.8.9-2 GNU TLS library - runtime library libisc4 1 ISC Shared Library used by BIND libldap2 OpenLDAP libraries
2.1.22-1
libldap2-dev 2.1.22-1 OpenLDAP development libraries libnewt0 0.50.17-11zorpos Not Erik’s Windowing Toolkit - text mode windowing with slang libopencdk4 1 Open Crypto Development Kit (OpenCDK) (runtime) maildrop 1.5.3-1 mail delivery agent with filtering abilities
115 Csomag neve verziószám Rövid leírás mailx 1 A simple mail user agent python-newt 0.50.17-11zorpos A newt module for Python. python2.1 2.1.3-20 An interactive high-level object-oriented language (version 2.1) whiptail 0.50.17-11zorpos Displays user-friendly dialog boxes from shell scripts. xfree86-common 4.2.1-6 X Window System (XFree86) infrastructure xlibs
4.2.1-6 X Window System client libraries
iptables-utils 1.9-3 iptables utilities for loading and maintaining iptables rulesets. python-extclass 1.2.0zope-2.5.1-1.2 Improves integration between Python and C++ classes libmagic1 4.02-4 File type determination library using "magic" numbers libpopt0 1.7-2 lib for parsing cmdline parameters uzi
2.0.2-1 UHU Zorp Interface
zui
2.0.2-1 Zorp User Interface, a simple character based configuration tool for Zorp bind9 1 Internet Domain Name Server bind9-doc 1 Documentation for BIND bind9-host 1 Version of ’host’ bundled with BIND 9.X dnsutils 1 Clients provided with BIND libdns8 1 DNS Shared Library used by BIND libisccc0 1 Command Channel Library used by BIND libisccfg0 1 Config File Handling Library used by BIND
˝ CSOMAGOK F. FÜGGELÉK. A DISZTRIBÚCIÓS CD-N LÉVO
116
Csomag neve verziószám Rövid leírás liblwres1 1 Lightweight Resolver Library used by BIND login
1 System login tools
passwd 1 Change and administer password and group data.
G. Függelék
Installálás karakteres képerny˝ ovel A 3. fejezetben említettük a karakteres telepítési felületet. Az ott leírtaknak megfelel˝oen kell a számítógépet CD-r˝ol boot-olhatóvá tenni, majd a CD meghajtóba helyezett telepít˝o CD-vel a számítógépet újraindítani. Ahogy az operációs rendszer betöltése megtörtént, megjelenik az indító képerny˝o, ahogy az a G.1. sz. ábrán is látszik.
G.1. ábra. Üdvözl˝o képerny˝o A képerny˝o két részre oszlik. A fels˝o részben segítség és a copyright információ látható, az alsó részen pedig a boot prompt látható. Itt adható(k) meg a kernel
117
118
˝ G. FÜGGELÉK. INSTALLÁLÁS KARAKTERES KÉPERNYOVEL
paraméter(ek) (pl. alternatív root meghajtó, más meghajtók paraméterei stb.), de az Enter lenyomásával az alapértelmezett opciókkal folytatódik a betöltés. A következ˝okben a kernel betöltésének üzeneti lathatóak. Ezt kés˝obb meg lehet nézni a parancs promptnál a dmesg parancs kiadásával. A kernel betöltése után megkezd˝odik az installálás els˝o fázisa. A program el˝oször megkérdezi a CD meghajtó elérési útját, alapértelmezettnek felajánlva az automatikusan érzékeltet. A szokásos Linux meghajtó neveket kell használni, ami függ a CD meghajtó interfészét˝ol (ATA vagy SCSI). Az ATA eszközök /dev/hd jellel kezd˝odnek, amit egy betu ˝ követ a csatorna azonosításául. Az els˝odleges eszköz els˝o csatornája /dev/hda, a második /dev/hdb, A másodlagos eszköz els˝o csatornája /dev/hdc és így tovább1 . Az SCSI eszközök számozva vannak a felismerés sorrendjében, így az els˝o a /dev/scd0, a második /dev/scd1 stb. A Zorp által automatikusan detektált CD-ROM eszközt felül lehet írni eltér˝o érték megadásával. Ha a CD csatlakoztatása (mount) sikeres volt, kiválasztható az installálás nyelve (jelenleg angol, magyar, vagy német). Válassza ki az Önnek legjobban megfelel˝o nyelvet! Ett˝ol a ponttól kezdve 4 virtuális terminál áll rendelkezésre: 1. Ez az, ahol az installáció folyik, itt kérdések és üzenetek fognak megjelenni, 2. Ha valami nem megfelel˝o, segítségként parancsokat adhat ki ezen a terminálon, mert itt egy parancsértelmez˝o áll rendelkezésre, 3. Itt fognak megjelenni az installációs naplóba kerül˝o üzenetek, 4. Itt pedig a kernel üzenetei fognak folyamatosan megjelenni. A virtuális terminálok közötti váltás úgy történik, hogy meg kell nyomni a baloldali Alt billentyut, ˝ ezt nyomva tartva azt a funkció billentyut, ˝ ami a meg felel˝o virtuális terminált azonosítja ( F1 a vt#1, a F2 a vt#2 és így tovább). A beállító rendszer két installációs típust ajánl fel, a könnyu˝ módot, amelynél nem jelenik meg egyetlen kérdés sem, minden az alapértelmezett konfigurációval lesz felinstallálva és a szakérto˝ mód, amely során egyes paraméterek megváltoztathatóak. A következ˝okben a szakért˝o módban való installálást ismertetjük, mivel a könnyu ˝ módszer nem igényel további megválaszolandó kérdést. A G.2. sz. ábrán látható szakért˝oi menü jelenik meg. Minden lépésnek saját menüpontja van, ami a végrehajtás sorrendjében látható, de a sorrend megváltoztatható, vagy bármelyik lépés többször is végrehajtható. fdisk elindítja a szokásos GNU/Linux fdisk programot, amivel particionálni lehet a merevlemez(eke)t, mkswap létrehozza és inicializálja a swap partíciót, 1 Az angol szabványos megnevezések: primary master, primary slave, illetve secondary master, secondary slave
119
G.2. ábra. Szakért˝oi menü
idisk inicializálja és felcsatolja az el˝oz˝oleg particionált lemezeket, copy felmásolja az operációs rendszert és a Zorpot arra célmeghajtóra, amit az idisk inicializált és felcsatolt, interfaces megkérdezi az interfészeket és a hozzájuk tartozó IP címeket, amit el is ment a célrendszerbe, hostcfg feltölti a különböz˝o konfigurációs fájlokat, mint pl. a /etc/hosts és /etc/hostname, fstab létrehozza a használandó fstab bejegyzéseket, ami az idisk során szerzett információkon alapul, passwd lehet˝oséget ad a root jelszó megváltoztatására, hogy már az els˝o alkalommal is elkerüljük a nem biztonságos rendszer indítást, lilo létrehozza a lilo konfigurációt, és hozzáírja a LILO2 betölt˝o blokkot a célmerevlemez MBR3 részéhez, umountall automatikusan lecsatol mindent, szinkronizál és el˝okészül az újraindításhoz reboot ahogy a neve is sugallja, újraindítja a számítógépet, aminek most már a merevlemezr˝ol kell indulnia, mount lecsatolja az el˝oz˝oleg inicializált és felcsatolt partíciót, lehet˝ové téve a csatolási pont megváltoztatását, vagy a merevlemez újraparticionálását. 2 LInux
LOader – Linux betölt˝o Boot Record – els˝odleges betölt˝o rekord
3 Master
120
˝ G. FÜGGELÉK. INSTALLÁLÁS KARAKTERES KÉPERNYOVEL
A következ˝o pontok részletesen leírják az installálást részletesen, ahol ez ésszeru, ˝ konfigurációs tippekkel.
G.1. A cél-merevlemez el˝ okészítése A következ˝o feladat a cél-merevlemez felkészítése az installációra. Ezt egy listából lehet kiválasztani, amint ezt a G.3. sz. ábra mutatja.
G.3. ábra. Eszköz kiválasztása particionáláshoz
Ha a Zorp telepít˝o nem tudja azonosítani a merevlemezt, az Other lehet˝oséget kell választani, ahol a megjelen˝o beviteli mez˝oben megadható az egység elérési útvonala. Ha nincs eszköz a listában, és az Other lehet˝oség alkalmazásával megadott eszköz hivatkozás hibával tér vissza, feltehet˝oen alacsony szintu ˝ formázási probléma merült fel. Ebben az esetben a Linux dokumentáció segítségével kell megoldani a problémát. A cél-merevlemez kiválasztását követ˝oen elindul az fdisk, így létrehozhatóak vagy törölhet˝oek a partíciók. Jellemz˝oen a Zorpnak kb. 200 Mb. a helyigénye a programok és a statikus adatok számára. Ezen felül szükség van még helyre az ideiglenes fájlok és a változó adatok (levél átmeneti tároló4 , rendszer, naplók stb.) tárolására. Ebb˝ol ered˝oen a / és a usr számára kb. 200 Mb. szükséges. A merevlemez fennmaradó részét érdemes felosztani a var, tmp és a lapozó terület5 között, és figyelemmel arra, hogy a legnagyobb részt a levél átmeneti tároló foglal el, a /var legyen a legnagyobb. 4 5
mail queue swap
˝ G.1. A CÉL-MEREVLEMEZ ELOKÉSZÍTÉSE
121
Mivel a muvelet ˝ közben a /, a /tmp és a /var könyvtárakba történik írás, a /usr felcsatolható csak olvashatóként. A /tmp és a /var könyvtárakba kerül˝o programok nem kerülnek végrehajtásra, ezért ez felcsatolható „noexec,nosuid” opcióval. A lemez sikeres particionálását követ˝oen elindítható a lemez(ek) inicializálása és felcsatolása a megfelel˝o csatolási pontokhoz. A csatolási opciók installálás után testre szabhatóak a /etc/fstab szerkesztésével. A lapozó terület inicializálható a mkswap menüponton keresztül. A lapozó területre vonatkozó ökölszabály szerint annak mérete a számítógép operatív memóriájának kétszerese, de legfeljebb 256 Mb. legyen. Minden GNU/Linux installációnak rendelkeznie kell egy root partícióval, ezért a „mount” parancs el˝oször megkérdezi, melyik partícióra kerüljön (l. G.4. ábra).
G.4. ábra. A root partíció felcsatolása
A root partíció felcsatolását követ˝oen inicializálható és felcsatolható a többi partíció, amihez el˝oször meg kell adni, melyik partíciót (G.5. ábra) milyen csatolási ponthoz (G.6. ábra) kívánunk csatolni. Az összes kívánt csatolási pont megadása után a Finish kiválasztásával lehet ezt a menüt elhagyni. A Zorp ext2 fájlrendszerre inicializálja a lemez partíciókat. Ett˝ol eltér˝o formázást a telepítés befejeztével kézzel lehet végrehajtani Az összes partíció sikeres inicializálása után lehet a disztribúciót a célmerevlemezre másolni a szakért˝o menü copy pont használatával. Ha a merevlemez újraparticionálása mellett döntött, el˝oször le kell csatolni a szóban forgó partíciókat, ami után újraindítható az fdisk , igény szerint megvál-
122
˝ G. FÜGGELÉK. INSTALLÁLÁS KARAKTERES KÉPERNYOVEL
G.5. ábra. Partíció választás felcsatoláshoz
toztatható a partíciós szerkezet, majd ez újra inicializálható. Ez végrehajtható a szakért˝o menü legutolsó pontjaként szerepl˝o umount elem használatával. A telepít˝o rendszer megkérdezi, melyik csatolási pontot kívánja lecsatolni (G.7. ábra), amit le is csatol, leválasztva annak tartalmát a könyvtár struktúrából.
G.2. A disztribúció másolása Ahogy befejez˝odött a merevlemez el˝okészítése, és a partíciók hozzá lettek csatolva a fájlrendszerhez, sor kerülhet a disztribúció tarball6 -ból való másolására. Erre szükség van egy használható Zorp telepítése érdekében. Természetesen a telepít˝o a végrehajtás el˝ott meger˝osít˝o kérdést tesz fel, mert ez egy visszavonhatatlan lépés. A meger˝osítést követ˝oen a képerny˝on el˝orehaladás jelz˝o látszik a muvelet ˝ teljesítésének százalékos teljességének mutatására. További részletes információ tekinthet˝o meg a 4. virtuális terminálon (ami a Alt + F4 lenyomásával érhet˝o el), ahol az átmásolt fájlok neve látható.
6 A .tar.gz vagy .tgz formátumba tömörített állományok neve; kialakult magyar megfelel˝oje nincs
G.3. KONFIGURÁLÁS
123
G.6. ábra. Csatolási pont megadása
G.3. Konfigurálás A disztribúció átmásolásával az installálás nagyobb része befejez˝odött. Most a tuzfal ˝ sikeres els˝o betöltése érdekében az alap operációs rendszer konfigurálása következik. Mindenek el˝ott meg kell adni a tuzfal ˝ hoszt nevét a domain név nélkül. Ennek érvényes DNS névnek kell lennie, vagyis csak angol betuket, ˝ számokat és köt˝ojeleket (aláhúzásokat) tartalmazhat. Ez levelez˝o alrendszer és más bels˝o célokra szükséges. A következ˝o kérdés a tuzfal ˝ domain neve, aminek - hasonlóan a hoszt névhez - szintén érvényes DNS névnek kell lennie. A hosztnév és a gazda név együtt ponttal elválasztva - a teljesen azonosított domain nevet7 adja. Ez az információ a /etc/hostname és a /etc/hosts fájlokban kerül tárolásra. Mindig meg kell gy˝oz˝odni arról, hogy minden olyan IP cím, ami a tuzfal ˝ interfészeihez kapcsolódik és a megfelel˝o domain név bejegyzés szerepel a /etc/hosts fájlban, ellenkez˝o esetben a tuzfal ˝ funkciói és/vagy indítása nem fog muködni, ˝ nem lesz megfelel˝o! A következ˝o lépés az installált hálózati interfészek konfigurálása. A telepít˝o rendszernek elegend˝o az els˝odleges interfész beállítása, a továbbiakat akár itt, akár a /etc/network/interfaces fájl szerkesztésével lehet konfigurálni. Az IP protokoll és a hálózati interfész összekapcsolásához a telepít˝o rendszernek szükséges megadni, melyik fizikai csatoló konfigurálásra kerül sor. Linux 7
Fully Qualified Domain Name – FQDN
124
˝ G. FÜGGELÉK. INSTALLÁLÁS KARAKTERES KÉPERNYOVEL
G.7. ábra. Partíció lecsatolása installálás közben
alatt az ethernet interfészek neve „eth” taggal kezd˝odik, és a kernel által észlelt sorrendnek megfelel˝oen kap sorszámot. Mivel az ethernet interfészek meghajtó moduljai nem kerülnek betöltésre az installálás során, itt választható ki, melyik modul betöltése történjen az els˝o indításkor a merevlemezr˝ol. A fizikai interfész kiválasztását követ˝oen a következ˝o kérdésekre kell válaszolni: 1. Az interfész IP címe, amelynek abba az IP címtartományba kell esnie, ahová az adott interfész csatlakozik, Ennek az IP címtartománynak a hálózati maszkja pontozott négyrészes formában8 . Egy C osztályú hálózati maszk értéke 255.255.255.0, 2. Az IP címtartomány hálózati azonosítója pontozott négyrészes formában, 3. Az IP címtartomány üzenetkezel˝o címe pontozott négyrészes formában. Ez természetesen a megadott címtartomány utolsó címe. Egy C osztályú hálózatban az üzenetkezel˝o utolsó tagjának értéke 255, 4. Az alapértelmezett átjáró címe pontozott négyrészes formában. Ezt elegend˝o a küls˝o interfészen megadni, és ez lesz a tuzfal ˝ alapértelmezett átjárója. Természetesen egy tuzfalnak ˝ egynél több interfésze van, így most lehet˝oség van a további interfészek és jellemz˝oik definiálására. Ezek konfigurálása hasonló az els˝onél végrehajtotthoz azzal a különbséggel, hogy alapértelmezett átjárót csak az els˝odleges interfésznél kell definiálni. Az interfész konfigurációt követ˝oen lehet a szakért˝o menü fstab pontját futtatni, hogy a /etc/fstab fájl létrejöjjön. 8
dotted quad - a maszk minden egyes bájtja decimális formában ponttal elválasztva.
G.4. A ROOT JELSZÓ BEÁLLÍTÁSA
125
G.4. A root jelszó beállítása A Zorp alapértelmezésben MD5 titkosítású jelszót használ. Ezt általában nem érzékeli a felhasználó eltekintve attól, hogy 8 karakternél hosszabb jelszó is használható. Hangsúlyozzuk a nehezen visszafejthet˝o jelszó szükségességét. Ajánljuk a legalább 8 karakter hosszú jelszót, ami tartalmazzon nagybetuket, ˝ számokat, speciális karaktereket (pl. <>&@{}-;:?) is. A passwd menüpont a szokásos GNU/Linux jelszó változtató parancsot hívja meg.
G.5. Az installálás befejezése Az installálás végén a lilo menüponttal installálni kell a LInux LOader-t a betöltésvezérl˝o rekordba, utána a umuontall menüpontot minden el˝oz˝oleg felcsatolt partíció lecsatolására, végül a reboot menüponttal újra kell indítani a számítógépet (G.8. ábra).
G.8. ábra. Az installálás befejezése
Ezzel véget ért az installálás els˝o fázisa.
G.5.1. Csomagok installálása Az installálás els˝o fázisa létrehozza a számítógépen az alaprendszert. Ez alkalmas a teljes csomag menedzselés végrehajtására, ami szükséges a Zorp ins-
126
˝ G. FÜGGELÉK. INSTALLÁLÁS KARAKTERES KÉPERNYOVEL
tallálása második fázisának elvégzésére, mert a Zorp néhány elemét csomagként kell installálni. Ahogy els˝o alkalommal az alaprendszer elindul, automatikusan kiválasztja a csomagok alapértelmezett választékát, és automatikusan felinstallálja azokat a CD-r˝ol. Egyes csomagok installálása után parancsokat kell futtatni (pl. az OpenSSHt a kulcsok generálása érdekében), amit az installálás utáni szkript végez el az adott csomagra. Ez a szkript kérdéseket tehet fel az alapértelmezett konfiguráció finomhangolására.
G.5.2. További szoftverek hozzáadása A Zorp GNU/Linux disztribúción alapul, így Debian csomagok adhatóak a tuzfalhoz, ˝ ha a megfelel˝o függ˝oségek rendelkezésre állnak. A dpkg vagy az apt-get parancsok használhatóak. F ONTOS ! Miel˝ott további csomagot installálna, gy˝oz˝odjön meg arról, hogy az nem veszélyezteti a tuzfal ˝ biztonságát!
Tárgymutató AIM, 89 alkalmazás, 9
HttpsPlug, 96 HttpsWebdav, 96 HttpTrans, 92 HttpWebdavNonTrans, 93 HttpWebdavTrans, 93
BalaBit, 22 Bell-LaPadule modell, 17
Icq2000, 96 Imap, 97 inband, 10 inbound, 54 inetd, 73 instances.conf, 54, 56 interfész, 119, 123, 124 internet, 17, 20, 54 intranet, 19, 20, 54 IPTables, 48 iptables.conf.in, 50, 82 iptables.conf.var, 50, 81 Irc, 97
chainer, 67 Compuserve, 89 Crystal box, 16 Cvs, 90 csomagszur˝ ˝ ok, 18 daemon, 73 DMZ, 19, 20, 54 DNAT, 10, 58 DNS, 24, 47, 48 fdisk, 118 Finger, 90 FQDN, 123 FtpAnonRO, 90 FtpAnonRW, 90 FtpRO, 90 FtpRW, 91
LAN, 14 Ldap, 97 Ldaps, 98 LdapsPlug, 98 listener, 9, 66, 70 logcheck, 75 LotusNotes, 99
Gopher, 91 GroupWiseClt, 91 GroupWiseSrv, 91
mail, 24 ISP szervere, 25 saját szerver, 24 MGMT, 20 Mssql, 103 Mysql, 103
HTTP, 25 HttpFilterNonTrans, 93 HttpFilterTrans, 92 HttpNonTrans, 92 Https, 94 HttpsFilter, 95
named, 74
127
128 NAT, 23, 49 nmap, 74, 75 NntpProxy, 98 NntpsPlug, 99 NntpsRW, 99 NTP, 48 ntpd, 74 ORA, 102 outband, 10 outbound, 54 Pgsql, 102 policy, 18 hálózati biztonságpolitika, 15 IT biztonsági, 19 szervezeti, 15 tuzfal, ˝ 18 vállalati biztonság, 13 policy.py, 50, 54, 59, 85 Pop3, 100 POP3, 24 Pop3s, 100 Pop3sConvert, 101 Pop3sPlug, 100 portmap, 73 postfix, 48, 74 Printer, 101 proxy, 58, 64, 67, 70 AIMProxy, 89 CopmuserveProxy, 89 CVSProxy, 90 FingerProxy, 90 FtpProxyAnonRO, 90 FtpProxyAnonRW, 90 FtpProxyRO, 90 FtpProxyRW, 91 GopherProxy, 91 GroupwiseClientProxy, 91 GroupwiseServerproxy, 91 HttpProxy, 92 HttpProxyNonTransparent, 92 HttpsPlug, 96 HttpsProxy, 94 HttpsProxyURIFilter, 95
TÁRGYMUTATÓ HttpsWebdavProxy, 96 ICQProxy, 96 ImapProxy, 97 IrcProxy, 97 LdapProxy, 97 LdapsProxy, 98 LdapsProxyPlug , 98 LotusNotesProxy, 99 LpProxy, 101 MSSQLProxy, 103 MyHttpURIFilterProxy, 92 MyHttpWebdavProxy, 93 MyNontransHttpURIFilterProxy, 93 MyNontransWebdavHttpProxy, 93 MySQLProxy, 103 NetbiosSSNProxy, 102 NntpProxy, 98 NntpProxyRW, 99 NNTPsProxy, 99 OraProxy, 102 PgsqlProxy, 102 Pop3Proxy, 100 Pop3sConvertProxy, 101 Pop3sPlugProxy, 100 Pop3sProxy, 100 RTSPProxy, 101 ShoutCastProxy, 102 SSHProxy, 103 TelnetProxy, 103 WhoisProxy, 104 python, 51, 63 receiver, 9, 66 router, 9, 23, 58, 64, 67 RTSP, 101 Samba, 102 service, 9, 67 Shoutcast, 102 SMTP, 24, 48 SNAT, 10, 58 SOCKS, 26 SSH, 103
TÁRGYMUTATÓ sshd, 74 syslog-ng, 74, 75 szerver, 23 szolgáltatás, 69, 75 Telnet, 103 tuzfal, ˝ 20, 23 tripwire, 75 UDP, 71 WAN, 14 Whois, 104 zóna, 9, 54, 67, 68 umbrella, 56 zorp, 74 zorpctl, 51
129
