path: root/nl_NL.ISO8859-1/books/handbook/security/chapter.sgml

<!--
     The FreeBSD Dutch Documentation Project

     $FreeBSD$
     $FreeBSDnl: nl_NL.ISO8859-1/books/handbook/security/chapter.sgml,v 1.77 2005/10/04 21:04:27 siebrand Exp $
     gebaseerd op: 1.282
-->

<chapter id="security">
  <chapterinfo>
    <authorgroup>
      <author>
	<firstname>Matthew</firstname>
	<surname>Dillon</surname>
	<contrib>Veel uit dit hoofdstuk is overgenomen uit de
	  security(7) handboekpagina van </contrib>
      </author>
    </authorgroup>
    <authorgroup>
      <author>
	<firstname>Siebrand</firstname>
	<surname>Mazeland</surname>
	<contrib>Vertaald door </contrib>
      </author>
    </authorgroup>
  </chapterinfo>

  <title>Beveiliging</title>

  <indexterm><primary>beveiliging</primary></indexterm>

  <sect1 id="security-synopsis">
    <title>Overzicht</title>

    <para>Dit hoofdstuk biedt een basisinleiding in
      systeembeveiligingsconcepten, een aantal goede basisregels en
      een paar gevorderde onderwerpen binnen &os;.  Veel van de
      onderwerpen die worden behandeld kunnen ook worden toegepast op
      systemen en internet in het algemeen.  Het internet is niet
      langer een <quote>vriendelijke</quote> omgeving waar iedereen
      een goede buur wil zijn.  Het beveiligen van een systeem is
      onontbeerlijk als gegevens, intellectueel eigendom, tijd en wat
      dan ook uit de handen van hackers c.s. gehouden moeten
      worden.</para>

    <para>&os; biedt veel hulpmiddelen en mechanismen om te zorgen
      voor de integriteit en veiligheid van een systeem en
      netwerk.</para>

    <para>Na het lezen van dit hoofdstuk weet de lezer:</para>

    <itemizedlist>
      <listitem>
	<para>Van basis systeembeveiligingsconcepten in relatie tot
	  &os;;</para>
      </listitem>

      <listitem>
	<para>Meer over verschillende versleutelingsmechanismen die
	  beschikbaar zijn in &os; zoals <acronym>DES</acronym> en
	  <acronym>MD5</acronym>;</para>
      </listitem>

      <listitem>
	<para>Hoe eenmalige wachtwoordauthenticatie opgezet kan
	  worden;</para>
      </listitem>

      <listitem>
	<para>Hoe <acronym>TCP</acronym> Wrappers in te stellen voor
	  gebruik met <command>inetd</command>;</para>
      </listitem>

      <listitem>
	<para>Hoe <application>KerberosIV</application> op &os;
	  releases eerder dan 5.0 opgezet kan worden;</para>
      </listitem>

      <listitem>
	<para>Hoe <application>Kerberos5</application> op &os;&nbsp;5.0
	  release en verder opgezet kan worden;</para>
      </listitem>

      <listitem>
	<para>Hoe IPsec wordt ingesteld en hoe een
	  <acronym>VPN</acronym> op te zetten tussen &os; en
	  &microsoft.windows; machines;</para>
      </listitem>

      <listitem>
	<para>Hoe <application>OpenSSH</application>, &os;'s
	  <acronym>SSH</acronym> implementatie, in te stellen en te
	  gebruiken;</para>
      </listitem>

      <listitem>
	<para>Wat filesysteem <acronym>ACL</acronym>s zijn en hoe
	  die te gebruiken;</para>
      </listitem>

      <listitem>
	<para>Hoe het hulpprogramma
	  <application>Portaudit</application> gebruikt kan worden om
	  softwarepakketten uit de Portscollectie te auditen;</para>
      </listitem>

      <listitem>
	<para>Hoe om te gaan met publicaties van &os;
	  beveiligingswaarschuwingen;</para>
      </listitem>

      <listitem>
	<para>Iets van Procesaccounting en hoe dat is in te schakelen
	  in &os;.</para>
      </listitem>
    </itemizedlist>

    <para>Er wordt aangenomen dat de lezer van dit hoofdstuk:</para>

    <itemizedlist>
      <listitem>
	<para>Basisbegrip heeft van &os; en internetconcepten.</para>
      </listitem>
    </itemizedlist>

    <para>In dit boek worden nog meer onderwerpen met betrekking tot
      beveiliging beschreven.  Zo wordt bijvoorbeeld Verplichte
      Toegangscontrole (Mandatory Access Control) besproken in <xref
	linkend="mac"> en Internet Firewalls in <xref
	linkend="firewalls">.</para>
  </sect1>

  <sect1 id="security-intro">
    <title>Introductie</title>

    <para>Beveiliging is een taak die begint en eindigt bij de
      systeembeheerder.  Hoewel alle BSD &unix; multi-user systemen
      enige inherente beveiliging kennen, is het bouwen en onderhouden
      van additionele beveiligingsmechanismen om de gebruikers
      <quote>eerlijk</quote> te houden waarschijnlijk een van de
      zwaarste taken voor de systeembeheerder.  Machines zijn zo veilig
      als ze gemaakt worden en beveiligingsoverwegingen staan altijd op
      gespannen voet met de wens om gebruiksvriendelijkheid.  &unix;
      systemen zijn in het algemeen in staat tot het tegelijkertijd
      uitvoeren van een enorm aantal processen en veel van die
      processen acteren als server - daarmee wordt bedoeld dat externe
      entiteiten er verbindingen mee kunnen maken en ertegen kunnen
      praten.  Nu de minicomputers en mainframes van gisteren de
      desktops van vandaag zijn en computers onderdeel zijn van
      netwerken en internetwerken, wordt beveiliging nog
      belangrijker.</para>

    <para>Beveiliging kan het beste ingesteld worden door een gelaagde
      <quote>ui</quote>-aanpak.  In een notendop zijn er het beste net
      zoveel lagen van beveiliging als handig is en daarna dient het
      systeem zorgvuldig gemonitord te worden op inbraken.  Het is niet
      wenselijk beveiliging te overontwerpen, want dat doet afbreuk aan
      de detectiemogelijkheden en detectie is een van de belangrijkste
      aspecten van beveiligingsmechanismen.  Zo heeft het bijvoorbeeld
      weinig zin om de <literal>schg</literal> vlaggen (zie
      &man.chflags.1;) op ieder binair bestand op een systeem te
      zetten, omdat het, hoewel dit misschien tijdelijk binaire
      bestanden beschermt, een inbreker in een systeem ervan kan
      weerhouden een eenvoudig te detecteren wijziging te maken
      waardoor beveiligingsmaatregelen de inbreker misschien
      helemaal niet ontdekken.</para>

    <para>Systeembeveiliging heeft ook te maken met het omgaan met
      verschillende vormen van aanvallen, zoals een poging om een
      systeem te crashen of op een andere manier onstabiel te maken,
      zonder te proberen de <username>root</username> account aan te
      vallen (<quote>break root</quote>).  Aandachtspunten voor
      beveiliging kunnen opgesplitst worden in categorie&euml;n:</para>

    <orderedlist>
      <listitem>
	<para>Ontzeggen van dienst aanvallen (<quote>Denial of
	    service</quote>).</para>
      </listitem>

      <listitem>
	<para>Gebruikersaccounts compromitteren.</para>
      </listitem>

      <listitem>
	<para><username>root</username> compromitteren via
	  toegankelijke servers.</para>
      </listitem>

      <listitem>
	<para><username>root</username> compromitteren via
	  gebruikersaccounts.</para>
      </listitem>

      <listitem>
	<para>Achterdeur cre&euml;ren (<quote>Backdoor</quote>).</para>
      </listitem>
    </orderedlist>

    <indexterm>
      <primary>DoS aanvallen</primary>

      <see>Ontzegging van Dienst (DoS)</see>
    </indexterm>

    <indexterm>
      <primary>beveiliging</primary>

      <secondary>Ontzegging van Dienst DoS aanvallen</secondary>

      <see>(DoS)</see>
    </indexterm>

    <indexterm><primary>Ontzegging van Dienst (DoS)</primary></indexterm>

    <para>Een ontzegging van dienst (DoS) aanval is een techniek die
      de machine middelen ontneemt.  In het algemeen zijn DoS aanvallen
      brute kracht mechanismen die proberen de machine te crashen of op
      een andere manier onbruikbaar te maken door de machine of de
      netwerkcode te overvragen.  Sommige DoS aanvallen proberen
      misbruik te maken van bugs in de netwerkcode om een machine met
      een enkel pakket te crashen.  Zoiets kan alleen gerepareerd
      worden door een aanpassing aan de kernel te maken.  Aanvallen op
      servers kunnen vaak hersteld worden door op de juiste wijze
      opties in stellen om de belasting van servers te limiteren in
      ongunstige omstandigheden.  Omgaan met brute kracht aanvallen is
      lastiger.  Zo is een aanval met gefingeerde pakketten
      (<quote>spoofed-packet</quote>) vrijwel niet te stoppen, behalve
      dan door het systeem van internet los te koppelen.  Misschien
      gaat de machine er niet door plat, maar het kan wel een volledige
      internetverbinding verzadigen.</para>

    <indexterm>
      <primary>beveiliging</primary>

      <secondary>account compromittering</secondary>
    </indexterm>

    <para>Een gecompromitteerde gebruikersaccount komt nog veel vaker
      voor dan een DoS aanval.  Veel systeembeheerders draaien nog
      steeds standaard <application>telnetd</application>,
      <application>rlogind</application>,
      <application>rshd</application> en
      <application>ftpd</application> servers op hun machines.  Deze
      servers communiceren standaard niet over beveiligde verbindingen.
      Het resultaat is dat als er een redelijk grote gebruikersgroep
      is, er altijd wel van een of meer van de gebruikers die van
      afstand op dat systeem aanmelden (wat toch de meest normale en
      makkelijke manier is om op een systeem aan te melden) het
      wachtwoord is afgeluisterd (<quote>sniffed</quote>).  Een
      oplettende systeembeheerder analyseert zijn logboekbestanden om
      te zoeken naar verdachte bronadressen, zelfs als het om
      succesvolle aanmeldpogingen gaat.</para>

    <para>Uitgangspunt moet altijd zijn dat als een aanvaller toegang
      heeft tot een gebruikersaccount, de aanvaller de
      <username>root</username> account kan compromitteren.  In
      werkelijkheid is het wel zo dat voor een systeem dat goed
      beveiligd is en goed wordt onderhouden, toegang tot een
      gebruikersaccount niet automatisch betekent dat de aanvaller ook
      <username>root</username> privileges kan krijgen.  Het is van
      belang dit onderscheid te maken, omdat een aanvaller zonder
      toegang tot <username>root</username> in het algemeen zijn sporen
      niet kan wissen en op z'n best wat kan rommelen met bestanden van
      de gebruiker of de machine kan crashen.  Gecompromitteerde
      gebruikersaccounts zijn vrij normaal omdat gebruikers normaliter
      niet de voorzorgsmaatregelen nemen die systeembeheerders
      nemen.</para>

    <indexterm>
      <primary>beveiliging</primary>

      <secondary>achterdeuren</secondary>
    </indexterm>

    <para>Systeembeheerders moeten onthouden dat er in potentie heel
      veel manieren zijn om toegang tot <username>root</username> te
      krijgen.  Een aanvaller zou het
      <username>root</username> wachtwoord kunnen kennen, een bug kunnen
      ontdekken in een dienst die onder <username>root</username>
      draait en daar via een netwerkverbinding op in kunnen breken of
      een aanvaller zou een probleem kunnen met een suid-root programma
      dat de aanvaller in staat stelt <username>root</username> te
      worden als hij eenmaal toegang heeft tot een gebruikersaccount.
      Als een aanvaller een manier heeft gevonden om
      <username>root</username> te worden op een machine, dan hoeft
      hij misschien geen achterdeur (<quote>backdoor</quote>) te
      installeren.  Veel bekende manieren die zijn gevonden om
      <username>root</username> te worden, en weer zijn afgesloten,
      vereisen veel werk van de aanvaller om zijn rommel achter zich op
      te ruimen, dus de meeste aanvallers installeren een achterdeur.
      Een achterdeur biedt de aanvaller een manier om makkelijk opnieuw
      <username>root</username> toegang tot het systeem te krijgen, maar
      dit geeft de slimme systeembeheerder ook een makkelijke manier om
      de inbraak te ontdekken.  Het onmogelijk maken een achterdeur te
      installeren zou best wel eens nadelig kunnen zijn voor
      beveiliging, omdat hiermee nog niet het gat gedicht is waardoor
      er in eerste instantie is ingebroken.</para>

    <para>Beveiligingsmaatregelen moeten altijd ge&iuml;mplementeerd
      worden in een meerlagenmodel en worden als volgt
      gecategoriseerd:</para>

    <orderedlist>
      <listitem>
	<para>Beveiligen van <username>root</username> en
	  medewerkersaccounts.</para>
      </listitem>

      <listitem>
	<para>Beveiligen van <username>root</username> &ndash; servers
	  onder <username>root</username> en suid/sgid binaire
	  bestanden.</para>
      </listitem>

      <listitem>
	<para>Beveiligen van gebruikersaccounts.</para>
      </listitem>

      <listitem>
	<para>Beveiligen van het wachtwoordbestand.</para>
      </listitem>

      <listitem>
	<para>Beveiligen van de kern van de kernel, ruwe apparaten
	  en bestandssystemen.</para>
      </listitem>

      <listitem>
	<para>Snel detecteren van ongeoorloofde wijzigingen aan het
	  systeem.</para>
      </listitem>

      <listitem>
	<para>Paranoia.</para>
      </listitem>
    </orderedlist>

    <para>In het volgende onderdeel van dit hoofdstuk gaan we dieper in
      op de bovenstaande punten.</para>
  </sect1>

  <sect1 id="securing-freebsd">
    <title>&os; beveiligen</title>

    <indexterm>
      <primary>beveiliging</primary>

      <secondary>&os; beveiligen</secondary>
    </indexterm>

    <note>
      <title>Commando vs. protocol</title>

      <para>In dit hele document gebruiken we
	<application>vette</application> tekst om te verwijzen naar een
	commando of applicatie en een <command>monospaced</command>
	lettertype om te verwijzen naar specifieke commando's.
	Protocollen staan vermeld in een normaal lettertype.  Dit
	typografische onderscheid is zinvol omdat bijvoorbeeld ssh
	zowel een protocol als een commando is.</para>
    </note>

    <para>In de volgende onderdelen behandelen we de methodes uit de
      <link linkend="security-intro">vorige paragraaf</link> om een
      &os; systeem te beveiligen.</para>

    <sect2 id="securing-root-and-staff">
      <title>Beveiligen van <username>root</username> en
	medewerkersaccounts.</title>

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

      <para>Om te beginnen: doe geen moeite om medewerkersaccounts
	te beveiligen als de <username>root</username> account niet
	beveiligd is.  Op de meeste systemen heeft de
	<username>root</username> account een wachtwoord.  Als eerste
	moet aangenomen worden dat dit wachtwoord
	<emphasis>altijd</emphasis> gecompromitteerd is.  Dit betekent
	niet dat het wachtwoord verwijderd moet worden.  Het wachtwoord
	is namelijk bijna altijd nodig voor toegang via het console van
	de machine.  Het betekent wel dat het niet mogelijk gemaakt
	moet worden om het wachtwoord te gebruiken buiten het console
	om en mogelijk zelfs niet via het &man.su.1; commando.  Pty's
	moeten bijvoorbeeld gemarkeerd staan als onveilig
	(<quote>insecure</quote>) in het bestand
	<filename>/etc/ttys</filename> zodat direct aanmelden met
	<username>root</username> via <command>telnet</command>
	of <command>rlogin</command> niet wordt toegestaan.  Als andere
	aanmelddiensten zoals <application>sshd</application> gebruikt
	worden, dan hoort direct aanmelden via
	<username>root</username> uitgeschakeld staat.  Dit kan door
	het bestand <filename>/etc/ssh/sshd_config</filename> te
	bewerken en ervoor te zorgen dat
	<literal>PermitRootLogin</literal> op <literal>NO</literal>
	staat.  Dit moet gebeuren voor iedere methode van toegang
	&ndash; diensten zoals FTP worden vaak over het hoofd gezien.
	Het direct aanmelden van <username>root</username> hoort alleen
	te mogen via het systeemconsole.</para>

      <indexterm><primary><groupname>wheel</groupname></primary></indexterm>

      <para>Natuurlijk moet een systeembeheerder de mogelijkheid hebben
	om <username>root</username> te worden.  Daarvoor kunnen een
	paar gaatjes geprikt worden.  Maar dan moet ervoor gezorgd
	worden dat er voor deze gaatjes extra aanmelden met een
	wachtwoord nodig is.  E&eacute;n manier om
	<username>root</username> toegankelijk te maken is door het
	toevoegen van de juiste medewerkersaccounts aan de
	<groupname>wheel</groupname> groep (in
	<filename>/etc/group</filename>).  De medewerkers die lid zijn
	van de groep <groupname>wheel</groupname> mogen
	<command>su</command>&ndash;en naar <username>root</username>.
	Maak medewerkers nooit <quote>native</quote> lid van de groep
	<groupname>wheel</groupname> door ze in de groep
	<groupname>wheel</groupname> te plaatsen in
	<filename>/etc/group</filename>.  Medewerkersaccounts horen lid
	te zijn van de groep <groupname>staff</groupname> en horen dan
	pas toegevoegd te worden aan de groep
	<groupname>wheel</groupname> in het bestand
	<filename>/etc/group</filename>.  Alleen medewerkers die ook
	echt toegang tot <username>root</username> nodig hebben horen
	in de groep <groupname>wheel</groupname> geplaatst te worden.
	Het is ook mogelijk, door een authenticatiemethode als Kerberos
	te gebruiken, om het bestand <filename>.k5login</filename> van
	Kerberos in de <username>root</username> account te gebruiken
	om een &man.ksu.1; naar <username>root</username> toe te staan
	zonder ook maar iemand lid te maken van de groep
	<groupname>wheel</groupname>.  Dit is misschien wel een
	betere oplossing, omdat het
	<groupname>wheel</groupname>-mechanisme het nog steeds mogelijk
	maakt voor een inbreker <username>root</username> te breken als
	de inbreker een wachtwoordbestand te pakken heeft gekregen en
	toegang kan krijgen tot &eacute;&eacute;n van de
	medewerkersaccounts.  Hoewel het instellen van het
	<groupname>wheel</groupname>-mechanisme beter is dan niets, is
	het niet per se de meest veilige optie.</para>

      <!-- XXX:
	   This will need updating depending on the outcome of PR
	   bin/71147.  Personally I know what I'd like to see, which
	   puts this in definite need of a rewrite, but we'll have to
	   wait and see.  ceri@
      -->

      <para>Een indirecte manier om de medewerkersaccounts te
	beveiligen en uiteindelijk ook de toegang tot
	<username>root</username>, is het gebruik van alternatieve
	aanmeldmethodes en de wachtwoorden van de medewerkersaccounts,
	zoals het heet <quote>uit te sterren</quote>.  Met &man.vipw.8;
	kan iedere instantie van een gecodeerd wachtwoord vervangen
	worden door een enkel <quote><literal>*</literal></quote>
	karakter.  Met dit commando worden
	<filename>/etc/master.passwd</filename> en de
	gebruikers/wachtwoord database bijgewerkt om het aanmelden met
	wachtwoord uit te schakelen.</para>

      <para>Een regel voor een medewerkersaccount als:</para>

      <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>

      <para>Zou veranderd moeten worden naar:</para>

      <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>

      <para>Door deze wijziging kan niet langer normaal aangemeld
	worden omdat het gecodeerde wachtwoord nooit gelijk is aan de
	<quote><literal>*</literal></quote>.  Nu dit is gebeurd, moeten
	medewerkers een ander mechanisme gebruiken om zich te
	authenticeren zoals &man.kerberos.1; of &man.ssh.1; met een
	publiek/privaat sleutelpaar.  Bij het gebruik van iets als
	Kerberos moeten gewoonlijk de machines waarop de Kerberos
	server draait en het desktop werkstation beveiligd worden.  Bij
	het gebruik van een publiek/privaat sleutelpaar met ssh, moet
	in het algemeen de machine <emphasis>van</emphasis> waar wordt
	aangemeld beveiligd worden (meestal een werkstation).  Het is
	mogelijk nog een beveiligingslaag toe te voegen door het
	sleutelpaar te beschermen met een wachtwoord als het aan te
	maken met &man.ssh-keygen.1;.  Door accounts van medewerkers
	<quote>uit te sterren</quote> is het ook gegarandeerd dat ze
	alleen aan kunnen melden door gebruik te maken van de veilige
	toegangsmethodes die de beheerder heeft ingesteld.  Hierdoor
	worden alle medewerkers gedwongen veilige, gecodeerde
	verbindingen te gebruiken voor al hun sessies.  Daarmee wordt
	een belangrijk beveiligingsgat gesloten dat veel indringers
	gebruiken: snuffelen aan het netwerk vanaf een niet-relevante
	minder veilige machine.</para>

      <para>Meer indirecte beveiligingsmechanismen hebben ook als
	uitgangspunt dat vanaf een zwaarder beveiligde machine wordt
	aangemeld op een minder beveiligd systeem.  Als een
	hoofdserver bijvoorbeeld allerlei servers draait, zou het
	werkstation er geen moeten draaien.  Om een werkstation
	redelijk veilig te laten zijn, dienen er zo min mogelijk
	servers op te draaien, bij voorkeur zelfs geen en er zou een
	schermbeveiliging met wachtwoordbeveiliging op moeten draaien.
	Maar als een aanvaller fysieke toegang heeft tot een
	werkstation, dan kan hij elke beveiliging die erop is
	aangebracht omzeilen.  Dit probleem dient echt overwogen te
	worden, net als het feit dat de meeste aanvallen van een
	afstand plaatsvinden, via het netwerk, door mensen die geen
	fysieke toegang hebben tot werkstations of servers.</para>

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

      <para>Het gebruik van iets als Kerberos geeft de mogelijkheid
	om het wachtwoord van de account van een medewerker buiten
	gebruik te stellen of te wijzigen op &eacute;&eacute;n plaats,
	waarbij het meteen actief is op alle machines waarop die
	medewerker een account heeft.  Als de account van een
	medewerker gecompromitteerd raakt, moet vooral de mogelijkheid
	om per direct het wachtwoord voor machines te kunnen aanpassen
	niet onderschat worden.  Met afzonderlijke wachtwoorden kan het
	veranderen van wachtwoorden op N systemen een puinhoop worden.
	Met Kerberos kunnen ook wachtwoordrestricties opgelegd worden:
	het is niet alleen mogelijk om een Kerberos
	<quote>ticket</quote> na een bepaalde tijd te laten verlopen,
	maar het Kerberos systeem kan afdwingen dat de gebruiker na een
	bepaalde tijd een nieuw wachtwoord kiest (na bijvoorbeeld een
	maand).</para>
    </sect2>

    <sect2>
      <title>Beveiligen van <username>root</username> &ndash; servers
	onder <username>root</username> en suid/sgid binaire
	bestanden</title>

      <indexterm><primary><command>ntalk</command></primary></indexterm>

      <indexterm><primary><command>comsat</command></primary></indexterm>

      <indexterm><primary><command>finger</command></primary></indexterm>

      <indexterm><primary>zandbakken</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>Een voorzichtige systeembeheerder draait alleen die servers
	die nodig zijn, niets meer, niets minder.  Bedenk dat
	servers van derde partijen vaak de meeste neiging hebben tot
	het vertonen van bugs.  Zo staat bijvoorbeeld het draaien van
	een oude versie van <application>imapd</application> of
	<application>popper</application> gelijk aan het weggeven van
	de <username>root</username> account aan de hele wereld.  Draai
	nooit een server die niet zorgvuldig is onderzocht.  Veel
	servers hoeven niet te draaien als <username>root</username>.
	Zo kunnen de <application>ntalk</application>,
	<application>comsat</application> en
	<application>finger</application> daemons bijvoorbeeld draaien
	in speciale gebruikerszandbakken
	(<quote><firstterm>sandboxes</firstterm></quote>).  Een zandbak
	is niet perfect, tenzij er heel veel moeite gedaan wordt, maar
	de meerlagenbenadering blijft bestaan: als iemand via een
	server die in een zandbak draait weet in te breken, dan moeten
	ze eerst nog uit de zandbak komen.  Hoe groter het aantal lagen
	is waar een inbreker doorheen moet, hoe kleiner de kans op
	succes is.  <username>root</username> gaten zijn historisch
	gezien aanwezig geweest in vrijwel iedere server die ooit als
	<username>root</username> gedraaid heeft, inclusief de
	basisservers van een systeem.  Op een machine waarop mensen
	alleen aanmelden via <application>sshd</application> en nooit
	via <application>telnetd</application> of
	<application>rshd</application> of
	<application>rlogind</application> dienen die servers
	uitgeschakeld te worden!</para>

      <para>&os; draait <application>ntalkd</application>,
	<application>comsat</application> en
	<application>finger</application> tegenwoordig standaard in een
	zandbak.  Een ander programma dat misschien beter in een
	zandbak kan draaien is &man.named.8;.  In
	<filename>/etc/defaults/rc.conf</filename> staat als commentaar
	welke parameters er nodig zijn om
	<application>named</application> in een zandbak te draaien.
	Afhankelijk van of het een nieuwe systeeminstallatie of het
	bijwerken van een bestaand systeem betreft, worden de speciale
	gebruikersaccounts die bij die zandbakken horen misschien niet
	ge&iuml;nstalleerd.  Een voorzichtige systeembeheerder
	onderzoekt en implementeert zandbakken voor servers waar dat
	ook maar mogelijk is.</para>

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

      <para>Er zijn een aantal diensten die vooral niet in een zandbak
	draaien: <application>sendmail</application>,
	<application>popper</application>,
	<application>imapd</application>,
	<application>ftpd</application> en andere.  Voor sommige
	servers zijn alternatieven, maar dat kost misschien meer tijd
	dan er te besteden is (gemak dient de mens).  Het kan voorkomen
	dat deze servers als <username>root</username> moeten draaien
	en dat er vertrouwd moet worden op andere mechanismen om een
	inbraak via die servers te detecteren.</para>

      <para>De andere grote mogelijkheid voor <username>root</username>
	gaten in een systeem zijn de suid-root en sgid binaire
	bestanden die ge&iuml;nstalleerd zijn op een systeem.  Veel van
	die bestanden, zoals <application>rlogin</application>, staan
	in <filename>/bin</filename>, <filename>/sbin</filename>,
	<filename>/usr/bin</filename> of
	<filename>/usr/sbin</filename>.  Hoewel het niet 100% veilig
	is, mag aangenomen worden dat de suid en sgid binaire bestanden
	van een standaardsysteem redelijk veilig zijn.  Toch worden er
	nog wel eens <username>root</username> gaten gevonden in deze
	bestanden.  Zo is er in 1998 een <username>root</username> gat
	gevonden in <literal>Xlib</literal> waardoor
	<application>xterm</application> (die normaliter suid is)
	kwetsbaar bleek.  Een voorzichtige systeembeheerder kiest voor
	<quote>better to be safe than sorry</quote> door de suid
	bestanden die alleen medewerkers hoeven uit te voeren aan een
	speciale groep toe te wijzen en de suid bestanden die niemand
	gebruikt te lozen (<command>chmod 000</command>).  Een server
	zonder monitor heeft normaal gezien
	<application>xterm</application> niet nodig.  Sgid bestanden
	kunnen bijna net zo gevaarlijk zijn.  Als een inbreker een
	sgid-kmem stuk kan krijgen, dan kan hij wellicht
	<filename>/dev/kmem</filename> lezen en dus het gecodeerde
	wachtwoordbestand, waardoor mogelijk ieder account met
	een wachtwoord besmet is.  Een inbreker toegang tot de groep
	<literal>kmem</literal> kan krijgen, zou bijvoorbeeld mee
	kunnen kijken met de toetsaanslagen die ingegeven worden via de
	pty's, inclusief die pty's die gebruikt worden door gebruikers
	die via beveiligde methodes aanmelden.  Een inbreker die
	toegang krijgt tot de groep <groupname>tty</groupname> kan naar
	bijna alle tty's van gebruikers schrijven.  Als een gebruiker
	een terminalprogramma of een terminalemulator met een
	toetsenbordsimulatieoptie draait, dan kan de inbreker in
	potentie een datastroom genereren die ervoor zorgt dat de
	terminal van de gebruiker een commando echot, dat dan wordt
	uitgevoerd door die gebruiker.</para>
    </sect2>

    <sect2 id="secure-users">
      <title>Beveiligen van gebruikersaccounts</title>

      <para>Gebruikersaccounts zijn gewoonlijk het meest lastig om te
	beveiligen.  Hoewel er allerlei Draconische maatregelen genomen
	kunnen worden met betrekking tot de medewerkers en hun
	wachtwoorden <quote>weggesterd</quote> kunnen worden, gaat dat
	waarschijnlijk niet lukken met de gewone gebruikersaccounts.
	Als er toch voldoende vrijheid is, dan prijst de beheerder zich
	gelukkig en is het misschien toch mogelijk de accounts
	voldoende te beveiligen.  Als die vrijheid er niet is, dan
	moeten die accounts gewoon netter gemonitord worden.  Het
	gebruik van <application>ssh</application> en
	<application>Kerberos</application> voor gebruikersaccounts is
	problematischer vanwege het extra beheer en de ondersteuning,
	maar nog steeds een prima oplossing in vergelijking met een
	gecodeerd wachtwoordbestand.</para>
    </sect2>

    <sect2>
      <title>Beveiligen van het wachtwoordbestand</title>

      <para>De enige echte oplossing is zoveel mogelijk wachtwoorden
	<literal>*</literal> maken en <application>ssh</application>
	of <application>Kerberos</application> gebruiken voor toegang
	tot die accounts.  Hoewel een gecodeerd wachtwoordbestand
	(<filename>/etc/spwd.db</filename>) alleen gelezen kan worden
	door <username>root</username>, is het wel mogelijk dat een
	inbreker leestoegang krijgt tot dat bestand zonder dat de
	aanvaller root-schrijftoegang krijgt.</para>

      <para>Beveiligingsscripts moeten altijd controleren op en
	rapporteren over wijzigingen in het wachtwoordbestand (zie ook
	<link linkend="security-integrity">Bestandsintegriteit
	Controleren</link> hieronder).</para>
    </sect2>

    <sect2>
      <title>Beveiligen van de kern van de kernel, ruwe apparaten en
	bestandssystemen</title>

      <para>Als een aanvaller toegang krijgt tot
	<username>root</username> dan kan hij ongeveer alles, maar er
	zijn een paar slimmigheidjes.  Zo hebben bijvoorbeeld de meeste
	moderne kernels een ingebouwde pakketsnuffeldriver
	(<quote>packet sniffing</quote>).  Bij &os; is dat het
	<devicename>bpf</devicename> apparaat.  Een inbreker zal in het
	algemeen proberen een pakketsnuffelaar te draaien op een
	gecompromitteerde machine.  De inbreker hoeft deze mogelijkheid
	niet te hebben en bij de meeste systemen is het niet verplicht
	het <devicename>bpf</devicename> apparaat mee te
	compileren.</para>

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

      <para>Maar zelfs als het <devicename>bpf</devicename>
	apparaat is uitgeschakeld, dan zijn er nog
	<filename>/dev/mem</filename> en
	<filename>/dev/kmem</filename>.  De inbreker kan namelijk nog
	schrijven naar ruwe schrijfapparaten.  En er is ook nog een
	optie in de kernel die modulelader (<quote>module
	  loader</quote>) heet, &man.kldload.8;.  Een ondernemende
	  inbreker kan een KLD module gebruiken om zijn eigen
	<devicename>bpf</devicename> apparaat of een ander
	snuffelapparaat te installeren in een draaiende kernel.  Om
	deze problemen te voorkomen, moet de kernel op een hoger
	veiligheidsniveau draaien, ten minste securelevel 1.  Het
	securelevel wordt ingesteld met <command>sysctl</command> op de
	<varname>kern.securelevel</varname> variabele.  Als securelevel
	op 1 staat, is het niet langer mogelijk te schrijven naar ruwe
	apparaten en speciale <command>chflags</command> vlaggen als
	<literal>schg</literal> worden dan afgedwongen.  Ook dient de
	vlag <literal>schg</literal> gezet te worden op kritische
	opstartbestanden, mappen en scriptbestanden.  Alles dat wordt
	uitgevoerd voordat het securelevel wordt ingesteld.  Dit is
	misschien wat overdreven en het wordt lastiger een systeem te
	vernieuwen als dat in een hoger securelevel draait.  Er is een
	compromis mogelijk door het systeem in een hoger securelevel te
	draaien maar de <literal>schg</literal> vlag niet op alle
	systeembestanden en mappen te zetten die maar te vinden zijn.
	<filename>/</filename> en <filename>/usr</filename> zouden ook
	als alleen-lezen gemount kunnen worden.  Het is nog belangrijk
	om op te merken dat als de beheerder te Draconisch omgaat
	met dat wat hij wil beschermen, hij daardoor kan veroorzaken
	dat die o-zo belangrijke detectie van een inbraak wordt
	misgelopen.</para>
    </sect2>

    <sect2 id="security-integrity">
      <title>Bestandsintegriteit controleren: binaire bestanden,
	instellingenbestanden, enzovoort</title>

      <para>Als puntje bij paaltje komt kan de kern van een systeem
	maar tot een bepaald punt beveiligd worden zonder dat het
	minder prettig werken wordt.  Zo werk het zetten van de
	<literal>schg</literal> bit met <command>chflags</command> op
	de meeste bestanden in <filename>/</filename> en
	<filename>/usr</filename> waarschijnlijk averechts, omdat,
	hoewel de bestanden beschermd zijn, ook het venster waarin
	detectie plaats kan vinden is gesloten.  De laatste laag van
	beveiliging is waarschijnlijk de meest belangrijke: detectie.
	Alle overige beveiliging is vrijwel waardeloos (of nog erger:
	geeft een vals gevoel van veiligheid) als een mogelijke inbraak
	niet gedetecteerd kan worden.  Een belangrijk doel van het
	meerlagenmodel is het vertragen van een aanvaller, nog meer dan
	hem te stoppen, om de detectiekant van de vergelijking de kans
	te geven hem op heterdaad te betrappen.</para>

      <para>De beste manier om te zoeken naar een inbraak is zoeken
	naar gewijzigde, missende of onverwachte bestanden.  De beste
	manier om te zoeken naar gewijzigde bestanden is vanaf een
	ander (vaak gecentraliseerd) systeem met beperkte toegang.
	Met zelfgeschreven scripts op dat extra beveiligde systeem met
	beperkte toegang ben is een beheerder vrijwel onzichtbaar voor
	mogelijke aanvallers en dat is belangrijk.  Om het nut te
	maximaliseren moeten in het algemeen dat systeem met beperkte
	toegang best veel rechten gegeven worden op de andere machines
	in het netwerk, vaak via een alleen-lezen NFS export van de
	andere machines naar het systeem met beperkte toegang of door
	<application>ssh</application> sleutelparen in te stellen om
	het systeem met beperkte toegang een
	<application>ssh</application> verbinding te laten maken met de
	andere machines.  Buiten het netwerkverkeer, is NFS de minst
	zichtbare methode.  Hierdoor kunnen de bestandssystemen
	op alle client machines vrijwel ongezien gemonitord worden.
	Als de server met beperkte toegang verbonden is met de client
	machines via een switch, dan is de NFS methode vaak de beste
	keus.  Als de server met beperkte toegang met de andere
	machines is verbonden via een hub of door meerdere routers, dan
	is de NFS methode wellicht niet veilig genoeg (vanuit een
	netwerk standpunt) en kan beter <application>ssh</application>
	gebruikt worden, ondanks de audit-sporen die
	<application>ssh</application> achterlaat.</para>

      <para>Als de machine met beperkte toegang eenmaal minstens
	leestoegang heeft tot een clientsysteem dat het moet gaan
	monitoren, dan moeten scripts gemaakt worden om dat monitoren
	ook echt uit te voeren.  Uitgaande van een NFS mount, kunnen
	de scripts gebruik maken van eenvoudige systeem hulpprogramma's
	als &man.find.1; en &man.md5.1;.  We adviseren minstens
	&eacute;&eacute;n keer per dag een md5 te maken van alle
	bestanden op de clientmachine en van instellingenbestanden als
	in <filename>/etc</filename> en
	<filename>/usr/local/etc</filename> zelfs vaker.  Als er
	verschillen worden aangetroffen ten opzichte van de basis md5
	informatie op het systeem met beperkte toegang, dan hoort het
	script te gillen om een beheerder die het moet gaan uitzoeken.
	Een goed beveiligingsscript controleert ook op onverwachte suid
	bestanden en op nieuwe en verwijderde bestanden op
	systeempartities als <filename>/</filename> en
	<filename>/usr</filename>.</para>

      <para>Als <application>ssh</application> in plaats van NFS wordt
	gebruikt, dan is het schrijven van het script lastiger.  Dan
	moeten de scripts met <command>scp</command> naar de client
	verplaatst worden om ze uit te voeren, waardoor ze zichtbaar
	worden.  Voor de veiligheid dienen ook de binaire bestanden die
	het script gebruikt, zoals &man.find.1;, gekopieerd te
	worden.  De <application>ssh</application> client op de client
	zou al gecompromitteerd kunnen zijn.  Het is misschien
	noodzakelijk ssh te gebruiken over onveilige verbindingen, maar
	dat maakt alles een stuk lastiger.</para>

      <para>Een goed beveiligingsscript voert ook controles uit op de
	instellingenbestanden van gebruikers en medewerkers:
	<filename>.rhosts</filename>, <filename>.shosts</filename>,
	<filename>.ssh/authorized_keys</filename>, enzovoort&hellip;
	Dat zijn bestanden die buiten het bereik van de
	<literal>MD5</literal> controle vallen.</para>

      <para>Als gebruikers veel schijfruimte hebben, dan kan het te
	lang duren om alle bestanden op deze partitie te controleren.
	In dat geval is het verstandig de mount vlaggen zo in te
	stellen dat suid binaire bestanden en apparaten op die
	partities niet zijn toegestaan.  Zie daarvoor de
	<literal>nodev</literal> en <literal>nosuid</literal> opties
	(zie &man.mount.8;).  Die partities moeten wel toch nog
	minstens eens per week doorzocht worden, omdat het doel van
	deze beveiligingslaag het ontdekken van een inbraak is, of die
	nu succesvol is of niet.</para>

      <para>Procesverantwoording (zie &man.accton.8;) kost relatief
	gezien weinig en kan bijdragen aan een evaluatie mechanisme
	voor na inbraken.  Het is erg handig om uit te zoeken hoe
	iemand precies heeft ingebroken op het systeem, mits het
	bestand nog onbeschadigd is na de inbraak.</para>

      <para>Tenslotte horen beveiligingsscripts de logboekbestanden te
	verwerken en de logboekbestanden zelf horen zo veilig mogelijk
	tot stand te komen.  <quote>remote syslog</quote> kan erg
	zinvol zijn.  Een aanvaller probeert zijn sporen uit te wissen
	en logboekbestanden zijn van groot belang voor een
	systeembeheerder als het gaat om uitzoeken wanneer en hoe er is
	ingebroken.  Een manier om logboekbestanden veilig te stellen
	is door het systeemconsole via een seri&euml;le poort aan te
	sluiten op een veilige machine en zo continu informatie te
	verzamelen.</para>
    </sect2>

    <sect2>
      <title>Paranoia</title>

      <para>Een beetje paranoia is niet verkeerd.  Eigenlijk kan de
	systeembeheerder zoveel beveiligingsopties inschakelen als hij
	wil, als deze maar geen impact hebben op het gebruiksgemak en
	de beveiligingsopties die <emphasis>wel</emphasis> impact
	hebben op het gebruiksgemak kunnen ingeschakeld worden als daar
	zorgvuldig mee wordt omgegaan.  Nog belangrijker is misschien
	dat er een juiste combinatie wordt gevonden.  Als de
	aanbevelingen uit dit document woord voor woord worden
	opgevolgd, dan worden daarmee de methodes aan een toekomstige
	aanvaller verraden, die ook toegang heeft tot dit
	document.</para>
    </sect2>

    <sect2>
      <title>Ontzeggen van Dienst aanvallen</title>

      <indexterm><primary>Ontzegging van Dienst (DoS)</primary></indexterm>

      <para>In deze paragraaf worden Ontzeggen van Dienst aanvallen
	(<quote>Denial of Service</quote> of DoS) behandeld.  Een DoS
	aanval wordt meestal uitgevoerd als pakketaanval.  Hoewel er
	weinig gedaan kan worden tegen de huidige aanvallen met
	gefingeerde pakketten die een netwerk kunnen verzadigen, kan
	de schade geminimaliseerd worden door ervoor te zorgen dat
	servers er niet door plat gaan.</para>

      <orderedlist>
	<listitem>
	  <para>Limiteren van server forks.</para>
	</listitem>

      <listitem>
	<para>Limiteren van springplank (<quote>springboard</quote>)
	  aanvallen (ICMP response aanvallen, ping broadcast,
	  etc.).</para>
      </listitem>

      <listitem>
	  <para>Kernel Route Cache.</para>
	</listitem>
      </orderedlist>

      <para>Een veelvoorkomende DoS aanval tegen een server die forkt
	is er een die probeert processen, file descriptors en geheugen
	te gebruiken tot de machine het opgeeft.
	<application>inetd</application> (zie &man.inetd.8;) kent een
	aantal instellingen om dit type aanval af te zwakken.  Hoewel
	het mogelijk is ervoor te zorgen dat een machine niet plat
	gaat, is het in het algemeen niet mogelijk te voorkomen dat de
	dienstverlening door de aanval wordt verstoord.  Meer is te
	lezen in de handleiding van <application>inetd</application>
	en het advies is in het bijzonder aandacht aan de
	<option>-c</option>, <option>-C</option> en <option>-R</option>
	opties te besteden.  Aanvallen met gefingeerde
	<acronym>IP</acronym> adressen omzeilen de <option>-C</option>
	optie naar <application>inetd</application>, dus in het
	algemeen moet een combinatie van opties gebruikt worden.
	Sommige op zichzelf staande servers hebben parameters waarmee
	het aantal forks gelimiteerd kan worden.</para>

      <para><application>Sendmail</application> heeft de optie
	<option>-OMaxDaemonChildren</option> die veel beter blijkt te
	werken dan het gebruik van de opties van sendmail waarmee de
	werklast gelimitteerd kan worden.  De parameter
	<literal>MaxDaemonChildren</literal> moet zodanig ingesteld
	worden dat als <application>sendmail</application> start, hij
	hoog genoeg is om de te verwachten belasting aan te kunnen,
	maar niet zo hoog is dat de computer het aantal instanties van
	<application>sendmail</application>s niet aankan zonder plat te
	gaan.  Het is ook verstandig om sendmail in de wachtrij modus
	(<option>-ODeliveryMode=queued</option>) te draaien en de
	daemon (<command>sendmail -bd</command>) los te koppelen van de
	verwerking van de wachtrij (<command>sendmail -q15m</command>).
	Als de verwerking van wachtrij real-time moet, kunnen de
	tussenpozen voor verwerking verkort worden door deze
	bijvoorbeeld op <option>-q1m</option> in te stellen, maar dan
	is een redelijke instelling van
	<literal>MaxDaemonChildren</literal> van belang om
	<emphasis>die</emphasis> sendmail te beschermen tegen
	trapsgewijze fouten (<quote>cascade failures</quote>).</para>

      <para><application>Syslogd</application> kan direct aangevallen
	worden en het is sterk aan te raden de <option>-s</option>
	optie te gebruiken waar dat ook maar mogelijk is en anders de
	<option>-a</option> optie.</para>

      <para>Er dient voorzichtig omgesprongen te worden met diensten
	die terugverbinden zoals
	<application>TCP Wrapper</application>'s reverse-identd die
	direct aangevallen kan worden.  In het algemeen is het hierom
	onverstandig gebruik te maken van de reverse-ident optie van
	<application>TCP Wrapper</application>.</para>

      <para>Het is een goed idee om interne diensten af te schermen
	voor toegang van buitenaf door ze te firewallen op de routers
	aan de rand van een netwerk (<quote>border routers</quote>).
	Dit heeft als achtergrond dat verzadigingsaanvallen voorkomen
	van buiten het LAN voorkomen kunnen worden.  Daarmee wordt geen
	aanval op <username>root</username> via het netwerk en die
	diensten daaraan voorkomen.  Er dient altijd een exclusieve
	firewall te zijn, d.w.z. <quote>firewall alles
	  <emphasis>behalve</emphasis> poorten A, B, C, D en M-Z</quote>.
	Zo worden alle lage poorten gefirewalled behalve die voor
	specifieke diensten als <application>named</application> (als
	er een primary is voor een zone),
	<application>ntalkd</application>,
	<application>sendmail</application> en andere diensten die
	vanaf internet toegankelijk moeten zijn.  Als de firewall
	andersom wordt ingesteld, als een inclusieve of tolerante
	firewall, dan is de kans groot dat er wordt vergeten een aantal
	diensten af te <quote>sluiten</quote> of dat er een nieuwe
	interne dienst wordt toegevoegd en de firewall niet wordt
	bijgewerkt.  Er kan nog steeds voor gekozen worden de hoge
	poorten open te zetten, zodat een tolerante situatie ontstaat,
	zonder de lage poorten open te stellen.  &os; biedt ook de
	mogelijkheid een reeks poortnummers die gebruikt worden voor
	dynamische verbindingen in te stellen via de verscheidene
	<varname>net.inet.ip.portrange</varname>
	<command>sysctl</command>s (<command>sysctl -a | fgrep
	  portrange</command>), waardoor ook de complexiteit van de
	firewall instellingen kan vereenvoudigen.  Zo kan bijvoorbeeld
	een normaal begin tot eindbereik ingesteld worden van 4000 tot
	5000 en een hoog poortbereik van 49152 tot 65535.  Daarna kan
	alles onder 4000 op de firewall geblokkeerd worden (met
	uitzondering van bepaalde poorten die vanaf internet bereikbaar
	moeten zijn natuurlijk).</para>

      <para>Een andere veelvoorkomende DoS aanval is de springplank
	aanval: een server zo aanvallen dat de respons van die server
	de server zelf, het lokale netwerk of een andere machine
	overbelast.  De meest voorkomende aanval van dit type is de
	<emphasis>ICMP ping broadcast aanval</emphasis>.  De aanvaller
	fingeert ping pakketten die naar het broadcast adres van het
	LAN worden gezonden met als bron het <acronym>IP</acronym> adres
	van de machine die hij eigenlijk aan wil vallen.  Als de routers
	aan de rand van het netwerk niet zijn ingesteld om een ping aan
	een broadcast adres te blokkeren, dan kan het LAN genoeg
	antwoorden produceren om de verbinding van het slachtoffer (het
	gefingeerde bronadres) te verzadigen, zeker als de aanvaller
	hetzelfde doet met tientallen andere netwerken.
	Broadcastaanvallen met een volume van meer dan 120 megabit zijn
	al voorgekomen.  Een tweede springplank aanval is er een tegen
	het ICMP foutmeldingssysteem.  Door een pakket te maken waarop
	een ICMP foutmelding komt, kan een aanvaller de inkomende
	verbinding van een server verzadigen en de uitgaande verbinding
	wordt verzadigd door de foutmeldingen.  Dit type aanval kan een
	server ook laten crashen, zeker als de server de ICMP
	antwoorden niet zo snel kwijt kan als ze ontstaan.
	&os;&nbsp;4.X kernels kennen een compileeroptie
	<option>ICMP_BANDLIM</option> waarmee de effectiviteit van dit
	type aanvallen afneemt.  Latere kernels gebruiken de
	<application>sysctl</application> variabele
	<literal>net.inet.icmp.icmplim</literal>.  De laatste
	belangrijke klasse springplankaanvallen hangt samen met een
	aantal interne diensten van <application>inetd</application>
	zoals de UDP echo dienst.  Een aanvaller fingeert eenvoudigweg
	een UDP pakket met als bronadres de echopoort van Server A en
	als bestemming de echopoort van Server B, waar Server A en B
	allebei op een LAN staan.  Die twee servers gaan dat pakket dan
	heen en weer kaatsen.  Een aanvaller kan beide servers
	overbelasten door een aantal van deze pakketten te injecteren.
	Soortgelijke problemen kunnen ontstaan met de
	<application>chargen</application> poort.  Een competente
	systeembeheerder zal al deze interne
	<application>inetd</application> test-diensten
	uitschakelen.</para>

      <para>Gefingeerde pakketten kunnen ook gebruikt worden om de
	kernel route cache te overbelasten.  Raadpleeg daarvoor de
	<varname>net.inet.ip.rtexpire</varname>,
	<varname>rtminexpire</varname> en <varname>rtmaxcache</varname>
	<command>sysctl</command> parameters.  Een aanval met
	gefingeerde pakketten met een willekeurig bron IP zorgt ervoor
	dat de kernel een tijdelijke cached route maakt in de
	routetabel, die uitgelezen kan worden met <command>netstat -rna
	  | fgrep W3</command>.  Deze routes hebben een levensduur van
	ongeveer 1600 seconden.  Als de kernel merkt dat de cached
	routetabel te groot is geworden, dan wordt
	<varname>rtexpire</varname> dynamisch verkleind, maar deze
	waarde wordt nooit lager dan <varname>rtminexpire</varname>.
	Er zijn twee problemen:</para>

      <orderedlist>
	<listitem>
	  <para>De kernel reageert niet snel genoeg als een laag
	    belaste server wordt aangevallen.</para>
	</listitem>

	<listitem>
	  <para><varname>rtminexpire</varname> is niet laag genoeg om
	    de kernel de aanval te laten overleven.</para>
	</listitem>
      </orderedlist>

      <para>Als servers verbonden zijn met het internet via een E3
	of sneller, dan is het verstandig om handmatig
	<varname>rtexpire</varname> en <varname>rtminexpire</varname>
	aan te passen via &man.sysctl.8;.  Als de een van de parameters
	op nul wordt gezet, dan crasht de machine.  Het instellen van
	beide waarden op 2 seconden is voldoende om de routetabel
	tegen een aanval te beschermen.</para>
    </sect2>

    <sect2>
      <title>Aandachtspunten voor toegang met
	<application>Kerberos</application> en
	<application>SSH</application></title>

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

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

      <para>Er zijn een aantal aandachtspunten die in acht genomen
	moeten worden als Kerberos of ssh gebruikt worden.  Kerberos V
	is een prima authenticatieprotocol, maar er zitten bugs in de
	kerberos versies van <application>telnet</application> en
	<application>rlogin</application> waardoor ze niet geschikt
	zijn voor binair verkeer.  Kerberos codeert standaard sessie
	niet, tenzij de optie <option>-x</option> wordt gebruikt.
	<application>ssh</application> codeert standaard wel
	alles.</para>

      <para>ssh werkt prima, maar het stuurt coderingssleutels
	standaard door.  Dit betekent dat als gegeven een veilig
	werkstation met sleutels die toegang geven tot de rest van het
	systeem en ssh wordt gebruikt om verbinding te maken met een
	onveilige machine, die sleutels gebruikt kunnen worden.  De
	sleutels zelf zijn niet bekend, maar ssh stelt een
	doorstuurpoort in zolang als een gebruikers aangemeld blijft.
	Als de aanvaller <username>root</username>toegang heeft op de
	onveilige machine, dan kan hij die poort gebruiken om toegang
	te krijgen tot alle machines waar de sleutels van de gebruiker
	toegang toe geven.</para>

      <para>Het advies is ssh in combinatie met Kerberos te gebruiken
	voor het aanmelden door medewerkers wanneer dat ook maar
	mogelijk is.  <application>ssh</application> kan gecompileerd
	worden met Kerberos ondersteuning.  Dit vermindert de kans op
	blootstelling van ssh sleutels en beschermt tegelijkertijd
	de wachtwoorden met Kerberos.  ssh sleutels zouden alleen
	gebruikt moeten worden voor geautomatiseerde taken vanaf
	veilige machines (iets waar Kerberos ongeschikt voor is).  Het
	advies is om het doorsturen van sleutels uit te schakelen in de
	ssh instellingen of om de <literal>from=IP/DOMAIN</literal>
	optie te gebruiken die ssh in staat stelt het bestand
	<filename>authorized_keys</filename> te gebruiken om de
	sleutel alleen bruikbaar te maken voor entiteiten die zich
	aanmelden vanaf vooraf aangewezen machines.</para>
    </sect2>
  </sect1>

  <sect1 id="crypt">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Bill</firstname>
	  <surname>Swingle</surname>
	  <contrib>Delen geschreven en herschreven door </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Siebrand</firstname>
	  <surname>Mazeland</surname>
	  <contrib>Vertaald door </contrib>
	</author>
      </authorgroup>
      <!-- 21 Mar 2000 -->
    </sect1info>

    <title>DES, MD5 en crypt</title>

    <indexterm>
      <primary>beveiliging</primary>

      <secondary>crypt</secondary>
    </indexterm>

    <indexterm><primary>crypt</primary></indexterm>

    <indexterm><primary>DES</primary></indexterm>

    <indexterm><primary>MD5</primary></indexterm>

    <para>Iedere gebruiker op een &unix; systeem heeft een wachtwoord
      bij zijn account.  Het lijkt voor de hand liggend dat deze
      wachtwoorden alleen bekend horen te zijn bij de gebruiker en het
      eigenlijke besturingssysteem.  Om deze wachtwoorden geheim te
      houden, zijn ze gecodeerd in een <quote>eenweg hash</quote>
      (<quote>one-way hash</quote>), wat betekent dat ze eenvoudig
      gecodeerd kunnen worden maar niet gedecodeerd.  Met andere
      woorden, wat net gesteld werd is helemaal niet waar: het
      besturingssysteem kent het <emphasis>echte</emphasis> wachtwoord
      niet.  De enige manier om een wachtwoord in <quote>platte
	tekst</quote> te verkrijgen, is door er met brute kracht naar
      te zoeken in alle mogelijke wachtwoorden.</para>

    <para>Helaas was DES, de Data Encryption Standard, de enige
      manier om wachtwoorden veilig te coderen toen &unix; ontstond.
      Dit was geen probleem voor gebruikers in de VS, maar omdat
      de broncode van DES niet ge&euml;xporteerd mocht worden moest
      &os; een manier vinden om zowel te gehoorzamen aan de wetten van
      de VS als aansluiting te houden bij alle andere &unix; varianten
      die nog steeds DES gebruikten.</para>

    <para>De oplossing werd gevonden in het splitsen van de
      coderingsbibliotheken zodat gebruikers in de VS de DES
      bibliotheken konden installeren en gebruiken en internationale
      gebruikers een coderingsmethode konden gebruiken die
      ge&euml;xporteerd mocht worden.  Zo is het gekomen dat &os; MD5
      is gaan gebruiken als coderingsmethode.  Van MD5 wordt aangenomen
      dat het veiliger is dan DES, dus de mogelijkheid om DES te
      installeren is vooral beschikbaar om aansluiting te kunnen
      houden.</para>

    <sect2>
      <title>Het crypt mechanisme herkennen</title>

      <para>Voor &os;&nbsp;4.4 was <filename>libcrypt.a</filename> een
	symbolic link die wees naar de bibliotheek die gebruikt werd voor
	codering.  In &os;&nbsp;4.4 veranderde <filename>libcrypt.a</filename>
	zodat er een instelbare wachtwoordhash bibliotheek kwam.  Op dit
	moment ondersteunt de bibliotheek DES, MD5 en Blowfish
	hashfuncties.  Standaard gebruikt &os; MD5 om wachtwoorden te
	coderen.</para>

     <para>Het is vrij makkelijk om uit te vinden welke
       coderingsmethode &os; op een bepaald moment gebruikt.  De
       gecodeerde wachtwoorden in
       <filename>/etc/master.passwd</filename> bekijken is een manier.
       Wachtwoorden die gecodeerd zijn met MD5 zijn langer dan wanneer
       ze gecodeerd zijn met DES hash.  Daarnaast beginnen ze met de
       karakters <literal>&dollar;1&dollar;</literal>.  Wachtwoorden
       die beginnen met <literal>&dollar;2a&dollar;</literal> zijn
       gecodeerd met de Blowfish hashfunctie.  DES password strings
       hebben geen bijzondere kenmerken, maar ze zijn korter dan MD5
       wachtwoorden en gecodeerd in een 64-karakter alfabet waar geen
       <literal>&dollar;</literal> karakter in zit.  Een relatief korte
       string die niet begint met een dollar teken is dus
       waarschijnlijk een DES wachtwoord.</para>

     <para>Het wachtwoord formaat voor nieuwe wachtwoorden wordt
       ingesteld met de <literal>passwd_format</literal>
       aanmeldinstelling in <filename>/etc/login.conf</filename> waar
       <literal>des</literal>, <literal>md5</literal> of
       <literal>blf</literal> mag staan.  Zie de &man.login.conf.5;
       handboekpagina voor meer informatie over
       aanmeldinstellingen.</para>
    </sect2>
  </sect1>

  <sect1 id="one-time-passwords">
    <title>Eenmalige wachtwoorden</title>

    <indexterm><primary>eenmalige wachtwoorden</primary></indexterm>

    <indexterm>
      <primary>beveiliging</primary>

      <secondary>eenmalige wachtwoorden</secondary>
    </indexterm>

    <para>S/Key is een eenmalige wachtwoord methode die gebaseerd is op
      de eenweg hashfunctie.  &os; gebruikt een MD4 hash om aansluiting
      te houden, maar andere systemen gebruiken ook wel MD5 en DES-MAC.
      S/Key is al een onderdeel van het &os; basissysteem vanaf versie
      1.1.5 en wordt ook in een groeiend aantal andere
      besturingssystemen gebruikt.  S/Key is een geregistreerd
      handelsmerk van Bell Communications Research, Inc.</para>

    <para>Vanaf versie 5.0 van &os; is S/Key vervangen door OPIE
      (Eenmalige Wachtwoorden in Alles - <quote>One-time Passwords In
	Everything</quote>).  OPIE gebruikt standaard een MD5 hash.</para>

    <para>Hier worden drie verschillende soorten wachtwoorden
      besproken.  De eerste is het normale &unix; of Kerberos
      wachtwoord.  Dit heet het <quote>&unix; wachtwoord</quote>.  Het
      tweede type is een eenmalig wachtwoord dat wordt gemaakt met het
      S/Key programma <command>key</command> of het OPIE
      programma &man.opiekey.1; en dat wordt geaccepteerd door
      <command>keyinit</command> of &man.opiepasswd.1; en de
      aanmeldprocedure.  Dit heet het <quote>eenmalige
	wachtwoord</quote>.  Het laatste type wachtwoord is het
      wachtwoord dat wordt opgegeven aan de <command>key</command>/
      <command>opiekey</command> programma's (en soms aan de
      <command>keyinit</command> / <command>opiepasswd</command>
      programma's) die gebruikt worden om eenmalige wachtwoorden te
      maken.  Dit type heet <quote>geheim wachtwoord</quote> of gewoon
      een <quote>wachtwoord</quote> zonder toevoeging.</para>

    <para>Het geheime wachtwoord heeft niets te maken met het &unix;
      wachtwoord; ze kunnen hetzelfde zijn, dat wordt afgeraden.  S/Key
      en OPIE geheime wachtwoorden kennen niet de beperking van 8
      karakters als de oude &unix; wachtwoorden.

      <footnote>
	<para>Bij &os; mag het wachtwoord voor aanmelden tot 128
	  karakters lang zijn.</para>
      </footnote>

      Het mag onbeperkt lang zijn.  Wachtwoorden van een zes of zeven
      woorden lange zin zijn niet ongewoon.  Voor het overgrote deel
      werkt het S/Key of OPIE systeem volledig onafhankelijk van het
      &unix; wachtwoordsysteem.</para>

    <para>Buiten het wachtwoord zijn er nog twee stukjes data die van
      belang zijn voor S/Key en OPIE.  Het eerste wordt
      <quote>zaad</quote> (<quote>seed</quote>) of
      <quote>sleutel</quote> (<quote>key</quote>) genoemd en bestaat
      uit twee letters en vijf cijfers.  Het tweede stukje data heet de
      <quote>iteratieteller</quote> (<quote>iteration count</quote>),
      een nummer tussen 1 en 100.  S/Key maakt een eenmalig wachtwoord
      door het zaad en het geheime wachtwoord aaneen te schakelen en
      daarop het door de iteratieteller aangegeven keren MD4/MD5 hash
      toe te passen.  Daarna wordt het resultaat omgezet in zes korte
      Engelse woorden.  Die zes woorden zijn een eenmalige wachtwoord.
      Het authenticatiesysteem (hoofdzakelijk PAM) houdt bij welk
      eenmalig wachtwoord het laatst is gebruikt en de gebruiker wordt
      geauthenticeerd als de hash van het door de gebruiker ingegeven
      wachtwoord gelijk is aan het vorige wachtwoord.  Omdat er een
      eenweg hash wordt gebruikt, is het onmogelijk om toekomstige
      eenmalige wachtwoorden te maken als iemand toch een eenmalig
      wachtwoord heeft afgevangen.  De iteratieteller wordt verlaagd na
      iedere succesvolle aanmelding om de gebruiker en het
      aanmeldprogramma synchroon te houden.  Als de iteratieteller op 1
      staat, moeten S/Key en OPIE opnieuw ingesteld worden.</para>

    <para>Er zijn drie programma's bij ieder systeem betrokken die
      hieronder worden besproken.  De <command>key</command> en
      <command>opiekey</command> programma's hebben een iteratieteller,
      zaad en een geheim wachtwoord nodig en maken dan een eenmalig
      wachtwoord of een lijst van opeenvolgende eenmalige wachtwoorden.
      De programma's <command>keyinit</command> en
      <command>opiepasswd</command> worden gebruikt om respectievelijk
      S/Key en OPIE te initialiseren en om wachtwoorden,
      iteratietellers en zaad te wijzigen.  Ze accepteren zowel
      wachtwoordzinnen als een iteratieteller, zaad en een eenmalig
      wachtwoord.  De programma's <command>keyinfo</command> en
      <command>opieinfo</command> bekijken de relevante bestanden
      waarin de eigenschappen staan (<filename>/etc/skeykeys</filename>
      of <filename>/etc/opiekeys</filename>) en tonen de huidige
      iteratieteller en zaad van de gebruiker die het commando
      uitvoert.</para>

    <para>Nu worden vier verschillende acties besproken.  Bij de eerste
      worden <command>keyinit</command> of
      <command>opiepasswd</command> gebruikt in een beveiligde
      verbinding om voor het eerst eenmalige wachtwoorden in te stellen
      of om een wachtwoord of zaad aan te passen.  Bij de tweede worden
      <command>keyinit</command> of <command>opiepasswd</command>
      gebruikt in een niet-beveiligde verbinding samen met
      <command>key</command> of <command>opiekey</command> over een
      beveiligde verbinding om hetzelfde te bereiken.  In een derde
      scenario wordt <command>key</command>/<command>opiekey</command>
      gebruikt om te melden over een onveilige verbinding.  Het vierde
      scenario behandelt het gebruik van <command>key</command> of
      <command>opiekey</command> om een aantal sleutels aan te maken
      die opgeschreven of afgedrukt kunnen worden, zodat ze meegenomen
      kunnen worden naar een plaats van waar geen enkele veilige
      verbinding opgezet kan worden.</para>

    <sect2>
      <title>Veilige verbinding initialiseren</title>

      <para>Om S/Key voor de eerste keer te initialiseren, een
	wachtwoord te wijzigen of zaad te veranderen over een
	beveiligde verbinding (bijvoorbeeld op het console van een
	machine of via <application>ssh</application>), moet het
	commando <command>keyinit</command> gebruikt worden zonder
	parameters terwijl een gebruiker als zichzelf is
	aangemeld:</para>

      <screen>&prompt.user; <userinput>keyinit</userinput>
Adding unfurl:
Reminder - Only use this method if you are directly connected.
If you are using telnet or rlogin exit with no password and use keyinit -s.
Enter secret password:
Again secret password:

ID unfurl s/key is 99 to17757
DEFY CLUB PRO NASH LACE SOFT</screen>

      <para>Bij OPIE wordt <command>opiepasswd</command>
	gebruikt:</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>Als <prompt>Enter new secret pass phrase:</prompt> of
	<prompt>Enter secret password:</prompt> op het scherm verschijnt,
	dient een wachtwoord of wachtwoordzin ingevoerd te worden.  Dit
	is dus niet het aanmeldwachtwoord is, maar dat dit wordt gebruikt
	om eenmalige wachtwoorden te maken.  De <quote>ID</quote> regel
	geeft de parameters van het verzoek weer: de aanmeldnaam, de
	iteratieteller en zaad.  Bij het aanmelden kent het systeem deze
	parameters en worden deze weergegeven zodat ze niet onthouden
	hoeven te worden.  Op de laatste regel staat het eenmalige
	wachtwoord dat overeenkomt met die parameters en het geheime
	wachtwoord.  Als de gebruiker direct opnieuw zou aanmelden, zou
	hij dat eenmalige wachtwoord moeten gebruiken.</para>
    </sect2>

    <sect2>
      <title>Onveilige verbinding initialiseren</title>

      <para>Om te initialiseren of een wachtwoord te wijzigen over een
	onveilige verbinding, moet er al ergens een veilige verbinding
	bestaand de gebruiker <command>key</command> of
	<command>opiekey</command> kan uitvoeren.  Dit kan een desktop
	programma zijn op een &macintosh; of een shell prompt op een
	machine die vertrouwd wordt.  De gebruiker moet ook een
	iteratieteller verzinnen (100 is wellicht een prima getal) en
	moet een eigen zaad bedenken of er een laten fabriceren.  Over
	de onveilige verbinding (naar de machine die de gebruiker wil
	initialiseren) wordt het commando <command>keyinit -s</command>
	gebruikt:</para>

      <screen>&prompt.user; <userinput>keyinit -s</userinput>
Updating unfurl:
Old key: to17758
Reminder you need the 6 English words from the key command.
Enter sequence count from 1 to 9999: <userinput>100</userinput>
Enter new key [default to17759]:
s/key 100 to 17759
s/key access password:
s/key access password:<userinput>CURE MIKE BANE HIM RACY GORE</userinput></screen>

      <para>Bij OPIE is dat <command>opiepasswd</command>:</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>Om het standaard zaad te accepteren (dat het programma
	<command>keyinit</command> nogal verwarrend een
	<literal>key</literal>) noemt, is de invoer
	<keycap>Return</keycap>.  Voor een toegangswachtwoord wordt
	ingevoerd, dient eerst gewisseld te worden naar de veilige
	verbinding of het S/Key desktop programma en dienen dezelfde
	parameters ingegeven te worden:</para>

      <screen>&prompt.user; <userinput>key 100 to17759</userinput>
Reminder - Do not use this program while logged in via telnet or rlogin
Enter secret password: <userinput>&lt;secret password&gt;</userinput>
CURE MIKE BANE HIM RACY GORE</screen>

      <para>Of bij OPIE:</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>In de onveilige verbinding wordt nu het eenmalige
	wachtwoord in het relevante programma
	gekopieerd.</para>
    </sect2>

    <sect2>
      <title>Een enkel eenmalig wachtwoord maken</title>

      <para>Als S/Key of OPIE eenmaal is ingesteld staat er bij het
	aanmelden iets als het volgende:</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>&lt;username&gt;</userinput>
s/key 97 fw13894
Password:</screen>

      <para>Of bij OPIE:</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>&lt;username&gt;</userinput>
otp-md5 498 gr4269 ext
Password: </screen>

      <para>NB: de S/Key en OPIE meldingen hebben een erg zinvolle
	optie (die hier niet te zien is): als er op
	<keycap>Return</keycap> wordt gedrukt bij de wachtwoordregel,
	wordt de echo aangezet, zodat de invoer zichtbaar is.  Dit is
	erg handig als er met de hand een wachtwoord wordt ingegeven,
	zoals wanneer het wordt ingevoerd vanaf een afdruk.</para>

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

      <indexterm><primary>Windows</primary></indexterm>

      <indexterm><primary>MacOS</primary></indexterm>

      <para>Nu moet het eenmalige wachtwoord gemaakt worden om het
	aanmeldprompt mee te antwoorden.  Dit moet gedaan worden op een
	vertrouwd systeem waarop <command>key</command> of
	<command>opiekey</command> beschikbaar is.  Er zijn ook
	versies voor &ms-dos;, &windows; en &macos;.  Voor beide
	commando's moet zowel de iteratieteller als het zaad ingeven
	worden op de commandoregel.  Deze kan zo overgenomen worden
	vanaf het aanmeldprompt op de machine waarop de gebruiker wil
	aanmelden.</para>

      <para>Op het vertrouwde systeem:</para>

      <screen>&prompt.user; <userinput>key 97 fw13894</userinput>
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password:
WELD LIP ACTS ENDS ME HAAG</screen>

      <para>Bij OPIE:</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>Nu het eenmalige wachtwoord er is, kan het aanmelden
	doorgang vinden:</para>

      <screen>login: <userinput>&lt;username&gt;</userinput>
s/key 97 fw13894
Password: <userinput>&lt;return to enable echo&gt;</userinput>
s/key 97 fw13894
Password [echo on]: WELD LIP ACTS ENDS ME HAAG
Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... </screen>
    </sect2>

    <sect2>
      <title>Meerdere eenmalige wachtwoorden maken</title>

      <para>Soms moet is een gebruiker ergens waarvandaan er geen
	toegang is tot een vertrouwde machine of een beveiligde
	verbinding.  In dat geval is het mogelijk om met de
	<command>key</command> en <command>opiekey</command> commando's
	een aantal eenmalige wachtwoorden te maken om uit te printen en
	deze mee te nemen:</para>

      <screen>&prompt.user; <userinput>key -n 5 30 zz99999</userinput>
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: <userinput>&lt;secret password&gt;</userinput>
26: SODA RUDE LEA LIND BUDD SILT
27: JILT SPY DUTY GLOW COWL ROT
28: THEM OW COLA RUNT BONG SCOT
29: COT MASH BARR BRIM NAN FLAG
30: CAN KNEE CAST NAME FOLK BILK</screen>

      <para>Of bij OPIE:</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>Met <option>-n 5</option> worden vijf opeenvolgende
	sleutels aangevraagd, <option>30</option> geeft aan wat het
	laatste iteratiegetal moet zijn.  Deze wachtwoorden worden
	weergegeven in <emphasis>omgekeerde</emphasis> volgorde voor
	gebruik.  Als de gebruiker echt parano&iuml;de bent kan hij ze
	opschrijven of hij kan er ook voor kiezen ze af te drukken met
	<command>lpr</command>.  Op iedere regel staat dus de
	iteratieteller en het eenmalige wachtwoord, maar misschien is
	het toch handig om ze na gebruik af te strepen.</para>
    </sect2>

    <sect2>
      <title>Gebruik van &unix; wachtwoorden beperken</title>

      <para>S/Key kan beperkingen plaatsen op het gebruik van &unix;
	wachtwoorden gebaseerd op hostnaam, gebruikersnaam,
	terminalpoort of <acronym>IP</acronym> adres van een
	aanmeldsessie.  Deze beperkingen staan in het
	instellingenbestand <filename>/etc/skey.access</filename>.
	De handboekpagina voor &man.skey.access.5; bevat meer
	informatie over de inhoud van het bestand en bevat ook details
	over een aantal aandachtspunten voor beveiliging voordat
	besloten wordt dit bestand te gebruiken in de
	beveiliging.</para>

      <para>Als het bestand <filename>/etc/skey.access</filename> niet
	bestaat (dat mag in &os;&nbsp;4.X systemen), dan mogen alle
	gebruikers hun &unix; wachtwoord gebruiken.  Maar als het
	bestand wel bestaat, dan moeten alle gebruikers S/Key
	gebruiken, tenzij iets anders expliciet wordt toegestaan door
	instellingen in het bestand <filename>skey.access</filename>.
	In alle gevallen worden &unix; wachtwoorden op het console wel
	toegestaan.</para>

      <para>Nu volgt een voorbeeld met instellingen in het bestand
	<filename>skey.access</filename> waarin de drie meest gebruikte
	instellingen terugkomen:</para>

      <programlisting>permit internet 192.168.0.0 255.255.0.0
permit user fnord
permit port ttyd0</programlisting>

      <para>In de eerste regel (<literal>permit internet</literal>)
	staat dat gebruikers met een bron <acronym>IP</acronym> adres
	(wat gefingeerd kan worden) dat past binnen de aangegeven
	waarde en masker altijd &unix; wachtwoorden mogen gebruiken.
	Dit mag niet gezien worden als beveiligingsmechanisme, maar
	eerder als een mogelijkheid om gebruikers aan wie het wordt
	toegestaan eraan te herinneren dat ze op een onveilig netwerk
	zitten en gebruik moeten maken van S/Key bij het aanmelden.</para>

      <para>De tweede regel (<literal>permit user</literal>) staat de
	gebruiker <username>fnord</username> toe om altijd &unix;
	wachtwoorden te gebruiken.  In het algemeen dient dit alleen
	gebruikt te worden voor gebruikers die niet in staat zijn het
	programma <command>key</command> te gebruiken, zoals gebruikers
	met domme terminals of gebruikers die totaal niet op te voeden
	zijn.</para>

      <para>De derde regel (<literal>permit port</literal>) staat
	gebruikers die aanmelden vanaf een aangegeven
	terminalverbinding toe om &unix; wachtwoorden te gebruiken.
	Dit kan gebruikt worden voor inbellers.</para>

      <para>Met OPIE kan ook paal en perk gesteld worden aan het
	gebruik van &unix; wachtwoorden op basis van het
	<acronym>IP</acronym> adres van een aanmeldsessie, net als met
	S/Key.  Dat kan met het bestand
	<filename>/etc/opieaccess</filename> dat standaard aanwezig is
	op &os;&nbsp;5.0 en latere systemen.  Bij &man.opieaccess.5; staat
	meer informatie over dit bestand en welke
	beveiligingsoverwegingen bestaan bij het gebruik.</para>

      <para>Hieronder een voorbeeld voor een
	<filename>opieaccess</filename> bestand:</para>

      <programlisting>permit 192.168.0.0 255.255.0.0</programlisting>

      <para>In deze regel (<literal>permit internet</literal>) staat
	dat gebruikers met een bron <acronym>IP</acronym> adres (wat
	gefingeerd kan worden) dat past binnen de aangegeven waarde en
	masker altijd &unix; wachtwoorden mogen gebruiken.</para>

      <para>Als geen van de regels uit <filename>opieaccess</filename>
	van toepassing is, worden standaard pogingen zonder OPIE
	geweigerd.</para>
    </sect2>
  </sect1>

  <sect1 id="tcpwrappers">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Geschreven door </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Siebrand</firstname>
	  <surname>Mazeland</surname>
	  <contrib>Vertaald door </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <indexterm><primary>TCP Wrapper</primary></indexterm>

    <title>TCP wrappers</title>

    <para>Iedereen die bekend is met &man.inetd.8; heeft waarschijnlijk
      wel eens van <acronym>TCP</acronym> Wrappers gehoord.  Maar
      slechts weinigen lijken volledig te begrijpen hoe ze in een
      netwerkomgeving toegepast kunnen worden.  Het schijnt dat
      iedereen een firewall wil hebben om netwerkverbindingen af te
      handelen.  Ondanks dat een firewall veel kan, zijn er toch dingen
      die hij niet kan, zoals tekst terugsturen naar ontstaansplaats
      van een verbinding.  De <acronym>TCP</acronym> software kan dat
      en nog veel meer.  In dit onderdeel worden de
      <acronym>TCP</acronym> Wrappers mogelijkheden besproken en, waar
      dat van toepassing is, worden ook voorbeelden voor implementatie
      gegeven.</para>

    <para>De <acronym>TCP</acronym> Wrappers software vergroot de
      mogelijkheden van <command>inetd</command> door de mogelijkheid
      al zijn serverdaemons te controleren.  Met deze methode is het
      mogelijk om te loggen, berichten te zenden naar verbindingen, een
      daemon toe te staan alleen interne verbindingen te accepteren,
      etc.  Hoewel een aantal van deze mogelijkheden ook ingesteld
      kunnen worden met een firewall, geeft deze manier niet alleen een
      extra laag beveiliging, maar gaat dit ook verder dan wat een
      firewall kan bieden.</para>

    <para>De toegevoegde waarde van <acronym>TCP</acronym> Wrappers
      is niet dat het een goede firewall vervangt.
      <acronym>TCP</acronym> Wrappers kunnen samen met een firewall en
      andere beveiligingsinstellingen gebruikt worden om een extra laag
      van beveiliging voor het systeem te bieden.</para>

    <para>Omdat dit een uitbreiding is op de instellingen van
      <command>inetd</command>, wordt aangenomen dat de lezer het
      onderdeel <link
	linkend="network-inetd">inetd configuration</link> heeft
      gelezen.</para>

    <note>
      <para>Hoewel programma's die onder &man.inetd.8; draaien niet
	echt <quote>daemons</quote> zijn, heten ze traditioneel wel zo.
	Deze term wordt hier dus ook gebruikt.</para>
    </note>

    <sect2>
      <title>Voor het eerst instellen</title>

      <para>De enige voorwaarde voor het gebruiken van
	<acronym>TCP</acronym> Wrappers in &os; is ervoor te zorgen
	dat de <command>inetd</command> gestart wordt vanuit
	<filename>rc.conf</filename> met de optie <option>-Ww</option>.
	Dit is de standaardinstelling.  Er wordt vanuit gegaan dat
	<filename>/etc/hosts.allow</filename> juist is ingesteld, maar
	als dat niet zo is, dan zal &man.syslogd.8; dat melden.</para>

      <note>
	<para>In tegenstelling tot bij andere implementaties van
	  <acronym>TCP</acronym> Wrappers is het gebruik van
	  <filename>hosts.deny</filename> niet langer mogelijk.  Alle
	  instellingen moeten in <filename>/etc/hosts.allow</filename>
	  staan.</para>
      </note>

      <para>In de meest eenvoudige instelling worden verbindingen naar
	daemons toegestaan of geweigerd afhankelijk van de opties in
	<filename>/etc/hosts.allow</filename>.  De standaardinstelling
	in &os; is verbindingen toe te staan naar iedere daemon die met
	<command>inetd</command> is gestart.  Na de basisinstelling
	wordt aangegeven hoe dit gewijzigd kan worden.</para>

      <para>De basisinstelling heeft meestal de vorm
	<literal>daemon : adres : actie</literal>.
	<literal>daemon</literal> is de daemonnaam die
	<command>inetd</command> heeft gestart.  Het
	<literal>adres</literal> kan een geldige hostnaam, een
	<acronym>IP</acronym> adres of een IPv6 adres tussen
	blokhaken ([ ]) zijn.  Het veld <literal>actie</literal> kan
	allow of deny zijn, afhankelijk van of toegang toegestaan of
	geweigerd moet worden.  De instellingen werken zo dat ze
	worden doorlopen van onder naar boven om te kijken welke regel
	als eerste van toepassing is.  Als een regel van toepassing is
	gevonden, dan stop het zoekproces.</para>

      <para>Er zijn nog andere mogelijkheden, maar die worden elders
	toegelicht.  Een eenvoudige instelling kan al van met deze
	informatie worden gemaakt.  Om bijvoorbeeld
	<acronym>POP</acronym>3 verbindingen toe te staan via de
	<filename role="package">mail/qpopper</filename> daemon,
	zouden de volgende instellingen moeten worden toegevoegd aan
	<filename>hosts.allow</filename>:</para>

      <programlisting># This line is required for POP3 connections:
qpopper : ALL : allow</programlisting>

      <para>Nadat deze regel is toegevoegd moet
	<command>inetd</command> herstart worden.  Dit gaat met het
	&man.kill.1; commando of met de <parameter>restart</parameter>
	parameter met <filename>/etc/rc.d/inetd</filename>.</para>
    </sect2>

    <sect2>
      <title>Gevorderde instellingen</title>

      <para><acronym>TCP</acronym> Wrappers hebben ook gevorderde
	instellingen.  Daarmee komt meer controle over de wijze waarop
	er met verbindingen wordt omgegaan.  Soms is het een goed idee
	om commentaar te sturen naar bepaalde hosts of
	daemonverbindingen.  In andere gevallen moet misschien iets
	in een logboekbestand geschreven worden of een e-mail naar de
	beheerder gestuurd worden.  Dit kan allemaal met instellingen
	die <literal>wildcards</literal>, uitbreidingskarakters
	(expansion characters) en het uitvoeren van externe commando's
	heten.  De volgende twee paragrafen beschrijven deze
	mogelijkheden.</para>

      <sect3>
	<title>Externe commando's</title>

	<para>Stel dat zich de situatie voordoet waar een verbinding
	  geweigerd moet worden, maar er een reden gestuurd moet
	  worden naar het individu dat die verbinding probeerde op te
	  zetten.  Hoe gaat dat?  Dat is mogelijk door gebruik te
	  maken van de optie <option>twist</option>.  Als er een
	  poging tot verbinding wordt gedaan, wordt er met
	  <option>twist</option> een shellcommando of script
	  uitgevoerd.  Er staat al een voorbeeld in
	  <filename>hosts.allow</filename>:</para>

	<programlisting># De andere daemons zijn beschermd.
ALL : ALL \
        : severity auth.info \
        : twist /bin/echo "You are not welcome to use %d from %h."</programlisting>

	<para>Dit voorbeeld geeft aan dat het bericht <quote>You are
	    not allowed to use <literal>daemon</literal> from
	    <literal>hostname</literal>.</quote> wordt teruggestuurd
	  voor iedere daemon die niet al is ingesteld in het
	  toegangsbestand.  Het is erg handig om een antwoord terug
	  te sturen naar degene die een verbinding op heeft willen
	  zetten meteen nadat een tot stand gekomen verbinding is
	  verbroken.  Let wel dat alle berichten die gezonden worden
	  <emphasis>moeten</emphasis> staan tussen <literal>"</literal>
	  karakters.  Hier zijn geen uitzonderingen op.</para>

	<warning>
	  <para> Het is mogelijk een ontzegging van dienst aanval uit
	    te voeren op de server als een aanvaller, of een groep
	    aanvallers, deze daemons kan overstromen met verzoeken om
	    verbindingen te maken.</para>
	</warning>

	<para>Het is ook mogelijk hier de optie <option>spawn</option>
	  te gebruiken.  Net als <option>twist</option> weigert
	  <option>spawn</option> impliciet de verbinding en kan het
	  gebruikt worden om shellcommando's of scripts uit te voeren.
	  Anders dan bij <option>twist</option> stuurt
	  <option>spawn</option> geen bericht aan degene die de
	  verbinding wilde maken.  Zie bijvoorbeeld de volgende
	  instelling:</para>

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

	<para>Hiermee worden alle verbindingen van het domein
	  <hostid role="fqdn">*.example.com</hostid> geweigerd.
	  Tegelijkertijd worden ook hostnaam, <acronym>IP</acronym>
	  adres en de daemon waarmee verbinding werd gemaakt naar
	  <filename>/var/log/connections.log</filename>
	  geschreven.</para>

	<para>Naast de vervangingskarakters die al zijn toegelicht,
	  zoals %a, bestaan er nog een paar andere.  In de
	  handboekpagina van &man.hosts.access.5; staat een volledige
	  lijst.</para>
      </sect3>

      <sect3>
	<title>Wildcard opties</title>

	<para>Tot nu toe is in ieder voorbeeld <literal>ALL</literal>
	  gebruikt.  Er bestaan nog andere opties waarmee de
	  mogelijkheden nog verder gaan.  Zo kan <literal>ALL</literal>
	  gebruikt worden om van toepassing te zijn op iedere instantie
	  van een daemon, domein of een <acronym>IP</acronym> adres.
	  Een andere wildcard die gebruikt kan worden is
	  <literal>PARANOID</literal>.  Daarmee wordt iedere host die
	  een <acronym>IP</acronym> adres geeft dat gefingeerd kan zijn
	  aangeduid.  In andere woorden: <literal>paranoid</literal>
	  kan gebruikt worden om een actie aan te geven als er een
	  <acronym>IP</acronym> adres gebruikt wordt dat verschilt van
	  de hostnaam.  Het volgende voorbeeld kan wat verheldering
	  brengen:</para>

	<programlisting># Weiger mogelijke gespoofte verzoeken aan sendmail:
sendmail : PARANOID : deny</programlisting>

	<para>In het voorgaande voorbeeld worden alle
	  verbindingsverzoeken aan <command>sendmail</command> met een
	  <acronym>IP</acronym> adres dat verschilt van de hostnaam
	  geweigerd.</para>

	<caution>
	  <para>Het gebruik van <literal>PARANOID</literal> kan nogal
	    wat schade aanrichten als de client of de server kapotte
	    <acronym>DNS</acronym> instellingen heeft.  Voorzichtigheid
	    van de beheerder is geboden.</para>
	</caution>

	<para>De handboekpagina van &man.hosts.access.5; geeft meer
	  uitleg over wildcards en de mogelijkheden die ze
	  bieden.</para>

	<para>Voordat de bovenstaande instellingen werken, dient de
	  eerste regels in <filename>hosts.allow</filename> als
	  commentaar gemarkeerd te worden.</para>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="kerberosIV">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Mark</firstname>
	  <surname>Murray</surname>
	  <contrib>Bijgedragen door </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Mark</firstname>
	  <surname>Dapoz</surname>
	  <contrib>Gebaseerd op een bijdrage van </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Siebrand</firstname>
	  <surname>Mazeland</surname>
	  <contrib>Vertaald door </contrib>
	</author>
      </authorgroup>
    </sect1info>

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

    <para><application>Kerberos</application> is een netwerkdienst,
      protocol en systeem waarmee gebruikers zich kunnen aanmelden met
      behulp van een dienst op een veilige server.  Diensten als op een
      andere server aanmelden, op afstand kopi&euml;ren, veilig tussen
      systemen kopi&euml;ren en andere taken met een hoog risico worden
      aanmerkelijk veiliger en beter controleerbaar.</para>

    <para>De onderstaande instructies kunnen gebruikt worden als
      handleiding voor het opzetten van Kerberos op &os;.  Voor een
      volledige beschrijving wordt verwezen naar de relevante
      handboekpagina's.</para>

    <sect2>
      <title><application>KerberosIV</application> installeren</title>

      <indexterm><primary>MIT</primary></indexterm>

      <indexterm>
	<primary>KerberosIV</primary>

	<secondary>installeren</secondary>
      </indexterm>

      <para>Kerberos is een optioneel component van &os;.  De meest
	eenvoudige manier om de software te installeren is het
	selecteren van de <literal>krb4</literal> of
	<literal>krb5</literal> distributie in
	<application>sysinstall</application> tijdens de initi&euml;le
	installatie van &os;.  Hierdoor wordt de <quote>eBones</quote>
	(KerberosIV) of <quote>Heimdal</quote> (Kerberos5)
	implementatie van Kerberos ge&iuml;nstalleerd.  Deze
	implementaties zijn beschikbaar omdat ze ontwikkeld zijn buiten
	de VS/Canada en dus zijn ze beschikbaar voor systeemeigenaren
	buiten die landen in dit tijdperk waarin er beperkingen gelden
	ten aanzien van de export van coderingsprogramma's uit de
	VS.</para>

      <para>Het is ook mogelijk te kiezen voor de MIT implementatie van
	Kerberos via de Portscollectie: <filename
	  role="package">security/krb5</filename>.</para>
    </sect2>

    <sect2>
      <title>Maken van de initi&euml;le database</title>

      <para>Dit hoeft alleen op de Kerberos gedaan te worden.  Er
	dienen geen oude Kerberos databases rond te slingeren.
	Controleer in de map <filename>/etc/kerberosIV</filename> of de
	volgende bestanden aanwezig zijn:</para>

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

      <para>Als er nog meer bestanden zijn (zoals
	<filename>principal.*</filename> of
	<filename>master_key</filename>), dan kan met het programma
	<command>kdb_destroy</command> de oude Kerberos database
	vernietigd worden of de overige bestanden kunnen verwijderd
	worden als Kerberos niet draait.</para>

      <para>Nu moeten de bestanden <filename>krb.conf</filename> en
	<filename>krb.realms</filename> gewijzigd om de Kerberos wereld
	te defini&euml;ren.  In dit geval heet de wereld
	<literal>EXAMPLE.COM</literal> en de server heet
	<hostid role="fqdn">grunt.example.com</hostid>.  Wijzig of
	cre&euml;er het bestand <filename>krb.conf</filename>:</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>In dit geval hoeven de andere werelden er niet te zijn.  Ze
	staan er als voorbeeld van hoe een machine attent gemaakt kan
	worden op het bestaan van meerdere werelden.  In een eigen test
	kan ervoor gekozen worden ze weg te laten.</para>

      <para>De eerste regel benoemt de wereld waarin het systeem
	opereert.  De andere regels bevatten werelden/hosts.  Het
	eerste deel van een regel bevat de wereld en het tweede deel is
	een host in die wereld die fungeert als <quote>sleutel
	distributiecentrum</quote>.  De woorden <literal>admin
	  server</literal> achter een hostnaam betekenen dat een host
	ook administratieve database server is.  In de handboekpagina's
	van Kerberos wordt hierover meer uitleg gegeven.</para>

      <para>Nu moet <hostid role="fqdn">grunt.example.com</hostid> aan
	de wereld <literal>EXAMPLE.COM</literal> toegevoegd worden en
	er moet ook een instelling gemaakt worden voor alle hosts uit
	het <hostid role="domainname">.example.com</hostid> domein in
	de wereld <literal>EXAMPLE.COM</literal>.  Het bestand
	<filename>krb.realms</filename> dient dan als volgt gewijzigd
	te worden:</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>Nogmaals: de andere werelden hoeven er niet te staan.  Ze
	staan er als voorbeeld hoe een machine van het bestaan van
	andere werelden op de hoogte gebracht kan worden.  Om het
	overzichtelijker te maken, kan mogen ze verwijderd
	worden.</para>

      <para>De eerste regel plaatst het <emphasis>specifieke</emphasis>
	systeem in de genoemde wereld.  De rest van de regels geeft aan
	hoe standaardsystemen uit een bepaald subdomein in een wereld
	plaatst worden.</para>

      <para>Nu kan de database aangemaakt worden.  Dit hoeft alleen op
	de Kerberos server gedaan te worden (of Sleutel Distributie
	Centrum) met het commando <command>kdb_init</command>:</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>Nu moet de sleutel opgeslagen worden zodat diensten op de
	lokale machine er gebruik van kunnen maken met het commando
	<command>kstash</command>:</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>Nu is de gecodeerde hoofdsleutel opgeslagen in
	<filename>/etc/kerberosIV/master_key</filename>.</para>
    </sect2>

    <sect2>
      <title>Help het aan de praat</title>

      <indexterm>
	<primary>KerberosIV</primary>

	<secondary>eerste keer starten</secondary>
      </indexterm>

      <para>Voor <emphasis>ieder</emphasis> systeem dat met Kerberos
	wordt beveiligd moeten twee principals worden aangemaakt.  Die
	heten <literal>kpasswd</literal> en <literal>rcmd</literal>.
	Deze twee principals worden aangemaakt voor iedere systeem en
	de instantie is de naam van het systeem.</para>

      <para>Deze daemons, <application>kpasswd</application> en
	<application>rcmd</application>, staan andere systemen toe om
	Kerberos wachtwoorden te wijzigen en commando's als
	&man.rcp.1;, &man.rlogin.1; en &man.rsh.1; uit te
	voeren.</para>

      <para>Deze worden nu toegevoegd:</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;---- enter RANDOM here
Verifying password

<prompt>New Password:</prompt> &lt;---- enter RANDOM here

<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;---- enter RANDOM here
Verifying password

<prompt>New Password:</prompt>           &lt;---- enter RANDOM here

<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;---- null entry here will cause an exit</screen>
    </sect2>

    <sect2>
      <title>Aanmaken van het serverbestand</title>

      <para>Nu moeten alle instanties die de diensten op iedere server
	defini&euml;ren ge&euml;xtraheerd worden.  Dat kan met het
	commando <command>ext_srvtab</command>.  Dit commando maakt een
	bestand aan dat <emphasis>veilig</emphasis> gekopieerd moet
	worden naar de map <filename>/etc/kerberosIV</filename> van
	iedere Kerberos client.  Dit bestand moet aanwezig zijn op
	iedere server en op iedere client en is van doorslaggevend
	belang voor de werking van Kerberos.</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>Het bovenstaande commando maakt een tijdelijk bestand aan
	dat hernoemd moet worden naar <filename>srvtab</filename> zodat
	alle diensten erbij kunnen.  Met &man.mv.1; kan het op de
	juiste plaats op het originele systeem gezet worden:</para>

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

      <para>Als het bestand voor een clientsysteem is en het netwerk is
	niet veilig, dan kan het bestand
	<filename><replaceable>client</replaceable>-new-srvtab</filename>
	dan naar een verwijderbaar medium gekopieerd worden en dan
	fysiek veilig getransporteerd worden.  Op de client dient het
	bestand <filename>srvtab</filename> te heten in de map
	<filename>/etc/kerberosIV</filename> en in mode 600 te
	staan:</para>

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

    <sect2>
      <title>De database vullen</title>

      <para>Nu moeten de gebruikers in de database.  In dit voorbeeld
	wordt de gebruiker <username>jane</username> als eerste
	ingevoerd.  Hiervoor is het commando
	<command>kdb_edit</command>:</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>jane</userinput>
<prompt>Instance:</prompt>

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

Principal: jane, Instance: , kdc_key_ver: 1
<prompt>New Password:</prompt>                &lt;---- enter a secure password here
Verifying password

<prompt>New Password:</prompt>                &lt;---- re-enter the password here
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;---- null entry here will cause an exit</screen>
    </sect2>

    <sect2>
      <title>Alles testen</title>

      <para>Eerst moeten de Kerberos daemons gestart worden.  Als de
	juiste wijziging in <filename>/etc/rc.conf</filename> zijn
	gemaakt, dan gebeurt dit automatisch na een herstart.  Dit
	hoeft alleen ingesteld te worden op de Kerberos server.
	Kerberos clients vinden automatisch wat ze zoeken in de
	map <filename>/etc/kerberosIV</filename>.</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>Nu kunnen kan er getest worden of met het commando
	<command>kinit</command> een ticket (kaartje) gekregen kan
	worden voor het ID <username>jane</username> dat net is
	aangemaakt:</para>

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

      <para>Met <command>klist</command> kan gecontroleerd worden of de
	tokens er echt zijn:</para>

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

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

      <para>Nu wordt het wachtwoord gewijzigd met &man.passwd.1; om
	te controleren of de <application>kpasswd</application> daemon
	autorisatie krijgt van de Kerberos database:</para>

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

    <sect2>
      <title><command>su</command> rechten toewijzen</title>

      <para>Kerberos biedt mogelijkheid <emphasis>iedere</emphasis>
	gebruiker die <username>root</username>rechten nodig heeft zijn
	eigen <emphasis>afzonderlijke</emphasis> &man.su.1; wachtwoord
	te geven.  Nu wordt een ID toegevoegd dat geautoriseerd is om
	&man.su.1; te gebruiken naar <username>root</username>.  Dit
	wordt geregeld door een instantie van <username>root</username>
	te verbinden met een principal.  Met
	<command>kdb_edit</command> kan <literal>jane.root</literal>
	gemaakt worden in de Kerberos database:</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>jane</userinput>
<prompt>Instance:</prompt> <userinput>root</userinput>

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

Principal: jane, Instance: root, kdc_key_ver: 1
<prompt>New Password:</prompt>                    &lt;---- enter a SECURE password here
Verifying password

<prompt>New Password:</prompt>                    &lt;---- re-enter the password here

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;--- Keep this short!
<prompt>Attributes [ 0 ] ?</prompt>
Edit O.K.
<prompt>Principal name:</prompt>                         &lt;---- null entry here will cause an exit</screen>

      <para>Een lijst van de tokens kan bevestigen als alles werkt
	zoals verwacht:</para>

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

      <para>Nu dient de gebruiker toegevoegd te worden aan het
	bestand <filename>.klogin</filename> van
	<username>root</username>:</para>

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

      <para>Na een &man.su.1;:</para>

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

      <para>kan de lijst met tokens bekeken worden:</para>

      <screen>&prompt.root; <userinput>klist</userinput>
Ticket file:    /tmp/tkt_root_245
Principal:      jane.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>Andere commando's gebruiken</title>

      <para>In een eerder voorbeeld is een principal met de naam
	<literal>jane</literal> gemaakt met een instantie
	<literal>root</literal>.  Dit was gebaseerd op een gebruiker met
	dezelfde naam als de principal en dit is de standaard binnen
	Kerberos: een
	<literal>&lt;principal&gt;.&lt;instantie&gt;</literal> in de
	vorm van <literal>&lt;gebruikersnaam&gt;.</literal>
	<username>root</username> staat die
	<literal>&lt;gebruikersnaam&gt;</literal> het gebruik van
	&man.su.1; naar <username>root</username> toe als de benodigde
	instellingen in het bestand <filename>.klogin</filename> in de
	home directory van <username>root</username> zijn
	gemaakt:</para>

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

      <para>Zo werkt het ook als een gebruiker in zijn eigen home
	directory iets als volgt heeft opgenomen:</para>

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

      <para>Hierdoor mag iedereen die zich in de wereld
	<literal>EXAMPLE.COM</literal> heeft geauthenticeerd als
	<username>jane</username> of <username>jack</username> (via
	<command>kinit</command>, zie boven) bij
	<username>jane</username>'s account of de bestanden op dit
	systeem (<hostid>grunt</hostid>) met &man.rlogin.1;,
	&man.rsh.1; of &man.rcp.1;.</para>

      <para>Nu meldt bijvoorbeeld <username>jane</username> zich aan
	op een ander systeem met Kerberos:</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>Of <username>jack</username> meldt zich aan op
	<username>jane</username>'s account op dezelfde machine
	(<username>jane</username> heeft het bestand
	<filename>.klogin</filename> ingesteld zoals hierboven en de
	beheerder van Kerberos heeft een principal
	<emphasis>jack</emphasis> aangemaakt zonder instantie):</para>

      <screen>&prompt.user; <userinput>kinit</userinput>
&prompt.user; <userinput>rlogin grunt -l jane</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>Bijgedragen door </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Mark</firstname>
	  <surname>Murray</surname>
	  <contrib>Gebaseerd op een bijdrage van </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Siebrand</firstname>
	  <surname>Mazeland</surname>
	  <contrib>Vertaald door </contrib>
	</author>
      </authorgroup>
    </sect1info>

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

    <para>Iedere &os; release hoger dan &os;-5.1 bevat alleen
      ondersteuning voor <application>Kerberos5</application>.  Daarom
      is <application>Kerberos5</application> de enige versie die erbij
      zit.  De instellingen zijn op veel gebieden gelijk aan die van
      <application>KerberosIV</application>.  De nu volgende informatie
      geldt alleen voor &os;-5.0 releases en verder.  Gebruikers die
      het <application>KerberosIV</application> package willen
      gebruiken kunnen dat installeren uit de
      <filename role="package">security/krb4</filename> port.</para>

    <para><application>Kerberos</application> is een netwerkdienst,
      protocol en systeem waarmee gebruikers zich kunnen aanmelden
      met behulp van een dienst op een veilige server.  Diensten als
      op een andere server aanmelden, op afstand kopi&euml;ren, veilig
      tussen systemen kopi&euml;ren en andere taken met een hoog risico
      worden aanmerkelijk veiliger en beter controleerbaar.</para>

    <para><application>Kerberos</application> kan omschrijven worden
      als identiteitbevestigend proxy systeem.  Het kan ook
      omschreven worden als een vertrouwd authenticatiesysteem van een
      derde partij.  <application>Kerberos</application> vervult maar
      &eacute;&eacute;n taak: het veilig authenticeren van gebruikers
      op het netwerk.  Het vervult geen autorisatietaken (wat
      gebruikers mogen) en controleert ook niets (wat gebruikers hebben
      gedaan).  Nadat een client en server
      <application>Kerberos</application> hebben gebruikt om hun
      identiteit vast te stellen kunnen ze ook al hun communicatie
      coderen om hun privacy en data-integriteit te garanderen.</para>

    <para>Daarom wordt het sterk aangeraden om
      <application>Kerberos</application> samen met andere
      beveiligingsmechanismen te gebruiken die autorisatie en
      controlemogelijkheden bieden.</para>

    <para>De aanwijzingen die nu volgen kunnen gebruikt worden als
      werkinstructie om <application>Kerberos</application> in te
      stellen zoals dat wordt meegeleverd met &os;.  Een complete
      beschrijving staat in de handboekpagina.</para>

    <para>Voor demonstratie van de installatie van
      <application>Kerberos</application> wordt gebruik gemaakt van de
      volgende naamgeving:</para>

    <itemizedlist>
      <listitem>
	<para>Het <acronym>DNS</acronym> domein (<quote>zone</quote>)
	  is example.org.</para>
      </listitem>

      <listitem>
	<para>De <application>Kerberos</application> wereld is
	  EXAMPLE.ORG.</para>
      </listitem>
    </itemizedlist>

    <note>
      <para>Het advies is voor installaties van
	<application>Kerberos</application> echte domeinnamen te
	gebruiken, zelfs als het alleen intern wordt gebruikt.  Hiermee
	worden <acronym>DNS</acronym> problemen voorkomen is een
	goede samenwerking met andere
	<application>Kerberos</application> werelden verzekerd.</para>
    </note>

    <sect2>
      <title>Geschiedenis</title>

      <indexterm>
	<primary>Kerberos5</primary>

	<secondary>geschiedenis</secondary>
      </indexterm>

      <para><application>Kerberos</application> is ontworpen door
	<acronym>MIT</acronym> als oplossing voor
	netwerkbeveiligingsproblemen.  Het
	<application>Kerberos</application> protocol gebruikt sterke
	codering zodat een client zijn identiteit kan bewijzen aan een
	server (en andersom) over een onveilige
	netwerkverbinding.</para>

      <para><application>Kerberos</application> is zowel de naam van
	een netwerkautorisatieprotocol als een bijvoeglijk naamwoord om
	de programma's te beschrijven die gebruik maken van het
	programma (zoals <application>Kerberos</application> telnet).
	De huidige versie van het protocol is versie 5 en is beschreven
	in <acronym>RFC</acronym>&nbsp;1510.</para>

      <para>Er zijn een aantal vrij beschikbare implementaties van dit
	protocol beschikbaar voor veel systemen.  Het Massachusetts
	Institute of Technology (<acronym>MIT</acronym>), waar
	<application>Kerberos</application> ooit is ontwikkeld,
	ontwikkelt nog steeds door aan hun
	<application>Kerberos</application> pakket.  Het wordt in de
	<acronym>VS</acronym> veel gebruikt als coderingspakket en
	daarom wordt het ook geraakt door de exportwetgeving van de
	<acronym>VS</acronym>.  <application>Kerberos</application>
	van <acronym>MIT</acronym> is beschikbaar als port
	(<filename role="package">security/krb5</filename>).  Heimdal
	<application>Kerberos</application> is een andere implementatie
	van versie 5 die expliciet buiten de <acronym>VS</acronym> is
	ontwikkeld om de exportwetgeving de omzeilen (en wordt daarom
	vaak gebruikt in niet-commerci&euml;le &unix; varianten).  De
	Heimdal <application>Kerberos</application> distributie is
	beschikbaar als port (<filename
	  role="package">security/heimdal</filename>) en er zit een
	minimale installatie in de basisinstallatie van &os;.</para>

      <para>Om het grootst mogelijke publiek te bereiken gaan deze
	instructies ervan uit dat de Heimdal distributie die bij &os;
	zit wordt gebruikt.</para>
    </sect2>

    <sect2>
      <title>Opzetten van een Heimdal <acronym>KDC</acronym></title>

      <indexterm>
	<primary>Kerberos5</primary>

	<secondary>sleutel distributie centrum instellingen</secondary>
      </indexterm>

      <para>Het Sleutel Distributie Centrum (<acronym>KDC</acronym>,
	voluit <quote>Key Distribution Center</quote>) is de
	gecentraliseerde authenticatiedienst die
	<application>Kerberos</application> levert.  Het is de computer
	die <application>Kerberos</application> tickets uitgeeft.  Het
	<acronym>KDC</acronym> wordt <quote>vertrouwd</quote> door
	alle andere computer in de <application>Kerberos</application>
	wereld en daarom dient er een strenger beveiligingsregime op
	van kracht te zijn.</para>

      <para>Hoewel het draaien van de
	<application>Kerberos</application> dienst erg weinig van een
	systeem vraagt, wordt het wel aangeraden om een machine in te
	richten exclusief voor het <acronym>KDC</acronym> om
	beveiligingsredenen.</para>

      <para>Het opzetten van een <acronym>KDC</acronym> begint met de
	controle of de instellingen in
	<filename>/etc/rc.conf</filename> juist zijn om te functioneren
	als <acronym>KDC</acronym> (misschien moeten paden veranderd
	worden voor een eigen systeem):</para>

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

      <note>
	<para><option>kerberos_stash</option> is alleen beschikbaar in
	  &os;&nbsp;4.X.</para>
      </note>

      <para>Daarna wordt het <application>Kerberos</application>
	instellingenbestand <filename>/etc/krb5.conf</filename>
	aangemaakt:</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><filename>/etc/krb5.conf</filename> gaat ervan uit dat de
	<acronym>KDC</acronym> de fully-qualified hostname <hostid
	  role="fqdn">kerberos.example.org</hostid> heeft.  Als de
	<acronym>KDC</acronym> een andere hostname heeft, moet er nog
	een CNAME (alias) toevoegd aan de zonefile.</para>

      <note>
	<para>Voor grotere netwerken met een juist ingestelde
	<acronym>BIND</acronym> <acronym>DNS</acronym> server kan
	het bovenstaande voorbeeld ingekort worden tot:</para>

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

	<para>Door de volgende regels toe te voegen aan de zonefile
	  voor <hostid role="fqdn">example.org</hostid>:</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>Om clients de <application>Kerberos</application>
	  diensten te kunnen laten vinden, <emphasis>moet</emphasis>
	  er een volledig ingestelde
	  <filename>/etc/krb5.conf</filename> zijn of een minimaal
	  ingestelde <filename>/etc/krb5.conf</filename>
	  <emphasis>en</emphasis> een correct ingestelde DNS
	  server.</para>
      </note>

	<para>Nu wordt de <application>Kerberos</application>
	  database aangemaakt.  Deze database bevat de sleutels voor
	  alle principals en zijn versleuteld met een hoofdwachtwoord.
	  Dit wachtwoord hoeft niet onthouden te worden omdat het wordt
	  opgeslagen in (<filename>/var/heimdal/m-key</filename>).  De
	  hoofdsleutel wordt aangemaakt door <command>kstash</command>
	  te starten en een wachtwoord in te voeren.</para>

	<para>Als de hoofdsleutel is gemaakt, kan de database
	  ingeschakeld worden met <command>kadmin</command>
	  met de optie <literal>-l</literal> (die staat voor
	  <quote>local</quote>).  Deze optie geeft
	  <command>kadmin</command> de opdracht om de databasebestanden
	  direct te wijzigingen in plaats van via de
	  <command>kadmind</command> netwerkdienst.  Hiermee wordt het
	  kip-ei probleem opgelost waarbij een verbinding wordt gemaakt
	  met de database voordat hij bestaat.  Op het prompt van
	  <command>kadmin</command> kan met <command>init</command>
	  de database met de werelden aangemaakt worden.</para>

	<para>Tenslotte, nog steeds in <command>kadmin</command>, kan
	  de eerste principal gemaakt worden met
	  <command>add</command>.  De standaardopties voor de principal
	  worden nu aangehouden.  Deze kunnen later altijd
	  nog gewijzigd worden met <command>modify</command>.  Met
	  het commando <literal>?</literal> kunnen alle beschikbare
	  mogelijkheden getoond worden.</para>

	<para>Hieronder een sessie waarin een voorbeelddatabase wordt
	  aangemaakt:</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>Nu kan de <acronym>KDC</acronym> dienst gestart worden
	  met <command>/etc/rc.d/kerberos start</command> en
	  <command>/etc/rc.d/kadmind start</command>.  Op dit moment
	  draait er nog geen enkele daemon die gebruik maakt van
	  <application>Kerberos</application>.  Bevestiging dat
	  <acronym>KDC</acronym> draait is te krijgen door een ticket te
	  vragen en dat uit te lezen voor de principal (user)
	  die zojuist is aangemaakt vanaf de commandoregel van het
	  <acronym>KDC</acronym> zelf:</para>

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

&prompt.user; <userinput>k5list</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>
      </sect2>

      <sect2>
	<title><application>Kerberos</application> inschakelen op een
	  server met Heimdal diensten</title>

	<indexterm>
	  <primary>Kerberos5</primary>

	  <secondary>diensten inschakelen</secondary>
	</indexterm>

	<para>Als eerste is een kopie van het instellingenbestand van
	  <application>Kerberos</application> nodig,
	  <filename>/etc/krb5.conf</filename>.  Dit bestand kan
	  eenvoudigweg op een veilige manier (met netwerkprogramma's
	  als &man.scp.1;, of fysiek via een floppy) naar de
	  clientcomputer gekopieerd worden vanaf de
	  <acronym>KDC</acronym>.</para>

	<para>Hierna is het <filename>/etc/krb5.keytab</filename>
	  nodig.  Dit is het belangrijkste verschil tussen een server
	  die een daemons met <application>Kerberos</application>
	  aanbiedt en een werkstation: de server heeft het bestand
	  <filename>keytab</filename> nodig.  Dit bestand bevat de
	  hostsleutel van de server waardoor het werkstation en de
	  <acronym>KDC</acronym> elkaars identiteit kunnen bevestigen.
	  Dit bestand dient veilig overgebracht te worden omdat de
	  beveiliging van de server doorbroken kan worden als de
	  sleutel openbaar wordt gemaakt.  Dit betekent expliciet dat
	  overdracht via een protocol dat platte tekst gebruikt,
	  bv. <acronym>FTP</acronym>, een slecht idee is.</para>

	<para>Meestal wordt <filename>keytab</filename> naar de
	  server gebracht met <command>kadmin</command>.  Dat
	  werkt handig omdat ook de host principal (het
	  <acronym>KDC</acronym> onderdeel van
	  <filename>krb5.keytab</filename>) aangemaakt moet
	  worden met <command>kadmin</command>.</para>

	<para>Let wel op dat er al een ticket moet zijn en dat dit
	  ticket de <command>kadmin</command> interface moet mogen
	  gebruiken in <filename>kadmind.acl</filename>.  Zie
	  <quote>Beheer op Afstand</quote> in de Heimdal
	  informatiepagina's (<command>info heimdal</command>) voor
	  details over het ontwerpen van toegangscontrole.  Als
	  <command>kadmin</command> via het netwerk geen toegang mag
	  hebben, dan kan ook op een veilige verbinding gemaakt worden
	  met de <acronym>KDC</acronym> (via het lokale console,
	  &man.ssh.1; of <application>Kerberos</application>
	  &man.telnet.1;) zodat alles lokaal uitgevoerd kan worden met
	  <command>kadmin -l</command>.</para>

	<para>Na het installeren van
	  <filename>/etc/krb5.conf</filename> kan
	  <command>kadmin</command> van de
	  <application>Kerberos</application> server gebruikt worden.
	  Met <command>add --random-key</command> kan de host
	  principal toegevoegd worden en met <command>ext</command> kan
	  de host principal van de server naar zijn eigen keytab
	  getrokken worden.  Bijvoorbeeld:</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>Let op: <command>ext</command> slaat de sleutel standaard
	  op in <filename>/etc/krb5.keytab</filename>.</para>

	<para>Als <command>kadmind</command> niet beschikbaar is op de
	  <acronym>KDC</acronym> (wellicht om beveiligingsredenen) en
	  er via het netwerk dus geen toegang is tot
	  <command>kadmin</command>, dan kan de host principal
	  (<username>host/myserver.EXAMPLE.ORG</username>) ook direct
	  aan de <acronym>KDC</acronym> toegevoegd worden en daarna in
	  een tijdelijk bestand gezet worden.  Het volgende kan
	  gebruikt worden om te voorkomen dat
	  <filename>/etc/krb5.keytab</filename> op de
	  <acronym>KDC</acronym>) wordt overschreven:</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>Hierna kan de keytab veilig gekopieerd worden naar de
	  server (met <command>scp</command> of een floppy).  Geef
	  een niet-standaard naam op voor de keytab om te voorkomen
	  dat de keytab op de <acronym>KDC</acronym> wordt
	  overschreven.</para>

	<para>Nu kan de server communiceren met de
	  <acronym>KDC</acronym> (vanweg
	  <filename>krb5.conf</filename>) en zijn identiteit bewijzen
	  (vanwege <filename>krb5.keytab</filename>).  Nu is de server
	  klaar om er een aantal <application>Kerberos</application>
	  diensten op te activeren.  In dit voorbeeld wordt de dienst
	  <command>telnet</command> geactiveerd door de volgende regel
	  in <filename>/etc/inetd.conf</filename> te zetten en dan
	  &man.inetd.8; te herstarten met
	  <command>/etc/rc.d/inetd restart</command>:</para>

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

	<para>Het belangrijkste is dat de typering
	  <command>-a</command> (van authenticatie) op user staat.  Meer
	  details zijn in &man.telnetd.8; te vinden.</para>
      </sect2>

      <sect2>
	<title><application>Kerberos</application> activeren op een
	  client met Heimdal</title>

	<indexterm>
	  <primary>Kerberos5</primary>

	  <secondary>clientinstellingen</secondary>
	</indexterm>

	<para>Het opzetten van een clientcomputer is eigenlijk
	  kinderlijk eenvoudig.  Wat betreft de
	  <application>Kerberos</application> instelling is alleen het
	  <application>Kerberos</application> instellingenbestand
	  (<filename>/etc/krb5.conf</filename>) nodig.  Dat kan
	  eenvoudigweg naar de clientcomputer gekopieerd worden vanaf
	  de <acronym>KDC</acronym>.</para>

	<para>Test de client met <command>kinit</command>,
	  <command>klist</command> en <command>kdestroy</command>
	  vanaf de client om een ticket te krijgen, te bekijken en
	  daarna te verwijderen voor de principal die hierboven is
	  aangemaakt.  Nu moeten ook
	  <application>Kerberos</application> applicaties gebruikt
	  kunnen worden om verbindingen te maken met servers waarop
	  <application>Kerberos</application> is geactiveerd.  Als dat
	  niet lukt en het verkrijgen van een ticket is wel mogelijk,
	  dan ligt dat hoogstwaarschijnlijk aan de server en niet aan
	  de client of de <acronym>KDC</acronym>.</para>

	<para>Bij het testen van een applicatie als
	  <command>telnet</command> kan het beste een pakketsnuffelaar
	  (bv. &man.tcpdump.1;) gebruikt worden om te bevestigen dat
	  een wachtwoord niet als tekst wordt verzonden.  Gebruik
	  <command>telnet</command> met de optie <literal>-x</literal>.
	  Dan wordt de complete datastroom versleuteld (vergelijkbaar
	  met <command>ssh</command>).</para>

	<para>De <application>Kerberos</application> sleutelapplicaties
	  op de client (meestal <command>kinit</command>,
	  <command>klist</command>, <command>kdestroy</command> en
	  <command>kpasswd</command>) zitten in de basisinstallatie
	  van &os;.  Let wel dat ze in &os; versies van voor 5.0
	  hernoemd zijn naar <command>k5init</command>,
	  <command>k5list</command>, <command>k5destroy</command>,
	  <command>k5passwd</command> en <command>k5stash</command>
	  (deze commando's worden gewoonlijk maar een keer
	  gebruikt).</para>

	<para>Er worden standaard ook andere
	  <application>Kerberos</application> applicaties op de client
	  ge&iuml;nstalleerd.  Hier komt de
	  <quote>minimalistische</quote> natuur van de Heimdal
	  basisinstallatie boven drijven: <command>telnet</command> is
	  de enige dienst waarvoor <application>Kerberos</application>
	  geactiveerd is.</para>

	<para>De Heimdal port voegt een aantal missende
	  clientapplicaties toe: versies met ondersteuning voor
	  <application>Kerberos</application> van
	  <command>ftp</command>, <command>rsh</command>,
	  <command>rcp</command>, <command>rlogin</command> en een paar
	  minder gebruikelijke programma's.  De <acronym>MIT</acronym>
	  port bevat ook een volledig gamma aan
	  <application>Kerberos</application> clientapplicaties.</para>
      </sect2>

      <sect2>
	<title>Instellingenbestanden voor gebruikers:
	  <filename>.k5login</filename> en
	  <filename>.k5users</filename></title>

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

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

	<para>Voor gebruikers binnen een wereld wijst hun
	  <application>Kerberos</application> principal (bv.
	  <username>tillman@EXAMPLE.ORG</username>) gewoonlijk naar
	  een lokale gebruikeraccount (bijvoorbeeld een lokale account
	  met de naam <username>tillman</username>).  Voor
	  clientapplicaties als <command>telnet</command> is gewoonlijk
	  geen gebruikersnaam of principal nodig.</para>

	<para>Soms moet iemand zonder bijpassende
	  <application>Kerberos</application> principal toch toegang
	  hebben tot een lokale gebruikersaccount.
	  <username>tillman@EXAMPLE.ORG</username> zou bijvoorbeeld
	  toegang nodig kunnen hebben tot de lokale gebruikersaccount
	  <username>webdevelopers</username>.  Andere principals zouden
	  die toegang wellicht ook nodig kunnen hebben.</para>

	<para>De bestanden <filename>.k5login</filename> en
	  <filename>.k5users</filename> uit de gebruikersmap kunnen op
	  eenzelfde manier gebruikt worden als
	  <filename>.hosts</filename> en <filename>.rhosts</filename>.
	  Zo wordt het voorgaande probleem opgelost.  Als bijvoorbeeld
	  een <filename>.k5login</filename> met de volgende
	  inhoud:</para>

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

	<para>in de thuismap van de lokale gebruiker
	  <username>webdevelopers</username> gezet wordt dan zouden
	  beide principals toegang hebben tot die account zonder dat
	  ze een wachtwoord hoeven te delen.</para>

	<para>We raden aan de handboekpagina's voor deze commando's
	  te lezen.  Let op dat de <command>ksu</command> handboekpagina
	  <filename>.k5users</filename> behandelt.</para>
      </sect2>

      <sect2>
	<title><application>Kerberos</application> tips, trucs en
	  problemen oplossen</title>

	<indexterm>
	  <primary>Kerberos5</primary>

	  <secondary>problemen oplossen</secondary>
	</indexterm>

	<itemizedlist>
	  <listitem>
	    <para>Als de Heimdal of <acronym>MIT</acronym>
	      <application>Kerberos</application> port wordt gebruikt
	      dan dient de <envar>PATH</envar> omgevingsvariabele
	      de <application>Kerberos</application> versies van de
	      clientapplicaties te tonen voor de systeemversies.</para>
	  </listitem>

	  <listitem>
	    <para>Hebben alle computers in de wereld hun tijd
	      gesynchroniseerd?  Als dat niet zo is, dan slaagt de
	      authenticatie wellicht niet.
	      <xref linkend="network-ntp"> beschrijft hoe klokken
	      met <acronym>NTP</acronym> gesynchroniseerd kunnen
	      worden.</para>
	  </listitem>

	  <listitem>
	    <para><acronym>MIT</acronym> en Heimdal werken prima samen.
	      Dit geldt niet voor <command>kadmin</command> omdat
	      daarvoor geen protocolstandaard is.</para>
	  </listitem>

	  <listitem>
	    <para>Als een hostnaam wordt gewijzigd, dan moet ook de
	      <username>host/</username> principal aangepast en de
	      keytab.  Dit geldt ook voor bijzondere instellingen
	      in de keytab zoals de <username>www/</username> principal
	      voor <filename
		role="package">www/mod_auth_kerb</filename> van
	      Apache.</para>
	  </listitem>

	  <listitem>
	    <para>Alle hosts in een wereld moeten oplosbaar
	      (resolvable) zijn (zowel vooruit als achteruit) in de
	      <acronym>DNS</acronym> (of tenminste in
	      <filename>/etc/hosts</filename>).  CNAMEs werken wel,
	      maar de A en PTR records moeten juist en actief zijn.  De
	      foutmelding is niet erg duidelijk: <errorname>Kerberos5
	      refuses authentication because Read req failed: Key table
	      entry not found</errorname>.</para>
	  </listitem>

	  <listitem>
	    <para>Sommige besturingssystemen van clients voor een
	      <acronym>KDC</acronym> zetten wellicht geen setuid
	      <username>root</username> voor <command>ksu</command>.
	      Dit betekent dat <command>ksu</command> niet werkt.  Dat
	      is vanuit beveiligingsoogpunt een prima idee, maar wel
	      lastig.  Dit is dus geen <acronym>KDC</acronym>
	      fout.</para>
	  </listitem>

	  <listitem>
	    <para>Als met <acronym>MIT</acronym>
	      <application>Kerberos</application> een principal een
	      ticket moet krijgen dat langer geldig is dan de standaard
	      van tien uur, dan moet
	      <command>modify_principal</command> in
	      <command>kadmin</command> gebruikt worden om de maximale
	      geldigheidsduur (maxlife) van zowel de principal waar het
	      om gaat als de <username>krbtgt</username> principal aan
	      te passen.  Dan kan de principal <command>kinit</command>
	      <literal>-l</literal> gebruiken om een ticket met een
	      langere levensduur aan te vragen.</para>
	  </listitem>

	  <listitem>
	    <note>
	      <para>Als een pakketsnuffelaar op de
		<acronym>KDC</acronym> draait bij om te helpen bij het
		oplossen van problemen en dan <command>kinit</command>
		vanaf een werkstation wordt gestart, dan wordt zichtbaar
		dat de <acronym>TGT</acronym> meteen wordt verstuurd als
		<command>kinit</command> start, zelfs nog voor het
		wachtwoord!  De reden hiervoor is dat de
		<application>Kerberos</application> server vrijelijk een
		<acronym>TGT</acronym> (Ticket Granting
		Ticket) verstuurt op iedere niet geautoriseerd verzoek.
		Maar iedere <acronym>TGT</acronym> is versleuteld met een
		sleutel die is afgeleid van het wachtwoord van de
		gebruiker.  Als een gebruiker zijn wachtwoord ingeeft,
		wordt dat dus niet naar de <acronym>KDC</acronym>
		gezonden, maar ontcijfert het de <acronym>TGT</acronym>
		die <command>kinit</command> al heeft ontvangen.  Als de
		ontcijfering resulteert in een geldige ticket met een
		geldige tijdstempel, dan heeft de gebruiker geldige
		<application>Kerberos</application> rechten.  Deze
		rechten bevatten ook een sessiesleutel voor het opzetten
		van beveiligde communicatie met de
		<application>Kerberos</application> server in de toekomst
		en de eigenlijke ticket-granting ticket, die is
		versleuteld met de sleutel van de
		<application>Kerberos</application> server zelf.  Deze
		tweede laag van versleuteling is niet bekend voor de
		gebruiker, maar het stelt de
		<application>Kerberos</application> server in staat om de
		juistheid van iedere <acronym>TGT</acronym> te
		bevestigen.</para>
	    </note>
	  </listitem>

	  <listitem>
	    <para>Als tickets worden gebruik die lang geldig zijn (bv.
	      een week) en <application>OpenSSH</application> wordt
	      gebruikt om een verbinding te maken met de machine waarop
	      het ticket staat, zorg er dan voor dat de
	      <application>Kerberos</application> optie
	      <option>TicketCleanup</option> op <literal>no</literal>
	      staat in <filename>sshd_config</filename> want anders
	      worden tickets verwijderd bij afmelden.</para>
	  </listitem>

	  <listitem>
	    <para>Host principals kunnen ook een langere levensduur
	      hebben.  Als een gebruikers principal een levensduur van
	      een week heeft, maar de host waar de verbinding mee
	      gemaakt wordt heeft een levensduur van negen uur,
	      dan heb staat er een verlopen host principal in de cache
	      en dan werkt e.e.a. niet zoals verwacht.</para>
	  </listitem>

	  <listitem>
	    <para>Een <filename>krb5.dict</filename> bestand om het
	      gebruik van bepaalde slechte wachtwoorden te voorkomen
	      (dit wordt kort behandeld in de handboekpagina voor
	      <command>kadmind</command>) heeft alleen betrekking op
	      principals waar een wachtwoordbeleid voor geldt.  De
	      opmaak van <filename>krb5.dict</filename> is eenvoudig:
	      een rij tekens per regel.  Een symbolic link maken naar
	      <filename>/usr/share/dict/words</filename> is misschien
	      handig.</para>
	  </listitem>
	</itemizedlist>
      </sect2>

      <sect2>
	<title>Verschillen met de <acronym>MIT</acronym> port</title>

	<para>Het belangrijkste verschil tussen de
	  <acronym>MIT</acronym> en Heimdal installatie heeft
	  betrekking op <command>kadmin</command>, dat een andere (maar
	  gelijkwaardige) set commando's kent en een andere protocol
	  gebruikt.  Dit betekent nogal wat als een
	  <acronym>KDC</acronym> <acronym>MIT</acronym> is, omdat
	  dan de <command>kadmin</command> van Heimdal niet gebruikt
	  kan worden om de <acronym>KDC</acronym> vanaf afstand te
	  beheren (dat geldt trouwens ook vice versa).</para>

	<para>De clientapplicaties kunnen ook commandoregelopties
	  gebruiken die een beetje verschillen, maar waarmee wel
	  hetzelfde wordt bereikt.  We raden aan de instructies op de
	  <acronym>MIT</acronym> <application>Kerberos</application>
	  website (<ulink
	    url="http://web.mit.edu/Kerberos/www/"></ulink>) te volgen.
	  Wees voorzichtig met paden: de <acronym>MIT</acronym> port
	  installeert standaard in
	  <filename>/usr/local/</filename> en dus kunnen de
	  <quote>normale</quote> systeemapplicaties gestart worden in
	  plaats van die van <acronym>MIT</acronym> als de
	  <envar>PATH</envar> omgevingsvariabele de systeemmappen als
	  eerste weergeeft.</para>

	<note>
	  <para>Als de <acronym>MIT</acronym>
	    <filename role="package">security/krb5</filename> port die
	    bij &os; zit wordt gebruikt, dan zorgt het lezen van
	    <filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>
	    dat bij de port wordt ge&iuml;nstalleerd voor een beter
	    begrip over waarom het aanmelden via
	    <command>telnetd</command> en <command>klogind</command>
	    soms wat vreemd verloopt.  Als belangrijkste wijzen we erop
	    dat het bij het corrigeren van
	    <quote>onjuiste rechten op het cachebestand</quote>
	    noodzakelijk is dat het binaire bestand
	    <command>login.krb5</command> wordt gebruikt voor
	    authenticatie zodat het op de juiste wijze eigenaarschap kan
	    wijzigen voor de doorgegeven rechten.</para>
	</note>
      </sect2>

      <sect2>
	<title>Beperkingen in
	  <application>Kerberos</application></title>

	<indexterm>
	  <primary>Kerberos5</primary>

	  <secondary>beperkingen en tekortkomingen</secondary>
	</indexterm>

	<sect3>
	  <title><application>Kerberos</application> is een alles of
	    niets aanpak</title>

	  <para>Iedere ingeschakelde dienst op het netwerk moet
	    aangepast worden om met <application>Kerberos</application>
	    te werken (of op een andere manier beschermd zijn tegen
	    netwerkaanvallen), want anders kunnen gebruikersrechten
	    worden gestolen en hergebruikt.  Een voorbeeld hier van is
	    het inschakelen van <application>Kerberos</application>
	    voor alle shells op afstand (via <command>rsh</command> en
	    <command>telnet</command> bijvoorbeeld), maar de
	    <acronym>POP3</acronym> mailserver die wachtwoorden als
	    platte tekst verzend ongemoeid laten.</para>
	</sect3>

	<sect3>
	  <title><application>Kerberos</application> is bedoeld voor
	    werkstations met een gebruiker</title>

	  <para>In een multi-user omgeving is
	    <application>Kerberos</application> minder veilig.  Dit
	    komt doordat de tickets worden opgeslagen in de map
	    <filename>/tmp</filename>, waar gelezen kan worden door
	    alle gebruikers.  Als een gebruiker een computer deelt met
	    andere gebruikers op hetzelfde moment (dus multi-user), dan
	    is het mogelijk dat een ticket van een gebruiker wordt
	    gestolen (gekopieerd) door een andere gebruiker.</para>

	  <para>Dit kan voorkomen worden met de commandoregeloptie
	    <quote><literal>-c</literal> bestandsnaam</quote> of (bij
	    voorkeur) de omgevingsvariabele <envar>KRB5CCNAME</envar>,
	    maar dat wordt zelden gedaan.  In principe kan het opslaan
	    van een ticket in de thuismap van een gebruiker in
	    combinatie met eenvoudige bestandsrechten dit probleem
	    verhelpen.</para>
	</sect3>

	<sect3>
	  <title>De KDC is een single point of failure</title>

	  <para>Zoals het is ontworpen, moet de <acronym>KDC</acronym>
	    zo goed mogelijk beveiligd zijn, omdat de hoofd
	    wachtwoorddatabase erop staat.  De <acronym>KDC</acronym>
	    hoort geen enkele andere dienst aan te bieden en moet ook
	    fysiek afgeschermd worden.  Het gevaar is groot, omdat
	    <application>Kerberos</application> alle wachtwoorden
	    versleutelt met dezelfde sleutel (de <quote>master</quote>
	    sleutel) die als een bestand op de <acronym>KDC</acronym>
	    staat.</para>

	  <para>Toch is een gecompromitteerde master sleutel niet zo'n
	    groot probleem als wellicht wordt verondersteld.  De
	    mastersleutel wordt alleen gebruikt om de
	    <application>Kerberos</application> database te
	    versleutelen en als zaad voor de generator van willekeurige
	    nummers.  Zo lang als de toegang tot de
	    <acronym>KDC</acronym> is beveiligd, kan een aanvaller niet
	    echt iets doen met de mastersleutel.</para>

	  <para>Als de <acronym>KDC</acronym> niet beschikbaar is
	    (misschien door een ontzeggen van dienst aanval of
	    netwerkproblemen) kunnen de netwerkdiensten niet gebruikt
	    worden omdat er geen authenticatie uitgevoerd kan worden;
	    een recept voor een ontzeggen van dienst aanval.  Dit
	    risico kan omzeild worden door meerdere
	    <acronym>KDC</acronym>'s (&eacute;&eacute;n master en
	    &eacute;&eacute;n of meer slaves) en een zorgvuldige
	    implementatie van secundaire of fall-back authenticatie.
	    <acronym>PAM</acronym> is hier uitermate geschikt
	    voor.</para>
	</sect3>

	<sect3>
	  <title>Tekortkomingen van
	    <application>Kerberos</application></title>

	  <para><application>Kerberos</application> stelt gebruikers,
	    hosts en diensten in staat om elkaar te authenticeren.
	    Maar het heeft geen mechanisme om de <acronym>KDC</acronym>
	    te authenticeren aan de gebruikers, hosts of diensten.  Dit
	    betekent dat bijvoorbeeld een vervalste
	    <command>kinit</command> alle gebruikersnamen en
	    wachtwoorden zou kunnen afluisteren.  Iets als
	    <filename role="package">security/tripwire</filename> of
	    andere controle-instrumenten voor de integriteit van
	    bestandssystemen kunnen hier verlichting brengen.</para>
	</sect3>
      </sect2>

      <sect2>
	<title>Bronnen en verdere informatie</title>

	<indexterm>
	  <primary>Kerberos5</primary>

	  <secondary>externe bronnen</secondary>
	</indexterm>

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

	<listitem>
	  <para><ulink
	      url="http://web.mit.edu/Kerberos/www/dialogue.html">Een
	      Authenticatiesysteem Ontwerpen: een Dialoog in Vier
	      Scenes</ulink> (Engels)</para>
	</listitem>

	<listitem>
	  <para><ulink
	      url="http://www.ietf.org/rfc/rfc1510.txt?number=1510">
	      RFC 1510, De <application>Kerberos</application> Netwerk
	      Authenticatie Dienst (V5)</ulink> (Engels)</para>
	</listitem>

	<listitem>
	  <para><ulink
	      url="http://web.mit.edu/Kerberos/www/">
	      <acronym>MIT</acronym>
	      <application>Kerberos</application>
	      homepage</ulink></para>
	</listitem>

	<listitem>
	<para><ulink url="http://www.pdc.kth.se/heimdal/">Heimdal
	    <application>Kerberos</application> homepage</ulink></para>
	</listitem>
      </itemizedlist>
    </sect2>
  </sect1>

  <sect1 id="openssl">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Geschreven door </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Siebrand</firstname>
	  <surname>Mazeland</surname>
	  <contrib>Vertaald door </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>OpenSSL</title>

    <indexterm>
      <primary>beveiliging</primary>

      <secondary>OpenSSL</secondary>
    </indexterm>

    <indexterm><primary>OpenSSL</primary></indexterm>

    <para>Een toepassing die bij &os; zit die veel gebruikers over het
      hoofd zien is <application>OpenSSL</application>.
      <application>OpenSSL</application> biedt een versleutelde
      transportlaag bovenop de normale communicatielaag.  Daardoor
      biedt het de mogelijkheid met veel netwerktoepassingen en
      diensten verweven te raken.</para>

    <para>Een aantal toepassingen van
      <application>OpenSSL</application> zijn versleutelde
      authenticatie van mailclients, webgebaseerde transacties als
      creditcardbetalingen en nog veel meer.   Veel ports zoals
      <filename role="package">www/apache13-ssl</filename> en
      <filename role="package">mail/sylpheed-claws</filename>
      bieden tijdens het compileren ondersteuning om
      <application>OpenSSL</application> in te bouwen.</para>

    <note>
      <para>In de meeste gevallen zal de Portscollectie proberen de
	port <filename role="package">security/openssl</filename> te
	bouwen, tenzij de make variabele
	<makevar>WITH_OPENSSL_BASE</makevar> expliciet naar
	<quote>yes</quote> is gezet.</para>
    </note>

    <para>De versie van <application>OpenSSL</application> die bij &os;
      zit ondersteunt Secure Sockets Layer v2/v3 (SSLv2/SSLv3),
      Transport Layer Security v1 (TLSv1) netwerk
      beveiligingsprotocollen en kan gebruikt worden als generieke
      versleutelingsbibliotheek.</para>

    <note>
      <para>Hoewel <application>OpenSSL</application> ondersteuning
	biedt voor het <acronym>IDEA</acronym> algoritme, is dat
	standaard uitgeschakeld in verband met patenten in de VS.  Om
	het te gebruiken dient de licentie gelezen te worden en, als
	de restricties aanvaardbaar zijn, dient de make variabele
	<makevar>MAKE_IDEA</makevar> ingesteld te worden in
	<filename>make.conf</filename>.</para>
    </note>

    <para>Een van de meest gebruikte toepassingen van
      <application>OpenSSL</application> is het leveren van
      certificaten voor gebruik met softwaretoepassingen.  Deze
      certificaten verzekeren dat de eigenschappen van een bedrijf
      of individu geldig zijn en niet vervalst.  Als het certificaat
      in kwestie niet geldig verklaard is door een van de
      <quote>Certificate Authorities</quote> of
      <acronym>CA</acronym>'s, dan komt er een waarschuwing.  Een
      Certificate Authority is een bedrijf, zoals <ulink
	url="http://www.verisign.com">VeriSign</ulink>, dat
      certificaten ondertekent zodat de eigenschappen van een bedrijf
      of individu geldig verklaard kunnen worden.  Dit proces kost geld
      en het is zeker geen voorwaarde voor het gebruik van
      certificaten.  Het stelt wel de meer parano&iuml;de gebruikers
      gerust.</para>

    <sect2>
      <title>Certificaten maken</title>

      <indexterm>
	<primary>OpenSSL</primary>

	<secondary>certificaten maken</secondary>
      </indexterm>

      <para>Voor het maken van certificaten is het volgende commando
	beschikbaar:</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 '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:<userinput><replaceable>US</replaceable></userinput>
State or Province Name (full name) [Some-State]:<userinput><replaceable>PA</replaceable></userinput>
Locality Name (eg, city) []:<userinput><replaceable>Pittsburgh</replaceable></userinput>
Organization Name (eg, company) [Internet Widgits Pty Ltd]:<userinput><replaceable>My Company</replaceable></userinput>
Organizational Unit Name (eg, section) []:<userinput><replaceable>Systems Administrator</replaceable></userinput>
Common Name (eg, YOUR name) []:<userinput><replaceable>localhost.example.org</replaceable></userinput>
Email Address []:<userinput><replaceable>trhodes@FreeBSD.org</replaceable></userinput>

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<userinput><replaceable>SOME PASSWORD</replaceable></userinput>
An optional company name []:<userinput><replaceable>Another Name</replaceable></userinput></screen>

      <para>Let op dat het antwoord direct na <quote>Common
	  Name</quote> een domeinnaam weergeeft.  De prompt wil
	dat er een servernaam wordt ingegeven voor het
	verificatieproces.  Het plaatsen van iets anders dan een
	domeinnaam zorgt ervoor dat het certificaat waardeloos wordt.
	Er zijn ook andere opties als verloopdatum, andere
	versleutelingsalgoritmen, etc, beschikbaar.  Een volledige
	lijst is na te lezen in de handboekpagina van
	&man.openssl.1;.</para>

      <para>Er horen nu twee bestanden te staan in de map waarin het
	voorgaande commando is uitgevoerd.  Het certificaatverzoek,
	<filename>req.pem</filename>, kan naar een certificate
	authority gestuurd worden die de bijgevoegde gegevens kan
	valideren, het verzoek kan tekenen en het certificaat kan
	retourneren.  Het tweede bestand heet
	<filename>cert.pem</filename> en is de geheime sleutel voor het
	certificaat.  Deze dient zorgvuldig beschermd te worden.  Als
	de geheime sleutel in de handen van anderen valt kan die
	gebruikt worden om de identiteit van de eigenaar (of server)
	aan te nemen.</para> 

      <para>In gevallen waar ondertekening door een
	<acronym>CA</acronym> niet vereist is, kan een zelfondertekend
	certificaat gemaakt worden.  Maak als eerste de
	<acronym>RSA</acronym> sleutel:</para>

      <screen>&prompt.root; <userinput>openssl dsaparam -rand -genkey -out <filename>myRSA.key</filename> 1024</userinput></screen>

      <para>Hierna kan de <acronym>CA</acronym> sleutel gemaakt
	worden:</para>

      <screen>&prompt.root; <userinput>openssl gendsa -des3 -out <filename>myca.key</filename> <filename>myRSA.key</filename></userinput></screen>

      <para>Deze sleutel kan gebruikt worden om een certificaat te
	maken:</para>

      <screen>&prompt.root; <userinput>openssl req -new -x509 -days 365 -key <filename>myca.key</filename> -out <filename>new.crt</filename></userinput></screen>

      <para>Er zouden nu twee bestanden bijgekomen moeten zijn in de
	map: een certificate authority ondertekeningsbestand
	<filename>myca.key</filename> en <filename>new.crt</filename>,
	het certificaat zelf.  Deze moeten in een map geplaatst worden,
	bij voorkeur onder <filename class="directory">/etc</filename>
	waar alleen <username>root</username> kan lezen.  De rechten
	0700 zijn hier prima en die kunnen ingesteld worden met
	<command>chmod</command>.</para>
    </sect2>

    <sect2>
      <title>Certificaten gebruiken: een voorbeeld</title>

      <para>En wat kunnen deze bestanden?  Een prima toepassing zou
	het versleutelen van verbindingen naar de
	<application>Sendmail</application> <acronym>MTA</acronym>
	kunnen zijn.  Daardoor zouden gebruikers niet langer platte
	tekst hoeven te authenticeren om mail te sturen via de lokale
	<acronym>MTA</acronym>.</para>

      <note>
	<para>Dit is niet de best denkbare toepassing omdat sommige
	  <acronym>MUA</acronym>'s de gebruiker een foutmelding geven
	  als ze het certificaat niet lokaal ge&iuml;nstalleerd hebben.
	  De documentatie bij de software geeft meer informatie over
	  het installeren van certificaten.</para>
      </note>

      <para>De volgende regels moeten opgenomen worden in het lokale
	<filename>.mc</filename> bestand:</para>

      <programlisting>dnl SSL Options
define(`confCACERT_PATH',`/etc/certs')dnl
define(`confCACERT',`/etc/certs/new.crt')dnl
define(`confSERVER_CERT',`/etc/certs/new.crt')dnl
define(`confSERVER_KEY',`/etc/certs/myca.key')dnl
define(`confTLS_SRV_OPTIONS', `V')dnl</programlisting>

      <para><filename class="directory">/etc/certs/</filename> is de
	map die gebruikt wordt voor het lokaal opslaan van certificaten
	en sleutels.  De laatste voorwaarde het is opnieuw aanmaken van
	het lokale <filename>.cf</filename> bestand.  Dit gaat door
	eenvoudigweg <quote><command>make</command><
	<parameter>install</parameter></quote> te typen in de map
	<filename class="directory">/etc/mail</filename>.  Laat dat
	volgen door een <quote><command>make</command>
	<parameter>restart</parameter></quote> waardoor de
	<application>Sendmail</application> daemon herstart zou moeten
	worden.</para>

      <para>Als alles goed is gegaan, dan staan er geen foutmeldingen
	<filename>/var/log/maillog</filename> en is
	<application>Sendmail</application> zichtbaar in de
	proceslijst.</para>

      <para>Maak als eenvoudige test een verbinding met de mailserver
	met &man.telnet.1;:</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>Als de regel <quote>STARTTLS</quote> verschijnt in de
	uitvoer dan werkt alles correct.</para>
  </sect1>

  <sect1 id="ipsec">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Nik</firstname>
	  <surname>Clayton</surname>
	  <affiliation>
	    <address><email>nik@FreeBSD.org</email></address>
	  </affiliation>
	  <contrib>Gerschreven door </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Siebrand</firstname>
	  <surname>Mazeland</surname>
	  <contrib>Vertaald door </contrib>
	</author>
      </authorgroup>
    </sect1info>

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

    <title>VPN via IPsec</title>

    <para>Een VPN opzetten met &os; gateways tussen twee netwerken die
      gescheiden zijn door internet.</para>

    <sect2>
      <sect2info>
	<authorgroup>
	  <author>
	    <firstname>Hiten M.</firstname>
	    <surname>Pandya</surname>
	    <affiliation>
	      <address><email>hmp@FreeBSD.org</email></address>
	    </affiliation>
	    <contrib>Geschreven door </contrib>
	  </author>
	</authorgroup>
	<authorgroup>
	  <author>
	    <firstname>Siebrand</firstname>
	    <surname>Mazeland</surname>
	    <contrib>Vertaald door </contrib>
	  </author>
	</authorgroup>
      </sect2info>

      <title>IPsec begrijpen</title>

      <para>Deze paragraaf is een gids in het proces van het opzetten,
	en gebruiken van IPsec en het veilig laten communiceren van
	machines in een omgeving die bestaat uit &os; en
	<application>&microsoft.windows; 2000/XP</application>.
	Voordat IPsec opgezet kan worden dient de lezer bekend te zijn
	met de concepten die nodig zijn om een aangepaste kernel te
	bouwen (zie <xref linkend="kernelconfig">).</para>

      <para><emphasis>IPsec</emphasis> is een protocol dat bovenop de
	Internet Protocol (IP) laag ligt.  Hiermee kunnen twee of meer
	host op een veilige manier communiceren (vandaar de naam).  De
	&os; IPsec <quote>netwerk wachtrij (stack)</quote> is gebaseerd
	op de <ulink url="http://www.kame.net/">KAME</ulink>
	implementatie, die zowel de IPv4 als de IPv6 protocolfamilies
	ondersteunt.</para>

      <note>
	<para>&os;&nbsp;5.X bevat een door <quote>hardware
	  geaccelereerde</quote> IPsec wachtrij die <quote>Fast
	  IPsec</quote> heet en uit OpenBSD komt.  Die kan gebruik
	  maken van cryptografische hardware (waar mogelijk) via het
	  &man.crypto.4; subsysteem om de prestaties van IPsec te
	  optimaliseren.  Dit subsysteem is nieuw en ondersteunt niet
	  alle opties die beschikbaar zijn in de KAME versie van
	  IPsec.  Voordat er gebruik gemaakt kan worden van door
	  hardware versnelde IPsec, moet de volgende optie in het
	  kernelinstellingenbestand worden gezet:</para>

	<indexterm>
	  <primary>kernelopties</primary>

	  <secondary>FAST_IPSEC</secondary>
	</indexterm>

	<screen>options          FAST_IPSEC  # new IPsec (cannot define w/ IPSEC)</screen>

	<para>Het is op dit moment niet mogelijk om het
	  <quote>Fast IPsec</quote> subsysteem samen met de
	  KAME-implementatie van IPsec te gebruiken.  Zie
	  &man.fast.ipsec.4; voor meer informatie.</para>
      </note>

      <indexterm>
	<primary>IPsec</primary>

	<secondary>ESP</secondary>
      </indexterm>

      <indexterm>
	<primary>IPsec</primary>

	<secondary>AH</secondary>
      </indexterm>

      <para>IPsec bestaat uit twee subprotocollen:</para>

      <itemizedlist>
	<listitem>
	  <para><emphasis>Encapsulated Security Payload
	      (ESP)</emphasis> beschermt de IP pakketdata tegen
	    inmenging door een derde partij door de inhoud te
	    versleutelen met symmetrische
	    versleutelingsalgoritmen (als Blowfish en 3DES).</para>
	</listitem>

	<listitem>
	  <para><emphasis>Authentication Header (AH)</emphasis>
	    beschermt de IP pakketkop tegen inmenging door een derde
	    partij en spoofing door een cryptografische checksum te
	    berekenen en de IP pakketkopvelden te hashen met een
	    veilige hashfunctie.  Hierna wordt een extra kop ingevoegd
	    die de hash bevat zodat de informatie in het pakket
	    geauthenticeerd kan worden.</para>
	</listitem>
      </itemizedlist>

      <para><acronym>ESP</acronym> en <acronym>AH</acronym> kunnen
	samen of apart gebruikt worden, afhankelijk van de
	omgeving.</para>

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

      <indexterm>
	<primary>virtual private network</primary>

	<see>VPN</see>
      </indexterm>

      <indexterm>
	<primary>virtueel privaat netwerk</primary>

	<see>VPN</see>
      </indexterm>

      <para>IPsec kan gebruikt worden om het verkeer tussen twee hosts
	direct te versleutelen (dat heet <emphasis>Transport
	  Mode</emphasis>) of door <quote>virtuele tunnels</quote> te
	bouwen tussen twee subnetten die gebruikt kunnen worden voor
	veilige communicatie tussen twee bedrijfsnetwerken (dat heet
	<emphasis>Tunnel Mode</emphasis>).  De laatste versie staat
	beter bekend als <emphasis>Virtual Private Network
	  (VPN)</emphasis>.  In &man.ipsec.4; staat gedetailleerde
	informatie over het IPsec subsysteem in &os;.</para>

      <para>Voor ondersteuning voor IPsec in de kernel zijn de
	volgende opties nodig in het
	kernelinstellingenbestand:</para>

      <indexterm>
	<primary>kernelopties</primary>

	<secondary>IPSEC</secondary>
      </indexterm>

      <indexterm>
	<primary>kernelopties</primary>

	<secondary>IPSEC_ESP</secondary>
      </indexterm>

      <screen>options   IPSEC        #IP security
options   IPSEC_ESP    #IP security (crypto; define w/ IPSEC)</screen>

      <indexterm>
	<primary>kernelopties</primary>

	<secondary>IPSEC_DEBUG</secondary>
      </indexterm>

      <para>Als er ook fouten in IPsec (debugging) verwijderd moeten
	kunnen worden, dan is de volgende optie ook nodig:</para>

      <screen>options   IPSEC_DEBUG  #debug for IP security</screen>
    </sect2>

    <sect2>
      <title>Het probleem</title>

      <para>Er bestaat geen standaard voor wat een VPN is.  VPN's
	kunnen opgezet worden met behulp van een aantal verschillende
	technologie&euml;n die allemaal hun eigen voor- en nadelen
	hebben.  Dit onderdeel bevat een scenario en de
	strategie&euml;n die gebruikt kunnen worden voor het
	implementeren van een VPN in iedere situatie.</para>
    </sect2>

    <sect2>
      <title>Het scenario: twee netwerken die &eacute;&eacute;n moeten
	lijken en via internet verbonden zijn</title>

      <indexterm>
	<primary>VPN</primary>

	<secondary>maken</secondary>
      </indexterm>

      <para>Dit is het uitgangspunt:</para>

      <itemizedlist>
	<listitem>
	  <para>Er zijn tenminste twee locaties</para>
	</listitem>

	<listitem>
	  <para>Beide locaties gebruiken IP</para>
	</listitem>

	<listitem>
	  <para>Beide locaties hebben een internetverbinding via een
	    gateway waarop &os; draait.</para>
	</listitem>

	<listitem>
	  <para>De gateway op ieder netwerk heeft tenminste
	    &eacute;&eacute;n publiek <acronym>IP</acronym>
	    adres.</para>
	</listitem>

	<listitem>
	  <para>De interne adressen van de twee netwerken mogen
	    publieke of private <acronym>IP</acronym> adressen zijn,
	    dat maakt niet uit.  Er mag NAT draaien op de gateway als
	    dat nodig is.</para>
	</listitem>

	<listitem>
	  <para>De interne <acronym>IP</acronym> adressen van de twee
	    netwerken mogen <emphasis>niet conflicteren</emphasis>.
	    Hoewel dit in theorie mogelijk is een combinatie van VPN en
	    NAT te gebruiken om dit te laten werken, wordt het vast een
	    drama om dit in te stellen.</para>
	</listitem>
      </itemizedlist>

      <para>Als de twee netwerken die met elkaar verbonden moeten
	worden intern dezelfde private <acronym>IP</acronym>
	adresreeksen gebruiken (beiden gebruiken bijvoorbeeld <hostid
	  role="ipaddr">192.168.1.x</hostid>), dan moet een van de
	netwerken hernummerd worden.</para>

      <para>De netwerk topologie zou er zo uit kunnen zien:</para>

      <mediaobject>
	<imageobject>
	  <imagedata fileref="security/ipsec-network" align="center">
	</imageobject>

	<textobject>
<literallayout class="monospaced">Netwerk #1            [ Interne Hosts  ]    Privaat Net, 192.168.1.2-254
                      [   Win9x/NT/2K  ]
                      [      UNIX      ]
                               |
                               |
                        .---[fxp1]---.      Privaat IP, 192.168.1.1
                        |   FreeBSD  |
                        `---[fxp0]---'      Publiek IP, A.B.C.D
                               |
                               |
                      -=-=- Internet -=-=-
                               |
                               |
                        .---[fxp0]---.      Publiek IP, W.X.Y.Z
                        |   FreeBSD  |
                        `---[fxp1]---'      Privaat IP, 192.168.2.1
                               |
                               |
Netwerk #2            [ Internal Hosts ]
                      [   Win9x/NT/2K  ]    Privaat Net, 192.168.2.2-254
                      [      UNIX      ]</literallayout>
	</textobject>
      </mediaobject>

      <para>Let op de twee publieke <acronym>IP</acronym> adressen.
	In de rest van dit onderdeel worden de letters gebruikt
	om ze aan te duiden.  Overal waar die letters staan, kunnen ze
	vervangen worden door eigen publieke <acronym>IP</acronym>
	adressen.  Zo hebben ook de twee gateway machines intern .1
	<acronym>IP</acronym> adressen en de twee netwerken hebben
	andere <acronym>IP</acronym> adressen (respectievelijk <hostid
	  role="ipaddr">192.168.1.x</hostid> en <hostid
	  role="ipaddr">192.168.2.x</hostid>).  Alle machines op de
	private netwerken zijn zo ingesteld dat ze de <hostid
	  role="ipaddr">.1</hostid> machine als hun standaard gateway
	gebruiken.</para>

      <para>Het is de bedoeling dat, vanuit het netwerkstandpunt, ieder
	netwerk de machines in het andere netwerk kan zien alsof ze
	beiden aan dezelfde router zouden zitten; wel een router die
	een beetje langzaam is en af een toe een pakketje laat
	vallen.</para>

      <para>Dit betekent dat (bijvoorbeeld) op machine <hostid
	  role="ipaddr">192.168.1.20</hostid>:</para>

      <programlisting>ping 192.168.2.34</programlisting>

      <para>uitgevoerd kan worden en dat werkt, transparant.
	&microsoft.windows; machines moeten het andere netwerk kunnen
	zien, gedeelde bestanden kunnen benaderen, enzovoort, op
	dezelfde manier als ze dat kunnen op het lokale netwerk.</para>

      <para>En dat alles moet veilig zijn.  Dat betekent dat verkeer
	tussen de twee netwerken versleuteld moet zijn.</para>

      <para>Het opzetten van een VPN tussen twee netwerken is een
	proces dat uit meerdere stappen bestaat:</para>

      <orderedlist>
	<listitem>
	  <para>Het maken van een <quote>virtuele</quote>
	    netwerkverbinding tussen de twee netwerken over het
	    internet.  Testen met gereedschappen als &man.ping.8; om te
	    bevestigen dat het werkt.</para>
	</listitem>

	<listitem>
	  <para>Het instellen van beveiligingsbeleid om te verzekeren
	    dat het verkeer tussen de twee netwerken transparant wordt
	    versleuteld en ontsleuteld wanneer dat nodig is.  Testen
	    met gereedschappen als &man.tcpdump.1; om te bevestigen dat
	    het werkt.</para>
	</listitem>

	<listitem>
	  <para>Additionele software instellen op de &os; gateways om
	    &microsoft.windows; machines de andere kant van het VPN te
	    laten zien.</para>
	</listitem>
      </orderedlist>

      <sect3>
	<title>Stap 1: de <quote>virtuele</quote> netwerkverbinding
	  maken en testen</title>

	<para>Stel dat een gebruiker is aangemeld op de gatewaymachine
	  in netwerk #1 (met publiek <acronym>IP</acronym> adres
	  <hostid role="ipaddr">A.B.C.D</hostid> en privaat
	  <acronym>IP</acronym> adres <hostid
	    role="ipaddr">192.168.1.1</hostid>) en de voert
	  <command>ping 192.168.2.1</command> uit, naar het private
	  adres van de machine met <acronym>IP</acronym> adres <hostid
	    role="ipaddr">W.X.Y.Z</hostid>.  Wat moet er gebeuren om
	  dat te laten werken?</para>

	<orderedlist>
	  <listitem>
	    <para>De gateway host moet weten hoe hij <hostid
		role="ipaddr">192.168.2.1</hostid> kan bereiken.  Met
	      andere woorden: hij moet een route hebben naar <hostid
		role="ipaddr">192.168.2.1</hostid>.</para>
	  </listitem>

	  <listitem>
	    <para>Private <acronym>IP</acronym> adressen als de reeks
	      <hostid role="ipaddr">192.168.x</hostid> horen in het
	      algemeen niet thuis op internet.  Ieder pakket naar
	      <hostid role="ipaddr">192.168.2.1</hostid> moet dus
	      ingepakt worden in een ander pakket.  Dit pakket moet
	      afkomstig lijken van <hostid
		role="ipaddr">A.B.C.D</hostid> en moet naar
	      <hostid role="ipaddr">W.X.Y.Z</hostid> verstuurd worden.
	      Dit proces heet <firstterm>inkapseling
		(encapsulation)</firstterm>.</para>
	  </listitem>

	  <listitem>
	    <para>Als dit pakket aankomt bij <hostid
		role="ipaddr">W.X.Y.Z</hostid> dan moet het
	      <quote>uitgekapseld (unencapsulated)</quote> worden en
	      afgeleverd worden aan <hostid
		role="ipaddr">192.168.2.1</hostid>.</para>
	  </listitem>
	</orderedlist>

	<para>Dit is alsof er een <quote>tunnel</quote> moet bestaan
	  tussen de twee netwerken.  De twee
	  <quote>tunnelopeningen</quote> zijn de <acronym>IP</acronym>
	  adressen <hostid role="ipaddr">A.B.C.D</hostid> en
	  <hostid role="ipaddr">W.X.Y.Z</hostid> en de tunnel moet op de
	  hoogte zijn van de private <acronym>IP</acronym> adressen die
	  door de tunnel mogen.  De tunnel wordt gebruikt om verkeer
	  met private <acronym>IP</acronym> adressen over het internet
	  te leiden.</para>

	<para>Deze tunnel wordt gemaakt door gebruik te maken van de
	  generieke interface of <devicename>gif</devicename> apparaten
	  op &os;.  De <devicename>gif</devicename> interface moet op
	  iedere gatewaymachine ingesteld zijn met vier
	  <acronym>IP</acronym> adressen: twee voor de publieke
	  <acronym>IP</acronym> adressen en twee voor de private
	  <acronym>IP</acronym> adressen.</para>

	<para>Ondersteuning voor het <devicename>gif</devicename>
	  apparaat moet in de &os; kernel van beide machine
	  gecompileerd worden.  Dit kan door de volgende optie toe te
	  voegen aan de kernelinstellingenbestanden op beide machines,
	  dan de kernel te compileren, te installeren en dan gewoon te
	  herstarten:</para>

	<programlisting>device gif</programlisting>

	<para>Het instellen van de tunnel gaat in twee stappen.  Eerst
	  moet de tunnel verteld worden wat de <acronym>IP</acronym>
	  adressen aan de buitenkant (publiek) zijn met
	  &man.gifconfig.8;.  Daarna moeten de private
	  <acronym>IP</acronym> adressen ingesteld worden met
	  &man.ifconfig.8;.</para>

	<note>
	  <para>In &os;&nbsp;5.X is de functionaliteit van &man.gifconfig.8;
	    opgenomen in &man.ifconfig.8;.</para>
	</note>

	<para>Op de gatewaymachine op netwerk #1 moeten de volgende
	  commando's uitgevoerd worden om te tunnel in te
	  stellen.</para>

	<programlisting>gifconfig gif0 A.B.C.D W.X.Y.Z
ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff</programlisting>

	<para>Op de andere gatewaymachine moeten dezelfde commando's
	  uitgevoerd worden met omgedraaide <acronym>IP</acronym>
	  adressen.</para>

	<programlisting>gifconfig gif0 W.X.Y.Z A.B.C.D
ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff</programlisting>

	<para>Daarna toont:</para>

	<programlisting>gifconfig gif0</programlisting>

	<para>de instellingen.  Op netwerk #1 zou dat het volgende
	  zijn:</para>

	<screen>&prompt.root; <userinput>gifconfig gif0</userinput>
gif0: flags=8011&lt;UP,POINTTOPOINT,MULTICAST&gt; mtu 1280
inet 192.168.1.1 --&gt; 192.168.2.1 netmask 0xffffffff
physical address inet A.B.C.D --&gt; W.X.Y.Z</screen>

	<para>Er is nu een tunnel gemaakt tussen de fysieke adressen
	  <hostid role="ipaddr">A.B.C.D</hostid> en
	  <hostid role="ipaddr">W.X.Y.Z</hostid> en het verkeer dat
	  door de tunnel mag is dat tussen <hostid
	    role="ipaddr">192.168.1.1</hostid> en
	  <hostid role="ipaddr">192.168.2.1</hostid>.</para>

	<para>Hiermee is ook een regel gemaakt in de routetabel op
	  beide machines die te bekijken zijn met <command>netstat
	    -rn</command>.  Deze uitvoer komt van de gatewayhost op
	  netwerk #1.</para>

	<screen>&prompt.root; <userinput>netstat -rn</userinput>
Routing tables

Internet:
Destination      Gateway       Flags    Refs    Use    Netif  Expire
...
192.168.2.1      192.168.1.1   UH        0        0    gif0
...</screen>

	<para>De <quote>Flags</quote> waarde geeft aan dat dit een
	  hostroute is, wat betekent dat iedere gateway weet hoe hij de
	  andere gateway kan bereiken, maar dat ze niet weten hoe ze
	  bij de rest van elkaars netwerk kunnen komen.  Dat probleem
	  wordt snel opgelost.</para>

	<para>Het is waarschijnlijk dat op beide machines een firewall
	  draait.  Die moet omzeild worden voor VPN verkeer.  Het is
	  mogelijk al het verkeer tussen de beide netwerken toestaan of
	  firewallregels toe te voegen waarmee de beide netwerken die
	  het VPN met elkaar verbindt tegen elkaar beschermd
	  worden.</para>

	<para>Het testen wordt een stuk eenvoudiger als de firewall zo
	  is ingesteld dat al het verkeer door het VPN wordt
	  doorgelaten.  Laten kunnen nog restricties toegevoegd worden.
	  Met &man.ipfw.8; wordt met</para>

	<programlisting>ipfw add 1 allow ip from any to any via gif0</programlisting>

	<para>al het verkeer tussen de twee eindstations van het VPN
	  toegestaan zonder dat dit de andere regels van de firewall
	  be&iuml;nvloedt.  Dit commando moet natuurlijk wel op beide
	  gatewayhosts uitgevoerd worden.</para>

	<para>Deze instelling is toereikend om elke gateway machine het
	  recht te geven de ander te pingen.  Op <hostid
	    role="ipaddr">192.168.1.1</hostid> kan nu:</para>

	<programlisting>ping 192.168.2.1</programlisting>

	<para>gedraaid worden en moet een antwoord komen.  Op de andere
	  machine kan dezelfde test gedaan worden.</para>

	<para>Maar nu zijn de andere machines op het interne netwerk
	  nog niet te bereiken.  Dat komt door de routering: hoewel de
	  gateway machines elkaar nu weten te vinden, weten ze nog niet
	  hoe ze het netwerk achter elkaar kunnen bereiken.</para>

	<para>Om dat probleem op te lossen moet een statische route
	  worden toevoegd op iedere gateway machine.  Het commando
	  daarvoor is:</para>

	<programlisting>route add 192.168.2.0 192.168.2.1 netmask 0xffffff00</programlisting>

	<para>Dit betekent: <quote>om hosts op het netwerk <hostid
	    role="ipaddr">192.168.2.0</hostid> te bereiken moeten
	  pakketten naar de host <hostid
	    role="ipaddr">192.168.2.1</hostid> sturen</quote>.  Een
	  zelfde dient op de andere gateway uitgevoerd te worden, maar
	  dan met de <hostid role="ipaddr">192.168.1.x</hostid>
	  adressen.</para>

	<para>IP verkeer van hosts op het ene netwerk kan nu hosts op
	  het andere netwerk bereiken.</para>

	<para>Hiermee is tweederde van het VPN tussen twee netwerken
	  aangelegd in de zin dat het <quote>virtueel</quote> is en er een
	  <quote>netwerk</quote> is.  Maar het is nog niet privaat.
	  Dit wordt aangetoond met &man.ping.8; en &man.tcpdump.1;.
	  Voer op de gateway host het volgende commando uit:/para>

	<programlisting>tcpdump dst host 192.168.2.1</programlisting>

	<para>Voer vanuit een andere sessie op de host het onderstaande
	  commando uit:</para>

	<programlisting>ping 192.168.2.1</programlisting>

	<para>De uitvoer is ongeveer als volgt:</para>

	<programlisting>16:10:24.018080 192.168.1.1 &gt; 192.168.2.1: icmp: echo request
16:10:24.018109 192.168.1.1 &gt; 192.168.2.1: icmp: echo reply
16:10:25.018814 192.168.1.1 &gt; 192.168.2.1: icmp: echo request
16:10:25.018847 192.168.1.1 &gt; 192.168.2.1: icmp: echo reply
16:10:26.028896 192.168.1.1 &gt; 192.168.2.1: icmp: echo request
16:10:26.029112 192.168.1.1 &gt; 192.168.2.1: icmp: echo reply</programlisting>

	<para>Het is zichtbaar dat de ICMP berichten niet versleuteld
	  heen en weer gaan.  Als met &man.tcpdump.1; de parameter
	  <option>-s</option> was gebruikt om meer bytes te tonen uit
	  de pakketten, dan was meer informatie te zien geweest.</para>

	<para>Dit is natuurlijk onacceptabel.  In de volgende paragraaf
	  gaat het dan ook over het beveiligen van de verbinding tussen
	  de twee netwerken zodat al het verkeer automatisch wordt
	  versleuteld.</para>

	<itemizedlist>
	  <title>Samenvatting:</title>

	  <listitem>
	    <para>Stel voor beide kernels het <quote>pseudo-device
	      gif</quote> in.</para>
	  </listitem>

	  <listitem>
	    <para>Wijzig <filename>/etc/rc.conf</filename> op gateway
	      host #1 en voeg de volgende regels toe (wijzig
	      <acronym>IP</acronym> adressen naar wens).</para>

	    <programlisting>gifconfig_gif0="A.B.C.D W.X.Y.Z"
ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff"
static_routes="vpn"
route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00"</programlisting>
	  </listitem>

	  <listitem>
	    <para>Wijzig het firewallscript
	      (<filename>/etc/rc.firewall</filename> of iets dergelijks)
	      op beide hosts en voeg het volgende toe:</para>

	    <programlisting>ipfw add 1 allow ip from any to any via gif0</programlisting>
	  </listitem>

	  <listitem>
	    <para>Maak gelijksoortige wijzigingen in
	      <filename>/etc/rc.conf</filename> op gateway host #2 en
	      draai de volgorde van de <acronym>IP</acronym> adressen
	      om.</para>
	  </listitem>
	</itemizedlist>
      </sect3>

      <sect3>
	<title>Stap 2: de verbinding beveiligen</title>

	<para>Om de verbinding te beveiligen wordt IPsec gebruikt.
	  IPsec biedt een mechanisme waarmee twee hosts samen een
	  sleutel hebben en die sleutel dan gebruiken om gegevens te
	  versleutelen tussen die twee hosts.</para>

	<para>Hiervoor moet op twee plaatsen een aanpassing gemaakt
	  worden in de instellingen.</para>

	<orderedlist>
	  <listitem>
	    <para>Er moet een mechanisme zijn voor de twee hosts om het
	      eens te worden over het versleutelingsmechanisme dat
	      gebruikt gaat worden.  Als de twee hosts het daar over
	      eens zijn, dan hebben ze een zogenaamde
	      <quote>beveiligingssamenwerking (security
		association)</quote>.</para>
	  </listitem>

	  <listitem>
	    <para>Er moet een mechanisme zijn waarmee wordt aangegeven
	      welk verkeer versleuteld moet worden.  Tenslotte moet
	      niet al het uitgaande verkeer versleuteld worden, maar
	      alleen het verkeer dat onderdeel is van het VPN.  De
	      regels die worden opgesteld om te bepalen welke verkeer
	      versleuteld wordt heten <quote>beveiligingsbeleid
		(security policies)</quote>.</para>
	  </listitem>
	</orderedlist>

	<para>Beveiligingssamenwerking en beveiligingsbeleid worden
	  beiden onderhouden door de kernel en kunnen aangepast worden
	  met programma's in userland.  Maar voor dit mogelijk is, moet
	  de kernel geschikt gemaakt worden voor ondersteuning van IPsec
	  en het Encapsulated Security Payload (ESP) protocol.  Dit kan
	  door de volgende regel op te nemen in het
	  kernelinstellingenbestand:</para>

	<indexterm>
	  <primary>kernel options</primary>

	  <secondary>IPSEC</secondary>
	</indexterm>

	<programlisting>options IPSEC
options IPSEC_ESP</programlisting>

	<para>Daarna dienen hercompilatie en installatie van de kernel
	  plaats te vinden en moet de machine gereboot worden.  Dit
	  moet voor beide gateway hosts uitgevoerd worden.</para>

	<indexterm><primary>IKE</primary></indexterm>

	<para>Het is mogelijk twee wegen te bewandelen voor het
	  opzetten van beveiligingssamenwerking.  Als het met de hand
	  wordt opgezet dan moeten een versleutelingsalgoritme,
	  coderingssleutels, enzovoort gekozen worden.   Er kan ook een
	  daemons gebruikt worden die het Internet Key Exchange
	  protocol (IKE) implementeert om dit uit te voeren.</para>

	<para>Het advies is voor het laatste te kiezen.  Los van andere
	  overwegingen is het makkelijker in te stellen.</para>

	<indexterm>
	  <primary>IPsec</primary>

	  <secondary>security policies</secondary>
	</indexterm>

	<indexterm><primary><command>setkey</command></primary></indexterm>

	<para>Voor het wijzigen en weergeven van het beveiligingsbeleid
	  is er &man.setkey.8;.  Ter vergelijking:
	  <command>setkey</command> is voor het beveiligingsbeleid van
	  de kernel wat &man.route.8; is voor de routetabellen van de
	  kernel.  <command>setkey</command> kan ook de huidige
	  beveiligingssamenwerkingen weergeven en om de vergelijking
	  door te zetten is het in die zin verwant aan
	  <command>netstat -r</command>.</para>

	<para>Er zijn een aantal daemons beschikbaar voor het bijhouden
	  van beveiligingssamenwerking in &os;.  In dit artikel wordt
	  beschreven hoe dat met racoon gaat.  racoon zit in de &os;
	  Portscollectie in de security/ categorie en kan op de
	  gebruikelijke manier ge&iuml;nstalleerd worden.</para>

	<indexterm><primary>racoon</primary></indexterm>

	<para><filename role="package">security/racoon</filename> moet
	  draaien op beide gateway hosts.  Op iedere host moet het
	  <acronym>IP</acronym> adres van de andere kant van het VPN
	  ingesteld worden en een geheime sleutel (die door de
	  gebruiker zelf is gekozen en die hetzelfde moet zijn op beide
	  gateways).</para>

	<para>De twee daemons zoeken dan contact met elkaar en stellen
	  vast dat ze zijn wie ze beweren te zijn (door gebruik te
	  maken van de geheime sleutel die is ingesteld).  De daemons
	  maken dan een nieuwe geheime sleutel aan en gebruiken die om
	  het verkeer over het VPN te versleutelen.  Ze wijzigen die
	  sleutel periodiek zodat een aanvaller er niets aan heeft in
	  het geval hij achter een van de sleutels zou komen.  Dit is
	  theoretisch trouwens vrijwel onuitvoerbaar.  Tegen de tijd
	  dat de sleutel gekraakt is, hebben de twee daemons al een
	  nieuwe gekozen.</para>

	<para>De instellingen van racoon worden opgeslagen in
	  <filename>${PREFIX}/etc/racoon</filename>.  Daar tref staat
	  een instellingenbestand aan dat niet ingrijpend hoeft te
	  wijzigen.  De andere component van de instellingen van racoon
	  die gewijzigd moet worden is de <quote>wederzijds bekende
	  sleutel (pre-shared key)</quote>.</para>

	<para>Standaard verwacht racoon dat die in
	  <filename>${PREFIX}/etc/racoon/psk.txt</filename> staat.  Het
	  is belangrijk op te merken dat de wederzijds bekende sleutel
	  <emphasis>niet</emphasis> de sleutel is die gebruikt wordt om
	  het verkeer van de VPN verbinding te versleutelen.  Het is
	  gewoon een token die de sleutelbeheerdaemons in staat stelt
	  elkaar te vertrouwen.</para>

	<para><filename>psk.txt</filename> bevat een regel voor iedere
	  locatie waarmee verbinding bestaat.  In dit voorbeeld zijn er
	  twee locaties en dus bevat ieder <filename>psk.txt</filename>
	  bestand &eacute;&eacute;n regel (omdat de ene kant van de VPN
	  alleen iets te maken heeft met &eacute;&eacute;n andere
	  kant).</para>

	<para>Op gateway host #1 ziet dat er als volgt uit:</para>

	<programlisting>W.X.Y.Z            secret</programlisting>

	<para>Er staat dus het <emphasis>publieke</emphasis>
	  <acronym>IP</acronym> adres van de andere kant, witruimte
	  ;&ndash; spatie(s) of tab(s) &ndash; en een stuk tekst met de
	  geheime sleutel.  Natuurlijk dient <quote>secret</quote> niet
	  als sleutel gebruikt te worden.  Ook hier gelden de normale
	  regels voor wachtwoorden.</para>

	<para>Op gateway host #2 ziet dat er dan zo uit:</para>

	<programlisting>A.B.C.D            secret</programlisting>

	<para>Dus het <emphasis>publieke</emphasis>
	  <acronym>IP</acronym> adres van de andere kant en dezelfde
	  geheime sleutel.  <filename>psk.txt</filename> moet in mode
	  <literal>0600</literal> staan (alleen lees en schrijfrechten
	  voor <username>root</username>) voordat racoon zal
	  werken.</para>

	<para>Racoon moet draaien op beide gatewaymachines.  Er moeten
	  ook een aantal firewallregels toegevoegd worden om IKE
	  verkeer toe te staan, dat over UDP naar de ISAKMP (Internet
	  Security Association Key Management Protocol) poort loopt.
	  Nogmaals: deze regels staan bij voorkeur zo vroeg mogelijk in
	  de firewallregels.</para>

	<programlisting>ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp</programlisting>

	<para>Als racoon eenmaal draait, dan kan de ene gateway host
	  vanaf de andere gepingd worden.  De verbinding is dan nog
	  steeds niet versleuteld, maar racoon stelt wel de
	  beveiligingssamenwerking tussen de twee hosts op.  Dat kan
	  heel even duren en dat uit zich in een kleine vertraging
	  voordat er een antwoord op de ping komt.</para>

	<para>Als de beveiligingssamenwerking tot stand is gekomen,
	  dan kan deze getoond worden met &man.setkey.8;:</para>

	<programlisting>setkey -D</programlisting>

	<para>Het bovenstaande commando toont de
	  beveiligingssamenwerkingsingsinformatie.</para>

	<para>Dat is de ene helft van het probleem.  De andere helft is
	  het instellen van het beveiligingsbeleid.</para>

	<para>Voor er een zinvol beveiligingsbeleid opgesteld kan
	  worden volgt eerst een samenvatting van wat tot nu toe is
	  bereikt.  Het volgende geldt voor beide kanten van de
	  verbinding.</para>

	<para>Ieder IP pakket dat wordt verzonden heeft een kop die
	  gegevens over het pakket bevat.  De kop bevat het
	  <acronym>IP</acronym> adres van zowel de bron als de
	  bestemming.  Zoals bekend horen private
	  <acronym>IP</acronym> adressen zoals de reeks
	  <hostid role="ipaddr">192.168.x.y</hostid> niet thuis op
	  internet.  Ze moeten eerst ingepakt worden in een ander
	  pakket.  Voor dat pakket moeten het publieke bron en
	  bestemmingsadres op de plaats van de private adressen gezet
	  worden.</para>

	<para>Dus als een uitgaand pakket als volgt begon:</para>

	<mediaobject>
	  <imageobject>
	    <imagedata fileref="security/ipsec-out-pkt" align="center">
	  </imageobject>

	  <textobject>
	    <literallayout class="monospaced">
  .----------------------.
  | Src: 192.168.1.1     |
  | Dst: 192.168.2.1     |
  |  &lt;andere kopinfo&gt;    |
  +----------------------+
  | &lt;pakket data&gt;        |
  `----------------------'</literallayout>
	  </textobject>
	</mediaobject>

	<para>Dan wordt het ingepakt in een andere pakket dat er
	  ongeveer als volgt uitziet:</para>

	<mediaobject>
	  <imageobject>
	    <imagedata fileref="security/ipsec-encap-pkt" align="center">
	  </imageobject>

	  <textobject>
	    <literallayout class="monospaced">
  .--------------------------.
  | Src: A.B.C.D             |
  | Dst: W.X.Y.Z             |
  | &lt;andere kop info&gt;        |
  +--------------------------+
  | .----------------------. |
  | | Src: 192.168.1.1     | |
  | | Dst: 192.168.2.1     | |
  | | &lt;andere kop info&gt;    | |
  | +----------------------+ |
  | | &lt;pakket data&gt;        | |
  | `----------------------' |
  `--------------------------'</literallayout>
	  </textobject>
	</mediaobject>

	<para>Het <devicename>gif</devicename> apparaat zorgt voor het
	  inpakken.  Het pakket heeft nu een echt <acronym>IP</acronym>
	  adres aan de buitenkant en het originele pakket zit ingepakt
	  als data in het pakket dat het internet opgestuurd gaat
	  worden.</para>

	<para>Nu moet het verkeer over het VPN natuurlijk versleuteld
	  worden.  Dat kan als volgt worden weergegeven:</para>

	<para><quote>Als een pakket <hostid
	      role="ipaddr">A.B.C.D</hostid> verlaat met als bestemming
	    <hostid role="ipaddr">W.X.Y.Z</hostid>, versleutel het dan
	    met de benodigde beveiligingssamenwerkingen.</quote></para>

	<para><quote>Als een pakket aankomt van <hostid
	      role="ipaddr">W.X.Y.Z</hostid> en het heeft
	    <hostid role="ipaddr">A.B.C.D</hostid> als bestemming,
	    ontcijfer het dan met de benodigde
	    beveiligingssamenwerkingen.</quote></para>

	<para>Dat klopt bijna, maar niet helemaal.  Als dit gebeurde,
	  dan zou al het verkeer van en naar <hostid
	    role="ipaddr">W.X.Y.Z</hostid>, zelfs als dat geen deel
	  uit zou maken van het VPN, versleuteld worden.  Dat is niet
	  wenselijk.  Het correcte beleid ziet er zo uit:</para>

	<para><quote>Als een pakket <hostid
	      role="ipaddr">A.B.C.D</hostid> verlaat en dat pakket
	    bevat een ander pakket en als het <hostid
	      role="ipaddr">W.X.Y.Z</hostid> als bestemming heeft,
	    versleutel het dan met de benodigde
	    beveiligingssamenwerkingen.</quote></para>

	<para><quote>Als een pakket aankomt van <hostid
	      role="ipaddr">W.X.Y.Z</hostid> en het pakket bevat een
	    ander pakket en het heeft <hostid
	      role="ipaddr">A.B.C.D</hostid> als bestemming, ontcijfer
	    het dan met de benodigde
	    beveiligingssamenwerkingen.</quote></para>

	<para>Dat is een subtiele aanpassing, maar wel
	  noodzakelijk.</para>

	<para>Beveiligingsbeleid wordt ook ingesteld met
	  &man.setkey.8;.  &man.setkey.8; biedt een instellingtaal
	  voor het defini&euml;ren van beleid.  Instructies kunnen via
	  STDIN gegeven worden of met de <option>-f</option> optie
	  uit een bestand komen dat de instellingen bevat.</para>

	<para>De instellingen op gateway host #1 (die het publieke
	  <acronym>IP</acronym> adres <hostid
	    role="ipaddr">A.B.C.D</hostid> heeft) om al het uitgaande
	  verkeer naar <hostid role="ipaddr">W.X.Y.Z</hostid> te laten
	  versleutelen is:</para>

	<programlisting>spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;</programlisting>

	<para>Deze commando's kunnen in een bestand (bv.
	  <filename>/etc/ipsec.conf</filename>) gezet worden om
	  uitgevoerd te worden:</para>

	<screen>&prompt.root; <userinput>setkey -f /etc/ipsec.conf</userinput></screen>

	<para><option>spdadd</option> vertelt &man.setkey.8; dat er een
	  regel toegevoegd moet worden aan de database met het
	  beveiligingsbeleid.  De rest van de regel geeft aan op welke
	  pakketten dit beleid van toepassing is.  <hostid
	    role="ipaddr">A.B.C.D/32</hostid> en <hostid
	    role="ipaddr">W.X.Y.Z/32</hostid> zijn de
	  <acronym>IP</acronym> adressen en netmaskers waarmee het
	  netwerk of de hosts worden aangegeven waarop het beleid van
	  toepassing is.  In dit geval is het van toepassing op het
	  verkeer tussen twee hosts.  <option>ipencap</option> vertelt
	  de kernel dat dit beleid alleen van toepassing is op
	  pakketten waarin een ander pakket ingepakt zit.  <option>-P
	    out</option> betekent dat dit beleid van toepassing is op
	  uitgaande pakketten en <option>ipsec</option> betekent dat de
	  pakketten beveiligd moeten worden.</para>

	<para>Het tweede deel geeft aan hoe een pakket versleuteld
	  wordt.  <option>esp</option> is het protocol dat gebruikt
	  moet worden en <option>tunnel</option> geeft aan dat het
	  pakket ingepakt moet worden in een IPsec pakket.  Het
	  herhaalde gebruik van <hostid role="ipaddr">A.B.C.D</hostid>
	  en <hostid role="ipaddr">W.X.Y.Z</hostid> heeft te maken met
	  het aangeven welke beveiligingssamenwerking gebruikt moet
	  worden en als laatste is het door <option>require</option>
	  verplicht dat de pakketten versleuteld worden als deze regel
	  van toepassing is.</para>

	<para>Deze regel is alleen van toepassing op uitgaande
	  pakketten.  Er moet ook nog een regel komen voor inkomende
	  pakketten.</para>

	<programlisting>spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;</programlisting>

	<para>Let wel dat hier dus <option>in</option> staat in plaats
	  van <option>out</option> en dat de <acronym>IP</acronym>
	  adressen zijn omgedraaid.</para>

	<para>Op de andere gateway host (met een publiek
	  <acronym>IP</acronym> adres <hostid
	    role="ipaddr">W.X.Y.Z</hostid>) zijn soortgelijke regels
	  nodig.</para>

	<programlisting>spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;</programlisting>

	<para>Tenslotte moeten de firewalls ESP en IPENCAP pakketten
	  naar beide kanten toestaan.  Deze regels moeten op beide
	  hosts toegevoegd worden.</para>

	<programlisting>ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D</programlisting>

	<para>Omdat deze regels symmetrisch zijn, kunnen ze op beide
	  gateway hosts gebruikt worden.</para>

	<para>Uitgaande pakketten zien er nu ongeveer zo uit:</para>

	<mediaobject>
	  <imageobject>
	    <imagedata fileref="security/ipsec-crypt-pkt" align="center">
	  </imageobject>

	  <textobject>
	    <literallayout class="monospaced">
  .------------------------------.  --------------------------.
  | Src: A.B.C.D                 |                            |
  | Dst: W.X.Y.Z                 |                            |
  | &lt;andere kop info&gt;            |                            |  Versleuteld
  +------------------------------+                            |  pakket.
  | .--------------------------. |  -------------.            |  inhoud
  | | Src: A.B.C.D             | |               |            |  is
  | | Dst: W.X.Y.Z             | |               |            |  volledig
  | | &lt;andere kop info&gt;        | |               |            |- veilig
  | +--------------------------+ |               |  Ingepakt  |  voor
  | | .----------------------. | |  -.           |  pakket    |  snoopen
  | | | Src: 192.168.1.1     | | |   |  Origineel|- met echt  |  door derden
  | | | Dst: 192.168.2.1     | | |   |  pakket,  |  IP adres  |
  | | | &lt;andere kop info&gt;    | | |   |- privaat  |            |
  | | +----------------------+ | |   |  IP adres |            |
  | | | &lt;pakket data&gt;        | | |   |           |            |
  | | `----------------------' | |  -'           |            |
  | `--------------------------' |  -------------'            |
  `------------------------------'  --------------------------'
	    </literallayout>
	  </textobject>
	</mediaobject>

	<para>Als ze ontvangen worden door de andere kant van het VPN
	  dan worden ze eerst ontcijferd (met de
	  beveiligingssamenwerking die door racoon tot stand is
	  gebracht).  Daarna komen ze de <devicename>gif</devicename>
	  interface binnen die de tweede laag uitpakt zodat het
	  binnenste pakket overblijft, dan nu naar het interne netwerk
	  kan reizen.</para>

	<para>De beveiliging kan gecontroleerd worden met dezelfde
	  &man.ping.8; test die eerder is uitgevoerd, door eerst aan
	  te melden op de <hostid role="ipaddr">A.B.C.D</hostid>
	  gateway machine en het onderstaande uit te voeren:</para>

	<programlisting>tcpdump dst host 192.168.2.1</programlisting>

	<para>In nog een sessie op dezelfde host kan dan het volgende
	  commando uitgevoerd worden:</para>

	<programlisting>ping 192.168.2.1</programlisting>

	<para>Nu hoort de volgende uitvoer te zien te zijn:</para>

	<programlisting>XXX tcpdump output</programlisting>

	<para>&man.tcpdump.1; toont nu de ESP pakketten.  Als deze
	  pakketten verder bekeken worden met de optie
	  <option>-s</option> dan is de uitvoer onbegrijpelijk vanwege
	  de versleuteling.</para>

	<para>Gefeliciteerd.  Nu is het VPN tussen de twee locaties
	  opgezet.</para>

	<itemizedlist>
	  <title>Samenvatting</title>

	  <listitem>
	    <para>Stel beide kernels in met:</para>

	    <programlisting>options IPSEC
options IPSEC_ESP</programlisting>
	  </listitem>

	  <listitem>
	    <para>Installeer <filename
	        role="package">security/racoon</filename>.  Wijzig
	      <filename>${PREFIX}/etc/racoon/psk.txt</filename> op
	      beide gateway hosts en voeg een regel toe voor het
	      <acronym>IP</acronym> adres van de host aan de andere
	      kant en een geheime sleutel die aan beide kanten bekend
	      is.  Dit bestand hoort mode 0600 te hebben.</para>
	  </listitem>

	  <listitem>
	    <para>Voeg de volgende regels toe aan
	      <filename>/etc/rc.conf</filename> voor iedere
	      host:</para>

	    <programlisting>ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"</programlisting></listitem>

	  <listitem>
	    <para>Maak <filename>/etc/ipsec.conf</filename> op iedere
	      host die de benodigde spdadd regels bevat.  Op gateway
	      host #1 zou dat zijn:</para>

	    <programlisting>spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec
  esp/tunnel/A.B.C.D-W.X.Y.Z/require;
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec
  esp/tunnel/W.X.Y.Z-A.B.C.D/require;</programlisting>

	    <para>En op gateway host #2 is dat:</para>

<programlisting>spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec
  esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec
  esp/tunnel/A.B.C.D-W.X.Y.Z/require;</programlisting>
	  </listitem>

	  <listitem>
	    <para>Voeg firewallregels toe om IKE, ESP en IPENCAP
	      verkeer toe te staan naar beide hosts:</para>

	    <programlisting>
ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D</programlisting>
	  </listitem>
	</itemizedlist>

	<para>De voorgaande twee stappen zouden voldoende moeten zijn
	  voor het opzetten van het VPN.  Machines op ieder netwerk
	  kunnen elkaar nu bereiken op basis van <acronym>IP</acronym>
	  adressen en al het verkeer over de verbinding wordt
	  automatisch en veilig versleuteld.</para>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="openssh">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Chern</firstname>
	  <surname>Lee</surname>
	  <contrib>Bijgedragen door </contrib>
	</author>
	<!-- 21 April 2001 -->
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Siebrand</firstname>
	  <surname>Mazeland</surname>
	  <contrib>Vertaald door </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>OpenSSH</title>

    <indexterm><primary>OpenSSH</primary></indexterm>

    <indexterm>
      <primary>beveiliging</primary>

      <secondary>OpenSSH</secondary>
    </indexterm>

    <para><application>OpenSSH</application> is een groep
      netwerkverbindingsprogramma's waarmee computers via het netwerk
      veilig benaderd kunnen worden.  Het kan ingezet worden als een
      directe vervanger van <command>rlogin</command>,
      <command>rsh</command>, <command>rcp</command> en
      <command>telnet</command>.  Daarnaast kunnen alle andere
      <acronym>TCP</acronym>/<acronym>IP</acronym> verbindingen veilig
      getunneld of geforward worden door SSH.
      <application>OpenSSH</application> versleutelt al het verkeer om
      afluisteren, het stelen van een verbinding en andere
      netwerkaanvallen effectief te voorkomen.</para>

    <para><application>OpenSSH</application> wordt onderhouden door het
      OpenBSD project en is gebaseerd op SSH v1.2.12 met alle recente
      bugfixes en updates.  Het is compatibel met beide protocollen SSH
      1 en 2.  <application>OpenSSH</application> zit in de
      basisinstallatie sinds &os;&nbsp;4.0.</para>

    <sect2>
      <title>Voordelen van gebruik van OpenSSH</title>

      <para>Als gewoonlijk &man.telnet.1; of &man.rlogin.1; wordt
	gebruikt, wordt de data in platte tekst en niet versleuteld
	verzonden.  Netwerksnuffelaars die ergens tussen de client en
	de server meeluisteren, kunnen een gebruikersnaam en wachtwoord
	stelen en zien welke gegevens er worden overgezonden tijdens
	een sessie.  <application>OpenSSH</application> biedt een
	verscheidenheid aan authenticatie en versleutelingsmethoden
	die het voorgaande voorkomen.</para>
    </sect2>

    <sect2>
      <title><application>sshd</application> inschakelen</title>

      <indexterm>
	<primary>OpenSSH</primary>

	<secondary>inschakelen</secondary>
      </indexterm>

      <para>De <application>sshd</application> daemon wordt onder
	&os;&nbsp;4.X standaard ingeschakeld en bij de installatie van
	&os;&nbsp;5.X en later kan er tijdens de installatie gekozen
	worden.  De daemom is ingeschakeld als de volgende regel
	voorkomt in <filename>rc.conf</filename>:</para>

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

      <para>Hierdoor wordt &man.sshd.8; geladen, het daemonprogramma
	voor <application>OpenSSH</application>, als het systeem de
	volgende keer opstart.  De <application>sshd</application>
	daemon kan ook direct gestart worden door
	<command>sshd</command> in te geven op de commandoregel.</para>
    </sect2>

    <sect2>
      <title>SSH client</title>

      <indexterm>
	<primary>OpenSSH</primary>

	<secondary>client</secondary>
      </indexterm>

      <para>&man.ssh.1; werkt net zoals &man.rlogin.1;.</para>

      <screen>&prompt.root; <userinput>ssh <replaceable>user@example.com</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 'example.com' added to the list of known hosts.
user@example.com's password: <userinput>*******</userinput></screen>

      <para>Het aanmelden gaat nu net zoals het zou gaan als wanneer
	er een sessie gestart zou worden met <command>rlogin</command>
	of <command>telnet</command>.  SSH maakt gebruik van een
	systeem met vingerafdrukken als sleutels voor het vaststellen
	met welke server verbinding wordt gemaakt op het moment
	dat de client verbinding zoekt.  De gebruiker krijgt alleen de
	eerste keer dat verbinding wordt gezocht met de server een
	vraag waarop <literal>yes</literal> geantwoord dient te worden.
	Bij volgende pogingen om aan te melden wordt de
	vingerafdruksleutel vergeleken met de sleutel die is
	opgeslagen.  De SSH client alarmeert de gebruiker als de
	opgeslagen vingerafdruk sleutel anders is dan de sleutel die
	de server meldt.  De vingerafdrukken worden opgeslagen in
	<filename>~/.ssh/known_hosts</filename> of in
	<filename>~/.ssh/known_hosts2</filename> voor SSH v2
	vingerafdrukken.</para>

      <para>Recente <application>OpenSSH</application> servers staan
	standaard ingesteld om alleen SSH v2 connecties toe te staan.
	De client gebruikt versie 2 als dat mogelij is en valt anders
	terug op versie 1.  De client kan ook gedwongen worden om een
	van de twee protocollen te gebruiken door de optie
	<option>-1</option> of <option>-2</option> voor respectievelijk
	versie 1 en versie 2 aan te geven.  De mogelijkheid versie 1 te
	gebruiken blijft in de client bestaan om compatibiliteit met
	oudere versies te behouden.</para>
    </sect2>

    <sect2>
      <title>Veilig kopi&euml;ren</title>

      <indexterm>
	<primary>OpenSSH</primary>

	<secondary>veilig kopi&euml;ren</secondary>
      </indexterm>

      <indexterm><primary><command>scp</command></primary></indexterm>

      <para>Het commando &man.scp.1; (secure copy) werkt gelijk aan
	&man.rcp.1;.  Het kopieert een bestand van of naar een andere
	machine, maar doet dat veilig.</para>

      <screen>&prompt.root; <userinput> scp <replaceable>user@example.com:/COPYRIGHT COPYRIGHT</replaceable></userinput>
user@example.com's password: <userinput>*******</userinput>
COPYRIGHT            100% |*****************************|  4735
00:00
&prompt.root;</screen>

      <para>Omdat de vingerafdruk al is opgeslagen voor deze host in
	het vorige voorbeeld, is die al geverifieerd als &man.scp.1;
	gebruik wordt.</para>

      <para>De argumenten die aan &man.scp.1; gegeven worden zijn
	vrijwel gelijk aan die voor &man.cp.1; met het bestand of
	de bestanden als het eerste argument en de bestemming als het
	tweede.  Omdat het bestand over het netwerk gaat, door SSH,
	hebben een of meer van de bestandsargumenten de vorm
	<option>user@host:&lt;path_to_remote_file&gt;</option>.</para>
    </sect2>

    <sect2>
      <title>Instellen</title>

      <indexterm>
	<primary>OpenSSH</primary>

	<secondary>instellen</secondary>
      </indexterm>

      <para>Het instellingenbestand dat voor het hele systeem geldt
	voor zowel de <application>OpenSSH</application> daemon als
	client staat in de map <filename>/etc/ssh</filename>.</para>

      <para><filename>ssh_config</filename> bevat de instellingen voor
	de client en <filename>sshd_config</filename> bevat ze voor
	de daemon.</para>

      <para>Daarnaast bieden het <option>sshd_program</option>
	(standaard <filename>/usr/sbin/sshd</filename>) en
	<option>sshd_flags</option> <filename>rc.conf</filename>
	opties nog meer mogelijkheden voor instellingen.</para>
    </sect2>

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

      <para>In plaats van het gebruik van wachtwoorden kan
	&man.ssh-keygen.1; gebruikt worden om DSA en RSA sleutels te
	maken om een gebruiker te authenticeren:</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/user/.ssh/id_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com</screen>

      <para>&man.ssh-keygen.1; maakt een publiek en privaat sleutelpaar
	aan dat gebruikt kan worden voor authenticatie.  De private
	sleutel staat opgeslagen in
	<filename>~/.ssh/id_dsa</filename> of
	<filename>~/.ssh/id_rsa</filename> en de publieke sleutel
	staat in <filename>~/.ssh/id_dsa.pub</filename> of
	<filename>~/.ssh/id_rsa.pub</filename> voor respectievelijk DSA
	en RSA sleuteltypen.  De publieke
	sleutel moet in <filename>~/.ssh/authorized_keys</filename>
	van de andere machine staan om dit te laten werken.  RSA versie
	1 publieke sleutels horen ook in
	<filename>~/.ssh/authorized_keys</filename> te staan.</para>

      <para>Nu is het mogelijk een verbinding te maken met een andere
	machine die gebaseerd is op SSH sleutels in plaats van op
	wachtwoorden.</para>

      <para>Als er een wachtwoordzin is gebruikt bij &man.ssh-keygen.1;
	dan wordt de gebruiker iedere keer dat de private sleutel wordt
	gebruikt een wachtwoord gevraagd.  &man.ssh-agent.1; kan het
	ongemak van steeds opnieuw een lange wachtwoordzin moeten
	ingeven verlichten en wordt beschreven in het onderdeel <xref
	  linkend="security-ssh-agent">.</para>

      <warning>
	<para>Afhankelijk van de gebruikte versie van
	  <application>OpenSSH</application> kunnen opties en bestanden
	  verschillen.  Het is verstandig de handboekpagina
	  &man.ssh-keygen.1; te raadplegen.</para>
      </warning>
    </sect2>

    <sect2 id="security-ssh-agent">
      <title>ssh-agent en ssh-add</title>

      <para>De hulpprogramma's &man.ssh-agent.1; en &man.ssh-add.1;
	bieden de mogelijkheid om <application>SSH</application>
	in het geheugen te laden zodat niet iedere keer de
	wachtwoordzin ingegeven hoeft te worden.</para>

      <para>Het hulpprogramma &man.ssh-agent.1; handelt de
	authenticatie af voor de geheime sleutels die erin geladen
	zijn.  &man.ssh-agent.1; wordt gebruikt om andere programma's
	te starten.  Bij eenvoudig gebruik kan er een shell mee
	gestart worden of meer complex een schermbeheerprogramma.<para>

      <para>Voordat &man.ssh-agent.1; in een shell gebruikt kan worden
	dient het eerst gestart te worden met een shell als argument.
	Daarna kan de identiteit toegevoegd worden daar &man.ssh-add.1;
	aan te roepen en de wachtwoordzin voor de geheime sleutel op te
	geven.  Als deze stappen zijn voltooid kan een gebruiker met
	&man.ssh.1; naar iedere host waar de corresponderende publieke
	sleutel is ge&iuml;nstalleerd:</para>

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

      <para>Om &man.ssh-agent.1; te gebruiken in X11 dient er een
	verwijzing naar &man.ssh-agent.1; in
	<filename>~/.xinitrc</filename> te staan.  Dan zijn de diensten
	van &man.ssh-agent.1; beschikbaar voor alle programma's die in
	X11 gestart worden.  Een <filename>~/.xinitrc</filename> zou er
	als volgt uit kunnen zien:</para>

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

      <para>Hiermee wordt &man.ssh-agent.1; gestart die op zijn beurt
	<application>XFCE</application> start, iedere keer dat X11
	start.  Als dat is gebeurd en X11 is herstart zodat de
	wijzigingen actief zijn, dan kan eenvoudigweg &man.ssh-add.1;
	gestart worden om alle beschikbare SSH sleutels te
	laden.</para>
    </sect2>

    <sect2 id="security-ssh-tunneling">
      <title>SSH tunnels</title>

      <indexterm>
	<primary>OpenSSH</primary>

	<secondary>tunnels</secondary>
      </indexterm>

      <para><application>OpenSSH</application> kan een tunnel maken
	waarin een ander protocol ingepakt kan worden zodat er een
	versleutelde sessie ontstaat.</para>

      <para>Het volgende commando geeft &man.ssh.1; aan dat er een
	tunnel voor <application>telnet</application> gemaakt moet
	worden:</para>

      <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5023:localhost:23 user@foo.example.com</replaceable></userinput>
&prompt.user;</screen>

      <para>Aan het <command>ssh</command> commando worden de volgende
	opties meegegeven:</para>

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

	  <listitem>
	    <para>Dit dwingt <command>ssh</command> om versie 2 van het
	      protocol te gebruiken.  Gebruik van deze optie wordt
	      afgeraden als er verbinding wordt gemaakt met oudere SSH
	      servers.</para>
	  </listitem>
	</varlistentry>

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

	  <listitem>
	    <para>Dit geeft aan dat er geen commando volgt, maar dat er
	      een tunnel opgezet moet worden.  Als deze optie niet
	      aanwezig was, zou <command>ssh</command> een normale
	      sessie starten.</para>
	  </listitem>
	</varlistentry>

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

	  <listitem>
	    <para>Dit dwingt <command>ssh</command> om in de
	      achtergrond te draaien.</para>
	  </listitem>
	</varlistentry>

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

	  <listitem>
	    <para>Dit geeft aan dat de lokaal een tunnel wordt gemaakt
	      in de vorm
	      <replaceable>lokale_poort:netwerk_host:netwerk_poort</replaceable>.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>user@foo.example.com</option></term>

	  <listitem>
	    <para>Wijst naar een gebruiker op de SSH server op het
	      netwerk.</para>
	  </listitem>
	</varlistentry>
      </variablelist>

      <para>Een SSH tunnel werkt doordat een luistersocket wordt
	gemaakt op <hostid>localhost</hostid> op de aangegeven poort.
	Die stuurt dan iedere ontvangen verbinding op de lokale
	host/poort via de SSH verbinding door naar de aangegeven host
	en poort op het netwerk.</para>

      <para>In het voorbeeld wordt poort
	<replaceable>5023</replaceable> op <hostid>localhost</hostid>
	doorgestuurd naar poort <replaceable>23</replaceable> op
	<hostid>localhost</hostid> van de machine op het netwerk.
	Omdat <replaceable>23</replaceable>
	<application>telnet</application> is, zou dit een veilige
	<application>telnet</application> verbinding opleveren door
	een SSH tunnel.</para>

      <para>Dit kan gebruikt worden om ieder willekeurig onveilig
	TCP protocol in te pakken als <acronym>SMTP</acronym>,
	<acronym>POP</acronym>3, <acronym>FTP</acronym>, etc.</para>

      <example>
	<title>SSH gebruiken om een veilige tunnel te maken voor
	  SMTP</title>

	<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 user@mailserver.example.com</replaceable></userinput>
user@mailserver.example.com's password: <userinput>*****</userinput>
&prompt.user; <userinput>telnet localhost 5025</userinput>
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTP</screen>

	<para>Dit kan samen met een &man.ssh-keygen.1; en extra
	  gebruikersaccounts gebruikt worden om een min of meer
	  naadloze en eenvoudige SSH tunnelomgeving te maken.  In
	  plaats van wachtwoorden kunnen sleutels gebruikt worden en de
	  tunnels kunnen in de omgeving van een aparte gebruiker
	  draaien.</para>
      </example>

      <sect3>
	<title>Praktische voorbeelden van een SSH tunnel</title>

	<sect4>
	  <title>Veilige toegang tot een POP3 server</title>

	  <para>Op het werk staat een SSH server die verbindingen van
	    buitenaf toestaat.  Op hetzelfde netwerk op kantoor staat
	    een mailserver waarop POP3 draait.  Het netwerk of het
	    netwerkpad tussen de locatie op internet en kantoor is
	    wellicht niet helemaal te vertrouwen.  Om deze reden dient
	    de mailserver op een veilige manier benaderd te worden.  De
	    oplossing is een SSH verbinding opzetten naar de SSH server
	    op kantoor en dan door de tunnel heen een verbinding
	    opzetten met de mailserver.</para>

	  <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>2110:mail.example.com:110 user@ssh-server.example.com</replaceable></userinput>
user@ssh-server.example.com's password: <userinput>******</userinput></screen>

	  <para>Als de tunnel eenmaal draait, dan kan de mailclient
	    naar <hostid>localhost</hostid> poort 2110 gewezen worden.
	    Alle verbinding naar die poort worden veilig doorgestuurd
	    door de tunnel naar
	    <hostid>mail.example.com</hostid>.</para>
	</sect4>

	<sect4>
	  <title>Een draconische firewall omzeilen</title>

	  <para>Sommige netwerkbeheerders stellen draconische
	    firewallregels op en filteren niet alleen inkomende
	    verbindingen, maar ook uitgaande.  Meestal mag dan alleen
	    maar verbinding gemaakt worden met andere machines op
	    poorten 22 en 80 voor SSH en websurfen.</para>

	  <para>Soms wil een gebruiker dan toch toegang krijgen tot
	    andere (wellicht niet netwerk-gerelateerd) diensten, zoals
	    een Ogg Vorbis server om muziek te streamen.  Als die Ogg
	    Vorbis server streamt op een andere poort dan 22 of 80, dan
	    kan deze niet bereikt worden.</para>

	  <para>De oplossing ligt in het opzetten van een SSH
	    verbinding naar een machine buiten de firewall en die
	    tunnel te gebruiken om bij de Ogg Vorbis server te
	    komen.</para>

	  <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>8888:music.example.com:8000 user@unfirewalled-system.example.org</replaceable></userinput>
user@unfirewalled-system.example.org's password: <userinput>*******</userinput></screen>

	  <para>De streamingclient kan nu gewezen worden naar
	    <hostid>localhost</hostid> poort 8888 vanwaar er wordt
	    doorverwezen naar <hostid>music.example.com</hostid> poort
	    8000 en zo wordt de firewall succesvol ontwerken.</para>
	</sect4>
      </sect3>
    </sect2>

    <sect2>
      <title>De gebruikersoptie <varname>AllowUsers</varname></title>

      <para>Vaak is het verstandig om beperkingen aan te brengen op het
	gebied van welke gebruikers kunnen aanmelden en van waar.  De
	optie <literal>AllowUsers</literal> biedt deze mogelijkheid.
	Om bijvoorbeeld alleen <username>root</username> toe te staan
	zich aan te melden van <hostid
	  role="ipaddr">192.168.1.32</hostid>, kan iets als de volgende
	regel worden opgenomen in
	<filename>/etc/ssh/sshd_config</filename> file:</para>

      <programlisting>AllowUsers root@192.168.1.32</programlisting>

      <para>Om de gebruiker <username>admin</username> het recht te
	geven zich van overal aan te melden hoeft alleen de
	gebruikersnaam vermeld te worden:</para>

      <programlisting>AllowUsers admin</programlisting>

      <para>Meerdere gebruikers met rechten of beperkingen horen op
	dezelfde regel te staan:</para>

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

      <note>
	<para>Het is van belang dat iedere gebruiker die zich moet
	  kunnen aanmelden wordt genoemd.  De overige gebruikers
	  worden buitengesloten.</para>
      </note>

      <para>Nadat er wijzigingen zijn gemaakt aan
	<filename>/etc/ssh/sshd_config</filename> dienen de bestanden
	in &man.sshd.8; geladen te worden:</para>

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

    <sect2>
      <title>Meer informatie</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>Bijgedragen door </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Siebrand</firstname>
	  <surname>Mazeland</surname>
	  <contrib>Vertaald door </contrib>
	</author>
      </authorgroup>
    </sect1info>

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

    <title>Bestandssysteem toegangscontrolelijsten</title>

    <para>In combinatie met verbeteringen als snapshots, bieden
      &os;&nbsp;5.0 en volgende versies de veiligheid van
      Bestandssysteem Toegangscontrolelijsten (Access Control Lists,
      <acronym>ACL</acronym>s).</para>

    <para>Met Toegangscontrolelijsten wordt het standaard &unix;
      rechtenmodel uitgebreid op een zeer verenigbare (&posix;.1e)
      manier.  Deze methodes stellen een beheerder in staat om gebruik
      te maken en voordeel te halen uit een geraffineerder
      beveiligingsmodel.</para>

    <para>Om ondersteuning voor <acronym>ACL</acronym>s voor
      bestandssystemen in te schakelen dient het volgende in de kernel
      gecompileerd te worden:</para>

    <programlisting>options UFS_ACL</programlisting>

    <para>Als deze optie niet aanwezig is, dan wordt er een
      waarschuwing weergegeven als er wordt geprobeerd een
      bestandssysteem te mounten dat gebruik maakt van
      <acronym>ACL</acronym>s.  Deze optie is al geactiveerd in de
      <filename>GENERIC</filename> kernel.  <acronym>ACL</acronym>s
      zijn afhankelijk van uitgebreide attributen die zijn ingeschakeld
      op het bestandssysteem.  Uitgebreide attributen worden standaard
      ondersteund in het volgende generatie &unix; bestandssysteem
      <acronym>UFS2</acronym>.</para>

    <note>
      <para>Er is meer administratieve overhead nodig om
	uitgebreide attributen in te stellen op
	<acronym>UFS1</acronym> dan op <acronym>UFS2</acronym>.  De
	prestaties van uitgebreide attributen zijn op
	<acronym>UFS2</acronym> ook veel beter.  Daarom wordt
	<acronym>UFS2</acronym> ook meestal aangeraden boven
	<acronym>UFS1</acronym> bij het gebruik van
	toegangscontrolelijsten.</para>
    </note>

    <para><acronym>ACL</acronym>s worden ingeschakeld door de
      beheersvlag <option>acls</option> op het moment van mounten.  Dit
      kan ook in <filename>/etc/fstab</filename> staan.  De vlag op het
      moment van mounten kan ook automatisch gezet worden op een
      persistente wijze met &man.tunefs.8; door een superblok in de
      bestandssysteemkop te wijzigen.  In het algemeen wordt de
      voorkeur gegeven aan de vlag in het superblok om een aantal
      redenen:</para>

    <itemizedlist>
      <listitem>
	<para>De <acronym>ACL</acronym>s vlag op het moment van mounten
	  kan niet gewijzigd worden bij opnieuw mounten (&man.mount.8;
	  <option>-u</option>), maar alleen door een volledige
	  &man.umount.8; en een verse &man.mount.8;.  Dit betekent dat
	  <acronym>ACL</acronym>s niet ingeschakeld kunnen worden op
	  root bestandssysteem na het booten.  Het betekent ook dat de
	  aard van een bestandssysteem niet veranderd kan worden als
	  het eenmaal in gebruik is.</para>
      </listitem>

      <listitem>
	<para>Het inschakelen van de superblok vlag zorgt ervoor dat
	  het bestandssysteem altijd wordt gemount met de
	  <acronym>ACL</acronym>s ingeschakeld, zelfs als het niet in
	  <filename>fstab</filename> staat of als de apparaten van
	  plaats veranderen.  Hiermee wordt voorkomen dat het
	  bestandssysteem wordt gebruikt zonder dat
	  <acronym>ACL</acronym>s ingeschakeld zijn, wat ervoor zou
	  kunnen zorgen dat <acronym>ACL</acronym>s onjuist worden
	  toegepast wat weer kan zorgen voor
	  beveiligingsproblemen.</para>
      </listitem>
    </itemizedlist>

    <note>
      <para>Wellicht wordt het mogelijk om de
	<acronym>ACL</acronym>s via de vlag in te schakelen zonder een
	compleet verse &man.mount.8;, maar de ontwikkelaars vinden het
	wenselijk om het per ongeluk zonder <acronym>ACL</acronym>s
	mounten te ontmoedigen, omdat er bijzonder vervelende gevolgen
	kunnen zijn als <acronym>ACL</acronym>s worden ingeschakeld,
	daarna worden uitgezet en weer worden ingeschakeld zonder dat
	de uitgebreide attributen worden geschoond.  In het algemeen
	geldt dat als <acronym>ACL</acronym>s eenmaal zijn ingeschakeld
	voor een bestandssysteem, ze niet meer uitgeschakeld moeten
	worden, omdat de resulterende bestandsbescherming wellicht niet
	compatibel is met dat wat gebruikers van het systeem nodig
	hebben en het opnieuw aanzetten van <acronym>ACL</acronym>s kan
	leiden tot het opnieuw koppelen van voorheen bestaande
	<acronym>ACL</acronym>s aan bestanden waarvoor de
	toegangsrechten sindsdien zijn aangepast, wat kan leiden tot
	onverwachte situaties.</para>
    </note>

    <para>Bestandssystemen waarvoor <acronym>ACL</acronym>s zijn
      ingeschakeld worden weergegeven met een <literal>+</literal>
      (plus) teken als de toegangsrechten worden bekeken:</para>

    <programlisting>drwx------  2 robert  robert  512 Dec 27 11:54 private
drwxrwx---+ 2 robert  robert  512 Dec 23 10:57 directory1
drwxrwx---+ 2 robert  robert  512 Dec 22 10:20 directory2
drwxrwx---+ 2 robert  robert  512 Dec 27 11:57 directory3
drwxr-xr-x  2 robert  robert  512 Nov 10 11:54 public_html</programlisting>

    <para>Hierboven is te zien dat mappen
      <filename>directory1</filename>, <filename>directory2</filename>
      en <filename>directory3</filename> allemaal gebruik maken van
      <acronym>ACL</acronym>s.  De map <filename>public_html</filename>
      doet dat niet.</para>

    <sect2>
      <title>Gebruik maken van <acronym>ACL</acronym>s</title>

      <para>De <acronym>ACL</acronym>s van het bestandssysteem kunnen
	bekeken worden met het hulpprogramma &man.getfacl.1;.  Om de
	<acronym>ACL</acronym> op het bestand <filename>test</filename>
	te bekijken zou het volgende commando nodig zijn:</para>

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

      <para>Om de <acronym>ACL</acronym> op dit bestand te wijzigen
	wordt het hulpprogramma &man.setfacl.1; als volgt
	gebruikt:</para>

      <screen>&prompt.user; <userinput>setfacl -k <filename>test</filename></userinput></screen>

      <para>De vlag <option>-k</option> verwijdert alle bestaande
	<acronym>ACL</acronym>s van een bestand of bestandssysteem.  De
	methode die de voorkeur geniet is <option>-b</option> gebruiken
	omdat die optie de basisvelden die nodig zijn voor het laten
	werken van de <acronym>ACL</acronym>s laat staan.</para>

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

      <para>Bij het commando hierboven, werd de optie
	<option>-m</option> gebruikt om de standaard
	<acronym>ACL</acronym> aan te passen.  Omdat er geen
	voorgedefinieerde instellingen waren, die waren verwijderd door
	het commando daarvoor, werden nu de standaardinstellingen
	hersteld en de rechten die werden aangegeven toegevoegd.  Let
	op dat bij het toevoegen van een gebruiker of een groep die
	niet bekend is op het systeem een foutmelding
	<errorname>Invalid argument</errorname> wordt geschreven naar
	<devicename>stdout</devicename>.</para>
    </sect2>
  </sect1>

  <sect1 id="security-portaudit">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Geschreven door </contrib>
	</author>
      </authorgroup>
    </sect1info>

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

    <title>Monitoren van beveiligingsproblemen met andere
      software</title>

    <para>In de afgelopen jaren zijn er in de beveiligingswereld veel
      vorderingen gemaakt op het gebied van inzicht in kwetsbaarheden.
      Als er software naast het besturingssysteem wordt
      ge&iuml;nstalleerd en ingesteld neemt op vrijwel ieder
      besturingssysteem het risico op inbraak toe.</para>

    <para>Inzicht in kwetsbaarheid is een vitale factor in beveiliging
      en hoewel &os; waarschuwingen publiceert voor het basissysteem,
      gaat het publiceren van waarschuwingen voor alle overige software
      de scope van het &os; Project te buiten.  Er is een manier om
      inzicht te krijgen in de kwetsbaarheden voor additionele software
      en als beheerder gewaarschuwd te worden.  Voor dit doel bestaat
      het &os; hulpprogramma
      <application>Portaudit</application>.</para>

    <para>De port <filename role="port">security/portaudit</filename>
      zoekt naar bekende beveiligingsproblemen in een database die
      wordt bijgewerkt en onderhouden door het &os; Security Team en
      portontwikkelaars.</para>

    <para>Voordat <application>Portaudit</application> gebruikt kan
      worden dient het ge&iuml;nstalleerd te worden uit de
      Portscollectie:</para>

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

    <para>Tijdens het installatieproces worden de instellingenbestanden
      voor &man.periodic.8; bijgewerkt, waardoor
      <application>Portaudit</application> uitvoer in de dagelijkse
      security runs meekomt.  Het is van belang dat de e-mails die
      aan de e-mailaccount van <username>root</username> worden
      gezonden en uit de dagelijkse beveiligingsronde komen ook echt
      worden gelezen.  Er zijn geen verdere instellingen nodig.</para>

    <para>Na de installatie dient de beheerder de database bij te
      werken die lokaal staat in <filename
      role="directory">/var/db/portaudit</filename>:</para>

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

    <note>
      <para>De database wordt automatisch bijgewerkt tijdens de
	&man.periodic.8; run; dus het voorgaande commando is volledig
	optioneel.  Het is alleen nodig om de volgende voorbeelden na
	te kunnen doen.</para>
    </note>

    <para>De software de uit de Portscollection is ge&iuml;nstalleerd
      kan door een beheerder geaudit worden met:</para>

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

    <para>Hieronder staat een voorbeeld van de uitvoer:</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>Door met een webbrowser naar de aangegeven
      <acronym>URL</acronym> te gaan kan een beheerder meer informatie
      over de bewust kwetsbaarheid krijgen, waaronder de versies die
      het betreft, volgens de &os; Port versie en andere websites
      waarop beveiligingswaarschuwingen te lezen zijn.</para>

    <para>In het kort is <application>Portaudit</application> een
      krachtig hulpprogramma dat bijzonder handig is als het wordt
      gekoppeld aan het gebruik van de port
      <application>Portupgrade</application>.</para>
  </sect1>

  <sect1 id="security-advisories">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Bijgedragen door </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Siebrand</firstname>
	  <surname>Mazeland</surname>
	  <contrib>Vertaald door </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <indexterm><primary>&os; Beveiligingswaarschuwingen</primary></indexterm>

    <title>&os; beveiligingswaarschuwingen</title>

    <para>Net als veel andere kwalitatief goede
      productiebesturingssystemen publiceert &os;
      <quote>Beveiligingswaarschuwingen</quote>.  Deze waarschuwingen
      worden meestal pas naar de beveiligingslijst gemaild en
      gedocumenteerd in de Errata als de van toepassing zijnde
      releases gepatcht zijn.  In deze paragraaf wordt toegelicht wat
      een waarschuwing is, hoe die te begrijpen en welke maatregelen
      er genomen moeten worden om een systeem bij te werken.</para>

    <sect2>
      <title>Hoe ziet een waarschuwing eruit?</title>

      <para>De &os; beveiligingswaarschuwingen zien er ongeveer uit als
	die hieronder die van de &a.security-notifications.name;
	mailinglijst komt.</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">
&os; only:   NO<co id="co-only">

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>Het veld <literal>Topic</literal> geeft aan wat precies
	    het probleem is.  Het is eigenlijk een inleiding op de
	    beveiligingswaarschuwing en geeft aan welke programma
	    kwetsbaar is.</para>
	</callout>

	<callout arearefs="co-category">
	  <para>Het veld <literal>Category</literal> geeft aan welk
	    onderdeel van het systeem kwetsbaar is.  Dat kan een van de
	    onderdelen <literal>core</literal>,
	    <literal>contrib</literal> of <literal>ports</literal>
	    zijn.  De categorie <literal>core</literal> betekent dat
	    de een kerncomponent van het &os; besturingssysteem
	    kwetsbaar is.  De categorie <literal>contrib</literal>
	    betekent dat software die toegevoegd is aan het &os;
	    Project kwetsbaar is, zoals
	    <application>sendmail</application>.  Tenslotte geeft de
	    categorie <literal>ports</literal> aan dat een optionele
	    component uit de Portscollectie kwetsbaar is.</para>
	</callout>

	<callout arearefs="co-module">
	  <para>Het veld <literal>Module</literal> geeft aan waar de
	    component zich bevindt, bijvoorbeeld
	    <literal>sys</literal>.  In dit voorbeeld wordt het
	    duidelijk dat de module <literal>sys</literal> kwetsbaar
	    is.  Hier gaat het dus om een kwetsbaar component die
	    gebruikt wordt in de kernel.</para>
	</callout>

	<callout arearefs="co-announce">
	  <para>Het veld <literal>Announced</literal> geeft aan wanneer
	    de beveiligingswaarschuwing gepubliceerd of aangekondigd
	    is.  Dit betekent dat het beveiligingsteam heeft bevestigd
	    dat het probleem bestaat en dat er een patch is gecommit in
	    het depot met de broncode van &os;.</para>
	</callout>

	<callout arearefs="co-credit">
	  <para>In het veld <literal>Credits</literal> wordt iemand of
	    een organisatie bedankt die de kwetsbaarheid heeft ontdekt
	    en gerapporteerd.</para>
	</callout>

	<callout arearefs="co-affects">
	  <para>Het veld <literal>Affects</literal> geeft aan welke
	    releases van &os; door deze kwetsbaarheid worden getroffen.
	    Voor de kernel kan snel gekeken worden naar de uitvoer van
	    <command>ident</command> voor de betreffende bestanden om
	    te bepalen welke revisie ze hebben.  Voor ports is het
	    versienummer te zien in <filename>/var/db/pkg</filename>.
	    Als het systeem niet gelijk op loopt met het &os;
	    <acronym>CVS</acronym> depot en dagelijks herbouwd wordt,
	    dan is de kans groot dat het systeem kwetsbaar is.</para>
	</callout>

	<callout arearefs="co-corrected">
	  <para>Het veld <literal>Corrected</literal> geeft de datum,
	    tijd en tijdzone aan en de release die is aangepast.</para>
	</callout>

	<callout arearefs="co-only">
	  <para>Het veld <literal>&os; only</literal> geeft aan of deze
	    kwetsbaarheid alleen betrekking heeft op &os; of dat hij
	    ook betrekking heeft op andere besturingssystemen.</para>
	</callout>

	<callout arearefs="co-backround">
	  <para>Het veld <literal>Background</literal> geeft meer
	    informatie over wat er precies aan de hand is.  Meestal
	    staat hier waarom het programma aanwezig is in &os;, waar
	    het voor gebruikt wordt en hoe het programma is
	    ontstaan.</para>
	</callout>

	<callout arearefs="co-descript">
	  <para>Het veld <literal>Problem Description</literal> geeft
	    gedetailleerde toelichting op het beveiligingsprobleem.
	    Hier kan informatie bij staat over programmacode die
	    fouten bevat of zelfs hoe het programma gebruikt kan worden
	    om een beveiligingsgat te openen.</para>
	</callout>

	<callout arearefs="co-impact">
	  <para>Het veld <literal>Impact</literal> beschrijft welke
	    invloed het probleem kan hebben op het systeem.  Dit kan
	    bijvoorbeeld een ontzegging van dienst aanval zijn,
	    gebruikers extra rechten geven of het verkrijgen van
	    supergebruiker toegang voor de aanvaller zijn.</para>
	</callout>

	<callout arearefs="co-workaround">
	  <para>Het veld <literal>Workaround</literal> geeft aan hoe
	    het mogelijk is het probleem te omzeilen (workaround) in
	    het geval systeembeheerders niet in staat zijn om het
	    systeem bij te werken.  Dit zou te maken kunnen hebben
	    met de tijd, beschikbaarheid van het netwerk en een hele
	    lijst met andere redenen.  Hoe dan ook, beveiliging
	    dient serieus genomen te worden en een systeem dat
	    kwetsbaar is moet bijgewerkt worden of het gat in de
	    beveiliging moet gedicht worden met de alternatieve
	    oplossing.</para>
	</callout>

	<callout arearefs="co-solution">
	  <para>Het veld <literal>Solution</literal> geeft instructies
	    over hoe een systeem aangepast kan worden.  Dit is een
	    werkinstructie die getest en gecontroleerd is om een
	    systeem aan te passen en weer veilig werkend te
	    krijgen.</para>
	</callout>

	<callout arearefs="co-details">
	  <para>In het veld <literal>Correction Details</literal> staan
	    de <acronym>CVS</acronym> takken of releasenamen, met de
	    punten veranderd in een liggend streepje.  Er staat ook
	    welke revisienummer de aangetaste bestanden binnen een tak
	    hebben.</para>
	</callout>

	<callout arearefs="co-ref">
	  <para>In het veld <literal>References</literal> wordt
	    gewoonlijk verwezen naar andere bronnen.  Dit kunnen
	    <acronym>URL</acronym>s, boeken, mailinglijsten en
	    nieuwsgroepen zijn.</para>
	</callout>
      </calloutlist>
    </sect2>
  </sect1>

  <sect1 id="security-accounting">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Geschreven door </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <indexterm><primary>Procesaccounting</primary></indexterm>

    <title>Procesaccounting</title>

    <para>Procesaccounting is een beveiligingsmethode die een beheerder
      in staat stelt om in de gaten te houden welke systeembronnen
      worden gebruikt, hoe ze over gebruikers verdeeld zijn,
      systeemmonitoring biedt en op minimalistische wijze het gebruik
      van commando's door gebruikers volgt.</para>

    <para>Deze methode heeft voordelen en nadelen.  E&eacute;n van de
      positieve punten is dat een inbraak gevolgd kan worden tot het
      moment waarop die zich voordeed.  Nadelen zijn de grootte van de
      logboeken die door procesaccounting worden gegenereerd en de
      schijfruimte die dat kost.  In dit onderdeel wordt een beheerder
      de basis van procesaccounting getoond.</para>

    <sect2>
      <title>Procesaccounting inschakelen en gebruiken</title>

      <para>Voordat procesaccounting gebruikt kan worden dient het te
	worden ingeschakeld met de volgende commando's:</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>Eenmaal ingeschakeld begint accounting met het bijhouden
	van <acronym>CPU</acronym> statistieken, commands, enzovoort.
	Alle accounting logboeken worden in een niet leesbaar formaat
	bijgehouden en zijn uit te lezen met &man.sa.8;.  Bij het
	uitvoeren zonder opties, toont <command>sa</command> informatie
	gerelateerd aan het aantal calls per gebruiker, de totale tijd
	in minuten die is verstreken, de totale <acronym>CPU</acronym>
	en gebruikerstijd in minuten, gemiddeld aantal I/O operaties,
	enzovoort.</para>

      <para>Informatie over uitgevoerde commando's kan bekeken worden
	met &man.lastcomm.1;.  Zo kan met <command>lastcomm</command>
	bijvoorbeeld weergegeven worden welke commando's door
	gebruikers op een specifieke &man.ttys.5; zijn
	uitgevoerd:</para>

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

      <para>Het bovenstaande commando toont ieder bekend gebruikt van
	<command>ls</command> door de gebruiker
	<username>trhodes</username> op terminal ttyp1.</para>

      <para>Veel andere handige opties staan beschreven in
	&man.lastcomm.1;, &man.acct.5; en &man.sa.8;.</para>
    </sect2>
  </sect1>
</chapter>

<!--
     Local Variables:
     mode: sgml
     sgml-declaration: "../chapter.decl"
     sgml-indent-data: t
     sgml-omittag: nil
     sgml-always-quote-attributes: t
     sgml-parent-document: ("../book.sgml" "part" "chapter")
     End:
-->