svn commit: r44410 - translations/nl_NL.ISO8859-1/books/handbook/security
Remko Lodder
remko at FreeBSD.org
Tue Apr 1 20:55:33 UTC 2014
Author: remko
Date: Tue Apr 1 20:55:32 2014
New Revision: 44410
URL: http://svnweb.freebsd.org/changeset/doc/44410
Log:
Update work in progress for the security chapter
Facilitated by: Snow B.V.
Modified:
translations/nl_NL.ISO8859-1/books/handbook/security/chapter.xml
Modified: translations/nl_NL.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- translations/nl_NL.ISO8859-1/books/handbook/security/chapter.xml Tue Apr 1 18:31:33 2014 (r44409)
+++ translations/nl_NL.ISO8859-1/books/handbook/security/chapter.xml Tue Apr 1 20:55:32 2014 (r44410)
@@ -5,16 +5,28 @@
$FreeBSD$
%SOURCE% en_US.ISO8859-1/books/handbook/security/chapter.xml
- %SRCID% 41645
+ %SRCID% 43328
-->
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security">
<info><title>Beveiliging</title>
<authorgroup>
- <author><personname><firstname>Matthew</firstname><surname>Dillon</surname></personname><contrib>Veel uit dit hoofdstuk is overgenomen uit de
- security(7) handleiding van </contrib></author>
+ <author>
+ <personname>
+ <firstname>Matthew</firstname>
+ <surname>Dillon</surname>
+ </personname>
+ <contrib>Veel uit dit hoofdstuk is overgenomen uit de
+ security(7) handleiding van </contrib>
+ </author>
</authorgroup>
<authorgroup>
- <author><personname><firstname>Siebrand</firstname><surname>Mazeland</surname></personname><contrib>Vertaald door </contrib></author>
+ <author>
+ <personname>
+ <firstname>Siebrand</firstname>
+ <surname>Mazeland</surname>
+ </personname>
+ <contrib>Vertaald door </contrib>
+ </author>
</authorgroup>
</info>
@@ -29,29 +41,24 @@
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 en dergelijke 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>
+ systemen en Internet in het algemeen. Het beveiligen van een
+ systeem is onontbeerlijk als gegevens, intellectueel eigendom,
+ tijd en wat dan ook uit de handen van hackers en dergelijke
+ gehouden moeten worden.</para>
+
+ <para>&os; biedt veel hulpmiddelen en mechanismen om de integriteit
+ te borgen en de veiligheid van een systeem en het netwerk.</para>
<para>Na het lezen van dit hoofdstuk weet de lezer:</para>
<itemizedlist>
<listitem>
- <para>Van basis systeembeveiligingsconcepten in relatie tot
- &os;.</para>
+ <para>van Basis systeembeveiligingsconcepten in &os;.</para>
</listitem>
<listitem>
- <para>Meer over verschillende versleutelingsmechanismen die
- beschikbaar zijn in &os; zoals <acronym>DES</acronym> en
- <acronym>MD5</acronym>.</para>
+ <para>Meer over verschillende versleutelingsmechanismen in
+ &os;.</para>
</listitem>
<listitem>
@@ -61,29 +68,27 @@
<listitem>
<para>Hoe <acronym>TCP</acronym> Wrappers in te stellen voor
- gebruik met <application>inetd</application>.</para>
+ gebruik met &man.inetd.8;.</para>
</listitem>
<listitem>
- <para>Hoe <application>Kerberos5</application> op &os; opgezet
+ <para>Hoe <application>Kerberos</application> op &os; opgezet
kan worden.</para>
</listitem>
<listitem>
<para>Hoe IPsec wordt ingesteld en hoe een
- <acronym>VPN</acronym> op te zetten tussen &os; en
- µsoft.windows; machines.</para>
+ <acronym>VPN</acronym> op te zetten.</para>
</listitem>
<listitem>
- <para>Hoe <application>OpenSSH</application>, &os;'s
- <acronym>SSH</acronym> implementatie, in te stellen en te
- gebruiken.</para>
+ <para>Hoe <application>OpenSSH</application> in &os; is in te
+ stellen en te gebruiken.</para>
</listitem>
<listitem>
- <para>Wat bestandssysteem-<acronym>ACL</acronym>s zijn en hoe
- die te gebruiken;</para>
+ <para>Hoe bestandssysteem-<acronym>ACL</acronym>s gebruikt
+ kunnen worden.</para>
</listitem>
<listitem>
@@ -93,13 +98,19 @@
</listitem>
<listitem>
- <para>Hoe om te gaan met publicaties van &os;
- beveiligingswaarschuwingen.</para>
+ <para>Hoe om te gaan met beveiligingswaarschuwingen van
+ &os;</para>
+ </listitem>
+
+ <listitem>
+ <para>Wat processaccounting is en hoe deze ingeschakeld kan
+ worden binnen &os;</para>
</listitem>
<listitem>
- <para>Iets van procesaccounting en hoe dat is in te schakelen
- in &os;.</para>
+ <para>Hoe de bron limieten database in elkaar zit en hoe deze
+ gebruikt kan worden om gebruikerslimieten te
+ controleren.</para>
</listitem>
</itemizedlist>
@@ -113,34 +124,25 @@
<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>
+ Toegangscontrole (Mandatory Access Control) besproken in
+ <xref linkend="mac"/> en Internet Firewalls in
+ <xref linkend="firewalls"/>.</para>
</sect1>
<sect1 xml:id="security-intro">
<title>Introductie</title>
<para>Beveiliging is een taak die begint en eindigt bij de
- systeembeheerder. Hoewel alle BSD &unix; meergebruikerssystemen
- 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>
+ systeembeheerder. Hoewel &os; enige inherente beveiliging
+ levert is het de zwaarste taak voor een systeembeheerder om deze
+ te configureren en bij te houden.</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 <systemitem class="username">root</systemitem> account aan te
- vallen (<quote>break root</quote>). Aandachtspunten voor
+ zonder te proberen de
+ <systemitem class="username">root</systemitem> account aan te
+ vallen. Aandachtspunten voor
beveiliging kunnen opgesplitst worden in categorieën:</para>
<orderedlist>
@@ -184,22 +186,20 @@
<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>
+ <para>Een ontzegging van dienst <acronym>DoS</acronym> aanval is
+ een actie die de machine middelen ontneemt. In het algemeen
+ zijn <acronym>DoS</acronym> 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.
+ Dit type aanval kan weliswaar de machine niet omver krijgen maar
+ kan wel de internetverbinding overbelasten.</para>
<indexterm>
<primary>beveiliging</primary>
@@ -207,36 +207,25 @@
<secondary>account compromitteren</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
- <systemitem class="username">root</systemitem> 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
- <systemitem class="username">root</systemitem> privileges kan krijgen. Het is van
- belang dit onderscheid te maken, omdat een aanvaller zonder
- toegang tot <systemitem class="username">root</systemitem> 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>
+ <para>Een gecompromitteerde gebruikersaccount komt veel vaker
+ voor dan een <acronym>DoS</acronym> aanval. Veel
+ systeembeheerders draaien nog onbeveiligde diensten, wat
+ betekend dat mensen die op het systeem aanloggen vanaf een
+ andere locatie potentieel het wachtwoord afgeluisterd kan worden.
+ De oplettende systeembeheerder analyseert de log bestanden en
+ zoekt dan naar verdachte bron adressen en verdachte logins.</para>
+
+ <para>Op een goed beveiligd en onderhouden systeem, betekend
+ toegang tot een gebruikersaccount niet direct dat de aanvaller
+ ook toegang heeft tot het
+ <systemitem class="username">root</systemitem> account. Zonder
+ <systemitem class="username">root</systemitem> toegang is de
+ aanvaller veelal niet in staat om zijn sporen uit te wissen en
+ kan op zijn best in staat zijn om met de bestanden van de
+ gebruiker te rommelen of de machine te laten crashen.
+ Gecompromiteerde gebruikeraccounts komen vaker voor omdat
+ gebruikers niet dezelfde voorzorgsmaatregelen nemen die
+ systeembeheerders vaak wel nemen.</para>
<indexterm>
<primary>beveiliging</primary>
@@ -244,29 +233,18 @@
<secondary>achterdeuren</secondary>
</indexterm>
- <para>Systeembeheerders moeten onthouden dat er in potentie heel
- veel manieren zijn om toegang tot <systemitem class="username">root</systemitem> te
- krijgen. Een aanvaller zou het
- <systemitem class="username">root</systemitem> wachtwoord kunnen kennen, een bug kunnen
- ontdekken in een dienst die onder <systemitem class="username">root</systemitem>
- draait en daar via een netwerkverbinding op in kunnen breken of
- een aanvaller zou een probleem kennen met een suid-root programma
- dat de aanvaller in staat stelt <systemitem class="username">root</systemitem> te
- worden als hij eenmaal toegang heeft tot een gebruikersaccount.
- Als een aanvaller een manier heeft gevonden om
- <systemitem class="username">root</systemitem> te worden op een machine, dan hoeft
- hij misschien geen achterdeur (<quote>backdoor</quote>) te
- installeren. Veel bekende manieren die zijn gevonden om
- <systemitem class="username">root</systemitem> 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
- <systemitem class="username">root</systemitem> 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>Er zijn veel potentiele manieren om toegang tot
+ <systemitem class="username">root</systemitem> te krijgen. Het
+ kan zijn dat de aanvaller het wachtwoord weet voor
+ <systemitem class="username">root</systemitem>, of dat de
+ aanvaller in staat is om een exploit op een bug los te laten in
+ een dienst die draait als
+ <systemitem class="username">root</systemitem>, of de aanvaller
+ weet misschien een bug in een SUID-root programma. Een aanvaller
+ kan een programma gebruiken, welke bekend staat als een backdoor,
+ om te zoeken naar vatbare systemen gebruik makende van
+ ongepatchte exploits om toegang tot een systeem te verkrijgen en
+ zijn sporen uit te wissen.</para>
<para>Beveiligingsmaatregelen moeten altijd geïmplementeerd
worden in een meerlagenmodel en worden als volgt
@@ -274,13 +252,14 @@
<orderedlist>
<listitem>
- <para>Beveiligen van <systemitem class="username">root</systemitem> en
- medewerkersaccounts.</para>
+ <para>Beveiligen van <systemitem class="username">root</systemitem>
+ en medewerkersaccounts.</para>
</listitem>
<listitem>
- <para>Beveiligen van <systemitem class="username">root</systemitem> – servers
- onder <systemitem class="username">root</systemitem> en suid-/sgid-binaire
+ <para>Beveiligen van <systemitem class="username">root</systemitem>
+ – servers onder <systemitem
+ class="username">root</systemitem> en suid-/sgid-binaire
bestanden.</para>
</listitem>
@@ -307,8 +286,8 @@
</listitem>
</orderedlist>
- <para>In het volgende onderdeel van dit hoofdstuk gaan we dieper in
- op de bovenstaande punten.</para>
+ <para>In het volgende onderdeel van dit hoofdstuk gaan we dieper
+ in op deze punten.</para>
</sect1>
<sect1 xml:id="securing-freebsd">
@@ -320,95 +299,67 @@
<secondary>&os; beveiligen</secondary>
</indexterm>
- <note>
- <title>Commando versus 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>
+ <para>Deze sectie beschrijft methoden om een &os; systeem te
+ beveiligen tegen de aanvallen zoals genoemd in de
+ <link linkend="security-intro">voorgaande sectie</link>.</para>
<sect2 xml:id="securing-root-and-staff">
- <title>Beveiligen van <systemitem class="username">root</systemitem> en
- medewerkersaccounts.</title>
+ <title>Beveiligen van <systemitem class="username">root</systemitem>
+ en medewerkersaccounts.</title>
- <indexterm><primary><command>su</command></primary></indexterm>
+ <indexterm>
+ <primary>&man.su.1;</primary>
+ </indexterm>
- <para>Om te beginnen: doe geen moeite om medewerkersaccounts
- te beveiligen als de <systemitem class="username">root</systemitem> account niet
- beveiligd is. Op de meeste systemen heeft de
- <systemitem class="username">root</systemitem> 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
+ <para>Op de meeste systemen heeft de
+ <systemitem class="username">root</systemitem> account een
+ wachtwoord. Als eerste moet aangenomen worden dat dit
+ wachtwoord <emphasis>altijd</emphasis> het risico loopt om
+ gecompromitteerd te worden. 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
- <systemitem class="username">root</systemitem> 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
- <systemitem class="username">root</systemitem> 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
- – diensten zoals FTP worden vaak over het hoofd gezien.
- Het direct aanmelden van <systemitem class="username">root</systemitem> hoort alleen
- te mogen via het systeemconsole.</para>
-
- <indexterm><primary><systemitem class="groupname">wheel</systemitem></primary></indexterm>
-
- <para>Natuurlijk moet een systeembeheerder de mogelijkheid hebben
- om <systemitem class="username">root</systemitem> 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én manier om
- <systemitem class="username">root</systemitem> toegankelijk te maken is door het
- toevoegen van de juiste medewerkersaccounts aan de
- <systemitem class="groupname">wheel</systemitem> groep (in
- <filename>/etc/group</filename>). De medewerkers die lid zijn
- van de groep <systemitem class="groupname">wheel</systemitem> mogen
- <command>su</command>–en naar <systemitem class="username">root</systemitem>.
- Maak medewerkers nooit <quote>native</quote> lid van de groep
- <systemitem class="groupname">wheel</systemitem> door ze in de groep
- <systemitem class="groupname">wheel</systemitem> te plaatsen in
- <filename>/etc/group</filename>. Medewerkersaccounts horen lid
- te zijn van de groep <systemitem class="groupname">staff</systemitem> en horen dan
- pas toegevoegd te worden aan de groep
- <systemitem class="groupname">wheel</systemitem> in het bestand
- <filename>/etc/group</filename>. Alleen medewerkers die ook
- echt toegang tot <systemitem class="username">root</systemitem> nodig hebben horen
- in de groep <systemitem class="groupname">wheel</systemitem> geplaatst te worden.
- Het is ook mogelijk, door een autenticatiemethode als Kerberos
- te gebruiken, om het bestand <filename>.k5login</filename> van
- Kerberos in de <systemitem class="username">root</systemitem> account te gebruiken
- om een &man.ksu.1; naar <systemitem class="username">root</systemitem> toe te staan
- zonder ook maar iemand lid te maken van de groep
- <systemitem class="groupname">wheel</systemitem>. Dit is misschien wel een
- betere oplossing, omdat het
- <systemitem class="groupname">wheel</systemitem>-mechanisme het nog steeds mogelijk
- maakt voor een inbreker <systemitem class="username">root</systemitem> te breken als
- de inbreker een wachtwoordbestand te pakken heeft gekregen en
- toegang kan krijgen tot één van de
- medewerkersaccounts. Hoewel het instellen van het
- <systemitem class="groupname">wheel</systemitem>-mechanisme beter is dan niets, is
- het niet per se de meest veilige optie.</para>
+ om en mogelijk zelfs niet via het &man.su.1; commando. In
+ het bestand <filename>/etc/ttys</filename> kunnen bijvoorbeeld
+ regels ingesteld worden als <literal>insecure</literal>
+ waardoor <systemitem class="username">root</systemitem> niet
+ kan inloggen op de gespecificeerde terminals. In &os; is het
+ zo dat <systemitem class="username">root</systemitem> standaard
+ niet kan aanloggen via &man.ssh.1; omdat
+ <literal>PermitRootLogin</literal> is ingesteld op
+ <literal>no</literal> in het bestand
+ <filename>/etc/ssh/sshd_config</filename>. Overdenk dit voor
+ elke methode waarbij toegang verkregen kan worden tot het
+ systeem, omdat diensten zoals FTP vaak vergeten worden. Directe
+ logins van <systemitem class="username">root</systemitem>
+ zouden alleen mogelijk moeten zijn via de console.</para>
- <para>Om een account volledig op slot te zetten, dient het
- commando &man.pw.8; gebruikt te worden:</para>
+ <indexterm>
+ <primary><systemitem class="groupname">wheel</systemitem></primary>
+ </indexterm>
+
+ <para>Omdat een systeembeheerder toegang nodig heeft tot het
+ <systemitem class="username">root</systemitem> account, moet er
+ additionele wachtwoord verificatie geconfigureerd worden. EEn
+ methode is om de gewenste gebruikeraccounts toe te voegen aan
+ de <systemitem class="groupname">wheel</systemitem> groep in
+ <filename>/etc/group</filename>. Leden van de groep
+ <systemitem class="groupname">wheel</systemitem> mogen gebruik
+ maken van &man.su.1; om <systemitem class="username">root</systemitem>
+ te worden. Alleen de gebruikers die echt toegang nodig hebben
+ tot het <systemitem class="username">root</systemitem> account
+ moeten geplaatst worden in de groep
+ <systemitem class="groupname">wheel</systemitem>. Als er
+ gebruik gemaakt wordt van Kerberos authenticatie moet er een
+ <filename>.k5login</filename> bestand gemaakt worden in de
+ homedirectory van <systemitem class="username">root</systemitem>
+ om gebruik te kunnen maken van &man.ksu.1; zonder dat iedereen
+ in de groep <systemitem class="groupname">wheel</systemitem>
+ geplaatst moet worden.</para>
+
+ <para>Om een account volledig op slot te zetten wordt gebruik
+ gemaakt van &man.pw.8;:</para>
<screen>&prompt.root; <userinput>pw lock staff</userinput></screen>
@@ -420,7 +371,7 @@
<quote><literal>*</literal></quote>-karakter te vervangen. Dit
karakter zal nooit overeenkomen met het versleutelde wachtwoord
en dus gebruikerstoegang blokkeren. Het volgende
- medewerkersaccount bijvoorbeeld:</para>
+ account bijvoorbeeld:</para>
<programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
@@ -437,34 +388,27 @@
<para>Deze 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>
+ minder beveiligd systeem. Als een server bijvoorbeeld netwerk
+ diensten levert, zou een workstation 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. Gelukkig vinden de meeste aanvallen
+ plaats op afstand, van mensen die geen fysieke toegang hebben
+ tot het systeem.</para>
<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 éé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>
+ om het wachtwoord van een account buiten gebruik te stellen of
+ te wijzigen op één plaats, waarbij het meteen actief is op
+ alle machines waarop de gebruiker een account heeft. Als het
+ account gecompromitteerd raakt, moet vooral de mogelijkheid om
+ per direct het wachtwoord voor machines te kunnen aanpassen
+ niet onderschat worden. Additionele beperkingen kunnen worden
+ opgedrongen met Kerberos: een Kerberos ticket kan na verloop
+ van tijd zijn geldigheid verliezen waarna het Kerberos systeem
+ de gebruiker dwingt om het wachtwoord te wijzigen.</para>
</sect2>
<sect2>
@@ -472,79 +416,30 @@
onder <systemitem class="username">root</systemitem> 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>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 <systemitem class="username">root</systemitem> account aan de hele wereld. Draai
- nooit een server die niet zorgvuldig is onderzocht. Veel
- servers hoeven niet te draaien als <systemitem class="username">root</systemitem>.
- 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. <systemitem class="username">root</systemitem> gaten zijn historisch
- gezien aanwezig geweest in vrijwel iedere server die ooit als
- <systemitem class="username">root</systemitem> 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ï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 <systemitem class="username">root</systemitem> moeten draaien
- en dat er vertrouwd moet worden op andere mechanismen om een
- inbraak via die servers te detecteren.</para>
+ <indexterm>
+ <primary>&man.sshd.8;</primary>
+ </indexterm>
+ <para>Een voorzichtige systeembeheerder draait alleen die diensten
+ die nodig zijn, niets meer, niets minder. De systeembeheerder
+ is zich ervan bewust dat diensten van derde partijen vaak het
+ meest bug gevoelig zijn. Draai nooit een server die niet
+ goed gecontroleerd is. Denk twee keer na voordat een dienst
+ als <systemitem class="username">root</systemitem> gestart
+ wordt, omdat er veel daemons zijn die onder andere gebruikers
+ kunnen draaien of gestart kunnen worden in een
+ <firstterm>zandbak</firstterm>. Activeer geen onveilige
+ diensten als &man.telnetd.8; of &man.rlogind.8;.</para>
+
+ <para>Een ander potentieel beveiligingsgat is het gebruik van
+ SUID-root en SGID binaries. De meeste van deze binaries zoals
+ &man.rlogin.1; leven in <filename>/bin</filename>,
+ <filename>/sbin</filename>
+ <!-- XXX REMKO -->
<para>De andere grote mogelijkheid voor <systemitem class="username">root</systemitem>
gaten in een systeem zijn de suid-root en sgid-binaire
bestanden die geïnstalleerd zijn op een systeem. Veel van
More information about the svn-doc-all
mailing list