Laborarbeit Network & Services Überwachung komplexer IT-Infrastrukturen

Transkript

1 Laborarbeit Network & Services Überwachung komplexer IT-Infrastrukturen Horw,

2 Projekt Dokument Schule Modul Projektteam Überwachung komplexer IT-Infrastrukturen Projektdokumentation, TA.NS Galliker Thomas Studiengang Informatik (BB) Panorama 6123 Geiss Tel Hauswirth Daniel Studiengang Informatik (BB) Sandacherweg Rüfenach Tel Dozenten Assistenten Letzte Änderung Prof., Dr., dipl. Ing. ETH, Bernhard M. Hämmerli Prof., Werner Odermatt Dipl. Ing. Inf. FH, Nicola Lardieri 3. Dezember 2009, 16:00:00 Uhr Änderungsprotokoll Version Datum Autor Beschreibung thg Layout erstellt thg Provisorisches Inhaltsverzeichnis had/thg Netzwerktopologie thg Ausgangslage, Analyse had Konfiguration Nagios Appliance thg Dokumentation SNMP had/thg Dokumentation Laborversuche 1, 2, had/thg Überarbeitung des gesamten Dokuments had/thg Dokumentation Laborversuche 4, 5, thg SNMP Nachrichtenformat dokumentiert had/thg Laborversuche verbessern, korrigieren, Ablauf optimieren had/thg Rechtschreibkorrektur had/thg Abgabe

3 Inhalt 1 Einführung Theorie Einführung in SNMP Das Kommunikationsmodell von SNMP Die Management Information Base (MIB) SNMP Funktionen get / get-response get-next / walk Protokollstruktur Verbindungslose Kommunikation Nachrichtenformat SNMP im TCP/IP Referenzmodell SNMP Communities Laborübung Ausgangslage Analyse der Ausgangslage Laboraufbau Client Network Server Network Demilitarized Zone Netztopologie Netzwerkdienste Installation und Konfiguration der Nagios Appliance Vorbereitung der Nagios Appliance für die Laborversuche SNMP Überwachung zu Nagios hinzufügen Laborversuche Versuch 1: SNMP Protokollanalyse an LABROU Versuch 2: SNMP Protokollanalyse an LABSRV Versuch 3: Crash-Simulation mit LABSRV11 und NAGIOS Monitoring Versuch 4: Config Notification Trap auf LABROU Versuch 5: linkdown Trap auf LABROU Versuch 6: Notification per Persönliches Fazit Autor: Daniel Hauswirth Autor: Thomas Galliker Anhang Glossar Quellenverzeichnis Konfigurationen labsw labrou labrou labfw

4 Abbildungsverzeichnis Abbildung 1: Schematische Darstellung des Master/Slave Architektur von SNMP....6 Abbildung 2: Das SNMP Attribut sysdescr, ausgelesen mit einem SNMP Manager....7 Abbildung 3: Die Hierarchie von SNMP: Das Attribut sysdescr ist unter zu finden...7 Abbildung 4: Schematische Darstellung der SNMP GET Anfrage...8 Abbildung 5: Das Nachrichtenformat von SNMP....9 Abbildung 6: SNMP im TCP/IP Referenzmodell Abbildung 7: Eine mit Fehlermeldungen überfüllte Mailbox ist so nutzlos wie keine Überwachung...11 Abbildung 8: Netzwerktopologie des Laboraufbaus Abbildung 9: Reihenfolge Konfiguration Nagios wie in Combobox...15 Abbildung 10: Diverse Timeperiods werden festgelegt Abbildung 11: Host-Konfiguration am Beispiel von labsrv Abbildung 12: Von Nagios automatisch erstellte Netztopologie...17 Abbildung 13: Konfiguration eines Services in Nagios...18 Abbildung 14: Einrichten eines SNMP Services in Nagios...19 Abbildung 15: Schematischer Aufbau des Laborversuchs Abbildung 16: Ansicht der RFC1213 MIB-2 im MIB Browser...21 Abbildung 17: SNMP get-request und get-response Datagramme im Network Analyzer WireShark Abbildung 18: Das Resultat nach dem Ausführen des Get-Requests auf LABROU Abbildung 19: SNMP Protokollanalyse: Die get-request Operation Abbildung 20: SNMP Protokollanalyse: Die get-response Operation Abbildung 21: Schematischer Aufbau des Laborversuchs Abbildung 22: SNMP/UDP Datagramme werden am Firewall Interface INSIDE blockiert...25 Abbildung 23: Die blockierten SNMP get-request Datagramme bleiben unbeantwortet Abbildung 24: Schematischer Aufbau des Laborversuchs Abbildung 25: Übersicht über die von Nagios überwachten Hosts Abbildung 26: Services, welche den Server LABSRV11 überwachen...28 Abbildung 27: Nach genau 2 Minuten erscheint die Meldung DOWN auf der Oberfläche Abbildung 28: Definition der Kontaktgruppe Pikett Abbildung 29: Nach ungefähr 45 Sekunden ist die Anzeige wieder auf UP...28 Abbildung 30: Nach nur 30 Sekunden ist die Meldung CRITICAL auf unserer Überwachung erschienen Abbildung 31: Nach 30 Sekunden ist die Meldung OK wieder erschienen Abbildung 32: Punkt Commands des Plugins check_http: Individuelle Abfragen werden hier eingerichtet Abbildung 33: Nach 30 Sekunden ist die Meldung OK wieder erschienen Abbildung 34: Schematischer Aufbau des Laborversuchs Abbildung 35: SNMP Trap linkdown und linkup beim Aus-/Einstecken des Netzwerkkabels...32 Abbildung 36: Die Azeti Nagios Appliance erlaubt das Empfangen von SNMP Traps Abbildung 37: Der eingehende SNMP Trap löst in Nagios eine Warnung aus...33 Abbildung 38: SNMP Trap Config Notification, welcher von LABROU01 abgesetzt wurde Abbildung 39: SNMP Trap Config Notification, welcher von LABROU01 abgesetzt wurde Abbildung 40: Einrichten eines neuen Empfängers in Nagios Abbildung 41: Schematischer Aufbau des Laborversuchs Abbildung 42: Konfiguration eines check_snmp Monitors für den Netzwerkdrucker Tabellenverzeichnis Tabelle 1: Netztabelle mit sämtlichen Netzwerke und den dazugehörigen Netzbereichen...12 Tabelle 2: Die Netzwerkdienste der Laborumgebung in tabellarischer Übersicht Tabelle 3: Mapping zwischen VLANs und Firewall Interfaces Tabelle 4: Konfigurierte Regeln der Firewall LABFW Tabelle 5: Die Regeln der Firewall LABFW01 mussten mit neuen SNMP Regeln ergänzt werden Tabelle 6: UP- und DOWN-Meldung wie sie von Nagios als versendet wurde....36

5 Dokumentation / Einführung 1 Einführung Die,, führt im Rahme des Moduls Network & Services praxisbezogene Laborübungen durch. Die Studierenden haben die Wahl zwischen verschiedenen Themenbereichen aus dem Fachgebiet Netzwerk. Über das gewählte Thema wird im Zeitraum von 5 bis 6 Semesterwochen eine Dokumentation geschrieben. Dabei sollen Theorie und Praxis des zu behandelnden Themas tangiert werden. Ziel der Übung ist es, eine bestimmte Netzwerktechnologie detailliert zu studieren und das angeeignete Know-how in praktischen Übungen anzuwenden. Das hier vorliegende Dokument wurde von Daniel Hauswirth und Thomas Galliker erarbeitet. Die beiden Autoren haben sich während mehrerer Wochen intensiv mit dem Thema Überwachung komplexer IT Infrastrukturen auseinandergesetzt. Dabei standen das Simple Network Monitoring Protocol sowie die Monitoring Appliance azeti SONARPLEX 4000 A im Vordergrund der Arbeit. Inhalte von Drittautoren werden jeweils vermerkt und sind im Quellenverzeichnis aufgeführt. Gruppe 7 5 / 49

