14.3. A FreeBSD védelme

14.3.1. A rendszergazda és a személyzet hozzáférésének védelme

Először is: ne törjük magunkat a személyzeti fiókok biztonságossá tételével, ha még a rendszergazda hozzáférését sem tettük eléggé biztonságossá. A legtöbb rendszerben a root hozzáféréshez tartozik egy jelszó. Elsőként fel kell tennünk, hogy ez a jelszó mindig megszerezhető. Ez természetesen nem arra utal, hogy el kellene távolítanunk. A jelszó szinte mindig szükséges a számítógép konzolon keresztüli eléréséhez. Valójában arra szeretnénk rávilágítani, hogy a konzolon kívül sehol máshol ne lehessen használni ezt a jelszót, még a su(1) paranccsal sem. Például gondoskodjunk róla, hogy az /etc/ttys állományban megadott pszeudó terminálokat “insecure” (nem biztonságos) típusúnak állítottuk be, és így a telnet vagy az rlogin parancsokon keresztül nem lehet rendszergazdaként bejelentkezni. Ha más szolgáltatáson keresztül jelentkezünk be, például az sshd segítségével, akkor ebben az esetben is gondoskodjunk róla, hogy letiltottuk a közvetlen rendszergazdai bejelentkezés lehetőségét. Ezt úgy tudjuk megtenni, ha megnyitjuk az /etc/ssh/sshd_config állományt és a PermitRootLogin paramétert átállítjuk a NO értékre. Vegyünk számba minden lehetséges hozzáférési módot -- az FTP és a hozzá hasonló módok gyakran átszivárognak a repedéseken. A rendszergazdának csak a rendszerkonzolon keresztül szabad tudnia bejelentkeznie.

Természetesen egy rendszergazdának valahogy el kell érnie a root hozzáférést, ezért ezzel felnyitunk néhány biztonsági rést. De gondoskodjunk róla, hogy ezek a rések további jelszavakat igényelnek a működésükhöz. A root hozzáférés eléréséhez érdemes felvenni tetszőleges személyzeti (staff) hozzáféréseket a wheel csoportba (az /etc/group állományban). Ha a személyzet tagjait a wheel csoportba rakjuk, akkor innen a su paranccsal fel tudjuk venni a root felhasználó jogait. A személyzet tagjait létrehozásukkor közvetlenül sose vegyük fel a wheel csoportba! A személyzet tagjai először kerüljenek egy staff csoportba, és majd csak ezután az /etc/group állományon keresztül a wheel csoportba. A személyzetnek csak azon tagjait tegyük ténylegesen a wheel csoportba, akiknek valóban szükségük van a root felhasználó hozzáférésére. Ha például a Kerberost használjuk hitelesítésre, akkor megcsinálhatjuk azt is, hogy a Kerberos .k5login állományában engedélyezzük a ksu(1) parancson keresztül a root hozzáférés elérését a wheel csoport alkalmazása nélkül. Ez a megoldás talán még jobb is, mivel a wheel használata esetén a behatolónak még mindig lehetősége van hozzájutni a root hozzáféréséhez olyankor, amikor a kezében van a jelszavakat tároló állomány és meg tudja szerezni a személyzet valamelyik tagjának hozzáférését. A wheel csoport által felkínált megoldás ugyan jobb, mint a semmi, de kétségtelenül nem a legbiztonságosabb.

A hozzáférések teljes körű letiltásához a pw(8) parancsot érdemes használni:

# pw lock személyzet

Ezzel meg tudjuk akadályozni, hogy a felhasználó akármilyen módon, beleértve az ssh(1) használatát is, hozzá tudjon férni a rendszerünkhöz.

A hozzáférések blokkolásának másik ilyen módszere a titkosított jelszó átírása egyetlen “*” karakterre. Mivel ez a karakter egyetlen titkosított jelszóra sem illeszkedik, ezért a felhasználó nem lesz képes bejelentkezni. Ahogy például a személyzet alábbi tagja sem:

izemize:R9DT/Fa1/LV9U:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh

Erre cseréljük ki:

izemize:*:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh

Ezzel megakadályozzuk, hogy az izemize nevű felhasználó a hagyományos módszerekkel be tudjon jelentkezni. Ez a megoldás azonban a Kerberost alkalmazó rendszerek esetén nem működik, illetve olyan helyezetekben sem, amikor a felhasználó az ssh(1) paranccsal már létrehozott magának kulcsokat.

