Eddigi ZH-kérdések

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen KornAndras (vitalap | szerkesztései) 2006. november 27., 19:45-kor történt szerkesztése után volt.

Az alábbiakban leírom az eddig szerepelt zh-kérdéseket, a hozzájuk tartozó helyes válaszokat (ezeket a zh-ban elvárt minimális részletességnél szabatosabban kifejtve), és esetleg néhány, a hallgatók által írt választ, kommentárokkal. Az olvashatatlan szavakat "????" jelöli; a megtippelt, de nem jól olvasható szavakat "????megtippelt_szó????". A helyes válaszokban zárójelben szereplő mondatok csak kiegészítik a választ, nem elvárás, hogy a zh-ban is leírjátok őket.

A megadott pontszámok a zh-ban szereplő pontszámok; elvileg a kérdések relatív nehézségén és fontosságán kívül azt is hivatottak tükrözni, mennyire részletes választ várok el. A későbbiekben a tapasztalatok alapján ezek a pontszámok módosulhatnak, és egy itt leírt négypontos kérdés legközelebb szerepelhet pl. hatpontosként.

Sajnos a zh-k helyesírása és magyarsága több esetben hagyott kívánnivalót maga után. Szerintem helytelenül írni igénytelenség. Ezzel persze nem kötelező egyetérteni, és a pontozásnál sem vettem figyelembe a nem értelemzavaró hibákat, de azért próbáljatok erre is odafigyelni.

Tartalomjegyzék

1 Unix-alapok

  • Mit jelent a kiegészítő csoporttagság (supplementary group membership)? (4 pont)
Helyes válasz:
Egy unixos felhasználónak van egy felhasználó-azonosítója (UID) és egy csoport-azonosítója (GID), vagyis egy csoportnak mindenképpen tagja. Ez az elsődleges csoporttagság. Emellett a felhasználó más csoportoknak is tagja lehet; a /etc/group fájlban (vagy az ezt helyettesítő címtárban/adatbázisban) fel van sorolva, hogy az egyes csoportoknak mely felhasználók a tagjaik. Amikor a felhasználó belép, az őt beléptető processz a login shell elindítása előtt belép ezekbe a csoportokba is, és ezeket a csoporttagságokat a shell örökli tőle. Így tehát igazából a kiegészítő csoporttagságok halmaza a unixos processz egyik állapotváltozója.
Ha egy processz tagja egy csoportnak, akkor vonatkoznak rá a fájlrendszerben a csoportra vonatkozó jogosultságbitek.
Egy válasz a zh-ból (betű szerint):
az amikor egy felhasználó a /etc/group fileban nem csak a saját group-jában szerepel, hanem egyibb csoportokban is pl: audio,floppy. Így több fájlhoz is hozzáférhet a filok nála groupra vonatkozó rwx csoportnál ezeket a csoport tagságokat is figyelembe veszi. csak a változtatás után indított process-ekre igaz, hiszen igazából nem a felh.nak, hanem a process-eknek van UID-jük és GID-jük.
Kommentár: A válasz 2,5 pontot ér; több súlyos tévedést is tartalmaz, de ezekre szerencsére részben nem vonatkozott a kérdés.
A /etc/group file-ban az egyes csoportok tagjai vannak felsorolva, nem az, hogy az egyes felhasználók mely csoportoknak tagjai (ha így lenne, az utolsó csoporttag törlésével elvesztenénk a csoportot is). A /etc/group amúgy csak a kiegészítő csoporttagságokat tartalmazza, a felhasználó a GID-jához tartozó csoportnál alapértelmezés szerint nincs felsorolva.
Ha egy felhasználót berakunk egy új csoportba, akkor az általa indított új processzek nem kapják meg automatikusan az új csoporttagságot, hiszen a csoporttagságokat a szülőfolyamatuktól öröklik, az pedig nem rendelkezett ezzel a csoporttagsággal. Az új csoporttagságra új login session indításával vagy a newgrp segítségével lehet ténylegesen szert tenni.

2 IP-alapok

  • Hogyan működik a SYN támadás? (8 pont)
Helyes válasz:
A TCP SYN-elárasztás a TCP-kapcsolatfelépítés (handshake) egy sajátosságát használja ki. A kapcsolatot kezdeményező kliens először olyan csomagot küld a szervernek, amelyen a SYN bit be van állítva, egy kezdeti szekvenciaszámmal. A szerver erre egy SYNACK csomaggal válaszol, a saját szekvenciaszámával. Végül a kapcsolat létrejön, amint a kliens visszaküld egy olyan csomagot, amelyben csak az ACK bit van beállítva, és a szerver kezdeti szekvenciaszámát nyugtázza.
Ahhoz azonban, hogy a szerver el tudja dönteni, hogy egy beérkező ACK üzenet egy kapcsolat-felépítés utolsó üzenete-e, meg kell jegyeznie, melyik kliensnek milyen kezdeti szekvenciaszámú SYNACK csomagot küldött. Ezek az adatok a TCP kapcsolatpuffer (TCP backlog-queue) nevű adatstruktúrában tároldónak, amelynek a mérete véges (gyakran portonként csak pár tucat félig nyitott kapcsolat tárolására elegendő).
A SYN-elárasztás során a támadó rengeteg SYN csomagot küld, gyakran hamis IP-címről, ám egyik kapcsolat felépítését sem fejezi be ACK üzenettel, így a szerver puffere megtelik, nem képes új kapcsolatokat fogadni. A pufferben tárolt ún. félig nyitott kapcsolatok egy idő után, ha addig nem érkezik rájuk ACK, törlődnek; ám ha a támadó csomagok gyorsan jönnek, akkor elárasztják a tárolót, és az áldozat nem lesz képes a legtöbb legitim kliens kérésének feldolgozására.
Egy válasz a zh-ból (betű szerint):
A TCP-kapcsolat felépítésének normális menete a SYN - SYN ACK - ACK protokollfutam.
Ezzel kétféleképp lehet visszaélni:
a) Az ún 'SYN flood' támadás során a támadó nagymennyiségű SYN csomaggal árasztja el a célpontot (noha valódi kapcsolatfelépítési szándéka feltehetőleg nincs). Ez a célpontot beéníthatja, lefagyaszthatja, túlterhelheti (különösen az egyszerűbb hálózati eszközöket). DoS támadás.
b) Egyszerű tűzfalak (amelyek nem állapotkövetőek, és csak a felépítést szolgáló csomagokra tartalmaznak szűrőfeltételeket) "becsaphatók", ha - nemlétező - sequence numberrel ellátott ACK csomagot küld a támadó.
A syncookies ezeket a támadásokat hatékonyan képes elhárítani.
Kommentár: a válasz 4 pontot ér. A kérdés az "a)" részben leírt támadásra vonatkozott, ennek az ismertetése azonban nem elég részletes; nem derül ki, mi okozza a túlterhelést, melyik erőforrás fogy el (hogyan különbözik egy SYN-elárasztás egy tetszőleges más csomagfajtával való elárasztástól?).
A "b)" jelű támadásról nem derül ki, mitől "SYN támadás", és hogy mit nyer a támadó azzal, ha egy "nem létező" szekenciaszámú ACK csomaggal "becsapja a tűzfalat", de még az sem, mit jelent az, hogy egy szekvenciaszám nem létezik, vagy hogy az ACK csomag saját szekvenciaszámáról, vagy az általa nyugtázott szekvenciaszámról van szó.
Akárhogy is, a syncookies mechanizmus csak az első ellen "véd" (a szó egy tág értelmében), a második ellen nem.

  • Mire való a PMTU discovery és hogyan működik? (7 pont)