6 Dokumentation / Theorie 2 Theorie 2.1 Einführung in SNMP Simple Network Management Protocol (SNMP) ist ein UDP-basiertes Netzwerkprotokoll, welches zur Verwaltung und Überwachung von Netzwerkgeräten eingesetzt wird. SNMP gehört neben einigen hundert anderen bekannten Protokollen zur Internetprotokollfamilie. Grundsätzlich standardisiert das Protokoll SNMP ein Datenbankschema, verwaltete Datenobjekte sowie ein OSI-Layer 7 Kommunikationsprotokoll. 2.2 Das Kommunikationsmodell von SNMP Das Protokoll baut auf einem typischen Client-/Servermodell auf. Die beiden Endpunkte werden dabei "Master/Slave" oder "Manager/Agent" genannt. Der Manager spielt die Rolle des Überwachers während ein Slave ein beliebiges Netzwerksystem sein kann. Das Netzwerk Management Protokoll SNMP regelt die Kommunikation zwischen den beiden Endpunkten. Beispielsweise übertragen SNMP Agents in regelmässigen Zeitabständen gegenwärtige Statusinformation über Software- und/oder Hardwarekomponenten. Die Werte werden in vordefinierten Variablen übermitteln. Einige Beispiele für Informationen sind: freier Diskplatz, freier Arbeitsspeicher, CPU Auslastung, und vieles mehr. Dem Umfang der abzufragenden Variablen wird alleine durch den Hersteller der eingesetzten Informationsbasis (MIB) Grenzen gesetzt. Es besteht jedoch nicht nur die Möglichkeit, dass SNMP Agents ihre Systeminformationen auf periodischer Basis an den SNMP Manager senden die SNMP Manager können mit definierten Protokolloperationen Informationen auch zu einem bestimmten Zeitpunkt abholen. Das Protokoll erlaubt auch das Modifizieren von Werten auf SNMP Slaves. In der Praxis hat diese Operation aber keine grosse Beliebtheit gefunden, da bis und mit SNMPv2 keine akzeptablen Sicherheitsmechanismen eingebaut wurden. Abbildung 1: Schematische Darstellung des Master/Slave Architektur von SNMP. Mit SNMP lassen sich die unterschiedlichsten Netzwerkgeräte im weitesten Sinne überwachen. Ob es sich nun um Vermittlungskomponenten wie Router, Switches, IP Telefone oder Computersysteme, Server oder gar Drucksysteme handelt hängt dabei nur davon ab, ob der Hersteller auf den TCP/IP Stack auch das SNMP implementiert hat. Der Hersteller eines Geräts legt in eineindeutigen Variablen fest, welche Attribute ausgelesen und gesetzt werden können. Wie bereits angesprochen werden diese Variablen in einer so genannten Management Information Base gespeichert. Auf diese MIB wird in den nächsten Abschnitten näher eingegangen. Gruppe 7 6 / 49

7 Dokumentation / Theorie 2.3 Die Management Information Base (MIB) Sehr wichtig beim Verständnis von SNMP ist die Tatsache, dass SNMP selbst keine Informationsträger (Variablen) bereitstellt, welche von verwalteten Systemen abgefragt werden können. SNMP definiert lediglich das Datenmodell. Erst in einer so genannten Management Information Base, kurz MIB, sind die abzufragenden Variablen festgelegt. Die Informationen in einer MIB sind in hierarchische Namenspaces gruppiert. Die MIB Hierarchie baut auf einem namenlosen root"-knoten auf. Darunter folgen Knoten, welche verschiedenen Organisationen zugeordnet wurden. Viele Knoten haben heute keinen expliziten Verwendungszweck und sind rein experimentell. Die nach dem root -Knoten folgenden Knoten werden als MIB Module oder nicht selten auch als Managed Object bezeichnet. Jedem Objekt ist ein eindeutiger Object Identifier (OID) zugeordnet. Über diesen OID kann ein Objekt ausgelesen werden (Auch das setzen von Werten ist möglich falls dies vorgesehen ist). Dieser OID kann in zwei Formen dargestellt werden: als eine Zahlenkette ( ) oder durch eine ASCII-Repräsentation (.iso.org.dod.internet.private.management.mib-2.system.sysdescr). Diese beiden Formen können auch gemischt werden. Abbildung 2: Das SNMP Attribut sysdescr, ausgelesen mit einem SNMP Manager. Die gute Skalierbarkeit macht SNMP sehr flexibel und durch individuelle Hersteller MIBs erweiterbar. Jeder Hersteller, welcher ein SNMP-fähiges Gerät auf den Markt bringt, bietet dazu meist auch eine MIB an. herstellerabhängige MIB Module sind in der MIB- Hierarchie unter.iso.org.dod.internet.private.enterprise angegliedert. Die sog. Enterprise ID s können bei der Internet Assigned Numbers Authority (IANA) beantragt werden. Es gibt jedoch auch Hersteller-unabhängige MIBs wie beispielsweise die MIB for Network Management of TCP/IP-based Internets oder kurz MIB-2 welche mit RFC1213 ratifiziert wurde. Abbildung 3: Die Hierarchie von SNMP: Das Attribut sysdescr ist unter zu finden. Gruppe 7 7 / 49

8 Dokumentation / Theorie 2.4 SNMP Funktionen Nachdem wir wissen, wie SNMP Informationen organisiert ist es jetzt an der Zeit, die verschiedenen Funktionen von SNMP genauer anzuschauen. SNMP implementiert folgende Operationen: get get-next get-bulk (ab SNMPv2) set get-response trap notification (ab SNMPv2) inform (ab SNMPv2) report (ab SNMPv2) In den nachfolgenden Abschnitten wird die Funktionsweise der Operationen get, get-response, get-next und walk kurz beschrieben. (Achtung: Die Operation walk ist keine standardisierte SNMP Operation) get / get-response Eine get-anfrage wird von einem SNMP Manager ausgelöst, um Informationen von einem SNMP Agent abzufragen. Der SNMP Agent versucht die Anfrage bestmöglich zu beantworten. (Aus netzwerktechnischen Gründen ist dies nicht immer möglich). Falls es keine Zwischenfälle gibt, antwortet der SNMP Agent mit einer get-response Nachricht. Die get Anfrage wird an UDP Zielport 161 gerichtet. Der Anfrager verwendet einen dynamischen Quellport. Bei der get-response Antwort werden Quell- und Zieladressen vertauscht: Zielport ist nun der dynamische Port, auf welchem der anfragende Client auf eine Antwort horcht. Abbildung 4: Schematische Darstellung der SNMP GET Anfrage get-next / walk Die get-next Operation ist eine Erweiterung der get Operation. Mit get-next wird die n+1. OID ausgelesen. Dies erlaubt das einfache Traversieren durch MIBs. Oft bieten SNMP Manager die Möglichkeit, eine Operation walk auszuführen. Dabei handelt es sich um eine automatisierte und kontinuierlich wiederholte Ausführung von get-next Operationen. Dies kann insbesondere dann von Vorteil sein, wenn der Administrator eine bestimmte Management-Information sucht und diese mit Hilfe der MIB Dokumentation nicht finden kann. Gruppe 7 8 / 49

9 Dokumentation / Theorie 2.5 Protokollstruktur Verbindungslose Kommunikation SNMP verwendet das User Datagram Protocol (UDP) um Informationen zwischen SNMP Manager und Agents auszutauschen. Für den Versand von SNMP Datagrammen wird UDP Port 161 verwendet, während für das Empfangen von SNMP Traps der UDP Port 162 vorgesehen ist. Da UDP ein verbindungsloses Protokoll ist, liegt es an der SNMP Anwendung zu kontrollieren, ob eine Nachricht verloren gegangen ist. Typischerweise wird dies mit Timeouts gelöst: Ein Manager sendet eine Anfrage an einen Agent. Erhält er nach einer bestimmten Zeit keine Antwort sendet er dieselbe Anfrage einfach nochmals. Einwenig anders läuft dies mit SNMP Traps: Ein SNMP Agent, welcher einen Trap zum Manager sendet, wird nie herausfinden, ob dieser Trap beim Manager angekommen ist. Traps werden vom Manager nicht quittiert. Auch hier liegt es wieder an der Agent Anwendung. Eine intelligente Agent Anwendung sendet SNMP Traps in zeitlichen Abständen. Unter Umständen können so beim Manager grosse Mengen an SNMP Informationen angeschwemmt werden. Das ist aber lediglich eine Frage der Konfiguration des Agents. Laut O Reilly s Artikel Essential SNMP wurden bereits Versuche unternommen, SNMP auf TCP zu implementieren diese schienen aber weniger Erfolg zu verbuchen als SNMP mit UDP Nachrichtenformat Das Nachrichtenformat von SNMP spezifiziert, welche Informationen in welcher Reihenfolge verpackt und versendet werden. In der äussersten Schicht einer SNMP Nachricht sind drei Informationsträger vorgesehen: SNMP Version (als Integer) SNMP Community String (als String) SNMP Payload Data Unit Die Payload Data Unit ist ihrerseits wieder in weitere Felder unterteilt. So werden beispielsweise die OID und der dazugehörige Abfragewert in einem Feld der PDU übertragen. Bemerkenswert ist auch das Feld Request ID. Hier wird eine eindeutige Identifikationsnummer übertragen. Mit dieser Nummer kann der Sender eine Antwortnachricht zu einer Anfragenachricht zuordnen. Auf weitere Felder wird in dieser Dokumentation nicht näher eingegangen. Die vollständige Protokolldefinition ist im RFC 1157 nachzulesen (siehe Quellen). Die nachfolgende Abbildung veranschaulicht den Protokollaufbau grafisch: Abbildung 5: Das Nachrichtenformat von SNMP. Gruppe 7 9 / 49