Az ilyen védelmi mechanizmusok esetében mindig egy szigorúbb biztonsági szintű gépről jelentkezünk be egy kevésbé biztonságosabb gépre. Például, ha a szerverünk mindenféle szolgáltatásokat futtat, akkor a munkaállomásunknak egyetlen egyet sem lenne szabad. A munkaállomásunk biztonságossá tételéhez a lehető legkevesebb szolgáltatást szabad csak futtatnunk, de ha lehet, egyet sem, és mindig jelszóval védett képernyővédőt használjuk. Természetesen ha a támadó képes fizikailag hozzáférni a munkaállomásunkhoz, akkor szinte bármilyen mélységű védelmet képes áttörni. Ezt mindenképpen számításba kell vennünk, azonban ne felejtsük el, hogy a legtöbb betörési kísérlet távolról, hálózaton keresztülről érkezik olyan emberektől, akik fizikailag nem férnek hozzá a munkaállomásunkhoz vagy a szervereinkhez.

A Kerberos és a hozzá hasonló rendszerek használatával egyszerre tudjuk a személyzet tagjainak jelszavát letiltani vagy megváltoztatni, ami egyből érvényessé válik minden olyan gépen, ahová az adott felhasználónak bármilyen hozzáférése is volt. Nem szabad lebecsülnünk ezt a gyors jelszóváltási lehetőséget abban az esetben, ha a személyzet valamelyik tagjának hozzáférését megszerezték. Hagyományos jelszavak használatával a jelszavak megváltoztatása N gépen igazi káosz. A Kerberosban jelszóváltási megszorításokat is felállíthatunk: nem csak a Kerberos által adott jegyek járnak le idővel, hanem a Kerberos rendszer meg is követelheti a felhasználóktól, hogy egy adott idő (például egy hónap) után változtasson jelszót.

14.3.2. A rendszergazdai jogokkal futó szerverek és SUID/SGID engedélyekkel rendelkező programok védelme

A bölcs rendszergazda mindig csak akkor futtat szervereket, amikor szüksége van rá, se többet, se kevesebbet. Az egyéb fejlesztőktől származó szerverekkel bánjunk különösen óvatosan, mivel gyakran hajlamosak hibákat tartalmazni. Például az imapd vagy a popper használata olyan, mintha az egész világnak ingyenjegyet osztogatnánk a rendszerünk root hozzáféréséhez. Soha ne futtassunk olyan szervert, amelyet nem vizsgáltunk át kellő alapossággal. Sok szervert nem is feltétlenül kell root felhasználóként futtatni. Például az ntalk, comsat és finger démonok egy speciális járókában (sandbox) futnak. Ezek a járókák sem teljesen tökéletesek, hacsak erre külön figyelmet nem fordítunk. Ilyenkor a többvonalas védelem eszménye még mindig él: ha valakinek sikerült betörnie a járókába, akkor onnan ki is tud törni. Minél több védelmi vonalat húzunk a támadó elé, annál jobban csökken a sikerének valószínűsége. A történelem során lényegében minden root jogokkal futó szerverben, beleértve az alapvető rendszerszintű szervereket is, találtak már biztonsági jellegű hibát. Ha a gépünkre csak az sshd szolgáltatáson keresztül tudnak belépni, és soha nem használja senki a telnetd, rshd vagy rlogind szolgáltatásokat, akkor kapcsoljuk is ki ezeket!

A FreeBSD most már alapértelmezés szerint járókában futtatja az ntalkd, comsat és finger szolgáltatásokat. Másik ilyen program, amely szintén esélyes lehet erre, az a named(8). Az /etc/defaults/rc.conf megjegyzésben tartalmazza a named járókában futtatásához szükséges paramétereket. Attól függően, hogy egy új rendszert telepítünk vagy frissítjük a már meglévő rendszerünket, a járókákhoz tartozó speciális felhasználói hozzáférések nem feltétlenül jönnek létre. Amikor csak lehetséges, az előrelátó rendszergazda kikísérletez és létrehoz ilyen járókákat.

Vannak más olyan szerverek, amelyek tipikusan nem járókákban futnak. Ilyen többek közt a sendmail, popper, imapd, ftpd és még sokan mások. Léteznek rájuk alternatívák, de a telepítésük valószínűleg több munkát igényel, mint amennyit megérné számunkra vesződni velük (és itt megint lesújt a kényelmi tényező). Ezeket a szervereket többnyire root felhasználóként kell futtatnunk és a rajtuk keresztül érkező betörési kísérleteket más módokra támaszkodva kell észlelnünk.

