Jericho 2.0

Deperimeterisatie: een firewall met gaten.

Volgens het Oude testament werd stad Jericho belegerd door de Israëlieten. De stad had een robuuste stadsmuur die niet zomaar beslecht kon worden. Rond de muren van de stad werd zes dagen lang, eenmaal per dag, een ronde gelopen door de belegeraars, al blazend op de sjofar (ramshoorn). Op de zevende dag liepen de belegeraars zevenmaal rond de stad. De muren stortten in en de belegeraars kwamen probleemloos in de stad.

Vanaf de jaren ’90 werden bedrijfsnetwerken die met het internet werden verbonden, beveiligd met een firewall. Het bedrijfsnetwerk was een veilige en vertrouwde zone die door een elektronische stadsmuur werd beschermd tegen het grote boze internet. Zo’n vertrouwde zone wordt een perimeter genoemd. Ik heb dit in 2001 beschreven in een tijdschriftartikel dat ook op deze site te vinden is.

perimeter om kantoornetwerk en rekencentrum

Tot 1990: Afgesloten netwerk, geen internet

Het principe van beveiligen door het instellen van perimeters is erg handig. Je hoeft je dan niet meer druk te maken over de beveiliging van de afzonderlijke systemen, maar je kunt alles regelen in de firewall. Deze wijze van beveiligen is effectief zolang er weinig behoefte is aan interacties tussen systemen die in verschillende perimeters staan.

perimeter om kantoor- en rekencentrumnetwerk, met eigen website en verbindingen met het Internet

Jaren ’90: Perimeterbescherming

De tijd heeft intussen niet stilgestaan. Bedrijven bieden hun diensten aan via het Internet of nemen diensten af via het Internet. Medewerkers werken op uiteenlopende locaties en gebruiken laptops, tablets en smartphones om gegevens met het bedrijfsnetwerk uit te wisselen. Ook binnen het bedrijfsnetwerk is de gegevensuitwisseling tussen de verschillende bedrijfsonderdelen gevarieerder en intensiever geworden. Het gevolg is dat de firewall die het verkeer tussen perimeters zo veel mogelijk moest beperken, steeds meer moet gaan doorlaten.

Perimeter rond kantoor- en rekencentriumnetwerk wordt op veel plaatsen doorbroken

21e eeuw: Toenemende deperimeterisatie

Beveiliging en functionaliteit gaan elkaar tegenwerken. Extra functionaliteit is een directe bedreiging van de beveiliging en een adequate beveiliging gaat weer ten koste van functionaliteit. De beveiliging wordt daardoor minder effectief en je kunt er niet meer van uit gaan dat het interne netwerk gesloten en veilig is.

Dit afbrokkelen van den beveiliging van de perimeter vertoont gelijkenis met het spontaan ineenstorten van de muren van Jericho. Dit fenomeen, dat aangeduid wordt als ‘deperimeterisation’, vraagt om een aangepaste visie op informatiebeveiliging. The Open Group, een Internationaal consortium dat zich richt op het ontwikkelen en beheren van open IT-standaarden, heeft dit al vroeg onderkend en tien jaar geleden een denktank opgericht met de naam Jericho Forum.

Het Jericho Forum, inmiddels Jericho Work Group, heeft een beveiligingsconcept ontwikkeld in de vorm van 11 ‘commandments‘ (geboden). Dit beveiligingsconcept is bekend geraakt als Jericho 2.0 en kan worden samengevat als: “Beveilig de gegevens en in plaats van de perimeter.” Dit kan worden gerealiseerd met:

  • Encryptie
  • Inherent veilige protocollen
  • Inherent veilige systemen
  • Authenticatie op gegevenselement

Gebaseerd op de 11 commandments is een architectuurframework ontwikkeld genaamd Collaboration Oriented Architecture, waarover een andere keer meer.

Kleine perimeters om data-elementen en verslutelde verbindingen tussen data, kantor, externe mederwerkers, klanten en ketenpartners.

Beveiliging van gegevens en gegevensstromen beveiligd door middel van encryptie.

