ΑΤΕΙ ΘΕΣΣΑΛΙΑΣ ΣΧΟΛΗ ΤΕΧΝΟΛΟΓΙΚΩΝ ΕΦΑΡΜΟΓΩΝ. Τμήμα Μηχανικών Πληροφορικής ΤΕ

Transcript

1 ΑΤΕΙ ΘΕΣΣΑΛΙΑΣ ΣΧΟΛΗ ΤΕΧΝΟΛΟΓΙΚΩΝ ΕΦΑΡΜΟΓΩΝ Τμήμα Μηχανικών Πληροφορικής ΤΕ

2 Διαχείριση Δικτύων: Πρωτόκολλα και Εφαρμογές ΠΤΥΧΙΑΚΗ ΕΡΓΑΣΙΑ Τσόλκας Φώτης (ΑΜ: T854) Επιβλέπων: Τσουκάτος Κων/νος ΛΑΡΙΣΑ 2014

3 «Δηλώνω υπεύθυνα ότι το παρόν κείμενο αποτελεί προϊόν προσωπικής μελέτης και εργασίας και πως όλες οι πηγές που χρησιμοποιήθηκαν για τη συγγραφή της δηλώνονται σαφώς. Γνωρίζω πως η λογοκλοπή αποτελεί σοβαρότατο παράπτωμα και είμαι ενήμερος για την επέλευση των νομίμων συνεπειών» Τσόλκας Φώτης υπογραφή -3-

4 Εγκρίθηκε από την τριμελή εξεταστική επιτροπή Τόπος: Ημερομηνία: ΕΠΙΤΡΟΠΗ ΑΞΙΟΛΟΓΗΣΗΣ

5 Περίληψη Με την ακόλουθη πτυχιακή θα ασχοληθούμε με τα πρωτόκολλα διαχείρησης δικτύων καθώς και που εφαρμόζονται αυτά. Από τη στιγμή που θα δημιουργήσουμε ένα δίκτυο επιβάλλεται να μπορούμε να διαχειριζόμαστε,να παρακολούθουμε αλλα και να εξασφαλίσουμε γενικά την ομαλή του λειτουργία. Φυσικά απο τα πρώτα πράγματα που θα αναλύσουμε είναι το ICMP και το SNMP πρωτόκολλο. Το ICMP στην ουσία είναι ο πυρήνας της σουίτας IP. Το SNMP από την άλλη είναι πιό πολύπλοκο απο το SNMP και χρησιμοποιείται από πολλές συσκευές. Στη συνέχεια θα ασχοληθούμε με κάποια εργαλεία διαχείρησης δικτύων σε περιβάλλον Windows. Πιο συγκεκριμένα με το RPC και το WMI. Τέλος θα μιλήσουμε και για το αρκετά γνωστό Telnet που αν και ξεκίνησε για Unix-based λειτουργικά στη συνέχεια επεκτάθηκε η χρήση του και σε άλλα. Επίσης για τον διάδοχο του Telnet,το Secure Shell. Απο τη μεριά του χρήστη το SSH είναι φαινομενικά το ίδιο με το Telnet. Η σημαντική διαφορά του όμως με το Telnet είναι η ασφάλεια σύνδεσης που παρέχει από άκρη σε άκρη. -5-

6 Περιεχόμενα 1ΕΙΣΑΓΩΓΗ ΔΙΑΧΕIΡΙΣΗ ΔΙΚΤYΟΥ ΚΑΙ ΠΡΩΤOΚΟΛΛΑ ΔΙΑΧΕIΡΙΣΗ ΔΙΚΤΎΟΥ ΑΡΧΙΤΕΚΤΟΝΙΚH ΔΙΑΧΕIΡΙΣΗΣ ΔΙΚΤYΟΥ Εξυπηρετητής Διαχείρισης Δικτύου Πράκτορες Διαχείρισης Δικτύου Βάση Πληροφοριών Διαχείρισης Πρωτόκολλο Διαχείρισης Δικτύου ΕIΔΗ ΠΡΩΤΟΚOΛΛΩΝ ΠΡΩΤOΚΟΛΛΑ ΔΙΑΧΕIΡΙΣΗΣ ΔΙΚΤYΩΝ ICMP ΓΕΝΙΚA ΤΕΧΝΙΚEΣ ΛΕΙΤΟΥΡΓIΕΣ ΔΟΜH ΠΑΚEΤΟΥ ICMP ICMP ΜΗΝYΜΑΤΑ ΛIΣΤΑ ΜΗΝΥΜAΤΩΝ ΕΛEΓΧΟΥ ICMP ΜΗΝYΜΑΤΑ ΣΦAΛΜΑΤΟΣ Απρόσιτος Προορισμός (Destination unreachable) Σιγή Πηγής (Source quench) Αναδρομολόγηση (Redirect) Λήξη χρόνου (Time exceeded) ΜΗΝYΜΑΤΑ ΑIΤΗΣΗΣ /ΑΠAΝΤΗΣΗΣ Η εντολή ping

7 3.7.2Μηνύματα αίτησης / απάντησης χρονικής σφραγίδας (Timestamp request / replay) Μηνύματα αίτησης / απάντησης μάσκας δικτύου (Address mask request / replay) SNMP ΓΕΝΙΚA ΣYΝΟΨΗ ΚΑΙ ΒΑΣΙΚΟI OΡΟΙ SNMP MIB & NMS SNMP-Compliant MIB Δομή πληροφοριών της MIB Αναγνωριστικά αντικειμένων MIB SNMP NMS ΤΕΧΝΙΚEΣ ΛΕΙΤΟΥΡΓIΕΣ ΔΟΜH ΚΑΙ ΕΚΔOΣΕΙΣ ΤΟΥ SNMP SNMPv SNMPv SNMPv SNMP ΚΑΙ ΑΣΦAΛΕΙΑ ΤΑ ΠΡΩΤOΚΟΛΛΑ ΔΙΑΧΕIΡΙΣΗΣ ΤΩΝ WINDOWS ΓΕΝΙΚA RPC Το MSRPC Αρχιτεκτονική δομή του MSRPC Διεργασία MSRPC Δομή μηνυμάτων RPC Ρύθμιση "RPC over HTTP" για επικοινωνία DCOM MSRPC και ασφάλεια WMI Αρχιτεκτονική δομή του WMI...71

8 5.3.2Συνεχόμενη Παρακολούθηση Συμβάντων (Monitoring Events) Απομακρυσμένο WMI και DCOM Σύγκριση SNMP και WMI ΠΡΩΤΟΚΟΛΛΑ ΒΑΣΙΣΜEΝΑ ΣΤΟ UNIX ΓΕΝΙΚA TELNET Περιγραφή πρωτοκόλλου Η λειτουργία του telnet Telnet και ασφάλεια SSH Περιγραφή πρωτοκόλλου Δημιουργία SSH σύνδεσης Πιστοποίηση SSH client Ασφάλεια SSH

9 1 Εισαγωγή Η διαχείριση δικτύων υφίσταται από την πρώτη στιγμή που δημιουργήθηκε δίκτυο. Κάθε φορά που δύο ή περισσότεροι υπολογιστές συνδέονται μεταξύ τους υπάρχει ανάγκη για διαχέιριση, συνεχή παρακολούθηση και ανάλυση της επικοινωνίας τους. Για το λόγο αυτό με το πέρασμα του χρόνου δημιουργήθηκε μια σειρά από πρωτόκολλα διαχείρισης που βοηθούν στην κατανόηση της επικοινωνίας ανάμεσα στις δικτυακές συσκευές. Αυτά τα εξειδικευμένα πρωτόκολλα είναι απαραίτητα λόγω της φύσης της δικτυακής επικοινωνίας. Κανένας δεν μπορεί να δει τα bits και bytes να διατρέχουν τα καλώδια του κέντρου δεδομένων. Επομένως ο μοναδικός τρόπος για την κατανόηση της συμπεριφοράς ενός δικτύου είναι η στήριξη στα δεδομένα που αντλούνται μέσω αυτών των πρωτοκόλλων. Σήμερα υπάρχουν αναρίθμητα πρωτόκολλα που υποστηρίζουν την ορθή λειτουργία ενός δικτύου. Τα πιο γνωστά είναι τα Transmission Control Protocol (TCP) και User Datagram Protocol (UDP) που υποστηρίζουν ένα Local Area Network (LAN), όμως τα περισσότερα δίκτυα απαιτούν και πρωτόκολλα που είναι λιγότερο γνωστά (για παράδειγμα AppleTalk και IPX) όπως επίσης και πρωτόκολλα που χρησιμοποιούνται για εξωτερική δρομολόγηση (για παράδειγμα BGP και EIGRP). Αξιοσημείωτη είναι η διαφορά στον τρόπο λειτουργίας των πρωτοκόλλων διαχείρισης δικτύου από τα πρωτόκολλα μεταφοράς δεδομένων. Παρόλα αυτά, ένα πρωτόκολλο εφαρμογής πρόσβασης και μεταφοράς δεδομένων λειτουργεί παράλληλα με αυτά που χρησιμοποιούνται για τη διαχείριση του δικτύου. Σκοπός της πτυχιακής αυτής εργασίας είναι η κατανόηση και η επιτυχημένη εφαρμογή τέτοιων ιδιαίτερων πρωτόκολλων διαχείρισης δικτύων. Με κέντρο τα πολύ απλά πρωτόκολλα Internet Control Message Protocol (ICMP) και Simple Network Management Protocol (SNMP), η πτυχιακή αυτή θα κινηθεί στην περιγραφή και ανάλυση άλλων πρωτοκόλλων που χρησιμοποιούνται στη διαχείριση δικτύων. -9-

10 1 Διαχείριση Δικτύου και Πρωτόκολλα Στις μέρες μας ένα δίκτυο αποτελείται από ένα σύστημα διαφορετικών συσκευών, πολλές φορές με διαφορετικά χαρακτηριστικά η κάθε μία, που συνδέονται μέσω hardware και software πηγών. Οι πηγές αυτές περιέχουν τόσο φυσικές συσκευές όπως routers, bridges, hosts, terminal servers, modems, links, interfaces, όσο και πρωτόκολλα διαχείρισης που ελέγχουν και βοηθούν στην κατανόηση της επικοινωνίας μεταξύ των συσκευών που διαμορφώνουν ένα δίκτυο. Στο κεφάλαιο αυτό θα γίνει μια σύντομη αναφορά στην διαχείριση δικτύου καθώς και στα πρωτόκολλα που την καθορίζουν. 1.1 Διαχείριση δικτύου Όταν γίνεται λόγος για διαχείριση δικτύου (Network Management), ουσιαστικά γίνεται αναφορά στις διεργασίες, μεθόδους, δραστηριότητες και εργαλεία που σχετίζονται με την λειτουργία, διαχείριση, συντήρηση και πρόβλεψη των δικτυακών συστημάτων. Επειδή οι όροι αυτοί είναι σημαντικοί στην κατανόηση της έννοιας Διαχείριση Δικτύου, θα αναλυθούν ευθύς αμέσως: Λειτουργία (Operation): Περιλαμβάνει την διατήρηση τόσο του δικτύου όσο και των υπηρεσιών του σε κατάσταση που δεν θα παρουσιάζει προβλήματα. Επίσης, περιλαμβάνει την συνεχή παρακολούθηση του δικτύου σε σημείο που αν προκύψει ένα πρόβλημα, αυτό να εντοπιστεί όσο το δυνατόν γρηγορότερα, πριν το καταλάβει ο χρήστης του δικτύου Διαχείριση (Administration): Περιλαμβάνει τον έλεγχο των πόρων ενός δικτύου καθώς και με τον συσχετισμό τους. Ουσιαστικά ασχολείται με οτιδήποτε αφορά το δίκτυο για να αποτρέψει την πτώση της απόδοσής του ή την αδυναμία λειτουργίας του Συντήρηση (Maintenance): Περιλαμβάνει την επισκευή και την αναβάθμιση του δικτύου καθώς και την λήψη διορθωτικών μέτρων και μέτρων αποφυγής σφαλμάτων που είναι απαραίτητα για την λειτουργία του δικτύου με όσο το δυνατόν καλύτερη απόδοση Πρόβλεψη (Provisioning): Περιλαμβάνει την ρύθμιση των παραμέτρων ενός δικτύου για μεγαλύτερη και καλύτερη υποστήριξη των υπηρεσιών του. -10-

11 1.2 Αρχιτεκτονική Διαχείρισης Δικτύου Όπως αναφέρθηκε στην εισαγωγή του κεφαλαίου, τα πρωτόκολλα διαχείρισης δικτύου ελέγχουν και βοηθούν στην κατανόηση της επικοινωνίας μεταξύ των συσκευών που διαμορφώνουν ένα δίκτυο.για το λόγο αυτό κάθε πρωτόκολλο έχει την δική του αρχιτεκτονική που ουσιαστικά ακολουθεί το γενικό ή βασικό μοντέλο της αρχιτεκτονικής του δικτύου. Ένα τέτοιο μοντέλο είναι σχεδιασμένο ως εξής: Σταθμός Διαχείρισης (Management station) Πράκτορας Διαχείρισης (Management agent) Βάση Πληροφοριών Διαχείρισης (Management information base) Πρωτόκολλο Διαχείρισης Δικτύου (Network management protocol) Η αρχιτεκτονική αυτή απεικονίζεται στην εικόνα 1. Εικόνα 1: Αρχιτεκτονική διαχείριση δικτύου Εξυπηρετητής Διαχείρισης Δικτύου Ο εξυπηρετητής διαχείρισης δικτύου (Network Management Server - NMS) χρησιμοποιείται για τη διαχείριση και επίβλεψη ολόκληρου του δικτύου, μέσω συλλογής πληροφοριών που λαμβάνει, επεξεργάζεται και απεικονίζει. Οι πιο κοινές πλατφόρμες NMS platforms είναι οι εξής: Hewlett-Packard OpenViewTM, Cabletron SPECTRUM, SunNet Manager, IBM NetView, Harris Corporation FarScan και Alcatel MCS

12 Οι πλατφόρμες των HP, Cabletron και Sun είναι διαχειριστές SNMP και μπορούν να λειτουργήσουν με κάθε συσκευή που υποστηρίζει SNMP. Ο HP OpenView μάλιστα, λόγω των πλεονεκτημάτων του, είναι από τους πιο διαδεδομένους και θεωρείται ως de facto standard για πλατφόρμες διαχείρισης. Οι πλατφόρμες της Harris και της Alcatel είναι λύσεις που δεν υποστηρίζουν τα standards της open source αγοράς και δεν μπορούν να συνδυαστούν με καμία άλλη συσκευή δικτύου πέρα των δικών τους προϊόντων. Μια τέτοια περίπτωση, που είναι αρκετά συνηθισμένη, δημιουργεί προβλήματα στους διαχειριστές δικτύων επειδή το δίκτυο μπορεί να περιλαμβάνει εξοπλισμό από πολλούς παρόχους που να μην είναι συμβατοί με τις πλατφόρμες αυτές. Τέτοιες συσκευές δεν μπορούν να διαχειριστούν από το σύστημα διαχείρισης και οι διαχειριστές ουσιαστικά δεν μπορούν να "δουν" ούτε την λειτουργία τους ούτε την απόδοσή τους Πράκτορες Διαχείρισης Δικτύου Οι πράκτορες διαχείρισης δικτύου (Network Management Agent - NMA) ονομάζονται απλά και ως πράκτορες (agents). Αποτελούν το δεύτερο ενεργό στοιχείο στην αρχιτεκτονική διαχείρισης. Οι agents είναι λογισμικά των συσκευών του δικτύου που εξυπηρετούν τις αιτήσεις πληροφοριών που λαμβάνουν από τον NMS. Δυστυχώς, οι agents, στέλνουν στον NMS και αυθαίρετες πληροφορίες μαζί με τις επιθυμητές, γνωστές ως παγίδες (traps). Τέτοιου είδους προγράμματα είναι άρρητα συνδεδεμένα με την εσωτερική λειτουργία των συσκευών. Όλες οι συσκευές που είναι συνδεδεμένες σε ένα δίκτυο πρέπει να περιέχουν πράκτορα διαχείρισης. Τυπικά, ένας agent μπορεί να είναι ενσωματωμένος στη συσκευή, ή εναλλακτικά μπορεί να λειτουργεί ως proxy agent Βάση Πληροφοριών Διαχείρισης Το τρίτο κομμάτι της αρχιτεκτονικής αποτελούν οι πληροφορίες που μεταφέρονται μεταξύ του NMS και του NMA. Οι πληροφορίες αυτές αποτελούν την βάση πληροφοριών διαχείρισης (Management Information Base MIB). Ουσιαστικά είναι μια συλλογή από αντικείμενα (objects) ή τιμές δεδομένων, που αντιπροσωπεύουν την εκάστοτε συνδεδεμένη στο δίκτυο συσκευή. Παραδείγματα τέτοιων πληροφοριών της MIB μπορεί να είναι το μέρος που είναι συνδεδεμένη η συσκευή ή ο αριθμός των σφαλμάτων της σε κάποιο χρονικό διάστημα. -12-

