Hoofdstuk 29. Netwerkdiensten

29.1. Overzicht

Dit hoofdstuk behandelt een aantal veelgebruikte netwerkdiensten op UNIX® systemen. Er wordt ingegaan op de installatie, het instellen, testen en beheren van verschillende typen netwerkdiensten. Overal in dit hoofdstuk staan voorbeeldbestanden met instellingen waar de lezer zijn voordeel mee kan doen.

Na het lezen van dit hoofdstuk weet de lezer:

  • Hoe om te gaan met de inetd daemon;

  • Hoe een netwerkbestandssysteem opgezet kan worden;

  • Hoe een netwerkinformatiedienst (NIS) opgezet kan worden voor het delen van gebruikersaccounts;

  • Hoe automatische netwerkinstellingen gemaakt kunnen worden met DHCP;

  • Hoe een domeinnaam server opgezet kan worden;

  • Hoe een Apache HTTP Server opgezet kan worden;

  • Hoe een File Transfer Protocol (FTP) Server opgezet kan worden;

  • Hoe een bestand-- en printserver voor Windows® cliënten opgezet kan worden met Samba;

  • Hoe datum en tijd gesynchroniseerd kunnen worden en hoe een tijdserver opgezet kan worden met het NTP-protocol.

  • Hoe het standaard log-daemon syslogd in te stellen om logs van hosts op afstand te accepteren.

Veronderstelde voorkennis:

29.2. De inetd"Super-Server"

29.2.1. Overzicht

inetd(8) wordt soms de "Internet Super-Server" genoemd, omdat het verbindingen voor meerdere diensten beheert. Als door inetd een verbinding wordt ontvangen, bepaalt die voor welk programma de verbinding bedoeld is, splitst het dat proces af en delegeert de socket (het programma wordt gestart met de socket van de dienst als zijn standaardinvoer, -uitvoer en -foutbeschrijvingen). Het draaien van inetd voor servers die niet veel gebruikt worden kan de algehele werklast verminderen in vergelijking met het draaien van elke daemon individueel in stand-alone modus.

inetd wordt primair gebruikt om andere daemons aan te roepen, maar het handelt een aantal triviale protocollen direct af, zoals chargen, auth en daytime.

In deze paragraaf worden de basisinstellingen van inetd behandeld met de opties vanaf de commandoregel en met het instellingenbestand /etc/inetd.conf.

29.2.2. Instellingen

inetd wordt gestart door het rc(8)-systeem. De optie inetd_enable staat standaard op NO, maar kan tijdens de installatie door sysinstall worden aangezet. Door het plaatsen van

inetd_enable="YES"

of

inetd_enable="NO"

in /etc/rc.conf wordt inetd bij het opstarten van een systeem wel of niet ingeschakeld. Het commando:

# service inetd rcvar

kan gedraaid worden om de huidige effectieve instellingen weer te geven.

Dan kunnen er ook nog een aantal commandoregelopties aan inetd meegegeven worden met de optie inetd_flags.

29.2.3. Commandoregelopties

Zoals de meeste serverdaemons heeft inetd een aantal opties die doorgegeven kunnen worden om het gedrag aan te passen. Zie de handleidingpagina inetd(8) voor een volledige lijst van de opties.

Opties kunnen door middel van de optie inetd_flags in /etc/rc.conf aan inetd worden doorgegeven. Standaard staat inetd_flags ingesteld op -wW -C 60, dat TCP-wrapping aanzet voor de diensten van inetd, en voorkomt dat elk enkelvoudig IP-adres enige dienst meer dan 60 keer per minuut opvraagt.

Ook al worden er hieronder rate-limiting opties besproken, beginnende gebruikers kunnen blij zijn met het feit dat deze parameters gewoonlijk niet hoeven te worden aangepast. Deze opties kunnen interessant zijn wanneer er een buitensporige hoeveelheid verbindingen worden opgezet. Een volledige lijst van opties staat in de hulppagina inetd(8).

-c maximum

Geeft het maximale aantal gelijktijdige verzoeken voor iedere dienst aan. De standaard is ongelimiteerd. Kan per dienst ter zijde geschoven worden met de parameter max-child.

-C rate

Geeft het maximale aantal keren aan dat een dienst vanaf een bepaald IP-adres per minuut aangeroepen kan worden. Kan per dienst ter zijde geschoven worden met de parameter max-connections-per-ip-per-minute.

-R rate

Geeft het maximale aantal keren aan dat een dienst per minuut aangeroepen kan worden. De standaard is 256. De instelling 0 geeft aan dat er geen limiet is.

-s maximum

Specificeert het maximaal aantal keer per minuut dat een dienst aangeroepen kan worden vanuit een enkelvoudig IP-adres; de standaard is onbeperkt. Kan worden overstemd op een per-dienst-basis met de parameter max-child-per-ip.

29.2.4. inetd.conf

De instellingen van inetd worden beheerd in /etc/inetd.conf.

Als er een wijziging wordt aangebracht in /etc/inetd.conf, dan kan inetd gedwongen worden om de instellingen opnieuw in te lezen door dit commando te draaien:

Voorbeeld 1. Het instellingenbestand van inetd herladen
# service inetd reload

Iedere regel in het bestand met instellingen heeft betrekking op een individuele daemon. Commentaar wordt vooraf gegaan door een #. De opmaak van elke regel van /etc/inetd.conf is als volgt:

service-name
socket-type
protocol
{wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]
user[:group][/login-class]
server-program
server-program-arguments

Een voorbeeldregel voor de daemon ftpd(8) met IPv4 kan eruit zien als:

ftp     stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -l
service-name

Dit is de dienstnaam van een daemon. Die moet overeenkomen met een dienst uit /etc/services. Hiermee kan de poort waarop inetd moet luisteren aangegeven worden. Als er een nieuwe dienst wordt gemaakt, moet die eerst in /etc/services gezet worden.

socket-type

Dit is stream, dgram, raw of seqpacket. stream moet gebruikt worden voor verbindingsgebaseerde TCP-daemons, terwijl dgram wordt gebruikt voor daemons die gebruik maken van het transportprotocol UDP.

protocol

Een van de volgende:

ProtocolToelichting

tcp, tcp4

TCP IPv4

udp, udp4

UDP IPv4

tcp6

TCP IPv6

udp6

UDP IPv6

tcp46

Zowel TCP IPv4 als v6

udp46

Zowel UDP IPv4 als v6

{wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]

wait|nowait geeft aan of de daemon die door inetd wordt aangesproken zijn eigen sockets kan afhandelen of niet. dgram sockettypen moeten de optie wait gebruiken, terwijl streamsocket daemons, die meestal multi-threaded zijn, de optie nowait horen te gebruiken. wait geeft meestal meerdere sockets aan een daemon, terwijl nowait een kinddaemon draait voor iedere nieuwe socket.

Het maximum aantal kinddaemons dat inetd mag voortbrengen kan ingesteld worden met de optie max-child. Als een limiet van tien instanties van een bepaalde daemon gewenst is, dan zou er /10 achter nowait gezet worden. Door /0 wordt een onbeperkt aantal kinderen toegestaan.

Naast max-child zijn er nog twee andere opties waarmee het maximale aantal verbindingen van een bepaalde plaats naar een daemon ingesteld kan worden. max-connections-per-ip-per-minute beperkt het aantal verbindingen per minuut voor enig IP-adres, een waarde van tien betekent hier dat er van ieder IP-adres maximaal tien verbindingen naar een bepaalde dienst tot stand gebracht kunnen worden. max-child-per-ip beperkt het aantal kindprocessen dat namens enig IP-adres op enig moment gestart kan worden. Deze opties kunnen zijn nuttig om bedoeld en onbedoeld buitensporig bronnengebruik van en Denial of Service (DoS) aanvallen op een machine te voorkomen.

In dit veld is één van wait of nowait verplicht. max-child, max-connections-per-ip-per-minute en max-child-per-ip zijn optioneel.

Een stream-type multi-threaded daemon zonder één van de limieten max-child, max-connections-per-ip-per-minute of max-child-per-ip is eenvoudigweg: nowait.

Dezelfde daemon met een maximale limiet van tien daemons zou zijn: nowait/10.

Dezelfde instellingen met een limiet van twintig verbindingen per IP-adres per minuut en een totaal maximum van tien kinddaemons zou zijn: nowait/10/20.

Deze opties worden allemaal gebruikt door de standaardinstellingen van de daemon fingerd(8):

finger stream  tcp     nowait/3/10 nobody /usr/libexec/fingerd fingerd -s

Als afsluiting, een voorbeeld in dit veld met een maximum van 100 kinderen in totaal, met een maximum van 5 voor enig IP-adres zou zijn: nowait/100/0/5.

user

Dit is de gebruikersnaam waar een daemon onder draait. Daemons draaien meestal als de gebruiker root. Om veiligheidsredenen draaien sommige daemons onder de gebruiker daemon of de gebruiker met de minste rechten: nobody.

server-program

Het volledige pad van de daemon die uitgevoerd moet worden als er een verbinding wordt ontvangen. Als de daemon een dienst is die door inetd intern wordt geleverd, dan moet de optie internal gebruikt worden.

server-program-arguments

Deze optie werkt samen met de optie server-program en hierin worden de argumenten ingesteld, beginnend met argv[0], die bij het starten aan de daemon worden meegegeven. Als mijndaemon -d de commandoregel is, dan zou mijndaemon -d de waarde van server-program-arguments zijn. Hier geldt ook dat als de daemon een interne dienst is, hier de optie internal moet worden.

29.2.5. Beveiliging

Afhankelijk van keuzes gemaakt tijdens de installatie, kunnen veel van de diensten van inetd standaard ingeschakeld zijn. Het is verstandig te overwegen om een daemon dat niet noodzakelijk is uit te schakelen. Plaats een # voor de daemon in /etc/inetd.conf en herlaad vervolgens de instellingen van inetd. Sommige daemons, zoals fingerd, zijn wellicht helemaal niet gewenst omdat ze informatie geven die nuttig kan zijn voor een aanvaller.

Sommige daemons zijn zich niet echt bewust van beveiliging en hebben lange of niet bestaande timeouts voor verbindingspogingen. Hierdoor kan een aanvaller langzaam veel verbindingen maken met een daemon en zo beschikbare bronnen verzadigen. Het is verstandig voor die daemons de limietopties max-connections-per-ip-per-minute, max-child of max-child-per-ip te gebruiken als ze naar uw smaak teveel verbindingen hebben.

TCP-wrapping staat standaard aan. Er staat meer informatie over het zetten van TCP-restricties op de verschillende daemons die door inetd worden aangesproken in hosts_access(5).

29.2.6. Allerlei

daytime, time, echo, discard, chargen en auth zijn allemaal interne diensten van inetd.

De dienst auth biedt identiteitsnetwerkdiensten en is tot op een bepaald niveau instelbaar, terwijl de anderen eenvoudigweg aan of uit staan.

Meer diepgaande informatie staat in inetd(8).

29.3. Netwerkbestandssysteem (NFS)

Het Netwerkbestandssysteem (Network File System) is een van de vele bestandssystemen die FreeBSD ondersteunt. Het staat ook wel bekend als NFS. Met NFS is het mogelijk om mappen en bestanden met anderen in een netwerk te delen. Door het gebruik van NFS kunnen gebruikers en programma’s bij bestanden op andere systemen op bijna dezelfde manier als bij hun eigen lokale bestanden.

De grootste voordelen van NFS zijn:

  • Lokale werkstations gebruiken minder schijfruimte omdat veel gebruikte data op één machine opgeslagen kan worden en nog steeds toegankelijk is voor gebruikers via het netwerk;

  • Gebruikers hoeven niet op iedere machine een thuismap te hebben. Thuismappen kunnen op de NFS server staan en op het hele netwerk beschikbaar zijn;

  • Opslagapparaten als floppydisks, CD-ROM drives en Zip® drives kunnen door andere machines op een netwerk gebruikt worden. Hierdoor kan het aantal drives met verwijderbare media in een netwerk verkleind worden.

29.3.1. Hoe NFS werkt

NFS bestaat uit tenminste twee hoofdonderdelen: een server en een of meer cliënten. De cliënt benadert de gegevens die op een servermachine zijn opgeslagen via een netwerk. Om dit mogelijk te maken moeten er een aantal processen ingesteld en gestart worden.

Op de server moeten de volgende daemons draaien:

DaemonBeschrijving

nfsd

De NFS-daemon die verzoeken van de NFS cliënten afhandelt.

mountd

De NFS koppeldaemon die doorgestuurde verzoeken van nfsd(8) uitvoert.

rpcbind

Deze daemon geeft voor NFS-cliënten aan welke poort de NFS-server gebruikt.

Op de cliënt kan ook een daemon draaien: nfsiod. De daemon nfsiod handelt verzoeken van de NFS-server af. Dit is optioneel en kan de prestaties verbeteren, maar het is niet noodzakelijk voor een normale en correcte werking. Meer informatie staat in nfsiod(8).

29.3.2. NFS instellen

NFS instellen gaat redelijk rechtlijnig. Alle processen die moeten draaien kunnen meestarten bij het opstarten door een paar wijzigingen in /etc/rc.conf.

Op de NFS server dienen de volgende opties in /etc/rc.conf te staan:

rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"

mountd start automatisch als de NFS server is ingeschakeld.

Op de cliënt dient de volgende optie in /etc/rc.conf te staan:

nfs_client_enable="YES"

In het bestand /etc/exports staat beschreven welke bestandssystemen NFS moet exporteren (soms heet dat ook wel delen of "sharen"). Iedere regel in /etc/exports slaat op een bestandssysteem dat wordt geëxporteerd en welke machines toegang hebben tot dat bestandssysteem. Samen met machines die toegang hebben, kunnen ook toegangsopties worden aangegeven. Er zijn veel opties beschikbaar, maar hier worden er maar een paar beschreven. Alle opties staan beschreven in exports(5).

Nu volgen een aantal voorbeelden voor /etc/exports:

Het volgende voorbeeld geeft een beeld van hoe een bestandssysteem te exporteren, hoewel de instellingen afhankelijk zijn van de omgeving en het netwerk. Om bijvoorbeeld de map /cdrom te exporteren naar drie machines die dezelfde domeinnaam hebben als de server (vandaar dat de machinenamen geef domeinachtervoegsel hebben) of in /etc/hosts staan. De vlag -ro exporteert het bestandssysteem als alleen-lezen. Door die vlag kan een ander systeem niet schrijven naar het geëxporteerde bestandssysteem.

/cdrom -ro host1 host2 host3

Het volgende voorbeeld exporteert /home naar drie hosts op basis van IP-adres. Dit heeft zin als er een privaat netwerk bestaat, zonder dat er een DNS server is ingesteld. Optioneel kan /etc/hosts gebruikt worden om interne hostnamen in te stellen. Er is meer informatie te vinden in hosts(5). Met de vlag -alldirs mogen submappen ook koppelpunten zijn. De submap wordt dan niet feitelijk aangekoppeld, maar de cliënt koppelt dan alleen de submappen aan die verplicht of nodig zijn.

/home  -alldirs  10.0.0.2 10.0.0.3 10.0.0.4

Het volgende voorbeeld exporteert /a zo dat twee cliënten uit verschillende domeinen bij het bestandssysteem mogen. Met de vlag -maproot=root mag de gebruiker op het andere systeem gegevens naar het geëxporteerde bestandssysteem schrijven als root. Als de vlag -maproot=root niet wordt gebruikt, dan kan een gebruiker geen bestanden wijzigen op het geëxporteerde bestandssysteem, zelfs niet als een gebruiker daar root is.

/a  -maproot=root  host.example.com box.example.org

Om een cliënt toegang te geven tot een geëxporteerd bestandssysteem, moet die cliënt daar rechten voor hebben. De cliënt moet daarvoor genoemd worden in /etc/exports.

In /etc/exports staat iedere regel voor de exportinformatie van één bestandssysteem naar één host. Per bestandssysteem mag een host maar één keer genoemd worden en mag maar één standaard hebben. Stel bijvoorbeeld dat /usr een enkel bestandssysteem is. Dan is de volgende /etc/exports niet geldig:

# Werkt niet als /usr 1 bestandssysteem is
/usr/src   client
/usr/ports client

Eén bestandssysteem, /usr, heeft twee regels waarin exports naar dezelfde host worden aangegeven, client. In deze situatie is de juiste instelling:

/usr/src /usr/ports  client

De eigenschappen van een bestandssysteem dat naar een bepaalde host wordt geëxporteerd moeten allemaal op één regel staan. Regels waarop geen cliënt wordt aangegeven worden behandeld als een enkele host. Dit beperkt hoe bestandssysteem geëxporteerd kunnen worden, maar dat blijkt meestal geen probleem te zijn.

Het volgende voorbeeld is een geldige exportlijst waar /usr en /exports lokale bestandssystemen zijn:

# Exporteer src en ports naar client01 en client02,
# maar alleen client01 heeft er rootprivileges
/usr/src /usr/ports -maproot=root    client01
/usr/src /usr/ports               client02
# De cliëntmachines hebben rootrechten en kunnen overal aankoppelen
# op /exports. Iedereen in de wereld kan /exports/obj als alleen-lezen aankoppelen.
/exports -alldirs -maproot=root      client01 client02
/exports/obj -ro

De daemon mountd moet gedwongen worden om het bestand /etc/exports te controleren steeds wanneer het is aangepast, zodat de veranderingen effectief kunnen worden. Dit kan worden bereikt door òfwel een HUP-signaal naar de draaiende daemon te sturen:

# kill -HUP `cat /var/run/mountd.pid`

of door het rc(8) script mountd met de juiste parameter aan te roepen:

# service mountd onereload

Raadpleeg Gebruik van rc met FreeBSD voor meer informatie over het gebruik van rc-scripts.

Het is ook mogelijk een machine te herstarten, zodat FreeBSD alles netjes in kan stellen, maar dat is niet nodig. Het uitvoeren van de volgende commando’s als root hoort hetzelfde resultaat te hebben.

Op de NFS server:

# rpcbind
# nfsd -u -t -n 4
# mountd -r

Op de NFS cliënt:

# nfsiod -n 4

Nu is alles klaar om feitelijk het netwerkbestandssysteem aan te koppelen. In de volgende voorbeelden is de naam van de server server en de naam van de cliënt is client. Om een netwerkbestandssysteem slechts tijdelijk aan te koppelen of om alleen te testen, kan een commando als het onderstaande als root op de cliënt uitgevoerd worden:

# mount server:/home /mnt

Hiermee wordt de map /home op de server aangekoppeld op /mnt op de cliënt. Als alles juist is ingesteld, zijn nu in /mnt op de cliënt de bestanden van de server zichtbaar.

Om een netwerkbestandssysteem iedere keer als een computer opstart aan te koppelen, kan het bestandssysteem worden toegevoegd aan het bestand /etc/fstab:

server:/home	/mnt	nfs	rw	0	0

Alle beschikbare opties staan in fstab(5).

29.3.3. Op slot zetten

Voor sommige applicaties (b.v. mutt) is het nodig dat bestanden op slot staan om correct te werken. In het geval van NFS, kan rpc.lockd worden gebruikt voor het op slot zetten van bestanden. Voeg het volgende toe aan het bestand /etc/rc.conf op zowel de cliënt als de server om het aan te zetten (het wordt aangenomen dat de NFS-cliënt en -server reeds zijn geconfigureerd):

rpc_lockd_enable="YES"
rpc_statd_enable="YES"

Start de applicatie met:

# service lockd start
# service statd start

Als echt op slot zetten tussen de NFS-cliënten en de NFS-server niet nodig is, is het mogelijk om de NFS-cliënt bestanden lokaal op slot te laten zetten door -L aan mount_nfs(8) door te geven. In de handleidingpagina mount_nfs(8) staan verdere details.

29.3.4. Mogelijkheden voor gebruik

NFS is voor veel doeleinden in te zetten. Een aantal voorbeelden:

  • Een aantal machines een CD-ROM of andere media laten delen. Dat is goedkoper en vaak ook handiger, bijvoorbeeld bij het installeren van software op meerdere machines;

  • Op grote netwerken kan het praktisch zijn om een centrale NFS server in te richten, waarop alle thuismappen staan. Die thuismappen kunnen dan geëxporteerd worden, zodat gebruikers altijd dezelfde thuismap hebben, op welk werkstation ze ook aanmelden;

  • Meerdere machines kunnen een gezamenlijke map /usr/ports/distfiles hebben. Dan is het mogelijk om een port op meerdere machines te installeren, zonder op iedere machine de broncode te hoeven downloaden.

