Egy kis rendszerbiztonság

A biztonság a rendszergazdánál kezdődik, s nála is ér véget. Bár minden BSD UNIX - történeténél fogva - többfelhasználós rendszer, a felhasználók 'kordában tartására' hivatott biztonsági rendszerek kiépítése és rendbentartása talán a legnagyobb a rendszergazdára háruló feladatok közül. A rendszerek csak annyira biztonságosak, amennyire azzá tesszük őket, és a biztonsági megfontolások sohasem egyeztethetők össze az emberek kényelmi igényeivel. A UNIX rendszerek képesek sok folyamat egyidejű futtatására, s ezen folyamatok közül sok szerverként működik - azaz külső entitások kapcsolódhatnak hozzájuk és kommunikálhatnak velük. Ahogyan a tegnap mainframe gépei a ma asztali számítógépeivé válnak, s ahogyan ezek a gépek hálózatokba, illetve hálózatok hálózataiba kapcsolódnak, a biztonság kérdése egyre inkább előtérbe kerül.

A biztonsági megfontolások az alábbi csoportokra oszthatók:

1. Denial of Service támadások
2. Felhasználói fiókok feltörése
3. Root törések szervereken keresztül
4. Root törések felhasználói fiókokon keresztül

A 'denial of service' típusú támadások arra irányulnak, hogy megfosszák a rendszereket a működésükhöz szükséges erőforrásoktól. A DoS támadások tipikusan nyers erőn alapuló támadások: céljuk az, hogy a gépen futó szerverek illetve a hálózati alrendszer túlterhelésével elérhetetlenné tegyék a gépet illetve szolgáltatásait. Egyes DoS támadások a hálózati rendszerben lévő hibákat próbálják kihasználni - így akár egyetlen adatcsomag is elegendő lehet a gép leállításához. Ezen utóbbi támadás egyedüli ellenszere a hibát kijavító kernel-javítócsomag (patch) használata. A támadások gyakran kivédhetők azzal, ha szervereinket úgy konfiguráljuk, hogy rendkívüli körülmények között is csak korlátozott mértékben terhelhessék meg a rendszert. A nyers erőn alapuló támadásokkal már nehezebb megbírkózni. Hamisított adatcsomagokat (spoofed-packet) használó támadást szinte lehetetlen kivédeni anélkül, hogy a rendszerünk ne szigetelődne el az internettől.

A felhasználói fiókok feltörése talán még gyakoribb támadási forma mint a DoS. A legtöbb rendszergazda még mindig a standard telnetd, rlogind, rshd és ftpd szervereket használja a gépein. Ezek a szerverek - alapbeállításaik szerint - nem működnek titkosított adatcsatornákon keresztül. Az eredmény pedig az, hogy egy közepes nagyságú felhasználói kör esetén, ahol egy vagy több felhasználó távolról jelentkezik be a rendszerbe (ami a leggyakrabban használt módja a gépen való munkának), biztos van néhány, akinek lehallgatták (sniff) a jelszavát. A figyelmes rendszergazda gyakran ellenőrzi a távoli bejelentkezések naplófájljait, hogy nem talál-e bennük gyanús kiindulási (source) címeket - akár a sikeres bejelentkezések esetében is.

Mindig szem előtt kell tartani, hogy ha a behatoló hozzáfért valamelyik felhasználó fiókjához, a root fiókot is megtörheti. Egy jól őrzött rendszerben egy felhasználói fiók feltörése persze nem jelent hozzáférést a root jogosultságokhoz. A különbségtétel fontos, mivel root jogok nélkül a behatoló nem tudja sikeresen eltakarítani maga után a behatolás nyomait, s bár az adott felhasználó fájljait letörölheti, vagy leállíthatja a gépet, de nem képes hozzáférni mások adataihoz.

A rendszergazdáknak tudniuk kell, hogy több módja is van a root megtörésének egy rendszeren. A támadó ismerheti a root jelszót, találhat hibát a root által futtatott szerverekben, s hálózaton keresztül feltörheti azokat, esetleg tudhat hibákról suid-root programokban, melyeket kihasználva root jogokat szerezhet megtört felhasználói fiókokból kiindulva.

A biztonsági megoldásoknak mindig több rétege van, melyeket a következőképpen kategorizálhatunk:

