Date: Sat, 3 May 2008 11:32:52 GMT From: Gabor Pali <pgj@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 141086 for review Message-ID: <200805031132.m43BWqsb080396@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 @@ </chapterinfo> <title>Biztonság</title> + <indexterm><primary>biztonság</primary></indexterm> <sect1 id="security-synopsis"> <title>Áttekintés</title> - <para>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 - <quote>békés</quote> 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.</para> + <para>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 <quote>békés</quote> 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.</para> <para>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.</para> + sorát kínálja fel a rendszerünk + és hálózatunk + sértetlenségének és + biztonságának fenntartására.</para> <para>A fejezet elolvasása során megismerjük:</para> @@ -53,65 +55,66 @@ <itemizedlist> <listitem> <para>az alapvetõ rendszerbiztonsági fogalmakat, - különös tekintettel a &os;-re</para> + különös tekintettel a &os;-re;</para> </listitem> <listitem> <para>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 <acronym>DES</acronym> és az - <acronym>MD5</acronym></para> + <acronym>MD5</acronym>;</para> </listitem> <listitem> <para>hogyan állítsunk be egyszeri jelszavas - azonosítást</para> + azonosítást;</para> </listitem> <listitem> - <para>hogyan burkoljunk az <application>>inetd</application>> + <para>hogyan burkoljunk az <application>inetd</application> segítségével <acronym>TCP</acronym> - kapcsolatokat</para> + kapcsolatokat;</para> </listitem> <listitem> <para>hogyan állítsuk be a - <application>KerberosIV</application>-t a &os; 5.0-nál - korábbi változatain</para> + <application>KerberosIV</application>-t a + &os; 5.0-nál korábbi + változatain;</para> </listitem> <listitem> <para>hogyan állítsuk be a - <application>Kerberos5</application>-t a &os;-n</para> + <application>Kerberos5</application>-t a &os;-n;</para> </listitem> <listitem> <para>hogyan állítsuk be az IPsec-et és hozzunk létre <acronym>VPN</acronym>-t &os;/&windows; - gépek között</para> + gépek között;</para> </listitem> <listitem> <para>hogyan állítsuk be és használjuk az <application>OpenSSH</application>-t, a &os; <acronym>SSH</acronym> - implementációját</para> + implementációját;</para> </listitem> <listitem> <para>mik azok az <acronym>ACL</acronym>-ek az állományrendszerben és miként kell - õket használni</para> + ezeket használni;</para> </listitem> <listitem> <para>hogyan kell használni a <application>Portaudit</application> segédprogramot a Portgyûjteménybõl telepített - külsõs szoftvercsomagok + külsõ szoftvercsomagok biztonságosságának - ellenõrzésére</para> + ellenõrzésére;</para> </listitem> <listitem> @@ -123,7 +126,7 @@ <listitem> <para>mit jelent a futó programok nyilvántartása és hogyan - engedélyezzük azt &os;-n</para> + engedélyezzük azt &os;-n.</para> </listitem> </itemizedlist> @@ -132,7 +135,7 @@ <itemizedlist> <listitem> <para>az alapvetõ &os; és internetes fogalmak - ismerete</para> + ismerete.</para> </listitem> </itemizedlist> @@ -140,7 +143,7 @@ témákról is szó esik, például a <xref linkend="mac">ben a Kötelezõ - hozzáférésvezérlésrõl + hozzáférés-vezérlésrõl (MAC) és a <xref linkend="firewalls">ben pedig az internetes tûzfalakról.</para> @@ -157,26 +160,26 @@ felhasználók <quote>fegyelmezéséhez</quote> 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.</para> @@ -196,13 +199,12 @@ <listitem> <para>A szolgáltatások mûködésképtelenné - tételére irányuló (DoS) - támadások.</para> + tételére irányuló (DoS, Denial of + Service) támadások.</para> </listitem> <listitem> - <para>A felhasználók - hozzáférésének + <para>A felhasználói fiókok veszélyeztetése.</para> </listitem> @@ -213,7 +215,7 @@ <listitem> <para>Rendszergazdai jogok megszerzése a - felhasználói hozzáféréseken + felhasználói fiókokon keresztül.</para> </listitem> @@ -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.</para> <indexterm> @@ -274,21 +276,19 @@ </indexterm> <para>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 <application>telnetd</application>, + elõfordul, hogy feltörik a felhasználók + fiókjait. A rendszergazdák többsége + még mindig futtat <application>telnetd</application>, <application>rlogin</application>, <application>rshd</application> és <application>ftpd</application> 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.</para> <indexterm> @@ -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 <username>root</username> - 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 + <username>root</username> 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 @@ <listitem> <para>A rendszergazdai jogokkal futó szerverek és - suid/sgid engedélyekkel rendelkezõ programok + a suid/sgid engedélyekkel rendelkezõ programok védelme.</para> </listitem> @@ -389,8 +389,8 @@ <listitem> <para>A rendszermag belsejének, a nyers - eszközök és az állományrendszerek - védelme.</para> + eszközök és az + állományrendszerek védelme.</para> </listitem> <listitem> @@ -406,12 +406,13 @@ <para>A fejezet most következõ szakaszában az imént felsorolt elemeket fejtjük ki - mélyebben.</para> + részletesebben.</para> </sect1> <sect1 id="securing-freebsd"> <title>A &os; védelme</title> + <indexterm> <primary>biztonság</primary> <secondary>a &os; védelme</secondary> @@ -440,15 +441,14 @@ <sect2 id="securing-root-and-staff"> <title>A rendszergazda és a személyzet - hozzáférésének védelme</title> - <indexterm> - <primary><command>su</command></primary> - </indexterm> + hozzáférésének + védelme</title> + + <indexterm><primary><command>su</command></primary></indexterm> <para>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 <username>root</username> @@ -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 <filename>/etc/ttys</filename> - állományban megadott - pszeudóterminálokat <quote>insecure</quote> (nem + állományban megadott pszeudó + terminálokat <quote>insecure</quote> (nem biztonságos) típusúnak állítottuk be, és így a - <command>telnet</command> vagy <command>rlogin</command> + <command>telnet</command> vagy az <command>rlogin</command> parancsokon keresztül nem lehet rendszergazdaként bejelentkezni. Ha más szolgáltatáson keresztül jelentkezünk be, például az <application>sshd</application> 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 <filename>/etc/ssh/sshd_config</filename> állományt és a - <literal>PermitRootLogin</literal> paraméter - értékét átállítjuk - <literal>NO</literal>-ra. Vegyünk számba minden + <literal>PermitRootLogin</literal> paramétert + átállítjuk a <literal>NO</literal> + é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 <command>su</command> paranccsal fel tudjuk venni a <username>root</username> felhasználó jogait. A személyzet tagjait - közvetlenül sose vegyük fel a - <groupname>wheel</groupname> 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 <groupname>wheel</groupname> csoportba! A + személyzet tagjai elõször kerüljenek egy <groupname>staff</groupname> csoportba, és majd csak ezután az <filename>/etc/group</filename> állományon keresztül a @@ -521,18 +520,19 @@ <groupname>wheel</groupname> csoportba, akiknek valóban szükségük van a <username>root</username> felhasználó - hozzáférésére. Ha mondjuk a - Kerberost használjuk hitelesítésre, akkor - megcsinálhatjuk azt is, hogy a Kerberos - <filename>.k5login</filename> állományában - engedélyezzük a &man.ksu.1; parancson keresztül - a <username>root</username> hozzáférés - elérését a <groupname>wheel</groupname> - csoport alkalmazása nélkül. Ez a - megoldás talán még jobb is, mivel a - <groupname>wheel</groupname> használata esetén a - behatolónak még mindig lehetõsége van - hozzájutni a <username>root</username> + hozzáférésére. Ha + például a Kerberost használjuk + hitelesítésre, akkor megcsinálhatjuk azt + is, hogy a Kerberos <filename>.k5login</filename> + állományában engedélyezzük a + &man.ksu.1; parancson keresztül a <username>root</username> + hozzáférés elérését a + <groupname>wheel</groupname> csoport alkalmazása + nélkül. Ez a megoldás talán + még jobb is, mivel a <groupname>wheel</groupname> + használata esetén a behatolónak még + mindig lehetõsége van hozzájutni a + <username>root</username> 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 <groupname>wheel</groupname> 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.</para> <para>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:</para> - <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting> + <programlisting>izemize:R9DT/Fa1/LV9U:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh</programlisting> - <para>Amit tehát erre cserélünk ki:</para> + <para>Erre cseréljük ki:</para> - <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting> + <programlisting>izemize:*:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh</programlisting> - <para>Ezzel megakadályozzuk, hogy a - <username>foobar</username> nevû felhasználó a - hagyományos módszerekkel be tudjon jelentkezni. + <para>Ezzel megakadályozzuk, hogy az + <username>izemize</username> nevû felhasználó + a hagyományos módszerekkel be tudjon jelentkezni. Ez a megoldás azonban a <application>Kerberos</application>t 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.</para> + (például egy hónap) után + változtasson jelszót.</para> + </sect2> <sect2> @@ -635,30 +636,14 @@ SUID/SGID engedélyekkel rendelkezõ programok védelme</title> - <indexterm> - <primary><command>ntalk</command></primary> - </indexterm> - <indexterm> - <primary><command>comsat</command></primary> - </indexterm> - <indexterm> - <primary><command>finger</command></primary> - </indexterm> - <indexterm> - <primary>sandboxes</primary> - </indexterm> - <indexterm> - <primary><application>sshd</application></primary> - </indexterm> - <indexterm> - <primary><application>telnetd</application></primary> - </indexterm> - <indexterm> - <primary><application>rshd</application></primary> - </indexterm> - <indexterm> - <primary><application>rlogind</application></primary> - </indexterm> + <indexterm><primary><command>ntalk</command></primary></indexterm> + <indexterm><primary><command>comsat</command></primary></indexterm> + <indexterm><primary><command>finger</command></primary></indexterm> + <indexterm><primary>járókák</primary></indexterm> + <indexterm><primary><application>sshd</application></primary></indexterm> + <indexterm><primary><application>telnetd</application></primary></indexterm> + <indexterm><primary><application>rshd</application></primary></indexterm> + <indexterm><primary><application>rlogind</application></primary></indexterm> <para>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 <username>root</username> 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 <username>root</username> felhasználóként futtatni. Például az <application>ntalk</application>, <application>comsat</application> és <application>finger</application> démonok egy speciális - <firstterm>járókában</firstterm> futnak. - Ezek a járókák sem teljesen + <firstterm>járókában</firstterm> (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 <application>sshd</application>-n - keresztül tudnak belépni és soha nem - használja senki a <application>telnetd</application>, + gépünkre csak az <application>sshd</application> + szolgáltatáson keresztül tudnak + belépni, és soha nem használja senki a + <application>telnetd</application>, <application>rshd</application> vagy <application>rlogind</application> szolgáltatásokat, akkor kapcsoljuk is ki - õket!</para> + ezeket!</para> <para>A &os; most már alapértelmezés szerint járókában futtatja az <application>ntalkd</application>, <application>comsat</application> és <application>finger</application> - szolgáltatásokat. Másik ilyen program, ami - szintén esélyes lehet erre, az a &man.named.8;. - Az <filename>/etc/defaults/rc.conf</filename> + szolgáltatásokat. Másik ilyen program, + amely szintén esélyes lehet erre, az a + &man.named.8;. Az <filename>/etc/defaults/rc.conf</filename> megjegyzésben tartalmazza a <application>named</application> 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.</para> - <indexterm> - <primary><application>sendmail</application></primary> - </indexterm> + <indexterm><primary><application>sendmail</application></primary></indexterm> - <para>Vannak más olyan szerverek, amik tipikusan nem + <para>Vannak más olyan szerverek, amelyek tipikusan nem járókákban futnak. Ilyen többek közt a <application>sendmail</application>, <application>popper</application>, @@ -748,14 +732,14 @@ támaszkodva kell észlelnünk.</para> <para>A <username>root</username> 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 - <application>rlogin</application>, a <filename>/bin</filename> - és <filename>/sbin</filename>, + binárisok többsége, mint + például az <application>rlogin</application>, a + <filename>/bin</filename> és <filename>/sbin</filename>, <filename>/usr/bin</filename> vagy <filename>/usr/sbin</filename> 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 - <username>root</username> lyukakat az ilyen binárisokban + Alkalmanként azonban találnak a + <username>root</username> felhasználót + veszélyeztetõ lyukakat az ilyen binárisokban is. Például 1998-ban az <literal>Xlib</literal>-ben volt egy olyan rendszergazdai - szintû hiba, amivel az <application>xterm</application> - (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 - (<command>chmod 000</command>). A monitorral nem + szintû hiba, amellyel az <application>xterm</application> + (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 (<command>chmod 000</command>). A monitorral nem rendelkezõ szervereknek általában nincs szükségük az <application>xterm</application> 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 <filename>/dev/kmem</filename> állomány + behatoló képes feltörni egy + <groupname>kmem</groupname> csoporthoz tartozó sgid + binárist, akkor képes lesz olvasni a + <filename>/dev/kmem</filename> á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 <groupname>kmem</groupname> 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 - <groupname>tty</groupname> 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 <groupname>tty</groupname> 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 @@ <para>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 <link linkend="security-integrity">Az + folyamatosan tudnia kell figyelnie és jelentie + (lásd lentebb a <link linkend="security-integrity">Az állományok sértetlenségének ellenõrzése</link> címû fejezetet).</para> @@ -892,9 +876,7 @@ rendszermagba a <devicename>bpf</devicename> eszközt.</para> - <indexterm> - <primary><command>sysctl</command></primary> - </indexterm> + <indexterm><primary><command>sysctl</command></primary></indexterm> <para>De ha még ki is iktatjuk a <devicename>bpf</devicename> 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 <devicename>bpf</devicename> - 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 + <devicename>bpf</devicename> 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 <command>sysctl</command> parancson keresztül a <varname>kern.securelevel</varname> 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 <literal>schg</literal> 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.</para> + összeszedését is.</para> </sect2> @@ -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 <command>chflags</command> paranccsal beállítjuk az <literal>schg</literal> állományjelzõt a <filename>/</filename> és <filename>/usr</filename> @@ -1020,17 +1003,17 @@ által hagyott nyomokkal együtt is.</para> <para>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 <filename>/etc</filename> és <filename>/usr/local/etc</filename> 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 <filename>/</filename> és a <filename>/usr</filename> partíciókon.</para> <para>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 - <command>scp</command> paranccsal lényegében - át kell másolni a kliensekre, amivel így - láthatóvá válnak. Ne feledjük - továbbá, hogy az <application>ssh</application> - kliens már eleve feltört lehet. Szó, ami - szó, ha nem megbízható + használt eszközöket (például + find) az <command>scp</command> paranccsal + lényegében át kell másolni a + kliensekre, amivel így láthatóvá + válnak. Ne feledjük továbbá, hogy az + <application>ssh</application> 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û.</para> <para>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 - <filename>.rhosts</filename>, <filename>.shosts</filename>, + felhasználók és a személyzet + tagjainak hozzáférését + vezérlõ állományokban, mint + például az <filename>.rhosts</filename>, + <filename>.shosts</filename>, <filename>.ssh/authorized_keys</filename> és társaiban keletkezett változásokat is, amelyek esetleg elkerülhetik egy <literal>MD5</literal> alapú ellenõrzés figyelmét.</para> <para>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.</para> - <para>A futó programok nyilvántartása (ld. - &man.accton.8;) egy olyan viszonylag kevés + <para>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.</para> - <para>Végül a védelmi szkripteknek javasolt - feldolgozni a naplóállományokat is, valamint - a naplókat magukat is a lehetõ + <para>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 @@ </orderedlist> <para>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 <application>inetd</application> - (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 @@ <application>Sendmail</application> indításakor tehát a <literal>MaxDaemonChildren</literal> paramétert javasolt megadni egy olyan - értékkel, ami elegendõ a + értékkel, amely elegendõ a <application>Sendmail</application> 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. <option>-q1m</option>) de arra - <emphasis>mindig ügyeljünk</emphasis>, hogy a + lefuttathatjuk (például <option>-q1m</option>), de + arra <emphasis>mindig ügyeljünk</emphasis>, hogy a <literal>MaxDaemonChildren</literal> beállítása ne okozzon kaszkádosítási hibákat a @@ -1285,9 +1272,9 @@ <emphasis>kivéve</emphasis> az A, B, C, D és M-Z portokat</quote>. Ezen a módon ki tudjuk szûrni az összes alacsonyabb portot, kivéve bizonyos eseteket, - mint mondjuk a <application>named</application> (ha az adott - zónában ez az elsõdleges gép), - <application>ntalkd</application>, + mint például a <application>named</application> + (ha az adott zónában ez az elsõdleges + gép), <application>ntalkd</application>, <application>sendmail</application> 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).</para> >>> TRUNCATED FOR MAIL (1000 lines) <<<
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200805031132.m43BWqsb080396>