Jericho 2.0 gaat er van uit dat een ‘veilig intern netwerk’ een utopie is. Dit betekent dat we de systemen moeten inrichten alsof ze direct op het grote boze internet zijn aangesloten. Dat lijkt best ingrijpend, maar moderne besturingssystemen zijn goed te beveiligen.  Er zijn voldoende tools beschikbaar die het  opzetten en beheren van een veilige inherent veilige infrastructuur mogelijk maken. Ook het beveiligen van het netwerkverkeer met bijvoorbeeld SSL is best te doen. Deze manier van werken is bij internetproviders gemeengoed, maar bij de meer traditionele organisaties nog niet erg ingeburgerd.

Dit betekent niet dat we er licht over kunnen denken, of dat het allemaal makkelijk en eenvoudig is. Het vraagt wel degelijk kennis en kunde, aandacht en zorgvuldigheid. Maar de middelen en benodigde informatie zijn ruim voorhanden. Ik zal in een volgend bericht dieper ingaan op de beschikbare technieken om dit in de praktijk te brengen.

Betekent dit nu dat we de firewall bij het grof vuil moeten zetten? Integendeel, maar de firewall is niet meer de hoeksteen van de beveiliging. Het is altijd verstandig om een gelaagde beveiliging toe te passen. Defense in depth. Maar de firewall is in dit model niet meer de belangrijkste barrière maar de eerste barrière; de first line of defense.

Het goede nieuws is dat Jericho 2.0, wanneer goed toegepast, een veel flexibeler vorm van beveiliging biedt dan het oude perimetermodel. Wijzigingen in de infrastructuur die de perimeter doorkruisen zijn nu geen bedreiging meer. Locatie-onafhankelijk werken (thuiswerken e.d) is eenvoudiger geworden. Koppelingen met ketenpartners zijn veilig te realiseren.

Op deze wijze is beveiliging niet meer blokkerend maar juist faciliterend.

Beveiliging inbedden in de organisatie

Onderstaand artikel schreef ik in 2001 voor het tijdschrift Mnet. Netwerkbeveiliging was nog een betrekkelijk nieuw begrip en veel bedrijven worstelden met het toepassen ervan.

Leeswijzer: In dit artikel gebruik ik het begrip ‘perimeter’ en geef aan hoe dit kan worden gebruikt om tot een veilige netwerkarchitectuur te komen. In het huidige tijdsgewricht is perimeter-gebaseerde beveiliging niet meer toereikend. De-perimeterisatie is een gegeven en we zullen de aandacht moeten verleggen van de perimeter naar de bron. Zie het recentere bericht over Jericho 2.0.

Intro

Enige tijd geleden vroeg een klant aan mij of ik nog wel lekker sliep. Ik had voor deze klant onderhoud aan een van zijn systemen gedaan en hem op het hart gedrukt om uitsluitend nog SSH (Secure Shell) te gebruiken omdat bij gebruik van Telnet of FTP het risico bestaat dat het password onderschept wordt. De klant kende mijn stokpaardjes al en vroeg toen plagerig of ik ’s nachts nog wel lekker sliep. Hoezo? Of ik niet bang was dat mijn dromen afgetapt zouden worden….

Hoewel het belang van een goede netwerkbeveiliging door steeds meer organisaties onderkend wordt, blijft het toch zeer lastig te zijn het een goede plek in een organisatie te geven. Er blijkt vaak een grote kloof te zijn tussen diegenen die verantwoordelijk zijn voor het beveiligingsbeleid en diegenen die belast zijn met het netwerkbeheer. Ik zal in dit artikel een poging doen om die kloof wat kleiner te maken.

Een automatiseringsnetwerk is een abstracte samenhang van interacties tussen computersystemen. Een netwerk is meer dan de som van de afzonderlijke componenten. Juist de abstractie maakt het voor velen lastig om zich een goed beeld te vormen van wat zich op een netwerk afspeelt en de beveiligingsrisico’s die er zijn. Dit leidt er dikwijls toe dat in het beleid de netwerkbeveiliging minder aandacht krijgt dan de beveiliging van de afzonderlijke computersystemen.

