Hoofdstuk 15. Beveiliging

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 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.

Natuurlijk moet een systeembeheerder de mogelijkheid hebben om root te worden. Daarvoor kunnen een paar gaatjes geprikt worden. Maar dan moet ervoor gezorgd worden dat er voor deze gaatjes extra aanmelden met een wachtwoord nodig is. Eén manier om root toegankelijk te maken is door het toevoegen van de juiste medewerkersaccounts aan de wheel groep (in /etc/group). De medewerkers die lid zijn van de groep wheel mogen su-en naar root. Maak medewerkers nooit "native" lid van de groep wheel door ze in de groep wheel te plaatsen in /etc/group. Medewerkersaccounts horen lid te zijn van de groep staff en horen dan pas toegevoegd te worden aan de groep wheel in het bestand /etc/group. Alleen medewerkers die ook echt toegang tot root nodig hebben horen in de groep wheel geplaatst te worden. Het is ook mogelijk, door een autenticatiemethode als Kerberos te gebruiken, om het bestand .k5login van Kerberos in de root account te gebruiken om een ksu(1) naar root toe te staan zonder ook maar iemand lid te maken van de groep wheel. Dit is misschien wel een betere oplossing, omdat het wheel-mechanisme het nog steeds mogelijk maakt voor een inbreker root te breken als de inbreker een wachtwoordbestand te pakken heeft gekregen en toegang kan krijgen tot één van de medewerkersaccounts. Hoewel het instellen van het wheel-mechanisme beter is dan niets, is het niet per se de meest veilige optie.

Om een account volledig op slot te zetten, dient het commando pw(8) gebruikt te worden:

Dit voorkomt dat de gebruiker zich aanmeldt via enig mechanisme, inclusief ssh(1).

Een andere manier om toegang tot accounts te blokkeren is om het versleutelde wachtwoord door een enkel “*”-karakter te vervangen. Dit karakter zal nooit overeenkomen met het versleutelde wachtwoord en dus gebruikerstoegang blokkeren. Het volgende medewerkersaccount bijvoorbeeld:

zou veranderd moeten worden in:

Dit voorkomt dat de gebruiker foobar zich aanmeldt met conventionele methoden. Deze methode om toegang te beperken werkt niet op sites die Kerberos gebruiken of in situaties waarin de gebruiker met ssh(1) sleutels heeft geïnstalleerd.

Deze beveiligingsmechanismen hebben ook als uitgangspunt dat vanaf een zwaarder beveiligde machine wordt aangemeld op een minder beveiligd systeem. Als een hoofdserver bijvoorbeeld allerlei servers draait, zou het werkstation er geen moeten draaien. Om een werkstation redelijk veilig te laten zijn, dienen er zo min mogelijk servers op te draaien, bij voorkeur zelfs geen en er zou een schermbeveiliging met wachtwoordbeveiliging op moeten draaien. Maar als een aanvaller fysieke toegang heeft tot een werkstation, dan kan hij elke beveiliging die erop is aangebracht omzeilen. Dit probleem dient echt overwogen te worden, net als het feit dat de meeste aanvallen van een afstand plaatsvinden, via het netwerk, door mensen die geen fysieke toegang hebben tot werkstations of servers.

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).

Een voorzichtige systeembeheerder draait alleen die servers die nodig zijn, niets meer, niets minder. Bedenk dat servers van derde partijen vaak de meeste neiging hebben tot het vertonen van bugs. Zo staat bijvoorbeeld het draaien van een oude versie van imapd of popper gelijk aan het weggeven van de root account aan de hele wereld. Draai nooit een server die niet zorgvuldig is onderzocht. Veel servers hoeven niet te draaien als root. Zo kunnen de ntalk, comsat en finger daemons bijvoorbeeld draaien in speciale gebruikerszandbakken ("sandboxes"). Een zandbak is niet perfect, tenzij er heel veel moeite gedaan wordt, maar de meerlagenbenadering blijft bestaan: als iemand via een server die in een zandbak draait weet in te breken, dan moeten ze eerst nog uit de zandbak komen. Hoe groter het aantal lagen is waar een inbreker doorheen moet, hoe kleiner de kans op succes is. root gaten zijn historisch gezien aanwezig geweest in vrijwel iedere server die ooit als root gedraaid heeft, inclusief de basisservers van een systeem. Op een machine waarop mensen alleen aanmelden via sshd en nooit via telnetd of rshd of rlogind dienen die servers uitgeschakeld te worden!

