path: root/hu_HU.ISO8859-2/books/handbook/security/chapter.sgml

<?xml version="1.0" encoding="iso-8859-2" standalone="no"?>
<!--
     The FreeBSD Documentation Project

     $FreeBSD$
-->

<!-- The FreeBSD Hungarian Documentation Project
     Translated by: PALI, Gabor <pgj@FreeBSD.org>
     %SOURCE%	en_US.ISO8859-1/books/handbook/security/chapter.sgml
     %SRCID%	1.336
-->

<chapter id="security" lang="hu">
  <chapterinfo>
    <authorgroup>
      <author>
	<firstname>Matthew</firstname>
	<surname>Dillon</surname>
	<contrib>A fejezet legnagyobb részét a security(7)
	  man oldal alapján írta: </contrib>
      </author>
    </authorgroup>
  </chapterinfo>

  <title>Biztonság</title>

  <indexterm><primary>biztonság</primary></indexterm>

  <sect1 id="security-synopsis">
    <title>Áttekintés</title>

    <para>Ez a fejezet egy alapvetõ bevezetés a rendszerek
      biztonsági fogalmaiba, ad néhány
      általános jótanácsot és a
      &os;-vel kapcsolatban feldolgoz néhány komolyabb
      témát.  Az itt megfogalmazott témák
      nagy része egyaránt ráhúzható
      rendszerünk és általánosságban
      véve az internet biztonságára is.  A internet
      már nem az <quote>békés</quote> hely, ahol
      mindenki a kedves szomszéd szerepét játssza.
      A rendszerünk bebiztosítása
      elkerülhetetlen az adataink, szellemi tulajdonunk, idõnk
      és még sok minden más
      megvédésére az internetes banditák
      és hasonlók ellen.</para>

    <para>A &os; segédprogramok és mechanizmusok
      sorát kínálja fel a rendszerünk
      és hálózatunk
      sértetlenségének és
      biztonságának fenntartására.</para>

    <para>A fejezet elolvasása során
      megismerjük:</para>

    <itemizedlist>
      <listitem>
	<para>az alapvetõ rendszerbiztonsági fogalmakat,
	  különös tekintettel a &os;-re;</para>
      </listitem>

      <listitem>
	<para>milyen olyan különbözõ
	  titkosítási mechanizmusok érthetõek
	  el a &os;-ben, mint például a
	  <acronym>DES</acronym> és az
	  <acronym>MD5</acronym>;</para>
      </listitem>

      <listitem>
	<para>hogyan állítsunk be egyszeri jelszavas
	  azonosítást;</para>
      </listitem>

      <listitem>
	<para>hogyan burkoljunk az <application>inetd</application>
	  segítségével <acronym>TCP</acronym>
	  kapcsolatokat;</para>
      </listitem>

      <listitem>
	<para>hogyan állítsuk be a
	  <application>KerberosIV</application>-t a
	  &os;&nbsp;5.0-nál korábbi
	  változatain;</para>
      </listitem>

      <listitem>
	<para>hogyan állítsuk be a
	  <application>Kerberos5</application>-t a &os;-n;</para>
      </listitem>

      <listitem>
	<para>hogyan állítsuk be az IPsec-et és
	  hozzunk létre <acronym>VPN</acronym>-t &os;/&windows;
	  gépek között;</para>
      </listitem>

      <listitem>
	<para>hogyan állítsuk be és
	  használjuk az <application>OpenSSH</application>-t, a
	  &os; <acronym>SSH</acronym>
	  implementációját;</para>
      </listitem>

      <listitem>
	<para>mik azok az <acronym>ACL</acronym>-ek az
	  állományrendszerben és miként kell
	  ezeket használni;</para>
      </listitem>

      <listitem>
	<para>hogyan kell használni a
	  <application>Portaudit</application> segédprogramot a
	  Portgyûjteménybõl telepített
	  külsõ szoftvercsomagok
	  biztonságosságának
	  ellenõrzésére;</para>
      </listitem>

      <listitem>
	<para>hogyan hasznosítsuk a &os; biztonsági
	  tanácsait tartalmazó
	  leírásokat</para>
      </listitem>

      <listitem>
	<para>mit jelent a futó programok
	  nyilvántartása és hogyan
	  engedélyezzük azt &os;-n.</para>
      </listitem>
    </itemizedlist>

    <para>A fejezet elolvasásához ajánlott:</para>

    <itemizedlist>
      <listitem>
	<para>az alapvetõ &os; és internetes fogalmak
	  ismerete.</para>
      </listitem>
    </itemizedlist>

    <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és-vezérlésrõl
      (MAC) és a <xref linkend="firewalls"/>ben pedig az
      internetes tûzfalakról.</para>

  </sect1>

  <sect1 id="security-intro">
    <title>Bevezetés</title>

    <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ésére és
      karbantartására, ami minden bizonnyal egy
      rendszergazda egyik legfontosabb kötelessége.  A
      számítógépek csak annyira
      biztonságosak, mint amennyire beállítjuk,
      é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
      &mdash; ez azt jelenti, hogy hozzájuk
      kívülrõl érkezõ egyedek
      csatlakozhatnak és társaloghatnak velük.  Ahogy
      a tegnap kicsi és nagy
      számítógépei napjaink asztali
      gépeivé váltak és ahogy a
      számítógépek egyre többen
      csatlakoznak hálózatra és az internetre, a
      biztonság fontossága is egyre jobban
      növekszik.</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>A szolgáltatások
	  mûködésképtelenné
	  tételére irányuló (DoS, Denial of
	  Service) támadások.</para>
      </listitem>

      <listitem>
	<para>A felhasználói fiókok
	  veszélyeztetése.</para>
      </listitem>

      <listitem>
	<para>Rendszergazdai jogok megszerzése a közeli
	  szervereken keresztül.</para>
      </listitem>

      <listitem>
	<para>Rendszergazdai jogok megszerzése a
	  felhasználói fiókokon
	  keresztül.</para>
      </listitem>

      <listitem>
	<para>Kiskapuk létrehozása a rendszerben.</para>
      </listitem>
    </orderedlist>

    <indexterm>
      <primary>DoS támadás</primary>
      <see>Denial of Service (DoS)</see>
    </indexterm>
    <indexterm>
      <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 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
      ezeket ért terhelést egy kellemetlenebb helyezetben.
      A nyers erõt alkalmazó hálózati
      támadásokkal a legnehezebb szembenézni.
      Például az álcázott
      támadadások, melyeket szinte lehetetlen
      megállítani, remek eszközök arra, hogy
      elvágják gépünket az internettõl.
      Ezzel viszont nem csak azt iktatják ki, hanem az
      internet-csatlakozásunkat is
      eldugítják.</para>

    <indexterm>
      <primary>biztonság</primary>
      <secondary>a hozzáférések
	megszerzése</secondary>
    </indexterm>

    <para>A DoS támadásoknál még gyakrabban
      elõfordul, hogy feltörik a felhasználók
      fiókjait.  A rendszergazdák többsége
      még mindig futtat <application>telnetd</application>,
      <application>rlogin</application>, <application>rshd</application>
      és <application>ftpd</application> szervereket a
      gépen.  Ezek a szerverek alapértelmezés
      szerint nem titkosított kapcsolaton keresztül
      mûködnek.  Ebbõl következik, hogy ha nincs
      annyira sok felhasználónk és
      közülük néhányan távoli
      helyekrõl jelentkeznek be (ami az egyik leggyakoribb
      és legkényelmesebb módja ennek), akkor
      elõfordulhat, hogy valami megneszeli a jelszavaikat.  A
      körültekintõ rendszergazdák mindig
      ellenõrzik a bejelentkezéseket tartalmazó
      naplókat és igyekeznek kiszûrni a gyanús
      címeket még abban az esetben is, amikor a
      bejelentkezés sikeres volt.</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 fiókok feltörése
      nagyon gyakran megtörténik, mivel a
      felhasználók messze nem annyira
      elõvigyázatosak, mint egy rendszergazda.</para>

    <indexterm>
      <primary>biztonság</primary>
      <secondary>kiskapuk</secondary>
    </indexterm>

    <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 rendszerben.
      Az eddig talált és javított, rendszergazdai
      jogok megszerzését lehetõvé tevõ
      biztonsági rések egy része esetében
      viszont a támadónak akkora mennyiségû
      munkát jelentene eltûntetni maga után a
      nyomokat, hogy megéri neki egy kiskaput telepíteni.
      Ennek segítségével a támadó
      ismét könnyedén hozzájuthat a
      <username>root</username> felhasználó
      hozzáféréséhez a rendszerben, de ezen
      keresztül egy okos rendszergazda képes is a
      behatolót leleplezni.  A kiskapuk lerakásának
      megakadályozása valójában káros
      a biztonság szempontjából nézve, mert
      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>

    <orderedlist>
      <listitem>
	<para>A rendszergazda és a személyzet
	  hozzáférésének
	  védelme.</para>
      </listitem>

      <listitem>
	<para>A rendszergazdai jogokkal futó szerverek és
	  a suid/sgid engedélyekkel rendelkezõ programok
	  védelme.</para>
      </listitem>

      <listitem>
	<para>A felhasználói
	  hozzáférések védelme.</para>
      </listitem>

      <listitem>
	<para>A jelszavakat tároló állomány
	  védelme.</para>
      </listitem>

      <listitem>
	<para>A rendszermag belsejének, a nyers
	  eszközök és az
	  állományrendszerek védelme.</para>
      </listitem>

      <listitem>
	<para>A rendszert ért szabálytalan
	  módosítások gyors
	  észlelése.</para>
      </listitem>

      <listitem>
	<para>Állandó paranoia.</para>
      </listitem>
    </orderedlist>

    <para>A fejezet most következõ szakaszában az
      imént felsorolt elemeket fejtjük ki
      részletesebben.</para>

  </sect1>

  <sect1 id="securing-freebsd">
    <title>A &os; védelme</title>

    <indexterm>
      <primary>biztonság</primary>
      <secondary>a &os; védelme</secondary>
    </indexterm>

    <note>
      <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>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>A rendszergazda és a személyzet
	hozzáférésének
	védelme</title>

      <indexterm><primary><command>su</command></primary></indexterm>

      <para>Elõször is: ne törjük magunkat a
	személyzeti fiókok biztonságossá
	tételével, ha még a rendszergazda
	hozzáférését sem tettük
	eléggé biztonságossá.  A
	legtöbb rendszerben a <username>root</username>
	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 szeretnénk
	rávilágítani, hogy a konzolon
	kívül sehol máshol ne lehessen
	használni ezt a jelszót, még a &man.su.1;
	paranccsal sem.  Például gondoskodjunk
	róla, hogy az <filename>/etc/ttys</filename>
	állományban megadott pszeudó
	terminálokat <quote>insecure</quote> (nem
	biztonságos) típusúnak
	állítottuk be, és így a
	<command>telnet</command> vagy az <command>rlogin</command>
	parancsokon keresztül nem lehet rendszergazdaként
	bejelentkezni.  Ha más szolgáltatáson
	keresztül jelentkezünk be, például az
	<application>sshd</application>
	segítségével, akkor ebben az esetben is
	gondoskodjunk róla, hogy 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étert
	átállítjuk a <literal>no</literal>
	értékre.  Vegyünk számba minden
	lehetséges hozzáférési módot
	&mdash; 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>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
	létrehozásukkor közvetlenül sose
	vegyük fel a <groupname>wheel</groupname> csoportba!  A
	személyzet tagjai elõször kerüljenek egy
	<groupname>staff</groupname> csoportba, és majd csak
	ezután az <filename>/etc/group</filename>
	állományon keresztül a
	<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
	például a Kerberost használjuk
	hitelesítésre, akkor megcsinálhatjuk azt
	is, hogy a Kerberos <filename>.k5login</filename>
	állományában engedélyezzük a
	&man.ksu.1; parancson keresztül a <username>root</username>
	hozzáférés elérését a
	<groupname>wheel</groupname> csoport alkalmazása
	nélkül.  Ez a megoldás talán
	még jobb is, mivel a <groupname>wheel</groupname>
	használata esetén a behatolónak még
	mindig lehetõsége van hozzájutni a
	<username>root</username>
	hozzáféréséhez olyankor, amikor a
	kezében van a jelszavakat tároló
	állomány és meg tudja szerezni a
	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 a
	legbiztonságosabb.</para>

      <para>A hozzáférések teljes körû
	letiltásához a &man.pw.8; parancsot érdemes
	használni:</para>

      <screen>&prompt.root; <userinput>pw lock <replaceable>személyzet</replaceable></userinput></screen>

      <para>Ezzel meg tudjuk akadályozni, hogy a
	felhasználó akármilyen módon,
	beleértve az &man.ssh.1; használatát is,
	hozzá tudjon férni a
	rendszerünkhöz.</para>

      <para>A hozzáférések
	blokkolásának másik ilyen módszere a
	titkosított jelszó átírása
	egyetlen <quote><literal>*</literal></quote> karakterre.  Mivel
	ez a karakter egyetlen titkosított jelszóra sem
	illeszkedik, ezért a felhasználó nem lesz
	képes bejelentkezni.  Ahogy például a
	személyzet alábbi tagja sem:</para>

      <programlisting>izemize:R9DT/Fa1/LV9U:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh</programlisting>

      <para>Erre cseréljük ki:</para>

      <programlisting>izemize:*:1000:1000::0:0:Ize-Mize:/home/izemize:/usr/local/bin/tcsh</programlisting>

      <para>Ezzel megakadályozzuk, hogy az
	<username>izemize</username> nevû felhasználó
	a hagyományos módszerekkel be tudjon jelentkezni.
	Ez a megoldás azonban a
	<application>Kerberos</application>t alkalmazó rendszerek
	esetén nem mûködik, illetve olyan helyezetekben
	sem, amikor a felhasználó az &man.ssh.1;
	paranccsal már létrehozott magának
	kulcsokat.</para>

      <para>Az ilyen védelmi mechanizmusok esetében 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>

      <indexterm><primary>KerberosIV</primary></indexterm>

      <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õ
	(például egy hónap) után
	változtasson jelszót.</para>

    </sect2>

    <sect2>
      <title>A rendszergazdai jogokkal futó szerverek és
	SUID/SGID engedélyekkel rendelkezõ programok
	védelme</title>

      <indexterm><primary><command>ntalk</command></primary></indexterm>
      <indexterm><primary><command>comsat</command></primary></indexterm>
      <indexterm><primary><command>finger</command></primary></indexterm>
      <indexterm><primary>járókák</primary></indexterm>
      <indexterm><primary><application>sshd</application></primary></indexterm>
      <indexterm><primary><application>telnetd</application></primary></indexterm>
      <indexterm><primary><application>rshd</application></primary></indexterm>
      <indexterm><primary><application>rlogind</application></primary></indexterm>

      <para>A bölcs rendszergazda mindig csak akkor futtat
	szervereket, amikor szüksége van rá, se
	többet, se kevesebbet.  Az egyéb
	fejlesztõktõl származó szerverekkel
	bánjunk különösen óvatosan, mivel
	gyakran hajlamosak hibákat tartalmazni.
	Például az <application>imapd</application> vagy a
	<application>popper</application> használata olyan,
	mintha az egész világnak ingyenjegyet
	osztogatnánk a rendszerünk <username>root</username>
	hozzáféréséhez.  Soha ne futtassunk
	olyan szervert, amelyet nem vizsgáltunk át
	kellõ alapossággal.  Sok szervert nem is
	feltétlenül kell <username>root</username>
	felhasználóként futtatni.
	Például az <application>ntalk</application>,
	<application>comsat</application> és
	<application>finger</application> démonok egy
	speciális
	<firstterm>járókában</firstterm> (sandbox)
	futnak.  Ezek a járókák sem teljesen
	tökéletesek, hacsak erre külön figyelmet
	nem fordítunk.  Ilyenkor a többvonalas
	védelem eszménye még mindig él: ha
	valakinek sikerült betörnie a
	járókába, akkor onnan ki is tud törni.
	Minél több védelmi vonalat húzunk a
	támadó elé, annál jobban
	csökken a sikerének
	valószínûsége.  A
	történelem során lényegében
	minden <username>root</username> jogokkal futó
	szerverben, beleértve az alapvetõ
	rendszerszintû szervereket is, találtak már
	biztonsági jellegû hibát.  Ha a
	gépünkre csak az <application>sshd</application>
	szolgáltatáson keresztül tudnak
	belépni, és soha nem használja senki a
	<application>telnetd</application>,
	<application>rshd</application> vagy
	<application>rlogind</application>
	szolgáltatásokat, akkor kapcsoljuk is ki
	ezeket!</para>

      <para>A &os; most már alapértelmezés szerint
	járókában futtatja az
	<application>ntalkd</application>,
	<application>comsat</application> és
	<application>finger</application>
	szolgáltatásokat.  Másik ilyen program,
	amely szintén esélyes lehet erre, az a
	&man.named.8;.  Az <filename>/etc/defaults/rc.conf</filename>
	megjegyzésben tartalmazza a
	<application>named</application> járókában
	futtatásához szükséges
	paramétereket.  Attól függõen, hogy egy
	új rendszert telepítünk vagy
	frissítjük a már meglévõ
	rendszerünket, a járókákhoz
	tartozó speciális felhasználói
	hozzáférések nem feltétlenül
	jönnek létre.  Amikor csak lehetséges, az
	elõrelátó rendszergazda
	kikísérletez és létrehoz ilyen
	járókákat.</para>

      <indexterm><primary><application>sendmail</application></primary></indexterm>

      <para>Vannak más olyan szerverek, amelyek tipikusan nem
	járókákban futnak.  Ilyen többek
	közt a <application>sendmail</application>,
	<application>popper</application>,
	<application>imapd</application>,
	<application>ftpd</application> és még sokan
	mások.  Léteznek rájuk
	alternatívák, de a telepítésük
	valószínûleg több munkát
	igényel, mint amennyit megérné
	számunkra veszõdni velük (és itt megint
	lesújt a kényelmi tényezõ).  Ezeket a
	szervereket többnyire <username>root</username>
	felhasználóként kell futtatnunk és a
	rajtuk keresztül érkezõ betörési
	kísérleteket más módokra
	támaszkodva kell észlelnünk.</para>

      <para>A <username>root</username> felhasználó
	keltette biztonsági rések másik nagy
	csoportja azok a végrehajtható
	állományok a rendszerben, amelyek a suid és
	sgid engedélyekkel rendelkeznek, futtatásuk
	rendszergazdai jogokkal történik.  Az ilyen
	binárisok többsége, mint
	például az <application>rlogin</application>, a
	<filename class="directory">/bin</filename> és <filename
	  class="directory">/sbin</filename>, <filename
	  class="directory">/usr/bin</filename> vagy <filename
	  class="directory">/usr/sbin</filename> könyvtárakban
	található meg.  Habár semmi sem
	biztonságos 100%-ig, a rendszerben
	alapértelmezetten suid és sgid engedéllyel
	rendelkezõ binárisok ebbõl a szempontból
	meglehetõsen megbízhatónak tekinhetõek.
	Alkalmanként azonban találnak a
	<username>root</username> felhasználót
	veszélyeztetõ lyukakat az ilyen binárisokban
	is.  Például 1998-ban az
	<literal>Xlib</literal>-ben volt egy olyan rendszergazdai
	szintû hiba, amellyel az <application>xterm</application>
	(ez általában suid engedéllyel rendelkezik)
	sebezhetõvé vált.  Mivel jobb félni,
	mint megijedni, ezért az elõretekintõ
	rendszergazda mindig igyekszik úgy csökkenteni az
	ilyen engedélyekkel rendelkezõ binárisok
	körét, hogy csak a személyzet tagjai legyenek
	képesek ezeket futtatni.  Ezt egy olyan speciális
	csoport létrehozásával oldhatjuk meg,
	amelyhez csak a személyzet tagjai férhetnek
	hozzá.  Az olyan suid binárisoktól pedig,
	amelyeket senki sem használ, igyekszik teljesen
	megszabadulni (<command>chmod 000</command>).  A monitorral nem
	rendelkezõ szervereknek általában nincs
	szükségük az <application>xterm</application>
	mûködtetésére.  Az sgid
	engedéllyel rendelkezõ binárisok is
	legalább ugyanennyire veszélyesek.  Ha a
	behatoló képes feltörni egy
	<groupname>kmem</groupname> csoporthoz tartozó sgid
	binárist, akkor képes lesz olvasni a
	<filename>/dev/kmem</filename> állomány
	tartalmát, ezáltal hozzájut a
	titkosított jelszavakhoz és így
	megszerezheti magának akármelyik
	hozzáférést.  Sõt, a
	<groupname>kmem</groupname> csoportot megszerzõ
	behatolók figyelni tudják a pszeudó
	terminálokon keresztül érkezõ
	billentyûleütéseket, még abban az
	esetben is, amikor a felhasználók
	egyébként biztonságos módszereket
	használnak.  A <groupname>tty</groupname> csoportot
	bezsebelõ támadók szinte bármelyik
	felhasználó termináljára
	képesek írni.  Ha a felhasználó
	valamilyen terminál programot vagy terminál
	emulátort használ a billentyûzet
	szimulációjával, akkor a behatoló
	tud olyan adatokat generálni, amivel a
	felhasználó nevében adhat ki
	parancsokat.</para>

    </sect2>

    <sect2 id="secure-users">
      <title>A felhasználói
	hozzáférések védelme</title>

      <para>A felhasználók
	hozzáféréseit szinte a legnehezebb
	megvédeni.  Míg a személyzet tagjaival
	szemben lehetünk kíméletlenül
	szigorúak és <quote>ki is csillagozhatjuk</quote>
	a jelszavukat, addig a felhasználók
	hozzáféréseivel
	általánosságban véve ezt nem
	tehetjük meg.  Ha a kezünkben van a megfelelõ
	mértékû irányítás, akkor
	még gyõzhetünk és kényelmesen
	biztonságba helyezethetjük a
	felhasználók
	hozzáférését.  Ha nincs, akkor nem
	tehetünk mást, mint állandóan
	õrködünk a hozzáférések
	felett.  Az ssh és Kerberos használata a
	felhasználók esetén sokkalta
	problematikusabb, mivel ilyenkor jóval több
	adminisztrációra és mûszaki
	segítségnyújtásra van
	szükség, de még mindig jobb megoldás a
	titkosított jelszavakhoz képest.</para>

    </sect2>

    <sect2>
      <title>A jelszavakat tároló állomány
	védelme</title>

      <para>Az a legbiztosabb, ha minél több jelszót
	kicsillagozunk és a hozzáférések
	hitelesítésére ssh-t vagy Kerberost
	használunk.  Igaz, a titkosított jelszavakat
	tároló állományt
	(<filename>/etc/spwd.db</filename>) csak a
	<username>root</username> képes olvasni, de a
	támadó meg tudja szerezni ezt a jogot még
	olyankor is, ha <username>root</username>
	felhasználóként nem feltétlenül
	tud írni.</para>

      <para>A rendszerünkben futó biztonsági
	szkripteknek a jelszavakat tároló
	állomány változását
	folyamatosan tudnia kell figyelnie és jelentie
	(lásd lentebb a <link linkend="security-integrity">Az
	állományok sértetlenségének
	ellenõrzése</link> címû
	fejezetet).</para>

    </sect2>

    <sect2>
      <title>A rendszermag belsejének, a nyers eszközök
	és az állományrendszerek
	védelme</title>

      <para>Ha a támadó megszerzi a
	<username>root</username>
	hozzáférését, akkor szinte
	bármit képes megtenni, de vannak bizonyos
	elõnyei.  Például a mostanság
	fejlesztett legtöbb rendszermag tartalmaz valamilyen
	beépített csomaglehallgatót, amit &os;
	alatt a <devicename>bpf</devicename> eszköz
	valósít meg.  A támadók szinte
	mindig megpróbálnak valamilyen
	csomaglehallgatót használni a feltört
	gépen.  A legtöbb rendszeren azonban nem kell
	feltétlenül megadnunk ezt az örömet,
	ezért nem is kell beépítenünk a
	rendszermagba a <devicename>bpf</devicename>
	eszközt.</para>

      <indexterm><primary><command>sysctl</command></primary></indexterm>

      <para>De ha még ki is iktatjuk a
	<devicename>bpf</devicename> eszközt, még
	aggódhatunk a <filename>/dev/mem</filename> és
	<filename>/dev/kmem</filename> miatt.  Egyébként
	ami azt illeti, a behatoló még így is
	képes írni a nyers eszközökre.
	Sõt, a rendszermagba képesek vagyunk modulokat is
	betölteni a &man.kldload.8; használatával.  A
	vállalkozó kedvû támadó a
	rendszermag moduljaként képes telepíteni
	és használni a saját
	<devicename>bpf</devicename> eszközét vagy
	bármilyen más, a csomagok
	lehallgatására alkalmas eszközt.  Az ilyen
	problémák elkerülése
	érdekében a rendszermagot a legmagasabb
	védelmi szinten kell üzemeltetni, tehát
	legalább egyes szinten.</para>

      <para>A rendszermag védelmi szintjét több
	különbözõ módon lehet
	állítani.  A védelmi szintet úgy
	lehet a legegyszerûbben növelni, ha a
	<command>sysctl</command> paranccsal beállítjuk a
	<varname>kern.securelevel</varname> nevû,
	rendszerszintû változó
	értékét:</para>

      <screen>&prompt.root; <userinput>sysctl kern.securelevel=<replaceable>1</replaceable></userinput></screen>

      <para>A &os; rendszermag alapértelmezés szerint a
	<literal>-1</literal> védelmi szinten indul.  Ez
	egészen addig <literal>-1</literal> marad, amíg a
	rendszergazda vagy valamelyik &man.init.8; során
	hívott rendszerindító szkript ezt meg nem
	változtatja.  A rendszer indítása
	során úgy tudjuk beállítani a
	megfelelõ védelmi szintet, ha az
	<filename>/etc/rc.conf</filename> állományban
	megadjuk a <varname>kern_securelevel_enable</varname>
	változót a <literal>YES</literal>
	értékkel, illetve
	<varname>kern_securelevel</varname>
	értékeként a kívánt
	védelmi szintet.</para>

      <para>A &os; alapértelmezett védelmi szintje
	közvetlenül a rendszerindító szkriptek
	lefutása után <literal>-1</literal>.  Ezt
	<quote>nem biztonságos módnak</quote> nevezik,
	mivel az állományok
	írásáért felelõs
	állományjelzõk nem feltétlenül
	mûködnek, mindegyik eszköz írható,
	olvasható és a többi.</para>

      <para>Miután a védelmi szintet <literal>1</literal>
	vagy annál magasabb értékre
	állítottuk, akkor a rendszer figyelembe veszi a
	csak hozzáfûzést (append-only) és
	módosíthatatlanságot (immutable)
	megszorító állományjelzõket,
	nem engedélyezi a tiltásukat és az
	eszközök közvetlenül nem
	érhetõek el.  A különbözõ
	védelmi szintek részletesebb
	bemutatását a &man.security.7; man oldalon
	olvashatjuk (vagy a &os; 7.0 elõtti változataiban a
	&man.init.8; man oldalon).</para>

      <note>
	<para>Az <literal>1</literal> és az afeletti
	  védelmi szinteken többek közt az X11 nem
	  feltétlenül lesz futtatható (mivel a
	  <filename>/dev/io</filename> eszköz elérése
	  blokkolt), illetve a rendszer frissítése is
	  akadályokba fog ütközni (a
	  <maketarget>installworld</maketarget> futtatása
	  során ideiglenesen ki kell kapcsolni az append-only
	  és immutable állományjelzõket).  Az
	  X11 esetében ezt valahogy még ki lehet
	  kerülni úgy, hogy ha az &man.xdm.1; démont
	  még a rendszerindítás elején
	  aktiváljuk (amikor a védelmi szint még
	  kellõen alacsony).  Az összes védelmi szint
	  és megszorítás esetén azonban nem
	  mindig adható ilyen jellegû javaslat, ezért
	  ilyenkor mindig érdemes elõre tervezni egy
	  keveset.  Emellett fontos alaposan megismerni a
	  különbözõ védelmi
	  megszorításokat, mivel jelentõs
	  mértékben visszafoghatják a rendszer
	  használhatóságát.  Ez segít
	  az adott helyzetben az egyszerûbb megoldást
	  választani és ezáltal elkerülni a
	  kellemetlen meglepetéseket.</para>
      </note>

      <para>Ha a rendszermag védelmi szintjét az
	<literal>1</literal> érték vagy afelé
	emeljük, akkor hasznos lehet a fontosabb
	(lényegében minden olyan programnak, amely a
	védelmi szint helyes
	beállítódása elõtt lefut)
	programoknak, könyvtáraknak és szkripteknek
	beállítani az <literal>schg</literal>
	állományjelzõt.  Ilyenkor azonban vegyük
	figyelembe, hogy a rendszer frissítése is
	nehezebbé válik a magasabb védelmi
	szinteken.  Egy mûködõképesebb
	megoldás lehet, ha rendszerünket egy magasabb
	védelmi szinten használjuk, de nem
	állítjuk be mindegyik rendszerszintû
	állományra az <literal>schg</literal>
	állományjelzõt.  Másik
	lehetõség még a <filename
	  class="directory">/</filename> és <filename
	  class="directory">/usr</filename> partíciók
	írásvédett csatlakoztatása.  Ne
	felejtsük el azonban, hogy ha túlságosan
	szigorúak vagyunk magunkhoz, akkor azzal egyúttal
	a behatolás észlelését is meg tudjuk
	nehezíteni!</para>
    </sect2>

    <sect2 id="security-integrity">
      <title>Az állományok
	sértetlenségének ellenõrzése:
	binárisok, konfigurációs
	állományok stb.</title>

      <para>Ha arról van szó, csak a legfontosabb
	rendszerszintû konfigurációs- és
	vezérlõállományokat tudjuk
	megvédeni, még mielõtt a korábban
	emlegetett kényelmi tényezõ kimutatná
	a foga fehérjét.  Például, ha a
	<command>chflags</command> paranccsal beállítjuk
	az <literal>schg</literal> állományjelzõt a
	<filename class="directory">/</filename> és <filename
	  class="directory">/usr</filename>
	állományrendszereken található
	legtöbb állományra, akkor az minden bizonnyal
	csökkenti a hatékonyságunkat, hiszen az
	állományok védelmének
	növekedésével csökken az
	észlelés lehetõsége.  A védelmi
	vonalaink közül ugyanis az utolsó talán
	az egyik legfontosabb &mdash; a detektálás.  A
	felépített biztonsági rendszerünk
	legnagyobb része szinte teljesen hasztalan (vagy ami
	még rosszabb, a biztonság hamis
	érzetét kelti), ha nem vagyunk képesek
	észrevenni a betörési
	kísérleteket.  A védelmi rendszer egyik
	részére nem a támadó
	megállításához, hanem a
	lelassításához van szükség,
	hogy így majd munka közben érhessük
	tetten.</para>

      <para>A betörés tényét legjobban a
	megváltozott, hiányzó vagy éppen
	váratlanul felbukkanó állományok
	utáni kutatással tudjuk felismerni.  A
	módosított állományokat
	általában egy másik (gyakran
	központosított) korlátozott
	hozzáférésû rendszerbõl
	ellenõrizhetjük a legjobban.  Fontos, hogy ha egy
	korlátozott hozzáférésû,
	kiemelten védett rendszeren írjuk a
	védelemért felelõs szkripteket, akkor azok
	szinte teljesen láthatlanok lesznek a
	támadó számára.  A legjobb
	kihasználás érdekében a
	korlátozott hozzáférésû
	gépnek jelentõs mértékû
	rálátással kell rendelkeznie az összes
	többi gépre, amit írásvédett
	NFS exportok vagy ssh kulcspárok
	felhasználásával érhetünk el.
	A hálózati forgalmat leszámítva az
	NFS látszik a legkevésbé &mdash;
	segítségével lényegében
	észrevétlenül tudjuk figyelni az egyes
	gépek állományrendszereit.  Ha a
	megfigyelésre használt szerver a kliensekhez
	switchen keresztül csatlakozik, akkor az NFS gyakran jobb
	választásnak bizonyul.  Ha a szerver hubon vagy
	több hálózati elemen keresztül
	éri el a megfigyelni kívánt klienseket,
	akkor az NFS nem eléggé biztonságos
	(és hatékony), ezért ilyen esetekben az ssh
	választása lehet a kedvezõ még az ssh
	által hagyott nyomokkal együtt is.</para>

      <para>Miután a korlátozott
	hozzáférésû gépünk
	legalább látja a hozzá tartozó
	kliensek rendszereit, el kell készítenünk a
	tényleges monitorozást végzõ
	szkripteket.  Ha NFS csatlakozást tételezünk
	fel, akkor az olyan egyszerû rendszereszközökkel,
	mint például a &man.find.1; és &man.md5.1;
	képesek vagyunk összerakni ezeket.  A szemmel
	tartott kliensek állományait naponta
	legalább egyszer érdemes ellenõrizni md5-tel,
	valamint még ennél gyakrabban is tesztelni az
	<filename class="directory">/etc</filename> és <filename
	  class="directory">/usr/local/etc</filename>
	könyvtárakban található
	konfigurációs és
	vezérlõállományokat.  Ha valamilyen
	eltérést tapasztal az ellenõrzést
	végzõ szerverünk és a rajta levõ
	md5 információk is helyesek, akkor
	értesítenie kell a rendszergazdát.  Egy
	jó védelmi szkript képes megkeresni az oda
	nem illõ suid binárisokat, valamint az új
	vagy törölt állományokat a <filename
	  class="directory">/</filename> és a <filename
	  class="directory">/usr</filename>
	partíciókon.</para>

      <para>A védelmi szkriptek megírása valamivel
	nehezebb feladat, ha ssh-t használunk az NFS helyett.  A
	futtatásukhoz a szkripteket és az általuk
	használt eszközöket (például
	find) az <command>scp</command> paranccsal
	lényegében át kell másolni a
	kliensekre, amivel így láthatóvá
	válnak.  Ne feledjük továbbá, hogy az
	<application>ssh</application> kliens már eleve
	feltört lehet.  Szó, ami szó, ha nem
	megbízható
	összeköttetésekrõl beszélünk,
	akkor az ssh használata elkerülhetetlen, de nem
	feltétlenül egyszerû.</para>

      <para>Egy jó védelmi szkript észreveszi a
	felhasználók és a személyzet
	tagjainak hozzáférését
	vezérlõ állományokban, mint
	például az <filename>.rhosts</filename>,
	<filename>.shosts</filename>,
	<filename>.ssh/authorized_keys</filename> és
	társaiban keletkezett változásokat is,
	amelyek esetleg elkerülhetik egy <literal>MD5</literal>
	alapú ellenõrzés figyelmét.</para>

      <para>Ha netalán órási mennyiségû
	tárterületettel rendelkeznénk, akkor
	eltarthat egy ideig, amíg végigsöprünk
	az összes partíció összes
	állományán.  Ebben az esetben
	érdemes olyan beállításokat megadni
	az állományrendszerek
	csatlakoztatásánál, amivel le tudjuk
	tiltani a suid engedéllyel rendelkezõ
	binárisok futtatását.  Ezzel kapcsolatban a
	&man.mount.8; parancs <literal>nosuid</literal>
	opcióját nézzük meg.  Hetente
	legalább egyszer azért mégis érdemes
	átnézni az ilyen partíciókat is,
	mivel ez a réteg a betörési
	kísérletek felderítésével
	foglalkozik, függetlenül a
	sikerességüktõl.</para>

      <para>A futó programok nyilvántartása
	(lásd &man.accton.8;) egy olyan viszonylag kevés
	költséggel járó lehetõség
	az operációs rendszerben, ami
	segítségünkre lehet a betörés
	utáni események
	kiértékelésében.
	Különösen hasznos olyankor, amikor
	megpróbáljuk modellezni, miképp is
	sikerült a támadónak bejutnia a
	rendszerünkbe, természetesen feltételezve,
	hogy az ehhez felhasznált feljegyzések a
	betörés után is érintetlenek
	maradtak.</para>

      <para>Végül a védelmet ellátó
	szkripteknek javasolt feldolgozni a
	naplóállományokat is, valamint a
	naplókat magukat is a lehetõ
	legbiztonságosabb formában generálni
	&mdash; ilyenkor nagyon hasznos lehet, ha egy távoli
	gépre naplózunk.  A behatoló
	megpróbálja majd eltüntetni a nyomait, a
	naplóállományok viszont nagyon fontosak a
	rendszergazda számára a betörési
	kísérletek idejének és
	módjának
	megállapításában.  A naplókat
	úgy tudjuk tartósan rögzíteni, ha a
	rendszerkonzol üzeneteit soros porton keresztül
	gyûjtjük össze a konzolok
	felügyeletéért felelõs
	biztonságos gépen.</para>

    </sect2>

    <sect2>
      <title>Állandó paranoia</title>

      <para>Egy kis paranoia sosem árt.  Elmondható, hogy
	a rendszergazda tetszõleges számú
	biztonsági intézkedéssel élhet
	egészen addig, amíg az nincs hatással a
	kényelmére, és a kényelmet
	<emphasis>befolyásoló</emphasis> biztonsági
	intézkedéseket pedig megfelelõ
	mérlegelés mellett tegye meg.  Ami még
	ennél is fontosabb, hogy mindig változtassunk
	valamit a biztonsági hálónkon &mdash; mivel
	ha egy az egyben követjük a dokumentumban
	leírtakat, akkor ezzel együtt kiadjuk a
	bejutás receptjét annak a leendõ
	támadónknak, aki szintén elolvasta
	ugyanezt.</para>

    </sect2>

    <sect2>
      <title>A szolgáltatások
	mûködésképtelenné
	tételét célzó
	támadások</title>

      <indexterm><primary>Denial of Service (DoS)</primary></indexterm>

      <para>Ez a szakasz a szolgáltatások
	mûködésképtelenségét
	elérni kívánó, más
	néven <quote>Denial of Service</quote>
	típusú támadásokkal foglalkozik.
	Noha nem tudunk túlságosan sokat tenni a
	manapság felbukkanó álcázott, a
	hálózatunk totális
	leterhelését célbavevõ
	támadások ellen, akadnak olyan
	általános érvényû
	eszközök, amelyekkel elejét vehetjük a
	szervereink szétbomzásának:</para>

      <orderedlist>
	<listitem>
	  <para>A létjövõ
	    szerverpéldányok
	    korlátozása.</para>
	</listitem>

	<listitem>
	  <para>Az ugródeszkaszerû támadások
	    (támadás ICMP-válasszal,
	    pingszórás stb.)
	    korlátozása.</para>
	</listitem>

	<listitem>
	  <para>A rendszermag útválasztási
	    gyorsítótárának
	    túlterhelése.</para>
	</listitem>
      </orderedlist>

      <para>A DoS támadások egyik jellemzõ
	sémája szerint egy sokszorozódni
	képes szervert támadnak meg, amelynek igyekeznek
	minél több példányát
	legyártatni, míg végül az ezt
	futtató rendszer ki nem fogy a
	memóriából,
	állományleíróból
	satöbbibõl és megállásra nem
	kényszerül.  Az <application>inetd</application>
	(lásd &man.inetd.8;) számos
	lehetõséget kínál fel ennek
	megakadályozására.  Ezzel kapcsolatban
	szeretnénk megjegyezni, hogy bár ezzel el tudjuk
	kerülni a gépünk
	leállását, semmilyen garanciát nem
	ad arra, hogy a szolgáltatás a
	támadás során is zavartalanul üzemel
	tovább.  Alaposan olvassuk el az
	<application>inetd</application> man oldalát és
	legyünk különös tekintettel a
	<option>-c</option>, <option>-C</option> és
	<option>-R</option> kapcsolóira.  Vigyázzunk, hogy
	az <application>inetd</application> <option>-C</option>
	kapcsolóját képesek kijátszani az
	álcázott IP-vel érkezõ
	támadások, ezért inkább az
	elõbbi kapcsolók valamilyen
	kombinációja az ajánlott.  Egyes
	szerverprogramoknál be lehet állítani a
	példányainak maximális
	számát.</para>

      <para>A <application>Sendmail</application> rendelkezik egy
	<option>-OMaxDaemonChildren</option>
	beállítással, ami a terhelésben
	levõ késleltetése miatt néha mintha
	jobban beválna, mint a
	<application>Sendmail</application>
	terheléskorlátozó paraméterei.  A
	<application>Sendmail</application> indításakor
	tehát a <literal>MaxDaemonChildren</literal>
	paramétert javasolt megadni egy olyan
	értékkel, amely elegendõ a
	<application>Sendmail</application> számára
	betervezett terhelés kiszolgálására,
	de még kevés ahhoz, hogy a
	<application>Sendmail</application> fûbe harapjon
	tõle.  Továbbá bölcs dolog a
	<application>Sendmail</application>t várakozási
	sorral (<option>-ODeliveryMode=queued</option>) és
	démonként (<command>sendmail -bd</command>),
	külön feldolgozási menetekkel
	(<command>sendmail -q15m</command>) futtatni.  Ha
	továbbra is valós idejû
	kézbesítést akarunk, akkor a
	feldolgozást kisebb idõközökkel is
	lefuttathatjuk (például <option>-q1m</option>), de
	arra <emphasis>mindig ügyeljünk</emphasis>, hogy a
	<literal>MaxDaemonChildren</literal>
	beállítása ne okozzon
	kaszkádosítási hibákat a
	<application>Sendmail</application>
	mûködésében.</para>

      <para>A <application>Syslogd</application> közvetlenül
	is támadható, ezért határozottan
	javasoljuk a <option>-s</option> használatát,
	amikor csak lehet, minden más esetben pedig a
	<option>-a</option> beállítást.</para>

      <para>Fordítsunk kellõ figyelmet a TCP kapcsolatok
	burkolását végzõ <application>TCP
	Wrapper</application> <quote>reverse-ident</quote>
	lehetõségére, ami szintén
	közvetlenül támadható.  Ebbõl az
	okból kifolyólag valószínûleg
	nem is akarjuk a <application>TCP Wrapper</application>
	által felkínált reverse-ident-et
	használni.</para>

      <para>Jól járunk el abban az esetben, ha a
	belsõ szolgáltatásainkat az
	útválasztóink mentén tûzfal
	segítségével védjük meg a
	külsõ hozzáféréstõl.  Ezzel
	lényegében a helyi hálózatunkat
	kívülrõl fenyegetõ támadások
	ellen védekezünk, de ez nem nyújt
	elegendõ védelmet a belsõ
	szolgáltatásaink esetén a
	<username>root</username> hozzáférés
	megszerzésére irányuló
	kísérletek ellen.  Mindig egy exkluzív,
	tehát zárt tûzfalat állítsunk
	be, vagyis <quote>tûzfalazzunk mindent
	<emphasis>kivéve</emphasis> az A, B, C, D és M-Z
	portokat</quote>.  Ezen a módon ki tudjuk szûrni az
	összes alacsonyabb portot, kivéve bizonyos eseteket,
	mint például a <application>named</application>
	(ha az adott zónában ez az elsõdleges
	gép), <application>ntalkd</application>,
	<application>sendmail</application> vagy más interneten
	keresztül elérhetõ
	szolgáltatásokat.  Ha másképpen
	állítjuk a tûzfalat &mdash; inkluzív,
	nyílt avagy megengedõ módon, akkor jó
	eséllyel elfelejtünk <quote>lezárni</quote>
	egy csomó szolgáltatást, vagy úgy
	adunk hozzá egy új belsõ
	szolgáltatást, hogy közben elfelejtjük
	frissíteni a tûzfalat.  Ennél még azon
	is jobb, ha a tûzfalon nyitunk egy magasabb
	portszámú tartományt, és ott
	valósítjuk meg ezt a megengedõ jellegû
	mûködést, az alacsonyabb portok
	veszélybe sodrása nélkül.  Vegyük
	azt is számításba, hogy a &os;-ben a
	kiosztott portokat dinamikusan állíthatjuk a
	<varname>net.inet.ip.portrange</varname> sysctl
	változókon keresztül (<command>sysctl -a |
	fgrep portrange</command>), ami nagyságrendekkel
	megkönnyíti a tûzfal
	beállítását.  Ennek megfelelõen
	például meg tudjuk adni, hogy a 4000-tõl
	5000-ig terjedõ porttartomány a 49152-tõl
	65535-ig húzódó tartományba
	kerüljön át, majd a 4000 alatti összes
	portot blokkoljuk (természetesen az internetrõl
	szándékosan hozzáférhetõ portok
	kivételével).</para>

      <para>A DoS támadások másik elterjedt
	fajtája az ún.  <quote>ugródeszka
	támadás</quote> &mdash; ilyenkor a szervert
	úgy próbálják túlterhelni,
	hogy folyamatosan válaszokat kérnek tõle a
	helyi hálózatról vagy egy másik
	számítógéprõl.  Az ilyen
	természetû támadások közül
	is a legnépszerûbb az <emphasis>ICMP
	pingszórásos támadás</emphasis>.  A
	támadó olyan ping csomagokat küld szét
	a helyi hálózaton, amelyek
	forrásának azt a gépet jelöli meg,
	amelyiket meg akarja támadni.  Ha a
	hálózatokat elválasztó
	útválasztók nem fogják meg a
	pingszórást, akkor a helyi
	hálózatról összes gépe
	nekilát válaszolgatni a meghamisított
	forrás címére, amivel így teljesen
	leterhelik az áldozatot.  Ez különösen
	akkor hatásos, amikor a támadó ugyanezt a
	trükköt eljátssza egyszerre több tucat
	különbözõ hálózatban is.  Az
	üzenetszórással járó
	támadások akár százhúsz
	megabitnyi forgalmat is képesek generálni
	másodpercenként.  A második legelterjedtebb
	ugródeszkás támadás az ICMP
	hiba-visszajelzési rendszere ellen irányul.
	Ilyenkor a támadó ICMP hibaüzeneteket
	kiváltó csomagok
	készítésével képes
	eltömíteni egy szerver bejövõ
	hálózati kapcsolatát és az ICMP
	válaszokkal pedig a szerver maga dugítja el a
	kimenõ hálózati kapcsolatát.  Ez a
	fajtájú támadás képes
	kinyomni az összes memóriát a szerverbõl
	és ezzel összeomlasztani, különösen
	olyankor, amikor a szerver nem tudja elég gyorsan
	elnyelni az általa generált ICMP
	válaszokat.  A <varname>net.inet.icmp.icmplim</varname>
	sysctl változóval tudunk gátat szabni a
	támadások ezen fajtájának.  Az
	ugródeszkás támadások utolsó
	nagyobb osztálya az <application>inetd</application>
	olyan szolgáltatásait szemeli ki, mint
	például az udp echo.  A támadó
	ilyenkor egyszerûen küld a helyi
	hálózatunkon található A és B
	szerverünknek egy olyan UDP csomagot, ahol
	forrásként az A szerver echo portját adja
	meg, célnak pedig a B szerver echo portját.
	Ezután a két szerver elkezdi egymás
	között passzolgatni ezt az egyetlen csomagot.  A
	támadó még több ilyen csomag
	befecskendezésével pillanatok alatt képes
	leterhelni a két szervert és helyi
	hálózatot.  Hasonló problémák
	vannak a belsõ <application>chargen</application>
	portjával is.  Egy hozzáértõ
	rendszergazda ezért kikapcsolja az összes ilyen
	inetd-alapú belsõ tesztelõ
	szolgáltatást.</para>

      <para>Az álcázott csomagok
	felhasználhatóak a rendszermag
	útválasztó
	gyorsítótárának
	túlterhelésére is.  Ezzel kapcsolatban
	nézzük meg a
	<varname>net.inet.ip.rtexpire</varname>,
	<varname>rtminexpire</varname> és
	<varname>rtmaxcache</varname> sysctl változókat.
	A véletlenszerû IP-címekkel megcímzett
	álcázott csomagok hatására a
	rendszermag létrehoz mindegyikõjükhöz egy
	ideiglenesen pufferelt utat az útválasztó
	táblázatában, amelyet a <command>netstat
	-rna | fgrep W3</command> paranccsal tudunk lekérdezni.
	Az ilyen útvonalak nagyjából 1600
	másodperc múlva elévülnek.  Ha a
	rendszermag észleli, hogy a
	gyorsítótárazott
	útválasztási táblázat
	mérete túlságosan megnövekedett, akkor
	automatikusan csökkenti az <varname>rtexpire</varname>
	értékét, de soha nem megy a
	<varname>rtminexpire</varname> alá.  Ebbõl
	két probléma adódik:</para>

      <orderedlist>
	<listitem>
	  <para>A rendszermag nem reagál elég gyorsan
	    amikor egy alig terhelt szervert hirtelen
	    megtámadnak.</para>
	</listitem>

	<listitem>
	  <para>Az <varname>rtminexpire</varname> nem elég kicsi
	    ahhoz, hogy a rendszermag túléljen egy
	    tartósabb rohamot.</para>
	</listitem>
      </orderedlist>

      <para>Ha a szervereink az internethez T3 (kb.  45 Mbit/s) vagy
	gyorsabb összeköttetésen keresztül
	csatlakoznak, akkor határozottan javasolt kézileg
	behangolni a &man.sysctl.8; segítségével az
	<varname>rtexpire</varname> és az
	<varname>rtminexpire</varname> értékeket.  Soha ne
	állítsuk egyiket sem nullára (hacsak nem
	akarjuk összeomlasztani a gépünket).  Ha
	például mind a kettõt 2 másodpercre
	állítjuk, akkor az többnyire elegendõ az
	útválasztási táblázat
	megvédéséhez.</para>

    </sect2>

    <sect2>
      <title>Hozzáférés Kerberosszal és
	SSH-val</title>

      <indexterm><primary><command>ssh</command></primary></indexterm>
      <indexterm><primary>KerberosIV</primary></indexterm>

      <para>Van néhány dolog, amit a Kerberos és az
	ssh esetén ajánlatos tisztázni,
	mielõtt használjuk ezeket.  A Kerberos&nbsp;5 egy
	kifogástalan hitelesítési protokoll.  A
	<application>telnet</application> és
	<application>rlogin</application> Kerberos által
	módosított változatában vannak olyan
	hibák, amelyek alkalmatlanná teszik ezeket a
	bináris adatfolyamok helyes kezelésére.
	Sõt, alapértelmezés szerint a Kerberos nem
	titkosítja a kapcsolatot, csak ha megadjuk neki a
	<option>-x</option> kapcsolót.  Az
	<application>ssh</application> alapértelmezés
	szerint mindent titkosít.</para>

      <para>Az ssh minden szempontból nagyon jól
	teljesít kivéve, hogy alapértelmezés
	szerint átküldi a kulcsokat is.  Ez azt jelenti,
	hogy ha van egy olyan biztonságos
	munkaállomásunk, ahol a rendszer többi
	részéhez tartozó kulcsainkat tartjuk
	és egy nem biztonságos gépre akarunk vele
	ssh-n keresztül belépni, akkor a kulcsaink
	használatóvá válnak.  A
	tényleges kulcsokat ugyan nem látja senki, de a
	bejelentkezés során az ssh megnyit egy
	közvetítéshez használt portot, amit a
	nem biztonságos gépen a támadó egy
	feltört <username>root</username>
	hozzáférés birtokában ki tud
	használni úgy, hogy a kulcsaink
	segítségével hozzá tudjon
	férni egy másik olyan géphez, amelyet a
	kulcsok nyitnak.</para>

      <para>Ha lehetséges, akkor a személyzet
	bejelentkeztetéséhez az ssh-t és Kerberost
	együttesen használjuk.  Az
	<application>ssh</application> lefordíható
	Kerberos támogatással.  Ezzel
	csökkentjük a potenciálisan
	kiszivárgó ssh kulcsok esélyét,
	miközben jelszavainkat a Kerberosszal védjük.
	Az ssh kulcsokat csak biztonságos gépekrõl
	és csak automatizált feladatok esetén
	használjuk (amire a Kerberos lényegében nem
	alkalmas).  Emellett javasoljuk azt is, hogy az ssh
	beállításai között tiltsuk le a
	kulcsok átküldését (key forwarding)
	vagy használjuk az <literal>from=IP/DOMAIN</literal>
	opciót, amivel az ssh csak a megadott
	gépekrõl engedi az
	<filename>authorized_keys</filename> állomány
	és a így benne levõ kulcsok
	használatát.</para>

    </sect2>
  </sect1>

  <sect1 id="crypt">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Bill</firstname>
	  <surname>Swingle</surname>
	  <contrib>Egyes részeit újraírta és
	    aktualizálta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>DES, Blowfish, MD5 és a Crypt</title>

    <indexterm>
      <primary>biztonság</primary>
      <secondary>crypt</secondary>
    </indexterm>

    <indexterm><primary>crypt</primary></indexterm>
    <indexterm><primary>Blowfish</primary></indexterm>
    <indexterm><primary>DES</primary></indexterm>
    <indexterm><primary>MD5</primary></indexterm>

    <para>Minden &unix; rendszer használójához
      tartozik egy jelszó is a
      hozzáféréséhez.  Teljesen
      nyilvánvalónak tûnik, hogy ezt a jelszót
      csak az adott felhasználó és az adott
      operációs rendszer ismeri.  A jelszavakat a titokban
      tartásukhoz ún.  <quote>csapóajtó
      függvényekkel</quote> titkosítják,
      amelyeket könnyû titkosítani, ám
      nehéz visszafejteni.  Tehát amit egy perccel
      ezelõtt még nyilvalónak tituláltunk, az
      mostanra már nem is teljesen igaz:
      <emphasis>valójában</emphasis> az
      operációs rendszer sem ismeri a jelszót.  Az
      operációs rendszer csak a jelszó
      <emphasis>titkosított</emphasis> változatát
      ismeri.  A jelszó <quote>titkosítatlan</quote>
      formáját csak nyers erõ
      igényebevételével tudjuk megkeresni az
      összes lehetséges jelszó
      szénakazlában.</para>

    <para>Sajnos, annak idején, amikor a jelszavak
      titkosítása bekerült a &unix;-ba, egyedül
      a DES, vagy más néven a Data Encryption Standard
      (Adattitkosítási szabvány) jött
      szóba.  Ez alapvetõen nem jelentett
      problémát az Egyesült Államok
      állampolgárai számára, de mivel a DES
      forráskódját nem lehetett kivinni az
      Egyesült Államokból, a &os;-nek találnia
      kellett valami olyasmit, ami mind megfelel az Egyesült
      Államok törvényeinek, mind pedig kompatibilis
      marad az összes többi DES-t használó
      &unix; variánssal.</para>

    <para>Ezt úgy oldották meg, hogy felosztották a
      titkosítással foglalkozó
      függvénykönyvtárakat, így az
      Egyesült Államokban élõ
      felhasználók tudtak DES könyvtárakat
      telepíteni és használni, miközben a
      többi nemzet felhasználói olyan más
      titkosítási módszert tudtak
      választani, amit kinn is lehetett alkalmazni.  Ennek
      tulajdonítható, hogy a &os;
      alapértelmezés szerint az MD5
      segítségével titkosít.  Az MD5-öt
      a DES-nél sokkalta biztonságosabbnak tartják,
      ezért a DES telepítésének
      lehetõségét leginkább csak
      kompatibilitási okokból ajánlották
      fel.</para>

    <sect2>
      <title>A titkosítási mechanizmus
	azonosítása</title>

      <para>Jelenleg a könyvtár ismeri a DES, MD5 és
	Blowfish függvényeit.  A &os; a jelszavak
	titkosításához alapból az
	MD5-öt használja.</para>

      <para>Nagyon könnyen meg tudjuk mondani, hogy a &os;
	éppen melyik titkosítási módszert
	alkalmazza.  Ennek egyik lehetõsége, ha az
	<filename>/etc/master.passwd</filename> állományt
	vizsgáljuk meg.  Az MD5 függvényével
	titkosított jelszavak hosszabbak, mint a DES
	függvényével titkosítottak és a
	<literal>&dollar;1&dollar;</literal> karakterekkel
	kezdõdnek.  A <literal>&dollar;2a&dollar;</literal>
	karakterekkel kezdõdõ jelszavakat Blowfish-sel
	titkosították.  A DES
	kódolású jelszavaknak nincs semmilyen
	különleges ismertetõjelük, de
	általánosságban elmondható
	róluk, hogy rövidebbek az MD5 jelszavaknál
	és olyan 64 karakteres ábécével
	kódolják ezeket, amelyek nem tartalmazzák a
	<literal>&dollar;</literal> karaktert, így tehát a
	viszonylag rövid, nem dollárjellel kezdõdõ
	karakterláncok minden bizonnyal DES
	kódolású jelszavak.</para>

      <para>Az új jelszavak kódolásához
	használt formátumot az
	<filename>/etc/login.conf</filename> állományban
	tárolt <literal>passwd_format</literal>
	bejelentkezési tulajdonság adja meg, amelynek
	értékei <literal>des</literal>,
	<literal>md5</literal> vagy <literal>blf</literal> lehetnek.  A
	&man.login.conf.5; man oldalon
	tájékozódhatunk bõvebben a
	bejelentkezési tulajdonságokról.</para>

    </sect2>
  </sect1>

  <sect1 id="one-time-passwords">
    <title>Egyszeri jelszavak</title>

    <indexterm><primary>egyszeri jelszavak</primary></indexterm>
    <indexterm>
      <primary>biztonság</primary>
      <secondary>egyszeri jelszavak</secondary>
    </indexterm>

    <para>A &os; alapértelmezés szerint támogatja
      az OPIE-t (One-time Passwords In Everything, azaz <quote>Egyszeri
      jelszavak mindenben</quote>), ami alapból az MD5
      függvényét használja.</para>

    <para>A jelszavak három fajtáját fogjuk a
      továbbiakban tárgyalni.  Az elsõ a megszokott
      &unix; stílusú avagy Kerberos jelszó.  Ezt a
      továbbiakban <quote>&unix; jelszónak</quote>
      nevezzük.  A második fajtában az OPIE
      &man.opiekey.1; nevû segédprogramja által
      generált és a bejelentkezésnél a
      &man.opiepasswd.1; által elfogadott jelszavak tartoznak.
      Ezeket <quote>egyszeri jelszavaknak</quote> fogjuk nevezni.  A
      jelszavak utolsó típusa az a titkos jelszó,
      amit az <command>opiekey</command> programnak (és
      néha a <command>opiepasswd</command> programnak) adunk meg,
      ami ebbõl egyszer használatos jelszavakat
      állít elõ.  Ezt innentõl <quote>titkos
      jelszónak</quote> vagy csak egyszerûen
      <quote>jelszónak</quote> hívjuk.</para>

    <para>A titkos jelszónak semmi köze sincs a &unix;
      jelszavunkhoz.  Természetesen megegyezhetnek, de ezt nem
      ajánljuk.  Az OPIE által használt titkos
      jelszavaknak nem kell a régi &unix; jelszavakhoz
      hasonlóan legfeljebb 8 karakteresnek lenniük
      <footnote>
	<para>&os; alatt a bejelentkezéshez használt
	  szabványos jelszavak akár 128 karakteresek is
	  lehetnek.</para>
      </footnote>, bármekkorát használhatunk.  A
      hat vagy hét szóból álló
      jelszavak ilyenkor igen gyakoriak.  Az OPIE jobbára a
      &unix; jelszórendszerétõl teljesen
      függetlenül mûködik.</para>

    <para>A jelszavak mellett két másik fajta adat fontos
      az OPIE számára.  Közülük az egyiket
      <quote>magnak</quote> vagy <quote>kulcsnak</quote> nevezik, ami
      két betûbõl és öt
      számjegybõl áll.  A másik az
      <quote>iterációk száma</quote>, ami egy 1
      és 100 közötti számot takar.  Az OPIE
      úgy hozza létre az egyszeri jelszavakat, hogy
      egymás után fûzi a magot és a titkos
      jelszót, majd az iterációk megadott
      számának megfelelõ mennyiségben
      kiszámolja rá az MD5 függvény
      értékét és az eredményt hat
      rövid angol szóba önti.  Ez a hat angol
      szó lesz a mi egyszeri jelszavunk.  A
      hitelesítéssel foglalkozó rendszer
      (elsõsorban a PAM) figyelemmel kíséri a
      legutoljára használt egyszeri jelszavunkat,
      és csak akkor engedi a felhasználót
      hitelesíteni, ha az általa megadott jelszó
      kódolt változata megegyezik az elõzõleg
      megadott jelszaváéval.  A csapóajtó
      függvények használata miatt lehetetlen
      legenerálni a következõ egyszeri jelszót,
      ha a sikerült megszereznünk az egyiket.  Az
      iterációk száma minden egyes sikeres
      bejelentkezés után csökken eggyel, amivel a
      felhasználót és a bejelentkeztetõ
      programot szinkronban tartja.  Amikor így az
      iterációk száma eléri az egyet, az
      OPIE-t újra kell inicializálni.</para>

    <para>Az említésre kerülõ rendszerek
      mindegyikéhez tartozik néhány program.  Az
      <command>opiekey</command> bekéri az
      iterációk számát, a magot és a
      titkos jelszót, majd elõállít egy
      egyszer használatos jelszót vagy azok folytonos
      listáját.  Az <command>opiepasswd</command> az OPIE
      inicializálásért, a jelszavak, az
      iterációk számának és a mag
      megváltoztatásáért felelõs.
      Egyaránt elfogad titkos jelmondatot,
      iterációs számot vagy magot és egy
      egyszeri jelszót.  Az <command>opieinfo</command>
      megvizsgálja a felhasználókra
      vonatkozó adatbázist
      (<filename>/etc/opiekeys</filename>) és kiírja az
      adott felhasználó által használt
      iterációs számot és magot.</para>

    <para>Négyféle különbözõ
      mûveletrõl fogunk most itt beszélni.  Az
      elsõben egy biztonságos kapcsolaton keresztül
      elsõként inicializáljuk az egyszeri
      jelszavakat, vagy megváltoztatjuk a jelszót vagy a
      magot az <command>opiepasswd</command>
      segítségével.  A második
      mûveletben ugyanarra adjuk ki az
      <command>opiepasswd</command> parancsot egy nem biztonságos
      kapcsolaton keresztül az <command>opiekey</command>
      paranccsal együtt egy biztonságos kapcsolaton
      keresztül.  A harmadikban az <command>opiekey</command>
      használatával nem biztonságos kapcsolaton
      keresztül jelentkezünk be.  A negyedikben az
      <command>opiekey</command> paranccsal létrehozunk egy adott
      mennyiségû kulcsot, amelyeket aztán
      leírhatunk vagy kinyomtathatunk, hogy magunkkal tudjuk
      vinni olyan helyre, ahonnan nem tudnk biztonságos
      módon csatlakozni.</para>

    <sect2>
      <title>Inicializálás biztonságos
	kapcsolattal</title>

      <para>Az OPIE elsõ inicializálásához
	adjuk ki az <command>opiepasswd</command> parancsot:</para>

      <screen>&prompt.user; <userinput>opiepasswd -c</userinput>