Om een zinvolle en effectieve netwerkbeveiliging te implementeren is het noodzakelijk dat er een netwerkbeveiligingsbeleid wordt ontwikkeld dat past binnen het totale beveiligingsbeleid van de organisatie. Dit netwerkbeveiligingsbeleid is onderdeel van het informatie-beveiligingsbeleid. Om een dergelijk beleid te ontwikkelen is kennis nodig van netwerk-technologie; hoe zitten de protocollen in elkaar, wat zijn de zwakheden, welke aanvalstechnieken zijn er en wat zijn de beschikbare beschermingstechnieken. Maar er is ook kennis nodig van het algemene beveiligingsbeleid van de organisatie; wat zijn de bedrijfsprocessen, wat zijn de gevolgen wanneer deze verstoord worden, en hoeveel inspanningen willen we verrichten om de bedrijfsprocessen te beschermen. Het lastige is dat beide kennisgebieden zelden bij dezelfde persoon in de organisatie vertegenwoordigd is. Doorgaans is de kennis verdeeld over meerdere personen en vaak zal ook expertise van buiten de organisatie aangetrokken moeten worden. Daarbij komt nog dat de kennisgebieden aan continue veranderingen onderhevig zijn.

Er moet dus een dialoog opgezet worden tussen vertegenwoordigers van de beide kennisgebieden. We raken nu het oude probleem van managers en technici die elkaar maar niet willen begrijpen. Het is echter van wezenlijk belang dat geïnvesteerd wordt in wederzijds begrip. De communicatie wordt makkelijker wanneer er een zekere overlap is in de kennisgebieden. Er moet een gemeenschappelijke begrippenkader gecreëerd worden zodat het mogelijk is om bedrijfsmatige beveiligingsvraagstukken te vertalen in technische oplossingen en vice versa. In het volgende deel van dit artikel zal ik proberen een aantal begrippen aan te reiken die voor vertegenwoordigers van beide kennisgebieden bruikbaar zijn.

Gezamenlijk wordt een risico-analyse gemaakt en worden de mogelijke maatregelen besproken. Hierbij zal een kosten-baten analyse gemaakt dienen te worden. Met kosten moet ook gekeken worden naar de gebruiksinspanningen. Het resultaat hiervan behoort een netwerkbeveiligingsbeleid te zijn dat qua kosten, inspanningen, functionaliteit en effectiviteit in harmonie is met het algemene beveiligingsbeleid van de organisatie. Het is niet zinvol om veel te investeren in bewaking, toegangspasjes en tourniquets wanneer men zonder veel moeite vanaf het Internet belangrijke gegevens kan benaderen. Anderzijds is een dure firewall zinloos wanneer men zo het gebouw binnenloopt en de passwords op gele plakbriefjes naast de schermen hangen.

Bereik

Sun Microsystems gebruikte zo’n 10 jaar geleden de slogan “The network is your computer”. Deze slogan geeft goed weer waar het hier om gaat. De combinatie van de verschillende computersystemen op het eigen, en eventueel andermans, netwerk, alsmede de onderlinge interactie, voorzien in de feitelijke automatiseringsbehoefte. De verschillende componenten van onze IT infrastructuur zijn gezamenlijk te beschouwen als een grote computer. Dit betekent dat zowel de computersystemen als de onderlinge datacommunicatie onderwerp zijn van beveiliging. Bij automatiseringsprocessen waarbij systemen en netwerken van derden betrokken zijn, behoren ook deze systemen en netwerken tot het aandachtsgebied.

Aandachtsgebieden

Informatiebeveiliging kent drie aandachtsgebieden:

  • Het waarborgen van de exclusiviteit van informatie
  • Het waarborgen van de beschikbaarheid van informatie
  • Het waarborgen van de juistheid van informatie

Exclusiviteit van data is vaak het eerste waar bij informatiebeveiliging aan gedacht wordt. Men wil niet dat gevoelige bedrijfsinformatie in handen van de concurrent terecht komt. Maar men kan ook denken aan de verplichtingen die men heeft jegens derden wanneer het gaat om de bescherming van creditcard-gegevens of persoonsgegevens.