Helyes válasz:
L. az IP-alapok szócikkben; felesleges itt megismételni.
Egy válasz a zh-ból (betű szerint):
Path Maximum Transfer Unit Discovery: A maximális csomagmeret meghatározásár a szolgáló algoritmus, amely arra szolgál, hogy a kapcsolat kezdeményezője megállapítsa, hogy mekkora csomagokat küldhet az adott címzett felé.
A kapcs. kezdeményező fél először egy előre beallított MTU meretű csomagot küld a címzettnek. Ezután a ????visszafelvő???? üzenetek (ICMP) alapján ????binalis???? kereséssel megkeressük az MTU-t. Ha a csomag átmegy, akkor megduplázzuk az előző méretet, ha viszont egy router "Fragmentation needed" üzenetet küld vissza, akkor az (MTUi+MTUi-1)/2-vel próbálkozunk és így tovább ????binalis???? kereséssel. Az IP elvi határa 64k az MTU-ra, de a különböző adatkapcsolati és fizikai rétegek általában 1-2MB (sic!) közötti értékeket engednek meg.
Kommentár: A válasz a sok pontatlanság és egy darab, a Richter-skálán mérhető tévedés miatt csak 3 pontot ér.
1. A PMTU discovery egy TCP-kapcsolat mindkét viszonylatában lejátszható, nemcsak a kliens->szerver irányban.
2. A válasz nem tér ki a DF (Don't Fragment) bit szerepére.
3. A csomagméret megduplázása problémás lehet, hiszen ezzel a saját interfészünk MTU-jánál nagyobb csomagméret is előállhat.
4. Ha a saját interfészünk MTU-ja túl nagy, és ICMP fragmentation needed üzenetet kapunk, nincs í mínusz egyedik MTU, amit felhasználhatnánk, hiszen ez volt az első csomag - akkor viszont hogyan számítsuk ki a másodiknak a méretét?
5. Ha valahogyan eljutottunk a 800 byte-hoz (mondjuk a 400 duplázásával), és a 800 túl nagy, akkor a leírt algoritmus szerint először a 600-zal kellene próbálkoznunk, de ha az még átfér, akkor ezt duplázva, 1200-zal - az viszont több, mint 800, és már a 800 se fért át.
6. Az az 1-2MB nagyon sok lesz...

  • Mire való az ARP? Milyen üzenetei vannak? (5 pont)
Helyes válasz:
Az ARP arra való, hogy az egy fizikai hálózaton levő IP-vel kommunikálni vágyó számítógépek fel tudják deríteni egymás fizikai rétegbeli címét. Etherneten és az Ethernetre elegendően hasonlító hálózatokban használják.
Két üzenete van: a kérdés ("who-has 1.2.3.4 tell 1.2.3.1") és a válasz ("1.2.3.4 is-at 00:f0:0d:d0:0d:00").
(Az ARP nem IP-csomag, így nincs IP-fejléce.)
Adatkapcsolati szinten a kérdés forráscíme annak az állomásnak a címe, amely a választ tudni szeretné; a célcím a broadcast.
A válasz forráscíme annak az állomásnak a címe, amely tudja a választ (ez nem feltétlenül a keresett állomás); a célcím a kérdező állomás címe.
(Az ARP-kérdést elvileg nem muszáj broadcastként feltenni, de ez a leggyakoribb.)
(Az ARP elvileg többféle Ethernet felett szállítható protokollt is támogat.)
(Az ARP-kérdés a payloadban is tartalmazza a kérdező hardvercímét, és igazából erre a címre kell küldeni a választ.)
(Elvileg a RARP-üzenetek is az ARP-hez tartoznak, de nemigen használ ilyet senki.)
(A "who-has" és az "is-at" nevek a tcpdumphoz fűződnek, a szabvány kevésbé szemléletes neveken emlegeti az üzeneteket.)
Egy válasz a zh-ból (betű szerint):
ARP
IP->MAC megfeleltetés
who-has src mac: saját valós mac
dst mac: FF:FF:FF:FF:FF:FF
src IP: saját IP
dst IP: a cél IP-je
is-at src mac: cél saját mac-je
dst mac: saját mac
src IP: cél IP-je
dst IP: saját IP
Kommentár: a válasz 2,5 pontot ér. Súlyos hiba, hogy az ARP-t IP fölötti protokollként képzeli el. Nem írja le továbbá a who-has és az is-at üzenetek tartalmát.

3 DNS

  • Mekkora legyen egy rekord TTL-je? Miért éppen annyi? Miért baj, ha túl nagy, és miért baj, ha túl kicsi? (6 pont)
Helyes válasz:
Egy rekord TTL-je akkora legyen, hogy lehetőleg éppen a következő tervezett módosítás előtt járjon le. Ha nem tudjuk, mikor lesz a következő módosítás, akkor akkora legyen, amennyi ideig vállalható, hogy kliensek esetleg még a rekord régi tartalma szerint járnak el; tehát pl. az előző címén keresik a webszervert.
Ökölszabály: várhatóan lassan változó rekordok TTL-je legyen néhány órás (vagy akár néhány napos). Nem valószínű, hogy gyakran változna pl. egy domain MX-ének a neve, tehát az MX rekord TTL-je akár egy hét is lehet; a névhez tartozó IP viszont talán megváltozhat "váratlanul" (pl. mert átmegyünk másik hosting-szolgáltatóhoz, vagy mert DNS alapú failovert valósítottunk meg), így ennek a TTL-je lehet jóval alacsonyabb (néhány óra, vagy failover esetén akár csak öt perc).
Ha a TTL túl nagy, az azért baj, mert akkor a rekord tartalmának megváltoztatása után sokáig lehetnek olyan kliensek, akik a rekordnak még az előző tartalmát ismerik, és rossz gépnek próbálják kézbesíteni a leveleinket, rossz DNS-szervertől érdeklődnek a hosztneveinkről s.í.t. Ha az ebből adódó problémákat el akarjuk kerülni, akkor a rekord megváltoztatása után még legalább a TTL-ben megadott ideig mindkét címen (az újon és a régin) nyújtanunk kell a szolgáltatást.
Ha a TTL túl kicsi, az azért baj, mert a kliensek csak rövid ideig cache-elik a rekordok tartalmát és feleslegesen gyakran fordulnak a DNS-szerverünkhöz; így a szervernek megnő a terhelése, a kliensek pedig lelassulhatnak (mert pl. két kattintás között megint le kell kérdezni a webszerver IP-címét).
(Van olyan DNS-szerver, pl. a djbdns, amely tervezett DNS-változtatásokat úgy támogat, hogy a megváltoztatandó rekord TTL-jét minden válaszhoz egyenként kiszámítja úgy, hogy éppen a tervezett változtatás pillanatában járjon le.)
Egy válasz a zh-ból (betű szerint):
Általában néhány óra legyen egy DNS rekord TTL-je, ez szabja meg, hogy a kliens ezt meddit cachelheti. Ha túl nagy a TTL azzal az a baj, hogy lehet, hogy a rekord valami miatt megváltozott és erről csak nagyon későn a TTL lejárta után értesül a kliens. Ezért szolgáltatás kiesést okozhat.
Ha túl kicsi azzal az a baj, hogy folyton lekérdezi a kliens ezzel megterheli a DNS szervereket. Ezért optimális a pár óra. Ha nagyobb karbantartást szeretnénk végezni, akkor ????érdemes???? a TTL-t ????1-re 1s-ra???? ????állítani????, megvárni míg a régi ????lejár???? majd ????utána???? elvégezni a karbantartást, ezzel gyakorlatilag 0 lesz a szolgáltatás kiesés.
Kommentár: A válasz 4 pontot ér.
Alapvetően jó, de nem írja le, hogy a néhány óra egy olyan ökölszabály, amitől bizonyos esetekben érdemes eltérni (l. a DNS-alapú failover, ill. a szinte biztosan hosszú életű rekordok esetét).
Csak az ökölszabályt írja le, nem próbálja mérnöki módon megfogalmazni, mi alapján döntsük el, mennyi legyen a TTL.
Nem említi, hogy a szolgáltatáskiesés elkerülhető, ha a régi címen is fenntartjuk a szolgáltatást a TTL lejártáig (ami persze költséges és/vagy lehetetlen lehet).
Nem említi, hogy kliensoldalon is eredményezhet lassulást a túl kicsi TTL.

  • Mi a baj a glueless delegációkkal? Ugyanakkor mi a jó bennük? (10 pont)
Helyes válasz:
Egy delegáció kétféleképpen lehet glueless. Az egyik eset az, amikor olyan szervernek delegálunk egy domaint, amelynek a nevére nem vagyunk autoritatívak (pl. mondjuk a .hu-ra autoritatív szerver az ns.foo.com-nak delegálja a foo.hu domaint). Ebben az esetben a delegáló szerver nem adhatja át glue-ként a delegációban szereplő szerver A rekordját a kliensnek, mivel nincs joga nyilatkozni arról a domainről, amelybe az a szerver tartozik; a .hu nameserver nem autoritatív a .com-ra (elvileg lehetne autoritatív arra is, de ez most mindegy).
A másik eset az, amikor a delegáló szerver adatbázisába szándékosan nem vesszük fel az alárendelt szerver A rekordját annak ellenére, hogy megtehetnénk (mert autoritatívak vagyunk a nevére). Ez elég nagy marhaságnak tűnik; remélem, a valóságban senki nem csinál ilyet.
A baj a glueless delegációval az, hogy a kliensnek újra kell kezdenie a feloldást, esetleg a gyökértől, hogy megtudja a megkérdezendő szerver IP-címét; ha közben újabb glueless delegációval találkozik, akkor megint, s.í.t. Így nem biztos, hogy adható felső korlát egy feloldás memóriaigényére. Ráadásul a glueless-ség körbeérhet, és ebben az esetben a körben szereplő egyetlen domain sem oldható fel.
Pl. ha az a.com nameservere az ns.b.net, a b.net-é az ns.c.hu, a c.hu-é az ns.d.org, a d.org-é pedig az ns.a.com, akkor egyik domain sem elérhető, ha a delegációk glueless-ek, de mire ez kiderül, a rekurzív rezolver elpazarolt egy csomó időt és memóriát.
A glueless delegáció egyetlen "előnye" az, hogy a delegációval kapcsolatos NS rekordot tartalmazó zónába nem kell felvenni a delegációt kapó DNS-szerver A rekordját, így ezt a rekordot karbantartani sem kell, ha megváltozna (ehhez persze viszonylag bonyolult üzleti folyamatok tartozhatnak, úgyhogy nem feltétlenül egyszerű). Ez roppant kényelmes a delegációt végző szerver üzemeltetője számára, csak mindenki mással kitolás.
Hogy a mi domainjeinkre mutató delegációk gluelessek-e, azt mi magunk is befolyásolhatjuk; ha ügyelünk arra, hogy a domainre autoritatív szerver neve a domainen belül legyen (tehát a foo.com nameserverének neve a foo.com domainbe tartozzon, mondjuk ns.foo.com vagy a.ns.foo.com), akkor adunk esélyt a glue-nak.
Egy válasz a zh-ból (betű szerint):
A DNS-szerver a kérdezőnek delegáláskor a glue-ban átadhatja egy a keresett domainnel azonos zónába eső nameserver IP címét. Ez jó, mert így nem kell külön feloldani a nameserver ????nevét????, növekszik a DNS hatékonysága. Pl. a pool-foobar.axelero.hu megkérdezi a .hu zónáért felelős nameservert, hogy mi a www.bme.hu IP címe. A szerver válaszol, hogy ő nem authoritatív, de kérdezze meg az ns.bme.hu-t. Ilyenkor a kliensnek fel kellene oldani az ns.bme.hu-t is, ezt azonban a nameserver átadhatja glue-ban. Ha pl. a www.bme.edu-t próbáljuk meg feloldani, és a .hu-ért felelős name servertől kapjuk meg az ns.bme.edu IP címét, azt nem hisszük el neki.
A glueless delegációk rontják a DNS hatékonyságát, jó bennük, hogy pl. minden további nélkül megváltoztathatjuk a name serverünk IP címért, mert mindig feloldásra kerül a neve. Ez az előny elenyésző, érdemes használni a glue-t.
Kommentár: a válasz 9 pontot ér. Hibák:
A .hu zónáért felelős szerver természetesen autoritatív minden, a .hu alatti névre, így a www.bme.hu-ra is. Nem azt válaszolja az erre vonatkozó kérdésre, hogy nem autoritatív (ilyen válasz a DNS-ben gyakorlatilag nem is lehetséges), hanem egy delegációt tartalmazó választ küld.
Ha a .hu zónáért felelős szerver egy másik, .hu alatti szervernek delegál egy zónát, akkor annak a címét illik is átadnia glue-ban, hiszen kitől kérdezhetnénk meg, ha a .hu szerverek nem mondják meg?
A válasz első fele részben redundáns volt; nem volt kérdés, mi a glue (de persze inkább írjatok többet, mint kevesebbet). Ugyanakkor ez a bevezető győzött meg arról, hogy a hallgató valószínűleg érti, miért rontja a glueless delegáció a DNS hatékonyságát, mert azt külön nem írta le.

  • Mi a DNS poisoning, hogyan működik és hogyan lehet ellene védekezni? (12 pont)
Helyes válasz:
Legalább háromféle DNS poisoningot érdemes megkülönböztetni. Az egyik esetben a támadó az általunk megszólított nameserver helyett válaszol, és a válasz tartalmával mérgezi meg a cache-ünket (ezt akkor tudja könnyen megtenni, ha le tudja hallgatni a kérdést). Ezt a támadást DNS spoofingnak vagy DNS forgerynek (hamisításnak) is nevezik.
A másik eset az, amikor a támadónak van egy domainje, mondjuk a foo.bar, és ennek valamelyik szubdomainjét delegálja - mondjuk - az ns.bme.hu-nak: ize.foo.bar. NS ns.bme.hu., és ehhez a válaszhoz glue-ként mellékeli az ns.bme.hu állítólagos IP-címét, de nem a valódit, hanem egy olyan címet, amit ő ellenőriz: ns.bme.hu. A 1.2.3.4 , ahol 1.2.3.4 a támadó szervere. Ha a kliensszoftver hibás, és elfogadja a glue-t annak ellenére, hogy a foo.bar nameserver nem autoritatív a bme.hu domainre (és így nincs joga nyilatkozni az ns.bme.hu IP-jéről), akkor a cache-ben a támadó által megadott - vélhetően jó hosszú - TTL lejártáig tárolja, hogy az ns.bme.hu IP-je 1.2.3.4. Ezután, ha ez a kliens olyan domainhez tartozó nevet próbálna feloldani, amire az ns.bme.hu autoritatív, az 1.2.3.4-hez fog fordulni, hiszen "tudja", hogy az ns.bme.hu IP-je ez. Így a támadó az ilyen módon "eltérített" szervernek szóló összes kérdésre adott választ ellenőrizheti, átírhatja.
Ennek a támadásnak egy variánsa az, ha irreleváns Authority sectiont rak a támadó a válaszába, amiben pl. azt mondja, hogy bme.hu. NS ns.foo.bar., holott ezt nem is kérdezte senki.
A harmadik fajta támadás lényege az, hogy a támadó man-in-the-middle támadást valósít meg egy primary és egy secondary nameserver között (vagy egyéb módon eléri, hogy a secondary őhozzá forduljon AXFR-rel a primary helyett), és az AXFR-rel átvitt adatokat "röptükben" átírja. Így a secondaryn a támadó által elhelyezett hamis adatok lesznek, úgyhogy azok a kliensek, akik a secondaryhoz fordulnak, a hamis válaszokat fogják megkapni. Ha a primaryt a támadó valahogyan ki tudja vonni a forgalomból, akkor minden kliens a hamis adatokat látja.
Az első támadás ellen gyakorlatilag nem lehet védekezni (nem húzhatunk ki VPN-t a világ összes DNS-szerveréhez). A saját ellenőrzésünk alá tartozó szakaszon megnehezíthetjük a lehallgatást, de nagyjából ennyi. A lehallgatásra amúgy azért van szükség, mert minden DNS-kérés tartalmaz egy 16 bites azonosítót (amit amúgy nonce-nak hívnak), aminek a válaszban is szerepelnie kell; ha a támadó nem tudja, milyen nonce-szal ment ki a kérés, meg kell tippelnie, mit írjon a válaszba. Ha emellett a kérés forrásportja is véletlenszerű, összesen kb. 31-32 bitnyi véletlenséget (azért nem 32, mert jó pár forrásport kizárható) tudunk vinni a kérésbe, úgyhogy a vak tippelés nehézzé válik.
A második támadás ellen úgy védekezhetünk, hogy nem fogadunk el olyan glue-t, amelyre az a szerver, amelytől kapjuk, nem autoritatív; a példában az ns.bme.hu IP-címét a gyökértől indulva külön meg kellett volna keresni a "hagyományos" feloldóalgoritmussal.
Természetesen abban az esetben, ha a támadó szervere valóban autoritatív a .hu-ra vagy a .bme.hu-ra, azt hazudik az ns.bme.hu IP-jével kapcsolatban, amit csak akar; sőt, mivel ő mondja, definíció szerint az lesz az igazság. Ezért veszélyes, ha egy a DNS-hierarchiában "magas szinten álló" nameserverre betör valaki. Ez ellen max. úgy védekezhetünk, ha megpróbáljuk az összes választ az összes, rá autoritatív szervertől beszerezni, aztán pl. többségi szavazással eldöntjük, melyik választ fogadjuk el. Ez elég lassú lenne.
A harmadik támadás ellen a saját szervereink esetében úgy védekezhetünk, hogy biztonságos VPN-t húzunk ki a két szerver között, és efölött AXFR-ezünk, vagy AXFR helyett valamilyen más, biztonságos, hitelesített átviteli módszert alkalmazunk (pl. rsync over ssh). Más szerveren így elhelyezett hamis adatok ellen gyakorlatilag nem tudunk védekezni (max. a többségi szavazásos módszerrel, de az nem hatékony és nem is 100%-os).
Érdemes a Wikipédián utánaolvasni, ha nem lenne világos.
(Ennyire részletesen nem kell leírni a válaszban.)
Egy válasz a zh-ból (betű szerint):
Ha egy támadó man-in-the-middle szerűen ???? be tud épülni egy kliens és egy DNS szerver közé, vagy két DNS szerver közé, akkor elcsípheti a DNS lekérdezéseket és meghamisíthatja a válaszokat.
De ha például a támadó egy kiszemelt áldozatnál azt szeretné elérni, hogy a www.otp.hu címre az ő "phishing" oldala jöjjön be, akkor ezt sokszor beékelődés nélkül is megteheti, hiszen a DNS protokoll a kapcsolatnélküli UDP felett működik, tehát a támadónak csak folyamatosan, rövid időközönként "DNS Reply" válaszüzeneteket kell küldenie az áldozatnak, az eredeti DNS szerver nevében. Ezt UDP esetén egyszerűen megteheti, hiszen csak az IP fejléc source IP mezejét kell a DNS szerver IP-jére állítania, és a DNS üzenet tartalma pedig az, hogy a www.otp.hu IP címe a támadó szerverére mutat. Ilyenkor ha az áldozat egy DNS lekérdezést küld az otp.hu-ra és a támadó válaszcsomagja érkezik meg hamarabb, ????akkor???? ????máris???? sikeres volta "poisoning".
Védekezési lehetőségek:
* Minden lekérdezés tartalmaz egy nounce-ot, ami a válaszban is szerepel.
* DNS protokoll TCP feletti használata
* A DNS szerver hitelesíti magát, pl. PKI kiépítése esetén a válaszokban a kliens által küldött nounce a szerver titkos kulcsával le van titkosítva. (Nyilv. kulcsú digitális aláírás)
Kommentár: a válasz 6 pontot ér.
Nem tér ki a poisoning többféle módozatára, főleg a glue-alapú módszer leírása hiányzik.
Nem magyarázza el, mi a nonce (nem nounce, de ez mindegy), és hogyan segít a védekezésben.
Nem derül ki, miért jó a támadónak, ha két DNS-szerver közé épül be, mint man int the middle (talán az AXFR-es támadásra gondolt a hallgató, de nem írta le).

  • Mit jelent a DNS-ben a "classless" delegáció? Mikor használnak classless ("de Groot") delegációt és miért? Mutasson példát classless delegációra! (10 pont)
Helyes válasz:
A reverse DNS (PTR rekordok rendszere) megalkotásakor A, B és C osztályú címekben gondolkodtak.
A reverse DNS gyökere az in-addr.arpa. zóna; ennek a szubdomainjeit delegálják az egyes IP-tartományok üzemeltetőinek, hogy reverse DNS szolgáltatást tudjanak nyújtani. A DNS-ben a pont karakter választja el egymástól a hierarchia szintjeit; ha tehát pl. a 4.0.0.0/8-as hálózat teljes reverse-tartományát akarjuk delegálni egy nameservernek, akkor valami ilyesmit írhatunk az in-addr.arpa. zónafájljába: "4.in-addr.arpa. NS ns1.Level3.net.". Hasonlóképpen, ha a 152.66.0.0/16-os hálózat reverse delegációját nézzük, akkor egy "66.152.in-addr.arpa. NS ns.bme.hu." jellegű bejegyzést találunk majd a 152.in-addr.arpa. zónafájljában.
Látható, hogy a reverse delegációnak ez a módja csak nyolccal osztható netmaskú alhálózatra működik; ha pl. a 172.16.0.0/12-höz tartozó reverse domaint akarnánk delegálni, gondban lennénk, mert a 16.172.in-addr.arpa túl szűk (a /12-es tartomány a 172.16.0.0-172.31.255.255 címeket foglalja magában), a 172.in-addr.arpa pedig túl tág.
Kézenfekvő, hogy delegáljuk egyenként az összes reverse zónát 16.172.in-addr.arpától 31.172.in-addr.arpáig; ez 16 db NS rekord felvételét jelentené. A módszer kifogástalanul működik is, csak az a hátránya, hogy ha a delegációt fogadó, tehát a reverse zonáért ténylegesen felelős szerveren BIND, vagy egy BINDra hasonlítani vágyó program fut, akkor mind a 16 "önálló" domainhez külön zónafájlt kell létrehozni, és ezekre hivatkozni kell a konfigurációs fájlban. Ez nyilván olyan rettenetes megterhelést jelent, hogy mindenáron el kell kerülni; ezt a célt szolgálja a "classless" delegáció (amúgy érdemes elolvasni az [RFC2317]-et, akad benne marhaság a javából).
(A BIND-felhasználók számára amúgy még rosszabb lenne a helyzet, ha pl. egy /25-ös hálózat reverse zónáját delegálná nekik valaki 128 darab NS rekorddal: 128 darab zónafájlt kellene létrehozniuk. Természetes, hogy egy szoftver tervezési hibáit egy új szabvánnyal kell maszkolni; ezért született meg az RFC2317. Nyilván a véletlen műve, hogy az RFC egyik szerzője az a Paul Vixie, aki a BIND-ot jegyző Internet Software Consortium munkatársa is. A sorok között ne olvassatok, oda nem írtam semmit! :)
Példa. Tegyük fel, hogy az 1.2.3.4-es és az 1.2.3.5-ös IP-cím a miénk; a nameserverünk az ns.foo.com. Ez ugye az 1.2.3.4/31-es hálózat. "Classful" delegáció esetén két darab NS rekorddal intéznénk el a delegációt: "4.3.2.1.in-addr.arpa. NS ns.foo.com." ill. "5.3.2.1.in-addr.arpa. NS ns.foo.com." (sőt, még jobb lenne, ha nem glueless delegáció lenne, tehát mondjuk az ns.4.3.2.1.in-addr.arpa nevet viselné a nameserverünk). Classless delegáció esetén ugyanez úgy történik, hogy felveszünk egy darab NS-rekordot így: "4/31.3.2.1.in-addr.arpa. NS ns.foo.com." - ezzel létrehoztunk egy új zónát, a 4/31.3.2.1.in-addr.arpa nevűt; most már csak az a dolgunk, hogy az egyes PTR-rekordokat áthelyezzük ebbe a zónába, ezt pedig két CNAME rekorddal lehet megtenni: "4.3.2.1.in-addr.arpa. CNAME 4.4/31.3.2.1.in-addr.arpa." és "5.3.2.1.in-addr.arpa. CNAME 5.4/31.3.2.1.in-addr.arpa.".
Így a DNS-kliens, amikor a 4.3.2.1 PTR rekordját keresi, megtalálja a 4.4/31.3.2.1.in-addr.arpára mutató CNAME-et, úgyhogy megpróbálja a 4.4/31.3.2.1.in-addr.arpa PTR rekordját feloldani, erre pedig a delegációt fogadó szerver a keresett PTR rekorddal válaszol. Egyszerű, nem?
Note to self: Erre kéne részletes példa, mindkét szerver zónafájljával, a DNS-ről szóló oldalra. Bár az RFC-ben is megvan és DJB oldalán is.
Egy válasz a zh-ból (betű szerint):
Classless delegáció: ha egy DNS nem egy teljes A, B vagy C tartományt fed le.
Delegáció: ha az adott DNS szerver "tudja" a választ, de a klienst továbbirányítja a megfelelő authoritatív szerverhez.
Kommentár: a válasz sajnos csak 1 pontot ér. Csak a kérdés legegyszerűbb részére válaszolt ("mit jelent a classless delegáció?"), és arra is pontatlanul. Mit jelent az, hogy "egy DNS nem egy teljes A, B vagy C tartományt fed le"? Több DNS van? És pl. a BME nameserverei "nem fednek le" egy teljes A-osztályú hálózatot - akkor ez most classless delegáció? Ha igen, akkor ki delegál kinek mit classless módon? Ha nem, miért nem? Nyilván nem kellett volna ugyanolyan részletesen leírni, mint ahogy én leírtam feljebb, de annak ki kellett volna derülnie, hogy mi a "trükk" benne (a CNAME és a példában a 4/31.3.2.1.in-addr.arpa zóna).

  • Mit jelent a DNS-ben a delegáció? Mondjon példát! (6 pont)
Helyes válasz:
Delegációnak - a kliens szemszögéből - azt nevezzük, amikor egy DNS-szerver válaszában nincs Answer section, csak olyan Authority section, amiben a kérdésben szereplő domainre, vagy egy a hierarchiában fölötte álló domainre vonatkozó NS rekordok vannak. Ebből a kliens megtudja, hogy melyik másik DNS-szervernek kell feltennie a kérdést a végső válasz reményében.
A DNS-adminisztrátor szemszögéből a delegáció az, amikor szubdomaint definiál, és ennek a karbantartását rábízza valaki másra: a szubdomainhez tartozó NS-rekordban megadott szerver üzemeltetőjére.
A DNS egésze szempontjából a delegáció az, ami hierarchikussá teszi a DNS-t, mint adatbázist. Elvileg a root szerverek minden névre autoritatívak, a valóságban azonban - a delegációnak köszönhetően - nem kell minden név összes rekordját ismerniük, hanem elegendő azt tudniuk, hogy a TLD-kre (top-level domainekre) mely szerverek autoritatívak; vagyis a TLD-ket delegálják azoknak a szervereknek, amelyek az egyes TLD-kre autoritatívak, s.í.t.
Példa: Ha valamelyik, a hu. zónára autoritatív szervertől megkérdezzük, mi a www.bme.hu domain A rekordja (ne feledjük, a DNS-ben minden domain, a "hosztnevek" is), a válaszban nem lesz Answer section (vagyis a keresett A rekord), de lesz olyan Authority section, amiben fel vannak sorolva a bme.hu domainre autoritatív szerverek (és lehet egy Additional section, amelyben ezek közül azoknak, amik szintén .hu alattiak - vagyis, véletlenül, az összesnek - benne lesz az A és/vagy AAAA rekordja is - ez a glue).
Példa az adminisztrátor szemszögéből: ha a hu. zónafájlba azt írjuk, hogy "bme.hu. NS ns.bme.hu.", akkor az ns.bme.hu-nak delegáltuk a bme.hu domainnel kapcsolatos kérdéseket.
Egy válasz a zh-ból (betű szerint):
Delegáció: ha csak azt mondjuk meg egy DNS-kérésre, hogy merre kell tovább tapogatózni a cím után.
Pl. ha a www.bme.hu keresésekor a *.hu-ra autoritatív DNS szerver címét kapjuk válaszként
Kommentár: a válasz 5 pontot ér. A delegációt, mint láttuk, többféle szemszögből meg lehet közelíteni; a hallgató a kliens oldaláról közelítette meg, és a lényeges információk többségét leírta. Hiányzik azonban, hogy kitől (ti. a root szervertől) fogjuk megkapni a .hu-ra autoritatív szerverek nevét (a címüket csak glue-ként). Ezek a pontatlanságok önmagukban nem súlyosak, de összesen indokolják egy pont levonását.

  • Mit jelent a DNS-ben az NXDOMAIN? (5 pont)
Helyes válasz:
Ha egy kérdésre azt a választ kapjuk, hogy NXDOMAIN, az azt jelenti, hogy sem a keresett domainnek, sem egyetlen aldomainjének sem a keresett típusú, sem más típusú rekordja nincs. Csak olyan szerver jogosult NXDOMAINnel válaszolni, amely autoritatív a keresett domainre; ha egy szerver csak autoritatív kérdésekre válaszol, és olyan domainről kérdezik, amire nem autoritatív, akkor nem válaszolhat NXDOMAINt, hanem csöndben kell maradnia (mert a DNS-ben nincs olyan válasz, hogy "nem vagyok autoritatív").
Egy válasz a zh-ból (betű szerint):
A DNS szerver biztosan állítja, hogy sem a kérdezett domén, sem annak aldoméne nem létezik. Ez nem egyenértékű azzal, hogy a DNS szerver nem ismeri a domént vagy nem autoritatív rá.
Kommentár: a válasz 4 pontot ér, mert nem fejti ki, mit jelent az, hogy egy domain "nem létezik" (ti. azt, hogy semmilyen típusú rekordja nincs), pedig igazából éppen ez volt a kérdés; az, hogy az NXDOMAIN a "domain" és a "(does) not exist" szavak valamilyen permutációjának rövidítése, elég evidens.

  • Mit jelent az, hogy egy DNS-szerver autoritatív egy domainre? Mitől válik azzá? Ki határoz erről? (10 pont)
Helyes válasz:
Elsősorban azt jelenti, hogy a mindenki által ismert gyökérszerverektől elindulva az adott domainre vonatkozó kérdések feloldása során delegációs lánc vezet az adott DNS-szerverhez. Például az ns.bme.hu azért autoritatív a bme.hu domainre, mert azok a szerverek, amelyek a root szerverek szerint autoritatívak a .hu-ra, a .bme.hu-t (többek között) az ns.bme.hu-nak delegálják. Vagyis az autoritativitás "felülről érkezik", a DNS-hierarchiában "feljebb található" szerver nyilatkozata alapján válik egy "alacsonyabb szintű" szerver autoritatívvá egy domainre. Úgy is mondhatnánk, hogy a root szerverek a saját autoritativitásuk egyes partícióit adják tovább a delegációk mentén a TLD-kre autoritatív szervereknek, és így tovább. Egy domainre csak olyan szerver tehet minket autoritatívvá, amely maga is autoritatív rá (pl. a tmit.bme.hu-t csak a .bme.hu-ra, a .hu-ra vagy a gyökérzónára autoritatív szerver delegálhatja az alpha.tmit.bme.hu-nak, az ns.whitehouse.gov nem).
Azt is fontos érteni, hogy a root szerverek minden domainre autoritatívak; a .hu szerverek (pl. az ns.nic.hu) minden, a .hu alatti domainre autoritatívak (tehát pl. az alpha.tmit.bme.hu vagy az ez.egy.nagyon.mely.domain.nev.hu IP-címéről is jogosultak nyilatkozni); a delegált domain nem kerül ki abból a halmazból, amelyre a szerver autoritatív. Tehát attól, hogy az ns.nic.hu az ns.bme.hu-t egy delegáció révén autoritatívvá teszi a .bme.hu-ra, még ő maga is autoritatív marad a .bme.hu domainre.
Az autoritativitás másik kritériuma az, hogy a szerver saját magát autoritatívnak gondolja egy domainre; ez beállítás kérdése.
A "ki határoz erről?" kérdésre a technikai válasz az, hogy a hierarchiában feljebb található domain karbantartója; jogilag természetesen ennél bonyolultabb a helyzet, de ez most nem érdekel minket.
A "mit jelent?" kérdésre adott válaszhoz hozzá tartozik az is, hogy az adott szerver a saját adatbázisából képes megválaszolni minden, az adott domaint érintő kérdést (és ebből a szempontból a delegáció is válasznak számít); jogosult pl. úgy nyilatkozni, hogy a keresett név nem létezik (NXDOMAIN, l. feljebb).
Egy válasz a zh-ból (betű szerint):
Az autoritatív DNS-szerver azt jelenti, hogy az adott domainre vonatkozó név-IPcím megfeleltetésekért ő a "felelős": a kérések feloldásában az autoritatív DNS-szerver a hiteles válaszadó.
A hierarchikus DNS-szervezésben alapvetően két fontos tényező tesz autoritatívvá egy DNS-szervert:
a) "Gondolja magát annak" (Elvileg nem célszerű - nem szép dolog - olyan kéréseket kiszolgálni, amire nézve nem autoritatív a szerver)
b) A hierarchiában felette álló szerverek delegálják az adott szervernek a vonatkozó domainre vonatkozó jogokat
Kommentár: a válasz csak 8,5 pontot ér a következő két hiba miatt:
1. A DNS-ben nemcsak név-IPcím-párokat tárolunk, vannak más rekordtípusok is (-0,5 pont).
2. Dehogynem célszerű olyan kéréseket kiszolgálni, amire nézve nem autoritatív a szerver - éppen ezt csinálja a rekurzív rezolver, amit sok implementáció egybeépít az autoritatív szerverrel. Ami nem szép dolog, az az, ha úgy állítjuk be a szervert, hogy olyan domainre is autoritatívnak gondolja magát, amit nem delegálnak neki a felsőbb szintű szerverek. (-1 pont)