[grimreaper] ~ $ opiepasswd -f -c
Adding unfurl:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:
ID unfurl OTP key is 499 to4268
MOS MALL GOAT ARM AVID COED
</screen>

      <para>A figyelmeztetés fordítása:</para>

      <screen>Ezt a módszert csak konzolról alkalmazzuk, SOHA ne távoli kapcsolaton
keresztül!  Ha telnetet, xtermet vagy betárcsázós kapcsolatot használunk, akkor
azonnal nyomjunk ^C-t vagy ne adjunk meg jelszót.</screen>

      <para>Az <prompt>Enter new secret pass phrase:</prompt> vagy
	<prompt>Enter secret password:</prompt> kérdések
	után adjunk meg egy jelmondatot, illetve jelszót.
	Ne felejtsük el, hogy ez nem bejelentkezéshez
	használt jelszó lesz, hanem ebbõl jönnek
	majd létre az egyszeri kulcsaink.  Az <quote>ID</quote>
	sor adja meg az aktuális példányunk
	paramétereit: a bejelentkezéshez használt
	nevünket, az iterációk számát
	és a magot.  Amikor a bejelentkezések során
	a rendszer emlékszik a paraméterekre és
	megjeleníti ezeket, nem kell megjegyeznünk.  Az
	utolsó sor adja meg a paramétereinknek és a
	titkos jelszavunknak megfelelõ egyszeri jelszót.  Ha
	most azonnal akarnánk bejelentkezni, akkor ezt az
	egyszeri jelszót kellene hozzá
	használnunk.</para>

    </sect2>

    <sect2>
      <title>Inicializálás nem biztonságos
	kapcsolattal</title>

      <para>Ha egy nem biztonságos kapcsolaton keresztül
	akarjuk inicializálni vagy megváltoztatni a
	jelszavunkat, akkor szükségünk lesz valahol egy
	megbízható kapcsolatra, ahol le tudjuk futtatni az
	<command>opiekey</command> parancsot.  Ez lehet egy
	számunkra biztonsági szempontból
	elfogadható gép parancssora.  Emellett ki kell
	találnunk egy iterációs számot (erre
	a 100 egy jó választás) és adnunk
	egy magot vagy használni egy véletlenszerûen
	generáltat.  Az inicializálás
	színtere felé vezetõ nem biztonságos
	kapcsolaton keresztül adjuk ki az
	<command>opiepasswd</command> parancsot:</para>

      <screen>&prompt.user; <userinput>opiepasswd</userinput>

