PERFORCE change 134491 for review
Gabor Pali
pgj at FreeBSD.org
Wed Jan 30 14:40:24 PST 2008
http://perforce.freebsd.org/chv.cgi?CH=134491
Change 134491 by pgj at disznohal on 2008/01/30 22:39:35
Add initial Hungarian translation of Chapter 14: Security.
Affected files ...
.. //depot/projects/docproj_hu/books/handbook/security/chapter.sgml#4 edit
Differences ...
==== //depot/projects/docproj_hu/books/handbook/security/chapter.sgml#4 (text+ko) ====
@@ -4,962 +4,1525 @@
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.316 2007/10/23 07:03:34 dougb Exp $
-->
-<chapter id="security">
+<!-- The FreeBSD Hungarian Documentation Project
+ Translated by: PALI, Gabor <pgj at FreeBSD.org>
+ Original Revision: 1.316 -->
+
+<chapter id="security" lang="hu">
<chapterinfo>
<authorgroup>
<author>
<firstname>Matthew</firstname>
<surname>Dillon</surname>
- <contrib>Much of this chapter has been taken from the
- security(7) manual page by </contrib>
+ <contrib>A fejezet legnagyobb részét a security(7)
+ man oldal alapján írta: </contrib>
</author>
</authorgroup>
</chapterinfo>
- <title>Security</title>
- <indexterm><primary>security</primary></indexterm>
+ <title>Biztonság</title>
+ <indexterm><primary>biztonság</primary></indexterm>
<sect1 id="security-synopsis">
- <title>Synopsis</title>
+ <title>Áttekintés</title>
- <para>This chapter will provide a basic introduction to system security
- concepts, some general good rules of thumb, and some advanced topics
- under &os;. A lot of the topics covered here can be applied
- to system and Internet security in general as well. The Internet
- is no longer a <quote>friendly</quote> place in which everyone
- wants to be your kind neighbor. Securing your system is imperative
- to protect your data, intellectual property, time, and much more
- from the hands of hackers and the like.</para>
+ <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>&os; provides an array of utilities and mechanisms to ensure
- the integrity and security of your system and network.</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>
- <para>After reading this chapter, you will know:</para>
+ <para>A fejezet elolvasása során
+ megismerjük:</para>
<itemizedlist>
<listitem>
- <para>Basic system security concepts, in respect to &os;.</para>
+ <para>az alapvetõ rendszerbiztonsági fogalmakat,
+ különös tekintettel a &os;-re</para>
</listitem>
<listitem>
- <para>About the various crypt mechanisms available in &os;,
- such as <acronym>DES</acronym> and <acronym>MD5</acronym>.</para>
+ <para>milyen olyan különbözõ
+ titkosítási mechanizmusok érthetõek el
+ a &os;-ben, mint például a
+ <acronym>DES</acronym> és az
+ <acronym>MD5</acronym></para>
</listitem>
<listitem>
- <para>How to set up one-time password authentication.</para>
+ <para>hogyan állítsunk be egyszeri jelszavas
+ azonosítást</para>
</listitem>
<listitem>
- <para>How to configure <acronym>TCP</acronym> Wrappers for use
- with <command>inetd</command>.</para>
+ <para>hogyan burkoljunk az <command>inetd</command>
+ segítségével <acronym>TCP</acronym>
+ kapcsolatokat</para>
</listitem>
<listitem>
- <para>How to set up <application>KerberosIV</application> on &os;
- releases prior to 5.0.</para>
+ <para>hogyan állítsuk be a
+ <application>KerberosIV</application>-t a &os; 5.0-nál
+ korábbi változatain</para>
</listitem>
<listitem>
- <para>How to set up <application>Kerberos5</application> on
- &os;.</para>
+ <para>hogyan állítsuk be a
+ <application>Kerberos5</application>-t a &os;-n</para>
</listitem>
<listitem>
- <para>How to configure IPsec and create a <acronym>VPN</acronym> between
- &os;/&windows; machines.</para>
+ <para>hogyan állítsuk be az IPsec-et és
+ hozzunk létre <acronym>VPN</acronym>-t &os;/&windows;
+ gépek között</para>
</listitem>
-
+
<listitem>
- <para>How to configure and use <application>OpenSSH</application>, &os;'s <acronym>SSH</acronym>
- implementation.</para>
+ <para>hogyan állítsuk be és
+ használjuk az <application>OpenSSH</application>-t, a
+ &os; <acronym>SSH</acronym>
+ implementációját</para>
</listitem>
<listitem>
- <para>What file system <acronym>ACL</acronym>s are and how to use them.</para>
+ <para>mik azok az <acronym>ACL</acronym>-ek az
+ állományrendszerben és miként kell
+ õket használni</para>
</listitem>
<listitem>
- <para>How to use the <application>Portaudit</application>
- utility to audit third party software packages installed
- from the Ports Collection.</para>
+ <para>hogyan kell használni a
+ <application>Portaudit</application> segédprogramot a
+ Portgyûjteménybõl telepített
+ külsõs szoftvercsomagok
+ biztonságosságának
+ ellenõrzésére</para>
</listitem>
<listitem>
- <para>How to utilize the &os; security advisories
- publications.</para>
+ <para>hogyan hasznosítsuk a &os; biztonsági
+ tanácsait tartalmazó
+ leírásokat</para>
</listitem>
<listitem>
- <para>Have an idea of what Process Accounting is and how to
- enable it on &os;.</para>
+ <para>mit jelent a futó programok
+ nyilvántartása és hogyan
+ engedélyezzük azt &os;-n</para>
</listitem>
</itemizedlist>
- <para>Before reading this chapter, you should:</para>
+ <para>A fejezet elolvasásához ajánlott:</para>
<itemizedlist>
<listitem>
- <para>Understand basic &os; and Internet concepts.</para>
+ <para>az alapvetõ &os; és internetes fogalmak
+ ismerete</para>
</listitem>
</itemizedlist>
- <para>Additional security topics are covered throughout this book.
- For example, Mandatory Access Control is discussed in <xref
- linkend="mac"> and Internet Firewalls are discussed in <xref
- linkend="firewalls">.</para>
+ <para>A könyvben további biztonsági
+ 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
+ (MAC) és a <xref linkend="firewalls">ben pedig az
+ internetes tûzfalakról.</para>
+
</sect1>
<sect1 id="security-intro">
- <title>Introduction</title>
+ <title>Bevezetés</title>
- <para>Security is a function that begins and ends with the system
- administrator. While all BSD &unix; multi-user systems have some
- inherent security, the job of building and maintaining additional
- security mechanisms to keep those users <quote>honest</quote> is
- probably one of the single largest undertakings of the sysadmin.
- Machines are only as secure as you make them, and security concerns
- are ever competing with the human necessity for convenience. &unix;
- systems, in general, are capable of running a huge number of
- simultaneous processes and many of these processes operate as
- servers — meaning that external entities can connect and talk
- to them. As yesterday's mini-computers and mainframes become
- today's desktops, and as computers become networked and
- inter-networked, security becomes an even bigger issue.</para>
+ <para>A biztonság egy olyan funkció, ami a
+ rendszergazdától indul és nála is
+ végzõdik. Míg az összes
+ többfelhasználós BSD &unix; rendszer
+ önmagában is valamennyire biztonságos, a
+ 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
+ számítógépek csak annyira
+ biztonságosak, mint amennyire beállítjuk
+ õket, é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
+ 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
+ biztonság fontossága is egyre jobban
+ növekszik.</para>
- <para>System security also pertains to dealing with various forms of
- attack, including attacks that attempt to crash, or otherwise make a
- system unusable, but do not attempt to compromise the
- <username>root</username> account (<quote>break root</quote>).
- Security concerns
- can be split up into several categories:</para>
+ <para>A rendszerek biztonsága a támadások
+ különbözõ formáival is foglalkozik,
+ többek közt olyan támadásokkal, amelyek a
+ rendszer összeomlását vagy
+ használhatatlanságát célozzák
+ meg, de nem próbálják meg veszélybe
+ sodorni a <username>root</username> felhasználó
+ hozzáférését (<quote>feltörni a
+ gépet</quote>). A biztonsággal kapcsolatos
+ problémák több kategóriára
+ oszthatóak:</para>
<orderedlist>
<listitem>
- <para>Denial of service attacks.</para>
+ <para>A szolgáltatások
+ mûködésképtelenné
+ tételére irányuló (DoS)
+ támadások.</para>
</listitem>
<listitem>
- <para>User account compromises.</para>
+ <para>A felhasználók
+ hozzáférésének
+ veszélyeztetése.</para>
</listitem>
<listitem>
- <para>Root compromise through accessible servers.</para>
+ <para>Rendszergazdai jogok megszerzése a közeli
+ szervereken keresztül.</para>
</listitem>
<listitem>
- <para>Root compromise via user accounts.</para>
+ <para>Rendszergazdai jogok megszerzése a
+ felhasználói hozzáféréseken
+ keresztül.</para>
</listitem>
<listitem>
- <para>Backdoor creation.</para>
+ <para>Kiskapuk létrehozása a rendszerben.</para>
</listitem>
</orderedlist>
<indexterm>
- <primary>DoS attacks</primary>
+ <primary>DoS támadás</primary>
<see>Denial of Service (DoS)</see>
</indexterm>
<indexterm>
- <primary>security</primary>
- <secondary>DoS attacks</secondary>
+ <primary>biztonság</primary>
+ <secondary>DoS támadás</secondary>
<see>Denial of Service (DoS)</see>
</indexterm>
<indexterm><primary>Denial of Service (DoS)</primary></indexterm>
- <para>A denial of service attack is an action that deprives the
- machine of needed resources. Typically, DoS attacks are
- brute-force mechanisms that attempt to crash or otherwise make a
- machine unusable by overwhelming its servers or network stack. Some
- DoS attacks try to take advantage of bugs in the networking
- stack to crash a machine with a single packet. The latter can only
- be fixed by applying a bug fix to the kernel. Attacks on servers
- can often be fixed by properly specifying options to limit the load
- the servers incur on the system under adverse conditions.
- Brute-force network attacks are harder to deal with. A
- spoofed-packet attack, for example, is nearly impossible to stop,
- short of cutting your system off from the Internet. It may not be
- able to take your machine down, but it can saturate your
- Internet connection.</para>
+ <para>A szolgáltatások
+ mûködésképtelenné
+ tételére irányuló
+ támadások olyan tevékenységre utalnak,
+ amelyek képesek megfosztani egy
+ számítógépet az
+ erõforrásaitól. A DoS támadások
+ többnyire nyers erõvel kivitelezett technikák,
+ melyek vagy a rendszer összeomlasztását vagy
+ pedig a használhatatlanná tételét
+ veszik célba úgy, hogy túlterhelik az
+ általa felkínált
+ szolgáltatásokat vagy a hálózati
+ alrendszert. Egyes DoS támadások a
+ hálózati alrendszerben rejtõzõ
+ hibákat igyekeznek kihasználni, amivel akár
+ egyetlen csomaggal is képesek romba dönteni egy
+ számítógépet. Ez utóbbit csak
+ úgy lehet orvosolni, ha a hibát kijavítjuk a
+ rendszermagban. A szerverekre mért csapásokat
+ 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
+ eldugítják.</para>
<indexterm>
- <primary>security</primary>
- <secondary>account compromises</secondary>
+ <primary>biztonság</primary>
+ <secondary>a hozzáférések
+ megszerzése</secondary>
</indexterm>
- <para>A user account compromise is even more common than a DoS
- attack. Many sysadmins still run standard
- <application>telnetd</application>, <application>rlogind</application>,
- <application>rshd</application>,
- and <application>ftpd</application> servers on their machines.
- These servers, by default, do
- not operate over encrypted connections. The result is that if you
- have any moderate-sized user base, one or more of your users logging
- into your system from a remote location (which is the most common
- and convenient way to login to a system) will have his or her
- password sniffed. The attentive system admin will analyze his
- remote access logs looking for suspicious source addresses even for
- successful logins.</para>
+ <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>,
+ <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
+ körültekintõ rendszergazdák mindig
+ ellenõrzik a bejelentkezéseket tartalmazó
+ naplókat és igyekeznek kiszûrni a gyanús
+ címeket még abban az esetben is, amikor a
+ bejelentkezés sikeres volt.</para>
- <para>One must always assume that once an attacker has access to a
- user account, the attacker can break <username>root</username>.
- However, the reality is that in a well secured and maintained system,
- access to a user account does not necessarily give the attacker
- access to <username>root</username>. The distinction is important
- because without access to <username>root</username> the attacker
- cannot generally hide his tracks and may, at best, be able to do
- nothing more than mess with the user's files, or crash the machine.
- User account compromises are very common because users tend not to
- take the precautions that sysadmins take.</para>
+ <para>Mindig arra kell gondolni, hogy ha a támadónak
+ sikerült megszerezni az egyik felhasználó
+ hozzáférését, akkor akár
+ képes lehet a <username>root</username>
+ felhasználó fiókjának
+ feltörésére is. Azonban a
+ valóságban egy jól õrzött és
+ karbantarott rendszer esetén a felhasználói
+ hozzáférések megszerzése nem
+ feltétlenül adja a támadó kezére
+ a <username>root</username>
+ hozzáférését. Ebben fontos
+ különbséget tenni, hiszen a
+ <username>root</username> felhasználó jogai
+ nélkül a támadó nem képes
+ 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
+ elõvigyázatosak, mint egy rendszergazda.</para>
<indexterm>
- <primary>security</primary>
- <secondary>backdoors</secondary>
+ <primary>biztonság</primary>
+ <secondary>kiskapuk</secondary>
</indexterm>
- <para>System administrators must keep in mind that there are
- potentially many ways to break <username>root</username> on a machine.
- The attacker may know the <username>root</username> password,
- the attacker may find a bug in a root-run server and be able
- to break <username>root</username> over a network
- connection to that server, or the attacker may know of a bug in
- a suid-root program that allows the attacker to break
- <username>root</username> once he has broken into a user's account.
- If an attacker has found a way to break <username>root</username>
- on a machine, the attacker may not have a need
- to install a backdoor. Many of the <username>root</username> holes
- found and closed to date involve a considerable amount of work
- by the attacker to cleanup after himself, so most attackers install
- backdoors. A backdoor provides the attacker with a way to easily
- regain <username>root</username> access to the system, but it
- also gives the smart system administrator a convenient way
- to detect the intrusion.
- Making it impossible for an attacker to install a backdoor may
- actually be detrimental to your security, because it will not
- close off the hole the attacker found to break in the first
- place.</para>
+ <para>A rendszergazdáknak mindig észben kell tartani,
+ hogy egy számítógépen több
+ módon is meg lehet szerezni a <username>root</username>
+ felhasználó
+ hozzáférését. A támadó
+ megtudhatja a <username>root</username> jelszavát,
+ hibát fedezhet fel az egyik rendszergazdai
+ jogosultsággal futó szerverben és
+ képes feltörni a <username>root</username>
+ hozzáférést egy hálózati
+ kapcsolaton keresztül, vagy a támadó olyan
+ programban talál hibát, aminek
+ segítségével el tudja érni a
+ <username>root</username> fiókját egy
+ felhasználói hozzáférésen
+ 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ó
+ hozzáféréséhez a rendszerben, de ezen
+ keresztül egy okos rendszergazda képes 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
+ ezzel nem szüntetjük meg azokat a lyukakat, amin
+ keresztül a támadó elõször
+ bejutott.</para>
+ <para>A támadások elleni védelmet mindig
+ több vonalban kell megvalósítani, melyeket
+ így oszthatunk fel:</para>
- <para>Security remedies should always be implemented with a
- multi-layered <quote>onion peel</quote> approach and can be
- categorized as follows:</para>
-
<orderedlist>
<listitem>
- <para>Securing <username>root</username> and staff accounts.</para>
+ <para>A rendszergazda és a személyzet
+ hozzáférésének
+ védelme.</para>
</listitem>
<listitem>
- <para>Securing <username>root</username>–run servers
- and suid/sgid binaries.</para>
+ <para>A rendszergazdai jogokkal futó szerverek és
+ suid/sgid engedélyekkel rendelkezõ programok
+ védelme.</para>
</listitem>
<listitem>
- <para>Securing user accounts.</para>
+ <para>A felhasználói
+ hozzáférések védelme.</para>
</listitem>
<listitem>
- <para>Securing the password file.</para>
+ <para>A jelszavakat tároló állomány
+ védelme.</para>
</listitem>
<listitem>
- <para>Securing the kernel core, raw devices, and
- file systems.</para>
+ <para>A rendszermag belsejének, a nyers
+ eszközök és az állományrendszerek
+ védelme.</para>
</listitem>
<listitem>
- <para>Quick detection of inappropriate changes made to the
- system.</para>
+ <para>A rendszert ért szabálytalan
+ módosítások gyors
+ észlelése.</para>
</listitem>
<listitem>
- <para>Paranoia.</para>
+ <para>Állandó paranoia.</para>
</listitem>
</orderedlist>
- <para>The next section of this chapter will cover the above bullet
- items in greater depth.</para>
+ <para>A fejezet most következõ szakaszában az
+ imént felsorolt elemeket fejtjük ki
+ mélyebben.</para>
+
</sect1>
<sect1 id="securing-freebsd">
- <title>Securing &os;</title>
+ <title>A &os; védelme</title>
<indexterm>
- <primary>security</primary>
- <secondary>securing &os;</secondary>
+ <primary>biztonság</primary>
+ <secondary>a &os; védelme</secondary>
</indexterm>
<note>
- <title>Command vs. Protocol</title>
- <para>Throughout this document, we will use
- <application>bold</application> text to refer to an
- application, and a <command>monospaced</command> font to refer
- to specific commands. Protocols will use a normal font. This
- typographical distinction is useful for instances such as ssh,
- since it is
- a protocol as well as command.</para>
+ <title>Parancs kontra protokoll</title>
+
+ <para>A dokumentumban a
+ <application>félkövéren</application> fogjuk
+ szedni az alkalmazásokat, és
+ <command>egyenszélességû</command>
+ betûkkel pedig az adott parancsokra hivatkozunk. A
+ protokollokat nem különböztetjük meg. Ez a
+ tipográfiai elkülönítés hasznos
+ például az ssh egyes vonatkozásainak
+ esetén, mivel ez egyben egy protokoll és egy
+ parancs is.</para>
</note>
- <para>The sections that follow will cover the methods of securing your
- &os; system that were mentioned in the <link
- linkend="security-intro">last section</link> of this chapter.</para>
+ <para>A most következõ szakaszok a &os;
+ védelmének azon módszereit ismertetik,
+ amelyekrõl a fejezet <link
+ linkend="security-intro">elõzõ szakaszában</link>
+ már írtunk.</para>
<sect2 id="securing-root-and-staff">
- <title>Securing the <username>root</username> Account and
- Staff Accounts</title>
+ <title>A rendszergazda és a személyzet
+ hozzáférésének védelme</title>
<indexterm>
<primary><command>su</command></primary>
</indexterm>
- <para>First off, do not bother securing staff accounts if you have
- not secured the <username>root</username> account.
- Most systems have a password assigned to the <username>root</username>
- account. The first thing you do is assume
- that the password is <emphasis>always</emphasis> compromised.
- This does not mean that you should remove the password. The
- password is almost always necessary for console access to the
- machine. What it does mean is that you should not make it
- possible to use the password outside of the console or possibly
- even with the &man.su.1; command. For example, make sure that
- your ptys are specified as being insecure in the
- <filename>/etc/ttys</filename> file so that direct
- <username>root</username> logins
- via <command>telnet</command> or <command>rlogin</command> are
- disallowed. If using other login services such as
- <application>sshd</application>, make sure that direct
- <username>root</username> logins are disabled there as well.
- You can do this by editing
- your <filename>/etc/ssh/sshd_config</filename> file, and making
- sure that <literal>PermitRootLogin</literal> is set to
- <literal>NO</literal>. Consider every access method —
- services such as FTP often fall through the cracks.
- Direct <username>root</username> logins should only be allowed
- via the system console.</para>
+ <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
+ hozzáférését sem tettük
+ eléggé biztonságossá. A
+ legtöbb rendszerben a <username>root</username>
+ hozzáféréshez tartozik egy jelszó.
+ Elsõként fel kell tennünk, hogy ez a
+ jelszó <emphasis>mindig</emphasis> megszerezhetõ.
+ Ez természetesen nem arra utal, hogy el kellene
+ 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
+ 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
+ biztonságos) típusúnak
+ állítottuk be, és így a
+ <command>telnet</command> vagy <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
+ 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
+ lehetséges hozzáférési módot
+ — az FTP és a hozzá hasonló
+ módok gyakran átszivárognak a
+ repedéseken. A rendszergazdának csak a
+ rendszerkonzolon keresztül szabad tudnia
+ bejelentkeznie.</para>
+
<indexterm>
<primary><groupname>wheel</groupname></primary>
</indexterm>
- <para>Of course, as a sysadmin you have to be able to get to
- <username>root</username>, so we open up a few holes.
- But we make sure these holes require additional password
- verification to operate. One way to make <username>root</username>
- accessible is to add appropriate staff accounts to the
- <groupname>wheel</groupname> group (in
- <filename>/etc/group</filename>). The staff members placed in the
- <groupname>wheel</groupname> group are allowed to
- <command>su</command> to <username>root</username>.
- You should never give staff
- members native <groupname>wheel</groupname> access by putting them in the
- <groupname>wheel</groupname> group in their password entry. Staff
- accounts should be placed in a <groupname>staff</groupname> group, and
- then added to the <groupname>wheel</groupname> group via the
- <filename>/etc/group</filename> file. Only those staff members
- who actually need to have <username>root</username> access
- should be placed in the
- <groupname>wheel</groupname> group. It is also possible, when using
- an authentication method such as Kerberos, to use Kerberos'
- <filename>.k5login</filename> file in the <username>root</username>
- account to allow a &man.ksu.1; to <username>root</username>
- without having to place anyone at all in the
- <groupname>wheel</groupname> group. This may be the better solution
- since the <groupname>wheel</groupname> mechanism still allows an
- intruder to break <username>root</username> if the intruder
- has gotten hold of your
- password file and can break into a staff account. While having
- the <groupname>wheel</groupname> mechanism is better than having
- nothing at all, it is not necessarily the safest option.</para>
+ <para>Természetesen egy rendszergazdának valahogy el
+ kell érnie a <username>root</username>
+ hozzáférést, ezért ezzel felnyitunk
+ néhány biztonsági rést. De
+ gondoskodjunk róla, hogy ezek a rések
+ további jelszavakat igényelnek a
+ mûködésükhöz. A
+ <username>root</username> hozzáférés
+ eléréséhez érdemes felvenni
+ tetszõleges személyzeti (staff)
+ hozzáféréseket a
+ <groupname>wheel</groupname> csoportba (az
+ <filename>/etc/group</filename> állományban). Ha
+ a személyzet tagjait a <groupname>wheel</groupname>
+ 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
+ <groupname>staff</groupname> csoportba, és majd csak
+ ezután az <filename>/etc/group</filename>
+ állományon keresztül a
+ <groupname>wheel</groupname> csoportba. A személyzetnek
+ csak azon tagjait tegyük ténylegesen a
+ <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éhez olyankor, amikor a
+ kezében van a jelszavakat tároló
+ állomány és meg tudja szerezni a
+ személyzet valamelyik tagjának
+ 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
+ legbiztonságosabb.</para>
- <!-- XXX:
- This will need updating depending on the outcome of PR bin/71147.
- Personally I know what I'd like to see, which puts this in definite
- need of a rewrite, but we'll have to wait and see. ceri@
- -->
+ <para>A személyzeti hozzáférések
+ és ezáltal a <username>root</username>
+ hozzáférésének egyik közvetett
+ módja egy alternatív bejelentkezési
+ mód használata, ami lényegében a
+ személyzeti hozzáférések
+ titkosított jelszavainak
+ <quote>kicsillagozását</quote> jelenti. A
+ &man.vipw.8; parancs használatával a
+ titkosított jelszavakat ki tudjuk cserélni
+ egyetlen <quote><literal>*</literal></quote> karakterre. Ez a
+ parancs a jelszó alapú hitelesítések
+ letiltásához frissíteni fogja az
+ <filename>/etc/master.passwd</filename> állományt
+ valamint a felhasználókat és jelszavakat
+ tartalmazó adatbázist.</para>
- <para>An indirect way to secure staff accounts, and ultimately
- <username>root</username> access is to use an alternative
- login access method and
- do what is known as <quote>starring</quote> out the encrypted
- password for the staff accounts. Using the &man.vipw.8;
- command, one can replace each instance of an encrypted password
- with a single <quote><literal>*</literal></quote> character.
- This command will update the <filename>/etc/master.passwd</filename>
- file and user/password database to disable password-authenticated
- logins.</para>
+ <para>A személyzet egyik tagjának tehát
+ így néz ki a bejegyzése:</para>
- <para>A staff account entry such as:</para>
-
<programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
- <para>Should be changed to this:</para>
+ <para>Amit erre cserélünk ki:</para>
<programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
- <para>This change will prevent normal logins from occurring,
- since the encrypted password will never match
- <quote><literal>*</literal></quote>. With this done,
- staff members must use
- another mechanism to authenticate themselves such as
- &man.kerberos.1; or &man.ssh.1; using a public/private key
- pair. When using something like Kerberos, one generally must
- secure the machines which run the Kerberos servers and your
- desktop workstation. When using a public/private key pair
- with ssh, one must generally secure
- the machine used to login <emphasis>from</emphasis> (typically
- one's workstation). An additional layer of protection can be
- added to the key pair by password protecting the key pair when
- creating it with &man.ssh-keygen.1;. Being able to
- <quote>star</quote> out the passwords for staff accounts also
- guarantees that staff members can only login through secure
- access methods that you have set up. This forces all staff
- members to use secure, encrypted connections for all of their
- sessions, which closes an important hole used by many
- intruders: sniffing the network from an unrelated,
- less secure machine.</para>
+ <para>Ez a változtatás meggátolja a
+ hagyományos bejelentkezéseket, mivel a
+ titkosított jelszó soha nem fog egyezni a
+ <quote><literal>*</literal></quote> karakterrel. Ezután
+ a személyzet tagjainak más módon kell
+ azonosítaniuk magukat, például a
+ &man.kerberos.1; segítségével vagy az
+ &man.ssh.1; nyilvános/privát
+ kulcspárjaival. Amikor egy Kerberoshoz hasonló
+ rendszert használunk, akkor általában a
+ Kerberos szervereit futtató gépeket és az
+ asztali munkaállomásunkat kell védeni.
+ Amikor az ssh-t használjuk nyilvános/privát
+ kulcspárokkal, általában azt a gépet
+ kell védenünk <emphasis>ahonnan</emphasis>
+ bejelentkezünk (ez többnyire egy
+ munkaállomás). A kulcspárokat bevonhatjuk
+ egy további védelmi réteggel is, ha a
+ &man.ssh-keygen.1; paranccsal történõ
+ létrehozásuk során jelszót is
+ megadunk. Ha <quote>kicsillagozzuk</quote> a személyzet
+ tagjainak jelszavait, akkor biztosra vehetjük, hogy
+ kizárólag csak az általunk
+ telepített biztonságos módokon fognak
+ bejelentkezni. Ennek köszönhetõen a
+ személyzet minden tagja biztonságos,
+ titkosított kapcsolatot fog használni, és
+ ezzel elzárunk egy olyan biztonsági rést,
+ amit a legtöbb behatoló kihasznál: a
+ gyengébb védelmû
+ számítógépek felõl
+ érkezõ forgalom lehallgatását.</para>
+
+ <para>Egy még közvetettebb védelmi mechanizmus
+ szerint mindig 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
+ szolgáltatásokat futtat, akkor a
+ munkaállomásunknak egyetlen egyet sem lenne
+ szabad. A munkaállomásunk
+ biztonságossá tételéhez a
+ lehetõ legkevesebb szolgáltatást szabad csak
+ futtatnunk, de ha lehet, egyet sem, és mindig
+ jelszóval védett
+ képernyõvédõt használjuk.
+ Természetesen ha a támadó képes
+ fizikailag hozzáférni a
+ munkaállomásunkhoz, akkor szinte bármilyen
+ mélységû védelmet képes
+ áttörni. Ezt mindenképpen
+ számításba kell vennünk, azonban ne
+ felejtsük el, hogy a legtöbb betörési
+ kísérlet távolról,
+ hálózaton keresztülrõl érkezik
+ olyan emberektõl, akik fizikailag nem férnek
+ hozzá a munkaállomásunkhoz vagy a
+ szervereinkhez.</para>
- <para>The more indirect security mechanisms also assume that you are
- logging in from a more restrictive server to a less restrictive
- server. For example, if your main box is running all sorts of
- servers, your workstation should not be running any. In order for
- your workstation to be reasonably secure you should run as few
- servers as possible, up to and including no servers at all, and
- you should run a password-protected screen blanker. Of course,
- given physical access to a workstation an attacker can break any
- sort of security you put on it. This is definitely a problem that
- you should consider, but you should also consider the fact that the
- vast majority of break-ins occur remotely, over a network, from
- people who do not have physical access to your workstation or
- servers.</para>
<indexterm><primary>KerberosIV</primary></indexterm>
- <para>Using something like Kerberos also gives you the ability to
- disable or change the password for a staff account in one place,
- and have it immediately affect all the machines on which the staff
- member may have an account. If a staff member's account gets
- compromised, the ability to instantly change his password on all
- machines should not be underrated. With discrete passwords,
- changing a password on N machines can be a mess. You can also
- impose re-passwording restrictions with Kerberos: not only can a
- Kerberos ticket be made to timeout after a while, but the Kerberos
- system can require that the user choose a new password after a
- certain period of time (say, once a month).</para>
+ <para>A Kerberos és a hozzá hasonló
+ rendszerek használatával egyszerre tudjuk a
+ személyzet tagjainak jelszavát letiltani vagy
+ megváltoztatni, ami egybõl
+ érvényessé válik minden olyan
+ gépen, ahová az adott felhasználónak
+ bármilyen hozzáférése is volt. Nem
+ szabad lebecsülnünk ezt a gyors
+ jelszóváltási lehetõséget abban
+ az esetben, ha a személyzet valamelyik tagjának
+ hozzáférését megszerezték.
+ Hagyományos jelszavak használatával a
+ jelszavak megváltoztatása N gépen igazi
+ káosz. A Kerberosban jelszóváltási
+ megszorításokat is felállíthatunk:
+ 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>
</sect2>
<sect2>
- <title>Securing Root-run Servers and SUID/SGID Binaries</title>
+ <title>A rendszergazdai jogokkal futó szerverek és
+ SUID/SGID engedélyekkel rendelkezõ programok
+ védelme</title>
<indexterm>
- <primary><command>ntalk</command></primary>
+ <primary><command>ntalk</command></primary>
</indexterm>
<indexterm>
- <primary><command>comsat</command></primary>
+ <primary><command>comsat</command></primary>
</indexterm>
<indexterm>
- <primary><command>finger</command></primary>
+ <primary><command>finger</command></primary>
</indexterm>
<indexterm>
- <primary>sandboxes</primary>
+ <primary>sandboxes</primary>
</indexterm>
<indexterm>
- <primary><application>sshd</application></primary>
+ <primary><application>sshd</application></primary>
</indexterm>
<indexterm>
- <primary><application>telnetd</application></primary>
+ <primary><application>telnetd</application></primary>
</indexterm>
<indexterm>
- <primary><application>rshd</application></primary>
+ <primary><application>rshd</application></primary>
</indexterm>
<indexterm>
- <primary><application>rlogind</application></primary>
+ <primary><application>rlogind</application></primary>
</indexterm>
- <para>The prudent sysadmin only runs the servers he needs to, no
- more, no less. Be aware that third party servers are often the
- most bug-prone. For example, running an old version of
- <application>imapd</application> or
- <application>popper</application> is like giving a universal
- <username>root</username> ticket out to the entire world.
- Never run a server that you have not checked out carefully.
- Many servers do not need to be run as <username>root</username>.
- For example, the <application>ntalk</application>,
- <application>comsat</application>, and
- <application>finger</application> daemons can be run in special
>>> TRUNCATED FOR MAIL (1000 lines) <<<
More information about the p4-projects
mailing list