4 Az SMTP működése

  • Írja le egy tipikus SMTP-tranzakció menetét! Milyen üzeneteket küld a kliens, és milyeneket a szerver? (6 pont)
Helyes válasz:
Itt említeni kellett a HELO, a MAIL FROM, az RCPT TO, a DATA és a QUIT parancsot; röviden a levél felépítését (fejléc; üres sor; törzs; egyetlen pontból álló sor); és a szerver válaszainak felépítését (háromjegyű szám, az első jegy jelentése stb.). Bővebben l. Az SMTP működése c. szócikkben.
Egy válasz a zh-ból (betű szerint):
C->S: HELO valaki.valahol.hu.
* ESMTP esetén HELO helyett EHLO
* A kliens megadja a domain nevét
S-C: HELO [...]
A szerver köszönti a klienst, és megadja a paramétereit (név, típus, verzió, használható parancsok, stb...)
C->S: MAIL FROM küldő@e-mail.címe.hu
* A kliens megadja a küldő e-mail címét
* Az "e-mail.címe.hu" jóesetben "valaki.valahol.hu"
C->S: MAIL TO címzett@e-mail.címe.hu
C->S: DATA [...]
Itt küldi el a tényleges üzenetet.
Az üzenet végét a ".<ENTER>" jelzi.
S->C: Message received üzenet, ha minden rendben.
Kommentár: a válasz csak 2 pontot ér, mert nem a valóságban használt SMTP-t, hanem egy hasonló, de alternatív protokollt ír le.
Az első üzenetet a szerver küldi, egy SMTP banner formájában: pl. 220 chardonnay.math.bme.hu ESMTP.
A kliens a HELO-üzenetben nem a domain-nevét adja meg, hanem a hosztnevét, vagy, ha ilyen nincs neki, akkor az IP címét.
A szerver sosem küld HELO üzenetet a kliensnek; mindig három számból álló kódokkal jelzi, hogy az előző parancsról mi a véleménye.
A szerver általában nem árulja el a saját verziószámát, nehogy ezzel feleslegesen megkönnyítse egy esetleges támadó dolgát.
A MAIL FROM-ban megadott feladó domainje semmilyen kapcsolatban nem kell, hogy álljon a HELO-üzenetben megadott hosztnévvel - pl. a saját másodlagos MX-ünk nyilván a saját nevén mutatkozik majd be, viszont az eredeti feladó nevében küldi nekünk a levelet.
MAIL TO helyett RCPT TO van az SMTP-ben.
A tényleges üzenet felépítése hiányzik.
A QUIT parancs hiányzik.

  • Milyen módokon (nem mi alapján!) utasíthat el egy SMTP-szerver egy nem kívánt levelet? Melyiknek mi a következménye a levél későbbi sorsát illetően? (6 pont)
