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
[email protected] 2009. március 23.
Debian GNU/Linux
2
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
(14.8.2 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¶ • •
kis méret¶, írógép típusú bet¶
fájlok és könyvtárak neve;
kiadandó parancsok;
kis méret¶, írógép típusú bet¶, bekeretezve
Kósa Attila
kongurációs állományok, szkriptek.
2009. március 23.
Debian GNU/Linux
3
c 2007. Kósa Attila Copyright 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.
2009. március 23.
Kósa Attila
Debian GNU/Linux
4
Kósa Attila
2009. március 23.
Tartalomjegyzék
El®szó
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Köszönetnyilvánítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.
A terv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.
3.
4.
5.
6.
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.1.
BIND8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2.
BIND9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.3.
Adminisztrációs eszközök a
. . . . . . . . . . . . . . . . . . . . . .
23
2.4.
A DNS tesztelésére használható eszközök . . . . . . . . . . . . . . . . . . . . .
25
2.5.
A többi szerver DNS beállítása
. . . . . . . . . . . . . . . . . . . . . . . . . .
26
DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.1.
dhcp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.
dhcp3-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.1.
Id®szinkron ntp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2.
ntpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.3.
Windows alatti NTP beállítások . . . . . . . . . . . . . . . . . . . . . . . . . .
Biztonság
SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
ssh
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
LDAP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OpenLDAP
43
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
SaMBa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Levelek küldése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
Fájlszerver
8.1. 9.
34 35
5.2.
7.1. 8.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.
6.1. 7.
BIND9 -hez
Postx
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Levelek olvasása 9.1.
10. Proxy
Dovecot
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65 69
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
10.1.
Squid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
10.2.
Automatikus proxybeállítás
75
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
11. Web
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
11.1.
Apache HTTP-n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
11.2.
Apache HTTPS-en
78
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12. Naplózás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
12.1.
logcheck
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
12.2.
logrotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
12.3.
pogsumm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
12.4.
syslog-ng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
13. Mentés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
13.1.
Amanda
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
14. Csomagsz¶rés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
5
Debian GNU/Linux
6
14.1.
DNS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.2.
NTP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
99
14.3.
ICMP
14.4.
POP2, POP3, POP3S, IMAP, IMAPS
14.5.
SMTP
14.6.
UUCP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
14.7.
AUTH
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
14.8.
FTP
14.9.
TFTP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 . . . . . . . . . . . . . . . . . . . . . . 101
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
14.10. HTTP, HTTPS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
14.11. nger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 14.12. whois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 14.13. syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 14.14. r parancsok
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
14.15. telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 14.16. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 14.17. NNTP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
14.18. talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 14.19. IRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 14.20. SNMP 14.21. NFS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
14.22. NIS/YP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
14.23. X11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 14.24. SaMBa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 14.25. lpr
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
15. TZFAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 15.1.
DNS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
15.2.
NTP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
15.3.
ntpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
15.4.
SMTP
15.5.
VPN
15.6.
Csomagsz¶rés
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
GNU Licenc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Tárgymutató
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Irodalomjegyzék . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Kósa Attila
2009. március 23.
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ám-
ban), ami persze nem jelenti azt, hogy használhatatlan lenne más Linux disztribúciók használóinak. A leírás hálózatot
LATEX -ben
készült,
vmware server
vim
és
dvips
segítségével. A tesztelésre használt gépeket és
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]) szer-
z®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
Debian GNU/Linux
8
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 e-mail-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ó e-mail címen. OTP bankos számlaszámom: 11773346-04210407.
Támogatók Csak a weben elérhet® változatban található meg a felsorolás.
http://www.mithrandir.hu/doc/book/index.html
Kósa Attila
2009. március 23.
1. fejezet
A terv
El®ször pár szót arról, hogy MIRL 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
1
tényez® , amely az egyes szolgáltatások beállítását befolyásolja. És most nézzük végre azt, hogy MIRL SZÓL a könyv. Kiválasztottam egy számomra szimpatikus hálózatot (egy C osztályút, a 192.168.10.0 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.
2
A szerverek Linuxot fognak futtatni, míg a munkaállomások windowsos gépek lesznek . 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):
1 2
•
DNS (els®dleges és másodlagos);
•
DHCP (egyes gépekhez xen hozzárendelt IP címek);
A felsorolás nem teljes, számtalan egyéb dologtól is függhet az optimális beállítás. 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
Debian GNU/Linux
10
•
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ányne-
vet 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, 192.168.10.247;
•
a mentéseket végz® szerver backup, 192.168.10.248;
•
a logszerver syslog, 192.168.10.249;
•
a fájlszerver samba, 192.168.10.250;
•
a proxyszerver proxy, 192.168.10.251;
•
a levelez®szerver mail, 192.168.10.252;
•
a DNS-szerver dns, 192.168.10.253;
•
a t¶zfal bels® hálózat felé néz® lába fw, 192.168.10.254.
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 (http://www.ietf.
org/rfc/rfc1519.txt)
Kósa Attila
és az rfc1219.txt (http://www.ietf.org/rfc/rfc1219.txt).
2009. március 23.
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.
2009. március 23.
Kósa Attila
Debian GNU/Linux
12
Kósa Attila
2009. március 23.
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.
2.1.
BIND8
2.1.1.
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
szer-
ver (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
Debian GNU/Linux
14
Két fájl jött létre a parancs hatására: Ktitkos_kulcs.+157+00000.key Ktitkos_kulcs.+157+00000.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áj-
lokat, 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á-
1
ció ). A
/etc/bind
könyvtárban találhatóak a kongurációs állományok:
• named.conf
include
az els®dleges kongurációs állomány, a többi ebbe kerül beágyazásra (az
opció segítségével);
• named.conf.local
a lokális zónák megadására szolgáló fájl;
• named.conf.options A
egyéb opciók megadására szolgáló fájl.
named.conf állományt hagyjuk változatlanul, csak a másik két named.conf.options fájl felépítése az egyszer¶bb, ezért
münket. A
fájlra fordítsuk a gyelel®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 { 192.168.10.254; }; check-names master fail; check-names response warn; }; key titkos_kulcs { algorithm hmac-md5; secret "0mPVTGyCXISROZNDFwIkrbc/iI9hhFvdInL1gym3JAgEs1ibzPwYoxm39g3X1qYO+KK8ymFRe7pn7nQ0diFVIw=="; }; server 192.168.10.252 { transfer-format many-answers; keys { titkos_kulcs; }; };
A fájl elején látható a hatjuk a A
directory
named.conf.local
query-source address
indítsa a lekérdezéseket a
opció. Az itt látható
/var/cache/bind
könyvtárban tárol-
fájlban megadott zónafájljainkat.
opció azt határozza meg, hogy melyik interfészen melyik portról
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 (http://www.securityfocus.com/news/11526?ref=rss), 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 szer-
verü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
1 2
forward only
opció megadása is.
Ez is indokolja az id®szinkronizálásról szóló 4. fejezet létjogosultságát. 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
2009. március 23.
Debian GNU/Linux A
15
recursion no opcióval azt tudjuk szabályozni, hogy a szerverünk válaszoljon-e a klienseknek allow-recursion opció, amellyel az
a saját zónáin kívül es® adatokkal kapcsolatban. Van egy
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 beírni a
/etc/resolv.conf fájlban célszer¶ saját magát (tehát a 127.0.0.1 IP címet)
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 127.0.0.1 nameserver 192.168.10.254
A
named.conf.local
fájlnak kell tartalmaznia azt, hogy az egyes zónákhoz hogyan vi-
szonyuljon a DNS szerverünk. Leggyakrabban a Egyel®re csak a
master
master és slave típusú zónák használatosak. slave típusra a másodlagos DNS szerver
típusú zónákkal foglalkozunk, a
beállításánál látható példa (17. oldal). zone "akarmi.intra" { type master; file "belso.db"; allow-transfer { 192.168.10.252; }; allow-query { 127.0.0.1; 192.168.10.0/24; }; also-notify { 192.168.10.252; }; notify yes; }; zone "10.168.192.in-addr.arpa" { type master; file "belso-rev.db"; allow-transfer { 192.168.10.252; }; allow-query { 127.0.0.1; 192.168.10.0/24; }; also-notify { 192.168.10.252; }; notify yes; };
type sorban azt lehet megadni, hogy milyen 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 opLássuk, mit is jelentenek a zónafájl sorai. A
viszonyban áll a szerverünk az adott zónával. A
ció 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
2009. március 23.
notify yes
Kósa Attila
arra utasítja az
Debian GNU/Linux
16
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 $TTL 86400 @ IN
SOA
belso.db3
névre keresztelt fájlt készítsük el.
dns.akarmi.intra. dnsmaster.akarmi.intra. ( 2007022001 ; Serial 86400 ; Refresh 900 ; Retry 604800 ; Expire 86400 ) ; Negativ cache TTL
@ @
IN IN
NS NS
dns.akarmi.intra. slavedns.akarmi.intra.
$origin akarmi.intra. kliens1
IN
A
192.168.10.10
intraweb wpad backup syslog samba proxy mail slavedns dns time fw
IN IN IN IN IN IN IN IN IN IN IN
A CNAME A A A A A CNAME A CNAME A
192.168.10.247 intraweb.akarmi.intra. 192.168.10.248 192.168.10.249 192.168.10.250 192.168.10.251 192.168.10.252 mail.akarmi.intra. 192.168.10.253 dns.akarmi.intra. 192.168.10.254
Már csak a $TTL 86400 @ IN
SOA
belso-rev.db3
nev¶ fájl elkészítése van hátra.
dns.akarmi.intra. root.dns.akarmi.intra. ( 2007022001 ; Serial 86400 ; Refresh 900 ; Retry 604800 ; Expire 86400 ) ; Negativ cache TTL
@ @
IN IN
NS NS
dns.akarmi.intra. slavedns.akarmi.intra.
$origin 10.168.192.in-addr.arpa. 10
IN
PTR
kliens1.akarmi.intra.
247 248 249 250 251 252 253 254
IN IN IN IN IN IN IN IN
PTR PTR PTR PTR PTR PTR PTR PTR
intraweb.akarmi.intra. backup.akarmi.intra. syslog.akarmi.intra. samba.akarmi.intra. proxy.akarmi.intra. mail.akarmi.intra. dns.akarmi.intra. fw.akarmi.intra.
Némi magyarázat ahhoz, hogy mit is jelentenek a fájlok elején a számsorok.
2007022001
Serial. Ez egy egyszer¶ sorszám, amelyet lehetne más formában használni (pél-
dá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.
86400
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
2009. március 23.
Debian GNU/Linux 900
17
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.
604800
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.
86400
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
pa-
ranccsal, hogy gyel-e a megfelel® interfészeken.
2.1.2.
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 127.0.0.1 nameserver 192.168.10.253 nameserver 192.168.10.254
A
named.conf.options fájl tartalma megegyezik az els®dleges szerverével (két apró eltérés-
t®l eltekintve, amely a illetve a
server
check-names
opciót érinti, ahová
master
helyett a
slave
szót kell beírni;
opciót, ahová az els®dleges szerver IP címét kell beírni), így akár át is másol-
hatjuk 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 { 192.168.10.253; }; file "belso.db"; allow-query { 127.0.0.1; 192.168.10.0/24; }; }; zone "10.168.192.in-addr.arpa" { type slave; masters port 53 { 192.168.10.253; }; file "belso-rev.db"; allow-query { 127.0.0.1; 192.168.10.0/24; }; };
Mondhatni, hogy készen is vagyunk, hiszen a
named.conf fájlt ezen a gépen is változatlanul
hagyhatjuk. Indítsuk el:
2009. március 23.
Kósa Attila
Debian GNU/Linux
18
# /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 Mar Mar Mar
26 26 26 26
11:21:21 11:21:21 11:21:21 11:21:21
2.2.
dns dns dns dns
named[10481]: named[10481]: named[10481]: named[10481]:
approved AXFR zone transfer approved AXFR zone transfer
from [192.168.10.252].2266 for "akarmi.intra" (TSIG key "titkos_kulcs") (AXFR) of "akarmi.intra" (IN) to [192.168.10.252].2266 serial 2007032101 from [192.168.10.252].2267 for " 10.168.192.in-addr.arpa" (TSIG key "titkos_kulcs") (AXFR) of "10.168.192.in-addr.arpa" (IN) to [192.168.10.252].2267 serial 2007032101
BIND9
2.2.1.
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 (9.3.4-2) ... 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.+157+34456
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.+157+34456.key Ktitkos_kulcs.+157+34456.private
A
/etc/default könyvtárban található egy bind9 nev¶ állomány, amely mindössze az aláb-
biakat tartalmazza: OPTIONS="-u bind" RESOLVCONF=yes
Ez azt okozza, hogy a
BIND9
root jogosultságokkal. A /etc/bind könyvtárban
a
bind
nev¶ felhasználó és csoport nevében fog futni, tehát
nem
• named.conf
include
az els®dleges kongurációs állomány, a többi ebbe kerül beágyazásra (az
opció segítségével);
• named.conf.local
a lokális zónák megadására szolgáló fájl;
• named.conf.options A
találhatóak a kongurációs állományok:
egyéb opciók megadására szolgáló fájl.
named.conf állományt hagyjuk változatlanul, és csak a másik két fájlra fordítsuk a named.conf.options fájl felépítése az egyszer¶bb, ezért el®ször azzal kezdjük a
gyelmünket. A kongurálást.
Amikor készen vagyunk, akkor így néz ki a kongurációs állomány:
Kósa Attila
2009. március 23.
Debian GNU/Linux
19
acl belso_halo { 192.168.10.0/24; }; acl masodlagos_dns { 192.168.10.252; }; server 192.168.10.252 { 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 { 192.168.10.254; }; 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
indítsa a lekérdezéseket a
opció azt határozza meg, hogy melyik interfészen melyik portról
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 (http://www.securityfocus.com/news/11526?ref=rss), 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 szer-
verü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,
forward only opció megadása is. check-names opció a kongurációs hibákra
szükséges még a A
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:
4
•
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.
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).
2009. március 23.
Kósa Attila
Debian GNU/Linux
20
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. max-cache-size nev¶ opció, amelynek a segítségével lehet limitálni a gyorsító-
Létezik egy
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 beírni a
/etc/resolv.conf fájlban célszer¶ saját magát (tehát a 127.0.0.1 IP címet)
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 127.0.0.1 nameserver 192.168.10.254
A
named.conf.local
fájlnak kell tartalmaznia azt, hogy az egyes zónákhoz hogyan vi-
szonyuljon a DNS szerverünk. Leggyakrabban a Egyel®re csak a
master
master és slave típusú zónák használatosak. slave típusra a másodlagos DNS szerver
típusú zónákkal foglalkozunk, a
beállításánál látható példa (23. oldal). zone "akarmi.intra" { type master; file "belso.db"; allow-transfer { 192.168.10.252; }; allow-query { 127.0.0.1; 192.168.10.0/24; }; also-notify { 192.168.10.252; }; notify yes; }; zone "10.168.192.in-addr.arpa" { type master; file "belso-rev.db"; allow-transfer { 192.168.10.252; }; allow-query { 127.0.0.1; 192.168.10.0/24; }; also-notify { 192.168.10.252; }; notify yes; };
type sorban azt lehet megadni, hogy milyen 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 opLássuk, mit is jelentenek a zónafájl sorai. A
viszonyban áll a szerverünk az adott zónával. A
ció 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
2009. március 23.
Debian GNU/Linux
21
amikor a zónafájl új verziója kerül betöltésre a szerveren. A
notify yes arra utasítja az 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 $TTL 86400 @ IN
SOA
@ @
belso.db5
névre keresztelt fájlt készítsük el.
dns.akarmi.intra. dnsmaster.akarmi.intra. ( 2007022001 ; Serial 86400 ; Refresh 900 ; Retry 604800 ; Expire 86400 ) ; Negativ cache TTL IN IN
NS NS
dns.akarmi.intra. slavedns.akarmi.intra.
$origin akarmi.intra. kliens1
IN
A
192.168.10.10
intraweb wpad backup syslog samba proxy mail slavedns dns time fw
IN IN IN IN IN IN IN IN IN IN IN
A CNAME A A A A A CNAME A CNAME A
192.168.10.247 intraweb.akarmi.intra. 192.168.10.248 192.168.10.249 192.168.10.250 192.168.10.251 192.168.10.252 mail.akarmi.intra. 192.168.10.253 dns.akarmi.intra. 192.168.10.254
Már csak a $TTL 86400 @ IN
SOA
@ @
belso-rev.db5
nev¶ fájl elkészítése van hátra.
dns.akarmi.intra. root.dns.akarmi.intra. ( 2007022001 ; Serial 86400 ; Refresh 900 ; Retry 604800 ; Expire 86400 ) ; Negativ cache TTL IN IN
NS NS
dns.akarmi.intra. slavedns.akarmi.intra.
$origin 10.168.192.in-addr.arpa. 10
IN
PTR
kliens1.akarmi.intra.
247 248 249 250 251 252 253 254
IN IN IN IN IN IN IN IN
PTR PTR PTR PTR PTR PTR PTR PTR
intraweb.akarmi.intra. backup.akarmi.intra. syslog.akarmi.intra. samba.akarmi.intra. proxy.akarmi.intra. mail.akarmi.intra. dns.akarmi.intra. fw.akarmi.intra.
Állítsuk be a létrehozott fájlok jogosultságait és tulajdonosait: # chmod 640 /var/cache/bind/belso* # chown root:bind /var/cache/bind/belso*
Némi magyarázat ahhoz, hogy mit is jelentenek a fájlok elején a számsorok.
2007022001
Serial. Ez egy egyszer¶ sorszám, amelyet lehetne más formában használni (pél-
dá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
5
Önkényesen választottam ezt a fájlnevet.
2009. március 23.
Kósa Attila
Debian GNU/Linux
22
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.
86400
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).
900
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.
604800
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.
86400
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 szer-
/etc/init.d/bind9 start
verrel, csak el kell indítanunk a
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
pa-
ranccsal, hogy gyel-e a megfelel® interfészeken.
2.2.2.
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 bind9
Itt is 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 (9.3.4-2) ... 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.
Ezt is állítsuk le a kongurálás id®szakára. # /etc/init.d/bind9 stop
Az azonos szoftverb®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 a kongurációs állományokat. A
resolv.conf
állomány így nézzen ki: search akarmi.intra nameserver 127.0.0.1 nameserver 192.168.10.253 nameserver 192.168.10.254
A
named.conf.options
fájlt másoljuk át, majd javítsuk ki a következ® módon.
acl belso_halozat { 192.168.10.0/24; }; server 192.168.10.253 { keys { titkos_kulcs; }; }; key titkos_kulcs { algorithm hmac-md5; secret "islfIxRey4p2Uedv9+Rhfw=="; }; options {
Kósa Attila
2009. március 23.
Debian GNU/Linux
23
directory "/var/cache/bind"; query-source address * port 53; forward only; forwarders { 192.168.10.254; }; check-names slave fail; check-names response warn; allow-transfer { none; }; allow-query { localhost; belso_halo; }; allow-recursion { localhost; belso_halo; }; auth-nxdomain no; listen-on-v6 { none; };
};
A néhány különbség magyarázata a következ®. A
check-names
opció esetén azért került
slave megadásra, mert nincsenek saját els®dleges zónái a másodlagos szerverünknek. Az allowtransfer opció pedig azért nem tartalmaz semmit (illetve a none paramétert), mert róla senki sem végezhet zónatranszfert. 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 { 192.168.10.253; }; file "belso.db"; allow-query { 127.0.0.1; 192.168.10.0/24; }; }; zone "10.168.192.in-addr.arpa" { type slave; masters port 53 { 192.168.10.253; }; file "belso-rev.db"; allow-query { 127.0.0.1; 192.168.10.0/24; }; };
Mondhatni, hogy készen is vagyunk, hiszen a
named.conf fájlt ezen a gépen is változatlanul
hagyhatjuk. Indítsuk el: # /etc/init.d/bind9 start
A másodlagos szerver elindításakor azt fogjuk látni a logokban (az els®dleges szerveren), ahogy lekéri az els®dleges szervert®l a zónákat (a titkos kulcs segítségével): Mar Mar Mar Mar
23 23 23 23
14:57:49 14:57:49 14:57:50 14:57:50
2.3.
dns dns dns dns
named[2501]: named[2501]: named[2501]: named[2501]:
client client client client
192.168.10.252#4550: 192.168.10.252#4550: 192.168.10.252#2465: 192.168.10.252#2465:
transfer transfer transfer transfer
of of of of
'akarmi.intra/IN': AXFR started: TSIG titkos_kulcs 'akarmi.intra/IN': AXFR ended '10.168.192.in-addr.arpa/IN': AXFR started: TSIG titkos_kulcs '10.168.192.in-addr.arpa/IN': AXFR ended
Adminisztrációs eszközök a
BIND9 -hez
Telepítsük fel a szükséges csomagot: # apt-get install dnsutils
2.3.1. A
named-checkconf
named.conf, a named.conf.local és a named.conf.options fájlok szintaktikai ellen®rzésére
szolgál. Használata: # # 0 # 0 # 0
cd /etc/bind named-checkconf named.conf ; echo $? named-checkconf named.conf.local ; echo $? named-checkconf named.conf.options ; echo $?
Ha minden rendben van, akkor semmilyen választ nem látunk a képerny®n (a parancs visszatérési értéke 0, ezt írattuk ki az
2009. március 23.
echo $?
parancs segítségével).
Kósa Attila
Debian GNU/Linux
24
2.3.2.
named-checkzone
Szintaktikai ellen®rzést végez, valamint a fájlok konzisztenciáját ellen®rzi. # cd /var/cache/bind # named-checkzone akarmi.intra belso.db zone akarmi.intra/IN: loaded serial 2007032101 OK # named-checkzone 10.168.192.in-addr.arpa belso-rev.db zone 10.168.192.in-addr.arpa/IN: loaded serial 2007032101 OK
2.3.3.
rndc
A remote name daemon control (távoli név démon ellen®rzés) névb®l származik a program neve:
rndc.
Hozzáférést biztosít egy távoli névszerverhez, és parancsok kiadását teszi lehet®vé.
Használata: rndc [-c config] [-s server] [-p port] [-y key] command [command...]
A következ® parancsokat lehet használni:
• reload
Újra betölti a kongurációs állományokat és a zónafájlokat.
• reload
zone [class [view]]
• refresh
Újra betölti az adott zónát.
zone [class [view]]
• reconfig
Frissíti a megadott zónákat.
Újra betölti a kongurációs állományokat és betölti az új zónákat. De nem
tölti újra a létez® zónákat, ha azok nem változtak. Ez gyorsabb megoldás, mint az összes zóna újratöltése, ennek nagy számú zóna használata esetén láthatjuk az el®nyeit.
• stats
Kiírja a szerver statisztikát a
named.run
nev¶ fájlba, amely a
/var/cache/bind
könyvtárban található.
• querylog A parancs els® kiadásakor be-, a második kiadásakor kikapcsolja a lekérdezések loggolását. Alapértelmezésben a syslog-ba kerülnek az üzenetek.
• dumpdb Kiírja a szerver gyorsítótárának a tartalmát a named_dump.db nev¶ fájlba, amely a /var/cache/bind könyvtárban található. • stop
Leállítja a szolgáltatást. Minden változtatás (dinamikus update és IXFR esetén)
el®ször mentésre kerül a megfelel® zónafájlba.
• halt Leállítja a szolgáltatást. A változtatások (dinamikus update és IXFR) nem kerülnek mentésre a zónafájlokba, de a journal fájlból visszajátszásra kerülnek a szolgáltatás újraindításakor.
• trace
Növeli a szerver debug szintjét eggyel.
• trace
level
• notrace • flush
Beállítja a szerver debug szintjét a megadott értékre.
Beállítja a szerver debug szintjét 0-ra.
Kiüríti a szerver gyorsítótárát.
• status
Kiírja a képerny®re a szerver állapotinformációit.
Használatához szükséges egy kongurációs fájl. A szerverrel folytatott minden kommunikáció digitálisan aláírottan zajlik egy megosztott kulcs segítségével, és a szerver ennek a kulcsnak a segítségével azonosítja a klienst. Ez a titkos kulcs a
rndc.key fájlban található (a telepítéskor generálódik az rndc-confgen -a parancs segítségével).
Kósa Attila
/etc/bind
könyvtárban, a
automatikusan, de újra lehet generálni
2009. március 23.
Debian GNU/Linux
25
A kommunikáció alapértelmezésben a 953-as porton zajlik, erre a csomagsz¶r® beállításánál oda kell gyelnünk, de alapértelmezésben csak a localhoston gyel, tehát kívülr®l nem lehet elérni ezt a szolgáltatást. Most az
rndc.key nev¶ fájlt használjuk az rndc kongurációs állományaként. Alapértelme-
zésben mindössze ennyit tartalmaz (a
secret
opció utáni rész véletlenszer¶en el®állított):
key "rndc-key" { algorithm hmac-md5; secret "c63Vt1syLt6eLTz0h2gM6g=="; };
Ez lehet®vé teszi a lokálisan futó szolgáltatás elérését mindenféle kapcsoló használata nélkül: # rndc status number of zones: 6 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/1000 tcp clients: 0/100 server is up and running
2.4.
A DNS tesztelésére használható eszközök
2.4.1. A
dig
dig egy parancssoros eszköz, amely információkat képes gy¶jteni a DNS-szerverekt®l. Két
üzemmódja van, egy egyszer¶ interaktív mód, amely egyszerre egy kérést tesz lehet®vé, illetve az úgynevezett batch mód, amelyben egy listában sorolhatjuk fel a kéréseket, amelyeket végre kell hajtania. Minden lekérdezési opció elérhet® a parancssorból. dig [@server] domain [query-type] [query-class] [+query-option] [-dig-option] [%comment]
Az összes opcióról a
2.4.2.
dig
manual oldala nyújt leírást.
host
Egy egyszer¶ DNS lekérdézést lehet®vé tev® parancssoros eszköz. Alapértelmezésben konvertál a gépnevek és az IP címek között. host [-aCdlrTwv] [-c class] [-N ndots] [-t type] [-W timeout] [-R retries] hostname [server]
Az összes opcióról a
2.4.3.
host
manual oldala nyújt leírást.
nslookup
DNS szerverek lekérdezésére használható parancssoros eszköz. Két üzemmódja van: az interaktív és a nem interaktív. Interaktív módban lehet®vé teszi a felhasználónak, hogy lekérdezéseket intézzen a névszerverhez gépekkel, domain-ekkel és címekkel kapcsolatban. Nem interaktív módban csak kiírja a neveket és a kért információkat a gépr®l vagy a domain-r®l. nslookup [-option...] [host-to-find | - [server]]
A
dig
használata javasolt az
2009. március 23.
nslookup
helyett.
Kósa Attila
Debian GNU/Linux
26
2.5.
A többi szerver DNS beállítása
A dns szervereken és a t¶zfalon kívüli szerverek
/etc/resolv.conf
fájljainak a tartalma a
következ®: search akarmi.intra nameserver 192.168.10.253 nameserver 192.168.10.252
A dhcp-vel IP címet kapó gépek a dhcp szervert®l megkapják az aktuális beállításokat a névfeloldást végz® szerverekre vonatkozóan.
Kósa Attila
2009. március 23.
3. fejezet
DHCP
Célunk az, hogy a gépeknek központi helyr®l küldjük ki a hálózati beállításokat (amelyek akár gépenként különböz®ek is lehetnek).
3.1.
dhcp
Telepítsük fel azt a szoftvert, amely szükséges ahhoz, hogy a kívánt célt elérjük. Ne felejtsük el azonban, hogy ennek a szoftvernek kerneltámogatásra is szüksége van, egészen pontosan a
CONFIG_FILTER
és a
CONFIG_PACKET
opciókra (ezek hiányát beleírja a logokba).
# apt-get install dhcp Setting up dhcp (2.0pl5-19.5) ... Generating /etc/default/dhcp... Please note that if you are installing the DHCP server for the first time you need to configure it first. Please stop (/etc/init.d/dhcp stop) the DHCP server daemon, edit /etc/dhcpd.conf to suit your needs and particular configuration, and restart the DHCP server daemon (/etc/init.d/dhcp start). You also need to edit /etc/default/dhcp to specify the interfaces dhcpd should listen to. By default it listens to eth0. NOTE: dhcpd's messages are being sent to syslog. Look there for diagnostics messages. Starting DHCP server: dhcpd failed to start - check syslog for diagnostics.
Megpróbálja elindítani a szolgáltatást, de mivel a csomaggal érkez® kongurációs állomány nem a mi hálózatunknak megfelel® beállításokat tartalmaz, ezért nem indul el. A
/etc/dhcpd.conf fájl maga a kongurációs állomány, de találunk a /etc/default könyv-
tárban is egy fájlt (dhcp néven), amelyben azt tudjuk beállítani, hogy melyik interfészen gyeljen a szerver (több interfész is megadható).
A csomag telepítésekor felkerül® állományt eltehetjük emlékbe, írjunk helyette rögtön egy másikat, amely az alábbiakat tartalmazza. server-identifier dns.akarmi.intra; subnet 192.168.10.0 netmask 255.255.255.0 { authoritative; default-lease-time 21600; max-lease-time 43200; option subnet-mask 255.255.255.0; option broadcast-address 192.168.10.255; option routers 192.168.10.254; option domain-name-servers 192.168.10.253, 192.168.10.252; option domain-name "akarmi.intra"; option netbios-node-type 8; option netbios-name-servers 192.168.10.249; deny unknown-clients;
}
host kliens1 { hardware ethernet 00:50:8b:de:2d:f8; fixed-address 192.168.10.10; }
27
Debian GNU/Linux
28
server-identier opciót annak a gépnek a teljes neve kell kövesse, amelyen a szolgáltatás subnet meghatározza (a netmask -kal együtt) azt a címtartományt, amelyb®l a címeket osztani fogjuk. A lease-time opciók a bérleti szerz®désre vonatkoznak, arra, hogy mennyi A
fut. A
ideig érvényesek azok az adatok, amelyeket a szerver átadott a klienseknek (másodpercben meghatározva). Ha nem vagyunk authoritative-ek a hálózatra, akkor az ismeretlen kliensekt®l
unknown-clients opció) érkez® kérésekre nem ad semmilyen választ, és nem biztos, hogy ezt authoritative opció hatására az ismeretlen klienseknek a szerver egy DHCPNAK üzenetettel megtiltja a további próbálkozást. A default-lease-time a bérlet lejárati idejét határozza meg másodpercben, ha a kliens nem kér speciális lejárati id®t. A max-lease-time a bérlet
(
akarjuk. Az
maximális id®tartamát határozza meg, ennek lejártakor a kliensnek mindenképpen újra kell kérnie a szervert®l az adatokat. Az
option
kulcsszóval kezd®d® sorok elég beszédesek, de azért
szaladjunk végig a jelentésükön.
•
subnet-mask
•
broadcast-address
•
routers
•
domain-name-servers
•
domain-name
•
netbios-node-type
az alkalmazott alhálózati maszk; a hálózat broadcast címe;
az alapértelmezett átjáró (default gateway) címe; a névszerver(ek) címei;
a tartomány neve; a windowsos gépek miatt szükséges opció, a hálózati kommunikáció-
jukat lehet befolyásolni a
•
netbios-name-servers
segítségével (b®vebben a 7.1.3. fejezetben);
a WINS szerver címe, ugyancsak a windowsos gépek miatt (bár
Windows 2000-t®l már tudnak tisztán IP alapon is m¶ködni). A
deny unknown-clients
opció arra szolgál, hogy az azonosítatlan klienseket, akiknek nincs
a mac address-e (hardware ethernet sor a fenti példában) rögzítve a kongurációs állományban, nem szolgálja ki, tehát nem ad nekik IP címet. Ezzel biztosíthatjuk, hogy csak az általunk ismert gépek kaphatnak IP címet a dhcp szervert®l. Viszont nem szabad elfelejtenünk, hogy ez nem tekinthet® védelemnek, mert minden operációs rendszer lehet®séget nyújt (megfelel® jogosultságokkal rendelkez® felhasználó számára) a hálózati kártya azonosítójának (mac address-ének) az átírására, ezáltal bármelyik gép felveheti bármelyik ismert azonosítót, és így fordulhat a dhcp szerverhez IP címért (amely ezután problémázás nélkül ki is fogja szolgálni, azaz fog neki IP címet adni). Egy másik megoldás ennek a védelemnek a kikerülésére (amelyre szintén minden operációs rendszerben van lehet®ség), ha x IP címet állítanak be egy gépnek, tehát nem is igényelnek a dhcp szervert®l IP címet. Egyes switchek lehet®séget nyújtanak arra, hogy portonként beállíthassuk, hogy milyen mac address-¶ hálózati kártya kommunikálhat az adott porton, de ennek a kifejtése túllépi ezen anyag határait.
3.2.
dhcp3-server
Telepítsük fel azt a szoftvert, amely szükséges ahhoz, hogy a kívánt célt elérjük. # apt-get install dhcp3-server Setting up dhcp3-server (3.0.4-13) ... Generating /etc/default/dhcp3-server... Starting DHCP server: dhcpd3 failed to start - check syslog for diagnostics. invoke-rc.d: initscript dhcp3-server, action "start" failed.
Megpróbálja elindítani a szolgáltatást, de mivel a csomaggal érkez® kongurációs állomány nem a mi hálózatunknak megfelel® beállításokat tartalmaz, ezért nem indul el.
Kósa Attila
2009. március 23.
Debian GNU/Linux A
29
/etc/dhcp3/dhcpd.conf fájl maga a kongurációs állomány, de találunk a /etc/default
könyvtárban is egy fájlt (dhcp3-server néven), amelyben azt tudjuk beállítani, hogy melyik interfészen gyeljen a szerver (több interfész is megadható).
A csomag telepítésekor felkerül® állományt eltehetjük emlékbe, írjunk helyette rögtön egy másikat, amely az alábbiakat tartalmazza. server-identifier dns.akarmi.intra; subnet 192.168.10.0 netmask 255.255.255.0 { authoritative; default-lease-time 21600; max-lease-time 43200; option subnet-mask 255.255.255.0; option broadcast-address 192.168.10.255; option routers 192.168.10.254; option domain-name-servers 192.168.10.253, 192.168.10.252; option domain-name "akarmi.intra"; option netbios-node-type 8; option netbios-name-servers 192.168.10.249; deny unknown-clients; host kliens1 { hardware ethernet 00:50:8b:de:2d:f8; fixed-address 192.168.10.10; }
}
server-identier opciót annak a gépnek a teljes neve kell kövesse, amelyen a szolgáltatás subnet meghatározza (a netmask -kal együtt) azt a címtartományt, amelyb®l a címeket osztani fogjuk. A lease-time opciók a bérleti szerz®désre vonatkoznak, arra, hogy mennyi A
fut. A
ideig érvényesek azok az adatok, amelyeket a szerver átadott a klienseknek (másodpercben meghatározva). Ha nem vagyunk authoritative-ek a hálózatra, akkor az ismeretlen kliensekt®l
unknown-clients opció) érkez® kérésekre nem ad semmilyen választ, és nem biztos, hogy ezt authoritative opció hatására az ismeretlen klienseknek a szerver egy DHCPNAK üzenetettel megtiltja a további próbálkozást. A default-lease-time a bérlet lejárati idejét határozza meg másodpercben, ha a kliens nem kér speciális lejárati id®t. A max-lease-time a bérlet (
akarjuk. Az
maximális id®tartamát határozza meg, ennek lejártakor a kliensnek mindenképpen újra kell kérnie a szervert®l az adatokat. Az
option
kulcsszóval kezd®d® sorok elég beszédesek, de azért
szaladjunk végig a jelentésükön.
•
subnet-mask
•
broadcast-address
•
routers
•
domain-name-servers
•
domain-name
•
netbios-node-type
az alkalmazott alhálózati maszk; a hálózat broadcast címe;
az alapértelmezett átjáró (default gateway) címe; a névszerver(ek) címei;
a tartomány neve; a windowsos gépek miatt szükséges opció, a hálózati kommunikáció-
jukat lehet befolyásolni a
•
netbios-name-servers
segítségével (b®vebben a 7.1.3. fejezetben);
a WINS szerver címe, ugyancsak a windowsos gépek miatt (bár
Windows 2000-t®l már tudnak tisztán IP alapon is m¶ködni). A
deny unknown-clients
opció arra szolgál, hogy az azonosítatlan klienseket, akiknek nincs
a mac address-e (hardware ethernet sor a fenti példában) rögzítve a kongurációs állományban, nem szolgálja ki, tehát nem ad nekik IP címet. Ezzel biztosíthatjuk, hogy csak az általunk ismert gépek kaphatnak IP címet a dhcp szervert®l. Viszont nem szabad elfelejtenünk, hogy ez nem tekinthet® védelemnek, mert minden operációs rendszer lehet®séget nyújt (megfelel® jogosultságokkal rendelkez® felhasználó számára) a hálózati kártya azonosítójának (mac address-ének) az átírására, ezáltal bármelyik gép felveheti bármelyik ismert azonosítót, és így fordulhat a dhcp szerverhez IP címért (amely ezután problémázás nélkül ki is fogja szolgálni, azaz fog neki IP címet adni). Egy másik megoldás ennek a
2009. március 23.
Kósa Attila
Debian GNU/Linux
30
védelemnek a kikerülésére (amelyre szintén minden operációs rendszerben van lehet®ség), ha x IP címet állítanak be egy gépnek, tehát nem is igényelnek a dhcp szervert®l IP címet. Egyes switchek lehet®séget nyújtanak arra, hogy portonként beállíthassuk, hogy milyen mac address-¶ hálózati kártya kommunikálhat az adott porton, de ennek a kifejtése túllépi ezen anyag határait.
Kósa Attila
2009. március 23.
4. fejezet
Id®szinkron
Több okból is szükség van arra, hogy a bels® hálózat gépeinek (mind a szervereknek, mind a munkaállomásoknak) az órái szinkronban legyenek egymással.
•
A titkosított kapcsolatok nem szeretik, ha az id® jelent®sen eltér egymástól a kapcsolatban részt vev® gépeken. Ez akár azt is okozhatja, hogy nem is képesek egymással a titkosított kapcsolatot létrehozni.
•
Bármit szeretnénk visszakeresni a logokban, megkönnyíti a dolgunkat, ha egyformán járnak a gépek órái.
4.1.
ntp
A telepítés egyszer¶: # apt-get install ntp
Nem látható a telepítés alatt (csak a logokban), hogy a csomag létrehoz egy
ntp
nev¶
csoportot, és egy ugyanilyen nev¶ felhasználót is. Elindításakor ezeknek a nevében fog futni a szolgáltatás, nem a
root
felhasználó jogosultságaival.
A kongurációs állomány a egy
ntp
/etc/ntp.conf
fájl, illetve a
/etc/default
könyvtárban van
nev¶ állomány. Ez utóbbi mindössze egyetlen sort tartalmaz a telepítés után:
NTPD_OPTS='-g'
Az általunk használt kongurációs állomány: driftfile /var/lib/ntp/ntp.drift statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable server 192.168.10.254 server 127.127.1.0 fudge 127.127.1.0 stratum 13 restrict default kod notrap nomodify nopeer noquery restrict 127.0.0.1 nomodify
Ténylegesen sokkal több opció létezik, illetve a szerepl® opcióknak is több kapcsolója van, de most csak a fentiek magyarázatára térünk ki.
driftle
Ebben a fájlban tárolja az
ntp
démon, hogy az els® elindulásakor a számítógép bels®
frekvenciájának mennyi a hibája. Körülbelül 1 napig tart az elindítása után, amíg egy jó becslést kiszámít, és ily módon közel kerül a szinkronizáláshoz használt szerver idejéhez. Ezt a fájlt használja arra, hogy a démon újraindítása esetén újra inicializálja saját magát, és így el tudja kerülni azt, hogy újra 1 napig tartson a becslés kiszámítása.
31
Debian GNU/Linux
32
statsdir
Egy könyvtár teljes elérési útvonalát határozza meg, ahol a statisztikai fájlokat tárolni
fogja a rendszer.
statistics
Engedélyezi statisztikai adatok írását. Jelenleg 6 különböz® statisztika támogatott.
clockstats Az óra statisztikai információi. loopstats A loop lter statisztikai információi. peerstats Az egyéb ntp szerverekkel kapcsolatos statisztikai információk (magában foglalja a kongurált speciális szignálokat is).
legen
Egy adott sor meghatározza, hogy milyen típusú adatot mikor és hová kell írni. A
régi adatokat (fájlokat) el lehet távolítani, mert csak adminisztrációs szempontból van jelent®ségük, az
server fudge
ntp
csak az aktuális fájlokat használja.
A szinkronizáláshoz használt time szerver neve vagy IP címe. Arra használatos, hogy plusz információt szolgáltasson az egyéni órairányítók számára.
A
stratum
opció használható az eszköz alapértelmezésének felülírására.
Egy referenciaórának a stratum száma alapértelmezésben nulla. Az
ntp
minden egyes
szerver stratumához (amelyekhez ® szinkronizál) hozzáad egyet. 15 fölötti stratum esetén már nem használják szinkronizálásra, mert túlságosan pontatlan lenne.
restrict
Az alapértelmezett bejegyzés (IP cím: 0.0.0.0, netmaszk 0.0.0.0) mindig benne van, és
mindig a listának az els® tagja. Tehát az els®
restrict
bejegyzés mindig erre vonatkozik.
A további bejegyzéseknél megadhatjuk (IP címmel vagy DNS névvel) a korlátozandók listáját. Ha nincs
restrict
sor a kongurációs állományunkban, akkor nincs semmilyen
korlátozás a szolgáltatás elérését tekintve. A korlátozásokat két csoportra lehet osztani, az egyik, amely az id®szolgáltatás elérését korlátozza, a másik pedig a szervert®l kérhet® információkat, valamint a szerver futási id®ben történ® újrakongurálását.
ignore
Minden csomagot gyelmen kívül hagy, beleértve az
ntpq
és az
ntpdc
lekérdezé-
seket is.
kod
Ha ez a jelz® be van állítva amikor egy szabálytalan elérési próbálkozás történik, akkor egy KoD (kiss-o'-death a halál csókja) csomagot fog küldeni a szerver. Ezen csomagok száma másodpercenként egyre van korlátozva.
nomodify
Megakadályozza, hogy az
ntpq
és az
ntpdc
segítségével változtatni lehessen
a kongurációs beállításokon, tehát futás közben nem lehet átállítani a szervert. Az ezekkel a parancsokkal történ® lekérdezést azonban nem tiltja meg.
noquery Letiltja az ntpq és az ntpdc kéréseit. Ez magát a szolgáltatást nem érinti. nopeer Elutasítja azokat a csomagokat, amelyek új szervert vennének fel. notrap A trap szolgáltatás elérését tiltja. A fentiek ismeretében lássuk, pontosan mit is jelent az elkészített kongurációs állományunk.
/var/lib/ntp/ntp.drift fájl van beállítva driftle -ként (azaz ott tárolja az adatokat). A statisztikák tárolására a /var/log/ntpstats/ könyvtár van megadva. 3 statisztika készüljön,
A
naponta egy, a statisztikák nevének megfelel® fájlba kerüljenek (az el®z®leg megadott könyvtárban). 2 szerver van beállítva. A bels® szerverünk. A
127.127.1.0
192.168.10.254
a t¶zfalunk IP címe, ahhoz szinkronizál a
cím¶ szerver az saját magát, a lokális gép óráját jelenti. A
saját órájához 13 van beállítva stratumként (az egyszer¶ség kedvéért nevezzük pontosságnak, bár nem egészen fedi ez a kifejezés a valóságot). Ez arra jó, hogy ha nem tud a távoli szerverhez szinkronizálni, akkor is tud id®t szolgáltatni a kliensek (és a szerverek) számára. És végül két korlátozás szerepel még a kongurációs állományban.
Kósa Attila
2009. március 23.
Debian GNU/Linux
4.1.1.
33
A szolgáltatás ellen®rzése
Több lehet®ségünk is van a szolgáltatás m¶ködésének az ellen®rzésére. A legegyszer¶bb az
ntpdate használata (ehhez el®ször természetesen telepítenünk kell az ntpdate csomagot). Ezzel egyszer¶en megpróbáljuk elérni a szervert: # ntpdate -q -v time 8 Nov 15:54:39 ntpdate[1213]: ntpdate 4.2.0a@1:4.2.0a+stable-2-r Fri Aug 26 10:30:13 UTC 2005 (1) server 192.168.10.253, stratum 5, offset 0.000004, delay 0.02568 8 Nov 15:54:39 ntpdate[1213]: adjust time server 192.168.10.253 offset 0.000004 sec
Egy másik lehet®ség az
ntpq
használata. Ha úgy indítjuk, hogy
ntpq,
akkor egy
ntpq>
promptot kapunk, ahol a ? (kérd®jel) segítségével juthatunk a használható parancsok listájához. Ugyanezeket a parancsokat használhatjuk az a
-c
ntpq másik indítási módjánál is: ntpq -c ?. Tehát
parancssori opció után adhatjuk meg a használható parancsokat. Például a
readvar
opció
hatására a következ® adatokat kapjuk: # ntpq -c readvar assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg, version="ntpd [email protected] Sun Mar 4 13:21:35 UTC 2007 (1)" processor="i686", system="Linux/2.6.18-4-686", leap=00, stratum=5 precision=-20, rootdelay=25.092, rootdispersion=379.947, peer=29110, refid=192.168.10.254, reftime=c9b22e22.81d92a97 Mon, Mar 26 2007 13:33:54.507, poll=6, clock=c9b22fea.083a1008 Mon, Mar 26 2007 13:41:30.032, state=4, offset=122.694, frequency=38.028, jitter=140.360, noise=43.379, stability=13.445, tai=0
Itt látható, hogy miért ajánlatos letiltani az NTP szerverünk
ntpq
segítségével történ® el-
érését. Hiszen még a használt szoftver és kernel verziója is megjelenik az üzenetben, amely a legtöbb esetben nem publikus információ. A harmadik lehet®ség az
ntpdc
4.2.
ntpq parancshoz hasonlóan m¶ködik. ntpdc -c ? parancs segítségével kaphatjuk meg.
használata, amely az
A lekérdezéshez használható opciókat ennél az
ntpdate
Arra szolgál, hogy a gép óráját egy id®kiszolgálóhoz szinkronizálja. El®ször telepítsük fel: # apt-get install ntpdate
Egyetlen kongurációs állománya van, a
/etc/default/ntpdate fájl. A fájl a telepítés után
az alábbiakat tartalmazza (a kommenteket kihagytam): NTPDATE_USE_NTP_CONF=yes NTPSERVERS="0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org" NTPOPTIONS=""
Az
NTPOPTIONS
opciónál sorolhatjuk fel az
ntpdate
parancssori kapcsolóit. Ezek közül
az alábbi hármat látom én célszer¶nek használni:
s
Alapértelmezésben a standard kimenetre küldi üzeneteit az
ntpdate, de ett®l a kapcsolótól a
syslog-ba fognak bekerülni az üzenetek.
u
E nélkül a kapcsoló nélkül az
ntpdate a 123-as (privilegizált) portot akarja használni. Ha fut
egy NTP szerver a gépen, akkor ez nem fog neki sikerülni, és az alábbi hibaüzenetet adja:
the NTP socket is in use, exiting.
v
B®beszéd¶bbé válik t®le az
ntpdate, kiírja, hogy mennyi volt az id®eltérés a szinkronizálásra
használt szervert®l. Végeredményben így fog kinézni a
/etc/default/ntpdate
állományunk:
NTPDATE_USE_NTP_CONF=no NTPSERVERS="time" NTPOPTIONS="-vus"
2009. március 23.
Kósa Attila
Debian GNU/Linux
34
ntpdate csak a rendszer indulásakor fut le automatikusan. Ha nem csak ilyenkor szeretcron segítségével elindítani. Ehhez a /etc/cron.d 1 könyvtárba helyezzünk el egy ntpdate nev¶ fájlt az alábbi tartalommal: Az
nénk futtatni, akkor kénytelenek vagyunk a
MAILTO="" 15 * * * *
A
root
/usr/sbin/ntpdate-debian -s -b >/dev/null
MAILTO
sor hatására a
cron
nem fog levelet küldeni a parancs végrehajtásáról. A kö-
vetkez® sor hatására pedig minden óra 15 perckor fogja futtatni a szinkronizáláshoz szükséges parancsot.
4.2.1.
ntpdate az NTP szerveren
A time (igazi nevén dns) gépen másképp fog kinézni, mivel neki a t¶zfalon futó NTP szerverhez kell szinkronizálnia, illetve rá fel van telepítve az
/etc/ntp.conf
ntp
csomag, ily módon elérhet®vé válik a
fájl (és abból fogja venni az információt, hogy mely szerverhez kell szinkroni-
zálnia, nem az itt látható
NTPSERVERS
opcióból):
NTPDATE_USE_NTP_CONF=yes NTPSERVERS="0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org" NTPOPTIONS="-u -v -s"
4.3.
4.3.1.
Windows alatti NTP beállítások
Windows 2000
Picit nehézkesen érhet® el a kattintgatásokhoz szokott felhasználóknak az id®szinkronizáció beállítása. A parancssor szerelmesei viszont örülni fognak az egyszer¶ségnek. Készítenünk kell egy olyan fájlt, amelyet majd be tudunk importálni a registry-be. A következ®ket kell tartalmazni ennek a fájlnak (az egyszer¶ség kedvéért legyen
ntp_2000.reg
a neve):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters "LocalNTP"=dword:00000000 "Period"="SpecialSkew" "type"="NTP" "NtpServer"="time.akarmi.intra"
Ezt a fájl felrakhatjuk a fájlszerverünk egy megosztásába, majd importálnunk kell, és újraindítani a megfelel® szolgáltatást (kérjünk egy command promptot a Futtatás menüpont segítségével, és oda gépeljük az alábbiakat rendszergazdai jogok szükségesek az óra beállításához és a szolgáltatás újraindításához!): C:\ regedit /s \\samba\megosztas_neve\ntp_2000.reg C:\ net stop w32time && net start w32time
4.3.2.
Windows XP
Sajnos a Windows ezen verziójában már nagyon sok minden tartozik ezen szolgáltatáshoz a regisrty-ben, ezért nem tudok a fentieknek megfelel®en egy egyszer¶
.reg
fájlt ajánlani.
Így kénytelenek vagyunk kattintgatva beállítani a szinkronizálást. Természetesen ha azonos Windows-aink vannak, akkor az els® elkészített gépen exportálhatjuk a megfelel® registry kulcsot, és attól kezdve használhatjuk a parancssort az importálásra, valamint a szolgáltatás újraindítására. Adminisztrátor jogosultságokkal lépjünk be, majd a tálcán látható órára kattintsunk kett®t. Erre meg kell jelennie egy ablaknak, amelynek a harmadik fülén az Itt egy mez®ben látható a
nevet, majd kattintsunk az a
Azonnali frissítés 1
Internet-id®
felirat látható.
time.windows.com név. Ennek a helyére írjuk be a time.akarmi.intra
Alkalmaz
gombra. Ezután kipróbálhatjuk az azonnali szinkronizálást
gombra kattintva, majd az
OK
gombra kattintva befejezhetjük a beállítást.
Önkényesen választottam ezt a nevet.
Kósa Attila
2009. március 23.
5. fejezet
Biztonság
Azért van szükségünk az egyes hálózati forgalmak titkosítására, hogy érzékeny adatokat is biztonságosan tudjunk átjuttatni a bárki által elérhet® hálózaton keresztül. Jellemz®en ilyen érzékeny adatok a felhasználói név és jelszó párosok. Emiatt célszer¶ titkosítással ellátni azokat a szolgáltatásokat, amelyek ezen két adattal dolgoznak. A Bibliográában szerepl® ([1]) anyagban részletes leírást találunk a tanúsítványokról, valamint érdekes példákat a használatukra.
1
A különböz® szolgáltatásokhoz szükséges titkosítás el®állításáról , valamint az ssh-n keresztüli távoli adminisztrációról lesz szó ebben a fejezetben. Nem szabad elfelejtenünk, hogy ha saját CA-t készítünk, és ezen CA-val írjuk alá a szervereink tanúsítványait, akkor ezen CA-nak a tanúsítványát el kell helyeznünk a megfelel® helyeken. Ha egy webszerverhez generálunk kulcsot, akkor a munkaállomás böngész®jének is a tudomására kell hoznunk, hogy miképpen tudja ellen®rizni a webszerver tanúsítványát. Erre azonban csak a CA tanúsítványának ismeretében lesz képes! Tehát ha a kliens nem rendelkezik a CA tanúsítványával, akkor nem fogja tudni ellen®rizni a webszerver tanúsítványát. Alapesetben ez annyit fog jelenteni, hogy minden böngész® gyelmeztetni fogja a felhasználót, hogy a webszerver tanúsítványát nem tudja ellen®rizni. Ekkor a felhasználók jelent®s része arra a gombra kattint, amelynek segítségével tovább léphet. . .
2
Mivel a felhasználó legtöbbször gondolkodás nélkül kattint a minél gyorsabb továbblépés érdekében, az is el®fordulhat, hogy egy támadó hasonló weboldalt és tanúsítványokat állít el® mint a valódiak, majd az általa elkészített oldalra irányítva (vagy csalva) a klienseket ily módon értékes adatokhoz jut. Ha azonban a kliens rendelkezik a valódi CA tanúsítványával, akkor azonnal reklamálnia kell az alkalmazott szoftvernek, hogy nem egyezik a tanúsítvány, így a támadó nem jár sikerrel.
5.1.
SSL
El®ször fel kell telepítenünk a szükséges csomagot: # apt-get install openssl
Ezután hozzunk létre egy könyvtárat, amely védett helyen van, tehát a felhasználók nem férhetnek hozzá, majd lépjünk bele, és ebben a könyvtárban végezzük a következ® feladatokat. # echo "01" > serial # touch index.txt
1 2
Az egyes alkalmazások emiatti kongurációs igényeir®l az adott alkalmazásról szóló fejezetben esik szó. Ugyanez igaz a levelezést kezel® szerverünkre, tehát a levelek eléréséhez használt alkalmazásnak is meg kell
adnunk a CA-nk tanúsítványát.
35
Debian GNU/Linux
36
5.1.1.
CA létrehozása
Hozzunk létre egy
CA.cnf
nev¶ fájlt az alábbi tartalommal, amely a CA-nk alapértelmezett
beállításait fogja tartalmazni. [ ca ] default_ca = CA_akarmi [ CA_akarmi ] dir = ./ certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir serial = $dir/serial database = $dir/index.txt certificate = $dir/CA.crt private_key = $dir/CA.key default_days = 365 default_crl_days = 30 default_md = md5 preserve = no policy = policy_anything [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] default_bits = 1024 encrypt_key = yes distinguished_name = req_dn x509_extensions = cert_type prompt = no [ cert_type ] nsCertType = server [ req_dn ] countryName = HU stateOrProvinceName = BAZ localityName = Miskolc organizationName = "Akarmi Kft" organizationalUnitName = CA_kiallito commonName = akarmi.intra emailAddress = [email protected]
Ezután nézzük meg, hogy pontosan milyen parancsokat is kell kiadnunk ahhoz, hogy saját CA-t hozzunk létre, amely 10 évig m¶ködik. # openssl req -set_serial 00 -passout "pass:CA_jelszo" -new -x509 -keyout CA.key -out CA.crt -days 3650 -config CA.cnf Generating a 1024 bit RSA private key ..++++++ ..............++++++ writing new private key to 'CA.key' -----
És már készen is van a saját CA-nk, amelyet 2 fájl is bizonyít: a
A
CA.key
CA.crt
és a
CA.key.
fájlra nagyon kell vigyáznunk, mert ha valaki hozzájut (és valahogyan kitalálja az
általunk adott jelszót, amely jelen esetben a CA_jelszo), akkor ugyanolyan tanúsítványokat (certicate-eket) tud létrehozni, mint mi magunk. Ne felejtsük el, hogy a
CA.crt
fájlt kell elér-
het®vé tennünk a kliensek számára, hogy képesek legyenek ellen®rizni az aláírt tanúsítványokat. Ehhez az ellen®rzéshez be kell importálniuk ezt a fájlt a böngész®be, valamint szükség esetén a levelez®programba. Ellen®rizzük le, hogy mi is található benne: # openssl x509 -serial -issuer -subject -dates -fingerprint -noout -in CA.crt serial=00 issuer= /C=HU/ST=BAZ/L=Miskolc/O=Akarmi Kft/OU=CA_kiallito/CN=akarmi.intra/[email protected] subject= /C=HU/ST=BAZ/L=Miskolc/O=Akarmi Kft/OU=CA_kiallito/CN=akarmi.intra/[email protected] notBefore=Mar 26 14:53:13 2007 GMT notAfter=Mar 23 14:53:13 2017 GMT SHA1 Fingerprint=E1:83:66:97:0D:33:2A:B6:8E:32:F4:32:28:61:F2:BD:45:7A:0F:92
5.1.2.
Tanúsítványok létrehozása
A tanúsítványokat nem szokás túlságosan hosszú id®re generálni, általában 1 évre szokták. Persze nem árt megjegyezni, hogy mikor fog lejárni, mert az azt használó alkalmazásoknál el®fordulhat,
Kósa Attila
2009. március 23.
Debian GNU/Linux
37
hogy nem fognak m¶ködni a tanúsítvány lejárta után. A tanúsítvány akkor is érvényét veszti, ha saját maga ugyan még érvényes lenne, ám az ®t aláíró CA lejár.
3
Mivel évente újra kell majd generálnunk az összes tanúsítványunkat , ezért érdemesnek t¶nik valamiképp automatizálni a feladatot. Ennek érdekében minden tanúsítványhoz hozzunk létre saját
.cnf
fájlt (amely neve megegyezik a tanúsítványban szerepl®
Példaként nézzük meg a
samba.akarmi.intra.cnf
commonName -mel).
fájl tartalmát.
[ req_dn ] countryName = HU stateOrProvinceName = BAZ localityName = Miskolc organizationName = "Akarmi Kft" organizationalUnitName = tanusitvany_generalo commonName = samba.akarmi.intra emailAddress = [email protected]
Nagyon fontos, hogy a
commonName
opciónál azt a nevet kell megadnunk, amely néven
meg fogják szólítani a szervert! # cat CA.cnf samba.akarmi.intra.cnf > atmeneti.cnf # openssl req -nodes -newkey rsa:1024 -config atmeneti.cnf -keyout samba.akarmi.intra.key.nopass -out samba.akarmi.intra.csr Generating a 1024 bit RSA private key .............................++++++ ...............++++++ writing new private key to 'samba.akarmi.intra.key.nopass' -----
Ennek hatására egy
samba.akarmi.intra.csr
és egy
samba.akarmi.intra.key.nopass
nev¶ fájllal lettünk gazdagabbak. Gyakorlatilag bármilyen neveket adhatunk ezeknek a fájloknak (miként a CA generálásakor is bármilyen neveket választhatunk a fájloknak), mégis érdemesebb beszédes neveket alkalmazni.
5.1.3.
Tanúsítványok aláírása
# openssl ca -passin "pass:CA_jelszo" -config atmeneti.cnf -out samba.akarmi.intra.pem -infiles samba.akarmi.intra.csr Using configuration from atmeneti.cnf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'HU' stateOrProvinceName :PRINTABLE:'BAZ' localityName :PRINTABLE:'Miskolc' organizationName :PRINTABLE:'Akarmi Kft' organizationalUnitName:T61STRING:'tanusitvany_generalo' commonName :PRINTABLE:'samba.akarmi.intra' emailAddress :IA5STRING:'[email protected]' Certificate is to be certified until Mar 25 15:22:26 2008 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated
az
Itt kétszer le kell nyomnunk az y billenty¶t válaszként a kérdésekre. Ha szkriptet írunk, akkor echo parancsra rá tudjuk bízni, hogy ezt végezze el helyettünk, és akkor nem kell gyelemmel
kísérnünk a számítógépet unalmas munkája elvégzésében. Ellen®rizzük le, hogy valóban sikerült-e aláírnunk a tanúsítványunkat: # openssl x509 -serial -issuer -subject -dates -fingerprint -noout -in samba.akarmi.intra.pem serial=01 issuer= /C=HU/ST=BAZ/L=Miskolc/O=Akarmi Kft/OU=CA_kiallito/CN=akarmi.intra/[email protected] subject= /C=HU/ST=BAZ/L=Miskolc/O=Akarmi Kft/OU=tanusitvany_generalo/CN=samba.akarmi.intra/[email protected] notBefore=Mar 26 15:22:26 2007 GMT notAfter=Mar 25 15:22:26 2008 GMT SHA1 Fingerprint=BF:81:A4:88:4B:B8:C0:64:C2:CA:3C:C5:2A:AF:3D:9E:6F:25:3C:D6
Néhány apróságot még el kell végeznünk miel®tt használatba vennénk újonnan elkészített tanúsítványunkat. # sed -e '/-----BEGIN CERT/,/-----END CERT/!d' < samba.akarmi.intra.pem > samba.akarmi.intra.crt # rm atmeneti.cnf
Igazából csak a többi állományt (a
3
.crt és a .key.nopass nev¶ fájlokra lesz szükségünk, akár le is törölhetjük a 01.pem, samba.akarmi.intra.csr és a samba.akarmi.intra.pem fájlokat).
Ha valóban csak 1 éves érvényességgel hoztuk létre ®ket.
2009. március 23.
Kósa Attila
Debian GNU/Linux
38
5.2.
ssh
Két csomagra bontották az ssh-t, az létrehoztak egy
ssh
openssh-server és az openssh-client csomagokra. Illetve
nev¶ csomagot, amely mindkett®t felteszi egyszerre. Tehát az alábbi két
parancs egyenérték¶ (ebb®l kifolyólag csak az egyikre van szükségünk): # apt-get install openssh-server openssh-client # apt-get install ssh
5.2.1.
Kulcsok generálása
Alapjában véve helytelen jelszó nélküli kulcsokat használni. De el®fordulhat olyan feladat, amelynek a megoldásához szükségünk van ilyen kulcsokra. Azonban ilyenkor mindig gondoljunk arra, hogy a jelszó nélküli kulcs illetéktelen kezekbe történ® kerülése esetén a miénkkel megegyez® jogkört biztosítunk a kulcsot megszerz®nek. Ezért mindig próbáljuk meg szerveroldalon korlátozni a kulcs használatát. Ennek a részletes dokumentációját a kiadása után az
authorized_keys
anyag 5.2.5. fejezetében
man 8 sshd parancs
fájl formátumáról szóló fejezetben találhatjuk meg, de ezen
(a 40. oldalon)
van szó az elérhet® opciókról.
Tehát generáljunk magunknak kulcsot, és tegyük fel az összes szerverre. Az interaktív használatra szánt kulcsunkat azonban mindenképpen jelszóval védjük (tehát az kérdésre adjunk meg jelszót)! Az
ssh-agent
Enter passphrase
használatakor ezt a jelszót kell majd megadnunk
(amellyel a kulcsunkat védtük). # ssh-keygen -b 1024 -f ~/.ssh/id_dsa -t dsa -C root@sajat Generating public/private dsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_dsa. Your public key has been saved in /root/.ssh/id_dsa.pub. The key fingerprint is: a5:8e:94:5b:c9:d1:63:0f:38:0a:22:3e:ce:d2:86:16 root@sajat
Az amdump használatához generáljunk backup nev¶ felhasználó kezelésébe:
a backup nev¶ gépen egy kulcsot, amelyet adjunk a
# mkdir /var/backups/.ssh # chmod 0750 /var/backups/.ssh # ssh-keygen -b 1024 -f /var/backups/.ssh/id_rsa_amdump -t rsa -C backup@backup_amdump Generating public/private dsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /var/backups/.ssh/id_rsa_amdump Your public key has been saved in /var/backups/.ssh/id_rsa_amdump.pub The key fingerprint is: bd:59:41:58:f6:4c:dc:3e:32:7f:f6:6f:33:e8:c2:ac backup@backup_amdump # chown -R backup:backup /var/backups/.ssh
Ne felejtkezzünk el a kulcs korlátozásáról (40. oldal)! Hogy az
amanda
használni is tudja majd a kulcsot, egy
tárolnunk azoknak a gépeknek a kulcsát, amelyekre
ssh-val
known_hosts
nev¶ fájlban el kell
be szeretne jutni a
felhasználónk. Ennek a legegyszer¶bb módja az, ha ezen felhasználó
ssh-val
backup
nev¶
belép ezekre a gé-
pekre, hiszen ekkor automatikusan eltárolódik ebben a fájlban a szerver kulcsa. Tehát mindössze ennyit kell tennünk: # su - backup $ ssh -i .ssh/id_rsa_amdump dns.akarmi.intra The authenticity of host 'dns.akarmi.intra (192.168.10.253)' can't be established. RSA key fingerprint is 58:35:7c:d2:d5:ad:5e:21:ec:a8:9b:5f:68:e6:35:95. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'dns.akarmi.intra,192.168.10.253' (RSA) to the list of known hosts.
Ehhez azonban el®ször oda kell másolnunk a publikus kulcsot a megfelel® gépre, hiszen a
backup
felhasználónknak nincs jelszava, így csak kulcs segítségével tud belépni, jelszóval nem.
Ugyanezt a két lépést meg kell tennünk az
amrecover
futtatása el®tt is!
A mentett adatok visszaállításához is generáljunk kulcsot (ezt minden szerveren meg kell tennünk!):
Kósa Attila
2009. március 23.
Debian GNU/Linux
39
# ssh-keygen -b 1024 -f .ssh/id_rsa_amrecover -t rsa -C root@backup_amrecover Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in .ssh/id_rsa_amrecover. Your public key has been saved in .ssh/id_rsa_amrecover.pub. The key fingerprint is: 00:37:df:7c:e4:7d:fd:5d:78:73:2d:89:a4:15:0e:6b root@backup_amrecover
Az így létrehozott kulcsot át kell másolnunk a backup nev¶ gépre, a
authorized_keys
5.2.2.
fájljába, és természetesen ezt is nagyon ajánlott
backup
felhasználó
korlátozni.
A kulcsok másolása
A legegyszer¶bb megoldás az
ssh-copy-id
parancs használata.
# ssh-copy-id -i ~/.ssh/id_dsa.pub user@gepnev
Sajnos az
ssh-copy-id
nem tud a 22-es porttól eltér® portra kapcsolódni, tehát ha ett®l
eltér® porton futó ssh szerverre szeretnénk a kulcsunkat átmásolni, akkor más megoldást kell keresnünk, például az alábbit: # cat ~/.ssh/id_dsa.pub | ssh -p 22222 gepnev "cat >> ~/.ssh/authorized_keys"
Tekintve, hogy a backup nev¶ felhasználónak nincsen jelszava, ezért nem tudjuk használni ssh-copy-id parancsot, hiába a 22-es porton gyel az ssh szolgáltatásunk. Ekkor is jól jön a másodikként bemutatott lehet®ség (csak ne a root authorized_keys fájljába tegyük a kulcsot, 4 hanem a backup felhasználóéba). az
5.2.3.
Az ssh szerver beállítása
Ha sikerült elhelyeznünk a kulcsunkat a szervereken, akkor állítsuk be úgy az
ssh
szervereket,
hogy csak kulcs használatával lehessen rájuk belépni, jelszóval ne. A telepítés után így néz ki a
/etc/ssh/sshd_config
fájlunk (a kommenteket kihagytam):
Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes
Ahhoz, hogy a jelszavas authentikáció ne legyen lehetséges (csak a kulcsos), ki kell egészítenünk a fentieket az alábbi sorral, majd újra kell indítanunk az
ssh
szolgáltatást:
PasswordAuthentication no # /etc/init.d/ssh restart
Azt mindenkinek magának kell eldöntenie, hogy engedélyezi-e a
ssh-n
PermitRootLogin
keresztül (
root-ként
való belépést
opció). Ha nem akarunk olyan grakus alkalmazást futtatni
a szerveren, amely a mi képerny®nkre rajzol, akkor célszer¶ az
X11Forwarding
opció
no-ra
állítása is.
4
Az
amanda-val
végzett mentés miatt szükséges.
2009. március 23.
Kósa Attila
Debian GNU/Linux
40
5.2.4.
Az ssh-agent használata
Az új X szerverek alapértelmezésben olyan kongurációval érkeznek, hogy az X-be belépéskor elindul az
ssh-agent
ssh-agent,
és így képes felügyelni a felhasználó összes ssh kapcsolatát. Ezt a
use-
/etc/X11/Xsession.options ki kell adnunk az ssh-add pa-
opcióval lehet bekapcsolni Xfree és Xorg alatt is (a
fájlban). Igy a belépés után egy tetsz®leges terminálablakban
rancsot, majd megadnunk az ssh kulcsainkhoz tartozó jelszavakat, és ezzel regisztráltuk is az
ssh-agent-nél a kulcsainkat. Ha nem id_rsa, id_dsa vagy identity néven tároljuk a kulcsainkat a .ssh könyvtárunkban, akkor meg kell adnunk a fájl(ok) nevét is ahhoz, hogy az ssh-agent-nél be tudjuk jegyeztetni. Ha sikerül, akkor innent®l kezdve (amíg be nem fejezi a futását, vagy mi magunk nem utasítjuk a kulcsaink eldobására) az ssh-agent elintéz minden ssh kapcsolatunkkal kapcsolatos kérdést. Tehát ha olyan szerverre kívánunk belépni, amelyen megtalálható az ssh kulcsunk publikus része és engedélyezték a kulcsos authentikációt, akkor sehol sem kell jelszót megadnunk, mert az
ssh-agent
ezt elintézi helyettünk.
Természetesen nem csak X alatt van lehet®ségünk az
ssh-agent
használatára, hanem kon-
zolon is.
ssh-agent-tel kapcsolatban érdemes odagyelni az ssh -A parancssori kapcsolójára is, ssh-agent kapcsolatát továbbítja a következ® szerverre. Ennek segítségével az ssh kliensünk viszi magával az ssh-agent segítségét akárhány gépen keresztül anélkül, hogy a Az
amely az
titkos kulcsunknak ott kellene lennie azokon a gépeken, amelyeken keresztülmentünk.
5.2.5. Az
Korlátozási lehet®ségek
authorized_keys
fájlban lehet®ségünk nyílik korlátozni a kulcsok használatát. A követke-
z®kben olvasható opciókat a publikus kulcs elé kell beírni. Több opció is használható egyszerre, ekkor vessz®vel kell elválasztani ®ket egymástól.
from="lista"
Ezzel azt lehet korlátozni, hogy mely gépekr®l léphet be a kulcs használója.
Vessz®kkel elválasztva több gépet is meg lehet adni, illetve lehet használni a tesít®ket is. Lehet®ség van a megadás negálására is a
command="parancs"
!
* és ? helyet-
karakterrel.
Ezzel azt lehet korlátozni, hogy milyen parancsot lehet futtatni a kulcs
segítségével.
environment="NÉV=érték"
Környezeti változókat lehet engedélyezni a segítségével. Ez az
opció automatikusan kikapcsolásra kerül, ha a
/etc/ssh/sshd_config fájlban a UseLogin
opció engedélyezve van.
no-port-forwarding
Letiltja a portok továbbításának lehet®ségét.
no-X11-forwarding
Letiltja az X11 továbbításának a lehet®ségét.
no-agent-forwarding no-pty
Letiltja az
ssh-agent
továbbításának lehet®ségét.
Nem engedélyez terminált a kulcs használójának.
permitopen="gép:port"
Korlátozza a portok továbbításának lehet®ségét a megadott gép és
port párosra. Egy konkrét példaként nézzük meg az
amanda-val végzett mentéshez használt kulcs korlátobackup felhasználó authorized_keys fájlja (csak
zását. Tehát így nézzen ki a dns nev¶ gépen a az oldal szélessége miatt van tördelve):
from="backup.akarmi.intra",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/lib/amanda/amandad -auth=ssh amdump" ssh-rsa AAAAB3 NzaC1yc2EAAAABIwAAAIEApndHiSGSowMeNDZvShUazfPk8964yLvfu//goCid5NVHZIuL0OQGdo4mS+BKsS9R5jkHZcy2hPJZLLrx+Tvl7r2G0P2rarXLkwvh+v5/gE9ZX/Az1CL0ZADDw7z9fUL A9XAopd8XparKi0ASPWDhLxRXa1iw6LlUgibiUdV2ex0= backup@backup_amdump
Kósa Attila
2009. március 23.
Debian GNU/Linux
41
Az adatok visszaállításához használt kulcsot is nagyon ajánlott korlátozni. Tehát így nézzen ki a backup nev¶ gépen a
backup
felhasználó
authorized_keys
fájlja (csak az oldal szélessége
miatt van tördelve): from="dns.akarmi.intra",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/lib/amanda/amandad -auth=ssh amindexd amidxtaped" ssh-rsa AA AAB3NzaC1yc2EAAAABIwAAAIEA0ttfgVtHJpUsihlFPLubUqmyxSOMnGDNQuBktdWUMypJgUldR1AgHVV4dTy954dJlYqy1yUmNSHgdE9DdSKiJrWnYpr4CQ622Vy+9mcewBGRH42ZjsdkibGuej7lf3qoC sgY6Od2cm6h6NhX+VA/+gX7iaqQxqvyFMe9hxwIoRM= root@backup_amrecover
2009. március 23.
Kósa Attila
Debian GNU/Linux
42
Kósa Attila
2009. március 23.
6. fejezet
LDAP
Ezen szolgáltatás használatának az a célja, hogy a felhasználóknak csak egyetlen jelszót kelljen megjegyeznie, bármely szolgáltatást szeretnék is igénybe venni a bels® hálózatunkon.
6.1.
6.1.1.
OpenLDAP
A f® kiszolgáló telepítése és kongurálása
A samba.akarmi.intra nev¶ gépre telepítjük az LDAP szervert, hogy a l®vel egy gépen legyen. A
samba
samba
tartományvezér-
fejleszt®i azt javasolják, hogy a f® LDAP szerveren legyen a
tartományvezérl® (bár m¶köd®képes akkor is, ha csak egy LDAP replika áll a rendelkezésére). Sokat kommunikál egymással a
samba és az LDAP, és ha külön gépen helyezkednek el, akkor ez
kihathat a (fájl)kiszolgálás sebességére. # apt-get install slapd
Válaszoljunk a kérdésekre: Admin password: ldap_admin_jelszo Confirm password: ldap_admin_jelszo Setting up slapd (2.3.30-5) ... Creating new user openldap... done. Creating initial slapd configuration... done. Creating initial LDAP directory... done. Starting OpenLDAP: slapd.
A telepítés végén elinduló
slapd-t
állítsuk le amíg be nem konguráljuk:
# /etc/init.d/slapd stop
Érdemes lefuttatni a következ® parancsot, mert így még több dolgot beállíthatunk a kongurációs állomány kézi szerkesztése nélkül, és így a
debconf
is megjegyzi válaszainkat, aminek
egy frissítés esetén vehetjük hasznát. # dpkg-reconfigure -plow slapd Omit OpenLDAP server configuration? No DNS domain name: akarmi.intra Name of your organization: akarmi.intra Admin password: ldap_admin_jelszo Confirm password: ldap_admin_jelszo Database backend to use: BDB Do you want your database to be removed when slapd is purged? Yes Move old database? Yes Allow LDAPv2 protocol? No
Az újrakongurálás végén elinduló
slapd-t
állítsuk le amíg teljesen be nem konguráljuk:
# /etc/init.d/slapd stop
Ha a
Move old database? kérdésre Yes
volt a válaszunk, akkor a
/var/backups könyvtár-
ban létrejött egy új könyvtár, amelyre tekintettel arra, hogy az adatbázisunk még teljesen üres volt nincs szükségünk, tehát nyugodtan törölhetjük.
43
Debian GNU/Linux
44
# rm -rf /var/backups/unknown-2.3.30-5.*
Telepítsük fel a tanúsítványok kezeléséhez szükséges csomagot. # apt-get install openssl
Az 5.1.1 és az 5.1.2 fejezetekben
generált fájlokat másoljuk be a megfelel® helyekre, és
állítsuk be a jogosultságaikat: # # # # # # # #
cp CA.crt /etc/ssl/certs/ cp samba.akarmi.intra.crt /etc/ssl/certs/ cp samba.akarmi.intra.key.nopass /etc/ssl/private/ chgrp openldap /etc/ssl/private chgrp openldap /etc/ssl/private/samba.akarmi.intra.key.nopass chmod 0710 /etc/ssl/private/ chmod 0644 /etc/ssl/certs/*.crt chmod 0640 /etc/ssl/private/samba.akarmi.intra.key.nopass
A
/etc/default/slapd
fájlt egészítsük ki a következ® sorral (már szerepel hasonló sor a
fájlban, de ki van kommentezve, a kikommentezett sor alá írjuk az alábbit): SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:///"
Ezzel beállítottuk, hogy a lokális interfészen titkosítás nélkül lehessen elérni az LDAP szerverünket, illetve az összes többi interfészünkön pedig csak titkosított módon. A
/etc/ldap/ldap.conf
HOST BASE TLS_CACERT TLS_CACERTDIR TLS_REQCERT
A
fájlba írjuk bele a következ®ket:
127.0.0.1 dc=akarmi,dc=intra /etc/ssl/certs/CA.crt /etc/ssl/certs/ allow
samba.schema
fájl megszerzésének egyszer¶ módja, ha telepítjük a
samba-doc
csomagot.
# apt-get install samba-doc # gzip -dc /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz > /etc/ldap/schema/samba.schema # chmod 0644 /etc/ldap/schema/samba.schema
mail-alias.schema nev¶ fájlt egy másik fájlból alakítottam ki tettem a /etc/ldap/schema/ könyvtárba), és mindössze az alábbiakat A
magamnak
1 (és elmen-
tartalmazza:
attributetype ( 1.1.2.1.1.2 NAME ( 'alias' ) DESC 'email alias' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclass ( 1.1.2.2.1.1 NAME 'MailAlias' SUP top AUXILIARY DESC 'Objectclass for Mail Alias' MAY ( alias $ uid ) )
Egészítsük ki a
/etc/ldap/slapd.conf
fájlunkat, hogy az alábbi módon nézzen ki (a rep-
likára vonatkozó részt értelemszer¶en hagyjuk ki, ha nincs rá szükségünk): include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/mail-alias.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 0 modulepath /usr/lib/ldap moduleload back_bdb sizelimit 500 tool-threads 1 TLSCipherSuite :SSLv3 TLSCertificateFile /etc/ssl/certs/samba.akarmi.intra.crt TLSCertificateKeyFile /etc/ssl/private/samba.akarmi.intra.key.nopass TLSCACertificateFile /etc/ssl/certs/CA.crt
1
Ez nem szép, bár m¶köd® megoldás. Csak akkor használjuk, ha biztosak vagyunk benne, hogy nem kell
más LDAP szerverekkel együttm¶ködnünk a kés®bbiekben. Ha erre szükségünk van, akkor igényeljünk (a
//www.iana.org/
http:
oldalon) magunknak OID-ket, és készítsünk saját schema fájlt vagy használjunk egy már
meglév®t.
Kósa Attila
2009. március 23.
Debian GNU/Linux
45
backend bdb checkpoint 512 30 database bdb suffix "dc=akarmi,dc=intra" directory "/var/lib/ldap" dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index givenname eq,sub index default sub lastmod on replogfile /var/lib/slapd/replog access to attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdCanChange by dn="cn=admin,dc=akarmi,dc=intra" write by dn="cn=replicator,dc=akarmi,dc=intra" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=akarmi,dc=intra" write by dn="cn=replicator,dc=akarmi,dc=intra" write by self write by * read replica uri=ldaps://mail.akarmi.intra:636/ binddn="cn=replicator,dc=akarmi,dc=intra" bindmethod=simple credentials=ldap_replicator_jelszo
Miel®tt elindítanánk az LDAP szerverünket, generáljuk le az index állományokat, és ne felejtsük el hozzáférhet®vé tenni a
slapd-t
futtató felhasználónak és csoportnak:
# slapindex -f /etc/ldap/slapd.conf WARNING! Runnig as root! There's a fair chance slapd will fail to start. Check file permissions! # chown openldap:openldap /var/lib/ldap/cn.bdb # chmod 0600 /var/lib/ldap/cn.bdb
Most már el kell tudnunk indítani az LDAP szerverünket: # /etc/init.d/slapd start
Telepítsük fel az adatbázisunk parancssori módosításához szükséges eszközöket: # apt-get install ldap-utils
Ekkor már le tudjuk kérdezni a futó szerverünket, és az alábbi választ kell kapnunk: # # # # # # # #
ldapsearch -h localhost -x extended LDIF LDAPv3 base <> with scope subtree filter: (objectclass=*) requesting: ALL
# akarmi.intra dn: dc=akarmi,dc=intra objectClass: top objectClass: dcObject objectClass: organization o: akarmi.intra dc: akarmi # admin, akarmi.intra dn: cn=admin,dc=akarmi,dc=intra objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2
2009. március 23.
Kósa Attila
Debian GNU/Linux
46
A
replicator 2
felhasználóra akkor van szükségünk, ha egy (vagy több) slave LDAP szer-
vert is üzemeltetni szeretnénk. A következ® dolgunk ennek a felhasználónak a hozzáadása az adatbázishoz, hogy utána már a replikálás m¶köd®képes legyen. Tehát hozzunk létre egy
replicator.ldif
2 az alábbi tartalommal:
nev¶ fájl
dn: cn=replicator,dc=akarmi,dc=intra cn: replicator objectClass: top objectClass: organizationalRole objectClass: simpleSecurityObject userPassword: {SSHA}JXkMpPzYB5N4W8ZhH9FpCuodrzcD2WGv description: LDAP replicator
A
userPassword
mez® tartalmát a következ® paranccsal tudjuk meg:
# slappasswd -h {SSHA} New password: Re-enter new password: {SSHA}JXkMpPzYB5N4W8ZhH9FpCuodrzcD2WGv
A
New password:
jelszót (45. oldal),
a
kérdésre adjuk meg a /etc/ldap/slapd.conf állományban Re-enter new password kérésre pedig ismételjük meg.
megadott
Már csak hozzá kell adnunk az adatbázishoz. Ezt a következ® paranccsal tudjuk megtenni: # ldapmodify -a -x -D 'cn=admin,dc=akarmi,dc=intra' -W -f replicator.ldif Enter LDAP Password: adding new entry "cn=replicator,dc=akarmi,dc=intra"
Jelszóként
6.1.2.
a 43. oldalon,
az
Admin password:
kérdésre adott jelszót kell megadnunk.
Replika beállítása
A mail szerveren A példaként bemutatott hálózatunkban a mail.akarmi.intra nev¶ szerverre fogjuk telepíteni az LDAP replikát, mert a levelek kézbesítéséhez és eléréséhez is szükségük lesz a szoftvereknek az LDAP-pal történ® kommunikációra. Gyakorlatilag ugyanúgy kell kezdenünk, mint a f® szerver telepítésekor. Felrakjuk a szükséges csomagokat, majd leállítjuk a szervert a kongurálás idejére. Hogy gyorsabban haladjunk, egyszer¶en átmásoljuk a f® szerverr®l a kongurációs állományokat, majd átszerkesztjük a szükséges opciókat. Így kihagyhatjuk a
dpkg-reconfigure
lépést is. Nyugodtan letörölhetjük a telepít®
által létrehozott adatbázist is, hiszen úgyis ide kell másolnunk a f® szerveren létrehozott adatbázisunkat. Ezen másolás idejére a f® szervert ne felejtsük el leállítani!
Az 5.1.2. fejezetben
leírtaknak megfelel®en generáljunk tanúsítványt ezen szerver részére is. # # # # # # # # # # # # # #
apt-get install slapd ldap-utils openssl rsync /etc/init.d/slapd stop rm -f /var/lib/ldap/* rsync -av -e ssh samba:/etc/ldap/ /etc/ldap/ scp samba:/etc/default/slapd /etc/default/ cp CA.crt /etc/ssl/certs/ cp mail.akarmi.intra.crt /etc/ssl/certs/ cp mail.akarmi.intra.key.nopass /etc/ssl/private/ chgrp openldap /etc/ssl/private chgrp openldap /etc/ssl/private/mail.akarmi.intra.key.nopass chmod 0710 /etc/ssl/private chmod 0644 /etc/ssl/certs/*.crt chmod 0640 /etc/ssl/private/mail.akarmi.intra.key.nopass rsync -av -e ssh samba:/var/lib/ldap/ /var/lib/ldap/
Lássuk, melyik állományon mit is kell változtatnunk. A
/etc/ldap/slapd.conf
fájlt némi-
képp át kell írnunk, hogy az alábbi módon nézzen ki. include include include include include include pidfile argsfile
2
/etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema /etc/ldap/schema/nis.schema /etc/ldap/schema/inetorgperson.schema /etc/ldap/schema/samba.schema /etc/ldap/schema/mail-alias.schema /var/run/slapd/slapd.pid /var/run/slapd/slapd.args
A nevet önkényesen választottam.
Kósa Attila
2009. március 23.
Debian GNU/Linux
47
loglevel 0 modulepath /usr/lib/ldap moduleload back_bdb sizelimit 500 tool-threads 1 TLSCipherSuite :SSLv3 TLSCertificateFile /etc/ssl/certs/mail.akarmi.intra.crt TLSCertificateKeyFile /etc/ssl/private/mail.akarmi.intra.key.nopass TLSCACertificateFile /etc/ssl/certs/CA.crt backend bdb checkpoint 512 30 database bdb suffix "dc=akarmi,dc=intra" directory "/var/lib/ldap" dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index givenname eq,sub index default sub lastmod on replogfile /var/lib/slapd/replog access to attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdCanChange by dn="cn=admin,dc=akarmi,dc=intra" write by dn="cn=replicator,dc=akarmi,dc=intra" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=akarmi,dc=intra" write by dn="cn=replicator,dc=akarmi,dc=intra" write by self write by * read updatedn updateref
"cn=replicator,dc=akarmi,dc=intra" "ldaps://samba.akarmi.intra"
Ha ezek után mindkét gépen lefuttatjuk a # /etc/init.d/slapd start
parancsot (el®ször a f® szerveren futtassuk), akkor látni fogjuk, hogy a f® szerveren nem csak a
slapd,
hanem a
slurpd
is elindult. Ugyanis ez felel®s a replikálásért.
Ha most a mail nev¶ gépen is kiadjuk az el®z®leg leírt
ldapsearch parancsot, akkor ugyanazt
kell látnunk, mint amikor a f® szerveren adjuk ki.
6.1.3.
Az adatbázis feltöltése
Kezdjük el feltölteni az adatbázisunkat. Ehhez
.ldif
fájlokat fogunk írni, amelyeket egyesével
fogunk betölteni. Természetesen lehetséges egyetlen menetben is elvégezni a feltöltést, egyetlen
.ldif fájlt használva, de most az átláthatóság kedvéért csináljuk egyesével. Nem fogom minden betöltéshez leírni a szükséges parancsot, a Groups rész betöltésénél bemutatott parancsot (és jelszót) kell mindig használni, csak a betöltend® fájl nevét kell változtatni értelemszer¶en. El®ször a csoportok tárolására szolgáló ágat hozzuk létre (a
groups.ldif
nev¶ fájlba).
dn: ou=Groups,dc=akarmi,dc=intra objectClass: top objectClass: organizationalUnit ou: Groups
És maga a betöltés: ldapmodify -a -x -D 'cn=admin,dc=akarmi,dc=intra' -W -f groups.ldif Enter LDAP Password: adding new entry "ou=Groups,dc=akarmi,dc=intra"
A windowsos tartományvezérl® miatt van erre szükség, itt fognak tárolódni a tartományba belépett számítógépek (a
2009. március 23.
computers.ldif
nev¶ fájlba).
Kósa Attila
Debian GNU/Linux
48
dn: ou=Computers,dc=akarmi,dc=intra objectClass: top objectClass: organizationalUnit ou: Computers
A felhasználók tárolására szolgáló ágat hozzuk létre (a
users.ldif
nev¶ fájlba).
dn: ou=Users,dc=akarmi,dc=intra objectClass: top objectClass: organizationalUnit ou: Users
Mivel sambát szeretnénk használni, kénytelenek vagyunk átnyúlni a
samba
telepítéséhez, és
onnan kiszedni bizonyos információkat, illetve gyelembe venni a sambával kapcsolatos dolgokat. Ugyanis ezeket az információkat is szerepeltetni kell az adatbázisban. Az 55. oldalon
láthatóak
a lekérdezéshez szükséges parancsok és az általuk visszaadott eredmények. Hogy ketté tudjuk választani az LDAP-ban és az esetlegesen a
ldapusers.ldif
nálókat, hozzunk létre egy csoportot (az
passwd
fájlban lév® felhasz-
fájlba).
dn: cn=ldapusers,ou=Groups,dc=akarmi,dc=intra objectClass: top objectClass: posixGroup cn: ldapusers gidNumber: 20000 description: Domain Users group
A tartományi rendszergazdáknak hozzunk létre külön csoportot (a
ntadmins.ldif
fájlba).
dn: cn=ntadmins,ou=Groups,dc=akarmi,dc=intra objectClass: top objectClass: posixGroup cn: ntadmins gidNumber: 20001 description: Domain Admins group
A tartományi vendég usereknek hozzunk létre külön csoportot (az
ldapguests.ldif fájlba).
dn: cn=ldapguests,ou=Groups,dc=akarmi,dc=intra objectClass: top objectClass: posixGroup cn: ldapguests gidNumber: 20002 description: Domain Guests group
Ebbe a csoportba fognak tartozni a tartományba belép® gépek (az
ldapmachine.ldif
fájlba). dn: cn=ldapmachine,ou=Computers,dc=akarmi,dc=intra objectClass: top objectClass: posixGroup cn: ldapmachine gidNumber: 20003 description: Domain Computers group
nobody felhasználónk, de a samba nem tud róla (mivel az LDAP-ban nincs, samba csak az LDAP-val kommunikál). Ezért létre kell hoznunk egy nobody felhasználót az
Igaz, hogy van és a
LDAP adatbázisában is, de unixos dolgokat (mint például home könyvtár, shell) nem kell neki beállítanunk, az alábbiak elegend®ek (a
nobody_user.ldif
fájlba).
dn: uid=nobody,ou=Users,dc=akarmi,dc=intra objectClass: inetOrgPerson objectClass: sambaSamAccount uid: nobody cn: nobody sn: nobody sambaLogonTime: 0 sambaLogoffTime: 0 sambaKickoffTime: 0 sambaPwdCanChange: 0 sambaPwdMustChange: 0 sambaPwdLastSet: 0 sambaBadPasswordCount: 0 sambaAcctFlags: [UX ] sambaSID: S-1-5-21-3140357665-410036179-3970665752-501 sambaPrimaryGroupSID: S-1-5-21-3140357665-410036179-3970665752-514 sambaLMPassword: NO PASSWORDXXXXXXXXXXXXXXXXXXXXX sambaNTPassword: NO PASSWORDXXXXXXXXXXXXXXXXXXXXX
Kósa Attila
2009. március 23.
Debian GNU/Linux
49
És most adjuk hozzá az els® felhasználónkat (de el®tte mindenképpen állítsuk be a tartományvezérl®n a tartományra vonatkozó alapbeállításokat lásd az 57. oldalt). kerüljenek az
atkosa_user.ldif
Ezek az adatok
nev¶ fájlba.
dn: uid=atkosa,ou=Users,dc=akarmi,dc=intra objectClass: top objectClass: shadowAccount objectClass: posixAccount objectClass: person objectClass: inetOrgPerson objectClass: sambaSamAccount objectClass: MailAlias uid: atkosa description: Kosa Attila cn: Kosa Attila sn: Kosa givenName: Attila mail: atkosa alias: kosa.attila alias: attila.kosa uidNumber: 20000 gidNumber: 20000 homeDirectory: /home/atkosa loginShell: /bin/bash shadowMin: 0 shadowMax: 9999 shadowWarning: 7 shadowExpire: 0 shadowLastChange: 13598 sambaLogonTime: 0 sambaLogoffTime: 0 sambaKickoffTime: 0 sambaPwdCanChange: 0 sambaPwdMustChange: 0 sambaPwdLastSet: 0 sambaBadPasswordCount: 0 sambaLogonHours: -1 displayName: Kosa Attila sambaPasswordHistory: 0000000000000000000000000000000000000000000000000000000000000000 sambaAcctFlags: [U ] sambaSID: S-1-5-21-3140357665-410036179-3970665752-41000 sambaPrimaryGroupSID: S-1-5-21-3140357665-410036179-3970665752-41001 sambaLMPassword: 0 sambaNTPassword: 0 userPassword: {SMD5}0
A használt attribútumok magyarázata:
•
dn Annak leírása, hogy a fában hová kerül a bejegyzés.
•
objectClass Az alkalmazni kívánt osztályok.
•
uid A felhasználói név, amely a belépésre (a szolgáltatások igénybevételére) használható.
•
description Egy egyszer¶ leírás mez®.
•
cn A felhasználó teljes neve.
•
sn A felhasználó vezetékneve.
•
givenName A felhasználó keresztneve.
•
mail A felhasználó els®dleges e-mail címe. Azért nem szerepel benne a
@domain.név,
hogy bármilyen domainnek szóló levelet fogad is el a levelez®szerver, abban a domain-ben érvényes név lesz. Ez gondot okozhat, ha virtuális domain-eket is kell kezelnünk, ekkor ajánlott a teljes (domainnévvel kiírt) e-mail cím használata.
•
alias A felhasználó összes olyan neve, amelyre leveleket szeretne kapni. Ugyanazért nem tartalmazza a domain részt, mint a
mail
változó.
•
uidNumber A felhasználó azonosítási száma.
•
gidNumber A felhasználó csoportazonosító száma.
2009. március 23.
Kósa Attila
Debian GNU/Linux
50
•
homeDirectory A felhasználó home könyvtára. Ne felejtkezzünk el arról, hogy a felhasználó létrehozásakor nem jön létre automatikusan a home könyvtára! Valahogyan létre kell hoznunk az összes gépen, amelyeken home könyvtárra van szüksége. Ebb®l a szempontból egyedül a levelez®szerver a kritikus. A többi gépen elégséges, ha a
pam_mkhomedir
beál-
lításával akkor jön létre a home könyvtár, ha a felhasználó belép. De levelek érkezhetnek számára azel®tt is, miel®tt belépne a levelez®szerverre. A lásához szükséges
Maildir
postfix
képes a levelek táro-
könyvtár létrehozására a felhasználó home könyvtárában, de
a biztonság kedvéért beletehetjük a
/etc/skel
könyvtárba is a
Maildir
könyvtárat (a
levelez®szerveren). # mkdir /etc/skel/Maildir && chmod 0700 /etc/skel/Maildir
Természetesen az is megoldást jelenthet, ha azokra a szerverekre, amelyeken fontos, hogy a felhasználónak létrejöjjön a home könyvtára, mi magunk ssh-zunk be a felhasználó nevében (hiszen ismerjük a kezdeti jelszavát), így a jogosultságokkal és tartalommal (a
/etc/skel
pam_mkhomedir létrehozza a megfelel®
könyvtár megfelel® feltöltése esetén) a
felhasználó home könyvtárát. Ehhez persze az kell, hogy minden szükséges gépen az
ssh
úgy legyen beállítva, hogy az LDAP-t használja a felhasználók azonosítására.
•
loginShell A felhasználó shell-je. Nem kell, hogy feltétlenül valódi shell-je legyen a felhasználónak, a
/bin/false
is megteszi. A használni kívánt szolgáltatások függvénye (és
a saját döntésünk), hogy adunk-e a felhasználónak shell-t vagy sem.
•
shadowMin Két jelszóváltoztatás között minimum ennyi napnak kell eltelnie. A unixos jelszóra vonatkozik, a sambás jelszóra nincs hatással.
•
shadowMax Két jelszóváltoztatás között maximum ennyi nap telhet el. Tekintve, hogy az utolsó jelszócserét®l ( hosszabb ideig (
shadowMax
shadowLastChange
változó) a megengedett leg-
változó) érvényes a unixos jelszó, ezért ezek értékét úgy kell
megválasztani, hogy az aktuálisan számolt id®érték (az 1970. január 01-t®l eltelt napok száma) kisebb vagy egyenl® legyen, mint a fent említett két változó összege. Egyszer¶en a következ® parancs segítségével számolható ki ez az összeg: # echo $[`date +%s` / (60*60*24)]
Ha az így kapott összegnél nagyobb az eltelt napok száma, akkor a felhasználó nem tudja használni a unixos jelszavát, mert lejártnak tekinti a rendszer. Sajnos ebben az esetben az
smbpasswd
parancs sem segít (mert az nem változtatja a
tartalmát, csak a tudja a
passwd
userPassword
shadowLastChange
mez®ét magyarul a unixos jelszavát), egyedül a
mez®
root
parancs segítségével megváltoztatni a felhasználó jelszavát.
Másképpen mondva: ha a
shadowLastChange változó értékét a létrehozásakor beállítjuk shadowMax változóban megadott napig lesz
a fenti parancs által megadott számra, a
érvényes a unixos jelszava. Persze ha a felhasználónak lehet®sége van rá, akkor saját maga is megváltoztathatja a
passwd
3
parancs segítségével a jelszavát , de ehhez el®ször be kell
tudnia jelentkezni.
•
shadowWarning Ennyi nappal a jelszó lejárata el®tt gyelmezteti a rendszer a felhasználót.
•
shadowExpire Ha nem 0, akkor maximum addig érvényes a jelszó (1970-01-01-t®l számolva napokban értend®).
•
shadowLastChange Az utolsó jelszóváltoztatás id®pontja (1970-01-01-t®l számolva napokban értend®). Értékének mindenképpen nagyobbnak kell lennie nullánál.
3
De így nem változik a sambaLMPassword és a sambaNTPassword mez®k értéke (magyarul a windowsos
jelszava).
Kósa Attila
2009. március 23.
Debian GNU/Linux
51
•
sambaLogonTime Jelenleg nem használt mez®.
•
sambaLogoTime Jelenleg nem használt mez®.
•
sambaKickoTime Azt az id®t határozhatjuk meg (Unix id® formátumban), amikor a felhasználó zárolva van és nem tud belépni. Ha ezt az attribútumot elhagyjuk, akkor a
shadowAccount oszshadowExpire attribútumával, akkor teljesen pontos dátummal határozhatjuk meg az
felhasználó account-ja soha nem jár le. Ha együtt használjuk ezt a tály
account lejáratát.
•
sambaPwdCanChange Azt az id®t határozhatjuk meg (Unix id® formátumban), amikor a felhasználó megváltoztathatja a jelszavát. Ha ez az attribútum nincs beállítva, akkor a felhasználó bármikor megváltoztathatja a jelszavát.
•
sambaPwdMustChange Azt az id®t határozhatjuk meg (Unix id® formátumban), amikor a felhasználónak kötelez® megváltoztatnia a jelszavát. Ha ez az érték 0, akkor a felhasználónak az els® belépéskor meg kell változtatnia a jelszavát. Ha az attribútumot nem használjuk, akkor a felhasználó jelszava soha nem jár majd le.
•
sambaPwdLastSet Az 1970. 01. 01-t®l eltelt id®t tartalmazza másodpercekben, amikor a
•
sambaLMPassword
és a
sambaNTPassword
attribútumok utoljára változtak.
sambaBadPasswordCount A hibás bejelentkezéseket számolja ebben a mez®ben a Az 57. oldalon
látható
bad lockout attempt
samba.
beállításával lehet meghatározni, hogy hány
hibás bejelentkezés után zárolódjon az account.
•
sambaLogonHours Ezzel szabályozhatjuk, hogy a felhasználó mely napokon, és mett®l meddig terjed® id®szakban léphet be a tartományba. A bitek jelentésér®l részletes leírás található a
http://pdbsql.sourceforge.net/field-descriptions-passdb.txt
fájlban.
•
displayName Windows XP kliens esetén az itt megadott név fog látszani a Start menü tetején.
•
sambaPasswordHistory A felhasználó által korábban használt jelszavak MD4 hash-ét tartalmazza.
•
sambaAcctFlags Az account jellemz®it tartalmazó mez®. A lehetséges tartalmát a 7.3. fejezetben
•
(a 60. oldalon) láthatjuk. Egyszerre több jelz®t is lehet használni.
sambaSID A felhasználó azonosítási száma windowsos oldalon. Az 58. oldalon
látható
módon lehet kiszámolni az értékét.
•
sambaPrimaryGroupSID A felhasználó els®dleges csoportjának Windows oldali azonosítási száma.
Az 58. oldalon
látható módon lehet kiszámolni az értékét.
•
sambaLMPassword A felhasználó LANMAN windowsos jelszava 16 byte-on tárolva.
•
sambaNTPassword A felhasználó NT windowsos jelszava 16 byte-on tárolva.
•
userPassword A felhasználó unixos jelszava.
Mivel nem írtunk jelszót a felhasználónak, ezért interaktívan kell jelszóval ellátnunk. Ez (a samba
ldap passwd sync = yes opciójának köszönhet®en) megváltoztatja a unixos és a windowsos
jelszavát is a felhasználónak. # smbpasswd atkosa
2009. március 23.
Kósa Attila
Debian GNU/Linux
52
.ldif fájlt, hogy már a jelszó eleve belekerüljön, akkor szükmkntpwd programra (a 60. oldalon látható a beszerzése és a fordítása), illetve látható slappasswd parancsot kell használnunk. Ebben az esetben viszont gyel-
Ha úgy szeretnénk generálni a ségünk lesz az a 46. oldalon
nünk kell rá, hogy mindkét jelszónak azonosat generáljunk, hogy a felhasználónak ne legyenek
4
problémái . Adjuk hozzá az új felhasználónkat az
ldapusers
csoporthoz. Ezt az alábbi
.ldif
fájl segít-
ségével tehetjük meg. dn: cn=ldapusers,ou=Groups,dc=akarmi,dc=intra changetype: modify add: memberUid memberUid: atkosa
Adjuk hozzá az új felhasználónkat az
ntadmins
csoporthoz, hogy adminisztrátori jogokat
biztosítsunk számára a windowsos gépeken. Ezt az alábbi
.ldif
fájl segítségével tehetjük meg.
dn: cn=ntadmins,ou=Groups,dc=akarmi,dc=intra changetype: modify add: memberUid memberUid: atkosa
6.1.4.
A rendszer kongurálása a samba (master) szerveren
Telepítenünk kell azokat a csomagokat, amelyek segítségével a rendszerünk látni fogja az adatbázisban lév® felhasználókat és csoportokat. # apt-get install libpam-ldap libnss-ldap
Válaszok a kérdésekre. LDAP server Uniform Resource Identifier: ldap://127.0.0.1:389/ Distinguished name of the search base: dc=akarmi,dc=intra LDAP version to use: 3 LDAP account for root: cn=admin,dc=akarmi,dc=intra LDAP root account password: ldap_admin_jelszo Make local root Database admin. Yes Does the LDAP database require login? No LDAP account for root: cn=admin,dc=akarmi,dc=intra LDAP root account password: ldap_admin_jelszo
A passwd: group: shadow:
/etc/nsswitch.conf
fájlban ki kell javítani az alább láthatóra a megfelel® sorokat.
compat ldap compat ldap compat ldap
Ezekben a fájlokban mindössze a megadott soroknak kell benne lenniük. A
/etc/pam.d/common-account
fájl tartalma.
account sufficient pam_ldap.so account required pam_unix.so try_first_pass
A
/etc/pam.d/common-auth
fájl tartalma.
auth sufficient pam_ldap.so auth required pam_unix.so nullok_secure try_first_pass
A
/etc/pam.d/common-password
fájl tartalma.
password sufficient pam_ldap.so password required pam_unix.so nullok obscure min=4 max=8 md5 try_first_pass
A
4
/etc/pam.d/common-session
fájl tartalma.
Lehetséges oly módon is használni az LDAP-t, hogy a unixos és a sambás jelszavak ne legyenek szinkronban
egymással, tehát külön lehessen változtatni ®ket, egymástól függetlenül.
Kósa Attila
2009. március 23.
Debian GNU/Linux
53
session required pam_unix.so session optional pam_mkhomedir.so skel=/etc/skel/ umask=0077
Ezáltal az összes PAM-ot használó szolgáltatásunk el tudja érni az adatbázisban lév® felhasználókat és csoportokat. Amennyiben nincs erre szükségünk, akkor megtehetjük, hogy csak az adott szolgáltatás
/etc/pam.d/ könyvtárban lév® fájlját módosítjuk a kívánalmainknak meg-
felel®en. A
getent passwd
és a
getent group
parancsokkal ellen®rizni tudjuk, hogy valóban látja-e
a rendszerünk az adatbázisban lév® felhasználókat és csoportokat. A
/etc/pam.d
könyvtárban lév® fájlok módosítása után az
ssh
és a
cron
szolgáltatást újra
kell indítanunk, hogy értesüljön a PAM változásairól!
6.1.5.
A rendszer kongurálása a mail (replika) szerveren
Telepítenünk kell azokat a csomagokat, amelyek segítségével a rendszerünk látni fogja az adatbázisban lév® felhasználókat és csoportokat. # apt-get install libpam-ldap libnss-ldap
Válaszok a kérdésekre. LDAP server Uniform Resource Identifier: ldap://127.0.0.1:389/ Distinguished name of the search base: dc=akarmi,dc=intra LDAP version to use: 3 LDAP account for root: cn=admin,dc=akarmi,dc=intra LDAP root account password: ldap_admin_jelszo Make local root Database admin. No Does the LDAP database require login? No
A passwd: group: shadow:
/etc/nsswitch.conf
fájlban ki kell javítani az alább láthatóra a megfelel® sorokat.
compat ldap compat ldap compat ldap
Ezekben a fájlokban mindössze a megadott soroknak kell benne lenniük (ugyanazoknak, mint a f® szerveren, tehát nyugodtan át is másolhatjuk ®ket). A
/etc/pam.d/common-account
fájl tartalma.
account sufficient pam_unix.so account required pam_ldap.so try_first_pass
A
/etc/pam.d/common-auth
fájl tartalma.
auth sufficient pam_ldap.so auth required pam_unix.so nullok_secure
A
/etc/pam.d/common-password
fájl tartalma.
password sufficient pam_ldap.so password required pam_unix.so nullok obscure md5 try_first_pass
A
/etc/pam.d/common-session
fájl tartalma.
session required pam_unix.so session optional pam_mkhomedir.so skel=/etc/skel/ umask=0077
A
getent passwd
és a
getent group
parancsokkal ellen®rizni tudjuk, hogy valóban látja-e
a rendszerünk az adatbázisban lév® felhasználókat és csoportokat.
2009. március 23.
Kósa Attila
Debian GNU/Linux
54
6.1.6.
A rendszer kongurálása a proxy szerveren
Telepítsük fel a szükséges csomagot, majd másoljuk a megfelel® helyre a másoljuk át a samba nev¶ gépr®l az
ldap.conf
fájlt, és írjuk át a
CA.crt
HOST
fájlt, illetve
változóhoz tartozó
értéket 192.168.10.250-re. # apt-get install openssl # scp samba:/etc/ssl/certs/CA.crt /etc/ssl/certs/ # scp samba:/etc/ldap/ldap.conf /etc/ldap/
Telepítenünk kell azokat a csomagokat, amelyek segítségével a rendszerünk látni fogja az adatbázisban lév® felhasználókat és csoportokat. # apt-get install libpam-ldap libnss-ldap
5
Válaszok a kérdésekre.
LDAP server Uniform Resource Identifier: ldaps://samba.akarmi.intra/ Distinguished name of the search base: dc=akarmi,dc=intra LDAP version to use: 3 LDAP account for root: cn=admin,dc=akarmi,dc=intra LDAP root account password: mindegy_mit_adunk_meg Make local root Database admin. No Does the LDAP database require login? No
Azért nem kell megadnunk az LDAP helyes root jelszavát, mert nincs rá szükség, és a következ® parancs kiadásakor a rendszer tudomására is tudjuk ezt hozni. Mindenképpen futtassuk a következ® parancsokat, miel®tt tovább lépnénk! # dpkg-reconfigure -plow libnss-ldap
Válaszok a kérdésekre: LDAP server Uniform Resource Identifier: ldaps://samba.akarmi.intra/ Distinguished name of the search base: dc=akarmi,dc=intra LDAP version to use: 3 Does the LDAP database require login? No Special LDAP privileges for root? No Make the configuration file readable/writeable by its owner only? No # dpkg-reconfigure -plow libpam-ldap
Válaszok a kérdésekre: LDAP server Uniform Resource Identifier: ldaps://samba.akarmi.intra/ Distinguished name of the search base: dc=akarmi,dc=intra LDAP version to use: 3 Make local root Database admin. No Does the LDAP database require login? No Local crypt to use when changing passwords. md5
A
/etc/nsswitch.conf
passwd: group: shadow:
A
fájlban ki kell javítani az alább láthatóra a megfelel® sorokat.
compat ldap compat ldap compat ldap
getent passwd
és a
getent group
parancsokkal ellen®rizni tudjuk, hogy valóban látja-e
a rendszerünk az adatbázisban lév® felhasználókat és csoportokat. Mivel ezen a gépen mindössze a proxy szolgáltatást szeretnénk igénybevenni, nem kell az összes
/etc/pam.d
könyvtárban lév® fájlt átalakítani. Csak létre kell hoznunk egy
6 ebben a könyvtárban a következ® tartalommal:
squid
nev¶
fájlt
auth required pam_ldap.so account required pam_ldap.so
5
Most direkt nem lokális LDAP-szerverrel mutatom be a proxy kongurálását, hanem úgy, hogy egy másik
gépen futó szolgáltatástól szerzi be a felhasználói adatokat. De csak azért, hogy erre is lássunk egy példát, és nem pedig azért, mert így jobb lenne a proxy-nak.
6
a
Ha más nevet választunk neki, akkor a
squid
pam_auth
parancs -n opciójának azt a másik nevet kell megadnunk
kongurációs állományában.
Kósa Attila
2009. március 23.
7. fejezet
Fájlszerver
Egy olyan szolgáltatást szeretnék megvalósítani, amely LDAP-alapú felhasználókezeléssel rendelkezik.
7.1.
SaMBa
Egy els®dleges tartományvezérl® kongurálását szeretném bemutatni a teljesség igénye nélkül.
7.1.1.
Telepítés és kongurálás
A telepítés egyszer¶: # apt-get install samba
Válasz az egy szem kérdésre. Workgroup/Domain Name? TARTOMANY
Kérdezzük le a SID értékét. # net getlocalsid SID for domain SAMBA is: S-1-5-21-3140357665-410036179-3970665752
Állítsuk le addig, amíg be nem konguráljuk. # /etc/init.d/samba stop
Hozzuk létre a szükséges könyvtárakat és fájlokat, valamint állítsuk be a megfelel® jogosultságokat és tulajdonosokat, illetve csoportokat. # # # # # # # # # #
touch touch mkdir chmod chmod mkdir chown chown chmod chmod
/etc/printcap /etc/samba/lmhosts -p /etc/skel/.profile/nt 700 /etc/skel/.profile /etc/skel/.profile/nt 600 /etc/skel/.bash* -p /var/local/samba/netlogon 0:0 /var/local/samba/ 0:ntadmins /var/local/samba/netlogon 0700 /var/local/samba 2775 /var/local/samba/netlogon
Amíg nincs
/etc/printcap
fájlunk, addig a
samba
hibaüzeneteket ír a logba, hogy nem
találja ezt a fájlt, emiatt szoktam megtenni az els® lépést (legalább addig, amíg egy nyomtató nem kerül bekongurálásra a rendszerben). Hasonló a helyzet a második paranccsal is. Hiába állítottam be (a
name resolv order
opcióban), hogy ne használja az
lmhosts
fájlt, akkor
is hibaüzenetet ad, ha nem találja. Ezzel létrehoztuk a felhasználói prolok tárolására szolgáló könyvtárakat (abban a könyvtárban, amelynek a tartalmát a rendszer oda fogja másolni a kés®bb létrejöv® felhasználók home könyvtárába), valamint a
netlogon nev¶ megosztáshoz szük-
séges könyvtárakat (itt tárolódnak a felhasználók login szkriptjei). Biztosítottuk azt is, hogy az
55
Debian GNU/Linux
56
ntadmins csoport tagjai írhassák ezt a könyvtárat, illetve minden ebben a könyvtárban létrejöv® fájl és könyvtár automatikusan az ® tulajdonukba kerüljön. A szükséges kongurációs változtatások a
/etc/samba/smb.conf
fájlban:
security = user enable privileges = yes wins support = yes name resolve order = wins host bcast passdb backend = ldapsam:"ldap://localhost" domain logons = yes domain master = yes local master = yes preferred master = yes logon drive = h: logon path = \\%L\profilent logon home = \\%L\%U logon script = %U.bat allow trusted domains = yes machine password timeout = 604800 ldap admin dn = cn=admin,dc=akarmi,dc=intra ldap ssl = no ldap suffix = dc=akarmi,dc=intra ldap user suffix = ou=Users ldap group suffix = ou=Groups ldap machine suffix = ou=Computers ldap delete dn = no ldap replication sleep = 5000 ldap passwd sync = yes ldap timeout = 15 log level = 3 dos charset = CP852 unix charset = ISO8859-2 add machine script = /root/bin/samba_gep_add.sh %u [netlogon] comment = Network Logon Service path = /var/local/samba/netlogon writable = no browseable = no share modes = no guest ok = yes locking = no write list = @ntadmins create mask = 0664 directory mask = 0775 [profilent] path = /home/%U/.profile/nt browseable = no writeable = yes public = no create mask = 0600 directory mask = 0700 profile acls = yes
Az
ldap admin dn
opcióban beállított felhasználónak a jelszavát a samba tudomására kell
hozni, ennek segítségével fog tudni hozzáférni az adatbázishoz. Mivel írni is akar az adatbázisba, ezért egy olyan felhasználót kell itt beállítani, aki megfelel® jogosultsággal rendelkezik az adatbázis megfelel® részeinek az írásához. # smbpasswd -w ldap_admin_jelszo Setting stored password for "cn=admin,dc=akarmi,dc=intra" in secrets.tdb
A gépek hozzáadásához szükségünk van egy szkriptre, amelyet a helyezünk el
samba_gep_add.sh
is az ® nevében futtatja az
néven (úgyis csak a
add machine script
root
/root/bin/
könyvtárban
felhasználó fog hozzáférni, a samba
opcióban megadott szkriptet). Nézzük a szkript
tartalmát. #!/bin/sh PATH=/usr/sbin:/usr/bin:/sbin:/bin LANG=C LC_CTYPE=C LC_COLLATE=C LC_TIME=C LC_ALL=C PRG=`basename $0 .sh` LDAPJELSZO=ldap_admin_jelszo LDAPMASTER=localhost BINDDN=cn=admin,dc=akarmi,dc=intra MINUID=20000 NTMACHINEGIDNUMBER=20003 HOMEDIRECTORY=/dev/null LOGINSHELL=/bin/false DESCRIPTION=Computer CNT=0 VARAKOZAS=10 if [ -f /var/run/$PRG.pid ]; then exit 2 fi echo $$ > /var/run/$PRG.pid
Kósa Attila
2009. március 23.
Debian GNU/Linux
57
UU=`getent passwd | awk -v min=$MINUID -F: '{ if($3 >= min) { uid[$3]=1 } } \ END { k=0; for(j=min; k==0; j++) { if(uid[j] != 1) { print j; k=1 } } }'` XTMP=`mktemp -q -p /tmp -t $PRG.XXXXXX` if [ -z "$XTMP" ]; then XTMP=/tmp/$PRG.$$.tmp fi ( echo "dn: uid=$1,ou=Computers,dc=akarmi,dc=intra" echo "objectClass: top" echo "objectClass: inetOrgPerson" echo "objectClass: posixAccount" echo "cn: $1" echo "sn: $1" echo "uid: $1" echo "uidNumber: $UU" echo "gidNumber: $NTMACHINEGIDNUMBER" echo "displayName: $1" echo "homeDirectory: $HOMEDIRECTORY" echo "loginShell: $LOGINSHELL" echo "description: $DESCRIPTION" echo "" echo "dn: cn=ldapmachine,ou=Groups,dc=akarmi,dc=intra" echo "changetype: modify" echo "add: memberUid" echo "memberUid: $1" echo "" ) >$XTMP ldapmodify -a -x -w $LDAPJELSZO -H ldap://$LDAPMASTER -D "$BINDDN" -f $XTMP | logger -t "gep hozzaadas" while [ "`getent passwd $1 ; echo $?`" == "2" -a $CNT -ne $VARAKOZAS ]; do sleep 1 CNT=$[$CNT+1] done rm -f $XTMP /var/run/$PRG.pid exit 0
Most már elindíthatjuk a tartományvezérl®nket, munkára kész. # /etc/init.d/samba start
A unixos csoportok windowsos csoportokra való leképezése. Természetesen ehhez már az ldap adatbázisában szerepelnie kell ezeknek a csoportoknak! A parancsokban látható nem szabadon választott érték (részletesen lásd
az 59. oldalon).
rid
értéke
A Windows ezen értéket
használja a jogosultságok megállapítására. Ennek a három csoportnak mindenképpen léteznie kell egy tartományvezérl®n (ezek beépített csoportok a windowsos gépeken). # net groupmap add rid=512 unixgroup=ntadmins ntgroup='Domain Admins' Successfully added group Domain Admins to the mapping db as a domain group # net groupmap add rid=513 unixgroup=ldapusers ntgroup='Domain Users' Successfully added group Domain Users to the mapping db as a domain group # net groupmap add rid=514 unixgroup=ldapguests ntgroup='Domain Guest' Successfully added group Domain Guest to the mapping db as a domain group # net groupmap add rid=515 unixgroup=ldapmachine ntgroup='Domain Computers' Successfully added group Domain Computers to the mapping db as a domain group # net groupmap list Domain Users (S-1-5-21-3140357665-410036179-3970665752-513) -> ldapusers Domain Admins (S-1-5-21-3140357665-410036179-3970665752-512) -> ntadmins Domain Guest (S-1-5-21-3140357665-410036179-3970665752-514) -> ldapguests Domain Computers (S-1-5-21-3140357665-410036179-3970665752-515) -> ldapmachine
A fenti parancsok hatására az LDAP-ban lév® bejegyzések kiegészülnek.
A 48. oldalon
látható dn: cn=ldapusers,ou=Groups,dc=akarmi,dc=intra objectClass: top objectClass: posixGroup cn: ldapusers gidNumber: 20000 description: Domain Users group
bejegyzés például ilyen formát fog ölteni: dn: cn=ldapusers,ou=Groups,dc=akarmi,dc=intra objectClass: top objectClass: posixGroup objectClass: sambaGroupMapping cn: ldapusers gidNumber: 20000 sambaSID: S-1-5-21-3140357665-410036179-3970665752-513 sambaGroupType: 2 displayName: Domain Users description: Domain Users group
Tehát a
samba
beleírja a számára szükséges dolgokat az LDAP adatbázisába. Bármelyik
unixos csoportunkat láthatóvá tehetjük a windowsos gépeken egy
net groupmap add parancs
segítségével. A tartományra vonatkozó alapbeállítások:
2009. március 23.
Kósa Attila
Debian GNU/Linux
58
# pdbedit -P "min password length" -C 8 -d 0 account policy "min password length" description: Minimal password length (default: 5) account policy "min password length" value was: 5 account policy "min password length" value is now: 8 # pdbedit -P "password history" -C 5 -d 0 account policy "password history" description: Length of Password History Entries (default: 0 => off) account policy "password history" value was: 0 account policy "password history" value is now: 5 # pdbedit -P "minimum password age" -C 3600 -d 0 account policy "minimum password age" description: Minimal password age, in seconds (default: 0 => allow immediate password change) account policy "minimum password age" value was: 0 account policy "minimum password age" value is now: 3600 # pdbedit -P "maximum password age" -C 3888000 -d 0 account policy "maximum password age" description: Maximum password age, in seconds (default: -1 => never expire passwords) account policy "maximum password age" value was: 4294967295 account policy "maximum password age" value is now: 3888000 # pdbedit -P "bad lockout attempt" -C 3 -d 0 account policy "bad lockout attempt" description: Lockout users after bad logon attempts (default: 0 => off) account policy "bad lockout attempt" value was: 0 account policy "bad lockout attempt" value is now: 3
Domain Admins csoportnak2 , hogy gépeket vehessenek fel a tartományba. Az atkosa felhasználó jelszavát kell megadni! Ez azt feltételezi, hogy az atkosa felhasználó már tagja az ntadmins csoportnak, és a korábban említett (a net groupmap parancsok által megvaAdjunk jogokat
1a
lósított) csoportleképezések már készen vannak. # net -U atkosa rpc rights grant 'TARTOMANY\Domain Admins' SeMachineAccountPrivilege Password: Successfully granted rights.
Ellen®rizzük le, hogy milyen jogokkal rendelkezik a
Domain Admins
csoport.
# net -U atkosa rpc rights list 'TARTOMANY\Domain Admins' Password: SeMachineAccountPrivilege
7.1.2.
Tesztelés
Telepítsük fel a tesztelésre egyszer¶en használható parancssori kliensprogramot. # apt-get install smbclient
Kérjünk egy listát a szerver elérhet® megosztásairól. # smbclient -L samba -U atkosa -d 0 Password: Domain=[TARTOMANY] OS=[Unix] Server=[Samba 3.0.24] Sharename Type Comment -----------------print$ Disk Printer Drivers IPC$ IPC IPC Service (samba server) atkosa Disk Home Directories Domain=[TARTOMANY] OS=[Unix] Server=[Samba 3.0.24] Server --------SAMBA
Comment ------samba server
Workgroup --------TARTOMANY
Master ------SAMBA
És közben a
7.1.3.
/home/atkosa
könyvtár is létrejött a
pam_mkhomedir
modulnak köszönhet®en.
Kiegészít® információk
sambaSID értékét ki kell számolni. Ennek a következ® a logikája: RID base értéke a samba algorithmic rid base opciójában megadott érték, alapértelmezésben 1000. A SID értékét a net getlocalsid parancs segítségével kaphatjuk meg. A felhasználóhoz tartozó uid értékét magunk állíthatjuk be. Ezek alapján a képlet a következ®: Az ldap adatbázisába beírandó
a
RID
= RID
base
+ (2 ∗ uid)
Nézzük meg konkrét számokkal: felhasználói uid
1 2
= 10000
A delegálható jogosultságok táblázata az 59. oldalon
látható.
Nem csak csoportoknak, hanem egyes felhasználóknak is lehetséges jogokat delegálni.
Kósa Attila
2009. március 23.
Debian GNU/Linux RID base
59
= 1000
RID
= 1000 + (2 ∗ 10000) = 21000
SID
= S-1-5-21-3140357665-410036179-3970665752
sambaSID
= S-1-5-21-3140357665-410036179-3970665752-21000
A csoportok esetén annyi a változás, hogy a (természetesen az
uid
helyett a
gid
De vannak speciális, fenntartott
RID
net groupmap add
értéke 1001, a képlet ugyanaz marad
értékek, amelyeknek kötelez® a 7.1. táblázatban
hatónak lennie. Ezért kellett az 57. oldalon a
RID base
értékét kell behelyettesíteni). látható módon a
RID
lát-
értékét direktben megadni
parancsoknak. 7.1. táblázat: A Windows RID értékei
Ismert entitások
A
RID
Típus
Domain Administrator
500
User
Domain Guest
501
User
Domain KRBTGT
502
User
Nem
Domain Admins
512
Csoport
Igen
Domain Users
513
Csoport
Igen
Domain Guest
514
Csoport
Igen
Domain Computers
515
Csoport
Nem
Domain Controllers
516
Csoport
Nem
Domain Certicate Admins
517
Csoport
Nem
Domain Schema Admins
518
Csoport
Nem
Domain Enterprise Admins
519
Csoport
Nem
Domain Policy Admins
520
Csoport
Nem
Builtin Admins
544
Alias
Nem
Builtin Users
545
Alias
Nem
Builtin Guest
546
Alias
Nem
Builtin Power Users
547
Alias
Nem
Builtin Account Operators
548
Alias
Nem
Biltin System Operators
549
Alias
Nem
Builtin Print Operators
550
Alias
Nem
Builtin Backup Operators
551
Alias
Nem
Bultin Replicator
552
Alias
Nem
Builtin RAS Servers
553
Alias
Nem
http://support.microsoft.com/kb/243330
Szükséges-e Nem
3
Nem
címen érhet® el a Microsoft által kiadott
anyag. Az 58. oldalon
láthattunk példát egy jogosultság kiadására. A 7.2. táblázat
összefoglalja,
hogy milyen jogosultságok delegálhatóak jelenleg. 7.2. táblázat: Delegálható jogosultságok
3
A
Jogosultságok
Magyarázat
SeMachineAccountPrivilege
Gépek hozzáadása a tartományhoz
SePrintOperatorPrivilege
Nyomtatók menedzselése
SeAddUsersPrivilege
Felhasználók és csoportok felvétele a tartományba
samba
dokumentációja szerint nem lényeges, de a
samba
mégis keresi az elinduláskor, és reklamál, ha nem
találja. Ezért én inkább mégis létre szoktam hozni lásd a nobody felhasználó létrehozását a 48. oldalon.
2009. március 23.
Kósa Attila
Debian GNU/Linux
60
7.2. táblázat: (folytatás)
Jogosultságok
Magyarázat
SeRemoteShutdownPrivilege
Távoli rendszerek leállítása
SeDiskOperatorPrivilege
Megosztások menedzselése
A 7.3. táblázat
a
sambaAcctFlags
attribútum lehetséges értékeit mutatja be.
7.3. táblázat: Használható jelz®k
Az
mkntpwd
Jelz®
Magyarázat
U
Felhasználó
W
Munkaállomás
X
Nem jár le a jelszó
I
Domain trust account
H
Home könyvtár szükséges
S
Szerver trust account
D
Kikapcsolva
program beszerzése és lefordítása.
# cd /usr/local/src/ # wget "http://downloads.sourceforge.net/ldaputils/mkntpwd.tar.gz?modtime=997682498&big_mirror=0" # tar zxpvf mkntpwd.tar.gz # chmod 0600 * # chown 0:0 * # apt-get install make gcc libc6-dev # make gcc -g -Wall -D_DEBUG -O2 -DMPU8086 -c -o getopt.o getopt.c gcc -g -Wall -D_DEBUG -O2 -DMPU8086 -c -o md4.o md4.c md4.c: In function `mdfour': md4.c:144: warning: implicit declaration of function `memcpy' gcc -g -Wall -D_DEBUG -O2 -DMPU8086 -c -o mkntpwd.o mkntpwd.c mkntpwd.c:37: warning: return type of `main' is not `int' mkntpwd.c: In function `main': mkntpwd.c:67: warning: implicit declaration of function `getopt' gcc -g -Wall -D_DEBUG -O2 -DMPU8086 -c -o smbdes.o smbdes.c gcc -g -Wall -D_DEBUG -O2 -DMPU8086 -o mkntpwd getopt.o md4.o mkntpwd.o smbdes.o # chmod 0700 mkntpwd # cp mkntpwd /usr/local/sbin # chown 0:0 /usr/local/sbin/mkntpwd # apt-get remove --purge make gcc libc6-dev linux-kernel-headers binutils cpp cpp-3.3 gcc-3.3
A 3.1. fejezetben
említésre került a node-type kifejezés. Ez az a beállítás, amely megmondja
a windowsos gépnek, hogy mit tegyen elindulás után. Az alábbi 4 megoldás lehetséges:
•
B-Node Broadcastot és direkt kérdést is kiküld UDP-n és TCP-n. Hatalmas broadcast forgalmat csinál. Száma az 1.
•
P-Node Direkt IP címet szólít meg UDP-n és TCP-n. Ha a cím nem él, nem tud belépni a rendszerbe. Száma a 2.
•
M-Node El®ször egy broadcast üzenettel kísérletezik, majd ha az nem sikerül neki, akkor egy direkt kapcsolattal. Szintén nagy broadcast forgalmat okoz. Száma a 4.
•
H-Node El®ször direkt kapcsolatot keres, majd ha ez nem sikerül neki, akkor elküld 1 broadcast üzenetet. Ha talál valakit, akkor vele attól kezdve direktben beszélget. Száma a 8.
A direkt címek (amelyeket szólítgatnak) a WINS szerver(ek) címei. Ilyenkor regisztrálja is magát a gép az adott WINS szervernél.
7.1.4.
Nyomtatódriverek telepítése a szerverre
Ebben az alfejezetben megnézzük, hogy mit kell ahhoz tennünk, hogy a szerverünkr®l elérhet® nyomtatók windowsos meghajtóprogramjait (drivereit) felrakjuk a szerverünkre, amelyek auto-
Kósa Attila
2009. március 23.
Debian GNU/Linux
61
matikusan települnek (extra jogosultságtól függetlenül), amint a kliens nyomtatni szeretne az adott nyomtatón. A régi
4
printer admin
opció helyett a
SePrintOperatorPrivilege
jogot kell delegálni az alábbi
módon.
# net -U atkosa rpc rights grant 'TARTOMANY\Domain Admins' SePrintOperatorPrivilege Password: Successfully granted rights.
Ellen®rizzük le újra, hogy milyen jogokkal rendelkezik a
Domain Admins
csoport.
# net -U atkosa rpc rights list 'TARTOMANY\Domain Admins' Password: SeMachineAccountPrivilege SePrintOperatorPrivilege
Konguráljuk be a nyomtatót a szerveren (mindegy, hogy
cups-ot vagy lprng-t használunk, samba-t beállíta-
csak gyeljünk arra, hogy a használt nyomtatószerver függvényében kell a
nunk), majd teszteljük le. Célszer¶ el®ször parancssorból kipróbálni, hogy tudunk-e nyomtatni a nyomtatóra. Ha ez m¶ködik (és már a
samba-t is beállítottuk), akkor az smbclient program-
mal ellen®rizhetjük, hogy látszik-e a nyomtatónk. Én az egyszer¶ség kedvéért az
lprng-t használtam, és egy hálózati nyomtatót állítottam be.
Ekkor mindössze ennyire volt szükség az
smb.conf
fájlban (a többi maradt az alapértelmezett
beállításon): load printers = yes printing = lprng printcap name = /etc/printcap
Végre kell hajtanunk némi változtatást az alapértelmezett
print$
nev¶ megosztáson. Úgy
javítsuk ki, hogy az alábbi információkat tartalmazza: [print$] comment = Printer Drivers path = /var/lib/samba/printers browseable = yes read only = yes guest ok = no write list = @ntadmins force group = ntadmins create mask = 0664 directory mask = 0775
Gondoskodnunk kell arról is, hogy a
/var/lib/samba/printers
könyvtárat az
ntadmins
csoportnak legyen joga írni. # chgrp -R ntadmins /var/lib/samba/printers # find /var/lib/samba/printers -type d -exec chmod 775 {} \;
Az
smbclient
ezt mutatja:
# smbclient -L localhost -U atkosa Password: Domain=[TARTOMANY] OS=[Unix] Server=[Samba 3.0.24] Sharename Type Comment -----------------print$ Disk Printer Drivers IPC$ IPC IPC Service (samba server) lexmark Printer Lexmark atkosa Disk Home Directories Domain=[TARTOMANY] OS=[Unix] Server=[Samba 3.0.24]
4
Server --------SAMBA
Comment ------samba server
Workgroup --------TARTOMANY
Master ------SAMBA
Természetesen nem kötelez® a tartományi rendszergazdáknak adni ezt a jogot, de akkor gyelnünk kell a
kapcsolódó beállításokra, mint például a könyvtárjogosultságok.
2009. március 23.
Kósa Attila
Debian GNU/Linux
62
Eddig jól alakulnak a dolgok, most nézzük meg, hogy mit kell tennünk windowsos oldalról. Jelentkezzünk be egy olyan felhasználóval a tartományba egy windowsos gépen, akinek delegáltuk a
SePrintOperatorPrivilege
jogot. Nem akarok képeket tenni az anyagba, ezért inkább
leírom, hogy miképp juthatunk el a szerveren lév® nyomtatóhoz. Magyar nyelv¶ Windows XP a kliens. Hálózati helyek, Teljes hálózat, Microsoft Windows hálózat, Tartomany (ez a tartományunk neve), Samba server (ez a szerverünk neve), Nyomtatók és faxok, lexmark (ez pedig a nyomtatónk neve). Erre az utolsóra kell a jobb egérgombbal kattintani, majd a Tulajdonságok menüpontot kiválasztani. Felugrik egy ablak (Nyomtató tulajdonságai fejléccel), amely arról tájékoztat bennünket, hogy nincs telepítve a nyomtató illeszt®programja, és rákérdez, hogy szeretnénk-e telepíteni. Most jön a trükk, a Nem-et kell választanunk. A következ® ablak már a nyomtatóé, 5 füllel rendelkezik (Általános, Megosztás, Portok, Speciális, Biztonság). A Speciális fül kell nekünk, annak is a fels® harmadából az Illeszt®program sor végén található Új feliratú gomb. Erre kell kattintanunk, majd a Tovább gombra. Ezután van lehet®ségünk kiválasztani a szerveren keresztül elérhet® nyomtató típusát, majd ismét a Tovább gombra kattinthatunk. Ekkor láthatjuk, hogy mely illeszt®programot fogjuk telepíteni. Már csak a Befejezés gombra kell kattintanunk, és láthatjuk, amint felkerülnek a megfelel® fájlok a szerveren a helyükre. Az Alapértelmezések gombra kattintva beállíthatjuk, hogy a kliensekre letölt®dve mik legyenek az alapértelmezett beállítások. Érdemes megvizsgálni ezeket a lehet®ségeket. Az OK gombra kattintva készen is vagyunk. Ily módon megkaptuk annak a lehet®ségét is, hogy egyetlen helyr®l adminisztrálhatjuk az összes kliens erre a nyomtatóra vonatkozó beállításait. Az is lehet®vé vált ezáltal, hogy a felhasználó saját login szkriptjében rendeljük hozzá a nyomtatókat, automatikusan telepítve azokat. Természetesen így törölhetjük is a feleslegessé vált nyomtatókat a felhasználó gépér®l. Lássuk, mit is kell beírni a felhasználó login szkriptjébe, hogy ez valóban m¶ködjön is. rundll32 printui.dll,PrintUIEntry /in /n "\\samba\lexmark" /q rundll32 printui.dll,PrintUIEntry /y /n "\\samba\lexmark" /q
A login szkript els® sora feltelepíti a gépre a megadott nyomtatót, a második sor pedig beállítja, hogy ez legyen az alapértelmezett nyomtató. Az egyéb lehet®ségekr®l egy windowsos gépen tudunk tájékozódni, az alábbi parancs hatására megjelen® ablakból (akár a Start menü Futtatás pontjából is indítható): rundll32 printui.dll,PrintUIEntry /?
7.1.5.
Megosztások létrehozása
Nézzünk néhány példát a láthattuk (az 56. oldalon),
samba
lehet®ségeinek b®séges tárházából. A
netlogon
megosztásnál
hogyan korlátozzuk egy csoport tagjaira az írásjogokat. Ott unixos
oldalon gondoskodtunk arról, hogy a létrejöv® fájlok a megfelel® csoport tulajdonába kerüljenek (az 55. oldalon látható módon). Az els® példában olyan megosztást szeretnénk létrehozni, amelyhez az egyik csoport tagjai teljes (írási és olvasási) joggal férhetnek hozzá (a fájlokat és könyvtárakat a csoport összes tagja létrehozhatja, törölheti, módosíthatja), míg a másik csoport kizárólag olvasásra érheti el a megosztásban lév® állományokat és könyvtárakat, tehát nem hozhat ott létre semmit, nem is másolhat oda semmit, és nem is törölhet. Hozzuk létre a megosztás könyvtárát. # mkdir /samba/teszt01
Beállítjuk a könyvtár jogosultságait, ezzel biztosítva azt, hogy a könyvtárban létrejöv® fájlok és könyvtárak az
iro_csoport
tulajdonába kerüljenek. Ennek akkor van jelent®sége, ha
el®fordulhat, hogy unix alól is eléri valaki az adott megosztást. # chmod 2770 /samba/teszt01 # chown root:iro_csoport /samba/teszt01
Kósa Attila
2009. március 23.
Debian GNU/Linux Az ehhez szükséges minimális
63
samba
konguráció.
[teszt01] path = /samba/teszt01 writeable = yes valid users = @iro_csoport @olvaso_csoport read list = @olvaso_csoport create mask = 0660 directory mask = 0770 force group = iro_csoport
2009. március 23.
Kósa Attila
Debian GNU/Linux
64
Kósa Attila
2009. március 23.
8. fejezet
Levelek küldése
A központi levelez®szerver, illetve az egyéb szerverek és kliensek beállításairól lesz szó ebben a fejezetben.
8.1.
8.1.1.
Postx
Telepítés a központi szerveren
Két csomagra van szükségünk, egy lépésben telepítsük mindkett®t: # apt-get install postfix postfix-ldap Setting up postfix (2.3.8-2+b1) ... Adding group `postfix' (GID 106) ... Done. Adding system user `postfix' (UID 103) ... Adding new user `postfix' (UID 103) with group `postfix' ... Not creating home directory `/var/spool/postfix'. Creating /etc/postfix/dynamicmaps.cf Adding tcp map entry to /etc/postfix/dynamicmaps.cf Adding group `postdrop' (GID 107) ... Done. setting myhostname: mail.akarmi.intra setting alias maps setting alias database changing /etc/mailname setting myorigin setting destinations: kulso-domain.hu mail.akarmi.intra, localhost.akarmi.intra, localhost setting relayhost: fw.akarmi.intra setting mynetworks: 127.0.0.0/8 setting mailbox_size_limit: 0 setting recipient_delimiter: + setting inet_interfaces: all /etc/aliases does not exist, creating it. WARNING: /etc/aliases exists, but does not have a root alias. Postfix is now set up with a default configuration. If you need to make changes, edit /etc/postfix/main.cf (and others) as needed. To view Postfix configuration values, see postconf(1). After modifying main.cf, be sure to run '/etc/init.d/postfix reload'. Running newaliases Stopping Postfix Mail Transport Agent: postfix. Starting Postfix Mail Transport Agent: postfix. Setting up postfix-ldap (2.3.8-2+b1) ... Adding ldap map entry to /etc/postfix/dynamicmaps.cf
Válaszok a telepítés közben feltett kérdésekre. General type of configuration? Internet with smarthost Mail name? mail.akarmi.intra SMTP relay host? (blank for none) fw.akarmi.intra
Érdemes lefuttatni a következ® parancsot, mert így még több dolgot bekongurálhatunk a kongurációs állomány kézi szerkesztése nélkül, és így a aminek egy frissítés esetén vehetjük hasznát. # dpkg-reconfigure -plow postfix
Válaszok a kérdésekre.
65
debconf
is megjegyzi válaszainkat,
Debian GNU/Linux
66
General type of configuration? Internet with smarthost Where should mail for root go atkosa Mail name? mail.akarmi.intra SMTP relay host? (blank for none) fw.akarmi.intra Other destinations to accept mail for? (blank for none) kulso-domain.hu mail.akarmi.intra, akarmi.intra, localhost.akarmi.intra, localhost Force synchronous updates on mail queue? No Local networks? 127.0.0.0/8 192.168.10.0/24 Mailbox size limit 0 Local address extension character? + Internet protocols to use? ipv4
8.1.2.
Beállítás a központi szerveren
A telepítés végén a
/etc/postfix/main.cf
kongurációs állomány a következ® sorokat tartal-
mazza (a kommenteket nem írom le): smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no append_dot_mydomain = no smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache myhostname = mail.akarmi.intra alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = kulso-domain.hu mail.akarmi.intra, akarmi.intra, localhost.akarmi.intra, localhost relayhost = fw.akarmi.intra mynetworks = 127.0.0.0/8 192.168.10.0/24 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = ipv4
1
Az egyes opciók magyarázata :
•
Az
smtpd_banner
változó tartalmát több változóból rakja össze a rendszer. Nem biztos,
hogy még azt is tudatni kívánjuk az érdekl®d®kkel, hogy Debian/GNU rendszer futtatunk, ezért érdemes lehet olyasmire átírni, ami nem nyújt ilyen információkat.
•
A
bi
változó azt szabályozza, hogy küldjön-e értesítést a
gnubiff, xlbiff •
Az
biff utility-knek (például biff,
stb.). Egy szerveren nincs értelme a használatának.
append_dot_mydomain
változó azt szabályozza, hogy ha olyan e-mail érkezik a szer-
verre, amelyben nem teljes domain név szerepel, akkor hozzátegye-e a
mydomain
változó
tartalmát (ponttal elválasztva) a @ (kukac) utáni részhez, és így próbálja meg kézbesíteni a levelet.
• •
A
myhostname
Az
változóban a gép saját neve szerepel.
alias_maps
és az
alias_database
változókban szerepel az aliasok kezeléséhez haszná-
landó fájl neve.
•
A
myorigin
változó tartalmazza a teljes domainnevét a gépnek. Csak a helyben (az adott
gépen) feladott leveleknél számít (amely levelekben a @ mögött semmi sem szerepel), mert ott a @ mögé az egész változó tartalmát beilleszti.
•
A
mydestination
változóban felsorolt domainekre érkez® levelek kerülnek lokálisan feldol-
gozásra.
•
A
relayhost
változóban megadott gépnek továbbítsa a nem neki szóló leveleket (ezt a
viselkedést lehet befolyásolni a
•
A
mynetworks
transport
táblával).
változóban megadott hálózatoktól és/vagy egyedi címekt®l fogadjon el le-
veleket tárolásra vagy továbbításra.
1
Még néhány hiányzik.
Kósa Attila
2009. március 23.
Debian GNU/Linux •
A
67
mailbox_size_limit
változó tartalma határozza meg, hogy mailbox formátumú levél-
tárolás esetén az egyes felhasználók mailboxa mekkora méret¶ lehet maximum. Globális érték, nem lehet felhasználónként szabályozni. Maildir használata esetén nincs hatása.
•
A
recipient_delimiter
azt határozza meg, hogy a felhasználói név és az extension között
milyen elválasztójel van. Ha ebben a változóban megadott jelet talál a @ el®tti részben, akkor szétválasztja a jel két oldalán álló részt. Jellemz®en internetszolgáltatók használják, egy átlagos hálózaton nincs jelent®sége.
•
inet_interfaces sorban alapértelmezésben az szerepel, hogy minden interfészen gyeljen
Az
a postx. A
dpkg-reconfigure alkalmával lefutó konguráló rákérdez ugyan, hogy kinek szeretnénk root-nak szóló leveleket, de a /etc/aliases fájlba nem teszi bele a válaszunkat.
továbbítani a
Emiatt szükséges szerkesztenünk ezt a fájlt, hogy így nézzen ki: postmaster: root root: atkosa
A levelek Maildir-ben történ® tárolásáról tudnia kell a szervernek is. Az alábbi opció fogja megmondani neki, hogy ne mailbox formátumot használjon a felhasználók leveleinek tárolására. home_mailbox = Maildir/
Az ldap-val kapcsolatos beállítások: alias_ldap_timeout = 15 alias_ldap_search_base = ou=Users,dc=akarmi,dc=intra alias_ldap_server_host = localhost alias_ldap_server_port = 389 alias_ldap_query_filter = (|(uid=%u)(mail=%[email protected])(alias=%[email protected])) alias_ldap_result_attribute = uid alias_ldap_scope = sub alias_ldap_bind = no alias_ldap_expansion_limit = 1000 alias_ldap_version = 3
A TLS miatt egészítsük ki az alábbi sorokkal a
main.cf
fájlt:
smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_ccert_verifydepth = 3
8.1.3. A
A hálózat összessége miatti nomítások
/etc/aliases
dnsmaster: proxymaster:
fájlba vegyük fel a következ® sorokat:
root root
A dnsmaster alias a master alias a
squid
felejtsük el futtatni a
8.1.4.
bind
kongjában beállított név miatt kell (16. és 21. oldal),
beállítása
miatt (74. oldal).
newaliases
A
/etc/aliases
a proxy-
fájl változtatása után ne
parancsot.
Tesztelés
Telepítsünk fel egy egyszer¶ levélküld® klienst: # apt-get install mailx
Küldjünk egy levelet a létrehozott felhasználónknak (egyúttal tesztelve az alias beállításainkat is): # date | mailx -s"teszt001" root
2009. március 23.
Kósa Attila
Debian GNU/Linux
68
A
/var/log/syslog
2
fájlban a következ® látható a kézbesítésr®l :
postfix/pickup[4410]: 6ED10231D: uid=0 from= postfix/cleanup[4417]: 6ED10231D: message-id=<[email protected]> postfix/qmgr[4411]: 6ED10231D: from=, size=333, nrcpt=1 (queue active) postfix/local[4419]: 6ED10231D: to=, orig_to=, relay=local, \ delay=0.61, delays=0.38/0.09/0/0.14, dsn=2.0.0, status=sent (delivered to maildir) postfix/qmgr[4411]: 6ED10231D: removed
Tehát sikeresen kézbesült a levél.
8.1.5.
Postx a hálózat többi szerverén
Nem kötelez® minden szerverünkre MTA-t (Mail Transfer Agent) telepíteni, de tudnunk kell, hogy anélkül még a
cron
üzeneteir®l sem fogunk semmit sem kapni. . .
Viszont a syslog nev¶ gépre mindenképpen telepítenünk kell, mert a
logcheck csomagnak postfix telepítését
szüksége van rá. Ezért ennek a gépnek a példáján keresztül mutatom be a az egyszer¶ (levelez® szolgáltatást nem végz®) szerverekre. # apt-get install postfix Setting up postfix (2.3.8-2+b1) ... Adding group `postfix' (GID 104) ... Done. Adding system user `postfix' (UID 101) ... Adding new user `postfix' (UID 101) with group `postfix' ... Not creating home directory `/var/spool/postfix'. Creating /etc/postfix/dynamicmaps.cf Adding tcp map entry to /etc/postfix/dynamicmaps.cf Adding group `postdrop' (GID 105) ... Done. setting myhostname: syslog.akarmi.intra setting alias maps setting alias database changing /etc/mailname setting myorigin setting destinations: syslog.akarmi.intra, localhost.akarmi.intra, localhost setting relayhost: mail.akarmi.intra setting mynetworks: 127.0.0.0/8 setting mailbox_size_limit: 0 setting recipient_delimiter: + setting inet_interfaces: all /etc/aliases does not exist, creating it. WARNING: /etc/aliases exists, but does not have a root alias. Postfix is now set up with a default configuration. If you need to make changes, edit /etc/postfix/main.cf (and others) as needed. To view Postfix configuration values, see postconf(1). After modifying main.cf, be sure to run '/etc/init.d/postfix reload'. Running newaliases Stopping Postfix Mail Transport Agent: postfix. Starting Postfix Mail Transport Agent: postfix.
Válaszok a telepítés közben feltett kérdésekre. General type of configuration? Internet with smarthost Mail name? syslog.akarmi.intra SMTP relay host? (blank for none) mail.akarmi.intra
Érdemes lefuttatni a következ® parancsot, mert így még több dolgot bekongurálhatunk a kongurációs állomány kézi szerkesztése nélkül, és így a
debconf
is megjegyzi válaszainkat,
aminek egy frissítés esetén vehetjük hasznát. # dpkg-reconfigure -plow postfix
Válaszok a kérdésekre. General type of configuration? Internet with smarthost Where should mail for root go [email protected] Mail name? syslog.akarmi.intra SMTP relay host? (blank for none) mail.akarmi.intra Other destinations to accept mail for? (blank for none) syslog.akarmi.intra, localhost.akarmi.intra, localhost Force synchronous updates on mail queue? No Local networks? 127.0.0.0/8 Mailbox size limit 0 Local address extension character? + Internet protocols to use? ipv4
Az
inet_interfaces: all
sorban az
all
szót javítsuk át
localhost -ra. Ez azt fogja eredmé-
nyezni, hogy csak a 127.0.0.1 IP címen (tehát a localhost-on) lehet majd elérni a
postfix-et.
Ett®l függetlenül lehet levelet kiküldeni err®l a gépr®l, de kintr®l beküldeni rá nem lehetséges.
2
Az utolsó el®tti sort eltörtem, hogy kiférjen az oldalra.
Kósa Attila
2009. március 23.
9. fejezet
Levelek olvasása
A felhasználók leveleihez hozzáférést biztosító szolgáltatás kialakítása a cél, amelyet a biztonságot szem el®tt tartva SSL fölötti kapcsolódással fogunk megoldani. Az IMAP segítségével a felhasználók a szerveren tárolhatják a leveleiket, amelynek több el®nye is van:
•
A munkaállomások esetleges sérülése nem jelenti az üzletileg fontos levelezés elvesztését.
•
Az egy helyen tárolt adatok megkönnyítik a biztonsági másolat készítését.
•
A felhasználók bárhonnan elérhetik a leveleiket.
9.1.
9.1.1.
Dovecot
Telepítés
A telepítés egyszer¶ (mivel ez a szolgáltatás is a mail nev¶ szerverre kerül, ezért az
openssl
csomag már fel van telepítve): # apt-get install dovecot-imapd Setting up dovecot-common (1.0.rc15-2) ... adduser: Warning: that home directory does not belong to the user you are currently creating. Adding user `dovecot' to group `mail' ... Done. Creating generic self-signed certificate: /etc/ssl/certs/dovecot.pem (replace with hand-crafted or authorized one if needed). Setting up dovecot-imapd (1.0.rc15-2) ...
A telepítés után állítsuk le amíg bekonguráljuk. # /etc/init.d/dovecot stop
9.1.2.
Beállítás
/etc/dovecot könyvtárba: dovecot.conf, dovecot-sql.conf dovecot-ldap.conf. A dovecot-*.conf fájlok a különböz® adatbázisokhoz tartozó authentikációs módokat tartalmazzák. A dovecot.conf fájl tartalmazza az egyéb beállítási lehet®ségeket. Alakítsuk át úgy A telepítés végén 3 fájl kerül a
és
ezt a fájlt, hogy az alábbiakat tartalmazza: protocols = imaps disable_plaintext_auth = yes shutdown_clients = yes log_timestamp = "%Y-%m-%d %H:%M:%S " ssl_disable = no ssl_cert_file = /etc/ssl/certs/mail.akarmi.intra.crt ssl_key_file = /etc/ssl/private/mail.akarmi.intra.key.nopass ssl_verify_client_cert = no ssl_parameters_regenerate = 168 ssl_cipher_list = ALL:!LOW verbose_ssl = no
69
Debian GNU/Linux
70
login_process_per_connection = yes login_log_format_elements = user=<%u> method=%m rip=%r lip=%l %c mail_location = maildir:~/Maildir mail_extra_groups = mail mail_full_filesystem_access = no mail_debug = no mail_read_mmaped = no mmap_disable = no first_valid_uid = 20000 last_valid_uid = 30000 first_valid_gid = 20000 last_valid_gid = 20000 umask = 0077 mail_cache_fields = imap.bodystructure mailbox_idle_check_interval = 30 maildir_copy_with_hardlinks = no protocol imap { mail_executable = /usr/lib/dovecot/imap imap_max_line_length = 65536 login_greeting_capability = no imap_client_workarounds = outlook-idle } auth_executable = /usr/lib/dovecot/dovecot-auth auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@ auth_verbose = no auth_debug = no auth default { mechanisms = plain passdb pam { args = session=yes } userdb passwd { args = blocking=yes } user = root }
9.1.3.
Tesztelés
A sikeresen kézbesült levelet
(lásd a 68. oldalt)
próbáljuk meg elolvasni az új IMAP szerve-
rünkön. # openssl s_client -host mail -port 993 -CAfile /etc/ssl/certs/CA.crt CONNECTED(00000003) depth=1 /C=HU/ST=BAZ/L=Miskolc/O=Akarmi Kft/OU=CA_kiallito/CN=akarmi.intra/email [email protected] verify return:1 depth=0 /C=HU/ST=BAZ/L=Miskolc/O=Akarmi Kft/OU=tanusitvany_generalo/CN=mail.akar mi.intra/[email protected] verify return:1 --Certificate chain 0 s:/C=HU/ST=BAZ/L=Miskolc/O=Akarmi Kft/OU=tanusitvany_generalo/CN=mail.akarmi.intra/[email protected] i:/C=HU/ST=BAZ/L=Miskolc/O=Akarmi Kft/OU=CA_kiallito/CN=akarmi.intra/[email protected] --Server certificate -----BEGIN CERTIFICATE----MIICqTCCAhICAQMwDQYJKoZIhvcNAQEEBQAwgZUxCzAJBgNVBAYTAkhVMQwwCgYD VQQIEwNCQVoxEDAOBgNVBAcTB01pc2tvbGMxEzARBgNVBAoTCkFrYXJtaSBLZnQx FDASBgNVBAsUC0NBX2tpYWxsaXRvMRUwEwYDVQQDEwxha2FybWkuaW50cmExJDAi BgkqhkiG9w0BCQEWFXNlY3VyaXR5QGFrYXJtaS5pbnRyYTAeFw0wNzAzMjYxODAz MDZaFw0wODAzMjUxODAzMDZaMIGjMQswCQYDVQQGEwJIVTEMMAoGA1UECBMDQkFa MRAwDgYDVQQHEwdNaXNrb2xjMRMwEQYDVQQKEwpBa2FybWkgS2Z0MR0wGwYDVQQL FBR0YW51c2l0dmFueV9nZW5lcmFsbzEaMBgGA1UEAxMRbWFpbC5ha2FybWkuaW50 cmExJDAiBgkqhkiG9w0BCQEWFXNlY3VyaXR5QGFrYXJtaS5pbnRyYTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAwUuBpAWEhqOuVSemAsTCiB/P/1j1nx+tP4H/ 400gqqSubQy2vMqTS3mL3UOWqtA1t5zr9moGge0lpq1AHFmXOkGMpBMLhAWFugDm zGi/mFXiyAKPrTJHe8pQ0yrd5KJv6sG4nPXSzOewI4sEvux70H5E+nURwBOm/t72 5sEf9kcCAwEAATANBgkqhkiG9w0BAQQFAAOBgQCQ+tymGX4Wuv64YNpxAl8eeTz/ Tu072ovEjwkEI5sIvbjakhUgLAAGMqNRsf4xbhzKsid88UNsYlX79F3NvsWRo9V2 SPvN7UKCl6h/3YJYSgOgu4BqedZqBGor6Vrx9vIt2nu1CTiI83WPheXdVDS1Rvts w7dbWciRYba+AD8a2w== -----END CERTIFICATE----subject=/C=HU/ST=BAZ/L=Miskolc/O=Akarmi Kft/OU=tanusitvany_generalo/CN=mail.akarmi.intra/[email protected] issuer=/C=HU/ST=BAZ/L=Miskolc/O=Akarmi Kft/OU=CA_kiallito/CN=akarmi.intra/[email protected] --No client certificate CA names sent --SSL handshake has read 1249 bytes and written 316 bytes --New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 37B9C878A0AAB3B2F72DC600909C11DBD0309F483DCDB9219677615413DCCD58 Session-ID-ctx: Master-Key: D6AC180889FB966EC5E5E38DA0A81163DAAFF0A0FAA0D0E9DF3F0A1DAA8910FFEEB85D562D539768B25ACCE1B3655BE7 Key-Arg : None Start Time: 1182176669 Timeout : 300 (sec) Verify return code: 0 (ok) --* OK dovecot ready. 01 login atkosa jelszo
Kósa Attila
2009. március 23.
Debian GNU/Linux
71
01 OK Logged in. 02 select inbox * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 27 EXISTS * 1 RECENT * OK [UNSEEN 27] First unseen. * OK [UIDVALIDITY 1182176824] UIDs valid * OK [UIDNEXT 28] Predicted next UID 02 OK [READ-WRITE] Select completed. 03 status inbox (messages) * STATUS "inbox" (MESSAGES 27) 03 OK Status completed. 04 fetch 1 rfc822 * 1 FETCH (RFC822 {2328} Return-Path: X-Original-To: atkosa Delivered-To: [email protected] Received: by mail.akarmi.intra (Postfix, from userid 0) id 3BCBF41C4; Mon, 18 Jun 2007 10:44:03 +0100 (CET) To: [email protected] Subject: teszt001 Message-Id: <[email protected]> Date: Mon, 18 Jun 2007 10:44:03 +0100 (CET) From: [email protected] (root) Mon Jun 18 10:44:02 CET 2007 ) 04 OK Fetch completed. 05 logout * BYE Logging out 05 OK Logout completed. read:errno=0
2009. március 23.
Kósa Attila
Debian GNU/Linux
72
Kósa Attila
2009. március 23.
10. fejezet
Proxy
A sávszélesség az, ami sohasem elég. Emiatt minden alkalmat meg kell ragadnunk, hogy tehermentesítsük a vonalunkat. Erre jó lehet®séget nyújtanak a proxy szerverek, amelyek eltárolják a rajtuk keresztül leszedett tartalmakat, és az ugyanazt kér® felhasználóknak már a tárolt tar-
1
talmat szolgáltatják . De nem csak a sávszélességünk védelme lehet az egyetlen ok, ami miatt proxy-t szeretnénk használni.
•
Például nem akarunk minden felhasználónak Internet-elérési jogosultságot adni.
•
Bizonyos tartalmak, oldalak elérését nem akarjuk engedélyezni felhasználóinknak.
•
Tudni szeretnénk, hogy felhasználóink merre barangolnak az Interneten, mivel foglalkoznak a munkaidejükben. Ezzel kapcsolatban gyelnünk kell arra, hogy ne sértsük meg a hatályos törvényeket!
A példában az egész bels® hálózatból érkez® felhasználók használhatják a proxy szolgáltatást, ha képesek egy az LDAP-ban lév® érvényes felhasználói névvel és jelszóval azonosítani magukat. Ha a böngész®jük képes NTLM authentikációra, akkor a proxy elintézi az azonosítást a háttérben a tartományvezérl®vel, ellenkez® esetben a felhasználó el®tt meg fog jelenni egy ablak, amelybe beírhat egy felhasználói nevet és jelszót.
10.1.
Squid
A telepítés nem bonyolult. # apt-get install squid
A kongurálás idejére állítsuk le, és töröljük a cache könyvtárakat (mert valószín¶leg nem felel meg az alapértelmezésben megadott 100 MB terület). # /etc/init.d/squid stop # rm -rf /var/spool/squid/*
A
/etc/squid
könyvtárban találjuk meg a kongurációs állományt
squid.conf
néven. Na-
gyon sok beállítás attól függ, hogy mennyi memória áll a rendelkezésünkre a használt gépben, ezért ezekre most nem térek ki. Ha készen vagyunk a kongurálással, akkor indítsuk el (induláskor ellen®rzi, hogy a cache könyvtárak megvannak-e, ha nincsenek, akkor létrehozza ®ket). # /etc/init.d/squid start Starting proxy server: Creating squid spool directory structure 2007/05/12 12:04:59| Creating Swap Directories squid.
1
Ennél persze árnyaltabb a dolog, például a https-en elérhet® tartalmat nem tárolják a proxy-k.
73
Debian GNU/Linux
74
10.1.1.
1 proxy a hálózatban
Rengeteg beállítási lehet®ség áll a rendelkezésünkre, most csak a m¶ködéshez legszükségesebbeket vesszük szemügyre (el®ször arra az esetre koncentrálva, amikor egyetlen proxy-nk van).
http_port 3128 icp_port 0 htcp_port 0 client_netmask 255.255.255.255 ftp_user [email protected] ftp_passive on auth_param ntlm program /usr/lib/squid/ntlm_auth TARTOMANY\\samba auth_param ntlm children 5 auth_param ntlm keep_alive on #auth_param ntlm max_challenge_reuses 0 #auth_param ntlm max_challenge_lifetime 2 minutes #auth_param ntlm use_ntlm_negotiate on auth_param basic program /usr/lib/squid/pam_auth -n squid auth_param basic children 5 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 2 hours auth_param basic casesensitive off authenticate_ip_ttl 2 hour acl password proxy_auth REQUIRED acl our_networks src 192.168.10.0/24 http_access allow our_networks password http_access allow localhost http_access deny all icp_access deny all logfile_rotate 0 append_domain .akarmi.intra log_icp_queries off query_icmp off error_directory /usr/share/squid/errors/Hungarian snmp_port 0 snmp_access deny all
10.1.2.
2 proxy a hálózatban
Ebben az alfejezetben azt szeretném bemutatni, hogy miképpen kell beállítani 2 proxy-t úgy, hogy csak az egyik érheti el az Internetet, a másik pedig csak rajta keresztül kérhet le bármit is. Itt most csak azokat az opciókat mutatom be, amelyek szükségesek ahhoz, hogy a két proxy együtt tudjon m¶ködni, illetve a második (az Internetre közvetlenül ki nem látó) proxy mögötti felhasználók is elérjék az engedélyezett oldalakat. Az els® proxy beállításai (amely közvetlenül kilát az Internetre):
http_port 3128 icp_port 3130 htcp_port 0 acl our_networks src 192.168.10.0/24 acl slave_proxy src 192.168.88.29/255.255.255.255 http_access allow slave_proxy http_access allow our_networks password http_access allow localhost http_access deny all icp_access allow slave_proxy icp_access deny all log_icp_queries on always_direct allow all
A második proxy beállításai (amely közvetlenül nem lát ki az Internetre, csak az els® proxy-n keresztül):
http_port 3128 icp_port 3130 htcp_port 0 cache_peer proxy.akarmi.intra parent 3128 0 default acl our_networks src 192.168.88.0/24 http_access allow our_networks password http_access allow localhost http_access deny all icp_access deny all log_icp_queries off never_direct allow all
Kósa Attila
2009. március 23.
Debian GNU/Linux 10.2.
75
Automatikus proxybeállítás
Ez nem a szervereket, hanem a munkaállomásokat érint® dolog. Az elterjedt böngész®k képesek arra (és alapértelmezésben úgy is vannak beállítva), hogy automatikusan keressenek egy állományt egy webszerveren, amelyet letöltve be tudják állítani saját magukat. Ezt az állományt a wpad nev¶ webszerveren fogják keresni (ahol a wpad után a kliens által ismert teljes domain név áll),
proxy.pac
néven.
Létre kell hoznunk a megfelel® helyen egy
proxy.pac
nev¶ állományt. Az Interneten talál-
ható leírások alapján célszer¶nek látszik két szoftlinket is létrehozni erre az állományra, hogy biztosan minden elterjedt böngész® megtalálja. # ln -s proxy.pac wpad.da # ln -s proxy.pac wpad.dat
A
proxy.pac
fájl tartalma (a teljesség igénye nélkül):
function FindProxyForURL(url, host) { if (shExpMatch(host, "*.akarmi.intra")|| shExpMatch(host, "*.akarmi.intra")) return "DIRECT"; if (isPlainHostName(host)) return "DIRECT"; if (dnsDomainIs(host, "akarmi.intra")) return "DIRECT"; if (isInNet(host, "192.168.10.0", "255.255.255.0")) return "DIRECT"; if (url.substring(0, 5) == "http:" || url.substring(0, 4) == "ftp:" || url.substring(0, 4) == "FTP:" || url.substring(0, 5) == "HTTP:" || url.substring(0, 6) == "https:" || url.substring(0, 6) == "HTTPS:" || url.substring(0, 7) == "gopher:") return "PROXY proxy:3128"; }
return "DIRECT";
Lehet®ségeket és példákat a Bibliográában látható ([10]) anyagban olvashatunk.
2009. március 23.
Kósa Attila
Debian GNU/Linux
76
Kósa Attila
2009. március 23.
11. fejezet
Web
Az egyetlen IP címmel rendelkez® webszerverünkön több site-ot szeretnénk üzemeltetni. Ehhez a webszervernek képesnek kell lennie arra, hogy szétválogassa a beérkez® kéréseket, és a megfelel® szerverhez továbbítsa. Ezt a böngész® által küldött kérés Host fejlécének tartalma alapján tudják megtenni a szerverek. Ezen lehet®ség bemutatására hozzunk létre 2 különböz® szervert, egyet az intrawebnek és egy másikat a wpadnak sima HTTP-n, és egy HTTPS-en elérhet®t, amelyet szintén intraweb néven lehet megszólítani.
11.1.
11.1.1.
Apache HTTP-n
Telepítés és kongurálás
A telepítés egyszer¶en a következ® paranccsal oldható meg: # apt-get install apache
A legegyszer¶bb, ha azonnal leállítjuk az elinduló szervert (/etc/init.d/apache majd elindítjuk a
dpkg-reconfigure
parancsot, hogy újrakonguráljuk az
apache-ot.
stop),
# dpkg-reconfigure -plow apache
Válaszok a kérdésekre: Would you like to start apache at boot time? Yes Enable suExec? No Please select the modules that apache will load (itt választanunk kell, hogy mely modulokat szeretnénk használni) Set the FQDN for apache default server intraweb.akarmi.intra Set the email address of the apache administrator [email protected] Set the directory that will contain the web pages for apache default server /var/www Set the TCP port on which the apache server will listen 80
Ismét állítsuk le, hogy ne zavarjon a kongurálás ideje alatt. # /etc/init.d/apache stop
A
/etc/apache/httpd.conf
fájlba tegyük bele a következ® sort:
NameVirtualHost 192.168.10.247:80
Ez biztosítja annak a lehet®ségét, hogy egy IP címen több webszervert használhassunk. A
/etc/apache/conf.d könyvtárban kell elhelyeznünk a szükséges kongurációs állományo-
kat. A fájlok nevei nem lényegesek, de itt is célszer¶ a már sokszor emlegetett beszédes neveket alkalmazni. Tehát az intraweb kiszolgálásáért felel®s szerver kongurációs állományát nevezzük
intraweb-nek,
míg a wpad nev¶ webszerver állományának a neve legyen
wpad.1
És
most nézzük a fájlok tartalmát. Az
1
intraweb
fájl tartalma:
Ezt meg lehetne oldani egyetlen szerverrel (hiszen a ServerAlias opció segítségével megadhatnánk neki a
wpad.akarmi.intra nevet is), csak a példa kedvéért csináltam két virtuális szerverrel.
77
Debian GNU/Linux
78
ServerName intraweb.akarmi.intra ServerAlias intraweb ServerAdmin [email protected] ErrorLog /var/log/apache/intraweb-error.log CustomLog /var/log/apache/intraweb-access.log common DocumentRoot /var/www/intraweb/ AllowOverride None AllowOverride None Order allow,deny allow from all
A
wpad
fájl tartalma:
ServerName wpad.akarmi.intra ServerAlias wpad ServerAdmin [email protected] ErrorLog /var/log/apache/wpad-error.log CustomLog /var/log/apache/wpad-access.log common DocumentRoot /var/www/wpad/ AllowOverride None AllowOverride None Order allow,deny allow from all
/var/www/wpad könyvtárba kell elhelyeznünk proxy.pac kongurációs állományt (és a linkeket is). /etc/logrotate.d/apache fájlban látható, hogy azért érdemes
A fentiek alapján a
a 10.2. fejezetben
be-
mutatott A
.log kiterjesztést adni a
logfájljainknak, mert így automatikusan rotálódni fognak.
11.2.
Apache HTTPS-en apache segítségével létrehozni és üzemeltetni, libapache-mod-ssl csomag telepítése. Ez fel fogja tenni a openssl csomagot
Ha https-en elérhet® weboldalakat szeretnénk az akkor szükséges a
is, ha még nem lenne fent. # apt-get install libapache-mod-ssl
A csomag telepítésekor a
/etc/apache/modules.conf
fájlba bekerül a
mod_ssl.so,
tehát
be fogja tölteni a következ® újraindításkor. Az
ssl
fájl (HTTPS-t megvalósító) tartalma:
ServerName intraweb.akarmi.intra ServerAlias intraweb ServerAdmin [email protected] ErrorLog /var/log/apache/intraweb-ssl-error.log CustomLog /var/log/apache/intraweb-ssl-access.log common DocumentRoot /var/www/intraweb-ssl/ AllowOverride None AllowOverride None Order allow,deny allow from all SSLEngine SSLCertificateFile SSLCertificateKeyFile SSLCACertificateFile # # # #
on /etc/ssl/certs/intraweb.akarmi.intra.crt /etc/ssl/private/intraweb.akarmi.intra.key.nopass /etc/ssl/certs/CA.crt
cp intraweb.akarmi.intra.crt CA.crt /etc/ssl/certs/ cp intraweb.akarmi.intra.key.nopass /etc/ssl/private/ chmod 600 /etc/ssl/private/intraweb.akarmi.intra.key.nopass chmod 644 /etc/ssl/certs/*.crt
Kósa Attila
2009. március 23.
Debian GNU/Linux
79
Egy apró változtatást kell végrehajtanunk a
/etc/apache
könyvtárban lév®
httpd.conf
Port 80 opciót ki kell kommenteznünk, Listen 192.168.10.247:80 és a Listen 192.168.10.247:443 sorokat.
fájlunkon is, hogy http-n és https-en is elérhet® legyen. A és helyette be kell írnunk a
Figyeljünk arra, hogy ebben az esetben a localhoston (a 127.0.0.1-es IP címen) nem fog válaszolni a szerverünk!
2009. március 23.
Kósa Attila
Debian GNU/Linux
80
Kósa Attila
2009. március 23.
12. fejezet
Naplózás
Központi logszerver beállításáról, valamint az összegy¶jtött logok automatikus elemzésér®l szól ez a fejezet. A logok távoli szerverre történ® eljuttatása fontos dolog, például egy esetleges betörés alkalmával lehet®séget nyújthat annak rekonstruálására, hogy mi is történt a megtámadott gépen, még akkor is, ha a támadó eltünteni az adott gépen a behatolás nyomait. A logok meg®rzése akár törvényi kötelezettségként is jelentkezhet! Egyrészt azért célszer¶ a központi logszerveren végezni a logok elemzését, mert így nem szükséges diszkterületet, processzorid®t és memóriát (egyszóval er®forrásokat) áldozni minden egyes gépen erre a feladatra. Másrészt így a logelemzést végz® szoftvert és a keresési feltételeket csak egyetlen helyen kell karbantartani.
12.1.
logcheck
A logok elemzésére a
logcheck
nev¶ programcsomagot használhatjuk. Telepítése egyszer¶en
az alábbi paranccsal végezhet® el (feltételezem, hogy
a 8.1.5. fejezetben
leírtak már készen
vannak): # apt-get install logcheck logcheck-database
Figyelembe kell vennünk, hogy a
logcheck
alapbeállítások esetén a logcheck nev¶ felhasz-
náló (és a logcheck nev¶ csoport) nevében fut, ezért az elemezni kívánt logokhoz olvasási jogokat kell biztosítani, illetve a logokat tartalmazó könyvtárakhoz is a megfelel® jogokat kell biztosítanunk. Mivel a
logcheck pontosan ismeri az elemzésre kijelölt fájlok nevét, ezért nem szükséges
olvasási jogot is adnunk a könyvtárakra, elég a végrehajtási jog, de a fájlokra olvasási jogot kell beállítanunk. Ennek a kongurálása látható a szerverr®l szóló 12.4.1. fejezetben lon). A
logcheck
/etc/logcheck könyvtárban található az ehhez logcheck.logfiles. A logcheck.logfiles fájlban állományokat, amelyekben szeretnénk, ha keresne a logcheck. Az
is kongurálásra szorul. A
szükséges 2 fájl, a
logcheck.conf
kell felsorolnunk azokat az összes szerverünk
syslog
és a
fájlját vegyük fel a következ®képpen (a sorrend lényegtelen):
/var/log/GEPEK/127.0.0.1/syslog /var/log/GEPEK/192.168.10.254/syslog /var/log/GEPEK/192.168.10.253/syslog /var/log/GEPEK/192.168.10.252/syslog /var/log/GEPEK/192.168.10.251/syslog /var/log/GEPEK/192.168.10.250/syslog /var/log/GEPEK/192.168.10.249/syslog /var/log/GEPEK/192.168.10.248/syslog /var/log/GEPEK/192.168.10.247/syslog
A
(a 84. olda-
logcheck.conf
fájlt javítsuk ki ízlésünknek megfelel®en, például ilyenre:
81
Debian GNU/Linux
82
DATE="$(date +'%Y-%m-%d %H:%M')" INTRO=0 REPORTLEVEL="server" SENDMAILTO="[email protected]" FQDN=1 SORTUNIQ=0 SUPPORT_CRACKING_IGNORE=1 RULEDIR="/etc/logcheck" SYSLOGSUMMARY=0 ATTACKSUBJECT="Attack Alerts" SECURITYSUBJECT="Security Events" EVENTSSUBJECT="System Events" ADDTAG="yes"
Ennek eredményeként az alábbihoz hasonló fejléc¶ e-mail-eket fogunk kapni: Date: Wed, 4 Apr 2007 22:03:49 +0200 (CEST) From: [email protected] (logcheck system account) To: [email protected] Subject: [logcheck] syslog.akarmi.intra 2007-04-04 22:02 System Events
A
REPORTLEVEL változó alapértelmezésben a server értéket tartalmazza. Két másik váworkstation és a paranoid. Ehhez kapcsolódnak a ignore.d.* könyv-
lasztási lehet®ségünk van, a
tárak. Ezen könyvtárak (pontosabban az ezekben a könyvtárakban lév® fájlok tartalma) segítségével tudjuk azt beállítani, hogy milyen logrészleteket hagyjon gyelmen kívül a
logcheck,
melyeket ne tegyen bele az elküldött e-mail-be. Célszer¶nek látszik, ha nem a disztribúció csomagjai által odatett fájlokba írjuk bele, hogy mi nem érdekel bennünket, mert egy esetleges frissítés alkalmával ezen fájlok felülíródhatnak, és ezzel elveszítenénk a saját bejegyzéseinket. Ezért hozzunk létre egy fájlt a megfelel® könyvtárban (a
REPORTLEVEL
változó által meg-
határozott könyvtárban), és abba tegyük saját bejegyzéseinket.
12.2.
logrotate
12.2.1.
A szerveren
Ne felejtsük el, hogy amiatt, hogy a
syslog-ng-vel
az alapbeállításoktól eltér®en tároljuk (a
logszerveren) a logokat, módosítanunk kell a logok rotálását végz® program kongurációs állományát. Ez a
/etc/logrotate.d/syslog-ng
fájl. Írjuk át az alábbira:
/var/log/GEPEK/192.168.10.*/syslog { rotate 7 daily compress } /var/log/GEPEK/192.168.10.*/postfix { rotate 7 daily compress } /var/log/GEPEK/127.0.0.1/postfix { rotate 7 daily compress } /var/log/GEPEK/127.0.0.1/syslog { rotate 7 daily compress postrotate /etc/init.d/syslog-ng reload >/dev/null endscript }
Ez minden nap el fogja rotálni a logfájlokat, tömöríteni fogja ®ket, de mindig csak az utolsó 7 nap logja fog megmaradni, a régebbiek törl®dnek.
12.2.2.
A klienseken
A klienseken nincs szükség ilyen átkongurálásra, mert ott marad a
syslog
fájl a
/var/log
könyvtárban. Tehát ott mindössze ennyit kell tartalmaznia a fenti állománynak (a felesleges sorokat töröljük ki bel®le nyugodtan):
Kósa Attila
2009. március 23.
Debian GNU/Linux
83
/var/log/syslog { rotate 7 daily compress postrotate /etc/init.d/syslog-ng reload >/dev/null endscript }
12.3.
pogsumm
Telepítsük fel a
postfix
logjainak az elemzésére alkotott szoftvert:
# apt-get install pflogsumm # zcat /var/log/GEPEK/192.168.10.252/postfix.1.gz | \ pflogsumm -d yesterday -i --problems_first -q --smtpd_stats | \ mailx -s "Levelezési statisztika: `/bin/date --date '-1 day' +%Y%m%d`" [email protected]
A fenti parancs hatására kapunk egy ilyen e-mail-t (jó esetben nem ennyire üreset, hanem hasznos adatokat tartalmazót): Date: Wed, 4 Apr 2007 22:44:55 +0200 (CEST) From: [email protected] (root) To: [email protected] Subject: Levelezési statisztika: 20070403 Postfix log summaries for Apr 3 Grand Totals -----------messages 0 0 0 0 0 0 0 0 0
received delivered forwarded deferred bounced rejected (0%) reject warnings held discarded (0%)
0 0 0 0 0 0
bytes received bytes delivered senders sending hosts/domains recipients recipient hosts/domains
smtpd 0 0 0 0:00:00
connections hosts/domains avg. connect time (seconds) total connect time
Fatal Errors: none Panics: none Per-Hour Traffic Summary time received delivered deferred bounced rejected -------------------------------------------------------------------0000-0100 0 0 0 0 0 0100-0200 0 0 0 0 0 0200-0300 0 0 0 0 0 0300-0400 0 0 0 0 0 0400-0500 0 0 0 0 0 0500-0600 0 0 0 0 0 0600-0700 0 0 0 0 0 0700-0800 0 0 0 0 0 0800-0900 0 0 0 0 0 0900-1000 0 0 0 0 0 1000-1100 0 0 0 0 0 1100-1200 0 0 0 0 0 1200-1300 0 0 0 0 0 1300-1400 0 0 0 0 0 1400-1500 0 0 0 0 0 1500-1600 0 0 0 0 0 1600-1700 0 0 0 0 0 1700-1800 0 0 0 0 0 1800-1900 0 0 0 0 0 1900-2000 0 0 0 0 0 2000-2100 0 0 0 0 0 2100-2200 0 0 0 0 0 2200-2300 0 0 0 0 0 2300-2400 0 0 0 0 0 Host/Domain Summary: Message Delivery sent cnt bytes defers avg dly max dly host/domain
2009. március 23.
Kósa Attila
Debian GNU/Linux
84
-------- ------- ------- ------- ------- ----------Host/Domain Summary: Messages Received msg cnt bytes host/domain -------- ------- ----------Per-Hour SMTPD Connection Summary hour connections time conn. avg./conn. max. time -------------------------------------------------------------------Host/Domain Summary: SMTPD Connections connections time conn. avg./conn. max. time host/domain ----------- ---------- ---------- --------- -----------
Ha m¶ködik, és ezt szeretnénk, akkor már csak el kell helyeznünk például a könyvtárban, egy
12.4.
pflogsumm
1 a fenti parancsokat.
/etc/cron.daily
nev¶ fájlban
syslog-ng
12.4.1.
A szerveren
Azért javaslom a magyar fejlesztés¶
syslog-ng csomagot, mert sokoldalúbban kongurálható, sysklogd és klogd csomagok. Ezek a csomagok ütköznek
mint a gyárilag a disztribúcióban lév®
a felrakni kívánt csomaggal, ezért ezeket le kell takarítanunk. Ehhez a következ® parancsokat kell kiadnunk: # # # #
apt-get install syslog-ng dpkg --purge sysklogd klogd cd /var/log && mkdir GEPEK && chmod 710 GEPEK && chown 0:logcheck GEPEK /etc/init.d/syslog-ng stop
Miel®tt elindítanánk a
syslog-ng-t,
a
/etc/syslog-ng
könyvtárba másoljuk be az alábbi
kongurációs állományt. options
{ sync(0); time_reopen(10); log_fifo_size(1000); long_hostnames(off); use_dns(no); use_fqdn(no); create_dirs(yes); dir_perm(0710); dir_group(logcheck); keep_hostname(yes); stats_freq(0); };
source src { unix-stream("/dev/log" max_connections(200)); internal(); tcp(ip(192.168.10.249) port(514) max-connections(10)); file("/proc/kmsg"); }; filter y_postfix
{
match("postfix");
};
destination syslog { file("/var/log/GEPEK/$SOURCEIP/syslog" perm(0640) group("logcheck") ); }; destination postfix { file("/var/log/GEPEK/$SOURCEIP/postfix" perm(0600) ); }; log { source(src); destination(syslog); }; log { source(src); filter(y_postfix); destination(postfix); };
/var/log/GEPEK/$SOURCEIP könyv$SOURCEIP változót a syslog-ng képes ki-
Lássuk, mi történik a logjainkkal ennek hatására. A tárban lév®
syslog
fájlba minden log bekerül. A
fejteni és a logot küld® gép IP címét behelyettesíteni. Ezáltal a logokat gy¶jt® szerveren minden gépnek saját könyvtárba kerülnek a logjai, ezzel is követhet®bbé válik a logolás. A
ter y_postx
kezdet¶ sorban látható
postx
l-
egyezés (match) által meghatározott logok kerül-
/var/log/GEPEK/$SOURCEIP könyvtárban lév® postfix fájlba (de ezek is bekerülnek a /var/log/GEPEK/$SOURCEIP/syslog fájlba!). A perm opció azért felel, hogy a létrejöv® állo-
nek a
mány jogosultságai 0640-ra legyenek beállítva. A
group opcióval a létrejöv® állomány csoporttu-
lajdonosát állíthatjuk be. Gyakorlatilag szétszedhetjük a logokat tetsz®leges elvek szerint, a fenti csak egy példa. Azért javaslom a TCP használatát UDP helyett, mert az UDP nem megbízható kapcsolat, ezért el®fordulhat, hogy elvesznek logok.
12.4.2. A
A klienseken
/etc/syslog-ng/syslog-ng.conf 1
fájl tartalma a klienseken:
Más nevet is választhatunk.
Kósa Attila
2009. március 23.
Debian GNU/Linux options
source src
85
{ sync(0); time_reopen(10); log_fifo_size(1000); long_hostnames(off); use_dns(no); use_fqdn(no); create_dirs(no); keep_hostname(yes); stats_freq(0); }; { unix-stream("/dev/log" max_connections(200)); internal(); file("/proc/kmsg"); };
destination syslog { file("/var/log/syslog" perm(0600) ); }; destination loghost { tcp( 192.168.10.249 port(514) ); }; log { source(src); log { source(src);
destination(loghost); }; destination(syslog); };
Minden log a
/var/log/syslog
fájlba kerül, valamint átkerül a 192.168.10.249 IP cím¶
központi logszerverre (az IP cím helyett írhattunk volna gépnevet is). A klienseken nincs szükség, hogy a
root-on
kívül bárkinek olvasási jogot biztosítsunk a logfájlra, hiszen az elemzést végz®
program a központi logszerveren fut.
2009. március 23.
Kósa Attila
Debian GNU/Linux
86
Kósa Attila
2009. március 23.
13. fejezet
Mentés
Egyszer¶ feladatot vázoltam fel ebben a fejezetben. Egy távoli gép meghatározott könyvtárát kell minden nap teljes egészében lementeni merevlemezre, a hónap utolsó napján pedig szalagos meghajtóra. De ez az egyszer¶ség nem jelenti azt, hogy a bemutatott program mindössze erre lenne képes.
13.1.
13.1.1.
Amanda
A kliens telepítése és beállítása
A kliens szoftver telepítése el®tt kénytelenek vagyunk valamilyen levelez®szervert felrakni, mert az
amanda-client
nyozzuk
függ®ségei között szerepel valamilyen MTA. Ehhez a feladathoz tanulmá-
a 8.1.5. fejezetet
(persze a megfelel® módosításokat értelemszer¶en hajtsuk végre).
# apt-get install amanda-client
A telepítés közben látható, hogy a
az
amanda-common
backup felhasználót hozzáadja a disk és a tape csoporthoz
csomag postinst szkriptje.
Setting up amanda-common (2.5.1p1-2.1) ... Adding user `backup' to group `disk' ... Done. Adding user `backup' to group `tape' ... Done.
Szükség van
inetd-re (vagy xinetd-re) a kliensen is az Amanda m¶ködéséhez. Az alábbi sor /etc/inetd.conf fájlba:
kerül bele a fenti telepítéskor a
amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad
Ne felejtsük el elindítani az képes! A
netstat -napu
parancs kimenetében látható, hogy a 10080-as porton gyel az
pontosabban az általa felügyelt A
openbsd-inetd démont, különben az amanda nem lesz m¶köd®amanda.
inetd,
/etc/amandahosts fájlba be kell írni a mentést végz® gép teljes nevét, valamint a mentést localhost backup páros, de ki
végz® felhasználó nevét. Alapértelmezésben szerepel benne a kell egészítenünk, hogy az alábbi módon nézzen ki: localhost backup backup.akarmi.intra backup
Az
exclude-list
opciónak megadott fájlnak (a szerveren a
exclude.gtar
nevet adtuk meg),
léteznie kell a kliensen is (a megfelel® elérési útvonalon). A kliens telepítése nem hozza ezt létre (mivel nem tudhat róla, hogy a szerveren mi mit állítottunk be), tehát nekünk kell ezt megtennünk.
87
Debian GNU/Linux
88
# # # # # #
mkdir touch touch chmod chmod chown
/etc/amanda /etc/amanda/exclude.gtar /etc/amanda/amanda-client.conf 0770 /etc/amanda 440 /etc/amanda/exclude.gtar /etc/amanda/amanda-client.conf -R backup:backup /etc/amanda
Az
amanda-client.conf
nev¶ fájlba írjuk bele az alábbiakat:
conf "napi_backup" index_server "backup.akarmi.intra" tape_server "backup.akarmi.intra" auth "ssh" ssh_keys "/root/.ssh/id_rsa_amrecover"
Ezzel a kliens beállításával készen is vagyunk. A kliens mentéséhez a szerveren (a megfelel®
disklist
fájlban) kell megadnunk, hogy mit is szeretnénk menteni a kliensr®l.
13.1.2.
A szerver telepítése
A szerver telepítése: # apt-get install amanda-server
Ez felteszi az
amanda-server
és
együtt). A telepítés közben látható, hogy a
az
amanda-common
amanda-common
csomagokat (persze az összes függ®séggel
backup felhasználót hozzáadja a disk és a tape csoporthoz
csomag postinst szkriptje.
Setting up amanda-common (2.5.1p1-2.1) ... Adding user `backup' to group `disk' ... Done. Adding user `backup' to group `tape' ... Done.
Ha a mentést végz® gépr®l is szeretnénk mentést készíteni, akkor fel kell telepítenünk a
amanda-client
csomagot is.
# apt-get install amanda-client
Szükség van
inetd-re
(vagy
xinetd-re) a szerveren is az Amanda /etc/inetd.conf fájlba:
m¶ködéséhez. Az alábbi
sorok kerülnek bele a fenti telepítéskor a
amandaidx stream tcp nowait backup /usr/sbin/tcpd /usr/lib/amanda/amindexd amidxtape stream tcp nowait backup /usr/sbin/tcpd /usr/lib/amanda/amidxtaped amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad
Ne felejtsük el elindítani az képes! A
netstat -napu
openbsd-inetd démont, különben az amanda nem lesz m¶köd®-
parancs kimenetében látható, hogy a 10080-as porton gyel az
amanda. A netstat -natp kimenetében pedig /etc/services fájlban tudjuk megnézni, hogy
inetd,
pontosabban az általa felügyelt
az 10082-es és
10083-as portok láthatóak. A
melyik portot
melyik szolgáltatás használja. A telepítés után a
/etc/amanda könyvtárban találunk egy fájlt (crontab.amanda) DailySet1 könyvtár két fájlt tartalmaz, egy amanda.conf
könyvtárat (DailySet1). A
disklist
és egy és egy
nev¶t. Mindezek csak minták, hasonlóakat kell létrehoznunk ahhoz, hogy m¶köd®
mentési rendszerünk legyen. A
/etc/amanda
könyvtárban hozzunk létre egy könyvtárat (cél-
szer¶nek t¶nik aszerint elnevezni, amilyen célt fog szolgálni, például a napi mentésekhez adjuk
napi_backup nevet). A napi_backup könyvtárba fogjuk létrehozni saját amanda.conf és disklist fájlunkat. A havi mentésekhez hozzunk létre egy új könyvtárat, például havi_backup néven. Ebben is ugyanúgy létre kell majd hoznunk saját amanda.conf és disklist fájlunkat. neki a
Nem szabad elfelejtenünk, hogy a backup felhasználónak és csoportnak kell adnunk a könyvtárakat és fájlokat! Erre azért van szükség, mert ezekben a könyvtárakban adminisztrálja az Amanda
tapelist, tapelist.amlabel, tapelist.yesterday, changer-slot nev¶ fájlokban). Hozzuk létre a szüksé-
a szalagokkal kapcsolatos dolgokat (a
changer-access, changer-clean,
és
ges könyvtárakat, valamint állítsuk be a tulajdonosukat és a jogosultságokat.
Kósa Attila
2009. március 23.
Debian GNU/Linux
89
# mkdir -p /etc/amanda/napi_backup /etc/amanda/havi_backup /holding /backup /var/lib/amanda/napi_backup/curinfo /var/lib/amanda/napi_backup/index \ /var/lib/amanda/napi_backup/log /var/lib/amanda/havi_backup/curinfo /var/lib/amanda/havi_backup/index /var/lib/amanda/havi_backup/log \ /var/log/amanda/napi_backup/log /var/log/amanda/havi_backup/log # touch /etc/amanda/exclude.gtar /etc/amanda/napi_backup/tapelist /etc/amanda/havi_backup/tapelist # chmod -R 0770 /holding /backup /etc/amanda/napi_backup /etc/amanda/havi_backup /var/lib/amanda/napi_backup /var/lib/amanda/havi_backup \ /var/log/amanda/napi_backup/log /var/log/amanda/havi_backup/log # chmod 0440 /etc/amanda/exclude.gtar # chmod 0660 /etc/amanda/napi_backup/tapelist /etc/amanda/havi_backup/tapelist # chown -R backup:backup /holding /backup /etc/amanda/napi_backup /etc/amanda/havi_backup /var/lib/amanda/napi_backup/ /var/lib/amanda/havi_backup \ /etc/amanda/exclude.gtar /var/log/amanda/napi_backup/log /var/log/amanda/havi_backup/log
13.1.3. A
Általános kongurációs beállítások
/var/backups könyvtárban található egy .amandahosts nev¶ link, amely a /etc könyvtárban amandahosts fájlra mutat. Már szerepel benne a localhost backup páros, de egészítsük
lév®
ki a következ®képpen: localhost backup backup.akarmi.intra backup
Tehát a gép teljes nevét, és a backup felhasználói nevet kell feltüntetni. A mentési stratégia kialakításában viszonylag szabad kezünk van. Lehet®ségünk van a mentésre alkalmazandó program kiválasztására (jellemz®en a de a
dump
dump
és a
tar
programot használjuk,
esetén ellen®rizni kell, hogy képes-e a fájlrendszerünk mentésére).
Meglehet®sen sok opciót használhatunk, de csak a példában használtak magyarázatát olvashatjuk alább:
comment
Csak megjegyzés megadására szolgál.
compress
A tömörítési módszer megadása. Az alábbi lehet®ségekb®l választhatunk (az alap-
értelmezés a
compress client fast ):
none Nincs tömörítés. client best A kliens gépen történik a tömörítés és a legjobb tömörítési módot használja. client fast A kliens gépen történik a tömörítés és a leggyorsabb tömörítési módot használja.
server best A szerver gépen történik a tömörítés és a legjobb tömörítési módot használja. server fast A szerver gépen történik a tömörítés és a leggyorsabb tömörítési módot használja.
index
Indexfájlokat hoz létre, amelyekben kereshetünk.
exclude-list
Ennek az opciónak egy fájlt lehet megadni (most az
exclude.gtar
nev¶t adtuk
meg), amelyben azokat a fájlokat és könyvtárakat adhatjuk meg, amelyeket ki akarunk hagyni a mentésb®l. Nézzünk erre is egy példát: ./proc/* ./tmp/*
Magának a fájlnak mindenképpen léteznie kell, akár üresen is. Figyelni kell arra, hogy (a
tar miatt, mert leszedi a / -t a mentés elejér®l) . (pont)-tal kell kezdeni az elérési útvonalak megadását. Ha csak annyit írnánk, hogy
./proc,
akkor a könyvtár neve sem kerül bele
a mentésbe. Ha azt szeretnénk, hogy a könyvtár neve benne legyen a mentésben, de a tartalma nem, akkor a fent kiemelt példának megfelel®en kell megadni a könyvtár nevét. Ennek a visszaállításkor lehet jelent®sége, nem árt erre gyelni. A fentieken kívül lehet®ségünk van meghatározni egy prioritási szintet. A
high
low, medium
és
lehet®ségek közül választhatunk. Ezeknek akkor van jelent®ségük, amikor az Amandának
nem áll rendelkezésére szalag a mentéshez valamilyen hiba miatt. Ekkor a magasabb prioritású kerül el®ször mentésre.
2009. március 23.
Kósa Attila
Debian GNU/Linux
90
A mentend® könyvtárakat (partíciókat) is meg kell határoznunk. Ehhez a
disklist fájlt kell
megszerkesztenünk. Ebben a következ®knek kell egy sorba kerülniük: gep_neve /mentendo strategia
gep_neve elég egyértelm¶, a mentend® gép nevét kell megadni (én a domain részt nem /mentendo már érdekesebb, itt megadhatunk könyvtárnevet, illetve partíciónevet is. Tehát az sdb2 is érvényes (használható) deníció. A strategia helyére írhato dolgokat az amanda.conf fájlban találhatjuk meg (illetve hozhatjuk létre) dumptypes címszó alatt. A
írtam oda). A
Például ahhoz, hogy a
dns nev¶ gép /etc könyvtárát le tudjuk menteni a saját stratégiánkdisklist fájlunkba.
kal, a következ®ket kell beleírni a dns /etc teljes_mentes
Az Amandának szüksége van néhány MB-nyi területre, ahol a log, debug és index fájlokat tárolja. Ezek nagyra meg tudnak n®ni, ezért nem ajánlott a tárolni ®ket. Ezen fájlok helyének beállítására szolgálnak az az
amanda.conf
fájlban.
A mentés automatizálásához a
/etc/amanda
infole, logle
és
könyvtárban
indexdir
opciók
cron segítségét kell igénybe vennünk. A /etc/cron.d könyvmentes néven), amelyben határozzunk meg id®pontot
tárban hozzunk létre egy fájlt (például
(vagy id®pontokat) a szalagok ellen®rzésére, valamint a tényleges mentésre. Az alábbihoz hasonlóaknak kell szerepelnie ebben a fájlban. 0 10,15 * * mon-fri backup /usr/sbin/amcheck -a napi_backup 55 22 * * mon-fri backup /usr/sbin/amdump napi_backup
Ezzel azt érjük el, hogy hétf®t®l péntekig minden nap (beleértve a hétf®t és a pénteket is) pontosan 10 és 15 órakor lefusson az
amcheck,
ily módon ellen®rizve azt, hogy a következ®
mentésnek megfelel® szalag található-e a meghajtóban és mindenképpen küldjön e-mail-t az ellen®rzés eredményér®l (a
-a
opció hatására). A
-a
opció helyett használhatjuk a
amely csak probléma esetén küld e-mail-t. A mentés (az
-m
opciót,
amdump futása) hétf®t®l péntekig minden
este 22 óra 55 perckor indul (amelynek eredményér®l szintén e-mail-ben kapunk jelentést, az
amanda.conf
13.1.4.
fájl
mailto
opciójában megadott címre vagy címekre).
Merevlemezre történ® mentés
Ehhez úgynevezett virtuális szalagos egységet kell létrehoznunk. Menjünk végig ennek a folyamatnak a lépésein. Fentebb már létrehoztunk egy
/backup nev¶ könyvtárat, hogy ebbe mountoljuk a mentések
tárolására szolgáló lemezegységet. A fájlrendszerek általában rosszul viselik, ha a telítettség meghaladja a 90%-ot, ezért ajánlott a következ® képletet gyelembe venni a szükséges diszkterület kiszámításához:
(elérhet®
terület
∗ 0.9) >= szalaghossz ∗ szalagszám.
Például egy 20 GB-os merevlemez esetén ez a következ®ket jelenti:
20 GB ∗ 0.9 = 18 GB.
Tehát a következ® lehet®ségeink vannak:
18 GB = 18 GB ∗ 1 18 GB = 9 GB ∗ 2 18 GB = 6 GB ∗ 3 18 GB = 3 GB ∗ 6 Létre kell hozni egy
stb.
tapetype deníciót a merevlemezhez. Az alábbi egy 3 GB-os szalag-nak
megfelel® egységet határoz meg:
Kósa Attila
2009. március 23.
Debian GNU/Linux
91
define tapetype HARD-DISK { comment "Mentes merevlemezre" length 3072 mbytes }
Nem kötelez® használni a
speed
opciót, ugyanis az Amanda nem használja ezt. A
lemark
opció használata sem kötelez®, alapértelmezetten 1 KB-os értéket tételez fel. Mivel merevlemez esetén meglehet®sen nehézkes lenne cserélgetni a diszkeket, ezért célszer¶ úgy megoldani, hogy az Amanda automatikusan váltogassa a mentéshez használt könyvtárakat (mint szalagos meghajtó esetén a szalagokat). Ehhez a csomagban lév® (a könyvtárban helyet foglaló)
chg-disk
szkriptet használjuk.
Lássuk, hogy mi is kell egy diszkre történ® mentés esetén az
/usr/lib/amanda
amanda.conf
fájlunkba.
org "Napi diszkre mentes" mailto "[email protected]" usetimestamps dumpuser "backup" inparallel 4 dumporder "BTBTBTBT" taperalgo first displayunit "k" netusage 600 Kbps dumpcycle 1 weeks runspercycle 5 tapecycle 5 tapes bumpsize 20 MB bumppercent 20 bumpdays 1 bumpmult 4 etimeout 300 dtimeout 1800 ctimeout 30 tapebufs 20 runtapes 1 tapedev "file:/backup/napi_backup" rawtapedev "file:/backup/napi_backup" changerdev "/dev/null" tpchanger "chg-disk" changerfile "/etc/amanda/napi_backup/changer" maxdumpsize -1 tapetype HARD-DISK labelstr "^NAPIBACKUP[0-9][0-9]*$" amrecover_do_fsf yes amrecover_check_label yes amrecover_changer "file:/backup/napi_backup" autoflush no infofile "/var/lib/amanda/napi_backup/curinfo" logdir "/var/log/amanda/napi_backup/log" indexdir "/var/lib/amanda/napi_backup/index" define tapetype HARD-DISK { comment "Mentes diszkre" length 3072 mbytes } define dumptype global { comment "Global definitions" holdingdisk never auth "ssh" ssh_keys "/var/backups/.ssh/id_rsa_amdump" } define dumptype teljes_mentes { global program "GNUTAR" comment "Teljes mentes tar-ral" compress none index exclude list "/etc/amanda/exclude.gtar" priority high dumpcycle 0 }
Merevlemezre történ® mentés esetén nem érdemes átmeneti (holding) területet megadni. Ugyanis el®ször oda hozná létre a mentést az Amanda és onnan másolná át a szalagként funkcionáló könyvtárba. Ezáltal egy mentés kétszer foglalná a helyet a merevlemezen, valamint felesleges terhelést okozna a diszknek maga a másolás (hiszen els®re is oda hozná létre a mentést).
1
És a kongurációs állományhoz tartozó magyarázatok :
org 1
Az ide beírt adat fog megjelenni az e-mail-ek tárgy mez®jében (subject), amelyeket az
amcheck
és az
amdump
fog küldeni.
Még hiányzik néhány.
2009. március 23.
Kósa Attila
Debian GNU/Linux
92
mailto
Az itt megadott e-mail címre fognak érkezni az e-mail-ek. Felsorolhatunk több címet
is, szóközökkel elválasztva.
usetimestamps
Ezen opciót akkor kell használnunk, ha egy nap több mentést is szeretnénk
készíteni. Használatakor ugyanis nem csak az év, hónap és nap kerül bele a mentés címkéjébe, hanem az óra, perc és másodperc is.
dumpuser inparallel
Ennek a felhasználónak a nevében fognak futni az
amcheck és az amdump processzek.
Azt szabályozza, hogy hány mentés futhat párhuzamosan (maximum 63 állítható
be).
netusage
KB/másodpercben megadott érték, amely a hálózat maximális terhelését adja meg.
dumpcycle tapecycle
Egy mentési ciklus alatti napok száma.
A mentési körforgásban használt szalagok száma.
etimeout
Ennyi másodpercet kap a fájlrendszer becslésére.
dtimeout
Ennyi másodpercet vár miel®tt a mentést megszakítottnak tekinti.
ctimeout
Maximum ennyi másodpercet vár az
runtapes
A szalagok száma, hogy mennyit használhat az
tapedev
amcheck
a mentend® kliensre.
amdump
a futása közben.
A mentésre használt eszköz megnevezése, fontos, hogy norewinding eszköz nevét kell
itt megadni. Ugyanis Linux alatt többféleképpen is meg lehet szólítani a szalagos meghajtót. Tehát: a
/dev/st0 az az univerzális
(mindentudó) meghajtónév, a
a norewinding eszköz neve. Mentéskor a
/dev/nst0,
eszköznevet kell használnunk. Ez utóbbi használatára a 96. oldalon
tapetype labelstr
/dev/nst0 pedig /dev/st0
visszaállításkor pedig a
láthatunk példát.
Itt határozzuk meg, hogy melyik kés®bb deniált meghajtót szeretnénk használni.
A labelstr sorba azt kell beírni, hogy hogyan akarjuk nevezni a szalagjainkat. Ez abban
lesz segítségünkre, hogy csak a következ® szalagra fog írni az Amanda, nem fogja felülírni az éppen lementett anyagainkat.
infole logdir
Az adatbázis tárolására szolgáló könyvtárak helyének beállítása. A mentésekr®l szóló logfájlok tárolására szolgáló könyvtár beállítása.
indexdir
A mentésekben történ® kereséseket segít® indexállományok tárolására szolgáló könyv-
tár beállítása. Nem minden mentési stratégia hoz létre indexállományokat.
dene tapetype
A ment®egység adatainak meghatározása. Ebb®l többet is deniálhatunk, de
a neveknek egyedieknek kell lenniük.
dene dumptype
A mentési stratégia meghatározása. Ebb®l többet is deniálhatunk, de a
neveknek egyedieknek kell lenniük. Ezek a deníciók egymásba is ágyazhatóak, amelyet a
global
deníció mutat be.
Ha az összes kongurációs opciót látni szeretnénk, akkor adjuk ki az alábbi parancsot (a teljes kimenetet nem idézem be, mert elég hosszú): # su - backup $ amadmin napi_backup config | less
Ezután létre kell hoznunk a szalagokat mintázó könyvtárakat, amelyekbe a mentések fognak kerülni.
Kósa Attila
2009. március 23.
Debian GNU/Linux # # # # # # #
93
mkdir /backup/napi_backup cd /backup/napi_backup touch info for i in `seq 5` ; do mkdir slot$i ; done ln -s slot1 data chown -R backup:backup /backup/napi_backup chmod -R 750 /backup/napi_backup
Még fel kell címkéznünk a szalagokat, hogy az Amanda is tudjon róluk. Ezt már backup userként kell végrehajtanunk (csakúgy, mint igazi szalagok esetén). # su - backup $ /usr/sbin/amlabel napi_backup NAPIBACKUP01 slot 1 labeling tape in slot 1 (file:/backup/napi_backup): rewinding, reading label, not an amanda tape (Read 0 bytes) rewinding, writing label NAPIBACKUP01, checking label, done. $ /usr/sbin/amlabel napi_backup NAPIBACKUP02 slot 2 labeling tape in slot 2 (file:/backup/napi_backup): rewinding, reading label, not an amanda tape (Read 0 bytes) rewinding, writing label NAPIBACKUP02, checking label, done. $ /usr/sbin/amlabel napi_backup NAPIBACKUP03 slot 3 labeling tape in slot 3 (file:/backup/napi_backup): rewinding, reading label, not an amanda tape (Read 0 bytes) rewinding, writing label NAPIBACKUP03, checking label, done. $ /usr/sbin/amlabel napi_backup NAPIBACKUP04 slot 4 labeling tape in slot 4 (file:/backup/napi_backup): rewinding, reading label, not an amanda tape (Read 0 bytes) rewinding, writing label NAPIBACKUP04, checking label, done. $ /usr/sbin/amlabel napi_backup NAPIBACKUP05 slot 5 labeling tape in slot 5 (file:/backup/napi_backup): rewinding, reading label, not an amanda tape (Read 0 bytes) rewinding, writing label NAPIBACKUP05, checking label, done.
Lehet®ségünk van a szalagok cserélgetésére is: # # 5 # 1
cd /etc/amanda/napi_backup /usr/lib/amanda/chg-disk -current file:/backup/napi_backup /usr/lib/amanda/chg-disk -next file:/backup/napi_backup
A címkézés után az ötödik szalag van a meghajtóban (mint a fentebbi példában látható), esetleg érdemes lehet átállítani a nekünk szükséges számú szalagra. Teszteljük le a virtuális meghajtónkat: # su - backup $ ammt -f file:/backup/napi_backup/ status file:/backup/napi_backup/ status: ONLINE
Ha reseteljük a virtuális meghajtónkat, akkor az els® szalag tölt®dik be. # su - backup $ amtape napi_backup reset amtape: changer is reset, slot 1 is loaded.
Az
amcheck
(backup felhasználóként történ®) futtatásakor a következ®höz hasonló üzenetet
kapunk. # su - backup $ /usr/sbin/amcheck napi_backup Amanda Tape Server Host Check ----------------------------slot 1: read label `NAPIBACKUP01', date `X' NOTE: skipping tape-writable test Tape NAPIBACKUP01 label ok WARNING: tapecycle (5) <= runspercycle (5). NOTE: host info dir /var/lib/amanda/napi_backup/curinfo/dns does not exist NOTE: it will be created on the next run. NOTE: index dir /var/lib/amanda/napi_backup/index/dns does not exist NOTE: it will be created on the next run. Server check took 1.138 seconds Amanda Backup Client Hosts Check -------------------------------Client check: 1 host checked in 0.458 seconds, 0 problems found (brought to you by Amanda 2.5.1p1)
Láthatjuk, hogy melyik szalagra fog történni a következ® mentés. A
WARNING mindössze arra
gyelmeztet bennünket, hogy nincs tartalék ..szalagunk (hiba esetére), de mivel merevlemezre mentünk, felesleges lenne többet deniálni a használtnál (hiszen ha nem tudja használni, akkor a helyette használni kívánt sem m¶ködne, révén ugyanarról a diszkr®l van szó). A jegyzések arról tájékoztatnak, hogy az újonnan felvett géphez még nem létezik a
index
NOTE
curinfo
megés az
könyvtár.
2009. március 23.
Kósa Attila
Debian GNU/Linux
94
Host key verification failed. sor az amcheck üzenetében, known_hosts fájljában nem jó kulcs szerepel (vagy egyáltalán nem
Ha szerepel egy
backup
felhasználó
kulcs). Ekkor a 38. oldalon
akkor a szerepel
látható parancsot kell kiadnunk a megfelel® gép nevével.
Sikeres mentés esetén egy ehhez hasonló e-mail érkezik az
amdump
programtól:
From: backup To: [email protected] Subject: Napi diszkre mentes AMANDA MAIL REPORT FOR April 27, 2007 These dumps were to tape NAPIBACKUP01. The next tape Amanda expects to use is: a new tape. The next new tape already labelled is: NAPIBACKUP02. STATISTICS: Estimate Time (hrs:min) Run Time (hrs:min) Dump Time (hrs:min) Output Size (meg) Original Size (meg) Avg Compressed Size (%) Filesystems Dumped Avg Dump Rate (k/s)
Total -------0:00 0:00 0:00 1.3 1.2 -1 301.7
Tape Time (hrs:min) Tape Size (meg) Tape Used (%) Filesystems Taped Chunks Taped Avg Tp Write Rate (k/s) USAGE BY TAPE: Label NAPIBACKUP01
Time 0:00
Full --------
Incr. --------
0:00 1.3 1.2 -1 301.7
0:00 0.0 0.0 -0 --
0:00 1.3 0.1 1
0:00 1.3 0.1 1
0:00 0.0 0.0 0
0 275.9
0 275.9
0 --
Size 1312K
% 0.1
Nb 1
Nc 0
^L NOTES: planner: tapecycle (5) <= runspercycle (5) planner: Adding new disk dns:/etc. taper: tape NAPIBACKUP01 kb 1312 fm 1 [OK] ^L DUMP SUMMARY:
DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -------------------------- ------------------------------------- ------------dns /etc 0 1250 1312 -0:04 287.4 0:05 275.9 (brought to you by Amanda version 2.5.1p1)
Miután lefuttattuk az
amdump programot (backup felhasználóként),
használhatjuk az alábbi
parancsot (is) a mentés ellen®rzésére: # su - backup $ amadmin napi_backup find date host disk lv tape or file file part status 2007-04-27 21:54:09 dns /etc 0 NAPIBACKUP03 1 -- OK
Ami még érdekes (és hasznosnak t¶n®) volt, hogy a
length
paramétert gond nélkül tudtam
növelni két mentés között (tehát nem mentés közben!), semmilyen problémát nem jelentett az Amanda számára, szépen megértette, hogy a szalag mostantól kezdve hosszabb.
13.1.5.
Szalagos egység beállítása
amanda.conf fájlban, akkor egyszer¶en másoljuk /etc/amanda/havi_backup/amanda.conf fájlunkba. Ha nem szerepel, akkor le kell futtat-
Ha szerepel a szalagos egységünk az eredeti át a
nunk a következ® parancsot: # /usr/sbin/tapetype -f /dev/st0 -t MYDAT
Ez a parancs végigírja a szalagot, ezért csak olyat tegyünk bele, amin nincs fontos adat, mert minden letörl®dik róla! El®ször folyamatosan végigírja, másodszor pedig véletlenszer¶en ír, teker, majd megint ír. Meglehet®sen hosszú ideig tart a felismerés folyamata (például egy HP SureStore DAT40, 16508 MB-os szalag esetén körülbelül 4 óra). Ha végzett, akkor kiírja azokat az adatokat, amelyeket be kell írnunk a saját
amanda.conf
fájlunkba (a MYDAT nevet
én választottam, de bármi lehet, csak egyedi legyen):
Kósa Attila
2009. március 23.
Debian GNU/Linux
95
define tapetype MYDAT { comment "just produced by tapetype program" length 16508 mbytes filemark 452 kbytes speed 2610 kbytes }
Nézzük meg a szalagos mentéshez szükséges teljes kongurációs állományt. org "Havi szalagos mentes" mailto "[email protected]" dumpuser "backup" inparallel 4 dumporder " netusage 600 dumpcycle 6 weeks tapecycle 6 tapes bumpsize 20 MB bumpdays 1 bumpmult 4 etimeout 300 dtimeout 1800 ctimeout 30 runtapes 1 tapedev "/dev/nst0" tapetype MYDAT labelstr "^HAVISZALAG[0-9][0-9]*$" diskdir "/holding" disksize 200 MB infofile "/var/lib/amanda/havi_backup/curinfo" logfile "/var/lib/amanda/havi_backup/log" indexdir "/var/lib/amanda/havi_backup/index" define tapetype MYDAT { comment "just produced by tapetype program" length 16508 mbytes filemark 452 kbytes speed 2610 kbytes } define dumptype teljes_mentes { program "GNUTAR" comment "particiok mentese tar-ral" options index, exclude-list "/etc/amanda/exclude.gtar" priority high dumpcycle 0 maxcycle 0 }
A kongurációs állományból csak azokat az opciókat magyarázom el, amelyek eltérnek a merevlemezes mentés esetén alkalmazottaktól.
diskdir
Az itt megadott könyvtárban helyezi el az Amanda az átmeneti adatokat, miel®tt kiírná
®ket a szalagra. Ez akkor jön jól, ha a hálózaton keresztül több gépr®l kell összeszednünk a mentend® adatokat.
disksize
Az el®z® pontban megadott merevlemez-terület mérete.
Ahhoz viszont meg kell ismertetnünk az Amandával a szalagjainkat (fel kell címkéznünk ®ket), hogy tudja, melyik szalag a soron következ®. Ezt az alábbi paranccsal tudjuk megtenni: # su - backup $ /usr/sbin/amlabel havi_backup HAVISZALAG01
A
belstr
napi_szalag
a
/etc/amanda
könyvtárban lév® könyvtár, a
HAVISZALAG01
pedig a
la-
sorban megadott névnek megfelel® elnevezés.
Ellen®rizzük le az ily módon megcímkézett szalagot: # su - backup $ /usr/sbin/amcheck havi_backup
Ha hasonló a válasz, akkor jó minden: Amanda Tape Server Host Check ----------------------------/holding: 106474 KB disk space available, that's plenty. NOTE: skipping tape-writable test. Tape HAVISZALAG01 label ok. Server check took 0.008 seconds. Amanda Backup Client Host Check ------------------------------Client check: 1 host checked in 0.127 seconds, 0 problems found. (brought to you by Amanda 2.5.1p1)
2009. március 23.
Kósa Attila
Debian GNU/Linux
96
A
/holding: 106474 KB disk space available, that's plenty. sor azt jelenti, hogy a
kongurációs állományban (amanda.conf) megadott 200 MB átmeneti területb®l csak 106474 KB szabad.
13.1.6.
Visszaállítás
amrestore A mentett adatok visszaállítására használható használható egyik parancs (szalagos mentés esetén) a következ®: # su - backup $ /usr/sbin/amrestore -p /dev/st0 gep_neve /mentendo | /sbin/restore -i -v -f - -T /var/tmp
Figyelni kell arra, hogy itt eszköznévként a het oda-vissza tekergetni a szalagot). A világos, a
i v f
restore
és a
kell feltüntetni (azért, mert itt kell-
/mentendo
a fentiekb®l remélem, hogy
parancs kapcsolóinak magyarázata pedig a következ®:
Interaktív visszaállítást jelent. Az el®z® opcióhoz kapcsolódik, b®beszéd¶bbé teszi azt. Azt a fájlnevet el®zi meg, amelyb®l olvasni kell a mentést. A jelenti a
T
/dev/st0-t
gep_neve
restore
-
itt a pipe-ból érkez® adatokat
számára.
Ez után az opció után adhatjuk meg azt a könyvtárat, ahová az átmeneti állományok kerülhetnek. A fenti parancs kiadása után (viszonylag rövid id®n belül) kapunk egy parancssorhoz hasonló
promptot (/sbin/restore> kinézet¶t). Itt a
? billenty¶ lenyomására megkapjuk a használható
parancsok listáját. A visszaállításkor a történt. Ha
tar-ral,
/sbin/restore
abban az esetben jó, ha a mentés a
akkor hibát kapunk. Ilyen esetben a
tar-t
dump
segítségével
kell visszaállításra is használni.
Ellenben ha backup felhasználóként indítjuk a visszaállítást, akkor a
tar
nem tudja visszaál-
lítani az eredeti tulajdonosokat és jogokat. Erre viszont alkalmas a csomagban lév® wrapper (/usr/lib/amanda/runtar).
amrecover amrecover használata. Egyel®re a dump és a tar programokkal készült mentéseket lehet ezen a módon visszaállítani. Úgy dolgozik,
Egy másik lehet®ség a mentett anyagok visszaállítására az
hogy az Amanda index-fájljaiban keres. Csak root-ként tudjuk használni, más felhasználóként nem lehet. Nézzük meg a merevlemezre történ® mentés esetén hogyan tudnánk visszaállítani a mentést. A dns nev¶ gépen állunk, és oda próbálunk meg a mentésb®l visszaállítani egy könyvtárat. # /usr/sbin/amrecover AMRECOVER Version 2.5.1p1. Contacting server on backup.akarmi.intra ... 220 backup AMANDA index server (2.5.1p1) ready. Setting restore date to today (2007-06-18) 200 Working date set to 2007-06-18. 200 Config set to napi_backup. 200 Dump host set to dns. Use the setdisk command to choose dump disk to recover amrecover>
Látható, hogy kaptunk egy promptot, ahol egy csomó dolgot be tudunk állítani. Ahhoz, hogy a megfelel® adatokat nyerjük vissza, be is kell :) A használható parancsok listájához a
help
(vagy
Kósa Attila
?)
parancs segítségével juthatunk:
2009. március 23.
Debian GNU/Linux
97
amrecover> help valid commands are: add path1 ... - add to extraction list (shell wildcards) addx path1 ... - add to extraction list (regular expressions) cd directory - change cwd on virtual file system (shell wildcards) cdx directory - change cwd on virtual file system (regular expressions) clear - clear extraction list delete path1 ... - delete from extraction list (shell wildcards) deletex path1 ... - delete from extraction list (regular expressions) extract - extract selected files from tapes exit help history - show dump history of disk list [filename] - show extraction list, optionally writing to file lcd directory - change cwd on local file system ls - list directory on virtual file system lpwd - show cwd on local file system mode - show the method used to extract SMB shares pwd - show cwd on virtual file system quit listhost - list hosts listdisk [diskdevice] - list disks setdate {YYYY-MM-DD|--MM-DD|---DD} - set date of look {YYYY-MM-DD-HH-MM-SS} - set date of look setdisk diskname [mountpoint] - select disk on dump host sethost host - select dump host settape [host:][device|default] - select tape server and/or device setmode smb|tar - select the method used to extract SMB shares amrecover>
Menjünk végig a dns nev¶ gép
/etc/pam.d
könyvtárának visszaállítási folyamatán. El®ször
magát a gépet kell kijelölnünk, amelynek a mentéseivel foglalkozni szeretnénk: amrecover> sethost dns 200 Dump host set to dns.
A következ® parancs elárulja nekünk, hogy az el®bb kijelölt gépen mir®l is van mentésünk: amrecover> listdisk 200- List of disk for host dns 201- /etc 200 List of disk for host dns
A visszaállítandó anyag dátumát is be kell állítanunk. Ez a példában a 2006. 11. 27-i mentés, ennek megfelel®en folytatjuk a visszaállítás kongurálását: amrecover> setdate 2006-11-27 200 Working date set to 2006-11-27.
Ha nem találja az
amanda
2
a mentéshez tartozó indexfájlokat, akkor az alábbit láthatjuk :
amrecover> setdisk /etc 200 Disk set to /etc. No index records for disk for specified date If date correct, notify system administrator
Egy
/bin/ls -Al /backup/napi_backup/ parancs megmutatja, hogy melyik nap is készült data nev¶ link arra a
utoljára mentésünk (ha máshonnan nem jutna véletlenül eszünkbe). A
könyvtárra mutat, amelyik következik majd a mentés folyamán. Ezt át kell állítanunk, mondhatni be kell állítanunk a szalagos egységünket, hogy az a kazetta legyen benne, amelyikre szükségünk van. # # 3 # 4
cd /etc/amanda/napi_backup /usr/lib/amanda/chg-disk -info 5 1 /usr/lib/amanda/chg-disk -next file:/backup/napi_backup
Állítsunk be egy olyan id®pontot, amikorról már tényleg vannak mentéseink: amrecover> setdate 2007-06-12 200 Working date set to 2007-06-12.
Állítsuk be a visszaállítani kívánt részt: amrecover> setdisk /etc 200 Disk set to /etc.
2
Ha felcseréljük a
setdisk és setdate parancsokat (probléma nélkül fel lehet), akkor a kés®bb kiadott esetében
kapunk értesítést az indexfájlok hiányáról.
2009. március 23.
Kósa Attila
Debian GNU/Linux
98
Ha megvannak az indexfájlok, akkor itt már láthatjuk a beállított
/etc könyvtár tartalamanda index-fájljait
mát egészen pontosan még nem a mentésben nézel®dünk, mindössze az használjuk). Használhatjuk a
pwd,
a
cd
és az
ls
parancsokat, amelyek hasonlóak a shellben
megszokott parancsokhoz. Az
add
paranccsal kiválasztjuk amit vissza szeretnénk kapni (több fájlt is megadhatunk
egyszerre és használhatjuk a shellben használható helyettesít® karaktereket is). amrecover> add pam.d Added dir /pam.d/ at date 2007-06-12-14-00-02
Ellen®rizzük, hogy hol állunk: amrecover> lpwd /root
Módosítsuk (ha nem tetszik): amrecover> lcd /tmp amrecover> lpwd /tmp
Szerezzük vissza: amrecover> extract Extracting files using tape drive file:/backup/napi_backup on host backup.akarmi.intra. The following tapes are needed: NAPIBACKUP04 Restoring files into directory /tmp Continue [?/Y/n]? ? Enter "y"es to continue, "n"o to stop Continue [?/Y/n]? Y Extracting files using tape drive file:/backup/napi_backup on host backup.akarmi.intra. Load tape NAPIBACKUP04 now Continue [?/Y/n/s/t]? ? Enter "y"es to continue, "n"o to stop, "s"kip this tape or "t"ape to change tape drives Continue [?/Y/n/s/t]? Y ./pam.d/ ./pam.d/chfn ./pam.d/chsh ./pam.d/common-account ./pam.d/common-auth ./pam.d/common-password ./pam.d/common-session ./pam.d/cron ./pam.d/login ./pam.d/other ./pam.d/passwd ./pam.d/ssh ./pam.d/su amrecover> quit 200 Good bye.
A program kiírja, hogy melyik meghajtót szeretné használni a visszaállításhoz (melyik gépen), és hogy melyik címkéj¶ szalagra van szüksége. Én mindig a root felhasználót használtam a visszaállításhoz, és így nem voltak a visszaállítással kapcsolatban problémáim.
Kósa Attila
2009. március 23.
14. fejezet
Csomagsz¶rés
Talán néhol túlságosan is leegyszer¶sítve tárgyalom a különböz® dolgokat, de ezt amiatt teszem, mert kizárólag a csomagsz¶réssel megoldható dolgokat szeretném megvilágítani. Valószín¶leg nem említek meg minden, az Interneten használatos alkalmazást, de igyekszem a fontosabbakra kitérni. Figyelni kell arra is, hogy a kiszolgálónk bizonyos esetekben kliensként fog viselkedni (például SMTP kiszolgáló e-mail küldése esetén), tehát a csomagsz¶rést ennek megfelel®en kell beállítani. A kiszolgálók alapértelmezett portszáma is tájékoztató jelleg¶ információnak számít a szövegben, mert hála a Linux kongurálhatóságának szinte mindegyik kiszolgálót át lehet állítani, hogy más porton szolgáljon ki. Tehát amennyiben az alapértelmezett®l eltér® portra állítottuk bármelyik kiszolgálónkat, akkor ennek megfelel®en kell módosítanunk a csomagsz¶r®nk beállításait is. Amennyiben root felhasználóként (vagy setuid-os programmal sima felhasználóként) próbálunk bizonyos kliensprogramokat használni, akkor el®fordulhat, hogy a kliensprogram által
ssh esetén). ftp://ftp.kfki.hu/pub/documents/rfc/
használt forrásport száma 1023 alatti lesz (például A kapcsolódó RFC-k elérhet®k például az
a
http://www.faqs.org/rfcs/
14.1.
vagy
címen.
DNS
Két típusa van a DNS szolgáltatásoknak: az egyszer¶ lekérdezés és a zónatranszfer. Lekérdezés az, amikor a kliens kér információkat a DNS-kiszolgálótól (például egy névhez tartozó IP címet, vagy egy IP címhez tartozó nevet szeretne megtudni). Zónatranszfer az, amikor a másodlagos DNS-kiszolgáló kérdést küld egy másik DNS-kiszolgálónak (az els®dlegesnek), amelyben az els®dleges kiszolgáló által felügyelt zóna adatairól szeretne információkat kérni. Lássuk, hogyan zajlik ez protokollokat és portszámokat is gyelembevéve. A kiszolgálók az 53-as porton gyelnek alapértelmezés szerint. A kapcsolódó RFC-k száma: 1101, 1183, 1348, 1383, 1401, 1535, 1536, 1537, 1611, 1612, 1637, 1664, 1706, 1712, 1713, 1794, 1886, 1912, 1995, 1996, 2052, 2136, 2181, 2182, 2219, 2230, 2308, 2517, 2536, 2537, 2538, 2539, 2540, 2541, 2606, 2671, 2672, 2694, 2782, 2826, 2845, 2874, 2915, 2916, 2929, 2930, 2931, 3007, 3008, 3071, 3090, 3110, 3123, 3130, 3197, 3225, 3226, 3363, 3364, 3403, 3467, 3596, 3597, 3645, 3646, 3655, 3757, 3832, 3833, 3845, 3901, 4025, 4033, 4034, 4035, 4074, 4183, 4185, 4255, 4310, 4339, 4343, 4367, 4398, 4431, 4470, 4471, 4472, 4509, 4641, 4690, 4697, 4701.
99
Debian GNU/Linux
100
14.1.1.
Lekérdezés
A kliens kérdezi a kiszolgálót: a forrás port 1023 fölötti, a célport az 53-as. A kliens véletlenszer¶en választ portot 1023 fölött, UDP-n és TCP-n egyaránt kérdezhet. A kiszolgáló amikor válaszol, akkor az 53-as portjáról indítja a válaszcsomagokat, és a kliens 1023 fölötti portjára kapcsolódik. Bizonyos esetekben a kiszolgáló átkapcsol TCP-re, hiába UDP-n keresztül érkezett a kérés, akkor is TCP-n keresztül küldi a választ. Két kiszolgáló egymás közötti kommunikációja
1
(lekérdezése) az 53-as porton zajlik, tehát a kapcsolat forrás-, illetve célportja is 53 .
14.1.2.
Zónatranszfer
Zónatranszfernél: kizárólag TCP-n történik a kommunikáció. A másodlagos kiszolgáló az 1023as port fölül indítja a kérést, az els®dleges kiszolgáló 53-as portjára. Az els®dleges kiszolgáló az 53-as portjáról válaszol a másodlagos kiszolgáló 1023-as portja fölé címzett csomagokkal.
14.2.
NTP
UDP alapú szolgáltatás. A kiszolgálók a 123-as porton gyelnek alapértelmezés szerint. A kapcsolódó RFC-k száma: 0958, 1165, 1361, 1708, 1769, 2030, 2980, 3977, 4075, 4330, 4642, 4643, 4644.
14.2.1.
Klienskiszolgáló
A kliens kérdezi a kiszolgálót: a forrás port 1023 fölötti, a célport a 123-as. A kliens véletlenszer¶en választ portot 1023 fölött. A kiszolgáló válasza a 123-as portról indul, a célport pedig a kliens egy 1023 fölötti portja.
14.2.2.
Kiszolgálókiszolgáló
A forrás- és a célport is a 123-as.
14.3.
ICMP
Az ICMP csomagoknak nincsen forrás-, illetve célportjuk, jellemz®jük viszont az ICMP csomag típusa. A következ® típusú icmp üzenetek szokásosak: 14.1. táblázat: ICMP üzenetek típusai
típus
angol leírás
magyar leírás
0
echo reply
válasz a ping-re
3
destination unreachable
cél elérhetetlen
4
source quench
forrás lecsendesítése
8
echo request
ping
11
time exceeded
id®túllépés
12
parameter problem
paraméter probléma
Hacsak nincs valami különleges okunk, akkor a fentieket nem érdemes kisz¶rni, mert több problémát okozhatunk magunknak, mint amennyit segít megoldani. A kapcsolódó RFC-k száma: 0844, 1256, 1788, 1885, 2463, 2466, 2521, 2765, 4443, 4727.
1
Ez is kongurálható, az újabb szoftverek alapértelmezésben már egyszer¶ kliensként viselkednek inkább,
tehát az 1023 fölötti portról indítják a kapcsolatot (az 53-as portra).
Kósa Attila
2009. március 23.
Debian GNU/Linux
14.3.1.
101
traceroute
Ez egy érdekes képz®dmény, mert UDP csomagokat küld ki, de ICMP csomagokat vár vissza. Hogy milyen portokat használ UDP alatt, az függ az adott implementációtól, és/vagy a parancssori paraméterekt®l. Általában elmondható, hogy a forrásport 32768 fölött helyezkedik el, míg a célport 33434 és 33523 közé esik. Ha nagyon kíváncsiak vagyunk, akkor érdemes elolvasni a
traceroute
forráskódját :)
Tehát a kommunikáció így zajlik: elindítunk egy UDP csomagot a 32768-as port fölül, a fent meghatározott célportra. Érkezik vissza (jó esetben) egy 11-es és/vagy egy 3-as típusú ICMP csomag. A kapcsolódó RFC-k száma: 1393, 2925, 4560.
14.4.
POP2, POP3, POP3S, IMAP, IMAPS
TCP alapú szolgáltatás mind az öt. Alapértelmezésben a POP2 kiszolgáló a 109-es porton gyel, a POP3 a 110-es porton, az IMAP a 143-as porton, a POP3S a 995-ös porton, az IMAPS kiszolgáló pedig a 993-as porton. A kommunikáció mindegyik esetében hasonlóan zajlik, ezért csak egyet írok le, a többinél értelemszer¶en kell behelyettesíteni a szerver szolgáltatás portját. A kliens kérdezi a kiszolgálót: a forrás port 1023 fölötti, a célport a 110-es. A kliens véletlenszer¶en választ portot 1023 fölött. A kiszolgáló válasza a 110-es portról indul, a célport pedig a kliens egy 1023 fölötti portja. A POP3-hoz kapcsolódó RFC-k száma: 1734, 1957, 2449, 2595. Az IMAP-hoz kapcsolódó RFC-k száma: 1731, 1732, 1733, 2061, 2086, 2087, 2088, 2095, 2177, 2180, 2192, 2193, 2195, 2221, 2342, 2359, 2595, 2683, 2971, 3348, 3502, 3503, 3516, 3691, 4314, 4315, 4466, 4467, 4469, 4549, 4551, 4731.
14.5.
SMTP
TCP alapú szolgáltatás. A kiszolgálók a 25-ös porton gyelnek alapértelmezés szerint. Az SMTPt használó küld®k véletlenszer¶en választanak portot 1023 fölött. A küld® kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport a 25-ös. A kiszolgáló válasza a 25-ös portról indul, a célport a küld® egy 1023 fölötti portja. A kapcsolódó RFC-k száma: 0876, 1047, 1090, 1425, 1426, 1427, 1428, 1651, 1652, 1653, 1830, 1845, 1846, 1854, 1869, 1870, 1891, 1985, 2034, 2197, 2442, 2487, 2505, 2554, 2645, 2852, 2920, 3030, 3207, 3461, 3848, 3865, 3885, 3974, 4141, 4405, 4496.
14.6.
UUCP
TCP alapú szolgáltatás. A kiszolgálók az 540-es porton gyelnek alapértelmezés szerint. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport az 540-es. A kiszolgáló válasza az 540-es portról indul, a célport a kliens egy 1023 fölötti portja. A kapcsolódó RFC száma: 0976.
14.7.
AUTH
TCP alapú szolgáltatás. A kiszolgálók a 113-as porton gyelnek alapértelmezésben. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport az 113-as. A kiszolgáló válasza a 113-as portról indul, a célport a kliens egy 1023 fölötti portja.
2009. március 23.
Kósa Attila
Debian GNU/Linux
102
Bizonyos esetekben szükséges lehet a tiltása, jellemz®en akkor, ha a másik oldal igényelne ilyen szolgáltatást, de nekünk nincs ilyen (vagy nem akarjuk engedélyezni a használatát). Ilyen eset fordulhat el® bizonyos SMTP, illetve FTP kiszolgálók esetén. Nem javasolt az ide érkez® csomagok válasz nélküli eldobása, mert ebben az esetben a lekérést elindító kiszolgáló kényszer¶en ki fogja várni a timeout-ot, ezáltal lassítva a kapcsolódást. A kapcsolódó RFC-k száma: 0912, 0931, 0989, 1040, 1113, 1421, 1511, 1704, 3127.
14.8.
FTP
TCP alapú szolgáltatás. Kétféle mód létezik az FTP használatára, a normál, illetve a passzív mód. Lényeges különbség van köztük csomagsz¶rés szempontjából. A kapcsolódásig lényegében
2
megegyezik a két üzemmód, az eltérés majd az adatok átvitelében jelentkezik . A kiszolgálók a 21-es porton gyelnek alapértelmezés szerint. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport a 21-es. A kiszolgáló válasza a 21-es portról indul, a célport a kliens egy 1023 fölötti portja. Tehát a kiadott parancsok mindig a kliens 1023 fölötti portjáról indulnak a kiszolgáló 21-es portjára (például az
ls
parancs), de az adatok már a lentebb ismertetett módon közlekednek a két gép
között. A kapcsolódó RFC-k száma: 0238, 0412, 0414, 0438, 0448, 0458, 0463, 0468, 0475, 0478, 0479, 0480, 0506, 0520, 0532, 0571, 0593, 0630, 0640, 0683, 0691, 0697, 0737, 0743, 0751, 0775, 0949, 1545, 1579, 1635, 1639, 2228, 2428, 2577, 2585, 4217.
14.8.1.
Normál mód
Az adatcsatorna létrehozásához a kiszolgáló a 20-as portjáról indít egy kapcsolatot a kliens 1023 fölött véletlenszer¶en kiválasztott portjára, és a továbbiakban azon történik az adatcsere. Tehát a kliens err®l az 1023 fölötti portról fog válaszolni a kiszolgáló 20-as portjára.
14.8.2. A kliens a
Passzív mód pasv
paranccsal tudatja a szerverrel, hogy passzív módú adatátvitelt kezdeményez.
Ebben az esetben az adatcsatorna létrehozásához a kiszolgáló 1023 fölött egy véletlenszer¶en kiválasztott portot kinyit, és a kliens számára a nyitott címet és portszám-párt elküldi a kliensnek a parancs csatornán, majd passzívan várja a portra kapcsolódást. A kliens erre a portra egy 1023 fölötti portcímr®l fog csatlakozni. Ily módon épül ki az adatcsatorna.
14.9.
TFTP
UDP alapú szolgáltatás. A kiszolgálók a 69-es porton gyelnek alapértelmezés szerint. A kliensek véletlenszer¶en választanak portot 1023 fölött, és onnan küldik az els® csomagot a kiszolgáló felé. A kiszolgáló az 1023-as portja fölötti portról válaszol, a célport a kliens 1023 fölötti portja. Tehát a kommunikáció az 1023 fölötti portokon folyik, az els® csomagot leszámítva. A kapcsolódó RFC-k száma: 0783, 0906, 1350, 1782, 1783, 1784, 1785, 2090, 2347, 2348, 2349, 3617.
14.10.
HTTP, HTTPS
TCP alapú szolgáltatás mind a kett®. A kiszolgálók a 80-as porton gyelnek alapértelmezés szerint (http esetén). A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kap-
2
A kiadott parancsokra kapott válaszcsomag is adatnak számít!
Kósa Attila
2009. március 23.
Debian GNU/Linux
103
csolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport a 80-as. A kiszolgáló válasza a 80-as portról indul, a célport a kliens egy 1023 fölötti portja. Jegyezzük meg, hogy ugyanígy m¶ködik (csomagsz¶rés szempontjából) a HTTPS protokoll is, csak ott a kiszolgáló (alapértelmezés szerint) a 443-as porton gyel. A kapcsolódó RFC-k száma: 1945, 2068, 2069, 2109, 2145, 2169, 2227, 2295, 2296, 2518, 2585, 2616, 2617, 2774, 2817, 2818, 2935, 2936, 2964, 2965, 3143, 3205, 3229, 3230, 3310, 4130, 4169, 4229, 4236, 4387, 4559.
14.11.
nger
TCP alapú szolgáltatás. A kiszolgálók a 79-es porton gyelnek alapértelmezés szerint. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport a 79-es. A kiszolgáló válasza a 79-es portról indul, a célport a kliens egy 1023 fölötti portja. A kapcsolódó RFC-k száma: 0742, 1194, 1196, 1288.
14.12.
whois
TCP alapú szolgáltatás. A kiszolgálók a 43-as porton gyelnek alapértelmezés szerint. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport a 43-as. A kiszolgáló válasza a 43-as portról indul, a célport a kliens egy 1023 fölötti portja. A kapcsolódó RFC-k száma: 0812, 0954, 1714, 1834, 1835, 1913, 1914, 2167, 2957, 2958, 3912.
14.13.
syslog
UDP alapú szolgáltatás. A kiszolgálók az 514-es porton gyelnek alapértelmezés szerint. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport az 514-es. A kiszolgáló válasza az 514-es portról indul, a célport a kliens egy 1023 fölötti portja. A kapcsolódó RFC-k száma: 3164, 3195. A magyar fejlesztés¶
syslog-ng (http://www.balabit.hu/)
képes TCP-n és UDP-n is
kommunikálni. TCP fölött ugyanazokat a portokat használja alapértelmezésben, mint UDP fölött (és mint a hagyományos syslog szolgáltatások).
14.14.
r parancsok rlogin az rsh / rdump / rcp / rrestore / rdist az 514-es rsync pedig a 873-as porton. A portszám kivételével a
TCP alapú szolgáltatások. Négy portot használnak általánosan a kiszolgálók: az 513-as porton gyel alapértelmezésben, az porton, az
rexec
az 512-es porton, az
kommunikációjuk megegyezik (csomagsz¶rés szempontjából). A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport az 514-es. A kiszolgáló válasza az 514-es portról indul, a célport a kliens 1023 fölötti portja. Kivételt képez az
rsh,
amelynél a kliens egy véletlenszer¶en választott 1023 fölötti portról
nyit egy hibacsatornát a kiszolgáló 1023 fölötti portjára, és azon kommunikálnak. Az
rlogin-hoz
2009. március 23.
kapcsolódó RFC-k száma: 1258, 1282.
Kósa Attila
Debian GNU/Linux
104
14.15.
telnet
TCP alapú szolgáltatás. A kiszolgálók a 23-as porton gyelnek alapértelmezés szerint. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport a 23-as. A kiszolgáló válasza a 23-as portról indul, a célport a kliens egy 1023 fölötti portja. A kapcsolódó RFC-k száma: 0097, 0137, 0139, 0158, 0206, 0318, 0328, 0339, 0340, 0393, 0435, 0461, 0466, 0495, 0513, 0559, 0560, 0562, 0563, 0581, 0587, 0593, 0595, 0596, 0651, 0652, 0653, 0654, 0655, 0656, 0657, 0658, 0659, 0669, 0688, 0698, 0701, 0702, 0703, 0726, 0727, 0727, 0728, 0729, 0731, 0732, 0735, 0748, 0749, 0764, 0779, 0818, 0854, 0855, 0856, 0857, 0858, 0859, 0860, 0861, 0884, 0885, 0927, 0930, 0933, 0946, 1041, 1043, 1053, 1073, 1079, 1080, 1091, 1096, 1097, 1116, 1143, 1184, 1205, 1372, 1408, 1409, 1412, 1416, 1571, 1572, 2066, 2217, 2840, 2877, 2941, 2942, 2943, 2944, 2948, 2949, 2950, 2951, 2952, 2953, 4248, 4777.
14.16.
SSH
TCP alapú szolgáltatás. A kiszolgálók a 22-es porton gyelnek alapértelmezés szerint. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport a 22-es. A kiszolgáló válasza a 22-es portról indul, a célport a kliens egy 1023 fölötti portja. El®fordul, hogy a rendszergazdai jogosultsággal rendelkez® felhasználó által indított
ssh
kliens 1023 alatti portról indítja a kapcsolatot!
A kapcsolódó RFC-k száma: 4250, 4251, 4252, 4253, 4254, 4255, 4256, 4335, 4344, 4345, 4419, 4432, 4462, 4716, 4742.
14.17.
NNTP
TCP alapú szolgáltatás. A kiszolgálók a 119-es porton gyelnek alapértelmezés szerint. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport a 119-es. A kiszolgáló válasza a 119-es portról indul, a célport a kliens egy 1023 fölötti portja. Ennél a szolgáltatásnál független az, hogy két kiszolgáló, vagy egy kliens és egy kiszolgáló közötti kapcsolatról van-e szó, mindkét esetben ugyanúgy zajlik le a kapcsolódás. A kapcsolódó RFC-k száma: 2980, 3977, 4642, 4643, 4644.
14.18.
talk
TCP és UDP alapú szolgáltatás. Létezik egy régebbi és egy újabb változata. A kett® között az a különbség (csomagsz¶rés szempontjából), hogy a régebbi verzió az 517-es, az újabb pedig az 518-as portot használja (mármint a kiszolgáló alapértelmezésben). Csak az egyik (az újabb) esetet nézzük végig, akinek a régebbi kiszolgálóra van szüksége, az értelemszer¶en javítsa át a portszámokat. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport az 518-as, ez UDP-n történik. A kiszolgáló válasza az 518-as portról indul, a célport a kliens egy 1023 fölötti portja, szintén UDP-n. A két kliens közötti kommunikáció viszont már TCP-n történik, mégpedig 1023 fölötti portok igénybevételével. Tehát 1023 fölötti portról 1023 fölötti portra indulnak, illetve érkeznek a csomagok TCP segítségével.
Kósa Attila
2009. március 23.
Debian GNU/Linux 14.19.
105
IRC
TCP alapú szolgáltatás. A kiszolgálók a 6667-es porton gyelnek alapértelmezés szerint. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport a 6667-es. A kiszolgáló válasza a 6667-es portról indul, a célport a kliens egy 1023 fölötti portja. Két kliens egymás közti kommunikációja az 1023-as port fölötti tartományban zajlik, DCC-t használva. Amikor egy kliens meghív egy másik klienset, akkor a hívásban elküldi annak a TCP portnak a számát, amelyen fogadni képes a kapcsolatot. Amennyiben a másik kliens elfogadja a meghívást, akkor nyit egy csatornát a megadott portra.
14.20.
SNMP
UDP alapú szolgáltatás. Az SNMP-kiszolgáló a 161-es porton gyel alapértelmezésben, de TCPn és UDP-n is. Az SNMP trap-kiszolgáló a 162-es porton gyel alapértelmezés szerint, de TCPn és UDP-n is. Az SNMP kliens általában egy 1023 fölötti portot használ a kommunikációra mindkét kiszolgáló esetén. A kapcsolódó RFC-k száma: 1089, 1098, 1157, 1161, 1187, 1215, 1227, 1228, 1270, 1283, 1298, 1303, 1351, 1352, 1353, 1381, 1382, 1418, 1419, 1420, 1442, 1443, 1444, 1445, 1446, 1447, 1448, 1449, 1450, 1461, 1503, 1901, 1902, 1903, 1904, 1905, 1906, 1907, 1909, 1910, 2011, 2012, 2013, 2089, 2261, 2262, 2263, 2264, 2265, 2271, 2272, 2273, 2274, 2275, 2571, 2572, 2573, 2574, 2575, 2742, 2962, 3411, 3412, 3413, 3414, 3415, 3416, 3417, 3418, 3512, 3781, 3826, 4088, 4789.
14.21.
NFS
RPC alapú szolgáltatás. Nagyon nehéz a csomagsz¶r®t megfelel®en beállítani a használatához, mert a kiszolgáló normálisan el®re nem megjósolhatóan választja ki az általa alkalmazott portszámokat. Általában UDP-n történik a kommunikáció (bár létezik TCP-n kommunikálni képes NFS kiszolgáló és kliens is, ám ezek ritkán használatosak). A kapcsolódó rfc-ben azt írják, hogy az NFS protokoll jelenleg a 2049-es UDP portot használja. Ez azonban nem egy hivatalosan hozzárendelt port, a protokoll kés®bbi verziói a
portmap
programot használják az alkalmazott
portok megbeszélésére. A kapcsolódó RFC száma: 1094, 1813, 2054, 2055, 2224, 2623, 2624, 2755, 3010, 3530.
14.22.
NIS/YP
RPC alapú szolgáltatás, általában UDP fölötti kommunikációval. Ugyanaz a helyzet vele kapcsolatban, mint amit az NFS-r®l is elmondtunk: el®re nem megjósolható az általa alkalmazott portszám.
14.23.
X11
TCP alapú szolgáltatás. Az els® X-kiszolgáló alapértelmezésben a 6000-s porton gyel, a második a 6001-es porton, és így tovább. Egyes leírások szerint a kliensek az 1023 fölötti tartomány közepéb®l választanak portot maguknak de ez ugye elég megfoghatatlan :). Ezért kénytelenek vagyunk az egész 1023 fölötti porttartományból engedélyezni a bejöv® kéréseket, amelyek a fentebb említett portok valamelyikére kívánnak csatlakozni.
2009. március 23.
Kósa Attila
Debian GNU/Linux
106
14.24.
SaMBa
Minden Windows hálózat SMB alapú, és NetBIOS-t használ. A SaMBa megvalósításában ez TCP/IP fölötti NetBIOS-t jelent. A NetBIOS alapú hálózatok broadcast üzeneteket használnak a browse lista menedzselésére. Amikor TCP/IP fölött futtatjuk a NetBIOS-t, akkor erre a célra UDP üzeneteket használ (ezek lehetnek broadcast vagy unicast üzenetek). Normálisan csak az unicast UDP üzeneteket továbbítják a routerek. Alapértelmezésben a 137, 138, 139 és 445-ös portokat használják a gépek, függetlenül attól, hogy kliensr®l vagy kiszolgálóról van szó.
14.25.
lpr
TCP alapú szolgáltatás. A kiszolgálók az 515-ös porton gyelnek alapértelmezés szerint. A kliensek véletlenszer¶en választanak portot 1023 fölött. A kliens kapcsolódik a kiszolgálóhoz: a forrás port 1023 fölötti, a célport az 515-ös. A kiszolgáló válasza az 515-ös portról indul, a célport a kliens egy 1023 fölötti portja.
Kósa Attila
2009. március 23.
15. fejezet
TZFAL
Egy t¶zfal kongurálása nem annyira egyszer¶, hogy mindegyikre rá lehetne húzni egy sémát. Persze vannak alapok, amelyeket nem árt gyelembe venni a tervezéskor. Ezeket próbálom meg felvázolni ebben a fejezetben, a teljesség igénye nélkül. A bels® hálózat munkaállomásait igyekszem teljes egészében kizárni a t¶zfallal folytatandó kommunikációból. Tehát minden forgalom csak valamilyen bels® szerveren keresztül jut el a t¶zfalhoz. Közvetlenül csak a kijelölt bels® szerverek fordulhatnak a t¶zfalhoz.
15.1.
DNS
A t¶zfalon futó DNS szolgáltatás beállításának bemutatása ennek a fejezetnek a célja.
15.1.1.
BIND
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 (9.3.4-2) ... 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
A
/etc/default könyvtárban található egy bind9 nev¶ állomány, amely mindössze az aláb-
biakat tartalmazza: OPTIONS="-u bind" RESOLVCONF=yes
Ez azt okozza, hogy a
BIND9
root jogosultságokkal. A /etc/bind könyvtárban
a
bind
nev¶ felhasználó és csoport nevében fog futni, tehát
nem
• named.conf
include
találhatóak a kongurációs állományok:
az els®dleges kongurációs állomány, a többi ebbe kerül beágyazásra (az
opció segítségével);
107
Debian GNU/Linux
108
• named.conf.local
a lokális zónák megadására szolgáló fájl;
• named.conf.options A
egyéb opciók megadására szolgáló fájl.
named.conf állományt hagyjuk változatlanul, és csak a másik két fájlra fordítsuk a named.conf.options fájl felépítése az egyszer¶bb, ezért el®ször azzal kezdjük a
gyelmünket. A kongurálást.
Amikor készen vagyunk, akkor így néz ki a kongurációs állomány: acl belso_halo { 192.168.10.253; 192.168.10.252; }; options { directory "/var/cache/bind"; check-names response warn; allow-query { localhost; belso_halo; }; allow-recursion { localhost; belso_halo; }; auth-nxdomain no; listen-on { 127.0.0.1; 192.168.10.254; }; 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
directory opció határozza meg, hogy melyik könyvtárban tárolhatjuk a named.conf.local
fájlban megadott zónafájljainkat.
query-source address
A
indítsa a lekérdezéseket a
opció azt határozza meg, hogy melyik interfészen melyik portról
BIND9.
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).
check-names
A
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.
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
opció azt befolyásolja, hogy mely hálózati címeken gyeljen IPv4-en. Mivel kí-
vülr®l nem akarjuk megengedni, hogy meg tudják szólítani (felesleges is lenne, hiszen nincs olyan adat, amelyet szolgáltatni tudna), ezért elég csak a lokális és a bels® interfész címét felvenni. A
listen-on-v6 opció azt szabályozza, hogy mely hálózati kártyákon gyeljen IPv6-on. max-cache-size nev¶ opció, amelynek a segítségével lehet limitálni a gyorsító-
Létezik egy
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 beírni a
/etc/resolv.conf fájlban célszer¶ saját magát (tehát a 127.0.0.1 IP címet)
nameserver
sorba, illetve a
search opcióban a bels® hálózat zónáját megadni. Tehát így
nézzen ki a fájl:
Kósa Attila
2009. március 23.
Debian GNU/Linux
109
search akarmi.intra nameserver 127.0.0.1
A
named.conf.local
fájlnak kell tartalmaznia azt, hogy az egyes zónákhoz hogyan viszo-
nyuljon a DNS szerverünk. Jelen példában nem a t¶zfalunkon van a saját (Interneten beregisztrált) zónánk (hanem például a szolgáltatónk kezeli), így semmilyen zónát nem kell felvennünk a t¶zfalon futó DNS szerverbe. 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/bind9 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
pa-
ranccsal, hogy gyel-e a megfelel® interfészeken.
15.2.
NTP
A t¶zfalon futó NTP szolgáltatás beállításának bemutatása ennek a fejezetnek a célja.
15.2.1.
ntp-server
A telepítés egyszer¶: # apt-get install ntp
Nem látható a telepítés alatt (csak a logokban), hogy a csomag létrehoz egy
ntp
nev¶
csoportot, és egy ugyanilyen nev¶ felhasználót is. Elindításakor ezeknek a nevében fog futni a szolgáltatás, nem a
root
felhasználó jogosultságaival.
A kongurációs állomány a egy
ntp
/etc/ntp.conf
fájl, illetve a
/etc/default
könyvtárban van
nev¶ állomány. Ez utóbbi mindössze egyetlen sort tartalmaz a telepítés után:
NTPD_OPTS='-g'
Az általunk használt kongurációs állomány: driftfile /var/lib/ntp/ntp.drift statsdir /var/log/ntpstats/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst server 127.127.1.0 fudge 127.127.1.0 stratum 12 restrict default kod notrap nomodify nopeer noquery restrict 127.0.0.1 nomodify
Ténylegesen sokkal több opció létezik, illetve a szerepl® opcióknak is több kapcsolója van, de most csak a fentiek magyarázatára térünk ki.
driftle
Ebben a fájlban tárolja az
ntp
démon, hogy az els® elindulásakor a számítógép bels®
frekvenciájának mennyi a hibája. Körülbelül 1 napig tart az elindítása után, amíg egy jó becslést kiszámít, és ily módon közel kerül a szinkronizáláshoz használt szerver idejéhez. Ezt a fájlt használja arra, hogy a démon újraindítása esetén újra inicializálja saját magát, és így el tudja kerülni azt, hogy újra 1 napig tartson a becslés kiszámítása.
statsdir
Egy könyvtár teljes elérési útvonalát határozza meg, ahol a statisztikai fájlokat tárolni
fogja a rendszer.
statistics
Engedéyezi statisztikai adatok írását. Jelenleg 6 különböz® statisztika támogatott.
2009. március 23.
Kósa Attila
Debian GNU/Linux
110
clockstats Az óra statisztikai információi. loopstats A loop lter statisztikai információi. peerstats Az egyéb ntp szerverekkel kapcsolatos statisztikai információk (magában foglalja a kongurált speciális szignálokat is).
legen
Egy adott sor meghatározza, hogy milyen típusú adatot mikor és hová kell írni. A
régi adatokat (fájlokat) el lehet távolítani, mert csak adminisztrációs szempontból van jelent®ségük, az
server fudge
ntp
csak az aktuális fájlokat használja.
A szinkronizáláshoz használt time szerver neve vagy IP címe. Arra használatos, hogy plusz információt szolgáltasson az egyéni órairányítók számára.
A
stratum
opció használható az eszköz alapértelmezésének felülírására.
Egy referenciaórának a stratum száma alapértelmezésben nulla. Az
ntp
minden egyes
szerver stratumához (amelyekhez ® szinkronizál) hozzáad egyet. 15 fölötti stratum esetén már nem használják szinkronizálásra, mert túlságosan pontatlan lenne.
restrict
Az alapértelmezett bejegyzés (IP cím: 0.0.0.0, netmaszk 0.0.0.0) mindig benne van, és
mindig a listának az els® tagja. Tehát az els®
restrict
bejegyzés mindig erre vonatkozik.
A további bejegyzéseknél megadhatjuk (IP címmel vagy DNS névvel) a korlátozandók listáját. Ha nincs
restrict
sor a kongurációs állományunkban, akkor nincs semmilyen
korlátozás a szolgáltatás elérését tekintve. A korlátozásokat két csoportra lehet osztani, az egyik, amely az id®szolgáltatás elérését korlátozza, a másik pedig a szervert®l kérhet® információkat, valamint a szerver futási id®ben történ® újrakongurálását.
ignore
Minden csomagot gyelmen kívül hagy, beleértve az
ntpq
és az
ntpdc
lekérdezé-
seket is.
kod
Ha ez a jelz® be van állítva amikor egy szabálytalan elérési próbálkozás történik, akkor egy KoD (kiss-o'-death a halál csókja) csomagot fog küldeni a szerver. Ezen csomagok száma másodpercenként egyre van korlátozva.
nomodify
Megakadályozza, hogy az
ntpq
és az
ntpdc
segítségével változtatni lehessen
a kongurációs beállításokon, tehát futás közben nem lehet átállítani a szervert. Az ezekkel a parancsokkal történ® lekérdezést azonban nem tiltja meg.
noquery Letiltja az ntpq és az ntpdc kéréseit. Ez magát a szolgáltatást nem érinti. nopeer Elutasítja azokat a csomagokat, amelyek új szervert vennének fel. notrap A trap szolgáltatás elérését tiltja. A fentiek ismeretében lássuk, pontosan mit is jelent az elkészített kongurációs állományunk.
/var/lib/ntp/ntp.drift fájl van beállítva driftle -ként (azaz ott tárolja az adatokat). A statisztikák tárolására a /var/log/ntpstats/ könyvtár van megadva. 3 statisztika készüljön,
A
naponta egy, a statisztikák nevének megfelel® fájlba kerüljenek (az el®z®leg megadott könyvtárban). 2 szerver van beállítva. A bels® szerverünk. A
127.127.1.0
192.168.10.254
a t¶zfalunk IP címe, ahhoz szinkronizál a
cím¶ szerver az saját magát, a lokális gép óráját jelenti. A
saját órájához 13 van beállítva stratumként (az egyszer¶ség kedvéért nevezzük pontosságnak, bár nem egészen fedi ez a kifejezés a valóságot). Ez arra jó, hogy ha nem tud a távoli szerverhez szinkronizálni, akkor is tud id®t szolgáltatni a kliensek (és a szerverek) számára. És végül két korlátozás szerepel még a kongurációs állományban.
Kósa Attila
2009. március 23.
Debian GNU/Linux
15.2.2.
111
A szolgáltatás ellen®rzése
Több lehet®ségünk is van a szolgáltatás m¶ködésének az ellen®rzésére. A legegyszer¶bb az
ntpdate használata (ehhez el®ször természetesen telepítenünk kell az ntpdate csomagot). Ezzel egyszer¶en megpróbáljuk elérni a szervert: # ntpdate -q -v time 8 Nov 15:54:39 ntpdate[1213]: ntpdate 4.2.0a@1:4.2.0a+stable-2-r Fri Aug 26 10:30:13 UTC 2005 (1) server 192.168.10.253, stratum 5, offset 0.000004, delay 0.02568 8 Nov 15:54:39 ntpdate[1213]: adjust time server 192.168.10.253 offset 0.000004 sec
Egy másik lehet®ség az
ntpq
használata. Ha úgy indítjuk, hogy
ntpq,
akkor egy
ntpq>
promptot kapunk, ahol a ? (kérd®jel) segítségével juthatunk a használható parancsok listájához. Ugyanezeket a parancsokat használhatjuk az a
-c
ntpq másik indítási módjánál is: ntpq -c ?. Tehát
parancssori opció után adhatjuk meg a használható parancsokat. Például a
readvar
opció
hatására a következ® adatokat kapjuk: # ntpq -c readvar assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg, version="ntpd [email protected] Sun Mar 4 13:21:35 UTC 2007 (1)" processor="i686", system="Linux/2.6.18-4-686", leap=00, stratum=5 precision=-20, rootdelay=25.092, rootdispersion=379.947, peer=29110, refid=192.168.10.254, reftime=c9b22e22.81d92a97 Mon, Mar 26 2007 13:33:54.507, poll=6, clock=c9b22fea.083a1008 Mon, Mar 26 2007 13:41:30.032, state=4, offset=122.694, frequency=38.028, jitter=140.360, noise=43.379, stability=13.445, tai=0
Itt látható, hogy miért ajánlatos letiltani az NTP szerverünk
ntpq
segítségével történ® el-
érését. Hiszen még a használt szoftver és kernel verziója is megjelenik az üzenetben, amely a legtöbb esetben nem publikus információ. A harmadik lehet®ség az
ntpdc
15.3.
ntpq parancshoz hasonlóan m¶ködik. ntpdc -c ? parancs segítségével kaphatjuk meg.
használata, amely az
A lekérdezéshez használható opciókat ennél az
ntpdate
Arra szolgál, hogy a gép óráját egy id®kiszolgálóhoz szinkronizálja. El®ször telepítsük fel: # apt-get install ntpdate
Egyetlen kongurációs állománya van, a
/etc/default/ntpdate fájl. A fájl a telepítés után
az alábbiakat tartalmazza (a kommenteket kihagytam): NTPDATE_USE_NTP_CONF=yes NTPSERVERS="0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org" NTPOPTIONS=""
Az
NTPOPTIONS
opciónál sorolhatjuk fel az
ntpdate
parancssori kapcsolóit. Ezek közül
az alábbi hármat látom én célszer¶nek használni:
s
Alapértelmezésben a standard kimenetre küldi üzeneteit az
ntpdate, de ett®l a kapcsolótól a
syslog-ba fognak bekerülni az üzenetek.
u
E nélkül a kapcsoló nélkül az
ntpdate a 123-as (privilegizált) portot akarja használni. Ha fut
egy NTP szerver a gépen, akkor ez nem fog neki sikerülni, és az alábbi hibaüzenetet adja:
the NTP socket is in use, exiting.
v
B®beszéd¶bbé válik t®le az
ntpdate, kiírja, hogy mennyi volt az id®eltérés a szinkronizálásra
használt szervert®l. Végeredményben így fog kinézni a
/etc/default/ntpdate
állományunk:
NTPDATE_USE_NTP_CONF=no NTPSERVERS="time" NTPOPTIONS="-vus"
2009. március 23.
Kósa Attila
Debian GNU/Linux
112
ntpdate csak a rendszer indulásakor fut le automatikusan. Ha nem csak ilyenkor szeretcron segítségével elindítani. Ehhez a /etc/cron.d 1 könyvtárba helyezzünk el egy ntpdate nev¶ fájlt az alábbi tartalommal: Az
nénk futtatni, akkor kénytelenek vagyunk a
MAILTO="" 15 * * * *
A
root
MAILTO
/usr/sbin/ntpdate-debian -s -b >/dev/null
sor hatására a
cron
nem fog levelet küldeni a parancs végrehajtásáról. A kö-
vetkez® sor hatására pedig minden óra 15 perckor fogja futtatni a szinkronizáláshoz szükséges parancsot.
15.4.
SMTP
A t¶zfalon futó SMTP szolgáltatás beállításának bemutatása ennek a fejezetnek a célja.
15.4.1.
postx
# apt-get install postfix Setting up postfix (2.3.8-2+b1) ... Adding group `postfix' (GID 104) ... Done. Adding system user `postfix' (UID 101) ... Adding new user `postfix' (UID 101) with group `postfix' ... Not creating home directory `/var/spool/postfix'. Creating /etc/postfix/dynamicmaps.cf Adding tcp map entry to /etc/postfix/dynamicmaps.cf Adding group `postdrop' (GID 105) ... Done. setting myhostname: fw.kulso-domain.hu setting alias maps setting alias database changing /etc/mailname setting myorigin setting destinations: fw.kulso-domain.hu, localhost.kulso-domain.hu, localhost setting relayhost: setting mynetworks: 127.0.0.0/8 setting mailbox_size_limit: 0 setting recipient_delimiter: + setting inet_interfaces: all /etc/aliases does not exist, creating it. WARNING: /etc/aliases exists, but does not have a root alias. Postfix is now set up with a default configuration. If you need to make changes, edit /etc/postfix/main.cf (and others) as needed. To view Postfix configuration values, see postconf(1). After modifying main.cf, be sure to run '/etc/init.d/postfix reload'. Running newaliases Stopping Postfix Mail Transport Agent: postfix. Starting Postfix Mail Transport Agent: postfix.
Válaszok a telepítés közben feltett kérdésekre. General type of configuration? Internet with smarthost Mail name? fw.kulso-domain.hu SMTP relay host? (blank for none)
Érdemes lefuttatni a következ® parancsot, mert így még több dolgot bekongurálhatunk a kongurációs állomány kézi szerkesztése nélkül, és így a
debconf
is megjegyzi válaszainkat,
aminek egy frissítés esetén vehetjük hasznát. # dpkg-reconfigure -plow postfix
Válaszok a kérdésekre. General type of configuration? Internet Site Where should mail for root go [email protected] Mail name? fw.kulso-domain.hu SMTP relay host? (blank for none) Other destinations to accept mail for? (blank for none) fw.kulso-domain.hu, localhost.kulso-domain.hu, localhost Force synchronous updates on mail queue? No Local networks? 127.0.0.0/8 192.168.10.252/32 Mailbox size limit 0 Local address extension character? + Internet protocols to use? ipv4
1
Önkényesen választottam ezt a nevet.
Kósa Attila
2009. március 23.
Debian GNU/Linux Állítsuk le a
postfix-et
113
amíg be nem állítjuk, nehogy valahogy elveszítsünk leveleket. Akár
a csomagsz¶r® segítségével is letilthatjuk ideiglenesen, hogy kívülr®l (vagy akár belülr®l is) kapcsolódhassanak hozzá. A csomagsz¶r®s tiltástól még fog tudni kifelé küldeni levelet, tehát azt tudjuk majd tesztelni, hogy a
kulso-domain.hu
címre érkez® leveleket megfelel®en továbbítja-
e az általunk kívánt gépre. A kongurálás és a teszt végén ne felejtsük el a csomagsz¶r®ben
postfix). /etc/postfix/main.cf kongurációs állomány a következ® sorokat tar-
engedélyezni a 25-ös portra való kapcsolódást (alapértelmezésben ott gyel a A telepítés végén a
talmazza (a kommenteket nem írom le): smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no append_dot_mydomain = no smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache myhostname = fw.kulso-domain.hu alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = fw.kulso-domain.hu, localhost.kulso-domain.hu, localhost mynetworks = 127.0.0.0/8 192.168.10.252/32 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = ipv4
Ezt ki kell egészítenünk egy pár opcióval, hogy az Internet fel®l érkez® leveleket továbbítsa a bels® levelez®szerverünknek. relay_domains = kulso-domain.hu transport_maps = hash:/etc/postfix/transport
A
/etc/postfix/transport
fájl tartalma az alábbi legyen.
kulso-domain.hu smtp:[192.168.10.252]
Majd kell egy parancs, amivel a
a
transport
postfix számára szükséges .db kiterjesztés¶ fájlt létrehozzuk
fájlból.
# cd /etc/postfix # postmap transport
Ezután már csak el kell indítanunk a
postfix-et
(ha az elején leállítottuk, ellenkez® eset-
ben újra kell indítanunk), és m¶ködni fog továbbítani fogja a
kulso-domain.hu
címre érkez®
leveleket a bels® levelez®szerverünknek.
15.5.
VPN
A hálózatunkon kívül lev®knek szeretnénk szabályozott módon biztonságos elérést biztosítani a védett hálózatunkban lév® szolgáltatásokhoz. A t¶zfalon futó szerver, valmint a kapcsolódni kívánó kliensek beállításainak bemutatása ezen fejezet célja.
15.5.1.
OpenVPN
Telepítés szerver oldalon A telepítés egyszer¶. De a használatához kernel-szint¶ támogatás szükséges (legalább modulba kell fordítanunk a
Universal TUN/TAP device driver support
könyvtárba kell egy
opciót). Valamint a /dev/net tun nev¶ eszközfájl is. Felrakja az openssl csomagot is, ha még nincs fent.
# apt-get install openvpn
2009. március 23.
Kósa Attila
Debian GNU/Linux
114
Beállítás szerver oldalon Extra biztonságot ad az SSL/TLS kapcsolatok mellett, segítséget nyújt a Dos (Denial of Service) támadások kivédéséhez és az UDP port elárasztása (ood) ellen. # cd /etc/openvpn # openvpn --genkey --secret ta.key
2
Die-Hellman paraméter . A Die-Hellman protokoll a kulcsegyeztetés feladatát oldja meg két távoli fél között. B®vebben például a bibliográában szerepl® [2] anyagban olvashatunk róla. # cd /etc/openvpn # openssl dhparam -out dh2048.pem 2048 Generating DH parameters, 2048 bit long safe prime, generator 2 This is going to take a long time ...............................................................................+ ................................................................................ .............................++*++*
Az 5.1.2. fejezetben leírtaknak megfelel®en generáljunk tanúsítványt ezen szerver részére is, valamint a vpn-en csatlakozni kívánó kliensek részére is. Ez utóbbiaknál lényegtelen a nevük, mindössze arra kell gyelnünk, hogy a generált tanúsítvány nevének megfelel® nev¶ fájlba kell
/etc/openvpn/client.d vpn001.akarmi.intra néven
majd beírnunk a szerveren az adott kliensre vonatkozó dolgokat (a könyvtárban). Az egyszer¶ség és az érthet®ség kedvéért nevezzük az els® kliensünket. Nézzük meg, mit is tartalmazzon a
server.conf
nev¶ kongurációs állomány:
local t¶zfal.küls®.ip.címe port 1194 proto udp dev tun ca /etc/ssl/certs/CA.crt cert /etc/ssl/certs/tuzfal.akarmi.intra.crt key /etc/ssl/private/tuzfal.akarmi.intra.key.nopass dh /etc/openvpn/dh2048.pem server 10.10.0.0 255.255.255.248 ifconfig-pool-persist /etc/openvpn/ipp.txt client-config-dir /etc/openvpn/client.d push "dhcp-options DNS 192.168.10.253" route 10.10.1.0 255.255.255.0 keepalive 10 120 tls-auth /etc/openvpn/ta.key 0 comp-lzo max-clients 100 user nobody group nogroup persist-key persist-tun status /var/log/openvpn-status.log log /var/log/openvpn.log verb 5 management localhost 7505
Az opciók magyarázata:
local
A t¶zfalnak az az IP címe, amelyen gyelnie kell az
port
Az a portszám, ahol gyelnie kell az
proto dev
openvpn-nek.
openvpn-nek.
A kapcsolódáshoz használt protokoll.
A tun beállítás IP tunnelt hoz létre, a tap beállítás pedig ethernet tunnelt. Ha bridge-et szeretnénk csinálni, akkor a tap beállítást kell használnunk.
ca
A CA tanúsítványa.
cert key dh 2
A t¶zfal részére kiállított tanúsítvány. A t¶zfal titkos kulcsa.
A Die Hellman paraméter. A generálás ideje alatt a beidézettnél jóval több pont és összeadás-jel jelent meg a képerny®n. A gép
er®sségét®l függ, hogy mennyi ideig húzódik el a generálás.
Kósa Attila
2009. március 23.
Debian GNU/Linux server
115
Itt állítunk be a szervernek egy alhálózatot, amelyb®l majd a klienseknek adhat címet.
A szerver fenntartja magának a 10.10.0.1-es IP címet, amely címen minden kliens elérheti. Kommentezzük ki ezt a sort, ha bridge-et szeretnénk beállítani.
ifcong-pool-persist
Ebben a fájlban tartjuk nyilván a kliens IP cím összerendeléseket.
Ha újraindítjuk az
openvpn-t,
akkor ezáltal lehet®ség nyílik arra, hogy a visszacsatlakozó
kliensek ugyanazt az IP címet kapják, amit korábban.
client-cong-dir
Az a könyvtár, ahol a kliensek (szerver oldali) kongurációs állományait
tároljuk. Ne felejtsük el létrehozni!
push "dhcp-options DNS 192.168.10.253"
A klienseknek kiküldi a névfeloldást végz® szer-
ver IP címét. Ne felejtsük el odaengedni a csomagsz¶r®ben a klienseket ehhez a címhez!
route
Ezzel állíthatjuk be, hogy milyen IP tartományokat kezeljen a szerverünk. Több ilyen
sort is tartalmazhat a kongurációs állomány.
keepalive
Ping-szer¶ üzeneteket küld oda-vissza a linken keresztül, hogy észrevegye, ha a kap-
csolat leáll. Minden 10 másodpercben küld csomagot, és ha nem jön válasz, akkor 120 másodperc után veszi úgy, hogy leállt a kapcsolat.
tls-auth
Extra biztonságot ad az SSL/TLS kapcsolatok mellett, segítséget nyújt a Dos (Denial
of Service) támadások kivédéséhez és az UDP port elárasztása (ood) ellen. A szerveren 0-t kell beállítani, a klienseken pedig 1-et.
comp-lzo
Engedélyezi a tömörítést.
max-clients user
Maximum az itt megadott számú kliens kapcsolódhat egyszerre.
Melyik felhasználó nevében fusson az
openvpn.
group
Melyik csoport nevében fusson az
status
Egy fájlnevet kell megadnunk, amelybe percenként rövid statisztika készül, mutatva az
openvpn.
aktuális kapcsolatokat.
log
Alapértelmezésben a syslog-ba kerülnek az
openvpn üzenetei, de ezzel az opcióval küldhet-
jük külön fájlba.
verb
Az
openvpn
management
b®beszéd¶ségének beállítása.
Egy menedzsment interfészt állít be, amelyet a megadott porton lehet elérni
(telnet segítségével).
15.1. táblázat: Fájlok jogosultságai Fájlnév
CA.crt CA.key dh2048.pem ta.key tuzfal.akarmi.intra.crt tuzfal.akarmi.intra.key.nopass vpn001.akarmi.intra.crt vpn001.akarmi.intra.key.nopass
Szükséges
a szerver + minden kliens csak a kulcsgeneráló gépen csak a szerveren szerver + minden kliens csak a szerveren csak a szerveren csak a kliens1 gépen csak a kliens1 gépen
Micsoda
Root CA tanúsítvány Root CA kulcs Die Hellman paraméter Extra biztonság Szerver tanúsítvány Szerver kulcs Kliens1 tanúsítvány Kliens1 kulcs
Titkos
Nem Igen Nem Igen Nem Igen Nem Igen
Ilyen párokat lehet kialakítani:
2009. március 23.
Kósa Attila
Debian GNU/Linux
116
[ 1, 2] [ 21, 22] [ 41, 42] [ 61, 62] [ 81, 82] [101,102] [121,122] [141,142] [161,162] [181,182] [201,202] [221,222] [241,242]
[ 5, 6] [ 25, 26] [ 45, 46] [ 65, 66] [ 85, 86] [105,106] [125,126] [145,146] [165,166] [185,186] [205,206] [225,226] [245,246]
[ 9, 10] [ 29, 30] [ 49, 50] [ 69, 70] [ 89, 90] [109,110] [129,130] [149,150] [169,170] [189,190] [209,210] [229,230] [249,250]
[ 13, 14] [ 33, 34] [ 53, 54] [ 73, 74] [ 93, 94] [113,114] [133,134] [153,154] [173,174] [193,194] [213,214] [233,234] [253,254]
[ 17, 18] [ 37, 38] [ 57, 58] [ 77, 78] [ 97, 98] [117,118] [137,138] [157,158] [177,178] [197,198] [217,218] [237,238]
A menedzsment rész viszonylag egyszer¶en m¶ködik: $ telnet localhost 7505 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info help Management Interface for OpenVPN 2.0.9 i386-pc-linux [SSL] [LZO] [EPOLL] built on Dec 2 2006 Commands: auth-retry t : Auth failure retry mode (none,interact,nointeract). echo [on|off] [N|all] : Like log, but only show messages in echo buffer. exit|quit : Close management session. help : Print this message. hold [on|off|release] : Set/show hold flag to on/off state, or release current hold and start tunnel. kill cn : Kill the client instance(s) having common name cn. kill IP:port : Kill the client instance connecting from IP:port. log [on|off] [N|all] : Turn on/off realtime log display + show last N lines or 'all' for entire history. mute [n] : Set log mute level to n, or show level if n is absent. net : (Windows only) Show network info and routing table. password type p : Enter password p for a queried OpenVPN password. signal s : Send signal s to daemon, s = SIGHUP|SIGTERM|SIGUSR1|SIGUSR2. state [on|off] [N|all] : Like log, but show state history. status [n] : Show current daemon status info using format #n. test n : Produce n lines of output for testing/debugging. username type u : Enter username u for a queried OpenVPN username. verb [n] : Set log verbosity level to n, or show if n is absent. version : Show current version number. END
Telepítés windowsos kliensen http://openvpn.net/release/openvpn-2.0.9-install.exe fájlt, majd fel C:\Program Files\OpenVPN könyvtárba települ. A kapszükséges állományokat az ebben a könyvtárban lév® config nev¶ könyvtárba kell
Le kell tölteni a
kell telepíteni. Alapértelmezésben a csolódáshoz
elhelyezni. Az ide kerül® fájlok a következ®k:
• client.ovpn
(a kongurációs állomány),
• CA.crt
(a CA-nk tanúsítványa),
• ta.key
(amelyet a t¶zfalon generáltunk az extra biztonság érdekében),
• vpn001.akarmi.intra.crt
(a kliens számára kiállított tanúsítvány),
• vpn001.akarmi.intra.key.nopass Nézzük meg, mit is tartalmazzon a
(a kliens titkos kulcsa).
client.ovpn
nev¶ kongurációs állomány:
client dev tun proto udp remote t¶zfal.küls®.ip.címe 1194 resolv-retry infinite nobind persist-key persist-tun ca CA.crt cert vpn001.akarmi.intra.crt key vpn001.akarmi.intra.key.nopass tls-auth ta.key 1 comp-lzo verb 3
Az opciók magyarázata (csak a szervert®l eltér® opciók magyarázata szerepel):
Kósa Attila
2009. március 23.
Debian GNU/Linux client
117
Meghatározza, hogy kliensr®l van szó, és hogy a szervert®l bizonyos kongurációs utasí-
tásokat fogunk kapni.
remote
A t¶zfal küls® IP címe, ahová kapcsolódnia kell a kliensnek. Az 1194 a kapcsolódásra
használt port száma.
resolv-retry
Azt okozza ezen opció, hogy a kliens korlátlanul próbálja feloldani a szerver nevét.
Nagyon hasznos olyan gépek esetén, amelyeknek nincs folyamatos Internet-kapcsolata.
nobind
Nagyon sok kliensnek nincs szüksége arra, hogy egy speciális helyi porthoz hozzáren-
delje a kapcsolódást.
cert key
A kliens részére kiállított tanúsítvány. A kliens titkos kulcsa.
Ha mindezekkel megvagyunk, akkor elindíthatjuk a kapcsolódást. Az egér jobb gombjával kattintsunk a
client.ovpn fájlon és válasszuk a Start OpenVPN on this cong le
menüpontot.
Amikor a kliens kapcsolódott a szerverhez, akkor egy DOS-ablak jelenik meg a képerny®n, amelyben láthatóak a logok, és az alábbi billenty¶kkel adhatunk parancsokat az
F1
Feltételes restart (a hálózati interfész bezárása és újra megnyitása nélkül).
F2
A kapcsolat statisztikáinak megmutatása.
F3
A kapcsolat teljes újraindítása.
F4
A kapcsolat bontása.
openvpn-nek.
Egy kliens beállítása a szerveren A korábban létrehozott kulcshoz tartozó opciók beállítása következik. Az alábbi tartalommal hozzunk létre a
/etc/openvpn/client.d
könyvtárban egy
vpn001.akarmi.intra
nev¶ fájlt.
ifconfig-push 10.10.1.1 10.10.1.2 push "route 192.168.10.0 255.255.255.0"
Ezzel elértük azt, hogy a
vpn001.akarmi.intra
névre kiállított kulccsal kapcsolódó kliens
mindig a 10.10.1.1 IP címet fogja kapni, valamint a windowsos gépén beállításra kerül egy route bejegyzés, miszerint a 192.168.10.0/24 hálózatot a VPN-en keresztül tudja elérni. A csomagsz¶r® beállítása fontos
15.6.
(119. oldal),
ne felejtkezzünk el róla!
Csomagsz¶rés
Célom az ebben a fejezetben bemutatott beállításokkal, hogy a bels® hálózatból csak a meghatározott forgalom juthasson ki az Internetre. De nem csak a forgalom milyensége legyen korlátozva, hanem az is, hogy mely gépek érhetik el egyáltalán a bels® hálózaton kívüli gépeket. Valamint az, hogy a VPN-en kapcsolódó felhasználók csak a számukra engedélyezett szolgáltatásokat tudják használni. Nagyon hasznos, alapos és jó (bár angol nyelv¶) olvasmány a csomagsz¶rés témában: [4], amely többféle formátumban is letölthet® az oldalról. Egy szkriptben készítettem el a csomagsz¶r®nk beállításait, hogy egyszer¶en használhassak változóneveket is. Viszont semmi sem akadályoz meg bennünket abban, hogy ha egyszer betöltöttük a szabályainkat, akkor az egy fájlba, és a rendszer indulásakor az
iptables-save parancs segítségével kimentsük azokat iptables-restore parancs segítségével abból a fájlból
töltsük ®ket vissza.
2009. március 23.
Kósa Attila
Debian GNU/Linux
118
Önkényesen választott elnevezéseket használok a saját láncok neveként, illetve a változók neveiként, de bízom benne, hogy érthet®. A feltételezés az, hogy a t¶zfal egy dhcp szervert®l kapja az IP címét, amely dinamikusan változik, tehát nem x a cím.
3 Ha ftp elérést is sze-
retnénk a t¶zfalon keresztül engedélyezni, akkor javasolt a megfelel® kernelmodulok betöltése (a 2.6-os sorozatnál az
ip_conntrack_ftp
és az
ip_nat_ftp
modulok). Az alábbi szkriptet a
magyarázatok feldarabolták, de egyetlen fájlba kell beírnunk! A kés®bb használt változókat deniáltam a szkript elején. #!/bin/sh BelsoInterface=eth1 KulsoInterface=eth0 KulsoIPCim=a.tuzfal.kulso.cime BELSO_PROXY=192.168.10.251 BELSO_MAIL=192.168.10.252 BELSO_SLAVEDNS=192.168.10.252 BELSO_DNS=192.168.10.253 BELSO_NTP=192.168.10.253 BELSO_WEB=192.168.10.247 ADMIN=192.168.10.10 VPN1NET=10.10.1.0
Itt az látható, hogy el®ször kitöröljük a jelenlegi szabályokat a
lter
és
nat
táblákat, majd
töröljük az általunk létrehozott láncokat. Ezekre a sorokra azért van szükség, hogy ha újra lefuttatjuk ezt a szkriptet, akkor nulláról jöjjenek létre a szabályaink, ne maradhasson bent régi szabály. A szkript els® futtatásakor emiatt hibaüzenet fogunk kapni, mely szerint nem léteznek a törölni kívánt láncok, de ez természetes, hiszen valóban nem léteznek, a törlés után fogjuk ®ket létrehozni. iptables iptables iptables iptables iptables iptables
-t -t -X -X -X -X
nat -F filter -F icmpk belso kulso DROPINVALID
Ezen sorok segítségével beállítjuk a iptables iptables iptables iptables iptables iptables
-t -t -t -t -t -t
filter filter filter nat -P nat -P nat -P
lter
és
nat
táblák alapértelmezett szabályait.
-P INPUT DROP -P FORWARD DROP -P OUTPUT ACCEPT PREROUTING ACCEPT POSTROUTING ACCEPT OUTPUT ACCEPT
Annak biztosítása, hogy a bels® hálózat proxy-jától érkez® csomagok úgy jussanak ki az Internetre, hogy a t¶zfal címével látszódjanak. Megtehetjük, hogy ezt a szabályt úgy írjuk meg, hogy csak megadott portokra men® csomagokra legyen érvényes, de a
FORWARD 3
láncban is
szabályozhatjuk, hogy mit engedünk át magunkon. Most ez utóbbit mutatom be. iptables -t nat -A POSTROUTING -s $BELSO_PROXY -o eth0 -j MASQUERADE #iptables -t nat -A POSTROUTING -s $BELSO_PROXY -o eth0 -j SNAT --to-source $KulsoIPCim
Az alábbi két szabály a t¶zfal két megadott küls® portjára érkez® kapcsolatokat berakja a bels® hálózat megadott gépeire. Ne felejtsük, hogy a
FORWARD
lánc erre vonatkozó szabályai
is szükségesek ahhoz, hogy a bels® gépeink a megadott portokon valóban elérhet®ek legyenek a külvilág számára! iptables -t nat -A PREROUTING -i $KulsoInterface -p tcp --dport 80 -j DNAT --to-destination $BELSO_WEB:80 iptables -t nat -A PREROUTING -i $KulsoInterface -p tcp --dport 993 -j DNAT --to-destination $BELSO_MAIL:993
A saját láncaink létrehozása. iptables iptables iptables iptables
3
-N -N -N -N
icmpk belso kulso DROPINVALID
Fix IP cím esetén a MASQUERADE helyett érdemesebb az SNAT megoldást használni.
Kósa Attila
2009. március 23.
Debian GNU/Linux
119
Az els® szabály azt biztosítja, hogy a loopback interfészen minden forgalom lehetséges legyen. A második szabály a t¶zfalra érkez® az
icmpk
ICMP
csomagok sorsáról rendelkezik (betereli ®ket
néven létrehozott saját láncunkba). A harmadik szabály az
iptables
állapottartó
lehet®ségét használja ki. Ily módon arról értesítettük a kernelünket, hogy a már kiépült kapcsolatokhoz tartozó csomagokat engedélyezze. A negyedik szabály a
DROPINVALID nev¶ saját
láncunkba tereli a kernel által INVALID állapotúnak érzékelt csomagokat. Az utolsó sor szintén a
DROPINVALID
láncba küldi a csomagokat, de csak azokat, amelyek NEW állapotúak ugyan,
de nincs bekapcsolva bennük a iptables iptables iptables iptables iptables
-A -A -A -A -A
INPUT INPUT INPUT INPUT INPUT
-i -p -m -m -p
SYN
bit.
lo -j ACCEPT icmp -j icmpk state --state ESTABLISHED,RELATED -j ACCEPT state --state INVALID -j DROPINVALID tcp -m state --state NEW ! --syn -j DROPINVALID
A forgalom átirányítása a saját láncainkra attól függ®en, hogy a t¶zfal melyik hálózati kártyáján érkezik. iptables -A INPUT -i $BelsoInterface -j belso iptables -A INPUT -i $KulsoInterface -j kulso
Azt a forgalmat, amely a szabályainkon kívül esik, azt logoljuk, majd eldobjuk. iptables -A INPUT -j LOG --log-prefix "INPUT DROP: " iptables -A INPUT -j DROP
Az els® szabály ismer®s lehet, hiszen az
INPUT
láncban már kiadtunk egy hasonlót. Itt
is ugyanaz a feladata, mint ott. A második, harmadik és negyedik szabállyal azt állítjuk be, hogy a bels® hálózaton lév® proxyszerverünk az általában használatos portokra (ftp 21, http 80, https 443) kimehessen (és persze rajta keresztül a proxy-n engedélyezett egyéb bels® gépek is). Az utolsó két sor a külvilág számára teszi lehet®vé a két megadott bels® gépünk megfelel® portjának az elérését. Ne felejtsük, hogy ezek a szabályok összefüggésben állnak a
PREROUTING iptables iptables iptables iptables iptables iptables
-A -A -A -A -A -A
FORWARD FORWARD FORWARD FORWARD FORWARD FORWARD
-p -p -p -p -p -p
láncban meghatározott
tcp tcp tcp tcp tcp tcp
-m -m -m -m -m -m
state state state state state state
--state --state --state --state --state --state
DNAT
szabályokkal!
ESTABLISHED,RELATED -j ACCEPT NEW --syn -s $BELSO_PROXY --dport 21 -j ACCEPT NEW --syn -s $BELSO_PROXY --dport 80 -j ACCEPT NEW --syn -s $BELSO_PROXY --dport 443 -j ACCEPT NEW --syn -d $BELSO_WEB --dport 80 -j ACCEPT NEW --syn -d $BELSO_MAIL --dport 993 -j ACCEPT
Itt szabályozzuk a 10.10.1.0/24-es VPN hálózatunkból érkez® kapcsolatokat. Az els® szabály a névfeloldást végz® bels® szerverünk elérését engedélyezi UDP protokollon, a második szabály pedig minden bels® hálózaton lév® gép elérését lehet®vé teszi TCP protokollon keresztül. iptables -A FORWARD -p udp -m state --state NEW --syn -s VPN1NET -d $BELSO_DNS --dport 53 -j ACCEPT iptables -A FORWARD -p tcp -m state --state NEW --syn -s VPN1NET -j ACCEPT
Azt a forgalmat, amely a szabályainkon kívül esik, azt logoljuk, majd eldobjuk. iptables -A FORWARD -j LOG --log-prefix "FORWARD DROP: " iptables -A FORWARD -j DROP
Azokat az
ICMP típusokat soroltam fel itt, amelyek eljuthatnak a t¶zfalhoz. Ezeket általában
érdemes engedélyezni, bár a ping-r®l megoszlanak a vélemények. iptables iptables iptables iptables iptables iptables
-A -A -A -A -A -A
icmpk icmpk icmpk icmpk icmpk icmpk
-p -p -p -p -p -p
icmp icmp icmp icmp icmp icmp
--icmp-type --icmp-type --icmp-type --icmp-type --icmp-type --icmp-type
destination-unreachable -j ACCEPT time-exceeded -j ACCEPT parameter-problem -j ACCEPT source-quench -j ACCEPT echo-request -j ACCEPT echo-reply -j ACCEPT
Azt a forgalmat, amely a szabályainkon kívül esik, azt logoljuk, majd eldobjuk.
2009. március 23.
Kósa Attila
Debian GNU/Linux
120
iptables -A icmpk -j LOG --log-prefix "Icmpk DROP: " iptables -A icmpk -j DROP
Korlátozzuk, hogy a bels® hálózatból mely gépek a t¶zfal melyik portját érhetik el. Így érvé-
4
nyesítjük azt az elvet , hogy a t¶zfallal a munkaállomások nem léphetnek közvetlen kapcsolatba, csak valamelyik bels® szerveren keresztül csinálhatnak bármit is (levelet csak a bels® mailszerver küldhet a t¶zfalnak, névfeloldásért csak a két dns szerver fordulhat a t¶zfalhoz, a t¶zfal id®szolgáltatását csak a bels® ntp szerver veheti igénybe, és csak az adminisztrátor gépér®l lehet elérni a t¶zfalat iptables iptables iptables iptables iptables iptables iptables
-A -A -A -A -A -A -A
belso belso belso belso belso belso belso
-p -p -p -p -p -p -p
tcp udp tcp udp tcp udp tcp
ssh-val).
-s -s -s -s -s -s -s
$BELSO_MAIL --dport 25 -j ACCEPT $BELSO_DNS --dport 53 -j ACCEPT $BELSO_DNS --dport 53 -j ACCEPT $BELSO_SLAVEDNS --dport 53 -j ACCEPT $BELSO_SLAVEDNS --dport 53 -j ACCEPT $BELSO_NTP --dport 123 -j ACCEPT $ADMIN --dport 22 -j ACCEPT
Azt a forgalmat, amely a szabályainkon kívül esik, azt logoljuk, majd eldobjuk. iptables -A belso -j LOG --log-prefix "belso DROP: " iptables -A belso -j DROP
A küls® portjaink elérésére vonatkozó szabályok. Az els® a dinamikus IP cím miatt van, a második azért, hogy tudjanak nekünk levelet küldeni. A harmadik pedig azért, mert egyes levelez®szerverek megpróbálják elérni az
identd démont, hogy információhoz jussanak a levelet
küld®r®l, és amíg ez nem sikerül nekik (vagy az erre szánt id® le nem jár), addig nem veszik el t®lünk a levelet. A
REJECT
szabálynak köszönhet®en azonnal elutasító választ kap a kérdez®,
így nem kell az id®túllépést megvárnunk, gyorsabb lesz a levél elküldése. iptables -A kulso -p udp --sport 67 --dport 68 -j ACCEPT iptables -A kulso -p tcp --dport 25 -j ACCEPT iptables -A kulso -p tcp --dport 113 -j REJECT
Azt a forgalmat, amely a szabályainkon kívül esik, azt logoljuk, majd eldobjuk. iptables -A kulso -j LOG --log-prefix "kulso DROP: " iptables -A kulso -j DROP
Az összes érvénytelen csomagot logoljuk, majd eldobjuk. iptables -A DROPINVALID -j LOG --log-prefix "INVALID packet: " iptables -A DROPINVALID -j DROP
4
Azt hiszem, hogy ebben sincs teljes egyetértés a biztonsággal foglalkozó szakemberek között, ezért minden-
kinek saját belátása szerint kell döntenie.
Kósa Attila
2009. március 23.
GNU Szabad Dokumentációs Licenc 1.1 verzió, 2000 március
Copyright
c 2000
Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA Jelen licenc szó szerinti sokszorosítása és terjesztése bárki számára megengedett, változtatni rajta ugyanakkor nem lehet.
0. ELSZÓ Jelen Licenc célja egy olyan kézikönyv, tankönyv, vagy eajta írott dokumentum megalkotása, mely a szó szoros értelmében szabad: annak érdekében, hogy mindenkinek biztosítsa a szöveg sokszorosításának és terjesztésének teljes szabadságát, módosításokkal, vagy anélkül, akár kereskedelmi, akár nem-kereskedelmi úton. Másfel®l, e Licenc meg®rzi a szerz®, vagy kiadó munkája elismeréséhez f¶z®d® jogát, s egyúttal mentesíti ®t a mások által beiktatott módosítások következményei alól. Jelen Licenc egyfajta etalonnak tekinthet®, ami nem jelent mást, mint hogy a dokumentumból származtatott munkák maguk is szabad min®sítést kell, hogy kapjanak. E dokumentum egyben a GNU Általános Felhasználói Licenc kiegészít®jeként is szolgál, mely egy a szabad szoftverekre vonatkozó etalon licenc. E Licencet a szabad szoftverek kézikönyveiben való használatra alkottuk, hiszen a szabad szoftver egyben szabad dokumentációt is igényel: egy szabad programot olyan kézikönyvvel kell ellátni, mely ugyanazon szabadságokat biztosítja, mint maga a program. Jelen Licenc, mindazonáltal, nem korlátozódik pusztán kézikönyvekre; feltételei tetsz®leges tárgykör¶ írott dokumentumra alkalmazhatók, függetlenül attól, hogy az könyvformában valaha megjelent-e. Mindamellett e Licencet f®ként olyan munkákhoz ajánljuk, melyek els®dleges célja az útmutatás, vagy a tájékoztatás.
1. ALKALMAZHATÓSÁG ÉS DEFINÍCIÓK E Licenc minden olyan kézikönyvre, vagy más jelleg¶ munkára vonatkozik, melyen megtalálható a szerz®i jogtulajdonos által feltüntetett gyelmeztetés, miszerint a dokumentum terjesztése jelen Licenc feltételei alapján lehetséges. A Dokumentum alább bármely ilyen jelleg¶ kézikönyvre, vagy egyéb munkára vonatkozik. A lakosság minden tagja potenciális licenctulajdonosnak tekinthet®, és mindegyikük megszólítása egyaránt ön. A Dokumentum Módosított Változata bármely olyan munkára vonatkozik, mely tartalmazza a Dokumentumot, vagy annak elemeit akár szó szerint, akár módosításokkal, és/vagy más nyelvre lefordítva. A Másodlagos Szakasz egy egyedi névvel bíró függelék, esetleg a Dokumentum egy megel®z® szakasza, mely kizárólag a kiadóknak, vagy az alkotóknak a Dokumentum átfogó tárgyköréhez
121
Debian GNU/Linux
122
(vagy kapcsolódó témákhoz) f¶z®d® viszonyáról szól, és nem tartalmaz semmi olyat, ami közvetlenül ezen átfogó témakör alá eshet. (Ha például a Dokumentum részben egy matematika tankönyv, úgy a Másodlagos Szakaszban nincs lehet®ség matematikai tárgyú magyarázatokra.) A fenti kapcsolat tárgya lehet a témakörrel, vagy a kapcsolódó témákkal való történelmi viszony, illetve az azokra vonatkozó jogi, kereskedelmi, lozóai, etikai, vagy politikai felfogás. A Nem Változtatható Szakaszok olyan speciális Másodlagos Szakasznak számítanak, melyek ilyetén való meghatározását az a közlemény tartalmazza, miszerint a Dokumentum jelen Licenc hatálya alatt lett kiadva. A Borítószövegek olyan rövid szövegrészek, melyek Címlap-szövegként, illetve Hátlapszövegként kerülnek felsorolásra abban a közleményben, miszerint a Dokumentum jelen Licenc hatálya alatt lett kiadva. A Dokumentum Átlátszó példánya olyan géppel-olvasható változatot jelöl, mely a nyilvánosság számára hozzáférhet® formátumban kerül terjesztésre, továbbá melynek tartalma szokványos szövegszerkeszt®-programokkal, illetve (pixelekb®l álló képek esetén) szokványos képmegjelenít®-programokkal, vagy (rajzok esetén) általánosan hozzáférhet® rajzprogramok segítségével azonnal és közvetlenül megtekinthet®, vagy módosítható; továbbá olyan formátumban mely alkalmas a szövegszerkeszt®kbe való bevitelre, vagy a szövegszerkeszt®k által kezelt formátumokba való automatikus átalakításra. Egy olyan, egyébként Átlátszó formátumban készült példány, melynek markupja úgy lett kialakítva, hogy megakadályozza, vagy eltántorítsa az olvasókat minden további módosítástól, nem tekinthet® Átlátszónak. A nem Átlátszó példányok az Átlátszatlan megnevezést kapják. Az Átlátszóság kritériumainak megfelel® formátumok között megtalálható például a markup AT X beviteli formátum, az SGML vagy nélküli egyszer¶ ASCII, a Texinfo beviteli formátum, a L E az XML egy általánosan hozzáférhet® DTD használatával, és a standardnak megfelel®, emberi módosításra tervezett egyszer¶ HTML. Az Átlátszatlan formátumok közé sorolható a PostScript, a PDF, a szabadalmaztatott és csak zet®s szövegszerkeszt®kkel olvasható formátumok, az olyan SGML vagy XML, melyhez a szükséges DTD és/vagy egyéb feldolgozó eszközök nem általánosan hozzáférhet®k, és az olyan gépileg-generált HTML formátum, melyet egyes szövegszerkeszt®k hoznak létre, kizárólag kiviteli célra. Egy nyomtatott könyv esetében a Címlap magát a címlapot, illetve bármely azt kiegészít® további oldalt jelöl, amely a jelen Licencben deniált címlap-tartalmak közzétételéhez szükséges. Az olyan formátumú munkáknál, melyek nem rendelkeznek eajta címlappal, a Címlap a munka címéhez legközelebb es®, ám a szöveg törzsét megel®z® szövegrészeket jelöli.
2. SZÓ SZERINTI SOKSZOROSÍTÁS Önnek lehet®sége van a dokumentum kereskedelmi, vagy nem-kereskedelmi jelleg¶ sokszorosítására és terjesztésére, bármely médiumon keresztül, feltéve, hogy jelen Licenc, a szerz®i jogi gyelmeztetés, továbbá a Dokumentumot jelen Licenc hatálya alá rendel® közlemény minden példányban egyaránt megjelenik, és hogy e feltételeken kívül semmi mást nem tesz hozzá a szöveghez. Nem alkothat olyan technikai korlátokat, melyek megakadályozhatják, vagy szabályozhatják az ön által terjesztett példányok elolvasását, vagy sokszorosítását. Mindazonáltal elfogadhat bizonyos összeget a másolatok fejében. Amennyiben az ön által terjesztett példányok száma meghalad egy bizonyos mennyiséget, úgy a 3. szakasz feltételeinek is eleget kell tennie. A fenti kritériumok alapján kölcsönbe adhat egyes példányokat, de akár nyilvánosan is közzéteheti a szöveget.
Kósa Attila
2009. március 23.
Debian GNU/Linux
123
3. SOKSZOROSÍTÁS NAGYOBB MENNYISÉGBEN Amennyiben 100-nál több nyomtatott változatot tesz közzé a Dokumentumból, és annak Licence feltételül szabja a Borítószövegek meglétét, úgy minden egyes példányt köteles ellátni olyan borítólapokkal, melyeken a következ® Borítószövegek tisztán és olvashatóan fel vannak tüntetve: Címlap-szövegek a címlapon, illetve Hátlap-szövegek a hátlapon. Mindkét borítólapra egyértelm¶en és olvashatóan rá kell vezetnie a kiadó, vagyis jelen esetben az ön nevét. A címlapon a Dokumentum teljes címének jól láthatóan, továbbá minden egyes szónak azonos szedésben kell megjelennie. Ezen felül, belátása szerint, további részleteket is hozzáadhat a borítólapokhoz. Amennyiben az esetleges módosítások kizárólag a borítólapokat érintik, és feltéve, hogy a Dokumentum címe változatlan marad, továbbá a borítólapok megfelelnek minden egyéb követelménynek, úgy a sokszorosítás ett®l eltekintve szó szerinti reprodukciónak min®sül. Abban az esetben, ha a borítólapok bármelyikén megkövetelt szövegrészek túl hosszúnak bizonyulnának az olvasható közzétételhez, úgy csak az els®ként felsoroltakat kell feltüntetnie (amennyi józan belátás szerint elfér) a tényleges borítón, a továbbiak pedig átkerülhetnek a következ® oldalakra. Amennyiben 100-nál több Átlátszatlan példányt tesz közzé, vagy terjeszt a Dokumentumból, úgy köteles vagy egy géppel-olvasható Átlátszó példányt mellékelni minden egyes Átlátszatlan példányhoz, vagy leírni minden egyes Átlátszatlan példányban egy a módosítatlan Átlátszó példányt tartalmazó nyilvános hozzáférés¶ számítógép-hálózat elérhet®ségét, ahonnan bárki, anonim módon, térítésmentesen letöltheti azt, egy közismert hálózati protokoll használatával. Ha az utóbbi lehet®séget választja, köteles gondoskodni arról, hogy attól a naptól kezdve, amikor az utolsó Átlátszatlan példány is terjesztésre került (akár közvetlenül ön által, akár kiskereskedelmi forgalomban), a fenti helyen közzétett Átlátszó példány még legalább egy évig hozzáférhet® legyen a felhasználók számára. Megkérjük, ámde nem kötelezzük önt arra, hogy minden esetben, amikor nagyobb példányszámú terjesztésbe kezd, már jóval ezt megel®z®en lépjen kapcsolatba a Dokumentum szerz®ivel, annak érdekében, hogy megkaphassa t®lük a Dokumentum esetleges felújított változatát.
4. MÓDOSÍTÁS Önnek lehet®sége van a Dokumentum Módosított Változatának sokszorosítására és terjesztésére a 2. és 3. szakaszok fenti rendelkezései alapján, feltéve, hogy a Módosított Változatot kizárólag jelen Licenc feltételeivel összhangban teszi közzé, ahol a Módosított Változat a Dokumentum szerepét tölti be, ezáltal lehet®séget biztosítva annak terjesztésére és módosítására bárkinek, aki csak hozzájut egy példányához. Mindezen felül, a Módosított Változat az alábbi követelményeknek is meg kell, hogy feleljen:
•
A Címlapon (és ha van, a borítókon) tüntessen fel egy a Dokumentumétól, illetve bármely korábbi változatétól eltér® címet (melyeknek, ha vannak, a Dokumentum El®zmények szakaszában kell szerepelniük). Egy korábbi változat címét csak akkor használhatja, ha annak szerz®je engedélyezte azt.
•
A Címlapon szerz®kként sorolja fel a Módosított Változatban elvégzett változtatásokért felel®s személyeket, vagy entitásokat, továbbá a Dokumentum f® szerz®i közül legkevesebb ötöt (vagy mindet, ha nincsenek öten).
•
A Címlapon a Módosított Változat közzétételéért felel®s személyt tüntesse fel kiadóként.
•
A Dokumentum összes szerz®i jogi gyelmeztetését hagyja érintetlenül.
•
Saját módosításaira vonatkozóan is tegyen közzé egy szerz®i jogi megjegyzést, a többi ilyen jelleg¶ gyelmeztetés mellett.
2009. március 23.
Kósa Attila
Debian GNU/Linux
124
•
Rögtön a szerz®i jogi gyelmeztetéseket követ®en tüntessen fel egy közleményt, az alábbi Függelék mintájára, melyben engedélyezi a Módosított Változat felhasználását jelen Licenc feltételei alapján.
•
A fenti közleményben hagyja érintetlenül a Nem Változtatható Szakaszok és a szükséges Borítószövegek jelen Dokumentum licencében el®írt teljes listáját.
•
Mellékelje jelen Licenc egy eredeti példányát.
•
Az El®zmények szakaszt, illetve annak címét szintén hagyja érintetlenül, emellett adjon hozzá egy új elemet, amely minimálisan tartalmazza a Módosított Változat címét, kiadási évét, továbbá az új szerz®k, illetve a kiadó nevét, a Címlapon láthatókhoz hasonlóan. Amennyiben a Dokumentum nem tartalmaz semmiféle El®zmények elnevezés¶ szakaszt, úgy hozzon létre egyet, mely tartalmazza a Dokumentum címét, kiadási évét, továbbá a szerz®k, illetve a kiadó nevét, a Címlapon láthatókhoz hasonlóan; majd ezt követ®en adjon hozzá egy új, a Módosított Változatra vonatkozó elemet, a fentiekkel összhangban.
•
Ne tegyen változtatásokat a Dokumentumban megadott Átlátszó példány nyilvános hálózati elérhet®ségét (ha van ilyen) illet®en, vagy hasonlóképp, a Dokumentum alapjául szolgáló korábbi változatok hálózati helyére vonatkozóan. Ezek az El®zmények szakaszban is szerepelhetnek. Csak abban az esetben hagyhatja el egyes korábbi változatok hálózati elérhet®ségét, ha azok legkevesebb négy évvel a Dokumentum el®tt készültek, vagy ha maga az alkotó engedélyezi azt.
•
Bármely Köszönetnyilvánítás, vagy Ajánlások szakasz címét hagyja érintetlenül, továbbá gondoskodjon arról, hogy azok tartalma és hangvétele az egyes hozzájárulókat, és/vagy az ajánlásokat illet®en változatlan maradjon.
•
A Dokumentum összes Nem Változtatható Szakaszát hagyja érintetlenül, úgy címüket, mint tartalmukat illet®en. A szakaszok számozása, vagy bármely azzal egyenérték¶ jelölés nem tartozik a szakaszcímek közé.
•
Töröljön minden Jóváhagyás elnevezés¶ szakaszt. Eajta szakaszok nem képezhetik részét a Módosított Változatnak.
•
Ne nevezzen át semmilyen létez® szakaszt Jóváhagyás-ra, vagy olyasmire, mely címében a Nem Változtatható Szakaszokkal ütközhet.
Ha a Módosított Változat új megel®z® szakaszokat tartalmaz, vagy olyan függelékeket, melyek Másodlagos Szakasznak min®sülnek, ám nem tartalmaznak a Dokumentumból származó anyagot, abban az esetben, belátása szerint, e szakaszok némelyikét, vagy akár az összeset nem változtathatóként sorolhatja be. Ehhez nem kell mást tennie, mint felsorolni a szóban forgó címeket a Módosított Változat licencének Nem Változtatható Szakaszok listájában. E címeknek határozottan el kell különülnie minden egyéb szakaszcímt®l. Jóváhagyás elnevezés¶ szakaszt csak akkor adhat a Dokumentumhoz, ha az kizárólag a Módosított Változatra utaló megjegyzéseket tartalmaz például mások recenzióira vonatkozóan, vagy hogy egy szervezet a szöveget egy standard mérvadó deníciójaként ismerte el. Címlap-szöveg gyanánt egy legfeljebb öt szóból álló szövegrészt adhat meg, a Hátlap-szöveg esetén pedig 25 szót f¶zhet a Módosított Változat Borítószövegeinek végéhez. Bármely entitás csak és kizárólag egy Címlap- és egy Hátlap-szövegrészt adhat (akár közvetít®n keresztül) a Dokumentumhoz. Ha a dokumentum már eleve rendelkezik Borítószöveggel, akár azért, mert azt korábban ön adta hozzá, vagy mert valaki más önön keresztül gondoskodott err®l, abban az esetben nincs lehet®ség újabb Borítószöveg hozzáadására; a régit mindazonáltal lecserélheti, abban az esetben, ha annak kiadója egyértelm¶en engedélyezi azt.
Kósa Attila
2009. március 23.
Debian GNU/Linux
125
A Dokumentum szerz®je/i és kiadója/i jelen Licenc alapján nem teszik lehet®vé nevük nyilvános felhasználását egyetlen Módosított Változat támogatása, vagy támogatottsága érdekében sem.
5. KOMBINÁLT DOKUMENTUMOK Önnek lehet®sége van a Dokumentum egyéb, e Licenc hatálya alatt kiadott dokumentumokkal való kombinálására a 4. szakasz módosított változatokra vonatkozó rendelkezései alapján, feltéve, hogy a kombináció módosítás nélkül tartalmazza az eredeti dokumentumok összes Nem Változtatható Szakaszát, és hogy azok mind Nem Változtatható Szakaszként kerülnek felsorolásra a kombinált munka licencében. A kombinált munkának jelen Licenc mindössze egy példányát kell tartalmaznia, az egymással átfedésben lév® Nem Változtatható Szakaszok pedig kiválthatók egy összegzett példánnyal. Amennyiben több Nem Változtatható Szakasz szerepelne ugyanazon címmel, ám eltér® tartalommal, úgy alakítsa át minden egyes szakasz címét olyan módon, hogy mögéírja zárójelben az eredeti szerz® és kiadó nevét (ha ismeri), vagy egy egyedi sorszámot. Ha szükséges, a Nem Változtatható Szakaszok címeivel is végezze el a fenti módosításokat a kombinált munka licencében. A kombinált munkában az eredeti dokumentumok összes El®zmények elnevezés¶ szakaszát össze kell olvasztania, miáltal egy összefügg® El®zmények szakasz jön létre; hasonlóképp kell eljárnia a Köszönetnyilvánítás, illetve az Ajánlások szakaszok tekintetében. Ugyanakkor minden Jóváhagyás elnevezés¶ szakaszt törölnie kell.
6. DOKUMENTUMGYJTEMÉNYEK Önnek lehet®sége van a Dokumentumból, illetve bármely egyéb, e Licenc hatálya alatt kiadott dokumentumból gy¶jteményt létrehozni, és az egyes dokumentumokban található licenceket egyetlen példánnyal kiváltani, feltéve, hogy a gy¶jteményben szerepl® összes dokumentum esetén minden más tekintetben követi jelen Licenc feltételeit, azok szó szerinti sokszorosítására vonatkozóan. Tetszése szerint ki is emelhet egy meghatározott dokumentumot a gy¶jteményb®l, továbbá terjesztheti azt jelen Licenc feltételei alapján, feltéve, hogy a szóban forgó dokumentumhoz mellékeli e Licenc egy példányát, és minden egyéb tekintetben betartja jelen Licenc el®írásait a dokumentum szó szerinti sokszorosítására vonatkozóan.
7. ÖSSZEFZÉS FÜGGETLEN MUNKÁKKAL A Dokumentum és annak származékainak különálló, vagy független dokumentumokkal, illetve munkákkal való összef¶zése egy közös tárolási, vagy terjesztési egységen, egészében nem tekinthet® a Dokumentum Módosított Változatának, feltéve, hogy az összef¶zés nem lesz szerz®i jogvédett. Az eajta összef¶zés eredményeként összegzés jön létre, ám jelen Licenc nem érvényes az abban a Dokumentummal együtt szerepl® önálló munkákra, hacsak azok nem a Dokumentum származékai. Amennyiben a 3. szakasz Borítószövegekre vonatkozó rendelkezései alkalmazhatók a Dokumentum e példányaira, és a Dokumentum a teljes összegzésnek kevesebb, mint egynegyedét teszi ki, úgy a Dokumentum Borítószövegeit olyan módon is el lehet helyezni, hogy azok csak magát a Dokumentumot fogják át. Minden más esetben a teljes összegzés borítólapjain kell feltüntetni a fenti szövegeket.
2009. március 23.
Kósa Attila
Debian GNU/Linux
126
8. FORDÍTÁS A fordítás egyfajta módosításnak tekinthet®, így hát a Dokumentum lefordított példányai a 4. szakasz rendelkezései alapján terjeszthet®k. A Nem Változtatható Szakaszok lefordítása külön engedélyt igényel a szerz®i jogtulajdonostól, mindazonáltal közzéteheti a lefordított változatokat is abban az esetben, ha az eredeti Nem Változtatható Szakaszokat is belefoglalja a munkába. E Licenc lefordítására ugyanezek a feltételek érvényesek, vagyis a lefordított változat csak akkor jelenhet meg, ha mellette ott van az eredeti, angol nyelv¶ Licenc szövege is. Amennyiben eltérés mutatkozna az eredeti változat, illetve a fordítás között, úgy a Licenc angol nyelv¶ eredetije tekintend® mérvadónak.
9. MEGSZNÉS A jelen Licencben egyértelm¶en kijelölt kereteken kívül tilos a Dokumentum bárminem¶ sokszorosítása, módosítása, allicencelése, vagy terjesztése. Minden ezzel szembeni sokszorosítási, módosítási, allicencelési, vagy terjesztési kísérlet a jelen Licencben meghatározott jogok automatikus megsz¶nését vonja maga után. Azok a felek, ugyanakkor, akik önön keresztül jutottak másolathoz, vagy jogosultságokhoz, nem veszítik el azokat, amíg maradéktalanul betartják e Licenc el®írásait.
10. JELEN LICENC JÖVBENI JAVÍTÁSAI Megtörténhet, hogy a Szabad Szoftver Alapítvány id®r®l id®re felülvizsgált és/vagy új verziókat bocsát ki a GNU Szabad Dokumentációs Licencb®l. E verziók szellemisége hasonló lesz jelen változatéhoz, ám részleteikben eltérhetnek, új problémák, új aggályok felmerülése okán. Vö.:
http://www.gnu.org/copyleft/
A Licenc minden változata egyedi verziószámmal van ellátva. Ha a Dokumentum jelen Licenc egy konkrét, számozott verziójára, vagy bármely újabb verzióra hivatkozik, úgy önnek a szóban forgó változat, vagy bármely újabb a Szabad Szoftver Alapítvány által (nem vázlatként) publikált verzió feltételeinek követésére lehet®sége van. Ha a Dokumentum nem ad meg semmilyen verziószámot, úgy bármely, a Szabad Szoftver Alapítvány által valaha (nem vázlatként) publikált változat megfelel.
FÜGGELÉK: A Licenc alkalmazása saját dokumentumaira Ha e Licencet egy ön által írt dokumentumban kívánja használni, akkor mellékelje hozzá a Licenc egy példányát, továbbá vezesse rá az alábbi szerz®i jogi és licenc közleményeket, rögtön a címlapot követ®en: c ÉV AZ ÖN NEVE. Copyright 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 SOROLJA FEL A CÍMÜKET, a Címlapszövegek neve LISTA, a Hátlap-szövegek neve pedig LISTA. E licenc egy példányát a GNU Szabad Dokumentációs Licenc elnevezés¶ szakasz alatt találja. Ha a szövegben nincsenek Nem Változtatható Szakaszok, úgy írjon nincs Nem Változtatható Szakasz-t, ahelyett, hogy egyenként felsorolná azokat. Ha nincsenek Címlap-szövegek, akkor
Kósa Attila
2009. március 23.
Debian GNU/Linux
127
írjon nincs Címlap-szöveg-et, ahelyett, hogy a Címlap-szövegek neve LISTA, és hasonlóképp járjon el a Hátlap-szövegek esetében is. Amennyiben a dokumentum haladó programkód-példákat is tartalmaz, úgy azt javasoljuk, hogy e példákat egy választása szerinti szabad szoftver licenc alatt közölje mint például a GNU Általános Felhasználói Licenc , hogy lehet®vé tegye a kódok szabad szoftverekben való alkalmazását.
2009. március 23.
Kósa Attila
Tárgymutató
r parancsok, 103
lpr, 106
Amanda, 87
named-checkconf, 23
Amanda beállítás, 89, 90, 94
named-checkzone, 24
Amanda kliens, 87
NFS, 105
Amanda szerver, 88
NIS/YP, 105
Amanda visszaállítás, 96
NNTP, 104
amrecover, 96
node-type, 60
amrestore, 96
normál ftp, 102
Apache, 77, 78
nslookup, 25
Apache telepítés, 77
NTP, 100
AUTH, 101
ntp, 31
BIND, 107 BIND8, 13 BIND9, 18 CA létrehozása, 36 csomagsz¶rés, 117 dig, 25 DNS, 99 DNS lekérdezés, 100 DNS zónatranszfer, 100 dovecot, 69 dovecot beállítás, 69 dovecot telepítés, 69 FDL, 121 nger, 103 FTP, 102 host, 25
ntp-server, 109 ntpdate, 33, 111 OpenLDAP, 43 OpenLDAP feltöltése, 47 OpenLDAP replika, 46 OpenLDAP telepítése, 43 OpenVPN, 113 OpenVPN szerver, 114 OpenVPN telepítés, 113 OpenVPN Windows alatt, 116 passzív ftp, 102 pogsumm, 83 POP2, 101 POP3, 101 POP3S, 101 postx, 65, 112 postx beállítás, 66 postx telepítés, 65
HTTP, 102 HTTPS, 102
rndc, 24
ICMP, 100
SaMBa, 55, 106
IMAP, 69, 101
SaMBa telepítés, 55
IMAP tesztelés, 70
SaMBa tesztelés, 58
IMAPS, 101
SMTP, 65, 101
IRC, 105
SMTP tesztelés, 67 SNMP, 105
logcheck, 81
Squid, 73
logrotate, 82
SSH, 104
128
Debian GNU/Linux
129
ssh, 38 ssh beállítás, 39 ssh kulcsgenerálás, 38 ssh kulcsmásolás, 39 ssh-agent, 40 SSL, 35 syslog, 103 syslog-ng, 84 syslog-ng kliensen, 84 syslog-ng szerveren, 84 talk, 104 tanúsítvány létrehozása, 36 tanúsítványok aláírása, 37 telnet, 104 TFTP, 102 traceroute, 101 UUCP, 101 whois, 103 wpad, 75 X11, 105
2009. március 23.
Kósa Attila
Debian GNU/Linux
130
Kósa Attila
2009. március 23.
Irodalomjegyzék
[1] D. RICHARD KUHN VINCENT C. HU W. TIMOTHY POLK SHU-JEN CHANG: Introduction to Public Key Technology and the Federal PKI Infrastrukture U.S. Govern-
ment Publication. 2001. február 26. http://csrc.nist.gov/publications/nistpubs/ index.html http://www.itktb.hu/resource.aspx/?ResourceID=Publikus_Kulcsu_Technologia_ V1 [2] ENDRDI CSILLA: Dife-Hellman kulcsegyeztet® protokoll. 2004. 10. 22.
biztostu.hu/mod/resource/view.php?id=241
http://www.
[3] JELMER R. VERNOOIJ JOHN H. TERPSTRA GERALD (JERRY) CARTER: The Ofcial Samba-3 HOWTO and Reference Guide. É.n.
docs/man/Samba-HOWTO-Collection/ [4] OSKAR
ANDREASSON:
Iptables
Tutorial.
frozentux.net/iptables-tutorial.html
É.n.
http://us4.samba.org/samba/
http://iptables-tutorial.
[5] PÁSZTOR MIKLÓS: Az internet DNS Elv és konguráció. É.n.
hu/dns/index.html
http://szabilinux.
AT X kezd®knek és haladók[6] WETTL FERENC MAYER GYULA SUDÁR CSABA: L E nak. Budapest, Panem., 1998. AT X kézikönyv. Budapest, [7] WETTL FERENC MAYER GYULA SZABÓ PÉTER: L E Panem Kft., 2004. [8] N.N. BSD System Manager's Manual (man 8 sshd) 1999. 09. 25. [9] N.N. Name-based Virtual Host Support. É.n.
vhosts/name-based.html
http://httpd.apache.org/docs/1.3/
[10] N.N. Navigator Proxy Auto-Cong File Format. 1996. március
eng/mozilla/2.0/relnotes/demo/proxy-live.html
131
http://wp.netscape.com/