Bij de beschikbaarheid van informatie kan men denken aan het (tijdelijk) niet beschikbaar zijn van een webserver door een DoS aanval, maar nog vervelender is het wanneer bedrijfskritische gegevens permanent verloren zijn gegaan. Bedreigingen van de beschikbaarheid worden vaak onderschat. Men heeft liever dat informatie niet beschikbaar is dan dat het in verkeerde handen valt. Het uitschakelen van een informatiesysteem is echter veel eenvoudiger dan het stelen van informatie. Verstoringen van de beschikbaarheid kunnen organisaties echter veel schade berokkenen.

Bij juistheid van informatie kan men denken aan de juistheid van een banksaldo, maar men kan ook denken aan de juistheid van informatie op basis waarvan beslissingen worden genomen, of compromitterende informatie op een website. Overigens kan men, wanneer er onjuistheid in informatie is opgemerkt of wordt vermoed, spreken van het niet beschikbaar zijn van de informatie zolang niet bekend is welke gegevens gewijzigd zijn, en wat de juiste gegevens zouden moeten zijn.

In bovenstaande voorbeelden is steeds uitgegaan van de informatie waar we in onze bedrijfsprocessen uiteindelijk in geïnteresseerd zijn. We dienen de drie genoemde aandachtsgebieden echter ook toe te passen op informatie over de informatie (en informatie over de informatie over de informatie etc.). We kunnen hierbij denken aan de exclusiviteit van toegangscodes, de beschikbaarheid van logfiles waarin een mogelijke inbraakpoging is geregistreerd, en de juistheid van het IP-adres van een door ons vertrouwd systeem.

Perimeter

Tot nu toe hebben we alleen de complexiteit van netwerkbeveiliging belicht. We zullen nu proberen of we deze complexiteit kunnen reduceren. We doen dit door onze infrastructuur in te delen in zones met eenzelfde beveiligingsniveau. De begrenzing van zo’n zone noemen we een perimeter. Het beveiligingsbeleid binnen een perimeter dient eenduidig bepaald te zijn. Het is daarom belangrijk dat er slechts een entiteit is die het beleid bepaalt en er slechts een organisatie belast is met de uitvoering van dat beleid. Op plaatsen waar de perimeter overschreden wordt zullen we beveiligingsmaatregelen moeten treffen. Dit doen we doorgaans door het plaatsen van een firewall. We streven ernaar om het aantal overschrijdingen van een perimeter te reduceren tot één. Hierdoor kunnen we de beveiligingsrisico’s overzien en kunnen de maatregelen, de configuratie van de firewall, eenduidig bepaald worden. Wanneer er meer dan één plaats is waar de perimeter overschreden wordt ontstaat het gevaar dat er discrepanties ontstaan tussen de verschillende beveiligingsniveaus. We kunnen deze topologie het beste vergelijken met een kasteel met een muur en een slotgracht en een enkele poort met ophaalbrug.

De meest voorkomende implementatie is een bedrijfsnetwerk dat met een enkele firewall aan het Internet verbonden is. Zie figuur 1. Een meer complexe situatie ontstaat wanneer we een gedeelte van de eigen organisatie aan een strenger beveiligingsbeleid onderworpen is of wanneer een gedeelte van de activiteiten een ruimere toegang vereisen. We kunnen binnen een perimeter een nieuwe beveiligde zone identificeren en deze door een extra perimeter omgeven. Verkeer dat een binnenliggende perimeter binnengaat of verlaat zal gecontroleerd moeten worden. Zie figuur 2. In het plaatje zijn drie aparte firewalls getekend. In de praktijk zijn implementaties met een enkele firewall mogelijk. Waar het om gaat is dat er additionele regels zijn voor de binnenliggende perimeters. Wanneer we het voorbeeld met het kasteel erbij halen dan is deze situatie te vergelijken met een burcht, die omgeven is door een aarden wal. Buiten het kasteel, maar binnen de aarden wal wonen handwerkslieden en landarbeiders. Binnen het kasteel wonen de kasteelheer, familie en personeel. In een extra beveiligd gedeelte van het kasteel woont de jonkvrouwe.