Helyes válasz:
- A TCP-kapcsolat elutasításával. A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.
- A TCP-kapcsolat bontásával az SMTP-kapcsolat során, a levél átvétele előtt. A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.
- Kliensoldali időtúllépés szándékos kiprovokálásával az SMTP-kapcsolat során (egyszerűen sokáig nem válaszol). A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.
- Az SMTP-tranzakció során, "ideiglenes" (négyessel kezdődő) válaszkóddal. A kliens (ha valódi levelezőszerver) egy darabig újra meg fogja kísérelni kézbesíteni a levelet; ha hosszú ideig nem sikerül, feladja, és hibaüzenetet küld a feladónak.
- Az SMTP-tranzakció során, "végleges" (ötössel kezdődő) válaszkóddal. A kliens a levelet kézbesíthetetlennek tekinti és hibaüznetet küld a feladónak.
- (Minden ettől eltérő viselkedés - pl. ha átveszi a levelet, de nem kézbesíti, csak hibaüzenetet küld a feladónak, vagy még azt sem - a levél elfogadásának minősül az SMTP kontextusában.)
Egy válasz a zh-ból (betű szerint):
- nem épít fel a másik szerverrel TCP kapcsolatot
következmény: ha spammer vsz. nem próbálkozik újra ma már ez sajnos nem igaz.
ha nem spammer akkor újra próbálkozik kicsit lelassítja a valódi leevlek kézbesítését
- átmenetileg vissza utasítja
köv: 4xy hibakóddal átmenetileg visszautasitja a levél átvételét, késöbb lehet próbálkozni
- permanensen visszautasítja
köv: 5xy hibakóddal végérvényesen visszautasítja a levél átvételét, nem érdemes többszörprobálkozni
Kommentár: a válasz 6 pontot ér annak ellenére, hogy keveri a következményeket a módszerrekkel (jóra gondolt, de rosszat írt). Felsorolta a három legelterjedtebb módszert. Kicsit hiányzik, hogy mi történik, ha a későbbi próbálkozások is hasonlóan sikertelenek, de az SMTP-hibaüzenetek annyira közismertek, hogy bizonyára mindenki tudja, hogy ilyenkor hibaüzenet jön.

5 A HTTP működése

  • Milyen problémával kell számolnunk, ha HTTP virtualhostingot használunk, és SSL-re is szükségünk van? Milyen megoldásai vannak a problémának? (6 pont)
Helyes válasz:
A HTTP virtualhosting működési elve az, hogy a HTTP Host: fejlécében megmondjuk a webszervernek, melyik virtuális szerver címterében kell értelmezni a kérésben átadott elérési utat és fájlnevet. Ha HTTPS-t használunk, akkor a böngésző és a webszerver közötti TCP-kapcsolat felépülése után először az SSL handshake-re kerül sor; ennek során a böngésző hitelesíti a szervert, és többek között azt is ellenőrzi, hogy a szerver tanúsítványa az URL-ben szereplő hosztnévre szól-e.
A gond az, hogy a szerver ebben a pillanatban még nem tudja, hogy mi az URL, így, ha virtuális hosztokat használunk, nem tudja eldönteni, melyik virtuális hoszt tanúsítványával hitelesítse magát a böngésző felé; ha nem a jót választja, a böngésző hibaüzenetet ad (vagy az alkalmazásszintű proxy megtagadja a webszájthoz való hozzáférést). A szerver csak az SSL-handshake után, a HTTP-tranzakcióból tudja meg (a Host: fejlécből), hogy melyik virtualhostra kíváncsi a kliens.
Két megoldás van: az egyik az, hogy minden HTTPS-es virtualhostos külön IP:port páron futtatunk, így a szerver abból, hogy melyik IP:portra jött kapcsolatkérés, meg tudja állapítani, melyik virtualhostot szólítják meg éppen, és így azt is tudja, melyik tanúsítvánnyal kell hitelesítenie magát.
A másik megoldást csak akkor használhatjuk, ha minden virtualhostunk ugyanabba a domainbe tartozik, és a hitelesítő hatóságunk (CA, certificate authority) hajlandó nekünk joker-tanúsítványt adni erre a domainre; ekkor a tanúsítvány elvileg minden, az adott domainbe tartozó konkrét hosztnévre érvényes lesz, tehát a szerver nem kerül olyan dilemma elé, hogy több tanúsítvány közül kellene választania, vagyis az összes virtualhost maradhat ugyanazon az IP:port páron, hanem hitelesítheti magát azzal az eggyel, ami van. A módszer hátránya, hogy nem minden CA ad ki - és nem minden böngésző fogadja el - a joker-tanúsítványt.
Egy válasz a zh-ból (betű szerint):
Az a probléma, hogy a kliens elküldi a HTTP-kérésben a kért weboldal címét, ekkorra azonban már túl kéne esni az SSL-handshake-en, amihez kéne tudni a kért oldal címét (hogy melyikhez tartozó tanúsítványt használjuk). Megoldás:
1. különböző portra kell tenni a virtuális HTTPS-szervereket és port alapján tudjuk, melyik cert. kell
2. a domain-re vonatkozó cert. kell
Kommentár: A válasz 5 pontot ér. Fél pont levonás jár azért, mert nem fejti ki, mi "a domain" (impliciten feltételezi, hogy minden virtualhost ugyanabba a domainbe tartozik), és másik fél pont levonás azért, mert nemcsak külön portra, hanem külön IP-re is tehetjük az egyes virtuális szervereket; az IP:port párnak kell különböznie.

6 Filerendszerek

  • Fájlrendszerek kontextusában mi a fork? (3 pont)
