Egy elképzelt hálózat összeállítása a Debian GNU/Linux Etch verziójának segítségével

Átírás

1 Egy elképzelt hálózat összeállítása a Debian GNU/Linux Etch verziójának segítségével Kósa Attila konyv@mithrandir.hu március 23.

2 2 Debian GNU/Linux Szerkeszt Kósa Attila Szerz k Kósa Attila (1, 2.1, 2.2, 2.3, 2.4, 2.5, 3.1, 3.2, 4.1, 4.2, 4.3, 5.1, 5.2, 6.1, 7.1, 8.1, 10.1, 10.2, 11.1, 11.2, 12.1, 12.2, 12.3, 12.4, 13.1, 14 fejezetek) Lektorok Korn András (2.1 fejezet) Nemkin Róbert (2.1, 3.1 fejezetek) Pásztor György (2.1, 3.1 fejezetek) Javítást küld k A beküldés sorrendjében. Kolozs Sándor ( fejezet) Kondás János (2.2 fejezet) Bekény Bálint (5.2.5 fejezet) Csabka (6.1.2 fejezet) Biacsics Balázs (15.6 fejezet) Jelmagyarázat: d lt bet opciók neve; írógép típusú bet fájlok és könyvtárak neve; kis méret, írógép típusú bet kiadandó parancsok; kis méret, írógép típusú bet, bekeretezve kongurációs állományok, szkriptek. Kósa Attila <konyv@mithrandir.hu> március 23.

3 Debian GNU/Linux 3 Copyright c Kósa Attila E közlemény felhatalmazást ad önnek jelen dokumentum sokszorosítására, terjesztésére és/vagy módosítására a Szabad Szoftver Alapítvány által kiadott GNU Szabad Dokumentációs Licenc 1.1-es, vagy bármely azt követ verziójának feltételei alapján. A Nem Változtatható Szakaszok neve: Szerz k, El szó és Köszönetnyilvánítás, Címlap-szöveg a legels oldalon található szöveg, a Hátlap-szövegek neve pedig hátlapszöveg. E licenc egy példányát a GNU Szabad Dokumentációs Licenc elnevezés szakasz alatt találja március 23. Kósa Attila <konyv@mithrandir.hu>

4 4 Debian GNU/Linux Kósa Attila március 23.

5 Tartalomjegyzék El szó Köszönetnyilvánítás A terv DNS BIND BIND Adminisztrációs eszközök a BIND9 -hez A DNS tesztelésére használható eszközök A többi szerver DNS beállítása DHCP dhcp dhcp3-server Id szinkron ntp ntpdate Windows alatti NTP beállítások Biztonság SSL ssh LDAP OpenLDAP Fájlszerver SaMBa Levelek küldése Postx Levelek olvasása Dovecot Proxy Squid Automatikus proxybeállítás Web Apache HTTP-n Apache HTTPS-en Naplózás logcheck logrotate pogsumm syslog-ng Mentés Amanda Csomagsz rés

6 6 Debian GNU/Linux DNS NTP ICMP POP2, POP3, POP3S, IMAP, IMAPS SMTP UUCP AUTH FTP TFTP HTTP, HTTPS nger whois syslog r parancsok telnet SSH NNTP talk IRC SNMP NFS NIS/YP X SaMBa lpr T ZFAL DNS NTP ntpdate SMTP VPN Csomagsz rés GNU Licenc Tárgymutató Irodalomjegyzék Kósa Attila <konyv@mithrandir.hu> március 23.

7 El szó Azért kezdtem bele ennek a könyvnek a megírásába, mert ilyen összetett anyaggal még nem találkoztam, és reményeim szerint képes lesz betölteni az általam érzett rt. Természetesen soha nem mernék olyat állítani, hogy tökéletes lesz, inkább azt mondom, hogy igyekszem a legjobb tudásom szerint elmesélni, hogyan csinálnám én. Öszintén örülnék annak, ha sikerülne egy színvonalas anyagot átnyújtani a közönségnek, amelyb l a kételked k számára is nyilvánvalóvá válik, hogy a Linux igenis alkalmas a cégeknél felmerül problémák megoldására, a felhasználók minél teljesebb kör kiszolgálására. De egy percre se feledje senki, hogy ami ebben az anyagban megjelenik, az nem szentírás! Linux alatt mindenki megszokhatta, hogy egy problémának több megoldása is lehetséges, ezért felel tlenség lenne azt állítani, hogy az itt leírtak az üdvözít ek egyedül. Ugyanezen okból botorság lenne azt hinni, hogy minden megemlített szoftver minden lehet sége szóba kerül majd. Inkább egyfajta szakácskönyvként tekintsen az olvasó e m re, és a benne szerepl receptek alapján kedve szerint, ízlésének megfelel en f szerezzen. Debian-specikus az egész anyag (köszönhet en annak, hogy azt használok a napi munkámban), ami persze nem jelenti azt, hogy használhatatlan lenne más Linux disztribúciók használóinak. A leírás LATEX -ben készült, vim és dvips segítségével. A tesztelésre használt gépeket és hálózatot vmware server alatt állítottam össze. Köszönetnyilvánítás Újra köszönetet mondok Drótos Dániel nev f iskolai tanáromnak, hogy megismertetett a Linuxszal. Sokat köszönhetek Gál Tamás barátomnak, aki magánbeszélgetéseinken meger sítette azon meggy z désemet, hogy könyvet kell írnom, és tanácsaival átlendített a holtpontokon. Remélem, nem okozok neki csalódást... Nem gy zöm elégszer megköszönni a LATEX kezd knek és haladóknak cím könyv ([6]) szerz inek (Wettl Ferenc, Mayer Gyula és Sudár Csaba), hogy megírták csodálatos könyvüket, mely elindított a LATEX -hel való megismerkedés útján, valamint azóta kiadták LATEX kézikönyv cím könyvüket ([7] Wettl Ferenc, Mayer Gyula és Szabó Péter), amely a felmerült kérdéseim jó részére választ tudott adni. Meg kell emlékeznem és köszönetet kell mondanom az Irodalomjegyzékben található összes többi könyv, anyag szerz jér l, illetve szerz jének is, mert k is sokat segítettek a Linuxszal való ismerkedésben, valamint tudásom elmélyítésében. Köszönöm Korn Andrásnak, Nemkin Róbertnek és Pásztor Györgynek, hogy az anyag készítésének korai szakaszában támogattak ötleteikkel, és elvállalták az els fejezetek lektorálását, valamint sok id t eltöltöttek azzal, hogy meggy zzenek az igazukról. Köszönet illeti a kollégáimat Balsai Pétert és Váradi Gábort, akik elnézték nekem, hogy a közös szekér el remozdítása helyett ezen anyag elkészítésébe fektettem fölös energiáimat, valamint minden támogatást megadtak, amelyet megadhattak. 7