Updating unfurl:
You need the response from an OTP generator.
Old secret pass phrase:
        otp-md5 498 to4268 ext
        Response: GAME GAG WELT OUT DOWN CHAT
New secret pass phrase:
        otp-md5 499 to4269
        Response: LINE PAP MILK NELL BUOY TROY

ID mark OTP key is 499 gr4269
LINE PAP MILK NELL BUOY TROY
</screen>

      <para>Az alapértelmezett mag elfogadásához
	nyomjuk le a <keycap>Return</keycap> billentyût.
	Mielõtt megadnánk a hozzáférés
	jelszavát, menjünk át a biztonságos
	kapcsolatra és adjuk meg neki ugyanezeket a
	paramétereket:</para>

      <screen>&prompt.user; <userinput>opiekey 498 to4268</userinput>
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT
</screen>

      <para>Most váltsunk vissza a nem biztonságos
	kapcsolatra és másoljuk be az így
	generált egyszeri jelszót a megfelelõ
	programba.</para>

    </sect2>

    <sect2>
      <title>Egyetlen egyszeri jelszó
	létrehozása</title>

      <para>Miután sikeresen inicializáltuk az OPIE-t
	és bejelentkezünk, a következõket
	láthatjuk:</para>

<screen>&prompt.user; <userinput>telnet example.com</userinput>
Trying 10.0.0.1...
Connected to example.com
Escape character is '^]'.

FreeBSD/i386 (example.com) (ttypa)

login: <userinput><replaceable>felhasználói_név</replaceable></userinput>
otp-md5 498 gr4269 ext
Password: </screen>

      <para>Mellékesen megjegyezzük, hogy az OPIE
	paranccsorának van egy (itt nem látható)
	hasznos képessége: ha <keycap>Return</keycap>
	billentyût nyomunk a jelszó
	bekérésekor, akkor a program megmutatja a
	begépelt betûket, így láthatjuk
	pontosan mit is írunk be.  Ez nagyon kényelmes
	lehet olyankor, amikor valahonnan, például egy
	lapról olvassuk a jelszót.</para>

      <indexterm><primary>MS-DOS</primary></indexterm>
      <indexterm><primary>Windows</primary></indexterm>
      <indexterm><primary>MacOS</primary></indexterm>

      <para>A bejelentkezéshez ekkor le kell valahogy
	generálnunk az egyszeri jelszavunkat.  Ezt egy
	megbízható rendszeresen tudjuk megtenni az
	<command>opiekey</command> lefuttatásával.  (Ennek
	vannak DOS-os, &windows;-os és &macos;-es
	változatai is.) Paraméterként az
	iterációs számot és a magot kell
	megadnunk.  Ezt akár közvetlenül át is
	másolhatjuk annak a gépnek a bejelentkezési
	képernyõjérõl, ahova be akarunk
	jelentkezni.</para>

      <para>A megbízható rendszeren tehát:</para>

      <screen>&prompt.user; <userinput>opiekey 498 to4268</userinput>
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT</screen>

      <para>Most már megvan a bejelentkezéshez
	szükséges egyszeri jelszavunk.</para>

    </sect2>

    <sect2>
      <title>Több egyszeri jelszó
	létrehozása</title>

      <para>Néha olyan helyekre kell mennünk, ahol se egy
	megbízható gép, sem pedig
	biztonságos kapcsolat nem található.  Ilyen
	esetekben megadhatjuk az <command>opiekey</command> parancsnak,
	hogy elõre gyártson le több egyszer
	használatos jelszót, amit késõbb
	aztán ki tudunk nyomtatni.  Például:</para>

      <screen>&prompt.user; <userinput>opiekey -n 5 30 zz99999</userinput>
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase: <userinput>&lt;secret password&gt;</userinput>
26: JOAN BORE FOSS DES NAY QUIT
27: LATE BIAS SLAY FOLK MUCH TRIG
28: SALT TIN ANTI LOON NEAL USE
29: RIO ODIN GO BYE FURY TIC
30: GREW JIVE SAN GIRD BOIL PHI</screen>

      <para>Az <option>-n 5</option> öt kulcsot kér
	egymás után, a <option>30</option> pedig megadja
	az utolsó iterációs számot.
	Vegyük észre, hogy a kulcsokat a
	felhasználás sorrendjével
	<emphasis>ellentétes</emphasis> sorrendben írja ki
	a program.  Ha igazán paranoiások vagyunk, akkor
	írjuk le kézzel a jelszavakat.  Ha viszont annyira
	nem, akkor egyszerûen küldjük át ezeket az
	<command>lpr</command> parancsnak.  Megfigyelhetjük, hogy
	minden sorban látható az iterációs
	szám és a hozzá tartozó egyszeri
	jelszó.  Hasznos lehet a felhasználás
	szerinti felírni a jelszavakat.</para>

    </sect2>

    <sect2>
      <title>A &unix; jelszavak használatának
	leszûkítése</title>

      <para>Az OPIE képes a bejelentkezéshez
	használt IP-címek alapján
	leszûkíteni a &unix; jelszavak
	használatát.  Ehhez az
	<filename>/etc/opieaccess</filename> használható,
	amely alapból megtalálható a
	rendszerünkön.  Az &man.opieaccess.5; man
	oldalán találhatjuk meg a rá
	vonatkozó információkat és az
	összes vele kapcsolatos biztonsági
	megfontolást.</para>

      <para>Íme egy példa az
	<filename>opieaccess</filename> állományra:</para>

      <programlisting>permit 192.168.0.0 255.255.0.0</programlisting>

      <para>Ezzel a sorral megengedjük a &unix; jelszavak
	használatát minden olyan felhasználó
	számára, akinek az IP-je illeszkedik a megadott
	címre és maszkra (ez viszont
	álcázással
	kijátszható).</para>

      <para>Ha az <filename>opieaccess</filename>
	állományból egyetlen szabály sem
	illeszkedik, akkor alapértelmezés szerint nem
	engedélyezettek a nem OPIE típusú
	jelszavak.</para>

    </sect2>
  </sect1>

  <sect1 id="tcpwrappers">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>A TCP kapcsolatok burkolása</title>

    <indexterm><primary>TCP burkolók</primary></indexterm>

    <para>Aki ismeri az &man.inetd.8; programot, az már biztosan
      hallott a <acronym>TCP</acronym> kapcsolatok
      burkolásáról, eredeti nevén a a
      <acronym>TCP</acronym> wrapperekrõl.  Azonban csak kevesek
      képesek felfogni ezek valódi hasznát.
      Úgy néz ki, mindenki csak tûzfalakon
      keresztül akarja megoldani a hálózati
      kapcsolatot kezelését.  Habár a
      tûzfalakat sok mindenre fel lehet ugyan használni,
      egyetlen tûzfal nem képes például
      szövegesen válaszolni a kapcsolatok
      kezdeményezõinek.  Ellenben bármelyik
      <acronym>TCP</acronym>-wrapper szoftver képes erre,
      sõt még többre is.  A következõ
      néhány szakaszban szemügyre vesszük a
      <acronym>TCP</acronym> wrapperek számos
      lehetõségét, és ahol lehetséges,
      ott konfigurációs állományokkal is
      illusztráljuk ezek használatát.</para>

    <para>A <acronym>TCP</acronym> burkoló szoftverek
      kiterjesztik az <application>inetd</application>
      képességeit minden alatta dolgozó
      szerverdémon támogatására.  Ezzel a
      módszerrel meg lehet oldani a naplózást,
      üzenetek küldését a kapcsolatokhoz, a
      démonok elérhetõségének
      korlátozását stb.  Noha ezen
      lehetõségek közül néhány
      tûzfallal is megvalósítható, ezzel nem
      csupán egy további védelmi réteget
      húzunk fel a rendszerünk köré, hanem
      túllépjük mindazt, amit egy tûzfallal
      irányítani lehet.</para>

    <para>A <acronym>TCP</acronym> burkolók
      használatával hozzáadott
      funkcionalitás azonban nem helyettesít egy jó
      tûzfalat.  A <acronym>TCP</acronym> kapcsolatok
      burkolását tûzfallal vagy más
      egyéb biztonsági megoldással együtt
      tudjuk csak eredményesen használni, viszont a
      rendszerünk biztonságában egy újabb
      remek védelmi vonalat képvisel.</para>

    <para>Mivel lényegében ez az
      <application>inetd</application>
      beállításának
      kibõvítése, ezért a szakasz
      elolvasásához feltételezzük az <link
	linkend="network-inetd">inetd beállításával</link>
      kapcsolatos tudnivalók ismeretét.</para>

    <note>
      <para>Bár az &man.inetd.8; által indított
	programok nem egészen tekinthetõen
	<quote>démonoknak</quote>, hagyományosan
	démonnak hívják ezeket.  Ezért
	rájuk ebben a szakaszban is ezt a kifejezést
	használjuk.</para>
    </note>

    <sect2>
      <title>Kezdeti beállítások</title>

      <para>&os; alatt a <acronym>TCP</acronym> burkolók
	használatának egyetlen feltétele
	csupán annyi, hogy az <application>inetd</application>
	parancsot a <option>-Ww</option> paraméterrel
	indítsuk az <filename>rc.conf</filename>
	állományból.  Az egyébként az
	alapbeállítás.  Természetesen nem
	árt, ha helyesen állítjuk be az
	<filename>/etc/hosts.allow</filename> állományt
	is, ellenkezõ esetben a &man.syslogd.8;
	egyébként dobálni fogja errõl az
	üzeneteket.</para>

      <note>
	<para>Eltérõen a <acronym>TCP</acronym>
	  burkolók egyéb
	  implementációitól, a
	  <filename>hosts.deny</filename> állományt itt
	  már nem használjuk.  Minden
	  beállítást az
	  <filename>/etc/host.allow</filename> állományba
	  kell raknunk.</para>
      </note>

      <para>A legegyszerûbb konfiguráció
	esetén a démonok
	kapcsolódását egyszerûen
	engedélyezhetjük vagy letilthatjuk az
	<filename>/etc/hosts.allow</filename> állományban
	szereplõ beállításokkal.  A &os;
	alapértelmezett beállításai szerint
	minden <application>inetd</application> által
	indított démonhoz lehet kapcsolódni.  Ennek
	megváltoztatásával az
	alapkonfiguráció áttekintése
	után foglalkozunk.</para>

      <para>Az alapkonfiguráció általában
	<literal>démon : cím : cselekvés</literal>
	alakú.  Itt a <literal>démon</literal> egy olyan
	démonra utal, amelyet az <command>inetd</command>
	indított el.  A <literal>cím</literal> egy
	érvényes hálózati név,
	IP-cím vagy szögletes zárójelek
	([&nbsp;]) között megadott IPv6
	formátumú cím.  A cselekvést
	tartalmazó mezõ (<literal>action</literal>) lehet
	<literal>allow</literal> vagy <literal>deny</literal> annak
	megfelelõen, hogy engedélyezzük vagy tiltjuk a
	megadott címrõl a csatlakozást.  Nem szabad
	elfelejtenünk, hogy az így megadott
	beállítások közül mindig az
	elsõként illeszkedõ
	érvényesül, ami arra utal, hogy a
	konfigurációs állományban
	szereplõ szabályok egymás után
	növekvõ sorrendben értékelõdnek ki.
	Ha valamelyikük illeszkedik, akkor a keresés
	megáll.</para>

      <para>Rengeteg egyéb opció is megadható
	még, de ezekrõl csak a késõbbi
	szakaszokban fogunk szólni.  Egy egyszerû
	konfigurációs állomány már
	ennyi információból is
	könnyedén összeállítható.
	Például, ha engedélyezni szeretnénk
	a <acronym>POP</acronym>3 kapcsolatokat a <filename
	role="package">mail/qpopper</filename> démonon
	keresztül, akkor a következõ sorral kell
	kiegészítenünk a
	<filename>hosts.allow</filename> állományt:</para>

      <programlisting># Ez a sor kell a POP3 kapcsolatokhoz:
qpopper : ALL : allow</programlisting>

      <para>Miután hozzáadtuk ezt a sort, az
	<application>inetd</application> szervert újra kell
	indítanunk.  Ezt vagy a &man.kill.1; paranccsal, vagy
	pedig az <filename>/etc/rc.d/inetd</filename> szkript
	<parameter>restart</parameter> paraméterével
	tehetjük meg.</para>

    </sect2>

    <sect2>
      <title>Komolyabb beállítások</title>

      <para>A <acronym>TCP</acronym> kapcsolatok
	burkolásánál is meg lehet adni
	további opciókat.
	Segítségükkel még jobban
	irányítani tudjuk a kapcsolatok
	kezelésének módját.
	Néhány esetben az is hasznos lehet, ha
	küldünk valamilyen választ az egyes
	gépeknek vagy démonoknak.  Máskor
	szükségünk lehet a csatlakozások
	naplózására vagy e-mailen keresztüli
	jelzésére a rendszergazda felé.  Teljesen
	más helyezetekben csak a helyi
	hálózatunkról engedjük meg a
	csatlakozást.  Ez mind lehetséges a
	<literal>helyettesítõ jelekként</literal>
	ismert beállítási opciók,
	kiterjesztõ karakterek és külsõ parancsok
	végrehajtásának
	használatával.  A következõ két
	szakasz az ilyen és ehhez hasonló
	szituációk megoldására
	íródott.</para>

      <sect3>
	<title>Külsõ parancsok</title>

	<para>Tegyük fel, hogy olyan helyezetben vagyunk, amikor a
	  kapcsolatot tiltani akarjuk, de közben azért
	  szeretnénk errõl értesíteni a
	  kapcsolatot kezdeményezõ felet is.  Hogyan tudjuk
	  ezt megcsinálni?  Ezt a <option>twist</option>
	  nevû opcióval tehetjük meg.  Amikor
	  megpróbál valaki csatlakozni, akkor a
	  <option>twist</option> hívódik meg és
	  végrehajt egy megadott parancsot vagy szkriptet.  Erre
	  találunk is egy példát a
	  <filename>hosts.allow</filename>
	  állományban:</para>

	<programlisting># The rest of the daemons are protected.
ALL : ALL \
        : severity auth.info \
        : twist /bin/echo "You are not welcome to use %d from %h."</programlisting>

	<para>Ez a példa a következõ üzenetet
	  jeleníti meg: <quote>You are not allowd to use
	  <literal>a démon neve</literal> from
	  <literal>hálózati név</literal>.</quote>
	  (Jelentése: <quote>A <literal>démon
	  neve</literal> démont nem érheti el a
	  <literal>hálózati név</literal>
	  helyrõl!</quote>) Ez minden olyan démon
	  esetén megjelenik, amirõl nem nyilatkoztunk
	  korábban az állományban.  Ezzel nagyon
	  könnyen vissza tudunk küldeni egy választ a
	  kapcsolat kezdményezõje felé, miután
	  a kapcsolatot eldobtuk.  Vegyük észre, hogy a
	  visszaküldendõ üzenetet <literal>"</literal>
	  karakterek közé <emphasis>kell</emphasis>
	  tennünk, ez alól semmi sem kivétel.</para>

	<warning>
	  <para>DoS támadást lehet elõidézni
	    azzal, ha egy támadó vagy
	    támadók egy csoportja csatlakozási
	    kérelmekkel kezdi el bombázni a
	    démonainkat.</para>
	</warning>

	<para>Ilyen esetekben használhatjuk a
	  <option>spawn</option> opciót is.  A
	  <option>spawn</option> a <option>twist</option>
	  opcióhoz hasonlóan implicit módon tiltja
	  a kapcsolódást és arra
	  használható, hogy lefuttassunk vele egy
	  parancsot vagy szkriptet.  A <option>spawn</option> azonban a
	  <option>twist</option> opciótól
	  eltérõen nem küld vissza semmilyen
	  választ a kapcsolatot létrehozni
	  kívánó egyénnek.  Ehhez
	  példaként vegyük a következõ sort
	  a konfigurációs
	  állományban:</para>

	<programlisting># We do not allow connections from example.com:
ALL : .example.com \
	: spawn (/bin/echo %a from %h attempted to access %d &gt;&gt; \
	  /var/log/connections.log) \
	: deny</programlisting>

	<para>Ezzel a <hostid role="fqdn">*.example.com</hostid>
	  címtartományból érkezõ
	  összes kapcsolódási kísérlet
	  sikertelen lesz, miközben ezzel egyidõben a
	  <filename>/var/log/connections.log</filename>
	  állományba rögzítjük a
	  csatlakozni akaró egyén hálózati
	  nevét, <acronym>IP</acronym>-címét
	  és a démont.</para>

	<para>A korábban már kifejtett
	  helyettesítõ karakterek túl, mint
	  például az <literal>%a</literal>, még
	  léteznek továbbiak is.  Róluk a
	  &man.hosts.access.5; man oldalon találhatjuk meg a
	  teljes listát.</para>

      </sect3>

      <sect3>
	<title>Helyettesítõ jelek</title>

	<para>Az eddigi példákban folyamatosan csak az
	  <literal>ALL</literal> opciót adtuk meg.  Azonban rajta
	  kívûl léteznek mások is, amivel a
	  megoldás funkcionalitását még egy
	  kicsivel tovább növelhetjük.
	  Például az <literal>ALL</literal>
	  használható egy démon, egy
	  tartomány vagy egy <acronym>IP</acronym>-cím
	  illesztésére.  A másik ilyen
	  helyettesítõ jel a <literal>PARANOID</literal>,
	  amelyet olyan gépek
	  <acronym>IP</acronym>-címének
	  illesztésekor alkalmazhatunk, ami
	  feltételezhetõen hamis.  Más szóval
	  a <literal>PARANOID</literal> olyan cselekvések
	  megadását teszi lehetõvé, amelyek
	  akkor hajtódnak végre, amikor a kapcsolatot
	  létrehozó gép
	  <acronym>IP</acronym>-címe eltér a
	  hálózati nevétõl.  A most
	  következõ példa
	  valószínûleg segít fényt
	  deríteni ennek lényegére:</para>

	<programlisting># Block possibly spoofed requests to sendmail:
sendmail : PARANOID : deny</programlisting>

	<para>A példában minden olyan
	  kapcsolatkérést elutasítunk, ami a
	  <command>sendmail</command> felé a
	  hálózati névtõl eltérõ
	  <acronym>IP</acronym>-címrõl
	  irányul.</para>

	<caution>
	  <para>Ha rossz <acronym>DNS</acronym>
	    beállításokat használunk, a
	    <literal>PARANOID</literal> megadásával
	    súlyosan mozgásképtelenné
	    tehetjük a kliensünket vagy szerverünket.
	    Ezért legyünk óvatosak vele!</para>
	</caution>

	<para>A helyettesítõ jelekrõl és
	  hozzájuk tartozó további
	  lehetõségekrõl a &man.hosts.access.5; man
	  oldalon tájékozódhatunk.</para>

	<para>A <filename>hosts.allow</filename>
	  állományból ki kell venni az elsõ
	  sort ahhoz, hogy bármilyen egyéb
	  konfigurációs beállítás
	  mûködõképes legyen.  Ezt
	  említettük a szakasz elején is.</para>

      </sect3>
    </sect2>
  </sect1>

  <sect1 id="kerberosIV">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Mark</firstname>
	  <surname>Murray</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Mark</firstname>
	  <surname>Dapoz</surname>
	  <contrib>Eredetileg írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title><application>KerberosIV</application></title>

    <para>A Kerberos egy olyan járulékos
      rendszer/protokoll, amellyel a felhasználók egy
      biztonságos szerver szolgáltatásain
      keresztül tudják hitelesíteni magukat.  Ilyen
      szolgáltatás többek közt a távoli
      bejelentkezés, távoli másolás, a
      rendszeren belüli biztonságos másolás
      és minden olyan egyéb veszélyes feladat, amit
      számottevõen megbízhatóbbá
      és irányíthatóbbá
      tettek.</para>

    <para>A következõ utasítások a &os;-hez
      mellékelt Kerberos
      beállításához adnak
      útmutatást.  A teljes leíráshoz
      azonban érdemes fellapoznunk a menet közben
      hivatkozott man oldalakat is.</para>

    <sect2>
      <title>A <application>KerberosIV</application>
	telepítése</title>

      <indexterm><primary>MIT</primary></indexterm>
      <indexterm>
	<primary>KerberosIV</primary>
	<secondary>telepítés</secondary>
      </indexterm>

      <para>A Kerberos a &os; egyik választható
	komponense.  Legkönnyebben úgy tudjuk
	feltelepíteni, ha a &os; telepítése
	során a <application>sysinstall</application> programban
	kiválasztjuk a <literal>krb4</literal> vagy
	<literal>krb5</literal> terjesztések valamelyikét.
	Ezzel felrakhatjuk a Kerberos <quote>eBones</quote> (KerberosIV)
	vagy <quote>Heimdal</quote> (Kerberos5) elnevezésû
	változatait.  A &os; azért tartalmazza ezeket az
	implementációkat, mert nem az Amerikai
	Egyesült Államokban vagy Kanadában
	fejlesztették, így az Egyesült Államok
	titkosításokkal kapcsolatos kiviteli
	korlátozások korában minden olyan rendszer
	adminisztrátora el tudta érni, aki nem ezekben az
	országokban lakott.</para>

      <para>A Kerberos MIT által fejlesztett
	implementációját egyébként a
	Portgyûjteménybõl a <filename
	role="package">security/krb5</filename> porton keresztül
	érhetjük el.</para>

    </sect2>

    <sect2>
      <title>A kezdeti adatbázis
	létrehozása</title>

      <para>Ezt a lépést csak a Kerberos szerveren kell
	elvégezni.  Elõször is
	gyõzõdjünk meg róla, hogy semmilyen
	korábbi Kerberos adatbázis nem
	található a gépen.  Váltsunk az
	<filename class="directory">/etc/kerberosIV</filename>
	könyvtárra és ellenõrizzük a
	következõ állományok
	meglétét:</para>

      <screen>&prompt.root; <userinput>cd /etc/kerberosIV</userinput>
&prompt.root; <userinput>ls</userinput>
README		krb.conf        krb.realms</screen>

      <para>Ha rajtuk kívül további
	állományok is feltûnnének (mint
	például a <filename>principal.*</filename> vagy
	<filename>master_key</filename>), akkor a
	<command>kdb_destroy</command> paranccsal pusztítsuk el a
	régi Kerberos adatbázist, vagy ha nem fut
	már a Kerberos, akkor egyszerûen csak
	törüljük le ezeket.</para>

      <para>Ezután lássunk neki a
	<filename>krb.conf</filename> és
	<filename>krb.realms</filename> állományok
	átírásán keresztül a Kerberos
	egyes övezeteinek (realm)
	létrehozásához.  Itt most az
	<literal>EXAMPLE.COM</literal> lesz a létrehozandó
	övezet, a hozzá tartozó szerver pedig a
	<hostid role="fqdn">grunt.example.com</hostid>.  Így
	szerkesszük át vagy készítsünk el
	a neki megfelelõ <filename>krb.conf</filename>
	állományt:</para>

      <screen>&prompt.root; <userinput>cat krb.conf</userinput>
EXAMPLE.COM
EXAMPLE.COM grunt.example.com admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.gov</screen>

      <para>A többi övezetnek valójában nem
	feltétlenül kell itt lennie.  Ezek csupán
	azért szerepelnek itt, hogy bemutassák
	miként lehet egyetlen géphez hozzárendelni
	egyszerre több övezetet is.  Az
	egyszerûség kedvéért nyugodtan
	elhagyhatóak.</para>

      <para>Az elsõ sor nevezi meg a rendszer által
	mûködtetett övezeteket.  Az utána
	következõ sorokban övezeteket és
	hálózati neveket láthatunk.  Itt az
	elsõ elem egy övezetet nevez meg, a második
	elem pedig az övezet <quote>kulcselosztó
	központját</quote> (key distribution center).  A
	hálózati nevet követõ <literal>admin
	server</literal> kulcsszavak arra utalnak, hogy az adott
	gép adminisztratív szerepet ellátó
	adatbázist is tartalmaz.  Ezeket a fogalmakat
	részleteiben a Kerberos man oldalain ismerhetjük
	meg.</para>

      <para>Ezután hozzá kell adnunk a <hostid
	role="fqdn">grunt.example.com</hostid> nevû gépet az
	<literal>EXAMPLE.COM</literal> övezethez, valamint az
	<hostid role="domainname">.example.com</hostid>
	tartományban levõ összes géphez
	létre kell hoznunk egy bejegyzést az
	<literal>EXAMPLE.COM</literal> övezetben.  A
	<filename>krb.realms</filename> állományt ehhez a
	következõképpen kellene
	módosítanunk:</para>

      <screen>&prompt.root; <userinput>cat krb.realms</userinput>
grunt.example.com EXAMPLE.COM
.example.com EXAMPLE.COM
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDU</screen>

      <para>Ismét hozzátesszük, hogy a többi
	övezetnek nem kötelezõ itt szerepelnie.  Ezek
	csupán azt demonstrálják, hogy
	miként kell egy gépet egyszerre több
	övezethez is beállítani.  Az
	átláthatóság kedvéért
	minden további nélkül
	eltávolíthatjuk ezeket.</para>

      <para>Itt az elsõ sor az <emphasis>adott</emphasis> rendszert
	elhelyezi egy nevesített övezetbe.  A többi sor
	azt mutatja meg, hogyan kell alapértelmezett módon
	a meghatározott altartományokba tartozó
	gépeket egy nevesített övezethez
	hozzárendelni.</para>

      <para>Most már készen állunk az
	adatbázis létrehozására.  Ehhez
	egyedül a Kerberos szerverét (avagy
	Kulcselosztó központját) kell
	elindítanunk.  Adjuk ki a <command>kdb_init</command>
	parancsot:</para>

      <screen>&prompt.root; <userinput>kdb_init</userinput>
<prompt>Realm name [default  ATHENA.MIT.EDU ]:</prompt> <userinput>EXAMPLE.COM</userinput>
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.

<prompt>Enter Kerberos master key:</prompt> </screen>

      <para>Az üzenet fordítása:</para>

      <screen>Most az adatbázis mesterkulcsát kell megadni.  Fontos, hogy
NE FELEJTSÜK EL ezt a jelszót.</screen>

      <para>Most el kell mentenünk a kulcsot, így a helyi
	gépen futó szerverek fel tudják szedni.
	Ehhez a <command>kstash</command> parancsra van
	szükségünk:</para>

      <screen>&prompt.root; <userinput>kstash</userinput>

<prompt>Enter Kerberos master key:</prompt>

Current Kerberos master key version is 1.

Master key entered. BEWARE!</screen>

      <para>Az üzenet fordítása:</para>

      <screen>A Kerberos mesterkulcsának jelenlegi változata: 1.

VIGYÁZAT, megadták a mesterkulcsot!</screen>

      <para>Ez elmenti a titkosított mesterkulcsot az
	<filename>/etc/kerberosIV/master_key</filename>
	állományba.</para>

    </sect2>

    <sect2>
      <title>Az egész beüzemelése</title>

      <indexterm>
	<primary>KerberosIV</primary>
	<secondary>kezdeti indítása</secondary>
      </indexterm>

      <para><emphasis>Mindegyik</emphasis> Kerberosszal õrzött
	rendszerrel kapcsolatban két ún.  szereplõt
	(principal) kell még hozzátennünk az
	adatbázishoz.  A nevük <literal>kpasswd</literal>
	és <literal>rcmd</literal>.  Minden rendszerhez
	létre kell hoznunk ezeket a szereplõket,
	példányonként (instance) az egyes
	rendszerek neveivel.</para>

      <para>A <application>kpasswd</application> és
	<application>rcmd</application> démonok teszik
	lehetõvé a többi rendszer
	számára, hogy megváltoztathassák a
	Kerberos jelszavukat, valamint hogy futtathassák az
	&man.rcp.1;, &man.rlogin.1; és &man.rsh.1;
	parancsokat.</para>

      <para>Vegyük fel ezeket a bejegyzéseket is:</para>

      <screen>&prompt.root; <userinput>kdb_edit</userinput>
Opening database...

<prompt>Enter Kerberos master key:</prompt>

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

<prompt>Principal name:</prompt> <userinput>passwd</userinput>
<prompt>Instance:</prompt> <userinput>grunt</userinput>

&lt;Not found&gt;, <prompt>Create [y] ?</prompt> <userinput>y</userinput>

Principal: passwd, Instance: grunt, kdc_key_ver: 1
<prompt>New Password:</prompt>                    &lt;---- írjuk be, hogy <quote>RANDOM</quote>
Verifying password

<prompt>New Password:</prompt> &lt;---- írjuk be, hogy <quote>RANDOM</quote>

<prompt>Random password [y] ?</prompt> <userinput>y</userinput>

Principal's new key version = 1
<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt>
<prompt>Attributes [ 0 ] ?</prompt>
Edit O.K.
<prompt>Principal name:</prompt> <userinput>rcmd</userinput>
<prompt>Instance:</prompt> <userinput>grunt</userinput>

&lt;Not found&gt;, <prompt>Create [y] ?</prompt>

Principal: rcmd, Instance: grunt, kdc_key_ver: 1
<prompt>New Password:</prompt>		&lt;---- írjuk be, hogy <quote>RANDOM</quote>
Verifying password

<prompt>New Password:</prompt>           &lt;---- írjuk be, hogy <quote>RANDOM</quote>

<prompt>Random password [y] ?</prompt>

Principal's new key version = 1
<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt>
<prompt>Attributes [ 0 ] ?</prompt>
Edit O.K.
<prompt>Principal name:</prompt>         &lt;---- ha nem adunk meg semmit, akkor kilép</screen>
    </sect2>

    <sect2>
      <title>A szerver állomány
	létrehozása</title>

      <para>Most pedig kivonatolni kell azokat a
	példányokat, amelyek szolgáltatást
	definiálnak a gépen.  Erre az
	<command>ext_srvtab</command> parancsot használjuk.
	Ennek eredményeképpen keletkezik egy
	állományt, amelyet <emphasis>biztonságos
	eszközökkel</emphasis> át kell másolni
	vagy át kell mozgatni az egyes Kerberos kliensek
	<filename class="directory">/etc</filename> könyvtárába.  Ennek
	az állománynak egyaránt jelent kell lennie
	a szerveren és a kliensen is, nélküle a
	Kerberos mûködésképtelen.</para>

      <screen>&prompt.root; <userinput>ext_srvtab grunt</userinput>
<prompt>Enter Kerberos master key:</prompt>

Current Kerberos master key version is 1.

Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....</screen>

      <para>Ez a parancs most létrehozott egy ideiglenes
	állományt, amit át kell nevezni az
	<filename>srvtab</filename> névre, hogy
	megtalálhassák a szerverek.  Az eredeti rendszeren
	a &man.mv.1; paranccsal tudjuk a helyére rakni:</para>

      <screen>&prompt.root; <userinput>mv grunt-new-srvtab srvtab</userinput></screen>

      <para>Ha egy kliensnek szánjuk az állományt
	és a hálozatunkat nem tekinthetjük
	biztonságosnak, akkor a
	<filename><replaceable>kliens</replaceable>-new-srvtab</filename>
	állományt másoljuk egy mozgatható
	adathordozóra és megbízható
	módon jutassuk el.  Ne felejtsük el az
	állományt <filename>srvtab</filename> néven
	átrakni a kliens <filename
	  class="directory">/etc</filename> könyvtárába
	és az engedélyeit 600-ra
	állítani:</para>

      <screen>&prompt.root; <userinput>mv grumble-new-srvtab srvtab</userinput>
&prompt.root; <userinput>chmod 600 srvtab</userinput></screen>

    </sect2>

    <sect2>
      <title>Az adatbázis feltöltése</title>

      <para>Ezt követõen rögzítenünk kell
	néhány felhasználót is
	adatbázisban.  Elõször is hozzunk létre
	egy bejegyzést a <username>janos</username> nevû
	felhasználónak.  Ezt a <command>kdb_edit</command>
	parancs kiadásával tesszük meg:</para>

      <screen>&prompt.root; <userinput>kdb_edit</userinput>
Opening database...

<prompt>Enter Kerberos master key:</prompt>

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

<prompt>Principal name:</prompt> <userinput>janos</userinput>
<prompt>Instance:</prompt>

&lt;Not found&gt;, <prompt>Create [y] ?</prompt> <userinput>y</userinput>

Principal: janos, Instance: , kdc_key_ver: 1
<prompt>New Password:</prompt>                &lt;---- adjunk meg egy biztonságos jelszót
Verifying password

<prompt>New Password:</prompt>                &lt;---- itt ismét adjuk meg a jelszót
Principal's new key version = 1
<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt>
<prompt>Attributes [ 0 ] ?</prompt>
Edit O.K.
<prompt>Principal name:</prompt>		   &lt;---- ha nem írunk be semmit, akkor kilép</screen>

    </sect2>

    <sect2>
      <title>Próbáljuk ki</title>

      <para>Elsõként a Kerberos démonait kell
	beindítanunk.  Ezzel kapcsolatban megjegyeznénk,
	hogy ha ehhez megfelelõen átírtuk az
	<filename>/etc/rc.conf</filename> állományunkat,
	akkor ez az újraindítással együtt
	magától lezajlik.  Ezt csak a Kerberos szerveren
	kell megcsinálni.  A Kerberos kliensei maguktól
	összeszedik a mûködésükhöz
	szükséges adatokat az <filename
	  class="directory">/etc/kerberosIV</filename>
	könyvtárból.</para>

      <screen>&prompt.root; <userinput>kerberos &amp;</userinput>
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.

Master key entered. BEWARE!

Current Kerberos master key version is 1
Local realm: EXAMPLE.COM
&prompt.root; <userinput>kadmind -n &amp;</userinput>
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead

Current Kerberos master key version is 1.

Master key entered.  BEWARE!</screen>

      <para>A fenti figyelmeztetés
	fordítása:</para>

      <screen>A program leállítására ne a 'kill -9' parancsot, hanem a
normális kill parancsot használjuk</screen>

      <para>Ezután a <command>kinit</command> parancs
	használatával próbáljunk meg az
	elõbb létrehozott <username>janos</username>
	azonosítónak kérni egy jegyet:</para>

      <screen>&prompt.user; <userinput>kinit janos</userinput>
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "janos"
<prompt>Password:</prompt> </screen>

      <para>A <command>klist</command> paranccsal most
	próbáljuk meg kilistázni a tokeneket
	és így ellenõrizni, hogy valóban
	rendelkezünk velük:</para>

      <screen>&prompt.user; <userinput>klist</userinput>
Ticket file:    /tmp/tkt245
Principal:      janos@EXAMPLE.COM

  Issued           Expires          Principal
Apr 30 11:23:22  Apr 30 19:23:22  krbtgt.EXAMPLE.COM@EXAMPLE.COM</screen>

      <para>Ezután a &man.passwd.1; használatával
	próbáljuk meg megváltoztatni a
	jelszavunkat.  Ezzel tudjuk ellenõrizni, hogy a
	<application>kpasswd</application> démon
	hozzáfér a Kerberos
	adatbázisához:</para>

      <screen>&prompt.user; <userinput>passwd</userinput>
realm EXAMPLE.COM
<prompt>Old password for janos:</prompt>
<prompt>New Password for janos:</prompt>
Verifying password
<prompt>New Password for janos:</prompt>
Password changed.</screen>

    </sect2>

    <sect2>
      <title>Adminisztrátori jogosultságok
	felvétele</title>

      <para>A Kerberos lehetõvé teszi, hogy
	<emphasis>mindegyik</emphasis> olyan
	felhasználónak, akinek rendszergazdai jogokra
	lenne szüksége, a &man.su.1;
	eléréséhez
	<emphasis>külön</emphasis> meg tudjunk adni egy
	jelszót.  Most már tudunk mondani egy olyan
	azonosítót is, amely jogosult a &man.su.1;
	használatával <username>root</username> jogokat
	szerezni.  Ezt úgy tudjuk megoldani, ha az adott
	szereplõhöz társítunk egy
	<username>root</username> példányt.  A
	<command>kdb_edit</command> használatával
	készíteni tudunk egy <literal>janos.root</literal>
	bejegyzést a Kerberos adatbázisában:</para>

      <screen>&prompt.root; <userinput>kdb_edit</userinput>
Opening database...

<prompt>Enter Kerberos master key:</prompt>

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

<prompt>Principal name:</prompt> <userinput>janos</userinput>
<prompt>Instance:</prompt> <userinput>root</userinput>

&lt;Not found&gt;, Create [y] ? y

Principal: janos, Instance: root, kdc_key_ver: 1
<prompt>New Password:</prompt>                    &lt;---- ide csak egy BIZTONSÁGOS jelszót adjuk meg!
Verifying password

<prompt>New Password:</prompt>    	 	 &lt;---- adjuk meg ismét a jelszót

Principal's new key version = 1
<prompt>Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?</prompt>
<prompt>Max ticket lifetime (*5 minutes) [ 255 ] ?</prompt> <userinput>12</userinput> &lt;--- ne állítsuk nagyon hosszúra!
<prompt>Attributes [ 0 ] ?</prompt>
Edit O.K.
<prompt>Principal name:</prompt>		         &lt;---- ha nem adunk meg semmit, akkor kilép</screen>

      <para>Ezt követõen úgy tudunk megbizonyosodni a
	mûködésérõl, hogy
	megpróbálunk neki tokeneket szerezni:</para>

      <screen>&prompt.root; <userinput>kinit janos.root</userinput>
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "janos.root"
<prompt>Password:</prompt></screen>

      <para>Most rakjuk bele a felhasználót a
	<username>root</username> <filename>.klogin</filename>
	állományába:</para>

      <screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
janos.root@EXAMPLE.COM</screen>

      <para>Ezután próbáljunk meg kiadni a
	&man.su.1; parancsát:</para>

      <screen>&prompt.user; <userinput>su</userinput>
<prompt>Password:</prompt></screen>

      <para>Nézzük meg milyen tokenjeink is vannak:</para>

      <screen>&prompt.root; <userinput>klist</userinput>
Ticket file:	/tmp/tkt_root_245
Principal:      janos.root@EXAMPLE.COM

  Issued           Expires          Principal
May  2 20:43:12  May  3 04:43:12  krbtgt.EXAMPLE.COM@EXAMPLE.COM</screen>

    </sect2>

    <sect2>
      <title>Más parancsok használata</title>

      <para>Az iménti példában létrehoztunk
	egy <literal>janos</literal> nevû szereplõt, amihez a
	<literal>root</literal> egy példányát
	rendeltük.  Ez egy olyan felhasználón
	alapján történt, akinek a neve megegyezik a
	hozzá tartozó szereplõvel, ami a Kerberosban
	alapértelmezés.  Amennyiben a
	szükséges megjegyzések
	megtalálhatóak a <username>root</username>
	könyvtárában levõ
	<filename>.klogin</filename> állományban, akkor a
	<literal><replaceable>felhasználó</replaceable>.<username>root</username></literal>
	formátumú
	<literal><replaceable>szereplõ</replaceable>.<replaceable>példány</replaceable></literal>
	azonosító megengedi a
	<literal><replaceable>felhasználó</replaceable></literal>
	számára, hogy végrehajtsa a &man.su.1;
	parancsot.</para>

      <screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
janos.root@EXAMPLE.COM</screen>

      <para>Ehhez hasonlóan, ha a felhasználó
	saját könyvtárában
	megtalálható egy ilyen
	állomány:</para>

      <screen>&prompt.user; <userinput>cat ~/.klogin</userinput>
janos@EXAMPLE.COM
jozsef@EXAMPLE.COM</screen>

      <para>Ezzel a konfigurációval bárki, aki
	<username>janos</username> felhasználóként
	vagy <username>jozsef</username>
	felhasználóként (a <command>kinit</command>
	parancson keresztül) hitelesítette magát
	<literal>EXAMPLE.COM</literal> övezetbõl, ezen a
	rendszeren (<hostid>grunt</hostid>) bejelentkezhet a
	<username>janos</username> nevû
	felhasználóként vagy
	hozzáférhet az állományaihoz az
	&man.rlogin.1;, &man.rsh.1; vagy &man.rcp.1;
	használatával.</para>

      <para>Például <username>janos</username> most egy
	másik Kerberost használó rendszerre
	jelentkezik be:</para>

      <screen>&prompt.user; <userinput>kinit</userinput>
MIT Project Athena (grunt.example.com)
<prompt>Password:</prompt>
&prompt.user; <userinput>rlogin grunt</userinput>
Last login: Mon May  1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.   All rights reserved.

FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>

      <para>Vagy <username>jozsef</username> jelentkezik be ugyanazon a
	gépen <username>janos</username>
	hozzáférésével (a
	<username>janos</username> nevû
	felhasználónak a fentebb bemutatt
	<filename>.klogin</filename> állomány
	található a könyvtárában
	és a Kerberos üzemeltetéséért
	felelõs személy létrehozott egy
	<emphasis>jozsef</emphasis> nevû szereplõt egy null
	példánnyal):</para>

      <screen>&prompt.user; <userinput>kinit</userinput>
&prompt.user; <userinput>rlogin grunt -l janos</userinput>
MIT Project Athena (grunt.example.com)
<prompt>Password:</prompt>
Last login: Mon May  1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.   All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>

    </sect2>
  </sect1>

  <sect1 id="kerberos5">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tillman</firstname>
	  <surname>Hodgson</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Mark</firstname>
	  <surname>Murray</surname>
	  <contrib>Eredetileg írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title><application>Kerberos5</application></title>

    <para>A &os;&nbsp;5.1 után következõ mindegyik &os;
      kiadás már csak a
      <application>Kerberos5</application> támogatást
      tartalmaz.  Ezért bennük csak a
      <application>Kerberos5</application> található meg,
      és a beállítása sok szempontból
      hasonlít a <application>KerberosIV</application>
      beállításához.  A most
      következõ információk csak és
      kizárólag a &os;&nbsp;5.0 kiadás után
      következõkben található
      <application>Kerberos5</application> változatra
      vonatkoznak.  A <application>KerberosIV</application>
      szolgáltatásait a felhasználók
      csomagként, a <filename
      role="package">security/krb4</filename> porton keresztül
      érhetik el.</para>

    <para>A <application>Kerberos</application> egy
      hálózati kiegészítõ
      rendszer/protokoll, amivel a felhasználók egy
      biztonságos szerveren keresztül képesek magukat
      azonosítani.  A távoli bejelentkezések,
      távoli másolások, a rendszer belüli
      védett másolások valamint egyéb nagyon
      kockázatos feladatok, szolgáltatások
      biztonsága és felügyelete így
      jelentõs mértékben
      javítható.</para>

    <para>A <application>Kerberos</application> úgy
      írható le, mint az személyazonosságok
      ellenõrzésére feljogosított rendszer.
      Vagy tekinthetjük egy megbízható
      külsõ megfigyelõ által végzett
      hitelesítési rendszernek is.  A
      <application>Kerberos</application> csak egyetlen funkciót
      kínál fel &mdash; ez a felhasználók
      biztonságos hitelesítése a
      hálózaton.  Viszont nem nyújt semmilyen
      felhatalmazási (mit csinálhatnak a
      felhasználók) vagy vizsgálati (mit
      csináltak végül a felhasználók)
      lehetõséget.  Miután egy kliens és a
      szerver a <application>Kerberos</application>
      használatával azonosították
      egymást, az egymás közt folyó
      kommunikációjuk titkosításával
      képesek megõrzi az átáramló
      adatok sértetlenségét és
      lehallgathatatlanságát.</para>

    <para>Ennek tükrében a
      <application>Kerberos</application> használata csak
      más olyan biztonsági módszerekkel
      együttesen javasolt, amelyek felhatalmazást és
      vizsgálati szolgáltatásokkal is
      rendelkeznek.</para>

    <para>A most következõ utasítások arra
      igyekeznek útmutatást adni, hogy miként
      használjuk a &os;-vel együtt terjesztett
      <application>Kerberos</application> verziót.  Azonban a
      teljes leírást csak a témához
      tartozó man oldalak átolvasásával
      együtt kapjuk meg.</para>

    <para>A <application>Kerberos</application>
      telepítésének bemutatásához az
      alábbi névtereket fogjuk használni:</para>

    <itemizedlist>
      <listitem>
	<para>A <acronym>DNS</acronym> tartomány
	  (<quote>zóna</quote>) az <hostid
	  role="fqdn">example.org</hostid> lesz.</para>
      </listitem>

      <listitem>
	<para>A <application>Kerberos</application> övezet az
	  EXAMPLE.ORG lesz.</para>
      </listitem>
    </itemizedlist>

    <note>
      <para>Kérjük, hogy még abban az esetben is
	valódi tartományneveket adjuk meg, amikor a
	<application>Kerberos</application> használatát
	csak a belsõ hálózaton tervezzük.  Ezzel
	elkerülhetjük az egyes
	<application>Kerberos</application> övezetek
	együttmûködése során
	felmerülõ <acronym>DNS</acronym>
	problémákat.</para>
    </note>

    <sect2>
      <title>A <application>Kerberos</application>
	története</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>története</secondary>
      </indexterm>

      <para>A <application>Kerberos</application>t az
	<acronym>MIT</acronym> hozta létre a
	hálózati biztonsággal kapcsolatos
	problémák egyik megoldásaként.  A
	<application>Kerberos</application> erõs
	titkosítást használ, ezért a
	kliensek képesek egy nem biztonságos
	hálózaton is azonosítani magukat a szerver
	felé (és fordítva).</para>

      <para>A <application>Kerberos</application> egyaránt utal
	egy hálózati protokoll nevére és
	azokra programokra, amelyek implementálják
	(például <application>Kerberos</application>
	telnet).  Az 5 a protokoll jelenlegi verziója, amit az
	<acronym>RFC</acronym>&nbsp;1510 ír le.</para>

      <para>A protokollnak számos szabad változata
	létezik, rengeteg típusú
	operációs rendszerre.  A Massachusettsi
	Mûszaki Intézet (Massachusetts Institute of
	Technology, <acronym>MIT</acronym>), ahol a
	<application>Kerberos</application>t eredetileg
	kifejlesztették, napjainkban is folytatja a saját
	<application>Kerberos</application> csomagjának
	fejlesztését.  Többnyire az Egyesült
	Államokban használják
	titkosításra, mivel régebben az amerikai
	kiviteli korlátozások voltak rá
	érvényesek.  Az <acronym>MIT</acronym>
	<application>Kerberos</application> változata
	portként érhetõ el (<filename
	role="package">security/krb5</filename>).  A Heimdal
	<application>Kerberos</application> egy másik 5
	verziójú implementáció, amit a
	kiviteli korlátozások elkerülése
	érdekében határozottan az Egyesült
	Államokon kívül fejlesztettek ki
	(ezért gyakran megtalálhatjuk a
	különbözõ nem kereskedelmi &unix;
	variánsokban).  A Heimdal
	<application>Kerberos</application> terjesztés
	portként elérhetõ (<filename
	role="package">security/heimdal</filename>) és kisebb
	méretben a &os; alaptelepítésének is
	része.</para>

      <para>Mivel ezzel az írással a legtöbb
	felhasználót kívánjuk
	segíteni, ezért a következõ
	utasítások a &os;
	telepítésében mellékelt Heimdal
	terjesztés használatát
	feltételezik.</para>

    </sect2>

    <sect2>
      <title>A Heimdal kulcselosztójának
	telepítése</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>kulcselosztó központ</secondary>
      </indexterm>

      <para>A kulcselosztó központ (Key Distribution Center,
	avagy <acronym>KDC</acronym>) az a centralizált
	hitelesítési szolgáltatás, amit a
	<application>Kerberos</application> nyújt &mdash;
	lényegében az a
	számítógép, amely
	<application>Kerberos</application>-jegyeket bocsájt ki.
	A <acronym>KDC</acronym>
	<quote>megbízhatónak</quote> tekinthetõ a
	<application>Kerberos</application> által
	kialakított övezetben levõ többi
	számítógép számára,
	ezért védelme kiemelten fontos.</para>

      <para>Itt jegyeznénk meg, hogy habár a
	<application>Kerberos</application> szerver futtatása
	nagyon kevés számítógépes
	erõforrást igényel, ennek ellenére
	biztonsági szempontból egy külön
	számítógépet javasoljunk a
	kulcselosztó szerepének
	betöltéséhez.</para>

      <para>Mielõtt nekifognánk a <acronym>KDC</acronym>
	konfigurálásának, ellenõrizzük,
	hogy az <filename>/etc/rc.conf</filename> tartalmazza a
	<acronym>KDC</acronym> mûködéséhez
	szükséges beállításokat (az
	elérési utakat természetesen a saját
	rendszerünk szerint állítsuk be):</para>

      <programlisting>kerberos5_server_enable="YES"