Helyes válasz:
Ha a fájlrendszer lehetővé teszi, hogy egyetlen fájlhoz több, a fájlrendszer szintjén elkülönülő adatterület is tartozzon, akkor ezen adatterületek mindegyike egy-egy fork.
(A fájl érdemi tartalma a default fork; egyéb forkok tartalmazhatnak pl. bővített attribútumokat, POSIX ACL-eket, kép thumbnailjét, dokumentum meta-adatait stb.)
Egy válasz a zh-ból (betű szerint):
egy file-t több részletben több helyen tárolunk az FS-en ilyen lehet pl. mp3 ID3 tagjei, képek tumbnailjei, extended attribute-umok
Kommentár: A válasz 2,5 pontot ér, mert sajnos pontatlanul fogalmaz. Mit jelent az, hogy "több részletben, több helyen tároljuk"? A fragmentálódott fájlokat is több részletben, több helyen tároljuk, mégsem állnak szükségszerűen több forkból. A válasz igazából nem definiálta a forkot, csak mondott rá példát, amiből az ID3 tag ráadásul nem is jó példa, mert az szükségszerűen a fájl elsődleges adatterületének a része (persze az ID3 tagben található adatokat tarthatnánk egy - vagy egy-egy - forkban).

  • Mire jók a POSIX ACL-ek? Mondjon példát olyan jogosultságrendszerre, ami POSIX ACL-ekkel leírható, de hagyományos unixos jogosultságokkal nem! Bónuszkérdés: olyanra is tud példát, ami POSIX ACL-ekkel sem írható le? (10 pont)
Helyes válasz:
A POSIX ACL-ek egy olyan DAC (discretionary access control) mechanizmust valósítanak meg, amelynek segítségével csoportokra és felhasználókra lebontva megadhatjuk, hogy az adott inode-ra (fájlra, könyvtárra) kinek legyen olvasási, írási ill. végrehajtási joga. Az ún. "effective rights mask" segítségével valamennyi ACL-ből kimaszkolhatók bizonyos bitek (tehát pl. egyszerűen megvonható mindenkitől az írási jog akkor is, ha a saját ACL-je szerint van neki, és a mask újbóli módosításával visszaadható).
(Az ACL az Access Control List rövidítése.)
Mivel a POSIX ACL DAC-mechanizmus, nem pedig MAC (mandatory access control), a felhasználók a saját fájljaikon átállíthatják az ACL-eket, vagyis rendszerszinten sajnos nem kényszeríthetők ki vele bizonyos jogok bizonyos könyvtárakon.
Példa olyan esetre, ami unixos jogosultságokkal nem írható le: olyan fájl, amire az olvasó csoportnak olvasási joga van, az író csoportnak írási és olvasási joga is van, és azoknak a felhasználóknak, akik nem tagjai ezek közül egyik csoportnak sem, sem írási, sem olvasási joga nincs. (POSIX ACL-ekkel ezt egyébként így adhatjuk meg: setfacl -m g:olvaso:r--,g:iro:rw-,o:--- file)
Példa olyan esetre, ami POSIX ACL-ekkel sem írható le: egy végrehajtható fájl az egyik csoport számára legyen setuid root, a másik csoport számára egyszerűen végrehajtható, de ne setuidos. Ez azért nem oldható meg POSIX ACL-ekkel, mert a POSIX ACL-ek csak az rwx biteket tartalmazzák, a setuid, setgid, sticky biteket nem.
Egy válasz a zh-ból (betű szerint):
ACL Access Control List. Bonyolultabb hozzáférési jogrendszer mint a hagyományos unixos jogosultságok.
Pl. AFS-nél az hogy az AFS szerver gyökerén belül van egy Private mappa, Public és Public_html. Itt azt kell megoldani, hogy a public_html-t csak a webszerver olvassa viszont a publicot ne. Tehát ha egy szolgáltatásnak akarunk jogokat megadni azt ACL-el érdemes megtenni.
Kommentár: A válasz 2 pontot ér. A leírt példa lehet jó is, de a válaszból ez sajnos nem derül ki, mivel sajnos érthetetlen - mit jelent az, hogy "a publicot ne"? A publicot ne olvashassa a webszerver, vagy a publicot ne csak a webszerver olvashassa? És milyen jogok legyenek a Private könyvtáron? A POSIX ACL-ek szemantikájáról sajnos egy szó sem esik.

7 Software RAID Linux alatt

  • Mi a write-behind a linuxos softraid kontextusában, és mire jó? (5 pont)
Helyes válasz:
RAID1 esetén a tömb egyes elemein beállítható külön a write-mostly flag, és az egész tömbre a write-behind működés. A write-mostly hatása az, hogy az adott eszközről az md driver próbál nem olvasni, csak szinkronizálni rá; ez akkor jó, ha az adott eszköz lassú, mert így akkor csak az írást lassítja le, az olvasást nem. A write-behind-ot akkor tudjuk bekapcsolni, ha a tömbnek van write-intent bitmapje, és az a hatása, hogy a write-mostly-nak jelölt eszközökre aszinkron módon fog írni az md driver; ennek az az értelme, hogy ha pl. egy viszonylag lassú hálózati diszk is része a tömbnek, akkor annak a sebessége nem fogja vissza nagyon a teljes tömb írási teljesítőképességét, a tartalma mégis nagyjából szinkronban marad a tömb többi részével.

(Erre a kérdésre az a hallgató, akinek a zh-jában szerepelt, nem válaszolt.)


  • Mit jelent a linuxos softraid terminológiájában a RAID10? Mik a jellemzői? Mik a paraméterei? (8 pont)
Helyes válasz:
Itt elsősorban azt kell leírni, hogy:
- egy absztrakciós szinten megvalósított csíkozás és tükrözés (több diszken is tárolja ugyanannak az adatnak egy-egy példányát, és az egészet csíkozza);
- így pl. csinálhatunk páratlan számú diszkből is csíkozott-tükrözött tömböt (RAID0+1 és RAID1+0 csak páros számú diszkkel megy);
- lehet hozzá hotspare-t adni;
- paraméter: hány éles diszk (ami nem spare), hány near másolat, hány far másolat, hány spare.
(A near/far magyarázatát l. a Software RAID Linux alatt szócikkben.)
Egy válasz a zh-ból (betű szerint):
Egy absztrakciós szinten megvalósított RAID1 és RAID0. A tömb hotspare-t tartalmaz, bővíthető, a hibajavítást megvalósító paritás "tömbök" nem külön meghajtón helyezkednek el, ezek ugyanúgy az adatok mellett szerepelnek. A RAID0 a diszkek csíkozását, a RAID1 a diszkek tükrözését jelent. Csíkozás alatt az értendő, hogy a több diszkből álló tömb teljes területét felhasználjuk, ellenben nem törekedünk az adatok biztonságos tárolására. A csíkok szélesíthetőek több diszk beiktatásával, sekélyíthetőek, mélyíthetőek a csíkonkénti blokkszám csökkentésével, növelésével.
A tükrözés a redundancia növelését szolgálja, az adatok pontos másolata található meg az összes diszken. RAID10 esetén a hotspare bármelyik kiesett lemezt pótolhatja, online képes szinkronizálni. Maximum 2 winchester kiesését képes túlélni.
Kommentár: a válasz sajnos csak 2 pontot ér, mert számos hibát tartalmaz:
- A RAID10 egyelőre nem bővíthető.
- Nincs benne paritás (súlyos hiba paritást emlegetni); a redundanciát másolatok tárolásával biztosítja, mint a RAID1.
- A csíkozás nem azt jelenti, hogy a teljes területet felhasználjuk, hanem azt, hogy a logikailag folytonos adatterületek több diszkre vannak elosztva annak érdekében, hogy a folytonos írás/olvasás több diszket is érintsen, és így ezek a műveletek gyorsuljanak.
- A csíkozás nem zárja ki, hogy a biztonságra is figyeljünk: a RAID5 is csíkoz, csak számol paritást is.
- A RAID10 annyi diszk kiesését képes elviselni, ahány redundáns másolatot tartalmaz, ez viszont egy olyan paraméter, amit a tömb létrehozásakor állíthatunk be.
- Nem tér ki a near és far másolatokra.

8 Logikai kötetkezelés

  • Hogyan lehet az LVM segítségével online mentést nem támogató adatbázisról mégis kvázi-online mentést készíteni? (10 pont)
Helyes válasz:
1. Leállítjuk az adatbázist – ami az adatokat egy logikai köteten tárolja –, vagy legalábbis befagyasztjuk a tranzakciókat, hogy rövid időre konzisztens állapotban maradjanak a diszken tárolt adatok.
2. Készítünk egy pillanatfelvételt (LVM snapshotot) az adott logikai kötetről. Ez nagyon gyorsan megvan.
3. Az adatbázist újraindítjuk, vagy újra engedélyezzük az író tranzakciókat.
4. Ezután az LVM a snapshot copy-on-write szemantikájának köszönhetően, ha az adatbázisszoftver ír az eredeti kötetre, akkor a módosítandó adatoknak egy másolatát elhelyezi a snapshot-köteten, így biztosítva, hogy onnan mindig kiolvasható legyen a snapshot készítésekori állapot.
5. Ezután a kedvenc offline backup-megoldásunkkal lementjük a snapshot-kötetről az adatbázist.
Így megoldható, hogy az adatbázist ne kelljen annyi időre leállítani, ameddig az offline mentés tart, csak a snapshot létrehozásának idejére, ami max. tizedmásodperces nagyságrendű idő.
Egy válasz a zh-ból (betű szerint):
LVM-el lehet snapshotot ???? ez csak a ????változtatásokat???? ???? le mivel ez kell vissza????.
Kommentár: a válasz az olvashatatlan szavaktól függetlenül 1 pontot ér, mivel csak a snapshotot, mint kulcsfogalmat említi, a módszer részleteiről egyáltalán nem emlékezik meg.

  • Legfeljebb mennyi helyet érdemes allokálni egy snapshot LV számára? Miért? (3 pont)
Helyes válasz:
Legfeljebb annyit, amekkora az eredeti LV (aminek a snapshotja), mégpedig azért, mert a snapshot csak azokat az adatokat tárolja, amelyek az eredeti köteten megváltoztak, ennek a tárolásához pedig nem lehet szükség több helyre, mint amekkora az eredeti kötet (x MiB-nyi adatban legfeljebb x MiB-nyi változás tud bekövetkezni).
Egy válasz a zh-ból (betű szerint):
Legfeljebb annyit, amekkora a volume, amiről a snapshot készül, ez általában sok, helyette elég annyi, amennyi változásra számítunk az adott volume-on a snapshot használata alatt (a volume változhat, de a snapshot megőrzi a volume eredeti állapotát, ha a snapshotot nem változtatjuk, így az eredeti állapotnak változáskor ki kell íródnia a snapshotra).
Kommentár: a válasz 3 pontot ér; az indoklás ugyan nem szabatos, de a kérdés szempontjából irreleváns kiegészítésből kiderül, hogy a hallgató érti, miről van szó.

  • Miért jó logikai kötetkezelést használni? Mondjon alkalmazási példákat is! (5 pont)
Helyes válasz:
Itt aztán lehet mesélni. :) Amit meg lehet említeni: rugalmasság (nem kell előre eldönteni, minek mennyi hely kell; utólag betolt diszk kapacitása hozzáadható a filerendszerhez; akár működés közben kicserélhető az összes diszk a rendszer alatt); snapshot lehetősége (és erre néhány alkalmazási példa, nem részletesen). Biztos olyasmit is fel lehet sorolni, ami nekem most nem is jutott eszembe.
Egy válasz a zh-ból (betű szerint):
Mert relatíve "eszközfüggetlen". A hardver és szoftver (=fájlrendszer) közé épül be, a fizikai eszközök cserélhetőek a fájlrendszer alatt, a fájlrendszer ill. az alatta levő LVM kötet pedig növelhető, zsugorítható (fájlrendszerfüggő).
A logikai kötetkezelés linux alatt (RAID) ill. LVM formájában jelenik meg. Az LVM felett tetszőleges fájlrendszer elhelyezhető. SunOS-nél az újonnan megjelent ZFS az LVM-et a fájlrendszerekkel ötvözi, a SPARC architektúrát nagyon specifikusan lekezelve.
Felhasználás: érdemes lehet nem a teljes LVM-et "kimérni" a partíciók számára, így igény szerinti automatizált partíciónövelő és egyben rendszergazdát e-mailben/SMS-ben/... értesítő scriptet/programokat írni kritikus alkalmazásokat futtató szerveren. (PL.: a /VAR/LOG partíció nem telet be (nem blokkolódhatnak a programok), de a logokat hosszú, előre megadott ideig őrizni kell (EU-s távközlési szolgáltatók?)
Ilyenkor a teljes LVM betelése előtt növelhetőek az LVM kapacitása. (VG)
Kommentár: a válasz 5 pontot ér annak ellenére, hogy nem minden mondat értelmes. :) Hogy mit jelenthet a SPARC architektúra "specifikus lekezelése", az pl. rejtély, de valamit hagyni kell az utókornak is.

