From owner-p4-projects@FreeBSD.ORG Wed Jan 30 22:40:24 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 493FD16A420; Wed, 30 Jan 2008 22:40:24 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D2B016A417 for ; Wed, 30 Jan 2008 22:40:24 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 0208C13C468 for ; Wed, 30 Jan 2008 22:40:24 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.1/8.14.1) with ESMTP id m0UMeN5F017467 for ; Wed, 30 Jan 2008 22:40:23 GMT (envelope-from pgj@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.1/8.14.1/Submit) id m0UMeN76017464 for perforce@freebsd.org; Wed, 30 Jan 2008 22:40:23 GMT (envelope-from pgj@FreeBSD.org) Date: Wed, 30 Jan 2008 22:40:23 GMT Message-Id: <200801302240.m0UMeN76017464@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to pgj@FreeBSD.org using -f From: Gabor Pali To: Perforce Change Reviews Cc: Subject: PERFORCE change 134491 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 22:40:24 -0000 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 $ --> - + + + Matthew Dillon - Much of this chapter has been taken from the - security(7) manual page by + A fejezet legnagyobb részét a security(7) + man oldal alapján írta: - Security - security + Biztonság + biztonság - Synopsis + Áttekintés - 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 friendly 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. + Ez a fejezet egy alapvetõ bevezetést ad a + rendszerek biztonsági fogalmaiba, néhány + általános jótanácsot és + néhány komolyabb témát &os; alatt. Az + itt megfogalmazott témák nagy része + egyaránt ráhúzható rendszerünk + és általánosságban véve az + internetes biztonságra is. A internet már nem az + békés hely, ahol mindenki a kedves + szomszéd szerepét játssza. A + rendszerünk bebiztosítása elkerülhetetlen + az adataink, szellemi tulajdonunk, idõnk és még + sok minden más megvédésére az + internetes banditák és hasonlók ellen. - &os; provides an array of utilities and mechanisms to ensure - the integrity and security of your system and network. + 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. - After reading this chapter, you will know: + A fejezet elolvasása során + megismerjük: - Basic system security concepts, in respect to &os;. + az alapvetõ rendszerbiztonsági fogalmakat, + különös tekintettel a &os;-re - About the various crypt mechanisms available in &os;, - such as DES and MD5. + milyen olyan különbözõ + titkosítási mechanizmusok érthetõek el + a &os;-ben, mint például a + DES és az + MD5 - How to set up one-time password authentication. + hogyan állítsunk be egyszeri jelszavas + azonosítást - How to configure TCP Wrappers for use - with inetd. + hogyan burkoljunk az inetd + segítségével TCP + kapcsolatokat - How to set up KerberosIV on &os; - releases prior to 5.0. + hogyan állítsuk be a + KerberosIV-t a &os; 5.0-nál + korábbi változatain - How to set up Kerberos5 on - &os;. + hogyan állítsuk be a + Kerberos5-t a &os;-n - How to configure IPsec and create a VPN between - &os;/&windows; machines. + hogyan állítsuk be az IPsec-et és + hozzunk létre VPN-t &os;/&windows; + gépek között - + - How to configure and use OpenSSH, &os;'s SSH - implementation. + hogyan állítsuk be és + használjuk az OpenSSH-t, a + &os; SSH + implementációját - What file system ACLs are and how to use them. + mik azok az ACL-ek az + állományrendszerben és miként kell + õket használni - How to use the Portaudit - utility to audit third party software packages installed - from the Ports Collection. + hogyan kell használni a + Portaudit segédprogramot a + Portgyûjteménybõl telepített + külsõs szoftvercsomagok + biztonságosságának + ellenõrzésére - How to utilize the &os; security advisories - publications. + hogyan hasznosítsuk a &os; biztonsági + tanácsait tartalmazó + leírásokat - Have an idea of what Process Accounting is and how to - enable it on &os;. + mit jelent a futó programok + nyilvántartása és hogyan + engedélyezzük azt &os;-n - Before reading this chapter, you should: + A fejezet elolvasásához ajánlott: - Understand basic &os; and Internet concepts. + az alapvetõ &os; és internetes fogalmak + ismerete - Additional security topics are covered throughout this book. - For example, Mandatory Access Control is discussed in and Internet Firewalls are discussed in . + A könyvben további biztonsági + témákról is szó esik, + például a ben a + Kötelezõ + hozzáférésvezérlésrõl + (MAC) és a ben pedig az + internetes tûzfalakról. + - Introduction + Bevezetés - 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 honest 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. + 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 + fegyelmezéséhez szükség + további biztonsági mechanizmusok + kiépítése és karbantartása + minden bizonnyal egy rendszergazda egyik legnagyobb + kötelessége. A + 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. - 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 - root account (break root). - Security concerns - can be split up into several categories: + 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 root felhasználó + hozzáférését (feltörni a + gépet). A biztonsággal kapcsolatos + problémák több kategóriára + oszthatóak: - Denial of service attacks. + A szolgáltatások + mûködésképtelenné + tételére irányuló (DoS) + támadások. - User account compromises. + A felhasználók + hozzáférésének + veszélyeztetése. - Root compromise through accessible servers. + Rendszergazdai jogok megszerzése a közeli + szervereken keresztül. - Root compromise via user accounts. + Rendszergazdai jogok megszerzése a + felhasználói hozzáféréseken + keresztül. - Backdoor creation. + Kiskapuk létrehozása a rendszerben. - DoS attacks + DoS támadás Denial of Service (DoS) - security - DoS attacks + biztonság + DoS támadás Denial of Service (DoS) Denial of Service (DoS) - 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. + 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. - security - account compromises + biztonság + a hozzáférések + megszerzése - A user account compromise is even more common than a DoS - attack. Many sysadmins still run standard - telnetd, rlogind, - rshd, - and ftpd 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. + A DoS támadásoknál még gyakrabban + elõfordulnak a felhasználói + hozzáférések feltörései. A + rendszergazdák többsége még mindig + futtat telnetd, + rlogin, rshd + és ftpd szervereket a + gépén. Ezek a szerverek + alapértelmezés szerint nem titkosított + kapcsolaton keresztül mûködnek. Ebbõl + következik, hogy ha nincsen annyira sok + felhasználónk és közülük + néhányan távoli helyekrõl jelentkeznek + be (ami az egyik leggyakoribb és legkényelmesebb + módja a bejelentkezésnek), akkor elõfordulhat, + hogy valami megneszeli a jelszavaikat. A + 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. - One must always assume that once an attacker has access to a - user account, the attacker can break root. - 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 root. The distinction is important - because without access to root 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. + 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 root + 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 root + hozzáférését. Ebben fontos + különbséget tenni, hiszen a + root 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. - security - backdoors + biztonság + kiskapuk - System administrators must keep in mind that there are - potentially many ways to break root on a machine. - The attacker may know the root password, - the attacker may find a bug in a root-run server and be able - to break root 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 - root once he has broken into a user's account. - If an attacker has found a way to break root - on a machine, the attacker may not have a need - to install a backdoor. Many of the root 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 root 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. + A rendszergazdáknak mindig észben kell tartani, + hogy egy számítógépen több + módon is meg lehet szerezni a root + felhasználó + hozzáférését. A támadó + megtudhatja a root jelszavát, + hibát fedezhet fel az egyik rendszergazdai + jogosultsággal futó szerverben és + képes feltörni a root + 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 + root 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 root + 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. + A támadások elleni védelmet mindig + több vonalban kell megvalósítani, melyeket + így oszthatunk fel: - Security remedies should always be implemented with a - multi-layered onion peel approach and can be - categorized as follows: - - Securing root and staff accounts. + A rendszergazda és a személyzet + hozzáférésének + védelme. - Securing root–run servers - and suid/sgid binaries. + A rendszergazdai jogokkal futó szerverek és + suid/sgid engedélyekkel rendelkezõ programok + védelme. - Securing user accounts. + A felhasználói + hozzáférések védelme. - Securing the password file. + A jelszavakat tároló állomány + védelme. - Securing the kernel core, raw devices, and - file systems. + A rendszermag belsejének, a nyers + eszközök és az állományrendszerek + védelme. - Quick detection of inappropriate changes made to the - system. + A rendszert ért szabálytalan + módosítások gyors + észlelése. - Paranoia. + Állandó paranoia. - The next section of this chapter will cover the above bullet - items in greater depth. + A fejezet most következõ szakaszában az + imént felsorolt elemeket fejtjük ki + mélyebben. + - Securing &os; + A &os; védelme - security - securing &os; + biztonság + a &os; védelme - Command vs. Protocol - Throughout this document, we will use - bold text to refer to an - application, and a monospaced 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. + Parancs kontra protokoll + + A dokumentumban a + félkövéren fogjuk + szedni az alkalmazásokat, és + egyenszélességû + 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. - The sections that follow will cover the methods of securing your - &os; system that were mentioned in the last section of this chapter. + A most következõ szakaszok a &os; + védelmének azon módszereit ismertetik, + amelyekrõl a fejezet elõzõ szakaszában + már írtunk. - Securing the <username>root</username> Account and - Staff Accounts + A rendszergazda és a személyzet + hozzáférésének védelme su - First off, do not bother securing staff accounts if you have - not secured the root account. - Most systems have a password assigned to the root - account. The first thing you do is assume - that the password is always 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 - /etc/ttys file so that direct - root logins - via telnet or rlogin are - disallowed. If using other login services such as - sshd, make sure that direct - root logins are disabled there as well. - You can do this by editing - your /etc/ssh/sshd_config file, and making - sure that PermitRootLogin is set to - NO. Consider every access method — - services such as FTP often fall through the cracks. - Direct root logins should only be allowed - via the system console. + 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 root + hozzáféréshez tartozik egy jelszó. + Elsõként fel kell tennünk, hogy ez a + jelszó mindig 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 /etc/ttys + állományban megadott + pszeudóterminálokat insecure (nem + biztonságos) típusúnak + állítottuk be, és így a + telnet vagy rlogin + parancsokon keresztül nem lehet rendszergazdaként + bejelentkezni. Ha más szolgáltatáson + keresztül jelentkezünk be, például az + sshd + segítségével, akkor ebben az esetben is + gondoskodjunk róla, hogy itt is letiltottuk a + közvetlen rendszergazdai bejelentkezés + lehetõségét. Ezt úgy tudjuk megtenni, + ha megnyitjuk az /etc/ssh/sshd_config + állományt és a + PermitRootLogin paraméter + értékét átállítjuk + NO-ra. Vegyünk számba minden + 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. + wheel - Of course, as a sysadmin you have to be able to get to - root, so we open up a few holes. - But we make sure these holes require additional password - verification to operate. One way to make root - accessible is to add appropriate staff accounts to the - wheel group (in - /etc/group). The staff members placed in the - wheel group are allowed to - su to root. - You should never give staff - members native wheel access by putting them in the - wheel group in their password entry. Staff - accounts should be placed in a staff group, and - then added to the wheel group via the - /etc/group file. Only those staff members - who actually need to have root access - should be placed in the - wheel group. It is also possible, when using - an authentication method such as Kerberos, to use Kerberos' - .k5login file in the root - account to allow a &man.ksu.1; to root - without having to place anyone at all in the - wheel group. This may be the better solution - since the wheel mechanism still allows an - intruder to break root if the intruder - has gotten hold of your - password file and can break into a staff account. While having - the wheel mechanism is better than having - nothing at all, it is not necessarily the safest option. + Természetesen egy rendszergazdának valahogy el + kell érnie a root + 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 + root hozzáférés + eléréséhez érdemes felvenni + tetszõleges személyzeti (staff) + hozzáféréseket a + wheel csoportba (az + /etc/group állományban). Ha + a személyzet tagjait a wheel + csoportba rakjuk, akkor innen a su paranccsal + fel tudjuk venni a root + felhasználó jogait. A személyzet tagjait + közvetlenül sose vegyük fel a + wheel csoportba a + létrehozásukkor! A személyzet tagjai + elõször kerüljenek egy + staff csoportba, és majd csak + ezután az /etc/group + állományon keresztül a + wheel csoportba. A személyzetnek + csak azon tagjait tegyük ténylegesen a + wheel csoportba, akiknek valóban + szükségük van a root + felhasználó + hozzáférésére. Ha mondjuk a + Kerberost használjuk hitelesítésre, akkor + megcsinálhatjuk azt is, hogy a Kerberos + .k5login állományában + engedélyezzük a &man.ksu.1; parancson keresztül + a root hozzáférés + elérését a wheel + csoport alkalmazása nélkül. Ez a + megoldás talán még jobb is, mivel a + wheel használata esetén a + behatolónak még mindig lehetõsége van + hozzájutni a root + hozzáférésé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 + wheel csoport által + felkínált megoldás ugyan jobb, mint a + semmi, de kétségtelenül nem + legbiztonságosabb. - + A személyzeti hozzáférések + és ezáltal a root + 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 + kicsillagozását jelenti. A + &man.vipw.8; parancs használatával a + titkosított jelszavakat ki tudjuk cserélni + egyetlen * karakterre. Ez a + parancs a jelszó alapú hitelesítések + letiltásához frissíteni fogja az + /etc/master.passwd állományt + valamint a felhasználókat és jelszavakat + tartalmazó adatbázist. - An indirect way to secure staff accounts, and ultimately - root access is to use an alternative - login access method and - do what is known as starring 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 * character. - This command will update the /etc/master.passwd - file and user/password database to disable password-authenticated - logins. + A személyzet egyik tagjának tehát + így néz ki a bejegyzése: - A staff account entry such as: - foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - Should be changed to this: + Amit erre cserélünk ki: foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - This change will prevent normal logins from occurring, - since the encrypted password will never match - *. 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 from (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 - star 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. + Ez a változtatás meggátolja a + hagyományos bejelentkezéseket, mivel a + titkosított jelszó soha nem fog egyezni a + * 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 ahonnan + 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 kicsillagozzuk 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. + + 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. - 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. KerberosIV - 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). + 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. - Securing Root-run Servers and SUID/SGID Binaries + A rendszergazdai jogokkal futó szerverek és + SUID/SGID engedélyekkel rendelkezõ programok + védelme - ntalk + ntalk - comsat + comsat - finger + finger - sandboxes + sandboxes - sshd + sshd - telnetd + telnetd - rshd + rshd - rlogind + rlogind - 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 - imapd or - popper is like giving a universal - root 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 root. - For example, the ntalk, - comsat, and - finger daemons can be run in special >>> TRUNCATED FOR MAIL (1000 lines) <<<