Date: Wed, 30 Jan 2008 22:40:23 GMT From: Gabor Pali <pgj@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 134491 for review Message-ID: <200801302240.m0UMeN76017464@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=134491 Change 134491 by pgj@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@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) <<<
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801302240.m0UMeN76017464>