PERFORCE change 141086 for review
Gabor Pali
pgj at FreeBSD.org
Sat May 3 11:32:53 UTC 2008
http://perforce.freebsd.org/chv.cgi?CH=141086
Change 141086 by pgj at 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) <<<
More information about the p4-projects
mailing list