A root felhasználó keltette biztonsági rések másik nagy csoportja azok a végrehajtható állományok a rendszerben, amelyek a suid és sgid engedélyekkel rendelkeznek, futtatásuk rendszergazdai jogokkal történik. Az ilyen binárisok többsége, mint például az rlogin, a /bin és /sbin, /usr/bin vagy /usr/sbin könyvtárakban található meg. Habár semmi sem biztonságos 100%-ig, a rendszerben alapértelmezetten suid és sgid engedéllyel rendelkező binárisok ebből a szempontból meglehetősen megbízhatónak tekinhetőek. Alkalmanként azonban találnak a root felhasználót veszélyeztető lyukakat az ilyen binárisokban is. Például 1998-ban az Xlib-ben volt egy olyan rendszergazdai szintű hiba, amellyel az xterm (ez általában suid engedéllyel rendelkezik) sebezhetővé vált. Mivel jobb félni, mint megijedni, ezért az előretekintő rendszergazda mindig igyekszik úgy csökkenteni az ilyen engedélyekkel rendelkező binárisok körét, hogy csak a személyzet tagjai legyenek képesek ezeket futtatni. Ezt egy olyan speciális csoport létrehozásával oldhatjuk meg, amelyhez csak a személyzet tagjai férhetnek hozzá. Az olyan suid binárisoktól pedig, amelyeket senki sem használ, igyekszik teljesen megszabadulni (chmod 000). A monitorral nem rendelkező szervereknek általában nincs szükségük az xterm működtetésére. Az sgid engedéllyel rendelkező binárisok is legalább ugyanennyire veszélyesek. Ha a behatoló képes feltörni egy kmem csoporthoz tartozó sgid binárist, akkor képes lesz olvasni a /dev/kmem állomány tartalmát, ezáltal hozzájut a titkosított jelszavakhoz és így megszerezheti magának akármelyik hozzáférést. Sőt, a kmem csoportot megszerző behatolók figyelni tudják a pszeudó terminálokon keresztül érkező billentyűleütéseket, még abban az esetben is, amikor a felhasználók egyébként biztonságos módszereket használnak. A tty csoportot bezsebelő támadók szinte bármelyik felhasználó termináljára képesek írni. Ha a felhasználó valamilyen terminál programot vagy terminál emulátort használ a billentyűzet szimulációjával, akkor a behatoló tud olyan adatokat generálni, amivel a felhasználó nevében adhat ki parancsokat.

14.3.3. A felhasználói hozzáférések védelme

A felhasználók hozzáféréseit szinte a legnehezebb megvédeni. Míg a személyzet tagjaival szemben lehetünk kíméletlenül szigorúak és “ki is csillagozhatjuk” a jelszavukat, addig a felhasználók hozzáféréseivel általánosságban véve ezt nem tehetjük meg. Ha a kezünkben van a megfelelő mértékű irányítás, akkor még győzhetünk és kényelmesen biztonságba helyezethetjük a felhasználók hozzáférését. Ha nincs, akkor nem tehetünk mást, mint állandóan őrködünk a hozzáférések felett. Az ssh és Kerberos használata a felhasználók esetén sokkalta problematikusabb, mivel ilyenkor jóval több adminisztrációra és műszaki segítségnyújtásra van szükség, de még mindig jobb megoldás a titkosított jelszavakhoz képest.

14.3.4. A jelszavakat tároló állomány védelme

Az a legbiztosabb, ha minél több jelszót kicsillagozunk és a hozzáférések hitelesítésére ssh-t vagy Kerberost használunk. Igaz, a titkosított jelszavakat tároló állományt (/etc/spwd.db) csak a root képes olvasni, de a támadó meg tudja szerezni ezt a jogot még olyankor is, ha root felhasználóként nem feltétlenül tud írni.

A rendszerünkben futó biztonsági szkripteknek a jelszavakat tároló állomány változását folyamatosan tudnia kell figyelnie és jelentie (lásd lentebb a Az állományok sértetlenségének ellenőrzése című fejezetet).

14.3.5. A rendszermag belsejének, a nyers eszközök és az állományrendszerek védelme

