diff --git a/nl_NL.ISO8859-1/books/handbook/filesystems/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/filesystems/chapter.sgml index 6b9c919f3c..07e20d3e1b 100644 --- a/nl_NL.ISO8859-1/books/handbook/filesystems/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/filesystems/chapter.sgml @@ -1,673 +1,658 @@ Tom Rhodes Geschreven door Wouter Reckman Vertaald door René Ladan Ondersteuning van bestandssystemen Overzicht Bestandssystemen Ondersteuning bestandssystemen Bestandssystemen Bestandssystemen zijn een integraal onderdeel van ieder besturingssysteem. Ze stellen gebruikers in de gelegenheid om bestanden te uploaden en op te slaan, geven toegang tot gegevens en maken natuurlijk harde schijven bruikbaar. Verschillende besturingssystemen hebben gewoonlijk één gezamenlijk aspect, namelijk het bestandssysteem. Op &os; staat dit bestandssysteem bekend onder de naam Fast File System ofwel FFS, dat is gebaseerd op het oorspronkelijke Unix™ File System, ook bekend als UFS. Dit is het oorspronkelijke bestandssysteem van &os; dat op harde schijven wordt geplaatst voor gegevenstoegang. &os; ondersteunt daarnaast ook een groot aantal andere bestandssystemen om lokaal toegang tot gegevens van andere besturingssystemen te bewerkstelligen; dat wil zeggen: gegevens opgeslagen op lokaal aangesloten USB opslagapparaten, flash drives, en harde schijven. Verder is er ook ondersteuning voor vreemde bestandssystemen. Dit zijn bestandssystemen ontwikkeld voor andere besturingssystemen zoals het &linux; Extended File System (EXT) en het &sun; Z File System (ZFS). Er zijn verschillende gradaties van ondersteuning voor de verschillende bestandssystemen op &os;. Sommigen vereisen het laden van een kernelmodule, voor anderen moet een toolset worden geïnstalleerd. Dit hoofdstuk is geschreven om gebruikers van &os; te helpen om op hun systeem toegang te verkrijgen tot andere bestandssystemen, te beginnen met het &sun; Z File System. Na het lezen van dit hoofstuk weet de lezer: Het verschil tussen eigen en ondersteunde bestandssystemen. Welke bestandssystemen zijn ondersteund in &os;. Hoe niet-eigen bestandssystemen geactiveerd, geconfigureerd, benaderd en gebruikt kunnen worden. Voorafgaand aan het lezen van dit hoofdstuk dient de lezer: Begrip te hebben van de beginselen van &unix; en &os; (). Bekend te zijn met de beginselen van kernelconfiguratie en -compilatie (). Vertrouwd te zijn met installatie van software van derden in &os; (). Enigszins bekend te zijn met schijven, opslag en apparaatnamen in &os; (). - - - - - Ondersteuning van ZFS wordt - beschouwd als experimenteel. Sommige opties kunnen beperkt - zijn in functionaliteit, andere onderdelen werken mogelijk in - het geheel niet. Op een zeker moment zal deze ondersteuning - klaar voor productie zijn en zal deze documentatie worden - aangepast aan de nieuwe situatie. - Het Z File System (ZFS) Het Z File System, ontwikkeld door &sun;, is een nieuwe technologie ontwikkeld om gebruik te maken van een pool-gebaseerde opslagmethode. Dit houdt in dat ruimte pas wordt gebruikt wanneer het nodig is voor dataopslag. Verder is het ontworpen voor maximale integriteit van gegevens, ondersteuning van gegevens-snapshots, meerdere kopieën, en gegevenschecksums. Ook is een nieuw gegevensreplicatiemodel, bekend als RAID-Z, toegevoegd; RAID-Z lijkt op RAID5, maar is ontworpen om corruptie tijdens het schrijven van gegevens te voorkomen. ZFS tuning Het ZFS subsysteem maakt gebruik van veel systeembronnen waardoor het nodig kan zijn een en ander af te stellen, zodat voor het dagelijks gebruik maximale efficiëntie wordt behaald. Doordat het een experimentele eigenschap van &os; is, kan dit in de nabije toekomst veranderen; op dit moment echter, worden de volgende stappen aangeraden. Geheugen De totale hoeveelheid systeemgeheugen dient minstens één gigabyte te zijn, maar twee gigabytes of meer wordt aanbevolen. In alle voorbeelden hier heeft het systeem één gigabyte geheugen, met verschillende andere afstelmechanismen in werking. Sommigen hebben succes gehad met minder dan een gigabyte geheugen, maar met een dergelijke, beperkte hoeveelheid geheugen is de kans groot dat onder zware belasting een kernelpanic in &os; op zal treden door uitputting van het geheugen. Kernelconfiguratie Het wordt aangeraden om ongebruikte stuurprogramma's en opties te verwijderen uit het kernelconfiguratiebestand. Omdat de meeste stuurprogramma's beschikbaar zijn als modules kunnen ze alsnog worden geladen door middel van het bestand /boot/loader.conf. Gebruikers van de &i386;-architectuur dienen de volgende optie aan hun kernelconfiguratiebestand toe te voegen, de kernel opnieuw te compileren, en opnieuw op te starten: options KVA_PAGES=512 Deze optie vergroot de kerneladresruimte, waarmee het mogelijk wordt gemaakt om de vm.kvm_size afstelling hoger dan de huidige limiet van 1 GB (2 GB voor PAE) in te stellen. Deel, om de meest geschikte waarde voor deze optie te vinden, de gewenste hoeveelheid adresruimte door vier (4). In dit geval is dat 512 voor 2 GB. Loader tunables De kmem adresruimte dient te worden vergroot op alle &os; architecturen. Op het testsysteem met één gigabyte fysiek geheugen werd succes behaald met de volgende opties, die in het bestand /boot/loader.conf geplaatst dienen te worden, waarna het systeem opnieuw moet worden opgestart: vm.kmem_size="330M" vm.kmem_size_max="330M" vfs.zfs.arc_max="40M" vfs.zfs.vdev.cache.size="5M" Zie voor een meer gedetailleerde lijst van aanbevelingen aangaande ZFS-afstelling: . Gebruik maken van <acronym>ZFS</acronym> Er is een opstartmechanisme dat &os; in staat stelt om ZFS pools te mounten tijdens initialisatie van het systeem. Voer de volgende commando's uit om dit in te stellen: &prompt.root; echo 'zfs_enable="YES"' >> /etc/rc.conf &prompt.root; /etc/rc.d/zfs start In het resterende deel van dit document wordt aangenomen dat er drie SCSI-schijven beschikbaar zijn, en dat hun apparaatnamen respectievelijk da0, da1 en da2 zijn. Gebruikers van IDE-hardware kunnen de ad apparaten gebruiken in plaats van SCSI-apparaten. Een pool op een enkele schijf Voer het commando zpool uit om een simpele, niet-redundante ZFS-pool op een enkele schijf aan te maken: &prompt.root; zpool create example /dev/da0 Bestudeer de uitvoer van het commando df om de nieuwe pool te zien: &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235230 1628718 13% / devfs 1 1 0 100% /dev /dev/ad0s1d 54098308 1032846 48737598 2% /usr example 17547136 0 17547136 0% /example In deze uitvoer wordt duidelijk dat de example-pool niet alleen is aangemaakt, maar ook direct gemount is. Hij is ook toegankelijk, net als een gewoon bestandssysteem; er kunnen bestanden op worden aangemaakt en gebruikers kunnen er op rondkijken zoals in het volgende voorbeeld: &prompt.root cd /example &prompt.root; ls &prompt.root; touch testfile &prompt.root; ls -al total 4 drwxr-xr-x 2 root wheel 3 Aug 29 23:15 . drwxr-xr-x 21 root wheel 512 Aug 29 23:12 .. -rw-r--r-- 1 root wheel 0 Aug 29 23:15 testfile Helaas benut deze pool nog geen ZFS-mogelijkheden. Maak een bestandssysteem aan op deze pool en activeer er compressie op: &prompt.root; zfs create example/compressed &prompt.root; zfs set compression=gzip example/compressed example/compressed is nu een gecomprimeerd ZFS-bestandssysteem. Probeer er een paar grote bestanden naartoe te kopiëren door ze naar /example/compressed te kopiëren. De compressie kan nu worden uitgeschakeld met: &prompt.root; zfs set compression=off example/compressed Voer het volgende commando uit om het bestandssysteem te unmounten, en controleer dat daarna met df: &prompt.root; zfs umount example/compressed &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235232 1628716 13% / devfs 1 1 0 100% /dev /dev/ad0s1d 54098308 1032864 48737580 2% /usr example 17547008 0 17547008 0% /example Mount het bestandssysteem opnieuw om het weer toegankelijk te maken en controleer met df: &prompt.root; zfs mount example/compressed &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235234 1628714 13% / devfs 1 1 0 100% /dev /dev/ad0s1d 54098308 1032864 48737580 2% /usr example 17547008 0 17547008 0% /example example/compressed 17547008 0 17547008 0% /example/compressed De pool en het bestandssysteem zijn ook zichtbaar in de uitvoer van mount: &prompt.root; mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1d on /usr (ufs, local, soft-updates) example on /example (zfs, local) example/data on /example/data (zfs, local) example/compressed on /example/compressed (zfs, local) Zoals is te zien kunnen ZFS-bestandssystemen, nadat ze zijn gecreëerd, net als gewone bestandssystemen worden gebruikt; er zijn echter ook vele andere mogelijkheden beschikbaar. In het volgende voorbeeld wordt er een nieuw bestandssysteem data gecreëerd. Er zullen belangrijke bestanden op worden bewaard, dus het bestandssysteem wordt zodanig ingesteld dat het twee kopieën van ieder gegevensblok opslaat: &prompt.root; zfs create example/data &prompt.root; zfs set copies=2 example/data Het is nu mogelijk om het gegevens- en ruimtegebruik te bekijken door df opnieuw te draaien: &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235234 1628714 13% / devfs 1 1 0 100% /dev /dev/ad0s1d 54098308 1032864 48737580 2% /usr example 17547008 0 17547008 0% /example example/compressed 17547008 0 17547008 0% /example/compressed example/data 17547008 0 17547008 0% /example/data Merk op dat ieder bestandssysteem in de pool dezelfde hoeveelheid vrije ruimte heeft. Dit is de reden dat df steeds wordt gebruikt tussen de voorbeelden door, om te laten zien dat de bestandssystemen slechts zoveel ruimte gebruiken als ze nodig hebben en allemaal putten uit dezelfde pool. Het ZFS bestandssysteem elimineert concepten als volumes en partities, en staat verschillende bestandssystemen toe om in dezelfde pool te bestaan. Verwijder nu de bestandssystemen en verwijder daarna de pool, omdat deze niet meer nodig zijn: &prompt.root; zfs destroy example/compressed &prompt.root; zfs destroy example/data &prompt.root; zpool destroy example Schijven gaan slechter werken en begeven het, een onvermijdelijke eigenschap. Wanneer de schijf stukgaat zullen de gegevens verloren gaan. Een methode om gegevensverlies ten gevolge van een kapotte harde schijf te vermijden is het implementeren van RAID. ZFS ondersteunt deze mogelijkheid in zijn pool-ontwerp en wordt beschreven in de volgende sectie. <acronym>ZFS</acronym> RAID-Z Zoals eerder opgemerkt wordt in deze sectie aangenomen dat er drie SCSI-schijven bestaan als de apparaten da0, da1 en da2 (of ad0 en hoger als IDE-schijven worden gebruikt). Voer het volgende commando uit om een RAID-Z-pool te creëren: &prompt.root; zpool create storage raidz da0 da1 da2 &sun; raadt aan om tussen de drie en negen schijven te gebruiken voor een RAID-Z-configuratie. Overweeg, als u een enkele pool met 10 of meer schijven nodig heeft, om deze te splitsen in kleine RAID-Z-groepen. Overweeg, als u slechts twee schijven heeft en nog steeds redundantie nodig heeft, om in plaats hiervan een ZFS-spiegel te gebruiken. Bekijk de handleidingpagina &man.zpool.8; voor meer details. De storage zpool zou gecreëerd moeten zijn. Dit kan worden geverifieerd met de &man.mount.8; en &man.df.1; commando's zoals eerder. Er kunnen meer schijfapparaten worden toegewezen door ze aan het einde van de bovenstaande lijst toe te voegen. Maak een nieuw bestandssysteem in de pool, genaamd home waar op den duur de gebruikersbestanden geplaatst zullen worden: &prompt.root; zfs create storage/home Het is nu mogelijk om compressie in te schakelen en extra kopieën te bewaren van de gebruikersmappen en -bestanden. Dit kan net als eerder worden bewerkstelligd door de volgende commando's uit te voeren: &prompt.root; zfs set copies=2 storage/home &prompt.root; zfs set compression=gzip storage/home Kopieer, om dit als de nieuwe home-map voor gebruikers in te stellen, de gebruikersgegevens naar deze map en creëer de benodigde links: &prompt.root; cp -rp /home/* /storage/home &prompt.root; rm -rf /home /usr/home &prompt.root; ln -s /storage/home /home &prompt.root; ln -s /storage/home /usr/home De gebruikersgegevens zouden nu op het nieuw aangemaakte /storage/home bestandssysteem moeten staan. Test dit door een nieuwe gebruiker aan te maken en daarmee in te loggen. Probeer een snapshot te maken dat later weer hersteld kan worden: &prompt.root; zfs snapshot storage/home@08-30-08 Merk op dat de snapshot-optie alleen een echt bestandssysteem vastlegt, geen mappen of bestanden. Het @-karakter wordt gebruikt als scheidingsteken tussen de naam van het bestandssysteem of de naam van het volume. Wanneer de home-map van een gebruiker wordt weggegooid, kan deze worden hersteld met: &prompt.root; zfs rollback storage/home@08-30-08 Voer ls in de .zfs/snapshot directory van het bestandssysteem uit om een lijst van alle beschikbare snapshots te krijgen. Voer, om bijvoorbeeld het zojuist gemaakte snapshot te zien, het volgende commando uit: &prompt.root; ls /storage/home/.zfs/snapshot Het is mogelijk om een script te schrijven dat maandelijks een snapshot van de gebruikersgegevens maakt; na verloop van tijd kunnen snapshots echter een grote hoeveelheid schrijfruimte in beslag nemen. Het vorige snapshot kan worden verwijderd met het volgende commando: &prompt.root; zfs destroy storage/home@08-30-08 Na al dit testen is er geen reden om /storage/home in zijn huidige staat nog te bewaren. Maak er het echte /home bestandssysteem van: &prompt.root; zfs set mountpoint=/home storage/home Het uitvoeren van de commando's df en mount laat zien dat het systeem ons bestandssysteem nu als de echte /home behandelt: &prompt.root; mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1d on /usr (ufs, local, soft-updates) storage on /storage (zfs, local) storage/home on /home (zfs, local) &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235240 1628708 13% / devfs 1 1 0 100% /dev /dev/ad0s1d 54098308 1032826 48737618 2% /usr storage 26320512 0 26320512 0% /storage storage/home 26320512 0 26320512 0% /home Hiermee is de RAID-Z configuratie compleet. Voer het volgende commando uit om status-updates van de gecreëerde bestandssystemen te krijgen tijdens het draaien van de nachtelijke &man.periodic.8;: &prompt.root; echo 'daily_status_zfs_enable="YES"' >> /etc/periodic.conf Het herstellen van <acronym>RAID</acronym>-Z Iedere software-RAID heeft een methode om zijn status te inspecteren. ZFS is geen uitzondering. De status van RAID-Z-apparaten kan worden geïnspecteerd met het volgende commando: &prompt.root; zpool status -x Als alle pools in orde zijn en alles is normaal, dan wordt het volgende bericht weergegeven: all pools are healthy Als er een probleem is, misschien een schijf die offine is gegaan, dan wordt de status van de pool weergegeven en dat zal er als volgt uitzien: pool: storage state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scrub: none requested config: NAME STATE READ WRITE CKSUM storage DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 da0 ONLINE 0 0 0 da1 OFFLINE 0 0 0 da2 ONLINE 0 0 0 errors: No known data errors Hier staat dat het apparaat offline is gezet door de beheerder. Dat is waar voor dit specifieke voorbeeld. Om de schijf offline te zetten werd het volgende commando gebruikt: &prompt.root; zpool offline storage da1 Het is nu mogelijk om de schijf da1 te vervangen nadat het systeem uitgeschakeld is. Zodra het systeem weer opgestart is, kan het volgende commando worden uitgevoerd om de schijf te vervangen: &prompt.root; zpool replace storage da1 Nu kan de status opnieuw geïnspecteerd worden, dit keer zonder de vlag, om de statusinformatie op te vragen: &prompt.root; zpool status storage pool: storage state: ONLINE scrub: resilver completed with 0 errors on Sat Aug 30 19:44:11 2008 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 errors: No known data errors Zoals te zien in dit voorbeeld lijkt alles normaal te zijn. Gegevensverificatie Zoals eerder opgemerkt gebruikt ZFS checksums om de integriteit van opgeslagen gegevens te verifiëren. Ze worden automatisch ingeschakeld bij het creëeren van bestandssystemen en kunnen worden uitgeschakeld door middel van het volgende commando: &prompt.root; zfs set checksum=off storage/home Dit is echter geen verstandig idee, omdat checksums zeer weinig opslagruimte innemen en nuttiger zijn wanneer ze zijn ingeschakeld. Het lijkt daarnaast ook geen merkbare invloed op de prestaties te hebben wanneer ze zijn ingeschakeld. Wanneer ze aanstaan is het mogelijk om ZFS gegevensintegriteit te laten controleren door middel van checksum-verificatie. Dit proces staat bekend als scrubbing. Voer het volgende commando uit om de gegevensintegriteit van de storage-pool te controleren: &prompt.root; zpool scrub storage Dit proces kan, afhankelijk van de hoeveelheid opgeslagen gegevens, een aanzienlijke hoeveelheid tijd in beslag nemen. Het is daarnaast ook zeer I/O-intensief, zozeer dat slechts één van deze operaties tegelijkertijd uitgevoerd kan worden. Nadat de scrub is voltooid wordt de status bijgewerkt en kan deze worden bekeken door een statusaanvraag te doen: &prompt.root; zpool status storage pool: storage state: ONLINE scrub: scrub completed with 0 errors on Sat Aug 30 19:57:37 2008 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 errors: No known data errors De voltooiingstijd is in dit voorbeeld duidelijk zichtbaar. Deze eigenschap helpt om gegevensintegriteit te garanderen gedurende een langere tijdsperiode. Er zijn vele andere opties voor het Z-bestandssysteem, zie de handleidingpagina's &man.zfs.8; en &man.zpool.8;. diff --git a/nl_NL.ISO8859-1/books/handbook/firewalls/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/firewalls/chapter.sgml index 80edffac58..afb70a6018 100644 --- a/nl_NL.ISO8859-1/books/handbook/firewalls/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/firewalls/chapter.sgml @@ -1,3591 +1,3604 @@ Joseph J. Barbish Bijgedragen door Brad Davis Omgezet naar SGML en bijgewerkt door Siebrand Mazeland Vertaald door René Ladan Firewalls firewall beveiliging firewalls Inleiding Firewalls bieden de mogelijkheid om inkomend en uitgaand verkeer op een systeem te filteren. Een firewall gebruikt daarvoor een of meer groepen regels (rules) om netwerkpakketten te inspecteren als ze binnenkomen of weggaan door netwerkverbindingen en staat dat verkeer dan toe of blokkeert het. De regels van een firewall kunnen één of meerdere eigenschappen van pakketten onderzoeken waaronder, maar niet uitsluitend, het protocol, het bron- of bestemmingsadres en de bron- en bestemmingspoort. Firewalls kunnen de veiligheid van een host of netwerk enorm vergroten. Ze kunnen één of meer van de volgende dingen doen: Applicaties, diensten en machines op een intern netwerk te beschermen tegen ongewild verkeer van het Internet. Toegang tot Internet voor interne hosts te limiteren of uitschakelen. Ondersteuning bieden voor netwerkadres vertaling (network address translation of NAT), waarmee er vanaf een intern netwerk met private IP adressen een Internetverbinding gedeeld kan worden met één IP adres of met een groep van publieke adressen die automatisch wordt toegewezen. Na het lezen van dit hoofdstuk weet de lezer: Hoe pakketfilteringsregels op de juiste wijze samengesteld kunnen worden; De verschillen tussen de firewalls die bij &os; worden geleverd; Hoe de OpenBSD firewall PF te gebruiken en in te stellen; Hoe IPFILTER te gebruiken en in te stellen; Hoe IPFW te gebruiken en in te stellen. Er wordt aangenomen dat de lezer van dit hoofdstuk: Basisbegrip heeft van &os; en Internetconcepten. Firewallconcepten firewall sets regels Er zijn twee basismogelijkheden om sets met regels te maken voor firewalls: inclusief of exclusief. Een exclusieve firewall staat al het verkeer door behalve het verkeer dat past bij de set met regels. Een inclusieve firewall doet het tegenovergestelde. Die staat alleen verkeer toe dat past bij de regels en blokkeert al het overige verkeer. Een inclusieve firewall biedt veel betere controle over het uitgaande verkeer, waardoor het een betere keuze is voor systemen die diensten op het publieke Internet aanbieden. Het beheert ook het type verkeer dat van het publieke Internet afkomt en toegang heeft tot uw privé-netwerk. Al het verkeer dat niet aan de regels voldoet wordt geblokkeerd en gelogd, dat is zo ontworpen. Inclusieve firewalls zijn over het algemeen veiliger dan exclusieve firewalls omdat ze het risico dat ongewenst verkeer door ze heen gaat aanzienlijk verminderen. Tenzij anders aangegeven, creëeren alle configuraties en voorbeelden van regelverzamelingen in dit hoofdstuk inclusieve firewalls. De beveiliging kan nog verder vergroot worden met een stateful firewall. Dit type firewall houdt bij welke connecties er door de firewall tot stand zijn gekomen en laat alleen verkeer door dat bij een bestaande connectie hoort of onderdeel is van een connectie in opbouw. Het nadeel van een stateful firewall is dat die kwetsbaar kan zijn voor Ontzegging van Dienst (DoS) aanvallen als er een groot aantal nieuwe verbindingen binnen korte tijd wordt opgezet. Met de meeste firewalls is het mogelijk een combinatie te maken van stateful en niet stateful gedrag om een optimale firewall voor een site te maken. Firewallsoftware &os; heeft drie soorten firewallsoftware in de basisinstallatie. Dat zijn: IPFILTER (ook bekend als IPF), IPFIREWALL (ook bekend als IPFW) en de pakketfilter van OpenBSD (ook bekend als PF). &os; heeft ook twee ingebouwde pakketten voor het regelen van verkeer (in de basis het beheersen van bandbreedtegebruik): &man.altq.4; en &man.dummynet.4;. Dummynet is traditioneel sterk verbonden met IPFW en ALTQ met PF. Het vormgeven van verkeer voor IPFILTER kan momenteel gedaan worden met IPFILTER voor NAT en filtering en IPFW met &man.dummynet.4; of door PF met ALTQ te gebruiken. IPFW en PF gebruiken allemaal regels om de toegang van pakketten tot een systeem te regelen, hoewel ze dat op andere manieren doen en ze een andere regelsyntaxis hebben. De reden dat er meerdere firewallpakketten in &os; zitten is dat verschillende mensen verschillende eisen en voorkeuren hebben. Geen enkel firewallpakket is het beste. De schrijver van dit artikel geeft de voorkeur aan IPFILTER omdat daarmee stateful regels minder complex zijn toe te passen in een omgeving waar NAT wordt gebruikt en IPF heeft een ingebouwde FTP proxy waardoor de regels voor het veilig gebruiken van FTP eenvoudiger worden. Omdat alle firewalls gebaseerd zijn op het inspecteren van aangegeven controlevelden in pakketten, moet iemand die sets van firewallregels opstelt begrijpen hoe TCP/IP werkt, welke waarde de controlevelden kunnen hebben en hoe die waarden gebruikt worden in normaal verkeer. Op de volgende webpagina wordt een prima uitleg gegeven: . John Ferrell Herzien en bijgewerkt door De OpenBSD Packet Filter (PF) en <acronym>ALTQ</acronym> firewall PF Vanaf juli 2003 is de OpenBSD firewalltoepassing PF geporteerd naar &os; en beschikbaar gekomen in de &os; Portscollectie. In 2004 was &os; 5.3 de eerste release die PF bevatte is integraal onderdeel van het basissysteem. PF is een complete en volledige firewall die optioneel ALTQ bevat (Alternate Queuing). ALTQ biedt Quality of Service (QoS) functionaliteit. het OpenBSD Project levert een uitstekend werk wat betreft het onderhouden van de PF FAQ. Zodoende zal deze sectie van het handboek zich richten op PF met betrekking tot &os; terwijl het ook wat algemene informatie over het gebruik zal geven. Voor gedetailleerde gebruikersinformatie wordt naar de PF FAQ verwezen. Meer informatie over PF voor &os; staat op . - De laadbare kernelmodule voor PF gebruiken - - Sinds de uitgave van &os; 5.3 wordt PF geleverd in de - basisinstallatie als een aparte tijdens runtime laadbare module. Het - systeem zal de PF kernelmodule dynamisch laden wanneer het - statement pf_enable="YES" voor - &man.rc.conf.5; aanwezig is. De PF module - zal echter niet geladen worden als het systeem geen instellingenbestand - met een PF-regelverzameling kan vinden. De - standaardplaats is /etc/pf.conf. Indien uw - PF-regelverzameling ergens anders staat, voeg dan - pf_rules="/pad/pf.rules" - aan uw instellingenbestand /etc/rc.conf toe - om de plaats te specificeren. + De laadbare kernelmodules voor PF gebruiken + + Voeg de volgende regel toe aan /etc/rc.conf om + de kernelmodule PF te laden: + + pf_enable="YES" + + Draai vervolgens het opstartscript om de module te laden: + + &prompt.root; /etc/rc.d/pf start + + Merk op dat de PF Module niet laadt als het het instellingenbestand + met de regelverzameling niet kan vinden. De standaardlocatie is + /etc/pf.conf. Als de regelverzameling voor PF zich + elders bevindt, kan PF worden verteld om daar te kijken een regel + analoog aan de volgende aan /etc/rc.conf toe te + voegen: + + pf_rules="/pad/naar/pf.conf" Sinds &os; 7.0 is het voorbeeld pf.conf dat in /etc/ stond verplaatst naar /usr/share/examples/pf/. Voor versies van &os; voor 7.0 is er standaard een /etc/pf.conf aanwezig. De module PF kan ook handmatig vanaf de opdrachtregel geladen worden: &prompt.root; kldload pf.ko - De laadbare module was gemaakt met &man.pflog.4; aangezet - dat ondersteuning biedt voor logging. Indien u andere - mogelijkheden van PF nodig heeft dient u - ondersteuning voor PF in de kernel te + Logondersteuning voor PF wordt geleverd door + pflog.ko en kan worden geladen door de volgende regel + aan /etc/rc.conf toe te voegen: + + pflog_enable="YES" + + Draai vervolgens het opstartscript om de module te laden: + + &prompt.root; /etc/rc.d/pflog start + + Als u andere mogelijkheden van PF nodig heeft + dient u ondersteuning voor PF in de kernel te compileren. Kernelopties voor PF kernelopties device pf kernelopties device pflog kernelopties device pfsync Hoewel het niet nodig is om ondersteuning voor PF in de kernel te compileren, biedt dit wel de mogelijkheid om van een van PF's geavanceerde mogelijkheden gebruik te maken die niet in de laadbare module zitten, namelijk &man.pfsync.4;, dat een pseudo-apparaat is dat zekere veranderingen aan de toestandstabel die door PF wordt gebruikt prijsgeeft. Het kan worden gecombineerd met &man.carp.4; om failover firewalls aan te maken die gebruik maken van PF. Meer informatie over CARP kan gevonden worden in van het Handboek. De kernelopties voor PF kunnen gevonden worden in /usr/src/sys/conf/NOTES en zijn hieronder gereproduceerd: device pf device pflog device pfsync De optie device pf schakelt ondersteuning voor de Packet Filter firewall (&man.pf.4;) in. De optie device pflog schakelt het optionele &man.pflog.4; pseudo-netwerkapparaat in dat gebruikt kan worden om verkeer te loggen naar een &man.bpf.4; descriptor. De &man.pflogd.8; daemon kan gebruikt worden om de logboekinformatie naar schijf te schrijven. De optie device pfsync schakelt het optionele &man.pfsync.4; pseudo netwerkapparaat in waarmee de toestandswijzigingen gemonitord kunnen worden. Beschikbare opties voor <filename>rc.conf</filename> De volgende &man.rc.conf.5; statements stellen PF en &man.pflog.4; in tijdens het opstarten: pf_enable="YES" # Schakel PF in (laad module als nodig) pf_rules="/etc/pf.conf" # bestand met regels voor pf pf_flags="" # aanvullende vragen voor opstarten pfctl pflog_enable="YES" # start pflogd(8) pflog_logfile="/var/log/pflog" # waar pflogd het logboekbestand moet opslaan pflog_flags="" # aanvullende vlaggen voor opstarten pflogd Als er een LAN achter de firewall staat en er pakketten doorgestuurd moeten worden naar computers op het LAN of als NAT actief is, dan is de volgende optie ook nodig: gateway_enable="YES" # Schakel in als LAN gateway Filterregels aanmaken PF leest de instelregels van &man.pf.conf.5; (standaard /etc/pf.conf) en het verandert, verwijdert, of geeft pakketten door aan de hand van de regels of definities die daar zijn gespecificeerd. De &os;-installatie bevat een aantal voorbeeldbestanden in /usr/share/examples/pf/. In de PF FAQ staat een complete behandeling van de PF regels. Houd tijdens het doornemen van de PF FAQ in de gaten dat verschillende versies van &os; verschillende versies van PF bevatten: &os; 5.X — PF is op OpenBSD 3.5 &os; 6.X — PF is op OpenBSD 3.7 &os; 7.X — PF is op OpenBSD 4.1 De &a.pf; is een goede plaats om vragen over het instellen en draaien van de PF firewall te stellen. Vergeet niet de mailinglijstarchieven te controleren alvorens vragen te stellen! Werken met PF Gebruik &man.pfctl.8; om PF te beheren. Hieronder staan wat nuttige commando's (bekijk de hulppagina &man.pfctl.8; voor alle beschikbare opties): Commando Doel pfctl PF aanzetten pfctl PF uitzetten pfctl all /etc/pf.conf Spoel alle regels door (nat, filter, toestand, tabel, etc.) en herlaad vanuit het bestand /etc/pf.conf pfctl [ rules | nat | state ] Rapporteer over de filterregels, NAT-regels, of toestandstabel pfctl /etc/pf.conf Controleer /etc/pf.conf op fouten, maar laad de regelverzameling niet <acronym>ALTQ</acronym> inschakelen ALTQ is alleen beschikbaar ondersteuning ervoor in de &os; Kernel te compileren. ALTQ wordt niet door alle netwerkkaartstuurprogramma's ondersteund. In &man.altq.4; staat een lijst met ondersteunde stuurprogramma's voor de betreffende versie. Met de volgende opties wordt ALTQ ingeschakeld en additionele functionaliteit toegevoegd: options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build options ALTQ schakelt het ALTQ raamwerk in. options ALTQ_CBQ schakelt Class Based Queuing (CBQ) in. Met CBQ kan de bandbreedte van een verbinding worden opgedeeld in verschillende klassen of wachtrijen om verkeer te prioriteren op basis van filterregels. options ALTQ_RED schakelt Random Early Detection (RED) in. RED wordt gebruikt om netwerkverstopping te voorkomen. RED doet dit door de lengte van de wachtrij te meten en die te vergelijken met de minimale en maximale drempelwaarden voor de wachtrij. Als de wachtrij groter is dan de maximale waarde worden alle nieuwe pakketten genegeerd. Het werkt naar zijn naam, dus RED negeert willekeurig pakketten van verschillende verbindingen. options ALTQ_RIO schakelt Random Early Detection In and Out in. options ALTQ_HFSC schakelt de Hierarchical Fair Service Curve Packet Scheduler in. Meer informatie over HFSC staat op . options ALTQ_PRIQ schakelt Priority Queuing (PRIQ) in. PRIQ laat verkeer dat in een hogere wachtrij staat altijd eerder door. options ALTQ_NOPCC schakelt SMP ondersteuning voor ALTQ in. Deze optie is verplicht op SMP systemen. De IPFILTER (IPF) firewall firewall IPFILTER Darren Reed is de auteur van IPFILTER, dat niet afhankelijk is van één besturingssysteem. Het is een open source applicatie die is geporteerd naar &os;, NetBSD, OpenBSD, SunOS, HP/UX en Solaris besturingssystemen. IPFILTER wordt actief ondersteund en onderhouden en er worden regelmatig nieuwe versies uigebracht. IPFILTER is gebaseerd op een firewall aan de kernelkant en een NAT mechanisme dat gecontroleerd en gemonitord kan worden door programma's in userland. De firewallregels kunnen ingesteld of verwijderd worden met het hulpprogramma &man.ipf.8;. De NAT regels kunnen ingesteld of verwijderd worden met &man.ipnat.1;. Het programma &man.ipfstat.8; kan actuele statistieken leveren voor de kernelonderdelen van IPFILTER. &man.ipmon.8; kan acties van IPFILTER wegschrijven naar logboekbestanden van het systeem. IPF is oorspronkelijk geschreven met logica die regels verwerkte volgens het principe de laatst passende regel wint en gebruikte toen alleen staatloze regels. In de loop der tijd is IPF verbeterd en zijn de opties quick en keep state toegevoegd waarmee de logica van het verwerken van regels drastisch is gemoderniseerd. In de officiële documentatie van IPF worden alleen de regels en verwerkingslogica behandeld. De moderne functies worden alleen behandeld als opties, waardoor hun nut dat er een veel betere en veiligere firewall mee te maken volledig onderbelicht blijft. De instructies in dit hoofdstuk zijn gebaseerd op regels die gebruik maken van de optie quick en de stateful optie keep state. Dit is het raamwerk waarmee een set van inclusieve firewallregels wordt samengesteld. Voor een gedetailleerde uitleg over de verwerking van de verouderde regels zie en . De IPF FAQ is te vinden op . Een doorzoekbaar archief van de open-source IPFilter mailing lijst is beschikbaar op . IPF inschakelen IPFILTER inschakelen IPF zit in de basisinstallatie van &os; als een aparte run time laadbare module. Een systeem laadt de IPF kernel laadbare module dynamisch als ipfilter_enable="YES" in rc.conf staat. Voor de laadbare module zijn de opties logging en default pass all ingeschakeld. IPF hoeft niet in de kernel gecompileerd te worden om het standaardgedrag te wijzigen naar block all. Dat is mogelijk door op het einde van de regelverzameling een regel block all toe te voegen die al het verkeer blokkeert. Kernelopties kernelopties IPFILTER kernelopties IPFILTER_LOG kernelopties IPFILTER_DEFAULT_BLOCK IPFILTER kernelopties Het is niet verplicht om IPF in te schakelen door de volgende opties in de &os; kernel te compileren. Dit wordt alleen beschreven als achtergrondinformatie. Door IPF in de kernel te compileren wordt de laadbare module niet gebruikt. Voorbeeld kernelinstellingen voor IPF staan beschreven in de /usr/src/sys/i386/conf/LINTin de kernelbroncode en worden hier beschreven: options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK options IPFILTER schakelt ondersteuning voor de IPFILTER firewall in. options IPFILTER_LOG schakelt de optie in waarmee IPF verkeer kan loggen door het naar het ipl pakketloggende pseudo–apparaat te schrijven voor iedere regel met het sleutelwoord log erin. options IPFILTER_DEFAULT_BLOCK wijzigt het standaardgedrag zodat ieder pakket waarop geen enkele pass regel van toepassing is wordt geblokkeerd. Deze instelling worden pas actief nadat een kernel waarvoor deze instellingen zijn gemaakt is gebouwd en geïnstalleerd. Beschikbare opties voor rc.conf De volgende instellingen moeten in /etc/rc.conf staan om IPF bij het opstarten te activeren: ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # laad regels uit het doelbestand ipmon_enable="YES" # Start IP monitor log ipmon_flags="-Ds" # D = start als daemon # s = log naar syslog # v = log tcp window, ack, seq # n = vertaal IP & poort naar namen Als er een LAN achter de firewall staat dat gebruik maakt van IP-adressen uit de private reeks, dan moet de volgende optie ook ingesteld worden om NAT-functionaliteit in te schakelen: gateway_enable="YES" # Schakel in als LAN gateway ipnat_enable="YES" # Start ipnat functie ipnat_rules="/etc/ipnat.rules" # bestand met regels voor ipnat IPF ipf Het commando &man.ipf.8; wordt gebruikt om het bestand met firewallregels te laden. Gewoonlijk wordt er een bestand aangemaakt waarin de situatieafhankelijke regels staan waarmee in één keer de bestaande regels kunnen worden vervangen: &prompt.root; ipf -Fa -f /etc/ipf.rules : verwijder alle interne tabellen met regels. : laad het aangegeven bestand met regels. Hiermee wordt het mogelijk wijzigingen te maken aan het bestand met eigen regels en met &man.ipf.8; de firewall aan te passen met verse regels zonder het systeem te booten. Deze methode is erg handig om nieuwe regels te testen omdat dit zo vaak als nodig gedaan kan worden. In &man.ipf.8; worden alle opties die beschikbaar zijn toegelicht. &man.ipf.8; verwacht dat het bestand met regels een standaard tekstbestand is. Het accepteert geen bestand met regels dat is opgesteld als een script dat gebruik maakt van substitutie. Er is wel een mogelijkheid om IPF regels op te stellen en gebruik te maken van substitutie. Meer informatie staat in . IPFSTAT ipfstat IPFILTER statistieken &man.ipfstat.8; haalt de totalen van de statistieken op die horen bij de firewall sinds die is gestart en toont deze. Het kan ook zijn dat de tellers in tussentijd op nul zijn gesteld met ipf –Z. In &man.ipfstat.8; worden alle details behandeld. Standaard ziet &man.ipfstat.8; uitvoer er ongeveer als volgt uit: input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 input packets logged: blocked 99286 passed 0 output packets logged: blocked 0 passed 0 packets logged: input 0 output 0 log failures: input 3898 output 0 fragment state(in): kept 0 lost 0 fragment state(out): kept 0 lost 0 packet state(in): kept 169364 lost 0 packet state(out): kept 431395 lost 0 ICMP replies: 0 TCP RSTs sent: 0 Result cache hits(in): 1215208 (out): 1098963 IN Pullups succeeded: 2 failed: 0 OUT Pullups succeeded: 0 failed: 0 Fastroute successes: 0 failures: 0 TCP cksum fails(in): 0 (out): 0 Packet log flags set: (0) Als er als optie voor inkomend of voor uitgaand wordt meegegeven, dan zal het commando de juiste lijst met regels die de kernel op dat moment gebruikt wordt weergeven. ipfstat –in toont de tabel met regels voor inkomend verkeer met regelnummers ipfstat –on toont de tabel met regels voor uitgaand verkeer met regelnummers De uitvoer ziet er ongeveer als volgt uit: @1 pass out on xl0 from any to any @2 block out on dc0 from any to any @3 pass out quick on dc0 proto tcp/udp from any to any keep state ipfstat –ih toont de tabel met regels voor inkomend verkeer, waarbij voor iedere regel staat hoe vaak die van toepassing was. ipfstat –oh toont de tabel met regels voor uitgaand verkeer, waarbij voor iedere regel staat hoe vaak die van toepassing was. De uitvoer ziet er ongeveer als volgt uit: 2451423 pass out on xl0 from any to any 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state Een van de belangrijkste functies van ipfstat is de vlag waarmee de staat-tabel wordt getoond op een wijze die vergelijkbaar is met de wijze waarop &man.top.1; de draaiende &os; procestabel toont. Als een firewall wordt aangevallen, dan geeft deze functie de mogelijkheid om de pakketten van de aanvaller te identificeren en nader te onderzoeken. De optionele subvlaggen bieden de mogelijkheid om een bron of bestemmings IP adres, poort of protocol aan te geven dat gemonitord moet worden. Details zijn na te lezen in &man.ipfstat.8;. IPMON ipmon IPFILTER loggen Om &man.ipmon.8; te laten werken zoals bedoeld, moet de kerneloptie IPFILTER_LOG aan staan. Dit commando kan op twee verschillende wijzen gebruikt worden. De standaard is van toepassing als het commando op de commandoregel wordt ingegeven zonder de optie . De daemon wordt gebruikt als continu een systeemlogboek bijgewerkt moet worden zodat het mogelijk is om gebeurtenissen in het verleden te bekijken. Zo zijn &os; en IPFILTER ingesteld om samen te werken. &os; heeft ingebouwde mogelijkheden om automatisch syslogs te roteren. Daarom is het beter om de uitvoer naar &man.syslogd.8; te schrijven dan naar een gewoon bestand. In de standaardversie van het bestand rc.conf is te zien dat de instelling ipmon_flags de waarde heeft: ipmon_flags="-Ds" # D = start als daemon # s = log naar syslog # v = log tcp window, ack, seq # n = vertaal IP & poort naar namen De voordelen van loggen zijn duidelijk. Het biedt de mogelijkheid om na het feit informatie na te zien als: welke pakketten heeft de firewall laten vallen, waar kwamen ze vandaan en waar gingen ze heen? Dit zijn allemaal voordelen als het gaat om uitvinden waar een aanvaller vandaan komt en wat deze heeft geprobeerd. Zelfs als loggen is ingeschakeld, logt IPF nog niets uit zichzelf. De beheerder van de firewall beslist welke regels in de regelverzameling iets weg moeten schrijven door het sleutelwoord log aan die regels toe te voegen. Gewoonlijk worden alleen deny regels gelogd. Het is heel normaal om als laatste regel een deny regel aan de set met regels toe te voegen waar het sleutelwoord log in staat. Zo krijgt een beheerder alle pakketten te zien waarop geen enkele regel van toepassing was. Loggen met IPMON Syslogd heeft een eigen methode om logboekgegevens te scheiden. Het maakt gebruik van speciale groepen die facility en level heten. &man.ipmon.8; in mode gebruikt security als facilitynaam. Alle door &man.ipmon.8; gelogde gegevens gaan naar security. De nu volgende levels kunnen gebruikt worden om de gelogde gegevens nog verder uit elkaar te trekken als dat gewenst is. LOG_INFO – pakketten gelogd met het sleutelwoord "log" als actie in plaats van pass of block. LOG_NOTICE – gelogde pakketten die ook zijn doorgelaten LOG_WARNING – gelogde pakketten die ook geblokkeerd zijn LOG_ERR – gelogde pakketten die een verkeerde opbouw hebben, "short" Om IPFILTER alle gelogde gegevens naar /var/log/ipfilter.log te laten schrijven, dient dat bestand vooraf te bestaan. Dat kan met het volgende commando: &prompt.root; touch /var/log/ipfilter.log De functionaliteit van &man.syslogd.8; wordt beheerd met instellingen in /etc/syslog.conf. syslog.conf biedt aanzienlijke flexibiliteit in hoe syslog omgaat met systeemberichten die door softwaretoepassingen als IPF worden gegeven. Zo kan de volgende instelling toegevoegd worden aan /etc/syslog.conf: security.* /var/log/ipfilter.log Het deel security.* betekent dat alle logberichten naar de aangegeven plaats geschreven moeten worden. Om de wijzigingen in /etc/syslog.conf actief te maken kan er opnieuw opgestart worden of is het mogelijk de daemon &man.syslogd.8; een schop te geven zodat /etc/syslog.conf opnieuw wordt ingelezen met /etc/rc.d/syslogd reload. Het PID (procesnummer) is te achterhalen door een overzicht van taken te tonen met ps –ax. Het PID is het nummer in de linker kolom voor de regel waarop syslog staat. Vaak wordt vergeten /etc/newsyslog.conf te wijzigen om het nieuw aangemaakte logboekbestand te laten roteren. De opmaak van gelogde berichten Berichten die door ipmon wordt gezonden bestaan uit velden die gescheiden worden door een spatie. Velden die in alle berichten zitten zijn: De datum waarop het pakket is ontvangen. De tijd waarop het pakket is ontvangen weergegeven als HH:MM:SS.F voor uren, minuten, seconden en fracties van een seconde. De fractie kan meerdere cijfers lang zijn. De naam van de interface waarop het pakket is ontvangen, bijvoorbeeld dc0. De groep en regelnummer van de regel, bijvoorbeeld @0:17. Deze kunnen ingezien worden met ipfstat -in. De acties: p voor doorgelaten (passed), b voor geblokkeerd (blocked), S voor een verkeerd pakket (short packet), n voor dat er geen enkele regel van toepassing was, L voor een logboekregel. De volgorde waarin deze acties getoond worden is: S, p, b, n, L. Een hoofdletter P of B betekent dat het pakket gelogd is vanwege een globale instelling, niet vanwege één regel in het bijzonder. De adressen. Dit zijn eigenlijk drie velden: het bronadres en poort gescheiden door een komma, het symbool -> en het bestemmingsadres en poort, bijvoorbeeld: 209.53.17.22,80 -> 198.73.220.17,1722. Achter PR staat de naam van het protocol of het nummer, bijvoorbeeld PR tcp. Achter len staan de lengte van de pakketkop en de totale lengte van het pakket, bijvoorbeeld len 20 40. Als het pakket een TCP pakket is, dan is er nog een veld dat begint met een verbindingsstreepje met daarachter letters die overeenkomen met vlaggen die ingeschakeld waren. In &man.ipmon.8; is een lijst met letters en bijbehorende vlaggen te vinden. Als het pakket een ICMP pakket is, dan worden aan het einde twee velden toegevoegd. Het eerste is altijd ICMP en het volgende het ICMP bericht en subbericht type, gescheiden door een slash, bijvoorbeeld ICMP 3/3 voor een poort niet bereikbaar bericht. Script met regels met substitutie bouwen Geoefende gebruikers van IPF maken een bestand dat de regels bevat en stellen dat op zo'n manier op dat het uitgevoerd kan worden als een script met substitutie. Het grote voordeel van deze werkwijze is dat er dan alleen de waarde geassocieerd met een symbolische naam gewijzigd hoeft te worden en dat als het script opnieuw wordt uitgevoerd, op alle plaatsen waar de variabele wordt gebruikt, de nieuwe waarde in de regels wordt opgenomen. Omdat het een script is, kan substitutie gebruik worden om vaak voorkomende waarden de definiëren zodat ze in meerdere regels vervangen kunnen worden. Dit wordt geïllustreerd in het onderstaande voorbeeld. De syntaxis die in het script wordt gebruikt is compatibel met de shells &man.sh.1;, &man.csh.1; en &man.tcsh.1;. Velden waarvoor substitutie van toepassing is worden vooraf gegaan door het dollarteken $. Definities worden niet vooraf gegaan door het voorvoegsel $. De waarden van een definitie moet omsloten worden door dubbele aanhalingstekens ("). Een set regels begint wellicht als volgt: ############## Begin IPF regels script ######################### oif="dc0" # naam van de uitgaande interface odns="192.0.2.11" # IP adres van DNS server ISP myip="192.0.2.7" # statische IP adres gekregen van ISP ks="keep state" fks="flags S keep state" # Er kan gekozen worden om dit script te gebruiken om een eigen # /etc/ipf.rules script te maken of dit script kan gebruikt worden # "as is" # # Haal bij één van deze regels het commentaarteken weg # en plaats hem bij de ander. # # 1) Deze kan gebruikt worden om /etc/ipf.rules te maken: #cat > /etc/ipf.rules << EOF # 2) Deze kan gebruikt worden om het script "as is" te starten: # Let op: er moet een lege regel zijn na het EOF teken. /sbin/ipf -Fa -f - << EOF # Verleen toegang tot de DNS van de ISP. pass out quick on $oif proto tcp from any to $odns port = 53 $fks pass out quick on $oif proto udp from any to $odns port = 53 $ks # Sta uitgaand verkeer voor niet beveiligd www verkeer toe pass out quick on $oif proto tcp from $myip to any port = 80 $fks # Sta uitgaand verkeer voor beveiligd www verkeer toe (https over TLS SSL) pass out quick on $oif proto tcp from $myip to any port = 443 $fks EOF ################## Einde IPF regels script ######################## Dat is alles. De regels zijn niet van belang in dit voorbeeld, maar tonen hoe substitutievelden worden gedefinieerd en hoe ze worden gebruikt. Als het bovenstaande voorbeeld de inhoud van /etc/ipf.rules.script was, dan konden deze regels herladen worden door het vanaf de commandoregel aan te roepen: &prompt.root; sh /etc/ipf.rules.script Er is wel een probleem met het gebruik van regels in combinatie met substitutie. IPF snapt het niet en kan deze scripts niet direct lezen. Dit script kan gebruikt worden op één van de volgende twee manieren: Haal het commentaarteken weg bij de regel die begint met cat en zet het commentaarteken bij de regel die begint met /sbin/ipf. Plaats ipfilter_enable="YES" in /etc/rc.conf zoals gewoonlijk en start het script eenmalig na elke wijziging om /etc/ipf.rules te maken of bij te werken. Schakel IPFILTER uit in de systeem opstart scripts door ipfilter_enable="NO" toe te voegen aan /etc/rc.conf (dit is de standaardwaarde). Voeg een script zoals de volgende toe aan de opstartmap /usr/local/etc/rc.d. Het script zou een duidelijke naam moeten hebben zoals ipf.loadrules.sh. De uitbreiding .sh is noodzakelijk. #!/bin/sh sh /etc/ipf.rules.script De permissies op dit script moeten zijn: lezen,schrijven en uitvoeren voor de gebruiker root. &prompt.root; chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh Als het systeem nu herstart, worden de regels via het script gestart. Sets van IPF regels Een set regels is een groep IPF-regels die is gemaakt om pakketten toe te staan of te blokkeren op basis van de eigenschappen van dat pakket. De bi-directionele uitwisseling van pakketten tussen hosts bestaat uit een gesprek dat een sessie heet. De set van firewallregels verwerkt zowel de pakketten die arriveren van het publieke Internet, als de pakketten die door het systeem zijn geproduceerd als een antwoord erop. Elke TCP/IP-dienst (i.e. telnet, www, mail, enz.) is vooraf gedefinieerd door een protocol en bevoorrechte (luister)poort. Pakketten bedoeld voor een speciale dienst beginnen bij het bronadres gebruik makend van een onbevoorrechte (hogere orde) poort en komen aan bij de specifieke dienstpoort op het bestemmingsadres. Alle bovengenoemde parameters (poorten en adressen) kunnen gebruikt worden als selectiecriteria om regels aan te maken die diensten zullen toestaan of blokkeren. IPFILTER volgorde regelverwerking IPF is oorspronkelijk geschreven met logica die regels verwerkte volgens het principe de laatst passende regel wint en gebruikte toen alleen staatloze regels. In de loop der tijd is IPF verbeterd en zijn de opties quick en keep state toegevoegd waarmee de logica van het verwerken van regels drastisch is gemoderniseerd. De instructies in dit hoofdstuk zijn gebaseerd op regels die gebruik maken van de optie quick en de stateful optie keep state. Dit is het raamwerk waarmee een set van inclusieve firewallregels wordt samengesteld. Werk bij het wijzigen van firewallregels zeer voorzichtig. Met sommige instellingen is een server niet meer bereikbaar. Om het veilig te spelen is het aan te raden de eerste instellingen vanaf het console te maken, in plaats van via ssh. Regelsyntaxis IPFILTER regelsyntaxis De regelsyntaxis die hier wordt besproken is versimpeld door alleen de moderne stateful regels en de eerste van toepassing zijnde regel wint te belichten. De complete regelsyntaxis is na te lezen in &man.ipf.8 Het karakter # wordt gebruikt om het begin van een opmerking te markeren en zowel op een eigen regel als achter een firewallregel staan. Lege regels worden genegeerd. Regels bevatten sleutelwoorden die in een bepaalde volgorde van links naar rechts op een regel horen te staan. Sleutelwoorden worden vet weergegeven. Sommige sleutelwoorden hebben subopties die zelf ook weer sleutelwoorden hebben die ook weer subopties kunnen hebben. Alle opties die hier direct onder staan, worden daaronder uitgebreid weergegeven en verderop in dit hoofdstuk in een aparte paragraaf behandeld. ACTIE IN/UIT OPTIES SELECTIE STATEFUL PROTO BRON_ADR,BEST_ADR OBJECT POORT_NUM TCP_VLAG STATEFUL ACTIE = block | pass IN/UIT = in | out OPTIES = log | quick | on interfacenaam SELECTIE = protowaarde | bron/bestemming IP | poort = nummer | flags flag–value PROTO = tcp/udp | udp | tcp | icmp BRON_ADR,BEST_ADR = all | from object to object OBJECT = IP adres | any POORT_NUM = poortnummer TCP_VLAG = S STATEFUL = keep state ACTIE De actie geeft aan wat er met het pakket gedaan moet worden als het van toepassing is op de rest van de filterregel. Iedere regel moet een actie hebben. De volgende acties zijn mogelijk: block geeft aan dat het pakket moet verdwijnen als de parameters van toepassing zijn het het pakket. pass geeft aan dat het pakket doorgelaten moet worden als de parameters van toepassing zijn op het pakket. IN/UIT Een verplicht onderdeel voor iedere filterregel waarin expliciet wordt aangegeven op welke zijde van de in/uit deze van toepassing is. Het volgende sleutelwoord moet in of out zijn en één van de twee moet gecodeerd worden, anders is de regel syntactisch onjuist. in betekent dat de regel van toepassing is op inkomende pakketten. out betekent dat de regel van toepassing is op inkomende pakketten. OPTIES Deze opties moeten in de volgorde waarin ze hier beschreven staan gebruikt worden. log geeft aan dat het pakket naar het ipl logboekbestand geschreven moeten worden (zoals verderop beschreven staat in de paragraaf Loggen) als de regel van toepassing is op het pakket. quick geeft aan dat als een regel van toepassing is, dat de laatste regel moet zijn die wordt gecontroleerd, waardoor er een pad wordt kortgesloten waardoor de volgende regels voor dat pakket niet meer gecontroleerd worden. Deze optie is voor de moderne regels eigenlijk verplicht. on geeft de interface aan die in de parameters meegenomen moet worden. De namen van interfaces kunnen getoond worden met &man.ifconfig.8;. Als deze optie wordt gebruikt, kan een regel alleen van toepassing zijn als het pakket door de aangegeven interface gaat in de richting die is aangegeven (in/out). Ook deze optie is verplicht voor de moderne regels. Als een pakket wordt gelogd, dan worden de koppen van het pakket weggeschreven naar het ipl pakketloggende pseudo–apparaat. Direct na het sleutelwoord log mogen de volgende opties gebruikt worden (in de aangegeven volgorde): body geeft aan dat de eerste 128 bytes van de inhoud van het pakket worden opgeslagen na de kop. first; als het sleutelwoord log samen met een optie keep state wordt gebruikt, wordt het aangeraden om deze optie ook te gebruiken zodat alleen het pakket dat als eerste in de sessie van toepassing was en niet ook alle pakketten die daarna in de sessie volgens keep state van toepassing zijn. SELECTIE De sleutelwoorden in deze paragraaf worden gebruikt om attributen van het pakket dat wordt geïnspecteerd te beschrijven om te bepalen of een regel wel of niet van toepassing is. Er is een sleutelwoord en er zijn subopties waarvan er één of meer gekozen moeten worden. De volgende attributen zijn beschikbaar voor het proces en moeten in de aangegeven volgorde worden gebruikt: PROTO proto is het sleutelwoord dat moet worden aangegeven samen met een van de sleutelwoorden uit de subopties. De waarde geeft een bepaald protocol aan dat van toepassing moet zijn. Ook deze optie is verplicht voor de moderne regels. tcp/udp, tcp, udp, icmp of ieder ander protocol dat in /etc/protocols staat wordt herkend en kan gebruikt worden. Het bijzondere protocolsleutelwoord tcp/udp kan gebruikt worden om zowel voor TCP- als UDP-pakketten van toepassing te laten zijn. Het is toegevoegd voor het gemak om vrijwel gelijke regels te voorkomen. BRON_ADR/BEST_ADR Het sleutelwoord all is in feite hetzelfde als from any to any zonder overige parameters. from bron to bestemming; de sleutelwoorden from en to worden gebruikt om te testen op IP-adressen. In regels moet zowel een bron- als bestemmings-IP-adres aangegeven worden. any is een bijzonder sleutelwoord dat van toepassing is op ieder IP-adres. Voorbeelden van gebruik: from any to any of from 0.0.0.0/0 to any of from any to 0.0.0.0/0 of from 0.0.0.0 to any of from any to 0.0.0.0. Het is vaak lastig om te komen tot een reeks IP-adressen die zich niet gemakkelijk laten uitdrukken met de gepunte numerieke vorm/ maskerlengte notatie. De port net-mgmt/ipcalc kan gebruikt worden om de berekeningen te vereenvoudigen. Aanvullende informatie is beschikbaar op de webpagina van het gereedschap: . POORT Als in een regel op een poort wordt gecontroleerd, voor bron- of bestemmingspoort of beiden, dan is dat alleen van toepassing op TCP- en UDP-pakketten. Bij het maken van poortvergelijkingen kunnen zowel de dienstnamen uit /etc/services als een uit een natuurlijk getal bestaand poortnummer ingesteld worden. Als de poort onderdeel is van het from object dan wordt het vergeleken met het poortnummer van de bron en als het onderdeel is van het to object, dan wordt het vergeleken met het poortnummer van de bestemming. Het gebruik van het to object is in de moderne regels verplicht en neemt de vorm aan van from any to any port = 80. Enkelvoudige poortvergelijkingen kunnen op verschillende manieren gedaan worden met een aantal verschillende operatoren. Er kunnen ook reeksen van poorten ingesteld worden. poort "=" | "!=" | "<" | ">" | "<=" | ">=" | "eq" | "ne" | "lt" | "gt" | "le" | "ge" Reeksen van poorten worden met de volgende optie aangegeven: poort <> | >< De volgende twee parameters die betrekking hebben op bron en bestemming, zijn verplicht in de moderne regels. <acronym>TCP</acronym>_VLAG Vlaggen zijn alleen beschikbaar voor het filteren van TCP. De letters staan voor de mogelijke vlaggen die bekeken kunnen worden in de kop van een TCP-pakket. In de moderne regels wordt de optie flags S gebruikt om het verzoek tot het starten van een TCP sessie. STATEFUL keep state geeft aan dat in een regel met pass voor alle pakketten die van toepassing zijn stateful gefilterd moet worden. Deze optie is voor moderne regels verplicht. Stateful filteren IPFILTER stateful filteren Met stateful filteren wordt verkeer benaderd als een uitwisseling van pakketten tussen twee kanten die een sessie zijn. Als het is ingeschakeld, dan maakt het mechanisme dynamisch interne regels voor pakketten die in de sessie horen te volgen. Het kan bekijken of de karakteristieken van de sessie tussen verzender en ontvanger de juiste procedure volgen. Alle pakketten die niet passen in de sessie, worden automatisch geblokkeerd. keep state staat ook ICMP-pakketten toe die gerelateerd zijn aan een TCP- of UDP-sessie. Dus als er een ICMP-type 3 code 4 komt in antwoord op websurfen, dat wordt toegestaan van binnen naar buiten door een keep state regel, dan wordt dat toegelaten. Pakketten waarvan IPF zeker is dat ze onderdeel zijn van de sessie worden toegelaten, zelfs als ze van een ander protocol zijn. Wat er gebeurt: pakketten die naar buiten gaan op de interface die met Internet is verbonden worden eerst vergeleken met de dynamische staattabel. Als een pakket voldoet aan de verwachting van het volgende pakket in de sessie, dan mag het de firewall verlaten en wordt de toestand van de sessie in de dynamische toestandstabel bijgewerkt. Pakketten die niet bij een reeds actieve sessie horen, worden tegen de uitgaande regelverzameling gecontroleerd. Pakketten die binnenkomen op de interface die met Internet is verbonden worden eerst vergeleken met de dynamische staattabel. Als een pakket voldoet aan de verwachting van het volgende pakket in de sessie, dan mag het de firewall verlaten en wordt de toestand van de sessie in de dynamische toestandstabel bijgewerkt. Pakketten die niet bij een reeds actieve sessie horen, worden vergeleken met de regelverzameling voor binnenkomend verkeer. Als de sessie wordt beëindigd wordt het uit de dynamische staattabel verwijderd. Met stateful filteren is het mogelijk om de focus te leggen op het blokkeren of toestaan van nieuwe sessies. Als een nieuwe sessie tot stand mag komen, dan worden alle volgende pakketten automatisch doorgelaten en al het vervalste verkeer wordt automatisch tegengehouden. Als een nieuwe sessie wordt geweigerd, dan wordt geen enkel pakket doorgelaten. Met stateful filteren zijn er uitgebreide mogelijkheden voor onderzoek om bescherming te bieden tegen de veelheid aan aanvallen die tegenwoordig door aanvallers worden uitgevoerd. Voorbeeld van inclusieve regels De onderstaande regels zijn een voorbeeld van hoe een erg veilige inclusieve firewall opgezet kan worden. Een inclusieve firewall staat alleen diensten toe die passen bij de pass-regels en blokkeert al het overige verkeer. Firewalls die bedoeld zijn om andere machines te beschermen, ook wel netwerk-firewalls genoemd, dienen tenminste twee interfaces te hebben, die over het algemeen zijn ingesteld om de ene kant te vertrouwen (het LAN) maar niet de andere (het publieke Internet). Ook kan een firewall worden ingesteld om alleen het systeem te beschermen waarop het draait—dit wordt een host-gebaseerde firewall genoemd, en is in het bijzonder geschikt voor servers op een onvertrouwd netwerk. Alle &unix; systemen en dus ook &os; zijn zo ontworpen dat ze voor interne communicatie de interface lo0 en IP adres 127.0.0.1 gebruiken. De firewall moet dit interne verkeer gewoon doorgang laten vinden. Voor de interface die is verbonden met het publieke Internet worden regels gemaakt waarmee de toegang voor uitgaande en binnenkomende verbindingen worden geautoriseerd en beheerst. Dit kan de PPP-interface tun0 zijn of de netwerkkaart die is verbonden met een xDSL- of kabelmodem. In gevallen dat er één of meer netwerkkaarten zijn aangesloten op private netwerksegmenten kunnen er regels op de firewall nodig zijn om pakketten die van die LAN-interfaces afkomen vrije doorgang te geven naar elkaar en/of naar buiten (het Internet). De regels worden opgedeeld in drie onderdelen: eerst de vertrouwde interfaces, dan het publieke uitgaande interface en als laatste het onvertrouwde publieke binnenkomende interfaces. In iedere sectie moeten zo staan dat de regels die het meest gebruikt worden vóór de regels die minder vaak gebruikt worden staan. De laatste regel van een onderdeel geeft aan dat al het overige verkeer op die interface in die richting geblokkeerd en gelogd moet worden. In het onderdeel Uitgaand staan alleen regels met pass die parameters bevatten om uniek individuele diensten identificeren die het publieke Internet mogen benaderen. Bij al die regels staan de opties quick, on, proto, port en keep state aan. De regels met proto tcp maken ook gebruik van de optie flag om te bekijken of het een pakket betreft voor het opzetten van een sessie om de stateful functionaliteit aan te sturen. In het onderdeel Inkomend staan eerst alle regels voor het blokkeren van ongewenste pakketten, om twee redenen. Als eerste kan het zo zijn dat kwaadaardige pakketten gedeeltelijk overeenkomen met legitiem verkeer. Deze pakketten moeten worden weggegooid in plaats van binnengelaten te worden, gebaseerd op hun gedeeltelijke match met de allow-regels. De tweede reden is dat bekende en oninteressante verwerpingen stil geblokkeerd kunnen worden in plaats van gevangen en gelogd te worden door de laatste regels in de sectie. De laatste regel in elke sectie blokkeert en logt alle pakketten en kan worden gebruikt voor het wettelijke bewijs nodig om degenen die uw systeem aanvallen aan te klagen. Waar ook gezorgd voor moet worden is dat al het verkeer dat wordt geweigerd geen antwoord verstuurd. Ongeldige pakketten dienen gewoon te verdwijnen. Zo weet een aanvaller niet of een pakket het doelsysteem wel heeft bereikt. Zo kan een aanvaller geen informatie verzamelen over een systeem: hoe minder informatie er over een systeem beschikbaar is, hoe meer tijd iemand erin moet steken voordat er iets slechts gedaan kan worden. Regels die een optie log first bevatten, zullen alleen de eerste keer dat de gebeurtenis voorkomt de gebeurtenis loggen. Deze optie is opgenomen in de voorbeeldregel nmap OS fingerpint. Het gereedschap security/nmap wordt vaak door aanvallers gebruikt om het besturingssysteem van uw server proberen te achterhalen. We raden aan om telkens als er logmeldingen komen van een regel met log first het commando ipfstat -hio uit te voeren om te bekijken hoe vaak de regel van toepassing is geweest. Een groot aantal overeenkomsten geeft gewoonlijk aan dat de firewall overspoeld wordt, m.a.w. aangevallen wordt. Het bestand /etc/services kan gebruikt worden om onbekende poortnummers op te zoeken. Ook kan worden bezocht en het poortnummer worden opgezocht om het doel van een bepaalde poort uit te vinden. Op de volgende link worden poortnummers van Trojans beschreven: . De onderstaande set regels is een complete en erg veilige inclusieve set met regels voor een firewall die is getest op productiesystemen. Deze set met regels is eenvoudig aan te passen voor uw eigen systeem. Maak gewoon commentaar van elke pass-regel voor een dienst die niet gewenst is. Logberichten die niet gewenst zijn, zijn uit te sluiten door een block-regel toe te voegen in het begin van het onderdeel Inkomend. Voor de onderstaande regels dient de dc0 interfacenaam in iedere regel vervangen te worden door de echte interfacenaam van de netwerkkaart in het systeem die met het publieke Internet is verbonden. Voor gebruikers van PPP zou dat tun0 zijn. Dit zou de inhoud van /etc/ipf.rules kunnen zijn: ################################################################# # Geen beperkingen op de interface aan de LAN kant. # Niet nodig als er geen LAN is. ################################################################ #pass out quick on xl0 all #pass in quick on xl0 all ################################################################# # Geen beperkingen op de loopback interface ################################################################# pass in quick on lo0 all pass out quick on lo0 all ################################################################# # Interface aan het publieke Internet (onderdeel Uitgaand). # Inspecteer verzoeken om een sessie te starten van achter de # firewall op het private netwerk of vanaf deze gateway-server # naar het publieke Internet. ################################################################# # Geef toegang tot de DNS server van de ISP. # xxx moet het IP adres van de DNS van de ISP zijn. # Dupliceer deze regels als een ISP meerdere DNS servers heeft. # Haal het IP adres evt. uit /etc/resolv.conf. pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state pass out quick on dc0 proto udp from any to xxx port = 53 keep state # Geef toegang tot de DHCP server van de ISP voor kabel- en # xDSL-netwerken. Deze regel is niet nodig als gebruik gemaakt worden # van PPP naar het publieke Internet. In dat geval kan de hele groep # verwijderd worden. Gebruik de volgende regel en controleer het # logboek voor het IP adres. Wijzig dan het IP adres in de regel # commentaar hieronder en verwijder de eerste regel. pass out log quick on dc0 proto udp from any to any port = 67 keep state #pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state # Sta niet beveiligd www verkeer toe. pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state # Sta beveiligd www verkeer over TLS SSL toe. pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state # Sta het verzenden en ontvangen van e-mail toe. pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state # Sta Time toe. pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state # Sta uitgaand NNTP nieuws toe. pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state # Sta uitgaande lokale niet beveiligde FTP (ook van LAN-gebruikers) toe # (zowel passieve als actieve modes). Deze functie maakt gebruik van # de in IP-NAT ingebouwde FTP-proxy die in het bestand met NAT-regels # staat om dit in één regel te laten werken. Als er met # pkg_add pakketten toegevoegd moeten kunnen worden op een systeem, dan # is deze regel nodig. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state # Sta uitgaande SSH/SFTP/SCP toe (vervangingen van telnet/rlogin/FTP) # Deze functie maakt gebruik van SSH (secure shell) pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state # Sta uitgaande niet beveiligde telnet toe. pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state # Sta de &os; CVSUP-functie toe. pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state # Sta ping toe naar het publieke Internet. pass out quick on dc0 proto icmp from any to any icmp–type 8 keep state # Sta whois toe vanaf het LAN naar het publieke Internet. pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state # Blokkeer en log het eerste voorkomen van al het andere dat probeert # buiten te komen. Deze regel implementeert de standaard-blokkade. block out log first quick on dc0 all ################################################################# # Interface aan het publieke Internet (onderdeel Inkomend). # Inspecteert pakketten die van het publieke Internet komen # met als bestemming deze gateway-server of het private netwerk. ################################################################# # Blokkeer al het verkeer voor niet–routeerbare of gereserveerde # adresreeksen. block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918 privaat IP block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918 privaat IP block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918 privaat IP block in quick on dc0 from 127.0.0.0/8 to any #loopback block in quick on dc0 from 0.0.0.0/8 to any #loopback block in quick on dc0 from 169.254.0.0/16 to any #DHCP auto–config block in quick on dc0 from 192.0.2.0/24 to any #gereserveerd voor documentatie block in quick on dc0 from 204.152.64.0/23 to any #Sun cluster interconnect block in quick on dc0 from 224.0.0.0/3 to any #Klasse D & E multicast ##### Blokkeer wat vervelende dingen ############ # die niet in de logboeken moeten komen. # Blokkeer fragmenten. block in quick on dc0 all with frags # Block korte TCP pakketten. block in quick on dc0 proto tcp all with short # Blokkeer source gerouteerde pakketten. block in quick on dc0 all with opt lsrr block in quick on dc0 all with opt ssrr # Blokkeer pogingen voor nmap OS fingerprint. # Blokkeer het eerste voorkomen ervan voor de IP-adressen block in log first quick on dc0 proto tcp from any to any flags FUP # Blokkeer alles met speciale opties. block in quick on dc0 all with ipopts # Blokkeer publieke pings. block in quick on dc0 proto icmp all icmp–type 8 # Blokkeer ident. block in quick on dc0 proto tcp from any to any port = 113 # Blokkeer alle Netbios diensten. 137=naam, 138=datagram, 139=sessie. # Netbios is de &windows; bestandsdeeldienst. # Blokkeer &windows; hosts2 name server verzoeken 81. block in log first quick on dc0 proto tcp/udp from any to any port = 137 block in log first quick on dc0 proto tcp/udp from any to any port = 138 block in log first quick on dc0 proto tcp/udp from any to any port = 139 block in log first quick on dc0 proto tcp/udp from any to any port = 81 # Sta inkomend verkeer toe van de DHCP server van de ISP. Deze regel # moet het IP adres van de DHCP server van de ISP bevatten omdat die # de enige toegestane bron van dit type pakketten moet zijn. Alleen # van belang voor kabel en xDSL instellingen. Deze regel is niet nodig # voor PPP verbindingen naar het publieke Internet. Dit is hetzelfde # IP adres dat in het Uitgaande onderdeel is opgezocht. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state # Sta inkomend webverkeer toe omdat er een Apache server draait. pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state # Sta niet beveiligde telnet sessie toe vanaf het publieke Internet. # Dit heeft het label niet veilig omdat gebruikersnaam en # wachtwoord als platte tekst over Internet gaan. Als er geen telnet # server draait, hoeft deze regel niet actief te zijn. #pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state # Sta beveiligde FTP, telnet en SCP toe vanaf Internet. # Deze functie gebruikt SSH (secure shell). pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state # Blokkeer en log het eerste voorkomen van al het andere dat probeert # binnen te komen. Het loggen van alleen het eerste voorkomen stopt # een ontzegging van dienst aanval die gericht is op het laten # vollopen van de partitie waarop de logboeken staan. Deze regel implementeert # de standaard blokkade. block in log first quick on dc0 all ################### Einde van de regels ################################### <acronym>NAT</acronym> NAT IP masquerading NAT network address translation NAT netwerkadres vertaling NAT NAT staat voor Network Address Translation (netwerkadres vertaling). In &linux; heet dit IP Masquerading. Een van de vele mogelijkheden die IPF NAT kan bieden is het delen van één IP adres op het publieke Internet met een LAN achter een firewall. De vraag zou kunnen rijzen waarom iemand dat zou willen. ISP's wijzen normaliter namelijk dynamisch een IP adres toe aan hun niet-commerciële gebruikers. Dynamisch betekent hier dat het IP-adres iedere dat er wordt ingebeld of dat het kabel- of xDSL-modem uit- en aangeschakeld wordt anders kan zijn. Dit dynamische IP-adres wordt gebruikt om uw systeem op het publieke Internet te identificeren. Stel dat er vijf PC's in een huis staan en iedere computer in dat huis heeft toegang tot Internet nodig. Dan zouden er bij een ISP vijf individuele accounts moeten zijn en vijf telefoonlijnen om dat te realiseren. Met NAT is er maar één account bij een ISP nodig. De andere vier PC's moeten met kabels op een switch worden aangesloten waarop ook een &os; systeem is aangesloten dat binnen uw LAN als gateway gaat opereren. NAT zal automatisch de private LAN IP adressen van alle PC's vertalen naar een enkel publiek IP-adres als de pakketten de firewall naar het Internet verlaten. Er is een speciale reeks van IP-adressen gereserveerd voor NAT op private LANs. Volgens RFC 1918 kunnen de volgende reeksen IP-adressen gebruikt worden op private netwerken die nooit direct op het publieke Internet gerouteerd worden. Eerste IP – Laatste IP 10.0.0.0 – 10.255.255.255 172.16.0.0 – 172.31.255.255 192.168.0.0 – 192.168.255.255 IP<acronym>NAT</acronym> NAT en IPFILTER ipnat NAT regels worden geladen met ipnat. De NAT regels worden vaak opgeslagen in /etc/ipnat.rules . Meer details staan in &man.ipnat.1;. Bij het maken van wijzigingen aan de NAT-regels nadat NAT gestart is, wordt aangeraden de wijziging aan het bestand met regels te maken en daarna het commando ipnat te gebruiken om alle actieve NAT-regels te wissen. Daarna kunnen de regels uit het bestand weer als volgt geladen worden: &prompt.root; ipnat -CF -f /etc/ipnat.rules Gebruiksgegevens over NAT kunnen getoond worden met: &prompt.root; ipnat -s De huidige inhoud van de NAT tabellen kan getoond worden met: &prompt.root; ipnat -l Met het volgende commando kan de uitgebreide rapportage worden ingeschakeld en dan wordt informatie over het verwerken van verkeer en de actieve regels getoond: &prompt.root; ipnat –v IP<acronym>NAT</acronym> regels NAT regels zijn erg flexibel en er kunnen veel dingen mee gedaan worden om behoeften van bedrijven en thuisgebruikers in te vullen. De syntaxis van de regels die hier wordt toegelicht is vereenvoudigd om te passen bij een niet-commerciële omgeving. De complete syntaxis is na te lezen in &man.ipnat.5;. De syntaxis voor een NAT regel ziet er ongeveer als volgt uit: map IF LAN_IP_REEKS -> PUBLIEK_ADRES De regel begint met het sleutelwoord map. IF dient vervangen te worden door de aanduiding van de externe interface. LAN_IP_REEKS is de reeks die clients op een LAN gebruiken, meestal iets van 192.168.1.0/24. PUBLIEK_ADRES kan het publieke IP adres zijn of een speciaal sleutelwoord 0.32, wat betekent dat het IP adres van IF gebruikt moet worden. Hoe <acronym>NAT</acronym> werkt Een pakket komt vanaf het LAN aan bij de firewall en heeft een publieke bestemming. Het wordt verwerkt door de filterregels voor inkomend verkeer en daarna krijgt NAT de kans zijn regels op het pakket toe te passen. De regels worden van boven naar beneden toegepast en de eerste regel die van toepassing is wint. NAT controleert voor alle regels het pakket op interfacenaam en bron IP adres. Als de interfacenaam van een pakket past bij een NAT regel dan wordt het bron IP adres van dat pakket gecontroleerd, dat is dus een IP adres op het private LAN, om te bekijken of het valt in de reeks die is opgegeven aan de linkerkant van een NAT regel. Als ook dat klopt, dan wordt het bron IP adres van het pakket vervangen (rewritten) door een publiek IP adres dat verkregen kan zijn met het sleutelwoord 0.32. NAT werkt dan zijn interne NAT tabel bij, zodat als er een pakket uit die sessie terugkomt van het publieke Internet, dat pakket weer gepast kan worden bij het originele private IP adres en door de firewallregels gefilterd kan worden om daarna, als dat mag, naar een client gestuurd te worden. IP<acronym>NAT</acronym> inschakelen Voor IPNAT zijn de onderstaande instellingen in /etc/rc.conf beschikbaar. Om verkeer tussen interfaces te kunnen routeren: gateway_enable="YES" Om IPNAT automatisch te starten: ipnat_enable="YES" Om aan te geven waar de IPNAT regels staan: ipnat_rules="/etc/ipnat.rules" <acronym>NAT</acronym> voor een groot LAN Voor netwerken met grote aantallen PC's of netwerken met meerdere LAN's kan het een probleem worden om al die private IP adressen met één enkel publiek IP adres te vervangen, omdat vaak dezelfde poortnummers gebruikt worden. Er zijn twee manieren om dit probleem op te lossen. Aangeven welke poorten te gebruiken Een normale regel voor NAT ziet er als volgt uit: map dc0 192.168.1.0/24 -> 0.32 Met de bovenstaande regel blijft de bronpoort ongewijzigd als het pakket door IPNAT gaat. Door gebruik te maken van het sleutelwoord portmap kan IPNAT ingesteld worden om alleen bronpoorten in de aangegeven reeks te gebruiken. Zo stelt de onderstaande regel in dat IPNAT de bronpoort aanpast naar een poortnummer dat in de aangegeven reeks valt: map dc0 192.168.1.0/24 -> 0.32 portmap tcp/udp 20000:60000 Het kan nog eenvoudiger door gebruik te maken van het sleutelwoord auto zodat IPNAT zelf bepaalt welke poorten gebruikt kunnen worden: map dc0 192.168.1.0/24 -> 0.32 portmap tcp/udp auto Meerdere publieke adressen gebruiken In grote netwerken komt er een moment waarop er gewoon te veel adressen zijn om te bedienen met één IP adres. Als er een blok van publiekelijke IP adressen beschikbaar is, dan kunnen deze adressen gebruikt worden in een poel, welke door IPNAT gebruikt kan worden om één van de adressen te gebruiken als uitgaand adres. Bijvoorbeeld om alle pakketten te verstoppen achter één een enkel IP adres: map dc0 192.168.1.0/24 -> 204.134.75.1 Een reeks van publiekelijke IP adressen kan gespecificeerd worden met een netwerkmasker: map dc0 192.168.1.0/24 -> 204.134.75.1–10 of door gebruik van de CIDR notatie: map dc0 192.168.1.0/24 -> 204.134.75.0/24 Poorten omleiden Het is erg gebruikelijk om een webserver, mailserver, database server en DNS server op verschillende computers op een LAN te draaien. Het uitgaande verkeer van die servers kan dan met NAT afgehandeld worden, maar er moet ook ingesteld worden dat inkomend verkeer bij de juiste computer terecht komt. IPNAT gebruikt daarvoor de opties in NAT waarmee verkeer omgeleid kan worden. Als bijvoorbeeld een webserver op het LAN-adres 10.0.10.25 draait en het enkele publieke IP adres zou 20.20.20.5 zijn, dan zou de regel er als volgt uit zien: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 of: rdr dc0 0.0.0.0/32 port 80 -> 10.0.10.25 port 80 Voor een DNS server op een LAN die ook vanuit Internet bereikbaar met zijn en die draait op 10.0.10.33 zou de regel er als volgt uit zien: rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp FTP en <acronym>NAT</acronym> FTP is dinosaurus uit het tijdperk van voor Internet was zoals het nu is, toen onderzoeksinstellingen met elkaar verbonden waren via huurlijnen en FTP de aangewezen methode was om bestanden met elkaar uit te wisselen. Maar bij het gebruik van FTP worden gebruikersnaam en wachtwoord als platte tekst verzonden en het protocol is nooit aangepast. FTP is er in twee smaken: actief en passief. Het verschil zit 'm in hoe het datakanaal wordt opgezet. De passieve variant is veiliger voor een gebruiker omdat bij deze variant beide communicatiekanalen door de cliënt zelf worden opgezet. Op de volgende pagina zijn details over FTP na te lezen: . IP<acronym>NAT</acronym>-regels IPNAT heeft een een speciale FTP-proxy ingebouwd die kan worden ingeschakeld met een NAT-map-regel. Die kan al het uitgaande verkeer monitoren wat betreft opstartverzoeken voor sessies voor actieve en passieve FTP en dynamisch tijdelijke filterregels maken die alleen het poortnummer dat echt in gebruik is voor het datakanaal doorlaten. Hiermee wordt een veiligheidsrisico dat normaal gepaard gaat met FTP, namelijk het toestaan van grote reeksen hoge poortnummers, weggenomen. De volgende regel handelt al het FTP verkeer van het LAN af: map dc0 10.0.10.0/29 -> 0/32 proxy port 21 ftp/tcp De regel hieronder handelt het FTP verkeer van de gateway zelf af: map dc0 0.0.0.0/0 -> 0/32 proxy port 21 ftp/tcp Deze laatste regel handelt al het niet–FTP verkeer voor het LAN af: map dc0 10.0.10.0/29 -> 0/32 De FTP-afbeeldregel hoort voor de normale regels te staan. Alle pakketten worden als eerste vergeleken met de eerste regel en zo verder. Eerst wordt gekeken over de interfacenaam overeenkomt, daarna het bron IP adres van het LAN en dan of het een FTP pakket is. Als dat allemaal klopt, dan maakt de speciale FTP proxy een tijdelijke filterregel die de pakketten uit de FTP sessie naar binnen en buiten doorlaat en ook NAT toepast op de FTP pakketten. Alle pakketten van het LAN die niet van het protocoltype FTP zijn en dus niet bij de eerste regel passen, worden tegen de derde regel gehouden die van toepassing is vanwege de interface en bron IP adres, zodat er dan NAT op toegepast wordt. IP<acronym>NAT</acronym> FTP filterregels Als de NAT-FTP-proxy wordt gebruikt is er maar één filterregel voor FTP nodig. Zonder de FTP-proxy zouden er drie regels nodig zijn: # Sta LAN client toe te FTP-en naar Internet # Actieve en passieve modes pass out quick on rl0 proto tcp from any to any port = 21 flags S keep state # Sta opzetten van het datakanaal voor passieve mode toe voor hoge poorten pass out quick on rl0 proto tcp from any to any port > 1024 flags S keep state # Laat het datakanaal van de FTP server binnen voor actieve mode pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state IPFW firewall IPFW IPFIREWALL (IPFW) is een firewall die binnen &os; wordt ontwikkeld en onderhouden door vrijwillige leden van de staf. Het maakt gebruik van verouderde staatloze regels en een verouderde techniek om te realiseren wat eenvoudige stateful logica zou kunnen heten. De set voorbeeldregels van IPFW (die in /etc/rc.firewall en /etc/rc.firewall6 staan) uit de standaard &os;-installatie is redelijk eenvoudig en niet voorbereid om zonder wijzigingen gebruikt te worden. Het voorbeeld maakt geen gebruik van stateful filteren, wat een voordeel is in de meeste situaties. Daarom worden deze regels niet als basis gebruikt in dit onderdeel. De staatloze syntaxis van IPFW is krachtig door de technisch geavanceerde mogelijkheden van de regelsyntaxis die de kennis van de gemiddelde gebruiker van firewalls ver overstijgt. IPFW is gericht op de professionele gebruiker of de gevorderde thuisgebruiker die hoge eisen stelt aan de wijze waarop er met pakketten wordt omgegaan. Voordat de kracht van de IPFW regels echt ingezet kan worden, moet de gebruiker veel weten over de verschillende protocollen en de wijze waarop pakketten in elkaar zitten. Het tot op dat niveau behandelen van stof valt buiten de doelstellingen van dit Handboek. IPFW bestaat uit zeven componenten: de verwerkingseenheid voor de firewallregels, verantwoording, loggen, regels met divert (omleiden) waarmee NAT gebruikt kan worden en de speciale gevorderde mogelijkheden voor bandbreedtebeheer met DUMMYNET, de fwd rule forward-mogelijkheid, de bridge-mogelijkheden en de ipstealth-mogelijkheden. IPFW ondersteunt zowel IPv4 als IPv6. IPFW inschakelen IPFW inschakelen IPFW zit bij de basisinstallatie van &os; als een losse tijdens runtime laadbare module. Het systeem laadt de kernelmodule dynamisch als in rc.conf de regel firewall_enable="YES" staat. IPFW hoeft niet in de &os; kernel gecompileerd te worden, tenzij het nodig is dat NAT beschikbaar is. Na het rebooten van een systeem met firewall_enable="YES" in rc.conf is het volgende bericht op het scherm te zien tijdens het booten: ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled In de laadbare module zit de mogelijkheid om te loggen gecompileerd. Er is een knop in /etc/sysctl.conf om loggen aan te zetten en de uitgebreide loglimiet in te stellen. Door deze regels toe te voegen, staat loggen aan bij toekomstige herstarts: net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=5 Kernelopties kernelopties IPFIREWALL kernelopties IPFIREWALL_VERBOSE kernelopties IPFIREWALL_VERBOSE_LIMIT IPFW kernelopties Het is niet verplicht om IPFW in te schakelen door het mee te compileren in de &os; kernel, tenzij de NAT functionaliteit beschikbaar moet zijn. Dit wordt alleen beschreven als achtergrondinformatie. options IPFIREWALL Met IPFIREWALL wordt IPFW ingeschakeld als deel van de kernel. options IPFIREWALL_VERBOSE Met IPFIREWALL_VERBOSE wordt het loggen van pakketten die worden verwerkt met IPFW mogelijk die het sleutelwoord log in een regel hebben staan. options IPFIREWALL_VERBOSE_LIMIT=5 Limiteert het aantal pakketten dat per regel wordt gelogd via &man.syslogd.8;. Deze optie kan gebruikt worden in vijandige omgevingen waar de activiteit van een firewall gelogd moet worden. Hierdoor kan een mogelijke ontzegging van dienst aanval door het vol laten lopen van syslog voorkomen worden. kernelopties IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_DEFAULT_TO_ACCEPT Met IPFIREWALL_DEFAULT_TO_ACCEPT wordt standaard alles door de firewall doorgelaten. Dit wordt aangeraden als iemand voor het eerst een firewall opzet. kernelopties IPDIVERT options IPDIVERT Met IPDIVERT wordt de NAT functionaliteit ingeschakeld. De firewall zal alle binnenkomende en uitgaande pakketten blokkeren als de kerneloptie IPFIREWALL_DEFAULT_TO_ACCEPT of een regel om deze verbindingen expliciet toe te staan ontbreekt. <filename>/etc/rc.conf</filename> opties Start de firewall: firewall_enable="YES" Om één van de standaard firewall types te selecteren die geleverd wordt door &os; lees /etc/rc.firewall, maak een selectie en plaats de volgende regel: firewall_type="open" Beschikbare waardes voor deze instelling zijn: open — laat al het verkeer door. client — beschermt alleen deze machine. simple — beschermt het hele netwerk. closed — blokkeert alle IP-verkeer, behalve voor lokaal verkeer. UNKNOWN — voorkomt het laden de firewall-regels. bestandsnaam — absoluut pad naar een bestand dat firewall-regels bevat. Het is mogelijk om twee verschillende manieren te gebruiken voor speciaal gemaakte regels voor de ipfw firewall. één daarvan is door het zetten van de firewall_type variabele naar een absoluut pad van een bestand, welke firewall-regels bevat, zonder enige specifieke opties voor &man.ipfw.8;. Het volgende is een eenvoudig voorbeeld van een bestand met regelverzamelingen dat al het inkomend en uitgaand verkeer blokkeert: add deny in add deny out Aan de andere kant is het mogelijk om de variabele firewall_script in te stellen op een absoluut pad van een uitvoerbaar script, welke inclusief ipfw commando's uitgevoerd wordt tijdens het opstarten van het systeem. Een geldig script met regels dat gelijkwaardig is aan het bestand met regels hierboven, zou het volgende zijn: #!/bin/sh ipfw -q flush ipfw add deny in ipfw add deny out Als firewall_type is gezet naar client of simple moeten de standaard regels die gevonden kunnen worden in /etc/rc.firewall gecontroleerd worden om te zien of deze configuratie voldoet voor de machine. Let ook op dat alle voorbeelden die gebruikt zijn in dit hoofdstuk ervan uitgaan dat de firewall_script variabele gezet is naar /etc/ipfw.rules. Om loggen in te schakelen: firewall_logging="YES" Het enige dat de variabele firewall_logging doet is de sysctl variabele net.inet.ip.fw.verbose op de waarde 1 zetten (zie ). Er is geen variabele in rc.conf om logboeklimieten in te stellen, maar dat kan ingesteld worden via een sysctl variabele, handmatig of via het bestand /etc/sysctl.conf: net.inet.ip.fw.verbose_limit=5 Als de machine in kwestie een gateway is, dus Network Address Translation (NAT) diensten levert via &man.natd.8;, dan staat in meer informatie over de benodigde instellingen voor /etc/rc.conf. Het commando <command>IPFW</command> ipfw Gewoonlijk wordt ipfw gebruikt om met de hand enkelvoudige regels toe te voegen of te verwijderen als IPFW actief is. Het probleem met deze methode is dat, als het systeem wordt uitgezet alle regels die gewijzigd of verwijderd zijn verloren gaan. Door alle regels in een bestand op te nemen dat bij het booten wordt geladen of door het bestand waarin de wijzigingen zijn gemaakt als een machine draait te laden bestaat die probleem niet. Met ipfw kunnen de actieve regels van de firewall op het scherm getoond worden. De verantwoordingsmogelijkeden van &man.ipfw.8; maken dynamisch tellers aan voor iedere regel en houden die bij voor alle pakketten die van toepassing zijn op die regel. Tijdens het testen van een regel is het afbeelden van de regel met zijn teller een van de manieren om te bepalen of de regel werkt. Om alle regels in volgorde te tonen: &prompt.root; ipfw list Om alle regels te tonen met de tijd waarop deze voor het laatst van toepassing was: &prompt.root; ipfw –t list Het volgende commando kan gebruikt worden om de verantwoordingsinformatie, pakkettellers en de regel zelf te tonen. De eerste kolom is het regelnummer met daarachter het aantal keren dat de regel van toepassing was voor inkomend verkeer, gevolgd door het aantal keren dat de regel van toepassing was voor uitgaand verkeer. Als laatste wordt de regel zelf getoond: &prompt.root; ipfw –a list Ook kunnen onder de statische regels de dynamische regels getoond worden: &prompt.root; ipfw –d list En de dynamische regels die verlopen zijn: &prompt.root; ipfw –d –e list De tellers op nul gesteld worden: &prompt.root; ipfw zero Alleen de tellers voor regel met nummer NUM op nul stellen: &prompt.root; ipfw zero NUM Sets van IPFW regels Een verzameling regels is een groep IPFW-regels die is gemaakt om pakketten toe te staan of te blokkeren op basis van de inhoud van dat pakket. De bi-directionele uitwisseling van pakketten tussen hosts bestaat uit een gesprek dat een sessie heet. De verzameling van firewallregels beoordeelt zowel de pakketten die aankomen van de host op het publieke Internet als de pakketten die op het systeem ontstaan als antwoord daarop. Iedere TCP/IP-dienst als telnet, www, mail, etc, heeft zijn eigen protocol en bevoorrechte (luister)poort. Pakketten bestemd voor een specifieke poort verlaten het bronadres via een onbevoorrechte (hogere) poort en doelen op de specifieke dienstpoort op het bestemmingsadres. Alle bovenstaande parameters (poorten en adressen) kunnen gebruikt worden als selectiecriteria om regels aan te maken die diensten doorlaten of blokkeren. IPFW volgorde regelverwerking Als een pakket de firewall binnenkomt wordt het vergeleken met de eerste regel in de set regels en zo gaat dat voor iedere regel vanaf boven tot beneden. Als een regel van toepassing is op een pakket, dan wordt het actieveld van de regel uitgevoerd. Dit wordt de de eerst passende regel wint zoekmethode genoemd. Als een pakket bij geen enkele regel past, dan wordt de verplichte standaardregel 65535 van IPFW toegepast, die alle pakketten weigert zonder een antwoord terug te sturen naar de verzender. Het zoeken gaat door na regels met count, skipto en tee. De instructies in dit onderdeel zijn gebaseerd op regels die gebruik maken van de stateful opties keep state, limit, in, out en via. Dit is het raamwerk waarmee een set van inclusieve firewallregels wordt samengesteld. Wees voorzichtig tijdens het werken met firewall-regels, het is gemakkelijk om uzelf uit te sluiten. Regelsyntaxis IPFW regelsyntaxis De regelsyntaxis zoals hier toegelicht is vereenvoudigd door alleen te tonen wat nodig is om een standaard inclusieve set met firewallregels te maken. De complete beschrijving van alle mogelijkheden staat in &man.ipfw.8;. Regels bevatten sleutelwoorden die in een bepaalde volgorde van links naar rechts op een regel horen te staan. Sleutelwoorden worden vet weergegeven. Sommige sleutelwoorden hebben subopties die zelf ook weer sleutelwoorden hebben die ook weer subopties kunnen hebben. Het karakter # wordt gebruikt om het begin van een opmerking te markeren en kan zowel op een eigen regel als achter een firewallregel staan. Lege regels worden genegeerd. CMD REGEL_NUMMER ACTIE LOGGEN SELECTIE STATEFUL CMD Iedere regel moet beginnen met add om hem toe te voegen aan de tabel met regels. REGEL_NUMMER Iedere regel moet een regelnummer hebben. ACTIE Bij een regel kunnen één of meer acties horen die worden uitgevoerd als een regel geldt voor een pakket. allow | accept | pass | permit Deze opties betekenen allemaal hetzelfde: als de regel geldt voor een pakket, laat dat pakket dan door en stop met het zoeken naar geldende regels. check–state Vergelijkt het pakket met de tabel met dynamische regels. Als het erin staat, dan wordt de actie van de dynamisch door deze regel gemaakte regel uitgevoerd. Anders wordt er verder gezocht door de regels. Een regel met check–state heeft geen selectiecriteria. Als er geen regel met check–state in de set met regels staat, dan wordt de tabel met dynamische regels bij het eerste voorkomen van keep–state of limit gecontroleerd. deny | drop Deze opties betekenen hetzelfde: als de regel geldt voor een pakket, blokkeer dat pakket dan en stop met het zoeken naar geldende regels. Loggen log of logamount Als een regel met het sleutelwoord log van toepassing is op een pakket, dan wordt er een bericht naar &man.syslogd.8; geschreven met de faciliteitsnaam SECURITY. Er wordt alleen een bericht geschreven als het aantal voor die regel gelogde pakketten niet groter is dan de instelling van de parameter logamount. Als er geen logamount is ingesteld, dan wordt de limiet uit de &man.sysctl.8; variabele net.inet.ip.fw.verbose_limit gehaald. In beide gevallen bestaat er in het geval de waarde nul is geen limiet. Als de limiet is bereikt, dan kan het loggen weer ingeschakeld worden door de teller voor het loggen weer op nul te zetten voor die regel met het commando ipfw reset log. Er wordt gelogd als een pakket zeker past bij een regel, maar voordat de actie (bijvoorbeeld accept of deny) op een pakket wordt toegepast. Uiteindelijk bepaalt de gebruiker zelf voor welke regels loggen wordt ingeschakeld. Selectie De sleutelwoorden in deze paragraaf beschrijven de attributen van een pakket die gecontroleerd worden bij het bepalen of een regel wel of niet op een pakket van toepassing is. De attributen waarop gecontroleerd kan worden moeten in de beschreven volgorde gebruikt worden. udp | tcp | icmp Naast de hierboven aangegeven protocollen kunnen alle in /etc/protocols beschreven protocollen gebruikt worden. De waarde die wordt opgegeven is het protocol dat van toepassing moet zijn. Dit attribuut is verpicht. from bron to best De sleutelwoorden from en to worden gebruikt om te bekijken of een regel van toepassing is op IP-adressen. Een regel moet zowel bron- als bestemmingsadressen bevatten. any is een bijzonder sleutelwoord dat van toepassing is op alle IP-adressen. me is een bijzonder sleutelwoord dat van toepassing is op alle IP-adressen die ingesteld zijn op interfaces van een &os; systeem om de PC waarop de firewall draait te vertegenwoordigen (deze machine). Zo kan dit onderdeel bijvoorbeeld de volgende vormen aannemen: from me to any, from any to me, from 0.0.0.0/0 to any, from any to 0.0.0.0/0, from 0.0.0.0 to any, from any to 0.0.0.0 of from me to 0.0.0.0. IP-adressen mogen ingevoerd worden in de vorm numeriek, door punten gescheiden adres/maskerlengte (CIDR-notatie) of als een enkelvoudig IP-adres in de vorm numeriek, door punten gescheiden. De port net-mgmt/ipcalc kan gebruikt worden om de berekeningen e vereenvoudigen. Aanvullende informatie is beschikbaar op de webpagina van het programma: . poortnummer Wordt gebruikt voor protocollen die poortnummers ondersteunen (als TCP en UDP). Het gebruik van een poortnummer is verplicht. Er mogen ook dienstnamen uit /etc/services gebruikt worden in plaats van nummers. in | out Is op respectievelijk inkomende of uitgaande pakketten van toepassing. De sleutelwoorden in of out zijn verplicht in een regel. via IF Deze parameter geeft aan op welke interface de regel van toepassing is, waarbij IF de exacte naam van de bedoelde interface is. setup Dit is een verplicht sleutelwoord waarmee wordt aangegeven dat er gezocht wordt naar een pakket met het verzoek tot het opstarten van een TCP sessie. keep–state Dit is een verplicht sleutelwoord. Als er een pakket op een regel met keep–state van toepassing is, dan wordt er door de firewall een dynamische regel gemaakt die bi–directioneel verkeer zal toestaan tussen bron en bestemming en de bijbehorende poorten voor hetzelfde protocol. limit {bron–adr | bron–poort | best–adr | best–poort} De firewall staat maar N verbindingen toe met dezelfde groep parameters uit een regel. Er kunnen één of meer van de parameters bron- of bestemmingsadres en bron- en bestemmingspoort gebruikt worden. limit en keep–state kunnen niet in dezelfde regel gebruikt worden. De optie limit geeft dezelfde mogelijkheden als keep–state en voegt daar zijn eigen mogelijkheden aan toe. Regeloptie stateful IPFW stateful filteren Bij stateful filteren wordt verkeer bekeken als bi–directioneel verkeer dat samen een sessie vormt. Het heeft de mogelijkheid om te bepalen of de sessie tussen de zender en de ontvanger op de juiste wijze voortgaat. Alle pakketten die niet precies in de verwachting van een sessie passen worden automatisch als fout geblokkeerd. De optie check–state wordt gebruikt om aan te geven waar IPFW-regels tegen de mogelijkheden voor dynamische regels gehouden moeten worden. Als er een passende regel bij een pakket wordt gevonden, dan kan dat pakket de firewall verlaten en wordt een nieuwe regel gemaakt voor het volgende pakket dat wordt verwacht in de sessie. Als er geen regel van toepassing is op het pakket, dan wordt de volgende regel in de groep regels getest. De mogelijkheden voor dynamische regels zijn kwetsbaar voor een aanval die SYN–flood heet, waarmee wordt geprobeerd een zeer groot aantal regels aan te laten maken. Om deze aanval tegen te gaan, is de optie limit beschikbaar. Met deze optie kan het maximaal aantal simultane sessies geregeld worden op basis van bron en bestemmingsvelden. Als het aantal sessies gelijk aan het maximale aantal sessies is, wordt een pakket voor een nieuwe sessie geweigerd. Firewallberichten loggen IPFW loggen De voordelen van loggen zijn duidelijk. Het biedt de mogelijkheid om na het feit informatie na te zien als: welke pakketten heeft de firewall laten vallen, waar kwamen ze vandaan en waar gingen ze heen. Dit zijn allemaal voordelen als het gaat om uitvinden waar een aanvaller vandaan komt en wat hij heeft geprobeerd. Zelfs als logging is ingeschakeld logt IPFW nog niets uit zichzelf. De beheerder van de firewall beslist welke actieve regels iets weg moeten schrijven door het sleutelwoord log aan die regels toe te voegen. Gewoonlijk worden alleen deny-regels gelogd. Dit geldt bijvoorbeeld voor de deny-regel voor inkomende ICMP pings. Het is gebruikelijk om de standaardregel ipfw default deny everything te dupliceren, daar log in op te nemen, en deze als laatste in de verzameling met regels te plaatsen. Zo zijn alle pakketten te zien die niet voldeden aan ook maar één regel. Loggen heeft ook mogelijke nadelen. Het is mogelijk om te veel te loggen en dan om te komen in logboekgegevens die uiteindelijk een schijf kunnen vullen. Een DoS aanval om een schijf met logs te vullen is een van de oudst bekende typen DoS aanvallen. Logberichten van de firewall worden niet alleen naar syslogd geschreven, maar ook op het root console getoond waar ze snel erg vervelend kunnen worden. De kerneloptie IPFIREWALL_VERBOSE_LIMIT=5 beperkt het aantal opeenvolgende berichten dat naar &man.syslogd.8; wordt geschreven voor één specifieke regel. Als deze optie is ingeschakeld, worden in dit geval maximaal vijf berichten voor dezelfde regel gemeld. Als er meer berichten op dezelfde regel zouden zijn, zou dat als volgt aan syslogd gemeld worden: last message repeated 45 times Standaard worden alle gelogde pakketten weggeschreven naar /var/log/security, wat is ingesteld in /etc/syslog.conf. Regelscript bouwen De meeste ervaren gebruikers van IPFW maken een bestand waarin de regels staan en stellen dat zo op dat het als script uitgevoerd kan worden. Het grootste voordeel van deze methode is dat de firewallregels allemaal vervangen kunnen worden zonder dat het systeem opnieuw gestart moet worden. Deze methode is ook erg geschikt voor het testen van regels omdat de procedure zo vaak als nodig uitgevoerd kan worden. Omdat het een script is, kan er gebruik gemaakt worden van substitutie zodat veel gebruikte waarden verduidelijkt en in meerdere regels toegepast kunnen worden. In het volgende voorbeeld wordt hier gebruik van gemaakt. De syntaxis die in het script wordt gebruikt is compatibel met de shells &man.sh.1;, &man.csh.1; en &man.tcsh.1;. Velden waarvoor substitutie van toepassing is worden vooraf gegaan door het dollarteken $. Definities worden niet vooraf gegaan door het voorvoegsel $. De waarden van een substitutie moet omsloten worden door "dubbele aanhalingstekens". Een bestand met regels kan als volgt beginnen: ############### begin voorbeeldscript ipfw regels ############## # ipfw –q –f flush # Verwijder alle bestaande regels. # Stel standaarden in. oif="tun0" # uitgaande interface. odns="192.0.2.11" # IP adres DNS server ISP. cmd="ipfw –q add " # Voorvoegsel voor regel. ks="keep–state" # Te lui om iedere keer in te typen. $cmd 00500 check–state $cmd 00502 deny all from any to any frag $cmd 00501 deny tcp from any to any established $cmd 00600 allow tcp from any to any 80 out via $oif setup $ks $cmd 00610 allow tcp from any to $odns 53 out via $oif setup $ks $cmd 00611 allow udp from any to $odns 53 out via $oif $ks ################### einde voorbeeldscript ipfw regels ########### Dat is alles. De feitelijke functie van de regels is in dit voorbeeld van ondergeschikt belang. Dit was slechts een voorbeeld om het gebruik van substitutie te illustreren. Als het bovenstaande voorbeeld de inhoud van /etc/ipfw.rules was, dan kon het herladen worden met het volgende commando: &prompt.root; sh /etc/ipfw.rules /etc/ipfw.rules zou overal kunnen staan met iedere gewenste naam. Wat in het bovenstaande voorbeeld met een bestand is gerealiseerd, kan ook met de hand: &prompt.root; ipfw –q –f flush &prompt.root; ipfw –q add 00500 check–state &prompt.root; ipfw –q add 00502 deny all from any to any frag &prompt.root; ipfw –q add 00501 deny tcp from any to any established &prompt.root; ipfw –q add 00600 allow tcp from any to any 80 out via tun0 setup keep–state &prompt.root; ipfw –q add 00610 allow tcp from any to 192.0.2.11 53 out via tun0 setup keep–state &prompt.root; ipfw –q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep–state Verzameling van stateful regels De volgende verzameling van regels, waarin geen gebruik gemaakt wordt van NAT, is een voorbeeld van hoe een erg veilige inclusieve firewall kan worden opgezet. Een inclusieve firewall laat alleen diensten toe waarvoor pass regels van toepassing zijn en blokkeert al het andere verkeer. Firewalls die ontworpen zijn om hele netwerksegmenten te beschermen hebben tenminste twee interfaces waarvoor regels moeten zijn die de firewall in staat stellen zijn werk te doen. Alle &unix; systemen en dus ook &os; zijn zo ontworpen dat ze voor interne communicatie de interface lo0 en IP adres 127.0.0.1 gebruiken. De firewall moet dit interne verkeer gewoon doorgang laten vinden. Voor de interface die is verbonden met het publieke Internet worden regels gemaakt waarmee sessies naar het Internet mogelijk gemaakt worden en toegang wordt gegeven voor pakketten die uit die sessies terug komen. Dit kan de gebruikers-PPP-interface tun0 zijn of de netwerkkaart die is verbonden met een xDSL of kabelmodem. In gevallen dat er meer dan één netwerkkaart is aangesloten op het private netwerk achter de firewall, moeten er op de firewall-regels zijn om het verkeer tussen die interfaces vrije doorgang te geven. De regels worden opgedeeld in drie onderdelen: alle interfaces met vrije doorgang, uitgaand op publieke interfaces en inkomend op publieke interfaces. De volgorde van de regels in iedere sectie voor publieke interfaces moet zo zijn dat de regels die het meest gebruikt worden vóór de regels staan die minder vaak gebruikt worden. De laatste regel van een onderdeel geeft aan dat al het overige verkeer op die interface in die richting geblokkeerd en gelogd moet worden. In het onderdeel Uitgaand van de volgende verzameling regels staan alleen regels met allow die parameters bevatten om individuele diensten beschikbaar te maken die publieke toegang tot Internet mogen hebben Al die regels moeten gebruik maken van de opties proto, port, in/out, via en keep-state. De regels met proto tcp maken ook gebruik van setup om te bekijken of het een pakket betreft voor het opzetten van een sessie om de stateful functionaliteit aan te sturen. In het onderdeel Inkomend staan als eerste alle regels voor het blokkeren van ongewenste pakketten, om twee redenen. Als eerste kan het zo zijn dat kwaadaardige pakketten gedeeltelijk overeenkomen met legitiem verkeer. Deze regels moeten worden geblokkeerd in plaats van te worden binnengelaten, gebaseerd op hun gedeeltelijke overeenkomst met allow-regels. De tweede reden is dat nu ongewenste pakketten die vaak voorkomen en die bij voorkeur niet in de logboeken voorkomen niet meer van toepassing zijn op de laatste regel van het onderdeel waarin ze zouden worden gelogd. Met de laatste regel van dit onderdeel worden alle overige pakketten geblokkeerd en gelogd en ze kunnen bewijsmateriaal zijn in een zaak tegen iemand die heeft geprobeerd een systeem aan te vallen. Iets waarop u ook moet letten is dat voor al het verkeer dat wordt geweigerd geen antwoord wordt gestuurd. Die pakketten verdwijnen gewoon. Zo weet een aanvaller niet of een pakket het doelsysteem wel heeft bereikt. Zo kan een aanvaller geen informatie verzamelen over een systeem: hoe minder informatie er over een systeem beschikbaar is, hoe veiliger het is. Als er pakketten gelogd worden met een onbekend poortnummer, dan is de functie van dat poortnummer na te zoeken in /etc/services of op . Op de volgende link worden poortnummers van Trojans beschreven: . Voorbeeld van een set inclusieve regels Het volgende voorbeeld is een complete inclusieve verzameling van regels die geen gebruik maakt van NAT. Deze verzameling van regels is veilig om deze regels op uw eigen systemen te gebruiken. Dit kan door commentaar te maken van een pass-regel voor een dienst die niet gewenst is. Logberichten die niet gewenst zijn, zijn uit te sluiten door een deny-regel toe te voegen aan het onderdeel Inkomend. Voor de onderstaande regels dient de interfacenaam dc0 in iedere regel vervangen te worden door de interfacenaam van de netwerkkaart in het systeem die met het publieke Internet is verbonden. Voor gebruikers van PPP zou dat tun0 zijn. Er zit een merkbare structuur in het gebruik van deze regels: Alle regels die een verzoek zijn voor het opzetten van een sessie gebruiken keep–state. Alle diensten die vanaf Internet bereikbaar zijn gebruiken de optie limit om flooding te voorkomen. Alle regels gebruiken in of out om de richting aan te geven. Alle regels gebruiken via interfacenaam om aan te geven op welke interface de regel van toepassing is. De volgende regels zouden in /etc/ipfw.rules kunnen staan: ################ Begin bestand met IPFW regels ############################### # Verwijder eerst de bestaande regels. ipfw –q –f flush # Stel commando voorvoegsel in. cmd="ipfw –q add" pif="dc0" # Interfacenaam van NIC die verbinding # met het publieke Internet heeft. ################################################################# # Geen beperkingen op de interface aan de LAN kant. Alleen nodig # als er een LAN is. Wijzig xl0 naar de gebruikte interfacenaam. ################################################################# #$cmd 00005 allow all from any to any via xl0 ################################################################# # Geen beperkingen op de loopback interface. ################################################################# $cmd 00010 allow all from any to any via lo0 ################################################################# # Sta het pakket toe als het aan de tabel met dynamische regels # was toegevoegd met een 'allow keep–state' commando. ################################################################# $cmd 00015 check–state ################################################################# # Interface aan het publieke Internet (onderdeel Uitgaand). # Inspecteer verzoeken om een sessie te starten van achter de # firewall op het private netwerk of vanaf de server zelf naar # het publieke Internet. ################################################################# # Geef toegang tot de DNS server van de ISP. # x.x.x.x moet het IP adres van de DNS van de ISP zijn. # Dupliceer deze regels als een ISP meerdere DNS servers heeft. # Haal het IP adres evt. uit /etc/resolv.conf $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep–state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep–state # Geef toegang tot de DHCP server van de ISP voor kabel- en # xDSL-netwerken. Deze regel is niet nodig als gebruik gemaakt worden # van PPP naar het publieke Internet. In dat geval kan de hele groep # verwijderd worden. Gebruik de volgende regel en controleer het # logboek voor het IP adres. Wijzig dan het IP adres in de regel # commentaar hieronder en verwijder de eerste regel. $cmd 00120 allow log udp from any to any 67 out via $pif keep–state #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep–state # Sta niet beveiligd www verkeer toe. $cmd 00200 allow tcp from any to any 80 out via $pif setup keep–state # Sta beveiligd www verkeer over TLS SSL toe. $cmd 00220 allow tcp from any to any 443 out via $pif setup keep–state # Sta het verzenden en ontvangen van e-mail toe. $cmd 00230 allow tcp from any to any 25 out via $pif setup keep–state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep–state # Sta de FreeBSD CVSUP functie toe voor uid root. $cmd 00240 allow tcp from me to any out via $pif setup keep–state uid root # Sta ping toe. $cmd 00250 allow icmp from any to any out via $pif keep–state # Sta Time toe naar buiten. $cmd 00260 allow tcp from any to any 37 out via $pif setup keep–state # Sta NNTP nieuws toe naar buiten. $cmd 00270 allow tcp from any to any 119 out via $pif setup keep–state # Sta beveiligde FTP, Telnet en SCP toe naar buiten. # Deze functie maakt gebruik van SSH (secure shell). $cmd 00280 allow tcp from any to any 22 out via $pif setup keep–state # Sta whois toe naar buiten. $cmd 00290 allow tcp from any to any 43 out via $pif setup keep–state # Blokkeer en log al het andere dat probeert buiten te komen. # Deze regel dwingt de 'block all' logica af. $cmd 00299 deny log all from any to any out via $pif ################################################################# # Interface aan het publieke Internet (onderdeel Inkomend). # Inspecteert pakketten die van het publieke Internet komen # met als bestemming de host zelf of het private netwerk. ################################################################# # Blokkeer al het verkeer voor niet-routeerbare of gereserveerde # adresreeksen. $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 privaat IP $cmd 00301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 privaat IP $cmd 00302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 privaat IP $cmd 00303 deny all from 127.0.0.0/8 to any in via $pif #loopback $cmd 00304 deny all from 0.0.0.0/8 to any in via $pif #loopback $cmd 00305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto–config $cmd 00306 deny all from 192.0.2.0/24 to any in via $pif #gereserveerd voor documentatie $cmd 00307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster interconnect $cmd 00308 deny all from 224.0.0.0/3 to any in via $pif #Klasse D & E multicast # Blokkeer publieke pings. $cmd 00310 deny icmp from any to any in via $pif # Blokkeer ident. $cmd 00315 deny tcp from any to any 113 in via $pif # Blokkeer alle Netbios diensten. 137=naam, 138=datagram, 139=sessie. # Netbios is de Windows® bestandsdeeldienst. # Blokkeer Windows hosts2 name server verzoeken 81. $cmd 00320 deny tcp from any to any 137 in via $pif $cmd 00321 deny tcp from any to any 138 in via $pif $cmd 00322 deny tcp from any to any 139 in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Blokkeer gefragmenteerde pakketten. $cmd 00330 deny all from any to any frag in via $pif # Blokkeer ACK pakketten die niet in de tabel met dynamische regels # staan. $cmd 00332 deny tcp from any to any established in via $pif # Geef toegang tot de DHCP server van de ISP voor kabel- en # xDSL-netwerken. Deze regel is niet nodig als gebruik gemaakt worden # van PPP naar het publieke Internet. In dat geval kan de hele groep # verwijderd worden. Hier wordt hetzelfde IP adres gebruikt als in de # sectie voor Uitgaand verkeer. #$cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep–state # Sta inkomend webverkeer toe omdat er een Apache server draait. $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src–addr 2 # Sta beveiligde FTP, telnet en SCP toe vanaf Internet. $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src–addr 2 # Sta niet beveiligde telnet sessie toe vanaf het publieke Internet. # Dit heeft het label ``niet veilig'' omdat gebruikersnaam en # wachtwoord als platte tekst over Internet gaan. Als er geen telnet # server draait, hoeft deze regel niet actief te zijn. $cmd 00420 allow tcp from any to me 23 in via $pif setup limit src–addr 2 # Weiger en log alle niet toegestane inkomende verbindingen van buiten. $cmd 00499 deny log all from any to any in via $pif # Al het andere verkeer wordt standaard geblokkeerd. Weiger en log alle # pakketten die tot hier zijn gekomen om te bekijken welke het waren. $cmd 00999 deny log all from any to any ################ Einde bestand met IPFW regels ######################## Voorbeeld <acronym>NAT</acronym> en stateful regels NAT en IPFW Om NAT met IPFW te gebruiken moeten een extra aantal instellingen gemaakt worden. In het instellingenbestand voor de kernel moet option IPDIVERT toegevoegd worden aan de andere opties van IPFIREWALL. Naast de normale IPFW opties in /etc/rc.conf zijn de volgende nodig: natd_enable="YES" # Schakel NATD in natd_interface="rl0" # interfacenaam voor de publieke Internet NIC natd_flags="–dynamic –m" # –m = behoud poortnummers als mogelijk Stateful regels samen met de regel divert natd (Network Address Translation) gebruiken maakt het schrijven van regels veel gecompliceerder. De plaats van de regels met check–state en divert natd zijn van kritiek belang. De logica bestaat niet langer uit het eenvoudigweg van boven naar beneden doorwerken van de regels. Er wordt dan ook een nieuw type actie gebruik: skipto. Bij het gebruik van skipto is het verplicht iedere regel te nummeren zodat duidelijk is waar een skipto precies heen springt. Hieronder staat een groep regels zonder commentaar waarin een manier om pakketten door de groep regels te leiden wordt aangegeven. De verwerking begint met de eerste regel en er wordt steeds een volgende regel gecontroleerd tot het einde wordt bereikt of totdat een regel op het gecontroleerde pakket van toepassing is, en het pakket uit de firewall wordt vrijgelaten. In het voorbeeld zijn de regels 100, 101, 450, 500, en 510 van belang. Die regels regelen de vertaling van inkomende en uitgaande pakketten zodat er in de tabel met de dynamische keep–state-regels altijd het private IP-adres staat. Daarnaast is het van belang op te merken dat er in alle allow- en deny-regels de richting van het pakket wordt gecontroleerd (inkomend of uitgaand) en over welke interface het pakket gaat. Merk ook op dat alle uitgaande verzoeken voor het starten van een sessie met een skipto naar regel 500 gaan voor NAT. Stel dat een gebruiker zijn webbrowser gebruikt om een webpagina op te halen. Webpagina's worden over poort 80 verzonden. Er komt een pakket de firewall binnen dat niet past bij regel 100 omdat het naar buiten gaat en niet naar binnen. Het komt voorbij regel 101 omdat dit het eerste pakket is en er dus nog niets over in de dynamische keep-state tabel staat. Als het pakket bij 125 aankomt blijkt het te passen bij die regel. Het gaat naar buiten door de interface aan het publieke Internet. Het pakket heeft dan nog steeds het bron-IP-adres van het private LAN. Als blijkt dat deze regel geldt, dan gebeuren er twee dingen: door keep–state wordt er een regel in de dynamische keep–state tabel gezet en wordt de aangegeven actie uitgevoerd. De actie is onderdeel van de informatie uit de dynamische tabel. In dit geval is het skipto rule 500. In regel 500 wordt NAT op het IP-adres van het pakket toegepast en dan kan het weg. Dit is van groot belang. Dit pakket komt aan op zijn bestemming en als er een pakket als antwoord terug komt, dan begint de verwerking van het antwoordpakket weer van voor af aan. Nu voldoet het aan regel 100 en dus wordt het bestemmingsadres vertaald naar het bijbehorende IP-adres op het LAN. Daarna past het bij de check–state-regel en wordt een vermelding in de tabel gevonden wat betekent dat er een bestaande sessie is en wordt het doorgelaten naar het LAN. Het gaat dan naar de PC op het LAN die als eerste een pakket heeft verzonden en die verstuurt een nieuw pakket met de vraag om een volgend segment met gegevens naar de server. Nu blijkt bij controle van de check–state-regel dat die op het pakket van toepassing moet zijn en er staat een vermelding in de tabel voor uitgaand verkeer. Daarom wordt de bijbehorende actie skipto rule 500 uitgevoerd. Het pakket springt naar regel 500, er wordt NAT op toegepast en het kan zijn weg vervolgen. Wat betreft binnenkomende pakketten wordt alles dat onderdeel is van een bestaande sessie automatisch afgehandeld door de check–state-regel en de correct geplaatste divert natd-regels. Nu hoeven alleen de foute pakketten nog geweigerd te worden en moeten de inkomende diensten doorgelaten worden. In dit geval draait er een Apache server op de firewall-machine die vanaf Internet bereikbaar moet zijn. Het nieuwe inkomende pakket past bij regel 100 en het IP-adres wordt aangepast aan het interne IP-adres van de firewall-machine. Dat pakket wordt dan gecontroleerd op alle ongewenste eigenschappen en komt uiteindelijk aan bij regel 425 die van toepassing blijkt te zijn. In dat geval kunnen er twee dingen gebeuren: de pakketregel wordt in de dynamische keep–state tabel gezet, maar nu wordt het aantal nieuwe sessies dat van het bron IP-adres komt gelimiteerd tot twee. Dit is een bescherming tegen DoS-aanvallen op de dienst die op dat poortnummer wordt aangeboden. De actie is allow, dus het pakket wordt tot het LAN toegelaten. Voor het pakket dat als antwoord wordt verstuurd herkent de check–state regel dat het pakket bij een bestaande sessie hoort. Het stuurt het naar regel 500 voor NAT en stuurt het via de uitgaande interface weg. Voorbeeld Set Regels #1: #!/bin/sh cmd="ipfw –q add" skip="skipto 500" pif=rl0 ks="keep–state" good_tcpo="22,25,37,43,53,80,443,110,119" ipfw –q –f flush $cmd 002 allow all from any to any via xl0 # exclude LAN traffic $cmd 003 allow all from any to any via lo0 # exclude loopback traffic $cmd 100 divert natd ip from any to any in via $pif $cmd 101 check–state # Toegestaan uitgaand verkeer. $cmd 120 $skip udp from any to xx.168.240.2 53 out via $pif $ks $cmd 121 $skip udp from any to xx.168.240.5 53 out via $pif $ks $cmd 125 $skip tcp from any to any $good_tcpo out via $pif setup $ks $cmd 130 $skip icmp from any to any out via $pif $ks $cmd 135 $skip udp from any to any 123 out via $pif $ks # Blokkeer al het verkeer voor niet-routeerbare of gereserveerde # adresreeksen. $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 privaat IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 privaat IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 privaat IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto–config $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #gereserveerd voor documentatie $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Klasse D & E multicast # Toegestaan inkomend verkeer. $cmd 400 allow udp from xx.70.207.54 to any 68 in $ks $cmd 420 allow tcp from any to me 80 in via $pif setup limit src–addr 1 $cmd 450 deny log ip from any to any # Dit is de 'skipto' locatie voor de uitgaande stateful regels. $cmd 500 divert natd ip from any to any out via $pif $cmd 510 allow ip from any to any ######################## Einde regels ################## Het volgende voorbeeld doet vrijwel hetzelfde als het bovenstaande, maar volgt een zelfdocumenterende stijl voor het opstellen van regels en commentaar waardoor minder ervaren gebruikers beter kunnen begrijpen wat de regels doen. Voorbeeld Set Regels #2: #!/bin/sh ################ Begin bestand met IPFW regels ############################### # Verwijder eerst de bestaande regels. ipfw –q –f flush # Stel commando voorvoegsel in. cmd="ipfw –q add" skip="skipto 800" pif="rl0" # Interfacenaam van NIC die verbinding # met het publieke Internet heeft. ################################################################# # Geen beperkingen op de interface aan de LAN kant. # Wijzig xl0 naar de gebruikte interfacenaam. ################################################################# $cmd 005 allow all from any to any via xl0 ################################################################# # Geen beperkingen op de loopback interface. ################################################################# $cmd 010 allow all from any to any via lo0 ################################################################# # Controleer of pakket inkomend is. NAT in dat geval. ################################################################# $cmd 014 divert natd ip from any to any in via $pif ################################################################# # Sta het pakket toe als het aan de tabel met dynamische regels # was toegevoegd met een 'allow keep–state' commando. ################################################################# $cmd 015 check–state ################################################################# # Interface aan het publieke Internet (onderdeel Uitgaand). # Inspecteer verzoeken om een sessie te starten van achter de # firewall op het private netwerk of vanaf de server zelf naar # het publieke Internet. ################################################################# # Geef toegang tot de DNS server van de ISP. # x.x.x.x moet het IP adres van de DNS van de ISP zijn. # Dupliceer deze regels als een ISP meerdere DNS servers heeft. # Haal het IP adres evt. uit /etc/resolv.conf $cmd 020 $skip tcp from any to x.x.x.x 53 out via $pif setup keep–state # Geef toegang tot de DHCP server van de ISP voor kabel en xDSL. $cmd 030 $skip udp from any to x.x.x.x 67 out via $pif keep–state # Sta niet beveiligd www verkeer toe. $cmd 040 $skip tcp from any to any 80 out via $pif setup keep–state # Sta beveiligd www verkeer over TLS SSL toe. $cmd 050 $skip tcp from any to any 443 out via $pif setup keep–state # Sta het verzenden en ontvangen van e-mail toe. $cmd 060 $skip tcp from any to any 25 out via $pif setup keep–state $cmd 061 $skip tcp from any to any 110 out via $pif setup keep–state # Sta de FreeBSD CVSUP functie toe voor uid root. $cmd 070 $skip tcp from me to any out via $pif setup keep–state uid root # Sta ping toe naar het publieke Internet. $cmd 080 $skip icmp from any to any out via $pif keep–state # Sta Time toe. $cmd 090 $skip tcp from any to any 37 out via $pif setup keep–state # Sta NNTP nieuws toe. $cmd 100 $skip tcp from any to any 119 out via $pif setup keep–state # Sta beveiligde FTP, Telnet en SCP toe. # Deze functie maakt gebruik van SSH (secure shell). $cmd 110 $skip tcp from any to any 22 out via $pif setup keep–state # Sta whois toe. $cmd 120 $skip tcp from any to any 43 out via $pif setup keep–state # Sta NPT tijdserver toe. $cmd 130 $skip udp from any to any 123 out via $pif keep–state ################################################################# # Interface aan het publieke Internet (onderdeel Inkomend). # Inspecteert pakketten die van het publieke Internet komen met # als bestemming deze gateway-server zelf of het private netwerk. ################################################################# # Blokkeer al het verkeer voor niet-routeerbare of gereserveerde # adresreeksen. $cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 privaat IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 privaat IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 privaat IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP auto–config $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #gereserveerd voor documentatie $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Klasse D & E multicast # Blokkeer ident. $cmd 315 deny tcp from any to any 113 in via $pif # Blokkeer alle Netbios diensten. 137=naam, 138=datagram, 139=sessie. # Netbios is de Windows® bestandsdeeldienst. # Blokkeer Windows hosts2 name server verzoeken 81. $cmd 320 deny tcp from any to any 137 in via $pif $cmd 321 deny tcp from any to any 138 in via $pif $cmd 322 deny tcp from any to any 139 in via $pif $cmd 323 deny tcp from any to any 81 in via $pif # Blokkeer gefragmenteerde pakketten. $cmd 330 deny all from any to any frag in via $pif # Blokkeer ACK pakketten die niet in de tabel met dynamische regels # staan. $cmd 332 deny tcp from any to any established in via $pif # Geef toegang tot de DHCP server van de ISP voor kabel- en # xDSL-netwerken. Deze regel is niet nodig als gebruik gemaakt worden # van PPP naar het publieke Internet. In dat geval kan de hele groep # verwijderd worden. Hier wordt hetzelfde IP adres gebruikt als in de # sectie voor Uitgaand verkeer. $cmd 360 allow udp from x.x.x.x to any 68 in via $pif keep–state # Sta inkomend webverkeer toe omdat er een Apache server draait. $cmd 370 allow tcp from any to me 80 in via $pif setup limit src–addr 2 # Sta beveiligde FTP, telnet en SCP toe vanaf Internet. $cmd 380 allow tcp from any to me 22 in via $pif setup limit src–addr 2 # Sta niet beveiligde telnet sessie toe vanaf het publieke Internet. # Dit heeft het label ``niet veilig'' omdat gebruikersnaam en # wachtwoord als platte tekst over Internet gaan. Als er geen telnet # server draait, hoeft deze regel niet actief te zijn. #$cmd 390 allow tcp from any to me 23 in via $pif setup limit src–addr 2 # Weiger en log alle niet toegestane inkomende verbindingen vanaf het # publieke Internet. $cmd 400 deny log all from any to any in via $pif # Weiger en log alle niet toegestane uitgaande verbindingen naar # Internet. $cmd 450 deny log all from any to any out via $pif # Dit is de 'skipto' locatie voor de uitgaande stateful regels $cmd 800 divert natd ip from any to any out via $pif $cmd 801 allow ip from any to any # Al het andere verkeer wordt standaard geblokkeerd. Weiger en log alle # pakketten die tot hier zijn gekomen om te bekijken welke het waren. $cmd 999 deny log all from any to any ################ Einde bestand met IPFW regels ######################## diff --git a/nl_NL.ISO8859-1/books/handbook/introduction/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/introduction/chapter.sgml index 9f53fc5a6a..2b2694d10e 100644 --- a/nl_NL.ISO8859-1/books/handbook/introduction/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/introduction/chapter.sgml @@ -1,1170 +1,1173 @@ Jim Mock Gereorganiseerd en delen herschreven door Arjan van Leeuwen Vertaald door Introductie Overzicht Welkom bij &os;! Dit hoofdstuk beschrijft de verschillende aspecten van het &os; Project: geschiedenis, doelen, ontwikkelmodel en meer. Na het lezen van dit hoofdstuk weet de lezer: Hoe &os; gerelateerd is aan andere besturingssystemen; De geschiedenis van het &os; Project; De doelen van het &os; Project; De fundering van het &os; open-source ontwikkelmodel; En natuurlijk: waar de naam &os; vandaan komt. Welkom bij &os;! 4.4BSD-Lite &os; is een op 4.4BSD-Lite gebaseerd besturingssysteem voor Intel (x86 en &itanium;), AMD64, Alpha en Sun &ultrasparc; computers. Er zijn ook ports naar andere architecturen in voorbereiding. Er is nog meer informatie over de geschiedenis van &os; of over de huidige uitgave. Als de lezer wil bijdragen aan het project (code, hardware, geld) wordt aangeraden het artikel Bijdragen aan &os; te lezen. Wat kan &os;? &os; heeft veel mogelijkheden die het bespreken waard zijn. Hier zijn er enkele op een rij gezet: preemptive multitasking Preemptive multitasking zorgt ervoor dat meerdere programma's en gebruikers op dezelfde computer kunnen werken, zonder dat de systeemrespons of stabiliteit beïnvloed wordt. Meerdere gebruikers Ondersteuning voor meerdere gebruikers maakt het mogelijk dat verschillende mensen een &os; systeem tegelijkertijd kunnen gebruiken voor een groot aantal taken. Dit betekent bijvoorbeeld dat randapparaten als printers en tapedrives gedeeld kunnen worden door alle gebruikers van het systeem en dat individuele beperkingen ingesteld kunnen worden voor gebruikers of voor groepen gebruikers, zodat kritieke systeembronnen beschermd kunnen worden tegen onrechtmatig of overmatig gebruik. TCP/IP netwerken Krachtige mogelijkheden voor TCP/IP netwerken met ondersteuning voor industriestandaarden als SCTP, DHCP, NFS, NIS, PPP, SLIP, IPsec en IPv6. Dit betekent dat een &os;-systeem makkelijk kan samenwerken met andere systemen en dat het kan functioneren als bedrijfsserver, waarbij het belangrijke functies als NFS (bestandsdeling over het netwerk), email, webdiensten, FTP, routing en firewall-diensten kan aanbieden. Geheugenbeveiliging Geheugenbeveiliging garandeert dat applicaties (of gebruikers) elkaar niet kunnen storen. Een crashende applicatie heeft totaal geen effect op andere applicaties. &os; is een 32-bits besturingssysteem (64-bits op de Alpha, &itanium;, AMD64, en &ultrasparc;) en is van de grond af aan zo ontworpen. X Window systeem XFree86 Het X Window systeem (X11R7), een industriële standaard, biedt een grafische gebruikersinterface (GUI) met als enige benodigdheden een VGA-kaart en een beeldscherm. binaire compatibiliteit Linux binaire compatibiliteit SCO binaire compatibiliteit SVR4 binaire compatibiliteit BSD/OS binaire compatibiliteit NetBSD Door binaire compatibiliteit met veel programma's voor &linux;, SCO, SVR4, BSDI en NetBSD is het mogelijk om deze programma's zonder snelheidsverlies op &os; te draaien. Er zijn duizenden applicaties beschikbaar in de &os; ports en pakketten collectie. Waarom zoeken op het Internet als het allemaal al klaarstaat? Duizenden andere en makkelijk over te zetten applicaties zijn beschikbaar op het Internet. &os; is broncode-compatibel met de meeste populaire commerciële &unix; systemen, wat betekent dat veel applicaties nagenoeg geen wijzigingen vereisen om te compileren op &os;. Virtueel geheugen Het demand-paged virtueel geheugen en de gecombineerde VM/buffer cache van &os; zorgen ervoor dat applicaties met grote geheugenbehoeften niets te kort komen, terwijl de systeemrespons niet achteruit gaat. Symmetric Multi-Processing (SMP) SMP-ondersteuning voor computers met meerdere processoren. compilers C compilers C++ compilers FORTRAN Een volledige C, C++, Fortran ontwikkelomgeving. Vele andere programmeertalen, te gebruiken voor onderzoek of geavanceerde ontwikkeling, zijn ook beschikbaar in de ports- en pakketcollectie. broncode De broncode van het hele systeem is beschikbaar, zodat gebruikers de volledige controle over het systeem in handen hebben. Waarom genoegen nemen met alleen het erewoord van de softwarefabrikant, als een compleet open systeem ook tot de mogelijkheden behoort? Uitgebreide online documentatie. En nog veel meer! 4.4BSD-Lite Computer Systems Research Group (CSRG) U.C. Berkeley &os; is gebaseerd op de 4.4BSD-Lite uitgave van de Computer Systems Research Group (CSRG) aan de University of California in Berkeley en borduurt voort op een lange traditie van ontwikkeling van BSD-systemen. Het &os; Project heeft duizenden uren gestoken in het afstellen van het systeem voor maximale prestaties en betrouwbaarheid in realistische en veel voorkomende situaties. Terwijl veel commerciële bedrijven blijven worstelen met het uitbrengen van besturingssystemen met dergelijke mogelijkheden, prestaties en betrouwbaarheid, kan &os; deze nu bieden! De toepassingen voor &os; worden alleen beperkt door eigen fantasie. Van software-ontwikkeling tot fabrieksautomatisering, van voorraadbeheersing tot de azimuth-correctie van een satellietantenne: als het kan met een commercieel &unix;product, dan kan het ook met &os;! &os; vaart ook wel bij de letterlijk duizenden open-source programma's, vaak van bijzonder hoge kwaliteit, die ontwikkeld zijn in onderzoekscentra, universiteiten over de hele wereld en open-source gemeenschappen, en die beschikbaar zijn voor weinig of geen geld. Ook steeds meer commerciële applicaties vinden hun weg naar &os;. Omdat ook de broncode van &os; zelf vrij beschikbaar is, kan het systeem aangepast worden voor speciale toepassingen of projecten, op manieren die meestal niet mogelijk zijn met besturingssystemen van vooraanstaande commerciële softwarehuizen. Hier zijn een aantal voorbeelden van toepassingen waar &os; voor gebruikt wordt: Internetdiensten: de robuuste TCP/IP netwerkarchitectuur die in &os; zit, maakt het een ideaal platform voor uiteenlopende Internetdiensten als: FTP servers FTP servers; webservers World Wide Webservers (standaard of beveiligd [SSL]); IPv4 en IPv6 routering firewall NAT Firewalls en NAT (IP-maskering) gateways; elektronische mail e-mail e-mail E-mail servers; USENET USENET nieuws of Bulletin Board (BBS) systemen; En meer... &os; kan eenvoudig geleerd worden op een goedkope standaard-PC, om later verder te groeien naar een professioneel Xeon-systeem met 4 processoren (of meer!) en RAID opslagsystemen als een bedrijf groeit. Onderwijs: is de lezer informaticastudent of werkzaam in een ander vakgebied dat hier mee te maken heeft? Er is geen betere manier om besturingssystemen, computerarchitecturen en netwerken te bestuderen dan de hands-on open-source ervaring die &os; kan bieden. Gratis beschikbare programma's voor CAD, wiskundige toepassingen en grafisch ontwerp maken &os; ook heel handig voor mensen wiens primaire interesse voor de computer ligt bij het voltooien van ander werk! Onderzoek: omdat de broncode van het volledige systeem beschikbaar is, vormt &os; een uitstekende basis voor het onderzoeken van besturingssystemen of andere takken in de informatica. De open natuur van &os; maakt het ook mogelijk voor groepen mensen over de hele wereld om met elkaar samen te werken, zonder dat men zich zorgen hoeft te maken over speciale licentieovereenkomsten of beperkingen op wat er besproken kan worden in open fora. router DNS Server Netwerken: nieuwe router nodig? Of een nameserver (DNS)? Een firewall om een intern netwerk te beschermen? &os; kan die ongebruikte 486 of Pentium PC die nog ergens in een hoekje ligt gemakkelijk omtoveren tot een geavanceerde router met uitgebreide pakketfilter mogelijkheden. X Window systeem XFree86 X Window systeem Accelerated-X X Window werkstation: &os; is een prima keuze als goedkope X terminal oplossing, door gebruik te maken van de gratis beschikbare X11 server. In tegenstelling tot een pure X terminal kan &os; ook applicaties lokaal draaien, wat een verlichting van de centrale server tot gevolg kan hebben. &os; heeft zelfs de mogelijkheid om schijfloos op te starten, zodat individuele werkstations nog goedkoper en makkelijker te beheren zijn. Bureaublad: de beschikbaarheid van geavanceerde bureaubladomgevingen als KDE en GNOME en kantoortoepassingen als tekstverwerkers en spreadsheet-programma's in de ports- en pakketcollectie maken van &os; een uitgebreid desktop-platform. Thuis en op het werk zorgt &os; ervoor dat er snel, efficiënt en veilig gewerkt kan worden! GNU Compiler Collection Software Ontwikkeling: bij het standaard &os;-systeem zit al een volledige verzameling van ontwikkelgereedschappen, inclusief de bekende GNU C/C++ compiler en debugger. &os; is beschikbaar in zowel broncode als binaire vorm op CD-ROM, DVD en via FTP. In staat meer informatie over het verkrijgen van &os;. Wie gebruiken &os;? gebruikers grote sites die &os; draaien &os; wordt gebruikt als platform voor apparaten en producten van vele van 's werelds grootste IT-bedrijven, waaronder: Apple Apple Cisco Cisco Juniper Juniper NetApp NetApp &os; wordt ook gebruikt om sommige van de grootste sites op het Internet te draaien, waaronder: Yahoo! Yahoo! Yandex Yandex Apache Apache Rambler Rambler Sina Sina Pair Networks Pair Networks Sony Japan Sony Japan Netcraft Netcraft NetEase NetEase Weathernews Weathernews TELEHOUSE America TELEHOUSE America en nog veel meer sites. Over het &os; Project Deze paragraaf geeft wat meer achtergrondinformatie over het project, inclusief een korte geschiedenis, projectdoelen, en het ontwikkelmodel van het project. Jordan Hubbard Bijgedragen door Een korte geschiedenis van &os; 386BSD Patchkit Hubbard, Jordan Williams, Nate Grimes, Rod &os; Project geschiedenis Het &os; Project zag het licht in het begin van 1993, gedeeltelijk als een voortzetting van de Unofficial 386BSD Patchkit door de 3 laatste coördinatoren van de patchkit: Nate Williams, Rod Grimes en ikzelf. 386BSD Het oorspronkelijke doel was om een zogenaamde 'snapshot'-uitgave te maken van 386BSD, om zo een aantal problemen op te lossen die niet op te lossen waren met het patchkit-mechanisme dat eerder gebruikt was. Sommigen kunnen zich misschien nog herinneren dat de werktitel van het project in het begin nog 386BSD 0.5 of 386BSD Interim was, refererend aan het oorspronkelijke doel. Jolitz, Bill 386BSD was het besturingssysteem van Bill Jolitz en had tot op dat moment geleden onder het feit dat er al bijna een jaar niet naar omgekeken was. Terwijl de patchkit steeds groter en onhandiger werd, was een groep mensen het er over eens dat er iets moest gebeuren en beslisten om Bill te assisteren bij het maken van een tussentijdse cleanup-snapshot. Deze plannen kwamen echter tot een plotseling einde toen Bill Jolitz besliste om zijn toestemming voor het project in te trekken, zonder dat er een alternatief werd geboden. Greenman, David Walnut Creek CD-ROM Het duurde niet lang om te beslissen dat het doel nog steeds belangrijk was, zelfs zonder de ondersteuning van Bill, dus werd de naam &os; aangenomen, naar een idee van David Greenman. De oorspronkelijke doelen werden opgesteld na het raadplegen van de gebruikers van het systeem. Toen het erop begon te lijken dat dit project misschien wel snel realiteit kon worden, werd contact opgenomen met Walnut Creek CD-ROM vanuit het oogpunt om de distributiekanalen van &os; te verbeteren voor diegenen die geen toegang hadden tot Internet. Walnut Creek CD-ROM ondersteunde niet alleen het idee om &os; op CD-ROM te distribueren, maar bood het project ook een systeem en een snelle Internetverbinding om mee te werken. Zonder Walnut Creek CD-ROM's bijna onbeperkte vertrouwen in wat op dat moment nog een compleet onbekend project was, is het onwaarschijnlijk dat &os; zo ver gekomen zou zijn, en zo snel, als het vandaag de dag is. 4.3BSD-Lite Net/2 U.C. Berkeley 386BSD Free Software Foundation De eerste CD-ROM (en algemene op het net beschikbare) distributie was &os; 1.0, uitgebracht in december 1993. Deze versie was gebaseerd op de 4.3BSD-Lite (Net/2) tape van U.C. Berkeley, met veel toevoegingen van 386BSD en de Free Software Foundation. Het werd een redelijk succes voor een eerste aanbod, en werd opgevolgd door de zeer succesvolle &os; 1.1 uitgave in mei 1994. Novell U.C. Berkeley Net/2 AT&T Rond deze tijd vormde zich nogal onverwacht een stormachtige lucht aan de horizon toen Novell en U.C. Berkeley hun langlopende rechtszaak over de legale status van de Berkeley Net/2 tape oplosten met een schikking. Een voorwaarde van deze schikking was dat U.C. Berkeley toegaf dat grote delen van Net/2 beladen code was en het eigendom van Novell, die deze code op haar beurt overgenomen had van AT&T enige tijd hiervoor. Wat Berkeley hiervoor terugkreeg was Novell's zegen over de 4.4BSD-Lite uitgave; wanneer deze uitkwam zou Novell verklaren dat geen van de code hierin eigendom van Novell was, en bestaande Net/2 gebruikers zou sterk aanbevolen worden om over te stappen naar deze nieuwe versie. Dit gold ook voor &os; en het project werd de tijd gegeven tot juli 1994 om te stoppen met het distribueren van het eigen op Net/2-gebaseerde product. De schikking liet wel toe dat nog een laatste uitgave werd uitgebracht voor de deadline en dat was &os; 1.1.5.1. &os; nam toen de enorme taak op zich om zichzelf letterlijk opnieuw uit te vinden, met als basis een volledig nieuwe en nogal incomplete verzameling van delen van 4.4BSD-Lite. De Lite uitgaven werden zo genoemd omdat Berkeley's CSRG grote delen code die nodig waren om een werkend systeem te construeren had weggelaten (om allerlei legale redenen) en omdat de Intel port van 4.4 grotendeels incompleet was. Het kostte het project tot november 1994 om deze overstap te maken. Op dat moment werd &os; 2.0 op het net en op CD-ROM (aan het einde van december) uitgebracht. Ondanks het feit dat deze uitgave nog wat ruige kanten had, werd het een groot succes en werd het gevolgd door de robuustere en makkelijker te installeren &os; 2.0.5 in juni 1995. In augustus 1996 is &os; 2.1.5 uitgebracht en deze bleek populair genoeg bij Internet service providers (ISP's) en andere commerciële gebruikers van &os; om nog een uitgave van de 2.1-STABLE tak te rechtvaardigen. Dit was &os; 2.1.7.1, uitgebracht in februari 1997. Deze uitgave markeerde het einde van de hoofdstroomontwikkeling op 2.1-STABLE; alleen beveilingsupdates en andere kritieke bugfixes werden nog op deze tak uitgevoerd (RELENG_2_1_0). &os; 2.2 werd afgesplitst van de ontwikkelingstak (-CURRENT) in november 1996 als RELENG_2_2 en de eerste volledige uitgave (2.2.1) werd uitgebracht in april 1997. Andere uitgaven van de 2.2 tak werden uitgebracht in de zomer en herfst van '97. De laatste (2.2.8) verscheen in november 1998. De eerste officiële 3.0 uitgave verscheen in oktober 1998 en was het begin van het einde voor de 2.2 tak. Er was opnieuw een afsplitsing op 20 januari 1999, wat leidde tot de 4.0-CURRENT en 3.x-STABLE takken. Vanuit 3.X-STABLE werd versie 3.1 uitgebracht op 15 februari 1999, 3.2 op 15 mei 1999, 3.3 op 16 september 1999, 3.4 op 20 december 1999 en 3.5 op 24 juni 2000. De laatste werd enkele dagen later gevolgd door een point uitgave update naar 3.5.1, om enkele net-ontdekte beveiligingsfouten in Kerberos te corrigeren. Dit was de laatste uitgave van de 3.X tak. Een nieuwe tak werd gemaakt op 13 maart 2000, de 4.X-STABLE tak. Er zijn verschillende uitgaven van deze tak gemaakt: 4.0-RELEASE werd geïntroduceerd in maart 2000, en de laatste 4.11-RELEASE verscheen in januari 2005. De langverwachte 5.0-RELEASE werd aangekondigd op 19 januari 2003. Dit resultaat van bijna drie jaar werk zette &os; stevig neer op de weg naar geavanceerde multiprocessor- en threading-ondersteuning en introduceerde nieuwe &os; ports voor de &ultrasparc; en ia64 architecturen. Deze uitgave werd gevolgd door 5.1 in juni 2003. De laatste 5.X uitgave uit de –CURRENT-tak was 5.2.1–RELEASE uit februari 2004. De RELENG_5 tak is gemaakt in augustus 2004 en werd gevolgd door 5.3-RELEASE, die het begin van de 5-STABLE tak markeert. De meest recente 5.5-RELEASE is uitgekomen in mei 2006. Er staan geen nieuwe versies gepland voor de RELENG_5 tak. De RELENG_6 tak is gemaakt in juli 2005, de eerste uitgave van de 6.X tak werd vrijgegeven in november 2005. De meest - recente &rel2.current;-RELEASE kwam uit op &rel2.current.date;. - Er zullen geen verdere uitgaven komen van de 6.X tak. + recente 6.4-RELEASE kwam uit in november 2008. + Er zullen geen verdere uitgaven komen van de RELENG_6 tak. De RELENG_7 tak is gemaakt in oktober 2007. De eerste uitgave van deze tak is 7.0-RELEASE, welke is uitgekomen in - februari 2008. De meest recente &rel.current;-RELEASE kwam uit - in &rel.current.date;. Er zullen nog andere uitgaven van de + februari 2008. De meest recente &rel2.current;-RELEASE kwam uit + in &rel2.current.date;. Er zullen nog andere uitgaven van de RELENG_7 tak uitkomen. + De RELENG_8 tak is gemaakt in augustus 2009. De eerste + uitgave van de 8.X tak is 8.0-RELEASE, vrijgegeven in + &rel.current.date;. + Op dit moment vinden lange-termijn ontwikkelprojecten - plaats in de 8.X-CURRENT tak, en snapshot uitgaven van 8.X op + plaats in de 9.X-CURRENT tak, en snapshot uitgaven van 9.X op CD-ROM (en natuurlijk op het Net) worden continu beschikbaar gemaakt op de snapshot server. Jordan Hubbard Bijgedragen door Doelen van het &os; Project &os; Project doelen Het doel van het &os; Project is om software aan te bieden die gebruikt kan worden voor iedere mogelijke toepassing, zonder beperkingen. Vele ontwikkelaars hebben een belangrijke investering in de code (en het project) zitten en vinden het niet erg om af en toe een financiële compensatie te ontvangen, maar dat is zeker geen voorwaarde. De ontwikkelaars van &os; geloven dat de eerste en belangrijkste missie het aanbieden van code is, aan iedereen die het wil hebben, voor wat voor doel dan ook, zodat de code zo breed mogelijk gebruikt kan worden tot voordeel van zoveel mogelijk mensen. Dit is een van de meest fundamentele doelen van Vrije Software dat &os; enthousiast ondersteunt. GNU General Public License (GPL) GNU Lesser General Public License (LGPL) BSD Copyright Sommige code in &os; valt onder de GNU General Public License (GPL) of Library General Public License (LGPL). Deze code heeft iets meer beperkingen, maar in ieder geval aan de kant waarbij vrije toegang tot de code geforceerd wordt, in plaats van het gebruikelijke tegenovergestelde hiervan. Door de toegevoegde moeilijkheden die kunnen voortkomen uit het commerciële gebruik van GPL software geeft het &os; Project echter de voorkeur aan het meer vrije BSD copyright, wanneer er een redelijk alternatief voor handen is. Satoshi Asami Bijgedragen door Het &os; ontwikkelmodel &os; Project ontwikkelmodel De ontwikkeling van &os; is een erg open en flexibel proces en wordt gevormd door de bijdragen van letterlijk honderden mensen over de hele wereld, zoals te zien is in de lijst van medewerkers. De infrastructuur die wordt gebruikt voor de ontwikkeling van &os; zorgt ervoor dat deze honderden ontwikkelaars kunnen samenwerken over het Internet. Het &os; Project is continu op zoek naar nieuwe ontwikkelaars en ideeën. Om bij te dragen aan de ontwikkeling van &os; is een mail naar &a.hackers; voldoende. De &a.announce; is beschikbaar om mededelingen te doen aan andere &os;-gebruikers over grote veranderingen. Een aantal dingen over het &os; Project en haar ontwikkelingsproces zijn handig om te weten, of een bijdrage nu onafhankelijk of in samenwerking met anderen komt: Het CVS-archief CVS archief Concurrent Versions System CVS SVN archief Subversion SVN Gedurende een aantal jaren werd de centrale broncode voor &os; bijgehouden door CVS (Concurrent Versions System), een vrij verkrijgbaar pakket voor het onderhouden van broncode dat bij &os; zit. In juni 2008 is het Project SVN (Subversion) gaan gebruiken. Deze overgang werd nodig geacht omdat de technische beperkingen die door CVS worden opgelegd duidelijk werden wegens de snelle uitbreiding van de broncode en de hoeveelheid geschiedenis die reeds is opgeslagen. Hoewel het hoofdarchief nu SVN gebruikt, blijven cliëntgereedschappen zoals CVSup en csup die van de oudere CVS-infrastructuur afhankelijk zijn normaal werken — veranderingen in het SVN-archief worden voor dit doel teruggeplaatst naar CVS. Momenteel wordt alleen de centrale broncode beheerst door SVN. De documentatie, World Wide Web, en Ports-archieven gebruiken nog steeds CVS. Het primaire archief staat op een systeem in Santa Clara, Californië, in de VS, waar het wordt gesynchroniseerd met verschillende mirrors over de hele wereld. De boomstructuur van SVN , waarin de broncode voor -CURRENT en -STABLE is te vinden, kan ook makkelijk met die op een eigen systeem gesynchroniseerd worden. Synchroniseren van broncode bevat meer informatie over dit onderwerp. Committers committers De zogenaamde committers zijn alle mensen die schrijf-rechten hebben in het CVS archief van &os;. Deze mensen mogen veranderingen maken aan de &os; broncode (de term committer is afkomstig uit het &man.cvs.1; commit commando, wat gebruikt wordt om veranderingen door te voeren in het CVS-archief). De beste manier om eigen bijdragen te laten keuren door een van de committers is door gebruik te maken van &man.send-pr.1;. Als het erop lijkt dat een bijdrage ergens in het systeem blijft hangen, dan is het ook mogelijk om mail te sturen naar de &a.committers;. Het &os; Core Team core team Het &os; core team zou het equivalent zijn van een raad van bestuur als het &os; Project een bedrijf zou zijn. De primaire taak van het core team is ervoor zorg te dragen dat het project, in zijn geheel, in goede vorm verkeert en de goede richting opgaat. Toegewijde en verantwoordelijke ontwikkelaars uitnodigen om deel te worden van de committers is één van de taken van het core team, net als het rekruteren van nieuwe leden van het core team. Het huidige core team is gekozen door de committers uit een groep van kandidaten (ook allen committers) in juli 2008. Elke twee jaar worden verkiezingen gehouden. Sommige leden van het core team hebben een bijzondere verantwoordelijkheid, wat wil zeggen dat zij er speciaal op toezien dat een bepaald deel van het systeem werkt zoals het hoort. In de lijst van medewerkers staat een complete lijst van ontwikkelaars en hun verantwoordelijkheden. De meeste leden van het core team zijn vrijwilligers. Toewijding betekent dus niet gegarandeerde ondersteuning. De raad van bestuur-analogie hierboven klopt niet helemaal en het is misschien beter om te zeggen dat dit de mensen zijn die hun leven opgaven voor &os;, tegen beter weten in! Externe Bijdragen externe bijdragen De grootste groep ontwikkelaars zijn de gebruikers zelf, die &os; continu voorzien van constructief commentaar en oplossingen voor fouten. De handigste manier om contact te houden met het niet-gecentraliseerde deel van de ontwikkeling van &os; is een abonnement nemen op de &a.hackers;, waar allerlei bijdragen, patches en nieuwe ideeën worden bediscussieerd. In is meer informatie te vinden over de verschillende &os; mailinglijsten. De lijst van medewerkers is lang en groeit iedere dag, dus wat let de lezer om zelf een bijdrage te doen aan &os;? Programmeren is niet de enige manier om een bijdrage te leveren aan het project. Een meer volledige lijst van dingen die gedaan moeten worden staat op de &os; website. Samengevat is het &os; ontwikkelmodel georganiseerd als een onsamenhangende verzameling van concentrische cirkels. Het gecentraliseerde model is ontworpen voor het gemak van de gebruikers van &os;, die op deze manier makkelijk de wijzigingen in het project kunnen volgen. Niet om potentiële medewerkers buiten de deur te houden! Het is wenselijk om een stabiel besturingssysteem te maken, met een grote verzameling samenhangende applicaties. Dit model heeft zijn waarde op dat gebied bewezen. Om bij te dragen en samen &os; verder te ontwikkelen, is het enige wat het &os; Project vraagt dat te doen met dezelfde toewijding als de huidige ontwikkelaars: succes gegarandeerd! Huidige &os; uitgave NetBSD OpenBSD 386BSD Free Software Foundation U.C. Berkeley Computer Systems Research Group (CSRG) &os; is een open source, op 4.4BSD-Lite gebaseerd besturingssysteem voor Intel (x86 en &itanium;), AMD64, Alpha en Sun &ultrasparc; computers. Het is grotendeels gebaseerd op software van de Computer Systems Research Group (CSRG) van de University of California in Berkeley (U.C. Berkeley), met verbeteringen overgenomen van NetBSD, OpenBSD, 386BSD en de Free Software Foundation. Sinds het uitbrengen van &os; 2.0 tegen het einde van 1994, zijn de prestaties, mogelijkheden en stabiliteit van &os; dramatisch verbeterd. &os; heeft namelijk de beschikking over een compleet nieuw subsysteem voor virtueel geheugen, dat niet alleen de prestaties ten goede komt, maar er ook voor zorgt dat het systeem minder geheugen gebruikt dan ooit tevoren. Andere belangrijke verbeteringen zijn de ondersteuning van veel nieuwe hardware, een compleet nieuw systeem voor de ondersteuning van machines met meerdere processoren (SMP) en een nieuwe bibliotheek voor de ondersteuning van multithreading in applicaties. Behalve de basisdistributie van het besturingssysteem, biedt &os; ook een enorme softwarecollectie met duizenden veelgebruikte programma's, de zogenaamde ports. Op het moment van schrijven zijn er al meer dan &os.numports; ports! In de ports zitten alle mogelijke klassen van software die te bedenken zijn, van HTTP-servers tot spellen, van kantoorapplicaties tot multimedia en alles wat er tussenin zit. De complete Portscollectie beslaat zo'n &ports.size; aan schijfruimte. Meer informatie over de ports en over de pakketten is te vinden in . Een aantal andere documenten die kunnen helpen bij het installeren en gebruiken van &os; staan in de map /usr/share/doc op ieder recente &os;-installatie. De lokaal geïnstalleerde documentatie kan in een browser bekeken worden door de volgende URLs te gebruiken: Het &os; handboek /usr/share/doc/handbook/index.html De &os; FAQ /usr/share/doc/faq/index.html De nieuwste versies van deze documenten zijn altijd te vinden op . diff --git a/nl_NL.ISO8859-1/books/handbook/jails/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/jails/chapter.sgml index 06368ce06d..bfe5f3ec20 100644 --- a/nl_NL.ISO8859-1/books/handbook/jails/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/jails/chapter.sgml @@ -1,1051 +1,1049 @@ Matteo Riondato Bijgedragen door Remko Lodder Vertaald door Jails jails Overzicht Dit hoofdstuk levert een uitleg van wat &os; jails zijn en hoe ze gebruikt kunnen worden. Jails, soms ook wel bekend als een verbeterde vervanging van chroot omgevingen, zijn een erg krachtige tool voor systeem beheerders, maar het standaard gedrag kan ook interessant zijn voor gevorderde gebruikers. Na het lezen van dit hoofdstuk weet de lezer: Wat een jail is, en welk doel het kan dienen in een &os; installatie. Hoe men een jail opbouwt, start en stopt. De basis over jail beheer, zowel van binnen in de jail, als van buitenaf. Andere bronnen met nuttige informatie over jails zijn: De &man.jail.8; handleiding. Hier kan de volledige referentie gevonden worden van het jail commando — de administratieve tool die in &os; gebruikt kan worden om &os; jails mee te beheren, te starten en te stoppen. De mailinglijsten en de archieven hiervan. De archieven van de &a.questions; en andere mailing lijsten die gehost worden door de &a.mailman.lists; bevatten reeds een rijke bron van informatie over jails. Het zou altijd aantrekkelijk moeten zijn om informatie in de archieven te zoeken, of een nieuwe vraag stellen aan de &a.questions.name; mailinglijst. Termen en begrippen van jails Om een beter begrip te geven over de onderdelen van &os; die gerelateerd zijn aan jails, de werking ervan, en hoe ze omgaan met de rest van &os; worden de volgende termen gebruikt in het hoofdstuk: &man.chroot.8; (commando) Hulpmiddel dat de systeemaanroep &man.chroot.2; van &os; gebruikt om de rootmap van een proces en alle afstammelingen te veranderen. &man.chroot.2; (omgeving) Een omgeving van processen die draaien in een chroot. Dit is inclusief bronnen die gebruikt worden, zoals bijvoorbeeld het gedeelte van het bestandssysteem dat zichtbaar is, de gebruiker en groep ID's welke beschikbaar zijn, netwerkkaarten en andere IPC mechanismes, etc. &man.jail.8; (commando) De systeem utility die het mogelijk maakt om processen binnenin een jail te starten. host (systeem, processen, gebruiker, etc.) Het controlerende systeem van een jail omgeving. Het host systeem heeft toegang tot alle beschikbare hardware bronnen en kan processen controleren zowel buiten als binnenin een jail. Één van de belangrijkste verschillen van het host systeem met een jail zijn de limitaties die van toepassing zijn op super-gebruiker processen binnenin een jail, niet geforceerd worden voor processen in het host systeem. hosted (systeem, processen, gebruiker, etc.) Een proces, gebruiker, of andere entiteit wiens toegang tot bronnen is gelimiteerd door een &os; jail. Introductie Omdat systeem beheer een complexe en enorme taak is, zijn er vele sterke tools ontwikkeld om het leven van een systeem beheerder makkelijker te maken. Deze tools leveren meestal verbeteringen op de manier waarop systemen worden geïnstalleerd, geconfigureerd en onderhouden. Een deel van de taken waarvan verwacht wordt dat die uitgevoerd wordt door de systeem beheerder is het goed configureren van de beveiliging van een systeem, zodat het kan blijven doorgaan met het serveren van de taak, zonder dat er beveiligings problemen optreden. Één van de tools welke gebruikt kan worden om de beveiliging van een &os; systeem te verbeteren zijn jails. Jails zijn geintroduceerd in &os; 4.X door &a.phk;, maar zijn grotendeels verbeterd in &os; 5.X om ze nog sterker en krachtiger te maken. De ontwikkeling gaat nog steeds door met verbeteringen voor het gebruik, performance, betrouwbaarheid en beveiliging. Wat is een jail BSD achtige systemen hebben sinds 4.2-BSD ondersteuning voor &man.chroot.2;. De &man.chroot.8; utility kan gebruikt worden om de root directory van een set processen te wijzigen waardoor een veilige omgeving wordt gecreeërd voor de rest van het systeem. Processen die gemaakt worden in een chroot omgeving kunnen bestanden en bronnen daarbuiten niet benaderen. Daardoor zou een compromitering van een dienst die in een chroot omgeving draait niet direct betekenen dat het hele systeem gecompromiteerd is. De &man.chroot.8; utility is goed genoeg voor simpele taken, waarbij flexibiliteit en geavanceerde en complexe opties niet nodig zijn. Sinds het uitvinden van het chroot concept, zijn er vele mogelijkheden gevonden om hieruit te kunnen komen en alhoewel ze verbeterd zijn in moderne versies van &os;, werd het duidelijk dat &man.chroot.2; niet de meest ideale oplossing was voor het beveiligen van diensten. Er moest een nieuw subsysteem ontwikkeld worden. Dit is één van de redenen waarom jails zijn ontwikkeld. Jails zijn een verbeterd concept van de &man.chroot.2; omgeving, in verschillende opzichten. In een traditionele &man.chroot.2; omgeving worden processen alleen gelimiteerd in het deel van het bestandssysteem die ze kunnen benaderen. De rest van de systeem bronnen (zoals de set van systeem gebruikers, de draaiende processen of het netwerk subsysteem) worden gedeeld door het chrooted proces en de processen op het host systeem. Jails breiden dit model uit door het niet alleen virtualizeren van de toegang tot het bestandssysteem maar ook tot de set van gebruikers, het netwerk subsysteem van de &os; kernel en een aantal andere delen. Een meer complete set van gespecificeerde controle mogelijkheden die beschikbaar zijn voor het personaliseren van de toegang tot een jail omgeving wordt beschreven in . Een jail heeft vier kenmerken: Een eigen directory structuur — het startpunt van waaruit een jail benaderd wordt. Zodra men in de jail zit, mogen processen niet buiten deze directory structuur komen. Traditionele problemen die &man.chroot.2;'s ontwerp getart hebben, hebben geen invloed op &os; jails. Een hostname — de hostnaam die gebruikt wordt in de jail. Jails worden met name gebruikt voor het hosten van netwerk diensten, daardoor kan het de systeembeheerder heel erg helpen als er beschrijvende hostnames worden gekozen. Een IP adres — deze wordt gekoppeld aan de jail en kan op geen enkele manier worden gewijzigd tijdens het leven van de jail. Het IP adres van een jail is meestal een alias op een reeds bestaande netwerk interface, maar dit is niet noodzakelijk. Een commando — het padnaam van een uitvoerbaar bestand in de jail. Deze is relatief aan de rootdirectory van de jail omgeving en verschilt per situatie, afhankelijk van het type van de specifieke jail omgeving. Buiten deze kenmerken, kunnen jails hun eigen set aan gebruikers en root gebruiker hebben. Uiteraard zijn de mogelijkheden van de root gebruiker beperkt tot de jail omgeving en, vanuit het host systeem gezien, is de root gebruiker geen super-gebruiker. Daarnaast is het de root gebruiker in een jail omgeving niet toegestaan om kritieke operaties uit te voeren op het systeem buiten de gedefinieerde jail omgeving. Meer informatie over de mogelijkheden en beperkingen van de root gebruiker kan gevonden worden in hieronder. Creeëren en controleren van jails Sommige beheerders kiezen ervoor om jails op te delen in de volgende twee types: complete jails, welke een volledig &os; systeem emuleert en service jails, gericht op één applicatie of dienst, mogelijkerwijs draaiende met privileges. Dit is alleen een conceptuele splitsing, de manier van het opbouwen van een jail wordt hierdoor niet veranderd. De &man.jail.8; handleiding is heel duidelijk over de procedure voor het maken van een jail: &prompt.root; setenv D /here/is/the/jail &prompt.root; mkdir -p $D &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make installworld DESTDIR=$D -&prompt.root; cd etc/ Deze stap -s niet benodigd onder &os; 6.0 en later. &prompt.root; make distribution DESTDIR=$D &prompt.root; mount -t devfs devfs $D/dev Het selecteren van een locatie voor een jail is het beste beginpunt. Hier zal de jail fysiek te vinden zijn binnen het bestandssysteem van het host systeem. Een goede keuze kan zijn /usr/jailjailnaam, waar jailnaam de naam is van de jail. Het /usr bestandssysteem heeft meestal genoeg ruimte voor het jail bestandssysteem, wat voor een complete jail betekend dat het eigenlijk een replica is van elk bestand dat standaard aanwezig is binnen het &os; basissysteem. Als u uw userland al heeft herbouwd met make world of make buildworld, dan kunt u deze stap overslaan en uw bestaande userland in de nieuwe jail installeren. Dit commando zal de gekozen fysieke directory vullen met de benodigde binaire bestanden, bibliotheken, handleidingen, etc. Het distribution doel voor make installeert elk benodigd configuratie bestand. In simpelere termen, het installeert alle installeerbare bestanden in /usr/src/etc naar de /etc directory van de jail omgeving: $D/etc. Het koppelen van het &man.devfs.8; bestandssysteem is niet vereist in een jail. Aan de andere kant, vrijwel elke applicatie heeft toegang nodig tot minstens één apparaat, afhankelijk van het doel van het programma. Het is erg belangrijk om toegang tot apparaten te controleren binnenin een jail, omdat incorrecte instellingen een aanvaller de mogelijkheid kunnen geven om vervelende dingen in de jail te doen. De controle over &man.devfs.8; wordt gedaan door middel van rulesets, welke beschreven worden in de &man.devfs.8; en &man.devfs.conf.5; handleidingen. Zodra een jail is geïnstalleerd, kan het opgestart worden door de &man.jail.8; applicatie. De &man.jail.8; applicatie heeft vier benodigde argumenten welke beschreven worden in . Er kunnen ook andere argumenten gebruikt worden, om bijvoorbeeld de jail te starten met de instellingen van een specifieke gebruiker. Het argument hangt af van het type jail, voor een virtueel systeem is /etc/rc een goede keuze, omdat het de reguliere opstart procedure nabootst van een &os; systeem. Voor een dienst jail is het geheel afhankelijk van de dienst of applicatie die in de jail gaat draaien. Jails worden over het algemeen gestart tegelijkertijd met de rest van het systeem. Het &os; rc mechanisme levert een makkelijke manier om dat te doen: Een lijst van jails die opgestart moeten worden tijdens het opstarten van het systeem, moeten worden toegevoegd aan het &man.rc.conf.5; bestand: jail_enable="YES" # Stel dit in op NO om te voorkomen dat er jails gestart worden jail_list="www" # Door spaties gescheiden lijst van jails Voor elke jail die gespecificeerd is in jail_list moet een groep van &man.rc.conf.5; instellingen worden toegevoegd: jail_www_rootdir="/usr/jail/www" # de hoofd directory van de jail jail_www_hostname="www.example.org" # de hostnaam van de jail jail_www_ip="192.168.0.10" # het IP adres van de jail jail_www_devfs_enable="YES" # moet devfs wel of niet gekoppeld worden in de jail jail_www_devfs_ruleset="www_ruleset" # welke devfs ruleset gebruikt moet worden voor de jail De standaard opstart variabelen in &man.rc.conf.5; gebruiken het /etc/rc bestand om de jail op te starten, wat er vanuit gaat dat de jail een compleet virtueel systeem is. Voor service jails moet het standaard opstart commando worden gewijzigd door het aanpassen van de jail_jailname_exec_start optie. Voor een complete lijst van beschikbare opties, zie de &man.rc.conf.5; handleiding. Het /etc/rc.d/jail bestand kan worden gebruikt om jails handmatig te starten en te stoppen, mits er een overeenkomstige set regels bestaat in /etc/rc.conf. &prompt.root; /etc/rc.d/jail start www &prompt.root; /etc/rc.d/jail stop www Er is op dit moment geen nette methode om een jail te stoppen. Dit komt omdat de benodigde applicaties die een nette afsluiting verzorgen, niet beschikbaar zijn in een jail. De beste manier om een jail af te sluiten is door het volgende commando van binnenin de jail uit te voeren of door middel van het &man.jexec.8; commando: &prompt.root; sh /etc/rc.shutdown Meer informatie hierover kan gevonden worden in de &man.jail.8; handleiding. Optimaliseren en administratie Er zijn meerdere opties beschikbaar die ingesteld kunnen worden voor elke jail, en er zijn meerdere mogelijkheden om een &os; host systeem te combineren met jails om een betere scheiding tussen systeem en applicaties te verkrijgen. Deze sectie leert: Een aantal opties zijn beschikbaar voor het optimaliseren van het gedrag en beveiligings beperkingen die geïmplementeerd worden in een jail. Een aantal high-level applicaties die gebruikt worden voor het beheren van jails, welke beschikbaar zijn via de &os; Ports Collectie en kunnen gebruikt worden om een complete jail-gebaseerde oplossing te creeëren. Systeem applicaties voor het optimaliseren van jails onder &os; Het goed kunnen optimaliseren van een jail configuratie wordt veelal gedaan door het instellen van &man.sysctl.8; variabelen. Er bestaat een speciale subtak van sysctl voor het organiseren van alle relevante opties: de security.jail.* hierarchie binnen de &os; kernel. Hieronder staat een lijst van de belangrijkste jail-gerelateerde sysctl variabelen, met informatie over de standaard waarden. De benaming zou zelf beschrijvend moeten zijn, maar voor meer informatie kunnen de &man.jail.8; en &man.sysctl.8; handleidingen geraadpleegd worden. security.jail.set_hostname_allowed: 1 security.jail.socket_unixiproute_only: 1 security.jail.sysvipc_allowed: 1 security.jail.enforce_statfs: 2 security.jail.allow_raw_sockets: 0 security.jail.chflags_allowed: 0 security.jail.jailed: 0 Deze variabelen kunnen door de systeem beheerder gebruikt worden op het host systeem om limitaties toe te voegen of te verwijderen, welke standaard opgedwongen worden aan de root gebruiker. Let op, een aantal beperkingen kan niet worden aangepast. De root gebruiker mag geen bestandssystemen koppelen of ontkoppelen binnenin een &man.jail.8;. De root gebruiker mag ook geen &man.devfs.8; rulesets laden of ontladen, firewall rules plaatsen of andere taken uitvoeren die vereisen dat de in-kernel data wordt aangepast, zoals het aanpassen van de securelevel variabele in de kernel. Het basis systeem van &os; bevat een basis set van applicaties voor het inzien van de actieve jails, en voor het uitvoeren van administratieve commando's in een jail. De &man.jls.8; en &man.jexec.8; commando's zijn onderdeel van het basis systeem en kunnen gebruikt worden voor het uitvoeren van de volgende simpele taken: Het printen van een lijst van actieve jails met het corresponderende jail ID (JID), IP adres, de hostnaam en het pad. Het koppelen met een actieve jail vanuit het host systeem, en voor het uitvoeren van administratieve taken in de jail zelf. Dit is bijzonder handig wanneer de root gebruiker een jail netjes wilt afsluiten. Het &man.jexec.8; commando kan ook gebruikt worden om een shell te starten in een jail om daarmee administratieve taken uit te voeren; bijvoorbeeld met: &prompt.root; jexec 1 tcsh High-Level administratieve applicaties in de &os; Ports Collection. Tussen de vele software van derde partijen voor jail beheer, is één van de meest complete en bruikbare paketten: sysutils/jailutils. Dit is een set van kleine applicaties, die bijdragen aan &man.jail.8; beheer. Kijk op de web pagina voor meer informatie. Toepassing van jails Daniel Gerzo Bijgedragen door Dienst jails Deze sectie is gebaseerd op een idee van &a.simon; op , en een geupdate artikel door Ken Tom locals@gmail.com. Deze sectie illusteert hoe een &os; systeem opgezet kan worden met een extra laag beveiliging door gebruik te maken van &man.jail.8;. Er wordt vanuit gegaan dat het betrokken systeem minstens RELENG_6_0 draait en dat de informatie eerder in dit hoofdstuk goed begrepen is. Ontwerp Één van de grootste problemen met jails is het beheer van het upgrade proces. Dit is meestal een probleem omdat elke jail vanaf het begin af aan moet worden opgebouwd wanneer er geupdate wordt. Meestal is dit voor een enkele jail geen probleem, omdat het update proces redelijk simpel is, maar het kan een vervelende tijdrovende klus zijn als er meerdere jails zijn. Deze opstelling vereist uitgebreide kennis en ervaring van &os; en zijn mogelijkheden. Als onderstaande stappen te lastig lijken te zijn, wordt aangeraden om een simpeler systeem te bekijken zoals sysutils/ezjail, welke een simpele manier geeft voor het beheren van &os; jails en niet zo complex is als deze opstelling. Het idee werd geopperd om zulke problemen zoveel als mogelijk te voorkomen door zoveel als mogelijk te delen tussen de verschillende jails op een zo veilig mogelijke manier — door gebruik te maken van alleen-lezen &man.mount.nullfs.8; koppelingen, zodat het upgraden simpeler wordt en het inzetten van jails voor enkele diensten interessanter wordt. Daarnaast geeft het een simpele manier om nieuwe jails toe te voegen of te verwijderen en om deze te upgraden. Voorbeelden binnen deze context zijn: een HTTP server, een DNS server, een SMTP server enzovoorts. De doelen van de opstelling zoals beschreven in dit hoofdstuk zijn: Het creeëren van een simpele en makkelijk te begrijpen jail structuur. Dit impliceert dat er niet elke keer een volledige installworld gedraaid hoeft te worden voor elke jail. Het makkelijk maken van het aanmaken en verwijderen van jails. Het makkelijk maken van het updaten en upgraden van bestaande jails. Het mogelijk maken van het draaien van een eigen gemaakte &os; tak. Paranoia zijn over beveiliging, zoveel mogelijk beperken, om de kans op inbraak zo klein mogelijk te maken. Het zoveel mogelijk besparen van ruimte en inodes. Zoals reeds besproken is dit ontwerp sterk afhankelijk van het hebben van een master-template, welke alleen-lezen (beter bekend als nullfs) gekoppeld is binnen elke jail, en een beschrijfbaar apparaat per jail. Een apparaat kan hierin zijn een aparte fysieke schijf, een partitie, of een door vnodes ondersteunde &man.md.4; apparaat. In dit voorbeeld wordt gebruik gemaakt van lezen-schrijven nullfs koppelpunten. Het gebruikte bestandssysteem wordt beschreven door de volgende lijst: Elke jail zal gekopeld worden onder de /home/j directory. /home/j/mroot is de template voor elke jail en tevens de alleen-lezen partitie voor elke jail. Voor elke jail zal een lege directory structuur gemaakt worden, welke valt onder de /home/j directory. Elke jail heeft een /s directory, welke gekoppeld zal worden aan het beschrijfbare gedeelte van het systeem. Elke jail zal zijn eigen beschrijfbaar systeem hebben welke gebaseerd is op /home/j/skel. Elke jail ruimte (het beschrijfbare gedeelte van de jail), wordt gecreeërd in de /home/js directory. De voorbeelden gaan er vanuit dat de jails geplaatst worden in /home partitie. Dit kan uiteraard aangepast worden, maar dan moeten de voorbeelden hieronder ook worden aangepast naar de plek die gebruikt zal worden. De template creeëren Deze sectie leert welke stappen er genomen moeten worden om de master-template te maken. Deze zal het alleen-lezen gedeelte vormen van de jails. Het is altijd een goed idee om ervoor te zorgen dat het &os; systeem de laatst beschikbare -RELEASE versie draait. Zie het corresponderende hoofdstuk in het Handboek om te lezen hoe dit gedaan wordt. In het geval dat het de moeite niet is om te updaten, zal een buildworld nodig zijn voordat er verder gegaan kan worden. Daarnaast is het sysutils/cpdup pakket benodigd. Er wordt gebruik gemaakt van de&man.portsnap.8; applicatie om de &os; Ports Collectie te downloaden. Het handbook met het hoofdstuk over Portsnap, is een aanrader voor nieuwe gebruikers. Als eerste moet er een directory structuur gecreeërd worden voor het alleen-lezen bestandssysteem, welke de &os; binaries zal bevatten voor de jails. Daarna wordt het alleen-lezen bestandssysteem geïnstalleerd vanuit de &os; broncode directory in de jail template: &prompt.root; mkdir /home/j /home/j/mroot &prompt.root; cd /usr/src &prompt.root; make installworld DESTDIR=/home/j/mroot Hierna moet de &os; Ports Collectie worden voorbereid, evenals de &os; broncode directory, wat voor mergemaster vereist is: &prompt.root; cd /home/j/mroot &prompt.root; mkdir usr/ports &prompt.root; portsnap -p /home/j/mroot/usr/ports fetch extract &prompt.root; cpdup /usr/src /home/j/mroot/usr/src Nu moet er een skelet gecreeërd worden voor het bechrijfbare gedeelte van het systeem: &prompt.root; mkdir /home/j/skel /home/j/skel/home /home/j/skel/usr-X11R6 /home/j/skel/distfiles &prompt.root; mv etc /home/j/skel &prompt.root; mv usr/local /home/j/skel/usr-local &prompt.root; mv tmp /home/j/skel &prompt.root; mv var /home/j/skel &prompt.root; mv root /home/j/skel De mergemaster applictie moet gebruikt worden om de ontbrekende configuratie bestanden te installeren. Erna moeten alle overtollige directories die gecreeërd zijn door mergemaster verwijderd worden: &prompt.root; mergemaster -t /home/j/skel/var/tmp/temproot -D /home/j/skel -i &prompt.root; cd /home/j/skel &prompt.root; rm -R bin boot lib libexec mnt proc rescue sbin sys usr dev Nu moet er een symbolische link gemaakt worden tussen het beschrijfbare bestandssysteem en het alleen-lezen bestandssysteem, zorg ervoor dat de links gemaakt worden in de juiste /s directory. Als hier echte directories worden gemaakt of de directories worden op de verkeerde plak aangemaakt zal dit resulteren in een mislukte installatie: &prompt.root; cd /home/j/mroot &prompt.root; mkdir s &prompt.root; ln -s s/etc etc &prompt.root; ln -s s/home home &prompt.root; ln -s s/root root &prompt.root; ln -s ../s/usr-local usr/local &prompt.root; ln -s ../s/usr-X11R6 usr/X11R6 &prompt.root; ln -s ../../s/distfiles usr/ports/distfiles &prompt.root; ln -s s/tmp tmp &prompt.root; ln -s s/var var Als laatste stap moet er een generieke /home/j/skel/etc/make.conf gemaakt worden met de volgende inhoud: WRKDIRPREFIX?= /s/portbuild Door het gebruik van WRKDIRPREFIX op deze manier, is het mogelijk om per jail &os; ports te compileren. Onthoud dat de ports directory onderdeel is van het alleen-lezen bestandssysteem. Het eigen pad voor WRKDIRPREFIX maakt het mogelijk dat port builds gedaan worden op het beschrijfbare gedeelte van elke jail. Jails creeëren Nu we een complete &os; template hebben, kunnen we de jails opzetten en configureren in /etc/rc.conf. Dit voorbeeld demonstreert het creeëren van drie jails: NS, MAIL en WWW. Zet het volgende in /etc/fstab zodat de alleen-lezen template voor de jails en de beschrijfbare partititie beschikbaar zijn in de respectievelijke jails: /home/j/mroot /home/j/ns nullfs ro 0 0 /home/j/mroot /home/j/mail nullfs ro 0 0 /home/j/mroot /home/j/www nullfs ro 0 0 /home/js/ns /home/j/ns/s nullfs rw 0 0 /home/js/mail /home/j/mail/s nullfs rw 0 0 /home/js/www /home/j/www/s nullfs rw 0 0 Partities die gemarkeerd zijn met een 0 als passnummer worden niet gecontroleerd door &man.fsck.8; tijdens het opstarten, en partities met een dumpnummer van 0 worden niet gebackupped door &man.dump.8;. Het is niet gewenst dat fsck de nullfs koppelingen controleert of dat dump een backup maakt van de alleen-lezen nullfs koppelingen van de jails. Daarom worden ze gemarkeerd met 0 0 in de laatste twee kolommen van elke fstab regel hierboven. Configureer de jails in /etc/rc.conf: jail_enable="YES" jail_set_hostname_allow="NO" jail_list="ns mail www" jail_ns_hostname="ns.example.org" jail_ns_ip="192.168.3.17" jail_ns_rootdir="/usr/home/j/ns" jail_ns_devfs_enable="YES" jail_mail_hostname="mail.example.org" jail_mail_ip="192.168.3.18" jail_mail_rootdir="/usr/home/j/mail" jail_mail_devfs_enable="YES" jail_www_hostname="www.example.org" jail_www_ip="62.123.43.14" jail_www_rootdir="/usr/home/j/www" jail_www_devfs_enable="YES" De reden dat de jail_name_rootdir variabele verwijst naar de /usr/home directory in plaats van naar /home komt doordat het fysieke pad van de /home directory op een standaard &os; installatie verwijst naar /usr/home. De jail_name_rootdir variabele mag niet ingesteld worden op een symbolische link, omdat dan de jail weigert te starten. Gebruik het &man.realpath.1; programma om te zien welke waarde ingesteld moet worden voor deze variabele. Zie de &os;-SA-07:11.jail waarschuwing voor meer informatie. Creeër de benodigde koppelpunten voor het alleen-lezen bestandssysteem van elke jail: &prompt.root; mkdir /home/j/ns /home/j/mail /home/j/www Installeer de beschrijfbare template in elke jail. Let op het gebruik van sysutils/cpdup, wat helpt om een goede kopie te maken in elke directory: &prompt.root; mkdir /home/js &prompt.root; cpdup /home/j/skel /home/js/ns &prompt.root; cpdup /home/j/skel /home/js/mail &prompt.root; cpdup /home/j/skel /home/js/www In deze fase zijn de jails gebouwd en voorbereid om op te starten. Koppel eerst de benodigde bestandssystemen voor elke jail, en start ze vervolgens door gebruik te maken van het /etc/rc.d/jail bestand: &prompt.root; mount -a &prompt.root; /etc/rc.d/jail start De jails zouden nu gestart moeten zijn. Om te zien of ze correct gestart zijn, wordt het &man.jls.8; programma gebruikt. Het resultaat hiervan ziet er ongeveer als volgend uit: &prompt.root; jls JID IP Address Hostname Path 3 192.168.3.17 ns.example.org /home/j/ns 2 192.168.3.18 mail.example.org /home/j/mail 1 62.123.43.14 www.example.org /home/j/www Op dit moment, zou het mogelijk moeten zijn om op elke jail aan te loggen, nieuwe gebruikers toe te voegen en het configureren van daemons. De JID kolom geeft het identificatie nummer voor elke gestarte jail. Gebruik het volgende commando om administratieve commando's uit te voeren in de jail met het JID 3: &prompt.root; jexec 3 tcsh Upgraden Naarmate de tijd verstrijkt komt de noodzaak om het systeem te updaten naar een nieuwere versie van &os;, danwel vanwege een veiligheids waarschuwing danwel vanwege nieuwe mogelijkheden die geïmplementeerd zijn en nuttig zijn voor de jails. Het ontwerp van deze opzet levert een makkelijke manier voor het upgraden van jails. Daarnaast minimaliseert het de down-time, omdat de jails alleen in de allerlaatste minuut uitgeschakeld worden. Het geeft ook de mogelijkheid om terug te keren naar een oudere versie, voor het geval er problemen ontstaan. De eerste stap is het upgraden van het host systeem zelf, waarna een nieuwe alleen-lezen template gemaakt wordt in /home/j/mroot2. &prompt.root; mkdir /home/j/mroot2 &prompt.root; cd /usr/src &prompt.root; make installworld DESTDIR=/home/j/mroot2 &prompt.root; cd /home/j/mroot2 &prompt.root; cpdup /usr/src usr/src &prompt.root; mkdir s Het installworld doel creeërt een aantal onnodige directories, welke verwijderd moeten worden: &prompt.root; chflags -R 0 var &prompt.root; rm -R etc var root usr/local tmp Maak opnieuw de beschrijfbare symbolische linken voor het hoofd bestandssysteem: &prompt.root; ln -s s/etc etc &prompt.root; ln -s s/root root &prompt.root; ln -s s/home home &prompt.root; ln -s ../s/usr-local usr/local &prompt.root; ln -s ../s/usr-X11R6 usr/X11R6 &prompt.root; ln -s s/tmp tmp &prompt.root; ln -s s/var var Dit is het juiste moment om de jails te stoppen: &prompt.root; /etc/rc.d/jail stop Ontkoppel de originele bestandssystemen: &prompt.root; umount /home/j/ns/s &prompt.root; umount /home/j/ns &prompt.root; umount /home/j/mail/s &prompt.root; umount /home/j/mail &prompt.root; umount /home/j/www/s &prompt.root; umount /home/j/www Het beschrijfbare gedeelte van de jail is gekoppeld aan het alleen-lezen gedeelte (/s) en moet derhalve eerst ontkoppeld worden. Verplaatst het oude alleen-lezen systeem en vervang het door de nieuwe systeem. Het oude systeem dient als reservekopie voor het geval er iets misgaat. De naam moet het zelfde zijn als bij de installatie van het nieuwe systeem. Verplaats de &os; Ports Collectie naar het nieuwe bestandssysteem om ruimte en inodes te besparen: &prompt.root; cd /home/j &prompt.root; mv mroot mroot.20060601 &prompt.root; mv mroot2 mroot &prompt.root; mv mroot.20060601/usr/ports mroot/usr Op dit moment is het alleen-lezen gedeelte klaar, de enig overgebleven taak is nu om alle bestandssystemen opnieuw te koppelen en om de jails weer op te starten: &prompt.root; mount -a &prompt.root; /etc/rc.d/jail start Gebruik het &man.jls.8; programma om te zien of de jails correct zijn opgestart. Vergeet niet om in elke jail het mergemaster programma te starten. Ook moeten de configuratie bestanden en de rc.d scripts geupdate worden. diff --git a/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml index 6821297fe7..934a6676f3 100644 --- a/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -1,3375 +1,3380 @@ &os; verkrijgen CD-ROM en DVD uitgevers Winkelproducten in doos &os; is beschikbaar in een doos (&os; CD-ROMs, additionele software en gedrukte documentatie) bij verschillende verkopers:
CompUSA WWW:
Frys Electronics WWW:
CD-ROMs en DVD's &os; CD-ROMs en DVD's zijn te koop bij veel online winkels:
&os; Mall, Inc. 700 Harvest Park Ste F Brentwood, CA 94513 Verenigde Staten Telefoon: +1 925 240-6652 Fax: +1 925 674-0821 E–mail: info@freebsdmall.com WWW:
Dr. Hinner EDV St. Augustinus-Str. 10 D-81825 München Duitsland Telefoon: (089) 428 419 WWW:
Ikarios 22-24 rue Voltaire 92000 Nanterre Frankrijk WWW:
JMC Software Ierland Telefoon: 353 1 6291282 WWW:
The Linux Emporium Hilliard House, Lester Way Wallingford OX10 9TA Verenigd Koninkrijk Telefoon: +44 1491 837010 Fax: +44 1491 837016 WWW:
Linux+ DVD Magazine Lewartowskiego 6 Warsaw 00-190 Polen Telefoon: +48 22 860 18 18 E–mail: editors@lpmagazine.org WWW:
Linux System Labs Australia 21 Ray Drive Balwyn North VIC - 3104 Australië Telefoon: +61 3 9857 5918 Fax: +61 3 9857 8974 WWW:
LinuxCenter.Ru Galernaya Street, 55 Saint-Petersburg 190000 Rusland Telefoon: +7-812-3125208 E–mail: info@linuxcenter.ru WWW:
Distributeurs Wederverkopers die &os; CD-ROM producten willen verkopen kunnen contact opnemen met een distributeur:
Cylogistics 809B Cuesta Dr., #2149 Mountain View, CA 94040 Verenigde Staten Telefoon: +1 650 694-4949 Fax: +1 650 694-4953 E–mail: sales@cylogistics.com WWW:
Ingram Micro 1600 E. St. Andrew Place Santa Ana, CA 92705-4926 Verenigde Staten Telefoon: 1 (800) 456-8000 WWW:
Kudzu, LLC 7375 Washington Ave. S. Edina, MN 55439 Verenigde Staten Telefoon: +1 952 947-0822 Fax: +1 952 947-0876 E–mail: sales@kudzuenterprises.com
LinuxCenter.Kz Ust-Kamenogorsk Kazachstan Telefoon: +7-705-501-6001 Email: info@linuxcenter.kz WWW:
LinuxCenter.Ru Galernaya Street, 55 Sint-Petersburg 190000 Rusland Telefoon: +7-812-3125208 E–mail: info@linuxcenter.ru WWW:
Navarre Corp 7400 49th Ave South New Hope, MN 55428 Verenigde Staten Telefoon: +1 763 535-8333 Fax: +1 763 535-0341 WWW:
FTP sites De officiële broncode voor &os; is beschikbaar via anoniem toegankelijke FTP in de hele wereld via vele mirrorsites. De site heeft een goede verbinding en staat veel verbindingen toe, maar het is waarschijnlijk beter om een mirrorsite te zoeken die dichterbij is (zeker als het doel is ook een soort mirrorsite op te zetten). De &os; mirrorsites database is beter bijgewerkt dan die in het Handboek omdat die lijst uit DNS komt in plaats van een met de hand ingevoerde lijst. &os; is beschikbaar via de onderstaande anonieme FTP mirror sites. Bij het kiezen van anonieme FTP voor het verkrijgen van &os; wordt aangeraden een site die dichtbij ligt te kiezen. De mirrorsites die in de lijst staan als Primaire Mirrorsites hebben meestal het complete &os; archief (alle beschikbare versies voor alle architecturen) maar downloads zijn waarschijnlijk sneller van een site die in het land of de regio van de gebruiker staat. De regionale sites hebben de meeste recente versies voor de meest populaire architecturen, maar hebben wellicht niet het complete archief. Alle sites geven toegang via anonieme FTP, maar een aantal sites hebben ook andere toegangsmogelijkheden. De toegangsmogelijkheden voor iedere site staan tussen haakjes achter de hostnaam. &chap.mirrors.ftp.inc; BitTorrent BitTorrent De ISO-afbeeldingen voor de basis-CD's van de uitgaven zijn beschikbaar via BitTorrent. Een verzameling torrent-bestanden om de afbeeldingen binnen te halen is beschikbaar op http://torrents.freebsd.org:8080 De software voor de BitTorrent-cliënt is beschikbaar via de port net-p2p/py-bittorrent, of als voorgecompileerd pakket. Nadat de ISO-afbeelding met BitTorrent is gedownload, kan het op CD of DVD gebrand worden zoals beschreven in . Anonieme CVS <anchor id="anoncvs-intro">Inleiding CVS anoniem Anonieme CVS (of ook wel bekend als anoncvs) is een functie die beschikbaar is met de hulpprogramma's die bij &os; zitten om te synchroniseren met een elders aanwezig CVS depot. Het staat gebruikers van &os; onder andere toe om zonder bijzondere rechten alleen-lezen operaties uit te voeren op een van de officiële anoncvs servers van het &os; project. Om het te kunnen gebruiken dient de omgevingsvariabele CVSROOT zo ingesteld te worden dat hij wijst naar de gewenste anoncvs server, dient het bekende wachtwoord anoncvs bij het commando cvs login opgegeven te worden en kan daarna &man.cvs.1; gebruikt worden om het te benaderen als ieder lokaal aanwezig depot. Het commando cvs login slaat de wachtwoorden die voor aanmelden bij de CVS server op in een bestand met de naam .cvspass in de map HOME. Als dit bestand niet bestaat, is het mogelijk dat er een foutmelding wordt gegeven als cvs login de eerste keer wordt gebruikt. Dat kan opgelost worden door een leeg bestand .cvspass te maken en dan opnieuw aan te melden. Hoewel de diensten CVSup en anoncvs beiden vrijwel dezelfde functie invullen, zijn er redenen die de keuze voor de synchronisatiemethode beïnvloeden. In een notendop is CVSup veel efficiënter in het gebruik van netwerkbronnen en is het de meest geavanceerde van de twee, maar daar staat iets tegenover. Voor het gebruik van CVSup moet eerst een speciale client geïnstalleerd en ingesteld worden voordat er bits kunnen gaan stromen en dat kan dan alleen in de redelijk grote brokken die in CVSup collections heten. Anoncvs kan daarentegen gebruikt worden om alles te bekijken van een individueel bestand tot aan een specifiek programma (als ls of grep) door aan de naam van de CVS module te refereren. Ook anoncvs is alleen geschikt voor alleen-lezen operaties op het CVS depot, dus als het de bedoeling is om lokaal ontwikkelwerk en hetzelfde depot met delen uit het &os; project te combineren, dan biedt alleen CVSup daar een oplossing voor. <anchor id="anoncvs-usage">Anonieme CVS gebruiken Het instellen van &man.cvs.1; om gebruik te maken van een Anoniem CVS depot is een kwestie van het instellen van de omgevingsvariabele CVSROOT op een van de anoncvs servers van het &os; project. Op het moment van schrijven zijn de volgende servers beschikbaar: Frankrijk: :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs (pserver (wachtwoord anoncvs), ssh (geen wachtwoord) Japan: :pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs Gebruik cvs login en gebruik als wachtwoord anoncvs Taiwan: :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs (pserver (gebruik cvs login en vul een willekeurig wachtwoord in wanneer daarom gevraagd wordt), ssh (geen wachtwoord)) SSH2 HostKey: 1024 e8:3b:29:7b:ca:9f:ac:e9:45:cb:c8:17:ae:9b:eb:55 /etc/ssh/ssh_host_dsa_key.pub VS: freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs (alleen ssh - geen wachtwoord) SSH HostKey: 1024 a1:e7:46:de:fb:56:ef:05:bc:73:aa:91:09:da:f7:f4 root@sanmateo.ecn.purdue.edu SSH2 HostKey: 1024 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65 ssh_host_dsa_key.pub VS: anoncvs@anoncvs1.FreeBSD.org:/home/ncvs (alleen ssh2 - geen wachtwoord) SSH2 HostKey: 2048 4d:59:19:7b:ea:9b:76:0b:ca:ee:da:26:e2:3a:83:b8 ssh_host_dsa_key.pub Omdat met CVS vrijwel iedere versie die ooit beschikbaar is geweest uitgecheckt kan worden, is het van belang op de hoogte te zijn van de &man.cvs.1; vlag voor revisie () en welke waarden zie zoal kan aannemen in het &os; Project depot. Er zijn twee soorten labels (tags): revisielabels en taklabels (branch). Een revisielabel refereert aan een specifieke revisie. De betekenis blijft van dag tot dag gelijk. Aan de andere kant refereert een taklabel aan de laatste revisie in een bepaalde ontwikkellijn op een bepaald moment. Omdat een taklabel niet refereert aan een specifieke revisie, kan die morgen anders zijn dan vandaag. bevat revisielabels waar gebruikers in geïnteresseerd kunnen zijn. Nogmaals: deze zijn allemaal niet geldig voor de Portscollectie omdat de Portscollectie geen meerdere ontwikkel takken kent. Als een specifiek taklabel wordt aangegeven, worden als alles goed gaat, de laatste revisies uit een bepaalde ontwikkellijn ontvangen. Als er een oudere versie opgehaald moet worden, kan dat door met de vlag een datum aan te geven. In &man.cvs.1; staan meer details. Voorbeelden Hoewel het sterk wordt aangeraden eerst de hulppagina's voor &man.cvs.1; grondig door te lezen, volgen hier een aantal snelle voorbeelden die feitelijk aangeven hoe Anonieme CVS gebruikt kan worden. SSH gebruiken om de <filename>src/</filename> tree uit te checken: &prompt.user; cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co src The authenticity of host 'anoncvs.freebsd.org (128.46.156.46)' can't be established. DSA key fingerprint is 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs.freebsd.org' (DSA) to the list of known hosts. Iets uitchecken uit -CURRENT (&man.ls.1;): &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Op de prompt, voer een willekeurig wachtwoord in wachtwoord. &prompt.user; cvs co ls SSH gebruiken om de <filename>src/</filename> structuur uit te checken: &prompt.user; cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co src The authenticity of host 'anoncvs.freebsd.org (128.46.156.46)' can't be established. DSA key fingerprint is 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs.freebsd.org' (DSA) to the list of known hosts. De versie van &man.ls.1; in de 6-STABLE tak uitchecken: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Op de prompt, voer een willekeurig wachtwoord in wachtwoord. &prompt.user; cvs co -rRELENG_6 ls Een lijst wijzigingen maken (als unified diffs) voor &man.ls.1; &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Op de prompt, voer een willekeurig wachtwoord in wachtwoord. &prompt.user; cvs rdiff -u -rRELENG_5_3_0_RELEASE -rRELENG_5_4_0_RELEASE ls Uitzoeken welke modulenamen gebruikt kunnen worden: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Op de prompt, voer een willekeurig wachtwoord in wachtwoord. &prompt.user; cvs co modules &prompt.user; more modules/modules Andere bronnen De volgende bronnen kunnen bijdragen aan een beter begrip van CVS: CVS Tutorial van California Polytechnic State University. CVS Home, de CVS gemeenschap voor ontwikkeling en ondersteuning. CVSweb is de &os; Project webinterface voor CVS. CTM gebruiken CTM CTM is een methode om een map elders gesynchroniseerd te houden met een centrale. Het is ontwikkeld voor gebruik met de &os; broncode, hoewel sommigen het ook voor andere doeleinden handig vinden. Er bestaat op dit moment weinig tot geen documentatie over het proces van het maken van delta's. Voor informatie over het gebruik van CTM kan het beste contact gezocht worden met de &a.ctm-users.name; mailinglijst. Waarom <application>CTM</application> gebruiken? CTM geeft een lokale kopie van de &os; broncode. Die is in een aantal smaken beschikbaar. Of het gaat om slechts één tak of de complete CVS structuur, CTM kan het bieden. CTM is gewoon gemaakt voor actieve ontwikkelaars die met &os; werken, maar geen of een slechte Internetverbinding hebben of gewoon automatisch de laatste wijzigingen willen ontvangen. De meest actieve takken kennen op z'n hoogst drie delta's per dag. Het is het overwegen waard om ze per automatische mail te laten sturen. De grootte van de updates wordt altijd zo klein mogelijk gehouden. Meestal kleiner dan 5 K en soms (in tien procent van de gevallen) is het 10–50 K. In uitzonderlijke gevallen komt het voor dat een mail van 100 K of meer wordt gestuurd. Het is wel van belang op de hoogte te zijn van de valkuilen die een rol spelen bij het direct werken met broncode in plaats van met een voorverpakte release. Dit geldt nog meer als wordt gewerkt met de current code. Het lezen van Bijblijven met &os; wordt sterk aangeraden. Wat is er nodig om <application>CTM</application> te gebruiken? Voor het gebruik van CTM zijn twee dingen nodig: het CTM programma en de initiële delta's om de applicatie te voeden en naar een current niveau te komen. CTM is al onderdeel van &os; sinds versie 2.0 is uitgebracht en is te vinden in /usr/src/usr.sbin/ctm, als de broncode aanwezig is. De delta's voor CTM kunnen op twee manieren komen: met FTP of per e-mail. De volgende FTP sites bieden ondersteuning voor CTM: Er staan er nog meer in de paragraaf mirrors. FTP de relevante map en download het bestand README vanaf daar. Voor delta's via e-mail: Er dient een abonnement genomen te worden op een van de CTM distributielijsten. &a.ctm-cvs-cur.name; ondersteunt de complete CVS structuur. &a.ctm-src-cur.name; ondersteunt het hoofd van de ontwikkeltak. &a.ctm-src-4.name; ondersteunt de 4.X release tak, enzovoort. Om te abonneren kan geklikt worden op de bovenstaande links of via &a.mailman.lists.link; kan in een lijst geklikt worden op de lijst waarvoor waarvoor een abonnement gewenst is. De lijstpagina bevat instructies over hoe te abonneren. Na het ontvangen van CTM updates per mail, kan ctm_rmail gebruikt worden voor het uitpakken en verwerken. ctm_rmail kan zelfs direct vanuit /etc/aliases gebruikt worden om het proces volledig automatisch te laten verlopen. In de hulppagina van ctm_rmail staan meer details. Welke methode ook gebruikt wordt voor de CTM delta's, het is belangrijk een abonnement te nemen op de &a.ctm-announce.name; mailinglijst. In de toekomst worden alleen op die lijst aankondigingen gedaan over het CTM systeem. Abonneren kan door op de link hierboven te klikken en de instructies te volgen. <application>CTM</application> de eerste keer gebruiken Voordat de CTM delta's gebruikt kunnen worden, moet er een startpunt voor bepaald worden. Eerst moet bepaald worden wat er al is. Het is mogelijk te beginnen vanuit een lege map. Dan moet een initiële Empty delta gebruikt worden om een door CTM ondersteunde structuur te starten. Het is de bedoeling dat deze start delta's ooit voor het gemak op de CD-ROM komen te staan, maar dit is nog niet het geval. Omdat de structuren tientallen megabytes groot zijn, heeft het de voorkeur om al met iets te beginnen. Als er een -RELEASE CD-ROM beschikbaar is, kan de initiële broncode gekopieerd of uitgepakt worden. Dit bespaart nogal wat dataverkeer. De start delta's kunnen herkend worden aan de X die aan het nummer is toegevoegd (bijvoorbeeld src-cur.3210XEmpty.gz). De nummering achter de X komt overeen met de oorsprong van het initiële zaad. Empty is een lege map. Er wordt in het algemeen iedere honderd delta's een basistransitie voor Empty gemaakt. Die zijn trouwens groot: 70 tot 80 Megabytes gzip data is normaal voor de XEmpty delta's. Als er een delta als startpunt is gekozen, zijn ook alle delta's met hogere volgnummers nodig. <application>CTM</application> in het dagelijks leven gebruiken Om de delta's toe te passen: &prompt.root; cd /where/ever/you/want/the/stuff &prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.* CTM begrijpt delta's in gzip formaat, dus het niet nodig om eerst gunzip te gebruiken. Dat spaart diskruimte. Tenzij het zeker is van de veiligheid van het proces, doet CTM niets met de structuur. Om een delta te verifiëren kan ook de vlag gebruikt worden en dan komt CTM ook niet aan een structuur. Dan wordt alleen de integriteit van de delta gecontroleerd en of die zonder problemen op de huidige structuur kan worden toegepast. CTM kent nog meer opties die in de hulppagina's worden besproken. Meer is er niet. Iedere keer dat er een delta wordt ontvangen, moet die door CTM gehaald worden om de broncode bijgewerkt te houden. Delta's kunnen het beste niet verwijderd worden als het lastig is ze opnieuw te downloaden. Dan kunnen ze het beste bewaard worden voor het geval er eens iets gebeurt. Zelfs als er alleen floppy's beschikbaar zijn, is het wellicht verstandig die te gebruiken met fdwrite. Lokale wijzigingen behouden Een ontwikkelaar wil graag experimenteren met bestanden in de structuur en die bestanden veranderen. CTM ondersteunt lokale wijzigingen in beperkte mate: alvorens te kijken of bestand foo bestaat, zoekt het eerst naar foo.ctm. Als dat bestand bestaat, past CTM de wijzigigen daarop toe in plaats van op foo. Dit gedrag biedt een eenvoudige mogelijkheid om lokale wijzigingen bij te houden. Dat kan dus door bestanden die gewijzigd gaan worden te kopiëren naar een bestand met dezelfde naam met de toevoeging .ctm. Dan kan er vrijelijk gespeeld worden met de code, terwijl CTM het bestand .ctm bijwerkt. Andere interessante mogelijkheden van <application>CTM</application> Uitvinden wat precies wordt veranderd met bijwerken Het is mogelijk een lijst met wijzigingen te maken die CTM zou maken op het broncodedepot met de optie . Dit is nuttig als het gewenst is om een logboek bij te houden van de wijzigingen, de te wijzigen bestanden voor- of na te bewerken op welke manier dan ook, of als de gebruiker gewoon een beetje paranoïde is. Back-ups maken vóór bijwerken Soms kan het wenselijk zijn om een back-up te maken van alle bestanden die gewijzigd gaan worden door een CTM update. Met back-upt CTM alle bestanden die gewijzigd gaan worden door een CTM delta naar back–upbestand. Te wijzigen bestanden door bijwerken beperken Soms is het wenselijk de reikwijdte voor een CTM update te beperken of kan het wenselijk zijn om maar een paar bestanden bij te werken uit een aantal delta's. Een lijst met bestanden die CTM mag bewerken kan aangegeven worden met de opties en en het opgeven van regular expressions. Om bijvoorbeeld een bijgewerkte kopie van lib/libc/Makefile te maken uit de verzameling met opgeslagen CTM delta's, kan het volgende commando uitgevoerd worden: &prompt.root; cd /where/ever/you/want/to/extract/it/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* Voor ieder te wijzigen bestand in een CTM delta worden de opties en toegepast in de volgorde waarin ze op de commandoregel staan. Het bestand wordt alleen door CTM verwerkt als het passend is bevonden na het toepassen van alle parameters in en . Toekomstige plannen voor <application>CTM</application> Die zijn er: Een of andere vorm van authenticatie in het CTM systeem bouwen zodat vervalste CTM updates afgevangen kunnen worden; De opties voor CTM opruimen omdat ze verwarrend zijn geworden. Nog meer Er zijn ook delta's voor de portscollectie, maar daar is nog niet zo veel belangstelling voor. CTM mirrors CTM/&os; is op de volgende mirrorsites via anonieme FTP beschikbaar. Als voor CTM anonieme FTP wordt gebruikt, heeft het de voorkeur een site die in geografische zin dichtbij is te gebruiken. Bij problemen kan contact gezocht worden met de &a.ctm-users.name; mailinglijst. Californië, Bay Area, officiële bron Zuid-Afrika, back-upserver voor oude delta's Taiwan/R.O.C. Als er geen mirror dichtbij is of als die incompleet is, kan een zoekmachine als alltheweb gebruikt worden. CVSup gebruiken Inleiding CVSup is een softwarepakket voor het verspreiden en bijwerken van broncodestructuren vanaf een master CVS depot op een andere server. De &os; broncode wordt beheerd in een broncode depot op een centrale ontwikkelmachine in Californië. Met CVSup kunnen &os; gebruikers op eenvoudige wijze hun broncode bijwerken. CVSup gebruikt een zogenaamd pull model voor het bijwerken. In het pull-model vraagt iedere client de server om updates als die nodig zijn. De server wacht passief op een verzoek om updates van zijn clients. Alle updates worden dus op initiatief van de client gedaan. De server stuurt nooit ongevraagde updates. Gebruikers moeten de CVSup client handmatig draaien om te updaten of een cron taak instellen om op regelmatige basis bij te werken. De term CVSup, op de gegeven wijze geschreven, doelt op het complete softwarepakket. De belangrijkste componenten zijn de client cvsup, die op de machine van een gebruiker draait, en de server cvsupd, die op alle &os; mirrorsites draait. In de &os; documentatie en op de mailinglijsten zijn referenties aan sup te vinden. Sup was de voorloper van CVSup en diende hetzelfde doel. CVSup wordt op dezelfde manier gebruikt als sup en gebruikt zelfs bestanden met instellingen die ook te gebruiken zijn met sup. Sup wordt niet langer gebruikt in het &os; project omdat CVSup sneller en flexibeler is. De csup applicatie is een herschreven versie van CVSup in de C taal. Het grootste voordeel ervan is dat het sneller is en dat het niet afhankelijk is van de Modula-3 taal, dus dat hoeft niet geïnstalleerd te worden als afhankelijkheid. Sterker nog als gebruik wordt gemaakt van &os; 6.2 of later, wordt de applicatie standaard meegeleverd, oudere versies hebben dit echter niet, maar deze kunnen simpel de net/csup port installeren of een vooraf gecompileerd pakket. Als je echter complete repositories wilt schaduwen, is CVSup nog steeds noodzakelijk. Als ervoor gekozen is om csup te gebruiken, sla dan de installatie stappen voor CVSup over en vervang de referenties naar CVSup met csup terwijl de rest van het artikel gevolgd wordt. Installatie De meest eenvoudige wijze van installatie van CVSup is met het voorgecompileerde pakket net/cvsup uit de &os; pakkettencollectie. Als het gewenst is, kan CVSup ook uit de broncode gebouwd worden in net/cvsup. De net/cvsup port is afhankelijk van het Modula-3 systeem en dat kan wel even duren en er is ook nogal wat schijfruimte voor nodig om het te downloaden en te bouwen. Als CVSup gebruikt gaat worden op een machine waarop geen &xfree86; of &xorg; staat, zoals een server, dan dient de port waar geen CVSup GUI bij zit geïnstalleerd te worden: net/cvsup-without-gui. Als csup geïnstalleerd moet worden op &os; 6.1 of eerder, kan gebruik gemaakt worden van een van te voren gecompileerd net/csup pakket van de &os; pakkettencollectie, of als de voorkeur wordt gegeven aan het volledig compileren van csup, kan gebruik gemaakt worden van de net/csup port. CVSup instellingen De werking van CVSup wordt gestuurd door een bestand met instellingen met de naam supfile. Er staan een aantal supfiles als voorbeeld in de map /usr/share/examples/cvsup/. De informatie in een supfile beantwoordt de volgende vragen voor CVSup: Welke bestanden moeten ontvangen worden? Welke versies daarvan moeten ontvangen worden? Waar moeten ze vandaan komen? Waar moeten ze komen te staan? Waar moet cvsup zijn statusbestanden bijhouden? In de volgende paragrafen wordt een supfile bestand opgebouwd door achtereenvolgens alle gestelde vragen te beantwoorden. Als eerste wordt de algemene structuur van een supfile beschreven. Een supfile is een tekstbestand. Commentaar begint met een # en loopt tot het einde van de regel. Lege regels en regels die alleen commentaar bevatten worden genegeerd. Iedere regel die overblijft slaat op een groep bestanden die ontvangen moet worden. De regel begint met de naam van een collectie, een logische groep bestanden op de server. De naam van de collectie geeft de server aan welke bestanden er gestuurd moeten worden. Na de naam van de collectie komen er geen of meer velden die gescheiden worden door witruimte. Die velden beantwoorden de hierboven gestelde vragen. Er zijn twee soorten velden: vlagvelden en waardevelden. Een vlagveld bestaat uit een alleenstaand sleutelwoord, bijvoorbeeld delete of compress. Een waardeveld begint ook met een sleutelwoord, maar het sleutelwoord wordt direct (zonder witruimte) gevolgd door = en een tweede woord. release=cvs is bijvoorbeeld een waardeveld. In een supfile wordt meestal aangegeven dat er meerdere collecties ontvangen moeten worden. Het is mogelijk om een supfile te structureren door expliciet alle relevante velden aan te geven voor iedere collectie, maar dat maakt de regels in de supfile nogal lang en het is onhandig omdat de meeste velden hetzelfde zijn voor alle collecties in een supfile. CVSup biedt een systeem met standaardinstellingen om dit probleem te omzeilen. Regels die beginnen met de speciale pseudo-collectienaam *default kunnen gebruikt worden om standaarden in te stellen voor de collecties die er in de supfile achteraan komen. Een standaardwaarde kan voor individuele collecties overschreven worden door een andere waarde in de collectie zelf aan te geven. Standaarden kunnen ook middenin het bestand gewijzigd of aangevuld worden met extra *default regels. Na deze achtergronden wordt er nu een supfile samengesteld voor het ontvangen en bijwerken van de hoofd broncodestructuur van &os;-CURRENT. Welke bestanden moeten ontvangen worden? De bestanden die via CVSup beschikbaar zijn, zijn beschikbaar in groepen die collecties heten. De beschikbare collecties staan beschreven in de volgende paragraaf. In dit voorbeeld is het de bedoeling dat de hele hoofd broncodestructuur voor &os; wordt ontvangen. Daar is één grote collectie voor: src-all. De eerste stap in het maken van een supfile is het opsommen van de gewenste collecties, één per regel (in dit geval maar één regel): src-all Welke versies daarvan moeten ontvangen worden? Met CVSup kan vrijwel iedere versie van de broncode die ooit heeft bestaan opgehaald worden. Dat kan omdat de cvsupd server direct vanaf het CVS depot werkt, dat alle versies bevat. Er kan aangegeven welke ontvangen moeten worden met de waardevelden tag= en . Voorzichtigheid is geboden bij het correct aangeven van velden met tag=. Sommige labels zijn alleen geldig voor bepaalde collecties of bestanden. Als ze incorrect worden aangeven of als er een spelfout wordt gemaakt in een label, verwijdert CVSup bestanden waarvan dat waarschijnlijk niet de bedoeling is. Het label tag=. dient eigenlijk alleen gebruikt te worden voor de ports-* collecties. Het veld tag= benoemt een symbolisch label in het depot. Er zijn twee soorten labels: revisielabels en taklabels. Een revisielabel refereert aan een specifieke revisie. De betekenis blijft altijd hetzelfde. Een taklabel refereert echter aan de laatste revisie van een gegeven ontwikkellijn op een gegeven moment. Omdat een taklabel niet refereert aan een specifieke revisie, kan het morgen iets anders betekenen dan vandaag. beschrijft de meest interessante taklabels. Als er in het instellingenbestand van CVSup een label wordt aangegeven, moet dat vooraf gegaan worden door tag= (RELENG_4 zal tag=RELENG_4 worden). Voor de Portscollectie is alleen tag=. relevant. Labels dienen exact zo ingegeven te worden als ze staan beschreven. CVSup kan geen onderscheid maken tussen geldige en ongeldige labels. Als er een spelfout in een label wordt gemaakt, doet CVSup alsof er een geldig label is ingegeven dat aan geen enkel bestand refereert. Dan zal CVSup de bestaande broncode wissen. Bij het aangeven van een taklabel wordt meestal de laatste versie van de bestanden voor een bepaalde ontwikkellijn ontvangen. Om een oudere versie te ontvangen kan in het veld een datum opgegeven worden. In &man.cvsup.1; staat hoe dat werkt. Om bijvoorbeeld &os;-CURRENT te ontvangen dient het volgende aan het begin van supfile toegevoegd te worden: *default tag=. Er ontstaat een belangrijk speciaal geval als er geen velden met tag= of date= worden aangegeven. In dat geval worden de eigenlijke RCS bestanden direct uit het CVS depot van de server ontvangen in plaats van dat een bepaalde versie wordt ontvangen. Ontwikkelaars geven in het algemeen de voorkeur aan deze optie. Door zelf een kopie van de broncode op hun systeem te hebben, krijgen ze de mogelijkheid om zelf door eerdere versies van bestanden te bladeren en de geschiedenis ervan te bekijken. Dit voordeel kost wel veel schijfruimte. Waar moeten ze vandaan komen? Het veld host= wordt gebruikt om cvsup aan te geven waar de updates vandaan moeten komen. Dat kan van elke CVSup mirrorsite, hoewel er wordt aangeraden een site die geografisch dichtbij ligt te kiezen. In dit voorbeeld wordt een fictieve &os; distributiesite gebruikt, cvsup99.FreeBSD.org: *default host=cvsup99.FreeBSD.org In een werkelijke situatie dient de hostnaam gewijzigd te worden in een host die echt bestaat voordat CVSup gaat draaien. Iedere keer dat cvsup wordt gestart, kan er een andere host op de commandoregel opgegeven worden met de optie . Waar moeten ze komen te staan? Het veld prefix= geeft cvsup aan waar de ontvangen bestanden terecht moeten komen. In dit voorbeeld worden de bestanden direct in de hoofd broncodestructuur /usr/src geplaatst. De map src is al impliciet in de gekozen collecties, vandaar dat het onderstaande de juiste instelling is: *default prefix=/usr Waar moet cvsup zijn statusbestanden bijhouden? De CVSup client houdt statusbestanden bij in een map die base wordt genoemd. Die bestanden helpen CVSup efficiënter te werken door bij te houden welke updates al eerder zijn ontvangen. Hier wordt de standaard basemap gebruikt, /var/db: *default base=/var/db De bovenstaande instelling wordt standaard gebruikt als die niet wordt aangegeven in de supfile, dus hij is eigenlijk niet nodig. Als de basemap niet al bestaat, moet die gemaakt worden. De cvsup client weigert te draaien als de basemap niet bestaat. Allerlei supfile instellingen: Er is nog een regel die in een supfile moet staan: *default release=cvs delete use-rel-suffix compress release=cvs geeft de server aan dat de informatie uit het &os; hoofd CVS depot moet komen. Dat is eigenlijk altijd het geval, maar er zijn mogelijkheden die buiten het bereik van dit handboek vallen. delete geeft CVSup het recht om bestanden te verwijderen. Dit moet altijd aangegeven worden zodat CVSup de broncode altijd kan bijwerken. CVSup gaat voorzichtig om met het verwijderen van bestanden waar het verantwoordelijk voor is. Extra bestanden in de structuur worden met rust gelaten. use-rel-suffix is nogal geheimzinnig. Voor de nieuwsgierigen staat er meer over in &man.cvsup.1;. Anders kan het gewoon ingesteld worden zonder erover na te denken. compress schakelt het gebruikt van gzip compressie in voor het communicatiekanaal. Als de verbinding een E1 of sneller is, hoeft er geen compressie gebruikt te worden. Anders helpt het aanzienlijk. Alles combinerend: Hieronder staat de hele supfile uit het voorbeeld: *default tag=. *default host=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all Het bestand <filename>refuse</filename> Zoals hierboven al is aangegeven, gebruikt CVSup een pull methode. Dat betekent eigenlijk dat er een verbinding wordt gemaakt met de CVSup server en die zegt dan: Dit kan er van mij gedownload worden..., en dan antwoordt de client met: Oké, ik wil dit en dat en zus en zo. Met de standaardinstellingen haalt de CVSup client alle bestanden die bij een collectie en het label horen dat in het bestand met de instellingen is opgegeven. Maar dat is niet altijd wenselijk, in het bijzonder als de doc, ports of www structuren worden gesynchroniseerd. De meeste mensen kunnen geen vier of vijf talen lezen en die hebben de taalspecifieke bestanden dus niet nodig. Als de Portscollectie met CVSup wordt opgehaald, is het mogelijk om iedere collectie apart aan te geven (bijvoorbeeld ports-astrology, ports-biology, enzovoort, in plaats van eenvoudigweg ports-all). Maar omdat de doc en www structuren geen taalspecifieke collecties hebben, moet er gebruik gemaakt worden van een van de vele mooie mogelijkheden van CVSup: het bestand refuse. Het bestand refuse geeft CVSup in feite aan dat niet ieder bestand uit een collectie opgehaald moet worden. Het geeft dus aan dat de client bepaalde bestanden van de server moet weigeren. Het bestand refuse staat in (of kan gemaakt worden in) base/sup/. base staat ingesteld in supfile. De standaardlocatie voor base is /var/db. De standaardplaats voor refuse is dus /var/db/sup/refuse. Het bestand refuse heeft een erg eenvoudige opmaak. Het bevat de namen van de bestanden die niet gedownload mogen worden. Als een gebruiker bijvoorbeeld geen andere talen spreekt dan Engels en Nederlands, maar de Nederlandse vertaling van de documentatie hoeft niet binnengehaald te worden, dan kan het volgende in het bestand refuse gezet worden: doc/bn_* doc/da_* doc/de_* doc/el_* doc/es_* doc/fr_* doc/hu_* doc/it_* doc/ja_* doc/mn_* doc/nl_* doc/no_* doc/pl_* doc/pt_* doc/ru_* doc/sr_* doc/tr_* doc/zh_* Dit gaat zo door voor de andere talen. De volledige lijst staat in het &os; CVS depot. Met deze handige eigenschap kunnen gebruikers met langzamere verbindingen of zij die per minuut voor hun Internetverbinding betalen waardevolle tijd besparen omdat er geen bestanden meer gedownload worden die nooit gebruikt worden. Meer informatie over refuse bestanden en andere leuke mogelijkheden van CVSup staat in de handleiding. <application>CVSup</application> draaien Nu kan het bijwerken beginnen. Het commando is best wel eenvoudig: &prompt.root; cvsup supfile De supfile is de naam van het supfile bestand dat gebruikt moet worden. Aangenomen dat er X11 draait op een machine, toont cvsup een GUI venster met wat knoppen om de bekende acties uit te voeren. Het proces start na het klikken op de knop go. Omdat in dit voorbeeld de werkelijke structuur in /usr/src wordt bijgewerkt, moet het programma als root uitgevoerd worden, zodat cvsup de rechten heeft die het nodig heeft om de bestanden bij te werken. Het is voorstelbaar dat de benodigde rechten, het net gemaakte bestand met instellingen en het voor de eerste keer draaien van een programma zorgt voor wat onrust. Daarom is het mogelijk proef te draaien zonder dat er bestanden gewijzigd worden. Dat kan door ergens een lege map te maken en een extra argument mee te geven op de commandoregel: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest De opgegeven map is de bestemming voor alle bestandsupdates. CVSup bekijkt wel de bestanden in /usr/src, maar wijzigt ze niet. Alle updates belanden in /var/tmp/dest/usr/src. CVSup werkt ook de statusbestanden niet bij als het op deze wijze wordt uitgevoerd. De nieuwe versies van de bestanden worden naar de aangegeven map geschreven. Als er maar leestoegang is tot /usr/src, hoeft een gebruiker zelfs geen root te zijn bij het uitvoeren van dit experiment. Als er geen X11 draait of als het niet wenselijk is een GUI te gebruiken, dan kunnen daarvoor opties op de commandoregel meegegeven worden bij het draaien van cvsup: &prompt.root; cvsup -g -L 2 supfile De optie geeft CVSup aan dat de GUI niet gebruikt hoeft te worden. Dit gebeurt automatisch als X11 niet draait, maar anders moet het aangegeven worden. De optie geeft CVSup aan dat details getoond moeten worden over alle bestanden die bijgewerkt worden. Er zijn drie niveaus van uitvoerigheid, van tot . Standaard is het 0, wat betekent dat er geen enkel bericht wordt getoond, met uitzondering van foutmeldingen. Er zijn nog veel andere opties beschikbaar. Met cvsup -H wordt een lijst met korte uitleg getoond. Beschrijvingen met meer details staan in de handleiding. Als het bijwerken op de gewenste manier loopt, kan het regulier draaien van CVSup met &man.cron.8; ingesteld worden. Natuurlijk hoort CVSup zonder GUI te draaien als het programma vanuit de &man.cron.8; draait. <application>CVSup</application> bestandscollecties De via CVSup beschikbare bestandscollecties zijn hiërarchisch georganiseerd. Er zijn een paar grote collecties en die zijn opgedeeld in kleinere subcollecties. Het ontvangen van een collectie is hetzelfde als het ontvangen van alle subcollecties. De hiërarchische relatie tussen de collecties wordt hieronder aangegeven door het niveau van inspringen. De meest gebruikte collecties zijn src-all en ports-all. De andere collecties worden door kleine groepen mensen gebruikt voor bijzondere doeleinden en sommige mirrorsites hebben ze niet allemaal. cvs-all release=cvs Het &os; CVS hoofddepot, inclusief de cryptografische code. distrib release=cvs Bestanden die betrekking hebben op het verspreiden en spiegelen van &os;. doc-all release=cvs Broncode voor het &os; Handboek en andere documentatie, zonder de bestanden voor de &os; website. ports-all release=cvs De &os; Portscollectie. Als ports-all (het complete portssysteem) niet bijgewerkt hoeft te worden, maar enkele van de onderstaande subcollecties, dan moet altijd ook de ports-base subcollectie bijgewerkt worden! Als er iets wijzigt in de infrastructuur van de ports waar ports–base voor staat, is het vrijwel zeker dat die wijzigingen heel snel door echte ports gebruikt gaan worden. Dus als alleen de echte ports bijgewerkt worden en als die gebruik maken van nieuwe mogelijkheden, dan is de kans groot dat het bouwen daarvan foutloopt met een vage foutmelding. Het eerste dat gedaan moeten worden is ervoor zorgen dat de ports-base subcollectie is bijgewerkt. Bij het zelf bouwen van een lokale kopie van ports/INDEX moet ports-all geaccepteerd worden (de hele port structuur). Het bouwen van ports/INDEX met een gedeeltelijke structuur wordt niet ondersteund. Zie ook de FAQ. ports-accessibility release=cvs Software voor minder valide gebruikers. ports-arabic release=cvs Ondersteuning voor de Arabische taal. ports-archivers release=cvs Archiveringshulpmiddelen. ports-astro release=cvs Astronomie ports. ports-audio release=cvs Geluidsondersteuning. ports-base release=cvs De infrastructuur van de Portscollectie. Bestanden uit de mappen Mk/ en Tools/ van /usr/ports. Zie ook de belangrijke waarschuwing hierboven: deze subcollectie dient altijd bijgewerkt te worden als er een onderdeel van de &os; Portscollectie wordt bijgewerkt! ports-benchmarks release=cvs Benchmarks. ports-biology release=cvs Biologie. ports-cad release=cvs Computer aided design programma's. ports-chinese release=cvs Ondersteuning voor de Chinese taal. ports-comms release=cvs Communicatiesoftware. ports-converters release=cvs Karaktercode omzetters. ports-databases release=cvs Databases. ports-deskutils release=cvs Dingen die op een bureaublad stonden voordat computers waren uitgevonden. ports-devel release=cvs Ontwikkelhulpmiddelen. ports-dns release=cvs DNS gerelateerde software. ports-editors release=cvs Editors. ports-emulators release=cvs Emulatoren voor besturingssystemen. ports-finance release=cvs Monetaire, financiële en gerelateerde applicaties. ports-ftp release=cvs FTP client en server programma's. ports-games release=cvs Spelletjes. ports-german release=cvs Ondersteuning voor de Duitse taal. ports-graphics release=cvs Grafische programma's. ports-hebrew release=cvs Ondersteuning voor de Hebreeuwse taal. ports-hungarian release=cvs Ondersteuning voor de Hongaarse taal. ports-irc release=cvs Internet Relay Chat hulpprogramma's. ports-japanese release=cvs Ondersteuning voor de Japanse taal. ports-java release=cvs &java; programma's. ports-korean release=cvs Ondersteuning voor de Koreaanse taal. ports-lang release=cvs Programmeertalen. ports-mail release=cvs Mailsoftware. ports-math release=cvs Numerieke rekensoftware. ports-mbone release=cvs MBone applicaties. ports-misc release=cvs Verschillende programma's. ports-multimedia release=cvs Multimedia software. ports-net release=cvs Netwerksoftware. ports-net-im release=cvs Berichtenuitwisseling. ports-net-mgmt release=cvs Netwerkbeheersoftware. ports-net-p2p release=cvs Peer to Peer Netwerken ports-news release=cvs USENET news software. ports-palm release=cvs Softwareondersteuning voor Palm apparatuur. ports-polish release=cvs Ondersteuning voor de Poolse taal. ports-ports-mgmt release=cvs Programma's om ports en pakketten te beheren. ports-portuguese release=cvs Ondersteuning voor de Portugese taal. ports-print release=cvs Printsoftware. ports-russian release=cvs Ondersteuning voor de Russische taal. ports-science release=cvs Wetenschappelijk. ports-security release=cvs Beveiligingsprogramma's. ports-shells release=cvs Commandoregelshells. ports-sysutils release=cvs Systeemprogramma's. ports-textproc release=cvs Tekstverwerkingsprogramma's (zonder desktop publishing). ports-ukrainian release=cvs Ondersteuning voor de Oekraïense taal. ports-vietnamese release=cvs Ondersteuning voor de Viëtnamese taal. ports-www release=cvs Software gerelateerd aan het Wereldwijde Web. ports-x11 release=cvs Ports voor het X windowsysteem. ports-x11-clocks release=cvs X11 klokken. ports-x11-drivers release=cvs X11-stuurprogramma's ports-x11-fm release=cvs X11 bestandsbeheerders. ports-x11-fonts release=cvs X11 lettertypen en lettertypeprogramma's. ports-x11-toolkits release=cvs X11 hulpprogramma's. ports-x11-servers release=cvs X11 servers. ports-x11-themes X11 thema's. ports-x11-wm release=cvs X11 vensterbeheerprogramma's. projects-all release=cvs Broncode's voor de &os; projecten repository. src-all release=cvs De hoofdbroncode van &os;, inclusief de cryptografische code. src-base release=cvs Verschillende bestanden bovenin de /usr/src structuur. src-bin release=cvs Gebruikersprogramma's die wellicht nodig zijn in single-user modus (/usr/src/bin). src-cddl release=cvs Programma's en bibliotheken die uitgegeven zijn onder de CDDL licentie (/usr/src/cddl). src-contrib release=cvs Programma's en bibliotheken van buiten het &os; project die vrijwel ongewijzigd gebruikt worden (/usr/src/contrib). src-crypto release=cvs Cryptografische programma's en bibliotheken van buiten het &os; project, die vrijwel ongewijzigd worden gebruikt (/usr/src/crypto). src-eBones release=cvs Kerberos en DES (/usr/src/eBones). Niet gebruikt in recente uitgaves van &os;. src-etc release=cvs Bestanden met systeeminstellingen (/usr/src/etc). src-games release=cvs Spelletjes (/usr/src/games). src-gnu release=cvs Programma's die onder de GNU Public License vallen (/usr/src/gnu). src-include release=cvs Headerbestanden (/usr/src/include). src-kerberos5 release=cvs Kerberos5 beveiligingspakket (/usr/src/kerberos5). src-kerberosIV release=cvs KerberosIV beveiligingspakket (/usr/src/kerberosIV). src-lib release=cvs Bibliotheken (/usr/src/lib). src-libexec release=cvs Systeemprogramma's die meestal door andere programma's worden uitgevoerd (/usr/src/libexec). src-release release=cvs Bestanden die nodig zijn voor het maken van een &os; release (/usr/src/release). src-release release=cvs Statisch gelinkte programma's voor nood onderhoud, zie &man.rescue.8; (/usr/src/rescue). src-sbin release=cvs Systeemprogramma's voor single-user modus (/usr/src/sbin). src-secure release=cvs Cryptografische bibliotheken en commando's (/usr/src/secure). src-share release=cvs Bestanden die tussen meerdere systemen gedeeld kunnen worden (/usr/src/share). src-sys release=cvs De kernel (/usr/src/sys). src-sys-crypto release=cvs Cryptografische kernelcode (/usr/src/sys/crypto). src-tools release=cvs Verschillende hulpprogramma's voor het onderhoud van &os; (/usr/src/tools). src-usrbin release=cvs Gebruikersprogramma's (/usr/src/usr.bin). src-usrsbin release=cvs Systeemprogramma's (/usr/src/usr.sbin). www release=cvs De broncode voor de &os; website. distrib release=self De instellingenbestanden van de CVSup server zelf. Gebruikt door de CVSup mirrorsites. gnats release=current De GNATS bug-tracking database. mail-archive release=current &os; mailinglijstarchief. www release=current De voorbewerkte &os; websitebestanden (niet de broncode). Gebruikt door WWW mirrorsites. Voor meer informatie De CVSup FAQ en andere informatie over CVSup is te vinden op De CVSup Homepage. De meeste &os;–gerelateerde discussie over CVSup vindt plaats op de &a.hackers;. Daar worden nieuwe versies van de software aangekondigd, net als op de &a.announce;. Voor vragen en foutrapporten moet een kijkje genomen worden op de CVSup FAQ CVSup sites CVSup servers voor &os; draaien op de onderstaande sites. &chap.mirrors.cvsup.inc; CVS labels Bij het ophalen of bijwerken van broncode met cvs of CVSup moet een revisielabel meegegeven worden. Een revisielabel refereert aan een specifieke lijn in de &os; ontwikkeling of aan een specifiek moment in de tijd. Het eerste type heet taklabel (branch tag) en het tweede type heet releaselabel (release tag). Taklabels Deze zijn, met uitzondering van HEAD (dat altijd een geldig label is), alleen van toepassing op de src/ structuur. De ports/, doc/ en www/ structuren kennen geen takken. HEAD Symbolische naam voor de hoofdlijn van &os;-CURRENT. Ook de standaard als geen revisie is aangegeven. In CVSup wordt dit label aangegeven met een . (dat is dus geen interpunctie, maar een echt . karakter). In CVS is dit de standaard als er geen revisielabel is aangegeven. Het is meestal geen goed idee om een checkout of update van CURRENT broncode op een STABLE machine te doen, tenzij dat expliciet de bedoeling is. RELENG_8 De ontwikkellijn voor &os;-8.X, ook bekend als &os; 8-STABLE. RELENG_8_0 De uitgavetak voor &os;-8.0, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_7 De ontwikkellijn voor &os;-7.X, ook bekend als &os; 7-STABLE. RELENG_7_2 De uitgavetak voor &os;-7.2, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_7_1 De uitgavetak voor &os;-7.1, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_7_0 De uitgavetak voor &os;-7.0, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_6 De ontwikkellijn voor &os;-6.X, ook bekend als &os; 6-STABLE. RELENG_6_4 De uitgavetak voor &os;-6.4, alleen gebruikt voor beveiligingsadviezen en andere kritieke reparaties. RELENG_6_3 De uitgavetak voor &os;-6.3, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_6_2 De releasetak voor &os;-6.2, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_6_1 De releasetak voor &os;-6.1, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_6_0 De releasetak voor &os;-6.0, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5 De ontwikkellijn voor &os;-5.X, ook bekend als &os; 5-STABLE. RELENG_5_5 De releasetak voor &os;-5.5, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5_4 De releasetak voor &os;-5.4, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5_3 De releasetak voor &os;-5.3, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5_2 De releasetak voor &os;-5.2 en &os;-5.2.1, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5_1 De releasetak voor &os;-5.1, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5_0 De releasetak voor &os;-5.0, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4 De ontwikkellijn voor &os;-4.X, ook bekend als &os; 4-STABLE. RELENG_4_11 De releasetak voor &os;-4.11, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_10 De releasetak voor &os;-4.10, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_9 De releasetak voor &os;-4.9, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_8 De releasetak voor &os;-4.8, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_7 De releasetak voor &os;-4.7, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_6 De releasetak voor &os;-4.6 en &os;-4.6.2, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_5 De releasetak voor &os;-4.5, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_4 De releasetak voor &os;-4.4, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_3 De releasetak voor &os;-4.3, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_3 De ontwikkellijn voor &os;-3.X, ook bekend als 3.X-STABLE. RELENG_2_2 De ontwikkellijn voor &os;-2.2.X, ook bekend als 2.2-STABLE. Deze tak is sterk verouderd. Releaselabels Deze labels refereren aan een specifiek moment in de tijd waarop een versie van &os; is uitgegeven. Het proces om tot een release te komen is gedetailleerder beschreven in de Release Engineering Informatie en Release Proces documenten. De src structuur gebruikt labelnamen die beginnen met RELENG_ labels. De ports en doc structuren gebruiken labels waarvan de naam begint met het label RELEASE. De www tenslotte, is niet gemarkeerd met een bijzondere naam bij releases. RELENG_7_2_0_RELEASE &os; 7.2 RELENG_7_1_0_RELEASE &os; 7.1 RELENG_7_0_0_RELEASE &os; 7.0 RELENG_6_4_0_RELEASE &os; 6.4 RELENG_6_3_0_RELEASE &os; 6.3 RELENG_6_2_0_RELEASE &os; 6.2 RELENG_6_1_0_RELEASE &os; 6.1 RELENG_6_0_0_RELEASE &os; 6.0 RELENG_5_5_0_RELEASE &os; 5.5 RELENG_5_4_0_RELEASE &os; 5.4 RELENG_4_11_0_RELEASE &os; 4.11 RELENG_5_3_0_RELEASE &os; 5.3 RELENG_4_10_0_RELEASE &os; 4.10 RELENG_5_2_1_RELEASE &os; 5.2.1 RELENG_5_2_0_RELEASE &os; 5.2 RELENG_4_9_0_RELEASE &os; 4.9 RELENG_5_1_0_RELEASE &os; 5.1 RELENG_4_8_0_RELEASE &os; 4.8 RELENG_5_0_0_RELEASE &os; 5.0 RELENG_4_7_0_RELEASE &os; 4.7 RELENG_4_6_2_RELEASE &os; 4.6.2 RELENG_4_6_1_RELEASE &os; 4.6.1 RELENG_4_6_0_RELEASE &os; 4.6 RELENG_4_5_0_RELEASE &os; 4.5 RELENG_4_4_0_RELEASE &os; 4.4 RELENG_4_3_0_RELEASE &os; 4.3 RELENG_4_2_0_RELEASE &os; 4.2 RELENG_4_1_1_RELEASE &os; 4.1.1 RELENG_4_1_0_RELEASE &os; 4.1 RELENG_4_0_0_RELEASE &os; 4.0 RELENG_3_5_0_RELEASE &os;-3.5 RELENG_3_4_0_RELEASE &os;-3.4 RELENG_3_3_0_RELEASE &os;-3.3 RELENG_3_2_0_RELEASE &os;-3.2 RELENG_3_1_0_RELEASE &os;-3.1 RELENG_3_0_0_RELEASE &os;-3.0 RELENG_2_2_8_RELEASE &os;-2.2.8 RELENG_2_2_7_RELEASE &os;-2.2.7 RELENG_2_2_6_RELEASE &os;-2.2.6 RELENG_2_2_5_RELEASE &os;-2.2.5 RELENG_2_2_2_RELEASE &os;-2.2.2 RELENG_2_2_1_RELEASE &os;-2.2.1 RELENG_2_2_0_RELEASE &os;-2.2.0 AFS sites Er draaien AFS servers voor &os; op de volgende sites: Zweden Het pad naar de bestanden is: /afs/stacken.kth.se/ftp/pub/FreeBSD/ stacken.kth.se # Stacken Computer Club, KTH, Sweden 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se Beheerder: ftp@stacken.kth.se rsync sites De volgende sites bieden &os; aan via het protocol rsync. Het programma rsync werkt vrijwel hetzelfde als &man.rcp.1;, maar kent meer mogelijkheden en gebruikt het rsync remote-update protocol, dat alleen verschillen tussen twee groepen bestanden overbrengt, waardoor het synchroniseren via een netwerk drastisch wordt versneld. Dit kan het beste gedaan worden als er een mirrorsite voor de &os; FTP server of het &os; CVS depot draait. De rsync suite is voor veel besturingssystemen beschikbaar. Voor &os; kan het pakket of de port uit net/rsync geïnstalleerd worden. Tsjechië rsync://ftp.cz.FreeBSD.org/ Beschikbare collecties: ftp: een gedeeltelijke mirror van de &os; FTP server. &os;: een volledige mirror van de &os; FTP server. Nederland rsync://ftp.nl.FreeBSD.org/ Beschikbare collecties: &os;: een volledige mirror van de &os; FTP server. Rusland - rsync://cvsup4.ru.FreeBSD.org/ + rsync://ftp.mtu.ru/ Beschikbare collecties: - FreeBSD-gnats: De GNATS bug-tracking database. + &os;: een volledige spiegel van de FTP-server van + &os;. + &os;-gnats: De GNATS bug-tracking + database. + &os;-archief: spiegel van de &os; Archive + FTP-server. Taiwan rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Beschikbare collecties: FreeBSD: een volledige mirror van de &os; FTP server. Verenigd Koninkrijk rsync://rsync.mirrorservice.org/ Beschikbare collecties: sites/ftp.freebsd.org: een volledige mirror van de &os; FTP server. Verenigde Staten van Amerika rsync://ftp-master.FreeBSD.org/ Deze server mag alleen gebruikt worden door &os; primaire mirrorsites. Beschikbare collecties: &os;: het masterarchief van de &os; FTP server. acl: de &os; master ACL lijst. rsync://ftp13.FreeBSD.org/ Beschikbare collecties: &os;: een volledige mirror van de &os; FTP server.