29.3.5. Automatisch aankoppelen met amd

amd(8) (de automatic mounter daemon) koppelt automatisch netwerkbestandssystemen aan als er aan een bestand of map binnen dat bestandssysteem wordt gerefereerd. amd ontkoppelt ook bestandssystemen die een bepaalde tijd niet gebruikt worden. Het gebruikt van amd is een aantrekkelijk en eenvoudig alternatief ten opzichte van permanente koppelingen, die meestal in /etc/fstab staan.

amd werkt door zichzelf als NFS-server te koppelen aan de mappen /host en /net. Als binnen die mappen een bestand wordt geraadpleegd, dan zoekt amd de bijbehorende netwerkkoppeling op en koppelt die automatisch aan. /net wordt gebruikt om een geëxporteerd bestandssysteem van een IP-adres aan te koppelen, terwijl /host wordt gebruikt om een geëxporteerd bestandssysteem van een hostnaam aan te koppelen.

Het raadplegen van een bestand in /host/foobar/usr geeft amd aan dat die moet proberen de /usr export op de host foobar aan te koppelen.

Voorbeeld 2. Een export aankoppelen met amd

De beschikbare koppelingen van een netwerkhost zijn te bekijken met showmount. Om bijvoorbeeld de koppelingen van de host foobar te bekijken:

% showmount -e foobar
Exports list on foobar:
/usr                               10.10.10.0
/a                                 10.10.10.0
% cd /host/foobar/usr

Zoals in het bovenstaande voorbeeld te zien is, toont showmount/usr als een export. Als er naar de map /host/foobar/usr wordt gegaan, probeert amd de hostnaam foobar te resolven en de gewenste export automatisch aan te koppelen.

amd kan gestart worden door de opstartscript door de volgende regel in /etc/rc.conf te plaatsen:

amd_enable="YES"

Er kunnen ook nog opties meegegeven worden aan amd met de optie amd_flags. Standaard staat amd_flags ingesteld op:

amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"

In het bestand /etc/amd.map staan de standaardinstellingen waarmee exports aangekoppeld worden. In het bestand /etc/amd.conf staan een aantal van de meer gevorderde instellingen van amd.

In amd(8) en amd.conf(8) staat meer informatie.

29.3.6. Problemen bij samenwerking met andere systemen

Bepaalde Ethernet adapters voor ISA PC systemen kennen limieten die tot serieuze netwerkproblemen kunnen leiden, in het bijzonder met NFS. Dit probleem is niet specifiek voor FreeBSD, maar het kan op FreeBSD wel voor komen.

Het probleem ontstaat bijna altijd als (FreeBSD) PC-systemen netwerken met hoog presterende werkstations, zoals van Silicon Graphics, Inc. en Sun Microsystems, Inc. De NFS-koppeling werkt prima en wellicht lukken een aantal acties ook, maar dan ineens lijkt de server niet meer te reageren voor de cliënt, hoewel verzoeken van en naar andere systemen gewoon verwerkt worden. Dit gebeurt op een cliëntsysteem, of de cliënt nu het FreeBSD systeem is of het werkstation. Op veel systemen is er geen manier om de cliënt netjes af te sluiten als dit probleem is ontstaan. Vaak is de enige mogelijkheid een reset van de cliënt, omdat het probleem met NFS niet opgelost kan worden.

Hoewel de enige "correcte" oplossing de aanschaf van een snellere en betere Ethernet adapter voor het FreeBSD systeem is, is er zo om het probleem heen te werken dat het werkbaar is. Als FreeBSD de server is, kan de optie -w=1024 gebruikt worden bij het aankoppelen door de cliënt. Als het FreeBSD systeem de cliënt is, dan dient het NFS-bestandssysteem aangekoppeld te worden met de optie r=1024. Deze opties kunnen het vierde veld zijn in een regel in fstab voor automatische aankoppelingen en bij handmatige aankoppelingen met mount(8) kan de parameter -o gebruikt worden.

Soms wordt een ander probleem voor dit probleem versleten, als servers en cliënten zich op verschillende netwerken bevinden. Als dat het geval is, dan dient vastgesteld te worden dat routers de UDP informatie op de juiste wijze routeren, omdat er anders nooit NFS-verkeer gerouteerd kan worden.

In de volgende voorbeelden is fastws de host(interface)naam van een hoog presterend werkstation en freebox is de host(interface)naam van een FreeBSD systeem met een Ethernet adapter die mindere prestaties levert. /sharedfs wordt het geëxporteerde NFS-bestandssysteem (zie exports(5)) en /project wordt het koppelpunt voor het geëxporteerde bestandssysteem op de cliënt.

In sommige gevallen kunnen applicaties beter draaien als extra opties als hard of soft en bg gebruikt worden.

Voorbeelden voor het FreeBSD systeem (freebox) als de cliënt in /etc/fstab op freebox:

fastws:/sharedfs /project nfs rw,-r=1024 0 0

Als een handmatig aankoppelcommando op freebox:

# mount -t nfs -o -r=1024 fastws:/sharedfs /project

Voorbeelden voor het FreeBSD systeem als de server in /etc/fstab op fastws:

freebox:/sharedfs /project nfs rw,-w=1024 0 0

Als een handmatig aankoppelcommando op fastws:

# mount -t nfs -o -w=1024 freebox:/sharedfs /project

Bijna iedere 16-bit Ethernet adapter werkt zonder de hierboven beschreven restricties op de lees- en schrijfgrootte.

Voor wie het wil weten wordt nu beschreven wat er gebeurt als de fout ontstaan, wat ook duidelijk maakt waarom het niet hersteld kan worden. NFS werkt meestal met een "block"grootte van 8 K (hoewel het mogelijk is dat er kleinere fragmenten worden verwerkt). Omdat de maximale grootte van een Ethernet pakket rond de 1500 bytes ligt, wordt een "block" opgesplitst in meerdere Ethernetpakketten, hoewel het hoger in de code nog steeds één eenheid is, en wordt ontvangen, samengevoegd en bevestigd als een eenheid. De hoog presterende werkstations kunnen de pakketten waaruit een NFS-eenheid bestaat bijzonder snel naar buiten pompen. Op de kaarten met minder capaciteit worden de eerdere pakketten door de latere pakketten van dezelfde eenheid ingehaald voordat ze bij die host zijn aangekomen en daarom kan de eenheid niet worden samengesteld en bevestigd. Als gevolg daarvan ontstaat er op het werkstation een timeout en probeert die de eenheid opnieuw te sturen, maar dan weer de hele eenheid van 8 K, waardoor het proces wordt herhaald, ad infinitum.

Door de grootte van de eenheid kleiner te houden dan de grootte van een Ethernet pakket, is het zeker dat elk Ethernetpakket dat compleet is aangekomen bevestigd kan worden, zodat de deadlock niet ontstaat.

Toch kan een PC systeem nog wel overrompeld worden als hoog presterende werkstations er op inhakken, maar met de betere netwerkkaarten valt het dan in ieder geval niet om door de NFS "eenheden". Als het systeem toch wordt overrompeld, dan worden de betrokken eenheden opnieuw verstuurd en dan is de kans groot dat ze worden ontvangen, samengevoegd en bevestigd.

29.4. Netwerkinformatiesysteem (NIS/YP)

29.4.1. Wat is het?

NIS, dat staat voor Netwerkinformatiediensten (Network Information Services), is ontwikkeld door Sun Microsystems om het beheer van UNIX® (origineel SunOS™) systemen te centraliseren. Tegenwoordig is het eigenlijk een industriestandaard geworden. Alle grote UNIX® achtige systemen (Solaris™, HP-UX, AIX®, Linux®, NetBSD, OpenBSD, FreeBSD, enzovoort) ondersteunen NIS.

NIS stond vroeger bekend als Yellow Pages, maar vanwege problemen met het handelsmerk heeft Sun de naam veranderd. De oude term, en yp, wordt nog steeds vaak gebruikt.

Het is een op RPC-gebaseerd cliënt/serversysteem waarmee een groep machines binnen een NIS-domein een gezamenlijke verzameling met instellingenbestanden kan delen. Hierdoor kan een beheerder NIS-systemen opzetten met een minimaal aantal instellingen en vanaf een centrale lokatie instellingen toevoegen, verwijderen en wijzigen.

Het is te vergelijken met het Windows NT® domeinsysteem en hoewel de interne implementatie van de twee helemaal niet overeenkomt, is de basisfunctionaliteit vergelijkbaar.

29.4.2. Termen en processen om te onthouden

Er zijn een aantal termen en belangrijke gebruikersprocessen die een rol spelen bij het implementeren van NIS op FreeBSD, zowel bij het maken van een NIS-server als bij het maken van een systeem dan NIS-cliënt is:

TermBeschrijving

NIS-domeinnaam

Een NIS-masterserver en al zijn cliënten (inclusief zijn slave master) hebben een NIS-domeinnaam. Vergelijkbaar met een Windows NT® domeinnaam, maar de NIS-domeinnaam heeft niets te maken met DNS.

rpcbind

Moet draaien om RPC (Remote Procedure Call in te schakelen, een netwerkprotocol dat door NIS gebruikt wordt). Als rpcbind niet draait, dan kan er geen NIS-server draaien en kan een machine ook geen NIS-cliënt zijn.

ypbind

"Verbindt" een NIS-cliënt aan zijn NIS-server. Dat gebeurt door met de NIS-domeinnaam van het systeem en door het gebruik van RPC te verbinden met de server. ypbind is de kern van cliënt-server communicatie in een NIS-omgeving. Als ypbind op een machine stopt, dan kan die niet meer bij de NIS-server komen.

ypserv

Hoort alleen te draaien op NIS-servers. Dit is het NIS-serverproces zelf. Als ypserv(8) stopt, dan kan de server niet langer reageren op NIS-verzoeken (hopelijk is er dan een slaveserver om het over te nemen). Er zijn een aantal implementaties van NIS, maar niet die op FreeBSD, die geen verbinding met een andere server proberen te maken als de server waarmee ze verbonden waren niet meer reageert. In dat geval is vaak het enige dat werkt het serverproces herstarten (of zelfs de hele server) of het ypbind-proces op de cliënt.

rpc.yppasswdd

Nog een proces dat alleen op NIS-masterservers hoort te draaien. Dit is een daemon waarbij NIS-cliënten hun NIS-wachtwoorden kunnen wijzigen. Als deze daemon niet draait, moeten gebruikers zich aanmelden op de NIS-masterserver en daar hun wachtwoord wijzigen.

29.4.3. Hoe werkt het?

Er zijn drie typen hosts in een NIS-omgeving: master servers, slaveservers en cliënten. Servers zijn het centrale depot voor instellingen voor een host. Masterservers bevatten de geautoriseerd kopie van die informatie, terwijl slaveservers die informatie spiegelen voor redundantie. Cliënten verlaten zich op de servers om hun die informatie ter beschikking te stellen.

Op deze manier kan informatie uit veel bestanden gedeeld worden. De bestanden master.passwd, group en hosts worden meestal via NIS gedeeld. Als een proces op een cliënt informatie nodig heeft die normaliter in een van die lokale bestanden staat, dan vraagt die het in plaats daarvan aan de NIS-servers waarmee hij verbonden is.

29.4.3.1. Soorten machines

  • Een NIS-masterserver. Deze server onderhoudt, analoog aan een Windows NT® primaire domeincontroller, de bestanden die door alle NIS-cliënten gebruikt worden. De bestanden passwd, group en andere bestanden die door de NIS-cliënten gebruikt worden staan op de masterserver.

    Het is mogelijk om één machine master server te laten zijn voor meerdere NIS-domeinen. Dat wordt in deze inleiding echter niet beschreven, omdat die uitgaat van een relatief kleine omgeving.

  • NIS-slaveservers. Deze zijn te vergelijken met Windows NT® backup domain controllers. NIS-slaveservers beheren een kopie van de bestanden met gegevens op de NIS-master. NIS-slaveservers bieden redundantie, die nodig is in belangrijke omgevingen. Ze helpen ook om de belasting te verdelen met de master server: NIS-cliënten maken altijd een verbinding met de NIS-server die het eerst reageert en dat geldt ook voor antwoorden van slaveservers.

  • NIS-cliënten. NIS-cliënten authenticeren, net als de meeste Windows NT® werkstations, tegen de NIS-server (of de Windows NT® domain controller in het geval van Windows NT® werkstations) bij het aanmelden.

29.4.4. NIS/YP gebruiken

Dit onderdeel behandelt het opzetten van een NIS-voorbeeldomgeving.

29.4.4.1. Plannen

Er wordt uitgegaan van een beheerder van een klein universiteitslab. Dat lab, dat bestaat uit FreeBSD machines, kent op dit moment geen centraal beheer. Iedere machine heeft zijn eigen /etc/passwd en /etc/master.passwd. Die bestanden worden alleen met elkaar in lijn gehouden door handmatige handelingen. Als er op dit moment een gebruiker aan het lab wordt toegevoegd, moet adduser op alle 15 machines gedraaid worden. Dat moet natuurlijk veranderen en daarom is besloten het lab in te richten met NIS, waarbij twee machines als server worden gebruikt.

Het lab ziet er ongeveer als volgt uit:

MachinenaamIP-adresRol Machine

ellington

10.0.0.2

NIS-master

coltrane

10.0.0.3

NIS-slave

basie

10.0.0.4

Wetenschappelijk werkstation

bird

10.0.0.5

Cliënt machine

cli[1-11]

10.0.0.[6-17]

Andere cliënt machines

Bij het voor de eerste keer instellen van een NIS-schema is het verstandig eerst na te denken over hoe dat opgezet moet worden. Hoe groot een netwerk ook is, er moeten een aantal beslissingen gemaakt worden.

29.4.4.1.1. Een NIS-domeinnaam kiezen

Dit is wellicht niet de bekende "domeinnaam". Daarom wordt het ook de "NIS-domeinnaam" genoemd. Bij de broadcast van een cliënt om informatie wordt ook de naam van het NIS-domein waar hij onderdeel van uitmaakt meegezonden. Zo kunnen meerdere servers op een netwerk bepalen of er antwoord gegeven dient te worden op een verzoek. De NIS-domeinnaam kan voorgesteld worden als de naam van een groep hosts die op een of andere manier aan elkaar gerelateerd zijn.

Sommige organisaties kiezen hun Internet-domeinnaam als NIS-domeinnaam. Dat wordt niet aangeraden omdat het voor verwarring kan zorgen bij het debuggen van netwerkproblemen. De NIS-domeinnaam moet uniek zijn binnen een netwerk en het is handig als die de groep machines beschrijft waarvoor hij geldt. Zo kan bijvoorbeeld de financiële afdeling van Acme Inc. als NIS-domeinnaam "acme-fin" hebben. In dit voorbeeld wordt de naam test-domain gekozen.

Sommige besturingssystemen gebruiken echter (met name SunOS™) hun NIS-domeinnaam als hun Internet-domeinnaam. Als er machines zijn op een netwerk die deze restrictie kennen, dan moet de Internet-domeinnaam als de naam voor het NIS-domeinnaam gekozen worden.

29.4.4.1.2. Systeemeisen

Bij het kiezen van een machine die als NIS-server wordt gebruikt zijn er een aantal aandachtspunten. Een van de onhandige dingen aan NIS is de afhankelijkheid van de cliënten van de server. Als een cliënt de server voor zijn NIS-domein niet kan bereiken, dan wordt die machine vaak onbruikbaar. Door het gebrek aan gebruiker- en groepsinformatie bevriezen de meeste systemen. Daarom moet er een machine gekozen worden die niet vaak herstart hoeft te worden of wordt gebruikt voor ontwikkeling. De NIS-server is in het meest ideale geval een alleenstaande server die als enige doel heeft NIS-server te zijn. Als een netwerk niet zwaar wordt gebruikt, kan de NIS-server op een machine die ook andere diensten aanbiedt gezet worden, maar het blijft belangrijk om ervan bewust te zijn dat als de NIS-server niet beschikbaar is, dat nadelige invloed heeft op alle NIS-cliënten.

29.4.4.2. NIS-servers

De hoofdversies van alle NIS-informatie staan opgeslagen op één machine die de NIS-masterserver heet. De databases waarin de informatie wordt opgeslagen heten NIS-afbeeldingen. In FreeBSD worden die afbeeldingen opgeslagen in /var/yp/[domeinnaam] waar [domeinnaam] de naam is van het NIS-domein dat wordt bediend. Een enkele NIS-server kan tegelijkertijd meerdere NIS-domeinen ondersteunen en het is dus mogelijk dat er meerdere van zulke mappen zijn, een voor ieder ondersteund domein. Ieder domein heeft zijn eigen onafhankelijke verzameling afbeeldingen.

In NIS-master- en -slaveservers worden alle NIS-verzoeken door de daemon ypserv afgehandeld. ypserv is verantwoordelijk voor het ontvangen van inkomende verzoeken van NIS-cliënten, het vertalen van de gevraagde domeinnaam en mapnaam naar een pad naar het corresponderende databasebestand en het terugsturen van de database naar de cliënten.

29.4.4.2.1. Een NIS-masterserver opzetten

Het opzetten van een master NIS-server kan erg eenvoudig zijn, afhankelijk van de behoeften. FreeBSD heeft ondersteuning voor NIS als basisfunctie. Alleen de volgende regels hoeven aan /etc/rc.conf toegevoegd te worden en FreeBSD doet de rest:

nisdomainname="test-domain"
  1. Deze regel stelt de NIS-domeinnaam in op test-domain bij het instellen van het netwerk (bij het opstarten).

    nis_server_enable="YES"
  2. Dit geeft FreeBSD aan de NIS-serverprocessen te starten als het netwerk de volgende keer wordt opgestart.

    nis_yppasswdd_enable="YES"
  3. Dit schakelt de daemon rpc.yppasswdd in die, zoals al eerder aangegeven, cliënten toestaat om hun NIS-wachtwoord vanaf een cliënt-machine te wijzigen.

Afhankelijk van de inrichting van NIS, kunnen er nog meer instellingen nodig zijn. In het onderdeel NIS-servers die ook NIS-cliënten zijn staan meer details.

Draai na het instellen van bovenstaande regels het commando /etc/netstart als supergebruiker. Het zal alles voor u instellen, gebruikmakende van de waarden die u in /etc/rc.conf heeft ingesteld. Start als laatste stap, voor het initialiseren van de NIS-afbeeldingen, de daemon ypserv handmatig:

# service ypserv start
29.4.4.2.2. NIS-afbeeldingen initialiseren

Die NIS-afbeeldingen zijn databasebestanden die in de map /var/yp staan. Ze worden gemaakt uit de bestanden met instellingen uit de map /etc van de NIS-master, met één uitzondering: /etc/master.passwd. Daar is een goede reden voor, want het is niet wenselijk om de wachtwoorden voor root en andere administratieve accounts naar alle servers in het NIS-domein te sturen. Daar moet voor het initialiseren van de NIS-afbeeldingen het volgende uitgevoerd worden:

# cp /etc/master.passwd /var/yp/master.passwd
# cd /var/yp
# vi master.passwd

Dan horen alle systeemaccounts verwijderd te worden (bin, tty, kmem, games, enzovoort) en alle overige accounts waarvoor het niet wenselijk is dat ze op de NIS-cliënten terecht komen (bijvoorbeeld root en alle andere UID 0 (supergebruiker) accounts).

/var/yp/master.passwd hoort niet te lezen te zijn voor een groep of voor de wereld (dus modus 600)! Voor het aanpassen van de rechten kan chmod gebruikt worden.

Als dat is gedaan, kunnen de NIS-afbeeldingen geïnitialiseerd worden. Bij FreeBSD zit een script ypinit waarmee dit kan (in de hulppagina staat meer informatie). Dit script is beschikbaar op de meeste UNIX® besturingssystemen, maar niet op allemaal. Op Digital UNIX/Compaq Tru64 UNIX heet het ypsetup. Omdat er afbeeldingen voor een NIS-master worden gemaakt, wordt de optie -m meegegeven aan ypinit. Aangenomen dat de voorgaande stappen zijn uitgevoerd, kunnen de NIS-afbeeldingen gemaakt worden op de volgende manier:

ellington# ypinit -m test-domain
Server Type: MASTER Domain: test-domain
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n] n
Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
At this point, we have to construct a list of this domains YP servers.
rod.darktech.org is already known as master server.
Please continue to add any slave servers, one per line. When you are
done with the list, type a <control D>.
master server   :  ellington
next host to add:  coltrane
next host to add:  ^D
The current list of NIS servers looks like this:
ellington
coltrane
Is this correct?  [y/n: y] y

[..uitvoer van het maken van de afbeeldingen..]

NIS Map update completed.
ellington has been setup as an YP master server without any errors.

ypinit hoort /var/yp/Makefile gemaakt te hebben uit /var/yp/Makefile.dist. Als dit bestand is gemaakt, neemt dat bestand aan dat er in een omgeving met een enkele NIS-server wordt gewerkt met alleen FreeBSD-machines. Omdat test-domain ook een slaveserver bevat, dient /var/yp/Makefile gewijzigd te worden:

ellington# vi /var/yp/Makefile

Als de onderstaande regel niet al uitgecommentarieerd is, dient dat alsnog te gebeuren:

NOPUSH = "True"
29.4.4.2.3. Een NIS-slaveserver opzetten

Het opzetten van een NIS-slaveserver is nog makkelijker dan het opzetten van de master. Dit kan door aan te melden op de slaveserver en net als voor de masterserver /etc/rc.conf te wijzigen. Het enige verschil is dat nu de optie -s gebruikt wordt voor het draaien van ypinit. Met de optie -s moet ook de naam van de NIS-master meegegeven worden. Het commando ziet er dus als volgt uit:

coltrane# ypinit -s ellington test-domain

Server Type: SLAVE Domain: test-domain Master: ellington

Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.

Do you want this procedure to quit on non-fatal errors? [y/n: n]  n

Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
There will be no further questions. The remainder of the procedure
should take a few minutes, to copy the databases from ellington.
Transferring netgroup...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byuser...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byhost...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring group.bygid...
ypxfr: Exiting: Map successfully transferred
Transferring group.byname...
ypxfr: Exiting: Map successfully transferred
Transferring services.byname...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.byname...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.byname...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring netid.byname...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring ypservers...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byname...
ypxfr: Exiting: Map successfully transferred

coltrane has been setup as an YP slave server without any errors.
Don't forget to update map ypservers on ellington.

Nu hoort er een map /var/yp/test-domain te zijn waarin kopieë van de NIS-masterserver afbeeldingen staan. Die moeten bijgewerkt blijven. De volgende regel in /etc/crontab op de slaveservers regelt dat:

20      *       *       *       *       root   /usr/libexec/ypxfr passwd.byname
21      *       *       *       *       root   /usr/libexec/ypxfr passwd.byuid

Met de bovenstaande twee regels wordt de slave gedwongen zijn afbeeldingen met de afbeeldingen op de masterserver te synchroniseren. Dit is niet verplicht omdat de masterserver automatisch probeert veranderingen aan de NIS-afbeeldingen door te geven aan zijn slaves. Echter, vanwege het belang van correcte wachtwoordinformatie op andere cliënten die van de slaveserver afhankelijk zijn, is het aanbevolen om specifiek de wachtwoordafbeeldingen vaak tot bijwerken te dwingen. Dit is des te belangrijker op drukke netwerken, omdat daar het bijwerken van afbeeldingen niet altijd compleet afgehandeld hoeft te worden.

Nu kan ook op de slaveserver het commando /etc/netstart uitgevoerd worden, dat op zijn beurt de NIS-server start.

29.4.4.3. NIS-cliënten

Een NIS-cliënt maakt wat heet een verbinding (binding) met een NIS-server met de daemon ypbind. ypbind controleert het standaarddomein van het systeem (zoals ingesteld met domainname) en begint met het broadcasten van RPC-verzoeken op het lokale netwerk. Die verzoeken bevatten de naam van het domein waarvoor ypbind een binding probeert te maken. Als een server die is ingesteld om het gevraagde domein te bedienen een broadcast ontvangt, dan antwoordt die aan ypbind dat dan het IP-adres van de server opslaat. Als er meerdere servers beschikbaar zijn, een master en bijvoorbeeld meerdere slaves, dan gebruikt ypbind het adres van de eerste server die antwoord geeft. Vanaf dat moment stuurt de cliënt alle NIS-verzoeken naar die server. ypbind "pingt" de server zo nu en dan om te controleren of die nog draait. Als er na een bepaalde tijd geen antwoord komt op een ping, dan markeert ypbind het domein als niet verbonden en begint het broadcasten opnieuw, in de hoop dat er een andere server wordt gelocaliseerd.

29.4.4.3.1. Een NIS-cliënt opzetten

Het opzetten van een FreeBSD machine als NIS-cliënt is redelijk doorzichtig:

  1. Wijzig /etc/rc.conf en voeg de volgende regels toe om de NIS-domeinnaam in te stellen en ypbind mee te laten starten bij het starten van het netwerk:

    nisdomainname="test-domain"
    nis_client_enable="YES"
  2. Om alle mogelijke regels voor accounts uit de NIS-server te halen, dienen alle gebruikersaccounts uit /etc/master.passwd verwijderd te worden en dient met vipw de volgende regel aan het einde van het bestand geplaatst te worden:

    +:::::::::

    Door deze regel wordt alle geldige accounts in de wachtwoordafbeelding van de NIS-server toegang gegeven. Er zijn veel manieren om de NIS-cliënt in te stellen door deze regel te veranderen. In het onderdeel netgroepen hieronder staat meer informatie. Zeer gedetailleerde informatie staat in het boek NFS en NIS beheren van O’Reilly.

    Er moet tenminste één lokale account behouden blijven (dus niet geïmporteerd via NIS) in /etc/master.passwd en die hoort ook lid te zijn van de groep wheel. Als er iets mis is met NIS, dan kan die account gebruikt worden om via het netwerk aan te melden, root te worden en het systeem te repareren.

  3. Om alle groepen van de NIS-server te importeren, kan de volgende regel aan /etc/group toegevoegd worden:

    +:*::

Voer, om de NIS-cliënt onmiddelijk te starten, de volgende commando’s als supergebruiker uit:

# /etc/netstart
# service ypbind start

Na het afronden van deze stappen zou met ypcat passwd de passwd map van de NIS-server te zien moeten zijn.

29.4.5. NIS-beveiliging

In het algemeen kan iedere netwerkgebruiker een RPC-verzoek doen uitgaan naar ypserv(8) en de inhoud van de NIS-afbeeldingen ontvangen, mits die gebruiker de domeinnaam kent. Omdat soort ongeautoriseerde transacties te voorkomen, ondersteunt ypserv(8) de optie "securenets", die gebruikt kan worden om de toegang te beperken tot een opgegeven aantal hosts. Bij het opstarten probeert ypserv(8) de securenets informatie te laden uit het bestand /var/yp/securenets.

Dit pad kan verschillen, afhankelijk van het pad dat opgegeven is met de optie -p. Dit bestand bevat regels die bestaan uit een netwerkspecificatie en een netwerkmasker, gescheiden door witruimte. Regels die beginnen met # worden als commentaar gezien. Een voorbeeld van een securenetsbestand zou er zo uit kunnen zien:

# allow connections from local host -- mandatory
127.0.0.1     255.255.255.255
# allow connections from any host
# on the 192.168.128.0 network
192.168.128.0 255.255.255.0
# allow connections from any host
# between 10.0.0.0 to 10.0.15.255
# this includes the machines in the testlab
10.0.0.0      255.255.240.0

Als ypserv(8) een verzoek ontvangt van een adres dat overeenkomt met een van de bovenstaande regels, dan wordt dat verzoek normaal verwerkt. Als er geen enkele regel op het verzoek van toepassing is, dan wordt het verzoek genegeerd en wordt er een waarschuwing gelogd. Als het bestand /var/yp/securenets niet bestaat, dan accepteert ypserv verbindingen van iedere host.

Het programma ypserv ondersteunt ook het pakket TCP Wrapper van Wietse Venema. Daardoor kan een beheerder de instellingenbestanden van TCP Wrapper gebruiken voor toegangsbeperking in plaats van /var/yp/securenets.

Hoewel beide methoden van toegangscontrole enige vorm van beveiliging bieden, zijn ze net als de geprivilegieerde poorttest kwetsbaar voor "IP spoofing" aanvallen. Al het NIS-gerelateerde verkeer hoort door een firewall tegengehouden te worden.

Servers die gebruik maken van /var/yp/securenets kunnen wellicht legitieme verzoeken van NIS-cliënten weigeren als die gebruik maken van erg oude TCP/IP-implementaties. Sommige van die implementaties zetten alle host bits op nul als ze een broadcast doen en/of kijken niet naar het subnetmasker als ze het broadcastadres berekenen. Hoewel sommige van die problemen opgelost kunnen worden door de instellingen op de cliënt aan te passen, zorgen andere problemen voor het noodgedwongen niet langer kunnen gebruiker van NIS voor die cliënt of het niet langer gebruiken van /var/yp/securenets.

Het gebruik van /var/yp/securenets op een server met zo’n oude implementatie van TCP/IP is echt een slecht idee en zal leiden tot verlies van NIS-functionaliteit voor grote delen van een netwerk.

Het gebruik van het pakket TCP Wrapper leidt tot langere wachttijden op de NIS-server. De extra vertraging kan net lang genoeg zijn om een timeout te veroorzaken in cliëntprogramma’s, in het bijzonder als het netwerk druk is of de NIS-server traag is. Als een of meer cliënten last hebben van dat symptoom, dan is het verstandig om de cliëntsysteem in kwestie NIS-slaveserver te maken en naar zichzelf te laten wijzen.

29.4.6. Aanmelden voor bepaalde gebruikers blokkeren

In het lab staat de machine basie, die alleen faculteitswerkstation hoort te zijn. Het is niet gewenst die machine uit het NIS-domein te halen, maar het passwd bestand op de master NIS-server bevat nu eenmaal accounts voor zowel de faculteit als de studenten. Hoe kan dat opgelost worden?

Er is een manier om het aanmelden van specifieke gebruikers op een machine te weigeren, zelfs als ze in de NIS-database staan. Daarvoor hoeft er alleen maar -gebruikersnaam met het juiste aantal dubbele punten (zoals bij andere regels) aan het einde van /etc/master.passwd op de cliëntmachine toegevoegd te worden, waar gebruikersnaam de gebruikersnaam van de gebruiker die niet mag aanmelden is. De regel met de geblokkeerde gebruiker moet voor de regel met + staan om NIS-gebruikers toe te staan. Dit gebeurt bij voorkeur met vipw, omdat vipw de wijzigingen aan /etc/master.passwd controleert en ook de wachtwoord database opnieuw bouwt na het wijzigen. Om bijvoorbeeld de gebruiker bill te kunnen laten aanmelden op basie:

basie# vipw
[voeg -bill::::::::: aan het einde toe, exit]
vipw: rebuilding the database...
vipw: done

basie# cat /etc/master.passwd

root:[password]:0:0::0:0:The super-user:/root:/bin/csh
toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
operator:*:2:5::0:0:System &:/:/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/shared/man:/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
-bill:::::::::
+:::::::::

basie#

29.4.7. Netgroups gebruiken

De methode uit het vorige onderdeel werkt prima als er maar voor een beperkt aantal gebruikers en/of machines speciale regels nodig zijn. Op grotere netwerken gebeurt het gewoon dat er wordt vergeten om een aantal gebruikers de aanmeldrechten op gevoelige machines te ontnemen of dat zelfs iedere individuele machine aangepast moet worden, waardoor het voordeel van NIS teniet wordt gedaan: centraal beheren.

De ontwikkelaars van NIS hebben dit probleem opgelost met netgroepen. Het doel en de semantiek kunnen vergeleken worden met de normale groepen die gebruikt worden op UNIX® bestandssystemen. De belangrijkste verschillen zijn de afwezigheid van een numeriek ID en de mogelijkheid om een netgroep aan te maken die zowel gebruikers als andere netgroepen bevat.

Netgroepen zijn ontwikkeld om gebruikt te worden voor grote, complexe netwerken met honderden gebruikers en machines. Aan de ene kant is dat iets Goeds. Aan de andere kant is het wel complex en bijna onmogelijk om netgroepen met een paar eenvoudige voorbeelden uit te leggen. Dat probleem wordt in de rest van dit onderdeel duidelijk gemaakt.

Stel dat de succesvolle implementatie van NIS in het lab de interesse heeft gewekt van een centrale beheerclub. De volgende taak is het uitbreiden van het NIS-domein met een aantal andere machines op de campus. De onderstaande twee tabellen bevatten de namen van de nieuwe gebruikers en de nieuwe machines met een korte beschijving.

GebruikersnamenBeschrijving

alpha, beta

Gewone medewerkers van de IT-afdeling

charlie, delta

Junior medewerkers van de IT-afdeling

echo, foxtrott, golf, …​

Gewone medewerkers

able, baker, …​

Stagiairs

MachinenamenBeschrijving

war, death, famine, pollution

De belangrijkste servers. Alleen senior medewerkers van de IT-afdeling mogen hierop aanmelden.

pride, greed, envy, wrath, lust, sloth

Minder belangrijke servers. Alle leden van de IT-afdeling mogen aanmelden op deze machines.

one, two, three, four, …​

Gewone werkstations. Alleen echte medewerkers mogen zich op deze machines aanmelden.

trashcan

Een erg oude machine zonder kritische data. Zelfs de stagiair mag deze doos gebruiken.

Als deze restricties ingevoerd worden door iedere gebruiker afzonderlijk te blokkeren, dan wordt er een -user regel per systeem toegevoegd aan de passwd voor iedere gebruiker die niet mag aanmelden op dat systeem. Als er maar één regel wordt vergeten, kan dat een probleem opleveren. Wellicht lukt het nog dit juist in te stellen bij de bouw van een machine, maar het wordt echt vergeten de regels toe te voegen voor nieuwe gebruikers in de productiefase. Murphy was tenslotte een optimist.

Het gebruik van netgroepen biedt in deze situatie een aantal voordelen. Niet iedere gebruiker hoeft separaat afgehandeld te worden. Een gebruik kan aan een of meer groepen worden toegevoegd en aanmelden kan voor alle leden van zo’n groep worden toegestaan of geweigerd. Als er een nieuwe machine wordt toegevoegd, dan hoeven alleen de aanmeldrestricties voor de netgroepen te worden ingesteld. Als er een nieuwe gebruiker wordt toegevoegd, dan hoeft die alleen maar aan de juiste netgroepen te worden toegevoegd. Die veranderingen zijn niet van elkaar afhankelijk: geen "voor iedere combinatie van gebruiker en machine moet het volgende …​". Als de NIS-opzet zorgvuldig is gepland, dan hoeft er maar één instellingenbestand gewijzigd te worden om toegang tot machines te geven of te ontnemen.

De eerst stap is het initialiseren van de NIS-afbeelding netgroup. ypinit(8) van FreeBSD maakt deze map niet standaard, maar als die is gemaakt, ondersteunt de NIS-implementatie hem wel. Een lege map wordt als volgt gemaakt:

ellington# vi /var/yp/netgroup

Nu kan hij gevuld worden. In het gebruikte voorbeeld zijn tenminste vier netgroepen: IT-medewerkers, IT-junioren, gewone medewerkers en stagiars.

IT_MW   (,alpha,test-domain)    (,beta,test-domain)
IT_APP  (,charlie,test-domain)  (,delta,test-domain)
USERS   (,echo,test-domain)     (,foxtrott,test-domain) \
        (,golf,test-domain)
STAGS   (,able,test-domain)     (,baker,test-domain)

IT_MW, IT_APP enzovoort, zijn de namen van de netgroepen. Iedere groep tussen haakjes bevat een of meer gebruikersnamen voor die groep. De drie velden binnen een groep zijn:

  1. De naam van de host of namen van de hosts waar de volgende onderdelen geldig zijn. Als er geen hostnaam wordt opgegeven dan is de regel geldig voor alle hosts. Als er wel een hostnaam wordt opgegeven, dan wordt een donker, spookachtig en verwarrend domein betreden.

  2. De naam van de account die bij deze netgroep hoort.

  3. Het NIS-domein voor de account. Er kunnen accounts uit andere NIS-domeinen geïmporteerd worden in een netgroep als een beheerder zo ongelukkig is meerdere NIS-domeinen te hebben.

Al deze velden kunnen jokerkarakters bevatten. Details daarover staan in netgroup(5).

De naam van een netgroep mag niet langer zijn dan acht karakters, zeker niet als er andere besturingssystemen binnen een NIS-domein worden gebruikt. De namen zijn hoofdlettergevoelig: alleen hoofdletters gebruiken voor de namen van netgroepen is een makkelijke manier om onderscheid te kunnen maken tussen gebruikers-, machine- en netgroepnamen.

Sommige NIS-cliënten (andere dan die op FreeBSD draaien) kunnen niet omgaan met netgroepen met veel leden. Sommige oudere versies van SunOS™ gaan bijvoorbeeld lastig doen als een netgroep meer dan 15 leden heeft. Dit kan omzeild worden door meerdere subnetgroepen te maken met 15 gebruikers of minder en een echte netgroep die de subnetgroepen bevat:

BIGGRP1  (,joe1,domain)  (,joe2,domain)  (,joe3,domain) [...]
BIGGRP2  (,joe16,domain)  (,joe17,domain) [...]
BIGGRP3  (,joe31,domain)  (,joe32,domain)
BIGGROUP  BIGGRP1 BIGGRP2 BIGGRP3

Dit proces kan herhaald worden als er meer dan 225 gebruikers in een netgroep moeten.

Het activeren en distribueren van de nieuwe NIS-map is eenvoudig:

ellington# cd /var/yp
ellington# make

Hiermee worden drie nieuwe NIS-afbeeldingen gemaakt: netgroup, netgroup.byhost en netgroup.byuser. Met ypcat(1) kan bekeken worden op de nieuwe NIS-afbeeldingen beschikbaar zijn:

ellington% ypcat -k netgroup
ellington% ypcat -k netgroup.byhost
ellington% ypcat -k netgroup.byuser

De uitvoer van het eerste commando hoort te lijken op de inhoud van /var/yp/netgroup. Het tweede commando geeft geen uitvoer als er geen host-specifieke netgroepen zijn ingesteld. Het derde commando kan gebruikt worden om een lijst van netgroepen voor een gebruiker op te vragen.

Het instellen van de cliënt is redelijk eenvoudig. Om de server war in te stellen hoeft alleen met vipw(8) de volgende regel in de regel daarna vervangen te worden:

+:::::::::

Vervang de bovenstaande regel in de onderstaande.

+@IT_MW:::::::::

Nu worden alleen de gebruikers die in de netgroep IT_MW geïmporteerd in de wachtwoorddatabase van de host war, zodat alleen die gebruikers zich kunnen aanmelden.

Helaas zijn deze beperkingen ook van toepassing op de functie ~ van de shell en alle routines waarmee tussen gebruikersnamen en numerieke gebruikers ID’s wordt gewisseld. Met andere woorden: cd ~user werkt niet, ls -l toont het numerieke ID in plaats van de gebruikersnaam en find . -user joe -print faalt met de foutmelding No such user. Om dit te repareren moeten alle gebruikers geïmporteerd worden, zonder ze het recht te geven aan te melden op een server.

Dit kan gedaan worden door nog een regel aan /etc/master.passwd toe te voegen:

+:::::::::/sbin/nologin

Dit betekent "importeer alle gebruikers, maar vervang de shell door /sbin/nologin". Ieder veld in een passwd regel kan door een standaardwaarde vervangen worden in /etc/master.passwd.

De regel +:::::::::/sbin/nologin moet na +@IT_MW::::::::: komen. Anders krijgen alle gebruikers die uit NIS-komen /sbin/nologin als aanmeldshell.

Na deze wijziging hoeft er nog maar één NIS-afbeelding gewijzigd te worden als er een nieuwe medewerker komt bij de IT-afdeling. Dezelfde aanpak kan gebruikt worden voor de minder belangrijke servers door de oude regel +::::::::: in de lokale versie van /etc/master.passwd door iets als het volgende te vervangen:

+@IT_MW:::::::::
+@IT_APP:::::::::
+:::::::::/sbin/nologin

Voor normale werkstations zijn het de volgende regels:

+@IT_MW:::::::::
+@USERS:::::::::
+:::::::::/sbin/nologin

En dat zou allemaal leuk en aardig zijn als er niet na een paar weken een beleidsverandering komt: de IT-afdeling gaat stagiairs aannemen. De IT-stagiairs mogen de normale werkstations en de minder belangrijke servers gebruiken en de juniorbeheerders mogen gaan aanmelden op de hoofdservers. Dat kan door een nieuwe groep IT_STAG te maken en de nieuwe IT-stagiairs toe te voegen aan die netgroep en dan de instellingen op iedere machine te gaan veranderen. Maar zoals het spreekwoord zegt: "Fouten in een centrale planning leiden tot complete chaos."

Deze situaties kunnen voorkomen worden door gebruik te maken van de mogelijkheid in NIS om netgroepen in netgroepen op te nemen. Het is mogelijk om rolgebaseerde netgroepen te maken. Er kan bijvoorbeeld een netgroep BIGSRV gemaakt worden om het aanmelden op de belangrijke servers te beperken en er kan een andere netgroep SMALLSRV voor de minder belangrijke servers zijn en een derde netgroep met de naam USERBOX voor de normale werkstations. Al die netgroepen kunnen de netgroepen bevatten die op die machines mogen aanmelden. De nieuwe regels in de NIS-afbeelding netgroup zien er dan zo uit:

BIGSRV    IT_MW  IT_APP
SMALLSRV  IT_MW  IT_APP  ITSTAG
USERBOX   IT_MW  ITSTAG USERS

Deze methode voor het instellen van aanmeldbeperkingen werkt redelijk goed als er groepen van machines gemaakt kunnen worden met identieke beperkingen. Helaas blijkt dat eerder uitzondering dan regel. Meestal moet het mogelijk zijn om per machine in te stellen wie zich wel en wie zich niet mogen aanmelden.

Daarom is het ook mogelijk om via machinespecifieke netgroepen de hierboven aangegeven beleidswijziging op te vangen. In dat scenario bevat /etc/master.passwd op iedere machine twee regels die met "+" beginnen. De eerste voegt de netgroep toe met de accounts die op de machine mogen aanmelden en de tweede voegt alle andere accounts toe met /sbin/nologin als shell. Het is verstandig om als naam van de netgroep de machinenaam in "HOOFDLETTERS" te gebruiken. De regels zien er ongeveer als volgt uit:

+@MACHINENAAM:::::::::
+:::::::::/sbin/nologin

Als dit voor alle machines is gedaan, dan hoeven de lokale versies van /etc/master.passwd nooit meer veranderd te worden. Alle toekomstige wijzigingen kunnen dan gemaakt worden door de NIS-afbeelding te wijzigen. Hieronder staat een voorbeeld van een mogelijke netgroep map voor het beschreven scenario met een aantal toevoegingen:

# Definieer eerst de gebruikersgroepen
IT_MW     (,alpha,test-domain)    (,beta,test-domain)
IT_APP    (,charlie,test-domain)  (,delta,test-domain)
DEPT1     (,echo,test-domain)     (,foxtrott,test-domain)
DEPT2     (,golf,test-domain)     (,hotel,test-domain)
DEPT3     (,india,test-domain)    (,juliet,test-domain)
ITSTAG    (,kilo,test-domain)     (,lima,test-domain)
D_STAGS   (,able,test-domain)     (,baker,test-domain)
#
# En nu een aantal groepen op basis van rollen
USERS     DEPT1   DEPT2     DEPT3
BIGSRV    IT_MW   IT_APP
SMALLSRV  IT_MW   IT_APP    ITSTAG
USERBOX   IT_MW   ITSTAG    USERS
#
# Een een groep voor speciale taken.
# Geef echo en golf toegang tot de anti-virus machine.
SECURITY  IT_MW   (,echo,test-domain)  (,golf,test-domain)
#
# Machinegebaseerde netgroepen
# Hoofdservers
WAR       BIGSRV
FAMINE    BIGSRV
# Gebruiker india heeft toegang tot deze server nodig.
POLLUTION  BIGSRV  (,india,test-domain)
#
# Deze is erg belangrijk en heeft strengere toegangseisen nodig.
DEATH     IT_MW
#
# De anti-virus machine als hierboven genoemd.
ONE       SECURITY
#
# Een machine die maar door 1 gebruiker gebruikt mag worden.
TWO       (,hotel,test-domain)
# [...hierna volgen de andere groepen]

Als er een soort database wordt gebruikt om de gebruikersaccounts te beheren, dan is het in ieder geval nodig dat ook het eerste deel van de afbeelding met de databaserapportagehulpmiddelen gemaakt kan worden. Dan krijgen nieuwe gebruikers automatisch toegang tot de machines.

Nog een laatste waarschuwing: het is niet altijd aan te raden gebruik te maken van machinegebaseerde netgroepen. Als er tientallen of zelfs honderden gelijke machines voor bijvoorbeeld studentenruimtes worden uitgerold, dan is het verstandiger rolgebaseerde netgroepen te gebruiken in plaats van machinegebaseerde netgroepen om de grootte van de NIS-afbeelding binnen de perken te houden.

29.4.8. Belangrijk om te onthouden

In een NIS-omgeving werken een aantal dingen wel anders.

  • Als er een gebruiker toegevoegd moet worden, dan moet die alleen toegevoegd worden aan de master NIS-server en mag niet vergeten worden dat de NIS-afbeeldingen herbouwd moeten worden. Als dit wordt vergeten, dan kan de nieuwe gebruiker nergens anders aanmelden dan op de NIS-master. Als bijvoorbeeld een nieuwe gebruiker jsmith toegevoegd moet worden:

    # pw useradd jsmith
    # cd /var/yp
    # make test-domain

    Er kan ook adduser jsmith in plaats van pw useradd jsmith gebruikt worden.

  • De beheeraccounts moeten buiten de NIS-afbeeldingen gehouden worden. Het is niet handig als de beheeraccounts en wachtwoorden naar machines waarop gebruikers zich aanmelden die geen toegang tot die informatie horen te hebben zouden gaan.

  • De NIS-master en slave moeten veilig blijven en zo min mogelijk niet beschikbaar zijn. Als de machine wordt gehackt of als hij wordt uitgeschakeld, dan kunnen er in theorie nogal wat mensen niet meer aanmelden.

    Dit is de belangrijkste zwakte van elk gecentraliseerd beheersysteem. Als de NIS-servers niet goed beschermd worden, dan worden veel gebruikers boos!

29.4.9. NIS v1-compatibiliteit

ypserv voor FreeBSD biedt wat ondersteuning voor NIS v1 cliënten. De NIS-implementatie van FreeBSD gebruikt alleen het NIS v2 protocol, maar andere implementaties bevatten ondersteuning voor het v1 protocol voor achterwaartse compatibiliteit met oudere systemen. De ypbind-daemons die bij deze systemen zitten proberen een binding op te zetten met een NIS v1 server, hoewel dat niet per se ooit nodig is (en ze gaan misschien nog wel door met broadcasten nadat ze een antwoord van een v2 server hebben ontvangen). Het is belangrijk om te melden dat hoewel ondersteuning voor gewone cliëntoproepen aanwezig is, deze versie van ypserv geen overdrachtsverzoeken voor v1-afbeeldingen af kan handelen. Daarom kan ypserv niet gebruikt worden als master of slave in combinatie met oudere NIS-servers die alleen het v1 protocol ondersteunen. Gelukkig worden er in deze tijd niet meer zoveel van deze servers gebruikt.

29.4.10. NIS-servers die ook NIS-cliënten zijn

Het is belangrijk voorzichtig om te gaan met het draaien van ypserv in een multi-server domein waar de server machines ook NIS-cliënten zijn. Het is in het algemeen verstandiger om de servers te dwingen met zichzelf te binden dan ze toe te staan een bindverzoek te broadcasten en het risico te lopen dat ze een binding met elkaar maken. Er kunnen vreemde fouten optreden als een van de servers plat gaat als er andere servers van die server afhankelijk zijn. Na verloop van tijd treedt op de cliënten wel een timeout op en verbinden ze met een andere server, maar de daarmee gepaard gaande vertraging kan aanzienlijk zijn en de foutmodus is nog steeds van toepassing, omdat de servers dan toch weer opnieuw een verbinding met elkaar kunnen vinden.

Het is mogelijk een host aan een specifieke server te binden door aan ypbind de vlag -S mee te geven. Om dit niet iedere keer handmatig na een herstart te hoeven uitvoeren, kan de volgende regel worden opgenomen in /etc/rc.conf van de NIS-server:

nis_client_enable="YES"	# start ook het cliënt gedeelte
nis_client_flags="-S NIS domain,server"

In ypbind(8) staat meer informatie.

29.4.11. Wachtwoordformaten

Een van de meest voorkomende problemen bij het implementeren van NIS is de compatibiliteit van het wachtwoordformaat. Als een NIS-server wachtwoorden gebruikt die met DES gecodeerd zijn, dan kunnen alleen cliënten die ook DES gebruiken ondersteund worden. Als er bijvoorbeeld Solaris™ NIS-cliënten in een netwerk zijn, dan moet er vrijwel zeker gebruik gemaakt worden van met DES gecodeerde wachtwoorden.

Van welk formaat cliënten en servers gebruik maken is te zien in /etc/login.conf. Als een host gebruik maakt van met DES gecodeerde wachtwoorden, dan staat er in de klasse default een regel als de volgende:

default:\
	:passwd_format=des:\
	:copyright=/etc/COPYRIGHT:\
	[Overige regels weggelaten]

Andere mogelijke waarden voor passwd_format zijn blf en md5 (respectievelijk voor Blowfish en MD5 gecodeerde wachtwoorden).

Als er wijzigingen gemaakt zijn aan /etc/login.conf dan moet de login capability database herbouwd worden door het volgende commando als root uit te voeren:

# cap_mkdb /etc/login.conf

Het formaat van de wachtwoorden die al in /etc/master.passwd staan worden niet bijgewerkt totdat een gebruiker zijn wachtwoord voor de eerste keer wijzigt nadat de login capability database is herbouwd.

Om te zorgen dat de wachtwoorden in het gekozen formaat zijn gecodeerd, moet daarna gecontroleerd worden of de waarde crypt_default in /etc/auth.conf de voorkeur geeft aan het gekozen formaat. Om dat te realiseren dient het gekozen formaat vooraan gezet te worden in de lijst. Als er bijvoorbeeld gebruik gemaakt wordt van DES gecodeerde wachtwoorden, dan hoort de regel er als volgt uit te zien:

crypt_default	=	des blf md5

Als de bovenstaande stappen op alle FreeBSD gebaseerde NIS-servers en cliënten zijn uitgevoerd, dan is het zeker dat ze het allemaal eens zijn over welk wachtwoordformaat er op het netwerk wordt gebruikt. Als er problemen zijn bij de authenticatie op een NIS-cliënt, dan is dit een prima startpunt voor het uitzoeken waar de problemen vandaan komen. Nogmaals: als er een NIS-server in een heterogene omgeving wordt geplaatst, dan is het waarschijnlijk dat er gebruik gemaakt moet worden van DES op alle systemen, omdat dat de laagst overeenkomende standaard is.

29.5. Automatisch netwerk instellen (DHCP)

29.5.1. Wat is DHCP?

DHCP, het Dynamic Host Configuration Protocol, schrijft voor hoe een systeem verbinding kan maken met een netwerk en hoe het de benodigde informatie kan krijgen om met dat netwerk te communiceren. FreeBSD gebruikt de OpenBSD dhclient welke uit OpenBSD 3.7 komt. Alle informatie over dhclient kan zowel voor de ISC als de OpenBSD DHCP-cliënt gebruikt worden. De DHCP-server zit bij de ISC-distributie.

29.5.2. Wat behandeld wordt

In dit onderdeel worden de cliëntcomponenten van de ISC en OpenBSD DHCP-cliënt en de servercomponenten van het ISC DHCP-systeem beschreven. Het programma voor de cliënt, dhclient, zit standaard in FreeBSD en de server is beschikbaar via de port net/isc-dhcp42-server. Naast de onderstaande informatie, zijn de hulppagina’s van dhclient(8), dhcp-options(5) en dhclient.conf(5) bruikbare bronnen.

29.5.3. Hoe het werkt

Als dhclient, de DHCP-cliënt, wordt uitgevoerd op een cliëntmachine, dan begint die met het broadcasten van verzoeken om instellingeninformatie. Standaard worden deze verzoeken op UDP poort 68 gedaan. De server antwoordt op UDP 67 en geeft de cliënt een IP-adres en andere relevante netwerkinformatie, zoals een netmasker, router en DNS-servers. Al die informatie komt in de vorm van een DHCP "lease" en is voor een bepaalde tijd geldig (die is ingesteld door de beheerder van de DHCP-server). Op die manier kunnen IP-adressen voor cliënten die niet langer met het netwerk verbonden zijn (stale) automatisch weer ingenomen worden.

DHCP-cliënten kunnen veel informatie van de server krijgen. Er staat een uitputtende lijst in dhcp-options(5).

29.5.4. FreeBSD integratie

FreeBSD integreert de OpenBSD DHCP-cliënt dhclient volledig. Er is ondersteuning voor de DHCP-cliënt in zowel het installatieprogramma als in het basissysteem, waardoor het niet noodzakelijk is om kennis te hebben van het maken van netwerkinstellingen voor het netwerk waar een DHCP-server draait.

DHCP wordt ondersteund door sysinstall. Bij het instellen van een netwerkinterface binnen sysinstall is de tweede vraag: "Wil je proberen de interface met DHCP in te stellen?" Als het antwoord bevestigend luidt, dan wordt dhclient uitgevoerd en als dat succesvol verloopt, dan worden de netwerkinstellingen automatisch ingevuld.

Voor het gebruiken van DHCP bij het opstarten van het systeem zijn twee instellingen nodig:

  • Het apparaat bpf moet in de kernel gecompileerd zijn. Dit kan door device bpf aan het bestand met kernelinstellingen toe te voegen en de kernel te herbouwen. Meer informatie over het bouwen van een kernel staat in De FreeBSD-kernel instellen.

    Het apparaat bpf is al onderdeel van de GENERIC kernel die bij FreeBSD zit, dus als er geen sprake is van een aangepaste kernel, dan hoeft er geen nieuwe gemaakt te worden om DHCP aan te praat te krijgen.

    Voor de lezer die bijzonder begaan is met beveiliging, is het belangrijk aan te geven dat bpf ook het apparaat is waardoor pakketsnuffelaars hun werk kunnen doen (hoewel ze nog steeds als root moeten draaien). bpfis noodzakelijk voor DHCP, maar als beveiliging bijzonder belangrijk is, dan hoort bpf waarschijnlijk niet in een kernel te zitten omdat de verwachting dat er in de toekomst ooit DHCP gebruikt gaat worden.

  • Standaard draait de DHCP-synchronisatie op FreeBSD in de achtergrond, of asynchroon. Andere opstartscripten gaan verder terwijl DHCP wordt voltooid, wat het opstarten van het systeem versnelt.

    DHCP in de achtergrond werkt goed als de DHCP-server snel op verzoeken reageert en het DHCP-configuratieproces snel gaat. Op sommige systemen kan het lang duren voordat DHCP klaar is. Als netwerkdiensten proberen te draaien voordat DHCP voltooid is, zullen ze falen. Door DHCP in synchrone modus te draaien wordt dit probleem voorkomen en wordt het opstarten gepauzeerd totdat de DHCP-configuratie voltooid is.

    Gebruik om in de achtergrond verbinding te maken met een DHCP-server terwijl andere opstartscripts verder gaan (asynchrone modus) de waarde “DHCP” in /etc/rc.conf:

    ifconfig_fxp0="DHCP"

    Gebruik om het opstarten te pauzeren totdat DHCP voltooid is de synchrone modus met waarde “SYNDHCP”:

    ifconfig_fxp0="SYNDHCP"

    Vervang fxp0 zoals getoond in deze voorbeelden met de naam van de interface dat dynamisch geconfigureerd moet worden, zoals getoond in Netwerkkaarten instellen.

    Als er een andere lokatie voor dhclient wordt gebruikt of als er extra parameters aan dhclient meegegeven moeten worden, dan dient ook iets als het volgende toegevoegd te worden:

    dhclient_program="/sbin/dhclient"
    dhclient_flags=""

De DHCP-server, dhcpd, zit bij de port net/isc-dhcp42-server in de Portscollectie. Deze port bevat de ISC DHCP-server en documentatie.

29.5.5. Bestanden

  • /etc/dhclient.conf

    Voor dhclient is een instellingenbestand /etc/dhclient.conf nodig. Dat bestand bevat meestal alleen maar commentaar, omdat de standaardinstellingen redelijk zinvol zijn. Dit bestand wordt beschreven in dhclient.conf(5).

  • /sbin/dhclient

    dhclient is statisch gelinkt en staat in /sbin. Er staat meer informatie over dhclient in dhclient(8).

  • /sbin/dhclient-script

    dhclient-script is het FreeBSD-specifieke DHCP-cliënt instellingenscript. Het wordt beschreven in dhclient-script(8), maar het is niet nodig het te wijzigen om goed te werken.

  • /var/db/dhclient.leases.interface

    De DHCP-cliënt houdt in dit bestand een database bij van geldige leases, die naar een logboekbestand worden geschreven. In dhclient.leases(5) staat een iets uitgebreidere beschrijving.

29.5.6. Verder lezen

Het DHCP-protocol staat volledig beschreven in RFC 2131. Er is nog een bron van informatie ingesteld op http://www.dhcp.org/.

29.5.7. Een DHCP-server installeren en instellen

29.5.7.1. Wat behandeld wordt

In dit onderdeel wordt beschreven hoe een FreeBSD systeem zo ingesteld kan worden dat het opereert als DHCP-server door gebruik te maken van de ISC (Internet Systems Consortium) implementatie van de DHCP-server.

De server wordt niet geleverd als deel van FreeBSD en om deze dienst aan te bieden dient de port net/isc-dhcp42-server geïnstalleerd te worden. In Applicaties installeren. pakketten en ports staat meer informatie over de Portscollectie.

29.5.7.2. DHCP-serverinstallatie

Om een FreeBSD systeem in te stellen als DHCP-server moet het apparaat bpf(4) in de kernel zijn opgenomen. Om dit te doen dient device bpf aan het bestand met kernelinstellingen toegevoegd te worden en dient de kernel herbouwd te worden. Meer informatie over het bouwen van kernels staat in De FreeBSD-kernel instellen.

Het apparaat bpf is al onderdeel van de GENERIC kernel die bij FreeBSD, dus het is meestal niet nodig om een aangepaste kernel te bouwen om DHCP aan de praat te krijgen.

Het is belangrijk te vermelden dat bpf ook het apparaat is waardoor pakketsnuffelaars kunnen werken (hoewel de programma’s die er gebruik van maken wel bijzondere toegang nodig hebben). bpfis verplicht voor DHCP, maar als beveiliging van belang is, dan is het waarschijnlijk niet verstandig om bpf in een kernel op te nemen alleen omdat er in de toekomst misschien ooit DHCP gebruikt gaat worden.

Hierna dient het standaardbestand dhcpd.conf dat door de port net/isc-dhcp42-server is geïnstalleerd gewijzigd te worden. Standaard is dit /usr/local/etc/dhcpd.conf.sample en dit bestand dient gekopieerd te worden naar /usr/local/etc/dhcpd.conf voordat de wijzigingen worden gemaakt.

29.5.7.3. De DHCP-server instellen

dhcpd.conf is opgebouwd uit declaraties over subnetten en hosts en is wellicht het meest eenvoudig te beschrijven met een voorbeeld:

option domain-name "example.com"; (1)
option domain-name-servers 192.168.4.100; (2)
option subnet-mask 255.255.255.0; (3)

default-lease-time 3600; (4)
max-lease-time 86400; (5)
ddns-update-style none; (6)

subnet 192.168.4.0 netmask 255.255.255.0 {
  range 192.168.4.129 192.168.4.254; (7)
  option routers 192.168.4.1; (8)
}