Ha a támadó megszerzi a root hozzáférését, akkor szinte bármit képes megtenni, de vannak bizonyos előnyei. Például a mostanság fejlesztett legtöbb rendszermag tartalmaz valamilyen beépített csomaglehallgatót, amit FreeBSD alatt a bpf eszköz valósít meg. A támadók szinte mindig megpróbálnak valamilyen csomaglehallgatót használni a feltört gépen. A legtöbb rendszeren azonban nem kell feltétlenül megadnunk ezt az örömet, ezért nem is kell beépítenünk a rendszermagba a bpf eszközt.

De ha még ki is iktatjuk a bpf eszközt, még aggódhatunk a /dev/mem és /dev/kmem miatt. Egyébként ami azt illeti, a behatoló még így is képes írni a nyers eszközökre. Sőt, a rendszermagba képesek vagyunk modulokat is betölteni a kldload(8) használatával. A vállalkozó kedvű támadó a rendszermag moduljaként képes telepíteni és használni a saját bpf eszközét vagy bármilyen más, a csomagok lehallgatására alkalmas eszközt. Az ilyen problémák elkerülése érdekében a rendszermagot a legmagasabb védelmi szinten kell üzemeltetni, tehát legalább egyes szinten.

A rendszermag védelmi szintjét több különböző módon lehet állítani. A védelmi szintet úgy lehet a legegyszerűbben növelni, ha a sysctl paranccsal beállítjuk a kern.securelevel nevű, rendszerszintű változó értékét:

# sysctl kern.securelevel=1

A FreeBSD rendszermag alapértelmezés szerint a -1 védelmi szinten indul. Ez egészen addig -1 marad, amíg a rendszergazda vagy valamelyik init(8) során hívott rendszerindító szkript ezt meg nem változtatja. A rendszer indítása során úgy tudjuk beállítani a megfelelő védelmi szintet, ha az /etc/rc.conf állományban megadjuk a kern_securelevel_enable változót a YES értékkel, illetve kern_securelevel értékeként a kívánt védelmi szintet.

A FreeBSD alapértelmezett védelmi szintje közvetlenül a rendszerindító szkriptek lefutása után -1. Ezt “nem biztonságos módnak” nevezik, mivel az állományok írásáért felelős állományjelzők nem feltétlenül működnek, mindegyik eszköz írható, olvasható és a többi.

Miután a védelmi szintet 1 vagy annál magasabb értékre állítottuk, akkor a rendszer figyelembe veszi a csak hozzáfűzést (append-only) és módosíthatatlanságot (immutable) megszorító állományjelzőket, nem engedélyezi a tiltásukat és az eszközök közvetlenül nem érhetőek el. A különböző védelmi szintek részletesebb bemutatását a security(7) man oldalon olvashatjuk (vagy a FreeBSD 7.0 előtti változataiban a init(8) man oldalon).

Ha a rendszermag védelmi szintjét az 1 érték vagy afelé emeljük, akkor hasznos lehet a fontosabb (lényegében minden olyan programnak, amely a védelmi szint helyes beállítódása előtt lefut) programoknak, könyvtáraknak és szkripteknek beállítani az schg állományjelzőt. Ilyenkor azonban vegyük figyelembe, hogy a rendszer frissítése is nehezebbé válik a magasabb védelmi szinteken. Egy működőképesebb megoldás lehet, ha rendszerünket egy magasabb védelmi szinten használjuk, de nem állítjuk be mindegyik rendszerszintű állományra az schg állományjelzőt. Másik lehetőség még a / és /usr partíciók írásvédett csatlakoztatása. Ne felejtsük el azonban, hogy ha túlságosan szigorúak vagyunk magunkhoz, akkor azzal egyúttal a behatolás észlelését is meg tudjuk nehezíteni!

14.3.6. Az állományok sértetlenségének ellenőrzése: binárisok, konfigurációs állományok stb.

Ha arról van szó, csak a legfontosabb rendszerszintű konfigurációs- és vezérlőállományokat tudjuk megvédeni, még mielőtt a korábban emlegetett kényelmi tényező kimutatná a foga fehérjét. Például, ha a chflags paranccsal beállítjuk az schg állományjelzőt a / és /usr állományrendszereken található legtöbb állományra, akkor az minden bizonnyal csökkenti a hatékonyságunkat, hiszen az állományok védelmének növekedésével csökken az észlelés lehetősége. A védelmi vonalaink közül ugyanis az utolsó talán az egyik legfontosabb -- a detektálás. A felépített biztonsági rendszerünk legnagyobb része szinte teljesen hasztalan (vagy ami még rosszabb, a biztonság hamis érzetét kelti), ha nem vagyunk képesek észrevenni a betörési kísérleteket. A védelmi rendszer egyik részére nem a támadó megállításához, hanem a lelassításához van szükség, hogy így majd munka közben érhessük tetten.