1. a root és személyzeti (staff) fiókok biztosítása
2. a root által futtatott szerverek és suid/sgid programok biztosítása
3. a felhasználói fiókok biztosítása
4. a jelszó fájl biztosítása
5. a kernel, a memória, a raw device-ok és a fájlrendszer biztosítása
6. a fájlok integritásának ellenőrzése: binárisok, konfigurációs fájlok, stb.
7. paranoia

A root és a személyzeti (staff) fiókok biztosítása

Felesleges a személyzeti fiókok biztosításával bajlódni, ha a root fiók nincs kellőképpen biztosítva. A legtöbb rendszeren jelszó védi a root fiókot. A legelső dolog, hogy feltételezzük azt, hogy ez a jelszó 'mindig' nyilvánosságra kerül. Hogy ennek ellenére is biztonságban tudhassuk a root fiókot, úgy kell beállítani a rendszert, hogy ne lehessen rootként bejelentkezni bármely felhasználói fiókból, vagy a hálózaton keresztül. Ha még nem tettük volna meg, konfiguráljuk úgy a telnetd, rlogind és más szervereket, melyek képesek bejelentkezéseket fogadni, hogy utasítsák vissza a root login kérelmet, akár helyes volt a megadott jelszó, akár nem. Közvetlen root belépést csak a rendszer konzolján keresztül engedélyezzünk. A /etc/ttys fájl jól jöhet ilyenkor, s bár a rendszerek többségén biztoságosan van beállítva, egy jó rendszergazda csak abban bízik, amit saját maga ellenőrzött.

Természetesen mint rendszergazda be kell hogy tudjunk jelentkezni a rendszerünkbe, ezért nyitva hagyunk pár kaput. De biztosnak kell lennünk abban, hogy ezek a kapuk dupla jelszóvédelemmel vannak ellátva. Az egyik módja annak, hogy a root fiókot elérhetővé tegyük az az, hogy a wheel csoportban (/etc/group). személyzeti fiókokat hozunk létre. Azok, akik ilyen fiókkal rendelkeznek, átváltoztathatják magukat root felhasználóvá (su root). Persze nem kell, hogy a személyzet minden tagja wheel jogokat kaphasson csak mert ilyen bejegyzéssel rendelkezik a jelszófájlban. Hozzunk létre külön 'személyzet' csoportot számukra, s csak az kapjon wheel csoporttagságot, akiknél tényleg indokolt az, hogy root jogosultságokat használjon. Sajnos a wheel módszer ellenére is könnyű megtörni a root fiókot, ha a behatoló megszerzi a jelszófájlt - elegendő a root és valamelyik, wheel csoportba tartozó személyzeti fiók jelszavának a visszafejtése. Így bár a wheel mechanizmus használható, nem nyújt sokkal nagyobb biztonságot annál, mintha nem is létezne wheel csoport egyáltalán.

Egy közvetett módja a root fiók védelmének az, hogy ha a személyzeti fiókok elérésére valamilyen alternatív módszert használunk, s kicsillagozzuk a személyzeti fiókok titkosított jelszavait a jelszófájlban. Ebben az esetben a behatoló még akkor sem tudja feltörni a személyzeti fiókokat, ha hozzájutna a jelszófájlhoz - s ezáltal a root fiók is el lesz zárva előle. A személyzet olyan biztoságos beléptetőmechanizmusokon keresztül érheti el fiókjait mint pl. a kerberos vagy az ssh nyilvános/titkos kulcspárjai. A kerberos használata esetén biztosítani kell a kerberos szervert és az azt használó asztali gépeket. Az ssh nyilvános/titkos kulcspárjainak használatkor főleg azt a gépet kell biztosítani AHONNAN a kapcsolatot kezdeményezik (tipikusan az asztali munkaállomás), de a védelem szintjeinek számát is megnövelhetjük azzal, hogy jelszóval védett kulcspárat hoznuk létre az ssh-keygen programmal. A személyzeti jelszavak kicsillagozása biztosítja azt is, hogy a személyzet a rendszergazda által felállított biztonságos bejelentkezési eszközt használja. Az így használt titkosított adatkapcsolatok egy, a behatolók által előszeretettel használt biztonsági rést zárnak be: a hálózati adatforgalom lehallgatását egy megbízhatatlan, kevéssé biztosított rendszerről.