10 Dokumentation / Theorie 2.6 SNMP im TCP/IP Referenzmodell Ein SNMP Datagramm wird nicht einfach so, alleine aufs Netz gelegt. Als Application Layer Protocol (Layer 7) basiert SNMP auf dem UDP Protokoll (Layer 4). Dieses wiederum baut auf dem Internet Protokoll (Layer 3), welches seinerseits auf MAC+LLC (Layer 2) und Ethernet (Layer 1) basiert. Die nachfolgende Abbildung veranschaulicht den Sachverhalt grafisch. Abbildung 6: SNMP im TCP/IP Referenzmodell. 2.7 SNMP Communities SNMPv1 und SNMPv2 nutzen Communities zur Bildung einer Vertrauensstellung zwischen SNMP Manager und Agent. Es gibt folgende Arten von Communities: Read-Only; RO Read-Write; RW Der Name einer Community ist vergleichbar mit einem Passwort. Die drei Community Typen regeln die möglichen SNMP Aktivitäten: Wie bereits der Name sagt, darf die Read-Only Community nur lesen. In vielen Fällen genügt die Read-Only Community vollkommen. Mit der Read-Write Community ist nicht nur möglich, Daten zu auszulesen es können auch Daten geschrieben werden. Das kann beispielsweise eine Konfiguration, ein Kontrollbefehl oder ein Reset einer Variablen sein. Die meisten Anbieter SNMP-fähiger Geräte verwenden die Standardnamen für die Communities. Das sind typischerweise public für die Read-Only Community und private für die Read-Write Community. Es ist also ein essentieller Fehler, wenn ein Netzwerkadministrator ein SNMP-aktiviertes Netzwerkgerät mit Standardkonfiguration ins Netz stellt. Es gilt also sicherzustellen, dass alternative Community Strings verwendet werden. Jede Community kann aber unabhängig voneinander deaktiviert werden. Oft reicht es, wenn die Read-Only Community aktiviert ist. Eine der grössten Sicherheitslücken in SNMP besteht in der Tatsache, dass SNMP die Community Namen also die Passwörter in Klartext über das Netzwerk überträgt. Eine Authentifizierung wurde erst in SNMPv3 implementiert. (SNMPv3 ist nicht Bestandteil dieser Laborarbeit). Um das Risiko eines Angriffs dennoch zu reduzieren, empfiehlt es sich, den Netzwerkverkehr über eine Firewall zu regulieren. An den Interfaces einer Firewall kann festgelegt werden, welche Geräte SNMP Anfragen an andere Geräte richten dürfen. In den Laborversuchen dieser Dokumentation wird dies an einem einfachen Beispiel erklärt. Gruppe 7 10 / 49

11 3 Laborübung Nach eingehendem Studium der theoretischen Grundlagen von SNMP wird dieses Wissen nun in einer praktischen Laborübung zur Anwendung gebracht. Die Laborübung wurde von den Studenten selbstständig erarbeitet und lehnt sich an eine realistische IT-Infrastruktur, wie sie heute in der Industrie angetroffen werden kann. Die Umgebung wurde auf die wesentlichsten Faktoren reduziert. 3.1 Ausgangslage Dieses Fallbeispiel dreht sich um ein kleines Internet Hosting Unternehmen. Die Firma plant, gestaltet und betreibt Webauftritt für private, institutionelle und industrielle Partner. Auf Kundenwunsch werden auch dedizierte Root Server bereitgestellt. Der Kern der Firma bildet das firmeneigene Rechenzentrum, in welchem die Kundensysteme betrieben werden. Die Überwachung der Infrastruktur wurde wegen fehlenden Ressourcen vernachlässigt. Der Hardwarestatus wird unregelmässig von einem Mitarbeiter des Rechenzentrums optisch kontrolliert. Die oberen Überwachungsschichten (Webdienste, Services, ) werden mit einem komplexen Überwachungssystem überwacht. Fehlermeldungen werden in eine Mailbox versendet, welche sporadisch konsultiert wird. 3.2 Analyse der Ausgangslage Ein durchdachtes Überwachungskonzept könnte der Firma viel Ärger ersparen. Reaktives und zögerliches Fehlerbehebungsverhalten wird von keinem Kunden akzeptiert. Gerade ein kleiner Hoster kann sich der Verlust von frustrierten Kunden nicht erlauben. Es scheint aber nicht nur an der mangelnden oder fehlenden Überwachungsinfrastruktur zu liegen auch Prozesse und Abläufe sind nicht definiert. Sporadische Konsultation bedeutet für die Überwachung von wichtigen Systemen keine verbindliche Fehlererkennung und indes auch keine garantierte Behebung eines Fehlers innerhalb bestimmter Zeit. Der Hoster hat keine Chance, dem Kunden eine bestimmte Verfügbarkeit zu garantieren. Tut er das trotzdem, hängt er sich weit zum Fenster hinaus Abbildung 7: Eine mit Fehlermeldungen überfüllte Mailbox ist so nutzlos wie keine Überwachung. Gruppe 7 11 / 49

12 3.3 Laboraufbau Mit dem nachfolgenden Laboraufbau wird versucht, die IT-Infrastruktur des Web Hosters in den wesentlichsten Punkten möglichst realistisch abzubilden. Netzwerke wurden nach Einsatzzweck und Sicherheitsrelevanz in verschiedene virtuelle LANs (VLANs) aufgeteilt. Detaillierte Informationen zu den jeweiligen Netzwerken sind der Netztabelle sowie der Netztopologie zu entnehmen Client Network Im Client Network sollen alle Computer der Arbeitnehmer des Hosting Unternehmens platziert werden. Dies betrifft auch Supporter und Administrator, welche für den Betrieb der Systeme im internen wie im demilitarisierten Netzwerk zuständig sind. Für das Netzwerk wird ein geroutetes VLAN eingerichtet (siehe Netztopologie) Server Network Der Name dieses Netzwerks ist wiederum selbsterklärend: Im Server Network sollen sämtliche internen Systeme platziert werden. Neben den Netzwerkdiensten wie Active Directory, DNS und DHCP wird hier auch der SNMP Manager eingerichtet Demilitarized Zone Bemerkenswert ist natürlich die Implementierung einer Demilitarized Zone, kurz DMZ, auch bekannt als Perimeter Netzwerk. In der DMZ des Hosters werden diejenigen Systeme betrieben, welche dem World Wide Web ihre Dienste bereitstellt. Der Zugriff auf DMZ Systeme erfolgt von innen (sog. Inside Netzwerk) sowie von aussen (sog. Outside Netzwerk;) über eine Firewall. In unserem Fallbeispiel wird die DMZ mit einer einzigen Firewall, welche mit drei Ethernet-Schnittstellen bestückt ist, umgesetzt. Die Firewall sichert den Verkehr zwischen Inside und der DMZ bzw. Outside und der DMZ. Damit will erreicht werden, dass nur bestimmte Anfragen von Outside nur zu bestimmten Systemen in der DMZ gelangen können und keineswegs direkt in das interne Netzwerk Netztopologie Folgende Tabelle illustriert die Eigenschaften der geplanten Netzwerke VLAN ID Bezeichnung Netzwerk Adressbereich Default Gateway 10 Server_Network / Client_Network / Transit_LAN_ / DMZ_Network / Transit_LAN_ / Tabelle 1: Netztabelle mit sämtlichen Netzwerke und den dazugehörigen Netzbereichen. Gruppe 7 12 / 49

13 Abbildung 8: Netzwerktopologie des Laboraufbaus. Gruppe 7 13 / 49