host mailhost {
  hardware ethernet 02:03:04:05:06:07; (9)
  fixed-address mailhost.example.com; (10)
}
1Deze optie geeft het domein aan dat door cliënten als standaard zoekdomein wordt gebruikt. In resolv.conf(5) staat meer over wat dat betekent.
2Deze optie beschrijft een door komma’s gescheiden lijst met DNS-servers die de cliënt moet gebruiken.
3Het netmasker dat aan de cliënten wordt voorgeschreven.
4Een cliënt kan om een bepaalde duur vragen die een lease geldig is. Anders geeft de server aan wanneer de lease vervalt (in seconden).
5Dit is de maximale duur voor een lease die de server toestaat. Als een cliënt vraagt om een langere lease, dan wordt die wel verstrekt, maar is de maar geldig gedurende max-lease-time seconden.
6Deze optie geeft aan of de DHCP-server moet proberen de DNS-server bij te werken als een lease is geaccepteerd of wordt vrijgegeven. In de ISC implementatie is deze optie verplicht.
7Dit geeft aan welke IP-adressen in de groep met adressen zitten die zijn gereserveerd om uitgegeven te worden aan cliënten. Alle IP-adressen tussen de aangegeven adressen en die adressen zelf worden aan cliënten uitgegeven.
8Geeft de default gateway aan die aan de cliënten wordt voorgeschreven.
9Het hardware MAC-adres van een host, zodat de DHCP-server een host kan herkennen als die een verzoek doet.
10Geeft een host aan die altijd hetzelfde IP-adres moet krijgen. Hier kan een hostnaam gebruikt worden, omdat de DHCP-server de hostnaam zelf opzoekt voordat de lease-informatie terug wordt gegeven.

Wanneer u klaar bent met het schrijven van uw dhcpd.conf, dient u de DHCP-server in /etc/rc.conf aan te zetten, door het volgende toe te voegen:

dhcpd_enable="YES"
dhcpd_ifaces="dc0"

Vervang de interfacenaam dc0 door de interface (of interfaces, gescheiden door witruimtes) waarop uw DHCP-server moet luisteren naar DHCP-verzoeken van cliënten.

Daarna kunt u doorgaan met het starten van de server door het volgende commando te geven:

# service isc-dhcpd start

Als er later wijzigingen in de instellingen gemaakt moeten worden, dan is het belangrijk te onthouden dat het sturen van een SIGHUP signaal naar dhcpd_niet_ resulteert in het opnieuw laden van de instellingen, zoals voor de meeste daemons geldt. Voor deze daemon dient een signaal SIGTERM gestuurd te worden om het proces te stoppen. Daarna dient de daemon met het hiervoor beschreven commando weer gestart worden.

29.5.7.4. Bestanden

  • /usr/local/sbin/dhcpd

    dhcpd is statisch gelinkt en staat in /usr/local/sbin. In de hulppagina voor dhcpd(8) die meekomt met de port staat meer informatie over dhcpd.

  • /usr/local/etc/dhcpd.conf

    dhcpd heeft een instellingenbestand, /usr/local/etc/dhcpd.conf, nodig voordat de daemon diensten aan cliënten kan leveren. Het bestand moet alle informatie bevatten die aan cliënten gegeven moet worden en de informatie die nodig is voor het draaien van de dienst. Dit instellingenbestand staat beschreven in de hulppagina voor dhcpd.conf(5) die meekomt met de port.

  • /var/db/dhcpd.leases

    De DHCP-server houdt in dit bestand een database bij met leases die zijn uitgegeven en die naar een logboek worden geschreven. In de hulppagina dhcpd.leases(5) die bij de port zit wordt dit uitvoeriger beschreven.

  • /usr/local/sbin/dhcrelay

    dhcrelay wordt in uitgebreidere omgevingen gebruikt waar de ene DHCP-server een verzoek van een cliënt naar een andere DHCP-server op een ander netwerk doorstuurt. Als deze functionaliteit nodig is, kan die beschikbaar komen door de port net/isc-dhcp42-relay te installeren. De hulppagina voor dhcrelay(8) die bij de port zit bevat meer details.

29.6. Domeinnaamsysteem (DNS)

29.6.1. Overzicht

FreeBSD gebruikt standaard een versie van BIND (Berkeley Internet Name Domain), wat de meest gebruikte implementatie van het DNS-protocol is. DNS is het protocol waarmee namen aan IP-adressen gebonden worden en vice versa. Zo wordt bijvoorbeeld op een zoekopdracht voor www.FreeBSD.org geantwoord met het IP-adres van de webserver van het FreeBSD Project en op een zoekopdracht voor ftp.FreeBSD.org wordt geantwoord met het IP-adres van de bijbehorende FTP-machine. Het tegenovergestelde kan ook gebeuren. Een zoekopdracht voor een IP-adres kan de bijbehorende hostnaam opleveren. Het is niet nodig om een naamserver te draaien om op een systeem zoekopdrachten met DNS uit te voeren.

FreeBSD wordt momenteel standaard geleverd met de BIND9 DNS-serversoftware. Onze installatie biedt verbeterde beveilingsmogelijkheden, een nieuwe indeling van het bestandssysteem en geautomatiseerde configuratie van chroot(8).

DNS wordt op Internet onderhouden door een enigszins complex systeem van autoritaire root, Top Level Domain (TLD), en andere kleinschaligere naamservers die individuele domeininformatie hosten en cachen.

Op dit moment wordt BIND beheerd door het Internet Systems Consortium https://www.isc.org/.

29.6.2. Terminologie

Om dit document te begrijpen moeten een aantal termen gerelateerd aan DNS begrepen worden.

TermDefinitie

Voorwaartse DNS

Het afbeelden van hostnamen op IP-adressen.

Herkomst (origin)

Verwijst naar het domein dat door een bepaald zonebestand wordt gedekt.

named, BIND

Vaak gebruikte namen voor het naamserverpakket BIND in FreeBSD.

Resolver

Een systeemproces waarmee een machine zoekopdrachten om zoneinformatie aan een naamserver geeft.

Reverse DNS

Het afbeelden van IP-adressen op hostnamen.

Rootzone

Het begin van de Internet zonehiërarchie. Alle zones vallen onder de rootzone, net zoals alle bestanden in een bestandssysteem onder de rootmap vallen.

Zone

Een individueel domein, subdomein of een deel van de DNS die door dezelfde autoriteit wordt beheerd.

Voorbeelden van zones:

  • . is hoe de rootzone normaliter in de documentatie genoemd wordt.

  • org. is een Top Level Domain (TLD) onder de rootzone.

  • example.org. is een zone onder het TLD org..

  • 1.168.192.in-addr.arpa is een zone die naar alle IP-adressen verwijst die onder de IP-adresruimte 192.168.1.* vallen.

Zoals te zien is staat het specifiekere deel van een hostnaam aan de linkerkant. Zo is bijvoorbeeld example.org. specifieker dan org. en is org. specifieker dan de rootzone. De indeling van ieder deel van een hostnaam lijkt veel op een bestandssysteem: de map /dev valt onder de root, enzovoort.

29.6.3. Redenen om een naamserver te draaien

Naamservers bestaan in het algemeen in twee smaken: autoratieve naamservers en caching (ook bekend als resolving) naamservers.

Er is een autoratieve naamserver nodig als:

  • Het gewenst is om DNS-informatie aan te bieden aan de wereld om met autoriteit op verzoeken te antwoorden.

  • Een domein, zoals example.org, is geregistreerd en er IP-adressen aan hostnamen die daaronder liggen toegewezen moeten worden.

  • Een IP-adresblok omgekeerde DNS-ingangen nodig heeft (IP naar hostnaam).

  • Een omgekeerde of tweede naamserver, die een slaaf wordt genoemd, moet antwoorden op verzoeken.

Er is een caching naamserver nodig als:

  • Een lokale DNS-server kan cachen en wellicht sneller kan antwoorden dan een naamserver die verder weg staat.

Als er een verzoek wordt gedaan voor www.FreeBSD.org, dan doet de resolver meestal een verzoek bij de naamserver van de ISP die de uplink levert en ontvangt daarop een antwoord. Met een lokale, caching DNS-server hoeft het verzoek maar één keer door de caching DNS-server naar de buitenwereld gedaan te worden. Voor aanvullende verzoeken hoeft niet buiten het lokale netwerk te gaan omdat het al lokaal in de cache staat.

29.6.4. Hoe het werkt

De daemon BIND heet in FreeBSD named.

BestandBeschrijving

named(8)

De daemon BIND.

rndc(8)

Naamserverbeheerprogramma.

/etc/namedb

Map waar zoneinformatie van BIND staat.

/etc/namedb/named.conf

Instellingenbestand van de daemon.

Afhankelijk van hoe en gegeven zone op de server is geconfigureerd, staan de bestanden gerelateerd aan die zone in de submappen master, slave, of dynamic van de map /etc/namedb. Deze bestanden bevatten de DNS-informatie die door de naamserver als antwoord op zoekopdrachten gegeven zal worden.

29.6.5. BIND starten

Omdat BIND standaard wordt geïnstalleerd, is het instellen relatief eenvoudig.

De standaardconfiguratie van named is die van een eenvoudige resolverende naamserver, draaiende in een chroot(8)-omgeving, en beperkt tot het luisteren op het lokale IPv4-teruglusadres (127.0.0.1). Gebruik het volgende commando om de server eenmaal met deze configuratie te starten:

# service named onestart

Om er zeker van te zijn dat de daemon named elke keer bij het opstarten gestart wordt, moet de volgende regel in /etc/rc.conf gezet worden:

named_enable="YES"

Het is duidelijk dat er vele instelopties voor /etc/namedb/named.conf zijn die buiten het bereik van dit document vallen. Als u echter geïnteresseerd bent in de opstartopties voor named op FreeBSD, bekijk dan de named_*-vlaggen in /etc/defaults/rc.conf en raadpleeg de handleidingpagina rc.conf(5). De sectie Gebruik van rc met FreeBSD is ook nuttig om te lezen.

29.6.6. Instellingenbestanden

Instellingenbestanden voor named bevinden zich momenteel in /etc/namedb en moeten gewijzigd worden voor gebruik, tenzij er alleen een eenvoudige resolver nodig is. Hier vindt de meeste configuratie plaats.

29.6.6.1. /etc/namedb/named.conf

// $FreeBSD$
//
// In de handleidingpagina's named.conf(5) en named(8), en in de
// documentatie in /usr/shared/doc/bind9 zijn meer details te vinden.
//
// Voor het opzetten van een autoratieve server is een grondig begrip
// van de werking van DNS noodzakelijk.  Zelfs eenvoudige fouten kunnen // de werking verstoren voor beïnvloede partijen of veel onnodig
// Internetverkeer veroorzaken.

options {
       // Alle namen van bestanden en paden zijn relatief aan de chroot-map,
       // indien aanwezig, en moeten volledig gekwalificeerd zijn.
       directory       "/etc/namedb/working";
       pid-file        "/var/run/named/pid"
       dump-file       "/var/dump/named_dump.db"
       statistics-file "/var/stats/named.stats"

// Als named alleen als een lokale resolver gebruikt wordt, is dit een
// veilige standaardinstelling.  Om named toegang tot het netwerk te
// verschaffen, dient deze optie gecommentarieerd te worden, het
// juiste IP-adres opgegeven te worden, of dient deze optie verwijderd
// te worden.
       listen-on       { 127.0.0.1; };

// Als u IPv6 aan heeft staan op dit systeem, dient deze optie
// uitgecommentarieerd te worden om als lokale resolver te dienen.  Om
// toegang tot het netwerk te verschaffen, dient een IPv6-adres of het
// sleutelwoord "any" gegeven te worden.
//     listen-on-v6    { ::1; };

// Deze zones zijn reeds opgenomen door de lege zones die hieronder
// staan.  Als u de gerelateerde lege zones hieronder verwijdert,
// dienen deze regels uitgecommentarieerd te worden.
        disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
        disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
        disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";

// Als er een DNS-server beschikbaar is bij een upstream provider dan
// kan het IP-adres op de regel hieronder ingegeven worden en kan die
// geactiveerd worden.  Hierdoor wordt voordeel gehaald uit de cache,
// waardoor het algehele DNS-verkeer op het Internet vermindert.
/*
       forwarders {
               127.0.0.1;
       };

*/

// Als de 'forwarders'-clausule niet leeg is, is de standaard om "forward
// first" te gebruiken, welke terug zal vallen op het versturen van een
// verzoek naar uw lokale server als de naamservers in 'forwarders' het
// antwoord niet weten.  Als alternatief kunt u uw naamserver dwingen om
// nooit zelf verzoeken in te dienen door de volgende regel aan te
// zetten:
//     forward only;

// Als u forwarding automatisch wilt configureren gebaseerd op de regels
// in /etc/resolv.conf, verwijder dan het commentaar van de volgende
// regel en stel in /etc/rc.conf named_auto_forward=yes in.  U kunt ook
// named_auto_forward_only aanzetten (het effect hiervan is hierboven
// beschreven).
//      include "/etc/namedb/auto_forward.conf";

Zoals al in het commentaar staat kan van een cache in de uplink geprofiteerd worden als forwarders ingeschakeld worden. Onder normale omstandigheden maakt een naamserver recursief verzoeken tot het Internet op zoek naar zekere naamservers tot er een antwoord komt waar het naar op zoek is. Door de bovenstaande optie in te schakelen wordt eerst de uplink naamserver (of de opgegeven naamserver) gevraagd, waardoor er gebruik gemaakt kan worden van de cache van die server. Als die uplink naamserver een drukke, snelle naamserver is, kan het erg de moeite waard zijn om dit aan te zetten.

127.0.0.1 werkt hier niet. Verander dit IP-adres in een naamserver in de uplink.

/*
	  Moderne versies van BIND gebruiken standaard een random
	  UDP-poort voor elk uitgaand verzoek om de kans op cache
	  poisoning drastisch te verminderen.  Alle gebruikers wordt met
	  klem verzocht om deze mogelijkheid te gebruiken en hun
	  firewalls overeenkomstig aan te passen.

	  ALS EEN LAATSTE UITVLUCHT om een beperkende firewall te
	  omzeilen kunt u proberen om onderstaande optie aan te zetten.
	  Het gebruik van deze optie vermindert uw kans om een cache
	  poisoning aanval te weerstaan aanzienlijk, en dient indien
	  mogelijk te worden vermeden.

	  Vervang NNNNN in het voorbeeld door een getal tussen 49160 en
	  65530.
	*/
	// query-source address * port NNNNN;
};

// Als er een lokale naamserver wordt gebruikt, vergeet dan niet om
// eerst 127.0.0.1 in /etc/resolv.conf te zetten zodat die gevraagd
// wordt.  Controleer ook dat het in /etc/rc.conf is aangezet.

// Het traditionele root-hint-mechanisme.  Gebruik dit OF de
// onderstaande slaafzones.
zone "." { type hint; file "/etc/namedb/named.root"; };

/*	Het slaaf maken van de volgende zones vanaf de root-naamservers
	heeft een aantal aanzienlijke voordelen:
	1. Snellere lokale resolutie voor uw gebruikers
	2. Geen vals verkeer dat vanaf uw netwerk naar de roots wordt verzonden
	3. Betere weerstand tegen elke mogelijk falen van de rootserver/DDoS

	Wel is het zo dat deze methode meer toezicht vraagt dan het
	hintbestand om er zeker van te zijn dat een onverwachte
	faalmodus uw server niet heeft lamgelegd.  Naamservers die
	veel clienten serveren zullen meer voordeel uit deze aanpak
	halen dan individuele hosts.  Met zorg gebruiken.

	Verwijder het commentaar uit de onderstaande regels en
	commentarieer de bovenstaande hintzone om dit mechanisme te
	gebruiken.

	Zoals gedocumenteerd op http://dns.icann.org/services/axfr/ zijn deze
	zones: "." (de root), ARPA, IN-ADDR.ARPA, IP6.ARPA en ROOT-SERVERS.NET
	beschikbaar voor AXFR van deze servers op IPv4 en IPv6:
	xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
*/

zone "." {
	type slave;
	file "/etc/namedb/slave/root.slave";
	masters {
		192.5.5.241;	// F.ROOT-SERVERS.NET.
	};
	notify no;
};

zone "arpa" {
	type slave;
	file "/etc/namedb/slave/arpa.slave";
	masters {
		192.5.5.241;	// F.ROOT-SERVERS.NET.
	};
	notify no;
};

/*	Het lokaal serveren van de volgende zones voorkomt dat enig
	verzoek voor deze zones uw netwerk verlaat en naar de
	root-naamservers gaat.  Dit heeft twee aanzienlijke voordelen:
	1. Snellere lokale resolutie voor uw gebruikers
	2. Er zal geen vals verkeer vanaf uw netwerk naar de roots worden verzonden
*/
// RFCs 1912 en 5735 (en BCP32 voor localhost)
zone "localhost"	{ type master; file "/etc/namedb/master/localhost-forward.db"; };
zone "127.in-addr.arpa"	{ type master; file "/etc/namedb/master/localhost-reverse.db"; };
zone "255.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// RFC 1912-stijl zone voor IPv6 localhost adres
zone "0.ip6.arpa"	{ type master; file "/etc/namedb/master/localhost-reverse.db"; };

// "Dit" netwerk (RFCs 1912 en 5735)
zone "0.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// Netwerken voor privaat gebruik (RFC 1918 en 5735)
zone "10.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "16.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "17.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "18.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "19.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "20.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "21.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "22.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "23.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "24.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "25.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "26.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "27.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "28.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "29.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "30.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "31.172.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "168.192.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// Lokale link/APIPA (RFCs 3927 en 5735)
zone "254.169.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// IETF protocol-toewijzingen (RFCs 5735 en 5736)
zone "0.0.192.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// TEST-NET-[1-3] voor documentatie (RFCs 5735 en 5737)
zone "2.0.192.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "100.51.198.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };
zone "113.0.203.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// IPv6-bereik voor documentatie (RFC 3849)
zone "8.b.d.0.1.0.0.2.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; };

// Domeinnamen voor documentatie en testen (BCP 32)
zone "test" { type master; file "/etc/namedb/master/empty.db"; };
zone "example" { type master; file "/etc/namedb/master/empty.db"; };
zone "invalid" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.com" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.net" { type master; file "/etc/namedb/master/empty.db"; };
zone "example.org" { type master; file "/etc/namedb/master/empty.db"; };

// Router benchmarken (RFC 2544 en 5735)
zone "18.198.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "19.198.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }

// Gereserveerd door IANA - oude ruimte van klasse E (RFC 5735)
zone "240.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "241.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "242.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "243.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "244.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "245.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "246.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "247.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "248.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "249.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "250.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "251.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "252.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "253.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "254.in-addr.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }

// Niet-toegewezen IPv6-adressen (RFC 4291)
zone "1.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "2.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "3.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "4.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "5.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "6.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "7.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "8.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "9.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "a.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "b.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "c.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "d.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "e.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "0.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "1.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "2.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "3.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "4.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "5.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "6.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "7.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "8.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "9.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "a.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "b.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "0.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "1.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "2.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "3.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "4.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "5.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "6.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "7.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }

// IPv6 ULA (RFC 4193)
zone "c.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "d.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }

// IPv6 lokale link (RFC 4291)
zone "8.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "9.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "a.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "b.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }

// IPv6 verouderde site-lokale adressen (RFC 3879)
zone "c.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "d.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "e.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }
zone "f.e.f.ip6.arpa"	{ type master; file "/etc/namedb/master/empty.db"; }

// IP6.INT is verouderd (RFC 4159)
zone "ip6.int"	{ type master; file "/etc/namedb/master/empty.db"; }

