Automatische device discovery in IP-netwerken

Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Automatische device discovery in IP-netwerken door De Clercq Wouter

Promotor: Prof. Dr. Ir. P. DEMEESTER Scriptiebegeleider: Ir. B. VERMEULEN, J. DELEU

Scriptie ingediend tot het behalen van de academische graad van Licentiaat Informatica

Academiejaar 2005–2006

Voorwoord Graag had ik Brecht Vermeulen en Johannes Deleu bedankt voor hun waardevolle ideeën en raadgevingen bij deze thesis. Dank aan mijn ouders voor het nalezen van dit werk en de steun doorheen mijn ganse opleiding. Tenslotte had ik ook graag mijn dank betuigd aan Prof. Demeester voor het ter beschikking stellen van het Atlantis-testlab, een boeiende en leerrijke omgeving.

De Clercq Wouter, mei 2006

Toelating tot bruikleen “De auteur geeft 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.”

De Clercq Wouter, mei 2006

Automatische device discovery in IP-netwerken door De Clercq Wouter Scriptie ingediend tot het behalen van de academische graad van Licentiaat Informatica Academiejaar 2005–2006 Promotor: Prof. Dr. Ir. P. DEMEESTER Scriptiebegeleider: Ir. B. VERMEULEN, J. DELEU Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Samenvatting In deze thesis wordt de ontwikkeling beschreven van een programma in C++ om een eigen beheerd netwerk te kunnen detecteren en beheren. Het programma zal de mogelijkheid bieden tot het detecteren van apparaten in een netwerk, het mappen van de topologie van een netwerk en zal toelaten de gedetecteerde apparaten te beheren en te analyseren. In de opeenvolgende hoofdstukken van deze thesis worden de verschillende modules van het programma besproken: analyse van individuele apparaten, mapping van de netwerktopologie en provisioning (beheer). In elk hoofdstuk wordt op het einde een concreet voorbeeld uitgewerkt ter illustratie.

Trefwoorden Topologie, detectie, analyse, provisioning, nmap, expect.

Extended Abstract

Automatic device discovery in IP networks De Clercq Wouter Supervisor(s): Piet Demeester Abstract— This article will summarize the content of the thesis ”‘Automatic device discovery in IP networks”’, made in order to obtain the degree of Master in Computer Sciences.

obviously to improve the readability and give the opportunity to include this textfile in a report.

Keywords— Device discovery, analysis, provisioning, topology detection, FTW PhD Symposium

B. Detecting the topology of a self-administered network

I. I NTRODUCTION

T

HE goal of this thesis was to develop a program written in C++ that has the possibility to analyse hosts in a network, to do some provisioning such as remotely configuring network interface cards of this hosts, installing kernels, and that also has the possibility to detect the topology of a self-administered network. The reason for writing this program was that there is no such software with these capabilities available. The current available commercial software often has the possibility to detect a network topology, however, this kind of software often can not detect a topology past a router. Another problem is that commercially available software that can analyse and control hosts often is very brand-specific, e.g. only available for Cisco equipment. In most cases, that software uses SNMP to analyse and control hosts. However, the developed program is intended to be used in the testlabs of the IBCN-group. In this situation, one can asume the user of the program has the necessary information, such as login and password, to be able to login on the hosts in the networks and extract much more information than is available with SNMP. The program also has to cope with fast changing environments in the testlabs of IBCN, as testnetworks are often build and then disassembled after a short time. II. S TRUCTURE OF THE PROGRAM In the program, as described earlier, three parts can be distinguished: A. Analysing hosts in a self-administered network Functionality for analysing hosts in the developed program is: • Remote execution of commands on a host in a network and storing the output locally on the controlmachine with the developed program. • Locally downloading of files from a remote host and creating an MD5-hash code for each downloaded file. • Controlling by means of this created MD5-hash if the files that were downloaded are changed on the remote host. • Analysing the locally stored output to create an XML-file containing relevant information on a host in the network. This file could contain information such as the IP-adresses of the interfaces, the content of the routing table, how much memory and which CPU the host has, ... • Using XSLT-stylesheets specifically designed for XML-files to view these XML-files in a browser as a text document. This

An important feature of the program is to discover the topology of a network. This however is not limited to just scanning on the IP layer for the IP’s of the hosts that are online in a network, as much of the software of this kind does. The intention is to discover a topology on layer 2 of the network protocol stack, the datalink/MAC-layer. The idea is to figure out e.g. which interfaces of a switch are connected to which interfaces on a connected host. However, an important problem in the testlab networks with IBCN is as follows: one can distinguish a control network and several other subnetworks, often defined by using VLAN’s. Sometimes ordinary hosts have an interface to a certain subnetwork and an interface to the control network. Usually manageable switches have an IP in the control network, which is ofcourse also an important security feature. The detection program will also run in the control network, so these switches are often immediately reachable for the detection program. However, sometimes there is no known route to the subnetworks defined by VLAN’s for the detection program. This will be solved by using a remote agent, uploading it from the control host that runs the detection program to a host with a control interface on one hand, so that it is reachable from the control agent, and an interface to the target subnetwork on the other hand. Then using the remote agent from a host that is reachable for the controlprogram on one hand and has a route to the target subnetwork on the other hand, an entire subnetwork can be analysed that otherwise could not be analysed. Several tools are used by the program to detect the topology. Some of these tools are: • nmap: to find the online hosts in a subnetwork, to find the OS of a host and the services it is running such as telnet, ssh, ... • snmpget: to read the information from the MIB’s of a host that supports SNMP. • expectscripts: to log in on a remote host and execute remote commands, such as to find the interface information. Once the online hosts are detected and the interface info is gathered, such as IP- and MAC-addresses, the program analyses the switches using the login and password that will be known, as we are working in a self-administered network. From each switch, the ARP table is analysed. This gives for each port of the switch the MAC-adress that is connected on that port. Then these MAC-addresses are matched against the list of hosts that were found by the program. This way, the MAC-layer connectivity is analysed. This information is again put into an XMLfile, which in turn combined with an XSLT-stylesheet gives a nicely readable representation of the connectivity of the network on the MAC-layer. On the other hand, a second XML file is

constructed that can be used with a GUI written in Java to give a visual representation of the network topology. C. Provisioning for hosts in a self-administered network Implemented functionality for this part is: Using the controlprogram on the controlhost to remotely change configurations of network interface cards on remote hosts in the network. • The posibility to backup entire directory-trees from a remote host by downloading them locally. • Installing a kernel on a Linux host in the network. This could be done by means of APT for debian, to install a standard kernel image on a host. On the other hand, there is also the possibility to upload a selfbuild kernel image to a remote host and install it. Because in the testlabs of IBCN there are a lot of simmilar machines with the same hardware, it could easily be possible to have one self build kernel image that one wants to upload and install on several hosts. This too is possible. • The option to download a single file from a host and also the option to upload a single file to a host. This could be usefull to change a configurationfile for a remote host. An example could be, after a kernel has been installed on a host, one would like to change the default kernel in which the host wil boot on restart. Therefore, the user of the program could download the configuration file for the bootloader such as GRUB, change it, upload it again, and then reboot the host. •

III. C ONCLUSIONS The program provided for analysing and provisioning of hosts plus the detection of the network topology is only a prototype. Several enchancements could be made to the program, such as: • The detection of the network topology could be made significantly faster by implementing this using multithreading. For now, the prototype only scans the hosts and subnetworks in a sequential order. • The provisioning could be made more efficient. E.g., taking backups of hosts makes use of SCP. However, this implementation for now copies entire directory trees one file at the time sequentially. This causes lots of extra network traffic. An improvement could be, to log in on the remote host, make a compressed archive containing the entire directory tree, such as a tarball or gzip-file. Then the entire directory tree could be downloaded in one single file, and with a reduced amount of data to be downloaded. • Using multithreading in the analysis part to analyse multiple hosts at the same time instead of sequentially as it does now. R EFERENCES [1] [2] [3] [4] [5]

http://expect.nist.gov/ http://www.debian.org/ http://www.insecure.org/nmap/ http://www.lookatlan.com/ James F. Kurose, Keith W. Ross, “Computernetwerken: een ’top-down’benadering”, Pearson Addison Wesley, 2003. [6] Bruce Eckel, Thinking in C++ 2nd Edition, Prentice Hall, 2000. [7] Glazemakers Kurt, Studie van algoritmen en technieken voor netwerktopologie detectie, thesis, Universiteit Gent, 1999-2000. [8] Volckaert Bruno, Automatische generatie van grafische gebruikersinterfaces voor netwerkbeheer, thesis, Universiteit Gent, 2000-2001.

INHOUDSOPGAVE

i

Inhoudsopgave 0.1

Gebruikte afkortingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 Voorbeschouwing

1 2

1.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

Doelstellingen van het ontwikkelde programma . . . . . . . . . . . . . . . . . . .

5

2 Device analyse

7

2.1

Probleemsituering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2

Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3

Belangrijke bestanden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.4

Voorziene functionaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.4.1

Remote uitvoeren van commando’s en lokaal opslaan van de output . . .

10

2.4.2

Genereren van een XML-document . . . . . . . . . . . . . . . . . . . . . .

12

2.4.3

Genereren van een tekst-rapport . . . . . . . . . . . . . . . . . . . . . . .

13

2.4.4

Lokaal downloaden van bestanden . . . . . . . . . . . . . . . . . . . . . .

16

2.4.5

Controle op wijzigingen van gedownloade bestanden . . . . . . . . . . . .

17

Uitgewerkt voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.5

3 Topologie detectie 3.1

26

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.1.1

Netwerk topologieën . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.1.2

SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

3.1.3

nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.2

Enkele voorbeschouwingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.3

Belangrijke bestanden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

3.4

Topologie detectiealgoritme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

INHOUDSOPGAVE

ii

3.5

Verdere uitwerking van de topologie: . . . . . . . . . . . . . . . . . . . . . . . . .

44

3.6

Uitgewerkt voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

4 Provisioning

53

4.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

4.2

Belangrijke bestanden voor het provisioning gedeelte . . . . . . . . . . . . . . . .

54

4.3

Instellen van IP-adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

4.3.1

Instellen van IP-adres op één enkele host

. . . . . . . . . . . . . . . . . .

57

4.3.2

Sequentieel instellen van IP-adressen op meerdere hosts . . . . . . . . . .

58

4.4

. . . . . . . . . . . . . . . . . .

59

4.4.1

Installeren van een kernel op één host . . . . . . . . . . . . . . . . . . . .

59

4.4.2

Installeren van een kernel op meerdere hosts sequentieel . . . . . . . . . .

60

Downloaden en uploaden van één enkel bestand van en naar een machine . . . .

61

4.5.1

Lokaal downloaden van één enkel bestand van een remote machine . . . .

61

4.5.2

Uploaden van een bestand naar een remote machine . . . . . . . . . . . .

62

4.6

Nemen van backups van een volledige bestandsboom op een host . . . . . . . . .

63

4.7

Uitgewerkte voorbeelden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

4.7.1

Wijzigen van de interface-configuratie voor één host . . . . . . . . . . . .

65

4.7.2

Voorbeeld downloaden één enkel bestand van een remote machine . . . .

67

4.7.3

Voorbeeld uploaden één enkel bestand naar een remote machine . . . . .

68

4.7.4

Installeren kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

4.7.5

Backups nemen van bepaalde directory trees voor een host . . . . . . . .

70

4.5

Installeren van een kernel op een Linux-machine

5 Uitbreidingen

72

5.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

5.2

Uitbreidingen analyse van machines . . . . . . . . . . . . . . . . . . . . . . . . .

72

5.3

Uitbreidingen topologiedetectie . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

5.4

Uitbreidingen provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

5.5

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

6 Besluit

74

6.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

6.2

Analyse van hosts in het netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

6.3

Detectie van de netwerktopologie van een eigen beheerd netwerk . . . . . . . . .

75

INHOUDSOPGAVE

iii

6.4

Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

6.5

Uitbreidbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

6.6

Bijlages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

A UML diagrammen

77

B XSLT-Stylesheets

89

B.1 XSLT stylesheet voor host analyse . . . . . . . . . . . . . . . . . . . . . . . . . .

89

B.2 XSLT stylesheet voor topologie representatie . . . . . . . . . . . . . . . . . . . .

96

C Screenshots C.1 Analyse uitgewerkte voorbeelden . . . . . . . . . . . . . . . . . . . . . . . . . . .

97 97

C.1.1 Gedeeltelijke XML inhoud v/h rapport aangemaakt voor host met IP 192.168.0.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

97

C.1.2 Corresponderende weergave in een browser met behulp van XSLT stylesheet 99 C.2 Topologie detectie uitgewerkte voorbeelden . . . . . . . . . . . . . . . . . . . . .

99

C.2.1 Inhoud van analysis.list voor het beschouwde testnetwerk . . . . . . . . .

99

C.2.2 Gedeeltelijke inhoud van TopologyDescription.xml voor het beschouwde testnetwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

99

C.2.3 Weergave van TopologyDescription.xml met een XSLT stylesheet in een browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 C.2.4 Inhoud van output-gui-topology.xml voor de GUI . . . . . . . . . . . . . . 101 C.2.5 Weergave van output-gui-topology.xml in de GUI zelf . . . . . . . . . . . 102

0.1 Gebruikte afkortingen

0.1

Gebruikte afkortingen

• SCP: Secure Copy Protocol. • SSH: Secure SHell. • XML: EXtensible Markup Language. • XSL: EXtensible Stylesheet Language. • XSLT: XSL Transformations. • SNMP: Simple Network Management Protocol. • IP: Internet Protocol. • TCP: Transmission Control Protocol. • UDP: User Datagram Protocol. • MAC: Medium Access Control. • CIDR: Classless Inter-Domain Routing. • ARP: Address Resolution Protocol. • VLAN: Virtual Local Area Network. • ISP: Internet Service Provider. • LEX: Local EXchange. • TEX: Transit EXchange. • PSTN: Public Switched Telephony Network. • MB: Mother Board. • DNS: Domain Name Server. • GUI: Graphical User Interface.

1

VOORBESCHOUWING

2

Hoofdstuk 1

Voorbeschouwing 1.1

Inleiding

Een eerste vraag die men zich zou kunnen stellen bij dit onderwerp is : wat houdt netwerkbeheer en detectie van apparatuur in een netwerk concreet in? Netwerkbeheer zal voor verschillende mensen verschillende dingen inhouden in verschillende omstandigheden. Zo betekent netwerkbeheer in sommige gevallen één enkele netwerkconsultant die de netwerkactiviteit in de gaten houdt met een verouderde protocol analyzer. In andere gevallen, is netwerkbeheer geassocieerd met gedistribueerde databases, gebeurt er autopolling van netwerkapparaten en worden er high-end eindsystemen gebruikt om real-time grafische views te genereren van wijzigingen in netwerktopologie en -verkeer. Algemeen kan men zeggen dat netwerkbeheer een variatie aan tools, applicaties en apparaten gebruikt om menselijke netwerkbeheerders bij te staan in het monitoren en onderhouden van bestaande netwerken. Voor hedendaagse netwerken wordt dit een steeds grootschaliger en complexer aangelegenheid, iets wat zeker niet zal verbeteren naar de toekomst toe. Een voorbeeld hiervan vinden we onder andere in het netwerk aan de IBCN vakgroep, waar er gebruik wordt gemaakt van testopstellingen die enorm heterogeen zijn. Deze heterogeniteit wordt veroorzaakt door een grote diversiteit aan hardware- en software-componenten. Veel van de systemen in het atlantis-netwerk zijn Linux-machines, maar ook een selectie van windows-machines is hier terug te vinden. Daarnaast zien we natuurlijk ook verschillende types van machines, zoals routers, switches, eindsystemen, tot zelfs PDA’s. Ook het sterk dynamische karakter van de testopstellingen draagt bij tot de complexiteit. Sommige testopstellingen zullen continu aangepast of uitgebreid worden en sommige testopstellingen kennen slechts een kort bestaan. Zeker in deze situaties is het handig als

1.1 Inleiding

3

men tools heeft die toelaten de netwerken snel te detecteren en te beheren. Als men de hedendaagse commerciële toepassingen bekijkt die verkrijgbaar zijn op de markt, stellen we vast dat deze toch al vrij uitgebreide mogelijkheden hebben. Hierbij onderscheiden we eenvoudige en gratis tools zoals bijvoorbeeld: • Look@LAN: een eenvoudige tool die toelaat om snel de online hosts in een bepaald IP bereik te kennen en die bepaalde eigenschappen van de gedetecteerde devices toont, zoals of ze SNMP ondersteunen of niet, en die eenvoudige grafieken kan tonen over het gedetecteerde netwerk, zoals het percentage van windows- en linuxsystemen.

Figuur 1.1: Voorbeeld van de functionaliteit van look@LAN

Anderzijds zijn er natuurlijk ook de high-end commerciële en dus niet-gratise tools, zoals er zijn: • HP OpenView • SolarWinds Engineering Edition Veel van deze tools zijn echter vooral ontworpen om gebruikt te worden in algemene netwerken en in mindere mate in zelfbeheerde netwerken. Bij deze laatste categorie kan men verwachten

1.1 Inleiding

4

Figuur 1.2: Voorbeeld van de statistische functionaliteit van look@lan

dat de beheerder over de login-gegevens van de machines beschikt en die ook kan gebruiken. In deze gevallen kan men uiteraard veel meer informatie verzamelen over het beheerde netwerk en de specifieke apparatuur in dit netwerk. Net dit was de doelstelling van deze scriptie: een in eigen huis ontwikkelde tool voorzien, die de mogelijkheid biedt om eigen netwerken te mappen en beheren, gebruik makend van eventueel gekende login-gegevens over de apparatuur in dit netwerk. Bij de ontwikkeling van deze tool is er vertrokken van drie vooropgestelde fasen: • Het ontwikkelen van de nodige functionaliteit voor het analyseren van enkelvoudige apparaten. • Het detecteren van de netwerktopologie. • Provisioning en beheer van de gedetecteerde apparaten en dit door het remote wijzigen van configuratieparameters voor deze apparaten. Elke fase zal in de volgende drie hoofdstukken apart worden behandeld. Per hoofdstuk zal een overzicht gegeven worden van de functionaliteit per onderdeel, welke ontwerpbeslissingen er werden genomen en hoe elk deel nu concreet moet gebruikt worden. Dit laatste zal aangetoond

1.2 Doelstellingen van het ontwikkelde programma

5

worden door telkens op het einde van elk hoofdstuk een concreet maar eenvoudig voorbeeld uit te werken die de eerder beschreven functionaliteit zal demonstreren. Deze drie hoofdstukken zullen dan gevolgd worden door een besluitend hoofdstuk dat nog even kort de ge¨ımplementeerde functionaliteit zal samenvatten. Hierin zullen ook de belangrijkste voor- en nadelen nog even kort worden aangehaald van het ge¨ımplementeerde programma.

1.2

Doelstellingen van het ontwikkelde programma

Een aantal relevante aspecten van het ontwikkelde programma zijn: • Qua programmeertaal werden aanvankelijk Java en C++ overwogen. De keuze viel uiteindelijk op C++. Dit vooral omwille van performantie en snelheid die C++ meer kan garanderen dan Java. • Verder was een vereiste dat het mogelijk was om automatisch in te loggen op remote hosts, ´ en aspect dat er commando’s uit te voeren en de output lokaal op te vangen in bestanden. E´ hierbij van belang is, is dat er meestal wel zal gevraagd worden naar een login en paswoord, of het nu gaat om het remote uitvoeren van commando’s of het downloaden van files lokaal. Dit ingeven van login en paswoord moet automatisch kunnen gebeuren, vandaar dat er gekozen is voor expect. Deze scriptingtaal in Linux laat toe dat interactieve sessies zoals voor ftp, ssh, scp, ... volledig kunnen geautomatiseerd worden. • Eenvoud: om het programma zo eenvoudig mogelijk te houden, is er voor gezorgd dat er gebruik wordt gemaakt van standaardtools onder Linux en Windows. De bedoeling is dat er op de remote hosts zelf zo veel mogelijk standaard commando’s worden uitgevoerd, zoals ipconfig en ifconfig voor informatie over interfaces, systeminfo onder Windows, terwijl op het centrale beheerstation er zoveel software kan ge¨ınstalleerd worden als nodig is. Dit laat toe om in het beheerde netwerk zelf zo weinig mogelijk aanpassingen te doen, zoals het installeren van extra software, om het programma toch te kunnen gebruiken. • Portabiliteit/platformonafhankelijkheid: het programma is in zekere mate platformonafhankelijk. Dit houdt in dat het programma zoveel mogelijk geprogrammeerd is gebruik makend van standaard features van C++. Er werden geen systeemafhankelijke bibliotheken gebruikt. Door het programma te recompileren op een Windows machine, en in combinatie met Cygwin plus een aantal Windows-varianten van de door het programma