13 Η δομή και το περιεχόμενο της MIB είναι καθορισμένα για την κάθε ιδιαίτερη κατηγορία της. Από τη στιγμή που θα δημιουργηθεί μια MIB και θα δημοσιευθεί ως standard, οι πάροχοι μπορούν να κατασκευάσουν εξοπλισμό που να συμμορφώνεται με το standard αυτό, εξασφαλίζοντας με τον τρόπο αυτό την διαχείριση των συσκευών τους σε ένα δίκτυο TCP/IP Πρωτόκολλο Διαχείρισης Δικτύου Το πρωτόκολλο διαχείρισης δικτύου χρησιμοποιείται για την μεταφορά της πληροφορίας διαχείρισης μεταξύ agents και NMS καθορίζοντας ταυτόχρονα τους κανόνες της επικοινωνίας αυτής. Το πρωτόκολλο επίσης επιτρέπει την μεταφορά ερωτημάτων για την κατάσταση των συσκευών που είναι συνδεδεμένες στο δίκτυο και έμμεσα σηματοδοτεί την έναρξη των ενεργειών που απαιτούνται να γίνουν στις συσκευές μέσω των agent. Οι πράκτορες με τη σειρά τους μπορούν να κάνουν χρήση του πρωτοκόλλου διαχείρισης για να δώσουν πληροφορίες σχετικά με σημαντικά θέματα των συσκευών, όπως για παράδειγμα η παρουσίαση βλάβης ή το ξεπέρασμα των ορίων απόδοσής τους. 1.3 Είδη πρωτοκόλλων Χωρίς την παρουσία των πρωτοκόλλων η επικοινωνία μεταξύ των συσκευών ενός δικτύου θα ήταν πολύ δύσκολη στην πραγματοποίηση. Για τον λόγο αυτό και για την αποφυγή δημιουργίας περαιτέρω προβλημάτων οι διάφοροι φορείς δημιουργούν πρωτόκολλα με τυπικό καθορισμό λειτουργίας τους και των χαρακτηριστικών τους. Ένα πρωτόκολλο συνήθως δημιουργείται με ένα από τους παρακάτω τρόπους: 1. Defacto Standard: Από μια εταιρεία δημιουργεί ένα πρωτόκολλο που υιοθετείται από άλλους κατασκευαστές. Παράδειγμα τέτοιας δημιουργίας πρωτοτύπου είναι η αρχιτεκτονική SNA (System Network Architecture) της IBM και το πρωτόκολλο data communication BiSync. 2. Ένωση Βιομηχανιών: Από μια ομάδα εταιριών αποφασίζει από κοινού στη δημιουργία ενός διαλειτουργικού πρωτοκόλλου που δεν απορροφάται από κανένα από τα επίσημα πρότυπα και μπορεί να είναι επιλεκτικό σχετικά με την συμμετοχή τους. Παραδείγματα τέτοιων ομάδων είναι οι ATM Forum και The Bluetooth Alliance. 3. Οργανισμοί Τυποποίησης: Από διαπιστευμένες ομάδες από κυβερνητικές οργανώσεις που είναι μη υποκείμενες σε διώξεις για συμπαιγνία (όσο βέβαια υπακούουν στους κανονισμούς). Έχουν μια ανοιχτή, τυπική διαδικασία για συμμετοχή που απαιτείται για την κατοχύρωση της -13-

14 οποιασδήποτε πατέντας στηριζόμενη σε δίκαιη, λογική και χωρίς διακρίσεις βάση. Τέτοιου είδους πρωτόκολλα έχουν δημιουργηθεί από οργανισμούς όπως η International Telecommunications Union (ITU) και το American National Standards Institute (ANSI). Σήμερα υπάρχει ένας μεγάλος αριθμός οργανισμών και φορέων που ειδικεύεται στο να δημιουργεί πρότυπα και πρωτόκολλα. Μερικοί από τους γνωστούς οργανισμούς είναι οι εξής: ANSI The American National Standards Institute ETSI European Telecommunications Standards Institute T1 Committee T1 ADSL The ADSL Forum ATM The ATM Forum ITU The International Telecommunication Union IETF The Internet Engineering Task Force IEEE Institute of Electrical and Electronic Engineers TIA Telecommunications Industry Association Εκτός από τους παραπάνω οργανισμούς υπάρχουν ακόμα δύο που έχουν συνεισφέρει τα μέγιστα στη διαχείριση δικτύων: International Organization for Standardization (ISO): Ο γνωστότερος διεθνής οργανισμός δημιουργίας προτύπων έχει δημιουργήσει το πρότυπο διασύνδεσης ανοικτού συστήματος OSI reference model και την ακολουθία πρωτοκόλλου (protocol suite) OSI. Internet Activities Board (IAB): Είναι μια ομάδα ερευνητών του διαδικτύου που συναντιέται τακτικά για να συζητήσει θέματα που αφορούν το διαδίκτυο. Το συμβούλιο αυτό θέτει ένα μεγάλο μέρος της πολιτικής του διαδυκτίου μέσω αποφάσεων για διάφορα θέματα σχετικά με αυτό. Το IAB έχει σχεδιάσει και λανσάρει ως πρότυπα του διαδικτίου κάποια από τα πιο σημαντικά Request for Comments (RFC) έγγραφα, ανάμεσα στα οποία περιλαμβάνονται το Transmission Control Protocol/Internet Protocol(TCP/IP) και το Simple Network Management Protocol (SNMP) -14-

15 1.4 Πρωτόκολλα Διαχείρισης Δικτύων Η διαχείριση δικτύων ρυθμίζεται από ένα μεγάλο αριθμό πρωτοκόλλων που υπάρχουν για την υποστήριξή της. Πολλές φορές στην ορολογία συναντώνται και με τον όρο network management standards. Ουσιαστικά τα πρωτόκολλα είναι ένα σετ ειδικών κανόνων που επιτρέπουν σε υπολογιστές αλλά και σε άλλες συσκευές που δημιουργούν ένα δίκτυο και έχουν διαφορετικά λειτουργικά συστήματα, τοπολογίες δικτύων, hardware, κ.α. να επικοινωνούν μεταξύ τους με τις λιγότερες δυνατές δυσκολίες. Ο επόμενος πίνακας παρουσιάζει μια λίστα πρωτοκόλλων που χρησιμοποιούνται στη διαχείριση δικτύων. Οργανισμό ς IETF ISO Ακρονύμιο Πρωτόκολλα The Internet Engineering Task Force International Organization for SNMP, MIBs, SMI, Netconf Standardization CMIS, CMIP Telecommunications ITU International Telecommunication Union W3C DMTF World Wide Web Consortium Distributed Management Task Force Organization for the Advancement of Management Network (TMN) XML technologies WBEM, CIM Web Services Distributed Structured Information Standards Tele Management Forum Object Management Group Management (WSDM) etom και ITIL UML και Corba OASIS TMF OMG Τα πρωτόκολλα Internet Control Message Protocol (ICMP) και Simple Network Management Protocol (SNMP) θεωρούνται ως τα θεμελιώδη πρωτόκολλα στη διαχείριση ενός δικτύου. Με ύπαρξη που αντιστοιχεί με την εποχή που δημιουργήθηκαν τα πρώτα δίκτυα, τα δυο αυτά πρωτόκολλα παραμένουν μέχρι και σήμερα βασικά εργαλεία της λύσης προβλημάτων και διαχείρισης ενός δικτύου. Στα επόμενα κεφάλαια θα εξεταστεί και αναλυθεί η λειτουργία τους για να γίνει πλήρως κατανοητή η σημασία ύπαρξης τους στα δίκτυα ακόμα και σήμερα. -15-

16 2 ICMP Στο Internet, το ΙΡ χρησιμοποιείται για τη μεταφορά δεδομένων. Όμως για την εύρυθμη λειτουργία του IP χρησιμοποιείται μια πλειάδα άλλων πρωτοκόλλων. Ένα από τα πρωτόκολλα αυτά είναι το ICMP, ένα πρωτόκολλο ελέγχου στο στρώμα δικτύου (network layer). Στο κεφάλαιο αυτό θα εξεταστεί και θα αναλυθεί η λειτουργία του ICMP, για να κατανοηθεί πλήρως η σημασία του στη διαχείριση δικτύου. 2.1 Γενικά Το ICMP θεωρείται ένα από τα κεντρικά πρωτόκολλα της ακολουθίας πρωτοκόλλων του Internet Protocol (IP). Χρησιμοποιείται από δικτυακές συσκευές για την αποστολή μηνυμάτων σφάλματος που μπορεί να είναι για παράδειγμα ότι η ζητούμενη υπηρεσία δεν είναι διαθέσιμη ή ότι κάποιο host ή router δεν είναι προσπελάσιμο. Είναι πιο κοινά γνωστό, λόγω της ping εντολής του και δημιουργεί μια επικοινωνία χαμηλού επιπέδου (low level) που διασφαλίζει την σύνδεση των πυρήνων ανάμεσα σε δύο τερματικούς σταθμούς ενός επιπέδου. Σε αντίθεση με τα κοινά πρωτόκολλα μεταφοράς δεδομένων, όπως είναι τα TCP και UDP, το ICMP δεν χρησιμοποιείται από τις εφαρμογές που εκτελούνται σε κάποιο υπολογιστή ως τρόπος επικοινωνίας, αλλά από το λειτουργικό του σύστημα.. Εξαίρεση στο χαρακτηριστικό του αυτό αποτελεί η εντολή ping, που στέλνει ICMP Echo Request μηνύματα σε κάποιον υπολογιστή του δικτύου για να διαπιστώσει τόσο την ύπαρξη του υπολογιστή όσο και το πόσο απομακρυσμένος είναι μέσω της μέτρησης του χρόνου που χρειάζεται το μήνυμα να φτάσει σε αυτόν. Ο απομακρυσμένος υπολογιστής απαντάει στην περίπτωση αυτή με μηνύματα Echo Response. Η έκδοση του ICMP για την 4η έκδοση του IPv4 είναι γνωστή ως ICMPv4, που αναθεωρήθηκε κατά τη διάρκεια του ορισμού της IPv6 και οι λειτουργίες ελέγχου -16-

17 πολυεκπομπής του IPv4 Group Membership Protocol (IGMP) έχουν πλέον ενσωματωθεί στο ICMPv Τεχνικές λειτουργίες Αν και είναι μέρος του IP μέρους του TCP/IP, το ICMP λειτουργεί εκτός των κανόνων των παραδοσιακών πρωτοκόλλων TCP και UDP. Αυτό συνεπάγεται την μη επίδραση του ICMP σε περιπτώσεις τροποποίησης μιας σύνδεσης TCP ή των κανόνων προσπέλασης μιας συσκευής του δικτύου, ενώ ισχύει και το αντίστροφο. Αυτή η ουσιαστική απομόνωση από τα κοινά πρωτόκολλα μεταφοράς δεδομένων, δίνει στο ICMP μεγάλες δυνατότητες στην επίλυση προβλημάτων και στην σωστότερη διαχείριση του δικτύου. Τα τεχνικά χαρακτηριστικά και οι προδιαγραφές του πρωτοκόλλου αποτελούνται από μια εξαιρετικά περιορισμένη λίστα εντολών που περιορίζονται από τον σχεδιασμό του για εξερεύνηση της συνδεσιμότητας μεταξύ δικτύου και τερματικών καθώς και δρομολόγηση. Για το λόγο αυτό, το ICMP υπάρχει σε όλα τα δίκτυα με μέγιστη ασφάλεια. Εικόνα 2: Ανεύρεση σφάλματος στο δίκτυο με μυνήματα ICMP Οι βασικές λειτουργίες του ICMP είναι οι ακόλουθες: Ανεύρεση σφαλμάτων στο δίκτυο: Η μη προσπελασιμότητα ενός host ή ολόκληρων τμημάτων του δικτύου μπορεί να προέρχεται από κάποιο σφάλμα λειτουργίας είτε του host είτε του κόμβο σύνδεσης (Εικ. 2). Στα σφάλματα αυτού του είδους περιλαμβάνονται και περιπτώσεις όπου ένα TCP ή UDP πακέτο αποστέλλεται σε ένα port number χωρίς συνημμένο παραλήπτη. Ακόμα και τέτοια σφάλματα μπορούν να ανεβρεθούν μέσω του ICMP. -17-

18 Ανεύρεση συμφόρησης στο δίκτυο: Συμφόρηση σε ένα δίκτυο δημιουργείται όταν ένας δρομολογητής αρχίζει να αποθηκεύει προσωρινά πολλά πακέτα, λόγω της ανικανότητας του να τα στέλνει με τον ίδιο ρυθμό που τα λαμβάνει. Τέτοια συμφόρηση έχει ως αποτέλεσμα την δημιουργία ICMP Source Quench μηνυμάτων, που αποστέλλονται στην μονάδα που στέλνει τα πακέτα και αποσκοπούν την τελική μείωση του ρυθμού αποστολής των μηνυμάτων. Φυσικά η δημιουργία πολλών μηνυμάτων Source Quench θα επιβαρύνει την ήδη υπάρχουσα συμφόρηση του δικτύου και για το λόγο αυτό η χρήση τους γίνεται με φειδώ. Επίλυση προβλημάτων: Το ICMP υποστηρίζει την λειτουργία Echo, που απλά στέλνει ένα πακέτο από και προς δύο τερματικών. Η εντολή ping που βασίζεται σ αυτή την λειτουργία, αποστέλλει μια σειρά πακέτων και κάνει μετρήσεις σχετικά με το χρόνο αποστολής και λήψης των πακέτων καθώς και την ποσοστιαία απώλειά τους. Αναγγελία χρόνου λήξης (timeout): Αν ο χρόνος TTL ενός IP πακέτου μηδενιστεί, τότε ο δρομολογητής που απορρίπτει το πακέτο δημιουργεί ένα πακέτο ICMP αναγγελίας του γεγονότος αυτού, ICMP Time Exceeded. Το εργαλείο TraceRoute χαρτογραφεί τις διαδρομές του δικτύου στέλνοντας πακέτα με μικρό χρόνο TTL και παρακολουθώντας της αναγγελίες χρόνου λήξης Δομή πακέτου ICMP Ο header ενός ICMP πακέτου ξεκινάει αμέσως μετά τον IPv4 header και αναγνωρίζεται σαν πρωτόκολλο νούμερο '1'. Όλα τα πακέτα ICMP έχουν ένα 8-byte header και data section μεταβλητού μεγέθους. Τα 4 πρώτα byte του header παραμένουν σταθερά στις θέσεις τους και αντιπροσωπεύουν: το πρώτο byte, τον τύπο του ICMP, το δεύτερο, τον κωδικό του ICMP και τα 3 και 4, το άθροισμα ελέγχου του συνολικού μηνύματος ICMP. Τα υπόλοιπα 4 byte του header εξαρτώνται από τον τύπο και τον κωδικό του ICMP. Εικόνα 3: Δομή Header ενός μηνύματος ICMP -18-

