II. ALAPFOGALMAK

- 1. A GNU projekt, a GPL licensz
- 2. A Linux kernel
  - Néhány technikai jellegű információ
  - Nemzetközi változat
- 3. A Debian projekt
  - Mire jó egy terjesztés?
- 4. Az Apache projekt, az Apache moduljai
- 5. A Web-szerver helye a hálózatban (Internet/intranet)
- 6. A Web-személyzet felépítése
- 7. Web-proxy fogalma és helye a hálózatban
- 8. Biztonsági alapok (hardver, szoftver)
  - 8.1 Általános irányelvek
  - 8.2 A Linux kernel biztonságát növelő projektek
  - 8.3 A Web-alkalmazások biztonsága
- 9. SSH - Távoli menedzsment
- 10. PHP3 alapok (dinamikus Weblap-készítés)
- 11. MySQL alapok (adatbázis szerver)

##
II. Alapfogalmak

Ahhoz, hogy munkához tudjunk látni, szükségünk van néhány UN*X-os és Linux-os és operációs rendszerekhez kapcsolódó alapfogalomra. Ehhez ad segítséget Kósa Attila írása11 is. Mivel ez a kérdés is igen terjedelmes kifejtést követelne, ezért elhagyom és inkább a téma fővonalára összpontosítok, feltételezve, hogy az olvasó már rendelkezik ezekkel az alapfogalmakkal. Kezdőknek ajánlom a [14] [15] [30] könyveket, és a sysadmin-guide csomagot12, mely az LDP13 részeként írt Kezdő Rendszeradminisztrátorok Kézikönyve. A TCP/IP működésével kapcsolatban olvassuk el Scheidler Balázs írását14. Ajánlom továbbá a függelékben szereplő szómagyarázatok áttekintését.
Fontos kiemelnem, hogy legtöbb hiba és félreértés abból ered, hogy a kezdő rendszergazda más, nem UN*X alapú rendszerekhez szokva nem tudja, hogy itt a sorrend a következő:

1. Olvasd el a dokumentációt (/usr/doc könyvtár alatt lévő fájlok, manuál oldalak)

2. Ha még ezután sem érted, akkor olvasd el a FAQ-kat15

3. Ha ez se segít, látogasd meg az adott program Web-helyét és kutass új dokumentációkért.

4. Ha már végképp nem értesz valamit, akkor kérdezz meg profikat a helyi Linux-os, és / vagy az adott programhoz tartozó saját levelezőlistákon.

5. Csak miután a témát már megértetted, akkor kezdj neki a program beállításának / éles használatának.

A legtöbb hiba abból ered, hogy az emberek feltelepítik a programokat és aztán azt hiszik, hogy eddigi nem UN*X-os tapasztalataik alapján tudni is fogják kezelni. Ezután pánikba esnek, hiszen valami nem úgy megy, ahogy kellene, a rendszer pedig már élesbe van állítva. Ekkor gyorsan írnak egy haragos hangvételű levelet egy listára, hogy ez meg az nem megy. Persze általában - a dokumentáció ismeretében - a megoldás triviális. (Ezért sokszor válaszképp, csak annyit kap, hogy "RTFM"16.)
Summa summarum, a szerver operációs rendszereket szakembereknek készítették és nem átlagos felhasználóknak. A kezdő legyen türelmes. Pár napon belül úgyis rájön mennyi mindent nem tud még a rendszeréről.

##
1. A GNU projekt, a GPL licensz

A GNU projekt (és a Free Software Foundation) szabad szoftvereket fejlesztő programozókat fog össze. Ezek az emberek általában nem főállásban, csupán "hobbiból" írják meg ezeket a programokat. Azért teszik ezt, mert megunták, hogy a kereskedelmi programokat készítő cégektől függjenek. A GNU a szabadság ideáját közvetíti az emberek felé. Bár sokan kritizálták őket, "[...] ezek a programozók saját programjaikat továbbra is szabadon közreadták, várták mások módosító javaslatait, esetleg programrészeit, ezek közül a jobbakat beépítették az új verziókba, és így tökéletesítették programjukat. Ez többnyire jobb minőségű szoftverekhez vezetett, mint a nagy cégek korlátozott programozói gárdáinak termékei, amelyek erősen üzleti megfontolások szerint készülnek.
A sok különálló elszánt programozót szerette volna Richard M. Stallman összefogni az 1980-as évek első felében azzal, hogy megalapította a »Free Software Foundation«-t (FSF, Szabad Szoftver Alapítvány), és elindította a »GNU project«-et. Előbbinek elsődleges célja, hogy alapítványként adományokat fogadhat el, amelyekből gépparkot tarthat fenn és fizethet a programozóknak, utóbbi magát a programozási munkát hivatott koordinálni. A GNU project alapvető célja, hogy egy teljesen szabadterjesztésű programokból álló, UNIX-szerű rendszert hozzon össze."17
A GNU projekt célja tehát egy szabad forráskódú és ingyenes UN*X klón kifejlesztése. Mindez az Internet széleskörű elterjedésével lehetővé vált, ui. nem kell már se a székház, se a számítógépek, mert mindenki otthonról, a világ minden tájáról dolgozhat és segítheti a GNU projektet. Sok ember bár hivatalosan nem tagja a szervezetnek, de GNU/GPL licensz alatt adja ki a programjait, ezzel is támogatva a szabad szoftver közösséget.
Hogy mi is az a UN*X? - kérdezheti az olvasó, hiszen egyre azt emlegetjük, hogy a Linux az egy UN*X klón. Nos, ez általában véve kereskedelmi hálózati operációs rendszert jelent és nagyon sok fajtája van. Mivel magának a UN*X-nak is igen terjedelmes történelme van, ezért ennek részletezését mellőzöm. Ezen a címen18 találhat az olvasó egy jó magyar nyelvű összefoglalót. A lényeg az, hogy annak idején a UN*X-ból nőtt ki az Internet19. A UN*X-klónok a kezdetektől (és az Internet kezdetétől) fogva hálózati operációs rendszerek, tehát kifejezetten erre a célra és nem egyedülálló személyi számítógépekre lettek kifejlesztve. Ennélfogva, ezek többfelhasználós, multitaszkos rendszerek. Bár a legősibb változatoknál még szóba sem került a biztonság - hiszen nem is volt még kiber-bűnőzés, a mai változatok nagy részét már a tervezés során a biztonságra hangolják.
Maga a GNU filozófiájának kifejtése is meghaladja e munka kereteit. Viszont ezen a címen20 magyarul olvashatjuk Richard M. Stallman gondolatait és érveit, a GNU kiáltványt. A függelékben olvasható a GNU GPL v2 licensz magyar nyelvű változata.
További információkat szerezhetünk a http://www.gnu.org, http://www.fsf.org címeken.
Az is felmerülhet az olvasóban, hogy ezek az otthon barkácsolt szoftverek mennyire megbízhatóak. Erre a kérdésre Linus Torvalds így válaszolt: ,,[...] valamikor régen megjelent egy tanulságos beszámoló egy számítógépes terhelési próbáról, amely abból állt, hogy véletlenszerű, rossz adatokat tápláltak rendszerekbe, és figyelték, mi történik velük, hány száll el közülük. Kiderült, hogy az ingyenes segédprogramok sokkal ellenállóbbak, mint a fejlesztők termékei. Hogy miért? Mert sokkal több ember dolgozott rajtuk: sokkal többen odafigyeltek arra, hogy ellenállóbbak legyenek.''[32]
A másik ellenérv az szokott lenni, hogy ami ingyen van, ahhoz nincs támogatás, nincs semmire garancia, nincs akkor segítség se. Egy GNU/Linux szoftvereket tanuló felhasználó megnyilatkozása: "Találtam magyar nyelvű levelezési listákat, ahol számomra teljesen meglepő módon, időt és fáradságot nem kímélve, segítenek a kezdő felhasználóknak. Nagyon szokatlan volt először ez a segítőkészség, és még azóta is számtalanszor tapasztalom azt a remek érzést, hogy milyen jó segítséget kapni és adni. És mindezt anélkül, hogy tudnának rólad bármit is. Szinte hihetetlen! Ez az önzetlen segítőkészség áthatja az egész Linux mozgalmat."21
Gyakori ellenérv még a dokumentáció milyensége. Minden szoftverhez részletes dokumentáció tartozik, néhány programhoz a Web-helyüket (vagy egy részét) is mellékelik. Sok dokumentáció fellelhető SGML, HTML, PDF, PS, DVI, TXT, stb. formátumokban is, melyek közül sok (pl. PDF, PS) nagyon szépen, jó minőségben kinyomtatható és máris kész a papíralapú leírás. Természetesen vannak magyar fordítások is, de ezek inkább az ún. "manual page"-ek22 fordításai és a HOGYAN (HOWTO) fájlok esetében igaz. A magyar fordítás értelemszerűen mindig elmaradhat az angol változattól. Ezért mindig az angol változat az érvényes.
A fordítók a Web-helyek fordításának is nekiláttak, pl. www.debian.hu cím alatt a www.debian.org fordítását találhatjuk.
Összegezve, véleményem szerint a jövő a szabad szoftvereké, s közöttük legjobban is a GPL licenszű programoké. Igaz sok tekintetben még nem versenyezhetnek a kereskedelmi programokkal, (pl. kezdő-felhasználók támogatása). Sokan olyan dolgokat várnak el ezektől a programozóktól, ami nem az ő feladatuk. Ezeket a programokat nem komplett számítástechnikai analfabétáknak írják, de a nagymamára ugyan ki bízna szervertelepítést. Otthoni felhasználásra még nem olyan széles körben használható, mint egyes kereskedelmi termékek (abban az esetben, pl., ha kezdőkről van szó).

##
2. A Linux kernel