1.2 Doelstellingen van het ontwikkelde programma

6

gebruikte software (zoals nmap en snmpget) kan het programma even gemakkelijk op een Windows machine gebruikt worden. • Uitbreidbaarheid: wanneer commando’s op een remote host worden uitvoerd, wordt de gegenereerde output lokaal opgeslagen in een bestand. De gebruiker van het programma kan zelf modules specifiëren voor het verwerken van deze outputfiles, en deze dan als het ware inpluggen in het hoofdprogramma. Deze modules kunnen geschreven worden in C/C++, Java, Perl, ... en geeft de gebruiker alle mogelijkheid tot uitbreidbaarheid in de taal die hij zelf verkiest. ´ en van de • Er is zoveel mogelijk naar gestreefd om gebruik te maken van standaarden. E´ einddoelen van het analyse-gedeelte van het programma is dat uit de verzamelde gegevens een tekstueel rapport zou kunnen gehaald worden, dat dan eventueel kan ingevoegd worden bij documenten. Hiervoor is er gekozen voor standaarden zoals XML en XSLT, die de verzamelde gegevens zullen voorstellen onder XML-formaat. Dit laatste zal dan op zijn beurt grafisch overzichtelijker worden voorgesteld in combinatie met de XSLT-stylesheets onder vorm van HTML in een browser. Dit geeft de mogelijkheid tot het voorstellen van de informatie over een host in tabelvorm, waar figuren kunnen worden ingevoegd, enzovoort...

DEVICE ANALYSE

7

Hoofdstuk 2

Device analyse 2.1

Probleemsituering

Een eerste module van het programma die werd uitgewerkt, is die module verantwoordelijk voor het analyseren van individuele systemen. Deze zal in dit hoofdstuk verder uiteengezet worden. Een eerste belangrijke aspect bij het beheren van een eigen netwerk, is dat men natuurlijk de mogelijkheid wil hebben tot het kunnen analyseren van de systemen in dit netwerk. Zeker in de context van het testlabo in de groep breedbandnetwerken, waar er sprake is van een continu variërende infrastructuur, kan het handig zijn om snel duidelijke en gedetailleerde informatie te krijgen van bepaalde hosts in een netwerk. In dit testlabo worden er regelmatig nieuwe testopstellingen opgebouwd, waarvan sommige een grotere levensduur hebben dan andere. Dan kan het zeker handig zijn om snel en eenvoudig de systemen in deze testopstelling te analyseren. Relevante informatie die men wil bekomen met betrekking tot bepaalde apparaten kan zijn: gegevens over de CPU op elke machine, de hoeveelheid geheugen, de inhoud van de routing tabel, configuraties van netwerkkaarten...

2.2

Doelstellingen

´ en van de vooropgestelde doelen van het programma was, dat gegevens over de hosts in het E´ beheerde netwerk centraal op één enkele machine zouden kunnen verzameld worden. In feite zal het programma dus vrij veel principes gemeenschappelijk hebben met het SNMP-protocol waarbij één machine informatie over alle hosts in het netwerk verzamelt. Een belangrijk verschil is hier wel dat we beschikken over login-gegevens voor de verschillende hosts in het netwerk, wat ons toelaat om in te loggen op deze machines en er veel gedetailleerder informatie uit te

2.3 Belangrijke bestanden

8

extraheren dan mogelijk is via SNMP. De bedoeling van het analyse gedeelte is, dat de inhoud van bepaalde files en de output van remote uitgevoerde commando’s lokaal kan getoond worden op het beheerstation. Door het remote uitvoeren van commando’s en het downloaden van de nodige bestanden, moet het mogelijk zijn om een volledig overzicht te geven van de eigenschappen van bepaalde hosts, zoals bijvoorbeeld wat de huidige CPU-load is, wat de netwerkadressen zijn, welke kernelversie er draait op bepaalde systemen...

2.3

Belangrijke bestanden

De bestanden en klassen die voor het analyse-gedeelte van het programma van belang zijn, zijn: • Configuratiebestanden: – /datafiles/iplist: bevat alle hosts die moeten geanalyseerd worden door het programma. Dit bestand kan manueel ingevuld worden door de gebruiker of zal automatisch opgebouwd worden door het topologie detectiegedeelte. Elke lijn uit dit bestand is van de vorm: :::<password> – /datafiles/filesToDownloadLinux: bevat alle bestanden die moeten gedownload worden van een Linux host. – /datafiles/filesToDownloadWindows: bevat alle bestanden die moeten gedownload worden van een Windows host. – /datafiles/commandsLINUX: bevat alle commando’s die moeten remote uitgevoerd worden op een Linux host. – /datafiles/commandsWINDOWS: bevat alle commando’s die moeten remote uitgevoerd worden op een Windows host. – /datafiles/reportCommandsLINUX: geeft aan voor welke commando’s de output moet verwerkt worden en worden opgenomen in het XML- of tekst-rapport voor Linux hosts. Ook wordt hier gespecifieerd door welke externe modules deze commando’s worden verwerkt, modules te schrijven door de gebruiker zelf. – /datafiles/reportCommandsWINDOWS: geeft aan voor welke commando’s de output moet verwerkt worden en moeten opgenomen worden in het XML- of tekstrapport voor Windows hosts. Ook wordt hier gespecifieerd door welke externe modules deze commando’s worden verwerkt.


9

– /datafiles/login: bevat koppels van (login-paswoord), te gebruiken door het programma als de gebruiker zelf geen login en paswoord verschaft. Elke lijn is van de vorm: <paswoord>. Met de inhoud van dit bestand zal het programma analoog tewerk gaan aan software voor het kraken van paswoorden: een lijst van logins en paswoorden zal worden geprobeerd totdat het inloggen op de machine is geslaagd. • expect-scripts – /expectscripts/executeRemoteStoreLocallyLinux.exp: een expectscript dat toelaat om via ssh-inloggen remote commando’s uit te voeren op een Linux host en lokaal de output op te slaan. – /expectscripts/executeRemoteStoreLocallyWindows.exp: een expectscript dat toelaat om remote commando’s uit te voeren op een Windows host, gebruik makend van ssh, en de output lokaal op te slaan. De reden dat er twee verschillende scripts gebruikt worden voor Linux en Windows hosts, is dat er bij de Windows hosts een grotere timeout-waarde kan gebruikt worden voor het lokaal opslaan van de output, omdat bij sommige commando’s van Windows, zoals systeminfo, het systeem enige tijd nodig heeft om de noodzakelijke gegevens over de host te verzamelen. – /expectscripts/secureCopyFiles: een expectscript dat toelaat om van een remote host lokaal bestanden te downloaden, gebruik makend van scp. • programmabestanden(Voor UML-diagrammen verwijzen we naar bijlage A) – IplistObject.h en IplistObject.cpp: elk object van deze klasse zal een lijn uit het configuratiebestand ./datafiles/iplist bevatten, en zal per object het IP-adres, het besturingssysteem, de login en paswoord van een te analyseren host bijhouden. – SystemAnalysis.h en SystemAnalysis.cpp: deze klasse zal de noodzakelijke functionaliteit voor de analyse van remote machines in het netwerk implementeren. – ToolBox.h en ToolBox.cpp: gemeenschappelijke functionaliteit gedeeld door meerdere methodes uit SystemAnalysis zal hierin worden bijgehouden, alsook de noodzakelijke functies voor het inlezen en verwerken van de configuratiebestanden bij het opstarten van het programma. – automtopol.cpp: het hoofdprogramma, dat een menu zal aanbieden aan de gebruiker met de aangeboden functies.

2.4 Voorziene functionaliteit

2.4

10

Voorziene functionaliteit

Belangrijke functionaliteit die het programma biedt ter analyse van systemen aangetroffen in een netwerk zijn: • Remote uitvoeren van commando’s op een host en lokaal opslaan van de output. • Op basis van de lokaal opgevangen output een XML-document genereren dat meer informatie bevat over de host en zijn configuraties. • Het genereren van een tekst-rapport met informatie over de host en zijn configuraties, gebruik makend van XSLT en verder bouwend op het gegenereerde XML-document. • Het lokaal downloaden van bestanden van een remote host. • De mogelijkheid om te controleren of de gedownloade bestanden gewijzigd zijn op die host sinds de laatste keer dat ze zijn gedownload. Elk van deze functionaliteiten zal nu verder worden verduidelijkt.

2.4.1

Remote uitvoeren van commando’s en lokaal opslaan van de output

Een belangrijk aspect van het programma komt hier opnieuw naar voor: dit programma wordt gebruikt in een eigen beheerd netwerk, dus hebben we de mogelijkheid om op hosts in te loggen en commando’s uit te voeren op deze hosts. Net deze remote uitvoeringen vragen regelmatig interactie met de gebruiker, iets dat in dit programma zoveel mogelijk moet geautomatiseerd worden. Ook moet er zoveel mogelijk kunnen gereageerd worden vanuit het programma op output van de uitgevoerde commando’s of bijvoorbeeld op time-out’s. Voor deze redenen is er gekozen om in het programma gebruik te maken van expect-scripting, dat elk van eerder vermelde punten aankan. Expect is een tool dat het automatiseren van bepaalde applicaties mogelijk maakt zoals ssh, ftp, telnet, ... dus applicaties die vooral interactie met de gebruiker vragen. Het laat zelfs toe om, gebruik makend van Tk, interactieve programma’s te maken met een X11-GUI errond. Hier gaan we ons echter beperken tot de commandline variant.

Voor het remote uitvoeren van commando’s op een host zijn er twee opties voorzien: één voor het remote uitvoeren op één enkele host en één optie voor het remote uitvoeren op meerdere hosts uit een bestand sequentieel na mekaar.


11

Remote uitvoeren van commando’s op ´ e´ en enkele host Bij de optie voor het analyseren van één enkele host, is er enige interactiviteit voorzien met de gebruiker, waarbij er gevraagd wordt naar het IP van de te analyseren host en het besturingssysteem. Merk op dat er aan de gebruiker geen paswoord of login wordt gevraagd. Bij de analyse van een machine in het netwerk worden alle combinaties (login-paswoord) gebruikt uit het configuratiebestand ./datafiles/login, dus is het noodzakelijk dat de correcte login-gegevens zich in dit bestand bevinden. Dit kan gemakkelijk bekomen worden door op elke machine die moet geanalyseerd worden een account aan te maken met root-privileges en dat gebruik maakt van hetzelfde login en paswoord. Volgende stappen worden dan doorlopen voor het analyseren van één enkele machine: 1. Maak een subdirectory aan in de directory waarin het hoofdprogramma zich bevindt van de vorm .//output/. 2. Indien dan de login en het paswoord voor deze host niet gekend zijn in het configuratiebestand /datafiles/iplist, probeer dan elk van de mogelijke (login-paswoord)-koppels uit /datafiles/login. 3. Voer elk van de commando’s gespecifieerd in /datafiles/commandsLinux (voor een Linuxmachine) of in /datafiles/commandsWindows (voor een Windows-machine) uit op de remote host respectievelijk aan de hand van /expectscripts/executeRemoteStoreLocallyLinux.exp of aan de hand van /expectscripts/executeRemoteStoreLocallyWindows.exp. 4. Voor elk van de remote uitgevoerde commando’s, zal de output lokaal opgeslaan worden in de subdirectory //output/, dit telkens onder de vorm van bestanden met naam .output. Remote uitvoeren van commando’s op meerdere hosts sequentieel Het analyseren van meerdere hosts sequentieel zal op analoge wijze gebeuren als het analyseren van één enkele host. Uiteraard zal nu de interactiviteit met de gebruiker vermeden worden. Voor elke host gespecifieerd in ./datafiles/iplist zullen de stappen doorlopen worden zoals vermeld in de subsectie Remote uitvoeren van commando’s op één enkele host. Opnieuw kan de nodige login en paswoord gespecifieerd worden voor elke host in ./datafiles/iplist zelf. Indien deze niet gespecifieerd zijn, wordt elke mogelijkheid uit ./datafiles/login geprobeerd.


2.4.2

12

Genereren van een XML-document

Voor het genereren van een XML-document is er bijkomende functionaliteit nodig die de eerder bekomen .output-bestanden voor elke host zal analyseren en er een bepaalde XML-output zal uit genereren. Bij de implementatie van deze functionaliteit is gestreefd naar optimale uitbreidbaarheid. Dit wordt bereikt door de functionaliteit die de .output-bestanden analyseert niet hard te koppelen aan het hoofdprogramma zelf, maar door er externe modules of subprogramma’s van te maken die vanuit het programma zelf kunnen opgeroepen worden. Dit linken” van deze subprogramma’s aan het hoofdprogramma zal gebeuren aan de hand van ” het standaard pipelining-mechanisme onder Linux. Dit zal maximale uitbreidbaarheid mogelijk maken: op deze manier kan het programma verspreid worden als een binary, terwijl de externe programma’s voor het opbouwen van de XML-output naar believen kunnen geschreven en ingeplugd worden door de gebruiker. Dit laat toe om deze externe modules te schrijven in eender welke taal, zoals Java, C/C++, Perl, ... De enige vereiste is dat deze taal de mogelijkheid heeft om te schrijven naar standaard output en te lezen van standaard input, zodat het pipelining mechanisme kan gebruikt worden. Een aantal van deze standaardmodules zijn reeds meegeleverd met het programma, zoals modules voor het analyseren van de output van de commando’s ipconfig en ifconfig. Het analyseren van de output van deze commando’s komt er op neer dat het .output-bestand wordt ingelezen en dat er gezocht wordt in de output naar specifieke kernwoorden, zodat IP-adressen, MAC-adressen, ... kunnen gedetecteerd worden. Nadeel hieraan is dan uiteraard dat, indien de output van ifconfig of ipconfig gewijzigd wordt, deze module zal moeten herschreven worden. Voordeel is dan echter, dat hiervoor het programma zelf niet moet herschreven worden maar alleen deze externe module, zodat deze kan ingeplugd worden in het programma in plaats van de oudere versie.

In de configuratiebestanden ./datafiles/reportCommandsLINUX en ./datafiles/reportCommandsWINDOWS wordt opgegeven voor welk van de remote uitgevoerde commando’s de output moet verwerkt worden om opgenomen te worden in het XML-bestand. Dit respectievelijk voor een Linux-machine of een Windows-machine. Elke lijn in beide configuratiebestanden is van de vorm :<module>:<module> waarbij het aantal gespecifieerde modules in principe onbeperkt is. Dit geeft aan dat de output van het opgegeven commando zal verwerkt worden door de opgegeven module, die dan zijn output doorgeeft aan nog een module, die die output nog verder verwerkt, enzovoort... De output van de laatste module wordt dan


13

opgenomen in het uiteindelijke XML-bestand. Het programma onderneemt dan volgende acties: • Het programma begint met een subfolder .//report/ aan te maken. • Voor elk van die commando’s uit reportCommandsLINUX of reportCommandsWINDOWS wordt gekeken of ze reeds uitgevoerd zijn. Dit wordt gecontroleerd door te kijken of het correspondere .output-bestand reeds aanwezig is in de subfolder .//output/. • Indien het commando reeds uitgevoerd werd, wordt het corresponderende .output-bestand gekopieerd van .//output/ naar .//report/. Indien het commando nog niet is uitgevoerd, wordt het commando nu uitgevoerd en het bijhorende .outputbestand opgeslagen in de folder .//report/. • Voor elk commando wordt dan de output verwerkt door een sequentie van modules zoals opgenomen in de configuratiebestanden ./datafiles/reportCommandsLINUX en ./datafiles/reportCommandsWINDOWS. Die output wordt uiteindelijk gestuurd naar hetzelfde XML-bestand dat alle gegevens over de geanalyseerde host zal bevatten.

2.4.3

Genereren van een tekst-rapport

Tot nu toe is reeds de mogelijkheid besproken om een rapport voor een bepaalde host te construeren onder XML-formaat. Hoewel dit wel aanleiding geeft tot een eenvoudig gestructureerd document, is dit nog niet wat we verlangen om tussen te voegen in officiële documenten. Het XML-bestand zal wel te openen zijn in een browser, wat al een grafisch duidelijker beeld zal geven van de inhoud. Maar uiteindelijk willen we nog een stap verder gaan en overstappen van een puur XML-document naar een tekstueel document. Dit kan in het programma gerealiseerd worden aan de hand van een zogenaamde XSLT-stylesheet.

XSLT is een familie van aanbevelingen voor het definiëren van XML document transformaties en presentaties. De XSLT-specificatie bestaat uit drie delen:


14

• XSLT (XSL Transformations): een taal voor het transformeren van XML. • XPath (XML Path Language): een expressie-taal gebruikt door XSLT om toegang te krijgen tot of te refereren naar delen van een XML document. • XSL-FO (XSL Formatting Objects): een XML vocabularium voor het specifiëren van een formatteringssemantiek. Een XSLT stylesheet specifieert de presentatie van een klasse van XML documenten door het beschrijven van hoe een instantie van de klasse getransformeerd wordt in een XML document dat een formatterings-vocabularium gebruikt, zoals (X)HTML of XSL-FO. Een voorbeeld van een soortgelijke stylesheet dat gebruikt wordt door het programma is als volgt (merk op dat dit slechts een selectie is uit de volledige XSLT stylesheet. Voor de volledige stylesheet verwijzen we naar bijlage B van deze thesis):

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/">
Report

<xsl:if test="Report/OS_Version"> * The version of this OS is <xsl:value-of select="Report/OS_Version"/>.
<xsl:if test="Report/OS_Name"> * The OS-Name is <xsl:value-of select="Report/OS_Name"/>.
<xsl:if test="Report/Host_Name"> * The host name is <xsl:value-of select="Report/Host_Name"/>.
<xsl:if test="Report/OS_Build_Type"> * The build type of the OS is <xsl:value-of select="Report/OS_Build_Type"/>.


15

<xsl:if test="Report/Registered_Owner"> * The registered owner is <xsl:value-of select="Report/Registered_Owner"/>.
<xsl:if test="Report/Registered_Organization"> * The registered organisation is <xsl:value-of select="Report/Registered_Organization"/>.

...

<xsl:if test="Report/Routing_Table/Interface_List/Interface">
Interfaces
<xsl:for-each select="Report/Routing_Table/Interface_List/Interface">

ID Mac-address Name
<xsl:value-of select="ID"/> <xsl:value-of select="Mac_address"/> <xsl:value-of select="Name"/>

´ en van de voornaamste redenen om te kiezen voor de XSLT-technologie is zijn dynamische E´


16

karakter. Zo is het mogelijk om bepaalde stijlregels te specifiëren voor sommige tags. Deze tags zullen dan in een browser getoond worden als HTML-output. Als er in de onderliggende XMLfile die gebruik maakt van de XSLT-stylesheet tags voorkomen waarvoor geen stijlregels zijn opgenomen in de bijhorende stylesheet, zullen deze tags genegeerd worden in de HTML-output. De gegenereerde XML-file voor een Windows-machine zal verschillen van de gegenereerde XMLfile voor een Linux-machine, beide zullen immers verschillende tags gebruiken. Toch zal het mogelijk zijn om zowel de stijlregels voor Windows-specifieke tags als Linux-specifieke tags te plaatsen in één enkele stylesheet. Alleen de gepaste stijlregels zullen toegepast worden op de gepaste tags, de overige tags en stijlregels zullen eenvoudigweg genegeerd worden bij het tonen van de HTML-output.

In het programma is ook de mogelijkheid ontworpen om specifiek op te geven voor welke hosts een tekstueel rapport moet gegenereerd worden. Dit kan opgegeven worden in het configuratiebestand ./datafiles/ipTextReports. In dit bestand kunnen de IP-adressen worden opgegeven van de hosts waarvoor een tekstueel rapport moet gegenereerd worden. Wanneer een IP voorkomt in dit bestand, zal bij het genereren van het XML-bestand (zie voorgaande sectie Genereren van een XML-document), nog een extra lijn bovenaan het bestand worden ingevoegd, namelijk: Dit zorgt er voor dat de stylesheet wordt toegepast op het XML-bestand indien dit wordt geopend in een browser. Uiteraard moet in dit geval de stylesheet zich in dezelfde folder bevinden als het XML-bestand zelf, namelijk de folder .//report/. De stylesheet zelf bevindt zich in de folder ./stylesheets. Het bestand zal gedurende het aanmaken van het XMLbestand gekopieerd worden vanuit deze laatste folder naar .//report/.

2.4.4

Lokaal downloaden van bestanden