14 3.3.5 Netzwerkdienste In der Laborumgebung werden folgende grundlegende Netzwerkdienste eingerichtet. Die Installation bzw. Konfiguration der Services wird nicht explizit aufgezeigt. Dienst Funktionsbeschreibung Wert AD DNS DHCP DNS Domain Name NetBIOS Domain Name Schema Master Domain Naming Master RID Master Infrastructure Master PDC Emulator Global Catalog Primary DNS Secondary DNS Active DHCP Standby DHCP DHCP Bereiche lab.local LAB labsrv01 labsrv01 labsrv02 labsrv02 labsrv02 labsrv01 labsrv01 ( ) labsrv02 ( ) labsrv01 labsrv02 VLAN 10 und 20 werden mit DHCP bedient. (Siehe Netztabelle) DHCP Relays VLAN20: labrou01, Fa0/0.20 ( ) WWW Tabelle 2: Windows Webserver (IIS) labsrv10 Linux Webserver (Apache) labsrv11 Die Netzwerkdienste der Laborumgebung in tabellarischer Übersicht. Gruppe 7 14 / 49

15 3.3.6 Installation und Konfiguration der Nagios Appliance Für den Versuch stand eine Azeti Nagios Box zur Verfügung. Auf dieser Azeti Box läuft ein Linux mit installiertem Paket Nagios. So wird die nicht sehr triviale Installation und Konfiguration eines eigenen Nagios-Servers erheblich vereinfacht. Die Box kann nach einer kurzen Konfiguration über den seriellen Port an das LAN angeschlossen und danach per Web-Interface konfiguriert werden. Für die Netzwerkkonfiguration der über den seriellen Port sind folgende schritte notwendig: Verbinden per RS232 Admin User = "super" (Passwort wird mit Beiblatt vom Hersteller mitgeliefert) IP Adresse Anzeigen: show ip address IP Adresse ändern: ip address Gateway ändern: ip gateway DNS ändern: ip dns Um die Konfiguration wieder auf den Fabrikzustand zurückzusetzen, verwendet man den Befehl erase flash. Sobald die Azeti Box konfiguriert ist, kann man sie an das Netzwerk anschliessen und über die Web- Oberfläche drauf zugreifen. Dies kann man im Admin- oder im User-Modus tun. Den Admin Modus erreicht man über den User-Modus über den Standard http-port 80. Um die Box zu konfigurieren, verbinden wir im Admin Modus. Username und Passwort sind per default admin. Die Oberfläche stellt sich gemäss Abbildung dar (hier Screenshot der Azeti Oberfläche einfügen). Die Menüs auf der Oberfläche sind in zwei Hauptgruppen (Backup/Restore/Update und Configuration) aufgeteilt. Die erstgenannte Gruppe ist selbsterklärend. Hier können die Konfiguration gesichert und wiederhergestellt werden, und auch die Firmware kann man hier aktualisieren. Weit interessanter ist der Punkt Configuration. Im Untermenü Setup ist das Herz der Azeti Nagios Appliance. Hier werden die zu Überwachenden Hosts und Services konfiguriert. Der Ablauf der Konfiguration ist in einer Combobox hierarchisch aufgebaut; das heisst, die Konfiguration sollte vom ersten Punkt der Combobox (siehe Abbildung) an der Reihe nach durchgeführt werden. Nachfolgend die Erläuterung zum Ablauf der Konfiguration: Timeperiod Contacts: Contactgroups: Hosts: Standardmässig existieren "Always" und "Never" als Zeitperiode. Diese können nicht gelöscht werden. Hier kann man zusätzliche Zeitfenster definieren in welchen z.b. eine andere Person zuständig ist, dass die Services überwacht werden. Die Zeitfenster werden im Format HH:MM-HH:MM angegeben. Es ist auch möglich, mehrere Zeitfenster an einem Wochentag zu definieren. Ist dies gewünscht, kann man mit z.b. 08:00-12:00,13:30-17:30 ein Zeitfenster für die Arbeitszeiten definieren. Hier können die zuständigen Personen angegeben werden. Diese können einem Zeitintervall zugeordnet werden und man kann bestimmen, ob per SMS und Warnungen verschickt werden. Die Mobile Nummer wird ohne + vor der Ländervorwahl eingegeben. Ein Beispiel: Die erstellten Kontakte kann man den verschiedenen Gruppen zuordnen Hier fügt man die zu überprüfenden Hosts ein. Abbildung 9: Reihenfolge Konfiguration Nagios wie in Combobox - Name und Alias eingeben; hier ist die Eingabe des Hostnamens sinnvoll Gruppe 7 15 / 49

16 Hostgroups: Service: - IP-Adresse oder Hostnamen angeben - check host status via: hier wählen wir aus, welcher Standardcheck von Nagios auf den Host durchgeführt wird. Wir nehmen check-host, welcher den Host mit einem Ping überprüft. - Kontaktgruppe einstellen; Pikett-Gruppe - Perform checks und send notification aktivieren, damit Checks durchgeführt werden und Fehlermeldungen abgesetzt werden können. - Additional information: Hier kann die Abhängigkeit des Devices festgelegt werden. Weiter stellt man hier ein, um was für ein Device es sich handelt (Server etc) Die Hosts können zu Hostgroups zusammengefasste werden (z. B. Server, DMZ, etc.) Create New Service anklicken und gewünschten Check auswählen. Beschreibung angeben und auswählen ob hosts oder hostgroups gecheckt werden sollen. Die weiteren Punkte im Configuration Menü sind selbsterklärend und müssen an dieser Stelle nicht weiter dokumentiert werden Vorbereitung der Nagios Appliance für die Laborversuche Nachfolgend beschreiben wir unsere Beispielkonfiguration für den Laborversuch. Dies soll einen Einblick geben, wie wir uns die Überwachung vorstellen könnten. Die Konfiguration ist natürlich beinahe unendlich erweiterbar. Die Nagios Konfiguration wird wie oben beschrieben über die Admin Weboberfläche auf durchgeführt. Dort wählt man im Bereich Configuration das Menü Setup Timeperiods Wir haben zwei zusätzliche Zeitperioden eingeführt. Eine Zeitperiode für während der Arbeitszeit und eine für eine 24h Überwachung. Somit ist es möglich, später die Services gemäss Vertrag mit dem Kunden anzupassen. Es wurden die Timeperiods Status 5x10 und Status 7x24 eingerichtet (siehe Abbildung) Contacts Als Kontakt wurden die Teammitglieder mit eingetragen. Weiter wurde auch ein Pikett 7x24 Benutzer erstellt, welcher als E- Mail Adresse einen SMS-Gateway hat. Somit kann der Pikett-Dienst mit einem Pikett-Mobiltelefon sichergestellt werden Contacgroups Hier haben wir nur eine Gruppe Pikett erstellt. Dieser Gruppe könnte man jeweils die Supporter, die gerade im Pikettdienst leisten, zuordnen. Je nachdem welcher Philosophie die Firma folgt. Abbildung 10: Diverse Timeperiods werden festgelegt Hosts Bei den Hosts wurden alle Server in der DMZ und im Server LAN hinzugefügt. Am Beispiel des LABSRV11 (siehe Abbildung) wird kurz erklärt welche Einstellungen vorgenommen werden. Gruppe 7 16 / 49

17 Abbildung 11: Host-Konfiguration am Beispiel von labsrv11. Dem Host wird der Name labsrv11 zugewiesen, welcher später nicht mehr verändert werden kann. Auch eine Alias kann definiert werden und die IP oder den Hostnamen. Ist ein Host erfasst wird automatisch ein Standardcheck durchgeführt. Unter Check host status via kann die Art des Checks bestimmen. Wir wählen hier check-host. So wird mit einem Ping die Erreichbarkeit überprüft. Weiter haben wir die Pikett-Gruppe als Kontakt definiert, wenn der Host ausfallen soll. Ein wichtiger Punkt ist Maximum check attempts; hier legen wir fest, nach wie vielen erfolglosen Versuchen eine Meldung abgesetzt wir, dass der Server down ist. Am Schluss der Liste legt man bei Additional Information fest, in welcher Abhängigkeit der Host steht. Dies ist wichtig, da aufgrund dieser Information eine Netztopologie der überwachten Hosts erstellt wird, welche beim User GUI ersichtlich ist (siehe Abbildung). Abbildung 12: Von Nagios automatisch erstellte Netztopologie. Gruppe 7 17 / 49

18 Hostgroups Die erstellten Hosts haben wir in die Hostgruppen DMZ Network, Routing und Switching und Server Network erstellt und die betreffenden Host der Gruppe hinzugefügt. Eine sinnvolle Gliederung von Gruppen erleichtert die Administration der Services Services Bei den Services sind wir nun im Herzen von Nagios angelangt. Hier kann man beinahe alles erdenkliche überwachen. Als Beispiel zeigen wir hier auf, wie der von uns definierte ifcheck Aufgebaut ist (siehe Abbildung). Dieser Service kontrolliert ein Interface eines Cisco-Routers. Abbildung 13: Konfiguration eines Services in Nagios. Der Service ifcheck wird unter Hosts unserem Router labrou01 zugewiesen. Unter Command wurde das Plugin check_snmp ausgewählt. Die mit einem MIB Browser ermittelte OID kann man hier angeben. Auch der Wertebereich für Warnungen und kritische Warnungen wird hier definiert. Mit Nagios ist es nicht möglich, MIB Datenbanken auszulesen; daher wurde der MIB Browser von ireasoning herbeigezogen, um die SNMP MIBs zu durchsuchen. Gruppe 7 18 / 49