kadmind5_server_enable="YES"</programlisting>

      <para>A következõ lépésben vegyük
	szemügyre a <application>Kerberos</application>
	beállításait tartalmazó
	<filename>/etc/krb5.conf</filename>
	állományt:</para>

      <programlisting>[libdefaults]
    default_realm = EXAMPLE.ORG
[realms]
    EXAMPLE.ORG = {
        kdc = kerberos.example.org
        admin_server = kerberos.example.org
    }
[domain_realm]
    .example.org = EXAMPLE.ORG</programlisting>

      <para>Vegyük észre, hogy az itt szereplõ
	<filename>/etc/krb5.conf</filename> állomány
	szerint a kulcselosztónk teljes hálózati
	neve <hostid role="fqdn">kerberos.example.org</hostid>.  Ha a
	kulcselosztónknak nem ez a neve, akkor a
	zónákat leíró
	állományba vegyünk még fel egy ilyen
	CNAME (álnév) bejegyzést.</para>

      <note>
	<para>Ha egy nagyobb hálózatban vagyunk, ahol a
	  <acronym>DNS</acronym> szervert is megfelelõen
	  beállították, akkor az iménti
	  példa ennyire leszûkíthetõ:</para>

	<programlisting>[libdefaults]
      default_realm = EXAMPLE.ORG</programlisting>

	<para>Itt már a következõ sorokat
	  hozzáadták <hostid
	  role="fqdn">example.org</hostid> zónát
	  leíró állományhoz:</para>

	<programlisting>_kerberos._udp      IN  SRV     01 00 88 kerberos.example.org.
_kerberos._tcp      IN  SRV     01 00 88 kerberos.example.org.
_kpasswd._udp       IN  SRV     01 00 464 kerberos.example.org.
_kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.example.org.
_kerberos           IN  TXT     EXAMPLE.ORG</programlisting></note>

      <note>
	<para>A kliensek csak akkor lesznek képesek elérni
	  a <application>Kerberos</application>
	  szolgáltatásait, ha vagy
	  <emphasis>kötelezõ jelleggel</emphasis> megadunk egy
	  teljesen beállított
	  <filename>/etc/krb5.conf</filename> állományt,
	  vagy egy minimális <filename>/etc/krb5.conf</filename>
	  állományt <emphasis>és</emphasis> egy
	  helyesen beállított DNS szervert
	  használunk.</para>
      </note>

      <para>Ezután létrehozzuk a
	<application>Kerberos</application> adatbázisát.
	Ez az adatbázis tartalmazza az összes szereplõ
	kulcsát a mesterkulcssal titkosítva.  Erre a
	jelszóra nem kell feltétlenül
	emlékeznünk, mivel ez egy állományban
	tárolódik
	(<filename>/var/heimdal/m-key</filename>).  A mesterkulcsot a
	<command>kstash</command> parancs kiadásával
	és egy jelszó megadásával tudjuk
	létrehozni.</para>

      <para>Ahogy a mesterkulcs elkészült, a
	<command>kadmin</command> parancs <literal>-l</literal> (mint
	<quote>lokális</quote>, azaz helyi)
	opciójával inicializálni tudjuk az
	adatbázist.  Ez az opció arra utasítja a
	<command>kadmin</command> programot, hogy ne a
	<command>kadmind</command> hálózati
	szolgáltatást használja, hanem
	közvetlenül az adatbázis
	állományait módosítsa.  Ezzel
	oldható meg az adatbázis kezdeti
	létrehozásának problémája.
	Miután megkaptuk a <command>kadmin</command>
	parancssorát, az övezetünkhöz
	tartozó adatbázis
	inicializálásához adjuk ki az
	<command>init</command> parancsot.</para>

      <para>Végül, még mindig a
	<command>kadmin</command> parancssorát használva,
	az <command>add</command> paranccsal hozzuk létre az
	elsõ szereplõnket.  Egyelõre érjük be
	az alapértelmezett értékekkel, a
	<command>modify</command> paranccsal késõbb
	úgyis meg tudjuk változtatni ezeket.
	Hozzátesszük, hogy itt a <command>?</command>
	parancs segítségével bármikor
	lekérhetjük az opciók
	ismertetését.</para>

      <para>Példa egy adatbázis
	létrehozására:</para>

      <screen>&prompt.root; <userinput>kstash</userinput>
Master key: <userinput>xxxxxxxx</userinput>
Verifying password - Master key: <userinput>xxxxxxxx</userinput>

&prompt.root; <userinput>kadmin -l</userinput>
kadmin> <userinput>init EXAMPLE.ORG</userinput>
Realm max ticket life [unlimited]:
kadmin> <userinput>add tillman</userinput>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: <userinput>xxxxxxxx</userinput>
Verifying password - Password: <userinput>xxxxxxxx</userinput></screen>

      <para>Most már ideje elindítani a
	<acronym>KDC</acronym> szolgáltatásait.  Ezeket az
	<command>/etc/rc.d/kerberos start</command> és
	<command>/etc/rc.d/kadmind start</command> parancsok
	kiadásával tudjuk felhozni.  Megjegyezzük,
	hogy most még semmilyen kerberizált démont
	nem kell elindítanunk.  Ellenben igyekezzünk
	ellenõrizni a <acronym>KDC</acronym>
	mûködõképességét azzal, hogy
	<acronym>KDC</acronym> parancssorából
	kérünk egy jegyet a frissen hozzáadott
	szereplõnknek (felhasználónknak) és
	kilistázzuk:</para>

      <screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
tillman@EXAMPLE.ORG's Password:

&prompt.user; <userinput>klist</userinput>
Credentials cache: FILE:<filename>/tmp/krb5cc_500</filename>
	Principal: tillman@EXAMPLE.ORG

  Issued           Expires          Principal
Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>

      <para>Miután végeztünk, nyugodtan
	törölhetjük a jegyet:</para>

      <screen>&prompt.user; <userinput>kdestroy</userinput></screen>

    </sect2>

    <sect2>
      <title>Szerverek kerberizálása a Heimdal
	használatával</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>szolgáltatások
	  kerberizálása</secondary>
      </indexterm>

      <para>Ehhez elõször is szükségünk lesz
	a <application>Kerberos</application>
	konfigurációs állományának,
	az <filename>/etc/krb5.conf</filename> másolatára.
	Ezt úgy tudjuk megtenni, ha egyszerûen
	átmásoljuk a kulcselosztóról az
	egyik kliensre valamilyen megbízható módon
	(vagy az &man.scp.1; programhoz hasonló
	hálózati segédprogramok, vagy
	például fizikailag egy floppy lemez
	használatával).</para>

      <para>Ezután szükségünk lesz egy
	<filename>/etc/krb5.keytab</filename> nevû
	állományra.  Ez az alapvetõ
	különbség a kerberizált démonokat
	felkínáló szerver és egy
	munkaállomás közt &mdash; a szervernek
	rendelkeznie kell egy <filename>keytab</filename>
	állománnyal.  Ez az állomány
	tartalmazza a szerver kulcsát, amivel így a
	kulcselosztóval kölcsönösen
	azonosítani tudják egymást.  Ezt a
	szerverre biztonságosan kell eljuttatnunk, mivel ennek
	napvilágra kerülésével a szerver
	védelme komoly veszélybe kerül.
	Tehát, ha egy titkosítás
	nélküli csatornán, például
	<acronym>FTP</acronym>-n keresztül visszük át,
	akkor kifejezetten rossz ötlet.</para>

      <para>A szerverre általában a
	<command>kadmin</command> program használatával
	érdemes átvinni a <filename>keytab</filename>
	állományt.  Ez azért is hasznos, mert ehhez
	a <command>kadmin</command> segítségével
	létre kell hoznunk a befogadó szereplõt is (a
	kulcselosztó a <filename>krb5.keytab</filename>
	állomány végén).</para>

      <para>Vegyük észre, hogy már kaptunk egy jegyet
	és ezzel a jeggyel jogosultaknak kell lennünk a
	<filename>kadmind.acl</filename> állomány
	<command>kadmin</command> felület
	használatára.  A hozzáférést
	vezérlõ listák (ACL-ek)
	tervezésével kapcsolatban olvassuk el Heimdal info
	oldalán található <quote>Remote
	administration</quote> címû szakaszt (<command>info
	heimdal</command>).  Amennyiben nem kívánjuk
	engedélyezni a <command>kadmin</command> távoli
	elérését, egyszerûen csak
	csatlakozzunk valamilyen biztonságos módon (helyi
	konzolon, &man.ssh.1; vagy egy kerberizált &man.telnet.1;
	használatával) a kulcselosztóhoz, és
	a <command>kadmin -l</command> paranccsal végezzük
	el helyben az adminisztrációt.</para>

      <para>Miután telepítettük az
	<filename>/etc/krb5.conf</filename> állományt, a
	<application>Kerberos</application> szerverrõl el tudjuk
	érni a <command>kadmin</command> felületét.
	Az <command>add --random-key</command> paranccsal most
	már hozzáadhatjuk a szerver befogadó
	szereplõjét és az <command>ext</command>
	paranccsal ki tudjuk vonni a szerver befogadó
	szereplõjét a saját keytab
	állományából.
	Például:</para>

      <screen>&prompt.root; <userinput>kadmin</userinput>
kadmin><userinput> add --random-key host/myserver.example.org</userinput>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
kadmin><userinput> ext host/myserver.example.org</userinput>
kadmin><userinput> exit</userinput></screen>

      <para>Itt jegyeznénk meg, hogy az <command>ext</command>
	parancs (az <quote>extract</quote> rövdítése)
	a kivont kulcsot alapértelmezés szerint az
	<filename>/etc/krb5.keytab</filename> állományba
	menti ki.</para>

      <para>Ha a kulcselosztón nem fut a
	<command>kadmind</command> szolgáltatás
	(valószínûleg biztonsági
	okokból) és ezért távolról
	nem tudjuk elérni a <command>kadmin</command>
	felületét, akkor így tudjuk
	közvetlenül hozzáadni a befogadó
	szereplõt (<username>host/myserver.EXAMPLE.ORG</username>),
	majd kivonatolni azt egy ideiglenes állományba
	(elkerülve az <filename>/etc/krb5.keytab</filename>
	felülírását):</para>

      <screen>&prompt.root; <userinput>kadmin</userinput>
kadmin><userinput> ext --keytab=/tmp/example.keytab host/myserver.example.org</userinput>
kadmin><userinput> exit</userinput></screen>

      <para>Ezután valamilyen biztonságos eszközzel
	(például <command>scp</command> vagy floppy
	használatával) át tudjuk másolni
	keytab állományt a szerverre.  A
	kulcselosztón levõ keytab
	felülírását elkerülendõ, ne
	feledkezzünk el egy megfelelõ név
	megadásáról sem.</para>

      <para>Ezen a ponton már a szerver képes felvenni a
	kapcsolatot a kulcselosztóval (a
	<filename>krb5.conf</filename> állomány miatt)
	és bizonyítani a
	személyazonosságát (a
	<filename>krb5.keytab</filename> állomány miatt).
	Így tehát készen állunk a
	szolgáltatások
	kerberizálására.  Ebben a
	példában most a <command>telnet</command>
	szolgáltatást vesszük célba
	úgy, hogy elõször az
	<filename>/etc/inetd.conf</filename> állományba
	berakjuk az alábbi sort, majd újraindítjuk
	az &man.inetd.8; szolgáltatást az
	<command>/etc/rc.d/inetd restart</command> paranccsal:</para>

      <programlisting>telnet    stream  tcp     nowait  root    /usr/libexec/telnetd  telnetd -a user</programlisting>

      <para>Itt az a legfontosabb, hogy az <command>-a</command> (mint
	authentication, azaz hitelesítés)
	paramétert a <quote>user</quote>
	beállítással adjuk meg.  A &man.telnetd.8;
	man oldalán olvashatunk ennek pontos
	részleteirõl.</para>

    </sect2>

    <sect2>
      <title>Kliensek kerberizálása a Heimdal
	használatával</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>kliensek beállítása</secondary>
      </indexterm>

      <para>A kliensek beállítása szinte majdnem
	gyerekjáték.  A
	<application>Kerberos</application>
	beállításához egyedül az
	<filename>/etc/krb5.conf</filename> állományra
	lesz szükségünk.  Valamilyen biztonságos
	eszközzel másoljuk át a
	kulcselosztóról a kliensre.</para>

      <para>Úgy tudjuk letesztelni klienst, ha
	megpróbáljuk róla kiadni a
	<command>kinit</command>, <command>klist</command> és
	<command>kdestroy</command> parancsokat a fentebb
	létrehozott szereplõ jegyének
	megszerzéséhez,
	lekérdezéséhez és
	megsemmisítéséhez.  A
	<application>Kerberos</application> használatával
	megpróbálkozhatunk csatlakozni valamelyik
	kerberizált szerverre is, ha viszont ez nem
	mûködik még egy jegy megszerzése
	után sem, akkor a gond többnyire a szerverrel van,
	nem pedig a klienssel vagy a kulcselosztóval.</para>

      <para>Amikor egy <command>telnet</command> vagy egy hozzá
	hasonló alkalmazást tesztelünk, egy
	csomaglehallgató (mint amilyen például a
	&man.tcpdump.1;) elindításával
	gyõzödjünk meg róla, hogy a jelszavak
	ilyenkor titkosítva mennek át.
	Próbáljuk meg titkosítani a teljes
	kommunikációt a <command>telnet</command>
	<option>-x</option> paraméterével
	(hasonlóan az <command>ssh</command> parancshoz).</para>

      <para>Alapból még számos más
	kiegészítõ
	<application>Kerberos</application> kliensalkalmazás is
	telepítõdik.  Ezeken érezhetõ meg
	valójában az alaprendszerhez tartozó
	Heimdal változat <quote>minimalitása</quote>:
	ebben a <command>telnet</command> az egyedüli
	kerberizált szolgáltatás.</para>

      <para>A Heimdal port igyekszik pótolni a
	hiányzó klienseket a kerberizált
	<command>ftp</command>, <command>rsh</command>,
	<command>rcp</command>, <command>rlogin</command> és
	néhány kevéséb ismert program
	telepítésével.  Az <acronym>MIT</acronym>
	változat portja szintén tartalmazza a
	<application>Kerberos</application> kliensek teljes
	kelléktárát.</para>

    </sect2>

    <sect2>
      <title>A felhasználók konfigurációs
	állományai: a <filename>.k5login</filename>
	és a <filename>.k5users</filename></title>

      <indexterm><primary><filename>.k5login</filename></primary></indexterm>
      <indexterm><primary><filename>.k5users</filename></primary></indexterm>

      <para>Általában az övezetben
	található felhasználók
	mindegyikéhez tartozik egy
	<application>Kerberos</application>-szereplõ (mint
	például a
	<username>tillman@EXAMPLE.ORG</username>), ami a
	felhasználó helyi
	hozzáférésére mutat (mint
	például a <username>tillman</username> nevû
	helyi hozzáférés).  A
	<command>telnet</command> és a hozzá
	hasonló kliensalkalmazások általában
	nem igényelnek felhasználót vagy
	szereplõt.</para>

      <para>Elõfordulhat azonban, hogy valaki olyan szeretné
	elérni egy helyi felhasználó
	hozzáférését, aki nem rendelkezik a
	hozzá tartozó
	<application>Kerberos</application>-szereplõvel.
	Például a <username>tillman@EXAMPLE.ORG</username>
	nevû felhasználó el szeretné
	érni a helyi számítógépen
	levõ <username>webdevelopers</username>
	hozzáférést.  Más szereplõk is
	elérhetik a helyi
	hozzáféréseket.</para>

      <para>A probléma megoldásához a
	felhasználók könyvtárában
	található <filename>.k5login</filename> és
	a <filename>.k5users</filename> állományok
	használhatóak a <filename>.host</filename>
	és <filename>.rhosts</filename> állományok
	kombinációjához hasonlóan.
	Például a <filename>.k5login</filename> így
	néz ki:</para>

      <screen>tillman@example.org
jdoe@example.org</screen>

      <para>Ezt a <username>webdevelopers</username> nevû helyi
	felhasználó könyvtárában kell
	elhelyeznünk, így a felsorolt szereplõt
	megosztott jelszó használata nélkül
	képesek elérni a
	hozzáférést.</para>

      <para>Az említett parancsok man oldalának
	elolvasása ajánlott.  Megjegyezzük, hogy a
	<command>ksu</command> man oldal foglalkozik a
	<filename>.k5users</filename> állománnyal.</para>

    </sect2>

    <sect2>
      <title>Tippek, trükkök a
	<application>Kerberos</application>
	használatáról és
	hibaelhárítás</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>hibaelhárítás</secondary>
      </indexterm>

      <itemizedlist>
	<listitem>
	  <para>Akár a <application>Kerberos</application>
	    Heimdal vagy az <acronym>MIT</acronym>
	    változatát használjuk, ne
	    felejtsük úgy beállítani a
	    <envar>PATH</envar> környezeti változóban
	    felsorolt elérési utakat, hogy a
	    kliensalkalmazások kerberizált
	    változatai a rendszerben használatos
	    verziók elé kerüljenek.</para>
	</listitem>

	<listitem>
	  <para>Az övezetben minden
	    számítógép órája
	    ugyanúgy jár?  Ha nem, akkor a
	    hitelesítés csõdöt mondhat.  A <xref
	    linkend="network-ntp"/>ból tudhatjuk meg hogyan
	    szinkronizáljunk órákat az
	    <acronym>NTP</acronym>
	    segítségével.</para>
	</listitem>

	<listitem>
	  <para>Az <acronym>MIT</acronym> és a Heimdal
	    verziók a <command>kadmin</command>
	    kivételével remekül megvannak
	    egymással, mivel az általa használt
	    protokollt még nem
	    szabványosították.</para>
	</listitem>

	<listitem>
	  <para>Ha megváltoztatjuk a gépünk
	    hálózati nevét, akkor a ugyanígy
	    a <username>host/</username> szereplõnket is meg kell
	    változtatni és frissíteni a keytab
	    állományunkat.  Ez olyan speciális
	    keytab bejegyzésekre is vonatkozik, mint
	    például az Apache <filename
	    role="package">www/mod_auth_kerb</filename>
	    moduljához tartozó <username>www/</username>
	    szereplõ.</para>
	</listitem>

	<listitem>
	  <para>Az övezetünkben levõ összes
	    számítógépnek (mind a két
	    irányba) feloldható <acronym>DNS</acronym>
	    névvel kell rendelkeznie (vagy legalább egy
	    <filename>/etc/hosts</filename> állománnyal).
	    Erre a CNAME rekord megfelelõ, de az A és PTR
	    rekordoknak mindenképpen rendben kell lenniük.
	    Az ilyenkor keletkezõ hibaüzenet nem éppen
	    fogja meg a lényeget: <errorname>Kerberos5 refuses
	    authentication because Read req failed: Key table entry not
	    found</errorname>.</para>
	</listitem>

	<listitem>
	  <para>A kulcselosztó számára
	    kliensként viselkedõ bizonyos
	    operációs rendszerek nem
	    állítják be megfelelõen a
	    <command>ksu</command> engedélyeit, ezért nem
	    lehet <username>root</username> jogokkal futtatni.
	    Ezért a <command>ksu</command> parancs nem fog
	    mûködni, ami alapvetõen nem egy rossz
	    ötlet, de idegesítõ.  Ez nem a
	    kulcselosztó hibája.</para>
	</listitem>

	<listitem>
	  <para>Ha a <application>Kerberos</application>
	    <acronym>MIT</acronym> változatát
	    használjuk és a meg akarjuk
	    hosszabbítani a szereplõknek kiadott jegyek
	    élettartamát az alapértelmezett
	    tíz óráról, akkor a
	    <command>kadmin</command> felületén a
	    <command>modify_principal</command> paranccsal tudjuk
	    megváltoztatni mind a kérdéses
	    szereplõ, mind pedig a <username>krbtgt</username>
	    jegyeinek élettartamának maximumát.
	    Ezt követõen a szereplõ a
	    <command>kinit</command> <option>-l</option>
	    opciójával tud egy nagyobb
	    élettartammal rendelkezõ jegyet
	    kérni.</para>
	</listitem>

	<listitem>
	  <note>
	    <para>Amikor egy kulcselosztóval kapcsolatos
	      hibát próbálunk felderíteni a
	      csomagok lehallgatásával, és a
	      munkaállomásunkról kiadjuk a
	      <command>kinit</command> parancsot, akkor arra
	      lehetünk figyelmesek, hogy a <acronym>TGT</acronym>
	      már egybõl a <command>kinit</command>
	      indításakor átküldésre
	      kerül &mdash; még mielõtt
	      egyáltalán megadtuk volna a jelszavunkat!
	      Ezt azzal lehet magyarázni, hogy a
	      <application>Kerberos</application> szerver
	      bármilyen hitelesítetlen
	      kérésre elküld egy
	      <acronym>TGT</acronym>-t (Jegyadó jegy, azaz Ticket
	      Granting Ticket).  Azonban mindegyik ilyen
	      <acronym>TGT</acronym> a felhasználó
	      jelszavából származtatott kulccsal
	      titkosítódik.  Ezért amit a
	      felhasználó jelszóként megad,
	      nem megy el a kulcselosztónak, hanem vele a
	      <command>kinit</command> a már megkapott
	      <acronym>TGT</acronym>-t kódolja ki.  Amennyiben a
	      visszakódolás egy érvényes
	      idõbélyeggel rendelkezõ,
	      használható jegyet eredményez, akkor
	      a felhasználó érvényes
	      <application>Kerberos</application>
	      hitelesítést szerez.  Ez a
	      hitelesítés magában foglal egy
	      kulcsot, amellyel a késõbbiekben a
	      <application>Kerberos</application> szerverekkel tudjuk
	      felvenni biztonságos módon a kapcsolatot,
	      és rajta kívül egy újabb
	      jegyadó jegyet, amelyet a
	      <application>Kerberos</application> szerver a saját
	      kulcsával titkosított.  A
	      titkosítás második vonala a
	      felhasználó számára
	      ismeretlen, de segítségével a
	      <application>Kerberos</application> szerer képes
	      ellenõrizni az egyes jegyadó jegyek
	      hitelességét.</para>
	  </note>
	</listitem>

	<listitem>
	  <para>Ha a jegyeket hosszabb (például egyhetes)
	    élettartammal akarjuk használni és a
	    jegyeket tároló géphez
	    <application>OpenSSH</application>
	    segítségével csatlakozunk, akkor
	    mindenképpen ellenõrizzük, hogy az
	    <filename>sshd_config</filename> állományban a
	    <application>Kerberos</application>
	    <option>TicketCleanup</option>
	    beállításának
	    értéke <literal>no</literal>,
	    máskülönben a kijelentkezés
	    után automatikusan törlõdnek a
	    jegyeink.</para>
	</listitem>

	<listitem>
	  <para>Ne hagyjuk figyelmen kívül azt sem, hogy a
	    befogadó szereplõk is rendelkezhetnek nagyobb
	    élettartamú jegyekkel.  Ha a
	    felhasználónkhoz tartozó szereplõ
	    jegye például egy hét alatt
	    évül el, de a
	    számítógép, amire
	    bejelentkezük, csupán kilenc óráig
	    tartja életben ezeket, akkor a jegyeket
	    tároló gyorsítótárunkban
	    hamarabb elévül a hozzá tartozó
	    jegy, ami miatt pedig hibák keletkeznek.</para>
	</listitem>

	<listitem>
	  <para>Ha a rossz jelszavak használata ellen
	    beállítjuk a <filename>krb5.dic</filename>
	    állományt (errõl a
	    <command>kadmind</command> man oldalán
	    találunk egy rövid leírást), akkor
	    nem szabad elfelejteni, hogy ez csak olyan szereplõkre
	    vonatkozik, akiknek a jelszavára is
	    állítottunk be szabályozásokat.
	    A <filename>krb5.dict</filename> állományok
	    felépítési nem bonyolult: minden sorban
	    egyetlen karakterlánc szerepel.  Érdemes lehet
	    például létrehozni ezen a néven
	    egy szimbolikus linket a
	    <filename>/usr/share/dict/words</filename>
	    állományra.</para>
	</listitem>
      </itemizedlist>

    </sect2>

    <sect2>
      <title>Eltérések az <acronym>MIT</acronym>
	porttól</title>

      <para>A Heimdal és az <acronym>MIT</acronym>
	változatok közti egyik legnagyobb
	eltérés a <command>kadmin</command> programmal
	kapcsolatban van, ami eltérõ (de
	egyébként ekivalens) parancskészlettel
	rendelkezik és más protokollt használ.
	Ennek komoly következménye, hogy ha az
	<acronym>MIT</acronym>-féle kulcselosztót
	használjuk, akkor azt a Heimdal <command>kadmin</command>
	felületével nem tudjuk távolról
	adminisztrálni (és vica versa).</para>

      <para>A kliensalkalmazások paraméterezése is
	eltérhet ugyanazon feladatoknál.  Ezért
	velük kapcsolatban az <acronym>MIT</acronym>
	<application>Kerberos</application> honlapja (<ulink
	url="http://web.mit.edu/Kerberos/www/"></ulink>) a
	mérvadó.  Vigyázzunk az
	elérési utakkal: az <acronym>MIT</acronym> port
	magát alapértelmezés szerint a
	<filename class="directory">/usr/local</filename>
	könyvtárba telepíti, ezért az
	általuk kiváltani kívánt
	<quote>normális</quote> rendszerprogramokat esetleg
	hamarabb találja meg a rendszer, ha nem jól
	állítottuk be a <envar>PATH</envar>
	környezeti változónkat.</para>

      <note>
	<para>Ha nem értjük, hogy miért
	  mûködnek olyan furcsán a
	  <command>telnetd</command> és a
	  <command>klogind</command> által kezelt
	  bejelentkezések, akkor olvassuk el a &os; <filename
	  role="package">security/krb5</filename> portjával
	  települõ <acronym>MIT</acronym> változat
	  <filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>
	  állományt (angolul).  Az a legfontosabb, hogy a
	  <errorname>incorrect permissions on cache file</errorname>
	  hiba eltüntetéséhez a
	  <command>login.krb5</command> binárist kell
	  használnunk, így a továbbított
	  jogosultságoknak megfelelõen át tudja
	  állítani a tulajdonost.</para>
      </note>

      <para>Az <filename>rc.conf</filename> állományt is
	módosítani kell a következõ
	beállítás
	kialakításához:</para>

      <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