Het lokaal downloaden maakt gebruik van scp. De bestanden die moeten worden gedownload, worden gespecifieerd in de configuratiebestanden /datafiles/filesToDownloadLINUX en /datafiles/filesToDownloadWINDOWS. Opnieuw worden de gedownloade bestanden geplaatst in een specifieke subfolder met naam .//downloaded_files/. Tegelijkertijd wordt er ook een subfolder .//downloaded_files/MD5 aangemaakt. Hierin wordt een bestand MD5.hash” geplaatst waarin voor elk gedownload bestand een lijn wordt opgenomen. Op ” elke lijn staat een MD5 hash van het gedownloade bestand, plus een timestamp”, het tijdstip ”


17

waarop het bestand is gedownload. Een voorbeeld van de inhoud van MD5.hash” bij het downloaden van enkele bestanden van een ” Linux host zijn:

Fri Apr

7 10:33:11 2006 61ac235d4b5a07839ed0f3af03d4f15e *debian_version

Fri Apr

7 10:33:12 2006 58992474ca37a8d2625bbfa9a9ddad16 *sources.list

Fri Apr

7 10:33:13 2006 3217b9f332de72c137eaf703e714aacc *inetd.conf

Fri Apr

7 10:33:13 2006 9b759ea821f637590d60f979da82234c *passwd

Dit geeft aan dat debian_version, sources.list, inetd.conf en passwd gedownload zijn vanaf de remote host, op 7 april rond 10.33u.

2.4.5

Controle op wijzigingen van gedownloade bestanden

Wanneer we willen controleren of bepaalde bestanden gewijzigd zijn sinds de vorige keer dat ze gedownload zijn, is een ideaal hulpmiddel de zogenaamde MD5-hash functie. Het MD5 algoritme zal vertrekkend van een bepaalde input, in dit geval een bestand dat we gedownload hebben van een host, een 128 bit fingerprint” opbouwen. Deze hash zal absoluut uniek zijn voor het ” gedownloade bestand, aangezien bij het MD5 hash algoritme geen twee verschillende inputs tot dezelfde MD5 hash kunnen leiden. Bij het controleren of voor een bepaalde host de gedownloade bestanden zijn gewijzigd sinds de vorige keer ze zijn gedownload, is er opnieuw een optie voorzien om dit voor één host te controleren of voor een lijst van hosts. Controleren op wijzigingen voor ´ e´ en enkele host Het controleren voor één enkele host gebeurt opnieuw mits enige interactiviteit met de gebruiker: de gebruiker wordt gevraagd naar het IP en OS van de host. Vervolgens wordt elke combinatie van (login-paswoord) geprobeerd uit het bestand /datafiles/login. Op de remote machine wordt dan van het gewenste bestand een MD5 hash code berekend. Dit zal gebeuren voor alle bestanden die gespecifieerd zijn in ./datafiles/filesToDownloadLINUX voor een Linux-machine en ./datafiles/filesToDownloadWINDOWS voor een Windows-machine. Deze remote berekende MD5 hash codes worden lokaal opgeslagen in een bestand MD5.changes, dat ook geplaatst wordt in de folder .//downloaded_files/MD5. Een voorbeeld van een soortgelijk bestand zal zijn:

2.5 Uitgewerkt voorbeeld

18

Fri Apr

7 10:39:11 2006 debian_version:NOT CHANGED since Fri Apr 7 10:33:11 2006

Fri Apr

7 10:39:11 2006 sources.list:NOT CHANGED since Fri Apr 7 10:33:12 2006

Fri Apr

7 10:39:12 2006 inetd.conf:NOT CHANGED since Fri Apr 7 10:33:13 2006

Fri Apr

7 10:39:12 2006 passwd:CHANGED since Fri Apr 7 10:33:13 2006

Zo wordt per bestand dat moet gecontroleerd worden aangegeven wanneer de controle is gebeurd, om welk bestand het gaat, of het gewijzigd is of niet, en het tijdstip sinds wanneer het de laatste keer gedownload is. Controleren op wijzigingen van meerdere hosts sequentieel Het controleren voor meerdere hosts gebeurt op analoge manier als het controleren van één enkele host, echter zonder enige interactiviteit met de gebruiker. Een analoge manier van werken aan de manier beschreven in Controleren op wijzigingen voor één enkele host wordt gehanteerd voor elke host waarvan de bestanden moeten gecontroleerd worden. Dit zal uitgevoerd worden voor elke host opgegeven in ./datafiles/iplist. Indien voor bepaalde hosts in dit bestand geen login en paswoord gespecifieerd zijn, zal opnieuw elk koppel van login en paswoord uit ./datafiles/login geprobeerd worden.

2.5

Uitgewerkt voorbeeld

Figuur 2.1: Eenvoudig voorbeeld van een testnetwerk voor analyse


19

Laten we nu even een voorbeeld beschouwen om de eerder besproken functionaliteit van het analyse-gedeelte te verduidelijken (Voor eventuele screenshots verwijzen we naar bijlage C). Dit doen we aan de hand van volgende hypothetische situatie, vertrekkend van een eenvoudig netwerk: we draaien het programma op één host, met bijvoorbeeld IP 192.168.0.44. Deze host is verbonden met een switch, samen met twee andere hosts die we willen analyseren. Deze twee hosts hebben IP-adres 192.168.0.5, voorzien van Linux-Debian en IP-adres 192.168.0.2, voorzien van Microsoft Windows XP SP2. Uitvoeren van remote commando’s en lokaal opslaan van output Laten we veronderstellen dat we op beide hosts alle analyse-functies willen toepassen. Eerst en vooral moeten we zorgen dat in /datafiles/iplist staat (we gaan er vanuit dat login en paswoord gekend zijn voor beide hosts): 192.168.0.5:linux:root:test 192.168.0.2:windows:root:root Zouden login en paswoord toch niet gekend zijn, moet een lijst van mogelijke logins en paswoorden geplaatst worden in /datafiles/login, als volgt: intec intec test test root test root root wouter test Deze kunnen dan geprobeerd worden telkens wanneer er moet ingelogd worden op één van beide hosts. Voor de Linux host worden dan de remote uit te voeren commando’s opgenomen in /datafiles/commandsLINUX, bijvoorbeeld als volgt: netstat -an ps aux uname -a xprobe2 vmstat iostat mpstat


20

lpstat route -n iptables -L ifconfig Analoog voor de Windows host in /datafiles/commandsWINDOWS : systeminfo /FO CSV ipconfig /all route print netstat -a Vervolgens kiezen we de optie van het programma om op meerdere hosts commando’s uit te voeren en de output lokaal op te slaan. Het programma zal er voor zorgen dat twee subfolders worden aangemaakt, met als naam de beide IP-adressen, /192.168.0.5/ en /192.168.0.2/. In elk van beide folders zal een subfolder worden aangemaakt met naam output. Dus krijgen we een subfolderstructuur van de vorm /192.168.0.5/output/ en /192.168.0.2/output/. Telkens nadat een bepaald commando is uitgevoerd uit bovenstaande lijst, zal men in de output-folder een bestand terugvinden van de vorm .output. Voor de Linux host vinden we zo onder andere terug: netstat.output ps.output iostat.output ... Bij de Windows host vinden we analoog onder andere: systeminfo.output route.output Wat hier zeker moet opgemerkt worden, is dat het soms mogelijk is dat een bepaald commando niet kon worden uitgevoerd. Dit kan zijn doordat er bepaalde software nog niet ge¨ınstalleerd is op deze host. Dit geeft dan .output-bestanden terug met als inhoud: bash: line 1: iostat: command not found


21

Analyseren van .output-bestanden en verwerken tot XML-formaat Uiteraard, zoals al eerder uitgelegd, zal het verwerken van deze output-bestanden gebeuren aan de hand van zelfgeschreven modules, die kunnen ingeplugd” worden in het hoofdprogramma. ” Deze kunnen geschreven worden in eender welke programmeertaal of scriptingtaal en het is dan ook de taak van deze modules om te reageren tijdens de verwerking van dit soort input. De verantwoordelijkheid hiervoor is dus opzettelijk niet bij het hoofdprogramma gelegd. Voorbeelden van commando’s die wel correct uitgevoerd zijn: Chain INPUT (policy ACCEPT) target

prot opt source

destination

Chain FORWARD (policy ACCEPT) target

prot opt source

destination

Chain OUTPUT (policy ACCEPT) target

prot opt source

destination

Bovenstaande is een voorbeeld van de output teruggevonden in iptables.output, door het uitvoeren van het commando iptables -L. Een voorbeeld van een output bestand voor een Windows systeem, terug te vinden in ipconfig.output na het remote uitvoeren van ipconfig /all is dan: Windows IP Configuration Host Name . . . . . . . . . . . . : test Primary Dns Suffix

. . . . . . . :

Node Type . . . . . . . . . . . . : Unknown IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : atlantis.ugent.be

Ethernet adapter VMware Network Adapter VMnet8: Connection-specific DNS Suffix

. :

Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet8


22

Physical Address. . . . . . . . . : 00-50-56-C0-00-08 Dhcp Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 192.168.232.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : Eens de output van de commando’s lokaal is opgeslagen, kan er begonnen worden met het verwerken van deze bestanden tot XML-formaat. Hiervoor nemen we dan volgende regels op in het configuratiebestand /datafiles/reportCommandsWINDOWS voor de Windows machine: systeminfo /FO CSV:processSysteminfo ipconfig /all:processIpconfig route print:processRoutingTableWindows netstat -a:processNetstatWindows Dit houdt in dat de output van het commando systeminfo /FO CSV, terug te vinden in de folder ./192.168.0.2/output/systeminfo.output, zal verwerkt worden door de module processSysteminfo. Dit zal een klein hulpprogramma zijn, dat zich in dezelfde map moet bevinden als het hoofdprogramma zelf, en kan dus geschreven zijn in eender welke programmeer- of scriptingtaal. Dit hulpprogramma zal de input uitlezen uit systeminfo.output, deze verwerken naar XML formaat, en uitschrijven naar een bestand REPORT-192.168.0.2.xml. Dit bestand zal geplaatst worden in een submap ./192.168.0.2/report/. Verder zullen ook alle noodzakelijke .outputbestanden, zoals hier systeminfo.output, mee gekopieerd worden naar deze map. Analoog zullen ook alle overige commando’s verwerkt worden voor de Windows host. Voor de Linux-machine vinden we dan in /datafiles/reportCommandsLINUX : ifconfig:processIfconfig uname -a:processUname ps aux:processPS route -n:processRoute netstat -an:processNetstat Hier zal opnieuw een analoge procedure gevolgd worden als bij de Windows-machine: de output van het commando ifconfig, terug te vinden in ./192.168.0.5/output/ifconfig.output zal ingelezen worden door het hulpprogramma processIfconfig, omgezet worden naar XML formaat en dan uitgeschreven worden naar het bestand REPORT-192.168.0.5.xml. Dit bestand zal opnieuw


23

in de submap ./192.168.0.5/report/ komen, en het bestand ifconfig.output zal ook opnieuw gekopieerd worden naar deze locatie. Analoog zullen alle overige .output-bestanden verwerkt worden door het gespecifieerde hulpprogramma.

Merk echter op dat deze lijst van rapport-commando’s niet noodzakelijk gelijk hoeft te zijn aan de volledige lijst van commando’s die remote is uitgevoerd op een machine. Dit kan evenwel slechts een subset van deze lijst zijn, zodat het mogelijk is om uit de uitgevoerde commando’s een selectie te maken voor opname in het rapport.

Genereren van een tekstueel rapport Vervolgens zal gekeken worden naar het configuratiebestand ./datafiles/ipTextReports. Hierin zullen alle hosts gespecifieerd worden aan de hand van hun IP-adres waarvoor een rapport onder tekstvorm moet aangemaakt worden. Stel dat de huidige inhoud van dit bestand is: 192.168.0.5 192.168.0.2 Dit houdt in dat voor beide beschouwde hosts een tekstrapport zal worden opgebouwd. Het enige wat hiervoor nodig is, is in het XML-bestand waarin het uiteindelijk rapport komt onder XML-formaat, volgende lijn toe te voegen: Verder zal uit de map ./xml-stylesheets het bestand stylesheet.xsl gekopieerd worden naar de map .//report/, in dit geval dus naar ./192.168.0.5/report/ en naar ./192.168.0.2/report/. Dit zal tot gevolg hebben dat in het XML-rapport een referentie naar de toe te passen stylesheet zal worden opgenomen. Downloaden van bestanden Vervolgens willen we een aantal bestanden downloaden van de hosts. Voor de Linux host specifiëren we dit in het configuratiebestand ./datafiles/filesToDownloadLinux, voor de Windows host in ./datafiles/filesToDownloadWindows. Stel dat we nu enkel bestanden willen downloaden van de Linux host. De inhoud van ./datafiles/filesToDownloadLinux zou kunnen zijn: /etc/debian_version


24

/etc/apt/sources.list /etc/inetd.conf /etc/passwd Het programma zal een subfolder ./192.168.0.5/downloaded_files/ aanmaken waar de gedownloade files zullen geplaatst worden. In deze folder zullen we volgende bestanden terugvinden: debian_version sources.list inetd.conf passwd Verder zal er ook een subfolder aangemaakt worden: ./192.168.0.5/downloaded_files/MD5. Hierin zal een bestand geplaatst worden, MD5.hash. Hierin kunnen de MD5 hash codes voor de gedownloade bestanden teruggevonden worden. De inhoud van dit bestand zal zijn: Fri Apr

7 10:33:11 2006 61ac235d4b5a07839ed0f3af03d4f15e *debian_version

Fri Apr

7 10:33:12 2006 58992474ca37a8d2625bbfa9a9ddad16 *sources.list

Fri Apr

7 10:33:13 2006 3217b9f332de72c137eaf703e714aacc *inetd.conf

Fri Apr

7 10:33:13 2006 9b759ea821f637590d60f979da82234c *passwd

Controleren of bestanden zijn gewijzigd Beschouwen we dan de optie van het programma dat controleert of de gedownloade bestanden gewijzigd zijn. In dit geval, zullen we alleen maar de gedownloade bestanden willen controleren voor de host met IP-adres 192.168.0.5. We zorgen er dan eerst voor dat het configuratiebestand ./datafiles/iplist dit weerspiegelt, en wijzigen de inhoud ervan naar: 192.168.0.5:linux:root:test Vervolgens kiezen we de optie in het programma om te controleren of de gedownloade bestanden op de remote host zijn gewijzigd. Dit houdt concreet in dat er zal gezocht worden naar wijzigingen in de bestanden debian_version, sources.list, inetd.conf en passwd. Er wordt ingelogd op de machine met IP 192.168.0.5, voor de vier bestanden worden remote de MD5 hash codes berekend en worden ze vervolgens vergeleken met de hash codes uit het bestand MD5.hash. De resultaten van deze vergelijkingen worden opgeslagen in het bestand MD5.changes in de folder ./192.168.0.5/downloaded_files/MD5/. In dit geval stellen we vast dat er één bestand gewijzigd is sinds het downloaden, en dat de overige drie ongewijzigd zijn gebleven. De inhoud van MD5.changes wordt:


25

Fri Apr

7 10:39:11 2006 debian_version:NOT CHANGED since Fri Apr 7 10:33:11 2006

Fri Apr

7 10:39:11 2006 sources.list:NOT CHANGED since Fri Apr 7 10:33:12 2006

Fri Apr

7 10:39:12 2006 inetd.conf:NOT CHANGED since Fri Apr 7 10:33:13 2006

Fri Apr

7 10:39:12 2006 passwd:CHANGED since Fri Apr 7 10:33:13 2006

TOPOLOGIE DETECTIE

26

Hoofdstuk 3

Topologie detectie 3.1 3.1.1

Inleiding Netwerk topologie¨ en

Wanneer we het hebben over de topologie van een netwerk, dan verstaan we hieronder in feite de indeling van computers binnen een netwerk, en de koppelingen tussen die computers. Topologie verwijst naar de vorm en layout van het netwerk. Bij de topologie kan men ook onderscheid maken tussen de logische en fysische topologie. Dit kan zowel gaan over computernetwerken als over algemene multimedia- en communicatienetwerken, zoals telefonie-netwerken.

Verschillende types van netwerktopologieën zijn te onderscheiden in algemene netwerken: een vermaasd netwerk (mesh topology), een sternetwerk (star topology), bustopologie (bus topology), een ringnetwerk (ring topology) en een boomstructuur (tree topology). Bij grootschalige netwerken, zoals het netwerk van een ISP zoals Belgacom of Telenet, kunnen eventueel meerdere topologieën door mekaar worden gebruikt. Een typisch voorbeeld is te vinden in een PSTN netwerk, waar de verschillende telefoontoestellen verbonden zijn met hun LEX in een stertopologie, terwijl de LEX en TEX kunnen verbonden zijn in een mesh topologie.

Mogelijke topologieën zijn:

3.1 Inleiding

27

• Mesh topologie: een netwerk met een mesh topology is een netwerk waarbij verschillende redundante connecties voorzien zijn tussen de nodes in het netwerk. In een pure mesh topologie is elke node in het netwerk verbonden met elke andere node in het netwerk.

Figuur 3.1: Mesh topologie

• Ster topologie: nodes zijn niet met elkaar verbonden, maar wel met een centrale ”hub”. De enige mogelijke manier om ze met mekaar te laten communiceren, is dat ze hun data met mekaar uitwisselen via de centrale ”hub”.

Figuur 3.2: Ster topologie

• Bus topologie: alle nodes in het netwerk zijn nu verbonden met een centrale kabel, de bus” of backbone” genoemd. ” ”

Figuur 3.3: Bus topologie

3.1 Inleiding

28

• Ring topologie: de verschillende nodes in het netwerk zijn nu met mekaar verbonden onder vorm van een gesloten lus, zodat elke node verbonden is met twee andere nodes, namelijk zijn linkerbuur” en rechterbuur”. ” ”

Figuur 3.4: Ring topologie

• Boom topologie: dit gaat vooral om een hybride topologie. Bijvoorbeeld, meerdere ster topologieën die verbonden zijn met een lineaire bus backbone.

Figuur 3.5: Boom topologie

3.1.2

SNMP

Een belangrijk hulpmiddel bij het detecteren van de topologie, is het gebruik van SNMP. SNMP staat voor Simple Network Management Protocol en is een protocol specifiek op de applicatie-laag die toelaat dat in een netwerk management informatie wordt uitgewisseld tussen netwerkapparatuur. In het kader van SNMP zijn vooral het management station en de management agents van belang. Enkele van de belangrijkste entiteiten in SNMP zijn: • In het ontwikkelde programma zal de host waarop het programma draait dienst doen als het management station wanneer er gebruik gemaakt wordt van SNMP om gegevens omtrent de topologie en de aard van de hosts in te winnen. In de context van SNMP zal het management station de centrale beheersentiteit zijn die, mits enige menselijke interventie,

3.1 Inleiding

29

informatie zal verzamelen over de management agents en deze informatie zal analyseren en/of weergeven. Op basis hiervan kan een netwerkbeheerder dan acties ondernemen om bepaalde wijzigingen aan te brengen in het netwerk, en eventueel configuraties aan te passen. • Op de machines in het netwerk, die SNMP ondersteunen, zullen zich dan management agents bevinden. Deze machines zullen bij het algoritme voor de topologiedetectie voornamelijk de hubs en switches in het netwerk zijn. Aan de hand van SNMP kan dan gemakkelijk gecontroleerd worden of we te maken hebben met een gewone host, of een hub/switch. (Men beschouwt deze hubs/switches soms ook als zogenaamde ”beheerde apparaten”, apparaten inclusief de software binnen het netwerk). Naast deze twee belangrijkste entiteiten in het SNMP protocol, onderscheiden we bij een meer gedetailleerde studie van het protocol ook nog: • Beheerde objecten: deze zijn terug te vinden in de beheerde apparaten in het netwerk. Die beheerde objecten zijn de eigenlijke stukken hardware binnen het beheerde apparaat inclusief de configuratieparameters voor de hardware- en softwarecomponenten. Deze beheerde objecten zijn dan gekoppeld aan net die informatie waar een netwerkbeheerder en het management station interesse voor hebben. In deze context onderscheiden we dan ook: • De Management Information Base: deze legt de koppelingen vast tussen de beheerde objecten en de informatie plus de informatie zelf. In deze MIB liggen dus als het ware de beheerde objecten opgeslagen. De waarden van die beheerde objecten in de MIB kunnen opgevraagd worden vanuit de beheersentiteit aan de hand van welgedefinieerde SNMP berichten. Wanneer we echter een scan uitvoeren van het IP-bereik vanaf 10.10.3.0 tot 10.10.3.255 in het testlab, gebruikmakend van de tool Look@LAN, bekomen we volgende resultaten (zie figuur 3.6):

Hierbij is vooral de voorlaatste kolom van belang, die aangeeft door middel van ”ON” welke hosts in dit gescande bereik SNMP ondersteunen. Op het moment van scannen, stellen we vast dat op 31 online hosts, er slechts 3 SNMP draaien. Bijgevolg zal er een andere manier moeten gevonden worden om te controleren of een bepaalde host een switch of hub is, die kan gebruikt worden als backup wanneer SNMP niet kan aangewend worden. Wanneer we kijken

