diff --git a/nl_NL.ISO8859-1/books/handbook/security/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/security/chapter.sgml index fdbd76a1a8..0e2cd7bbfa 100644 --- a/nl_NL.ISO8859-1/books/handbook/security/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/security/chapter.sgml @@ -1,5313 +1,5314 @@ Matthew Dillon Veel uit dit hoofdstuk is overgenomen uit de security(7) handboekpagina van Siebrand Mazeland Vertaald door Beveiliging beveiliging Overzicht Dit hoofdstuk biedt een basisinleiding in systeembeveiligingsconcepten, een aantal goede basisregels en een paar gevorderde onderwerpen binnen &os;. Veel van de onderwerpen die worden behandeld kunnen ook worden toegepast op systemen en internet in het algemeen. Het internet is niet langer een 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 c.s. gehouden moeten worden. &os; biedt veel hulpmiddelen en mechanismen om te zorgen voor de integriteit en veiligheid van een systeem en netwerk. Na het lezen van dit hoofdstuk weet de lezer: Van basis systeembeveiligingsconcepten in relatie tot &os;; Meer over verschillende versleutelingsmechanismen die beschikbaar zijn in &os; zoals DES en MD5; Hoe eenmalige wachtwoordauthenticatie opgezet kan worden; Hoe TCP Wrappers in te stellen voor gebruik met inetd; Hoe KerberosIV op &os; releases eerder dan 5.0 opgezet kan worden; Hoe Kerberos5 op &os; 5.0 release en verder opgezet kan worden; Hoe IPsec wordt ingesteld en hoe een VPN op te zetten tussen &os; en µsoft.windows; machines; Hoe OpenSSH, &os;'s SSH implementatie, in te stellen en te gebruiken; Wat filesysteem ACLs zijn en hoe die te gebruiken; Hoe om te gaan met publicaties van &os; beveiligingswaarschuwingen. Er wordt aangenomen dat de lezer van dit hoofdstuk: Basisbegrip heeft van &os; en internetconcepten. 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 . Introductie Beveiliging is een taak die begint en eindigt bij de systeembeheerder. Hoewel alle BSD &unix; multi-user systemen enige inherente beveiliging kennen, is het bouwen en onderhouden van additionele beveiligingsmechanismen om de gebruikers eerlijk te houden waarschijnlijk een van de - zwaarste taken voor de systeembeheerder. Machines zijn zo veilig + 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. Beveiliging kan het beste ingesteld worden door een gelaagde ui-aanpak. In een notendop zijn er het beste net zoveel lagen van beveiliging als handig is en daarna dient het systeem zorgvuldig gemonitord te worden op inbraken. Het is niet wenselijk beveiliging te overontwerpen, want dat doet afbreuk aan de detectiemogelijkheden en detectie is een van de belangrijkste aspecten van beveiligingsmechanismen. Zo heeft het bijvoorbeeld weinig zin om de schg vlaggen (zie &man.chflags.1;) op ieder binair bestand op een systeem te zetten, omdat het, hoewel dit misschien tijdelijk binaire bestanden beschermt, een inbreker in een systeem ervan kan weerhouden een eenvoudig te detecteren wijziging te maken waardoor beveiligingsmaatregelen de inbreker misschien helemaal niet ontdekken. 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 + vallen (break root). Aandachtspunten voor beveiliging kunnen opgesplitst worden in categorieën: Ontzeggen van dienst aanvallen (Denial of service). Gebruikersaccounts compromitteren. root compromitteren via toegankelijke servers. root compromitteren via gebruikersaccounts. Achterdeur creëren (Backdoor). DoS aanvallen Ontzegging van Dienst (DoS) beveiliging Ontzegging van Dienst DoS aanvallen (DoS) 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. beveiliging account compromittering 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 + de gebruiker of de machine kan crashen. Gecompromitteerde gebruikersaccounts zijn vrij normaal omdat gebruikers normaliter niet de voorzorgsmaatregelen nemen die systeembeheerders nemen. beveiliging 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 kunnen 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. Beveiligingsmaatregelen moeten altijd geïmplementeerd worden in een meerlagenmodel en worden als volgt gecategoriseerd: Beveiligen van root en medewerkersaccounts. Beveiligen van root – servers onder root en suid/sgid binaire bestanden. Beveiligen van gebruikersaccounts. Beveiligen van het wachtwoordbestand. Beveiligen van de kern van de kernel, ruwe devices en bestandssystemen. Snel detecteren van ongeoorloofde wijzigingen aan het systeem. Paranoia. In het volgende onderdeel van dit hoofdstuk gaan we dieper in op de bovenstaande punten. &os; Beveiligen beveiliging &os; beveiligen Commando vs. 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. Beveiligen van <username>root</username> en Medewerkersaccounts. su 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 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 authenticatiemethode 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. Een indirecte manier om de medewerkersaccounts te beveiligen en uiteindelijk ook de toegang tot root, is het gebruik van alternatieve aanmeldmethodes en de wachtwoorden van de medewerkersaccounts, zoals het heet uit te sterren. Met &man.vipw.8; kan iedere instantie van een gecodeerd wachtwoord vervangen worden door een enkel * karakter. Met dit commando worden /etc/master.passwd en de gebruikers/wachtwoord database bijgewerkt om het aanmelden met wachtwoord uit te schakelen. Een regel voor een medewerkersaccount als: foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh Zou veranderd moeten worden naar: foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh Door deze wijziging kan niet langer normaal aangemeld worden omdat het gecodeerde wachtwoord nooit gelijk is aan de *. Nu dit is gebeurd, moeten medewerkers een ander mechanisme gebruiken om zich te authenticeren zoals &man.kerberos.1; of &man.ssh.1; met een publiek/privaat sleutelpaar. Bij het gebruik van iets als Kerberos moeten gewoonlijk de machines waarop de Kerberos server draait en het desktop werkstation beveiligd worden. Bij het gebruik van een publiek/privaat sleutelpaar met ssh, moet in het algemeen de machine van waar wordt aangemeld beveiligd worden (meestal een werkstation). Het is mogelijk nog een beveiligingslaag toe te voegen door het sleutelpaar te beschermen met een wachtwoord als het aan te maken met &man.ssh-keygen.1;. Door accounts van medewerkers uit te sterren is het ook gegarandeerd dat ze alleen aan kunnen melden door gebruik te maken van de veilige toegangsmethodes die de beheerder heeft ingesteld. Hierdoor worden alle medewerkers gedwongen veilige, gecodeerde verbindingen te gebruiken voor al hun sessies. Daarmee wordt een belangrijk beveiligingsgat gesloten dat veel indringers gebruiken: snuffelen aan het netwerk vanaf een niet-relevante minder veilige machine. Meer indirecte beveiligingsmechanismen hebben ook als uitgangspunt dat vanaf een zwaarder beveiligde machine wordt aangemeld op een minder beveiligd systeem. Als een hoofdserver bijvoorbeeld allerlei servers draait, zou het werkstation er geen moeten draaien. Om een werkstation redelijk veilig te laten zijn, dienen er zo min mogelijk servers op te draaien, bij voorkeur zelfs geen en er zou een schermbeveiliging met wachtwoordbeveiliging op moeten draaien. Maar als een aanvaller fysieke toegang heeft tot een werkstation, dan kan hij elke beveiliging die erop is aangebracht omzeilen. Dit probleem dient echt overwogen te worden, net als het feit dat de meeste aanvallen van een afstand plaatsvinden, via het netwerk, door mensen die geen fysieke toegang hebben tot werkstations of servers. KerberosIV 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). Beveiligen van <username>root</username> – servers onder <username>root</username> en suid/sgid Binaire Bestanden ntalk comsat finger 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 + 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. 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 die bestanden, zoals rlogin, staan in /bin, /sbin, /usr/bin of /usr/sbin. 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 root gaten gevonden in deze bestanden. Zo is er in 1998 een root gat gevonden in Xlib waardoor xterm (die normaliter suid is) kwetsbaar bleek. Een voorzichtige systeembeheerder kiest voor better to be safe than sorry 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 (chmod 000). Een server zonder monitor heeft normaal gezien - xterm niet nodig. Sgid bestanden + xterm niet nodig. Sgid bestanden kunnen bijna net zo gevaarlijk zijn. Als een inbreker een sgid-kmem stuk kan krijgen, dan kan hij wellicht /dev/kmem lezen en dus het gecodeerde wachtwoordbestand, waardoor mogelijk ieder account met een wachtwoord besmet is. Een inbreker toegang tot de groep kmem 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 tty kan naar bijna alle tty's van gebruikers schrijven. Als een gebruiker een terminalprogramma of een terminalemulator met een toetsenbordsimulatieoptie draait, dan kan de inbreker in potentie een datastroom genereren die ervoor zorgt dat de terminal van de gebruiker een commando echot, dat dan wordt uitgevoerd door die gebruiker. Beveiligen van Gebruikersaccounts 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 weggesterd 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 ssh en Kerberos voor gebruikersaccounts is problematischer vanwege het extra beheer en de ondersteuning, maar nog steeds een prima oplossing in vergelijking met een gecodeerd wachtwoordbestand. Beveiligen van het Wachtwoordbestand De enige echte oplossing is zoveel mogelijk wachtwoorden * maken en ssh of Kerberos gebruiken voor toegang tot die accounts. Hoewel een gecodeerd wachtwoordbestand (/etc/spwd.db) alleen gelezen kan worden door root, is het wel mogelijk dat een inbreker leestoegang krijgt tot dat bestand zonder dat de aanvaller root-schrijftoegang krijgt. Beveiligingsscripts moeten altijd controleren op en rapporteren over wijzigingen in het wachtwoordbestand (zie ook Bestandsintegriteit Controleren hieronder). Beveiligen van de Kern van de Kernel, Ruwe Devices en Bestandssystemen Als een aanvaller toegang krijgt tot root dan kan hij ongeveer alles, maar er - zijn een paar slimmigheidjes. Zo hebben bijvoorbeeld de meeste + zijn een paar slimmigheidjes. Zo hebben bijvoorbeeld de meeste moderne kernels een ingebouwde pakketsnuffeldriver (packet sniffing). Bij &os; is dat het bpf device. 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 bpf device mee te compileren. sysctl Maar zelfs als het bpf device is uitgeschakeld, dan zijn er nog /dev/mem en /dev/kmem. De inbreker kan namelijk nog schrijven naar ruwe diskdevices. En er is ook nog een optie in de kernel die modulelader (module loader) heet, &man.kldload.8;. Een ondernemende inbreker kan een KLD module gebruiken om zijn eigen bpf device of een ander snuffeldevice te installeren in een draaiende kernel. Om deze problemen te voorkomen, moet de kernel op een hoger veiligheidsniveau draaien, ten minste securelevel 1. Het securelevel wordt ingesteld met sysctl op de kern.securelevel variabele. Als securelevel op 1 staat, is het niet langer mogelijk te schrijven naar ruwe devices en speciale chflags vlaggen als schg worden dan afgedwongen. Ook dient de vlag schg gezet te worden op kritische opstartbestanden, mappen en scriptbestanden. Alles dat wordt uitgevoerd voordat het securelevel wordt ingesteld. Dit is misschien wat overdreven en het wordt lastiger een systeem te vernieuwen als dat in een hoger securelevel draait. Er is een compromis mogelijk door het systeem in een hoger securelevel te draaien maar de schg vlag niet op alle systeembestanden en mappen te zetten die maar te vinden zijn. / en /usr zouden ook als alleen-lezen gemount kunnen worden. Het is nog belangrijk om op te merken dat als de beheerder te Draconisch omgaat met dat wat hij wil beschermen, hij daardoor kan veroorzaken dat die o-zo belangrijke detectie van een inbraak wordt misgelopen. Bestandsintegriteit Controleren: Binaire Bestanden, Instellingenbestanden, Etc. 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 schg bit met chflags op de meeste bestanden in / en /usr waarschijnlijk averechts, omdat, hoewel de bestanden beschermd zijn, ook het venster waarin detectie plaats kan vinden is gesloten. De laatste laag van beveiliging is waarschijnlijk de meest belangrijke: detectie. Alle overige beveiliging is vrijwel waardeloos (of nog erger: geeft een vals gevoel van veiligheid) als een mogelijke inbraak niet gedetecteerd kan worden. Een belangrijk doel van het meerlagenmodel is het vertragen van een aanvaller, nog meer dan hem te stoppen, om de detectiekant van de vergelijking de kans te geven hem op heterdaad te betrappen. De beste manier om te zoeken naar een inbraak is zoeken naar gewijzigde, missende of onverwachte bestanden. De beste manier om te zoeken naar gewijzigde bestanden is vanaf een ander (vaak gecentraliseerd) systeem met beperkte toegang. Met zelfgeschreven scripts op dat extra beveiligde systeem met beperkte toegang ben is een beheerder vrijwel onzichtbaar voor mogelijke aanvallers en dat is belangrijk. Om het nut te maximaliseren moeten in het algemeen dat systeem met beperkte toegang best veel rechten gegeven worden op de andere machines in het netwerk, vaak via een alleen-lezen NFS export van de andere machines naar het systeem met beperkte toegang of door ssh sleutelparen in te stellen om het systeem met beperkte toegang een ssh verbinding te laten maken met de - andere machines. Buiten het netwerkverkeer, is NFS de minst + andere machines. Buiten het netwerkverkeer, is NFS de minst zichtbare methode. Hierdoor kunnen de bestandssystemen op alle client machines vrijwel ongezien gemonitord worden. Als de server met beperkte toegang verbonden is met de client machines via een switch, dan is de NFS methode vaak de beste keus. Als de server met beperkte toegang met de andere machines is verbonden via een hub of door meerdere routers, dan is de NFS methode wellicht niet veilig genoeg (vanuit een netwerk standpunt) en kan beter ssh gebruikt worden, ondanks de audit-sporen die ssh achterlaat. Als de machine met beperkte toegang eenmaal minstens leestoegang heeft tot een clientsysteem dat het moet gaan monitoren, dan moeten scripts gemaakt worden om dat monitoren ook echt uit te voeren. Uitgaande van een NFS mount, kunnen de scripts gebruik maken van eenvoudige systeem hulpprogramma's als &man.find.1; en &man.md5.1;. We adviseren minstens één keer per dag een md5 te maken van alle bestanden op de clientmachine en van instellingenbestanden als in /etc en /usr/local/etc 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 / en /usr. Als ssh in plaats van NFS wordt gebruikt, dan is het schrijven van het script lastiger. Dan moeten de scripts met scp naar de client verplaatst worden om ze uit te voeren, waardoor ze zichtbaar worden. Voor de veiligheid dienen ook de binaire bestanden die het script gebruikt, zoals &man.find.1;, gekopieerd te worden. De ssh client op de client zou al gecompromitteerd kunnen zijn. Het is misschien noodzakelijk ssh te gebruiken over onveilige verbindingen, maar dat maakt alles een stuk lastiger. Een goed beveiligingsscript voert ook controles uit op de instellingenbestanden van gebruikers en medewerkers: .rhosts, .shosts, .ssh/authorized_keys, enzovoort… Dat zijn bestanden die buiten het bereik van de MD5 controle vallen. Als gebruikers veel diskruimte hebben, dan kan het te lang duren om alle bestanden op deze partitie te controleren. In dat geval is het verstandig de mount vlaggen zo in te stellen dat suid binaire bestanden en devices op die partities niet zijn toegestaan. Zie daarvoor de nodev en nosuid opties (zie &man.mount.8;). Die partities moeten wel toch nog minstens eens per week doorzocht worden, omdat het doel van deze beveiligingslaag het ontdekken van een inbraak is, of die nu succesvol is of niet. Procesverantwoording (zie &man.accton.8;) kost relatief gezien weinig en kan bijdragen aan een evaluatie mechanisme voor na inbraken. Het is erg handig om uit te zoeken hoe iemand precies heeft ingebroken op het systeem, mits het bestand nog onbeschadigd is na de inbraak. Tenslotte horen beveiligingsscripts de logboekbestanden te verwerken en de logboekbestanden zelf horen zo veilig mogelijk tot stand te komen. remote syslog kan erg zinvol zijn. Een aanvaller probeert zijn sporen uit te wissen en logboekbestanden zijn van groot belang voor een systeembeheerder als het gaat om uitzoeken wanneer en hoe er is ingebroken. Een manier om logboekbestanden veilig te stellen is door het systeemconsole via een seriële poort aan te sluiten op een veilige machine en zo continu informatie te verzamelen. Paranoia Een beetje paranoia is niet verkeerd. Eigenlijk kan de systeembeheerder zoveel beveiligingsopties inschakelen als hij wil, als deze maar geen impact hebben op het gebruiksgemak en de beveiligingsopties die wel impact hebben op het gebruiksgemak kunnen ingeschakeld worden als daar zorgvuldig mee wordt omgegaan. Nog belangrijker is misschien dat er een juiste combinatie wordt gevonden. Als de aanbevelingen uit dit document woord voor woord worden opgevolgd, dan worden daarmee de methodes aan een toekomstige aanvaller verraden, die ook toegang heeft tot dit document. Ontzeggen van Dienst Aanvallen Ontzegging van Dienst (DoS) In deze paragraaf worden Ontzeggen van Dienst aanvallen (Denial of Service of DoS) behandeld. Een DoS aanval wordt meestal uitgevoerd als pakketaanval. Hoewel er weinig gedaan kan worden tegen de huidige aanvallen met gefingeerde pakketten die een netwerk kunnen verzadigen, kan de schade geminimaliseerd worden door ervoor te zorgen dat servers er niet door plat gaan. Limiteren van server forks. Limiteren van springplank (springboard) aanvallen (ICMP response aanvallen, ping broadcast, etc.). Kernel Route Cache. Een veelvoorkomende DoS aanval tegen een server die forkt is er een die probeert processen, file descriptors en geheugen te gebruiken tot de machine het opgeeft. inetd (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 inetd en het advies is in het bijzonder aandacht aan de , en opties te besteden. Aanvallen met gefingeerde IP adressen omzeilen de optie naar inetd, 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. Sendmail heeft de optie die veel beter blijkt te werken dan het gebruik van de opties van sendmail waarmee de werklast gelimitteerd kan worden. De parameter MaxDaemonChildren moet zodanig ingesteld worden dat als sendmail start, hij hoog genoeg is om de te verwachten belasting aan te kunnen, maar niet zo hoog is dat de computer het aantal instanties van sendmails niet aankan zonder plat te gaan. Het is ook verstandig om sendmail in de wachtrij modus () te draaien en de daemon (sendmail -bd) los te koppelen van de verwerking van de wachtrij (sendmail -q15m). Als de verwerking van wachtrij real-time moet, kunnen de tussenpozen voor verwerking verkort worden door deze bijvoorbeeld op in te stellen, maar dan is een redelijke instelling van MaxDaemonChildren van belang om die sendmail te beschermen tegen trapsgewijze fouten (cascade failures). Syslogd kan direct aangevallen worden en het is sterk aan te raden de optie te gebruiken waar dat ook maar mogelijk is en anders de optie. Er dient voorzichtig omgesprongen te worden met diensten die terugverbinden zoals TCP Wrapper's reverse-identd die direct aangevallen kan worden. In het algemeen is het hierom onverstandig gebruik te maken van de reverse-ident optie van TCP Wrapper. 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 (border routers). Dit heeft als achtergrond dat verzadigingsaanvallen voorkomen van buiten het LAN voorkomen kunnen worden. Daarmee wordt geen aanval op root via het netwerk en die diensten daaraan voorkomen. Er dient altijd een exclusieve firewall te zijn, d.w.z. firewall alles behalve poorten A, B, C, D en M-Z. Zo worden alle lage poorten gefirewalled behalve die voor specifieke diensten als named (als er een primary is voor een zone), ntalkd, sendmail 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 sluiten 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 net.inet.ip.portrange sysctls (sysctl -a | fgrep portrange), 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). ICMP_BANDLIM Een andere veelvoorkomende DoS aanval is de springplank aanval: een server zo aanvallen dat de respons van die server de server zelf, het lokale netwerk of een andere machine overbelast. De meest voorkomende aanval van dit type is de ICMP ping broadcast aanval. De aanvaller fingeert ping pakketten die naar het broadcast adres van het LAN worden gezonden met als bron het IP adres van de machine die hij eigenlijk aan wil vallen. Als de routers aan de rand van het netwerk niet zijn ingesteld om een ping aan een broadcast adres te blokkeren, dan kan het LAN genoeg antwoorden produceren om de verbinding van het slachtoffer (het gefingeerde bronadres) te verzadigen, zeker als de aanvaller hetzelfde doet met tientallen andere netwerken. Broadcastaanvallen met een volume van meer dan 120 megabit zijn al voorgekomen. Een tweede springplank aanval is er een tegen het ICMP foutmeldingssysteem. Door een pakket te maken waarop een ICMP foutmelding komt, kan een aanvaller de inkomende verbinding van een server verzadigen en de uitgaande verbinding wordt verzadigd door de foutmeldingen. Dit type aanval kan een server ook laten crashen, zeker als de server de ICMP antwoorden niet zo snel kwijt kan als ze ontstaan. De kernel van &os; kent een nieuwe compileeroptie waarmee de effectiviteit van dit type aanvallen afneemt. De laatste belangrijke klasse springplankaanvallen hangt samen met een aantal interne diensten van inetd zoals de UDP echo dienst. Een aanvaller fingeert eenvoudigweg een UDP pakket met als bronadres de echopoort van Server A en als bestemming de echopoort van Server B, waar Server A en B allebei op een LAN staan. Die twee servers gaan dat pakket dan heen en weer kaatsen. Een aanvaller kan beide servers overbelasten door een aantal van deze pakketten te injecteren. Soortgelijke problemen kunnen ontstaan met de chargen poort. Een competente systeembeheerder zal al deze interne inetd test-diensten uitschakelen. Gefingeerde pakketten kunnen ook gebruikt worden om de kernel route cache te overbelasten. Raadpleeg daarvoor de net.inet.ip.rtexpire, rtminexpire en rtmaxcache sysctl parameters. Een aanval met gefingeerde pakketten met een willekeurig bron IP zorgt ervoor dat de kernel een tijdelijke cached route maakt in de routetabel, die uitgelezen kan worden met netstat -rna | fgrep W3. Deze routes hebben een levensduur van ongeveer 1600 seconden. Als de kernel merkt dat de cached routetabel te groot is geworden, dan wordt rtexpire dynamisch verkleind, maar deze waarde wordt nooit lager dan rtminexpire. Er zijn twee problemen: De kernel reageert niet snel genoeg als een laag belaste server wordt aangevallen. rtminexpire is niet laag genoeg om de kernel de aanval te laten overleven. Als servers verbonden zijn met het internet via een E3 of sneller, dan is het verstandig om handmatig rtexpire en rtminexpire aan te passen via &man.sysctl.8;. Als de een van de parameters op nul wordt gezet, dan crasht de machine. Het instellen van beide waarden op 2 seconden is voldoende om de routetabel tegen een aanval te beschermen. Aandachtspunten voor Toegang met <application>Kerberos</application> en <application>SSH</application> ssh KerberosIV Er zijn een aantal aandachtspunten die in acht genomen moeten worden als Kerberos of ssh gebruikt worden. Kerberos V is een prima authenticatieprotocol, maar er zitten bugs in de kerberos versies van telnet en rlogin waardoor ze niet geschikt zijn voor binair verkeer. Kerberos codeert standaard sessie niet, tenzij de optie wordt gebruikt. ssh codeert standaard wel alles. 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 roottoegang 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. Het advies is ssh in combinatie met Kerberos te gebruiken voor het aanmelden door medewerkers wanneer dat ook maar mogelijk is. ssh kan gecompileerd worden met Kerberos ondersteuning. Dit vermindert de kans op blootstelling van ssh sleutels en beschermt tegelijkertijd de wachtwoorden met Kerberos. ssh sleutels zouden alleen gebruikt moeten worden voor geautomatiseerde taken vanaf veilige machines (iets waar Kerberos ongeschikt voor is). Het advies is om het doorsturen van sleutels uit te schakelen in de ssh instellingen of om de from=IP/DOMAIN optie te gebruiken die ssh in staat stelt het bestand authorized_keys te gebruiken om de sleutel alleen bruikbaar te maken voor entiteiten die zich aanmelden vanaf vooraf aangewezen machines. Bill Swingle Delen geschreven en herschreven door Siebrand Mazeland Vertaald door DES, MD5 en Crypt beveiliging crypt crypt DES MD5 Iedere gebruiker op een &unix; systeem heeft een wachtwoord bij zijn account. Het lijkt voor de hand liggend dat deze wachtwoorden alleen bekend horen te zijn bij de gebruiker en het eigenlijke besturingssysteem. Om deze wachtwoorden geheim te houden, zijn ze gecodeerd in een eenweg hash (one-way hash), wat betekent dat ze eenvoudig gecodeerd kunnen worden maar niet gedecodeerd. Met andere woorden, wat net gesteld werd is helemaal niet waar: het besturingssysteem kent het echte wachtwoord - niet. De enige manier om een wachtwoord in - platte tekst te verkrijgen, is door er met brute - kracht naar te zoeken in alle mogelijke wachtwoorden. + niet. De enige manier om een wachtwoord in platte + tekst te verkrijgen, is door er met brute kracht naar + te zoeken in alle mogelijke wachtwoorden. Helaas was DES, de Data Encryption Standard, de enige manier om wachtwoorden veilig te coderen toen &unix; ontstond. Dit was geen probleem voor gebruikers in de VS, maar omdat de broncode van DES niet geëxporteerd mocht worden moest &os; een manier vinden om zowel te gehoorzamen aan de wetten van de VS als aansluiting te houden bij alle andere &unix; varianten die nog steeds DES gebruikten. De oplossing werd gevonden in het splitsen van de coderingsbibliotheken zodat gebruikers in de VS de DES bibliotheken konden installeren en gebruiken en internationale gebruikers een coderingsmethode konden gebruiken die geëxporteerd mocht worden. Zo is het gekomen dat &os; MD5 is gaan gebruiken als coderingsmethode. Van MD5 wordt aangenomen dat het veiliger is dan DES, dus de mogelijkheid om DES te installeren is vooral beschikbaar om aansluiting te kunnen houden. Het Crypt Mechanisme Herkennen Voor &os; 4.4 was libcrypt.a een symbolic link die wees naar de bibliotheek die gebruikt werd voor codering. In &os; 4.4 veranderde libcrypt.a zodat er een instelbare wachtwoordhash bibliotheek kwam. Op dit moment ondersteunt de bibliotheek DES, MD5 en Blowfish hashfuncties. Standaard gebruikt &os; MD5 om wachtwoorden te coderen. Het is vrij makkelijk om uit te vinden welke coderingsmethode &os; op een bepaald moment gebruikt. De gecodeerde wachtwoorden in /etc/master.passwd bekijken is een manier. Wachtwoorden die gecodeerd zijn met MD5 zijn langer dan wanneer ze gecodeerd zijn met DES hash. Daarnaast beginnen ze met de karakters $1$. Wachtwoorden die beginnen met $2a$ zijn gecodeerd met de Blowfish hashfunctie. DES password strings hebben geen bijzondere kenmerken, maar ze zijn korter dan MD5 wachtwoorden en gecodeerd in een 64-karakter alfabet waar geen $ karakter in zit. Een relatief korte string die niet begint met een dollar teken is dus waarschijnlijk een DES wachtwoord. Het wachtwoord formaat voor nieuwe wachtwoorden wordt ingesteld met de passwd_format aanmeldinstelling in /etc/login.conf waar des, md5 of blf mag staan. Zie de &man.login.conf.5; handboekpagina voor meer informatie over aanmeldinstellingen. Eenmalige Wachtwoorden eenmalige wachtwoorden beveiliging eenmalige wachtwoorden S/Key is een eenmalige wachtwoord methode die gebaseerd is op de eenweg hashfunctie. &os; gebruikt een MD4 hash om aansluiting te houden, maar andere systemen gebruiken ook wel MD5 en DES-MAC. S/Key is al een onderdeel van het &os; basissysteem vanaf versie 1.1.5 en wordt ook in een groeiend aantal andere besturingssystemen gebruikt. S/Key is een geregistreerd handelsmerk van Bell Communications Research, Inc. Vanaf versie 5.0 van &os; is S/Key vervangen door OPIE (Eenmalige Wachtwoorden in Alles - One-time Passwords In Everything). OPIE gebruikt standaard een MD5 hash. Hier worden drie verschillende soorten wachtwoorden besproken. De eerste is het normale &unix; of Kerberos wachtwoord. Dit heet het &unix; wachtwoord. Het tweede type is een eenmalig wachtwoord dat wordt gemaakt met het S/Key programma key of het OPIE programma &man.opiekey.1; en dat wordt geaccepteerd door keyinit of &man.opiepasswd.1; en de aanmeldprocedure. Dit heet het eenmalige wachtwoord. Het laatste type wachtwoord is het wachtwoord dat wordt opgegeven aan de key/ opiekey programma's (en soms aan de keyinit / opiepasswd programma's) die gebruikt worden om eenmalige wachtwoorden te maken. Dit type heet geheim wachtwoord of gewoon een wachtwoord zonder toevoeging. Het geheime wachtwoord heeft niets te maken met het &unix; wachtwoord; ze kunnen hetzelfde zijn, dat wordt afgeraden. S/Key en OPIE geheime wachtwoorden kennen niet de beperking van 8 karakters als de oude &unix; wachtwoorden. Bij &os; mag het wachtwoord voor aanmelden tot 128 karakters lang zijn. Het mag onbeperkt lang zijn. Wachtwoorden van een zes of zeven woorden lange zin zijn niet ongewoon. Voor het overgrote deel werkt het S/Key of OPIE systeem volledig onafhankelijk van het &unix; wachtwoordsysteem. Buiten het wachtwoord zijn er nog twee stukjes data die van belang zijn voor S/Key en OPIE. Het eerste wordt zaad (seed) of sleutel (key) genoemd en bestaat uit twee letters en vijf cijfers. Het tweede stukje data heet de iteratieteller (iteration count), een nummer tussen 1 en 100. S/Key maakt een eenmalig wachtwoord door het zaad en het geheime wachtwoord aaneen te schakelen en daarop het door de iteratieteller aangegeven keren MD4/MD5 hash toe te passen. Daarna wordt het resultaat omgezet in zes korte Engelse woorden. Die zes woorden zijn een eenmalige wachtwoord. Het authenticatiesysteem (hoofdzakelijk PAM) houdt bij welk eenmalig wachtwoord het laatst is gebruikt en de gebruiker wordt geauthenticeerd als de hash van het door de gebruiker ingegeven wachtwoord gelijk is aan het vorige wachtwoord. Omdat er een eenweg hash wordt gebruikt, is het onmogelijk om toekomstige eenmalige wachtwoorden te maken als iemand toch een eenmalig wachtwoord heeft afgevangen. De iteratieteller wordt verlaagd na iedere succesvolle aanmelding om de gebruiker en het aanmeldprogramma synchroon te houden. Als de iteratieteller op 1 staat, moeten S/Key en OPIE opnieuw ingesteld worden. Er zijn drie programma's bij ieder systeem betrokken die hieronder worden besproken. De key en opiekey programma's hebben een iteratieteller, zaad en een geheim wachtwoord nodig en maken dan een eenmalig wachtwoord of een lijst van opeenvolgende eenmalige wachtwoorden. De programma's keyinit en opiepasswd worden gebruikt om respectievelijk S/Key en OPIE te initialiseren en om wachtwoorden, iteratietellers en zaad te wijzigen. Ze accepteren zowel wachtwoordzinnen als een iteratieteller, zaad en een eenmalig wachtwoord. De programma's keyinfo en opieinfo bekijken de relevante bestanden waarin de eigenschappen staan (/etc/skeykeys of /etc/opiekeys) en tonen de huidige iteratieteller en zaad van de gebruiker die het commando uitvoert. Nu worden vier verschillende acties besproken. Bij de eerste worden keyinit of opiepasswd gebruikt in een beveiligde verbinding om voor het eerst eenmalige wachtwoorden in te stellen of om een wachtwoord of zaad aan te passen. Bij de tweede worden keyinit of opiepasswd gebruikt in een niet-beveiligde verbinding samen met key of opiekey over een beveiligde verbinding om hetzelfde te bereiken. In een derde scenario wordt key/opiekey gebruikt om te melden over een onveilige verbinding. Het vierde scenario behandelt het gebruik van key of opiekey om een aantal sleutels aan te maken die opgeschreven of afgedrukt kunnen worden, zodat ze meegenomen kunnen worden naar een plaats van waar geen enkele veilige verbinding opgezet kan worden. Veilige Verbinding Initialiseren Om S/Key voor de eerste keer te initialiseren, een wachtwoord te wijzigen of zaad te veranderen over een beveiligde verbinding (bv. op het console van een machine of via ssh), moet het commando keyinit gebruikt worden zonder parameters terwijl een gebruiker als zichzelf is aangemeld: &prompt.user; keyinit Adding unfurl: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. Enter secret password: Again secret password: ID unfurl s/key is 99 to17757 DEFY CLUB PRO NASH LACE SOFT Bij OPIE wordt opiepasswd gebruikt: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED Als Enter new secret pass phrase: of Enter secret password: op het scherm verschijnt, dient een wachtwoord of wachtwoordzin ingevoerd te worden. Dit is dus niet het aanmeldwachtwoord is, maar dat dit wordt gebruikt om eenmalige wachtwoorden te maken. De ID regel geeft de parameters van het verzoek weer: de aanmeldnaam, de iteratieteller en zaad. Bij het aanmelden kent het systeem deze parameters en worden deze weergegeven zodat ze niet onthouden hoeven te worden. Op de laatste regel staat het eenmalige wachtwoord dat overeenkomt met die parameters en het geheime wachtwoord. Als de gebruiker direct opnieuw zou aanmelden, zou hij dat eenmalige wachtwoord moeten gebruiken. Onveilige Verbinding Initialiseren Om te initialiseren of een wachtwoord te wijzigen over een onveilige verbinding, moet er al ergens een veilige verbinding bestaand de gebruiker key of opiekey kan uitvoeren. Dit kan een desktop programma zijn op een &macintosh; of een shell prompt op een machine die vertrouwd wordt. De gebruiker moet ook een iteratieteller verzinnen (100 is wellicht een prima getal) en moet een eigen zaad bedenken of er een laten fabriceren. Over de onveilige verbinding (naar de machine die de gebruiker wil initialiseren) wordt het commando keyinit -s gebruikt: &prompt.user; keyinit -s Updating unfurl: Old key: to17758 Reminder you need the 6 English words from the key command. Enter sequence count from 1 to 9999: 100 Enter new key [default to17759]: s/key 100 to 17759 s/key access password: s/key access password:CURE MIKE BANE HIM RACY GORE Bij OPIE is dat opiepasswd: &prompt.user; opiepasswd Updating unfurl: You need the response from an OTP generator. Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY Om het standaard zaad te accepteren (dat het programma keyinit nogal verwarrend een key) noemt, is de invoer Return. Voor een toegangswachtwoord wordt ingevoerd, dient eerst gewisseld te worden naar de veilige verbinding of het S/Key desktop programma en dienen dezelfde parameters ingegeven te worden: &prompt.user; key 100 to17759 Reminder - Do not use this program while logged in via telnet or rlogin Enter secret password: <secret password> CURE MIKE BANE HIM RACY GORE Of bij OPIE: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT In de onveilige verbinding wordt nu het eenmalige wachtwoord in het relevante programma gekopieerd. Een Enkel Eenmalig Wachtwoord Maken Als S/Key of OPIE eenmaal is ingesteld staat er bij het aanmelden iets als het volgende: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <username> s/key 97 fw13894 Password: Of bij OPIE: &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <username> otp-md5 498 gr4269 ext Password: NB: de S/Key en OPIE meldingen hebben een erg zinvolle optie (die hier niet te zien is): als er op Return wordt gedrukt bij de wachtwoordregel, wordt de echo aangezet, zodat de invoer zichtbaar is. Dit is erg handig als er met de hand een wachtwoord wordt ingegeven, zoals wanneer het wordt ingevoerd vanaf een afdruk. MS-DOS Windows MacOS Nu moet het eenmalige wachtwoord gemaakt worden om het aanmeldprompt mee te antwoorden. Dit moet gedaan worden op een vertrouwd systeem waarop key of opiekey beschikbaar is. Er zijn ook versies voor &ms-dos;, &windows; en &macos;. Voor beide commando's moet zowel de iteratieteller als het zaad ingeven worden op de commandoregel. Deze kan zo overgenomen worden vanaf het aanmeldprompt op de machine waarop de gebruiker wil aanmelden. Op het vertrouwde systeem: &prompt.user; key 97 fw13894 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: WELD LIP ACTS ENDS ME HAAG Bij OPIE: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Nu het eenmalige wachtwoord er is, kan het aanmelden doorgang vinden: login: <username> s/key 97 fw13894 Password: <return to enable echo> s/key 97 fw13894 Password [echo on]: WELD LIP ACTS ENDS ME HAAG Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... Meerdere Eenmalige Wachtwoorden Maken Soms moet is een gebruiker ergens waarvandaan er geen toegang is tot een vertrouwde machine of een beveiligde verbinding. In dat geval is het mogelijk om met de key en opiekey commando's een aantal eenmalige wachtwoorden te maken om uit te printen en deze mee te nemen: &prompt.user; key -n 5 30 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: <secret password> 26: SODA RUDE LEA LIND BUDD SILT 27: JILT SPY DUTY GLOW COWL ROT 28: THEM OW COLA RUNT BONG SCOT 29: COT MASH BARR BRIM NAN FLAG 30: CAN KNEE CAST NAME FOLK BILK Of bij OPIE: &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: <secret password> 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI Met worden vijf opeenvolgende sleutels aangevraagd, geeft aan wat het laatste iteratiegetal moet zijn. Deze wachtwoorden worden weergegeven in omgekeerde volgorde voor gebruik. Als de gebruiker echt paranoïde bent kan hij ze opschrijven of hij kan er ook voor kiezen ze af te drukken met lpr. Op iedere regel staat dus de iteratieteller en het eenmalige wachtwoord, maar misschien is het toch handig om ze na gebruik af te strepen. Gebruik van &unix; Wachtwoorden Beperken S/Key kan beperkingen plaatsen op het gebruik van &unix; wachtwoorden gebaseerd op hostnaam, gebruikersnaam, terminalpoort of IP adres van een aanmeldsessie. Deze beperkingen staan in het instellingenbestand /etc/skey.access. De handboekpagina voor &man.skey.access.5; bevat meer informatie over de inhoud van het bestand en bevat ook details over een aantal aandachtspunten voor beveiliging voordat besloten wordt dit bestand te gebruiken in de beveiliging. Als het bestand /etc/skey.access niet bestaat (dat mag in &os; 4.X systemen), dan mogen alle gebruikers hun &unix; wachtwoord gebruiken. Maar als het bestand wel bestaat, dan moeten alle gebruikers S/Key gebruiken, tenzij iets anders expliciet wordt toegestaan door instellingen in het bestand skey.access. In alle gevallen worden &unix; wachtwoorden op het console wel toegestaan. Nu volgt een voorbeeld met instellingen in het bestand skey.access waarin de drie meest gebruikte instellingen terugkomen: permit internet 192.168.0.0 255.255.0.0 permit user fnord permit port ttyd0 In de eerste regel (permit internet) staat dat gebruikers met een bron IP adres (wat gefingeerd kan worden) dat past binnen de aangegeven waarde en masker altijd &unix; wachtwoorden mogen gebruiken. Dit mag niet gezien worden als beveiligingsmechanisme, maar eerder als een mogelijkheid om gebruikers aan wie het wordt toegestaan eraan te herinneren dat ze op een onveilig netwerk zitten en gebruik moeten maken van S/Key bij het aanmelden. De tweede regel (permit user) staat de gebruiker fnord toe om altijd &unix; wachtwoorden te gebruiken. In het algemeen dient dit alleen gebruikt te worden voor gebruikers die niet in staat zijn het programma key te gebruiken, zoals gebruikers met domme terminals of gebruikers die totaal niet op te voeden zijn. De derde regel (permit port) staat gebruikers die aanmelden vanaf een aangegeven terminalverbinding toe om &unix; wachtwoorden te gebruiken. Dit kan gebruikt worden voor inbellers. Met OPIE kan ook paal en perk gesteld worden aan het gebruik van &unix; wachtwoorden op basis van het IP adres van een aanmeldsessie, net als met S/Key. Dat kan met het bestand /etc/opieaccess dat standaard aanwezig is op &os; 5.0 en latere systemen. Bij &man.opieaccess.5; staat meer informatie over dit bestand en welke beveiligingsoverwegingen bestaan bij het gebruik. Hieronder een voorbeeld voor een opieaccess bestand: permit 192.168.0.0 255.255.0.0 In deze regel (permit internet) staat dat gebruikers met een bron IP adres (wat gefingeerd kan worden) dat past binnen de aangegeven waarde en masker altijd &unix; wachtwoorden mogen gebruiken. Als geen van de regels uit opieaccess van toepassing is, worden standaard pogingen zonder OPIE geweigerd. Tom Rhodes Geschreven door Siebrand Mazeland Vertaald door TCP Wrapper TCP Wrappers Iedereen die bekend is met &man.inetd.8; heeft waarschijnlijk wel eens van TCP Wrappers gehoord. Maar slechts weinigen lijken volledig te begrijpen hoe ze in een netwerkomgeving toegepast kunnen worden. Het schijnt dat iedereen een firewall wil hebben om netwerkverbindingen af te handelen. Ondanks dat een firewall veel kan, zijn er toch dingen die hij niet kan, zoals tekst terugsturen naar ontstaansplaats van een verbinding. De TCP software kan dat en nog veel meer. In dit onderdeel worden de TCP Wrappers mogelijkheden besproken en, waar dat van toepassing is, worden ook voorbeelden voor implementatie gegeven. De TCP Wrappers software vergroot de mogelijkheden van inetd door de mogelijkheid al zijn serverdaemons te controleren. Met deze methode is het mogelijk om te loggen, berichten te zenden naar verbindingen, een daemon toe te staan alleen interne verbindingen te accepteren, etc. Hoewel een aantal van deze mogelijkheden ook ingesteld kunnen worden met een firewall, geeft deze manier niet alleen een extra laag beveiliging, maar gaat dit ook verder dan wat een firewall kan bieden. De toegevoegde waarde van TCP Wrappers is niet dat het een goede firewall vervangt. TCP Wrappers kunnen samen met een firewall en andere beveiligingsinstellingen gebruikt worden om een extra laag van beveiliging voor het systeem te bieden. Omdat dit een uitbreiding is op de instellingen van inetd, wordt aangenomen dat de lezer het onderdeel inetd configuration heeft gelezen. Hoewel programma's die onder &man.inetd.8; draaien niet echt daemons zijn, heten ze traditioneel wel zo. Deze term wordt hier dus ook gebruikt. Voor het Eerst Instellen De enige voorwaarde voor het gebruiken van TCP Wrappers in &os; is ervoor te zorgen dat de inetd gestart wordt vanuit rc.conf met de optie . Dit is de standaardinstelling. Er wordt vanuit gegaan dat /etc/hosts.allow juist is ingesteld, maar als dat niet zo is, dan zal &man.syslogd.8; dat melden. In tegenstelling tot bij andere implementaties van TCP Wrappers is het gebruik van hosts.deny niet langer mogelijk. Alle instellingen moeten in /etc/hosts.allow staan. In de meest eenvoudige instelling worden verbindingen naar daemons toegestaan of geweigerd afhankelijk van de opties in /etc/hosts.allow. De standaardinstelling in &os; is verbindingen toe te staan naar iedere daemon die met inetd is gestart. Na de basisinstelling wordt aangegeven hoe dit gewijzigd kan worden. De basisinstelling heeft meestal de vorm daemon : adres : actie. daemon is de daemonnaam die inetd heeft gestart. Het adres kan een geldige hostnaam, een IP adres of een IPv6 adres tussen blokhaken ([ ]) zijn. Het veld actie kan allow of deny zijn, afhankelijk van of toegang toegestaan of geweigerd moet worden. De instellingen werken zo dat ze worden doorlopen van onder naar boven om te kijken welke regel als eerste van toepassing is. Als een regel van toepassing is gevonden, dan stop het zoekproces. Er zijn nog andere mogelijkheden, maar die worden elders toegelicht. Een eenvoudige instelling kan al van met deze informatie worden gemaakt. Om bijvoorbeeld POP3 verbindingen toe te staan via de mail/qpopper daemon, zouden de volgende instellingen moeten worden toegevoegd aan hosts.allow: # This line is required for POP3 connections: qpopper : ALL : allow Nadat deze regel is toegevoegd moet inetd herstart worden. Dit gaat met het &man.kill.1; commando of met de restart parameter met /etc/rc.d/inetd. Gevorderde Instellingen TCP Wrappers hebben ook gevorderde instellingen. Daarmee komt meer controle over de wijze waarop er met verbindingen wordt omgegaan. Soms is het een goed idee om commentaar te sturen naar bepaalde hosts of daemonverbindingen. In andere gevallen moet misschien iets in een logboekbestand geschreven worden of een e-mail naar de beheerder gestuurd worden. Dit kan allemaal met instellingen die wildcards, uitbreidingskarakters (expansion characters) en het uitvoeren van externe commando's heten. De volgende twee paragrafen beschrijven deze mogelijkheden. Externe Commando's Stel dat zich de situatie voordoet waar een verbinding geweigerd moet worden, maar er een reden gestuurd moet worden naar het individu dat die verbinding probeerde op te zetten. Hoe gaat dat? Dat is mogelijk door gebruik te maken van de optie . Als er een poging tot verbinding wordt gedaan, wordt er met een shellcommando of script uitgevoerd. Er staat al een voorbeeld in hosts.allow: # De andere daemons zijn beschermd. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." Dit voorbeeld geeft aan dat het bericht You are not allowed to use daemon from hostname. wordt teruggestuurd voor iedere daemon die niet al is ingesteld in het toegangsbestand. Het is erg handig om een antwoord terug te sturen naar degene die een verbinding op heeft willen zetten meteen nadat een tot stand gekomen verbinding is verbroken. Let wel dat alle berichten die gezonden worden moeten staan tussen " karakters. Hier zijn geen uitzonderingen op. Het is mogelijk een ontzegging van dienst aanval uit te voeren op de server als een aanvaller, of een groep aanvallers, deze daemons kan overstromen met verzoeken om verbindingen te maken. Het is ook mogelijk hier de optie te gebruiken. Net als weigert impliciet de verbinding en kan het gebruikt worden om shellcommando's of scripts uit te voeren. Anders dan bij stuurt geen bericht aan degene die de verbinding wilde maken. Zie bijvoorbeeld de volgende instelling: # Geen verbindingen van example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny Hiermee worden alle verbindingen van het domein *.example.com geweigerd. Tegelijkertijd worden ook hostnaam, IP adres en de daemon waarmee verbinding werd gemaakt naar /var/log/connections.log geschreven. Naast de vervangingskarakters die al zijn toegelicht, zoals %a, bestaan er nog een paar andere. In de handboekpagina van &man.hosts.access.5; staat een volledige lijst. Wildcard Opties Tot nu toe is in ieder voorbeeld ALL gebruikt. Er bestaan nog andere opties waarmee de mogelijkheden nog verder gaan. Zo kan ALL gebruikt worden om van toepassing te zijn op iedere instantie van een daemon, domein of een IP adres. Een andere wildcard die gebruikt kan worden is PARANOID. Daarmee wordt iedere host die een IP adres geeft dat gefingeerd kan zijn aangeduid. In andere woorden: paranoid kan gebruikt worden om een actie aan te geven als er een IP adres gebruikt wordt dat verschilt van de hostnaam. Het volgende voorbeeld kan wat verheldering brengen: # Weiger mogelijke gespoofte verzoeken aan sendmail: sendmail : PARANOID : deny In het voorgaande voorbeeld worden alle verbindingsverzoeken aan sendmail met een IP adres dat verschilt van de hostnaam geweigerd. Het gebruik van PARANOID kan nogal wat schade aanrichten als de client of de server kapotte DNS instellingen heeft. Voorzichtigheid van de beheerder is geboden. De handboekpagina van &man.hosts.access.5; geeft meer uitleg over wildcards en de mogelijkheden die ze bieden. Voordat de bovenstaande instellingen werken, dient de eerste regels in hosts.allow als commentaar gemarkeerd te worden. Mark Murray Bijgedragen door Mark Dapoz Gebaseerd op een bijdrage van Siebrand Mazeland Vertaald door <application>KerberosIV</application> Kerberos is een netwerkdienst, protocol en systeem waarmee gebruikers zich kunnen aanmelden met behulp van een dienst op een veilige server. Diensten als op een andere server aanmelden, op afstand kopiëren, veilig tussen systemen kopiëren en andere taken met een hoog risico worden aanmerkelijk veiliger en beter controleerbaar. De onderstaande instructies kunnen gebruikt worden als handleiding voor het opzetten van Kerberos op &os;. Voor een volledige beschrijving wordt verwezen naar de relevante handboekpagina's. <application>KerberosIV</application> Installeren MIT KerberosIV installeren Kerberos is een optioneel component van &os;. De meest eenvoudige manier om de software te installeren is het selecteren van de krb4 of krb5 distributie in sysinstall tijdens de initiële installatie van &os;. Hierdoor wordt de eBones (KerberosIV) of Heimdal (Kerberos5) implementatie van Kerberos geïnstalleerd. Deze implementaties zijn beschikbaar omdat ze ontwikkeld zijn buiten de VS/Canada en dus zijn ze beschikbaar voor systeemeigenaren buiten die landen in dit tijdperk waarin er beperkingen gelden ten aanzien van de export van coderingsprogramma's uit de VS. Het is ook mogelijk te kiezen voor de MIT implementatie van - Kerberos via de ports collectie: security/krb5. Maken van de Initiële Database Dit hoeft alleen op de Kerberos gedaan te worden. Er dienen geen oude Kerberos databases rond te slingeren. Controleer in de map /etc/kerberosIV of de volgende bestanden aanwezig zijn: &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms Als er nog meer bestanden zijn (zoals principal.* of master_key), dan kan met het programma kdb_destroy de oude Kerberos database vernietigd worden of de overige bestanden kunnen verwijderd worden als Kerberos niet draait. Nu moeten de bestanden krb.conf en krb.realms gewijzigd om de Kerberos wereld te definiëren. In dit geval heet de wereld EXAMPLE.COM en de server heet grunt.example.com. Wijzig of creëer het bestand krb.conf: &prompt.root; cat krb.conf EXAMPLE.COM EXAMPLE.COM grunt.example.com admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov In dit geval hoeven de andere werelden er niet te zijn. Ze staan er als voorbeeld van hoe een machine attent gemaakt kan worden op het bestaan van meerdere werelden. In een eigen test kan ervoor gekozen worden ze weg te laten. De eerste regel benoemt de wereld waarin het systeem opereert. De andere regels bevatten werelden/hosts. Het eerste deel van een regel bevat de wereld en het tweede deel is een host in die wereld die fungeert als sleutel distributiecentrum. De woorden admin server achter een hostnaam betekenen dat een host ook administratieve database server is. In de handboekpagina's van Kerberos wordt hierover meer uitleg gegeven. Nu moet grunt.example.com aan de wereld EXAMPLE.COM toegevoegd worden en er moet ook een instelling gemaakt worden voor alle hosts uit het .example.com domein in de wereld EXAMPLE.COM. Het bestand krb.realms dient dan als volgt gewijzigd te worden: &prompt.root; cat krb.realms grunt.example.com EXAMPLE.COM .example.com EXAMPLE.COM .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU Nogmaals: de andere werelden hoeven er niet te staan. Ze staan er als voorbeeld hoe een machine van het bestaan van andere werelden op de hoogte gebracht kan worden. Om het overzichtelijker te maken, kan mogen ze verwijderd worden. De eerste regel plaatst het specifieke systeem in de genoemde wereld. De rest van de regels geeft aan hoe standaardsystemen uit een bepaald subdomein in een wereld plaatst worden. Nu kan de database aangemaakt worden. Dit hoeft alleen op de Kerberos server gedaan te worden (of Sleutel Distributie Centrum) met het commando kdb_init: &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: Nu moet de sleutel opgeslagen worden zodat diensten op de lokale machine er gebruik van kunnen maken met het commando kstash: &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Nu is de gecodeerde hoofdsleutel opgeslagen in /etc/kerberosIV/master_key. Help Het aan de Praat KerberosIV eerste keer starten Voor ieder systeem dat met Kerberos wordt beveiligd moeten twee principals worden aangemaakt. Die heten kpasswd en rcmd. Deze twee principals worden aangemaakt voor iedere systeem en de instantie is de naam van het systeem. Deze daemons, kpasswd en rcmd, staan andere systemen toe om Kerberos wachtwoorden te wijzigen en commando's als &man.rcp.1;, &man.rlogin.1; en &man.rsh.1; uit te voeren. Deze worden nu toegevoegd: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- enter RANDOM here Verifying password New Password: <---- enter RANDOM here Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Aanmaken van het Serverbestand Nu moeten alle instanties die de diensten op iedere server definiëren geëxtraheerd worden. Dat kan met het commando ext_srvtab. Dit commando maakt een bestand aan dat veilig gekopieerd moet worden naar de map /etc/kerberosIV van iedere Kerberos client. Dit bestand moet aanwezig zijn op iedere server en op iedere client en is van doorslaggevend belang voor de werking van Kerberos. &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... Het bovenstaande commando maakt een tijdelijk bestand aan dat hernoemd moet worden naar srvtab zodat alle diensten erbij kunnen. Met &man.mv.1; kan het op de juiste plaats op het originele systeem gezet worden: &prompt.root; mv grunt-new-srvtab srvtab Als het bestand voor een clientsysteem is en het netwerk is niet veilig, dan kan het bestand client-new-srvtab dan naar een verwijderbaar medium gekopieerd worden en dan fysiek veilig getransporteerd worden. Op de client dient het bestand srvtab te heten in de map /etc/kerberosIV en in mode 600 te staan: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab De Database Vullen Nu moeten de gebruikers in de database. In dit voorbeeld wordt de gebruiker jane als eerste ingevoerd. Hiervoor is het commando kdb_edit: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- enter a secure password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Alles Testen - Eerst moeten de Kerberos daemons gestart worden. Als de + Eerst moeten de Kerberos daemons gestart worden. Als de juiste wijziging in /etc/rc.conf zijn gemaakt, dan gebeurt dit automatisch na een herstart. Dit hoeft alleen ingesteld te worden op de Kerberos server. Kerberos clients vinden automatisch wat ze zoeken in de map /etc/kerberosIV. &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: EXAMPLE.COM &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! Nu kunnen kan er getest worden of met het commando kinit een ticket (kaartje) gekregen kan worden voor het ID jane dat net is aangemaakt: &prompt.user; kinit jane MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane" Password: Met klist kan gecontroleerd worden of de tokens er echt zijn: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jane@EXAMPLE.COM Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM Nu wordt het wachtwoord gewijzigd met &man.passwd.1; om te controleren of de kpasswd daemon autorisatie krijgt van de Kerberos database: &prompt.user; passwd realm EXAMPLE.COM Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. <command>su</command> Rechten Toewijzen Kerberos biedt mogelijkheid iedere gebruiker die rootrechten nodig heeft zijn eigen afzonderlijke &man.su.1; wachtwoord te geven. Nu wordt een ID toegevoegd dat geautoriseerd is om &man.su.1; te gebruiken naar root. Dit wordt geregeld door een instantie van root te verbinden met een principal. Met kdb_edit kan jane.root gemaakt worden in de Kerberos database: &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- enter a SECURE password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit Een lijst van de tokens kan bevestigen als alles werkt zoals verwacht: &prompt.root; kinit jane.root MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane.root" Password: Nu dient de gebruiker toegevoegd te worden aan het bestand .klogin van root: &prompt.root; cat /root/.klogin jane.root@EXAMPLE.COM Na een &man.su.1;: &prompt.user; su Password: kan de lijst met tokens bekeken worden: &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@EXAMPLE.COM Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM Andere Commando's Gebruiken In een eerder voorbeeld is een principal met de naam jane gemaakt met een instantie root. Dit was gebaseerd op een gebruiker met dezelfde naam als de principal en dit is de standaard binnen Kerberos: een <principal>.<instantie> in de vorm van <gebruikersnaam>. root staat die <gebruikersnaam> het gebruik van &man.su.1; naar root toe als de benodigde instellingen in het bestand .klogin in de home directory van root zijn gemaakt: &prompt.root; cat /root/.klogin jane.root@EXAMPLE.COM Zo werkt het ook als een gebruiker in zijn eigen home directory iets als volgt heeft opgenomen: &prompt.user; cat ~/.klogin jane@EXAMPLE.COM jack@EXAMPLE.COM Hierdoor mag iedereen die zich in de wereld EXAMPLE.COM heeft geauthenticeerd als jane of jack (via kinit, zie boven) bij jane's account of de bestanden op dit systeem (grunt) met &man.rlogin.1;, &man.rsh.1; of &man.rcp.1;. Nu meldt bijvoorbeeld jane zich aan op een ander systeem met Kerberos: &prompt.user; kinit MIT Project Athena (grunt.example.com) Password: &prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Of jack meldt zich aan op jane's account op dezelfde machine (jane heeft het bestand .klogin ingesteld zoals hierboven en de beheerder van Kerberos heeft een principal jack aangemaakt zonder instantie): &prompt.user; kinit &prompt.user; rlogin grunt -l jane MIT Project Athena (grunt.example.com) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Tillman Hodgson Bijgedragen door Mark Murray Gebaseerd op een bijdrage van Siebrand Mazeland Vertaald door <application>Kerberos5</application> Iedere &os; release hoger dan &os;-5.1 bevat alleen ondersteuning voor Kerberos5. Daarom is Kerberos5 de enige versie die erbij zit. De instellingen zijn op veel gebieden gelijk aan die van KerberosIV. De nu volgende informatie geldt alleen voor &os;-5.0 releases en verder. Gebruikers die het KerberosIV package willen gebruiken kunnen dat installeren uit de security/krb4 port. Kerberos is een netwerkdienst, protocol en systeem waarmee gebruikers zich kunnen aanmelden met behulp van een dienst op een veilige server. Diensten als op een andere server aanmelden, op afstand kopiëren, veilig tussen systemen kopiëren en andere taken met een hoog risico worden aanmerkelijk veiliger en beter controleerbaar. Kerberos kan omschrijven worden als identiteitbevestigend proxy systeem. Het kan ook omschreven worden als een vertrouwd authenticatiesysteem van een derde partij. Kerberos vervult maar één taak: het veilig authenticeren van gebruikers op het netwerk. Het vervult geen autorisatietaken (wat gebruikers mogen) en controleert ook niets (wat gebruikers hebben gedaan). Nadat een client en server Kerberos hebben gebruikt om hun identiteit vast te stellen kunnen ze ook al hun communicatie coderen om hun privacy en data-integriteit te garanderen. Daarom wordt het sterk aangeraden om Kerberos samen met andere beveiligingsmechanismen te gebruiken die autorisatie en controlemogelijkheden bieden. De aanwijzingen die nu volgen kunnen gebruikt worden als werkinstructie om Kerberos in te stellen zoals dat wordt meegeleverd met &os;. Een complete beschrijving staat in de handboekpagina. Voor demonstratie van de installatie van Kerberos wordt gebruik gemaakt van de volgende naamgeving: Het DNS domein (zone) is example.org. De Kerberos wereld is EXAMPLE.ORG. Het advies is voor installaties van Kerberos echte domeinnamen te gebruiken, zelfs als het alleen intern wordt gebruikt. Hiermee worden DNS problemen voorkomen is een goede samenwerking met andere Kerberos werelden verzekerd. Geschiedenis Kerberos5 geschiedenis Kerberos is ontworpen door MIT als oplossing voor netwerkbeveiligingsproblemen. Het Kerberos protocol gebruikt sterke codering zodat een client zijn identiteit kan bewijzen aan een server (en andersom) over een onveilige netwerkverbinding. Kerberos is zowel de naam van een netwerkautorisatieprotocol als een bijvoeglijk naamwoord om de programma's te beschrijven die gebruik maken van het programma (zoals Kerberos telnet). De huidige versie van het protocol is versie 5 en is beschreven in RFC 1510. Er zijn een aantal vrij beschikbare implementaties van dit protocol beschikbaar voor veel systemen. Het Massachusetts Institute of Technology (MIT), waar Kerberos ooit is ontwikkeld, ontwikkelt nog steeds door aan hun Kerberos pakket. Het wordt in de VS veel gebruikt als coderingspakket en daarom wordt het ook geraakt door de exportwetgeving van de VS. Kerberos van MIT is beschikbaar als port (security/krb5). Heimdal Kerberos is een andere implementatie van versie 5 die expliciet buiten de VS is ontwikkeld om de exportwetgeving de omzeilen (en wordt daarom vaak gebruikt in niet-commerciële &unix; varianten). De Heimdal Kerberos distributie is beschikbaar als port (security/heimdal) en er zit een minimale installatie in de basisinstallatie van &os;. Om het grootst mogelijke publiek te bereiken gaan deze instructies ervan uit dat de Heimdal distributie die bij &os; zit wordt gebruikt. Opzetten van een Heimdal <acronym>KDC</acronym> Kerberos5 sleutel distributie centrum instellingen Het Sleutel Distributie Centrum (KDC, voluit Key Distribution Center) is de gecentraliseerde authenticatiedienst die Kerberos levert. Het is de computer die Kerberos tickets uitgeeft. Het KDC wordt vertrouwd door alle andere computer in de Kerberos wereld en daarom dient er een strenger beveiligingsregime op van kracht te zijn. Hoewel het draaien van de Kerberos dienst erg weinig van een systeem vraagt, wordt het wel aangeraden om een machine in te richten exclusief voor het KDC om beveiligingsredenen. Het opzetten van een KDC begint met de controle of de instellingen in /etc/rc.conf juist zijn om te functioneren als KDC (misschien moeten paden veranderd worden voor een eigen systeem): kerberos5_server_enable="YES" kadmind5_server_enable="YES" kerberos_stash="YES" is alleen beschikbaar in &os; 4.X. Daarna wordt het Kerberos instellingenbestand /etc/krb5.conf aangemaakt: [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG /etc/krb5.conf gaat ervan uit dat de KDC de fully-qualified hostname kerberos.example.org heeft. Als de KDC een andere hostname heeft, moet er nog een CNAME (alias) toevoegd aan de zonefile. Voor grotere netwerken met een juist ingestelde BIND DNS server kan het bovenstaande voorbeeld ingekort worden tot: [libdefaults] default_realm = EXAMPLE.ORG Door de volgende regels toe te voegen aan de zonefile voor example.org: _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG. Om clients de Kerberos diensten te kunnen laten vinden, moet er een volledig ingestelde /etc/krb5.conf zijn of een minimaal ingestelde /etc/krb5.conf en een correct ingestelde DNS server. Nu wordt de Kerberos database aangemaakt. Deze database bevat de sleutels voor alle principals en zijn versleuteld met een hoofdwachtwoord. Dit wachtwoord hoeft niet onthouden te worden omdat het wordt opgeslagen in (/var/heimdal/m-key). De hoofdsleutel wordt aangemaakt door kstash te starten en een wachtwoord in te voeren. Als de hoofdsleutel is gemaakt, kan de database ingeschakeld worden met kadmin met de optie -l (die staat voor local). Deze optie geeft kadmin de opdracht om de databasebestanden direct te wijzigingen in plaats van via de kadmind netwerkdienst. Hiermee wordt het kip-ei probleem opgelost waarbij een verbinding wordt gemaakt met de database voordat hij bestaat. Op het prompt van kadmin kan met init de database met de werelden aangemaakt worden. Tenslotte, nog steeds in kadmin, kan de eerste principal gemaakt worden met add. De standaardopties voor de principal worden nu aangehouden. Deze kunnen later altijd nog gewijzigd worden met modify. Met het commando ? kunnen alle beschikbare mogelijkheden getoond worden. Hieronder een sessie waarin een voorbeelddatabase wordt aangemaakt: &prompt.root; kstash Master key: xxxxxxxx Verifying password - Master key: xxxxxxxx &prompt.root; kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx Nu kan de KDC dienst gestart worden met /etc/rc.d/kerberos start en /etc/rc.d/kadmind start. Op dit moment draait er nog geen enkele daemon die gebruik maakt van Kerberos. Bevestiging dat KDC draait is te krijgen door een ticket te vragen en dat uit te lezen voor de principal (user) die zojuist is aangemaakt vanaf de commandoregel van het KDC zelf: &prompt.user; k5init tillman tillman@EXAMPLE.ORG's Password: &prompt.user; k5list Credentials cache: FILE:/tmp/krb5cc_500 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG <application>Kerberos</application> inschakelen op een Server met Heimdal diensten Kerberos5 diensten inschakelen Als eerste is een kopie van het instellingenbestand van Kerberos nodig, /etc/krb5.conf. Dit bestand kan eenvoudigweg op een veilige manier (met netwerkprogramma's als &man.scp.1;, of fysiek via een floppy) naar de clientcomputer gekopieerd worden vanaf de KDC. Hierna is het /etc/krb5.keytab nodig. Dit is het belangrijkste verschil tussen een server die een daemons met Kerberos aanbiedt en een werkstation: de server heeft het bestand keytab nodig. Dit bestand bevat de hostsleutel van de server waardoor het werkstation en de KDC elkaars identiteit kunnen bevestigen. Dit bestand dient veilig overgebracht te worden omdat de beveiliging van de server doorbroken kan worden als de sleutel openbaar wordt gemaakt. Dit betekent expliciet dat overdracht via een protocol dat platte tekst gebruikt, bv. FTP, een slecht idee is. Meestal wordt keytab naar de server gebracht met kadmin. Dat werkt handig omdat ook de host principal (het KDC onderdeel van krb5.keytab) aangemaakt moet worden met kadmin. Let wel op dat er al een ticket moet zijn en dat dit ticket de kadmin interface moet mogen gebruiken in kadmind.acl. Zie Beheer op Afstand in de Heimdal informatiepagina's (info heimdal) voor details over het ontwerpen van toegangscontrole. Als kadmin via het netwerk geen toegang mag hebben, dan kan ook op een veilige verbinding gemaakt worden met de KDC (via het lokale console, &man.ssh.1; of Kerberos &man.telnet.1;) zodat alles lokaal uitgevoerd kan worden met kadmin -l. Na het installeren van /etc/krb5.conf kan kadmin van de Kerberos server gebruikt worden. Met add --random-key kan de host principal toegevoegd worden en met ext kan de host principal van de server naar zijn eigen keytab - getrokken worden. Bijvoorbeeld: + getrokken worden. Bijvoorbeeld: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/myserver.example.org kadmin> exit Let op: ext slaat de sleutel standaard op in /etc/krb5.keytab. Als kadmind niet beschikbaar is op de KDC (wellicht om beveiligingsredenen) en er via het netwerk dus geen toegang is tot kadmin, dan kan de host principal (host/myserver.EXAMPLE.ORG) ook direct aan de KDC toegevoegd worden en daarna in een tijdelijk bestand gezet worden. Het volgende kan gebruikt worden om te voorkomen dat /etc/krb5.keytab op de KDC) wordt overschreven: &prompt.root; kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit Hierna kan de keytab veilig gekopieerd worden naar de server (met scp of een floppy). Geef een niet-standaard naam op voor de keytab om te voorkomen dat de keytab op de KDC wordt overschreven. Nu kan de server communiceren met de KDC (vanweg krb5.conf) en zijn identiteit bewijzen (vanwege krb5.keytab). Nu is de server klaar om er een aantal Kerberos diensten op te activeren. In dit voorbeeld wordt de dienst telnet geactiveerd door de volgende regel in /etc/inetd.conf te zetten en dan &man.inetd.8; te herstarten met /etc/rc.d/inetd restart: telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user Het belangrijkste is dat de typering -a (van authenticatie) op user staat. Meer details zijn in &man.telnetd.8; te vinden. <application>Kerberos</application> Activeren op een Client met Heimdal Kerberos5 clientinstellingen Het opzetten van een clientcomputer is eigenlijk kinderlijk eenvoudig. Wat betreft de Kerberos instelling is alleen het Kerberos instellingenbestand (/etc/krb5.conf) nodig. Dat kan eenvoudigweg naar de clientcomputer gekopieerd worden vanaf de KDC. Test de client met kinit, klist en kdestroy vanaf de client om een ticket te krijgen, te bekijken en daarna te verwijderen voor de principal die hierboven is aangemaakt. Nu moeten ook Kerberos applicaties gebruikt kunnen worden om verbindingen te maken met servers waarop Kerberos is geactiveerd. Als dat niet lukt en het verkrijgen van een ticket is wel mogelijk, dan ligt dat hoogstwaarschijnlijk aan de server en niet aan de client of de KDC. Bij het testen van een applicatie als telnet kan het beste een pakketsnuffelaar (bv. &man.tcpdump.1;) gebruikt worden om te bevestigen dat een wachtwoord niet als tekst wordt verzonden. Gebruik telnet met de optie -x. Dan wordt de complete datastroom versleuteld (vergelijkbaar met ssh). De Kerberos sleutelapplicaties op de client (meestal kinit, klist, kdestroy en kpasswd) zitten in de basisinstallatie van &os;. Let wel dat ze in &os; versies van voor 5.0 hernoemd zijn naar k5init, k5list, k5destroy, k5passwd en k5stash (deze commando's worden gewoonlijk maar een keer gebruikt). Er worden standaard ook andere Kerberos applicaties op de client geïnstalleerd. Hier komt de minimalistische natuur van de Heimdal basisinstallatie boven drijven: telnet is de enige dienst waarvoor Kerberos geactiveerd is. De Heimdal port voegt een aantal missende clientapplicaties toe: versies met ondersteuning voor Kerberos van ftp, rsh, rcp, rlogin en een paar minder gebruikelijke programma's. De MIT port bevat ook een volledig gamma aan Kerberos clientapplicaties. Instellingenbestanden voor Gebruikers: <filename>.k5login</filename> en <filename>.k5users</filename> Kerberos5 bestanden met gebruikersinstellingen Voor gebruikers binnen een wereld wijst hun Kerberos principal (bv. tillman@EXAMPLE.ORG) gewoonlijk naar een lokale gebruikeraccount (bv. een lokale account met de naam tillman). Voor Clientapplicaties als telnet is gewoonlijk geen gebruikersnaam of principal nodig. Soms moet iemand zonder bijpassende Kerberos principal toch toegang hebben tot een lokale gebruikersaccount. tillman@EXAMPLE.ORG zou bijvoorbeeld toegang nodig kunnen hebben tot de lokale gebruikersaccount webdevelopers. Andere principals zouden die toegang wellicht ook nodig kunnen hebben. De bestanden .k5login en .k5users uit de gebruikersmap kunnen op eenzelfde manier gebruikt worden als .hosts en .rhosts. Zo wordt het voorgaande probleem opgelost. Als bijvoorbeeld een .k5login met de volgende inhoud: tillman@example.org jdoe@example.org in de thuismap van de lokale gebruiker webdevelopers gezet wordt dan zouden beide principals toegang hebben tot die account zonder dat ze een wachtwoord hoeven te delen. We raden aan de handboekpagina's voor deze commando's te lezen. Let op dat de ksu handboekpagina .k5users behandelt. <application>Kerberos</application> Tips, Trucs en Problemen Oplossen Kerberos5 problemen oplossen Als de Heimdal of MIT Kerberos port wordt gebruikt dan dient de PATH omgevingsvariabele de Kerberos versies van de clientapplicaties te tonen voor de systeemversies. Hebben alle computers in de wereld hun tijd gesynchroniseerd? Als dat niet zo is, dan slaagt de authenticatie wellicht niet. beschrijft hoe klokken met NTP gesynchroniseerd kunnen worden. MIT en Heimdal werken prima samen. Dit geldt niet voor kadmin omdat daarvoor geen protocolstandaard is. Als een hostnaam wordt gewijzigd, dan moet ook de host/ principal aangepast en de keytab. Dit geldt ook voor bijzondere instellingen in de keytab zoals de www/ principal voor www/mod_auth_kerb van Apache. Alle hosts in een wereld moeten oplosbaar (resolvable) zijn (zowel vooruit als achteruit) in de DNS (of tenminste in /etc/hosts). CNAMEs werken wel, maar de A en PTR records moeten juist en actief zijn. De foutmelding is niet erg duidelijk: Kerberos5 refuses authentication because Read req failed: Key table entry not found. Sommige besturingssystemen van clients voor een KDC zetten wellicht geen setuid root voor ksu. - Dit betekent dat ksu niet werkt. Dat + Dit betekent dat ksu niet werkt. Dat is vanuit beveiligingsoogpunt een prima idee, maar wel lastig. Dit is dus geen KDC fout. Als met MIT Kerberos een principal een ticket moet krijgen dat langer geldig is dan de standaard van tien uur, dan moet modify_principal in kadmin gebruikt worden om de maximale geldigheidsduur (maxlife) van zowel de principal waar het om gaat als de krbtgt principal aan te passen. Dan kan de principal kinit -l gebruiken om een ticket met een langere levensduur aan te vragen. Als een pakketsnuffelaar op de KDC draait bij om te helpen bij het oplossen van problemen en dan kinit vanaf een werkstation wordt gestart, dan wordt zichtbaar dat de TGT meteen wordt verstuurd als kinit start, zelfs nog voor het wachtwoord! De reden hiervoor is dat de Kerberos server vrijelijk een TGT (Ticket Granting Ticket) verstuurt op iedere niet geautoriseerd verzoek. Maar iedere TGT is versleuteld met een sleutel die is afgeleid van het wachtwoord van de gebruiker. Als een gebruiker zijn wachtwoord ingeeft, wordt dat dus niet naar de KDC gezonden, maar ontcijfert het de TGT die kinit al heeft ontvangen. Als de ontcijfering resulteert in een geldige ticket met een geldige tijdstempel, dan heeft de gebruiker geldige Kerberos rechten. Deze rechten bevatten ook een sessiesleutel voor het opzetten van beveiligde communicatie met de Kerberos server in de toekomst en de eigenlijke ticket-granting ticket, die is versleuteld met de sleutel van de Kerberos server zelf. Deze tweede laag van versleuteling is niet bekend voor de gebruiker, maar het stelt de Kerberos server in staat om de juistheid van iedere TGT te bevestigen. Als tickets worden gebruik die lang geldig zijn (bv. een week) en OpenSSH wordt gebruikt om een verbinding te maken met de machine waarop het ticket staat, zorg er dan voor dat de Kerberos optie op no staat in sshd_config want anders worden tickets verwijderd bij afmelden. Host principals kunnen ook een langere levensduur hebben. Als een gebruikers principal een levensduur van een week heeft, maar de host waar de verbinding mee gemaakt wordt heeft een levensduur van negen uur, dan heb staat er een verlopen host principal in de cache en dan werkt e.e.a. niet zoals verwacht. Een krb5.dict bestand om het gebruik van bepaalde slechte wachtwoorden te voorkomen (dit wordt kort behandeld in de handboekpagina voor kadmind) heeft alleen betrekking op principals waar een wachtwoordbeleid voor geldt. De opmaak van krb5.dict is eenvoudig: een rij tekens per regel. Een symbolic link maken naar /usr/share/dict/words is misschien handig. Verschillen met de <acronym>MIT</acronym> port Het belangrijkste verschil tussen de MIT en Heimdal installatie heeft betrekking op kadmin, dat een andere (maar gelijkwaardige) set commando's kent en een andere protocol gebruikt. Dit betekent nogal wat als een KDC MIT is, omdat dan de kadmin van Heimdal niet gebruikt kan worden om de KDC vanaf afstand te beheren (dat geldt trouwens ook vice versa). De clientapplicaties kunnen ook commandoregelopties gebruiken die een beetje verschillen, maar waarmee wel hetzelfde wordt bereikt. We raden aan de instructies op de MIT Kerberos website () te volgen. Wees voorzichtig met paden: de MIT port installeert standaard in /usr/local/ en dus kunnen de normale systeemapplicaties gestart worden in plaats van die van MIT als de PATH omgevingsvariabele de systeemmappen als eerste weergeeft. Als de MIT security/krb5 port die bij &os; zit wordt gebruikt, dan zorgt het lezen van /usr/local/share/doc/krb5/README.FreeBSD dat bij de port wordt geïnstalleerd voor een beter begrip over waarom het aanmelden via telnetd en klogind soms wat vreemd verloopt. Als belangrijkste wijzen we erop dat het bij het corrigeren van onjuiste rechten op het cachebestand noodzakelijk is dat het binaire bestand login.krb5 wordt gebruikt voor authenticatie zodat het op de juiste wijze eigenaarschap kan wijzigen voor de doorgegeven rechten. Beperkingen in <application>Kerberos</application> Kerberos5 beperkingen en tekortkomingen <application>Kerberos</application> is een alles of niets aanpak Iedere ingeschakelde dienst op het netwerk moet aangepast worden om met Kerberos te werken (of op een andere manier beschermd zijn tegen netwerkaanvallen), want anders kunnen gebruikersrechten worden gestolen en hergebruikt. Een voorbeeld hier van is het inschakelen van Kerberos voor alle shells op afstand (via rsh en telnet bijvoorbeeld), maar de POP3 mailserver die wachtwoorden als platte tekst verzend ongemoeid laten. <application>Kerberos</application> is bedoeld voor werkstations met een gebruiker In een multi-user omgeving is - Kerberos minder veilig. Dit komt - doordat de tickets worden opgeslagen in de map + Kerberos minder veilig. Dit + komt doordat de tickets worden opgeslagen in de map /tmp, waar gelezen kan worden door alle gebruikers. Als een gebruiker een computer deelt met andere gebruikers op hetzelfde moment (dus multi-user), dan is het mogelijk dat een ticket van een gebruiker wordt gestolen (gekopieerd) door een andere gebruiker. Dit kan voorkomen worden met de commandoregeloptie -c bestandsnaam of (bij voorkeur) de omgevingsvariabele KRB5CCNAME, maar dat wordt zelden gedaan. In principe kan het opslaan van een ticket in de thuismap van een gebruiker in combinatie met eenvoudige bestandsrechten dit probleem verhelpen. De KDC is een single point of failure Zoals het is ontworpen, moet de KDC zo goed mogelijk beveiligd zijn, omdat de hoofd wachtwoorddatabase erop staat. De KDC hoort geen enkele andere dienst aan te bieden en moet ook fysiek afgeschermd worden. Het gevaar is groot, omdat Kerberos alle wachtwoorden versleutelt met dezelfde sleutel (de master sleutel) die als een bestand op de KDC staat. Toch is een gecompromitteerde master sleutel niet zo'n groot probleem als wellicht wordt verondersteld. De mastersleutel wordt alleen gebruikt om de Kerberos database te versleutelen en als zaad voor de generator van willekeurige nummers. Zo lang als de toegang tot de KDC is beveiligd, kan een aanvaller niet echt iets doen met de mastersleutel. Als de KDC niet beschikbaar is (misschien door een ontzeggen van dienst aanval of netwerkproblemen) kunnen de netwerkdiensten niet gebruikt worden omdat er geen authenticatie uitgevoerd kan worden; een recept voor een ontzeggen van dienst aanval. Dit risico kan omzeild worden door meerdere KDC's (één master en één of meer slaves) en een zorgvuldige implementatie van secundaire of fall-back authenticatie. PAM is hier uitermate geschikt voor. Tekortkomingen van <application>Kerberos</application> Kerberos stelt gebruikers, hosts en diensten in staat om elkaar te authenticeren. Maar het heeft geen mechanisme om de KDC te authenticeren aan de gebruikers, hosts of diensten. Dit betekent dat bijvoorbeeld een vervalste kinit alle gebruikersnamen en wachtwoorden zou kunnen afluisteren. Iets als security/tripwire of andere controle-instrumenten voor de integriteit van bestandssystemen kunnen hier verlichting brengen. Bronnen en Verdere Informatie Kerberos5 externe bronnen De Kerberos FAQ (Engels) Een Authenticatiesysteem Ontwerpen: een Dialoog in Vier Scenes (Engels) RFC 1510, De Kerberos Netwerk Authenticatie Dienst (V5) (Engels) MIT Kerberos homepage Heimdal Kerberos homepage Tom Rhodes Geschreven door Siebrand Mazeland Vertaald door OpenSSL beveiliging OpenSSL OpenSSL Een toepassing die bij &os; zit die veel gebruikers over het hoofd zien is OpenSSL. OpenSSL biedt een versleutelde transportlaag bovenop de normale communicatielaag. Daardoor biedt het de mogelijkheid met veel netwerktoepassingen en diensten verweven te raken. Een aantal toepassingen van OpenSSL zijn versleutelde authenticatie van mailclients, webgebaseerde transacties als creditcardbetalingen en nog veel meer. Veel ports zoals www/apache13-ssl en mail/sylpheed-claws bieden tijdens het compileren ondersteuning om OpenSSL in te bouwen. - In de meeste gevallen zal de portscollectie proberen de + In de meeste gevallen zal de Portscollectie proberen de port security/openssl te bouwen, tenzij de make variabele WITH_OPENSSL_BASE expliciet naar yes is gezet. De versie van OpenSSL die bij &os; zit ondersteunt Secure Sockets Layer v2/v3 (SSLv2/SSLv3), Transport Layer Security v1 (TLSv1) netwerk beveiligingsprotocollen en kan gebruikt worden als generieke versleutelingsbibliotheek. Hoewel OpenSSL ondersteuning biedt voor het IDEA algoritme, is dat standaard uitgeschakeld in verband met patenten in de VS. Om het te gebruiken dient de licentie gelezen te worden en, als de restricties aanvaardbaar zijn, dient de make variabele MAKE_IDEA ingesteld te worden in make.conf. Een van de meest gebruikte toepassingen van OpenSSL is het leveren van certificaten voor gebruik met softwaretoepassingen. Deze certificaten verzekeren dat de eigenschappen van een bedrijf of individu geldig zijn en niet vervalst. Als het certificaat in kwestie niet geldig verklaard is door een van de Certificate Authorities of CA's, dan komt er een waarschuwing. Een Certificate Authority is een bedrijf, zoals VeriSign, dat certificaten - ondertekent zodat de eigenschappen van een bedrijf of individu - geldig verklaard kunnen worden. Dit proces kost geld en het is - zeker geen voorwaarde voor het gebruik van certificaten. Het - stelt wel de meer paranoïde gebruikers gerust. + url="http://www.verisign.com">VeriSign, dat + certificaten ondertekent zodat de eigenschappen van een bedrijf + of individu geldig verklaard kunnen worden. Dit proces kost geld + en het is zeker geen voorwaarde voor het gebruik van + certificaten. Het stelt wel de meer paranoïde gebruikers + gerust. Certificaten Maken OpenSSL certificaten maken Voor het maken van certificaten is het volgende commando beschikbaar: &prompt.root; openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................ ....................................... writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (eg, YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:SOME PASSWORD An optional company name []:Another Name Let op dat het antwoord direct na Common Name een domeinnaam weergeeft. De prompt wil dat er een servernaam wordt ingegeven voor het verificatieproces. Het plaatsen van iets anders dan een domeinnaam zorgt ervoor dat het certificaat waardeloos wordt. Er zijn ook andere opties als verloopdatum, andere versleutelingsalgoritmen, etc, beschikbaar. Een volledige lijst is na te lezen in de handboekpagina van &man.openssl.1;. Er zou nu een bestand cert.pem moeten bestaan in de map waar het voorgaande commando is uitgevoerd. Dit is het certificaat dat aan een CA ter ondertekening gezonden kan worden. In gevallen waar ondertekening door een CA niet vereist is, kan een zelfondertekend certificaat gemaakt worden. Maak als eerste de RSA sleutel: &prompt.root; openssl dsaparam -rand -genkey -out myRSA.key 1024 Hierna kan de CA sleutel gemaakt worden: &prompt.root; openssl gendsa -des3 -out \ myca.key myRSA.key Deze sleutel kan gebruikt worden om een certificaat te maken: &prompt.root; openssl req -new -x509 -days 365 -key myca.key -out new.crt Er zouden nu twee bestanden bijgekomen moeten zijn in de map: een certificate authority ondertekeningsbestand myca.key en new.crt, het certificaat zelf. Deze moeten in een map geplaatst worden, bij voorkeur onder /etc waar alleen root kan lezen. De rechten 0700 zijn hier prima en die kunnen ingesteld worden met chmod. Certificate Gebruiken: een Voorbeeld En wat kunnen deze bestanden? Een prima toepassing zou het versleutelen van verbindingen naar de Sendmail MTA kunnen zijn. Daardoor zouden gebruikers niet langer platte tekst hoeven te authenticeren om mail te sturen via de lokale MTA. Dit is niet de best denkbare toepassing omdat sommige MUA's de gebruiker een foutmelding geven als ze het certificaat niet lokaal geïnstalleerd hebben. De documentatie bij de software geeft meer informatie over het installeren van certificaten. De volgende regels moeten opgenomen worden in het lokale .mc bestand: dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/new.crt')dnl define(`confSERVER_CERT',`/etc/certs/new.crt')dnl define(`confSERVER_KEY',`/etc/certs/myca.key')dnl define(`confTLS_SRV_OPTIONS', `V')dnl /etc/certs/ is de map die gebruikt wordt voor het lokaal opslaan van certificaten en sleutels. De laatste voorwaarde het is opnieuw aanmaken van het lokale .cf bestand. Dit gaat door eenvoudigweg make< install te typen in de map /etc/mail. Laat dat volgen door een make restart waardoor de Sendmail daemon herstart zou moeten worden. Als alles goed is gegaan, dan staan er geen foutmeldingen /var/log/maillog en is Sendmail zichtbaar in de proceslijst. Maak als eenvoudige test een verbinding met de mailserver met &man.telnet.1;: &prompt.root; telnet example.com 25 Trying 192.0.34.166... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host. Als de regel STARTTLS verschijnt in de uitvoer dan werkt alles correct. - Nik + Nik Clayton
nik@FreeBSD.org
 Gerschreven door Siebrand Mazeland Vertaald door VPN via IPsec Een VPN opzetten met &os; gateways tussen twee netwerken die gescheiden zijn door internet. Hiten M. Pandya
