Date: Tue, 1 Apr 2014 20:55:33 +0000 (UTC) From: Remko Lodder <remko@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-translations@freebsd.org Subject: svn commit: r44410 - translations/nl_NL.ISO8859-1/books/handbook/security Message-ID: <201404012055.s31KtXVU078433@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404012055.s31KtXVU078433>