A Linux egy szabadon terjeszthető (GPL) UN*X-klón rendszermag. A következő processzorokon / architektúrákon fut jelenleg (valamilyen módon és nem minden altípuson): ARM, AS/400, AP+, Apollo, DEC Alpha, MIPS, CE, ELKS (8086, 80286), mk86, MC68000 (PalmPilot), NeXT, PowerPC, SH*, PA-RISC, SGI, SUN *sparc, VAX, x86, stb.23 A Linux-ot a kézi zsebgépektől a nagy szekrénynyi (Mainframe) gépekig szinte mindenre átültették, persze mi itt kis hazánkban anyagi és piaci okokból nem férünk hozzá sok ilyen hardverhez, így ez csupán érdekesség lehet számunkra.
A Linux igazából csak egy rendszermag, mely megfelel a POSIX szabvány előírásainak. Sokan összekeverik a Linux-ot a reá épülő komplett terjesztésekkel, mint amilyen pl. a Debian is. A többi szoftver, mely a kernel segítségével futtatható akár lehet kereskedelmi licenszelésű is. Azt, hogy milyen részei vannak egy operációs rendszernek, hogy mi a rendszermag feladata, egy - ebbe a témában alaposan elmélyedő szakkönyv elolvasásával tudható meg. Ilyen pl. a [4]. Végeredményben, a könyvben én is sokszor fogok a terjesztésekre "Linux" jelzővel hivatkozni, egyszerűsítésképpen.
A Linux-ot Linus Torvalds kezdte el fejleszteni 1990-ben, egy operációs rendszerről szóló egyetemi évfolyamdolgozatával. Népszerűségét a GPL licensz biztosítja.
"Magát a Linux operációs rendszert a GNU General Public Licence védi, ugyanaz a szerzői jogi copyright, amit a Free Software Foundation fejlesztett ki és alkalmaz. Ez az engedély bárkinek lehetővé teszi, hogy terjessze vagy módosítsa a szoftvert (díjmentesen, haszon nélkül), amíg a módosításai és bővítései szintén szabadon terjeszthetők. A »szabad szoftver« kifejezés a teljes szabadságra, nemcsak a jogdíjmentességre vonatkozik." [1. p. 7. ] "A Linux legfontosabb aspektusa, hogy maguk a felhasználók fejlesztik és bővítik a maguk igényeik szerint" [1. p. 5, Matt Welsh ]
A Debian GNU/Linux 2.2 (Potato) kiadása a Linux 2.2.x-es kernelsorozatával van ellátva. A Linux kernel verziószáma a következőképpen néz ki: az első szám a Version, a második a Patchlevel, a harmadik a Sublevel és a negyedik az Extraversion (ha van). Ha a második szám páros, akkor ez egy stabil kernel, ha páratlan, akkor fejlesztői kernellel állunk szemben. Éles rendszerben csak stabil kernelt szabad használni, jelenleg a 2.2.x-est. Ez most a Potato-ban 2.2.16.24 A fejlesztői (2.3.x) változat gyorsan változik, és sokszor okoz kavarodásokat, esetleg rendszerösszeomlást is. Mire ez a mű az olvasó kezébe kerül, lehet, hogy már a 2.4-es sorozat vélhetőleg stabil lesz és a Debian Woody nevű fejlesztői változata tartalmazni fogja. A 2.4.0-testX változatok még nem számítanak stabilnak.
Néhány technikai jellegű információ
"A Linux soha nem volt 16 bites, az első perctől fogva 32 bitesnek tervezte szülőapja - Linus Torvalds. (Szülőanyjaként az Internetet szokták emlegetni.) Valódi többfeladatos működésű, egyidejűleg több felhasználót kiszolgálni képes operációs rendszer. [...] A Linux (az egyéb PC-s Unix-okhoz hasonlóan) nem használja a BIOS-t, mert a BIOS rutinjai úgy vannak megírva, hogy csak azután adják vissza a vezérlést, miután az I/O művelet befejeződött.
A fájlrendszer maximális mérete 2 TB, a maximális fájlméret 2 GB (a hivatalos kernelek még nem tudnak ennél nagyobb fájlt kezelni, de már készült patch, ami 16 TB-os fájlméretet is tud kezelni).
16 processzort támogat Intel platformon. A Linux nem csak Intel platformon képes futni, van más architektúrára írott változata is (SPARC, 64 bites SPARC, Alpha, PowerPC, MIPS, stb.). Természetesen más architektúrán is támogatja több processzor használatát, és ki is használja az általuk nyújtott teljesítményt.
A rendszer minimális hardverigénye: 80386SX 16-os processzor, 1 MB RAM és floppymeghajtó - merevlemez nélkül! Természetesen ilyen konfiguráción éppen csak működik a rendszer.
Létezik Linux 3Com PalmPilot-ra is.
A nagy méretekre is egy példa: SGI 36 processzorral, 5 GB RAM-mal, és egy másik Sparc alapú Fujitsu AP 1000 nevű számítógép 128 processzorral.
Látható, hogy nagyon széles a skála, amin a Linux elfut, és nagyszerű teljesítményt produkál. Nincsen semmilyen korlátozás a felhasználók számát tekintve, tehát maximum a hardver határolhatja be a kiszolgált felhasználók számát. A hálózati protokollok közül támogatja például az IPv6-ot.
A feladatütemezője prioritásos ütemezést használ, így különböző prioritásokat rendelhetünk a futtatandó programjainkhoz. A kernelmodulok dinamikusan betölthetők és kivehetők a memóriából [...]
A 2000. év problémája Linux alatt nem jelent gondot. Ugyanis, mint a legtöbb UNIX, a Linux is 1970. január 1-je óta számolja az időt másodpercekben. Ezt az értéket egy 4 bájtos, előjeles számban tárolja, ami csak 2038-ban fog túlcsordulni.25
A 64 bites Merced processzorra való áttérésről azt nyilatkozta Linus Torvalds, utalva az Intel nyitására a Linux felé, hogy »[...] ma már nem hiszem, hogy a Merced komoly kérdés volna. «[32]"26
Igazság szerint a Linux kernelről már könyveket írtak és ráadásul a fejlődésével egyre többet tud - egyre több információ szerezhető meg róla. A mélyebb érdeklődésűek figyelmébe ajánlom a linux/Documentation könyvtárat, mely a forráskódban található és a legfrissebb információkat tartalmazza a kernel különböző részeiről. Számunkra a kernel inkább csak addig érdekes, amíg beállítjuk, lefordítjuk és futtatjuk. Utána már akkor jó, ha "észre se vesszük", hogy létezik.
Elérhetőség:
A Linux kernel forráskódja a Linkek-ben szereplő helyekről tölthető le. Pl.: ftp://ftp.hu.kernel.org/pub/linux/kernel/v2.2/linux-2.2.17.tar.gz
Ez egy igen nagy méretű (kb. 15 MB) fájl. Lefordításához többek között szükség van a binutils, (tar, gzip), egcs/gcc csomagokra. Hogy ne kelljen minden újabb kernelverzió kiadásakor letölteni ekkora méretű fájlt, ezért elég csak a frissítést letöltenünk. Pl.: ftp://ftp.hu.kernel.org/pub/linux/kernel/v2.2/patch-2.2.18.gz
A linux kernel részeit és lefordítását bővebben később tárgyalom.
Nemzetközi változat
Az USA-ban még érvényben lévő exportszabályozások miatt a titkosító algoritmusokat tartalmazó kódok egy külön európai gépen találhatóak. Ha szükség van, pl. fájl-rendszer szintű titkosításra, akkor töltsük le a kernelverziónkhoz megfelelő foltot ("patch"-et27). A törvényi szabályozások azonban 2000-ben megváltoztak, így nemsokára már a titkosítás is belekerül a kernel nagy csomagjába.
Linkek:
http://kernelnotes.org linux kernel információk, a hivatalos kernel honlap
http://edge.kernelnotes.org a fejlesztői kernel honlapja
http://netfilter.kernelnotes.org a csomagszűrő modulok honlapja
ftp://ftp.hu.kernel.org a linux kernel hivatalos hazai ftp tükre
ftp://ftp.kerneli.org a linux kernel nemzetközi változatának ftp szervere

##
3. A Debian project

A Debian projekt28 célja egy olyan szabad szoftverekre épülő teljesen ingyenes terjesztés (vagy inkább kernelfüggetlen operációs rendszer) kifejlesztése, amely nem kereskedelmi célú és független irányító testülettel rendelkezik. Ez a rendszer nem tartalmaz semmilyen kizárólagosan kereskedelmi szoftvert. Jelenleg egy stabil (Debian GNU/Linux) és két fejlesztői változata (Debian GNU/Hurd, Debian GNU/FreeBSD) van a kernelek szempontjából.
Mit jelent ez a szó?
Mivel sokan kérdezték: a »Debian«-t »debián«-nak kell ejteni. A név a Debian alkotójának, Ian Murdocknak és feleségének, Debrának a nevéből származik."30
"Mi az a Debian?
A Debian szabad vagy nyílt forráskódú számítógépes operációs rendszer. Az operációs rendszer alapvető programok összessége, amelyek a számítógép működéséhez szükségesek. Az operációs rendszer magja a kernel. A kernel a számítógép sarkalatos programja, amely az alapfeladatokat végzi, és más programokat indít. A Debian kernelfüggetlen. Jelenleg a Linux-kernelt használja, de készülőben van a Debian más kernelekhez is, például Hurd-ra."31
A Debian GNU/Linux a következő rendszereken fut: Intel x86 ("i386"), Alpha ("alpha"), ARM ("arm"), Motorola 68k ("m68k"), MIPS, PA-RISC, Motorola/IBM PowerPC ("powerpc"), Sun SPARC ("sparc"), Sun UltraSPARC ("sparc64"),
Mire jó egy terjesztés?
Az alapprobléma az, hogy a szabad szoftverek főleg forráskód formában hozzáférhetőek az Interneten. Ahhoz, hogy összeállítsuk a rendszerünket, le kellene fordítani az összes programot és felinstallálni a célgépre. Ez rengeteg munkát igényelne. Ezért találták ki a terjesztéseket. Ezek olyan lefordított és előrecsomagolt programokkal rendelkeznek, melyek már előre be vannak konfigurálva egy adott működőképes és általános felhasználói profilra. Ezeket a beállításokat természetesen meg kell változtatnunk a saját igényeink szerint.
Fontos továbbá az is, hogy a terjesztések rendelkeznek ún. installáló / telepítő programokkal, indítólemezekkel, stb. Ezek nélkül körülményes lenne a rendszer telepítése. Tehát a terjesztés (disztribúció) az egy keret a szabad szoftverek tömegéhez, mely egy egységbe kovácsolja azokat, miután azok egysége már nyugodtan nevezhető operációs rendszernek.
Minden terjesztésnek kell, hogy legyen egy ún. csomagkezelő programja, mely az előre lefordított bináris programokat tömörített formában tartalmazó csomagokat menedzseli.
A Debian és leszármazottainak csomagkezelője a dpkg, a Redhat32 és leszármazottainak programját pedig rpm-nek nevezik. A Debian-ban is telepíthetünk .rpm formátumú csomagokat, de ajánlatos az alien nevű programmal átkonvertálni .deb formátumra. (A Debian csomagok .deb, a Redhat-osok .rpm kiterjesztésűek)
Véleményem szerint a Debian csomagkezelője sokkal fejlettebb és jobban kidolgozott rendszer, mint bármelyik másik. Néhány fontos dolog a csomagkezelőről:
"A dpkg a Debian GNU/Linux csomagjainak installálására, eltávolítására, építésére és menedzselésére alkalmas csomagkezelő. Kérhetünk információkat a csomagokról. Egy csomagnak több státusza lehet:

- installed - feltelepített és konfigurált csomag,

- half-installed - a csomag telepítése el lett kezdve, de valami miatt nincs tökéletesen feltelepítve,

- not-installed - a csomag nincs feltelepítve a rendszerre,

- unpacked - a csomag fel van telepítve, de nincs konfigurálva,

- half-configured - a csomag fel van telepítve, de nincs teljesen konfigurálva,

- config-files - a csomag már nincs a rendszeren, csak a konfigurációs fájljai vannak meg.

Egy csomag kiválasztásának három státusza lehet:

- install - kiválasztva telepítésre,

- deinstall - kiválasztva törlésre,

- purge - minden része kiválasztva törlésre, még a konfigurációs fájlok is.

(Ugyanis a ,,deinstall'' nem távolítja el a csomaghoz tartozó konfigurációs fájlokat.)
Egy csomagnak két jelzője lehet:

- hold - nem változtat a csomagkezelő az így megjelölt csomag állapotán,

- reinst-required - a csomag meg van sérülve, de nincs eltávolítva, ezért szükséges újratelepíteni."33