Het komt vaak voor dat organisaties die veel onderling dataverkeer hebben een huurlijn aanleggen die beider netwerken verbindt. Er ontstaat nu een situatie als in figuur 3a. Er is een verbinding aangebracht tussen beide perimeters. Beide organisaties hebben echter ieder een eigen beveiligingsbeleid. Beide organisaties hebben een verbinding net het Internet via een firewall die geconfigureerd is volgens het eigen beveiligingsbeleid. De inzichten over beveiliging kunnen echter per organisatie enigszins verschillen. Ieder beleid kent zo zijn eigen sterke en minder sterke punten. In de hier geschetste situatie zijn de minder sterke punten van beide organisaties op beide netwerken van toepassing. Deze situatie is dus een bedreiging voor beide netwerken.

Een betere oplossing is weergegeven in 3b. Hier is de onderlinge verbinding aangebracht buiten de beide perimeters. Op ieders netwerk is het eigen beveiligingsbeleid van toepassing. Iedere partij kan nu zijn eigen beveiligingsbeleid jegens de andere partij bepalen. In gezamenlijk overleg kan worden besloten of en in welke mate het gemeenschappelijke netwerk beschermd wordt. We moeten hierbij accepteren dat deze bescherming nooit optimaal kan zijn omdat deze onderhevig is aan de nadelen die bij 3a genoemd zijn.

In het streven naar globalisering gaan veel organisaties samenwerkingsverbanden aan of slokken kleinere organisaties op. Andere organisaties laten delen min of meer zelfstandig worden. Een gevolg hieraan is dat diverse zelfstandig beheerde netwerken worden gekoppeld en er behoefte ontstaat aan intensief dataverkeer tussen deze netwerken. Het Probleem is echter dat iedere deelorganisatie haar eigen beveiligingsbeleid heeft ontwikkeld, dat gevormd is door specifieke eisen, wensen, ervaringen en kennis. Wanneer we deze netwerken zonder meer koppelen ontstaat een zelfde situatie als in 3a. Vaak zal de moederorganisatie een algemeen beveiligingsbeleid opleggen dat door de deelorganisaties dient te worden geïmplementeerd. De verantwoordelijken binnen de organisaties zullen dit opgelegde beleid op hun eigen wijze interpreteren en hebben soms hun eigen redenen om er van af te wijken. Vaak zijn er beperkingen in de netwerkstructuur die afwijkingen noodzakelijk maken of worden er fouten gemaakt bij de implementatie. Kortom het gevaar ontstaat dat tekortkomingen in de beveiliging bij een van de deelorganisaties leidt tot een bedreiging van beveiliging van de gehele organisatie.

Continuïteit

Netwerkbeveiliging is geen product maar een proces. Nieuwe technologische ontwikkelingen brengen nieuwe bedreigingen met zich mee, maar ook nieuwe beschermingstechnieken. Ook de organisatie is aan verandering onderhevig, zodat er steeds nieuwe aspecten zijn waarop de technische bedreigingen van toepassing zijn. We zullen dus continue bezig moeten zijn het proces van netwerkbeveiliging bij te sturen.

Naast het continu bijsturen is er ook een continu controle nodig. Dit kan bestaan uit het analyseren van logbestanden, het activeren van een alarmsysteem bij een eventuele aanval of het regelmatig testen van de kwaliteit van de maatregelen.

Onderzoek

Wanneer met een beveiligingsonderzoek laat uitvoeren zijn er feitelijk twee mogelijkheden:

  1. Een penetratietest:
    We laten een aantal slimme personen met minimale voorkennis de zwakke plekken in onze beveiliging opsporen en proberen zo ver mogelijk in onze infrastructuur door te dringen.
  2. Een analyse:
    We geven een aantal deskundigen volledige inzage in zowel het beleid als in de genomen maatregelen en controleren de kwaliteit van de geïmplementeerde maatregelen.