kadmind5_server="/usr/local/sbin/kadmind"
kerberos5_server_enable="YES"
kadmind5_server_enable="YES"</programlisting>

      <para>Erre azért van szükség, mert a
	<application>Kerberos</application> <acronym>MIT</acronym>
	változata a <filename
	  class="directory">/usr/local</filename> könyvtáron
	belülre telepíti fel a hozzá tartozó
	alkalmazásokat.</para>

    </sect2>

    <sect2>
      <title>A <application>Kerberos</application>ban talált
	korlátozások enyhítése</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>hiányosságok és
	  korlátozások</secondary>
      </indexterm>

      <sect3>
	<title>A <application>Kerberos</application> a <quote>mindent
	  vagy semmit</quote> megközelítést
	  követi</title>

	<para>A hálózaton minden
	  szolgáltatást módosítanunk kell
	  ahhoz, hogy együtt tudjanak mûködni a
	  <application>Kerberos</application>szal (vagy valamilyen
	  más módon védenünk kell ezeket a
	  támadások ellen), különben a
	  felhasználók jogait el lehet lopni vagy
	  újra fel lehet használni.  Erre jó
	  példa lehet az összes távoli parancssoros
	  elérés (például az
	  <command>rsh</command> valamint a <command>telnet</command>)
	  kerberizálása, de a jelszavakat
	  titkosítatlanul küldõ <acronym>POP3</acronym>
	  levelezõ szerver kihagyása.</para>

      </sect3>

      <sect3>
	<title>A <application>Kerberos</application> az
	  egyfelhasználós munkaállomások
	  számára készült</title>

	<para>Többfelhasználós környezetben a
	  <application>Kerberos</application> már nem annyira
	  biztonságos.  Ez azért mondható el, mert
	  a jegyeket a mindenki által olvasható
	  <filename class="directory">/tmp</filename>
	  könyvtárban tárolja.  Ha az adott
	  felhasználó
	  számítógépét egyszerre
	  több emberrel is megosztja (tehát
	  többfelhasználós), akkor a
	  felhasználó jegyeit egy másik
	  felhasználó bármikor lemásolhatja
	  (ellophatja).</para>

	<para>Ezt a <option>-c</option> opció után
	  megadott állománynévvel vagy
	  (inkább) a <envar>KRB5CCNAME</envar> környezeti
	  változó megfelelõ
	  beállításával tudjuk
	  áthidalni, habár ezt ritkán teszik is
	  meg.  Ha a felhasználók
	  könyvtárában és a megfelelõ
	  engedélyekkel tároljuk ezeket a jegyeket, akkor
	  némileg visszaszoríthatjuk a probléma
	  kockázatát.</para>

      </sect3>

      <sect3>
	<title>A kulcselosztó a rendszer legsebezhetõbb
	  pontja</title>

	<para>A rendszer kialakításából
	  fakadóan a kulcselosztónak legalább
	  annyira megbízhatónak kell lennie, mint a rajta
	  levõ központi jelszóadatbázisnak.  A
	  kulcselosztón semmilyen más
	  szolgáltatás nem futhat és fizikailag is
	  biztonságba kell helyezni.  A kockázat nagy,
	  mivel a <application>Kerberos</application> az összes
	  jelszót ugyanazzal a kulcssal (a
	  <quote>mesterkulcssal</quote>) titkosítja, amelyet a
	  kulcselosztó egy állományban
	  tárol.</para>

	<para>Széljegyzet gyanánt
	  hozzátesszük, hogy a mesterkulcs elvesztése
	  nem annyira rossz, mint azt elsõ gondolnánk.  A
	  mesterkulcsot csupán a
	  véletlenszám-generátor
	  inicializálásához
	  használják a <application>Kerberos</application>
	  adatbázisának titkosításakor.
	  Amíg a kulcselosztóhoz nem tudnak
	  illetéktelenek hozzáférni, addig nem
	  tudnak sokat kezdeni a mesterkulccsal.</para>

	<para>Mellesleg ha a kulcselosztó nem
	  elérhetõ (talán pontosan egy DoS
	  támadás vagy éppen hálózati
	  problémák miatt), akkor a
	  hitelesítés nem végezhetõ el, mivel
	  így a hozzá szükséges
	  hálózati szolgáltatások sem
	  használhatóak.  Ez remek eszköz egy DoS
	  támadáshoz.  Ezen több (egy központi
	  és egy vagy több alárendelt)
	  kulcselosztó telepítésével,
	  valamint a másodlagos vagy tartalékként
	  használt hitelesítési eszközök
	  (a <acronym>PAM</acronym> erre tökéletes)
	  körültekintõ
	  megvalósításával
	  enyhíthetünk.</para>

      </sect3>

      <sect3>
	<title>A <application>Kerberos</application>
	  hiányosságai</title>

	<para>A <application>Kerberos</application> révén
	  a felhasználók,
	  számítógépek és
	  szolgáltatások tudják egymást
	  hitelesíteni.  Ellenben semmilyen eszközt nem
	  kínál fel a kulcselosztó
	  hitelességének ellenõrzésére.
	  Így tehát (például) egy
	  eltérített <command>kinit</command> képes
	  ellopni az összes felhasználói nevet
	  és jelszót.  Az ilyen incidensek
	  elkerülésére a <filename
	  role="package">security/tripwire</filename> és a
	  hozzá hasonló segédprogramok
	  segítségével lehet megõrizni a
	  rendszer sértelenségét.</para>

      </sect3>
    </sect2>

    <sect2>
      <title>Erõforrások és további
	 információk</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>külsõ források</secondary>
      </indexterm>

      <itemizedlist>
	<listitem>
	  <para><ulink
	  url="http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html">
	    A <application>Kerberos</application> GYIK
	    (angolul)</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink
	    url="http://web.mit.edu/Kerberos/www/dialogue.html">Egy
	    hitelesítési rendszer kidolgozása:
	    párbeszéd négy színben
	    (angolul)</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink
	    url="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC
	    1510: A <application>Kerberos</application>
	    hálózati hitelesítési
	    szolgáltatás (V5) (angolul)</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink url="http://web.mit.edu/Kerberos/www/">Az
	    <acronym>MIT</acronym> <application>Kerberos</application>
	    holnapja (angolul)</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink url="http://www.pdc.kth.se/heimdal/">A Heimdal
	    <application>Kerberos</application> honlapja
	    (angolul)</ulink></para>
	</listitem>
      </itemizedlist>

    </sect2>
  </sect1>

  <sect1 id="openssl">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>OpenSSL</title>

    <indexterm>
      <primary>biztonság</primary>
      <secondary>OpenSSL</secondary>
    </indexterm>

    <para>A &os;-hez adott <application>OpenSSL</application> az egyik
      olyan tényezõ, amit a legtöbb
      felhasználó figyelmen kívül hagy.  Az
      <application>OpenSSL</application> egy titkosítási
      réteget nyújt a hagyományos
      kommunikációs csatorna felett, így rengeteg
      hálózati alkalmazásba és
      szolgáltatásba bele lehet szõni.</para>

    <para>Az <application>OpenSSL</application>
      felhasználható többek közt a levelezõ
      kliensek titkosított hitelesítésére,
      hitelkártyás fizetések weben keresztüli
      lebonyolítására alkalmas, és
      még sok minden másra.  Sok port, köztük a
      <filename role="package">www/apache13-ssl</filename> és a
      <filename role="package">mail/sylpheed-claws</filename> is
      felajánlja az <application>OpenSSL</application>
      felhasználását.</para>

    <note>
      <para>A legtöbb esetben a Portgyûjtemény
	megpróbálja lefordítani a <filename
	role="package">security/openssl</filename> portot, hacsak a
	<makevar>WITH_OPENSSL_BASE</makevar> változót
	határozottan a <quote>yes</quote> értékre
	nem állítjuk.</para>
    </note>

    <para>A &os;-hez mellékelt <application>OpenSSL</application>
      ismeri a Secure Sockets Layer v2/v3 (SSLv2/SSLv3) és
      Transport Layer Security v1 (TLSv1)
      hálózatbiztonsági protokollokat, és
      általános célú
      titkosítási könyvtárként is
      alkalmazható.</para>

    <note>
      <para>Noha az <application>OpenSSL</application> ismeri az
	<acronym>IDEA</acronym> algoritmusát is, az Egyesült
	Államokban érvényben levõ szabadalmak
	miatt alapértelmezés szerint nem
	engedélyezett.  A használatához el kell
	olvasni a hozzá tartozó licencet, és ha
	elfogadjuk a benne foglaltakat, akkor állítsuk be
	a <makevar>MAKE_IDEA</makevar> változót a
	<filename>make.conf</filename> állományban.</para>
    </note>

    <para>Az <application>OpenSSL</application>-t leginkább a
      szoftverek tanúsítványainak
      elkészítéséhez
      használják.  Ilyen
      tanúsítvánnyokkal lehet szavatolni, hogy az
      érte felelõs cég vagy egyén
      valóban megbízható és nem
      szélhámos.  Amennyiben a kérdéses
      tanúsítványt nem vizsgálta be
      valamelyik <quote>tanúsítványok
      hitelesítésével foglalkozó
      hatóság</quote> (Certificate Authority, vagy CA),
      akkor errõl általában kap egy
      figyelmeztetést a felhasználó.  A
      tanúsítványokat hitelesítõ
      cégek, mint például a <ulink
      url="http://www.verisign.com">VeriSign</ulink>,
      írják alá ezeket a
      tanúsítványokat és ezzel
      érvényesítik az egyes cégek vagy
      egyének megbízhatóságát.  Ez
      ugyan pénzbe kerül, de használatuk
      egyáltalán nem is kötelezõ.  Azonban az
      átlagosnál paranoidabb felhasználók
      számára megnyugvást jelenthet.</para>

    <sect2>
      <title>Tanúsítványok
	elõállítása</title>

      <indexterm>
	<primary>OpenSSL</primary>
	<secondary>tanúsítványok
	  elõállítása</secondary>
      </indexterm>

      <para>A tanúsítványok
	létrehozására a következõ parancs
	áll rendelkezésre:</para>

      <screen>&prompt.root; <userinput>openssl req -new -nodes -out req.pem -keyout cert.pem</userinput>
Generating a 1024 bit RSA private key
................++++++
.......................................++++++
writing new private key to 'cert.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:<userinput><replaceable>országnév (kétbetûs kóddal)</replaceable></userinput>
State or Province Name (full name) [Some-State]:<userinput><replaceable>állam vagy tartomány teljes neve</replaceable></userinput>
Locality Name (eg, city) []:<userinput><replaceable>település neve</replaceable></userinput>
Organization Name (eg, company) [Internet Widgits Pty Ltd]:<userinput><replaceable>szervezet neve</replaceable></userinput>
Organizational Unit Name (eg, section) []:<userinput><replaceable>szervezeti egység neve</replaceable></userinput>
Common Name (eg, YOUR name) []:<userinput><replaceable>általános név (hálózati név!)</replaceable></userinput>
Email Address []:<userinput><replaceable>e-mail cím</replaceable></userinput>

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<userinput><replaceable>VALAMILYEN JELSZÓ</replaceable></userinput>
An optional company name []:<userinput><replaceable>egy másik szervezet neve</replaceable></userinput></screen>

      <para>Az adatok bekérésére elõtt
	megjelenõ figyelmeztetõ üzenet
	fordítása:</para>

      <screen>
Itt a tanúsítvány igénylésével kapcsolatos információkat kell
megadnunk. Itt egy ún. <quote>ismertetõnevet</quote> (Distinguished
Name, DN) kell megadnunk. Ezen kívül van még néhány más mezõ is, de
ezeket akár üresen is hagyhatjuk. Néhány mezõnek van alapértelmezett
értéke, de ha oda egy pontot írunk, akkor kitöröljük.
</screen>

      <para>A <quote>Common Name</quote> mezõnél
	ellenõrzési okokból egy
	hálózati nevet, tehát a szerverünk
	nevét kell megadnunk.  Ha nem így járunk
	el, akkor lényegében egy használhatatlan
	tanúsítványt kapunk.  További
	opciók is elérhetõek, mint
	például a lejárati idõ (expire time)
	megadása, a titkosítási algoritmus
	megváltoztatása stb.  Ezek teljes listája
	megtalálható az &man.openssl.1; man
	oldalon.</para>

      <para>Az elõbbi parancs kiadása után két
	állománynak kell létrejönnie az
	aktuális könyvtárban.  A
	tanúsítványkérést, vagyis az
	<filename>req.pem</filename> állományt kell
	eljuttatnunk a tanúsítványok
	hitelesítésével foglakozó szervhez,
	aki majd érvényesíti az imént
	megadott adatainkat.  A második,
	<filename>cert.pem</filename> nevû állomány a
	tanúsítványhoz tartozó privát
	kulcs, amit semmilyen körülmények
	között sem szabad kiadnunk.  Ha ez mások
	kezébe kerül, akkor el tudnak játszani
	bennünket (vagy a szerverünket).</para>

      <para>Amikor a hitelesítõ szerv
	aláírása nem feltétlenül
	szükséges, akkor készíthetünk egy
	saját magunk által aláírt
	tanúsítványt is.  Ehhez elõször
	is generálnunk kell egy
	<acronym>RSA</acronym>-kulcsot:</para>

      <screen>&prompt.root; <userinput>openssl dsaparam -rand -genkey -out <filename><replaceable>saját_RSA.kulcs</replaceable></filename> 1024</userinput></screen>

      <para>Most pedig készítsünk el a
	hitelesítõ szerv kulcsát is:</para>

      <screen>&prompt.root; <userinput>openssl gendsa -des3 -out <filename><replaceable>hitelesítõ.kulcs</replaceable></filename> <filename><replaceable>saját_RSA.kulcs</replaceable></filename></userinput></screen>

      <para>Ezzel a kulccsal most gyártsunk le egy
	tanúsítványt:</para>

      <screen>&prompt.root; <userinput>openssl req -new -x509 -days 365 -key <filename><replaceable>hitelesítõ.kulcs</replaceable></filename> -out <filename><replaceable>új.tanúsítvány</replaceable></filename></userinput></screen>

      <para>Ekkor két új állomány keletkezik
	a könyvtárunkban: a hitelesítõ szerv
	aláírása, a
	<filename><replaceable>hitelesítõ.kulcs</replaceable></filename>
	és maga a tanúsítvány, az
	<filename><replaceable>új.tanúsítvány</replaceable></filename>
	állomány.  Ezeket tegyük az <filename
	class="directory">/etc</filename> könyvtáron
	belül egy olyan könyvtárba, amelyet csak a
	<username>root</username> tud olvasni.  A
	<command>chmod</command> paranccsal állítsunk be
	rá 0700-as kódú engedélyeket.</para>

    </sect2>

    <sect2>
      <title>Példa a tanúsítványok
	használatára</title>

      <para>Mire is jók ezek az állományok?
	Például kitûnõen alkalmazhatóak a
	<application>Sendmail</application> levelezõ szerverhez
	beérkezõ kapcsolatot
	titkosítására.  Így
	lényegében felszámoljuk minden olyan
	felhasználó titkosítatlan módon
	zajló hitelesítését, aki a helyi
	levelezõ szerveren keresztül küldi a
	leveleit.</para>

      <note>
	<para>Ez általában nem a legjobb megoldás,
	  mivel egyes levelezõ kliensek hibát jeleneznek a
	  felhasználónak, ha nem rendelkezik a
	  tanúsítvánnyal.  A
	  tanúsítványok
	  telepítésével kapcsolatban olvassuk el a
	  szoftverhez adott leírást.</para>
      </note>

      <para>A helyi <filename>.mc</filename> állományba
	ezeket a sorokat kell beletenni:</para>

      <programlisting>dnl SSL Options
define(`confCACERT_PATH',`/etc/certs')dnl
define(`confCACERT',`/etc/certs/<replaceable>új.tanúsítvány</replaceable>')dnl
define(`confSERVER_CERT',`/etc/certs/<replaceable>új.tanúsítvány</replaceable>')dnl
define(`confSERVER_KEY',`/etc/certs/<replaceable>hitelesítõ.kulcs</replaceable>')dnl
define(`confTLS_SRV_OPTIONS', `V')dnl</programlisting>

      <para>Itt a <filename class="directory">/etc/certs/</filename> az
	a könyvtár, amit tanúsítványok
	és kulcsok helyi tárolására
	használunk.  Végezetül még újra
	kell generálnunk a helyi <filename>.cf</filename>
	állományokat.  Ezt a <filename
	class="directory">/etc/mail</filename> könyvtárban a
	<command>make <maketarget>install</maketarget></command> parancs
	kiadásával könnyen elvégezhetjük.
	Miután ez megtörtént, akkor
	<application>Sendmail</application>hoz tartozó
	démont a <command>make
	<maketarget>restart</maketarget></command>
	paraméterével indíthatjuk
	újra.</para>

      <para>Ha minden jól ment, akkor a
	<filename>/var/log/maillog</filename> állományban
	nem találunk egyetlen hibaüzenetet sem, és a
	<application>Sendmail</application> is megjelenik a futó
	programok között.</para>

      <para>A &man.telnet.1; segédprogrammal így
	probálhatjuk ki a levelezõ szervert:</para>

      <screen>&prompt.root; <userinput>telnet <replaceable>example.com</replaceable> 25</userinput>
Trying 192.0.34.166...
Connected to <hostid role="fqdn">example.com</hostid>.
Escape character is '^]'.
220 <hostid role="fqdn">example.com</hostid> ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT)
<userinput>ehlo <replaceable>example.com</replaceable></userinput>
250-example.com Hello example.com [192.0.34.166], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
<userinput>quit</userinput>
221 2.0.0 <hostid role="fqdn">example.com</hostid> closing connection
Connection closed by foreign host.</screen>

      <para>Ha itt megjelenik a <quote>STARTTLS</quote> sor, akkor
	mindent sikerült beállítanunk.</para>

    </sect2>
  </sect1>

  <sect1 id="ipsec">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Nik</firstname>
	  <surname>Clayton</surname>
	  <affiliation>
	    <address><email>nik@FreeBSD.org</email></address>
	  </affiliation>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>VPN IPsec felett</title>

    <indexterm><primary>IPsec</primary></indexterm>

    <para>VPN létrehozása &os;
      átjárók használatával
      két olyan hálózat között, amelyeket
      egymástól az internet választ el.</para>

    <sect2>
      <sect2info>
	<authorgroup>
	  <author>
	    <firstname>Hiten M.</firstname>
	    <surname>Pandya</surname>
	    <affiliation>
	      <address><email>hmp@FreeBSD.org</email></address>
	    </affiliation>
	    <contrib>Írta: </contrib>
	  </author>
	</authorgroup>
      </sect2info>

      <title>Az IPsec bemutatása</title>

      <para>Ebben a szakaszban az IPsec
	beállításának folyamatát
	vázoljuk fel.  Az IPsec
	beállításához elengedhetetlen, hogy
	tisztában legyünk egy saját rendszermag
	fordításának alapjaival (lásd <xref
	linkend="kernelconfig"/>).</para>

      <para>Az <emphasis>IPsec</emphasis> egy olyan protokoll, amely az
	Internet Protocol (IP) rétegére épül.
	Segítségével két vagy több
	számítógép képes
	biztonságos módon tartani egymással a
	kapcsolatot (innen ered a neve).  A &os; IPsec
	<quote>hálózati protokollkészlete</quote> a
	<ulink url="http://www.kame.net">KAME</ulink>
	implementációjára épül, mely
	egyaránt támogatja az IPv4 és IPv6
	protokollcsaládokat.</para>

      <indexterm>
	<primary>IPsec</primary>
	<secondary>ESP</secondary>
      </indexterm>

      <indexterm>
	<primary>IPsec</primary>
	<secondary>AH</secondary>
      </indexterm>

      <para>Az IPsec két alprotokollból tevõdik
	össze:</para>

      <itemizedlist>
	<listitem>
	  <para><emphasis>A hasznos adat biztonságos
	    becsomagolása (Encapsulated Security Payload,
	    ESP)</emphasis> során egy szimmetrikus
	    kriptográfiai algoritmussal (mint
	    például Blowfish, 3DES) titkosítjuk az
	    IP-csomagok tartalmát, ezáltal
	    megvédjük ezeket az
	    illetéktelenektõl.</para>
	</listitem>
	<listitem>
	  <para>A <emphasis>Hitelesítési fejléc
	    (Authentication Header, AH)</emphasis>
	    használatával megakadályozzuk, hogy az
	    illetéktelenek meghamisítsák az IP
	    csomagok fejlécét.  Ezt úgy
	    érjük el, hogy kiszámolunk egy
	    kriptográfiai ellenõrzõ összeget
	    és az IP-csomagok fejlécének
	    mezõire egy biztonságos függvénnyel
	    generálunk valamilyen ujjlenyomatot.  Az ez
	    után következõ
	    kiegészítõ fejléc tartalmazza ezt
	    az ujjlenyomatot, amellyel a csomag
	    hitelesíthetõ.</para>
	</listitem>
      </itemizedlist>

      <para>Az <acronym>ESP</acronym> és az <acronym>AH</acronym>
	az alkalmazástól függõen
	használható együtt vagy
	külön-külön.</para>

      <indexterm><primary>VPN</primary></indexterm>

      <indexterm>
	<primary>virtuális
	  magánhálózat</primary>
	<see>VPN</see>
      </indexterm>

      <para>Az IPsec akár közvetlenül is
	használható két
	számítógép forgalmának
	titkosítására (ezt
	<emphasis>Szállítási módnak
	(Transport Mode)</emphasis> nevezik), vagy két
	alhálózat között
	építhetünk ki vele <quote>virtuális
	tunneleket</quote>, ami remekül alkalmas két
	vállalati hálózat
	kommunikációjának
	bebiztosítására (ez a <emphasis>Tunnel
	mód (Tunnel Mode)</emphasis>).  Ez utóbbit
	egyszerûen csak <emphasis>Virtuális
	magánhálózatként (Virtual Private
	Network, VPN)</emphasis> emlegetik.  A &os; IPsec
	alrendszerérõl az &man.ipsec.4; man oldalon
	találhatunk további
	információkat.</para>

      <para>A rendszermag IPsec támogatásának
	aktiválásához a következõ
	paramétereket kell beletennünk a
	konfigurációs állományba:</para>

      <indexterm>
	<primary>a rendszermag
	  beállításai</primary>
	<secondary>IPSEC</secondary>
      </indexterm>

      <screen>
options   IPSEC        # IP biztonság
device    crypto
      </screen>

      <indexterm>
	<primary>a rendszermag
	  beállításai</primary>
	<secondary>IPSEC_DEBUG</secondary>
      </indexterm>

      <para>Ha szükségünk van a IPsec
	nyomkövetésére, a következõ
	beállítást is
	hozzátehetjük:</para>

      <screen>
options   IPSEC_DEBUG  # az IP biztonság nyomkövetése
      </screen>

    </sect2>

    <sect2>
      <title>A probléma</title>

      <para>Semmilyen szabvány nem fogalmazza meg mi is
	számít VPN-nek.  A virtuális
	magánhálózatok tucatnyi
	különbözõ technológiával
	valósíthatóak meg, de mindegyiknek megvan a
	maga erõssége és gyengesége.  Ebben a
	szakaszban körvonalazunk egy ilyen helyzetet, valamint a
	benne felépített VPN
	megvalósításához alkalmazott
	stratégiákat.</para>

    </sect2>

    <sect2>
      <title>A forgatókönyv: adott egy otthoni és egy
	vállalati hálózat, amelyek
	külön-külön csatlakoznak az internetre,
	és <acronym>VPN</acronym> használatával
	ezeket egyetlen hálózatként
	szeretnénk használni</title>

      <indexterm>
	<primary>VPN</primary>
	<secondary>létrehozása</secondary>
      </indexterm>

      <para>Elõfeltételezéseink a
	következõek:</para>

      <itemizedlist>
	<listitem>
	  <para>legalább két hálózatunk
	    van;</para>
	</listitem>
	<listitem>
	  <para>magán belül mind a két
	    hálózat IP-t használ;</para>
	</listitem>
	<listitem>
	  <para>mind a két hálózat egy &os;
	    átjárón keresztül csatlakozik az
	    internethez;</para>
	</listitem>
	<listitem>
	  <para>a hálózatok átjárói
	    legalább egy publikus IP-címmel
	    rendelkeznek;</para>
	</listitem>
	<listitem>
	  <para>a hálózatok belsõ címei
	    lehetnek publikus vagy privát IP-címek, nem
	    számít.  Fontos viszont, hogy ezek ne
	    ütközzenek, vagyis ne használja egyszerre
	    mind a kettõ a <hostid
	      role="ipaddr">192.168.1.x</hostid>
	    címtartományt.</para>
	</listitem>
      </itemizedlist>
    </sect2>

    <sect2>
      <sect2info>
	<authorgroup>
	  <author>
	    <firstname>Tom</firstname>
	    <surname>Rhodes</surname>
	    <affiliation>
	      <address><email>trhodes@FreeBSD.org</email></address>
	    </affiliation>
	    <contrib>Írta: </contrib>
	  </author>
	</authorgroup>
      </sect2info>

      <title>Az IPsec beállítása &os; alatt</title>

      <para>Kezdésképpen a
	Portgyûjteménybõl telepítenünk kell a
	<filename role="package">security/ipsec-tools</filename> portot.
	Ez a programcsomag rengeteg olyan alkalmazást tartalmaz,
	amely segítségünkre lehet a
	beállítások elvégzése
	során.</para>

      <para>A következõ lépésben létre
	kell hoznunk két &man.gif.4; típusú
	pszeudoeszközt, melyeken keresztül a két
	hálózat között egy tunnel
	segítségével ki tudjuk
	építeni a szükséges kapcsolatot.
	Ehhez <username>root</username>
	felhasználóként futtassuk a
	következõ parancsokat (a
	<replaceable>belsõ</replaceable> és
	<replaceable>külsõ</replaceable>
	megnevezésû paramétereket
	cseréljük ki a valós belsõ és
	külsõ átjárók
	címeire):</para>

      <screen>&prompt.root; <userinput>ifconfig gif0 create</userinput></screen>
      <screen>&prompt.root; <userinput>ifconfig gif0 <replaceable>belsõ1 belsõ2</replaceable></userinput></screen>
      <screen>&prompt.root; <userinput>ifconfig gif0 tunnel <replaceable>külsõ1 külsõ2</replaceable></userinput></screen>

      <para>Tekintsük például, hogy a
	vállalati <acronym>LAN</acronym> publikus
	<acronym>IP</acronym>-címe <hostid
	  role="ipaddr">172.16.5.4</hostid>, valamint a privát
	<acronym>IP</acronym>-címe <hostid
	  role="ipaddr">10.246.38.1</hostid>.  Az otthoni
	<acronym>LAN</acronym> publikus
	<acronym>IP</acronym>-címe legyen most <hostid
	  role="ipaddr">192.168.1.12</hostid>, valamint a belsõ
	privát <acronym>IP</acronym>-címe pedig <hostid
	  role="ipaddr">10.0.0.5</hostid>.</para>

      <para>Elsõre ez talán még nem teljesen
	érthetõ, ezért az &man.ifconfig.8; parancs
	használatával is nézzük meg a
	példában szereplõ hálózatok
	konfigurációját:</para>

      <programlisting>Az elsõ átjáró:

gif0: flags=8051 mtu 1280
tunnel inet 172.16.5.4 --&gt; 192.168.1.12
inet6 fe80::2e0::81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6
inet 10.246.38.1 --&gt; 10.0.0.5 netmask 0xffffff00

A második átjáró:

gif0: flags=8051 mtu 1280
tunnel inet 192.168.1.12 --&gt; 172.16.5.4
inet 10.0.0.5 --&gt; 10.246.38.1 netmask 0xffffff00
inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4</programlisting>

      <para>Miután elvégeztük az iménti
	beállításokat, a &man.ping.8; paranccsal
	már mind a két privát
	<acronym>IP</acronym>-tartománynak
	elérhetõnek kell lennie, ahogy azt az alábbi
	példa is érzékeltetni
	kívánja:</para>

      <programlisting>otthoni-halo# ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5): 56 data bytes
64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms
64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms
--- 10.0.0.5 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms

vallalati-halo# ping 10.246.38.1
PING 10.246.38.1 (10.246.38.1): 56 data bytes
64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms
64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms
64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms
64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms
64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms
--- 10.246.38.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms</programlisting>

      <para>Az elvárásainknak megfelelõen
	tehát a privát címeken mind a két
	oldalnak képesnek kell lennie <acronym>ICMP</acronym>
	csomagokat küldenie és fogadnia.  A
	következõ lépésben meg kell mondanunk az
	átjáróknak hogyan
	irányítsák a csomagokat a két
	hálózat közti forgalom megfelelõ
	áramlásához.  Ezt az alábbi
	paranccsal elérhetjük el:</para>

	    <screen>&prompt.root; <userinput>vallalati-halo# route add <replaceable>10.0.0.0 10.0.0.5 255.255.255.0</replaceable></userinput></screen>
	    <screen>&prompt.root; <userinput>vallalati-halo# route add net <replaceable>10.0.0.0: gateway 10.0.0.5</replaceable></userinput></screen>

	    <screen>&prompt.root; <userinput>otthoni-halo# route add <replaceable>10.246.38.0 10.246.38.1 255.255.255.0</replaceable></userinput></screen>
	    <screen>&prompt.root; <userinput>otthoni-halo# route add host <replaceable>10.246.38.0: gateway 10.246.38.1</replaceable></userinput></screen>

	    <para>Itt már a belsõ gépeket az
	      átjárókról és az
	      átjárók mögül egyaránt
	      el tudjuk érni.  A következõ példa
	      alapján errõl könnyedén meg is
	      tudunk gyõzõdni:</para>

      <programlisting>vallalati-halo# ping 10.0.0.8
PING 10.0.0.8 (10.0.0.8): 56 data bytes
64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms
64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms
64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms
64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms
64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms
--- 10.0.0.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms

otthoni-halo# ping 10.246.38.107
PING 10.246.38.1 (10.246.38.107): 56 data bytes
64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms
64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms
64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms
64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms
64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms
--- 10.246.38.107 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms</programlisting>

      <para>A tunnelek beállítása volt
	igazából a könnyebb rész, egy
	biztonságos összeköttetés
	kialakítása azonban már valamivel komolyabb
	folyamatot rejt magában.  A most következõ
	konfigurációban erre <quote>elõre
	ismert</quote> (vagyis pre-shared, <acronym>PSK</acronym>)
	<acronym>RSA</acronym>-kulcsokat fogunk használni.  A
	konkrét <acronym>IP</acronym>-címektõl
	eltekintve az átjárókon a
	<filename>/usr/local/etc/racoon/racoon.conf</filename>
	állományok hasonlóan fognak kinézni,
	nagyjából valahogy így:</para>

      <programlisting>path    pre_shared_key "/usr/local/etc/racoon/psk.txt"; # az ismert kulcsot tartalmazó állomány helye
log     debug;	# a naplózás részletességének beállítása: ha végeztünk a teszteléssel és a hibakereséssel, akkor állítsuk át a 'notify' értékre

padding  # ezeket ne nagyon változtassuk meg
{
        maximum_length  20;
        randomize       off;
        strict_check    off;
        exclusive_tail  off;
}

timer	# idõzítési beállítások, állítsuk be igény szerint
{
        counter         5;
        interval        20 sec;
        persend         1;
#       natt_keepalive  15 sec;
        phase1          30 sec;
        phase2          15 sec;
}

listen	# cím [port], ahol a racoon majd válaszolni fog
{
        isakmp          172.16.5.4 [500];
        isakmp_natt     172.16.5.4 [4500];
}

remote  192.168.1.12 [500]
{
        exchange_mode   main,aggressive;
        doi             ipsec_doi;
        situation       identity_only;
        my_identifier   address 172.16.5.4;
        peers_identifier        address 192.168.1.12;
        lifetime        time 8 hour;
        passive         off;
        proposal_check  obey;
#       nat_traversal   off;
        generate_policy off;

                        proposal {
                                encryption_algorithm    blowfish;
                                hash_algorithm          md5;
                                authentication_method   pre_shared_key;
                                lifetime time           30 sec;
                                dh_group                1;
                        }
}

sainfo  (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $hálózat/$hálózati_maszk $típus address $hálózat/$hálózati_maszk $típus
 		  # (a $típus lehet "any" vagy "esp")
{		  # a $hálózat a két összekapcsolni kívánt belsõ hálózat legyen
        pfs_group       1;
        lifetime        time    36000 sec;
        encryption_algorithm    blowfish,3des,des;
        authentication_algorithm        hmac_md5,hmac_sha1;
        compression_algorithm   deflate;
}</programlisting>

      <para>A példában szereplõ összes
	opció részletes kifejtése jóval
	meghaladná ezen leírás kereteit,
	ezért a bõvebb információkkal
	kapcsolatban inkább a <application>racoon</application>
	beállításaihoz tartozó man oldal
	elolvasását javasoljuk.</para>

      <para>A gépek közti hálózati forgalom
	titkosításához be kell még
	állítanunk egy <acronym>SPD</acronym>
	házirendet is, így a &os; és a
	<application>racoon</application> képes kódolni
	és dekódolni a csomagokat.</para>

      <para>Ezt a most következõ, a vállalati
	átjárón találhatóhoz
	hasonló egyszerû shell szkripttel tudjuk
	elvégezni.  Ezt az állományt a rendszer
	indításakor fogjuk felhasználni, melyet
	<filename>/usr/local/etc/racoon/setkey.conf</filename>
	néven mentsünk el:</para>

      <programlisting>flush;
spdflush;
# Az otthoni hálózati felé
spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use;
spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use;</programlisting>

      <para>Ahogy ezzel megvagyunk, a <application>racoon</application>
	az egyes átjárókon a következõ
	paranccsal indítható el:</para>

      <screen>&prompt.root; <userinput>/usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log</userinput></screen>

      <para>A parancs eredménye ennek megfelelõen
	nagyjából a következõ lesz:</para>

      <programlisting>vallalati-halo# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf
Foreground mode.
2006-01-30 01:35:47: INFO: begin Identity Protection mode.
2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon
2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon
2006-01-30 01:36:04: INFO: ISAKMP-SA established 72.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a
2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 72.16.5.4[0]192.168.1.12[0]
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 92.168.1.12[0]-&gt;172.16.5.4[0] spi=28496098(0x1b2d0e2)
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]-&gt;192.168.1.12[0] spi=47784998(0x2d92426)
2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]-&gt;172.16.5.4[0] spi=124397467(0x76a279b)
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]-&gt;192.168.1.12[0] spi=175852902(0xa7b4d66)</programlisting>

      <para>A tunnel megfelelõ mûködését
	úgy tudjuk ellenõrizni, ha átváltunk egy
	másik konzolra és a &man.tcpdump.1; program
	segítségével figyeljük a
	hálózati forgalmat.  A példában
	szereplõ <literal>em0</literal> interfészt
	természetesen ne felejtsük el kicserélni a
	megfelelõ eszköz nevére.</para>

      <screen>&prompt.root; <userinput>tcpdump -i em0 host <replaceable>172.16.5.4 and dst 192.168.1.12</replaceable></userinput></screen>

      <para>Ennek hatására az alábbiakhoz
	hasonló adatoknak kellene megjelennie a konzolon.
	Amennyiben nem ez történik, valamilyen hiba
	történt, ezért meg kell keresnünk azt a
	visszakapott adatok alapján.</para>

      <programlisting>01:47:32.021683 IP vallalatihalozat.com &gt; 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xa)
01:47:33.022442 IP vallalatihalozat.com &gt; 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xb)
01:47:34.024218 IP vallalatihalozat.com &gt; 192.168.1.12.otthonihalozat.com: ESP(spi=0x02acbf9f,seq=0xc)</programlisting>

      <para>Itt már mind a két hálózatnak
	elérhetõnek kell lennie és egyként kell
	látszódnia.  A hálózatokat ezen
	felül még érdemes külön
	védeni egy tûzfallal is.  Ilyenkor a csomagok
	két hálózati közti zavartalan
	oda-vissza vándorlásához további
	szabályokat kell még felvennünk a tûzfal
	szabályrendszerébe.  A &man.ipfw.8; tûzfal
	esetén ez a következõ sorok
	hozzáadását jelenti a tûzfal
	konfigurációs
	állományához:</para>

      <programlisting>ipfw add 00201 allow log esp from any to any