hmp@FreeBSD.org
 Geschreven door Siebrand Mazeland Vertaald door IPsec Begrijpen Deze paragraaf is een gids in het proces van het opzetten, en gebruiken van IPsec en het veilig laten communiceren van machines in een omgeving die bestaat uit &os; en µsoft.windows; 2000/XP. Voordat IPsec opgezet kan worden dient de lezer bekend te zijn met de concepten die nodig zijn om een aangepaste kernel te bouwen (zie ). IPsec is een protocol dat bovenop de Internet Protocol (IP) laag ligt. Hiermee kunnen twee of meer host op een veilige manier communiceren (vandaar de naam). De &os; IPsec netwerk wachtrij (stack) is gebaseerd op de KAME implementatie, die zowel de IPv4 als de IPv6 protocolfamilies ondersteunt. &os; 5.X bevat een door hardware geaccelereerde IPsec wachtrij die Fast IPsec heet en uit OpenBSD komt. Die kan gebruik maken van cryptografische hardware (waar mogelijk) via het &man.crypto.4; subsysteem om de prestaties van IPsec te optimaliseren. Dit subsysteem is nieuw en ondersteunt niet alle opties die beschikbaar zijn in de KAME versie van IPsec. Voordat er gebruik gemaakt kan worden van door hardware versnelde IPsec, moet de volgende optie in het kernelinstellingenbestand worden gezet: options FAST_IPSEC # new IPsec (cannot define w/ IPSEC) Het is op dit moment niet mogelijk om het Fast IPsec subsysteem samen met de KAME implementatie van IPsec te gebruiken. Zie &man.fast.ipsec.4; voor meer informatie. IPsec bestaat uit twee subprotocollen: Encapsulated Security Payload (ESP) beschermt de IP pakketdata tegen inmenging door een derde partij door de inhoud te versleutelen met symmetrische versleutelingsalgoritmen (als Blowfish en 3DES). Authentication Header (AH) beschermt de IP pakketkop tegen inmenging door een derde partij en spoofing door een cryptografische checksum te berekenen en de IP pakketkopvelden te hashen met een veilige hashfunctie. Hierna wordt een extra kop ingevoegd die de hash bevat zodat de informatie in het pakket geauthenticeerd kan worden. ESP en AH kunnen samen of apart gebruikt worden, afhankelijk van de omgeving. IPsec kan gebruikt worden om het verkeer tussen twee hosts direct te versleutelen (dat heet Transport Mode) of door virtuele tunnels te bouwen tussen twee subnetten die gebruikt kunnen worden voor veilige communicatie tussen twee bedrijfsnetwerken (dat heet Tunnel Mode). De laatste versie staat beter bekend als Virtual Private Network (VPN). In &man.ipsec.4; staat gedetailleerde informatie over het IPsec subsysteem in &os;. Voor ondersteuning voor IPsec in de kernel zijn de volgende opties nodig in het kernelinstellingenbestand: options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) Als er ook fouten in IPsec (debugging) verwijderd moeten kunnen worden, dan is de volgende optie ook nodig: options IPSEC_DEBUG #debug for IP security Het Probleem Er bestaat geen standaard voor wat een VPN is. VPN's kunnen opgezet worden met behulp van een aantal verschillende technologieën die allemaal hun eigen voor- en nadelen hebben. Dit onderdeel bevat een scenario en de strategieën die gebruikt kunnen worden voor het implementeren van een VPN in iedere situatie. Het Scenario: twee netwerken die één moeten lijken en via internet verbonden zijn Dit is het uitgangspunt: Er zijn tenminste twee locaties Beide locaties gebruiken IP Beide locaties hebben een internetverbinding via een gateway waarop &os; draait. De gateway op ieder netwerk heeft tenminste één publiek IP adres. De interne adressen van de twee netwerken mogen publieke of private IP adressen zijn, dat maakt niet uit. Er mag NAT draaien op de gateway als dat nodig is. De interne IP adressen van de twee netwerken mogen niet conflicteren. Hoewel dit in theorie mogelijk is een combinatie van VPN en NAT te gebruiken om dit te laten werken, wordt het vast een drama om dit in te stellen. Als de twee netwerken die met elkaar verbonden moeten worden intern dezelfde private IP adresreeksen gebruiken (beiden gebruiken bijvoorbeeld 192.168.1.x), dan moet een van de netwerken hernummerd worden. De netwerk topologie zou er zo uit kunnen zien: Netwerk #1 [ Interne Hosts ] Privaat Net, 192.168.1.2-254 [ Win9x/NT/2K ] [ UNIX ] | | .---[fxp1]---. Privaat IP, 192.168.1.1 | FreeBSD | `---[fxp0]---' Publiek IP, A.B.C.D | | -=-=- Internet -=-=- | | .---[fxp0]---. Publiek IP, W.X.Y.Z | FreeBSD | `---[fxp1]---' Privaat IP, 192.168.2.1 | | Netwerk #2 [ Internal Hosts ] [ Win9x/NT/2K ] Privaat Net, 192.168.2.2-254 [ UNIX ] Let op de twee publieke IP adressen. In de rest van dit onderdeel worden de letters gebruikt om ze aan te duiden. Overal waar die letters staan, kunnen ze vervangen worden door eigen publieke IP adressen. Zo hebben ook de twee gateway machines intern .1 IP adressen en de twee netwerken hebben andere IP adressen (respectievelijk 192.168.1.x en 192.168.2.x). Alle machines op de private netwerken zijn zo ingesteld dat ze de .1 machine als hun standaard gateway gebruiken. Het is de bedoeling dat, vanuit het netwerkstandpunt, ieder netwerk de machines in het andere netwerk kan zien alsof ze beiden aan dezelfde router zouden zitten; wel een router die een beetje langzaam is en af een toe een pakketje laat vallen. Dit betekent dat (bijvoorbeeld) op machine 192.168.1.20: ping 192.168.2.34 uitgevoerd kan worden en dat werkt, transparant. µsoft.windows; machines moeten het andere netwerk kunnen zien, gedeelde bestanden kunnen benaderen, enzovoort, op dezelfde manier als ze dat kunnen op het lokale netwerk. - En dat alles moet veilig zijn. Dat betekent dat verkeer + En dat alles moet veilig zijn. Dat betekent dat verkeer tussen de twee netwerken versleuteld moet zijn. Het opzetten van een VPN tussen twee netwerken is een proces dat uit meerdere stappen bestaat: Het maken van een virtuele netwerkverbinding tussen de twee netwerken over het internet. Testen met gereedschappen als &man.ping.8; om te bevestigen dat het werkt. Het instellen van beveiligingsbeleid om te verzekeren dat het verkeer tussen de twee netwerken transparant wordt versleuteld en ontsleuteld wanneer dat nodig is. Testen met gereedschappen als &man.tcpdump.1; om te bevestigen dat het werkt. Additionele software instellen op de &os; gateways om µsoft.windows; machines de andere kant van het VPN te laten zien. Stap 1: De <quote>virtuele</quote> netwerkverbinding maken en testen Stel dat een gebruiker is aangemeld op de gatewaymachine in netwerk #1 (met publiek IP adres A.B.C.D en privaat IP adres 192.168.1.1) en de voert ping 192.168.2.1 uit, naar het private adres van de machine met IP adres W.X.Y.Z. Wat moet er gebeuren om dat te laten werken? De gateway host moet weten hoe hij 192.168.2.1 kan bereiken. Met andere woorden: hij moet een route hebben naar 192.168.2.1. Private IP adressen als de reeks 192.168.x horen in het algemeen niet thuis op internet. Ieder pakket naar 192.168.2.1 moet dus ingepakt worden in een ander pakket. Dit pakket moet afkomstig lijken van A.B.C.D en moet naar W.X.Y.Z verstuurd worden. Dit proces heet inkapseling (encapsulation). Als dit pakket aankomt bij W.X.Y.Z dan moet het uitgekapseld (unencapsulated) worden en afgeleverd worden aan 192.168.2.1. Dit is alsof er een tunnel moet bestaan tussen de twee netwerken. De twee tunnelopeningen zijn de IP adressen A.B.C.D en W.X.Y.Z en de tunnel moet op de hoogte zijn van de private IP adressen die door de tunnel mogen. De tunnel wordt gebruikt om verkeer met private IP adressen over het internet te leiden. Deze tunnel wordt gemaakt door gebruik te maken van de generieke interface of gif devices op &os;. De gif interface moet op iedere gatewaymachine ingesteld zijn met vier IP adressen: twee voor de publieke IP adressen en twee voor de private IP adressen. Ondersteuning voor het gif device moet in de &os; kernel van beide machine gecompileerd worden. Dit kan door de volgende optie toe te voegen aan de kernelinstellingenbestanden op beide machines, dan de kernel te compileren, te installeren en dan gewoon te herstarten: pseudo-device gif - Het instellen van de tunnel gaat in twee stappen. Eerst + Het instellen van de tunnel gaat in twee stappen. Eerst moet de tunnel verteld worden wat de IP adressen aan de buitenkant (publiek) zijn met &man.gifconfig.8;. Daarna moeten de private IP adressen ingesteld worden met &man.ifconfig.8;. In &os; 5.X is de functionaliteit van &man.gifconfig.8; opgenomen in &man.ifconfig.8;. Op de gatewaymachine op netwerk #1 moeten de volgende commando's uitgevoerd worden om te tunnel in te stellen. gifconfig gif0 A.B.C.D W.X.Y.Z ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff Op de andere gatewaymachine moeten dezelfde commando's uitgevoerd worden met omgedraaide IP adressen. gifconfig gif0 W.X.Y.Z A.B.C.D ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff Daarna toont: gifconfig gif0 de instellingen. Op netwerk #1 zou dat het volgende zijn: &prompt.root; gifconfig gif0 gif0: flags=8011<UP,POINTTOPOINT,MULTICAST> mtu 1280 inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff physical address inet A.B.C.D --> W.X.Y.Z Er is nu een tunnel gemaakt tussen de fysieke adressen A.B.C.D en W.X.Y.Z en het verkeer dat door de tunnel mag is dat tussen 192.168.1.1 en 192.168.2.1. Hiermee is ook een regel gemaakt in de routetabel op beide machines die te bekijken zijn met netstat -rn. Deze uitvoer komt van de gatewayhost op netwerk #1. &prompt.root; netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire ... 192.168.2.1 192.168.1.1 UH 0 0 gif0 ... De Flags waarde geeft aan dat dit een hostroute is, wat betekent dat iedere gateway weet hoe hij de andere gateway kan bereiken, maar dat ze niet weten hoe ze bij de rest van elkaars netwerk kunnen komen. Dat probleem wordt snel opgelost. Het is waarschijnlijk dat op beide machines een firewall draait. Die moet omzeild worden voor VPN verkeer. Het is mogelijk al het verkeer tussen de beide netwerken toestaan of firewallregels toe te voegen waarmee de beide netwerken die het VPN met elkaar verbindt tegen elkaar beschermd worden. Het testen wordt een stuk eenvoudiger als de firewall zo is ingesteld dat al het verkeer door het VPN wordt doorgelaten. Laten kunnen nog restricties toegevoegd worden. Met &man.ipfw.8; wordt met ipfw add 1 allow ip from any to any via gif0 al het verkeer tussen de twee eindstations van het VPN toegestaan zonder dat dit de andere regels van de firewall beïnvloedt. Dit commando moet natuurlijk wel op beide gatewayhosts uitgevoerd worden. Deze instelling is toereikend om elke gateway machine het recht te geven de ander te pingen. Op 192.168.1.1 kan nu: ping 192.168.2.1 gedraaid worden en moet een antwoord komen. Op de andere machine kan dezelfde test gedaan worden. Maar nu zijn de andere machines op het interne netwerk nog niet te bereiken. Dat komt door de routering: hoewel de gateway machines elkaar nu weten te vinden, weten ze nog niet hoe ze het netwerk achter elkaar kunnen bereiken. Om dat probleem op te lossen moet een statische route worden toevoegd op iedere gateway machine. Het commando daarvoor is: route add 192.168.2.0 192.168.2.1 netmask 0xffffff00 Dit betekent: om hosts op het netwerk 192.168.2.0 te bereiken moeten pakketten naar de host 192.168.2.1 sturen. Een zelfde dient op de andere gateway uitgevoerd te worden, maar dan met de 192.168.1.x adressen. IP verkeer van hosts op het ene netwerk kan nu hosts op het andere netwerk bereiken. Hiermee is tweederde van het VPN tussen twee netwerken aangelegd in de zin dat het virtueel is en er een netwerk is. Maar het is nog niet privaat. Dit wordt aangetoond met &man.ping.8; en &man.tcpdump.1;. Voer op de gateway host het volgende commando uit:/para> tcpdump dst host 192.168.2.1 Voer vanuit een andere sessie op de host het onderstaande commando uit: ping 192.168.2.1 De uitvoer is ongeveer als volgt: 16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply Het is zichtbaar dat de ICMP berichten niet versleuteld heen en weer gaan. Als met &man.tcpdump.1; de parameter was gebruikt om meer bytes te tonen uit de pakketten, dan was meer informatie te zien geweest. Dit is natuurlijk onacceptabel. In de volgende paragraaf gaat het dan ook over het beveiligen van de verbinding tussen de twee netwerken zodat al het verkeer automatisch wordt versleuteld. Samenvatting: Stel voor beide kernels het pseudo-device gif in. Wijzig /etc/rc.conf op gateway host #1 en voeg de volgende regels toe (wijzig IP adressen naar wens). gifconfig_gif0="A.B.C.D W.X.Y.Z" ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff" static_routes="vpn" route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00" Wijzig het firewallscript (/etc/rc.firewall of iets dergelijks) op beide hosts en voeg het volgende toe: ipfw add 1 allow ip from any to any via gif0 Maak gelijksoortige wijzigingen in /etc/rc.conf op gateway host #2 en draai de volgorde van de IP adressen om. Stap 2: De Verbinding Beveiligen Om de verbinding te beveiligen wordt IPsec gebruikt. IPsec biedt een mechanisme waarmee twee hosts samen een sleutel hebben en die sleutel dan gebruiken om gegevens te versleutelen tussen die twee hosts. Hiervoor moet op twee plaatsen een aanpassing gemaakt worden in de instellingen. Er moet een mechanisme zijn voor de twee hosts om het eens te worden over het versleutelingsmechanisme dat gebruikt gaat worden. Als de twee hosts het daar over eens zijn, dan hebben ze een zogenaamde beveiligingssamenwerking (security association). Er moet een mechanisme zijn waarmee wordt aangegeven welk verkeer versleuteld moet worden. Tenslotte moet niet al het uitgaande verkeer versleuteld worden, maar alleen het verkeer dat onderdeel is van het VPN. De regels die worden opgesteld om te bepalen welke verkeer versleuteld wordt heten beveiligingsbeleid (security policies). Beveiligingssamenwerking en beveiligingsbeleid worden beiden onderhouden door de kernel en kunnen aangepast worden met programma's in userland. Maar voor dit mogelijk is, moet de kernel geschikt gemaakt worden voor ondersteuning van IPsec en het Encapsulated Security Payload (ESP) protocol. Dit kan door de volgende regel op te nemen in het kernelinstellingenbestand: options IPSEC options IPSEC_ESP Daarna dienen hercompilatie en installatie van de kernel plaats te vinden en moet de machine gereboot worden. Dit moet voor beide gateway hosts uitgevoerd worden. Het is mogelijk twee wegen te bewandelen voor het opzetten van beveiligingssamenwerking. Als het met de hand wordt opgezet dan moeten een versleutelingsalgoritme, coderingssleutels, enzovoort gekozen worden. Er kan ook een daemons gebruikt worden die het Internet Key Exchange protocol (IKE) implementeert om dit uit te voeren. Het advies is voor het laatste te kiezen. Los van andere overwegingen is het makkelijker in te stellen. Voor het wijzigen en weergeven van het beveiligingsbeleid is er &man.setkey.8;. Ter vergelijking: setkey is voor het beveiligingsbeleid van de kernel wat &man.route.8; is voor de routetabellen van de kernel. setkey kan ook de huidige beveiligingssamenwerkingen weergeven en om de vergelijking door te zetten is het in die zin verwant aan netstat -r. Er zijn een aantal daemons beschikbaar voor het bijhouden van beveiligingssamenwerking in &os;. In dit artikel wordt beschreven hoe dat met racoon gaat. racoon zit in de &os; - portscollectie in de security/ categorie en kan op de + Portscollectie in de security/ categorie en kan op de gebruikelijke manier geïnstalleerd worden. racoon moet draaien op beide gateway hosts. Op iedere host moet het IP adres van de andere kant van het VPN ingesteld worden en een geheime sleutel (die door de gebruiker zelf is gekozen en die hetzelfde moet zijn op beide gateways). De twee daemons zoeken dan contact met elkaar en stellen vast dat ze zijn wie ze beweren te zijn (door gebruik te maken van de geheime sleutel die is ingesteld). De daemons maken dan een nieuwe geheime sleutel aan en gebruiken die om het verkeer over het VPN te versleutelen. Ze wijzigen die sleutel periodiek zodat een aanvaller er niets aan heeft in het geval hij achter een van de sleutels zou komen. Dit is theoretisch trouwens vrijwel onuitvoerbaar. Tegen de tijd dat de sleutel gekraakt is, hebben de twee daemons al een nieuwe gekozen. De instellingen van racoon worden opgeslagen in ${PREFIX}/etc/racoon. Daar tref staat een instellingenbestand aan dat niet ingrijpend hoeft te wijzigen. De andere component van de instellingen van racoon die gewijzigd moet worden is de wederzijds bekende sleutel (pre-shared key). Standaard verwacht racoon dat die in ${PREFIX}/etc/racoon/psk.txt staat. Het is belangrijk op te merken dat de wederzijds bekende sleutel niet de sleutel is die gebruikt wordt om het verkeer van de VPN verbinding te versleutelen. Het is gewoon een token die de sleutelbeheerdaemons in staat stelt elkaar te vertrouwen. psk.txt bevat een regel voor iedere locatie waarmee verbinding bestaat. In dit voorbeeld zijn er twee locaties en dus bevat ieder psk.txt bestand één regel (omdat de ene kant van de VPN alleen iets te maken heeft met één andere kant). Op gateway host #1 ziet dat er als volgt uit: W.X.Y.Z secret Er staat dus het publieke IP adres van de andere kant, witruimte ;– spatie(s) of tab(s) – en een stuk tekst met de geheime sleutel. Natuurlijk dient secret niet als sleutel gebruikt te worden. Ook hier gelden de normale regels voor wachtwoorden. Op gateway host #2 ziet dat er dan zo uit: A.B.C.D secret Dus het publieke IP adres van de andere kant en dezelfde geheime sleutel. psk.txt moet in mode 0600 staan (alleen lees en schrijfrechten voor root) voordat racoon zal werken. Racoon moet draaien op beide gatewaymachines. Er moeten ook een aantal firewallregels toegevoegd worden om IKE verkeer toe te staan, dat over UDP naar de ISAKMP (Internet Security Association Key Management Protocol) poort loopt. Nogmaals: deze regels staan bij voorkeur zo vroeg mogelijk in de firewallregels. ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp Als racoon eenmaal draait, dan kan de ene gateway host vanaf de andere gepingd worden. De verbinding is dan nog steeds niet versleuteld, maar racoon stelt wel de beveiligingssamenwerking tussen de twee hosts op. Dat kan heel even duren en dat uit zich in een kleine vertraging voordat er een antwoord op de ping komt. Als de beveiligingssamenwerking tot stand is gekomen, dan kan deze getoond worden met &man.setkey.8;: setkey -D Het bovenstaande commando toont de beveiligingssamenwerkingsingsinformatie. - Dat is de ene helft van het probleem. De andere helft is + Dat is de ene helft van het probleem. De andere helft is het instellen van het beveiligingsbeleid. Voor er een zinvol beveiligingsbeleid opgesteld kan worden volgt eerst een samenvatting van wat tot nu toe is bereikt. Het volgende geldt voor beide kanten van de verbinding. Ieder IP pakket dat wordt verzonden heeft een kop die gegevens over het pakket bevat. De kop bevat het IP adres van zowel de bron als de bestemming. Zoals bekend horen private IP adressen zoals de reeks 192.168.x.y niet thuis op internet. Ze moeten eerst ingepakt worden in een ander pakket. Voor dat pakket moeten het publieke bron en bestemmingsadres op de plaats van de private adressen gezet worden. Dus als een uitgaand pakket als volgt begon: .----------------------. | Src: 192.168.1.1 | | Dst: 192.168.2.1 | | <andere kopinfo> | +----------------------+ | <pakket data> | `----------------------' Dan wordt het ingepakt in een andere pakket dat er ongeveer als volgt uitziet: .--------------------------. | Src: A.B.C.D | | Dst: W.X.Y.Z | | <andere kop info> | +--------------------------+ | .----------------------. | | | Src: 192.168.1.1 | | | | Dst: 192.168.2.1 | | | | <andere kop info> | | | +----------------------+ | | | <pakket data> | | | `----------------------' | `--------------------------' Het gif device zorgt voor het inpakken. Het pakket heeft nu een echt IP adres aan de buitenkant en het originele pakket zit ingepakt als data in het pakket dat het internet opgestuurd gaat worden. Nu moet het verkeer over het VPN natuurlijk versleuteld worden. Dat kan als volgt worden weergegeven: Als een pakket A.B.C.D verlaat met als bestemming W.X.Y.Z, versleutel het dan met de benodigde beveiligingssamenwerkingen. Als een pakket aankomt van W.X.Y.Z en het heeft A.B.C.D als bestemming, ontcijfer het dan met de benodigde beveiligingssamenwerkingen. Dat klopt bijna, maar niet helemaal. Als dit gebeurde, dan zou al het verkeer van en naar W.X.Y.Z, zelfs als dat geen deel uit zou maken van het VPN, versleuteld worden. Dat is niet wenselijk. Het correcte beleid ziet er zo uit: Als een pakket A.B.C.D verlaat en dat pakket bevat een ander pakket en als het W.X.Y.Z als bestemming heeft, versleutel het dan met de benodigde beveiligingssamenwerkingen. Als een pakket aankomt van W.X.Y.Z en het pakket bevat een ander pakket en het heeft A.B.C.D als bestemming, ontcijfer het dan met de benodigde beveiligingssamenwerkingen. Dat is een subtiele aanpassing, maar wel noodzakelijk. Beveiligingsbeleid wordt ook ingesteld met &man.setkey.8;. &man.setkey.8; biedt een instellingtaal voor het definiëren van beleid. Instructies kunnen via STDIN gegeven worden of met de optie uit een bestand komen dat de instellingen bevat. De instellingen op gateway host #1 (die het publieke IP adres A.B.C.D heeft) om al het uitgaande verkeer naar W.X.Y.Z te laten versleutelen is: spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; Deze commando's kunnen in een bestand (bv. /etc/ipsec.conf) gezet worden om uitgevoerd te worden: &prompt.root; setkey -f /etc/ipsec.conf vertelt &man.setkey.8; dat er een regel toegevoegd moet worden aan de database met het beveiligingsbeleid. De rest van de regel geeft aan op welke pakketten dit beleid van toepassing is. A.B.C.D/32 en W.X.Y.Z/32 zijn de IP adressen en netmaskers waarmee het netwerk of de hosts worden aangegeven waarop het beleid van toepassing is. In dit geval is het van toepassing op het verkeer tussen twee hosts. vertelt de kernel dat dit beleid alleen van toepassing is op pakketten waarin een ander pakket ingepakt zit. betekent dat dit beleid van toepassing is op uitgaande pakketten en betekent dat de pakketten beveiligd moeten worden. Het tweede deel geeft aan hoe een pakket versleuteld wordt. is het protocol dat gebruikt moet worden en geeft aan dat het pakket ingepakt moet worden in een IPsec pakket. Het herhaalde gebruik van A.B.C.D en W.X.Y.Z heeft te maken met het aangeven welke beveiligingssamenwerking gebruikt moet worden en als laatste is het door verplicht dat de pakketten versleuteld worden als deze regel van toepassing is. Deze regel is alleen van toepassing op uitgaande pakketten. Er moet ook nog een regel komen voor inkomende pakketten. spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; Let wel dat hier dus staat in plaats van en dat de IP adressen zijn omgedraaid. Op de andere gateway host (met een publiek IP adres W.X.Y.Z) zijn soortgelijke regels nodig. spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; Tenslotte moeten de firewalls ESP en IPENCAP pakketten naar beide kanten toestaan. Deze regels moeten op beide hosts toegevoegd worden. ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D Omdat deze regels symmetrisch zijn, kunnen ze op beide gateway hosts gebruikt worden. Uitgaande pakketten zien er nu ongeveer zo uit: .------------------------------. --------------------------. | Src: A.B.C.D | | | Dst: W.X.Y.Z | | | <andere kop info> | | Versleuteld +------------------------------+ | pakket. | .--------------------------. | -------------. | inhoud | | Src: A.B.C.D | | | | is | | Dst: W.X.Y.Z | | | | volledig | | <andere kop info> | | | |- veilig | +--------------------------+ | | Ingepakt | voor | | .----------------------. | | -. | pakket | snoopen | | | Src: 192.168.1.1 | | | | Origineel|- met echt | door derden | | | Dst: 192.168.2.1 | | | | pakket, | IP adres | | | | <andere kop info> | | | |- privaat | | | | +----------------------+ | | | IP adres | | | | | <pakket data> | | | | | | | | `----------------------' | | -' | | | `--------------------------' | -------------' | `------------------------------' --------------------------' Als ze ontvangen worden door de andere kant van het VPN dan worden ze eerst ontcijferd (met de beveiligingssamenwerking die door racoon tot stand is gebracht). Daarna komen ze de gif interface binnen die de tweede laag uitpakt zodat het binnenste pakket overblijft, dan nu naar het interne netwerk kan reizen. De beveiliging kan gecontroleerd worden met dezelfde &man.ping.8; test die eerder is uitgevoerd, door eerst aan te melden op de A.B.C.D gateway machine en het onderstaande uit te voeren: tcpdump dst host 192.168.2.1 In nog een sessie op dezelfde host kan dan het volgende commando uitgevoerd worden: ping 192.168.2.1 Nu hoort de volgende uitvoer te zien te zijn: XXX tcpdump output &man.tcpdump.1; toont nu de ESP pakketten. Als deze pakketten verder bekeken worden met de optie dan is de uitvoer onbegrijpelijk vanwege de versleuteling. Gefeliciteerd. Nu is het VPN tussen de twee locaties opgezet. Samenvatting Stel beide kernels in met: options IPSEC options IPSEC_ESP Installeer security/racoon. Wijzig ${PREFIX}/etc/racoon/psk.txt op beide gateway hosts en voeg een regel toe voor het IP adres van de host aan de andere kant en een geheime sleutel die aan beide kanten bekend is. Dit bestand hoort mode 0600 te hebben. Voeg de volgende regels toe aan /etc/rc.conf voor iedere host: ipsec_enable="YES" ipsec_file="/etc/ipsec.conf" Maak /etc/ipsec.conf op iedere host die de benodigde spdadd regels bevat. Op gateway host #1 zou dat zijn: spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; En op gateway host #2 is dat: spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; Voeg firewallregels toe om IKE, ESP en IPENCAP verkeer toe te staan naar beide hosts: ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D De voorgaande twee stappen zouden voldoende moeten zijn voor het opzetten van het VPN. Machines op ieder netwerk kunnen elkaar nu bereiken op basis van IP adressen en al het verkeer over de verbinding wordt automatisch en veilig versleuteld. Chern Lee Bijgedragen door Siebrand Mazeland Vertaald door OpenSSH OpenSSH beveiliging OpenSSH OpenSSH is een groep netwerkverbindingsprogramma's waarmee computers via het netwerk veilig benaderd kunnen worden. Het kan ingezet worden als een directe vervanger van rlogin, rsh, rcp en telnet. Daarnaast kunnen alle andere TCP/IP verbindingen veilig getunneld of geforward worden door SSH. OpenSSH versleutelt al het verkeer om afluisteren, het stelen van een verbinding en andere netwerkaanvallen effectief te voorkomen. OpenSSH wordt onderhouden door het OpenBSD project en is gebaseerd op SSH v1.2.12 met alle recente bugfixes en updates. Het is compatibel met beide protocollen SSH 1 en 2. OpenSSH zit in de basisinstallatie sinds &os; 4.0. Voordelen van Gebruik van OpenSSH Als gewoonlijk &man.telnet.1; of &man.rlogin.1; wordt gebruikt, wordt de data in platte tekst en niet versleuteld verzonden. Netwerksnuffelaars die ergens tussen de client en de server meeluisteren, kunnen een gebruikersnaam en wachtwoord stelen en zien welke gegevens er worden overgezonden tijdens een sessie. OpenSSH biedt een verscheidenheid aan authenticatie en versleutelingsmethoden die het voorgaande voorkomen. sshd Inschakelen OpenSSH inschakelen In rc.conf dient het volgende te staan: sshd_enable="YES" Hierdoor wordt &man.sshd.8; geladen, het daemonprogramma voor OpenSSH, als het systeem de volgende keer opstart. De sshd daemon kan ook direct gestart worden door sshd in te geven op de commandoregel. SSH Client OpenSSH client &man.ssh.1; werkt net zoals &man.rlogin.1;. &prompt.root; ssh user@example.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'example.com' added to the list of known hosts. user@example.com's password: ******* Het aanmelden gaat nu net zoals het zou gaan als wanneer er een sessie gestart zou worden met rlogin of telnet. SSH maakt gebruik van een systeem met vingerafdrukken als sleutels voor het vaststellen met welke server verbinding wordt gemaakt op het moment dat de client verbinding zoekt. De gebruiker krijgt alleen de eerste keer dat verbinding wordt gezocht met de server een vraag waarop yes geantwoord dient te worden. Bij volgende pogingen om aan te melden wordt de vingerafdruksleutel vergeleken met de sleutel die is opgeslagen. De SSH client alarmeert de gebruiker als de opgeslagen vingerafdruk sleutel anders is dan de sleutel die de server meldt. De vingerafdrukken worden opgeslagen in ~/.ssh/known_hosts of in ~/.ssh/known_hosts2 voor SSH v2 vingerafdrukken. OpenSSH servers staan standaard ingesteld om alleen SSH v2 connecties toe te staan. De client kan echter tussen beiden kiezen. Versie 2 is robuster en veiliger dan zijn voorloper. Het commando &man.ssh.1; kan gedwongen worden om een van de twee protocollen te gebruiken door de optie of voor respectievelijk v1 en v2 aan te geven. Veilig Kopiëren OpenSSH veilig kopiëren scp Het commando &man.scp.1; (secure copy) werkt gelijk aan - &man.rcp.1;. Het kopieert een bestand van of naar een andere + &man.rcp.1;. Het kopieert een bestand van of naar een andere machine, maar doet dat veilig. &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; Omdat de vingerafdruk al is opgeslagen voor deze host in het vorige voorbeeld, is die al geverifieerd als &man.scp.1; gebruik wordt. De argumenten die aan &man.scp.1; gegeven worden zijn vrijwel gelijk aan die voor &man.cp.1; met het bestand of de bestanden als het eerste argument en de bestemming als het tweede. Omdat het bestand over het netwerk gaat, door SSH, hebben een of meer van de bestandsargumenten de vorm . Instellen OpenSSH instellen Het instellingenbestand dat voor het hele systeem geldt voor zowel de OpenSSH daemon als client staat in de map /etc/ssh. ssh_config bevat de instellingen voor de client en sshd_config bevat ze voor de daemon. Daarnaast bieden het (standaard /usr/sbin/sshd) en rc.conf opties nog meer mogelijkheden voor instellingen. ssh-keygen In plaats van het gebruik van wachtwoorden kan &man.ssh-keygen.1; gebruikt worden om RSA sleutels te maken om een gebruiker te authenticeren: &prompt.user; ssh-keygen -t rsa1 Initializing random number generator... Generating p: .++ (distance 66) Generating q: ..............................++ (distance 498) Computing the keys... Key generation complete. Enter file in which to save the key (/home/user/.ssh/identity): Enter passphrase: Enter the same passphrase again: Your identification has been saved in /home/user/.ssh/identity. ... &man.ssh-keygen.1; maakt een publiek en privaat sleutelpaar aan dat gebruikt kan worden voor authenticatie. De private sleutel staat opgeslagen in ~/.ssh/identity en de publieke sleutel staat in ~/.ssh/identity.pub. De publieke sleutel moet in ~/.ssh/authorized_keys van de andere machine staan om dit te laten werken. Nu is het mogelijk een verbinding te maken met een andere machine die gebaseerd is op RSA authenticatie in plaats van op wachtwoorden. De optie maakt RSA sleutels voor versie 1 van het SSH protocol. Als gebruik van versie 2 gewenst is, dan het commando ssh-keygen -t rsa gebruikt te worden. Als er een wachtwoordzin is gebruikt bij &man.ssh-keygen.1; dan wordt de gebruiker iedere keer dat de private sleutel wordt gebruikt een wachtwoord gevraagd. Het is mogelijk een SSH protocol versie 2 DSA sleutel te maken voor hetzelfde doel met het commando ssh-keygen -t dsa. Hiermee wordt een publiek/privaat DSA sleutelpaar gemaakt dat alleen gebruikt kan worden in SSH protocol versie 2 sessies. De publieke sleutel staat in ~/.ssh/id_dsa.pub en de private sleutel staat in ~/.ssh/id_dsa. Publieke DSA staan ook in ~/.ssh/authorized_keys op de andere machine. &man.ssh-agent.1; en &man.ssh-add.1; zijn hulpprogramma's die gebruikt worden om meerdere met wachtwoorden beschermde private sleutels te beheren. Opties en bestandslocaties kunnen afhankelijk zijn van de gebruikte OpenSSH versie op een systeem. Raadpleeg de &man.ssh-keygen.1; handboekpagina voor de correcte gegevens. SSH Tunnels OpenSSH tunnels OpenSSH kan een tunnel maken waarin een ander protocol ingepakt kan worden zodat er een versleutelde sessie ontstaat. Het volgende commando geeft &man.ssh.1; aan dat er een tunnel voor telnet gemaakt moet worden: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; Aan het ssh commando worden de volgende opties meegegeven: Dit dwingt ssh om versie 2 van het protocol te gebruiken. Gebruik van deze optie wordt afgeraden als er verbinding wordt gemaakt met oudere SSH servers. Dit geeft aan dat er geen commando volgt, maar dat er een tunnel opgezet moet worden. Als deze optie niet aanwezig was, zou ssh een normale sessie starten. Dit dwingt ssh om in de achtergrond te draaien. Dit geeft aan dat de lokaal een tunnel wordt gemaakt in de vorm lokale_poort:netwerk_host:netwerk_poort. Wijst naar een gebruiker op de SSH server op het netwerk. Een SSH tunnel werkt doordat een luistersocket wordt gemaakt op localhost op de aangegeven poort. Die stuurt dan iedere ontvangen verbinding op de lokale host/poort via de SSH verbinding door naar de aangegeven host en poort op het netwerk. In het voorbeeld wordt poort 5023 op localhost doorgestuurd naar poort 23 op localhost van de machine op het netwerk. Omdat 23 telnet is, zou dit een veilige telnet verbinding opleveren door een SSH tunnel. Dit kan gebruikt worden om ieder willekeurig onveilig TCP protocol in te pakken als SMTP, POP3, FTP, etc. SSH Gebruiken om een Veilige Tunnel te Maken voor SMTP &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP Dit kan samen met een &man.ssh-keygen.1; en extra gebruikersaccounts gebruikt worden om een min of meer naadloze en eenvoudige SSH tunnelomgeving te maken. In plaats van wachtwoorden kunnen sleutels gebruikt worden en de tunnels kunnen in de omgeving van een aparte gebruiker draaien. Praktische Voorbeelden van een SSH Tunnel Veilige Toegang tot een POP3 Server Op het werk staat een SSH server die verbindingen van buitenaf toestaat. Op hetzelfde netwerk op kantoor staat een mailserver waarop POP3 draait. Het netwerk of het netwerkpad tussen de locatie op internet en kantoor is wellicht niet helemaal te vertrouwen. Om deze reden dient de mailserver op een veilige manier benaderd te worden. De oplossing is een SSH verbinding opzetten naar de SSH server op kantoor en dan door de tunnel heen een verbinding opzetten met de mailserver. &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ****** Als de tunnel eenmaal draait, dan kan de mailclient naar localhost poort 2110 gewezen worden. Alle verbinding naar die poort worden veilig doorgestuurd door de tunnel naar mail.example.com. Een Draconische Firewall Omzeilen Sommige netwerkbeheerders stellen draconische firewallregels op en filteren niet alleen inkomende verbindingen, maar ook uitgaande. Meestal mag dan alleen maar verbinding gemaakt worden met andere machines op poorten 22 en 80 voor SSH en websurfen. Soms wil een gebruiker dan toch toegang krijgen tot andere (wellicht niet netwerk-gerelateerd) diensten, zoals een Ogg Vorbis server om muziek te streamen. Als die Ogg Vorbis server streamt op een andere poort dan 22 of 80, dan kan deze niet bereikt worden. De oplossing ligt in het opzetten van een SSH verbinding naar een machine buiten de firewall en die tunnel te gebruiken om bij de Ogg Vorbis server te komen. &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* De streamingclient kan nu gewezen worden naar localhost poort 8888 vanwaar er wordt doorverwezen naar music.example.com poort 8000 en zo wordt de firewall succesvol ontwerken. Meer Lezen OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.sshd.8; &man.sftp-server.8; Tom Rhodes Bijgedragen door Siebrand Mazeland Vertaald door ACL Bestandssysteem Toegangscontrolelijsten In combinatie met verbeteringen als snapshots, bieden &os; 5.0 en volgende versies de veiligheid van Bestandssysteem Toegangscontrolelijsten (Access Control Lists, ACLs). Met Toegangscontrolelijsten wordt het standaard &unix; rechtenmodel uitgebreid op een zeer verenigbare (&posix;.1e) manier. Deze methodes stellen een beheerder in staat om gebruik te maken en voordeel te halen uit een geraffineerder beveiligingsmodel. Om ondersteuning voor ACLs voor bestandssystemen in te schakelen dient het volgende in de kernel gecompileerd te worden: options UFS_ACL Als deze optie niet aanwezig is, dan wordt er een waarschuwing weergegeven als er wordt geprobeerd een bestandssysteem te mounten dat gebruik maakt van ACLs. Deze optie is al geactiveerd in de GENERIC kernel. ACLs zijn afhankelijk van uitgebreide attributen die zijn ingeschakeld op het bestandssysteem. Uitgebreide attributen worden standaard ondersteund in het volgende generatie &unix; bestandssysteem UFS2. Er is meer administratieve overhead nodig om uitgebreide attributen in te stellen op UFS1 dan op UFS2. De prestaties van uitgebreide attributen zijn op UFS2 ook veel beter. Daarom wordt UFS2 ook meestal aangeraden boven UFS1 bij het gebruik van toegangscontrolelijsten. ACLs worden ingeschakeld door de - beheersvlag op het moment van mounten. Dit + beheersvlag op het moment van mounten. Dit kan ook in /etc/fstab staan. De vlag op het moment van mounten kan ook automatisch gezet worden op een persistente wijze met &man.tunefs.8; door een superblok in de bestandssysteemkop te wijzigen. In het algemeen wordt de voorkeur gegeven aan de vlag in het superblok om een aantal redenen: De ACLs vlag op het moment van mounten kan niet gewijzigd worden bij opnieuw mounten (&man.mount.8; ), maar alleen door een volledige &man.umount.8; en een verse &man.mount.8;. Dit betekent dat ACLs niet ingeschakeld kunnen worden op root bestandssysteem na het booten. Het betekent ook dat de aard van een bestandssysteem niet veranderd kan worden als het eenmaal in gebruik is. Het inschakelen van de superblok vlag zorgt ervoor dat het bestandssysteem altijd wordt gemount met de ACLs ingeschakeld, zelfs als het niet in fstab staat of als de apparaten van plaats veranderen. Hiermee wordt voorkomen dat het bestandssysteem wordt gebruikt zonder dat ACLs ingeschakeld zijn, wat ervoor zou kunnen zorgen dat ACLs onjuist worden toegepast wat weer kan zorgen voor beveiligingsproblemen. Wellicht wordt het mogelijk om de ACLs via de vlag in te schakelen zonder een compleet verse &man.mount.8;, maar de ontwikkelaars vinden het wenselijk om het per ongeluk zonder ACLs mounten te ontmoedigen, omdat er bijzonder vervelende gevolgen kunnen zijn als ACLs worden ingeschakeld, daarna worden uitgezet en weer worden ingeschakeld zonder dat de uitgebreide attributen worden geschoond. In het algemeen geldt dat als ACLs eenmaal zijn ingeschakeld voor een bestandssysteem, ze niet meer uitgeschakeld moeten worden, omdat de resulterende bestandsbescherming wellicht niet compatibel is met dat wat gebruikers van het systeem nodig hebben en het opnieuw aanzetten van ACLs kan leiden tot het opnieuw koppelen van voorheen bestaande ACLs aan bestanden waarvoor de toegangsrechten sindsdien zijn aangepast, wat kan leiden tot onverwachte situaties. Bestandssystemen waarvoor ACLs zijn ingeschakeld worden weergegeven met een + (plus) teken als de toegangsrechten worden bekeken: drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html Hierboven is te zien dat mappen directory1, directory2 en directory3 allemaal gebruik maken van ACLs. De map public_html doet dat niet. Gebruik Maken van <acronym>ACL</acronym>s De ACLs van het bestandssysteem kunnen bekeken worden met het hulpprogramma &man.getfacl.1;. Om de ACL op het bestand test te bekijken zou het volgende commando nodig zijn: &prompt.user; getfacl test #file:test #owner:1001 #group:1001 user::rw- group::r-- other::r-- Om de ACL op dit bestand te wijzigen wordt het hulpprogramma &man.setfacl.1; als volgt gebruikt: &prompt.user; setfacl -k test De vlag verwijdert alle bestaande ACLs van een bestand of bestandssysteem. De methode die de voorkeur geniet is gebruiken omdat die optie de basisvelden die nodig zijn voor het laten werken van de ACLs laat staan. &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- test Bij het commando hierboven, werd de optie gebruikt om de standaard ACL aan te passen. Omdat er geen voorgedefinieerde instellingen waren, die waren verwijderd door het commando daarvoor, werden nu de standaardinstellingen hersteld en de rechten die werden aangegeven toegevoegd. Let op dat bij het toevoegen van een gebruiker of een groep die niet bekend is op het systeem een foutmelding Invalid argument wordt geschreven naar stdout. Tom Rhodes Bijgedragen door Siebrand Mazeland Vertaald door &os; Beveiligingswaarschuwingen &os; Beveiligingswaarschuwingen Net als veel andere kwalitatief goede productiebesturingssystemen publiceert &os; Beveiligingswaarschuwingen. Deze waarschuwingen worden meestal pas naar de beveiligingslijst gemaild en gedocumenteerd in de Errata als de van toepassing zijnde releases gepatcht zijn. In deze paragraaf wordt toegelicht wat een waarschuwing is, hoe die te begrijpen en welke maatregelen er genomen moeten worden om een systeem bij te werken. Hoe Ziet een Waarschuwing eruit? De &os; beveiligingswaarschuwingen zien er ongeveer uit als die hieronder die van de &a.security-notifications.name; mailinglijst komt. ============================================================================= &os;-SA-XX:XX.UTIL Security Advisory The &os; Project Topic: denial of service due to some problem Category: core Module: sys Announced: 2003-09-23 Credits: Person@EMAIL-ADDRESS Affects: All releases of &os; &os; 4-STABLE prior to the correction date Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) 2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15) 2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8) 2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18) 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) &os; only: NO For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://www.FreeBSD.org/security/. I. Background II. Problem Description III. Impact IV. Workaround V. Solution VI. Correction details VII. References Het veld Topic geeft aan wat precies het probleem is. Het is eigenlijk een inleiding op de beveiligingswaarschuwing en geeft aan welke programma kwetsbaar is. Het veld Category geeft aan welk onderdeel van het systeem kwetsbaar is. Dat kan een van de onderdelen core, contrib of ports zijn. De categorie core betekent dat de een kerncomponent van het &os; besturingssysteem kwetsbaar is. De categorie contrib betekent dat software die toegevoegd is aan het &os; Project kwetsbaar is, zoals sendmail. Tenslotte geeft de categorie ports aan dat een optionele - component uit de portscollectie kwetsbaar is. + component uit de Portscollectie kwetsbaar is. Het veld Module geeft aan waar de component zich bevindt, bijvoorbeeld sys. In dit voorbeeld wordt het duidelijk dat de module sys kwetsbaar is. Hier gaat het dus om een kwetsbaar component die gebruikt wordt in de kernel. Het veld Announced geeft aan wanneer de beveiligingswaarschuwing gepubliceerd of aangekondigd is. Dit betekent dat het beveiligingsteam heeft bevestigd dat het probleem bestaat en dat er een patch is gecommit in het depot met de broncode van &os;. In het veld Credits wordt iemand of een organisatie bedankt die de kwetsbaarheid heeft ontdekt en gerapporteerd. Het veld Affects geeft aan welke releases van &os; door deze kwetsbaarheid worden getroffen. Voor de kernel kan snel gekeken worden naar de uitvoer van ident voor de betreffende bestanden om te bepalen welke revisie ze hebben. Voor ports is het versienummer te zien in /var/db/pkg. Als het systeem niet gelijk op loopt met het &os; CVS depot en dagelijks herbouwd wordt, dan is de kans groot dat het systeem kwetsbaar is. Het veld Corrected geeft de datum, tijd en tijdzone aan en de release die is aangepast. Het veld &os; only geeft aan of deze kwetsbaarheid alleen betrekking heeft op &os; of dat hij ook betrekking heeft op andere besturingssystemen. Het veld Background geeft meer informatie over wat er precies aan de hand is. Meestal staat hier waarom het programma aanwezig is in &os;, waar het voor gebruikt wordt en hoe het programma is ontstaan. Het veld Problem Description geeft gedetailleerde toelichting op het beveiligingsprobleem. Hier kan informatie bij staat over programmacode die fouten bevat of zelfs hoe het programma gebruikt kan worden om een beveiligingsgat te openen. Het veld Impact beschrijft welke invloed het probleem kan hebben op het systeem. Dit kan bijvoorbeeld een ontzegging van dienst aanval zijn, gebruikers extra rechten geven of het verkrijgen van supergebruiker toegang voor de aanvaller zijn. Het veld Workaround geeft aan hoe het mogelijk is het probleem te omzeilen (workaround) in het geval systeembeheerders niet in staat zijn om het systeem bij te werken. Dit zou te maken kunnen hebben met de tijd, beschikbaarheid van het netwerk en een hele lijst met andere redenen. Hoe dan ook, beveiliging dient serieus genomen te worden en een systeem dat kwetsbaar is moet bijgewerkt worden of het gat in de beveiliging moet gedicht worden met de alternatieve oplossing. Het veld Solution geeft instructies over hoe een systeem aangepast kan worden. Dit is een werkinstructie die getest en gecontroleerd is om een systeem aan te passen en weer veilig werkend te krijgen. In het veld Correction Details staan de CVS takken of releasenamen, met de punten veranderd in een liggend streepje. Er staat ook welke revisienummer de aangetaste bestanden binnen een tak hebben. In het veld References wordt gewoonlijk verwezen naar andere bronnen. Dit kunnen URLs, boeken, mailinglijsten en nieuwsgroepen zijn.