FreeBSD draait ntalkd, comsat en finger tegenwoordig standaard in een zandbak. Een ander programma dat misschien beter in een zandbak kan draaien is 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.

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 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 gegevensstroom genereren die ervoor zorgt dat de terminal van de gebruiker een commando echot, dat dan wordt uitgevoerd door die gebruiker.

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 versleuteld wachtwoordbestand.

De enige echte oplossing is zoveel mogelijk wachtwoorden wegsterren 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).

Als een aanvaller toegang krijgt tot root dan kan hij ongeveer alles, maar er zijn een paar slimmigheidjes. Zo hebben bijvoorbeeld de meeste moderne kernels een ingebouwd pakketsnuffelstuurprogramma ("packet sniffing"). Bij FreeBSD is dat het bpf apparaat. Een inbreker zal in het algemeen proberen een pakketsnuffelaar te draaien op een gecompromitteerde machine. De inbreker hoeft deze mogelijkheid niet te hebben en bij de meeste systemen is het niet verplicht het bpf apparaat mee te compileren.

Maar zelfs als het bpf apparaat is uitgeschakeld, dan zijn er nog /dev/mem en /dev/kmem. De inbreker kan namelijk nog schrijven naar ruwe schrijfapparaten. En er is ook nog een optie in de kernel die modulelader ("module loader") heet, kldload(8). Een ondernemende inbreker kan een KLD-module gebruiken om zijn eigen bpf-apparaat of een ander snuffelapparaat te installeren in een draaiende kernel. Om deze problemen te voorkomen, moet de kernel op een hoger veiligheidsniveau draaien, ten minste securelevel 1.

Het veiligheidsniveau van de kernel kan op een aantal manieren worden ingesteld. De eenvoudigste manier om het veiligheidsniveau van een draaiende kernel te verhogen is met sysctl op de kernelvariabele kern.securelevel:

Standaard start de kernel van FreeBSD op met een veiligheidsniveau van -1. Het veiligheidsniveau blijft -1 tenzij het is veranderd, òfwel door de beheerder òfwel door init(8) vanwege een instelling in de opstartscripts. Het veiligheidsniveau kan tijdens het opstarten van het systeem verhoogd worden door de variabele kern_securelevel_enable op YES te zetten in het bestand /etc/rc.conf, en de waarde van de variabele kern_securelevel op het gewenste veiligheidsniveau in te stellen.

Het standaard veiligheidsniveau van een FreeBSD-systeem direct nadat de opstartscripts zijn uitgevoerd is -1. Dit wordt "onveilige modus" genoemd omdat de onveranderlijke bestandsvlag uitgezet kan worden, er van/naar alle apparaten mag worden gelezen en geschreven, enzovoorts.

Als eenmaal het veiligheidsniveau op 1 of een hogere waarde is ingesteld, worden de alleen-toevoegen en onveranderlijke bestanden gehonoreerd, deze kunnen niet worden uitgezet, en wordt toegang tot rauwe apparaten ontzegd. Hogere niveaus beperken nog meer bewerkingen. Lees, voor een volledige beschrijving van het effect van de verschillende veiligheidsniveaus, de handleidingpagina security(7).

Als het veiligheidsniveau van de kernel naar 1 of hoger wordt verhoogd, kan het nuttig zijn om de vlag schg aan te zetten voor kritieke opstartprogramma’s, mappen, en scriptbestanden (i.e., alles dat gedraaid wordt tot het punt waar het veiligheidsniveau wordt ingesteld). Dit kan overdreven zijn, en het bijwerken van het systeem is veel moeilijker wanneer het op een hoog veiligheidsniveau werkt. Een minder beperkend compromis is om het systeem op een hoger veiligheidsniveau te draaien maar het aanzetten van de vlag schg voor elk systeembestand en -map onder de zon over te slaan. Een andere mogelijkheid is om / en /usr simpelweg als alleen-lezen aan te koppelen. Het dient opgemerkt te worden dat het te draconisch zijn over wat is toegestaan het belangrijke detecteren van een inbraak kan verhinderen.

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 beveiliging) als een mogelijke inbraak niet gedetecteerd kan worden. Een belangrijk doel van het meerlagenmodel is het vertragen van een aanvaller, nog meer dan hem te stoppen, om hem op heterdaad te kunnen betrappen.