19 Τα ICMP μηνύματα σφάλματος περιέχουν ένα data section που περιέχει ολόκληρο τον IP header συν τα 8 πρώτα byte των δεδομένων του IP πακέτου που είχε ως αποτέλεσμα την δημιουργία του μηνύματος σφάλματος. Κατόπιν το ICMP πακέτο ενθυλακώνεται σε νέο πακέτο IP. Στο σχήμα της εικόνας 3 που ακολουθεί, φαίνεται το header ενός πακέτου ICMP και ακολουθεί επεξήγηση των πεδίων της. Τύπος (Type): Υπάρχουν 15 διαφορετικοί τύποι μηνυμάτων που μπορεί να είναι είτε αναφοράς σφάλματος είτε απλά πληροφοριακά. Τα μηνύματος αναφοράς σφάλματος συνήθως είναι τα εξής: Destination unreachable, Packet too big, Time exceed, Parameter problem. Τα πληροφοριακά μηνύματα είναι συνήθως τα εξής: Echo Request, Echo Reply, Group Membership Query, Group Membership Report, Group Membership Reduction. Κωδικός (Code): Κάθε τύπος μηνύματος έχει περισσότερους από ένα κωδικούς που αντιστοιχούν σε διαφορετικό είδος μηνύματος. Για παράδειγμα το μήνυμα Destination Unreachable περιλαμβάνει τα εξής διαφορετικά είδη μηνυμάτων: δεν υπάρχει διαδρομή προς τον παραλήπτη, η επικοινωνία με τον παραλήπτη προστατεύεται από διαχειριστή, μη προσβάσιμη διεύθυνση, μη προσβάσιμο port, κ.α. Περισσότερες λεπτομέρειες σχετικά με τους κωδικούς των μηνυμάτων θα αναφερθούν σε επόμενη υποενότητα. Άθροισμα ελέγχου (Checksum): Το 16-bit αυτό πεδίο χρησιμοποιείται για τον έλεγχο σφαλμάτων κατά την μετάδοση του πακέτου. Υπολογίζεται από το ICMP header και τα δεδομένα του ξεκινώντας από το ICMP Type. Για τον υπολογισμό του checksum, το πεδίο του θα πρέπει να είναι μηδέν. Αναγνωριστικό Ταυτότητας (Identifier ID): Η τιμή ID του πακέτου, η οποία επιστρέφεται στον υπολογιστή που δημιούργησε το πακέτο στην περίπτωση που έχουμε απάντηση ECHO REPLY. Βοηθάει στην ταυτοποίηση αιτήσεων και απαντήσεων. Αριθμός σειράς (Sequence number): Περιέχει την τιμή σειράς του πακέτου και επιστρέφεται στον υπολογιστή που δημιούργησε το πακέτο στην περίπτωση που έχουμε απάντηση ECHO REPLY. Βοηθάει στην ταυτοποίηση αιτήσεων και απαντήσεων. Address mask: Μια 32-bit mask. -19-

20 3.4. ICMP Μηνύματα Τα ICMP μηνύματα ενθυλακώνονται σε πακέτα IP και χρησιμοποιούνται σαν εξωζωνικά μηνύματα που σχετίζονται με την σωστή ή εσφαλμένη λειτουργία του δικτύου, χρησιμοποιούνται σε περιπτώσεις διάγνωσης ή ελέγχου ή δημιουργούνται σε περιπτώσεις σφαλμάτων της λειτουργίες του IP (Εικ. 4). Τα μηνύματα σφάλματος αποστέλλονται στην IP διεύθυνση του αρχικού πακέτου. Εικόνα 4: Μορφή μηνύματος ICMP Αποστέλλονται σε πλήθος περιπτώσεων όπως για παράδειγμα όταν ένα πακέτο δεν μπορεί να φτάσει στον προορισμό του, όταν η πύλη (gateway) δεν έχει την χωρητική ικανότητα να προωθήσει ένα πακέτο ή όταν ο δρομολογητής οδηγεί τα πακέτα από άλλο πιο σύντομο δρόμο. Αν και η πιο διαδεδομένη χρήση τους είναι η αναφορά σφαλμάτων κατά την επεξεργασία ενός πακέτου, για την αποφυγή της διαρκούς αποστολής μηνυμάτων, κανένα ICMP μήνυμα δεν αποστέλλεται που να αφορά προηγούμενο ICMP μήνυμα. Επίσης, ICMP μηνύματα δεν αποστέλλονται σε περιπτώσεις σφάλματος κατά τη διαχείριση fragment zero κατακερματισμένων πακέτων ( fragemented datagrams). Το ακόλουθο παράδειγμα βοηθάει στην καλύτερη κατανόηση της λειτουργίας των ICMP μηνυμάτων. Κάθε συσκευή, όπως είναι για παράδειγμα ένας δρομολογητής, που προωθεί ένα πακέτο IP πρώτα μειώνει την τιμή του χρόνου (time to live - TTL) στο πεδίο του IP header κατά ένα. Αν η τιμή του TTL που προκύπτει είναι 0, τότε το πακέτο απορρίπτεται -20-

21 και ένα μήνυμα ICMP Time To Live exceeded in transit αποστέλλεται στη διεύθυνση που απέστειλε το πακέτο. Αν και τα ICMP μηνύματα περιέχονται στα IP πακέτα, επεξεργάζονται σαν ειδικές περιπτώσεις και όχι σαν ένα πρωτόκολλο που ακολουθεί τους κανόνες του IP πρωτοκόλλου. Η επεξεργασία τους δηλαδή γίνεται με διαφορετικό τρόπο από αυτόν των IP πακέτων. Σε πολλές περιπτώσεις είναι απαραίτητος ο έλεγχος των περιεχομένων των ICMP μηνυμάτων για την αποστολή του κατάλληλου μηνύματος σφάλματος στην εφαρμογή που δημιούργησε το αρχικό IP πακέτο, αυτή δηλαδή που έστειλε το πακέτο που προκάλεσε την αποστολή του ICMP μηνύματος. Οι πιο διαδεδομένες εφαρμογές κοινής χρήσης (utilities) του δικτύου βασίζονται στα ICMP μηνύματα. Η εντολή traceroute υλοποιείται με αποστολή IP πακέτων που περιέχουν τον χρόνο TTL σε πεδίο του IP header και την λήψη ICMP Time to live exceeded in transit ή Destination unreachable μηνυμάτων που δημιουργούνται ανάλογα. Επίσης, η εντολή ping υλοποιείται με χρήση των ICMP "Echo request" και "Echo reply"μηνυμάτων. Λόγω της σπουδαιότητάς της, η εντολή ping θα αναλυθεί λεπτομερέστερα στην επόμενη υποενότητα. Ο σχεδιασμός του πρωτοκόλλου IP δεν το έκανε ποτέ αξιόπιστο. Επομένως, και η μεταφορά των ICMP πακέτων δεν είναι αξιόπιστη. Παρόλα αυτά ο σκοπός των μηνυμάτων αυτών είναι η παροχή πληροφοριών σχετικών με τα προβλήματα του επικοινωνιακού περιβάλλοντος και όχι η ενίσχυση της αξιοπιστίας του IP. Η αποστολή ενός πακέτου, ή η λήψη ενός μηνύματος ελέγχου, σε καμιά περίπτωση δεν είναι εγγυημένη. Επομένως, δεν είναι πανάκεια η αποστολή ή λήψη τους για κάθε πρόβλημα που μπορεί να προκύψει στο δίκτυο Λίστα μηνυμάτων ελέγχου ICMP Ο επόμενος πίνακας περιέχει μια λίστα μηνυμάτων ελέγχου ICMP. Στον πίνακα αυτό αναγράφονται ο τύπος, ο κωδικός καθώς και η περιγραφή του κάθε μηνύματος. Type 0 Echo Reply 1 and 2 3 Destination Unreachable Code Περιγραφή Echo reply (used to ping) Reserved Destination network unreachable Destination host unreachable Destination protocol unreachable Destination port unreachable Fragmentation required, and DF flag set Source route failed -21-

22 4 Source Quench 5 Redirect Message Echo Request 9 Router Advertisement 10 Router Solicitation 11 Time Exceeded 12 Parameter Problem: Bad IP header 13 Timestamp 14 Timestamp Reply 15 Information Request 16 Information Reply 17 Address Mask Request 18 Address Mask Reply through Traceroute Destination network unknown Destination host unknown Source host isolated Network administratively prohibited Host administratively prohibited Network unreachable for TOS Host unreachable for TOS Communication administratively prohibited Host Precedence Violation Precedence cutoff in effect Source quench (congestion control) Redirect Datagram for the Network Redirect Datagram for the Host Redirect Datagram for the TOS & network Redirect Datagram for the TOS & host Alternate Host Address Reserved Echo request (used to ping) Router Advertisement Router discovery/selection/solicitation TTL expired in transit Fragment reassembly time exceeded Pointer indicates the error Missing a required option Bad length Timestamp Timestamp reply Information Request Information Reply Address Mask Request Address Mask Reply Reserved for security Reserved for robustness experiment Information Request Datagram Conversion Error Mobile Host Redirect Where-Are-You (originally meant for IPv6) Here-I-Am (originally meant for IPv6) Mobile Registration Request Mobile Registration Reply -22-

23 37 38 Domain Name Request Domain Name Reply SKIP Algorithm Discovery Protocol, Simple Key-Management 39 for Internet Protocol 40 Photuris, Security failures ICMP for experimental mobility protocols such as Seamoby through 255 [RFC4065] Reserved Στις επόμενες υποενότητες θα εξεταστούν με λεπτομέρεια κάποια από αυτά τα μηνύματα ελέγχου με σκοπό την πλήρη κατανόηση των σημαντικότερων λειτουργιών του ICMP και είναι χωρισμένα σε μηνύματα σφάλματος και μηνύματα αιτήσεων/απαντήσεων Μηνύματα Σφάλματος Τα σπουδαιότερα μηνύματα της κατηγορίας αυτής είναι τα εξής: Απρόσιτος Προορισμός (Destination Unreachable) Σιγή Πηγής (Source Quench) Αναδρομολόγηση (Redirect Message) Λήξη χρόνου (Time Exceeded) Η δομή ενός πακέτου που περιέχει μηνύματα σφάλματος ICMP έχει την μορφή που φαίνεται στην εικόνα 5. Εικόνα 5: Δομή ενός πακέτου που περιέχει μηνύματα σφάλματος ICMP Κάθε μήνυμα σφάλματος ICMP έχει διαφορετικό header που εξαρτάται από το είδος του σφάλματος που περιέχει. Ιστορικά, τα μηνύματα αυτά επέστρεφαν το IP header του -23-

24 πακέτου που δημιούργησε το λάθος και τα πρώτα 8 byte δεδομένων. Κάτι τέτοιο όμως σήμερα δεν επαρκεί σε πιο πολύπλοκες περιστάσεις, όπως είναι το IP-in-IP tunneling. Επομένως το ICMP πακέτο θα πρέπει να περιέχει όσο το δυνατό περισσότερο μέρος του πακέτου που το προκάλεσε, χωρίς το μήκος του ICMP πακέτου να υπερβαίνει τα 576 bytes Απρόσιτος Προορισμός (Destination unreachable) Το Destination unreachable μήνυμα δημιουργείται από τον host ή την εσωτερική του πύλη για να ενημερώσει τους χρήστες του δικτύου ότι ο προορισμός του είναι απρόσιτος για κάποιον λόγο. Επίσης μπορεί να δημιουργηθεί μετά από μια εκπομπή TCP, UDP ή μετά από άλλη εκπομπή ICMP. Ένα απρόσιτο TCP port όμως απαντά σε ένα μήνυμα TCP RST και όχι σε ένα Destination Unreachable τύπου 3 όπως θα μπορούσε κάποιος να περιμένει. Σε περιπτώσεις που το αρχικό πακέτο έχει πολλαπλές διευθύνσεις προορισμού, μήνυμα σφάλματος δεν πρόκειται να δημιουργηθεί. Αντίθετα, οι λόγοι για τους οποίους μπορεί να δημιουργηθεί ένα μήνυμα τέτοιου είδους μπορούν να περιλαμβάνουν: την ανυπαρξία της φυσικής σύνδεσης με τον host (η απόσταση είναι άπειρη), το αναφερόμενο πρωτόκολλο (Εικ.6) ή port δεν είναι ενεργό, τα δεδομένα είναι κατακερματισμένα αλλά η 'don't fragment' flag είναι σε ενεργή κατάσταση, κ.α. Εικόνα 6: Περίπτωση μηνύματος ICMP Destination Unreachable Η δομή ενός πακέτου που περιέχει μηνύματα σφάλματος ICMP Destination unreachable έχει την μορφή που φαίνεται στην εικόνα 7. 8 Type = 3 unused IP header and first 8 bytes of 16 Code 32bit Header checksum Next-hop MTU original datagram's data -24-

25 Εικόνα 7:Μήνυμα Destination unreachable όπου τα πεδία: Type (bits 0-7) = 3 Code (bits 8-15): χρησιμοποιείται για τον καθορισμό του τύπου του σφάλματος που μπορεί να είναι ένας από τους παρακάτω: Code Περιγραφή 0 Network unreachable error. 1 Host unreachable error. 2 Protocol unreachable error (the designated transport protocol is not supported). Port unreachable error (the designated protocol is unable to inform the host of the 3 incoming message). The datagram is too big. Packet fragmentation is required but the 'don't fragment' 4 (DF) flag is on. 5 Source route failed error. 6 Destination network unknown error. 7 Destination host unknown error. 8 Source host isolated error. 9 The destination network is administratively prohibited. 10 The destination host is administratively prohibited. 11 The network is unreachable for Type Of Service. 12 The host is unreachable for Type Of Service. Communication administratively prohibited (administrative filtering prevents 13 packet from being forwarded). Host precedence violation (indicates the requested precedence is not permitted for 14 the combination of host or network and port). Precedence cutoff in effect (precedence of datagram is below the level set by the 15 network administrators) Σιγή Πηγής (Source quench) Το μήνυμα Source Quench αιτείται την μείωση των αποσταλμένων μηνυμάτων που στέλνονται προς ένα δρομολογητή ή ένα host. Το μήνυμα αυτό δημιουργείται όταν ένας δρομολογητής ή ένας host δεν έχει την απαιτούμενη χωρητικότητα στο buffer του για να μπορέσει να επεξεργαστεί τα αιτήματα που του αποστέλλονται. Source quench μήνυμα μπορεί να δημιουργηθεί και στην περίπτωση που η χωρητικότητα αυτή φτάνει στα όριά της. -25-

