Universiteit Gent Faculteit Toegepaste Wetenschappen
Vakgroep Information Technology Voorzitter: Prof. Dr. Ir. LAGASSE Paul
Monitoring van Internet verkeer door Martijn VANDEVYVERE
Promotor: Prof. Dr. Ir. DEMEESTER Piet
Scriptie ingediend tot het behalen van de academische graad van licentiaat informatica – optie software-ontwikkeling
Academiejaar 2001-2002
Voorwoord
Hierbij wensen we de personen te bedanken die hebben bijgedragen tot het tot stand komen van dit eindwerk. In het bijzonder vermeldt ik de promotor Prof. Dr. Ir. DEMEESTER Piet en mijn begeleider Dhr. VANDENBERGHE Benny bij het bedrijf Skyline Communications NV. Verder danken we nog alle personen van het bedrijf Skyline Communications NV. Door hun hulp en inzet is deze scriptie kunnen tot stand komen.
“De auteur(s) geeft(geven) de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.” 29/05/2002
1
Monitoring van Internet verkeer door Martijn VANDEVYVERE Scriptie ingediend tot het behalen van de academische graad van licentiaat informatica – optie software-ontwikkeling
Academiejaar 2001-2002-05-30 Promotor: Prof. Dr. Ir. DEMEESTER Piet Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Information Technology Voorzitter: Prof. Dr. Ir. LAGASSE Paul Samenvatting Een uitgebreid netwerk kan heel wat onderhoud en problemen met zich meebrengen. Wanneer een grote groep mensen afhankelijk is van de correcte werking van dit netwerk, is het belangrijk dat er bij problemen snel kan ingegrepen worden. Om snel te kunnen ingrijpen dient er een mechanisme te zijn dat snel verwittigd bij het voorkomen van problemen. Dit mechanisme, het monitoring van knopen en diensten op een IP netwerk, controleert op een continue wijze de beschikbare knopen en diensten. Dergelijke applicatie werd opgebouwd aan de hand van enkele technologieën zoals DCOM, MFC, etc en voor de implementatie van de tests werden enkele internet protocollen uitgekozen zoals ICMP, HTTP, FTP, POP3 en SMTP. De applicatie diende op en voor het Windows platform ontwikkeld te worden. In de inleiding wordt de probleemstelling geschetst. In hoofdstuk twee bespreken we alle onderzochte protocollen die tevens geïmplementeerd werden. In hoofdstuk drie bespreken we op welke manier de besproken protocollen aangewend kunnen worden om de beschikbaarheid van de knopen en de diensten op het netwerk te testen. In hoofdstuk vier wordt de opbouw van de applicatie besproken, waarna enkele voorstellen tot uitbreiding en verbetering aan beurt komen. In hoofdstuk vijf schrijven we dan een samenvatting neer. Trefwoorden: monitor, netwerk; service
2
1.
Inleiding................................................................................................................................... 4
2.
De ondersteunde protocollen ..................................................................................................... 5
3.
4.
2.1.
ICMP ............................................................................................................................... 5
2.2.
HTTP............................................................................................................................... 9
2.3.
FTP.................................................................................................................................16
2.4.
POP3 ..............................................................................................................................22
2.5.
SMTP .............................................................................................................................24
De controles ............................................................................................................................30 3.1.
ICMP controle .................................................................................................................30
3.2.
HTTP controle .................................................................................................................35
3.3.
FTP controle ....................................................................................................................37
3.4.
POP3 controle .................................................................................................................39
3.5.
SMTP controle ................................................................................................................41
3.6.
Samenwerking van de protocollen.....................................................................................43
3.7.
Stand van zaken in de implementatie .................................................................................44
De applicatie ...........................................................................................................................45 4.1.
Probleemstelling ..............................................................................................................45
4.2.
Aanvang van de applicatie ................................................................................................47
4.3.
Structuur van de applicatie ...............................................................................................48
4.3.1.
COM.......................................................................................................................48
4.3.2.
DCOM....................................................................................................................48
4.3.3.
Interface Methods van de NSM.................................................................................51
4.3.4.
XML.......................................................................................................................55
4.3.5.
input/output .............................................................................................................56
4.3.6.
Werkwijze van de objecten.......................................................................................57
4.3.7.
De GUI...................................................................................................................60
4.4. 5.
Verbeteringen voor een opvolger ......................................................................................64
Samenvatting...........................................................................................................................69
Appendix A.....................................................................................................................................70 Appendix B .....................................................................................................................................73 Referenties ......................................................................................................................................74
3
1. Inleiding Een bedrijf kan over een uitgebreid netwerk beschikken. Als werknemers afhankelijk zijn van de goede werking van dit netwerk, is het belangrijk dat alle diensten op het netwerk beschikbaar blijven. De productiviteit van de werknemer kan afhangen van deze werking of het netwerk kan instaan voor de communicatie naar de klant toe. De werknemer of de klant kan gehinderd worden wanneer de webserver of de e-mail server offline of een andere server offline gaat. Op deze cruciale ogenblikken moet men snel kunnen ingrijpen. Een applicatie die de beschikbaarheid van de diensten, die de servers leveren, op het netwerk controleert en automatisch de netwerkverantwoordelijke alarmeert bij het foutlopen, kan hierbij een grote hulp zijn. De netwerkverantwoordelijke kan zich beperken tot slechts enkele hosts op het netwerk te controleren of hij kan het volledige netwerk controleren. Een controle houdt bijvoorbeeld in dat een webobject van een webserver afgehaald wordt. Een foutieve controle van een dienst kan gaan van het niet kunnen bereiken van een bepaalde netwerkknoop tot een bericht waarbij gemeld wordt dat de webserver trage respons levert. De applicatie laat toe verschillende controles uit te voeren, die volledig geconfigureerd kunnen worden. Hierbij kan de netwerkbeheerder de soort test dan bepalen, de frequentie waarmee een test wordt uitgevoerd, enz. De opbouw van een dergelijke applicatie wordt in de volgende hoofdstukken besproken. In hoofdstuk 2 worden alle protocollen die onderzocht en geïmplementeerd werden besproken. De protocollen die we zullen bespreken zijn ICMP (Internet Control Message Protocol), HTTP (HyperText Transfer Protocol), FTP (File Transfer Protocol), POP3 (Post Office Protocol) en SMTP (Simple Mail Transfer Protocol). In hoofdstuk 3 bespreken we de testen die op elk protocol worden uitgevoerd. In hoofdstuk 4 wordt de opbouw van de applicatie besproken. Daarin worden eerst enkele begrippen zoals DCOM (Distributed Component Object Model) en XML besproken. Waarna we een duidelijk beeld scheppen van de opgebouwde applicatie. Hoofdstuk 5 bevat een samenvatting.
4
2. De ondersteunde protocollen Dit hoofdstuk beschrijft alle onderzochte netwerkprotocollen en geeft ook een beeld van wat het besproken protocol inhoudt en waartoe het dient.
2.1. ICMP Het ICMP [1] wordt gebruikt door IP knopen op een netwerk om fouten tussen gateways & hosts en tussen hosts te rapporteren, evenals om een beperkte hoeveelheid informatie te leveren aan een eindsysteem op een netwerk. Wanneer een router of een host duidelijk wil maken aan de vragende host dat er iets is fout gelopen in het verwerken van een datagram, dan wordt er gebruik gemaakt van het “Internet Control Message Protocol” (ICMP). ICMP kunnen we als volgt beschrijven: •
ICMP maakt gebruik van het IP (Internet Protocol) [2] protocol alsof ICMP een protocol is dat zich op een hoger liggend niveau bevindt (meer bepaald, alsof de ICMP berichten ingekapseld zijn in de IP datagrammen). Nochtans maakt ICMP deel uit van het IP protocol en dient ze geïmplementeerd te worden door iedere IP module. Dit betekent dat iedere host op een IP netwerk over een IP module beschikt waarin ICMP zeker ondersteund wordt.
•
ICMP hanteert men om fouten te rapporten, niet om de IP laag betrouwbaar te maken. Het is nog steeds mogelijk dat datagrammen niet afgeleverd worden waarbij er dan geen melding is van het foutlopen van deze operatie. Betrouwbaarheid moet nog steeds geïmplementeerd worden door een protocol dat zich op een hoger liggende laag bevindt en dat gebruik maakt van het IP protocol.
•
Op eender welk IP datagram kan ICMP fouten rapporteren met uitzondering van ICMP berichten zelf, dit om oneindige herhalingen te vermijden.
•
ICMP berichten worden nooit verzonden als antwoord op ICMP foutboodschappen. Ze kunnen enkel verzonden worden als antwoord op ICMP vragen (query berichten). Dit zijn berichten van het type 0, 8, 9, 10 en 13 tot en met 18).
•
Als er gebruik gemaakt wordt van gefragmenteerde IP datagrammen, dan worden er enkel ICMP berichten over fouten verzonden betreffende het eerste fragment. Meer bepaald, ICMP berichten verwijzen nooit naar een IP datagram met een fragment offset vlag die niet nul is.
•
ICMP berichten worden nooit verzonden als antwoord op een datagram dat geen IP adres als bron heeft, waarbij de bron een unieke host bepaalt. Specifieker, het IP adres van de bron kan
5
niet nul zijn, kan eveneens geen loopback adres, geen broadcast adres en geen multicast adres zijn. •
Er wordt eveneens gestipuleerd in RFC 792 dat ICMP berichten kunnen gegenereerd worden om IP datagram verwerkende fouten te rapporteren. Hierin wordt de nadruk gelegd op het woord kunnen, niet moeten.
ICMP pakketten kunnen dus de goede of de slechte werking van een netwerk signaleren. Sommige van de ICMP functies bestaan om: •
Netwerk fouten te signaleren, zoals een host of een deel van een netwerk dat onbereikbaar is, veroorzaakt door een bepaald type van fout. Een TCP of een UDP pakket gestuurd naar een bepaalde poort met geen ontvanger wordt gemeld door middel van ICMP.
•
Netwerk opeenhoping (congestion) signaleren. Wanneer een router teveel pakketten begint te bufferen, volgend op de onmogelijkheid om ze snel genoeg te verzenden, zal de router ICMP ‘Source Quench’ berichten genereren. Wanneer deze pakketten gericht worden aan de zender, zouden ze ervoor moeten zorgen dat de snelheid waarmee de pakketten door de router ontvangen worden vertraagd wordt. Hou er wel rekening mee dat het genereren van teveel ‘Source Quench’ berichten ervoor zou kunnen zorgen dat er nog meer netwerk opeenhoping optreedt, daarom worden deze berichten dan ook spaarzaam gebruikt.
•
ICMP ondersteunt een Echo functie, die enkel een pakket tussen twee hosts verzendt met een Round-Trip Time. Ping is een hulpstuk dat gebaseerd is op dit kenmerk. Ping zal een aantal pakketjes verzenden, de Round-Trip tijden meten en de verliespercentages berekenen.
•
Als de TTL van een IP pakket naar nul valt, zal de router die het pakket negeert dit vermelden. Traceroute is een werktuig die netwerkroutes in kaart brengt door pakketjes met kleine TTL waarden te verzenden en de ICMP time-out berichten te bekijken.
Om de bereikbaarheid van hosts te controleren kan er gebruik gemaakt worden van de ping. Hiermee kan dan gemeld worden wanneer een opgegeven host niet bereikbaar is. Het ping gereedschap maakt gebruik van de ‘Destination Unreachable Message’ van het ICMP protocol. In een IP netwerk, zendt een ping dan een kleine datahoeveelheid – een enkel pakket – en luistert de ping naar een enkel pakket als antwoord. Aangezien dit de basisfunctionaliteit van een IP netwerk test (aflevering van een enkel pakket), is het gemakkelijk om in te zien dat er veel geleerd kan worden van enkele pings. ICMP berichten worden verzonden in IP datagrammen. Het IP data veld zal dan het uiteindelijke ICMP bericht bevatten dat opgebouwd is zoals in figuur 2.1 aangetoond wordt.
6
Het ICMP bericht formaat
fig. 2.1
ICMP bericht formaat
Hierin specificeert Type het type van het bericht:
0 Echo reply
17 Address mask request
3 Destination unreachable
18 Address mask reply
4 Source quench
30 Traceroute
5 Redirect
31 Datagram conversion error
8 Echo
32 Mobile host redirect
9 Router advertisement
33 IPv6 Where-Are-You
10 Router solicitation
34 IPv6 I-Am-Here
11 Time exceeded
35 Mobile registration request
12 Parameter problem
36 Mobile registration reply
13 Time Stamp request
37 Domain name request
14 Time Stamp reply
38 Domain name reply
15 Information request (obsolete)
39 SKIP
16 Information reply (obsolete)
40 Photuris
Code bevat de foutcode van het datagram waarop gerapporteerd wordt door dit ICMP bericht. De interpretatie is afhankelijk van het berichttype. Checksum bevat het 16-bits 1-complement van de 1-complement som van het ICMP bericht. De som start hierbij vanaf het ICMP type veld. Om deze checksum te berekenen wordt er aangenomen dat het checksum veld nul is. Dit algoritme is identiek aan het algoritme gebruikt bij de IP hoofding.
7
Data bevat informatie over dit ICMP bericht. Het zal meestal een deel van het originele IP bericht bevatten waarvoor dit ICMP bericht gegenereerd werd. De lengte van de data kan bepaald worden aan de hand van de lengte van het IP datagram die het bericht bevat min de lengte van de IP hoofding. Echo (8) and Echo Reply (0) Echo wordt gebruikt om te controleren of een andere host actief is op het netwerk. De zender initieert daarvoor de identiteit (identifier) en het sequentie (sequence) nummer (dit wordt gebruikt als er meerdere echo verzoeken gestuurd worden). Er wordt eveneens data in het data veld geschreven en uiteindelijk wordt de ICMP echo verzonden naar de bestemming. De code van de ICMP hoofding is hierbij nul. De ontvanger verandert het type veld tot een Echo Reply en zendt het datagram daarna terug naar de zender.
Wat kan een ping u vertellen? Een ping plaatst een uniek sequentienummer in ieder pakket dat het verzendt, en het vermeld welk sequentienummer het ontvangen heeft. Men kan op deze manier te weten komen welke pakketten verloren zijn gegaan, gedupliceerd zijn of in een andere volgorde ontvangen worden. Een ping doet eveneens een checksum op ieder pakket dat het uitwisselt. Zo wordt dan gecontroleerd of een pakket beschadigd is. Een ping plaatst een tijdstip in ieder pakket dat het uitwisselt. Ieder pakker dat dan teruggezonden wordt kan dan gemakkelijk gebruikt kan worden om de tijdsduur die het nodig had om uitgewisseld te worden te berekenen. Dit wordt de Round-Trip Time genoemd.
Wat kan een ping u niet vertellen! Sommige routers kunnen onopvallend pakketten die niet afgehandeld kunnen worden negeren. Andere routers kunnen dan weer denken dat een pakket succesvol verzonden is terwijl dit niet het geval is. (Dit is zeker het geval op een Ethernet, dat geen link laag antwoorden voorziet). Om deze redenen kan een ping niet altijd redenen geven waarom pakketjes onbeantwoord blijven. Een ping kan u niet vertellen waarom een pakket beschadigd, vertraagd of gedupliceerd is. Het kan u eveneens niet vertellen waar dit gebeurd is, niettegenstaande je het misschien wel kan afleiden. Een ping kan u geen stap voor stap beschrijving geven van iedere host die het pakket behandeld heeft en informatie leveren over alles wat er onderweg gebeurd is. Het is een ongelukkig feit dat geen enkel stukje software deze informatie voor een TCP/IP netwerk betrouwbaar kan leveren.
8
2.2. HTTP Hypertext transfer protocol [3] [4] [5] is een protocol dat werd ontwikkeld voor het overzetten van hypertext markup language (HTML) documenten. HTML is taal gebaseerd op labels (tags) die gebruikt wordt om hypertext documenten te creëren. Hypertext documenten bevatten verwijzingen naar andere documenten die additionele informatie bevatten over de aangeduide term of onderwerp. Deze documenten kunnen eveneens andere elementen naast tekst bevatte n. Hierbij bedoelen we elementen zoals: afbeeldingen, geluid- en beeldfragmenten, Java applets, … HTTP wordt geïmplementeerd in twee soorten applicaties : in client applicaties en server applicaties. De client en server applicatie die opereren op de verschillende systemen, praten dan met elkaar aan de hand van HTTP berichten. HTTP definieert de structuur van deze berichten en hoe de client en de server deze berichten kunnen uitwisselen. Communicatie tussen de client en de server kan slechts opgestart worden indien men beschikt over een URL (Uniform Resource Locator). Een URL kan gezien worden als het adres naar waar gegaan moet worden om een pagina te lezen. Iedere URL heeft twee componenten: de naam van de server die eigenaar is van het object dat we wille n ontvangen en de plaatsnaam van het object op die server. HTTP_URL = “http” “//” host [ “:” port ] [ path ] host
= een geldige Internet host domein naam of een IP adres
Een overzicht van HTTP HTTP is een activiteit met vraag en antwoord. Een client, die een applicatie zoals een browser draait, zet een verbinding op met een server en zendt hierbij een verzoek naar de server in de vorm van een vraag. De server antwoord met een bericht waarin de status, de protocol versie van het bericht en een succes of foutieve code teruggegeven wordt, met daaropvolgend een bericht die informatie aangaande de server bevat, informatie over de entiteit en de inhoud van het gevraagde object. Een HTTP transactie wordt opgesplitst in vier stappen: 1. De browser opent een verbinding. 2. De browser zendt een verzoek naar de server. 3. De server zendt een antwoord naar de browser. 4. De connectie wordt afgesloten. Over het internet gebeurt de HTTP communicatie over TCP connecties. De standaard poort hiervoor is TCP poort 80, maar andere poorten kunnen eveneens gebruikt worden.Dit voorkomt niet dat HTTP geïmplementeerd wordt bovenop andere protocollen op het internet of op andere netwerken. HTTP gaat alleen van een betrouwbare transportlaag uit, eender welk protocol dat deze betrouwbaarheid garandeert voldoet dus om door HTTP gebruikt te worden.
9
Er wordt echter steeds van uit gegaan dat de verbinding reeds opgezet werd door de client voor ieder verzoek en gesloten wordt door de server na het zenden van een antwoord. Zowel de client als de server moeten er zich van bewust zijn dat de andere partij de connectie voorbarig kan afsluiten, dit tengevolge van een actie opgezet door de gebruiker, het verlopen van een tijdslimiet, of een programmafout. Het sluiten van de verbinding door een van de partije n beëindigd dan steeds het huidig verzoek, ongeacht zijn status. HTTP is simpelweg een staatloos protocol daar het geen informatie bijhoudt aangaande de connecties. Als een bepaalde client dan uiteindelijk tweemaal om hetzelfde object vraagt in enkele seconden, antwoordt de server niet door te zeggen dat het net dit object verzonden heeft naar de client, maar het zendt gewoon opnieuw het object. Dit omdat de server volledig vergeten is wat hij net gedaan heeft. Om bijvoorbeeld een pagina met twee afbeeldingen in te laden, moet de browser drie connecties opzetten, eentje voor de pagina en twee voor de afbeeldingen. De meeste browser kunnen deze connecties over het algemeen simultaan afhandelen. Dit gedrag kan echter heel wat resources verbruiken als een enkele pagina uit heel wat elementen bestaat, zoals dit nu het geval is op het internet. De oplossing hiervoor is HTTP\1.1, die dit probleem op zo’n manier verhelpt door slechts één TCP connectie op te zetten voor elk soort element op een webpagina. Alle elementen van dat type worden dan over dezelfde respectievelijke connectie verzonden. HTTP operatie Meestal wordt de HTTP communicatie opgestart door de gebruikersagent die een bepaald object van op de server wenst te verkrijgen. In het meest eenvoudige geval wordt de verbinding opgezet tussen de gebruikersagent en de server zoals hieronder aangetoond wordt.
fig. 2.2
http communicatie tussen een gebruikersagent en een server
10
In de meeste gevallen is er geen directe connectie tussen de gebruikersagent en de server waarop alle informatie zich bevindt. Er is dan één of meer tussenstap die genomen moet worden tussen de server en de gebruikersagent. Deze tussenstappen kunnen een proxy 1 , een gateway2 of een tunnel zijn. Verzoeken en antwoorden worden geëvalueerd door deze tussenstappen en worden na evaluatie doorgezonden naar de bestemming of een andere tussenstap in de ketting.
fig. 2.3
Een client/server connectie met tussenstappen.
Een proxy kan de inhoud van het antwoord bekijken en ze eveneens aanpassen. Wanneer een verzoek doorheen de proxy stroomt, zal die het gehele bericht of een deel ervan herschrijven en het bericht uiteindelijk doorsturen naar de volgende bestemming. Een gateway ontvangt het bericht en zendt het naar het onderliggende protocol in het correcte formaat. Een tunnel behandelt de inhoud van het bericht niet, m.a.w. het zal het bericht in zijn huidige toestand doorzenden.
fig. 2.4
Proxies en gateways kunnen HTTP berichten opslaan (caching).
1
In een bedrijf dat het Internet gebruikt, is een proxy server een server die optreedt als een verbinding tussen een gebruiker van een workstation en het Internet zodat het bedrijf administratieve controle, een caching service en veiligheid kan voorzien. Een proxy server ontvangt een verzoek voor een Internet service (zoals het verzoek voor een webpagina) van een gebruiker. Als het voldoet aan de eigenschappen om door de filter te raken, kijkt de proxy server, wanneer het ook een cache server is, in zijn lokale cache van vroegere afgehaalde webpagina’s. Als het de pagina vindt, zal de proxy server deze pagina teruggeven zonder het verzoek nog over het Internet te verzenden. 2 Een gateway is een punt op het netwerk dat dienst doet als toegang tot een ander netwerk.
11
Dit kan de antwoordsnelheid gevoelig beïnvloeden evenals het IP verkeer op een netwerk. Als in de vorige figuur één van de tussenstappen een interne cache bevat voor de server waarnaar een verzoek gestuurd werd, kan de gebruikersagent een antwoord verkrijgen van de tussenstap als dit antwoord bij een vorig verzoek bewaard werd. Figuur 2.4 toont aan dat A een opgeslagen kopie van een vorig verzoek bevat. Als het antwoord van de server nog niet bewaard werd in de cache van de gebruikersagent, dan kan het rechtstreeks opgehaald worden vanuit A. Er moet wel rekening mee gehouden worden dat caching niet toepasbaar is op alle server antwoorden. HTTP verzoek bericht Een verzoekbericht wordt in normale ASCII tekst geschreven, zodat iedereen het kan lezen. Een verzoekbericht zal steeds een minimum van één lijn omspannen. De eerste lijn van een HTTP verzoek bericht wordt een request lijn genoemd. De daaropvolgende lijnen worden de header lijnen genoemd. De request lijn heeft 3 velden: het method veld, het URL veld en het HTTP versie veld. Het method veld kan volgende methodes bevatten: GET, POST en HEAD. De meerderheid van HTTP verzoeken maken gebruik van de GET methode. De GET methode wordt gebruikt wanneer de browser een object aanvraagt, met het gevraagde object geïdentificeerd in het URL veld. In het versie veld wordt de HTTP versie gespecificeerd.
method
SP
version
CR/LF
header field name
SP
value
CR/LF
header field name
SP
value
CR/LF
CR/LF
SP URL
..
Entity Body
fig. 2.5
Het formaat van een http verzoek (request)
12
Je bemerkt misschien wel dat na de header lijnen (en de additionele carriage return / line feed ) er een entity body staat. Het entity body wordt niet gebruikt met de GET methode, maar wel met de POST methode. De HTTP client maakt gebruik van een POST methode wanneer een gebruiker een formulier invult. Met een POST methode vraagt de client nog steeds een web pagina van de server, maar de specifieke inhoud van de webpagina hangt af van wat de gebruiker ingevuld heeft. Wanneer de waarde van het method veld POST is, bevat de entity body wat de gebruiker ingevuld heeft in de formuliervelden. De HEAD methode is dan weer vergelijkbaar met de POST methode. Wanneer een server een verzoek ontvangt aan de hand van de HEAD methode, antwoordt de server met een HTTP bericht dat alle informatie over het object bevat, behalve het object zelf.
HTTP antwoord bericht Er zijn drie secties in een antwoordbericht: een initiële status lijn, zes header lijnen en uiteindelijk de entity body. De entity body bevat het gevraagde object. De status lijn heeft drie velden: het veld met de protocol versie, een status code en een corresponderend statusbericht. De header lijnen kunnen heel wat bevatten, enkele voorbeelden hiervan zijn: •
Connection die gebruikt wordt om de client te vertellen dat ze de TCP connectie zal afsluiten na het zenden van het bericht.
•
Date die de tijd en de datum aangeeft wanneer het HTTP antwoord gecreëerd en verzonden werd door de server. Bemerk dat dit niet de tijd is wanneer het object gecreëerd of laatst gemodificeerd werd; het is de tijd wanneer de server het object opgehaald heeft van zijn filesysteem, het in het antwoord bericht gestopt heeft en het antwoord verzonden heeft.
•
Server toont aan de het bericht opgesteld werd door een bepaalde server.
13
version
SP
header field name
Status code
..
header field name
SP
phrase
CR/LF
SP
value
CR/LF
SP
value
CR/LF
CR/LF Entity Body
fig. 2.6
Het formaat van een http antwoord
HTTP operaties •
GET: De GET methode haalt eender welke informatie op geïdentificeerd door de verzoek URL. Als de verzoek URL naar een proces verwijst dat data produceert, is de geproduceerde data wat teruggegeven zal worden in het antwoord en niet de broncode van het proces, behalve als de code
de
output
van
het
proces
blijkt
te
zijn.
De semantiek van een GET methode verandert naar een conditionele GET als het verzoek bericht een If-Modified-Since header veld bevat. Een conditionele GET methode vraagt dat de geïdentificeerde resource getransfereerd wordt, enkel en alleen als ze veranderd is sinds de datum die gegeven is in het If-Modified-Since veld. •
De HEAD methode is identiek aan de GET behalve dat de server geen entity body moet teruggeven in het antwoord. De meta -informatie die zich in de HTTP headers bevindt als antwoord op een HEAD verzoek zouden identiek moeten zijn aan de informatie gezonden als antwoord op een GET verzoek. Deze methode kan gebruikt worden om meta-informatie te bekomen over de resource geïdentificeerd door de verzoek URL zonder dat de entity body zelf wordt verzonden.
•
De POST methode wordt gebruikt om de doel server te vragen dat hij een entiteit ingesloten in het verzoek accepteert als een nieuwe ondergeschikte van de resource geïdentificeerd door de verzoek URL in de Request-Line. De POST is ontworpen om een uniforme methode toe te laten die de volgende functies ondersteund:
14
o Een aantekening van de bestaande resources; o Een bericht posten op een bulletin board, newsgroup, mailing lijst, of een soortgelijke groep van artikels; o Een blok van data voorzien, zoals het resultaat van het ingeven van een formulier, tot een data -hanteringsproces; o Een databank uitbreiden door middel van een append operatie. De eigenlijke functie gedaan door de POST methode wordt bepaald door de server en is meestal afhankelijk van de verzoek URL. De geposte entiteit is ondergeschikt aan die URL op dezelfde manier als een bestand ondergeschikt is aan een map die het bestand bevat.
De status code De status code definities zijn de volgende: •
Informatie leverend (1xx): De status codes die informatie leveren indiceren een tijdelijke antwoord.
•
Succes indicerende status codes (2xx): Deze klasse van codes indiceert dat een bepaald verzoek succesvol ontvangen, begrepen en geaccepteerd werd.
•
Doorverwijzende status codes (3xx): Deze klasse van codes indiceert dat er een actie nodig is van de gebruikersagent om het verzoek te vervolledigen.
•
Client fouten (4xx): Deze klasse van codes indiceert client fouten.
•
Server fouten (5xx): Deze klasse van codes indiceert server fouten.
HTTP caching Eén van de belangrijkste eigenschappen van HTTP is de caching eigenschap. Omdat HTTP een gedistribueerd informatie gebaseerd protocol is, kan caching de performantie gevoelig bevorderen. In de meeste gevallen kunnen de verzoeken van clients en de antwoorden van servers bewaard worden in een cache om de toekomstige corresponderende verzoeken te behandelen. Als het antwoord zich in de cache bevindt en accuraat is, is er geen nood om een nieuw antwoord van de server te verzoeken. Deze aanpak vermindert niet alleen het netwerkverkeer, maar heeft ook een snelheidsverhoging tot gevolg.
15
2.3. FTP Het kopiëren van bestanden van één machine naar een andere is een van de meest gebruikte operaties. Deze dataoverdracht tussen client en server kan in beide richtingen vloeien. De client kan een bestand naar een server zenden, maar de client kan eveneens een bestand van de server afhalen. Om toegang te krijgen tot deze bestanden die zich op een andere locatie bevinden, moet de gebruiker zich identificeren bij de server machine. Op dat ogenblik is de server verantwoordelijk voor de bevestiging van de authenticiteit van de client voordat de dataoverdracht plaatsvindt. Een FTP verbinding is connectie georiënteerd. Met ander woorden, het is een vereiste dat beide hosts moeten werken, en dat ze beiden TCP/IP moeten ondersteunen voordat er een verbinding opgezet kan worden.
Een overzicht van FTP FTP (File Transfer Protocol) [6] maakt gebruik van TCP als het transport protocol om een betrouwbare connectie op te zetten. De FTP server luistert naar connectie s op poort 20 en 21. Twee connecties worden er gebruikt: de eerste connectie is voor het inloggen en steunt op het TELNET protocol en de tweede connectie wordt gebruikt voor de dataoverdracht. Indien het nodig is om in te loggen dient de gebruiker een gebruikersnaam en een paswoord te voorzien om toegang te verkrijgen tot de bestanden en de mappen. De gebruiker die de connectie opzet speelt de client functie, terwijl de server functie dan voorzien wordt door de andere host. Aan beide zijden van de verbinding is de FTP applicatie opgebouwd aan de hand van een protocol vertaler (protocol interpreter, PI), een data transfer proces (DTP) en een gebruikersinterface. De gebruikersinterface communiceert met de PI, die de controle connectie beheert. Deze PI moet dan de nodige informatie toepassen op zijn eigen bestandssysteem. Aan de andere kant van de verbinding, moet de PI naast zijn functie van antwoorden op het TELNET protocol eveneens de data connectie initialiseren. Tijdens deze bestandsoverdracht wordt de data management gedaan door DTP’s. Nadat een verzoek van een gebruiker afgehandeld is moet de PI van de server de controleconnectie verbreken. Dit alles wordt geïllustreerd in figuur 2.7. Gedurende de sessie houdt de FTP server status informatie over de gebruiker bij. De server moet de controle connectie associëren met een specifieke user account en moet bijhouden in welke map de gebruiker zich bevindt wanneer de gebruiker door de mappen en bestanden wandelt. Doordat deze informatie bijgehouden wordt, beperkt dit het aantal FTP sessies die tegelijkertijd onderhouden kunnen worden.
16
FTP operaties Wanneer FTP gebruikt wordt moet de gebruiker enkele of alle van de volgende operaties uitvoeren. •
Een connectie opzetten met een FTP server.
•
Een directory selecteren.
•
De voor transfer beschikbare bestanden weergeven.
•
De overdrachtmodus definiëren.
•
De bestanden naar of van de FTP server kopiëren.
•
De verbinding met de FTP server verbreken.
fig. 2.7
FTP principe
Verbinden met een FTP server Om een bestandsoverdracht uit te voeren, begint de gebruiker met het inloggen op de FTP server. Dit is de manier waarop veiligheid ondersteund wordt. De gebruiker moet een gebruikersidentiteit hebben en een paswoord, behalve wanneer gebruik gemaakt wordt van een anonieme FTP sessie. Er zijn vier commando’s die gebruikt worden tijdens het verbinden: •
OPEN : selecteert de afgelegen host en initieert de aanmelding sessie.
•
USER : identificeert de gebruiker.
•
PASS : verifieert de gebruiker.
•
SITE : zendt informatie betreffende specifieke services voor de host naar de host .
17
Het selecteren van een map Wanneer er een controleverbinding opgezet is, kan de gebruiker aan de hand van het cd (change directory) subcommando veranderen van map. De gebruiker kan natuurlijk enkel gebruik maken van de mappen waartoe hij toegang heeft. De gebruiker kan de locale directory veranderen met het lcd (local change directory) commando. De syntax van deze commando’s hangt af van het besturingssysteem dat gebruikt wordt.
Bestanden beschikbaar voor de overdracht weergeven Deze taak wordt uitgevoerd door gebruik te maken van het dir of ls subcommando.
Het specificeren van de transfer modus Het overbrengen van data tussen verschillende soorten systemen vereist veelal transformatie van de data. De gebruiker moet beslissen tussen twee aspecten om de data te behandelen: •
De manier waarop de bits van de ene plaats naar de andere verplaatst moeten worden.
•
De verschillende manieren hoe de data gerepresenteerd kan worden.
Dit wordt gecontroleerd aan de hand van volgende twee subcommando’s: •
MODE : Bepaalt of het bestand behandeld moet worden alsof het een record structuur heeft in een byte stroom formaat. o Blok: de logische record grenzen van het bestand worden behouden. o Stroom: Het bestand wordt behandelt als een byte stroom. Dit is de standaard instelling en voorziet een efficiëntere transfer maar kan mogelijks voor een foutief resultaat zorgen in geval van een record gebaseerd systeem.
•
TYPE: Specificeert de karakterverzameling die gebruikt wordt voor de data. o ASCII: Stipuleert dat beide hosts op ASCII gebaseerd zijn, of als de een op ASCII gebaseerd is en de ander op EBCDIC gebaseerd is, dat er ASCII-EBCDIC translatie dient plaats te vinden. o EBCDIC: Meldt dat beide hosts gebruik maken van een EBCDIC data representatie. o IMAGE: Bepaalt dat de data behandeld dient te worden als opeenvolgende bits verpakt in 8-bit bytes.
Omdat deze subcommando’s niet alle mogelijke verschillen tussen de systemen omspannen, is het SITE subcommando voorhanden om implementatie afhankelijke commando’s uit te voeren.
18
Overzetten van bestanden De volgende commando’s kunnen gebruikt worden om bestanden tussen FTP clients en servers over te zetten: GET: Kopieert een bestand van de FTP server naar de locale host. MGET: Kopieert meerdere bestanden van de FTP server naar de locale host. PUT: Kopieert een bestand van de locale host naar de FTP server. MPUT: Kopieert meerdere bestanden van de locale host naar de FTP server. Passieve modus gebruiken Passieve modus draait de richting van de data transfer om, zodat de FTP server een poort selecteert en het client programma dan informeert welke poort die moet gebruiken wanneer de client een connectie opzet met de FTP serve. Aangezien passieve modus de FTP server toelaat om een poort voor de connectie te creëren, is het op deze manier eenvoudig te verzekeren dat er zich geen gevaarlijke dienst op een bepaalde poort bevindt. Deze aanpak maakt het configureren van firewalls een stuk eenvoudiger.
Proxy transfer gebruiken Dit laat de clients die over een trage connectie beschikken toe om gebruik te maken van een overdracht via derden om de data over te zetten tussen twee verschillende servers. Een client die een connectie opgezet heeft met een server opent op deze manier een FTP connectie met een andere server vanuit de eerste server door gebruik te maken van het proxy open commando. Bijvoorbeeld, client A wilt een bestand afhalen van server B maar de verbinding is traag. Client A kan nu eerst een verbinding maken met server C en dan een proxy open commando uitvoeren gericht naar server B om op server B in te loggen. Client A zendt proxy get file_name om de data over te zetten van server B naar server C. Daarna kan client A het bestand afhalen van server C.
Afsluiten van een dataoverdracht sessie De volgende commando’s worden gebruikt op het einde van een FTP sessie: •
QUIT: Verbreekt de verbinding met de server en sluit FTP af. Soms wordt het BYE subcommando gebruikt.
•
CLOSE: Verbreekt de verbinding met de server, maar laat de FTP client draaien. Een open commando kan gebruikt worden om te werken met een nieuwe host.
19
Antwoord codes Om deze commando’s te kunnen behandelen, voeren de client en de server een dialoog waarbij ze gebruik maken van de TELNET conventie. De client stuurt commando’s en de server antwoord met antwoord codes. De antwoorden omvatten eveneens commentaar voor het gemak van de gebruiker, maar het client programma gebruikt enkel codes. Antwoord codes zijn 3 cijfers lang, waarvan het eerste cijfer het belangrijkst is. Antwoord codes: •
1xx
positief voorlopig antwoord
•
2xx
positief beëindigend antwoord
•
3xx
positief tussentijds antwoord
•
4xx
voorbijgaand negatief beëindigend antwoord
•
5xx
definitief negatief beëindigend antwoord
Anonieme FTP Er zijn heel wat TCP/IP sites die anonieme FTP implementeren. Dit betekent dat deze sites publieke toegang toestaan tot sommige bestandsmappen. De afgelegen gebruiker dient enkel de inlognaam anonymous en het paswoord guest of een andere conventie die het paswoord bepaalt te kennen, bijvoorbeeld het e-mail adres van de gebruiker. De conventie voor het paswoord wordt uitgelegd aan de gebruiker gedurende het inlog proces.
20
fig. 2.8
Voorbeeld van een FTP scenario
21
2.4. POP3 POP3 (Post Office Protocol) [7] is een extreem gemakkelijk e-mail toegangsprotocol. Het wordt gebruikt om e-mail van de server te halen en lokaal te bewaren. Juist omdat het protocol zo simpel is, is de functionaliteit ervan eerder gelimiteerd. Een POP3 sessie begint wanneer de user agent een TCP connectie opent met een mail server op poort 110. POP3 commando’s en antwoorden POP3 commando’s bestaan uit een sleutelwoord en mogelijks één of meerdere argumenten die op het sleutelwoord volgen. Sleutelwoorden bestaan uit drie of vier karakters en zijn gescheiden van de argumenten met een enkele spatie. Ieder argument moet tot 40 karakters lang zijn. De server zendt een antwoord op het commando dat doorgestuurd werd door de client. Dit antwoord moet 512 karakters lang zijn en begint met een status indicator die aantoont of het antwoord positief of negatief is. Deze indicators zijn (+OK) of (-ERR). Van de server wordt verwacht dat hij die indicators in hoofdletters doorzendt. Antwoorden op bepaalde commando’s kunnen meerdere lijnen innemen. In deze gevallen, na het zenden van de eerste lijn van het antwoord en een CRLF (=Carriage return/ Line Feed), worden alle additionele lijnen beëindigd met een CRLF paar. Wanneer alle lijnen van het antwoord verzonden zijn, wordt er een finale lijn verzonden met een terminatie octet (“.”) en een CRLF paar. Een antwoord van meerdere lijnen wordt dus beëindigd met 5 octets: “CRFL.CRLF”. Bij het ontvangen van een antwoord dat meerdere lijnen omspant, kijkt de client als de lijn begint met een terminatie octet. Als dit het geval is, en als er octets verschillend van CRLF volgen, wordt de eerste octet van die lijn genegeerd.
Hieronder volgen de drie toestanden van een POP3 sessie:
Autorisatie toestand In deze toestand zendt de client informatie naar de server. Dit wordt op twee methodes geïmplementeerd. •
Gebruik makend van USER en PASS commando’s.
•
Gebruik makend van het APOP commando.
Transactie toestand Hierin kan de client commando’s zoals: een lijst teruggeven, ophalen en verwijderen doorsturen. Er moet wel opgemerkt worden dat het eigenlijke verwijderen niet plaatsvindt in deze toestand. De client moet eerst het QUIT commando zenden en dan pas gaat de server over naar de update toestand.
22
Update toestand In deze toestand zal de server de mailbox updaten aan de hand van de commando’s die ontvangen werden in de transactie toestand en daarna wordt de TCP connectie beëindigd. Als de connectie verbroken wordt omwille van eender welke reden voordat het quit commando verzonden werd door de client, gaat de server niet over naar de update toestand. Dit houdt in dat de server niks zal updaten.
Enkele belangrijke POP3 commando’s USER name:
Gebruikersnaam om de authenticiteit te controleren.
PASS password:
Paswoord om de authenticiteit te controleren. Het paswoord wordt echter als gewone tekst doorgezonden, men dient hier rekening mee te houden indien veiligheid een grote rol speelt.
STAT:
Om het aantal berichten te verkrijgen evenals de totale grootte.
LIST [msg]:
Als een berichtnummer meegegeven wordt, wordt de grootte van dit bericht teruggegeven als het bericht. Als het bericht niet bestaat worden ale berichten in een lijst teruggegeven samen met hun grootte.
RETR msg:
Dit commando zendt het gehele bericht naar de client.
DELE msg:
Dit commando verwijdert het geselecteerde bericht.
NOOP:
De server voert niks uit, het zendt enkel een positief antwoord.
RSET:
Dit commando maakt de voorgaande delete opdrachten ongedaan.
QUIT:
Als men zich in de autorisatie toestand bevindt, beëindigd dit enkel de TCP connectie. Als men zich in de transactie toestand bevond, zal dit commando er voor zorgen dat de mailbox eerst geüpdatet wordt en dan pas wordt de TCP connectie verbroken.
Formaat van het bericht Van alle berichten die verzonden worden gedurende een POP3 sessie wordt verondersteld dat ze voldoen aan de standaard van het formaat van een Internet tekst bericht (RFC 822).
23
2.5. SMTP Elektronische mail (e-mail) is waarschijnlijk de meest gekende TCP/IP applicatie. SMTP (Simple Mail Transfer Protocol) [8] wordt gebruikt om e-mail te verzenden. De uitwisseling van de berichten en de commando’s vindt plaats over TCP poort 25. Er zijn facilite iten toegevoegd voor de verzending van data die niet voorgesteld kan worden als 7-bit ASCII tekst. Er zijn drie standaard protocollen die van toepassing zijn op mail van deze soort. De term SMTP wordt veelal gebruikt om te verwijzen naar de gecombineerde verzameling van protocollen aangezien ze zo nauw verbonden zijn. Maar in de strikte zin van het woord bepaald SMTP slechts een van deze drie protocollen. Meestal is het duidelijk vanuit de context welk van deze drie protocollen bedoeld wordt. De drie protocollen zijn: •
Een standaard voor de uitwisseling van mail tussen twee computers die het protocol specificeren dat gebruikt wordt om mail te verzenden tussen TCP/IP hosts. Deze standaard is SMTP zelf. Het is eveneens slechts deze standaard die hier in beschouwing wordt genomen. Doch vernoemen we de andere twee protocollen nog voor de duidelijkheid.
•
Een standaard over het formaat van de mail berichten, bepaald door twee RFC’s. RFC 822 beschrijft de syntax van de mail header velden en definieert een verzameling van header velden en hun interpretatie. RFC 1049 beschrijft hoe een verzameling van documenttypes verschillend van gewone ASCII tekst gebruikt kan worden in het lichaam van de mail. De officiële naam voor dit protocol is MAIL.
•
Een standaard voor het routen van mail gebruik makende van het Domain Name System, beschreven in RFC 974. De officiële protocolnaam voor deze standaard is DNS-MX.
Hoe werkt SMTP SMTP is gebaseerd op een afleveringssysteem dat loopt van het begin tot einde. Een SMTP client zal de server van de doelhost rechtstreeks aanspreken om de mail af te leveren. Het zal de mail bewaren totdat het succesvol gekopieerd is op de SMTP server van de ontvanger. Dit verschilt van het stockeer-enzendt-door (store and forward) principe dat men meestal terugvindt in mailing systemen. In deze systemen zal de mail door enkele tussenliggende hosts passeren in hetzelfde netwerk terwijl hij op weg is naar de bestemming en waar succesvolle verzending van de zender enkel indiceert dat de mail de eerste tussenliggende stap bereikt heeft. In sommige implementaties is het mogelijk om data uit te wisselen tussen het TCP/IP SMTP mailing systeem en het lokaal gebruikte mailing systeem. Deze applicaties worden mail gateways of mail bridges genoemd. Mail verzenden langsheen een gateway kan de end-to-end afleveringsspecificatie wijzigen, dit
24
omdat SMTP enkel de aflevering bij de mail gateway garandeert, niet de echte destinatie die zich achter het TCP/IP netwerk bevindt. Wanneer dus een mail gateway gebruikt wordt, transformeert de SMTP end-to-end transmissie in een host-to-gateway, gateway-to-host of gateway-to-gateway dienst. Het gedrag na de gateway wordt niet gespecificeerd door SMTP. Ieder bericht heeft: •
Een header of envelop, waarvan de structuur gedefinieerd wordt
in RFC 822.
De mail header wordt afgesloten door een null lijn (dit is een lijn waar er zich niets voor de
sequentie bevindt). •
Zijn inhoud. Alles na de null lijn in het lichaam van het bericht dat een sequentie van lijnen bestaande uit ASCII karakters vormt.
RFC 821 definieert een client/server protocol. Zoals gebruikelijk is de client SMTP diegene die de sessie opstart en is de server diegene die antwoordt. Het formaat van een mail bericht De gebruiker hoeft zich hierover geen zorgen te maken, aangezien dit behandeld wordt door SMTP zelf.
Mail uitwisseling Het SMTP ontwerp is gebaseerd op een model van communicatie zoals in onderstaand figuur wordt aangetoond. Tengevolge van een mail verzoek van de gebruiker, start de zender SMTP een twee-wegs connectie op met de ontvanger SMTP. De ontvanger SMTP kan zodoende de ultieme bestemming of een tussenliggende bestemming zijn (mail gateway). De zender SMTP zal dusdanig commando’s genereren die beantwoord worden door de ontvanger SMTP.
fig. 2.9
Model voor SMTP
25
fig. 2.10
Normale SMTP data stroming
SMTP mail transactie stroming Niettegenstaande alle mail commando’s en antwoorden precies bepaald zijn, kan de uitwisseling precies gevolgd worden in bovenstaande figuur. Alle uitgewisselde commando’s/antwoorden/data zijn tekst lijnen, afgesloten door een . Alle antwoorden hebben een numerieke code in het begin van de lijn. •
De zender SMTP zet een TCP verbinding op met de destinatie SMTP en wacht dan tot de server een 220 Service ready boodschap zendt of een 421 Service not available boodschap wanneer het voor de bestemming tijdelijk niet mogelijk is om verder te gaan.
26
•
HELO wordt dan verzonden, waarna de ontvanger zichzelf zal identificeren door zijn domein naam terug te zenden. De zender SMTP kan dit dan gebruiken om te ve rifiëren of hij wel verbonden is met de
correcte
SMTP
bestemming.
Als de zender SMTP SMTP Service Extensions ondersteund zoals gespecificeerd in RFC 1869, mag het een EHLO commando verzenden in plaats van het HELO commando. Een ontvanger SMTP die geen service uitbreidingen ondersteund zal antwoorden met een 500 Syntax error, command unrecognized boodschap. De zender SMTP zou dan moeten herproberen met een HELO, of als zij het bericht niet kan verzenden zonder een of meerdere service uitbreidingen dient ze een QUIT boodschap
te
verzenden.
Als een ontvanger SMTP service uitbreidingen ondersteund, zal ze antwoorden met een 250 OK boodschap die meerdere lijnen omspant in welke zich een lijst van alle service uitbreidingen bevindt die ze ondersteund. •
De zender initieert nu de start van een mail transactie door een MAIL commando te verzenden naar de ontvanger. Dit commando bevat het omgekeerde pad (reverse-path) dat gebruikt kan worden om fouten te rapporteren. Bemerk dat het pad meer kan zijn dan enkel het gebruikers mailbox@host domein paar. Daarbovenop kan het de lijst van de routing hosts bevatten. Een voorbeeld van dit is wanneer we een mail bridge passeren, of wanneer we expliciete routing informatie voorzien in het bestemmingsadres. Als de informatie geaccepteerd wordt, zal de ontvanger antwoorden met een 250 OK.
•
De tweede stap van de eigenlijke mail uitwisseling bestaat uit het voorzien van de server SMTP met de bestemmingen van de boodschap. Dit omdat er meer dan één ontvanger kan zijn. Dit wordt uitgevoerd door één of meerdere RCPT TO: commando’s te voorzien. Elk van deze commando’s zal een 250 OK antwoord ontvangen in het geval de bestemming gekend is bij de server, in het andere geval wordt een 550 No such user here teruggestuurd.
•
Op het oge nblik dat alle RCPT commando’s verzonden zijn, verstrekt de zender een DATA commando om de ontvanger te verwittigen dat de inhoud van de boodschap nu volgt. De server antwoordt dan met een 354 Start mail input, end with .. Bemerk de eindbepalin g die de zender dient te gebruiken om de berichtdata te beëindigen.
•
De client verzendt nu de data lijn na lijn, en beëindigd deze met een vijf karakter sequentie . lijn waarop de ontvanger antwoordt met een 250 OK of een toepasselijke foutboodschap als er iets fout gelopen is.
•
Nu beschikken we over meerdere mogelijke acties:
27
o De zender hoeft geen boodschappen meer te verzenden. Hij of zij zal de connectie beëindigen met behulp van een QUIT commando, wat beantwoord zal worden met een 221 Service closing transmission channel reply. o De zender hoeft geen boodschappen meer te verzenden, maar is klaar om boodschappen te ontvangen van de andere zijde (indien er zijn). Hij of zij zal nu het TURN commando uitvoeren. De twee SMTPs veranderen nu van rol in het zender/ontvanger spel en de zender (de vroegere ontvanger) kan nu boodschappen beginnen te verzenden zoals beschreven in het derde puntje hierboven. o De zender dient nog een andere boodschap te verzenden, en begint hiervoor terug bij stap 3 zoals hierboven beschreven om een nieuw MAIL commando te verzenden.
SMTP commando’s Semantiek van de commando’s: SMTP commando’s zijn karakter strings die beëindigd worden door . De commando codes zelf zijn alfabetische karakters. •
HELLO (HELO): Dit commando wordt gebruikt om de zender SMTP te identificeren ten opzichte van ontvanger SMTP.
•
MAIL (MAIL): Dit commando wordt gebruikt om een mail transactie te initiëren waarin de mail data wordt afgeleverd in één of meerdere mailboxen. Het argument bevat een terugzendadres.
•
RECIPIENT (RCPT): Dit commando wordt gebruikt om een individuele ontvanger van de mail data te identificeren, meerdere ontvangers worden gespecificeerd door meermaals dit commando te gebruiken.
•
DATA (DATA): De ontvanger behandelt de lijnen die volgen op dit commando als mail data van de zender. Dit commando zorgt ervoor dat de mail data van dit commando toegevoegd wordt aan de mail data buffer. De mail dat mag eender welke van de 128 ASCII code karakters bevatten. De mail data wordt beëindigd met de karaktersequentie “.”. Het einde van de mail data stipuleert dat de ontvanger nu de opgeslagen mail transactie informatie verwerkt. Als alles correct verwerkt is zendt de ontvanger een OK reply.
•
RESET (RSET): Dit commando duidt aan dat de huidige mail transactie afgebroken moet worden. Alle opgeslagen zenders, ontvangers en mail data moeten genegeerd worden, en alle buffers en status tabellen moeten leeggemaakt worden. De ontvanger moet een OK reply teruggeven.
•
VERIFY (VRFY): Dit commando vraagt de ontvanger te bevestigen dat het argument een gebruiker identificeert. Als het een gebruiker is, wordt de gebruikersnaam en de volledige naam (als die gekend is) van de gebruiker teruggegeven.
28
•
QUIT (QUIT): Dit commando duidt aan dat de ontvanger een OK reply moet zenden en sluit dan de TCP connectie af.
SMTP replies De vorm van de antwoord berichten is identiek aan de vorm als bij FTP, met andere woorden, neem een kijkje in de FTP replies om hierover meer te weten te komen.
29
3. De controles In dit hoofdstuk bespreken we welke soort controle/test we kunnen uitvoeren op een bepaald protocol. Uiteindelijk worden alle testen gecombineerd.
3.1. ICMP controle Ping is de eerste plaats waarbij we stoppen voor netwerk troubleshooting. Het is een uiterst handig gereedschap om netwerk problemen te signaleren.
Hoe de beschikbaarheid van hosts testen op een netwerk De Echo en Echo Reply zijn de enige soort ICMP pakketten waarvan we gebruik maken. Met deze pakketten worden de gewenste hosts gecontroleerd indien ze nog actief zijn op het netwerk. Een antwoord op een echo wordt geëvalueerd als een positieve controle. Op het ogenblik dat er geen antwoord ontvangen wordt op een echo is de host niet bereikbaar. Dit betekent niet noodzakelijk dat de host niet actief is. Het foutlopen van de echo kan ook een andere oorzaak hebben. Het pakket kan mogelijks de bestemming niet eens bereikt hebben, of de bestemming kan misschien over een firewall beschikken dat geen ICMP pakketten toelaat. Het verloren gaan van pakketten kan veroorzaakt worden door een router die de pakketten opstapelt om ze dan te verzenden over een relatief trage verbinding, en de rij opgestapelde pakketten is helaas te groot geworden waardoor er pakketten weggeworpen worden. Er zijn bepaalde situaties, meer bepaald situaties in dicht bevolkte wide-area netwerken, waarin TCP implementaties niet op een continue manier kunnen werken zonder pakketten te laten vallen. Doch is er geen enkele reden om zich hierover zorgen te maken, aangezien TCP de data die verloren is gegaan opnieuw zal verzenden, maar dit zal het netwerk niet sneller maken. Indien u beschikt over snelle verbindingen die niet veel congestion vertonen, kan de oorzaak ergens anders liggen – link-level fouten zijn de tweede meest gebruikelijke oorzaak van pakke t verlies. Aangezien het IP protocol niet kan garanderen dat een pakket afgeleverd wordt, is het niet toegelaten te beslissen dat een host niet bereikbaar is op het netwerk als deze beslissing steunt op een enkel pakket. Omwille van deze reden wordt er dus steeds een reeks pakketten verzonden. Dit is echter enkel het geval wanneer we niet meteen een antwoord krijgen van de host. Als de host meteen antwoord blijft de check beperkt tot dit ene pakket. In het andere geval wordt er een aantal pakketten verzonden waarbij dit aantal bepaald wordt door de gebruiker. Het niet bereiken van een host wordt beslist aan de hand van een timeout. Op het ogenblik dat een bepaald tijdsinterval verloopt (dan is er nog geen antwoord ontvangen van de host) beslist men om het pakket als verloren te beschouwen. Wat er precies verkeerd is gelopen weet
30
men dan natuurlijk niet, maar we weten dan wel dat er iets niet correct is verlopen. Deze stappen worden voorgesteld in onderstaande figuur.
fig. 3.1
Een controle aan de hand van ICMP
Het tijdsinterval kan nog op een andere manier gebruikt worden. Op het ogenblik dat er een antwoord verkregen wordt, kunnen we de tijd beschouwen als de periode dat de controle nodig heeft om een andere host te bereiken en een antwoord terug te zenden. Deze tijden worden typisch Round Trip Times (RTT) genoemd. Indien deze gegevens dan verzameld worden kan men statistische gegevens bijhouden over het controleren van die host. Dit is zeer handig op het ogenblik men het verkeer op het netwerk wil beschouwen. Als er dan sprake is van fluctuerende RTT’s dan kunnen ze veroorzaakt worden door ongeveer dezelfde oorzaken die pakket verlies veroorzaken. Als u deze symptomen bemerkt, controleer dan op routing updates of andere verkeer dat voorkwam in dezelfde periode als het probleem. De slechte prestatie van het netwerk kan over het algemeen getraceerd worden tot enkele trage links. De drukste momenten worden dan voor de hosts zichtbaar aan de hand van deze testgegevens. Deze eigenschap is
31
dan natuurlijk enkel handig voor een lokaal netwerk. De werking van het Internet is van teveel andere factoren afhankelijk. Een andere optie bij de ping is pakketten te verzenden met verschillende grootte. De grootte kan dan eveneens bepaald worden door de gebruiker. Indien een TTL (Time To Live) waarde meegegeven wordt, kan men bekijken hoe ver de bestemming zich bevindt. De afstand wordt hier uitgedrukt aan de hand van tussenliggende hosts. Deze eigenschap wordt volledig benut door het stukje gereedschap dat we kennen bij de naam Traceroute. Ping (Packet InterNet Groper) Ping is uiteindelijk de simpelste van alle TCP/IP applicaties. Het zendt één of meer IP datagrammen naar een opgegeven host waarbij het een antwoord wenst te krijgen, hierbij worden dan de RTT gemeten. Op het ogenblik dat je een host kan pingen, dan kan men normaal gesproken andere applicaties zoals Telnet en FTP gebruiken om de host te bereiken. Maar met de stijgende noodzakelijkheid van veiligheid op het Internet, en het gebruik van firewalls die de toegang tot netwerken bepalen door middel van protocol en/of poort nummer, is dit langer steeds het geval. Niettegenstaande is het testen van de bereikbaarheid van een host nog steeds een poging doen om het te pingen.
Traceroute Het traceroute programma kan handig zijn om te debuggen. Traceroute laat toe de route die IP datagrammen tussen twee hosts volgen te bepalen. Traceroute is gebaseerd op ICMP en UDP. Het zendt een IP datagram met een kleine TTL waarde (om te beginnen 1) naar de bestemming. De eerste router die dan het datagram bekijkt zal dan de TTL decrementeren, en een ICMP Time Exceeded bericht terugzenden waarbij het datagram daarna genegeerd wordt door de eerste router. Op deze manier wordt de eerste router op het pad geïdentificeerd. Dit proces kan herhaald worden met steeds een iets grotere TTL om de routers de identificeren op weg naar de bestemming. Traceroute verzendt UDP datagrammen naar de bestemming die een poort nummer aanspreken dat buiten het normale bereik ligt. Dit laat traceroute toe om te bepalen wanneer de bestemming bereikt werd, meer bepaald, wanneer een ICMP Port Unreachable bericht ontvangen wordt.
Verder controleren Stel dat alle controles (die we later nog zullen bespreken) falen, dan dienen we een eerst en vooral een ping te doen op de locale netwerk interface. Op deze manier komen we dan te weten als het probleem zich op de controlerende host bevindt. Alle controles kunnen dan uitgesteld of gestopt worden totdat het
32
probleem bij de controlerende host opgelost is. Als de controlerende host geen correct antwoord krijgt op een lokale ping, dan kan dit misschien betekenen dat de TCP/IP stapel nog niet geïnitialiseerd is. Bij een controle door middel van ping kan men al heel wat te weten komen over het netwerk. Toch zouden we de controle kunnen verbeteren door zowel ping als traceroute te gebruiken. Stel dat we ons in het volgende scenario bevinden: we willen een host/bestemming controleren indien hij nog actief is op het Internet/netwerk, maar door een of andere reden kunnen we de host niet bereiken. We blijven nu natuurlijk zitten met de vraag waar het probleem zich voordoet. Indien we een host controleren die rechtstreeks op de controlerende host is aangesloten kunnen we het probleem snel vinden. Deze situatie zal zich echter uiterst zelden voordoen. Omwille hiervan voeren we na de falende ping controle een traceroute uit op dezelfde bestemming. De resultaten die de traceroute dan teruggeeft analyseren we en geven we terug aan de gebruiker zodat hij kan zien waar de traceroute verkeerd loopt. Aan de hand van de resultaten van de traceroute kan een betere sturing gegeven worden bij het oplossen van de problemen op het netwerk. Indien we hier eveneens ook nog eens de historiek van de controles bij kunnen betrekken, (het probleem kan zich bijvoorbeeld slechts op bepaalde tijdstippen voordoen) zouden we een beter beeld kunnen schetsen van het probleem. Let wel op dat deze raadgevingen slechts gezien mogen worden als indicators.
>ping ftp.microsoft.com Pinging ftp.microsoft.com [207.46.133.140] with 32 bytes of data: Request Request Request Request
timed timed timed timed
out. out. out. out.
Ping statistics for 207.46.133.140: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), >tracert ftp.microsoft.com Tracing route to ftp.microsoft.com [207.46.133.140] over a maximum of 30 hops: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
<1 25 25 28 53 * 68 108 119 172 182 165 198 173 171 * * *
ms ms ms ms ms ms ms ms ms ms ms ms ms ms
<1 20 22 12 10 * 10 93 93 199 165 170 165 175 167 * * *
ms ms ms ms ms ms ms ms ms ms ms ms ms ms
<1 22 10 11 7 * 8 93 102 175 163 169 155 166 158 * * *
ms ms ms ms ms
ELEANOR [10.0.0.254] D5E00001.kabel.telenet.be [213.224.0.1] 10.30.48.57 D5E0FD81.kabel.telenet.be [213.224.253.129] IBNOCM02-SRP5-0.telenet-ops.be [213.224.126.2] Request timed out. ms bcr1-sonet6-0-0-0.Brussels.cw.net [206.24.147.177] ms dcr2-loopback.Washington.cw.net [206.24.226.100] ms agr3-so-2-0-0.Washington.cw.net [206.24.238.186] ms acr2-loopback.Seattle.cw.net [208.172.82.62] ms bpr1.SeattleSwitchDesign.cw.net [208.172.82.7] ms microsoft-itg.SeattleSwitchDesign.cw.net [208.173.49.86] ms 207.46.154.5 ms 207.46.155.17 ms iuscmscomc7505-fe-1-0-0.msft.net [207.46.129.165] Request timed out. Request timed out. Request timed out.
33
19 20 21 22 23 24 25 26 27 28 29 30
* * * * * * * * * * * *
* * * * * * * * * * * *
* * * * * * * * * * * *
Request Request Request Request Request Request Request Request Request Request Request Request
timed timed timed timed timed timed timed timed timed timed timed timed
out. out. out. out. out. out. out. out. out. out. out. out.
Trace complete.
fig. 3.2
Resultaten van een ping en traceroute
In het bovenstaande voorbeeld zien we dat de host niet bereikbaar is aan de hand van een ping. Als we nu het pad naar die host bekijken zien we dat de host inderdaad niet kunnen bereiken. Op dit ogenblik kunnen we beslissen dat het foutlopen van de communicatie ofwel de bestemming of in een van de voorgaande hosts ligt. Waarschijnlijk bevindt de ‘fout’ zich hier in de firewall, want door middel van een FTP cliënt is de host wel te bereiken.
34
3.2. HTTP controle Het controleren van de activiteit en de bereikbaarheid van een HTTP server bij HTTP/1.0 kan simpelweg gedaan worden door een pagina op te vragen door middel van een GET commando. Door deze pagina op te vragen laten we de server een activiteit uitvoeren. Hierbij is het wel noodzakelijk dat we de pagina niet lokaal op de controlerende host cachen. Eveneens mag de pagina wel worden opgeslagen in een tussenliggende proxy, maar we zorgen er steeds voor dat de verzochte pagina opgehaald wordt op de originele server. De controle hoeft zich echter niet te beperken tot enkel html pagina’s. Eender welk (bestaand) object kan afgehaald worden, dit kan een html pagina, een javascript, een zip-file, etc zijn. Als de hoeveelheid data die langs het netwerk stroomt beperkt moet blijven, kan de controle eveneens aan de hand van een HEAD commando gebeuren. Hierbij wordt dan meta-informatie over het gevraagde object terug gezonden zonder dat er zich data in het lichaam van het bericht bevindt. Dit kan dan handig zijn in het geval de hoeveelheid data te groot is of indien men het netwerktrafiek gegenereerd door de tests wil verminderen. In het geval van HTTP/1.1kunnen we nog een stapje verder gaan. Naast het gebruikt va n de GET en HEAD methode kan er eveneens gebruik gemaakt worden van de TRACE methode. De TRACE methode laat namelijk toe om te zien op welke manier het bericht opgehaald werd en langs welke tussenliggende stappen de informatie stroomde. Deze informatie wordt normaal gesproken gebruikt tijdens testen en als diagnostische data. Maar hier kan het voor het monitoren uiterst handig zijn. Antwoorden van de server Een controle zal normaal gesproken steeds gebeuren op eenzelfde object. Van dit object zijn we dan ook zeker dat het bestaat als we voortdurend antwoord krijgen op ons verzoek. Vooral een status code van 200 met andere woorden. Op het ogenblik dat de statuscode geen 200 is kan dit gemeld worden aan de gebruiker, dit betekent namelijk dat er iets fout is gelopen met het ophalen van het gevraagde object. Krijgen we totaal geen antwoord terug van de server, dan zal ofwel de HTTP service niet meer draaien, ofwel kunnen we geen verbinding meer maken met de server. Het bijhouden van een geschiedenis hiervoor kan meer duidelijkheid scheppen over de opduikende problemen. De controles kunnen dan terug een indicator zijn.
35
fig. 3.3
Controle van een HTTP server
Uitgebreide controle Naast het testen van de HTTP service aan de hand van enkele commando’s, zouden we een iets uitgebreidere controle kunnen invoeren. Hierbij laten we de controle steeds eenzelfde webobject afhalen van de server en houden we enige gegevens over dit object bij. Deze gegevens bestaan dan uit bijvoorbeeld de grootte en de inhoud van het webobject. Deze gegevens worden dan vergeleken met de gegevens van een lokale kopie van dit webobject. Indien er dan enig verschil is kunnen we dit rapporteren aan de verantwoordelijke, maar niet zonder opnieuw proberen. Dit is een gouden regel doorheen al onze tests, in geval van faling wordt er opnieuw geprobeerd. Daarnaast kunnen er ook gegevens over de transfersnelheid, de bandbreedte, etc bijgehouden worden. Deze gegevens vormen dan een geschiedenis van de testen.
36
3.3. FTP controle Het controleren van een FTP server doen we op volgende manier. We proberen eerst een verbinding te maken met de server waarbij we (indien dit nodig is) ons identificeren. Op het ogenblik dat we ingelogd zijn op de server weten we dat het opzetten van een controleconnectie met die server lukt. We testen nu het opzetten van een dataconnectie met diezelfde server. Om zo weinig mogelijk netwerkverkeer te genereren kiezen we niet om een bestand over te zetten, maar maken we gebruik van het commando LIST. Dit commando zorgt ervoor dat er een lijst gezonden wordt van de server naar de passieve dataconnectie. Als het pad een directory specificeert of een andere groep van bestanden, dan zou de server een lijst van de bestanden in die directory moeten doorzenden. Als het pad een bestand specificeert zou de server huidige informatie over dit bestand moeten terugzenden. Een null argument bepaalt de huidige directory of de default directory. We geven echter een argument mee, en dit argument is een onbestaand bestand. De naam waarop gezocht wordt is uniek, waardoor de kans dat er een bestand met deze naam voorkomt op de server heel klein is. De server voert uiteindelijk wel een zoekoperatie uit in de huidige directory, maar deze zoekoperatie is lokaal en verbruikt enkel een klein aantal CPU cycli. De hoeveelheid data die dan doorgezonden wordt als resultaat is heel klein. Op deze manier verbruiken we niet teveel resources, zowel resources van het netwerk als resources van de FTP server. Als er geen resultaat terugkomt van de FTP server dan toont dit aan dat er zich een probleem voordoet met het opzetten van een data connectie tussen de controlerende host en de server. Dit wordt dan ook gemeld aan de gebruiker. Niet kunnen inloggen op de server betekent dat we over een verkeerde login en paswoord beschikken of dat de FTP dienst op de server niet correct werkt. Het verlopen van een tijdslimiet terwijl we een connectie willen opzetten met de server wijst er op dat ofwel de server niet actief is op dat we de server niet kunnen bereiken door één of ander netwerkprobleem. Een controle wordt in figuur 3.4 geïllustreerd.
37
fig. 3.4
Controle van een FTP server
Uitgebreide controle De uitgebreide controle gaat op dezelfde manier tewerk als bij de HTTP controle. Eenzelfde object wordt van de FTP server afgehaald en de gegevens van dit pas afgehaalde object worden vergeleken met de gegevens van een lokale kopie van ditzelfde object. In geval van een falende controle wordt dit dan gemeld aan de netwerkverantwoordelijke. Omgekeerd lukt dit ook, om bijvoorbeeld een bestand op de server te plaatsen of om dit beiden te combineren. Men transfereert dan een bestand naar de server, waarna men het terug afhaalt. De gegevens na verzenden en ontvangen worden dan met elkaar vergeleken. Daarnaast kunnen er ook gegevens over de transfersnelheid, de bandbreedte, etc bijgehouden worden. Deze gegevens vormen dan een geschiedenis van de testen.
38
3.4. POP3 controle Controleren van een POP3 server gaat als volgt: we loggen in op de server door middel van een gebruikersnaam en een paswoord. Het is bekend dat de gebruikersnaam en het paswoord als gewone tekst verzonden worden voor een POP3 server, hier is dus voorzichtigheid geboden. Het is misschien aangewezen om een speciale account aan te maken enkel en alleen voor de controle. Nadat er ingelogd is, wordt er een STAT commando doorgezonden. Dit kon eigenlijk eveneens een NOOP commando zijn, zolang de server maar een antwoord kan zenden. Hetzelfde geldt hier terug net als bij de controles van de andere soorten servers. Als we niet kunnen inloggen dan is dit een teken dat er iets verkeerd is met de POP3 dienst. Als we de server totaal niet kunnen bereiken, dan duidt dit op een probleem met het netwerk of met de host zelf.
fig. 3.5
Controle van een POP3 server
Uitgebreide controle In samenwerking met een SMTP test kan een uitgebreide controle gedaan worden. Na het verzenden van een e-mail door middel van de SMTP test worden de gegevens in verband met deze e-mail doorgegeven aan de POP3 test die de account van de ontvanger van de e-mail beheert. Dezelfde e-mail wordt dan
39
uiteindelijk afgehaald door de POP3 test en de gegevens van de afgehaalde e-mail kunnen dan vergeleken worden met de door de SMTP test doorgezonden gegevens. Daarnaast kunnen er ook gegevens over de transfersnelheid, de bandbreedte, etc bijgehouden worden. Deze gegevens vormen dan een geschiedenis van de testen.
40
3.5. SMTP controle Controleren van een SMTP server gaat als volgt: indien het nodig is om in te loggen dan vindt dit eerst plaats. Daarna wordt een korte conversatie met de server gestart. Eerst wordt een HELO/EHLO gestuurd naar de server, waarop we een antwoord krijgen. Daarna wordt de QUIT opdracht doorgezonden waardoor er uitgelogd wordt. Hetzelfde geldt hier als bij de controles van de andere soorten servers. Als we niet kunnen inloggen of geen antwoord krijgen bij een HELO/EHLO dan is dit een teken dat er iets verkeerd is met de SMTP dienst. Als we de server totaal niet kunnen bereiken, dan duidt dit op een probleem met het netwerk of met de host zelf.
fig. 3.6
Controle van een SMTP server.
Uitgebreide controle In samenwerking met een POP3 test kan een uitgebreide controle gedaan worden. Na het verzenden van een e-mail door middel van de SMTP test worden de gegevens in verband met deze e-mail doorgegeven aan de POP3 test die de account van de ontvanger van de e-mail beheert. De inhoud van de e-mail, de
41
grootte van de e-mail, de manier waarop de e-mail gecodeerd werd, etc worden dan doorgezonden. De POP3 test haalt de e-mail dan af van deze account en vergelijkt dan al deze gegevens. Daarnaast kunnen er ook gegevens over de transfersnelheid, de bandbreedte, etc bijgehouden worden. Deze gegevens vormen dan een geschiedenis van de testen.
42
3.6. Samenwerking van de protocollen Alle voorgaande protocollen kunnen we nu beginnen combineren. Als een HTTP, FTP, POP3 of SMTP controle faalt, hierbij bedoelen we dat we de host niet kunnen bereiken, kunnen we het netwerk controleren aan de hand van een ICMP controle. Er wordt eerst een ping gedaan naar die host. Indien deze antwoordt, dan weten we dat de host nog actief is op het netwerk. We kunnen dan nogmaals de HTTP, FTP, POP3 of SMTP controle uitvoeren. Indien deze terug faalt, weten we met zekerheid dat die dienst op de host niet meer correct werkt. In het andere geval, als de ping faalt kunnen we de traceroute inschakelen om een beter zicht van het probleem te verkrijgen. De traceroute resultaten geven dan een beter beeld van de probleemsituatie. Deze gehele combinatie van controles geeft ons de mogelijkheid om degelijke controles uit te voeren en een mooi beeld te scheppen van wat er verkeerd gaat.
fig. 3.7
Samenwerken van de verschillende controles.
43
3.7. Stand van zaken in de implementatie Van al de zonet besproken protocollen werden in de ontworpen applicatie alle eenvoudige tests opgebouwd. Al deze tests werken uiteraard op de gewenste manier. Voor ICMP betekent dit dat de ping geconstrueerd werd, maar dat de traceroute nog niet aanwezig is. Doch werd de applicatie zo opgebouwd zodat deze uitbreiding makkelijk bijgevoegd kan worden. Voor de HTTP, FTP, POP3 en SMTP testen geldt hetze lfde. Alle eenvoudige testen werken, maar er kan makkelijk uitgebreid worden. Naast rekening te hebben gehouden met uitbreiding bevatten sommige protocollen nog een verdere uitbreiding qua functionaliteit. Het is bijvoorbeeld mogelijks om een SMTP object aan te maken zodat er, in geval van negatief resultaat, een e-mail verzonden kan worden naar de persoon die verantwoordelijk is voor het netwerk. E-mail kan gecodeerd worden, in MIME formaat opgebouwd worden, etc. Bij dergelijke applicatie is een enkel jaar en één enkele persoon te weinig om alle uitgebreide tests te implementeren. Niettegenstaande is het toch een enorme uitdaging geweest om de applicatie zo ver te brengen.
44
4. De applicatie 4.1. Probleemstelling Stel, uw bedrijf of organisatie beschikt over een uitgebreid netwerk. Om alle personen die gebruik maken van dit netwerk te kunnen garanderen dat zij ten allen tijde van deze infrastructuur gebruik kunnen maken, dient de status van het netwerk, en bijgevolg de status van alle servers gecontroleerd te worden. Deze controle kan men aan de gebruikers overlaten door hen te laten melden dat er zich een probleem met het netwerk of een server voordoet. Indien deze controle automatisch zou gebeuren, dan zouden we beter en sneller kunnen ingrijpen. Deze netwerkgerelateerde tests kunnen zich tot een basistest beperken of een heel intensieve en uitgebreide controle bevatten. Verschillende protocollen moeten hierbij ondersteund worden. De ideale oplossing is wanneer deze tests periodiek gebeuren en bij een falende test de verantwoordelijke netwerkbeheerder verwittigen dat er iets verkeerd gaat. De applicatie die instaat voor deze tests moest worden ontwikkeld. Wat houdt deze netwerk service monitor (NSM) nu juist in? De NSM is een geavanceerd stukje gereedschap dat een groot aantal netwerk gerelateerde tests kan uitvoeren zoals een simpele ping (ICMP) test of meer geavanceerde tests voor web servers (HTTP) , FTP servers, e-mail servers, news servers, op maat gemaakte TCP port scans … Het objectief van deze thesis is het ontwikkelen van deze NSM. De ontwikkeling zelf diende te gebeuren in twee fasen. Ten eerste het ontwikkelen van een framework voor de NSM, waarop dan een simpele test wordt uitgevoerd. Optioneel kan in tweede fase de NSM uitgebreid worden met meer geavanceerde en nauwgezette testen. Dit zou performantietesten kunnen zijn voor web servers, ftp servers, e-mail servers… Er wordt een verschil gemaakt tussen de fysische testen en de logische testen. Onder een fysische test verstaan we de beschikbaarheid van een host (eventueel een server) op het netwerk testen (aan de hand van een ICMP test). Daar alle tests verlopen over een IP netwerk en ICMP zoals besproken deel uitmaakt van het IP protocol, kan iedere host op het netwerk getest worden.Dit geldt namelijk enkelals de firewall of een anders applicatie van een host de ICMP pakketten niet tegenhoudt. Onder een logische test verstaan we het controleren van de goede werking van een server. Meer bepaald, er wordt een communicatie opgezet tussen de NSM en de server waarbij de NSM de ontvangen data van de server analyseert. Daar de testen, uitgevoerd door de NSM, periodiek gebeuren (het is een continue dienst) is het enorm belangrijk om het netwerkverkeer dat hierbij gegenereerd wordt zo minimaal mogelijk te houden.
45
fig. 4.1
Framework van de NSM
46
4.2. Aanvang van de applicatie Het framework kan in grote lijnen als volgt beschreven worden: 1. Om een correcte werking van de applicatie te garanderen, is er nood aan een opslagmogelijkheid voor de configuratie -instellingen. Een open architectuur is hiervoor gewenst. Dit betekende dat er als ontwikkelaar gekozen koon worden voor bijvoorbeeld een simpele tekstbestand, of een .csv bestand, … Er werd echter geopteerd voor een geavanceerder, en bijgevolg flexibeler, opslag methode gebaseerd op XML. 2. Ontwikkelen van een service (dienst) voor Windows 2000, dat de testen uitvoert en de resultaten van de testen kan doorzenden. Enkele technologieën die hiervoor nodig zijn, zijn C++ (Visual Studio omgeving), TCP/IP, Win32, MFC (Microsoft Foundation Classes) en DCOM (Distributed Component Object Model). 3. Ontwikkeling van een client GUI (Graphical User Interface) voor de configuratie van de NSM. 4. Ontwikkeling van een GUI voor de representatie van de test resultaten. Er werd eerst begonnen met het ontwikkele n van de Windows 2000 service, dat de DCOM server objecten bevat, alsook met het opzetten van een structuur voor de opslag van de configuratie gegevens en de testresultaten.
47
4.3. Structuur van de applicatie 4.3.1.
COM
Zoals de naam laat vermoeden is het Component Object Model een model dat gebruikt kan worden om software te bouwen. Daar het een model is, wordt COM volledig gespecificeerd
in een formeel
document genaamd “The Component Object Model Specification”. Dit document specificeert een binaire standaard die he terogene componenten toelaat om samen te werken met elkaar. Van COM wordt gezegd dat het een binaire standaard is omdat het één component toelaat om een andere component te gebruiken zonder dat hierbij de broncode van deze tweede component gekend moet zijn. Naast het feit dat het een binaire standaard is, specificeert COM een aantal regels en benodigdheden om software componenten te bouwen. Niettemin, daar het enkel een specificatie is, legt het geen gebruik van een bepaalde taal, tool, of besturingssysteem op om de component software te creëren. Zoals voorgesteld wordt in onderstaande figuur, bevat de COM specificatie verscheidene voorheen succesvolle technologieën. Eén technologie waarvan COM gebruik maakt is dynamisch linken. De andere twee belangrijke technologieën zijn objectoriëntatie en het client/server model.
fig. 4.2
4.3.2.
Vorige technologieën die gebruikt worden bij COM
DCOM
Met client/server en gedistribueerde technologieën, kan men het werk distribueren en minder monolithische applicaties ontwikkelen. Wat verschillend is van monolithische software is dat een component een stuk software is met een goed gedefinieerd doel. Het is makkelijk te onderhouden en makkelijk opnieuw te gebruiken op een binair niveau. Bemerk dat er wel een drastisch verschil is tussen
48
een component een ‘static library’. Een component kan opnieuw gebruikt worden op een binair niveau en een ‘static library’ niet. Dit betekent dat je een component in uw applicatie kunt pluggen zonder dat je hierbij een header file of een import library nod ig hebt. Dit plug-in aspect van software integratie is het echte black-box programmeren. Je dient niets te weten over de code om de component te gebruiken. Eén van de voordelen van een component technologie is dat het geen enkele voorkeur heeft voor programmeertaal, besturingssysteem of netwerk. Hiermee bedoelen we dat ze kunnen communiceren zonder rekening te moeten houden met de verschillen in deze domeinen (dit is toch de uiteindelijke doelstelling). Hieronder zien we een voorbeeld van een software component, dat opgebouwd is uit COM klassen waarbij naar de runtime instanties gerefereerd wordt als COM objecten (of meer algemeen, gedistribueerde objecten). COM objecten zijn gebaseerd op de regels van het Component Object Model (COM). Een COM object stelt één of meerdere COM interfaces bloot om de diensten die het voorziet te ondersteunen.
fig. 4.3
Een COM component kan vele COM objecten bevatten.
Laten we nu als voorbeeld een simpele component applicatie beschouwen die gebaseerd is op DCOM.
49
fig. 4.4
Een simpele component-gebaseerd beeldverwerkingssyteem
Omdat deze componenten gedistribueerd kunnen worden over meerdere computers, is er nood aan een mechanisme dat instaat voor de communicatie. Indien voor TCP/IP geopteerd werd om deze interactie tussen de objecten te voltrekken, dan zou men volledig verzonken zijn in het schrijven van applicatie specifieke protocollen. Maar als er gebruik gemaakt wordt van een component technologie zoals DCOM, haalt men groot voordeel uit de gedistribueerde en plug-in interoperatibiliteit. Dit omdat DCOM transparantie van de locatie en binaire inter-operatibiliteit ondersteunt. In de figuur zien we bijvoorbeeld de OCRServer EXE, wat een component is. Het is een goed afgebakend stukje software dat ingezet kan worden en hergebruikt kan worden. Niettegenstaande is het toch makkelijk onderhoudbaar net omdat het klein en een goed afgebakende doelstelling heeft : om aan optische karakter herkenning te doen. Het bevat tevens een COM object, CoOcrEngine genoemd, dat een IOcr interface blootstelt. Het is deze interface die clients toelaat om OCR (Optical Character Recognition) uit te voeren. Zoals aangetoond kunnen componenten heel gedistribueerd zijn. Aangezien een component in cyberspace zowel server als client kan zijn, verzwakt het concept van client en server. Wat duidelijk moet worden uit voorgaande uiteenzetting is dat de Netwerk Service Monitor (NSM) als gedistribueerde black-box moet gezien worden. Nu staat de applicatie/service op zich, maar ze kan in een
50
veel breder concept betrokken worde n waarbij dan gebruik gemaakt wordt van deze component. Wat ook de bedoeling is! Het DCOM object staat in voor het continu uitvoeren van de testen, maar kan gemakkelijk geschakeld worden aan nieuwe componenten om zo de functionaliteit uit te breiden.
4.3.3.
Inte rface Methods van de NSM
Volgende methods zijn de enige methods die gekend moeten zijn om het DCOM object te kunnen hergebruiken.
HRESULT InitialiseService(); Deze method moet men aanroepen om de service op te starten. De method zal alle objecten construeren aan de hand van de configuratie bestanden (XML). Ofwel slaagt deze method in het opstarten van de functie ofwel faalt ze. De normale gebruiker die communiceert met de NSM zal zich normaal gesproken niet moeten aantrekken hiervan. De service zal namelijk opgestart worden door de netwerkbeheerder en continue lopen. HRESULT StopService(); Moet uitgevoerd worden om de service af te sluiten. Alles tests worden dan op een elegante manier stopgezet en alle geheugen dat ingenomen wordt, wordt dan opgeruimd zodat de service geen geheugen meer bezet. HRESULT StartAllServiceObjects(); Method om alle objecten te laten starten. De thread voor elke test wordt dan gecreëerd en de testen zelf worden aan de door de gebruiker voorop ingestelde frequentie uitgevoerd. HRESULT StopAllServiceObjects(); Method om alle objecten te stoppen. Alle threads worden hierbij stopgezet en alle geheugen dat hierbij niet meer gebruikt wordt, wordt opgeruimd. HRESULT PauseAllServiceObjects(); Method waarbij na aanroepen alle testen gepauzeerd worden. Hierbij worden de threads niet afgesloten maak enkel geblokkeerd in hun huidige toestand. HRESULT ResumeAllServiceObjects();
51
Na aanroepen van de method PauseAllServiceObjects(), kunnen alle gepauzeerde testen opnieuw aangevat worden door deze method aan te roepen. Het blokkeren van de threads wordt hierbij opgeheven waardoor zij opnieuw de testen kunnen beginnen uitvoeren. HRESULT StopObject([in] int nObjType, [in] BSTR bstrIpAddress); In het objecttype wordt een nummer meegegeven dat het type van het object bepaald. Het nummer dat voor een type geldig is wordt beschreven in een header file die meegeleverd wordt met de component. Momenteel kan het type ofwel een Ping, HTTP, FTP, POP3 of SMTP object zijn. In het tweede argument wordt dan de hostnaam bepaald, dit kan zowel aan de hand van een IP adres gebeuren als door middel van een string die de naam bepaalt, bijvoorbeeld www.google.com. Indien de argumenten beiden kloppen, dan wordt de test voor dat object gestopt en wordt de thread afgesloten. De return waarde bepaald hierbij of het stoppen van het object lukt, of het faalt of als het object bepaald door de argumenten niet gevonden kan worden. In het laatste geval betekent dit dan dat de meegeleverde argumenten niet correct waren. In alle volgende methods die gebruikt worden om een test te starten, stoppen, pauzeren of te resumen, blijft deze regel voor de return waarde gelden. HRESULT StartObject([in] int nObjType, [in] BSTR bstrIpAddress); Zoals hierboven gezegd werd, beschrijft het eerste argument het objecttype. In het tweede argument wordt dan de host bepaald waarvan de test moet opgestart worden. Bij het aanroepen van deze functie wordt een nieuwe thread aangemaakt en wordt gestart met het uitvoeren van de testen.
HRESULT PauseObject([in] int nObjType, [in] BSTR bstrIpAddress); Zoals besproken bij de method PauseAllObjects() wordt de thread gepauseerd, maar hier wordt dit gedaan enkel voor het object bepaald door de twee argumenten.
HRESULT ResumeObject([in] int nObjType, [in] BSTR bstrIpAddress); Een object waarvan de thread gepauzeerd was kan door middel van deze functie verder gezet worden. Het object wordt hierbij bepaald door beide argumenten. HRESULT StartAllObjectsFromHost([in] BSTR bstrHostname); Hierdoor worden alle tests die uitgevoerd worden op één host opgestart. HRESULT StopAllObjectsFromHost([in] BSTR bstrHostname);
52
Indien alle tests die uitgevoerd worden op een bepaalde moeten gestopt worden, kan men deze method aanroepen. Dit kan bijvoorbeeld het geval zijn wanneer we een host controleren aan de hand van een FTP controle en een HTTP controle. Indien de netwerkbeheerder dan beslist om deze server even van het netwerk af te halen om op deze manier een update of eender welke operatie uit te voeren, kan men al deze test laten stoppen door een enkele method aan te roepen.
HRESULT PauseAllObjectsFromHost([in] BSTR bstrHostname); Alle tests uitgevoerd op een bepaalde host op het netwerk worden hierbij gepauzeerd. HRESULT ResumeAllObjectsFromHost([in] BSTR bstrHostname); De gepauzeerde test worden opnieuw aangevat voor de gespecificeerde host. HRESULT GetAllServiceObjects([out] VARIANT *pvarServiceObjects); Wanneer men een lijst wil verkrijgen met de namen van alle hosts waarop een test wordt uitgevoerd, dan kan men deze lijst verkrijgen door deze method aan te roepen. Er moet wel als argument een wijzer meegeleverd worden naar een object van het type VARIANT. Deze VARIANT bevat dan een array die op zich een array van strings bevat onderverdeeld volgens het type van de test. HRESULT GetObjectInfo([in] int nObjType, [in] BSTR bstrIpAddress, [out] VARIANT* pvarResults); Als men van één object meer informatie te weten wil komen, men wil alle eigenschappen van dit object bekijken, dan moet men eerst het gewenste object bepalen door middel van de eerste twee argumenten. Alle eigenschappen worden dan teruggegeven in een lijst van strings die zich in de VARIANT bevindt. HRESULT AddObject([in] int nObjType, [in] VARIANT varObjData); Toevoegen van een nieuwe host waarop een test moet uitgevoerd worden. Het type van de test wordt bepaald door het eerste argument en het tweede argument bevat alle informatie om het nieuwe object bij te voegen. Hierbij bevat de VARIANT een array met één enkele string dat opgemaakt is in dezelfde manier als het XML bestand met de gegevens over dit object. HRESULT ChangeObject([in] int nObjType, [in] BSTR bstrHostname, [in] VARIANT varObjData); Bij het wijzigen van de gegevens van een bestaand object moet in de eerste twee argumenten het bestaand object bepaald worden. Het derde argument bevat alle nieuwe gegevens van het object en de
53
vorm van het derde argument is in dezelfde manier opgebouwd als bij het toevoegen van een nieuw object. HRESULT DeleteObject([in] int nObjType, [in] BSTR bstrHostname); Het te verwijderen object wordt volledig bepaald door de twee argumenten. De return waarde meldt dan indien de operatie succesvol was of indien de operatie faalde.
54
4.3.4.
XML
Wat is XML? XML is een opmaak (markup) taal voor documenten die gestructureerde informatie bevatten. De gestructureerde informatie bevat zowel inhoud (woorden, afbeeldingen, etc.) als een indicatie van wat voor rol deze inhoud speelt. Bijna alle documenten beschikken over een of andere structuur. Een opmaaktaal is een mechanisme om structuren in een document te identificeren. De XML specificatie definieert een standaard manier om enige opmaak aan documenten toe te voegen. Is XML zoals HTML? Neen. In HTML ligt zowel de tag als de semantiek van de tag vast. Het W3C werkt constant aan de uitbreiding van HTML om nieuwe tags te definiëren die de technologische veranderingen kunnen bijhouden en om variatie in presentatie (stylesheets) naar het web te brengen. XML specificeert noch semantiek, noch de tag verzameling. In feite is XML een meta-taal om opmaak talen te beschrijven. Met andere woorden, XML voorziet de faciliteiten om tags en de strucurele relatie tussen hen te definiëren. Aangezien er geen voor gedefinieerde tag verzameling is, kan er geen semantiek op voorhand vastliggen. Alle semantiek van een XML document zal ofwel gedefinieerd zijn door de applicaties die ze verwerken of door stylesheets. En net deze eigenschappen worden ten volle benut om een structuur op te zetten voor onze tests. Alle eigenschappen van de tests bevinden zich dan tussen de door ons gedefinieerde tags. Hoe ziet een XML document er nu uit? Elementen zijn de meest voorkomende vorm van opmaak. Afgebakend door het kleiner dan en het groter dan teken, identificeren de meeste elementen het type van de inhoud dat ze bevatten. Als een element niet leeg is, begint het met een start tag <element> en eindigt het met een eind-tag . Hieronder een voorbeeld van een XML configuratie bestand voor de NSM. In appendix A worden een aantal voorbeelden van XML bestanden bijgevoegd waarbij telkens één soort object beschreven wordt. In totaal bevinden er zich dus vijf verschillende XML bestanden in appendix A.
55
4.3.5.
Input/Output
Zoals besproken gebeurt de configuratie van de objecten aan de hand van XML bestanden. Naast deze XML bestanden is het eveneens mogelijk en zelfs wenselijker om nieuwe objecten bij te voegen / te veranderen / te verwijderen door gebruik te maken van de voorziene interface. Deze interface zal in punt 3.3.6 besproken worden. Op het ogenblik dat de service opgestart wordt, wordt er een object van de klasse CConfigData gecreëerd. Dit object blijft bestaan tijdens het draaien van de service en het staat in voor alle configuratie van de objecten. Wat wordt hiermee nu juist bedoelt? Bij het opstarten van de service worden alle XML bestanden bekeken en worden alle gegevens uit deze bestanden opgehaald om de objecten op te bouwen. Naast zijn functionaliteit tijdens het opstarten staat de klasse ook in om gedurende de werking van de service alle data die veranderd wordt, bijv oorbeeld bij het toevoegen, verwijderen of veranderen van objecten, op te slaan in de XML bestanden. Alle output wordt gegenereerd aan de hand van gebeurtenissen (events). Deze gebeurtenissen ontstaan wanneer een test faalt. De gegevens die hierbij doorgezonden worden bevinden zich in een “resource tabel”. Wat verstaan we hieronder? Deze tabel bevat een verzameling strings die het foutlopen van een test beschrijven. Deze strings zijn een beschrijving van de fout. Het grote voordeel van deze tabel is dat er gemakkelijk naar een andere taal overgeschakeld kan worden omdat enkel deze strings vertaald moeten worden. Hierbij wordt eveneens de bron van de fout vermeldt, het tijdstip waarop de fout gebeurde, de strengheid van de fout en het type van de test. Een voorbeeld van een mogelijke fout is dus: 2002/05/01 11:01:36
PING 10.0.0.138 The packet timed out.
56
4.3.6.
Werkwijze van de objecten
Iedere klasse die een protocol ondersteund, hieronder verstaan we de klassen voor de ping, http, ftp, pop3 en smtp implementatie zijn op eenzelfde manier opgebouwd. Al deze klassen bevatten de basisfunctionaliteit om een thread aan te maken, te starten, te stoppen, te pauzeren en te resumen. Wat zich in elke thread afspeelt is natuurlijk afhankelijk van het soort object. De klassen met de eigenlijke tests zijn gescheiden van de klassen met de basisfunctionalteit (hiermee bedoelen we de zonet besproken thread functionaliteit). Op deze manier kan er gemakkelijk een nieuwe test bijgevoegd worden zonder zich veel zorgen te moeten maken over deze basisfunctionaliteit. Naar het einde van de ontwikkelingsfase is het pas duidelijk geworden dat de klassen met basisfunctionaliteit van de vijf protocollen heel wat gemeen hadden. Dit door het toevoegen van functionaliteit aan de service. De klassen zouden nu gemakkelijk al hun eigenschappen kunnen overerven van een enkele basisklasse wat meteen ook op het plan stond om als eerste aanpassing door te voeren. Naast de thread functionaliteit bevat iedere klasse eveneens een aantal functies om het formaat van een alarm op te bouwen. Een alarm bevat enkel een heleboel gegevens die de oorzaak van de fout beschrijven en deze fout is natuurlijk heel sterk afhankelijk van de soort test. Naast deze functionaliteit naar threads toe beschikken ze over een hele verzameling get en set methoden. Dit om de eigenschappen gemakkelijk te kunnen veranderen. Deze omgeving waarin de tests worden uitgevoerd is volledig multi-threaded. We kunnen zelfs nog een stapje verder gaan en de omgeving free threaded noemen. Dit betekent dat alle tests concurrent gebeuren. Waarom werd nu net gekozen voor een multi-threaded omgeving en geen single threaded omgeving? Stel dat we onze NSM een honderdtal tests willen laten uitvoeren over ons netwerk. Daarbij kunnen we per test bepalen hoeveel maal er opnieuw geprobeerd moet worden voordat we de test als negatief kunnen beschouwen. Veronderstel nu dat er op een ping test een time -out van 10 seconden zit en dat we 5 maal moeten herproberen. Dit betekent dat wanneer de host op het netwerk niet bereikbaar is, we een eerste controle doen die 10 seconden duurt. Daarna wordt er nog 5 maal opnieuw geprobeerd met telkens dezelfde time-out. Samengeteld heeft deze test 60 seconden geduurd om te beslissen dat de host niet bereikbaar is. Op zich is dit niet zo erg, ware het niet dat alle andere tests die nog uitgevoerd moeten worden met een vertraging van 60 seconden. Op deze manier kunnen we niet garanderen dat tests met een bepaalde frequentie opnieuw uitgevoerd worden. Om dit wel te kunnen garanderen werd gekozen voor een multi-threaded omgeving. Het melden aan een gebruiker van een fout gelopen test gebeurt via één enkel kanaal. Dit kanaal (de interface _ISkyMonitorEvents) moet ondersteund worden door elke GUI die zich met de netwerk service monitor wil verbinden. Daarbij moet er een implementatie in de GUI voorzien worden voor één enkele method, nl. de method NotifyOfObjAlarm(VARIANT varAlarm). Aan de hand van deze method
57
wordt alle informatie over het foutlopen van een test doorgestuurd. De GUI kan hie rmee uiteindelijk doen wat hij wil, hij kan dit gebruiken om de ontvangen informatie te presenteren, om er bepaalde informatie uit te filteren, … Het meest interessante aan deze interface is dat het DCOM object niet dient te weten hoeveel GUI’s verbonden zijn met het object. Het DCOM object zal namelijk alle events automatisch doorsturen naar alle verbonden GUI’s. De applicaties die met het NSM DCOM object verbonden zijn dienen echter geen GUI’s te zijn, het kunnen eveneens andere applicaties zijn. De GUI wordt hier gebruikt als presentatielaag, maar de mogelijkheden zijn veel groter. Daar alle alarmberichten langs één kanaal vloeien, moet men rekening houden met concurrente toegang tot dit kanaal. Het is niet aanvaardbaar dat gegevens over het foutlopen van een test corrupt zouden toekomen. Daarom mag er slechts één object gebruik maken van dit kanaal. Alle andere objecten moeten dan even wachten tot dit kanaal terug vrijgegeven wordt. Na het vrijgeven is het dan de beurt aan één van de wachtenden. De implementatie werd gedaan aan de hand van critical sections, deze staan in voor de synchronisatie tussen de verschillende threads. Iedere object dat een test uitvoert moet dan natuurlijk een event kunnen creëren. Deze verbinding werd tot stand gebracht door gebruik te maken van een globaal object van de klasse COutputAlarms. Deze klasse omvat slechts één method en dit is het uitsturen van het alarm. Indien er bijvoorbeeld een databank gekoppeld wordt aan de NSM die alle gegevens verzameld, dan zouden we slechts deze klasse moeten aanpassen. Hieronder illustreren we de opbouw van de NSM aan de hand van een illustratie. Dit schept dan een visueel beeld van de opbouw.
58
fig. 4.5
Opbouw van de Netwerk Service Monitor
59
4.3.7.
De GUI
De GUI die ontwikkeld werd voor de NSM doet dienst als presentatie en testlaag. De GUI is hoogst waarschijnlijk tijdelijk, daar de NSM in een totaalpakket zal bijgevoegd worden, zal de GUI aangepast worden aan de eisen van dit totaalpakket en aan die vormgeving. Niettegenstaande doet de bestaande GUI toch dienst als controle en test programma. Merk wel op dat de GUI een volledig onafhankelijke applicatie is. De GUI roept enkel methods van de DCOM component aan, niks meer. De GUI bestaat uit twee delen. Het eerste deel staat in voor de configuratie en het tweede deel staat in voor de verzameling van de alarm gegevens. De configuratie interface wordt opnieuw opgedeeld in 3 stukken: 1. Een boomstructuur die de objecten verdeelt volgens functionaliteit. 2. De eigenschappen van het object dat geselecteerd werd uit de boomstructuur. 3. Filter op de alarm gegevens die binnenkomen. Enkel de gegevens van het geselecteerde object worden getoond.
fig. 4.6
De configuratie interface
De alarm interface verzamelt alle binnenkomende alarmgegevens in chronologische volgorde. Hierbij wordt bij ieder alarm het tijdstip van het alarm vermeldt, het type van het object, de host waarop de test werd uitgevoerd en de oorzaak van de falende test.
60
fig. 4.7
De alarm interface
Naast deze twee interfaces beschikt de gebruiker ook nog over een menu dat opgeroepen kan worden door op de rechter muistoets te klikken. Het menu laat toe om bepaalde objecten te starten, stoppen, pauzeren, hervatten, alsook om nieuwe objecten bij te voegen, te verwijderen en te veranderen.
fig. 4.8
Het rechts-klik menu
Hiernaast werd er een wizard geïmplementeerd voor het toevoegen van een object. De wizard bestaat uit 3 delen:
61
fig. 4.9
Deel 1 van de wizard
fig. 4.10
Deel 2 van de wizard
62
fig. 4.11
Deel 3 van de wizard (HTTP object)
63
4.4. Verbeteringen voor een opvolger Wat hier volgt zijn een aantal ideeën om de Netwerk Service Monitor te verbeteren en uit te breiden. •
Alle tests die momenteel geïmplementeerd zijn kunnen nog heel wat uitgebreid worden. Door zoveel mogelijk functionaliteit van een protocol te implementeren heeft de gebruiker/netwerkbeheerder een grotere controle over de tests die hij wil laten uitvoeren. Nemen we nu bijvoorbeeld het HTTP protocol, nu wordt een controle gedaan door een webobject af te halen, maar de controle zou eveneens kunnen gebeuren door automatisch een formulier in te vullen en dit dan door te sturen naar de webserver die dit formulier verwerkt. Dit is slechts één voorbeeld van een mogelijke uitbreiding. De mogelijkheden om namelijk uit te breiden zijn enorm.
•
Naast uitbreidingen binnen een protocol kan men uitbreiden naar andere protocollen. We denken hierbij aan protocollen zoals: o DNS (Domain Name Service) o HTTPS (HTTP Secure Socket Layer) o IMAP4 (Internet Message Access Protocol) o LDAP (Lightweight Directory Access Protocol) o NNTP (Network News Transport Protocol) o TCP PORT o RADIUS (Remote Authentication Dial-In Service) o SNMP (Simple Network Management Protocol) o DHCP (Dynamic Host Configuration Protocol) o NTP (Network Time Protocol) o …
•
De ICMP testen aanpassen zodat de applicatie klaar is voor IPv6.
•
Naast de verbeteringen naar protocollen toe kan er uitgebreid worden naar algemene zaken. We doelen hier vooral op het implementeren van kwaliteitscontroles. Het kan bijvoorbeeld zijn dat een webpagina van de webserver opgevraagd wordt, maar als dit meer dan 50 seconden duurt, duidt dit eveneens op een probleem. Er wordt dan getest of de verbinding wel snel genoeg is en indien dit het geval is wordt een kwaliteitscontrole gedaan van de server waarbij de antwoordsnelheid, de snelheid van de verbinding, … beschouwd wordt. Vooraf ingestelde parameters bepalen dan wanneer de slechte
werking
gemeld
wordt.
De kwaliteitscontroles kunnen verbeterd worden door lokale gegevens bij te houden over vorige tests. Er wordt dan op inhoud getest. Een aantal voorbeelden hiervan zijn: specifieke bestanden ophalen en daarvan de inhoud vergelijken met een lokale kopie van dat bestand. Dit geldt zowel voor
64
HTTP
als
voor
FTP.
Samenwerking tussen POP3 en SMTP: een e-mail wordt verzonden via SMTP en dezelfde e-mail wordt dan opgehaald door een POP3 test. Ondertussen werden alle gegevens in verband met deze mail van het SMTP test object naar het POP3 test object gestuurd. De inhoud van de e-mail wordt dan vergeleken, evenals beschouwen we opnieuw de responstijd. •
Naast het Monitor DCOM component een aantal nieuwe DCOM componenten ontwikkelen. Een eerste van deze nieuwe componenten staat in voor de verbinding met een (relationele) databank. Alle gegevens van een alarm worden dan verzameld in deze databank. Naast de gegevens van de alarmen zouden eveneens de configuratiegegevens bijgehouden kunnen worden. Alleen is het dan niet meer mogelijk
om
handmatig
de
XML
bestanden
te
veranderen.
Een tweede component kan dan instaan voor de presentatie van de gegevens naar de gebruiker toe. Hierbij worden dan automatisch grafieken opgebouwd die dan de resultaten van tests presenteren verlopen gedurende een bepaald tijdsinterval. De data-evaluatie wordt gescheiden van de dataverzameling. De NSM component kunnen we dan als een probe beschouwen terwijl de hierboven besproken component de test component is. De probe controleert een host op zijn goede werking en de test analyseert de informatie uit de geschiedenis van de probe. Hierbij ziet de test de veranderingen in de toestand
van
een
host
en
rapporteert
deze
veranderingen
dan
aan
de
gebruiker.
Eén NSM kan dienst doen als centraal punt. Dit centraal punt wordt dan door de overige NSMonitors gebruikt om informatie over een alarm naartoe te zenden. De controles verzamelen dan gegevens en schrijven die in een databank. Bij het foutlopen van een test wordt er eveneens in de databank geschreven maar wordt de centrale monitor gewaarschuwd. Deze centrale monitor evalueert dan de gegevens van het alarm en waarschuwt uiteindelijk de gebruiker door middel van bijvoorbeeld een email, een SMS berichtje, of een ander communicatiemiddel. Er wordt wel rekening gehouden met het wegvallen van dit centraal punt, op het ogenblik dat dit gebeurt, moet dit door een andere NSM overgenomen
worden.
65
60%
80%
100%
Resultaten PING test voor host 1 - 27-04-2002
0%
20%
40%
Foutief Geslaagd
1
3
5
fig. 4.12
•
7
9
11
13
15
17
19
21
23
Tijd (h)
Statistische gegevens van een test gedurende 24uur
Alle gegevens over de testen zouden kunnen samengevat worden in een rapport en automatisch doorgezonden worden naar de verantwoordelijke netwerkbeheerder. Om het rapport dan door te zenden kan dan weer gebruik gemaakt worden van de NSM DCOM component.
•
Als de NSM ingezet wordt in een omgeving waar meerdere NS monitors actief zijn, kunnen zij de werklast verdelen. Alle monitors voeren dan ongeveer even veel werk uit. Het netwerkverkeer wordt dan ook meer verspreid waardoor het verloren gaan van pakketten kleiner zal zijn. Naast het verspreiden van de werklast controleren alle NSM de beschikbaarheid en de werking van de anderen. Indien dan één van deze monitors uitvalt, kunnen de overige monitors zijn werk overnemen, dit verhoogt de reliability . Dit kan wel enkel indien de gegevens voor de testen steeds beschikbaar zijn. Bijvoorbeeld dan door middel van de zonet besproken databank. Het grootste nadeel wordt dan het beheer van dit gedistribueerd systeem. Het gemakkelijkst wordt het natuurlijk wanneer de verschillende NSM’s als één enkel systeem beschouwd kunnen worden. Er wordt dan als het ware een laag boven geconstrueerd en de distributie van de testen gebeurd dan volledig automatisch.
•
Als alle gegevens uiteindelijk toch centraal verzameld worden kan men een stap verder gaan en een knowledge base opbouwen. Deze knowledge base bevat dan oplossingen op problemen binnen het netwerk. Indien er dan een probleem voorkomt dat een grote gelijkenis heeft met een reeds voorgekomen probleem, dan kan de knowledge base misschien een oplossing daarvoor bevatten. Er
66
kan dan samen met de informatie over het foutlopen van de controle bijvoorbeeld een link meegezonden worden naar een webpagina die de oplossing beschrijft. •
Naast het uitbreiden van de testen is het handig om over een scripttaal te beschikken waardoor we de uitvoering van de tests zelf kunnen bepalen. Als de netwerkbeheerder uitgebreide controles wil definiëren
voor
een
host,
dan
kan
dit
door
middel
van
deze
scripttaal.
Naast de volgorde van de tests te bepalen kunnen de scripts eveneens gebruikt worden om correctieve acties te definiëren. Bijvoorbeeld automatisch antwoord op bepaalde alarmen zoals een email zenden, iemand een SMS zenden, een SNMP trap genereren, een server rebooten, een correctief programma laten lopen, ... •
Alle tijdstippen waarop de tests gebeuren liggen nu nog vast. Meer bepaald, wanneer een bepaald tijdsinterval is verstreken wordt een test opnieuw uitgevoerd. Een aparte sheduling agent zou hier welkom zijn. Wanneer een netwerk en bepaalde servers zwaar belast zijn, dit gebeurt meestal op regelmatige tijdstippen, kan het wenselijk zijn om de testen niet uit te voeren of toch zeker minder regelmatig uit te voeren. Hier komt dan de sheduling agent kijken. De tijdstippen van de testen kunnen met dit geavanceerd stukje gereedschap beter beheerd worden.
67
fig. 4.13
Architectuur voor alle verbeteringen
68
5. Samenvatting Het vooropgestelde doel om een framework te construeren voor de netwerk service monitor werd bereikt. Hierbij werd al uitgebreid naar andere protocollen, meer bepaald naar het ICMP, HTTP, FTP, POP3 en SMTP protocol toe. Voor al deze protocollen werd een basisfunctionaliteit voorzien die gemakkelijk kan worden uitgebreid. De zwarte doos werkt correct en is gemakkelijk bruikbaar wat blijkt uit het gebruik van de test GUI. Naast de Windows service werd een test GUI geïmplementeerd om de degelijkheid van de applicatie te controleren. Deze applicatie is vooral bedoeld om in te zetten op grote netwerken. De netwerkverantwoordelijke kan aan de hand van deze applicatie snel netwerkproblemen aanduiden en oplossen. De gebruikers van het netwerk krijgen hierdoor de beschikking over een goed gecontroleerd en goed werkend netwerk. Het is een uitdaging om een applicatie te ontwikkelen die netwerkcontroles uitvoert omdat dit gebied zeer uitgestrekt is. Voor een dergelijke uitgebreide applicatie is het moeilijk om alle functionaliteit die men er in wil stoppen er tevens in te stoppen. Een enkele persoon en één jaar is te weinig en te kort om deze ideale en uitgebreide applicatie te construeren. Bepaalde zaken moesten op het achterplan geschoven worden, maar heel wat functionaliteit heeft toch zijn plaats gevonden. Met het oog op de toekomst werden een aantal verbeteringen bekeken die aanleiding kunnen geven tot een robuustere en uitgebreidere applicatie. Hierbij treedt een gedistribueerde omgeving zeer op de voorgrond, wat op zich al een hele opgave is gebleken bij de ontwikkeling van de netwerk service monitor. Deze uitbreidingen en verbeteringen kunnen de aanze t zijn om een opvolger voor deze eerste versie te ontwikkelen. We vermelden tevens dat er nog heel wat verbeteringen dienen te gebeuren om een ideale oplossing te kunnen leveren.
69
Appendix A De structuur van de XML bestanden. De naam van elk XML bestand staat telkenmale in het vet gedrukt met eronder de inhoud van het bestand.
PingObjects.xml <ServiceMonitor> 127.0.0.1 60000 <TimeOut>3000 <PacketSize>32 1 192.168.0.3
HttpObjects.xml <ServiceMonitor> 127.0.0.1 80 60000 3000 <Username> <Password> index.htm 1 <WriteToLocalFile>FALSE
70
FtpObjects.xml <ServiceMonitor> ftp.microsoft.com 21 10000 <Timeout>2000 <Username> <Password> <PassiveTransfer>FALSE 1 Pop3Objects.xml <ServiceMonitor> pop.pandora.be 110 60000 <Timeout>2000 <Username> <Password> 1 192.168.0.3
71
SmtpObjects.xml <ServiceMonitor> <SmtpObject> smtp.pandora.be 25 <Username> <Password> 90000 <Timeout>20000 1 192.168.0.3
72
Appendix B Inhoud van de cd-rom
Volgende mappen staan op de cd-rom bijgevoegd bij deze thesis: De thesis De thesis werd bijgevoegd in elektronisch formaat. De elektronische formaten zijn een PDF be stand en een DOC (word) bestand.
De applicatie Voor meer uitleg betreffende de applicatie gelieve het bestand LeesMijEerst.txt er op na te lezen. De applicatie werd ontwikkeld in Visual C++ 6. De service en de GUI werden als Visual C++ project bijgevoegd. Ze kunnen dus gemakkelijk bekeken worden door gebruik te maken van de Visual C++ applicatie.
73
Referenties Algemene bibliografie •
L. Thai Thuan, Learning DCOM, First Edition, O’Reilly & Associates, Sebastopol (1999).
•
William Rubin, Understanding DCOM, First Edition, Prentice Hall PTR, Upper Saddle River (1999).
•
Jeffrey Richter, Programming Applications for Microsoft Windows, Fourth edition, Microsoft Press, Redmond (1999).
•
Jeff Prosise, Programming Windows with MFC, Second edition, Microsoft Press, Redmond (1999).
•
Jon Bates, Practical Visual C++ 6, First edition, Que Corporation, Indianapolis, (1999).
•
James F. Kurose, Computer Networking, A Top-Down Approach Featuring The Internet, Fisrt Edition, Addison Wesley Longman, Boston, (2001).
Veel gebruikte internet sites http://msdn.microsoft.com http://www.codeproject.com http://www.codeguru.com http://www.xml.com
Referenties [1] http://www.ietf.org/rfc/rfc792.txt [2] http://www.ietf.org/rfc/rfc791.txt [3] http://www.ietf.org/rfc/rfc1945.txt [4] http://www.ie tf.org/rfc/rfc2616.txt [5] http://www.ietf.org/rfc/rfc2068.txt [6] http://www.ietf.org/rfc/rfc959.txt [7] http://www.ietf.org/rfc/rfc1081.txt [8] http://www.ietf.org/rfc/rfc821.txt
Figuren Figuur 4.2, figuur 4.3 en figuur 4.4 : L. Thai Thuan, Learning DCOM, First Edition, O’Reilly & Associates, Sebastopol (1999).
74