19 3.3.8 SNMP Überwachung zu Nagios hinzufügen Um eine SNMP Überwachung mit Nagios durchzuführen, muss die OID des auszulesenden Wertes eingetragen werden. Diese kann mit einem MIB-Browser (z.b. ireasoning MIB-Browser) ermittelt werden. Wollen wir zum Beispiel die System Description des LABROU01 (Cisco 1800 Series Router) ermitteln, benötigen wir die OID Nun erstellen wir in der Admin Oberfläche von Nagios einen neuen Service und ordnen diesen dem Router LABROU11 zu. Im Command Abschnitte (siehe Abbildung) geben wir nun diese OID ein. Danach wird die System Beschreibung regelmässig abgefragt und ist unter Services ersichtlich. Abbildung 14: Einrichten eines SNMP Services in Nagios. Gruppe 7 19 / 49

20 3.4 Laborversuche Nach abgeschlossener Konzeptphase und erfolgreichem Aufbau der Laborumgebung ist es nun an der Zeit, einige Phrasen über die durchgeführten Laborversuche niederzuschreiben. Insgesamt wurde eine Vielzahl von kleineren und grösseren Versuchen durchgeführt. Die eindrücklichsten Versuche wurden zusammengefasst und nachfolgend in aufgearbeiteter Form präsentiert Versuch 1: SNMP Protokollanalyse an LABROU01 Der erste Laborversuch hat zum Ziel, eine einfache SNMP Anfrage durchzuführen und mit Hilfe eines Network Analyzers die übertragenen Pakete aufzuzeichnen und auszuwerten. Die SNMP Anfrage wird von einem MIB Browser gestartet und an den Cisco 1841 Router, LABROU01, gerichtet. Es wird versucht, Attribute aus der SNMP MIB-2 auszulesen, wie dies im vorgängigen Theorieteil dieser Dokumentation ausführlich beschrieben wurde. Die nachfolgende Abbildung zeigt den relevanten Ausschnitt aus der Topologie des Labornetzwerks. Abbildung 15: Schematischer Aufbau des Laborversuchs 1. Ein besonderes Augenmerk soll auf den Protokollaufbau und die damit verbundenen Mechanismen gelegt werden. Stimmen Theorie und Praxis wirklich überein? Welche Informationen werden bei den Protokolloperationen GET-REQUEST und GET-RESPONSE tatsächlich übertragen? Erwartungshaltung Der erste Laborversuch wurde absichtlich sehr einfach gestaltet, um möglichst rasch die ersten SNMP Pakete in die Fänge des Network Analyzers zu bringen und dort auszuwerten. Grössere Probleme werden nicht erwartet. Einwenig Skepsis war jedoch vor der Versuchsdurchführung schon vorhanden, da wir nicht sicher waren, ob wir den SNMP Agent auf LABROU01 wirklich richtig konfiguriert haben. Das sollte sich jedoch schon bald herausstellen. Gruppe 7 20 / 49

21 Versuchsablauf Vorgängig musste der SNMP Agent auf LABROU01 konfiguriert werden. Zum Auslesen von SNMP Informationen wurde eine SNMP ReadOnly Community eingerichtet. Dazu wurde folgender IOS Befehl verwendet: snmp-server community nagiosreadonly RO Auf dem LABROU01 werden auch die nach RFC1213 definierten Standardattribute syscontact und syslocation konfiguriert: snmp-server contact snmp-server location SecurityLab Im MIB Browser wird die RFC1213 MIB-2 geladen. Als Zieladresse für die SNMP Abfrage soll das virtuelle Interface von VLAN20 auf LABROU01 mit der IP Adresse verwendet werden. Im MIB Browser wird zudem der Zielport 161, die Read Community sowie die vorgesehene SNMP Version angegeben. In der SNMP MIB Übersicht kann das gewünschte auszulesende Attribut gewählt werden. In diesem Beispiel wird syslocation gewählt. Die OID wird automatisch angezeigt. Selbstverständlich kann auch direkt die OID anstelle des Objektnamens abgefragt werden. Bevor nun die Get Operation im MIB Browser ausgeführt wird, wird parallel dazu ein Network Analyzer gestartet. Dieser hat die Aufgabe, den ein- und ausgehenden Verkehr zu überwachen, so dass wir im Anschluss die SNMP Datagramme analysieren können. Die SNMP Operation Get wird im MIB Browser zum Auslesen des Attributs syslocation verwendet. Die Anfrage kann gestartet werden. Nur kurze Zeit nach dem Ausführen der Get-Operation können SNMP Datagramme im Network Analyzer festgestellt werden. Auf die ausgelöste get-request Operation hat der Router offensichtlich mit einem get-response Datagramm geantwortet. Abbildung 16: Ansicht der RFC1213 MIB-2 im MIB Browser. Abbildung 17: SNMP get-request und get-response Datagramme im Network Analyzer WireShark. Schlussendlich kann auch im MIB Browser festgestellt werden, dass das Attribut syslocation.0 den Wert SecurityLab zurückgibt. Abbildung 18: Das Resultat nach dem Ausführen des Get-Requests auf LABROU Auswertung Nach der Versuchsdurchführung richten wir den Blick auf die beiden SNMP Datagramme, welche während der SNMP Abfrage aufgezeichnet wurden. Der Network Analyzer zeigt grafisch, dass das SNMP Protokoll auf dem User Datagram Protocol aufbaut. Es kann auch festgestellt werden, dass der MIB Browser die Anfrage an den Destination Port 161 gerichtet hat. Als Source Port wird wie üblich ein dynamischer Port verwendet. Derselbe dynamische Port wird später im get-response Datagram vom Cisco Router als Destination Port verwendet. In dieser Analyse wird auch der Community String sichtbar gemacht. Spätestens jetzt dürfte klar sein, dass SNMPv2 keine Gruppe 7 21 / 49

22 Sicherheitsmechanismen implementiert. Zu guter Letzt sind im Datenteil des get-requests auch das abgefragte Objekt und der dazugehörige OID aufgeführt. Abbildung 19: SNMP Protokollanalyse: Die get-request Operation. Das get-response Datagramm sieht dem get-request Datagramm ziemlich ähnlich zumindest auf den ersten Blick. Quell- und Zieladressen sowie Quell- und Zielports wurden vertauscht. Im Datenteil des SNMP Protokolls befindet sich neu aber der Wert des abgefragten Objekts: SNMPv2-MIB::sysLocation: SecurityLab. Um die get-request Anfrage eindeutig zu identifizieren hat der Sender eine request-id (hier: ) mitgesandt. Diese wird nun vom Empfänger quittiert. In der get-response Nachricht bleibt diese request-id unverändert. Nur so ist es dem Sender möglich, die Antwort zu einer getätigten Anfrage zu mappen. Dieser Sachverhalt wurde bereits im Theorieteil diskutiert. Das Laborbeispiel bestätigt die Theorie. Abbildung 20: SNMP Protokollanalyse: Die get-response Operation. Gruppe 7 22 / 49