26 Σε ένα δίκτυο τα δεδομένα αποστέλλονται την ίδια χρονική στιγμή με μεγάλες ταχύτητες από ένα ή περισσότερους προς ένα συγκεκριμένο δρομολογητή. Παρόλο που οι δρομολογητές έχουν μεγάλες δυνατότητες χώρου αποθήκευσης μηνυμάτων, ο χώρος αυτός έχει τα όριά του, με αποτέλεσμα να μην μπορούν να αποθηκεύονται ή να μπαίνουν σε ουρά, περισσότερα δεδομένα από τα επιτρεπτά όρια του χώρου αυτού. Έτσι αν η ουρά γεμίσει, όσα δεδομένα έρχονται απορρίπτονται μέχρι τη στιγμή που η ουρά είναι σε θέση να δεχθεί νέα δεδομένα. Στην περίπτωση που στο στρώμα δικτύου δεν υπάρχει μηχανισμός που να ενημερώνει για την κατάσταση αυτή, ο χρήστης του δικτύου δεν είναι σε θέση να γνωρίζει αν τα δεδομένα που έχει στείλει έχουν φτάσει στον προορισμό τους. Επομένως, για την αποφυγή τέτοιων καταστάσεων, είναι επιβεβλημένη η λήψη μέτρων στο στρώμα δικτύου και τα μέτρα αυτά είναι τα μηνύματα σιγής πηγής. Με το μηχανισμό του source quench, ο δρομολογητής αναγνωρίζει ότι ο ρυθμός εισόδου των δεδομένων σε αυτόν είναι πολύ μεγαλύτερος από τον ρυθμό εξόδου τους και στέλνει ένα μήνυμα ICMP προς τους χρήστες, ειδοποιώντας τους ότι θα πρέπει να μειώσουν την ταχύτητα αποστολής των δεδομένων τους ή ότι θα πρέπει να περιμένουν για κάποιο χρονικό διάστημα μέχρι να ξαναδοκιμάσουν να στείλουν δεδομένα. Ο χρήστης με την λήψη του μηνύματος αυτού θα πράξει ανάλογα. Με τον τρόπο αυτό το μήνυμα source quench λειτουργεί ως ελεγκτής ροής δεδομένων στο στρώμα δικτύου. Η δομή ενός πακέτου που περιέχει μηνύματα σφάλματος ICMP Source Quench έχει την μορφή που φαίνεται στην εικόνα Code = 0 Type = 4 unused IP header and first 32bit Header checksum 8 bytes of original datagram's data Εικόνα 8: Μήνυμα Source quench όπου: Type = 4 Code = 0 IP header: μαζί με επιπρόσθετα δεδομένα χρησιμοποιείται για τον συσχετισμό αίτησης και απάντησης. -26-

27 Το είδος αυτό του μηνύματος σφάλματος δεν χρησιμοποιείται πλέον, καθώς έρευνες απέδειξαν ότι το ICMP Source Quench ήταν αναποτελεσματικό αντίδοτο σε περιπτώσεις συμφόρησης και οι δρομολογητές που δημιουργούσαν τέτοιου είδους μηνύματα αποδοκιμάστηκαν το 1995 από το RFC1812. Επιπλέον, η οποιαδήποτε δράση των μηνυμάτων source quench αποδοκιμάστηκαν το 2012 από το RFC Αναδρομολόγηση (Redirect) Τα ICMP redirect μηνύματα χρησιμοποιούνται από τους δρομολογητές για να ειδοποιήσουν τους host σε μια ζεύξη δεδομένων (data link) για την ύπαρξη καλύτερης διαδρομής προς ένα συγκεκριμένο προορισμό. Το ακόλουθο παράδειγμα (Εικ.9) θα δείξει με καλύτερο τρόπο τι είναι η καλύτερη διαδρομή για ένα συγκεκριμένο προορισμό. Οι δύο δρομολογητές R1 και R2 είναι συνδεδεμένοι στο ίδιο τμήμα Ethernet με τον host H. Η προκαθορισμένη πύλη (default gateway) του host H ρυθμισμένη να χρησιμοποιεί τον δρομολογητή R1. Ο host H στέλνει ένα πακέτο στον δρομολογητή R1 με τελικό προορισμό τον απομακρυσμένο Remote Branch office Host Ο δρομολογητής R1, αφού πρώτα συμβουλευτεί τον πίνακα δρομολόγησής του (routing table), βρίσκει ότι το επόμενο hop για τον Host είναι ο δρομολογητής R2. Έτσι προωθεί το πακέτο προς τον δρομολογητή R2 ενώ ταυτόχρονα στέλνει και ένα μήνυμα ICMP redirect στον host H. Το μήνυμα αυτό ειδοποιεί τον host ότι η καλύτερη διαδρομή για τον προορισμό Host είναι μέσω του δρομολογητή R2. Με τον τρόπο αυτό, όλα τα υπόλοιπα πακέτα που θέλει να στείλει ο host H προς τον Host , τα στέλνει μέσω του δρομολογητή R2. Εικόνα 9: Περίπτωση αναδρομολόγησης -27-

28 Η μορφή που έχει το διορθωτικό μήνυμα (ICMP redirect message) του δρομολογητή R1 προς τον host H ( ) είναι η ακόλουθη: R1# debug ip icmp ICMP packet debugging is on *Mar 18 06:28:54: ICMP:redirect sent to for dest , use gw R1# Μέσω του μηνύματος αυτού ο δρομολογητής R1 ( ) ειδοποιεί τον host H ( ) για χρήση του δρομολογητή R2 ( ) σαν πύλη προς τον προορισμό Οι δρομολογητές της Cisco στέλνουν ICMP redirects μόνο στην περίπτωση που επαληθεύονται όλες οι παρακάτω προϋποθέσεις: Το interface μέσω του οποίου ένα πακέτο φτάνει στον δρομολογητή είναι το ίδιο με αυτό από το οποίο δρομολογείται προς τον προορισμό του. Η IP διεύθυνση του αποστολέα και η IP διεύθυνση του επόμενου hop του δρομολογούμενου πακέτου ανήκουν στο ίδιο δίκτυο ή στο ίδιο subnet. kernel είναι ρυθμισμένος για αποστολή μηνυμάτων αναδρομολόγησης (Από προεπιλογή, οι δρομολογητές της Cisco στέλνουν μηνύματα αναδρομολόγησης, τα οποία μπορούν να απενεργοποιηθούν μέσω της εντολής interface no ip redirects). Σημείωση: Τα μηνύματα αναδρομολόγησης είναι απενεργοποιημένα από προεπιλογή αν στο interface είναι επιλεγμένο το πρωτόκολλο Hot Standby Router Protocol (HSRP). Από την έκδοση Cisco IOS Software Release 12.1(3)T και μετά, επιτρέπεται η ενεργοποίηση του ICMP Redirect ακόμα και σε interface με HSRP. Για παράδειγμα, αν ένας δρομολογητής έχει δύο IP διευθύνσεις σε ένα από τα interface του: interface ethernet 0-28-

29 ip address ip address secondary και λάβει ένα πακέτο από ένα host που είναι συνδεδεμένος στο subnet και το πακέτο προορίζεται για ένα host συνδεδεμένο στο subnet , τότε ο δρομολογητής δεν θα στείλει μήνυμα αναδρομολόγησης καθώς η δεύτερη συνθήκη από τις αναφερόμενες παραπάνω δεν επαληθεύεται. Η δομή ενός πακέτου που περιέχει μηνύματα αναδρομολόγησης έχει την μορφή που φαίνεται στην εικόνα Type = 5 IP address IP header and first 16 Code 32bit Header checksum 8 bytes of original datagram's data Εικόνα 10: Μήνυμα Redirect όπου: Type = 5 Code: καθορίζει τον λόγο της αναδρομολόγησης, που μπορεί να είναι ένας από τους παρακάτω: Cod Περιγραφή e Redirect for Network Redirect for Host Redirect for Type of Service and Network Redirect for Type of Service and Host IP address: η 32-bit διεύθυνση της πύλης στην οποία πρέπει να γίνει η αναδρομολόγηση IP header: μαζί με επιπρόσθετα δεδομένα χρησιμοποιείται για τον συσχετισμό της αίτησης και της απάντησης που προκάλεσαν την αναδρομολόγηση. -29-

30 3.6.4 Λήξη χρόνου (Time exceeded) Ένα μήνυμα Time Exceeded δημιουργείται από την πύλη για να ενημερώσει τον αποστολέα ότι το πακέτο που έστειλε απορρίφθηκε επειδή ο χρόνος TTL μηδενίστηκε. Μήνυμα λήξης χρόνου μπορεί επίσης να αποσταλεί από ένα host αν αποτύχει στην επανασυγκρότηση ενός κατακερματισμένου πακέτου μέσα στα επιτρεπτά χρονικά περιθώρια. Τα μηνύματα λήξης χρόνου χρησιμοποιούνται ευρέως από το traceroute για την αναγνώριση πυλών της σύνδεσης δύο host (Εικ.11). Εικόνα 11: Λειτουργία traceroute Η δομή ενός πακέτου που περιέχει μηνύματα λήξης χρόνου έχει την μορφή που φαίνεται στην εικόνα Type = 11 unused IP header and first 16 Code 32bit Header checksum 8 bytes of original datagram's data Εικόνα 12: Μήνυμα Time exceeded όπου: Type =

31 Code: καθορίζει τον λόγο για τον οποίο δημιουργήθηκε το μήνυμα λήξης χρόνου, που μπορεί να είναι ένας από τους παρακάτω: Cod e 0 1 Περιγραφή Time-to-live exceeded in transit. Fragment reassembly time exceeded. Ο IP header και τα πρώτα 64 bit του αρχικού πακέτου χρησιμοποιούνται από τον πηγαίο host για να συγκρίνει το μήνυμα λήξης χρόνου με το πακέτο που έχει απορριφθεί Μηνύματα αίτησης /απάντησης Τα σπουδαιότερα μηνύματα της κατηγορίας αυτής είναι τα εξής: Μηνύματα αίτησης / απάντησης ηχούς (Echo request / replay - Ping) Μηνύματα αίτησης / απάντησης χρονικής σφραγίδας (Timestamp request / replay) Μηνύματα αίτησης / απάντησης μάσκας δικτύου (Address mask request / replay) Η εντολή ping Η επίκληση της πιο κοινής ICMP εντολής γίνεται με πληκτρολόγηση στη γραμμή εντολών της command prompt της εκτελέσιμης εντολής ping (Εικ.13). Αυτή η εκτελέσιμη εντολή υπάρχει σήμερα σε κάθε λειτουργικό σύστημα ( Operating System - OS) και σε κάθε διαδικτυακό λειτουργικό σύστημα (Internetwork Operating System - IOS). Η εκτέλεση της προς μια απομακρυσμένη διέθυνση IP επιστρέφει στο χρήστη μια μικρή αλλά πολύ σημαντική πληροφορία. Εικόνα 13: Η εντολή ping -31-

32 Όπως φαίνεται στο κομμάτι κώδικα που ακολουθεί, μια επιτυχημένη εκτέλεση της εντολής ping έχει απάντηση που ενημερώνει τον χρήστη ότι το host λειτουργεί χωρίς προβλήματα και ότι ανταποκρίνεται στα πιο βασικά αιτήματα του δικτύου. C:\>ping Pinging [ ] with 32 bytes of data: Reply from : bytes=32 time=34ms TTL=117 Reply from : bytes=32 time=39ms TTL=117 Reply from : bytes=32 time=34ms TTL=117 Reply from : bytes=32 time=34ms TTL=117 Ping statistics for : Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli seconds: Minimum = 34ms, Maximum = 39ms, Average = 35ms Αλλά αυτή δεν είναι η μόνη πληροφορία που αντλείται από την απάντηση στην εντολή ping. Υπάρχουν πληροφορίες και για την κατάσταση της σύνδεσης μεταξύ αποστολέα και παραλήπτη. Η γρήγορη απάντηση περιλαμβάνει στοιχεία σχετικά με τον χρόνο, σε milliseconds, που απαιτήθηκαν για την ολοκλήρωση ολόκληρου του κύκλου εκτέλεσης της εντολής. Ο χρόνος αυτός δεν είναι άλλος από τον χρόνο αναμονής ή χρόνο καθυστέρησης που υπάρχει στην σύνδεση αυτή. Συνδέσεις με μεγάλο χρόνο αναμονής ή μεγάλο χρόνο καθυστέρησης μπορούν να προκύψουν λόγω πολλών παραγόντων όπως είναι η συμφόρηση του εύρους ζώνης (bandwidth congestion), ύπαρξη κάποιου ή κάποιων σφαλμάτων στη σύνδεση μεταξύ των δύο τερματικών ή ακόμα και πρόβλημα επεξεργασίας σε κάποια από τις συσκευές της διαδρομής. Μια τελευταία, αλλά εξίσου σημαντική πληροφορία που μπορεί να προκύψει είναι η ποιότητα της σύνδεσης. Στις τελευταίες 4 γραμμές της απάντησης στην επιτυχημένη εκτέλεση της εντολής ping response υπάρχει πληροφορία σχετικά με τον αριθμό των πακέτων που χάθηκαν κατά τη διαδρομή. Ο αριθμός των χαμένων αυτών πακέτων καθώς και ο ποσοστιαίος συσχετισμός τους με την συνολική μετακίνηση δεδομένων, αντιπροσωπεύουν την ποιότητα του TCP δικτύου. Μεγάλος αριθμός χαμένων πακέτων σημαίνει πρόβλημα στο -32-

33 δίκτυο, ο τύπος του οποίου βέβαια δεν είναι δουλειά της ICMP ping εντολής, όμως η σπουδαιότητα για την πληροφόρηση της κατάστασης του δικτύου είναι. Και μπορεί για ένα απλό δίκτυο στο οποίο γίνεται απλή μεταφορά αρχείο, η απώλεια κάποιων πακέτων να σημαίνει απλά μείωση της συνολικής απόδοσής του, υπάρχουν περιπτώσεις που η απώλεια αυτή να είναι προβληματική στην όλη λειτουργία του. Τέτοια δίκτυα είναι ως επί το πλείστον δίκτυα με streaming εφαρμογές, όπως VoIP, videoconferencing, ή δίκτυα που υποστηρίζουν απομακρυσμένη πρόσβαση Μηνύματα αίτησης / απάντησης χρονικής σφραγίδας (Timestamp request / replay) Τα μηνύματα Timestamp χρησιμοποιούνται για συγχρονισμό του χρόνου και εκτίμηση του χρόνου διαδρομής (Εικ.14). Εικόνα 14: Περίπτωση μηνύματος ICMP timestamp Η δομή ενός πακέτου που περιέχει μηνύματα αίτησης χρονικής σφραγίδας έχει την μορφή που φαίνεται στην εικόνα Type = Code = 32bit Header checksum 0 Identifier Sequ ence numb er Originate timestamp Εικόνα 15: Μήνυμα Timestamp όπου: Type = 13 Code = 0-33-

34 Identifier και Sequence Number: χρησιμοποιούνται για τον συσχετισμό των μηνυμάτων αίτησης και απάντησης timestamp Originate timestamp: είναι ο χρόνος σε msec, από τα μεσάνυχτα Universal Time Clock (UTC). Στην περίπτωση μη αναφοράς σε χρόνο UTC, το πιο σημαντικό (most-significant) έχει την τιμή 1. Το μήνυμα Timestamp Reply απαντά στο μήνυμα Timestamp. Αποτελείται από το αρχικό μήνυμα Timestamp του αποστολέα καθώς και ένα λαμβανόμενο timestamp και ένα εκπεμπόμενο timestamp. Η δομή ενός πακέτου που περιέχει μηνύματα απάντησης χρονικής σφραγίδας έχει την μορφή που φαίνεται στην εικόνα Type = Code = 32bit Header checksum 0 Identifier Sequ ence numb er Originate timestamp Receive timestamp Transmit timestamp Εικόνα 16: Μήνυμα Timestamp reply όπου: Type = 14 Code = 0 Identifier και Sequence number: χρησιμοποιούνται για τον συσχετισμό των μηνυμάτων αίτησης και απάντησης Originate timestamp: είναι ο χρόνος τη στιγμή αποστολής του μηνύματος από τον αποστολέα Receive timestamp: είναι ο χρόνος τη στιγμή λήψης του μηνύματος από τον παραλήπτη Transmit timestamp είναι ο χρόνος τη στιγμή αποστολής του μηνύματος από τον παραλήπτη -34-