A betörés tényét legjobban a megváltozott, hiányzó vagy éppen váratlanul felbukkanó állományok utáni kutatással tudjuk felismerni. A módosított állományokat általában egy másik (gyakran központosított) korlátozott hozzáférésű rendszerből ellenőrizhetjük a legjobban. Fontos, hogy ha egy korlátozott hozzáférésű, kiemelten védett rendszeren írjuk a védelemért felelős szkripteket, akkor azok szinte teljesen láthatlanok lesznek a támadó számára. A legjobb kihasználás érdekében a korlátozott hozzáférésű gépnek jelentős mértékű rálátással kell rendelkeznie az összes többi gépre, amit írásvédett NFS exportok vagy ssh kulcspárok felhasználásával érhetünk el. A hálózati forgalmat leszámítva az NFS látszik a legkevésbé -- segítségével lényegében észrevétlenül tudjuk figyelni az egyes gépek állományrendszereit. Ha a megfigyelésre használt szerver a kliensekhez switchen keresztül csatlakozik, akkor az NFS gyakran jobb választásnak bizonyul. Ha a szerver hubon vagy több hálózati elemen keresztül éri el a megfigyelni kívánt klienseket, akkor az NFS nem eléggé biztonságos (és hatékony), ezért ilyen esetekben az ssh választása lehet a kedvező még az ssh által hagyott nyomokkal együtt is.

Miután a korlátozott hozzáférésű gépünk legalább látja a hozzátartozó kliensek rendszereit, el kell készítenünk a tényleges monitorozást végző szkripteket. Ha NFS csatlakozást tételezünk fel, akkor az olyan egyszerű rendszereszközökkel, mint például a find(1) és md5(1) képesek vagyunk összerakni ezeket. A szemmel tartott kliensek állományait naponta legalább egyszer érdemes ellenőrizni md5-tel, valamint még ennél gyakrabban is tesztelni az /etc és /usr/local/etc könyvtárakban található konfigurációs és vezérlőállományokat. Ha valamilyen eltérést tapasztal az ellenőrzést végző szerverünk és a rajta levő md5 információk is helyesek, akkor értesítenie kell a rendszergazdát. Egy jó védelmi szkript képes megkeresni az oda nem illő suid binárisokat, valamint az új vagy törölt állományokat a / és a /usr partíciókon.

A védelmi szkriptek megírása valamivel nehezebb feladat, ha ssh-t használunk az NFS helyett. A futtatásukhoz a szkripteket és az általuk használt eszközöket (például find) az scp paranccsal lényegében át kell másolni a kliensekre, amivel így láthatóvá válnak. Ne feledjük továbbá, hogy az ssh kliens már eleve feltört lehet. Szó, ami szó, ha nem megbízható összeköttetésekről beszélünk, akkor az ssh használata elkerülhetetlen, de nem feltétlenül egyszerű.

Egy jó védelmi szkript észreveszi a felhasználók és a személyzet tagjainak hozzáférését vezérlő állományokban, mint például az .rhosts, .shosts, .ssh/authorized_keys és társaiban keletkezett változásokat is, amelyek esetleg elkerülhetik egy MD5 alapú ellenőrzés figyelmét.

Ha netalán órási mennyiségű tárterületettel rendelkeznénk, akkor eltarthat egy ideig, amíg végigsöprünk az összes partíció összes állományán. Ebben az esetben érdemes olyan beállításokat megadni az állományrendszerek csatlakoztatásánál, amivel le tudjuk tiltani a suid engedéllyel rendelkező binárisok futtatását. Ezzel kapcsolatban a mount(8) parancs nosuid opcióját nézzük meg. Hetente legalább egyszer azért mégis érdemes átnézni az ilyen partíciókat is, mivel ez a réteg a betörési kísérletek felderítésével foglalkozik, függetlenül a sikerességüktől.

