From owner-svn-doc-all@FreeBSD.ORG Tue Apr 1 20:55:33 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BA15479; Tue, 1 Apr 2014 20:55:33 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26F03AE9; Tue, 1 Apr 2014 20:55:33 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s31KtXaM078434; Tue, 1 Apr 2014 20:55:33 GMT (envelope-from remko@svn.freebsd.org) Received: (from remko@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s31KtXVU078433; Tue, 1 Apr 2014 20:55:33 GMT (envelope-from remko@svn.freebsd.org) Message-Id: <201404012055.s31KtXVU078433@svn.freebsd.org> From: Remko Lodder Date: Tue, 1 Apr 2014 20:55:33 +0000 (UTC) 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 X-SVN-Group: doc-translations MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 01 Apr 2014 21:23:03 +0000 X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:55:33 -0000 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 --> Beveiliging - MatthewDillonVeel uit dit hoofdstuk is overgenomen uit de - security(7) handleiding van + + + Matthew + Dillon + + Veel uit dit hoofdstuk is overgenomen uit de + security(7) handleiding van + - SiebrandMazelandVertaald door + + + Siebrand + Mazeland + + Vertaald door + @@ -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 vriendelijke 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. - - &os; biedt veel hulpmiddelen en mechanismen om te zorgen - voor de integriteit en veiligheid van een systeem en - netwerk. + 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. + + &os; biedt veel hulpmiddelen en mechanismen om de integriteit + te borgen en de veiligheid van een systeem en het netwerk. Na het lezen van dit hoofdstuk weet de lezer: - Van basis systeembeveiligingsconcepten in relatie tot - &os;. + van Basis systeembeveiligingsconcepten in &os;. - Meer over verschillende versleutelingsmechanismen die - beschikbaar zijn in &os; zoals DES en - MD5. + Meer over verschillende versleutelingsmechanismen in + &os;. @@ -61,29 +68,27 @@ Hoe TCP Wrappers in te stellen voor - gebruik met inetd. + gebruik met &man.inetd.8;. - Hoe Kerberos5 op &os; opgezet + Hoe Kerberos op &os; opgezet kan worden. Hoe IPsec wordt ingesteld en hoe een - VPN op te zetten tussen &os; en - µsoft.windows; machines. + VPN op te zetten. - Hoe OpenSSH, &os;'s - SSH implementatie, in te stellen en te - gebruiken. + Hoe OpenSSH in &os; is in te + stellen en te gebruiken. - Wat bestandssysteem-ACLs zijn en hoe - die te gebruiken; + Hoe bestandssysteem-ACLs gebruikt + kunnen worden. @@ -93,13 +98,19 @@ - Hoe om te gaan met publicaties van &os; - beveiligingswaarschuwingen. + Hoe om te gaan met beveiligingswaarschuwingen van + &os; + + + + Wat processaccounting is en hoe deze ingeschakeld kan + worden binnen &os; - Iets van procesaccounting en hoe dat is in te schakelen - in &os;. + Hoe de bron limieten database in elkaar zit en hoe deze + gebruikt kan worden om gebruikerslimieten te + controleren. @@ -113,34 +124,25 @@ In dit boek worden nog meer onderwerpen met betrekking tot beveiliging beschreven. Zo wordt bijvoorbeeld Verplichte - Toegangscontrole (Mandatory Access Control) besproken in en Internet Firewalls in . + Toegangscontrole (Mandatory Access Control) besproken in + en Internet Firewalls in + . Introductie 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 - eerlijk 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. + systeembeheerder. Hoewel &os; enige inherente beveiliging + levert is het de zwaarste taak voor een systeembeheerder om deze + te configureren en bij te houden. 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 root account aan te - vallen (break root). Aandachtspunten voor + zonder te proberen de + root account aan te + vallen. Aandachtspunten voor beveiliging kunnen opgesplitst worden in categorieën: @@ -184,22 +186,20 @@ Ontzegging van Dienst (DoS) - 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 - (spoofed-packet) 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. + Een ontzegging van dienst DoS aanval is + een actie 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. + Dit type aanval kan weliswaar de machine niet omver krijgen maar + kan wel de internetverbinding overbelasten. beveiliging @@ -207,36 +207,25 @@ account compromitteren - Een gecompromitteerde gebruikersaccount komt nog veel vaker - voor dan een DoS aanval. Veel systeembeheerders draaien nog - steeds standaard telnetd, - rlogind, - rshd en - ftpd 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 (sniffed). Een - oplettende systeembeheerder analyseert zijn logboekbestanden om - te zoeken naar verdachte bronadressen, zelfs als het om - succesvolle aanmeldpogingen gaat. - - Uitgangspunt moet altijd zijn dat als een aanvaller toegang - heeft tot een gebruikersaccount, de aanvaller de - root 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 - root privileges kan krijgen. Het is van - belang dit onderscheid te maken, omdat een aanvaller zonder - toegang tot root 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. + Een gecompromitteerde gebruikersaccount komt veel vaker + voor dan een DoS 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. + + Op een goed beveiligd en onderhouden systeem, betekend + toegang tot een gebruikersaccount niet direct dat de aanvaller + ook toegang heeft tot het + root account. Zonder + root 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. beveiliging @@ -244,29 +233,18 @@ achterdeuren - Systeembeheerders moeten onthouden dat er in potentie heel - veel manieren zijn om toegang tot root te - krijgen. Een aanvaller zou het - root wachtwoord kunnen kennen, een bug kunnen - ontdekken in een dienst die onder root - 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 root te - worden als hij eenmaal toegang heeft tot een gebruikersaccount. - Als een aanvaller een manier heeft gevonden om - root te worden op een machine, dan hoeft - hij misschien geen achterdeur (backdoor) te - installeren. Veel bekende manieren die zijn gevonden om - root 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 - root 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. + Er zijn veel potentiele manieren om toegang tot + root te krijgen. Het + kan zijn dat de aanvaller het wachtwoord weet voor + root, of dat de + aanvaller in staat is om een exploit op een bug los te laten in + een dienst die draait als + root, 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. Beveiligingsmaatregelen moeten altijd geïmplementeerd worden in een meerlagenmodel en worden als volgt @@ -274,13 +252,14 @@ - Beveiligen van root en - medewerkersaccounts. + Beveiligen van root + en medewerkersaccounts. - Beveiligen van root – servers - onder root en suid-/sgid-binaire + Beveiligen van root + – servers onder root en suid-/sgid-binaire bestanden. @@ -307,8 +286,8 @@ - In het volgende onderdeel van dit hoofdstuk gaan we dieper in - op de bovenstaande punten. + In het volgende onderdeel van dit hoofdstuk gaan we dieper + in op deze punten. @@ -320,95 +299,67 @@ &os; beveiligen - - Commando versus protocol - - In dit hele document gebruiken we - vette tekst om te verwijzen naar een - commando of applicatie en een monospaced - 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. - - - In de volgende onderdelen behandelen we de methodes uit de - vorige paragraaf om een - &os;-systeem te beveiligen. + Deze sectie beschrijft methoden om een &os; systeem te + beveiligen tegen de aanvallen zoals genoemd in de + voorgaande sectie. - Beveiligen van <systemitem class="username">root</systemitem> en - medewerkersaccounts. + Beveiligen van <systemitem class="username">root</systemitem> + en medewerkersaccounts. - su + + &man.su.1; + - Om te beginnen: doe geen moeite om medewerkersaccounts - te beveiligen als de root account niet - beveiligd is. Op de meeste systemen heeft de - root account een wachtwoord. Als eerste - moet aangenomen worden dat dit wachtwoord - altijd gecompromitteerd is. Dit betekent - niet dat het wachtwoord verwijderd moet worden. Het wachtwoord - is namelijk bijna altijd nodig voor toegang via het console van + Op de meeste systemen heeft de + root account een + wachtwoord. Als eerste moet aangenomen worden dat dit + wachtwoord altijd 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 - (insecure) in het bestand - /etc/ttys zodat direct aanmelden met - root via telnet - of rlogin niet wordt toegestaan. Als andere - aanmelddiensten zoals sshd gebruikt - worden, dan hoort direct aanmelden via - root uitgeschakeld staat. Dit kan door - het bestand /etc/ssh/sshd_config te - bewerken en ervoor te zorgen dat - PermitRootLogin op no - staat. Dit moet gebeuren voor iedere methode van toegang - – diensten zoals FTP worden vaak over het hoofd gezien. - Het direct aanmelden van root hoort alleen - te mogen via het systeemconsole. - - wheel - - Natuurlijk moet een systeembeheerder de mogelijkheid hebben - om root 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 - root toegankelijk te maken is door het - toevoegen van de juiste medewerkersaccounts aan de - wheel groep (in - /etc/group). De medewerkers die lid zijn - van de groep wheel mogen - su–en naar root. - Maak medewerkers nooit native lid van de groep - wheel door ze in de groep - wheel te plaatsen in - /etc/group. Medewerkersaccounts horen lid - te zijn van de groep staff en horen dan - pas toegevoegd te worden aan de groep - wheel in het bestand - /etc/group. Alleen medewerkers die ook - echt toegang tot root nodig hebben horen - in de groep wheel geplaatst te worden. - Het is ook mogelijk, door een autenticatiemethode als Kerberos - te gebruiken, om het bestand .k5login van - Kerberos in de root account te gebruiken - om een &man.ksu.1; naar root toe te staan - zonder ook maar iemand lid te maken van de groep - wheel. Dit is misschien wel een - betere oplossing, omdat het - wheel-mechanisme het nog steeds mogelijk - maakt voor een inbreker root 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 - wheel-mechanisme beter is dan niets, is - het niet per se de meest veilige optie. + om en mogelijk zelfs niet via het &man.su.1; commando. In + het bestand /etc/ttys kunnen bijvoorbeeld + regels ingesteld worden als insecure + waardoor root niet + kan inloggen op de gespecificeerde terminals. In &os; is het + zo dat root standaard + niet kan aanloggen via &man.ssh.1; omdat + PermitRootLogin is ingesteld op + no in het bestand + /etc/ssh/sshd_config. Overdenk dit voor + elke methode waarbij toegang verkregen kan worden tot het + systeem, omdat diensten zoals FTP vaak vergeten worden. Directe + logins van root + zouden alleen mogelijk moeten zijn via de console. - Om een account volledig op slot te zetten, dient het - commando &man.pw.8; gebruikt te worden: + + wheel + + + Omdat een systeembeheerder toegang nodig heeft tot het + root account, moet er + additionele wachtwoord verificatie geconfigureerd worden. EEn + methode is om de gewenste gebruikeraccounts toe te voegen aan + de wheel groep in + /etc/group. Leden van de groep + wheel mogen gebruik + maken van &man.su.1; om root + te worden. Alleen de gebruikers die echt toegang nodig hebben + tot het root account + moeten geplaatst worden in de groep + wheel. Als er + gebruik gemaakt wordt van Kerberos authenticatie moet er een + .k5login bestand gemaakt worden in de + homedirectory van root + om gebruik te kunnen maken van &man.ksu.1; zonder dat iedereen + in de groep wheel + geplaatst moet worden. + + Om een account volledig op slot te zetten wordt gebruik + gemaakt van &man.pw.8;: &prompt.root; pw lock staff @@ -420,7 +371,7 @@ *-karakter te vervangen. Dit karakter zal nooit overeenkomen met het versleutelde wachtwoord en dus gebruikerstoegang blokkeren. Het volgende - medewerkersaccount bijvoorbeeld: + account bijvoorbeeld: foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh @@ -437,34 +388,27 @@ 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. + 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. 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 - ticket 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). + 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. @@ -472,79 +416,30 @@ onder root en suid-/sgid-binaire bestanden - ntalk - - comsat - - finger - - zandbakken + + zandbakken + - sshd - - telnetd - - rshd - - rlogind - - 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 imapd of - popper gelijk aan het weggeven van - de root account aan de hele wereld. Draai - nooit een server die niet zorgvuldig is onderzocht. Veel - servers hoeven niet te draaien als root. - Zo kunnen de ntalk, - comsat en - finger daemons bijvoorbeeld draaien - in speciale gebruikerszandbakken - (sandboxes). 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. root gaten zijn historisch - gezien aanwezig geweest in vrijwel iedere server die ooit als - root gedraaid heeft, inclusief de - basisservers van een systeem. Op een machine waarop mensen - alleen aanmelden via sshd en nooit - via telnetd of - rshd of - rlogind dienen die servers - uitgeschakeld te worden! - - &os; draait ntalkd, - comsat en - finger tegenwoordig standaard in een - zandbak. Een ander programma dat misschien beter in een - zandbak kan draaien is &man.named.8;. In - /etc/defaults/rc.conf staat als commentaar - welke parameters er nodig zijn om - named 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. - - sendmail - - Er zijn een aantal diensten die vooral niet in een zandbak - draaien: sendmail, - popper, - imapd, - ftpd 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 root moeten draaien - en dat er vertrouwd moet worden op andere mechanismen om een - inbraak via die servers te detecteren. + + &man.sshd.8; + + 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 root gestart + wordt, omdat er veel daemons zijn die onder andere gebruikers + kunnen draaien of gestart kunnen worden in een + zandbak. Activeer geen onveilige + diensten als &man.telnetd.8; of &man.rlogind.8;. + + Een ander potentieel beveiligingsgat is het gebruik van + SUID-root en SGID binaries. De meeste van deze binaries zoals + &man.rlogin.1; leven in /bin, + /sbin + De andere grote mogelijkheid voor root gaten in een systeem zijn de suid-root en sgid-binaire bestanden die geïnstalleerd zijn op een systeem. Veel van