8 8 Debian GNU/Linux Köszönöm a Mithrandir Kft-nek a támogatást. Köszönöm Goreczky Rolandnak, Kecskeméti Lászlónak és Szél Miklósnak, hogy olyan sok id t áldoztak a html megjelenéssel kapcsolatos problémáim megoldására. Természetesen a családomnak feleségemnek, Marikának és két kisamnak, Attilának és Bálintnak tartozom a legtöbb köszönettel, hiszen k biztosították azt a hátteret, amely a nyugodt és eredményes munkához elengedhetetlen. Támogatás Az adományozás egy nagyszer módja, hogy kimutasd elismerésed és megbecsülésed, valamint ösztönözz a további munkára. Kérlek, hogy annyit még segíts, hogy az átutaláskor (bezetéskor) tüntesd fel, hogy mely rész volt számodra a leghasznosabb. Így lehet ségem nyílik annak felmérésére, hogy az anyag mely részére fordítsak több gyelmet, mit b vítsek, mir l írjak részletesebben. Természetesen -ben is elküldheted számomra ezen információkat. A támogatók nevei a weboldalon feltüntetésre kerülnek. Ha valamiért nem szeretnél ott megjelenni, akkor kérlek, jelezd ezt nekem a könyv elején található címen. Támogatók OTP bankos számlaszámom: Csak a weben elérhet változatban található meg a felsorolás. Kósa Attila <konyv@mithrandir.hu> március 23.

9 1. fejezet A terv El ször pár szót arról, hogy MIRŽL NEM SZÓL ez az anyag. Nem akarok a Debian telepítésének menetér l mesélni, feltételezem, hogy aki ebb l az anyagból akar protálni, az már túljutott a telepítés nehézségein, illetve elérhet ek az Interneten kifejezetten a Debian telepítésér l szóló anyagok. Nem írok részletesen arról, hogy egy-egy szolgáltatásra miért is van szükség a tervezett hálózatban, illetve nem szeretnék az ezekhez kapcsolódó elmélettel sem untatni senkit (bár valamennyit muszáj volt megemlítenem) akit érdekel, az rengeteg jó dokumentációt találhat az Interneten. Nem lesz szó tuningolásról, az egyes szolgáltatások memóriabeállításairól. Mégpedig azért nem, mert ezen opciók nagyon sok mindent l függenek, szinte lehetetlen megoldást mondani az egyes opciók értékére a körülmények pontos ismerete nélkül. Az egy gépen futó szolgáltatások, a sávszélesség, a felhasználók száma, a gépben lév memória mennyisége mind-mind olyan tényez 1, amely az egyes szolgáltatások beállítását befolyásolja. És most nézzük végre azt, hogy MIRŽL SZÓL a könyv. Kiválasztottam egy számomra szimpatikus hálózatot (egy C osztályút, a cím t), és ebben a hálózatban szeretnék különböz szolgáltatásokat beüzemelni. Az üzembeállításhoz szükséges feladatok leírása ezen anyag egyik célja. A szerverek Linuxot fognak futtatni, míg a munkaállomások windowsos gépek lesznek 2. Lehetséges, hogy egyszer az anyag el fogja érni azt a szintet, amikor linuxos munkaállomások hálózatba állításáról is szót fog ejteni, de ez egyel re csak nagyon távlati terv. Nem kötelez minden az anyagban szerepl szolgáltatást üzembe helyezni a saját hálózatunkban. Azért zsúfoltam bele talán feleslegesnek t n szolgáltatásokat (például másodlagos dns szerver), hogy a beállításával kapcsolatos dolgokat be tudjam mutatni. A fejezetek sorrendje nem az elkészítés sorrendjét határozza meg (bár van olyan, amit csak meghatározott sorrendben lehet végrehajtani, például tanúsítvány generálása el tt nem lehet a tanúsítványt használó LDAP szervert üzembe helyezni). Egyszer bbnek t nt, ha minden szolgáltatásról külön fejezet szól (még akkor is, ha maga a szolgáltatás több gépet is érint ekkor külön alfejezetben szólok a különböz gépek kongurációs igényeir l). De nézzük meg, hogy milyen szolgáltatásokat terveztem beüzemelni a hálózatban (picit részletesebb magyarázatot az egyes fejezetek elején találhat a Tisztelt Olvasó az egyes szolgáltatások szükségességér l): DNS (els dleges és másodlagos); DHCP (egyes gépekhez xen hozzárendelt IP címek); 1 A felsorolás nem teljes, számtalan egyéb dologtól is függhet az optimális beállítás. 2 A samba kivételével a többi szolgáltatás ugyanúgy m ködhetne linuxos hálózatban is, mint windowsos hálózatban (igazából a samba tisztán linuxos környezetben való m ködtetésének sincs akadálya). 9

