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.