De beste manier om te zoeken naar een inbraak is zoeken naar gewijzigde, ontbrekende of onverwachte bestanden. De beste manier om te zoeken naar gewijzigde bestanden is vanaf een ander (vaak gecentraliseerd) systeem met beperkte toegang. Met zelfgeschreven scripts op dat extra beveiligde systeem met beperkte toegang is een beheerder vrijwel onzichtbaar voor mogelijke aanvallers en dat is belangrijk. Om het nut te maximaliseren moeten in het algemeen dat systeem met beperkte toegang best veel rechten gegeven worden op de andere machines in het netwerk, vaak via een alleen-lezen NFS-export van de andere machines naar het systeem met beperkte toegang of door 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 zichtbare methode. Hierdoor kunnen de bestandssystemen op alle cliëntmachines vrijwel ongezien gemonitord worden. Als de server met beperkte toegang verbonden is met de cliëntmachines via een switch, dan is de NFS-methode vaak de beste keus. Als de server met beperkte toegang met de andere machines is verbonden via een hub of door meerdere routers, dan is de NFS-methode wellicht niet veilig genoeg (vanuit een netwerk standpunt) en kan beter ssh gebruikt worden, ondanks de audit-sporen die ssh achterlaat.

Als de machine met beperkte toegang eenmaal minstens leestoegang heeft tot een cliëntsysteem dat het moet gaan monitoren, dan moeten scripts gemaakt worden om dat monitoren ook echt uit te voeren. Uitgaande van een NFS-koppeling, kunnen de scripts gebruik maken van eenvoudige systeem hulpprogramma’s als find(1) en md5(1). We adviseren minstens één keer per dag een md5 te maken van alle bestanden op de cliëntmachine en van instellingenbestanden als in /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 cliënt verplaatst worden om ze uit te voeren, waardoor ze zichtbaar worden. Voor de veiligheid dienen ook de binaire bestanden die het script gebruikt, zoals find(1), gekopieerd te worden. De ssh-cliënt op de cliënt zou al gecompromitteerd kunnen zijn. Het is misschien noodzakelijk ssh te gebruiken over onveilige verbindingen, maar dat maakt alles een stuk lastiger.

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 schijfruimte hebben, dan kan het te lang duren om alle bestanden op deze partitie te controleren. In dat geval is het verstandig de koppelvlaggen zo in te stellen dat suid-binaire bestanden op die partities niet zijn toegestaan. Zie daarvoor de optie nosuid (zie mount(8)). Die partities moeten wel toch nog minstens eens per week doorzocht worden, omdat het doel van deze beveiligingslaag het ontdekken van een inbraakpoging is, of die nu succesvol is of niet.