De eerste mogelijkheid spreekt het meest tot de verbeelding. Het is echter niet de meest efficiënte testmethode. Het testen zal voor reen groot deel uit bestaan uit proberen en dat kost nu eenmaal tijd. Wanneer het niet lukt om in te breken betekent dit nog niet dat de beveiliging goed is. Het kan evengoed betekenen dat niet alle mogelijkheden afgetast zijn. De kwaliteit van de test is sterk afhankelijk van de creativiteit van de uitvoerders. Wanneer een penetratietest goed wordt uitgevoerd kan het helpen bij het identificeren van zwakke plekken in de beveiligingsstrategie en kan het een bijdrage leveren aan het creëren van draagvlak voor het doorvoeren van verbeteringen in de netwerkbeveiliging.

Bij het uitvoeren van een beveiligingsanalyse kunnen zwakke plekken efficiënt worden opgespoord en kunnen aanvullende maatregelen geadviseerd worden. Belangrijker is dat de verschillende lagen waaruit de beveiliging is opgebouwd afzonderlijk beoordeeld kunnen worden. Wanneer er een onderdeel van de beveiliging faalt, zijn er dan nog genoeg lagen over om bescherming te bieden? Door middel vaneen beveiligingsanalyse kan goed beoordeeld worden of de geïmplementeerde maatregelen in overeenstemming zijn met het gedefinieerde beleid. Men zou een beveiligingsanalyse kunnen vergelijken met een beveiligingsonderzoek van een gebouw. Men beoordeeld de kwaliteit van het hang en sluitwerk zonder daarbij te proberen de deur te forceren.

Bij beide soorten onderzoek geldt een second opinion nooit kwaad kan en zelfs bijdraagt aan het verruimen van het blikveld. Tevens geldt dat er nooit garanties worden gegeven.

Samenvatting

Gebruik een gemeenschappelijk begrippenkader waarmee technische disciplines en managementdisciplines gezamenlijk een beleid kunne formuleren voor de netwerkbeveiliging.

Beschouw de combinatie van netwerk en aangesloten computersystemen als een groot computersysteem en beveilig het alsof het een grote computer is.

Maak onderscheid tussen de afzonderlijke doelen van beveiliging: exclusiviteit, integriteit en beschikbaarheid van informatie. Pas deze onderverdeling ook toe op de onderliggende informatiestromen.

Verdeel het te beveiligen netwerk in afzonderlijke zones en zorg dat slechts een organisatorische eenheid verantwoordelijk is voor de beveiliging van een zone. Wanneer meerdere organisaties verantwoordelijk zijn voor een deel van het netwerk dient het netwerk zodanig opgedeeld te worden dat een zelfstandig beveiligingsbeleid gevoerd kan worden.

Connection Tracking

Onderstaand artikel is gepubliceerd in het septembernummer van Linux News, jaargang 2001. Het is enigszins aangepast aan de huidige situatie.

Wanneer we een netwerk willen beveiligen met een firewall is het gebruik van Linux een aantrekkelijke optie. Sinds kernelversie 2.4 biedt Linux een krachtige en complete firewall.

Met de komst van de Linux 2.4 kernel in 2001 zijn de mogelijkheden om IP-verkeer te filteren sterk uitgebreid. Het in eerdere kernelversies (2.2 en eerder) toegepaste ipchains is vervangen door iptables, met netfilter als onderliggende structuur. Deze faciliteit vinden we nog steeds terug in de huidige kernels. Met deze structuur is onder andere statefull filtering tot de mogelijkheden gaan behoren. De linux implementatie hiervan wordt overigens connection tracking genoemd. Door gebruik te maken van connection tracking is het mogelijk om het beveiligingsniveau dat door de firewall geboden wordt op een hoog niveau te brengen. “Connection Tracking” verder lezen

De TCP/IP protocolsuite

Iedere IP verbinding is herkenbaar aan de combinatie client ip-adres, client poortnummer, server ip-adres en server poortnummer.