3.1 Inleiding

30

Figuur 3.6: Look@LAN - scan van een range binnen het testnetwerk.

naar sommige van de hedendaags verkrijgbare commerciële pakketten voor netwerkanalyse en -beheer, dan stellen we vast dat die meestal niet beschikken over de beoogde functionaliteit van dit eindwerk. Een aantal voorbeelden van deze commerciële producten zijn HP Openview, Solarwinds Network Management Tools - Engineer’s Edition. Deze laatste bijvoorbeeld heeft geen mogelijkheid om grafisch een topologieoverzicht weer te geven, maar kan hoogstens per subnet of IP-range detecteren welke hosts er op het ogenblik van scannen online zijn. Ook het gratis te verkrijgen Look@LAN heeft de mogelijkheid om per IP-range of subnet te scannen welke hosts er online zijn, maar kan geen grafisch overzicht geven van de topologie. HP Openview blijkt deze mogelijkheid wel te hebben, mits bijkomende plugins die deze functionaliteit kunnen verschaffen, zoals te zien is op onderstaande figuur (zie figuur 3.7).

Net dit soort functionaliteit moet verschaft worden door de software ontwikkeld voor dit eindwerk. Maar het programma ontwikkeld voor dit eindwerk zal nog een stap verder gaan en

3.1 Inleiding

31

Figuur 3.7: Voorbeeld van visualisatie bij HP OpenView

niet alleen een topologie proberen te detecteren op de IP-laag, maar ook op de datalink laag. Zo zal het mogelijk zijn om te kunnen bepalen welke NIC op de ene host verbonden is met welke NIC op een andere host, doordat we opnieuw beschikken over login-gegevens voor elke machine in het netwerk. Dit laat toe om in te loggen en dan bijvoorbeeld het gevonden IP-adres te koppelen aan een bepaalde fysieke interface, zodat kan teruggegeven worden op welke interface (van eventueel meerdere interfaces) de beide hosts met mekaar zijn verbonden. Wanneer we echter de werking van tools zoals Look@LAN en HP Openview van nabij bekijken, stellen we vast dat veel van deze tools gebruik maken van SNMP om informatie te verzamelen over de gedetecteerde hosts in het netwerk. Wanneer hosts dan ook niet over SNMP beschikken, is de informatie over die hosts eerder schaars. Verder zullen deze software tools ook niet beschikken over de mogelijkheid om in te loggen op machines in het netwerk en dus uiteraard veel beperkter zijn in hun mogelijkheden om informatie over machines te verzamelen.

´ en van de redenen hiervoor is dat HP Openview en Look@LAN dan ook ontwikkeld zijn E´ om te kunnen gebruiken in eender welk netwerk, ook netwerken die men niet zelf beheert. Voor dit eindwerk konden we er echter vanuit gaan dat de software zou gebruikt worden in eigen beheerde netwerken. Bijgevolg kunnen we beschikken over de nodige informatie om te kunnen inloggen op remote machines, wat de mogelijkheden van de software enorm uitbreidt. Zodra we kunnen inloggen op remote machines, kunnen we onder meer informatie verzamelen over welke

3.2 Enkele voorbeschouwingen

32

interfaces er aanwezig zijn op die host en welke IP-adressen die interfaces bezitten, iets wat niet mogelijk is indien op die host SNMP niet geactiveerd is.

3.1.3

nmap

In plaats van zelf een tool te schrijven die een volledig subnet kan scannen naar online hosts, is er bij het implementeren van het programma voor gekozen om gebruik te maken van de functionaliteit van het programma nmap. Nmap is een gratis opensource tool, dat toelaat op efficiënte wijze aan network exploratie en security auditing te doen. Verdere voordelen van nmap zijn, naast het feit dat het hier gaat om opensource software: • Nmap kan op meerdere besturingssystemen gebruikt worden, zoals Linux en Windows. • Nmap is zeer schaalbaar en flexibel: het is mogelijk om grotere netwerken van meerdere honderden hosts te scannen in korte tijd. • Het kan zowel met GUI gebruikt worden als via commandline. Vooral dit laatste is uiteraard van belang in het kader van dit eindwerk. • Nmap is zeer goed gedocumenteerd. • Support is meervoudig aanwezig. • Nmap combineert meerdere functies in één pakket: 1. Port scanning, dit zowel met TCP als UDP. 2. Uitlezen van MAC-adressen behorende bij bepaalde IP-adressen. 3. Detectie van het besturingssysteem. 4. Ping sweeping voor het vinden van online hosts in een netwerk.

3.2

Enkele voorbeschouwingen

• Bij de aanvang van dit eindwerk, was het oorspronkelijk de bedoeling om te vertrekken van de code en studie gemaakt door Kurt Glazemakers in zijn eindwerk Studie van algoritmen ” en technieken voor netwerktopologie detectie”. Maar na een grondiger studie van dit eindwerk, bleek dat de algoritmes die hierin aan bod kwamen voor mijn eindwerk niet van toepassing zijn. Zo bleek immers dat bij die algoritmen meer de nadruk lag op snelheid


33

dan op correctheid. Bij mijn eindwerk is het belangrijker om de nadruk te leggen op de correctheid, eerder dan op de snelheid. Met andere woorden, een langere uitvoeringstijd is aanvaardbaar, als dit een garantie kan geven tot correctheid en detectie van alle machines in een netwerk. • Eerder in dit hoofdstuk werd als hulpmiddel het opensource programma nmap” aange” haald. Het besluit om nmap te gebruiken volgde uit een praktisch experiment bij de implementatie van het programma behorend bij dit eindwerk. Aanvankelijk werd er gepoogd om een volledig subnetwerk manueel” te scannen. Dit houdt in dat er zou ingelogd wor” den op een host uit een subnetwerk. Vervolgens kan uit de informatie over de interfaces, bijvoorbeeld te leren uit de output van het commando ifconfig op een Linux machine, het subnetmask voor een interface van deze machine naar het subnetwerk toe worden bekomen. Uit het IP-adres en subnetmask van een interface, kan het subnetadres worden bepaald, en kunnen dus ook alle IP-adressen in dit subnet worden bepaald. Als we dan nog maar zouden te maken krijgen met een subnetwerk met als subnetmask 255.255.255.0, /24 in CIDR notatie, zouden we een subnet moeten beschouwen van 254 mogelijke hosts. Veronderstel dan dat we elk van deze 254 IP-adressen manueel zouden pingen, met 2 ping pakketjes per host. Van elk van die 254 ping-operaties gaan we de output opslaan en analyseren. Als dit ongeveer 1 seconde zou innemen per host, zouden we voor een /24 subnetwerk al 254 seconden nodig hebben om alleen nog maar te zien welke hosts online zijn. Als er dan bijvoorbeeld maar 2 hosts zouden online zijn in dit netwerk, zal dit een enorme performantieverlies opleveren. Daarentegen, als we proefondervindelijk nmap loslaten op ditzelfde subnetwerk, met slechts 2 hosts online, kan deze dit aantonen in ongeveer 17 seconden, wat een enorme winst is op de manuele methode.

´ en van de problemen die kan opduiken bij het topologiedetectiealgoritme is het volgende: • E´ beschouw een eenvoudige testopstelling zoals ge¨ıllustreerd in figuur 3.8. De reden waarom in dit programma nmap wordt gebruikt, is zoals eerder vermeld, omdat nmap het scannen van een volledig subnetwerk toelaat in vrij korte tijd. Natuurlijk moeten er hierbij wel een aantal moeilijkheden in beschouwing worden genomen. Zo kan het soms zijn, dat bepaalde hosts niet rechtstreeks bereikbaar zijn vanop de machine waarop het hoofdprogramma loopt. Bekijken we even figuur 3.8: de twee Linux-machines hebben twee interfaces. Op beide machines zullen de interfaces met IP-adres 10.10.3.X rechtstreeks bereikbaar zijn


34

Figuur 3.8: Problematiek bij detectie van de topologie

vanop de controlemachine. Het doel van deze interfaces is net dat deze hosts bereikbaar zijn vanuit het controlenetwerk. Stel dan, dat de switch met IP-adres 10.10.3.172 zodanig geconfigureerd is, dat de beide interfaces van de Linux-machines met IP-adressen 10.0.1.X zich in een apart VLAN bevinden. Dit zou tot gevolg hebben, dat met nmap vanop de controlemachine niet rechtstreeks het subnetwerk 10.0.1.0/24 kan gescand worden. De controlemachine zal immers over geen route beschikken naar dit subnetwerk. Normaal zou men met nmap het subnetwerk proberen scannen met het commando nmap 10.0.1.0/24. Dit zal dus om eerder vernoemde reden niet lukken, nmap zal onterecht melden dat er geen hosts online zijn. Een andere mogelijkheid is te werken met het commando nmap -P0 10.0.1.0/24. Dit kan gebruikt worden indien bepaalde probes van nmap zouden geblokkeerd worden door firewals. In dit geval echter meldt nmap onterecht dat alle mogelijke IP-adressen online zijn in dit subnetwerk en verder vraagt het gebruik van deze optie veel meer tijd. Voor een /24-subnetwerk, kan dit gemakkelijk meer dan vijf minuten in beslag nemen, wat een onaanvaardbare uitvoeringstijd is. De enige mogelijkheid om efficiënt gebruik te maken van nmap voor het scannen van dit type subnetwerk, is om nmap te gebruiken vanop één van de machines die zich in het VLAN zelf bevindt. Deze zullen dan uiteraard wel een interface moeten hebben naar het controlenetwerk toe, en zullen ook moeten voorzien zijn van nmap. Bijgevolg, een belangrijke eis die door het programma zal


35

opgelegd worden is, dat er in elk subnetwerk in de te ontdekken topologie minstens ´ e´ en host moet zijn die toegankelijk is vanuit het controlenetwerk, en die ook voorzien is van een volledige installatie van nmap. • Zoals vermeld in voorgaand punt, moet zeker in elk te detecteren subnetwerk een host aanwezig zijn met een interface naar het controlenetwerk en een interface naar het te detecteren subnetwerk toe. Deze host zal moeten voorzien zijn van een installatie van nmap om het subnetwerk te kunnen scannen waarnaar de controlemachine zelf geen rechtstreekse route heeft. Naast nmap zal deze machine in kwestie echter ook moeten voorzien zijn van snmpget, om te kunnen controleren of bepaalde machines in een netwerk die voorzien zijn van SNMP een switch zijn of een gewone host. Ook hiervoor zal de controlemachine een rechtstreekse route nodig hebben naar de betrokken host, terwijl dit ook niet altijd het geval is als deze host zich bijvoorbeeld in een VLAN bevindt. • Wanneer we de testnetwerken beschouwen in het testlab, stellen we vast dat het de gewoonte is om switches op te nemen in het controlenetwerk, dus met een IP van de vorm 10.10.X.Y. Meestal zullen switches dus niet in een subnetwerk opgenomen worden met een IP-adres dat ook in het bereik van dit subnetwerk ligt. Dit laatste is ook niet nodig aangezien switches voornamelijk actief zijn op laag 1 (fysieke laag) en laag 2 (datalink laag). Vandaar dat een verdere veronderstelling die door het programma gemaakt wordt, is dat een lijst zal opgegeven worden van alle switches in de te detecteren topologie. Bekijken we immers opnieuw de eerder beschouwde testopstelling waarbij twee hosts een interface hebben die zich in een VLAN bevindt. Stel dat we bij aanvang van het algoritme alleen maar zouden beschikken over de controleinterfaces van één van deze hosts of van beide hosts. Als we dan nmap gebruiken vanop één van beide hosts om het subnet afgebakend door het VLAN (10.0.1.0/24) te scannen, zal de switch nooit worden gevonden. Dit zou tot gevolg hebben dat er nooit een link kan gevonden worden op laag 2 tussen beide Linux-machines. • Een verdere bedenking die we moeten maken bij de topologiedetectie is de volgende: aangezien we over de login-gegevens zullen beschikken van de switches in het netwerk, zullen we uiteraard inloggen op deze machines en de ARP-tabellen uitlezen. Hierbij moeten we echter opletten dat entries in de ARP tabellen van een switch maar een beperkte TTL hebben, waarna ze zullen verwijderd worden uit de switchingtabel. Bijgevolg zullen we er


36

voor moeten zorgen dat deze ARP tabellen up to date zijn op het moment van analyse. Dit kan eventueel bekomen worden door elke host in elk subnetwerk eerst te gaan pingen voor we de ARP-tabellen van de switches gaan inlezen. Conclusie: Een aantal vereisten om de topologiedetectie te laten werken zijn: • Een lijst van alle betrokken switches moet opgegeven zijn bij aanvang van het programma. • Er zullen zich geen switches in een subnetwerk bevinden met een IP eigen aan dit subnetwerk. Alle switches zullen dus bij aanvang worden opgegeven en zullen een IP-adres in het controlenetwerk hebben. (type 10.10.X.Y). • Alle hosts zullen zeker moeten gepingd worden in de gedetecteerde subnetwerken om ervoor te zorgen dat de ARP-tabellen van deze switches recent genoeg zijn. • Er moet zeker in elk te detecteren subnetwerk een host zijn met enerzijds een interface naar dit subnetwerk en anderzijds met een controleinterface naar het controlenetwerk toe, van het type 10.10.X.Y, zodat deze host bereikbaar is vanaf de controlemachine. Verder zal deze host moeten voorzien zijn van nmap en snmpget.

3.3

Belangrijke bestanden

De bestanden die van belang zijn voor het topologiedetectiegedeelte zijn: • Configuratiebestanden – ./datafiles/initialHosts: dit bestand bevat de initiële hosts om de topologie detectie te starten. Elke lijn van dit bestand ziet er uit als volgt: :<subnetmask_IP>::<paswoord>. Dit zullen meestal interfaces zijn van hosts gelegen in het controlenetwerk van het testlab. – ./datafiles/ignoreSubnets: dit configuratiebestand bevat voor een aantal subnetwerken het subnet adres en het subnetmask. Dit zal gebruikt worden om bepaalde interfaces te elimineren voor verdere analyse, voornamelijk interfaces in het controlenetwerk, dat normaal niet zal moeten gescand worden door het programma. Per te negeren subnet bevat dit bestand een lijn van de vorm <subnet_adres>:<subnetmask>. • Expect scripts


37

– ./expectscripts/executeRemoteStoreLocallyLinux.exp: een expectscript dat toelaat om via ssh-inloggen remote commando’s uit te voeren op een Linux host en lokaal de output op te slaan. Dit kan onder andere gebruikt worden om de Remote Agent bepaalde commando’s te laten uitvoeren(zie verder). – ./expectscripts/nmapsubnetScan.exp: een script dat gebruikt wordt om specifiek nmap uit te voeren op een host. – ./expectscripts/secureCopyFiles: een expectscript dat toelaat om van een host lokaal bestanden te downloaden, gebruik makend van scp. – ./expectscripts/uploadFiles: laat toe dat vanop de host waarop het programma zelf draait via scp bestanden kunnen geupload worden naar een remote host. • Programmabestanden (Voor de UML-diagrammen verwijzen we naar bijlage A) – TopolyMappingEngine.h/TopologyMappingEngine.cpp: deze klasse bevat de belangrijkste functionaliteit voor het detecteren van de netwerk topologie. – TopologyMappingToolBox.h/TopologyMappingToolBox.cpp: een algemene klasse met gemeenschappelijke functionaliteit die gebruikt wordt door de methodes uit TopologyMappingEngine. Bevat onder andere methoden voor het scannen van subnets naar online hosts met nmap, methodes om te bepalen welke services een host aanbiedt zoals telnet, ssh, snmp, ... – Subnet.h/Subnet.cpp: deze klasse laat toe een volledig subnetwerk te representeren, inclusief een lijst met alle Host-objecten die zich in dit subnetwerk bevinden. Verder wordt ook het subnetwerkadres en het subnetmask bijgehouden. – Host.h/Host.cpp: een Host-object representeert zowel gewone hosts als switches in het netwerk. Voor elke host wordt bijgehouden of deze telnet, ssh en snmp aanbiedt, of de host reeds geanalyseerd werd of niet, of het gaat om een gewone host of een switch. Verder wordt ook een lijst met Interface-objecten bijgehouden die de interfaces van de host representeren. – DlinkAnalyseToolBox.h/DlinkAnalyseToolBox.cpp: een klasse met specifieke functionaliteit voor het analyseren en detecteren van een D-Link switch, model DES3526. Door het schrijven van extra toolboxes analoog aan deze klasse, kan het programma uitgebreid worden om ook andere types switches te detecteren.

3.4 Topologie detectiealgoritme

38

– HostConnection.h/HostConnection.cpp: een klasse waarvan de objecten de koppelingen bijhouden op laag 2 (datalink laag). Elk object houdt twee hosts bij, namelijk twee hosts die met mekaar verbonden zijn op laag 2. Verder houdt het object ook nog bij op welke interfaces deze hosts exact verbonden zijn. – Interface.h/Interface.cpp: deze klasse representeert een interface van een host. Voor elke interface wordt de naam bijgehouden van de interface, het IP-adres en het MAC-adres plus het subnetmask. – PreliminarySubnetObject.h/PreliminarySubnetObject.cpp: wanneer het programma met nmap een subnetwerk heeft gescand en een aantal nieuwe hosts heeft ontdekt, wordt een PreliminarySubnetObject aangemaakt. Het zal het subnetadres en subnetmask bevatten voor het gedetecteerde subnet en verder een lijst met Hostobjecten die de nieuw gedetecteerde hosts representeren in dit subnet. – ArpContentObject.h/ArpContentObject.cpp: een klasse die gebruikt wordt door DlinkAnalyseToolBox. Een dergelijk object representeert één lijn uit de ARPtabel van deze host, en houdt dus bij welk MAC-adres te vinden is op welke poort van de switch. – ArpSwitchCouplingObject.h/ArpSwitchCouplingObject.cpp: dit object wordt gebruikt bij de analyse van ARP-tabellen voor een switch. Het houdt enerzijds de switch bij waarvoor de ARP-tabel is geanalyseerd en anderzijds een lijst met HostConnection objecten specifiek voor deze switch, afgeleid uit de analyse van de ARP-tabel.

3.4

Topologie detectiealgoritme

Wanneer we de machines in de testnetwerken van het testlabo beschouwen, stellen we vast dat er vrij veel hosts over minstens 2 NIC’s beschikken, waarvan er één meestal is geconnecteerd met het zogenaamde controlenetwerk”. Dit is meestal een netwerk van de vorm 10.10.X.Y en ” laat toe dat de beheerders van het testlabo kunnen inloggen op de machines in de testnetwerken en dat ze deze hosts kunnen beheren en monitoren. Een eerste vereiste bij het starten van het algoritme, is dat we op zijn minst kunnen beschikken over een aantal hosts waar we kunnen op inloggen.

Meestal zullen deze hosts

opgegeven worden aan de hand van een interface in het controlenetwerk en zullen we voor deze hosts over zowel login als paswoord beschikken. Deze zullen gespecifieerd worden in het


39

configuratiebestand /datafiles/initialHosts. Een voorbeeld van de inhoud van dit bestand kan zijn: 10.10.3.170:255.255.128.0:root:ruggent 10.10.3.171:255.255.128.0:root:ruggent Dit houdt in dat we bij de topologiedetectie kunnen vertrekken van twee hosts, al dan niet switches. Hierbij is voor elke host een IP-adres en subnetmask verschaft, plus login en paswoord, zodat inloggen mogelijk wordt.