A legközvetettebb módszer az, ha figyelünk arra, hogy egy korlátozott rendszerbe csak egy még korlátozottabb rendszerből lépjünk be. Például, ha a fő rendszerünkön több szerver is fut, akkor a munkaállomáson ne fusson egy sem. Hogy a munkaállomás megfelelően biztonságos legyen, a lehető legkevesebb szerveralkalmazás fusson rajta, de ha lehetséges, inkább egy se. Használjunk jelszóval védett képernyővédőt. Természetesen a munkaállomáshoz való fizikai hozzáféréssel minden arra telepített védelem kijátszható. Ezt mindenképpen figyelembe kell venni, de érdemes megfontolni azt is, hogy a betörések túlnyomó többsége távoli, hálózaton keresztüli behatolás, olyan emberek által, akiknek nincs fizikai hozzáférése a munkaállomásainkhoz vagy szervereinkhez.

A kerberos illetve a hasonló technológiák lehetőséget adnak arra, hogy letilthassuk vagy megváltoztathassuk egy személyzeti fiók jelszavát egy tetszőleges helyen, s ez azonnal minden gépen érvénybe lépjen, ahol az adott személynek fiókjai vannak. Ha egy személyzeti tag jelszava nyilvánosságra kerül, felbecsületetlenül fontos, hogy mindenhol minél előbb letilthassuk az adott fiókhoz való hozzáférést. Ha egy jelszó megváltozatásához végig kellene járni az összes gépet, sok gondunk lenne. A kerberos azonban lehetővé teszi, hogy jelszóválasztási szabályokat határozzunk meg a felhasználók számára: beállítható, hogy a bejelentkezés egy bizonyos idő múlva érvényét vessze (kerberos ticket timeout), vagy hogy a jelszavakat kénytelenek legyenek bizonyos időközönként megváltoztatni.

A root által futtatott szerverek és suid/sgid programok biztosítása

Egy megbízható adminisztrátor csak azokat a szervereket futtatja, melyekre valóban szüksége van, se többet, se kevesebbet. Figyeljünk arra, hogy a külsős (third party) szerverek a hibák leggyakoribb forrásai. Az imapd vagy a popper régebbi verzióinak a futtatása felér azzal, mintha az egész világ számára univerzális belépőt biztosítanánk a root fiókhoz. Sohase futassunk olyan szervert, melyet nem ellenőriztünk szigorúan. Sok szervernek nem is szükséges hogy root jogokkal fusson. A ntalk, a comsat vagy a finger jó példái azon szervereknek, melyek futhatnak valamilyen felhasználói homokozóban (sandbox) is. Természetesen a sandbox is sok probléma forrása lehet, de a biztonsági technikák réteges felépítése itt is beválik: még ha valakinek sikerül is a szerveren keresztül betörni a sandboxba, az innen való kitörés tovább nehezíti a dolgát. Minél több rétegen kell a behatolónak áthaladnia, annál kisebb az esélye a sikerre. A történelem azt mutatja, hogy minden, rootként valaha is futtatott szerverben találtak már hibát - még a legalapvetőbb rendszerszolgáltatásokban is. Ha egy gépre csak ssh használatával jelentkeznek be a felhasználók, s telnetd-vel, rshd-vel vagy rlogind-val soha, akkor kapcsoljuk ki ezeket a szervereket.

A FreeBSD mostmár alapbeállítás szerint sandboxban futtatja a ntalkd, a comsat és a finger szolgáltatásokat. Egy másik jelölt, amit így lenne érdemes használni, az a named(8). Az alapértelmezett rc.conf tartalmazza az ehhez szükséges beállításokat, de csak kikommentezve. Attól függően, hogy egy új rendszert telepítünk, vagy csak a régit frissítjük, hiányozhat az a speciális felhasználói fiók, amelyet ezek a szolgáltatások használnának sandboxként. Egy gondos rendszergazda minden szervert sandboxban futtat, amikor csak lehetséges.

Persze vannak olyan szerverek is, melyek nem futnak sandboxban: a sendmail, a popper, az imapd, az ftpd és hasonlók. Néhányuk helyett léteznek alternatív megoldások, de azok használata esetleg több munkával járhat, mint amennyit a rendszergazda rájuk szánni kíván (a kényelmi faktor megint betesz). Ezeket a szervereket rootként kénytelen futtatni a rendszer, s csak más módszerekre hagyatkozhatunk az ellenük intézett támadások kivédéséhez.