9 A bootfolyamat

  • Miért nehéz a System V init használata esetén egy daemonizált szolgáltatás megbízható, robusztus leállítása? Milyen módszerrel próbálják enyhíteni a problémát, és mi a baj ezzel a módszerrel? Hogyan foglalná össze, mi a probléma gyökere? (12 pont)
Helyes válasz:
A daemonizálódás azt jelenti, hogy amikor a szolgáltatás elindul, az első processz szinte azonnal indít egy gyermekfolyamatot (ami nyit egy új process groupot), majd kilép. A szolgáltatás nyújtásáért a továbbiakban ez a gyermekfolyamat, ill. az ő esetleges gyemekfolyamatai a felelősek; az első processzt indító folyamatnak a továbbiakban nincs kapcsolata a szolgáltatásért felelős processzekkel, mert az ő gyermekfolyamata szinte azonnal kilépett, és a Unixban minden processz csak a közvetlen gyermekfolyamatai állapotáról értesül hivatalból.
Ennek a következménye az, hogy nincs pontos képünk arról, melyik PID-hoz tartozó processz a felelős egy szolgáltatásért.
A szolgáltatás leállítása általában abból áll, hogy a megfelelő processznek küldünk egy bizonyos signalt. A gond az, hogy nem tudjuk, melyik a megfelelő processz. Többféle heurisztikával meg lehet próbálni megkeresni, de mindegyikkel van valami baj.
- Kereshetünk adott nevű processzt. Ez nem jó, mert a szolgáltatásunkkal nem összefüggő processznek is lehet olyan neve, ill. elképzelhető, hogy a szolgáltatásunkkal kapcsolatos processz neve nem kiszámítható (mert mondjuk átírja aszerint, hogy éppen mit csinál).
- Hálózati szolgáltatás esetén megnézhetjük, melyik processz figyel az adott szolgáltatás portján. Ezzel az a baj, hogy elképzelhető, hogy több olyan szolgáltatásunk is van, ami az adott porton figyelni tud; lehet, hogy hol az egyik fut, hol a másik, vagy az egyiket nem is használjuk szolgáltatásként, csak valamilyen segédprogramja miatt van fent, stb. stb.; ilyenkor, ha egy nem futó szolgáltatást próbálunk leállítani, lehet, hogy a futót állítjuk le véletlenül.
- A legelterjedtebb módszer a pidfile használata. Ez egy szövegfile, amibe a szolgáltatás (vagy az őt indító és daemonizáló segédprogram, pl. a start-stop-daemon) beleírja a PID-ját. Ezzel több baj is van:
- Ha a szolgáltatás több processzből áll, és ezeknek van életciklusa (tehát egy idő után kilépnek, és új veszi át a helyüket), akkor elképzelhető, hogy a pidfile már nem a megfelelő PID-t tartalmazza.
- Ha a pidfile helyét egy konfigurációs fájlban kell megadni, elképzelhető, hogy a szolgáltatás elindítása óta megváltozott a konfiguráció, és nem arra a pidfile-ra hivatkozik, amit a futó szolgáltatáspéldány használ.
- Összetett struktúrájú konfigurációs fájl esetén esetleg nem triviális megtalálni benne az érvényes pidfile-beállítást (pl. apache2).
- Így aztán, ha a pidfile-ból ki is olvasunk egy természetes számot, valahogyan meg kell(ene) győződni arról, hogy az valóban a leállítandó szolgáltatáshoz tartozó processz PID-ja-e; itt viszont versenyhelyzetbe kerülhetünk, mert a szám kiolvasása, hitelesítése és a signal elküldése között megeshet, hogy az eredeti processz kilép, és másik kapja meg a PID-ját, így annak a másiknak küldjük a signalt is.
- Még akkor is fennáll ugyanez a versenyhelyzet, ha nem hitelesítjük a PID-t sehogy (ez amúgy rossz ötlet), mert a kiolvasás-signalküldés nem atomi művelet (a kiolvasás után - de a signalküldés előtt - eltűnhet az eredeti processz és létrejöhet ugyanolyan PID-val másik, de még az is baj, csak kisebb, ha csak az eredeti tűnik el).
A probléma gyökere az, hogy az első processzt hagytuk kilépni. Ha ő még futna, akkor a szülője tudná a PID-ját, és így tudna neki signalokat küldeni PID-lottó nélkül is.
Egy válasz a zh-ból (betű szerint):
A System V init a processzeket a process ID-jük (PID) alapján állítja le. Ez azért lehet problémás, mert a PID fájlba bárki beleírhat, más processzt állíthatunk le. Ha a processz kilépett és más kapta meg a PID-jet, akkor is mást állíthatunk le. System V init esetén a démonizált szolgáltatások indítása a következőképpen történik: a processz elindul, háttérbe kerül, majd minden hívásra gyermekfolyamatokat hoz létre. Ez azért nem jó mert nem tudjuk ekzaktul (sic) meghatározni a keresett gyermekfolyamat PID-jét. Ez kiküszöbölhető úgy, hogy a szülő folyamat nem kerül háttérbe és ő foglalkozik minden kéréssel. Ezt valósítja meg a runit és a daemontools.
Kommentár: a válasz sajnos csak 3 pontot ér; nagyon zavaros, sokminden keveredik benne (úgy látszik, ezt rosszul mondtam el az előadáson). Konkrét hibák:
- Ha signalt kell küldeni egy szolgáltatás leállításához, akkor szükségszerűen tudnunk kell egy PID-t, aminek a signalt küldhetjük. Ez nem egyedül a System V initre jellemző.
- Nem derül ki, mi a pidfile.
- Az nem igaz, hogy a pidfile-t bárki felülírhatná; nem szükséges, hogy mindenki számára írható legyen.
- A daemonizálás folyamatának leírása nem jó; nem az a processz kerül a háttérbe, amit közvetlenül elindítunk (pl. a parancssorból), hanem annak a gyermekfolyamata. Amit elindítunk, az a gyermekfolyamat létrehozása után ki is lép.
- Nem szükségszerű, hogy egy daemon egyáltalán foglalkozzon "kérésekkel" (gondoljunk pl. az auto-nice-daemonra). Az pedig pláne nem szükségszerű, hogy minden kérés kiszolgálásához új processz induljon.
- Nem az a baj, hogy az egyes kérésekkel foglalkozó gyermekfolyamatok PID-ját nem tudjuk, hanem az, hogy egyáltalán semmilyen, a szolgáltatáshoz köthető PID-t nem tudunk, legalábbis nem megbízható módon.
- Teljesen független egymástól az, hogy egy szolgáltatás daemonizálódik-e, és hogy külön gyermekfolyamatot indít-e minden kérés kiszolgálásához. Emiatt a leírt, a runitnak tulajdonított megoldás sajnos szintén nem jó.

10 A runit működése

  • Mi alapján tudja az svlogd szétválogatni a naplóüzeneteket?
Helyes válasz:
Egy a reguláris kifejezésekénél gyengébb kifejezőerejű, de gyorsabban illeszthető wildcard-rendszer segítségével minden megadott naplókönyvtárban "halmazműveletekkel" megadhatjuk azon üzenetek halmazát, amelyeket az adott könyvtárba naplózni szeretnénk. Ha az adott könyvtár konfigurációja UDP-s naplózást (is) előír, akkor a kiválasztott üzeneteket az svlogd az UDP-s naplószervernek is elküldi. Az, hogy "halmazműveletekkel", azt jelenti, hogy a +/- operátorokkal szukcesszíven bővíthetjük/szűkíthetjük a kiválasztott üzenetek halmazát, amíg tényleg pontosan azok vannak benne, amikre kíváncsiak vagyunk.
Bizonyos értelemben "szétválogatás" az is, hogy külön meghatározhatjuk, melyik üzeneteket írja ki a standard errorra is (a logfájlon és/vagy az UDP-n kívül).
(A wildcard-rendszerben amúgy két metakarakter van, a plusz és a csillag; ezeknek a jelentése benne van a dokumentációban, nem kell fejből tudni.)
Egy válasz a zh-ból (betű szerint):
SVLOGD képes illeszteni mintákat, ill. pipe-onként is képes szétválogatni az üzeneteket (Minden pipe egy futó szolgáltatás, processz).
Kommentár: A válasz sajnos csak 1 pontot ér. Nem derül ki, hogy a szétválogatás azt jelenti, hogy minden egyes megadott könyvtárban egyenként kell rendelkezni az oda naplózandó vagy nem naplózandó üzenetek halmazáról (tehát igazából nem szétválogatásról van szó, mert az az lenne, hogy "ezt ide, azt meg amoda" - ehelyett viszont olyat tudunk mondani, hogy "ide semmit, kivéve ezt, de abból emezt mégse, kivéve amazt, mert azt mégis", és ezt minden könyvtárban egyenként).
A válasz második része pedig sajnos teljes tévedés; amit a hallgató leírt, az a socklog-ng-re jellemző, nem az svlogdre. Az svlogd pontosan egy "pipe-ból" (a standard inputról) olvas; ha több (a standard outputra logoló) szolgáltatást akarunk naplóztatni, akkor több svlogd-t kell futtatnunk (mindegyikhez egyet). Ebből a szempontból a socklog, ami a syslogd-t helyettesíti, egyetlen szolgáltatásnak minősül, kvázi "koncentrálja" a többi program által generált syslog-üzeneteket. A szétválogatásnak is főleg a socklog esetén van értelme, bár természetesen máskor is vehetjük hasznát.

  • Mik az előnyei a runitnak a hagyományos System V inittel szemben? Mik a hátrányai? (12 pont)
Helyes válasz:
Előnyök:
A runit több egyszerű (ezért kisebb erőforrásigényű és várhatóan kevesebb hibát tartalmazó) programmal oldja meg azt, amit az init egy bonyolult programmal.
A bootfolyamat jelentősen felgyorsulhat, mert a szolgáltatások egyszerre indulnak el.
A szolgáltatások közötti függőségek kezelése kézimunkával megoldható (System V init esetén csak kísérletezni lehet vele, robusztus megoldás nincs).
Menedzseli is a szolgáltatásokat, nemcsak elindítja: újraindítja őket, ha leállnak; küldhetünk nekik signalokat; kapunk hozzájuk robusztus naplózást.
(Az inittel is lehet újrainduló szolgáltatást csinálni - "respawn" -, de az nem állítható le szelektíven.)
A szolgáltatások leállításához nem szükséges PID-k megtippelése; mivel a szolgáltatás szülőfolyamata nem lép ki, mindig tudjuk, milyen PID tartozik a szolgáltatáshoz.
A szolgáltatások egységes környezettel indulnak, attól függetlenül, hogy parancssorból indítjuk őket vagy a bootfolyamat során indulnak el.
Tetszőleges számú és nevű runlevelünk lehet.
Ezeket az előnyöket a felhasználók saját szolgáltatásainak is tudjuk biztosítani.
A szolgáltatásokat, ha akarjuk, kiemelt csoportok vagy felhasználók root jogok nélkül is menedzselhetik, akkor is, ha a szolgáltatás root jogokkal fut; ehhez csak a szolgáltatáshoz tartozó runsv-parancs-FIFO-t kell a megfelelő csoport vagy felhasználó számára írhatóvá tenni.
Könnyen le tudjuk kérdezni a szolgáltatásaink státuszát (fut, nem fut, próbál elindulni, mióta fut, mióta nem fut stb.).
Kapunk olyan eszközöket (elsősorban a chpst-t), amikkel egyszerűen beállíthatjuk a futtatandó szolgáltatás unixos állapotterét az elindítása előtt.
Runlevel-váltáskor (a previous symlink segítségével) könnyen nyomon követhetjük, leálltak-e már az előző runlevelben igen, de az újban nem futó szolgáltatások.
Hátrányok:
Általában nem kapunk kész run-scripteket a szolgáltatásokhoz, ezeket nekünk kell megírnunk; így valamivel több munka van a runittal, mint az inittel.
Nincs egységes mechanizmus a szolgáltatások konfigurációjának újraolvastatására (ami az initben a /etc/init.d/szolgáltatásneve reload).
Ha blokkolódik a naplózás, blokkolódik a szolgáltatás (ez elkerülhető, de akkor viszont lehet, hogy elvesznek naplóüzenetek).
Általában nem a runit az alapértelmezés, így a rá való áttéréshez szükséges idő hozzáadódik a telepítés időigényéhez.
(Feltehetően lehet még találni előnyöket és hátrányokat is.)
Egy válasz a zh-ból (betű szerint):
runit előnyei:
- egy dologgal foglalkozik egy parancs, nem sokkal mint az init
- ha egy folyamat megáll újra tudja indítani
- nem probléma, hogy melyik processznek kell a signált küldeni
- kicsik a programok
- gyors
runit hátrányai:
- nem használják a distribek default az init helyett
- a szolgáltatások elindításához nekünk kell megírni a scripteket
- kicsit trükközni kell a runlevel váltásnál, bár a runlevel váltást nem nagyon használják
Kommentár: a válasz 7 pontot ér, mivel hét valódi előnyt/hátrányt említ. A runlevel-váltásra vonatkozó megjegyzés nem állja meg a helyét; nem kell "trükközni" runlevel-váltáshoz, egyszerűen más a mechanizmus, mint az initben. Egy (opcionálisan két) symlink átállítása nem "trükközés" ahhoz képest, hogy kiadjuk a "telinit x" parancsot. A previous symlink nem szükséges a runlevel-váltáshoz a runitban, csak nekünk segítség, hogy nyomon követhessük az előző runlevelben igen, de az újban nem futó szolgáltatásaink státuszát. Az initben ezzel ekvivalens mechanizmus amúgy egyáltalán nincs.

  • Milyen esetekben rotálja a logokat az svlogd? (6 pont)