ipfw add 00202 allow log ah from any to any
ipfw add 00203 allow log ipencap from any to any
ipfw add 00204 allow log udp from any 500 to any</programlisting>

      <note>
	<para>A szabályok számozását mindig
	  az adott gép aktuális
	  beállításainak megfelelõen kell
	  módosítani.</para>
      </note>

      <para>A &man.pf.4; és &man.ipf.8;
	felhasználók számára ehhez a
	következõ parancsot javasoljuk:</para>

      <programlisting>pass in quick proto esp from any to any
pass in quick proto ah from any to any
pass in quick proto ipencap from any to any
pass in quick proto udp from any port = 500 to any port = 500
pass in quick on gif0 from any to any
pass out quick proto esp from any to any
pass out quick proto ah from any to any
pass out quick proto ipencap from any to any
pass out quick proto udp from any port = 500 to any port = 500
pass out quick on gif0 from any to any</programlisting>

      <para>Végezetül a következõ sor
	hozzáadásával engedélyezzük az
	<filename>/etc/rc.conf</filename> állományban a
	<acronym>VPN</acronym> indítását a rendszer
	indítása során:</para>

      <programlisting>ipsec_enable="YES"
ipsec_program="/usr/local/sbin/setkey"
ipsec_file="/usr/local/etc/racoon/setkey.conf" # engedélyezzük az spd házirend beállítását a rendszer indításakor
racoon_enable="yes"</programlisting>
    </sect2>
  </sect1>

  <sect1 id="openssh">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Chern</firstname>
	  <surname>Lee</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>OpenSSH</title>

    <indexterm><primary>OpenSSH</primary></indexterm>
    <indexterm>
      <primary>biztonság</primary>
      <secondary>OpenSSH</secondary>
    </indexterm>

    <para>Az <application>OpenSSH</application> olyan
      hálózati kapcsolódási
      eszközök összessége, amivel
      biztonságos módon érhetünk el
      távoli számítógépeket.  Az
      <command>rlogin</command>, <command>rsh</command>,
      <command>rcp</command> és a <command>telnet</command>
      direkt kiváltására használható.
      Emellett SSH-n keresztül TCP/IP kapcsolatok is
      biztonságosan bújtathatóak vagy
      küldhetõek tovább.</para>

    <para>Az <application>OpenSSH</application>-t az OpenBSD projekt
      tartja karban, és az SSH 1.2.12 verziójára
      épül hibajavításokkal és
      frissítésekkel egyetemben.  Az SSH 1 és 2
      protokollokkal egyaránt kompatibilis.</para>

    <sect2>
      <title>Az <application>OpenSSH</application>
	használatának elõnyei</title>

      <para>A hétköznapi esetben, vagyis amikor a
	&man.telnet.1; vagy &man.rlogin.1; alkalmazásokat
	használjuk, az adatok titkosítatlan
	formában közlekednek a hálózaton.  A
	szerver és a kliens közé bárhova
	becsatlakozó hálózati
	kíváncsiskodók így
	könnyedén el tudják lopni a
	felhasználói nevünket és jelszavunkat,
	vagy lényegében bármilyen adatot, ami az
	adott munkamenetben megfordul.  Az
	<application>OpenSSH</application> ennek
	kivédésére kínál fel
	különféle hitelesítési és
	titkosítási eszközöket.</para>

    </sect2>

    <sect2>
      <title>Az sshd engedélyezése</title>

      <indexterm>
	<primary>OpenSSH</primary>
	<secondary>engedélyezés</secondary>
      </indexterm>

      <para>Az <application>sshd</application> a &os;
	telepítésekor jelentkezõ
	<literal>Standard</literal> lehetõségek egyike.  Az
	<application>sshd</application>
	engedélyezését úgy tudjuk
	kideríteni, ha az <filename>rc.conf</filename>
	állományban megkeressük a következõ
	sort:</para>

      <screen>sshd_enable="YES"</screen>

      <para>Ez tölti be a rendszer indításakor az
	&man.sshd.8;-t, az <application>OpenSSH</application>
	démonát.  Vagy az
	<filename>/etc/rc.d/sshd</filename> &man.rc.8; szkript
	segítségével is elindíthatjuk az
	<application>OpenSSH</application>-t:</para>

      <programlisting>/etc/rc.d/sshd start</programlisting>

   </sect2>

    <sect2>
      <title>Az SSH kliens</title>

      <indexterm>
        <primary>OpenSSH</primary>
        <secondary>kliens</secondary>
      </indexterm>

      <para>Az &man.ssh.1; segédprogram az &man.rlogin.1;
	programhoz hasonlóan mûködik.</para>

      <screen>&prompt.root; <userinput>ssh <replaceable>felhasználó@gép.hu</replaceable></userinput>
Host key not found from the list of known hosts.  Are you sure you
want to continue connecting (yes/no)?  <userinput>yes</userinput> Host
'gép.hu' added to the list of known hosts.
felhasználó@gép.hu's password:
<userinput>*******</userinput></screen>

      <para>Az üzenetek fordítása:</para>

      <screen>Nem találtam meg a gépet az ismert gépek között.  Biztosan csatlakozni
akarunk hozzá (igen/nem)?  <userinput>igen</userinput> A 'gép.hu'
felkerült az ismert gépek közé.
Adja meg a felhasználó@gép.hu jelszavát:</screen>

      <para>Bejelentkezés után minden ugyanolyan, mintha
	az <command>rlogin</command> vagy a <command>telnet</command>
	programokat használtuk volna.  Az SSH egy kulcs
	segítségével próbálja
	azonosítani a számítógépeket,
	ezzel ellenõrzi a szerver hitelességét a
	kliensek csatlakozásakor.  A felhasználónak
	ilyenkor elõször mindig <literal>yes</literal>
	választ kell adnia.  A késõbbi
	bejelentkezési kísérletek pedig majd mindig
	az így kapott kulccsal történnek.  Ha
	eltérne a kulcs, akkor az SSH kliens erre figyelmeztetni
	fog minket.  A kulcsok a <filename>~/.ssh/known_hosts</filename>
	vagy az SSH v2 protokoll esetén a
	<filename>~/.ssh/known_hosts2</filename>
	állományba kerülnek elmentésre.</para>

      <para>Alapértelmezés szerint az
	<application>OpenSSH</application> szerverek csak SSH v2
	kapcsolatokat fogadnak el.  Lehetõség szerint a
	kliens is ezt a változatot fogja használni, de ha
	nem sikerül, akkor megpróbálkozik a v1-el.  A
	kliensnek a <option>-1</option> vagy <option>-2</option>
	opciók segítségével elõ is
	lehet írni, hogy az elsõ vagy a második
	változatot használja.  A kliensben az elsõ
	változat támogatását csupán a
	régebbi verziók kompatibilitása miatt
	tartják karban.</para>

    </sect2>

    <sect2>
      <title>Biztonságos másolás</title>

      <indexterm>
	<primary>OpenSSH</primary>
	<secondary>biztonságos másolás</secondary>
      </indexterm>
      <indexterm><primary><command>scp</command></primary></indexterm>

      <para>Az &man.scp.1; parancs az &man.rcp.1; parancshoz
	hasonlóan mûködik: egyik géprõl
	másol a másikra, biztonságosan.</para>

      <screen>&prompt.root; <userinput> scp <replaceable>felhasználó@gép.hu:/COPYRIGHT COPYRIGHT</replaceable></userinput>
<replaceable>felhasználó@gép.hu</replaceable>'s password: <userinput>*******</userinput>
COPYRIGHT            100% |*****************************|  4735
00:00
&prompt.root;</screen>

      <para>Mivel a kulcsot már ismerjük ehhez a
	távoli géphez (az elõbbi
	példából), ezért az &man.scp.1;
	használatakor már ezzel
	hitelesítünk.</para>

      <para>Az &man.scp.1; paraméterei hasonlóak a
	&man.cp.1; parancséhoz: elsõ helyen az
	állomány vagy állományok neveit
	adjuk meg, a másodikon pedig a célt.  Mivel az
	állományokat a hálózaton SSH-n
	keresztül küldik át, ezért az
	állományok neveit
	<option><replaceable>felhasználó@gép</replaceable>:<replaceable>elérési_út</replaceable></option>
	formában kell megadni.</para>

    </sect2>

    <sect2>
      <title>Beállítások</title>

      <indexterm>
	<primary>OpenSSH</primary>
	<secondary>beállítások</secondary>
      </indexterm>

      <para>Az <application>OpenSSH</application> démon és
	kliens rendszerszintû konfigurációs
	állományai az <filename
	  class="directory">/etc/ssh</filename> könyvtárban
	találhatóak.</para>

      <para>Az <filename>ssh_config</filename> tartalmazza a kliens
	beállításait, miközben az
	<filename>sshd_config</filename> tartalmazza a
	démonét.</para>

      <para>Emellett az <filename>rc.conf</filename>
	állományban megadható
	<option>sshd_program</option> (ez alapból a
	<filename>/usr/sbin/sshd</filename>) és
	<option>sshd_flags</option> opciókkal további
	beállítási szinteket
	nyújtanak.</para>

    </sect2>

    <sect2 id="security-ssh-keygen">
      <title>ssh-keygen</title>

      <para>Jelszavak helyett az &man.ssh-keygen.1; programmal a
	felhasználók azonosítására
	DSA- vagy RSA-kulcsokat tudunk készíteni:</para>

      <screen>&prompt.user; <userinput>ssh-keygen -t <replaceable>dsa</replaceable></userinput>
Generating public/private dsa key pair.
Enter file in which to save the key (/home/<replaceable>felhasználó</replaceable>/.ssh/id_dsa):
Created directory '/home/<replaceable>felhasználó</replaceable>/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/<replaceable>felhasználó</replaceable>/.ssh/id_dsa.
Your public key has been saved in /home/<replaceable>felhasználó</replaceable>/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 <replaceable>felhasználó@gép.hu</replaceable>
</screen>

      <para>Az &man.ssh-keygen.1; ekkor a hitelesítésre
	létrehoz egy publikus és egy privát
	kulcsból álló párt.  A privát
	kulcs a <filename>~/.ssh/id_dsa</filename> vagy
	<filename>~/.ssh/id_rsa</filename> állományba
	kerül, miközben a publikus kulcs a
	<filename>~/.ssh/id_dsa.pub</filename> vagy
	<filename>~/.ssh/id_rsa.pub</filename> lesz attól
	függõen, hogy <acronym>DSA</acronym> vagy
	<acronym>RSA</acronym> a kulcs típusa.  A módszer
	mûködéséhez a publikus
	<acronym>DSA</acronym>- vagy <acronym>RSA</acronym>-kulcsot a
	távoli számítógép
	<filename>~/.ssh/authorized_keys</filename>
	állományába kell bemásolni.</para>

      <para>Így tehát a távoli
	számítógépre jelszavak
	alkalmazása helyett SSH-kulccsal tudunk
	belépni.</para>

      <para>Ha az &man.ssh-keygen.1; parancsnak megadunk egy jelmondatot
	is, akkor a felhasználó a privát
	kulcsát csak ennek megadásával tudja
	használni.  A hosszú jelmondatok
	állandó beirogatásától a
	<xref linkend="security-ssh-agent"/> szakaszban hamarosan
	bemutatásra került &man.ssh-agent.1; igyekszik
	megkímélni minket.</para>

      <warning>
	<para>A különbözõ opciók és
	  állományok eltérhetnek a
	  számítógépünkre
	  telepített <application>OpenSSH</application>
	  verziójától függõen.  Ilyen
	  esetben javasolt felkeresni az &man.ssh-keygen.1; man
	  oldalát.</para>
      </warning>

    </sect2>

    <sect2 id="security-ssh-agent">
      <title>Az ssh-agent és az ssh-add</title>

      <para>Az &man.ssh-agent.1; és &man.ssh-add.1;
	segédprogramokkal be tudjuk tölteni az
	<application>SSH</application>-kulcsokat a
	memóriába, amivel elkerülhetjük a
	jelmondat állandó
	begépelését.</para>

      <para>A hitelesítést az &man.ssh-agent.1; program
	kezeli a betöltött privát kulcsok
	alapján.  Az &man.ssh-agent.1;
	használatával egy másik programot is
	elindhatunk, egy parancsértelmezõtõl kezdve egy
	ablakkezelõig szinte bármit.</para>

      <para>Az &man.ssh-agent.1; programot úgy tudjuk egy
	parancsértelmezõben használni, hogy
	elõször is elindítjuk vele az adott
	parancsértelmezõt.  Ezután az &man.ssh-add.1;
	lefuttatásával hozzá kell adnunk egy
	identitást, annak jelmondatának
	megadásával.  Miután ezeket megtettük,
	a felhasználó bármelyik olyan távoli
	gépre be tud jelentkezni, ahol a publikus kulcsát
	ismerik.  Például:</para>

      <screen>&prompt.user; ssh-agent <replaceable>csh</replaceable>
&prompt.user; ssh-add
Enter passphrase for /home/<replaceable>felhasználó</replaceable>/.ssh/id_dsa:
Identity added: /home/<replaceable>felhasználó</replaceable>/.ssh/id_dsa (/home/<replaceable>felhasználó</replaceable>/.ssh/id_dsa)
&prompt.user;</screen>

      <para>Az &man.ssh-agent.1; programot X11-el úgy tudjuk
	használni, ha az <filename>~/.xinitrc</filename>
	állományba tesszük bele.  Ezzel az
	&man.ssh-agent.1; az összes X11-ben indított program
	számára rendelkezésre áll.
	Példának vegyük ezt az
	<filename>~/.xinitrc</filename> állományt:</para>

      <programlisting>exec ssh-agent <replaceable>startxfce4</replaceable></programlisting>

      <para>Így az X11 indulásakor mindig elindul az
	&man.ssh-agent.1;, amely pedig elindítja az
	<application>XFCE</application> alkalmazást.
	Miután átírtuk a saját
	állományunkat, a rendszer
	életbeléptetéséhez indítsuk
	újra az X11-et, az &man.ssh-add.1;
	futtatásával pedig töltsük be az
	összes SSH-kulcsunkat.</para>

    </sect2>

    <sect2 id="security-ssh-tunneling">
      <title>Tunnelezés SSH-val</title>

      <indexterm>
	<primary>OpenSSH</primary>
	<secondary>tunnelezés</secondary>
      </indexterm>

      <para>Az <application>OpenSSH</application>-val létre
	tudunk hozni egy tunnelt, amellyel egy másik protokoll
	adatait tudjuk titkosított módon
	becsomagolni.</para>

      <para>Az alábbi parancs arra utasítja az &man.ssh.1;
	programot, hogy hozzon létre egy tunnelt a
	<application>telnet</application>
	használatához:</para>

       <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5023:localhost:23 felhasználó@izé.mizé.hu</replaceable></userinput>
&prompt.user;</screen>

      <para>Az <command>ssh</command> parancsnak a következõ
	kapcsolókat adtuk meg:</para>

      <variablelist>
	<varlistentry>
	  <term><option>-2</option></term>

	  <listitem>
	    <para>Az <command>ssh</command> parancs a protokoll
	      második változatát használja.
	      (Ne adjuk meg, ha régi SSH szerverekkel
	      dolgozunk.)</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>-N</option></term>

	  <listitem>
	    <para>Tunnel létrehozása.  Ha nem adjuk meg,
	      akkor az <command>ssh</command> egy hagyományos
	      munkamenet felépítését kezdi
	      meg.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>-f</option></term>

	  <listitem>
	    <para>Az <command>ssh</command> a háttérben
	      fusson.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>-L</option></term>

	  <listitem>
	    <para>Egy helyi tunnel a
	    <replaceable>helyiport:távoligép:távoliport</replaceable>
	      felírásban.</para>
	  </listitem>
	  </varlistentry>

	<varlistentry>
	  <term><option>felhasználó@izé.mizé.hu</option></term>

	  <listitem>
	    <para>A távoli SSH szerver.</para>
	  </listitem>
	</varlistentry>
      </variablelist>

      <para>Az SSH által létrehozott járatok
	úgy mûködnek, hogy létrehozunk egy
	csatlakozást a <hostid>localhost</hostid> (a helyi
	gép) megadott portján.  Ezután minden olyan
	kapcsolatot, ami a helyi gép adott portjára
	érkezik, SSH-n keresztül
	átirányítunk a távoli gép
	portjára.</para>

      <para>Ebben a példában a helyi gép
	<replaceable>5023</replaceable> portját
	átirányítjuk a helyi gép
	<replaceable>23</replaceable> portjára.  Mivel a
	<replaceable>23</replaceable> a
	<application>telnet</application> portja, ezért az
	így definiált SSH járattal egy
	biztonságos <application>telnet</application>
	munkamenetet hozunk létre.</para>

      <para>Ezen a módon tetszõleges nem biztonságos
	TCP protokollt, például SMTP-t, POP3-at, FTP-t
	stb.  be tudunk csomagolni.</para>

      <example>
	<title>Biztonságos tunnel létrehozása
	  SSH-val SMTP-hez</title>

	<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 felhasználó@levelezõ.szerver.hu</replaceable></userinput>
<replaceable>felhasználó@levelezõ.szerver.hu</replaceable>'s password: <userinput>*****</userinput>
&prompt.user; <userinput>telnet <replaceable>localhost 5025</replaceable></userinput>
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 <replaceable>levelezõ.szerver.hu</replaceable> ESMTP</screen>

	<para>Az &man.ssh-keygen.1; és további
	  felhasználói hozzáférések
	  alkalmazásával ezen a módon ki tudunk
	  alakítani egy minden további
	  problémától és zûrtõl
	  mentes SSH tunnelezési környezetet.  A jelszavak
	  helyett kulcsokat használunk és minden tunnel
	  külön felhasználóként is
	  futtatható.</para>
      </example>

      <sect3>
	<title>Gyakorlati példák a tunnelek
	  használatára</title>

	<sect4>
	  <title>Egy POP3 szerver biztonságos
	    elérése</title>

	  <para>Tegyük fel, hogy a munkahelyünkön van egy
	    SSH szerver, amire kívülrõl lehet
	    csatlakozni, illetve vele egy hálózatban van
	    egy POP3 levelezõ szerver is.  A munkahelyünk
	    és az otthonunk között levõ
	    hálózati útvonalat részben vagy
	    teljesen nem tartjuk megbízhatónak.
	    Ezért az e-mailjeinket valamilyen biztonságos
	    módon szeretnénk elérni.  Ezt
	    úgy tudjuk megvalósítani, ha
	    otthonról csatlakozunk a munkahelyen levõ SSH
	    szerverre és ezen keresztül érjük a
	    levelezõ szervert.</para>

	  <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>2110:levél.gép.hu:110 felhasználó@ssh-szerver.gép.hu</replaceable></userinput>