TCP

TCP staat voor Transaction Control protocol. Bij dit type verbinding is er sprake van een connectie waarbij de status binnen het protocol gedefinieerd is. Een TCP connectie wordt opgebouwd in drie stappen. De client kiest een vrij poortnummer, doorgaans boven de 1023. De client probeert een connectie te maken naar een bekend, doorgaans laag, poortnummer op de server. Voorbeelden van bekende poortnummers zijn 80 voor HTTP, 23 voor Telnet en 22 voor SSH. De client stuurt een pakket waarbij de SYN-vlag is gezet naar het bekende poortnummer op de server en gebruikt daarbij het zojuist gekozen hoge poortnummer. Wanneer de server akkoord gaat met het opzetten van de connectie stuurt deze een pakketje met zowel de SYN-vlag als de ACK-vlag gezet terug naar het hoge poortnummer van de client. Dit pakket wordt weer door de client weer beantwoord met een ACK, echter zonder SYN. De connectie is nu tot stand gekomen. De status is nu ESTABLSHED.

     Client                     Server 

      SYN      ---> 
                     <---     SYN+ACK 
      ACK      ---> 

Het beëindigen van een connectie kan op twee manieren gebeuren. Een normale beëindiging vindt plaats wanneer de client een pakket stuurt waarbij de FIN en de ACK vlag gezet zijn. De server beantwoordt dit met een ACK of FIN+ACK.

     Client                     Server 

      FIN+ACK  ---> 
                     <---         ACK 
                     <---     FIN+ACK 
      ACK      ---> 

Een connectie kan ook beëindigd worden wanneer een van de partijen een pakket met de RST vlag stuurt. Dit gebeurt vaak wanneer na een periode van inactiviteit een van de partijen er van uit gaat dat de ander niet meer geïnteresseerd is in voortzetting van de connectie. maar ook wanneer een connectie om een of andere redden geweigerd wordt. Een RST wordt niet bevestigd met een ACK.

UDP

Bij UDP, User Datagram Protocol, is er op netwerk protocol niveau geen sprake van een connectie. De applicaties die dit protocol gebruiken zijn zelf verantwoordelijk voor het bewaken van de status en de kwaliteit van de verbinding. Net als bij TCP maakt de client doorgaans gebruik van een hoog poortnummer en de server van een bekend laag poortnummer.

ICMP

ICMP is het Internet Control Message Protocol. Het dient om berichten die verband houden met een goed functioneren van het IP protocol, of een van de bovenliggende protocollen, door te geven. Er zijn 18 verschillende bericht types, waarbinnen weer diverse bericht codes mogelijk zijn. De bekendste toepassing is het ping commando, dat een ICMP `echo request’ (type 8 code 0) stuurt. Een echo request wordt beantwoord door een `echo reply’ (type 0 code 0).

FTP

FTP is het File Transfer Protocol. Het maakt gebruik van TCP, net zoals HTTP of Telnet. Het bijzondere aan FTP is dat het gebruik maakt van meerdere connecties. Een client maakt contact met poort 21 op de server. Wanneer er data verkeer plaats moet vinden, dit kan een file upload of download zijn, maar ook het resultaat van een ls of dir, wordt er een aparte data connectie geopend. De client geeft daartoe aan de server een hoog poortnummer door waarop het de data connectie verwacht. De data connectie wordt opgezet door de server vanaf poort 20, naar het poortnummer dat de client doorgegeven heeft.

Een variant hierop is passive FTP. Hierbij geeft de server een hoog poortnummer op aan de client en opent de client de data connectie vanaf een hoog poortnummer naar de server.

Het ontstaan van IP

Onderstaand citaat is met toestemming van de auteur H.J. Thomassen overgenomen uit UNIX het standaard operating system ISBN 90 395 1510 7.