Helyes válasz:
A következő három esetben:
1. a log mérete elérte a configban megadott számú bájtot.
2. a log életkora elérte a configban megadott számú másodpercet, és a log nem üres.
3. az svlogd processz ALRM signalt kap, és a log nem üres.
Egy válasz a zh-ból (betű szerint):
svlogd: - ha a megadott paramétereket elérték a logok (méret, darabszám, időtartam stb.); a konfigfile-ban állítható be
- ha manuálisan megkérjük erre szignállal
Kommentár: a válasz 4 pontot ér, mivel gondolkodáshiányra utaló dolgot tartalmaz: a logok darabszáma nem lehet a rotálás feltétele, hiszen a rotálás megnöveli a logok számát, tehát ha egyszer túlléptük a küszöböt, akkor folyamatosan rotálnunk kellene. Másfelől viszont a logok darabszámát csak a rotálás növeli meg, tehát ha csak darabszám alapján akarnánk rotálni, akkor sosem rotálnánk. Emellett a válasz nem tér ki arra, hogy üres logot az svlogd semmiképpen nem rotál.

  • Milyen feltételeket kell teljesítenie egy minimális runitos run-scriptnek ahhoz, hogy a runit előnyei érvényre jussanak? (5 pont)
Helyes válasz:
- Nem szabad kilépnie, amíg a hozzá tartozó szolgáltatás ki nem lép.
- Lehetőleg azonnal ki kell lépnie, amikor a hozzá tartozó szolgáltatás kilép.
- exec-kel kell elindítania a szolgáltatást, hogy a runsv által a gyermekfolyamatának küldött signalokat a szolgáltatás kapja meg, és ne a run script; ha ez valami miatt nem megoldható, akkor gondoskodni kell a signalok továbbküldéséről, de ez már eléggé elbonyolítja a scriptet (a kill signalt pedig úgysem tudjuk továbbküldeni).
- A standard errort át kell irányítani a standard outputra ("exec 2>&1"), hogy az is megjelenjen a szolgáltatáshoz tartozó svlogd-példány standard inputján.
- Meg kell próbálnia (pl. az sv start parancs segítségével) elindítani azokat a szolgáltatásokat, amiktől az aktuális szolgáltatás függ; ha nem sikerül, ki kell lépnie (a runit később újrapróbálja).

(Erre a kérdésre az a hallgató, akinek a zh-jában szerepelt, nem válaszolt.)

11 Naplózás

  • Mik az előnyei/hátrányai az UDP ill. a TCP fölötti hálózati naplózásnak? (4 pont)
Helyes válasz:
Mivel a TCP kapcsolatorientált, a naplózószerver elvileg túlterhelhető kapcsolatokkal.
Mivel a TCP-ben van torlódásvezérlés, elképzelhető, hogy a naplóüzeneteket író programok blokkolódnak arra várva, hogy a helyi üzenetpuffert hálózaton át üríteni lehessen; ha nem ezt várják meg, egy idő után megtelik a memória a pufferrel vagy elküldés nélkül el kell dobni üzeneteket.
A TCP-kapcsolatok szemantikájának megvalósítása növeli a naplózókliens összetettségét; kezelni kell pl., ha megszakad a hálózati kapcsolat.
Az UDP kapcsolatmentes, "fire and forget" jellegű. Emiatt kliensoldalon nem feltétlenül van visszajelzés arról, hogy egy üzenet elküldése sikeres volt-e, vagyis hálózati problémák esetén naplóüzenetek elveszhetnek útközben.
A torlódásvezérlés hiánya miatt elvileg előfordulhat, hogy az UDP-s naplóüzenetek telítik a hálózatot.
A TCP-kapcsolatok viszonylag egyszerűen biztonságossá tehetők SSL/TLS használatával; elterjedt, szabványos UDP fölötti alkalmazási rétegbeli titkosító-hitelesítő technológia nincs.
UDP-csomagot könnyebb hamisítani, mint TCP-t (amihez session spoofing is kell), így könnyebb hamis naplóüzenetet küldeni UDP-n.

(Erre a kérdésre az a hallgató, akinek a zh-jában szerepelt, nem válaszolt.)

12 Tűzfalak

  • Hasonlítsa össze a DROP és a REJECT iptables-akció működését! Mikor és miért érdemes vagy lehet az egyiket vagy a másikat használni? Mondjon példákat! (6 pont)
Helyes válasz:
A DROP eldobja a csomagot; a REJECT szintén eldobja a csomagot, de erről értesíti a csomag feladóját egy ICMP-üzenettel vagy (választhatóan) egy TCP RST csomaggal. TCP RST csomagot értelemszerűen csak TCP-csomagra tudunk válaszolni; ICMP-csomagra pedig egyáltalán nem válaszolhatunk, nehogy visszacsatolt hurok képződhessen.
A REJECT előnye az, hogy a távoli gép megtudja, hogy a csomagja nem elveszett, hanem nem kértük, így esetleg nem próbálkozik feleslegesen újra (meg újra meg újra). Jó példa arra, amikor ez nekünk (a tűzfal üzemeltetőjének) is jó, az auth (ident) szolgáltatás; ha a 113-as TCP portra jövő kapcsolatokat egyszerűen eldobjuk, akkor olyankor, amikor bizonyos szolgáltatásokat (pl. IRC) próbálunk igénybe venni, ki kell várnunk, amíg a távoli szerver feladja a próbálkozásokat az auth porton; míg ha azonnal küldünk TCP RST-t, akkor az első próbálkozás után rájön, hogy nincs azon a porton semmi, és nem kell kivárnunk a félperces nagyságrendű timeoutot.
A REJECT hátránya ugyanakkor, hogy egyrészt elárulja, hogy az adott címen egyáltalán van számítógép, másrészt pedig forgalmat generál, ami felhasználható lehet DoS-támadáshoz. Ezért ügyelni kell arra, hogy a REJECT szabályaink által generált forgalmat rátalimitáljuk.
Másfelől viszont előnye a REJECTnek, hogy nem árulja el, hogy tűzfal védi a gépet: a védett szolgáltatások portjai úgy viselkednek, mintha csakugyan nem futna ott szolgáltatás, nem pedig úgy, mintha szűrnénk az oda irányuló forgalmat. Emellett "jólneveltség" is jelezni, hogy egy szolgáltatás nem elérhető.
A DROPot akkor célszerű használni, ha a bejövő csomag nyilvánvalóan ártó szándékú; pl. egy ismert spammer IP-jéről jövő SMTP-kapcsolatfelvétel. Ha küldünk neki TCP RST-t, azzal megkönnyítjük a dolgát, ha viszont csak eldobjuk a csomagját, akkor egy darabig még lekötjük az idejét, mert esetleg párszor még megpróbálja.
Egy válasz a zh-ból (betű szerint):
DROP: a csomagot eldobjuk, a küldőt nem értesítjük erről. Pl. támadások érzékelésekor célszerű (portscan esetében lelassítja a támadást, ki kell várnia a timeoutot a támadónak).
REJECT: a csomagot eldobjuk, a küldő kap erről értesítést. Ha szeretnénk, hogy a küldő értesüljön a csomag eldobásáról, ez a célszerű.
Kommentár: a válasz csak 3 pontot ér, mivel:
- nem írja le, milyen értesítést küld a REJECT a feladónak;
- nem mond konkrét példát arra, hogy mikor jó REJECT-et használni;
- nem szükségszerűen igaz, hogy portscan esetén a támadónak bármit is ki kellene várnia: megteheti, hogy minden vizsgált portra párhuzamosan elküld egy, majd röviddel később még egy, majd még egy csomagot, aztán csak a beérkező válaszokkal foglalkozik; ahonnan nem jön válasz, arról pedig feltételezi, hogy nem elérhető/szűrve van.

  • Milyen esetekben érdemes a Netfilterben rátalimitet használni és miért? Mondjon néhány példát! (6 pont)