23 3.4.2 Versuch 2: SNMP Protokollanalyse an LABSRV11 Im zweiten Versuch wird beabsichtigt, SNMP Informationen aus einem Apache DMZ Webserver herauszuholen. Hierzu wurde ein Debian Linux Server in die vorgängig aufgebaute Demilitarized Zone (VLAN40) gestellt. Die nachfolgende Illustration zeigt den schematischen Aufbau dieses Versuchs. Client Network Netzwerk: / 22 VLAN: 20 MIB Browser Network Analyzer (Promiscuous Mode) Fa0/5-8: VLAN 20 Fa0/23: Monitor Port labsw01 Fa0/10: VLAN 30 Fa0/9: VLAN 30 Fa0/24: 802.1q Trunk Fa0/1: /30 Fa0/0: 802.1q Trunk Fa0/0.10: /22 Fa0/0.20: /22 Fa0/0: /30 labfw01 Fa0/1: /24 Fa0/13: VLAN 40 labrou01 Fa0/14-16: VLAN 40 DMZ Network Netzwerk: / 24 VLAN: 40 labsrv11 IP Adresse: Debian Linux / Apache Abbildung 21: Schematischer Aufbau des Laborversuchs 2. Eine zentrale Rolle nimmt in diesem Versuch die Firewall LABFW01 ein. Diese regelt den Verkehr zwischen den Sicherheitsbereichen INSIDE, DMZ und OUTSIDE. (Aus lizenztechnischen Gründen konnten in diesem Versuch nur zwei der vorgesehenen drei Schnittstellen eingerichtet werden. Interface OUTSIDE spielt aber ohnehin keine massgebende Rolle und wird nur der Vollständigkeit wegen abgebildet). Die nachfolgende Tabelle illustriert die Zuordnung zwischen den VLANs und den konfigurierten Firewall Interfaces: VLAN ID Bezeichnung Firewall Interface 30 Transit_LAN_30 INSIDE 40 DMZ_Network DMZ 50 Transit_LAN_50 OUTSIDE Tabelle 3: Das Mapping zwischen VLANs und Firewall Interfaces. Die Firewall wurde bereits in der Phase des Laboraufbaus mit einigen grundlegenden Regelsätzen bestückt. Es ist absehbar, dass diese Regeln im Verlauf des Versuchs ergänzt werden müssen. Es gibt verschiedene Möglichkeiten, Regeln auf einer Firewall zu administrieren. In diesem Beispiel werden nur eingehende Regeln definiert ausgehende Regeln werden immer erlaubt (Source: any, Destination: any, Aktion: permit). Gruppe 7 23 / 49

24 Nr. Quelle Ziel Dienst Aktion Beschreibung INSIDE (Incoming Rules) 1 any labsrv11 icmp permit 2 any labsrv11 ssh permit 3 any labsrv11 http permit 4 any any Ip deny Implizite Regel INSIDE (Outgoing Rules) 1 any any ip permit Erlaubt sämtliche IP Pakete 2 any any ip deny Implizite Regel DMZ (Incoming Rules) 1 labsrv11 any icmp permit 2 any labsrv11 http permit 3 labsrv11 labsrv05 snmptrap permit 4 any any ip deny Implizite Regel DMZ (Outgoing Rules) 1 any any ip permit Erlaubt sämtliche IP Pakete 2 any any ip deny Implizite Regel OUTSIDE (Incoming Rules) 1 any labsrv11 http permit Ermöglicht Webzugriff auf labsrv11 2 any any Ip deny Implizite Regel OUTSIDE (Outgoing Rules) 1 any any ip permit Erlaubt sämtliche IP Pakete 2 any any ip deny Implizite Regel Tabelle 4: Konfigurierte Regeln der Firewall LABFW Erwartungshaltung Es ist zu erwarten, dass die Firewall etliche Probleme verursacht. Das Firewall Know-how der Initianten des Versuchs fehlt zu Beginn des Versuchs leider gänzlich. Mit Hilfe des Real Time Loggings sollte es jedoch möglich sein, Regelsätze für die SNMP Kommunikation zu errichten. Gruppe 7 24 / 49

25 Versuchsablauf Der Debian Linux Server musste im Vorfeld mit dem SNMP Deamon Package bestückt werden. Dazu kann folgender Befehl verwendet werden: apt-get install snmpd Standardmässig wird die SNMP Konfiguration unter /etc/snmp abgelegt. So sind dort folgende.conf Dateien zu finden: /etc/snmp/snmpd.conf Konfiguration für den Net-SNMP SNMP Agent /etc/snmp/snmptrapd.conf Konfiguration für den Net-SNMP Trap Daemon In der snmpd.conf Datei werden die beiden Attribute syscontact und syslocation angepasst: syscontact syslocation SecurityLab Mit /etc/init.d/snmpd restart wird der SNMP Daemon neu gestartet. Ein erster Versuch, die in der RFC1213 definierten MIB Objekte syscontact bzw. syslocation auszulesen, scheitert. Schuld daran ist die blockierende Firewall. Der Nachweis dafür liefert der Real Time Log, welcher auf der Firewall aktiviert wurde: Abbildung 22: SNMP/UDP Datagramme werden am Firewall Interface INSIDE blockiert. Auch im Sniffer ist der Misserfolg feststellbar: Auf die get-request Anfrage folgt keine get-response Antwort. Das mag der Grund dafür sein, dass sich der MIB Browser nach einem bestimmten Timeout dafür entscheidet, noch einmal eine get-request Anfrage auszulösen. Bemerkenswert: Die beiden get-requests haben beide dieselbe request-id. Scheinbar wird diese request-id wieder verwendet, wenn auf eine erste Anfrage keine Antwort eingeht. Abbildung 23: Die blockierten SNMP get-request Datagramme bleiben unbeantwortet. Folglich wurde eine neue Firewall Regel erstellt, welche auf dem Firewall Interface INSIDE die eingehende SNMP Kommunikation erlaubt. Die nachfolgende Tabelle bildet den vollständigen Regelsatz für eingehende Kommunikation auf dem Interface INSIDE ab: Nr. Quelle Ziel Dienst Aktion Beschreibung INSIDE (Incoming Rules) 1 any labsrv11 icmp permit 2 any labsrv11 ssh permit 3 any labsrv11 http permit labsrv11 snmp permit Laptop Thomas; nur temporär zu Testzwecken labsrv11 snmp permit Laptop Daniel; nur temporär zu Testzwecken 6 labsrv05 labsrv11 snmp permit Regel erlaubt SNMP Anfragen von labsrv05 zu labsrv11 7 any any Ip deny Implizite Regel Tabelle 5: Die Regeln der Firewall LABFW01 mussten mit neuen SNMP Regeln ergänzt werden. Gruppe 7 25 / 49

26 Auswertung Die Cisco ASA5505 ist in der Tat keine einfache Box. Insbesondere dann, wenn auch das Firewall Knowhow fehlt. Dank guter Unterstützung des Laborpersonals konnte die Firewall letztlich doch in Betrieb genommen werden. Sehr zuvorkommend war die grafische Oberfläche, genannt Adaptive Security Device Manager (ASDM), welche einige Konfigurationsarbeit erleichterte. Dank dem Real Time Logging konnte einfach festgestellt werden, welche Regelsätze neu erstellt werden mussten. Schwieriger könnte dieser Ansatz aber werden, wenn sehr viel Verkehr an die Interfaces der Firewall prallen würde. (In diesem Fall müssten womöglich Filter eingesetzt werden, um das Logging einzuschränken). SNMP-technisch war der Versuch ebenfalls ein Erfolg. Es ist nun gewährleistet, dass nur bestimmte Stationen zu bestimmten Stationen SNMP Anfragen machen können. Das macht doch das ansonsten sehr unsichere SNMP ein Stück sicherer. Gruppe 7 26 / 49

27 3.4.3 Versuch 3: Crash-Simulation mit LABSRV11 und NAGIOS Monitoring In diesem Laborversuch wird die Linux-basierte Überwachungssoftware NAGIOS zur Überwachung des DMZ Webservers labsrv11 ( ) eingesetzt. Nagios läuft in diesem Versuch nicht auf einem herkömmlichen Linux Betriebssystem, sondern auf einer Monitoring Appliance aus dem Hause Azeti. Abbildung 24: Schematischer Aufbau des Laborversuchs 3. Der LABSRV11 wird von Nagios mit dem Plugin check_host überwacht. Dieses Plugin setzt in regelmässigen Abständen einen Ping-Befehl an den überwachten Server ab. Bekommt Nagios eine Antwort, erscheint der Server grün auf der Weboberfläche der Azeti Box. Die Überwachung findet auf statt. Im Unterpunkt Hosts sind alle Überwachten Server angezeigt (siehe Abbildung). Abbildung 25: Übersicht über die von Nagios überwachten Hosts. Hier sieht man auf den ersten Blick, dass diverse Server nicht laufen. Für diesen Versuch wird allerdings nur der LABSRV11 benötigt. Weiter haben wir einen check_http Service definiert, welcher überwacht, ob eine Gruppe 7 27 / 49

28 Website noch erreichbar ist. Auf dem LABSRV11 werden die Services pingall, sshcheck und webcheck ausgeführt. Diese Services sind zuvor definiert worden und dem Host zugewiesen worden. In der Weboberfläche erscheint der LABSRV11 wie in der folgenden Abbildung gezeigt wird: Abbildung 26: Services, welche den Server LABSRV11 überwachen Erwartungshaltung Der Status des Servers wird manuell auf Menü Hosts überwacht. Wird der Netzwerklink entfernt, muss dies auf Nagios in nützlicher Frist angezeigt werden. Ist dieser Versuch erfolgreich, wird der zuvor definierte webcheck (Plugin check_http) getestet. Dazu wird der Apache-Service auf dem LABSRV11 heruntergefahren. Danach sollte dies auf der Nagios Oberfläche unter Menü Services angezeigt werden Versuchsablauf Host Wir gehen auf die Seite Menü Hosts und kontrollieren den Status des Servers. Status ist auf up. Nun entfernen wir das Netzwerkkabel um so einen Crash des Servers zu simulieren. Die Zeit wird gestoppt um zu sehen wie, lange es dauert, bis die Meldung auf der Oberfläche ersichtlich ist. Abbildung 27: Nach genau 2 Minuten erscheint die Meldung DOWN auf der Oberfläche. In der Service Definition ist festgelegt, dass solche Änderung versendet werden (siehe Abbildung, Servicedefinition des webcheck Services). In der Festgelegten Zeitperiode Status 7x24 werden Meldungen verschickt wenn Critical, Recovery, Unknown oder Warning Events auftreten. Da wir im Labor über keine Internetanbindung verfügen, wurde dieses Versenden hier nicht getestet. Nächster Schritt besteht im Wiederanschliessen der Netzwerkkabel. Auch hier wird wieder die Zeit gemessen, die der Wechsel auf UP benötigt. Abbildung 28: Definition der Kontaktgruppe Pikett. Abbildung 29: Nach ungefähr 45 Sekunden ist die Anzeige wieder auf UP. Beim Service wird check attempt auf den Wert 1 eingestellt. Jetzt wollen wir schauen, ob die Meldung DOWN schneller erscheint. keine Änderung siehe Auswertung Versuchsablauf Services Jetzt wird auf dem LABSRV11 der Apache Dienst abgeschaltet und somit haben wir nun keinen Zugriff auf die html-seite des Webservers mehr. Auch hier werden wir wieder messen, wie lange es dauert, bis uns die Meldung erreicht. Abbildung 30: Nach nur 30 Sekunden ist die Meldung CRITICAL auf unserer Überwachung erschienen. Nun starten wir den Service wieder und schauen auf die Zeit. Gruppe 7 28 / 49

29 Abbildung 31: Nach 30 Sekunden ist die Meldung OK wieder erschienen Versuchsablauf Webcheck Mit obiger Service-Definition kann man ermitteln, ob der Webservice läuft. Ob allerdings die korrekte Seite angezeigt wird, wissen wir nicht. Dazu Ändern wir die Einstellungen des Services webcheck. Wir kontrollieren ob das Wort works im Text vorkommt. Dazu wechseln wir im Admin-Interface auf die Service-Definitionen und wählen webcheck aus. Hier können diverse Individualisierungen unter dem Punkt Commands eingestellt werden (siehe Abbildung): Abbildung 32: Punkt Commands des Plugins check_http: Individuelle Abfragen werden hier eingerichtet. Wir tragen nun bei String to expect in content (optional): das Wort works ein. Und ändern die index.html auf dem Apache Server ab, damit das Wort works nicht mehr vorkommt. Nach etwa einer Minute erhält der Service webcheck den Status CRITICAL (siehe Abbildung): Abbildung 33: Nach 30 Sekunden ist die Meldung OK wieder erschienen Auswertung Die Dauer bis der Server auf DOWN gesetzt wird, wenn die Netzwerkverbindung unterbrochen wird, kann damit erklärt werden, dass bei der Service Definition der Wert check attempts auf 3 eingestellt wurde. Somit versucht meldet Nagios erst nach dem dritten Fehlschlag, dass der Server down ist. Ist hingegen ein Ping erfolgreich, wird sofort UP gemeldet, da gleich der Server beim ersten erfolgreichen Versuch als funktionierend betrachtet werden kann. Der von uns definierte Service pingall hat keinen Einfluss auf die Anzeige beim Menü Hosts. Bei diesem Menü werden alle Hosts die bei Nagios eingebunden worden sind automatisch geprüft mit Ping. Eine Statusänderung beim Service mit check_http wird viel schneller erkannt als ein check_host mit einem Ping. Um dies zu verifizieren, haben wir noch einmal die Netzwerkkabel entfernt und sind auf Services Seite auf den Dienst, welcher den ping absetzen sollte. Hier kann man einen Check forcieren. Danach dauerte es bis zu drei Minuten, bis der Check ausgeführt wurde. Diese Zeitunterschiede lassen sich dadurch erklären, dass es zwischen dem Ausführungszeitpunkt des Gruppe 7 29 / 49

30 Checks und dem erscheinen in der Weboberfläche Verzögerungen von bis zu einer Minute kommt. Beispielsweise meldet ein Service Down und bei Last Check um 16:08:10, aber diese Meldung erscheint erst um 16:09:06 (bei ständiger Aktualisierung durch Testteam) im Browser. Der check_http hat viele Einstellungsmöglichkeiten. Das kontrollieren des Strings hat Problemlos funktioniert. Damit kann die Firmenhomepage kontrolliert werden und sollte sich jemand am Inhalt zu schaffen machen, würde man informiert werden. Auch wenn durch einen Fehler eine Umleitung auf eine andere Seite vorgenommen wird, kann man so kontrollieren, dass die gewünschte Seite am laufen ist. Mit der Azeti Nagios Box kann man mit Hilfe der mitgelieferten Plugins sehr viele Abfragen durchführen. Mit den verschiedenen Plugins lässt sich das Monitoring sehr individuell einrichten und somit können für beinahe alle Bedürfnisse Überwachungen konfiguriert werden. Alle möglichen Einstellungen und Konfigurationen in Laborversuchen auszutesten, würde den Rahmen der zur Verfügung stehenden Zeit sprengen. Man kann allerdings festhalten, dass dieses Gerät mit einem überschaubaren Zeitaufwand konfiguriert und eingesetzt werden kann. Gruppe 7 30 / 49

31 3.4.4 Versuch 4: Config Notification Trap auf LABROU01 SNMP Geräte können, wie dies im Theorieteil erklärt wurde, in bestimmten Situationen Informationen mit Hilfe von SNMP Traps aktiv von sich geben. Diese nicht unwesentliche Funktion von SNMP in diesem Versuch anhand eines Praxisbeispiels erklärt werden. Auf LABROU01 werden SNMP Traps eingerichtet, welche Informationen an den SNMP Manager (Nagios Appliance; ) versenden. In diesem Versuch soll mit Hilfe von SNMP Traps festgestellt werden, wenn ein Ethernet Interface des Routers LABROU01 ausfällt, d.h. den Status down auftritt. Abbildung 34: Schematischer Aufbau des Laborversuchs Erwartungshaltung Es wird erwartet, dass nach dem Ausziehen des Patchkabels an FastEthernet 0/1 automatisch ein SNMP Trap von an gesendet wird. Fraglich ist jedoch, ob die Nagios Appliance die empfangenen Traps auswerten kann. Nagios wird womöglich nicht fähig sein, den Wert aus dem Trap zu lesen, weil keine passende MIB geladen wurde Versuchsablauf Der Router LABROU ist mit snmp-server enable traps snmp linkdown linkup zu konfigurieren. Nun wird das Netzwerkkabel an Routerport Fa0/1 herausgezogen. Ein Trap wird automatisch los gesendet. Das Netzwerkkabel wird wieder eingesteckt. Soeben wird auf dem Network Analyzer ein zweiter Trap ersichtlich. Gruppe 7 31 / 49

32 Auswertung Auf dem Network Analyzer wird ersichtlich, dass nicht nur ein linkdown Trap übertragen wurde. Beim Einstecken des Kabels wurde sogleich ein linkup Trap versendet. Ein intelligentes Überwachungssystem könnte diese Traps handeln und entsprechende Warnungen bzw. Entwarnungen an Systembetreuer weiterleiten. Abbildung 35: SNMP Trap linkdown und linkup beim Aus-/Einstecken des Netzwerkkabels. Entgegen der Befürchtungen ist es tatsächlich möglich, mit der Azeti Nagios Appliance SNMP Traps zu empfangen. Auf der deutschsprachigen FAQ Seite unter (siehe Quellen) ist zum Thema SNMP Traps folgendes Zitat zu finden: Nagios kann auch SNMP-Traps empfangen, allerdings nicht direkt. Nagios wurde nicht als Ersatz für ein voll ausgebautes SNMP Management-System entworfen, aber Sie können Nagios so konfigurieren, dass Warnungen aufgrund von SNMP-Traps, die von irgendeinem Host im Netzwerk empfangen werden, ausgelöst werden. Um SNMP Traps auf einer Nagios Installation empfangen zu können müsste das Programm snmptt ( installiert werden. Dieses Programm beinhaltet das Nagios Plugin check_snmp_traps, mit welchem nach der Installation von snmptt Traps empfangen werden können. Bei der uns zu Verfügung stehenden Azeti Nagios Appliance ist das nicht möglich. Azeti stellt allerdings ein gleichwertiges Plugin, check_azeti_trap, zur Verfügung. Das Plugin konfiguriert man über einen Service. Dazu gehen wir auf der Administrator Oberfläche unter Setup auf Services und erstellen dort einen neuen Service. Dort wählen wir das Plugin check_azeti_trap aus. Danach können diverse Einstellungen (siehe Abbildung) vorgenommen werden. Gruppe 7 32 / 49

33 Abbildung 36: Die Azeti Nagios Appliance erlaubt das Empfangen von SNMP Traps. Als Beschreibung nehmen wir irgendeine aussagekräftige Beschreibung; hier haben wir interfacetrap genommen. Der Host kann so belassen werden. Der Trap Service läuft später unter Azeti in den Services. Unter Command geben wird die IP, die OID und den Community String an. Hier geben wir den Router als sendenden Host an und die OID gibt den Status des Interfaces fa0/1 zurück. Weiter definieren wir, wie sich der Service verhält wenn er keinen Trap empfangen hat. Hier haben wir OK definiert und sobald ein Trap erhalten wurde wird WARNING zurückgegeben. Erst wenn der String des Traps wieder ein up beinhaltet wird der Status wieder auf OK gesetzt. Weiter unten in der Konfiguration muss noch der Admin-User mit Passwort angegeben werden. Hat man das Passwort noch nie geändert kann es vorkommen, dass der Service eine CRITICAL mit dem Wert NO Password meldet. Um dies zu verhindern muss in der Admin-Oberfläche unter Accounts das Administratorpasswort definiert werden. Sind alle Einstellungen eingerichtet erhalten wir unter Services ein Bild wie folgendes: Abbildung 37: Der eingehende SNMP Trap löst in Nagios eine Warnung aus. Gruppe 7 33 / 49

34 3.4.5 Versuch 5: linkdown Trap auf LABROU01 Der vorliegende Versuch baut auf dem vorhergehenden Laborversuch auf. Auf LABROU01 werden SNMP Traps eingerichtet, welche Informationen an den SNMP Manager (Nagios Appliance; ) versenden. Es sollen sämtliche Konfigurationsänderungen, welche am Router vorgenommen werden, an den SNMP Manager gesendet werden. Bei diesem Versuch geht es hauptsächlich darum, zu zeigen, wie mächtig SNMP ist. Die Möglichkeiten von SNMP reichen jedoch noch viel weiter als sie in dieser Laborarbeit aufgezeigt werden Erwartungshaltung Der Versuch wird vermutlich erfolgreich enden. SNMP Traps können einfach produziert werden. Im vorhergehenden Versuch konnten erfolgreich SNMP Traps ausgelöst und empfangen werden Versuchsablauf Der Router LABROU1 wird so konfiguriert, dass er bei Konfigurationsänderungen einen SNMP Trap versendet. Dazu wird folgender Befehl benötigt: snmp-server enable traps config (Hinweis: Mit dem Befehl snmp-server enable traps könnten gleich sämtliche Trap Kategorien aktiviert werden, welche der Router bereitstellt. Das kann zu einer unnötigen Informationsflut führen) Die SNMP Community ist aus den vorhergehenden Beispielen immer noch NagiosReadOnly (IOS Befehl: snmp-server community nagiosreadonly) Die Trap Destination sowie die zu verwendende SNMP Version werden mit folgenden Befehlen festgelegt: snmp-server host nagiosreadonly snmp-server host version 2c public Wird nun eine Konfigurationsänderung vorgenommen, sendet der Router automatisch einen Trap an den Zielhost (Nagios Appliance). Um dieser Vorgang zu verdeutlichen, wurde eine Netzwerkanalyse gestartet. Abbildung 38: SNMP Trap Config Notification, welcher von LABROU01 abgesetzt wurde Auswertung Beim genaueren Hinsehen mit Hilfe des Network Analyzers kann festgestellt werden, dass die OID für die Identifizierung der Information genutzt wurde. Diese OID ist Teil einer Cisco Mgmt MIB, welche direkt bei Cisco heruntergeladen werden kann (siehe Quellenverzeichnis). Die agentaddr ist , also das virtuelle Interface VLAN10 von LABROU01. Dem Network Analyzers ist es verständlicherweise nicht möglich, die Information aus diesem Trap zu interpretieren. Dazu wäre die MIB nötig. Abbildung 39: SNMP Trap Config Notification, welcher von LABROU01 abgesetzt wurde. Gruppe 7 34 / 49

35 3.4.6 Versuch 6: Notification per Was bringt ein Monitoring ohne Alerting? Nicht viel Beim einem Monitoring ist es sinnvoll, im Fall eines Unterbruchs den verantwortlichen Techniker in Kenntnis darüber zusetzen. Wir wollen mit diesem Versuch einer Meldung erzwingen. Dazu wird bei der Konfiguration im Admin GUI der Nagios Appliance ein Postausgansserver eingerichtet werden (Bild). Fällt nun ein überwachter Host aus, wird über die eingerichtete Adresse eine Meldung versandt, sofern dies beim Host so konfiguriert wurde. In diesem Versuch wurde ein LAN-Printer als zu überwachender Host eingesetzt. Als E- Mail Provider wird GMX.net verwendet. Nachfolgende Zeichnung illustriert den für diese Übung verwendeten Laboraufbau. Abbildung 40: Einrichten eines neuen Empfängers in Nagios. Abbildung 41: Schematischer Aufbau des Laborversuchs Erwartungshaltung Wir überwachen einen Host mit einem check-host. Wenn wir diesen Host vom Netzwerk entfernen, sollte dies nach einiger Zeit auf der Nagios Oberfläche ersichtlich sein. Sobald dies passiert ist, müsste auch eine an die definierten Adressen gesendet werden. Wie aussagekräftig die Meldung ist, kann noch nicht abgeschätzt werden. Diese Meldung analysieren wir nach dem Versuch. Gruppe 7 35 / 49

36 Versuchsablauf Ein Host wird mit einem check-host eingerichtet. Zielgerät ist der Netzwerkdrucker hw-pr01 mit der IP Adresse Als Kontaktgruppe wird die Pikett-Gruppe ausgewählt. In dieser Pikett-Gruppe sind die Gruppenmitglieder mit ihren Adressen hinterlegt. Der Drucker wird vom Netzwerk getrennt. Auf der Weboberfläche wird unter Hosts kontrolliert, ob dieser den Status ändert. Sobald dieser ändert, sollte auch eine Mail abgeschickt werden. Sobald Meldung auf DOWN gewechselt hat, empfangen wir eine , dass der Host DOWN ist. Nun schliessen wir diesen wieder an und erwarten eine UP Meldung per . Abbildung 42: Konfiguration eines check_snmp Monitors für den Netzwerkdrucker Auswertung Die s sind umgehend nach Änderung des Staus eingetroffen. Die Aussagekraft der Nachricht ist auch gegeben wie die folgende Tabelle zeigt. DOWN Meldung Problem : PROBLEM (1) Host : hw-pr01 Hostalias: hw-pr01 Address : Hoststate: DOWN Time : :47:54 ( ) Hostcheck took seconds and returned: CRITICAL - Plugin timed out after 10 seconds Tabelle 6: UP Meldung UP- und DOWN-Meldung wie sie von Nagios als versendet wurde. Problem : RECOVERY (2) Host : hw-pr01 Hostalias: hw-pr01 Address : Hoststate: UP Time : :06:10 ( ) Hostcheck took seconds and returned: PING OK - Packet loss = 0%, RTA = 6.80 ms Als Erweiterung haben wir die auf einen von Bluewin bereitgestellten SMS Gateway umgeleitet. Der SMS Gateway leitet die Nachricht dem Supporter direkt weiter auf ein Mobiltelefon. Der Empfang funktioniert mit einigen Sekunden Verzögerung einwandfrei. Bleibt einfach zu erwähnen, dass hier mehrere Systeme bei der Weiterleitung der Störmeldung beteiligt sind. Alle diese Systeme haben ihrerseits bestimmte Ausfallzeiten. Der Swisscom SMS Dienst bietet beispielsweise eine Verfügbarkeit von nicht mehr als 99.8% (während den Geschäftszeiten) bzw. 98% (ausserhalb der Geschäftszeiten). Gruppe 7 36 / 49