A rendszerek másik nagy potenciális root hibaforrásai a suid-root és a sgid-root programok. Ezek a binárisok, mint pl a rlogin, a /bin, az /sbin, a /usr/bin és a /usr/sbin könyvtárakban találhatóak. Bár semmi se 100%-ig biztonságos, a rendszer alapvető suid és sgid programjai meglehetősen jók. Ettől függetlenül, néha ezekben is találnak root hibákat. 1998-ban egy ilyen hibát találtak az Xlib-ben, ami miatt az xterm program (amely tipikusan suid) sérülékennyé vált. Jobb tehát előre félni, mint később megijedni, ezért a gondos adminisztrátor a személyzetre korlátozza az ezekhez való hozzáférést illetve ezek futtatását, valamint megszabadul azoktól (chmod 000), melyeket senki sem használ. A szervereknek általában nincs is szüksége az xterm programra. Az sgid binárisok hasonló veszélyeket rejtenek magukban. Ha egy behatoló hozzáfért egy sgid-kmem binárishoz, olvasni tudja a /dev/kmem-et, s ezáltal minden adatot, ami a rendszeren áthalad. A támadó, aki megtöri a tty csoportot (group), képes írni minden felhasználó termináljára. Ha a felhasználó olyan terminálprogramot vagy emulátort használ, mely rendelkezik talk-back funkcióval, a támadó képessé válhat olyan adatfolyam létrehozására, mely arra utasítja a terminált, hogy visszhangozzon valamely parancsot, mely azután mint a felhasználó által kiadott parancs fog futni.

A felhasználói fiókok biztosítása

A felhasználói fiókok biztosítása a legnehezebb feladat. Míg drákói szabályokat kényszeríthetünk a személyzetre, s kicsillagozhatjuk a jelszavukat a jelszófájlban, mindezt nem tehetjük meg a gépünkön lévő általános felhasználói fiókokkal. Ha van elég befolyásunk a dolgokra, elég jól bebiztosíthatjuk ezeket a fiókokat is, ha nincs, egyszerűen nagyobb figyelmet kell szentelnünk ezen fiókok monitorozására. Az ssh vagy a kerberos használata felhasználói fiókokra problematikus, de még mindig jobb megoldás mint a titkos jelszófájl.

A jelszó fájl biztosítása

Az egyetlen tűzbiztos módszer az, ha minél több jelszót csillagozunk ki, és ssh-t vagy kerberost használunk ezen fiókok elérésére. Bár a titkosított jelszófájlt (/etc/spwd.db) csak a root olvashatja, elképzelhető, hogy a behatoló olvasási jogot szerez erre a fájlra, mégha írási jogot nem is. A biztonsági szkripteknek mindig ellenőrizniük kell a jelszófájl integritását, s jelezniük a változásokat (lásd a fájlok integritásáról szóló fejezetet lentebb).

A kernel, a memória, a raw device-ok és a fájlrendszer biztosítása

Ha egy támadó root jogosultságot szerez, szinte mindent képes megtenni a rendszeren, de még így is korlátozhatjuk mozgásterét. Például a modern kernelek legtöbbjében van hálózati 'csomaglehallgató' (sniffing device). FreeBSD alatt ez a 'bpf'. A behatolók gyakran használják ezt a feltört gépeken. Ezt megakadályozandó, kerüljük a bpf eszköz kernelbe fordítását: a legtöbb rendszernek nincs is szüksége erre.

Még a bpf kiiktatása után is van mi miatt aggódnunk: a /dev/mem és a /dev/kmem. A behatoló esetleg írhat a raw device-okra. Egy ügyes támadó a kldload(8) eszközt használja arra, hogy betöltse saját bpf eszközét vagy más csomaglehallgató programját, mint kernelmodult. Hogy mindezeket kivédjük, a kernelt a legmagasabb biztonsági szinten kell futtatnunk, legalább 1-es szinten. A biztonsági szintet a kern.securelevel kernelváltozó határozza meg, amit a sysctl paranccsal szabályozhatunk. Az 1-es biztonsági szinten a kernel nem enged írni a raw device-okra, illetve az olyan speciális chflags jelzők, mint a 'schg' használata kötelezővé válik. Ellenőrizni kell, hogy az 'schg' jelző be van-e állítva a kritikus boot programokon, könyvtárakon vagy szkripteken, tehát minden olyanon, ami azelőtt fut le, hogy a biztonsági szint be nem áll. Ez egy elég biztonságos módszer, de a rendszer frissítése (upgrade) is számottevően nehezebbé válik magasabb biztonsági szinten. Meg kell találni a köztes utat: magasabb biztonsági szintet érdemes használni, de nem kell minden rendszerfájlra 'schg' jelzőt tenni.