// NB: De IP-adressen hieronder zijn bedoeld als voorbeeld en dienen
//     niet gebruikt te worden!
//
// Voorbeeld instellingen voor slaafzones.  Het kan handig zijn om
// tenminste slaaf te worden voor de zone waar de host onderdeel van
// uitmaakt.  Bij uw netwerkbeheerder kan het IP-adres van de
// verantwoordelijke meester-naamserver nagevraagd worden.
//
// Vergeet niet om de omgekeerde lookup-zone op te nemen!
// Dit is genoemd na de eerste bytes van het IP-adres, in omgekeerde
// volgorde, met daarachter ".IN-ADDR.ARPA", of "IP6.ARPA" voor IPv6.
//
// Het is van groot belang om de werking van DNS en BIND te begrijpen
// voordat er een meester-zone wordt opgezet.  Er zijn nogal wat
// onverwachte valkuilen.  Het opzetten van een slaafzone is
// gewoonlijk eenvoudiger.
//
// NB: Zet de onderstaande voorbeelden niet blindelings aan. :-)
// Gebruik in plaats hiervan echte namen en adressen.
/* Een voorbeeld van een dynamische zone
key "exampleorgkey" {
       algorithm hmac-md5;
       secret "sf87HJqjkqh8ac87a02lla==";
};

zone "example.org" {
       type master;
       allow-update {
               key "exampleorgkey";
       };
       file "/etc/namedb/dynamic/example.org";
};
*/

/* Voorbeeld van een omgekeerde slaafzone
zone "1.168.192.in-addr.arpa" {
       type slave;
       file "/etc/namedb/slave/1.168.192.in-addr.arpa";
       masters {
               192.168.1.1;
       };
};
*/

In named.conf zijn dit voorbeelden van slaafregels voor een voorwaartse en een omgekeerde zone.

Voor iedere nieuwe zone die wordt aangeboden dient een nieuwe instelling voor de zone aan named.conf toegevoegd te worden.

De eenvoudigste instelling voor de zone example.org kan er als volgt uitzien:

zone "example.org" {
	type master;
	file "master/example.org";
};

De zone is een master, zoals aangegeven door het statement type, waarvan de zoneinformatie in /etc/namedb/example.org staat, zoals het statement file aangeeft.

zone "example.org" {
	type slave;
	file "slave/example.org";
};

In het geval van de slaaf wordt de zoneinformatie voor een zone overgedragen van de master naamserver en opgeslagen in het ingestelde bestand. Als de masterserver het niet meer doet of niet bereikbaar is, dan heeft de slaveserver de overgedragen zoneinformatie nog en kan het die aanbieden.

29.6.6.2. Zonebestanden

Een voorbeeldbestand voor een masterzone voor example.org (bestaande binnen /etc/namedb/master/example.org) ziet er als volgt uit:

$TTL 3600        ; 1 uur standaard TTL
example.org.     IN      SOA      ns1.example.org. admin.example.org. (
                                 2006051501      ; Serienummer
                                 10800           ; Verversen
                                 3600            ; Opnieuw proberen
                                 604800          ; Verlopen
                                 300             ; Negatieve antwoord-TTL
                         )

; DNS Servers
                 IN      NS      ns1.example.org.
                 IN      NS      ns2.example.org.

; MX Records
                 IN      MX 10   mx.example.org.
                 IN      MX 20   mail.example.org.

                 IN      A       192.168.1.1

; Machinenamen
localhost        IN      A       127.0.0.1
ns1              IN      A       192.168.1.2
ns2              IN      A       192.168.1.3
mail             IN      A       192.168.1.4
mx               IN      A       192.168.1.5

; Aliases
www              IN      CNAME   example.org.

Iedere hostnaam die eindigt op een "." is een exacte hostnaam, terwijl alles zonder een "." op het einde relatief is aan de oorsprong. Zo wordt ns1 bijvoorbeeld vertaald naar ns1.example.org..

De regels in een zonebestand volgen de volgende opmaak:

recordnaam      IN recordtype   waarde

De meest gebruikte DNS-records:

SOA

begin van autoriteit (start of authority)

NS

een bevoegde (autoratieve) name server

A

een hostadres

CNAME

de canonieke naam voor een alias

MX

mail exchanger

PTR

een domeinnaam pointer (gebruikt in omgekeerde DNS)

example.org. IN SOA ns1.example.org. admin.example.org. (
                        2006051501      ; Serienummer
                        10800           ; Ververs na 3 uur
                        3600            ; Opnieuw proberen na 1 uur
                        604800          ; Verlopen na 1 week
                        300             ; Negatieve antwoord-TTL
example.org.

de domeinnaam, ook de oorsprong voor dit zonebestand.

ns1.example.org.

de primaire/bevoegde naamserver voor deze zone.

admin.example.org.

de persoon die verantwoordelijk is voor deze zone, emailadres met "@" vervangen. admin@example.org wordt admin.example.org.

2006051501

het serienummer van het bestand. Dit moet iedere keer als het zonebestand wordt aangepast opgehoogd worden. Tegenwoordig geven veel beheerders de voorkeur aan de opmaak yyyymmddrr voor het serienummer. 2006051501 betekent dan dat het voor het laatst is aangepast op 15-05-2006, de laatste 01 betekent dat het zonebestand die dag voor het eerst is aangepast. Het serienummer is belangrijk omdat het slaafnaamservers aangeeft dat een zone is bijgewerkt.

       IN NS           ns1.example.org.

Hierboven staat een NS-regel. Voor iedere naamserver die bevoegde antwoorden moet geven voor de zone hoort er zo’n regel te zijn.

localhost       IN      A       127.0.0.1
ns1             IN      A       192.168.1.2
ns2             IN      A       192.168.1.3
mx              IN      A       192.168.1.4
mail            IN      A       192.168.1.5

Een A-record geeft een machinenaam aan. Hierboven is te zien dat ns1.example.org zou resolven naar 192.168.1.2.

       IN      A       192.168.1.1

Deze regel kent IP-adres 192.168.1.1 toe aan de huidige oorsprong, in dit geval example.org.

www             IN CNAME        @

Een canoniek naamrecord wordt meestal gebruikt voor het geven van aliassen aan een machine. In het voorbeeld is www een alias naar de "master" machine waarvan de naam gelijk is aan de domeinnaam example.org (192.168.1.1). CNAME’s kunnen nooit samen met een ander soort record voor dezelfde hostnaam gebruikt worden.

               IN MX   10      mail.example.org.

MX records geven aan welke mailservers verantwoordelijk zijn voor het afhandelen van inkomende mail voor de zone. mail.example.org is de hostnaam van een mailserver en 10 is de prioriteit voor die mailserver.

Het is mogelijk meerdere mailservers in te stellen met prioriteiten 10, 20, enzovoorts. Een mailserver die probeert mail af te leveren voor example.org probeert dat eerst bij de MX met de hoogste prioriteit (het record met het laagste prioriteitsnummer), daarna de tweede hoogste, enzovoort, totdat de mail afgeleverd kan worden.

Voor in-addr.arpa zonebestanden (omgekeerd DNS) wordt dezelfde opmaak gebruikt, maar dan met PTR-regels in plaats van A of CNAME.

$TTL 3600

1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
                        2006051501      ; Serienummer
                        10800           ; Ververs
                        3600            ; Opnieuw proberen
                        604800          ; Verlopen
                        300 )           ; Negatieve antwoord-TTL

        IN      NS      ns1.example.org.
        IN      NS      ns2.example.org.

1       IN      PTR     example.org.
2       IN      PTR     ns1.example.org.
3       IN      PTR     ns2.example.org.
4       IN      PTR     mx.example.org.
5       IN      PTR     mail.example.org.

Dit bestand geeft de juiste IP-adressen voor hostnamen in het voorbeelddomein hierboven.

Het is het vernoemen waard dat alle namen aan de rechterkant van een PTR-record volledig gekwalificeerd dienen te zijn (i.e., met een "." eindigen).

29.6.7. Caching naamserver

Een caching naamserver is een naamserver wiens primaire rol het oplossen van recursieve verzoeken is. Het dient simpelweg zelf verzoeken in en onthoudt de antwoorden voor later gebruik.

29.6.8. DNSSEC

Domain Name Security System Extensions, ofwel DNSSEC, is een verzameling van specificaties om resolvende naamservers te beschermen tegen valse DNS-gegevens, zoals vervalste DNS-records. Door digitale handtekeningen te gebruiken kan een resolver de integriteit van een record controleren. Merk op dat DNSSEC alleen integriteit biedt via het digitaal ondertekenen van het Resource Record (RRs). Het biedt noch betrouwbaarheid noch bescherming tegen onjuiste aannames van eindgebruikers. Dit betekent dat het mensen niet kan beschermen tegen het bezoeken van example.net in plaats van example.com. Het enige wat DNSSEC doet is authenticeren dat de gegevens niet tijdens het transport zijn gecompromitteerd. De beveiliging van DNSSEC is een belangrijke stap in het beveiligen van het internet in het algemeen. De relevante RFCs zijn een goed beginpunt voor meer gedetailleerde gegevens over hoe DNSSEC werkt. Raadpleeg de lijst in Verder lezen.

De volgende secties laten zien hoe DNSSEC voor een autoratieve DNS-server en een recursieve (of caching) DNS-server die BIND 9 draait kan worden bewerkstelligd. Hoewel alle versies van BIND 9 DNSSEC ondersteunen, is tenminste versie 9.6.2 nodig om gebruik te kunnen maken van de ondertekende rootzones tijdens het valideren van DNS-verzoeken. Dit komt doordat eerdere versies de benodigde algoritmes om validatie met de sleutel voor de rootzone te uit te voeren niet hebben. Het wordt sterk aangeraden om de nieuwste versie van BIND 9.7 te gebruiken om gebruik te kunnen maken van automatische sleutel-updates voor de rootsleutel en van andere mogelijkheden om zones ondertekend en sleutel up-to-date te houden. Wanneer configuraties tussen 9.6.2 en 9.7 en later verschillen, zullen deze worden toegelicht.

29.6.8.1. Configuratie van een recursieve DNS-server

Het aanzetten van DNSSEC-validatie van verzoeken die door een recursieve DNS-server worden uitgevoerd heeft enkele aanpassingen aan named.conf nodig. Voordat deze wijzigingen worden gemaakt dient de rootzone-sleutel, of vertrouwensanker, te worden opgehaald. Momenteel is de rootzone-sleutel niet beschikbaar in een bestandsformaat dat BIND begrijpt, dus moet het handmatig in het juiste formaat omgezet worden. De sleutel zelf kan verkregen worden door de rootzone ervoor met dig te ondervragen. Door

% dig +multi +noall +answer DNSKEY . > root.dnskey

te draaien, wordt de sleutel in root.dnskey opgeslagen. De inhoud dient er ongeveer als volgt uit te zien:

. 93910 IN DNSKEY 257 3 8 (
	AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
	bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
	/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
	JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
	oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
	LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
	Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
	LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
	) ; key id = 19036
. 93910 IN DNSKEY 256 3 8 (
	AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf
	UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE
	g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V
	EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt
	) ; key id = 34525

Schrik niet als de verkregen sleutels anders zijn dan in dit voorbeeld. Ze kunnen zijn veranderd nadat deze instructies voor het laatst waren bijgewerkt. De uitvoer bevat in feite twee sleutels. De eerste sleutel, met de waarde 257 na het DNSKEY-recordtype, is degene die nodig is. Deze waarde geeft aan dat dit een Secure Entry Point ( SEP) is, beter bekend als een Key Signing Key (KSK). De tweede sleutel, met de waarde 256, is een deelsleutel, beter bekend als een Zone Signing Key (ZSK). Meer over de verschillende soorten sleutels komt aan bod in Configuratie van een autoratieve DNS-server.

Nu moet de sleutel gecontroleerd en geformatteerd worden zodat BIND deze kan gebruiken. Maak om de sleutel te controleren een DS - RR-paar aan. Maak een bestand aan dat deze RRs bevat aan met

% dnssec-dsfromkey -f root-dnskey . > root.ds

Deze records gebruiken respectievelijk SHA-1 en SHA-256, en dienen er als het volgende voorbeeld uit te zien, waarbij het langere record SHA-256 gebruikt.

. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

Het SHA-256 RR kan nu worden vergeleken met de digest in https://data.iana.org/root-anchors/root-anchors.xml. Om er absoluut zeker van te zijn dat er niet geknoeid is met de sleutel kunnen de gegevens in het XML-bestand worden gecontroleerd met de PGP-handtekening in https//data.iana.org/root-anchors/root-anchors.asc.

Vervolgens dient de sleutel juist geformateerd te worden. Dit verschilt een beetje tussen versie 9.6.2 en versie 9.7 en later van BIND. In versie 9.7 is ondersteuning toegevoegd om automatisch veranderingen aan de sleutel te volgen en deze bij te werken indien nodig. Dit wordt gedaan met managed-keys zoals in het volgende voorbeeld te zien is. Als de oudere versie gebruikt wordt, wordt de sleutel toegevoegd met een commando trusted-keys en dient deze handmatig bijgewerkt te worden. Voor BIND 9.6.2 ziet het formaat er uit als:

trusted-keys {
	"." 257 3 8
	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
	QxA+Uk1ihz0=";
};

Voor versie 9.7 ziet het formaat er echter zo uit:

managed-keys {
	"." initial-key 257 3 8
	"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
	FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
	bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
	X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
	W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
	Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
	QxA+Uk1ihz0=";
};

De rootsleutel kan nu aan named.conf worden toegevoegd, ofwel direct of door een bestand dat de sleutel bevat te includen. Stel na deze stappen BIND in zodat het DNSSEC-validatie uitvoert op verzoeken door named.conf te bewerken en het volgende aan de directief options toe te voegen:

dnssec-enable yes;
dnssec-validation yes;

Om te controleren dat het ook echt werkt, kan dig gebruikt worden om een verzoek op een ondertekende zone uit te voeren met de zojuist geconfigureerde resolver. Een succesvol antwoord zal de vlag AD bevatten om aan te geven dat de gegevens zijn geautenticeerd. Een verzoek als

% dig @resolver +dnssec se ds

zou het DSRR paar voor de .se-zone moeten teruggeven. In de sectie flags: moet de vlag AD te zien zijn, als in:

...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
...

De resolver is nu in staat om DNS-verzoeken te autenticeren.

29.6.8.2. Configuratie van een autoratieve DNS-server

Om een autoratieve naamserver een met DNSSEC ondertekende zone te laten serveren is wat meer werk nodig. Een zone wordt ondertekend met cryptografische sleutels die aangemaakt moeten worden. Het is mogelijk om hier slechts één sleutel voor te gebruiken. De methode die de voorkeur verdient is echter om een sterke, goed beschermde Key Signing Key (KSK) die niet vaak wordt geroteerd en een Zone Signing Key (ZSK) die vaker wordt geroteerd te hebben. Informatie over aanbevolen procedures staat in RFC 4641: DNSSEC Operational Practices. Procedures betreffende de rootzone staan in DNSSEC Practice Statement for the Root Zone KSK operator en DNSSEC Practice Statement for the Root Zone ZSK operator. De KSK wordt gebruikt om een autoriteitsketen voor de te valideren gegevens op te bouwen en wordt daarom ook een Secure Entry Point (SEP)-sleutel genoemd. Een bericht-digest van deze sleutel, dat Delegation Signer (DS)-record genoemd wordt, moet gepubliceerd zijn in de ouderzone om een vertrouwensketen op te bouwen. Hoe dit bereikt wordt hangt af van de eigenaar van de ouderzone. De ZSK wordt gebruikt om de zone te ondertekenen, en hoeft alleen daar gepubliceerd te worden.

Om DNSSEC aan te zetten voor de zone example.com zoals beschreven in de voorgaande voorbeelden, dient als eerste dnssec-keygen gebruikt te worden om het sleutelpaar met de KSK en ZSK te genereren. Dit sleutelpaar kan verschillende cryptografische algoritmes gebruiken. Het wordt aanbevolen om RSA/SHA-256 voor de sleutels te gebruiken, een sleutellengte van 2048 bits zou voldoende moeten zijn. Om de KSK voor example.com te genereren:

% dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com

en om de ZSK te genereren:

% dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com

dnssec-keygen maakt twee bestanden, de publieke en private sleutels in bestanden met namen als Kexample.com.+005+nnnnn.key (publiek) en Kexample.com.+005+nnnnn.private (privaat). Het gedeelte nnnnn van de bestandsnaam is een sleutel-ID van vijf cijfers. Houd bij welke sleutel-ID bij welke sleutel hoort. Dit is in het bijzonder van belang wanneer er meerdere sleutels per zone zijn. Het is ook mogelijk om de sleutels te hernoemen. Voor elk KSK-bestand:

% mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnn.KSK.key
% mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private

Voor ZSK-bestanden dient KSK waar nodig door ZSK vervangen te worden. De bestanden kunnen nu worden opgenomen in het zonebestand, door de opdracht $include te gebruiken. Het zou er ongeveer als volgt uit moeten zien:

$include Kexample.com.+005+nnnnn.KSK.key ; KSK
$include Kexample.com.+005+nnnnn.ZSK.key ; ZSK

Onderteken tenslotte de zone en vertel BIND om het ondertekende zonebestand te gebruiken. Voor het ondertekenen van een zone wordt dnssec-signzone gebruikt. Het commando om de zone example.com, dat zich in example.com.db bevindt, zou er ongeveer zo uit moeten zien:

% dnssec-signzone -o example.com -k Kexample.com.+005+nnnnn.KSK example.com.db Kexample.com.+005+nnnnn.ZSK.key

De sleutel die aan het argument -k wordt meegegeven is de KSK en het andere sleutelbestand is de ZSK dat bij het ondertekenen gebruikt moet worden. Het is mogelijk om meer dan één KSK en ZSK op te geven, wat tot gevolg heeft dat de zone met alle meegegeven sleutels wordt ondertekend. Dit kan nodig zijn om zonegegevens aan te leveren die met meerdere algoritmes zijn ondertekend. De uitvoer van dnssec-signzone is een zonebestand met daarin alle RRs ondertekend. Deze uitvoer komt in een bestand met de extensie .signed terecht, zoals example.com.db.signed. De DS-records worden ook naar een apart bestand dsset-example.com geschreven. Om deze ondertekende zone te gebruiken hoeft alleen de zone-directief in named.conf veranderd te worden om example.com.db.signed. Standaard zijn de ondertekeningen slechts 30 dagen geldig, wat betekent dat de zone over ongeveer 15 dagen hertekend moet worden om er zeker van te zijn dat resolvers geen records met oude ondertekeningen cachen. Het is mogelijk om hiervoor een script en een crontaak te maken. Bekijk de relevante handleidingen voor details.

Zorg ervoor dat de private sleutels veilig blijven, zoals met alle cryptografische sleutels. Bij het veranderen van een sleutel kan het beste de nieuwe sleutel in de zone opgenomen worden, en nog met de oude sleutel te ondertekenen, en om daarna over te stappen op de nieuwe sleutel. Nadat deze handelingen zijn voltooid kan de oude sleutel uit de zone worden verwijderd. Wanneer dit niet wordt gedaan kunnen de DNS-gegevens tijdelijk onbeschikbaar zijn totdat de nieuwe sleutel door de DNS-hiërarchie is gepropageerd. Meer informatie over sleutelwisselingen en andere praktijken rondom DNSSEC staan in RFC 4641: DNSSEC Operational practices.

29.6.8.3. Automatisering met BIND 9.7 of nieuwer

In versie 9.7 van BIND is een nieuwe mogelijkheid genaamd Smart Signing geïntroduceerd. Deze mogelijkheid heeft als doel om het sleutelbeheer en ondertekenproces eenvoudiger te maken door delen van deze taken te automatiseren. Door de sleutels in een sleutelreservoir te stoppen en de nieuwe optie auto-dnssec te gebruiken, is het mogelijk om een dynamische zone aan te maken welke opnieuw getekend wordt indien dat nodig is. Gebruik om deze zone bij te werken nsupdate met de nieuwe -l. rndc kan nu ook zones ondertekenen met sleutels uit het sleutelreservoir door de optie sign te gebruiken. Voeg, om BIND dit automatische ondertekenen en bijwerken van zones te laten gebruiken voor example.com, het volgende aan named.conf toe:

zone example.com {
	type master;
	key-directory "/etc/named/keys";
	update-policy local;
	auto-dnssec maintain;
	file "/etc/named/dynamic/example.com.zone";
};

Nadat deze veranderingen gemaakt zijn, dienen de sleutels voor de zone aangemaakt te worden zoals uitgelegd in Configuratie van een autoratieve DNS-server, deze sleutels in het sleutelreservoir gestopt te worden dat als argument aan de key-directory in het zoneconfiguratie is meegegeven, waarna de zone automatisch zal worden ondertekend. Zones die op deze manier zijn geconfigureerd dienen met nsupdate te worden gedaan, dat voor het opnieuw ondertekenen van de zone met de nieuw toegevoegde gegevens zal zorgen. Zie voor meer details Verder lezen en de BIND-documentatie.