A futó programok nyilvántartása (lásd accton(8)) egy olyan viszonylag kevés költséggel járó lehetőség az operációs rendszerben, ami segítségünkre lehet a betörés utáni események kiértékelésében. Különösen hasznos olyankor, amikor megpróbáljuk modellezni, miképp is sikerült a támadónak bejutnia a rendszerünkbe, természetesen feltételezve, hogy az ehhez felhasznált feljegyzések a betörés után is érintetlenek maradtak.

Végül a védelmet ellátó szkripteknek javasolt feldolgozni a naplóállományokat is, valamint a naplókat magukat is a lehető legbiztonságosabb formában generálni -- ilyenkor nagyon hasznos lehet, ha egy távoli gépre naplózunk. A behatoló megpróbálja majd eltüntetni a nyomait, a naplóállományok viszont nagyon fontosak a rendszergazda számára a betörési kísérletek idejének és módjának megállapításában. A naplókat úgy tudjuk tartósan rögzíteni, ha a rendszerkonzol üzeneteit soros porton keresztül gyűjtjük össze a konzolok felügyeletéért felelős biztonságos gépen.

14.3.7. Állandó paranoia

Egy kis paranoia sosem árt. Elmondható, hogy a rendszergazda tetszőleges számú biztonsági intézkedéssel élhet egészen addig, amíg az nincs hatással a kényelmére, és a kényelmet befolyásoló biztonsági intézkedéseket pedig megfelelő mérlegelés mellett tegye meg. Ami még ennél is fontosabb, hogy mindig változtassunk valamit a biztonsági hálónkon -- mivel ha egy az egyben követjük a dokumentumban leírtakat, akkor ezzel együtt kiadjuk a bejutás receptjét annak a leendő támadónknak, aki szintén elolvasta ugyanezt.

14.3.8. A szolgáltatások működésképtelenné tételét célzó támadások

Ez a szakasz a szolgáltatások működésképtelenségét elérni kívánó, más néven “Denial of Service” típusú támadásokkal foglalkozik. Noha nem tudunk túlságosan sokat tenni a manapság felbukkanó álcázott, a hálózatunk totális leterhelését célbavevő támadások ellen, akadnak olyan általános érvényű eszközök, amelyekkel elejét vehetjük a szervereink szétbomzásának:

1. A létjövő szerverpéldányok korlátozása.

2. Az ugródeszkaszerű támadások (támadás ICMP-válasszal, pingszórás stb.) korlátozása.

3. A rendszermag útválasztási gyorsítótárának túlterhelése.

A DoS támadások egyik jellemző sémája szerint egy sokszorozódni képes szervert támadnak meg, amelynek igyekeznek minél több példányát legyártatni, míg végül az ezt futtató rendszer ki nem fogy a memóriából, állományleíróból satöbbiből és megállásra nem kényszerül. Az inetd (lásd inetd(8)) számos lehetőséget kínál fel ennek megakadályozására. Ezzel kapcsolatban szeretnénk megjegyezni, hogy bár ezzel el tudjuk kerülni a gépünk leállását, semmilyen garanciát nem ad arra, hogy a szolgáltatás a támadás során is zavartalanul üzemel tovább. Alaposan olvassuk el az inetd man oldalát és legyünk különös tekintettel a -c, -C és -R kapcsolóira. Vigyázzunk, hogy az inetd -C kapcsolóját képesek kijátszani az álcázott IP-vel érkező támadások, ezért inkább az előbbi kapcsolók valamilyen kombinációja az ajánlott. Egyes szerverprogramoknál be lehet állítani a példányainak maximális számát.

A Sendmail rendelkezik egy -OMaxDaemonChildren beállítással, ami a terhelésben levő késleltetése miatt néha mintha jobban beválna, mint a Sendmail terheléskorlátozó paraméterei. A Sendmail indításakor tehát a MaxDaemonChildren paramétert javasolt megadni egy olyan értékkel, amely elegendő a Sendmail számára betervezett terhelés kiszolgálására, de még kevés ahhoz, hogy a Sendmail fűbe harapjon tőle. Továbbá bölcs dolog a Sendmailt várakozási sorral (-ODeliveryMode=queued) és démonként (sendmail -bd), külön feldolgozási menetekkel (sendmail -q15m) futtatni. Ha továbbra is valós idejű kézbesítést akarunk, akkor a feldolgozást kisebb időközökkel is lefuttathatjuk (például -q1m), de arra mindig ügyeljünk, hogy a MaxDaemonChildren beállítása ne okozzon kaszkádosítási hibákat a Sendmail működésében.

A Syslogd közvetlenül is támadható, ezért határozottan javasoljuk a -s használatát, amikor csak lehet, minden más esetben pedig a -a beállítást.

Fordítsunk kellő figyelmet a TCP kapcsolatok burkolását végző TCP Wrapper “reverse-ident” lehetőségére, ami szintén közvetlenül támadható. Ebből az okból kifolyólag valószínűleg nem is akarjuk a TCP Wrapper által felkínált reverse-ident-et használni.

Jól járunk el abban az esetben, ha a belső szolgáltatásainkat az útválasztóink mentén tűzfal segítségével védjük meg a külső hozzáféréstől. Ezzel lényegében a helyi hálózatunkat kívülről fenyegető támadások ellen védekezünk, de ez nem nyújt elegendő védelmet a belső szolgáltatásaink esetén a root hozzáférés megszerzésére irányuló kísérletek ellen. Mindig egy exkluzív, tehát zárt tűzfalat állítsunk be, vagyis “tűzfalazzunk mindent kivéve az A, B, C, D és M-Z portokat”. Ezen a módon ki tudjuk szűrni az összes alacsonyabb portot, kivéve bizonyos eseteket, mint például a named (ha az adott zónában ez az elsődleges gép), ntalkd, sendmail vagy más interneten keresztül elérhető szolgáltatásokat. Ha másképpen állítjuk a tűzfalat -- inkluzív, nyílt avagy megengedő módon, akkor jó eséllyel elfelejtünk “lezárni” egy csomó szolgáltatást, vagy úgy adunk hozzá egy új belső szolgáltatást, hogy közben elfelejtjük frissíteni a tűzfalat. Ennél még azon is jobb, ha a tűzfalon nyitunk egy magasabb portszámú tartományt, és ott valósítjuk meg ezt a megengedő jellegű működést, az alacsonyabb portok veszélybe sodrása nélkül. Vegyük azt is számításba, hogy a FreeBSD-ben a kiosztott portokat dinamikusan állíthatjuk a net.inet.ip.portrange sysctl változókon keresztül (sysctl -a | fgrep portrange), ami nagyságrendekkel megkönnyíti a tűzfal beállítását. Ennek megfelelően például meg tudjuk adni, hogy a 4000-től 5000-ig terjedő porttartomány a 49152-től 65535-ig húzódó tartományba kerüljön át, majd a 4000 alatti összes portot blokkoljuk (természetesen az internetről szándékosan hozzáférhető portok kivételével).

A DoS támadások másik elterjedt fajtája az ún. “ugródeszka támadás” -- ilyenkor a szervert úgy próbálják túlterhelni, hogy folyamatosan válaszokat kérnek tőle a helyi hálózatról vagy egy másik számítógépről. Az ilyen természetű támadások közül is a legnépszerűbb az ICMP pingszórásos támadás. A támadó olyan ping csomagokat küld szét a helyi hálózaton, amelyek forrásának azt a gépet jelöli meg, amelyiket meg akarja támadni. Ha a hálózatokat elválasztó útválasztók nem fogják meg a pingszórást, akkor a helyi hálózatról összes gépe nekilát válaszolgatni a meghamisított forrás címére, amivel így teljesen leterhelik az áldozatot. Ez különösen akkor hatásos, amikor a támadó ugyanezt a trükköt eljátssza egyszerre több tucat különböző hálózatban is. Az üzenetszórással járó támadások akár százhúsz megabitnyi forgalmat is képesek generálni másodpercenként. A második legelterjedtebb ugródeszkás támadás az ICMP hiba-visszajelzési rendszere ellen irányul. Ilyenkor a támadó ICMP hibaüzeneteket kiváltó csomagok készítésével képes eltömíteni egy szerver bejövő hálózati kapcsolatát és az ICMP válaszokkal pedig a szerver maga dugítja el a kimenő hálózati kapcsolatát. Ez a fajtájú támadás képes kinyomni az összes memóriát a szerverből és ezzel összeomlasztani, különösen olyankor, amikor a szerver nem tudja elég gyorsan elnyelni az általa generált ICMP válaszokat. A net.inet.icmp.icmplim sysctl változóval tudunk gátat szabni a támadások ezen fajtájának. Az ugródeszkás támadások utolsó nagyobb osztálya az inetd olyan szolgáltatásait szemeli ki, mint például az udp echo. A támadó ilyenkor egyszerűen küld a helyi hálózatunkon található A és B szerverünknek egy olyan UDP csomagot, ahol forrásként az A szerver echo portját adja meg, célnak pedig a B szerver echo portját. Ezután a két szerver elkezdi egymás között passzolgatni ezt az egyetlen csomagot. A támadó még több ilyen csomag befecskendezésével pillanatok alatt képes leterhelni a két szervert és helyi hálózatot. Hasonló problémák vannak a belső chargen portjával is. Egy hozzáértő rendszergazda ezért kikapcsolja az összes ilyen inetd-alapú belső tesztelő szolgáltatást.

Az álcázott csomagok felhasználhatóak a rendszermag útválasztó gyorsítótárának túlterhelésére is. Ezzel kapcsolatban nézzük meg a net.inet.ip.rtexpire, rtminexpire és rtmaxcache sysctl változókat. A véletlenszerű IP-címekkel megcímzett álcázott csomagok hatására a rendszermag létrehoz mindegyikőjükhöz egy ideiglenesen pufferelt utat az útválasztó táblázatában, amelyet a netstat -rna | fgrep W3 paranccsal tudunk lekérdezni. Az ilyen útvonalak nagyjából 1600 másodperc múlva elévülnek. Ha a rendszermag észleli, hogy a gyorsítótárazott útválasztási táblázat mérete túlságosan megnövekedett, akkor automatikusan csökkenti az rtexpire értékét, de soha nem megy a rtminexpire alá. Ebből két probléma adódik:

1. A rendszermag nem reagál elég gyorsan amikor egy alig terhelt szervert hirtelen megtámadnak.

2. Az rtminexpire nem elég kicsi ahhoz, hogy a rendszermag túléljen egy tartósabb rohamot.

Ha a szervereink az internethez T3 (kb. 45 Mbit/s) vagy gyorsabb összeköttetésen keresztül csatlakoznak, akkor határozottan javasolt kézileg behangolni a sysctl(8) segítségével az rtexpire és az rtminexpire értékeket. Soha ne állítsuk egyiket sem nullára (hacsak nem akarjuk összeomlasztani a gépünket). Ha például mind a kettőt 2 másodpercre állítjuk, akkor az többnyire elegendő az útválasztási táblázat megvédéséhez.

14.3.9. Hozzáférés Kerberosszal és SSH-val

Van néhány dolog, amit a Kerberos és az ssh esetén ajánlatos tisztázni, mielőtt használjuk ezeket. A Kerberos 5 egy kifogástalan hitelesítési protokoll. A telnet és rlogin Kerberos által módosított változatában vannak olyan hibák, amelyek alkalmatlanná teszik ezeket a bináris adatfolyamok helyes kezelésére. Sőt, alapértelmezés szerint a Kerberos nem titkosítja a kapcsolatot, csak ha megadjuk neki a -x kapcsolót. Az ssh alapértelmezés szerint mindent titkosít.

Az ssh minden szempontból nagyon jól teljesít kivéve, hogy alapértelmezés szerint átküldi a kulcsokat is. Ez azt jelenti, hogy ha van egy olyan biztonságos munkaállomásunk, ahol a rendszer többi részéhez tartozó kulcsainkat tartjuk és egy nem biztonságos gépre akarunk vele ssh-n keresztül belépni, akkor a kulcsaink használatóvá válnak. A tényleges kulcsokat ugyan nem látja senki, de a bejelentkezés során az ssh megnyit egy közvetítéshez használt portot, amit a nem biztonságos gépen a támadó egy feltört root hozzáférés birtokában ki tud használni úgy, hogy a kulcsaink segítségével hozzá tudjon férni egy másik olyan géphez, amelyet a kulcsok nyitnak.

Ha lehetséges, akkor a személyzet bejelentkeztetéséhez az ssh-t és Kerberost együttesen használjuk. Az ssh lefordíható Kerberos támogatással. Ezzel csökkentjük a potenciálisan kiszivárgó ssh kulcsok esélyét, miközben jelszavainkat a Kerberosszal védjük. Az ssh kulcsokat csak biztonságos gépekről és csak automatizált feladatok esetén használjuk (amire a Kerberos lényegében nem alkalmas). Emellett javasoljuk azt is, hogy az ssh beállításai között tiltsuk le a kulcsok átküldését (key forwarding) vagy használjuk az from=IP/DOMAIN opciót, amivel az ssh csak a megadott gépekről engedi az authorized_keys állomány és a így benne levő kulcsok használatát.