IV. MEGVALÓSÍTÁS
IV. Megvalósítás
A következőkben a Debian GNU/Linux 2.2 (Potato) változatának telepítését és behangolását fogom bemutatni lépésről lépésre. Ennek a fejezetnek az elolvasása inkább csak a rendszergazda-beállítottságú embereknek javasolt. Az egész fejezet elolvasásának csak akkor van értelme, ha egy számítógép mellett ülve végigkövetjük a teendőket. Azok számára, akik nem követik végig a feladatmegoldásomat, az egész fejezet értelmetlennek tűnhet, mert az anyag “másik fele” a számítógép monitorán jelenik meg (mivelhogy minden egyes képernyőképet nem tudok itt bemutatni).
Fontos feltétel, hogy addig, amíg az összes beállítást el nem végeztük a rendszeren és le nem teszteltük széleskörűen szerverünket, NE tegyük ki élesben az Internetre. A telepítést úgy végezzük, hogy a gép le legyen választva minden hálózatról. A tesztelést egy Internettől elzárt, belső hálózati szegmensen végezzük (mely nem része a produktív hálózatnak). Ekkor persze hogy lenne lehetséges az Internetről való telepítés? - kérdezheti az olvasó. Ha mindenképp ezt a megoldást választjuk, nem baj. Lényeg az, hogy a telepítés megkezdése előtt állítsuk be megfelelően a tűzfalat, nehogy menet közben rögtön ránk akadjanak. Továbbá a csomagok letöltése után kapcsolódjunk le a hálózatról. (Vagy töltsük le a csomagokat egy másik gépre, stb.)
1. Gyorstalpalás
A következőkben a “totálisan türelmetlenek” számára néhány lépésben felvázolom a Debian GNU/Linux Potato kiadásának telepítését. Később finomhangolom a rendszert.
1.1 A szoftver beszerezése: CD-set, vagy FTP tükör.
Mi sem egyszerűbb, mint letölteni a CD ISO image fájlokat (jelenleg 3 db kompakt lemez110) és kiíratni őket. A lemezek elérhetőek többek között az ftp.fsn.hu alól is. Célszerű újraírható lemezre íratni az anyagot. Ekkor, ha biztonsági frissítések látnak napvilágot, gyorsan átírhatjuk a lemezeket és nem kell kidobni azokat.
Ha nincs szélessávú elérésünk, kérjünk meg valakit a Linux-os levelező listákról, hogy írjon nekünk CD-t megegyezés szerint. Általában anyagáron meg szokták írni a lemezeket.
(Ne felejtsük el, hogy az első kompakt lemezről indíthatjuk a telepítést, ha az adott gép BIOS-a támogatja ezt. Ha nem, akkor legalább 2-5 floppy-t készítenünk kell.)
Ha viszont nem akarunk a CD-kel vesződni és van szélessávú Internet-elérésünk (értsd: legalább 1-2 Mbit/sec), akkor nyugodtan telepíthetjük a rendszert ftp-n keresztül is. Elég csak a kernel és a “root” floppy image fájlokat letölteni, és azokat floppyra másolni. A kernel floppyhoz tartoznak a driver lemezek. Ezeken a kernel moduljai találhatóak. Továbbá az alaprendszer is lemezeken van, méghozzá 11 db-on. Ha 1.44-es floppy meghajtót használunk, akkor összesen 16 db lemezre lesz szükségünk az alaprendszer telepítéséhez. Ha az alaprendszert FTP, NFS vagy HTTP protokollokon keresztül is be tudjuk szerezni, akkor elég 5 db floppy (rescue, root, driver-1,2,3).
A telepítéshez szükséges fájlok a debian/dists/potato/main/disks-i386/current könyvtárban találhatóak. (A telepítő lemezek magyar nyelvű fordítása megtalálható az ftp://mlf.linux.rulez.org/pub/mirrors/debian-disks-hu címen. A fordítás még nem teljes, fejlesztés alatt áll. A hivatalos tükrökön az angol nyelvű változat lelhető fel.) Először érdemes letölteni a doc alkönyvtárban lévő dokumentációkat és átolvasgatni azokat. A doc/ch-hardware-req.en.html fájl fontos információkat tartalmaz a szükséges és támogatott hardver eszközökről, továbbá a telepítéshez használt kernel és modulok milyenségéről. Ha ezt elolvassuk, sok fejfájást spórolhatunk meg.
Az installációs folyamathoz négyféle lemezkészletet készítettek. Minden készlet hozzáférhető egyben (loadlin-es változat), 1.2Mb, 1.44Mb és 2.8Mb-os floppy méretben is. A floppy image fájlok a megfelelő image-méret alkönyvtárakban lettek elhelyezve.
- A standard, általános célú készlet egyben megtalálható a fenti könyvtárban. Ez méretben a legnagyobb, szinte minden modul le lett fordítva. Ha nem tudjuk, hogy mire lesz szükség, ezt érdemes használni. Előnye, hogy szinte mindennel működik, amit a Linux támogat, hátránya a nagy mérete.
- A compact változat sokkal kisebb, csak egy modul lemez tartozik hozzá. Természetesen kevesebb hardvert támogat. Előnyös olyan esetekben, ahol tudjuk, hogy mire számíthatunk, és a megfelelő vezérlők benne vannak ebben a csomagban. Ez a készlet az azonos nevű alkönyvtárakban található. Olvassuk el a README.txt fájlt bővebb információkért.
- Az idepci készlet olyan esetben használatos, amikor nincsenek SCSI-s eszközeink (merevlemez) és PCI buszos IDE vezérlős merevlemezre akarjuk telepíteni a rendszert.
- Az udma66 készletre akkor van szükségünk, ha a merevlemezünk ATA-66-os IDE vezérlőre van csatlakoztatva. (pl. HPT366)
Fontos kiemelni azt, hogy ha a gépen már van egy FAT típusú fájlrendszer, akkor elég letölteni a linux (kernel, 1Mb), drivers.tgz (modulok, 3.6Mb), base2_2.tgz (alaprendszer, 15Mb), loadlin.exe (kernel betöltő) fájlokat és a root floppy-t. Ezután az install.bat indításával indulhat a kernel betöltése és a telepítés merevlemezről.
Ha floppy-s módszert válasszuk (mert pl. szűz merevlemezre akarunk telepíteni), de nincs még kéznél linux rendszer, akkor a dosutils könyvtárban lévő programokat letöltve (loadlin, rawwrite) segíthetjük az image-ek floppy-ra írását.
Linux alatt a dd if=image of=/dev/fd0 bs=512; sync; paranccsal írhatunk ki egy floppy-t. Ekkor persze a rajta lévő dolgok törlődnek. Fontos, hogy hibamentes lemezeket használjunk, mert nem lesz ellenőrizve a lemez írás közben, és esetleg a telepítés közepén derül ki a hiba.
Az images-1.44 alkönyvtárban találhatjuk a root.bin, a rescue.bin, drivers-x.bin és a base-x.bin lemezeket 1.44Mb-os floppy meghajtóhoz. Ez a legelterjedtebb mostanában, a továbbiakban erre vonatkozik, amit írok.
1.2 A telepítés menete
Nézzük meg a telepítés konkrét lépéseit. Amikor már a kezünkben vannak a kész telepítő lemezek vagy CD-k, hangoljuk be a számítógép BIOS-át a nekünk legmegfelelőbb beállításra. Védjük le a Setup-ba való belépést jelszóval, a rendszerindítást viszont semmiképp se. Válasszuk ki indítási célként vagy a CD-ROM olvasót, vagy a lemezmeghajtót. A telepítés befejezése után ne felejtsük el ezt visszaállítani úgy, hogy az első indítható egység az a merevlemez legyen, amelyikre a rendszert telepítettük.
1.2.1 Indítás CD-ről vagy floppy-ról
Helyezzük be az indítható médiát és indítsuk el a számítógépet. Nemsokára ezt a képet láthatjuk: (a színeket a legtöbb képen megfordítottam az olvashatóság és a tinta kedvéért.)
2. kép - Üdvözlőkép
Nyomogassuk végig az F1..F10 billentyűket és olvassuk el az információkat. Ha valamely hardver eszköz vezérlőjének indulási paramétert kell átadnunk (pl. I/O bázis cím, megszakítás, stb.), akkor az tegyük meg. Általában a kernel mindent megtalál magától, és nem kell kézzel paraméterezni. Ha a hardver eszköz valamilyen nem hétköznapi I/O címen van, vagy a kernel modul / vezérlő nem ismeri fel magától, tájékozódjunk, hogy kell azt paraméterezni. Alább a SCSI kártyák minta paramétereit láthatjuk:
3. kép - Speciális indítási paraméterek
Az indításnak több lehetséges módozata van:
4. kép - Indítási metódusok
Ha minden jól megy, mi csak nyomjunk le az Enter billentyűt - ekkor elindul a kernel betöltése és a hardver felismerése. A kernel betöltése után a rendszer jelez, hogy tegyük be a root floppy-t. (CD esetén erre nincs szükség). Ha minden jól ment, akkor egy üdvözlő képernyő fogad minket. Itt csak nyomjunk Enter-t.
1.2.2 Szükséges alapbeállítások, partícionálás
Először válasszunk billentyűzetet. Én az “us” billentyűkiosztást ajánlom. (És persze angol billentyűzetet, hiszen ezt a gépet nem szövegszerkesztésre fogjuk használni.)
Mivel még nincs Linux-os fájlrendszer a merevlemezen, partícionálnunk kell azt a tervünk alapján.111
5. kép - Merevlemez partícionálás
Több lemez esetén ki kell választanunk azt, amelyiket fel akarjuk partícionálni. Jelen esetben ez a “hda” lesz. A következő képernyőkép figyelmeztet minket, hogy a LILO nem képes a régi merevlemezeken az 1023-as cilinder felett lévő részekről betölteni a kernelt. Nekünk ez itt nem számít, mert az első partíció a /boot lesz, így a kernel nem kerülhet azokra a területekre.112
Ha a lemez teljesen szűz, akkor egy kérdést kapunk, hogy új MBR táblát készíthet-e a rendszer. Természetesen válaszoljunk igennel. Ha a tábla esetleg hibás, akkor is ezt a képernyőt kaphatjuk. Esetünkben mindenképp töröljük az egész táblát, hiszen nem lesz más operációs rendszer a gépen. A cfdisk program segítségével feloszthatjuk a merevlemezt. Ez egy elég könnyen használható és elég egyértelmű program (Bár én a mai napig jobban szeretem a fapados fdisk programot. Elszántaknak ezt az utóbbit ajánlom.)
6. kép - A cfdisk program
(A fenti ábrán lévő méret-adatok irreálisak, mert ez egy virtuális gépen belüli telepítést mutat egy 280 MB-os lemezre.)
Hozzunk létre 3 db “primary” és 5 db “logical” szeletet (=partíciót) a “New” menüpontra lépve. A méreteket az eredeti terv arányai szerint válasszuk meg. A “hda2” szeletnél álljunk rá a “Type” menüpontra és válasszuk ki a 82-es kódot (Linuxswap). Amint minden kész, nyomjuk meg a “Write” menüpontot. Ekkor válaszoljunk “yes”-szel, igen tényleg ki akarjuk írni a táblát.
A következő lépés a swap partíció inicializálása. Válasszuk ki a megfelelő (esetünkben “hda2”) partíciót. A szeletről minden adat törlődik.
Most a szeletek formázása következik ext2fs fájlrendszerrel. Először a “hda3” részt válasszuk. Ne kérjünk 2.0-s kernel kompatibilitást, hiszen nem lesz rá szükségünk. A szeleten minden adat törlődik. A telepítő megkérdezi, hogy ez-e a gyökérnek szánt rész. Válaszoljunk igennel. Ezután sorra formázzuk meg a többi partíciót is hasonlóképpen. Amikor a partíció felfűzési pontjáról kérdez, jelöljük ki a helyes választ a tervünknek megfelelően. Ha a listában nem szerepel a pont, az “other” menüpontban megadhatjuk kézzel.
1.2.3 A hálózat beállításaí
Ha ezzel készen vagyunk, telepíthetjük a kernelt és a modulokat a gépre. Válasszuk ki a floppy-t (vagy a CD-t) forrásmédiumként. Itt még nem lehet hálózatról telepíteni sajnos, mert még nincsen a hálózati kártya vezérlője betöltve, ami a floppy-n van.
Ha a floppy-t választottuk, tegyük be a “rescue” lemezt. A tartalma felmásolódik a gépre. Ha ez kész, a telepítő bekéri egymás után a három “driver” lemezt, mely a kernel moduljait tartalmazza.
7. kép - Modulok kiválasztása és betöltése a modconf programmal
Ami a hálózat működéséhez feltétlenül szükséges, azt keressük meg és töltsük be. (Pl. hálókártya vezérlő modulja) A “cdrom, fs, ipv4, ipv6, video” menüpontokban ne is keresgéljünk, szerverünkhöz szükséges vezérlők itt úgyse lesznek. Ha SCSI-s merevlemezünk van, akkor azt már eddig úgyis fel kellett ismernie a kernelnek. A telepítéshez nem szükséges speciális eszközeinket pedig később is megkereshetjük a modconf program futtatásával.
Válasszuk ki tehát a “net” menüpontot. Itt keressük ki a hálókártyánknak megfelelő vezérlőt. Megkérdezi, hogy biztosan be akarjuk-e tölteni. “Igen”. Ezután - ha szükség van rá - paramétereket is adhatunk a moduloknak, mint pl. I/O bázis cím. Általában a legtöbb modul megtalálja az eszközt a szabványos címeken keresgélve. Ha a hálókártya ISA-PnP-s, akkor lehetőleg vegyük ki PnP-ből és “jumper”-oljuk fel egy adott megszakításra, különben a Linux nem ismeri fel egykönnyen.113
8. kép - Hálózati modulok tallózása
Ha a következő üzenetet kapjuk: “Installation succeeded”, akkor minden rendben, sikerült. Ha “…failed” a szöveg vége, akkor próbálkozzunk mással, vagy másik báziscímmel, megszakításokkal.
Ha már nincs más betölteni való eszközvezérlőnk, lépjünk ki a modconf-ból és válasszuk a Hálózat beállítása menüpontot. Elsőként adjuk meg a szerver nevét. Ezt mindenki saját fantáziájára bízom. Legyen minél ötletesebb és ritkább (pl. egy szép női név). Én a példa számára az egyszerűség kedvéért az “alfa” nevet választottam.
Ha esetleg több hálókártya is lenne a gépben, akkor ebben a lépésben ki kell választani, hogy melyiket konfiguráljuk. Legyen az eth0 eszköz.
Most az IP cím megállapításának módja következik. A telepítő felajánlja, hogy DHCP, vagy BOOTP protokoll segítségével szerez egy dinamikus IP címet. Nekünk ez nem jó, hiszen Web-szerverünknek statikus IP címe van. “Nem” a válasz. A következő kérdésre adjuk meg a statikus IP címünket, a hozzá tartozó hálózati maszk értékét, és az (Internet felé) átjáró IP címét. Ezek után a megvásárolt domén-nevet írjuk be. Esetünkben ez boresszormegyar.hu. A következő lépés a névkiszolgálók IP címeinek megadása. Adjuk meg az elsődleges és másodlagos név-szerverek címeit szóközökkel elválasztva.
1.2.4 Alaprendszer telepítése, újraindítás a merevlemezről
Egy telepítési médiumot kell kiválasztani. Ha CD-lemezeink vannak, akkor semmi probléma, indulhat az alaprendszer telepítése. Nyomjunk párszor Enter-t. Az alapbeállítások célravezetőek.
Floppy esetén, ha az alaprendszert is hálózatról akarjuk letölteni (miért is ne?), akkor válasszuk ki a hálózatot. Ha valahol a Debian tükör ki van exportálva NFS segítségével, akkor azt is használhatjuk. Alapállásban egy HTTP címről szeretné letölteni az alaprendszert, mely messze Amerikában található. Szerencsére a http://ftp.fsn.hu/ftp:80 alatt találunk megfelelő magyar tükröt. Írjuk be ezt a cím helyett. Ha az alaprendszert is kiírtuk floppy-ra, és nem akarunk / tudunk hálózati telepítést, akkor egyenként tegyük be a lemezeket.
Miután az alaprendszert sikerült telepíteni, a rendszer beállítása következik. Itt meg kell adni az időzónánkat. Válasszuk ki a CET-et (Central European Time). Ekkor kérdést kapunk a hardver óra felől. Mivel csak ez a rendszer lesz a gépen, állítsuk a gépidőt a GMT-hez. (Ez a 0-s időzóna).
A gép merevlemezének indíthatóvá tétele a következő feladat. A LILO-t tegyük az MBR114-be, vagyis válasszuk az első lehetőséget. Ha van még egy üres floppy-nk, akkor készíthetünk egy boot-floppy-t. Mivel a rescue floppy segítségével is be tudunk jutni a rendszerbe, ezt elhagyhatjuk.
Vegyük ki a telepítő médiumot a meghajtóból, nehogy az induljon el a merevlemez helyett! A felmerülő “tényleg mehet-e az újraindítás” kérdésre ezután válaszoljunk igennel.
1.2.5 A jelszórendszer beállítása. (“MD5”, “Shadow password”)
Miután a rendszerünk felállt, megkérdezi a telepítő, hogy akarunk-e MD5-ös jelszókódolást. Természetesen akarunk, hiszen ekkor maximum 8 karakter helyett maximum 127 karakteres jelszókat is használhatunk, ami nagyban növeli a biztonságot. Ezután válaszoljunk szintén igennel, akarunk árnyék-jelszófájlt (shadow), ez is közelebb visz a biztonsághoz.
A következő lépés a rendszergazdai (root) jelszó megadása. Mostanra már ezt is kitaláltuk a tervünk szerint.115 Írjuk be kétszer.
Hozzunk létre legalább egy felhasználót, méghozzá a rendszergazdáét, az “rgazda” nevűt. (A telepítő segítségével.) Adjuk meg a nevet, a valódi nevet és kétszer a jelszót.
Most a telepítő észrevette, hogy a PCMCIA modulokat nem is használjuk, nincs ilyen eszköz a gépben. Bátran távolíttassuk el vele.
1.2.6 Az “apt” program beállítása
A következő lépés az apt program letöltési forrásának beállítása. Itt kell megadnunk, hogy a Debian tükör (a CD is annak számít valamilyen mértékben) hol található. Innen fogja leszedni a csomaglistát. Ezután kezdhetünk csak neki a csomagok kiválasztásának. CD-s telepítés esetén válasszuk ki a “cdrom” menüpontot és az alapértelmezett beállítások kiválasztásával biztosan sikerrel járunk. Floppy-s telepítés esetén válasszuk az “ftp” menüpontot.
9. kép - Az APT program beállítása
Ekkor kérdést kapunk: akarunk-e a non-US tükrökről származó (vagyis kriptográfiát tartalmazó) programokat használni. Mivel a szervergép nem az USA-ban helyezkedik el, válaszoljunk “Igen”-nel. A következő kérdés a non-free, majd a contrib szekciókra vonatkozik.116 Itt is válaszoljunk igennel.
Ekkor a Debian tükrök listáját kínálja fel. Először válasszuk ki Magyarországot (Hungary), aztán a hozzánk sávszélességben közelebb eső szervert. Én az ftp.hu.debian.org-ot választom.
Biztos, ami biztos, a legjobb, ha az apt-t saját kézzel konfiguráljuk, ugyanis ekkor megadhatjuk a biztonsági frissítéseket tartalmazó könyvtárat is. Válasszuk ki az “Edit sources by hand” menüpontot. Ekkor egy egyszerű és jól használható szövegszerkesztő jön elő (ae). Módosítsuk a rendszert a következőképp:
deb ftp://ftp.hu.debian.org/debian potato main contrib non-free
deb ftp://ftp.hu.debian.org/debian-non-US non-US/main non-US/contrib non-US/non-free
deb ftp://ftp.hu.debian.org/debian dists/potato-proposed-updates/
Az első sorban a “fő” debian szervert jelöljük meg, melyen nincsenek kriptográfiát tartalmazó programok. Itt három részre oszlik a rendszer: a fő, a nem-szabad és a nem szabadhoz kapcsolódó programokra. A második sorban ugyanez igaz, de a titkosítást tartalmazó programokra. A harmadik sor a biztonsági frissítések külön könyvtára.
A sorok jelentése: csomag protokoll://szervernév/tükörgyökér változat szekciók
- csomag: deb: bináris csomag, vagyis a .deb fájlok kellenek (forráskód esetén “deb-src”)
- protokoll: lehet “ftp”,“file”118 vagy “http”
- szervernév: a tükör helye, domén-név, vagy IP cím
- tükörgyökér: az adott szerveren belül hol kezdődik a tükör (melyik alkönyvtárban)
- változat: lehet “stable” “unstable” “frozen”. Ez mind a három egy-egy szimbolikus kötés (link) az adott állapotban lévő változathoz. Az írás pillanatában a Potato még “frozen” állapotban van119, ezért inkább direkt módon határozom meg annak a helyét.
- szekciók: a használni kívánt szekciók egymástól üres közzel elválasztva.
Mentsük el a változtatásokat (a képernyő tetején segítség olvasható, a “^” jel a Control billentyűt jelenti.) Ekkor az apt-get program letölti a csomaglistát a szerverről. Ha ez sikerült mehetünk tovább. Ha nem, akkor szerkesszük át a forráslistát.
Most azt kell eldönteni, hogy a csomagokat egyenként (advanced) válogatjuk ki, vagy egy előre elkészített összeállítást használjunk. Én az egyenkénti kiválasztást javaslom. Igaz ez sokáig eltarthat, de így pontosan meg tudjuk határozni, hogy mi kell és mi nem. A türelmetlenek válasszák ki a Web-server pontot. Ekkor egy általános csomaglista alapján kerülnek telepítésre, ami eléggé különbözik az általam felsoroltaktól.
Később
- az apt-get update paranccsal frissíthetjük a csomaglistát,
- az apt-get upgrade paranccsal frissíthetjük a csomagokat,
- az apt-get dselect-upgrade paranccsal a dselect által kiválasztott új csomagokat is telepíthetjük,
- az apt-get install csomagnév paranccsal letölthetünk és telepíthetünk egy csomagot
- az apt-get remove csomagnév paranccsal eltávolíthatunk csomagokat
- és még sok mást is tehetünk, ha elolvastuk a dokumentációt.
1.2.7 A “dselect” program
A dselect program használata igen egyszerű és egyértelmű, ha az ember már ismeri. Más rendszerekhez szokott embernek ez először nagyon ijesztő lehet, mert ez egy igazi UN*X-os szemléletű program. Először is olvassuk el a súgóját, hogy mit hogyan kell csinálni, mert különben nem megyünk semmire. (A súgó a 2. menüpont alatt érhető el.)
10. kép - dselect - Főmenü
A főmenü 7 pontból áll.
- 0. Access: ki tudjuk választani, hogy milyen médiáról telepítjük a csomagokat. Ez a módszer lehet most apt, floppy és nfs. (CD esetében cdrom, multicd is), továbbá később lehet http, ftp is. Mivel az apt már be van állítva, ezzel ne is foglalkozzunk.
- 1. Update: itt indíthatjuk a csomaglista frissítését. Esetünkben ez az apt-get update parancsnak felel meg.
- 2. Select: Ez az egész program szíve-lelke. A csomaglistában tallózhatunk, és a kívánt csomagokat kijelölhetjük telepítésre, megtartásra, törlésre, vagy teljes törlésre.120 Részletesen később.
- 3. Install: Ezzel indíthatjuk a csomagok letöltését (Internet esetén) vagy bemásolását (CD esetén). Miután a csomag a rendszerbe került, ki lesz csomagolva, majd be lesz állítva. Bizonyos csomagok interaktivitást igényelnek a rendszergazdától beállítás közben.
- 4. Config: Ha egy csomagot az előző menetben nem tudott a rendszer beállítani, de már ki lett bontva, akkor itt újra próbálkozhatunk.
- 5. Remove: A törlésre jelölt csomagok eltávolítását itt lehet elindítani.
- 6. Quit: A dselect programból való kilépés.
Belépve a “Select” menübe egy üdvözlő képernyőt kapunk, mely tájékoztat a program használatáról. Ezt itt olvassuk végig. Nyomjuk meg a “?” gombot, majd a “k” betűt. Ekkor az összes felhasználható funkció és a hozzá tartozó billentyű fel lesz sorolva.
11. kép - dselect - Súgó
Navigálni a csomagok között a kurzorgombokkal lehet. Ha egy csomagot telepíteni akarunk, jelöljük meg a “+” gombbal. Ha törölni akarjuk, akkor jelöljük meg a “-” gombbal. Ha azt akarjuk, hogy a csomaghoz tartozó konfigurációs fájlok is törlődjenek, akkor jelöljük meg a “_” gombbal. Ha azt akarjuk, hogy a csomag ne frissüljön, akkor jelöljük meg a “=” gombbal. Ha később mégis azt szeretnénk, hogy frissüljön a csomag, jelöljük meg a “:” gombbal.
A csomagokat többféle szempont szerint is sorba lehet rendezni. Nyomjuk meg az “o” gombot egyszer, az “O”-t pedig kétszer. Ekkor szekció szerint fogjuk rendezni a csomagokat. Véleményem szerint telepítéskor ez a legjobb sorrend, karbantartáskor viszont csak egyszer nyomjuk meg az “O”-t (ekkor aszerint is rendezi, hogy az adott csomag telepítve van-e már vagy nincs).
A csomaglistából az Enter leütésével lehet kilépni, ezt eleinte nehéz megszokni. “Q”-val felülbírálhatjuk a csomagfüggőségeket. Esc-el pedig a változtatások elhagyásával léphetünk ki.
A csomagnevek között keresni a “/” gomb lenyomásával lehet. Ha ezt a nevet akarjuk továbbra is kerestetni, akkor a “\” gombbal megtehetjük.
A súgóból a Space billentyűvel léphetünk ki. Először lehet, hogy nem érthető mi az a három “*” vagy három “-“ egymás mellett. Nyomjuk meg a “v” betűt és rögtön megértjük.
A csomagok kiválasztása
Miután beléptünk a csomaglistába először is nyomjuk meg az “o”-t majd kétszer az “O”-t. Ezután a “/” gombot leütve keressük meg egyenként a következő csomagokat és jelöljük meg őket telepítésre a “+” gombbal. Ha egy csomag egy másiktól függ, egy új képernyő fog megjelenni. Ettől ne ijedjünk meg. Ha valami függ egy másiktól (depends), akkor a program automatikusan megjelöli és megkér minket, hogy fogadjuk el ezt a beállítást. Ha mégse tetszene a függés okozta változás, akkor nyomjuk meg az “R” gombot. Ha megfelel így is, akkor nyomjunk Enter-t. Ha csak javasolja a csomag egy másik csomag telepítését is (recommends, suggests), akkor ő nem jelöli meg, a döntést teljesen ránk bízza. Javaslatom, hogy tartsuk magunkat a következő listákhoz.
“+”: cruft, debconf, logcheck, vlock, members, memstat, quota, slay, suidmanager, syslog-ng, syslog-summary, systune, tmpreaper, whowatch, hdparm, watchdog, slocate, kernel-image-2.2.16, dpkg-mountable, dpkg-multicd, doc-base, manpages-hu, joe, postfix-tls, libssl09, openssl, screen, ud, ippl, snort, traceroute, tripwire, mysql-client, mysql-server, apache-ssl, apache-common, ssh, cracklib-runtime, cracklib2, wipe, analog, php3, php3-mysql, webalizer, wget
12. kép - dselect - Csomaglista
A következő csomagok rövid összefoglalóját olvassuk el, és igény / hardver konfiguráció szerint válasszuk ki azokat telepítésre, melyek számunkra szükségesek, vagy hasznosak. Semmiképp se válasszuk ki mindet, mert több olyan csomag is van, melyek hasonló, vagy ugyanazon funkciót töltik be121, továbbá egyes csomagok csak speciális hardverelemek esetében szükségesek.
esetleg “+”: anacron, linuxconf, mon, makepasswd, pwgen, raidtools, raidtools2, sudo, alien, apcd, autolog, bpowerd, ext2resize, mtx, genpower, powstatd, timeoutd, upsd, apache-doc, debian-guide, dhelp, doc-rfc, dpkg-www, dwww, info2www, sysadmin-guide, ftape-doc, grep-mail, pkg-order, eject, ncftp, netcat, linuxlogo, lm-sensors, bing, echoping, fping, fwctl, icmpinfo, netmask, netselect, ntop, queso, lshell, rdate, tcpdump, nstreams, asp, mason, netdig, nmap, , libapache-mod-auth-pam, wdsetup, idled, doc-html-w3, nwm, cronolog, ldp-nag, mysql-doc, tdlug, wdg-html-ref, lasg, bigbrother, gnupg, lynx-ssl, zip-crypt, unzip-crypt, powstatd-crypt, cdrecord, mkisofs, afbackup, afbackup-client, amanda-*, apcupsd, bzip2, dlocate, dump, hwtools, kbackup-*, knl, ltrace, mc, mc-common, parted, setcd, sformat, symlinks, sysutils, taper, tob, tree, vfu, yard, fonty, ftape-util, set6x86, statserial, weblint, zope-*, wml, linbot, www-mysql
A következő csomagokat pedig jelöljük ki eltávolításra (“_”), vagyis - most még nem-telepítésre. A zárójelben lévő csomagokat én törlésre ajánlom, viszont mások esetleg hasznosnak találhatják, ezért tessék elolvasni a hozzájuk tartozó információt és igény szerint választani.
“_”: bison, flex, dpkg-perl, tetex-bin, bin86, gcc, fbset, (elvis-tiny), ppp, pppconfig, g++, libstdc++-210-dev, (isapnptools), pump, (fdutils), xviddetect, tetex-base, gdb, libc6-dev, make, dpkg-dev, rcs, manpages-dev, (nvi), emacs20, emacs-common, (perl-5.005-doc), (perl-5.005-suid), m4, libindent, exim, libopenldap1, libopenldap-runtime, libpcre2, liblockfile1, libpng2, tetex-lib, dialog, (mutt), (procmail), dc, bc, gpm, fingerd, lpr, nfs-common, nfs-kernel-server, pidentd, talk, talkd, telnetd
Ha ezekkel végeztünk, nyomjunk Enter-t és ekkor kikerülünk a főmenübe.
Indítsuk el az “Install” menüpontot. Ez a parancs megfelel az apt-get dselect-upgrade parancsnak. Az én konfigurációm esetében mindössze 35 MB-nyi csomagot kell letölteni. Kibontás után kb. 55 MB helyet foglal a rendszeren.
1.2.8 A feltelepített programok konfigurálása
Miután az összes kért csomag lejött a tükörről, a rendszer megkérdi, hogy a programokat milyen felületen szeretnénk beállítani. A választási lehetőségek a következőek: Dialog (dialógus ablakok), Text (hagyományos, egyszerű szöveges felület), Web (böngészővel), Noninteractive (mindenből az alapbeállítást tárolja el, később kézzel beállíthatjuk, amit akarunk. Bár én legjobban a sima szöveges módot szeretem, a kezdők kedvéért a barátságosabb dialógusos módszert tárgyalom a következőkben.
debconf beállítása: A következő kérdés az, hogy milyen szintű kérdések alatti prioritású kérdésekkel nem akarunk foglalkozni: medium, critical, high, low. Válaszunk legyen “low”, tehát minden kérdést megválaszolunk. A következő kérdés arra vonatkozik, hogy az adott csomag kérdéseire adott válaszunkat megjegyezze-e és azt válaszolja automatikusan minden újabb frissítésnél. Most még válaszoljunk nemmel, hiszen lehet, hogy valamit elrontunk. A kérdés furfangos: megmutassam-e újra és újra a régi kérdéseket: Igen. Később ezt javasolt Nem-re változtatni a dpkg-reconfig debconf parancs segítségével.122
A csomagok felépítésükben hasonlítanak a .tar.gz fájlokra, telepítő / eltávolító script-ekkel vannak ellátva, stb. Egy csomag telepítése két részből áll: először kibontja a csomagból a fájlokat, és a megfelelő helyre másolja őket (unpacking). A második szakaszban pedig beállítja a konfigurációs állományokat és futtatási jogot ad a futtatható fájloknak (setting up). Ha a beállításhoz szükség van a rendszergazda döntésére is, akkor megkérdezi.
A következőkben az én általam összeállított csomaglista beállító kérdéseit sorolom fel. Más lista (csomagok) esetén más kérdések lehetnek.
Az “unpacking” fázisban:
netbase:
- adjuk meg, hogy mely IP tartomány helyi: 127.0.0.1/8 (mivel igazi IP címünk van, nem adunk meg belső hálózati tartományokat.)
- adjuk meg mely hálózati interfészekkel rendelkezünk, pl.: eth0 eth1
logcheck:Engedélyezzük, hogy felülírja az /etc/cron.d/logcheck fájlt, ha ezt kéri.
mysql-server:
- figyelmeztet, hogy adjunk meg egy adatbázis rendszergazda felhasználót. Ezt majd később megtesszük.
- Megkérdezi, hogy ha a mysql-server teljes eltávolítását kérjük, akkor letörölje-e az adatbázisainkat is. Válaszoljunk nemmel.
snort: (portscan-detektor): adjuk meg azt az IP tartományt, ahonnan portscan támadásokat várunk. Mivel az interneten vagyunk, ez legyen a saját IP címünk/tartományunk. (Vagy az Internet Kijárat IP-je, stb.)
ssh: az ssh kliens kapjon-e SUID bitet. Semmiképp, mivel nem akarunk .rhosts azonosítást. Nem a válasz.
lilo: megkérdi, hogy az új LILO fájlok segítségével hozzon-e létre új indítót. Igen.
A következőkben számos csomag kerül kibontásra és telepítésre. Ezek nem igényelnek interaktivitást.
A következő kérdés az /etc/motd (Message of the day) cseréje. Y,I: igen, N,O: nem, D: megmutatja a kettő közötti különbséget, Z: majd később döntök. Válasszuk az Y-t. A csomagok telepítése folytatódik.
A “setting up” fázisban:
netbase:
- kikapcsoljuk-e az inetd.conf-ban a DoS veszélyes szolgáltatásokat? Igen.
- Az ipfwadm parancs legyen-e ipchains kompatibilis átjátszó? Igen.
- Akarunk-e IPv6-os címeket az /etc/hosts-ban. Nem.
apache-ssl:Az SSL szerverhez készül egy azonosító. A cégünkről kell adatokat megadnunk, hogy majd a kliens azonosíthassa szerverünket. Írjuk be az ország nevét (HU), a megye nevét (pl. Zala), a város nevét, a cég nevét, az eszköz titulusát: Web-szerver, majd végül a szerver nevét: www.boresszormegyar.hu, email címét (pl. info@boresszormegyar.hu.
postfix-tls:
- kérdést tesz fel, hogy a levéltovábbítás előtt az átmeneti fájlok olvashatóak legyenek-e a gépen fenn levő felhasználók által (gyorsabb út), vagy legyen egy külön felhasználó (postdrop) létrehozva, és ekkor csak a rendszergazda láthatja ezeket a fájlokat (lassabb, de biztonságosabb út). Válaszunk Igen.
- Adjuk meg a gépünk nevét: alfa.boresszormegyar.hu
- Elindítsa-e a levelező démont? Igen.
13. kép - a “snort” program beállítása
snort:
- Mikor induljon el a portscan detektor? “boot” vagyis induláskor.
- Melyik interfészen figyeljen? Amelyiken az Internetre vagyunk kapcsolódva. Nekem eth0.
- A hálókártya hallgatózó üzemmódját kikapcsolja-e? Igen.123
- A következő kérdésre Igen legyen a válasz, itt nem részletezem.
- Addicionális paraméterek: nyomjunk egy Enter-t.
- Ki kapja meg email-ben a napi statisztikákat: adjuk meg e-mail címünket.
- Itt is nyomjunk Enter-t
webalizer:
- hova tegye a kész statisztikákat? Ha ki akarjuk tenni a Web-re, akkor nyomjunk Enter-t (nem ajánlott). Adjunk meg neki egy nem nyilvános könyvtárat.
- Melyik gépnek nézzük meg a statisztikáit? Adjuk meg az egyik virtuális Web-szerverünk nevét.
php3: elindítsam az apache-ssl beállítóját, hogy a modult betöltse? Igen.
apache-ssl: ki a Web-szerver rendszergazdája (e-mail). Az alapértelmezés jó lesz, lásd későbbiekben.
- Mi legyen a nyilvános neve a Web-szervernek? www.boresszormegyar.hu
- megkeresi a dinamikusan betölthető modulokat. Ezekeket majd később beállítjuk kézzel. Elmentsem a beállításokat? Igen.
- Újraindítsam az Apache-ot? Igen.
lshell: (korlátozott shell, az átlagfelhasználók jogait tudjuk vele korlátozni belső DoS támadások kivédésre) A kérdésre válaszoljunk Igennel. Figyelem! Azoknak a felhasználóknak, melyeknek sok erőforrást biztosítunk, adjuk vissza később a /bin/bash rendes shell-t az /etc/passwd fájlban!
lynx-ssl: adjuk meg kezdőoldalnak a saját gépünket.
tripwire: (fájl integritás auditáló program) kinek küldje el a rendszeren észlelt változásokat? Adjuk meg a gyakran olvasott e-mail címünket.
watchdog: (hasznos őrszem DoS ellen): elindítsa-e minden induláskor a démonját? Igen. És most? Igen.
2. Finomítás
Természetesen az eddig elvégzettek finomhangolásra szorulnak. Egy rendszer akkor van készen, ha optimalizáltuk az adott hardverhez és az adott igényeinkhez. A finomítás elég időigényes is lehet, de hosszú távon megéri. A finomhangolás legfőbb célja a sebesség és a biztonság fokozása. Persze a kényelem se az utolsó szempont. (Ez alatt nem a biztonság hiányát, vagy háttérbeszorítását értem. Hiszen maga a biztonság is kényelmet nyújt.)
Kezdetnek - a következő lépések magyarázatára - elolvashatjuk ezt a cikket [21].
2.1 Első lépések
- Első lépésként tegyük a /root könyvtárat olvashatatlanná mások számára: chmod o-xr /root Tegyük meg ezt továbbá minden felhasználói könyvtárral is, hogy a felhasználók egymás személyes anyagába ne nézhessenek bele: chmod o-xr /home/* 124
- Állítsuk be a TCP SYN-flood elleni védekezést125: szerkesszük meg az /etc/network/options fájlt és írjuk be ezt a sort: syncookies=yes, továbbá egy ilyen sornak is szerepelnie kell: spoofprotect=yes126 Ezután állítsuk le, majd indítsuk újra a hálózati interfészt: /etc/init.d/networking stop; /etc/init.d/networking start
- Változtassuk meg az /etc/default/rcS fájl utolsó sorát FSCKFIX=no -ról yes-re. Ezzel elérjük, hogy ha a rendszer hibásan állna le és az fsck program beindul, annak minden kérdésére válaszoljon yes-el a rendszer, különben rendszergazdai beavatkozásra lenne szükség a helyszínen. (Vagyis minden felmerülő hibát automatikusan kijavít.)
- Készítsük el a következő ipchains táblát, pl. a /root/szabalyok.sh fájlba:
#!/bin/sh
MYIP=”sajátIP”
# IPChains szabályok
# Az alapártelmezett viselkedés tiltó (-P = Policy)
ipchains -P input DENY
ipchains -P output DENY
ipchains -P forward DENY
# Kitöröljük az előző szabályokat (-F = Flush)
ipchains -F
# Befelé jövő kérések (-A = Add, -p procotol, -i interface, -s source, -d destination)
# Ezeken a portokon lehet kérni szolgáltatást
ipchains -A input -p tcp -i eth0 -j ACCEPT -s 0.0.0.0/0 -d $MYIP 80
# a többihez nem írom oda a -s 0.0.0.0/0 (bárhonnan)-t mert ez az alapértelmezés
ipchains -A input -p tcp -i eth0 -j ACCEPT -d $MYIP 443
ipchains -A input -p tcp -i eth0 -j ACCEPT -d $MYIP 22
ipchains -A input -p tcp -i eth0 -j ACCEPT -d $MYIP 25
# Ahhoz, hogy a belső gépről is tudjunk kapcsolódni kifelé, szükség van egy
# befelé jövő kapcsolati portra is. Mivel ez tetszőleges lehet, ezért tiltsunk
# le minden olyan csomagot, mely kapcsolódni próbálna a portjainkra (-y = SYN flag)
ipchains -A input -p tcp -y -i eth0 -j REJECT -d $MYIP
# itt viszont megnyitunk minden portot (ACK, FIN, ACK+SYN flag-es csomagok jöhetnek)
ipchains -A input -p tcp -i eth0 -j ACCEPT -s 0.0.0.0/0 -d $MYIP
#Megendedunk néhany ICMP típust a helyes működés érdekében
# A “nagyok” javaslata alapján ezeket szabad beengedni:
# echo-reply (echo-request) time-exceeded destination-unreachable source-quench
# (a következőket egyenként egy sorba kell írni)
ipchains -A input -p icmp -i eth0 -j ACCEPT -d $MYIP --icmp-type echo-reply
ipchains -A input -p icmp -i eth0 -j ACCEPT -d $MYIP --icmp-type echo-request
ipchains -A input -p icmp -i eth0 -j ACCEPT -d $MYIP --icmp-type time-exceeded
ipchains -A input -p icmp -i eth0 -j ACCEPT -d $MYIP --icmp-type destination-unreachable
ipchains -A input -p icmp -i eth0 -j ACCEPT -d $MYIP --icmp-type source-quench
# a localhost-nak megengedhetjuk a működést az lo interfészen
ipchains -A input -p all -i lo -j ACCEPT -s 127.0.0.0/8 -d 127.0.0.0/8
ipchains -A output -p all -i lo -j ACCEPT -s 127.0.0.0/8 -d 127.0.0.0/8
# viszont meg kell tiltanunk azt, hogy valaki a 127.0.0.0-s tartományból
# küldjön csomagot a nem-hurok interfészeken:
ipchains -A input -j DENY -l -s 127.0.0.0/8 -i ! lo
# a kifelé mehet minden, tcp, udp, icmp, stb.
ipchains -A output -p all -i eth0 -j ACCEPT -s $MYIP -d 0.0.0.0/0
A fenti lista feltételezi, hogy csak egy Ethernet interfészünk és egy IP címünk van. Több hálózati kártya és IP cím esetén értelemszerűen módosítsuk, vagy egészítsük ki a listát. Ha nem gépeltünk el semmit, és a teszt is működőképesnek mutatja a rendszert, akkor szerkesszük meg. Ha kész, futtassuk le a fájlt: sh /root/szabalyok.sh majd tároltassuk el a beállításokat az ipchains-save > /etc/default/ipchains.rules paranccsal. A szerver leállása esetén ezt a listát induláskor újra be kell tölteni. Lényeges, hogy a lista még a hálózati interfészek felhúzása előtt töltődjön be. Ezt megtehetjük úgy is, hogy átszerkesztjük a networking script-et, vagy írunk egy egyszerű indító script-et /etc/init.d/ipchains-rules.sh néven.
#!/bin/sh
echo “Restoring IPChains rules…”
/sbin/ipchains-restore < /etc/default/ipchains.rules
Tegyük a fájlt futtathatóvá: chmod a+x /etc/init.d/ipchains-rules.sh Hogy induláskor ez el is induljon, egy szimbolikus linket kell elhelyeznünk az /etc/rcS.d könyvtárban:
ln -s /etc/init.d/ipchains-rules.sh /etc/rcS.d/S38ipchains-rules.sh
(Ugyanis a networking a 40-es számot viseli.)
- Szerkesszük meg az /etc/host.conf127 fájlt a következőképp:
order hosts,bind # mi a név-lekérdezés sorrendje
multi on # egy névhez az összes hozzá tartozó IP-t adja vissza
nospoof on # a DNS átejtést próbálja kiküszöbölni
spoofalert on # az átejtési kísérletet naplózza
- ippl: IP Protocol Logger, vagyis egy csomagforgalom naplózó. Később segítségünkre lehet betörés utáni nyomozásra. Olvassuk el a manuált128, szerkesszük meg az /etc/ippl.conf-ot, majd indítsuk újra a démont (/etc/init.d/ippl restart).
runas nobody # Milyen jogokkal fusson
noresolve all # nem kell DNS feloldás, mert lassít
# ident # nem kell ident kikeresés, mer ez is lassít
# Alapesetben a syslog()-on keresztül naplóz, de
#a három protokollt külön logfájlba is helyezhetjük
#log-in tcp /var/log/ippl/tcp.log
#log-in udp /var/log/ippl/udp.log
#log-in icmp /var/log/ippl/icmp.log
run icmp tcp # csak az icmp-t és a tcp-t naplózzuk
logformat normal all # a log bőeszédűsége: short / normal / detailed
ignore icmp type echo_reply # a ping csomagokat nem naplózzuk
log options ident,resolve tcp port 22 # az ssh-s kapcsolatokat lenyomozzuk
Ahhoz, hogy szét tudjuk válogatni az ippl üzeneteit, helyezzük el ezt a három sort az /etc/syslog-ng/syslog-ng.conf-ba, majd indítsuk újra a syslog-ng-t.
destination ippl { file(“/var/log/ippl.log”); }; # ide fognak kerülni az üzenetek
filter f_ippl { program(ippl); }; # ennek a szűrőnek a segítségével
log { source(src); filter(f_ippl); destination(ippl); };
- Ha szükség van rá, állítsunk be a kernelnek számunkra megfelelő értékeket a systune program segítségével (ha telepítve lett.) Szerkesszük meg az /etc/systune.conf fájlt.
# 2.2 és 2.4 kernelek beállításai
# az alapértelmezett egyszerre nyitott fájlok száma 4096
# Amennyiben TÉNYLEG szükség van rá a nagy forgalom és a sok fájl
# miatt, (olvassuk el először a dokumentációt!) az értéket megnövelhetjük így:
/proc/sys/fs/file-max:16384
# a következő paraméter hasonlóképpen szabályozza az inode számokat:
/proc/sys/fs/inode-max:16384 # eredetileg 8192
Ha változtattunk valamit a beállításokon, érvényesítsük ezeket:
/etc/init.d/systune restart
- Mentsük el floppy lemezre a partíciós táblát. Ez nagyon előnyös lehet később, ha esetleg valamilyen hiba miatt megsérülne az.
mount /floppy
dd if=/dev/hda of=/floppy/mbr.gépnév.dátum bs=512 count=1
Visszatölthetjük később ezzel a paranccsal:
dd if=/floppy/mbr.gépnév.dátum of=/dev/hda bs=1 count=64 skip=446 seek=446
- Készítsünk egy mysql rendszergazda129 jelszót, mely különbözzön a rendszergazdai jelszótól: mysqladmin -u root password új-jelszó
Ezután végezzük el a következőket:130
Ezzel elértük, hogy titkos jelszavat adtunk az adatbázis rendszergazdának és még a szerver is jól fog funkcionálni (különben induláskor és leálláskor is jelszót kérne, ami nem lenne jó, ha nem is vagyunk gépközelben). Ezt a jelszót adjuk át az adatbázis-rendszergazdának is, hogy egyáltalán tudjon valamit kezdeni a rendszerével és létrehozhassa a felhasználóit.
Ahhoz, hogy a mysql hibaüzeneti magyarul jelenjenek meg, keressük meg ezt a sort és módosítsuk az /etc/mysql/my.cnf fájlban
language=/usr/share/mysql/hungarian
Rengeteg apró trükk is számba jöhet, mely mind a kényelmünket szolgálja. Például sokkal használhatóbb a héj, ha a héj “kérdése” így néz ki: [webgazda@alfa:/usr/doc/]$ Ezt úgy érhetjük el, ha a saját .bashrc-nkbe ezt írjuk be: PS1='[\u@\h:\w]\$'
Egy minta .bashrc:
set meta-flag on # ezek a magyar bill. kezeléshez szükségesek
set convert-meta off
set output-meta on
PS1='[\u@\h:\w]\$' # ez állítja be a shell prompt-ot
#\u az felhasználó neve, \h a gépnév, \w pedig az aktuális könyvtár
export PS1 # ezzel pedig közzétesszük azt magunknak
umask 027 # állítsuk be az umask értékét
# ez annyit tesz, mint umask -S u=rwx,g=rx,o=
export LS_OPTIONS='--color=auto -h' # kellemes színeket kapunk az ls parancshoz
eval `dircolors`
alias ls='ls $LS_OPTIONS' # ezzel érvényesítjük
alias ll='ls $LS_OPTIONS -l' # legyen egy-két rövidebb parancs a hosszú
alias l='ls $LS_OPTIONS -lA' # paraméterezés helyett
HISTFILESIZE=0 # ez biztonsági okok miatt hasznos, ekkor nem
# olvasható el, hogy milyen parancsokat használtunk eddig
EDITOR=/usr/bin/joe # ha nem adjuk meg, az alap szövegszerkesztő a “vi”
Ha ezt az /etc/skel könyvtárban helyezzük el, akkor minden új létrehozott felhasználónak ez kerül be a könyvtárába.
Készítsünk egy /etc/environment fájlt a következő tartalommal: LANG=hu_HU
Ezután, amikor lehet, magyarul fognak megjelenni az üzenetek. Mivel ahhoz, hogy ez érvénybe lépjen, újra be kellene jelentkezni, ezért írjuk be ezt a parancssorba: export LANG=hu_HU.
Magyar ékezetes kiosztásra az angolról loadkeys hu paranccsal válthatunk. Értelemszerűen visszaváltani angolra a loadkeys us -el lehet. (Szükségünk lehet a fonty csomagra is.)
A hat konzol között ctrl-alt-F1..6 gombokkal válthatunk.
2.2 Az Inetd.conf finomhangolása - a nem biztonságos szolgáltatások letiltása
Az inetd program az Internetes Szuperszerver. Feladata az, hogy a ritkán használt és / vagy speciális szolgáltatásokat elindítsa, ha kívülről kérés érkezik valamelyik meghatározott portra. Mivel az Apache (és a többi itt futó szolgáltatás is) “Standalone”131 módban fut, ezért esetünkben nincs szükség az inetd munkájára.
Igazság szerint a jelen felállásban nincs szükség egyetlen szolgáltatásra sem azok közül, melyeket az inetd nyújt. Ezért az egész inetd programot letilthatjuk. Sajnos ez a program és a hozzá tartozó fájlok sok más jóval együtt a netbase csomagban vannak - így nem törölhetjük le őket a rendszerből. Amennyiben mégis szükségünk lenne néhány szolgáltatásra, mely az inetd-ből futna, használjunk egy profibb helyettesítő csomagot, mint amilyen pl. az xinetd, vagy rlinetd.
Előszöris állítsuk le az /etc/init.d/inetd stop paranccsal. Ezután szerkesszük át az /etc/inetd.conf fájlt úgy, hogy minden bejegyzés elé tegyünk egy “#” jelet. Erre azért van szükség, hogyha valaki el is indítaná az inetd programot, akkor se tudjon vele mit kezdeni. Ezután írjunk az /etc/init.d/inetd fájl első sorába egy “exit 0” sort. Ekkor a inicializáló script indítás helyett kilép. Az /etc/inetd.conf jogosultságait állítsuk a következőre: chmod u+r,u-w,a-wrx inetd.conf132. Ezek után biztos ami biztos alapon adjunk neki immutable bit-et: chattr +i inetd.conf. (Sőt, akár chmod a-x /usr/sbin/inetd, de ez könnyen kijátszható.)
Hogy a paranoia teljes legyen, állítsuk be a tcp_wrapper133 fájljait is: /etc/hosts.deny-ban kommentezzünk ki mindent és tegyük be az ALL:ALL és az ALL:PARANOID sorokat. Az első sor minden olyan címről érkező kérést megtagad, amelyik nincs benne a hosts.allow fájlban. A másik szabály az olyan gépekre vonatkozik, melyeknek az IP címe nem egyezik meg a nevük szerint a DNS-ből, vagy az /etc/hosts fájlból lehívott név-IP cím hozzárendelésnek.
A Standalone módban futó szervizeknek a saját konfigurációs állományaikban lehet meghatározni, hogy milyen tartományokat szolgáljanak ki és milyeneket nem. Ezekre az adott helyen kitérek.
A következő felesleges szolgáltatás a portmap. Ez a démon szolgáltatná a SUN féle RPC-k listáját134 (Remote Procedure Call, Távoli Eljárás Hívás). Mivel ezeket a szolgáltatásokat is az inetd indítja - és azt már megszüntettük - erre sincs szükség. Állítsuk le a szolgáltatást az /etc/init.d/portmap stop paranccsal, majd írjunk egy exit 0 sort az /etc/init.d/portmap script első sorába.
2.3 A levelező démon beállítása
A nagyfokú biztonságossága miatt a postfix csomagot választottam. Ezt az IBM-nél kezdték fejleszteni. Szerzője Wietse Venema, aki többek között a tcp_wrapper program írója is és biztonsági problémák megoldásán dolgozik. A Postfix-et már a tervezési fázisban a biztonságra hangolták. A program neve arra utal, hogy az elterjedt és viszonylag könnyen feltörhető sendmail program lecserélésével utólagos biztonsági foltozást kapunk. Mivel ez egy Web és nem egy levelező szerver lesz, nincs szükségünk a sendmail extra funkcióira. Nincs szükségünk a qmail gyorsaságára és teljesítményére sem. A Postfix ezért kitűnő választás.135
A Postfix a Potato-ban két változatban is megtalálható. A postfix csomag a standard programot tartalmazza, míg a postfix-tls csomag (mely a non-US szekcióban van) egy TLS (Transportation Layer Security, az RFC2246 szerint) bővítéssel rendelkezik. Ez az OpenSSL rendszerkönyvtárat használja. Az RFC2487136 leírja a TLS SMTP-be való integrálását. Ezek segítségével készítette el Lutz Jänicke a TLS bővítést a Postfix-hez. Segítségével a következők érhetők el, amennyiben mindkét gép, melyek között a kapcsolat folyik, ismeri ezt a protokollt:137
- Titkosított e-mail szállítás a gépek között
- A fogadó gép beazonosítása, hogy azonos-e azzal, akinek mondja magát.
- A küldő gép beazonosítása, levéltovábbítás céljából (relaying)
És amire nem képes:
- A felhasználók leveleinek biztonságát megőrizni - ez a titkosítás csak szállítási rétegre vonatkozik
- A küldő azonosítása
A fentiek eléréséhez használjunk gpg-t vagy pgp-t
Bár még nagyon kevés gépen van ilyen protokollt ismerő levelező démon138, mégis ajánlom ennek a használatát. Később egyre jobban el fog terjedni, és addig is legalább a saját szervereink legyenek nagyobb biztonságban.
Konfigurációs állományait az /etc/postfix könyvtárban találjuk. A fő beállításokat a main.cf fájl tartalmazza. Nyissuk meg kedvenc szerkesztőnkben és módosítsuk a következő sorokat:
myhostname = alfa.boresszormegyar.hu # a saját gépünk neve
mydomain = boresszormegyar.hu # mi a bejegyzett domén-nevünk
# myorigin = $mydomain # ha ez lenne a fő mail szerver, akkor ezt adnánk forráscímnek
# milyen gépeknek vagyunk a levelező szervere: ( “A” típusú DNS rekord kell)
mydestination = $myhostname, localhost.$mydomain, www.$mydomain
Ha szeretnénk a felhasználóknak Családnév.Keresztnév stílusú címzést is biztosítani, szúrjuk be a következő sort is:
canonical_maps = hash:/etc/postfix/canonical
Alapbeállításként ez a fájl a manuál oldal szövegét tartalmazza, ezért töröljük ki / le. Majd szerkesszük meg a hivatkozott fájlt a következőképp:139
# user Név.Név
rgazda Kis.Jozsef
webgazda Nagy.Istvan
abgazda Kovacs.Lajos
#stb.
Ha virtuális doméneket is akarunk használni, akkor szúrjuk be ezt a main.cf-be:
virtual_maps = hash:/etc/postfix/virtual
Ezután szerkesszük a hivatkozott fájlt:140
# ezeket a doméneket is bejegyeztük, ezért nekik is fogadjuk a leveleket.
borgyar.hu
szormegyar.hu
Ha kéretlen levelek szerverszintű szűrésére van szükségünk, olvassuk el a /usr/doc/postfix-tls/html/uce.html fájlt. Fontos, hogy ne használjunk “Open Relay”-t, vagyis ne továbbítsuk bárki leveleit átjátszóként, mert ekkor a spamer141-ek céltáblájává válhatunk, ráadásul bekerülünk az ORBS142-be, és akkor sok helyre levelet sem küldhetünk majd.
Mivel ez nem egy levelező szervernek lett szánva, limitáljuk az egyszerre futható levélküldések számát az /etc/postfix/master.cf-ben 50-ről pl. 10-re143:
# ==================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (50)
# ==================================================================
smtp inet n - n - 10 smtpd
Nyissuk meg az /etc/aliases144 fájlt is és módosítsuk így:
# a postamesternek szánt leveleket a rendszergazda kapja meg két helyre is
postmaster: rgazda@gyakranolvasom.hu root
# a webmesternek szánt leveleket ketten is megkaphatják
webmaster: rgazda@gyakranolvasom.hu webgazda, wgazda@gyakranolvassa.hu
# minden root-nak szánt levelet továbbítsunk
root: rgazda@gyakranolvasom.hu
info: titkarno
Indítsuk újra a levelező szervert : /etc/init.d/postfix restart
Ha valamit elgépeltünk a fájlokban, akkor most lehet, hogy nem fut a démon. Győződjünk meg erről így: ps aux | grep postfix Ekkor három programnak kell megjelennie: master, pickup, qmgr. Ha ezek láthatóak a sorok között, akkor minden rendben van.
A titkosítás beállítása
A következőkre van szükség a titkosításhoz:
- 1 db titkos kulcs a szerverhez
- 1 db nyilvános kulcs a szerverhez, melyet egy CA145 hitelesített (~digitálisan aláírt), mely azt bizonyítja, hogy cégünké az adott gépnév (és domén).
- 1 db CA igazolás a CA nyilvános kulcsával
El kell készítenünk tehát egy igazolást arról, hogy azok vagyunk, akik vagyunk (vagy vásárolhatunk egyet egy erre szakosodott cégtől, de ez még felesleges). A következő lépéseket kell megtenni:
- Megkeresünk egy segédprogramot és beállítjuk azt igényeinkhez.
- Legyártunk magunknak egy saját CA kulcsot, hogy CA-vá válhassunk.
- Legyártunk a levelező szerver számára egy szerver kulcsot.
- Ezt aláíratjuk a CA kulccsal.
- Bemásoljuk a fájlokat a helyükre.
- Megszerkesztjük a konfigurációs fájlt
- Újraindítjuk a levelezőt.
Részletesen:
- A dokumentáció146 elolvasása után keressük meg a következő fájlt: /usr/lib/ssl/misc/CA.pl Másoljuk át a /root könyvtárába és hívjuk be kedvenc szövegszerkesztőnkbe. Az alábbi minta alapján szerkesszük át a fájlt (csupán egy -nodes paramétert kell beírnunk két helyre147):
[…]
# create a certificate
system ("$REQ -new -x509 -nodes -keyout newreq.pem -out newreq.pem $DAYS");
$RET=$?;
print "Certificate (and private key) is in newreq.pem\n"
} elsif (/^-newreq$/) {
# create a certificate request
system ("$REQ -new -nodes -keyout newreq.pem -out newreq.pem $DAYS");
[…]
Erre azért van szükség, mert az indításkor nem szabad, hogy a kulcs fájl kódolt legyen, különben a postfix nem fogja tudni beolvasni. Keressük meg továbbá a $DAYS=’-days 365’ sort. Ennyi nap után jár le az igazolás, évente meg kell újítanunk saját magunknak. Sajnos nem jöttem rá, hogyan lehetne ezt működőképesen megnövelni.
- Most futtassuk ezt a programot: ./CA.pl -newca Ez a kis programocska legyártja nekünk a megfelelő igazolást (CA). Előszöris adjunk meg neki egy jelszót kétszer (erre később emlékeznünk kell!). Majd - az Apache-SSL-hez hasonlóan - töltsük ki itt is az azonosítói adatokat. Ekkor már mi vagyunk a saját azonosító-szolgáltatónk (CA).
- A következő lépésben futtassuk a ./CA.pl -newreq -t, és töltsük ki ezt is hasonlóképpen:
14. kép - Postfix - igazolás készítése a CA.pl programmal
A challenge password és optional company name mezőket üresen is hagyhatjuk. (Ezzel elkészítettünk egy igazolást).
- Ha ez kész, futtassuk le ezt: ./CA.pl -sign Írjuk be a jelszót, a felmerülő kérdésekre válaszoljunk Igen-nel. (Ezzel aláírtuk az igazolást.)
- Másoljuk be a fájlokat a helyükre:
cp /root/demoCA/cacert.pem /etc/postfix/CA.pem
cp /root/newcert.pem /etc/postfix/igazolas.pem
cp /root/newreq.pem /etc/postfix/privatkulcs.pem
- Szerkesszük meg a main.cf-et:
smtp_tls_key_file = /etc/postfix/privatkulcs.pem # a titkos kulcsunk
smtp_tls_cert_file = /etc/postfix/igazolas.pem # a nyilvános igazolás, kik vagyunk
smtp_tls_CAfile = /etc/postfix/CA.pem # a CA igazolása (ezt is mi csináltuk most)
smtpd_tls_key_file = /etc/postfix/privatkulcs.pem # a “d” re végződő paraméterek
smtpd_tls_cert_file = /etc/postfix/igazolas.pem # segítségével kliens is lehet
smtpd_tls_CAfile = /etc/postfix/CA.pem # a szerverünk és így is lehet azonosítani
A titkos kulcsot csak a rendszergazdának szabad látnia:
chown root /etc/postfix/privatkulcs.pem
chmod 400 /etc/postfix/privatkulcs.pem
- Indítsuk újra a levelezőt: /etc/init.d/postfix restart
Ha valamit elgépeltünk a fájlokban, akkor most lehet, hogy nem fut a démon. Győződjünk meg erről így: ps aux | grep postfix Ekkor három programnak kell megjelennie: master, pickup, qmgr. Ha ezek láthatóak a sorok között, akkor minden rendben van.
A többi alapbeállítás általában megfelelő minden esetre. Az egész programot már a tervezéskor úgy hangolták, hogy biztonságos legyen.
Ha minden jól ment, akkor a levelező szerverünk rendesen be lett állítva igényeinkhez. Mindenképp olvassuk végig a dokumentációt, amint van rá egy kis időnk. pl. lynx /usr/doc/postfix-tls/html/index.html
Linkek: http://www.postfix.org, http://www.aet.tu-cottbus.de/personen/jaenicke
2.3 Másik gép használata a fordításokhoz, miért?
Mivel éles szerveren biztonsági okokból nem tarthatunk semmilyen fejlesztő-eszközt, fordítót, stb., ezért nagyon ajánlott egy másik - rendszergazdai adminisztrációs gépet fenntartani. Ha fordítókat tartanánk a szerveren, bármelyik felhasználó - vagy épp a betörő forráskódból fordíthatna magának a gépen programokat. Ez kerülendő.
A szerveken üzembe helyezés után általában se billentyűzet (BIOS beállítás!), se egér, se monitor nem szokott lenni. A szervert mindig a hálózatról, egy másik gépről - a rendszergazda gépéről lehet menedzselni.
Jelöljünk ki (vagy vásároljunk) egy gépet a rendszergazda számára. Ez lehetőleg megfelelően jó tudású / teljesítményű gép legyen. Az se baj, ha ez egy megfelelő eszközökkel (hálózati kártya, modem) ellátott laptop. Ekkor a rendszergazda azt mindenhova magával viheti, és szükség esetén nála van minden fontos és kézreálló eszköz.
Továbbá ezen a gépen kell kipróbálni először az új programokat, kernelverziókat, hogy az éles rendszerekre már tesztelve, megismerten kerülhessenek fel az újítások.
Ez a gép legyen elzárva a hálózat többi részétől - lévén ez a rendszer nem éles, tehát nincsenek (ne legyenek) publikus szolgáltatásai, hiszen fejlesztői rendszer, ezért érzékeny lehet a támadásokra. Ez a rendszer mindig érzékeny adatokat és programokat tartalmazhat. Ezért nagyon körültekintőeknek kell lennünk. Ebből a rendszerből csak kifele lehessen látni, kintről befele ne.
2.4 Másik gép használata a fordításokhoz, miért?
Mivel éles szerveren biztonsági okokból nem tarthatunk semmilyen fejlesztő-eszközt, fordítót, stb., ezért nagyon ajánlott egy másik - rendszergazdai adminisztrációs gépet fenntartani. Ha fordítókat tartanánk a szerveren, bármelyik felhasználó - vagy épp a betörő forráskódból fordíthatna magának a gépen programokat. Ez kerülendő.
A szerveken üzembe helyezés után általában se billentyűzet (BIOS beállítás!), se egér, se monitor nem szokott lenni. A szervert mindig a hálózatról, egy másik gépről - a rendszergazda gépéről lehet menedzselni.
Jelöljünk ki (vagy vásároljunk) egy gépet a rendszergazda számára. Ez lehetőleg megfelelően jó tudású / teljesítményű gép legyen. Az se baj, ha ez egy megfelelő eszközökkel (hálózati kártya, modem) ellátott laptop. Ekkor a rendszergazda azt mindenhova magával viheti, és szükség esetén nála van minden fontos és kézreálló eszköz.
Továbbá ezen a gépen kell kipróbálni először az új programokat, kernelverziókat, hogy az éles rendszerekre már tesztelve, megismerten kerülhessenek fel az újítások.
Ez a gép legyen elzárva a hálózat többi részétől - lévén ez a rendszer nem éles, tehát nincsenek (ne legyenek) publikus szolgáltatásai, hiszen fejlesztői rendszer, ezért érzékeny lehet a támadásokra. Ez a rendszer mindig érzékeny adatokat és programokat tartalmazhat. Ezért nagyon körültekintőeknek kell lennünk. Ebből a rendszerből csak kifele lehessen látni, kintről befele ne.
2.5 Személyre szabott kernel konfigurálása és fordítása kézzel és a “kernel-package” csomaggal. A “lilo” beállításai.
Ez egy nagyon tág és mély témakör. II. Alapfogalmak / 2. A Linux kernel c. fejezetben már kitértem a kernel sajátosságaira, azokat itt nem szeretném elismételni. Szintén nem térhetek ki a különböző hardver eszközök kiválasztására és beállítására. Azokat a lényeges pontokat viszont megpróbálom érinteni, melyek a biztonság szempontjából fontosak, és / vagy mindenképp bele kell kerülnie a kernelbe.
A 2.2-es linux konfigurálásához van egy részletes magyar nyelvű útmutató, mely itt [7] található. Igaz ez már egy kicsit idejétmúlt, a 2.2.4-es kernelt taglalja, viszont 25 oldal terjedelmével elég kimerítő. Ez a link148 pedig a magyar nyelvű linux-kernel-HOGYAN-t fedi, igaz, ez is elég idejétmúlt már, viszont jó elméleti kiindulópont lehet.
Olvassuk végig először az eljárások menetét és csak utána kezdjünk hozzá a tényleges gyakorlati megvalósításhoz. Én a kernel-package csomag segítségével való fordítást ajánlom, de meg kell ismernünk a kézzel való fordítás menetét is.
Szerezzünk be egy kernel forráskódot, ha lehet, akkor pl. az apt-get install kernel-source-2.2.16 paranccsal. Ha ennél frissebb vagy speciálisabb forrást szeretnénk, akkor valamelyik kernel tükörről beszerezhetjük azt. Ha szükség van kernelszintű fájlrendszer-titkosításra, akkor a nemzetközi változat “foltját” is töltsük le. Továbbá szerezzünk be minden olyan forráskódot, amelyre az adott hardverhez szükségünk lehet, de még nincs benne a hivatalos kernelben (pl. alaplapi CPU hőmérőket és ventilátor fordulatszámmérőt kezelő programrész, az lm_sensors nevű folt.149). Ha megvan minden és a fordításhoz szükséges bináris csomagok is fenn vannak a gépen (gcc, binutils, make, libc6-dev, bin86, ha kell menuconfig: ncursesX.X-dev, make xconfig: tkX.X-dev, azok a csomagok, melyeket ezek igényelnek, gzip, grep, shellutils, stb.).
Ha i586, vagy i686 architektúrájú processzorral rendelkezünk a szervergépben, akkor a fejlesztői (rendszergazdai) gépre tegyük fel a pentium-builder csomagot. Segítségével a célgép processzorához tudjuk optimalizálni a kernel (és minden más lefordított C program) kódját, mely viszonylag nagy sebességnövekedést eredményezhet. Ha a program fent van, adjuk a következő parancsot: export DEBIAN_BUILDARCH=pentium (i686 esetén pedig pentiumpro). Ha nem akarjuk ezt minden fordítás előtt begépelni, tegyük be a ~/.bashrc fájlunkba. Ezután az összes C program kódja a kért processzorhoz lesz optimalizálva. Ekkor az ennél kisebb processzorokon az adott program / kernel nem fog futni (pl. i486).
A kész lefordított kernel a következő részekből áll:
fájl(ok) |
méret |
forma |
funkció |
arch/i386/boot/bzImage
modulok
./System.map,
./.config,
|
~600kb
1-2Mb
~300kb
~10kb
|
bináris
bináris
szöveges
szöveges
|
A rendszermag.
az induláshoz nem szükséges programrészek
A rendszerhívások listája
A kernel konfigurációja
|
9. táblázat - A kernel részei
A rendszermag elkészülte után le lesz tömörítve és a fenti könyvtárba lesz másolva. Minden olyan kódrészt, amely a rendszer indulásához nélkülözhetetlen bele kell fordítani a kernelbe és nem szabad modulba tenni (pl. ha IDE vezérlős lemezünk van és arról indul a rendszer, akkor az IDE vezérlő támogatást mindenképp fordítsuk be). Bizonyos kódrészeket egyáltalán nem is lehet modulba fordítani. A modulokat később pl. a modprobe vagy insmod paranccsal lehet betölteni, az rmmod-al kiszedni és az lsmod-al listázni (modutils csomag).
A System.map fájl a kernel rendszerhívásait és szimbólumait tartalmazza. Induláskor ezt a kernel (klogd) beolvassa. Ez megkönnyítheti a kernel üzeneteinek megértését, ugyanis ekkor emberi (angol) nyelven szól hozzánk.
A .config fájlt jó eltenni későbbre, hogyha egy kis változás miatt újra kell fordítani, akkor ne kelljen előröl kezdeni a “konfigolást”.
A kézzel való fordítás lépései:
- Csomagoljuk ki a kernelforrást, pl. az /usr/src könyvtár alá:
tar -xzvf linux-2.2.16.tar.gz; cd linux
- Ha kell, foltozzuk be a szükséges plusz kódokkal. Pl.:
cat folt.txt | patch -p1 -E -N -s -d /usr/src/linux
Ha úgy döntünk, alkalmazzuk az OpenWall-féle kódot, csomagoljuk ki:
tar -xzvf linux-2.2.16-ow1.tar.gz
Majd pedig foltozzunk:
cat linux-2.2.16-ow1/linux-2.2.16-ow1.diff | patch -p1 -E -N -s -d /usr/src/linux
Ha használni akarjuk a LIDS rendszert is, olvassuk el a függelékben lévő útmutatót.
- Mivel már tudjuk, hogy melyik hardver elemet milyen vezérlővel fogunk használni, ezért keressük elő ezt a jegyzetünket. Végezzük el a kernel konfigurálását. Ezt háromféleképpen is megtehetjük: make config, make menuconfig, make xconfig parancsokkal. Az első elég kényelmetlen, mert egyenként rákérdez minden egyes lehetőségre. A második már jó, ekkor egy színes, menüs, de még szöveges programocska fut, melyből kényelmesen kiválogathatjuk, hogy mi kell nekünk. Ehhez szükséges az ncurses-dev csomag, mivel ez a programocska is le kell, hogy forduljon és ncurses képernyőkezelő rutinokat használ. Kérésre angol nyelvű rövid leírást kapunk minden egyes opcióról.
15. kép - make menuconfig
A harmadik változat a legkényelmesebb, egy TCL/Tk függvénykönyvtárat használó grafikus X11 felületű beállító-programot kapunk.
16. kép - make xconfig
Akkor nézzük a fontosabb beállításokat. Én a make xconfig felületet használom. Mi az ami mindenképp benne kell, hogy legyen és mi az ami semmiképp se kell a konfigunkban:
- Code maturity level options / Prompt for development and/or incomplete code/drivers: a félkész/fejlesztés alatt lévő eszközvezérlők és funkciók megjelenítése választási lehetőségként. Kell.
- Processor type and features / Processor family: válasszuk ki, hogy milyen processzor van a gépünkben. Math emulation - ez semmiképp sem kell, ha van FPU150 a gépünkben. MTRR151 support: ha i686-os processzorunk van akkor ennek a használata gyorsítja a végrehajtást, kellhet. SMP support: ha egynél több processzor van a gépünkben, akkor kell.
- Loadable module support / Enable …: kell, hiszen szeretnénk modulokat használni. Kernel module loader: mindenképp kell - kernelszintű modul betöltő.
- General setup / Networking support: [y], hiszen épp hálózatra tesszük a gépet. Itt be lehet állítani a PCI buszt, ha van tegyük. A System V IPC, a BSD process Accounting, Sysctl support, kernel support for ELF bin., mindenképp kell. Ha akarjuk használni a párhuzamos portot, tegyük be, de ez is egy betörési lehetőség lehet a gépre, igaz helyi. Én javaslom az APM152 support kernelbe-fordítását és megfelelő beállítását (SMP módban nem megy). Egyrészt áramot és ezzel pénzt spórolhatunk meg, másrészt megnöveljük a szerver élettartamát, mivel kevesebbet “pörög” a gép processzora. Figyelem! A suspend funkciót tiltsuk le a BIOS-ban, csak a doze mode-ot engedélyezzük (esetleg a stand by módot is), mely - ha nincs szükség rá - leszabályozza a processzor frekvenciáját.153 A suspend funkció hatására a gép alvó-üzemmódra kapcsol és csak pl. a billentyűzet megnyomásával ébreszthető fel - ez szervereken nem előnyös. Ha a gép nagyon nagy forgalmat bonyolít, akkor az egész APM-et hagyjuk ki. Ha viszont keveset forgalmaz, akkor fontoljuk meg használatát. Javaslom továbbá az RTC GMT155-hez való állítását is.
- Plug and Play support: ha van ilyen kártya a gépben, akkor kapcsoljuk be.
- Block devices: válasszuk ki, milyen blokkos eszközöket (floppy, merevlemez) akarunk használni. Azt az eszközt, amiről a rendszer indul, fordítsuk kernelbe, a többi mehet modulba is. Ha nincs szükség rá, a floppy-t ki is hagyhatjuk. Ha alaplapi IDE vezérlő chipset-ünk van és a Linux támogatja ezt, akkor válasszuk azt is156. Loopback Device support, Network block device support kell. Ha valamilyen RAID, vagy párhuzamos portra csatlakoztatható IDE eszközünk van, válasszuk ki.
- Networking options: itt ki kell választanunk, hogy milyen hálózati funkciókra lesz szükség. Packet socket: [m], K./U. netlink socket: [y], Network firewalls: [y], Unix domain sockets: [y], Socket filtering: [y], TCP/IP networking: [y], IP firewalling: [y], IP firewall packet netlink dev.: [y] Ezek többek között a tűzfal és csomagszűrő funkciók. Masq és proxy nem kell, mert ennek a szervernek nem az a feladata. IP aliasing: [y] - ez kell, ha IP-s virtualhost-ot szeretnénk. TCP syncookie support: [y] - ez a DoS típusú támadásoktól véd. Allow large windows: [y] Ha szükségünk van egyéb hálózati protokollokra, funkciókra, akkor jelöljük ki azokat is.
- SCSI support: ha van ilyen eszközünk, válasszuk ki. (pl. merevlemez)
- Network device support: [y], Dumy:[y], Ha van pl. üvegszálas hálózati eszközünk, akkor válasszuk ki. Ha van ARCnet, Ethernet, Appletalk, Token ring, WAN, Amateur Radio hálózati eszközünk válasszuk a megfelelő vezérlőt.
- Nem hiszem, hogy a szerverben infravörös, ISDN, és / vagy régi kártyás CD-ROM eszközeink lennének. Ezeket kihagyhatjuk.
- Character devices / Virtual terminal: [y], Support for console…:[y], ha kell, soros port vezérlőnket is válasszuk ki. Unix98 PTY support: [y], Watchdog support: [y], (lesz majd szoftveres) Eanched Real Time Clock Support: [y] Egérre nem hiszem, hogy itt szükség lesz. Nyomtatóra, botkormányra, képfeldolgozó eszközre sem.
- Watchdog cards: / software watchdog: [m], ezt később tárgyalom.
- Ha van Ftape (floppy portra kapcsolható szalagos egység), akkor azt is.
- Filesystems / Second extended fs support: [y] - erről fogunk ui. indulni. /proc…, /dev/pts…: [y] Itt még sok egyéb választásunk is van. Ha esetleg más operációs rendszereket is tartanánk ugyanazon a gépen (a mi esetünkben nem), akkor válasszuk ki, ami kell.
- Network file systems / NFS fs supp.: [m] ez a klienshez kell, szervert meg nem tanácsos üzemeltetnünk, az kimarad. Ha van a környezetben más gyártótól rendszerszoftver és szükség is van rá, hogy rendszerünk lássa azokat, akkor válasszuk ki ami kell.
- Partition types: ha ugyanazon a gépen más op’rendszereket is tartunk, jól jöhet a nekik megfelelő speciális partíciós tábla vezérlője, egyébként semmi szükség rájuk.
- Native language support / NLS ISO 8859-1 és -2 modulba.
- Console drivers / VGA text console:[y], - ha VGA kártya van a gépben. Támogathatjuk továbbá az MDA egyszínű monitorokat is. Szerverben a Frame buffer-nek nem sok értelme van, úgysincs rajta monitor. Ha nem választunk itt ki semmit, akkor nem jutunk be a gépbe, csak a soros porton!
- Sound - itt hangkártyának semmi értelme, nem kell.
- Ha betettük az OpenWall-féle foltot, akkor itt van egy Security Options menü is, ami alatt az összes kérdésre válaszoljunk yes-el.
- Ha a LIDS rendszert is befoltoztuk, olvassuk el a részletesebb útmutatót a Függelékben!
- Kernel hacking - Magic SysRq key : [y] - ha a rendszer lefagyna, akkor az alt-printscreen billentyűvel még esetleg feléleszthetjük a konzolt, vagy legalább kiíratjuk a veremtárat és a gyorsítótárakat. (Olvassuk el a doksiját!)
Miután mindent beállítottunk mentsük el a változásokat és lépjünk ki.
- Ebben a lépésben a fordító a .config fájl alapján beállítja a függőségeket - csak az fog lefordulni a forrásból, amire szükség van a mi beállításainkhoz. Ezt a make depend paranccsal tehetjük meg. Ezt a lépést nem lehet kihagyni!
- Most elindítjuk a kernel fordítását: make -j2 bzImage157
- Ha nem kapunk hibaüzenetet, akkor indítsuk a modulok fordítását: make -j2 modules
- Ha itt se kaptunk hibaüzenetet, akkor a make modules_install paranccsal felteszi a /lib/modules/kernelverzió könyvtárba a kész modulokat. Ha kész mozgassuk át őket a szerverre.
- Másoljuk a magot, a térképet és a konfigot a /boot-ba
scp arch/i386/boot/bzImage root@alfa:/boot/vmlinuz-kernelverzió
scp System.map root@alfa:/boot/System.map-kernelverzió
scp .config root@alfa:/boot/config-kernelverzió-gépnév
- (Innentől minden a szerveren történik) Szerkesszük meg az /etc/lilo.conf fájlt, hogy az új kernelünk felkerülhessen az indítható kernelek közé. Ha kész futtassuk a lilo-t. Itt látható egy mintapélda:
boot=/dev/hda # az eszköz, ahova a boot menedzser települjön
install=/boot/boot.b # ez az i386 arhitektúra miatt szükséges valós módú kód
map=/boot/map # és lemeztérképe
vga=5 # milyen VGA szöveges módba váltson a konzol, itt 80x34
delay=50 # várakozás tizedmásodpercben, mielőtt a kernelt indítja.
prompt # mindenképp jelezze ki a választómenüt
timeout=50 # ha nekikezdünk gépelni, de abbahagyjuk…
default=sajat # melyik kernel induljon el, ha nem választunk
message=/boot/message # a lilo prompt elé írhatunk üzenetet.
root=/dev/hda3 # hol van a gyökér fájlrendszer
read-only # csak olvasható módban fűzze fel először a rendszert
#a gyári kernel mindig legyen fenn, hátha kell.
image=/vmlinuz # a kernel helye
password=jelszo # mi legyen a jelszó, arra az esetre
restricted # ha paraméterek akarunk átadni a kernelnek induláskor158
label=gyari # mi legyen a kernel neve a lilo prompt-nál
image=/boot/vmlinuz-2.2.16
password=mehet
restricted
label=sajat
append="idebus=45” # paraméterezhetjük az egyes kódrészeket az append
# parancs segítségével. (opcionális)
Ezek után, ha minden hiba nélkül futott le, újraindíthatjuk a szervert. Mindenképp legyen egy stabil, működő kernel a lilo.conf-ban, nehogy kizárjuk magunkat a rendszerből. Érdemes minden jól működő és használatban lévő kernelből boot floppy-t is gyártani, hátha megsérül az MBR.
Ha a lilo.conf159 végleges, állítsuk 400-re a mask-ját, és tegyük rá az immutable bit-et.
Az új kernelt teszteljük, stresszeljük először, mielőtt feltennénk az éles szerverre. Persze, mivel a rendszergazdai gép biztosan más hardvereket tartalmaz, mint a szerver, ezért lehet, hogy ki se próbálhatjuk. A kernel fordítása közbeni hibák egy része utalhat hibás memória vagy processzor elemekre. Esetleg nem jó a processzor hűtése. Ellenőrizzük.
Fordítás a kernel-package csomaggal:
Első fázis:160 kernel beszerzése és konfigurálása
cd <kernel forráskönyvtár>
make config / make menuconfig / make xconfig , beállítás
Második fázis: az /etc/kernel-pkg.conf beállítása
maintainer: Kis József # a csomag készítőjének a neve
email: kjozsi@akarmi.hu # és a címe
debian: gepnev.datum # az alapbeállítás, ha véletlenül nem adnánk meg
image_in_boot:true # ekkor a /vmlinuz szimbolikus link a /boot-ba kerül,
# így lehet még egy gyári csomagunk is.
Harmadik fázis: Egy szállítható bináris kernel gyártása .deb csomagba
- make-kpkg clean - Ez a parancs letörli az előző próbálkozásaink által generált átmeneti fájlokat. Az export CONCURRENCY_LEVEL=2 paranccsal létrehozunk egy változót, amely a make parancsnak megadja a -j2 paramétert.161
- (rendszergazdai jogkör), majd make-kpkg --revision=alfa.20000420 --bzimage kernel_image - Ez a parancs elkészíti a Debian csomagot. A revision paramétere mindig kezdődjön betűvel, hogy egy frissítésnél ne cserélje le a rendszer a saját kernelünket egy “gyárira”. (Esetleg tegyük “Hold” állapotba.) Ebbe a saját verziószámban nem lehet “_” jel, ne legyen “:” jel, de lehet “-, +, =” jel. Én a következő módszert javaslom: gépnév.dátum. Ekkor egy csomag neve így fog kinézni:
kernel-image-2.2.16_2.2.16-alfa.20000420_i386.deb
Negyedik fázis: a kernel csomag telepítése. Vigyük át a kernel csomagot a szerverre (pl. scp-vel, floppy-val, stb.), majd ott:
- dpkg -i kernel-image-2.2.16_2.2.16-alfa.20000420_i386.deb
- Vizsgáljuk át az /etc/lilo.conf-ot, ha kell, tegyük meg a szükséges változtatásokat, majd futtassuk a lilo-t.
- shutdown -r now Csak akkor lehet újraindítani a gépet, ha a lilo rendesen lefutott.
Végeredményben ez a második változat sokkal kényelmesebb és Debian-kompatibilis. Mindenkinek ezt ajánlom az éles gépeken való használatra. Előnyösebb, mert:
- Kényelmes, hiszen kevesebb parancsot kell kiadni, a script elvégzi helyettünk a munka nagy részét
- Könnyebben tarthatunk több kernelt is egy gépen
- Olyanok készítették el, akik nagyon járatosak a témában, ezért mi nem is hibázhatunk egy kis lépésben sem
- A csomagkezelőre bízhatjuk az összes feltelepített programot, nem kell kézi telepítéssel és törléssel vesződni
- Megőrzi a konfigurációs fájlokat későbbi használatra
- Installációs script-ekkel jön, melyek segítik a telepítést és a letörlést is
- Nem kell a modulok másolgatásával foglalkozni
- Egy gyorsabb gépen is fordíthatjuk a lassabb gép számára a kernelt
Ha kész vagyunk mindennel, és megfelelően le is van tesztelve a kernel, akkor állítsuk a kernel jogait így: chmod 0400 /boot/kernelneve Sőt, a jól bevált immutable bit is jól jöhet.
2.6 Az Apache finomhangolása, esetleges újrafordítása hardver és feladatorientáltan
Mondhatni ez is egy sokrétű kérdés. A felhasználási - alkalmazási céloktól függ sok minden. Érdemes elolvasni ezt a cikket: [19]. Mivel a munka keretét meghaladja az összes modul funkciójának ismertetése, ezt mellőzöm. Bármilyen felmerülő kérdésünk van, olvassuk el először a dokumentációt (apache-doc csomag), vagy nézzük meg a csoport honlapját.
A következőkben a mintapéldához hangolom a rendszert. A példában szereplő cégnek profilja szerint két divíziója van: egy szőrme és egy bőrgyártó részleg. Mivel a két divízió eléggé különböző piaccal, PR-el és termékkel rendelkezik ezért két külön Web-helyet hozunk létre nekik. A “fő” Web-hely a cég általános információit tartalmazza és linkeket a két másik, specifikusabb hely felé. Mivel jelen esetben csak egy IP címet vásároltunk, ezért az Apache NameVirtualHost funkcióját fogjuk használni. Így képesek leszünk arra, hogy a kliens böngészője által kért Web-helyet adjuk vissza neki név szerint. Mivel az egyetlen IP címünket lefogja a NameVirtualHost, ezért a fő Web-szerver nem fog szolgáltatni ezen, csak a hurok interfészen. Ezért három virtuális szervert készítünk. Egy a főcég és kettő a két divízió tartalmát tárolja és szolgáltatja.
Az alapbeállítás szerint az Apache-SSL csomag csak a 443-as portot használja. Mi azonban szeretnénk, hogy a szabványos 80-as porton kódolatlan Web-szolgáltatást is nyújtson.
Az Apache konfigurációs állományai az /etc/apache-ssl/ könyvtárban helyezkednek el. Több állományból áll a rendszer. A fő beállításokat a httpd.conf tartalmazza. Az access.conf a hozzáférést szabályozza, míg az srm.conf állomány a felhasználók által látott rész dolgait szabályozza, mint pl. a MIME, ikonok, stb.
Mivel az Apache esetünkben nagyon fontos, ezért nem csak azokat a beállításokat fogom felsorolni, melyeket meg kell változtatni, hanem nagyrészt azokat is, melyek alapbeállításai jók. Ezt azért teszem, hogy az olvasó minél könnyebben megértse a paraméterek jelentését és szükség szerint finomhangolhassa azt saját igényeihez. A paramétereket kommentezett megjegyzésekkel próbálom érthetővé tenni. Olvassuk el figyelmesen a megjegyzéseket.
Először vegyük sorra a httpd.conf-ot:
# - Általános beállítások----------------------------------------
ServerType Standalone # a szerver indításkor betöltődik, nem az inetd indítja
#Port 443 #
#Port 80 #
Listen 443 # ezeket a portokat figyelje, ez a HTTPS
Listen 80 # ez a szabványos HTTP port162
HostNameLookups off # ne keresse meg a kliens nevét, elég az IP címe
# a DNS keresés nagyon lelassíthatja a működést
User www-data
Group www-data # milyen jogokkal fusson a szerver, semmiképp se root!
ServerAdmin webmaster@boresszormegyar.hu # hova küldje a leveleket hiba esetén
ServerRoot /etc/apache-ssl # hol vannak a konfig’ fájlok
BindAddress agépünkIPcíme # ezen a címen vagyunk elérhetőek (ha esetleg több IP
# címünk is lenne - több hálókártya )
NameVirtualHost agépünkIPcíme:80 # virtuális szervereink ezt az IP címet fogják
NameVirtualHost agépünkIPcíme:443 # figyelni a 80-as és 443-as portokon
# ServerName # mi legyen a fő szerver neve? - erre itt nincs szükség
UseCanonicalName on # linkek kiegészítése a saját névvel
Timeout 300 # kacsolat bontása másodpercben
KeepAlive on # tartós kapcsolatok fenntartása a kliensekkel
MaxKeepAliveRequests 100 # hány db kérést tartson fenn
KeepAliveTimeout 15 # Mennyi másodpercig tartsa fenn a kapcsolatot
MinSpareServers 5 # Minimálisan hány “felesleges” szerver fusson
MaxSpareServers 10 # Maximálisan hány “felesleges” szerver fusson
StartServers 5 # Induláskor hány szervert indítson el
MaxClients 200 # Maximálisan hány kapcsolat élhet
MaxRequestsPerChild 50 # 50 kérés teljesítése után “megöli gyermekét”163
#---------------------- Modulok ---------------------------------
# Melyik modulokat töltsük be? Azokat, amelyeket én nem láttam szükségesnek
# kikommenteztem. Ha az olvasónak szüksége van valamelyikre, válasszon tetszés
# szerint
# A virtuális szerverek álnév támogatása
LoadModule vhost_alias_module /usr/lib/apache/1.3/mod_vhost_alias.so
# Könrnyezeti változók átadása CGI script-eknek
# LoadModule env_module /usr/lib/apache/1.3/mod_env.so
# Testre szabható naplózás
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config_ssl.so
# Objektum típus megállapítása tartalomból
LoadModule mime_magic_module /usr/lib/apache/1.3/mod_mime_magic.so
# Objektumtípus megállapítása fájlkiterjesztésből
LoadModule mime_module /usr/lib/apache/1.3/mod_mime_ssl.so
# Tartalom “tárgyalás”
LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so
# a szerver állapotának megjelenítése weblapként (autentikáció szükséges)
LoadModule status_module /usr/lib/apache/1.3/mod_status.so
# Szerver beállítási információk
LoadModule info_module /usr/lib/apache/1.3/mod_info.so
# Szerveroldalon előállított objektumok
LoadModule includes_module /usr/lib/apache/1.3/mod_include.so
# Automatikus könyvtár listázás
LoadModule autoindex_module /usr/lib/apache/1.3/mod_autoindex.so
# Alapszintű könyvtárkezelés
LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so
# CGI script-ek meghívása
#LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so
# Az “.asis” fájl kezelő
# LoadModule asis_module /usr/lib/apache/1.3/mod_asis.so
# Kép-térkép fájlkezelő
# LoadModule imap_module /usr/lib/apache/1.3/mod_imap.so
# Automatikus hibajavitás félregépelt url-ekben
LoadModule speling_module /usr/lib/apache/1.3/mod_speling.so
# A felhasználók könyvtárait kezeli (listázás, letöltés)
# LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
# HTTP gyorsítótár
# LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so
# Álnevek és átirányítások
LoadModule alias_module /usr/lib/apache/1.3/mod_alias.so
# Az access.conf értelmezéséhez
LoadModule access_module /usr/lib/apache/1.3/mod_access.so
# Felhasználó azonosítás szöveg fájlokkal
LoadModule auth_module /usr/lib/apache/1.3/mod_auth_ssl.so
# ftp stílusú anonimusz felhasználó azonosítás
# LoadModule anon_auth_module /usr/lib/apache/1.3/mod_auth_anon.so
# felhasználó azonosítás DBM fájlokkal
# LoadModule dbm_auth_module /usr/lib/apache/1.3/mod_auth_dbm.so
# felhasználó azonosítás a Berkeley-féle DB (adatbázis) fájlokkal
# LoadModule db_auth_module /usr/lib/apache/1.3/mod_auth_db.so
# MD5 felhasználó azonosítás
LoadModule digest_module /usr/lib/apache/1.3/mod_digest.so
# HTTP fejléc metafájlok támogatása
LoadModule cern_meta_module /usr/lib/apache/1.3/mod_cern_meta.so
# Fejlécek erőforrásokhoz (pl. meddig érvényes egy oldal)
LoadModule expires_module /usr/lib/apache/1.3/mod_expires.so
# Tetszőleges HTTP fejlécek beépítése
LoadModule headers_module /usr/lib/apache/1.3/mod_headers.so
# Felhasználó-követés sütik segítségével
# LoadModule usertrack_module /usr/lib/apache/1.3/mod_usertrack.so
# egységes kérés azonosító generálása minden lekéréshez
LoadModule unique_id_module /usr/lib/apache/1.3/mod_unique_id.so
# Környezeti változók beállítása kliens információk alapján
LoadModule setenvif_module /usr/lib/apache/1.3/mod_setenvif.so
# Szerverek online statisztikái.
LoadModule throttle_module /usr/lib/apache/1.3/mod_throttle.so
# SSL rendszerhívások
AddModule apache_ssl.c
# LDAP alapú azonosítás
# LoadModule auth_ldap_module /usr/lib/apache/1.3/auth_ldap.so
# Eszlözfájlok kezelése
# LoadModule allowdev_module /usr/lib/apache/1.3/mod_allowdev.so
# PostgreSQL adatbázis alapú azonosítás
# LoadModule pgsql_auth_module /usr/lib/apache/1.3/mod_auth_pgsql.so
# A fontos PHP3 modul
LoadModule php3_module /usr/lib/apache/1.3/libphp3.so
# Netscape 4.x roaming támogatása
# LoadModule roaming_module /usr/lib/apache/1.3/mod_roaming.so
#----- Naplózás -----------------------------------------------------------
# itt tárolja induláskor a folyamat azonosító számát
PidFile /var/run/apache-ssl.pid
ErrorLog /var/log/apache-ssl/error.log # A hibaüzenetek ide menjenek
LogLevel warn # mit loggoljon? debug/info/notice/warn/error/crit
# mi legyen a naplózás formája?
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %T %v" full
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
# Egyéni naplófájlok:
# Vigyázat! Ha nagy a forgalom nagyra dagadhat a fájl. Biztonsági szempontból
# előnyös, hiszen minden egyes kérés naplózva lesz IP címmel. Ha támadás gyanú van,
# akkor mindenképp kapcsoljuk be. Továbbá a statisztikákat is ezekből készítjük.
CustomLog /var/log/apache-ssl/access.log common # naplózhatjuk a hozzáférést is
# Ezzel naplózzuk azt az oldalt, ahonnan idelépett a kliens
# CustomLog /var/log/apache-ssl/referer.log referer
# A kliens böngészőinformációit naplózza
# CustomLog /var/log/apache-ssl/agent.log agent
# SSL beállítások --------------------------------
#Globális szerver-gyorsító a kulcsok számára
SSLCacheServerPath /usr/lib/apache-ssl/gcache
SSLCacheServerPort /var/run/gcache_port # a használandó port (unix domain socket)
SSLSessionCacheTimeout 50 # időzítő
SSLCACertificatePath /etc/apache-ssl # a CA igazolás helye
#SSLCACertificateFile CA.pem # ha van saját CA igazolásunk
SSLCertificateFile /etc/apache-ssl/apache.pem # az igazolás
# SSLVerifyClient beállítása:
# 0 ha nincs szükség arra, hogy a kliensnek legyen igazolása
# 1 ha a kliens adhat igazolást
# 2 ha a kliensnek kötelezően be kell mutatnia egy igazolást
# 3 ha a kliensnek lehet igazolása, de nem szükséges, hogy az érvényes CA-ja legyen
SSLVerifyClient 0
SSLFakeBasicAuth # a BD és DBM kompatibilitás miatt
#SSLRequireCipher # csak ilyen titkosító algoritmusokat fogadunk el
#SSLBanCipher # ezeket pedig letiltjuk
# SSL tranzakciók naplózása:
CustomLog /var/log/apache-ssl/ssl.log "%t %{version}c %{cipher}c %{clientcert}c"
# ---Virtuális gépek ------------------------
# Itt definiáljuk a két gyárrészleg külön oldalait
<VirtualHost www.szormegyar.hu:80> # virtuális szerver ezen a néven a 80-as porton
#ServerAdmin # lehetne külön webmestere mindnek
SSLDisable # itt kikapcsoljuk az SSL-t
DocumentRoot /var/www/szormegyar # mindenkinek a saját gyökerét
ServerName www.szormegyar.hu # és a saját nevét adjuk meg
ServerAlias szormegyar.hu *.szormegyar.hu # az erre hivatkozókat is ide irányítjuk
# külön is kérhetjük a log-okat.
ErrorLog /var/log/apache-ssl /szormegyar-error.log
# Az összes kérést és forgalmat is lehet külön naplózni,
# ebből készülnek a statisztikák.
CustomLog /var/log/apache-ssl/szormegyar-access.log common
#TransferLog /var/log/apache-ssl/szormegyar-access.log
</VirtualHost>
<VirtualHost www.szormegyar.hu:443> # ugyanazt kikínáljuk SSL-el is
SSLEnable
DocumentRoot /var/www/szormegyar
ServerName www.szormegyar.hu
ServerAlias szormegyar.hu *.szormegyar.hu
ErrorLog /var/log/apache-ssl/szormegyar-ssl-error.log
CustomLog /var/log/apache-ssl/szormegyar-ssl-access.log common
</VirtualHost>
<VirtualHost www.borgyar.hu:80>
DocumentRoot /var/www/borgyar
SSLDisable
ServerName www.borgyar.hu
ServerAlias borgyar.hu *.borgyar.hu
ErrorLog /var/log/apache-ssl/borgyar-error.log
CustomLog /var/log/apache-ssl/borgyar-access.log common
</VirtualHost>
<VirtualHost www.borgyar.hu:443>
SSLEnable
DocumentRoot /var/www/borgyar
ServerName www.borgyar.hu
ServerAlias borgyar.hu *.borgyar.hu
ErrorLog /var/log/apache-ssl/borgyar-ssl-error.log
CustomLog /var/log/apache-ssl/borgyar-ssl-access.log common
</VirtualHost>
<VirtualHost www.boresszormegyar.hu:80>
DocumentRoot /var/www/boresszormegyar
SSLDisable
ServerName www.boresszormegyar.hu
ServerAlias boresszormegyar.hu *.boresszormegyar.hu
ErrorLog /var/log/apache-ssl/boresszormegyar-error.log
CustomLog /var/log/apache-ssl/boresszormegyar-access.log common
</VirtualHost>
<VirtualHost www.boresszormegyar.hu:443>
SSLEnable
DocumentRoot /var/www/boresszormegyar
ServerName www.boresszormegyar.hu
ServerAlias boresszormegyar.hu *.boresszormegyar.hu
ErrorLog /var/log/apache-ssl/boresszormegyar-ssl-error.log
CustomLog /var/log/apache-ssl/boresszormegyar-ssl-access.log common
</VirtualHost>
A következő fájl, az access.conf:
Minden könyvtárra külön szabályokat állíthatunk fel.
<Directory /var/www>
# none: semmi, all: az összes következő, Indexes: a kliens listázhatja,
# Includes: futtathat szerver-oldali scripteket,
# FollowSymlinks: követi a szimbolikus linkeket - veszélyes lehet!
# ExecCGI: CGI scripteket futtathatunk innen - veszélyes!
# olvassuk el a dokumentációt! /usr/share/doc/apache/manual/mod/core.html#options
Options none
AllowOverride none # olvassuk el a dokumentációt!
Order deny,allow
# deny from gonosz.betörő.domén
allow from all
</Directory>
#A CGI-ket tartalmazó könyvtár. Nézzük meg mi van benne. Ha üres, akkor
# kommentezzük ki innen is.
<Directory /usr/lib/cgi-bin>
AllowOverride None
Options ExecCGI FollowSymLinks
</Directory>
Az alkönyvtárak ezeket a beállításokat öröklik. Az alkönyvtárak beállításait egyenként felülbírálhatjuk.
Ha egyes könyvtárakhoz való hozzáféréshez felhasználó azonosítást szeretnénk, megtehetjük az
access.conf fájlban, vagy az adott könyvtárban elhelyezett
.htaccess/.htpasswd fájlban is. A kódoláshoz és azonosításhoz több féle autentikációs modul használható:
mod_auth
mod_digest
mod_auth_sys
mod_auth_pam
|
alapfunkciós, crypt() függvényt használ
MD5 kódolást használ
a /etc/passwd fájlt használja
a PAM függvényeit használja
|
10. táblázat - Autentikációs modulok
Nekünk a PAM lenne jobb, de az /etc/shadow fájlt nem látja, ezért azt olvashatóvá kellene tenni az Apache számára, ami komoly veszélyeket rejt magában. Az árnyékjelszó miatt az auth_sys sem működik sajnos. Az MD5-ös kódolás jó választás lenne, de a legtöbb böngésző (pl. Netscape 4.x) még nem támogatja. Így kénytelenek vagyunk a hagyományos azonosítást használni. Itt használhatunk sima szöveges, DB és DBM formátumú fájlokat is. Mivel nem sok felhasználót kell tárolnunk, megfelel a szöveges fájlt is. Egy jó cikk olvasható kezdőknek e témában itt [20].
Ha betöltöttük a status modult, akkor Weben keresztül is lekérdezhető a szerver állapota. Vigyázat, ennek nyilvánossá tétele megkönnyíti a betörők helyzetét! Alkalmazzunk SSL-es kódolást és azonosítást. Csak a rendszer és Web-gazdák tekinthessék meg a szerver állapotát. Ehhez először is létre kell hoznunk egy jelszófájlt. Ez a fájl nem lehet a /var/www könyvtár alatt, hiszen ekkor azt mások könnyen meg tudják szerezni. Helyezzük el az /etc/apache-ssl könyvtárban, pl. info.pwf néven164. Így hozhatjuk létre:
htpasswd -c jelszófájl felhasználó; chmod 0640 jelszófájl;
chgrp www-data jelszófájl
Vigyázzunk, hogy ha más autentikációs modul is be van töltve, az lesz érvényes és ezért esetleg nem fog helyesen működni a mod_auth.
<Location /szerver-statusz>
SetHandler server-status # ez esetben a server-status modul veszi át a tartalmat
order deny,allow
#deny from all
allow from all # ide azt írjuk be, hogy honnan lehessen lekérdezni.
SSLRequireSSL # ide csak SSL-el lehet belépni
# AuthPam_Enable off # ha betöltöttük a mod_auth_pam modult, most kapcs. ki
AuthType Basic # crypt() függvényt használó azonosítás
AuthName Státusz # ez jelenik meg a jelszó kérésekor
AuthGroupFile /dev/null # a csoport lista most üres (nem kötelező)
AuthUserFile /etc/apache-ssl/info.pwf # ebben a fájlban tároljuk a jelszavakat
require user rgazda wgazda # csak ezek a felhasználók férhetnek hozzá az infókhoz
</Location>
# A szerver beállításait tartalmazó információkkal is ugyanígy járjunk el:
<Location /szever-info>
SetHandler server-info
order deny,allow
#deny from all
allow from all # ide azt írjuk be, hogy honnan lehessen lekérdezni.
SSLRequireSSL # ide csak SSL-el lehet belépni
# AuthPam_Enable off # ha betöltöttük a mod_auth_pam modult, most kapcs. ki
AuthType Basic
AuthName Infó
AuthUserFile /etc/apache-ssl/info.pwf
require user rgazda wgazda
</Location>
# Ez a phf típusú betörési kísérleteket naplózza
Location /cgi-bin/phf*>
deny from all
ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
</Location>
# Kiadhatjuk a dokumentációt, hogy könnyebb legyen a konfigurálás.
<Directory /usr/share/doc>
Options Indexes FollowSymLinks
AllowOverride None
order allow,deny
allow from 127.0.0.1 “rendszergazdaIP-je”
deny from all
SSLRequireSSL # ide csak SSL-el lehet belépni
AuthType Basic
AuthName Doksik
AuthUserFile /etc/apache-ssl/info.pwf
require user rgazda wgazda
</Directory>
Alias /doksik/ /usr/doc/
# Ez is veszélyes lehet, mert a betörő megtudhatja, hogy milyen programok
# vannak a gépen, ezért mindenképp kössük azonosításhoz a hozzáférést.
<location /th-info> # az egyes virtuális gépek forgalmát monitorozhatjuk vele.
SetHandler throttle-info
order deny,allow
#deny from all
allow from all # ide azt írjuk be, hogy honnan lehessen lekérdezni.
SSLRequireSSL # ide csak SSL-el lehet belépni
# AuthPam_Enable off # ha betöltöttük a mod_auth_pam modult, most kapcs. ki
AuthType Basic
AuthName Th-Infó
AuthUserFile /etc/apache-ssl/info.pwf
require user rgazda wgazda
</location>
#A felhasználók - bár nem lesznek - ne tudjanak symlink-támadást csinálni.
<DirectoryMatch ^/home/.*/public_html>
Options Indexes SymLinksIfOwnerMatch
AllowOverride None
</DirectoryMatch>
# Biztonsági okokból ezeknek a fájloknak a forgalmát letiltjuk
<Files .htaccess>
order allow,deny
deny from all
</Files>
<Files .htpasswd>
order allow,deny
deny from all
</Files>
Az srm.conf-ot itt nem részletezem, mert alapbeállításai jók számunkra, mindazonáltal mindenki olvasgassa át, és ha szüksége van rá, ízlés szerint módosítsa.
Az Apache fordítása
Ezt csak és kizárólag olyanok végezzék, akiknek már van kellő tapasztalatuk és gyakorlatuk az Apache fordításában, annak konfigurálásában, általánosan a fordítások folyamatában, és tényleg tudják, hogy mit csinálnak. Sajnos ez elég nehéz kezdetben.
Amennyiben úgy döntünk, hogy lefordítjuk magunknak az Apache-ot, mert:
- Nagy forgalmat fogunk bonyolítani és a processzorhoz akarjuk optimalizálni a kódot, a gyorsabb végrehajtás érdekében
- Olyan modulra van szükségünk, amelyet a “gyári” csomag nem tartalmaz
- Az 1.3.12-es vagy újabb verzióra van szükségünk az új funkciók miatt
- Egyszerűen szeretünk mindent a saját kezünkben tartani akkor üljünk át a rendszergazdai géphez.
- Ha megfelel az 1.3.9-es verzió és az apt-t úgy konfiguráltuk, hogy a forráskód csomaglistát is kezelje, akkor elég ezt a parancsot kiadnunk: apt-get source apache-ssl Ha minden jól ment, akkor néhány percen belül az /usr/src alatt találjuk a szükséges fájlokat.165
- Ha az 1.3.12-es vagy újabb változatra van szükségünk, akkor adjuk ki a következő parancsokat (vagy töltsük le ftp-vel a következő fájlokat):
wget ftp://ftp.hu.debian.org/debian-non-US/dists/woody/non-US/main/source/apache-ssl* és helyezzük el az /usr/src könyvtárba.
Ezek után lépjünk be az /usr/src könyvtárba és adjuk ki ezt a parancsot: dpkg-source apache-ssl*.dsc166 Ez kibontja a három forráscsomagot. Lépjünk be az apache-ssl* alkönyvtárba. Ne felejtsük el ellenőrizni a DEBIAN_BUILDARCH változó értékét.167 Ha a fordítás előtti konfigurációt is módosítani szeretnénk, akkor először is tudnunk kell, hogy mit is akarunk pontosan. Pl. ha az összes modult le szeretnénk fordíttatni, nem csak a stabil állapotúakat, lépjünk be a debian alkönyvtárba és szerkesszük meg a rules fájlt a következőképp: írjuk be a 100. sorába az all szót a most helyébe:
17. kép - rules fájl szerkesztése
Ha nem akarjuk megváltoztatni a modulok konfigurációját, akkor lépjünk tovább. Ezután lépjünk vissza egy könyvtárral, majd: debian/rules binary paranccsal indíthatjuk a fordítást. Ha minden fordításhoz szükséges csomag fenn van a gépen és van elég helyünk is, akkor pár perc múlva (lassabb gépen tovább is eltarthat!) az /usr/src könyvtárban megjelennek a kész, lefordított csomagok. Ezután a dpkg -i csomagnév paranccsal telepíthetjük őket. Ha már kész, beállított konfigurációs állományaink vannak, ne engedjük felülírni őket! Ha minden jól ment, akkor már egy gépre optimalizált, egyéni beállításokkal fordított Apache szerverünk fut a gépen.
2.7 Az SSH konfigurációjának finomhangolása
A Debian-ban az OpenSSH program alapbeállításai elég jók és szigorúak, ám ezen is lehet még finomítani. Az /etc/ssh könyvtárban lévő ssh_config és sshd_config fájlokat kell megvizsgálnunk. Az első a kliens a második a szerver program beállításait tartalmazza. Érdemes először a manuál oldalakat elolvasni, mert így legalább tisztában leszünk a következő fogalmakkal. Az ssh képes X11 kapcsolatokat és más TCP portokat továbbítani a titkosított csatornán.
- Ha léteznek a /etc/hosts.equiv vagy /etc/ssh/shost.equiv fájlok (megfelelően ki is vannak töltve) és mindkét gépen a felhasználónak ugyanaz a login neve, akkor azonosítás nélkül beléphet az egyik gépről a másikra. Ezt nekünk mindenképp le kell tiltanunk, mert komoly biztonsági veszélyforrást jelent. (RhostsAuthentication)
- Ez az eljárás kiegészülhet azzal, hogy a szerver ellenőrizheti a kliens gépének RSA kulcsát és csak ezek után engedélyezi a belépést. Ez már valamennyire biztonságosabb az előzőnél, de még mindig fennáll annak a veszélye, hogy valaki más ül a kliens előtt, mint akié a számla és ekkor az a jelszó ismerete nélkül is beléphet. Ezért ez a módszer is kerülendő. (RhostsRSAAuthentication)
- A harmadik azonosítási módszer a tiszta RSA autentikáció, mely nyilvános kulcsú azonosítást tesz lehetővé. Ez is felment minket a jelszók állandó gépelésétől, viszont generálni kell minden egyes felhasználónak (mindenki saját magának) egy saját titkos és nyilvános kulcsot. Ezután, ha a szerveren megvan a megfelelő kulcs párja, akkor egy kulcsteszt után beenged. (RSAAuthentication)
- A negyedik és egyben legbiztonságosabb azonosítási rendszer a hagyományos jelszó alapú rendszer. (PasswordAuthentication)
Figyelem! Minden felhasználó felülbírálhatja a gépszintű beállításokat a saját .ssh/config fájl beállításával.
Nézzük tehát a kliens beállításait: /etc/ssh/ssh_config
Host localhost # ezek a saját gépre vonatkoznak.
ForwardAgent yes # csak itt engedélyezzük az X11-es titkosított
ForwardX11 yes # csomagok átjátszását. Ha ezt engedélyeznénk
Host * # kívülre is, akkor komoly biztonsági problé-
ForwardAgent no # val kellene szembenézni.
ForwardX11 no
RhostsAuthentication no # .rhost fájl alapján ne engedjünk azonosítást
RhostsRSAAuthentication no # még RSA kulcsosat se
RSAAuthentication yes # RSA kulcsos azonosítás jelszó helyett
PasswordAuthentication yes # a jelszós azonosítást engedélyezzük
FallBackToRsh no # hiba esetén ne térjünk vissza kódolatlan üzemmódba
UseRsh no # rsh használatát tiltsuk le
BatchMode no # ez a script-ekben használatos, de tiltsuk le, mert
# ekkor nincs jelszó-kérés!
CheckHostIP yes # ha név szerint kérjük, ellenőrizzük le a név-IP párost
# StrictHostKeyChecking yes # nem engedjük új gépek kulcsának elfogadását
IdentityFile ~/.ssh/identity # itt van a saját kulcsunk
Port 22 # általában itt kell keresgélnünk
Cipher blowfish # ez a titkosító algoritmus sokkal gyorsabb és bizton-
# ságosabb, mint a DES vagy a 3DES.
EscapeChar ~ # bővebb leírást ezekről a manuálban!
Compression yes # ha modemen keresztül vagyunk, akkor jól jöhet
# a tömörítés, gyors hálózaton viszont lassít.
GatewayPorts no # más gépek ne kapcsolódhassanak a helyi továbbított
# portokhoz
Ez itt pedig egy minta sshd_config:
Port 22 #melyik portot használjuk
ListenAddress 0.0.0.0 # milyen tartományból engedjünk be hívásokat
HostKey /etc/ssh/ssh_host_key # a szerver kulcsa
ServerKeyBits 1024 #eredeti: 768 # a kulcs hossza
LoginGraceTime 300 # hány másodperce van a kliensnek azonosításra
KeyRegenerationInterval 3600 # a kulcs óránként újragenerálódik
PermitRootLogin no # a root nem jelentkezhet be!
#AllowGroups webcsap # csak ezek a csoportok jelentkezhetnek be
#AllowUsers webgazda system # csak ezek a felh. jelentkezhetnek be
#DenyGroups stuff nogroup # ezek semmiképp sem jelentkezhetnek be
#DenyUsers nobody
StrictModes yes # ellenőrzi belépés előtt a felh. fájlok jogait
X11Forwarding yes # szerverszinten engedélyezhető
X11DisplayOffset 10
KeepAlive yes # próbálja meg életben tartani a kapcsolatot
UseLogin no # ne használjuk, hátha trojan-os
PrintMotd no # mivel ezeket már a PAM kezeli, kikapcs.
CheckMail no
SyslogFacility AUTH # melyik syslog kategóriába tartozzon az
# azonosítás
LogLevel INFO # naplózási szint
RhostsRSAAuthentication no
IgnoreRhosts yes # el se olvassuk ezeket
RhostsAuthentication no
IgnoreUserKnownHosts yes # ekkor csak a rendszergazda határozhatja meg,
# melyek az ismert gépek
RSAAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords no # ne engedjünk meg üres jelszavakat!
Ezek után indítsuk újra az sshd-t az /etc/init.d/ssh restart paranccsal. Teszteljük le az új beállításokat és próbáljunk bejelentkezni másik gépekről a szerverre. Saját RSA kulcsot az ssh-keygen paranccsal hozhatunk létre. Mindenképp válasszunk egy jó jelszót ehhez a kulcshoz is.
2.8 Szoftveres figyelő (“watchdog”) beállítása
Ha a rendszerünket pl. DoS támadás éri, akkor nagyon nagy terhelésnek lesz kitéve. A CPU terhelési mutatója 25 fölé is mehet. Ez esetben jobb, ha a rendszer újraindítja magát, ezzel újra életképessé téve önmagát - és persze a DoS támadást is hatástalanítja egy időre ilyenkor. A rendszer terhelésének monitorozására sokféle hardverkártyás megoldás is van, melyek sokkal hatékonyabbak, mint az ingyenes szoftveres megoldás: ha a rendszer teljesen lefagy, akkor is újra indítja a hardverkártya. Ha belefér a keretbe, vásároljunk egy Linux-kompatíbilis (lásd: kernel dokumentáció) hardverkártyát. Ha nincs rá lehetőségünk a kernel lehetőséget ad szoftveres terhelésfigyelésre is. A watchdog csomag tartalmaz egy azonos nevű démont, mely elég jól testre szabható és működik a kernel által támogatott összes hardveres és szoftveres megoldással is. A man watchdog és a man watchdog.conf parancsok segítségével olvassuk el a dokumentációt.
A program segítségével rengeteg mindent lehet monitorozni, pl.:
- a rendszer terhelése az elmúlt 1, 5, 15 percben nem ment-e adott értékek fölé
- egy általunk beállított memória mennyiség szabad-e
- a rendszer hőmérséklete elérte-e a határszintet (csak hardverkártyák esetén)
- egy adott fájlba tud-e írni, vagy azon történt-e változás (pl. naplófájlok)
- fut-e az adott szerverprogram (PID-fájlon keresztül)
- él-e a hálózaton valamely gép vagy tartomány (ping)
- egy adott hálózati interfészen van-e forgalom (eth)
A program segítségével saját teszt-program és helyreállító / leállító program futtatható. Ha leállítás vagy újraindítás történt, akkor e-mail-ben értesíti az adott személyt. Szerkesszük meg tehát az /etc/watchdog.conf fájlt:
admin rgazda@gyakranolvasom.hu
max-load-1 = 24 # 24-es terhelésnél indítson újra
max-load-5 = 18
max-load-15 = 12
watchdog-device=/dev/watchdog # ez a kernel eszközvezérlője
Igény szerint adjuk meg saját opcióinkat is. Indítsuk újra a démont: /etc/init.d/watchdog restart
Figyelem! Ha esetleg 2.3.x vagy 2.4.x sorozatú kernelt használunk, ne lepődjünk meg, ha váratlanul, minden ok nélkül újraindul a rendszer, mert a watchdog programot még nem hangolták az új kernelekhez. Ez esetben inkább távolítsuk el a programot.
2.9 E-mail titkosító kulcspárok létrehozása a “gpg” programmal
A következő fontos feladat: saját kulcspár létrehozása mindkét gépen a gpg (GNU Privacy Guard) segítségével. Ez azért fontos, mert ha e-mail-jeinket lehallgatják, sok mindent megtudhatnak a szerverről. Pl. ha a naplófájlokat kódolatlanul továbbítjuk, bárki elkaphatja és elolvashatja azokat. A nyilvános kulcsú titkosítási eljárást nem részletezem, túlmutat a témán. Nézzünk utána, pl. a [12. p. 185.], vagy a GPG dokumentációjában.
Ha még nem telepítettük, telepítsük mindkét gépre a gnupg csomagot. A pgp-vel való kompatibilitás miatt van néhány kiegészítő csomagja is gpg-* néven. Ha szükség van rá, telepítsük ezeket is. Olvassuk el a dokumentációt.
Első lépésként a rendszergazda gépén készítsünk egy kulcspárt: Az alábbi paranccsal indíthatjuk az interaktív folyamatot:
rgazda@rgazdagepe:~]#gpg --gen-key
gpg (GnuPG) 1.0.1; Copyright (C) 1999 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Válasszuk ki, milyen kódolási algoritmusokat használjunk (1)
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) ElGamal (sign and encrypt)
Your selection? 1
DSA keypair will have 1024 bits.
About to generate a new ELG-E keypair.
Válasszunk legalább 2048 bites kulcsot, de a 4096 bit az ajánlott méret, mivel ezt már tényleg nehéz feltörni (gondoljunk a jövő gépeire is!).
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024) 2048
Do you really need such a large keysize? y
Requested keysize is 2048 bits
A kulcs érvényessége ne járjon le. Bár javasolt legalább évente újat létrehozni.
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct (y/n)? y
Itt megadjuk a felhasználó nevét és e-mail címét.
You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) "
Real name: Kis Jozsef
Email address: rgazda@gyakranolvasom.hu
Comment:
You selected this USER-ID:
"Kis Jozsef "
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
Adjunk meg kétszer egy jó és biztonságos jelszót, majd jegyezzük fel valahova, ahol megtaláljuk, mert úgyis el fogjuk felejteni.
You need a Passphrase to protect your secret key.
Enter passphrase:
Ezután a gép elkezdi legenerálni a kulcsokat, ez elég sokáig is eltarthat, ha lassú a gépünk. Jobb, ha minél gyorsabb gépen végezzük el ezt. Arra kér, hogy mozgassuk az egeret, vagy tegyünk valamit, hogy minél jobb entrópiát hozhasson létre. Jelentkezzünk át egy másik terminálra és csináljunk valami hasznosat.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
..+++++++++++++++...++++++++++.+++++.+++++....+++++++++++++++....
Amint kész a folyamat, exportáljuk ki a kulcsot egy szövegfájlba:
gpg --export -a -u Kis -o kisjozsi.gpg.txt
Ezután a szerveren is generáljunk egy kulcspárt a root számára (root@alfa.boresszormegyar.hu). Ha ez megtörtént, akkor a szerverre vegyük fel az előbbi kiexportált nyilvános kulcsot.
[root@alfa:~/]cat kisjozsi.gpg.txt | gpg --import
Ekkor, ha minden jól ment, az olvasós e-mail címünk kulcsa felkerült a kulcscsomóra. Ennek a hasznára majd később visszatérek.
2.10 A rendszernapló (log) és kezelése
A rendszergazda számára a rendszerről az elsődleges információforrás a rendszernapló (log). Ebből tudhatja meg, hogy mi történt a rendszerén, amíg távol volt. Nagyon fontos ezt a naplót karbantartani, kezelni, olvasgatni. Ebből derülhetnek ki a betörési kísérletek is. Ha a betörő nagyon ügyes, akkor meg tudja változtatni ezeket a fájlokat. Ekkor észrevétlen maradhat a számunkra. Ezért fontos, hogy automatizáljuk a naplózási rendszerünket. Ha tehetjük (van a hálózatban egy log-szerver) akkor tükrözzük az információkat. A másik lehetőség egy régi leporellós mátrix nyomtató alkalmazása, mint másodlagos log-kimenet. Ekkor minden információ papírra kerül és ez bizonyíték értékű lehet betörés esetén. (Hátránya persze a kifogyó papír.)
Először is állítsuk be úgy a /var/log könyvtár jogait, hogy az egyéb felhasználók ne is léphessenek oda be.168 Továbbá azok a programok, melyek nem a syslog()-on keresztül naplóznak, legyen bejárásuk ide, különben el sem indulnak.
[root@alfa:/var]#chmod o-rxw log; addgrp loggers; chgrp loggers log; adduser mysql loggers; adduser www-data loggers;
[root@alfa:/var]#ls -ld log
drwxr-x--- 12 root loggers 8192 ÁPR 28 09:39 log
Ez azért fontos, hogy egy felhasználó jelszavát megszerezve ne tudjon a behatoló információkat szerezni a rendszerről. Ekkor viszont vigyáznunk kell, mert azok a programok, melyek nem a syslog()-on keresztül naplóznak és nem root-ként futnak, nem tudnak majd hozzáférni a napló-fájljaikhoz, kivéve, ha hozzá nem adjuk őket a loggers csoporthoz.
2.10.1 A “syslog” démon kiválasztása
A Potato-ban két syslog démon közül választhatunk. Az első a hagyományos syslogd. Ezt eredetileg a BSD-ből hozták át. Ez a rendszer található szinte minden UN*X típusú rendszeren. A másik lehetőség az új, magyar fejlesztésű syslog-ng (New Generation). Ez sokkal korszerűbb, a mai igényeknek megfelelően kialakított, már stabil állapotú, könnyen konfigurálható program. Egy fiatal magyar programozó fejleszti, Scheidler Balázs, GPL licensz alatt. Ez szinte minden UN*X típusú rendszer alatt használható. Az én javaslatom, hogy ezt válasszuk előnyei miatt. (Bővebb információként nézzük meg a dokumentációt.) A továbbiakban erre fogok hivatkozni. A Debian-ban a syslog-ng alapból megfelelően be van konfigurálva, hacsak nem akarunk log-szervert használni. Egyedi kívánságokért nézzük át a konfig’ állományokat.
2.10.2 A naplófájlok rotálásának beállítása
A rendszernapló a használat során egyre csak duzzad, s ha nem töröljük le időnként, akkor teljesen be fogja tölteni a /var partíciót. Ennek a kiküszöbölésére írták a logrotate programot. Megfelelő beállítás után időközönként átnevezi a naplófájlokat, megszámozza őket és megtart annyit, amennyit meghatároztunk neki, a többit pedig letörli. Állítsuk be az /etc/logrotate.conf-ot a következőképp:
# először olvassuk el a logrotate manuál oldalát!
# az itt található beállítások globálisak, majd
# külön-külön minden fájlra definiálhatunk szabályokat
# ------------------- Globális
# a naplófájlokat naponta rotáljuk
daily
# 14 napot megtartunk, azután töröljük. (minél több megmarad, annál jobb a biztonság
# szempontjából, de annál rosszabb a hely szempontjából.)
rotate 14
# a hibákat ide küldje
errors rgazga@gyakranolvasom.hu
# új üres naplófájlok létrehozása rotálás után, megadható, hogy milyen jogokkal
# keletkezzen az új és ki legyen a tulajdonosa: create mód tulaj csoport
create 027 # ekkor a “többiek” számára nem lesz olvasható
# a rotált log-okat letömörítjük, hogy kevesebb helyet foglaljanak
compress
# ha üres a fájl, akkor ne forgassuk
noifempty
# egyes csomagok ebbe az alkönyvtárba teszik a logrotate-ra tartozó információkat
# ezért azokat így érvényesítjük.
include /etc/logrotate.d
# ide küldje el kódoltatlanul a rotált naplókat:
# mail rgazda@gyakranolvasom.hu
# Ezt kihagyjuk, mert egy script segítségével kódolva fogjuk küldeni a naplókat.
# Ha túlságosan kényelmetlennek találja az olvasó a dekódolást, és nem fél attól,
# hogy a naplóit elolvassák, akkor válassza a hagyományos módszert.
# mivel ezt a két fontos fájlt egyik csomag sem birtokolja ezért a részletes
# beállításaikat it közöljük (lokális)
/var/log/wtmp {
weekly
create 0664 root utmp
rotate 2
}
/var/log/btmp {
missingok
weekly
create 0664 root utmp
rotate 2
}
#Ezt a részt átveszem a /etc/logrotate.d/syslog-ng fájlból és kiegészítettem.
# A syslog-ng-t újra kell indítani a rotálás után.
/var/log/syslog
{
postrotate
/etc/init.d/syslog-ng reload >/dev/null
# mivel a syslog fájl mindig telik, ez a script mindig le fog futni
# itt elindítjuk a titkosító scriptünket:
/bin/bash /root/logtit.sh
endscript
}
# ha ezt nem tesszük meg, a syslog továbbra is a törölt fájlba fogja küldeni
# az információkat és azok így elvesznek, továbbá logikai lemezhibát okozhatnak.
# Frissítések során ne engedjük ezt a fájlt felülírni!
Ezután rm -f /etc/logrotate.d/syslog-ng
touch /etc/logrotate.d/syslog-ng
Frissítések során ne engedjük ezt a fájlt felülírni!
Ez a kis shell-script kódolja és postázza a rotált log-okat. Mentsük ezt a fájlt /root/logtit.sh néven.
PATH=$PATH:/bin:/usr/bin # Beállítjuk az elérési útvonalakat.
umask 077 # Csak a root tudja olvasni a keletkező fájlokat
cd /var/log # Belépünk
rm -f naplok.tar.gz 2>&1 /dev/null # Ha esetleg lenne még itt ilyen fájl, töröljük
DATUM=`date +%Y.%m.%d-%H.%M` # A mai dátum
tar -czf naplok.tar.gz *.0* # Minden épp most rotált fájlt elcsomagoljuk,
cat naplok.tar.gz | gpg -e -a -q -r rgazda@gyakranolvasom.hu \
| mail -s naplorotalas-$HOSTNAME-$DATUM rgazda@gyakranolvasom.hu
rm -f naplok.tar.gz # # titkosítjuk és postázzuk. Végül töröljük az átmeneti fájlt.
2.10.3 A Web-szerver naplófájljai
A cronolog program a hosszú Web-szerver naplófájlokat szét tudja szedni adott minta szerint. Ez pl. akkor előnyös, ha a log-okat megőrizzük és eltároljuk kompakt lemezen napi bontásban. A program hátránya, hogy minden naplófájlhoz külön folyamatot indít, ezért nagy forgalmú helyeken nem ajánlott használni, ugyanis nem utólag, hanem folyamatosan válogatja szét az érkező üzeneteket. Ha beírjuk ezt a sort a httpd.conf-ba:
CustomLog “|/usr/sbin/cronolog /var/log/apache-ssl/access.%Y-%m-%d.log” combined
akkor ilyenforma fájlokat kapunk: access.2000-05-13.log Minden log-fájlt hasonlóképp kezelhetünk.
2.10.4 A napló automatikus ellenőrzése
A logcheck program nagyon hasznos lehet számunkra. Az időzítő (cron) indítja el időközönként. Ez a program leellenőrzi a rendszer naplófájljait az előre megadott szűrők szerint (melyeket persze testre szabhatunk) és az eredményt elküldi a kért e-mail címre. Ha a szűrők megfelelnek nekünk (/etc/logcheck/*), akkor semmi más tennivalónk nincs vele, mint az /etc/logcheck/logcheck.conf fájlba beírni ezt: SENDMAILTO=rgazda@gyarkranolvasom.hu. Ekkor a betörési kísérletekről, biztonságot veszélyeztethető és / vagy szokatlan eseményről értesít a rendszer (mint pl. valaki root-ra su-zott.) Ha esetleg olyan tevékenységet is ebbe a kategóriába vesz, melyet nem tartunk veszélyesnek, akkor olvassuk el a dokumentációt és hangoljuk be a szűrőket igényeink szerint.
A probléma a módszerrel az, hogy egyrészt kódolatlanul küldi el a levelet, másrészt pedig nem tömöríti le, és ekkor sokáig tarthat a levél letöltése. Ha szeretnénk ezeket a problémákat megoldani, akkor hajtsuk végre a következő lépéseket:
- Másoljuk az eredeti programot le két példányba:
cp /usr/sbin/logcheck.sh /root/logcheck.sh.orig
cp /usr/sbin/logcheck.sh /root/
- Szerkesszük át a fájlt: pl. joe /root/logcheck.sh
[…]
# If there are results, mail them to sysadmin
if [ "$ATTACK" -eq 1 ]; then
# Ha vészriadó van, nem kódoljuk le a levelet, hogy gyorsan el tudjuk olvasni
cat $TMPDIR/checkreport.$$ | \
$MAIL -s "$HOSTNAME $DATE A RENDSZER OSTROM ALATT! ACTIVE SYSTEM ATTACK!" $SYSADMIN
elif [ "$FOUND" -eq 1 ]; then
# Viszont, ha csak valami gyanúsat talált, akkor azt kódoljuk.
cat $TMPDIR/checkreport.$$ | /bin/gzip - | \
/usr/bin/gpg -e -a -q -r $SYSADMIN | \
$MAIL -s "$HOSTNAME $DATE rendszerellenőrzés - system check" $SYSADMIN
fi
[…]
A $SYSADMIN változó megegyezik azzal az e-mail címmel, melyet a konfig’ fájlba írtunk. Ha ehhez az e-mail címhez nincs publikus kulcsunk (a root felhasználónak!), akkor hibaüzenettel le fog állni a kódolás.
- Másoljuk vissza az átjavított fájlt: cp /root/logcheck.sh /usr/sbin/
Ezzel kész is. Már csak arra kell figyelnünk, hogy a programot frissüléskor ne írjuk felül, vagy tegyük “hold” állapotba, ekkor nem fog frissülni.
Az üzenetek kicsomagolásához is használhatunk egy kis script-et (írjunk egyet). A kedvenc levélolvasó programunkból mentsük ki a levél tartalmát egy fájlba, pl. kodolt.txt néven. Ez a művelet interaktivitást igényel, meg kell adnunk a visszakódoláshoz szükséges jelszónkat.
cat kodolt.txt | gpg -d | gunzip - > visszakodolt.txt
less visszakodolt.txt
2.11 A Web-szerver statisztikái
A webalizer programmal szép grafikákkal tűzdelt HTML-es statisztikákat készíthetünk a Web-szerverünk forgalmáról, melyeket azonnal közzé is tesz a Weben (persze csak ha akarjuk). Előszöris szerkesszük meg az /etc/webalizer.conf fájlt:
LogFile /var/log/apache-ssl/szormegyar-access.log
HostName www.szormegyar.hu
OutputDir /var/www/szormegyar/webstat
ReportTitle Jelentés
Quiet yes #ha cron-ból futtatjuk, akkor ne szövegeljen
A többi beállítás általában jó, de azért olvassuk végig. Ajánlatos az access.conf-ban azonosításhoz kötni a /var/www/szormegyar/webstat könyvtár tartalmát, hogy csak az illetékes személyek tekinthessék azt meg. A program kimenetét nagymértékben testre szabhatjuk. Olvassuk el a dokumentációt. A különböző virtuális szerverek forgalmát külön mérhetjük (ekkor a log formátumát is meg kell változtatni). Létrehozhatunk külön konfigurációs fájlokat minden egyes virtuális szervernek (külön a HTTPS forgalomnak is). Ezekre bővebben nem térek ki.
A programot futtathatjuk az időzítőből is, megfelelően kell csupán paraméterezni. Ez esetben a rendszer magától frissíti pl. naponta, vagy óránként a statisztikáit. Érdemes belemélyedni, ha szükségünk van a forgalom mérésére.
A webalizer ehhez hasonló grafikákat készít:
18. kép - Webalizer statisztika
Ha az időzítőből szeretnénk futtatni, tegyünk egy bejegyzést. /etc/crontab:
58 06 * * * www-data webalizer >/dev/null
Ha külön szeretnénk mérni az egyes virtuális szerverek forgalmát, készítsünk külön konfig’ fájlt és indítsuk el mindegyikkel egyszer-egyszer.169 Ahhoz, hogy magyarul készítse el a statisztikákat, újra kell fordítani.
A másik kitűnő eszköz az analog programcsomag. Szintén HTML-es kimenete van, néhány grafikával megtűzdelve. Itt is érdemes elolvasni a dokumentációt, mely HTML-es formátumú. Itt kiderül milyen sok platformon életképes a program, továbbá megtanulhatjuk a használatát és a szintaxisát. Mivel szorosan nem kapcsolódik a témához, nem részletezem. Ez a program is automatizálható az időzítővel. Előnye, hogy teljesen magyar nyelvű jelentést is tud készíteni, ha beírjuk ezt a sort az /etc/analog.conf-ba:
LANGFILE /usr/lib/analog/lang/huh.lng
Ha szükségünk van az oldalon megjelenő látogató-számlálóra, telepítsük a wwwcount csomagot, mely (teljes dokumentációval ellátott) számláló program. Beállítását itt nem részletezem.
2.12 Az “upsd” beállítása
Mivel erősen függ a hardvertől az, hogy melyik csomagot fogjuk használni, ezért ebbe a témába sem merülhetek el teljességgel.
A példában szereplő géphez egy APC Smart -BackUPSPro PnP eszközt vásároltunk, melyet az első soros portra illesztettünk (/dev/ttyS0). Ennek megfelelően az apcupsd programot telepítettem.
Szerkesszük meg az /etc/apcupsd.conf-ot. Adjuk meg az UPS típusát, a kábel típusát, és a portot. Mivel csak ezt az egy gépet szolgálja ki a tápegység, nincs szükség hálózati beállításokra. A tápegység állapota akár Web-es felületen is lekérdezhető. Mindenképp végezzük el a finomhangolást a dokumentáció elolvasása után. Ha lehet, állítsuk be a démont úgy, hogy hiba esetén e-mail-t küldjön címünkre.
2.13 A biztonsági mentés időzítése
Én a mentéshez a kbackup csomagot választottam. Egyrészt jól dokumentált (külön csomag), másrészt egyszerűen használható mind szalagos, mind floppy-s mentésekhez. Ha telepítettük a dialog csomagot, akkor a make menuconfig-hoz hasonló könnyen kezelhető menüs programot kapunk. A különböző partíciókat érdemes külön-külön menteni. Minden mentéshez egyedi beállításokat menthetünk el, melyeket később újra fel lehet használni. A Schedule menüpontban beállíthatjuk az automatikus időzítéseket is. Olvassuk el a dokumentációt és állítsunk be mindent a tervek szerint. Készítsünk próbamentéseket és visszaállításokat egy üres partícióra.
2.14 A szükséges felhasználók/csoportok létrehozása és a lemezkvóták beállítása
A felhasználói számlák kreálásának alapszabályai az /etc/adduser.conf170 fájlban találhatóak. Tudnunk kell, hogy alapbeállításban minden felhasználó létrehozásakor egy azonos nevű csoport is keletkezik, melybe az illető természetesen bele fog tartozni. Ez sok felhasználó esetén nem jó eljárás, de esetünkben még megfelel. (Ha nekünk ez mégse felelne meg, akkor a fenti állományban állítsuk a USERGROUPS=yes értékét no-ra.) Az az általános eljárás, hogy létrehoznak egy általános users csoportot. Ennek a jogait és korlátait (kvótáit) minden felhasználó örökli keletkezéskor. Ezen túlmenően specifikus csoportok is létrehozhatóak, melybe később fel lehet venni a megfelelő illetőket.
Ha már létrehoztunk egy sablont és annak beállítottuk a kvótáit, akkor a QUOTAUSER=”sablon” sorral ezt kiterjeszthetjük az összes ezután keletkező felhasználóra.
Minden olyan fájlt (pl. a “.”-al kezdődő “rc” fájlokat171) helyezzünk el az /etc/skel könyvtárban, melyet az új felhasználók meg kell, hogy kapjanak. (A programok alapbeállításait.)
A kvóták beállításához először olvassuk el a dokumentációt172, majd hozzunk létre egy sablonfelhasználót. Ennek a kvótáit állítsuk be a kívánt értékre az edquota -u sablon (Itt a program behívja a vi szövegszerkesztőt, hacsak az EDITOR környezeti változóban ezt át nem definiáltuk. Ha nem találja a szövegszerkesztőt, akkor hibaüzenettel leáll.) (1 block= 1024 bytes)
Quotas for user sablon
/dev/hda6: blocks in use: 4, limits (soft = 2000, hard = 4000)
inodes in use: 5, limits (soft = 500, hard = 1000)
Később külön-külön is szabályozhatjuk a kvóták határait az egyes felhasználókra. Járjunk el hasonlóképp a többi kvótát igénylő partíció esetén is.
A tervek szerint hozzuk létre a felhasználókat az adduser fnév paranccsal173. Kérjünk mindenkitől egy jelszót, amit most megadhatunk, és amelyet nekik rögtön meg is kell változtatniuk a passwd paranccsal (vagy találjunk ki mi magunk valamit, esetleg a jelszógeneráló programokat használjuk fel). Felhasználót a userdel fnév paranccsal törölhetünk.
Csoportokat az addgroup paranccsal hozhatunk létre. Felhasználót a csoportba adduser fnév csoport paranccsal adhatunk. Egy adott csoport tagjait kilistázhatjuk a members csoport paranccsal (ha telepítettük).
Egy részletesebb leírást találhatunk a felhasználók / csoportok létrehozásának technikájáról itt174.
2.15 A “/etc/fstab” és az “init script”-ek beállítása
Ha úgy véljük, hogy a rendszer kész, szerkesszük meg az /etc/fstab fájlt, hogy a különböző partíciókra korlátozásokat vezessünk be a terveink szerint. Előszöris mentsük el az eredetit fstab.rw néven: cp /etc/fstab /etc/fstab.rw A kedvenc szövegszerkesztőnkkel pedig tegyük meg az alábbi változtatásokat:
# /etc/fstab: statikus file-rendszer információk. # #
/dev/hda3 / ext2 defaults 0 1
/dev/hda2 none swap sw 0 0
proc /proc proc defaults 0 0
# Vedd ki a kommentből a következő sort, ha 2.2.x vagy újabb kernelnél
# UNIX98-szerű pty kezelést szeretnél
none /dev/pts devpts gid=5,mode=620 0 0
#/dev/fd0 /floppy auto defaults,user,noauto 0 0
#/dev/cdrom /cdrom iso9660 defaults,ro,user,noauto 0 0
/dev/hda1 /boot ext2 ro,nosuid,noexec,nodev,defaults 0 2
/dev/hda5 /usr ext2 ro,nodev,defaults 0 2
/dev/hda6 /home ext2 defaults,nosuid,nodev,noexec,usrquota 0 2
/dev/hda7 /tmp ext2 nosuid,noexec,nodev,defaults,usrquota 0 2
# /var noexec esetén nem futnak pre és postinst scriptek csomagok telepítésekor!
/dev/hda8 /var ext2 nosuid,noexec,nodev,defaults 0 2
/dev/hda9 /var/www ext2 nosuid,noexec,nodev,defaults 0 2
Ha a gyökér partíciót ro-ban szeretnénk használni, először bele kell nyúlnunk az init fájlokba, mivel azok oda írni akarnak. Bizonyos indító script-eket át kell szerkesztenünk, és módosítani kell minden /etc/*-ra való fájlműveletet /var/*-ra
A következő fájlok érintettek: /etc/motd, /etc/nologin, /etc/nologin.boot /etc/mtab, /etc/adjtime, /dev/MAKEDEV, /dev/log és ezeket kell módosítanunk: /etc/init.d/checkroot.sh, /etc/init.d/bootmisc.sh, /etc/init.d/rmnologin, /etc/init.d/hwclock.sh, /etc/init.d/makedev, /etc/syslog-ng/syslog-ng.conf, /etc/default/rcS
Az /etc/mtab fájl tárolja azt a listát, hogy melyik partíció hogyan van felfűzve a rendszerbe. Szerencsére a 2.2-es kernelektől kezdve létezik egy /proc/mounts fájl, mely ugyanezeket az információkat tartalmazza175. Így nem lesz szükség az mtab-ra.
rm -f /etc/mtab
ln -s /var/mtab /proc/mounts
/etc/init.d/checkroot.sh:
[…]
# elméletileg ez csak akkor indul el, ha a / rw-ben van. Azért szedjük ki, mert
# elpiszkálja a szimbolikus linkünket.
if [ "$mode" = rw ]
then
rm -f /var/nologin #/etc/mtab~
#: > /etc/mtab
[…]
A nologin fájl arra szolgál, hogy amíg a rendszer indulási, vagy leállási folyamatban van, ne lehessen bejelentkezni. A fájlt ha áthelyezzük, a programoknak ugyanúgy észre kell vennie:
ln -s /var/nologin /etc/nologin
ln -s /var/nologin.boot /etc/nologin.boot
A nologin problémát kiküszöbölhetjük úgy is, ha az /etc/default/rcS fájlba ezt írjuk: (Ez viszont nem javasolt.)
DELAYLOGIN=no
A motd (Message of the day, a napi üzenet) problémáját így oldjuk meg:
mv /etc/motd /var; ln -s /var/motd /etc/motd
/etc/init.d/bootmisc.sh
[…]
if [ "$DELAYLOGIN" = yes ]
then
echo "System bootup in progress - please wait" > /var/nologin
cp /var/nologin /var/nologin.boot
fi
[…]
# Update /etc/motd.
#
if [ "$EDITMOTD" != no ]
then
uname -a > /var/motd.tmp
sed 1d /var/motd >> /var/motd.tmp
mv /var/motd.tmp /var/motd
fi
[…]
/etc/init.d/rmnologin:
[…]
if [ -f /var/nologin.boot ]
then
rm -f /var/nologin /var/nologin.boot
fi
[…]
Vagy a motd problémát kiküszöbölhetjük úgy is, ha az /etc/default/rcS fájlba ezt írjuk:
EDITMOTD=no
Az /etc/adjtime fájl tárolja a hardver idő-beállításait.
mv /etc/adjtime /var/adjtime
ln -s /var/adjtime /etc/adjtime
/etc/init.d/hwclock.sh:
[…]
start)
if [ ! -f /var/adjtime ]
then
echo "0.0 0 0.0" > /var/adjtime
fi
[…]
Az /etc/init.d/makedev script feladata biztosítani azt, hogy a /dev/MAKEDEV egy szimbolikus link legyen az /sbin/MAKEDEV fájlra. Erre nincs szükségünk, ezért írjunk exit 0-át a script első sorába.
A következő probléma az, hogy a syslog-ng induláskor megnyitná a /dev/log fájlt. Persze ez esetünkben nem lehetséges.
/etc/init.d/syslog-ng stop
mv /dev/log /dev/log1; ln -s /var/run/log /dev/log;
/etc/syslog-ng/syslog-ng.conf:
source src { unix-stream(“/var/run/log”); internal(); };
/etc/init.d/syslog-ng start
Ha mindent elrendeztünk és leellenőriztünk, adjunk ki egy sync parancsot, majd egy reboot-ot176. Újrainduláskor figyeljük meg a hibaüzeneteket (ha vannak). A modulfüggőségeket nem fogja tudni a rendszer újra elkészíteni, de ez nem is baj. A shift-pageup billentyű kombinációval visszalapozhatunk a képernyőn. Ha később változtatni akarunk valamit, a mount / -o remount,rw paranccsal újra felfűzhetjük az adott partíciót írható módban.
A fenti fájlok letölthetőek: http://w3.externet.hu/~narancs1/ro-root-0.1.tgz
2.16 A “tripwire” program beállítása és használata
A tripwire program egy fájlintegritás ellenőrző segédeszköz. Miután minden működik és teljesen készretettük a rendszert, beleértve az összes beállítást és tesztet, készítünk egy adatbázist, mely a fontos fájlok és könyvtárak méretét és jogosultágait eltárolja MD5-ös algoritmust használva. A tripwire-t később az időzítőből futtatva összehasonlítathatjuk a fájlok állapotát az adatbázisban tároltakkal. Ekkor a program levelet küld nekünk, hogy változott-e valami. Ha változott, akkor vagy kompromittálták a rendszert, vagy mi magunk csinálhattunk valamit. Az adatbázis részeit igény szerint frissíthetjük is.
A dokumentáció és a manuál oldal177 elolvasása után szerkesszük meg az /etc/tripwire/tw.config fájlt.
[…]
/ R # ezek a partíciók jobb esetben ro-ban vannak
/usr R # tehát ezekről készítünk lenyomatot, mert nem
/boot R # szabad, hogy változzanak
/dev @@DEVSEARCH # speciális keresést kap
=/home # ezek egy minimális tesztet kérünk
=/tmp @@TMPSEARCH
=/var/tmp @@TMPSEARCH
!/mnt # ezeket nem kell ellenőrizni
!/floppy
!/cdrom
!/var
!/var/www
!/usr/doc # ezeket a fájlokat nem szükséges ellenőrizni
!/usr/share/doc # de ha valakinek ez is fontos, akkor vegye ki innen
!/usr/dict # a “!” jelet és ellenőriztesse.
!/usr/info
!/usr/man # a többi beállítást hagyjuk meg.
[…]
Ahhoz, hogy az változásokat nyomonkövessük, a rendszer időzítője mindennap lefuttatja az ellenőrzést. Szerkesszük meg az /etc/cron.daily/tripwire fájlt:
#!/bin/sh
cd /var
# hol az adatbázis? Lehet törömített is.
DATABASE="/root/databases/tw.db_`hostname`"
DATABASEGZIP="/root/databases/tw.db_`hostname`.gz"
LOG=/var/log/tripwire
# hova köldjük a levelet?
MAILTO=rgazda@gyakranolvasom.hu
[…]
# if the temporary file is empty do not send mail
# azt akarjuk, hogy ha nincs változás ne küldjön levelet,
[ ! -s $LOG -o -z "$MAILTO" ] && exit 0
# ha mindig szeretnénk levelet kapni, akkor kommentezzük ki.
# ha gondoljuk, írjuk át a levél szövegét magyarra:
(cat <<EOF;
This is an automated report of possible file integrity changes, generated by
the Tripwire integrity checker.
Ezt egy automatikusan készülő levél, mely a lehetséges fájlintegritás-változásokat
tartalmazza, és melyet a Tripwire program készít.
Changed files/directories include:
A megváltozott fájlok / könyvtárak listája:
EOF
cat $LOG
) | /usr/bin/mail -s "Fájl integritás-jelentés - File integrity report" $MAILTO
Ha úgy gondoljuk, hogy ezt a levelet is kódoltan szeretnénk megkapni, akkor módosítsuk az utolsó sort:
) | /bin/gzip - | \
/usr/bin/gpg -e -a -q -r $MAILTO | \
/usr/bin/mail -s "Fájl integritás-jelentés - File integrity report" $MAILTO
Ha nem szeretnénk a gzip-el bajlódni, hagyjuk ki. Nem biztos, hogy olyan hosszú levelet fog készíteni.
Ha ez kész a tripwire -initialize paranccsal készíthetjük el az adatbázist. Az adatbázis eredetileg a ./databases könyvtárba kerül, ezért tanácsos a /root könyvtárban állnunk. Persze itt nem biztos, hogy jó helyen van. Mindenképp mentsük ki egy példányban floppy-ra (tömörítve). Ezt a lemezt helyezzük biztonságba. Ha a rendszert kompromittálták, lehet, hogy az adatbázist is elérték. Ekkor elővehetjük a lemezt és az ellenőrzést ez alapján is elvégezhetjük.
Ha később szeretnénk változtatásokat felvinni az adatbázisba, akkor az -interactive kapcsolóval indítsuk. Az integritás ellenőrzésekor elkészít egy új adatbázist és azt hasonlítja össze a régivel. Ezért írható könyvtárban kell indítani. Paraméterként adjuk meg neki az adatbázist a -d adatbázis kapcsolóval. Frissítés után mentsük el az új adatbázist is lemezre.
Ezután végezzük el a gyökérpartíció újrafelfűzését ro módban.