Gegevensvoorstelling Belangrijk is nu om te weten hoe het algoritme de gegevens over de topologie bijhoudt in het geheugen. 1. Een lijst wordt bijgehouden van alle mogelijke hosts die zullen gedetecteerd worden, dit zonder onderscheid te maken tussen subnetwerken. Er zullen echter geen switches worden opgenomen in deze lijst. 2. Een tweede lijst houdt alle gedetecteerde switches bij, opnieuw zonder onderscheid te maken tussen subnetwerken. 3. In een derde lijst worden alle subnetwerken bijgehouden, inclusief een lijst van hosts per subnetwerk. Deze lijst zal pas worden opgebouwd nadat alle hosts en switches zijn gedetecteerd en geanalyseerd door het algoritme. Remote Agent Zoals al eerder aangetoond is, zal het niet altijd mogelijk zijn voor de controlemachine om rechtstreeks bepaalde hosts te gaan onderzoeken of bepaalde subnetwerken te gaan scannen. Dit zal bijvoorbeeld het geval zijn wanneer deze hosts zich in een VLAN bevinden waar de controlemachine geen rechtstreekse route naar heeft. Vandaar dat in dit programma ook een extra tool voorzien is om dit soort beperkingen te omzeilen, een zogenaamde Remote Agent. Dit zal een eenvoudig hulpprogramma zijn dat grotendeels dezelfde functionaliteiten biedt als het hoofdprogramma zelf, maar zal toelaten dat deze functionaliteit wordt uitgevoerd vanop een machine die enerzijds een interface heeft naar het controlenetwerk (en dus rechtstreeks bereikbaar


40

is vanaf de controlemachine) en anderzijds een interface heeft naar het huidige subnetwerk toe dat het programma moet analyseren. De aangeboden functies door deze Remote Agent zijn: • Het pingen van elke host in een subnetwerk waar de Remote Agent een interface naar heeft. Dit zal voornamelijk nodig zijn om ervoor te zorgen dat de ARP tabellen van de switches in het gedetecteerde netwerk recent genoeg zijn. • Het scannen van een volledig subnetwerk naar hosts die online zijn met behulp van nmap vanop de machine met de Remote Agent. Deze lijst kan doorgegeven worden naar het hoofdprogramma zodat ook deze over die informatie beschikt. • Het analyseren van de gedetecteerde hosts in een subnet. Zo kan er gekeken worden of op de gedetecteerde hosts telnet, ssh en snmp beschikbaar is en welk besturingssysteem deze machines draaien. Ook dit zal voornamelijk gebeuren met nmap vanop de Remote Agent en doorgegeven worden naar de controlemachine zodat het controleprogramma ook over deze informatie beschikt. • Het controleren door een Remote Agent of een bepaalde gedetecteerde machine in een subnetwerk een gewone host is of een switch, behoort ook tot de mogelijkheden. • De Remote Agent heeft ook de mogelijkheid om in te loggen op eender welke gedetecteerde machine in het subnetwerk en kan de informatie omtrent de interfaces op die host analyseren en doorgeven aan het hoofdprogramma. Het topologie detectiealgoritme Bij aanvang van het algoritme zal de lijst met hosts uiteraard die hosts bevatten die opgegeven zijn in /datafiles/initialHosts. Het algoritme zal de lijst met hosts één voor één onderzoeken en verder analyseren. De opeenvolgende stappen die zullen gevolgd worden zijn:

1. Beschouw de volgende machine uit de lijst met hosts. 2. Indien deze machine reeds geanalyseerd werd, ga dan terug naar de vorige stap. Zoniet, ga over naar de volgende stap. 3. Controleer of deze machine een controle-interface heeft, met andere woorden, of deze machine over een interface beschikt met prefix 10.10.X.Y.


41

Vervolgens kunnen we twee scenario’s onderscheiden: de beschouwde host beschikt over een controle-interface of beschikt niet over een controle-interface. a) De beschouwde host beschikt over een controle-interface:

merk op dat we nu vanop

de controlemachine rechtstreeks toegang hebben tot deze machine, zonder gebruik te maken van de Remote Agent. Volgende stappen zullen dan worden doorlopen: 4. Bepaal het besturingssysteem van deze machine. Dit kan gemakkelijk gebeuren aan de hand van nmap. 5. Controleer dan of deze host telnet, ssh en snmp ondersteunt. Ook dit kan gebeuren aan de hand van nmap. 6. Vervolgens wordt gecontroleerd of deze machine een gewone host of een switch is. Dit kan aan de hand van snmp of door inloggen, afhankelijk van welke services de host aanbiedt. Ook hier kunnen we dan opnieuw twee scenario’s onderscheiden: de beschouwde host die over een controle-interface beschikt, kan een gewone host of een switch zijn. 1. De host heeft een controle-interface en is een gewone host:

in dit geval is

er uiteraard de mogelijkheid om rechtstreeks vanop de controlemachine in te loggen op deze machine. De stappen die dan worden doorlopen zijn: 7. Het controleprogramma upload de Remote Agent als een .tar.gz-bestand naar de host en zorgt voor decompressie, zodat deze Remote Agent klaar is voor gebruik. 8. Het controleprogramma logt in op de host, download het bestand /etc/networking/interfaces lokaal en analyseert dit. Hieruit worden dan voor de huidige host de interfaces geconstrueerd. Per interface zal bijgehouden worden wat het MAC-adres is, het IP-adres, het subnetmask en de naam van de interface (cfr. eth0, eth1, ...); 9. Elk van de interfaces wordt dan beschouwd. Indien het gaat om een controle-interface of een interface die valt in de subnetwerken met subnetadres en subnetmask gespecifieerd in ./datafiles/ignoreSubnets, wordt een interface buiten beschouwing gelaten. 10. Indien het gaat om een geldige interface, wordt het subnetadres en subnetmask voor deze interface berekend. Dit houdt in dat de huidige host naar dit subnet een interface heeft. Aangezien het hier gaat om een host met een controle-interface, zal het een vereiste voor


42

de correcte werking van dit algoritme zijn dat deze host voorzien is van nmap. Bijgevolg zal nmap gebruikt worden om het gevonden subnet te scannen naar online hosts. 11. De gevonden hosts worden toegevoegd achteraan de lijst met alle gevonden hosts om later verder geanalyseerd te worden. 12. Nadat dit voor alle interfaces gebeurd is, wordt de toestand van de huidige host veranderd naar volledig geanalyseerd. 2. De host heeft een controle-interface en is een switch: 7. Indien blijkt dat het om een switch gaat, wordt door het programma gecontroleerd om welk type switch het gaat. Momenteel controleert het programma alleen naar een D-Link model DES-3526. Andere types kunnen echter gemakkelijk ondersteund worden door het programma mits het bijschrijven van extra klassen die dan in het programma kunnen opgenomen worden. 8. Indien het gaat om een D-Link DES-3526 of eventueel een andere, later nog te voorziene switch, worden de interfaces opgebouwd voor deze switch. Indien het gaat om een DES3526 model, kan het controleprogramma voor deze host 26 interfaces voorzien, elk met hetzelfde IP-adres (het IP-adres dat kan gebruikt worden om op deze switch in te loggen). Elk van deze interfaces kan dan ook voorzien worden van hetzelfde MAC-adres. De interfacenamen zullen dan niet overeenkomen met standaard Linux benamingen zoals eth0, eth1, ... maar zullen genummerd worden van 1 tot en met 26, overeenkomend met de poortnummers op deze switch. Voor een ander eventueel later nog te voorzien model switch, kunnen interfaces dan eventueel geanalyseerd worden door inloggen. Sommige switches hebben immers een ander MAC-adres per poort. 9. Eens het controleprogramma geverifieerd heeft dat het effectief om een switch gaat en de interfaces zijn geanalyseerd, wordt door het controleprogramma de toestand van deze host ingesteld op volledig geanalyseerd. 10. Vervolgens wordt deze switch toegevoegd aan de lijst met alle switches die reeds door het programma zijn gedetecteerd. b) De beschouwde host beschikt niet over een controle-interface:

een belangrijke

beperking in dit geval is natuurlijk dat er eventueel geen rechtstreekse route gekend is door de


43

controlemachine naar deze host, omdat deze zich bijvoorbeeld in een VLAN bevindt. Hier zal dan gebruik gemaakt worden van een Remote Agent programma dat geuploaded is naar een host met zowel een interface in het controlenetwerk als een interface in het subnetwerk waarin de huidige te analyseren host zich bevindt. Bemerk eerst en vooral wel dat, indien er een host aanwezig is met een interface in het controlenetwerk en een interface naar het subnetwerk van de huidige host, deze reeds zal voorzien zijn van een Remote Agent. Zo een host zal immers moeten opgegeven worden in ./datafiles/initialHosts en zal dus vooraan in de lijst worden bijgehouden met nog te analyseren hosts. Nieuwe hosts die geen controle-interface hebben en die achteraf gedetecteerd worden, worden achteraan de lijst toegevoegd door het controleprogramma. Dit heeft tot gevolg dat de voor het controleprogramma gekende hosts met een controle-interface reeds in het begin van de topologie detectie zullen geanalyseerd zijn en dus reeds van een Remote Agent zullen voorzien zijn.

Volgende stappen worden nu doorlopen: 7. Het subnetmask en subnetadres van de interface van de huidige host worden bepaald. 8. Vervolgens wordt de lijst met alle reeds gekende hosts afgezocht naar een host die zowel een interface heeft in het controlenetwerk als een interface naar het subnetwerk van de huidige host. 9. Indien zo een host gevonden wordt, zal het controleprogramma gebruik maken van de Remote Agent op deze host. 10. Het controleprogramma vraagt vervolgens aan de Remote Agent om een analyse uit te voeren van de huidige host. De Remote Agent zal hierna onderzoeken of de huidige host telnet, ssh en snmp aanbiedt. 11. Vertrekkend van de kennis over de services aangeboden door de huidige host, zal dan de Remote Agent proberen achterhalen of de huidige host een switch of gewone host is. Dit kan door snmp, indien de huidige host dit aanbiedt, of door inloggen, indien telnet of ssh wordt voorzien door de huidige host. De resultaten van deze testen worden door de Remote Agent lokaal opgeslagen in een bestand. 12. Het controleprogramma logt dan in op de host met de remote agent, download dit bestand met de testresultaten en analyseert lokaal deze resultaten.

3.5 Verdere uitwerking van de topologie:

44

Nu zijn er opnieuw twee mogelijke scenario’s: de host zonder controle-interface kan een switch blijken te zijn of een gewone host. 1. De host heeft geen controle-interface en is een gewone host: Volgende stappen worden doorlopen: 7. Het controleprogramma vraagt aan de Remote Agent om het bestand /etc/networking/interfaces te downloaden naar zijn locatie. 8. Indien dit geslaagd is, logt het controleprogramma in op de host met de Remote Agent, downloadt zelf het interfaces-bestand lokaal en analyseert de interfaces voor de huidige host. 9. Deze interfaces zullen niet verder geanalyseerd worden. Indien deze host nog een interface zou hebben naar een ander subnetwerk, dan is een vereiste van dit programma dat er een host met een controle-interface beschikbaar is in dit subnetwerk, en zal dus vanop die host dit andere subnetwerk via nmap worden gedetecteerd en verder geanalyseerd. 10. De toestand van de huidige host wordt dan ingesteld op volledig geanalyseerd. 2. De host heeft geen controle-interface en is een switch: Dit is in feite een situatie die nooit kan voorvallen. In het algoritme voor topologiedetectie wordt er verondersteld dat alle switches een IP-adres zullen hebben in het controlenetwerk en nooit een IP-adres in het gedetecteerde subnetwerk zelf. Bijgevolg zullen er alleen maar gewone hosts worden gedetecteerd in nieuw ontdekte subnets.

3.5

Verdere uitwerking van de topologie:

Opbouwen analyselijst: Eens alle hosts zijn gedetecteerd door het eerder besproken algoritme, wordt een lijst opgebouwd van hosts die dan kan aangewend worden voor verdere analyse, zoals besproken in hoofdstuk 2. Dit kan eenvoudig doordat het controleprogramma de lijst van alle gedetecteerde hosts overloopt. Voor elke host worden dan al zijn IP-adressen uitgeschreven naar een bestand, het besturingssysteem en ook login en paswoord indien gekend. In dit bestand bevindt er zich dan een IP-adres per lijn, in volgend formaat:


45

:::<paswoord>. Dit is hetzelfde formaat als terug te vinden is in ./datafiles/iplist. Door deze lijnen dus te kopiëren in dit configuratiebestand, kunnen de gedetecteerde hosts verder worden geanalyseerd. Dit bestand zal de naam analysis.list hebben en zal terug te vinden zijn in de folder ./topology. Opbouwen van subnetten: Het controleprogramma zal vervolgens overgaan tot het onderverdelen van de verschillende gedeteceerde hosts in subnetten. Hierbij zal dan de eerder vermelde lijst van alle gedetecteerde subnetten worden opgebouwd. Elke subnet wordt gerepresenteerd door een zogenaamd Subnetobject, dat per subnet het subnetadres, subnetmask en een lijst met hosts in dit subnet bijhoudt. Dit kan eenvoudigweg gebeuren door voor elke host in de hostlijst hun interfaces te beschouwen, te onderzoeken in welk subnet ze een interface hebben en dan ofwel een nieuw Subnet-object aanmaken indien dit subnet nog niet eerder is tegengekomen en de host toe te voegen aan dit subnet, ofwel door de host toe te voegen aan de hostlijst van een reeds bestaand Subnet-object indien het subnet wel al eerder is tegengekomen. Voor elk van de switches wordt dan gekeken met welke hosts uit welke subnetten ze geconnecteerd zijn. In deze subnetten worden ze dan aan de lijst van switches en hubs toegevoegd, hoewel ze natuurlijk een IP-adres in het controlenetwerk zullen hebben en niet in de subnetten zelf. Pingen van alle hosts in elk subnet: Zoals reeds eerder vermeld, kan een volledige topologie detectie eventueel gehinderd worden doordat in de ARP-tabellen van de switches de entries slechts een beperkte TTL hebben, waarna ze verwijderd worden. Bijgevolg zal het controleprogramma dan het volgende doen om dit te vermijden: 1. De intussen opgebouwde lijst met subnetten wordt overlopen. 2. Per beschouwd subnet, wordt een bestand aangemaakt met de gedetecteerde IP-adressen in dit subnet. 3. Het controleprogramma zoekt dan in elk subnet opnieuw een host die een interface heeft naar het doelnetwerk en in het controlenetwerk. Deze host zal dus opnieuw over een Remote Agent beschikken.


46

4. Het controleprogramma zal voor elk subnet naar de Remote Agent het bestand met IPadressen uploaden en de Remote Agent telkens de opdracht te geven alle IP-adressen uit dit bestand te pingen. 5. De Remote Agent zal dit bestand inlezen en om het verkeer in het netwerk te beperken tot een minimum, zal elke host gepingd worden met twee pakketjes. Verzamelen van de ARP-informatie uit de gedetecteerde switches: Eens alle hosts in elk subnet zijn gepingd, kan het controleprogramma de lijst van gedetecteerde switches overlopen en voor elke switch inloggen en de inhoud van de ARP-tabel lokaal downloaden. Eens deze informatie geanalyseerd is voor elke switch, weet het controleprogramma voor elke switch welk MAC-adres terug te vinden is op welke poort van de switch. Het kan dan de lijst gaan overlopen van alle hosts, op zoek naar de corresponderende MAC-adressen. Op deze manier kan het programma afleiden op laag 2 wat de connectiviteit is tussen de verschillende hosts en switches om een volledig beeld van de topologie te verkrijgen. Natuurlijk is het mogelijk dat het programma in die ARP-informatie MAC-adressen zal tegenkomen die niet bij gedetecteerde hosts behoren. Dit zal dan ook bijgehouden worden en in de resulterende output van het programma weergegeven worden als links die niet verder kunnen gevolgd worden. Genereren van de noodzakelijke output omtrent de gedetecteerde topologie: Feedback:

feedback omtrent de gedetecteerde topologie zal weergegeven worden onder vorm

van twee XML-bestanden. Deze zullen uiteindelijk geplaatst worden in de folder ./topology. We onderscheiden: Visualisatie van de topologie door middel van een GUI:

voor het visualiseren

van de gedeteceerde topologie wordt er gebruik gemaakt van een GUI voor het representeren van topologieën, ontwikkeld door Bruno Volckaert in zijn thesis Automatische generatie van grafische gebruikersinterfaces voor netwerkbeheer. Hierin is er een GUI ontwikkeld in Java, dat een XML-bestand als input krijgt met een beschrijving van één of meerdere subnetwerken onder XML-formaat en vervolgens automatisch de nodige coördinaten berekent van de netwerknodes op het scherm om de volledige topologie te kunnen tonen. Dit XML-bestand met naam output_gui_topology.xml wordt in de map ./topology geplaatst, waar zich ook reeds een bestand ipnetwork.dtd bevindt dat de grammatica en structuur van dit XML-bestand zal vast-


47

leggen. Voor meer uitleg omtrent het formaat van dit inputbestand en de werking van de GUI wordt dan ook verwezen naar het eerder vernoemde eindwerk van Bruno Volckaert. Tekstuele weergave van de gevonden connecties: dit was een vooropgestelde vereiste voor het ontwikkelde programma: er moest een beschrijving kunnen gegeven worden van de gevonden connecties, zodat achteraf het gedetecteerde netwerk opnieuw zou kunnen opgebouwd worden. Deze weergave zal geplaatst worden in een XML-bestand met naam: TopologyDescription.xml. Ook dit bestand zal geplaatst worden in de folder ./topology waar zich ook een XSLT-stylesheet zal bevinden met naam stylesheet_topology.xsl. Het principe van XML-bestanden in samenwerking met XSLT-bestanden werd reeds eerder besproken in hoofdstuk 2, voor meer informatie hieromtrent verwijzen we daar dan ook naar. Voor de structuur van dit XML-bestand en de output in combinatie met de XSLT-stylesheet verwijzen we naar de volgende paragraaf met het uitgewerkte voorbeeld (Voor een voorbeeld van de gebruikte stylesheet verwijzen we naar bijlage B).

3.6

Uitgewerkt voorbeeld

Beschouwen we opnieuw onderstaand voorbeeld van een testopstelling in het testlab (zie figuur 3.9):

Veronderstel dat we bij aanvang van het algoritme de inhoud van het configuratiebestand ./datafiles/initialHosts als volgt is: 10.10.3.170:255.255.128.0:root:ruggent 10.10.3.172:255.255.128.0:wodclerc:ruggent We beschikken dus, zoals de vereisten van het algoritme bepalen, over één machine in het te detecteren subnet 10.0.1.0/24 met een controle-interface, zijnde de host met het IP-adres 10.10.3.170, dat ook een interface heeft naar het subnetwerk 10.0.1.0/24. Verder beschikken we ook over de lijst van alle te beschouwen switches, namelijk met IP-adres 10.10.3.172. De tweede switch in de figuur is onderdeel van het controlenetwerk en kan genegeerd worden. Stel dan ook dat de lijst met initiële hosts waarvan het algoritme vertrekt, deze twee hosts bevat, en dan ook


48

Figuur 3.9: Voorbeeld topologie detectie

in deze volgorde, dus eerst 10.10.3.170, dan 10.10.3.172. Het verloop van het detectie algoritme bij dit voorbeeld zal zijn: 1. Eerst wordt de host met IP-adres 10.10.3.170 beschouwd. Er wordt gecontroleerd of deze host nog niet geanalyseerd is. Wat uiteraard nog niet het geval zal zijn. 2. Controleer of deze host een controle-interface heeft, dus een interface met prefix 10.10.X.Y. Dit is uiteraard het geval, dus mogen we concluderen dat deze host rechtstreeks bereikbaar is vanop de controlemachine. 3. Controleer of het besturingssysteem nog niet gekend is. Dit zal nog niet het geval zijn, dus bepaal dit met nmap. Dit zal Linux blijken te zijn. 4. Bepaal vervolgens welke services deze host draait. Dit kan ook aan de hand van nmap. Deze host zal blijken ssh te draaien, echter geen snmp of telnet. 5. Vervolgens wordt gecontroleerd door het programma of deze machine een switch is of een gewone host. Dit gebeurt door inloggen aangezien geen snmp voorhanden is en zal een gewone host blijken te zijn. 6. Nu het programma weet dat het om een gewone host gaat, wordt de Remote Agent geuploaded naar deze host en klaargemaakt voor verder gebruik.


49

7. Vervolgens wordt ingelogd op de host en worden de interfaces geanalyseerd. Hieruit zal uiteraard blijken dat er twee interfaces zijn: 10.10.3.170 en 10.0.1.100. De eerste interface zal genegeerd worden voor verdere analyse wegens een controle-interface. De tweede interface zal nader beschouwd worden. 8. Voor de interface 10.0.1.100 wordt het subnet adres bepaald en bijhorend subnetmask. Dit zal blijken om het subnetwerk 10.0.1.0/24 te gaan. Dit subnetwerk zal met behulp van nmap gescand worden vanop de huidige host. De bekomen informatie wordt doorgegeven aan de controlemachine, die de informatie analyseert en hieruit afleidt dat er twee hosts in dit netwerk actief zijn, met IP-adres 10.0.1.100 en met IP-adres 10.0.1.101. De host met IPadres 10.0.1.100 kan buiten beschouwing worden gelaten, dit is natuurlijk de huidige host. Een nieuwe host met IP-adres 10.0.1.101 wordt achteraan de lijst met hosts toegevoegd voor verdere analyse in de toekomst. 9. De toestand voor de huidige host met interfaces 10.0.1.100 en 10.10.3.170 wordt ingesteld als volledig geanalyseerd. Op dit punt weten we dus welke interfaces deze host heeft, welk besturingssysteem, welke relevante services deze draait en in welke subnetwerken deze een interface heeft. De eerste host is nu geanalyseerd. Gaan we nu naar de tweede host in de lijst met hosts, dan komen wij bij de machine met IP-adres 10.10.3.172, de switch in de opstelling. Nu worden volgende stappen doorlopen voor deze host: 1. Opnieuw wordt begonnen met een controle of deze host nog niet geanalyseerd is. Uiteraard zal dit nog niet het geval zijn. 2. Opnieuw zal blijken na controle dat deze host een interface heeft in het controlenetwerk met prefix 10.10.X.Y, namelijk 10.10.3.172. Ook deze host is dus vanaf de controlemachine rechtstreeks bereikbaar voor analyse, interventie van een Remote Agent zal niet nodig zijn. 3. Er wordt vervolgens gecontroleerd door het programma welk besturingssysteem deze machine gebruikt. Er zal geen besturingssysteem kunnen vastgesteld worden, het programma gaat verder. 4. Het controleprogramma gebruikt nmap om te bepalen welke services deze machine aanbiedt. Er zal vastgesteld worden dat deze machine telnet aanbiedt, ssh en snmp.