További fontos információk:
"Hol találok Debian-os infókat, csomaglistát, ilyesmiket?
A Debian website a http://www.debian.org címen található, de érdemes a legfelső sorban34 látható tükrözések közül a legközelebbit választani (ez az Internet kapcsolatodtól függ). A csomagok között a http://www.debian.org/packages.html címen lehet keresgélni, akár a csomag nevét a felső ablakban (a teljes nevet meg kell adni!) vagy a csomag leírásában lehet az alsóban keresni. Az aktuális hibalista csomagokra, sürgősségre vagy más szempontok szerint lebontva a http://www.debian.org/Bugs/ címen érhető el. Az angol nyelvű Debian FAQ a http://www.debian.org/cgi-bin/fom címen érhető el.
A Debian-os levelezőlistákban a http://www.debian.org/Lists-Archives/ címen lehet keresgélni . A teljes disztribúció az alábbi helyeken érhető el: [...] ftp://ftp.kfki.hu/pub/linux/debian/35, illetve ha valami probléma van akkor természetesen az ftp://ftp.debian.org címen."37
A Debian GNU/Linux különböző kiadásait verziószámokkal és kódnevekkel jelölik. Itt a magyar Debian FAQ-ból idézek: "Mik ezek a furcsa nevek: bo? hamm? ...?
Ezek a kódnevei a különböző Debian verzióknak, amíg dolgoznak rajtuk. Kiadáskor mindegyik kap egy verziószámot, de a kódnevek általában az igazi rajongók között tovább élnek (a könyvtárnevekről nem is beszélve).
A jelenlegi verziók a következők: buzz v1.1 rex v1.2 bo v1.3 hamm v2.0 slink v2.1 potato v2.2 woody v2.3 és sid ez az új architektúrák (sparc, arm, ...) gyűjtőhelye
Bruce Perens, a Debian ex-vezéralakja a Pixarnál (http://www.pixar.com/) dolgozik, akik a Toy Story című számítógéppel készült animációs filmet készítették. A jelenlegi kódnevek a Toy Story szereplői..."38
A Debian csomagkezelője kiegészül az apt nevű programmal, mely a folyamatos frissítést és a csomagok letöltését teszi lehetővé pl. az interneten lévő ftp helyekről.
Egy Debian tükör a következőképpen néz ki: a /debian könyvtár alatt találhatóak a Debian-nal kapcsolatos anyagok. Az ez alatt lévő dists könyvtár tartalmazza a Debian terjesztés különböző változatait. Pl. a potato alkönyvtár alatt a Potato változat csomagjai vannak. Itt három részre szakad licensz szerint: main (minden amit a DFSG39 szerint szabadnak minősül), a contrib ("olyan ingyenes csomagok, amik függhetnek nem ingyenes csomagoktól"40) és a non-free ("valami miatt nem ingyenes alkalmazások, általában egyéni felhasználók számára ezek is ingyenesek"41). Platform szerint megosztva vannak a bináris, és egy külön könyvtárban a forrás csomagok. Pl. binary-i386 alatt vannak az Intel processzorokra szánt változatok. Ezek alatt alszekciók találhatóak. Pl. a mail könyvtárban a levelezéssel kapcsolatos programcsomagok vannak elhelyezve.
Tehát: ftp.hu.debian.org/debian/dists/potato/main/binary-i386/mail
Ezzel nekünk általában nem kell törődnünk különösebben, az apt 42 program megtalálja egy Packages.gz nevű fájllista szerint, hogy milyen csomagok találhatóak az adott ftp tükrön. Ebből eldöntheti, hogy van-e csomagfrissítés a mi gépünkön lévő állapothoz képest. Ez a lista pontosan tartalmazza a programcsomagok relatív elhelyezkedését.
Nagyon fontos a Debian terjesztésben a dselect program. Ez egy menüs csomagtelepítő és karbantartó szoftver. Először megkérdezi azt, hogy milyen forrásból kívánjuk a csomaglistát és a csomagokat megszerezni. Ez lehet ftp, kompakt lemez, NFS43 és a kedvelt apt program is. Én mindenképp az apt használatát javaslom. Persze ha van kompakt lemezünk és az kellően friss, akkor azt is alkalmazhatjuk. (Általában a kompakt lemezeket telepítéskor használjuk, frissítésnél pedig az ftp tükröt, bár lehet telepíteni közvetlenül az ftp-ről is.)
Ha ez megtörtént, akkor megszerzi a csomaglistát. Ennek birtokában már nekikezdhetünk válogatni. Bizony, ha kezdő Linux-os felhasználók vagyunk, akkor fájhat most a fejünk, ugyanis majd 4500 programcsomag közül kell kiválasztanunk a számunkra szükségeseket. Ez akár órákig is eltarthat, ha minden csomag rövid leírását át akarjuk tanulmányozni.

##
4. Az Apache projekt, az Apache moduljai

Az Apache projekt (http://www.apache.org) célja egy olyan Web-szerver program létrehozása és karbantartása, fejlesztése, amely megfelel a gyorsan változó Internetnek, elég biztonságos és üzleti célra is megfelelő és szabadon használható. Az Apache-ot, mivel a régi NCSA44 httpd szerveréből készült, BSD licensz alatt terjesztik.45 A projektet rendszergazdák kezdték el amikor Rob McCool, az NCSA szerverének írója kilépett az NCSA-tól, és a szoftver nem fejlődött tovább.
Az Apache projekt koordinálását az Apache Group végzi. Néhány vezető és több száz fejlesztő van e mögött a szoftver mögött. Jelenleg a stabil változata 1.3.12, a fejlesztői pedig a 2.0a számot viseli. A Potato-ban jelenleg az 1.3.9-es verzió van és valószínűleg ez is marad meg, mivel ez már egy bevált, tesztelt verzió. A Woody változatban valamelyik újabb verzió lesz. Hacsak nincs valami különösebb okunk rá (pl. hibajavítás, teljesítménygondok) ne fordítsunk újabbat.46
Az Apache Web-szerver szinte minden UN*X platformra lefordítható, futtatható, de egyéb kommerciális platformokon is működik.
Az SSL bővítést Ben Laurie készítette az OpenSSL programkönyvtár segítségével. Érdemes végigtanulmányozni a /usr/doc/apache-common és a /usr/doc/apache-ssl könyvtárakban lévő dokumentációkat és szerzői jogi információkat, példafájlokat.
Néhány alapvető fogalom:
Virtualhost: Ugyanazon a gépen több virtuális Web-szerver is futhat. Pl. a www.borgyar.hu és a www.szormegyar.hu ugyanazon a szerveren van, de kintről két különböző helynek látszik. Nagyon egyszerű egy gépen akár több száz virtuális szervert futtatni. Csupán a konfigurációs állományokat kell megfelelően behangolni. Minden egyes szerver teljesen különböző formában is beállítható, azok egymástól elég különbözően is viselkedhetnek. A virtuális Web-szerverek lehetnek külön-külön IP címen (IPVirtualHosting), vagy egy azonos IP címen is (NameVirtualHosting) egy azonos gépen. Tehát elég akár csak 1 db statikus IP címet vásárolnunk és több domént bejegyeztetni. Ha minden doménnek külön IP címet veszünk, nagy forgalom esetén később szétválaszthatjuk külön gépre is a helyeket.
SSL:Secure Socket Layer, vagyis Biztonságos Csatorna Réteg. Ennek a segítségével a kliens böngészője és a Web-szerver között titkosított formában fog folyni az adatcsere, ha mindkettő képes erre és úgy van beállítva. Ez nagyon hasznos érzékeny adatok cseréjekor, hiszen egyébként minden vonal nagyon könnyen lehallgatható. Főleg személyes és hitelkártya adatok cseréjekor szokták alkalmazni. Én javaslom ennek minél szélesebb körű alkalmazását a személyiségi jogok védelmében, hiszen az ember könnyen kiismerhető arról, hogy milyen tartalmakat látogat.
A titkosításnak a böngésző szempontjából 56-bites és 128-bites kóderősségű változata van. (Az USA exportszabályozásai miatt). A szerver oldalon szükség van egy úgynevezett igazolásra (Certificate) is, mellyel a szerver igazolja magát a kliens felé, hogy ő kicsoda-micsoda. Egy ilyen igazolást készíthetünk magunknak is, de ezt a böngésző gyanúsan fogja fogadni. Az igazolást általában egy kereskedelmi cégtől lehet vásárolni, mely egy adott időre szól. Ez a cég igazolja, hogy az igazolásunk valós adatokat tükröz és nem egy cracker banda DNS spoof-olt47 ál-szerverére lépett be a felhasználó. Persze ezek a "Signer" cégek főként külföldiek és viszonylag sokba is kerül egy ilyen igazolás, ezért, ha szükséges, készíthetünk magunknak egyet. (Részletesen később.)
user authentication: vagyis a felhasználó azonosítása. Ha vannak olyan oldalak, ahová csak bizonyos felhasználók léphetnek be, akkor oda általában valamilyen autentikáció szükséges. Ilyen lehet pl. egy név / jelszó bekérés, de ettől sokkal komplexebb formák is vannak. Azonosítás történhet LDAP48 protokoll vagy adatbázis segítségével is.
Modulok: Nagyon hasznos funkció, hogy csak azokat a részeket kérjük betölteni a szerverprogram indulásakor (a konfigurációs fájl szerint), melyek számunkra szükségesek. Így rengeteg erőforrást takaríthatunk meg. Mivel a rendszer szabványos API49-val rendelkezik, külső beszállítóktól is szerezhetünk be speciális modulokat (akár kereskedelmi termékeket is), melyeket a rendszerbe beilleszthetünk. "A kernelhez hasonlóan, az Apache is képes megfelelően elkészített külső file-t beültetni, mely a saját kódjába épül a memóriában. Az itteni modulok annyiban eltérnek a kernelben használatosaktól, hogy csak induláskor tölthetőek be, futás közben nem." [19. p. 87] Ekkor persze a gépet nem kell újraindítani, csupán a Web-szerver programot.
Általában elég összetett kérdés, hogy melyik modul hol van, mi a funkciója, és hogyan illeszthető bele a rendszerbe. Mindenesetre a főág moduljai megtalálhatóak a http://modules.apache.org -on.
Pl. a mod_rewrite modul az oldalak kódjában lévő URL-ek átírásával foglalkozik. Ez bár elsőre viszonylag bonyolult dolognak50 tűnik, megfelelő dokumentációval rendelkezik. Ez a probléma főleg a webgazda (lásd később) feladatába tartozik. A lényeg az, hogy ha megváltoztatjuk a Web hely "fizikai" felépítését, az oldalakban szereplő hivatkozásokat is mind meg kellene változtatni, ami igen nagy munka lehet. Ezért találták ki ezt a kitűnő segédeszközt.
A modulok51 listáját és funkcióját mutatja az 1. táblázat - Az Apache moduljai

mod_access | Gép (IP) alapú hozzáférés-szabályozás
mod_actions | Fájltípus / metódus alapú script indítás
mod_alias | Álnevek és átirányítások
mod_asis | Az ".asis" fájl kezelő
mod_auth | Felhasználó azonosítás szöveg fájlokkal
mod_auth_anon | ftp stílusú névtelen felhasználó azonosítás
mod_auth_db | felhasználó azonosítás a Berkeley-féle DB (adatbázis) fájlokkal
mod_auth_dbm | felhasználó azonosítás DBM (adatbázis) fájlokkal
mod_auth_digest | MD5 felhasználó azonosítás
mod_autoindex | Automatikus könyvtár listázás
mod_cern_meta | HTTP fejléc metafájlok támogatása
mod_cgi | CGI52 script-ek meghívása
mod_digest | MD5 felhasználó azonosítás
mod_dir | Alapszintű könyvtárkezelés
mod_env | Környezeti változók átadása CGI script-eknek
mod_example | API demonstráció
mod_expires | Fejlécek erőforrásokhoz (meddig érvényes egy oldal)
mod_headers | Tetszőleges HTTP fejlécek beépítése
mod_imap | Kép-térkép fájlkezelő
mod_include | Szerveroldalon előállított objektumok
mod_info | Szerver beállítási információk
mod_log_agent | A "User Agent"-ek naplózása (a felhasználó milyen böngészőt használ)
mod_log_config | Testre szabható naplózó
mod_log_referer | "referer" naplózó (honnan lett a kliens erre az oldalra irányítva)
mod_mime | Objektumtípus megállapítása fájlkiterjesztésből
mod_mime_magic | Objektumtípus megállapítása tartalomból
mod_mmap_static | Fájlok térképének elkészítése a memóriába a gyorsabb kiszolgálás érdekében
mod_negotiation | Tartalom "tárgyalás"
mod_proxy | HTTP gyorsítótár
mod_rewrite | Profi URL-ből fájlnévre konvertáló
mod_setenvif | Környezeti változók beállítása kliens információk alapján
mod_so | Futás közbeni modul-betöltés támogatása (fejlesztés alatt!)
mod_speling | Automatikus hibajavítás félregépelt URL-ekben
mod_status | a szerver állapotának megjelenítése Web-lapként (autentikáció szükséges)
mod_userdir | A felhasználók könyvtárait kezeli (listázás, letöltés)
mod_unique_id | egységes kérés azonosító generálása minden lekéréshez
mod_usertrack | Felhasználó-követés sütik (cookies) segítségével
mod_vhost_alias | dinamikusan konfigurálható virtuális szerver-támogatás

1. táblázat - Az Apache moduljai

Ha újra szeretnénk fordítani az Apache-ot (pl. hogy a rendszerünkhöz optimalizáljuk), ajánlom, hogy a Debian előrecsomagolt forrását használjuk, mert ekkor egyből, a Debian segédeszközeivel .deb csomagba fordíthatjuk azt. Ez nagyban megkönnyíti a későbbi használatot.
Hogy miért pont az Apache-ot választottam?
Azért, mert:

- a világ Internetes Web-szervereinek 60%-án ez fut53

- széles körben elterjedt, ismert, bevált, tesztelt

- ezt ismerik azok, akiktől segítséget kérhetünk (pl. levelező listák)

- nagy teljesítményű, rengeteg funkcióval és lehetőséggel rendelkezik

- ezután is támogatott, fejlesztett lesz még sokáig

- ingyenes, szabadon felhasználható, nyitott forráskódú

- elég biztonságos, ha jól be van állítva

- nagyon sok platformon fut, ezért egységesen használható

- nagymértékben személyre szabható

- nagy, neves gyártók által is támogatott

##
5. A Web-szerver helye a hálózatban (Internet/intranet)

A publikus Web-szerverünket az un. demilitarizált, semleges zónában kell elhelyeznünk. Ezt az 1. kép - A Web szerver helye a hálózatban mutatja.

1. kép - A Web szerver helye a hálózatban

"Egy tipikus profit szférába tartozó hálózat védekezésénél szigorúan konfigurált tűzfal rendszereket alkalmaznak, amelyek vagy gondosan kontrollálják-monitorozzák a kifelé irányuló hálózati forgalmat, vagy gyakran teljesen megakadályozzák azt. Az Internet felé nyújtott publikus szolgáltatásaikat olyan rendszerekről nyújtják, amelyek egy tűzfal mögött, de még a második tűzfallal védett belső hálózatukon kívül helyezkednek el (semleges zóna). Ha lehetővé tesznek interaktív belépést, akkor azt csak bizonyos hálózatokról és/vagy csak szigorú ellenőrzés után engedik meg."54
A lényeg az, hogy az Internet felé nyújtott publikus szolgáltatásokat sose keverjük össze a csak belső használatra kialakított szolgáltatásokkal, azok ne legyenek közös gépen és alhálózaton.
Fontos beállítani a Web-szerveren is a csomagszűrést (pl. ipchains)55, hogy ez ne legyen egy ugródeszka a belső hálózat felé. Az Internet és a Web-szerver közötti szűrőn (lehet ez egy Linux-os tűzfal is PC-n.) tiltsunk le először minden forgalmat, amely befele irányul, majd engedélyezzük a következőket a Web-szerver felé (--destination IP címmel megadva!):

port | szolgáltatás | irány | miért?
80 443 22 25 | http (Web) https (Web) ssh smtp (mail) | kintről befelé | ezt szolgáltatjuk ezt szolgáltatjuk távoli menedzsment kapjunk leveleket

2. táblázat - Az engedélyezett szolgálatások listája

A Web-szerverünkön más szolgáltatást az Internet felé nem kívánunk nyújtani. Az SMTP-re is csak azért van szükségünk, hogy a rendszergazda megkapja a rendszernaplókat és esetleg a rendszergazdák egymás között levelezhessenek.
Figyelnünk kell azonban arra is, hogy így a Web-szerverről nem fogunk tudni elérni semmit (pl. nem tudunk ftp-zni, ssh-zni), mivel a kapcsolódási portok (is) le vannak tiltva. Ezért hozzá kell még adnunk néhány olyan szabályt is, amely ezt lehetővé teszi.
Meg kell akadályoznunk továbbá azt, hogy olyan csomagok átjussanak a szűrőn, mely külső helyről érkező csomag fejlécében, a forrás (source) IP cím a mi belső hálózati szegmensünk valamely címét tartalmazza. Vagyis belső címről érkező csomagnak tünteti fel magát, de olyan interfészről érkezik, amely biztosan a külső hálózathoz tartozik.
Ha Linux-os tűzfalunk van így kell eljárni:56 (Az ipchains program részletes bemutatására nem térek ki. Ennek használatát olvassuk el a dokumentációból. A HOWTO57 7. fejezetében részletesen tárgyalva van egy - a mi példánkhoz hasonló - hálózat tűzfalának beállítása. Az ipchains-el kapcsolatban ajánlom továbbá ezt a két cikket [22], [23]. )
Először is, állítsuk be az alapviselkedést tiltóra:

    ipchains -P input DENY # minden olyan csomag amely nem felel meg egyetlen

    ipchains -P output DENY # további szabálynak sem, ne legyen átengedve

    ipchains -P forward DENY # se be, se ki, se továbbítva

Minden olyan csomagot, amely a loopback interfésznek fenntartott címről jön, de más interfészről, tiltsunk le, mert ez IP átejtés (spoofing)58. Több hálózati kártya esetén tegyük meg ezeket az egyes interfészekkel is, vagyis pl. az Internethez tartozó interfészen ne jöhessen be olyan csomag, melynek forráscíme a belső hálózatunkhoz tartozik.

    ipchains -A input -j DENY -l -s 127.0.0.0/8 -i ! lo

    # a $MYNET/MASK helyett mindenki írja be a saját alhálózatát és annak maszkját.

    ipchains -A input -j DENY -l -s $MYNET/MASK -i ! eth0 # stb.

Itt megengedjük, hogy az Internetről látható legyen a Web-szerverünk:

    # az $INETIF helyett mindenki írja be azt a hálózati interfészt, mely az Internetre

    # kapcsolódik

    ipchains -A input -p all -i $INETIF -j ACCEPT -d "a mi Web-szerverünk IP címe" 80

Ha egy adott IP címről vagy tartományról nem akarjuk fogadni a kéréseket, akkor azokat tiltsuk le. (Pl. innen betörési kísérletek voltak már.)

    ipchains -A input -p all -j DENY -s "akármi" -d "a mi Web-szerverünk IP címe" 80

Minden egyéb próbálkozást tiltsunk le, hogy senki se futtathasson a belső hálón Web-szervert úgy, hogy azt kívülről látni lehessen.

    ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d $MYNET/MASK 80

Ugyanezt tegyük meg a 443-as porton is.

    ipchains -A input -p all -i $INETIF -j ACCEPT -d "mi Web-szerverünk IP címe" 443

    ipchains -A input -p all -j DENY -s "akármi" -d "a mi Web-szerverünk IP címe" 443

    ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d $MYNET/MASK 443

Hasonlóképpen járhatunk el a 22-es és a 25-ös portok esetén is. Ha van másik levelező, vagy menedzselni való szerverünk, akkor adjunk meg megengedő szabályokat azokra is. Újra felhívom a figyelmet arra, hogy ekkor csak a Web-szerver 22, 25, 80, 443-as portjai érhetőek el, ezért egyrészt nem lehet a Web-szerverről kapcsolódni más gépekre és a DMZ-ben lévő más gépekre se, ezért azokat az IP-ket és portokat külön engedélyezni kell. Ha azt akarjuk, hogy vissza is kapjunk adatokat, ha belülről kérünk kifelé, tegyük ezt:

    ipchains -A input -p tcp -j REJECT -y -i $INETIF -d "saját alháló v. gépcím"

    ipchains -A input -p tcp -j ACCEPT -i $INETIF -d "saját alháló v. gépcím"

Ekkor a kívülről jövő külön nem felsorolt kapcsolatkérések el lesznek utasítva egy "célállomás nem elérhető" válasszal. Amint látszik, ez csak a TCP protokollt igénylő szolgáltatások esetében igaz. Az UDP-s szolgáltatásoknál nincs engedély. Meg kell engednünk viszont az Internet és a belső szegmensek között az 53,123-as UDP portokat, mert ezek nélkül az egyes szolgáltatások nem működhetnek helyesen.

    ipchains -A input -p udp -j ACCEPT -i $INETIF -d "saját alháló v. gépcím" 53

    ipchains -A input -p udp -j ACCEPT -i $INETIF -d "saját alháló v. gépcím" 123

Az itt felsorolt szabályok csak töredékei az összes tűzfalon beállítandó szabályoknak. Célszerűbb a különböző zónáknak saját szabályláncot létrehozni. Erről bővebben a dokumentációban.
Figyelnünk kell továbbá az ICMP forgalmat is. Javasolt az "echo-reply, echo-request, time-exceeded, destination-unreachable, source-quench" típusú csomagok átengedése az összes többinek pedig a tiltása a tűzfalon.

    ipchains -A input -p icmp -i $INETIF -j ACCEPT -d $MYNET/MASK --icmp-type echo-reply

    ipchains -A input -p icmp -i $INETIF -j ACCEPT -d $MYNET/MASK --icmp-type echo-request

    ipchains -A input -p icmp -i $INETIF -j ACCEPT -d $MYNET/MASK --icmp-type time-exceeded

    ipchains -A input -p icmp -i $INETIF -j ACCEPT -d $MYNET/MASK --icmp-type destination-unreachable

    ipchains -A input -p icmp -i $INETIF -j ACCEPT -d $MYNET/MASK --icmp-type source-quench

Fontos továbbá az is, hogy a DMZ és a belső hálózat közötti tűzfalon csak azokat a portokat engedélyezzük átmenni, amelyek a cég munkájához szükségesek lehetnek. "Csak azokat a szolgáltatásokat engedélyezzük, amelyről tudjuk, hogy használni akarjuk, és azt is, hogy milyen módon. A tűzfal és a belső gépek számára engedélyezett TCP/IP szolgáltatások mások lehetnek, de a belső gépeken is csak az okvetlenül szükséges dolgokat engedélyezzük. Kényelmi szolgáltatásokat semmiképpen. A belső gépek számára a tűzfalon át proxy szerverek segítségével biztosítunk kijutást. Belső hálónk forgalmát védjük az Internet felől jövő fenyegetésektől, legyen legalább egy szűrőnk." [12. p. 198.] Tehát a belső hálóról az Internet felé induló kéréseket is szűrjük meg. Átengedhetjük a Web (80, 8080, 443), az ftp (20,21), mail (smtp, imap, esetleg pop3), stb. munkát ténylegesen segítő portokat. Ha szükség van rá, akkor engedélyezzük az ntp (123/tcp/udp) protokollt, mely az idő beállításához használható. Ezt csak egy vagy két IP címről engedélyezzük, mert ez is támadási felület lehet, hiszen a naplófájlok emiatt össze-vissza írhatják az időpontokat. Az összes többi portot tiltsuk le a tűzfalon. (Az irc (6666,6667,6668), napster, és a különböző hálózati játékok portjait mindenképp tiltsuk le. Tiltsuk le továbbá a nem biztonságos szolgáltatások portjait, mint pl. a telnet (23).)
Azokat a tartalmakat, melyeket átengedünk, csak a tűzfalon engedjük ki, proxy (vagy transzparens proxy) segítségével. Enélkül az egész tűzfal semmit sem ér. A Web gyorsítására használjunk Web-caching-proxy-t (pl. Squid).
Mindenképp olvassuk el a Firewall-Howto-t59. Ajánlom továbbá a következő szakkönyveket: [16], [17], [18]. Két hasznos cikk a TCP működéséről és a hálózati biztonságról Paul Russel-től (az ipchains program írójától) [24], [25]. Elolvashatjuk ezenfelül a Firewall Checklist-et60 is.

##
6. A Web-személyzet felépítése

A mai világban már annyira specializálódtak a feladatok, hogy egy ember nem képes átlátni egy ilyen komplex rendszert. Ezért van szükség a feladatok szétosztására.
Gyakorlatilag három rendszergazdára lenne szükség: Egy általános hardver/szoftver, egy adatbázis és egy Web-szerver rendszergazdára. (Sok esetben már a hardver és a szoftver gazdája is különválhat nagyobb mennyiségű gép esetén.)
A Web-személyzet ideális esetben a következő pozíciókból áll:

1. Rendszergazda: összeszereli és hálózatba köti a számítógépet, telepíti és karbantartja a szoftvereket, Az Ő feladata a biztonságos üzemeltetés és a biztonsági másolatok készítése is. Ő csak a Web-szerver és az adatbázis-szerver rendszergazdáknak ad belépési jogot a gépre. A "közönséges" felhasználóknak ideális esetben ezek a személyek adnak feladatuk szerinti hozzáférési jogot.

2. Adatbázis-rendszergazda: ő felügyeli az adatbázis szerver programot, ő hozza létre az adatbázis-felhasználókat (akik feltölthetik, módosíthatják az adatbázis tartalmát), ad nekik jogosultságokat az adatbázis elérését illetően. Hiba esetén a rendszergazdával együtt kell dolgoznia a helyreállítás érdekében.

3. Web-tervező: kialakítja a Web-hely arculatát, struktúráját, továbbá összefogja a fejlesztő-stáb munkáját. Ő a fő koordinátor, a többi taggal ő tartja a kapcsolatot.

4. Grafikus: a Web-tervező által kigondolt arculathoz grafikai terveket, munkákat és a konkrét fényképeket, képobjektumokat készíti el.

5. Web-programozó: az előbbi személyek által megtervezett dinamikus oldalakat programozza le valamilyen (pl. PHP3) script nyelven és azt a Web-tervező rendelkezésére bocsátja.

6. "Titkárnő": ő viszi fel (gépeli be) a statikus szövegeket, melyeket a Web-tervező rendelkezésére bocsát. Felesleges egy képzett embert ilyesmire "kényszeríteni". Továbbá ő lehet az, aki feltölti az adatbázist friss adatokkal, pl. termék és árlista. Neki, lehet, hogy egyáltalán nem kell felhasználói számlát létrehoznunk (Esetleg e-mail-t).

7. Webmester/webgazda (ált. a Web-szerver program rendszergazdája): elhelyezi és karbantartja a Web-lapokat, az ő feladata a website belső fájlstruktúrájának megtervezése, az e-mail-ek fogadása és megválaszolása (erre a témára vonatkozóan) esetleg továbbítása a megfelelő személyeknek.

Amint láthatjuk ezt nem sok kisvállalat engedheti meg magának. Ha már van egy rendszergazdánk (ekkor ő veszi át az összes rendszergazdai szerepkört), meg egy titkárnőnk, akkor a többit egy külsős cégre bízhatjuk. Ekkor meg kell bíznunk a külsős cég alkalmazottaiban, mert azok a kész és a frissített anyagokat mindig fel kell hogy töltsék szerverünkre, tehát ide valamilyen hozzáférésük kell, hogy legyen. Ez persze nagymértékben csökkenti szerverünk védettségét a külső behatolás ellen, hiszen nem tudhatjuk, mennyire vigyáznak az ottani kollegák jelszavaikra. A másik lehetőség, hogy a friss anyagokat elküldik a rendszergazdának és az személyesen tartja karban a dolgokat.
A mi rendszergazdánk végzi a dolgát, és a titkárnőnk pedig frissítheti az adatbázist (pl. az árlistát) akár egy lekérdezős dinamikus Web-oldalon keresztül is.

##
7. Web-proxy fogalma és helye a hálózatban

A Web-caching-proxy egy olyan gyorsítótár-szerver, amely a Web-szerverekről lekért objektumokat tárolja. Ha egy új kérés érkezik, azt először a proxy kapja meg. Ha már megvan a tárolójában az adott objektum, és még érvényes annak a tartalma, akkor azt küldi el a kérőnek, és nem továbbítja a kérést a Web-szervernek. Főleg akkor hasznos, ha a belső hálózatunkat engedjük ki kliensként az Internetre. Ezt mindenképp egy jól beállított proxy-n keresztül érdemes megtenni, hogy a kisebb sávszélességű vonal terhelését csökkentsük. A Linux rendszereken a squid nevű GPL-es Web-proxy szoftver a legelterjedtebb.
A mi esetünkben a Web-proxy más jelentést kap. Ha nagyon nagy forgalmat bonyolít a szerverünk akkor a Web-szerver és az Internet kijárat közé beékelhetünk egy Web-proxy-t. Ez főleg a statikus tartalom esetében nagy terhet vesz le a szerverünk vállairól. Ekkor persze a külvilág a szervert nem láthatja, csak a proxy-t, vagyis transzparens-proxy-zást kell beállítanunk. A kliens azt hiszi a Web-szerverrel beszélget, közben csupán a proxy-val kommunikál.
Az Apache is rendelkezik egy beépített proxy modullal. Ez persze nem olyan hatékony, mint egy külön gép squid-et futtatva, de bizonyos esetekben és terhelési szinteken (talán) hasznos lehet.

##
8. Biztonsági alapok (hardver, szoftver)

A biztonság nagyon fontos, összetett és vitatható kérdés. Napjainkban egyre jobban előtérbe kerülnek a biztonsági problémák. A lényeg: nincs abszolút biztonság. Legfőbb ellenségünk maga a felhasználó (és a rendszergazda) lustasága. Ő az aki nem vigyáz kellően a jelszavára, ő az aki egy cetlire írja azt és ráragasztja a monitorjára, mert mindig elfelejti, stb. Egy hírhedt amerikai cracker elfogása után később elmesélte, hogy pofonegyszerű volt bejutnia a kormányzati rendszerekbe. Rendszergazdának adta ki magát és felhívott közalkalmazottakat, titkárnőket mindenféle ürüggyel, hogy azok adják ki jelszavaikat. Így nem is kellett szó szerint feltörnie a rendszereket, mert a kiskapu nyitva állt, onnan már szinte gyerekjáték volt a hiányos és átgondolatlanul megszervezett biztonsági kapukon átjutnia, hogy megszerezze a szükséges információkat.

###
8.1 Általános irányelvek

Az első pont tehát olyan rendszert tervezni, ahol a felhasználók a lehető legkevesebb kárt tehetik, vagyis a lehető legkevesebb, csakis az adott munkakörükhöz szükséges jogokkal szabad rendelkezniük.
A külső támadás lehetséges okai:

- A cégünk imázsának, jóhírének lerombolása

- Üzleti információk megszerzése, kémkedés a konkurenciának

- Unaloműző rosszindulatú károkozás

- Ugródeszka keresése más gépek feltöréséhez

A külső támadások fajtái:

- Portscan: az összes lehetséges portot végig próbálgatva ezzel mérik fel a gépen futó szolgáltatásokat és, hogy azokat milyen programok nyújtják. Ezután el lehet dönteni, hogy a rendszer melyik része ellen kezdjenek támadást.

- Sniffing: Ha valakinek a belső (pl. Ethernet) hálózaton gépe van (vagy feltesz egy gépet) rendszergazdai jogosultságokkal (az egy-felhasználós rendszerek ilyenek), akkor ún. promiscuous módba kapcsolhatja a hálózati kártyáját. Ekkor minden csomagot, amely kikerül arra a fizikai hálózatra, a kártya elfogad magának is. Egy hallgatózó programmal felszerelkezve az illető megszerezhet bármilyen kódolatlan információt, amely "átfolyik" a kártyán.

- DoS: Itt a cél a szolgáltatás(ok) teljes lelassítása, megakasztása. Megfelelő (pl. TCP) kvótákkal szinte minden szolgáltatást meg lehet védeni ez ellen valamilyen mértékben.

- DDoS (Distributed Denial of Service): Az előbbi támadásnak egy olyan fajtája, amikor sok "ártatlan" számítógépre valamely módon egy támadóprogramot telepítenek a tulajdonos engedélye nélkül, melyekről később egy időpontban indul 'szétosztott' támadás a célgép ellen.

- Spoofing: DNS vagy IP cím átfedése. Pl. ha egy kliens lekérdez egy Web-oldalt, akkor egy ál név-szervertől nem a valódi Web-szerver címét kapja vissza, hanem előbb a károkozó gépét. Innen persze átirányítódhat a kérés az eredeti szerverre, de közben akár hitelkártyaszámokat is lejegyezhet a cracker programja. Az IP átejtés esetében valaki úgy manipulálja a hálózatot, hogy a célgép IP címét ő veszi fel, és annak nevében kommunikál.

A belső támadások fajtái:

- Buffer overflow: egyes programok programozási hibáját kihasználva veremtúlcsordulást okoznak, majd egy rootshell-t kérnek le az IP (Instruction Pointer) segítségével. Ekkor rendszergazdai jogosultságokat szerezhetnek, ha a megtámadott program (pl. sendmail) rendszergazdai jogkörökkel futott. Ez ellen a programok biztonsági frissítésével lehet védekezni, és ha lehet alkalmazzunk "chroot jail"-t61 és felhasználóként futtassuk a démont.

- known temp file attack: "E támadási módszer lényege: a behatoló megfigyeli, hogy a hibás program milyen néven hívja meg a .tmp file-jait, és abban a könyvtárban, ahol azokat eltárolja létrehoz egy ugyanolyan nevű szimbolikus linket, mint az egyik .tmp file. Ez arra a file-ra mutat, amit át akar írni."[2]

- Exploit-ok: olyan előre gyártott programocskák, melyek minden különösebb szakértelem nélkül rendszergazdai jogköröket adhatnak az újdonsült cracker-nek. Ezek az Internetről le is tölthetőek. http://rootshell.org Ilyen például a rootkit programcsomag, amely Linux alá is létezik. Ez trójai programokat tartalmaz, melyekkel kicserélve az eredetieket állandó kiskapu biztosítható a betörő számára.

Tehát a következő fontos elveket kell betartanunk:

- Fizikai védelem: a szervergép egy külön lévő elzárt, és jól zárható szobában üzemeljen, mely helyiségben (esetleg) légkondicionáló berendezés is van (~21 Celsius fok). A szobához csak az illetékeseknek legyen kulcsa. Takarító nem járhat a szobában, mert véletlenül kihúzhatja a vezetéket, stb. Továbbá fontos szempont a tűzvédelmi berendezés (pl. porral oltó), ráccsal védett ablakok, lehetőleg emeleti helyiség, stb. A mentés lemezeket egy másik helyiségben, esetleg épületben őrizni tűzkár miatt, jól elzárva, hogy illetéktelen személyek ne férjenek hozzá, stb. A helyiségben tilos a dohányzás, kávézás, stb.

- A gép BIOS-át úgy állítsuk be, hogy jelszóval legyen védve, csak a merevlemezről lehessen indítani, a felesleges hardvereket (floppy, soros, párhuzamos portok) tiltsuk le, ha nem használjuk őket.

- Hivatalos biztonsági szabályzat befoglalása a cég működési szabályzatába. A szabályok hatókörének és az egyes pozíciókon lévő alkalmazottak felelősségének megállapítása, stb.

- Hálózati tervezés: a hálózatot már a tervezéskor úgy kell kialakítani, hogy véletlenül se keveredjenek egy fizikai vagy logikai alhálózatra az egymással nem kapcsolatos szegmensek, kliensek.

- Minimum elv: csak azon programok / szolgáltatások fussanak és legyenek rajta a gépeken, amelyek ténylegesen és indokoltan használva lesznek.

- Mindent tilos, kivéve, amit szabad elv: a tűzfalon és más biztonsági szabályzó szűrőkön mindent letiltunk, és egyesével adjuk meg azokat a szabályokat, amelyek a "szabad" kategóriába tartoznak.

- A jelszó rendelet: minden jelszó legalább 8 karakteres, tartalmaz számokat és egyéb ASCII karaktereket és nem szótári szó. Nem tartalmaz semmi személyhez köthetőt, pl. valaki születésnapját, stb. A jelszavak 30 naponként változzanak meg, stb. (Használjunk MD5 kódolású jelszavakat, lásd később). Használjunk shadow password funkciót.

- Email titkosítás: amikor csak lehet, a szerveren lévő felhasználók kódolt formában levelezzenek és a rendszer is legyen képes kódolt levéltovábbításra. Ehhez már megvannak a szükséges programok: felhasználói oldalon a gpg 62, vagy a pgp 63, szerver oldalon a TLS-képes64 levéltovábbító, mint pl. a postfix-tls. Továbbá a rendszer eseménynaplóját is titkosított formában ajánlott elküldeni a rendszergazdának, hogy ez se legyen lehallgatható.

- Őrizetlen terminál: A felhasználók ne hagyják őrizetlenül a számítógépüket bekapcsolt és bejelentkezett állapotban, mert bárki leülhet mellé és kárt tehet. Használjuk a vlock vagy xlock programokat a terminál lezárására.

- Csak az kapjon shell-t akinek arra tényleg szüksége van. Akinek a munkájához nem szükséges a UN*X shell használata, pl. csak a böngészőjén keresztül módosítja az adatokat, annak ne legyen shell-je.

- Nem biztonságos szolgáltatások (pl. telnet, ftp) tiltása és helyettük kódolt változataik beállítása (ssh, scp)

- Lehetőséget adni a Web-szerver látogatójának a titkosított adatcserére (SSL) Érzékeny fájlokat / könyvtárakat azonosításhoz kötni.

- Folyamatos mentés: adott időközönként teljes vagy részleges mentést kell végrehajtani a rendszerről, hogy hiba esetén gyorsan visszaállítható legyen az utolsó működő állapot. Egy mentési szabályzatot is ki kell dolgozni: milyen időközönként milyen mértékű mentést kell végezni, visszamenőleg hány állapotot kell megtartani, stb.

- Rendszernaplók nyomon-követése: a rendszergazdának figyelnie kell a rendszer eseményeit, és ha valami kompromittálásra utaló jelet találna, akkor azonnal cselekednie kell.

- Alapos ok nélkül semmilyen programot újabb verziójúra cserélni nem szabad. Egy jól működő rendszerhez hozzányúlni nem szabad. Csakis a biztonsági problémák miatt szabad új verziókat feltenni. Ha mégis lecserélni szándékoznánk valamit, csak már egy előre letesztelt, kipróbált változatot tegyünk fel. Tudniillik "a pokolba vezető út is jószándékkal van kikövezve". Mi jószándékkal feltelepítjük a legfrissebb verziót, amely lehet, hogy teljesen másképp fog viselkedni, és akkor állhatunk neki tanulmányozni a hiba okát. Mindazonáltal, nem szabadna ~2 évnél idősebb szoftvert használni. Van néhány olyan hiba, amit a fejlesztők kijavítanak, de nem publikálnak. Ésszel kövessük mindig a legfrissebb stabil verziókat.

- A "nagy" levelező szerveren sose legyen Web-szerver és vica versa. Általában a sendmail program a legérzékenyebb a betörésekre és rajta keresztül elérhető lehet a Web-szerver. Miután az OpenBSD csapat elkezdte auditálni a kódját, sokat javult a biztonsága, de azért Én az életemet nem bíznám rá. A levelezőszerveren használjunk egy sokkal biztonságosabb alternatívát, mint amilyen például a postfix vagy a qmail.

- Ne futtassunk FTP szervert a Web-szerveren. Szintén sérülékeny pont a buffer overflow szempontjából. Lehetőleg a legfrissebb, legstabilabb szervert használjuk. Ha lehet, ne legyen Anonymous (névtelen) ftp, de ha mégis, akkor vigyázzunk a jelszófájlra. Ne engedjünk meg olyan könyvtárat, amelyben Anonymous olvashat és írhat is.

- A Web-szerver démon sose fusson root jogokkal, kapcsoljuk ki a könyvtárlistázást, és ne kövesse a szimbolikus linkeket. (Ezekről részletesen később)

Ha a rengeteg jelszót nem tudjuk megjegyezni, ne használjunk ugyanolyan jelszókat több helyen, ne írjuk le őket papírra, se kódolatlan fájlba. Használjuk pl. a gpasman programot. (http://gpasman.nl.linux.org) Ez a program tipikusan a sok jelszó menedzselését segíti. A jelszavakat kódolt formában tárolja. A Woody-ban már benne lesz. Töltsük le a rendszergazdai gépre (vagy fordítsuk le forrásból). Többen mindenféle kézigépekbe írják a jelszavaikat. Fontos, hogy ez esetben egyrészt kódoljuk az eszközben az információt lopás esetére, másrészt pedig tartsunk róla biztonsági másolatot, ha a készülék elromolna (ellopják, elvész), ne kelljen mindent előröl kezdeni.
Sokan viszont az javasolják, hogy semmiféle jelszót ne tároljunk hálózatra csatlakoztatott gépen, hiszen valamiképpen ekkor úgyis hozzá lehet jutni. Persze ekkor meg kellene jegyezni az összes jelszót, amire kevés ember képes.
Fontos feladat a rendszergazdának a rendszer folyamatos frissítése a biztonsági javításokkal, a biztonsággal foglalkozó oldalak látogatása. Pl. http://www.linuxsecurity.com, http://www.debian.org/security, http://www.cert.org. Olvassuk el a Compromise FAQ-t (http://www.iss.net), a Linux Security- HOWTO-t http://metalab.unc.edu/pub/Linux/docs/HOWTO/Security-HOWTO A tűzfal és a kernel tűzfalfunkcióját szabályzó ipchains program HOGYAN-ját ugyanitt találjuk Firewall-HOWTO és Ipchains-HOWTO néven. Az utóbbi magyar fordítása: http://www.rkcs.hu/linux/index2.html A http://www.faqs.org/rfcs/rfc2196.html címen egy biztonságpolitikai szabályzatot találunk RFC-be foglalva. Továbbá érdemes áttekinteni az 1244 és 1281-es számú RFC-ket is, melyek szintén ezzel a témával foglalkoznak. Végül egy valós életbeli példa található az ftp://coast.cs.purdue.edu/pub/doc/policy címen.
Ajánlom továbbá az olvasó figyelmébe a következő könyvet: [12]

###
8.2 A Linux kernel biztonságát növelő projektek

A Linux-hoz létezik több biztonsági "folt" is. Az egyik ilyen érdekes és hasznos kód a http://www.openwall.com/linux könyvtárában található. Jelenleg csak a 2.0 és 2.2-es sorozatú kerneleket támogatják. Sok biztonsági javítás kerül később innen a hivatalos kernelforrásba. A következők ellen nyújt bizonyos mértékű (nem 100%-os) védelmet:

- Nem futtatható felhasználói veremterület védelme a puffer túlcsordulásoktól.

- Szimbolikus link és FIFO korlátozás a /tmp könyvtárban

- /proc könyvtár információinak védelme a felhasználói kutakodástól és információgyűjtésről (csak az adott csoportba tartozó emberek tekinthetik meg a fájlok tartalmát)

- A fájl leírótáblák (File descriptors: 0,1,2) speciális kezelése

- A felhasználók által maximálisan futtatható folyamatok számának hatékonyabb korlátozása

- Használaton kívüli megosztott memória szegmensek megsemmisítése (kinullázása)

Hasznos megfontolni ennek a foltnak a használatát, hiszen növelheti a rendszerünk biztonságát. Hátránya viszont az, hogy megfelelő tesztelés kell, hogy megelőzze a használatát, mert egyes "veszélyes" módon viselkedő programok esetleg nem fognak rendesen futni. (Tapasztalatom szerint minden jól működött.) Ha használni szeretnénk, mindenképp olvassuk el a dokumentációját, hogy megértsük, miről is van itt szó és milyen szintű biztonsági erősítést kapunk ezáltal. Ezt a foltot a kezdőknek is ajánlom, mivel nem igényel semmilyen különös karbantartást.
Meg kell említenem a LIDS (Linux Intrusion Detection System Patch, vagyis Linux Betörés Detektáló Rendszer) foltot is. (http://www.lids.org) A LIDS képes együttműködni az OpenWall folttal és erős biztonsági rendszert épít a Linux-ba. Lényegében ez abban a fázisban fontos, amikor már valaki behatolt a rendszerbe és root jogokat szerzett. Ez a program lekorlátozza a root jogait. Amikor nekünk kell adminisztrálni a gépet, egy jelszó megadásával kikapcsolhatjuk a védelmet, hogy tudjunk dolgozni.
Korlátozások:

- Megtiltja a modulok betöltését és eltávolítását.

- Megtiltja a közvetlen memória-kezelést

- Megtiltja a közvetlen lemez-kezelést

- Megtiltja a közvetlen I/O port-kezelést

- Védi az indulási folyamatban résztvevő fájlokat (kernel, lilo, démonok, modulok, init script-ek)

Behatolás-figyelés:

- Naplózza a tiltott dolgokhoz való hozzáférési próbálkozásokat

- Csak olvashatóvá ill. csak hozzáfűzhetővé teszi a naplófájlokat, hogy a behatoló ne tudja eltüntetni nyomait

- Elrejti a behatolás-figyelő program részeit

Rendszer-védelem:

- Az útválasztó-táblák és a tűzfal-szabályok védelme

- A felfűzések (mounts) befagyasztása

- A démonok védelme a szignáloktól (pl. kill)

- Kernel jogosultságok - a root user szintre butítható, stb. (bővebben a dokumentációban)

A rendszert egy lidsadm nevű démon kezeli, melyhez egy RipeMD-160 kódolású jelszóval lehet csak hozzáférni. Ez a program monitorozza az eseményeket. A védelmet rajta keresztül lehet ki és bekapcsolni. Külön védelem állítható be szinte mindenhez a rendszeren.
Ha érdekel minket a dolog, olvassuk el a dokumentációt. A lids@egroups.com címen érhető el a rendszer levelező listája. A függelékben egy részletesebb útmutatóban tárgyalom a beállítását. Ezt a programot a haladóknak ajánlom.
A következő fontos és hasznos törekvés a Medusa, melyet Szlovákiában fejlesztenek - többek között szlovákiai magyarok is. Ez a programcsomag kernel foltból és egy démonból áll. A cél kernel szintű felhasználó azonosítás. Ez az "azonosító-szerver" átlátszóan működik a kernel és a felhasználói programok között. Bizonyos műveletek indítása előtt a kernel jóváhagyást kér a szervertől. Ezzel a módszerrel szinte bármilyen biztonsági modell megvalósítható. A konfigurációs fájlok megfelelő beállításával nagyon magas szintű biztonságot érhetünk el. A kernel és a démon egy speciális /dev/medusa eszközön keresztül kommunikál.
A jelenlegi implementáció a következőkre képes:

- Teljes hozzáférés szabályozás (Access control) a fájlrendszeren

- Hozzáférés átirányítása egyik fájlról a másikra

- A jel (signal) küldés / fogadás teljes szabályozása

- Fontos folyamat-műveletek direkt irányítása

- Bármely rendszerhívás indításának szabályozása egy adott folyamaton belül

- Egyes fájlok és/vagy folyamatok teljes elrejtése más folyamatok elől

- Minden folyamat saját bejelentkezési azonosítót kap

- Adott kód végrehajtásának kikényszerítése

- Bármely rendszerhívás alacsonyszintű szabályozása

Hátránya, hogy egyelőre csak Intel architektúrán működik, de már folyamatban van a kód portolása más rendszerekre is. A tesztek szerint jól működik többprocesszoros rendszereken is. A másik nehézség a rendszer beállítása, egy kis C nyelvi programozói múlt nem árt hozzá. A forráskód letölthető a http://medusa.fornax.sk címről. Amennyiben érdekel bennünket a dolog, olvassuk el az egész dokumentációt és kövessük az ott leírtakat. Segítséget kérhetünk a csapat levelezőlistáján: medusa@medusa.fornax.sk
Azt, hogy a Medusa együttműködik-e az előzőekkel, sajnos nem tudom és nem is garantálhatom. (Van egy-két ember a levelezőlistákon, aki már készített vegyes foltokat, melyek több biztonsági foltot együtt tartalmaznak.) Végül is, egy jól felépített / beállított Medusa nagyrészt feleslegessé teheti a másik két kódot.
Én az OpenWall-féle kódot alkalmazom a mintapéldámban. A függelékben röviden bemutatom a LIDS féle rendszert is.

###
8.3 A Web-alkalmazások biztonsága

Nem egy Web-helyet a hibásan elkészített Web-alkalmazásokon keresztül törnek fel, vagy férnek hozzá egyes felhasználók személyes adataihoz. Ezeket a hibákat a Web-programozónak kell kiküszöbölnie a kódok rendszeres ellenőrzésével. Röviden bemutatom a betörési technikákat:

- "Süti mérgezés": A felhasználó gépére a Web-szerverről kisebb, a későbbi azonosításhoz szükséges információkat tartalmazó fájlok kerülhetnek. Ezeket cookie-knak, magyarul sütiknek nevezzük. Ezeknek két fajtája van: egy állandó, azaz a lemezen lévő, és egy nem-állandó, vagyis a memóriában lévő süti. Természetesen a legtöbb kliensgépen a kódolatlan szöveges állományokként helyet foglaló sütik könnyen elolvashatók mások számára. Ezek használatát kerüljük. Továbbá a kódolatlan sütik hálózati szaglászással is elfoghatóak. Ezért javasolt az SSL csatorna használata kényes információkat tartalmazó sütik esetén. Sok szakember teljesen ellenzi a sütik használatát azok megbízhatatlansága miatt. Az elkapott sütik segítségével jelszavak és hitelkártyaszámok is megszerezhetőek.

- Űrlap manipulációk: A károkozó letöltve egy űrlapot végignézheti annak HTML kódját és azt módosítva küldheti vissza. Általában több elemet tartalmaz, mint amit az értelmező vár, ezzel pl. buffer overflow támadást indíthat a rendszer ellen. Más esetekben parancsok elindítását kezdeményezhetik a szerveren. Ha az értelező script root-ként futott, máris kész a bejárat. Védekezés: ellenőrizni kell az űrlap integritását értelmezés előtt, továbbá a kapott mezők értékeit nagymértékben szűrni és ellenőrizni kell a szerveren végrehajtás előtt.

- Több űrlap esetén egyes űrlapok kihagyása: Ha több űrlapot kell kitölteni egymás után, a károkozó személy direkt URL begépelésével kihagyhat néhány lapot, ezzel érvénytelen adatbázis rekordokat generálhat. Biztosítani kell, hogy csak akkor dolgozzon fel az értelmező egy adatsort, ha minden űrlap ki lett töltve.

- Direkt adatbázis lekérdezések: Sokszor az űrlap mezőiből direkt lekérdezések generálódnak az adatbázis felé, melyre a választ a következő oldal hozza. Ha a károkozó ismeri a programnyelvet (pl. SQL), akkor más felhasználókra vonatkozó információkat is lekérdezhet. Megoldás lehet itt is a mezők szűrése és az adatbázis hozzáférési jogosultságainak helyes beállítása.

- Könyvtárlistázás: Ha olyan könyvtárak is listázhatóak, melyek a Web-alkalmazás kódját tartalmazzák, akkor a kód könnyen megszerezhető és abban biztonsági hiba kereshető ki. A CGI-ket, PHP, stb. kódokat tartalmazó könyvtárak semmiképp se legyenek listázhatóak. (És limitáljuk a fel/letöltésüket.)

Bővebb információkért nézzük át a szakirodalmat: [26], [27], [28].

##
9. SSH - Távoli menedzsment

Amint a rendszer változtatást, karbantartást igényel, a rendszergazda nem szaladgálhat be állandóan a lezárt szerver-helyiségbe, pláne, ha otthon ül, vagy épp úton van több száz kilométerre a szervertől. De ekkor is ki kell javítani az esetleges hibákat, ellenőrizni kell a rendszert. Ezért be kell jelentkeznie egy távoli gépről a szerverre, hogy elvégezze a karbantartást. Ha szerver nem állt le teljesen, van áram és a bejelentkezéshez szükséges minden hálózati kapcsolat él, akkor semmi akadálya, hogy a rendszergazda bejelentkezzen. Persze ezt a hagyományos telnet65 programmal is megtehetné, de hát bolond lenne, hiszen valahol talán egy lehallgató program pont erre vár, hogy a beírt rendszergazdai jelszavát elmentse és elküldje valakinek. Ezért a rendszergazda az ssh (Secure shell - biztonságos héj) program segítségével lép be rendszerébe. A szerveren futnia kell egy ún. sshd démonnak (szolgáltatás, kiszolgáló) és a kliens gépen kell lennie egy ssh kliensnek. Ez szinte minden platform alá létezik. BSD licensz alatt megjelent egy szabad forráskódú implementáció (http://www.openssh.com 66). Egyébként a sokkal szigorúbb licenszel rendelkező SSHv1 és SSHv2 szerver/kliens csomagokat is választhatjuk.67
"A hálózatba kötött gépek távoli kezelése egyszerűen megoldható. Akár telnetes kapcsolaton keresztül (nem biztonságos), akár ssh vagy ssl segítségével (ezek már biztonságosak). Ezek karakteres felületeket biztosítanak, így egy lassú kapcsolaton (modem) keresztül is alkalmazhatóak. És hozzá kell tenni azt is, hogy egy profi rendszeradminisztrátor sokkal gyorsabban végzi a munkáját parancssorból, mint grafikus felületen. Ezenkívül léteznek karakteres terminálon is futtatható programok, amelyek menükön keresztül kommunikálnak a felhasználóval.
Megfelelő beállítások esetén a rendszergazda közvetlenül is bejelentkezhet az adminisztrálni kívánt gépre, akár grafikus felületen keresztül is, anélkül, hogy zavarná a gépen dolgozó egyéb felhasználókat. Szinte minden változtatást végre lehet hajtani a gépen, az operációs rendszer újraindítása nélkül is."68
"A távoli felügyelet lehetőségeinek köszönhetően a rendszergazdának el sem kell mozdulnia a számítógépe mellől ahhoz, hogy karbantartsa a gondjaira bízott gépeket. Az átlagos felhasználó teljesen a saját képére formálhatja az általa használt rendszert, és ehhez az operációs rendszeren nem kell változtatni, nem kell elállítani semmit sem. Ily módon a működőképesség fenntartása nem kerül erőfeszítésbe, mert nem szükséges változtatni a jól beállított rendszeren. A biztonsági rendszer miatt pedig a felhasználó nem tud elállítani semmit a gépen, amihez nincsen joga."69
A tapasztaltabb rendszergazdák régóta tudják, hogy parancssoros üzemmódban sokkal hatékonyabban lehet dolgozni és karbantartani, mint mindenféle grafikus felületű ikonok és menük rengetegében.
Azoknak, akiknek mégis fontos a grafikus felület segítsége, ott a linuxconf programcsomag. Ezzel szöveges módban egy menüs programmal szerkesztgethetjük a legfontosabb konfigurációs állományokat. Létezik hozzá egy X11 grafikus felületű (linuxconf-x11) kezelő is, ha kell. Ezt a csomagot telepítve a szerveren, a mi távvezérlő gépünk X szerverén meg fog jelenni a program, (javasolt egy ssh socket-be becsomagolni!) és máris állítgathatunk kedvünkre.
Összegezve, ma már a karbantartás elképzelhetetlen távoli bejelentkezés nélkül. További információkat a IV. Megvalósítás / 2. Finomítás / 2.4 Az SSH konfigurációjának finomhangolása és az VII. Alternatívát nyújtó programok a Debian-ban / 4. Alternatívák a távoli bejelentkezésre c. fejezetekben találhat az olvasó.

##
10. PHP3 alapok (dinamikus Weblap-készítés)

A PHP egy szerveroldali értelmező script nyelv. A PHP nyelvet Rasmus Lendorf készítette először. Később rengeteg programozó beszállt a fejlesztésbe, ahogy a nyelv egyre népszerűsödött. Miután a PHP alapjait teljesen újraírták, megszületett a PHPv3.70
Tulajdonságai:71

- Nyitott forráskód, GPL licensz

- Szerveroldali, nem kíván speciális böngészőt

- Többplatformos

- Több mint 600 ezer Web-helyen használják72

- HTML-be ágyazott

- Egyszerű szintaktika

- Kis erőforrásigény - az Apache moduljaként futhat

- XML kezelése

- Adatbázis kapcsolat mind szabad, mind kereskedelmi adatbázis-szerverekhez

- Fájlkezelő rutinok

- Szövegkezelő rutinok

- Sokféle változó, komplex adatszerkezetek lehetősége

- Képfeldolgozó rutinok - dinamikus képek előállítása

- és még sok más

Ez egy HTML-be beépülő nyelv, mely a szintaxisának egy részét a C, Java és Perl nyelvekből vette át. A PHP magas szinten integrálva van az Apache Web-szerver programba. Emiatt sokkal gyorsabb az Apache-PHP páros, mint az Apache-PerlCGI, mivel nem kell külső értelmezőt indítani.73 A másik fontos tényező az, hogy mivel szerveroldali a kód értelmezése, ezért a végfelhasználó a böngészőjében már csak HTML kódot kap, minden PHP kód HTML-lé lesz fordítva. Így egyrészt nem kell a böngészőnek az értelmezéssel törődni (mint pl. Java), másrészt az értékes munka, a Web-programozói kód sem kerül ki a szerverről és azt más így nem használhatja fel.
A PHP3 hátrányai: "

- Az Apache (tehát egyúttal a modulok, így a PHP3 is) mindvégig ugyanazon felhasználó jogaival fut [...] CGI esetén suEXEC vagy setuid bit segítségével el tudjuk érni, hogy a script biztonságosan a mi jogainkkal fusson. [...] Ezt azonban az Apache-on belül (a Unix biztonsági rendszerének felépítéséből következően) nem tehetjük meg - így vagy osztoznunk kell, vagy új process indítására kényszerülünk (lásd php3-cgi), de ezzel elvesztjük a PHP3 legnagyobb előnyét, a kezdési időt. A PHP3 tehát akkor ideális, ha az adott szerveren csak egyvalaki (például a webmaster) vagy egymással teljes mértékben együttműködők dolgoznak.

- A hosszabb, számításigényes feladatok lassan futnak, mivel a PHP3 utasításértelmezője lassú74 [...] Bonyolultabb feladatoknál érdemes áttérni Perl-re, vagy C-re.

- [...] az Apache több példányban fut egyszerre, és ez megnehezíti a letöltések közti adatmegtartást. Bár ez a probléma kis kényelmetlenség árán megoldható, de akinek feltétlenül megmaradó adatokra van szüksége, annak a Roxen Challanger Web-szervert ajánljuk."75

[13]

Ugyanúgy mint az Apache, a PHP is szét van darabolva különböző csomagokra annak érdekében, hogy csak azt kelljen felrakni, amire igazán szükség van. Ezáltal kevesebb erőforrást foglalunk le.

php3 php3-doc php3-dev php3-gd php3-imap php3-ldap php3-magick php3-mhash php3-mysql php3-pgsql php3-snmp php3-xml php3-cgi | Az alapcsomag. Ez tartalmazza a betölthető modulokat az Apache szerverhez, néhány extra funkciót nyújtó modult és a php2-php3 konvertert. Az Online dokumentációkat tartalmazza. A fejléc fájlokat tartalmazza (új modulok fordításához.) E modulnak a segítségével dinamikus grafikákat készíttethetünk (a libgd grafikus könyvtárat használva). IMAP76 függvények hívása közvetlenül PHP script-ből. LDAP77 funkciók meghívása közvetlenül PHP script-ből. ImageMagick78 funkciók meghívása közvetlenül PHP script-ből. MHASH79 funkciók meghívása közvetlenül PHP script-ből. MySQL kapcsolat létrehozása közvetlenül PHP script-ből. PostgreSQL kapcsolat létrehozása közvetlenül PHP script-ből. SNMP80 funkciók meghívása közvetlenül PHP script-ből. XML81 kezelő funkciók meghívása közvetlenül PHP script-ből. Egyedülálló (Apache nélküli) értelmező. Ekkor más Web-szervereket is használhatunk82. Minden fenti modul megtalálható CGI-s változatban is. Ezek az Apache-al is használhatóak, de akkor a sebesség kisebb lesz, viszont a futtató felhasználói jogkör megváltozhat.

3. táblázat - PHP3 csomagok a Debian-ban
Ha az Apache fut és php3 modul be van töltve, akkor egy egyszerű kis programocskával letesztelhetjük. Írjuk be ezt a shell prompt-ba:

    echo "<?php phpinfo() ?>" > /var/www/phpteszt.php3

Ezután ízlés szerint kedvenc böngészőnkkel tekintsük meg az oldalt, pl.:

    lynx http://localhost/phpteszt.php3

Ha minden jól be van állítva, akkor itt egy hosszú információs oldal keletkezik, amely a szervergép és a rajta futó Web és PHP programok adatait listázza ki.
A továbbiakban bemutatok egy egyszerű programrészletet ízelítőnek. A programozás részletes bemutatása meghaladja e munka kereteit. Javaslom az Online dokumentáció és a szakirodalom (pl. [3]) tanulmányozását a Web-programozásban érdekelteknek. Információk a hivatalos Web-oldalon bőven fellelhetőek: http://php.net. Néhány hasznos tipp és trükk: http://phpclub.unet.ru/index_e.php3
A következő egyszerű programocska a "Hello világ!" PHP-s megvalósítása83. Természetesen ez korántsem mutatja meg a PHP erősségeit. Három fájlt készítünk. Az első egy függvény (include) fájl. Innen rutinokat hívhatunk meg - nem kell megírni minden egyes .php3 84 fájlba egy adott függvényt.
Az első fájl két függvényt tartalmaz. Az első az oldal címét változtatja meg, a második pedig számokat ír ki ciklus segítségével.
/var/www/hello.inc:

    <?php

    function printtitle()

    {

    print "<title>Helló a hello.inc fájlból.</title>\n";

    }

    function printnumbers($start)

    {

    print "<H2>";

    for($temp=0; $temp < 5; $temp++)

    {

    print $start++ . "<br>\n";

    }

    print "</H2>";

    }

    ?>

Ez a fájl egy HTML fájl, mely PHP kódot tartalmaz. Ebből hívjuk meg az előző hello.inc fájlt, hogy kiírjuk a lap címét.
/var/www/hello.php3:

    <HTML>

    <?php include("./hello.inc") ?>

    <HEAD>

    <?php printtitle() ?>

    <META HTTP-EQUIV="pragma" CONTENT="nocache">

    </HEAD>

    <BODY>

    A szövegtest kezdete<p>

    <?php

    printnumbers(7);

    ?>

    <p> A szövegtest vége<p>

    </BODY>

    </HTML>

Ha futtatjuk az oldalt egy böngészőben (jelen esetben a lynx-ben) akkor a következő képet kapjuk vissza:

    Helló a hello.inc fájlból.

    A szövegtest kezdete

    7

    8

    9

    10

    11

    A szövegtest vége

A Potato-ban a PHP csomagok karbantartója Madarász Gergely. A PHP dokumentációjának magyar fordítása letölthető innen: http://weblabor.hu/php
A Debian Potato-ban 33 csomag foglalkozik a PHP3-al, 14 pedig a PHP4-el (Lásd később).

##
11. MySQL alapok (adatbázis szerver)

A MySQL egy igazi többfelhasználós, többszálúsított SQL adatbázis szerver. Jelenleg az SQL (Structured Query Language, Strukturált Lekérdező Nyelv) a legelterjedtebb és szabványos adatbázis nyelv világszerte. A rendszer kliens/szerver felépítésű.
A MySQL legfőbb erényei a gyorsaság, robusztusság és a (viszonylag) könnyű használat. 1996-ban kezdték fejleszteni a T.c.X. nevű cégnél., ahol azóta több mint 40 adatbázisban tárolnak 10000 táblát, melyből csak 500-ban 7 millió sor van. Ez kb. 100GB adat.
A MySQL-t a http://web.mysql.com hálószemen érhetjük el. Itt található Online dokumentáció, melynek nagy része természetesen benne van a Debian-ban is.
A MySQL sajnos nem teljesen szabad szoftver85. Saját licenszpolitikájuk viszont megengedi ingyenes használatát sok platformon és szituációban. A mi esetünk:
" 3.5.4 Running a web server using MySQL: If you use MySQL in conjunction with a web server on Unix, you don't have to pay for a license. This is true even if you run a commercial web server that uses MySQL, because you are not selling MySQL itself."86
Vagyis, ha egy Linux-os Web-szerveren futtatjuk, legyen az akár üzleti célú is, számunkra ingyenes a használata.
Licenszet akkor kell vásárolni, ha:

- Eladjuk a MySQL szervert egy másik termék vagy szolgáltatás részeként.

- Pénzt kérünk a MySQL telepítéséért és üzemeltetéséért valakitől.

- Beletesszük egy olyan terjesztésbe, amiért pénzt kérünk és az nem terjeszthető ingyenesen tovább.

- Nem UN*X platformon futtatjuk / használjuk.

Ekkor licenszet kell venni minden olyan gépre, amin a szerver fut. Az egyik kliens kódja GPL alatt van, ezért arra ezek nem vonatkoznak.
Itt [8] egy hasznos olvasmány a papíralapú dokumentációt kedvelőknek. Ezek [9],[10],[11] pedig az SQL nyelvet taglalják.
A következő címen MySQL + PHP mintapéldákat találhatunk:
http://www.wernhart.priv.at/php

libmysqlclient6 libmysqlclient6-dev mysql-gpl-doc mysql-gpl-client mysql-manual mysql-doc mysql-client mysql-server www-mysql xmysqladmin | 3.22.30 3.22.30 3.22.30 3.22.30 0.95 3.22.32 3.22.32 3.22.32 0.5.7 1.0 | a kliens oldal függvénykönyvtára fejléc fájlok fejlesztőknek Online dokumentáció GPL licensz alatt info, HTML, és text formátumban GPL-es kliens binárisok Mike Miller nemhivatalos kézikönyve. Ez a non-free szekcióban található. Már idejétmúlt, de hasznos lehet a non-free Online dokumentáció a non-free kliens binárisok az adatbázis-szerver motorja Web-interfész - segítségével SQL parancsok építhetőek be a Web-oldalakba. A parancsok a szerveren hajtódnak végre és az eredményt HTML-ben küldi el a felhasználónak egy frontend (kliens) az adatbázis motorhoz. X11 grafikus rendszerekben használható, funkciói: a szerver újraindítása, státusz ellenőrzés, folyamat ellenőrzés, jogosultságok kezelése, adatbázisok / táblák kezelése

4. táblázat - MySQL csomagok a Debian-ban

A szerverre nem elég feltenni a mysql-server csomagot. Ha ott akarjuk kezelni az adatbázisokat / táblákat is ssh segítségével, akkor valamelyik klienst is fel kell tenni. Érdekes lehet egy távoli gépről karbantartani az xmysqladmin segítségével is, mely könnyen kezelhető grafikus megoldást kínál. Ez esetben a programot telepítsük inkább a távoli gépre. Ha nem a szerveren végezzük a feltöltést, akkor a mysql portját is engedélyeznünk kell a megfelelő hálózatok felé. Ez azonban elég veszélyes is lehet. Javaslatom az, hogy egy jól megírt PHP-s programmal tartsuk karban az adatbázist a Web-szerveren keresztül. (SSL és felhasználó-azonosítás segítségével) Ekkor a mysql csak a szerveren belül lesz (legyen) elérhető.
A MySQL hibaüzeneteinek egy része már le van fordítva magyar nyelvre is.