10 10 Debian GNU/Linux SMTP (a bels hálózat levelezése, valamint az Internet felé irányuló levélforgalom); IMAPS (titkosított kapcsolaton keresztüli levélkezelés, miközben a levelek a szerveren tárolódnak); proxy (sávszélességünk védelme és egyéb megfontolások); fájltárolás (fájlok tárolása a szerveren); központi felhasználókezelés (egy jelszót minden szolgáltatáshoz, single sign on); naplózás (központi logszerver, logelemzések); backup (ha minden a szervereken van, akkor érdemes menteni); pontos id (például a titkosításokhoz szükséges, hogy azonosan járjanak a szerverek órái, de a logokban való keresgélést is megkönnyíti, ha az összes gép órája azonosan jár); bels webszerver (például nyilvános adatoknak); t zfal (védjük meg, amit összeraktunk). A gépek nevei és IP címei (a bels hálózatban példaként az akarmi.intra tartománynevet fogom használni) a következ k (ezeket az adatokat fogom felhasználni az egész anyagban, ezeknek megfelel en készülnek majd el a kongurációs állományok): a bels weboldalakat tároló szerver intraweb, ; a mentéseket végz szerver backup, ; a logszerver syslog, ; a fájlszerver samba, ; a proxyszerver proxy, ; a levelez szerver mail, ; a DNS-szerver dns, ; a t zfal bels hálózat felé néz lába fw, Nem lehet megszabni, hogy milyen szolgáltatásokat kell egy gépre összerakni, és melyeket muszáj más gépekre telepíteni. Ebben a kérdésben is csak az általam követett elveket tudom elmondani (plusz még néhány olyan dolgot, amelyet fontosnak tartok kiemelni): A DNS és DHCP szolgáltatást azért szoktam egy gépre tenni, mert hasonló adatokra van szükségük, és egyszer bb szkriptb l generálni a mindkét szolgáltatáshoz szükséges állományokat. Ez pedig nehézkes lenne (persze nem megoldhatatlan), ha külön gépen lennének. Természetesen lehetséges külön gépen futtatni ezeket az alkalmazásokat, és például cvs-b l venni a kongurációs állományokat. A DNS-ben (és egyúttal a DHCP-ben is) érdemes valamilyen rendszer szerint elkülöníteni pár dolgot. A szerverek, a hálózati nyomtatók, az aktív eszközök és a felhasználói gépek csoportosítását tartom én célszer nek. Egy lehetséges megoldás netmaszk határokon vágni, ez a kés bbi esetleges zikai szétválasztást is egyszer vé teszi. Természetesen bármilyen más felosztás is megoldást jelenthet, s t, ilyen jelleg felosztás nélkül is m köd képes a hálózat. Hasznos olvasmányok a döntéshez az rfc1519.txt ( org/rfc/rfc1519.txt) és az rfc1219.txt ( Kósa Attila <konyv@mithrandir.hu> március 23.

11 Debian GNU/Linux 11 Az IMAP-on történ levelezés meglehet sen sok feladatot ad a diszk-alrendszernek (sok egyidej felhasználó esetén), és a hálózati forgalma is nagy tud lenni. Emiatt nem célszer hasonlóan nagy hálózati forgalmat bonyolító szolgáltatásokkal egy gépre telepíteni, amilyen például a samba és a squid. A proxy (squid) is komolyan képes igénybevenni a diszk-alrendszert, emiatt célszer önmagában futtatni, illetve olyan diszkeket (vagy diszkelrendezést) választani, amelyek képesek megfelelni ennek a terhelésnek. A diszkrendszer terhelését befolyásolja például a letöltésre használható sávszélesség is. Még a fájlrendszer kiválasztására is ügyelnünk kell, s t, a mountolás opcióival is lehet ségünk nyílik gyorsítani a rendszert (például a noatime opcióval). Az IMAP és az SMTP szolgáltatás egy gépen történ futtatása ésszer nek t nik, hiszen a levelek kézbesítéséhez szükség van egy MTA-ra (SMTP szolgáltatásra). NTP szolgáltatást szoktam a t zfalra is telepíteni, hogy a bels szervereknek ne az Internetre kelljen menniük a pontos id ért. Viszont a bels hálózat klienseit nem szoktam a t zfalhoz odaengedni, ezért a bels hálózaton is létre szoktam hozni NTP szervert (vagy szervereket), amelyek közvetlenül a t zfalhoz szinkronizálják az óráikat, és szolgáltatnak a kliensek felé. Amennyiben nem áll rendelkezésünkre egy gép, amely a bels ntp szerver lehetne, akkor természetesen a kliensek szinkronizálhatnak a t zfalon futó ntp szerverhez. Ugyanez a helyzet a DNS szolgáltatással is. A t zfalra is telepítek, hogy a bels DNS szerver ne az Interneten lév szerverekkel beszéljen. Ily módon csak a t zfallal kell beszélnie. De a t zfal is csak a bels hálózat dedikált DNS szervereivel kommunikál, a kliensek nem érhetik el a t zfalon futó DNS szolgáltatást közvetlenül. Amennyiben nem áll rendelkezésünkre egy külön gép, amely a bels DNS szerver lehetne, akkor természetesen a klienseknek is el kell érniük a t zfalon futó DNS szervert. A központi logszerverre nem igazán érdemes mindenki számára elérhet szolgáltatásokat telepíteni, nehogy a felhasználók elfoglalják a logolás számára létfontosságú sávszélességet. Célszer a logelemz programokat is ezen a gépen futtatni, nem pedig a különálló szervereken, bár vigyáznunk kell, hogy az elemz programok ne terheljék le annyira a gépet, hogy az ne legyen képes mással foglalkozni. A mentéseket végz (és tároló) gépre lehet ség szerint semmilyen kívülr l elérhet szolgáltatást nem szabad rakni, hiszen (valószín leg) a lehet legtöbb érzékeny adatot ez a szerver tárolja. Az rsync csomag sokszor a segítségünkre lehet, érdemes telepíteni. Alapbeállításban nem fut démonként, tehát nem nyújt lehet séget a gép kívülr l történ elérésére. Jellemz en ssh csatornán keresztül használjuk március 23. Kósa Attila <konyv@mithrandir.hu>

12 12 Debian GNU/Linux Kósa Attila március 23.

13 2. fejezet DNS A cél az, hogy a bels hálózatunkban név szerint szólíthassuk meg a gépeinket. Ezt a feladatot megoldhatnánk a hosts fájlok segítségével is (miként az Internet h skorában is megoldották), de egy rendesen m köd névfeloldó-rendszer üzemeltetése kevesebb problémát okoz, mint a hiánya. Ugyanis a legtöbb szolgáltatás alapértelmezésben használni szeretné a névfeloldást, és a névfeloldás hiányából fakadó id túllépés lassítani fogja a kliensek kiszolgálását. Másodlagos DNS szerver nélkül is m köd képes a bels hálózat, de több okból érdemes megfontolni az alkamazását: Növelheti az üzembiztonságot, ha az els dleges szerver problémája esetén is van, aki kiszolgálja a klienseket. Vannak olyan szolgáltatások, amelyek sok névfeloldási kérést küldenek. Jellemz en ilyen például a proxy vagy a levelezés. Ezek mellé tehetünk másodlagos dns szervert (ezért került a példában is a levelez szerverre), ezáltal kihasználhatjuk a cache el nyét, valamint azt is, hogy a névfeloldási kérések nem a hálózaton keresztül történnek, hanem a saját gépen belül ezáltal gyorsabban jut adatokhoz a szolgáltatás, gyorsabbá válhat a kiszolgálás. A bels hálózatunkon használt domain-nek nem fontos az Interneten kapott tartománynévvel megegyeznie. Aki b vebb magyarázatot szeretne, az forduljon például az Irodalomjegyzékben megadott ([5]) anyaghoz. A használt DNS szerver típusától függetlenül javasolt betartanunk azt az elvet, hogy ne adjunk ki felesleges információt vagy túl sok adatot BIND Els dleges DNS szerver Telepítsük fel azokat a szoftvereket, amelyek szükségesek ahhoz, hogy a BIND8 segítségével megvalósíthassuk a DNS szerverünket. # apt-get install bind Állítsuk meg a kongurálás idejére: # /etc/init.d/bind stop Generáljunk egy titkos kulcsot (a dnskeygen parancs segítségével), amely a két BIND8 szerver (az els dleges és a másodlagos szerverekr l van szó) közötti adatforgalom titkosításához szükséges: # dnskeygen -H 512 -h -n titkos_kulcs ** Adding dot to the name to make it fully qualified domain name** Generating 512 bit HMAC-MD5 Key for titkos_kulcs. Generated 512 bit Key for titkos_kulcs. id=0 alg=157 flags=513 13

14 14 Debian GNU/Linux Két fájl jött létre a parancs hatására: Ktitkos_kulcs key Ktitkos_kulcs private A titkos_kulcs név bármi lehet, ez csak annak a fájlnak a nevét (pontosabban nevének egy részét) alkotja, amelyben a kulcs tárolásra kerül. A /etc/bind könyvtárban hoztam létre a fájlokat, de gyakorlatilag nincs jelent sége, hogy hol tároljuk, hiszen a kongurációs állományban úgyis szerepel maga a kulcs. Figyeljünk arra, hogy a két szerver órájának azonosan kell járnia (például 10 perc eltérés esetén már biztosan nem fog m ködni a szerverek közötti kommunikáció 1 ). A /etc/bind könyvtárban találhatóak a kongurációs állományok: named.conf az els dleges kongurációs állomány, a többi ebbe kerül beágyazásra (az include opció segítségével); named.conf.local a lokális zónák megadására szolgáló fájl; named.conf.options egyéb opciók megadására szolgáló fájl. A named.conf állományt hagyjuk változatlanul, csak a másik két fájlra fordítsuk a gyelmünket. A named.conf.options fájl felépítése az egyszer bb, ezért el ször azzal kezdjük a kongurálást. Amikor készen vagyunk, akkor így néz ki a kongurációs állomány: options { directory "/var/cache/bind"; fetch-glue no; // query-source address * port 53; forward only; forwarders { ; }; check-names master fail; check-names response warn; }; key titkos_kulcs { algorithm hmac-md5; secret "0mPVTGyCXISROZNDFwIkrbc/iI9hhFvdInL1gym3JAgEs1ibzPwYoxm39g3X1qYO+KK8ymFRe7pn7nQ0diFVIw=="; }; server { transfer-format many-answers; keys { titkos_kulcs; }; }; A fájl elején látható a directory opció. Az itt látható /var/cache/bind könyvtárban tárolhatjuk a named.conf.local fájlban megadott zónafájljainkat. A query-source address opció azt határozza meg, hogy melyik interfészen melyik portról indítsa a lekérdezéseket a BIND8. Vegyük ki a kommentet ez el l a sor el l, így az alapértelmezett 53-as portról fogja indítani a kérdéseket minden interfészen. 2 Az id bebizonyította, hogy NEM jó ötlet xálni a portot ( tehát NE vegyük ki a kommentet ez el l a sor el l! A forwarders opció abban van a segítségünkre, hogy a bels hálózatunkon lév DNS szerverünk ne akarjon a nagyvilággal kommunikálni, kizárólag a t zfalunkon lév DNS szerverrel beszélgessen tehát itt adjuk meg a t zfalunk IP címét. Ahhoz, hogy ez valóban így is történjen, szükséges még a forward only opció megadása is. 1 Ez is indokolja az id szinkronizálásról szóló 4. fejezet létjogosultságát. 2 Ennek a csomagsz r beállításánál látjuk hasznát, hiszen így pontosan korlátozni tudjuk, hogy egyes DNS szervereink melyik portról fogják indítani kérdéseiket. Viszont egy esetleges támadó is élhet azzal a feltételezéssel, hogy rögzítettük a portszámot, ezáltal nagyságrendekkel könnyebb dolga lesz egy dns támadás (blind DNS forgery) esetén. Persze ahhoz, hogy sikeres támadást hajthasson végre kell az, hogy a t zfal bels lábának IP címét spoofolja (azt hazudja, hogy a t zfal), el kell találnia mind a kérdésben szerepl úgynevezett nonce-ot (ami egy 16 bites szám), mind a forrásportot. Amennyiben kikommentezve hagyjuk, akkor a szerverünk úgy fog viselkedni (lekérdezés szempontjából), mint egy egyszer kliens (az 1024-es portjánál magasabb portról fogja indítani a lekérdezéseket). Kósa Attila <konyv@mithrandir.hu> március 23.

15 Debian GNU/Linux 15 A recursion no opcióval azt tudjuk szabályozni, hogy a szerverünk válaszoljon-e a klienseknek a saját zónáin kívül es adatokkal kapcsolatban. Van egy allow-recursion opció, amellyel az esetleges tiltás ellenére ezt mégis engedélyezni tudjuk a kívánt gépek számára. A check-names opció a kongurációs hibákra adott viselkedést szabályozza. Külön lehet szabályozni, hogy mi történjen, ha a saját els dleges zónáiban (master), ha a másodlagos zónákban (slave), illetve egy kérdésre kapott válaszban (response) talál hibát. Három értéket lehet beállítani mindegyik eseteben: fail hibaüzenetet ír a logfájlba, és az adatot nem veszi gyelembe; warn hibaüzenetet ír a logfájlba; ignore nem tör dik a hibával. A transfer-format many-answers opció azt biztosítja, hogy a szerver a válaszait ne egyesével, hanem kötegelve küldje a másodlagos szervernek. Ezen a gépen a /etc/resolv.conf fájlban célszer saját magát (tehát a IP címet) beírni a nameserver sorba, illetve a search opcióban az általa kezelt zónát megadni. A t zfal IP címét is tegyük bele a biztonság kedvéért. Tehát így nézzen ki a fájl: search akarmi.intra nameserver nameserver A named.conf.local fájlnak kell tartalmaznia azt, hogy az egyes zónákhoz hogyan viszonyuljon a DNS szerverünk. Leggyakrabban a master és slave típusú zónák használatosak. Egyel re csak a master típusú zónákkal foglalkozunk, a slave típusra a másodlagos DNS szerver beállításánál látható példa (17. oldal). zone "akarmi.intra" { type master; file "belso.db"; allow-transfer { ; }; allow-query { ; /24; }; also-notify { ; }; notify yes; }; zone " in-addr.arpa" { type master; file "belso-rev.db"; allow-transfer { ; }; allow-query { ; /24; }; also-notify { ; }; notify yes; }; Lássuk, mit is jelentenek a zónafájl sorai. A type sorban azt lehet megadni, hogy milyen viszonyban áll a szerverünk az adott zónával. A le opció után a zóna tárolására szolgáló fájl nevét adhatjuk meg (csak fájlnév esetén a named.conf.options fájl directory opciója határozza meg az elérési útvonalat, de akár teljes elérési útvonalat is megadhatunk). Az allow-transfer opció lehet séget nyújt azon IP címek felsorolására, amelyek zónatranszfert végezhetnek. Itt több címet is megadhatunk, egymás alatt, de pontosvessz vel elválasztva ket. Az allow-query opció annak korlátozását teszi lehet vé, hogy kikt l fogadjon el kérést (illetve milyen címekr l, címtartományokból érkez kérésekre válaszoljon) a szerver. Az also-notify deniál egy IP címekb l álló listát, egyúttal meghatározva azt, hogy ezeknek a címeknek kell elküldeni a NOTIFY üzenetet, amikor a zónafájl új verziója kerül betöltésre a szerveren. A notify yes arra utasítja az március 23. Kósa Attila <konyv@mithrandir.hu>

16 16 Debian GNU/Linux els dleges szerverünket, hogy ha a zónafájl változását észleli, akkor küldjön jelzést a másodlagos szervereknek, hogy frissítsék a zónát. Ekkor van jelent sége a kés bb említésre kerül Serial-nak, mert a másodlagos szerverek ennek a változásából tudják majd, hogy valóban frissült az adott zóna, és ezután kérik le az els dleges szervert l, hogy náluk is az új adatok legyenek meg. Miután az alapvet kongurációval elkészültünk, már csak az általunk kezelt zónafájlok megírása van hátra, hogy üzembeállíthassuk DNS szerverünket. Ezeket a fájlokat a /var/cache/bind könyvtárban kell elhelyeznünk. Lássuk ezen fájlok formátumát és a lehetséges tartalmukat (a teljesség igénye nélkül). El ször a belso.db 3 névre keresztelt fájlt készítsük el. $TTL IN SOA dns.akarmi.intra. dnsmaster.akarmi.intra. ( ; Serial ; Refresh 900 ; Retry ; Expire ) ; Negativ cache IN NS IN NS slavedns.akarmi.intra. $origin akarmi.intra. kliens1 IN A intraweb IN A wpad IN CNAME intraweb.akarmi.intra. backup IN A syslog IN A samba IN A proxy IN A mail IN A slavedns IN CNAME mail.akarmi.intra. dns IN A time IN CNAME dns.akarmi.intra. fw IN A Már csak a belso-rev.db 3 nev fájl elkészítése van hátra. $TTL IN SOA dns.akarmi.intra. root.dns.akarmi.intra. ( ; Serial ; Refresh 900 ; Retry ; Expire ) ; Negativ cache IN NS IN NS slavedns.akarmi.intra. $origin in-addr.arpa. 10 IN PTR kliens1.akarmi.intra. 247 IN PTR intraweb.akarmi.intra. 248 IN PTR backup.akarmi.intra. 249 IN PTR syslog.akarmi.intra. 250 IN PTR samba.akarmi.intra. 251 IN PTR proxy.akarmi.intra. 252 IN PTR mail.akarmi.intra. 253 IN PTR dns.akarmi.intra. 254 IN PTR fw.akarmi.intra. Némi magyarázat ahhoz, hogy mit is jelentenek a fájlok elején a számsorok Serial. Ez egy egyszer sorszám, amelyet lehetne más formában használni (például nem a fenti évhónapnapverzió formában, hanem egyszer en egy számot írnánk oda, például 1). Ezt a számot kell növelnünk, ha az adott zónafájlban változtatásokat hajtottunk végre ebb l tudják majd a másodlagos szerverek, hogy az adott zónán mikor történt változtatás (azért használom én a dátumos formátumot, hogy az emberi szem számára is azonnal látható legyen, mikor történt az utolsó változtatás). Nem árt megszoknunk, hogy növeljük ezt a számot, sok bosszúságtól (érthetetlen problémáktól és felesleges hibakeresést l) kímélhetjük meg magunkat Refresh (frissítési id ). Ez egy másodpercekben megadott érték. Azt mondja meg, hogy a másodlagos szervereknek mennyi id nként kell az els dleges szervert l lekérdezniük a Serial értékét (hogy szükséges-e a zónát frissíteni). 3 Önkényesen választottam ezt a fájlnevet. Kósa Attila <konyv@mithrandir.hu> március 23.

17 Debian GNU/Linux Retry (várakozás). Ez egy másodpercekben megadott érték. Ha a frissítés nem sikerül a másodlagos szervereken, akkor ennyi ideig kell várakozniuk az újabb próbálkozás el tt Expire (lejárati id ). Ez egy másodpercekben megadott érték, amely a zóna adatainak lejárati idejét adja meg. A másodlagos DNS szerverek ennyi ideig szolgáltathatják az els dleges szervert l kapott zónát, ha nem sikerül felvenniük a kapcsolatot az els dleges szerverrel Negatív cache TTL. Ez egy másodpercekben megadott érték, amely a hibás lekérdezések cache-elésének id tartamára vonatkozik. Végeztünk is az alapvet kongurálással, most már rendelkezünk egy m köd DNS szerverrel, csak el kell indítanunk a /etc/init.d/bind start paranccsal. Az indítást követ en ellen rizzük a logokban, hogy hibaüzenet nélkül indult el, illetve például a netstat -natp paranccsal, hogy gyel-e a megfelel interfészeken Másodlagos DNS szerver Gyakorlatilag ugyanarra a szoftverre van szükségünk, amelyre az els dleges szerver telepítésénél. # apt-get install bind Ebb l következ en ugyanazokat a fájlokat fogjuk megtalálni a telepítés végén, mint amelyeket már megbeszéltünk, tehát nézzük azonnal a kongurációs állományokat (miután leállítottuk a kongurálás idejére a szolgáltatást): # /etc/init.d/bind stop A resolv.conf állomány így nézzen ki: search akarmi.intra nameserver nameserver nameserver A named.conf.options fájl tartalma megegyezik az els dleges szerverével (két apró eltérést l eltekintve, amely a check-names opciót érinti, ahová master helyett a slave szót kell beírni; illetve a server opciót, ahová az els dleges szerver IP címét kell beírni), így akár át is másolhatjuk a másodlagos szerverre (csak ne felejtsük el átírni a fentieket). A named.conf.options fájlnak nem kötelez megegyeznie, hiszen más feladatokat is elláthat a szerver amellett, hogy az els dleges szerver zónáit kezeli. A named.conf.local fájl tartalma már némiképp eltér, amint az a következ kben látható. zone "akarmi.intra" { type slave; masters port 53 { ; }; file "belso.db"; allow-query { ; /24; }; }; zone " in-addr.arpa" { type slave; masters port 53 { ; }; file "belso-rev.db"; allow-query { ; /24; }; }; Mondhatni, hogy készen is vagyunk, hiszen a named.conf fájlt ezen a gépen is változatlanul hagyhatjuk. Indítsuk el: március 23. Kósa Attila <konyv@mithrandir.hu>

18 18 Debian GNU/Linux # /etc/init.d/bind start A másodlagos szerver elindításakor azt fogjuk látni a logokban (a master szerveren), ahogy lekéri a master szervert l a zónákat: Mar 26 11:21:21 dns named[10481]: approved AXFR from [ ].2266 for "akarmi.intra" (TSIG key "titkos_kulcs") Mar 26 11:21:21 dns named[10481]: zone transfer (AXFR) of "akarmi.intra" (IN) to [ ].2266 serial Mar 26 11:21:21 dns named[10481]: approved AXFR from [ ].2267 for " in-addr.arpa" (TSIG key "titkos_kulcs") Mar 26 11:21:21 dns named[10481]: zone transfer (AXFR) of " in-addr.arpa" (IN) to [ ].2267 serial BIND Els dleges DNS szerver Telepítsük fel azt a szoftvert, amely szükséges ahhoz, hogy a BIND9 segítségével megvalósíthassuk a DNS szerverünket. # apt-get install bind9 Láthatjuk, amint a telepítés végén létrejön egy csoport és egy felhasználói account, illetve egy rndc.key nev fájl a /etc/bind könyvtárban, majd elindul a szolgáltatás: Setting up bind9 ( )... Adding group `bind' (GID 103)... Done. Adding system user `bind' (UID 101)... Adding new user `bind' (UID 101) with group `bind'... Not creating home directory `/var/cache/bind'. wrote key file "/etc/bind/rndc.key" Starting domain name service...: bind. Állítsunk le a kongurálás idejére: # /etc/init.d/bind9 stop Generáljunk egy titkos kulcsot, amelynek segítségével a két DNS-szerverünk (az els dleges és a másodlagos) egymással titkosított kapcsolaton beszélhet: # cd /etc/bind # dnssec-keygen -a hmac-md5 -b 128 -n HOST titkos_kulcs Ktitkos_kulcs Két fájl jött létre a parancs hatására, amelyeket igazából nem használunk semmire, csak a tartalmukat. Ktitkos_kulcs key Ktitkos_kulcs private A /etc/default könyvtárban található egy bind9 nev állomány, amely mindössze az alábbiakat tartalmazza: OPTIONS="-u bind" RESOLVCONF=yes Ez azt okozza, hogy a BIND9 a bind nev felhasználó és csoport nevében fog futni, tehát nem root jogosultságokkal. A /etc/bind könyvtárban találhatóak a kongurációs állományok: named.conf az els dleges kongurációs állomány, a többi ebbe kerül beágyazásra (az include opció segítségével); named.conf.local a lokális zónák megadására szolgáló fájl; named.conf.options egyéb opciók megadására szolgáló fájl. A named.conf állományt hagyjuk változatlanul, és csak a másik két fájlra fordítsuk a - gyelmünket. A named.conf.options fájl felépítése az egyszer bb, ezért el ször azzal kezdjük a kongurálást. Amikor készen vagyunk, akkor így néz ki a kongurációs állomány: Kósa Attila <konyv@mithrandir.hu> március 23.

19 Debian GNU/Linux 19 acl belso_halo { /24; }; acl masodlagos_dns { ; }; server { keys { titkos_kulcs; }; }; key titkos_kulcs { algorithm hmac-md5; secret "islfixrey4p2uedv9+rhfw=="; }; options { directory "/var/cache/bind"; // query-source address * port 53; forward only; forwarders { ; }; check-names master fail; check-names response warn; allow-transfer { key titkos_kulcs; }; allow-query { localhost; belso_halo; }; allow-recursion { localhost; belso_halo; }; }; auth-nxdomain no; listen-on-v6 { none; }; Az acl opciókban el re felsorolhatjuk az IP címeket, és adhatunk nekik egy-egy nevet, majd ezeket a neveket használhatjuk a többi opcióban. Ily módon egyetlen helyen tudjuk karbantartani az IP címeket, nem kell minden opciónál külön-külön. A server opcióval azt határozzuk meg, hogy mely szerverekkel való kapcsolattartáshoz melyik titkos kulcsot használja a szerver. A key opcióval rendelhetünk egy nevet egy kulcshoz, hogy ennek a névnek a segítségével tudjunk hivatkozni rá a kés bbiekben. A directory opció határozza meg, hogy melyik könyvtárban tárolhatjuk a named.conf.local fájlban megadott zónafájljainkat. A query-source address opció azt határozza meg, hogy melyik interfészen melyik portról indítsa a lekérdezéseket a BIND9. Vegyük ki a kommentet ez el l a sor el l, így az alapértelmezett 53-as portról fogja indítani a kérdéseket minden interfészen. 4 Az id bebizonyította, hogy NEM jó ötlet xálni a portot ( tehát NE vegyük ki a kommentet ez el l a sor el l! A forwarders opció abban van a segítségünkre, hogy a bels hálózatunkon lév DNS szerverünk ne akarjon a nagyvilággal kommunikálni, kizárólag a t zfalunkon lév DNS szerverrel beszélgessen tehát itt adjuk meg a t zfalunk IP címét. Ahhoz, hogy ez valóban így is történjen, szükséges még a forward only opció megadása is. A check-names opció a kongurációs hibákra adott viselkedést szabályozza. Külön lehet szabályozni, hogy mi történjen, ha a saját els dleges zónáiban (master), ha a másodlagos zónákban (slave), illetve egy kérdésre kapott válaszban (response) talál hibát. Három értéket lehet beállítani mindegyik eseteben: fail hibaüzenetet ír a logfájlba, és az adatot nem veszi gyelembe; warn hibaüzenetet ír a logfájlba; ignore nem tör dik a hibával. 4 Ennek a csomagsz r beállításánál látjuk hasznát, hiszen így pontosan korlátozni tudjuk, hogy egyes DNS szervereink melyik portról fogják indítani kérdéseiket. Viszont egy esetleges támadó is élhet azzal a feltételezéssel, hogy rögzítettük a portszámot, ezáltal nagyságrendekkel könnyebb dolga lesz egy dns támadás (blind DNS forgery) esetén. Persze ahhoz, hogy sikeres támadást hajthasson végre kell az, hogy a t zfal bels lábának IP címét spoofolja (azt hazudja, hogy a t zfal), el kell találnia mind a kérdésben szerepl úgynevezett nonce-ot (ami egy 16 bites szám), mind a forrásportot. Amennyiben kikommentezve hagyjuk, akkor a szerverünk úgy fog viselkedni (lekérdezés szempontjából), mint egy egyszer kliens (az 1024-es portjánál magasabb portról fogja indítani a lekérdezéseket) március 23. Kósa Attila <konyv@mithrandir.hu>

20 20 Debian GNU/Linux Az allow-transfer opció lehet séget nyújt azon IP címek felsorolására, akik zónatranszfert végezhetnek. Itt több címet is megadhatunk, egymás alatt, de pontosvessz vel elválasztva ket, illetve kiköthetjük azt, hogy csak azok végezhetnek ilyet, akik rendelkeznek a megfelel tikos kulccsal. Az allow-query opció annak korlátozását teszi lehet vé, hogy kikt l fogadjon el kérést (illetve milyen címekr l, címtartományokból érkez kérésekre válaszoljon) a szerver. Az allow-recursion opcióval azt tudjuk szabályozni, hogy a szerverünk mely klienseknek válaszoljon a saját zónáin kívül es adatokkal kapcsolatban. A listen-on-v6 opció azt szabályozza, hogy mely hálózati kártyákon gyeljen IPv6-on. Létezik egy max-cache-size nev opció, amelynek a segítségével lehet limitálni a gyorsítótárnak használt memória méretét (byte-ban kell megadni). Ha túl kevés memóriát adunk a szolgáltatásnak, akkor az kihat a kiszolgálás sebességére. Érdemes pár héten keresztül korlátozás nélkül futtatni a szolgáltatást, annyi id alatt be fog állni egy megközelít leg stabil értékre a memóriafoglalás, majd ezt az értéket gyelembe véve kell beállítani a limitet. Ideális esetben ez a limit magasabbra van állítva, mint a tapasztalt stabil érték. Ezen a gépen a /etc/resolv.conf fájlban célszer saját magát (tehát a IP címet) beírni a nameserver sorba, illetve a search opcióban az általa kezelt zónát megadni. A biztonság kedvéért tegyük bele a t zfal IP címét is. Tehát így nézzen ki a fájl: search akarmi.intra nameserver nameserver A named.conf.local fájlnak kell tartalmaznia azt, hogy az egyes zónákhoz hogyan viszonyuljon a DNS szerverünk. Leggyakrabban a master és slave típusú zónák használatosak. Egyel re csak a master típusú zónákkal foglalkozunk, a slave típusra a másodlagos DNS szerver beállításánál látható példa (23. oldal). zone "akarmi.intra" { type master; file "belso.db"; allow-transfer { ; }; allow-query { ; /24; }; also-notify { ; }; notify yes; }; zone " in-addr.arpa" { type master; file "belso-rev.db"; allow-transfer { ; }; allow-query { ; /24; }; also-notify { ; }; notify yes; }; Lássuk, mit is jelentenek a zónafájl sorai. A type sorban azt lehet megadni, hogy milyen viszonyban áll a szerverünk az adott zónával. A le opció után a zóna tárolására szolgáló fájl nevét adhatjuk meg (csak fájlnév esetén a named.conf.options fájl directory opciója határozza meg az elérési útvonalat, de akár teljes elérési útvonalat is megadhatunk). Az allow-transfer opció lehet séget nyújt azon IP címek felsorolására, amelyek zónatranszfert végezhetnek. Itt több címet is megadhatunk, de pontosvessz vel kell elválasztanunk ket. Az allow-query opció annak korlátozását teszi lehet vé, hogy kikt l fogadjon el kérést (illetve milyen címekr l, címtartományokból érkez kérésekre válaszoljon) a szerver. Az also-notify deniál egy IP címekb l álló listát, egyúttal meghatározva azt, hogy ezeknek a címeknek kell elküldeni a NOTIFY üzenetet, Kósa Attila <konyv@mithrandir.hu> március 23.