29.6.9. Beveiliging

Hoewel BIND de meest gebruikte implementatie van DNS is, is er altijd nog het beveiligingsvraagstuk. Soms worden er mogelijke en te misbruiken beveiligingsgaten gevonden.

Hoewel FreeBSD named automatisch in een chroot(8)-omgeving plaatst; zijn er verschillende andere beveiligingsmechanismen actief die zouden kunnen helpen om mogelijke aanvallen op de DNS-dienst af te wenden.

Het is altijd verstandig om de CERT beveiligingswaarschuwingen te lezen en een abonnement te nemen op de FreeBSD beveiligingswaarschuwingen mailinglijst om bij te blijven met de beveiligingsproblemen wat betreft Internet en FreeBSD.

Als er problemen ontstaan, kan het bijwerken van broncode en het opnieuw bouwen van named hulp bieden.

29.7. Apache HTTP server

29.7.1. Overzicht

FreeBSD wordt gebruikt om een paar van de drukste websites ter wereld te draaien. De meeste webservers op Internet maken gebruik van de Apache HTTP Server. Apache softwarepakketten staan op de FreeBSD installatiemedia. Als Apache niet bij de oorspronkelijke installatie van FreeBSD is meegeïnstalleerd, dan kan dat vanuit de port www/apache22.

Als Apache succesvol is geïnstalleerd, moeten er instellingen gemaakt worden.

In dit onderdeel wordt versie 2.2.X van de Apache HTTP Server behandeld omdat die het meest gebruikt wordt op FreeBSD. Meer gedetailleerde informatie over Apache 2.X dat buiten het bereik van dit document valt is te vinden op http://httpd.apache.org/.

29.7.2. Instellen

Het belangrijkste bestand met instellingen voor de Apache HTTP Server op FreeBSD is /usr/local/etc/apache22/httpd.conf. Dit bestand is een typisch UNIX® tekstgebaseerd instellingenbestand waarin regels met commentaar beginnen met het karakter #. Het uitputtend beschrijven van alle mogelijke instellingen valt buiten het bereik van dit boek, dus worden alleen de meest gebruikte directieven beschreven.

ServerRoot "/usr/local"

Hierin wordt de standaard mappenhiërarchie voor de Apache installatie aangegeven. Binaire bestanden staan in de submappen bin en sbin van de serverroot en bestanden met instellingen staan in etc/apache.

ServerAdmin beheerder@beheer.adres

Het adres waaraan problemen met de server gemaild kunnen worden. Dit adres verschijnt op een aantal door de server gegenereerde pagina’s, zoals documenten met foutmeldingen.

ServerName www.example.com

Met ServerName kan een hostnaam ingesteld worden die wordt teruggezonden aan de cliënten als de naam van de server anders is dan diegene is ingesteld (gebruik bijvoorbeeld www in plaats van de echte hostnaam).

DocumentRoot "/usr/local/www/apache22/data"

DocumentRoot: de map waaruit de documenten worden geserveerd. Standaard worden alle verzoeken uit deze map gehaald, maar er kunnen symbolische links en aliassen gebruikt worden om naar andere locaties te wijzen.

Het is altijd een goed idee om reservekopieën te maken van het instellingenbestand voor Apache vóór het maken van wijzigingen. Als de juiste instellingen gemaakt zijn, kan Apache gestart worden.

29.7.3. Apache draaien

De port www/apache2 installeert een rc(8)-script dat helpt met het starten, stoppen en herstarten van Apache en is te vinden in /usr/local/etc/rc.d/.

Om Apache met het systeem mee te starten kan de volgende regel aan /etc/rc.conf worden toegevoegd:

apache22_enable="YES"

Als het nodig is Apache met afwijkende opties op te starten, kan de volgende regel aan /etc/rc.conf worden toegevoegd:

apache22_flags=""

De configuratie van Apache kan worden getest op fouten voordat het daemon httpd voor de eerste keer wordt gestart, of na het maken van wijzigingen aan de instellingen terwijl httpd draait. Dit kan direct door het rc(8)-script worden gedaan, of door het gereedschap service(8) door één van de volgende commando’s op te geven:

# service apache22 configtest

Het is belangrijk om op te merken dat configtest geen rc(8)-standaard is, verwacht niet dat het met alle rc(8)-opstartscripts werkt.

Als Apache geen instellingsfouten meldt, kan Apache httpd gestart worden met service(8):

# service apache22 start

De dienst httpd kan getest worden door http://localhost in een webbrowser te typen, waarbij localhost door de volledig gekwalificeerde domeinnaam wordt vervangen van de machine die httpd draait, als het niet de lokale machine is. De standaard webpagina die afgebeeld wordt is /usr/local/www/apache22/data/index.html.

29.7.4. Virtuele hosting

Apache ondersteunt twee verschillende manieren van Virtuele Hosting. De eerste methode is Naamgebaseerde Virtuele Hosting. Naamgebaseerde Virtuele Hosting gebruikt de HTTP/1.1 headers van de cliënten om de hostnaam uit te zoeken. Hierdoor kunnen meerdere domeinen hetzelfde IP-adres delen.

Om Apache gebruik te laten maken van Naamgebaseerde Virtuele Hosting kan een regel als de volgende in httpd.conf worden opgenomen:

NameVirtualHost *

Als een webserver www.domein.tld heet en er moet een virtueel domein voor www.anderdomein.tld gaan draaien, dan kunnen de volgende regels aan httpd.conf worden toegevoegd:

<VirtualHost *>
    ServerName www.domein.tld
    DocumentRoot /www/domein.tld
</VirtualHost>

<VirtualHost *>
    ServerName www.anderdomein.tld
    DocumentRoot /www/anderdomein.tld
</VirtualHost>

De adressen en de paden uit dit voorbeeld kunnen in echte implementaties uiteraard gewijzigd worden.

Meer informatie over het opzetten van virtuele hosts staat in de officiële documentatie voor Apache op http://httpd.apache.org/docs/vhosts/

29.7.5. Apache modules

Er zijn veel verschillende Apache modules die functionaliteit toevoegen aan de basisdienst. De FreeBSD Portscollectie biedt op een eenvoudige manier de mogelijkheid om Apache samen met de meeste populaire add-on modules te installeren.

29.7.5.1. mod_ssl

De module mod_ssl gebruikt de bibliotheek OpenSSL om sterke cryptografie te leveren via de protocollen Secure Sockets Layer (SSL v2/v3) en Transport Layer Security (TLS v1). Deze module levert alles wat nodig is om een getekend certificaat aan te vragen bij een vertrouwde certificaatautoriteit om een veilige webserver onder FreeBSD te kunnen draaien.

De module mod_ssl wordt standaard gebouwd, maar kan worden aangezet door tijdens het compileren -DWITH_SSL op te geven.

29.7.5.2. Taalbindingen

Er zijn Apache-modules beschikbare voor de meeste grote scriptingtalen. Deze modules maken het typisch mogelijk om Apache-modules geheel in een scriptingtaal te schrijven. Ze worden ook vaak gebruikt als een persistente interpreter die in de server zit en die de rompslomp van het starten van een externe interpreter en de opstartvertraging voor dynamische websites vermijdt, zoals beschreven in de volgende sectie.

29.7.6. Dynamische websites

In het afgelopen decennium hebben steeds meer bedrijven zich op Internet gericht om hun omzet te verhogen en hun zichtbaarheid te vergroten. Hiermee is ook de behoefte aan interactieve webinhoud toegenomen. Hoewel sommige bedrijven zoals Microsoft® oplossingen hebben geïntroduceerd voor hun eigen (propriëtaire) producten, heeft ook de open source gemeenschap een antwoord op de vraag gegeven. Moderne opties voor dynamische webinhoud zijn onder andere Django, Ruby on Rails, mod_perl2, en mod_php.

29.7.6.1. Django

Django is een BSD-gelicenseerd raamwerk ontworpen om ontwikkelaars in staat te stellen om snel hoog presterende, elegante webapplicaties te schrijven. Het biedt een vertaling van objecten naar relaties zodat datatypes ontwikkeld kunnen worden als Python-objecten, en er een rijke dynamische databasetoegang voor die objecten kan worden geboden zonder dat de ontwikkelaar ooit SQL hoeft te schrijven. Het biedt ook een uitbreidbaar sjabloonsysteem zodat de applicatielogica is gescheiden van de HTML-presentatie.

Django is afhankelijk van mod_python, Apache, en een SQL-database-engine naar keuze. De FreeBSD-port zal al deze vereisten met de juiste vlaggen voor u installeren.

Voorbeeld 3. Django installeren met Apache2, mod_python3 en PostgreSQL
# cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL

Als Django en deze vereisten eenmaal zijn geïnstalleerd, dient u een Django-projectmap te maken en vervolgens Apache te configureren om de ingebakken Python-interpreter te gebruiken om uw applicatie voor specifieke URL’s op uw site aan te roepen.

Voorbeeld 4. Apache-configuratie voor Django/mod_python

U moet een regel aan het Apache-bestand httpd.conf toevoegen om Apache in te stellen om verzoeken voor bepaalde URL’s aan uw webapplicatie door te geven:

<Location "/">
    SetHandler python-program
    PythonPath "['/map/naar/uw/django-pakketten/'] + sys.path"
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mijnsite.settings
    PythonAutoReload On
    PythonDebug On
</Location>

29.7.6.2. Ruby on Rails

Ruby on Rails is een ader opensource webraamwerk dat een volledige ontwikkelstack biedt en geoptimaliseerd is om webontwikkelaars productiever te maken en snel krachtige applicaties te laten ontwikkelen. Het kan eenvoudig vanuit het portssysteem geïnstalleerd worden.

# cd /usr/ports/www/rubygem-rails; make all install clean

29.7.6.3. mod_perl2

Het Apache/Perl integratieproject brengt de volledige kracht van de programmeertaal Perl en de Apache HTTP Server samen. Met de module mod_perl2 is het mogelijk om Apache-modules volledig in Perl te schrijven. Daarnaast voorkomt een ingebouwde persistente interpreter in de server de rompslomp van het starten van een externe interpreter en de nadelen van de opstarttijd van Perl.

mod_perl2 is beschikbaar in de port www/mod_perl2.

29.7.6.4. mod_php

PHP, ook bekend als "PHP: Hypertext Preprocessor", is een algemene scripttaal die bijzonder geschikt is voor webontwikkeling. Het is mogelijk de taal in te bedden in HTML en de syntaxis is afgeleid van C, Java™ en Perl met de bedoeling webontwikkelaars in staat te stellen om snel dynamisch samengestelde pagina’s te schrijven.

Om ondersteuning voor PHP5 toe te voegen aan de Apache webserver kan eerst de port lang/php5 geïnstalleerd worden.

Als de port lang/php5 voor het eerst geïnstalleerd wordt, worden automatisch de beschikbare OPTIONS weergegeven. Als er geen menu wordt weergegeven, omdat de port lang/php5 reeds in het verleden is geïnstalleerd, is het altijd mogelijk om het optiedialoog weer te laten verschijnen door

# make config

uit te voeren in de map van de port.

Controleer in het optiedialoog dat de optie APACHE mod_php5 als een laadbare module voor de webserver Apache bouwt.

Een heleboel sites draaien nog steeds PHP4 om verschillende redenen (compatibiliteitszaken of reeds in gebruik genomen webapplicaties). Als mod_php4 nodig is in plaats van mod_php5, gebruik dan de port lang/php4. De port lang/php4 ondersteunt een groot deel van de configuratie- en bouwopties van de port lang/php5.

Hiermee worden de modules die nodig zijn voor de ondersteuning van dynamische PHP-applicaties geïnstalleerd en ingesteld. Controleer dat de volgende secties aan /usr/local/etc/apache22/httpd.conf zijn toegevoegd:

LoadModule php5_module        libexec/apache/libphp5.so
AddModule mod_php5.c
    IfModule mod_php5.c
        DirectoryIndex index.php index.html
    /IfModule
    IfModule mod_php5.c
        AddType application/x-httpd-php .php
        AddType application/x-httpd-php-source .phps
    /IfModule

Na voltooiing is een eenvoudige aanroep van het commando apachectl voor een nette herstart nodig om de module PHP te laden:

# apachectl graceful

Voor toekomstig bijwerken van PHP zal het commando make config niet nodig zijn; de geselecteerde OPTIONS worden automatisch bewaard door het FreeBSD Ports raamwerk.

De ondersteuning voor PHP in FreeBSD is extreem modulair waardoor de basisinstallatie zeer beperkt is. Het is heel gemakkelijk om ondersteuning toe te voegen door de port lang/php5-extensions te gebruiken. Deze port biedt een menugestuurde interface voor de installatie van PHP-uitbreidingen. Als alternatief kunnen individuele uitbreidingen worden geïnstalleerd door de juiste port te gebruiken.

Om bijvoorbeeld ondersteuning voor de MySQL databaseserver aan PHP5 toe te voegen kan gewoonweg de port databases/php5-mysql geïnstalleerd worden:

Na de installatie van een uitbreiding moet de Apache-server herladen worden om de nieuwe veranderingen in de configuratie op te pikken:

# apachectl graceful

29.8. File Transfer Protocol (FTP)

29.8.1. Overzicht

Het File Transfer Protocol (FTP) biedt gebruikers een eenvoudige manier om bestanden van en naar een FTP server te verplaatsen. FreeBSD bevat FTP server software, ftpd, in het basissysteem. Hierdoor is het opzetten en beheren van een FTP server op FreeBSD erg overzichtelijk.

29.8.2. Instellen

De belangrijkste stap bij het instellen is de beslissing welke accounts toegang krijgen tot de FTP server. Een normaal FreeBSD systeem heeft een aantal systeemaccounts die gebruikt worden voor daemons, maar onbekende gebruikers mag niet toegestaan worden van die accounts gebruikt te maken. In /etc/ftpusers staat een lijst met gebruikers die geen FTP toegang hebben. Standaard staan daar de voorgenoemde accounts in, maar het is ook mogelijk om daar gebruikers toe te voegen die geen FTP toegang mogen hebben.

Het kan ook wenselijk zijn de FTP toegang voor sommige gebruikers te beperken, maar niet onmogelijk te maken. Dit kan met /etc/ftpchroot. In dat bestand staan gebruikers en groepen waarop FTP toegangsbeperkingen van toepassing zijn. In ftpchroot(5) staan alle details die hier niet beschreven zijn.

Om anonieme FTP toegang voor een server in te schakelen, dient er een gebruiker ftp op een FreeBSD systeem aangemaakt te worden. Dan kunnen gebruikers op de server aanmelden met de gebruikersnaam ftp of anonymous en met ieder wachtwoord (de geldende conventie schrijft voor dat dit een emailadres van de gebruiker is). De FTP server roep bij een anonieme aanmelding chroot(2) aan, zodat er alleen toegang is tot de thuismap van de gebruiker ftp.

Er zijn twee tekstbestanden waarin welkomstberichten voor de FTP-cliënten gezet kunnen worden. De inhoud van /etc/ftpwelcome wordt getoond voordat gebruikers een aanmeldprompt zien. Na een succesvolle aanmelding wordt de inhoud van /etc/ftpmotd getoond. Het genoemde pad is relatief ten opzichte van de aanmeldomgeving, dus voor anonieme gebruikers wordt ~ftp/etc/ftpmotd getoond.

Als een FTP server eenmaal correct is ingesteld, moet die ingeschakeld worden in /etc/inetd.conf. Daar moet het commentaarkarakter # voor de bestaande ftpd regel verwijderd worden:

ftp	stream	tcp	nowait	root	/usr/libexec/ftpd	ftpd -l

Zoals is uitgelegd in Het instellingenbestand van inetd herladen, moet de configuratie van inetd worden herladen nadat dit instellingenbestand is gewijzigd. Details over het aanzetten van inetd op uw systeem staan in Instellingen.

Als alternatief kan ftpd ook gestart worden als een op zichzelf staande dienst. In dat geval volstaat het om de juiste variabele in te stellen in /etc/rc.conf:

ftpd_enable="YES"

Na het instellen van de bovenstaande variabele zal de op zichzelf staande server gestart worden nadat de computer opnieuw is opgestart, of het kan handmatig worden gestart door het volgende commando als root uit te voeren:

# service ftpd start

Nu kan aangemeld worden op de FTP-server met:

% ftp localhost

29.8.3. Beheren

De ftpd daemon gebruikt syslog(3) om berichten te loggen. Standaard plaatst de systeemlogdaemon berichten over FTP in /var/log/xferlog. De lokatie van het FTP logboek kan gewijzigd worden door de volgende regels in /etc/syslog.conf te wijzigen:

ftp.info      /var/log/xferlog

Het is verstandig na te denken over de gevaren die op de loer liggen bij het draaien van een anonieme FTP server. Dat geldt in het bijzonder voor het laten uploaden ven bestanden. Het is dan goed mogelijk dat een FTP site een forum wordt om commerciële software zonder licenties uit te wisselen of erger. Als anonieme uploads toch nodig zijn, dan horen de rechten op die bestanden zo te staan dat ze niet door andere anonieme gebruikers gelezen kunnen worden tot er door een beheerder naar gekeken is.

29.9. Bestands- en printdiensten voor Microsoft® Windows® cliënten (Samba)

29.9.1. Overzicht

Samba is een populair open source softwarepakket dat bestands- en printdiensten voor Microsoft® Windows® cliënten biedt. Die cliënten kunnen dan ruimte op een FreeBSD bestandssysteem gebruiken alsof het een lokale schijf is en FreeBSD printers gebruiken alsof het lokale printers zijn.

Samba softwarepakketten horen op de FreeBSD installatiemedia te staan. Als Samba bij de basisinstallatie niet mee is geïnstalleerd, dan kan dat alsnog via de net/samba34 port of met het pakket.

29.9.2. Instellen

Een standaardbestand met instellingen voor Samba wordt geïnstalleerd als /usr/local/shared/examples/samba34/smb.conf.default. Dit bestand dient gekopieerd te worden naar /usr/local/etc/smb.conf en voordat Samba gebruikt kan worden, moeten er aanpassingen aan worden gemaakt.

smb.conf bevat de instellingen voor Samba, zoals die voor de printers en de "gedeelde bestandssystemen" die gedeeld worden met Windows® cliënten. Het pakket Samba bevat een webgebaseerde beheermodule die swat heet, waarmee smb.conf op een eenvoudige manier ingesteld kan worden.

29.9.2.1. De Samba webbeheermodule gebruiken (SWAT)

De Samba Webbeheermodule (SWAT) draait als een daemon vanuit inetd. Daarom dient inetd aangezet te worden zoals beschreven in De inetd"Super-Server" en dient voor de volgende regel uit /etc/inetd.conf het commentaarkarakter verwijderd te worden voordat swat gebruikt kan worden om Samba in te stellen:

swat   stream  tcp     nowait/400      root    /usr/local/sbin/swat    swat

Zoals is uitgelegd in Het instellingenbestand van inetd herladen, moet de configuratie van inetd worden herladen nadat dit instellingenbestand is gewijzigd.

Als swat is ingeschakeld in inetd.conf, kan de module gebruikt worden door met een browser een verbinding te maken met http://localhost:901. Er dient aangemeld te worden met het root account van het systeem.

Na succesvol aanmelden op de hoofdpagina voor de Samba instellingen, is het mogelijk de systeemdocumentatie te bekijken of te starten door op het tabblad Globals te klikken. Het onderdeel Globals correspondeert met de sectie [global] in /usr/local/etc/smb.conf.

29.9.2.2. Systeembrede instellingen

Of Samba nu wordt ingesteld door /usr/local/etc/smb.conf direct te bewerken of met swat, de eerste instellingen die gemaakt moeten worden zijn de volgende:

workgroup

NT Domeinnaam of Werkgroepnaam voor de computers die verbinding gaan maken met de server.

netbiosnaam

Hiermee wordt de NetBIOS naam waaronder de Samba server bekend zal zijn ingesteld. Standaard is de naam het eerste gedeelte van de DNS-naam van een host.

server string

Hiermee wordt de string ingesteld die te zien is als het commando net view en een aantal andere commando’s die gebruik maken van de beschrijvende tekst voor de server gebruikt worden.

29.9.2.3. Beveiligingsinstellingen