35 Όλοι οι χρόνοι είναι σε msec και μετρούνται από τα μεσάνυχτα Universal Time Clock (UTC). Στην περίπτωση μη αναφοράς σε χρόνο UTC, το πιο σημαντικό (most-significant) έχει την τιμή Μηνύματα αίτησης / απάντησης μάσκας δικτύου (Address mask request / replay) Τα μηνύματα Address mask request κανονικά αποστέλλονται από έναν host προς ένα δρομολογητή με σκοπό την απόκτηση της κατάλληλης μάσκας subnet (Εικ.17). Εικόνα 17: Περίπτωση μηνύματος ICMP address mask Οι παραλήπτες θα πρέπει να απαντήσουν στο μήνυμα αυτό με μήνυμα Address mask reply. Η δομή ενός πακέτου που περιέχει μηνύματα αίτησης μάσκας δικτύου έχει την μορφή που φαίνεται στην εικόνα Type = Code = 32bit Header checksum 0 Identifier Sequ ence numb er Address mask Εικόνα 18: Μήνυμα Address mask request όπου: Type = 17 Code = 0 Address mask: μπορεί να ορισθεί και ως 0 Δυστυχώς, ένα μήνυμα ICMP Address Mask Request μπορεί να χρησιμοποιηθεί ως μέρος αναγνωριστικής επίθεσης για την συγκέντρωση πληροφοριών για το προς επίθεση δίκτυο. -35-

36 Τα μηνύματα Address mask reply χρησιμοποιούνται για απάντηση σε μηνύματα address mask re-quest περιέχοντας την κατάλληλη subnet mask. Η δομή ενός πακέτου που περιέχει μηνύματα απάντησης μάσκας δικτύου έχει την μορφή που φαίνεται στην εικόνα Type = Code = 32bit Header checksum 0 Identifier Sequ ence numb er Address mask Εικόνα 19: Μήνυμα Address mask reply όπου: Type = 18 Code = 0 Address mask: ο αριθμός του subnet mask. -36-

37 3 SNMP Η απλότητα στο σχεδιασμό του ICMP και το γεγονός ότι οι εντολές του είναι αρκετά απλοϊκές, επιτρέπουν στο διαχειριστή ενός δικτύου να μάθει σημαντικές μεν, αλλά μόνο βασικές πληροφορίες για τις συνδέσεις των host. Για πληροφορίες υψηλότερου επιπέδου απαιτείται η χρήση ενός άλλου πρωτοκόλλου που θα μπορεί να εμβαθύνει στις συσκευές του δικτύου. Εδώ μπαίνει το SNMP που ανεβάζει το επίπεδο των πληροφοριών στις ρυθμίσεις των συσκευών. Στο κεφάλαιο αυτό θα εξεταστεί και θα αναλυθεί η λειτουργία του SNMP, για να κατανοηθεί πλήρως η σημασία του στη διαχείριση δικτύου Γενικά Ένα από τα πρώτα πρωτόκολλα που δημιουργήθηκαν και που παραμένει ακόμα σε μεγάλη χρήση ακόμα και σήμερα είναι το Simple Network Management Protocol (SNMP). Αποτελεί μέρος της ακολουθίας πρωτοκόλλων του διαδικτύου (Internet-standard protocol) και χρησιμοποιείται στη διαχείριση συσκευών IP δικτύων. Συσκευές που υποστηρίζουν το SNMP μπορεί να είναι routers, switches, servers, workstations, printers, modem racks κ.α. Χρησιμοποιείται σε συστήματα διαχείρισης δικτύου για συνεχή παρακολούθηση των συνδεδεμένων συσκευών που χρίζουν προσοχής εγγυημένης διαχείρισης. Αποτελείται από μια ομάδα προτύπων για τη διαχείριση δικτύου και περιλαμβάνει ένα πρωτόκολλο επιπέδου εφαρμογών (application layer), μια βάση δεδομένων διαχείρισης και μια ομάδα από σύνολα δεδομένων (data objects). Το SNMP ουσιαστικά αναδεικνύει δεδομένα διαχείρισης του συστήματος με την μορφή μεταβλητών του. Οι μεταβλητές αυτές περιγράφουν τις ρυθμίσεις του συστήματος και μπορούν, μετά την ανάδειξή τους από το SNMP, να επεξεργαστούν και να τροποποιηθούν από εφαρμογές διαχείρισης. Σήμερα, υπάρχουν τρεις εκδόσεις του SNMP, οι SNMP v1, SNMP v2 και SNMP v3. Οι εκδόσεις 1 και 2 έχουν πολλά κοινά χαρακτηριστικά, με την μόνη διαφορά ότι η SNMPv2 παρέχει βελτιώσεις όπως επιπρόσθετες λειτουργίες. Η SNMPv3 προσθέτει επιπλέον δυνατότητες που αφορούν την ασφάλεια και την απομακρυσμένη ρύθμιση των μεταβλητών. -37-

38 Προβλήματα ασυμβατότητας μεταξύ των τριών εκδόσεων του SNMP, λύθηκαν με το RFC Σύνοψη και βασικοί όροι Το SNMP ξεπερνάει την απλή και αρκετά δομημένη πληροφορία που συλλέγει το ICMP και στοχεύει σε πολύ εξεζητημένες πληροφορίες που αφορούν αυτές καθαυτές τις συσκευές. Λόγω της μακροχρόνιας και ευρέως διαδεδομένης χρήσης του στην διαχείριση δικτύων, κάθε συσκευή που μπορεί να συνδεθεί σε ένα δίκτυο, συμπεριλαμβανομένων των εξυπηρετητών και των εφαρμογών, έχει σχεδιαστεί για την υποστήριξή του. Υποστήριξη σημαίνει ότι η εκάστοτε συσκευή έχει σχεδιαστεί και ρυθμιστεί από προεπιλογή στο να λαμβάνει και να απαντά σε αιτήματα του SNMP μέσω του σταθμού διαχείρισης δικτύου (NMS). Σε τυπική βάση το SNMP χρησιμοποιεί ένα ή περισσότερους υπολογιστές διαχείρισης (SNMP manager) και παρακολουθεί συνεχώς ή διαχειρίζεται μια ομάδα host ή συσκευών ενός δικτύου. Κάθε διαχειριζόμενο σύστημα εκτελεί ένα λογισμικό, που όπως έχει αναφερθεί στο 2ο κεφάλαιο ονομάζεται πράκτορας (agent), και που στέλνει πληροφορίες μέσω του SNMP στον υπολογιστή διαχείρισης. Οι πληροφορίες αυτές, όπως αναφέρθηκε στην προηγούμενη υποενότητα, έχουν τη μορφή μεταβλητών. Το πρωτόκολλο επίσης επιτρέπει ενεργές διαχειριστικές διεργασίες, όπως είναι η τροποποίηση μιας ρύθμισης των συσκευών ή η δημιουργία μιας νέας. Οι αλλαγές αυτές των μεταβλητών γίνεται από απομακρυσμένη πρόσβαση. Ένα σημαντικό χαρακτηριστικό των μεταβλητών που προσπελαύνονται από το SNMP είναι η ιεραρχική τους δομή. Τόσο η ιεραρχία αυτή των μεταβλητών όσο και άλλα δεδομένα τους, όπως ο τύπος και η περιγραφή τους, περιγράφονται από την Βάση Πληροφοριών Διαχείρισης (Management information base - MIB) και ορίζονται ως αναγνωριστικά αντικειμένων (object identifiers - OID). Κάθε OID προσδιορίζει μια μεταβλητή που μπορεί να διαβαστεί ή να ρυθμιστεί από το SNMP. Το OID ουσιαστικά είναι ένα αναγνωριστικό με σημειογραφία δεκαδικής μορφής που δηλώνεται μοναδικά και χρησιμοποιείται από το SNMP, όπως μια IP διεύθυνση, για τον μοναδικό καθορισμό κάθε καταχωρητή πληροφοριών κάθε συσκευής που συνδέεται στο δίκτυο. Για παράδειγμα, για την πρόσβαση της τιμής του agentcurrentcpuutilization καταχωρητή ενός συγκεκριμένου είδους switch της Cisco, το SNMP θα διαμορφωθεί κατάλληλα για να πάρει μέσω εντολής GET την τιμή από το OID της IP διεύθυνσης του switch. -38-

39 Ένα δίκτυο διαχείρισης SNMP έχει την αρχιτεκτονική δομή που έχει περιγραφεί στο 2ο κεφάλαιο. Αυτό σημαίνει ότι αποτελεί από: τις διαχειριζόμενες συσκευές τους πράκτορες (agents) τη βάση πληροφοριών διαχείρισης (MIB), και το σταθμό διαχείρισης δικτύου (NMS), που στην προκειμένη περίπτωση είναι το λογισμικό που τρέχει στον υπολογιστή διαχείρισης 4.3. SNMP MIB & NMS Σε σχέση με το SNMP, οι λειτουργίες των MIB και NMS έχουν κάποιες ιδιαιτερότητες από ότι έχει ήδη αναφερθεί στο 2ο κεφάλαιο και για το λόγο αυτό θα αναλυθούν λίγο περισσότερο στην παρούσα υποενότητα SNMP-Compliant MIB Κάθε σταθμός διαχείρισης ή πράκτορας σε ένα δίκτυο που διαχειρίζεται μέσω SNMP διατηρεί μια τοπική βάση δεδομένων πληροφοριών σχετικές με τη διαχείριση του δικτύου, γνωστή ως βάση πληροφοριών διαχείρισης (MIB). Ο συσχετισμός μεταξύ του σταθμού διαχείρισης, του πράκτορα και της MIB φαίνεται στην εικόνα 20. Εικόνα 20: Βασική αρχιτεκτονικής SNMP -39-

40 Μια SNMP-compliant MIB περιέχει ορισμούς και πληροφορίες για τις ιδιότητες διαχείρισης πόρων και τις υπηρεσίες που υποστηρίζουν οι πράκτορες. Τα στοιχεία αυτά, όπως έχει ήδη αναφερθεί, ονομάζονται μεταβλητές. Ένας σταθμός διαχείρισης παίρνει και θέτει μεταβλητές στην MIB, ενώ ένας πράκτορας ειδοποιεί τον σταθμό διαχείρισης για τα σημαντικά αλλά αυτόκλητα γεγονότα που ονομάζονται traps. Όλα τα μηνύματα που ανταλλάσσουν ο σταθμός διαχείρισης και των πρακτόρων γίνονται μέσω του SNMP. Η MIB του σταθμού διαχείρισης περιέχει όλες τις πληροφορίες διαχείρισης δικτύου που προέρχονται από τις MIB όλων των διαχειριζόμενων οντοτήτων του δικτύου Δομή πληροφοριών της MIB Η δομή των πληροφοριών διαχείρισης (structure of management information - SMI), ένα SNMP standard που περιγράφεται στην NWG RFC 1155, ορίζει τη δομή των πληροφοριών της MIB, τους επιτρεπόμενους τύπους δεδομένων καθώς και το πώς θα παρουσιάζονται και θα ονομάζονται οι πόροι της MIB. Φιλοσοφία της SMI είναι η διασφάλιση της απλότητας και επεκτασιμότητας της MIB. Το SNMP περιέχει ένα πίνακα, γνωστό ως Abstract Syntax Notation One (ASN.1) OBJECT TYPE macro, που καθορίζει το τυπικό μοντέλο ορισμού των μεταβλητών και των πινάκων των μεταβλητών στην MIB. Μια μεταβλητή επομένως καθορίζεται συνήθως από τις εξής λέξεις κλειδιά: Σύνταξη (Syntax): Ορίζει την αφηρημένη δομή των δεδομένων που αντιστοιχούν στον τύπο της μεταβλητής. Η SMI περιορίζει εσκεμμένα τις δομές του ASN.1 για λόγους απλότητας. Πρόσβαση (Access): Ορίζει το είδος προσπέλασης μιας μεταβλητής, δηλαδή αν η μεταβλητή μπορεί απλά να ανακτηθεί χωρίς να τροποποιηθεί (read-only) ή αν μπορεί και να τροποποιηθεί (read-write). Περιγραφή (Description): Περιέχει τον ορισμό του τύπου της μεταβλητής. Ο ορισμός περιέχει όλα τα σημασιολογικά στοιχεία που βοηθούν στην ερμηνεία. Τυπικά περιέχει πληροφορίες του είδους που μπορούν να επικοινωνήσουν με οποιουσδήποτε ASN.1 σχολιασμούς σχετικούς με τη μεταβλητή. -40-

41 4.3.3 Αναγνωριστικά αντικειμένων MIB Κάθε μεταβλητή στην MIB έχει ένα αναγνωριστικό αντικειμένου (OID), τα οποία χρησιμοποιούνται από το σταθμό διαχείρισης για την αίτηση της τιμής της μεταβλητής από τον πράκτορα. Το OID είναι μια ακολουθία ακεραίων που ορίζει μοναδικά μια διαχειριζόμενη μεταβλητή μέσω του προσδιορισμού του path στο οποίο βρίσκεται η μεταβλητή. Μέσα στην MIB οι μεταβλητές είναι τοποθετημένες ιεραρχικά σε μια δομή δέντρου που ονομάζεται OID tree ή δέντρο καταχώρησης (registration tree). Όταν ο SNMP agent θέλει να προσπελάσει μια συγκεκριμένη μεταβλητή, διατρέχει το OID tree για να την βρει. Η δομή και η ιεραρχία των αναγνωριστικών αντικειμένων της MIB φαίνεται στην εικόνα 21. Εικόνα 21: Δομή και ιεραρχεία SMNP MIB OID i. Απόλυτα και Σχετικά OID Τα απόλυτα (absolute) OID προσδιορίζουν τη διαδρομή (path) από το root του δέντρου OID. Τα ονόματα των απόλυτων OID ξεκινούν πάντα με τελείες και πρέπει να καθορίζουν κάθε κόμβο του δέντρου OID, από τον πιο σημαντικό μέχρι τον τελευταίο κόμβο που βρίσκεται η μεταβλητή. Για παράδειγμα: Τα σχετικά (Relative) OID προσδιορίζουν το σχετικό path κάποιου κόμβου στο δέντρο OID. Για παράδειγμα, το προσδιορίζει την μεταβλητή sysdescr του συστήματος, σχετική με τον κόμβο Internet στο δέντρο OID. -41-

42 ii. Τρόποι καθορισμού OID Εκτός από την σειρά των ακεραίων χωρισμένους με τελείες που χρησιμοποιείται ως σημειογραφία για την περιγραφή των OID, τα OID μπορούν να οριστούν και με χρήση γραμματικών συμβόλων στη θέση των αριθμητικών για τον προσδιορισμό των κόμβων της διαδρομής μιας μεταβλητής. Άλλος ένας τρόπος είναι ο συνδυασμός χρήσης ακεραίων και γραμματικών συμβόλων. Ένα συμβολικό (symbolic) OID χρησιμοποιεί μνημονικές λέξεις κλειδιά για τον καθορισμό των μεταβλητών. Για παράδειγμα: mgmt.mib-2.system.syscontact Το επόμενο αριθμητικό (numeric) OID χρησιμοποιεί ακέραιους για τον καθορισμό μια μεταβλητής: Όπως φαίνεται από το παράδειγμα πρόκειται για ένα σχετικό OID. Ένα παράδειγμα OID που χρησιμοποιεί συνδυασμό ακεραίων και γραμματικών συμβόλων είναι το ακόλουθο: mgmt.mib-2.1.syscontact SNMP NMS Όπως είναι φανερό από την ανάλυση του MIB, η λίστα των πιθανών OID για όλες τις συσκευές σε ένα δίκτυο είναι τεράστια. Επομένως, και το NMS με τη σειρά του έχει μια μεγάλη σειρά από OID τα οποία υπάρχουν στην βάση δεδομένων του. Επιπρόσθετα OID μπορούν να κατέβουν μέσω διαδικτύου από τον προμηθευτή των συσκευών και αυτόματα να αποθηκευτούν στη βάση του σταθμού διαχείρισης δικτύου. Λόγω της υποστήριξης του SNMP από όλους σχεδόν τους κατασκευαστές συσκευών, το NMS έχει τη δυνατότητα διαχείρισης και συνεχούς παρακολούθησης κάθε είδους συσκευής και εφαρμογής που υποστηρίζει το SNMP. Το γεγονός αυτό έχει σαν αποτέλεσμα, ότι το NMS μπορεί να σχηματίσει μια ολοκληρωτική εικόνα για την εσωτερική συμπεριφορά των συσκευών του δικτύου που διαχειρίζεται. Η εικόνα αυτή περιλαμβάνει όλες τις δυνατές πληροφορίες σχετικά με την απόδοση των συσκευών που σχετίζονται με λεπτομέρειες ως προς την διαμόρφωσή τους, τα περιβαλλοντικά χαρακτηριστικά τους, καθώς και τα στατιστικά του δικτύου. Όλες αυτές οι πληροφορίες μπορούν να αποθηκευτούν για μελλοντική χρήση. Μια δεύτερη πολύ σημαντική λειτουργία ενός αποτελεσματικού NMS είναι η δημιουργία απεικονίσεων των παραπάνω δεδομένων, απεικονίσεις που είναι απίστευτα χρήσιμες τους διαχειριστές του δικτύου. Όλες αυτές οι πληροφορίες που αφορούν τις συσκευές ενός δικτύου μπορούν να ανακαλεστούν με τις SNMP εντολές GET, ενώ μπορούν να ενημερωθούν με εντολές SET. Για -42-

43 συγκεκριμένους τύπους OID, τους τύπους δηλαδή που σχετίζονται με διαμορφώσεις συσκευών, είναι δυνατή η χρήση της SET εντολής σε μια OID από απομακρισμένη απόσταση. Σε κάθε περίπτωση, είτε η απομακρισμένη πρόσβαση γίνεται από τον NMS είτε όχι, η συσκευή θα πρέπει να έχει από πριν ρυθμιστεί με ένα SNMP Community String. Το string αυτό είναι διπλό, ένα χρησιμοποιείται για την ανάγνωση των πληροφοριών και ένα δεύτερο ξεχωριστό για την ενημέρωση τους, και λειτουργεί ως κοινό μυστικό password ανάμεσα στον NMS και τη συσκευή που διαχειρίζεται. Σαν κοινό μυστικό, το string πρέπει να υπάρχει τόσο στην εκάστοτε συσκευή όσο και στον NMS πριν ξεκινήσει η επικοινωνία τους. Η διαχείριση τέτοιων Community Strings είναι ένας πονοκέφαλος για τους διαχειριστές δικτύων με χρήση SNMP, πονοκέφαλος όμως που περνάει αν ο NMS είναι πλήρως εξοπλισμένος. Οι SNMP εντολές που έχουν αναφερθεί μέχρι τώρα, είναι χρήσιμες μόνο όταν ο NMS καταγράφει κανονικά κάθε συσκευή του δικτύου. Ωστόσο, μερικές καταστάσεις μπορούν να δώσουν εντολή ότι μια συσκευή ενημερώνει μονομερώς τον NMS της σχετικά με μια συγκεκριμένη προρυθμισμένη κατάσταση. Στην περίπτωση αυτή, μια αυτοκλητη SNMP TRAP εντολή μπορεί να σταλλεί από την συσκευή προς τον NMS ενημερώνοντάς τον σχετικά με την κατάσταση που συνέβη. Τέτοιου είδους εντολή μπορεί να σχετίζεται με την τροφοδότηση ή παύση τροφοδότησης του server ή με μια προρυθμισμένη κατάσταση του δικτύου όπως μπορεί να είναι η παρουσία συμφόρησης στο ρεύμα μεταφοράς δεδομένων της συσκευής. Οι εντολές GET, SET και TRAP, θα αναλυθούν με περισσότερες λεπτομέρειες στην επόμενη υποενότητα Τεχνικές λειτουργίες Το SNMP λειτουργεί στο επίπεδο εφαρμογών της ακολουθίας πρωτοκόλλων του διαδυκτύου (επίπεδο 7 του μοντέλου OSI). Η δομή της λειτουργίας του βασίζεται στην αίτηση πληροφοριών. Για το σκοπό αυτό ο SNMP agent δέχεται αιτήματα στο UDP port 161. Ο υπολογιστής διαχείρισης μπορεί να στείλει τα αιτήματα αυτά από οποιοδήποτε διαθέσιμο πηγαίο port. Η απάντηση του πράκτορα θα καταλήξει στο ίδιο πηγαίο port του υπολογιστή διαχείρισης. Εκτός από τις πληροφορίες, με την ίδια λογική αποστέλλονται και ενημερώσεις, οι οποίες καταλήγουν στο port 162 του υπολογιστή διαχείρισης, ενώ έχουν αποσταλλεί από οποιοδήποτε διαθέσιμο port του πράκτορα (Εικ.22). -43-

44 Εικόνα 22: Διαχείριση μηνυμάτων SNMP Όταν το SNMP χρησιμοποείται με ασφάλεια επιπέδου μεταφοράς (Transport Layer Security TLS) ή ασφάλεια επιπέδου μεταφοράς πακέτων (Datagram Transport Layer Security DTLS) τότε οι αιτήσεις πληροφοριών λαμβάνονται στο port και οι ενημερώσεις στο port Η SNMPv1 ορίζει πέντε βασικές μονάδες δεδομένων του πρωτοκόλλου (protocol data units - PDU). Άλλες δύο PDU, οι GetBulkRequest και InformRequest προστέθηκαν στην SNMPv2 και μεταφέρθηκαν και στην SNMPv3. Όλες οι SNMP PDU έχουν την ακόλουθη δομή: IP UDP versio communit PDU- request- error- error- variable header header n y type id status index bindings Παρακάτω αναλύονται οι εφτά SNMP PDU: GetRequest: Είναι μια από τις βασικότερες αιτήσεις της λειτουργικής δομής του SNMP. Aποστέλλεται από τον υπολογιστή διαχείρισης προς τον πράκτορα με σκοπό την ανάκτηση της τιμής μιας μεταβλητής ή μιας λίστας μεταβλητών. Οι επιθυμητές μεταβλητές καθορίζονται στο σώμα της αίτησης με δέσμευση των μεταβλητών και όχι των τιμών τους. Ακολουθείται από τον τύπο της διεύθυνσης της επιθυμητής πληροφορίας. Μετά την αποστολή της αίτησης αυτής η ανάκτηση των τιμών τωνεπιθυμητών μεταβλητών είναι αποκλειστική δουλειά των agent. Μια τέτοια εντολή έχει ως επιστροφή μια απάντηση (Response) με την τιμή που έχει η μεταβλητή την ώρα της αίτησης. -44-

45 SetRequest: Aποστέλλεται από τον υπολογιστή διαχείρισης προς τον πράκτορα με σκοπό τη ρύθμιση της τιμής μιας μεταβλητής ή μιας λίστας μεταβλητών. Οι δεσμεύσεις των μεταβλητών καθορίζονται στο σώμα της αίτησης. Οι ρυθμίσεις των τιμών των μεταβλητών γίνεται από τους πράκτορες. Μια τέτοια εντολή έχει ως επιστροφή μια απάντηση με την νέα τιμή που έχει η μεταβλητή. GetNextRequest: Aποστέλλεται από τον υπολογιστή διαχείρισης προς τον πράκτορα με σκοπό την ανέυρεση διαθέσιμων μεταβλητών και των τιμών τους. Μια τέτοια εντολή έχει επιστροφή μια απάντηση με δέσμευση μεταβλητής για την λεξικογραφική διάταξη της μεταβλητής στην MIB. Ολόκληρη η MIB ενός πράκτορα μπορεί να προσπελαστεί με συνεχή εκτέλεση της εφαρμογής GetNextRequest, ξεκινώντας από το OID 0. GetBulkRequest: Αποτελεί βελτιωμένη έκδοση της GetNextRequest και προστέθηκε στην SNMPv2. Αποστέλλεται από τον υπολογιστή διαχείρισης προς τον πράκτορα με σκοπό την πολλαπλή επανάληψη της GetNextRequest. Με τον τρόπο αυτό είναι δυνατή η μεταφορά ακόμα και ολόκληρων πινάκων με δεδομένα. Μια τέτοια εντολή έχει ως επιστροφή πολλών δεσμεύσεων μεταβλητών. Η συγκεκριμένη PDU περιέχει και δύο συγκεκριμένα πεδία ( non-repeaters και max-repetitions) για τον έλεγχο της απάντησης. Response: Επιστρέφει δεσμεύσεις μεταβλητών και επιβεβαίωση λήψης και αποστέλλεται από τον πράκτορα προς τον υπολογιστή διαχείρισης σαν απάντηση στις GetRequest, SetRequest, GetNextRequest, GetBulkRequest και InformRequest. Σε περίπτωση σφάλματος, αυτό υποδεικνύεται μέσω των πεδίων error-status και errorindex που περιέχει. Αν και χρησιμοποιήθηκε σαν απάντηση σε get και set PDU, η Response ονομαζόταν GetResponse στην SNMPv1. Trap: Αποτελεί μια ασύγχρονη ενημέρωση που αποστέλλεται από τον πράκτορα προς τον υπολογιστή διαχείρισης. Τα SNMP traps ενεργοποιούν ένα πράκτορα ώστε να ενημερώσει το κέντρο διαχείρισης για σημαντικά γεγονότα του δικτύου μέσω αυτόκλητων μηνυμάτων SNMP. Περιλαμβάνει την ισχύουσα τιμή του sysuptime, ένα OID που δείχνει τον τύπο του trap και προαιρετικές δεσμεύσεις μεταβλητών. Η διεύθυνση προορισμού των trap καθορίζεται με ένα τρόπο ιδιαίτερης εφαρμογής μέσω μεταβλητών ρύθμισης των trap στην MIB. Η μορφή του μηνύματος trap άλλαξε στην SNMPv2 και η PDU μετονομάστηκε σε SNMPv2-Trap. -45-

46 Ενώ στις κλασσικές επικοινωνίες ο χρήστης πάντα αιτείται ενεργά πληροφορίες από τον εξυπηρετητή, το SNMP επιτρέπει την επιπρόσθετη λειτουργία αυτών που ονομάζονται traps. Πρόκειται για πακέτα δεδομένων που στέλνονται από τον SNMP χρήστη στον εξυπηρετητή χωρίς προηγούμενη ρητή αίτηση. InformRequest: Αποτελεί μια ασύγχρονη ενημέρωση επιβεβαίωσης λήψης που εισήχθη στην SNMPv2 και αρχικά ορίστηκε ως επικοινωνία μεταξύ υπολογιστών διαχείρισης και αργότερα επιτράπηκε και σε επικοινωνίες πρακτόρων με υπολογιστές διαχείρισης. Οι ενημερώσεις μεταξύ υπολογιστών διαχείρισης ήταν ήδη δυνατές από την SNMPv1, με χρήση της Trap, όμως από τη στιγμή που το SNMP ουσιαστικά τρέχει πάνω από το UDP όπου η μεταφορά δεν είναι εξασφαλισμένη και δεν γίνεται αναφορά για την απόρριψη πακέτων, η μεταφορά μιας Trap δεν ήταν εγγυημένη. Η InformRequest λύνει αυτό το πρόβλημα με αποστολή ενημέρωσης επιβεβαίσης λήψης την στιγμή της λήψης ενός αιτήματος Δομή και εκδόσεις του SNMP Όπως έχει ήδη αναφερθεί το SNMP είναι ένα πρωτόκολλο επιπέδου εφαρμογών που ενθυλακώνεται στο UDP. Η γενική δομή των SNMP μηνυμάτων για όλες τις εκδόσεις του φαίνεται στην εικόνα 23: Εικόνα 23: Γενική δομή SNMP μηνυμάτων -46-

47 όπου: Version είναι ο αριθμός της έκδοσης του SNMP. Τόσο ο υπολογιστής διαχείρισης όσο και ο πράκτορας θα πρέπει να χρησιμοποιούν την ίδια έκδοση του SNMP. Μηνύματα που περιέχουν διαφορετικούς αριθμούς έκδοσης απορρίπτονται χωρίς περαιτέρω επεξεργασία Κοινότητα (Community). Το όνομα της κοινότητας χρησιμοποιείται για να πιστοποιηθεί ο υπολογιστής διαχείρισης και να αποκτήσει άδεια πρόσβασης στο πράκτορα. Ο τύπος και η δομή της PDU για τις εκδόσεις SNMPv1, v2 και v3 θα εξηγηθούν στις αντίστοιχες υποενότητες SNMPv1 Το SNMPv1 είναι ένα απλό πρωτόκολλο αίτησης/απάντησης. Το σύστημα διαχείρισης δικτύου εκπέμπει ένα αίτημα και οι προς διαχείριση συσκευές απαντούν. Αυτού του είδους η επικοινωνία υλοποιείται με χρήση μιας από τις τέσσερις λειτουργίες του πρωτοκόλλου: Get, GetNext, Set, και Trap. Η λειτουργία Get χρησιμοποιείται από το NMS για την ανάκτηση της τιμής μίας ή περισσότερων μεταβλητών από έναν πράκτορα. Αν ο πράκτορας, που απαντάει στην αίτηση αυτή, δεν μπορεί να δώσει τιμές για όλες τις μεταβλητές που υπάρχουν στην λίστα αίτησης, τότε δεν δίνει καμία τιμή. Η λειτουργία GetNext χρησιμοποιείται από το NMS για την ανάκτηση της τιμής της επόμενης μεταβλητής ενός πίνακα ή μιας λίστας του πράκτορα. Η λειτουργία Set χρησιμοποιείται από το NMS για τον ορισμό τιμών μεταβλητών που βρίσκονται σε ένα πράκτορα. Η λειτουργία Trap χρησιμοποιείται από τους πράκτορες για ασύγχρονη ενημέρωση του NMS σχετικά με ένα σημαντικό γεγονός που συνέβη στο δίκτυο. Η δομή της πρώτης έκδοσης του πρωτοκόλλου δεν διαφέρει από αυτή της εικόνας 24. Οι τύποι των PDU της έκδοσης αυτής είναι οι εξής πέντε: GetRequest, GetNextRequest, GetResponse, SetRequest, και Trap. Η δομή των GetRequest, GetNextRequest, GetResponse και SetRequest είναι η ακόλουθη: -47-

48 Εικόνα 24: Δομή PDU SNMPv1 όπου: PDU type: Είναι ο τύπος της PDU που εκπέμπεται και παίρνει τις τιμές: 0 GetRequest 1 GetNextRequest 2 GetResponse 3 SetRequest Request ID: Σχετίζει τα SNMP αιτήματα με τις απαντήσεις Error status: Υποδεικνύει ένα από τους αριθμούς των σφαλμάτων και τα είδη αυτών. Παίρνει τιμές μόνο κατά την απάντηση ενός αιτήματος, ενώ σε όλες τις άλλες λειτουργίες η τιμή του είναι μηδέν. Error index: Σχετίζει ένα σφάλμα με μια συγκεκριμένη στιγμή μιας μεταβλητής. Παίρνει τιμές μόνο κατά την απάντηση ενός αιτήματος, ενώ σε όλες τις άλλες λειτουργίες η τιμή του είναι μηδέν. Variable bindings: Εξυπηρετεί ως το πεδίο των δεδομένων της SNMPv1 PDU. Κάθε δέσμευση μεταβλητής σχετίζει μια συγκεκριμένη στιγμή της μεταβλητής με την ισχύουσα τιμή της (με εξαίρεση των Get και GetNext αιτημάτων, για τα οποία η τιμή αγνοείται). Η δομή της Trap PDU είναι η ακόλουθη (Εικ.25): -48-

49 Εικόνα 25: Δομή SNMPv1 Trap όπου: PDU type: Είναι ο τύπος της PDU (4 για την Trap) Enterprise: Προσδιορίζει τον τύπο της μεταβλητή που δημιούργησε το Trap Agent address: Είναι η IP διεύθυνση του πράκτορα που δημιούργησε το Trap Generic trap type: Πεδίο στο οποίο περιγράφεται το γεγονός που αναφέρεται Specific trap type: Χρησιμοποιείται για τον προσδιορισμό της δημιουργίας ενός μηgeneric trap Timestamp: Είναι η τιμή της μεταβλητής sysuptime, που προσδιορίζει το χρόνο που πέρασε ανάμεσα στην τελευταία αρχικοποίηση των παραμέτρων και την δημιουργία του Trap SNMPv2 Η δεύτερη έκδοση του SNMP (SNMPv2) είναι μια εξέλιξη της SNMPv1. Οι λειτουργίες Get, GetNext και Set που χρησιμοποιούνται στην SNMPv1 είναι ακριβώς οι ίδιες μ αυτές της SNMPv2. Παρ όλα αυτά, η έκδοση SNMPv2 προσθέτει και ενισχύει κάποιες λειτουργίες του πρωτοκόλλου. Για παράδειγμα, η λειτουργία SNMPv2 Trap operation, ναι μεν λειτουργεί -49-

50 όπως στην SNMPv1 όμως έχει διαφορετική δομή μηνύματος και σχεδιάστηκε για να αντικαταστήσει την SNMPv1 Trap. Η έκδοση SNMPv2 επίσης προσθέτει δύο νέες λειτουργίες, τις GetBulk και Inform. Η λειτουργία GetBulk χρησιμοποιείται από τον NMS για την ανάκτηση μεγάλων μπλοκ δεδομένων όπως είναι οι γραμμές ενός πίνακα. Η GetBulk γεμίζει ένα μήνυμα απάντησης με όσα από τα αιτούμενα δεδομένα αυτό χωράει. Η λειτουργία Inform επιτρέπει σε ένα NMS να στείλει πληροφορία trap σε ένα άλλο NMS και μετά να δεκτεί μια απάντηση. Στην έκδοση SNMPv2, αν ο πράκτορας που απαντάει σε λειτουργία GetBulk δεν μπορεί να δώσει τιμές για όλες τις μεταβλητές της λίστας αίτησης, τότε στέλνει μερικά αποτελέσματα. Η δομή της δεύτερης έκδοσης του πρωτοκόλλου δεν διαφέρει από αυτή της εικόνας 26. Η δομή των Get, GetNext, Inform, Response, Set και Trap PDU είναι η ακόλουθη: Εικόνα 26: Δομή PDU SNMPv2 όπου: PDU type: Προσδιορίζει τον τύπο της PDU που αποστέλλεται (Get, GetNext, Inform, Response, Set, ή Trap) Request ID: Σχετίζει τα SNMP αιτήματα με τις απαντήσεις Error status: Υποδεικνύει ένα από τους αριθμούς των σφαλμάτων και τα είδη αυτών. Παίρνει τιμές μόνο κατά την απάντηση ενός αιτήματος, ενώ σε όλες τις άλλες λειτουργίες η τιμή του είναι μηδέν Error index: Σχετίζει ένα σφάλμα με μια συγκεκριμένη στιγμή μιας μεταβλητής. Παίρνει τιμές μόνο κατά την απάντηση ενός αιτήματος, ενώ σε όλες τις άλλες λειτουργίες η τιμή του είναι μηδέν -50-

51 Variable bindings: Εξυπηρετεί ως πεδίο δεδομένων (τιμή 1, τιμη 2 ) της SNMPv2 PDU. Κάθε δέσμευση μεταβλητής σχετίζει μια συγκεκριμένη στιγμή της μεταβλητής με την ισχύουσα τιμή της (με εξαίρεση των Get και GetNext αιτημάτων, για τα οποία η τιμή αγνοείται). Η δομή της SNMPv2 GetBulk PDU είναι η ακόλουθη (Εικ.27): Εικόνα 27: Δομή SNMPv2 GetBulkRequest όπου: PDU type: Προσδιορίζει την PDU σαν λειτουργία GetBulk Request ID: Σχετίζει τα SNMP αιτήματα με τις απαντήσεις Non repeaters: Καθορίζει τον αριθμό των στιγμών των μεταβλητών στο πεδίο δέσμευσης μεταβλητών που θα πρέπει να ανακτηθεί μόνο μια φορά από την έναρξη της αίτησης. Το πεδίο αυτό χρησιμοποιείται όταν κάποιες από τις στιγμές είναι βαθμωτές μεταβλητές με μια μόνο τιμή Max repetitions: Ορίζει τον μέγιστο αριθμό ανάκτησης των μεταβλητών πλην αυτών που ορίζονται στο πεδίο Non repeaters Variable bindings: Εξυπηρετεί ως πεδίο δεδομένων (τιμή 1, τιμη 2 ) της SNMPv2 PDU. Κάθε δέσμευση μεταβλητής σχετίζει μια συγκεκριμένη στιγμή της μεταβλητής με την ισχύουσα τιμή της (με εξαίρεση των Get και GetNext αιτημάτων, για τα οποία η τιμή αγνοείται). -51-

52 4.5.3 Η τρίτη SNMPv3 έκδοση του SNMP (SNMPv3) προσθέτει δυνατότητες ασφάλειας και απομακρυσμένης ρύθμισης στις λειτουργίες των προηγούμενων εκδόσεων. Η αρχιτεκτονική του SNMPv3 εισαγάγει το μοντέλο ασφάλειας χρήστη (User-based Security Model - USM) για ασφάλεια μηνυμάτων και το View-based Access Control Model (VACM) για έλεγχο πρόσβασης. Μια τέτοια αρχιτεκτονική υποστηρίζει την ταυτόχρονη χρήση των μοντέλων διαφορετικής ασφάλειας, ελέγχου πρόσβασης και επεξεργασίας μηνυμάτων. Η SNMPv3 επίσης εισαγάγει την δυνατότητα της δυναμικής ρύθμισης του SNMP agent με χρήση των SNMP SET εντολών στις μεταβλητές της MIB που ανταποκρίνονται στις ρυθμίσεις του πράκτορα. Αυτή η δυναμική ρύθμιση υποστηρίζει την τοπική ή απομακρισμένη πρόσθεση, διαγραφή και τροποποίηση των οντοτήτων ρύθμισης. Η δομή ενός μηνύματος της SNMPv3 έκδοσης είναι η εξής (Εικ. 28): Εικόνα 28: Δομή μηνύματος SNMPv3 με USM -52-

53 όπου: Version: snmv3(3) ID: Ένας μοναδικός αριθμός αναγνώρισης που χρησιμοποιείται μεταξύ δύο SNMP οντοτήτων για τον συντονισμό των μηνυμάτων αίτησης και απάντησης Msg Size: Μέγιστο μέγεθος μηνύματος σε οκτάδες bit που υποστηρίζεται από τον αποστολέα του μηνύματος Msg Flags: Ένα string 8 bit που περιέχει 3 flag στα 3 bit μικρότερης αξίας: reportableflag, privflag και authflag Security Model: Αριθμός αναγνώρισης του μοντέλου ασφάλειας που χρησιμοποιήθηκε από τον αποστολέα. Αυτό σημαίνει ότι και ο παραλήπτης του μηνύματος θα πρέπει να χρησιμοποιήσει το ίδιο μοντέλο ασφάλειας για να επεξεργαστεί το μήνυμα που έλαβε AuthoritativeEngineID: Είναι ο snmpengineid της authoritative SNMP engine που εμπλέκεται στην ανταλλαγή του μυνήματος αυτού. Με άλλα λόγια είναι ο μοναδικός αριθμός αναγνώρισης που αντιστοιχεί στην πηγή των Trap, Response, ή Report και στον προορισμό των Get, GetNext, GetBulk, Set, ή Inform AuthoritativeEngineBoots: Είναι η snmpengineboots τιμή της authoritative SNMP engine που εμπλέκεται στην ανταλλαγή του μηνύματος αυτού AuthoritativeEngineTime: Είναι η snmpenginetime τιμή της authoritative SNMP engine που εμπλέκεται στην ανταλλαγή του μηνύματος αυτού User Name: Είναι το όνομα του κυρίως χρήστη για λογαριασμό του οποίου ανταλλάσσεται το μήνυμα αυτό AuthenticationParameters: Είναι η παράμετρος της πιστοποίησης. Έχει τιμή Null αν κατά την ανταλλαγή του μηνύματος αυτού δεν έχει γίνει πιστοποίηση PrivacyParameters: Είναι η παράμετρος της απομόνωσης. Έχει τιμή Null αν κατά την ανταλλαγή αυτού του μηνύματος δεν έχει γίνει απομόνωση PDU (Protocol Data Unit): Οι τύποι των PDU της SNMPv3 είναι οι ίδιοι με εκείνους της SNMPv

54 4.6. SNMP και Ασφάλεια Το SNMP είναι μια ενωποιημένη λύση ανάκτησης και ενημέρωσης δεδομένων τόσο των συσκευών όσο και των εφαρμογών ενός δικτύου, επομένως μεγάλη προσοχή θα πρέπει να δίνεται κατά την εκτέλεσή του. Η σωστή ασφάλεια του SNMP είναι πολλή σημαντική. Τέτοιου είδους ασφάλεια μπορεί να πραγματοποιηθεί μέσω μιας μεγάλης κλίμακας τακτικών, όπως η χρήση λίστας πρόσβασης στα firewalls για την απομόνωση της SNMP κυκλοφορίας κάτι που θα διασφαλίσει την χρήση των Community String στην πρόληψη κατά της πειρατείας (hacking) και την αύξηση της απόδοσης των μεθόδων μυστικότητας (privacy) και κωδικοποίσης (encryption) που είναι διαθέσιμες στην SNMP v3. Αντίθετα με την τρίτη έκδοση, οι SNMPv1 και 2c υπόκεινται σε επιθέσεις packet sniffing του κειμένου των Community String της κυκλοφορίας του δικτύου, επειδή δεν μπορούν να υποστηρίξουν την κωδικοποίηση. Άλλος τρόπος ασφάλειας είναι η χρήση απομονωμένων VLAN διαχείρισης αποκλειστικά για την SNMP επικοινωνία. Όλοι αυτοί οι τρόποι ασφαλίζουν κατά μεγάλο βαθμό το SNMP από την πιθανότητα εξωτερικών επιθέσεων. Παρ όλα αυτά το SNMP, αντιμετωπίζει θέματα ασφάλειας που μπορούν να συνοψισθούν ως ακολούθως: Όλες οι εκδόσεις του SNMP υπόκεινται σε επιθέσεις brute force και dictionary με σκοπό την υποκλοπή των Community String, των Authentication String και των Encryption Strings, καθώς επίσης των Authentication Keys και των Encryption Keys, επειδή δεν υποστηρίζουν την επικοινωνία πρόκλησης απάντησης (challengeresponse handshake) Αν και το SNMP τρέχει πάνω από το TCP και άλλα πρωτόκολλα, η πιο κοινή του χρήση είναι πάνω από το UDP, το οποίο είναι ευάλωτο σε επιθέσεις IP spoofing. Επομένως, όλες οι εκδόσεις υπόκεινται σε κίνδυνο παράκαμψης των λιστών πρόσβασης συσκευών. Όπως αναφέρθηκε παραπάνω ο τρόπος αντιμετώπισης αυτού του κινδύνου είναι η χρήση απομονωμένων VLAN διαχείρισης αποκλειστικά για την SNMP επικοινωνία, τουλάχιστον για τις δύο πρώτες εκδόσεις αφού η SNMPv3 υποστηρίζει μηχανισμούς ασφαλείας που αποτρέπουν τις επιτυχημένες επιθέσεις Οι ισχυρές δυνατότητες του SNMP στην ρύθμιση των παραμέτρων στων συσκευών δεν αξιοποιούνται πλήρως από όλους τους κατασκευαστές, εν μέρη λόγω της έλλειψης μηαχανισμών ασφαλείας, πριν την SNMPv3, και εν μέρη λόγω της -54-

55 αδυναμίας παραμετροποίησης πολλών συσκευών από τις αλλαγές των μεταβλητών των MIB. -55-

56 5. Τα Πρωτόκολλα Διαχείρισης των Windows Η επιτυχημένη συνεχής παρακολούθηση και διαχείριση των δικτύων που βασίζονται στο λειτουργικό σύστημα (Operating System OS) των Windows απαιτούν κάτι περισσότερο από τα ICMP και SNMP. Τα δίκτυα αυτά διαχειρίζονται καλύτερα με πρωτόκολλα σχεδιασμένα αποκλειστικά για την φιλοσοφία των Windows. Στο κεφάλαιο αυτό θα αναλυθεί και εξεταστεί η λειτουργία των πρωτοκόλλων διαχείρισης των Windows με σκοπό την κατανόηση των πλεονεκτημάτων τους σε σχέση με τα ICMP και SNMP, όσον αφορά τα Windows-based δίκτυα Γενικά Τα πρωτόκολλα διαχείρισης των Windows βρίσκονται ψηλά στην IP στοίβα του επιπέδου εφαρμογών και με βάση το σχεδιασμό τους εξαρτώνται από άλλα που βρίσκονται χαμηλότερα για την υποστήριξη της δρομολόγησης (routing) και της μεταγωγής (switching). Χρησιμοποιούνται για εφαρμογές όπως το DNS, το διαδίκτυο, το FTP και την αποστολή mail. Από τα παραπάνω γίνεται κατανοητό ότι η διαχείριση ενός δικτύου με Windows OS γίνεται μέσω μιας ακολουθίας πρωτοκόλλων του επιπέδου εφαρμογών που σχεδιάστηκαν για την επικοινωνία των Windows server και των Windows OS τερματικών. Τοποθετημένα πάνω από τα TCP και UDP, τα πρωτόκολλα αυτά επιτρέπουν την καλύτερη παροχή υπηρεσιών από τους εξυπηρετητές σε όλο το μήκος ενός IP δικτύου. Δύο παραδείγματα τέτοιου είδους πρωτοκόλλων είναι το πρωτόκολλο Κλήσης Απομακρυσμένης Διαδικασίας (Remote Procedure Call - RPC), που χρησιμοποιείται από τα Windows για ενδοεπικοινωνιακές διεργασίες και το πρωτόκολλο Απομακρυσμένης Επιφάνειας Εργασίας (Remote Desktop Protocol - RDP), που χρησιμοποιείται για μεταφορά πληροφοριών απεικόνισης και ελέγχου μεταξύ server και client. Άλλα πρωτόκολλα που χρησιμοποιούνται από το Windows OS περιλαμβάνουν το Φίλτρο Οργάνων Διαχείρισης των Windows (Windows Management -56-

57 Instrumentation - WMI) καθώς και το πρωτόκολλο Διαχείρισης Υπηρεσιών Διαδικτύου (WS Management). Η αναφορά αυτών των OS σχεδιασμένων πρωτοκόλλων είναι αξιοσημείωτη λόγω των πληροφοριών που μπορούν να παρέχουν στον διαχειριστή ενός δικτύου. Πρωτόκολλα όπως τα ICMP και SNMP, που περιγράφηκαν στα προηγούμενα κεφάλαια, μπορούν, λόγω του σχεδιασμού τους, να παρέχουν μόνο συγκεκριμένου είδους μετρήσεις στους διαχειριστές δικτύων. Αν και το SNMP μπορεί να επεκταθεί για να υποστηρίξει την αποθήκευση σχεδόν κάθε σημείου δεδομένων, αυτή η επέκταση θα πρέπει πρώτα να διαμορφωθεί σε κάθε λειτουργικό σύστημα ή εφαρμογή. Τέτοιες επεκτάσεις του SNMP δεν έχουν αναληφθεί για μεγάλο μέρος των δεδομένων που αφορούν το σύστημα αυτό καθαυτό, κάτι που είναι απαραίτητο για την πραγματικά ολιστική διαχείριση. Από την άλλη μεριά, η Microsoft έχει καταβάλει μεγάλες προσπάθειες στη διαχείριση τέτοιων συστημάτων και με τον σχεδιασμό του WMI υποστηρίζει τα OS και της εφαρμογές της. Έτσι, η συνεχής παρακολούθηση σε βάθος που δεν θα μπορούσε να γίνει με τα ICMP ή SNMP γίνεται υλοποιήσιμη με την χρήση του WMI. Το αποτέλεσμα είναι ότι κάθε λύση δικτυακής διαχείρισης που πραγματοποιείται μέσω του Windows OS και των εφαρμογών του θα πρέπει επιπρόσθετα να υποστηρίζει και τα πρωτόκολλα αυτά RPC Η Κλήση Απομακρυσμένης Διαδικασίας (RPC) καλύπτει τα επίπεδα μεταφοράς και εφαρμογών του μοντέλου Open Systems Interconnection (OSI) των δικτυακών επικοινωνιών και διευκολύνει την ανάπτυξη εφαρμογών που περιλαμβάνουν πληθώρα κατανεμημένων προγραμμάτων σε ένα δίκτυο. Το RPC είναι ένα πρωτόκολλο που ένα πρόγραμμα μπορεί να χρησιμοποιήσει για να αιτηθεί μια υπηρεσία ενός άλλου προγράμματος που τρέχει σε άλλο υπολογιστή ενός δικτύου χωρίς να πρέπει να γνωρίζει τις φυσικές και λογικές λεπτομέρειες της επικοινωνίας δεδομένων του δικτύου. Το RPC χρησιμοποιεί το μοντέλο client/server. Το πρόγραμμα που κάνει την αίτηση είναι ο client, ενώ το πρόγραμμα που θα παρέχει τις υπηρεσίες του είναι ο -57-

