diff --git a/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml index 7056746807..e74b28a122 100644 --- a/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/advanced-networking/chapter.sgml @@ -1,7912 +1,8063 @@ Egyéb haladó hálózati témák Áttekintés Ebben a fejezetben számos komolyabb hálózati témát fogunk tárgyalni. A fejezet elolvasása során megismerjük: az átjárók és az útválasztás alapjait; hogyan állítsunk be &ieee; 802.11 és &bluetooth; eszközöket; a &os; segítségével hogyan tudunk két hálózatot összekötni hálózati hidakon keresztül; hogyan indítsuk hálózatról egy lemez nélküli gépet; hogyan állítsunk be hálózati címfordítást; hogyan kapcsoljunk össze két számítógépet PLIP használatával; hogyan állítsuk be az IPv6 használatát egy &os;-s gépen hogyan állítsuk be az ATM használatát; hogyan engedélyezzük és használjuk a Közös címredundancia protokollt &os;-ben. A fejezet elolvasásához ajánlott: az /etc/rc könyvtárban található szkriptek mûködésének ismerete; az alapvetõ hálózati fogalmak ismerete; egy új &os; rendszermag beállításának és telepítésének ismerete (); a külsõ szoftverek telepítésének ismerete (). Coranth Gryphon Készítette: Átjárók és az útválasztás útválasztás átjáró alhálózat Egy gép egy másikat úgy tud megtalálni a hálózaton, ha erre létezik egy olyan mechanizmus, amely leírja, hogyan tudunk eljutni az egyiktõl a másikig. Ezt hívjuk útválasztásnak (routing). Az útvonal (route) címek egy párjaként adható meg, egy céllal (destination) és egy átjáróval (gateway). Ez a páros mondja meg, hogy ha el akarjuk érni ezt a célt, akkor ezen az átjárón keresztül kell továbbhaladnunk. A céloknak három típusa lehet: egyéni gépek, alhálózatok és az alapértelmezett. Az alapértelmezett útvonalat (default route) abban az esetben alkalmazzuk, ha semelyik más útvonal nem megfelelõ. Az alapértelmezett útvonalakról a késõbbiekben még beszélni fogunk. Három típusa van az átjáróknak: egyéni gépek, felületek (avagy linkek) és a hardveres Ethernet címek (MAC-címek). Példa Az útválasztás különbözõ területeit a következõ netstat parancs alapján fogjuk bemutatni: &prompt.user; netstat -r Routing tables Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 example.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.example.com link#1 UC 0 0 224 link#1 UC 0 0 alapértelmezett útvonal Az elsõ két sorban az alapértelmezett útvonalat (melyrõl részleteiben majd a következõ szakaszban fogunk szólni) és a localhost útvonalát láthatjuk. loopback eszköz A localhost címhez az útválasztási táblázatban a lo0 eszköz tartozik (a Netif oszlopban), amelyet loopback eszköznek is neveznek. Ez arra utasítja a rendszert, hogy az ide küldött csomagokat ne a helyi hálózaton küldje keresztül, hanem csak ezen a belsõ felületen, mivel úgyis oda jutnának vissza, ahonnan indultak. Ethernet MAC-cím A táblázatban a következõ sor egy 0:e0 kezdetû címet tartalmaz. Ez egy hardveres Ethernet cím, más néven MAC-cím. A &os; magától képes beazonosítani tetszõleges gépet (ebben a példában a test0 gépet) a helyi Ethernetes hálózaton és felvenni hozzá egy útvonalat, közvetlenül az ed0 Ethernetes csatolófelületen keresztül. Ehhez a típusú útvonalhoz tartozik még egy lejárati idõ is (a Expire oszlop), amely akkor kap szerepet, ha ennyi idõ elteltével nem kapunk semmilyen hírt a géprõl. Amikor ilyen történik, az géphez eddig nyilvántartott útvonal automatikusan törlõdik. Ezek a gépek a RIP (útvonal-információs protokoll, Routing Information Protocol) nevû mechanizmuson keresztül azonosítódnak, mely a legrövidebb út kiszámítása alapján határozza meg a helyi gépekhez vezetõ útvonalat. alhálózat A &os; a helyi alhálózat (10.20.30.255 és example.com, az alhálózathoz tartozó név) esetében is felvesz útvonalakat. A link#1 megnevezés a gépben található elsõ Ethernet-kártyát jelöli. Megfigyelhetjük, hogy rajta kívül nincs is több felülete. Mindegyik csoport (a helyi hálózati gépek és a helyi alhálózatokatok) útvonalait a routed nevû démon tartja automatikusan karban. Ha ez nem fut, akkor csak a statikusan definiált (vagyis az elõre megadott) útvonalak fognak létezni. A host1 sor a saját gépünkre vonatkozik, amelyet az Ethernet címe szerint ismerünk. Mivel mi vagyunk küldõ gép, a &os; tudni fogja, hogy ilyenkor az Ethernetes felület helyett a loopback eszközt (lo0) kell használnia. A két host2 sor arra mutat példát, amikor az &man.ifconfig.8; paranccsal álneveket hozunk létre (ennek konkrét okait lásd az Ethernetrõl szóló részben). A lo0 felület neve után szereplõ => szimbólum azt jelzi, hogy ez nem csak egy loopback felület (mivel a címe szintén a helyi gépre mutat), hanem a felület egy másik neve. Ilyen útvonalak csak az álneveket ismerõ gépeknél jelennek meg. A helyi hálózaton minden más gépnél egyszerûen csak a link#1 jelenik meg az ilyen útvonalak esetében. Az utolsó sor (a 224 céllal rendelkezõ alhálózat) a multicastre (többesküldésre) szolgál, amellyel majd egy másik szakaszban foglalkozunk. Végezetül az útvonalakhoz tartozó különféle tulajdonságok a Flags oszlopban láthatóak. Az alábbi rövid táblázatban összefoglaltunk közülük néhányat: U Up: az útvonal aktív H Host: az útvonal egyetlen gépre mutat G Gateway: az adott cél felé ezen a gépen keresztül küldjünk, amely majd kitalálja, hogy merre küldje tovább S Static: ez az útvonal statikus, nem a rendszer hozta létre automatikusan C Clone: ebbõl az útvonalból származtatunk új útvonalat azokhoz a gépekhez, amelyekhez csatlakozunk. Ilyen útvonalakat általában a helyi hálózatokban találhatunk W WasCloned: azt jelzi, hogy ezt az útvonalat egy helyi hálózatra mutató (klón, avagy Clone típusú) útvonal alapján hoztuk létre automatikusan L Link: az útvonal Ethernetes hardverhez kapcsolódik Alapértelmezett útvonalak alapértelmezett útvonal Amikor a helyi rendszernek fel kell vennie a kapcsolatot egy távoli géppel, ellenõrzi az útválasztási táblázatban, hogy létezik-e már hozzá valamilyen útvonal. Ha a távoli gép egy olyan alhálózatba esik, amelyet már el tudunk érni (klónozott útvonalak), akkor a rendszer megnézi, hogy a hozzátartozó felületen képes-e kapcsolatot létesíteni. Ha minden ismert útvonal csõdöt mond, akkor a rendszerünknek marad még egy utolsó esélye: az alapértelmezett útvonal használata. Ez az útvonal egy speciális átjáró útvonal (ebbõl általában csak egyetlen egy létezik a rendszerben) és tulajdonságai között mindig szerepel a c. A helyi hálózat gépei közül ez az átjáró az legyen, amelyik közvetlenül kapcsolódik a külsõ világhoz (PPP összeköttetéssel, DSL, kábelmodem, T1 vagy bármilyen más hálózati felületen keresztül). Amikor pedig magát a külsõ világ felé átjáróként szolgáló gépet állítjuk be, az alapértelmezett útvonal az internet-szolgáltatónk által megadott gép címe lesz. Vegyünk egy példát az alapértelmezett útvonalakra. Egy tipikus konfiguráció: [Helyi2] <--ether--> [Helyi1] <--PPP--> [ Szolg. ] <--ether--> [T1-ÁJ] A Helyi1 és Helyi2 gépek a hálózatunk tagjai. A Helyi1 az internet-szolgáltatót éri el egy betárcsázós PPP kapcsolaton keresztül. A PPP szerver a külsõ felületén keresztül a helyi hálózaton pedig egy másik átjáróhoz csatlakozik. Az egyes gépek alapértelmezett útvonalai így alakulnak: Gép Alapértelmezett átjáró Felület Helyi2 Helyi1 Ethernet Helyi1 T1-ÁJ PPP Gyakran felmerül a kérdés, hogy Miért (és hogy-hogy) a T1-ÁJ a Helyi1 gép számára az alapértelmezett átjáró és nem a szolgáltató azon szervere, amelyhez csatlakozott? Ne felejtsük el, hogy a PPP felület a szolgáltató helyi hálózatában a mi részünkre kap címet, és a itt az összes többi géphez tartozó útvonal automatikusan létrejön. Emiatt már eleve el tudjuk érni a T1-ÁJ gépet, ezért amikor a szolgáltatón keresztül küldünk, nincs szükségünk egy további lépcsõre. Általában a X.X.X.1 címet szokták a helyi hálózat átjárójának kiosztani. Ezért (az elõbbi példát újrahasznosítva) ha a helyi hálózatunkon a C osztályú 10.20.30 címtartományt használjuk, és a szolgáltatónkhoz a 10.9.9 címtartomány tartozik, akkor az alapértelmezett útvonalak a következõk lesznek: Gép Alapértelmezett útvonal Helyi2 (10.20.30.2) Helyi1 (10.20.30.1) Helyi1 (10.20.30.1, 10.9.9.30) T1-ÁJ (10.9.9.1) Az /etc/rc.conf állományon keresztül könnyen meg tudjuk adni az alapértelmezett útvonalat. A példánkban a Helyi2 gép /etc/rc.conf állományába kell felvennünk a következõ sort: defaultrouter="10.20.30.1" A &man.route.8; parancs használatával viszont akár közvetlenül is megtehetjük mindezt: &prompt.root; route add default 10.20.30.1 A &man.route.8; man oldalon olvashatunk arról bõvebben, hogy a hálózati útválasztási táblázatokat kézzel hogyan tudjuk módosítani. Kettõs hálózatú gépek kettõs hálózatú gépek Egy másik típusú konfigurációról is szót kell ejtenünk, ahol a gép egyszerre két hálózatnak is tagja. Gyakorlatilag az átjáróként üzemelõ számítógépek (mint például az, amelyik a fenti példában PPP kapcsolattal csatlakozott) ilyen kettõs hálózatú gépnek tekinthetõek. Ez a kifejezés azonban igazából csak azokra az esetekre illik, ahol a gép egyszerre két helyi hálózatban is megjelenik. Az egyik esetben a gépben két Ethernet kártya található, melyek mindegyike birtokol egy-egy hálózati címet az egyes alhálózatokon. De elõfordulhat az is, hogy a gépünkben csupán egyetlen Ethernet kártya van és az &man.ifconfig.8; segítségével álneveket hoztunk létre hozzá. Az elõbbi általában két fizikailag elkülönölõ Ethernet alapú hálózat esetében történik, míg az utóbbinál csak egyetlen fizikai hálózati szegmensrõl van szó, amely viszont logikailag két külön alhálózatot tartalmaz. Akármelyiket is vesszük, az útválasztási táblázatok úgy jönnek létre, hogy bennük a gép a másik alhálózat felé átjáróként (bejövõ útvonalként) lesz nyilvántartva. Ebben a konfigurációban a gép a két alhálózat között útválasztóként fog tevékenykedni, és gyakran valamelyik vagy éppen mind a két irányba be kell állítanunk valamilyen csomagszûrést vagy tûzfalazást. Ha azt szeretnénk, hogy ez a gép a két felület között továbbítson csomagokat, akkor a &os;-ben külön engedélyezni kell ezt a lehetõséget. A következõ szakaszban ennek részleteit tárjuk fel. Az útválasztók beállítása útválasztó A hálózati útválasztó nem csinál mást, csak továbbküldi az egyik felületén beérkezõ csomagokat egy másik felületére. Az internetes szabványok és a sokéves mérnöki tapasztalat azonban nem engedik, hogy a &os; Projekt alapértelmezés szerint is elérhetõvé tegye ezt a &os; rendszerekben. Ezt a lehetõséget az alábbi változó YES értékûre állításával lehet engedélyezni az &man.rc.conf.5; állományban: gateway_enable="YES" # Ez legyen YES, ha átjáróként akarunk üzemelni Ezzel lényegében a net.inet.ip.forwarding &man.sysctl.8; változó értékét állítjuk 1-re. Ha valamiért egy idõre szüneteltetni akarjuk a csomagok továbbküldését, akkor állítsuk a változó értékét 0-ra. BGP RIP OSPF Az új útválasztónak nem árt arról sem tudnia, hogy merre továbbítsa a forgalmat. Ha elég egyszerû a hálózatunk, akkor akár statikus útvonalakat is használhatunk. A &os; alapból tartalmazza a BSD-k esetén szabványos &man.routed.8; útválasztó démont, amely a RIP (v1 és v2) valamint az IRDP megoldásokat ismeri. A BGP v4, OSPF v2 és a többi fejlettebb útválasztási protokoll a net/zebra csomagban érhetõ el. Az ettõl bonyolultabb hálózati útválasztási feladatokhoz olyan kereskedelmi termékek is elérhetõek, mint például a &gated;. Al Hoang Írta: Statikus útvonalak beállítása Manuális konfiguráció Tegyük fel, hogy hálózatunk a következõ: INTERNET | (10.0.0.1/24) alapértelmezett átjáró internet felé | |az xl0 felület |10.0.0.10/24 +------+ | | A-utvalaszto | | (FreeBSD átjáró) +------+ | az xl1 felület | 192.168.1.1/24 | +--------------------------------+ 1. belsõ hálózat | 192.168.1.2/24 | +------+ | | B-utvalaszto | | +------+ | 192.168.2.1/24 | 2. belsõ hálózat Ebben a forgatókönyvben az A-utvalaszto a mi &os;-s gépünk, amely az internet felé vezetõ útválasztó szerepét játssza. Számára az alapértelmezett útvonal a 10.0.0.1, amelyen keresztül a külsõ világot tudja elérni. Feltételezzük, hogy a B-utvalaszto nevû gépet már eleve jól állítottuk be, ezért tudja merre kell mennie. (A kép alapján egyszerû: csak vegyünk fel egy alapértelmezett útvonalat a B-utvalaszto géphez, ahol így a 192.168.1.1 lesz az átjáró.) Ha megnézzük most az A-utvalaszto útválasztási táblázatát, akkor nagyjából a következõket fogjuk látni: &prompt.user; netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGS 0 49378 xl0 127.0.0.1 127.0.0.1 UH 0 6 lo0 10.0.0/24 link#1 UC 0 0 xl0 192.168.1/24 link#2 UC 0 0 xl1 Az A-utvalaszto útválasztási táblázata alapján jelen helyzetben nem lehet elérni a 2. belsõ hálózatot. Nincs ugyanis olyan útvonal, amely a 192.168.2.0/24 alhálózat felé vezetne. Ezt például úgy tudjuk megoldani, ha manuálisan felvesszük ezt az útvonalat. Az alábbi paranccsal hozzáadjuk a 2. belsõ hálózat elérését az A-utvalaszto útválasztási táblázatához, ahol a 192.168.1.2 lesz a következõ ugrási pont (next hop): &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 Most már az A-utvalaszto bármelyik gépet képes elérni a 192.168.2.0/24 hálózaton. Rögzített konfiguráció A fenti példa tökéletesen szemlélti a statikus útvonalak felvételét egy mûködõ rendszeren. Azonban ezzel az a gond, hogy az így megadott útválasztási információ nem marad meg a gép újraindítása után. Ezért az elõbbihez hasonló statikus útvonalakat inkább az /etc/rc.conf állományban rögzítsük: # A 2. belsõ hálózat elérését felvesszük statikus útvonalként static_routes="belsohalo2" route_belsohalo2="-net 192.168.2.0/24 192.168.1.2" A static_routes konfigurációs változó karakterláncok szóközzel tagolt felsorolását tartalmazza. Mindegyik karakterlánc egy útvonal neve. Az iménti példában csak egyetlen ilyen név szerepelt a static_routes értékében, amely a belsohalo2 volt. Utána beírtunk még egy konfigurációs változót is, amelynek a neve route_belsohalo2. Ide helyeztük a &man.route.8; parancsnak átadandó beállítás összes paraméterét. Ez pontosan olyan, mintha a következõ parancsot adtuk volna ki: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 Ezért kellett a "-net 192.168.2.0/24 192.168.1.2". Ahogy már korábban is említettük, a static_routes értékében több karakterláncot is megadhatunk, aminek segítségével egyszerre több statikus útvonalat is létrehozhatunk. A következõ sorok arra mutatnak példát, hogy a 192.168.0.0/24 és 192.168.1.0/24 hálózatok számára miként állítsunk be statikus útvonalakat a képzeletbeli útválasztónkon: static_routes="net1 net2" route_net1="-net 192.168.0.0/24 192.168.0.1" route_net2="-net 192.168.1.0/24 192.168.1.1" Az útvonalak terjedése útvonalterjedés Azt már tudjuk, hogyan adjuk meg a külvilág felé vezetõ útvonalakat, azonban arról még nem beszéltünk, hogy kívülrõl miként találnak meg bennünket. Annyit már megismertünk, hogy az útválasztási táblázatokban megadhatjuk a hálózaton azt a gépet, amelyen keresztül az adott címtartomány (a példában egy C osztályú alhálózat) felé küldhetünk, amely pedig továbbküldi a hozzá érkezõ csomagokat. Amikor a csatlakozunk az internet-szolgáltatónkhoz, a nála levõ útválasztási táblázatok úgy állítódnak be, hogy az alhálózatunk felé igyekvõ adatok a korábban létrejött PPP összeköttetésen keresztül jutnak el hozzánk. A világ többi részén levõ rendszerek viszont honnan fogják tudni, hogy a mi internet-szolgáltatónknak küldjenek? Van egy rendszer (ez leginkább a névszerverek elosztott információs adatbázisához hasonlít), ami nyilvántartja a pillanatnyilag kiosztott címtartományokat és megadja a csatlakozási pontjukat az internet gerinchálózatán. Ez a gerinc tulajdonképpen olyan fõvonalakból áll, amelyen keresztül a világban az országok között mozog az internet forgalma. A gerinchálózat mindegyik gépe tárolja a központi útválasztási táblázatok egy másolatát, ami a forgalmat egy adott hálózatról a megadott gerincbeli hordozóra irányítja át, végig az internet-szolgáltatók láncán egészen addig, amíg az el nem éri a hálózatunkat. A szolgáltatónk feladata, hogy a gépünk felé leágazásként (és így a felénk vezetõ útként) beregisztálja magát a gerinchálózat gépein. Ezt nevezik az útvonal terjedésének. Hibaelhárítás traceroute Néha gondok lehetnek az útvonal terjedésével, és egyes gépek nem képesek elérni minket. A &man.traceroute.8; parancs mind közül talán az egyik leghasznosabb ilyen helyzetekben, mivel ezzel fel tudjuk deríteni, hogy az útválasztás hol akad meg. Ugyanilyen jól hasznosítható azokban az esetekben, amikor látszólag nem tudunk elérni egy távoli gépet (tehát a &man.ping.8; csõdöt mond). A &man.traceroute.8; parancsnak annak a távoli gépnek a nevét kell megadnunk, amelyhez csatlakozni akarunk. Futása közben megjeleníti azokat az átjárókat, amelyeken keresztül csatlakozni próbál, akár sikerült elérni a célgépet, akár a kapcsolat hiánya miatt kudarcot vall. A parancs használatáról és mûködésérõl részletesebb információkat a &man.traceroute.8; man oldalán találunk. Útválasztás multicast esetén multicast útválasztás a rendszermag beállításai MROUTING A &os; alapból támogatja mind a multicastet használó alkalmazásokat, mind pedig a multicasthez tartozó útválasztást. Multicast esetében semmilyen speciális beállítás nem szükségeltetik, az ilyen alkalmazások egybõl el tudják érni ezt a lehetõséget. A multicast kérések útválasztásához azonban be kell építenünk némi támogatást a rendszermagba: options MROUTING Emellett még el kell indítanunk az &man.mrouted.8; démont is, amelyhez az /etc/mrouted.conf állományban még be kell állítanunk tunneleket és a DVMRP használatát. A multicasthez tartozó további beállításokat az &man.mrouted.8; man oldalán találhatjuk. A &os; 7.0 megjelenésével a &man.mrouted.8; démont kivették az alaprendszerbõl. Azt a DVMRP többesküldési protokollt valósítja meg, amelyet a legtöbb alkalmazásban mostanság már a &man.pim.4; segítségével oldanak meg. Ennek megfelelõen a hozzátartozó multicast protokollt valósítja meg, amelyet a legtöbb alkalmazásban mostanság már a &man.pim.4; segítségével oldanak meg. Ennek megfelelõen a hozzátartozó &man.map-mbone.8; és &man.mrinfo.8; segédprogramok is eltávolításra kerültek. Ezek a programok attól a kiadástól kezdõdõen a Portgyûjtemény részeként érhetõek el a net/mrouted portban. Loader Marc Fonvieille Murray Stokely Vezeték nélküli hálózatok vezeték nélküli hálózatok 802.11 vezeték nélküli hálózatok A vezeték nélküli hálózatok alapjai A legtöbb vezeték nélküli hálózat az &ieee; 802.11 szabványon nyugszik. Az alapvetõ vezeték nélküli hálózatokban több olyan állomást találhatunk, amelyek egymással rádiójelek szórásával kommunikálnak a 2,4 GHz vagy 5 GHz frekvenciatartományban (noha ez a helyi viszonyoknak megfelelõen változhat, és a 2,3 GHz, illetve a 4,9 GHz tartományokban is lehetséges a kommunikáció). A 802.11 szabványú hálózatok kétféleképpen szervezõdnek. Elõször is infrastrukturálisan, (infrastructural mode) ahol az egyik állomást kinevezzük a központnak és a többi pedig ehhez fog tartozni. Az ilyen hálózatokat BSS-nek nevezzük és az imént említett központ neve hozzáférési pont (Access Point, AP) lesz. A BSS-ben az összes kommunikáció a hozzáférési pontokon keresztül halad még abban az esetben is, amikor az egyik állomás egy másik vezeték nélküli állomással akarja felvenni a kapcsolatot. Az ilyen jellegû hálózatok másik típusú szervezõdési módjában nincsenek kijelölt központok és a kommunikáció az állomások között közvetlenül zajlik. A hálózat ezen formáját IBBS-nek nevezzük, vagy ismeretebb nevén ad-hoc hálózatnak (ad-hoc network). A 802.11 alapú hálózatok elsõként a 2,4 GHz-es sávot hódították meg, és az &ieee; 802.11 valamint 802.11b szabványokban rögzített protokollokat használták. Ezekben a specifikációkban megtalálhatjuk a mûködési frekvenciát, a közeghozzáférési réteg jellemzõinek leírását, beleértve a keretezést és az átviteli sebességeket (a kommunikáció ugyanis eltérõ sebességekkel is történhet). A késõbb kiadott 802.11a szabvány azt specifikálja, hogy az 5 GHz-es tartományban miként mûködjenek, ahol többek közt megtalálhatjuk a különféle jelkezelési mechanizmusokat és a nagyobb átviteli sebességek használatát. Ezt még a 802.11g szabvány követte, ami a 802.11b hálózatokkal kompatibilis módon lehetõvé tette a 802.11a jelkezelésének és átviteli módszereinek használatát a 2,4 GHz-es sávban. A 802.11 alapú hálózatok mindenféle átviteli technikáitól eltekintve többféle biztonsági megoldással találkozhatunk. Az korai 802.11 dokumentumok egy nagyon egyszerû biztonsági protokollt, a WEP-et említenek. Ez a protokoll a hálózaton mozgó adatokat egy rögzített és ismert osztott kulccsal kódolja le az RC4 titkosítással. A kommunikációhoz az összes állomásnak elõre meg kell egyeznie ebben a kulcsban. Errõl a sémáról idõközben kiderült, hogy könnyen feltörhetõ és manapság már csak nagyon ritkán alkalmazzák, kivéve talán csak a kóbor felhasználók elijesztésére. A jelenleg érvényes biztonsági elõírásokat az &ieee; 802.11i specifikáció adja meg, amely új kriptográfiai titkosításokat definiál valamint egy további protokollt az állomások azonosítására és a kulcsok cseréjére. Emellett a titkosításhoz használt kulcsok idõszakosan frissülnek és külön eszközök állnak rendelkezésre a betörési kísérletek észlelésére (és azok elhárítására). A vezeték nélküli hálózatok esetében másik elterjedt titkosítási protokoll a WPA. Ez igazából 802.11i elõdjének tekinthetõ, amelyet egy ipari csoport definiált, amíg a 802.11i minõsítés alatt állt. A WPA ennek megfelelõen teljesíti a 802.11i szabvány elvárásainak egy részét és kifejezetten a régi hardverek számára készült. A WPA mûködéséhez egyedül a TKIP titkosításra van szükségünk, amely az eredeti WEP titkosításból származik. A 802.11i engedi a TKIP használatát, de az adatok kódolására egy erõsebb titkosítás, az AES-CCM ismeretét is igényli. (Az AES a WPA esetében nem kell, mivel a régi eszközök esetében túlságosan költségesnek ítélték meg a használatát.) A fenti szabványokon kívül a 802.11e a másik fontos szabvány, amire tekintettel kell lennünk. Ez írja le a 802.11 hálózatokon a multimédiás alkalmazások közvetítéséhez, mint például a videók valós idejû lejátszásához vagy a VoIP (voice over IP) megvalósításához tartozó protokollokat. A 802.11i szabványhoz hasonlóan a 802.11e is magában foglal egy elõzetes specifikációt, amelyet WME (késõbb pedig már WMM)-nek neveznek. Ezt szintén egy ipari csoport definiálta a 802.11e részeként, amivel a 802.11e végsõ elfogadásáig tudják a multimédiás igényeket kiszolgálni. Amit a 802.11e és WME/WMM megoldásaival kapcsolatban érdemes tudnunk: a QoS (Quality of Service) protokoll és más egyéb fejlett közeghozzáférési protokollok segítségével a vezeték nélküli hálózatokban lehetõvé teszik a forgalom prioritás szerinti ütemezését. Ezen protokollok megfelelõ implementációjának segítségével tehát a fontosabb adatok nagy sebességû küldését és áramoltatását vagyunk képesek elérni. A &os; a 6.0 verzió óta ismeri a 802.11a, 802.11b és 802.11g szabványokon alapján mûködõ hálózatokat. A WPA és 802.11i biztonsági protokollok (a 11a, 11b és 11g szabványok bármelyike esetén) hasonlóképpen támogatottak, valamint a WME/WMM protokollok mûködéséhez szükséges QoS csak bizonyos vezeték nélküli eszközök esetében. Kezdeti beállítások A rendszermag beállítása A vezeték nélküli hálózatok használatához egy vezeték nélküli hálózati kártyára lesz szükségünk, valamint a rendszermagban is be kell állítani ehhez a megfelelõ támogatást. Ez utóbbit több különbözõ modulra szedték szét, és ezek közül csak azokat kell beállítani, amelyeket tényleg használni is fogunk. Elõször is tehát kell egy vezeték nélküli eszköz. Az elterjedtebb típusaik általában az Atheos által gyártott alkatrészeket tartalmazzák. Az ilyen fajtájú eszközöket az &man.ath.4; meghajtó kezeli, melyet úgy tudunk a rendszer indításakor betölteni, ha a /boot/loader.conf állományba felvesszük a következõ sort: if_ath_load="YES" Az Atheos meghajtója három különálló részre oszlik: maga a meghajtó (&man.ath.4;), a hardveres réteg, ami a chipfüggõ funkciókat kezeli (&man.ath.hal.4;) és a keretek küldésével kapcsolatban az átviteli sebesség megválasztását lehetõvé tevõ algoritmus (ez itt most az ath_rate_sample). Amikor ezt a támogatást modulként töltjük be, ezek a függõségek automatikusan feloldódnak. Ha az Atheos eszközök helyett valamelyik másikhoz tartozó modult szeretnénk használni, akkor például az Intersil Prism esetében a &man.wi.4; meghajtót kell megadnunk: if_wi_load="YES" A leírás további részeiben az &man.ath.4; eszközt fogjuk használni, minden más esetben ennek a nevét kell csak lecserélünk a példákban. A rendszerben elérhetõ vezeték nélküli meghajtók a &man.wlan.4; man oldal elején találhatóak. Ha a vezeték nélküli eszközünkhöz nem létezik natív &os;-s meghajtó, akkor az NDIS meghajtó segítségével akár közvetlenül a &windows;-os meghajtóját is használhatjuk. Az eszközmeghajtó beállításával együtt a 802.11 hálózatok támogatását is be kell töltenünk a rendszermagba. Ez az &man.ath.4; meghajtó esetében a legalább a &man.wlan.4;, wlan_scan_ap és wlan_scan_sta modulok betöltését jelenti. A &man.wlan.4; modul a vezetéknélküli eszköz meghajtóprogramjával együtt töltõdik be, míg a többi modult a /boot/loader.conf állomány használatával kell a rendszerindítás során betöltenünk: wlan_scan_ap_load="YES" wlan_scan_sta_load="YES" A &os; 7.X változataiban mind a wlan_scan_ap és wlan_scan_sta modulokra szükségünk van, más verziók esetén nem kell megadnunk ezeket. Emellett még azokra a modulokra is szükségünk van, amelyek a használni kívánt biztonsági protokollokhoz nyújtanak kriptográfiai támogatást. Ezek hivatalosan a &man.wlan.4; modul kérésére automatikusan betöltõdnek, azonban itt most manuálisan állítjuk be. Erre a célra a következõ modulokat találjuk: &man.wlan.wep.4;, &man.wlan.ccmp.4; és &man.wlan.tkip.4;. A &man.wlan.ccmp.4; és &man.wlan.tkip.4; meghajtók csak akkor fognak kelleni, ha a WPA és/vagy a 802.11i biztonsági protokollokat használjuk. Amennyiben a hálózatunk teljesen nyitott (azaz nincs titkosítás), akkor még a &man.wlan.wep.4; támogatás sem kell. Ezeket a modulok úgy lehet betölteni a rendszerindításnál, ha felvesszük a következõ sorokat a /boot/loader.conf állományba: wlan_wep_load="YES" wlan_ccmp_load="YES" wlan_tkip_load="YES" Miután ezt megcsináltuk, egyszerûen csak indítsuk újra a gépünket. Ha még nem akarjuk újraindítani a gépet, akkor a &man.kldload.8; parancs segítségével akár kézzel is betölthetjük az elõbb felsorolt modulokat. Ha nem akarunk modulokat használni, a mûködéshez szükséges meghajtókat a rendszermagba is be tudjuk építeni a következõ sorok megadásával a rendszermag beállításait tartalmazó állományban: device ath # Atheros IEEE 802.11 vezeték nélküli hálózati meghajtó device ath_hal # az Atheros meghajtó hardveres rétege device ath_rate_sample # SampleRate forgalomvezérlési algoritmus device wlan # a 802.11 támogatása options AH_SUPPORT_AR5416 # az AR5416 tx/rx leírók engedélyezése device wlan_scan_ap # a 802.11 AP módú keresés device wlan_scan_sta # a 802.11 STA módú keresés device wlan_wep # 802.11 WEP támogatás device wlan_ccmp # 802.11 CCMP támogatás device wlan_tkip # 802.11 TKIP támogatás Hozzátesszük, hogy a &os; 7.X változatában a wlan_scan_ap és wlan_scan_sta modulok megadása egyaránt kötelezõ, más verzióknál viszont nem. Az elõbbiek megadásával fordítsuk újra és telepítsük a rendszermagot, majd indítsuk újra a számítógépünket. Miután a rendszerünk újra elindult, a rendszer indítás során generált üzenetei között találnunk kell valamennyi információt a felismert vezeték nélküli eszközökrõl. Például: ath0: <Atheros 5212> mem 0xff9f0000-0xff9fffff irq 17 at device 2.0 on pci2 ath0: Ethernet address: 00:11:95:d5:43:62 ath0: mac 7.9 phy 4.5 radio 5.6 Az infrastrukturális mûködési mód Általában az infrastrukturális avagy a BBS mód használata a gyakori. Ebben a mûködési módban adott számú vezeték nélküli hozzáférési pont csatlakozik a hagyományos hálózatra. Mindegyik vezeték nélküli hálózatnak saját neve van, amit a hálózat SSID-jének hívunk. A vezeték nélküli kliensek ezekhez a vezeték nélküli hozzáférési pontokhoz kapcsolódnak. A &os;-s kliensek használata Hogyan keressünk hozzáférési pontokat A hálózatok kereséséhez az ifconfig paranccsal tudunk nekifogni. Egy ilyen kérés kiszolgálása eltarthat néhány pillanatig, mivel ekkor a rendszernek végig kell bóklásznia az összes elérhetõ frekvenciát és azokon hozzáférési pontok után kutatni. Egyedül a rendszeradminisztrátor kezdeményezheti ezeket a kereséseket: &prompt.root; ifconfig ath0 up scan SSID BSSID CHAN RATE S:N INT CAPS dlinkap 00:13:46:49:41:76 6 54M 29:3 100 EPS WPA WME freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 EPS WPA Csak jelzésû felületen tudunk hálózatokat keresni. További keresésekre már nincs szükség a felület állapotban tartásához. A keresés során keletkezõ listában láthatjuk megtalált BBS vagy IBBS fajtájú hálózatokat. A hálózatok neve és SSID-ja mellett még megjelenik egy BSSID oszlop is, ahol a hozzáférési pontok MAC-címe szerepel. A CAPS oszlop az egyes állomások tulajdonságait adja meg: E Extended Service Set (ESS): az állomás egy infrastrukturális vagyis BBS hálózat része. I IBSS/ad-hoc hálózat: az állomás egy ad-hoc hálózat része. P Privacy: a BBS-en belül minden keretet titkosítani kell. Tehát a BSS arra kötelezi az állomást, hogy WEP, TKIP vagy AES-CCMP titkosítás használatával kódolja a hálózat tagjai között közlekedõ kereteket. S Short Preamble: a hálózatban rövid bevezetõjeleket használnak (a 802.11b High Rate/DSSS PHY elõírásai szerint), ahol a szokványos 128 bites szinkronizációs mezõ hossza csak 56 bit. s Short Slot Time: a 802.11g hálózat rövid slotidõt használ, mivel nem találhatóak benne régi (802.11b szabványú) állomások. A jelenleg ismert hálózatok listáját így tudjuk lekérdezni: &prompt.root; ifconfig ath0 list scan Ezt az információt maga az adapter automatikusan, vagy a felhasználó tudja frissíteni a kérés kiadásával. Az elavult adatok maguktól törlõdnek a gyorsítótárból, így idõvel a lista zsugorodni fog, hacsak nem keresünk folyamatosan hálózatokat. Alapvetõ beállítások Ebben a szakaszban arra mutatunk példákat, hogy miként tudunk &os; alatt titkosítás nélkül használni egy vezeték nélküli hálózati kártyát. Miután elsajátítottuk az itt szereplõ ismereteket, határozottan javasoljuk, hogy a vezeték nélküli hálózatunkat WPA használatával állítsuk be. A vezeték nélküli hálózatok beállítása három elemi lépésbõl épül fel: a hozzáférési pont kiválasztása, az állomásunk hitelesítése és az IP-cím beállítása. A következõkben ezeket a lépéseket vitatjuk meg. A hozzáférési pont kiválasztása A legtöbb esetben hagyjuk, hogy a rendszer válassza ki magának a különbözõ heurisztikák alapján a leginkább megfelelõ hozzáférési pontot. Ez az alapértelmezett tevékenység, amikor aktiváljuk a felületet vagy valamilyen más módon, például az/etc/rc.conf állományból hivatkozunk rá: ifconfig_ath0="DHCP" Ha viszont több hozzáférési pont közül mi magunk akarunk kiválasztani egyet, akkor ezt az SSID megadásával tehetjük meg: ifconfig_ath0="ssid saját_ssid DHCP" Amikor olyan környezetben vagyunk, ahol több hozzáférési pontnak is megegyezik az SSID-ja (gyakran így próbálják egyszerûsíteni azt, hogy automatikusan váltani lehessen köztük), akkor szükségünk lehet ezt egy adott eszközhöz hozzárendelni. Ebben az esetben a hozzáférési pont BSSID-ját is definiálni kell (és az SSID-t akár el is hagyhatjuk): ifconfig_ath0="ssid saját_ssid bssid xx:xx:xx:xx:xx:xx DHCP" Más módokon is képesek vagyunk szabályozni a hozzáférési pontok megválasztását, például a rendszerünk által vizsgált frekvenciasávok megadásával. Ez olyankor tud hasznos lenni, ha többsávos vezeték nélküli kártyánk van, és az összes tartomány végigpásztázása túlságosan sok idõt venne el. Ezt a mûvelet a paraméter megadásával lehet egy konkrét sávra leszûkíteni, például a ifconfig_ath0="mode 11g ssid saját_ssid DHCP" beállítás hatására a kártya 802.11g módban fog üzemelni, ami kizárólag csak 2,4 GHz-es frekvenciákon használható, így az 5 GHz-es csatornákat egyszerûen figyelmen kívül hagyjuk. Ugyanezt a paraméterrel is meg tudjuk oldani, mivel így a mûködést egy adott frekvenciára korlátozzuk, valamint a paraméterrel, ahol a pásztázandó csatornákat sorolhatjuk fel. Ezekrõl a paraméterekrõl részletesebb leírást az &man.ifconfig.8; man oldalon találhatunk. Hitelesítés Miután sikeresen kiválasztottuk a számunkra megfelelõ hozzáférési pontot, az adatok küldéséhez az állomásunknak valamilyen módon hitelesítenie kell magát. A hitelesítés több módon történhet. Erre a leggyakrabban alkalmazott sémát nyílt hitelesítésnek (open authentication) nevezik, ahol a hálózathoz tetszõleges állomás csatlakozhat és kommunikálhat vele. Ezt a típusú hitelesítést akkor érdemes használni, amikor a vezeték nélküli hálózatunkat teszteljük. Más sémákban az adatfolyam megindításához egy titkosítási kézfogás szükséges, vagy elõre megosztott kulcsok esetleg jelszavak segítségével, vagy bonyolultabb sémák esetében itt még olyan különbözõ háttérszolgáltatások is megjelennek, mint például a RADIUS. A legtöbb felhasználó a nyílt hitelesítést használja, ami egyben az alapértelmezés is. A másik legelterjedtebb beállítás a WPA-PSK, avagy WPA Personal, amelyrõl lentebb még szólni fogunk. Ha &apple; &airport; Extreme Base Station típusú hozzáférési pontunk van, akkor az osztott kulcsú hitelesítés mellett egy WEP kulcsot is be állítanunk. Ezt az /etc/rc.conf állományban vagy a &man.wpa.supplicant.8; programban tehetjük meg. Ha egyetlen &airport; bázisállomásunk van, akkor az elérést valahogy így tudjuk beállítani: ifconfig_ath0="authmode shared wepmode on weptxkey 1 wepkey 01234567 DHCP" Általánosságban véve elmondhatjuk, hogy az osztott kulcsú hitelesítést inkább kerüljük el, mivel WEP kulcsok használatára alapszik és ráadásul olyan módon, hogy nagyon könnyû feltörni. Ha már mindenképpen a WEP mellett kell döntenünk (például a régebbi eszközökkel így tudunk csak kompatibilisek maradni), akkor jobban járunk, ha a nyílt hitelesítéshez alkalmazzuk. A WEP használatát érintõ további információkat a ban találjuk. IP-cím szerzése DHCP használatával Miután kiválasztottunk egy hozzáférési pontot és beállítottuk a hitelesítés paramétereit, egy IP-cím is kelleni fog a kommunikációhoz. Az esetek túlnyomó részében DHCP-n keresztül kapunk IP-címet a vezeték nélküli kapcsolatunkhoz. Ezt úgy érhetjük el, ha egyszerûen megnyitjuk az /etc/rc.conf állományt és az alábbihoz hasonló módon felvesszük a DHCP paramétert az eszközünk beállításaihoz: ifconfig_ath0="DHCP" Így már készen is állunk a vezeték nélküli felület használatára: &prompt.root; /etc/rc.d/netif start Ahogy a felület mûködõképessé válik, az ifconfig parancs segítségével ellenõrizni is tudjuk az ath0 felület állapotát: &prompt.root; ifconfig ath0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid dlinkap channel 6 bssid 00:13:46:49:41:76 authmode OPEN privacy OFF txpowmax 36 protmode CTS bintval 100 A status: associated azt jelenti, hogy sikeresen csatlakoztunk egy vezeték nélküli hálózathoz (jelen esetben ez a dlinkap). A bssid 00:13:46:49:41:76 rész a hozzáférési pont MAC-címét tartalmazza. Az authmode pedig arról számol be, hogy a kommunikáció nem titkosított (OPEN). Statikus IP-cím Ha valami okból nem tudjuk az IP-címünket DHCP szerveren keresztül lekérni, beállíthatunk rögzített IP-címet is. Ehhez nem kell mást tennünk, mint a korábban bemutatott DHCP kulcsszót kicserélni egy konkrét címmel. A hozzáférési ponthoz megadott többi paramétert azonban feltétlenül hagyjuk meg: ifconfig_ath0="ssid saját_ssid inet 192.168.1.100 netmask 255.255.255.0" WPA A WPA (Wi-Fi Protected Access, vagyis védett wi-fi hozzáférés) a 802.11 szabványokban használatos biztonsági protokoll, amelyet a WEP gyengeségeinek és megfelelõ hitelesítésének ellensúlyozására dolgoztak ki. A WPA a 802.1X hitelesítési protokolljait erõsíti és az adat sértetlenségének megõrzésére a WEP helyett több titkosítási algoritmust is felhasznál. A WPA által igényelt egyetlen titkosítás a TKIP (Temporary Key Integrity Protocol, vagyis az ideiglenes kulcs integritási protokoll), amely a WEP által az integritás ellenõrzésére és a bejutások észlelésére és azok reagálására szánt alap RC4 titkosítást bõvíti ki. A TKIP a régebbi hardvereken csupán szoftveres módosítással mûködõképessé tehetõ. Ez a kompromisszum a védelmet ugyan növeli, de még mindig kevés a támadások megfelelõ elhárításához. A WPA a TKIP mellett tartalmazza még az AES-CCMP titkosítást is, és ennek a használata javasolt. Ezt a specifikációt gyakran WPA2 (vagy RSN) néven emlegetik. A WPA definiál hitelesítési és titkosítási protokollokat. A hitelesítés általában a következõ két technika egyike alapján történik: vagy 802.1X és egy háttérszolgáltatás, például a RADIUS segítségével, vagy egy elõre megosztott kulcsot alkalmazó minimális kézfogással az állomás és a hozzáférési pont között. Az elõbbit gyakran WPA Enterprise-nak, míg az utóbbit WPA Personalnak hívják. Mivel a legtöbben nem állítanak be egy komplett RADIUS alapú szervert a vezeték nélküli hálózatukhoz, ezért a WPA-PSK a WPA leginkább elterjedten használt változata. A vezeték nélküli kapcsolat és a hitelesítés (kulcs alapján vagy szerverrel) vezérlését a &man.wpa.supplicant.8; segédprogram végzi. Ennek a programnak mûködéséhez egy konfigurációs állományra van szüksége, amely az /etc/wpa_supplicant.conf néven érhetõ el. Errõl az állományról bõvebb információt a &man.wpa.supplicant.conf.5; man oldalán lelhetünk. WPA-PSK A WPA-PSK, más néven WPA-Personal, egy adott jelszó alapján generált elõre megosztott kulcssal (pre-shared key, PSK) mûködik, amit a vezeték nélküli hálózatokban mesterkulcsént használnak. Ez azt jelenti, hogy minden egyes vezeték nélküli felhasználó ugyanazon a kulcson osztozik. A WPA-PSK olyan kis méretû hálózatok esetében megfelelõ, ahol a hitelesítést elvégzõ szerver használata nem lehetséges vagy nem oldható meg. Mindig igyekezzünk erõs jelszavakat használni, melyek kellõen hosszúak és sokféle karaktert tartalmaznak, és így nehezebben fejthetõek meg vagy törhetõek fel. Elõször az /etc/wpa_supplicant.conf állományban állítsuk be az SSID-t és a hálózatunkhoz tartozó elõre megosztott kulcsot: network={ ssid="freebsdap" psk="freebsdmall" } Ezután az /etc/rc.conf állományban jelezzük, hogy a vezeték nélküli eszközt a WPA segítségével állítjuk be és az IP-címet a DHCP szervertõl kérjük el: ifconfig_ath0="WPA DHCP" Innentõl már fel is tudjuk éleszteni a felületet: &prompt.root; /etc/rc.d/netif start Starting wpa_supplicant. DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 6 DHCPOFFER from 192.168.0.1 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.254 -- renewal in 300 seconds. ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 Kézzel is megpróbálhatjuk elindítani az elõbb elkészített /etc/wpa_supplicant.conf állomány használatával: &prompt.root; wpa_supplicant -i ath0 -c /etc/wpa_supplicant.conf Trying to associate with 00:11:95:c3:0d:ac (SSID='freebsdap' freq=2412 MHz) Associated with 00:11:95:c3:0d:ac WPA: Key negotiation completed with 00:11:95:c3:0d:ac [PTK=TKIP GTK=TKIP] A következõ parancs a dhclient indítása legyen, amivel megszerezzük a DHCP szervertõl az IP-címünket: &prompt.root; dhclient ath0 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.254 -- renewal in 300 seconds. &prompt.root; ifconfig ath0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 Ha az /etc/rc.conf állományban szerepel a ifconfig_ath0="DHCP" sor, akkor egyáltalán nem szükséges a dhclient parancs manuális kiadása, mivel a dhclient magától el fog indulni, miután a wpa_supplicant egyeztette a kulcsokat. Amikor a DHCP nem használható, megadhatunk a statikus IP-címet is, miután a wpa_supplicant sikeresen lebonyolította a hitelesítést: &prompt.root; ifconfig ath0 inet 192.168.0.100 netmask 255.255.255.0 &prompt.root; ifconfig ath0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/36Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 Ha egyáltalán nem használunk DHCP szervert, akkor nekünk kell beállítani az alapértelmezett átjárót és a névszervert is: &prompt.root; route add default alapértelmezett_átjáró &prompt.root; echo "nameserver névszerver" >> /etc/resolv.conf WPA és EAP-TLS A másik mód, ahogy a WPA használható, az a 802.1X hitelesítési szerveren keresztül történik, és ebben az esetben a WPA neve WPA-Enterprise. Ez sokkal biztonságosabb a WPA-Personal elõre kiosztott kulcsaival szemben. A WPA-Enterprise az EAP (Extensible Authentication Protocol, azaz Bõvíthetõ hitelesítési protokoll) használatán alapszik. Az EAP önmaga nem végez titkosítást, mivel úgy alakították ki, hogy magát az EAP protokollt kell egy titkosított járaton keresztül bújtatni. Az EAP hitelesítési módszereinek több típusát is kidolgozták, melyek közül a legismertebbek az EAP-TLS, EAP-TTLS valamint a EAP-PEAP. Az EAP-TLS (EAP szállítási rétegbeli védelemmel) a vezeték nélküli világban egy nagyon jól támogatott hitelesítési protokoll, mivel ez volt az elsõ EAP módszer, amit a Wi-fi szövetség jóváhagyott. Az EAP-TLS mûködéséhez három tanúsítvány kell: egy hitelesítõ hatóságtól (Certificate Authority, CA), egy a hitelesítést végzõ szervertõl és egy a klienstõl. Ezzel az EAP módszerrel mind a hitelesítõ szerver, mind a vezeték nélküli kliens külön képviselik a saját tanúsítványaikat, és ezeket a szervezetünket hitelesítõ hatóság aláírása alapján ellenõrzik. A korábbiaknak megfelelõen a beállításokat szintén az /etc/wpa_supplicant.conf állományon keresztül végezzük el: network={ ssid="freebsdap" proto=RSN key_mgmt=WPA-EAP eap=TLS identity="loader" ca_cert="/etc/certs/cacert.pem" client_cert="/etc/certs/clientcert.pem" private_key="/etc/certs/clientkey.pem" private_key_passwd="freebsdmallclient" } Ez a mezõ adja meg a hálózat nevét (SSID). Itt az RSN (&ieee; 802.11i), vagyis a WPA2 protokollt használjuk. A key_mgmt sor a kulcskezelési protokollt adja meg. A mi esetünkben ez a WPA lesz, EAP hitelesítéssel: WPA-EAP. Ebben a mezõben az EAP módszert nevezzük meg a kapcsolathoz. Az identity mezõ az EAP esetén használt azonosítót tartalmazza. A ca_cert mezõ a hitelesítõ hatóság tanúsítványát tároló állomány elérési útvonalát adja meg. Ezt a szerver tanúsítványának hitelesítéséhez használjuk. A client_cert sor a kliens tanúsítványát tartalmazó állomány elérési útvonalát adja meg. Ennek a vezeték nélküli hálózat minden egyes kliense esetében egyedinek kell lennie. A private_key mezõ a kliens tanúsítvánáynak privát kulcsát tároló állomány elérési útját adja meg. A private_key_passwd mezõ a privát kulcshoz tartozó jelmondatot rögzíti. Az /etc/rc.conf állományba vegyük fel a következõ sort: ifconfig_ath0="WPA DHCP" A következõ lépés a felület felébresztése lesz az rc.d eszköz segítségével: &prompt.root; /etc/rc.d/netif start Starting wpa_supplicant. DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 Természetesen, ahogy azt már az elõbbiekben is megmutattuk, mindezt manuálisan is el tudjuk végezni a wpa_supplicant és az ifconfig parancsok segítségével. WPA és EAP-TTLS Az EAP-TLS használatakor mind a hitelesítést végzõ szervernek és kliensnek is kell tanúsítvány, azonban az EAP-TTLS ( szállítási rétegbeli védelem EAP tunnelen keresztül) esetében a kliensnél ez elhagyható. Ez a módszer nagyjából olyan, mint amit a webes oldalak csinálnak, ahol a webszerverek egy védett SSL tunnelt képeznek még akkor is, amikor a látogatók nem rendelkeznek kliens oldali tanúsítvánnyal. Az EAP-TTLS egy titkosított TLS tunnelen keresztül védi le a hitelesítési adatok forgalmát. Ezt ismét az /etc/wpa_supplicant.conf állományon keresztül tudjuk beállítani: network={ ssid="freebsdap" proto=RSN key_mgmt=WPA-EAP eap=TTLS identity="test" password="test" ca_cert="/etc/certs/cacert.pem" phase2="auth=MD5" } Ebben a mezõben az EAP módszert állítjuk be a kapcsolathoz. Az identity mezõ a titkosított TLS tunnelen keresztül az EAP hitelesítésnél felhasznált azonosítót adja meg. A password tartalmazza az EAP hitelesítésnél használt jelmondatot. A ca_cert mezõ hivatkozik a hitelesítõ hatóság tanúsítványát tartalmazó állományra. Ez az állomány kell a szerver tanúsítványának ellenõrzéséhez. Ebben a mezõben a titkosított TLS tunnelben használt hitelesítési módszer nevezzük meg. Jelen esetünkben ez az EAP MD5-Challenge használatával. A belsõ hitelesítés fázisát gyakran csak phase2-nak (2. fázisnak) hívják. Mindezek mellett még a következõ sort is vegyük fel az /etc/rc.conf állományba: ifconfig_ath0="WPA DHCP" Ezután hozzuk mûködésbe a felületet: &prompt.root; /etc/rc.d/netif start Starting wpa_supplicant. DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 WPA és EAP-PEAP A PEAP (Védett EAP) az EAP-TTLS egyik alternatívájaként jött létre. A PEAP módszernek két változata van, melyek közül a leggyakoribb a PEAPv0/EAP-MSCHAPv2. A leírás további részében a PEAP elnevezéssel erre az EAP módszerre fogunk hivatkozni. A PEAP az EAP-TLS után a leginkább alkalmazott szabvány, más szóval, ha a hálózatunkban többféle operációs rendszer is megtalálható, akkor az EAP-TLS után valószínûleg a PEAP lesz a másik, amit mindegyik ismerni fog. A PEAP hasonló az EAP-TTLS-hez: szerver oldali tanúsítványokkal hitelesíti a klienseket és titkosított TLS tunnelt hoz létre a kliens és a hitelesítést végzõ szerver között, amivel segíti megóvni a hitelesítési információkat. Biztonság szempontjából az EAP-TTLS és a PEAP között az a különbség, hogy a PEAP hitelesítés a felhasználói nevet titkosítatlanul küldi és csak a jelszó megy át a titkosított TLS tunnelen. Az EAP-TTLS egyaránt a TLS tunnelt használja mind a felhasználói név, mind a jelszó esetében. Az EAP-PEAP beállításait az /etc/wpa_supplicant.conf állományba kell felvenni: network={ ssid="freebsdap" proto=RSN key_mgmt=WPA-EAP eap=PEAP identity="test" password="test" ca_cert="/etc/certs/cacert.pem" phase1="peaplabel=0" phase2="auth=MSCHAPV2" } Ebben a mezõben megadjuk, az EAP módszert használjuk a kapcsolathoz. Az identity mezõ az EAP hitelesítés során a titkosított TLS tunnelben átküldött azonosítót tartalmazza. A password mezõ az EAP hitelesítés során használt jelmondatot definiálja. A ca_cert mezõ a hitelesítõ hatóság tanúsítványát tartalmazó állomány elérési útját adja meg. Ez az állomány kell a szerver tanúsítványának ellenõrzéséhez. Ez a mezõ a hitelesítés elsõ fázisának (vagyis a TLS tunnel) paramétereit tartalmazza. A hitelesítést végzõ szervertõl függõen a hitelesítéshez meg kell adnunk bizonyos címkéket. A legtöbb esetben a címke a kliens oldali EAP titkosítás lesz, amit a peaplabel=0 használatával állítunk be. A részleteket a &man.wpa.supplicant.conf.5; man oldalon olvashatjuk. Ebben a mezõben a titkosított TLS tunnelben alkalmazott hitelesítést protokollt nevezzük meg. A PEAP esetében ez az auth=MSCHAPV2 lesz. A következõket kell még hozzátennünk az /etc/rc.conf állományhoz: ifconfig_ath0="WPA DHCP" Ezután már mûködésbe is hozhatjuk a felületet: &prompt.root; /etc/rc.d/netif start Starting wpa_supplicant. DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.20 bound to 192.168.0.254 -- renewal in 300 seconds. ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 36 protmode CTS roaming MANUAL bintval 100 WEP A WEP (Wired Equivalent Privacy, azaz kábellel egyenértékû titkosság) az eredeti 802.11 szabvány része. Nincs külön hitelesítési mechanizmusa, csupán a hozzáférés-vezérlés egy gyenge formájával találkozhatunk benne, amit azonban könnyen fel lehet törni. A WEP ifconfig parancs használatán keresztül állítható be: &prompt.root; ifconfig ath0 ssid saját_hálózat wepmode on weptxkey 3 wepkey 3:0x3456789012 \ inet 192.168.1.100 netmask 255.255.255.0 A weptxkey utal arra, hogy a küldés során WEP kulcsot használunk. Itt most egy harmadik kulcsot használtunk, amelynek egyeznie kell a hozzáférési pont beállításaival. Ha nem tudjuk pontosan, hogy milyen kulcsot használ a hozzáférési pont, akkor próbálkozzunk az 1 érték (vagyis az elsõ kulcs) megadásával. A wepkey után következik a kiválasztott WEP kulcs. index:kulcs alakban kell megadni, és ha itt nem adunk meg indexet, akkor azzal az 1 indexû kulcsot állítjuk be. Úgyis fogalmazhatnánk, hogy az indexet csak olyankor kell megadni, amikor nem az elsõ kulcsot akarjuk használni. A 0x3456789012 értéket a hozzáférési pontnál beállított kulcsra kell beállítani. Ha érdekelnek minket a további részletek, akkor bátran lapozzuk fel az &man.ifconfig.8; parancs man oldalát. A wpa_supplicant segédprogramot is bevonhatjuk a vezeték nélküli felületek WEP alapú használatába. A fenti példát a következõ módon tudjuk leírni az /etc/wpa_supplicant.conf állományban: network={ ssid="sajat_halozat" key_mgmt=NONE wep_key3=3456789012 wep_tx_keyidx=3 } Majd: &prompt.root; wpa_supplicant -i ath0 -c /etc/wpa_supplicant.conf Trying to associate with 00:13:46:49:41:76 (SSID='dlinkap' freq=2437 MHz) Associated with 00:13:46:49:41:76 Az ad-hoc mûködési mód Az IBSS vagy más néven ad-hoc módot pont-pont típusú kapcsolatok kialakítására tervezték. Például, ha az A és a B gépek között egy ad-hoc típusú hálózatot akarunk létesíteni, akkor egyszerûen csak ki kell választanunk két IP-címet és egy SSID-t. Így állítjuk be az A gépet: &prompt.root; ifconfig ath0 ssid freebsdap mediaopt adhoc inet 192.168.0.1 netmask 255.255.255.0 &prompt.root; ifconfig ath0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::211:95ff:fec3:dac%ath0 prefixlen 64 scopeid 0x4 ether 00:11:95:c3:0d:ac media: IEEE 802.11 Wireless Ethernet autoselect <adhoc> (autoselect <adhoc>) status: associated ssid freebsdap channel 2 bssid 02:11:95:c3:0d:ac authmode OPEN privacy OFF txpowmax 36 protmode CTS bintval 100 Az adhoc paraméterrel utalunk arra, hogy a felület most IBSS módban mûködik. A B gépen ezután már képesek vagyunk észlelni az A gépet: &prompt.root; ifconfig ath0 up scan SSID BSSID CHAN RATE S:N INT CAPS freebsdap 02:11:95:c3:0d:ac 2 54M 19:3 100 IS A kimenetben szereplõ I is megerõsíti, hogy az A gépet ad-hoc módban érjük el. Így már csak a B gépet kell beállítanunk egy másik IP-címmel: &prompt.root; ifconfig ath0 ssid freebsdap mediaopt adhoc inet 192.168.0.2 netmask 255.255.255.0 &prompt.root; ifconfig ath0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect <adhoc> (autoselect <adhoc>) status: associated ssid freebsdap channel 2 bssid 02:11:95:c3:0d:ac authmode OPEN privacy OFF txpowmax 36 protmode CTS bintval 100 Most már mind az A és mind a B készen áll az adatok cseréjére. &os; alapú hozzáférési pontok A &os; képes hozzáférési pontként (Access Point, AP) is üzemelni, így nem kell külön hardveres hozzáférési pontot vásárolnunk vagy ad-hoc hálózatot használnunk. Ez különösen akkor hasznos, amikor a &os; gépet egy másik hálózat (például az internet) felé állítottuk be átjárónak. Alapvetõ beállítások Mielõtt nekiállnánk a &os;-s gépünket hozzáférési pontnak beállítani, egy olyan rendszermagra lesz szükségünk, amely tartalmazza a megfelelõ vezeték nélküli támogatást a kártyánkhoz. Emellett az alkalmazni kívánt biztonsági protokollok támogatását is bele kell építenünk. Ennek részleteit lásd a ban. Jelenleg az NDIS meghajtón keresztül használt &windows;-os meghajtók nem teszik lehetõvé hozzáférési pontok kialakítását. Egyedül a vezeték nélküli eszközök natív &os;-s meghajtói ismerik a hozzáférési pont módot. Ahogy betöltöttük a vezeték nélküli hálózatok támogatását, egybõl ellenõrizni is tudjuk, hogy a vezeték nélküli eszközünk használható-e hozzáférési pontként (avagy hostap módban): &prompt.root; ifconfig ath0 list caps ath0=783ed0f<WEP,TKIP,AES,AES_CCM,IBSS,HOSTAP,AHDEMO,TXPMGT,SHSLOT,SHPREAMBLE,MONITOR,TKIPMIC,WPA1,WPA2,BURST,WME> A fenti kimenetben láthatjuk a kártyánk tulajdonságait. A HOSTAP szó arról tanúskodik, hogy a vezeték nélküli kártyánk képes hozzáférési pontként viselkedni. Mellette még a különféle támogatott titkosítási módszerek is láthatóak: WEP, TKIP, WPA2 stb. Ezekbõl az információkból tudjuk kideríteni, hogy a hozzáférési pontunkon milyen titkosítási protokollokat tudunk használni. A vezeték nélküli eszközünket most már átállíthatjuk hozzáférési pontnak, amihez megadunk még egy SSID-t és egy IP-címet: &prompt.root; ifconfig ath0 ssid freebsdap mode 11g mediaopt hostap inet 192.168.0.1 netmask 255.255.255.0 Az ifconfig parancs ismételt használatával le is tudjuk kérdezni az ath0 felület állapotát: &prompt.root; ifconfig ath0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::211:95ff:fec3:dac%ath0 prefixlen 64 scopeid 0x4 ether 00:11:95:c3:0d:ac media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap> status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode OPEN privacy OFF txpowmax 38 bmiss 7 protmode CTS burst dtimperiod 1 bintval 100 A hostap paraméterbõl kiderül, hogy a felület hozzáférési pont módban van. Ha az /etc/rc.conf állományban megadjuk a következõ sort, akkor a felület beállítása a rendszer indításakor magától megtörténik: ifconfig_ath0="ssid freebsdap mode 11g mediaopt hostap inet 192.168.0.1 netmask 255.255.255.0" Hitelesítés vagy titkosítás nélküli hozzáférési pontok Habár a hozzáférési pontok mûködtetése nem javasolt hitelesítés vagy titkosítás nélkül, ebben a módban könnyen meg tudunk gyõzõdni a hozzáférési pontunk használhatóságáról. Ez a típusú konfiguráció ezenkívül még fontos szerepet játszik a klienseken felbukkanó hibák kiszûrésében is. Miután sikerült az elõbbiekben bemutatottak alapján beállítani a hozzáférési pontunkat, egy másik vezeték nélküli géprõl rögtön meg is kezdhetjük a keresését: &prompt.root; ifconfig ath0 up scan SSID BSSID CHAN RATE S:N INT CAPS freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 ES Láthatjuk, hogy a kliens megtalálta a hozzáférési pontot és tudunk is rá kapcsolódni: &prompt.root; ifconfig ath0 ssid freebsdap inet 192.168.0.2 netmask 255.255.255.0 &prompt.root; ifconfig ath0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::211:95ff:fed5:4362%ath0 prefixlen 64 scopeid 0x1 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:11:95:d5:43:62 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode OPEN privacy OFF txpowmax 36 protmode CTS bintval 100 WPA titkosítást használó hozzáférési pontok Ebben a szakaszban a &os;-s hozzáférési pontunkat WPA titkosítással állítjuk be. A WPA és a WPA alapú kliensek beállításának részleteit a ban találjuk. A WPA titkosítást használó hozzáférési pontokon a hostapd démon foglalkozik a kliensek hitelesítésével és a kulcsok kezelésével. A továbbiakban az összes beállítást egy olyan &os;-s gépen végezzük el, amely hozzáférési pontként mûködik. Ahogy sikerült beállítanunk a hozzáférési pont módot, az /etc/rc.conf állományban a következõ sor segítségével könnyen meg tudjuk oldani, hogy az hostapd démon a rendszerrel együtt magától elinduljon: hostapd_enable="YES" Mielõtt megpróbálnánk beállítani a hostapd démont, ne felejtsük el elvégezni a ban említett alapvetõ beállításokat sem. WPA-PSK A WPA-PSK használatát olyan kis méretû hálózatok számára szánják, ahol egy külön hitelesítõ szervert alkalmazása nem lehetséges vagy nem kívánatos. A konfiguráció az /etc/hostapd.conf állományon keresztül történik: interface=ath0 debug=1 ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=freebsdap wpa=1 wpa_passphrase=freebsdmall wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP TKIP Ebben a mezõben jelöljük ki a hozzáférési pontként használt vezeték nélküli felületet. Ebben a mezõben adjuk meg a hostapd futtatása során keletkezõ üzenetek részletességét. A példában szereplõ 1 érték ennek a legkisebb szintjét jelöli. A ctrl_interface mezõ megadja a hostapd által használt könyvtár elérési útvonalát, amiben azokat a tartományokhoz tartozó socketeket tároljuk, amelyeken keresztül olyan programokkal tudunk kommunikálni, mint például a &man.hostapd.cli.8;. Itt az alapértelmezett értéket írtuk be. A ctrl_interface_group sor beállítja azt a csoportot (ez jelen esetben a wheel), amin keresztül a vezérlõfelület (control interface) állományaihoz hozzá tudunk férni. Ebben a mezõben a hálózat nevét állítjuk be. A wpa mezõvel engedélyezzük a WPA használatát és megadjuk, hogy melyik WPA hitelesítési protokollt alkalmazzuk. Az itt szereplõ 1 érték a WPA-PSK hitelesítés állítja be a hozzáférési pont számára. A wpa_passphrase mezõ a WPA hitelesítéshez szükséges ASCII jelmondatot tartalmazza. Lehetõleg mindig erõs jelszavakat használjunk, amelyek kellõen hosszúak és sokféle karaktert tartalmaznak, így nehezebben fejthetõek meg vagy törhetõek fel. A wpa_key_mgmt sor a kulcsok kezelésére használt protokollt definiálja. Ez a mi esetünk most a WPA-PSK. A wpa_pairwise mezõ a hozzáférési pont által elfogadott titkosítási algoritmusokat határozza meg. A példában a TKIP (WPA) és CCMP (WPA2) titkosítást is támogatjuk. A CCMP titkosítás a TKIP egyik alternatívája, és lehetõség szerint használjuk ezt. A TKIP csak olyan állomások esetében javasolt, amelyek nem támogatják a CCMP használatát. A következõ lépés a hostapd elindítása: &prompt.root /etc/rc.d/hostapd forcestart &prompt.root; ifconfig ath0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2290 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::211:95ff:fec3:dac%ath0 prefixlen 64 scopeid 0x4 ether 00:11:95:c3:0d:ac media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap> status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA2/802.11i privacy MIXED deftxkey 2 TKIP 2:128-bit txpowmax 36 protmode CTS dtimperiod 1 bintval 100 A hozzáférési pont mostantól mûködik, innentõl a kliensek már képesek csatlakozni hozzá, bõvebben lásd a ban. A hozzáférési ponthoz tartozó állomásokat az ifconfig ath0 list sta paranccsal tudjuk listázni. WEP titkosítást használó hozzáférési pontok A WEP titkosítást nem javasoljuk a hozzáférési pontok esetében, mivel nem tartalmaz semmilyen hitelesítési mechanizmust és könnyen feltörhetõ. Egyes régebbi vezeték nélküli kártyák azonban csak a WEP által nyújtott védelmet ismerik, ezért az ilyenek csak olyan hozzáférési pontokhoz tudnak csatlakozni, amelyek vagy nem használnank hitelesítést és titkosítást, vagy erre a WEP protokollt használják. A vezeték nélküli eszközt tegyük hozzáférési pont módba és állítsuk be neki a megfelelõ SSID-t és IP-címet: &prompt.root; ifconfig ath0 ssid freebsdap wepmode on weptxkey 3 wepkey 3:0x3456789012 mode 11g mediaopt hostap \ inet 192.168.0.1 netmask 255.255.255.0 A weptxkey beállítás után adjuk meg a küldéshez használt WEP kulcsot. Itt a harmadik kulcsot adtuk meg (vegyük észre, hogy a kulcsok számozása az 1 értékkel kezdõdik). Ez a paramétert az adatok tényleges titkosításához kell megadni. A wepkey a kiválasztott WEP kulcs beállítását jelöli, aminek a formátuma index:kulcs. Ha itt nem adunk meg indexet, akkor automatikusan az elsõ kulcsot állítjuk be. Ezért talán mondanunk sem kell, hogy az indexet csak akkor kell megadni, ha nem az elsõ kulcsot akarjuk használni. A ath0 felület állapotának megtekintéséhez adjuk ki megint az ifconfig parancsot: &prompt.root; ifconfig ath0 ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::211:95ff:fec3:dac%ath0 prefixlen 64 scopeid 0x4 ether 00:11:95:c3:0d:ac media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap> status: associated ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode OPEN privacy ON deftxkey 3 wepkey 3:40-bit txpowmax 36 protmode CTS dtimperiod 1 bintval 100 Egy másik vezeték nélküli géprõl most már megpróbálhatjuk megkeresni a hozzáférési pontot: &prompt.root; ifconfig ath0 up scan SSID BSSID CHAN RATE S:N INT CAPS freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 EPS Láthatjuk, hogy a kliens megtalálta a hozzáférési pontot, és a megfelelõ paraméterekkel (kulcs stb.) képes kapcsolódni hozzá a ban leírtak szerint. - + + A vezetékes és vezeték + nélküli hálózatok együttes + használata + + A vezetékes hálózatok + általában jobb teljesítményt + nyújtanak és megbízhatóbbak, + miközben a vezeték nélküli + hálózatok pedig nagyobb rugalmasságot + és mozgásteret szolgáltatnak. Ezért + a hordozható számítógépek + tulajdonosaiban felmerülhet az igény, hogy egyszerre + mind a kettõt használva, tetszõlegesen + és problémamentesen válthassanak a + hálózatok között. + + &os; rendszereken ún. + hibatûrõ módon két vagy + akár több hálózati interfészt + össze tudunk vonni. Ennek köszönhetõen az + aktív hálózati kapcsolat + megszünésekor rendszerünk + önállóan igyekszik mindig a fennmaradó + elérhetõ hálózatok közül a + leginkább preferáltabbra váltani. + + A hálózati összeköttetések + összefûzésével és a + hibatûrés konkrét + megvalósításával az ban foglalkozunk, ahol a ban + láthatjuk is a vezetékes és vezeték + nélküli kapcsolatok együttes + használatának + beállítását. + + Hibaelhárítás Ha valamilyen gondunk lenne a vezeték nélküli hálózatok használatával, akad néhány lépés, amivel esetleg fel tudjuk deríteni a hiba okát. Ha nem látjuk a hozzáférési pontot a pásztázás után, ellenõrizzük, hogy a vezeték nélküli eszközt véletlenül nem korlátoztuk-e le bizonyos csatornákra. Ha nem tudunk csatlakozni a hozzáférési ponthoz, akkor egyeztessük vele az állomás egyes paramétereit, beleértve a hitelesítési sémát és a biztonsági protokollokat. Minél jobban egyszerûsítsük le a konfigurációkat. Ha WPA vagy WEP titkosítást használunk, akkor a hozzáférési ponton állítsunk be nyílt hitelesítést és kapcsoljuk ki a titkosítást, majd nézzük meg, hogy így eljut-e hozzánk valamilyen forgalom. Ahogy sikerült csatlakozunk a hozzáférési ponthoz, a biztonsági beállításokat olyan egyszerû eszközökkel próbáljuk meg diagnosztizálni, mint például a &man.ping.8;. A wpa_supplicant segédprogrammal tudunk nyomkövetést végezni. A opció megadásával indítsuk el manuálisan és ellenõrizzük a rendszernaplókat. Vannak alacsonyabb szintû nyomkövetési lehetõségek is. A 802.11 protokollt támogató rétegben is tudunk engedélyezni nyomkövetési üzeneteket a /usr/src/tools/tools/net80211 könyvtárban található wlandebug program segítségével. Például a &prompt.root; wlandebug -i ath0 +scan+auth+debug+assoc net.wlan.0.debug: 0 => 0xc80000<assoc,auth,scan> paranccsal a hozzáférési pontok kereséséhez és a 802.11 protokollon belül a kapcsolat megszervezéséhez szükséges kézfogásokhoz kapcsolódó konzolüzeneteket tudjuk engedélyezni. A 802.11 rétegben rengeteg hasznos statisztikát találhatunk. Mindezeket a wlanstats eszközzel tudjuk kiíratni. Ezeknek a statisztikáknak a 802.11 réteg összes hibáját be kell tudniuk azonosítaniuk. Vigyázzunk azonban, mert az eszközmeghajtókban a 802.11 réteg alatt rejlõ bizonyos hibák ilyenkor nem jelennek meg. Az eszközfüggõ problémák felderítésével kapcsolatban a megfelelõ meghajtó dokumentációját olvassuk át. Amennyiben a fenti tanácsok mentén sem sikerül orvosolnunk a hibát okát, küldjünk egy hibajelentést és mellékeljük hozzá a fentebb tárgyalt eszközök által gyártott kimeneteket. Pav Lucistnik Írta:
pav@FreeBSD.org
 Bluetooth Bluetooth Bevezetés A Bluetooth egy olyan vezeték nélküli technológia, amellyel a 2,4 GHz-es frekvenciatartományban tudunk személyi hálózatokat létrehozni 10 méteren belül. Az ilyen típusú hálózatok általában alkalmi jelleggel keletkeznek különféle hordozható eszközök, mint például mobiltelefonok, kézi számítógépek és laptopok között. Eltérõen más népszerû vezeték nélküli technológiáktól, például a wi-fitõl, a Bluetooth magasabb szintû szolgáltási profilokat is felajánl: FTP-szerû állományszervereket, az állományok áttolását, hang átküldését, soros vonali emulációt és még sok minden mást. A &os;-ben megvalósított Bluetooth protokollkészlet a Netgraph rendszerre építkezik (lásd &man.netgraph.4;). A Bluetooth alapú USB-s hardverzárak széles körét támogatja az &man.ng.ubt.4; meghajtó. A Broadcom BCM2033 chipre épített Bluetooth eszközöket az &man.ubtbcmfw.4; és az &man.ng.ubt.4; meghajtók támogatják. A 3Com Bluetooth PC Card 3CRWB60-A eszközt az &man.ng.bt3c.4; meghajtó támogatja. A soros és UART alapú Bluetooth eszközöket a &man.sio.4;, &man.ng.h4.4; és &man.hcseriald.8; ismeri. Ebben a szakaszban a Bluetooth alapú USB-s hardverzárak használatát mutatjuk be. Az eszköz csatlakoztatása Alapértelmezés szerint a Bluetooth eszközmeghajtók modulként érhetõek el. Az eszköz csatlakoztatása elõtt a megfelelõ meghajtót be kell töltenünk a rendszermagba: &prompt.root; kldload ng_ubt Ha a Bluetooth eszköz már a rendszer indításakor is jelen van, akkor a modult az /boot/loader.conf állományon keresztül is betölthetjük: ng_ubt_load="YES" Dugjuk be az USB-s hardverzárunkat. Az alábbihoz hasonló kimenet fog keletkezni a konzolon (vagy a rendszernaplóban): ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, wMaxPacketSize=49, nframes=6, buffer size=294 Az /etc/rc.d/bluetooth szkript fogja végezni a Bluetooth használatához szükséges protokollkészlet elindítását és leállítását. Jó ötlet leállítani az eszköz eltávolítása elõtt, de ha elhagyjuk, (általában) nem okoz végzetes hibát. Az indításkor a következõ kimenetet kapjuk: &prompt.root; /etc/rc.d/bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a Features: 0xff 0xff 0xf 00 00 00 00 00 <3-Slot> <5-Slot> <Encryption> <Slot offset> <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <Park mode> <RSSI> <Channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <Paging scheme> <Power control> <Transparent SCO data> Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8 HCI Host Controller Interface (HCI) A Host Controller Interface (HCI) egy parancsfelületet nyújt a mûködési sáv vezérlõjéhez (baseband controller) és az összeköttetések kezelõjéhez (link manager), valamint hozzáférést a hardverállapot és -vezérlõ regiszterekhez. Ez a felület egy egységes módszert szolgáltat a Bluetooth mûködési sávjához tartozó tulajdonságok eléréséhez. Az eszközön üzemelõ HCI réteg a Bluetooth hardverben található HCI firmware-rel vált adatokat és parancsokat. A Host Controller Transport Layer (vagyis a fizikai busz) meghajtója mind a két HCI réteget és a kettejük közti információcserét is elérhetõvé teszi. Az egyes Bluetooth eszközökhöz létrejön egy-egy hci típusú Netgraph-beli csomópont. Ez a HCI csomópont általában a Bluetooth eszközmeghajtó csomópontjához (lefelé) és az L2CAP csomóponthoz (felfelé) csatlakozik. Az összes HCI mûveletet a HCI csomóponton kell elvégezni és nem az eszközmeghajtóhoz tartozón. A HCI csomópont alapértelmezett neve a devicehci. Ezekrõl többet az &man.ng.hci.4; man oldalán tudhatunk meg. Az egyik legáltalánosabb feladat a Bluetooth eszközök esetében a közelben levõ további eszközök felderítése. Ezt a mûveletet tudakozódásnak (inquiry) nevezik. A tudakozódást és az összes többi HCI-hez kapcsolódó mûveletet a &man.hccontrol.8; segédprogrammal tudjuk elvégezni. A lentebb látható példa azt mutatja meg, hogyan tudunk Bluetooth eszközöket keresni egy adott távolságon belül. Az elérhetõ eszközök listáját néhány másodpercen alatt megkapjuk. A távoli azonban eszközök csak akkor fognak válaszolni, ha felderíthetõ (discoverable) módban vannak. &prompt.user; hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] A BD_ADDR a Bluetooth eszköz egyedi címe, hasonló a hálózati kártyák MAC-címéhez. Erre a címre lesz szükség ahhoz, hogy a továbbiakban kommunikálni tudjunk az eszközzel. Emberek számára értelmezhetõ nevet is hozzá tudunk rendelni a BD_ADDR címhez. Az /etc/bluetooth/hosts állomány tartalmazza a Bluetooth eszközökre vonatkozó információkat. A következõ példában azt láthatjuk, hogyan tudunk beszédesebb nevet adni egy távoli eszköznek: &prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav T39-ese Amikor tudakozódni kezdünk a távoli Bluetooth eszközök jelenléte felõl, a gépünket sajat.gep.nev (ubt0) néven fogják látni. Ez a helyi eszközhöz rendelt név bármikor megváltoztatható. A Bluetooth rendszer lehetõség ad pont-pont (természetesen csak két Bluetooth egység között) vagy pont-multipont típusú kapcsolatok kiépítésére. A pont-multipont kapcsolat esetén a kapcsolaton több Bluetooth eszköz osztozik. A most következõ példában megláthatjuk, hogyan kell az aktív mûködési sávban lekérdezni a helyi eszköz létrejött kapcsolatait: &prompt.user; hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN A kapcsolat azonosítója (connection handle) akkor hasznos, amikor egy sávbeli kapcsolatot akarunk lezárni. Ezt általában nem kell kézzel megcsinálni. A rendszer magától lezárja az inaktív sávbeli kapcsolatokat. &prompt.root; hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16] A hccontrol help paranccsal tudjuk lekérdezni az elérhetõ HCI parancsokat. A legtöbb HCI parancs végrehajtásához nem kellenek rendszeradminisztrátori jogosultságok. L2CAP Logical Link Control and Adaptation Protocol (L2CAP) A Logical Link Control and Adaptation Protocol (L2CAP) a kapcsolat-orientált és a kapcsolat nélküli adatszolgáltatásokért felelõs a felsõbb rétegek felé, valamit támogatja a protokollok többszörözését, a darabolást és az összerakást. Az L2CAP a magasabb szintû protokollok és az alkalmazások számára egészen 64 kilobyte méretig lehetõvé teszi az adatcsomagok küldését és fogadását. A L2CAP a csatorna (channel) fogalmára építkezik. A csatorna egy logikai kapcsolatot képvisel a mûködési sávon belüli kapcsolat felett. Mindegyik csatornához egyetlen protokoll kötõdik, egy a többhöz alapon. Több csatorna is tarthozhat ugyanahhoz a protokollhoz, de egy csatornán nem használhatunk több protokollt. A csatornákon keresztül érkezõ L2CAP csomagok ezután a megfelelõ felsõbb rétegbeli protokollokhoz kerülnek. Több csatorna osztozhat ugyanazon a sávbeli kapcsolaton. Minden Bluetooth eszközhöz létrejön egy l2cap típusú Netgraph-csomópont. Az L2CAP csomópont általában egy Bluetooth HCI csomóponthoz (lefelé) és egy Bluetooth sockethez (felfelé) kapcsolódik. Az L2CAP csomópont alapértelmezett neve devicel2cap. Errõl részletesebben az &man.ng.l2cap.4; man oldal világosít fel minket. Ezen a szinten hasznos parancsnak bizonyulhat az &man.l2ping.8;, amivel más eszközöket tudunk pingelni. Elõfordulhat, hogy egyes Bluetooth implementációk nem válaszolnak semmilyen feléjük küldött adatra, így az alábbi példában is szereplõ 0 bytes teljesen normális. &prompt.root; l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0 Az &man.l2control.8; segédprogram használható az L2CAP csomópontok különbözõ mûveleteinek kivitelezésére. Ebben a példában a helyi eszközhöz tartozó logikai kapcsolatokat (csatornák) és sávokat kérdezzük le: &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN &prompt.user; l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN Másik ugyanilyen diagnosztikai eszköz a &man.btsockstat.1;. Ha a viselkedését tekintjük, akkor leginkább a &man.netstat.1; programra hasonlít, de a Bluetooth hálózatban megjelenõ adatszerkezetekkel dolgozik. Az alábbi példa az iménti &man.l2control.8; parancs kimenetében szereplõ logikai kapcsolatokat mutatja: &prompt.user; btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN RFCOMM Az RFCOMM protokoll Az RFCOMM protokoll a soros portok emulációját valósítja meg az L2CAP protokollon keresztül. A protokoll az ETSI TS 07.10. RFCOMM szabványán alapszik, és egy egyszerû átviteli protokoll, amelyet a 9 tûs RS-232 (EIATIA-232-E) soros portok emulációjára készítettek fel. Az RFCOMM protokoll legfeljebb 60 kapcsolat (RFCOMM csatorna) párhuzamos használatát támogatja két Bluetooth eszköz között. Az RFCOMM számára a teljes kommunikációs útvonal két különbözõ eszközön futó alkalmazást (kommunikációs végpontot) és köztük levõ kommunikációs szegments foglalja magában. Az RFCOMM az adott eszközön a soros portot használó alkalmazások részére készült. A kommunikációs szegmens az egyik eszköztõl a másikig vezetõ Bluetooth alapú összeköttetés (közvetlen kapcsolat). Közvetlen kapcsolat esetén az RFCOMM csak az eszközök közti kapcsolattal foglalkozik, valamint hálózati kapcsolat esetén az eszköz és a modem közti kapcsolattal. Az RFCOMM más konfigurációkat is támogat, például olyan modulokat, amelyek az egyik oldalon a Bluetooth vezeték nélküli technológián keresztül kommunikálnak, míg a másik oldalon egy vonalas felületet nyújtanak. A &os;-ben az RFCOMM protokollt Bluetooth foglalatok rétegében valósították meg. párosítás Az eszközök párosítása Alapértelmezés szerint a Bluetooth kommunikáció nem hitelesítõdik és bármelyik eszköz képes bármelyik másikkal felvenni a kapcsolatot. Egy Bluetooth eszköz (például egy mobiltelefon) egy adott szolgáltatáshoz igényelhet hitelesítést (például betárcsázáshoz). A Bluetooth alapú hitelesítés többnyire PIN kódokkal történik. A PIN kód egy legfeljebb 16 karakterbõl álló ASCII karakterlánc. A felhasználóknak mind a két eszközön ugyanazt a PIN kódot kell megadniuk. Miután megadtuk a PIN kódot, az eszközök létrehoznak hozzájuk egy összekötettésbeli kulcsot (link key). Ezután ezt a kulcsot vagy az eszközökön tároljuk vagy pedig valamilyen tartós tárolón. A következõ alkalommal mind a két eszközt ezt a korábban elkészített kulcsot fogja használni. Ezt az eljárást nevezik párosításnak (pairing). Ha valamelyik eszköz elveszti az össszeköttetés kulcsát, akkor a párosítást meg kell ismételni. A &man.hcsecd.8; démon felelõs az összes Bluetooth alapú hitelesítési kérés lekezeléséért. Az alapértelmezett konfigurációs állománya az /etc/bluetooth/hcsecd.conf. Például így tudjuk benne egy mobiltelefonhoz megadni az 1234 PIN kódot: device { bdaddr 00:80:37:29:19:a4; name "Pav T39-ese"; key nokey; pin "1234"; } Semmilyen korlátozás nincs a PIN kódokra (a méretüktõl eltekintve). Egyes eszközökbe (például a Bluetooth fejhallgatók) elõre rögzített PIN kódot építettek bele. A kapcsoló hatására a &man.hcsecd.8; démont az elõtérben lehet futtatni, így könnyebben láthatjuk mi történik. A távoli eszközt állítsuk be a párosítás elfogadására és kezdeményezzünk felé egy Bluetooth kapcsolatot. A távoli eszköznek erre azt kell válaszolnia, hogy elfogadta a párosítást, majd kérni fogja a PIN kódot. Adjuk meg ugyanazt a PIN kódot, mint amit a hcsecd.conf állományba is beírtunk. Most már a gépünk és a távoli eszköz párban vannak. A párosítást a távoli eszközrõl is kezdeményezhetjük. A &os; 5.5, 6.1 és újabb változataiban az /etc/rc.conf állományba a következõ sort kell felvenni a hcsecd automatikus indításához: hcsecd_enable="YES" Ez pedig a hcsecd démon által generált kimenetre példa: hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 SDP Service Discovery Protocol (SDP) A Service Discovery Protocol (SDP) segítségével a kliens alkalmazások képes felderíteni, hogy a szerver alkalmazások részérõl milyen szolgáltatások érhetõek el, valamint ezek a szolgáltatások milyen tulajdonságokkal rendelkeznek. A szolgáltatások tulajdonsági közé soroljuk többek között a felajánlott szolgáltatás típusát vagy osztályát, illetve a szolgáltatás kihasználásához szükséges mechanizmusra vagy protokollra vonatkozó információkat. Az SDP az SDP szerver és az SDP kliens közti kommunikációt foglalja magában. A szerver karbantart egy listát azokról a szolgáltatási rekordokról, amelyek a szerverhez tartozó szolgáltatások jellemzõit írják le. Mindegyik ilyen szolgáltatási rekord egyetlen szolgáltatás adatait tartalmazza. A kliensek egy SDP kéréssel ezeket a szolgáltatási rekordokat kérhetik el az SDP szervertõl. Amennyiben a kliens, vagy a hozzátartozó alkalmazás a szolgáltatás használata mellett dönt, akkor a szolgáltatás használatához a megfelelõ szolgáltató felé nyitnia kell egy külön kapcsolatot. Az SDP csak a szolgáltatások és azok tulajdonságainak felderítéséhez ad segítséget, de semmilyen eszközt nem tartalmaz a felhasználásukra. Általában az SDP kliensek általában valamilyen számunkra kellõ tulajdonság alapján keresnek szolgáltatásokat. Ráadásul adódhatnak olyan alkalmak is, amikor a szolgáltatások elõzetes ismerete nélkül szeretnénk felderíteni a rendelkezésre álló szolgáltatások típusait. A felajánlott szolgáltatások ilyen típusú feldolgozását nevezzük böngészésnek (browsing). Az &man.sdpd.8; Bluetooth SDP szerver és a parancssoros &man.sdpcontrol.8; kliens az alap &os; telepítés része. Az alábbi példában egy SDP böngészési kérést adunk ki: &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse Record Handle: 00000000 Service Class ID List: Service Discovery Server (0x1000) Protocol Descriptor List: L2CAP (0x0100) Protocol specific parameter #1: u/int/uuid16 1 Protocol specific parameter #2: u/int/uuid16 1 Record Handle: 0x00000001 Service Class ID List: Browse Group Descriptor (0x1001) Record Handle: 0x00000002 Service Class ID List: LAN Access Using PPP (0x1102) Protocol Descriptor List: L2CAP (0x0100) RFCOMM (0x0003) Protocol specific parameter #1: u/int8/bool 1 Bluetooth Profile Descriptor List: LAN Access Using PPP (0x1102) ver. 1.0 és így tovább. Mindegyik szolgáltatáshoz hozzátartozik a tulajdonságok egy listája (például RFCOMM csatorna). Lehetséges, hogy szolgáltatástól függõen bizonyos tulajdonságokat kell figyelnünk. Egyes Bluetooth implementációk nem támogatják a szolgáltatások böngészését és ezért egy üres listát adnak vissza. Ebben az esetben egy konkrét szolgáltatásra tudunk rákeresni. A következõ példában az OBEX Object Push (OPUSH) szolgáltatást keressük: &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH &os; alatt az &man.sdpd.8; szerverrel tudunk szolgáltatásokat felajánlani a Bluetooth klienseknek. A &os; 5.5, 6.1 vagy késõbbi változataiban ehhez a következõ sort kell megadnunk az /etc/rc.conf állományban: sdpd_enable="YES" Ezután az sdpd démon így indítható el: &prompt.root; /etc/rc.d/sdpd start A távoli kliensek részére Bluetooth szolgáltatásokat felajánlani kívánó helyi szerver alkalmazásoknak regisztrálniuk kell magukat a helyi SDP démonnál. Például az egyik ilyen alkalmazás az &man.rfcomm.pppd.8;, és elindítása után regisztrálni fogja a Bluetooth LAN szolgáltatást a helyi SDP démonnál. A helyi SDP szerveren regisztrált szolgáltatásokat a helyi vezérlési csatornán keresztül egy browse kéréssel tudjuk lekérdezni: &prompt.root; sdpcontrol -l browse A betárcsázós hálózati és a PPP hálózati hozzáférési (LAN) profilok A betárcsázós hálózati (Dial-Up Networking, DUN) profil leggyakrabban a modemek és mobiltelefonok között tûnik fel. Ez a profil a következõ forgatókönyveket dolgozza fel: A számítógépünkkel egy mobiltelefont vagy modemet vezeték nélküli modemként használunk, amivel az internethez vagy más hálózatokhoz csatlakozunk betárcsázással. A számítógépünkkel egy mobiltelefonon vagy modemen keresztül fogadunk adathívásokat. A PPP hálózati hozzáférési (LAN) profil a következõ helyezetekben alkalmazható: LAN hozzáférés egyetlen Bluetooth eszközhöz LAN hozzáférés több Bluetooth eszközhöz Két gép összekötése (a soros vonali kapcsolat emulációval PPP-n keresztül) &os; alatt mind a két profilt a &man.ppp.8; és az &man.rfcomm.pppd.8; valósítja meg — egy olyan wrapper eszköz, amely az RFCOMM Bluetooth kapcsolatokat a PPP számára is értelmessé alakítja át. Mielõtt még bármelyik profilt elkezdenénk használni, egy új PPP címkét kell létrehozni az /etc/ppp/ppp.conf állományban. Erre példát az &man.rfcomm.pppd.8; man oldalon találhatunk. A következõ példában az &man.rfcomm.pppd.8; programot fogjuk használni arra, hogy egy RFCOMM típusú kapcsolatot nyissunk a 00:80:37:29:19:a4 címmel rendelkezõ távoli Bluetooth eszköz felé. A tényleges RFCOMM csatorna számát SDP-n keresztül a távoli eszköztõl kapjuk. Az RFCOMM csatorna kézzel is megadható, és ilyen esetekben az &man.rfcomm.pppd.8; nem fog SDP kérést küldeni. A &man.sdpcontrol.8; használatával tudjuk lekérdezni a távoli eszközön létrejött RFCOMM csatornát. &prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup A PPP hálózati elérés (LAN) szolgáltatás beindításához futni kell a &man.sdpd.8; szervernek. A helyi hálózaton keresztül csatlakozó kliensekhez létre kell hozni egy új bejegyzést az /etc/ppp/ppp.conf állományban. Az &man.rfcomm.pppd.8; man oldalon találhatunk erre példákat. Végezetül indítsuk el az RFCOMM PPP szervert egy érvényes RFCOMM csatornaszámmal. Az RFCOMM PPP szerver ekkor automatikusan regisztrálja a Bluetooth LAN szolgáltatást a helyi SDP démonnál. A következõ példában megmutatjuk, hogyan lehet elindítani egy RFCOMM PPP szervert: &prompt.root; rfcomm_pppd -s -C 7 -l rfcomm-server OBEX Az OBEX Object Push (OPUSH) profil Az OBEX egy széles körben alkalmazott protokoll a mobileszközök közti egyszerû állományvitelre. Legfõképpen az infravörös kommunikációban alkalmazzák, ahol a laptopok vagy PDA-k közti általános állományátvitelre használják, illetve névjegykártyák vagy naptárbejegyzések átküldésére mobiltelefonok között és egyéb PIM alkalmazást futtató eszközök esetében. Az OBEX szervert és klienst egy külsõ csomag, az obexapp valósítja meg, amelyet az comms/obexapp portból érhetünk el. Az OBEX kliens használható objektumok áttolására vagy lehúzására az OBEX szerverhez. Ez az objektum lehet például egy névjegykártya vagy egy megbeszélt találkozó. Az OBEX kliens SDP-n keresztül tud magának RFCOMM csatornaszámot szerezni. Ezt úgy tehetjük meg, ha a szolgáltatás neve helyett egy RFCOMM csatorna számát adjuk meg. A támogatott szolgáltatások: IrMC, FTRN és OPUSH. Számként RFCOMM csatorna is megadható. Az alábbi példában egy OBEX munkamenetet láthatunk, ahol az eszköz információs objektumát húzzuk le a mobiltelefonról és egy új objektumot (egy névjegykártyát) tolunk fel a telefon könyvtárába. &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get telecom/devinfo.txt devinfo-t39.txt Success, response: OK, Success (0x20) obex> put new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20) Az OBEX objektumok tologatásának támogatásához az &man.sdpd.8; szervernek kell futnia. Továbbá a beérkezõ objektumok tárolásához létre kell hoznunk még egy könyvtárat is. Ez az könyvtár alapértelmezés szerint a /var/spool/obex. Végül indítsuk el az OBEX szervert egy érvényes RFCOMM csatorna számának megadásával. Az OBEX szerver ezután automatikusan regisztrálja az OBEX Object Push nevû szolgáltatást a helyi SDP démonnál. Ebben a példában láthatjuk az OBEX szerver indítását: &prompt.root; obexapp -s -C 10 Soros vonali profil (SPP) A soros vonali profil (Serial Port Profile, SPP) használatával RS232 (vagy ahhoz hasonló) vonali adatátvitelt tudunk emulálni. Ez a profil a régebben fejlesztett alkalmazásokkal birkózik meg, és a Bluetooth technológiával valódi kábel helyett egy virtuális soros portot képez le. Az &man.rfcomm.sppd.1; segédprogram ezt a soros vonali profilt valósítja meg. Így egy pszeudo terminált tudunk virtuális soros portként használni. Ha nem adunk meg RFCOMM csatornát, akkor az &man.rfcomm.sppd.1; képes SDP-n keresztül kérni egyet magának a távoli eszköztõl. Ha ezt felül kívánjuk bírálni, akkor a parancssorban megadhatunk akár egy konkrét RFCOMM csatornát is. &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6... Miután csatlakoztunk, a pszeudo terminált tudjuk soros portként használni: &prompt.root; cu -l ttyp6 Hibaelhárítás Nem tudunk csatlakozni a távoli eszközzel Egyes Bluetooth eszközök nem támogatják a szerepek cseréjét (role switch). Alapértelmezés szerint amikor a &os; elfogad egy új kapcsolatot, megpróbál rajta szerepet cserélni és mesterré válni. Azok az eszközök, amelyek ezt nem támogatják, nem lesznek képesek emiatt csatlakozni. Ez a szerepváltás az új kapcsolatok felépítése során zajlik le, ezért egy távoli eszköztõl nem lehet megtudni, hogy ismeri-e ezt a lehetõséget. A helyi oldalon a következõ HCI opcióval lehet kikapcsolni a szerepcserét: &prompt.root; hccontrol -n ubt0hci write_node_role_switch 0 Valami nem megy. Lehet látni valahogy, pontosan mi is történik? Persze, igen. Egy külsõ csomag, a hcidump segítségével, amely a comms/hcidump portból érhetõ el. A hcidump segédprogram a &man.tcpdump.1; programhoz hasonlítható. Ezzel lehet a Bluetooth csomagok tartalmát megnézni a terminálon vagy elmenteni ezeket egy állományba. Andrew Thompson Írta: Hálózati hidak Bevezetés IP-alhálózat hálózati híd Gyakran hasznos lehet anélkül felosztani egy fizikai hálózatot (például egy Ethernet szegmenst) két külön hálózati szegmensre, hogy külön IP-alhálózatot kellene létrehozunk és összekötnünk ezeket egy útválasztóval. A két ilyen módon kialakított hálózatot összekötõ eszközt nevezzük hálózati hídnak (bridge). A legalább két hálózati felülettel rendelkezõ &os; rendszerek képesek hálózati híd szerepét betölteni. A hálózati híd az eszközök adatkapcsolati rétegben a hozzátartozó felületein megjelenõ (vagyis Ethernet) címének megtanulásával mûködik. A két hálózat között csak akkor közvetít forgalmat, amikor a forrás és cél nem ugyanabban a hálózatban található. A hálózati hidak bizonyos szempontból lényegében nagyon kevés porttal rendelkezõ Ethernet switch-ek. A hálózati hidak tipikus alkalmazásai Napjainkban akad néhány igen jellemzõ szituáció, ahol szükség van a hálózati hidak alkalmazására. Hálózatok összekötése A hálózati hidak alapvetõ feladata két vagy több hálózati szegmens összekötése. Az egyszerû hálózati környezet felállítása helyett több okból is felmerülhet a hidak létrehozása: kábelezési megszorítások, tûzfalazás vagy pszeudo hálózatok, például virtuális gépek felületének csatlakoztatása miatt. Egy híd használatával ráadásul össze tudunk kötni egy vezeték nélküli hozzáférési pontként üzemelõ felületet egy vezetékes hálózattal. Szûrés vagy forgalomkorlátozás tûzfallal tûzfal NAT Sokszor elõfordulhat, hogy útválasztás vagy hálózati címfordítás (NAT) nélkül szeretnénk tûzfalat használni. Példaként képzeljünk el egy olyan kis méretû céget, amely egy DSL vagy ISDN vonalon kapcsolódik az internet-szolgáltatójához. A szolgáltatótól 13, mindenki által használható IP-címet kaptak és a hálózatukban 10 gép van. Ebben a helyzetben egy útválasztást végzõ tûzfal mûködtetése nehézkessé válna az alhálózatok problémái miatt. útválasztó DSL ISDN Egy hídként viselkedõ tûzfallal azonban minden IP számozási probléma nélkül egyszerûen be tudjuk dobni a gépeket a DSL/ISDN útválasztó mögé. A hálózat megcsapolása Egy hálózati híddal úgy kapcsolunk össze két hálózati szegmenst, hogy közben meg tudjuk vizsgálni a kettejük között mozgó Ethernet kereteket. Ezt a híd felületen a &man.bpf.4; valamint a &man.tcpdump.1; segítségével tudjuk megoldani, vagy úgy, ha egy másik felületen elküldjük az összes keret másolatát (span, vagyis feszítõ port). VPN az adatkapcsolati rétegben A két Ethernet hálózatot egy IP alapú összeköttetésen keresztül is össze tudunk kötni, ha a hálózatokat egy EtherIP járaton keresztül kötjük össze híddal, vagy egy OpenVPN-hez hasonló &man.tap.4; alapú megoldással. Redundancia az adatkapcsolati rétegben A hálózatokat több linken keresztül kötjük össze és a redundáns útvonalakat a feszítõfa protokollal (Spanning Tree Protocol, STP). Az Ethernetes hálózatok esetében a megfelelõ mûködéshez a két eszköz között csak egyetlen aktív útvonal létezhet, így a feszítõfa protokoll észleli a hurkokat és a redundáns összeköttetéseket blokkolt állapotba teszi. Amikor azonban az aktív linkek egyike meghibásodik, akkor a protokoll újraszámolja a fát és a hálózati pontjai közti konnektivitást megpróbálja helyreállítani az addig blokkolt linkek ismételt engedélyezésével. A rendszermag beállításai Ebben a szakaszban az &man.if.bridge.4; hálózati híd implementációval foglalkozunk, de a Netgraph segítségével is tudunk hidakat építeni. Ez utóbbiról az &man.ng.bridge.4; man oldalon olvashatunk. Amikor létrehozunk egy hálózati hidat, az &man.ifconfig.8; automatikusan betölti a hozzátartozó meghajtót. Ha viszont a rendszermag beállításait tartalmazó állományba felvesszük a device if_bridge sort, akkor akár be is építhetjük a rendszermagba. A csomagszûrés minden olyan tûzfallal használható, amely a &man.pfil.9; rendszerre kapcsolódik. Maga a tûzfal is betölthetõ modulként, vagy belefordítható a rendszermagba. A hálózati híddal forgalmat is tudunk szabályozni az &man.altq.4; vagy a &man.dummynet.4; segítségével. A hálózati híd engedélyezése Hálózati hidak felületek klónozásával hozhatóak létre. A híd létrehozásához használjuk az &man.ifconfig.8; programot, és a megfelelõ meghajtó automatikusan betöltõdik, ha nem lenne még elérhetõ a rendszermagban. &prompt.root; ifconfig bridge create bridge0 &prompt.root; ifconfig bridge0 bridge0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 96:3d:4b:f1:79:7a id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0 Ekkor létrejön a hálózati hídhoz tartozó felület és véletlenszerûen generálódik hozzá egy Ethernetes cím. A maxaddr és a timeout paraméterek vezérlik, hogy a híd mennyi MAC-címet tartson meg a keretek továbbításáért felelõs táblázatban és mennyi másodperc után töröljön automatikusan egy bejegyzést a legutolsó használat után. A többi paraméter a feszítõfa mûködését irányítja. Vegyük fel a hídhoz tartozó hálózati tagfelületeket. A híd csak akkor fog a tagfelületek között csomagokat továbbküldeni, amikor a híd és a tagok is up állapotban vannak: &prompt.root; ifconfig bridge0 addm fxp0 addm fxp1 up &prompt.root; ifconfig fxp0 up &prompt.root; ifconfig fxp1 up A híd most már átküldi az Ethernet kereteket a fxp0 és fxp1 felületek között. Az iméntiekkel megegyezõ konfigurációt az /etc/rc.conf állományban így alakíthatjuk ki: cloned_interfaces="bridge0" ifconfig_bridge0="addm fxp0 addm fxp1 up" ifconfig_fxp0="up" ifconfig_fxp1="up" Ha a hídhoz IP-címet is rendelni akarunk, akkor inkább magánál a hídnál adjuk meg, ne a tagoknál. Ezt statikusan vagy DHCP használatával is megtehetjük: &prompt.root; ifconfig bridge0 inet 192.168.0.1/24 A hídhoz IPv6 címet is hozzá tudunk rendelni. Tûzfalazás tûzfalak Ha engedélyezzük a csomagszûrést, a hídon áthaladó csomagok elõször a küldõ felület érkezési oldalára kerülnek, majd a hídra, végül a megfelelõ irányban levõ felület küldési oldalára. Bármelyik fázis letiltható. Amikor a csomagok áramlásának iránya fontos számunkra, akkor jobban járunk, ha nem magára a hídra, hanem csak a tagfelületekre állítjuk be a tûzfalat. A híd számos módosítható beállítással rendelkezik a nem-IP és ARP csomagok átküldésére, valamint arra, hogy az IPFW tûzfal adatkapcsolati réteg szintjén mûködhessen. Az &man.if.bridge.4; man oldal ennek részleteit tárja fel. Feszítõfák A híd meghajtója a gyors feszítõfa protokollt (Rapid Spanning Tree Protocol, RSTP avagy 802.1w) valósítja meg, ami visszafelé kompatibilis a korábban említett feszítõfa protokollal. A feszítõfákat a hálózati topológiában felbukkanó hurkok észlelésére és eltávolítására alkalmazzák. Az RSTP azonban a hagyományos STP-nél valamivel gyorsabb konvergenciát ígér, mivel itt a szomszédos switch-ek kicserélik egymás között az adataikat, és így újabb hurkok létrehozása nélkül képesek viszonylag gyorsan egyik állapotból átváltani a másikba. Az alábbi táblázat a támogatott mûködési módokat láthatjuk: Operációs rendszer STP módok Alapértelmezés &os; 5.4—&os; 6.2 STP STP &os; 6.3+ RSTP vagy STP STP &os; 7.0+ RSTP vagy STP RSTP A tagfelületeken az stp paranccsal tudjuk engedélyezni a feszítõfák használatát. Az fxp0 és fxp1 felületeket összekötõ hídfelület esetében tehát így: &prompt.root; ifconfig bridge0 stp fxp0 stp fxp1 bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether d6:cf:d5:a0:94:6d id 00:01:02:4b:d4:50 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:01:02:4b:d4:50 priority 32768 ifcost 0 port 0 member: fxp0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 3 priority 128 path cost 200000 proto rstp role designated state forwarding member: fxp1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 4 priority 128 path cost 200000 proto rstp role designated state forwarding Láthatjuk, hogy a híd a feszítõfában megkapta a 00:01:02:4b:d4:50-es azonosítót és a 32768-as prioritást. Mivel root id értéke is ugyanez, elmondhatjuk, hogy ez a fa gyökereként funkcionáló híd. Ha a hálózaton már valahol létezik egy másik híd: bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 96:3d:4b:f1:79:7a id 00:13:d4:9a:06:7a priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:01:02:4b:d4:50 priority 32768 ifcost 400000 port 4 member: fxp0 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 4 priority 128 path cost 200000 proto rstp role root state forwarding member: fxp1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP> port 5 priority 128 path cost 200000 proto rstp role designated state forwarding A root id 00:01:02:4b:d4:50 priority 32768 ifcost 400000 port 4 sor mutatja, hogy a fa gyökerét képezõ híd most a 00:01:02:4b:d4:50 azonosítóval rendelkezik, és ezt a hidat 400000-res költséggel éri el a port 4 (a 4. porton) keresztül, amely jelen esetben az fxp0 felület. Komolyabb hidak építése A forgalom áramlásának átszerkesztése A hidak támogatják az ún. megfigyelési módot, ahol a csomagokat a &man.bpf.4; feldolgozásuk után eldobja, így nem folytatódik a feldolgozásuk vagy nem haladnak tovább. Ennek kihasználásával a két vagy több felületen érkezõ adatokat egyetlen &man.bpf.4; folyammá tudjuk alakítani. Ez olyan hálózati csapok forgalmának átszerkesztésében hasznos, ahol a két különbözõ felületen keresztül küldjük ki az RX/TX (fogadás/küldés) jeleket. Az alábbi paranccsal tudjuk megoldani, hogy négy felületrõl érkezõ adatot legyünk képesek egyetlen folyamként olvasni: &prompt.root; ifconfig bridge0 addm fxp0 addm fxp1 addm fxp2 addm fxp3 monitor up &prompt.root; tcpdump -i bridge0 Feszítõ portok A hídhoz befutó Ethernet keretek mindegyikérõl készül egy másolat, ami egy megadott feszítõ porton keresztül megy tovább. Hidanként végtelen számú ilyen feszítõ port létezhet, és ha egy felületet feszítõ portnak adtunk meg, akkor hagyományos portként már nem használhatjuk. Ez leginkább akkor hasznos, amikor passzívan akarjuk megfigyelni a híddal rendelkezõ hálózatot a híd valamelyik feszítõ portjára csatlakozó géprõl. Küldessük az összes keretrõl egy másolatot az fxp4 felületre: &prompt.root; ifconfig bridge0 span fxp4 Privát felületek A privát felületek (private interface) csak más privát felületek felé küldenek tovább adatot. Így feltétel nélkül tudjuk korlátozni a forgalmat, és sem Ethernet keretek, sem pedig ARP nem megy keresztül rajtuk. Ha viszont szelektíven akarjuk korlátozni a forgalmat, akkor helyette használjunk tûzfalat. Tapadós felületek Ha a híd egyik tagfelületét tapadósnak (sticky) adjuk meg, akkor a dinamikusan megtanult címek bejegyzései a gyorsítótárba kerülésük után állandósulnak. A tapadós bejegyzések soha nem évülnek el vagy cserélõdnek le, még abban az esetben sem, ha utána az adott címet egy másik felületrõl látjuk. Így a továbbításra vonatkozó táblázatot nem kell elõre feltöltenünk, és a híd egyik oldalán meglátott kliensek nem képesek átvándorolni egy másik hálózati szegmensbe. Másik ilyen példa a tapadós címek használatára az lehetne, amikor a hidat VLAN-nal kombináljuk, és így egy olyan útválasztót hozunk létre, ahol az ügyfeleink az IP-címtartomány pocséklása nélkül zárhatóak el egymástól. Tegyük fel, hogy az A-ugyfel a vlan100, és a B-ugyfel a vlan101 felületen csatlakozik. A híd IP-címe 192.168.0.1, amely maga is egy internet felé mutató útválasztó. &prompt.root; ifconfig bridge0 addm vlan100 sticky vlan100 addm vlan101 sticky vlan101 &prompt.root; ifconfig bridge0 inet 192.168.0.1/24 Mind a két kliens a 192.168.0.1 címet látja alapértelmezett átjáróként, és mivel a híd gyorsítótára tapadós bejegyzéseket tartalmaz, a MAC-címeik meghamisításával nem tudják elcsípni a másikuk forgalmát. A VLAN-ok közti bárminemû kommunikációt privát felületek létrehozásával akadályozzuk meg (vagy egy tûzfallal): &prompt.root; ifconfig bridge0 private vlan100 private vlan101 Ezzel a megoldással az ügyfeleinket teljesen elszigeteljük egymástól úgy, hogy közben az egész /24 címtartomány külön alhálózatok kialakítása nélkül kiosztható. Címek korlátozása Korlátozhatóak az egy felület mögül küldeni képes egyedi MAC-címek. Amikor ezen a határon felül érkeznek ismeretlen feladótól csomagok, egészen addig eldobjuk ezeket, amíg egy korábban már regisztrált bejegyzést a rendszer ki nem töröl vagy ki nem veszünk a gyorsítótárból. A következõ példában az vlan100 felületen csatlakozó A-ugyfel számára korlátozzuk le 10-re az Ethernet eszközök számát: &prompt.root; ifconfig bridge0 ifmaxaddr vlan100 10 SNMP felügyelet A hidak és az STP paraméterei az alap &os; rendszerben megtalálható SNMP démonnal felügyelhetõek. A hídhoz exportált felügyeleti információk (Management Information Base, MIB) megfelelnek az IETF által elõírt szabványoknak, így akár tetszõleges SNMP kliens vagy bármilyen más felügyeleti szoftver alkalmas az olvasásukra. A hidat mûködtetõ gépen az /etc/snmp.config állományban engedélyezzük a begemotSnmpdModulePath."bridge" = "/usr/lib/snmp_bridge.so" sort és indítsuk el a bsnmpd démont. Itt még szükség lehet más beállítások, például a közösségek nevének (community name) vagy a hozzáférési listák (access list) módosítására is. Ezzel kapcsolatban a &man.bsnmpd.1; és az &man.snmp.bridge.3; man oldalakat lapozzuk fel. A következõ példában a Net-SNMP nevû szoftver (net-mgmt/net-snmp) fogjuk használni a híd elérésére, de ugyanerre a net-mgmt/bsnmptools port is alkalmas. Az SNMP klienst használó gépen egészítsük ki az $HOME/.snmp/snmp.conf állományt a híd felügyeleti információinak importálásával az Net-SNMP rendszerébe: mibdirs +/usr/share/snmp/mibs mibs +BRIDGE-MIB:RSTP-MIB:BEGEMOT-MIB:BEGEMOT-BRIDGE-MIB Az IETF BRIDGE-MIB (RFC 4188) használatán keresztül így tudjuk elindítani egy híd felügyeletét: &prompt.user; snmpwalk -v 2c -c public bridge1.example.com mib-2.dot1dBridge BRIDGE-MIB::dot1dBaseBridgeAddress.0 = STRING: 66:fb:9b:6e:5c:44 BRIDGE-MIB::dot1dBaseNumPorts.0 = INTEGER: 1 ports BRIDGE-MIB::dot1dStpTimeSinceTopologyChange.0 = Timeticks: (189959) 0:31:39.59 centi-seconds BRIDGE-MIB::dot1dStpTopChanges.0 = Counter32: 2 BRIDGE-MIB::dot1dStpDesignatedRoot.0 = Hex-STRING: 80 00 00 01 02 4B D4 50 ... BRIDGE-MIB::dot1dStpPortState.3 = INTEGER: forwarding(5) BRIDGE-MIB::dot1dStpPortEnable.3 = INTEGER: enabled(1) BRIDGE-MIB::dot1dStpPortPathCost.3 = INTEGER: 200000 BRIDGE-MIB::dot1dStpPortDesignatedRoot.3 = Hex-STRING: 80 00 00 01 02 4B D4 50 BRIDGE-MIB::dot1dStpPortDesignatedCost.3 = INTEGER: 0 BRIDGE-MIB::dot1dStpPortDesignatedBridge.3 = Hex-STRING: 80 00 00 01 02 4B D4 50 BRIDGE-MIB::dot1dStpPortDesignatedPort.3 = Hex-STRING: 03 80 BRIDGE-MIB::dot1dStpPortForwardTransitions.3 = Counter32: 1 RSTP-MIB::dot1dStpVersion.0 = INTEGER: rstp(2) A példában látszik, hogy a dot1dStpTopChanges.0 értéke kettõ, ami arra utal, hogy az STP híd topológiája kétszer változott. A topológia változása pedig azt jelenti, hogy a hálózaton belül egy vagy több link állapota megváltozott vagy egyszerûen meghibásodott és ezért egy új fát kellett számolni. A dot1dStpTimeSinceTopologyChange.0 érték adja meg, hogy ez pontosan mikor is történt. Több híd felületének felügyeletéhez a belsõ BEGEMOT-BRIDGE-MIB parancsot is használhatjuk: &prompt.user; snmpwalk -v 2c -c public bridge1.example.com enterprises.fokus.begemot.begemotBridge BEGEMOT-BRIDGE-MIB::begemotBridgeBaseName."bridge0" = STRING: bridge0 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseName."bridge2" = STRING: bridge2 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseAddress."bridge0" = STRING: e:ce:3b:5a:9e:13 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseAddress."bridge2" = STRING: 12:5e:4d:74:d:fc BEGEMOT-BRIDGE-MIB::begemotBridgeBaseNumPorts."bridge0" = INTEGER: 1 BEGEMOT-BRIDGE-MIB::begemotBridgeBaseNumPorts."bridge2" = INTEGER: 1 ... BEGEMOT-BRIDGE-MIB::begemotBridgeStpTimeSinceTopologyChange."bridge0" = Timeticks: (116927) 0:19:29.27 centi-seconds BEGEMOT-BRIDGE-MIB::begemotBridgeStpTimeSinceTopologyChange."bridge2" = Timeticks: (82773) 0:13:47.73 centi-seconds BEGEMOT-BRIDGE-MIB::begemotBridgeStpTopChanges."bridge0" = Counter32: 1 BEGEMOT-BRIDGE-MIB::begemotBridgeStpTopChanges."bridge2" = Counter32: 1 BEGEMOT-BRIDGE-MIB::begemotBridgeStpDesignatedRoot."bridge0" = Hex-STRING: 80 00 00 40 95 30 5E 31 BEGEMOT-BRIDGE-MIB::begemotBridgeStpDesignatedRoot."bridge2" = Hex-STRING: 80 00 00 50 8B B8 C6 A9 Így tudjuk megadni, hogy a hidat mib-2.dot1dBridge részfán keresztül akarjuk megfigyelni: &prompt.user; snmpset -v 2c -c private bridge1.example.com BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2 Andrew Thompson Írta: Linkek összefûzése és hibatûrése lagg failover fec lacp loadbalance roundrobin Bevezetés A &man.lagg.4; felület lehetõvé teszi, hogy több hálózati felületet egyetlen virtuális felületként fûzzünk össze, és ezzel egy hibatûrõ és nagysebességû összeköttetést alakítsunk ki. Mûködési módok failover Csak az elsõdlegesként kijelölt porton keresztül fogad és küld adatokat. Amikor ez az elsõdleges port elérhetetlenné válik, a következõ aktív portot fogja használni. Az elsõként felvett felület válik automatikusan az elsõdleges porttá, és az utána felvett összes többit pedig csak hiba esetén használjuk. &cisco; Fast ðerchannel; A &cisco; Fast ðerchannel; (FEC) technológia támogatása. Ez egy statikus beállítás, és nem egyezteti az összefûzést a többiekkel vagy a linkek felügyeletéhez nem vált kereteket. Ha a switch támogatja az LACP használatát, akkor inkább azt válasszuk. A FEC a kimenõ forgalmat a fejlécekben szereplõ protokollok alapján számolt hasítókóddal próbálja szétosztani az aktív portok között, és tetszõleges aktív porton fogad beérkezõ adatokat. Az említett hasítókódban egy Ethernetes forrás- és célcím szerepel, valamint ha elérhetõ, akkor egy VLAN címke, illetve az IPv4/IPv6 forrás- és célcím. LACP Az &ieee; 802.3ad Link Aggregation Control Protocol (LACP) és a Marker Protcol támogatása. Az LACP megpróbálja egyeztetni a többi géppel az összefûzhetõ linkeket egy vagy több csoportban (Link Aggregated Group, LAG). Mindegyik ilyen csoportban ugyanolyan sebességû portokat találunk, full-duplex mûködési módban. A forgalmat így a legnagyobb összsebességgel rendelkezõ csoportban megtalálható portok között osztja el, ami a legtöbb esetben az összes portot magában foglaló csoport. A fizikai konnektivitás megváltozása esetén a linkek összefûzõdése igen gyorsan alkalmazkodik az új konfigurációhoz. Az LACP a kimenõ forgalmat az aktív portok között osztja szét fejlécekben szereplõ protokollok alapján számolt hasítókóddal, és bármelyik aktív portról fogad bejövõ forgalmat. A hasítókódban megtalálható az Ethernetes forrás- és célcím, valamint ha elérhetõ, akkor a VLAN címke, illetve az IPv4/IPv6 forrás- és célcímek. Loadbalance Ez a FEC mód másik neve. Round-Robin A kimenõ forgalmat egy körkörös (Round-Robin) elvû ütemezõvel osztja szét az aktív portok között és tetszõleges aktív portról fogad bejövõ forgalmat. Ez a mûködési mód megsérti az Ethernet keretek rendezését és csak nagy körültekintés mellett alkalmazzuk. Példák LACP alapú összefûzés egy &cisco; switch-csel Ebben a példában egy &os;-s gép két felületét kapcsoljuk össze switch-csel egy egyszerû terhelés-kiegyenlítéssel és hibatûréssel beállított linken keresztül. Mivel az Ethernet keretek sorrendje döntõ fontosságú, ezért a két állomás között egyazon fizikai linken zajló forgalom maximális sebességét az adott felület kapacitása korlátozza. A küldési algoritmus a lehetõ legtöbb információ alapján próbálja egymástól megkülönböztetni a forgalmakat és elosztani ezeket a rendelkezésre álló felületek között. A &cisco; switch-en vegyünk fel a FastEthernet0/1 és FastEthernet0/2 interfészeket az 1 csoportba (channel group): interface FastEthernet0/1 channel-group 1 mode active channel-protocol lacp ! interface FastEthernet0/2 channel-group 1 mode active channel-protocol lacp A &os;-s gépen pedig a fxp0 és fxp1 használatával hozzunk létre a &man.lagg.4; interfészt: &prompt.root; ifconfig lagg0 create &prompt.root; ifconfig lagg0 up laggproto lacp laggport fxp0 laggport fxp1 Ellenõrizzük a felület állapotát: &prompt.root; ifconfig lagg0 A ACTIVE jelzésû, vagyis aktív állapotú portok az összefûzéshez kialakított csoport azon tagjai, amelyeknél felépült a kapcsolat a távoli switch felé és készen állnak a küldésre és fogadásra. Ha az &man.ifconfig.8; programtól részletesebb kimenetet kérünk, akkor láthatjuk a csoportok azonosítóit is: lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8<VLAN_MTU> ether 00:05:5d:71:8d:b8 media: Ethernet autoselect status: active laggproto lacp laggport: fxp1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> laggport: fxp0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> A show lacp neighbor paranccsal kérdezhetjük le a portok állapotát: switch# show lacp neighbor Flags: S - Device is requesting Slow LACPDUs F - Device is requesting Fast LACPDUs A - Device is in Active mode P - Device is in Passive mode Channel group 1 neighbors Partner's information: LACP port Oper Port Port Port Flags Priority Dev ID Age Key Number State Fa0/1 SA 32768 0005.5d71.8db8 29s 0x146 0x3 0x3D Fa0/2 SA 32768 0005.5d71.8db8 29s 0x146 0x4 0x3D Részletesebb kijelzést a show lacp neighbor detail paranccsal kaphatunk. A hibatûrés beállítása A hibatûrési mód arra alkalmas, hogy amikor az elsõdleges porton elvesztjük a kapcsolatot, helyette egy másodlagos interfész használatára tudunk áttérni. Hozzuk létre és állítsuk be a lagg0 interfészt, ahol az fxp0 legyen a fõinterfész, az fxp1 pedig a tartalék interfész: &prompt.root; ifconfig lagg0 create &prompt.root; ifconfig lagg0 up laggproto failover laggport fxp0 laggport fxp1 Az így létrejövõ interfész nagyjából az alábbi lesz, ahol eltérés a MAC-cím és az eszköz neve: &prompt.root; ifconfig lagg0 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8<VLAN_MTU> ether 00:05:5d:71:8d:b8 media: Ethernet autoselect status: active laggproto failover laggport: fxp1 flags=0<> laggport: fxp0 flags=5<MASTER,ACTIVE> A forgalom kezdetben az fxp0 felületen keresztül érkezik és távozik. Ha az fxp0 felületen valamiért megszakadna a kapcsolat, helyette az fxp1 lesz az aktív link. Ha késõbb helyreáll a kapcsolat az elsõdleges felületen, akkor újra az lesz aktív link. + + + Hibatûrés beállítása + vezetékes és vezeték nélküli + hálózatok között + + Hordozható számítógépek + használata esetén általában + érdemesebb a vezeték nélküli + kapcsolatot másodlagos interfészként + beállítani, így csak akkor + használja a rendszer, ha vezetékes + hálózat nem érhetõ el. A + &man.lagg.4; segítségével egyetlen + IP-címmel tudjuk használni mind a két + interfészt: a teljesítmény és + biztonságosság miatt elsõsorban a + vezetékes hálózatot használjuk, + miközben megmarad a lehetõség az adatok + továbbítására a vezeték + nélküli kapcsolaton keresztül is. + + A beállítás során a + vezeték nélküli interfész + MAC-címét úgy kell + módosítanunk, hogy megegyezzen a &man.lagg.4; + címével. A &man.lagg.4; interfész a + saját MAC-címét az + elsõdleges interfésztõl örökli, + amely jelen esetünkben a vezetékes + interfész lesz. + + A most következõ példában a + vezetékes hálózatunk lesz az + elsõdleges interfész + (bge0), míg a vezeték + nélküli (wlan0) a + másodlagos. A wlan0 + interfészt az iwn0 + interfészbõl hoztuk létre, és a + vezetékes kapcsolat + MAC-címét + állítjuk be neki. Elsõ + lépésként tehát le kell + kérdeznünk a vezetékes interfész + MAC-címét: + + &prompt.root; ifconfig bge0 +bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 + options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4> + ether 00:21:70:da:ae:37 + inet6 fe80::221:70ff:feda:ae37%bge0 prefixlen 64 scopeid 0x2 + nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> + media: Ethernet autoselect (1000baseT <full-duplex>) + status: active + + A bge0 helyett + természetesen a saját vezetékes + hálózati interfészünket kell + megadni, és az ether kezdetû + sorban is saját kártyánk + MAC-címe fog megjelenni. + Ezután már meg is tudjuk változtatni az + iwn0 címét: + + &prompt.root; ifconfig iwn0 ether 00:21:70:da:ae:37 + + Aktiváljuk a vezeték nélküli + interfészt, de ne állítsunk be neki + semmilyen IP-címet: + + &prompt.root; ifconfig create wlan0 wlandev iwn0 ssid wlan_hálózat up + + Hozzuk létre a &man.lagg.4; interfészt a + bge0 mint elsõdleges + interfész megadásával, valamint a + wlan0 legyen a szükség + esetén használható + tartalék: + + &prompt.root; ifconfig lagg0 create +&prompt.root; ifconfig lagg0 up laggproto failover laggport bge0 laggport wlan0 + + Az így létrehozott interfész + nagyjából így fog megjelenni, egyedüli + fontosabb eltérések a + MAC-címek és az + eszközök nevei: + + &prompt.root; ifconfig lagg0 +lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 + options=8<VLAN_MTU> + ether 00:21:70:da:ae:37 + media: Ethernet autoselect + status: active + laggproto failover + laggport: wlan0 flags=0<> + laggport: bge0 flags=5<MASTER,ACTIVE> + + Hogy ne kelljen a rendszer minden egyes + indítása után ezt a mûveletet + megismételni, vegyük fel a következõ + sorokat az /etc/rc.conf + állományba: + + ifconfig_bge0="up" +ifconfig_iwn0="ether 00:21:70:da:ae:37" +wlans_iwn0="wlan0" +ifconfig_wlan0="WPA" +cloned_interfaces="lagg0" +ifconfig_lagg0="laggproto failover laggport bge0 laggport wlan0 DHCP" + + Jean-François Dockès Frissítette: Alex Dupre Átdolgozta és javította: Lemez nélküli mûködés lemez nélküli munkaállomás lemez nélküli mûködés A &os; képes hálózaton keresztül elindulni és helyi lemez nélkül egy NFS szerver által megosztott állományrendszer csatlakoztatásával mûködni. Ehhez a szabványos konfigurációs állományok módosításán kívül semmi másra nincs szükségünk. Egy ilyen rendszert viszonylag könnyû beállítani, mivel az összes hozzávaló szinte készen elérhetõ: Rögtön adott legalább két módszer, ha a rendszermagot hálózaton keresztül akarjuk betölteni: PXE: az &intel; által fejlesztett Preboot eXecution Environment (indítás elõtti végrehajtási környezet) nevû rendszer a hálózati kártyákba vagy alaplapokba épített ROM segítségével teszi lehetõvé az intelligens rendszerindítást. A &man.pxeboot.8; man oldalán olvashatunk errõl részletesebben. Az Etherboot port (net/etherboot) olyan ROM-ba programozható kódot készít, amellyel rendszermagokat tudunk hálózaton keresztül betölteni. Ez a kód egyaránt felhasználható egy hálózati rendszerindító PROM beégetéséhez, vagy betölthetõ a helyi floppy (esetleg merev)lemezrõl, illetve &ms-dos; rendszer alól. Elég sok hálózati kártya támogatja ezt a módot. Egy mintaszkript (/usr/share/examples/diskless/clone_root) is próbálja megkönnyíteni a szerveren a munkaállomás rendszerindító állományrendszerének létrehozását és karbantartását. Ezt a szkriptet valószínûleg némileg módosítani kell, de így is sokat segít az elindulásban. Az /etc könyvtárban található szabványos rendszerindításhoz használt állományok, amelyekkel a lemez nélküli indulást lehet detektálni és segíteni. A lapozás, amennyiben szükséges, NFS vagy helyi lemez segítségével oldható meg. Számos módon állíthatunk be egy lemez nélküli munkaállomást. Rengeteg részbõl tevõdik össze, és ezek legtöbbje remekül testreszabható az igényeinknek. A továbbiakban egy teljes rendszer összeállításának lehetséges variációit ismertetjük, különös hangsúlyt fektetünk arra, hogy egyszerûek és a hagyományos &os; indítószkriptekkel kompatibilisek maradjanak. A bemutatandó rendszer a következõ jellemzõkkel bír: A lemez nélküli munkaállomások megosztott / és /usr állományrendszereket használnak. A rendszer indításához használt gyökér állományrendszer a szabvány &os;-s gyökér (ez általában a szerveré), ahol néhány állományt felülírtunk a lemez nélküli mûködéshez vagy azért, mert egyszerûen az adott munkaállomáshoz tartozik. A gyökér azon részeit, amelyeket írhatóvá kívánunk tenni, &man.md.4; alapú állományrendszerekkel lapoljuk felül. Ilyenkor azonban bármilyen rajtuk ejtett változtatás a rendszer újraindításával elveszik. A rendszermagot vagy az Etherboot vagy a PXE használatával küldessük át és töltsük be, mivel egyes helyzetekben ezekre szükség lesz. A bemutatott rendszer nem biztonságos. Helyezzük a hálózatunk egy jól védett részére, és a többi gép ne tekintse megbízhatónak. A szakaszban szereplõ összes információt a &os; 5.2.1-RELEASE változatával teszteltük. Háttérinformációk A lemez nélküli munkaállomások beállítása egyszerre adja magát és könnyen is elvéthetõ. Az elkövetett hibákat olykor számos okból kifolyólag nehéz felismerni. Például: A fordítási idõben megadott beállítások mást eredményeznek futási idõben. A hibaüzenetek gyakran titokzatosak vagy esetleg teljesen el is maradnak. Ezért ha valamennyire tisztában vagyunk a háttérben zajló folyamatokkal, akkor sokkal több eséllyel leszünk képesek megoldani a menet közben felmerülõ problémákat. A rendszernek a sikeres felkapaszkodáshoz több mûveletet is végre kell hajtania: A gépnek szüksége van olyan induló paraméterekhez, mint például az IP-cím, a végrehajtható állomány neve, a szerver neve, a gyökér elérési útja. Ezeket a DHCP vagy a BOOTP protokollok használatával adhatjuk meg. A DHCP a BOOTP kompatibilis kiterjesztése, ezért ugyanazokat a portokat és alapvetõ csomagformátumot alkalmazza. A rendszerüket kizárólag BOOTP használatával is beállíthatjuk. A &man.bootpd.8; szerver az alap &os; rendszer része. A DHCP azonban rengeteg elõnnyel rendelkezik a BOOTP protokollal szemben (áttekinthetõbb konfigurációs állományok, a PXE használatának lehetõsége, illetve sok minden más, ami nem csak a lemez nélküli mûködéshez kellhet), ezért itt alapvetõen egy DHCP alapú konfigurációt mutatunk be, de ahol megoldható, megemlítjük a &man.bootpd.8; esetén alkalmas példákat is. A mintaként szolgáló konfiguráció az ISC DHCP szoftvercsomagot használja (a tesztszerverre ennek a 3.0.1.r12 verzióját telepítetük fel). A gépnek egy vagy több programot kell a saját memóriájába áttöltenie. Erre vagy a TFTP vagy pedig az NFS alkalmas. A TFTP és az NFS között sok helyen fordítási idõben tudunk választani. Gyakori hibaforrás a protokollhoz rosszul megadott állománynevek használata: a TFTP általában az összes állományt a szerverrõl egyetlen könyvtárból tölti át, ezért arra számít, hogy a neveiket ehhez viszonyítva adjuk meg. Az NFS használata során azonban abszolút elérési utakat kell megadnunk. A rendszer indítását lehetõvé tevõ közbensõ programokat és a rendszermagot valahogy inicializálni kell és elindítani. Ezen a területen több fontos változat kapott helyet: A PXE a &man.pxeboot.8; kódját fogja betölteni, ez lényegében a &os; betöltõ harmadik fokozatának egy módosított változata. A &man.loader.8; a mûködéséhez szükséges paramétereket a rendszer indításakor kapja meg, majd a vezérlés átadása elõtt ezeket a rendszermag környezetében hagyja. Ebben az esetben akár a GENERIC rendszermag is használható. Az Etherboot kevesebb elõkészítéssel közvetlenül magát a rendszermagot tölti be. Ehhez azonban egy saját rendszermagot kell építeni, külön beállításokkal. A PXE és az Etherboot egyaránt jól használható. Mivel azonban a rendszermagok általában a &man.loader.8; kódjára hagyják a munka legnagyobb részét, ezért ahol lehetséges, a PXE megoldását érdemes alkalmazni. Tehát ha az alaplapi BIOS és a hálózati kártya is támogatja a PXE használatát, akkor válasszunk inkább azt. Végezetül a gépnek valamilyen módon hozzá kell tudnia férnie az állományrendszerekhez. Erre többnyire az NFS jöhet szóba. A további részleket lásd a &man.diskless.8; man oldalon. Beállítási útmutató Beállítás a <application>ISC DHCP</application> használatával DHCP lemez nélküli mûködés Az ISC DHCP szervere képes a BOOTP és DHCP kéréseket is megválaszolni. Az ISC DHCP 3.0 nem az alaprendszer része, ezért a használatához elõször telepítenünk kell a net/isc-dhcp30-server portot vagy a neki megfelelõ csomagot. Ahogy feltelepítettük, le kell futtatnunk az ISC DHCP konfigurációs állományát (ezt általában /usr/local/etc/dhcpd.conf néven találjuk meg). A most következõ, megjegyzésekkel kiegészített példában egy margaux nevû gép az Etherboot, valamint egy corbieres nevû gép PXE használatával akar kapcsolódni: default-lease-time 600; max-lease-time 7200; authoritative; option domain-name "minta.com"; option domain-name-servers 192.168.4.1; option routers 192.168.4.1; subnet 192.168.4.0 netmask 255.255.255.0 { use-host-decl-names on; option subnet-mask 255.255.255.0; option broadcast-address 192.168.4.255; host margaux { hardware ethernet 01:23:45:67:89:ab; fixed-address margaux.minta.com; next-server 192.168.4.4; filename "/data/misc/kernel.diskless"; option root-path "192.168.4.4:/data/misc/diskless"; } host corbieres { hardware ethernet 00:02:b3:27:62:df; fixed-address corbieres.minta.com; next-server 192.168.4.4; filename "pxeboot"; option root-path "192.168.4.4:/data/misc/diskless"; } } Ez a beállítás arra utasítja a dhcpd démont, hogy a lemez nélküli gép hálózati neveként a host deklarációban megadott értéket küldje el. Ezt úgyis meg lehet csinálni, hogy felvesszünk egy option host-name margaux részt a host deklarációk közé. A next-server direktíva a betöltõ vagy a rendszermag betöltéséért felelõs TFTP vagy NFS szervert jelöli ki (alapértelmezés szerint ez megegyezik a DHCP szerverrel). A filename direktíva azt az állományt adja meg, amelyet az Etherboot vagy a PXE a következõ végrehajtási lépésben betölt. Ezt a kiválasztott átviteli módnak megfelelõen kell megadni. Az Etherboot lefordítható az NFS vagy a TFTP használatával is. A &os; port alapból az NFS támogatását tartalmazza. A PXE a TFTP protokollt használja, ezért itt relatív állományneveket adunk meg (ez persze a TFTP szerver beállításaitól függ, de általában ez a jellemzõ). Sõt, a PXE a pxeboot állományt tölti be, nem is a rendszermagot. Léteznek további érdekes lehetõségek is, mint például a pxeboot állomány betöltése a &os; CD-jén található /boot könyvtárból (mivel a &man.pxeboot.8; a GENERIC rendszermagot képes betölteni, ezért a PXE használatával akár egy távoli CD-meghajtóról is indíthatjuk a rendszert). A root-path opció a rendszer indításához használt gyökér állományrendszert nevezi meg, amelyet többnyire az NFS jelölési módszere szerint kell megadni. A PXE használata során el lehet hagyni a gép IP-címét egészen addig, amíg nem engedélyezzük a rendszermagban a BOOTP beállítást. Az NFS szerver ekkor megegyzik a TFTP szerverrel. Beállítás a BOOTP használatával BOOTP lemez nélküli mûködés Itt a bootpd (egyetlen kliensre korlátozott) beállítását láthatjuk. Ezt az /etc/bootptab állományba tegyük. Ne feledjük, hogy a BOOTP használatához az Etherboot portot a NO_DHCP_SUPPORT beállítással kell fordítanunk, miközben a PXE esetében kell a DHCP. Egyébként a bootpd egyedüli nyilvánvaló elõnye csupán annyi, hogy az alaprendszer része. .def100:\ :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ :sm=255.255.255.0:\ :ds=192.168.4.1:\ :gw=192.168.4.1:\ :hd="/tftpboot":\ :bf="/kernel.diskless":\ :rp="192.168.4.4:/data/misc/diskless": margaux:ha=0123456789ab:tc=.def100 A rendszer elõkészítése az <application>Etherboot</application> számára Etherboot Az Etherboot honlapján találhatunk egy minden részletre kiterjedõ dokumentációt (angolul), amely elsõsorban ugyan a Linux típusú rendszerek számára íródott, de ettõl függetlenül még hasznos információkat tartalmaz. A továbbiakban csak annyit szeretnénk körvonalazni, hogy az Etherboot miként bírható mûködésre &os; rendszerekkel. Elõször telepítenünk kell a net/etherboot csomagot vagy portot. Az Etherboot beállítását (vagyis a TFTP használatának megadását az NFS helyett) az Etherboot forrását tartalmazó könyvtárban található Config állomány megfelelõ átírásával tudjuk megtenni. Itt most floppyról fogjuk indítani a rendszert. A többi módszerrel (PROM vagy &ms-dos; program) kapcsolatban olvassuk el az Etherboot dokumentációját. A rendszerindító lemez elkészítéséhez tegyünk egy lemezt annak a gépnek a meghajtójába, ahová az Etherboot felkerült. Váltsunk az Etherboot könyvtárán belül az src alkönyvtárba és gépeljük be: &prompt.root; gmake bin32/eszköztípus.fd0 Az eszköztípus a lemez nélküli munkaállomás Ethernet kártyájától függ. Az ugyanebben a könyvtárban található NIC állományból tudjuk kiolvasni, hogy az adott kártyához melyik eszköztípus tartozik. A rendszer indítása <acronym>PXE</acronym> használatával Alapértelmezés szerint a &man.pxeboot.8; betöltõ a rendszermagot NFS-en keresztül tölti be. Ha az /etc/make.conf állományban a LOADER_TFTP_SUPPORT beállítást adjuk meg, akkor TFTP támogatással is lefordítható. Ezzel kapcsolatban a /usr/share/examples/etc/make.conf állományban található megjegyzéseket érdemes elolvasnunk. A make.conf állományban még további két másik hasznos opciót is találhatunk a soros vonali konzollal üzemelõ lemez nélküli gépek számára: az egyik a BOOT_PXELDR_PROBE_KEYBOARD, a másik pedig a BOOT_PXELDR_ALWAYS_SERIAL. A gép indításakor úgy tudjuk beüzemelni a PXE használatát, ha a BIOS beállításai között a Boot from network opciót választjuk ki, vagy a gép bekapcsolása után lenyomjuk hozzá a megfelelõ funkcióbillentyût. A <acronym>TFTP</acronym> és <acronym>NFS</acronym> szerverek beállítása TFTP lemez nélküli mûködés NFS lemez nélküli mûködés Ha a PXE vagy az Etherboot a TFTP protokollt használja, akkor az állományszerveren a tftpd démont kell elindítani: Készítsünk egy könyvtárat, ahonnan majd a tftpd küldi az állományokat, például legyen ez a /tftpboot. Vegyük fel a következõ sort az /etc/inetd.conf állományunkba: tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot A tapasztalat szerint egyes PXE verziók a TFTP TCP alapú változatát használják. Ebben az esetben vegyünk fel még egy második sort is, ahol a dgram udp részt stream tcp-re cseréljük. Mondjuk meg az inetd démonnak, hogy olvassa újra a konfigurációs állományát. Az alábbi parancs megfelelõ mûködéséhez Az sornak szerepelnie kell az /etc/rc.conf állományban: &prompt.root; /etc/rc.d/inetd restart A tftpboot könyvtárat bárhova rakhatjuk a szerveren. Viszont az inetd.conf és dhcpd.conf állományokban ezt ne felejtsük fel megadni. Minden esetben engedélyeznünk kell az NFS használatát és vele együtt exportálni az NFS szerverrõl elérni kívánt állományrendszereket. Az /etc/rc.conf állományba tegyük bele a következõt: nfs_server_enable="YES" Az /etc/exports állományban a lemez nélküli rendszereknek szánt gyökérkönyvtárat tegyük elérhetõvé (a példában írjuk át a kötet csatlakozási pontját és a margaux corbieres helyére állítsuk be a saját lemez nélküli munkaállomásaink neveit: /data/misc -alldirs -ro margaux corbieres Kérjük meg a mountd démont, hogy olvassa újra a konfigurációs állományát. Elõfordulhat azonban, hogy ehhez elõször az NFS szolgáltatást kell engedélyezni az /etc/rc.conf állományból és újraindítani a gépet. &prompt.root; /etc/rc.d/mountd restart Lemez nélküli rendszermag fordítása lemez nélküli mûködés a rendszermag beállításai Ha az Etherboot használata mellett döntünk, akkor a lemez nélküli kliensek számára a rendszermagot a következõ beállítások használatával kell újrafordítani (a megszokottak mellett): options BOOTP # BOOTP-n keresztül kérünk IP-címet és hálózati nevet options BOOTP_NFSROOT # a BOOTP-tõl kapott információk alapján csatoljuk a gyökeret NFS-en keresztül Ezek mellett valószínûleg szükségünk lesz a BOOTP_NFSV3, BOOT_COMPAT és BOOTP_WIRED_TO beállítások megadására is (lásd a NOTES állományt). A beállítások nevei régrõl származnak és némileg félrevezetõek lehetnek, mivel valójában semmit sem változtatnak a rendszermagban levõ DHCP vagy a BOOTP rutinok használatában (egyébként meg lehet adni vagy az egyik vagy a másik protokoll kizárólágos használatát is). Fordítsuk le a rendszermagot (lásd ), és másoljuk a dhcpd.conf állományban megadott helyre. Amikor a PXE protokollt használjuk, a rendszermagot nem fontos az imént felsorolt paraméterekkel fordítanunk (habár ajánlatos). Az engedélyezésükkel több DHCP kérés keletkezik a rendszermag elindulása közben, ezért kisebb a kockázata annak, hogy a &man.pxeboot.8; által bizonyos esetekben megszerzett és az új értékek között valamilyen ellentmondás jön létre. A használatuk egyik elõnye, hogy így mellékhatásként a hálózati nevünket is megkapjuk. Ellenkezõ esetben erre is találnunk kellene valamilyen módot, például fenntartani egy-egy rc.conf állományt minden kliensen. Az Etherboot csak akkor lesz képes betölteni a rendszermagot, ha device hinteket is beépítünk. Ezt a következõ beállítással tudjuk megoldani (errõl bõvebben lásd a NOTES állomány megjegyzéseit): hints "GENERIC.hints" A rendszerindító állományrendszer elõkészítése rendszerindító állományrendszer lemez nélküli mûködés A dhcpd.conf állomány root-path beállításának megfelelõen hozzunk létre a rendszer indítására alkalmas gyökér állományrendszert. Az állományrendszer feltöltése a <command>make world</command> paranccsal Ezzel a módszerrel a DESTDIR könyvtárba pillanatok alatt telepíteni tudunk egy teljes szûz rendszert (és nem csak a rendszerindító állományrendszert). Ehhez mindössze csak annyit kell tenni, hogy lefuttatjuk a következõ szkriptet: #!/bin/sh export DESTDIR=/data/misc/diskless mkdir -p ${DESTDIR} cd /usr/src; make buildworld && make buildkernel cd /usr/src/etc; make distribution Miután végzett, már csak a DESTDIR könyvtárban található /etc/rc.conf és /etc/fstab állományokat kell az igényeinkhez igazítani. A lapozóterület beállítása Amennyiben szükséges, a szerveren található lapozóállományt NFS-en keresztül el tudjuk érni. Lapozás <acronym>NFS</acronym>-sel A rendszermag maga nem támogatja az NFS alapú lapozás engedélyezését a rendszer indításakor. A lapozóállományt ezért a rendszerindító szkripteken keresztül aktiváljuk, amelyekben csatlakoztatunk egy írható állományrendszert, ahol létrehozzuk és engedélyezzük a lapozóállományt. Tetszõleges méretû lapozóállományt például így tudunk készíteni: &prompt.root; dd if=/dev/zero of=/a/lapozóállomány/helye bs=1k count=1 oseek=100000 Az engedélyezéséhez pedig a következõ sort kell felvenni az rc.conf állományba: swapfile=/a/lapozóállomány/helye Egyéb problémák Írásvédett <filename>/usr</filename> használata lemez nélküli mûködés írásvédett /usr Ha a lemez nélküli munkaállomáson X szervert akarunk futtatni, akkor az XDM konfigurációs állományait kicsit módosítanunk kell, mert alapértelmezés szerint a /usr könyvtárban hozza létre a naplókat. Nem &os;-s szerver használata Amikor a rendszer indításához használt állományrendszert nem egy &os; alapú számítógépen tároljuk, akkor elõször ezt egy &os;-s gépen kell elkészíteni, majd a tar vagy cpio segítségével átmásolni a megfelelõ helyre. Ilyen helyzetekben gyakran gondok adódhatnak olyan speciális állományokkal, mint például amelyek a /dev könyvtárban találhatóak, mivel a fõ- és aleszközazonosítók tárolására szánt méret különbözhet. Ezt úgy oldhatjuk meg, ha exportálunk egy könyvtárat a nem &os; alapú szerveren, ezt csatlakoztatjuk a &os;-s gépen, majd a &man.devfs.5; segítségével a eszközleírókat a felhasználó számára észrevétlen módon foglaljuk le. ISDN ISDN Az ISDN technológiai és hardveres hátterérõl sokat megtudhatunk Dan Kegel ISDN-rõl szóló oldalán (angolul). Az ISDN használatát röviden így foglalhatnánk össze: Ha Európában élünk, akkor minden bizonnyal az ISDN kártyákkal foglalkozó szakaszt érdemes elolvasnunk. Ha elsõsorban betárcsázós ISDN-nel szeretnénk csatlakozni az internetre egy internet-szolgáltatón keresztül, akkor a terminál adaptereket tárgyaló szakaszt nézzük meg. A szolgáltatók váltásakor ezzel jár a legtöbb rugalmasság és a legkevesebb probléma. Ha két helyi hálózat összekötésére használjuk, vagy az internethez egy bérelt ISDN vonalon keresztül kapcsolódunk, akkor egy önálló útválasztó vagy hálózati híd beállításában érdemes gondolkodnunk. A költség fontos szerepet játszik az elfogadható megoldás kiválasztásában. A most következõ lehetõségeket a legolcsóbbtól indulva kezdjük el felsorolni egészen a legdrágábbig. Hellmuth Michaelis Készítette: ISDN kártyák ISDN kártyák A &os;-ben megtalálható ISDN implementáció csak a DSS1/Q.931 (más néven Euro-ISDN) szabvány szerint gyártott passzív kártyákat támogatja. Ismer azonban egyes olyan aktív kártyákat is, amelyeknél a firmware további más jelkezelési protokollokat is támogat. Ilyen többek közt az elsõként támogatott Primary Rate (PRI) ISDN kártya. Az isdn4bsd szoftver segítségével kapcsolódni tudunk más ISDN útválasztókhoz IP-n keresztül a nyers HDLC felett, vagy szinkron PPP használatával. Mindezeket a rendszermagban található PPP-re vagy az isppp-re építkezik. &os; alatt egyre több PC-s ISDN kártyához készül el a támogatás, és a visszajelzések azt mutatják, hogy Európában és a világ minden részén sikerrel használják ezeket. A passzív ISDN kártyák közül is leginkább az Infineon (korábban Siemens) gyártmányú ISAC/HSCX/IPAC ISDN chipkészletek támogatottak, de a Cologne chippel rendelkezõ (de csak ISA buszos) ISDN kártyák, a Winbond W6692 chipes PCI buszos kártyák, és a Tiger300/320/ISAC chipkészletek egyes változatai, valamint néhány gyártófüggõ chipkészlettel rendelkezõ kártya, mint például az AVM Fritz!Card PCI V.1.0 és az AVM Fritz!Card PnP is remekül mûködik. Jelenleg a következõ aktív ISDN kártyákat támogatja a rendszer: AVM B1 (ISA és PCI) BRI kártyák és az AVM T1 PCI PRI kártyák. Az isdn4bsd dokumentációját a rendszerünkön belül a /usr/share/examples/isdn/ könyvtárban találhatjuk meg, vagy közvetlenül az isdn4bsd honlapján, ahol több hivatkozást is találunk tippekre, hibajegyzékekre és bõségesebb dokumentációra, például az isdn4bsd saját kézikönyvére. Ha szeretnénk egy másik ISDN protokoll támogatásának kifejlesztésében résztvenni, vagy egy jelenleg még nem támogatott ISDN kártyát használhatóvá tenni, esetleg valamilyen más módon segíteni az isdn4bsd ügyét, vegyük fel a kapcsolatot &a.hm; fejlesztõvel. Az isdn4bsd telepítésével, beállításával és hibaelhárításával kapcsolatos kérdéseinket a &a.isdn.name; levelezési listán tehetjük fel. ISDN terminál adapterek Az ISDN számára olyanok a terminál adapterek, mint a hagyományos telefonvonalak számára a modemek. modem A legtöbb terminál adapter a Hayes-modemek szabványos AT parancskészletét használja, és könnyen be lehet iktatni egy modem helyett. A terminál adapterek alapvetõen ugyanúgy mûködnek, mint a modemek, kivéve, hogy egy átlagos modemnél jóval nagyobb adatátviteli sebességre képesek. Ezért a PPP kapcsolatunkat pontosan ugyanúgy kell beállítani, mint a modemek esetében. Ne felejtsük a soros pont sebességét a maximális értékre állítani. PPP A terminál adapterek használatának egyik legnagyobb elõnye, hogy segítségükkel dinamikus PPP-n keresztül tudunk az internet-szolgáltatónkhoz kapcsolódni. Mivel az IP-címtartomány egyre inkább szûkösebb, a legtöbb szolgáltató nem szívesen oszt ki bárkinek is statikus IP-címet. A legtöbb önálló útválasztó azonban nem képes alkalmazkodni az IP-címek dinamikus kiosztásához. A terminál adapter az elérhetõ lehetõségeket és a kapcsolat stabilitását tekintve teljesen a PPP démontól függ. Emiatt egy &os;-s gépet könnyû modemrõl átállítani az ISDN használatára, ha már egyszer beállítottuk a PPP démont. Ezzel együtt azonban a PPP használata során tapasztalt problémák ugyanúgy ismét felmerülnek. Ha a maximális stabilitásra van szükségünk, akkor a rendszermag PPP beállítását használjuk, és ne a felhasználói PPP megoldást. A &os; hivatalosan az alábbi terminál adaptereket ismeri: Motorola BitSurfer és Bitsurfer Pro Adtran Valószínûleg a többi terminál adapterrel is képes együttmûködni, mivel a terminál adapterek gyártói általában igyekeznek a termékeiket a szabványos modemes AT parancskészletével kompatibilissá tenni. Az igazi probléma a külsõ terminál adapterekkel adódik, mivel, akárcsak a modemek esetében, egy nagyon jó soros kártyát igényelnek. A soros eszközök mûködésének részleteit valamint az aszinkron és szinkron soros portok közti különbségeket a &os; soros hardverekrõl szóló cikkében olvashatjuk. A terminál adaptereken keresztül elérhetõ sebességet a PC-kben található szabványos (aszinkron) soros port 115,2 Kb/mp-re korlátozza, még 128 Kb/mp-es adatátvitelû kapcsolatok esetében is. Az ISDN által nyújtott 128 Kb/mp kihasználásához a terminál adaptert egy szinkron soros kártyával kell összekötnünk. Ne higyjük, hogy egy belsõ terminál adapter megvásárlásával megmenekülünk ettõl a gondtól. A belsõ terminál adapterekbe egyszerûen csak egy sima szabványos PC-s soros portot építettek bele. Mindössze egy soros kábelt és egy konnektort takarítunk meg velük. A terminál adapterhez csatlakozó szinkron kártyák legalább olyan gyorsak, mint egy önálló útválasztó, és egy egyszerû 386-osra épülõ &os; rendszerrel talán még rugalmasabban is kezelhetõek. A terminál adapter plusz szinkron kártya kontra önálló útválasztó kérdése már hitkérdéssé fajult, amirõl igen sokat vitatkoztak szerte a levelezési listákon. A teljes okfejtés elolvasásához az archívum böngészését javasoljuk. Önálló ISDN hálózati hidak és útválasztók ISDN önálló hálózati hidak és útválasztók Az ISDN hidak vagy útválasztók nem egészen a &os; vagy operációs rendszerek területéhez tartoznak. Az útválasztás és a hálózatok hidak alapjainak a számítógépes hálózatokról szóló szakirodalomban járhatunk utána. Ebben a szakaszban a hálózati híd és az útválasztó kifejezéseket egymás szinonímájaként fogjuk használni. Ahogy az olcsóbb ISDN útválasztók és hidak árai egyre jobban csökkennek, ezért egyre inkább népszerûbbé válnak. Az ISDN útválasztó egy apró doboz, amelyet közvetlenül a helyi Ethernet hálózatunkra tudunk csatlakoztatni, és a többi útválasztóhoz vagy hídhoz kapcsolódik. A benne található szoftverrel képes kommunikálni a PPP vagy más egyéb népszerû protokollokon keresztül. Az útválasztó egy szabványos terminál adapternél sokkal nagyobb adatátvitelt tesz lehetõvé, mivel a teljes szinkron ISDN kapcsolatot képes kihasználni. Az ISDN útválasztókkal és hidakkal kapcsolatban az egyik legnagyobb problémát a különbözõ gyártók közti eltérések jelenthetik. Ha egy szolgáltatóhoz akarunk ezen a módon csatlakozni, akkor érdemes elõzetesen egyeztetni az igényeinket velük. Ha két helyi hálózati szegmenst akarunk összekapcsolni, mint például az otthoni és az irodai hálózatot, akkor ez a megoldás jár a legkevesebb karbantartási költséggel. Mivel ekkor mi magunk vásároljuk a kapcsolat mind a két oldalára a felszerelést, biztosak lehetünk benne, hogy az így létrehozott összekötettés mûködni fog. Például, ha egy otthon vagy a vállalat egy fiókjánál levõ gépet akarjuk összekötni az igazgatóság hálózatával, akkor a következõ felállást érdemes követnünk: Egy otthoni vagy egy fiókbeli hálózat 10 Base 2 A hálózat busz topológiájú és 10 Base 2 Ethernetet használ (thinnet). Ha szükséges, akkor az útválasztót egy AUI/10BT adó-vevõvel csatlakoztassuk a hálózati kábelre. ---Sun munkaállomás | ---&os; | ---Windows 95 | az önálló útválasztó | ISDN BRI vonal 10 Base 2 Ethernet Ha az otthoni vagy fiókbeli számítógép az egyedüli, akkor egy keresztkötésû sodrott érpár kábellel akár közvetlenül is csatlakozhatunk az útválasztóhoz. Az igazgatósági iroda vagy egy másik helyi hálózat 10 Base T A hálózat csillag topológiájú, és 10 Base T Ethernet kábelezésû (sodrott érpár). -------Novell szerver | H | | ---Sun | | | U ---&os; | | | ---Windows 95 | B | |___---az önálló útválasztó | ISDN BRI vonal Az ISDN hálózat felépítése A legtöbb útválasztó/híd elõnye, hogy egyszerre 2 egymástól független PPP kapcsolatot tudunk felépíteni velük 2 egymástól független géppel. Ezt a legtöbb terminál adapter nem támogatja, kivéve azok a (általában drága) típusok, amelyek két soros porttal rendelkeznek. Ezt ne tévesszük össze a csatornák nyalábolásával, az MPP-vel és a többivel. Ez nagyon hasznos lehet például olyan esetekben, amikor van egy dedikált ISDN kapcsolatunk az irodában, amelyet ugyan szeretnénk megcsapolni, de nem szeretnénk a másik ISDN vonalat is elrabolni. Az irodában levõ A útválasztó képes a dedikált B csatornájú kapcsolaton (64 Kb/mp) keresztül elérni az internetet, miközben a másik B csatornát ettõl független adatkapcsolatra használja. A második B csatorna így használható betárcsázásra, kitárcsázásra vagy a másik B csatornával együtt dinamikus nyalábolásra (MPP stb.) a nagyobb sávszélesség elérése érdekében. IPX/SPX Az Ethernetes híd nem IP alapú forgalmat is képes továbbítani, ezért rajta keresztül akár IPX vagy SPX és más egyéb protokollokat is használni tudunk. Chern Lee Írta: Hálózati címfordítás Áttekintés natd A &os; hálózati címfordításért felelõs démonprogramja, a &man.natd.8; (Network Address Translation daemon), a beérkezõ nyers IP csomagokat dolgozza fel, és a helyi gépek forráscímét kicserélve visszailleszti ezeket a csomagokat a kimenõ folyamba. A &man.natd.8; mindezt úgy teszi a forrás IP-címekkel és portokkal, hogy amikor az adat visszaérkezik, akkor képes lesz megmondani a csomag eredeti küldõjét és visszaküldeni neki a választ. internet-kapcsolat megosztása NAT A hálózati címfordítást általában az internet-kapcsolatok megosztásánál alkalmazzuk. A hálózat felépítése Az IPv4 világában egyre jobban fogyó IP-címek és az egyre növekvõ számú, nagysebességre vágyó, például kábeles vagy DSL-es fogyasztók miatt az igény is egyre nagyobb az internet-kapcsolatok megosztására. Ha több számítógéppel szeretnénk egyetlen kapcsolaton és egy IP-címen keresztül kapcsolódni az internetre, akkor ehhez a &man.natd.8; tökéletes választás. Az esetek többségében a felhasználók egy kábeles vagy DSL vonalra csatlakoznak, melyhez egyetlen IP-cím tartozik, és ezen a gépen keresztül szeretnék elérni az internetet a helyi hálózaton levõ többi géprõl. Ezt úgy tudjuk elérni, ha az internethez kapcsolódó &os;-s gépet átjárónak állítjuk be. Ebben az átjáróban legalább két hálózati felületnek kell léteznie — az egyikkel az internetes útválasztóhoz, a másikkal pedig a helyi hálózathoz kapcsolódik. A belsõ hálózaton levõ gépek egy hub vagy egy switch segítségével csatlakoznak egymáshoz. Több módon is el tudjuk érni a belsõ hálózatról az internetet egy &os;-s átjárón keresztül. Ebben a példában most csak olyan átjárókkal foglalkozunk, amelyekben legalább két hálózati kártya található. _______ __________ ________ | | | | | | | Hub |-----| B kliens |-----| Útvál. |----- Internet |_______| |__________| |________| | ____|_____ | | | A kliens | |__________| A hálózat felosztása Egy ehhez hasonló beállítás igen gyakori a megosztott internet-kapcsolatok esetében. A helyi hálózat egyik gépe csatlakozik az internetre. A többi gép ezen az átjárón keresztül éri el az internetet. rendszerbetöltõ beállítása A rendszerbetöltõ beállítása A &man.natd.8; mûködéséhez szükséges címfordítási támogatást a GENERIC típusú rendszermagok nem tartalmazzák, viszont a /boot/loader.conf megfelelõ paraméterezésével a rendszer betöltése közben ezt hozzá tudjuk adni: ipfw_load="YES" ipdivert_load="YES" Valamint a net.inet.ip.fw.default_to_accept változót állítsuk az 1 értékre. net.inet.ip.fw.default_to_accept="1" Ez utóbbi beállítást leginkább a tûzfal és a címfordítást végzõ átjáró próbálgatásakor érdemes alkalmazni. Ilyenkor ugyanis az &man.ipfw.8; alapértelmezett módon az allow ip from any to any (minden forgalom engedélyezett) szabályt követi, és nem pedig a kevésbé barátságos deny ip from any to any (minden forgalom tiltott) szabályt. A rendszer újraindításakor így valamivel nehezebb lesz kizárnunk magunkat a szabályok megadása során. rendszermag beállítása A rendszermag beállítása Amikor viszont nincs lehetõségünk modulok használatára, vagy szeretnénk minden igényelt funkciót beépíteni a rendszermagba, akkor a rendszermag beállításait tartalmazó állományban a következõket kell megadnunk: options IPFIREWALL options IPDIVERT A fentiek mellett még ezeket a lehetõségeket tudjuk választani: options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE A rendszerindítás beállítása A tûzfal és a hálózati címfordítás beindításához a következõknek kell az /etc/rc.conf állományban lennie: gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="fxp0" natd_flags="" A gépet átjárónak állítja be. Hatása megegyezik a sysctl net.inet.ip.forwarding=1 parancs kiadásával. A rendszer indításakor engedélyezi az /etc/rc.firewall állományban szereplõ tûzfalszabályok használatát. Egy olyan elõre definiált tûzfalat ad meg, amely alapból mindent beenged. Az /etc/rc.firewall állományban találhatjuk a többi típust. Megadja, hogy melyik felületen továbbítsunk csomagokat az internet felé (ez a felület csatlakozik az internetre). Itt szerepel minden további paraméter, amelyet még az indításkor át kell adnunk a &man.natd.8; démonnak. Amikor megadjuk ezeket a beállításokat az /etc/rc.conf állományban, pontosan ugyanaz történik, mintha a natd -interface fxp0 parancsot adtunk volna ki a rendszer indításakor. Ez tehát manuálisan is elindítható. Ha túlságosan sok paramétert akarunk egyszerre beállítani &man.natd.8; használatához, akkor akár egy külön konfigurációs állományt is megadhatunk. Ebben az esetben a konfigurációs állományt a következõ módon kell megjelölni az /etc/rc.conf állományban: natd_flags="-f /etc/natd.conf" Ekkor a /etc/natd.conf állomány fogja tartalmazni a beállításokat, soronként egyet. Például a következõ szakaszban ez lesz a tartalma: redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 A konfigurációs állományról és az opció használatával kapcsolatban olvassuk el a &man.natd.8; man oldalát. A helyi hálózaton mindegyik gépnek az RFC 1918 által megadott privát IP-címterekbõl származó címet kell használnia, és az alapértelmezett átjárónak mindenhol a natd démont futtató gép IP-címét kell megadni. Például a belsõ hálózaton található A és B kliensek IP-címei rendre 192.168.0.2 és 192.168.0.3, míg a &man.natd.8; démont futtató gép belsõ címe 192.168.0.1. Az A és a B kliens alapértelmezett átjáróját a natd gépre, vagyis a 192.168.0.1 címre kell beállítanunk. A natd gép külsõ, avagy internetes felülete semmilyen további módosítást nem igényel a &man.natd.8; mûködéséhez. A portok átirányítása A &man.natd.8; alkalmazásának hátránya, hogy a belsõ hálózatra csatlakozó kliensek az internetrõl nem érhetõek el. Tehát a helyi hálózat kliensei képesek elérni a külvilágot, de az visszafelé már nem igaz. Ez akkor jelent igazából problémát, ha az egyik belsõ kliensen szolgáltatásokat akarunk futtatni. A probléma egyik egyszerû megoldása, ha a natd használatával az internet felõl egyszerûen átirányítunk bizonyos portokat a megfelelõ belsõ kliensre. Például tegyük fel, hogy az A kliens egy IRC szervert, míg a B kliens egy webszervert futtat. Ez akkor fog mûködni, ha a szolgáltatásokhoz tartozó 6667 (IRC) és 80 (web) portokat átirányítjuk a hozzájuk tartozó gépek felé. Ehhez a &man.natd.8; démonnak a paramétert kell átadni. A pontos felírás így néz ki: -redirect_port protokoll célIP:célPORT[-célPORT] [külsõIP:]külsõPORT[-külsõPORT] [távoliIP[:távoliPORT[-távoliPORT]]] A fenti példában tehát ezt kell megadnunk: -redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 Így az egyes külsõ tcp portokat átirányítjuk a belsõ hálózat gépei felé. A paraméternek akár egész porttartományokat is megadhatunk. Például a tcp 192.168.0.2:2000-3000 2000-3000 megadásával az összes 2000-tõl 3000-ig terjedõ port csatlakozását leképezzük az A kliens 2000 és 3000 közti portjaira. Ezek a beállítások a &man.natd.8; közvetlen futtatásakor adhatóak meg, esetleg az /etc/rc.conf állományban az natd_flags="" opció keresztül, vagy egy külön konfigurációs állományban. A többi beállítási lehetõséget a &man.natd.8; man oldalán ismerhetjük meg. A címek átirányítása címátirányítás A címek átirányítása abban az esetben hasznos, amikor több IP-cím áll rendelkezésünkre, de ezek egy géphez tartoznak. Ilyenkor az &man.natd.8; képes a belsõ hálózat egyes gépeihez saját külsõ IP-címet rendelni. A &man.natd.8; a belsõ hálózat kliensei által küldött csomagokban kicseréli a címüket a megfelelõ külsõ IP-címmel, illetve az ezekre a címekre érkezõ forgalmat továbbítja a megfelelõ belsõ kliens irányába. Ezt a megoldást statikus hálózati címfordításnak is nevezzük. Például a 128.1.1.2 és a 128.1.1.3 IP-címek a natd démont futtató átjáróhoz tartoznak. A 128.1.1.1 cím használható a natd alapú átjáró külsõ IP-címeként, miközben a 128.1.1.2 és a 128.1.1.3 címeket a belsõ hálózaton elérhetõ A és B kliensek felé közvetítjük. A felírása tehát a következõ: -redirect_address helyiIP publikusIP helyiIP A helyi hálózaton található kliens saját IP-címe. publikusIP A klienshez tartozó megfelelõ külsõ IP-cím. Az iménti példában a pontos paraméterek ezek lesznek: -redirect_address 192.168.0.2 128.1.1.2 -redirect_address 192.168.0.3 128.1.1.3 A opcióhoz hasonlóan ez is megadható az /etc/rc.conf állományban az natd_flags="" beállításon keresztül vagy egy külön konfigurációs állományban. A címek átirányításával nincs szüksége a portok átirányítására, mivel az adott IP-címhez tartozó összes forgalmat átirányítjuk. A natd démont futtató gépen a külsõ IP-címeket aktiválni kell és a külsõ felületéhez kell rendelni. A &man.rc.conf.5; man oldalon járhatunk utána, hogy mindezt hogyan is tudjuk megcsinálni. Párhuzamos vonali IP (PLIP) PLIP párhuzamos vonali IP PLIP A párhuzamos vonali IP (Parallel Line IP, PLIP) a TCP/IP protokoll használatát valósítja meg párhuzamos porton keresztül. Olyan gépek számára lehet hasznos, amelyekben nincs hálózati kártya, vagy esetleg laptopoknál. Ebben a szakaszban a következõket tárgyaljuk: Párhuzamos (laplink) kábel készítése Két számítógép összekapcsolása a PLIP segítségével Párhuzamos kábel készítése Párhuzamos kábelt a legtöbb számítástechnikai boltban tudunk vásárolni. Ha mégsem tudnánk sehol sem beszerezni, vagy egyszerûen tudni szeretnénk, hogyan lehet ilyet készíteni, akkor az alábbi táblázatban láthatjuk, hogy miként tudunk egy hétköznapi nyomtatókábelt átalakítani a céljainkra. A párhuzamos kábel hálózati használatra alkalmas bekötése A-név A-vég B-vég Leírás Post/Bit DATA0 -ERROR 2 15 15 2 Adat 0/0x01 1/0x08 DATA1 +SLCT 3 13 13 3 Adat 0/0x02 1/0x10 DATA2 +PE 4 12 12 4 Adat 0/0x04 1/0x20 DATA3 -ACK 5 10 10 5 Vál. imp. 0/0x08 1/0x40 DATA4 BUSY 6 11 11 6 Adat 0/0x10 1/0x80 GND 18-25 18-25 Föld -
A PLIP beállítása Elõször is szereznünk kell valahonnan egy laplink kábelt. Ha ez megvan, akkor mind a két gépen ellenõrizzük, hogy a rendszermag tartalmazza az &man.lpt.4; meghajtót: &prompt.root; grep lp /var/run/dmesg.boot lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port A párhuzamos portnak megszakítással vezéreltnek kell lennie (interrupt driven), és az /boot/device.hints állományban szerepelnie kell nagyjából a következõ soroknak: hint.ppc.0.at="isa" hint.ppc.0.irq="7" Ezután nézzük meg, hogy a rendszermag beállításait tartalmazó állományban megjelenik-e a device plip sor, vagy a plip.ko modul betöltõdött-e. Akármelyik is történt, a párhuzamos hálózati felület most már a rendelkezésünkre áll, és az &man.ifconfig.8; paranccsal ezt meg is tudjuk nézni: &prompt.root; ifconfig plip0 plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 A laplink kábelt csatlakoztassuk mind a két számítógéphez. Mind a két a hálózati felület paramétereit root felhasználóként hangoljuk be. Például, ha az egyikgép nevû gépet akarjuk a másikgép nevû géphez csatlakoztatni: egyikgép <-----> másikgép IP-cím 10.0.0.1 10.0.0.2 Az egyikgép felületét így állítsuk be: &prompt.root; ifconfig plip0 10.0.0.1 10.0.0.2 A másikgép felületét így állítsuk be: &prompt.root; ifconfig plip0 10.0.0.2 10.0.0.1 Ezt követõen már egy mûködõ kapcsolatnak kell felépülnie. Az egyéb részletek kapcsán az &man.lp.4; és az &man.lpt.4; man oldalait nézzük át. Ezt a két gépet vegyük fel az /etc/hosts állományba is: 127.0.0.1 localhost.saját.tartomány localhost 10.0.0.1 egyikgép.saját.tartomány egyikgép 10.0.0.2 másikgép.saját.tartomány A kapcsolat mûködõképességérõl úgy tudunk meggyõzõdni, ha az egyik géprõl megpróbáljuk pingelni a másikat. Például az egyikgép esetében: &prompt.root; ifconfig plip0 plip0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 &prompt.root; netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire másikgép egyikgép UH 0 0 plip0 &prompt.root; ping -c 4 másikgép PING másikgép (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- másikgép ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms Aaron Kaplan Eredetileg írta: Tom Rhodes Átszervezte és kiegészítette: Brad Davis Tovább bõvítette: Az IPv6 Az IPv6 (másik néven az IPng, vagy a az internet következõ generációs protokollja, IP next generation) a jól ismert IP protokoll (avagy az IPv4) új változata. Hasonlóan a jelenleg mûködõ összes többi BSD rendszerhez, a &os; is tartalmazza a KAME IPv6 referencia implementációt. Ezért ha ezzel szeretnénk kísérletezni, akkor ehhez a &os; minden eszköz biztosít számunkra. Ez a szakasz az IPv6 beállítását és használatát mutatja be. Az 1990-es évek elején az IPv4-es címterek rohamos mértékû kimerülését figyelték meg. Az internet jelenlegi bõvülési üteme mellett két nagyobb aggodalomnak adott okot: A címek elfogyása. Napjainkban efelõl egyre kevesebb a kétség, mivel az RFC 1918 által megfogalmazott privát címterek (10.0.0.0/8, 172.16.0.0/12, és 192.168.0.0/16), valamint a hálózati címfordítás (Network Address Translation, NAT) használata igen elterjedt. Az útválasztási táblázatok méretének növekedése. Ez még manapság is aggasztó. Az IPv6 ezeket és még más egyéb problémákat a következõ módon igyekszik megoldani: A 128 bites címtér használata. Más szóval, elméletben összesen 340 282 366 920 938 463 463 374 607 431 768 211 456 darab címet képes kiosztani. Ez azt jelenti, hogy bolygónk minden egyes négyzetméterére megközelítõleg 6,67 * 10^27 IPv6 típusú cím jut. Az útválasztók a saját táblázataikban csak a hálózatok összevont címeit tárolják el, ezáltal egy átlagos útválasztási táblázatban található bejegyzések száma 8192 alá csökken. Az IPv6 emellett még rengeteg más elõnyös lehetõséget is kínál: A címek automatikus beállítása (lásd RFC 2462) Anycast (bárkiküldés, vagyis egy a sokból) Kötelezõ (mandatory) multicast IPsec (IP szintû védelem) Egyszerûsített fejléc Mobil IP IPv6-IPv4 közti átjárhatóság Ha mindezekrõl többet szeretnénk megtudni, akkor erre érdemes továbblépnünk: Az IPv6 áttekintése a playground.sun.com honlapon KAME.net Az IPv6 címek háttere Az IPv6 címeknek több típusa létezik: a unicast (egyesküldés), az anycast (bárkiküldés) és a multicast (többesküldés). A unicasthez használt címek jól ismert címek. Az így elküldött csomag pontosan ahhoz a felülethez érkezik meg, amelyhez az adott cím tartozik. Az anycasthez használt címek felírásukban tökéletesen megegyeznek a unicast esetével, de valójában felületek egy csoportját címezik. Az anycastre beállított címekre küldött csomagok mindig a(z útválasztó szerinti) legközelebb levõ felülethez érkeznek meg. Az anycastet az útválasztók számára találták ki. A multicasthez használt címek felületek egy csoportját nevezik meg. A multicast címekre érkezõ csomagokat a csoport minden egyes tagja megkapja. Az IPv4 esetében az üzenetszórásra szánt (általában az xxx.xxx.xxx.255 formátumú) címeket az IPv6 esetében multicast címekkel fejezzük ki. Fenntartott IPv6 címek IPv6 cím Az elõtag hossza (bitekben) Leírás Megjegyzés :: 128 bit nem specifikált Vö. a 0.0.0.0 címmel az IPv4 esetében. ::1 128 bit saját cím Vö. a 127.0.0.1 címmel az IPv4 esetében. ::00:xx:xx:xx:xx 96 bit IPv4 beágyazása Az alsó 32 bit egy IPv4 formátumú cím. Ezt IPv4 kompatibilis IPv6 címnek is nevezik. ::ff:xx:xx:xx:xx 96 bit IPv4-re leképzett IPv6 címek Az alsó 32 bit egy IPv4 címet jelöl. Olyan gépeknél használatos, amelyek nem támogatják az IPv6 protokollt. fe80:: - feb:: 10 bit helyi összeköttetés Vö. az IPv4 loopback címeivel. fec0:: - fef:: 10 bit helyi cím   ff:: 8 bit multicast   001 (2-es alapú) 3 bit globális unicast Az összes globális unicast címet ebbõl a tartományból osztjuk ki. Az elsõ 3 bit értéke001.
Az IPv6 címek olvasása Az IPv6 címek kanonikus formája így ábrázolható: x:x:x:x:x:x:x:x, ahol mindegyik x egy 16 bites hexadecimális érték. Például: FEBC:A574:382B:23C1:AA49:4592:4EFE:9982. Gyakran a címek hosszú nullákból álló sorozatokat tartalmaznak, ezért mindegyik ilyen sorozatot rövidíteni tudjuk a :: jelöléssel. Rajtuk kívül még az egyes hexadecimális csoportokban a bevezetõ nullák is elhagyhatóak. Például az fe80::1 cím kanonikus formája: fe80:0000:0000:0000:0000:0000:0000:0001. A harmadik forma szerint az utolsó 32 bites részt írjuk fel a megszokott (decimális) IPv4 stílusú pontozással, ahol tehát a . választja el a tagokat. Így például a 2002::10.0.0.1 felírás a 2002:0000:0000:0000:0000:0000:0a00:0001 kanonikus (hexadecimális) ábrázolásnak feleltethetõ meg, ami pedig egyszerûen 2002::a00:1 alakban is megadható. Mostanra már minden bizonnyal a kedves olvasó érteni fogja a következõt: &prompt.root; ifconfig rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 ether 00:00:21:03:08:e1 media: Ethernet autoselect (100baseTX ) status: active A fe80::200:21ff:fe03:8e1%rl0 cím az automatikusan beállított helyi összeköttetés címe. Ez az automatikus beállítás részeként a MAC-címbõl jött létre. Az IPv6 címek szerkezetérõl további részleteket az RFC 3513-ban találunk. Kapcsolódás Jelenleg négy módon tudunk más IPv6-os géphez és hálózathoz csatlakozni: Kérjünk a hálózati elérésünkért felelõs illetékesektõl IPv6 alapú hálózatot. A részletek tekintetében vegyük fel a kapcsolatot az internet-szolgáltatónkkal. A SixXS a világ minden táján kínál végpontokkal rendelkezõ tunneleket. Egy 6-ból-4 (RFC 3068) típusú tunnellel. Ha betárcsázós kapcsolatunk van, akkor használjuk a net/freenet6 portot. A nevek feloldása az IPv6 világában IPv6 alatt régebben két típusa volt a nevek feloldásáért felelõs rekordoknak. Az IETF az A6 rekordokat idõközben elavultnak nyilvánította. Ezért manapság már az AAAA rekordok tekinthetõek szabványosnak. Az AAAA rekordok használata magától értetõdik. A hálózati nevükhöz az alábbi módon tudunk IPv6 címet rendelni az elsõdleges zónát leíró állományban: SAJÁTNÉV AAAA SAJÁTIPv6CÍM Ha nem rendelkezünk saját névfeloldási zónával, akkor erre kérjük meg a névfeloldást végzõ szolgáltatónkat. A bind jelenlegi változatai (8.3 és 9), valamint a dns/djbdns (IPv6 támogatására vonatkozó javítással) támogatják az AAAA rekordokat. Az <filename>/etc/rc.conf</filename> szükséges módosításai Az IPv6 kliensek beállításai Ezek a beállítások egy helyi hálózaton levõ gépre vonatkoznak, nem pedig egy útválasztóra. Az &man.rtsol.8; az alábbi megadásával fogja automatikusan beállítani a felületeinket a rendszer indításakor: ipv6_enable="YES" Ha az fxp0 felülethez statikusan akarunk IP-címet rendelni, például a 2001:471:1f11:251:290:27ff:fee0:2093 címet, akkor ehhez a következõt kell megadni: ipv6_ifconfig_fxp0="2001:471:1f11:251:290:27ff:fee0:2093" Az /etc/rc.conf állományban az alapértelmezett átjárót a következõ módon tudjuk a 2001:471:1f11:251::1 címre beállítani: ipv6_defaultrouter="2001:471:1f11:251::1" Az IPv6 útválasztók és átjárók beállítása Itt most a tunnelt biztosító szolgáltató által mutatott irányt követjük, és olyan formára alakítjuk, amely megmarad az újraindítás után is. A rendszer indításakor az /etc/rc.conf állományban valami ilyesmit kell megadni a járat visszaállításához: Soroljuk fel a beállítandó általános tunnel alapú felületeket, ilyen lehet például a gif0: gif_interfaces="gif0" A felületnek állítsunk be egy helyi végpontot a SAJÁT_IPv4_CÍM megadásával, valamint egy távoli végpontot a TÁVOLI_IPv4_CÍM megadásával: gifconfig_gif0="SAJÁT_IPv4_CÍM TÁVOLI_IPv4_CÍM" Az IPv6 tunnelünk végpontjához kapott cím aktiválásához az alábbit kell még megadnunk: ipv6_ifconfig_gif0="SAJÁT_KAPOTT_IPv6_TUNNEL_VÉGPONTJÁNAK_CÍME" Ezután már csak az alapértelmezett útvonalat kell beállítani az IPv6 számára. Ez az IPv6 járat másik oldala: ipv6_defaultrouter="SAJÁT_IPv6_TÁVOLI_TUNNEL_VÉGPONTJÁNAK_CÍME" Az IPv6 tunnel beállításai Amennyiben a szerver IPv6 alapú forgalmat közvetít a hálózatunk és a világ között, az /etc/rc.conf állományba a következõt kell felvennünk: ipv6_gateway_enable="YES" Az útválasztók kihirdetése és automatikus konfigurációja Ebben a szakaszban az &man.rtadvd.8; beállításával fogjuk az alapértelmezett IPv6 útvonalat kihirdetni. Az &man.rtadvd.8; engedélyezéséhez az alábbi sort kell betennünk az /etc/rc.conf állományba: rtadvd_enable="YES" Emellett még fontos megadnunk azt a felületet, ahol az IPv6 útválasztó kérelmezését végezzük. Ha erre a feladatra például az fxp0 felületet választjuk, akkor errõl az &man.rtadvd.8; így értesíthetõ: rtadvd_interfaces="fxp0" Most pedig készítenünk kell hozzá egy konfigurációt is, vagyis az /etc/rtadvd.conf állományt. Íme erre egy példa: fxp0:\ :addrs#1:addr="2001:471:1f11:246::":prefixlen#64:tc=ether: Az fxp0 felületet természetesen cseréljük ki a sajátunkkal. Ezután a 2001:471:1f11:246:: címre helyére írjuk be a saját kiosztásunk elõtagját. Egy egész /64 alhálózat esetén nem is kell többet megadni. Minden más helyezetben az elõtag hosszára prefixlen# vonatkozó értéket is be kell még állítanunk. Harti Brandt Készítette: Az Aszinkron adatátviteli mód (ATM) A klasszikus IP-címek beállítása ATM felett (állandó) A klasszikus IP ATM felett (Classical IP over ATM, CLIP) a legegyszerûbb módszer az IP-címek használatára az Aszinkron adatátviteli móddal (Asynchronous Transfer Mode, ATM) együtt. Kapcsolt és állandó kapcsolatok (Switched Virtual Channel, SVC és Permanent Virtual Channel, PVC) esetén egyaránt megfelelõ. Ebben a szakaszban ez utóbbival fogunk foglalkozni. A teljesen hálószerû konfigurációk A CLIP beállítását állandó csatornákon például úgy tudjuk megoldani, ha az összes gépet külön ezekre a célokra szánt állandó csatornákkal összekapcsoljuk egymással. Ez az egyszerû megoldás azonban nagyobb számú gép esetében már nem eléggé hatékony. A következõ példában csupán négy gépet kötünk hálózatba, melyik mindegyike egy ATM kártyával csatlakozik az ATM hálózatra. Ehhez elsõként tervezzük meg az IP-címek kiosztását és a gépek közti ATM kapcsolatokat. A példában ez az alábbiak szerint alakul: Gép IP-cím A-gep 192.168.173.1 B-gep 192.168.173.2 C-gep 192.168.173.3 D-gep 192.168.173.4 A teljes hálózat felépítéséhez minden egyes pár között egy-egy ATM kapcsolatra lesz szükségünk: Gépek VPI.VCI pár A-gep - B-gep 0.100 A-gep - C-gep 0.101 A-gep - D-gep 0.102 B-gep - C-gep 0.103 B-gep - D-gep 0.104 C-gep - D-gep 0.105 A kapcsolatok egyes végein szereplõ VPI és VCI értékek természetesen eltérhetnek, de ezeket mi most az egyszerûség kedvéért egyenlõnek tekintettük. A következõ lépésben minden gépen állítsuk be az ATM felület: A-gep&prompt.root; ifconfig hatm0 192.168.173.1 up B-gep&prompt.root; ifconfig hatm0 192.168.173.2 up C-gep&prompt.root; ifconfig hatm0 192.168.173.3 up D-gep&prompt.root; ifconfig hatm0 192.168.173.4 up Ha feltételezzük, hogy minden gépen a hatm0 az ATM felület neve. Most pedig az A-gep-en állítsuk be az állandó csatornákat. (Itt most feltesszük, hogy az ATM switch-eken mindezt már elvégeztük. A switch kézikönyvében errõl részletesebb leírást is találhatunk.) A-gep&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr A-gep&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr A-gep&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 102 llc/snap ubr B-gep&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 100 llc/snap ubr B-gep&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 103 llc/snap ubr B-gep&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 104 llc/snap ubr C-gep&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 101 llc/snap ubr C-gep&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 103 llc/snap ubr C-gep&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 105 llc/snap ubr D-gep&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 102 llc/snap ubr D-gep&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 104 llc/snap ubr D-gep&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 105 llc/snap ubr Természetesen nem csak UBR használható, hanem minden más olyan forgalmazási beállítás, amit az ATM kártyáink ismernek. Itt most a forgalmi beállítás nevét a hozzátartozó konkrét paraméterek követik. Az &man.atmconfig.8; segédprogram használatához így kérhetünk segítséget: &prompt.root; atmconfig help natm add Olvassuk el az &man.atmconfig.8; man oldalát. Ugyanez a beállítás az /etc/rc.conf állomány használatával is elvégezhetõ. Az A-gep esetében mindez így nézne ki: network_interfaces="lo0 hatm0" ifconfig_hatm0="inet 192.168.173.1 up" natm_static_routes="B-gep C-gep D-gep" route_B-gep="192.168.173.2 hatm0 0 100 llc/snap ubr" route_C-gep="192.168.173.3 hatm0 0 101 llc/snap ubr" route_D-gep="192.168.173.4 hatm0 0 102 llc/snap ubr" A CLIP útvonalak pillanatnyi állapota így kérdezhetõ le: A-gep&prompt.root; atmconfig natm show Tom Rhodes Írta: A Közös cím redundancia protokoll (CARP) CARP Közös cím redundancia protokoll A Közös cím redundancia protokoll (Common Address Redundancy Protocol, avagy CARP) segítségével több gép képes egyazon IP-címen osztozni. Bizonyos konfigurációkban ez a terhelés elosztására (terhelés-kiegyenlítésre) vagy a rendelkezésre állás növelésére (hibatûrésre) alkalmazható. A benne szereplõ gépek akár eltérõ IP-címmel is rendelkezhetnek, ahogy azt majd a példában is láthatjuk. A CARP támogatásának engedélyezéséhez a &os; rendszermagját a következõ beállítással kell újrafordítanunk: device carp A CARP által biztosított lehetõségek ezután már elérhetõek, és számos sysctl változón keresztül állíthatóak: Változó Leírás net.inet.carp.allow A beérkezõ CARP csomagok elfogadása. Alapértelmezés szerint engedélyezett. net.inet.carp.preempt Ezzel a beállítással az adott gépen az összes CARP felület leáll, ha közülük bármelyik is mûködésképtelenné válik. Alapértelmezés szerint tiltott. net.inet.carp.log A 0 értékkel kikapcsoljuk a naplózást. Az 1 értékkel a rossz CARP csomagok naplózását engedélyezzük. Az ettõl nagyobb értékek esetén pedig a CARP felületek változásait naplózzuk. Az alapértelmezett értéke az 1. net.inet.carp.arpbalance Az ARP protokoll segítségével próbálja meg a helyi hálózati forgalmat mentesíteni a terheléstõl. Alapértelmezés szerint tiltott. net.inet.carp.suppress_preempt Ez a változó írásvédett, és a megszakítás elnyomásának állapotát mutatja. A megszakítás elnyomható, ha a felület egyik linkje nem mûködik. A 0 érték arra utal, hogy a megszakítást nem nyomták el. Minden probléma növeli ennek a változónak az értékét. A CARP eszközök maguk az ifconfig paranccsal készíthetõek el: &prompt.root; ifconfig carp0 create Egy valós környezetben az ilyen felületeknek egy VHID néven ismert egyedi azonosítóval kell rendelkezniük. Ez a VHID vagy más néven a virtuális gépazonosító (azaz Virtual Host Identification) fogja a gépünket a hálózat többi elemétõl megkülönböztetni. A CARP felhasználása a rendelkezésre állás javításában A CARP használatának egyik módja, ahogy arra már korábban is utaltunk, a szerverek rendelkezésre állásának feljavítása. Ebben a példában három géppel fogunk hibatûrést biztosítani, melyik mindegyike egyedi IP-címmel rendelkezik és ugyanazt a webes tartalmat szolgáltatják. A gépeket egy Round Robin rendszerû (körbejáró) névfeloldással együtt használjuk. A tartalék gépünknek lesz még további két CARP felülete, külön a szerver IP-címeihez tartozó egyes webes tartalmakhoz. Amikor valami meghibásodik, a tartalék szerver átveszi a meghibásodott gép IP-címét. Ilyenkor a hiba teljesen észrevétlen marad a felhasználók számára. A tartalék szerveren a többi szerverrel egyezõ tartalomnak és szolgáltatásoknak kell megjelennie, hogy bármikor át tudja tõlük venni a forgalmat. A hálózati neveiktõl és a virtuális azonosítóiktól eltekintve a két gépet ugyanúgy kell beállítani. Ebben a példában a gépeket most az a-gep.minta.org és b-gep.minta.org nevekkel láttuk el. Elõször is a CARP beállításához el kell helyeznünk a megfelelõ hivatkozásokat az rc.conf állományban. Az a-gep.minta.org esetében az rc.conf állomány a következõ sorokat tartalmazza: hostname="a-gep.minta.org" ifconfig_fxp0="inet 192.168.1.3 netmask 255.255.255.0" cloned_interfaces="carp0" ifconfig_carp0="vhid 1 pass testpass 192.168.1.50/24" Miközben a b-gep.minta.org az rc.conf állományában ezeket adjuk meg: hostname="b-gep.minta.org" ifconfig_fxp0="inet 192.168.1.4 netmask 255.255.255.0" cloned_interfaces="carp0" ifconfig_carp0="vhid 2 pass testpass 192.168.1.51/24" Nagyon fontos, hogy az ifconfig parancs pass paraméterével megadott jelszavak megegyezzenek. A carp eszközök csak a megfelelõ jelszót birtokló gépeket fogadják el. A virtuális gépazonosítónak azonban minden esetben el kell térnie. A harmadik, szolgaltato.minta.org címmel rendelkezõ gépet fogjuk felkészíteni az elõbbi gépek meghibásodására felkészíteni. Ennek a gépnek két carp eszközre lesz szüksége, melyek az egyes gépeket kezelik. Az ehhez illeszkedõ sorok valahogy így fognak kinézni az rc.conf állományban: hostname="szolgaltato.minta.org" ifconfig_fxp0="inet 192.168.1.5 netmask 255.255.255.0" cloned_interfaces="carp0 carp1" ifconfig_carp0="vhid 1 advskew 100 pass testpass 192.168.1.50/24" ifconfig_carp1="vhid 2 advskew 100 pass testpass 192.168.1.51/24" Két carp eszköz használatával a szolgaltato.minta.org képes észlelni és átvenni bármelyik olyan gép IP-címét, amely nem válaszol. Az alap &os; rendszermag használata esetén elõfordulhat, hogy a megszakítás (a preemption opció) engedélyezett. Amennyiben így lenne, a szolgaltato.minta.org nem fogja minden esetben fogja rendesen visszaadni az IP-címet az eredeti tulajdonosának. Ilyenkor a rendszergazdának kell ezt manuálisan megtennie. Tehát a következõ parancsot kell kiadnia a szolgaltato.minta.org gépen: &prompt.root; ifconfig carp0 down && ifconfig carp0 up Ezt az adott géphez tartozó carp felülettel kell megcsinálni. Innentõl a CARP már teljesen engedélyezhetõ és készen áll a tesztelésre. A teszteléshez vagy a hálózati rendszert kell újraindítani, vagy a gépeket. További információkat a &man.carp.4; man oldalán találhatunk. diff --git a/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml index 8897736424..5e53d46476 100644 --- a/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/cutting-edge/chapter.sgml @@ -1,4605 +1,4605 @@ Jim Mock Átdolgozta, átrendezte és egyes részeit aktualizálta: Jordan Hubbard Eredetileg írta: Poul-Henning Kamp John Polstra Nik Clayton A &os; frissítése és frissen tartása Áttekintés A &os; a kiadások közt is állandó fejlõdésben van. Vannak felhasználók, akik a hivatalosan kiadott változatokat használják, és vannak, akik szeretik folyamatosan nyomonkövetni a fejlesztéseket. Emellett viszont a hivatalos kiadások esetében szükség lehet bizonyos biztonsági frissítések és kritikus javítások alkalmazására. Függetlenül a pillanatnyilag használt változattól, a &os; alaprendszerében megtalálható minden olyan eszköz, amellyel könnyedén frissíteni tudunk a különbözõ verziók között. Ebben a fejezetben segítünk dönteni a fejlesztõi változat és a kiadások használata között. Továbbá megismerhetjük a rendszer frissítéséhez használható alapvetõ eszközöket. A fejezet elolvasása során megismerjük: milyen segédprogramokkal tudjuk frissíteni az alaprendszert és a Portgyûjteményt; hogyan tartsuk naprakészen rendszerünket a freebsd-update, CVSup, CVS vagy CTM használatával; hogyan vessük össze a telepített rendszerünk aktuális állapotát egy ismert eredeti változattal; hogyan frissítsük a dokumentációt CVSup vagy dokumentációs portok segítségével. a két fejlesztõi ág, a &os.stable; és a &os.current; közti különbséget; a make buildworld (stb.) segítségével hogyan fordítsuk és telepítsük újra az egész alaprendszert. A fejezet elolvasásához ajánlott: a hálózati kapcsolatunk helyes beállítása (); a külsõ szoftverek telepítésének ismerete (). A fejezetben a &os; forrásainak frissítését a cvsup parancs segítségével fogjuk elvégezni. Ehhez telepítsük a net/cvsup-without-gui portot vagy csomagot, vagy ha már a &os; 6.2-RELEASE vagy késõbbi változatával rendelkezünk, akkor elegendõ csak az alaprendszer részeként elérhetõ &man.csup.1; programot használnunk. Tom Rhodes Írta: Colin Percival A megíráshoz felhasznált jegyzeteket készítette: A &os; frissítése frissítés és frissen tartás freebsd-update frissítés és frissen tartás A biztonsági javítások telepítése minden számítógépes szoftver, különösen az operációs rendszerek számára lényeges mozzanat. Nagyon hosszú ideig ez a &os; esetében nem volt könnyen megoldható: a javításokat közvetlenül a forráskódon kellett elvégezni, ezekbõl újrafordítani a rendszert, majd telepíteni. Ez a nehézség mostanra viszont már elhárult, mivel a &os; legfrissebb verziói már tartalmaznak egy freebsd-update nevû segédprogramot, amellyel mindez leegyszerûsödik. Ez a program két külön funkciót lát el. Elõször is, lehetõvé teszi, hogy a &os; alaprendszer újrafordítása és -telepítése nélkül javítsunk biztonsági és egyéb apró hibákat, valamint másodsorban támogatja a kisebb és nagyobb verziójú kiadások közti váltást. Ezek a bináris frissítések azonban csak a &os; biztonsági csapata által is felügyelt architektúrák és kiadások esetén érhetõek el. Emellett bizonyos lehetõségek használatához, például a &os; verziói közti átállás támogatásához a &man.freebsd-update.8; legújabb változata, valamint minimum a &os; 6.3 kiadása szükségeltetik. Ezért ne felejtsük el alaposan átolvasni a legújabb kiadásokról szóló bejelentéseket mielõtt frissítenénk rájuk, mivel ezzel kapcsolatban fontos információkat tartalmazhatnak. Az említett bejelentések a címen érhetõek el. Ha a crontab már hivatkozik a freebsd-update programra, akkor a most következõ mûvelet elkezdése elõtt tiltsuk le. A konfigurációs állományok - Elõfordulhat, hogy változtatni akarunk valamin - a frissítési folyamatban és ezért - szeretnénk módosítani a programhoz - tartozó konfigurációs - állományt. Az opciók részletes - ismertetéssel rendelkeznek, habár + Ha változtatnénk szeretnénk a + frissítési folyamaton, ekkor a programhoz + tartozó, /etc/freebsd-update.conf + nevû konfigurációs állományt + kell módosítanunk. Az opciók + részletes ismertetéssel rendelkeznek, habár némelyiknél még további magyarázat kellhet: # Az alaprendszerben frissíteni kívánt komponensek Components src world kernel Ezzel a paraméterrel határozhatjuk meg, hogy a &os; mely részei kerüljenek frissítésre. Alapértelmezés szerint a program frissíti a forrásokat, a teljes alaprendszert és a rendszermagot. Komponensként a telepítésnél választható elemeket adhatjuk meg, például "world/games" hozzáadásakor a games kategória elemei is folyamatosan frissülni fognak. Az "src/bin" megadásakor pedig az src/bin könyvtár tartalma frissül. Ezt a beállítást a legjobb meghagyni az alapértelmezett értéken, mivel a további elemek megadásánál egyenként fel kell sorolni a frissítendõ komponenseket. Ha itt viszont kifelejtünk valamit, akkor könnyen megeshet, hogy a források és a binárisok verziója elcsúszik egymástól. # Az IgnorePaths beállítás után megadott szövegre illeszkedõ összes # bejegyzés frissítése kimarad IgnorePaths Ennél a beállításnál azokat a könyvtárakat kell megadnunk, amelyeket (és tartalmukat) ki szeretnénk hagyni a frissítés során. Ezek lehetnek például a /bin vagy az /sbin. Így meg tudjuk akadályozni, hogy freebsd-update esetleg felülírjon valamilyen helyi változtatást a rendszerünkben. # Az UpdateIfUnmodified beállítás után megadott elérési útvonalakon csak # a felhasználó által még nem módosított állományok fognak frissülni # (hacsak a módosításokat össze nem fésüljük, lásd lentebb) UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile A megadott könyvtárakban csak azokat a konfigurációs állományokat fogja frissíteni, amelyeket nem változtattuk meg. Amennyiben bármelyikük eltér az eredetileg frissítendõ változattól, azt a program nem módosítja. Létezik egy másik hasonló beállítás, a KeepModifiedMetadata, amely hatására a freebsd-update az összefésülés során elmenti a változtatásokat. # A MergeChanges beállításnál szereplõ állományok helyi módosításait # automatikusan összefésüljük a &os; újabb verziójára frissítése közben MergeChanges /etc/ /var/named/etc/ Itt azokat a könyvtárakat adhatjuk meg, amelyekben a freebsd-update számára engedélyezzük a konfigurációs állományok új verziójának összefésülését a jelenlegi állapottal. Az összefésülés lényegében a &man.mergemaster.8; használatánál már megszokott módon, &man.diff.1; formátumban érkezõ módosítások sorozata alapján történik. Ekkor egy szövegszerkesztõ segítségével felügyelhetjük az összefésülés menetét vagy megállíthatjuk a freebsd-update futását. Ha kétségeink adódnak, akkor egyszerûen mentsük le az /etc könyvtárat és fogadjuk el mindegyik összefésülés eredményét. A mergemaster mûködésérõl a ad részletesebb tájékoztatást. # A &os; frissítésekor ezt a könyvtárat fogja a program használni a # letöltött módosítások és az egyéb ideiglenes állományok tárolására # WorkDir /var/db/freebsd-update Az itt megadott könyvtárba fognak kerülni az elvégzendõ módosítások és az egyéb ideiglenesen keletkezõ állományok. A verziók közti váltás során ebben a könyvtárban ajánlott legalább 1 GB szabad tárterületnek lennie. # A kiadások közti váltás során a Components beállításnál megadott # elemek kerüljenek csak frissítésre (StrictComponents yes), vagy a # program próbálja meg magától kitalálni, hogy milyen komponesek # *lehetnek* fenn a rendszeren és azokat frissítse (StrictComponents # no)? # StrictComponents no Ha ennél a beállításnál a yes értéket adjuk meg, akkor a freebsd-update feltételezni fogja, hogy a Components opciónál felsoroltunk minden frissítendõ komponenst és nem próbál meg mást is megváltoztatni. Ilyenkor tehát a freebsd-update tulajdonképpen egyedül csak a Components által meghatározott elemekhez tartozó állományokat fogja frissíteni. Biztonsági javítások A biztonsági javítások mindig egy távoli gépen tárolódnak, a következõ parancsok használatával tölthetõek le és telepíthetõek: &prompt.root; freebsd-update fetch &prompt.root; freebsd-update install Amennyiben a rendszermagot is érintik javítások, úgy a rendszert a mûvelet befejezõdésével újra kell indítanunk. Ha minden a megfelelõ módon történt, akkor a rendszerünk már tartalmazni fogja a korábban letöltött és telepített javításokat, és a freebsd-update akár beállítható egy naponta végrehajtandó &man.cron.8; feladatnak. Ehhez mindössze a következõ bejegyzést kell elhelyeznünk az /etc/crontab állományban: @daily root freebsd-update cron A bejegyzés szerint naponta egyszer le fog futni a freebsd-update. Ilyenkor, vagyis a paraméter megadásakor a freebsd-update csak ellenõrzi, hogy vannak-e telepítendõ frissítések. Ha talál, akkor automatikusan letölti ezeket a lemezre, de nem telepíti. Helyette levélben értesíti a root felhasználót, aki ezután bármikor manuálisan kérheti a telepítést. Probléma esetén az alábbi paranccsal megkérhetjük a freebsd-update programot a legutóbb telepített módosítások visszavonására: &prompt.root; freebsd-update rollback Ha ez a visszavonás a rendszermagra vagy annak moduljaira is vonatkozott, akkor a rendszert újra kell indítanunk a parancs futásának befejezõdésével. A &os; csak ilyenkor képes betölteni az új binárisokat betölteni a memóriába. A freebsd-update önmagától csak a GENERIC típusú rendszermagokat képes frissíteni. Ha saját rendszermagot használunk, akkor azt a rendszer többi komponensének frissítését követõen újra kell fordítanunk és telepítenünk. A freebsd-update azonban még akkor is érzekelni és frissíteni fogja a GENERIC rendszermagot (amennyiben az létezik), ha az éppen nem az aktuális(an futó) rendszermag. Mindig érdemes tartani egy másolatot a GENERIC rendszermagról a /boot/GENERIC könyvtárban. Rengeteg különbözõ probléma felderítésében tud segíteni, illetve ez a szakaszban leírt freebsd-update programmal végzett frissítéseknél is hasznos lehet. Hacsak nem változtatjuk meg az /etc/freebsd-update.conf állományt, a freebsd-update a rendszermag forrásait is frissíti a többivel együtt. A saját rendszermag újrafordítása és telepítése ezután a már a megszokott módon elvégezhetõ. A freebsd-update által terjesztett frissítések nem mindig érintik a rendszermagot. Ha a rendszermag forrásai nem változnak egy freebsd-update install parancs kiadása során, akkor nem kötelezõ újrafordítani a saját rendszermagot. A freebsd-update viszont mindig módosítani fogja a /usr/src/sys/conf/newvers.sh állományt. Itt az aktuális hibajavítás sorszáma szerepel (amelyet a -p (mint patch level elõtaggal kapcsolnak a rendszer verziójához, és a uname -r paranccsal lehet lekérdezni). Ennek megfelelõen tehát a saját rendszermag újrafordítása után, még ha semmi más nem is változott, a &man.uname.1; képes pontosan jelezni a rendszerhez készült hibajavítás sorszámát. Ez különösen fontos több rendszer karbantartása során, mivel így könnyen és gyorsan tájékozódhatunk azok naprakészségérõl. Váltás kisebb és nagyobb verziók között Verziók közti váltás során a külsõ alkalmazások mûkõdését akadályozó régi tárgykódok és függvénykönyvtárak törlõdni fognak. Ezért javasoljuk, hogy vagy töröljük le az összes portot és telepítsük újra, vagy az alaprendszer frissítése után hozzuk ezeket is naprakész állapotba a ports-mgmt/portupgrade segédprogram segítségével. Elõször minden bizonnyal szeretnék kipróbálni a frissítést, ezt a következõ paranccsal tehetjük meg: &prompt.root; portupgrade -af Ezzel gondoskodunk róla, hogy a minden a megfelelõen telepítõdjön újra. Ha a BATCH környezeti változót a yes értékre állítjuk, akkor a folyamat során megjelenõ összes kérdésre automatikusan a yes választ adjuk, ezáltal önállósítani tudjuk. Ha saját rendszermagot használunk, akkor ennél valamivel azért több feladatunk van. Szükségünk lesz a GENERIC rendszermagot egy példányára, amelyet másoljunk a /boot/GENERIC könyvtárba. Amennyiben nincs GENERIC típusú rendszermag a rendszerünkön, a következõ módok valamelyikén keresztül tudunk szerezni: Ha a saját rendszermagot még csak egyszer fordítottuk, akkor a /boot/kernel.old könyvtárban még megtalálható a GENERIC. Ezt nevezzük át egyszerûen /boot/GENERIC könyvtárra. Ha fizikailag hozzá tudunk férni az érintett géphez, akkor a GENERIC egy példányát akár CD-rõl is átmásolhatjuk. Helyezzük be a telepítõlemezt és adjuk ki a következõ parancsokat: &prompt.root; mount /cdrom &prompt.root; cd /cdrom/X.Y-RELEASE/kernels &prompt.root; ./install.sh GENERIC Itt a X.Y-RELEASE könyvtár nevében értelemszerûen helyettesítsük be az általunk használt változatot. A GENERIC rendszermag ekkor alapértelmezés szerint a /boot/GENERIC könyvtárba kerül. Ha az elõbbiek közül egyik sem lehetséges, akkor a GENERIC rendszermagot közvetlenül akár forrásból is lefordíthatjuk és telepíthetjük: &prompt.root; cd /usr/src &prompt.root; env DESTDIR=/boot/GENERIC make kernel &prompt.root; mv /boot/GENERIC/boot/kernel/* /boot/GENERIC &prompt.root; rm -rf /boot/GENERIC/boot A freebsd-update akkor fogja ezt GENERIC rendszermagként felismerni, ha a hozzátartozó konfigurációs állományt nem módosítjuk. Továbbá javasoljuk, hogy semmilyen speciális beállítást ne alkalmazzunk a fordítás során (érdemes üresen hagyni ehhez az /etc/make.conf állományt). Nem kötelezõ újraindítani a rendszert a GENERIC rendszermaggal. A freebsd-update képes frissíteni rendszerünket egy adott kiadásra. Például a következõ paraméterek megadásával válthatunk a &os; 6.4 használatára: &prompt.root; freebsd-update -r 6.4-RELEASE upgrade A parancs elindulása után nem sokkal, a váltáshoz szükséges információk összegyûjtéséhez a freebsd-update elemzi a konfigurációs állományában megadott beállításokat és a rendszer jelenleg használt verzióját. A képernyõn ekkor sorban megjelennek a program részérõl érzékelt és nem érzékelt komponensek. Mint például ahogy itt látható: Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 6.3-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/info world/lib32 world/manpages The following components of FreeBSD do not seem to be installed: kernel/generic world/catpages world/dict world/doc world/games world/proflibs Does this look reasonable (y/n)? y Ekkor a freebsd-update megpróbálja letölteni a verziók közti váltáshoz szükséges összes állományt. Bizonyos esetekben kérdésekkel fordul a felhasználó felé arra vonatkozóan, hogy miket telepítsen fel vagy mit csináljon. A saját rendszermag használatakor az iménti lépés valamilyen ehhez hasonló figyelmeztetést fog adni: WARNING: This system is running a "SAJÁT RENDSZERMAG" kernel, which is not a kernel configuration distributed as part of FreeBSD 6.3-RELEASE. This kernel will not be updated: you MUST update the kernel manually before running "/usr/sbin/freebsd-update install" Ez a figyelmeztetés most nyugodtan figyelmen kívül hagyható. A folyamat során a frissített GENERIC rendszermagot fogjuk használni. A javítások letöltését követõen megkezdõdik a telepítésük. A váltás ezen lépése az adott gép aktuális terhelésétõl és sebességétõl függõen változó hosszúságú lehet. Ezután a konfigurációs állományok összefésülése zajlik le — itt általában a emberi felügyeletre is szükség van az állományok összefésülésének irányításához, amelynek folyamatosan láthatóak az eredményei. A meghiúsult vagy kihagyott összefésülések a teljes frissítési folyamat leállását vonják maguk után. Az /etc könyvtárban tárolt fontosabb állományokról, mint például a master.passwd vagy group javasolt elõzetesen biztonsági mentést készíteni és késõbb kézzel hozzájuk adni a változtatásaikat. A rendszerben ekkor még nem lesz jelen semmilyen konkrét változás, az összes említett javítás és összefésülés egy külön könyvtárban történik. A telepített javításokat és az összefésült konfigurációs állományokat a folyamat végén magának a felhasználónak kell véglegesíteni. A frissítési eljárás végén a következõ parancs kiadásával tudjuk ténylegesen érvényesíteni az eddig elvégzett módosításokat: &prompt.root; freebsd-update install Elõször mindig a rendszermag és a hozzátartozó modulok cserélõdnek le. Ahogy ez végrehajtódott, újra kell indítanunk a rendszert. Ha saját rendszermagot használunk, akkor a &man.nextboot.8; parancs segítségével állítsuk be a következõ rendszerindítás során betöltendõ rendszermagot a /boot/GENERIC könyvtárban levõre (ezt frissítettük): &prompt.root; nextboot -k GENERIC Mielõtt újraindítanánk a gépünket a GENERIC rendszermaggal, gyõzõdjünk meg róla, hogy szerepel benne minden olyan meghajtó, amely elengedhetetlen a rendszer hiánytalan indításához (és képes lesz újra csatlakozni a hálózathoz, ha éppen távolról adminisztráljuk). Ez különösen olyan esetben fontos, amikor a saját rendszermagunkban beépítetten szerepeltek bizonyos modulok. Ilyenkor a GENERIC rendszermag használatakor ezeket a /boot/loader.conf állományon keresztül töltethetjük be ideiglenesen. A frissítés befejezéséig érdemes viszont minden nem létfontosságú szolgáltatást leállítani, leválasztani lemezeket és hálózati megosztásokat stb. A rendszerünk most már újraindítható a frissített rendszermaggal: &prompt.root; shutdown -r now A rendszer sikeres újraindulása után ismét el kell indítanunk a freebsd-update programot, amely korábban már elmentette a frissítés állapotát, emiatt a legutóbbi pontról fog folytatódni, illetve törli az osztott könyvtárak és tárgykódok régebbi változatait. Innen az alábbi paranccsal léphetünk tovább: &prompt.root; freebsd-update install A függvénykönyvtárak verziói közti eltérések mértékétõl függõen elképzelhetõ, hogy a telepítés az említett három fázis helyett kettõben történik. Most pedig újra kell fordítanunk vagy telepítenünk az összes általunk korábban használt külsõ alkalmazást. Erre azért van szükségünk, mert bizonyos alkalmazások a verziók közti váltás során törölt programkönyvtáraktól függtek. Ennek automatizálásában a ports-mgmt/portupgrade lesz segítségünkre. Az alkalmazások frissítésének elindításához a következõ parancsokat használjuk: &prompt.root; portupgrade -f ruby &prompt.root; rm /var/db/pkg/pkgdb.db &prompt.root; portupgrade -f ruby18-bdb &prompt.root; rm /var/db/pkg/pkgdb.db /usr/ports/INDEX-*.db &prompt.root; portupgrade -af A parancsok lefutását követõen a freebsd-update utolsó hívásával zárjuk le a frissítést. Ezzel a paranccsal tudunk tehát pontot tenni a frissítési procedúra végére: &prompt.root; freebsd-update install Ha a GENERIC rendszermagot csak átmenetileg használtuk, akkor most már a megszokott módon fordíthatunk és telepíthetünk magunk egy saját rendszermagot. Indítsuk újra a rendszert a &os; frissített változatával. A folyamat ezzel véget ért. Rendszerek állapotainak összehasonlítása A freebsd-update ragyogóan felhasználható a &os; egy telepített változatának és egy általunk garantáltan megbízható példányának összevetésére. Ilyenkor a rendszerhez tartozó segédprogramokat, programkönyvtárakat és konfigurációs állományokat ellenõriztethetjük le. Az összehasonlítást ezzel a paranccsal kezdhetjük meg: &prompt.root; freebsd-update IDS >> eredmeny.idk Habár a parancs neve IDS (intrusion detection system), nem helyettesít semmilyen olyan behatolásjelzõ megoldást, mint amilyen például a security/snort. Mivel a freebsd-update adatokat tárol a lemezen, teljesen kézenfekvõ a hamisítás lehetõsége. Míg ennek eshetõsége adott mértékben visszaszorítható a kern.securelevel csökkentésével és a freebsd-update által használt adatok írásvédett állományrendszerre helyezésével, erre a problémára az ideális megoldást mégis egy teljes biztonságban tudható referencia rendszer jelentheti. Ennek tárolására alkalmas lehet például egy DVD vagy egy külsõ USB-egység. A parancs kiadása után megkezdõdik a rendszer vizsgálata, és az ellenõrzés során folyamatosan jelennek meg az átvizsgált állományok a hozzájuk tartozó ismert és kiszámított &man.sha256.1;-kódjukkal együtt. Mivel a képernyõn túlságosan gyorsan elúsznának az eredmények, ezért ezeket egy eredmeny.idk nevû állományba mentjük a késõbbi elemzésekhez. Az így keletkezõ állomány sorai ugyan meglehetõsen hosszúak, de szerencsére viszonylag könnyen értelmezhetõek. Például az adott kiadásban szereplõ állományoktól eltérõeket ezzel a paranccsal kérdezhetjük le: &prompt.root; cat eredmeny.idk | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf A példában most csak az elsõ néhány állományt hagytuk meg, gyakran tapasztalhatunk viszont ennél többet. Ezek közül bizonyos állományok értelemszerûen eltérnek, mint itt például az /etc/passwd, mert idõközben új felhasználókat adtunk a rendszerhez. Máskor egyéb állományok, például modulok nevei is felbukkanhatnak, mert tegyük fel, hogy a freebsd-update már frissítette ezeket. Ha ki szeretnénk zárni valamilyen állományokat vagy könyvtárakat az ellenõrzésbõl, egyszerûen csak soroljuk fel ezeket az /etc/freebsd-update.conf állományban megjelenõ IDSIgnorePaths beállításnál. A korábban tárgyaltaktól függetlenül ez a rendszer alkalmas bonyolultabb frissítési folyamatok kisegítésére is. Tom Rhodes Írta: Colin Percival A megíráshoz felhasznált jegyzeteket készítette: A Portgyûjtemény frissítése a Portsnap használatával frissítés és frissen tartás Portsnap frissítés és frissen tartás A &os; alaprendszer a Portgyûjtemény frissítéséhez is tartalmaz egy &man.portsnap.8; elnevezésû segédprogramot. Ez a program elindítása után csatlakozik egy távoli géphez, ellenõrzi a biztonsági kulcsát és letölti a portok legfrissebb változatait. A biztonsági kulcs feladata a frissítés közben letöltött állományok sértetlenségének szavatolása, ezzel gondoskodik róla, hogy az adatok átvitelük közben nem változtak meg. A Portgyûjtemény legújabb változatát így érhetjük el: &prompt.root; portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found. Fetching snapshot tag from portsnap1.FreeBSD.org... done. Fetching snapshot metadata... done. Updating from Wed Aug 6 18:00:22 EDT 2008 to Sat Aug 30 20:24:11 EDT 2008. Fetching 3 metadata patches.. done. Applying metadata patches... done. Fetching 3 metadata files... done. Fetching 90 patches.....10....20....30....40....50....60....70....80....90. done. Applying patches... done. Fetching 133 new ports or files... done. A példában látható, hogy a &man.portsnap.8; eltéréseket talált a helyi és a távoli rendszerekben fellelhetõ portok között, majd azokat ellenõrizte. Emellett az is megfigyelhetõ, hogy korábban már futtatuk a programot, mivel ha most indítottuk volna az elsõ alkalommal, akkor egyszerûen letöltötte volna a teljes Portgyûjteményt. Ahogy a &man.portsnap.8; sikeresen befejezi az imént kiadott fetch mûvelet végrehajtását, a helyi rendszeren már telepítésre készen fognak várakozni a Portgyûjtemény és az hozzátartozó ellenõrzött módosítások. A portsnap elsõ használatakor az extract parancs segítségével telepíthetjük a frissített állományokat: &prompt.root; portsnap extract /usr/ports/.cvsignore /usr/ports/CHANGES /usr/ports/COPYRIGHT /usr/ports/GIDs /usr/ports/KNOBS /usr/ports/LEGAL /usr/ports/MOVED /usr/ports/Makefile /usr/ports/Mk/bsd.apache.mk /usr/ports/Mk/bsd.autotools.mk /usr/ports/Mk/bsd.cmake.mk ... A portsnap fetch késõbbi futtatásakor viszont már az update parancsot kell használnunk: &prompt.root; portsnap update Ezzel lezárult a portok frissítése, innentõl már az aktualizált Portgyûjtemény felhasználásával tetszõlegesen telepíthetõek vagy frissíthetõek az alkalmazások. A fetch, extract vagy update mûveletek egyetlen parancsba is összefûzhetõek, ahogy ezt az alábbi példában is láthatjuk: &prompt.root; portsnap fetch update A dokumentáció frissítése frissítés és frissen tartás dokumentáció frissítés és frissen tartás Az alaprendszer és a Portgyûjtemény mellett a dokumentáció is a &os; operációs rendszer szerves részét képezi. Noha a &os; dokumentációjának legfrissebb változata folyamatosan elérhetõ a &os; honlapjáról, egyes felhasználók ezt csak lassan vagy nem képesek folyamatosan elérni. Szerencsére egy helyi másolat megfelelõ karbantartásával az egyes kiadásokhoz tartozó dokumentáció is frissíthetõ. A dokumentáció frissítése CVSup használatával A &os; telepített dokumentációjának forrásai az alaprendszeréhez hasonlóan (lásd ) a CVSup segítségével frissíthetõek. Ebben a szakaszban megismerhetjük: hogyan telepítsük a dokumentáció elõállításához szükséges eszközöket, amelyekkel a forrásokból újra tudjuk generálni a &os; dokumentációját; hogyan töltsük le a dokumentáció forrását CVSup segítségével a /usr/doc könyvtárba; a dokumentáció elõállításához alkalmazott rendszer milyen beállításokkal rendelkezik, vagyis hogyan korlátozzuk a generálást bizonyos nyelvekre vagy formátumokra. A CVSup és a dokumentációs eszközök telepítése Viszonylag sokféle eszközre lesz szükségünk, ha a &os; dokumentációját a forrásokból akarjuk elõállítani. Ezek az segédprogramok nem részei a &os; alaprendszerének, mivel alapvetõen nagyon sok helyet foglalnak el, és leginkább olyan &os; felhasználók számára fontosak, akik folyamatosan a dokumentációval dolgoznak vagy gyakran frissítik azt forrásból. A feladathoz szükséges összes eszköz elérhetõ a Portgyûjteménybõl. Ebben a &os; Dokumentációs Projekt összeállított egy textproc/docproj nevû portot, amellyel az említett programok telepítését és frissítését igyekezték megkönnyíteni. Ha nem tartunk igényt a dokumentáció &postscript; vagy PDF változatára, akkor ehelyett inkább érdemes megfontolnunk a textproc/docproj-nojadetex port telepítését. Ebben a változatban a teTeX betûszedõ rendszer kivételével az összes segédprogram megtalálható. Mivel a teTeX önmagában nagyon sok segédeszköz telepítését jelenti, ezért amennyiben a PDF változat ténylegesen nem szükséges, érdemes eltekinteni a telepítésétõl. A CVSup telepítésével kapcsolatban pedig részletesebb információkat a CVSup használatával foglalkozó szakaszban olvashatunk. A dokumentáció forrásának frissítése A /usr/share/examples/cvsup/doc-supfile konfigurációs állomány segítségével a CVSup képes letölteni a dokumentáció forrásállományainak legfrissebb példányait. Itt a frissítést alapértelmezés szerint egy nem létezõ géptõl fogjuk kérni (mivel ezt kötelezõ kitölteni), azonban a &man.cvsup.1; programnak egy parancssori paraméter segítségével megadhatjuk melyik CVSup szerverrõl töltse le a forrásokat: &prompt.root; cvsup -h cvsup.FreeBSD.org -g -L 2 /usr/share/examples/cvsup/doc-supfile Ne felejtsük el a cvsup.FreeBSD.org helyére beírni a hozzánk földrajzilag legközelebb elhelyezkedõ CVSup szervert. Ezek teljes listáját a tartalmazza. Egy ideig eltarthat, amíg elõször letöltjük a forrásokat. Várjuk meg türelmesen, amíg befejezõdik a mûvelet. Késõbb a forrásokat ugyanezzel a paranccsal tudjuk frissíteni. A CVSup ugyanis mindig csak a legutóbbi futtatása óta történt változásokat tölti le, ezért késõbb már ez a lépés jelentõsen felgyorsulhat. A források letöltése után a dokumentációt például az ekkor keletkezett /usr/doc könyvtárban található Makefile használatával állíthatjuk elõ. Tehát miután az /etc/make.conf állományban beállítottuk a SUP_UPDATE, SUPHOST és DOCSUPFILE változókat, le tudjuk futtatni a következõ parancsot: &prompt.root; cd /usr/doc &prompt.root; make update Az elõbb említett &man.make.1; változók jellemzõ értékei: SUP_UPDATE= yes SUPHOST?= cvsup.freebsd.org DOCSUPFILE?= /usr/share/examples/cvsup/doc-supfile Mivel a SUPHOST és a DOCSUPFILE változók értékét a ?= szimbólummal állítottuk be, lehetõségünk van a parancssorból ezeknek más értékeket adni. Az /etc/make.conf állományba általában így érdemes felvenni a változókat, így nem kell minden alkalommal módosítani, amikor valamilyen új beállítást akarunk kipróbálni. A dokumentáció különbözõ beállításai A &os; dokumentációjához tartozó, frissítést és elõállítást végzõ rendszernek van néhány olyan beállítása, amelyekkel kérhetjük kizárólag csak a dokumentáció egyes részeinek frissítését vagy bizonyos kimeneti formátumok használatát. Ezek vagy globálisan az /etc/make.conf állományban, vagy pedig a parancssorból, a &man.make.1; program paramétereként adhatóak meg. Ízelítõül néhány közülük: DOC_LANG Az elõállítandó és telepítendõ nyelvû dokumentáció felsorolása, tehát például csak az angol dokumentáció esetén ez en_US.ISO8859-1. FORMATS Az elõállítandó dokumentáció kimeneti formátumainak felsorolása. Itt pillanatnyilag értékként a html, html-split, txt, ps, pdf és rtf jelenhet meg. SUPHOST A frissítéshez használt CVSup szerver hálózati neve. DOCDIR Az elkészült dokumentáció telepítésének helye. Ez alapértelmezés szerint a /usr/share/doc. A folyamathoz kapcsolódóan további rendszerszintû &man.make.1; változókról a &man.make.conf.5; man oldalon olvashatunk. A &os; dokumentációjának elõállításáért felelõs rendszerben használható &man.make.1; további változók bemutatásával kapcsolatban pedig olvassuk el az A &os; Dokumentációs Projekt irányelvei kezdõknek címû könyvet. A &os; dokumentációjának telepítése forrásból Miután sikerült letöltenünk a /usr/doc könyvtárba a dokumentáció legfrissebb forrásait, készen állunk a rendszerünkön telepített példány frissítésére. A DOCLANG értékeként megadott nyelven készült dokumentációkat a következõ paranccsal tudjuk frissíteni: &prompt.root; cd /usr/doc &prompt.root; make install clean Ha a make.conf állományban korábban már megadtuk a DOCSUPFILE, SUPHOST és SUP_UPDATE változók értékeit, akkor a telepítés fázisa könnyedén össze is vonatható a források frissítésével: &prompt.root; cd /usr/doc &prompt.root; make update install clean Ha pedig csak bizonyos nyelvekhez tartozó dokumentációt szeretnénk frissíteni, akkor a &man.make.1; akár a /usr/doc könyvtáron belül az egyes nyelvekhez tartozó alkönyvtárakon belül is meghívható, például: &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make update install clean A dokumentáció formátumát a FORMATS változó felhasználásával tudjuk meghatározni: &prompt.root; cd /usr/doc &prompt.root; make FORMATS='html html-split' install clean Marc Fonvieille A szóbanforgó megoldást fejlesztette: A dokumentációs portok használata frissítés és frissen tartás dokumentáció frissítés és frissen tartás Ez elõzõ szakaszban megmutattuk hogyan lehet a &os; dokumentációját a források felhasználásával frissíteni. A források használatával végzett frissítés azonban nem minden &os; rendszer esetében lehetséges vagy hatékony. Ha ugyanis a dokumentációs forrásból akarjuk elõállítani, viszonylag sok eszköz és segédprogram, az ún. dokumentációs eszközök használatával kell tisztában lennünk, valamint bizonyos mértékig ismernünk kell a CVS használatát, tudunk kell kikérni a legfrissebb változatot és elõállítatattnunk belõle a végleges változatot. Ezért ebben a szakaszban most szót ejtünk egy olyan módszerrõl, ahol a &os; dokumentációját a Portgyûjteményen keresztül tudjuk frissíteni, ezáltal: anélkül le tudjuk tölteni és telepíteni a dokumentáció adott pillanatban generált változatát, hogy a rendszerünkön bármi további teendõre szükség lenne (ennek köszönhetõen nem kell telepítenünk a dokumentációs eszközöket); letölthetjük a dokumentáció forrását és a Portgyûjtemény eszközeivel elõállíthatjuk belõle a megfelelõ változatot (ez a források beszerzésében és feldolgozásában segít valamelyest). A &os; dokumentáció frissítésének fentebb említett módjait támogatják tehát a dokumentációs portok, amelyeket a &a.doceng; havi rendszerességgel tart karban. Ezek a portok a &os; Portgyûjteményén belül a docs nevû virtuális kategóriában találhatóak meg. A dokumentációs portok fordítása és telepítése A dokumentáció könnyebb elõállításához a dokumentációs portok a Portgyûjtemény lehetõségeit veszik igénybe. Segítségükkel automatikussá teszik a dokumentáció forrásának letöltését, a &man.make.1; parancs meghívását a megfelelõ környezetben, beállításokkal és parancssori paraméterekkel. Rajtuk keresztül a dokumentáció eltávolítása ugyanolyan egyszerûen megtehetõ, mint akármelyik másik &os; port vagy csomag esetében. Továbbá, amikor a dokumentációs portokat a saját rendszerünkön fordítjuk, a dokumentációs eszközök függõségként automatikusan települni fognak. A dokumentációs portok a következõ módon szervezõdnek: Létezik egy ún. fõport, a misc/freebsd-doc-en, ahol az összes fontosabb állomány megtalálható. Ez lényegében a dokumentációs portok közös õse. Alapértelmezés szerint kizárólag csak az angol nyelvû dokumentációt állítja elõ. Létezik egy mindenes port, a misc/freebsd-doc-all, amely az összes elérhetõ nyelven és formátumban elõállítja a dokumentációt. Végezetül minden nyelvhez létezik egy-egy alport, ilyen például a magyar dokumentáció esetén a misc/freebsd-doc-hu port. Mindegyikük a fõporttól függ és az adott nyelvû dokumentációt telepítik. Az eddigi összefoglaltaknak megfelelõen a dokumentációs portokat forrásból a következõ paranccsal lehet telepíteni (root felhasználóként): &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean Ennek hatására elõáll és telepítõdik a /usr/local/share/doc/freebsd könyvtárba az angol nyelvû dokumentáció állományokra bontott HTML formátumban (hasonlóan a tartalmához). Gyakori beállítások A dokumentációs portok alapértelmezett viselkedése több különbözõ opció segítségével is befolyásolható. Ezek közül most összefoglalunk néhányat: WITH_HTML Minden dokumentum egyetlen HTML állományba kerüljön. A végeredmény ekkor az adott dokumentum típusának megfelelõen article.html (cikk) vagy book.html (könyv) néven keletkezik (képekkel együtt). WITH_PDF Minden dokumentum &adobe; Portable Document Format típusú állományban jön létre. Ezek az állományok a Ghostscript vagy más egyéb PDF nézegetõkkel nyithatóak meg. Ekkor a dokumentáció konkrét típusától függõen az állományok article.pdf (cikk) vagy book.pdf (könyv) néven állítódnak elõ. DOCBASE A dokumentáció telepítésének helye. Alapértelmezés szerint ez a /usr/local/share/doc/freebsd könyvtár. Ügyeljünk arra, hogy a telepítés alapértelmezett célkönyvtára eltér a CVSup módszerétõl. Ugyanis mivel ilyenkor egy portot telepítünk, a tartalma alapértelmezés szerint a /usr/local könyvtáron belülre kerül. Ez azonban a PREFIX változó átállításával tetszõleges megváltoztatható. Az elõbbieket most egy rövid példán keresztül összefoglaljuk. A következõ paranccsal tudjuk tehát a magyar nyelvû dokumentáció Portable Document Format változatát telepíteni: &prompt.root; cd /usr/ports/misc/freebsd-doc-hu &prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean A dokumentációs csomagok használata A dokumentációs portok elõzõ szakaszban bemutatott forrásból telepítésével kapcsolatban már említettük, hogy szükséges hozzá a dokumentációs eszközök telepítése, valamint némi szabad tárterület. Ha a dokumentációs eszközök telepítéséhez nem elengedõek a rendelkezésre álló erõforrásaink vagy a források feldolgozása túlságosan sokat foglalna a rendszerünkön, akkor lehetõségünk van a dokumentációs portok elõre lefordított, csomagolt változatát használni. A &a.doceng; minden hónapban elõkészíti a &os; dokumentációs csomagok legfrissebb változatát. Az így karbantartott bináris csomagok azután tetszõlegesen használhatóak a szabványos csomagkezelõ eszközökkel, mint amilyen például a &man.pkg.add.1;, &man.pkg.delete.1; és így tovább. A bináris csomagok használata esetén a &os; dokumentációja az adott nyelvhez az összes elérhetõ formátumban telepítésre kerül. Például az alábbi paranccsal a magyar nyelvû dokumentációhoz tartozó legfrissebb bináris csomagot tudjuk telepíteni: &prompt.root; pkg_add -r hu-freebsd-doc A csomagok elnevezése eltér a hozzátartozó port nevétõl. Alakja a következõ: nyelv-freebsd-doc, ahol a nyelv az adott nyelv rövid kódja, vagyis a magyar esetén a hu, illetve az egyszerûsített kínai esetén a zh_ch. A dokumentációs portok frissítése Az elõzetesen telepített dokumentációs portok bármilyen portok frissítésére alkalmas eszközzel frissíthetõek. Például a telepített magyar nyelvû dokumentáció a ports-mgmt/portupgrade eszközön keresztül így frissíthetõ csomagok használatával: &prompt.root; portupgrade -PP hu-freebsd-doc Pav Lucistnik A szükséges információkat szolgáltatta: A Docsnap használata frissítés és frissen tartás Docsnap frissítés és frissen tartás A Docsnap a &os; dokumentációjának egy viszonylag gyors és könnyû frissítésére alkalmas &man.rsync.1; repository. Az ún. Docsnap szerver folyamatosan követi a dokumentáció forrásainak változásait, majd minden órában elõállítja a HTML változatukat. A Docsnap használatakor nincs szükségünk a textproc/docproj port telepítésére, mivel mindig csak a már elõállított dokumentációt frissítjük. A módszer használatához mindössze a net/rsync port vagy csomag telepítése szükségeltetik. Ezt a következõ paranccsal tudjuk elvégezni: &prompt.root; pkg_add -r rsync A Docsnap módszerét eredetileg a /usr/share/doc könyvtárban tárolt dokumentáció frissítésére fejlesztették ki, de a bemutatott példák tetszõleges könyvtárra alkalmazhatóak. Felhasználói könyvtárak esetén még rendszergazdai jogosultságokra sincs szükségünk a feladat elvégzéséhez. A dokumentáció így az alábbi paranccsal frissíthetõ: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap /usr/share/doc Jelenleg csak egyetlen Docsnap szerver érhetõ el, ez a fentebb is látható docsnap.sk.FreeBSD.org. Közvetlenül ne használjuk a paramétert, mert a make installworld parancs futása közben olyan elemeket is telepíthetett a /usr/share/doc könyvtárba, amelyek így törlõdnének. Helyette inkább így használjuk a parancsot: &prompt.root; rsync -rltvz --delete docsnap.sk.FreeBSD.org::docsnap/??_??\.\* /usr/share/doc Ha csak a dokumentáció egy részét akarjuk frissíteni, például csak az angol nyelvû változatát, akkor pedig ezt a parancsot használjuk: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap/en_US.ISO8859-1 /usr/share/doc ]]> A fejlesztõi ág követése -CURRENT -STABLE A &os;-nek két fejlesztési ága van: a &os;.current és a &os.stable;. Ebben a szakaszban mindegyikükrõl monduk pár szót, és megmutatjuk, miként lehet az adott ághoz igazítani a rendszerünk frissítését. Elõször a &os.current;, majd a &os.stable; változata kerül tárgyalásra. A &os; friss változatának használata Ahogy arról már az imént is szó esett, nem szabad elfelejtenünk, hogy a &os.current; a &os; fejlesztésének frontvonala. Emiatt a &os.current; használóinak szakmailag jólképzetteknek kell lenniük, és sosem szabad visszariadniuk a használat közben felmerülõ rendszerszintû problémák önálló megoldásától. Ha korábban még nem foglalkoztunk &os;-vel, kétszer is gondoljuk meg a telepítését! Mi a &os.current;? pillanatkép A &os.current; a &os; mögött álló legfrissebb forráskódot képviseli. Itt találkozhatunk különféle olyan fejlesztés alatt álló részekkel, kísérletezésekkel és átmeneti megoldásokkal, amelyek nem feltétlenül kerülnek bele a szoftver következõ hivatalos kiadásába. Noha a &os; fejlesztõi a &os.current; forráskódját naponta fordítják, adódhatnak olyan idõszakok, amikor a források mégsem használhatóak maradéktalanul. Az ilyen gondokat általában a lehetõ leggyorsabban igyekeznek megoldani, azonban attól függõen, hogy éppen a forráskód melyik verzióját sikerült kifogni, a &os.current; használata kész katasztrófa vagy akár a fejlõdésben igazi továbblépés is lehet. Kinek van szüksége a &os.current;-re? A &os.current; használata elsõsorban az alábbi 3 csoportot érinti: A &os; közösség azon tagjait, akik aktívan dolgoznak a forrásfa valamelyik részén, és mindazokat, akik számára a legfrissebb verzió használata feltétlen elvárás. A &os; közösség azon tagjait, akik aktívan tesztelnek, és a &os.current; kordában tartásához hajlandóak idõt áldozni a menet közben felbukkanó problémák megoldására. Vannak olyanok is, akik a &os; változásaival és fejlesztési irányával kapcsolatban kívánnak javaslatokat tenni, melyeket javítások és módosítások formájában tesznek közzé. Mindazokat, akik pusztán kíváncsiak a fejlesztésben zajló eseményekre, vagy hivatkozási szándékkal töltik le a legfrissebb forrásokat (például csak nézegetik, de nem futtatják). Az ilyen emberek esetenként megjegyzéseket fûznek a fejlesztéshez vagy kódot küldenek be. Mi <emphasis>nem</emphasis> a &os.current;? Az olyan kiadás elõtt álló funkciók kipróbálásának egyszerû módja, amelyekrõl hallottunk, hogy milyen remek újdonságokat hoznak és mi akarunk lenni az elsõk, akik ezt használni is fogják. Ne feledjük azonban, hogy amikor mindenki elõtt kezdünk el használni egy újítást, mi leszünk egyben az elsõk is, akik szembesülnek a benne rejlõ hibákkal. A gyors hibajavítások eszköze. A &os.current; szinte bármelyik változata pontosan ugyanakkora valószínûséggel hoz magával új hibákat, mint ahogy eltünteti a régieket. Akármilyen értelemben is hivatalosan támogatott. Képességeinktõl függõen õszintén igyekszünk a lehetõ legtöbbet megtenni a 3 törvényes &os.current; csoportba tartozó emberekért, azonban egyszerûen nincs idõnk komolyabb segítségnyújtást adni. Ez viszont nem azt jelenti, hogy komisz és fukar emberek vagyunk, akik utálnak segíteni a másiknak (de máskülönben nem tudna fejlõdni a &os;). Csupán a &os; fejlesztése közben fizikailag képtelenek vagyunk a naponta érkezõ ezernyi üzenetet rendre megválaszolni! A &os; elõremozdítása és a kísérleti stádiumban álló kóddal kapcsolatos kérdések megválaszolása közül a fejlesztõk általában az elsõt részesítik elõnyben. A &os.current; használata -CURRENT használata Iratkozzunk fel az &a.current.name; és &a.svn-src-head.name; listákra. Ez nem egyszerûen hasznos, hanem elengedhetetlen. Ha nem vagyunk a &a.current.name; listán, akkor nem fogjuk látni a rendszer aktuális állapotára vonatkozó megjegyzéseket, és így esetleg feleslegesen öljük az idõnket olyan problémák megoldásába, amelyeket mások már korábban megoldottak. Ami viszont ennél is fontosabb, hogy így elszalasztjuk a rendszerünk folyamatos életbentartására vonatkozó létfontosságú bejelentéseket. Az &a.svn-src-head.name; listán láthatjuk az a forráskód egyes változtatásaihoz tartozó naplóbejegyzéseket, a hozzájuk tartozó esetleges mellékhatások ismertetésével együtt. A listákra vagy a &a.mailman.lists.link; oldalon található többi lista valamelyikére úgy tudunk feliratkozni, ha rákattintunk a nevére. A további lépésekrõl ezt követõen itt kapunk értesítést. Amennyiben a teljes forrásfa változásai érdekelnek minket, javasoljuk az &a.svn-src-all.name; lista olvasását. A tükrözések egyikérõl töltsük le a &os; forrását. Erre két mód is kínálkozik: cvsup cron -CURRENT frissítés CVSuppal Használjuk a cvsup programot a /usr/share/examples/cvsup könyvtárban található standard-supfile állománnyal. Ez a leginkább ajánlott módszer, hiszen így csak egyszer kell letölteni az egész gyûjteményt, majd ezután már csak a változásokat. Sokan a cvsup parancsot a cron parancson keresztül adják ki, és ezzel mindig automatikusan frissítik a forrásaikat. A cvsup mûködését a fentebb említett minta supfile állomány megfelelõ módosításával tudjuk a saját környezetünkhöz igazítani. Az említett standard-supfile állomány eredetileg nem a &os.current;, hanem inkább a &os; biztonsági problémáit érintõ javítások követésére használatos. A &os.current; forrásainak eléréséhez a következõ sort kell kicserélnünk ebben az állományban: *default release=cvs tag=RELENG_X_Y Erre: *default release=cvs tag=. A tag paramétereként megadható egyéb címkékrõl a kézikönyv CVS címkék szakaszában olvashatunk. -CURRENT frissítés CTM-mel Használjuk a CTM alkalmazás nyújtotta lehetõségeket. Amennyiben nagyon rossz netkapcsolattal rendelkezünk (drága vagy csak levelezésre használható) a CTM megoldást jelenthet számunkra. Legyünk azonban tekintettel arra, hogy helyenként zûrös lehet a használata és néha hibás állományokat gyárt. Emiatt viszont csak ritkán használják, így elõfordulhat, hogy hosszabb ideig nem is mûködik. A 9600 bps vagy annál nagyobb sebességû kapcsolatok esetén ezért inkább a CVSup használatát javasoljuk. Ha nem csak böngészésre, hanem fordításra is szedjük a forrásokat, mindig töltsük le a &os.current; egészét, ne csak egyes részeit. Ez azzal magyarázandó, hogy a forráskód bizonyos részei más helyeken található részektõl is függenek, és ezért az önálló fordításuk szinte garantáltan gondot fog okozni. -CURRENT fordítása A &os.current; lefordítása elõtt figyelmesen olvassuk át a /usr/src könyvtárban található Makefile állományt. A frissítési folyamat részeként elõször mindenképpen érdemes telepíteni egy új rendszermagot és újrafordítani az alaprendszert. Olvassuk el a &a.current; üzeneteit és a /usr/src/UPDATING állományt, ahol megtalálhatjuk az ezzel kapcsolatos legújabb információkat, melyek egy-egy újabb kiadás közeledtével egyre fontosabbá válnak. Foglalkozzunk vele! Ha már a &os.current; változatát használjuk, ne legyünk restek véleményt formálni róla, különösen abban az esetben, ha továbbfejlesztésekrõl vagy hibákra van szó. Leginkább a forráskóddal együtt érkezõ javaslatoknak szoktak örülni a fejlesztõk! A &os; stabil változatának használata Mi a &os.stable;? -STABLE A &os.stable; az a fejlesztési ág, ahonnan az egyes kiadások származnak. Ebbe az ágba már más ütemben kerülnek a változások, mivel általánosan elfogadott, hogy ide a korábban már kipróbált módosítások vándorolnak át a &os.current; ágból. Ez azonban még mindig csak egy fejlesztési ág, ami arra utal, hogy a &os.stable; által adott pillanatban képviselt források nem feltétlenül felelnek meg bizonyos célokra. Ez csupán egy újabb fejlesztési nyomvonal, nem pedig a végfelhasználók kenyere. Kinek van szüksége a &os.stable;-re? Ha szeretnénk figyelemmel kísérni vagy valamilyen módon kiegészíteni a &os; fejlesztési folyamatát, különösen a &os; következõ nagyobb kiadását illetõen, akkor érdemes követnünk a &os.stable; forrásait. Habár a &os.stable; ágba is bekerülnek a biztonsági jellegû javítások, ettõl még nem kell feltétlenül ezt követnünk. A &os;-hez kiadott biztonsági figyelmeztetések mindig leírják, hogyan kell javítani a hibát az érintett kiadásokban Ez azért nem teljesen igaz. A régebbi &os; kiadásokat ugyan nem támogathatjuk a végtelenségig, de általában így is több évig foglalkozunk velük. A &os; régebbi kiadásaival kapcsolatos jelenleg érvényes biztonsági házirend részletes bemutatása a http://www.FreeBSD.org/security/ oldalon olvasható (angolul). , azonban az egész fejlesztési ágat felesleges csak biztonsági okból kifolyólag követni, mivel így olyan változások is kerülhetnek a rendszerbe, amire nincs szükségünk. Habár igyekszünk gondoskodni a &os.stable; ágban található források lefordíthatóságáról és mûködõképességérõl, nem minden esetben szavatolható. Ráadásul mivel a &os.stable; ágba kerülõ kódokat elõször a &os.current; ágban fejlesztik ki, és mivel a &os.stable; felhasználói többen vannak a &os.current; változaténál, ezért szinte elkerülhetetlen, hogy ilyenkor a &os.stable; változatban bizonyos hibák és szélsõséges esetek be ne következzenek, amelyek a &os.current; használata során még nem buktak ki. Ezért a &os.stable; ág vakon követését senkinek sem ajánljuk, és különösen fontos, hogy éles szervereken elõzetes kimerítõ tesztelések nélkül ne futassunk &os.stable; rendszert. Ha ehhez nem rendelkezünk elegendõ erõforrással, akkor egyszerûen használjuk a &os; legfrissebb kiadását, és az egyes kiadások között pedig bináris frissítéssel közlekedjünk. A &os.stable; használata -STABLE használata Iratkozzunk fel a &a.stable.name; listára. Ezen keresztül értesülhetünk a &os.stable; használata során felmerülõ fordítási függõségekrõl vagy más, külön figyelmet igénylõ problémákról. Gyakran ezen a levelezési listán elmélkednek a fejlesztõk a vitatott javításokról vagy frissítésekrõl, amibe a felhasználók is beleszólhatnak, ha a szóbanforgó változtatással kapcsolatban bármilyen problémájuk vagy ötletünk van. Iratkozzunk fel a követni kívánt ághoz tartozó SVN levelezési listára. Például ha a 7-STABLE ág változásait követjük, akkor az &a.svn-src-stable-7.name; listára érdemes feliratkoznunk. Ennek segítségével elolvashatjuk az egyes változtatásokhoz tartozó naplóbejegyzéseket, a rájuk vonatkozó esetleges mellékhatások ismertetésével együtt. Ezekre, valamint a &a.mailman.lists.link; címen elérhetõ listák valamelyikére úgy tudunk feliratkozni, ha a nevükre kattintunk. A további teendõk ezután itt jelennek meg. Amennyiben egy új rendszert akarunk telepíteni és a &os.stable; havonta készült pillanatképeit akarjuk rajta futtatni, akkor errõl bõvebb felvilágosítást a Pillanatképek honlapján találhatunk (angolul). Emellett a legfrissebb &os.stable; kiadást telepíthetjük a tükrözések valamelyikérõl is, majd innen a lentebb található utasítások szerint tudunk hozzáférni a &os.stable; forráskódjának legfrissebb változatához. Ha már fut a gépünkön a &os; egy korábbi kiadása, és ezt akarjuk forráson keresztül frissíteni, akkor ezt a &os; tükrözéseivel könnyedén megtehetjük. Két módon is: cvsup cron -STABLE frissítés CVSuppal Használjuk a cvsup programot a /usr/share/examples/cvsup könyvtárból származó stable-supfile állománnyal. Ez a leginkább ajánlott módszer, mivel így csak egyszer kell letölteni a teljes gyûjteményt, utána már csak a hozzátartozó változtatásokra van szükségünk. A cvsup parancsot sokan a cron segítségével futtatják, és ezzel automatikusan frissülnek a forrásainak. A cvsup mûködését környezetünkhöz az elõbb említett minta supfile megfelelõ módosításával tudjuk behangolni. -STABLE frissítés CTM-mel Használjuk a CTM programot. Ha nincs olcsó vagy gyors internetkapcsolatunk, akkor érdemes ezt a módszert választani. Alapvetõen azonban ha gyorsan szeretnénk hozzájutni a forrásokhoz és a sávszélesség nem meghatározó tényezõ, akkor helyette válasszuk a cvsup vagy az ftp használatát, és csak minden más esetben CTM-et. -STABLE fordítása Mielõtt lefordítanánk a &os.stable; változatát, figyelmesen olvassuk át a /usr/src könyvtárban levõ Makefile állományt. Az átállási folyamat részeként elõször minden bizonnyal telepítenünk kell egy új rendszermagot és újra kell fordítanunk az alaprendszert. A &a.stable; valamint a /usr/src/UPDATING elolvasásából értesülhetünk azokról az egyéb, gyakran nagyon fontos változásokról, melyek elengedhetetlenek lesznek a következõ kiadás használatához. A forrás szinkronizálása Az internet (vagy elektronikus levelek) használatán keresztül számos mód kínálkozik az &os; Projekthez tartozó források frissen tartásához egy adott, vagy éppen az összes területen attól függõen, hogy mik érdekelnek minket. Ehhez elsõsorban az Anonim CVS, CVSup és CTM szolgáltatásokat ajánljuk fel. Habár lehetséges csupán a forrásfa egyes részeit letölteni, a támogatott frissítési eljárás során azonban szükségünk lesz az egész fa szinkronizálására és a rendszerhez tartozó felhasználói programok (vagyis minden olyan program, amely a felhasználói térben fut, ilyeneket találhatunk többek közt a /bin és /sbin könyvtárakban) valamint rendszermag újrafordítására is. Ha csak a felhasználói programok forrásait, vagy csak a rendszermagot, esetleg csupán a forrásfa egyes részeit frissítjük, akkor az gondokat okozhat. Az itt elõforduló problémák fordítási hibáktól kezdve rendszerösszeomlásokon keresztül akár adatvesztésbe is torkollhatnak. CVS anonim Az Anonim CVS és a CVSup alkalmazások ún. lehúzással frissítik a forrásokat. A CVSup használatakor a felhasználó (vagy a cron szkript) meghívja a cvsup programot, amely az állományok aktualizálásához felveszi a kapcsolatot egy máshol megtalálható cvsupd szerverrel. Az így nyert frissítések az adott pillanatig visszemenõleg érkeznek meg, de csak akkor, ha igényeljük ezeket. A frissítést könnyedén le tudjuk szabályozni a számunkra érdekes egyes állományokra és könyvtárakra. A frissítéseket a szerver hozza létre menet közben annak megfelelõen, hogy milyen verziókkal rendelkezünk, és mihez akarunk szinkronizálni. Az Anonim CVS a CVSupnál valamivel egyszerûbb abban a tekintetben, hogy ez a CVS-nek egy olyan kiterjesztése, amely lehetõvé teszi a változtatások közvetlen lehúzását egy távoli CVS tárházból. Miközben a CVSup mindezt sokkal hatékonnyabb valósítja meg, addig az Anonim CVS jóval könnyebben használható. CTM Velük szemben a CTM nem hasonlítja össze interaktívan a saját és a központi szerveren tárolt forrásokat és nem is húzza át ezeket. Ehelyett egy olyan szkriptõl van szó, amely naponta többször megvizsgálja a központi CTM szerveren tárolt állományok a legutóbbi futtatás óta keletkezett változtatásait, majd az észlelt módosulásokat betömöríti, felcímkézi egy sorozatszámmal és (nyomtatható ASCII formátumban) elõkészíti ezeket az e-mailen keresztüli küldésre. Az így létrehozott CTM delták megérkezésük után a &man.ctm.rmail.1; segédprogrammal kerülnek feldolgozásra, amely magától visszaalakítja, ellenõrzi és alkalmazza a változtatásokat a forrásfa felhasználó birtokában levõ másolatára. Ez a megoldás hatékonyabb a CVSup használatánál, mert kisebb terhelést jelent a szerverek számára, hiszen a frissítéshez nem a lehúzást, hanem a küldést alkalmazzák. Természetesen minden említett eljárásnak megvannak a maga kompromisszumai. Ha véletlenül kitöröljük a forrásfánk egyes részeit, a CVSup képes ezt észrevenni és helyreállítani a sérült részeket. A CTM ezzel szemben ezt nem végzi el, szóval ha (biztonsági mentés nélkül) letöröljük a forrásainkat, akkor az egész szinkronizálást az elejérõl kell kezdenünk (pontosabban a legfrissebb CVS-es alapdeltától) és a CTM-mel újraépíteni az egészet, esetleg a Anonim CVS-sel letörölni a hibás adatokat és újraszinkronizálni. Az alaprendszer újrafordítása az alaprendszer újrafordítása Miután sikerült a helyi forrásfánkat a &os; egy nekünk szimpatikus (&os.stable;, &os.current; és így tovább) változatához igazítanunk, elérkezett az idõ, hogy a segítségével újrafordítsuk az egész rendszert. Készítsünk biztonsági mentést Nem tudjuk eléggé nyomatékosítani, hogy mielõtt nekikezdenénk, készítsünk egy biztonsági mentést a rendszerünkrõl. Míg az alaprendszer újrafordítása nem túlságosan bonyolult feladat (egészen addig, amíg a megadott utasításokat követjük), saját magunk vagy mások hibájából fakadóan kialakulhatnak olyan helyzetek, amikor a rendszer nem lesz képes elindulni. Mindenképpen gyõzödjünk meg róla, hogy tisztességesen elvégeztük a mentést és akad a kezünk ügyében egy javításra felhasználható rendszerindító floppy vagy CD. Valószínûleg soha nem lesz ténylegesen szükségünk rájuk, azonban jobb félni, mint megijedni! Iratkozzunk fel a megfelelõ levelezési listákra levelezési lista A &os.stable; és &os.current; ágak természetüknél fogva fejlesztés alatt állnak. A &os; fejlesztését is emberek végzik, ezért elõfordulhatnak benne tévedések. Ezek a tévedések gyakran csak ártalmatlan apróságok, amelyek hatására kapunk például egy ismeretlen diagnosztikai hibát. De ezzel szemben létrejöhetnek pusztító erejû hibák is, amelyek hatására a rendszerünk nem lesz képes elindulni, károsodnak az állományrendszerek (vagy még rosszabb). Ha ilyen történik, akkor egy felszólítást (egy heads up témájú üzenetet) küldenek az érintett változatokhoz tartozó listákra, amelyben igyekeznek kifejteni a probléma természetét és a rendszerre mért hatását. Miután minden rendbejött, a probléma megoldásáról is küldenek egy értesítést. Ha a &a.stable; vagy a &a.current; olvasása nélkül próbáljuk meg használni a &os.stable; és &os.current; verziókat, akkor csak magunknak keressük a bajt. Ne használjuk a <command>make world</command> parancsot Rengeteg régebben készült dokumentáció erre a feladatra a make world parancs kiadását javasolja. Ennek használatával azonban átlépünk olyan fontos lépéseket, amelyek valójában csak akkor lennének kihagyhatóak, ha pontosan tudjuk mit csinálunk. Ezért az esetek döntõ többségében nem a make world használatára van szükségünk, hanem a most bemutatandó eljárásra. A rendszer frissítése dióhéjban A frissítés megkezdése elõtt érdemes elolvasnunk a /usr/src/UPDATING állományt, ahol a letöltött források használatához elvégzendõ elõzetes intézkedésekrõl kaphatunk hírt. Ezután kövessük az alábbiakban körvonalazott módszer egyes lépéseit. Ezek a lépések feltételezik, hogy egy korábbi &os; verziót használunk, tehát a fordító, a rendszermag, az alaprendszer és a konfigurációs állományok valamelyik régebbi változatát. Alaprendszer alatt, amelyet sokszor csak a world néven hivatkozunk, a rendszer számára alapvetõ fontosságú binárisokat, programkönyvtárakat és programfejlesztéshez szükséges egyéb állományokat értjük. Maga a fordítóprogram is része ennek, azonban tartalmaz néhány speciális megszorítást. Mindezek mellett továbbá feltételezzük, hogy elõzetesen már valamilyen módon letöltöttük a friss forrásokat. Ha rendszerünkön ezt még nem tettük volna meg, akkor a segítségével tájékozódhatunk részletesen arról, hogyan tölthetjük le a legfrissebb verziót. A rendszer forráskódon keresztüli frissítése egy kicsivel körülményesebb, mint amennyire elsõre látszik. A &os; fejlesztõk az évek során fontosnak találták, hogy a folyamatosan felszínre bukkanó, elkerülhetetlen függõségek tükrében meglehetõsen drámai módon megváltoztassák az erre javasolt módszert. Ezért a szakasz további részében a pillanatnyilag javasolt frissítési megoldás nyomán fogunk haladni. A sikeres frissítések során az alábbi akadályokkal kell mindenképpen szembenéznünk: A fordító régebbi változata nem feltétlenül lesz képes lefordítani az új rendszermagot. (Illetve a régebbi fordítóprogramok tartalmazhatnak hibákat.) Ezért az új rendszermagot már a fordító új változatával kell elõállítanunk. Ebbõl következik, hogy az új rendszermag elkészítéséhez elõször a fordítóprogram újabb változatát kell lefordítanunk. Ez viszont nem feltétlenül jelenti azt, hogy az új rendszermag fordítása elõtt az új fordítóprogramot telepítenünk is kellene. Az új alaprendszer esetenként bizonyos új funkciókat igényelhet a rendszermagtól. Ezért a frissebb alaprendszer telepítése elõtt telepítenünk kell a frissebb rendszermagot. Ez az elõbb említett két akadály képzi az okát a következõ bekezdésekben bemutatott buildworld, buildkernel, installkernel, installworld sorozatnak. Természetesen léteznek további egyéb indokok is, amiért még érdemes az itt leírtak szerint frissíteni a rendszerünket. Ezek közül most vegyünk néhány kevésbé nyilvánvalóbbat: A régebbi alaprendszer nem minden esetben fog problémamentesen együttmûködni az új rendszermaggal, ezért az alaprendszer újabb változatát szinte azonnal az új rendszermagot követõen kell telepítenünk. Vannak olyan konfigurációs változtatások, amelyeket még az új alaprendszer telepítése elõtt el kell végeznünk, a többi viszont veszélyes lehet a korábbi alaprendszerre. Ezért a konfigurációs állományokat általában két külön lépésben kell frissíteni. A frissítés során nagyrészt csak állományok cserélõdnek el és újabbak érkeznek, a korábbiak nem törlõdnek. Ez bizonyos esetekben azonban gondokat okozhat. Ennek eredményeképpen a frissítés során idõnként elõfordulhat, hogy magunknak kell manuálisan némely megadott állományokat törölnünk. Elképzelhetõ, hogy ezt a jövõben még majd automatizálni fogják. Ezek a megfontolások vezettek tehát az ismertetendõ eljárás kialakításához. Ettõl függetlenül adódhatnak olyan helyzetek, amikor további lépéseket is be kell iktatnunk, viszont az itt bemutatott folyamat egy ideje már viszonylag elfogadottnak tekinthetõ: make buildworld Elõször lefordítja az új fordítóprogramot és néhány hozzátartozó eszközt, majd ennek felhasználásával elkészíti az alaprendszer többi részét. Az eredmény a /usr/obj könyvtárban keletkezik. make buildkernel Eltérõen a &man.config.8; és &man.make.1; programok korábban javasolt alkalmazásától, ezzel a paranccsal már a /usr/obj könyvtárban létrehozott új fordítót használjuk. Ez védelmet nyújt a fordító és rendszermag változatai közti eltérésekbõl fakadó problémák ellen. make installkernel Telepíti a lemezre az új rendszermagot és a hozzátartozó modulokat, ezáltal lehetõvé válik a frissített rendszermag betöltése. Átváltás egyfelhasználós módba. Egyfelhasználós módban a minimálisra csökkenthetjük a futó szoftverek frissítésébõl adódó bonyodalmakat. Ezzel együtt minimálissá válik a régi alaprendszer és az új rendszermag eltéréseibõl eredõ problémák elõfordulása is. mergemaster -p Az új alaprendszer telepítéséhez elvégzi a konfigurációs állományok részérõl szükséges frissítéseket. Például felvesz még nem létezõ csoportokat vagy felhasználókat. Ez gyakran elengedhetetlennek bizonyulhat, mivel ha a rendszer legutóbbi frissítése óta újabb csoportok vagy felhasználók kerültek be az alaprendszerbe, a installworld csak akkor tud hibamentesen lefutni, ha ezek már a futásakor is elérhetõek. make installworld Átmásolja a /usr/obj könyvtárból a korábban elkészített új alaprendszert. Lefutása után már mind az új rendszermag és az új alaprendszer a megfelelõ helyén található. mergemaster Feldolgozzuk a korábbi fázisból fennmaradó konfigurációs állományok frissítését, mivel most már elérhetõ az új alaprendszer. A rendszer újraindítása. Az új rendszermag és az új konfigurációs állományokkal futó alaprendszer használatához teljesen újra kell indítanunk a számítógépünket. Ha a &os; ugyanazon fejlesztési ágán belül frissítjük a rendszerünket, például a 7.0 kiadásról a 7.1 kiadásra, akkor értelemszerûen nem kell az iménti eljárás minden lépését szorosan követni, hiszen nagyon valószínûtlen, hogy komoly eltérések lennének a fordítóprogram, a rendszermag, az alaprendszer és a konfigurációs állományok között. Ilyenkor akár nyugodtan kiadhatjuk a make world parancsot, majd kérhetjük a rendszermag fordítását és telepítését. A fejlesztési ágak közti váltás során azonban könnyen érhetnek minket meglepetések, ha nem a megadottak szerint járunk el. Egyes váltásokhoz (például 4.X és 5.0 között) további lépések megtétele is szükséges lehet (például adott állományok törlése vagy átnevezése még az installworld elõtt). Ilyenkor mindig figyelmesen olvassuk át a /usr/src/UPDATING állományt, különös tekintettel a végére, mivel gyakran ott adják meg a konkrét verzióváltáshoz szükséges teendõket. A szakaszban összefoglalt lépések egyfajta evolúciós folyamat eredményei, melynek során a fejlesztõk felismerték, hogy nem tökéletesen kivédeni az összes frissítéssel járó problémát. A javasolt eljárás remélhetõleg viszont még sokáig érvényes marad. A &os; 3.X vagy annál is korábbi változatok frissítése még ennél is több ügyességet kíván. Ha ilyen verziót akarunk frissíteni, akkor feltétlenül olvassuk el az UPDATING állományt! Röviden tehát a &os; forráskódon keresztüli frissítését így foglalhatjuk össze: &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; shutdown -r now Néhány ritka esetben a buildworld lépés elõtt szükségünk lehet a mergemaster -p parancs lefuttatására is. Errõl az UPDATING állományból tudakozódhatunk. Általában azonban nyugodt szívvel kihagyhatjuk ezt a lépést, kivéve, ha nem egy vagy több fõbb &os; változatot átívelõ frissítést végzünk. Miután az installkernel sikeresen befejezte a munkáját, indítsuk újra a számítógépet egyfelhasználós módban (a betöltõ parancssorában adjuk ki boot -s parancsot). Itt futtassuk a következõket: &prompt.root; adjkerntz -i &prompt.root; mount -a -t ufs &prompt.root; mergemaster -p &prompt.root; cd /usr/src &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot Olvassuk el a magyarázatokat Az iménti leírt folyamat csupán rövid összefoglalás, amivel némi gyorstalpalást igyekeztünk adni. Az egyes lépések megértéséhez azonban javasolt átolvasni a most következõ szakaszokat is, különösen abban az esetben, ha saját rendszermagot akarunk használni. Nézzük meg a <filename>/usr/src/UPDATING</filename> állományt Mielõtt bármihez is nekifognánk, keressük meg a /usr/src/UPDATING (vagy hasonló, a forráskód másolatunk tényleges helyétõl függõ) állományt. Ebben adják hírül az esetlegesen felmerülõ problémákra vonatkozó fontosabb információkat, vagy határozzák meg az egyes lefuttatandó parancsok pontos sorrendjét. Amennyiben az UPDATING ellentmondana az itt olvasottaknak, az UPDATING tartalma a mérvadó. A korábban tárgyaltak szerint az UPDATING elolvasása nem helyettesíti a megfelelõ levelezési listák figyelemmel kísérését. Ez a két elvárás nem kizárja, hanem kiegészíti egymást. Ellenõrizzük az <filename>/etc/make.conf</filename> állományt make.conf Vizsgáljuk át a /usr/share/examples/etc/make.conf és az /etc/make.conf állományokat. Az elõbbi tartalmaz néhány alapértelmezett beállítást – ezek javarészét megjegyzésbe rakták. Ha használni akarjuk a rendszer lefordítása során, tegyük bele ezeket az /etc/make.conf állományba. Ne felejtsük el azonban, hogy minden, amit megadunk az /etc/make.conf állományba, a make minden egyes elindításakor felhasználásra kerül. Éppen ezért olyanokat érdemes itt beállítani, amik az egész rendszerünket érintik. A legtöbb felhasználó számára az /etc/make.conf állományhoz a /usr/share/examples/etc/make.conf állományban található CFLAGS és NO_PROFILE sorokra lesz szüksége, melyeket kivehetünk a megjegyzésbõl. A többi definíció (COPTFLAGS, NOPORTDOCS és így tovább) használatáról már mindenki maga dönt. Frissítsük az <filename>/etc</filename> tartalmát Az /etc könyvtár tartalmazza a rendszer beállításaival kapcsolatos információk jelentõs részét, valamint a rendszer indítása során lefutó szkripteket. Egyes szkriptek a &os; verzióiról verzióira változnak. Némely konfigurációs állományok a rendszer hétköznapi mûködésében is szerepet játszanak. Ilyen például az /etc/group. Alkalmanként a make installworld parancs futása során igényt tart adott nevû felhasználókra és csoportokra. A frissítéskor azonban ezek a felhasználók vagy csoportok nem feltétlenül állnak rendelkezésre, ami gondokat okozhat. Ezért bizonyos esetekben a make buildworld elõzetesen ellenõrzi az igényelt felhasználók és csoportok meglétét. Erre például szolgálhat a smmsp felhasználó esete. Nélküle a felhasználók nem tudták telepíteni az új rendszert, mert hiányában az &man.mtree.8; nem volt képes létrehozni a /var/spool/clientmqueue könyvtárat. Ezt úgy lehetett megoldani, hogy még az alaprendszer lefordítása (a buildworld) elõtt meg kellett hívni a &man.mergemaster.8; parancsot a paraméterrel. Így csak azokat az állományokat fogja összehasonlítani, amelyek feltétlenül szükségesek a buildworld vagy az installworld sikeres mûködéséhez. Amennyiben a mergemaster egy olyan verziójával rendelkezünk, amely nem ismeri a paramétert, akkor az elsõ indításakor használjuk a forrásfában található újabb verzióját: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p Ha különösen paranoiásak vagyunk, akkor a csoport törlése vagy átnevezése elõtt az alábbi paranccsal ellenõrizni tudjuk az általa birtokolt állományokat: &prompt.root; find / -group GID -print Ez megmutatja GID (mely megadható numerikus vagy név formájában is) jelzésû csoporthoz tartozó összes állományt a rendszerünkben. Váltsunk egyfelhasználós módba egyfelhasználós mód A rendszert egyfelhasználós módban érdemes lefordítani. A nyilvánvalóan érezhetõ gyorsaság elõnyei mellett azért is jobban járunk, mert az új rendszer telepítése során számos rendszerszintû állomány is módosításra kerül, beleértve a szabványos rendszerszintû binárisokat, függvénykönyvtárakat, include állományokat és így tovább. Ha üzemelõ rendszeren végezzük el mindezen változtatásokat (különösen amikor rajtunk kívül még további felhasználók is tartózkodnak a rendszerben), az csak a bajt hozza ránk. többfelhasználós mód Másik lehetõség gyanánt a rendszert magát lefordíthatjuk többfelhasználós módban is, majd ezután csak a telepítést hajtjuk végre egyfelhasználós üzemmódban. Ha eszerint cselekszünk, egyszerûen várjunk addig, amíg az összes fordítás be nem fejezõdik, és az egyfelhasználósra váltást halasszuk a installkernel vagy installworld idejére. Egy mûködõ rendszerben rendszeradminisztrátorként az alábbi parancs kiadásával válthatunk át egyfelhasználós módba: &prompt.root; shutdown now Ezt elérhetjük úgy is, ha újraindítjuk a rendszert és a rendszer indításakor a single user pontot választjuk a menübõl. Ekkor a rendszer egyfelhasználós módban indul el. Miután ez megtörtént, adjuk ki a következõ parancsokat: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a Ezekkel a parancsokkal elõször ellenõrizzük az állományrendszereket, ezután újracsatlakoztatjuk a / állományrendszert írható módban, csatlakoztatjuk az /etc/fstab állományban megadott összes többi UFS típusú állományrendszert, majd bekapcsoljuk a lapozóállomány használatát. Ha a gépünk óráját nem a greenwich-i, hanem a helyi idõ szerint állítottuk be (ez akkor áll fenn, ha a &man.date.1; parancs nem a helyes idõt és idõzónát jelzi ki), akkor még erre is szükségünk lehet: &prompt.root; adjkerntz -i Ezzel a helyi idõzóna beállításait tudjuk jól beállítani — nélküle késõbb még gondjaink akadhatnak. Töröljük a <filename>/usr/obj</filename> könyvtárat A rendszer egyes részei fordításuk során a /usr/obj könyvtáron belülre kerülnek (alapértelmezés szerint). Az itt található könyvtárak a /usr/src könyvtárszerkezetét követik. Ha mindenestõl töröljük ezt a könyvtárat, akkor növeli tudjuk a make buildworld folyamat sebességét és megmenekülünk néhány függõségekkel kapcsolatos fejfájástól is. Egyes /usr/obj könyvtáron belüli állományoknál szerepelhet a megváltoztathatatlan (immutable) állományjelzõ (lásd &man.chflags.1;), amelyet a mûvelet elvégzéséhez elõször el kell távolítanunk. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * Fordítsuk újra az alaprendszert A kimenet elmentése Jól járunk azzal, ha a &man.make.1; futásának kimenetét elmentjük egy állományba, mivel így a hibák esetén lesz egy másolatunk a hibaüzenetrõl. Ha konkrétan nekünk nem is feltétlenül segít megtalálni a hiba tényleges okát, mások viszont többet tudnak róla mondani, ha beküldjük ezt a &os; egyik levelezési listájára. Ezt egyébként a legegyszerûbben a &man.script.1; parancs segítségével oldhatjuk meg, amelynek paraméteréül azt az állományt kell megadni, ahova menteni akarjuk a kimenetet. Ezt közvetlenül a rendszer újrafordítása elõtt kell kiadnunk, majd miután megállt, a exit paranccsal kiléphetünk belõle. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … fordít, fordít, fordít … &prompt.root; exit Script done, … Ilyenkor soha ne a /tmp könyvtárba mentsük a kimenetet, mert ennek a tartalma a következõ indítás során magától törlõdik. Sokkal jobban tesszük, ha a /var/tmp könyvtárba (ahogy tettük azt az elõbbi példában is) vagy a root felhasználó könyvtárába mentünk. Az alaprendszer fordítása A /usr/src könyvtárban kell állnunk: &prompt.root; cd /usr/src (kivéve természetesen, ha máshol van a forráskód, akkor abba a könyvtárba menjünk). make Az alaprendszert a &man.make.1; paranccsal fordíthatjuk újra. Ez a Makefile nevû állományból olvassa be a &os; programjainak újrafordítását leíró utasításokat, a fordításuk sorrendjét és így tovább. A begépelendõ paranccsor általános alakja tehát a következõképpen néz ki: &prompt.root; make -x -DVÁLTOZÓ target A fenti példában a egy olyan a paraméter, amelyet a &man.make.1; programnak adunk át. A &man.make.1; man oldalán megtalálhatjuk az összes neki átadható ilyen beállítást. A alakú paraméterek közvetlenül a Makefile állománynak adnak át olyan változókat, amelyek segítségével vezérelhetõ a viselkedése. Ezek ugyanazok a változók, mint amelyek az /etc/make.conf állományban is szerepelnek, és itt a beállításuk egy másik módját kapjuk. Így a &prompt.root; make -DNO_PROFILE target paranccsal is megadhatjuk, hogy ne profilozott függkönyvtárak jöjjenek létre, ami pontosan megfelel a NO_PROFILE= true # Avoid compiling profiled libraries sornak az /etc/make.conf állományban. A target árulja el a &man.make.1; programnak, hogy mi a teendõje. Minden egyes Makefile különbözõ targeteket definiál, és a kiválasztott target mondja meg, pontosan mi is fog történni. Egyes targetek ugyan megjelennek a Makefile állományban, azonban nem feltétlenül hivatkozhatunk rájuk közvetlenül. Ehelyett csupán arra valók, hogy a fordítás folyamatának lépéseit felbontsák még kisebb allépésekre. A legtöbb esetben azonban semmilyen paramétert nem kell átadnunk a &man.make.1; parancsnak, ezért a teljes formája így fog kinézni: &prompt.root; make target ahol a target az egyik fordítási lehetõséget képviseli. Az elsõ ilyen targetnek mindig a buildworld-nek kell lennie. Ahogy a neve is mutatja, a buildworld lefordítja az összes forrást a /usr/obj könyvtárba, majd a installworld mint másik target, telepíti az így létrehozott elemeket a számítógépre. A targetek szétválasztása két okból is elõnyös. Elõször is lehetõvé teszi, hogy az új rendszert biztonságban lefordíthassuk, miközben az a jelenleg futó rendszert nem zavarja. A rendszer tehát képes saját magát újrafordítani. Emiatt a buildworld target akár többfelhasználós módban is mindenféle nem kívánatos hatás nélkül használható. Ennek ellenére azonban továbbra is azt javasoljuk, hogy a installworld részt egyfelhasználós módban futtassuk le. Másodrészt ezzel lehetõségünk nyílik NFS állományrendszer alkalmazásával több számítógépre is telepíteni hálózaton keresztül. Ha például három frissítendõ számítógépünk van, az A, B és C, akkor az A gépen elõször adjuk ki a make buildworld, majd a make installworld parancsot. A B és C gépek ezután NFS segítségével csatlakoztatják az A /usr/src és /usr/obj könyvtárait, amelyet követõen a make installworld paranccsal telepíteni tudjuk a fordítás eredményét a B és C gépekre. Noha a world mint target még mindig létezik, használata határozottan ellenjavalt. A &prompt.root; make buildworld parancs kiadásakor a make parancsnak megadható egy paraméter is, amellyel párhuzamosíthatjuk a folyamat egyes részeit. Ez általában többprocesszoros számítógépeken nyer értelmet, azonban mivel a fordítás folyamatának haladását inkább az állománymûveletek mintsem a processzor sebessége korlátozza, ezért alkalmazható akár egyprocesszoros gépeken is. Tehát egy átlagos egyprocesszoros gépen így adható ki a parancs: &prompt.root; make -j4 buildworld Ennek hatására &man.make.1; egyszerre 4 szálon igyekszik mûködni. A levelezési listákra beküldött tapasztalati jellegû bizonyítékok azt igazolják, hogy általában ez a beállítás adja a legjobb teljesítményt. Ha többprocesszoros géppel rendelkezünk és rajta SMP támogatású rendszermagot indítottunk el, akkor érdemes 6 és 10 közötti értékekkel kísérleteznünk. Idõigény az alaprendszer újrafordítása idõigény Számos tényezõ befolyásolja a fordítás tényleges idõbeli hosszát, de a &os.stable; fa lefordítása mindenféle trükkök és rövidítések nélkül a legtöbb számítógépen olyan egy vagy két órára taksálható. A &os.current; fához ennél valamivel több idõre lesz szükségünk. Fordítsunk és telepítsünk egy új rendszermagot rendszermagot fordítása Az újdonsült rendszerünket csak akkor tudjuk igazán kihasználni, ha egy új rendszermagot is készítünk hozzá. Ez gyakorlati szinten tulajdonképpen elvárás, mivel könnyen elõfordulhat, hogy bizonyos memóriabeli adatszerkezetek felépítése megváltozott, ezért némely programok, mint például a &man.ps.1; és &man.top.1;, egészen addig nem lesznek képesek normálisan mûködni, amíg a rendszer és a rendszermag forráskódja nem illeszkedik egymáshoz. Ennek legegyszerûbb és egyben legbiztonságosabb módja, ha a GENERIC beállításai alapján gyártunk és telepítünk egy rendszermagot. Még ha a GENERIC beállításai nem is tartalmazzák a rendszerünkben fellelhetõ összes eszközt, minden megtalálható bennük ahhoz, hogy a rendszert sikeresen elindíthassuk legalább egyfelhasználós módban. Ez mellesleg remek próbája az új rendszer életképességének. Miután elindítottuk a rendszert a GENERIC típusú rendszermaggal és meggyõzõdtünk róla, hogy a rendszer tényleg mûködõképes, a megszokott rendszermagunk konfigurációs állománya alapján nyugodtan elkészíthetjük ezután azt is. &os; alatt egy új rendszermag építése elõtt fontos újrafordítani az alaprendszert. Ha saját beállításaink szerint akarunk rendszermagot létrehozni és már van is ehhez egy konfigurációs állományunk, akkor erre használhatjuk a KERNCONF=SAJÁTMAG paramétert is, valahogy így: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=SAJÁTMAG &prompt.root; make installkernel KERNCONF=SAJÁTMAG Hozzátennénk, hogy ha a kern.securelevel rendszerváltozó értékét 1 felé állítottuk és a rendszermag állományának beállítottunk noschg vagy hozzá hasonló állományjelzõt, akkor az installkernel lefuttatásához mindenképpen egyfelhasználós módba kell váltanunk. Minden más esetben további bonyodalmak nélkül ki tudjuk adni az említett parancsokat. A kern.securelevel részleteirõl az &man.init.8; oldalán, a különbözõ állományjelzõkrõl pedig a &man.chflags.1; oldalán olvashatunk. Indítsuk újra a rendszert egyfelhasználós módban egyfelhasználós mód Az új rendszermag mûködésének leteszteléséhez indítsuk újra a rendszert egyfelhasználós módban. Ennek pontos részleteit lásd . Telepítsük az új rendszer binárisait Ha a &os; friss változatát nemrég fordítottuk le a make buildworld paranccsal, akkor utána az installworld segítségével tudjuk telepíteni a keletkezett programokat. Tehát írjuk be ezeket: &prompt.root; cd /usr/src &prompt.root; make installworld Amennyiben a paranccsorban a make buildworld használata során adtunk meg változókat, akkor ne felejtsük el ugyanazokat megadni a make installworld kiadása során sem. Ez viszont a többi paraméterre már nem feltétlenül érvényes. Például a beállítást szigorúan tilos az installworld targettel együtt használni. Ennek megfelelõen tehát ha korábban ezt írtuk be: &prompt.root; make -DNO_PROFILE buildworld akkor így telepítsünk: &prompt.root; make -DNO_PROFILE installworld Máskülönben azokat a profilozott függvénykönyvtárakat próbáljuk meg telepíteni, amelyek a make buildworld futása során nem jöttek létre. Frissítsük a <command>make installworld</command> által kihagyott állományokat Az alaprendszer újrafordítása nem regisztrálja az új vagy megváltozott állományokat bizonyos könyvtárakban (különösen értendõ ez az /etc, /var és /usr esetén). Az ilyen állományokat a legegyszerûbben a &man.mergemaster.8; használatával tarthatjuk karban, de igény szerint akár kézzel is elvégezhetjük a szükséges aktualizálásokat. Függetlenül attól, hogy mit is választunk, mindenképpen készítsünk biztonsági mentést az /etc könyvtárról arra az esetre, ha bármilyen szörnyûség történne. Tom Rhodes Írta: A <command>mergemaster</command> mergemaster A &man.mergemaster.8; segédprogram valójában egy Bourne szkript, amely segít az /etc könyvtárunkban és a forrásfában levõ /usr/src/etc könyvtárban elhelyezkedõ konfigurációs állományok közti eltérések megállapításában. Ezt a módszert ajánljuk arra, hogy összevessük a konfigurációs állományainkat a forrásfában található változataikkal. A használatának megkezdéséhez egyszerûen írjuk be, hogy mergemaster, majd várjunk egy kicsit, amíg a mergemaster létrehoz magának egy átmeneti környezetet a / könyvtárból elindulva és megtölti azt a különbözõ rendszerszintû beállításokat tartalmazó állományokkal. Ezeket az állományokat aztán összehasonlítja a jelenleg érvényben levõ változataikkal. Ilyenkor a köztük talált eltéréseket a &man.diff.1; formátumának megfelelõen módon mutatja meg, ahol a jelöli a hozzáadott vagy módosított sorokat, a pedig a teljesen eltávolítandó vagy cserélendõ sorokat. Errõl a formátumról bõvebben a &man.diff.1; man oldalán találhatunk felvilágosítást. A &man.mergemaster.8; ezt követõen megmutatja az összes olyan állományt, ahol eltérést tapasztalt, és ezen a ponton van lehetõségünk letörölni (delete) az új állományokat (amelyekre itt most ideiglenes állományként hivatkozik), telepíteni (install) a módosítatlan ideiglenes (új) állományt, valamint összefésülni (merge) az ideiglenes (új) és a jelenlegi állományokat, vagy ismét átnézni (view) a &man.diff.1; által jelzett különbségeket. Ha az ideiglenes állomány törlését választjuk, akkor a &man.mergemaster.8; ezt úgy értelmezi, hogy változatlanul meg akarjuk tartani a jelenlegi változatot és törölni az újat. Ezt alapvetõen nem javasoljuk, hacsak tényleg nem látunk valamilyen okot erre. A &man.mergemaster.8; parancssorában a ? begépelésével bármikor kérhetünk segítséget. Ha az állomány kihagyását (skip) választjuk, akkor majd ismét felajánlja, amikor végeztünk az összes többivel. A módosítatlan ideiglenes állomány telepítésének választásával lecseréljük a jelenleg verziót az újra. Ha az aktuális verziót sem változtattuk meg, akkor számunkra ez a legjobb megoldás. Az állományok összefésülésének kiválasztásakor kapunk egy szövegszerkesztõt, benne a két állomány tartalmával. Ilyenkor tudjuk a képernyõn soronként egyeztetni a két állományt, majd a belõlük a megfelelõ részek összeválogatásával kialakítani az eredményt. Ebben a feldolgozási módban az l (mint left, vagyis bal) billentyû lenyomására a bal oldalon látható részt, az r (mint right, vagyis jobb) lenyomására pedig a jobb oldalon látható részt választjuk ki. Az így keletkezõ eredményt ezután egy állományba kerül, amelyet telepíteni tudunk. Ez a megoldás olyan állományok esetében használható, amikor a felhasználó módosított az alapértelmezett beállításokat. Ha a &man.diff.1; szerinti alakban akarjuk átnézni a különbségeket, akkor a &man.mergemaster.8; ugyanúgy megmutatja ezeket, mint a paranccsor megjelenítése elõtt. Miután a &man.mergemaster.8; végigment a rendszerszintû állományokon, további opciókat mutat. Megkérdezheti, hogy újra létre akarjuk-e hozni a jelszavakat tároló állományt (rebuild), illetve a folyamat végén a megmaradt ideiglenes állományok törlésére (remove) vár választ. Az állományok aktualizálása kézzel Ha inkább manuálisan szeretnénk frissíteni, akkor nem másolhatjuk csak egyszerûen át az állományokat a /usr/src/etc könyvtárból a /etc könyvtárba és nem hagyhatjuk ezeket sorsukra. Egyes állományokat elõször telepíteni kell. Ez azért van így, mert a /usr/src/etc könyvtár nem pusztán az /etc könyvtár egyszerû másolata. Ráadásul az /etc könyvtárban vannak olyan állományok, amelyek a /usr/src/etc könyvtárban nem is találhatóak meg. Ha (az ajánlottak szerint) a &man.mergemaster.8; segítségével dolgozunk, nyugodtan átléphetünk a következõ szakaszra. Saját magunk a legegyszerûbben ezt úgy tudjuk megoldani, ha telepítjük az állományokat egy új könyvtárba és ezután nekiállunk változásokat keresni. Az <filename>/etc</filename> meglevõ tartalmának mentése Habár elméletileg magától semmi sem fogja bántani ezt a könyvtárat, azért ettõl függetlenül mindig érdemes biztosra menni. Ezért másoljuk az /etc könyvtár tartalmát egy megbízható helyre. Például: &prompt.root; cp -Rp /etc /etc.old Az itt a rekurzív másolást jelenti, a pedig a dátumok, az állományok és egyebek tulajdoni viszonyainak megõrzését. Az /etc új változatának telepítéséhez szükségünk lesz még további könyvtárakra is. Erre a feladatra a /var/tmp/root tökéletesen megfelel, ahol még létre kell hoznunk néhány alkönyvtárat. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution Ezzel létrejön a szükséges könyvtárszerkezet és települnek az állományok. Sok üres alkönyvtár is keletkezik a /var/tmp/root könyvtáron belül, ezeket töröljük. Ezt a legkönnyebben így tehetjük meg: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null Ezzel törlõdnek az üres könyvtárak. (A szabvány hibakimenetet átirányítottuk a /dev/null eszközre, és ezzel elnyomtuk a nem üres könyvtárak esetén keletkezõ hibaüzeneteket.) A /var/tmp/root most már tartalmazza az összes olyan állományt, amelyek normális esetben a / könyvtáron belül foglalnak helyet. Ezt követõen nincs más dolgunk, csak végigmenni az itt található állományokon és megállapítani, miben térnek a meglévõektõl. Vegyük észre, hogy a /var/tmp/root könyvtárba telepített állományok némelyikének neve .-tal kezdõdik. Az írás pillanatában ezek csak a /var/tmp/root/ és /var/tmp/root/root/ könyvtárakban található parancsértelmezõhöz tartozó indító állományok lehetnek, habár adódhatnak még ilyenek (attól függõen, mikor olvassuk ezt). Ezért a feldolgozásukhoz ne felejtsük el a ls -a parancsot használni. A &man.diff.1; alkalmazásával legegyszerûbben így tudunk összehasonlítani két állományt: &prompt.root; diff /etc/shells /var/tmp/root/etc/shells Ennek hatására megjelennek az /etc/shells és az új /var/tmp/root/etc/shells állományok közti különbségek. A segítségével gyorsan el tudjuk dönteni, hogy összefésüljük-e a két állományt, vagy csak egyszerûen írjuk felül a régebbi verziót az újjal. Az új könyvtár (<filename>/var/tmp/root</filename>) nevébe írjuk bele a dátumot is, így könnyedén össze tudunk hasonlítani több verziót is A rendszer gyakori újrafordítása az /etc szintén gyakori aktualizálását is maga után vonja, ami viszont fárasztó lehet. Az iménti folyamatot fel tudjuk gyorsítani, hogy ha az /etc legutoljára összefésült változatát megtartjuk. A most következõ eljárás ennek mikéntjét vázolja fel. A megszokottak szerint fordítsuk le a rendszert. Majd amikor az /etc könyvtárat és a többit is frissíteni akarjuk, a célként megadott könyvtár nevében adjuk meg a dátumot. Ha tehát például 1998. február 14. van, akkor írjuk ezt: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Fésüljük össze a könyvtárban található az állományokat a fentiekben körvonalazottak szerint. Befejezés után õrizzük meg a /var/tmp/root-19980214 könyvtárat. Mikor újra letöltjük a legfrissebb forrásokat és megismételjük az elõbbi lépéseket, haladjunk megint az elsõ lépés szerint. Ekkor tehát létrejön egy újabb könyvtár, amelynek a neve ezúttal már /var/tmp/root-19980221 lesz (ha például hetente frissítünk). Most már meg tudjuk vizsgálni a közbeesõ héten született eltéréseket, ha a két könyvtárra kiadunk egy rekurzív &man.diff.1; hívást: &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Általában így kevesebb eltérést kapunk, mint amennyi például a /var/tmp/root-19980221/etc/ és az /etc összehasonlítása során elkerült volna. Mivel kisebb a keletkezett különbségek száma, ezért könnyebb lesz átvinnünk az /etc könyvtárunkba is a módosításokat. Ezután törölhetjük a régebbi /var/tmp/root-* könyvtárat: &prompt.root; rm -rf /var/tmp/root-19980214 Az /etc összefésülésekor mindig ismételjük meg ezeket a lépéseket. A &man.date.1; meghívásával akár automatikussá is tehetjük a könyvtárak névadását: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Újraindítás Ezzel készen is vagyunk. Miután ellenõriztük, hogy minden a megfelelõ helyére került, indítsuk újra a rendszert. Ehhez egy egyszerû &man.shutdown.8; is elegendõ: &prompt.root; shutdown -r now Befejeztük! Gratulálunk, sikerült frissítenünk a &os; rendszerünket. Ha mégis valami balul ütne ki, könnyen újra tudjuk fordítani a rendszer egyes részeit. Például, ha véletlenül letöröltük az /etc/magic állományt az /etc frissítése vagy összefésülése során, a &man.file.1; parancs nem fog tudni rendesen mûködni. Ilyenkor a következõket kell tennünk a hiba kijavításához: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install Kérdések Minden egyes változtatásnál újra kell fordítani a rendszert? Nem könnyû választ adni erre a kérdésre, mivel ez alapvetõen a változtatás jellegétõl függ. Például, ha elindítjuk a CVSup programot és csak az alábbi állományok frissülnek: src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk Ekkor valószínûleg nem éri meg újrafordítani a teljes rendszert. Elegendõ csupán belépni az érintett állományokat tartalmazó alkönyvtárakba és ott rendre kiadni a make all install parancsot. Ha viszont már valami komolyabb, például az src/lib/libc/stdlib változott meg, akkor vagy az egész rendszert, vagy legalább azon részeit fordítsuk újra, amely statikusan linkeltek (és minden más idõközben még hozzáadott statikusan linkelt dolgot). Hogy melyik megoldást választjuk, teljesen rajtunk áll. Újrafordíthatjuk az egész rendszert kéthetente, mondván, hadd gyüljenek fel szépen a módosítások, vagy a függõségek pontos kielemzésével csak azokat az elemeket fordítjuk újra, amelyek tényleg meg is változtak. Természetesen az egész attól függ, hogy milyen gyakran és melyik rendszert, a &os.stable;-t vagy a &os.current;-et frissítjük. A fordító rengeteg 11-es jelzést (signal 11) (vagy másfajta jelzéseket) dob hibával. Mi történhetett? signal 11 Ez általában hardveres meghibásodásra utal. A rendszer újrafordítása alapjaiban véve egy remek módszer számítógépünk alkatrészeinek terhelésére, ezért gyakorta elõhozza a memória már meglevõ hibáit. Ezek többnyire abban fogalmazódnak meg, hogy a fordító rejtélyes módon leáll mindenféle furcsa jelzések hatására. Errõl biztosan úgy tudunk meggyõzõdni, ha újraindítjuk a make programot és az a folyamat egy teljesen másik pontján vérzik el. Ilyenkor nem tudunk mást tenni, mint egymás után kicserélgetjük, kivesszük az alkatrészeket és így próbáljuk megállapítani, pontosan melyikük is okozza a gondokat. A fordítása befejezése után törölhetem a /usr/obj könyvtárat? Röviden: Igen. A /usr/obj tartalmazza a fordítás folyamata során keletkezõ összes tárgykódot. Ennek törlése általában a make buildworld elsõ lépései között szerepel. Ezért tulajdonképpen a /usr/obj megtartásának nincs túlságosan sok értelme, viszont elég sok (jelenleg úgy kb. 340 MB) helyet fel tudunk így szabadítani. Ha azonban értjük a dolgunkat, akkor megadhatjuk a make buildworld parancsnak, hogy hagyja ki ezt a lépést. Ennek hatására a fordítás sokkal hamarabb véget ér, mivel a legtöbb forrást így nem kell újrafordítani. Üröm az örömben, hogy ha netalán aprócska függõségi problémák merülnének fel, akkor az egész fordítás megfeneklik mindenfelé különös módokon. Emiatt gyakran írnak feleslegesen leveleket a &os; levelezési listáira, melyek a rendszer sikertelen újrafordításáról panaszkodnak, miközben kiderül, hogy az maguk az érintettek akarták lerövidíteni a folyamatot. Lehetséges a megszakadt fordítás folytatása? Ez attól függ, hogy a probléma bekövetkezése elõtt mennyire sikerült eljutni a fordításban. Általában (tehát nem feltétlenül minden esetben) a make buildworld lefordítja a fordításhoz szükséges eszközök (például a &man.gcc.1; és &man.make.1;) újabb változatait és a rendszer függvénykönyvtárait, majd ezeket telepíti. Ezután ezekkel az új eszközökkel lefordítattja saját magukat és ismét telepíti. Ezt követõen fordítja újra az új rendszerállományokkal az egész rendszert (így ezúttal már az olyan szokásos felhasználói programokat is, mint például az &man.ls.1; és a &man.grep.1;). Ha tudjuk, hogy az utolsó fázisban álltunk le (mivel megnéztük a fordításhoz tartozó kimenetet), akkor (minden további nélkül) elég ennyi: … kijavítjuk a hibát … &prompt.root; cd /usr/src &prompt.root; make -DNO_CLEAN all Ezzel megmarad a korábbi make buildworld munkájának eredménye. Ha ezt az üzenetet látjuk a make buildworld kimenetében: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- akkor különösebb gond nélkül megcsinálhatjuk. Amennyiben viszont nem látunk ilyen üzenetet, vagy nem vagyunk benne biztosak, akkor még mindig jobb elõvigyázatosnak lenni, ezért kénytelenek leszünk teljesen elölrõl kezdeni a fordítást. Hogyan tudjuk felgyorsítani a fordítást? Futtassuk egyfelhasználós módban. Tegyük a /usr/src és /usr/obj könyvtárakat külön állományrendszerekre, külön lemezekre. Sõt, ha lehetséges, akkor ezeket a lemezeket tegyük külön lemezvezérlõkre. Még mindig jobb, ha ezeket az állományrendszereket a &man.ccd.4; (lemezek összefûzését vezérlõ meghajtó) segítségével kiterjesztjük több lemezes eszközre. Kapcsoljuk ki a profilozást (az /etc/make.conf állományban a NO_PROFILE=true megadásával). Többnyire úgy sem lesz rá szükségünk. Az /etc/make.conf állományban a CFLAGS változót állítsuk az értékre. Az gyakran sokkal lassabb, az és alig tér el az optimalizálás mértékében. A paraméter hatására pedig a fordítóprogram átmeneti állományok helyett csöveket használ a kommunikációra, és így megtakarít némi lemezhasználatot (a memóriahasználat terhére). Ha a &man.make.1; parancsnak átadjuk a paramétert, akkor képes több mindent párhuzamosan futtatni. Ez sok esetben segít attól függetlenül, hogy egy- vagy többprocesszoros gépünk van. A /usr/src könyvtárat tartalmazó állományrendszert csatlakoztathatjuk (vagy újracsatlakoztathatjuk) a beállítással. Ilyenkor az állományrendszer nem rögzíti a hozzáférés idejét. Erre az információra sincs igazából szükségünk. &prompt.root; mount -u -o noatime /usr/src A fenti példa azt feltételezi, hogy a /usr/src könyvtárnak saját állományrendszere van. Ha ez nem így lenne (tehát például a /usr része), akkor itt azt kell megadnunk, nem pedig a /usr/src nevét. A /usr/obj könyvtárat tartalmazó állományrendszert csatlakoztathatjuk (vagy újracsatlakoztathatjuk) az beállítással. Ennek hatására a lemez írása aszinkron módon történik. Magyarul az írási mûveletek azonnal befejezõdnek, miközben az adat ténylegesen csak pár másodperccel késõbb kerül ki a lemezre. Ezzel az írási kérelmek gyönyörûen összegyûjthetõek, ami nagymértékû növekedést eredményez a teljesítményben. Ne felejtsük el azonban, hogy ezzel együtt az állományrendszerünk is sérülékenyebbé válik. Ezen beállítás használatával megnõ annak az esélye, hogy egy áramkimaradást követõ indításnál az állományrendszer helyreállíthatatlan állapotba kerül. Ha egyedül csak a /usr/obj található ezen az állományrendszeren, akkor ez nem jelent akkora veszélyt. Amikor viszont rajta kívül még értékes adat is található az állományrendszeren, a beállítás érvényesítése elõtt mindenképpen készítsünk róla friss mentéseket. &prompt.root; mount -u -o async /usr/obj Ahogy arról az elõbb is szó esett, ha a /usr/obj nem egy különálló állományrendszeren található, akkor a példában szereplõ csatlakozási pontot cseréljük ki a megfelelõre. Mi tegyünk, ha valami nem megy rendesen? Egyértelmûen bizonyosodjunk meg róla, hogy a korábbi fordításokból nem maradtak vissza semmiféle kóbor állományok. Ennyi sokszor pontosan elég. &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; make cleandir Igen, a make cleandir parancsot tényleg kétszer kell kiadni. Ezután a make buildworld parancstól indulva kezdjük újra a fordítást. Ha még ezek után is fennáll a probléma, küldjük el a hibát tartalmazó kimenetet és a uname -a parancs eredményét a &a.questions; címére. Ne lepõdjünk meg, ha a beállításainkra vonatkozóan még kapunk további kérdéseket is! Mike Meyer Írta: A források követése több géppel NFS több gép telepítése Ha egyszerre több számítógéppel is szeretnénk követni ugyanannak a forrásfának a változásait és ezért mindegyikre letöltjük a forrásokat majd újrafordítjuk ezeket, akkor sok erõforrást, de leginkább lemezterületet, hálózati sávszélességet és processzoridõt, feleslegesen használunk. Ezekkel úgy tudunk spórolni, ha valójában csak egyetlen géppel végeztetjük el a munka legtöbb részét, miközben a többi NFS használatával dolgozik. Ez a szakasz ezt a módszert foglalja össze. Elõkészületek Elõször is szedjük össze az egyezõ binárisokat futtató gépeket, melyekre a továbbiakban csak fordítási csoport néven hivatkozunk. Minden gépnek lehet saját rendszermagja, viszont a felhasználói programok mindegyikõjük esetében ugyanazok. Ebbõl a csoportból válasszuk ki egy fordító gépet. Ez lesz az a gép, amelyen a rendszer és a rendszermag lefordításra kerül. Ideális esetben ez a leggyorsabb gép, amelynek elegendõ a processzorkapacitása arra, hogy lefuttassa a make buildworld és make buildkernel parancsokat. Érdemes még rajta kívül kiválasztanunk egy tesztelõ gépet is, ahol a véglegesítés elõtt kipróbálhatjuk a szoftverfrissítéseket. Ennek egy olyan gépnek kell lennie, amely akár hosszabb ideig is nélkülözhetõ a csoportból. Lehet akár maga a fordítást végzõ gép is, de nem elvárás. A fordítási csoportban levõ összes gépnek ugyanarról a géprõl és ugyanarra a pontra kell csatlakoztatnia a /usr/obj és /usr/src könyvtárakat. Ezek optimális esetben a fordítással foglalkozó gép két külön lemezmeghajtóján vannak, melyek egyaránt elérhetõek NFS-en keresztül. Ha több fordítási csoportunk is van, akkor az /usr/src könyvtárnak elegendõ csak egyetlen fordító gépen meglennie, a többi pedig csatlakoztassa NFS-en keresztül. Végül gyõzödjünk meg róla, hogy az /etc/make.conf és a /etc/src.conf állományok tartalma a fordítási csoport mindegyik gépénél megegyezik a fordító gépével. Ez azt jelenti, hogy a fordító gépnek az alaprendszer ugyanazon részeit és ugyanúgy kell létrehozni, mint amelyet a fordítási csoport akármelyik gépére telepíteni is akarunk. Ezenkívül még a fordítási csoportban levõ minden egyes gép /etc/make.conf állományában a KERNCONF értékének a saját rendszermagjára vonatkozó konfigurációt kell megadni, illetve a fordítással foglakozó gép KERNCONF változójánál pedig az együtt összeset, a sajátjával kezdve. Ennek megfelelõen a fordító gépnek a rendszermagok lefordításához rendelkeznie kell az egyes gépek /usr/src/sys/arch/conf könyvtárában meglevõ állományaival. Az alaprendszer Most, miután mindent megfelelõen elõkészítettünk, készen állunk a munkára. A ban leírtak szerint fordítsuk le a rendszermagokat és az alaprendszert a fordító gépen, de utána még nem telepítsünk semmit se. Ha befejezõdött a fordítás, lépjünk be a tesztelõ gépre és telepítsük a frissen fordított rendszermagot. Ha ez a gép NFS-en keresztül éri a /usr/src és /usr/obj könyvtárakat, akkor az egyfelhasználós módban aktiválni kell a hálózatot, majd csatlakoztatni ezeket. Ezt legkönnyebben úgy tudjuk megcsinálni, ha a gépet elõször elindítjuk többfelhasználós módban, majd a shutdown now paranccsal egyfelhasználós módba váltunk. Ha eljuttunk ide, telepítsünk az új rendszermagot és rendszert, illetve a megszokott módon futtassuk a mergemaster parancsot. Amikor ezt befejeztük, ezen a gépen térjünk vissza a hétköznapi többfelhasználós mûködési módba. Miután a tesztelésre szánt gépen ellenõriztük, hogy minden a megfelelõ módon mûködik, az elõbb tárgyalt eljárással telepítsük fel a fordítási csoportban levõ összes többi gépre is az új szoftvereket. Portok Ugyanezt a gondolatmenet alkalmazható a portfa esetében is. Az elsõ és egyben legfontosabb lépés a /usr/ports csatlakoztatása ugyanarról a géprõl a fordítási csoport minden gépére. Az /etc/make.conf megfelelõ beállításával még a terjesztési állományokat is meg tudjuk osztani. A DISTDIR értékét egy olyan közösen használt könyvtárra állítsuk, amely írható az NFS-en keresztül megosztott állományrendszerünkben a root felhasználóként tevékenykedõk számára. A WRKDIRPREFIX változót minden gépen egy helyi fordítási könyvtárra állítsuk. Zárásképpen még hozzátesszük, hogy ha csomagokat akarunk készíteni és mások számára is elérhetõvé tenni, akkor ne felejtsük el a PACKAGES változót a DISTDIR változóhoz hasonlóan beállítani. diff --git a/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml index 714d92b36c..8f1b7d6bff 100644 --- a/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml @@ -1,6287 +1,6296 @@ Matthew Dillon A fejezet legnagyobb részét a security(7) man oldal alapján írta: Biztonság biztonság Áttekintés Ez a fejezet egy alapvetõ bevezetés a rendszerek biztonsági fogalmaiba, ad néhány általános jótanácsot és a &os;-vel kapcsolatban feldolgoz néhány komolyabb témát. Az itt megfogalmazott témák nagy része egyaránt ráhúzható rendszerünk és általánosságban véve az internet biztonságára is. A internet már nem az békés hely, ahol mindenki a kedves szomszéd szerepét játssza. A rendszerünk bebiztosítása elkerülhetetlen az adataink, szellemi tulajdonunk, idõnk és még sok minden más megvédésére az internetes banditák és hasonlók ellen. A &os; segédprogramok és mechanizmusok sorát kínálja fel a rendszerünk és hálózatunk sértetlenségének és biztonságának fenntartására. A fejezet elolvasása során megismerjük: az alapvetõ rendszerbiztonsági fogalmakat, különös tekintettel a &os;-re; milyen olyan különbözõ titkosítási mechanizmusok érthetõek el a &os;-ben, mint például a DES és az MD5; hogyan állítsunk be egyszeri jelszavas azonosítást; hogyan burkoljunk az inetd segítségével TCP kapcsolatokat; hogyan állítsuk be a KerberosIV-t a &os; 5.0-nál korábbi változatain; hogyan állítsuk be a Kerberos5-t a &os;-n; hogyan állítsuk be az IPsec-et és hozzunk létre VPN-t &os;/&windows; gépek között; hogyan állítsuk be és használjuk az OpenSSH-t, a &os; SSH implementációját; mik azok az ACL-ek az állományrendszerben és miként kell ezeket használni; hogyan kell használni a Portaudit segédprogramot a Portgyûjteménybõl telepített külsõ szoftvercsomagok biztonságosságának ellenõrzésére; hogyan hasznosítsuk a &os; biztonsági tanácsait tartalmazó leírásokat mit jelent a futó programok nyilvántartása és hogyan engedélyezzük azt &os;-n. A fejezet elolvasásához ajánlott: az alapvetõ &os; és internetes fogalmak ismerete. A könyvben további biztonsági témákról is szó esik, például a ben a Kötelezõ hozzáférés-vezérlésrõl (MAC) és a ben pedig az internetes tûzfalakról. Bevezetés A biztonság egy olyan funkció, ami a rendszergazdától indul és nála is végzõdik. Míg az összes többfelhasználós BSD &unix; rendszer önmagában is valamennyire biztonságos, a felhasználók fegyelmezéséhez szükség további biztonsági mechanizmusok kiépítésére és karbantartására, ami minden bizonnyal egy rendszergazda egyik legfontosabb kötelessége. A számítógépek csak annyira biztonságosak, mint amennyire beállítjuk, és a biztonsági megfontolások állandó versenyben vannak az emberi kényelemmel. A &unix; rendszerek általánosságban véve órási mennyiségû program párhuzamos futtatására képesek, melyek többsége kiszolgálóként fut — ez azt jelenti, hogy hozzájuk kívülrõl érkezõ egyedek csatlakozhatnak és társaloghatnak velük. Ahogy a tegnap kicsi és nagy számítógépei napjaink asztali gépeivé váltak és ahogy a számítógépek egyre többen csatlakoznak hálózatra és az internetre, a biztonság fontossága is egyre jobban növekszik. A rendszerek biztonsága a támadások különbözõ formáival is foglalkozik, többek közt olyan támadásokkal, amelyek a rendszer összeomlását vagy használhatatlanságát célozzák meg, de nem próbálják meg veszélybe sodorni a root felhasználó hozzáférését (feltörni a gépet). A biztonsággal kapcsolatos problémák több kategóriára oszthatóak: A szolgáltatások mûködésképtelenné tételére irányuló (DoS, Denial of Service) támadások. A felhasználói fiókok veszélyeztetése. Rendszergazdai jogok megszerzése a közeli szervereken keresztül. Rendszergazdai jogok megszerzése a felhasználói fiókokon keresztül. Kiskapuk létrehozása a rendszerben. DoS támadás Denial of Service (DoS) biztonság DoS támadás Denial of Service (DoS) Denial of Service (DoS) A szolgáltatások mûködésképtelenné tételére irányuló támadások olyan tevékenységre utalnak, amelyek képesek megfosztani egy számítógépet az erõforrásaitól. A DoS támadások többnyire nyers erõvel kivitelezett technikák, melyek vagy a rendszer összeomlasztását vagy pedig a használhatatlanná tételét veszik célba úgy, hogy túlterhelik az általa felkínált szolgáltatásokat vagy a hálózati alrendszert. Egyes DoS támadások a hálózati alrendszerben rejtõzõ hibákat igyekeznek kihasználni, amivel akár egyetlen csomaggal is képesek romba dönteni egy számítógépet. Ez utóbbit csak úgy lehet orvosolni, ha a hibát kijavítjuk a rendszermagban. A szerverekre mért csapásokat gyakran ki lehet védeni a paramétereik ügyes beállításával, melyek segítségével korlátozni tudjuk az ezeket ért terhelést egy kellemetlenebb helyezetben. A nyers erõt alkalmazó hálózati támadásokkal a legnehezebb szembenézni. Például az álcázott támadadások, melyeket szinte lehetetlen megállítani, remek eszközök arra, hogy elvágják gépünket az internettõl. Ezzel viszont nem csak azt iktatják ki, hanem az internet-csatlakozásunkat is eldugítják. biztonság a hozzáférések megszerzése A DoS támadásoknál még gyakrabban elõfordul, hogy feltörik a felhasználók fiókjait. A rendszergazdák többsége még mindig futtat telnetd, rlogin, rshd és ftpd szervereket a gépen. Ezek a szerverek alapértelmezés szerint nem titkosított kapcsolaton keresztül mûködnek. Ebbõl következik, hogy ha nincs annyira sok felhasználónk és közülük néhányan távoli helyekrõl jelentkeznek be (ami az egyik leggyakoribb és legkényelmesebb módja ennek), akkor elõfordulhat, hogy valami megneszeli a jelszavaikat. A körültekintõ rendszergazdák mindig ellenõrzik a bejelentkezéseket tartalmazó naplókat és igyekeznek kiszûrni a gyanús címeket még abban az esetben is, amikor a bejelentkezés sikeres volt. Mindig arra kell gondolni, hogy ha a támadónak sikerült megszerezni az egyik felhasználó hozzáférését, akkor akár képes lehet a root felhasználó fiókjának feltörésére is. Azonban a valóságban egy jól õrzött és karbantarott rendszer esetén a felhasználói hozzáférések megszerzése nem feltétlenül adja a támadó kezére a root hozzáférését. Ebben fontos különbséget tenni, hiszen a root felhasználó jogai nélkül a támadó nem képes elrejteni a nyomait és legjobb esetben sem tud többet tenni, mint tönkretenni az adott felhasználó állományait vagy összeomlasztani a rendszert. A felhasználói fiókok feltörése nagyon gyakran megtörténik, mivel a felhasználók messze nem annyira elõvigyázatosak, mint egy rendszergazda. biztonság kiskapuk A rendszergazdáknak mindig észben kell tartani, hogy egy számítógépen több módon is meg lehet szerezni a root felhasználó hozzáférését. A támadó megtudhatja a root jelszavát, hibát fedezhet fel az egyik rendszergazdai jogosultsággal futó szerverben és képes feltörni a root hozzáférést egy hálózati kapcsolaton keresztül, vagy a támadó olyan programban talál hibát, aminek segítségével el tudja érni a root fiókját egy felhasználói hozzáférésen keresztül. Miután a támadó megtalálta a rendszergazdai jogok megszerzésének módját, nem feltétlenül kell kiskapukat elhelyeznie a rendszerben. Az eddig talált és javított, rendszergazdai jogok megszerzését lehetõvé tevõ biztonsági rések egy része esetében viszont a támadónak akkora mennyiségû munkát jelentene eltûntetni maga után a nyomokat, hogy megéri neki egy kiskaput telepíteni. Ennek segítségével a támadó ismét könnyedén hozzájuthat a root felhasználó hozzáféréséhez a rendszerben, de ezen keresztül egy okos rendszergazda képes is a behatolót leleplezni. A kiskapuk lerakásának megakadályozása valójában káros a biztonság szempontjából nézve, mert ezzel nem szüntetjük meg azokat a lyukakat, amin keresztül a támadó elõször bejutott. A támadások elleni védelmet mindig több vonalban kell megvalósítani, melyeket így oszthatunk fel: A rendszergazda és a személyzet hozzáférésének védelme. A rendszergazdai jogokkal futó szerverek és a suid/sgid engedélyekkel rendelkezõ programok védelme. A felhasználói hozzáférések védelme. A jelszavakat tároló állomány védelme. A rendszermag belsejének, a nyers eszközök és az állományrendszerek védelme. A rendszert ért szabálytalan módosítások gyors észlelése. Állandó paranoia. A fejezet most következõ szakaszában az imént felsorolt elemeket fejtjük ki részletesebben. A &os; védelme biztonság a &os; védelme Parancs kontra protokoll A dokumentumban a félkövéren fogjuk szedni az alkalmazásokat, és egyenszélességû betûkkel pedig az adott parancsokra hivatkozunk. A protokollokat nem különböztetjük meg. Ez a tipográfiai elkülönítés hasznos például az ssh egyes vonatkozásainak esetén, mivel ez egyben egy protokoll és egy parancs is. A most következõ szakaszok a &os; védelmének azon módszereit ismertetik, amelyekrõl a fejezet elõzõ szakaszában már írtunk. A rendszergazda és a személyzet hozzáférésének védelme su Elõször is: ne törjük magunkat a személyzeti fiókok biztonságossá tételével, ha még a rendszergazda hozzáférését sem tettük eléggé biztonságossá. A legtöbb rendszerben a root hozzáféréshez tartozik egy jelszó. Elsõként fel kell tennünk, hogy ez a jelszó mindig megszerezhetõ. Ez természetesen nem arra utal, hogy el kellene távolítanunk. A jelszó szinte mindig szükséges a számítógép konzolon keresztüli eléréséhez. Valójában arra szeretnénk rávilágítani, hogy a konzolon kívül sehol máshol ne lehessen használni ezt a jelszót, még a &man.su.1; paranccsal sem. Például gondoskodjunk róla, hogy az /etc/ttys állományban megadott pszeudó terminálokat insecure (nem biztonságos) típusúnak állítottuk be, és így a telnet vagy az rlogin parancsokon keresztül nem lehet rendszergazdaként bejelentkezni. Ha más szolgáltatáson keresztül jelentkezünk be, például az sshd segítségével, akkor ebben az esetben is gondoskodjunk róla, hogy letiltottuk a közvetlen rendszergazdai bejelentkezés lehetõségét. Ezt úgy tudjuk megtenni, ha megnyitjuk az /etc/ssh/sshd_config állományt és a PermitRootLogin paramétert átállítjuk a NO értékre. Vegyünk számba minden lehetséges hozzáférési módot — az FTP és a hozzá hasonló módok gyakran átszivárognak a repedéseken. A rendszergazdának csak a rendszerkonzolon keresztül szabad tudnia bejelentkeznie. wheel Természetesen egy rendszergazdának valahogy el kell érnie a root hozzáférést, ezért ezzel felnyitunk néhány biztonsági rést. De gondoskodjunk róla, hogy ezek a rések további jelszavakat igényelnek a mûködésükhöz. A root hozzáférés eléréséhez érdemes felvenni tetszõleges személyzeti (staff) hozzáféréseket a wheel csoportba (az /etc/group állományban). Ha a személyzet tagjait a wheel csoportba rakjuk, akkor innen a su paranccsal fel tudjuk venni a root felhasználó jogait. A személyzet tagjait létrehozásukkor közvetlenül sose vegyük fel a wheel csoportba! A személyzet tagjai elõször kerüljenek egy staff csoportba, és majd csak ezután az /etc/group állományon keresztül a wheel csoportba. A személyzetnek csak azon tagjait tegyük ténylegesen a wheel csoportba, akiknek valóban szükségük van a root felhasználó hozzáférésére. Ha például a Kerberost használjuk hitelesítésre, akkor megcsinálhatjuk azt is, hogy a Kerberos .k5login állományában engedélyezzük a &man.ksu.1; parancson keresztül a root hozzáférés elérését a wheel csoport alkalmazása nélkül. Ez a megoldás talán még jobb is, mivel a wheel használata esetén a behatolónak még mindig lehetõsége van hozzájutni a root hozzáféréséhez olyankor, amikor a kezében van a jelszavakat tároló állomány és meg tudja szerezni a személyzet valamelyik tagjának hozzáférését. A wheel csoport által felkínált megoldás ugyan jobb, mint a semmi, de kétségtelenül nem a legbiztonságosabb. A hozzáférések teljes körû letiltásához a &man.pw.8; parancsot érdemes használni: &prompt.root; pw lock személyzet Ezzel meg tudjuk akadályozni, hogy a felhasználó akármilyen módon, beleértve az &man.ssh.1; használatát is, hozzá tudjon férni a rendszerünkhöz. A hozzáférések blokkolásának másik ilyen módszere a titkosított jelszó átírása egyetlen * karakterre. Mivel ez a karakter egyetlen titkosított jelszóra sem illeszkedik, ezért a felhasználó nem lesz képes bejelentkezni. Ahogy például a személyzet alábbi tagja sem: izemize:R9DT/Fa1/LV9U:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh Erre cseréljük ki: izemize:*:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh Ezzel megakadályozzuk, hogy az izemize nevû felhasználó a hagyományos módszerekkel be tudjon jelentkezni. Ez a megoldás azonban a Kerberost alkalmazó rendszerek esetén nem mûködik, illetve olyan helyezetekben sem, amikor a felhasználó az &man.ssh.1; paranccsal már létrehozott magának kulcsokat. Az ilyen védelmi mechanizmusok esetében mindig egy szigorúbb biztonsági szintû géprõl jelentkezünk be egy kevésbé biztonságosabb gépre. Például, ha a szerverünk mindenféle szolgáltatásokat futtat, akkor a munkaállomásunknak egyetlen egyet sem lenne szabad. A munkaállomásunk biztonságossá tételéhez a lehetõ legkevesebb szolgáltatást szabad csak futtatnunk, de ha lehet, egyet sem, és mindig jelszóval védett képernyõvédõt használjuk. Természetesen ha a támadó képes fizikailag hozzáférni a munkaállomásunkhoz, akkor szinte bármilyen mélységû védelmet képes áttörni. Ezt mindenképpen számításba kell vennünk, azonban ne felejtsük el, hogy a legtöbb betörési kísérlet távolról, hálózaton keresztülrõl érkezik olyan emberektõl, akik fizikailag nem férnek hozzá a munkaállomásunkhoz vagy a szervereinkhez. KerberosIV A Kerberos és a hozzá hasonló rendszerek használatával egyszerre tudjuk a személyzet tagjainak jelszavát letiltani vagy megváltoztatni, ami egybõl érvényessé válik minden olyan gépen, ahová az adott felhasználónak bármilyen hozzáférése is volt. Nem szabad lebecsülnünk ezt a gyors jelszóváltási lehetõséget abban az esetben, ha a személyzet valamelyik tagjának hozzáférését megszerezték. Hagyományos jelszavak használatával a jelszavak megváltoztatása N gépen igazi káosz. A Kerberosban jelszóváltási megszorításokat is felállíthatunk: nem csak a Kerberos által adott jegyek járnak le idõvel, hanem a Kerberos rendszer meg is követelheti a felhasználóktól, hogy egy adott idõ (például egy hónap) után változtasson jelszót. A rendszergazdai jogokkal futó szerverek és SUID/SGID engedélyekkel rendelkezõ programok védelme ntalk comsat finger járókák sshd telnetd rshd rlogind A bölcs rendszergazda mindig csak akkor futtat szervereket, amikor szüksége van rá, se többet, se kevesebbet. Az egyéb fejlesztõktõl származó szerverekkel bánjunk különösen óvatosan, mivel gyakran hajlamosak hibákat tartalmazni. Például az imapd vagy a popper használata olyan, mintha az egész világnak ingyenjegyet osztogatnánk a rendszerünk root hozzáféréséhez. Soha ne futtassunk olyan szervert, amelyet nem vizsgáltunk át kellõ alapossággal. Sok szervert nem is feltétlenül kell root felhasználóként futtatni. Például az ntalk, comsat és finger démonok egy speciális járókában (sandbox) futnak. Ezek a járókák sem teljesen tökéletesek, hacsak erre külön figyelmet nem fordítunk. Ilyenkor a többvonalas védelem eszménye még mindig él: ha valakinek sikerült betörnie a járókába, akkor onnan ki is tud törni. Minél több védelmi vonalat húzunk a támadó elé, annál jobban csökken a sikerének valószínûsége. A történelem során lényegében minden root jogokkal futó szerverben, beleértve az alapvetõ rendszerszintû szervereket is, találtak már biztonsági jellegû hibát. Ha a gépünkre csak az sshd szolgáltatáson keresztül tudnak belépni, és soha nem használja senki a telnetd, rshd vagy rlogind szolgáltatásokat, akkor kapcsoljuk is ki ezeket! A &os; most már alapértelmezés szerint járókában futtatja az ntalkd, comsat és finger szolgáltatásokat. Másik ilyen program, amely szintén esélyes lehet erre, az a &man.named.8;. Az /etc/defaults/rc.conf megjegyzésben tartalmazza a named járókában futtatásához szükséges paramétereket. Attól függõen, hogy egy új rendszert telepítünk vagy frissítjük a már meglévõ rendszerünket, a járókákhoz tartozó speciális felhasználói hozzáférések nem feltétlenül jönnek létre. Amikor csak lehetséges, az elõrelátó rendszergazda kikísérletez és létrehoz ilyen járókákat. sendmail Vannak más olyan szerverek, amelyek tipikusan nem járókákban futnak. Ilyen többek közt a sendmail, popper, imapd, ftpd és még sokan mások. Léteznek rájuk alternatívák, de a telepítésük valószínûleg több munkát igényel, mint amennyit megérné számunkra veszõdni velük (és itt megint lesújt a kényelmi tényezõ). Ezeket a szervereket többnyire root felhasználóként kell futtatnunk és a rajtuk keresztül érkezõ betörési kísérleteket más módokra támaszkodva kell észlelnünk. A root felhasználó keltette biztonsági rések másik nagy csoportja azok a végrehajtható állományok a rendszerben, amelyek a suid és sgid engedélyekkel rendelkeznek, futtatásuk rendszergazdai jogokkal történik. Az ilyen binárisok többsége, mint például az rlogin, a - /bin és /sbin, - /usr/bin vagy - /usr/sbin könyvtárakban + /bin és /sbin, /usr/bin vagy /usr/sbin könyvtárakban található meg. Habár semmi sem biztonságos 100%-ig, a rendszerben alapértelmezetten suid és sgid engedéllyel rendelkezõ binárisok ebbõl a szempontból meglehetõsen megbízhatónak tekinhetõek. Alkalmanként azonban találnak a root felhasználót veszélyeztetõ lyukakat az ilyen binárisokban is. Például 1998-ban az Xlib-ben volt egy olyan rendszergazdai szintû hiba, amellyel az xterm (ez általában suid engedéllyel rendelkezik) sebezhetõvé vált. Mivel jobb félni, mint megijedni, ezért az elõretekintõ rendszergazda mindig igyekszik úgy csökkenteni az ilyen engedélyekkel rendelkezõ binárisok körét, hogy csak a személyzet tagjai legyenek képesek ezeket futtatni. Ezt egy olyan speciális csoport létrehozásával oldhatjuk meg, amelyhez csak a személyzet tagjai férhetnek hozzá. Az olyan suid binárisoktól pedig, amelyeket senki sem használ, igyekszik teljesen megszabadulni (chmod 000). A monitorral nem rendelkezõ szervereknek általában nincs szükségük az xterm mûködtetésére. Az sgid engedéllyel rendelkezõ binárisok is legalább ugyanennyire veszélyesek. Ha a behatoló képes feltörni egy kmem csoporthoz tartozó sgid binárist, akkor képes lesz olvasni a /dev/kmem állomány tartalmát, ezáltal hozzájut a titkosított jelszavakhoz és így megszerezheti magának akármelyik hozzáférést. Sõt, a kmem csoportot megszerzõ behatolók figyelni tudják a pszeudó terminálokon keresztül érkezõ billentyûleütéseket, még abban az esetben is, amikor a felhasználók egyébként biztonságos módszereket használnak. A tty csoportot bezsebelõ támadók szinte bármelyik felhasználó termináljára képesek írni. Ha a felhasználó valamilyen terminál programot vagy terminál emulátort használ a billentyûzet szimulációjával, akkor a behatoló tud olyan adatokat generálni, amivel a felhasználó nevében adhat ki parancsokat. A felhasználói hozzáférések védelme A felhasználók hozzáféréseit szinte a legnehezebb megvédeni. Míg a személyzet tagjaival szemben lehetünk kíméletlenül szigorúak és ki is csillagozhatjuk a jelszavukat, addig a felhasználók hozzáféréseivel általánosságban véve ezt nem tehetjük meg. Ha a kezünkben van a megfelelõ mértékû irányítás, akkor még gyõzhetünk és kényelmesen biztonságba helyezethetjük a felhasználók hozzáférését. Ha nincs, akkor nem tehetünk mást, mint állandóan õrködünk a hozzáférések felett. Az ssh és Kerberos használata a felhasználók esetén sokkalta problematikusabb, mivel ilyenkor jóval több adminisztrációra és mûszaki segítségnyújtásra van szükség, de még mindig jobb megoldás a titkosított jelszavakhoz képest. A jelszavakat tároló állomány védelme Az a legbiztosabb, ha minél több jelszót kicsillagozunk és a hozzáférések hitelesítésére ssh-t vagy Kerberost használunk. Igaz, a titkosított jelszavakat tároló állományt (/etc/spwd.db) csak a root képes olvasni, de a támadó meg tudja szerezni ezt a jogot még olyankor is, ha root felhasználóként nem feltétlenül tud írni. A rendszerünkben futó biztonsági szkripteknek a jelszavakat tároló állomány változását folyamatosan tudnia kell figyelnie és jelentie (lásd lentebb a Az állományok sértetlenségének ellenõrzése címû fejezetet). A rendszermag belsejének, a nyers eszközök és az állományrendszerek védelme Ha a támadó megszerzi a root hozzáférését, akkor szinte bármit képes megtenni, de vannak bizonyos elõnyei. Például a mostanság fejlesztett legtöbb rendszermag tartalmaz valamilyen beépített csomaglehallgatót, amit &os; alatt a bpf eszköz valósít meg. A támadók szinte mindig megpróbálnak valamilyen csomaglehallgatót használni a feltört gépen. A legtöbb rendszeren azonban nem kell feltétlenül megadnunk ezt az örömet, ezért nem is kell beépítenünk a rendszermagba a bpf eszközt. sysctl De ha még ki is iktatjuk a bpf eszközt, még aggódhatunk a /dev/mem és /dev/kmem miatt. Egyébként ami azt illeti, a behatoló még így is képes írni a nyers eszközökre. Sõt, a rendszermagba képesek vagyunk modulokat is betölteni a &man.kldload.8; használatával. A vállalkozó kedvû támadó a rendszermag moduljaként képes telepíteni és használni a saját bpf eszközét vagy bármilyen más, a csomagok lehallgatására alkalmas eszközt. Az ilyen problémák elkerülése érdekében a rendszermagot a legmagasabb védelmi szinten kell üzemeltetni, tehát legalább egyes szinten. A rendszermag védelmi szintjét több különbözõ módon lehet állítani. A védelmi szintet úgy lehet a legegyszerûbben növelni, ha a sysctl paranccsal beállítjuk a kern.securelevel nevû, rendszerszintû változó értékét: &prompt.root; sysctl kern.securelevel=1 A &os; rendszermag alapértelmezés szerint a -1 védelmi szinten indul. Ez egészen addig -1 marad, amíg a rendszergazda vagy valamelyik &man.init.8; során hívott rendszerindító szkript ezt meg nem változtatja. A rendszer indítása során úgy tudjuk beállítani a megfelelõ védelmi szintet, ha az /etc/rc.conf állományban megadjuk a kern_securelevel_enable változót a YES értékkel, illetve kern_securelevel értékeként a kívánt védelmi szintet. A &os; alapértelmezett védelmi szintje közvetlenül a rendszerindító szkriptek lefutása után -1. Ezt nem biztonságos módnak nevezik, mivel az állományok írásáért felelõs állományjelzõk nem feltétlenül mûködnek, mindegyik eszköz írható, olvasható és a többi. Miután a védelmi szintet 1 vagy annál magasabb értékre állítottuk, akkor a rendszer figyelembe veszi a csak hozzáfûzést (append-only) és módosíthatatlanságot (immutable) megszorító állományjelzõket, nem engedélyezi a tiltásukat és az eszközök közvetlenül nem érhetõek el. A különbözõ védelmi szintek részletesebb bemutatását a &man.security.7; man oldalon olvashatjuk (vagy a &os; 7.0 elõtti változataiban a &man.init.8; man oldalon). Az 1 és az afeletti védelmi szinteken többek közt az X11 nem feltétlenül lesz futtatható (mivel a /dev/io eszköz elérése blokkolt), illetve a rendszer frissítése is akadályokba fog ütközni (a installworld futtatása során ideiglenesen ki kell kapcsolni az append-only és immutable állományjelzõket). Az X11 esetében ezt valahogy még ki lehet kerülni úgy, hogy ha az &man.xdm.1; démont még a rendszerindítás elején aktiváljuk (amikor a védelmi szint még kellõen alacsony). Az összes védelmi szint és megszorítás esetén azonban nem mindig adható ilyen jellegû javaslat, ezért ilyenkor mindig érdemes elõre tervezni egy keveset. Emellett fontos alaposan megismerni a különbözõ védelmi megszorításokat, mivel jelentõs mértékben visszafoghatják a rendszer használhatóságát. Ez segít az adott helyzetben az egyszerûbb megoldást választani és ezáltal elkerülni a kellemetlen meglepetéseket. Ha a rendszermag védelmi szintjét az 1 érték vagy afelé emeljük, akkor hasznos lehet a fontosabb (lényegében minden olyan programnak, amely a védelmi szint helyes beállítódása elõtt lefut) programoknak, könyvtáraknak és szkripteknek beállítani az schg állományjelzõt. Ilyenkor azonban vegyük figyelembe, hogy a rendszer frissítése is nehezebbé válik a magasabb védelmi szinteken. Egy mûködõképesebb megoldás lehet, ha rendszerünket egy magasabb védelmi szinten használjuk, de nem állítjuk be mindegyik rendszerszintû állományra az schg állományjelzõt. Másik - lehetõség még a / - és /usr partíciók + lehetõség még a / és /usr partíciók írásvédett csatlakoztatása. Ne felejtsük el azonban, hogy ha túlságosan szigorúak vagyunk magunkhoz, akkor azzal egyúttal a behatolás észlelését is meg tudjuk nehezíteni! Az állományok sértetlenségének ellenõrzése: binárisok, konfigurációs állományok stb. Ha arról van szó, csak a legfontosabb rendszerszintû konfigurációs- és vezérlõállományokat tudjuk megvédeni, még mielõtt a korábban emlegetett kényelmi tényezõ kimutatná a foga fehérjét. Például, ha a chflags paranccsal beállítjuk az schg állományjelzõt a - / és /usr + / és /usr állományrendszereken található legtöbb állományra, akkor az minden bizonnyal csökkenti a hatékonyságunkat, hiszen az állományok védelmének növekedésével csökken az észlelés lehetõsége. A védelmi vonalaink közül ugyanis az utolsó talán az egyik legfontosabb — a detektálás. A felépített biztonsági rendszerünk legnagyobb része szinte teljesen hasztalan (vagy ami még rosszabb, a biztonság hamis érzetét kelti), ha nem vagyunk képesek észrevenni a betörési kísérleteket. A védelmi rendszer egyik részére nem a támadó megállításához, hanem a lelassításához van szükség, hogy így majd munka közben érhessük tetten. A betörés tényét legjobban a megváltozott, hiányzó vagy éppen váratlanul felbukkanó állományok utáni kutatással tudjuk felismerni. A módosított állományokat általában egy másik (gyakran központosított) korlátozott hozzáférésû rendszerbõl ellenõrizhetjük a legjobban. Fontos, hogy ha egy korlátozott hozzáférésû, kiemelten védett rendszeren írjuk a védelemért felelõs szkripteket, akkor azok szinte teljesen láthatlanok lesznek a támadó számára. A legjobb kihasználás érdekében a korlátozott hozzáférésû gépnek jelentõs mértékû rálátással kell rendelkeznie az összes többi gépre, amit írásvédett NFS exportok vagy ssh kulcspárok felhasználásával érhetünk el. A hálózati forgalmat leszámítva az NFS látszik a legkevésbé — segítségével lényegében észrevétlenül tudjuk figyelni az egyes gépek állományrendszereit. Ha a megfigyelésre használt szerver a kliensekhez switchen keresztül csatlakozik, akkor az NFS gyakran jobb választásnak bizonyul. Ha a szerver hubon vagy több hálózati elemen keresztül éri el a megfigyelni kívánt klienseket, akkor az NFS nem eléggé biztonságos (és hatékony), ezért ilyen esetekben az ssh választása lehet a kedvezõ még az ssh által hagyott nyomokkal együtt is. Miután a korlátozott hozzáférésû gépünk legalább látja a hozzátartozó kliensek rendszereit, el kell készítenünk a tényleges monitorozást végzõ szkripteket. Ha NFS csatlakozást tételezünk fel, akkor az olyan egyszerû rendszereszközökkel, mint például a &man.find.1; és &man.md5.1; képesek vagyunk összerakni ezeket. A szemmel tartott kliensek állományait naponta legalább egyszer érdemes ellenõrizni md5-tel, valamint még ennél gyakrabban is tesztelni az - /etc és - /usr/local/etc könyvtárakban - található konfigurációs és + /etc és /usr/local/etc + könyvtárakban található + konfigurációs és vezérlõállományokat. Ha valamilyen eltérést tapasztal az ellenõrzést végzõ szerverünk és a rajta levõ md5 információk is helyesek, akkor értesítenie kell a rendszergazdát. Egy jó védelmi szkript képes megkeresni az oda nem illõ suid binárisokat, valamint az új - vagy törölt állományokat a - / és a /usr + vagy törölt állományokat a / és a /usr partíciókon. A védelmi szkriptek megírása valamivel nehezebb feladat, ha ssh-t használunk az NFS helyett. A futtatásukhoz a szkripteket és az általuk használt eszközöket (például find) az scp paranccsal lényegében át kell másolni a kliensekre, amivel így láthatóvá válnak. Ne feledjük továbbá, hogy az ssh kliens már eleve feltört lehet. Szó, ami szó, ha nem megbízható összeköttetésekrõl beszélünk, akkor az ssh használata elkerülhetetlen, de nem feltétlenül egyszerû. Egy jó védelmi szkript észreveszi a felhasználók és a személyzet tagjainak hozzáférését vezérlõ állományokban, mint például az .rhosts, .shosts, .ssh/authorized_keys és társaiban keletkezett változásokat is, amelyek esetleg elkerülhetik egy MD5 alapú ellenõrzés figyelmét. Ha netalán órási mennyiségû tárterületettel rendelkeznénk, akkor eltarthat egy ideig, amíg végigsöprünk az összes partíció összes állományán. Ebben az esetben érdemes olyan beállításokat megadni az állományrendszerek csatlakoztatásánál, amivel le tudjuk tiltani a suid engedéllyel rendelkezõ binárisok futtatását. Ezzel kapcsolatban a &man.mount.8; parancs nosuid opcióját nézzük meg. Hetente legalább egyszer azért mégis érdemes átnézni az ilyen partíciókat is, mivel ez a réteg a betörési kísérletek felderítésével foglalkozik, függetlenül a sikerességüktõl. A futó programok nyilvántartása (lásd &man.accton.8;) egy olyan viszonylag kevés költséggel járó lehetõség az operációs rendszerben, ami segítségünkre lehet a betörés utáni események kiértékelésében. Különösen hasznos olyankor, amikor megpróbáljuk modellezni, miképp is sikerült a támadónak bejutnia a rendszerünkbe, természetesen feltételezve, hogy az ehhez felhasznált feljegyzések a betörés után is érintetlenek maradtak. Végül a védelmet ellátó szkripteknek javasolt feldolgozni a naplóállományokat is, valamint a naplókat magukat is a lehetõ legbiztonságosabb formában generálni — ilyenkor nagyon hasznos lehet, ha egy távoli gépre naplózunk. A behatoló megpróbálja majd eltüntetni a nyomait, a naplóállományok viszont nagyon fontosak a rendszergazda számára a betörési kísérletek idejének és módjának megállapításában. A naplókat úgy tudjuk tartósan rögzíteni, ha a rendszerkonzol üzeneteit soros porton keresztül gyûjtjük össze a konzolok felügyeletéért felelõs biztonságos gépen. Állandó paranoia Egy kis paranoia sosem árt. Elmondható, hogy a rendszergazda tetszõleges számú biztonsági intézkedéssel élhet egészen addig, amíg az nincs hatással a kényelmére, és a kényelmet befolyásoló biztonsági intézkedéseket pedig megfelelõ mérlegelés mellett tegye meg. Ami még ennél is fontosabb, hogy mindig változtassunk valamit a biztonsági hálónkon — mivel ha egy az egyben követjük a dokumentumban leírtakat, akkor ezzel együtt kiadjuk a bejutás receptjét annak a leendõ támadónknak, aki szintén elolvasta ugyanezt. A szolgáltatások mûködésképtelenné tételét célzó támadások Denial of Service (DoS) Ez a szakasz a szolgáltatások mûködésképtelenségét elérni kívánó, más néven Denial of Service típusú támadásokkal foglalkozik. Noha nem tudunk túlságosan sokat tenni a manapság felbukkanó álcázott, a hálózatunk totális leterhelését célbavevõ támadások ellen, akadnak olyan általános érvényû eszközök, amelyekkel elejét vehetjük a szervereink szétbomzásának: A létjövõ szerverpéldányok korlátozása. Az ugródeszkaszerû támadások (támadás ICMP-válasszal, pingszórás stb.) korlátozása. A rendszermag útválasztási gyorsítótárának túlterhelése. A DoS támadások egyik jellemzõ sémája szerint egy sokszorozódni képes szervert támadnak meg, amelynek igyekeznek minél több példányát legyártatni, míg végül az ezt futtató rendszer ki nem fogy a memóriából, állományleíróból satöbbibõl és megállásra nem kényszerül. Az inetd (lásd &man.inetd.8;) számos lehetõséget kínál fel ennek megakadályozására. Ezzel kapcsolatban szeretnénk megjegyezni, hogy bár ezzel el tudjuk kerülni a gépünk leállását, semmilyen garanciát nem ad arra, hogy a szolgáltatás a támadás során is zavartalanul üzemel tovább. Alaposan olvassuk el az inetd man oldalát és legyünk különös tekintettel a , és kapcsolóira. Vigyázzunk, hogy az inetd kapcsolóját képesek kijátszani az álcázott IP-vel érkezõ támadások, ezért inkább az elõbbi kapcsolók valamilyen kombinációja az ajánlott. Egyes szerverprogramoknál be lehet állítani a példányainak maximális számát. A Sendmail rendelkezik egy beállítással, ami a terhelésben levõ késleltetése miatt néha mintha jobban beválna, mint a Sendmail terheléskorlátozó paraméterei. A Sendmail indításakor tehát a MaxDaemonChildren paramétert javasolt megadni egy olyan értékkel, amely elegendõ a Sendmail számára betervezett terhelés kiszolgálására, de még kevés ahhoz, hogy a Sendmail fûbe harapjon tõle. Továbbá bölcs dolog a Sendmailt várakozási sorral () és démonként (sendmail -bd), külön feldolgozási menetekkel (sendmail -q15m) futtatni. Ha továbbra is valós idejû kézbesítést akarunk, akkor a feldolgozást kisebb idõközökkel is lefuttathatjuk (például ), de arra mindig ügyeljünk, hogy a MaxDaemonChildren beállítása ne okozzon kaszkádosítási hibákat a Sendmail mûködésében. A Syslogd közvetlenül is támadható, ezért határozottan javasoljuk a használatát, amikor csak lehet, minden más esetben pedig a beállítást. Fordítsunk kellõ figyelmet a TCP kapcsolatok burkolását végzõ TCP Wrapper reverse-ident lehetõségére, ami szintén közvetlenül támadható. Ebbõl az okból kifolyólag valószínûleg nem is akarjuk a TCP Wrapper által felkínált reverse-ident-et használni. Jól járunk el abban az esetben, ha a belsõ szolgáltatásainkat az útválasztóink mentén tûzfal segítségével védjük meg a külsõ hozzáféréstõl. Ezzel lényegében a helyi hálózatunkat kívülrõl fenyegetõ támadások ellen védekezünk, de ez nem nyújt elegendõ védelmet a belsõ szolgáltatásaink esetén a root hozzáférés megszerzésére irányuló kísérletek ellen. Mindig egy exkluzív, tehát zárt tûzfalat állítsunk be, vagyis tûzfalazzunk mindent kivéve az A, B, C, D és M-Z portokat. Ezen a módon ki tudjuk szûrni az összes alacsonyabb portot, kivéve bizonyos eseteket, mint például a named (ha az adott zónában ez az elsõdleges gép), ntalkd, sendmail vagy más interneten keresztül elérhetõ szolgáltatásokat. Ha másképpen állítjuk a tûzfalat — inkluzív, nyílt avagy megengedõ módon, akkor jó eséllyel elfelejtünk lezárni egy csomó szolgáltatást, vagy úgy adunk hozzá egy új belsõ szolgáltatást, hogy közben elfelejtjük frissíteni a tûzfalat. Ennél még azon is jobb, ha a tûzfalon nyitunk egy magasabb portszámú tartományt, és ott valósítjuk meg ezt a megengedõ jellegû mûködést, az alacsonyabb portok veszélybe sodrása nélkül. Vegyük azt is számításba, hogy a &os;-ben a kiosztott portokat dinamikusan állíthatjuk a net.inet.ip.portrange sysctl változókon keresztül (sysctl -a | fgrep portrange), ami nagyságrendekkel megkönnyíti a tûzfal beállítását. Ennek megfelelõen például meg tudjuk adni, hogy a 4000-tõl 5000-ig terjedõ porttartomány a 49152-tõl 65535-ig húzódó tartományba kerüljön át, majd a 4000 alatti összes portot blokkoljuk (természetesen az internetrõl szándékosan hozzáférhetõ portok kivételével). A DoS támadások másik elterjedt fajtája az ún. ugródeszka támadás — ilyenkor a szervert úgy próbálják túlterhelni, hogy folyamatosan válaszokat kérnek tõle a helyi hálózatról vagy egy másik számítógéprõl. Az ilyen természetû támadások közül is a legnépszerûbb az ICMP pingszórásos támadás. A támadó olyan ping csomagokat küld szét a helyi hálózaton, amelyek forrásának azt a gépet jelöli meg, amelyiket meg akarja támadni. Ha a hálózatokat elválasztó útválasztók nem fogják meg a pingszórást, akkor a helyi hálózatról összes gépe nekilát válaszolgatni a meghamisított forrás címére, amivel így teljesen leterhelik az áldozatot. Ez különösen akkor hatásos, amikor a támadó ugyanezt a trükköt eljátssza egyszerre több tucat különbözõ hálózatban is. Az üzenetszórással járó támadások akár százhúsz megabitnyi forgalmat is képesek generálni másodpercenként. A második legelterjedtebb ugródeszkás támadás az ICMP hiba-visszajelzési rendszere ellen irányul. Ilyenkor a támadó ICMP hibaüzeneteket kiváltó csomagok készítésével képes eltömíteni egy szerver bejövõ hálózati kapcsolatát és az ICMP válaszokkal pedig a szerver maga dugítja el a kimenõ hálózati kapcsolatát. Ez a fajtájú támadás képes kinyomni az összes memóriát a szerverbõl és ezzel összeomlasztani, különösen olyankor, amikor a szerver nem tudja elég gyorsan elnyelni az általa generált ICMP válaszokat. A net.inet.icmp.icmplim sysctl változóval tudunk gátat szabni a támadások ezen fajtájának. Az ugródeszkás támadások utolsó nagyobb osztálya az inetd olyan szolgáltatásait szemeli ki, mint például az udp echo. A támadó ilyenkor egyszerûen küld a helyi hálózatunkon található A és B szerverünknek egy olyan UDP csomagot, ahol forrásként az A szerver echo portját adja meg, célnak pedig a B szerver echo portját. Ezután a két szerver elkezdi egymás között passzolgatni ezt az egyetlen csomagot. A támadó még több ilyen csomag befecskendezésével pillanatok alatt képes leterhelni a két szervert és helyi hálózatot. Hasonló problémák vannak a belsõ chargen portjával is. Egy hozzáértõ rendszergazda ezért kikapcsolja az összes ilyen inetd-alapú belsõ tesztelõ szolgáltatást. Az álcázott csomagok felhasználhatóak a rendszermag útválasztó gyorsítótárának túlterhelésére is. Ezzel kapcsolatban nézzük meg a net.inet.ip.rtexpire, rtminexpire és rtmaxcache sysctl változókat. A véletlenszerû IP-címekkel megcímzett álcázott csomagok hatására a rendszermag létrehoz mindegyikõjükhöz egy ideiglenesen pufferelt utat az útválasztó táblázatában, amelyet a netstat -rna | fgrep W3 paranccsal tudunk lekérdezni. Az ilyen útvonalak nagyjából 1600 másodperc múlva elévülnek. Ha a rendszermag észleli, hogy a gyorsítótárazott útválasztási táblázat mérete túlságosan megnövekedett, akkor automatikusan csökkenti az rtexpire értékét, de soha nem megy a rtminexpire alá. Ebbõl két probléma adódik: A rendszermag nem reagál elég gyorsan amikor egy alig terhelt szervert hirtelen megtámadnak. Az rtminexpire nem elég kicsi ahhoz, hogy a rendszermag túléljen egy tartósabb rohamot. Ha a szervereink az internethez T3 (kb. 45 Mbit/s) vagy gyorsabb összeköttetésen keresztül csatlakoznak, akkor határozottan javasolt kézileg behangolni a &man.sysctl.8; segítségével az rtexpire és az rtminexpire értékeket. Soha ne állítsuk egyiket sem nullára (hacsak nem akarjuk összeomlasztani a gépünket). Ha például mind a kettõt 2 másodpercre állítjuk, akkor az többnyire elegendõ az útválasztási táblázat megvédéséhez. Hozzáférés Kerberosszal és SSH-val ssh KerberosIV Van néhány dolog, amit a Kerberos és az ssh esetén ajánlatos tisztázni, mielõtt használjuk ezeket. A Kerberos 5 egy kifogástalan hitelesítési protokoll. A telnet és rlogin Kerberos által módosított változatában vannak olyan hibák, amelyek alkalmatlanná teszik ezeket a bináris adatfolyamok helyes kezelésére. Sõt, alapértelmezés szerint a Kerberos nem titkosítja a kapcsolatot, csak ha megadjuk neki a kapcsolót. Az ssh alapértelmezés szerint mindent titkosít. Az ssh minden szempontból nagyon jól teljesít kivéve, hogy alapértelmezés szerint átküldi a kulcsokat is. Ez azt jelenti, hogy ha van egy olyan biztonságos munkaállomásunk, ahol a rendszer többi részéhez tartozó kulcsainkat tartjuk és egy nem biztonságos gépre akarunk vele ssh-n keresztül belépni, akkor a kulcsaink használatóvá válnak. A tényleges kulcsokat ugyan nem látja senki, de a bejelentkezés során az ssh megnyit egy közvetítéshez használt portot, amit a nem biztonságos gépen a támadó egy feltört root hozzáférés birtokában ki tud használni úgy, hogy a kulcsaink segítségével hozzá tudjon férni egy másik olyan géphez, amelyet a kulcsok nyitnak. Ha lehetséges, akkor a személyzet bejelentkeztetéséhez az ssh-t és Kerberost együttesen használjuk. Az ssh lefordíható Kerberos támogatással. Ezzel csökkentjük a potenciálisan kiszivárgó ssh kulcsok esélyét, miközben jelszavainkat a Kerberosszal védjük. Az ssh kulcsokat csak biztonságos gépekrõl és csak automatizált feladatok esetén használjuk (amire a Kerberos lényegében nem alkalmas). Emellett javasoljuk azt is, hogy az ssh beállításai között tiltsuk le a kulcsok átküldését (key forwarding) vagy használjuk az from=IP/DOMAIN opciót, amivel az ssh csak a megadott gépekrõl engedi az authorized_keys állomány és a így benne levõ kulcsok használatát. Bill Swingle Egyes részeit újraírta és aktualizálta: DES, Blowfish, MD5 és a Crypt biztonság crypt crypt Blowfish DES MD5 Minden &unix; rendszer használójához tartozik egy jelszó is a hozzáféréséhez. Teljesen nyilvánvalónak tûnik, hogy ezt a jelszót csak az adott felhasználó és az adott operációs rendszer ismeri. A jelszavakat a titokban tartásukhoz ún. csapóajtó függvényekkel titkosítják, amelyeket könnyû titkosítani, ám nehéz visszafejteni. Tehát amit egy perccel ezelõtt még nyilvalónak tituláltunk, az mostanra már nem is teljesen igaz: valójában az operációs rendszer sem ismeri a jelszót. Az operációs rendszer csak a jelszó titkosított változatát ismeri. A jelszó titkosítatlan formáját csak nyers erõ igényebevételével tudjuk megkeresni az összes lehetséges jelszó szénakazlában. Sajnos, annak idején, amikor a jelszavak titkosítása bekerült a &unix;-ba, egyedül a DES, vagy más néven a Data Encryption Standard (Adattitkosítási szabvány) jött szóba. Ez alapvetõen nem jelentett problémát az Egyesült Államok állampolgárai számára, de mivel a DES forráskódját nem lehetett kivinni az Egyesült Államokból, a &os;-nek találnia kellett valami olyasmit, ami mind megfelel az Egyesült Államok törvényeinek, mind pedig kompatibilis marad az összes többi DES-t használó &unix; variánssal. Ezt úgy oldották meg, hogy felosztották a titkosítással foglalkozó függvénykönyvtárakat, így az Egyesült Államokban élõ felhasználók tudtak DES könyvtárakat telepíteni és használni, miközben a többi nemzet felhasználói olyan más titkosítási módszert tudtak választani, amit kinn is lehetett alkalmazni. Ennek tulajdonítható, hogy a &os; alapértelmezés szerint az MD5 segítségével titkosít. Az MD5-öt a DES-nél sokkalta biztonságosabbnak tartják, ezért a DES telepítésének lehetõségét leginkább csak kompatibilitási okokból ajánlották fel. A titkosítási mechanizmus azonosítása Jelenleg a könyvtár ismeri a DES, MD5 és Blowfish függvényeit. A &os; a jelszavak titkosításához alapból az MD5-öt használja. Nagyon könnyen meg tudjuk mondani, hogy a &os; éppen melyik titkosítási módszert alkalmazza. Ennek egyik lehetõsége, ha az /etc/master.passwd állományt vizsgáljuk meg. Az MD5 függvényével titkosított jelszavak hosszabbak, mint a DES függvényével titkosítottak és a $1$ karakterekkel kezdõdnek. A $2a$ karakterekkel kezdõdõ jelszavakat Blowfish-sel titkosították. A DES kódolású jelszavaknak nincs semmilyen különleges ismertetõjelük, de általánosságban elmondható róluk, hogy rövidebbek az MD5 jelszavaknál és olyan 64 karakteres ábécével kódolják ezeket, amelyek nem tartalmazzák a $ karaktert, így tehát a viszonylag rövid, nem dollárjellel kezdõdõ karakterláncok minden bizonnyal DES kódolású jelszavak. Az új jelszavak kódolásához használt formátumot az /etc/login.conf állományban tárolt passwd_format bejelentkezési tulajdonság adja meg, amelynek értékei des, md5 vagy blf lehetnek. A &man.login.conf.5; man oldalon tájékozódhatunk bõvebben a bejelentkezési tulajdonságokról. Egyszeri jelszavak egyszeri jelszavak biztonság egyszeri jelszavak A &os; alapértelmezés szerint támogatja az OPIE-t (One-time Passwords In Everything, azaz Egyszeri jelszavak mindenben), ami alapból az MD5 függvényét használja. A jelszavak három fajtáját fogjuk a továbbiakban tárgyalni. Az elsõ a megszokott &unix; stílusú avagy Kerberos jelszó. Ezt a továbbiakban &unix; jelszónak nevezzük. A második fajtában az OPIE &man.opiekey.1; nevû segédprogramja által generált és a bejelentkezésnél a &man.opiepasswd.1; által elfogadott jelszavak tartoznak. Ezeket egyszeri jelszavaknak fogjuk nevezni. A jelszavak utolsó típusa az a titkos jelszó, amit az opiekey programnak (és néha a opiepasswd programnak) adunk meg, ami ebbõl egyszer használatos jelszavakat állít elõ. Ezt innentõl titkos jelszónak vagy csak egyszerûen jelszónak hívjuk. A titkos jelszónak semmi köze sincs a &unix; jelszavunkhoz. Természetesen megegyezhetnek, de ezt nem ajánljuk. Az OPIE által használt titkos jelszavaknak nem kell a régi &unix; jelszavakhoz hasonlóan legfeljebb 8 karakteresnek lenniük &os; alatt a bejelentkezéshez használt szabványos jelszavak akár 128 karakteresek is lehetnek. , bármekkorát használhatunk. A hat vagy hét szóból álló jelszavak ilyenkor igen gyakoriak. Az OPIE jobbára a &unix; jelszórendszerétõl teljesen függetlenül mûködik. A jelszavak mellett két másik fajta adat fontos az OPIE számára. Közülük az egyiket magnak vagy kulcsnak nevezik, ami két betûbõl és öt számjegybõl áll. A másik az iterációk száma, ami egy 1 és 100 közötti számot takar. Az OPIE úgy hozza létre az egyszeri jelszavakat, hogy egymás után fûzi a magot és a titkos jelszót, majd az iterációk megadott számának megfelelõ mennyiségben kiszámolja rá az MD5 függvény értékét és az eredményt hat rövid angol szóba önti. Ez a hat angol szó lesz a mi egyszeri jelszavunk. A hitelesítéssel foglalkozó rendszer (elsõsorban a PAM) figyelemmel kíséri a legutoljára használt egyszeri jelszavunkat, és csak akkor engedi a felhasználót hitelesíteni, ha az általa megadott jelszó kódolt változata megegyezik az elõzõleg megadott jelszaváéval. A csapóajtó függvények használata miatt lehetetlen legenerálni a következõ egyszeri jelszót, ha a sikerült megszereznünk az egyiket. Az iterációk száma minden egyes sikeres bejelentkezés után csökken eggyel, amivel a felhasználót és a bejelentkeztetõ programot szinkronban tartja. Amikor így az iterációk száma eléri az egyet, az OPIE-t újra kell inicializálni. Az említésre kerülõ rendszerek mindegyikéhez tartozik néhány program. Az opiekey bekéri az iterációk számát, a magot és a titkos jelszót, majd elõállít egy egyszer használatos jelszót vagy azok folytonos listáját. Az opiepasswd az OPIE inicializálásért, a jelszavak, az iterációk számának és a mag megváltoztatásáért felelõs. Egyaránt elfogad titkos jelmondatot, iterációs számot vagy magot és egy egyszeri jelszót. Az opieinfo megvizsgálja a felhasználókra vonatkozó adatbázist (/etc/opiekeys) és kiírja az adott felhasználó által használt iterációs számot és magot. Négyféle különbözõ mûveletrõl fogunk most itt beszélni. Az elsõben egy biztonságos kapcsolaton keresztül elsõként inicializáljuk az egyszeri jelszavakat, vagy megváltoztatjuk a jelszót vagy a magot az opiepasswd segítségével. A második mûveletben ugyanarra adjuk ki az opiepasswd parancsot egy nem biztonságos kapcsolaton keresztül az opiekey paranccsal együtt egy biztonságos kapcsolaton keresztül. A harmadikban az opiekey használatával nem biztonságos kapcsolaton keresztül jelentkezünk be. A negyedikben az opiekey paranccsal létrehozunk egy adott mennyiségû kulcsot, amelyeket aztán leírhatunk vagy kinyomtathatunk, hogy magunkkal tudjuk vinni olyan helyre, ahonnan nem tudnk biztonságos módon csatlakozni. Inicializálás biztonságos kapcsolattal Az OPIE elsõ inicializálásához adjuk ki az opiepasswd parancsot: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED A figyelmeztetés fordítása: Ezt a módszert csak konzolról alkalmazzuk, SOHA ne távoli kapcsolaton keresztül! Ha telnetet, xtermet vagy betárcsázós kapcsolatot használunk, akkor azonnal nyomjunk ^C-t vagy ne adjunk meg jelszót. Az Enter new secret pass phrase: vagy Enter secret password: kérdések után adjunk meg egy jelmondatot, illetve jelszót. Ne felejtsük el, hogy ez nem bejelentkezéshez használt jelszó lesz, hanem ebbõl jönnek majd létre az egyszeri kulcsaink. Az ID sor adja meg az aktuális példányunk paramétereit: a bejelentkezéshez használt nevünket, az iterációk számát és a magot. Amikor a bejelentkezések során a rendszer emlékszik a paraméterekre és megjeleníti ezeket, nem kell megjegyeznünk. Az utolsó sor adja meg a paramétereinknek és a titkos jelszavunknak megfelelõ egyszeri jelszót. Ha most azonnal akarnánk bejelentkezni, akkor ezt az egyszeri jelszót kellene hozzá használnunk. Inicializálás nem biztonságos kapcsolattal Ha egy nem biztonságos kapcsolaton keresztül akarjuk inicializálni vagy megváltoztatni a jelszavunkat, akkor szükségünk lesz valahol egy megbízható kapcsolatra, ahol le tudjuk futtatni az opiekey parancsot. Ez lehet egy számunkra biztonsági szempontból elfogadható gép parancssora. Emellett ki kell találnunk egy iterációs számot (erre a 100 egy jó választás) és adnunk egy magot vagy használni egy véletlenszerûen generáltat. Az inicializálás színtere felé vezetõ nem biztonságos kapcsolaton keresztül adjuk ki az opiepasswd parancsot: &prompt.user; opiepasswd Updating unfurl: You need the response from an OTP generator. Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY Az alapértelmezett mag elfogadásához nyomjuk le a Return billentyût. Mielõtt megadnánk a hozzáférés jelszavát, menjünk át a biztonságos kapcsolatra és adjuk meg neki ugyanezeket a paramétereket: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Most váltsunk vissza a nem biztonságos kapcsolatra és másoljuk be az így generált egyszeri jelszót a megfelelõ programba. Egyetlen egyszeri jelszó létrehozása Miután sikeresen inicializáltuk az OPIE-t és bejelentkezünk, a következõket láthatjuk: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: felhasználói_név otp-md5 498 gr4269 ext Password: Mellékesen megjegyezzük, hogy az OPIE paranccsorának van egy (itt nem látható) hasznos képessége: ha Return billentyût nyomunk a jelszó bekérésekor, akkor a program megmutatja a begépelt betûket, így láthatjuk pontosan mit is írunk be. Ez nagyon kényelmes lehet olyankor, amikor valahonnan, például egy lapról olvassuk a jelszót. MS-DOS Windows MacOS A bejelentkezéshez ekkor le kell valahogy generálnunk az egyszeri jelszavunkat. Ezt egy megbízható rendszeresen tudjuk megtenni az opiekey lefuttatásával. (Ennek vannak DOS-os, &windows;-os és &macos;-es változatai is.) Paraméterként az iterációs számot és a magot kell megadnunk. Ezt akár közvetlenül át is másolhatjuk annak a gépnek a bejelentkezési képernyõjérõl, ahova be akarunk jelentkezni. A megbízható rendszeren tehát: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Most már megvan a bejelentkezéshez szükséges egyszeri jelszavunk. Több egyszeri jelszó létrehozása Néha olyan helyekre kell mennünk, ahol se egy megbízható gép, sem pedig biztonságos kapcsolat nem található. Ilyen esetekben megadhatjuk az opiekey parancsnak, hogy elõre gyártson le több egyszer használatos jelszót, amit késõbb aztán ki tudunk nyomtatni. Például: &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: <secret password> 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI Az öt kulcsot kér egymás után, a pedig megadja az utolsó iterációs számot. Vegyük észre, hogy a kulcsokat a felhasználás sorrendjével ellentétes sorrendben írja ki a program. Ha igazán paranoiások vagyunk, akkor írjuk le kézzel a jelszavakat. Ha viszont annyira nem, akkor egyszerûen küldjük át ezeket az lpr parancsnak. Megfigyelhetjük, hogy minden sorban látható az iterációs szám és a hozzátartozó egyszeri jelszó. Hasznos lehet a felhasználás szerinti felírni a jelszavakat. A &unix; jelszavak használatának leszûkítése Az OPIE képes a bejelentkezéshez használt IP-címek alapján leszûkíteni a &unix; jelszavak használatát. Ehhez az /etc/opieaccess használható, amely alapból megtalálható a rendszerünkön. Az &man.opieaccess.5; man oldalán találhatjuk meg a rá vonatkozó információkat és az összes vele kapcsolatos biztonsági megfontolást. Íme egy példa az opieaccess állományra: permit 192.168.0.0 255.255.0.0 Ezzel a sorral megengedjük a &unix; jelszavak használatát minden olyan felhasználó számára, akinek az IP-je illeszkedik a megadott címre és maszkra (ez viszont álcázással kijátszható). Ha az opieaccess állományból egyetlen szabály sem illeszkedik, akkor alapértelmezés szerint nem engedélyezettek a nem OPIE típusú jelszavak. Tom Rhodes Írta: TCP burkolók A TCP kapcsolatok burkolása Aki ismeri az &man.inetd.8; programot, az már biztosan hallott a TCP kapcsolatok burkolásáról, eredeti nevén a a TCP wrapperekrõl. Azonban csak kevesek képesek felfogni ezek valódi hasznát. Úgy néz ki, mindenki csak tûzfalakon keresztül akarja megoldani a hálózati kapcsolatot kezelését. Habár a tûzfalakat sok mindenre fel lehet ugyan használni, egyetlen tûzfal nem képes például szövegesen válaszolni a kapcsolatok kezdeményezõinek. Ellenben bármelyik TCP-wrapper szoftver képes erre, sõt még többre is. A következõ néhány szakaszban szemügyre vesszük a TCP wrapperek számos lehetõségét, és ahol lehetséges, ott konfigurációs állományokkal is illusztráljuk ezek használatát. A TCP burkoló szoftverek kiterjesztik az inetd képességeit minden alatta dolgozó szerverdémon támogatására. Ezzel a módszerrel meg lehet oldani a naplózást, üzenetek küldését a kapcsolatokhoz, a démonok elérhetõségének korlátozását stb. Noha ezen lehetõségek közül néhány tûzfallal is megvalósítható, ezzel nem csupán egy további védelmi réteget húzunk fel a rendszerünk köré, hanem túllépjük mindazt, amit egy tûzfallal irányítani lehet. A TCP burkolók használatával hozzáadott funkcionalitás azonban nem helyettesít egy jó tûzfalat. A TCP kapcsolatok burkolását tûzfallal vagy más egyéb biztonsági megoldással együtt tudjuk csak eredményesen használni, viszont a rendszerünk biztonságában egy újabb remek védelmi vonalat képvisel. Mivel lényegében ez az inetd beállításának kibõvítése, ezért a szakasz elolvasásához feltételezzük az inetd beállításával kapcsolatos tudnivalók ismeretét. Bár az &man.inetd.8; által indított programok nem egészen tekinthetõen démonoknak, hagyományosan démonnak hívják ezeket. Ezért rájuk ebben a szakaszban is ezt a kifejezést használjuk. Kezdeti beállítások &os; alatt a TCP burkolók használatának egyetlen feltétele csupán annyi, hogy az inetd parancsot a paraméterrel indítsuk az rc.conf állományból. Az egyébként az alapbeállítás. Természetesen nem árt, ha helyesen állítjuk be az /etc/hosts.allow állományt is, ellenkezõ esetben a &man.syslogd.8; egyébként dobálni fogja errõl az üzeneteket. Eltérõen a TCP burkolók egyéb implementációitól, a hosts.deny állományt itt már nem használjuk. Minden beállítást az /etc/host.allow állományba kell raknunk. A legegyszerûbb konfiguráció esetén a démonok kapcsolódását egyszerûen engedélyezhetjük vagy letilthatjuk az /etc/hosts.allow állományban szereplõ beállításokkal. A &os; alapértelmezett beállításai szerint minden inetd által indított démonhoz lehet kapcsolódni. Ennek megváltoztatásával az alapkonfiguráció áttekintése után foglalkozunk. Az alapkonfiguráció általában démon : cím : cselekvés alakú. Itt a démon egy olyan démonra utal, amelyet az inetd indított el. A cím egy érvényes hálózati név, IP-cím vagy szögletes zárójelek ([ ]) között megadott IPv6 formátumú cím. A cselekvést tartalmazó mezõ (action) lehet allow vagy deny annak megfelelõen, hogy engedélyezzük vagy tiltjuk a megadott címrõl a csatlakozást. Nem szabad elfelejtenünk, hogy az így megadott beállítások közül mindig az elsõként illeszkedõ érvényesül, ami arra utal, hogy a konfigurációs állományban szereplõ szabályok egymás után növekvõ sorrendben értékelõdnek ki. Ha valamelyikük illeszkedik, akkor a keresés megáll. Rengeteg egyéb opció is megadható még, de ezekrõl csak a késõbbi szakaszokban fogunk szólni. Egy egyszerû konfigurációs állomány már ennyi információból is könnyedén összeállítható. Például, ha engedélyezni szeretnénk a POP3 kapcsolatokat a mail/qpopper démonon keresztül, akkor a következõ sorral kell kiegészítenünk a hosts.allow állományt: # Ez a sor kell a POP3 kapcsolatokhoz: qpopper : ALL : allow Miután hozzáadtuk ezt a sort, az inetd szervert újra kell indítanunk. Ezt vagy a &man.kill.1; paranccsal, vagy pedig az /etc/rc.d/inetd szkript restart paraméterével tehetjük meg. Komolyabb beállítások A TCP kapcsolatok burkolásánál is meg lehet adni további opciókat. Segítségükkel még jobban irányítani tudjuk a kapcsolatok kezelésének módját. Néhány esetben az is hasznos lehet, ha küldünk valamilyen választ az egyes gépeknek vagy démonoknak. Máskor szükségünk lehet a csatlakozások naplózására vagy e-mailen keresztüli jelzésére a rendszergazda felé. Teljesen más helyezetekben csak a helyi hálózatunkról engedjük meg a csatlakozást. Ez mind lehetséges a helyettesítõ jelekként ismert beállítási opciók, kiterjesztõ karakterek és külsõ parancsok végrehajtásának használatával. A következõ két szakasz az ilyen és ehhez hasonló szituációk megoldására íródott. Külsõ parancsok Tegyük fel, hogy olyan helyezetben vagyunk, amikor a kapcsolatot tiltani akarjuk, de közben azért szeretnénk errõl értesíteni a kapcsolatot kezdeményezõ felet is. Hogyan tudjuk ezt megcsinálni? Ezt a nevû opcióval tehetjük meg. Amikor megpróbál valaki csatlakozni, akkor a hívódik meg és végrehajt egy megadott parancsot vagy szkriptet. Erre találunk is egy példát a hosts.allow állományban: # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." Ez a példa a következõ üzenetet jeleníti meg: You are not allowd to use a démon neve from hálózati név. (Jelentése: A démon neve démont nem érheti el a hálózati név helyrõl!) Ez minden olyan démon esetén megjelenik, amirõl nem nyilatkoztunk korábban az állományban. Ezzel nagyon könnyen vissza tudunk küldeni egy választ a kapcsolat kezdményezõje felé, miután a kapcsolatot eldobtuk. Vegyük észre, hogy a visszaküldendõ üzenetet " karakterek közé kell tennünk, ez alól semmi sem kivétel. DoS támadást lehet elõidézni azzal, ha egy támadó vagy támadók egy csoportja csatlakozási kérelmekkel kezdi el bombázni a démonainkat. Ilyen esetekben használhatjuk a opciót is. A a opcióhoz hasonlóan implicit módon tiltja a kapcsolódást és arra használható, hogy lefuttassunk vele egy parancsot vagy szkriptet. A azonban a opciótól eltérõen nem küld vissza semmilyen választ a kapcsolatot létrehozni kívánó egyénnek. Ehhez példaként vegyük a következõ sort a konfigurációs állományban: # We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny Ezzel a *.example.com címtartományból érkezõ összes kapcsolódási kísérlet sikertelen lesz, miközben ezzel egyidõben a /var/log/connections.log állományba rögzítjük a csatlakozni akaró egyén hálózati nevét, IP-címét és a démont. A korábban már kifejtett helyettesítõ karakterek túl, mint például az %a, még léteznek továbbiak is. Róluk a &man.hosts.access.5; man oldalon találhatjuk meg a teljes listát. Helyettesítõ jelek Az eddigi példákban folyamatosan csak az ALL opciót adtuk meg. Azonban rajta kívûl léteznek mások is, amivel a megoldás funkcionalitását még egy kicsivel tovább növelhetjük. Például az ALL használható egy démon, egy tartomány vagy egy IP-cím illesztésére. A másik ilyen helyettesítõ jel a PARANOID, amelyet olyan gépek IP-címének illesztésekor alkalmazhatunk, ami feltételezhetõen hamis. Más szóval a PARANOID olyan cselekvések megadását teszi lehetõvé, amelyek akkor hajtódnak végre, amikor a kapcsolatot létrehozó gép IP-címe eltér a hálózati nevétõl. A most következõ példa valószínûleg segít fényt deríteni ennek lényegére: # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny A példában minden olyan kapcsolatkérést elutasítunk, ami a sendmail felé a hálózati névtõl eltérõ IP-címrõl irányul. Ha rossz DNS beállításokat használunk, a PARANOID megadásával súlyosan mozgásképtelenné tehetjük a kliensünket vagy szerverünket. Ezért legyünk óvatosak vele! A helyettesítõ jelekrõl és hozzájuk tartozó további lehetõségekrõl a &man.hosts.access.5; man oldalon tájékozódhatunk. A hosts.allow állományból ki kell venni az elsõ sort ahhoz, hogy bármilyen egyéb konfigurációs beállítás mûködõképes legyen. Ezt említettük a szakasz elején is. Mark Murray Írta: Mark Dapoz Eredetileg írta: <application>KerberosIV</application> A Kerberos egy olyan járulékos rendszer/protokoll, amellyel a felhasználók egy biztonságos szerver szolgáltatásain keresztül tudják hitelesíteni magukat. Ilyen szolgáltatás többek közt a távoli bejelentkezés, távoli másolás, a rendszeren belüli biztonságos másolás és minden olyan egyéb veszélyes feladat, amit számottevõen megbízhatóbbá és irányíthatóbbá tettek. A következõ utasítások a &os;-hez mellékelt Kerberos beállításához adnak útmutatást. A teljes leíráshoz azonban érdemes fellapoznunk a menet közben hivatkozott man oldalakat is. A <application>KerberosIV</application> telepítése MIT KerberosIV telepítés A Kerberos a &os; egyik választható komponense. Legkönnyebben úgy tudjuk feltelepíteni, ha a &os; telepítése során a sysinstall programban kiválasztjuk a krb4 vagy krb5 terjesztések valamelyikét. Ezzel felrakhatjuk a Kerberos eBones (KerberosIV) vagy Heimdal (Kerberos5) elnevezésû változatait. A &os; azért tartalmazza ezeket az implementációkat, mert nem az Amerikai Egyesült Államokban vagy Kanadában fejlesztették, így az Egyesült Államok titkosításokkal kapcsolatos kiviteli korlátozások korában minden olyan rendszer adminisztrátora el tudta érni, aki nem ezekben az országokban lakott. A Kerberos MIT által fejlesztett implementációját egyébként a Portgyûjteménybõl a security/krb5 porton keresztül érhetjük el. A kezdeti adatbázis létrehozása Ezt a lépést csak a Kerberos szerveren kell elvégezni. Elõször is gyõzõdjünk meg róla, hogy semmilyen korábbi Kerberos adatbázis nem található a gépen. Váltsunk az - /etc/kerberosIV könyvtárra - és ellenõrizzük a következõ - állományok meglétét: + /etc/kerberosIV + könyvtárra és ellenõrizzük a + következõ állományok + meglétét: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms Ha rajtuk kívül további állományok is feltûnnének (mint például a principal.* vagy master_key), akkor a kdb_destroy paranccsal pusztítsuk el a régi Kerberos adatbázist, vagy ha nem fut már a Kerberos, akkor egyszerûen csak törüljük le ezeket. Ezután lássunk neki a krb.conf és krb.realms állományok átírásán keresztül a Kerberos egyes övezeteinek (realm) létrehozásához. Itt most az EXAMPLE.COM lesz a létrehozandó övezet, a hozzátartozó szerver pedig a grunt.example.com. Így szerkesszük át vagy készítsünk el a neki megfelelõ krb.conf állományt: &prompt.root; cat krb.conf EXAMPLE.COM EXAMPLE.COM grunt.example.com admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov A többi övezetnek valójában nem feltétlenül kell itt lennie. Ezek csupán azért szerepelnek itt, hogy bemutassák miként lehet egyetlen géphez hozzárendelni egyszerre több övezetet is. Az egyszerûség kedvéért nyugodtan elhagyhatóak. Az elsõ sor nevezi meg a rendszer által mûködtetett övezeteket. Az utána következõ sorokban övezeteket és hálózati neveket láthatunk. Itt az elsõ elem egy övezetet nevez meg, a második elem pedig az övezet kulcselosztó központját (key distribution center). A hálózati nevet követõ admin server kulcsszavak arra utalnak, hogy az adott gép adminisztratív szerepet ellátó adatbázist is tartalmaz. Ezeket a fogalmakat részleteiben a Kerberos man oldalain ismerhetjük meg. Ezután hozzá kell adnunk a grunt.example.com nevû gépet az EXAMPLE.COM övezethez, valamint az .example.com tartományban levõ összes géphez létre kell hoznunk egy bejegyzést az EXAMPLE.COM övezetben. A krb.realms állományt ehhez a következõképpen kellene módosítanunk: &prompt.root; cat krb.realms grunt.example.com EXAMPLE.COM .example.com EXAMPLE.COM .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU Ismét hozzátesszük, hogy a többi övezetnek nem kötelezõ itt szerepelnie. Ezek csupán azt demonstrálják, hogy miként kell egy gépet egyszerre több övezethez is beállítani. Az átláthatóság kedvéért minden további nélkül eltávolíthatjuk ezeket. Itt az elsõ sor az adott rendszert elhelyezi egy nevesített övezetbe. A többi sor azt mutatja meg, hogyan kell alapértelmezett módon a meghatározott altartományokba tartozó gépeket egy nevesített övezethez hozzárendelni. Most már készen állunk az adatbázis létrehozására. Ehhez egyedül a Kerberos szerverét (avagy Kulcselosztó központját) kell elindítanunk. Adjuk ki a kdb_init parancsot: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: Az üzenet fordítása: Most az adatbázis mesterkulcsát kell megadni. Fontos, hogy NE FELEJTSÜK EL ezt a jelszót. Most el kell mentenünk a kulcsot, így a helyi gépen futó szerverek fel tudják szedni. Ehhez a kstash parancsra van szükségünk: &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Az üzenet fordítása: A Kerberos mesterkulcsának jelenlegi változata: 1. VIGYÁZAT, megadták a mesterkulcsot! Ez elmenti a titkosított mesterkulcsot az /etc/kerberosIV/master_key állományba. Az egész beüzemelése KerberosIV kezdeti indítása Mindegyik Kerberosszal õrzött rendszerrel kapcsolatban két ún. szereplõt (principal) kell még hozzátennünk az adatbázishoz. A nevük kpasswd és rcmd. Minden rendszerhez létre kell hoznunk ezeket a szereplõket, példányonként (instance) az egyes rendszerek neveivel. A kpasswd és rcmd démonok teszik lehetõvé a többi rendszer számára, hogy megváltoztathassák a Kerberos jelszavukat, valamint hogy futtathassák az &man.rcp.1;, &man.rlogin.1; és &man.rsh.1; parancsokat. Vegyük fel ezeket a bejegyzéseket is: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- írjuk be, hogy RANDOM Verifying password New Password: <---- írjuk be, hogy RANDOM Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- írjuk be, hogy RANDOM Verifying password New Password: <---- írjuk be, hogy RANDOM Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- ha nem adunk meg semmit, akkor kilép A szerver állomány létrehozása Most pedig kivonatolni kell azokat a példányokat, amelyek szolgáltatást definiálnak a gépen. Erre az ext_srvtab parancsot használjuk. Ennek eredményeképpen keletkezik egy állományt, amelyet biztonságos eszközökkel át kell másolni vagy át kell mozgatni az egyes Kerberos kliensek - /etc könyvtárába. Ennek + /etc könyvtárába. Ennek az állománynak egyaránt jelent kell lennie a szerveren és a kliensen is, nélküle a Kerberos mûködésképtelen. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... Ez a parancs most létrehozott egy ideiglenes állományt, amit át kell nevezni az srvtab névre, hogy megtalálhassák a szerverek. Az eredeti rendszeren a &man.mv.1; paranccsal tudjuk a helyére rakni: &prompt.root; mv grunt-new-srvtab srvtab Ha egy kliensnek szánjuk az állományt és a hálozatunkat nem tekinthetjük biztonságosnak, akkor a kliens-new-srvtab állományt másoljuk egy mozgatható adathordozóra és megbízható módon jutassuk el. Ne felejtsük el az állományt srvtab néven - átrakni a kliens /etc - könyvtárába és az engedélyeit - 600-ra állítani: + átrakni a kliens /etc könyvtárába + és az engedélyeit 600-ra + állítani: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab Az adatbázis feltöltése Ezt követõen rögzítenünk kell néhány felhasználót is adatbázisban. Elõször is hozzunk létre egy bejegyzést a janos nevû felhasználónak. Ezt a kdb_edit parancs kiadásával tesszük meg: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: janos Instance: <Not found>, Create [y] ? y Principal: janos, Instance: , kdc_key_ver: 1 New Password: <---- adjunk meg egy biztonságos jelszót Verifying password New Password: <---- itt ismét adjuk meg a jelszót Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- ha nem írunk be semmit, akkor kilép Próbáljuk ki Elsõként a Kerberos démonait kell beindítanunk. Ezzel kapcsolatban megjegyeznénk, hogy ha ehhez megfelelõen átírtuk az /etc/rc.conf állományunkat, akkor ez az újraindítással együtt magától lezajlik. Ezt csak a Kerberos szerveren kell megcsinálni. A Kerberos kliensei maguktól összeszedik a mûködésükhöz - szükséges adatokat az - /etc/kerberosIV + szükséges adatokat az /etc/kerberosIV könyvtárból. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: EXAMPLE.COM &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! A fenti figyelmeztetés fordítása: A program leállítására ne a 'kill -9' parancsot, hanem a normális kill parancsot használjuk Ezután a kinit parancs használatával próbáljunk meg az elõbb létrehozott janos azonosítónak kérni egy jegyet: &prompt.user; kinit janos MIT Project Athena (grunt.example.com) Kerberos Initialization for "janos" Password: A klist paranccsal most próbáljuk meg kilistázni a tokeneket és így ellenõrizni, hogy valóban rendelkezünk velük: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: janos@EXAMPLE.COM Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM Ezután a &man.passwd.1; használatával próbáljuk meg megváltoztatni a jelszavunkat. Ezzel tudjuk ellenõrizni, hogy a kpasswd démon hozzáfér a Kerberos adatbázisához: &prompt.user; passwd realm EXAMPLE.COM Old password for janos: New Password for janos: Verifying password New Password for janos: Password changed. Adminisztrátori jogosultságok felvétele A Kerberos lehetõvé teszi, hogy mindegyik olyan felhasználónak, akinek rendszergazdai jogokra lenne szüksége, a &man.su.1; eléréséhez külön meg tudjunk adni egy jelszót. Most már tudunk mondani egy olyan azonosítót is, amely jogosult a &man.su.1; használatával root jogokat szerezni. Ezt úgy tudjuk megoldani, ha az adott szereplõhöz társítunk egy root példányt. A kdb_edit használatával készíteni tudunk egy janos.root bejegyzést a Kerberos adatbázisában: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: janos Instance: root <Not found>, Create [y] ? y Principal: janos, Instance: root, kdc_key_ver: 1 New Password: <---- ide csak egy BIZTONSÁGOS jelszót adjuk meg! Verifying password New Password: <---- adjuk meg ismét a jelszót Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- ne állítsuk nagyon hosszúra! Attributes [ 0 ] ? Edit O.K. Principal name: <---- ha nem adunk meg semmit, akkor kilép Ezt követõen úgy tudunk megbizonyosodni a mûködésérõl, hogy megpróbálunk neki tokeneket szerezni: &prompt.root; kinit janos.root MIT Project Athena (grunt.example.com) Kerberos Initialization for "janos.root" Password: Most rakjuk bele a felhasználót a root .klogin állományába: &prompt.root; cat /root/.klogin janos.root@EXAMPLE.COM Ezután próbáljunk meg kiadni a &man.su.1; parancsát: &prompt.user; su Password: Nézzük meg milyen tokenjeink is vannak: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: janos.root@EXAMPLE.COM Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM Más parancsok használata Az iménti példában létrehoztunk egy janos nevû szereplõt, amihez a root egy példányát rendeltük. Ez egy olyan felhasználón alapján történt, akinek a neve megegyezik a hozzátartozó szereplõvel, ami a Kerberosban alapértelmezés. Amennyiben a szükséges megjegyzések megtalálhatóak a root könyvtárában levõ .klogin állományban, akkor a felhasználó.root formátumú szereplõ.példány azonosító megengedi a felhasználó számára, hogy végrehajtsa a &man.su.1; parancsot. &prompt.root; cat /root/.klogin janos.root@EXAMPLE.COM Ehhez hasonlóan, ha a felhasználó saját könyvtárában megtalálható egy ilyen állomány: &prompt.user; cat ~/.klogin janos@EXAMPLE.COM jozsef@EXAMPLE.COM Ezzel a konfigurációval bárki, aki janos felhasználóként vagy jozsef felhasználóként (a kinit parancson keresztül) hitelesítette magát EXAMPLE.COM övezetbõl, ezen a rendszeren (grunt) bejelentkezhet a janos nevû felhasználóként vagy hozzáférhet az állományaihoz az &man.rlogin.1;, &man.rsh.1; vagy &man.rcp.1; használatával. Például janos most egy másik Kerberost használó rendszerre jelentkezik be: &prompt.user; kinit MIT Project Athena (grunt.example.com) Password: &prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Vagy jozsef jelentkezik be ugyanazon a gépen janos hozzáférésével (a janos nevû felhasználónak a fentebb bemutatt .klogin állomány található a könyvtárában és a Kerberos üzemeltetéséért felelõs személy létrehozott egy jozsef nevû szereplõt egy null példánnyal): &prompt.user; kinit &prompt.user; rlogin grunt -l janos MIT Project Athena (grunt.example.com) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Tillman Hodgson Írta: Mark Murray Eredetileg írta: <application>Kerberos5</application> A &os; 5.1 után következõ mindegyik &os; kiadás már csak a Kerberos5 támogatást tartalmaz. Ezért bennük csak a Kerberos5 található meg, és a beállítása sok szempontból hasonlít a KerberosIV beállításához. A most következõ információk csak és kizárólag a &os; 5.0 kiadás után következõkben található Kerberos5 változatra vonatkoznak. A KerberosIV szolgáltatásait a felhasználók csomagként, a security/krb4 porton keresztül érhetik el. A Kerberos egy hálózati kiegészítõ rendszer/protokoll, amivel a felhasználók egy biztonságos szerveren keresztül képesek magukat azonosítani. A távoli bejelentkezések, távoli másolások, a rendszer belüli védett másolások valamint egyéb nagyon kockázatos feladatok, szolgáltatások biztonsága és felügyelete így jelentõs mértékben javítható. A Kerberos úgy írható le, mint az személyazonosságok ellenõrzésére feljogosított rendszer. Vagy tekinthetjük egy megbízható külsõ megfigyelõ által végzett hitelesítési rendszernek is. A Kerberos csak egyetlen funkciót kínál fel — ez a felhasználók biztonságos hitelesítése a hálózaton. Viszont nem nyújt semmilyen felhatalmazási (mit csinálhatnak a felhasználók) vagy vizsgálati (mit csináltak végül a felhasználók) lehetõséget. Miután egy kliens és a szerver a Kerberos használatával azonosították egymást, az egymás közt folyó kommunikációjuk titkosításával képesek megõrzi az átáramló adatok sértetlenségét és lehallgathatatlanságát. Ennek tükrében a Kerberos használata csak más olyan biztonsági módszerekkel együttesen javasolt, amelyek felhatalmazást és vizsgálati szolgáltatásokkal is rendelkeznek. A most következõ utasítások arra igyekeznek útmutatást adni, hogy miként használjuk a &os;-vel együtt terjesztett Kerberos verziót. Azonban a teljes leírást csak a témához tartozó man oldalak átolvasásával együtt kapjuk meg. A Kerberos telepítésének bemutatásához az alábbi névtereket fogjuk használni: A DNS tartomány (zóna) az example.org lesz. A Kerberos övezet az EXAMPLE.ORG lesz. Kérjük, hogy még abban az esetben is valódi tartományneveket adjuk meg, amikor a Kerberos használatát csak a belsõ hálózaton tervezzük. Ezzel elkerülhetjük az egyes Kerberos övezetek együttmûködése során felmerülõ DNS problémákat. A <application>Kerberos</application> története Kerberos5 története A Kerberost az MIT hozta létre a hálózati biztonsággal kapcsolatos problémák egyik megoldásaként. A Kerberos erõs titkosítást használ, ezért a kliensek képesek egy nem biztonságos hálózaton is azonosítani magukat a szerver felé (és fordítva). A Kerberos egyaránt utal egy hálózati protokoll nevére és azokra programokra, amelyek implementálják (például Kerberos telnet). Az 5 a protokoll jelenlegi verziója, amit az RFC 1510 ír le. A protokollnak számos szabad változata létezik, rengeteg típusú operációs rendszerre. A Massachusettsi Mûszaki Intézet (Massachusetts Institute of Technology, MIT), ahol a Kerberost eredetileg kifejlesztették, napjainkban is folytatja a saját Kerberos csomagjának fejlesztését. Többnyire az Egyesült Államokban használják titkosításra, mivel régebben az amerikai kiviteli korlátozások voltak rá érvényesek. Az MIT Kerberos változata portként érhetõ el (security/krb5). A Heimdal Kerberos egy másik 5 verziójú implementáció, amit a kiviteli korlátozások elkerülése érdekében határozottan az Egyesült Államokon kívül fejlesztettek ki (ezért gyakran megtalálhatjuk a különbözõ nem kereskedelmi &unix; variánsokban). A Heimdal Kerberos terjesztés portként elérhetõ (security/heimdal) és kisebb méretben a &os; alaptelepítésének is része. Mivel ezzel az írással a legtöbb felhasználót kívánjuk segíteni, ezért a következõ utasítások a &os; telepítésében mellékelt Heimdal terjesztés használatát feltételezik. A Heimdal kulcselosztójának telepítése Kerberos5 kulcselosztó központ A kulcselosztó központ (Key Distribution Center, avagy KDC) az a centralizált hitelesítési szolgáltatás, amit a Kerberos nyújt — lényegében az a számítógép, amely Kerberos-jegyeket bocsájt ki. A KDC megbízhatónak tekinthetõ a Kerberos által kialakított övezetben levõ többi számítógép számára, ezért védelme kiemelten fontos. Itt jegyeznénk meg, hogy habár a Kerberos szerver futtatása nagyon kevés számítógépes erõforrást igényel, ennek ellenére biztonsági szempontból egy külön számítógépet javasoljunk a kulcselosztó szerepének betöltéséhez. Mielõtt nekifognánk a KDC konfigurálásának, ellenõrizzük, hogy az /etc/rc.conf tartalmazza a KDC mûködéséhez szükséges beállításokat (az elérési utakat természetesen a saját rendszerünk szerint állítsuk be): kerberos5_server_enable="YES" kadmind5_server_enable="YES" A következõ lépésben vegyük szemügyre a Kerberos beállításait tartalmazó /etc/krb5.conf állományt: [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG Vegyük észre, hogy az itt szereplõ /etc/krb5.conf állomány szerint a kulcselosztónk teljes hálózati neve kerberos.example.org. Ha a kulcselosztónknak nem ez a neve, akkor a zónákat leíró állományba vegyünk még fel egy ilyen CNAME (álnév) bejegyzést. Ha egy nagyobb hálózatban vagyunk, ahol a DNS szervert is megfelelõen beállították, akkor az iménti példa ennyire leszûkíthetõ: [libdefaults] default_realm = EXAMPLE.ORG Itt már a következõ sorokat hozzáadták example.org zónát leíró állományhoz: _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG A kliensek csak akkor lesznek képesek elérni a Kerberos szolgáltatásait, ha vagy kötelezõ jelleggel megadunk egy teljesen beállított /etc/krb5.conf állományt, vagy egy minimális /etc/krb5.conf állományt és egy helyesen beállított DNS szervert használunk. Ezután létrehozzuk a Kerberos adatbázisát. Ez az adatbázis tartalmazza az összes szereplõ kulcsát a mesterkulcssal titkosítva. Erre a jelszóra nem kell feltétlenül emlékeznünk, mivel ez egy állományban tárolódik (/var/heimdal/m-key). A mesterkulcsot a kstash parancs kiadásával és egy jelszó megadásával tudjuk létrehozni. Ahogy a mesterkulcs elkészült, a kadmin parancs -l (mint lokális, azaz helyi) opciójával inicializálni tudjuk az adatbázist. Ez az opció arra utasítja a kadmin programot, hogy ne a kadmind hálózati szolgáltatást használja, hanem közvetlenül az adatbázis állományait módosítsa. Ezzel oldható meg az adatbázis kezdeti létrehozásának problémája. Miután megkaptuk a kadmin parancssorát, az övezetünkhöz tartozó adatbázis inicializálásához adjuk ki az init parancsot. Végül, még mindig a kadmin parancssorát használva, az add paranccsal hozzuk létre az elsõ szereplõnket. Egyelõre érjük be az alapértelmezett értékekkel, a modify paranccsal késõbb úgyis meg tudjuk változtatni ezeket. Hozzátesszük, hogy itt a ? parancs segítségével bármikor lekérhetjük az opciók ismertetését. Példa egy adatbázis létrehozására: &prompt.root; kstash Master key: xxxxxxxx Verifying password - Master key: xxxxxxxx &prompt.root; kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx Most már ideje elindítani a KDC szolgáltatásait. Ezeket az /etc/rc.d/kerberos start és /etc/rc.d/kadmind start parancsok kiadásával tudjuk felhozni. Megjegyezzük, hogy most még semmilyen kerberizált démont nem kell elindítanunk. Ellenben igyekezzünk ellenõrizni a KDC mûködõképességét azzal, hogy KDC parancssorából kérünk egy jegyet a frissen hozzáadott szereplõnknek (felhasználónknak) és kilistázzuk: &prompt.user; kinit tillman tillman@EXAMPLE.ORG's Password: &prompt.user; klist Credentials cache: FILE:/tmp/krb5cc_500 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG Miután végeztünk, nyugodtan törölhetjük a jegyet: &prompt.user; kdestroy Szerverek kerberizálása a Heimdal használatával Kerberos5 szolgáltatások kerberizálása Ehhez elõször is szükségünk lesz a Kerberos konfigurációs állományának, az /etc/krb5.conf másolatára. Ezt úgy tudjuk megtenni, ha egyszerûen átmásoljuk a kulcselosztóról az egyik kliensre valamilyen megbízható módon (vagy az &man.scp.1; programhoz hasonló hálózati segédprogramok, vagy például fizikailag egy floppy lemez használatával). Ezután szükségünk lesz egy /etc/krb5.keytab nevû állományra. Ez az alapvetõ különbség a kerberizált démonokat felkínáló szerver és egy munkaállomás közt — a szervernek rendelkeznie kell egy keytab állománnyal. Ez az állomány tartalmazza a szerver kulcsát, amivel így a kulcselosztóval kölcsönösen azonosítani tudják egymást. Ezt a szerverre biztonságosan kell eljuttatnunk, mivel ennek napvilágra kerülésével a szerver védelme komoly veszélybe kerül. Tehát, ha egy titkosítás nélküli csatornán, például FTP-n keresztül visszük át, akkor kifejezetten rossz ötlet. A szerverre általában a kadmin program használatával érdemes átvinni a keytab állományt. Ez azért is hasznos, mert ehhez a kadmin segítségével létre kell hoznunk a befogadó szereplõt is (a kulcselosztó a krb5.keytab állomány végén). Vegyük észre, hogy már kaptunk egy jegyet és ezzel a jeggyel jogosultaknak kell lennünk a kadmind.acl állomány kadmin felület használatára. A hozzáférést vezérlõ listák (ACL-ek) tervezésével kapcsolatban olvassuk el Heimdal info oldalán található Remote administration címû szakaszt (info heimdal). Amennyiben nem kívánjuk engedélyezni a kadmin távoli elérését, egyszerûen csak csatlakozzunk valamilyen biztonságos módon (helyi konzolon, &man.ssh.1; vagy egy kerberizált &man.telnet.1; használatával) a kulcselosztóhoz, és a kadmin -l paranccsal végezzük el helyben az adminisztrációt. Miután telepítettük az /etc/krb5.conf állományt, a Kerberos szerverrõl el tudjuk érni a kadmin felületét. Az add --random-key paranccsal most már hozzáadhatjuk a szerver befogadó szereplõjét és az ext paranccsal ki tudjuk vonni a szerver befogadó szereplõjét a saját keytab állományából. Például: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/myserver.example.org kadmin> exit Itt jegyeznénk meg, hogy az ext parancs (az extract rövdítése) a kivont kulcsot alapértelmezés szerint az /etc/krb5.keytab állományba menti ki. Ha a kulcselosztón nem fut a kadmind szolgáltatás (valószínûleg biztonsági okokból) és ezért távolról nem tudjuk elérni a kadmin felületét, akkor így tudjuk közvetlenül hozzáadni a befogadó szereplõt (host/myserver.EXAMPLE.ORG), majd kivonatolni azt egy ideiglenes állományba (elkerülve az /etc/krb5.keytab felülírását): &prompt.root; kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit Ezután valamilyen biztonságos eszközzel (például scp vagy floppy használatával) át tudjuk másolni keytab állományt a szerverre. A kulcselosztón levõ keytab felülírását elkerülendõ, ne feledkezzünk el egy megfelelõ név megadásáról sem. Ezen a ponton már a szerver képes felvenni a kapcsolatot a kulcselosztóval (a krb5.conf állomány miatt) és bizonyítani a személyazonosságát (a krb5.keytab állomány miatt). Így tehát készen állunk a szolgáltatások kerberizálására. Ebben a példában most a telnet szolgáltatást vesszük célba úgy, hogy elõször az /etc/inetd.conf állományba berakjuk az alábbi sort, majd újraindítjuk az &man.inetd.8; szolgáltatást az /etc/rc.d/inetd restart paranccsal: telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user Itt az a legfontosabb, hogy az -a (mint authentication, azaz hitelesítés) paramétert a user beállítással adjuk meg. A &man.telnetd.8; man oldalán olvashatunk ennek pontos részleteirõl. Kliensek kerberizálása a Heimdal használatával Kerberos5 kliensek beállítása A kliensek beállítása szinte majdnem gyerekjáték. A Kerberos beállításához egyedül az /etc/krb5.conf állományra lesz szükségünk. Valamilyen biztonságos eszközzel másoljuk át a kulcselosztóról a kliensre. Úgy tudjuk letesztelni klienst, ha megpróbáljuk róla kiadni a kinit, klist és kdestroy parancsokat a fentebb létrehozott szereplõ jegyének megszerzéséhez, lekérdezéséhez és megsemmisítéséhez. A Kerberos használatával megpróbálkozhatunk csatlakozni valamelyik kerberizált szerverre is, ha viszont ez nem mûködik még egy jegy megszerzése után sem, akkor a gond többnyire a szerverrel van, nem pedig a klienssel vagy a kulcselosztóval. Amikor egy telnet vagy egy hozzá hasonló alkalmazást tesztelünk, egy csomaglehallgató (mint amilyen például a &man.tcpdump.1;) elindításával gyõzödjünk meg róla, hogy a jelszavak ilyenkor titkosítva mennek át. Próbáljuk meg titkosítani a teljes kommunikációt a telnet paraméterével (hasonlóan az ssh parancshoz). Alapból még számos más kiegészítõ Kerberos kliensalkalmazás is telepítõdik. Ezeken érezhetõ meg valójában az alaprendszerhez tartozó Heimdal változat minimalitása: ebben a telnet az egyedüli kerberizált szolgáltatás. A Heimdal port igyekszik pótolni a hiányzó klienseket a kerberizált ftp, rsh, rcp, rlogin és néhány kevéséb ismert program telepítésével. Az MIT változat portja szintén tartalmazza a Kerberos kliensek teljes kelléktárát. A felhasználók konfigurációs állományai: a <filename>.k5login</filename> és a <filename>.k5users</filename> .k5login .k5users Általában az övezetben található felhasználók mindegyikéhez tartozik egy Kerberos-szereplõ (mint például a tillman@EXAMPLE.ORG), ami a felhasználó helyi hozzáférésére mutat (mint például a tillman nevû helyi hozzáférés). A telnet és a hozzá hasonló kliensalkalmazások általában nem igényelnek felhasználót vagy szereplõt. Elõfordulhat azonban, hogy valaki olyan szeretné elérni egy helyi felhasználó hozzáférését, aki nem rendelkezik a hozzátartozó Kerberos-szereplõvel. Például a tillman@EXAMPLE.ORG nevû felhasználó el szeretné érni a helyi számítógépen levõ webdevelopers hozzáférést. Más szereplõk is elérhetik a helyi hozzáféréseket. A probléma megoldásához a felhasználók könyvtárában található .k5login és a .k5users állományok használhatóak a .host és .rhosts állományok kombinációjához hasonlóan. Például a .k5login így néz ki: tillman@example.org jdoe@example.org Ezt a webdevelopers nevû helyi felhasználó könyvtárában kell elhelyeznünk, így a felsorolt szereplõt megosztott jelszó használata nélkül képesek elérni a hozzáférést. Az említett parancsok man oldalának elolvasása ajánlott. Megjegyezzük, hogy a ksu man oldal foglalkozik a .k5users állománnyal. Tippek, trükkök a <application>Kerberos</application> használatáról és hibaelhárítás Kerberos5 hibaelhárítás Akár a Kerberos Heimdal vagy az MIT változatát használjuk, ne felejtsük úgy beállítani a PATH környezeti változóban felsorolt elérési utakat, hogy a kliensalkalmazások kerberizált változatai a rendszerben használatos verziók elé kerüljenek. Az övezetben minden számítógép órája ugyanúgy jár? Ha nem, akkor a hitelesítés csõdöt mondhat. A ból tudhatjuk meg hogyan szinkronizáljunk órákat az NTP segítségével. Az MIT és a Heimdal verziók a kadmin kivételével remekül megvannak egymással, mivel az általa használt protokollt még nem szabványosították. Ha megváltoztatjuk a gépünk hálózati nevét, akkor a ugyanígy a host/ szereplõnket is meg kell változtatni és frissíteni a keytab állományunkat. Ez olyan speciális keytab bejegyzésekre is vonatkozik, mint például az Apache www/mod_auth_kerb moduljához tartozó www/ szereplõ. Az övezetünkben levõ összes számítógépnek (mind a két irányba) feloldható DNS névvel kell rendelkeznie (vagy legalább egy /etc/hosts állománnyal). Erre a CNAME rekord megfelelõ, de az A és PTR rekordoknak mindenképpen rendben kell lenniük. Az ilyenkor keletkezõ hibaüzenet nem éppen fogja meg a lényeget: Kerberos5 refuses authentication because Read req failed: Key table entry not found. A kulcselosztó számára kliensként viselkedõ bizonyos operációs rendszerek nem állítják be megfelelõen a ksu engedélyeit, ezért nem lehet root jogokkal futtatni. Ezért a ksu parancs nem fog mûködni, ami alapvetõen nem egy rossz ötlet, de idegesítõ. Ez nem a kulcselosztó hibája. Ha a Kerberos MIT változatát használjuk és a meg akarjuk hosszabbítani a szereplõknek kiadott jegyek élettartamát az alapértelmezett tíz óráról, akkor a kadmin felületén a modify_principal paranccsal tudjuk megváltoztatni mind a kérdéses szereplõ, mind pedig a krbtgt jegyeinek élettartamának maximumát. Ezt követõen a szereplõ a kinit opciójával tud egy nagyobb élettartammal rendelkezõ jegyet kérni. Amikor egy kulcselosztóval kapcsolatos hibát próbálunk felderíteni a csomagok lehallgatásával, és a munkaállomásunkról kiadjuk a kinit parancsot, akkor arra lehetünk figyelmesek, hogy a TGT már egybõl a kinit indításakor átküldésre kerül — még mielõtt egyáltalán megadtuk volna a jelszavunkat! Ezt azzal lehet magyarázni, hogy a Kerberos szerver bármilyen hitelesítetlen kérésre elküld egy TGT-t (Jegyadó jegy, azaz Ticket Granting Ticket). Azonban mindegyik ilyen TGT a felhasználó jelszavából származtatott kulccsal titkosítódik. Ezért amit a felhasználó jelszóként megad, nem megy el a kulcselosztónak, hanem vele a kinit a már megkapott TGT-t kódolja ki. Amennyiben a visszakódolás egy érvényes idõbélyeggel rendelkezõ, használható jegyet eredményez, akkor a felhasználó érvényes Kerberos hitelesítést szerez. Ez a hitelesítés magában foglal egy kulcsot, amellyel a késõbbiekben a Kerberos szerverekkel tudjuk felvenni biztonságos módon a kapcsolatot, és rajta kívül egy újabb jegyadó jegyet, amelyet a Kerberos szerver a saját kulcsával titkosított. A titkosítás második vonala a felhasználó számára ismeretlen, de segítségével a Kerberos szerer képes ellenõrizni az egyes jegyadó jegyek hitelességét. Ha a jegyeket hosszabb (például egyhetes) élettartammal akarjuk használni és a jegyeket tároló géphez OpenSSH segítségével csatlakozunk, akkor mindenképpen ellenõrizzük, hogy az sshd_config állományban a Kerberos beállításának értéke no, máskülönben a kijelentkezés után automatikusan törlõdnek a jegyeink. Ne hagyjuk figyelmen kívül azt sem, hogy a befogadó szereplõk is rendelkezhetnek nagyobb élettartamú jegyekkel. Ha a felhasználónkhoz tartozó szereplõ jegye például egy hét alatt évül el, de a számítógép, amire bejelentkezük, csupán kilenc óráig tartja életben ezeket, akkor a jegyeket tároló gyorsítótárunkban hamarabb elévül a hozzátartozó jegy, ami miatt pedig hibák keletkeznek. Ha a rossz jelszavak használata ellen beállítjuk a krb5.dic állományt (errõl a kadmind man oldalán találunk egy rövid leírást), akkor nem szabad elfelejteni, hogy ez csak olyan szereplõkre vonatkozik, akiknek a jelszavára is állítottunk be szabályozásokat. A krb5.dict állományok felépítési nem bonyolult: minden sorban egyetlen karakterlánc szerepel. Érdemes lehet például létrehozni ezen a néven egy szimbolikus linket a /usr/share/dict/words állományra. Eltérések az <acronym>MIT</acronym> porttól A Heimdal és az MIT változatok közti egyik legnagyobb eltérés a kadmin programmal kapcsolatban van, ami eltérõ (de egyébként ekivalens) parancskészlettel rendelkezik és más protokollt használ. Ennek komoly következménye, hogy ha az MIT-féle kulcselosztót használjuk, akkor azt a Heimdal kadmin felületével nem tudjuk távolról adminisztrálni (és vica versa). A kliensalkalmazások paraméterezése is eltérhet ugyanazon feladatoknál. Ezért velük kapcsolatban az MIT Kerberos honlapja () a mérvadó. Vigyázzunk az elérési utakkal: az MIT port magát alapértelmezés szerint a - /usr/local könyvtárba - telepíti, ezért az általuk kiváltani - kívánt normális - rendszerprogramokat esetleg hamarabb találja meg a - rendszer, ha nem jól állítottuk be a - PATH környezeti - változónkat. + /usr/local + könyvtárba telepíti, ezért az + általuk kiváltani kívánt + normális rendszerprogramokat esetleg + hamarabb találja meg a rendszer, ha nem jól + állítottuk be a PATH + környezeti változónkat. Ha nem értjük, hogy miért mûködnek olyan furcsán a telnetd és a klogind által kezelt bejelentkezések, akkor olvassuk el a &os; security/krb5 portjával települõ MIT változat /usr/local/share/doc/krb5/README.FreeBSD állományt (angolul). Az a legfontosabb, hogy a incorrect permissions on cache file hiba eltüntetéséhez a login.krb5 binárist kell használnunk, így a továbbított jogosultságoknak megfelelõen át tudja állítani a tulajdonost. Az rc.conf állományt is módosítani kell a következõ beállítás kialakításához: kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_enable="YES" kadmind5_server_enable="YES" Erre azért van szükség, mert a Kerberos MIT változata a /usr/local könyvtáron belülre telepíti fel a hozzátartozó alkalmazásokat. A <application>Kerberos</application>ban talált korlátozások enyhítése Kerberos5 hiányosságok és korlátozások A <application>Kerberos</application> a <quote>mindent vagy semmit</quote> megközelítést követi A hálózaton minden szolgáltatást módosítanunk kell ahhoz, hogy együtt tudjanak mûködni a Kerberosszal (vagy valamilyen más módon védenünk kell ezeket a támadások ellen), különben a felhasználók jogait el lehet lopni vagy újra fel lehet használni. Erre jó példa lehet az összes távoli parancssoros elérés (például az rsh valamint a telnet) kerberizálása, de a jelszavakat titkosítatlanul küldõ POP3 levelezõ szerver kihagyása. A <application>Kerberos</application> az egyfelhasználós munkaállomások számára készült Többfelhasználós környezetben a Kerberos már nem annyira biztonságos. Ez azért mondható el, mert a jegyeket a mindenki által olvasható - /tmp könyvtárban - tárolja. Ha az adott felhasználó + /tmp + könyvtárban tárolja. Ha az adott + felhasználó számítógépét egyszerre több emberrel is megosztja (tehát többfelhasználós), akkor a felhasználó jegyeit egy másik felhasználó bármikor lemásolhatja (ellophatja). Ezt a opció után megadott állománynévvel vagy (inkább) a KRB5CCNAME környezeti változó megfelelõ beállításával tudjuk áthidalni, habár ezt ritkán teszik is meg. Ha a felhasználók könyvtárában és a megfelelõ engedélyekkel tároljuk ezeket a jegyeket, akkor némileg visszaszoríthatjuk a probléma kockázatát. A kulcselosztó a rendszer legsebezhetõbb pontja A rendszer kialakításából fakadóan a kulcselosztónak legalább annyira megbízhatónak kell lennie, mint a rajta levõ központi jelszóadatbázisnak. A kulcselosztón semmilyen más szolgáltatás nem futhat és fizikailag is biztonságba kell helyezni. A kockázat nagy, mivel a Kerberos az összes jelszót ugyanazzal a kulcssal (a mesterkulcssal) titkosítja, amelyet a kulcselosztó egy állományban tárol. Széljegyzet gyanánt hozzátesszük, hogy a mesterkulcs elvesztése nem annyira rossz, mint azt elsõ gondolnánk. A mesterkulcsot csupán a véletlenszám-generátor inicializálásához használják a Kerberos adatbázisának titkosításakor. Amíg a kulcselosztóhoz nem tudnak illetéktelenek hozzáférni, addig nem tudnak sokat kezdeni a mesterkulccsal. Mellesleg ha a kulcselosztó nem elérhetõ (talán pontosan egy DoS támadás vagy éppen hálózati problémák miatt), akkor a hitelesítés nem végezhetõ el, mivel így a hozzá szükséges hálózati szolgáltatások sem használhatóak. Ez remek eszköz egy DoS támadáshoz. Ezen több (egy központi és egy vagy több alárendelt) kulcselosztó telepítésével, valamint a másodlagos vagy tartalékként használt hitelesítési eszközök (a PAM erre tökéletes) körültekintõ megvalósításával enyhíthetünk. A <application>Kerberos</application> hiányosságai A Kerberos révén a felhasználók, számítógépek és szolgáltatások tudják egymást hitelesíteni. Ellenben semmilyen eszközt nem kínál fel a kulcselosztó hitelességének ellenõrzésére. Így tehát (például) egy eltérített kinit képes ellopni az összes felhasználói nevet és jelszót. Az ilyen incidensek elkerülésére a security/tripwire és a hozzá hasonló segédprogramok segítségével lehet megõrizni a rendszer sértelenségét. Erõforrások és további információk Kerberos5 külsõ források A Kerberos GYIK (angolul) Egy hitelesítési rendszer kidolgozása: párbeszéd négy színben (angolul) RFC 1510: A Kerberos hálózati hitelesítési szolgáltatás (V5) (angolul) Az MIT Kerberos holnapja (angolul) A Heimdal Kerberos honlapja (angolul) Tom Rhodes Írta: OpenSSL biztonság OpenSSL A &os;-hez adott OpenSSL az egyik olyan tényezõ, amit a legtöbb felhasználó figyelmen kívül hagy. Az OpenSSL egy titkosítási réteget nyújt a hagyományos kommunikációs csatorna felett, így rengeteg hálózati alkalmazásba és szolgáltatásba bele lehet szõni. Az OpenSSL felhasználható többek közt a levelezõ kliensek titkosított hitelesítésére, hitelkártyás fizetések weben keresztüli lebonyolítására alkalmas, és még sok minden másra. Sok port, köztük a www/apache13-ssl és a mail/sylpheed-claws is felajánlja az OpenSSL felhasználását. A legtöbb esetben a Portgyûjtemény megpróbálja lefordítani a security/openssl portot, hacsak a WITH_OPENSSL_BASE változót határozottan a yes értékre nem állítjuk. A &os;-hez mellékelt OpenSSL ismeri a Secure Sockets Layer v2/v3 (SSLv2/SSLv3) és Transport Layer Security v1 (TLSv1) hálózatbiztonsági protokollokat, és általános célú titkosítási könyvtárként is alkalmazható. Noha az OpenSSL ismeri az IDEA algoritmusát is, az Egyesült Államokban érvényben levõ szabadalmak miatt alapértelmezés szerint nem engedélyezett. A használatához el kell olvasni a hozzátartozó licencet, és ha elfogadjuk a benne foglaltakat, akkor állítsuk be a MAKE_IDEA változót a make.conf állományban. Az OpenSSL-t leginkább a szoftverek tanúsítványainak elkészítéséhez használják. Ilyen tanúsítvánnyokkal lehet szavatolni, hogy az érte felelõs cég vagy egyén valóban megbízható és nem szélhámos. Amennyiben a kérdéses tanúsítványt nem vizsgálta be valamelyik tanúsítványok hitelesítésével foglalkozó hatóság (Certificate Authority, vagy CA), akkor errõl általában kap egy figyelmeztetést a felhasználó. A tanúsítványokat hitelesítõ cégek, mint például a VeriSign, írják alá ezeket a tanúsítványokat és ezzel érvényesítik az egyes cégek vagy egyének megbízhatóságát. Ez ugyan pénzbe kerül, de használatuk egyáltalán nem is kötelezõ. Azonban az átlagosnál paranoidabb felhasználók számára megnyugvást jelenthet. Tanúsítványok elõállítása OpenSSL tanúsítványok elõállítása A tanúsítványok létrehozására a következõ parancs áll rendelkezésre: &prompt.root; openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................++++++ .......................................++++++ writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:országnév (kétbetûs kóddal) State or Province Name (full name) [Some-State]:állam vagy tartomány teljes neve Locality Name (eg, city) []:település neve Organization Name (eg, company) [Internet Widgits Pty Ltd]:szervezet neve Organizational Unit Name (eg, section) []:szervezeti egység neve Common Name (eg, YOUR name) []:általános név (hálózati név!) Email Address []:e-mail cím Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:VALAMILYEN JELSZÓ An optional company name []:egy másik szervezet neve Az adatok bekérésére elõtt megjelenõ figyelmeztetõ üzenet fordítása: Itt a tanúsítvány igénylésével kapcsolatos információkat kell megadnunk. Itt egy ún. ismertetõnevet (Distinguished Name, DN) kell megadnunk. Ezen kívül van még néhány más mezõ is, de ezeket akár üresen is hagyhatjuk. Néhány mezõnek van alapértelmezett értéke, de ha oda egy pontot írunk, akkor kitöröljük. A Common Name mezõnél ellenõrzési okokból egy hálózati nevet, tehát a szerverünk nevét kell megadnunk. Ha nem így járunk el, akkor lényegében egy használhatatlan tanúsítványt kapunk. További opciók is elérhetõek, mint például a lejárati idõ (expire time) megadása, a titkosítási algoritmus megváltoztatása stb. Ezek teljes listája megtalálható az &man.openssl.1; man oldalon. Az elõbbi parancs kiadása után két állománynak kell létrejönnie az aktuális könyvtárban. A tanúsítványkérést, vagyis az req.pem állományt kell eljuttatnunk a tanúsítványok hitelesítésével foglakozó szervhez, aki majd érvényesíti az imént megadott adatainkat. A második, cert.pem nevû állomány a tanúsítványhoz tartozó privát kulcs, amit semmilyen körülmények között sem szabad kiadnunk. Ha ez mások kezébe kerül, akkor el tudnak játszani bennünket (vagy a szerverünket). Amikor a hitelesítõ szerv aláírása nem feltétlenül szükséges, akkor készíthetünk egy saját magunk által aláírt tanúsítványt is. Ehhez elõször is generálnunk kell egy RSA-kulcsot: &prompt.root; openssl dsaparam -rand -genkey -out saját_RSA.kulcs 1024 Most pedig készítsünk el a hitelesítõ szerv kulcsát is: &prompt.root; openssl gendsa -des3 -out hitelesítõ.kulcs saját_RSA.kulcs Ezzel a kulccsal most gyártsunk le egy tanúsítványt: &prompt.root; openssl req -new -x509 -days 365 -key hitelesítõ.kulcs -out új.tanúsítvány Ekkor két új állomány keletkezik a könyvtárunkban: a hitelesítõ szerv aláírása, a hitelesítõ.kulcs és maga a tanúsítvány, az új.tanúsítvány állomány. Ezeket tegyük az /etc könyvtáron belül egy olyan könyvtárba, amelyet csak a root tud olvasni. A chmod paranccsal állítsunk be rá 0700-as kódú engedélyeket. Példa a tanúsítványok használatára Mire is jók ezek az állományok? Például kitûnõen alkalmazhatóak a Sendmail levelezõ szerverhez beérkezõ kapcsolatot titkosítására. Így lényegében felszámoljuk minden olyan felhasználó titkosítatlan módon zajló hitelesítését, aki a helyi levelezõ szerveren keresztül küldi a leveleit. Ez általában nem a legjobb megoldás, mivel egyes levelezõ kliensek hibát jeleneznek a felhasználónak, ha nem rendelkezik a tanúsítvánnyal. A tanúsítványok telepítésével kapcsolatban olvassuk el a szoftverhez adott leírást. A helyi .mc állományba ezeket a sorokat kell beletenni: dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/új.tanúsítvány')dnl define(`confSERVER_CERT',`/etc/certs/új.tanúsítvány')dnl define(`confSERVER_KEY',`/etc/certs/hitelesítõ.kulcs')dnl define(`confTLS_SRV_OPTIONS', `V')dnl Itt a /etc/certs/ az a könyvtár, amit tanúsítványok és kulcsok helyi tárolására használunk. Végezetül még újra kell generálnunk a helyi .cf állományokat. Ezt a /etc/mail könyvtárban a make install parancs kiadásával könnyen elvégezhetjük. Miután ez megtörtént, akkor Sendmailhoz tartozó démont a make restart paraméterével indíthatjuk újra. Ha minden jól ment, akkor a /var/log/maillog állományban nem találunk egyetlen hibaüzenetet sem, és a Sendmail is megjelenik a futó programok között. A &man.telnet.1; segédprogrammal így probálhatjuk ki a levelezõ szervert: &prompt.root; telnet example.com 25 Trying 192.0.34.166... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host. Ha itt megjelenik a STARTTLS sor, akkor mindent sikerült beállítanunk. Nik Clayton
nik@FreeBSD.org
 Írta: IPsec VPN IPsec felett VPN létrehozása &os; átjárók használatával két olyan hálózat között, amelyeket egymástól az internet választ el. Hiten M. Pandya
hmp@FreeBSD.org
 Írta: Az IPsec bemutatása Ebben a szakaszban az IPsec beállításának folyamatát vázoljuk fel. Az IPsec beállításához elengedhetetlen, hogy tisztában legyünk egy saját rendszermag fordításának alapjaival (lásd ). Az IPsec egy olyan protokoll, amely az Internet Protocol (IP) rétegére épül. Segítségével két vagy több számítógép képes biztonságos módon tartani egymással a kapcsolatot (innen ered a neve). A &os; IPsec hálózati protokollkészlete a KAME implementációjára épül, mely egyaránt támogatja az IPv4 és IPv6 protokollcsaládokat. IPsec ESP IPsec AH Az IPsec két alprotokollból tevõdik össze: A hasznos adat biztonságos becsomagolása (Encapsulated Security Payload, ESP) során egy szimmetrikus kriptográfiai algoritmussal (mint például Blowfish, 3DES) titkosítjuk az IP-csomagok tartalmát, ezáltal megvédjük ezeket az illetéktelenektõl. A Hitelesítési fejléc (Authentication Header, AH) használatával megakadályozzuk, hogy az illetéktelenek meghamisítsák az IP csomagok fejlécét. Ezt úgy érjük el, hogy kiszámolunk egy kriptográfiai ellenõrzõ összeget és az IP-csomagok fejlécének mezõire egy biztonságos függvénnyel generálunk valamilyen ujjlenyomatot. Az ez után következõ kiegészítõ fejléc tartalmazza ezt az ujjlenyomatot, amellyel a csomag hitelesíthetõ. Az ESP és az AH az alkalmazástól függõen használható együtt vagy külön-külön. VPN virtuális magánhálózat VPN Az IPsec akár közvetlenül is használható két számítógép forgalmának titkosítására (ezt Szállítási módnak (Transport Mode) nevezik), vagy két alhálózat között építhetünk ki vele virtuális tunneleket, ami remekül alkalmas két vállalati hálózat kommunikációjának bebiztosítására (ez a Tunnel mód (Tunnel Mode)). Ez utóbbit egyszerûen csak Virtuális magánhálózatként (Virtual Private Network, VPN) emlegetik. A &os; IPsec alrendszerérõl az &man.ipsec.4; man oldalon találhatunk további információkat. A rendszermag IPsec támogatásának aktiválásához a következõ paramétereket kell beletennünk a konfigurációs állományba: a rendszermag beállításai IPSEC options IPSEC # IP biztonság device crypto a rendszermag beállításai IPSEC_DEBUG Ha szükségünk van a IPsec nyomkövetésére, a következõ beállítást is hozzátehetjük: options IPSEC_DEBUG # az IP biztonság nyomkövetése A probléma Semmilyen szabvány nem fogalmazza meg mi is számít VPN-nek. A virtuális magánhálózatok tucatnyi különbözõ technológiával valósíthatóak meg, de mindegyiknek megvan a maga erõssége és gyengesége. Ebben a szakaszban körvonalazunk egy ilyen helyzetet, valamint a benne felépített VPN megvalósításához alkalmazott stratégiákat. A forgatókönyv: adott egy otthoni és egy vállalati hálózat, amelyek külön-külön csatlakoznak az internetre, és <acronym>VPN</acronym> használatával ezeket egyetlen hálózatként szeretnénk használni VPN létrehozása Elõfeltételezéseink a következõek: legalább két hálózatunk van; magán belül mind a két hálózat IP-t használ; mind a két hálózat egy &os; átjárón keresztül csatlakozik az internethez; a hálózatok átjárói legalább egy publikus IP-címmel rendelkeznek; a hálózatok belsõ címei lehetnek publikus vagy privát IP-címek, nem számít. Fontos viszont, hogy ezek ne ütközzenek, vagyis ne használja egyszerre mind a kettõ a 192.168.1.x címtartományt. Tom Rhodes
trhodes@FreeBSD.org
 Írta: Az IPsec beállítása &os; alatt Kezdésképpen a Portgyûjteménybõl telepítenünk kell a security/ipsec-tools portot. Ez a programcsomag rengeteg olyan alkalmazást tartalmaz, amely segítségünkre lehet a beállítások elvégzése során. A következõ lépésben létre kell hoznunk két &man.gif.4; típusú pszeudoeszközt, melyeken keresztül a két hálózat között egy tunnel segítségével ki tudjuk építeni a szükséges kapcsolatot. Ehhez root felhasználóként futtassuk a következõ parancsokat (a belsõ és külsõ megnevezésû paramétereket cseréljük ki a valós belsõ és külsõ átjárók címeire): &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 belsõ1 belsõ2 &prompt.root; ifconfig gif0 tunnel külsõ1 külsõ2 Tekintsük például, hogy a vállalati LAN publikus IP-címe 172.16.5.4, valamint a privát IP-címe 10.246.38.1. Az otthoni LAN publikus IP-címe legyen most 192.168.1.12, valamint a belsõ privát IP-címe pedig 10.0.0.5. Elsõre ez talán még nem teljesen érthetõ, ezért az &man.ifconfig.8; parancs használatával is nézzük meg a példában szereplõ hálózatok konfigurációját: Az elsõ átjáró: gif0: flags=8051 mtu 1280 tunnel inet 172.16.5.4 --> 192.168.1.12 inet6 fe80::2e0::81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 A második átjáró: gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4 Miután elvégeztük az iménti beállításokat, a &man.ping.8; paranccsal már mind a két privát IP-tartománynak elérhetõnek kell lennie, ahogy azt az alábbi példa is érzékeltetni kívánja: otthoni-halo# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes 64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms 64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms --- 10.0.0.5 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms vallalati-halo# ping 10.246.38.1 PING 10.246.38.1 (10.246.38.1): 56 data bytes 64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms 64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms 64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms 64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms 64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms --- 10.246.38.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms Az elvárásainknak megfelelõen tehát a privát címeken mind a két oldalnak képesnek kell lennie ICMP csomagokat küldenie és fogadnia. A következõ lépésben meg kell mondanunk az átjáróknak hogyan irányítsák a csomagokat a két hálózat közti forgalom megfelelõ áramlásához. Ezt az alábbi paranccsal elérhetjük el: &prompt.root; vallalati-halo# route add 10.0.0.0 10.0.0.5 255.255.255.0 &prompt.root; vallalati-halo# route add net 10.0.0.0: gateway 10.0.0.5 &prompt.root; otthoni-halo# route add 10.246.38.0 10.246.38.1 255.255.255.0 &prompt.root; otthoni-halo# route add host 10.246.38.0: gateway 10.246.38.1 Itt már a belsõ gépeket az átjárókról és az átjárók mögül egyaránt el tudjuk érni. A következõ példa alapján errõl könnyedén meg is tudunk gyõzõdni: vallalati-halo# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes 64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms 64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms 64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms 64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms 64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms --- 10.0.0.8 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms otthoni-halo# ping 10.246.38.107 PING 10.246.38.1 (10.246.38.107): 56 data bytes 64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms 64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms 64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms 64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms 64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms --- 10.246.38.107 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms A tunnelek beállítása volt igazából a könnyebb rész, egy biztonságos összeköttetés kialakítása azonban már valamivel komolyabb folyamatot rejt magában. A most következõ konfigurációban erre elõre ismert (vagyis pre-shared, PSK) RSA-kulcsokat fogunk használni. A konkrét IP-címektõl eltekintve az átjárókon a /usr/local/etc/racoon/racoon.conf állományok hasonlóan fognak kinézni, nagyjából valahogy így: path pre_shared_key "/usr/local/etc/racoon/psk.txt"; # az ismert kulcsot tartalmazó állomány helye log debug; # a naplózás részletességének beállítása: ha végeztünk a teszteléssel és a hibakereséssel, akkor állítsuk át a 'notify' értékre padding # ezeket ne nagyon változtassuk meg { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } timer # idõzítési beállítások, állítsuk be igény szerint { counter 5; interval 20 sec; persend 1; # natt_keepalive 15 sec; phase1 30 sec; phase2 15 sec; } listen # cím [port], ahol a racoon majd válaszolni fog { isakmp 172.16.5.4 [500]; isakmp_natt 172.16.5.4 [4500]; } remote 192.168.1.12 [500] { exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 172.16.5.4; peers_identifier address 192.168.1.12; lifetime time 8 hour; passive off; proposal_check obey; # nat_traversal off; generate_policy off; proposal { encryption_algorithm blowfish; hash_algorithm md5; authentication_method pre_shared_key; lifetime time 30 sec; dh_group 1; } } sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $hálózat/$hálózati_maszk $típus address $hálózat/$hálózati_maszk $típus # (a $típus lehet "any" vagy "esp") { # a $hálózat a két összekapcsolni kívánt belsõ hálózat legyen pfs_group 1; lifetime time 36000 sec; encryption_algorithm blowfish,3des,des; authentication_algorithm hmac_md5,hmac_sha1; compression_algorithm deflate; } A példában szereplõ összes opció részletes kifejtése jóval meghaladná ezen leírás kereteit, ezért a bõvebb információkkal kapcsolatban inkább a racoon beállításaihoz tartozó man oldal elolvasását javasoljuk. A gépek közti hálózati forgalom titkosításához be kell még állítanunk egy SPD házirendet is, így a &os; és a racoon képes kódolni és dekódolni a csomagokat. Ezt a most következõ, a vállalati átjárón találhatóhoz hasonló egyszerû shell szkripttel tudjuk elvégezni. Ezt az állományt a rendszer indításakor fogjuk felhasználni, melyet /usr/local/etc/racoon/setkey.conf néven mentsünk el: flush; spdflush; # Az otthoni hálózati felé spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use; spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use; Ahogy ezzel megvagyunk, a racoon az egyes átjárókon a következõ paranccsal indítható el: &prompt.root; /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log A parancs eredménye ennek megfelelõen nagyjából a következõ lesz: vallalati-halo# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf Foreground mode. 2006-01-30 01:35:47: INFO: begin Identity Protection mode. 2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:36:04: INFO: ISAKMP-SA established 72.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a 2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 72.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 92.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2) 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426) 2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b) 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66) A tunnel megfelelõ mûködését úgy tudjuk ellenõrizni, ha átváltunk egy másik konzolra és a &man.tcpdump.1; program segítségével figyeljük a hálózati forgalmat. A példában szereplõ em0 interfészt természetesen ne felejtsük el kicserélni a megfelelõ eszköz nevére. &prompt.root; tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12 Ennek hatására az alábbiakhoz hasonló adatoknak kellene megjelennie a konzolon. Amennyiben nem ez történik, valamilyen hiba történt, ezért meg kell keresnünk azt a visszakapott adatok alapján. 01:47:32.021683 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xa) 01:47:33.022442 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xb) 01:47:34.024218 IP vallalatihalozat.com > 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xc) Itt már mind a két hálózatnak elérhetõnek kell lennie és egyként kell látszódnia. A hálózatokat ezen felül még érdemes külön védeni egy tûzfallal is. Ilyenkor a csomagok két hálózati közti zavartalan oda-vissza vándorlásához további szabályokat kell még felvennünk a tûzfal szabályrendszerébe. A &man.ipfw.8; tûzfal esetén ez a következõ sorok hozzáadását jelenti a tûzfal konfigurációs állományához: ipfw add 00201 allow log esp from any to any ipfw add 00202 allow log ah from any to any ipfw add 00203 allow log ipencap from any to any ipfw add 00204 allow log udp from any 500 to any A szabályok számozását mindig az adott gép aktuális beállításainak megfelelõen kell módosítani. A &man.pf.4; és &man.ipf.8; felhasználók számára ehhez a következõ parancsot javasoljuk: pass in quick proto esp from any to any pass in quick proto ah from any to any pass in quick proto ipencap from any to any pass in quick proto udp from any port = 500 to any port = 500 pass in quick on gif0 from any to any pass out quick proto esp from any to any pass out quick proto ah from any to any pass out quick proto ipencap from any to any pass out quick proto udp from any port = 500 to any port = 500 pass out quick on gif0 from any to any Végezetül a következõ sor hozzáadásával engedélyezzük az /etc/rc.conf állományban a VPN indítását a rendszer indítása során: ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # engedélyezzük az spd házirend beállítását a rendszer indításakor racoon_enable="yes" Chern Lee Írta: OpenSSH OpenSSH biztonság OpenSSH Az OpenSSH olyan hálózati kapcsolódási eszközök összessége, amivel biztonságos módon érhetünk el távoli számítógépeket. Az rlogin, rsh, rcp és a telnet direkt kiváltására használható. Emellett SSH-n keresztül TCP/IP kapcsolatok is biztonságosan bújtathatóak vagy küldhetõek tovább. Az OpenSSH-t az OpenBSD projekt tartja karban, és az SSH 1.2.12 verziójára épül hibajavításokkal és frissítésekkel egyetemben. Az SSH 1 és 2 protokollokkal egyaránt kompatibilis. Az <application>OpenSSH</application> használatának elõnyei A hétköznapi esetben, vagyis amikor a &man.telnet.1; vagy &man.rlogin.1; alkalmazásokat használjuk, az adatok titkosítatlan formában közlekednek a hálózaton. A szerver és a kliens közé bárhova becsatlakozó hálózati kíváncsiskodók így könnyedén el tudják lopni a felhasználói nevünket és jelszavunkat, vagy lényegében bármilyen adatot, ami az adott munkamenetben megfordul. Az OpenSSH ennek kivédésére kínál fel különféle hitelesítési és titkosítási eszközöket. Az sshd engedélyezése OpenSSH engedélyezés Az sshd a &os; telepítésekor jelentkezõ Standard lehetõségek egyike. Az sshd engedélyezését úgy tudjuk kideríteni, ha az rc.conf állományban megkeressük a következõ sort: sshd_enable="YES" Ez tölti be a rendszer indításakor az &man.sshd.8;-t, az OpenSSH démonát. Vagy az /etc/rc.d/sshd &man.rc.8; szkript segítségével is elindíthatjuk az OpenSSH-t: /etc/rc.d/sshd start Az SSH kliens OpenSSH kliens Az &man.ssh.1; segédprogram az &man.rlogin.1; programhoz hasonlóan mûködik. &prompt.root; ssh felhasználó@gép.hu Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'gép.hu' added to the list of known hosts. felhasználó@gép.hu's password: ******* Az üzenetek fordítása: Nem találtam meg a gépet az ismert gépek között. Biztosan csatlakozni akarunk hozzá (igen/nem)? igen A 'gép.hu' felkerült az ismert gépek közé. Adja meg a felhasználó@gép.hu jelszavát: Bejelentkezés után minden ugyanolyan, mintha az rlogin vagy a telnet programokat használtuk volna. Az SSH egy kulcs segítségével próbálja azonosítani a számítógépeket, ezzel ellenõrzi a szerver hitelességét a kliensek csatlakozásakor. A felhasználónak ilyenkor elõször mindig yes választ kell adnia. A késõbbi bejelentkezési kísérletek pedig majd mindig az így kapott kulccsal történnek. Ha eltérne a kulcs, akkor az SSH kliens erre figyelmeztetni fog minket. A kulcsok a ~/.ssh/known_hosts vagy az SSH v2 protokoll esetén a ~/.ssh/known_hosts2 állományba kerülnek elmentésre. Alapértelmezés szerint az OpenSSH szerverek csak SSH v2 kapcsolatokat fogadnak el. Lehetõség szerint a kliens is ezt a változatot fogja használni, de ha nem sikerül, akkor megpróbálkozik a v1-el. A kliensnek a vagy opciók segítségével elõ is lehet írni, hogy az elsõ vagy a második változatot használja. A kliensben az elsõ változat támogatását csupán a régebbi verziók kompatibilitása miatt tartják karban. Biztonságos másolás OpenSSH biztonságos másolás scp Az &man.scp.1; parancs az &man.rcp.1; parancshoz hasonlóan mûködik: egyik géprõl másol a másikra, biztonságosan. &prompt.root; scp felhasználó@gép.hu:/COPYRIGHT COPYRIGHT felhasználó@gép.hu's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; Mivel a kulcsot már ismerjük ehhez a távoli géphez (az elõbbi példából), ezért az &man.scp.1; használatakor már ezzel hitelesítünk. Az &man.scp.1; paraméterei hasonlóak a &man.cp.1; parancséhoz: elsõ helyen az állomány vagy állományok neveit adjuk meg, a másodikon pedig a célt. Mivel az állományokat a hálózaton SSH-n keresztül küldik át, ezért az állományok neveit formában kell megadni. Beállítások OpenSSH beállítások Az OpenSSH démon és kliens rendszerszintû konfigurációs - állományai az /etc/ssh - könyvtárban találhatóak. + állományai az /etc/ssh könyvtárban + találhatóak. Az ssh_config tartalmazza a kliens beállításait, miközben az sshd_config tartalmazza a démonét. Emellett az rc.conf állományban megadható (ez alapból a /usr/sbin/sshd) és opciókkal további beállítási szinteket nyújtanak. ssh-keygen Jelszavak helyett az &man.ssh-keygen.1; programmal a felhasználók azonosítására DSA- vagy RSA-kulcsokat tudunk készíteni: &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/felhasználó/.ssh/id_dsa): Created directory '/home/felhasználó/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/felhasználó/.ssh/id_dsa. Your public key has been saved in /home/felhasználó/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 felhasználó@gép.hu Az &man.ssh-keygen.1; ekkor a hitelesítésre létrehoz egy publikus és egy privát kulcsból álló párt. A privát kulcs a ~/.ssh/id_dsa vagy ~/.ssh/id_rsa állományba kerül, miközben a publikus kulcs a ~/.ssh/id_dsa.pub vagy ~/.ssh/id_rsa.pub lesz attól függõen, hogy DSA vagy RSA a kulcs típusa. A módszer mûködéséhez a publikus DSA- vagy RSA-kulcsot a távoli számítógép ~/.ssh/authorized_keys állományába kell bemásolni. Így tehát a távoli számítógépre jelszavak alkalmazása helyett SSH-kulccsal tudunk belépni. Ha az &man.ssh-keygen.1; parancsnak megadunk egy jelmondatot is, akkor a felhasználó a privát kulcsát csak ennek megadásával tudja használni. A hosszú jelmondatok állandó beirogatásától a szakaszban hamarosan bemutatásra került &man.ssh-agent.1; igyekszik megkímélni minket. A különbözõ opciók és állományok eltérhetnek a számítógépünkre telepített OpenSSH verziójától függõen. Ilyen esetben javasolt felkeresni az &man.ssh-keygen.1; man oldalát. Az ssh-agent és az ssh-add Az &man.ssh-agent.1; és &man.ssh-add.1; segédprogramokkal be tudjuk tölteni az SSH-kulcsokat a memóriába, amivel elkerülhetjük a jelmondat állandó begépelését. A hitelesítést az &man.ssh-agent.1; program kezeli a betöltött privát kulcsok alapján. Az &man.ssh-agent.1; használatával egy másik programot is elindhatunk, egy parancsértelmezõtõl kezdve egy ablakkezelõig szinte bármit. Az &man.ssh-agent.1; programot úgy tudjuk egy parancsértelmezõben használni, hogy elõször is elindítjuk vele az adott parancsértelmezõt. Ezután az &man.ssh-add.1; lefuttatásával hozzá kell adnunk egy identitást, annak jelmondatának megadásával. Miután ezeket megtettük, a felhasználó bármelyik olyan távoli gépre be tud jelentkezni, ahol a publikus kulcsát ismerik. Például: &prompt.user; ssh-agent csh &prompt.user; ssh-add Enter passphrase for /home/felhasználó/.ssh/id_dsa: Identity added: /home/felhasználó/.ssh/id_dsa (/home/felhasználó/.ssh/id_dsa) &prompt.user; Az &man.ssh-agent.1; programot X11-el úgy tudjuk használni, ha az ~/.xinitrc állományba tesszük bele. Ezzel az &man.ssh-agent.1; az összes X11-ben indított program számára rendelkezésre áll. Példának vegyük ezt az ~/.xinitrc állományt: exec ssh-agent startxfce4 Így az X11 indulásakor mindig elindul az &man.ssh-agent.1;, amely pedig elindítja az XFCE alkalmazást. Miután átírtuk a saját állományunkat, a rendszer életbeléptetéséhez indítsuk újra az X11-et, az &man.ssh-add.1; futtatásával pedig töltsük be az összes SSH-kulcsunkat. Tunnelezés SSH-val OpenSSH tunnelezés Az OpenSSH-val létre tudunk hozni egy tunnelt, amellyel egy másik protokoll adatait tudjuk titkosított módon becsomagolni. Az alábbi parancs arra utasítja az &man.ssh.1; programot, hogy hozzon létre egy tunnelt a telnet használatához: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 felhasználó@izé.mizé.hu &prompt.user; Az ssh parancsnak a következõ kapcsolókat adtuk meg: Az ssh parancs a protokoll második változatát használja. (Ne adjuk meg, ha régi SSH szerverekkel dolgozunk.) Tunnel létrehozása. Ha nem adjuk meg, akkor az ssh egy hagyományos munkamenet felépítését kezdi meg. Az ssh a háttérben fusson. Egy helyi tunnel a helyiport:távoligép:távoliport felírásban. A távoli SSH szerver. Az SSH által létrehozott járatok úgy mûködnek, hogy létrehozunk egy csatlakozást a localhost (a helyi gép) megadott portján. Ezután minden olyan kapcsolatot, ami a helyi gép adott portjára érkezik, SSH-n keresztül átirányítunk a távoli gép portjára. Ebben a példában a helyi gép 5023 portját átirányítjuk a helyi gép 23 portjára. Mivel a 23 a telnet portja, ezért az így definiált SSH járattal egy biztonságos telnet munkamenetet hozunk létre. Ezen a módon tetszõleges nem biztonságos TCP protokollt, például SMTP-t, POP3-at, FTP-t stb. be tudunk csomagolni. Biztonságos tunnel létrehozása SSH-val SMTP-hez &prompt.user; ssh -2 -N -f -L 5025:localhost:25 felhasználó@levelezõ.szerver.hu felhasználó@levelezõ.szerver.hu's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 levelezõ.szerver.hu ESMTP Az &man.ssh-keygen.1; és további felhasználói hozzáférések alkalmazásával ezen a módon ki tudunk alakítani egy minden további problémától és zûrtõl mentes SSH tunnelezési környezetet. A jelszavak helyett kulcsokat használunk és minden tunnel külön felhasználóként is futtatható. Gyakorlati példák a tunnelek használatára Egy POP3 szerver biztonságos elérése Tegyük fel, hogy a munkahelyünkön van egy SSH szerver, amire kívülrõl lehet csatlakozni, illetve vele egy hálózatban van egy POP3 levelezõ szerver is. A munkahelyünk és az otthonunk között levõ hálózati útvonalat részben vagy teljesen nem tartjuk megbízhatónak. Ezért az e-mailjeinket valamilyen biztonságos módon szeretnénk elérni. Ezt úgy tudjuk megvalósítani, ha otthonról csatlakozunk a munkahelyen levõ SSH szerverre és ezen keresztül érjük a levelezõ szervert. &prompt.user; ssh -2 -N -f -L 2110:levél.gép.hu:110 felhasználó@ssh-szerver.gép.hu felhasználó@ssh-szerver.gép.hu's password: ****** Miután a tunnel létrejött és mûködõképes, állítsuk be a levelezõ kliensünkben, hogy a POP3 kéréseket a localhost 2110 portjára küldje. Innen pedig biztonságos módon megy tovább a levél.gép.hu címre. Egy szigorú tûzfal megkerülése Egyes hálózati adminisztrátorok túlságosan szigorú szabályokat adnak meg a tûzfalban, és nem csak a bejövõ kapcsolatokat szûrik, hanem a kimenõket is. A távoli gépekhez csak a 22 (SSH) és 80 (böngészés) portjaikon tudunk csatlakozni. Mi viszont szeretnénk más (nem egészen a munkánkkal kapcsolatos) szolgáltatásokat is elérni, például egy Ogg Vorbis szerverrõl zenét hallgatni. Ehhez a szerverhez viszont csak akkor tudnánk csatlakozni, ha a 22 vagy 80 portokon üzemelne. Ezt a problémát úgy oldhatjuk meg, ha felépítünk egy SSH kapcsolatot a hálózatunk tûzfalán kívül levõ számítógéppel és segítségével átbújunk az Ogg Vorbis szerverhez. &prompt.user; ssh -2 -N -f -L 8888:zene.gép.hu:8000 felhasználó@tûzfalazatlan-rendszer.gép.org felhasználó@tûzfalazatlan-rendszer.gép.org's password: ******* A zenelejátszó kliensüknek adjuk meg a localhost 8888 portját, amely pedig a tûzfal sikeres kijátszásával továbbítódik a zene.gép.hu 8000-res portjára. Az <varname>AllowUsers</varname> felhasználói beállítás Gyakran nem árt korlátozni a felhasználók bejelentkezését. Az AllowUsers erre tökéletesen megfelel. Például, ha csak 192.168.1.32 címrõl engedjük bejelentkezni a root felhasználót, akkor ehhez valami ilyesmit kell beírnunk az /etc/ssh/sshd_config állományba: AllowUsers root@192.168.1.32 Ezzel pedig csupán nevének megadásával engedélyezzük az admin felhasználó bejelentkezését (bárhonnan): AllowUsers admin Egy sorban több felhasználó is megadható, mint például: AllowUsers root@192.168.1.32 admin Ilyenkor ne felejtsük el megadni az összes bejelentkezésre (valamilyen formában) jogosult felhasználót megadni, máskülönben kizárjuk ezeket. Miután elvégeztük a szükséges változtatásokat az /etc/ssh/sshd_config állományban, utasítsuk az &man.sshd.8; démont a konfigurációs állományok újraolvasására: &prompt.root; /etc/rc.d/sshd reload Ajánlott olvasnivalók (angolul) OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; &man.sshd.8; &man.sftp-server.8; &man.sshd.config.5; Tom Rhodes Írta: ACL Az állományrendszerek hozzáféréseit vezérlõ listák A &os; 5.0 és késõbbi változatai különbözõ fejlesztéseket hoztak az állományrendszerekben, például a pillanatképek készítése vagy a hozzáférés-vezérlési listák (Access Control List, ACL-ek) támogatása. A hozzáférés-vezérlési listák a szabványos &unix;-os engedély modellt bõvítik ki egy igen kompatibilis (&posix;.1e) módon. Használatával a rendszergazdák egy sokkal kifinomultabb biztonsági modellt tudhatnak a kezük ügyében. Az UFS állományrendszerek ACL támogatását úgy tudjuk engedélyezni, ha a rendszermagot az options UFS_ACL paraméterrel fordítjuk le. Amennyiben ezt nem fordítottuk bele, akkor az ACL támogatással rendelkezõ állományrendszerek csatlakoztatása során egy figyelmeztetést kapunk. Ez az opció a GENERIC rendszermag része. Az ACL az állományrendszeren engedélyezett kiterjesztett tulajdonságokra támaszkodik. Ezeket a kiterjesztett tulajdonságokat a következõ generációs &unix; állományrendszer, az UFS2 már alapból ismeri. UFS1 típusú állományrendszereken sokkal nagyobb a kiterjesztett tulajdonságok kezelésének költsége, mint az UFS2 esetében. Az UFS2 jóval nagyobb teljesítménnyel képes dolgozni a kiterjesztett tulajdonságokkal. Emiatt a hozzáférés-vezérlési listák használatához az UFS2 sokkal inkább ajánlott, mint az UFS1. Az ACL használatát a csatlakoztatáskor megadott beállítással engedélyezhetjük, amelyet érdemes felvennünk az /etc/fstab állományba. Ha a &man.tunefs.8; segédprogrammal az állományrendszer fejlécében levõ szuperblokk ACL kapcsolóját átírjuk, akkor ez a beállítás automatikussá tehetõ. A szuperblokk használata több okból is ajánlatos: A csatlakoztatáskor megadott ACL beállítás nem változtatható egy egyszerû újracsatlakoztatással (&man.mount.8; ), csak egy teljes leválasztással (&man.umount.8;) és egy friss csatlakoztatással (&man.mount.8;). Ennek értelmében az ACL-ek a rendszerindító állományrendszeren a rendszer indulása után nem engedélyezhetõek. Ám ez azt is jelenti, hogy egy már használatban levõ állományrendszer beállításai sem változtathatóak meg. Ha a kapcsolót a szuperblokkban állítjuk be, akkor az állományrendszert még akkor is ACL támogatással csatlakoztatja a rendszer, ha azt nem adtuk meg az fstab állományban vagy az eszközeink átrendezõdtek. Így az állományrendszereket még véletlenül sem tudjuk ACL használata nélkül csatlakoztatni, ami egyébként így komoly biztonsági problémákat okozhatna. Beállíthatjuk úgy is ACL kezelését, hogy egy friss csatlakoztatás nélkül is bekapcsolható legyen, azonban az ilyen állományrendszerek ACL nélküli csatlakoztatását nem ajánljuk senkinek, mivel ha egyszer már engedélyeztük a használatukat, majd kikapcsoljuk ezeket és végül a kiterjesztett tulajdonságok törlése nélkül újra engedélyezzük, akkor nagyon könnyen pórul járhatunk. Ha elkezdtük használni az ACL-eket egy állományrendszeren, akkor ne tiltsuk le ezeket, mert az így keletkezõ állományvédelem nem feltétlenül lesz kompatibilis a felhasználók által beállítottakkal, és az ACL újraengedélyezése a változásaik elõtti korábbi ACL engedélyeket fogja visszaállítani az állományokra, aminek hatása kiszámíthatatlan. A hozzáférés-vezérlési listákat használó állományrendszerek esetén egy + (plusz) jellel ábrázolják a kiterjesztett engedélyeket. Például: drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 könyvtár1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 könyvtár2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 könyvtár3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html Láthatjuk, hogy a - könyvtár1, - könyvtár2 és - könyvtár3 + könyvtár1, + könyvtár2 és + könyvtár3 könyvtárakhoz tartoznak ACL típusú engedélyek, míg a - public_html könyvtárhoz + public_html könyvtárhoz nem. Az <acronym>ACL</acronym>-ek használata Az állományrendszerben található ACL engedélyeket a &man.getfacl.1; segédprogrammal nézhetjük meg. Például a próba állomány ACL engedélyeit a következõ paranccsal tudjuk megnézni: &prompt.user; getfacl próba #file:próba #owner:1001 #group:1001 user::rw- group::r-- other::r-- Egy állomány ACL engedélyeit a &man.setfacl.1; segédprogrammal tudjuk megváltoztatni. Figyeljük meg: &prompt.user; setfacl -k próba A opció törli az összes ACL alapú engedélyt egy állományról vagy állományrendszerrõl. Ennél viszont sokkal hasznosabb a opció használata, mivel az meghagyja az ACL mûködéséhez szükséges alapvetõ mezõket. &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- próba Ebben a fenti parancsban a opciót pedig arra használtuk, hogy módosítsuk az alapértelmezett ACL bejegyzéseket. Mivel az ezt megelõzõ parancsban teljesen töröltük még az elõredefiniált bejegyzéseket is, ez a parancs a megadott paraméterekkel kiegészítve ezeket vissza fogja állítani. Ügyeljünk arra, hogy ha olyan felhasználót vagy csoportot adunk meg, ami nem létezik a rendszerben, akkor a szabvány kimenetre egy Invalid argument hibaüzenetet kapunk. Tom Rhodes Írta: Portaudit A külsõ programok biztonsági problémáinak figyelése Az utóbbi években a biztonsági kérdésekkel foglalkozó világban számos fejlesztésre került sor a sebezhetõségi figyelmeztetések feldolgozásában. Manapság tulajdonképpen bármilyen operációs rendszer fokozott veszélynek teszik ki magát a külsõ programok telepítésével és használatával. A sebezhetõségekrõl beszámoló értesítések a biztonság egyik alapköve, azonban a &os; projekt nem tud ilyen jelentéseket kiadni a &os; alaprendszerén kívül minden egyes külsõ alkalmazáshoz. Azonban lehetõségünk van enyhíteni a külsõ csomagok sebezhetõségén és figyelmeztetni a rendszergazdákat az ismert biztonsági problémákra. A &os;-nek van egy Portaudit nevû segédprogramja, amit kizárólag erre a célra hoztak létre. A ports-mgmt/portaudit port egy adatbázist használ, ahol a &os; biztonsági csapata és a portok fejlesztõi tartják karban az ismert biztonsági problémákat. A Portaudit használatának megkezdéséhez telepítsük a Portgyûjteménybõl: &prompt.root; cd /usr/ports/ports-mgmt/portaudit && make install clean A telepítési folyamat során a &man.periodic.8; konfigurációs állományai is frissítõdnek, így a Portaudit is lefut a napi biztonsági ellenõrzések folyamán. Gondoskodjunk róla, hogy a root felhasználónak levélben elküldött a napi biztonsági értesítéseket rendesen elolvassuk. Nincs szükségünk további beállításokra. A telepítés után a rendszergazda a következõ paranccsal tudja frissíteni a saját adatbázispéldányát és megnézni a pillanatnyilag telepített csomagok ismert sebezhetõségeit: &prompt.root; portaudit -Fda Ez az adatbázis a &man.periodic.8; minden egy futásakor magától frissül, ezért ez a parancs lényegében elhagyható. Egyedül a soronkövetkezõ példákhoz kell kiadni. A Portgyûjteménybõl telepített külsõ alkalmazások megbízhatóságának ellenõrzését az alábbi parancs kiadásával bármikor elvégezhetjük: &prompt.root; portaudit -a A Portaudit ennek hatására valahogy így fogja megjeleníteni a sebezhetõ csomagokat: Affected package: cups-base-1.1.22.0_1 Type of problem: cups-base -- HPGL buffer overflow vulnerability. Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html> 1 problem(s) in your installed packages found. You are advised to update or deinstall the affected package(s) immediately. Fordítása: Érintett csomag: cups-base-1.1.22.0_1 A probléma jellege: cups-base -- HPGL puffer túlcsordulási sebezhetõség. Link: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html> A telepített csomagokkal kapcsolatban 1 problemát találtam. Javasoljuk, hogy az érintett csomagokat azonnal frissítse vagy távolítsa el. Ha a böngészõnket az itt megadott címre irányítjuk, akkor megismerhetjük a kérdéses sebezhetõség pontosabb részleteit. Ezen az oldalon megtalálhatjuk a hiba által érintett verziókat a &os; portok verziója szerint, illetve más olyan honlapokat, ahol biztonsági figyelmeztetéseket találhatunk. Röviden összefoglalva, a Portaudit egy komoly segédeszköz és hitetlenül hasznos kiegészítõje a Portupgrade portnak. Tom Rhodes Írta: a FreeBSD biztonsági figyelmeztetései A &os; biztonsági figyelmeztetései A &os; több más kereskedelmi minõségû operációs rendszerhez hasonlóan Biztonsági figyelmeztéseket (Security Advisory) ad ki. Ezek a figyelmeztetések általában megjelennek a biztonsággal foglalkozó levelezési listákon és a hivatkozott hibák kijavítása után a megfelelõ kiadások hibajegyzékében is. Ebben a szakaszban megismerjük és értelmezzük ezeket a figyelmeztetéseket, valamint megtudhatjuk, milyen lépéseket kell megtennünk a rendszerünk kijavításához. Hogyan épül fel egy figyelmeztetés? A &os; biztonsági figyelmeztetései az alább látható formában jelennek meg, amit mi most a &a.security-notifications.name; levelezési listáról kölcsönöztünk. ============================================================================= &os;-SA-XX:XX.UTIL Security Advisory The &os; Project Topic: denial of service due to some problem Category: core Module: sys Announced: 2003-09-23 Credits: Person@EMAIL-ADDRESS Affects: All releases of &os; &os; 4-STABLE prior to the correction date Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) 2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15) 2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8) 2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18) 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) CVE Name: CVE-XXXX-XXXX For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://www.FreeBSD.org/security/. I. Background II. Problem Description III. Impact IV. Workaround V. Solution VI. Correction details VII. References A Topic mezõben olvashatjuk pontosan mi is maga a probléma. Alapvetõen bemutatja az érintett biztonsági figyelmeztetést és megemlíti a sebezhetõ segédprogramot. A Category mezõ hivatkozik a rendszer azon részére, amelyre a hiba kihatással lehet. Értéke lehet core, contrib vagy ports. A core kategória azt jelzi, hogy a sebezhetõség a &os; legfontosabb komponenseit érinti. A contrib kategória a &os; projekt számára felajánlott szoftverek, mint például a sendmail sebezhetõségére utal. Végezetül a ports kategória jelzi, hogy a sebezhetõség valamelyik, a Portgyûjteményben szereplõ szoftverre érvényes. A Module mezõ a sebezhetõ komponens helyét nevezi meg, például sys. Ebben a példában azt láthatjuk, hogy a sys modul a hibás. Ezért a sebezhetõség egy rendszermagban használt komponenst érint. Az Announced mezõ a biztonsági figyelmeztetés kiadásának vagy széleskörû kihirdetésének dátumát rögzíti. Ez azt jelenti, hogy a biztonsági csapat meggyõzõdött a probléma létezésérõl és a hibát orvosoló javítás már felkerült a &os; forráskódjába. A Credits mezõ azokat az egyéneket vagy szervezeteket említi meg, akik észlelték a sebezhetõséget és jelentették. Az Affects mezõben megadják, hogy a &os; melyik kiadásaira van hatással a sebezhetõség. Ha a rendszermag esetén lefuttatjuk az ident parancsot az érintett állományokra, akkor megtudhatjuk a pontos revíziójukat. A portoknál a verziószám a port neve után szerepel a - /var/db/pkg könyvtárban. - Ha a rendszerünket nem frissítettük - CVS-rõl és fordítottuk - újra, akkor nagy a + /var/db/pkg + könyvtárban. Ha a rendszerünket nem + frissítettük CVS-rõl + és fordítottuk újra, akkor nagy a valószínûsége, hogy a sebezhetõség minket is érint. A Corrected mezõ tartalmazza a a kijavítás dátumát, idejét, idõzónáját és az ezt tartalmazó kiadást. Az ismert sebezhetõségek adatbázisában (Common Vulnerabilities Database, CVD) használt azonosítási információk alapján végzett keresések számára fenntartott. A Background mezõ adja meg részleteiben a sebezhetõ programmal kapcsolatos tudnivalókat. Az esetek többségében itt írják le, hogy miért jött létre az adott eszköz a &os;-ben, mire használják és hogyan keletkezett. A Problem Description mezõ a biztonsági rést részletezi. Ebben a részben szerepelhet a hibás kódrészlet vagy akár még az is, hogy miként kell vele elõidézni a hibát. Az Impact mezõ a probléma lehetséges hatásait írja körül a rendszerben. Ez például lehet egy DoS támadás, speciális engedélyek ellopása vagy akár a rendszeradminisztrátori jogok megszerzése. A Workaround mezõ igyekszik elfogadható megoldást nyújtani a rendszerük frissítésére képtelen rendszergazdák számára. Ennek oka lehet az idõ rövidsége, a hálózati elérhetõség vagy más okokból fakadó elcsúszás. Ennek ellenére a biztonsági kérdéseket sosem szabad félvállról venni, ezért a sebezhetõ rendszereket vagy ki kell javítani vagy valamilyen módon meg kell kerülni a biztonsági rés kialakulását. A Solution mezõ utasításokkal segít a rendszer kijavítását. Ez egy lépésrõl lépésre tesztelt és ellenõrzött módszer, amellyel a rendszerünket megfelelõen ki tudjuk javítani és biztonságossá tenni. A Correction Details mezõ mutatja a CVS-ág vagy kiadás nevét, amelyben a pontokat aláhúzásra cserélték. Ezenkívül még az egyes ágakban az érintett állományok revízióját is mutatja. A References mezõ általában a témával kapcsolatos további forrásokat kínálja fel URL, könyv, levelezési lista vagy hírcsoport formájában. Tom Rhodes Írta: a futó programok nyilvántartása A futó programok nyilvántartása A futó programok nyilvántartása olyan biztonsági módszer, ahol a rendszergazda figyelemmel kíséri a rendszer használatban levõ erõforrásait, a felhasználók közti megoszlását, gondoskodik a rendszer felügyeletérõl és valamennyire nyomon követi a felhasználók parancsait. Ennek a módszernek egyaránt megvannak a maga elõnyei és hátrányai. Az egyik elõnye, hogy a használatával a behatolás egészen a betörés pontjáig visszakövethetõ. Hátranya viszont, hogy a futó programok nyilvántartása rengeteg mennyiségû naplót generál és ehhez sok lemezterületre lesz szükségünk. Ebben a szakaszban végigjárjuk a programok nyilvántartásának alapjait. A futó programok nyilvántartásának engedélyezése és használata A futó programok nyilvántartását elõször engedélyeznünk kell. Ehhez a következõ parancsokat kell kiadnunk: &prompt.root; touch /var/account/acct &prompt.root; accton /var/account/acct &prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf Miután aktiváltuk, a nyilvántartást elkezdi számbavenni a processzor kihasználtságát, a parancsokat stb. A nyilvántartás emberek számára nem olvasható formátumban készül, ezért csak az &man.sa.8; segédprogrammal tudjuk megnézni. Ha nem adunk meg neki semmilyen opciót, akkor az sa kilistázza a felhasználónkénti hívásokat, az összes eltelt idõt percben, a teljes processzor- és felhasználói idõt percben, az I/O mûveletek átlagos számát stb. A kiadott parancsokról a &man.lastcomm.1; programmal tudunk tájékozódni. A lastcomm segítségével ki tudjuk íratni a felhasználók adott terminálon kiadott parancsait is, mint például: &prompt.root; lastcomm ls trhodes ttyp1 Ezzel megjelenik a trhodes nevû felhasználó ttyp1 terminálon kiadott összes ismert ls parancsa. Számos hasznos beállítást és hozzájuk tartozó leírást találhatunk még a &man.lastcomm.1;, &man.acct.5; és &man.sa.8; man oldalakon.