A fájlok integritásának ellenőrzése: binárisok, konfigurációs fájlok, stb.

A védelem utolsó és talán a legfontosabb szintje: a detektálás. A rendszer fájljainak ellenőrzése egyetlen elfogadható módon valósítható meg: egy másik, még biztonságosabb rendszerről. Nem nehéz biztonságos rendszert felállítani: egyszerűen nem szabad semmilyen szolgáltatást futtatni rajta. Egy helyben felállított biztonságos rendszerből ssh-n keresztül elérést biztosíthatunk már rendszerek root területeihez. Bár ez biztonsági résnek tűnhet, valamiben azért meg kell bízni, s ameddig valaki nem csinál olyan butaságokat, hogy mindenféle szervert futtat egy adott gépen, összehozható egy biztonságos rendszer. Mikor 'biztonságos' rendszerről beszéltem, értettem ezalatt a fizikai hozzáférésmentességet is. Ha tehát adott egy biztosított gép, mely hozzáférhet más gépek root területeihez, hozzá lehet kezdeni biztonsági szkriptek írásának a BIZTOSÍTOTT gépen, melyek majd a többi gép integritását hivatottak ellenőrizni. A legelterjedtebb ellenőrzési módszer az scp(1) biztonsági szkript használata a find-on és az md5-ön, majd bejelentkezés ssh-n keresztül a távoli gépre, és az ott lévő fájlokat (de legalábbis a ./, a ./usr és a ./var partíciók fájljainak) ellenőrzése md5-tel. A biztonságos gép eltárolja az eredményeket és figyeli az esetleges eltéréseket a korábbi eredményekhez képest (diff), esetleg összehasonlítja azokat a saját binárisairól vett értékekel - s ezután e-mail-ben naponta közli az eredményeket a kijelölt személyekkel.

Egy másik módja a gépek közötti kapcsolat létrehozásának, ha a főbb fájlrendszereket NFS-el exportáljuk a biztonságos gépre. Ez persze intenzívebb hálózati forgalmat generál, de szinte kizárt, hogy a behatoló észrevegye vagy lehallgassa.

A jó biztonsági szkript az olyan fájlokban lévő változásokról is tudósít, mint a felhasználói vagy a személyzeti fiókokban lévő hozzáférésvezérlő fájlok, pl. az .rhosts, az .shosts, ./ssh/autorized_keys, stb. - mely fájlok esetleg kimaradhattak az md5 ellenőrzésből.

A jó biztonsági szkript ellenőrzi a suid/sgid programokat minden fájlrendszeren és jelzi egyrészt azok jelenlétét illetve változásait a korábbi ellenőrzéshez képest. Bár bizonyos fájlrendszereken letilthatjuk a suid és az sgid programok futtatását a 'nosuid' opcióval az fstab/mount -ban, nem tehetjük meg ezt magán a root fájlrendszeren, és bárki, aki ide betör, telepítheti saját binárisait. Ha nagy felhasználói lemezterülettel rendelkezünk, hasznos lehet ezen a területen letiltani a suid programok és eszközök ('nodev') használatát, így emiatt nem kell ezen területeket ellenőriznünk. Ettől függetlenül mégis érdemes lehet átfutni ezen területeket, hetente például, mivel ennek a biztonsági rétegnek a feladata éppen a behatolások felderítése.

A 'process accounting' (lásd accton(8)) az operációs rendszer egy meglehetősen erőforráskímélő eszköze, mely sikerrel alkalmazható a behatolás utáni visszaállító-elemző folyamatokban. Különösen hasznos lehet annak felderítésében, hogyan sikerült a behatolónak feltörnie a rendszert, feltéve ha a fájok érintetlenek maradtak a betörés óta.