Procesverantwoording (zie 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 zal proberen zijn sporen uit te wissen en logboekbestanden zijn van groot belang voor een systeembeheerder als het gaat om uitzoeken wanneer en hoe er is ingebroken. Een manier om logboekbestanden veilig te stellen is door het systeemconsole via een seriële poort aan te sluiten op een veilige machine en zo informatie te verzamelen.

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.

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 door:

Een veelvoorkomende DoS-aanval is om een server aan te vallen door het zoveel kindprocessen aan te laten maken dat het hostsysteem uiteindelijk geen bestandsdescriptors, geheugen enzovoort meer heeft en het dan opgeeft. inetd (zie 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 -c, -C en -R opties te besteden. Aanvallen met gefingeerde IP adressen omzeilen de -C 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 -OMaxDaemonChildren die veel beter blijkt te werken dan het gebruik van de opties van Sendmail waarmee de werklast gelimiteerd kan worden. De parameter MaxDaemonChildren moet zodanig ingesteld worden dat als sendmail start; deze 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 wachtrijmodus (-ODeliveryMode=queued) 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 -q1m in te stellen, maar dan is een redelijke instelling van MaxDaemonChildren van belang om die Sendmail te beschermen tegen trapsgewijze fouten.

Syslogd kan direct aangevallen worden en het is sterk aan te raden de -s optie te gebruiken waar dat ook maar mogelijk is en anders de -a 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, dat wil zeggen "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. FreeBSD biedt ook de mogelijkheid een reeks poortnummers die gebruikt worden voor dynamische verbindingen in te stellen via de verscheidene net.inet.ip.portrange``sysctl`s (`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).

Een andere veelvoorkomende DoS-aanval is de springplankaanval: een server zo aanvallen dat de respons van die server de server zelf, het lokale netwerk of een andere 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-pakketten 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 springplankaanval is er een tegen het ICMP-foutmeldingssysteem. Door een pakket te maken waarop een ICMP-foutmelding komt, kan een aanvaller de inkomende verbinding van een server verzadigen en de uitgaande verbinding laten verzadigen met ICMP-foutmeldingen. Dit type aanval kan een server ook laten crashen door te zorgen dat het geheugen ervan vol zit, zeker als de server de ICMP-antwoorden niet zo snel kwijt kan als dat het ze genereert. Gebruik de sysctl-variabele net.inet.icmp.icmplim om deze aanvallen te beperken. De laatste belangrijke klasse springplankaanvallen hangt samen met een aantal interne diensten van inetd zoals de UDP-echodienst. Een aanvaller fingeert eenvoudigweg een UDP-pakket met als bronadres de echopoort van Server A en als bestemming de echopoort van Server B, waar Server A en B allebei op een LAN staan. Die twee servers gaan dat pakket dan heen en weer kaatsen. Een aanvaller kan beide servers overbelasten door een aantal van deze pakketten te injecteren. Soortgelijke problemen kunnen ontstaan met de poort chargen. Een competente systeembeheerder zal al deze interne inetd testdiensten 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 gecachede 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 gecachede routetabel te groot is geworden, dan wordt rtexpire dynamisch verkleind, maar deze waarde wordt nooit lager dan rtminexpire. Er zijn twee problemen:

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 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.

Er zijn een aantal aandachtspunten die in acht genomen moeten worden als Kerberos of ssh gebruikt worden. Kerberos 5 is een prima autenticatieprotocol, maar er zitten bugs in de Kerberos-versies van telnet en rlogin waardoor ze niet geschikt zijn voor binair verkeer. Kerberos codeert standaard de sessie niet, tenzij de optie -x 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 `root`toegang heeft op de onveilige machine, dan kan hij die poort gebruiken om toegang te krijgen tot alle machines waar de sleutels van de gebruiker toegang toe geven.

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.

Op dit moment ondersteunt de bibliotheek DES, MD5, Blowfish, SHA256 en SHA512 hashfuncties. Standaard gebruikt FreeBSD 9.1 en nieuwer SHA512 om wachtwoorden te coderen. Oudere versies gebruiken standaard MD5.

Het is vrij makkelijk om uit te vinden welke coderingsmethode FreeBSD 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-wachtwoordstrings 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. Zowel SHA256 als SHA512 beginnen met de tekens $6$.

Het wachtwoordformaat voor nieuwe wachtwoorden wordt ingesteld met de passwd_format aanmeldinstelling in /etc/login.conf waar des, md5, blf, sha256 of sha512 in mag staan. Zie de login.conf(5) handleiding voor meer informatie over aanmeldinstellingen.

Gebruik het commando opiepasswd om OPIE voor de eerste keer te initialiseren:

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 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.

Om een wachtwoord te initialiseren of te wijzigen over een onveilige verbinding, moet er al ergens een veilige verbinding bestaan waar de gebruiker opiekey kan uitvoeren. Dit kan een shellprompt zijn op een machine die vertrouwd wordt. De gebruiker moet ook een iteratieteller verzinnen (100 is wellicht een prima getal) en een eigen zaad bedenken of er een laten fabriceren. Over de onveilige verbinding (naar de machine die de gebruiker wil initialiseren) wordt het commando opiepasswd gebruikt:

Druk op Return om het standaardzaad te accepteren. Voor een toegangswachtwoord wordt ingevoerd, dient eerst gewisseld te worden naar de veilige verbinding en dienen dezelfde parameters ingegeven te worden:

In de onveilige verbinding wordt nu het eenmalige wachtwoord in het relevante programma gekopieerd.

Als OPIE eenmaal is ingesteld staat er bij het aanmelden iets als het volgende:

NB: de OPIE-prompt heeft een handige 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.

Nu moet het eenmalige wachtwoord gemaakt worden om het aanmeldprompt mee te antwoorden. Dit moet gedaan worden op een vertrouwd systeem waarop opiekey beschikbaar is. Er zijn ook versies voor MS-DOS®, Windows® en Mac OS®. Voor het commando 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 zich wil aanmelden.

Op het vertrouwde systeem:

Nu het eenmalige wachtwoord er is, kan het aanmelden doorgang vinden.

Soms moet een gebruiker ergens naar toe gaan waar er geen toegang is tot een vertrouwde machine of een beveiligde verbinding. In dat geval is het mogelijk om met het commando opiekey een aantal eenmalige wachtwoorden te maken om uit te printen en mee te nemen:

Met -n 5 worden vijf opeenvolgende sleutels aangevraagd, 30 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.

Met OPIE kan paal en perk gesteld worden aan het gebruik van UNIX® wachtwoorden op basis van het IP-adres van een aanmeldsessie. Dat kan met het bestand /etc/opieaccess dat standaard aanwezig is. Bij opieaccess(5) staat meer informatie over dit bestand en welke beveiligingsoverwegingen bestaan bij het gebruik.

Hieronder een voorbeeld voor een opieaccess bestand:

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.

De enige voorwaarde voor het gebruiken van TCP Wrappers in FreeBSD is ervoor te zorgen dat de server inetd gestart wordt vanuit rc.conf met de optie -Ww; dit is de standaardinstelling. Er wordt vanuit gegaan dat /etc/hosts.allow juist is ingesteld, maar als dat niet zo is, dan zal syslogd(8) dat melden.

In de meest eenvoudige instelling worden verbindingen naar daemons toegestaan of geweigerd afhankelijk van de opties in /etc/hosts.allow. De standaardinstelling in FreeBSD 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:

Nadat deze regel is toegevoegd moet inetd herstart worden door gebruik te maken van service(8):

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 email 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.

Kerberos is ontworpen door MIT als oplossing voor netwerkbeveiligingsproblemen. Het Kerberos protocol gebruikt sterke codering zodat een cliënt 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 FreeBSD.

Om het grootst mogelijke publiek te bereiken gaan deze instructies ervan uit dat de Heimdal distributie die bij FreeBSD zit wordt gebruikt.

Het Sleutel Distributie Centrum (KDC, voluit "Key Distribution Center") is de gecentraliseerde autenticatiedienst 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):

Daarna wordt het Kerberos-instellingenbestand /etc/krb5.conf aangemaakt:

/etc/krb5.conf gaat ervan uit dat de KDC de volledig gekwalificeerde hostnaam kerberos.example.org heeft. Als de KDC een andere hostnaam heeft, moet er nog een CNAME (alias) toegevoegd aan de zonefile.

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:

Nu kan de KDC dienst gestart worden met service kerberos start en service 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 (gebruiker) die zojuist is aangemaakt vanaf de commandoregel van het KDC zelf:

Het ticket kan worden ingenomen wanneer u klaar bent:

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 scp(1), of fysiek via een floppy) naar de cliëntcomputer 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, bijvoorbeeld 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, ssh(1) of Kerberos 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:

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:

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 inetd(8) te herstarten met service inetd restart:

Het belangrijkste is dat de typering -a (van autenticatie) op user staat. Meer details zijn in telnetd(8) te vinden.

Het opzetten van een cliëntcomputer is eigenlijk kinderlijk eenvoudig. Wat betreft de Kerberos instelling is alleen het Kerberos instellingenbestand (/etc/krb5.conf) nodig. Dat kan eenvoudigweg naar de cliëntcomputer gekopieerd worden vanaf de KDC.

Test de cliënt met kinit, klist en kdestroy vanaf de cliënt 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 cliënt of de KDC.

Bij het testen van een applicatie als telnet kan het beste een pakketsnuffelaar (bijvoorbeeld 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 gegevensstroom versleuteld (vergelijkbaar met ssh).

Er worden standaard ook andere Kerberos applicaties op de cliënt geïnstalleerd. Hier komt de "minimalistische" natuur van de basisinstallatie van Heimdal boven drijven: telnet is de enige dienst waarvoor Kerberos geactiveerd is.

De port Heimdal voegt een aantal ontbrekende cliëntapplicaties 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 cliëntapplicaties.

Voor gebruikers binnen een wereld wijst hun Kerberos principal (bv. tillman@EXAMPLE.ORG) gewoonlijk naar een lokale gebruikersaccount (bijvoorbeeld een lokale account met de naam tillman). Voor cliëntapplicaties 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:

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 handleidingen voor deze commando’s te lezen. Let op dat de ksu handleiding .k5users behandelt.

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 KDCMIT 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 cliëntapplicaties kunnen ook commandoregelopties gebruiken die een beetje verschillen, maar waarmee wel hetzelfde wordt bereikt. We raden aan de instructies op de MITKerberos website (http://web.mit.edu/Kerberos/www/) 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.

Het bestand rc.conf moet ook gewijzigd worden zodat het de volgende configuratie bevat:

Dit is gedaan omdat de applicaties voor MIT-Kerberos binairen in de hiërarchie /usr/local installeren.

Voor het maken van certificaten is het volgende commando beschikbaar:

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 versleutelingsalgoritmes, etc, beschikbaar. Een volledige lijst is na te lezen in de handleiding van openssl(1).

Er horen nu twee bestanden te staan in de map waarin het voorgaande commando is uitgevoerd. Het certificaatverzoek, req.pem, kan naar een certificaat autoriteit gestuurd worden die de bijgevoegde gegevens kan valideren, het verzoek kan tekenen en het certificaat kan retourneren. Het tweede bestand heet cert.pem en is de geheime sleutel voor het certificaat. Deze dient zorgvuldig beschermd te worden. Als de geheime sleutel in de handen van anderen valt kan die gebruikt worden om de identiteit van de eigenaar (of server) aan te nemen.

In gevallen waar ondertekening door een CA niet vereist is, kan een zelfondertekend certificaat gemaakt worden. Maak als eerste de RSA sleutel:

Hierna kan de CA sleutel gemaakt worden:

Deze sleutel kan gebruikt worden om een certificaat te maken:

Er zouden nu twee bestanden bijgekomen moeten zijn in de map: een certificaatautoriteit 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.

En wat kunnen deze bestanden? Een prima toepassing zou het versleutelen van verbindingen naar de SendmailMTA kunnen zijn. Daardoor zouden gebruikers niet langer platte tekst hoeven te autenticeren om mail te sturen via de lokale MTA.

De volgende regels moeten opgenomen worden in het lokale .mc bestand:

/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 make install waardoor de daemon Sendmail 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 telnet(1):

Als de regel "STARTTLS" verschijnt in de uitvoer dan werkt alles correct.

Deze paragraaf is een gids in het proces van het opzetten van IPsec. Voordat IPsec opgezet kan worden dient de lezer bekend te zijn met de concepten die nodig zijn om een aangepaste kernel te bouwen (zie De FreeBSD-kernel instellen).

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 FreeBSD IPsec "netwerk wachtrij (stack)" is gebaseerd op de KAME-implementatie, die zowel de protocolfamilies IPv4 als de IPv6 ondersteunt.

IPsec bestaat uit twee subprotocollen:

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 ipsec(4) staat gedetailleerde informatie over het IPsec subsysteem in FreeBSD.

Voor ondersteuning voor IPsec in de kernel zijn de volgende opties nodig in het kernelinstellingenbestand:

Als er ook fouten in IPsec (debugging) verwijderd moeten kunnen worden, dan is de volgende optie ook nodig:

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.

Dit is het uitgangspunt:

Om te beginnen moet de port security/ipsec-tools geïnstalleerd zijn vanuit de Portscollectie. Dit softwarepakket van een derde partij biedt een aantal applicaties die helpen de configuratie te ondersteunen.

De volgende benodigdheid is om twee gif(4) pseudo-apparaten aan te maken om de pakketten te tunnelen en beide netwerken in staat stellen om op een juiste wijze te communiceren. Draai als root de volgende commando’s, waarbij de items intern en extern met de echte interne en externe gateways:

Het publieke IP van het LAN van de onderneming is bijvoorbeeld 172.16.5.4 en het heeft een privaat IP`10.246.38.1`. Het publieke IP van het LAN van huis is 192.168.1.12 met een intern privaat IP`10.0.0.5`.

Dit kan verwarrend lijken, dus bekijk de volgende voorbeeld van het commando ifconfig(8):

Eenmaal compleet zouden beide private IP’s bereikbaar moeten zijn met het commando ping(8) zoals de volgende uitvoer suggereert:

Zoals verwacht hebben beide kanten de mogelijkheid om ICMP-pakketten te verzenden en te ontvangen van de privaat geconfigureerde adressen. Vervolgens dient aan beide gateways verteld te worden hoe pakketten te routeren om op de juiste wijze verkeer van een van de netwerken te versturen. Het volgende commando doet dit:

Op dit moment dienen interne machines bereikbaar te zijn vanuit elke gateway alsook als vanuit machines achter de gateways. Dit is eenvoudig te zien aan het volgende voorbeeld:

De tunnels opzetten is het eenvoudige deel. Het configureren van een veilige verbinding is een veel diepgaander proces. De volgende configuratie gebruikt vooraf gedeelde (PSK) RSA-sleutels. Afgezien van de IP-adressen zijn beide bestanden /usr/local/etc/racoon/racoon.conf identiek en zien ze er ongeveer als volgt uit:

Het uitleggen van elke beschikbare optie, samen met diegenen in deze voorbeelden valt buiten het bereik van dit document. De configuratiehandleiding van racoon staat vol relevante informatie.

De SPD-beleiden moeten geconfigureerd worden zodat FreeBSD en racoon in staat zijn om netwerkverkeer tussen hosts te versleutelen en te ontsleutelen.

Deze taak kan met een eenvoudig shellscript zoals het volgende dat op de gateway van de onderneming staat worden uitgevoerd. Dit bestand wordt gebruikt tijdens de systeeminitialisatie en dient bewaard te worden als /usr/local/etc/racoon/setkey.conf.

Eenmaal aanwezig kan racoon op beide gateways gestart worden met het volgende commando:

De uitvoer moet ongeveer gelijk zijn aan de volgende:

Om er zeker van te zijn dat de tunnel correct werkt, dient naar een ander console geschakeld te worden en tcpdump(1) gebruikt te worden om hiermee het netwerkverkeer te bekijken. Vervang em0 door de netwerkinterfacekaart indien nodig.

Gegevens lijkend op de volgende zouden op het console moeten verschijnen. Indien niet, dan is er iets aan de hand, en is het nodig om de teruggegeven gegevens te debuggen.

Op dit punt zouden beide netwerken beschikbaar moeten zijn en deel lijken van hetzelfde netwerk. Waarschijnlijk zijn beide netwerken beschermt door een firewall, zoals het hoort. Om verkeer tussen hen toe te staan, moeten er regels worden toegevoegd om pakketten heen en terug door te laten. Voeg voor de firewall ipfw(8) de volgende regels toe aan het instellingenbestand van de firewall:

Voor gebruikers van pf(4) of ipf(8) zouden de volgende regels moeten volstaan:

Ter afsluiting, voeg de volgende regels toe aan /etc/rc.conf om de machine toe te staan om ondersteuning voor het VPN te starten tijdens de systeeminitialisatie:

Als gewoonlijk telnet(1) of rlogin(1) wordt gebruikt, wordt de data in platte tekst en niet versleuteld verzonden. Netwerksnuffelaars die ergens tussen de cliënt 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 autenticatie en versleutelingsmethoden die het voorgaande voorkomen.

De sshd is een optie die wordt aangeboden tijdens een Standard-installatie van FreeBSD. sshd is ingeschakeld als de volgende regel voorkomt in rc.conf:

Hierdoor wordt sshd(8) geladen, het daemonprogramma voor OpenSSH, als het systeem de volgende keer opstart. Als alternatief is het mogelijk om rc(8) te gebruiken om OpenSSH te starten:

ssh(1) werkt net zoals rlogin(1).

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 cliënt 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-cliënt 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.

Recente OpenSSH servers staan standaard ingesteld om alleen SSH v2 connecties toe te staan. De cliënt gebruikt versie 2 als dat mogelijk is en valt anders terug op versie 1. De cliënt kan ook gedwongen worden om een van de twee protocollen te gebruiken door de optie -1 of -2 voor respectievelijk versie 1 en versie 2 aan te geven. De mogelijkheid versie 1 te gebruiken blijft in de cliënt bestaan om compatibiliteit met oudere versies te behouden.

Het commando scp(1) (secure copy) werkt gelijk aan rcp(1). Het kopieert een bestand van of naar een andere machine, maar doet dat veilig.

Omdat de vingerafdruk al is opgeslagen voor deze host in het vorige voorbeeld, is die al geverifieerd als scp(1) gebruik wordt.

De argumenten die aan scp(1) gegeven worden zijn vrijwel gelijk aan die voor 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 user@host:<path_to_remote_file>.

Het instellingenbestand dat voor het hele systeem geldt voor zowel de OpenSSH daemon als cliënt staat in de map /etc/ssh.

ssh_config bevat de instellingen voor de cliënt en sshd_config bevat ze voor de daemon.

Daarnaast bieden het sshd_program (standaard /usr/sbin/sshd) en sshd_flagsrc.conf opties nog meer mogelijkheden voor instellingen.

In plaats van het gebruik van wachtwoorden kan ssh-keygen(1) gebruikt worden om DSA en RSA sleutels te maken om een gebruiker te autenticeren:

ssh-keygen(1) maakt een publiek en privaat sleutelpaar aan dat gebruikt kan worden voor autenticatie. De private sleutel staat opgeslagen in ~/.ssh/id_dsa of ~/.ssh/id_rsa en de publieke sleutel staat in ~/.ssh/id_dsa.pub of ~/.ssh/id_rsa.pub voor respectievelijk sleuteltypen DSA en RSA. De publieke sleutel moet voor beide RSA- of DSA-sleutels in het bestand ~/.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 SSH sleutels in plaats van op wachtwoorden.

Als er een wachtwoordzin is gebruikt bij ssh-keygen(1) dan wordt de gebruiker iedere keer dat de private sleutel wordt gebruikt een wachtwoord gevraagd. ssh-agent(1) kan het ongemak van steeds opnieuw een lange wachtwoordzin moeten ingeven verlichten en wordt beschreven in het onderdeel ssh-agent en ssh-add.

De hulpprogramma’s ssh-agent(1) en ssh-add(1) bieden de mogelijkheid om SSH in het geheugen te laden zodat niet iedere keer de wachtwoordzin ingegeven hoeft te worden.

Het hulpprogramma ssh-agent(1) handelt de autenticatie af voor de geheime sleutels die erin geladen zijn. ssh-agent(1) wordt gebruikt om andere programma’s te starten. Bij eenvoudig gebruik kan er een shell mee gestart worden of meer complex een schermbeheerprogramma.

Voordat ssh-agent(1) in een shell gebruikt kan worden dient het eerst gestart te worden met een shell als argument. Daarna kan de identiteit toegevoegd worden daar ssh-add(1) aan te roepen en de wachtwoordzin voor de geheime sleutel op te geven. Als deze stappen zijn voltooid kan een gebruiker met ssh(1) naar iedere host waar de corresponderende publieke sleutel is geïnstalleerd:

Om ssh-agent(1) te gebruiken in X11 dient er een verwijzing naar ssh-agent(1) in ~/.xinitrc te staan. Dan zijn de diensten van ssh-agent(1) beschikbaar voor alle programma’s die in X11 gestart worden. Een ~/.xinitrc zou er als volgt uit kunnen zien:

Hiermee wordt ssh-agent(1) gestart die op zijn beurt XFCE start, iedere keer dat X11 start. Als dat is gebeurd en X11 is herstart zodat de wijzigingen actief zijn, dan kan eenvoudigweg ssh-add(1) gestart worden om alle beschikbare SSH sleutels te laden.

OpenSSH kan een tunnel maken waarin een ander protocol ingepakt kan worden zodat er een versleutelde sessie ontstaat.

Het volgende commando geeft ssh(1) aan dat er een tunnel voor telnet gemaakt moet worden:

Aan het ssh commando worden de volgende opties meegegeven:

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.

Vaak is het verstandig om beperkingen aan te brengen op het gebied van welke gebruikers kunnen aanmelden en van waar. De optie AllowUsers biedt deze mogelijkheid. Om bijvoorbeeld alleen root toe te staan zich aan te melden van 192.168.1.32, kan iets als de volgende regel worden opgenomen in het bestand /etc/ssh/sshd_config:

Om de gebruiker admin het recht te geven zich van overal aan te melden hoeft alleen de gebruikersnaam vermeld te worden:

Meerdere gebruikers met rechten of beperkingen horen op dezelfde regel te staan:

Nadat er wijzigingen zijn gemaakt aan /etc/ssh/sshd_config dienen de bestanden in sshd(8) geladen te worden:

OpenSSH

ssh(1) scp(1) ssh-keygen(1) ssh-agent(1) ssh-add(1) ssh_config(5)

sshd(8) sftp-server(8) sshd_config(5)

De ACLs van het bestandssysteem kunnen bekeken worden met het hulpprogramma getfacl(1). Om de ACL op het bestand test te bekijken zou het volgende commando nodig zijn:

Om de ACL op dit bestand te wijzigen wordt het hulpprogramma setfacl(1) als volgt gebruikt:

De vlag -k verwijdert alle bestaande ACLs van een bestand of bestandssysteem. De methode die de voorkeur geniet is -b gebruiken omdat die optie de basisvelden die nodig zijn voor het laten werken van de ACLs laat staan.

Bij het commando hierboven, werd de optie -m 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.

De FreeBSD beveiligingswaarschuwingen zien er ongeveer uit als die hieronder die van de FreeBSD beveiligingswaarschuwingen mailinglijst mailinglijst komt.

Voordat procesaccounting gebruikt kan worden dient het te worden ingeschakeld met de volgende commando’s:

Eenmaal ingeschakeld begint accounting met het bijhouden van CPU statistieken, commando’s, enzovoort. Alle accounting logboeken worden in een niet leesbaar formaat bijgehouden en zijn uit te lezen met sa(8). Bij het uitvoeren zonder opties, toont sa informatie gerelateerd aan het aantal aanroepen per gebruiker, de totale tijd in minuten die is verstreken, de totale CPU- en gebruikerstijd in minuten, gemiddeld aantal I/O operaties, enzovoort.

Informatie over uitgevoerde commando’s kan bekeken worden met lastcomm(1). Zo kan met lastcomm bijvoorbeeld weergegeven worden welke commando’s door gebruikers op een specifieke ttys(5) zijn uitgevoerd:

Het bovenstaande commando toont ieder bekend gebruikt van ls door de gebruiker trhodes op terminal ttyp1.

Veel andere handige opties staan beschreven in lastcomm(1), acct(5) en sa(8).