diff --git a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml index e5135af596..5b8693f19d 100644 --- a/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/firewalls/chapter.sgml @@ -1,4558 +1,4558 @@ Joseph J. Barbish Írta: Brad Davis SGML formátumúra alakította és aktualizálta: Tûzfalak tûzfalak biztonság tûzfalak Bevezetés A tûzfalakkal a rendszerünkön keresztülfolyó bejövõ és kimenõ forgalmat tudjuk szûrni. A tûzfalak egy vagy több szabályrendszer alapján vizsgálják az éppen érkezõ vagy távozó hálózati csomagokat, és vagy továbbengedik ezeket vagy megállítják. A tûzfalak szabályai a csomagok egy vagy több jellemzõjét veszik szemügyre, amelyek lehetnek például a protokoll típusa, a forrás vagy cél hálózati címe, esetleg a forrás- vagy a célport. A tûzfalak jelentõs mértékben képesek gyarapítani egy gép vagy egy hálózat védelmét. Leginkább a következõkre tudjuk felhasználni: A belsõ hálózatunkban futó alkalmazások, szolgáltatások, gépek megvédésére és elszigetelésére az internetrõl érkezõ nem kívánt forgalom ellen A belsõ hálózatban levõ gépek elérését tudjuk korlátozni vagy letiltani az interneten elérhetõ szolgáltatások felé A hálózati címfordítás (Network Address Translation, NAT) beállításához, ahol a belsõ hálózatunk privát IP-címeket használnak és egy közös kapcsolaton keresztül érik el az internetet (egyetlen IP-címmel, vagy pedig automatikusan kiosztott publikus címekkel). A fejezet elolvasása során megismerjük: hogyan adjuk meg helyesen a csomagok szûrését leíró szabályokat; a &os;-be épített tûzfalak közti különbségeket; hogyan állítsuk be és használjuk az OpenBSD PF tûzfalát; hogyan állítsuk be és használjuk az IPFILTER tûzfalat; hogyan állítsuk be és használjuk az IPFW tûzfalat. A fejezet elolvasása elõtt ajánlott: a &os;-hez és az internethez kötõdõ alapvetõ fogalmak ismerete. Röviden a tûzfalakról tûzfalak szabályrendszerei A tûzfalak szabályrendszereit alapvetõen kétféleképpen tudjuk összeállítani: inkluzív, vagyis megengedõ, illetve exkluzív vagyis kizáró módon. Az exkluzív tûzfalak minden forgalmat átengednek, amirõl nem rendelkeznek a tûzfal szabályai. Az inkluzív tûzfalak ennek pontosan az ellenkezõjét teszik. Csak azt a forgalmat engedik át, amirõl van szabály és minden mást blokkolnak. Az inkluzív tûzfalak alkalmazásával sokkal jobban kezünkbentudjuk tartani a hálózatunk kimenõ forgalmát, ezért leginkább az internetes szolgáltatásokat futtató rendszerek esetében bizonyulhat jobb választásnak. Emellett az internetrõl a hálózatunk felé irányuló forgalmat is képes szabályozni. Ekkor az egyetlen szabályra sem illeszkedõ csomagokat egyszerûen eldobjuk és naplózzuk. Az inkluzív tûzfalak általában biztonságosabbak az exkluzív típusú társaiknál, mivel esetükben jelentõs mértékben visszaszorul a nem kívánatos átfolyó forgalom. Hacsak nem emeljük ki külön, a fejezet további részében minden példaként megadott szabályrendszer inkluzív tûzfalat hoz létre. Ez a típusú védelem még tovább fokozható az állapottartó tûzfalak (stateful firewall) használatával. Az ilyen típusú tûzfalak szemmel tartják a rajtuk keresztül megnyitott kapcsolatokat, és vagy csak a már meglevõ kapcsolathoz tartozó forgalmat engedik át vagy nyitnak egy újat. Az állapottartó tûzfalak hátránya, hogy a Denial of Service (DoS) típusú támadásokkal szemben sokkal sérülékenyebbek olyan helyzetekben, amikor az új kapcsolatok nagyon gyorsan jönnek létre. A legtöbb tûzfal esetében azonban tudjuk vegyíteni az állapottartó és nem állapottartó viselkedést, és ezzel egy ideális beállítást kialakítani. Tûzfalak A &os; alaprendszerébe három különbözõ tûzfalat építettek be, melyek a következõk: az IPFILTER (másik nevén IPF), az IPFIREWALL (más néven IPFW) és az OpenBSD csomagszûrõje (Packet Filter, azaz PF). A forgalom szabályozására (vagyis alapvetõen a sávszélesség kihasználtságának vezérlésére) a &os; két beépített csomagot tartalmaz: ez az &man.altq.4; és a &man.dummynet.4;. Általában a Dummynet az IPFW, míg az ALTQ a PF partnere. Az IPFILTER esetében maga az IPFILTER végzi a címfordítást és a szûrést, a sávszélességet pedig az IPFW a &man.dummynet.4; vagy a PF az ALTQ segítségével. Az IPFW és a PF szabályokkal rendelkezik a rendszerünkbe érkezõ vagy onnan távozó csomagokról, habár megoldásaik teljesen máshogy mûködnek és a szabályok megadási módja is eltér. A &os; azért tartalmaz egyszerre ennyiféle tûzfalat, mert az emberek elvárásai és igényei eltérnek. Egyikük sem tekinthetõ a legjobbnak. A szerzõ egyébként az IPFILTER megoldását részesíti elõnyben, mivel egy hálózati címfordítást alkalmazó környezetben sokkal könnyebb vele megfogalmazni az állapottartó szabályokat, valamint tartalmaz egy beépített FTP proxyt is, amivel így a kimenõ FTP kapcsolatok beállítása még tovább egyszerûsödik. Mivel az összes tûzfal a csomagok fejlécének bizonyos mezõinek alapján dolgozik, ezért a tûzfal szabályrendszerét megalkotó egyénnek teljesen tisztában kell lennie a TCP/IP mûködésével, továbbá azzal, hogy ezekben a mezõkben milyen értékek szerepelhetnek és ezeket hogyan használják egy átlagos kapcsolat alatt. Ebben a témában a címen találhatunk egy remek ismertetõt (angolul). John Ferrell Átnézte és aktualizálta: Az OpenBSD csomagszûrõje (PF) és az <acronym>ALTQ</acronym> tûzfalak PF 2003 júliusában az OpenBSD PF néven ismert csomagszûrõjét átírták &os;-re és elérhetõvé tették a &os; Portgyûjteményének részeként. A PF programot beépítetten tartalmazó elsõ kiadás pedig 2004 novemberében a &os; 5.3 volt. A PF egy teljes, mindentudó tûzfal, amely támogatja az ún. ALTQ (Alternate Queuing, vagyis a váltóbesorolás) megoldást. Az ALTQ lehetõvé teszi a sávszélesség korlátozását a szolgáltatás minõsége (Quality of Service, QoS) alapján. Az OpenBSD Projekt kiváló munkát végez a PF felhasználói útmutatójának karbantartásával. A kézikönyv ezen szakasza ezért elsõsorban azzal foglalkozik, hogyan kell a PF-et &os; alatt használni, miközben igyekszik egy általános összefoglalást adni a témáról. A részletesebb információkkal kapcsolatban azonban feltétlenül nézzük meg a felhasználói útmutatót. A címen olvashatunk többet arról (angolul), hogy a PF-et hogyan használjunk &os;-n. A PF rendszermagmodul használata A &os; 5.3 megjelenése óta a PF az alaprendszer része mint futás közben betölthetõ rendszermagmodul. A rendszer induláskor tehát képes automatikusan betölteni, ha az &man.rc.conf.5; állományban megadjuk a pf_enable="YES" sort. A PF modul azonban csak akkor fog mûködésbe lépni, ha talál hozzátartozó szabályrendszert, amely alapértelmezés szerint az /etc/pf.conf állományban található. Amennyiben a PF szabályrendszere a mi esetünkben máshol található, akkor az rc.conf állományban ne felejtsük megadni a pf_rules="/elérési/útvonal/pf.szabályok" sor használatával. A &os; 7.0 kiadással a minta pf.conf állomány az /etc könyvtárból átkerült a /usr/share/examples/pf könyvtárba. A &os; 7.0 elõtti kiadásokban alapértelmezés szerint található egy pf.conf állomány az /etc könyvtárban. A PF modul parancssorból akár kézzel is betölthetõ: &prompt.root; kldload pf.ko A betölthetõ modul tartalmazza a &man.pflog.4; támogatását, amely segítségével naplózni is tudunk. Amennyiben a PF további szolgáltatásaira is szükségünk lenne, akkor a PF támogatását be kell építenünk a rendszermagba. A PF rendszermagbeli beállításai a rendszermag beállításai device pf a rendszermag beállításai device pflog a rendszermag beállításai device pfsync Noha egyáltalán nem szükséges beépítenünk a PF támogatását a rendszermagba, abban az esetben mégis szükségünk lehet rá, amikor a PF olyan komolyabb lehetõségeit szeretnénk kiaknázni, amelyek már nem részei a modulnak. Ilyen például a &man.pfsync.4;, amely a PF által használt állapottáblázatok bizonyos változásainak megjelenítésére alkalmas pszeudoeszköz. A &man.carp.4; megoldásával párosítva így akár hibatûrõ tûzfalak is kialakíthatóak a PF-fel. A CARP megoldásáról a kézikönyvben bõvebb ismertetést a ad. A PF rendszermag konfigurációs beállításai a /usr/src/sys/conf/NOTES állományban találhatóak: device pf device pflog device pfsync A device pf beállítás engedélyezi a csomagszûrõ tûzfalat (&man.pf.4;). A device pflog megadásával keletkezik egy &man.pflog.4; pszeudo hálózati eszköz, amellyel egy &man.bpf.4; eszközre érkezõ forgalmat tudunk naplózni. Ezután a &man.pflogd.8; démon használható tõle származó naplózott adatok rögzítésére. A device pfsync engedélyezi a &man.pfsync.4; pszeudo hálózati eszköz létrejöttét, amely az ún. állapotváltások megfigyelésére alkalmas. Az <filename>rc.conf</filename> állományban elérhetõ beállítások A következõ &man.rc.conf.5; beállítások aktiválják a rendszerindítás során a PF és a &man.pflog.4; használatát: pf_enable="YES" # a PF engedélyezése (a modul betöltése, ha kell) pf_rules="/etc/pf.conf" # a pf szabályait tartalmazó állomány pf_flags="" # a pfctl indításához szükséges további paraméterek pflog_enable="YES" # a pflogd(8) elindítása pflog_logfile="/var/log/pflog" # hol tartsa a pflogd az naplóit pflog_flags="" # a pflogd indításához szükséges paraméterek Ha a tûzfalunk mögött egy helyi hálózat is meghúzódik, akkor az ott levõ gépek számára valamilyen módon tudnunk kell továbbítani a csomagokat vagy címfordítást kell végezni, így ez is mindenképpen kelleni fog: gateway_enable="YES" # az átjáró funkciók engedélyezése A szûrési szabályok megfogalmazása A PF a beállításait a &man.pf.conf.5; állomány tárolja (amely alapértelmezés szerint az /etc/pf.conf helyen található), és az ebben található szabályok alapján módosítja, dobja el vagy éppen engedi át a csomagokat. A &os; rendszerünkben ehhez találhatunk néhány példát a /usr/share/examples/pf/ könyvtárban. A PF által használt szabályokról minden részletre kiterjedõen a PF felhasználói útmutatójában olvashatunk. A PF felhasználói útmutatójának olvasásakor ne feledkezzünk meg róla, hogy a különbözõ &os; verziók különbözõ PF verziókat tartalmaznak: &os; 5.X — OpenBSD 3.5 PF &os; 6.X — OpenBSD 3.7 PF &os; 7.X — OpenBSD 4.1 PF A &a.pf; remek hely a PF tûzfal beállításával és futtatásával kapcsolatos kérdésekre. A kérdezés elõtt azonban ne felejtsük el alaposan átnézni az archívumot! A PF használata A PF a &man.pfctl.8; segítségével vezérelhetõ. Az alábbiakban ezzel kapcsolatban most összefoglalunk néhány hasznos parancsot (de ne felejtsük el megnézni a &man.pfctl.8; man oldalon található többi lehetõséget sem): Parancs Leírás pfctl A PF engedélyezése pfctl A PF tiltása pfctl all /etc/pf.conf Az összes (címfordítási, szûrési, állapottartási stb.) szabály törlése, és az /etc/pf.conf állomány újratöltése pfctl [ rules | nat | state ] A szûrési (rules), címfordítási (nat) és állapottartási (state) információk lekérdezése pfctl /etc/pf.conf Az /etc/pf.conf állomány ellenõrzése a benne levõ szabályok betöltése nélkül Az <acronym>ALTQ</acronym> engedélyezése Az ALTQ kizárólag csak úgy használható, ha a konfigurációs beállításokon keresztül beépítjük a &os; rendszermagjába. Az ALTQ alkalmazását nem minden hálózati kártya meghajtója támogatja, ezért ezt a &man.altq.4; man oldalon ellenõrizzük. A következõ rendszermag konfigurációs beállításokkal engedélyezhetjük az ALTQ használatát és bõvíthetjük azt további lehetõségekkel: options ALTQ options ALTQ_CBQ # osztályozás alapú besorolás (Class Bases Queuing, CBQ) options ALTQ_RED # véletlen korai észlelés (Random Early Detection, RED) options ALTQ_RIO # RED befele/kifele options ALTQ_HFSC # hiearchikus csomagütemezõ (Hierarchical Packet Scheduler, HFSC) options ALTQ_PRIQ # prioritásos besorolás (Priority Queuing, PRIQ) options ALTQ_NOPCC # az SMP esetén kell Az options ALTQ az ALTQ rendszert engedélyezi. Az options ALTQ_CBQ engedélyezi a osztályozás alapú besorolást (Class Based Queuing, CBQ). A CBQ használatával a kapcsolatunkhoz tartozó sávszélességet különbözõ osztályokra vagy sorokra tudjuk bontani és a szûrési szabályoknak megfelelõen osztályozni segítségükkel a forgalmat. Az options ALTQ_RED a véletlen korai észlelés (Random Early Detection, RED) használatát engedélyezi. A RED a hálózati forgalomban keletkezõ torlódások elkerülésére alkalmas. A RED ezt a problémát úgy oldja meg, hogy méri a sorok hosszát és összeveti a hozzátartozó minimális és maximális küszöbértékekkel. Ha a sor hossza meghaladja a számára elõírt maximális értéket, akkor az új csomagokat eldobja. Nevéhez hûen a RED az eldobásra ítélt csomagokat véletlenszerûen választja ki. Az options ALTQ_RIO engedélyezi a RED használatát mind a két irányba, tehát be- és kifelé. Az options ALTQ_HFSC a pártatlan hierachikus szolgáltatási görbe alapú csomagütemezõt (Hierarchical Fair Service Curve Packet Scheduler, HFSC) engedélyezi. Vele kapcsolatban a címen találhatunk bõvebben olvasnivalót (angolul). Az options ALTQ_PRIQ a prioritásos besorolást (Priority Queuing, PRIQ) teszi elérhetõvé. A PRIQ mindig elsõként a nagyobb értékû sorban levõ forgalmat továbbítja. Az options ALTQ_NOPCC az ALTQ SMP, vagyis többprocesszoros támogatását adja meg. Ilyen típusú rendszerekben ez kötelezõ. Az IPFILTER (IPF) tûzfal tûzfalak IPFILTER Az IPFILTER szerzõje Darren Reed. Az IPFILTER nem kötõdik egyik rendszerhez sem: ez egy olyan nyílt forráskódú alkalmazás, amelyet átírtak &os;, NetBSD, OpenBSD, &sunos;, HP/UX és &solaris; operációs rendszerekre. Az IPFILTER karbantartása és támogatása pillanatnyilag is aktív, folyamatosan jelennek meg újabb változatai. Az IPFILTER egy rendszermag oldalán mûködõ tûzfalazási és egy címfordítási mechanizmusra alapszik, amelyet felhasználói programokkal tudunk felügyelni és vezérelni. A tûzfal szabályai az &man.ipf.8; segédprogrammal állíthatóak be vagy törölhetõek. A hálózati címfordításra vonatkozó szabályokat az &man.ipnat.1; segédprogrammal állíthatjuk be vagy törölhetjük. Az &man.ipfstat.8; segédprogram képes futás közben statisztikákat készíteni az IPFILTER rendszermagban elhelyezkedõ részeinek viselkedésérõl. Az &man.ipmon.8; program pedig az IPFILTER cselekvéseit képes a rendszernaplókba feljegyezni. Az IPF eredetileg olyan szabályfeldolgozási módszer szerint készült, amelyben az utolsó egyezõ szabály nyer és csak állapotnélküli szabályokat ismert. Az idõ múlásával az IPF részévé vált a quick opció és a keep state opción keresztül az állapottartás is, melyek drámai mértékben korszerûsítették a szabályok feldolgozásának elvét. Az IPF hivatalos dokumentációja csak a régi szabályok létrehozását és azok feldolgozásának leírását tartalmazza. A korszerûsített funkciók csak kiegészítésképpen jelennek meg, és az általuk felkínált elõnyök megértése egy sokkal magasabb szintû és biztonságosabb tûzfal megépítését teszik lehetõvé. A szakaszban szereplõ utasításokban olyan szabályok szerepelnek, amelyek kihasználják a quick és keep state opciókat. Ezek az inkluzív tûzfalszabályok létrehozásának alapjai. A régi típusú szabályokról a és címeken olvashatunk (angolul). Az IPF gyakran ismételt kérdései a címen érhetõek el (angolul). A nyílt forrású IPFILTER levelezési lista kereshetõ archívumait a címen találjuk (angolul). Az IPF engedélyezése IPFILTER engedélyezés Az IPF megtalálható a &os; alaptelepítésében mint menet közben külön betölthetõ modul. Ha az rc.conf állományba beírjuk a ipfilter_enable="YES" sort, akkor ez a modul dinamikusan betöltõdik. A betölthetõ modul alapból naplóz és a default pass all beállítást tartalmazza. Ha helyette a block all szabályt akarjuk használni, akkor emiatt még nem kell feltétlenül újrafordítanunk a &os; rendszermagját, elég ha egyszerûen csak a szabályrendszerünk végére beszúrjuk. A rendszermag beállításai a rendszermag beállításai IPFILTER a rendszermag beállításai IPFILTER_LOG a rendszermag beállításai IPFILTER_DEFAULT_BLOCK IPFILTER a rendszermag beállításai Az IPF használatához nem kötelezõ a következõ beállításokkal újrafordítani a &os; rendszermagját, itt csupán háttérinformációként szerepel. Amikor az IPF a rendszermagba kerül, a betölhetõ modulra nem lesz szükség. Az IPF a rendszermag forrásai között található /usr/src/sys/conf/NOTES állományban megadott beállításai a következõ módon foglalhatóak össze: options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK Az options IPFILTER engedélyezi az IPFILTER tûzfal támogatását. Az options IPFILTER_LOG hatására az IPF az ipl csomagnaplózó pszeudo eszközre jegyzi fel a forgalmat — minden olyan szabály esetén, ahol megjelenik a log kulcsszó. Az options IPFILTER_DEFAULT_BLOCK megváltoztatja az alapértelmezett viselkedést, tehát minden olyan csomag, amely nem illeszkedik a tûzfal valamelyik pass típusú (átengedõ) szabályára, blokkolásra kerül. Ezek a beállítások csak azt követõen érvényesülnek, ha fordítottunk és telepítettünk velük egy új rendszermagot. Az <filename>rc.conf</filename> állomány beállításai Az /etc/rc.conf állományban a következõ utasításokra lesz szükségünk az IPF mûködésbe hozására a rendszer indítása során: ipfilter_enable="YES" # az ipf tûzfal indítása ipfilter_rules="/etc/ipf.rules" # betölti a szabályokat tartalmazó szöveges állományt ipmon_enable="YES" # elindítja az IP monitor naplózását ipmon_flags="-Ds" # D = indítás démonként # s = naplózás a syslog használatával # v = a tcp ablak, ack, seq csomagok naplózása # n = az IP-címek és portok feloldása Ha olyan helyi hálózat áll meg a tûzfal mögött, amely egy fenntartott privát IP-címtartományt használ, akkor még a következõ utasításokra is szükségünk lesz a címfordítás bekapcsolásához: gateway_enable="YES" # a helyi hálózat átjárója ipnat_enable="YES" # az ipnat funkció elindítása ipnat_rules="/etc/ipnat.rules" # az ipnat mûködéséhez szükséges definíciók IPF ipf Az &man.ipf.8; parancs használható a szabályokat tartalmazó állomány betöltésére. Általában egy állományba írjuk össze a tûzfal szabályait és ezzel a paranccsal cseréljük le egyszerre a tûzfalban levõ jelenlegi szabályokat: &prompt.root; ipf -Fa -f /etc/ipf.rules Az az összes belsõ szabály törlését jelenti. Az jelzi, hogy egy állományból kell beolvasni a betöltendõ szabályokat. Ezzel mintegy lehetõségünk van változtatni a korábban összeállított szabályainkon, futtatni a fenti IPF parancsot és ezen keresztül úgy frissíteni a szabályok friss másolatával a már mûködõ tûzfalat, hogy nem is kell újraindítanunk a rendszert. Ez a módszer igen kényelmes az új szabályok kipróbálásához, mivel bármikor tetszõlegesen végrehajtható. Az &man.ipf.8; man oldala tartalmazza a parancsnak megadható további beállításokat. Az &man.ipf.8; parancs a szabályokat tároló állományt egy szabványos szöveges állománynak tekinti, semmilyen szimbolikus helyettesítést alkalmazó szkriptet nem fogad el. Lehetõségünk van azonban olyan IPF szabályokat készíteni, amelyek kiaknázzák a szkriptek szimbolikus helyettesítésének lehetõségeit. Errõl bõvebben lásd . Az IPFSTAT ipfstat IPFILTER statisztika Az &man.ipfstat.8; alapértelmezés szerint a arra használatos, hogy le tudjuk kérdezni és megjeleníteni a tûzfalhoz tartozó számlálók értékeit, amelyek a legutóbbi indítás vagy az ipf -Z parancs által kiadott lenullázásuk óta a bejövõ vagy kimenõ forgalomból a megadott szabályoknak megfelelõ csomagok alapján gyûjtenek össze statisztikákat. A parancs mûködésének részleteit az &man.ipfstat.8; man oldalon olvashatjuk. Az &man.ipfstat.8; meghívása alapból így néz ki: input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 input packets logged: blocked 99286 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 log failures: input 3898 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 169364 lost 0 packet state(out): kept 431395 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Result cache hits(in): 1215208 (out): 1098963 IN Pullups succeeded: 2 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0) Az mint bejövõ (inbound), vagy az mint kimenõ (outbound) forgalomra vonatkozó paraméterek megadásával a rendszermagban az adott oldalon jelenleg telepített és alkalmazott szabályokat kérhetjük le és jeleníthetjük meg. Az ipfstat -in parancs így a bejövõ forgalomra vonatkozó belsõ szabályokat mutatja a szabályok számával. Az ipfstat -on parancs a kimenõ forgalmat érintõ belsõ szabályokat mutatja a szabályok számával. Az eredmény körülbelül ilyen lesz: @1 pass out on xl0 from any to any @2 block out on dc0 from any to any @3 pass out quick on dc0 proto tcp/udp from any to any keep state Az ipfstat -ih a bejövõ forgalomhoz tartozó belsõ szabályokat mutatja és mindegyik elé odaírja, hogy eddig mennyi csomag illeszkedett rájuk. Az ipfstat -oh ugyanígy a kimentõ forgalom esetén mutatja a belsõ szabályokat és mindegyik elõtt feltünteti, hogy az adott pillanatig mennyi csomag illeszkedett rájuk. A kimenete nagyjából ilyen lesz: 2451423 pass out on xl0 from any to any 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state Az ipfstat parancs talán egyik legfontosabb funkciója a kapcsolóval csalható elõ, melynek hatására a rendszerben aktív állapotok táblázatát mutatja meg ugyanúgy, ahogy a &man.top.1; a &os; rendszerben futó programokat. Amikor a tûzfalunk támadás alatt áll, ezzel a funkcióval tudjuk a problémát beazonosítani, leásni a mélyébe és látni a támadótól érkezõ csomagokat. A kiegészítésképpen megadható alkapcsolók megadásával kiválaszthatjuk azt a cél vagy forrás IP-címet, portot vagy protokollt, amelyet valós idõben meg akarunk figyelni. Ennek részleteit az &man.ipfstat.8; man oldalán láthatjuk. Az IPMON ipmon IPFILTER naplózás Az ipmon megfelelõ mûködéséhez be kell kapcsolnunk a rendszermag IPFILTER_LOG beállítását. Ez a parancs két különbözõ módban használható. Ha parancsot a opció nélkül gépeljük be, akkor ezek közül alapból a natív módot kapjuk meg. A démon mód abban az esetben hasznos, ha folyamatosan naplózni akarjuk a rendszerben zajló eseményeket, majd késõbb ezeket átnézni. Így képes egymással együttmûködni a &os; és az IPFILTER. A &os; beépítve tartalmaz olyan lehetõséget, aminek révén magától cseréli a rendszernaplókat. Ezért ha átküldjük a &man.syslogd.8; démonnak a naplózandó üzeneteket, akkor sokkal jobban járunk, mintha egyszerûen csak mezei állományba naplóznánk. Az rc.conf alapértelmezései között az ipmon_flags beállítás a kapcsolókat rögzíti: ipmon_flags="-Ds" # D = indítás démonként # s = naplózás a syslog használatával # v = a tcp ablak, ack, seq csomagok naplózása # n = az IP-címek és portok nevének feloldása Ennek a viselkedésnek az elõnyei minden bizonnyal egyértelmûek. Segítségével képesek vagyunk az esetek megtörténte után átnézni, hogyan milyen csomagokat dobott el a rendszer, azok milyen címekrõl érkeztek és hova szánták. Ez egy komoly fegyver a támadók lenyomozásában. Hiába engedélyezzük a naplózást, az IPF önszántából semmilyen naplózási szabályt nem fog gyártani. A tûzfal gazdájának kell eldöntenie, hogy a szabályokat közül melyiket akarja naplózni, és így neki kell megadnia a log kulcsszót ezekben az esetekben. Normális esetben csak a deny szabályokat naplózzák. Egyáltalán nem ritka, hogy a szabályrendszer végén egy alapértelmezés szerint mindent eldobó szabály áll, amely naplóz. Ezzel lehetõségünk nyílik rögzíteni azokat a csomagokat, amelyek egyetlen szabályra sem illeszkedtek. Naplózás az IPMON használatával A syslogd egy saját módszert alkalmaz a naplózott adatok elkülönítésére. Egy funkciók (facility) és szintek (level) segítségével kialakított speciális csoportosítást alkalmaz. Az IPMON módja a security (biztonság) funkciót használja. Tehát az IPMON által naplózott összes adat a security csoportjába kerül. Ezen túl a következõ szinteken különíthetjük el igényeinknek megfelelõen a naplózott adatokat: LOG_INFO - az átengedés vagy blokkolás helyett a "log" kulcsszóval ellátott csomagok LOG_NOTICE - az át is engedett csomagok LOG_WARNING - a blokkolt csomagok LOG_ERR - a naplózott csomagok közül azok, amelyek túlságosan kicsik (hibás a fejlécük) Az IPFILTER csak akkor tud naplózni a /var/log/ipfilter.log állományba, ha elõtte létrehozzuk. Az alábbi parancs erre tökéletesen megfelelõ: &prompt.root; touch /var/log/ipfilter.log A &man.syslogd.8; mûködését az /etc/syslog.conf állományban szereplõ definíciók vezérlik. A syslog.conf állomány számottevõ mértékben képes meghatározni azt, ahogy a syslog az IPF és a hozzá hasonló alkalmazásoktól kapott rendszerszintû üzeneteket kezeli. Az /etc/syslog.conf állományba az alábbi sor kell felvennünk: security.* /var/log/ipfilter.log A security.* megadásával az összes ilyen típusú üzenet egy elõre rögzített helyre kerül. Az /etc/syslog.conf állományban elvégzett módosításokat úgy léptethetjük érvénybe, ha újraindítjuk a számítógépet vagy az /etc/rc.d/syslogd reload paranccsal megkérjük a &man.syslogd.8; démont, hogy olvassa újra az /etc/syslog.conf állományt. Az imént létrehozott naplót ne felejtsük el megadni az /etc/newsyslog.conf állományban sem, és akkor ezzel a cseréjét is megoldjuk. A naplózott üzenetek formátuma Az ipmon által létrehozott üzenetek whitespace karakterekkel elválasztott adatmezõkbõl állnak. A következõ mezõk az összes üzenet esetében megjelennek: A csomag megérkezésének dátuma A csomag megérkezésének idõpontja. ÓÓ:PP:MM.E alakban jelennek meg az órák, percek, másodpercek és ezredmásodpercek (ez több számjegy hosszú is lehet) szerint Azon interfész a neve, ahol a csomag feldolgozásra került, például dc0 A szabályhoz tartozó csoport és sorszám, például @0:17 Ezek az ipfstat -in paranccsal nézhetõek meg. Cselekvés: a p mint átment (passed), b mint blokkolt (blocked), S mint rövid csomag (short packet), n mint egyik szabályra sem illeszkedett (not match), L mint naplózás (log). A módosítók megjelenítésének sorrendje: S, p, b, n, L. A nagybetûs P és B azt jelzi, hogy a csomagot egy felsõbb szintû beállítás miatt naplózták, nem egy szabály hatására. Címek: ez tulajdonképpen három mezõt takar: a forrás címet és portot (melyet egy vesszõ választ el), a -> jelet és cél címet és portot. Például: 209.53.17.22,80 -> 198.73.220.17,1722. A PR után a protokoll neve vagy száma olvasható, például PR tcp. A len csomaghoz tartozó fejléc és törzsének teljes hosszát jelöli, például len 20 40. Amennyiben a csomag TCP, egy kötõjellel kezdõdõen további mezõk is megjelenhetnek a beállított opcióknak megfelelõ betûk képében. A betûket és beállításaikat az &man.ipmon.8; man oldalán olvashatjuk. Amennyiben a csomag ICMP, a sort két mezõ zárja, melyek közül az elsõ tartalma mindig ICMP, és ezt egy perjellel elválasztva az ICMP üzenet típusa és altípusa követi. Tehát például az ICMP 3/3 a nem elérhetõ port üzenetet hordozza. A szabályok felírása szimbolikus helyettesítéssel Az IPF használatában gyakorlott felhasználók közül néhányan képesek olyan stílusú szabályrendszert készíteni, ahol szimbolikus helyettesítést használnak. Ennek az egyik legnagyobb elõnye az, hogy ilyenkor elég csak a szimbolikus névhez tartozó értéket megváltoztatni és amikor a szkript lefut, akkor az összes rá hivatkozó szabályba ez kerül be. Szkript lévén a szimbolikus helyettesítéssel ki tudjuk emelni a gyakran használt értékeket és behelyettesíteni ezeket több helyre. Ezt a most következõ példában láthatjuk. Az itt alkalmazott felírás kompatibilis az &man.sh.1;, &man.csh.1; és &man.tcsh.1; parancsértelmezõkkel. A szimbolikus helyettesítést egy dollárjellel fejezzük ki: $. A szimbolikus mezõkben nem szerepel a $ jelölés. A szimbolikus mezõ tartalmát kettõs idézõjelbe (") tesszük. Kezdjük így el a szabályok írását: ######### Az IPF szabályait tartalmazó szkript eleje ########### oif="dc0" # a kimenõ interfész neve odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe myip="192.0.2.7" # a szolgáltatótól kapott statikus IP-címünk ks="keep state" fks="flags S keep state" # Választhatunk, hogy az /etc/ipf.rules állományt ebbõl a szkriptbõl # hozzuk létre vagy futtathatjuk "magát" a szkriptet. # # Egyszerre csak az egyik sort használjuk. # # 1) Ezzel gyárhatjuk le az /etc/ipf.rules állományt: #cat > /etc/ipf.rules << EOF # # 2) Ezzel futtathajuk "magát" a szkriptet: /sbin/ipf -Fa -f - << EOF # Engedélyezzük a szolgáltató névszerverének elérését. pass out quick on $oif proto tcp from any to $odns port = 53 $fks pass out quick on $oif proto udp from any to $odns port = 53 $ks # Engedélyezzük kifelé a titkosítatlan www funkciót. pass out quick on $oif proto tcp from $myip to any port = 80 $fks # Engedélyezzük kifelé a TLS SSL felett üzemelõ titkosított www funkciót. pass out quick on $oif proto tcp from $myip to any port = 443 $fks EOF ################## Itt az IPF szkript vége ######################## Ennyi lenne. A példában szereplõ szabályok most nem annyira lényegesek, a hangsúly most igazából a szimbolikus helyettesítésen és annak használatán van. Ha a fenti példát az /etc/ipf.rules.script állományba mentjük, akkor ezeket a szabályokat a következõ paranccsal újra tudjuk tölteni: &prompt.root; sh /etc/ipf.rules.script Egyetlen aprócska gond van a beágyazott szimbólumokat tartalmazó állományokkal: az IPF maga nem képes megérteni a helyettesítéseket, azért közvetlenül nem olvassa a szkriptet. Ez a szkript két módon hasznosítható: Vegyük ki megjegyzésbõl a cat paranccsal kezdõdõ sort, és tegyük megjegyzésbe az /sbin/ipf kezdetût. A megszokottak szerint tegyük az ipfilter_enable="YES" sort az /etc/rc.conf állományba, majd minden egyes módosítása után futtassuk le a szkriptet az /etc/ipf.rules állomány létrehozásához vagy frissítéséhez. Tiltsuk le az IPFILTER aktiválását a rendszerindításkor, tehát írjuk bele az ipfilter_enable="NO" sort (ami mellesleg az alapértelmezett értéke) az /etc/rc.conf állományba. Tegyünk egy, az alábbi szkripthez hasonlót az /usr/local/etc/rc.d/ könyvtárba. A szkriptnek adjuk valamilyen értelmes nevet, például ipf.loadrules.sh. Az .sh kiterjesztés használata kötelezõ. #!/bin/sh sh /etc/ipf.rules.script A szkript engedélyeit állítsuk be úgy, hogy a root tulajdonában legyen és képes legyen olvasni, írni valamint végrehajtani. &prompt.root; chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh Most miután a rendszer elindult, az IPF szabályai be fognak töltõdni. Szabályrendszerek az IPF-ben Az IPF esetében a szabályrendszer olyan szabályokból áll, amelyek a csomagokról tartalmuk alapján eldöntik, hogy át kell engedni vagy vissza kell tartani. A gépek közt két irányban áramló csomagok egy munkamenet alapú társalgást képeznek. A tûzfalhoz tartozó szabályrendszer egyaránt feldolgozza a internetrõl a hálózatunk felé igyekvõ csomagokat, illetve a hálózatunk ezekre adott válaszait. Az egyes TCP/IP szolgáltatásokat (mint például telnet, www, levelezés stb.) a hozzájuk tartozó protokol és szabványos (fogadó) portszám írja le. Ezekre a forrásról általában valamilyen nem szabványos (magasabb értékû) portról érkeznek csomagok. Ekkor a kommunikáció összes paramétere (vagyis a portok és címek) bármelyike alapján definiálhatunk blokkolást vagy továbbengedést leíró szabályokat. IPFILTER a szabályok feldolgozásának sorrendje Az IPF eredetileg úgy íródott, hogy a szabályokat az utolsó illeszkedõ szabály nyer stílusban dolgozza fel és csak állapot nélküli szabályokat ismert. Az idõk folyamán az IPF szabályai kiegészültek a quick és az állapottartásra vonatkozó keep state opciókkal, amelynek köszönhetõen óriási mértékben korszerûsödött a szabályok feldolgozása. A szakaszban szereplõ utasítások olyan szabályokat alkalmaznak, amelyekben egyaránt szerepel a quick és az állapottartásért felelõs keep state beállítás. Ez az inkluzív tûzfalak létrehozásának egyik alapeszköze. A tûzfal szabályainak összeállítása során nagyon óvatosnak kell lennünk! Bizonyos beállítások hatására akár ki is zárhatjuk magunkat a szerverünkrõl. Az ebbõl fakadó esetleges kellemetlenségek elkerülése érdekében javasoljuk, hogy a tûzfal alapjait elõször helyi konzolról építsük fel, ne pedig távolról, például ssh segítségével. A szabályok felépítése IPFILTER a szabályok felépítése A szabályok felépítésének bemutatását itt most leszûkítjük a modern állapottartó szabályokra és az elsõ illeszkedõ szabály nyer típusú feldolgozásra. A szabályok felírásának régebbi módjai az &man.ipf.8; man oldalon találhatóak. A # karakterrel egy megjegyzés kezdetét jelezzük, és általában a sor végén vagy egy külön sorban bukkan fel. Az üres sorokat a rendszer nem veszi figyelembe. A szabályok kulcsszavakat tartalmaznak. Ezeknek a kulcsszavaknak balról jobbra haladva adott sorrendben kell szerepelniük. A kulcsszavakat kiemeltük. Egyes kulcsszavakhoz további beállítások is tartozhatnak, amelyek maguk is kulcsszavak lehetnek, és még további opciókkal rendelkezhetnek. Az alábbi nyelvtan mindegyik elemét kiemeltük és az alábbiakban egyenként kifejtjük a részleteiket. CSELEKVÉS BE-KI OPCIÓK SZÛRÉS ÁLLAPOTTARTÓ PROTOKOLL FORRÁS_CÍM,CÉL_CÍM OBJEKTUM PORTSZÁM TCP_BEÁLLÍTÁS ÁLLAPOTTARTÓ CSELEKVÉS = block | pass BE-KI = in | out OPCIÓK = log | quick | on interfész SZÛRÉS = proto érték | forrás/cél IP | port = szám | flags beállítás PROTOKOLL = tcp/udp | udp | tcp | icmp FORRÁS_CÍM,CÉL_CÍM = all | from objektum to objektum OBJEKTUM = IP-cím | any PORTSZÁM = portszám TCP_BEÁLLÍTÁS = S ÁLLAPOTTARTÓ = keep state CSELEKVÉS A cselekvés határozza meg, hogy mit kell tenni azokkal a csomagokkal, amelyek illeszkednek a szabály többi részére. Minden szabályhoz tartoznia kell egy cselekvésnek. A következõ cselekvések közül választhatunk: A block megadásával a szabályban szereplõ szûrési feltételre illeszkedõ csomagot eldobjuk. A pass megadásával a szabályban szereplõ szûrési feltételre illeszkedõ csomagot átengedjük a tûzfalon. BE-KI Az összes szûrési szabály esetében kötelezõ egyértelmûen nyilatkozunk arról, hogy a bemenõ vagy a kimenõ forgalomra vonatkozik. Ezért a következõ kulcsszó vagy az in vagy pedig az out, de közülük egyszerre csak az egyiket szabad használni, máskülönben a szabály hibásnak minõsül. Az in jelenti, hogy a szabályt az internet felõl az adott interfészen beérkezõ csomagokra kell alkalmazni. Az out jelenti, hogy a szabályt az internet felé az adott interfészen kiküldött csomagokra kell alkalmazni. OPCIÓK Ezek az opciók csak a lentebb bemutatott sorrendben használhatók. A log jelzi, hogy illeszkedés esetén a csomag fejlécét az ipl eszközön keresztül naplózni kell (lásd a naplózásról szóló szakaszt). A quickjelzi, hogy illeszkedés esetén ez lesz a legutolsónak ellenõrzött szabály és így egy olyan rövidzárat tudunk képezni a feldolgozásban, amellyel elkerüljük a csomagra egyébként vonatkozó többi szabály illesztését. Ez az opció a korszerûsített szabályfeldolgozás kihasználásához elengedhetetlen. Az on használatával a szûrés feltételei közé bevonhatjuk a csomaghoz tartozó hálózati interfészt. Itt az interfészek az &man.ifconfig.8; által megjelenített formában adhatóak meg. Az opció megadásával csak az adott interfészen az adott irányba (befelé/kifelé) közlekedõ csomagokra fog illeszkedni a szabály. Ez az opció a korszerûsített szabályfeldolgozás kihasználásához nélkülözhetetlen. Amikor naplózunk egy csomagot, akkor a hozzátartozó fejléc az IPL csomagnaplózó pszeudo eszközhöz kerül. A log kulcsszó után közvetlenül a következõ minõsítõk szerepelhetnek (a következõ sorrendben): A body jelzi, hogy a csomag tartalmának elsõ 128 byte-ját még jegyezzük fel a fejléc mellé. A first minõsítõt akkor érdemes használnunk, amikor a log kulcsszót a keep state opcióval együtt alkalmazzuk, mivel ilyenkor csak a szabályt kialakító csomag kerül naplózásra és nem minden olyan, ami illeszkedik az állapottartási feltételekre. SZÛRÉS Ebben a szakaszban olyan kulcsszavak jelenhetnek meg, amelyekkel a csomagok különféle tulajdonságai alapján ítélkezhetünk azok illeszkedésérõl. Itt adott egy kiinduló kulcsszó, amelyhez további kulcsszavak is tartoznak, és amelyek közül csak egyet választhatunk. Az alábbi általános tulajdonságok alapján tudjuk szûrni a csomagokat, ebben a sorrendben: PROTOKOLL A proto egy olyan kulcsszó, amelyhez hozzá kell rendelnünk még valamelyik opcióját is. Ez az opció segít az adott protokolloknak megfelelõen válogatni a csomagok között. A korszerûsített szabályfeldolgozás lehetõségeinek kihasználásához nélkülözhetetlen. Opcióként a tcp/udp | udp | tcp | icmp, vagy bármelyik, az /etc/protocols állományban megtalálható kulcsszó felhasználható. A tcp/udp ebbõl a szempontból speciálisnak tekinthetõ, mivel hatására egyszerre illeszthetõek a szabályra a TCP és UDP csomagok, és így a protokolltól eltekintve azonos szabályok felesleges többszörözését kerülhetjük el. FORRÁS_CÍM/CÉL_CÍM Az all kulcsszó gyakorlatilag a from any to any (bárhonnan bárhova) szinonímája és nem tartozik hozzá paraméter. A from forrás to cél felépítése: a from és to kulcsszavak az IP-címek illesztésére használhatóak. Ilyenkor a szabályokban a forrás és a cél paramétereknek is szerepelniük kell. Az any egy olyan speciális kulcsszó, amely tetszõleges IP-címre illeszkedik. Néhány példa az alkalmazására: from any to any vagy from 0.0.0.0/0 to any, from any to 0.0.0.0/0, from 0.0.0.0/0 to any vagy from any to 0.0.0.0. Az IP-címek megadhatóak pontozott numerikus formában a hálózati maszk bitekben mért hosszával együtt, vagy akár egyetlen pontozott numerikus IP-címként. Nincs lehetõség olyan IP-címtartományok illesztésére, amelyek nem adhatóak meg kényelmesen ponttal elválasztott számok és maszk hosszával. A net-mgmt/ipcalc port az ilyen számításokat könnyíti meg. A hálózati maszkok hosszának megállapításban segíthet az említett segédprogram (angol nyelvû) honlapja: . PORT Amikor portra vonatkozó illeszkedést írunk elõ, megadhatjuk a forrásra és célra, amit aztán vagy csak TCP vagy pedig csak UDP csomagokra alkalmazunk. A portok feltételeinek megfogalmazásánál használhatjuk a portok számát vagy az /etc/services állományban szereplõ nevüket. Amikor a port egy from típusú objektum leírásában jelenik meg, akkor automatikusan a forrásportot jelenti, míg a to objektum leírásában pedig a célportot. A to objektumoknál a port megadása elengedhetetlen a korszerûsített szabályfeldolgozás elõnyeinek kihasználásához. Példa: from any to any port = 80. Az egyes portokat különbözõ mûveletek segítségével, numerikusan hasonlíthatjuk össze, ahol akár porttartományt is megadhatunk. port "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" | "gt" | "le" | "ge". A porttartományok megadásához használjuk a port "<>" | "><" felírási módot. A forrásra és célra vonatkozó paraméterek után szereplõ másik két paraméter nélkülözhetetlen a korszerûsített szabályfeldolgozás mûködéséhez. <acronym>TCP</acronym>_BEÁLLÍTÁS A beállítások csak a TCP forgalom szûrésénél érvényesülnek. A betûk jelölik azokat a lehetséges beállításokat, amelyek a TCP csomagok fejlécében megvizsgálhatóak. A korszerûsített szabályfeldolgozás a flags S paraméter segítségével ismeri fel a TCP munkameneteket kezdeményezõ kéréseket. ÁLLAPOTTARTÓ A keep state jelzi, hogy a szabály paramétereinek megfelelõ bármely csomag aktiválja az állapottartó szûrés használatát. Ez a beállítás feltétlenül szükséges a korszerûsített szabályfeldolgozás megfelelõ kihasználásához. Állapottartó csomagszûrés IPFILTER állapottartó szûrés Az állapottartó szûrés a csomagok kétirányú áramlását egy létrejött kapcsolatba sorolja be. Amikor aktiválódik, az állapottartó szabály elõre dinamikusan létrehozza a kétirányú kommunikációban megforduló csomagokhoz a megfelelõ belsõ szabályokat. Olyan vizsgálatokat végez, amelyek segítségével ki tudja deríteni, hogy a csomag küldõje és címzettje között fennálló kétirányú kapcsolat érvényes szabályok szerint zajlik-e. Minden olyan csomagot, amely nem illeszkedik megfelelõen a kapcsolatra vonatkozó sémára, csalásnak tekintjük és automatikusan eldobjuk. Az állapottartás révén lehetõségünk van a TCP vagy UDP kapcsolatokhoz tartozó ICMP csomagokat is átengedni a tûzfalon. Tehát ha kapunk egy 3-as típusú, 4-es kódú ICMP választ valamilyen böngészésre használt állapottartó szabályon keresztül kiküldött kérésre, akkor az automatikusan bejöhet. Amelyik csomagot az IPF egyértelmûen képes besorolni az aktív kapcsolatba, még ha az eltérõ protokollt is használ, beengedi. Ami ilyenkor történik: Az internethez csatlakozó interfészen keresztül kifelé haladó csomagokat elõször egy dinamikus állapottábla alapján illesztjük, és ha a csomag illeszkedik az aktív kapcsolatban következõként várt csomagra, akkor átmegy a tûzfalon és a dinamikus állapottáblában frissül a kapcsolat állapota. Az aktív munkameneten kívül csomagok pedig egyszerûen a kimenõ szabályrendszer szerint kerülnek ellenõrzésre. Hasonlóan az elõzõhöz, az internethez csatlakozó interfészen keresztül befelé haladó csomagokat elõször egy dinamikus állapottábla alapján illesztjük, és ha a csomag illeszkedik az aktív kapcsolatban következõként várt csomagra, akkor átmegy a tûzfalon és a dinamikus állapottáblában frissül a kapcsolat állapota. Az aktív munkamenethez nem tartozó csomagok pedig egyszerûen a bejövõ szabályrendszer szerint kerülnek ellenõrzésre. Amikor egy kapcsolat befejezõdik, automatikusan törlõdik a dinamikus állapottáblából. Az állapottartó csomagszûrés használatával az újonnan keletkezõ kapcsolatok elutasítására vagy engedélyezésére tudunk koncentrálni. Ha engedélyeztük egy új kapcsolat létrejöttét, akkor a rákövetkezõ összes többi csomag automatikusan átmegy a tûzfalon és minden más hamis csomag eldobódik. Ha tiltjuk az új kapcsolatot, akkor egyetlen rákövetkezõ csomag sem juthat át. Az állapottartó szûrés által felkínált fejlett elemzési lehetõségek képesek védelmet nyújtani a behatolók részérõl alkalmazott megannyi különbözõ támadási módszer ellen. Példa inkluzív szabályrendszerre A most következõ szabályrendszer arra mutat példát, hogyan programozzunk le egy nagyon biztonságos inkluzív tûzfalat. Az inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik keresztül, és alapértelmezés szerint minden mást blokkolnak. Egy hálózat gépeit védõ tûzfalnak, amelyet gyakran hálózati tûzfalnak (network firewall) is neveznek, legalább két hálózati interfésszel kell rendelkeznie. Ezeket az interfészeket általában úgy állítják be, hogy tökéletesen megbíznak az egyik oldalban (a helyi hálózatban), a másikban (az internetben) pedig egyáltalán nem. A tûzfalat egyébként úgy is beállíthatjuk, hogy csak a tûzfalat mûködtetõ gépet védje — ezt egyrendszeres tûzfalnak (host based firewall) nevezik. Az ilyen típusú megoldásokat nem biztonságos hálózaton keresztül kommunikáló szervereknél alkalmaznak. Mindegyik &unix;-típusú rendszert, köztük a &os;-t is úgy alakították ki, hogy az operációs rendszeren belüli kommunikáció az lo0 interfészen és a 127.0.0.1 IP-címen keresztül történik. A tûzfal szabályai között feltétlenül szerepelniük kell olyanoknak, amelyek lehetõvé teszik ezen a speciális intefészen a csomagok zavartalan mozgását. Az internetre csatlakozó interfészhez kell rendelni a kifelé és befelé haladó forgalom hitelesítését é a hozzáférésének vezérlését. Ez lehet a felhasználói PPP által létrehozott tun0 interfész vagy a DSL-, illetve kábelmodemhez csatlakozó hálózati kártya. Ahol egy vagy több hálózati kártya is csatlakozik több különbözõ helyi hálózathoz, úgy kell beállítani a hozzájuk tartozó interfészeket, hogy egymás felé és az internet felé képesek legyenek küldeni és fogadni. A szabályokat elõször három nagy csoportba kell szerveznünk: elõször jönnek a megbízható interfészek, ezeket követik az internet felé mutató interfészek, végül internet felõl jövõ, nem megbízható interfészeke. Az egyes csoportokban szereplõ szabályokat úgy kell megadni, hogy közülük elõre kerüljenek a leggyakrabban alkalmazottak, és a csoport utolsó szabálya blokkoljon és naplózzon minden csomagot az adott interfészen és irányban. A kimenõ forgalomat vezérlõ szabályrendszer csak pass (tehát átengedõ) szabályokat tartalmazhat, amelyek bentrõl az interneten elérhetõ szolgáltatásokat azonosítják egyértelmûen. Az összes ilyen szabályban meg kell jelenni a quick, on, proto, port és keep state beállításoknak. A proto tcp szabályok esetében meg kell adni a flag opciót is, amivel fel tudjuk ismertetni a kapcsolatok keletkezését és ezen keresztül aktiválni az állapottartást. A bejövõ forgalmat vezérlõ szabályrendszerben elõször az eldobni kívánt csomagokat kell megadni, aminek két eltérõ oka van. Elõször is elõfordulhat, hogy a veszélyes csomagok részleges illeszkedés miatt szabályosnak tûnnek. Az ilyen csomagokat értelemszerûen nem lenne szabad beengedni a szabályok részleges megfelelése alapján. A másodszor az eleve ismerten problémás és értelmetlen csomagokat csendben el kellene vetni, mielõtt a szakaszhoz tartozó utolsó szabály fogná meg és naplózná. Ez az utolsó szabály egyébként szükség esetén felhasználható a támadók elleni bizonyítékok begyûjtésére. A másik, amire még oda kell figyelnünk, hogy a blokkolt csomagok esetében semmilyen válasz nem keletkezzen, egyszerûen csak tûnjenek el. Így a támadó nem fogja tudni, hogy a csomagjai vajon elérték-e a rendszerünket. Minél kevesebb információt tudnak összegyûjteni a rendszerünkrõl a támadók, annál több idõt kell szánniuk csínytevéseik kieszelésére. A log first opciót tartalmazó szabályok csak az illeszkedésnél fogják naplózni a hozzájuk tartozó eseményt. Erre láthatunk példát az nmap OS fingerprint szabálynál. Az security/nmap segédprogramot a támadók gyakran alkalmazzák a megtámadni kívánt szerver operációs rendszerének felderítésére. Minden log first opcióval megadott szabály illeszkedésénél a ipfstat -hio parancs meghatározódik az eddigi illeszkedések aktuális száma. Nagyobb értékek esetében következtethetünk arra, hogy a rendszerünket megtámadták (vagyis csomagokkal árasztják éppen el). Az ismeretlen portszámok felderítésére az /etc/services állomány, esetleg a (angol nyelvû) honlap használható. Érdemes továbbá megnézni a trójai programok által használt portokat a címen (angolul). A következõ szabályrendszer egy olyan biztonságos inkluzív típusú tûzfal, amelyet éles rendszeren is használnak. Ezt a rendszerünkön nem használt szolgáltatásokra vonatkozó pass szabályok törlésével könnyedén a saját igényeink szerint alakíthatjuk. Ha nem akarunk látni bizonyos üzeneteket, akkor vegyünk fel hozzájuk egy block típusú szabályt a befelé irányuló forgalomhoz tartozó szabályok közé. A szabályokban írjuk át a dc0 interfész nevét annak a hálózati kártyának az interfészére, amelyen keresztül csatlakozunk az internethez. A felhasználói PPP esetében ez a tun0 lesz. Tehát a következõket kell beírni az /etc/ipf.rules állományba: ################################################################# # A helyi hálózatunkon zajló forgalmat ne korlátozzuk. # Csak akkor kell, ha helyi hálózathoz is csatlakozunk. ################################################################# #pass out quick on xl0 all #pass in quick on xl0 all ################################################################# # A belsõ interfészen szintén ne korlátozzunk semmit. ################################################################# pass in quick on lo0 all pass out quick on lo0 all ################################################################# # Az internet felé forgalmazó interfész (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################# # Engedélyezzük az internet szolgáltatók névszerverének elérését, # az "xxx" helyett a névszervet IP-címét kell megadni. # Másoljuk le ezeket a sorokat, ha a szolgáltatónknak több # névszerverét is beakarjuk állítani. A címeiket az /etc/resolv.conf # állományban találjuk. pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state pass out quick on dc0 proto udp from any to xxx port = 53 keep state # DSL vagy kábeles hálózatoknál engedélyezzük a # szolgáltatónk DHCP szerverének elérését. # Ez a szabály nem kell, ha "felhasználói PPP"-vel # kapcsolódunk az internethez, ilyenkor tehát az egész # csoport törölhetõ. # Használjuk az alábbi szabályt és keressük meg a naplóban az # IP-címet. Ha megtaláltuk, akkor tegyük bele a megjegyzésben # szereplõ szabályba és töröljük az elsõ szabályt. pass out log quick on dc0 proto udp from any to any port = 67 keep state #pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state # Kifelé engedélyezzük a szabványos nem biztonságos WWW funkciókat. pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state # Kifelé engedélyezzük a biztonságos WWW funkciókat TLS SSL # protokollal. pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state # Kifelé engedélyezzük az e-mailek küldését és fogadását. pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state # Kifelé engedélyezzük az idõ szolgáltatást. pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state # Kifelé engedélyezzük az nntp híreket. pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state # Kifelé engedélyezzük az átjáróról és a helyi hálózatról a nem # biztonságos FTP használatát (passzív és akív módokban is). Ez a # funkció a mûködéséhez a nat szabályokat tartalmazó állományban # hivatkozott FTP proxyt használja. Amennyiben a pkg_add paranccsal # csomagokat akarunk telepíteni az átjáróra, erre a szabályra # mindenképpen szükségünk lesz. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state # Kifelé engedélyezzük az ssh/sftp/scp # (biztonságos telnet/rlogin/FTP) # szolgáltatások # elérését az SSH (secure shell) használatával. pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state # Kifelé engedélyezzük a nem biztonságos telnet elérését. pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state # Kifelé engedélyezzük FreeBSD CVSUp funkcióját. pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state # Kifelé engedélyezzük a pinget. pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state # Kifelé engedélyezzük a helyi hálózatról érkezõ whois kéréseket. pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state # Minden mást eldobunk és naplózzuk az elsõ elõfordulásukat. # Ez a szabály blokkol alapértelmezés szerint mindent. block out log first quick on dc0 all ################################################################# # Az internet felõli interfész (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################# # Eldobjuk az összes olyan bejövõ forgalmat, amit hivatalosan nem # lehetne továbbítani vagy fenntartott címterülethez tartozik. block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918: privát IP block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918: privát IP block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918: privát IP block in quick on dc0 from 127.0.0.0/8 to any #helyi block in quick on dc0 from 0.0.0.0/8 to any #helyi block in quick on dc0 from 169.254.0.0/16 to any #DHCP block in quick on dc0 from 192.0.2.0/24 to any #dokumentációs célokra fenntartva block in quick on dc0 from 204.152.64.0/23 to any #Sun klaszterek összekötésére használt block in quick on dc0 from 224.0.0.0/3 to any #D és E osztályú multicast ##### Itt eldobunk egy rakás csúf dolgot ############ # Ezeket nem akarjuk a naplóban látni: # Eldobjuk a töredékcsomagokat. block in quick on dc0 all with frags # Eldobjuk a túlságosan rövid TCP csomagokat. block in quick on dc0 proto tcp all with short # Eldobjuk a forrás által közvetített (source routed) csomagokat. block in quick on dc0 all with opt lsrr block in quick on dc0 all with opt ssrr # Elutasítjuk az "OS fingerprint" kéréseket. # Naplózzuk az elsõ elõfordulást, így nálunk lesz a kíváncsiskodó # egyén IP-címe. block in log first quick on dc0 proto tcp from any to any flags FUP # Eldobunk mindent, aminek speciális beállításai vannak. block in quick on dc0 all with ipopts # Elutasítjuk a publikus pinget. block in quick on dc0 proto icmp all icmp-type 8 # Elutasítjuk az ident kéréseket. block in quick on dc0 proto tcp from any to any port = 113 # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. block in log first quick on dc0 proto tcp/udp from any to any port = 137 block in log first quick on dc0 proto tcp/udp from any to any port = 138 block in log first quick on dc0 proto tcp/udp from any to any port = 139 block in log first quick on dc0 proto tcp/udp from any to any port = 81 # Engedélyezzük a szolgáltatónk DHCP szerverétõl érkezõ forgalmat. # Ebben a szabályban meg kell adnunk a szolgáltató DHCP szerverének # IP-címét, mivel itt csak a hiteles forrásból fogadunk el csomagokat. # Erre csak DSL- és kábelmodemes kapcsolat esetében van szükség, a # "felhasználói PPP" alkalmazása során szükségtelen. Ez az IP-cím # megegyezik a kimenõ kapcsolatoknál megadott címmel. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state # Befelé engedélyezzük a szabványos WWW funkciót, mivel webszerverünk # van. pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state # Befelé engedélyezzük az internetrõl érkezõ nem biztonságos telnet # kapcsolatokat. Azért nem biztonságos, mert az azonosítókat és # jelszavakat titkosítatlan formában közli az interneten keresztül. # Töröljük ezt a szabályt, ha nem használunk telnet szervert. #pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state # Befelé engedélyezzük az internetrõl # érkezõ ssh/sftp/scp (biztonságos # telnet/rlogin/FTP) # kapcsolatokat az SSH (secure shell) használatával. pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state # Minden mást dobjuk el és naplózzuk az elsõ elõfordulásukat. # Az elsõ alkalom naplózásával elejét tudjuk venni a "Denial of # Service" típusú támadásoknak, amivel egyébként lehetséges lenne a # napló elárasztása. # Ez a szabály blokkol alapértelmezés szerint mindent. block in log first quick on dc0 all ################### Itt van a szabályok vége ############################## <acronym>NAT</acronym> NAT IP maszkolás NAT hálózati címfordítás NAT A NAT jelentése Network Address Translation, vagyis hálózati címfordítás. A &linux; esetében ezt IP masqueradingnak, vagyis IP maszkolásnak hívják. A hálózati címfordítás és az IP maszkolás lényegben ugyanazt takarja. Az IPF címfordításért felelõs funkciójának köszönhetõen képesek vagyunk a tûzfal mögött elhelyezkedõ helyi hálózat számára megosztani az internet-szolgáltatól kapott publikus IP-címet. Sokakban felmerülhet a kérdés, hogy erre vajon mi szükségünk lehet. Az internet-szolgáltatók a magánszemélyeknek általában dinamikus IP-címeket osztanak ki. A dinamikus itt arra utal, hogy a címünk minden alkalommal változik, amikor betárcsázunk a szolgáltatóhoz vagy amikor ki- és bekapcsoljuk a modemünket. Ez a dinamikus IP-cím fog azonosítani minket az interneten. Most tegyük fel, hogy öt gépünk van otthon, viszont csak egyetlen elõfizetéssel rendelkezünk. Ebben az esetben öt telefonvonalat kellene használnunk és mindegyik géphez elõfizetni az internetre. A hálózati címfordítás alkalmazásával azonban mindössze egyetlen elõfizetés kell. A gépek közül négyet hozzákötünk egy switch-hez és a switch-et pedig a fennmaradó géphez, amelyen &os; fut. Ez utóbbi lesz az így kialakított helyi hálózatunk átjárója. A tûzfalban mûködõ címfordítás segítségével a helyi hálózaton található gépek IP-címeit észrevétlenül át tudjuk fordítani a hálózatunk publikus IP-címére, ahogy a csomagok elhagyják az átjárót. A beérkezõ csomagok esetében mindez visszafelé történik meg. Az IP-címek közül adott egy tartomány, amit a címfordítást használó helyi hálózatok részére tartanak fenn. Az RFC 1918 szerint az alábbi IP-címtartományok használhatók a helyi hálózatban, mivel ezeken keresztül közvetlenül sosem lehet kijutni az internetre: Kezdõ IP: 10.0.0.0 - Záró IP: 10.255.255.255 Kezdõ IP: 172.16.0.0 - Záró IP: 172.31.255.255 Kezdõ IP: 192.168.0.0 - Záró IP: 192.168.255.255 IP<acronym>NAT</acronym> NAT IPFILTER ipnat A címfordításra vonatkozó szabályokat az ipnat paranccsal tudjuk betölteni. Az ilyen típusú szabályokat általában az /etc/ipnat.rules állományban találjuk. A részleteket lásd az &man.ipnat.1; man oldalán. Amikor a címfordítás üzembe helyezése után meg akarjuk változtatni a címfordítás szabályait, elõször a címfordítás szabályait tartalmazó állományt módosítsuk, majd a belsõ címfordítási szabályok és a címfordítási táblázatban szereplõ aktív bejegyzések törléséhez futassuk le az ipnat parancsot a beállítással. A címfordítási szabályok újratöltését egy ehhez hasonló paranccsal tudjuk elvégezni: &prompt.root; ipnat -CF -f /etc/ipnat.szabályok A címfordításhoz tartozó statisztikákat ezzel a paranccsal tudjuk lekérdezni: &prompt.root; ipnat -s A címfordítási táblázatban pillanatnyilag szereplõ összerendeléseket a következõ paranccsal tudjuk listázni: &prompt.root; ipnat -l A szabályok feldolgozásával és az aktív szabályokkal/bejegyzésekkel kapcsolatos információk részletezését így engedélyezhetjük: &prompt.root; ipnat -v A címfordítási szabályok A címfordítási szabályok nagyon rugalmasak és rengeteg olyan funkciót meg tudunk velük valósítani, ami az üzleti és otthoni felhasználók számára egyaránt hasznos. Itt most a szabályok felépítését csak egyszerûsítve mutatjuk be, leginkább a nem üzleti környezetek tekintetében. A szabályok komplett formai leírását az &man.ipnat.5; man oldalán találjuk. Egy címfordítási szabály tehát valahogy így néz ki: map INTERFÉSZ HELYI_IP_TARTOMÁNY -> PUBLIKUS_CÍM A szabályt a map kulcsszó kezdi. A INTERFÉSZ helyére az internet felé mutató külsõ interfész nevét írjuk be. A HELYI_IP_TARTOMÁNY lesz az, amelyben a kliensek címeznek. Ez például a 192.168.1.0/24. A PUBLIKUS_CÍM lehet egy külsõ IP-cím vagy a 0/32 speciális kulcsszó, amellyel a FELÜLET-hez rendelt IP-címre hivatkozunk. Hogyan mûködik a hálózati címfordítás A publikus cél felé haladó csomag megérkezik a helyi hálózatról. Miután a kimenõ kapcsolatokra vonatkozó szabályok átengedik, a címfordítás kapja meg a szerepet és fentrõl lefelé haladva nekilát alkalmazni a saját szabályait, ahol az elsõ egyezõ szerint cselekszik. A címfordítás a szabályokat a csomaghoz tartozó interfészre és a forrás IP-címére illeszti. Amikor a csomag interfészének neve illeszkedik egy címfordítási szabályra, akkor ezután a csomag forrás (vagyis a helyi hálózaton belüli) IP-címérõl igyekszik eldönteni, hogy a szabály nyilának bal oldalán szereplõ tartományba esik-e. Ha erre is illeszkedik, akkor a forrás IP-címét átírjuk a 0/32 kulcsszó alapján felderített publikus IP-címre. A címfordító rutin ezt feljegyzi a saját belsõ táblázatába, így amikor a csomag visszatér az internetrõl, akkor képes lesz visszafordítani az eredeti belsõ IP-címére és feldolgozásra átadni a tûzfal szabályainak. A címfordítás engedélyezése A címfordítás életre keltéséhez a következõket kell beállítanunk az /etc/rc.conf állományban. Elõször engedélyezzük a gépünknek, hogy közvetítsen forgalmat az interfészek között: gateway_enable="YES" Minden alkalommal indítsuk el a címfordításért felelõs IPNAT programot: ipnat_enable="YES" Adjuk meg az IPNAT számára a betöltendõ szabályokat: ipnat_rules="/etc/ipnat.rules" Hálózati címfordítás nagyon nagy helyi hálózatok esetében Az olyan helyi hálózatokban, ahol rengeteg PC található vagy több alhálózatot is tartalmaz, az összes privát IP-cím egyetlen publikus IP-címbe tömörítése igen komoly problémává tud dagadni és az azonos portok gyakori használata a helyi hálózatra kötött számítógépek között ütközéseket okoz. Két módon tudunk megoldást nyújtani erre a problémára. A használható portok kiosztása Egy normális címfordítási szabály valahogy így nézne ki: map dc0 192.168.1.0/24 -> 0/32 A fenti szabályban a csomag forrásportját az IPNAT változatlanul a feldolgozás után hagyja. Ha ehhez még hozzátesszük a portmap kulcsszót, akkor ezzel utasítani tudjuk az IPNAT-ot, hogy csak az adott tartományban képezze le a forrásportokat. Például a következõ szabály hatására az IPNAT a forrásportokat egy adott tartományon belül fogja módosítani: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 Ha viszont még inkább meg akarjuk könnyíteni a dolgunkat, akkor itt egyszerûen csak adjuk meg az auto kulcsszót, amellyel az IPNAT önmagától megállapítja, hogy milyen portokat tud használni: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto Több publikus cím használata Minden nagyobb helyi hálózat esetében elérkezünk ahhoz a ponthoz, ahol már egyetlen publikus cím nem elég. Ha több publikus IP-címmel is rendelkezünk, akkor ezekbõl a címekbõl egy közös készletet hozhatunk létre, amibõl majd az IPNAT válogathat miközben a csomagok címeit átírja kifelé menetben. Például ahelyett, hogy a csomagokat egyetlen publikus IP-címre képeznénk le, ahogy itt tesszük: map dc0 192.168.1.0/24 -> 204.134.75.1 A hálózati maszk segítségével meg tudjuk adni IP-címek egy tartományát is: map dc0 192.168.1.0/24 -> 204.134.75.0/255.255.255.0 CIDR-jelöléssel: map dc0 192.168.1.0/24 -> 204.134.75.0/24 A portok átirányítása Gyakran elõfordul, hogy van webszerverünk, levelezõ szerverünk, adatbázis szerverünk és névszerverünk, melyek a helyi hálózat különbözõ gépein futnak. Ebben az esetben a szerverekhez tartozó forgalmat is fordítanunk kell, illetve valamilyen módon a bejövõ forgalmat is át kell irányítanunk a helyi hálózat megfelelõ gépeihez. Az IPNAT ezt a gondot a hálózati címfordítás átirányítást támogató funkcióival szünteti meg. Tegyük fel, hogy a 10.0.10.25 belsõ címen van egy webszerverünk, amelyhez a 20.20.20.5 publikus IP tartozik. Ilyenkor a következõ szabályt adjuk meg: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 vagy: rdr dc0 0.0.0.0/0 port 80 -> 10.0.10.25 port 80 Így tudjuk beállítani a 10.0.10.33 címmel rendelkezõ névszervert a kintrõl érkezõ névfeloldási kérések fogadására: rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp Az FTP és a címfordítás Az FTP egy olyan õskövület, amely még az internet egy régi korszakából maradt fenn, amikor az egyetemek között még bérelt vonal létezett és az FTP szolgált a kutatók közt az állományok megosztására. Ez még abban az idõben történt, amikor a biztonság egyáltalán nem volt lényeges szempont. Az évek elõrehaladtával az FTP protokoll beleivódott a feltörekvõ internet gerincébe és a titkosítatlanul küldött azonosítóival és jelszavaival továbbra is ugyanolyan védtelen maradt. Az FTP két változatban, aktív és passzív módban képes mûködni. Az eltérés kettejük között az adatcsatorna megállapításában van. A passzív mód sokkal biztonságosabb, mivel ilyenkor az adatcsatornát az FTP kapcsolatot kezdeményezõ állítja be. Az FTP különbözõ módjainak magyarázatát és a köztük levõ különbséget a címen ismerhetjük meg részleteiben (angolul). Az IPNAT szabályai Az IPNAT egy speciális beépített FTP proxyval rendelkezik, amelyre a hálózati címfordítás leképezései között hivatkozhatunk. Képes figyelni az összes aktív vagy passzív FTP kapcsolathoz tartozó kimenõ kérést és ezekhez dinamikusan létrehozni olyan ideiglenes szûrési szabályokat, amelyek valóban csak az adatcsatornához felhasznált portokat tartalmazzák. Ezzel ki tudjuk küszöbölni az FTP azon káros hatását a tûzfalra nézve, hogy egyszerre túlságosan sok magasabb tartománybeli port legyen nyitva. Ez a szabály a belsõ hálózat összes FTP forgalmát lekezeli: map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp Ez a szabály pedig az átjáróról érkezõ FTP forgalommal bírkózik meg: map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp Ez a szabály kezeli a belsõ hálózatról érkezõ összes nem FTP típusú forgalmat: map dc0 10.0.10.0/29 -> 0/32 Az FTP leképzésére vonatkozó szabály a szokásos leképzési szabály elé kerül. Az összes csomag fentrõl haladva az elsõ illeszkedõ szabály alapján kerül feldolgozásra. Elõször az interfész nevét vizsgáljuk, majd a belsõ hálózatbeli forrás IP-t, végül azt, hogy a csomag egy FTP kapcsolat része. Ha minden paraméterében megfelel, akkor az FTP proxy készít egy ideiglenes szûrési szabályt hozzá, amellyel az FTP kapcsolathoz tartozó csomagok mind a két irányba képesek lesznek vándorolni, természetesen a címfordítással együtt. Az összes többi bentrõl érkezõ csomag átlép ezen a szabályon és megáll a harmadiknál, ahol az interfésznek és forrás IP-nek megfelelõen átfordítjuk a címét. Az IPNAT szûrési szabályai FTP-re Az FTP esetében csak egyetlen szûrési szabályra van szükségünk a hálózati címfordításba épített FTP proxy használatához. FTP proxy nélkül az alábbi három szabály kellene: # Kifelé engedélyezzük a belsõ gépek FTP elérést az internet irányába, # aktív és passzív módokban. pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state # Kifelé engedélyezzük a passzív módhoz tartozó magasabb tartománybeli # adatcsatornákat. pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state # Aktív módban beengedjük az FTP szervertõl érkezõ adatcsatornát. pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state IPFW tûzfalak IPFW Az IPFIREWALL (IPFW) a &os; által támogatott tûzfalazó alkalmazás, melyet a &os; Projektben résztvevõ önkéntesek fejlesztettek ki és tartanak karban. Régi típusú, állapottartás nélküli szabályokat használ, és az itt használatos szabályírási technikát egyszerû állapottartó megoldásnak nevezzük. Az IPFW szabvány &os;-ben levõ, mintaként szolgáló szabályrendszere (ez az /etc/rc.firewall és /etc/rc.firewall6 állományokban található meg) annyira egyszerû, hogy komolyabb módosítások nélkül nem ajánlatos használni. Ez a példa nem tartalmaz állapottartó szûrést, ami viszont a legtöbb esetben kívánatos lenne, ezért ezt a szakaszt nem erre alapozzuk. Az IPFW állapottartás nélküli szabályainak felépítésében olyan technikailag kifinomult leválogatási képességek bújnak meg, amelyek jócskán meghaladják az átlagos tûzfalépítõk tudását. Az IPFW elsõsorban olyan szakemberek vagy szakmailag elõrehaladott felhasználók számára készült, akiknek speciális csomagszûrési igényeik vannak. A különbözõ protokollok használatának és a hozzájuk tartozó fejlécinformációk mindenre kiterjedõ ismerete szinte nélkülözhetetlen az IPFW valódi erejének kihasználásához. Ez a szint azonban túlmutat a kézikönyv ezen szakaszának keretein. Az IPFW hét komponensbõl épül fel, melyek közül az elsõdleges a rendszermag tûzfalazásért felelõs szabályfeldolgozó és a hozzátartozó csomagnyilvántartás, majd ezt követi a naplózás, a hálózati címfordítást aktiváló divert szabály, valamint a komolyabb célok megvalósítására alkalmas lehetõségek: a forgalom korlátozásáért felelõs dummynet, a továbbküldésre alkalmas fwd rule szabály, a hálózati hidak támogatása, illetve az ipstealth. Az IPFW egyaránt használható IPv4 és IPv6 esetén. Az IPFW engedélyezése IPFW engedélyezése Az IPFW az alap &os; telepítésben külön, futás idõben betölthetõ modulként érhetõ el. Ha az rc.conf állományban megadjuk a firewall_enable="YES" beállítást, akkor a rendszer indulásakor ezt a modult dinamikusan betölti. Az IPFW-t csak akkor kell a &os; rendszermagjába beépítenünk, ha szükségünk van a címfordítási funkciójára is. Ha tehát az rc.conf állományban megadtuk a firewall_enable="YES" sort és újraindítottuk a számítógépünket, akkor a következõ fehérrel kiemelt üzenet fog megjelenni a rendszerindítás során: ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled A logging disabled üzenetbõl kiderül, hogy a modul nem végez naplózást. A naplózást és a hozzátartozó részletesség szintjét úgy tudjuk beállítani, ha az /etc/sysctl.conf állományba felvesszük a következõ sorokat, amivel a következõ indításkor már mûködni fog: net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=5 A rendszermag beállításai a rendszermag beállításai IPFIREWALL a rendszermag beállításai IPFIREWALL_VERBOSE a rendszermag beállításai IPFIREWALL_VERBOSE_LIMIT IPFW a rendszermag beállításai Ha nem akarjuk kihasználni az IPFW által felkínált címfordítási lehetõségeket, akkor egyáltalán nem szükséges a &os; rendszermagjába belefordítani a támogatását. Ezért az alábbiakat csak kiegészítõ információként tüntettük fel. options IPFIREWALL Ez a beállítás engedélyezi az IPFW használatát a rendszermag részeként. options IPFIREWALL_VERBOSE Ezzel és a log kulcsszóval tudjuk az IPFW szabályain keresztülhaladó csomagokat naplózni. options IPFIREWALL_VERBOSE_LIMIT=5 Ez az érték korlátozza a &man.syslogd.8; segítségével naplózott azonos bejegyzések maximális számát. Ezt a beállítást olyan veszélyes környezetekben érdemes használnunk, ahol naplózni akarunk. Segítségével meg tudjuk akadályozni, hogy a rendszernapló elárasztásával megakasszák a rendszerünket. a rendszermag beállításai IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_DEFAULT_TO_ACCEPT Ezen beállítás hatására a tûzfal alapértelmezés szerint mindent átenged, ami általában akkor jöhet jól, amikor elõször beállítjuk a tûzfalat. a rendszermag beállításai IPDIVERT options IPDIVERT Ezzel a beállítással engedélyezzük a címfordítás használatát. Ha nem adjuk meg az IPFIREWALL_DEFAULT_TO_ACCEPT beállítást, vagy ha nem engedélyezzük a bejövõ csomagokat, akkor a gépünkre semmilyen csomag nem lesz képes bejutni, illetve onnan kijutni. Az <filename>/etc/rc.conf</filename> beállításai Így tudjuk engedélyezni a tûzfalat: firewall_enable="YES" A &os;-hez mellékelt alapértelmezett tûzfaltípusok közül az /etc/rc.firewall állomány átolvasásával tudunk választani, és megadni az alábbi helyett: firewall_type="open" A következõ értékek állnak rendelkezésünkre: open — átengedi az összes forgalmat client — csak ezt a gépet védi simple — az egész hálózatot védi closed — a helyi interfész kivételével minden IP alapú forgalmat tilt UNKNOWN — tiltja a tûzfal szabályainak betöltését állománynév — a tûzfal szabályait tartalmazó állomány abszolút elérési útvonala Két különbözõ módon lehet betölteni a saját ipfw szabályainkat. Az egyik közülük, ha a firewall_type változóban megadjuk a tûzfal szabályait tartalmazó állomány abszolút elérési útvonalát, az &man.ipfw.8; parancssori beállításai nélkül. Egy egyszerû szabályrendszer lehet például a következõ: add block in all add block out all Másrészrõl az firewall_script változóban is megadhatjuk azt a szkriptet, amelyben a rendszerindítás során meghívjuk ipfw parancsot. Az iménti szabályrendszert az alábbi szkripttel tudjuk kiváltani: #!/bin/sh ipfw -q flush ipfw add block in all ipfw add block out all Ha a firewall_type változó client vagy simple értékét használjuk, akkor az /etc/rc.firewall állományban található alapértelmezett szabályokat érdemes átvizsgálnunk, hogy kellõen illeszkednek-e az adott géphez. Hozzátennénk, hogy a fejezetben szereplõ példák azt feltételezik, hogy a firewall_script értéke az /etc/ipfw.rules állomány. A naplózás így engedélyezhetõ: firewall_logging="YES" A firewall_logging változó egyedül csak annyit tesz, hogy beállítja a net.inet.ip.fw.verbose sysctl változónak az 1 értéket (lásd ). A napló korlátozására nincs külön változó az rc.conf állományon belül, de az /etc/sysctl.conf állomány segítségével és manuálisan be tudjuk állítani a hozzátartozó változót: net.inet.ip.fw.verbose_limit=5 Amennyiben a gépünk átjáróként viselkedik, tehát a &man.natd.8; segítségével címfordítást végez, a ban olvashatunk utána, hogy ehhez az /etc/rc.conf állományban milyen beállításokat kell megadnunk. Az IPFW parancs ipfw Normál esetben az ipfw parancs használatos arra, hogy a tûzfal mûködése közben az aktív belsõ szabályai közé vegyünk fel vagy töröljünk közülük manuálisan bejegyzéseket. Ennek a módszernek az egyedüli hátránya, hogy az így végrehajtott módosítások el fognak veszni a rendszer leállításával. Itt inkább azt a megoldást javasoljuk, hogy az összes szabályt tegyük bele egy állományba és a rendszerindítás során ezt töltsük be, majd ha változtatni akarunk a tûzfalon, akkor ezt az állományt módosítsuk és a régiek törlésével töltsük be újra az egész szabályrendszert. Az ipfw parancs mellesleg remekül használható a jelenleg futó tûzfalszabályok megjelenítésére a konzolon. Az IPFW nyilvántartásában az egyes szabályokhoz dinamikusan jönnek létre számlálók, amelyek a rá illeszkedõ csomagokat számolják. A tûzfal tesztelése folyamán a szabályok és hozzátartozó számlálók lekérdezése a megfelelõ mûködés ellenõrzésének egyik lehetséges módja. A szabályokat így tudjuk egymás után felsoroltatni: &prompt.root; ipfw list A szabályokat így tudjuk az utolsó illeszkedésük idejével együtt megjeleníteni: &prompt.root; ipfw -t list A következõ példában a nyilvántartási információkat kérdezzük le, ekkor a szabályok mellett az illeszkedõ csomagok száma is láthatóvá válik. Az elsõ sorban a szabály száma szerepel, majd ezt követi rendre az illeszkedõ kimenõ és bejövõ csomagok mennyisége, valamint végül maga a szabály. &prompt.root; ipfw -a list A statikus szabályok mellett a dinamikusakat így lehet kilistázni: &prompt.root; ipfw -d list A lejárt dinamikus szabályokat is meg tudjuk nézni: &prompt.root; ipfw -d -e list A számlálók nullázása: &prompt.root; ipfw zero Csak a SZÁM sorszámú szabályhoz tartozó számlálók nullázása: &prompt.root; ipfw zero SZÁM Szabályrendszerek az IPFW-ben Az IPFW esetében a szabályrendszer olyan szabályokból áll, amelyek a csomagokról tartalmuk alapján eldöntik, hogy át kell engedni vagy vissza kell tartani. A gépek közt két irányban áramló csomagok egy munkamenet alapú társalgást képeznek. A tûzfalhoz tartozó szabályrendszer egyaránt feldolgozza a internetrõl a hálózatunk felé igyekvõ csomagokat, illetve a hálózatunk ezekre adott válaszait. Az egyes TCP/IP szolgáltatásokat (mint például telnet, www, levelezés stb.) a hozzájuk tartozó protokol és szabványos (fogadó) portszám írja le. Ezekre a forrásról általában valamilyen nem szabványos (magasabb értékû) portról érkeznek csomagok. Ekkor a kommunikáció összes paramétere (vagyis a portok és címek) bármelyike alapján definiálhatunk blokkolást vagy továbbengedést leíró szabályokat. IPFW a szabályok feldolgozásának sorrendje Amikor egy csomag eléri a tûzfalat, a szabályrendszer elsõ szabályával kerül összehasonlításra és amíg nem illeszkedik valamelyikre, addig lefut rá a többi szabály is fentrõl lefelé egyesével, a sorszámuknak megfelelõ növekvõ sorrendben. Ha a csomag megfelel valamelyik szabály leválogatási paramétereinek, akkor a benne megnevezett cselekvés zajlik le, és számára a feldolgozás befejezõdik. Ezt a viselkedést neveztük az elsõ illeszkedés nyer típusú keresésnek. Amennyiben a csomag egyetlen szabályra sem illeszkedik, akkor az IPFW 65535-ös sorszámú állandó szabálya fogja elcsípni, amely feladata szerint eldobja az összes hozzá beérkezõ csomagot anélkül, hogy bármit is válaszolna a csomag feladójának. A keresés a count, skipto és tee szabályok után még folytatódik. Az itt szereplõ utasítások különbözõ állapottartásra vonatkozó opciókat, például a keep state, limit, in, out és via kulcsszavakat tartalmazó szabályokon alapulnak. Lényegében ezt tekinthetjük az inkluzív típusú tûzfalak kiindulási alapjaként. A tûzfal szabályainak beállítása során nem árt óvatosnak lennünk, mert figyelmetlenségünk révén könnyen kizárathatjuk magunkat a gépünkrõl. A szabályok felépítése IPFW a szabályok felépítése Az itt bemutatásra kerülõ szabályok felépítését csak olyan mértékig részletezzük, ami elengedõ a szabványos inkluzív típusú tûzfalak kialakításához. A szabályok felépítésének pontos leírását az &man.ipfw.8; man oldalán találhatjuk meg. A szabályok kulcsszavakat tartalmaznak. Ezeket a kulcsszavakat soronként egy elõre rögzített sorrendben kell szerepeltetni. A kulcsszavakat a szövegben kiemeltük. Bizonyos kulcsszavakhoz további opciókhoz is tartozhatnak, amelyek gyakran maguk is kulcsszavak és szintén további opciókat tartalmazhatnak. A # egy megjegyzés kezdetét jelzi, mely egyaránt megjelenhet egy külön sorban, vagy egy szabályt tartalmazó sor végén. Az üres sorok nem vesznek részt a feldolgozásban. PARANCS SZABÁLY_SZÁM CSELEKVÉS NAPLÓZÁS SZÛRÉS ÁLLAPOTTARTÁS PARANCS Minden új szabály elõttt az add (mint hozzáadás) parancsnak kell szerepelni, amellyel a belsõ táblázatba tudjuk felvenni. SZABÁLY_SZÁM A szabályokhoz mindig tartozik egy sorszám is. CSELEKVÉS A szabályhoz az alábbi cselekvések valamelyike kapcsolható, amely akkor hajtódik végre, amikor a csomag megfelel a hozzátartozó szûrési feltételeknek. allow | accept | pass | permit A fentiek közül mindegyik ugyanazt jelenti, vagyis hatásukra az illeszkedõ csomag kilép a tûzfalból. Ez a szabály megállítja a keresést. check-state A csomagot a dinamikus szabályokat tároló táblázattal veti össze. Ha itt egyezést talál, akkor végrehajtja az egyezõ dinamikus szabályhoz tartozó cselekvést, minden más esetben továbblép a következõ szabályra. Ennek a szabálynak nincs illeszthetõ paramétere. Ha a szabályrendszerben nem szerepel ilyen, akkor a dinamikus szabályok vizsgálatát az elsõ keep-state vagy limit használatánál vonja be a rendszer. deny | drop Mind a két szó ugyanarra utal, vagyis a szabályra illeszkedõ csomagokat el kell dobni. Ebben az esetben a keresés befejezõdik. NAPLÓZÁS log vagy logamount Amikor egy csomag egy log kulcsszót tartalmazó szabályra illeszkedik, akkor a rendszernaplóban egy üzenet keletkezik a security (biztonság) funkción keresztül. A naplóba ténylegesen csak akkor kerül bele az üzenet, ha az adott szabály még nem haladta meg a hozzátartozó logamount paraméter értékét. Ha ezt nem adtuk meg, akkor az itt érvényes korlát a net.inet.ip.fw.verbose_limit sysctl változóból fog származni. A nulla érték mind a két esetben megszünteti ezt a korlátozást. Ha elértük a korlátot, akkor a naplózást úgy tudjuk újra engedélyezni, ha töröljük a naplózáshoz tartozó számláló értékét, lásd az ipfw reset log parancsot. A naplózás mindig az összes paraméter illeszkedésének ellenõrzése után történik, de még a cselekvés (accept, deny) elvégzése elõtt. Teljesen rajtunk múlik, hogyan milyen szabályokat naplózunk. SZÛRÉS Ebben a szakaszban azok a kulcsszavak találhatóak, amelyek segítségével a csomagok különbözõ tulajdonságait tudjuk megvizsgálni és eldönteni, hogy illeszkedik-e a szabályra vagy sem. A következõ általános tulajdonságokat tudjuk megvizsgálni, ebben a kötött sorrendben: udp | tcp | icmp Bármilyen más olyan protokoll is megadható, amely megtalálható az /etc/protocols állományban. Ezzel adjuk a csomaghoz tartozó protokollt. Használata kötelezõ. from forrás to cél Mind a from és to kulcsszavak IP-címek illesztésére alkalmasak. A szabályoknak tartalmazniuk kell a forrás ÉS a cél paramétereket is. Az any egy olyan kulcsszó, amely tetszõleges IP-címre illeszkedik. A me pedig egy olyan speciális kulcsszó, amely a tûzfalat mûködtetõ &os;-s gép (tehát ez a gép) adott interfészhez tartozó IP-címét jelöli, mint ahogy a from me to any, from any to me, from 0.0.0.0/0 to any, from any to 0.0.0.0/0, from 0.0.0.0 to any, from any to 0.0.0.0 vagy from me to 0.0.0.0 paraméterekben. Az IP-címek numerikus pontozott formában a hálózati maszk hosszával együtt (CIDR-jelöléssel), vagy egyszerûen csak pontozott formában adhatóak meg. A hálózati maszkok megállapításában a net-mgmt/ipcalc port lehet segítségünkre. Errõl bõvebb információkat a segédprogram honlapján, a címen találhatunk (angolul). port szám A portszámokat is ismerõ protokollok esetében (mint például a TCP vagy UDP) adhatjuk meg. Fontos, hogy itt annak a szolgáltatásnak a portszámát adjuk meg, amelyre a szabály vonatkozik. A szolgáltatás (az /etc/services állományból származó) nevét is megadhatjuk a port száma helyett. in | out A beérkezõ valamint a kimenõ csomagokat adhatjuk meg ezen a módon. Itt az in és out kulcsszavak, melyeket kötelezõ megadni a szabály részeként. via interfész Név szerint az adott interfészen keresztül haladó csomagokat tudjuk szûrni. A via kulcsszó hatására a használt interfész is számítani fog a csomag feldolgozása során. setup Ez a kulcsszó a TCP csomagok esetében a kapcsolatok felépítésére vonatkozó kéréseket segít beazonosítani. keep-state Ez egy kötelezõ kulcsszó. Feldolgozásakor a tûzfal létrehoz dinamikus szabályt, amely alapértelmezés szerint az egyazon protokollt használó forrás és cél IP/port párosok közti kétirányú forgalomra fog automatikusan illeszkedni. limit {forráscím | forrásport | célcím | célport} A tûzfal csak N darab, a szabálynak megfelelõ azonos paraméterû kapcsolatot fog átengedi. Itt egy vagy több forrás- és célcím valamint forrás- és célport adható meg. A limit és a keep-state egy szabályon belül nem használható. A limit ugyanazokat az állapottartó funkciókat képviseli, mint a keep-state, csak a saját kiegészítéseivel megtoldva. ÁLLAPOTTARTÁS IPFW állapottartó szûrés Az állapottartó szûrés a kétirányú csomagváltásokat egy létrejött kapcsolatba sorolja. Olyan vizsgálatokat végez, amivel képes megállapítani, hogy a csomag küldõje és címzettje között kialakult kommunikáció követ-e valamilyen kétirányú csomagküldésre érvényes folyamatot. Az így felállított sablontól eltérõ összes csomag hamisnak minõsül és automatikusan eldobásra kerül. A check-state segítségével ellenõrizhetjük, hogy az adott csomag a IPFW szerint megfelel-e valamelyik dinamikusan leképzett szabálynak. Ha egyezik valamelyikõjükkel, akkor a csomag a tûzfalból kilépve folytatja útját és a kommunikációban soron következõ csomag számára létrejön egy másik dinamikus szabály. Ha nincs egyezés, akkor csomag feldolgozása a szabályrendszer következõ szabályánál folytatódik. A dinamikus szabályokat kezelõ rutin sebezhetõ, mivel ha egyszerre nagy mennyiségû SYN csomagot küldünk, akkor olyan sok dinamikus bejegyzés keletkezik, hogy egyszerûen kifogyunk a rendelkezésre álló erõforrásokból. A &os; fejlesztõi azonban az ilyen természetû támadások kivédésére is felkészítették, és kialakították belõle a limit opciót. Alkalmazásával le tudjuk korlátozni az egyszerre folyó párhuzamos kapcsolatok számát a forrás vagy a cél a limit paraméternél megadott mezõinek és a csomag IP-címe alapján. Így az adott szabályhoz és IP-címhez csak elõre rögzített mennyiségû nyitott állapotú dinamikus szabály létezhet egy idõben. Ha ezt a korlátot átlépjük, a csomag eldobódik. A tûzfal üzeneteinek naplózása IPFW naplózás A naplózás elõnyei nyilvánvalóak. Ha engedélyezzük, aktiválása után képesek leszünk olyan információknak utánanézni, mint például milyen csomagokat dobtunk el, honnan érkeztek, hova tartottak. Ez egy komoly fegyverünk lehet a potenciális támadókkal szemben. Azonban hiába engedélyezzünk önmagában a naplózást, attól az IPFW még saját magától nem fog naplózást elõíró szabályokat gyártani. A tûzfal karbantartóinak maguknak kell eldöntenie, hogy a szabályrendszerben mely szabályokhoz tartozzon naplózás, nekik kell felvenni ezekhez a log kulcsszót. Általában csak az eldobással járó deny típusú szabályokat vagy a bejövõ ICMP pingeket szokták naplózni. Gyakran úgy oldják meg ezt, hogy a szabályrendszer utolsó szabályaként lemásolják az ipfw alapértelmezett mindent eldobunk szabályát és a naplózást adják meg benne. Ezen a módon fény derül azokra a csomagokra, amelyek a szabályrendszerben semmire sem illeszkedtek. A naplózás azonban egy kétélû fegyver, mivel ha nem vagyunk elég körültekintõek, akkor a sok naplóinformáció között könnyen el tudunk veszni és a lemezünk is gyorsan betelhet a mindent elfoglaló naplóktól. Mellesleg a naplók megdagasztását célzó DoS típusú támadás a rendszerek lebénítására alkalmazott egyik legõsibb technika. Ezek az üzenetek nem csak a rendszernaplóba kerülnek bele, hanem az elsõdleges konzol képernyõjére is kiíródnak, ami egy idõ után idegesítõ tud lenni. A rendszermag IPFIREWALL_VERBOSE_LIMIT=5 beállításával azonban képesek vagyunk korlátozni azokat a rendszernapló felé küldött egymás után következõ üzeneteket, amelyek ugyanarra a szabályra vonatkoznak. Amikor ezt a beállítást megadjuk a rendszermag fordításánál, akkor az egyes szabályokhoz az általa meghatározott értéken felül nem jön létre több hasonló üzenet. Hiszen semmi sem derül ki 200 teljesen azonos naplóüzenetbõl. Például, ha az egyes szabályokhoz legfeljebb öt egymást követõ üzenetet engedélyezünk, akkor a többi fennmaradó azonos üzenetet összeszámolja a rendszer és a következõ módon közvetíti a rendszernaplózó szolgáltatás felé: last message repeated 45 times Ami magyarul így hangzik: az utolsó üzenet 45 alkalommal ismétlõdött meg Az összes csomagokkal kapcsolatos naplózás alapértelmezés szerint a /var/log/security állományba kerül, amelyet az /etc/syslog.conf állomány definiál. Szabályokat tartalmazó szkript készítése A rutinosabb IPFW felhasználók a szabályokat egy állományban programozzák le olyan stílusban, hogy szkriptként is futtatható legyen. Ennek az egyik legnagyobb elõnye, hogy a tûzfal szabályai így egyszerre cserélhetõek a rendszer újraindítása nélkül. Ez a módszer nagyon kényelmes az új szabályok kipróbálásánál, mivel tetszõleges alkalommal végrehajthatjuk. Mivel ez egy szkript, ki tudjuk használni az itt megszokott szimbolikus helyettesítés által felkínált lehetõségeket, és ezzel a gyakran használt értékeket is egyszerre több szabályban tudjuk helyettesíteni. Erre a következõkben fogunk egy konkrét példát látni. A szkript felépítése kompatibilis a &man.sh.1;, &man.csh.1; és &man.tcsh.1; parancsértelmezõkkel. A szimbolikus mezõk helyettesítését a $ vagyis dollárjel vezeti be. Maguk a szimbolikus mezõk nem tartalmazzák a $ elõtagot. A szimbolikus mezõk értékeit "kettõs idézõjelek" között kell megadni. A szabályok összeírását kezdjük el így: ####### itt kezdõdik az ipfw szabályait tartalmazó szkript ###### # ipfw -q -f flush # töröljük az összes aktuális szabályt # Set defaults oif="tun0" # a kimenõ interfész odns="192.0.2.11" # az internet szolgáltató névszerverének IP-címe cmd="ipfw -q add " # a szabályok hozzáadásához szükséges elemek ks="keep-state" # csupán a lustaság miatt $cmd 00500 check-state $cmd 00502 deny all from any to any frag $cmd 00501 deny tcp from any to any established $cmd 00600 allow tcp from any to any 80 out via $oif setup $ks $cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks $cmd 00611 allow udp from any to $odns 53 out via $oif $ks #### itt fejezõdik be az ipfw szabályait tartalmazó szkript ###### Ezzel készen is vagyunk. Most ne törõdjünk a példában szereplõ szabályokkal, itt most a szimbolikus helyettesítés használatát igyekeztük bemutatni. Ha az iménti példát az /etc/ipfw.rules állományba mentettük el, akkor az alábbi parancs kiadásával tudjuk újratölteni a benne szereplõ szabályokat: &prompt.root; sh /etc/ipfw.rules Az /etc/ipfw.rules állományt egyébként tetszõleges néven hívhatjuk és bárhová rakhatjuk. Ugyanez természetesen elérhetõ a következõ parancsok egymás utáni begépelésével is: &prompt.root; ipfw -q -f flush &prompt.root; ipfw -q add check-state &prompt.root; ipfw -q add deny all from any to any frag &prompt.root; ipfw -q add deny tcp from any to any established &prompt.root; ipfw -q add allow tcp from any to any 80 out via tun0 setup keep-state &prompt.root; ipfw -q add allow tcp from any to 192.0.2.11 53 out via tun0 setup keep-state &prompt.root; ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state Állapottartó szabályrendszerek A most következõ címfordítás nélküli szabályrendszer arra mutat példát, hogyan valósítsunk meg egy biztonságos inkluzív tûzfalat. Az inkluzív tûzfalak csak a szabályainak megfelelõ szolgáltatásokat engedik át, minden mást alapértelmezés szerint tiltanak. A komplett hálózati szegmensek védelmére összeállított tûzfalaknak legalább két interfészük van, amelyek mindegyikéhez tartoznia kell szabályoknak a megfelelõ mûködéshez. Az &unix; mintájú operációs rendszer, köztül a &os; is olyan, hogy a rendszerben belüli kommunikációt a lo0 nevû interfészen és a 127.0.0.1 IP-címen bonyolítja le. A tûzfalban mindenképpen szerepelniük kell olyan szabályoknak, amelyek gondoskodnak ezen speciális belsõ csomagok zavartalan közlekedésérõl. Az internet felé csatlakozó interfész lesz az, amelyen keresztül a kifelé menõ kéréseket hitelesítjük és vezéreljük az internet elérését, valamint ahol szûrjük az internet felõl érkezõ kéréseket. Ez lehet a PPP esetében a tun0 eszköz, vagy a DSL-, illetve kábelmodemhez csatlakozó hálózati kártya. Abban az esetben, amikor egy vagy több hálózati kártyával csatlakozunk a tûzfal mögött található belsõ helyi hálózatra, szintén gondoskodnunk kell a helyi hálózaton belül mozgó csomagok akadálymentes továbbításáról. A szabályokat elõször három nagyobb osztályba kell sorolnunk: az összes szabadon forgalmazó interfész, a publikus kimenõ és a publikus bejövõ interfész csoportjába. A publikus interfészekhez tartozó csoportokban úgy kell rendeznünk a szabályokat, hogy elõre kerüljenek a gyakrabban használtak és hátra a kevésbé használtak, valamint a csoportok utolsó szabálya blokkoljon és naplózzon minden csomagot az adott interfészen és irányban. A következõ szabályrendszerben szereplõ, a kimenõ kapcsolatokat tartalmazó csoport csak olyan allow típusú szabályokat tartalmaz, amelyek szûrési feltételei egyértelmûen azonosítják az interneten elérhetõ szolgáltatásokat. Az összes szabályban megjelennek a proto, port, in/out, via és keep state opciók. A proto tcp szabályokban emellett szerepel még egy setup opció is, amellyel a kapcsolatokat kezdeményezõ csomagokat tudjuk azonosítani és felvenni az állapottartásért felelõs dinamikus szabályok közé. A bejövõ forgalmat vezérlõ szabályrendszerben elõször az eldobni kívánt csomagokat kell megadni, aminek két eltérõ oka van. Elõször is elõfordulhat, hogy a veszélyes csomagok részleges illeszkedés miatt szabályosnak tûnnek. Az ilyen csomagokat értelemszerûen nem lenne szabad beengedni a szabályok részleges megfelelése alapján. A másodszor az eleve ismerten problémás és értelmetlen csomagokat csendben el kellene vetni, mielõtt a szakaszhoz tartozó utolsó szabály fogná meg és naplózná. Ez az utolsó szabály egyébként szükség esetén felhasználható a támadók elleni bizonyítékok begyûjtésére. A másik, amire még oda kell figyelnünk, hogy a blokkolt csomagok esetében semmilyen válasz nem keletkezzen, egyszerûen csak tûnjenek el. Így a támadó nem fogja tudni, hogy a csomagjai vajon elérték-e a rendszerünket. Minél kevesebb információt tudnak összegyûjteni a rendszerünkrõl a támadók, annál biztonságosabbnak tekinthetõ. Amikor ismeretlen portokra érkezõ csomagokat naplózunk, érdemes az /etc/services/ állományban vagy címen (angolul) utánanézni a porthoz tartozó szolgáltatásnak. A különbözõ trójai programok által portok számai ezen a linken érhetõek el (angolul): . Példa egy inkluzív szabályrendszerre A most következõ, címfordítást nem tartalmazó szabályrendszer teljesen inkluzív típusú. Éles rendszereken is nyugodtan alkalmazhatjuk. Egyszerûen csak annyit kell tennünk, hogy megjegyzésbe tesszük az olyan szolgáltatásokra vonatkozó szabályokat, amelyeket nem akarunk engedélyezni. Amikor pedig olyan üzenetek jelennek meg a naplóban, amelyeket nem akarunk tovább látni, a bejövõ kapcsolatokhoz vegyünk fel egy deny típusú szabályt hozzájuk. Minden szabályban cseréljük ki a dc0 interfészt arra a hálózati kártyára, amely közvetlenül csatlakoztatja rendszerünket az internethez. A felhasználói PPP esetében ez a tun0. A szabályok használatában felfedezhetünk egyfajta rendszerszerûséget: Mindegyik sorban, ahol az internet felé nyitunk meg egy kapcsolatot, a keep-state opciót használjuk. Az internetrõl az összes hitelesített szolgáltatás elérése tartalmazza a limit opciót az elárasztások kivédése miatt. Az összes szabályban az in vagy az out paraméterrel megadjuk szûrni kívánt forgalom irányát. Az összes szabályban szerepel a via paraméterrel a csomagokat továbbító interfész neve. Az alábbi szabályokat tegyük az /etc/ipfw.rules állományba. ############## Itt kezdõdnek az IPFW szabályai ########################## # Kezdés elõtt töröljük az összes aktív szabályt. ipfw -q -f flush # Állítsuk be a parancsok további szükséges opciót. cmd="ipfw -q add" pif="dc0" # az internethez csatlakozó # interfész neve ################################################################# # A belsõ hálózat számára ne korlátozzunk semmit se. # Ha nincs helyi hálózatunk, akkor erre nincs szükségünk. # Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó # interfész nevére. ################################################################ #$cmd 00005 allow all from any to any via xl0 ################################################################ # A rendszer belsõ interfészét se szûrjük. ################################################################ $cmd 00010 allow all from any to any via lo0 ################################################################ # A csomagot engedjük át a tûzfalon, ha korábban már felvettünk # hozzá egy dinamikus szabályt a keep-state opcióval. ################################################################ $cmd 00015 check-state ################################################################ # Az internet felé forgalmazó interfész (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################ # Kifelé engedélyezzük az internet-szolgáltatónk névszerverének # elérését. Az x.x.x.x a szolgáltatónk névszerverének IP-címe # legyen. Ha a szolgáltatónak több névszervere is van, akkor # másoljuk le ezeket a sorokat és az /etc/resolv.conf # állományban található IP-címeket helyettesítsük be. $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state # Kábel/DSL konfigurációk esetében kifelé engedélyezzük a # szolgáltatónk DHCP szerverének elérését. Ha a "felhasználói # PPP"-t használjuk, akkor erre nem lesz szükségünk, az egész # csoportot törölhetjük. Az alábbi szabállyal csíphetjük el a # beírandó IP-címet. Ha a naplóban megtaláltuk, akkor vegyük # ki az elsõ szabályt, a másodikba írjuk bele a címet és # engedélyezzük. $cmd 00120 allow log udp from any to any 67 out via $pif keep-state #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state # Kifelé engedélyezzük a szabvány nem biztonságos WWW # funkció elérését. $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos HTTPS funkció # elérését TLS SSL használatával. $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state # Kifelé engedélyezzük a e-mailek küldését és fogadását. $cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state # Kifelé engedélyezzük a FreeBSD (a make install és a CVSUP) # funkcióit. Ezzel lényegében a rendszeradminisztrátornak # ,,ISTENI'' jogokat adunk. $cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root # Kifelé engedélyezzük a pinget. $cmd 00250 allow icmp from any to any out via $pif keep-state # Kifelé engedélyezzük az idõ szolgáltatást. $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state # Kifelé engedélyezzük az nntp news szolgáltatást # (vagyis a hírcsoportokat) $cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP # elérését az SSH (secure shell) használatával. $cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state # Kifelé engedélyezzük a whois szolgáltatást. $cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state # Dobjuk el és naplózzunk mindent, ami megpróbál kijutni. # Ez a szabály gondoskodik róla, hogy alapértelmezés szerint # mindent blokkoljunk. $cmd 00299 deny log all from any to any out via $pif ################################################################ # Az internet felõli interfész (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################ # Blokkoljunk minden olyan bejövõ forgalmat, amely a fenntartott # címtartományok felé tart. $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszterek összekötésére használt $cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # A nyilvános pingek tiltása. $cmd 00310 deny icmp from any to any in via $pif # Az ident szolgáltatás tiltása. $cmd 00315 deny tcp from any to any 113 in via $pif # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. $cmd 00320 deny tcp from any to any 137 in via $pif $cmd 00321 deny tcp from any to any 138 in via $pif $cmd 00322 deny tcp from any to any 139 in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Eldobjuk az összes késõn érkezõ csomagot. $cmd 00330 deny all from any to any frag in via $pif # Eldobjuk azokat az ACK csomagokat, amelyek egyik dinamikus # szabálynak sem felelnek meg. $cmd 00332 deny tcp from any to any established in via $pif # Befelé engedélyezzük a szolgáltató DHCP szerverének válaszát. Ebben # a szabályban csak a DHCP szerver IP-címe szerepelhet, mivel ez az # egyetlen olyan hitelesített forrás, ami ilyen csomagokat küldhet. # Ez csak a kábeles és DSL típusú kapcsolatok esetében szükséges. # Amikor a "felhasználói PPP"-vel csatlakozunk az internethez, nem # kell ez a szabály. Ugyanazt az IP-címet kell megadnunk, amelyet a # kimenõ kapcsolatoknál is. #$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state # Befelé engedélyezzük a szabvány WWW funkciót, mivel webszerverünk # is van. $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a biztonságos FTP, telnet és SCP # típusú kapcsolatokat az internetrõl. $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Befelé engedélyezzük az internetrõl érkezõ nem biztonságos telnet # kapcsolatokat. Azért tekintjük nem biztonságosnak, mert az # azonosítók és a jelszavak az interneten titkosítatlanul vándorolnak. # Töröljük ezt a csoportot, ha nincs telnet szolgáltatásunk. $cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Dobjuk el és naplózzuk az összes többi kintrõl érkezõ csomagot. $cmd 00499 deny log all from any to any in via $pif # Alapértelmezés szerint dobjuk el mindent. Az ide érkezõ # csomagokat is naplózzuk, amibõl többet is ki tudunk majd # deríteni. $cmd 00999 deny log all from any to any ############# Itt fejezõdnek be az IPFW szabályai ##################### Példa hálózati címfordításra és állapottartásra címfordítás és az IPFW Az IPFW címfordító funkciójának kihasználásához további konfigurációs beállítások alkalmazására is szükségünk lesz. A rendszermagban opció között meg kell adnunk az option IPDIVERT sort a többi IPFIREWALL sor mellett, és fordítanunk egy saját verziót. Emellett még az /etc/rc.conf állományban is engedélyezni kell az IPFW alapvetõ funkcióit. natd_enable="YES" # engedélyezzük a címfordításért felelõs démont natd_interface="rl0" # az internet felé mutató hálózati kártya neve natd_flags="-dynamic -m" # -m = a portszámok megtartása, ha lehetséges Az állapottartó szabályok használata a divert natd címfordítási opcióval együtt nagyban növeli a szabályrendszer leprogramozásának bonyolultságát. A check-state és divert natd szabályok helye kritikus a megfelelõ mûködés tekintetében. Az eddig megszokott egyszerû viselkedés itt már nem érvényesül. Bevezetünk egy új cselekvést is, amelynek a neve skipto. A skipto parancs használatához elengedhetetlen a szabályok sorszámozása, mivel pontosan tudnunk kell, hogy a skipto hatására hova kell ugrania a vezérlésnek. A következõ példában nem fogunk sok megjegyzést látni, mivel benne az egyik lehetséges programozási stílust próbáljuk érzékeltetni és a csomagok szabályrendszerek közti áramlását magyarázzuk. A feldolgozás a szabályokat tartalmazó állomány tetején található elsõ szabállyal kezdõdik, és innen egyesével pereg végig lefelé a feldolgozás egészen addig, amíg a csomag a szûrési feltételek valamelyikének eleget nem tesz és távozik a tûzfalból. Leginkább a 100-as, 101-es, 450-es, 500-as és 510-es sorszámú szabályokat emelnénk ki. Ezek vezérlik kimenõ és bejövõ csomagok fordítását, ezért a hozzájuk tartozó dinamikus állapottartó bejegyzések mindig a helyi hálózat IP-címeire hivatkoznak. Amit még érdemes megfigyelnünk, hogy az összes áteresztõ és eldobó szabályban szerepel a csomag haladási iránya (tehát kimenõ vagy éppen bejövõ) és az érintett interfészt megnevezése. Emellett azt is vegyük észre, hogy az összes kifelé irányuló kapcsolatlétrehozási kérés az 500-as sorszámú szabályhoz fog ugrani a címfordítás elvégzéséhez. Tegyük fel, hogy a helyi hálózatunkon levõ felhasználók szeretnek honlapokat nézgetni az interneten. A honlapok a 80-as porton keresztül kommunikálnak. Tehát amikor egy ilyen csomag eléri a tûzfalat, nem fog illeszkedni a 100-as szabályra, mert a fejléce szerint kifelé halad és nem befelé. A 101-es szabályon is átlép, mivel ez az elsõ csomag, így a dinamikus állapottartó táblázatban sem szerepel még. A csomag végül a 125-ös szabályra fog illeszkedni: kifelé halad az internetre csatlakozó hálózati kártyán. A csomagban azonban még mindig az eredeti forrás IP-címe található, amely a helyi hálózat egyik gépére hivatkozik. A szabály illeszkedésekor két cselekvés is végbemegy. A keep-state opció hatására ez a szabály felveszi ezt a kapcsolatot az állapottartó dinamikus szabályok közé és végrehajtja a másik megadott feladatot. Ez a feladat része a dinamikus táblázatba rögzített bejegyzésnek, ami ebben az esetben a skipto 500 (ugorjunk az 500-as szabályra) lesz. Az 500-as szabály a továbbküldés elõtt lefordítja a csomag forrás IP-címét. Ezt ne felejtsük el, nagyon fontos! A csomag ezután eljut a céljához, és visszatérve ismét belép a szabályrendszer tetején. Ezúttal illeszkedni fog a 100-as szabályra és a cél IP-címét visszafordítjuk a helyi hálózatunk megfelelõ gépének címére. Ezután a check-state szabályhoz kerül, amely megtalálja a dinamikus szabályok között és továbbengedi a belsõ hálózatra. Ezzel visszakerül a küldõ géphez, amely egy újabb csomagot küld egy újabb adatszeletet kérve a távoli szervertõl. Ekkor már a check-state szabály megtalálja a hozzátartozó bejegyzést a dinamikus szabályok között és végrehajtódik a korábban letárolt skipto 500 mûvelet. A csomag erre az 500-as szabályra ugrik, ahol lefordítjuk a címét és továbbküldjük. Az bejövõ oldalon minden, ami egy korábban kialakult kapcsolat részeként érkezik, automatikusan a check-state és a megfelelõ helyre rakott divert natd szabályok által dolgozódik fel. Itt mindössze a rossz csomagok eldobásával és a hitelesített szolgáltatások elérésének biztosításával kell foglalkoznunk. Például a tûzfalon egy webszerver fut, és azt szeretnénk, hogy az internetrõl képesek legyenek elérni a rajta levõ oldalakat. Az újonnan beérkezõ kapcsolatépítési kérelem a 100-as szabályra fog illeszkedni, amelynek a cél IP-címét a tûzfal helyi hálózaton található címére fogjuk leképezni. A csomagot ezután még megvizsgáljuk, nem tartalmaz-e valamilyen huncutságot, majd végül a 425-ös szabálynál fog kikötni. Az egyezéskor két dolog történhet: a csomaghoz felveszünk egy dinamikus szabályt, de ezúttal az adott forrás IP-címrõl érkezõ kapcsolatkérések számát 2-re lekorlátozzuk. Ezzel az adott szolgáltatás portján meg tudjuk óvni a tûzfalat üzemeltetõ gépet a DoS típusú támadásoktól. A csomagot ezután hozzátartozó cselekvés szerint továbbengedjük a belsõ hálózat felé. Visszatéréskor a tûzfal felismeri, hogy a csomag egy már meglevõ kapcsolathoz tartozik, ezért közvetlenül az 500-as szabályhoz kerül címfordításra, majd a kimenõ interfészen keresztül továbbküldjük. Íme az elsõ példa egy ilyen szabályrendszerre: #!/bin/sh cmd="ipfw -q add" skip="skipto 500" pif=rl0 ks="keep-state" good_tcpo="22,25,37,43,53,80,443,110,119" ipfw -q -f flush $cmd 002 allow all from any to any via xl0 # nem szûrjük a belsõ hálózatot $cmd 003 allow all from any to any via lo0 # nem szûrjük a helyi interfészt $cmd 100 divert natd ip from any to any in via $pif $cmd 101 check-state # A kimenõ csomagok hitelesítése: $cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks $cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks $cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks $cmd 130 $skip icmp from any to any out via $pif $ks $cmd 135 $skip udp from any to any 123 out via $pif $ks # Az összes olyan csomagot eldobjuk, amely a fenntartott # címtartományokba tart: $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # Az érkezõ csomagok hitelesítése: $cmd 400 allow udp from xx.70.207.54 to any 68 in $ks $cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1 $cmd 450 deny log ip from any to any # Ide ugrunk a kimenõ állapottartó szabályoknál: $cmd 500 divert natd ip from any to any out via $pif $cmd 510 allow ip from any to any ##################### a szabályok vége ################## A következõ példa teljesen megegyezik az elõzõvel, azonban itt már dokumentációs szándékkal szerepelnek megjegyzések is, melyek a tapasztalatlan IPFW szabályíróknak segítik jobban megérteni a szabályok pontos mûködését. A második példa: #!/bin/sh ############# Az IPFW szabályai itt kezdõdnek ########################### # Kezdés elõtt töröljük az összes jelenleg aktív szabályt: ipfw -q -f flush # Beállítjuk a parancsok megfelelõ elõtagjait: cmd="ipfw -q add" skip="skipto 800" pif="rl0" # az internethez csatlakozó # hálózati interfész neve ################################################################# # A belsõ hálózat számára ne korlátozzunk semmit se. # Ha nincs helyi hálózatunk, akkor erre nincs szükségünk. # Az 'xl0' nevét írjuk át a helyi hálózatra csatlakozó # interfész nevére. ################################################################# $cmd 005 allow all from any to any via xl0 ################################################################# # A rendszer belsõ interfészét se szûrjük. ################################################################# $cmd 010 allow all from any to any via lo0 ################################################################# # Ellenõrizzük, hogy ez egy beérkezõ csomag és ha igen, akkor # fordítsuk a címét. ################################################################# $cmd 014 divert natd ip from any to any in via $pif ################################################################# # Ha ehhez a csomaghoz korábban már vettük fel dinamikus # szabályt a keep-state opció révén, akkor engedjük tovább. ################################################################# $cmd 015 check-state ################################################################# # Az internet felé forgalmazó interfész (kimenõ kapcsolatok) # A saját hálózatunkról belülrõl vagy errõl az átjáróról # kezdeményezett kapcsolatokat vizsgáljuk az internet felé. ################################################################# # Kifelé engedélyezzük az internet-szolgáltatónk névszerverének # elérését. Az x.x.x.x a szolgáltató névszerverének IP-címe # lesz. Ha a szolgáltatónknak több névszervere is van, akkor # az /etc/resolv.conf állományból nézzük ki a címeiket és # másoljuk le az alábbi sor mindegyikükhöz. $cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep-state # A kábeles és DSL kapcsolatok esetén engedélyezzük a szolgáltató # DHCP szerverének elérését. $cmd 030 $skip udp from any to x.x.x.x 67 out via $pif keep-state # Kifelé engedélyezzük a szabvány nem biztonságos WWW funkciót $cmd 040 $skip tcp from any to any 80 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos HTTPS funkciót a TLS SSL # használatával. $cmd 050 $skip tcp from any to any 443 out via $pif setup keep-state # Kifelé engedélyezzük az e-mailek küldését és fogadását. $cmd 060 $skip tcp from any to any 25 out via $pif setup keep-state $cmd 061 $skip tcp from any to any 110 out via $pif setup keep-state # Kifelé engedélyezzük a FreeBSD (make install és CVSUP) funkcióit. # Ezzel a rendszeradminisztrátornak ,,ISTENI'' jogokat adunk. $cmd 070 $skip tcp from me to any out via $pif setup keep-state uid root # Kifelé engedélyezzük a pinget. $cmd 080 $skip icmp from any to any out via $pif keep-state # Kifelé engedélyezzük az idõ szolgáltatást. $cmd 090 $skip tcp from any to any 37 out via $pif setup keep-state # Kifelé engedélyezzük az nntp news szolgáltatást (tehát a # hírcsoportokat). $cmd 100 $skip tcp from any to any 119 out via $pif setup keep-state # Kifelé engedélyezzük a biztonságos FTP, telnet és SCP # funkciókat az SSH (secure shell) használatával. $cmd 110 $skip tcp from any to any 22 out via $pif setup keep-state # Kifelé engedélyezzük ki a whois kéréseket. $cmd 120 $skip tcp from any to any 43 out via $pif setup keep-state # Kifelé engedélyezzük az NTP idõszerver elérését. $cmd 130 $skip udp from any to any 123 out via $pif keep-state ################################################################# # Az internet felõli interfész (bejövõ kapcsolatok) # A saját hálózatunk felé vagy erre az átjáróra # nyitott kapcsolatokat vizsgáljuk az internet felõl. ################################################################# # Tiltsuk a fenntartott címtartományok felé haladó összes beérkezõ # forgalmat. $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918: privát IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918: privát IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918: privát IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #helyi $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #helyi $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #dokumentációs célokra fenntartott $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun klaszter $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #D és E osztályú multicast # Az ident tiltása. $cmd 315 deny tcp from any to any 113 in via $pif # Blokkoljuk az összes Netbios szolgáltatást: 137=név, 138=datagram, # 139=session. A Netbios az MS Windows megosztását implementálja. # Blokkoljuk az MS Windows hosts2 névszerver kéréseit is a 81-es # porton. $cmd 320 deny tcp from any to any 137 in via $pif $cmd 321 deny tcp from any to any 138 in via $pif $cmd 322 deny tcp from any to any 139 in via $pif $cmd 323 deny tcp from any to any 81 in via $pif # Dobjuk el a késõn érkezõ csomagokat. $cmd 330 deny all from any to any frag in via $pif # Dobjuk el azokat az ACK csomagokat, amelyekre nincs # dinamikus szabály. $cmd 332 deny tcp from any to any established in via $pif # Engedélyezzük a szolgáltató DHCP szerverétõl érkezõ forgalmat. Ennek # a szabálynak tartalmaznia kell a DHCP szerver címét, mert csak tõle # fogadunk el ilyen típusú csomagokat. Egyedül csak kábeles vagy DSL # konfigurációk esetén használatos, a "felhasználói PPP" esetében # törölhetjük. Ez ugyanaz az IP-cím, amelyet a kimenõ kapcsolatoknál # megadtunk. $cmd 360 allow udp from x.x.x.x to any 68 in via $pif keep-state # Befelé engedélyezzük a szabvány WWW funkciót, mivel van # webszerverünk. $cmd 370 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a biztonságos FTP, telnet és SCP # használatát az internetrõl. $cmd 380 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Befelé engedélyezzük a nem biztonságos telnet elérését az # internetrõl. Azért nem tekintjük biztonságosnak, mert az # azonosítókat és a jelszavakat az interneten titkosítatlanul # közvetíti. Ha nincs telnet szolgáltatásunk, akkor törölhetjük is ezt # a csoportot. $cmd 390 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Dobjuk el és naplózzuk az összes internetrõl érkezõ hitelesítetlen kapcsolatot. $cmd 400 deny log all from any to any in via $pif # Dobjuk el és naplózzuk az összes internetre menõ hitelesítetlen kapcsolatot. $cmd 450 deny log all from any to any out via $pif # Ez lesz a kimenõ szabályokhoz tartozó "skipto" célja. $cmd 800 divert natd ip from any to any out via $pif $cmd 801 allow ip from any to any # Minden mást alapértelmezés szerint tiltunk és naplózunk. $cmd 999 deny log all from any to any ############# Az IPFW szabályai itt fejezõdnek be ##################### diff --git a/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml index d2cd0da2fe..0713b64263 100644 --- a/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.sgml @@ -1,7137 +1,7259 @@ Murray Stokely Átdolgozta: Hálózati szerverek Áttekintés Ebben a fejezetben a &unix; típusú rendszerekben leggyakrabban alkalmazott hálózati szolgáltatások közül fogunk néhányat bemutatni. Ennek során megismerjük a hálózati szolgáltatások különbözõ típusainak telepítését, beállítását, tesztelését és karbantartását. A fejezet tartalmát folyamatosan példákkal igyekszünk illusztrálni. A fejezet elolvasása során megismerjük: hogyan dolgozzunk az inetd démonnal; hogyan állítsuk be a hálózati állományrendszereket; hogyan állítsunk be egy hálózati információs szervert a felhasználói hozzáférések megosztására; hogyan állítsuk be automatikusan a hálózati hozzáférésünket a DHCP használatával; hogyan állítsunk be névfeloldó szervereket; hogyan állítsuk be az Apache webszervert; hogyan állítsuk be az állományok átviteléért felelõs (FTP) szervert; a Samba használatával hogyan állítsunk be &windows;-os kliensek számára állomány- és nyomtatószervert; az NTP protokoll segítségével hogyan egyeztessük az idõt és dátumot, hogyan állítsunk be egy idõszervert; a szabványos naplózó démon, a syslogd beállítását hálózati keresztüli naplózásra. A fejezet elolvasásához ajánlott: az /etc/rc szkriptek alapjainak ismerete; az alapvetõ hálózati fogalmak ismerete; a külsõ szoftverek telepítésének ismerete (). Chern Lee Készítette: A &os; 6.1-RELEASE változatához igazította: A &os; Dokumentációs Projekt Az <application>inetd</application> <quote>szuperszerver</quote> Áttekintés Az &man.inetd.8; démont gyakran csak internet szuperszerverként nevezik, mivel a helyi szolgáltatások kapcsolatainak kezeléséért felelõs. Amikor az inetd fogad egy csatlakozási kérelmet, akkor eldönti róla, hogy ez melyik programhoz tartozik és elindít egy példányt belõle, majd átadja neki a socketet (az így meghívott program a szabvány bemenetéhez, kimenetéhez és hibajelzési csatornájához kapja meg a socket leíróit). Az inetd használatával úgy tudjuk csökkenteni a rendszerünk terhelését, hogy a csak alkalmanként meghívott szolgáltatásokat nem futtatjuk teljesen független önálló módban. Az inetd démont elsõsorban más démonok elindítására használjuk, de néhány triviális protokollt közvetlenül is képes kezelni, mint például a chargen, auth és a daytime. Ebben a fejezetben az inetd beállításának alapjait foglaljuk össze mind parancssoros módban, mind pedig az /etc/inetd.conf konfigurációs állományon keresztül. Beállítások Az inetd mûködése az &man.rc.8; rendszeren keresztül inicializálható. Az inetd_enable ugyan alapból a NO értéket veszi fel, vagyis tiltott, de a sysinstall használatával már akár a telepítés során bekapcsolható attól függõen, hogy a felhasználó milyen konfigurációt választott. Ha tehát a: inetd_enable="YES" vagy inetd_enable="NO" sort tesszük az /etc/rc.conf állományba, akkor azzal az inetd démont indíthatjuk el vagy tilthatjuk le a rendszer indítása során. Az &prompt.root; /etc/rc.d/inetd rcvar paranccsal lekérdezhetjük a pillanatnyilag érvényes beállítást. Emellett még az inetd démonnak az inetd_flags változón keresztül különbözõ parancssori paramétereket is át tudunk adni. Parancssori paraméterek Hasonlóan a legtöbb szerverhez, az inetd viselkedését is befolyásolni tudjuk a parancssorban átadható különbözõ paraméterekkel. Ezek teljes listája a következõ: inetd Ezek a paraméterek az /etc/rc.conf állományban az inetd_flags segítségével adhatóak meg az inetd részére. Alapértelmezés szerint az inetd_flags értéke -wW -C 60, ami az inetd által biztosított szolgáltatások TCP protokollon keresztüli wrappelését kapcsolja be, illetve egy IP-címrõl nem engedi a felkínált szolgáltatások elérését percenként hatvannál többször. A kezdõ felhasználók örömmel nyugtázhatják, hogy ezeket az alapbeállításokat nem szükséges módosítaniuk, habár a késõbbiekben majd fény derül arra, hogy a kiszolgálás gyakoriságának szabályozása remek védekezést nyújthat túlzottan nagy mennyiségû kapcsolódási kérelem ellen. A megadható paraméterek teljes listája az &man.inetd.8; man oldalán olvasható. -c maximum Az egyes szolgáltatásokhoz egyszerre felépíthetõ kapcsolatok alapértelmezett maximális számát adja meg. Alapból ezt a démont nem korlátozza. A beállítással ez akár szolgáltatásonként külön is megadható. -C arány Korlátozza, hogy egyetlen IP-címrõl alapból hányszor hívhatóak meg az egyes szolgáltatások egy percen belül. Ez az érték alapból korlátlan. A beállítással ez szolgáltatásonként is definiálható. -R arány Megadja, hogy egy szolgáltatást egy perc alatt mennyiszer lehet meghívni. Ez az érték alapértelmezés szerint 256. A 0 megadásával eltöröljük ezt a típusú korlátozást. -s maximum Annak maximumát adja meg, hogy egyetlen IP-címrõl egyszerre az egyes szolgáltatásokat mennyiszer tudjuk elérni. Alapból ez korlátlan. Szolgáltatásonként ezt a paraméterrel tudjuk felülbírálni. Az <filename>inetd.conf</filename> állomány Az inetd beállítását az /etc/inetd.conf konfigurációs állományon keresztül végezhetjük el. Amikor az /etc/inetd.conf állományban módosítunk valamit, az inetd démont a következõ paranccsal meg kell kérnünk, hogy olvassa újra: Az <application>inetd</application> konfigurációs állományának újraolvasása &prompt.root; /etc/rc.d/inetd reload A konfigurációs állomány minden egyes sora egy-egy démont ír le. A megjegyzéseket egy # jel vezeti be. Az /etc/inetd.conf állomány bejegyzéseinek formátuma az alábbi: szolgáltatás-neve socket-típusa protokoll {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] felhasználó[:csoport][/bejelentkezési-osztály] szerver-program szerver-program-paraméterei Az IPv4 protokollt használó &man.ftpd.8; démon bejegyzése például így néz ki: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l szolgáltatás-neve Ez az adott démon által képviselt szolgáltatást nevezi meg, amelynek szerepelnie kell az /etc/services állományban. Ez határozza meg, hogy az inetd milyen porton figyelje a beérkezõ kapcsolatokat. Ha egy új szolgáltatást hozunk létre, akkor azt elõször az /etc/services állományba kell felvennünk. csatlakozás-típusa Ennek az értéke stream, dgram, raw, vagy seqpacket lehet. A stream típust használja a legtöbb kapcsolat-orientált TCP démon, miközben a dgram típus az UDP szállítási protokollt alkalmazó démonok esetében használatos. protokoll Valamelyik a következõk közül: Protokoll Magyarázat tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 TCP IPv4 és v6 udp46 UDP IPv4 és v6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] A beállítás mondja meg, hogy az inetd démonból meghívott démon saját maga képes-e kezelni kapcsolatokat. A típusú kapcsolatok esetében egyértelmûen a beállítást kell használni, miközben a esetén, ahol általában több szálon dolgozunk, a megadása javasolt. A hatására általában egyetlen démonnak adunk át több socketet, míg a minden sockethez egy újabb példányt indít el. Az inetd által indítható példányokat a megadásával korlátozhatjuk. Ha tehát például az adott démon számára legfeljebb példány létrehozását engedélyezzük, akkor a után /10 beállítást kell megadnunk. A /0 használatával korlátlan mennyiségû példányt engedélyezhetünk. A mellett még további két másik beállítás jöhet számításba az egyes démonok által kezelhetõ kapcsolatok maximális számának korlátozásában. A az egyes IP-címekrõl befutó lekezelhetõ kapcsolatok percenkénti számát szabályozza, így például ha itt a tizes értéket adjuk meg, akkor az adott szolgáltatáshoz egy IP-címrõl percenként csak tízszer férhetünk hozzá. A az egyes IP-címekhez egyszerre elindítható példányok számára ír elõ egy korlátot. Ezek a paraméterek segítenek megóvni rendszerünket az erõforrások akaratos vagy akaratlan kimerítésétõl és a DoS (Denial of Service) típusú támadásoktól. Ebben a mezõben a vagy valamelyikét kötelezõ megadni. A , és paraméterek ellenben elhagyhatóak. A típusú több szálon futó démonok a , vagy korlátozása nélkül egyszerûen csak így adhatóak meg: nowait. Ha ugyanezt a démont tíz kapcsolatra lekorlátozzuk, akkor a következõt kell megadnunk: nowait/10. Amikor pedig IP-címenként 20 kapcsolatot engedélyezünk percenként és mindössze 10 példányt, akkor: nowait/10/20. Az iménti beállítások a &man.fingerd.8; démon alapértelmezett paramétereinél is megtalálhatóak: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Végezetül engedélyezzük 100 példányt, melyek közül IP-címenként 5 használható: nowait/100/0/5. felhasználó Ezzel azt a felhasználót adjuk meg, akinek a nevében az adott démon futni fog. Az esetek túlnyomó részében a démonokat a root felhasználó futtatja. Láthatjuk azonban, hogy biztonsági okokból bizonyos démonok a daemon vagy a legkevesebb joggal rendelkezõ nobody felhasználóval futnak. szerver-program A kapcsolat felépülésekor az itt teljes elérési úttal megadott démon indul el. Ha ezt a szolgáltatást maga az inetd belsõleg valósítja meg, akkor ebben a mezõben az értéket adjuk meg. szerver-program-paraméterei Ez a beállítással együtt mûködik, és ebben a mezõben a démon meghívásakor alkalmazandó paramétereket tudjuk rögzíteni, amelyet a démon nevével kezdünk. Ha a démont a parancssorból a sajátdémon -d paranccsal hívnánk meg, akkor a sajátdémon -d lesz beállítás helyes értéke is. Természetesen, ha a démon egy belsõleg megvalósított szolgáltatás, akkor ebben a mezõben is az fog megjelenni. Védelem Attól függõen, hogy a telepítés során mit választottunk, az inetd által támogatott szolgáltatások egyes része talán alapból engedélyezett is. Amennyiben egy adott démont konkrétan nem használunk, akkor érdemes megfontolni a letiltását. A kérdéses démon sorába tegyünk egy # jelet az /etc/inetd.conf állományba, majd olvastassuk újra az inetd beállításait. Egyes démonok, mint például az fingerd használata egyáltalán nem ajánlott, mivel a támadók számára hasznos információkat tudnak kiszivárogtatni. Más démonok nem ügyelnek a védelemre, és a kapcsolatokhoz rendelt lejárati idejük túlságosan hosszú vagy éppen nincs is. Ezzel a támadónak lehetõsége van lassú kapcsolatokkal leterhelni az adott démont, ezáltal kimeríteni a rendszer erõforrásait. Ha úgy találjuk, hogy túlságosan sok az ilyen kapcsolat, akkor jó ötletnek bizonyulhat a démonok számára a , vagy korlátozások elrendelése. Alapértelmezés szerint a TCP kapcsolatok wrappelése engedélyezett. A &man.hosts.access.5; man oldalon találhatjuk meg az inetd által meghívható különféle démonok TCP-alapú korlátozásainak lehetõségeit. Egyéb lehetõségek A daytime, time, echo, discard, chargen és auth szolgáltatások feladatainak mindegyikét maga az inetd is képes ellátni. Az auth szolgáltatás a hálózati keresztül azonosítást teszi lehetõvé és bizonyos mértékig beállítható. A többit egyszerûen csak kapcsoljuk ki vagy be. A témában az &man.inetd.8; man oldalán tudunk még jobban elmerülni. Tom Rhodes Átdolgozta és javította: Bill Swingle Írta: A hálózati állományrendszer (NFS) NFS A &os; több állományrendszert ismer, köztük a hálózati állományrendszert (Network File System, NFS) is. Az NFS állományok és könyvtárak megosztását teszi lehetõvé a hálózaton keresztül. Az NFS használatával a felhasználók és a programok képesek majdnem úgy elérni a távoli rendszereken található állományokat, mintha helyben léteznének. Íme az NFS néhány legjelentõsebb elõnye: A helyi munkaállomások kevesebb tárterületet használnak, mivel a közös adatokat csak egyetlen számítógépen tároljuk és megosztjuk mindenki között. A felhasználóknak nem kell a hálózat minden egyes gépén külön felhasználói könyvtárral rendelkezniük. Ezek ugyanis az NFS segítségével akár egy szerveren is beállíthatóak és elérhetõvé tehetõek a hálózaton keresztül. A különbözõ háttértárak, mint például a floppy lemezek, CD-meghajtók és &iomegazip; meghajtók a hálózaton több számítógép között megoszthatóak. Ezzel csökkenteni tudjuk a hálózatunkban szükséges cserélhetõ lemezes eszközök számát. Ahogy az <acronym>NFS</acronym> mûködik Az NFS legalább két fõ részbõl rakható össze: egy szerverbõl és egy vagy több kliensbõl. A kliensek a szerver által megosztott adatokhoz képesek távolról hozzáférni. A megfelelõ mûködéshez mindössze csak néhány programot kell beállítani és futtatni. A szervernek a következõ démonokat kell mûködtetnie: NFS szerver állományszerver UNIX kliensek rpcbind mountd nfsd Démon Leírás nfsd Az NFS démon, amely kiszolgálja az NFS kliensektõl érkezõ kéréseket. mountd Az NFS csatlakoztató démonja, amely végrehajtja az &man.nfsd.8; által átküldött kéréseket. rpcbind Ez a démon lehetõvé teszi az NFS kliensek számára, hogy fel tudják deríteni az NFS szerver által használt portot. A kliensen is futnia kell egy démonnak, amelynek a neve nfsiod. Az nfsiod démon az NFS szerver felõl érkezõ kéréseket szolgálja ki. A használata teljesen opcionális, csupán a teljesítményt hívatott javítani, de a normális és helyes mûködéshez nincs rá szükségünk. Az &man.nfsiod.8; man oldalán errõl többet is megtudhatunk. Az <acronym>NFS</acronym> beállítása NFS beállítás Az NFS beállítása viszonylag egyértelmûen adja magát. A mûködéséhez szükséges programok automatikus elindítása csupán néhány apró módosítást igényel az /etc/rc.conf állományban. Az NFS szerveren gondoskodjunk róla, hogy az alábbi beállítások szerepeljenek az /etc/rc.conf állományban: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" A mountd magától el fog indulni, ha az NFS szervert engedélyezzük. A kliensen a következõ beállítást kell felvennünk az /etc/rc.conf állományba: nfs_client_enable="YES" Az /etc/exports állomány adja meg, hogy az NFS milyen állományrendszereket exportáljon (vagy másképpen szólva osszon meg). Az /etc/exports állományban tehát a megosztani kívánt állományrendszereket kell szerepeltetnünk, és azt, hogy melyik számítógépekkel tudjuk ezeket elérni. A gépek megnevezése mellett a hozzáférésre további megszorításokat írhatunk fel. Ezek részletes leírását az &man.exports.5; man oldalon találjuk meg. Lássunk néhány példát az /etc/exports állományban megjelenõ bejegyzésekre: NFS példák exportálásra A most következõ példákban az állományrendszerek exportálásának finomságait igyekszünk érzékeltetni, noha a konkrét beállítások gyakran a rendszerünktõl és a hálózati konfigurációtól függenek. Például, ha a /cdrom könytárat akarjuk három gép számára megosztani, akik a szerverrel megegyezõ tartományban találhatóak (ezért nem is kell megadnunk a tartományt) vagy mert egyszerûen megtalálhatók az /etc/hosts állományunkban. Az beállítás az exportált állományrendszereket írásvédetté teszi. Ezzel a beállítással a távoli rendszerek nem lesznek képesek módosítani az exportált állományrendszer tartalmát. /cdrom -ro gép1 gép2 gép3 A következõ sorban a /home könyvtárat három gép számára osztjuk meg, melyeket IP-címekkel adtunk meg. Ez olyan helyi hálózat esetén hasznos, ahol nem állítottunk be névfeloldást. Esetleg a belsõ hálózati neveket az /etc/hosts állományban is tárolhatjuk. Ezzel utóbbival kapcsolatban a &man.hosts.5; man oldalt érdemes fellapoznunk. Az beállítás lehetõvé teszi, hogy az alkönyvtárak is csatlakozási pontok lehessenek. Más szóval, nem fogja csatlakoztatni az alkönyvtárakat, de megengedi a kliensek számára, hogy csak azokat a könyvtárakat csatlakoztassák, amelyeket kell vagy amelyekre szükségünk van. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 A következõ sorban az /a könyvtárat úgy exportáljuk, hogy az állományrendszerhez két különbözõ tartományból is hozzá lehessen férni. A beállítás hatására a távoli rendszer root felhasználója az exportált állományrendszeren szintén root felhasználóként fogja írni az adatokat. Amennyiben a -maproot=root beállítást nem adjuk meg, akkor a távoli rendszeren hiába root az adott felhasználó, az exportált állományrendszeren nem lesz képes egyetlen állományt sem módosítani. /a -maproot=root gep.minta.com doboz.haz.org A kliensek is csak a megfelelõ engedélyek birtokában képesek elérni a megosztott állományrendszereket. Ezért a klienst ne felejtsük el felvenni a szerver /etc/exports állományába. Az /etc/exports állományban az egyes sorok az egyes állományrendszerekre és az egyes gépekre vonatkoznak. A távoli gépek állományrendszerenként csak egyszer adhatóak meg, és csak egy alapértelmezett bejegyzésük lehet. Például tegyük fel, hogy a /usr egy önálló állományrendszer. Ennek megfelelõen az alábbi bejegyzések az /etc/exports állományban érvénytelenek: # Nem használható, ha a /usr egy állományrendszer: /usr/src kliens /usr/ports kliens Egy állományrendszerhez, vagyis itt a /usr partícióhoz, két export sort is megadtunk ugyanahhoz a kliens nevû géphez. Helyesen így kell megoldani az ilyen helyzeteket: /usr/src /usr/ports kliens Az adott géphez tartozó egy állományrendszerre vonatkozó exportoknak mindig egy sorban kell szerepelniük. A kliens nélkül felírt sorok egyetlen géphez tartozónak fognak számítani. Ezzel az állományrendszerek megosztását tudjuk szabályozni, de legtöbbek számára nem jelent gondot. Most egy érvényes exportlista következik, ahol a /usr és az /exports mind helyi állományrendszerek: # Osszuk meg az src és ports könyvtárakat a kliens01 és kliens02 részére, de csak a # kliens01 férhessen hozzá rendszeradminisztrátori jogokkal: /usr/src /usr/ports -maproot=root kliens01 /usr/src /usr/ports kliens02 # A kliensek az /exports könyvtárban teljes joggal rendelkeznek és azon belül # bármit tudnak csatlakoztatni. Rajtuk kívül mindenki csak írásvédetten képes # elérni az /exports/obj könyvtárat: /exports -alldirs -maproot=root kliens01 kliens02 /exports/obj -ro A mountd démonnal az /etc/exports állományt minden egyes módosítása után újra be kell olvastatni, mivel a változtatásaink csak így fognak érvényesülni. Ezt megcsinálhatjuk úgy is, hogy küldünk egy HUP (hangup, avagy felfüggesztés) jelzést a már futó démonnak: &prompt.root; kill -HUP `cat /var/run/mountd.pid` vagy meghívjuk a mountd &man.rc.8; szkriptet a megfelelõ paraméterrel: &prompt.root; /etc/rc.d/mountd onereload Az ban tudhatunk meg részleteket az rc szkriptek használatáról. Ezek után akár a &os; újraindításával is aktiválhatjuk a megosztásokat, habár ez nem feltétlenül szükséges. Ha root felhasználónként kiadjuk a következõ parancsokat, akkor azzal minden szükséges programot elindítunk. Az NFS szerveren tehát: &prompt.root; rpcbind &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r Az NFS kliensen pedig: &prompt.root; nfsiod -n 4 Ezzel most már minden készen áll a távoli állományrendszer csatlakoztatására. A példákban a szerver neve szerver lesz, valamint a kliens neve kliens. Ha csak ideiglenesen akarunk csatlakoztatni egy állományrendszert vagy egyszerûen csak ki akarjuk próbálni a beállításainkat, a kliensen root felhasználóként az alábbi parancsot hajtsuk végre: NFS csatlakoztatás &prompt.root; mount szerver:/home /mnt Ezzel a szerveren található /home könyvtárat fogjuk a kliens /mnt könyvtárába csatlakoztatni. Ha mindent jól beállítottunk, akkor a kliensen most már be tudunk lépni az /mnt könyvtárba és láthatjuk a szerveren található állományokat. Ha a számítógép indításával automatikusan akarunk hálózati állományrendszereket csatlakoztatni, akkor vegyük fel ezeket az /etc/fstab állományba. Erre íme egy példa: szerver:/home /mnt nfs rw 0 0 Az &man.fstab.5; man megtalálhatjuk az összes többi beállítást. Zárolások Bizonyos alkalmazások (például a mutt) csak akkor mûködnek megfelelõen, ha az állományokat a megfelelõ módon zárolják. Az NFS esetében az rpc.lockd használható az ilyen zárolások megvalósítására. Az engedélyezéséhez mind a szerveren és a kliensen vegyük fel a következõ sort az /etc/rc.conf állományba (itt már feltételezzük, hogy az NFS szervert és klienst korábban beállítottuk): rpc_lockd_enable="YES" rpc_statd_enable="YES" A következõ módon indíthatjuk el: &prompt.root; /etc/rc.d/lockd start &prompt.root; /etc/rc.d/statd start Ha nincs szükségünk valódi zárolásra az NFS kliensek és az NFS szerver között, akkor megcsinálhatjuk azt is, hogy az NFS kliensen a &man.mount.nfs.8; programnak az paraméter átadásával csak helyileg végzünk zárolást. Ennek további részleterõl a &man.mount.nfs.8; man oldalon kaphatunk felvilágosítást. Gyakori felhasználási módok Az NFS megoldását a gyakorlatban rengeteg esetben alkalmazzák. Ezek közül most felsoroljuk a legelterjedtebbeket: NFS használata Több gép között megosztunk egy telepítõlemezt vagy más telepítõeszközt. Ez így sokkal olcsóbb és gyakorta kényelmes megoldás abban az esetben, ha egyszerre több gépre akarjuk ugyanazt a szoftvert telepíteni. Nagyobb hálózatokon sokkal kényelmesebb lehet egy központi NFS szerver használata, ahol a felhasználók könyvtárait tároljuk. Ezek a felhasználói könyvtárak aztán megoszthatóak a hálózaton keresztül, így a felhasználók mindig ugyanazt a könyvárat kapják függetlenül attól, hogy milyen munkaállomásról is jelentkeztek be. Több géppel is képes így osztozni az /usr/ports/distfiles könyvtáron. Ezen a módon sokkal gyorsabban tudunk portokat telepíteni a gépekre, mivel nem kell külön mindegyikre letölteni az ehhez szükséges forrásokat. Wylie Stilwell Készítette: Chern Lee Újraírta: Automatikus csatlakoztatás az <application>amd</application> használatával amd automatikus csatlakoztató démon Az &man.amd.8; (automatikus csatlakoztató démon, az automatic mounter daemon) önmûködõen csatlakoztatja a távoli állományrendszereket, amikor azokon belül valamelyik állományhoz vagy könyvtárhoz próbálunk hozzáférni. Emellett az amd az egy ideje már inaktív állományrendszereket is automatikusan leválasztja. Az amd használata egy remek alternatívát kínál az általában az /etc/fstab állományban megjelenõ állandóan csatlakoztatott állományrendszerekkel szemben. Az amd úgy mûködik, hogy kapcsolódik egy NFS szerver /host és /net könyvtáraihoz. Amikor egy állományt akarunk elérni ezeken a könyvtárakon belül, az amd kikeresi a megfelelõ távoli csatlakoztatást és magától csatlakoztatja. A /net segítségével egy IP-címrõl tudunk exportált állományrendszereket csatlakoztatni, miközben a /host a távoli gép hálózati neve esetében használatos. Ha tehát a /host/izemize/usr könyvtárban akarunk elérni egy állományt, akkor az amd démonnak ahhoz elõször az izemize nevû géprõl exportált /usr könyvtárat kell csatlakoztatnia. Egy exportált állományrendszer csatlakoztatása az <application>amd</application> használatával Egy távoli számítógép által rendelkezésre bocsátott megosztásokat a showmount paranccsal tudjuk lekérdezni. Például az izemize gépen elérhetõ exportált állományrendszereket így láthatjuk: &prompt.user; showmount -e izemize Exports list on izemize: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/izemize/usr Ahogy a példában látjuk is, a showmount parancs a /usr könyvtárat mutatja megosztásként. Amikor tehát belépünk a /host/izemize/usr könyvtárba, akkor amd magától megpróbálja feloldani az izemize hálózati nevet és csatlakoztatni az elérni kívánt exportált állományrendszert. Az amd az indító szkripteken keresztül az /etc/rc.conf alábbi beállításával engedélyezhetõ: amd_enable="YES" Emellett még az amd_flags használatával további paraméterek is átadható az amd felé. Alapértelmezés szerint az amd_flags tartalmaz az alábbi: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" Az /etc/amd.map állomány adja meg az exportált állományrendszerek alapértelmezett beállításait. Az /etc/amd.conf állományban az amd további lehetõségeit konfigurálhatjuk.. Ha többet is szeretnénk tudni a témáról, akkor az &man.amd.8; és az &man.amd.conf.5; man oldalakat javasolt elolvasnunk. John Lind Készítette: Problémák más rendszerek használatakor Némely PC-s ISA buszos Ethernet kártyákra olyan korlátozások érvényesek, melyek komoly hálózati problémák keletkezéséhez vezethetnek, különösen az NFS esetében. Ez a nehézség nem &os;-függõ, de a &os; rendszereket is érinti. Ez gond általában majdnem mindig akkor merül fel, amikor egy (&os;-s) PC egy hálózatba kerül többek közt a Silicon Graphic és a Sun Microsystems által gyártott nagyteljesítményû munkaállomásokkal. Az NFS csatlakoztatása és bizonyos mûveletek még hibátlanul végrehajtódnak, azonban hirtelen a szerver látszólag nem válaszol többet a kliens felé úgy, hogy a többi rendszertõl folyamatosan dolgozza felfele a kéréseket. Ez a kliens rendszeren tapasztalható csak, amikor a kliens &os; vagy egy munkaállomás. Sok rendszeren egyszerûen rendesen le sem lehet állítani a klienst, ha a probléma egyszer már felütötte a fejét. Egyedüli megoldás gyakran csak a kliens újraindítása marad, mivel az NFS-ben kialakult helyzetet máshogy nem lehet megoldani. Noha a helyes megoldás az lenne, ha beszereznénk egy nagyobb teljesítményû és kapacitású kártyát a &os; rendszer számára, azonban egy jóval egyszerûbb kerülõút is található a kielégítõ mûködés eléréséhez. Ha a &os; rendszer képviseli a szervert, akkor a kliensnél adjuk meg a beállítást is a csatlakoztatásnál. Ha a &os; rendszer a kliens szerepét tölti be, akkor az NFS állományrendszert az beállítással csatlakoztassuk róla. Ezek a beállítások az fstab állomány negyedik mezõjében is megadhatóak az automatikus csatlakoztatáshoz, vagy manuális esetben a &man.mount.8; parancsnak a paraméterrel. Hozzá kell azonban tennünk, hogy létezik egy másik probléma, amit gyakran ezzel tévesztenek össze, amikor az NFS szerverek és kliensek nem ugyanabban a hálózatban találhatóak. Ilyen esetekben mindenképpen gyõzõdjünk meg róla, hogy az útválasztók rendesen továbbküldik a mûködéshez szükséges UDP információkat, különben nem sokat tudunk tenni a megoldás érdekében. A most következõ példákban a gyorsvonat lesz a nagyteljesítményû munkaállomás (felület) neve, illetve a freebsd pedig a gyengébb teljesítményû Ethernet kártyával rendelkezõ &os; rendszer (felület) neve. A szerveren az /osztott nevû könyvtárat fogjuk NFS állományrendszerként exportálni (lásd &man.exports.5;), amelyet majd a /projekt könyvtárba fogunk csatlakoztatni a kliensen. Minden esetben érdemes lehet még megadnunk a vagy , illetve opciókat is. Ebben a példában a &os; rendszer (freebsd) lesz a kliens, és az /etc/fstab állományában így szerepel az exportált állományrendszer: gyorsvonat:/osztott /projekt nfs rw,-r=1024 0 0 És így tudjuk manuálisan csatlakoztatni: &prompt.root; mount -t nfs -o -r=1024 gyorsvonat:/osztott /projekt Itt a &os; rendszer lesz a szerver, és a gyorsvonat /etc/fstab állománya így fog kinézni: freebsd:/osztott /projekt nfs rw,-w=1024 0 0 Manuálisan így csatlakoztathatjuk az állományrendszert: &prompt.root; mount -t nfs -o -w=1024 freebsd:/osztott /projekt Szinte az összes 16 bites Ethernet kártya képes mûködni a fenti írási vagy olvasási korlátozások nélkül is. A kíváncsibb olvasók számára eláruljuk, hogy pontosan miért is következik be ez a hiba, ami egyben arra is magyarázatot ad, hogy miért nem tudjuk helyrehozni. Az NFS általában 8 kilobyte-os blokkokkal dolgozik (habár kisebb méretû darabkákat is tud készíteni). Mivel az Ethernet által kezelt legnagyobb méret nagyjából 1500 byte, ezért az NFS blokkokat több Ethernet csomagra kell osztani — még olyankor is, ha ez a program felsõbb rétegeiben osztatlan egységként látszik — ezt aztán fogadni kell, összerakni és nyugtázni mint egységet. A nagyteljesítményû munkaállomások a szabvány által még éppen megengedett szorossággal képesek ontani magukból az egy egységhez tartozó csomagokat, közvetlenül egymás után. A kisebb, gyengébb teljesítményû kártyák esetében azonban az egymáshoz tartozó, késõbb érkezõ csomagok ráfutnak a korábban megkapott csomagokra még pontosan azelõtt, hogy elérnék a gépet, így az egységek nem állíthatóak össze vagy nem nyugtázhatóak. Ennek eredményeképpen a munkaállomás egy adott idõ múlva megint próbálkozik, de ismét az egész 8 kilobyte-os blokkot küldi el, ezért ez a folyamat a végtelenségig ismétlõdik. Ha a küldendõ egységek méretét az Ethernet által kezelt csomagok maximális mérete alá csökkentjük, akkor biztosak lehetünk benne, hogy a teljes Ethernet csomag egyben megérkezik és nyugtázódik, így elkerüljük a holtpontot. A nagyteljesítményû munkaállomások természetesen továbbra is küldhetnek a PC-s rendszerek felé túlfutó csomagokat, de egy jobb kártyával az ilyen túlfutások nem érintik az NFS által használt egységeket. Amikor egy ilyen túlfutás bekövetkezik, az érintett egységet egyszerûen újra elküldik, amelyet a rákövetkezõ alkalommal nagy valószínûséggel már tudunk rendesen fogadni, összerakni és nyugtázni. Bill Swingle Írta: Eric Ogren Írta: Udo Erdelhoff Hálózati információs rendszer (NIS/YP) Mi ez? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD A hálózati információs szolgáltatást (Network Information Service, avagy NIS) a Sun Microsystems fejlesztette ki a &unix; (eredetileg &sunos;) rendszerek központosított karbantartásához. Mostanra már lényegében ipari szabvánnyá nõtte ki magát, hiszen az összes nagyobb &unix;-szerû rendszer (a &solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, &os; stb.) támogatja a NIS használatát. sárga oldalak NIS A NIS régebben sárga oldalak (Yellow Pages) néven volt ismert, de a különbözõ jogi problémák miatt késõbb ezt a Sun megváltoztatta. A régi elnevezést (és a yp rövidítést) azonban még napjainkban is lehet néhol látni. NIS tartományok Ez egy RPC alapján mûködõ, kliens/szerver felépítésû rendszer, amely az egy NIS tartomány belül levõ számítógépek számára teszi lehetõvé ugyanazon konfigurációs állományok használatát. Segítségével a rendszergazda a NIS klienseket a lehetõ legkevesebb adat hozzáadásával, eltávolításával vagy módosításával képes egyetlen helyrõl beállítani. Windows NT Hasonló a &windowsnt; tartományaihoz, és habár a belsõ implementációt tekintve már akadnak köztük jelentõs eltérések is, az alapvetõ funkciók szintjén mégis összevethetõek. A témához tartozó fogalmak és programok A NIS telepítése számos fogalom és fontos felhasználói program kerül elõ &os;-n, akár egy NIS szervert akarunk beállítani, akár csak egy NIS klienst: rpcbind portmap Fogalom Leírás NIS tartománynév A NIS központi szerverei és az összes hozzájuk tartozó kliens (beleértve az alárendelt szervereket) rendelkezik egy NIS tartománynévvel. Hasonló a &windowsnt; által használt tartománynevekhez, de a NIS tartománynevei semmilyen kapcsolatban nem állnak a névfeloldással. rpcbind Az RPC (Remote Procedure Call, a NIS által használt egyik hálózati protokoll) engedélyezéséhez lesz rá szükségünk. Ha az rpcbind nem fut, akkor sem NIS szervert, sem pedig NIS klienst nem tudunk mûködtetni. ypbind A NIS klienst köti össze a hozzátartozó NIS szerverrel. A NIS tartománynevet a rendszertõl veszi, és az RPC használatával csatlakozik a szerverhez. Az ypbind a NIS környezet kliens és szerver közti kommunikációjának magját alkotja. Ha az ypbind leáll a kliens gépén, akkor nem tudjuk elérni a NIS szervert. ypserv Csak a NIS szervereken szabad futnia, mivel ez maga a NIS szerver programja. Ha az &man.ypserv.8; leáll, akkor a szerver nem lesz képes tovább kiszolgálni a NIS kéréseket (szerencsére az alárendelt szerverek képesek átvenni ezeket). A NIS bizonyos változatai (de nem az, amelyik a &os;-ben is megjelenik) nem próbálnak meg más szerverekhez csatlakozni, ha bedöglik az aktuális használt szerver. Ezen gyakran egyedül csak a szervert képviselõ program (vagy akár az egész szerver) újraindítása segíthet, illetve az ypbind újraindítása a kliensen. rpc.yppasswdd Ez egy olyan program, amelyet csak a NIS központi szerverein kell csak futtatni. Ez a démon a NIS kliensek számára a NIS jelszavaik megváltoztatását teszi lehetõvé. Ha ez a démon nem fut, akkor a felhasználók csak úgy tudják megváltoztatni a jelszavukat, ha bejelentkeznek a központi NIS szerverre. Hogyan mûködik? A NIS környezetekben háromféle gép létezik: a központi szerverek, az alárendelt szerverek és a kliensek. A szerverek képezik a gépek konfigurációs információinak központi tárhelyét. A központi szerverek tárolják ezen információk hiteles másolatát, míg ezt az alárendelt szerverek redundánsan tükrözik. A kliensek a szerverekre támaszkodnak ezen információk beszerzéséhez. Sok állomány tartalma megosztható ezen a módon. Például a master.passwd, a group és hosts állományokat meg szokták osztani NFS-en. Amikor a kliensen futó valamelyik programnak olyan információra lenne szüksége, amely általában ezekben az állományokban nála megtalálható lenne, akkor helyette a NIS szerverhez fordul. A gépek típusai NIS központi szerver A központi NIS szerver. Ez a szerver, amely leginkább a &windowsnt; elsõdleges tartományvezérlõjéhez hasonlítható tartja karban az összes, NIS kliensek által használt állományt. A passwd, group, és összes többi ehhez hasonló állomány ezen a központi szerveren található meg. Egy gép akár több NIS tartományban is lehet központi szerver. Ezzel a lehetõséggel viszont itt most nem foglalkozunk, mivel most csak egy viszonylag kis méretû NIS környezetet feltételezünk. NIS alárendelt szerver Az alárendelt NIS szerverek. A &windowsnt; tartalék tartományvezérlõihez hasonlítanak, és az alárendelt NIS szerverek feladata a központi NIS szerveren tárolt adatok másolatainak karbantartása. Az alárendelt NIS szerverek a redundancia megvalósításában segítenek, aminek leginkább a fontosabb környezetekben van szerepe. Emellett a központi szerver terhelésének kiegyenlítését is elvégzik. A NIS kliensek elsõként mindig ahhoz a NIS szerverhez csatlakoznak, amelytõl elõször választ kapnak, legyen akár az egy alárendelt szerver. NIS kliens A NIS kliensek. A NIS kliensek, hasonlóan a &windowsnt; munkaállomásokhoz, a NIS szerveren (amely a &windowsnt; munkaállomások esetében a tartományvezérlõ) keresztül jelentkeznek be. A NIS/YP használata Ebben a szakaszban egy példa NIS környezetet állítunk be. Tervezés Tegyük fel, hogy egy aprócska egyetemi labor rendszergazdái vagyunk. A labor, mely 15 &os;-s gépet tudhat magáénak, jelen pillanatban még semmilyen központosított adminisztráció nem létezik. Mindegyik gép saját /etc/passwd és /etc/master.passwd állománnyal rendelkezik. Ezeket az állományokat saját kezûleg kell szinkronban tartani. Tehát ha most felveszünk egy felhasználót a laborhoz, akkor az adduser parancsot mind a 15 gépen ki kell adni. Egyértelmû, hogy ez így nem maradhat, ezért úgy döntöttük, hogy a laborban NIS-t fogunk használni, és két gépet kinevezünk szervernek. Az iméntieknek megfelelõen a labor most valahogy így néz ki: A gép neve IP-cím A gép szerepe ellington 10.0.0.2 központi NIS coltrane 10.0.0.3 alárendelt NIS basie 10.0.0.4 tanszéki munkaállomás bird 10.0.0.5 kliensgép cli[1-11] 10.0.0.[6-17] a többi kliensgép Ha még nincs tapasztalatunk a NIS rendszerek összeállításában, akkor elõször jó ötlet lehet végiggondolni, miként is akarjuk kialakítani. A hálózatunk méretétõl függetlenül is akadnak olyan döntések, amelyeket mindenképpen meg kell hoznunk. A NIS tartománynév megválasztása NIS tartománynév Ez nem az a tartománynév, amit megszokhattunk. Ennek a pontos neve NIS tartománynév. Amikor a kliensek kérnek valamilyen információt, akkor megadják annak a NIS tartománynak a nevét is, amelynek részei. Így tud egy hálózaton több szerver arról dönteni, hogy melyikük melyik kérést válaszolja meg. A NIS által használt tartománynévre tehát inkább úgy érdemes gondolni, mint egy valamilyen módon összetartozó gépek közös nevére. Elõfordul, hogy egyes szervezetek az interneten is nyilvántartott tartománynevüket választják NIS tartománynévnek. Ez alapvetõen nem ajánlott, mivel a hálózati problémák felderítése közben félreértéseket szülhet. A NIS tartománynévnek a hálózatunkon belül egyedinek kell lennie, és lehetõleg minél jobban írja le az általa csoportba sorolt gépeket. Például a Kis Kft. üzleti osztályát tegyük a kis-uzlet NIS tartományba. Ebben a példában most a proba-tartomany nevet választottuk. SunOS A legtöbb operációs rendszer azonban (köztük a &sunos;) a NIS tartománynevet használja internetes tartománynévként is. Ha a hálózatunkon egy vagy több ilyen gép is található, akkor a NIS tartomány nevének az internetes tartománynevet kell megadnunk. A szerverek fizikai elvárásai Nem árt néhány dolgot fejben tartani, amikor a NIS szervernek használt gépet kiválasztjuk. Az egyik ilyen szerencsétlen dolog az a szintû függõség, ami a NIS kliensek felõl megfigyelhetõ a szerverek felé. Ha egy kliens nem tudja a NIS tartományon belül felvenni a kapcsolatot valamelyik szerverrel, akkor az a gép könnyen megbízhatatlanná válhat. Felhasználói- és csoportinformációk nélkül a legtöbb rendszer egy idõre le is merevedik. Ennek figyelembevételével tehát olyan gépet kell szervernek választanunk, amelyet nem kell gyakran újraindítani, és nem végzünk rajta semmilyen komoly munkát. A célnak legjobban megfelelõ NIS szerverek valójában olyan gépek, amelyek egyedüli feladata csak a NIS kérések kiszolgálása. Ha a hálózatunk nem annyira leterhelt, akkor még a NIS szerver mellett más programokat is futtathatunk, de ne feledjük, hogy ha a NIS szolgáltatás megszûnik, akkor az az összes NIS kliensen éreztetni fogja kedvezõtlen hatását. A NIS szerverek A NIS rendszerben tárolt összes információ általános példánya egyetlen gépen található meg, amelyet a központi NIS szervernek hívunk. Az információk tárolására szánt adatbázis pedig NIS táblázatoknak (NIS map) nevezzük. &os; alatt ezek a táblázatok a /var/yp/tartománynév könyvtárban találhatóak, ahol a tartománynév a kiszolgált NIS tartományt nevezi meg. Egyetlen NIS szerver egyszerre akár több tartományt is kiszolgálhat, így itt több könyvtár is található, minden támogatott tartományhoz egy. Minden tartomány saját, egymástól független táblázatokkal rendelkezik. A központi és alárendelt NIS szerverek az ypserv démon segítségével dolgozzák fel a NIS kéréseket. Az ypserv felelõs a NIS kliensektõl befutó kérések fogadásáért, és a kért tartomány valamint táblázat nevébõl meghatározza az adatbázisban tárolt állományt, majd innen visszaküldi a hozzátartozó adatot a kliensnek. A központi NIS szerver beállítása NIS szerver beállítása A központi NIS szerver beállítása viszonylag magától értetõdõ, de a nehézségét az igényeink szabják meg. A &os; alapból támogatja a NIS használatát. Ezért mindössze annyit kell tennünk, hogy a következõ sorokat betesszük az /etc/rc.conf állományba, és a &os; gondoskodik a többirõl. nisdomainname="proba-tartomany" Ez a sor adja meg a hálózati beállítások (vagy például az újraindítás) során a NIS tartomány nevét, amely a korábbiak szerint itt most a proba-tartomany. nis_server_enable="YES" Ezzel utasítjuk a &os;-t, hogy a hálózati alkalmazások következõ indításakor a NIS szervert is aktiválja. nis_yppasswdd_enable="YES" Ezzel engedélyezzük az rpc.yppasswdd démont, amely a korábban említettek szerint lehetõvé teszi a felhasználók számára, hogy a közvetlenül a kliensekrõl változtassák meg a NIS jelszavukat. A konkrét NIS beállításainktól függõen további bejegyzések felvételére is szükségünk lehet. Erre késõbb még az olyan NIS szervereknél, amelyek egyben NIS kliensek, vissza fogunk térni. Most mindössze annyit kell tennünk, hogy rendszeradminisztrátorként kiadjuk az /etc/netstart parancsot. Az /etc/rc.conf állományban szereplõ adatok alapján mindent beállít magától. A NIS táblázatok inicializálása NIS táblázatok A NIS táblázatok lényegében a /var/yp könyvtárban tárolt adatbázisok. A központi NIS szerver /etc könyvtárában található konfigurációs állományokból állítódnak elõ, egyetlen kivétellel: ez az /etc/master.passwd állomány. Ennek megvan a maga oka, hiszen nem akarjuk a root és az összes többi fontosabb felhasználóhoz tartozó jelszót az egész NIS tartománnyal megosztani. Ennek megfelelõen a NIS táblázatok inicializálásához a következõt kell tennünk: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd El kell távolítanunk az összes rendszerszintû (bin, tty, kmem, games, stb), és minden olyan egyéb hozzáférést, amelyeket nem akarjuk közvetíteni a NIS kliensek felé (például a root és minden más nullás, vagyis rendszeradminisztrátori azonosítóval ellátott hozzáférést). Gondoskodjunk róla, hogy az /var/yp/master.passwd állomány sem a csoport, sem pedig bárki más számára nem olvasható (600-as engedély)! Ennek beállításához használjuk az chmod parancsot, ha szükséges. Tru64 UNIX Ha végeztünk, akkor már tényleg itt az ideje inicializálni NIS táblázatainkat. A &os; erre egy ypinit nevû szkriptet ajánl fel (errõl a saját man oldalán tudhatunk meg többet). Ez a szkript egyébként a legtöbb &unix; típusú operációs rendszeren megtalálható, de nem az összesen. A Digital UNIX/Compaq Tru64 UNIX rendszereken ennek a neve ypsetup. Mivel most a központi NIS szerver táblázatait hozzuk létre, azért az ypinit szkriptnek át kell adnunk a opciót is. A NIS táblázatok elõállításánál feltételezzük, hogy a fentebb ismertetett lépéseket már megtettük, majd kiadjuk ezt a parancsot: ellington&prompt.root; ypinit -m proba-tartomany Server Type: MASTER Domain: proba-tartomany Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [ .. a táblázatok generálása .. ] NIS Map update completed. ellington has been setup as an YP master server without any errors. Az üzenetek fordítása: A szerver típusa: KÖZPONTI, tartomány: proba-tartomany Az YP szerver létrehozásához meg kell válaszolni néhány kérdést az eljárás megkezdése elõtt. Szeretnénk, ha az eljárás megszakadna a nem végzetes hibák esetén is? [i/n: n] n Rendben, akkor ne felejtsük el manuálisan kijavítani a hibát, ha valamivel gond lenne. Ha nem tesszük meg, akkor elõfordulhat, hogy valami nem fog rendesen mûködni. Most össze kell állítanunk egy listát a tartomány YP szervereirõl. Jelenleg a rod.darktech.org a központi szerver. Kérjünk, adjon meg további alárendelt szervereket, soronként egyet. Amikor ezt befejeztük, a <control D> lenyomásával tudunk kilépni. központi szerver : ellington következõ gép : coltrane következõ gép : ^D A NIS szerverek listája jelenleg a következõ: ellington coltrane Ez megfelelõ? [i/n: i] i [ .. a táblázatok generálása .. ] A NIS táblázatok sikeressen frissültek. Az elligon szervert minden hiba nélkül sikerült központi szerverként beállítani. Az ypinit a /var/yp/Makefile.dist állományból létrehozza a /var/yp/Makefile állományt. Amennyiben ez létrejött, az állomány feltételezi, hogy csak &os;-s gépek részvételével akarunk kialakítani egy egyszerveres NIS környezetet. Mivel a proba-tartomany még egy alárendelt szervert is tartalmaz, ezért át kell írnunk a /var/yp/Makefile állományt: ellington&prompt.root; vi /var/yp/Makefile Ezt a sort kell megjegyzésbe tennünk: NOPUSH = "True" (ha még nem lenne úgy). Az alárendelt NIS szerverek beállítása NIS alárendelt szerver Az alárendelt NIS szerverek beállítása még a központinál is egyszerûbb. Jelentkezzünk be az alárendelt szerverre és az eddigieknek megfelelõen írjuk át az /etc/rc.conf állományt. Az egyetlen különbség ezúttal csupán annyi lesz, hogy az ypinit lefuttatásakor a opciót kell megadnunk (mint slave, vagyis alárendelt). A opció használatához a központi NIS szerver nevét is át kell adnunk, ezért a konkrét parancs valahogy így fog kinézni: coltrane&prompt.root; ypinit -s ellington proba-tartomany Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. Most már lennie kell egy /var/yp/proba-tartomany nevû könyvtárunknak is. A központi NIS szerver táblázatainak másolata itt fognak tárolódni. Ezeket soha ne felejtsük el frissen tartani. Az alárendelt szervereken a következõ /etc/crontab bejegyzések pontosan ezt a feladatot látják el: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Ez a két sor gondoskodik róla, hogy az alárendelt szerverek ne felejtsék el egyeztetni a táblázataikat a központi szerver táblázataival. Habár ezek a bejegyzések nem nélkülözhetetlenek a megfelelõ mûködéshez, mivel a központi szerver mindig igyekszik az alárendelt szervereknek elküldeni a NIS táblázataiban létrejött változásokat. Mivel azonban a jelszavak létfontosságúak a szervertõl függõ rendszerek számára, ezért jó ötlet lehet explicit módon is elõírni a frissítést. Ez a forgalmasabb hálózatokon nagyobb jelentõséggel bír, mivel ott a táblázatok frissítése nem mindig fejezõdik be rendesen. Most pedig futassuk le a /etc/netstart parancsot az alárendelt szervereken is, amivel így elindul a NIS szerver. A NIS kliensek A NIS kliens az ypbind démon segítségével egy kötésnek (bind) nevezett kapcsolatot épít ki egy adott NIS szerverrel. Az ypbind ellenõrzi a rendszer alapértelmezett tartományát (ezt a domainname paranccsal állítottunk be), majd RPC kéréseket kezd szórni a helyi hálózaton. Ezek a kérések annak a tartománynak a nevét tartalmazzák, amelyhez az ypbind megpróbál kötést létrehozni. Ha az adott tartomány kiszolgálására beállított szerver észleli ezeket a kéréseket, akkor válaszol az ypbind démonnak, amely pedig feljegyzi a szerver címét. Ha több szerver is elérhetõ (például egy központi és több alárendelt), akkor az ypbind az elsõként válaszoló címét fogja rögzíteni. Innentõl kezdve a kliens közvetlenül ennek a szervernek fogja küldeni a NIS kéréseit. Az ypbind idõnként megpingeli a szervert, hogy meggyõzõdjön az elérhetõségérõl. Ha az ypbind egy adott idõn belül nem kap választ a ping kéréseire, akkor megszünteti a kötést a tartományhoz és nekilát keresni egy másik szervert. A NIS kliensek beállítása NIS a kliensek beállítása Egy &os;-s gépet NIS kliensként meglehetõsen egyszerûen lehet beállítani. Nyissuk meg az /etc/rc.conf állományt és a NIS tartománynév beállításához, valamint az ypbind elindításához a következõket írjuk bele: nisdomainname="proba-tartomany" nis_client_enable="YES" A NIS szerveren található jelszavak importálásához távolítsuk el az összes felhasználói hozzáférést az /etc/master.passwd állományunkból és a vipw segítségével adjuk hozzá az alábbi sort az állomány végéhez: +::::::::: Ez a sor beenged bárkit a rendszerünkre, akinek a NIS szervereken van érvényes hozzáférése. A NIS klienseket ezzel a sorral sokféle módon tudjuk állítani. A hálózati csoportokról szóló szakaszban találunk majd errõl több információt. A téma mélyebb megismeréséhez az O'Reilly Managing NFS and NIS címû könyvét ajánljuk. Legalább helyi hozzáférést (vagyis amit nem NIS-en keresztül importálunk) azonban mindenképpen hagyjunk meg az /etc/master.passwd állományunkban, és ez a hozzáférés legyen a wheel csoport tagja. Ha valami gond lenne a NIS használatával, akkor ezen a hozzáférésen keresztül tudunk a gépre távolról bejelentkezni, majd innen root felhasználóra váltva megoldani a felmerült problémákat. A NIS szerverrõl az összes lehetséges csoport-bejegyzést az /etc/group állományban így tudjuk importálni: +:*:: Miután elvégeztük ezeket a lépéseket, képesek leszünk futtatni az ypcat passwd parancsot, és látni a NIS szerver jelszavakat tartalmazó táblázatát. A NIS biztonsága Általában tetszõleges távoli felhasználó küldhet RPC kéréseket az &man.ypserv.8; számára és kérheti le a NIS táblázatok tartalmát, feltéve, hogy ismeri a tartomány nevét. Az ilyen hitelesítés nélküli mûveletek ellen az &man.ypserv.8; úgy védekezik, hogy tartalmaz egy securenets nevû lehetõséget, amellyel az elérhetõségüket tudjuk leszûkíteni gépek egy csoportjára. Az &man.ypserv.8; indításakor ezeket az információkat a /var/yp/securenets állományból próbálja meg betölteni. Az elérési útvonala megadható a opció használatával. Ez az állomány olyan bejegyzéseket tartalmaz, amelyekben egy hálózati cím és tõle láthatatlan karakterekkel elválasztva egy hálózati maszk szerepel. A # karakterrel kezdõdõ sorokat megjegyzésnek nyilvánítjuk. Egy minta securenets állomány valahogy így nézne ki: # Engedélyezzük önmagunkról a csatlakozást -- kell! 127.0.0.1 255.255.255.255 # Engedélyezzük a 192.168.128.0 hálózatról érkezõ csatlakozásokat: 192.168.128.0 255.255.255.0 # Engedélyezzük a laborban található 10.0.0.0 és 10.0.15.255 közti # címekkel rendelkezõ gépek csatlakozását: 10.0.0.0 255.255.240.0 Ha az &man.ypserv.8; olyan címrõl kap kérést, amely illeszkedik az elõírt címek valamelyikére, akkor a szokásos módon feldolgozza azt. Ellenkezõ esetben a kérést figyelmen kívül hagyja és egy figyelmeztetést vesz fel hozzá a naplóba. Ha a /var/yp/securenets állomány nem létezik, akkor az ypserv tetszõleges géprõl engedélyezi a csatlakozást. Az ypserv lehetõséget ad a Wietse Venema által fejlesztett TCP Wrapper csomag használatára is. Ezzel a rendszergazda a /var/yp/securenets állomány helyett a TCP Wrapper konfigurációs állományai alapján képes szabályozni az elérhetõséget. Miközben mind a két módszer nyújt valamilyen fajta védelmet, de a privilegizált portok teszteléséhez hasonlóan az IP álcázásával (IP spoofing) sebezhetõek. Ezért az összes NIS-hez tartozó forgalmat tûzfallal kell blokkolnunk. Az /var/yp/securenets állományt használó szerverek nem képesek az elavult TCP/IP implementációkat használó érvényes klienseket rendesen kiszolgálni. Egyes ilyen implementációk a címben a géphez tartozó biteket nullára állítják az üzenetszóráshoz, és/vagy ezért az üzenetszóráshoz használt cím kiszámításakor nem tudja észleli a hálózati maszkot. A legtöbb ilyen probléma megoldható a kliens konfigurációjának megváltoztatásával, míg más problémák megoldása a kérdéses kliensek nyugdíjazását kívánják meg, vagy a /var/yp/securenets használatának elhagyását. Egy régebbi TCP/IP implementációval üzemelõ szerveren pedig a /var/yp/securenets állomány használata kifejezetten rossz ötlet, és a hálózatunk nagy részében képes használhatatlanná tenni a NIS funkcióit. TCP wrapperek A TCP Wrapper csomag alkalmazása a NIS szerverünk válaszadáshoz szükséges idejét is segít csökkenteni. Az ilyenkor jelentkezõ plusz késlekedés mellesleg elég nagy lehet ahhoz, hogy a klienseknél idõtúllépés következzen be, különösen a terheltebb hálózatokon vagy a lassú NIS szerverek esetében. Ha egy vagy több kliensünk is ilyen tüneteket mutat, akkor érdemes a kérdéses kliens rendszereket alárendelt NIS szerverekké alakítani és önmagukhoz rendelni. Egyes felhasználók bejelentkezésének megakadályozása A laborunkban van egy basie nevû gép, amely a tanszék egyetlen munkaállomása. Ezt a gépet nem akarjuk kivenni a NIS tartományból, de a központi NIS szerver passwd állománya mégis egyaránt tartalmazza a hallgatók és az oktatók eléréseit. Mit lehet ilyenkor tenni? Adott felhasználók esetében le tudjuk tiltani a bejelentkezést a gépen még olyankor is, ha léteznek a NIS adatbázisában. Ehhez mindössze a kliensen az /etc/master.passwd állomány végére be kell tennünk egy -felhasználónév sort, ahol a felhasználónév annak a felhasználónak a neve, akit nem akarunk beengedni a gépre. Ezt leginkább a vipw használatán keresztül érdemes megtennünk, mivel a vipw az /etc/master.passwd állomány alapján végez némi ellenõrzést, valamint a szerkesztés befejeztével magától újragenerálja a jelszavakat tároló adatbázist. Például, ha a bill nevû felhasználót ki akarjuk tiltani a basie nevû géprõl, akkor: basie&prompt.root; vipw [vegyük fel a -bill sort a végére, majd lépjünk ki] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[jelszó]:0:0::0:0:The super-user:/root:/bin/csh toor:[jelszó]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Udo Erdelhoff Készítette: A hálózati csoportok alkalmazása hálózati csoportok Az elõzõ szakaszban ismertetett módszer viszonylag jól mûködik olyan esetekben, amikor nagyon kevés felhasználóra és/vagy számítógépre kell alkalmaznunk speciális megszorításokat. A nagyobb hálózatokban szinte biztos, hogy elfelejtünk kizárni egyes felhasználókat az érzékeny gépekrõl, vagy az összes gépen egyenként kell ehhez a megfelelõ beállításokat elvégezni, és ezzel lényegében elvesztjük a NIS legfontosabb elõnyét, vagyis a központosított karbantarthatóságot. A NIS fejlesztõi erre a problémára a hálózati csoportokat létrehozásával válaszoltak. A céljuk és mûködésük szempontjából leginkább a &unix;-os állományrendszerekben található csoportokhoz mérhetõek. A legnagyobb eltérés a numerikus azonosítók hiányában mutatkozik meg, valamint a hálózati csoportokat a felhasználókon kívül további hálózati csoportok megadásával is ki lehet alakítani. A hálózati csoportok a nagyobb, bonyolultabb, többszáz felhasználós hálózatok számára jöttek létre. Egy részrõl ez nagyon jó dolog, különösen akkor, ha egy ilyen helyzettel kell szembenéznünk. Másrészrõl ez a mértékû bonyolultság szinte teljesen lehetetlenné teszi a hálózati csoportok egyszerû bemutatását. A szakasz további részében használt példa is ezt a problémát igyekszik illusztrálni. Tételezzük fel, hogy laborunkban a NIS sikeres bevezetése felkeltette a fõnökeink figyelmét. Így a következõ feladatunk az lett, hogy terjesszük ki a NIS tartományt az egyetemen található néhány másik gépre is. Az alábbi két táblázatban az új felhasználók és az új számítógép neveit találjuk, valamint a rövid leírásukat. Felhasználók nevei Leírás alpha, beta az IT tanszék hétköznapi dolgozói charlie, delta az IT tanszék újdonsült dolgozói echo, foxtrott, golf, ... átlagos dolgozók able, baker, ... ösztöndíjasok Gépek nevei Leírás haboru, halal, ehseg, szennyezes A legfontosabb szervereink. Csak az IT tanszék dolgozói férhetnek hozzájuk. buszkeseg, kapzsisag, irigyseg, harag, bujasag, lustasag Kevésbé fontos szerverek. Az IT tankszék összes tagja el tudja érni ezeket a gépeket. egy, ketto, harom, negy, ... Átlagos munkaállomások. Egyedül csak a valódi dolgozók jelentkezhetnek be ezekre a gépekre. szemetes Egy nagyon régi gép, semmi értékes adat nincs rajta. Akár még az öszöndíjasok is nyúzhatják. Ha ezeket az igényeket úgy próbáljuk meg teljesíteni, hogy a felhasználókat egyenként blokkoljuk, akkor minden rendszer passwd állományába külön fel kell vennünk a -felhasználó sorokat a letiltott felhasználókhoz. Ha csak egyetlen bejegyzést is kihagyunk, akkor könnyen bajunk származhat belõle. Ez a rendszer kezdeti beállítása során még talán nem okoz gondot, de az új felhasználókat biztosan el fogjuk felejteni felvenni a megfelelõ csoportokba. Elvégre Murphy is optimista volt. A hálózati csoportok használata ilyen helyzetekben számos elõnyt rejt. Nem kell az egyes felhasználókat külön felvenni, egy felhasználót felveszünk valamelyik csoportba vagy csoportokba, és a csoportok összes tagjának egyszerre tudjuk tiltani vagy engedélyezni a hozzáféréseket. Ha hozzáadunk egy új gépet a hálózatunkhoz, akkor mindössze a hálózati csoportok bejelentkezési korlátozásait kell beállítani. Ha új felhasználót veszünk fel, akkor a felhasználót kell vennünk egy vagy több hálózati csoportba. Ezek a változtatások függetlenek egymástól, és nincs szükség minden felhasználó és minden gép összes kombinációjára. Ha a NIS beállításainkat elõzetesen körültekintõen megterveztük, akkor egyetlen központi konfigurációs állományt kell módosítani a gépek elérésének engedélyezéséhez vagy tiltásához. Az elsõ lépés a hálózati csoportokat tartalmazó NIS táblázat inicializálása. A &os; &man.ypinit.8; programja alapértelmezés szerint nem hozza létre ezt a táblázatot, de ha készítünk egy ilyet, akkor a NIS implementációja képes kezelni. Egy ilyen üres táblázat elkészítéséhez ennyit kell begépelni: ellington&prompt.root; vi /var/yp/netgroup Ezután elkezdhetjük felvenni a tartalmát. A példánk szerint legalább négy hálózati csoportot kell csinálnunk: az IT dolgozóinak, az IT új dolgozóinak, a normál dolgozóknak és az öszöndíjasoknak. IT_DOLG (,alpha,proba-tartomany) (,beta,proba-tartomany) IT_UJDOLG (,charlie,proba-tartomany) (,delta,proba-tartomany) FELHASZNALO (,echo,proba-tartomany) (,foxtrott,proba-tartomany) \ (,golf,proba-tartomany) OSZTONDIJAS (,able,proba-tartomany) (,baker,proba-tartomany) Az IT_DOLG, IT_UJDOLG stb. a hálózati csoportok nevei lesznek. Minden egyes zárójelezett csoport egy vagy több felhasználói hozzáférést tartalmaz. A csoportokban szereplõ három mezõ a következõ: Azon gépek neve, amelykre a következõ elemek érvényesek. Ha itt nem adunk meg neveket, akkor a bejegyzés az összes gépre vonatkozik. Ha megadjuk egy gép nevét, akkor jutalmunk a teljes sötétség, a rettegetés és totális megtébolyodás. A csoporthoz tartozó hozzáférés neve. A hozzáféréshez kapcsolódó NIS tartomány. A csoportba más NIS tartományokból is át tudunk hozni hozzáféréseket, ha netalán éppen olyan szerencsétlenek lennénk, hogy több NIS tartományt is felügyelnünk kell. A mezõk mindegyike tartalmazhat dzsókerkaraktereket. Errõl részletesebben a &man.netgroup.5; man oldalon olvashatunk. hálózati csoportok A hálózati csoportoknak lehetõleg ne adjunk 8 karakternél hosszabb nevet, különösen abban az esetben, ha a NIS tartományban más operációs rendszereket is használunk. A nevekben eltérnek a kis- és nagybetûk. Ha a hálózati csoportokat nevét nagybetûkkel írjuk, akkor könnyen különbséget tudunk tenni a felhasználók, gépek és hálózati csoportok nevei között. Egyes (nem &os; alapú) NIS kliensek nem képesek kezelni a nagyon sok bejegyzést tartalmazó hálózati csoportokat. Például a &sunos; néhány korábbi verziója fennakad rajta, ha egy hálózati csoport 15 bejegyzésnél többet tartalmaz. Az ilyen korlátozások alól úgy tudunk kibújni, ha 15 felhasználónként újabb hálózati csoportokat hozunk létre, amelyekkel az eredeti hálózati csoportot építjük fel: NAGYCSP1 (,joe1,tartomany) (,joe2,tartomany) (,joe3,tartomany) [...] NAGYCSP2 (,joe16,tartomany) (,joe17,tartomany) [...] NAGYCSP3 (,joe31,tartomany) (,joe32,tartomany) NAGYCSOPORT NAGYCSP1 NAGYCSP2 NAGYCSP3 Ugyanez a folyamat javasolt olyan esetekben is, ahol 225 felhasználónál többre lenne szükség egyetlen hálózati csoporton belül. Az így létrehozott új NIS táblázat szétküldése meglehetõsen könnyû feladat: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Ez a parancs létrehoz három NIS táblázatot: netgroup, netgroup.byhost és netgroup.byuser. Az &man.ypcat.1; paranccsal ellenõrizni is tudjuk az új NIS táblázatainkat: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser Az elsõ parancs kimenete a /var/yp/netgroup állomány tartalmára emlékeztethet minket. A második parancsnak nincs semmilyen kimenete, hacsak nem adtunk meg valamilyen gépfüggõ hálózati csoportot. A harmadik parancs a hálózati csoportokat listázza ki a felhasználókhoz. A kliensek beállítása tehát nagyon egyszerû. A haboru nevû szerver beállításához indítsuk el a &man.vipw.8; programot, és cseréljük a +::::::::: sort erre: +@IT_DOLG::::::::: Innentõl kezdve kizárólag csak az IT_DOLG csoportban található felhasználók fognak bekerülni a haboru jelszó adatbázisába, és csak ezek a felhasználók tudnak ide bejelentkezni. Sajnos ez a korlátozás a parancsértelmezõ ~ funkciójára és összes olyan rutinra is vonatkozik, amelyet a felhasználói nevek és azok numerikus azonosító között képez le. Más szóval a cd ~felhasználó parancs nem fog mûködni, és az ls -l parancs kimenetében a felhasználói nevek helyett csak numerikus azonosítók jelennek meg, továbbá afind . -user joe -print No such user (Nincs ilyen felhasználó) hibát fog visszaadni. Ez úgy tudjuk megjavítani, ha úgy importáljuk a szerverre az összes felhasználó bejegyzését, hogy közben tiltjuk a hozzáférésüket. Ehhez vegyünk fel egy újabb sort az /etc/master.passwd állományba. A sor valahogy így fog kinézni: +:::::::::/sbin/nologin, amely annyit tesz, hogy importáljuk az összes bejegyzést, de a hozzájuk tartozó parancsértelmezõ a /sbin/nologin legyen. A passwd állományban tetszõleges mezõ tartalmát le tudjuk úgy cserélni, ha megadunk neki egy alapértelmezett értéket az /etc/master.passwd állományban. Vigyázzunk, hogy a +:::::::::/sbin/nologin sort az +@IT_DOLG::::::::: sor után írjuk. Ha nem így teszünk, akkor a NIS-bõl importált összes felhasználói hozzáférés a /sbin/nologin parancsértelmezõt kapja. Miután elvégeztük ezt a változtatást, minden újabb dolgozó felvétele után csupán egyetlen táblázatot kell megváltoztatnunk. Ugyanezt a taktikát követhetjük a kevésbé fontosabb szerverek esetében is, hogy ha a helyi /etc/master.passwd állományukban a korábbi +::::::::: bejegyzést valami ilyesmivel helyettesítjük: +@IT_DOLG::::::::: +@IT_UJDOLG::::::::: +:::::::::/sbin/nologin Az egyszerû munkaállomások esetében pedig ezekre a sorokra lesz szükségünk: +@IT_DOLG::::::::: +@FELHASZNALOK::::::::: +:::::::::/sbin/nologin Minden remekül üzemel egészen addig, amíg néhány hét múlva ismét változik a házirend: az IT tanszékre ösztöndíjasok érkeznek. Az IT ösztöndíjasai a munkaállomásokat és a kevésbé fontosabb szervereket tudják használni. Az új IT dolgozók már a központi szerverekre is bejelentkezhetnek. Így tehát létrehozunk egy új hálózati csoportot IT_OSZTONDIJAS néven, majd felvesszük ide az új IT ösztöndíjasokat, és nekilátunk végigzongorázni az összes gép összes konfigurációs állományát... Ahogy azonban egy régi mondás is tartja: A központosított tervezésben ejtett hibák teljes káoszhoz vezetnek. A NIS az ilyen helyzeteket úgy igyekszik elkerülni, hogy megengedi újabb hálózati csoportok létrehozását más hálózati csoportokból. Egyik ilyen lehetõség a szerep alapú hálózati csoportok kialakítása. Például, ha a fontosabb szerverek bejelentkezési korlátozásai számára hozzunk létre egy NAGYSRV nevû csoportot, valamint egy másik hálózati csoportot KISSRV néven a kevésbé fontosabb szerverekhez, végül MUNKA néven egy harmadik hálózati csoportot a munkaállomásokhoz. Mindegyik ilyen hálózati csoport tartalmazza azokat a csoportokat, amelyek engedélyezik a gépek elérését. A hálózati csoportok leírását tartalmazó NIS táblázat most valahogy így fog kinézni: NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK A bejelentkezési megszorítások ilyen típusú megadása viszonylag jól mûködik, hogy ha azonos korlátozások alá esõ gépek csoportjait akarjuk felírni. Bánatunk ez a kivétel, és nem a szabály. Az esetek nagy többségében ugyanis a bejelentkezésre vonatkozó korlátozásokat gépenként kell egyesével megadni. A hálózati csoportok gépfüggõ megadása tehát az iménti házirendhez társuló igények kielégítésének egyik módja. Ebben a forgatókönyvben az /etc/master.passwd állomány minden számítógépen két +-os sorral kezdõdik. Közülük az elsõ a gépen engedélyezett hozzáféréseket tartalmazó hálózati csoportra vonatkozik, a második pedig az összes többi hozzáféréshez az /sbin/nologin parancsértelmezõt kapcsolja hozzá. Itt jó ötlet, ha a gép nevének VÉGIG-NAGYBETÛS változatát adjuk meg a hozzátartozó hálózati csoport nevének: +@GÉPNÉV::::::::: +:::::::::/sbin/nologin Miután elvégeztük ezt a feladatot minden egyes gépen, az /etc/master.passwd állomány helyi változatait soha többé nem kell módosítanunk. Az összes többi változtatást a NIS táblázaton keresztül tudjuk keresztül vinni. Íme a felvázolt forgatókönyvhöz tartozó hálózati csoportok kiépítésének egyik lehetséges változata, egy-két finomsággal kiegészítve: # Elõször a felhasználók csoportjait adjuk meg: IT_DOLG (,alpha,proba-tartomany) (,beta,proba-tartomany) IT_UJDOLG (,charlie,proba-tartomany) (,delta,proba-tartomany) TANSZ1 (,echo,proba-tartomany) (,foxtrott,proba-tartomany) TANSZ2 (,golf,proba-taromany) (,hotel,proba-tartomany) TANSZ3 (,india,proba-taromany) (,juliet,proba-tartomany) IT_OSZTONDIJAS (,kilo,proba-tartomany) (,lima,proba-tartomany) D_OSZTONDIJAS (,able,proba-tartomany) (,baker,proba-tartomany) # # Most pedig hozzunk létre csoportokat szerepek szerint: FELHASZNALOK TANSZ1 TANSZ2 TANSZ3 NAGYSRV IT_DOLG IT_UJDOLG KISSRV IT_DOLG IT_UJDOLG IT_OSZTONDIJAS MUNKA IT_DOLG IT_OSZTONDIJAS FELHASZNALOK # # Következzenek a speciális feladatokhoz tartozó csoportok: # Az echo és a golf tudja elérni a vírusvédelemért felelõs gépet: VEDELEM IT_DOLG (,echo,proba-tartomany) (,golf,proba-tartomany) # # Gép alapú hálózati csoportok # A fõ szervereink: HABORU NAGYSRV EHSEG NAGYSRV # Az india nevû felhasználó hozzá szeretné ehhez férni: SZENNYEZES NAGYSRV (,india,proba-tartomany) # # Ez valóban fontos és komolyan szabályoznunk kell: HALAL IT_DOLG # # Az elõbb említett vírusvédelmi gép: EGY VEDELEM # # Egyetlen felhasználóra korlátozzuk le ezt a gépet: KETTO (,hotel,proba-tartomany) # [...és itt folytatódik a többi csoporttal] Ha a felhasználói hozzáféréseinket valamilyen adatbázisban tároljuk, akkor a táblázat elsõ részét akár az adatbázis lekérdezésein keresztül is elõ tudjuk állítani. Ezzel a módszerrel az új felhasználók automatikusan hozzáférnek a gépekhez. Legyünk viszont óvatosak: nem mindig javasolt gépeken alapuló hálózati csoportokat készíteni. Ha a hallgatói laborokba egyszerre több tucat vagy akár több száz azonos konfigurációjú gépet telepítünk, akkor a gép alapú csoportok helyett inkább szerep alapú csoportokat építsünk fel, mivel így a NIS táblázatok méretét egy elfogadható méreten tudjuk tartani. Amit feltétlenül észben kell tartanunk Még mindig akad néhány olyan dolog, amit másképpen kell csinálnunk azután, hogy most már NIS környezetben vagyunk. Amikor egy új felhasználót akarunk felvenni a laborba, akkor csak a központi NIS szerverre kell felvennünk, és újra kell generáltatnunk a NIS táblázatokat. Ha ezt elfelejtjük megtenni, akkor az új felhasználó a központi NIS szerveren kívül sehova sem lesz képes bejelentkezni. Például, ha fel akarjuk venni a jsmith nevû felhasználót a laborba, akkor ezt kell tennünk: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make proba-tartomany Vagy a pw useradd jsmith parancs helyett az adduser jsmith parancsot is használhatjuk. A rendszergazdai szintû hozzáféréseket ne tároljuk a NIS táblázatokban. Olyan gépekre egyáltalán ne is küldjünk olyan karbantartáshoz használt hozzáféréseket, amelynek a felhasználói hivatalosan nem is férhetnének hozzájuk. A központi NIS szervert és az alárendelt szervereket óvjuk minél jobban, és igyekezzünk minimalizálni a kieséseiket. Ha valaki feltöri vagy egyszerûen csak kikapcsolja ezeket a gépeket, akkor ezzel lényegében mindenkit megakadályoz abban, hogy be tudjon jelentkezni a laborban. Ezek a központosított vezérlésû rendszerek legfõbb gyengeségei. Ha nem védjük kellõen a NIS szervereinket, akkor azzal nagyon ellenséget szerezhetünk magunknak! Kompatibilitás a NIS elsõ változatával A &os;-ben megtalálható ypserv szolgáltatás valamennyire képes ellátni a NIS elsõ változatát használó klienseket is. A &os; NIS implementációja csak a NIS v2 protokollt használja, azonban mivel más implementációk kompatibilisek kívánnak maradni a régebbi rendszerekkel, ismerik a v1 protokollt is. Az ilyen rendszerekhez tartozó ypbind démonok még olyankor is megpróbálnak v1-es NIS szerverekhez kötést létrehozni, amikor valójában nincs is rá szükségük (és gyakran még akkor is ilyet keresnek, amikor az üzenetükre már válaszolt egy v2-es szerver). Hozzátennénk, hogy bár az ypserver ezen változata a normál klienshívásokat képes feldolgozni, a táblázatokat már nem tudja átküldeni a v1-es klienseknek. Ebbõl következik, hogy a központi vagy alárendelt szerverek nem tudnak együttmûködni olyan NIS szerverekkel, amelyek csak a v1-es protokollt beszélik. Szerencsére ilyen szervereket manapság már alig használnak. NIS szerverek, melyek egyben NIS kliensek Óvatosan kell bánnunk az ypserv elindításával olyan többszerveres tartományokban, ahol a szerverek maguk is NIS kliensek. Alapvetõen nincs abban semmi kivetnivaló, ha a szervereket saját magukhoz kötjük ahelyett, hogy engednénk nekik a kötési kérések küldését és így egymáshoz kötnénk ezeket. Különös hibák tudnak származni olyan helyzetekben, amikor az egyik szerver leáll, miközben a többiek pedig függenek tõle. Végül is ilyenkor minden kliens szépen kivárja a szükséges idõt, aztán megpróbál más szerverekhez kötõdni, de az itt fellépõ késlekedés jelentõs mennyiségû lehet, és ez a hibajelenség ismét fennállhat, mivel elõfordulhat, hogy a szerverek megint egymáshoz kapcsolódnak. A klienst úgy tudjuk egy adott szerverhez kötni, ha az ypbind parancsot a beállítással indítjuk. Ha mindezt nem akarjuk manuálisan megtenni a NIS szerver minden egyes újraindításakor, akkor vegyük fel a következõ sorokat az /etc/rc.conf állományba: nis_client_enable="YES" # elindítjuk a klienst is nis_client_flags="-S NIS tartomány,szerver" Részletesebb lásd az &man.ypbind.8; man oldalát. A jelszavak formátuma NIS jelszavak formátuma A NIS rendszerek kiépítése során az emberek leggyakrabban a jelszavak formátumával kapcsolatban tapasztalnak nehézségeket. Ha a szerverünk DES titkosítású jelszavakat használ, akkor csak olyan klienseket fog tudni támogatni, amelyek szintén így kódolják ezeket. Például, ha a hálózaton vannak &solaris; rendszerû NIS klienseink, akkor szinte biztos, hogy DES titkosítást kell használnunk. A szerverek és a kliensek által használt formátumokat az /etc/login.conf állományba tekintve deríthetjük ki. Ha a gépek többségén a DES titkosítást látjuk, akkor a default osztálynak egy ilyen bejegyzést kell tartalmaznia: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [a többit most nem mutatjuk] A passwd_format tulajdonság további lehetséges értékei lehetnek a blf és az md5 (melyek rendre a Blowfish és MD5 titkosítású jelszavakat adják meg). Ha változtattunk valamit az /etc/login.conf állományban, akkor a bejelentkezési tulajdonságok adatbázisát is újra kell generálni, melyet root felhasználóként a következõ módon tehetünk meg: &prompt.root; cap_mkdb /etc/login.conf Az /etc/master.passwd állományban jelenlevõ jelszavak formátuma azonban nem frissítõdik egészen addig, amíg a felhasználók a bejelentkezési adatbázis újragenerálása után meg nem változtatják a jelszavaikat. Úgy tudjuk még biztosítani, hogy a jelszavak megfelelõ formátumban kódolódjanak, ha az /etc/auth.conf állományban megkeressük a crypt_default sort, amelyben a választható jelszóformátumok felhasználásái sorrendjét találhatjuk meg. Itt tehát mindössze annyit kell tennünk, hogy a kiszemelt formátumot a lista elejére tesszük. Például, ha a DES titkosítású jelszavakat akarunk használni, akkor ez a bejegyzés így fog kinézni: crypt_default = des blf md5 Ha a fenti lépéseket követjük az összes &os; alapú NIS szervernél és kliensnél, akkor biztosra mehetünk abban, hogy a hálózatunkon belül ugyanazt a jelszóformátumot fogják használni. Ha gondunk akadna a NIS kliensek hitelesítésével, akkor itt érdemes kezdeni a hiba felderítését. Ne felejtsük: ha egy NIS szervert egy heterogén hálózatba akarunk telepíteni, akkor valószínûleg az összes rendszeren a DES titkosítást kell választani, mivel általában ez a közös nevezõ ebben a tekintetben. Greg Sutter Írta: A hálózat automatikus beállítása (DHCP) Mi az a DHCP? Dinamikus állomáskonfigurációs protokoll DHCP - internetes szoftverkonzorcium + internetes rendszerkonzorcium (ISC) A Dinamikus állomáskonfigurációs protokoll, avagy Dynamic Host Configuration Protocol (DHCP) annak eszközeit írja le, hogy egy rendszer miként tud csatlakozni egy hálózathoz és miként tudja azon belül megszerezni a kommunikációhoz szükséges információkat. A &os; 6.0 elõtti - változatai az ISC (Internet Software Consortium, vagyis - az internetes szoftverkonzorcium) által kidolgozott DHCP + változatai az ISC (Internet Systems Consortium, vagyis + az internetes rendszerkonzorcium) által kidolgozott DHCP kliens (&man.dhclient.8;) implementációját tartalmazzák. A késõbbi verziókban pedig az OpenBSD 3.7 verziójából átvett dhclient paranccsal dolgozhatunk. Ebben a szakaszban a dhclient parancsra vonatkozó összes információ egyaránt érvényes az ISC és az OpenBSD által fejlesztett DHCP kliensekre. A DHCP szerver az ISC-tõl származik. Mivel foglalkozik ez a szakasz Ebben a szakaszban az ISC és az OpenBSD DHCP klienseinek kliens- és szerver oldali komponsenseit mutatjuk be. A kliens oldali program neve a dhclient, amely a &os; részeként érkezik, és a szerver oldali elem pedig a net/isc-dhcp3-server porton keresztül érhetõ el. A lentebb említett hivatkozások mellett a témában még a &man.dhclient.8;, &man.dhcp-options.5; és a &man.dhclient.conf.5; man adhatnak bõvebb felvilágosítást a témában. Ahogyan mûködik UDP Amikor a dhclient, vagyis a DHCP kliens elindul egy kliensgépen, akkor a hálózaton üzenetszórással próbálja meg elkérni a konfigurációjához szükséges adatokat. Alapértelmezés szerint ezek a kérések a 68-as UDP porton keresztül mennek. A szerver ezekre a 67-es UDP porton válaszol, ahol visszaad a kliensnek egy IP-címet és a hálózat használatához szükséges további információkat, mint például a hálózati maszkot, az alapértelmezett átjáró és a névfeloldásért felelõs szerverek címét. Az összes ilyen jellegû adat egy DHCP bérlet (lease) formájában érkezik meg, amely csak egy adott ideig érvényes (ezt a DHCP szerver karbantartója állítja be). Így a hálózaton a kliens nélküli IP-címeket egy idõ után automatikusan visszanyerjük. A DHCP kliensek rengeteg információt képes elkérni a szervertõl. Ezek teljes listáját a &man.dhcp-options.5; man oldalán olvashatjuk el. Használat a &os;-n belül A &os; teljes egészében tartalmazza az ISC vagy az OpenBSD DHCP kliensét, a dhclient programot (attól függõen, hogy a &os; melyik változatát használjuk). A DHCP kliensek támogatása a telepítõben és az alaprendszerben is megtalálható, és ezzel mentesülünk minden konkrét hálózati beállítás alól a DHCP szervereket alkalmazó hálózatokon. A dhclient a &os; 3.2 változata óta megtalálható a rendszerben. sysinstall DHCP használatát a sysinstall is lehetõvé teszi. Amikor egy hálózati felületet a sysinstall programon belül állítunk be, akkor a második kérdés mindig ez szokott lenni: Do you want to try DHCP configuration of the interface? (Megpróbáljuk DHCP használatával beállítani a felületet?) Ha erre igennel válaszolunk, akkor azzal lényegében a dhclient parancsot indítjuk el, és ha mindez sikerrel zárul, akkor szinte magától kitöltõdik az összes hálózati beállításunk. A DHCP használatához két dolgot kell beállítanunk a rendszerünkön: DHCP követelmények Gondoskodjunk róla, hogy a bpf eszköz része a rendszermagunknak. Ha még nem lenne benne, akkor a rendszermag beállításait tartalmazó állományba vegyük fel a device bpf sort és fordítsuk újra a rendszermagot. A rendszermagok fordításáról a ben tudhatunk meg többet. A bpf eszköz alapból megtalálható a GENERIC rendszermagokban, így ha ezt használjuk, akkor nem kell saját verziót készítenünk a DHCP használatához. Azok számára viszont, akik biztonsági szempontból aggódnak a rendszerük miatt, meg kell említenünk, hogy a bpf egyben az az eszköz, amely a csomagok lehallgatását is lehetõvé teszi (habár az ilyeneket root felhasználóként lehet csak elindítani). A bpf kell a DHCP használatához, azonban ha nagyon fontos nekünk a rendszerünk biztonsága, akkor a bpf eszközt érdemes kivennünk a rendszermagból, ha még pillanatnyilag nem használunk ilyet. Az /etc/rc.conf állományunkat az alábbiak szerint kell módosítani: ifconfig_fxp0="DHCP" Az fxp0 eszközt ne felejtsük el kicserélni arra a felületre, amelyet automatikusan akarunk beállítani. Ennek mikéntje a ban olvasható. Ha a dhclient a rendszerünkben máshol található, vagy egyszerûen csak további beállításokat akarunk átadni a dhclient parancsnak, akkor adjuk meg a következõt is (változtassuk meg igényeink szerint): dhclient_program="/sbin/dhclient" dhclient_flags="" DHCP szerver A DHCP szerver, a dhcpd a net/isc-dhcp3-server port részeként érhetõ el. Az a port tartalmazza az ISC DHCP szerverét és a hozzátartozó dokumentációt. Állományok DHCP konfigurációs állományok /etc/dhclient.conf A dhclient mûködéséhez szükség lesz egy konfigurációs állományra, aminek a neve /etc/dhclient.conf. Ez az állomány általában csak megjegyzéseket tartalmaz, mivel az alapértelmezett értékek többnyire megfelelõek. Ezt a konfigurációs állományt a &man.dhclient.conf.5; man oldal írja le. /sbin/dhclient A dhclient statikusan linkelt és az /sbin könyvtárban található. A &man.dhclient.8; man oldal tud róla részletesebb felvilágosítást adni. /sbin/dhclient-script A dhclient-script a &os;-ben levõ DHCP kliens konfigurációs szkriptje. Mûködését a &man.dhclient-script.8; man oldal írja le, de a felhasználók részérõl semmilyen módosítást nem igényel. /var/db/dhclient.leases A DHCP kliens az érvényes bérleteket tartja nyilván ezekben az állományban és naplóként használja. A &man.dhclient.leases.5; man oldal ezt valamivel bõvebben kifejti. További olvasnivalók A DHCP protokoll mûködését az RFC 2131 mutatja be. A témához kapcsolódóan itt tudunk még leírásokat találni. A DHCP szerverek telepítése és beállítása Mirõl szól ez a szakasz Ebben a szakaszban arról olvashatunk, hogy miként kell egy &os; típusú rendszert DHCP szervernek beállítani, ha az ISC - (internetes szoftverkonzorcium) DHCP szerverét + (internetes rendszerkonzorcium) DHCP szerverét használjuk. Ez a szerver nem része a &os;-nek, ezért a szolgáltatás elindításához elõször fel kell raknunk a net/isc-dhcp3-server portot. A Portgyûjtemény használatára vonatkozóan a lehet segítségünkre. A DHCP szerver telepítése DHCP telepítés Ha a &os; rendszerünket DHCP szerverként akarjuk beállítani, akkor ehhez elsõként a &man.bpf.4; eszköz jelenlétét kell biztosítani a rendszermagban. Ehhez vegyük fel a device bpf sort a rendszermagunk beállításait tartalmazó állományba, majd fordítsuk újra a rendszermagot. A rendszermag lefordításáról a ben olvashatunk. A bpf eszköz a &os;-hez alapból adott GENERIC rendszermag része, ezért a DHCP használatához nem kell feltétlenül újat fordítanunk. A biztonsági szempontok miatt aggódó felhasználók részére megjegyezzük, hogy a bpf eszköz egyben a csomagok lehallgatását is lehetõvé teszi (habár az ilyen témájú programok futtatásához megfelelõ jogokra is szükség van). A bpf használata kötelezõ a DHCP mûködtetéséhez, de ha nagyon kényesek vagyunk a biztonságot illetõen, akkor minden olyan esetben, amikor nem használjuk ki ezt a lehetõséget, távolítsuk el a rendszermagból. A következõ lépésben át kell szerkesztenünk a mintaként mellékelt dhcpd.conf állományt, amelyet a net/isc-dhcp3-server port rakott fel. Ez alapértelmezés szerint a /usr/local/etc/dhcpd.conf.sample néven található meg, és mielõtt bármit is változtatnánk rajta, másoljuk le /usr/local/etc/dhcpd.conf néven. A DHCP szerver beállítása DHCP dhcpd.conf A dhcpd.conf az alhálózatokat illetve a gépeket érintõ deklarációkat tartalmazza, és talán a legkönnyebben a következõ példa alapján mutatható be: option domain-name "minta.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address levelezes.minta.com; } Ez a beállítás adja meg a kliensek számára az alapértelmezett keresési tartományt (search domain). A &man.resolv.conf.5; tud ezzel kapcsolatban részletesebb információkat adni. Ez a beállítás adja meg a kliensek által használt névfeloldó szerverek vesszõvel elválasztott felsorolását. A kliensekhez tartozó hálózati maszk. A kliens egy adott idõre kérhet bérleti jogot, egyébként a szerver dönt a bérlet lejárati idejérõl (másodpercekben). Ez az a maximális idõ, amennyire a szerver hajlandó bérbe adni IP-címet. A kliens ugyan hosszabb idõre is kérheti és meg is kapja, de legfeljebb csak max-lease-time másodpercig lesz érvényes. Ez a beállítás határozza meg, hogy a DHCP szervernek frissítse-e a névoldási információkat a bérlések elfogadásánál vagy visszamondásánál. Az ISC implementációjánál ez a beállítás kötelezõ. Ezzel adjuk meg milyen tartományból tudunk IP-címeket kiosztani a kliensek számára. A kezdõ címet is beleértve, innen fogunk kiutalni egyet a klienseknek. A kliensek felé elküldött alapértelmezett átjáró címe. A gép hardveres MAC-címe (így a DHCP szerver képes felismerni a kérés küldõjét). Ennek megadásával a gépek mindig ugyanazt az IP-címet kapják. Itt már megadhatunk egy hálózati nevet, mivel a bérlethez tartozó információk visszaküldése elõtt maga a DHCP szerver fogja feloldani a gép nevét. Miután befejeztük a dhcpd.conf módosítását, a DHCP szerver az /etc/rc.conf állományban tudjuk engedélyezni, vagyis tegyük bele a következõt: dhcpd_enable="YES" dhcpd_ifaces="dc0" A dc0 felület nevét helyettesítsük annak a felületnek (vagy whitespace karakterekkel elválasztott felületeknek) a nevével, amelyen keresztül a DHCP szerver várni fogja a kliensek kéréseit. Ezután a következõ parancs kiadásával indítsuk el a szervert: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start Amikor a jövõben valamit változtatunk a konfigurációs állományon, akkor ezzel kapcsolatban fontos megemlíteni, hogy ha csak egy SIGHUP jelzést küldünk a dhcpd démonnak, akkor az a többi démontól eltérõen önmagában még nem eredményezi a konfigurációs adatok újraolvasását. Helyette a SIGTERM jelzéssel kell leállítani a programot, majd újraindítani a fenti paranccsal. Állományok DHCP konfigurációs állományok /usr/local/sbin/dhcpd A dhcpd statikusan linkelt és a /usr/local/sbin könyvtárban található. A porttal együtt felkerülõ &man.dhcpd.8; man oldal ad részletesebb útmutatást dhcpd használatáról. /usr/local/etc/dhcpd.conf Mielõtt a dhcpd megkezdhetné mûködését, egy konfigurációs állományra is szükségünk lesz, amely a /usr/local/etc/dhcpd.conf. Ez az állomány tartalmazza az összes olyan információt, ami kell a kliensek megfelelõ kiszolgálásához valamint a szerver mûködéséhez. Ez a konfigurációs állomány porthoz tartozó &man.dhcpd.conf.5; man oldalon kerül ismertetésre. /var/db/dhcpd.leases A DHCP szerver ebben az állományba tartja nyilván a kiadott bérleteket, egy napló formájában. A porthoz kapcsolódó &man.dhcpd.leases.5; man oldalon errõl többet is megtudhatunk. /usr/local/sbin/dhcrelay A dhcrelay állománynak olyan komolyabb környezetekben van szerepe, ahol a DHCP szerver a kliensektõl érkezõ kéréseket egy másik hálózaton található DHCP szerverhez továbbítja. Ha szükség lenne erre a lehetõségre, akkor telepítsük fel a net/isc-dhcp3-relay portot. A porthoz tartozó &man.dhcrelay.8; man oldal ennek részleteit taglalja. Chern Lee Készítette: Tom Rhodes Daniel Gerzo Névfeloldás (<acronym>DNS</acronym>) Áttekintés BIND A &os; alapértelmezés szerint a BIND (Berkeley Internet Name Domain) egyik verzióját tartalmazza, amely a névfeloldási (Domain Name System, DNS) protokoll egyik elterjedt implementációja. A DNS protokollon keresztül tudunk az IP-címekhez neveket rendelni és fordítva. Például a www.FreeBSD.org névre a &os; Projekt webszerverének IP-címét kapjuk meg, miközben a ftp.FreeBSD.org pedig a hozzátartozó FTP szerver IP-címét fogja visszaadni. Ehhez hasonlóan a fordítottja is megtörténhet, vagyis egy IP-címhez is kérhetjük a hálózati név feloldását. A névfeloldási kérések kiszolgálásához nem feltétlenül szükséges névszervert futtatni a rendszerünkön. A &os; jelen pillanatban alapból a BIND9 névszervert tartalmazza. A benne szereplõ változata több biztonsági javítást, új állományrendszeri kiosztást és automatizált &man.chroot.8; beállítást is magában foglal. névfeloldás Az interneten keresztüli névfeloldást legfelsõ szintû tartományoknak (Top Level Domain, TLD) nevezett hitelesített tövek némileg bonyolult rendszerén alapszik, valamint más egyéb olyan névszervereken, amelyek további egyéni információkat tárolnak és táraznak. A BIND fejlesztését jelenleg az Internet - Software Consortium () + Systems Consortium () felügyeli. Alapfogalmak A leírás megértéséhez be kell mutatnunk néhány névfeloldással kapcsolatos fogalmat. névfeloldó inverz DNS gyökérzóna Fogalom Meghatározás Közvetlen névfeloldás (forward DNS) A hálózati nevek leképezése IP-címekre. Õs (origin) Egy adott zóna állományban szereplõ tartományra vonatkozik. - named, BIND, - névszerver (name server) + named, BIND A &os;-n belüli BIND névszerver különbözõ megnevezései. Névfeloldó (resolver) Az a program a rendszerben, amelyhez a hálózaton levõ gépek a zónák adatainak elérésével kapcsolatban fordulnak. Inverz névfeloldás (reverse DNS) - A rendes névfeloldás - ellentéte, vagyis az - IP-címek + Az IP-címek leképzése hálózati nevekre. Gyökérzóna (root zone) Az interneten található zónák hierarchiájának töve. Minden zóna ebbe a gyökérzónába esik, ahhoz hasonlóan, ahogy egy állományrendszerben az állományok a gyökérkönyvtárba. Zóna (zone) Egy különálló tartomány, altartomány vagy a névfeloldás azon része, amelyet egyazon fennhatóság alatt tartanak karban. zónák példák Példák zónákra: - A . - gyökérzóna. + A gyökérzónára a + leírásokban általában + . néven szoktak hivatkozni. A org. egy legfelsõ szintû tartomány (TLD) a gyökérzónán belül. A minta.org. a org. TLD tartomány alatti zóna. A 1.168.192.in-addr.arpa egy olyan zóna, amelyek a 192.168.1.* - IP-tartományban szereplõ - összes címet jelöli. + IP-címtartományban + szereplõ összes címet jelöli. Mint láthatjuk, a hálózati nevek balról kiegészülve pontosodnak. Tehát például a minta.org. sokkal pontosabb meghatározás, mint a org., ahogy az org. magánál a gyökérzónánál jelent többet. A hálózati nevek felosztása leginkább egy állományrendszerhez hasonlítható, például a /dev könyvtár a gyökéren belül található, és így tovább. Miért érdemes névszervert futtatni A névszerverek általában két alakban jelennek meg. Egyikük a hitelesített névszerver, a másikuk a gyorsítótárazó névszerver. Egy hitelesített névszerverre akkor van szükségünk, ha: a világ többi része felé akarunk hiteles névfeloldási információkat szolgáltatni; regisztráltunk egy tartományt (például minta.org) és az alatta levõ hálózati nevekhez is szeretnénk IP-címeket rendeltetni; a IP-címtartományunkban szükség van inverz névfeloldási bejegyzésekre (amely IP-címbõl ad meg hálózati nevet) is; a kérések teljesítéséhez egy tartalék avagy második, alárendelt (slave) névszerver kell. A gyorsítótárazó névszerverre akkor van szükségünk, ha: egy helyi névfeloldó szerver felhasználásával fel akarjuk gyorsítani az egyébként a külsõ névszerver felé irányuló kérések kiszolgálását. Amikor valaki lekérdezi a www.FreeBSD.org címét, akkor a névfeloldó elõször általában a kapcsolatot rendelkezésre bocsátó internet-szolgáltató névszerverét kérdezi meg és onnan kapja meg a választ. Egy helyi, gyorsítótárazó névszerver használata esetén azonban egy ilyen kérést csak egyszer kell kiadni a külsõ névszervernek. Ezután már minden további ilyen kérés el sem hagyja a belsõ hálózatunkat, mivel a válasz szerepel a gyorsítótárban. Ahogyan mûködik &os; alatt a BIND démon nyilvánvaló okokból named néven érhetõ el. Állomány Leírás &man.named.8; A BIND démon. &man.rndc.8; A névszervert vezérlõ segédprogram. /etc/namedb A BIND által kezelt zónák adatait tároló könyvtár. /etc/namedb/named.conf A démon konfigurációs állománya. Attól függõen, hogy miként állítjuk be az adott zónát a szerveren, a hozzátartozó állományok a /etc/namedb könyvtáron belül a master, slave vagy dynamic alkönyvtárban foglalnak helyet. Az itt tárolt állományokban levõ névfeloldási információk alapján válaszol a névszerver a felé intézett kérésekre. A BIND elindítása BIND elindítás Mivel a BIND alapból elérhetõ a rendszerben, viszonylag könnyen be tudjuk állítani. A named alapértelmezett beállítása szerint egy &man.chroot.8; környezetben futó egyszerû - névfeloldást végzõ szerver. Ezzel a + névfeloldást végzõ szerver, amely a + helyi IPv4 interfészen (127.0.0.1) fogadja a + kéréseket. Ezzel a beállítással a következõ parancson keresztül tudjuk elindítani: - &prompt.root; /etc/rc.d/named forcestart + &prompt.root; /etc/rc.d/named onestart Ha engedélyezni akarjuk a named démont minden egyes rendszerindításkor, tegyük a következõ sort az /etc/rc.conf állományba: named_enable="YES" Értelemszerûen az /etc/namedb/named.conf tele van olyan beállítási lehetõségekkel, amelyek meghaladják ennek a leírásnak a kereteit. Ha viszont kíváncsiak vagyunk a &os;-ben a named indításához használt beállításokra, akkor az /etc/defaults/rc.conf állományban nézzük meg named_* változókat és olvassuk át az &man.rc.conf.5; man oldalt. Emellett még a t is hasznos lehet elolvasni. A konfigurációs állományok BIND konfigurációs állományok A named beállításait tartalmazó állományok pillanatnyilag az /etc/namedb könyvtárban találhatóak és hacsak nem egy egyszerû névfeloldóra tartunk igényt, akkor a használata elõtt módosítanunk is kell. Itt ejtjük meg a beállítások nagy részét. - - A <command>make-localhost</command> - használata - - Ha a helyi gépen egy központi - zónát akarunk beállítani, akkor - lépjünk be az /etc/namedb könyvtárba - és futtassuk le a következõ parancsot: - - &prompt.root; sh make-localhost - - Ha nem történt semmilyen hiba, akkor a - master - alkönyvtárban most meg kell jelennie egy új - állománynak. A helyi - tartománynévhez tartozó - állomány a localhost.rev, - valamint IPv6 környezetben a - localhost-v6.rev. Alapértelmezett - konfigurációs állományként - a named.conf ehhez tartalmaz minden - szükséges információt. - - - <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Részletesebb leírást a named.conf(5) és named(8) man oldalakon, valamint // a /usr/share/doc/bind9 könyvtárban találhatunk. // // Ha egy hitelesített szervert akarunk beállítani, akkor igyekezzünk // a névfeloldás összes finom részletével pontosan tisztában lenni. // Ugyanis még a legkisebb hibákkal is egyrészt elvághatunk gépeket az // internet-lérésétõl, vagy másrészt felesleges forgalmat tudunk // generálni // options { + // A chroot könyvtárhoz relatív elérési út, amennyiben létezik directory "/etc/namedb"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // Ha a named démont csak helyi névfeloldóként használjuk, akkor ez // egy biztonságos alapbeállítás. Ha viszont a named démon az egész // hálózatunkat is kiszolgálja, akkor ezt a beállítást tegyük // megjegyzésbe, vagy adjunk meg egy rendes IP-címet, esetleg // töröljük ki. listen-on { 127.0.0.1; }; // Ha rendszerünkön engedélyezett az IPv6 használata, akkor a helyi // névfeloldó használatához ezt a sort vegyük ki a megjegyzésbõl. // A hálózatunk többi részérõl pedig úgy lehet elérni, ha itt megadunk // egy IPv6 címet, vagy az "any" kulcsszót. // listen-on-v6 { ::1; }; -// A "forwarders" blokk mellett a következõ sorral megkérhetjük a -// névszervert, hogy önmagától soha nem kezdeményezzen kéréseket, -// hanem mindig az iménti helyen megjelölt szerverekhez irányítsa -// ezeket: -// -// forward only; +// Az alábbi zónákat már a lentebb található üres zónák eleve lefedik. +// Ha tehát a lenti üres zónákat kivesszük a konfigurációból, akkor +// ezeket a sorokat is tegyük megjegyzésbe. + disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; + disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; + disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // Ha a szolgáltatónk névszervert is elérhetõvé tett számunkra, akkor // itt adjuk meg annak az IP-címét és engedélyezzük az alábbi sort. // Ezzel egyben kihasználjuk a gyorsítótárat is, így mérsékeljük az // internet felé mozgó névfeloldásokat. /* forwarders { 127.0.0.1; }; -*/ +* + +// Ha a 'forwarders' rész nem üres, akkor alapértelmezés szerint a +// 'forward first' értékkel rendelkezik. Ekkor a kérést a helyi szerver +// kapja abban az esetben, amikor a 'forwarders' részben megadott +// szerverek nem tudják megválaszolni. Emellett a névszerverben a +// következõ sor hozzáadásával letilthatjuk, hogy önmagától ne +// kezdeményezzen kéréseket: +// forward only; + +// Ha a kérések továbbítását az /etc/resolv.conf állományban megadott +// bejegyzések mentén szeretnénk automatikusan konfigurálni, akkor vegyük +// ki a megjegyzésbõl az alábbi sort és adjuk hozzá az /etc/rc.conf +// állományhoz a name_auto_forward=yes sort. Emellett használható még a +// named_auto_forward_only beállítás is (amely fentebb leírt funkciót +// valósítja meg). +// include "/etc/namedb/auto_forward.conf"; Ahogy arról a megjegyzésekben is szó esik, úgy tudjuk aktiválni a gyorsítótárat, ha megadjuk a forwarders beállítást. Normális körülmények között a névszerver az interneten az egyes névszervereket rekurzívan fogja keresni egészen addig, amíg meg nem találja a keresett választ. Az iménti beállítás engedélyezésével azonban elõször a szolgáltató névszerverét (vagy az általa kijelölt névszervert) fogjuk megkérdezni, a saját gyorsítótárából. Ha a szolgáltató kérdéses névszervere egy gyakran használt, gyors névszerver, akkor ezt érdemes bekapcsolnunk. Itt a 127.0.0.1 megadása nem mûködik. Mindenképpen írjuk át a szolgáltatónk névszerverének IP-címére. /* - * Ha köztünk és az elérni kívánt névszerverek között tûzfal - * is található, akkor az alábbi "query-source" direktívát is - * engedélyeznünk kell. A BIND korábbi változatait mindig az - * 53-as porton keresztül küldték el a kéréseiket, de BIND - * nyolcadik verziójától kezdve alapértelmezés szerint - * erre a feladatra már egy véletlenszerûen választott, nem - * privilegizált UDP portot használnak. + A BIND legújabb változataiban alapértelmezés szerint minden egyes + kimenõ kérésnél más, véletlenszerûen választott UDP portot + használnak, ezáltal jelentõs mértékben csökkenthetõ a gyorsítótár + meghamisíthatóságának (cache poisoning) esélye. Javasoljuk + mindenkinek, hogy használják ki ezt a lehetõséget és eszerint + állítsák be a tûzfalakat. + + Ha nem sikerül a tûzfalat hozzáigazítani ehhez a + viselkedéshez AKKOR ÉS CSAK IS AKKOR engedélyezzük a lenti + beállítást. Alkalmazásával sokkal kevésbé lesz ellenálló a + névszerver a különbözõ hamisítási kísérletekkel szemben, + ezért lehetõség szerint kerüljük el. + + Az NNNNN helyére egy 49160 és 65530 közti számot kell + beírnunk. */ - // query-source address * port 53; + // query-source address * port NNNNN; }; // Ha engedélyezzük a helyi névszervert, akkor az /etc/resolv.conf // állományban elsõ helyen megadni a 127.0.0.1 címet. Sõt, az // /etc/rc.conf állományból se felejtsük ki. +// A hagyományos "root-hints" megoldás. Használjuk ezt VAGY a lentebb +// megadott alárendelt zónákat. +zone "." { type hint; file "named.root"; }; + +/* Több szempontból is elõnyös, ha a következõ zónákat alárendeljük a + gyökér névfeloldó szervereknek: + 1. A helyi felhasználók kéréseit gyorsabban tudjuk feloldalni. + 2. A gyökérszerverek felé nem megy semmilyen hamis forgalom. + 3. A gyökérszerverek meghibásodása vagy elosztott DoS támadás + esetén rugalmasabban tudunk reagálni. + + Másfelöl azonban ez a módszer a "hints" állomány alkalmazásával + szemben több felügyeletet igényel, mivel figyelnünk kell, nehogy + egy váratlan meghibásodás mûködésképtelenné tegye a + szerverünket. Ez a megoldás leginkább a sok klienst kiszolgáló + névszerverek esetén bizonyulhat jövedelmezõbbnek. Óvatosan + bánjunk vele! + + A módszer alkalmazásához vegyük ki a megjegyzésbõl a következõ + bejegyzéseket és tegyük megjegyzésbe a fenti hint zónát. +*/ + zone "." { - type hint; - file "named.root"; + type slave; + file "slave/root.slave"; + masters { + 192.5.5.241; // F.ROOT-SERVERS.NET. + }; + notify no; }; -zone "0.0.127.IN-ADDR.ARPA" { - type master; - file "master/localhost.rev"; -}; +zone "arpa" { + type slave; + file "slave/arpa.slave"; + masters { + 192.5.5.241; // F.ROOT-SERVERS.NET. + }; + notify no; +} -// RFC 3152 -zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" { - type master; - file "master/localhost-v6.rev"; +zone "in-addr.arpa" { + type slave; + file "slave/in-addr.arpa.slave"; + masters { + 192.5.5.241; // F.ROOT-SERVERS.NET. + }; + notify no; }; +*/ + +/* Az alábbi zónák helyi kiszolgálásával meg tudjuk akadályozni, hogy + a belõlük indított kérések elhagyják a hálózatunkat és a elérjük + a gyökér névfeloldó szervereket. Ez a megközelítés két komoly + elõnnyel rendelkezik: + 1. A helyi felhasználók kéréseit gyorsabban tudjuk + megválaszolni. + 2. A gyökérszerverek felé nem továbbítódik semmilyen hamis + forgalom. +*/ +// RFC 1912 +zone "localhost" { type master; file "master/localhost-forward.db"; }; +zone "127.in-addr.arpa" { type master; file "master/localhost-reverse.db"; }; +zone "255.in-addr.arpa" { type master; file "master/empty.db"; }; + +// A helyi IPv6 címek részére létrehozott RFC 1912-szerû zóna +zone "0.ip6.arpa" { type master; file "master/localhost-reverse.db"; }; + +// "Ez" a hálózat (RFC 1912 és 3330) +zone "0.in-addr.arpa" { type master; file "master/empty.db"; }; + +// Magáncélú hálózatok (RFC 1918) +zone "10.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "16.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "17.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "18.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "19.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "20.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "21.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "22.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "23.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "24.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "25.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "26.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "27.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "28.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "29.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "30.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "31.172.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "168.192.in-addr.arpa" { type master; file "master/empty.db"; }; + +// Helyi link/APIPA (RFC 3330 és 3927) +zone "254.169.in-addr.arpa" { type master; file "master/empty.db"; }; + +// Dokumentációs próbahálózat (RFC 3330) +zone "2.0.192.in-addr.arpa" { type master; file "master/empty.db"; }; + +// Útválasztási teljesítmény tesztelésére (RFC 3330) +zone "18.198.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "19.198.in-addr.arpa" { type master; file "master/empty.db"; }; + +// Az IANA részére fentartott - a régi E osztályú címtér +zone "240.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "241.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "242.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "243.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "244.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "245.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "246.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "247.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "248.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "249.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "250.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "251.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "252.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "253.in-addr.arpa" { type master; file "master/empty.db"; }; +zone "254.in-addr.arpa" { type master; file "master/empty.db"; }; + +// Hozzárendelés nélküli IPv6-címek (RFC 4291) +zone "1.ip6.arpa" { type master; file "master/empty.db"; }; +zone "3.ip6.arpa" { type master; file "master/empty.db"; }; +zone "4.ip6.arpa" { type master; file "master/empty.db"; }; +zone "5.ip6.arpa" { type master; file "master/empty.db"; }; +zone "6.ip6.arpa" { type master; file "master/empty.db"; }; +zone "7.ip6.arpa" { type master; file "master/empty.db"; }; +zone "8.ip6.arpa" { type master; file "master/empty.db"; }; +zone "9.ip6.arpa" { type master; file "master/empty.db"; }; +zone "a.ip6.arpa" { type master; file "master/empty.db"; }; +zone "b.ip6.arpa" { type master; file "master/empty.db"; }; +zone "c.ip6.arpa" { type master; file "master/empty.db"; }; +zone "d.ip6.arpa" { type master; file "master/empty.db"; }; +zone "e.ip6.arpa" { type master; file "master/empty.db"; }; +zone "0.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "1.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "2.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "3.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "4.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "5.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "6.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "7.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "8.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "9.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "a.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "b.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "0.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "1.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "2.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "3.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "4.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "5.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "6.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "7.e.f.ip6.arpa" { type master; file "master/empty.db"; }; + +// IPv6 ULA (RFC 4193) +zone "c.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "d.f.ip6.arpa" { type master; file "master/empty.db"; }; + +// IPv6 helyi link (RFC 4291) +zone "8.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "9.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "a.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "b.e.f.ip6.arpa" { type master; file "master/empty.db"; }; + +// Elavult IPv6 helyi címek (RFC 3879) +zone "c.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "d.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "e.e.f.ip6.arpa" { type master; file "master/empty.db"; }; +zone "f.e.f.ip6.arpa" { type master; file "master/empty.db"; }; + +// Az IP6.INT már elavult (RFC 4159) +zone "ip6.int" { type master; file "master/empty.db"; }; // FONTOS: Ne használjuk ezeket az IP-címeket, mert nem valódiak, // csupán illusztrációs és dokumentációs célokból adtuk meg! // // Az alárendelt zónák beállításaira vonatkozó bejegyzések. Érdemes // ilyet beállítani legalább ahhoz a zónához, amelyhez a tartományunk is -// tartozik. Az elsõdleges zónához tartozó IP-címet érdeklõdjük meg +// tartozik. Az elsõdleges névszerverhez tartozó IP-címet érdeklõdjük meg // az illetékes hálózati rendszergazdától. // -// Soha ne felejtsünk el megadni zónát az inverz kereséshez -// IN-ADDR.ARPA)! (A neve a IP-cím tagjainak fordított sorrendjébõl -// származik, amelyhez hozzátoldunk még egy ".IN-ADDR.ARPA" részt.) +// Soha ne felejtsünk el megadni zónát az inverz kereséshez! A neve az IP-cím +// tagjainak fordított sorrendjébõl // származik, amelyhez hozzátoldunk még egy +// ".IN-ADDR.ARPA" (illetve IPv6 esetén ".IP6.ARPA") részt. // // Mielõtt nekilátnánk egy elsõdleges zóna beállításának, gondoljuk // végig, hogy tényleg a megfelelõ szinten ismerjük a névfeloldás és // a BIND mûködését. Gyakran ugyanis egyáltalán nem nyilvánvaló -// csapdákba tudunk esni. Egy alárendelt zóna beállítása sokkal -// egyszerûbb feladat. +// csapdákba tudunk esni. Egy alárendelt zóna beállítása általában sokkal egyszerûbb feladat. // // FONTOS: Ne kövessük vakon a most következõ példát :-) Helyette inkább // valódi neveket és címeket adjunk meg. -/* Példa központi zónára -zone "minta.net" { - type master; - file "master/minta.net"; -}; -*/ - /* Példa dinamikus zónára key "mintaorgkulcs" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "minta.org" { type master; allow-update { key "mintaorgkulcs"; }; file "dynamic/minta.org"; }; */ -/* Példa közvetlen és inverz alárendelt zónákra -zone "minta.com" { - type slave; - file "slave/minta.com"; - masters { - 192.168.1.1; - }; -}; +/* Példa inverz alárendelt zónákra zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ A named.conf állományban tehát így adhatunk meg közvetlen és inverz alárendelt zónákat. Minden egyes újabb kiszolgált zónához az egy új bejegyzést kell felvenni a named.conf állományban. Például a minta.org címhez tartozó legegyszerûbb ilyen bejegyzés így néz ki: zone "minta.org" { type master; file "master/minta.org"; }; Ez egy központi zóna, ahogy arról a mezõ, vagyis a típusa is árulkodik. Továbbá a mezõben láthatjuk, hogy a hozzátartozó információkat az /etc/namedb/master/minta.org állományban tárolja. zone "minta.org" { type slave; file "slave/minta.org"; }; Az alárendelt esetben a zónához tartozó információkat a zóna központi szerverétõl kapjuk meg és megadott állományban mentjük el. Ha valamiért a központi szerver leáll vagy nem érhetõ el, akkor az alárendelt szerver az átküldött zóna információk alapján képes helyette kiszolgálni a kéréseket. - A zóna állományok BIND zóna állományok A minta.org címhez tartozó példa központi zóna állomány (amely az /etc/namedb/master/néven.org érhetõ el) tartalma az alábbi: - $TTL 3600 ; 1 óra + $TTL 3600 ; alapértelmezés szerint 1 óra minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat - 86400 ; minimális TTL + 300 ; TTL negatív válasz ) ; névszerverek IN NS ns1.minta.org. IN NS ns2.minta.org. ; MX rekordok IN MX 10 mx.minta.org. IN MX 20 levelezes.minta.org. IN A 192.168.1.1 ; a gépek nevei localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5 ; álnevek -www IN CNAME @ +www IN CNAME minta.org. A .-ra végzõdõ hálózati nevek abszolút nevek, míg minden más . nélküli név az õsére vezehetõ vissza - (tehát relatív). Például a - www a - www.õs. A - kitalált zóna állományunkban itt - most az õs a minta.org, így a - www névbõl a - www.minta.org név keletkezik. + (tehát relatív). Például az + ns1 névbõl az + ns1.minta.org + keletkezik. A zóna állományok felépítése a következõ: rekordnév IN rekordtípus érték névfeloldás rekordok A névfeloldásban leggyakrabban alkalmazott rekordok típusai: SOA a zóna fennhatóságának kezdete NS egy hitelesített névszerver A egy gép címe CNAME egy álnév kanonikus neve MX levélváltó PTR mutató a tartománynévre (az inverz feloldás használja) minta.org. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; 3 óránként frissítsünk 3600 ; 1 óra után próbálkozzunk újra 604800 ; 1 hét után jár le - 86400 ) ; a minimális TTL 1 nap - - + 300 ) ; TTL negatív válasz minta.org. a tartomány neve, amely egyben a zóna õse ns1.minta.org. a zóna elsõdleges/hitelesített névszervere admin.minta.org. a zónáért felelõs személy neve, akinek az e-mail címét a @ behelyettesítésével kapjuk meg. (Tehát a admin@example.org címbõl admin.example.org lesz.) 2006051501 az állomány sorozatszáma. Ezt a zóna állomány módosításakor mindig növelnünk kell. Manapság a rendszergazdák a sorozatszámot ééééhhnnvv alakban adják meg. A 2006051501 tehát azt jelenti, hogy az állományt 2006. május 15-én módosították utoljára, és a 01 pedig arra utal, hogy aznap elõször. A sorozatszám megadása fontos az alárendelt névszerverek számára, mivel így tudják megállapítani, hogy a zóna mikor változott utoljára. - IN NS ns1.minta.org. + IN NS ns1.minta.org. Ez egy NS bejegyzés. A zónához tartozó minden hitelesített névszervernek lennie kell legalább egy ilyen bejegyzésének. - -localhost IN A 127.0.0.1 + localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 levelezes IN A 192.168.1.5 Az A rekord egy gép nevét adja meg. Ahogy a fenti példából is kiderül, az ns1.minta.org név a 192.168.1.2 címre képzõdik le. - - IN A 192.168.1.1 + IN A 192.168.1.1 Ez a sor 192.168.1.1 címet rendeli az aktuális õshöz, amely jelen esetünkben az example.org. - -www IN CNAME @ + www IN CNAME @ A kanonikus neveket tároló rekordokat általában egy gép álneveihez használjuk. Ebben a példában a www a fõgép egyik - álneve, amely itt a minta.org (192.168.1.1) tartomány. A CNAME - rekordok tehát álnevek megadására - használhatóak, vagy egyetlen - állománynév körkörös - rendszerû (round robin típusú) - feloldására több gép - között. + álneve, amely itt éppenséggel a minta.org (192.168.1.1) tartományneve. A + CNAME rekordok mellé más típusú + rekordokat ugyanarra a hálózati névre + soha ne adjunk meg. MX rekord - - IN MX 10 levelezes.minta.org. + IN MX 10 levelezes.minta.org. Az MX rekord adja meg, hogy milyen levelezõ szerverek felelõsek a zónába érkezõ levelek fogadásáért. A levelezes.minta.org a levelezõ szerver hálózati neve, ahol a 10 az adott levelezõ szerver prioritása. Több levelezõ szerver is megadható 10-es, 20-as stb. prioritásokkal. A minta.org tartományon belül elõször mindig a legnagyobb MX prioritással rendelkezõ levelezõ szervernek próbáljuk meg továbbítani a leveleket (a legkisebb prioritási értékkel rendelkezõ rekord), majd ezután a második legnagyobbnak stb. egészen addig, amíg a levelet tovább nem küldtük. Az in-addr.arpa zóna állományok (inverz DNS) esetén ugyanez a felépítés, kivéve, hogy a PTR típusú bejegyzések szerepelnek az A és CNAME helyett. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.minta.org. admin.minta.org. ( 2006051501 ; sorozatszám 10800 ; frissítés 3600 ; ismétlés 604800 ; lejárat - 3600 ) ; minimum + 300 ) ; TTL negatív válasz IN NS ns1.minta.org. IN NS ns2.minta.org. 1 IN PTR minta.org. 2 IN PTR ns1.minta.org. 3 IN PTR ns2.minta.org. 4 IN PTR mx.minta.org. 5 IN PTR levelezes.minta.org. Ez az állomány írja le tehát a kitalált tartományunkon belül az IP-címek és hálózati nevek összerendelését. + Érdemes megemlíteni, hogy a PTR rekordok + jobb oldalán álló nevek + mindegyikének teljes hálózati + névnek kell lennie (vagyis . karakterrel + kell végzõdnie). A gyorsítótárazó névszerver BIND gyorsítótárazó névszerver A gyorsítótárazó - névszerver az a névszerver, amelyik egyik - zónában sem hitelesített. Egyszerûen - csak öncélú kéréseket - küld, és a kapott válaszokat megjegyzi. A - beállításához mindössze annyit - kell tennünk, hogy az eddigiekhez hasonlóan, de - zónák nélkül beállítunk - egy névszervert. - + névszerver az a névszerver, amely elsõdleges + feladata a rekurzív kérések + kiszolgálása. Egyszerûen + továbbítja a beérkezõ + kéréseket, majd megjegyzi azokat, így + késõbb közvetlenül tud + válaszolni. Biztonság Habár a névfeloldás szempontjából a BIND a legelterjedtebb, a biztonságosságával azért akadnak gondok. Gyakran találnak benne potenciális és kihasználható biztonsági réseket. A &os; azonban a named démont automatikusan egy &man.chroot.8; környezetbe helyezi. Emellett még léteznek további más védelmi mechanizmusok is, amelyek segítségével el tudjuk kerülni a névfeloldást célzó esetleges támadásokat. Sosem árt olvasgatni a CERT által kiadott biztonsági figyelmeztetéseket és feliratkozni a &a.security-notifications; címére, hogy folyamatosan értesüljünk az interneten és a &os;-ben talált különbözõ biztonsági hibákról. Ha valamilyen gondunk támadna, akkor esetleg próbálkozzunk meg a forrásaink frissítésével és a named újrafordításával. Egyéb olvasnivalók A BIND/named man oldalai: &man.rndc.8; &man.named.8; &man.named.conf.5; - Az ISC + Az ISC BIND hivatalos honlapja (angolul) - Az ISC BIND + Az ISC BIND hivatalos fóruma (angolul) - A BIND9 GYIK (angolul) - - - - O'Reilly DNS and + url="http://www.oreilly.com/catalog/dns5/">O'Reilly DNS and BIND 5th Edition RFC1034 - + url="http://www.rfc-editor.org/rfc/rfc1034.txt">RFC1034 - Domain Names - Concepts and Facilities RFC1035 - + url="http://www.rfc-editor.org/rfc/rfc1035.txt">RFC1035 - Domain Names - Implementation and Specification - Murray Stokely Készítette: Az Apache webszerver webszerverek beállítása Apache Áttekintés A &os; szolgálja ki a legforgalmasabb honlapok nagy részét szerte a világban. A mögöttük álló webszerverek általában az Apache webszervert alkalmazzák. Az Apache használatához szükséges csomagok megtalálhatóak a &os; telepítõlemezén is. Ha a &os; elsõ telepítésekor még nem telepítettük volna az Apache szerverét, akkor a www/apache13 vagy www/apache12 portból tudjuk feltenni. Az Apache szervert sikeres telepítését követõen be kell állítanunk. Ebben a szakaszban az Apache webszerver 1.3.X változatát mutatjuk be, mivel ezt használják a legtöbben &os; alatt. Az Apache 2.X rengeteg új technológiát vezetett be, de ezekkel itt most nem foglalkozunk. Az Apache 2.X változatával kapcsolatban keressük fel a oldalt. Beállítás Apache konfigurációs állományok Az Apache webszerver konfigurációs állománya &os; alatt /usr/local/etc/apache/httpd.conf néven található. Ez az állomány egy szokványos &unix;-os szöveges konfigurációs állomány, ahol a megjegyzéseket egy # karakterrel vezetjük be. Az itt használható összes lehetséges beállítási lehetõség átfogó ismertetése meghaladná az egész kézikönyv határait, ezért most csak a leggyakrabban módosított direktívákat fogjuk ismertetni. ServerRoot "/usr/local" Ez adja meg az Apache számára az alapértelmezett könyvtárat. A binárisai ezen belül a bin és sbin alkönyvtárakban, a konfigurációs állományai pedig az etc/apache könyvtárban tárolódnak. ServerAdmin saját@címünk.az.interneten Erre a címre küldhetik nekünk a szerverrel kapcsolatos hibákat. Ez a cím egyes szerver által generált oldalakon jelenik meg, például hibák esetében. ServerName www.minta.com A ServerName segítségével meg tudjuk adni, hogy milyen nevet küldjön vissza a szerver a klienseknek olyankor, ha az nem egyezne meg a jelenlegivel (vagyis a www nevet használjuk a gépünk valódi neve helyett). DocumentRoot "/usr/local/www/data" A DocumentRoot adja meg azt a könyvtárat, ahonnan kiszolgáljuk a dokumentumokat. Alapértelmezés szerint az összes kérés erre a könyvtárra fog vonatkozni, de a szimbolikus linkek és az álnevek akár más helyekre is mutathatnak. A változtatások végrehajtása elõtt mindig is jó ötlet biztonsági másolatot készíteni az Apache konfigurációs állományairól. Ahogy sikerült összerakni egy számunkra megfelelõ konfigurációt, készen is állunk az Apache futtatására. Az <application>Apache</application> futtatása Apache indítása és leállítása A többi hálózati szervertõl eltérõen az Apache nem az inetd szuperszerverbõl fut. A kliensektõl érkezõ HTTP kérések minél gyorsabb kiszolgálásának érdekében úgy állítottuk be, hogy önállóan fusson. Ehhez egy szkriptet is mellékeltünk, amellyel igyekeztünk a lehetõ legjobban leegyszerûsíteni a szerver indítását, leállítását és újraindítását. Az Apache elsõ indításához adjuk ki a következõ parancsot: &prompt.root; /usr/local/sbin/apachectl start Így pedig a szervert bármikor leállíthatjuk: &prompt.root; /usr/local/sbin/apachectl stop Ha valamilyen okból megváltoztattuk volna a szerver beállításait, akkor ezen a módon tudjuk újraindítani: &prompt.root; /usr/local/sbin/apachectl restart Ha a jelenleg megnyitott kapcsolatok felbontása nélkül akarjuk újraindítani az Apache szervert, akkor ezt írjuk be: &prompt.root; /usr/local/sbin/apachectl graceful Mindezekrõl az &man.apachectl.8; man oldalon találunk bõvebb leírást. Amennyiben szükségünk lenne az Apache elindítására a rendszer indításakor, akkor a következõ sort vegyünk fel az /etc/rc.conf állományba: apache_enable="YES" Az Apache 2.2 esetében: apache22_enable="YES" Amikor az Apache httpd nevû programjának szeretnénk további paranccsori paramétereket átadni a rendszer indítása során, akkor ezeket így tudjuk megadni az rc.conf állományban: apache_flags="" Most, miután a webszerverünk mûködik, a böngészõnkkel mindezt ellenõrizni is tudjuk a http://localhost/ cím beírásával. Ilyenkor az alapértelmezés szerinti /usr/local/www/data/index.html állomány tartalmát láthatjuk. Virtuális nevek Az Apache a virtuális nevek használatának két különbözõ módját ismeri. Ezek közül az elsõ módszer a név alapú virtualizáció (Name-based Virtual Hosting). Ilyenkor a kliens HTTP/1.1 fejlécébõl próbálja meg a szerver megállapítani a hivatkozási nevet. Segítségével több tartomány is osztozhat egyetlen IP-címen. Az Apache név alapú virtualizációjának beállításához az alábbi beállítást kell hozzátennünk a httpd.conf állományhoz: NameVirtualHost * Ha a webszerverünk neve www.tartomany.hu, és hozzá egy www.valamilyenmasiktartomany.hu virtuális nevet akarunk megadni, akkor azt a következõképpen tehetjük meg a httpd.conf állományon belül: <VirtualHost *> ServerName www.tartomany.hu DocumentRoot /www/tartomany.hu </VirtualHost> <VirtualHost *> ServerName www.valamilyenmasiktartomany.hu DocumentRoot /www/valamilyenmasiktartomany.hu </VirtualHost> A címek és elérési utak helyére helyettesítsük be a használni kívánt címeket és elérési utakat. A virtuális nevek beállításának további részleteivel kapcsolatosan keressük fel az Apache hivatalos dokumentációját a címen (angolul). Apache-modulok Apache modulok Az alap szerver képességeinek kiegészítéséhez több különbözõ Apache modul áll rendelkezésünkre. A &os; Portgyûjteménye az Apache telepítése mellett lehetõséget ad a népszerûbb bõvítményeinek telepítésére is. mod_ssl webszerverek biztonság SSL titkosítás A mod_ssl modul az OpenSSL könyvtár használatával valósít meg erõs titkosítást a biztonságos socket réteg második, illetve harmadik verziójával (Secure Sockets Layer, SSL v2/v3) és a biztonságos szállítási rétegbeli (Transport Layer Security v1) protokoll segítségével. Ez a modul mindent biztosít ahhoz, hogy a megfelelõ hatóságok által aláírt tanúsítványokat tudjunk kérni, és ezáltal egy védett webszervert futtassunk &os;-n. Ha még nem telepítettünk volna fel az Apache szervert, akkor a www/apache13-modssl porton keresztül a mod_ssl modullal együtt is fel tudjuk rakni az Apache 1.3.X változatát. Az SSL támogatása pedig már az Apache 2.X www/apache22 porton keresztül elérhetõ változataiban alapértelmezés szerint engedélyezett. Kapcsolódás nyelvekhez Mindegyik nagyobb szkriptnyelvhez létezik egy külön Apache-modul, amelyek segítségével komplett Apache-modulokat tudunk készíteni az adott nyelven. Gyakran a dinamikus honlapok is így próbálják a szerverbe épített belsõ értelmezõn keresztül a külsõ értelmezõ indításából és benne a szkriptek lefuttatásából fakadó költségeket megspórolni, ahogy errõl a következõ szakaszokban olvashatunk. Dinamikus honlapok webszerverek dinamikus Az utóbbi évtizedben egyre több vállalkozás fordult az internet felé bevételeik és részesedéseinek növelésének reményében, amivel egyre jobban megnõtt az igény a dinamikus honlapokra is. Miközben bizonyos cégek, mint például a µsoft;, a saját fejlesztésû termékeikbe építettek be ehhez támogatást, addig a nyílt forrásokkal foglalkozó közösség sem maradt tétlen és felvette a kesztyût. A dinamikus tartalom létrehozásához többek közt Django, Ruby on Rails, a mod_perl és a mod_php modulok használhatóak. Django Python Django A Django egy BSD típusú licensszel rendelkezõ keretrendszer, amelynek használatával nagy teljesítményû és elegáns webes alkalmazásokat tudunk gyorsan kifejleszteni. Tartalmaz egy objektum-relációs leképezõt, így az adattípusokat Python-objektumokként tudjuk leírni, és ezekhez az objektumokhoz egy sokrétû, dinamikus adatbázis hozzáférést nyújtó alkalmazásfejlesztõi felületet, így a fejlesztõknek egyetlen SQL utasítást sem kell megírniuk. Találhatunk még benne továbbá egy bõvíthetõ sablonrendszert, amelynek köszönhetõen az alkalmazás belsõ mûködése elválasztható a HTML-beli megjelenésétõl. A Django mûködéséhez a mod_python modulra, az Apache szerverre és egy tetszõlegesen választott SQL alapú adatbázisrendszerre van szükség. A hozzátartozó &os; port mindezeket automatikusan telepíti a megadott beállítások szerint. A Django telepítése az Apache, mod_python3 és a PostgreSQL használatával &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL Miután a Django és a hozzá szükséges komponensek felkerültek rendszerünkre, hozzunk létre egy könyvtárat a leendõ Django projektünknek és állítsuk be az Apache szervert, hogy az oldalunk belül a megadott linkekre a saját alkalmazásunkat hívja meg a beágyazott Python-értelmezõn keresztül. Az Apache beállítása a Django és mod_python használatához A következõ sort kell hozzátennünk a httpd.conf állományhoz, hogy az Apache bizonyos linkeket a webes alkalmazás felé irányítson át: <Location "/"> SetHandler python-program PythonPath "['/a/django/csomagok/helye/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE azoldalam.beallitasai PythonAutoReload On PythonDebug On </Location> Ruby on Rails Ruby on Rails A Ruby on Rails egy olyan másik nyílt forráskódú keretrendszer, amivel lényegében egy teljes fejlesztõi készletet kapunk és amelyet kifejezetten arra élezték ki, hogy segítségével a webfejlesztõk sokkal gyorsabban tudjanak haladni és a komolyabb alkalmazások gyorsabb elkészítése se okozzon nekik gondot. A Portrgyûjteménybõl pillanatok alatt telepíthetõ. &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean mod_perl mod_perl Perl Az Apache és Perl egyesítésén fáradozó projekt a Perl programozási nyelv és az Apache webszerver erejének összehangolásán dolgozik. A mod_perl modulon keresztül Perlben vagyunk képesek modulokat készíteni az Apache szerverhez. Ráadásul a szerverben egy belsõ állandó értelmezõ is található hozzá, ezzel igyekeznek megspórolni a külsõ értelmezõ és a Perl indításából keletkezõ többletköltségeket. A mod_perl több különbözõ módon állítható munkába. A mod_perl használatához nem szabad elfelejtenünk, hogy a mod_perl 1.0-ás verziója csak az Apache 1.3 változatával mûködik, és a mod_perl 2.0-ás változata pedig csak az Apache 2.X változataival. A mod_perl 1.0 a www/mod_perl portból telepíthetõ, valamint a statikusan beépített változata a www/apache13-modperl portban található. A mod_perl 2.0 a www/mod_perl2 portból rakható fel. Tom Rhodes Írta: mod_php mod_php PHP A PHP, vagy másik nevén PHP, a hipertext feldolgozó egy általános célú szkriptnyelv, amelyet kifejezetten honlapok fejlesztéséhez hoztak létre. A szabványos HTML ágyazható nyelv felépítésében a C, &java; és Perl nyelveket ötvözi annak elérése érdekében, hogy ezzel segítse a fejlesztõket a dinamikusan generált oldalak minél gyorsabb megírásában. A PHP5 támogatását úgy tudjuk hozzáadni az Apache webszerverhez, ha telepítjük a lang/php5 portot. Ha a lang/php5 portot most telepítjük elõször, akkor a vele kapcsolatos beállításokat tartalmazó OPTIONS menü automatikusan megjelenik. Ha ezzel nem találkoznánk, mert például valamikor korábban már felraktuk volna a lang/php5 portot, akkor a port könyvtárában következõ parancs kiadásával tudjuk újra visszahozni: &prompt.root; make config A beállítások között jelöljük be az APACHE opciót, amelynek eredményeképpen létrejön az Apache webszerverhez használható mod_php5 betölthetõ modul. A PHP4 modult még ma is rengeteg szerver használja több különbözõ okból (például kompatibilitási problémák vagy a már korábban kiadott tartalom miatt). Ha tehát a mod_php5 helyett inkább a mod_php4 modulra lenne szükségünk, akkor a lang/php4 portot használjuk. A lang/php4 portnál is megtalálhatjuk a lang/php5 fordítási idejû beállításainak nagy részét. Az iméntiek révén települnek és beállítódnak a dinamikus PHP alkalmazások támogatásához szükséges mouldok. Az /usr/local/etc/apache/httpd.conf állományban ellenõrizni is tudjuk, hogy az alábbi részek megjelentek-e: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Ahogy befejezõdött a mûvelet, a PHP modul betöltéséhez mindösszesen az apachectl paranccsal kell óvatosan újraindítanunk a webszervert: &prompt.root; apachectl graceful A PHP jövõbeni frissítéseihez már nem lesz szükségünk a make config parancsra, mivel a korábban kiválasztott OPTIONS menün belüli beállítasainkat a &os; Portgyûjteményéhez tartozó keretrendszer automatikusan elmenti. A PHP &os;-ben megtalálható támogatása kifejezetten moduláris, ezért az alap telepítése igencsak korlátozott. A további elemek hozzáadásához a lang/php5-extensions portot tudjuk használni. A port egy menüvezérelt felületet nyújt a PHP különbözõ bõvítményeinek telepítéséhez. Az egyes bõvítményeket azonban a megfelelõ portok használatával is fel tudjuk rakni. Például PHP5 modulhoz úgy tudunk támogatást adni a MySQL adatbázis szerverhez, ha feltelepítjük a databases/php5-mysql portot. Miután telepítettünk egy bõvítményt, az Apache szerverrel újra be kell töltetnünk a megváltozott beállításokat: &prompt.root; apachectl graceful Murray Stokely Készítette: Állományok átvitele (FTP) FTP szerverek Áttekintés Az adatállomány átviteli protokoll (File Transfer Protocol, FTP) a felhasználók számára lehetõséget ad az ún. FTP szerverekre állományokat feltölteni, illetve onnan állományokat letölteni. A &os; alaprendszere is tartalmaz egy ilyen FTP szerverprogramot, ftpd néven. Ezért &os; alatt egy FTP szerver beállítása meglehetõsen egyszerû. Beállítás A beállítás legfontosabb lépése, hogy eldöntsük milyen hozzáféréseken át lehet elérni az FTP szervert. Egy hétköznapi &os; rendszerben rengeteg hozzáférés a különbözõ démonokhoz tartozik, de az ismeretlen felhasználók számára nem kellene megengednünk ezek használatát. Az /etc/ftpusers állományban szerepelnek azok a felhasználók, akik semmilyen módon nem érhetik el az FTP szolgáltatást. Alapértelmezés szerint itt találhatjuk az elõbb említett rendszerszintû hozzáféréseket is, de ide minden további nélkül felvehetjük azokat a felhasználókat, akiknél nem akarjuk engedni az FTP elérését. Más esetekben elõfordulhat, hogy csak korlátozni akarjuk egyes felhasználók FTP elérését. Ezt az /etc/ftpchroot állományon keresztül tehetjük meg. Ebben az állományban a lekorlátozni kívánt felhasználókat és csoportokat írhatjuk bele. Az &man.ftpchroot.5; man oldalán olvashatjuk el ennek részleteit, ezért ennek pontos részleteit itt most nem tárgyaljuk. FTP anonim Ha az FTP szerverünkhöz névtelen (anonim) hozzáférést is engedélyezni akarunk, akkor ahhoz elõször készítenünk kell egy ftp nevû felhasználót a &os; rendszerünkben. A felhasználók ezután az ftp vagy anonymous nevek, valamint egy tetszõleges jelszó (ez a hagyományok szerint a felhasználó e-mail címe) használatával is képesek lesznek bejelentkezni. Az FTP szerver ezután a névtelen felhasználók esetében meghívja a &man.chroot.2; rendszerhívást, és ezzel lekorlátozza hozzáférésüket az ftp felhasználó könyvtárára. Két szöveges állományban adhatunk meg a becsatlakozó FTP kliensek számára üdvözlõ üzeneteket. Az /etc/ftpwelcome állomány tartalmát még a bejelentkezés elõtt látni fogják a felhasználók, a sikeres bejelentkezést követõen pedig az /etc/ftpmotd állomány tartalmát látják. Vigyázzunk, mert ennek az állománynak már a bejelentkezési környezethez képest relatív az elérése, ezért a névtelen felhasználók esetében ez konkrétan az ~ftp/etc/ftpmotd állomány lesz. Ahogy beállítottuk az FTP szervert, az /etc/inetd.conf állományban is engedélyeznünk kell. Itt mindössze annyira lesz szükségünk, hogy eltávolítsuk a megjegyzést jelzõ # karaktert a már meglevõ ftpd sor elõl: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Ahogy arról már a szót ejtett, az inetd beállításait újra be kell olvastatunk a konfigurációs állomány megváltoztatása után. A írja le az inetd engedélyezésének részleteit. Az ftpd önálló szerverként is elindítható. Ehhez mindössze elegendõ csak a megfelelõ változót beállítani az /etc/rc.conf állományban: ftpd_enable="YES" Miután megadtuk az iménti változót, a szerver el fog indulni a rendszer következõ indítása során. Szükség esetén természetesen root felhasználóként a következõ paranccsal is közvetlenül elindítható: &prompt.root; /etc/rc.d/ftpd start Most már be is tudunk jelentkezni az FTP szerverre: &prompt.user; ftp localhost Karbantartás syslog naplóállományok FTP Az ftpd démon a &man.syslog.3; használatával naplózza az üzeneteket. Alapértelmezés szerint a rendszernaplózó démon az FTP mûködésére vonatkozó üzeneteket az /var/log/xferlog állományba írja. Az FTP naplóinak helyét az /etc/syslog.conf állományban tudjuk módosítani: ftp.info /var/log/xferlog FTP anonim Legyünk körültekintõek a névtelen FTP szerverek üzemeltetésekor. Azt pedig kétszer is gondoljuk meg, hogy engedélyezzük-e a névtelen felhasználók számára állományok feltöltését, hiszen könnyen azon kaphatjuk magunkat, hogy az FTP oldalunk illegális állománycserék színterévé válik vagy esetleg valami sokkal rosszabb történik. Ha mindenképpen szükségünk lenne erre a lehetõségre, akkor állítsunk be olyan engedélyeket a feltöltött állományokra, hogy a többi névtelen felhasználó ezeket a tartalmuk tüzetes ellenõrzéséig ne is olvashassa. Murray Stokely Készítette: Állomány- és nyomtatási szolgáltatások µsoft.windows; kliensek számára (Samba) Samba szerver Microsoft Windows állományszerver windowszos kliensek nyomtatószerver windowszos kliensek Áttekintés A Samba egy olyan elterjedt nyílt forráskódú szoftver, ami µsoft.windows; kliensek számára tesz lehetõvé állomány- és nyomtatási szolgáltatásokat. Az ilyen kliensek általa helyi meghajtóként képesek elérni a &os; állományrendszerét, vagy helyi nyomtatóként a &os; általt kezelt nyomtatókat. A Samba csomagja általában megtalálható a &os; telepítõeszközén. Ha a &os;-vel együtt nem raktuk fel a Samba csomagját, akkor ezt késõbb net/samba3 port vagy csomag telepítésével pótolhatjuk. Beállítás A Samba konfigurációs állománya a telepítés után /usr/local/share/examples/samba/smb.conf.default néven található meg. Ezt kell lemásolnunk /usr/local/etc/smb.conf néven, amelyet aztán a Samba tényleges használata elõtt módosítanunk kell. Az smb.conf állomány a Samba futásához használt beállításokat tartalmazza, mint például &windows; kliensek számára felkínált a nyomtatók és megosztások adatait. A Samba csomagban ezen kívül találhatunk még egy swat nevû webes eszközt, amellyel egyszerû módon tudjuk az smb.conf állományt állítgatni. A Samba webes adminisztrációs eszköze (SWAT) A Samba webes adminisztrációs segédeszköze (Samba Web Administration Tool, SWAT) az inetd démonon keresztül fut démonként. Ennek megfelelõn az /etc/inetd.conf állományban a következõ sort kell kivennünk megjegyzésbõl, mielõtt a swat segítségével megkezdenénk a Samba beállítását: swat stream tcp nowait/400 root /usr/local/sbin/swat swat Ahogy azt a is mutatja, az inetd démont újra kell indítanunk a megváltozott konfigurációs állományának újbóli beolvasásához. Miután az inetd.conf állományban a swat engedélyezésre került, a böngészõnk segítségével próbáljunk meg a címre csatlakozni. Elõször a rendszer root hozzáférésével kell bejelentkeznünk. Miután sikeresen bejelentkeztünk a Samba beállításait tárgyaló lapra, el tudjuk olvasni a rendszer dokumentációját, vagy a Globals fülre kattintva nekiláthatunk a beállítások elvégzésének. A Globals részben található opciók az /usr/local/etc/smb.conf állomány [global] szekciójában található változókat tükrözik. Általános beállítások Akár a swat eszközzel, akár a /usr/local/etc/smb.conf közvetlen módosításával dolgozunk, a Samba beállítása során a következõkkel mindenképpen össze fogunk futni: workgroup A szervert elérni kívánó számítógépek által használt NT tartomány vagy munkacsoport neve. netbios name NetBIOS A Samba szerver NetBIOS neve. Alapértelmezés szerint ez a név a gép hálózati nevének elsõ tagja. server string Ez a szöveg jelenik meg akkor, ha például a net view paranccsal vagy valamilyen más hálózati segédprogrammal kérdezzük le a szerver beszédesebb leírását. Biztonsági beállítások A /usr/local/etc/smb.conf állományban a két legfontosabb beállítás a választott biztonsági modell és a kliensek felhasználói jelszavainak tárolásához használt formátum. Az alábbi direktívák vezérlik ezeket: security Itt a két leggyakoribb beállítás a security = share és a security = user. Ha a kliensek a &os; gépen található felhasználói neveiket használják, akkor felhasználói szintû védelemre van szükségünk (tehát a user beállításra). Ez az alapértelmezett biztonsági házirend és ilyenkor a klienseknek elõször be kell jelentkezniük a megosztott erõforrások eléréséhez. A megosztás (share) szintû védelem esetében, a klienseknek nem kell a szerveren érvényes felhasználói névvel és jelszóval rendelkezniük a megosztott erõforrások eléréséhez. Ez volt az alapbeállítás a Samba korábbi változataiban. passdb backend NIS+ LDAP SQL adatbázis A Samba számos különbözõ hitelesítési modellt ismer. A klienseket LDAP, NIS+, SQL adatbázis vagy esetleg egy módosított jelszó állománnyal is tudjuk hitelesíteni. Az alapértelmezett hitelesítési módszer a smbpasswd, így itt most ezzel foglalkozunk. Ha feltesszük, hogy az alapértelmezett smbpasswd formátumot választottuk, akkor a Samba úgy fogja tudni hitelesíteni a klienseket, ha elõtte létrehozzuk a /usr/local/private/smbpasswd állományt. Ha a &windows;-os kliensekkel is el akarjuk érni a &unix;-os felhasználói hozzáféréseinket, akkor használjuk a következõ parancsot: &prompt.root; smbpasswd -a felhasználónév A Samba a 3.0.23c verziójától kezdõdõen a hitelesítéshez szükséges állományokat a /usr/local/etc/samba könyvtárban tárolja. A felhasználói hozzáférések hozzáadására innentõl már a tdbsam parancs használata javasolt: &prompt.root; pdbedit felhasználónév A hivatalos Samba HOGYAN ezekrõl a beállításokról szolgál további információkkal (angolul). Viszont az itt vázolt alapok viszont már elegendõek a Samba elindításához. A <application>Samba</application> elindítása A net/samba3 port a Samba irányítására egy új indító szkriptet tartalmaz. A szkript engedélyezéséhez, tehát általa a Samba elindításának, leállításának és újraindításának lehetõvé tételéhez vegyük fel a következõ sort az /etc/rc.conf állományba: samba_enable="YES" Ha még finomabb irányításra vágyunk: nmbd_enable="YES" smbd_enable="YES" Ezzel egyben a rendszer indításakor automatikusan be is indítjuk a Samba szolgáltatást. A Samba a következõkkel bármikor elindítható: &prompt.root; /usr/local/etc/rc.d/samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Az rc szkriptekkel kapcsolatban a t ajánljuk elolvasásra. A Samba jelen pillanatban három különálló démonból áll. Láthatjuk is, hogy az nmbd és smbd démonokat elindította a samba szkript. Ha az smb.conf állományban engedélyeztük a winbind névfeloldási szolgáltatást is, akkor láthatjuk, hogy ilyenkor a winbindd démon is elindul. A Samba így állítható le akármikor: &prompt.root; /usr/local/etc/rc.d/samba stop A Samba egy összetett szoftvercsomag, amely a µsoft.windows; hálózatokkal kapcsolatos széles körû együttmûködést tesz lehetõvé. Az általa felkínált alapvetõ lehetõségeken túl a többit a honlapon ismerhetjük meg (angolul). Tom Hukins Készítette: Az órák egyeztetése az NTP használatával NTP Áttekintés Idõvel a számítógép órája hajlamos elmászni. A hálózati idõ protokoll (Network Time Protocol, NTP) az egyik módja az óránk pontosan tartásának. Rengeteg internetes szolgáltatás elvárja vagy éppen elõnyben részesíti a számítógép órájának pontosságát. Például egy webszervertõl megkérdezhetik, hogy egy állományt adott ideje módosítottak-e. A helyi hálózatban az egyazon állományszerveren megosztott állományok ellentmondásmentes dátumozása érdekében szinte elengedhetetlen az órák szinkronizálása. Az olyan szolgáltatások, mint a &man.cron.8; is komolyan építkeznek a pontosan járó rendszerórára, amikor egy adott pillanatban kell lefuttatniuk parancsokat. NTP ntpd A &os; alapból az &man.ntpd.8; NTP szervert tartalmazza, amellyel más NTP szerverek segítségével tudjuk beállítani gépünk óráját, vagy éppen idõvel kapcsolatos információkat szolgáltatni másoknak. A megfelelõ NTP szerverek kiválasztása NTP a szerverek kiválasztása Az óránk egyeztetéséhez egy vagy több NTP szerverre lesz szükségünk. Elõfordulhat, hogy a hálózati rendszergazdánk vagy az internet-szolgáltatónk már beállított egy ilyen szervert erre a célra. Ezzel kapcsolatban olvassuk el a megfelelõ leírásokat. A nyilvánosan elérhetõ NTP szerverekrõl készült egy lista, ahonnan könnyedén ki tudjuk keresni a számunkra leginkább megfelelõ (hozzánk legközelebbi) szervert. Ne hagyjuk figyelmen kívül a szerverre vonatkozó házirendet és kérjünk engedélyt a használatához, amennyiben ez szükséges. Több, egymással közvetlen kapcsolatban nem álló NTP szerver választásával járunk jól, ha netalán az egyikük váratlanul elérhetetlenné vagy az órája pontatlanná válna. Az &man.ntpd.8; a visszakapott válaszokat intelligensen használja fel, mivel esetükben a megbízható szervereket részesíti elõnyben. A gépünk beállítása NTP beállítása Alapvetõ beállítások ntpdate Ha a számítógépünk indításakor akarjuk egyeztetni az óránkat, akkor erre az &man.ntpdate.8; nevû programot használhatjuk. Ez olyan asztali gépek számára megfelelõ választás, amelyeket gyakran indítanak újra és csak idõnként kell szinkronizálnunk. A legtöbb gépnek viszont az &man.ntpd.8; használatára van szüksége. Az &man.ntpdate.8; elindítása olyan esetekben is hasznos, ahol az &man.ntpd.8; is fut. Az &man.ntpd.8; az órát fokozatosan állítja, ellenben az &man.ntpdate.8; az eltérés mértékétõl és irányától függetlenül egyszerûen átállítja a gép óráját a pontos idõre. Az &man.ntpdate.8; elindítását úgy tudjuk engedélyezni a rendszer indításakor, ha az /etc/rc.conf állományba berakjuk az ntpdate_enable="YES" sort. Emellett még ntpdate_flags változóban meg kell adnunk az alkalmazott beállítások mellett azokat a szervereket, amelyekkel szinkronizálni akarunk. NTP ntp.conf Általános beállítások Az NTP az /etc/ntp.conf állományon keresztül állítható, amelyek felépítését az &man.ntp.conf.5; man oldal tárgyalja. Íme erre egy egyszerû példa: server ntplocal.minta.com prefer server timeserver.minta.org server ntp2a.minta.net driftfile /var/db/ntp.drift A server beállítás adja meg az egyeztetéshez használt szervereket, soronként egyet. Ha egy szerver mellett szerepel még a prefer paraméter is, ahogy azt a példában a ntplocal.minta.com mellett láthattuk, akkor a többivel szemben azt a szervert fogjuk elõnyben részesíteni. Az így kiemelt szervertõl érkezõ választ abban az esetben viszont eldobjuk, hogy a többi szervertõl kapott válasz jelentõs mértékben eltér tõle. Minden más esetben a õ válasza lesz a mérvadó. A prefer paramétert általában olyan NTP szerverekhez használják, amelyek közismerten nagy pontosságúak, tehát például külön erre a célra szánt felügyeleti eszközt is tartalmaznak. A driftfile beállítással azt az állományt adjuk meg, amiben a rendszeróra frekvencia eltolódásait tároljuk. Az &man.ntpd.8; program ezzel ellensúlyozza automatikusan az óra természetes elmászását, ezáltal lehetõvé téve, hogy egy viszonylag pontos idõt kapjuk még abban az esetben is, amikor egy kis idõre külsõ idõforrások nélkül maradnánk. A driftfile beállítással egyben azt az állományt jelöljük ki, amely az NTP szervertõl kapott korábbi válaszokat tárolja. Ez az NTP mûködéséhez szükséges belsõ adatokat tartalmaz, ezért semmilyen más programnak nem szabad módosítania. A szerverünk elérésének szabályozása Alapértelmezés szerint az NTP szerverünket bárki képes elérni az interneten. Az /etc/ntp.conf állományban szereplõ restrict beállítás segítségével azonban meg tudjuk mondani, milyen gépek érhetik el a szerverünket. Ha az NTP szerverünk felé mindenféle próbálkozást el akarunk utasítani, akkor az /etc/ntp.conf állományba a következõ sort kell felvennünk: restrict default ignore Ezzel egyben azonban a helyi beállításainkban szereplõ szerverek elérését is megakadályozzuk. Ha külsõ NTP szerverekkel is szeretnénk szinkronizálni, akkor itt is engedélyezünk kell ezeket. Errõl bõvebben lásd az &man.ntp.conf.5; man oldalon. Ha csak a belsõ hálózatunkban levõ gépek számára szeretnénk elérhetõvé tenni az órák egyeztetését, de sem a szerver állapotának módosítását nem engedélyezzük, sem pedig azt, hogy a vele egyenrangú szerverekkel szinkronizáljon, akkor az iménti helyett a restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap sort írjuk bele, ahol a 192.168.1.0 a belsõ hálózatunk IP-címe és a 255.255.255.0 a hozzátartozó hálózati maszk. Az /etc/ntp.conf több restrict típusú beállítást is tartalmazhat. Ennek részleteirõl az &man.ntp.conf.5; man oldalon, az Access Control Support címû szakaszban olvashatunk. Az NTP futtatása Úgy tudjuk az NTP szervert elindítani a rendszerünkkel együtt, ha az /etc/rc.conf állományban szerepeltetjük az ntpd_enable="YES" sort. Ha az &man.ntpd.8; számára további beállításokat is át akarunk adni, akkor az /etc/rc.conf állományban adjuk meg az ntpd_flags paramétert. Ha a gépünk újraindítása nélkül akarjuk elindítani a szerver, akkor az ntpd parancsot adjuk ki az /etc/rc.conf állományban a ntpd_flags változóhoz megadott paraméterekkel. Mint például: &prompt.root; ntpd -p /var/run/ntpd.pid Az ntpd használati idõleges internet csatlakozással Az &man.ntpd.8; program megfelelõ mûködéséhez nem szükséges állandó internet kapcsolat. Ha azonban igény szerinti tárcsázással építjünk fel ideiglenes kapcsolatot, akkor érdemes letiltani az NTP forgalmát, nehogy feleslegesen aktiválja vagy tartsa életben a vonalat. Ha PPP típusú kapcsolatunk van, akkor az /etc/ppp/ppp.conf állományban a filter direktívával tudjuk ezt leszabályozni. Például: set filter dial 0 deny udp src eq 123 # Nem engedjük az NTP által küldött adatoknak, hogy tárcsázást # kezdeményezzenek: set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Nem engedjük az NTP adatainak, hogy fenntartsák a kapcsolatot: set filter alive 1 deny udp dst eq 123 set filter alive 2 permit 0/0 0/0 Mindenezekrõl részletesebb felvilágosítást a &man.ppp.8; man oldal PACKET FILTERING címû szakaszában és a /usr/share/examples/ppp/ könyvtárban található példákban kaphatunk. Egyes internet-szolgáltatók blokkolják az alacsonyabb portokat, ezáltal az NTP nem használható, mivel a válaszok nem fogják elérni a gépünket. További olvasnivalók Az NTP szerver dokumentációja HTML formátumban a /usr/share/doc/ntp/ könyvtárban található. Tom Rhodes Készítette: Távoli gépek naplózása <command>syslogd</command> használatával A rendszernaplókkal kapcsolatos mûveletek egyaránt fontosak a biztonság és a karbantartás szempontjából. Ha közepes vagy nagyobb méretû, esetleg különbözõ típusú hálózatokban adminisztrálunk több gépet, akkor könnyen átláthatatlanná válhat a naplók rendszeres felügyelete. Ilyen helyzetekben a távoli naplózás beállításával az egész folyamatot sokkal kényelmesebbé tehetjük. Némileg képesek vagyunk enyhíteni a naplóállományok kezelésének terhét, ha egyetlen központi szerverre küldjük át az adatokat. Ekkor a &os; alaprendszerében megtalálható alapeszközökkel, mint például a &man.syslogd.8; vagy a &man.newsyslog.8; felhasználásával egyetlen helyen be tudjuk állítani a naplók összegyûjtését, összefésülését és cseréjét. A most következõ példa konfigurációban az A gép, a naploszerver.minta.com fogja gyûjteni a helyi hálózatról érkezõ naplóinformációkat. A B gép, a naplokliens.minta.com pedig a szervernek küldi a naplózandó adatokat. Éles környezetben mind a két gépnek rendelkeznie kell megfelelõ DNS bejegyzésekkel, vagy legalább szerepelniük kell egymás /etc/hosts állományaiban. Ha ezt elmulasztjuk, a szerver nem lesz hajlandó adatokat fogadni. A naplószerver beállítása A naplószerverek olyan gépek, amelyeket úgy állítottunk be, hogy naplózási információkat tudjanak fogadni távoli számítógépekrõl. A legtöbb esetben így egyszerûsíteni tudunk a konfiguráción, vagy olykor egyszerûen csak hasznos, ha ezt a megoldást alkalmazzuk. Függetlenül attól, hogy miért használjuk, a továbblépés elõtt néhány elõkészületet meg kell tennünk. Egy rendesen beállított naplószervernek legalább a következõ követelményeknek kell eleget tennie: az 514-es UDP portot engedélyezni kell mind a kliensen, mind pedig a szerveren futó tûzfal szabályrendszerében; a &man.syslogd.8; képes legyen a távoli kliens gépekrõl érkezõ üzeneteket fogadni; a &man.syslogd.8; szervernek és az összes kliensnek rendelkeznie kell érvényes DNS (közvetlen és inverz) bejegyzésekkel vagy szerepelnie kell az /etc/hosts állományban. A naplószerver beállításához mindegyik klienst fel kell vennünk az /etc/syslog.conf állományba, valamint meg kell adnunk a megfelelõ funkciót (facility): +naplokliens.minta.com *.* /var/log/naplokliens.log A &man.syslog.conf.5; man oldalán megtalálhatjuk a különbözõ támogatott és elérhetõ funkciókat. Miután beállítottuk, az összes adott funkcióhoz tartozó üzenet az elõbb megadott állományba (/var/log/naplokliens.log) fog kerülni. A szerveren továbbá meg kell adnunk a következõ sort az /etc/rc.conf állományban: syslogd_enable="YES" syslogd_flags="-a naplokliens.minta.com -vv" Az elsõ sorral engedélyezzük a syslogd elindítását a rendszerindítás során, majd a második sorral engedélyezzük, hogy a kliens naplózni tudjon a szerverre. Itt még látható a opció, amellyel a naplózott üzenetek részletességét tudjuk növelni. Ennek nagyon fontos a szerepe a naplózási funkciók behangolásakor, mivel így a rendszergazdák pontosan láthatják milyen típusú üzenetek milyen funkcióval kerültek rögzítésre a naplóban. Befejezésképpen hozzuk létre a naplóállományt. Teljesen mindegy, hogy erre milyen megoldást alkalmazunk, például a &man.touch.1; remekül megfelel: &prompt.root; touch /var/log/naplokliens.log Ezután indítsuk újra és ellenõrizzük a syslogd démont: &prompt.root; /etc/rc.d/syslogd restart &prompt.root; pgrep syslog Ha válaszul megkapjuk a futó démon azonosítóját, akkor sikerült újraindítanunk, elkezdhetjük a kliens beállítását. Ha valamiért nem indult volna újra a szerver, az /var/log/messages állományból próbáljuk meg kideríteni az okát. A naplókliens beállítása A naplókliens az a gép, amely egy helyi naplópéldány karbantartása mellett továbbküldni a naplózandó információkat egy naplószervernek. Hasonlóan a naplószerverekhez, a klienseknek is teljesítenie bizonyos alapvetõ elvárásokat: a &man.syslogd.8; démon küldjön bizonyos típusú üzeneteket a naplószervernek, amely ezeket pedig képes legyen fogadni; a hozzátartozó tûzfal engedje át a forgalmat az 514-es UDP porton; rendelkezzen mind közvetlen, mind pedig inverz DNS bejegyzéssel, vagy szerepeljenek az /etc/hosts állományban. A kliens beállítása sokkal egyszerûbb a szerverhez képest. A kliensen adjuk hozzá a következõ sorokat az /etc/rc.conf állományhoz: syslogd_enabled="YES" syslogd_flags="-s -vv" A szerver beállításaihoz hasonlóan itt is engedélyezzük a syslogd démont és megnöveljük a naplózott üzenetek részletességét. A kapcsolóval pedig megakadályozzuk, hogy a kliens más gépekrõl is hajlandó legyen naplóüzeneteket elfogadni. A funkciók a rendszernek azon részét írják le, amelyhez létrejön az adott üzenet. Tehát például az ftp és ipfw egyaránt ilyen funkciók. Amikor keletkezik egy naplóüzenet valamelyikükhöz, általában megjelenik a nevük. A funkciókhoz tartozik még egy prioritás vagy szint is, amellyel az adott üzenet fontosságát jelzik. Ezek közül a leggyakoribb a warning (mint figyelmeztetés) és info (mint információ). A használható funkciók és a hozzájuk tartozó prioritások teljes listáját a &man.syslog.3; man oldalán olvashatjuk. A naplószervert meg kell adnunk a kliens /etc/syslog.conf állományában. Itt a @ szimbólummal jelezzük, hogy az adatokat egy távoli szerverre szeretnénk továbbküldeni, valahogy így: *.* @naploszerver.minta.com Ezután a beállítás érvényesítéséhez újra kell indítanunk a syslogd démont: &prompt.root; /etc/rc.d/syslogd restart A &man.logger.1; használatával próbáljuk ki a kliensrõl a aplóüzenetek hálózaton keresztüli küldését, és küldjünk valamit a syslogd démonnak: &prompt.root; logger "Udvozlet a naplokliensrol" A parancs kiadása után az üzenetnek mind a kliens, mind pedig a szerver /var/log/messages állományában meg kell jelennie. Hibakeresés Elõfordulhat, hogy a naplószerver valamiért nem kapja meg rendesen az üzeneteket, ezért valamilyen módon meg kell keresnünk a hiba okát. Ez több minden lehet, de általában két leggyakoribb ok valamilyen hálózati kapcsolódási vagy DNS beállítási hiba. Ezek teszteléséhez gondoskodjunk róla, hogy a gépek kölcsönösen elérhetõek egymásról az /etc/rc.conf állományban megadott hálózati nevük szerint. Ha ezzel látszólag minden rendben van, akkor próbáljuk meg módosítani a syslogd_flags értékét az /etc/rc.conf állományban. A most következõ példában a /var/log/naplokliens.log teljesen üres, illetve a /var/log/messages állomány semmilyen hibára utaló okot nem tartalmaz. A hibakereséshez még több információt a syslogd_flags átírásával tudunk kérni: syslogd_flags="-d -a naploklien.minta.com -vv" Természetesen ne felejtsük el újraindítani a szervert: &prompt.root; /etc/rc.d/syslogd restart A démon újraindítása után közvetlenül az alábbiakhoz hasonló üzenetek árasztják el a képernyõt: logmsg: pri 56, flags 4, from naploszerver.minta.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from naploszerver.minta.com, msg syslogd: kernel boot file is /boot/kernel/kernel Logging to FILE /var/log/messages syslogd: kernel boot file is /boot/kernel/kernel cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name naplokliens.minta.com; rejected in rule 0 due to name mismatch. A diagnosztikai üzeneteket végigolvasva nyilvánvaló válik, hogy azért dobja el az üzeneteket a szerver, mert nem megfelelõ a gép neve. Miután átnézzük a beállításainkat, felfedezhetünk az /etc/rc.conf állományban egy apró hibát: syslogd_flags="-d -a naploklien.minta.com -vv" Láthatjuk, hogy ebben a sorban a naplokliens névnek kellene szerepelni, nem pedig a naploklien névnek. Miután elvégeztük a szükséges javításokat, indítsuk újra a szervert és vizsgáljuk meg az eredményt: &prompt.root; /etc/rc.d/syslogd restart logmsg: pri 56, flags 4, from naploszerver.minta.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from naploszerver.minta.com, msg syslogd: kernel boot file is /boot/kernel/kernel syslogd: kernel boot file is /boot/kernel/kernel logmsg: pri 166, flags 17, from naploszerver.minta.com, msg Dec 10 20:55:02 <syslog.err> naploszerver.minta.com syslogd: exiting on signal 2 cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name naplokliens.minta.com; accepted in rule 0. logmsg: pri 15, flags 0, from naplokliens.minta.com, msg Dec 11 02:01:28 pgj: Masodik teszt uzenet Logging to FILE /var/log/naplokliens.log Logging to FILE /var/log/messages Itt már minden üzenet rendben megérkezett és a megfelelõ állományokba került (a /var/log/messages a kliensen, és a /var/log/naplokliens.log a szerveren)). Biztonsági megfontolások Mint minden hálózati szolgáltatás esetén, ilyenkor is figyelembe kell vennünk bizonyos biztonsági megfontolásokat a tényleges konfiguráció kiépítése elõtt. Olykor elõfordulhat, hogy a naplók különbözõ kényes információkat tartalmaznak, mint például a helyi rendszeren futó szolgáltatások nevei, felhasználói nevek vagy egyéb konfigurációs adatok. A kliens és a szerver között hálózaton utazó adatok viszont se nem titkosítottak, se nem jelszóval védettek. Ha titkosítást szeretnénk használni, akkor javasoljuk például a security/stunnel portot, amellyel egy titkosított tunnelen keresztül tudunk adatokat küldeni a hálózaton. A helyi rendszer biztonságának szavatolása is fontos lehet. A naplók sem a használat során, sem pedig a lecserélésük után nem kerülnek titkosításra. Emiatt a helyi rendszerhez hozzáférõ felhasználók kedvükre nyerhetnek ki belõlük a rendszerünket érintõ konfigurációs információkat. Ezért ilyenkor nagyon fontos, hogy mindig a megfelelõ engedélyeket állítsuk be a naplókra. A &man.newsyslog.8; segédprogrammal be tudjuk állítani a frissen létrehozott és a lecserélt naplók engedélyeit. Tehát könnyen megakadályozhatjuk a helyi felhasználók kíváncsiskodását, ha itt a naplók engedélyeit például a 600 kóddal adjuk meg.