50

5. Het programma zal controleren of het om een switch of een gewone host gaat. Aangezien de host snmp aanbiedt, zal de controle gebeuren door het gebruik van snmpget. De waarde voor system.sysDescr.0 wordt gecontroleerd met snmpget en de output hiervan wordt geanalyseerd. Door controle op specifieke kernwoorden, zoals switch, wordt vastgesteld dat het hier om een switch gaat. 6. Nu is vastgesteld dat het gaat om een host met een controle-interface, maar echter ook een switch, wordt door het controleprogramma niet gepoogd om een Remote Agent te uploaden. 7. Door het programma wordt gecontroleerd, ook hier via snmp, aangezien de host snmp aanbiedt, of het om een D-Link switch gaat van het type DES-3526. Dit kan gebeuren door te controleren op bepaalde kernwoorden, zoals DES-3526. Dit kan echter ook gebeuren door inloggen indien de switch geen snmp aanbiedt, maar wel telnet en/of ssh. In dit geval zal worden vastgesteld dat het om een switch van dit type gaat. 8. Vervolgens zal het programma de interfaces analyseren voor deze switch. Hiervoor zal er niet ingelogd worden. Aangezien door het controleprogramma het type switch gedentificeerd is, kan door het controleprogramma zelf besloten worden om aan deze switch 26 interfaces toe te kennen, allemaal met zelfde IP-adres (10.10.3.172) en zelfde MAC-adres. Dit zal immers voor elke D-Link switch van het type DES-3526 het geval zijn. 9. Deze switch wordt vervolgens toegevoegd aan de lijst van gevonden switches, niet aan de lijst van nog verder te analyseren hosts. 10. Ook voor deze switch wordt dan de toestand ingesteld als zijnde volledig geanalyseerd. Ook de tweede host in de topologie is nu gedetecteerd en geanalyseerd. In de lijst met te analyseren hosts zal er nog één host aan bod komen, de eerder gedetecteerde host met IP-adres 10.0.1.101. Voor deze host zullen volgende stappen worden doorlopen: 1. Na een eenvoudige controle, zal het programma opnieuw ondervinden dat deze laatste host nog niet geanalyseerd is. 2. Het controleprogramma test of deze host een controle-interface heeft of niet. Aangezien deze host tot nu toe slechts over één interface beschikt, met IP-adres 10.0.1.101, zal deze test uiteraard negatief zijn. Een belangrijk gevolg hiervan is dat voor het analyseren van deze host er zal moeten gewerkt worden via een Remote Agent.


51

3. Het programma bepaalt van deze interface het subnetadres en subnetmask, wat opnieuw 10.0.1.0/24 oplevert. Vervolgens zoekt het programma de lijst af met alle hosts tot nu toe gevonden naar een host die enerzijds zowel een controle-interface heeft, en dus rechtstreeks te bereiken is door de controlemachine, en die anderzijds een interface heeft in dit specifieke subnet. In dit geval zal het controleprogramma de host vinden met IP-adressen 10.10.3.170 en 10.0.1.100. Deze zal, zoals eerder besproken, reeds voorzien zijn van een Remote Agent. 4. Vervolgens zal het controleprogramma opdragen aan de Remote Agent op 10.10.3.170 om te controleren welke services de host met IP 10.0.1.101 zal draaien. De Remote Agent zal controleren of de services telnet, ssh en snmp worden aangeboden. Daarna zal de Remote Agent ook controleren of de host met IP 10.0.1.101 een switch of gewone host is. De resultaten van deze tests worden opgeslagen in een bestand, dat vervolgens door het controleprogramma lokaal op de controlemachine wordt gedownload en geanalyseerd. Hieruit zal blijken dat de host met interface 10.0.1.101 geen telnet of snmp aanbiedt, maar wel ssh en een gewone host is maar geen switch. 5. Nadat is vastgesteld via de Remote Agent dat de host met IP 10.0.1.101 een gewone host is en geen switch, draagt het controleprogramma aan de remote agent op om het bestand ./etc/networking/interfaces te downloaden naar de host die de Remote Agent ondersteunt (10.10.3.170). Vervolgens zal het controleprogramma inloggen op de host 10.10.3.170 en het interface bestand lokaal downloaden naar de controlemachine en het analyseren. Hieruit zal blijken dat de host twee interfaces heeft, 10.0.1.101 en 10.10.3.171. Deze tweede interface zal echter niet meer verder geanalyseerd worden aangezien dit een controle-interface is. 6. Voor deze host wordt vervolgens ook de status ingesteld als volledig geanalyseerd. Op dit punt is ook de derde host in de opstelling geanalyseerd. Intussen zijn er geen extra hosts meer toegevoegd aan de lijst met alle ontdekte hosts, dus het algoritme stopt hier. Dan zal een lijst worden geproduceerd die kan gebruikt worden voor verdere analyse van de hosts die gedetecteerd zijn. Dit levert op: 10.10.3.170:LINUX:root:ruggent 10.0.1.100:LINUX:root:ruggent 10.10.3.172:wodclerc:ruggent 10.10.3.171:LINUX


52

10.0.1.101:LINUX Dit zal terug te vinden zijn in analysis.list in de map ./topology. Dit kan dan gebruikt worden als inhoud voor ./datafiles/iplist zoals beschreven in hoofdstuk 2. Het programma onderneemt dan volgende stappen: 1. Het programma zal de lijst met subnetten opbouwen en zal in dit geval slechts één subnet opleveren, zijnde het subnet met subnetadres 10.0.1.0/24. Dit zal als hosts alleen maar de beide Linux-machines bevatten met IP-adres 10.0.1.100 en 10.0.1.101. 2. Verder zal zich ondertussen ook in de lijst met gedetecteerde switches slechts één host bevinden, de D-Link DES-3526 switch met IP-adres 10.10.3.172. 3. Het programma zal dan in het gevonden subnet op zoek gaan naar een gekende host met een controle-interface enerzijds en een interface naar het subnetwerk anderzijds, een host die dus reeds voorzien is van een Remote Agent. Dit zal de Linux-machine met IP 10.10.3.170 en 10.0.1.100 opleveren. 4. Het controleprogramma stelt dan een lijst op met alle IP-adressen in dit subnet, dit zullen de IP-adressen 10.0.1.100 en 10.0.1.101 zijn. Deze worden opgeslaan in een bestand en geuploaded naar de Remote Agent op 10.10.3.170. 5. De Remote Agent krijgt dan opdracht van het controleprogramma om dit bestand in te lezen en die IP-adressen te pingen. 6. Het controleprogramma overloopt dan alle switches, in dit geval slechts één switch met IP-adres 10.10.3.172 en logt in op deze machine om de geupdate ARP-tabel uit te lezen en lokaal te analyseren. Eens de ARP-inhoud van deze switch is geanalyseerd, wordt door het programma enerzijds het bestand output_gui_topology.xml (bestemd voor de GUI) aangemaakt en anderzijds het bestand TopologyDescription.xml (bestemd voor de tekstuele beschrijving van de connecties op laag 2). Beide bestanden zullen in de map ./topology geplaatst worden. Voor de inhoud van beide bestanden plus een screenshot van de weergave met de GUI en de weergave van TopologyDescription.xml in een browser met behulp van de bijhorende XSLT-stylesheet, verwijzen we naar de bijlages (C) van dit eindwerk.

PROVISIONING

53

Hoofdstuk 4

Provisioning 4.1

Inleiding

Een laatste luik van het te ontwikkelen programma zijn faciliteiten voor provisioning. Dit houdt in dat we ons na het analyseren en detecteren van hosts, nu gaan richten op het remote beheren van deze hosts. Wanneer we de commerciële management tools bekijken, valt vooral op dat veel van deze tools gebruik maken van SNMP voor het remote beheren van hosts. Dit zijn tools die van toepassing zijn op meerdere hosts, maar vereisen wel dat deze hosts SNMP ondersteunen. Dit is, zoals we reeds eerder aanhaalden, zeker niet altijd het geval in het testlab. Bijgevolg is voor deze thesis vooral gekozen voor een aanpak die geen SNMP gebruikt. We kunnen echter opnieuw een stap verder gaan, doordat we voor alle machines over genoeg gegevens beschikken om te kunnen inloggen. Dit zal toelaten om functionaliteit te voorzien die veel verder gevorderd zal zijn dan bij standaard commerciële tools.

Af en toe zijn er wel commerciële tools te verkrijgen die een meer dan standaard beheerfunctionaliteit leveren, niet gebruikmakend van SNMP. Het gaat hier dan niet meer over tools die algemeen bruikbaar zijn, maar wel over tools die gericht zijn op specifieke apparatuur, zoals bijvoorbeeld Cisco apparatuur. Bijgevolg gaan we proberen om nu het beste van beide oplossingen te combineren: een tool met meer gevorderde beheersfunctionaliteit die toch op meerdere hosts is toe te passen.

De verschafte functionaliteit in dit programma is:

4.2 Belangrijke bestanden voor het provisioning gedeelte

54

• Het instellen van IP-adressen op hosts (voor één enkele host of voor meerdere hosts sequentieel na mekaar). • Het installeren van een kernel op een Linux-machine (opnieuw voor slechts één host of voor meerdere hosts sequentieel na mekaar). • Het maken van backups van volledige directory-trees met behulp van scp(weer voor slechts één host of voor meerdere hosts sequentieel na mekaar). • Het downloaden van één enkel bestand van een bepaalde host en het uploaden van één enkel bestand naar een bepaalde host. Dit kan toelaten snel en efficiënt een bepaald configuratiebestand op een host aan te passen.

4.2

Belangrijke bestanden voor het provisioning gedeelte

• Configuratiebestanden: – ./datafiles/login: bevat koppels van (login,paswoord), te gebruiken door het programma als de gebruiker zelf geen login en paswoord verschaft. Elke lijn is van de vorm: <paswoord>. – ./datafiles/ipChangeList: wanneer IP-adressen voor meerdere hosts moeten gewijzigd worden, worden de te wijzigen gegevens opgenomen in dit bestand. De gegevens voor elke host worden van mekaar gescheiden door de delimiter #END. De velden LOGIN en PASSWORD spreken voor zich. Wat de andere velden betreft, deze zullen telkens van de vorm zijn: ::. Een voorbeeld hiervan is: #END LOGIN:root PASSWORD:ruggent IP:192.168.0.5:192.168.0.6 NETMASK:255.255.255.0:255.255.255.0 DNS:192.168.0.1:192.168.0.1 END


55

– ./datafiles/backupFilesForHosts: in dit bestand worden parameters opgenomen die gebruikt worden bij het nemen van een backup van gegevens voor bepaalde hosts in het netwerk. Voor elke host worden de parameters opnieuw afgebakend aan de hand van de delimiter #END. De velden IP, login en password spreken voor zich. Het veld remote directories zal gevolgd worden door de directories op de gespecifieerde host waarvoor lokaal een backup moet voorzien worden. Dit kan één enkele directory zijn of de root van een volledige directory-tree. Een voorbeeld is: #END IP:192.168.0.10 login:root password:ruggent remote directories: /root/ /etc/ #END – ./datafiles/kernelInstallOnHosts: hier worden parameters opgenomen die gebruikt worden voor het installeren van een kernel-image op meerdere hosts. Voor elke host zal er een lijn worden opgenomen in dit bestand, met per lijn een parameterreeks van volgende vorm: ::<password>::. De velden ip, login en password spreken voor zich. De installatiewijze zal aangeven of er een standaard image moet ge¨ınstalleerd worden via apt of er een zelfgebouwde image moet geupload en ge¨ınstalleerd worden op de host. Het laatste veld zal dan de naam specifiëren van de zelfgebouwde image die zal ge¨ınstalleerd worden of de naam van de image die moet ge¨ınstalleerd worden via apt. • Expectscripts: – ./expectscripts/backupScript.exp: voor het nemen van backups voor een bepaalde host werd gekozen om een apart expectscript te voorzien. Hoewel er al een expectscript voorzien is om via scp bestanden te downloaden (./expectscripts/secureCopyFiles), maakt dit script geen gebruik van de optie -r” ” voor scp, dat toelaat recursief volledige bestandsbomen te kopiëren. Dit zal wel het


56

geval zijn bij dit backupscript, dat dit script ook toelaat een hogere timeout waarde in te stellen dan bij het script secureCopyFiles. Dit laatste kan vooral handig zijn indien het gaat over grote hoeveelheden data die moeten gekopieerd worden. – ./expectscripts/executeRemoteStoreLocallyLinux.exp: een expectscript dat toelaat om via ssh-inloggen remote commando’s uit te voeren op een Linux-host en lokaal de output op te slaan. – ./expectscripts/installLinuxKernelApt.exp: een expectscript dat kan gebruikt worden om remote een kernelimage te installeren op een host gebruik makend van apt. – ./expectscripts/secureCopyFiles: een expectscript dat toelaat om van een host lokaal bestanden te downloaden, gebruik makend van scp. – ./expectscripts/uploadFiles: laat toe dat vanop de host waarop het controleprogramma zelf draait via scp bestanden kunnen geupload worden naar een remote host. – ./expectscripts/installKernelSelfmade.exp: een expectscript dat kan gebruikt worden om remote een zelfgebouwde kernelimage te installeren op een host, nadat de image eerst werd geupload naar deze host. • Programmabestanden (Voor de UML-diagrammen verwijzen we naar bijlage A): – ProvisioningEngine.h en ProvisioningEngine.cpp: deze klasse verzorgt de provisioningfunctionaliteit. Het laat toe IP-adressen te wijzigen op hosts in het netwerk, kernels te installeren, backups te nemen van volledige bestandsbomen en het downloaden plus terug uploaden van enkelvoudige bestanden. – ProvisioningToolBox.h en ProvisioningToolBox.cpp: deze klasse bevat vooral functionaliteit gemeenschappelijk voor verschillende functies uit ProvisioningEngine, zoals hulpmethodes voor het downloaden en uploaden van bestanden naar hosts, methodes om remote commando’s uit te voeren op hosts in het netwerk, ... – IpChangeObject.h en IpChangeObject.cpp: dit object zal gebruikt worden bij het wijzigen van IP-adressen voor machines in het netwerk. Voor elke host waarvoor de IP-gegevens moeten gewijzigd worden, zoals gespecifieerd in ./datafiles/ipChangeList, houdt dit object het IP-adres van die host bij, de login, het paswoord en verder de nieuwe waarden voor DNS-servers, IP-adressen en netmask.

4.3 Instellen van IP-adressen

4.3

57

Instellen van IP-adressen

Wat betreft het instellen van IP-adressen op remote hosts, is opnieuw de functionaliteit voorzien voor het instellen van een IP-adres op één enkele host of op meerdere hosts sequentieel. Beide gevallen zullen hier nu verder worden uiteen gezet.

4.3.1

Instellen van IP-adres op ´ e´ en enkele host

Opnieuw is er voor gekozen om bij deze optie enige interactiviteit te voorzien met de gebruiker. Twee gevallen zijn mogelijk: de gebruiker kent de login en het paswoord voor de betrokken host of hij kent deze gegevens niet. Volgende stappen worden genomen voor het wijzigen van interface-configuraties: 1. Eerst vraagt het programma aan de gebruiker het huidige IP-adres van de host waarvoor hij het IP-adres wil wijzigen. 2. Vervolgens wordt aan de gebruiker gevraagd, of hij ook effectief enige kennis heeft over het paswoord en login van deze host. Dit kan de gebruiker aangeven door Y(ja) of N(neen). We veronderstellen nu dat de gebruiker over deze gegevens beschikt, dus hij antwoordt Y. Indien de gebruiker hier aangeeft dat hij niet op de hoogte is van de login gegevens, zal op exact dezelfde manier verder gegaan worden als wanneer hij wel het login en paswoord voor die host kan verstrekken. Alleen zullen dan bij het inloggen op die host alle combinaties van (login,paswoord) geprobeerd worden uit het configuratiebestand ./datafiles/login. We gaan er hier dus verder vanuit dat de gebruiker aangeeft dat login en paswoord door hem gekend zijn. 3. De gebruiker wordt vervolgens naar het paswoord en de login van deze host gevraagd. (deze stap wordt uiteraard overgeslaan indien de gebruiker opgaf dat hij de logingegevens niet kent). 4. Gebruik makend van IP, login en paswoord wordt dan met behulp van scp het bestand /etc/network/interfaces gedownload van deze host. Het bestand wordt ingelezen en geanalyseerd. 5. De gebruiker krijgt dan een interactieve dialoog voorgeschoteld waarin hij de mogelijkheid heeft om de gegevens uit het interface bestand te wijzigen. Uiteraard wordt hierbij alleen de mogelijkheid geboden om de gegevens voor het specifieke IP-adres te wijzigen dat eerder

4.3 Instellen van IP-adressen

58

opgegeven is door de gebruiker. Dit is vooral van belang als de host meerdere interfaces heeft met een verschillend IP-adres. 6. De door de gebruiker ingegeven wijzigingen worden permanent gemaakt in de lokaal opgeslagen kopie van het interfaces-bestand. 7. Vervolgens wordt de gewijzigde kopie van het bestand opnieuw geupload naar de remote host door middel van scp en wordt dus de oude versie van het interfaces-bestand op de remote host overschreven met de gewijzigde versie. 8. Eens het bestand succesvol is geupload, zal het commando /etc/init.d/networking restart remote worden uitgevoerd op de host, wat nodig is om de wijzigingen actief te maken op die host, met als voordeel dat hiervoor de host niet moet herstart worden. Uiteraard is hier gekozen voor de zogenaamde permanente” oplossing. Een eenvoudiger en ” sneller methode zou geweest zijn dat het commando ifconfig” gebruikt werd op de remote host ” om de interface-gegevens te wijzigen. Bij een herstart van de host of een power failure zouden die wijzigingen onmiddellijk opnieuw hersteld worden naar hun vorige waarden. Bijgevolg is er voor gekozen om het interfaces-bestand aan te passen. Dit is natuurlijk een omslachtiger en tragere methode, maar heeft als voordeel dat de wijzigingen persistent zijn, zelfs in geval van een herstart van de betrokken host.

4.3.2

Sequentieel instellen van IP-adressen op meerdere hosts

Wanneer we wensen om voor meerdere hosts sequentieel de interface-gegevens te wijzigen, voorzien we geen interactiviteit meer per host met de gebruiker. Het proces kan geautomatiseerd worden aan de hand van een configuratiebestand. Belangrijk hierbij is het configuratiebestand ./datafiles/ipChangeList. (zie sectie inleiding). Hierin kan voor meerdere hosts gespecifieerd worden welke wijzigingen er moeten doorgevoerd worden aan de interface-configuraties. Deze functionaliteit zal aanvankelijk beginnen met het inlezen en verwerken van dit configuratiebestand. Vervolgens zal voor elke host sequentieel dezelfde methode gevolgd worden als voor het wijzigen van de interface configuratie voor één host, maar nu zal het programma zelf de nodige wijzigingen aan het interfaces-bestand voor elke host afleiden uit de inhoud van ./datafiles/ipChangeList en doorvoeren vóór de gewijzigde bestanden te uploaden.

4.4 Installeren van een kernel op een Linux-machine

4.4

59

Installeren van een kernel op een Linux-machine

Voor het installeren van een kernel zijn er twee mogelijkheden voorzien in het programma: het installeren van een kernel op een remote host via apt en het installeren van een eigen gebouwde kernel image op een remote host. • Installeren van een kernel via apt: deze optie geeft de mogelijkheid om op een remote host een standaard kernel image te installeren via apt. • Installeren van een zelfgemaakte kernel image op een remote host: deze optie geeft de mogelijkheid om een zelfgebouwde kernel image te installeren. Nu zijn in de netwerken in het testlab bij het IBCN veel hosts aanwezig die gebruik maken van dezelfde NIC’s, MB’s, ... Bijgevolg is er vanuit gegaan dat er geen kernel moet gecompileerd worden op de hosts vanaf source, maar dat er een .deb (debian) package ter beschikking is die op meerdere hosts in het netwerk integraal kan worden ge¨ınstalleerd. Opnieuw is de mogelijkheid voorzien voor het installeren van een kernel op één enkele host en op meerdere hosts sequentieel.