Twee van de belangrijkste instellingen in /usr/local/etc/smb.conf zijn het gekozen beveiligingsmodel en het wachtwoord voor cliëntgebruikers. Deze worden met de volgende instellingen gemaakt:

security

De twee meest gebruikte mogelijkheden hier zijn security = share en security = user. Als de cliënten gebruikersnamen hebben die overeenkomen met hun gebruikersnaam op de FreeBSD machine, dan is het verstandig om te kiezen voor beveiliging op gebruikersniveau. Dit is het standaard beveiligingsbeleid en kent als voorwaarde dat gebruikers zich eerst moeten aanmelden voordat ze toegang krijgen tot gedeelde bronnen.

Bij beveiliging op shareniveau hoeft een cliënt niet met een geldige gebruikersnaam en wachtwoord aan te melden op de server voor het mogelijk is om een verbinding te proberen te krijgen met een gedeelde bron. Dit was het standaardbeveiligingsmodel voor oudere versies van Samba.

passdb backend

Samba kent aan de achterkant verschillende authenticatiemodellen. Cliënten kunnen authenticeren met LDAP, NIS+, een SQL-database of een aangepast wachtwoordbestand. De standaard authenticatiemethode is smbpasswd. Meer wordt hier niet behandeld.

Als aangenomen wordt dat de standaard achterkant smbpasswd wordt gebruikt, dan moet /usr/local/etc/samba/smbpasswd gemaakt worden om Samba in staat te stellen cliënten te authenticeren. Als het gewenst is om uw UNIX® gebruikersaccounts toegang te geven vanaf Windows® cliënten, gebruik dan het volgende commando:

# smbpasswd -a gebruikersnaam

De aanbevolen backend is nu tdbsam, en het volgende command moet gebruikt worden om gebruikersaccounts toe te voegen:

# pdbedit -a -u gebruikersnaam

In de Official Samba HOWTO staat meer informatie over instelopties. Met de hier gegeven basisuitleg moet het mogelijk zijn Samba draaiende te krijgen.

29.9.3. Samba starten

De port net/samba34 voegt een nieuw opstartscript toe, dat gebruikt kan worden om Samba te beheren. Om dit script te activeren, zodat het bijvoorbeeld gebruikt kan worden om Samba te starten, stoppen, of te herstarten, dient de volgende regel aan /etc/rc.conf toegevoegd te worden:

samba_enable="YES"

Of, voor fijnkorrelig beheer:

nmbd_enable="YES"
smbd_enable="YES"

Dit stelt Samba ook in om automatisch tijdens het opstarten te starten.

Vervolgens is het mogelijk om Samba op elk moment te starten door dit te typen:

# service samba start
Starting SAMBA: removing stale tdbs :
Starting nmbd.
Starting smbd.

Refereer aan Gebruik van rc met FreeBSD voor meer informatie over het gebruikt van rc-scripts.

Samba bestaat feitelijk uit drie afzonderlijke daemons. Het script samba start de daemons nmbd en smbd. Als de winbind naamresolutiediensten in smb.conf zijn ingeschakeld, dan start ook de daemon winbindd.

Samba kan op ieder moment gestopt worden met:

# service samba stop

Samba is een complexe softwaresuite met functionaliteit waarmee verregaande integratie met Microsoft® Windows® netwerken mogelijk wordt. Informatie die verder gaat dan de basisinstallatie staat op http://www.samba.org.

29.10. Tijd synchroniseren met NTP

29.10.1. Overzicht

Na verloop van tijd gaat de tijd van een computer meestal uit de pas lopen. Het Netwerk Tijd Protocol (NTP) kan ervoor zorgen dat de tijd accuraat blijft.

Veel diensten op Internet zijn afhankelijk, of hebben veel voordeel, van het betrouwbaar zijn van de tijd. Zo ontvangt een webserver bijvoorbeeld veel verzoeken om een bestand te sturen als dat gewijzigd is sinds een bepaald moment. In een LAN-omgeving is het van groot belang dat computers die bestanden delen van eenzelfde server gesynchroniseerde tijd hebben zodat de tijdstempels consistent blijven. Diensten zoals cron(8) zijn ook afhankelijk van een betrouwbare systeemtijd om commando’s op het ingestelde moment uit te voeren.

Bij FreeBSD zit de ntpd(8) NTP server die gebruikt kan worden om bij andere NTP servers de tijd op te vragen om de eigen klok gelijk te zetten of om de juiste tijd te verstrekken aan andere apparaten.

29.10.2. Passende NTP-servers kiezen

Om de tijd te synchroniseren moeten er één of meer NTP-servers beschikbaar zijn. Een lokale systeembeheerder of een ISP heeft wellicht een NTP-server voor dit doel opgezet. Het is verstandig om documentatie te raadplegen en te bekijken of dat het geval is. Er is een online lijst van publiek toegankelijke NTP-servers waarop een NTP-server gezocht kan worden die in geografische zin dichtbij een te synchroniseren computer ligt. Het is belangrijk te voldoen aan het beleid voor de betreffende server en toestemming te vragen als dat in de voorwaarden staat.

Het is verstandig meerdere, niet van elkaar afhankelijke, NTP-servers te kiezen voor het geval een van de servers niet langer betrouwbaar is of niet bereikbaar is. ntpd(8) gebruikt de antwoorden die van andere servers ontvangen worden op intelligente wijze: betrouwbare servers krijgen voorrang boven onbetrouwbare servers.

29.10.3. Machine instellen

29.10.3.1. Basisinstellingen

Als het alleen de bedoeling is de tijd te synchroniseren bij het opstarten van een machine, dan kan ntpdate(8) gebruikt worden. Dit kan van toepassing zijn op desktops die regelmatig herstart worden en niet echt regelmatig gesynchroniseerd hoeven te worden. Op sommige machines hoort echter ntpd(8) te draaien.

Het gebruik van ntpdate(8) bij het opstarten is ook een goed idee voor machines waarop ntpd(8) draait. De ntpd(8) wijzigt de tijd geleidelijk, terwijl ntpdate(8) gewoon de tijd instelt, hoe groot het verschil tussen de bestaande tijd van een machine en de correcte tijd ook is.

Om ntpdate(8) tijdens het opstarten in te schakelen kan ntpdate_enable="YES" aan /etc/rc.conf worden toegevoegd. Alle voor de synchronisatie te gebruiken servers moeten dan, samen met eventuele opties voor ntpdate(8), in ntpdate_flags aangegeven worden.

29.10.3.2. Algemene instellingen

NTP wordt ingesteld met het bestand /etc/ntp.conf in het formaat dat beschreven staat in ntp.conf(5). Hieronder volgt een eenvoudig voorbeeld:

server ntplocal.example.com prefer
server timeserver.example.org
server ntp2a.example.net

driftfile /var/db/ntp.drift

De optie server geeft aan welke servers er gebruikt moeten worden, met op elke regel een server. Als de server wordt ingesteld met het argument prefer, zoals bij ntplocal.example.com, dan krijgt die server de voorkeur boven de andere. Een antwoord van een voorkeursserver wordt genegeerd als dat significant afwijkt van de antwoorden van de andere servers. In andere gevallen wordt het gebruikt zonder rekening te houden met de andere antwoorden. Het argument prefer wordt meestal gebruikt voor NTP-servers waarvan bekend is dat ze erg betrouwbaar zijn, zoals die met speciale tijdbewakingshardware.

De optie driftfile geeft aan welk bestand gebruikt wordt om de offset van de klokfrequentie van het systeem op te slaan. ntpd(8) gebruikt die om automatisch te compenseren voor het natuurlijke afwijken van de tijd, zodat er zelfs bij gebrek aan externe bronnen een redelijke accurate tijdsinstelling mogelijk is.

De optie driftfile geeft aan welk bestand gebruikt wordt om informatie over eerdere antwoorden van NTP-servers die gebruikt worden op te slaan. Dit bestand bevat interne informatie voor NTP. Het hoort niet door andere processen gewijzigd te worden.

29.10.3.3. Toegang tot een server instellen

Een NTP-server is standaard toegankelijk voor alle hosts op een netwerk. De optie restrict in /etc/ntp.conf maakt het mogelijk om aan te geven welke machines de dienst mogen benaderen.

Voor het blokkeren van toegang voor alle andere machines kan de volgende regel aan /etc/ntp.conf toegevoegd worden:

restrict default ignore

Dit zal ook toegang van uw server naar alle servers die vermeld staan in uw lokale configuratie verhinderen. Als u uw NTP-server moet synchroniseren met een externe NTP-server, dient u deze specifieke server toe te staan. Lees de handleiding voor ntp.conf(5) voor meer informatie.

Om alleen machines op bijvoorbeeld het lokale netwerk toe te staan hun tijd te synchroniseren met een server, maar ze tegelijkertijd niet toe te staan om de server te draaien of de server als referentie voor synchronisatie te gebruiken, kan de volgende regel toegevoegd worden:

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

Hierboven is 192.168.1.0 een IP-adres op een LAN en 255.255.255.0 is het bijbehorende netwerkmasker.

/etc/ntp.conf mag meerdere regels met restrict bevatten. Meer details staan in het onderdeel Access Control Support van ntp.conf(5).

29.10.4. De NTP-server draaien

De NTP-server kan bij het opstarten gestart worden door de regel ntpd_enable="YES" aan /etc/rc.conf toe te voegen. Om extra opties aan ntpd(8) mee te geven kan de parameter ntpd_flags in /etc/rc.conf gebruikt worden.

Om de server zonder een herstart van de machine te starten kan ntpd uitgevoerd worden, met toevoeging van de parameters uit ntpd_flags in /etc/rc.conf. Bijvoorbeeld:

# ntpd -p /var/run/ntpd.pid

29.10.5. ntpd gebruiken met een tijdelijke Internetverbinding

ntpd(8) heeft geen permanente verbinding met een netwerk nodig om goed te werken. Maar als er gebruik gemaakt wordt van een inbelverbinding, is het wellicht verstandig om ervoor te zorgen dat uitgaande NTP-verzoeken geen uitgaande verbinding kunnen starten. Als er gebruik gemaakt wordt van gebruikers-PPP, kunnen er filter commando’s ingesteld worden in /etc/ppp/ppp.conf. Bijvoorbeeld:

set filter dial 0 deny udp src eq 123
# NTP-verkeer zorgt niet voor uitbellen
set filter dial 1 permit 0 0
set filter alive 0 deny udp src eq 123
# Inkomend NTP-verkeer houdt de verbinding niet open
set filter alive 1 deny udp dst eq 123
# Uitgaand NTP-verkeer houdt de verbinding niet open
set filter alive 2 permit 0/0 0/0

Meer details staan in de sectie PACKET FILTERING in ppp(8) en in de voorbeelden in /usr/shared/examples/ppp/.

Sommige Internetproviders blokkeren lage poorten, waardoor NTP niet kan werken omdat er nooit een antwoord ontvangen kan worden door een machine.

29.10.6. Meer informatie

HTML-documentatie voor de NTP-server staat in /usr/shared/doc/ntp/.

29.11. Hosts op afstand loggen met syslogd

Het omgaan met systeemlogs is een cruciaal aspect van zowel beveiligings- als systeembeheer. Het in de gaten houden van logbestanden van meerdere hosts kan nogal onhandelbaar worden als deze hosts over (middel)grote netwerken zijn verspreid, of wanneer ze deel zijn van verschillende soorten netwerken. In deze gevallen kan het op afstand loggen het gehele proces een stuk aangenamer maken.

Het centraal loggen naar een specifieke loghost kan wat van de administratieve last van het beheren van logbestanden wegnemen. Het aggregeren, samenvoegen, en roteren van logbestanden kan op één enkele plaats worden ingesteld, door gebruik te maken van de eigen gereedschappen van FreeBSD, zoals syslogd(8) en newsyslog(8). In de volgende voorbeeldconfiguratie zal host A, genaamd logserv.example.com, loginformatie voor het plaatselijke netwerk verzamelen. Host B, genaamd logclient.example.com, zal loginformatie aan het serversysteem doorgeven. In echte configuraties hebben beide hosts degelijke voor- en terugwaartse DNS of regels in /etc/hosts nodig. Anders worden de gegevens geweigerd door de server.

29.11.1. Configuratie van de logserver

Logservers zijn machines die zijn geconfigureerd om loginformatie van hosts op afstand te accepteren. In de meeste gevallen is dit om de configuratie te vergemakkelijken, in andere gevallen kan het gewoon een beheersbeslissing zijn. Ongeacht de reden zijn er enkele eisen voordat er verder wordt gegaan.

Een juist geconfigureerde logserver voldoet aan de volgende minimale eisen:

  • De regels van de firewall staan toe dat UDP wordt doorgegeven op poort 514 van zowel de cliënt als de server;

  • syslogd is ingesteld om berichten op afstand van cliëntmachines te accepteren;

  • De syslogd-server en alle cliëntmachines moeten geldige regels hebben voor zowel voorwaartse als terugwaartse DNS, of correct zijn geconfigureerd in /etc/hosts.

Om de logserver te configureren, moet de cliënt vermeld zijn in /etc/syslog.conf, en moet de logfaciliteit zijn gespecificeerd:

+logclient.example.com
*.*	/var/log/logclient.log

Meer informatie over de verschillende ondersteunde en beschikbare faciliteiten kan gevonden worden in de handleidingpagina syslog.conf(5).

Eenmaal toegevoegd worden alle faciliteits-berichten gelogd naar het eerder gespecificeerde bestand, /var/log/logclient.log.

De servermachine moet ook het volgende in /etc/rc.conf hebben staan:

syslogd_enable="YES"
syslogd_flags="-a logclient.example.com -v -v"

De eerste optie zet de daemon syslogd aan tijdens het opstarten, en de tweede regel staat toe dat gegevens van de cliënt op deze server worden geaccepteerd. Het laatste gedeelte, dat -v -v gebruikt, verhoogt de verbositeit van gelogde berichten. Dit is extreem handig voor het optimaal instellen van faciliteiten aangezien beheerders kunnen zien welk soort berichten onder welke faciliteit worden gelogd.

Er kunnen meerdere opties -a worden gespecificeerd om logging vanuit meerdere cliënten toe te staan. IP-adressen en hele netblokken mogen ook worden gespecificeerd, bekijk de hulppagina syslog(3) voor een volledige lijst van mogelijke opties.

Als laatste dient het logbestand gecreëerd te worden. De gebruikte manier maakt niet uit, maar touch(1) werkt prima in dit soort situaties:

# touch /var/log/logclient.log

Nu dient het syslogd-daemon herstart en geverifieerd worden:

# service syslogd restart
# pgrep syslog

Als er een PID wordt teruggegeven, dan is de server succesvol herstart, en kan er begonnen worden met de configuratie van de cliënt. Raadpleeg de log /var/log/messages voor uitvoer als de server niet is herstart.

29.11.2. Configuratie van de logcliënt

Een logcliënt is een machine die loginformatie naar een logserver verstuurt en daarnaast lokale kopieën bewaart.

Net als logservers moeten logcliënten ook aan enkele minimumeisen voldoen:

  • syslogd(8) moet zijn ingesteld om berichten van bepaalde soorten naar een logserver te sturen, die ze moet accepteren;

  • De firewall moet UDP-pakketten doorlaten op poort 514;

  • Zowel voorwaartse als terugwaartse DNS moeten geconfigureerd zijn of juiste regels in /etc/hosts hebben.

De configuratie van cliënten is wat soepeler dan die van servers. De cliëntmachine moet de volgende regels in /etc/rc.conf hebben:

syslogd_enable="YES"
syslogd_flags="-s -v -v"

Net als eerder zullen deze regels de daemon syslogd tijdens het opstarten aanzetten, en de verbositeit van gelogde berichten verhogen. De optie -s voorkomt dat logs van deze cliënt vanuit andere hosts worden geaccepteerd.

Faciliteiten beschrijven het systeemgedeelte waarvoor een bericht is gegenereerd. ftp en ipfw bijvoorbeeld zijn beide faciliteiten. Wanneer er logberichten worden gegenereerd voor deze twee diensten, zullen ze normaalgesproken deze twee gereedschappen in elk logbericht opnemen. Faciliteiten worden vergezeld van een prioriteit of niveau, welke wordt gebruikt om aan te geven hoe belangrijk een logbericht is. De meest voorkomende zullen warning en info zijn. Bekijk de handleidingpagina syslog(3) voor een volledige lijst van beschikbare faciliteiten en prioriteiten.

De logserver moet in /etc/syslog.conf van de cliënt zijn gedefinieerd. In dit geval wordt het symbool @ gebruikt om loggegevens naar een server op afstand te sturen en zou er ongeveer als de volgende regel uit moeten zien:

*.*	@logserv.example.com

Eenmaal toegevoegd moet syslogd worden herstart zodat de veranderingen effect hebben:

# service syslogd restart

Om te testen of logberichten over het netwerk worden verzonden, wordt logger(1) op de cliënt gebruikt om een bericht naar syslogd te sturen:

# logger "Testbericht van logclient"

Dit bericht dient nu zowel in /var/log/messages op de cliënt als /var/log/logclient.log op de logserver te staan.

29.11.3. Logservers debuggen

In bepaalde gevallen kan het nodig zijn om te debuggen als berichten niet door de logserver worden ontvangen. Er zijn verschillende redenen waarom dit kan gebeuren; de twee meest voorkomende zijn echter voorvallen met de netwerkverbinding en DNS. Om deze gevallen te testen, dient te worden nagegaan dat beide hosts elkaar kunnen bereiken door de hostnaam in /etc/rc.conf te gebruiken. Als dit juist lijkt te werken, dient de optie syslogd_flags in /etc/rc.conf te worden veranderd.

In het volgende voorbeeld is /var/log/logclient.log leeg, en noemt /var/log/messages geen reden waarom het mislukt. Verander de optie syslogd_flags zoals in het volgende voorbeeld en herstart om de debuguitvoer te verhogen:

syslogd_flags="-d -a logclien.example.com -v -v"
# service syslogd restart

Debuggegevens zoals de volgende zullen meteen na de herstart over het scherm vliegen:

logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
syslogd: restarted
logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
Logging to FILE /var/log/messages
syslogd: kernel boot file is /boot/kernel/kernel
cvthname(192.168.1.10)
validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
rejected in rule 0 due to name mismatch.

Het is duidelijk dat de berichten worden geweigerd wegens een niet-overeenkomende naam. Na de configuratie grondig te hebben herzien, lijkt het of een typefout in de volgende regel in /etc/rc.conf een probleem heeft:

syslogd_flags="-d -a logclien.example.com -v -v"

De regel dient logclient, niet logclien te bevatten. Nadat de juiste wijzigingen zijn gemaakt, wordt er herstart met de verwachte resultaten:

# service syslogd restart
logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart
syslogd: restarted
logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel
syslogd: kernel boot file is /boot/kernel/kernel
logmsg: pri 166, flags 17, from logserv.example.com,
msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2
cvthname(192.168.1.10)
validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com;
accepted in rule 0.
logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2
Logging to FILE /var/log/logclient.log
Logging to FILE /var/log/messages

Nu worden de berichten juist ontvangen en in het correcte bestand geplaatst.

29.11.4. Beveiligingsoverwegingen

Zoals bij alle netwerkdiensten, dienen beveiligingseisen in acht te worden genomen voordat deze configuratie wordt geïmplementeerd. Soms kunnen logbestanden gevoelige gegevens bevatten over diensten die aanstaan op de lokale host, gebruikersaccounts, en configuratiegegevens. Netwerkgegevens die van de cliënt naar de server worden verzonden worden niet versleuteld noch met een wachtwoord beveiligd. Als versleuteling nodig is, kan security/stunnel worden gebruikt, wat gegevens over een versleutelde tunnel verstuurt.

Aan lokale beveiliging moet ook gedacht worden. Logbestanden worden niet versleuteld tijdens gebruik of na logrotatie. Lokale gebruikers kunnen deze bestanden benaderen om aanvullende inzichten over de systeemconfiguratie op te doen. In deze gevallen is het van kritiek belang om de juiste rechten op deze bestanden in te stellen. Het gereedschap syslogd(8) ondersteunt het instellen van rechten op nieuw aangemaakte en geroteerde logbestanden. Het instellen van logbestanden op modus 600 dient al het ongewenste spieken door lokale gebruikers te verhinderen.


All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.