És végül, a szkripteknek fel kell dolgozniuk a naplófájlokat (log) is, melyeket lehetőleg a legbiztonságosabb körülmények között generált a rendszer - a távoli syslog igen hasznos. A behatoló megpróbálja elfedni nyomait, s a naplófájlok kritikus eszközök a behatolás idejének és módjának felderítésében.

Paranoia

Egy kis paranoia sohasem árt. A rendszergazda akárhány biztonsági rendszert telepíthet míg az nem akadályozza a rendszer kényelmes használatát, illetve azon túl is egy kicsit, meghatározott célokkal.

Részletesebben a DoS támadásokról

Ez a fejezet a Denial of Service támadásokról szól. A tipikus DoS támadás adatcsomagocskákon alapuló támadási forma. Bár a modern hamisított adatcsomag (spoofed packet) támadásokkal szemben, melyek elszigetelik a hálózatot, nem sok mindent lehet tenni, lehetőség van mérsékelni a kárt azzal, ha elérjük, hogy szervereinket a támadások ne állíthassák le. Ennek érdekében:

1. Limitálhatjuk a szerverek forkolását
2. Korlátozhatjuk a hálózati támadások formáit (ICMP támadás, ping broadcast, stb...)
3. Megvédhetjük a kernel útválasztó cache-ét.

A hagyományos DoS támadás az önmagukat többször elindító (forking) szerverek ellen indul, s arra készteti a szervert, hogy fogyassza a processzeket, a fájlleírókat vagy a memóriát, míg a rendszer le nem áll. Az inetd(8)-nek több lehetősége is van az ilyen támadások kivédésére. Megjegyzendő, hogy bár lehetséges magát a gépen megvédeni a leállástól, általában ez nem sikerül az megtámadott szerverrel kapcsolatban. Az inetd manualjának a figyelmes elolvasása (különös tekintettel a -c, a -C és a -R kapcsolókra) kötelező. Bár a hamiscsomag támadások megkerülhetik a -C kapcsolót, a többi opcióval való együtthasználat sikeres lehet. Néhány önálló (standalone) szerver beépített fork-limitáló funkciókkal rendelkezik.

A sendmail -OMaxDaemonChildren kapcsolója jobban beválik, mint a terheléskorlátozó funkció. Ezt érdemes a sendmail indításakor elég magasra állítani ahhoz, hogy kezelni tudja az átmenő forgalmat, de ne olyan magasra, hogy maga a rendszer ne tudja kezelni a sok sendmail processzt. Biztosabb ha a sendmail-t queue módban futtatjuk (-ODeliveryMode=queued) és a daemont (sendmail -bd) külön futtatjuk a queue feldolgozástól (sendmail -q15m). Ha valaki valós idejű kézbesítést szeretne, kisebb időintervallumot is megadhat (-q1m), de mindenképpen egy ésszerű MaxDaemonChildren értéket kell beállítani, nehogy a sendmail kaszkádhibákat generáljon.

A syslogd szervert közvetlenül lehet támadni, s ezért erősen javasolt a -s opció használata ahol csak lehetséges, illetve a -a, egyéb esetekre.

Nagyon oda kell figyelni a 'connect-back' szerverekkel, mint pl. a tcp-wrapper reverse-identd funkciója, mely szintén közvetlenül támadható. Ezért a reverse-inetd használata erősen ellenjavalt.

Nagyon hatásos védelmi mód az, ha a belső szolgáltatások külső elérését valamilyen tűzfallal már a külső routereknél letiltjuk. Ennek a védelemnek a célja a kívülről jövő támadások megállítása, s nem a belső szolgáltatások védelme valamilyen hálózati alapú root-feltöréssel szemben. Kizáró jellegű tűzfalat konfiguráljunk: 'kizárni mindent kivéve az A, B, C, D valamint M és Z portokat'. Így minden alacsony portot lezárhatunk, kivéve persze azokat, melyeken olyan szolgáltatások futnak, melyeket elérhetőnek kell megtartani (named, sendmail, ntalkd, stb). Ha a tűzfalat megengedően állítjuk be, jó esélyünk lesz arra, hogy elfelejtünk levédeni pár fontos szervert, illetve elfelejtjük módosítani a szabályokat, ha új szolgáltatást telepítünk a rendszerre. Bármikor megnyithatjuk a magas portok egy részét is, ha megengedű típusú feladatok ezt igénylik anélkül, hogy veszélyeztetnénk a rendszer többi részét. Megjegyzendő, hogy a FreeBSD lehetőséget ad arra, hogy megadhassuk, dinamikus hozzárendeléskor (dynamic binding) mely portok kerülhessenek kiosztásra: a net.inet.ip.portrange kernelváltozók szolgálnak erre, melyek használatával a tűzfal szabályainak bonyolultsága is csökkenthető. A magam részéről a 4000/5000 első/utolsó értékeket, és a 49152/65535 magas port intervallumot használom, és blokkolok mindent 4000 alatt, kivéve persze néhány internetspecifikus portot.

