• 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)

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-kat¹⁵



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.

• 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.”³³

• a világ Internetes Web-szervereinek 60%-án ez fut⁵³



• 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

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

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

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.

# 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

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

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

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

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”

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

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

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.

• 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

• 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.

• 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”-t⁶¹ é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.

• 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⁶², vagy a pgp⁶³, szerver oldalon a TLS-képes⁶⁴ 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)

• 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)

• 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)

• 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

• 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)

• 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

• “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.)

• 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ák⁷²



• 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

• 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ú⁷⁴ […] 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.”⁷⁵ [13]

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

lynx http://localhost/phpteszt.php3

<?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>";

}

?>

<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>

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

A szövegtest kezdete

7

8

9

10

11

A szövegtest vége

• 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.