<replaceable>felhasználó@ssh-szerver.gép.hu</replaceable>'s password: <userinput>******</userinput></screen>

	  <para>Miután a tunnel létrejött és
	    mûködõképes, állítsuk be
	    a levelezõ kliensünkben, hogy a POP3
	    kéréseket a <hostid>localhost</hostid> 2110
	    portjára küldje.  Innen pedig biztonságos
	    módon megy tovább a
	    <hostid>levél.gép.hu</hostid>
	    címre.</para>

	</sect4>

	<sect4>
	  <title>Egy szigorú tûzfal
	    megkerülése</title>

	  <para>Egyes hálózati adminisztrátorok
	    túlságosan szigorú szabályokat
	    adnak meg a tûzfalban, és nem csak a
	    bejövõ kapcsolatokat szûrik, hanem a
	    kimenõket is.  A távoli gépekhez csak a
	    22 (SSH) és 80 (böngészés)
	    portjaikon tudunk csatlakozni.</para>

	  <para>Mi viszont szeretnénk más (nem
	    egészen a munkánkkal kapcsolatos)
	    szolgáltatásokat is elérni,
	    például egy Ogg Vorbis szerverrõl
	    zenét hallgatni.  Ehhez a szerverhez viszont csak
	    akkor tudnánk csatlakozni, ha a 22 vagy 80 portokon
	    üzemelne.</para>

	  <para>Ezt a problémát úgy oldhatjuk meg,
	    ha felépítünk egy SSH kapcsolatot a
	    hálózatunk tûzfalán
	    kívül levõ
	    számítógéppel és
	    segítségével átbújunk az
	    Ogg Vorbis szerverhez.</para>

	  <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>8888:zene.gép.hu:8000 felhasználó@tûzfalazatlan-rendszer.gép.org</replaceable></userinput>
<replaceable>felhasználó@tûzfalazatlan-rendszer.gép.org</replaceable>'s password: <userinput>*******</userinput></screen>

	  <para>A zenelejátszó kliensüknek adjuk meg
	    a <hostid>localhost</hostid> 8888 portját, amely
	    pedig a tûzfal sikeres
	    kijátszásával
	    továbbítódik a
	    <hostid>zene.gép.hu</hostid> 8000-res
	    portjára.</para>

	</sect4>
      </sect3>
    </sect2>

    <sect2>
      <title>Az <varname>AllowUsers</varname> felhasználói
	beállítás</title>

      <para>Gyakran nem árt korlátozni a
	felhasználók bejelentkezését.  Az
	<literal>AllowUsers</literal> erre tökéletesen
	megfelel.  Például, ha csak <hostid
	role="ipaddr">192.168.1.32</hostid> címrõl
	engedjük bejelentkezni a <username>root</username>
	felhasználót, akkor ehhez valami ilyesmit kell
	beírnunk az <filename>/etc/ssh/sshd_config</filename>
	állományba:</para>

      <programlisting>AllowUsers root@192.168.1.32</programlisting>

      <para>Ezzel pedig csupán nevének
	megadásával engedélyezzük az
	<username>admin</username> felhasználó
	bejelentkezését (bárhonnan):</para>

      <programlisting>AllowUsers admin</programlisting>

      <para>Egy sorban több felhasználó is
	megadható, mint például:</para>

      <programlisting>AllowUsers root@192.168.1.32 admin</programlisting>

      <note>
	<para>Ilyenkor ne felejtsük el megadni az összes
	  bejelentkezésre (valamilyen formában) jogosult
	  felhasználót megadni,
	  máskülönben kizárjuk ezeket.</para>
      </note>

      <para>Miután elvégeztük a szükséges
	változtatásokat az
	<filename>/etc/ssh/sshd_config</filename>
	állományban, utasítsuk az &man.sshd.8;
	démont a konfigurációs
	állományok
	újraolvasására:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/sshd reload</userinput></screen>

    </sect2>

    <sect2>
      <title>Ajánlott olvasnivalók (angolul)</title>

      <para><ulink url="http://www.openssh.com/">OpenSSH</ulink></para>

      <para>&man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1;
	&man.ssh-add.1; &man.ssh.config.5;</para>

      <para>&man.sshd.8; &man.sftp-server.8; &man.sshd.config.5;</para>

    </sect2>
  </sect1>

  <sect1 id="fs-acl">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Az állományrendszerek
      hozzáféréseit vezérlõ
      listák</title>

    <indexterm><primary>ACL</primary></indexterm>

    <para>A &os;&nbsp;5.0 és késõbbi
      változatai különbözõ
      fejlesztéseket hoztak az
      állományrendszerekben, például a
      pillanatképek készítése vagy a
      hozzáférés-vezérlési
      listák (Access Control List, <acronym>ACL</acronym>-ek)
      támogatása.</para>

    <para>A hozzáférés-vezérlési
      listák a szabványos &unix;-os engedély
      modellt bõvítik ki egy igen kompatibilis (&posix;.1e)
      módon.  Használatával a rendszergazdák
      egy sokkal kifinomultabb biztonsági modellt tudhatnak a
      kezük ügyében.</para>

    <para>Az <acronym>UFS</acronym> állományrendszerek
      <acronym>ACL</acronym> támogatását úgy
      tudjuk engedélyezni, ha a rendszermagot az</para>

    <programlisting>options UFS_ACL</programlisting>

    <para>paraméterrel fordítjuk le.  Amennyiben ezt nem
      fordítottuk bele, akkor az <acronym>ACL</acronym>
      támogatással rendelkezõ
      állományrendszerek csatlakoztatása
      során egy figyelmeztetést kapunk.  Ez az
      opció a <filename>GENERIC</filename> rendszermag
      része.  Az <acronym>ACL</acronym> az
      állományrendszeren engedélyezett
      kiterjesztett tulajdonságokra támaszkodik.  Ezeket a
      kiterjesztett tulajdonságokat a következõ
      generációs &unix; állományrendszer, az
      <acronym>UFS2</acronym> már alapból ismeri.</para>

    <note>
      <para><acronym>UFS1</acronym> típusú
	állományrendszereken sokkal nagyobb a
	kiterjesztett tulajdonságok kezelésének
	költsége, mint az <acronym>UFS2</acronym>
	esetében.  Az <acronym>UFS2</acronym> jóval
	nagyobb teljesítménnyel képes dolgozni a
	kiterjesztett tulajdonságokkal.  Emiatt a
	hozzáférés-vezérlési
	listák használatához az
	<acronym>UFS2</acronym> sokkal inkább ajánlott,
	mint az <acronym>UFS1</acronym>.</para>
    </note>

    <para>Az <acronym>ACL</acronym> használatát a
      csatlakoztatáskor megadott <option>acls</option>
      beállítással engedélyezhetjük,
      amelyet érdemes felvennünk az
      <filename>/etc/fstab</filename> állományba.  Ha a
      &man.tunefs.8; segédprogrammal az
      állományrendszer fejlécében levõ
      szuperblokk <acronym>ACL</acronym> kapcsolóját
      átírjuk, akkor ez a beállítás
      automatikussá tehetõ.  A szuperblokk használata
      több okból is ajánlatos:</para>

    <itemizedlist>
      <listitem>
	<para>A csatlakoztatáskor megadott <acronym>ACL</acronym>
	  beállítás nem változtatható
	  egy egyszerû újracsatlakoztatással
	  (&man.mount.8; <option>-u</option>), csak egy teljes
	  leválasztással (&man.umount.8;) és egy
	  friss csatlakoztatással (&man.mount.8;).  Ennek
	  értelmében az <acronym>ACL</acronym>-ek a
	  rendszerindító állományrendszeren
	  a rendszer indulása után nem
	  engedélyezhetõek.  Ám ez azt is jelenti,
	  hogy egy már használatban levõ
	  állományrendszer
	  beállításai sem
	  változtathatóak meg.</para>
      </listitem>

      <listitem>
	<para>Ha a kapcsolót a szuperblokkban
	  állítjuk be, akkor az
	  állományrendszert még akkor is
	  <acronym>ACL</acronym> támogatással
	  csatlakoztatja a rendszer, ha azt nem adtuk meg az
	  <filename>fstab</filename> állományban vagy az
	  eszközeink átrendezõdtek.  Így az
	  állományrendszereket még
	  véletlenül sem tudjuk <acronym>ACL</acronym>
	  használata nélkül csatlakoztatni, ami
	  egyébként így komoly biztonsági
	  problémákat okozhatna.</para>
      </listitem>
    </itemizedlist>

    <note>
      <para>Beállíthatjuk úgy is
	<acronym>ACL</acronym> kezelését, hogy egy friss
	csatlakoztatás nélkül is bekapcsolható
	legyen, azonban az ilyen állományrendszerek
	<acronym>ACL</acronym> nélküli
	csatlakoztatását nem ajánljuk senkinek,
	mivel ha egyszer már engedélyeztük a
	használatukat, majd kikapcsoljuk ezeket és
	végül a kiterjesztett tulajdonságok
	törlése nélkül újra
	engedélyezzük, akkor nagyon könnyen
	pórul járhatunk.  Ha elkezdtük
	használni az <acronym>ACL</acronym>-eket egy
	állományrendszeren, akkor ne tiltsuk le ezeket,
	mert az így keletkezõ
	állományvédelem nem feltétlenül
	lesz kompatibilis a felhasználók által
	beállítottakkal, és az
	<acronym>ACL</acronym> újraengedélyezése a
	változásaik elõtti korábbi
	<acronym>ACL</acronym> engedélyeket fogja
	visszaállítani az állományokra,
	aminek hatása kiszámíthatatlan.</para>
    </note>

    <para>A hozzáférés-vezérlési
      listákat használó
      állományrendszerek esetén egy
      <literal>+</literal> (plusz) jellel
      ábrázolják a kiterjesztett
      engedélyeket.  Például:</para>

    <programlisting>drwx------  2 robert  robert  512 Dec 27 11:54 private
drwxrwx---+ 2 robert  robert  512 Dec 23 10:57 könyvtár1
drwxrwx---+ 2 robert  robert  512 Dec 22 10:20 könyvtár2
drwxrwx---+ 2 robert  robert  512 Dec 27 11:57 könyvtár3
drwxr-xr-x  2 robert  robert  512 Nov 10 11:54 public_html</programlisting>

    <para>Láthatjuk, hogy a
      <filename class="directory">könyvtár1</filename>,
      <filename class="directory">könyvtár2</filename> és
      <filename class="directory">könyvtár3</filename>
      könyvtárakhoz tartoznak <acronym>ACL</acronym>
      típusú engedélyek, míg a
      <filename class="directory">public_html</filename> könyvtárhoz
      nem.</para>

    <sect2>
      <title>Az <acronym>ACL</acronym>-ek használata</title>

      <para>Az állományrendszerben található
	<acronym>ACL</acronym> engedélyeket a &man.getfacl.1;
	segédprogrammal nézhetjük meg.
	Például a
	<filename><replaceable>próba</replaceable></filename>
	állomány <acronym>ACL</acronym> engedélyeit
	a következõ paranccsal tudjuk megnézni:</para>

      <screen>&prompt.user; <userinput>getfacl <filename><replaceable>próba</replaceable></filename></userinput>
	#file:<replaceable>próba</replaceable>
	#owner:1001
	#group:1001
	user::rw-
	group::r--
	other::r--</screen>

      <para>Egy állomány <acronym>ACL</acronym>
	engedélyeit a &man.setfacl.1; segédprogrammal
	tudjuk megváltoztatni.  Figyeljük meg:</para>

      <screen>&prompt.user; <userinput>setfacl -k <filename><replaceable>próba</replaceable></filename></userinput></screen>

      <para>A <option>-k</option> opció törli az összes
	<acronym>ACL</acronym> alapú engedélyt egy
	állományról vagy
	állományrendszerrõl.  Ennél viszont
	sokkal hasznosabb a <option>-b</option> opció
	használata, mivel az meghagyja az <acronym>ACL</acronym>
	mûködéséhez szükséges
	alapvetõ mezõket.</para>

      <screen>&prompt.user; <userinput>setfacl -m u:trhodes:rwx,group:web:r--,o::--- <filename><replaceable>próba</replaceable></filename></userinput></screen>

      <para>Ebben a fenti parancsban a <option>-m</option> opciót
	pedig arra használtuk, hogy módosítsuk az
	alapértelmezett <acronym>ACL</acronym>
	bejegyzéseket.  Mivel az ezt megelõzõ
	parancsban teljesen töröltük még az
	elõredefiniált bejegyzéseket is, ez a parancs
	a megadott paraméterekkel kiegészítve
	ezeket vissza fogja állítani.  Ügyeljünk
	arra, hogy ha olyan felhasználót vagy csoportot
	adunk meg, ami nem létezik a rendszerben, akkor a
	szabvány kimenetre egy <errorname>Invalid
	argument</errorname> hibaüzenetet kapunk.</para>

    </sect2>
  </sect1>

  <sect1 id="security-portaudit">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>A külsõ programok biztonsági
      problémáinak figyelése</title>

    <indexterm><primary>Portaudit</primary></indexterm>

    <para>Az utóbbi években a biztonsági
      kérdésekkel foglalkozó világban
      számos fejlesztésre került sor a
      sebezhetõségi figyelmeztetések
      feldolgozásában.  Manapság
      tulajdonképpen bármilyen operációs
      rendszer fokozott veszélynek teszik ki magát a
      külsõ programok telepítésével
      és használatával.</para>

    <para>A sebezhetõségekrõl beszámoló
      értesítések a biztonság egyik
      alapköve, azonban a &os; projekt nem tud ilyen
      jelentéseket kiadni a &os; alaprendszerén
      kívül minden egyes külsõ
      alkalmazáshoz.  Azonban lehetõségünk van
      enyhíteni a külsõ csomagok
      sebezhetõségén és figyelmeztetni a
      rendszergazdákat az ismert biztonsági
      problémákra.  A &os;-nek van egy
      <application>Portaudit</application> nevû
      segédprogramja, amit kizárólag erre a
      célra hoztak létre.</para>

    <para>A <filename role="package">ports-mgmt/portaudit</filename> port
      egy adatbázist használ, ahol a &os;
      biztonsági csapata és a portok fejlesztõi
      tartják karban az ismert biztonsági
      problémákat.</para>

    <para>A <application>Portaudit</application>
      használatának megkezdéséhez
      telepítsük a
      Portgyûjteménybõl:</para>

    <screen>&prompt.root; <userinput>cd /usr/ports/ports-mgmt/portaudit &amp;&amp; make install clean</userinput></screen>

    <para>A telepítési folyamat során a
      &man.periodic.8; konfigurációs
      állományai is frissítõdnek, így a
      <application>Portaudit</application> is lefut a napi
      biztonsági ellenõrzések folyamán.
      Gondoskodjunk róla, hogy a <username>root</username>
      felhasználónak levélben elküldött a
      napi biztonsági értesítéseket rendesen
      elolvassuk.  Nincs szükségünk további
      beállításokra.</para>

    <para>A telepítés után a rendszergazda a
      következõ paranccsal tudja frissíteni a
      saját adatbázispéldányát
      és megnézni a pillanatnyilag telepített
      csomagok ismert sebezhetõségeit:</para>

    <screen>&prompt.root; <userinput>portaudit -Fda</userinput></screen>

    <note>
      <para>Ez az adatbázis a &man.periodic.8; minden egy
	futásakor magától frissül,
	ezért ez a parancs lényegében
	elhagyható.  Egyedül a soronkövetkezõ
	példákhoz kell kiadni.</para>
    </note>

    <para>A Portgyûjteménybõl telepített
      külsõ alkalmazások
      megbízhatóságának
      ellenõrzését az alábbi parancs
      kiadásával bármikor
      elvégezhetjük:</para>

    <screen>&prompt.root; <userinput>portaudit -a</userinput></screen>

    <para>A <application>Portaudit</application> ennek
      hatására valahogy így fogja
      megjeleníteni a sebezhetõ csomagokat:</para>

    <programlisting>Affected package: cups-base-1.1.22.0_1
Type of problem: cups-base -- HPGL buffer overflow vulnerability.
Reference: &lt;http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html&gt;

1 problem(s) in your installed packages found.

You are advised to update or deinstall the affected package(s) immediately.</programlisting>

    <para>Fordítása:</para>

    <programlisting>Érintett csomag: cups-base-1.1.22.0_1
A probléma jellege: cups-base -- HPGL puffer túlcsordulási sebezhetõség.
Link: &lt;http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html&gt;

A telepített csomagokkal kapcsolatban 1 problemát találtam.

Javasoljuk, hogy az érintett csomagokat azonnal frissítse vagy távolítsa el.</programlisting>

    <para>Ha a böngészõnket az itt megadott
      címre irányítjuk, akkor megismerhetjük a
      kérdéses sebezhetõség pontosabb
      részleteit.  Ezen az oldalon megtalálhatjuk a hiba
      által érintett verziókat a &os; portok
      verziója szerint, illetve más olyan honlapokat, ahol
      biztonsági figyelmeztetéseket
      találhatunk.</para>

    <para>Röviden összefoglalva, a
      <application>Portaudit</application> egy komoly
      segédeszköz és hitetlenül hasznos
      kiegészítõje a
      <application>Portupgrade</application> portnak.</para>

  </sect1>

  <sect1 id="security-advisories">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>A &os; biztonsági figyelmeztetései</title>

    <indexterm><primary>a FreeBSD biztonsági
      figyelmeztetései</primary></indexterm>

    <para>A &os; több más kereskedelmi
      minõségû operációs rendszerhez
      hasonlóan <quote>Biztonsági
      figyelmeztéseket</quote> (Security Advisory) ad ki.  Ezek a
      figyelmeztetések általában megjelennek a
      biztonsággal foglalkozó levelezési
      listákon és a hivatkozott hibák
      kijavítása után a megfelelõ
      kiadások hibajegyzékében is.  Ebben a
      szakaszban megismerjük és értelmezzük
      ezeket a figyelmeztetéseket, valamint megtudhatjuk, milyen
      lépéseket kell megtennünk a rendszerünk
      kijavításához.</para>

    <sect2>
      <title>Hogyan épül fel egy
	figyelmeztetés?</title>

      <para>A &os; biztonsági figyelmeztetései az
	alább látható formában jelennek meg,
	amit mi most a &a.security-notifications.name; levelezési
	listáról kölcsönöztünk.</para>

      <programlisting>=============================================================================
&os;-SA-XX:XX.UTIL                                     Security Advisory
                                                          The &os; Project

Topic:          denial of service due to some problem<co id="co-topic"/>

Category:       core<co id="co-category"/>
Module:         sys<co id="co-module"/>
Announced:      2003-09-23<co id="co-announce"/>
Credits:        Person@EMAIL-ADDRESS<co id="co-credit"/>
Affects:        All releases of &os;<co id="co-affects"/>
                &os; 4-STABLE prior to the correction date
Corrected:      2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE)
                2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6)
                2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15)
                2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8)
                2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18)
                2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21)
                2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33)
                2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43)
                2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39)<co id="co-corrected"/>
<acronym>CVE</acronym> Name:	CVE-XXXX-XXXX<co id="co-cve"/>

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
http://www.FreeBSD.org/security/.

I.   Background<co id="co-backround"/>


II.  Problem Description<co id="co-descript"/>


III. Impact<co id="co-impact"/>


IV.  Workaround<co id="co-workaround"/>


V.   Solution<co id="co-solution"/>


VI.  Correction details<co id="co-details"/>


VII. References<co id="co-ref"/></programlisting>


      <calloutlist>
	<callout arearefs="co-topic">
	  <para>A <literal>Topic</literal> mezõben olvashatjuk
	    pontosan mi is maga a probléma.  Alapvetõen
	    bemutatja az érintett biztonsági
	    figyelmeztetést és megemlíti a
	    sebezhetõ segédprogramot.</para>
	</callout>

	<callout arearefs="co-category">
	  <para>A <literal>Category</literal> mezõ hivatkozik a
	    rendszer azon részére, amelyre a hiba
	    kihatással lehet.  Értéke lehet
	    <literal>core</literal>, <literal>contrib</literal> vagy
	    <literal>ports</literal>.  A <literal>core</literal>
	    kategória azt jelzi, hogy a sebezhetõség
	    a &os; legfontosabb komponenseit érinti.  A
	    <literal>contrib</literal> kategória a &os; projekt
	    számára felajánlott szoftverek, mint
	    például a <application>sendmail</application>
	    sebezhetõségére utal.
	    Végezetül a <literal>ports</literal>
	    kategória jelzi, hogy a sebezhetõség
	    valamelyik, a Portgyûjteményben szereplõ
	    szoftverre érvényes.</para>
	</callout>

	<callout arearefs="co-module">
	  <para>A <literal>Module</literal> mezõ a sebezhetõ
	    komponens helyét nevezi meg, például
	    <literal>sys</literal>.  Ebben a példában azt
	    láthatjuk, hogy a <literal>sys</literal> modul a
	    hibás.  Ezért a sebezhetõség egy
	    rendszermagban használt komponenst
	    érint.</para>
	</callout>

	<callout arearefs="co-announce">
	  <para>Az <literal>Announced</literal> mezõ a
	    biztonsági figyelmeztetés
	    kiadásának vagy széleskörû
	    kihirdetésének dátumát
	    rögzíti.  Ez azt jelenti, hogy a
	    biztonsági csapat meggyõzõdött a
	    probléma létezésérõl
	    és a hibát orvosoló
	    javítás már felkerült a &os;
	    forráskódjába.</para>
	</callout>

	<callout arearefs="co-credit">
	  <para>A <literal>Credits</literal> mezõ azokat az
	    egyéneket vagy szervezeteket említi meg, akik
	    észlelték a sebezhetõséget
	    és jelentették.</para>
	</callout>

	<callout arearefs="co-affects">
	  <para>Az <literal>Affects</literal> mezõben
	    megadják, hogy a &os; melyik kiadásaira van
	    hatással a sebezhetõség.  Ha a
	    rendszermag esetén lefuttatjuk az
	    <command>ident</command> parancsot az érintett
	    állományokra, akkor megtudhatjuk a pontos
	    revíziójukat.  A portoknál a
	    verziószám a port neve után szerepel a
	    <filename class="directory">/var/db/pkg</filename>
	    könyvtárban.  Ha a rendszerünket nem
	    frissítettük <acronym>CVS</acronym>-rõl
	    és fordítottuk újra, akkor nagy a
	    valószínûsége, hogy a
	    sebezhetõség minket is érint.</para>
	</callout>

	<callout arearefs="co-corrected">
	  <para>A <literal>Corrected</literal> mezõ tartalmazza a a
	    kijavítás dátumát,
	    idejét, idõzónáját
	    és az ezt tartalmazó kiadást.</para>
	</callout>

	<callout arearefs="co-cve">
	  <para>Az ismert sebezhetõségek
	    adatbázisában (Common Vulnerabilities
	    Database, CVD) használt azonosítási
	    információk alapján végzett
	    keresések számára fenntartott.</para>
	</callout>

	<callout arearefs="co-backround">
	  <para>A <literal>Background</literal> mezõ adja meg
	    részleteiben a sebezhetõ programmal kapcsolatos
	    tudnivalókat.  Az esetek
	    többségében itt írják le,
	    hogy miért jött létre az adott
	    eszköz a &os;-ben, mire használják
	    és hogyan keletkezett.</para>
	</callout>

	<callout arearefs="co-descript">
	  <para>A <literal>Problem Description</literal> mezõ a
	    biztonsági rést részletezi.  Ebben a
	    részben szerepelhet a hibás
	    kódrészlet vagy akár még az is,
	    hogy miként kell vele elõidézni a
	    hibát.</para>
	</callout>

	<callout arearefs="co-impact">
	  <para>Az <literal>Impact</literal> mezõ a probléma
	    lehetséges hatásait írja
	    körül a rendszerben.  Ez például
	    lehet egy DoS támadás, speciális
	    engedélyek ellopása vagy akár a
	    rendszeradminisztrátori jogok
	    megszerzése.</para>
	</callout>

	<callout arearefs="co-workaround">
	  <para>A <literal>Workaround</literal> mezõ igyekszik
	    elfogadható megoldást nyújtani a
	    rendszerük frissítésére
	    képtelen rendszergazdák számára.
	    Ennek oka lehet az idõ rövidsége, a
	    hálózati elérhetõség vagy
	    más okokból fakadó
	    elcsúszás.  Ennek ellenére a
	    biztonsági kérdéseket sosem szabad
	    félvállról venni, ezért a
	    sebezhetõ rendszereket vagy ki kell javítani
	    vagy valamilyen módon meg kell kerülni a
	    biztonsági rés
	    kialakulását.</para>
	</callout>

	<callout arearefs="co-solution">
	  <para>A <literal>Solution</literal> mezõ
	    utasításokkal segít a rendszer
	    kijavítását.  Ez egy
	    lépésrõl lépésre tesztelt
	    és ellenõrzött módszer, amellyel a
	    rendszerünket megfelelõen ki tudjuk
	    javítani és biztonságossá
	    tenni.</para>
	</callout>

	<callout arearefs="co-details">
	  <para>A <literal>Correction Details</literal> mezõ
	    mutatja a <acronym>CVS</acronym>-ág vagy
	    kiadás nevét, amelyben a pontokat
	    aláhúzásra cserélték.
	    Ezenkívül még az egyes ágakban az
	    érintett állományok
	    revízióját is mutatja.</para>
	</callout>

	<callout arearefs="co-ref">
	  <para>A <literal>References</literal> mezõ
	    általában a témával kapcsolatos
	    további forrásokat kínálja fel
	    <acronym>URL</acronym>, könyv, levelezési lista
	    vagy hírcsoport formájában.</para>
	</callout>
      </calloutlist>

    </sect2>
  </sect1>

  <sect1 id="security-accounting">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>A futó programok nyilvántartása</title>

    <indexterm>
      <primary>a futó programok
	nyilvántartása</primary>
    </indexterm>

    <para>A futó programok nyilvántartása olyan
      biztonsági módszer, ahol a rendszergazda figyelemmel
      kíséri a rendszer használatban levõ
      erõforrásait, a felhasználók közti
      megoszlását, gondoskodik a rendszer
      felügyeletérõl és valamennyire nyomon
      követi a felhasználók parancsait.</para>

    <para>Ennek a módszernek egyaránt megvannak a maga
      elõnyei és hátrányai.  Az egyik
      elõnye, hogy a használatával a behatolás
      egészen a betörés pontjáig
      visszakövethetõ.  Hátranya viszont, hogy a
      futó programok nyilvántartása rengeteg
      mennyiségû naplót generál és
      ehhez sok lemezterületre lesz szükségünk.
      Ebben a szakaszban végigjárjuk a programok
      nyilvántartásának alapjait.</para>

    <sect2>
      <title>A futó programok
	nyilvántartásának
	engedélyezése és használata</title>

      <para>A futó programok nyilvántartását
	elõször engedélyeznünk kell.  Ehhez a
	következõ parancsokat kell kiadnunk:</para>

      <screen>&prompt.root; <userinput>touch <filename>/var/account/acct</filename></userinput>

&prompt.root; <userinput>accton <filename>/var/account/acct</filename></userinput>

&prompt.root; <userinput>echo 'accounting_enable="YES"' &gt;&gt; <filename>/etc/rc.conf</filename></userinput></screen>

      <para>Miután aktiváltuk, a
	nyilvántartást elkezdi számbavenni a
	processzor kihasználtságát, a parancsokat
	stb.  A nyilvántartás emberek
	számára nem olvasható formátumban
	készül, ezért csak az &man.sa.8;
	segédprogrammal tudjuk megnézni.  Ha nem adunk meg
	neki semmilyen opciót, akkor az <command>sa</command>
	kilistázza a felhasználónkénti
	hívásokat, az összes eltelt idõt
	percben, a teljes processzor- és
	felhasználói idõt percben, az I/O
	mûveletek átlagos számát stb.</para>

      <para>A kiadott parancsokról a &man.lastcomm.1; programmal
	tudunk tájékozódni.  A
	<command>lastcomm</command> segítségével ki
	tudjuk íratni a felhasználók adott
	terminálon kiadott parancsait is, mint
	például:</para>

      <screen>&prompt.root; <userinput>lastcomm ls
	<username>trhodes</username> ttyp1</userinput></screen>

      <para>Ezzel megjelenik a <username>trhodes</username> nevû
	felhasználó <literal>ttyp1</literal>
	terminálon kiadott összes ismert
	<command>ls</command> parancsa.</para>

      <para>Számos hasznos beállítást
	és hozzájuk tartozó leírást
	találhatunk még a &man.lastcomm.1;, &man.acct.5;
	és &man.sa.8; man oldalakon.</para>

    </sect2>
  </sect1>
</chapter>