From owner-p4-projects@FreeBSD.ORG Sat May 3 11:32:53 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id DD0431065675; Sat, 3 May 2008 11:32:52 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DBCB106564A for ; Sat, 3 May 2008 11:32:52 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 9D1658FC1E for ; Sat, 3 May 2008 11:32:52 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.1/8.14.1) with ESMTP id m43BWqQ5080398 for ; Sat, 3 May 2008 11:32:52 GMT (envelope-from pgj@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.1/8.14.1/Submit) id m43BWqsb080396 for perforce@freebsd.org; Sat, 3 May 2008 11:32:52 GMT (envelope-from pgj@FreeBSD.org) Date: Sat, 3 May 2008 11:32:52 GMT Message-Id: <200805031132.m43BWqsb080396@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to pgj@FreeBSD.org using -f From: Gabor Pali To: Perforce Change Reviews Cc: Subject: PERFORCE change 141086 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2008 11:32:53 -0000 http://perforce.freebsd.org/chv.cgi?CH=141086 Change 141086 by pgj@disznohal on 2008/05/03 11:31:54 Cleanup in Chapter 14. Affected files ... .. //depot/projects/docproj_hu/books/handbook/security/chapter.sgml#6 edit Differences ... ==== //depot/projects/docproj_hu/books/handbook/security/chapter.sgml#6 (text+ko) ==== @@ -21,31 +21,33 @@ Biztonság + biztonság Áttekintés - Ez a fejezet egy alapvetõ bevezetést ad a - rendszerek biztonsági fogalmaiba, néhány - általános jótanácsot és - néhány komolyabb témát &os; alatt. Az - itt megfogalmazott témák nagy része - egyaránt ráhúzható rendszerünk - és általánosságban véve az - internetes biztonságra is. A internet már nem az - békés hely, ahol mindenki a kedves - szomszéd szerepét játssza. A - rendszerünk bebiztosítása elkerülhetetlen - az adataink, szellemi tulajdonunk, idõnk és még - sok minden más megvédésére az - internetes banditák és hasonlók ellen. + Ez a fejezet egy alapvetõ bevezetés a rendszerek + biztonsági fogalmaiba, ad néhány + általános jótanácsot és a + &os;-vel kapcsolatban feldolgoz néhány komolyabb + témát. Az itt megfogalmazott témák + nagy része egyaránt ráhúzható + rendszerünk és általánosságban + véve az internet biztonságára is. A internet + már nem az békés hely, ahol + mindenki a kedves szomszéd szerepét játssza. + A rendszerünk bebiztosítása + elkerülhetetlen az adataink, szellemi tulajdonunk, idõnk + és még sok minden más + megvédésére az internetes banditák + és hasonlók ellen. A &os; segédprogramok és mechanizmusok - sorát kínálja fel a rendszerünk és - hálózatunk sértetlenségének - és biztonságának - fenntartására. + sorát kínálja fel a rendszerünk + és hálózatunk + sértetlenségének és + biztonságának fenntartására. A fejezet elolvasása során megismerjük: @@ -53,65 +55,66 @@ az alapvetõ rendszerbiztonsági fogalmakat, - különös tekintettel a &os;-re + különös tekintettel a &os;-re; milyen olyan különbözõ - titkosítási mechanizmusok érthetõek el - a &os;-ben, mint például a + titkosítási mechanizmusok érthetõek + el a &os;-ben, mint például a DES és az - MD5 + MD5; hogyan állítsunk be egyszeri jelszavas - azonosítást + azonosítást; - hogyan burkoljunk az >inetd> + hogyan burkoljunk az inetd segítségével TCP - kapcsolatokat + kapcsolatokat; hogyan állítsuk be a - KerberosIV-t a &os; 5.0-nál - korábbi változatain + KerberosIV-t a + &os; 5.0-nál korábbi + változatain; hogyan állítsuk be a - Kerberos5-t a &os;-n + Kerberos5-t a &os;-n; hogyan állítsuk be az IPsec-et és hozzunk létre VPN-t &os;/&windows; - gépek között + gépek között; hogyan állítsuk be és használjuk az OpenSSH-t, a &os; SSH - implementációját + implementációját; mik azok az ACL-ek az állományrendszerben és miként kell - õket használni + ezeket használni; hogyan kell használni a Portaudit segédprogramot a Portgyûjteménybõl telepített - külsõs szoftvercsomagok + külsõ szoftvercsomagok biztonságosságának - ellenõrzésére + ellenõrzésére; @@ -123,7 +126,7 @@ mit jelent a futó programok nyilvántartása és hogyan - engedélyezzük azt &os;-n + engedélyezzük azt &os;-n. @@ -132,7 +135,7 @@ az alapvetõ &os; és internetes fogalmak - ismerete + ismerete. @@ -140,7 +143,7 @@ témákról is szó esik, például a ben a Kötelezõ - hozzáférésvezérlésrõl + hozzáférés-vezérlésrõl (MAC) és a ben pedig az internetes tûzfalakról. @@ -157,26 +160,26 @@ felhasználók fegyelmezéséhez szükség további biztonsági mechanizmusok - kiépítése és karbantartása - minden bizonnyal egy rendszergazda egyik legnagyobb - kötelessége. A + kiépítésére és + karbantartására, ami minden bizonnyal egy + rendszergazda egyik legfontosabb kötelessége. A számítógépek csak annyira - biztonságosak, mint amennyire beállítjuk - õket, és a biztonsági megfontolások + biztonságosak, mint amennyire beállítjuk, + és a biztonsági megfontolások állandó versenyben vannak az emberi kényelemmel. A &unix; rendszerek általánosságban véve órási mennyiségû program párhuzamos futtatására képesek, melyek többsége kiszolgálóként fut - — ami azt jelenti, hogy hozzájuk + — ez azt jelenti, hogy hozzájuk kívülrõl érkezõ egyedek csatlakozhatnak és társaloghatnak velük. Ahogy a tegnap kicsi és nagy számítógépei napjaink asztali gépeivé váltak és ahogy a számítógépek egyre többen - csatlakoznak hálózatra és internetre, a + csatlakoznak hálózatra és az internetre, a biztonság fontossága is egyre jobban növekszik. @@ -196,13 +199,12 @@ A szolgáltatások mûködésképtelenné - tételére irányuló (DoS) - támadások. + tételére irányuló (DoS, Denial of + Service) támadások. - A felhasználók - hozzáférésének + A felhasználói fiókok veszélyeztetése. @@ -213,7 +215,7 @@ Rendszergazdai jogok megszerzése a - felhasználói hozzáféréseken + felhasználói fiókokon keresztül. @@ -256,15 +258,15 @@ gyakran ki lehet védeni a paramétereik ügyes beállításával, melyek segítségével korlátozni tudjuk az - õket ért terhelést egy kellemetlenebb - helyezetben. A nyers erõt alkalmazó - hálózati támadásokkal a legnehezebb - szembenézni. Például az - álcázott támadadások, melyeket szinte - lehetetlen megállítani, remek eszközei - gépünk elvágásának az - internettõl. Ezzel nem csak a gépünket - iktatják ki, hanem az internet csatlakozásunkat is + ezeket ért terhelést egy kellemetlenebb helyezetben. + A nyers erõt alkalmazó hálózati + támadásokkal a legnehezebb szembenézni. + Például az álcázott + támadadások, melyeket szinte lehetetlen + megállítani, remek eszközök arra, hogy + elvágják gépünket az internettõl. + Ezzel viszont nem csak azt iktatják ki, hanem az + internet-csatlakozásunkat is eldugítják. @@ -274,21 +276,19 @@ A DoS támadásoknál még gyakrabban - elõfordulnak a felhasználói - hozzáférések feltörései. A - rendszergazdák többsége még mindig - futtat telnetd, + elõfordul, hogy feltörik a felhasználók + fiókjait. A rendszergazdák többsége + még mindig futtat telnetd, rlogin, rshd és ftpd szervereket a - gépén. Ezek a szerverek - alapértelmezés szerint nem titkosított - kapcsolaton keresztül mûködnek. Ebbõl - következik, hogy ha nincsen annyira sok - felhasználónk és közülük - néhányan távoli helyekrõl jelentkeznek - be (ami az egyik leggyakoribb és legkényelmesebb - módja a bejelentkezésnek), akkor elõfordulhat, - hogy valami megneszeli a jelszavaikat. A + gépen. Ezek a szerverek alapértelmezés + szerint nem titkosított kapcsolaton keresztül + mûködnek. Ebbõl következik, hogy ha nincs + annyira sok felhasználónk és + közülük néhányan távoli + helyekrõl jelentkeznek be (ami az egyik leggyakoribb + és legkényelmesebb módja ennek), akkor + elõfordulhat, hogy valami megneszeli a jelszavaikat. A körültekintõ rendszergazdák mindig ellenõrzik a bejelentkezéseket tartalmazó naplókat és igyekeznek kiszûrni a gyanús @@ -313,9 +313,9 @@ elrejteni a nyomait és legjobb esetben sem tud többet tenni, mint tönkretenni az adott felhasználó állományait vagy összeomlasztani a rendszert. - A felhasználói hozzáférések - feltörése nagyon gyakran megtörténik, - mivel a felhasználók messze nem annyira + A felhasználói fiókok feltörése + nagyon gyakran megtörténik, mivel a + felhasználók messze nem annyira elõvigyázatosak, mint egy rendszergazda. @@ -341,18 +341,18 @@ keresztül. Miután a támadó megtalálta a rendszergazdai jogok megszerzésének módját, nem - feltétlenül kell kiskapukat elhelyeznie a rendszerbe. - Az eddig talált és lezárt rendszergazdai - jogokat eredményezõ biztonsági rések egy - része viszont akkora mennyiségû munkát - jelentenének a támadónak eltüntetni maga - után a nyomokat, hogy kiskapukat is telepítenek. - Egy ilyen kiskapu segítségével a - támadó ismét könnyedén - hozzájuthat a root - felhasználó + feltétlenül kell kiskapukat elhelyeznie a rendszerben. + Az eddig talált és javított, rendszergazdai + jogok megszerzését lehetõvé tevõ + biztonsági rések egy része esetében + viszont a támadónak akkora mennyiségû + munkát jelentene eltûntetni maga után a + nyomokat, hogy megéri neki egy kiskaput telepíteni. + Ennek segítségével a támadó + ismét könnyedén hozzájuthat a + root felhasználó hozzáféréséhez a rendszerben, de ezen - keresztül egy okos rendszergazda képes a + keresztül egy okos rendszergazda képes is a behatolót leleplezni. A kiskapuk lerakásának megakadályozása valójában káros a biztonság szempontjából nézve, mert @@ -373,7 +373,7 @@ A rendszergazdai jogokkal futó szerverek és - suid/sgid engedélyekkel rendelkezõ programok + a suid/sgid engedélyekkel rendelkezõ programok védelme. @@ -389,8 +389,8 @@ A rendszermag belsejének, a nyers - eszközök és az állományrendszerek - védelme. + eszközök és az + állományrendszerek védelme. @@ -406,12 +406,13 @@ A fejezet most következõ szakaszában az imént felsorolt elemeket fejtjük ki - mélyebben. + részletesebben. A &os; védelme + biztonság a &os; védelme @@ -440,15 +441,14 @@ A rendszergazda és a személyzet - hozzáférésének védelme - - su - + hozzáférésének + védelme + + su Elõször is: ne törjük magunkat a - személyzeti hozzáférések - biztonságossá tételével, ha - még a rendszergazda + 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 @@ -459,30 +459,30 @@ 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 akar + 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 &man.su.1; paranccsal sem. Például gondoskodjunk róla, hogy az /etc/ttys - állományban megadott - pszeudóterminálokat insecure (nem + állományban megadott pszeudó + terminálokat insecure (nem biztonságos) típusúnak állítottuk be, és így a - telnet vagy rlogin + 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 itt is letiltottuk a - közvetlen rendszergazdai bejelentkezés + 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éter - értékét átállítjuk - NO-ra. Vegyünk számba minden + 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 @@ -509,10 +509,9 @@ csoportba rakjuk, akkor innen a su paranccsal fel tudjuk venni a root felhasználó jogait. A személyzet tagjait - közvetlenül sose vegyük fel a - wheel csoportba a - létrehozásukkor! A személyzet tagjai - elõször kerüljenek egy + 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 @@ -521,18 +520,19 @@ wheel csoportba, akiknek valóban szükségük van a root felhasználó - hozzáférésére. Ha mondjuk a - Kerberost használjuk hitelesítésre, akkor - megcsinálhatjuk azt is, hogy a Kerberos - .k5login állományában - engedélyezzük a &man.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é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 + &man.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 @@ -540,7 +540,7 @@ 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 + semmi, de kétségtelenül nem a legbiztonságosabb. A hozzáférések teljes körû @@ -564,15 +564,15 @@ képes bejelentkezni. Ahogy például a személyzet alábbi tagja sem: - foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + izemize:R9DT/Fa1/LV9U:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh - Amit tehát erre cserélünk ki: + Erre cseréljük ki: - foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + izemize:*:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh - Ezzel megakadályozzuk, hogy a - foobar nevû felhasználó a - hagyományos módszerekkel be tudjon jelentkezni. + 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 @@ -584,7 +584,7 @@ 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 + 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 @@ -626,8 +626,9 @@ 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õ - (mondjuk egy hónap) után változtasson - jelszót. + (például egy hónap) után + változtasson jelszót. + @@ -635,30 +636,14 @@ SUID/SGID engedélyekkel rendelkezõ programok védelme - - ntalk - - - comsat - - - finger - - - sandboxes - - - sshd - - - telnetd - - - rshd - - - rlogind - + ntalk + comsat + finger + járókák + sshd + telnetd + rshd + rlogind A bölcs rendszergazda mindig csak akkor futtat szervereket, amikor szüksége van rá, se @@ -671,16 +656,16 @@ mintha az egész világnak ingyenjegyet osztogatnánk a rendszerünk root hozzáféréséhez. Soha ne futtassunk - olyan szervert, amit nem vizsgáltunk át kellõ - alapossággal. Sok szervert nem is + 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 futnak. - Ezek a járókák sem teljesen + 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 @@ -695,22 +680,23 @@ szerverben, beleértve az alapvetõ rendszerszintû szervereket is, találtak már biztonsági jellegû hibát. Ha a - gépünkre csak sshd-n - keresztül tudnak belépni és soha nem - használja senki a telnetd, + 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 - õket! + ezeket! A &os; most már alapértelmezés szerint járókában futtatja az ntalkd, comsat és finger - szolgáltatásokat. Másik ilyen program, ami - szintén esélyes lehet erre, az a &man.named.8;. - Az /etc/defaults/rc.conf + szolgáltatásokat. Másik ilyen program, + amely szintén esélyes lehet erre, az a + &man.named.8;. Az /etc/defaults/rc.conf megjegyzésben tartalmazza a named járókában futtatásához szükséges @@ -725,11 +711,9 @@ kikísérletez és létrehoz ilyen járókákat. - - sendmail - + sendmail - Vannak más olyan szerverek, amik tipikusan nem + Vannak más olyan szerverek, amelyek tipikusan nem járókákban futnak. Ilyen többek közt a sendmail, popper, @@ -748,14 +732,14 @@ támaszkodva kell észlelnünk. A root felhasználó - keltette biztonsági rések másik nagyon + 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 mondjuk az - rlogin, a /bin - és /sbin, + 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 @@ -763,45 +747,45 @@ alapértelmezetten suid és sgid engedéllyel rendelkezõ binárisok ebbõl a szempontból meglehetõsen megbízhatónak tekinhetõek. - Azonban alkalmanként találnak - root lyukakat az ilyen binárisokban + 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, amivel az xterm - (ami á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, amihez csak a - személyzet tagjai férhetnek hozzá. Az - olyan suid binárisoktól pedig, akiket senki sem - használni, igyekszik teljesen megszabadulni - (chmod 000). A monitorral nem + 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 - csoportú sgid binárist, akkor képes lesz - olvasni a /dev/kmem állomány + 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 + 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 @@ -862,8 +846,8 @@ A rendszerünkben futó biztonsági szkripteknek a jelszavakat tároló állomány változását - folyamatosan tudnia kell figyelnie és jelentie (ld. - lentebb a Az + folyamatosan tudnia kell figyelnie és jelentie + (lásd lentebb a Az állományok sértetlenségének ellenõrzése címû fejezetet). @@ -892,9 +876,7 @@ rendszermagba a bpf eszközt. - - sysctl - + sysctl De ha még ki is iktatjuk a bpf eszközt, még @@ -904,15 +886,16 @@ képes írni a nyers eszközökre. Sõt, a rendszermagba képesek vagyunk modulokat is betölteni a &man.kldload.8; használatával. A - vállalkozó kedvû támadó - kernelmodulké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 a - rendszermagban. Az ilyen problémák - elkerülése érdekében a rendszermagot a - legmagasabb védelmi szinten kell üzemeltetni, - tehát legalább 1-esen. A védelmi szint + 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 1-esen. A védelmi szint szabályozása a sysctl parancson keresztül a kern.securelevel változó értékének @@ -920,7 +903,7 @@ Ahogy a védelmi szintet 1-re állítottuk, a nyers eszközök írása azonnal letiltódik és az olyan speciális - állományjelzõk, mint mondjuk a + állományjelzõk, mint például az schg hatása mûködésbe lép. Gondoskodnunk kell róla, hogy a rendszer indítása szempontjából fontos @@ -944,7 +927,7 @@ védekezés egyben megakadályozza a betörések felderítéséhez szükséges összes információ - felderítését is. + összeszedését is. @@ -958,8 +941,8 @@ rendszerszintû konfigurációs- és vezérlõállományokat tudjuk megvédeni, még mielõtt a korábban - emlgetett kényelmi tényezõ kimutatná a - foga fehérjét. Például, ha a + 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 @@ -1020,17 +1003,17 @@ á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 + 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 mondjuk a &man.find.1; és &man.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 + mint például a &man.find.1; és &man.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 @@ -1040,39 +1023,41 @@ 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 + 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 (pl. 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ó + 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 a - .rhosts, .shosts, + 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 + 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 @@ -1088,8 +1073,8 @@ foglalkozik, függetlenül a sikerességüktõl. - A futó programok nyilvántartása (ld. - &man.accton.8;) egy olyan viszonylag kevés + A futó programok nyilvántartása + (lásd &man.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 @@ -1103,17 +1088,18 @@ betörés után is érintetlenek maradtak. - Végül a védelmi szkripteknek javasolt - feldolgozni a naplóállományokat is, valamint - a naplókat magukat is a lehetõ + 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 - — egy távoli gépre történõ - naplózás ilyenkor nagyon hasznos lehet. 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 + — 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 @@ -1188,16 +1174,17 @@ A DoS támadások egyik jellemzõ - sémája szerint egy sokszorozódni képes - szervert támadnak meg, aminek 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, + 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 - (ld. &man.inetd.8;) számos lehetõséget - kínál fel ennek + (lásd &man.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 @@ -1229,7 +1216,7 @@ Sendmail indításakor tehát a MaxDaemonChildren paramétert javasolt megadni egy olyan - értékkel, ami elegendõ a + értékkel, amely elegendõ a Sendmail számára betervezett terhelés kiszolgálására, de még kevés ahhoz, hogy a @@ -1243,8 +1230,8 @@ továbbra is valós idejû kézbesítést akarunk, akkor a feldolgozást kisebb idõközökkel is - lefuttathatjuk (pl. ) de arra - mindig ügyeljünk, hogy a + lefuttathatjuk (például ), de + arra mindig ügyeljünk, hogy a MaxDaemonChildren beállítása ne okozzon kaszkádosítási hibákat a @@ -1285,9 +1272,9 @@ 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 mondjuk a named (ha az adott - zónában ez az elsõdleges gép), - ntalkd, + 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 @@ -1300,7 +1287,7 @@ 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 - engedjük meg ezt a megengedõ jellegû + 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 &os;-ben a @@ -1315,8 +1302,8 @@ 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ékozasan hozzáférhetõ - portok kivételével). >>> TRUNCATED FOR MAIL (1000 lines) <<<