4.4.1

Installeren van een kernel op ´ e´ en host

Bij het installeren van een kernel op één enkele host is enige interactiviteit voorzien met de gebruiker. Er kan een onderscheid gemaakt worden tussen twee situaties: de gebruiker kent de login gegevens voor deze host of hij kent deze niet. De gebruiker kent de login gegevens Het programma doorloopt volgende stappen bij interactie met de gebruiker: 1. Het programma vraagt aan de gebruiker om het IP-adres op te geven van de host waarop een kernel moet worden ge¨ınstalleerd. 2. Er wordt gevraagd aan de gebruiker of hij de login gegevens kent. We veronderstellen dat hij hier bevestigend antwoord. 3. De gebruiker wordt gevraagd de login voor deze host in te geven. 4. Het programma vraagt het paswoord.

4.4 Installeren van een kernel op een Linux-machine

60

5. De gebruiker moet specifiëren of hij een standaard kernel wil installeren via apt of een zelfgemaakte kernel image. Dit moet respectievelijk aangegeven worden door het ingeven van de strings apt” of selfmade”. ” ” 6. De naam van de image wordt gevraagd om te installeren. Indien het gaat om een zelfgebouwde kernel, moet deze zich bevinden in de subdirectory ./kernelImages en moet de volledige naam van de image worden opgegeven(.deb). Indien het gaat om een standaard kernel, te installeren via apt, moet de naam opgegeven worden waarmee de kernel image kan ge¨ınstalleerd worden via apt. Vervolgens wordt de kernel ge¨ınstalleerd op de remote host. Hierbij zijn er twee opties: • Het ging om een zelfgebouwde kernel image. In dit geval zal de kernel image waarvan de naam door de gebruiker gespecifieerd is, geupload worden naar de remote host, dit aan de hand van remote interactie met behulp van het expectscript ./expectscripts/uploadFiles. Eens dit succesvol is voltooid, zal er remote ingelogd worden op de host met behulp van het expectscript ./expectscripts/installKernelSelfmade.exp. Dit zal gebruik maken van het commando dpkg -i om de kernel te installeren op de remote host. • Het ging om een standaard kernel image te installeren via apt. In dit geval wordt er remote ingelogd op de host via het expectscript ./expectscripts/installKernelApt.exp. Dit zal het command apt-get install remote uitvoeren om een standaard kernel via apt te installeren. De gebruiker kent de login gegevens niet In dit geval worden dezelfde stappen en technieken gebruikt als wanneer de gebruiker wel over deze gegevens beschikt. Het enige verschil hier is dat, telkens wanneer er een login en paswoord moet verschaft worden voor het uploaden van een kernel image of het remote uitvoeren van een installatiecommando, elke combinatie van (login,password) zal geprobeerd worden zoals gespecifieerd in ./datafiles/login.

4.4.2

Installeren van een kernel op meerdere hosts sequentieel

Wanneer meerdere hosts moeten voorzien worden van een kernel image, kan dit opgegeven worden aan de hand van het configuratiebestand ./datafiles/kernelInstallOnHosts. Hierin zullen per host een aantal parameters worden opgegeven die het programma nodig heeft om een kernel

4.5 Downloaden en uploaden van één enkel bestand van en naar een machine

61

te installeren. Per host wordt het volgende opgegeven: ::<password>:<selfmade_or_apt>: Er wordt per host opgegeven wat het IP is van deze host, wat de login en password is voor deze host, of het gaat om een installatie via apt of dat het gaat om een selfmade kernel image die moet ge¨ınstalleerd worden, en verder wat de naam is van de kernel image die moet ge¨ınstalleerd worden. Voor elke host zal dan dezelfde methode gebruikt worden als voor de installatie op één host, waarbij er nu uiteraard geen interactiviteit met de gebruiker zal zijn. Merk op, dat het login en paswoord veld in het configuratiebestand optioneel zijn. Indien deze niet worden vermeld, worden alle mogelijke combinaties van (login,paswoord) uit ./datafiles/login geprobeerd.

4.5

Downloaden en uploaden van ´ e´ en enkel bestand van en naar een machine

Deze optie is voornamelijk toegevoegd met het oog op de voorgaande optie, namelijk het installeren van kernel images op een host. Immers, voor het installeren van een kernel op een host, is het niet voldoende om alleen maar de image van die kernel zelf te installeren. De host moet nog herstart worden, maar daarnaast kan het bijvoorbeeld nodig zijn om de configuratie van de bootloader aan te passen. Bij Linux-machines zal het meestal gaan om Grub of Lilo. Met deze optie is het mogelijk om, bijvoorbeeld in geval van Grub als bootloader, het configuratiebestand te downloaden van Grub, er de nodige wijzigingen in aan te brengen zodat de machine na het herstarten automatisch in de nieuwe kernel zal opstarten, en dan het gewijzigde configuratiebestand opnieuw te uploaden. Na het herstarten van de machine, zal deze dan automatisch in de nieuwe kernel opstarten.

4.5.1

Lokaal downloaden van ´ e´ en enkel bestand van een remote machine

Het lokaal downloaden van één enkel bestand is opnieuw interactief ge¨ımplementeerd. Dit zal gebeuren met volgende stappen: 1. Het programma vraagt de gebruiker naar het IP-adres van de host waarvan het bestand moet worden gedownload. 2. Het programma vraagt de gebruiker om de login in te geven voor die host. Indien de gebruiker niet op de hoogte is van deze login, moet letterlijk N/A” worden ingegeven. ”

4.5 Downloaden en uploaden van één enkel bestand van en naar een machine

62

3. Het programma vraagt vervolgens de gebruiker om het paswoord in te geven voor deze host, en opnieuw moet N/A” worden ingegeven indien de gebruiker het paswoord niet ” kent. 4. De gebruiker wordt gevraagd naar het bestand dat lokaal moet worden gedownload, waarbij het belangrijk is op te merken dat het volledige pad naar dit bestand moet worden ingegeven. Opmerking: indien de gebruiker aangeeft via N/A” dat login en paswoord niet gekend zijn, zal ” opnieuw elke combinatie van (login,paswoord) geprobeerd worden uit ./datafiles/login. Eens deze stappen zijn doorlopen, neemt het programma het over van de gebruiker. Lokaal op de controlemachine wordt een speciale doelmap aangemaakt waar het bestand moet worden gedownload. Deze map zal zijn van de vorm ./downloadFolder//, waarbij IP_host uiteraard opnieuw overeen komt met het IP-adres verschaft door de gebruiker. In deze folder zal dan het gewenste bestand gedownload worden. Indien het downloaden is geslaagd, zal er onmiddellijk een tweede folder worden aangemaakt, van de vorm ./uploadFolder//. Deze folder zal echter initieel nog leeg blijven. De bedoeling is dan dat een gebruiker de mogelijkheid zou hebben om, eens hij een bestand heeft gedownload van een host en het gewijzigd heeft, dit gewijzigde bestand in de juiste uploadfolder te kopiëren. Vervolgens kan de gebruiker de upload functie benutten om het gewijzigde bestand dan opnieuw te uploaden naar die machine. Het downloaden van dit bestand zal analoog gebeuren aan het downloaden van bestanden zoals vermeld in hoofdstuk 2 bij het analyseren van individuele hosts. Het expectscript ./expectscripts/secureCopyFiles.exp zal gebruikt worden in combinatie met het scp commando om het bestand op een veilige wijze lokaal te downloaden.

4.5.2

Uploaden van een bestand naar een remote machine

Ook de functie in het programma dat toelaat één enkel bestand te uploaden naar een remote machine, zal gebruik maken van enige interactiviteit met de gebruiker. Ook hier worden er een aantal stappen doorlopen: 1. Het programma vraagt de gebruiker eerst naar het IP-adres van de remote machine, analoog aan de functie voor het downloaden van een bestand. 2. De gebruiker wordt gevraagd naar de login gegevens. Ook hier moet N/A” worden ” opgegeven indien de gebruiker deze niet kent.

4.6 Nemen van backups van een volledige bestandsboom op een host

63

3. Vervolgens wordt gevraagd naar het paswoord, opnieuw N/A” op te geven indien niet ” gekend. 4. Vanaf dit punt treedt er verschil op met de bovenstaande downloadfunctie. Het programma zal eerst vragen naar de naam van het bestand dat moet geupload worden naar de machine. Uiteraard zal dit bestand zich nu moeten bevinden in de folder ./uploadFolder// waarbij IP_host uiteraard overeen komt met het IP opgegeven in stap 1. 5. Vervolgens wordt gevraagd naar de uploadlocatie van het bestand op de remote machine. Hierbij wordt opnieuw gevraagd het ganse pad op te geven. Opmerking: indien de gebruiker aangeeft via N/A” dat login en paswoord niet gekend zijn, zal ” opnieuw elke combinatie van (login,paswoord) geprobeerd worden uit ./datafiles/login. Hier zal het uploaden van het bestand gebeuren met het expectscript ./expectscripts/uploadFiles in combinatie met het scp-commando om op veilige wijze het bestand te uploaden naar de remote machine.

4.6

Nemen van backups van een volledige bestandsboom op een host

Een handig hulpmiddel bij het beheren van een host in een netwerk kan zijn dat men de mogelijkheid heeft om bestanden te kunnen kopiëren, eventueel zelfs volledige bestandsbomen. Bijvoorbeeld zou men op een Linux-machine de volledige directory-tree willen opslaan vanaf de root /etc. Een eerste overweging die werd gemaakt was het gebruik van rsync. Het gebruik van rsync kan echter vrij omslachtig zijn, aangezien het automatiseren van backups via rsync vraagt dat er een publieke key zal gegenereerd worden op de controlemachine, die dan moet gekopieerd worden naar de remote machine. Dit zal wel mogelijk maken dat er via SSH kan ingelogd worden zonder dat er naar een paswoord wordt gevraagd, maar vraagt meer interactie tussen de controlemachine en de remote machine. Bijgevolg is er voor het nemen van backups hier geen gebruik gemaakt van rsync, maar wel van scp met de -r”-optie. Voordelen van scp ” zijn dus: • Gebruik van de -r”-optie zal toelaten om de root van een directorytree te specifiëren, ” waarna scp recursief gans deze tree vanaf de root lokaal zal kopiëren. • SCP verschaft dezelfde veiligheid als rsync en SSH.

4.7 Uitgewerkte voorbeelden

64

• Verder laat scp toe om zowel een login als paswoord te verschaffen voor een bepaalde host, wat handig is indien login en paswoord verschillend kunnen zijn voor elke te beschouwen machine in het netwerk. Het programma laat toe dat voor een aantal hosts zal gespecifieerd worden welke directory-tree’s moeten gekopieerd worden. Dit kan gebeuren in het configuratiebestand ./datafiles/backupFilesForHosts. Een voorbeeld van de inhoud is: #END IP:192.168.0.10 login:root password:test remote directories: /root/ /etc/ #END De parameters per host worden afgebakend door de delimiter #END. Per host wordt opgegeven wat de IP is voor deze host, een login en paswoord en verder een lijst met de roots van de directory-tree’s die lokaal moeten gedownload worden. Wanneer geen login of paswoord wordt voorzien, zal opnieuw elke combinatie van (login,paswoord) worden geprobeerd zoals opgegeven in ./datafiles/login. Lokaal op de controlemachine zal een specifieke map worden aangemaakt onder vorm van .//backup/ waarin de directory tree zal worden gedownload. Eens geldige credentials zijn gevonden, zal er gebruik gemaakt worden van het commando scp met de -r” optie om de bestandstransfer te initiëren. Meer bepaald, in het geval van de inhoud van ” ./datafiles/backupFilesForHosts zoals hierboven vermeld, zal er een map aangemaakt worden van de vorm ./192.168.0.10/backup/ waarin dan de mappen etc en root zullen terug te vinden zijn, inclusief hun inhoud.

4.7

Uitgewerkte voorbeelden

Bij het beschouwen van de uitgewerkte voorbeelden kunnen we opnieuw gebruik maken van onderstaande vereenvoudigde testopstelling:


65

Figuur 4.1: Eenvoudig voorbeeld van een testnetwerk voor provisioning

4.7.1

Wijzigen van de interface-configuratie voor ´ e´ en host

Onderstaande is een voorbeeld van het bestand /etc/network/interfaces voor een machine in de beschouwde testopstelling: #This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.0.6 netmask 255.255.255.0 gateway 192.168.0.1 network 192.168.0.0 broadcast 192.168.0.255 dns-nameservers 192.168.0.1 dns-search test


66

Wat volgt is een concreet voorbeeld van de output en interactie voorzien met de gebruiker, waarbij we voor een host het IP-adres 192.168.0.6 veranderen naar 192.168.0.5: *************** *PROVISIONING:* *************** 10) Change IP of a single host. 11) Change IP of multiple hosts. Voorgaande geeft een deel van het menu weer dat we verkrijgen bij het programma. Voor het wijzigen van het IP-adres van één host kiezen we hier dus optie 10. Please specify your choice: 10 Please specify the IP address of the host of which you would like to change the IP address: 192.168.0.6 Do you know the login and password for this host? (Y/N) y Please give the login for this host: root Please give the password for this host: test When specifying the new values, you have to specify the old values that do not change again too!! Old value: address 192.168.0.6 Give the new value for address (repeat the old value if unchanged): 192.168.0.5 Old value: netmask 255.255.255.0 Give the new value for netmask (repeat the old value if unchanged): 255.255.255.0 Old value: broadcast 192.168.0.255 Give the new value for broadcast (repeat the old value if unchanged): 192.168.0.255 Old value: network 192.168.0.0 Give the new value for network (repeat the old value if unchanged): 192.168.0.0 Old value: gateway 192.168.0.1 Give the new value for gateway (repeat the old value if unchanged): 192.168.0.1


67

Wanneer we vervolgens de desbetreffende host pingen op het nieuwe IP-adres, stellen we vast dat deze ook effectief online is: Pinging 192.168.0.5 with 32 bytes of data: Reply from 192.168.0.5: bytes=32 time<1ms TTL=64 Reply from 192.168.0.5: bytes=32 time<1ms TTL=64 Reply from 192.168.0.5: bytes=32 time<1ms TTL=64 Reply from 192.168.0.5: bytes=32 time<1ms TTL=64 Ping statistics for 192.168.0.5: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

4.7.2

Voorbeeld downloaden ´ e´ en enkel bestand van een remote machine

Nu volgt een uitgewerkt voorbeeld in verband met het downloaden van één enkel bestand van een remote machine. Onderstaande is een kopie van de output van het programma bij interactie met de gebruiker: Please specify your choice: 14 Downloading a file from a host... Please specify the IP of the host you want to download from: 192.168.0.5 Please specify the login for this host, type in "N/A" (without quotes) if unknown: root Please specify the password for this host, type in "N/A" (without quotes) if unknown: test Please specify the file you want to download, it will end up in the subfolder ./downloadFolder/ with the IP of the host: Remember to specify the entire path for this file, starting from the root! etc/network/interfaces


68

We kunnen vaststellen hoe de verschillende stappen worden doorlopen zoals eerder beschreven in dit hoofdstuk: het IP-adres wordt gevraagd aan de gebruiker, login en paswoord kunnen hier wel verschaft worden door de gebruiker. Vervolgens wordt het volledige pad verschaft naar het te downloaden bestand. Dit zal aanleiding geven tot het aanmaken van de directory ./downloadFolder/192.168.0.5. Hierin zal het bestand interfaces terug te vinden zijn. Verder zal er ook een tweede subfolder worden aangemaakt met naam ./uploadFolder/192.168.0.5. Deze folder zal momenteel nog leeg zijn.

4.7.3

Voorbeeld uploaden ´ e´ en enkel bestand naar een remote machine

Veronderstel dat onderstaand voorbeeld wordt uitgevoerd na het voorgaande voorbeeld. In het voorgaande voorbeeld heeft de gebruiker het bestand ./etc/network/interfaces lokaal gedownload. Veronderstel dat de gebruiker hier enige wijzigingen heeft aan doorgevoerd en dan de gewijzigde kopie heeft geplaatst in de folder ./uploadFolder/192.168.0.5 met als naam nog altijd interfaces. De gebruiker wil dan het gewijzigde bestand opnieuw uploaden. Dit zou onderstaande interactie met het programma kunnen geven: Please specify your choice: 15 Uploading a file to a host... Please specify the IP of the host you want to upload to: 192.168.0.5 Please specify the login for this host, type in "N/A" (without quotes) if unknown: root Please specify the password for this host, type in "N/A" (without quotes) if unknown: test Please specify the file you want to upload, make sure it is in the ./uploadFolder directory: interfaces Please specify the location on the host you want to upload to: /etc/networking/


69

Het gewijzigde bestand zal dan gekopieerd worden op de remote machine naar de opgegeven locatie.

4.7.4

Installeren kernel

Dit is een voorbeeld van de interactie met de gebruiker bij het installeren van een kernel via apt: Please specify your choice: 12 Preparing to install a new kernel... Please specify the IP of the host you would like to install the kernel on: 192.168.0.5 Do you know the login and password for this host? (Y/N) Y Please specify the login of this host: root Please specify the password for this host: test Would you like to install a selfmade kernel image, or use apt? (please answer with "selfmade" or "apt") apt Please specify the name of the image to be installed: kernel-2.4-386 Hierdoor wordt op de host ingelogd en remote het commando apt-get install kernel-2.4-386 wordt uitgevoerd. Dit zal ervoor zorgen dat via apt de image kernel-2.4-386 zal ge¨ınstalleerd worden.

Een voorbeeld van een zelfgebouwde kernel image installatie is als volgt: Please specify your choice: 12 Preparing to install a new kernel... Please specify the IP of the host you would like to install the kernel on: 192.168.0.5


70

Do you know the login and password for this host? (Y/N) Y Please specify the login of this host: root Please specify the password for this host: test Would you like to install a selfmade kernel image, or use apt? (please answer with "selfmade" or "apt") selfmade Please specify the name of the image to be installed: test.deb Dit zorgt er voor dat de kernel image test.deb die zich in de folder ./kernelImages moet bevinden, zal geupload worden naar de host met IP-adres 192.168.0.5. Vervolgens wordt ingelogd op deze host en het commando dpkg -i test.deb uitgevoerd waardoor deze zelfgebouwde image ge¨ınstalleerd wordt op die host.

4.7.5

Backups nemen van bepaalde directory trees voor een host

Veronderstel dat de inhoud van het configuratiebestand ./datafiles/backupFilesForHosts als volgt is: #END IP:192.168.0.10 login:root password:test remote directories: /root/ /etc/ #END IP:192.168.0.5 login:root password:test remote directories: /root


71

/etc/network #END Dit houdt in dat eerst voor de host met IP-adres 192.168.0.10 een lokale kopie zal gemaakt worden van de volledige directory-tree’s met als root /root en /etc/. Lokaal op de controlemachine zal een folder worden aangemaakt met naam ./192.168.0.10/backup/. Hierin zullen de folders /root/ inclusief alle subdirectories en /etc/ inclusief alle subdirectories geplaatst worden. Voor de tweede host in de lijst zal dan ook een folder aangemaakt worden met naam ./192.168.0.5/backup/ met daarin uiteindelijk de folders /root/ met alle subdirectories en /etc/network met alle subdirectories.

UITBREIDINGEN

72

Hoofdstuk 5

Uitbreidingen 5.1

Inleiding

In dit hoofdstuk komen een aantal beperkingen van het ontwikkelde programma in zijn huidige vorm naar voor en worden een aantal mogelijke uitbreidingen/verbeteringen naar de toekomst toe voorgesteld.

5.2

Uitbreidingen analyse van machines

• Een uitbreiding voor het analyse gedeelte zou eventueel kunnen zijn dat er gebruik gemaakt wordt van multithreading. Dit zou het mogelijk maken dat meerdere machines in parallel kunnen geanalyseerd worden. Tot nu toe worden de hosts sequentieel geanalyseerd wanneer meer dan één host moet behandeld worden. • Meer modules kunnen toegevoegd worden voor het analyseren van output van extra remote commando’s bij het analysegedeelte. Dit kan toelaten om nog meer informatie te extraheren uit Windows- en Linux-machines.

5.3

Uitbreidingen topologiedetectie

• Bij de topologiedetectie is het programma beperkt tot Linux-machines. Meer ondersteuning voor Windows-machines zou in de toekomst kunnen toegevoegd worden. • Ook hier kan een grote performantiewinst gerealiseerd worden door het invoeren van multithreading, zodat meerdere hosts en subnetwerken parallel kunnen gedetecteerd en ge-

5.4 Uitbreidingen provisioning

73