A DoS támadások másik gyakori formái az ún. 'springboard' támadások - megtámadni egy szervert azért, hogy az válaszokat generáljon, melyek majd túlterhelik magát a szervert, a hálózatot vagy egy másik gépet. E támadások legjellemzőbb formája az ICMP PING BROADCAST. A támadó olyan hamis ping csomagokat küld a célpont LAN broadcast címére, melyek kiindulási címe annak a gépnek az IP címe, melyet támadni kíván. Ha a router nincs megfelelően konfigurálva arra, hogy blokkolja a broadcast címekre irányuló ping csomagokat, a LAN olyan mennyiségű válaszcsomaggal árasztja el a célgépet, hogy az lefullad a terhelés alatt, különösen ha a támadó ugyanezt a trükköt több tucat broadcast címmel játsza el, több tucat hálózaton egyszerre. Találkoztak már 120 megabitnyi adatot árasztó broadcast támadással is. A springboard támadások második leggyakoribb formája az ICMP hibajelentő rendszer elleni támadás. ICMP hibajelentések generáló csomagocskákkal bombázzák a szervert, mely így csak ezekre képes figyelni, felfüggesztve szabályszerű működését. Ez a támadás a szerver leállásához vezethet ha a szerver kifut az mbuf-jából, különösen ha nem tudja elég gyorsan lekezelni az általa generált ICMP válaszokat. A FreeBSD kernelhez van egy fordítási opció, az ICMP_BANDLIM, melyel csökkenthető az ilyen típusú támadások hatékonysága.

A springboard támadások utolsó nagy típusa az inetd bizonyos belső szolgáltatásaihoz kapcsolódik, mint pl. az 'UDP echo'. A támadó olyan csomagot hamisít, melyben a kiindulási cím a LAN egyik gépének echo portja, a célcím pedig a LAN másik gépének echo portja. A gépek ezután ezt a csomagot küldözgetik oda vissza egymás között. A támadó mindkét gépet és a hálózatot is túlterhelheti ilyen csomagok a rendszerbe juttatásával. Hasonló problémákat találtak az inetd belső, tesztcélokra használt chargen szolgáltatásával is. Egy hozzáértő rendszergazda ezért minden ilyen tesztszolgáltatást kikapcsol a rendszerben.

Hamisított csomagokkal a kernel útválasztó cache-e is túlterhelhető. Utalok itt a net.inet.ip.rtexpire, rtminexpire és a rtmaxcache sysctl paraméterekre. Minden hamis csomaghoz, melyek véletlenszerű kiindulási IP címeket használnak, a kernel egy időleges bejegyzést rendel az útvonal táblában, melyeket a 'netstat -rna | grep W3' parancsal nézhetünk meg. Ezek a bejegyzések általában 1600 másodperc múlva törlődnek. Ha a kernel érzékel, hogy a cache-elt útvonaltábla túl nagyra nőtt, automatikusan csökkenti a bejegyzések érvénytelenné válásának idejét, de sohasem csökkenti azt a rtminexpire érték alá. Két probléma merülhet fel: (1) a kernel nem tud elég gyorsan cselekedni, ha a terheletlen gépet hirtelen támadás éri, illetve (2) az rtminexpire nem elég alacsony ahhoz, hogy a kernel túléljen egy elhúzódó támadást. Ha a szerver T3-as (44,736 Mbit/s) vagy még annál is gyorsabb kapcsolattal rendelkezik az internet felé, mindenképpen érdemes mind az rtexpire, mind az rtminexpire értéket lecsökkenteni. Persze ne nullára (hacsak nem akarjuk, hogy a gép azonnal lefulladjon). Mindkét érték 2 másodpercre állítása elegendő védelmet ad az ilyen támadások kivédéséhez.