Aan het einde van de jaren ’60 ontstond in de Verenigde Staten het ARPANET: een netwerk van geografisch verspreide mainframe-computers, gekoppeld via lange-afstands telefoon- huurlijnen. De ontwikkeling werd geïnitieerd en gefinancierd door ARPA (later herdoopt in DARPA, het `Defense Advanced Research Projects Agency’ een onderdeel van het Amerikaanse Department of Defense. De belangrijkste contractant was het commerciële researchbedrijf Bolt Beranek & Newman. In die dagen waren computernetwerken meer luchtkasteel dan werkelijkheid. Elementaire functies zoals files transporteren, remote inloggen en electronic mail bestonden nog slechts in de gedachten van researchers, en hun praktische haalbaarheid moest nog worden bewezen.

De eerste openbare demonstraties, eind 1972, waren meteen een doorslaand succes, en gaven voldoende argumentatie om de uitbouw voort te zetten. De eerste helft van de jaren ’70 vond ook de opkomst van de minicomputer plaats. Daardoor ontstond de wens om plaatselijk meerdere minicomputers met elkaar te verbinden, en dergelijke clusters weer te verbinden met de mainframe-computers die de lange-afstands verbindingen hadden. In feite betekende dit het onderling koppelen van Local Area netwerken met een Wide Area netwerk, en de term internetworking ontstond om zo’n `netwerk van netwerken’ aan te duiden.

Internetworking brengt een nieuwe klasse van problemen met zich mee: informatie moet kunnen `overstappen’ van één netwerk op een ander. Er zijn dan computers nodig die zijn uitgerust met een dubbele netwerk-interface, en er is een protocol nodig om beslissingen over route-keuzes af te handelen. Hiervoor werd het Internetworking Protocol (IP) ontwikkeld. Ook protocollen en bijbehorende user-interfaces voor remote inloggen en voor file transfer werden in dit kader ontwikkeld: de nog steeds zeer bekende commando’s telnet en ftp.

In de eerste helft van de jaren ’80 financierde het DARPA een project aan de University of California at Berkeley, om een operating system te bouwen ter ondersteuning van research in Artificial Intelligence laboratoria. Dat moest draaien op middenklasse-computers, en de (in 1978 geïntroduceerde) VAX-lijn van Digital Equipment leek hiervoor ideaal. Om samenwerking tussen verschillende AI- laboratoria te ondersteunen, eiste DARPA dat dat operating system ook in het ARPANET moest kunnen werken, dus dat IP (en alle aanverwante zaken) erin geïntegreerd moesten zijn.

Ken Thompson, een van de twee oorspronkelijke auteurs van UNIX, had toevallig een sabbatical gasthoogleraarschap aan Berkeley, juist in het jaar dat dit allemaal van start ging. Zo kwam het huwelijk tussen UNIX en IP tot stand, en verdiende de BSD-UNIX (Berkeley Software Distribution) versie haar plaats op de landkaart. De kernleden van deze Berkeley-groep (maar niet Thompson zelf) richtten na afloop van dit project hun eigen computerbedrijf op om het concept nog een stap te verkleinen van middenklasse-computer naar persoonlijk workstation (de Intel-gebaseerde PC bestond nog niet!). Zo ontstond Sun Microsystems.

Ongeveer in diezelfde tijd splitsten de militaire opdrachtgevers het ARPANET in tweeën. De militaire helft werd het MILNET. De overblijvende civiele tak werd op een aantal punten uitgebreid, met name om toegang tot een nieuwe reeks centraal opgestelde supercomputers te verschaffen aan veel meer onderwijsinstituten dan de `happy few’ die tot dan toe dat genot hadden gehad. Deze civiele ARPANET- opvolger noemde men het Internet. De hoofdletter I in deze schrijfwijze is karakteristiek als men specifiek dát netwerk bedoelt. Zoals bekend heeft het Internet vanaf het einde van de jaren ’80 een wereldwijde vlucht genomen. Overigens is aan een van deze supercomputer-centra (NCSA Chicago) de eerste browser Mosaic ontworpen, dat de killer-application bleek te zijn waarmee het Internet voor het grote publiek interessant werd. De bedenker van Mosaic (Andreessen) richtte later het bedrijf Netscape op.

© Copyright 2000, AT Computing