58 server. Όπως συμβαίνει και στις συμβατικές ή τοπικές διεργασίες ενός υπολογιστή, το RPC είναι μια σύγχρονη λειτουργία που απαιτεί την προσωρινή παύση της λειτουργίας του αιτούμενου προγράμματος μέχρι την επιστροφή των αποτελεσμάτων της απομακρυσμένης διεργασίας. Παρ όλα αυτά, η χρήση ελαφρών διεργασιών ή threads που μοιράζονται την ίδια διεύθυνση επιτρέπει την ταυτόχρονη λειτουργία πολλών RPC. Υπάρχουν πολλά μοντέλα και εφαρμογές RPC. Το πιο δημοφιλές μοντέλο και εφαρμογή είναι το Κατανεμημένο Υπολογιστικό Περιβάλλον Distributed Computing Environment (DCE). Το RPC των Windows είναι μια τροποποιημένη έκδοση του DCE/RPC. Το RPC των Windows (Microsoft RPC MSRPC) υποστηρίζει Unicode strings και πολύπλοκους υπολογισμούς των string μεταβλητού μήκους και των δομών παραδειγμάτων που υπάρχουν ήδη στο DCE/RPC Το MSRPC To MSRPC είναι ένας μηχανισμός ενδοεπικοινωνιακών διεργασιών που υποστηρίζει την μεταφορά δεδομένων και την ενεργοποίηση της λειτουργίας διαφορετικών εφαρμογών, που μπορεί να βρίσκονται στον ίδιο υπολογιστή ή σε απομακρυσμένους υπολογιστές ενός δικτύου (LAN), ή ακόμα να συνδέονται μέσω του διαδικτύου. Ο μηχανισμός του MSRPC των Windows χρησιμοποιεί άλλους μηχανισμούς ενδοεπικοινωνιακών διεργασιών όπως τις επώνυμες διοχετεύσεις (named pipes), το NetBIOS, ή το Winsock, προκειμένου να δημιουργήσει την επικοινωνία μεταξύ client και server. Με την χρήση του MSRPC, η βασική λογική του προγράμματος και ο σχετικός κώδικας επεξεργασίας μπορούν να βρίσκονται σε διαφορετικούς υπολογιστές, πράγμα πολύ σημαντικό για τις κατανεμημένες εφαρμογές Αρχιτεκτονική δομή του MSRPC Η φιλοσοφία της αρχιτεκτονικής του MSRPC είναι να διευκολύνει τις διεργασίες της επικοινωνίας μεταξύ client και server. Για το σκοπό αυτό έχουν αντικατασταθεί τόσο τα αποκλειστικά πρωτόκολλα όσο και οι μέθοδοι επικοινωνίας με μία ισχυρή και τυποποιημένη διεπαφή (interface). Οι λειτουργίες που περιέχει το MSRPC είναι προσβάσιμες από οποιοδήποτε πρόγραμμα, το οποίο πρέπει να χρησιμοποιεί την μεθοδολογία client/server σαν επικοινωνία. Η εικόνα 29 δείχνει μια τέτοια αρχιτεκτονική. -58-

59 Εικόνα 29: Αρχιτεκτονική δομή MSRPC Στον επόμενο πίνακα φαίνονται τα στοιχεία και οι λειτουργίες τους στην αρχιτεκτονική δομή του MSRPC. Στοιχείο Client or server process RPC stubs Περιγραφή Πρόγραμμα ή υπηρεσία που ξεκινάει μια αίτηση RPC ή απαντάει σε αυτή Υποσυστήματα προγράμματος που χρησιμοποιούνται από τον client ή τον server για την έναρξη μιας αίτησης RPC Marshalling engine Παρέχει μια RPC διεπαφή ανάμεσα στους RPC client και server (NDR20 (NDR20 or για 32-bit αρχιτεκτονική και NDR64 για 64-bit αρχιτεκτονική) NDR64) Παρέχει μια άμεση RPC διεπαφή στους client ή server. Οι RPC client και server την καλούν για την αρχικοποίηση (initialize) του RPC και την Runtime προετοιμασία της δομής των δεδομένων που χρησιμοποιούνται στην application δημιουργία των RPC κλήσεων. Το API layer καθορίζει επίσης αν η αίτηση programming RPC έρχεται από μια μηχανή marshalling ή από ένα client ή server και interface (API) πηγαίνει σε τοπικό ή απομακρυσμένο server. Μετά τον καθορισμό αυτό, το API layer δρομολογεί το RPC στα Connection RPC, Datagram RPC, ή Local RPC layers Connection Χρησιμοποιείται όταν το RPC χρειάζεται ένα επικοινωνιακοστρεφές RPC protocol πρωτόκολλο. Το layer προσδιορίζει το είδος του επικοινωνιακοστρεφούς -59-

60 engine πρωτοκόλλου ανάλογα με το αν το RPC πρόκειται να στείλει ή να λάβει προς ή από το πρωτόκολλο αυτό Χρησιμοποιείται όταν το RPC χρειάζεται ένα μη επικοινωνιακό Datagram RPC πρωτόκολλο. Το layer αυτό προσδιορίζει το είδος του μη επικοινωνιακού protocol engine πρωτοκόλλου ανάλογα με το αν το RPC πρόκειται να στείλει ή να λάβει προς ή από το πρωτόκολλο αυτό Local RPC protocol engine Χρησιμοποιείται όταν ο server και ο client βρίσκονται στον ίδιο host Γίνεται πρόσβαση με το πρώτο φόρτωμα της υπηρεσίας RPC. Τα Registry keys καθορίζουν το εύρος των IP port καθώς και τα ονόματα των Registry συσκευών του δικτύου στα οποία θα γίνει χρήση του RPC. Δεν χρησιμοποιείται σε κανονικές λειτουργίες του RPC, εκτός κι αν το αντίθετο οριστεί από το API Το kernel32.dll είναι ένα Windows NT API dynamic-link library (DLL) αρχείο που παρέχει υπηρεσίες διαχείρισης threads, μνήμης και πηγών στο Win32 APIs σύστημα (kernel32.dll, Το advapi32.dll είναι ένα αναβαθμισμένο Windows 32 base API DLL advapi32.dll, αρχείο και λειτουργεί ως API βιβλιοθήκη υπηρεσιών που υποστηρίζει ntdll.dll) ασφάλεια και καταχώρηση κλήσεων Το ntdll.dll είναι ένα NT layer DLL αρχείο που ελέγχει τις λειτουργίες του συστήματος Windows NT SSPI (secur32.dll) Παρέχει την διεπαφή ασφάλειας του RPC. Διαπραγματεύεται την χρήση των Kerberos, NTLM, ή Secure Sockets Layer (SSL) για authentication και encryption Το rpcss.dll βασικά παρέχει την υποδομή του COM, αλλά ένα μέρος του Endpoint Mapper (EPM) (rpcss.dll) χρησιμοποιείται για το EPM. Ένας RPC server επικοινωνεί με το EPM για να λάβει τα δυναμικά endpoint και να τα καταχωρήσει στην βάση δεδομένων του EPM. Οι RPC client επικοινωνούν με το EPM για να διακρίνουν τα endpoint στην περίπτωση που συνδέονται με ένα άγνωστο RPC server endpoint Active Χρησιμοποιείται στην διεργασία του RPC client μόνο όταν η διεπαφή Directory ασφαλείας έχει καθορίσει το Kerberos ή το Negotiate σαν μηχανισμούς -60-

61 ασφαλείας ή όταν ο server χρησιμοποιεί το NTLM σαν μηχανισμό ασφαλείας Network stack Kernel Χρησιμοποιείται για το πέρασμα των RPC αιτημάτων και απαντήσεων μεταξύ ενός client και ενός απομακρυσμένου server Χρησιμοποιείται για το πέρασμα των RPC αιτημάτων και απαντήσεων μεταξύ ενός client και του τοπικού server Διεργασία MSRPC Τα στοιχεία του MSRPC δίνουν την ευχέρεια στους client να καλέσουν μια διεργασία που είναι εγκατεστημένη σε ένα απομακρυσμένο πρόγραμμα στον server. Με τους client και server να έχουν ο καθένας τον δικό του χώρο διευθύνσεων, δίνεται η δυνατότητα στην διεργασία να αξιοποιήσει όσους πόρους δεδομένων χρειάζεται. Στην εικόνα 30 παρουσιάζεται η λειτουργία της διεργασίας MSRPC. Εικόνα 30: Διεργασία RPC Η διεργασία ξεκινάει στη μεριά του client. Η εφαρμογή του client καλεί την τοπική διαδικασία στελέχους (stub procedure) αντί να την εκτελέσει. Τα στελέχη μεταγλωττίζονται και συνδέονται με την εφαρμογή του client κατά τη διάρκεια της ανάπτυξης. Αντί να περιέχει κώδικα που θα υλοποιεί την απομακρυσμένη διαδικασία, ο κώδικας του στελέχους του client αντλεί τις απαιτούμενες παραμέτρους από τον χώρο διευθύνσεων του client και τις παραδίδει στην βιβλιοθήκη χρόνου εκτέλεσης (runtime library) του client. Εκεί, οι παράμετροι παίρνουν την μορφή που πρέπει να έχουν σύμφωνα με το Network Data Representation (NDR) standard για μεταφορά τους στον server. -61-

62 Το στέλεχος του client καλεί λειτουργίες της βιβλιοθήκης χρόνου εκτέλεσης του RPC (rpcrt4.dll) για να στείλει την αίτηση και της παραμέτρους στον server. Αν ο server βρίσκεται στον ίδιο υπολογιστή με τον client, η βιβλιοθήκη χρόνου εκτέλεσης μπορεί να χρησιμοποιήσει την λειτουργία τοπικού RPC (LRPC) και περνάει την αίτηση RPC στον kernel των Windows για μεταφορά δεδομένων προς τον server. Αν ο server βρίσκεται σε απομακρυσμένο host, η βιβλιοθήκη χρόνου εκτέλεσης καθορίζει την κατάλληλη μηχανή του πρωτοκόλλου μέσω του οποίου θα γίνει μεταφορά δεδομένων και περνάει το RPC στη στοιβάδα δικτύου για να γίνει η μεταφορά προς τον server. Το RPC μπορεί να κάνει χρήση άλλων ενδοεπικοινωνιακών μηχανισμών όπως η named pipes ή η Winsock, για μεγαλύτερη ευλυγισία πραγματοποίησης της μεταφοράς αυτής. Στον επόμενο πίνακα φαίνεται μια λίστα με τα πρωτόκολλα που υποστηρίζονται από το RPC καθώς και ο τύπος της σύνδεσης RPC που χρησιμοποιεί το κάθε πρωτόκολλο. Protocol RPC Type Transmission Control Protocol (TCP) Connection oriented Sequenced Packet Exchange (SPX) Connection oriented Named Pipe Connection oriented HTTP Connection oriented User Datagram Protocol (UDP) Connectionless Cluster Datagram Protocol (CDP) Connectionless Όταν ο server λάβει το RPC, οι λειτουργίες της RPC βιβλιοθήκης χρόνου εκτέλεσής του θα κάνουν δεκτό το αίτημα και θα καλέσουν την διαδικασία του στελέχους του. Το στέλεχος του server παίρνει τις παραμέτρους από το buffer του δικτύου και χρησιμοποιώντας μια από τις μηχανές NDR marshalling, τις μετατρέπει από την μορφή που είχαν κατά την μεταφορά τους στην επιθυμητή για τον server. Κατόπιν, το στέλεχος του server καλεί την διαδικασία στο server. Η απομακρυσμένη διαδικασία τρέχει για την δημιουργία πιθανών παραμέτρων εξόδου και μια τιμή επιστροφής. Με το πέρας της διεργασίας ξεκινάει η αντίστροφη ακολουθία βημάτων επιστροφής των δεδομένων στον client. Στα Windows, οι βιβλιοθήκες χρόνου εκτέλεσης έχουν δύο μέρη: μια βιβλιοθήκη εισόδου, που είναι συνδεδεμένη με την εφαρμογή και την RPC runtime library που υλοποιείται σαν DLL. Η εφαρμογή του server περιέχει κλήσεις στις λειτουργίες της βιβλιοθήκης χρόνου εκτέλεσης του, οι οποίες καταχωρούν την διεπαφή του server με την -62-

63 RPC runtime και σε κάποιες περιπτώσεις τον EPM, επιτρέποντας έτσι στον server να δέχεται απομακρυσμένες αιτήσεις διαδικασιών Δομή μηνυμάτων RPC Τα μηνύματα του RPC αποτελούνται από δύο ξεχωριστές δομές: τα μηνύματα κλήσης και τα μηνύματα απάντησης. Η ροή των μηνυμάτων αυτών φαίνεται στην Εικ. 31. Μήνυμα κλήσης RPC: Κάθε μήνυμα κλήσης απομακρυσμένης διαδικασίας περιέχει μια τριάδα πεδίων αριθμητικών τιμών μοναδικής αναγνώρισης της απομακρυσμένης διαδικασίας: Αριθμός προγράμματος (Program number): Ορίζει μια ομάδα απομακρυσμένων διαδικασιών, η κάθε μια με δικό της αριθμό Αριθμός έκδοσης προγράμματος (Program version number): Το πρόγραμμα μπορεί να έχει πολλαπλές εκδόσεις. Κάθε έκδοση περιέχει το δικό της σύνολο διαδικασιών που μπορεί να κληθούν απομακρυσμένα. Με αυτό το τρόπο μπορεί να έχουμε ταυτόχρονη ύπαρξη πολλών εκδόσεων της ίδιας RPC εφαρμογής Αριθμός διαδικασίας (Procedure number): Είναι ο κωδικός αριθμός που έχει κάθε διαδικασία σ ένα host -63-