svn commit: r44419 - translations/nl_NL.ISO8859-1/books/handbook/security
Remko Lodder
remko at FreeBSD.org
Wed Apr 2 17:59:41 UTC 2014
Author: remko
Date: Wed Apr 2 17:59:41 2014
New Revision: 44419
URL: http://svnweb.freebsd.org/changeset/doc/44419
Log:
Update my work in progress with today's work.
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 Wed Apr 2 10:25:12 2014 (r44418)
+++ translations/nl_NL.ISO8859-1/books/handbook/security/chapter.xml Wed Apr 2 17:59:41 2014 (r44419)
@@ -438,41 +438,26 @@
<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
- 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 <systemitem class="username">root</systemitem> gaten gevonden in deze
- bestanden. Zo is er in 1998 een <systemitem class="username">root</systemitem> 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 <systemitem class="groupname">tty</systemitem> kan naar
- bijna alle tty's van gebruikers schrijven. Als een gebruiker
- een terminalprogramma of een terminalemulator met een
+ <filename>/sbin</filename>, <filename>/usr/bin</filename> of
+ <filename>/usr/sbin</filename>. Ondanks dat niets 100% veilig
+ is, zijn de systeem standaard SUID en SGID binaries goed te
+ vertrouwen. Het is aangeraden om SUID binaries tot een
+ specifieke groep te beperken, zodat alleen bepaalde stafleden
+ SUID binaries kunnen gebruiken, en het verwijderen van niet
+ gebruikte SUID binaries. SGID binaries kunnen nagenoeg net
+ zo gevaarlijk zijn. Als een aanvaller in staat is om een
+ SGID-kmem binary te breken, kan de aanvaller in staat zijn om
+ <filename>/dev/kmem</filename> uit te lezen en daarmee ook
+ het gecodeerde wachtwoord bestand waardoor mogelijk ieder
+ genoemd account gecompromitteerd is. Ook is het mogelijk dat
+ een aanvaller die toegang heeft tot de groep
+ <filename>kmem</filename> in staat is om toetsaanslagen mee te
+ lezen welke verstuurd worden door de pty's, inclusief de pty's
+ die worden gebruikt om in te loggen met veilige methoden. Een
+ aanvaller die de groep
+ <systemitem class="groupname">tty</systemitem> kan breken, is
+ in staat om naar nagenoeg elke tty te schrijven. Als de
+ gebruiker een terminalprogramma of een terminalemulator met een
toetsenbordsimulatieoptie draait, dan kan de inbreker in
potentie een gegevensstroom genereren die ervoor zorgt dat de
terminal van de gebruiker een commando echot, dat dan wordt
@@ -483,65 +468,55 @@
<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
- versleuteld wachtwoordbestand.</para>
+ beveiligen. Wees alert bij het monitoren van gebruikeraccounts.
+ Het gebruik van &man.ssh.1; en Kerberos voor gebruikeraccounts,
+ vereisen extra beheer en technische ondersteuning maar leveren
+ een goede oplossing ten opzichte van een gecodeerd
+ wachtwoordbestand.</para>
</sect2>
<sect2>
<title>Beveiligen van het wachtwoordbestand</title>
<para>De enige echte oplossing is zoveel mogelijk wachtwoorden
- wegsterren 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 <systemitem class="username">root</systemitem>, is het wel mogelijk dat een
- inbreker leestoegang krijgt tot dat bestand zonder dat de
- aanvaller root-schrijftoegang krijgt.</para>
+ wegsterren en &man.ssh.1; of <application>Kerberos</application>
+ gebruiken voor toegang tot die accounts. Hoewel een gecodeerd
+ wachtwoordbestand (<filename>/etc/spwd.db</filename>) alleen
+ gelezen kan worden door
+ <systemitem class="username">root</systemitem>, 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
+ rapporteren over wijzigingen in het wachtwoordbestand zoals
+ beschreven in
<link linkend="security-integrity">Bestandsintegriteit
- Controleren</link> hieronder).</para>
+ 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
- <systemitem class="username">root</systemitem> dan kan hij ongeveer alles, maar er
- zijn een paar slimmigheidjes. Zo hebben bijvoorbeeld de meeste
- moderne kernels een ingebouwd pakketsnuffelstuurprogramma
- (<quote>packet sniffing</quote>). Bij &os; is dat het
- <filename>bpf</filename> 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 <filename>bpf</filename> apparaat mee te
- compileren.</para>
+ <para>De meeste moderne kernels bevatten een ingebouwd packet
+ sniffer apparaat. Binnen &os; wordt deze
+ <filename>bpf</filename> genoemd. Dit apparaat is nodig voor
+ DHCP maar kan verwijderd worden in een speciale kernel
+ configuratie als het systeem geen DHCP levert of nodig
+ heeft.</para>
- <indexterm><primary><command>sysctl</command></primary></indexterm>
+ <indexterm>
+ <primary>&man.sysctl.8;</primary>
+ </indexterm>
- <para>Maar zelfs als het <filename>bpf</filename>
+ <para>Zelfs als het <filename>bpf</filename>
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
+ inbreker kan een &man.kldload.8; gebruiken om zijn eigen
<filename>bpf</filename>-apparaat of een ander
snuffelapparaat te installeren in een draaiende kernel. Om
deze problemen te voorkomen, moet de kernel op een hoger
@@ -556,161 +531,145 @@
<screen>&prompt.root; <userinput>sysctl kern.securelevel=1</userinput></screen>
<para>Standaard start de kernel van &os; op met een
- veiligheidsniveau van -1. Het veiligheidsniveau blijft -1
- tenzij het is veranderd, òfwel door de beheerder
- òfwel door &man.init.8; vanwege een instelling in de
- opstartscripts. Het veiligheidsniveau kan tijdens het opstarten
- van het systeem verhoogd worden door de variabele
+ veiligheidsniveau van -1. Dit wordt <quote>insecure
+ mode</quote> genoemd, omdat alle onveranderlijke
+ bestandsvlaggen kunnen in en uitgeschakeld worden, en er
+ mag van alle apparaten gelezen en naartoe geschreven worden.
+ Het beveiliginsniveau blijft op -1 tenzij deze wordt aangepast,
+ ofwel door de beheerder ofwel door &man.init.8; door
+ instellingen in de opstartscripts. Het beveiligingsniveau kan
+ verhoogd worden tijdens het opstarten van het systeem door
+ het instellen van de variabele
<varname>kern_securelevel_enable</varname> op
- <literal>YES</literal> te zetten in het bestand
- <filename>/etc/rc.conf</filename>, en de waarde van de variabele
- <varname>kern_securelevel</varname> op het gewenste
- veiligheidsniveau in te stellen.</para>
-
- <para>Het standaard veiligheidsniveau van een &os;-systeem direct
- nadat de opstartscripts zijn uitgevoerd is -1. Dit wordt
- <quote>onveilige modus</quote> genoemd omdat de onveranderlijke
- bestandsvlag uitgezet kan worden, er van/naar alle apparaten mag
- worden gelezen en geschreven, enzovoorts.</para>
-
- <para>Als eenmaal het veiligheidsniveau op 1 of een hogere waarde
- is ingesteld, worden de alleen-toevoegen en onveranderlijke
- bestanden gehonoreerd, deze kunnen niet worden uitgezet, en
- wordt toegang tot rauwe apparaten ontzegd. Hogere niveaus
- beperken nog meer bewerkingen. Lees, voor een volledige
- beschrijving van het effect van de verschillende
- veiligheidsniveaus, de handleidingpagina &man.security.7;.</para>
+ <literal>YES</literal> in <filename>/etc/rc.conf</filename>, en
+ de waarde van <varname>kern_securelevel</varname> op het
+ gewenste beveiligingsniveau.</para>
+
+ <para>Zodra het beveiligingsniveau is ingesteld op 1 of een
+ hogere waarde worden de 'alleen toevoegen' en 'niet aanpassen'
+ bestanden gehonoreerd, deze kunnen niet worden uitgeschakeld
+ en toegang tot ruwe apparaten wordt verboden. Nog hogere
+ niveau's bieden nog meer restricties. Voor een volledige
+ beschrijving van het effect van de diverse beveiligingsniveau's
+ kan gekeken worden in &man.security.7; en &man.init.8;.</para>
<note>
<para>Het ophogen van het veiligheidsniveau naar 1 of hoger kan
- enkele problemen met X11 (toegang tot
- <filename>/dev/io</filename> zal worden geblokkeerd), of met
- de installatie van &os; wanneer die vanaf de broncode is
- gebouwd (het gedeelte <buildtarget>installword</buildtarget> van
- het proces moet tijdelijk de alleen-toevoegen en
- onveranderlijke vlaggen van sommige bestanden uitzetten), en
- met enkele andere gevallen veroorzaken. Soms, zoals het geval
- is met X11, is het mogelijk om dit te omzeilen door
- &man.xdm.1; behoorlijk vroeg in het opstartproces te starten,
- wanneer het veiligheidsniveau nog laag genoeg is.
- Omzeilmethoden zoals deze zijn misschien niet voor alle
- veiligheidsniveaus of voor alle beperkingen die ze opleggen
- mogelijk. Wat vooruit plannen is een goed idee. Het is
- belangrijk om de beperkingen die door elk veiligheidsniveau
- worden opgelegd te begrijpen omdat ze het gebruiksgemak van
- het systeem sterk verminderen. Het vergemakkelijkt ook het
- kiezen van eens standaardinstelling en voorkomt allerlei
- verassingen.</para>
+ enkele problemen met <application>&xorg;</application> geven
+ omdat toegang tot <filename>/dev/io</filename> wordt
+ geblokkeerd, of met de installatie van &os; wanneer deze uit
+ de broncode is gebouwd, omdat
+ <buildtarget>installworld</buildtarget> tijdelijk de
+ alleen-toevoegen en onveranderlijke vlaggen van enkele
+ bestanden moet resetten. In het geval van
+ <application>&xorg;</application> kan hier mogelijk omheen
+ gewerkt worden door het vroeg opstarten van &man.xdm.1; vroeg
+ in het opstart proces, zolang het beveiligingsniveau nog
+ laag genoeg is. Omzeilmethoden zoals deze zijn misschien
+ niet voor alle veiligheidsniveaus of voor alle beperkingen
+ die ze opleggen mogelijk. Wat vooruit plannen is een goed
+ idee. Het is belangrijk om de beperkingen die door elk
+ veiligheidsniveau worden opgelegd te begrijpen omdat ze het
+ gebruiksgemak van het systeem sterk verminderen. Het
+ vergemakkelijkt ook het kiezen van eens standaardinstelling
+ en voorkomt allerlei verrassingen.</para>
</note>
<para>Als het veiligheidsniveau van de kernel naar 1 of hoger
wordt verhoogd, kan het nuttig zijn om de vlag
<literal>schg</literal> aan te zetten voor kritieke
- opstartprogramma's, mappen, en scriptbestanden (i.e., alles dat
- gedraaid wordt tot het punt waar het veiligheidsniveau wordt
- ingesteld). Dit kan overdreven zijn, en het bijwerken van het
- systeem is veel moeilijker wanneer het op een hoog
- veiligheidsniveau werkt. Een minder beperkend compromis is om
+ opstartprogramma's, mappen, en scriptbestanden, en alles
+ dat opgestart wordt tot het punt waarop het veiligheidsniveau
+ toegepast wordt. Een minder beperkend compromis is om
het systeem op een hoger veiligheidsniveau te draaien maar het
aanzetten van de vlag <literal>schg</literal> voor elk
systeembestand en -map onder de zon over te slaan. Een andere
mogelijkheid is om <filename>/</filename> en
<filename>/usr</filename> simpelweg als alleen-lezen
- aan te koppelen. Het dient opgemerkt te worden dat het te draconisch
- zijn over wat is toegestaan het belangrijke detecteren van een
- inbraak kan verhinderen.</para>
+ aan te koppelen. Het dient opgemerkt te worden dat het te
+ draconisch zijn over wat is toegestaan het belangrijke
+ detecteren van een inbraak kan verhinderen.</para>
</sect2>
<sect2 xml:id="security-integrity">
- <title>Bestandsintegriteit controleren: binaire bestanden,
- instellingenbestanden, enzovoort</title>
+ <title>Bestandsintegriteit controleren</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 beveiliging) 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 hem op heterdaad te kunnen betrappen.</para>
+ <para>Er kan maar zoveel worden beveilgd aan de kern van
+ het systeem tot het onprettiger 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. Beveiligingsmaatregelen zijn waardeloos of nog erger
+ geven een vals gevoel van beveiliging als potentiele inbraken
+ niet kunnen worden gedetecteerd. De helft van het werk van
+ beveiliging is het vertragen van een aanvaller, niet om hem
+ te stoppen, zodat deze op heterdaad gepakt kan worden.</para>
<para>De beste manier om te zoeken naar een inbraak is zoeken
naar gewijzigde, ontbrekende of onverwachte bestanden. De beste
manier om te zoeken naar gewijzigde bestanden is vanaf een
- ander (vaak gecentraliseerd) systeem met beperkte toegang.
+ ander ,vaak gecentraliseerd, systeem met beperkte toegang.
Met zelfgeschreven scripts op dat extra beveiligde systeem met
beperkte toegang 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 cliëntmachines vrijwel ongezien gemonitord worden.
- Als de server met beperkte toegang verbonden is met de
- cliëntmachines 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>
+ maximaliseren moet het systeem met beperkte toegang
+ significante toegang hebben tot andere systemen, veelal door
+ een alleen-lezen <acronym>NFS</acronym> export of door het
+ opzetten van &man.ssh.1; sleutelparen. Buiten het netwerk
+ verkeer is <acronym>NFS</acronym> het minst zichtbaar waardoor
+ de beheerder in staat is om bestandssystemen op elke client
+ nagenoeg onzichtbaar te monitoren. Als de machine met
+ beperkte toegang verbonden is met een switch naar de andere
+ machines, is <acronym>NFS</acronym> veelal de betere keuze.
+ Als de machine met beperkte toegang verbonden is met de andere
+ machines via meerdere lagen routeringen kan de
+ <acronym>NFS</acronym> methode te onveilig zijn en kan
+ &man.ssh.1; een veiligere keuze zijn.</para>
<para>Als de machine met beperkte toegang eenmaal minstens
leestoegang heeft tot een cliëntsysteem dat het moet gaan
monitoren, dan moeten scripts gemaakt worden om dat monitoren
- ook echt uit te voeren. Uitgaande van een NFS-koppeling, kunnen
- de scripts gebruik maken van eenvoudige systeem hulpprogramma's
- als &man.find.1; en &man.md5.1;. We adviseren minstens
- één keer per dag een md5 te maken van alle
- bestanden op de cliëntmachine en van instellingenbestanden
- als in <filename>/etc</filename> en
+ ook echt uit te voeren. Uitgaande van een
+ <acronym>NFS</acronym>-koppeling, kunnen de scripts gebruik
+ maken van eenvoudige systeem hulpprogramma's als &man.find.1;
+ en &man.md5.1;. We adviseren minstens één keer per dag een
+ md5 te maken van alle bestanden op de cliëntmachine 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
+ 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. 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 cliënt
- 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>-cliënt op de
- cliënt zou al gecompromitteerd kunnen zijn. Het is
- misschien noodzakelijk ssh te gebruiken over onveilige
- verbindingen, maar dat maakt alles een stuk lastiger.</para>
+ <para>Als &man.ssh.1; in plaats van NFS wordt gebruikt, dan is
+ het schrijven van het script lastiger. Er is bijvoorbeeld
+ &man.scp.1; nodig om de scripts te transporteren naar de
+ machine die ze zal draaien. Het kan namelijk zijn dat
+ &man.ssh.1; reeds gecompromitteerd is op de clientmachine.
+ Het gebruik van &man.ssh.1; kan noodzakelijk zijn over
+ onveilige lijnen heen, maar is lastiger om mee om te
+ gaan.</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.
+ <filename>.ssh/authorized_keys</filename>.
Dat zijn bestanden die buiten het bereik van de
- <literal>MD5</literal>-controle vallen.</para>
+ <literal>MD5</literal>-controle kunnen 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 koppelvlaggen zo in te stellen dat
- suid-binaire bestanden op die partities niet zijn toegestaan.
- Zie daarvoor de optie <literal>nosuid</literal> (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 inbraakpoging is, of die
- nu succesvol is of niet.</para>
+ SUID-binaire bestanden op die partities niet zijn toegestaan
+ door gebruik te maken van de optie <literal>nosuid</literal>
+ in combinatie met &man.mount.8;. Controleer deze partities
+ minstens eens per week, omdat het doel is om een inbraak te
+ detecteren ongeacht of de poging wel of niet geslaagd is.</para>
<para>Procesverantwoording (zie &man.accton.8;) kost relatief
gezien weinig en kan bijdragen aan een evaluatie mechanisme
@@ -720,8 +679,8 @@
<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 zal proberen zijn sporen uit te
+ tot stand te komen en doorgestuurd te worden naar een syslog
+ server. Een aanvaller zal proberen 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
@@ -735,7 +694,7 @@
<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
+ wil, die 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
@@ -749,13 +708,13 @@
<sect2>
<title>Ontzeggen van Dienst aanvallen</title>
- <indexterm><primary>Ontzegging van Dienst (DoS)</primary></indexterm>
+ <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
+ <para>Een <acronym>DoS</acronym> aanval is meestal een pakket
+ gebasseerde aanval. Ondanks dat er niet veel te doen is tegen
+ gefingeerde pakkette die een netwerk kunnen verzadigen, kan
de schade geminimaliseerd worden door ervoor te zorgen dat
servers er niet door plat gaan door:</para>
@@ -765,33 +724,31 @@
</listitem>
<listitem>
- <para>Limiteren van springplank (<quote>springboard</quote>)
- aanvallen (ICMP response aanvallen, ping broadcast, etc.).</para>
+ <para>Limiteren van springplank aanvallen zoals ICMP
+ response aanvallen en ping broadcasts.</para>
</listitem>
<listitem>
- <para>De Kernel Route Cache overloaden.</para>
+ <para>De kernel route cache overloaden.</para>
</listitem>
</orderedlist>
- <para>Een veelvoorkomende DoS-aanval is om een server aan te
- vallen door het zoveel kindprocessen aan te laten maken dat het
- hostsysteem uiteindelijk geen bestandsdescriptors, geheugen
- enzovoort meer heeft en het dan 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>Een veelvoorkomende <acronym>DoS</acronym>-aanval is om
+ forkende server aan te vallen, waardoor er zoveel kindprocessen
+ worden gestart waarmee het hostsysteem uiteindelijk geen
+ bestandsdescriptors, geheugen enzovoort meer heeft en het dan
+ opgeeft. Er zijn een aantal &man.inetd.8; opties die dit
+ soort aanvallen kunnen beperken. Er moet wel worden opgemerkt
+ dat ondanks dat het mogelijk is om te voorkomen dat een machine
+ onderuit gaat, het meestal niet mogelijk is om te voorkomen dat
+ een dienst hinder ondervind van dit type aanval. Lees
+ &man.inetd.8; zorgvuldig en besteed in het bijzonder aandacht
+ aan de opties <option>-c</option>, <option>-C</option> en
+ <option>-R</option>. Gefingeerde pakketten kunnen de
+ <option>-C</option> optie omzeilen, dus vaak moet er een
+ combinatie van opties worden gebruikt. 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
@@ -812,59 +769,35 @@
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> <application>Sendmail</application> te
- beschermen tegen trapsgewijze fouten.</para>
+ <literal>MaxDaemonChildren</literal> van belang om tegen
+ trapsgewijze fouten te beschermen.</para>
- <para><application>Syslogd</application> kan direct aangevallen
+ <para>&man.syslogd.8;> 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
+ die terugverbinden zoals 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 <systemitem class="username">root</systemitem> via het netwerk en die
- diensten daaraan voorkomen. Er dient altijd een exclusieve
- firewall te zijn, dat wil zeggen <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
- springplankaanval: een server zo aanvallen dat de respons van
- die server de server zelf, het lokale netwerk of een andere
+ <para>Het is aangeraden om interne diensten te beschermen voor
+ toegang van buitenaf door deze te firewallen op de routers
+ aan de rand van het netwerk. Dit om verzadigingsaanvallen
+ van buiten het LAN netwerk te voorkomen, en niet zozeer om
+ een netwerk gebaseerde aanval op
+ <systemitem class="username">root</systemitem> te voorkomen.
+ Configureer altijd een exclusieve firewall, welke altijd alle
+ verkeer weigert, tenzij expliciet toegestaan. De reeks van
+ poorten die dynamisch gebruikt worden door &os; worden bediend
+ door de <varname>net.inet.ip.portrange</varname>
+ &man.sysctl.8; variabele.</para>
+
+ <para>Een andere veelvoorkomende <acronym>DoS</acronym>-aanval
+ is de springplankaanval: 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
@@ -877,44 +810,40 @@
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
- springplankaanval 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 laten verzadigen met
- ICMP-foutmeldingen. Dit type aanval kan een server ook laten
- crashen door te zorgen dat het geheugen ervan vol zit, zeker als
- de server de ICMP-antwoorden niet zo snel kwijt kan als dat het
- ze genereert. Gebruik de
- <application>sysctl</application>-variabele
- <literal>net.inet.icmp.icmplim</literal> om deze aanvallen te
- beperken. De laatste belangrijke klasse springplankaanvallen
- hangt samen met een aantal interne diensten van
- <application>inetd</application> zoals de UDP-echodienst. 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 poort <application>chargen</application>.
- Een competente systeembeheerder zal al deze interne
- <application>inetd</application> testdiensten
- uitschakelen.</para>
+ springplankaanval is er een er ICMP-foutmeldingen antwoorden
+ worden gegenereerd, welke de inkomende verbinding van een
+ server kan verzadigen en de uitgaande verbinding wordt verzadigd
+ door ICMP foutmeldingen. Dit type aanval kan een server laten
+ crashen door ervoor te zorgen dat de machine geen vrij geheugen
+ meer heeft, in het bijzonder als de server niet in staat is
+ om snel genoeg de ICMP foutmeldingen te verwerken. Gebruik de
+ &man.sysctl.8; variabele <literal>net.inet.icmp.icmplim</literal>
+ om deze aanvallen te beperken. De laatste belangrijke klasse
+ springplankaanvallen is gerelateerd aan bepaalde interne
+ &man.inetd.8; diensten, zoals de UDP-echodienst. Een aanvaller
+ fingeert 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 en het LAN overbelasten door een aantal van deze
+ pakketten te injecteren. Soortgelijke problemen kunnen
+ ontstaan met de poort <application>chargen</application>.
+ Deze interne test diensten moeten uitgeschakeld blijven.</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
+ &man.sysctl.8; parameters. Een aanval met gefingeerde
+ pakketten met een willekeurig bron-IP zorgt ervoor
dat de kernel een tijdelijke gecachede route maakt in de
routetabel, die uitgelezen kan worden met <command>netstat -rna
- | fgrep W3</command>. Deze routes hebben een levensduur van
+ | fgrep W3</command>. Deze routes hebben een levensduur van
ongeveer 1600 seconden. Als de kernel merkt dat de gecachede
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>
+ Dit creeërt twee problemen:</para>
<orderedlist>
<listitem>
@@ -928,7 +857,7 @@
</listitem>
</orderedlist>
- <para>Als servers verbonden zijn met het Internet via een E3
+ <para>Als servers verbonden zijn met het Internet via een T3
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
@@ -938,33 +867,35 @@
</sect2>
<sect2>
- <title>Aandachtspunten voor toegang met
- <application>Kerberos</application> en
- <application>SSH</application></title>
+ <title>Aandachtspunten voor toegang met Kerberos en
+ &man.ssh.1;</title>
- <indexterm><primary><command>ssh</command></primary></indexterm>
+ <indexterm>
+ <primary>&man.ssh.1;</primary>
+ </indexterm>
<para>Er zijn een aantal aandachtspunten die in acht genomen
- moeten worden als Kerberos of ssh gebruikt worden. Kerberos 5
- is een prima autenticatieprotocol, 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 de 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 <systemitem class="username">root</systemitem>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>
+ moeten worden als Kerberos of &man.ssh.1; gebruikt worden.
+ Kerberos is een prima autenticatieprotocol, maar er zitten
+ bugs in de Kerberos-versies van &man.telnet.1; en &man.rlogin.1;
+ waardoor ze niet geschikt zijn voor binair verkeer. Kerberos
+ codeert standaard de sessie niet, tenzij de optie
+ <option>-x</option> wordt gebruikt. &man.ssh.1; codeert
+ standaard wel alles.</para>
+
+ <para>Ondanks dat &man.ssh.1; prima werkt, stuurt deze de
+ coderingssleutels standaard door. Dit introduceert een
+ beveiligings risico voor een gebruiker die &man.ssh.1;
+ gebruikt om een onveilige machine te benaderen vanaf een
+ veilig werkstation. De sleutels zelf zijn niet bekend maar
+ &man.ssh.1; stelt een doorstuur poort in zolang de gebruiker
+ aangemeld is. Als een aanvaller in staat is geweest om het
+ <systemitem class="username">root</systemitem> account te
+ breken op de onveilige machine, kan hij van die poort gebruik
+ maken om toegang te krijgen tot alle machines waar de sleutels
+ van de gebruiker toegang toe geven.</para>
+
+ <!-- XXX Remko 777 -->
<para>Het advies is ssh in combinatie met Kerberos te gebruiken
voor het aanmelden door medewerkers wanneer dat ook maar
More information about the svn-doc-all
mailing list