analyseerd worden in plaats van sequentieel zoals dit nu het geval is.

5.4

Uitbreidingen provisioning

• Een uitbreiding hier zou ook kunnen zijn dat multithreading wordt ingevoerd, zodat meerdere hosts parallel kunnen behandeld worden in plaats van sequentieel. • Bij het nemen van backups worden tot nu toe ganse directory-trees met scp gekopieerd. Dit gebeurt bestand per bestand. Een andere en betere optie zou kunnen zijn, dat er ingelogd wordt op een remote machine, dat er een zip-bestand van de volledige gewenste directorytree wordt gemaakt, en dat dan dit ene bestand in één keer wordt gedownload. Dit zou een kleinere belasting van het netwerk tot gevolg hebben en een betere performantie.

5.5

Security

• Tot nu toe worden logins en paswoorden voor hosts in klare tekst bijgehouden door het programma in de configuratiebestanden. Veiliger zou zijn dat er een encryptie wordt voorzien voor alle bestanden die paswoorden en logins voor machines bevatten.

BESLUIT

74

Hoofdstuk 6

Besluit 6.1

Inleiding

Het doel van deze thesis was uiteindelijk om een programma te onwikkelen dat kon gebruikt worden in het testlab voor de vakgroep IBCN. Het moest kunnen werken in een snel wijzigende, dynamische omgeving waar op regelmatige tijdstippen testnetwerken worden afgebroken en opnieuw opgebouwd. Dit programma werd uiteindelijk ontwikkeld in drie fases. Elke fase representeert hierbij een bepaald luik van de nodige functionaliteit. Deze drie fases zijn: • Analyse van hosts in het netwerk. • Detectie van de netwerktopologie van een eigen beheerd netwerk. • Provisioning. Het grote verschil tussen dit programma en veel van de commercieel beschikbare programma’s, is dat deze laatste vooral aangewend worden in algemene netwerken, waarbij er geen logingegevens bekend zijn voor de machines in het netwerk. Soortgelijke tools zijn wel beschikbaar, maar deze zijn dan eerder vendor-specific. Zo zijn er dergelijke tools beschikbaar specifiek voor Cisco-hardware. Bedoeling was dat er een programma zou ontwikkeld worden dat de functionaliteit van de laatste categorie zou aanbieden, maar dat toch zou kunnen gebruikt worden in algemene netwerken voor algemene hardware en apparatuur. Ook zullen veel commerciële tools zich beperken tot detectie op de IP-laag, terwijl de topologiedetectie in het ontwikkelde programma zich ook toespitst op de datalink-laag. Belangrijk verschilpunt hier is dat het programma zou kunnen toegepast worden in algemene

6.2 Analyse van hosts in het netwerk

75

netwerken, maar vooral eigenbeheerde algemene netwerken. Dit houdt in dat we bij het implementeren van de noodzakelijke functionaliteit er kunnen vanuit gaan dat we voor de apparatuur in het netwerk, die credentials vereisen, hier ook over beschikken.

6.2

Analyse van hosts in het netwerk

Volgende functionaliteiten werden voorzien: • Remote uitvoeren van commando’s en lokaal opslaan van de output, dit voor zowel Linuxals Windows-machines, en dit voor zowel een enkele host als meerdere hosts sequentieel. • Het opbouwen van een rapport voor elk van de geanalyseerde hosts, dit onder XML formaat, en gebruik maken van XSLT-stylesheets om een tekstueel rapport te bekomen. • Het lokaal downloaden van bestanden van een remote host en tegelijkertijd van deze bestanden een hash code opbouwen, zodat achteraf kan gecontroleerd worden of deze bestanden zijn gewijzigd.

6.3

Detectie van de netwerktopologie van een eigen beheerd netwerk

Het detecteren van de topologie van een netwerk en het grafisch weergeven van deze topologie is ook een functionaliteit ingebouwd in het programma. Ook een tekstuele beschrijving van de gevonden connecties op laag 2 wordt geproduceerd na de topologie detectie zodat achteraf het netwerk kan herbouwd worden.

6.4

Provisioning

Volgende functionaliteiten zijn aanwezig: • Het instellen van IP-adressen, zowel voor enkelvoudige hosts als meerdere hosts na mekaar. • De mogelijkheid tot het uploaden naar en downloaden van enkelvoudige bestanden van en naar een bepaalde host. Dit laat bijvoorbeeld toe om snel op een host een configuratiebestand te wijzigen. • Installeren van een kernel image, op enkelvoudige hosts en meerdere hosts tegelijk.

6.5 Uitbreidbaarheid

76

• Het kopiëren van volledige bestandsbomen van hosts naar de controlemachine.

6.5

Uitbreidbaarheid

Bij het ontwikkelen van het programma is er zoveel mogelijk gestreefd naar uitbreidbaarheid van het programma. Zo kan het analysegedeelte verder uitgebreid worden door modules in het hoofdprogramma in te pluggen met behulp van het pipelining mechanisme. Ook de topologiedetectie kan uitgebreid worden met extra toolboxes voor het behandelen van andere switches dan alleen de switches die tot nu toe voorzien zijn. Ook kan bij het provisioninggedeelte achteraf verdere functionaliteit worden toegevoegd.

6.6

Bijlages

In de bijlages van dit eindwerk zijn tenslotte nog een aantal interessante appendixes voorzien. Zo vinden we hier terug: • Appendix A: bevat UML-diagrammen die de verschillende klassen en verbanden tussen die klassen van het programma meer verduidelijken. • Appendix B: hierin vinden we de XSLT-stylesheets terug die gebruikt worden in het programma ter referentie. • Appendix C: deze bevat een aantal screenshots en output-files van de uitgewerkte voorbeelden waarnaar in de hoofdstukken van dit eindwerk zelf wordt verwezen.

UML DIAGRAMMEN

77

Bijlage A

UML diagrammen

Figuur A.1: ArpContentObject

Figuur A.2: ArpSwitchCouplingObject

UML DIAGRAMMEN

78

Figuur A.3: Host

UML DIAGRAMMEN

79

Figuur A.4: HostConnection

Figuur A.5: Interface

UML DIAGRAMMEN

80

Figuur A.6: IpChangeObject

Figuur A.7: IplistObject

UML DIAGRAMMEN

81

Figuur A.8: LoginDataObject

Figuur A.9: PreliminarySubnetObject

Figuur A.10: ProvisioningEngine

UML DIAGRAMMEN

82

Figuur A.11: ProvisioningToolBox

Figuur A.12: Subnet

UML DIAGRAMMEN

83

Figuur A.13: SystemAnalysis

UML DIAGRAMMEN

84

Figuur A.14: ToolBox

UML DIAGRAMMEN

85

Figuur A.15: TopologyMappingEngine

UML DIAGRAMMEN

86

Figuur A.16: TopologyMappingToolBox

UML DIAGRAMMEN

87

Figuur A.17: Analyse-UML

Figuur A.18: Topology-UML

UML DIAGRAMMEN

88

Figuur A.19: Provisioning-UML

XSLT-STYLESHEETS

89

Bijlage B

XSLT-Stylesheets B.1

XSLT stylesheet voor host analyse

Report

<xsl:if test="Report/OS_Version"> * The version of this OS is <xsl:value-of select="Report/OS_Version"/>.
<xsl:if test="Report/OS_Name"> * The OS-Name is <xsl:value-of select="Report/OS_Name"/>.
<xsl:if test="Report/Host_Name"> * The host name is <xsl:value-of select="Report/Host_Name"/>.
<xsl:if test="Report/OS_Build_Type"> * The build type of the OS is <xsl:value-of select="Report/OS_Build_Type"/>.
<xsl:if test="Report/Registered_Owner"> * The registered owner is <xsl:value-of select="Report/Registered_Owner"/>.
<xsl:if test="Report/Registered_Organization"> * The registered organisation is <xsl:value-of select="Report/Registered_Organization"/>.
<xsl:if test="Report/BIOS_Version"> * The Bios version is <xsl:value-of select="Report/BIOS_Version"/>.

B.1 XSLT stylesheet voor host analyse

<xsl:if test="Report/Product_ID"> * The product ID is <xsl:value-of select="Report/Product_ID"/>.
<xsl:if test="Report/System_Model"> * The system type is <xsl:value-of select="Report/System_Model"/>.
<xsl:if test="Report/System_type"> * The system model is <xsl:value-of select="Report/System_type"/>.
<xsl:if test="Report/System_Up_Time"> * The system up time is <xsl:value-of select="Report/System_Up_Time"/>.
<xsl:if test="Report/Original_Install_Date"> * The original install date is <xsl:value-of select="Report/Original_Install_Date"/>.
<xsl:if test="Report/System_Locale"> * The system locale is <xsl:value-of select="Report/System_Locale"/>.
<xsl:if test="Report/Input_Locale"> * The input locale is <xsl:value-of select="Report/Input_Locale"/>.
<xsl:if test="Report/Kernel"> * The kernel of this system is <xsl:value-of select="Report/Kernel"/>.
<xsl:if test="Report/OS"> * The OS of this system is <xsl:value-of select="Report/OS"/>.
<xsl:if test="Report/Architecture"> * The Architecture of this system is <xsl:value-of select="Report/Architecture"/>.
<xsl:if test="Report/HostName"> * The hostname of this system is <xsl:value-of select="Report/HostName"/>.

<xsl:if test="Report/CPU_INFO">
CPU information:
<xsl:if test="Report/CPU_INFO/VENDOR"> * The CPU vendor is: <xsl:value-of select="Report/CPU_INFO/VENDOR"/>.
<xsl:if test="Report/CPU_INFO/FAMILY"> * The family of this CPU: <xsl:value-of select="Report/CPU_INFO/FAMILY"/>.

90


<xsl:if test="Report/CPU_INFO/NAME"> * The model name: <xsl:value-of select="Report/CPU_INFO/NAME"/>.
<xsl:if test="Report/CPU_INFO/MODEL"> * The CPU model: <xsl:value-of select="Report/CPU_INFO/MODEL"/>.
<xsl:if test="Report/CPU_INFO/STEPPING"> * Stepping: <xsl:value-of select="Report/CPU_INFO/STEPPING"/>.
<xsl:if test="Report/CPU_INFO/MHZ"> * Mhz: <xsl:value-of select="Report/CPU_INFO/MHZ"/>.
<xsl:if test="Report/CPU_INFO/CACHESIZE"> * Size of the cache is: <xsl:value-of select="Report/CPU_INFO/CACHESIZE"/>.
<xsl:if test="Report/CPU_INFO/CPUIDLEVEL"> * CPUID level is: <xsl:value-of select="Report/CPU_INFO/CPUIDLEVEL"/>.
<xsl:if test="Report/CPU_INFO/BOGOMIPS"> * Bogomips for this CPU: <xsl:value-of select="Report/CPU_INFO/BOGOMIPS"/>.

<xsl:if test="Report/MEMORY_INFO">
Memory information:
<xsl:if test="Report/MEMORY_INFO/MEMTOTAL"> * Total amount of memory (kB): <xsl:value-of select="Report/MEMORY_INFO/MEMTOTAL"/>.
<xsl:if test="Report/MEMORY_INFO/MEMFREE"> * Amount of memory free (kB): <xsl:value-of select="Report/MEMORY_INFO/MEMFREE"/>.
<xsl:if test="Report/MEMORY_INFO/BUFFERS"> * Buffers (kB): <xsl:value-of select="Report/MEMORY_INFO/BUFFERS"/>.
<xsl:if test="Report/MEMORY_INFO/CACHED"> * Cached (kB): <xsl:value-of select="Report/MEMORY_INFO/CACHED"/>.

91


<xsl:if test="Report/MEMORY_INFO/SWAPCACHED"> * Swap cached (kB): <xsl:value-of select="Report/MEMORY_INFO/SWAPCACHED"/>.
<xsl:if test="Report/MEMORY_INFO/ACTIVE"> * Active (kB): <xsl:value-of select="Report/MEMORY_INFO/ACTIVE"/>.
<xsl:if test="Report/MEMORY_INFO/INACTIVE"> * Inactive (kB): <xsl:value-of select="Report/MEMORY_INFO/INACTIVE"/>.
<xsl:if test="Report/MEMORY_INFO/HIGHTOTAL"> * Hightotal (kB): <xsl:value-of select="Report/MEMORY_INFO/HIGHTOTAL"/>.
<xsl:if test="Report/MEMORY_INFO/HIGHFREE"> * Highfree (kB): <xsl:value-of select="Report/MEMORY_INFO/HIGHFREE"/>.
<xsl:if test="Report/MEMORY_INFO/LOWTOTAL"> * Lowtotal (kB): <xsl:value-of select="Report/MEMORY_INFO/LOWTOTAL"/>.
<xsl:if test="Report/MEMORY_INFO/LOWFREE"> * Lowfree (kB): <xsl:value-of select="Report/MEMORY_INFO/LOWFREE"/>.
<xsl:if test="Report/MEMORY_INFO/SWAPTOTAL"> * Swaptotal (kB): <xsl:value-of select="Report/MEMORY_INFO/SWAPTOTAL"/>.
<xsl:if test="Report/MEMORY_INFO/SWAPFREE"> * Swapfree (kB): <xsl:value-of select="Report/MEMORY_INFO/SWAPFREE"/>.
<xsl:if test="Report/MEMORY_INFO/PAGETABLES"> * Pagetables (kB): <xsl:value-of select="Report/MEMORY_INFO/PAGETABLES"/>.

<xsl:if test="Report/Routing_Table/Interface_List/Interface">
Interfaces

92


<xsl:for-each select="Report/Routing_Table/Interface_List/Interface">

ID Mac-address Name

<xsl:value-of select="ID"/> <xsl:value-of select="Mac_address"/> <xsl:value-of select="Name"/>

<xsl:if test="Report/Routing_Table/Active_Routes/Route">
Routing Table

Active Routes
<xsl:for-each select="Report/Routing_Table/Active_Routes/Route">

NetworkDestination Gateway Interface Metric
<xsl:value-of select="@NetworkDestination"/> <xsl:value-of select="@Gateway"/> <xsl:value-of select="@Interface"/> <xsl:value-of select="@Metric"/>

<xsl:if test="Report/CurrentConnections/Connection">
Current Connections
<xsl:for-each select="Report/CurrentConnections/Connection">

93


Protocol Local address Foreign Address State
<xsl:value-of select="@Proto"/> <xsl:value-of select="@Local_Address"/> <xsl:value-of select="@Foreign_Address"/> <xsl:value-of select="@State"/>

<xsl:if test="Report/RunningProcesses/Process">
Running Processes
<xsl:for-each select="Report/RunningProcesses/Process">

User Pid CPU% MEM% VSZ RSS TTY Stat Start Time Command
<xsl:value-of select="@USER"/> <xsl:value-of select="@PID"/> <xsl:value-of select="@PercentageCPU"/> <xsl:value-of select="@PercentageMEM"/> <xsl:value-of select="@VSZ"/> <xsl:value-of select="@RSS"/> <xsl:value-of select="@TTY"/> <xsl:value-of select="@STAT"/> <xsl:value-of select="@START"/> <xsl:value-of select="@TIME"/> <xsl:value-of select="@COMMAND"/>

<xsl:if test="Report/Sockets-Connections/Active_Unix_Sockets">
Active Unix Sockets

94


95

<xsl:for-each select="Report/Sockets-Connections/Active_Unix_Sockets/Socket">

Protocol RefCnt Flags Type State I-Node Path
<xsl:value-of select="@Proto"/> <xsl:value-of select="@RefCnt"/> <xsl:value-of select="@Flags"/> <xsl:value-of select="@Type"/> <xsl:value-of select="@State"/> <xsl:value-of select="@I-Node"/> <xsl:value-of select="@Path"/>

B.2 XSLT stylesheet voor topologie representatie

B.2

96

XSLT stylesheet voor topologie representatie

Found connections
<xsl:for-each select="TOPOLOGY/SWITCH">

Connections found for switch with IP: <xsl:value-of select="SWITCH-IP"/>
<xsl:if test="VERIFIED-CONNECTIONS">
Verified connections found for this switch:
<xsl:for-each select="VERIFIED-CONNECTIONS/CONNECTION"> *A connection was found for this switch from port <xsl:value-of select="SWITCH-PORT"/> with NIC <xsl:value-of select="INTERFACE-NAME"/> with IP <xsl:value-of select="INTERFACE-IP"/>.
<xsl:if test="NON-VERIFIED-CONNECTIONS">
Non-Verified connections found for this switch:
<xsl:for-each select="NON-VERIFIED-CONNECTIONS/CONNECTION"> *A connection was found for this switch that could not be verified from port <xsl:value-of select="SWITCH-PORT"/> with MAC-address: <xsl:value-of select="UNVERIFIED-MAC"/>.

SCREENSHOTS

97

Bijlage C

Screenshots C.1 C.1.1

Analyse uitgewerkte voorbeelden Gedeeltelijke XML inhoud v/h rapport aangemaakt voor host met IP 192.168.0.5

2.6.8-3-386 #1 Thu Feb 9 07:17:13 UTC 2006 Linux debian i686 GNU/Linux 192.168.0.0 0.0.0.0 255.255.255.0 U <Metric>0 0 <Use>0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG <Metric>0 0 <Use>0 eth0 <MEMORY_INFO> <MEMTOTAL> 321924 kB

C.1 Analyse uitgewerkte voorbeelden

<MEMFREE> 208744 kB 9444 kB 58216 kB 0 kB 57868 kB 39496 kB 0 kB 0 kB 321924 kB 208744 kB <SWAPTOTAL> 1951888 kB <SWAPFREE> 1951888 kB 828 kB GenuineIntel 6 <MODEL> 7 Pentium III (Katmai) <STEPPING> 3 <MHZ> 451.071 512 KB 2 890.88

98

C.2 Topologie detectie uitgewerkte voorbeelden

99

C.1.2

Corresponderende weergave in een browser met behulp van XSLT stylesheet

Figuur C.1: Weergave in browser met XSLT stylesheet

C.2 C.2.1

Topologie detectie uitgewerkte voorbeelden Inhoud van analysis.list voor het beschouwde testnetwerk

10.10.3.170:LINUX:root:ruggent 10.0.1.100:LINUX:root:ruggent 10.10.3.172:wodclerc:ruggent 10.10.3.171:LINUX 10.0.1.101:LINUX

C.2.2

Gedeeltelijke inhoud van TopologyDescription.xml voor het beschouwde testnetwerk

<SWITCH>


<SWITCH-IP>10.10.3.172 <SWITCH-PORT>1 eth0 10.10.3.171 <SWITCH-PORT>4 eth1 10.0.1.100 <SWITCH-PORT>2 eth1 10.0.1.101 <SWITCH-PORT>1 00-03-2D-03-DB-69 <SWITCH-PORT>1 00-04-76-9D-03-DE <SWITCH-PORT>1 00-04-76-9D-03-F2 <SWITCH-PORT>1 00-05-5D-33-CB-71 <SWITCH-PORT>1 00-05-5D-D3-9C-55 <SWITCH-PORT>1 00-05-5D-D3-9C-63 <SWITCH-PORT>1 00-50-BA-CA-29-A9

100


101

<SWITCH-PORT>1 00-50-BA-CA-2B-8C <SWITCH-PORT>1 00-50-BA-CA-2C-AE <SWITCH-PORT>1 00-D0-95-D5-C5-0C

C.2.3

Weergave van TopologyDescription.xml met een XSLT stylesheet in een browser

Figuur C.2: Weergave in browser met XSLT stylesheet

C.2.4

Inhoud van output-gui-topology.xml voor de GUI

C.2.5

Weergave van output-gui-topology.xml in de GUI zelf

102


Figuur C.3: Weergave topologie in GUI

103

BIBLIOGRAFIE

104

Bibliografie [1] http://expect.nist.gov/ [2] http://www.debian.org/ [3] http://www.insecure.org/nmap/ [4] http://www.lookatlan.com/ [5] James F. Kurose, Keith W. Ross, “Computernetwerken: een ’top-down’-benadering”, Pearson Addison Wesley, 2003. [6] Bruce Eckel, Thinking in C++ 2nd Edition, Prentice Hall, 2000. [7] Glazemakers Kurt, Studie van algoritmen en technieken voor netwerktopologie detectie, thesis, Universiteit Gent, 1999-2000. [8] Volckaert Bruno, Automatische generatie van grafische gebruikersinterfaces voor netwerkbeheer, thesis, Universiteit Gent, 2000-2001.

Automatische device discovery in IP-netwerken

Recommend Documents

Report

Interfaces

Report

CPU information:

Memory information:

Interfaces

Routing Table

Active Routes

Current Connections

Running Processes

Active Unix Sockets

Found connections

Connections found for switch with IP: <xsl:value-of select="SWITCH-IP"/>

Verified connections found for this switch:

Non-Verified connections found for this switch: