A dokumentumban a
félkövéren fogjuk
szedni az alkalmazásokat, és
egyenszélességű
betűkkel pedig az adott parancsokra hivatkozunk. A
protokollokat nem különböztetjük meg. Ez a
tipográfiai elkülönítés hasznos
például az ssh egyes vonatkozásainak
esetén, mivel ez egyben egy protokoll és egy
parancs is.
A most következő szakaszok a FreeBSD védelmének azon módszereit ismertetik, amelyekről a fejezet előző szakaszában már írtunk.
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.
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.
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.
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).
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).
Az 1
és az afeletti
védelmi szinteken többek közt az X11 nem
feltétlenül lesz futtatható (mivel a
/dev/io
eszköz elérése
blokkolt), illetve a rendszer frissítése is
akadályokba fog ütközni (a
installworld
futtatása
során ideiglenesen ki kell kapcsolni az append-only
és immutable állományjelzőket). Az
X11 esetében ezt valahogy még ki lehet
kerülni úgy, hogy ha az xdm(1) démont
még a rendszerindítás elején
aktiváljuk (amikor a védelmi szint még
kellően alacsony). Az összes védelmi szint
és megszorítás esetén azonban nem
mindig adható ilyen jellegű javaslat, ezért
ilyenkor mindig érdemes előre tervezni egy
keveset. Emellett fontos alaposan megismerni a
különböző védelmi
megszorításokat, mivel jelentős
mértékben visszafoghatják a rendszer
használhatóságát. Ez segít
az adott helyzetben az egyszerűbb megoldást
választani és ezáltal elkerülni a
kellemetlen meglepetéseket.
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!
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.
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.
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:
A létjövő szerverpéldányok korlátozása.
Az ugródeszkaszerű támadások (támadás ICMP-válasszal, pingszórás stb.) korlátozása.
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:
A rendszermag nem reagál elég gyorsan amikor egy alig terhelt szervert hirtelen megtámadnak.
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.
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.
Ha kérdése van a FreeBSD-vel kapcsolatban, a
következő címre írhat (angolul):
<questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon:
<gabor@FreeBSD.org>.