Helyes válasz:
Rátalimitet elsősorban kimenő vagy átmenő forgalomra érdemes beállítani; arra is akkor, ha van olyan forgalom, ami nem létfontosságú, de hasznos, viszont nem szeretnénk, ha megtölthetné a kimenő vonalunkat (vagy a tűzfalunk mögött található hálózat bejövő vonalát). Ilyen például a REJECT szabályaink által generált TCP RST csomagok által képviselt forgalom; vagy a hasznosnak ítélt ICMP-típusok (azt nem szertnénk, ha egy bejövő Echo Request floodra kimenő Echo Reply flooddal válaszolnánk, de az azért nem árt, ha a ping amúgy működik). Ezen túlmenően célszerű rátalimitálni a naplózást végző szabályokat is, hogy ha valaki tudja, milyen csomagokat naplózunk, akkor se legyen képes arra, hogy tetszőleges mennyiségű naplóüzenetet gyártasson velünk rövid idő alatt.
Egy válasz a zh-ból (betű szerint):
Bizonyos DoS támadások elkerülése érdekében.
Vagy bizonyos mennyiségű csomag utáni naplózás bekapcsolásáért. -> PL: 100/s beérkező csomag a 113-as porton még nem érdekes, de utána már gyanús.
A DoS támadások egy része "elárasztáson" alapul: érdemes pl. a beengedett echo-request-eket valami a szerver feladatkörének megfelelően x/s-ra állítani. X eleme [0, végtelen[ (0 pl. otthon router, 100/s pl. BME levelezőszerver).
Ugyanígy minden portra lehet limiteket beállítani.
Kommentár: A válasz 4 pontot ér.
Alapvetően igaz, hogy bizonyos DoS támadások elkerülése érdekében célszerű rátalimiteket alkalmazni, de a konkrétumok sajnos nem teljesen jók.
Érdekes ötlet, hogy naplózzuk, ha 100/s-nál több csomag érkezik valamelyik portunkra; nekem nem jutott volna eszembe erre használni a rátalimitet, de végülis megoldható (egy olyan szabállyal, ami 100/s-os rátával naplózás nélkül elfogadja a csomagokat, aztán a következő szabály valami rátalimittel naplóz, az ezutáni pedig válogatás nélkül elfogad).
A beengedett echo-requestek rátájának korlátozása közvetve éri el ugyanazt a hatást, amit közvetlenül a kimenő echo reply csomagok rátájának korlátozásával érhetnénk el; erre viszont úgyis szükség van, úgyhogy a bejövő rátalimit majdnem felesleges (azért csak majdnem, mert ha a bejövő csomagokat rátalimitáljuk, akkor létre sem jön a hozzájuk tartozó, a kimenő rátalimit miatt úgyis halva születő válaszcsomag, és ezzel megspórolunk egy kis processzoridőt).
Az "ugyanígy minden portra lehet limiteket beállítani" vélhetően azt jelenti, hogy lehet a portra érkező kapcsolatok rátáját korlátozni. Ezt viszont ész nélkül nem érdemes megtenni, mert így azzal szúrunk ki a legkevésbé, aki a legtöbb kapcsolatot próbálja felépíteni, mivel az ő csomagjaiból van a legtöbb, és így neki van a legtöbb esélye mégis átcsúszni a korláton. Amúgy is kérdéses, miért akarnánk egy népszerű szolgáltatásra érkező kapcsolatkérések rátáját korlátozni; a számukat akarhatjuk (ha a szerverünk legfeljebb x darab klienst tud megfelelő minőségben párhuzamosan kiszolgálni), de a rátájukat miért?
Kifejezetten hiányzik a válaszból, hogy a naplózó szabályokat a naplóüzenet-dömping elkerülése végett lényegében minden esetben rátalimitálni kell.

  • Milyen fogalmakkal dolgozik a Linux Netfilter alrendszere? Magyarázza el, melyik micsoda! (8 pont).
Helyes válasz:
Elsősorban a tábla, a lánc, a szabály, az illesztés (match) és az akció (target) fogalmát kell elmagyarázni. Ezt valószínűleg lehetetlen megtenni a csomag útjának valamilyen mélységű ismertetése nélkül. Nem ismétlem meg itt azt, amit a Tűzfalak szócikkben leírtam.
Egy válasz a zh-ból (betű szerint):
Tábla: 3 táblát használ alapesetben a netfilter, filter, nat és mangle. A filter táblába kerülnek a hagyományos értelemben vett csomagszűrőszabályok (a 2.4-es kernel előtti netfilterben tekinthető úgy, hogy csak ez az egy tábla volt), azaz a node számára kimenő, bejövő és áthaladó csomagokra adhatunk meg szabályokat. A nat táblába a hálózati címfordítással kapcsolatos szabályok kerülnek, a mangle táblába pedig a csomagok jelölésével kapcsolatos szabályok.
Lánc: A a táblákban a szabályok láncokra tagolódnak. A beépített láncoknak előre meghatározott szerepük van, a felhasználók által létrehozott láncok általában valamelyik beépített láncra hivatkoznak. Pl. a filter tábla beépített láncai az INPUT, az OUTPUT és a FORWARD, amik rendre a bejövő, a kimenő, és a node-on áthaladó csomagokra hivatkoznak.
cél (target): a csomagok célja, azaz megadja, hogy az adott szabályra illeszkedő csomaggal mit csináljon a kernel. Ilyen pl. a DROP, ami az adott csomagot eldobja, vagy az ACCEPT, ami elfogadja.
Egy szabály megadása az iptables program segítségével kb. így néz ki: iptables -t tábla -A/D/valami lánc (-p protokoll, -s IP, stb.) -j (vagy -g vagy valami) cél
Kommentár: a válasz 6 pontot ér, mivel nem tér ki a match (illesztés) fogalmára, és kicsit zavarosan ismerteti a láncokat - mit jelent az, hogy "a felhasználók által létrehozott láncok valamelyik beépített láncra hivatkoznak"? Éppen fordítva van: a beépített láncokból fogunk elágazni a saját láncainkra, vagyis a beépítettek "hivatkoznak" a felhasználó által definiált láncokra. Van még néhány kisebb pontatlanság (pl. a mangle táblában módosíthatjuk is a csomagokat, nemcsak megjelölhetjük őket; újabban van egy raw tábla is; stb.), de ezek nem fontosak.

13 A munin működése

  • Milyen esetben érdemes COUNTER helyett DERIVE típusúnak definiálni egy adatot a munin (rrdtool) számára, és miért? (4 pont)
Helyes válasz:
(A COUNTER típusú adatról az rrdtool feltételezi, hogy monoton nő; tehát ha az értéke csökkent, akkor egy 32 vagy egy 64 bites számláló túlcsordult.)
(A DERIVE típusú adatnál az rrdtool nem feltételez monotonitást; a kiolvasott érték idő szerinti deriváltját ábrázolja, ami lehet negatív is.)
Akkor érdemes DERIVE-ot használni COUNTER helyett, ha:
- olyan számlálónk van, ami viszonylag gyakran resetelődik anélkül is, hogy túlcsordulna (pl. reboot miatt); de
- nem tudunk vagy akarunk konkrét felső korlátot megadni az általa számolt mennyiség növekedési rátájára (amit az rrdtool a grafikonban ábrázol); viszont
- zavarnak a grafikonokban az rrdtool által feltételezett túlcsordulásokat korrigálni hivatott 232-es tüskék; de
- az nem zavar minket, ha a számláló valódi túlcsordulásakor a grafikonban nem látunk semmit.
A DERIVE-hoz ilyenkor elég egy univerzális, 0-ás alsó korlátot megadni; a COUNTERnek viszont (ha pl. hálózati forgalomról van szó) minden gépen kellhet más korlát (pl. mert mindenhol más az upstream sávszélesség).
Egy válasz a zh-ból (betű szerint):
Ez két különböző számláló típus, akkor érdemes COUNTER helyett DERIVE-ot használni, ha a számláló nem növekedhet minden határon túl.
Kommentár: a válasz sajnos csak 1 pontot ér, mivel nem indokolja meg, hogy miért érdemes DERIVE-ot használni akkor, ha a "a számláló nem növekedhet minden határon túl", ez viszont önmagában érthetetlen. Az egy pont azért jár, mert a hallgató látszólag tisztában van azzal, hogy egyáltalán micsoda a COUNTER és a DERIVE.

  • rrdtoollal (ezt használja a munin) szeretnénk grafikont rajzolni arról, hogy hány kérést szolgál ki a webszerverünk. A webszervertől meg tudjuk kérdezni, hány kérés érkezett az elindítása óta összesen. Milyen típusú adatként vegyük fel ezt az adatforrást az rrdtoolban? COUNTER, GAUGE, DERIVE vagy ABSOLUTE? Miért? (4 pont)
Helyes válasz:
Vegyük sorra, melyik jön számításba. Ugyebár egy olyan adatot fogunk kiolvasni, ami normális körülmények között monoton nő (a webszerver elindítása óta kiszolgált kérések száma nem tud csökkenni), viszont a webszerver újraindítása esetén nullázódik.
COUNTER: ez jó; az egyetlen baj vele az, hogy a webszerver újraindulásakor túlcsordulást fog feltételezni, és 232-t hozzá fog adni a kiolvasott értékhez, vagyis minden restart után lesz egy nagy tüskénk a grafikonban. Ezeknek a kiszűrése viszonylag nehéz, mert nem biztos, hogy könnyen meg tudjuk mondani, hány kérés/s-nak látszó forgalom esetén kell érvénytelenként eldobni az adatot. Persze nem valószínű, hogy 106-nál több kérést tudnánk kiszolgálni másodpercenként, úgyhogy ha ezt adjuk meg maximumnak, azzal már jók vagyunk (ha ennél nagyobb értéket vél olvasni az rrdtool, akkor UNKNOWN értéket ír be az adatbázisába).
GAUGE: ez nem lesz jó; a grafikonon is azt látnánk, hogy elindulása óta hány kérést szolgált ki a webszerver, mi viszont általában valamilyen időegységre vetítve szeretnénk ezt tudni (mondjuk percenként vagy másodpercenként).
DERIVE: ez szintén jó, mivel a kiolvasott érték idő szerinti deriváltját fogja ábrázolni, ami éppen az, ami nekünk kell (ha 5 perc után 100 kérés, és 10 perc után is 100 kérés, akkor a derivált nulla, és ez összevág azzal, hogy ez alatt az öt perc alatt egyetlen kérést sem szolgáltunk ki). A webszerver újraindítása után a derivált negatív lesz, úgyhogy negatív tüskét láthatunk a grafikonon; ezt könnyű kiküszöbölni úgy, hogy nullára állítjuk az adat értékkészletének alsó határát.
ABSOLUTE: ez szintén rossz választás, mivel a feladat szövege szerint a számláló nem nullázódik kiolvasáskor, az rrdtool viszont ezt feltételezné; így a monoton növekvő számlálóból arra következtetne, hogy minden periódusban egyre több és több kérést szolgáltunk ki. Az előző számokkal számolva az első öt perc alatt is százat és a második alatt is százat. Ha 15 perc után 150-en állna a webszerver számlálója (vagyis a harmadik ötperces periódusban 50 kérést dolgozott fel), akkor ABSOLUTE adattípus esetén az rrdtool azt gondolná, hogy minde a 150 kérés az utolsó öt percben keletkezett.
Összefoglalva: a COUNTER vagy a DERIVE lehet jó választás. A COUNTER esetében a maximumot, a DERIVE esetében a minimumot kell helyesen beállítani ahhoz, hogy a nem kívánt tüskéket elkerüljük. Mindkét esetben torzítani fogja az értékeket, ha a webszerver újraindulása utáni következő kiolvasáskor a számláló már elérte a legutolsó kiolvasáskori értéket; az rrdtool nem fogja észrevenni, hogy újraindítás történt, és úgy fog számolni, mintha nem lett volna restart. Ezen sajnos nem lehet segíteni.
Egy válasz a zh-ból (betű szerint):
ABSOLUTE-ot használnék, mert ebben az esetben a számláló minden kiolvasáskor RESET-et kap, így nem csordulhat túl."
Kommentár: a válasz sajnos nem ér pontot. Az rrdtool nem tudja befolyásolni, hogy a számláló rendelkezik-e azzal a tulajdonsággal, hogy kiolvasáskor nullázódik; ez a kérdéses számlálónak egy adottnak vehető tulajdonsága, amihez nekünk alkalmazkodnunk kell, amikor az rrdtoolt beállítjuk. Az sem igaz, hogy a kiolvasáskor nullázódó számlálók nem csordulhatnak túl; értelemszerűen ha két kiolvasás között többel nő meg az értékük, mint amennyit tárolni tudnak, akkor ugyanúgy túlcsordulnak, mintha nem nullázná őket a kiolvasás. (Az azért igaz, hogy "ritkábban" vagy "kisebb valószínűséggel" csordulnak túl, mint nem nullázódó társaik.)

14 A Nagios működése

  • Mire és miért kell odafigyelni sok szolgáltatás monitorozása esetén (pl. ötpercenként meg akarunk győződni arról, hogy megy mind a 3000 webszerverünk)? Hogyan oldja meg ezt a problémát a Nagios? (5 pont)
Helyes válasz:
Nagyszámú szolgáltatás monitorozásakor több fontos problémával is szembe kell nézni. Ezek közül az egyik az, hogy a monitorozással kapcsolatos terhelés minél egyenletesebben jelentkezzen, tehát ne egyszerre akarjuk a 3000 webszerver állapotát lekérdezni, mert az ennyire szélsőségesen börsztös forgalmat esetleg nem bírja jól a hálózatunk, és a mérési eredményeket is eltorzíthatja; pl. lehet, hogy azért mérünk rossz reakcióidőt, mert elfogyott a sávszélesség, és nem azért, mert lassú a webszerver. Ezt a problémát a Nagios "okos" ütemezője megpróbálja megoldani, és aránylag egyenletesen elosztani a próbálkozásokat úgy, hogy mindegyikre az előírt gyakorisággal kerüljön sor, de lehetőleg minél kevesebb történjen egyszerre. NEMHASZ: Ne Monitorozzuk Halálra A Szolgáltatásokat.
Egy másik gond forrása az lehet, ha a monitorozó gép hálózati kapcsolata megszakad; ebben az esetben mind a 3000 webszervert egyszerre látja meghibásodni, és mindegyikről szépen küld is emailt, vagy rosszabb esetben sms-t. Ezt a Nagios-szal úgy kerülhetjük el, ha függőségeket vezetünk be a szolgáltatások között; így pl. ha nem látjuk a default gatewayt, csak erről az eseményről kapunk értesítést, és az ettől függő további tesztekre (a 3000 db webszerver ellenőrzésére) sor sem kerül.
Egy válasz a zh-ból (betű szerint):
A monitorozás szempontjából lényeges, hogy ne arról szóljon üzenet a monitorozónak, hogy egy adott szolgáltatás nem megy, hanem arról, hogy működik. A jelzés elmaradása esetén pedig riasszon minket. Fontos szempont, hogy a monitorozás ne vegyen nagyobb mennyiségű erőforrást igénybe,mint az adott szolgáltatás / ez akkor fontos, ha a monitorozás és a szolgáltatás ugyanazokat az erőforrásokat használja / Így a példában szereplő 3000 webszerver egyszerre történő állapotlekérdezése a hálózaton csúcsterhelést jelent. A lekérdezéseket osszuk szét az ötperces időtartamban, így elkerülhetjük a túlterhelést. Ha egyszerre vizsgálnánk az összeset, akkor elképzelhető lenne, hogy a webszerverek pingelése akkora terhelést okozna hálózatunkon, hogy a webszerverek nem lennének elérhetőek.
Kommentár: a válasz 3,5 pontot ér. A két probléma közül az egyiket jól leírja, és a kérdés sajnos olyan értelemben félrevezető volt, hogy egyes számban beszélt "a problémáról", azt a látszatot keltve, hogy csak egy van. A válasz ugyanakkor nem említi, hogy a Nagios képes lenne arra, hogy egyenletesen ossza el a próbálkozásokat; ezen túlmenően webszerverek elérhetőségét nem pingeléssel vizsgáljuk, hanem HTTP-kéréssel (hiába ping, ha az apache lerohadt, ill. a webszerver működhet akkor is, ha pingelni nem tudjuk).
Személyes eszközök