Realisierung einer zentralen Überwachungslösung. für die Server des Instituts für Informatik. Projektdokumentation. Martin Steinbach.

Transkript

1 Projektdokumentation Realisierung einer zentralen Überwachungslösung für die Server des Instituts für Informatik Martin Steinbach Oktober 2008 martin-luther-universität halle-wittenberg

2 Persönliche Erklärung des Prüfungsteilnehmers Hiermit erkläre ich, Martin Steinbach, geboren am 17. Oktober 1986 in Halle an der Saale, mit meiner nachfolgenden Unterschrift, dass ich die betriebliche Projektarbeit und die damit verbundene Dokumentation selbstständig in der vorgesehenen Zeit erarbeitet habe. Ich versichere, dass die Projektdokumentation weder Teile, noch ganze Passagen aus Dokumentationen enthält, die bereits bei der prüfenden Kammer eingereicht worden sind Neustadt, Ort, Datum Unterschrift Martin Steinbach 2 von 39

3 Inhaltsverzeichnis 1. Rahmenbedingungen Ausgangslage Projektumfeld Projektauslöser Projektziel Projektphasen Ist-Zustand Umfeld Gegebenheiten Soll-Konzept Wahl der Überwachungslösung Überwachungsprinzip Überwachungskonzept Technische Umgebung Realisierung VServer Apache Nagios Clients Qualitätssicherung Sicherheitsanalyse Abschluss Zeitplanung Soll-Ist-Vergleich Folgeaktivitäten Glossar Anhang 26 A Pichtenheft B Netzübersicht C Serverübersicht D Mindmap E Produktvergeleich F Kongurationsdateien G Übergabecheckliste H Clustercheck Abbildungs- und Tabellenverzeichnis 39 3

4 1. Rahmenbedingungen 1.1 Ausgangslage Derzeit nehme ich, Martin Steinbach, an einer zivilberuichen Aus- und Weiterbildung (ZAW) der Bundeswehr zum Fachinformatiker für Systemintegtation über das Berufsfortbildungswerk (bfw) teil. Im Rahmen dieser Maÿnahme ist ein sechsmonatiges Praktikum vorgesehen, welches ich in der Rechnerbetriebsgruppe des Instituts für Informatik der Martin-Luther-Universität Halle-Wittenberg absolviere. 1.2 Projektumfeld Die Rechnerbetriebsgruppe des Instituts für Informatik ist für die Funktion und die Verfügbarkeit aller Rechnersysteme des Instituts zuständig. Das Institut für Informatik ist der III. Naturwissenschaftlichen Fakultät der Martin-Luther-Universität zugeordnet; es umfasst die Arbeitsgebiete: Theoretische Informatik, Praktische Informatik, Technische Informatik und Angewandte Informatik. Im Institut arbeiten neun Professoren und etwa 50 Angestellte, von denen der gröÿte Teil wissenschaftliche Mitarbeiter und Doktoranden sind. Für die Verwaltung der zahlreichen Server (ca. 25) und des institutseigenen Clusters ist die Rechnerbetriebsgruppe zuständig. Sie besteht aus zwei fest angestellten Diplominformatikern, einem Techniker und einigen studentischen Hilfskräften. Die Umsetzung des Projektes erfolgt ausschlieÿlich in den Räumen des Instituts. Bei der Realisierung des Projektes wird mir weitgehend Freiraum eingeräumt. Das beigefügte Pichtenheft in Anlage A beschreibt alle Kriterien, in denen ich mich frei bewegen kann. beteiligte Personen Als mitwirkende Person an dem Projekt ist die Dipl.-Inform. Annett Thüring als Leiterin der Rechnerbetriebsgruppe und Projektverantwortliche zu nennen. Martin Steinbach 4 von 39

5 1.3. PROJEKTAUSLÖSER 1.3 Projektauslöser Für die groÿe Zahl an Servern, die sich über mehrere Serverräume erstrecken, soll eine zentrale Überwachungseinrichtung realisiert werden. So sollen kurze Reaktionszeiten bei Problemen und ein reibungsloser Lehrbetrieb ermöglicht werden. 1.4 Projektziel Das Überwachungssystem muss sich in die heterogene Struktur des Instituts integrieren. Des Weiteren soll sie eine breite Palette an Diensten und lokalen Ressourcen überwachen. Auf die Vertraulichkeit der zu ermittelnden Daten ist im besonderen Maÿe einzugehen. 1.5 Projektphasen Für die Durchführung des Projektes sind 35 Stunden veranschlagt; diese verteilen sich auf die unten genannten Projektphasen. Die Kundendokumentation wird in Gestalt eines Administrationsleitfadens verfasst und auf Wunsch in sich geschlossen sein. Das Projekt wird in der Woche vom bis zum durchgeführt. Das folgende Gantt-Diagramm veranschaulicht die Projektplanung. Tabelle 1..1: Projektphasen - Zeitplanung veranschlagte Zeit in Stunden Ist-Analyse 3 Soll-Konzept 4 Realisierung 11 Qualitätssicherung 6 Kundendokumentation 11 Summe 35 Abbildung 1..1: Gantt-Projektplanung Martin Steinbach 5 von 39

6 2. Ist-Zustand 2.1 Umfeld Räumlichkeiten Die Server des Instituts erstrecken sich über vier Räume, drei von ihnen benden sich in der dritten und einer in der vierten Etage des Gebäudes. Die Räume unterscheiden sich wesentlich in der Gröÿe, jedoch kaum in der Ausstattung. In jedem Serverraum ist eine fest installierte Klimaanlage vorhanden und fast jeder Server ist mit einer Tastatur und einem Bildschirm versehen. Zugang zu allen Serverräumen wird lediglich der Rechnerbetriebsgruppe gewährt. Des Weiteren bietet das Institut seinen Studenten fünf Computerpools, von denen zwei unter Verwaltung des Universitätsrechenzentrums stehen und daher nicht in die administrativen Aufgaben der Rechnerbetriebsgruppe fallen. Die anderen drei Pools unterscheiden sich grundlegend in ihrer Ausstattung. Es existiert ein Pool mit konventionellen x86 kompatiblen Rechnern, auf denen lokale Betriebssysteme (Windows XP, Ubuntu GNU/Linux) installiert sind und ein Thinclient-Pool, dessen Rechner auf einen Windows- und einen GNU/Linux- Terminalserver zugreifen. Auÿerdem ist ein Unix-Pool, auf dessen SPARC-Workstations lokal Solaris 10 installiert ist und dessen Sunrays 1 ebenfalls auf einen Solaris 10 Terminalserver angewiesen sind, vorhanden. Netzwerk Im Institut ist das Prinzip der strukturierten Gebäudeverkabelung realisiert wurden. Im Erdgeschoss bendet sich der Gebäudeverteiler in Form eines Catalyst Switches. Ihm sind mehrere verwaltbare Switches, welche ebenfalls als Firewall und Gateway dienen, untergeordnet. Die Primärverkabelung (1000 BASE-LX) führt direkt zum Universitätsrechenzentrum, welches wiederrum an das Deutsche Forschungsnetz 3 (DFN) angeschlossen ist. Für die Sekundärverkabelung wird gröÿtenteils Glasfaser als Übertragungsmedium verwendet. Als Grundlage für die Tertiärverkabelung dient vornehmlich Kupfer, wobei einzelne Server auch mittels Glasfaser angebunden werden. 1 Thinclientprodukt der Firma Sun Microsystems 2 Switch-Firewallprodukt der Firma Cisco 3 ca. 10 GBit/s Martin Steinbach 6 von 39

7 2.2. GEGEBENHEITEN Dem Institut wurden vom DFN drei Klasse-C-Netzsegmente ihres Netzwerks zugeordnet. Selbige sind den Bedürfnissen entsprechend in Port-basierende Vlans unterteilt, um DMZ und Studentennetzwerke von Mitarbeiter- und Servernetzen klar abzugrenzen. Eine detailliertere Übersicht über die einzelnen Netze des Instituts bendet sich in der Anlage B. Serversysteme Als Server werden neben x86 kompatiblen Rechnern auch auf der SPARC-Plattform basierende Server eingesetzt. Folglich existiert eine heterogene Betriebssystemumgebung. Es werden neben Microsoft Windows eine Vielzahl von verschiedenen unixoiden Betriebssystemen auf Servern und Klienten eingesetzt. Solaris in Version 10 und 9 beschränkt sich lediglich auf die SPARC-Server, währenddessen Linux in Form verschiedener Distributionen auf den x86 kompatiblen Rechnern vorliegt. Einen Überblick in tabellarischer Form verschat Anlage C. Innerhalb des Instituts werden die Server in drei gröÿere Gruppen unterschieden. Zum Ersten die zentralen Server, welche hauptsächlich verwaltende Aufgaben übernehmen. Die Arbeitsgruppenserver dienen den unterschiedlichen Arbeitsgruppen als Arbeitsplattform und Massenspeicher für persönliche Verzeichnisse. Für rechenintensive Aufgaben nden sich auch eine Reihe hochperformanter Rechner im Institut, deren Mittelpunkt der 32 Knoten Cluster HALC bildet. 2.2 Gegebenheiten Im Institut exisitiert keine globale Überwachungsmöglichkeit für Serversysteme. Einzelne Solaris-Server prüfen über Skripte bestimmte lokale Dienste, um bei einem Ausfall eine E- Mail zu generieren. Jedoch wurden diese Skripte lange Zeit nicht gepegt und sind zum gröÿten Teil bereits deaktiviert. Andere Systeme besitzen Serviceprozessoren 4, über welche man Zustandsinformationen des Servers in Erfahrung bringen kann. Dies betrit allerdings vornehmlich die Hardware. Darüber hinaus benden sich die Schnittstellen der Serviceprozessoren in einem eigenen Netz mit strenger Zugrisreglementierung. Diese Sachlage führt dazu, dass ausgefallene Dienste und Systeme erst dann erkannt werden, wenn ein Zugri auf diese vorgenommen wird. Dadurch kann der Lehrbetrieb beeinträchtigt werden. 4 Unabhängig vom Rechner arbeitende eingebettete Systeme mit eigenem Betriebssystem Martin Steinbach 7 von 39

8 3. Soll-Konzept In einem vorangestellten Gespräch mit der Projektverantwortlichen wurden Bedingungen für die Auswahl einer Lösung erörtert. Die Ergebnisse dieser Erörterung sind als Mindmap im Anhang D hinterlegt. 3.1 Wahl der Überwachungslösung Nach Analyse von drei Softwareprodukten (Anhang E) el die Entscheidung zugunsten von Nagios aus. Verglichen wurden die Produkte nach dem im Vorgespräch zusammengetragenen Kriterien. Je nach Erfüllung der Kriterien wurden Punkte an die einzelnen Lösungen vergeben. Ist ein Kriterium nicht erüllt, so sind keine Punkte vergeben wurden. Die meisten Bewertungspunkte (30 von 31) erreichte Nagios, da es fast alle vorgegebenen Bedingungen erfüllt. Demnach ist es modular erweiterbar und ermöglicht die Überwachung einer Vielzahl von Netzwerkservices und lokalen Ressourcen. Die Ergebnisse dieser Tests werden zentral über ein Webinterface verfügbar gemacht, welches auch ein Kommandointerface bietet und so eine Interaktion mit dem Nutzer ermöglicht. Die Übertragung der Testergebnisse an den Server kann über mehrere Wege erfolgen und wird standardmäÿig einer Verschlüsselung unterzogen. Des Weiteren wird Nagios unter der GPL 1 veröentlicht und freut sich groÿer Beliebtheit, so dass eine ständige Weiterentwicklung dieser kostenfreien Software sichergestellt ist. 3.2 Überwachungsprinzip Nagios ist mit Hilfe seiner Plugins in der Lage eine groÿe Bandbreite an Netzwerkdiensten und lokalen Ressourcen zu überwachen. Diese tests werden als Services bezeichnet. Es wird dabei nicht unterschieden, ob ein Service z.b. einen Netzwerkdienst oder einen lokalen Dienst überwacht. Lediglich der Status des Services entscheidet, ob ein Test eine Benachrichtigung auslöst. Ein beispielhafter Testverlauf sieht folgendermaÿen aus: Der Nagiosdienst übergibt im voraus eingerichtete Parameter an ein Plugin und führt dieses aus. Das Plugin 2 führt seinen Test durch und sendet, je nach mitgegebenem Schwellenwerten, einen Rückgabewert an den Nagiosdienst. Standardisierte Rückgabewerte sind: OK, 1 General Public License 2 Funktionsweisen verschiedener Plugins nden sich im Administrationsleitfaden (2.1.2) Martin Steinbach 8 von 39

9 3.3. ÜBERWACHUNGSKONZEPT WARING, CRITICAL und UNKNOWN 3. Die Rückgabewerte beeinussen den Status des Services. Solange der gleiche Rückgabewert geliefert wird, bendet sich der Service in einem sogenannten HARD-STATE. Sollte sich der Rückgabewerte des Plugins ändern, geht der Service in einen SOFT-STATE über. In diesem Status wird noch keine Benachrichtigung versandt. Nach einer vordenierten Zahl an Testwiederholungen geht der Service abermals in einen HARD-STATE, es wird eine Benachrichtigung verschickt und das normale Testintervall wird wieder aufgenommen. Analog zu den Servicetests existieren auch die Hostchecks. Diese testen lediglich die Erreichbarkeit des Hostes und sind ansonsten identisch mit den Servicetests. 3.3 Überwachungskonzept Die Überwachung beschränkt sich auf die Unix- und Linux-Server des Instituts und deren Netzwerkdienste. Die Tabelle im Anhang C zeigt neben dem installierten Betriebssystem und der primären Funktion des Servers auch die Netzwerkdienste, für die ein Test eingerichtet werden soll. Auf allen aufgezählten Rechnern sollen zudem auch die Kapazität aller Partitionen, Load-Faktor, Prozessanzahl, Zeit, Swap und wenn möglich CPU- oder Gehäusetemperatur überwacht werden. Für die lokale Überwachung ist es erforderlich, auf allen Servern die Nagiosplugins zu hinterlegen, einen neuen Benutzer einzurichten sowie den NRPE-Daemon 4 oder einen SSH-Zugang für die entfernte Ausführung der Plugins einzurichten. 3.4 Technische Umgebung Der Nagiosserver soll auf einem schon existierenden GNU/Linux-VServer lauähig sein, genauere Spezikationen sind in Anhang A beschrieben. Der Nagiosdienst benötigt neben seinen Plugins auch noch andere Dienste, um ein komplettes Überwachungssystem darzustellen. Das Ausliefern des Webinterfaces wird der Apache-Webserver übernehmen, er soll aus Sicherheitsgründen das Webinterface nur über HTTPS zur Verfügung stellen. s sollen durch den Nullmailer an den institutseigenen Mailserver versandt werden. 3 engl. Okay, Warnung, kritischer Zustand, unbekannter Zustand 4 Nagios Remote Plugin Executor, er führt Plugins auf entfernten Rechnern aus und stellt die Ergebnisse für Nagios bereit. Martin Steinbach 9 von 39

10 4. Realisierung Die zur Realisierung verwendeten Programme und Werkzeuge sind gröÿtenteils freie Software 1. Darunter zählen z.b.: Openssh, Openssl, Vim, Apache, gcc uvm.. Einzige Ausnahme bilden die Systemtools von Solaris. Diese werden unter einer suneigenen Closed-Source Lizenz veröentlicht. Als Shell wird unter GNU/Linux und Solaris die Bash verwendet. Zur Dokumentation wird das Textsatzsystem LATEX sowie das Versionskontrollsystem Subversion verwendet. 4.1 VServer Da die Überwachungslösung später auf einem VServer lauähig sein soll, wird auch die Entwicklungsumgebung auf einem VServer installiert. Dazu muss im Vorfeld ein Solcher auf dem VServer-Host erstellt werden. Für diesen Zweck existiert ein Template-VServer, der unter Angabe einer neuen IP-Adresse und eines neuen Namens dupliziert wird. # dupvserver ip xx.xx from vs-template to vs-nagios Der VServer-Host besitzt eine eigene physikalische Netzwerkkarte für jedes Netz im Institut. Daher muss dem VServers vor dem ersten Start die richtige Geräteadresse, über die er kommunizieren soll und die korrekte Netzwerkmaske mitgegeben werden. Ebenso benötigt jeder VServer eine spezielle Identikationsnummer, diese wird primär vom System verwendet. # echo eth5 > /etc/vservers/vs-nagios/interfaces/dev # echo 26 > /etc/vservers/vs-nagios/interfaces/prefix # vserver vsnagios start && vserver vsnagios enter Um aktuelle Softwarepakete zu installieren, mussten noch die Quellen der Debian-Repositories eingetragen und deren Priorität verändert werden. Das Debian-Paketverwaltungswerkzeug aptitude greift dazu auf die Dateien /etc/apt/sources.list und /etc/apt/preferences zu. Aktuelle und getestete Softwarepakete nden sich im testing-repository des Debianprojektes, als Bezugsquelle wurde der Ftp-Server der Technischen Universität Chemnitz verwendet. Da ausschlieÿlich Pakete aus einem Repository installiert wurden, konnte auf eine 1 Denition: Martin Steinbach 10 von 39

11 4.2. APACHE Priorisierung verzichtet werden und dem aktuellen Repository die höchste Priorität zugeteilt werden. #Sources.list deb testing main deb testing/updates main #preferences Package: * Pin: release testing Pin-Priority: 1001 Die Installation von weiterer Software erfolgte mit Hilfe von aptitude. Die Abhängigkeiten und Besonderheiten zum Nagiosinstallationspaket sind im Abdministrationsleitfaden im Unterpunkt 1.1 und 1.2 beschrieben. Vor der Installation wurde die lokale Paketdatenbank aktualisiert und das System auf den neusten Stand gebracht. # aptitude update && aptitude upgrade # aptitude install vim openssh-server nagios3 nagios3-common Mail Transfer Agent Im Gegensatz zu vollwertigen und komplexen Mail Transer Agents wie Sendmail, Exim oder Postx, wurde der Nullmailer zur Mailweiterleitung eingesetzt. Dieser läuft als Dienst und leitet die von Nagios ausgelösten s an den Mailserver des Instituts weiter. Das vereinfacht die Konguration und verhindert fehlerhafte Einstellungen die zu Sicherheitlücken führen können. 4.2 Apache Die Installation des Apache wurde als Abhängigkeit zum Paket nagios3-common automatisch durchgeführt. Es bestand auch die Möglichkeit den kleineren und einfacher zu kongurierenden Lighttpd zu installieren. Dieser besitzt ebenfalls ein CGI-Interface 2 und unterstützt die Übertragung über SSL. Allerdings wird auf den meisten Servern des Instituts, wo Webservices angeboten werden, der Apache Webserver verwendet. Demnach verfügen die meisten Administratoren bereits über Erfahrungen mit diesem Dienst und müssen sich nicht neu einarbeiten. Installiert wurde die zur Zeit der Projektdurchführung aktuellste Version des Webservers. Für die SSL-Unterstützung und die CGI-Schnittstelle mussten zwei Apache-Module zusätzlich geladen werden. 2 fastcgi Martin Steinbach 11 von 39

12 4.2. APACHE # a2enmod ssl cgi Damit der Apache die Nagios-Webseite ausliefert, musste ein neuer vhost mit SSL - Unterstützung erstellt werden. Die benötigten SSL-Zertikate wurden mit einem Skript 3, dass an die institutseigene CA angepasst ist, erstellt. Dieses Skript generiert mit Hilfe von Openssl ein gültiges X509-Zertikat mit einem 4096 Bit langen RSA-Schlüssel. Das Zertikat wurde auch gleichzeitig von der institutseigenen Zertizierungsstelle 4 signiert. Ein weiteres Skript extrahierte den privaten Schlüssel vom Zertikat in eine eigene Datei. Diese beiden Dateien (Zertikat und Schlüssel) sind für eine SSL-verschlüsselte HTTP-Verbindung erforderlich und wurden über folgende Apache-SSL-Direktiven in den neu erstellten vhost eingefügt: SSLCertificateFile /etc/apache2/cert/inf-stat.newcert.pem SSLCertificateKeyFile /etc/apache2/cert/inf-stat.newkey.pem Als weitere wichtige Einstellungen am vhost wurden Aliase und Skriptaliase hinzugefügt, diese müssen auf die real existierenden und ausführbaren CGI-Programme zeigen. Das Nagios Webinterface wurde durch die Allow from All-Direktive von überall erreichbar gemacht. In der Datei /etc/nagios3/htpasswd.users wurde eine Benutzerdatenbank erstellt. Die Benutzer, die in dieser Datei gelistet sind, das Passwort wissen und eine korrekte SSL-Verbindung zum Server aufgebaut haben, sind in der Lage das Webinterface zu betreten. Die Benutzer wurden mithilfe des Programms htpasswd, mittels der Option sichere SHA-Hashes zu erzeugen, angelegt. Die vollständige vhost-kongurationsdatei kann im Anhang F eingesehen werden. # htpasswd -s /etc/nagios3/htpasswd.users nagiosuser # htpasswd -s /etc/nagios3/htpasswd.users nagiosadmin Die CGI-Programme sind in der Lage die Berechtigungen für unterschiedliche Nutzer zu erkennen. Die Berechtigungslisten nden sich in /etc/nagios3/cgi.cfg (vgl. Administrationleitfaden 2.3.1). Der Nutzer nagiosadmin wurde in jede Berechtigungsliste eingetragen, er kann damit alle Hosts und Services einsehen sowie das Kommandointerface nutzen. Der Nutzer nagiosuser wurde hingegen nur in die Listen authorized_for_all_services=nagiosadmin und authorized_for_all_hosts=nagiosadmin eingetragen. Dadurch kann er lediglich den Status der Hosts und Services betrachten. Das Kommandointerface wird über eine Pipe realisiert. Vor der Inbetriebnahme von Nagios wurden ihr korrekte Zugrisberechtigungen gegeben. Gleichzeitig wurde der Debian Paketdatenbank mitgeteilt, dass die Berechtigungen für die Pipe auch nach einem Upgrade des Nagios-Pakets beibehalten werden sollen. 3 Name, Bedienung und Speicherort aus Sicherheitsgründen nicht veröentlicht 4 CA-Zertikat und Revokation-List des Instituts: Martin Steinbach 12 von 39

13 4.3. NAGIOS # dpkg-statoverride update add nagios www-data 2710 /var/lib/nagios3/rw # dpkg-statoverride update add nagios nagios 751 /var/lib/nagios3 4.3 Nagios Auf Wunsch der Projektverantwortlichen wurde ein ausführliches Administrationshandbuch verfasst. Dieses Handbuch bildet ein in sich geschlossenes Dokument und ist Teil der Projektdokumentation. Die Konguration von Nagios wird dort umfassend erläutert. Aus diesem Grund wird in diesem Abschnitt der Dokumentation nur in speziellen Fällen genauer auf die Konguration von Nagios eingegangen. Die Konguration wurde in der Datei /etc/nagios3/nagios.cfg vorgenommen. Es war nicht notwendig alle Optionen zu ändern, da die Standardkonguration schon sinnvolle Voreinstellungen mitbringt. Erwähnt sei, dass diese Datei eine Länge von ca Zeilen besitzt und über 100 Optionen verfügt. Es wurde eine Kontaktadresse und die zu ladenden Kongurationsdateien angegeben, da die Standardkongurationsdateien durch eigene ersetzt wurden. Die Debuggingausgabe wurde aktiviert, um eine einfachere Fehlerbehandlung zu ermöglichen. Damit die Logdateien nicht ins Unermessliche wachsen, wurde die interne Logrotation im Tagesintervall aktiviert. Zuvor musste noch der Ordner 5, in dem Nagios später die Logdateien hinterlegt, erstellt werden. admin_ =wihi@informatik.uni-halle.de cfg_dir=/etc/nagios3/common cfg_dir=/etc/nagios3/servers cfg_file=/etc/nagios3/commands.cfg debug_level=2 log_rotation_method=d Neben der Erstellung eines neuen Nutzers und einer Gruppe mit dem Namen Nagios, wurden auch ein Startskript sowie Runlevel-Einträge vom Debian-Paket angelegt. In der Datei /etc/nagios3/common/contacts.cfg 6 wurde das Nagios-Kontaktobjekt angelegt. Der Kontaktname lautet nagiosadmin. Die Adresse, an die Benachrichtigungen versandt werden, wurde ebenfalls in dieses Objekt eingetragen. Die vorhandene Zeitperiode ist in der Datei /etc/nagios3/common/timeperiods.cfg 6 deniert wurden. Es existiert nur eine Zeitperiode, in der Tests durchgeführt werden sollen: 24 Stunden am Tag, sieben Tage die Woche. Als nächster Schritt wurden Kommandos eingerichtet, diese werden später durch die Serviceobjekte aufgerufen. Im Abschnitt F des Anhangs ndet sich ein Ausschnitt aus der Kommandodenitionsdatei /etc/nagios3/commands.cfg. Die Hostobjekte sind zu Gunsten der 5 /var/log/nagios3 6 siehe Anhang F Martin Steinbach 13 von 39

14 4.3. NAGIOS Übersicht in mehrere Dateien verteilt wurden. Tabelle 4..1: Hostobjekt - Kongurationsdateien Kongurationsdatei Funktion /etc/nagios3/servers/ arbeitsgruppen-server.cfg Hostkonguration-AGs linux-server.cfg Hostkonguration-linux unix-server.cfg Hostkonguration-Solaris windows-server.cfg Hostkonguration Windows In jeder dieser Dateien bendet sich auch ein Referenzobjekt, von dem alle anderen Hostobjekte Eigenschaften erben. Ein Ausschnitt aus der Datei arbeitsgruppen-server.cfg bendet sich im Anhang. Der gröÿte Teil der Konguration umfasst die Serviceobjekte, sie sind in der Datei /etc/nagios3/servers/services.cfg deniert. Ein Serviceobjekt besteht hauptsächlich aus einem Verweis auf ein Kommandoobjekt und einem oder mehrerer Hostobjekte, auf denen später das Kommado ausgeführt werden soll. Wie schon in den Hostobjektkongurationsdateien wurde von mir auch hier ein generischer Service verwendet. Von ihm erben alle anderen Serviceobjekte ihre Benachrichtigungs- und Zeitperioden-Einstellungen. Als Services zählen sowohl Tests der Netzwerkdienste, als auch Checks der lokalen Ressourcen. Im Anhang F nden sich Ausschnitte aus der Kongurationsdatei Clients Für den Test von lokalen Ressourcen existieren ebenfalls Nagiosplugins. Damit deren Testergebnisse durch den Nagiosserver abgefragt werden können, wurden auf jedem GNU/Linux- Server 7 der Dienst nrpe und die Nagiosplugins installiert. Auf Solaris-Servern wurde ein Remote-Login per ssh mit einen Schlüsselpaar mit leerer Passphrase eingerichtet. Das erlaubt das entfernte Ausführen der Plugins. GNU/Linux-Server Für die Server, die unter Debian und Ubuntu laufen, existieren schon fertige Pakete für den nrpe-dienst. Installiert wurden diese per aptitude: # aptitude install nagios-nrpe-server nagios-plugins-standard C nagios-plugins-basic Der NRPE ist auf diesen Systemen sofort lauähig und bedarf nur noch einer Kommandokon- guration. 7 vgl. Anhang C Martin Steinbach 14 von 39

15 4.3. NAGIOS Für die Server mit SUSE-Installationen existieren keine Onlinerepositories mehr. Daher wurden die benötigten Pakete von einer SUSE-CD auf die jeweiligen Server kopiert und dort installiert: # rpm -iv nagios-nrpe x86_64.rpm nagios-plugins x86_64.rpm Auf den SUSE-Installationen ist der nrpe kein eigenständiger Dienst, sondern wird bei jeder Anfrage temporär durch den xinetd-dienst aufgerufen. Um den xinetd mitzuteilen wo der nrpe lokal gespeichert ist und welcher Rechner auf diesen zugreifen darf, wurde in dem Verzeichnis /etc/xinet.d/ eine Konguration für diesen angelegt 8. Auf dem Loginknoten des Clusters wurde ebenfalls der nrpe 9 in Verbindung mit dem xinetd zur Testdatenübermittlung verwendet. Dieser wurde mit den Plugins aus den Quellen heraus in das Verzeichnis /usr/local/nagios/ übersetzt. Die einzelnen Knoten wurden auf dem Nagiosserver als Service dem Masterknoten untergeordnet, da dieser die Knoten auf ihre Verfügbarkeit 10 testet. Aus Gründen der Performance und der niedrigeren Relevanz der ermittelten Daten, wird bei der Datenübermittlung auf eine Verschlüsselung mittles SSL verzichtet. Bevor allerdings eine Übermittlung der Testergebnisse stattnden konnte, musste eine neue Firewallregel auf dem Loginknoten gesetzt werden. Diese wurde in die Datei /etc/sysconfig/iptables eingetragen: -A INPUT -m state state NEW -p tcp dport nrpe -j ACCEPT Solaris Zu Beginn wurde auf jedem Solaris-Server eine neue Gruppe und ein neuer Nutzer angelegt. Dieser wird später die Plugins ausführen. # groupadd -g 413 nagios # useradd -d /home_local/nagios -m -g nagios -k /etc/skel -u 413 nagios Anschlieÿend musste in der Passwortdatei /etc/shadow anstelle des Passworthashes des Benutzers nagios ein Stern eingefügt werden, damit ein Login über das Public-Key Verfahren ohne Passworteingabe möglich wird. Die Plugins wurden als Quellcode heruntergeladen 11 und auf jeder Maschine separat übersetzt. Sie wurden alle in das Verzeichnis /usr/local/nagios/libexec/ installiert. 8 vgl. Administrationsleitfaden: per check_by_ssh wird SSH-Handshake geprüft 11 Martin Steinbach 15 von 39

16 4.3. NAGIOS Das benötigte SSH-Schlüsselpaar für das Public-Key Authentizierungsverfahren wurde mit Hilfe von ssh-keygen auf dem Nagiosserver erzeugt. Der geheime Schlüssel wurde in der Datei ~/.ssh/id_rsa gespeichert. Der Inhalt des öentlichen Schlüssels id_rsa.pub wurde jeweils in die ~/.ssh/authorized_keys-datei auf den verschiedenen Solarisrechnern gespeichert. # ssh-keygen -b t rsa -N -C nagios-key-pair -f id_rsa Kommandokonguration Die auszuführenden Kommandos wurden auf den GNU/Linux-Systemen direkt in die Datei /etc/nagios/nrpe.cfg 12 eingetragen. Ebenfalls wurde in der Konguration angegeben, dass sich nur der Nagiosserver an den nrpe binden darf. Die eingetragenen Kommandos werden von dem, auf dem Nagios-Server installierten, check_nrpe-plugin angesprochen. Dazu mussten auf dem Nagiosserver ein neues Kommandoobjekt und jeweils neue Serviceobjekte deniert werden. Für den Check von lokalen Ressourcen auf den Solaris-Servern musste für jeden möglichen Test ein eigenes Kommandoobjekt erstellt werden. Als Grundlage diente dabei das check_by_ssh- Plugin, ihm wurde der Pfad zu dem privaten Schlüssel und das entfernt auszuführende Kommando mitgegeben. Zugehörige Serviceobjekte wurden ebenfalls erstellt. Folgende Grak zeigt einen Ausschnitt des Institutsnetzes. Im Server-VLan bendet sich der VServer- Host. Der zentrale Cisco-Switch verwaltet über mehrere angeschlossene Module eine zentrale Firewall. Abbildung 4..1: Netzausschnitt Für alle oben genannten Hostobjekte und Serviceobjekte sind Beispiele im Anhang F hinterlegt. Ein beispielhaftes Überwachungsschema des Clusters HALC wurde dem Anhang im Unterpunkt G angefügt. 12 Anhang F Martin Steinbach 16 von 39

17 5. Qualitätssicherung Nachdem das Überwachungssystem auf dem Server vollständig lauähig war und alle Clients eingerichtet waren, wurden alle Kongurationen auf den Produktiv-VServer kopiert. Im Zuge dieses Vorgangs wurde eine Checkliste erstellt. Diese stellt sicher, dass keine Einstellungen und Bestandteile vergessen wurden. Die weitere Betrachtung lag schwerpunktmäÿig auf dem Schutz der zu übertragenden Daten. 5.1 Sicherheitsanalyse Die von Nagios ermittelten Daten sind als vertraulich einzustufen, da potenziellen Angreifern diese Informationen unter Umständen hilfreich sein können. Deshalb wurden so weit wie möglich alle Angrisvektoren untersucht. Das System Der Nagios-Server bendet sich in einem durch eine Alarmanlage gesicherten Serverraum. Zu diesem Raum hat niemand Zutritt auÿer den Mitarbeitern der Rechnerbetriebsgruppe. Das entfernte Einloggen über das sichere Secure Shell ist nicht direkt als Root erlaubt. Um sich dennoch entfernt auf dem Nagiosserver einzuloggen, wurde ein unprivilegierter Nutzer angelegt. Nagios arbeitet ebenfalls mit den Berechtigungen eines unprivilegierten Nutzers. Dieser Nutzer kann sich nicht am System anmelden und keine Programme ausführen. Ausschnitt aus der Datei /etc/ssh/sshd_config: PermitRootLogin no Ausschnitt aus der Datei /etc/ssh/passwd: nagios:x:104:108::/home/nagios:/bin/false Die Berechtigungen für Plugins und Kongurationsdateien wurden so gesetzt, dass nur die Nutzer Root und Nagios über Lese-, Ausführungs- und Schreibrechte verfügen. Martin Steinbach 17 von 39

18 5.1. SICHERHEITSANALYSE -rwx nagios nagios 36K :55 check_ping -rw nagios nagios 42K :50 nagios.cfg Neben den Systemdiensten und Nagios laufen nur noch der Nullmailer und Apache. Nicht benötigte Dienste wurden aus dem Mehrbenutzer-Runlevels entfernt. Folgendes Listing zeigt die einzigen Ports auf denen der Nagios-Server lauscht, es wurde mit netstat erstellt: Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 vs-inf-stat:ssh *:* LISTEN tcp 0 0 vs-inf-stat:https *:* LISTEN Ein Portscan aus dem selben Netz mit Hilfe von nmap zeigt das gleiche Ergebnis: 22/tcp open ssh (protocol 2.0) 443/tcp open ssl/http Apache httpd Datenübertragung Die Informationsübermittlung zwischen dem Nagios-Server und den Solaris-Servern wird über SSH vorgenommen. Daten werden somit nicht im Klartext übermittelt. Der geheime Schlüssel des Paares darf nicht einsehbar sein, da er zwecks der Public-Key Authentizierung nicht durch eine Passphrase geschützt ist. Der RSA-Schlüssel mit einer Länge von 2048 Bit bendet sich im Home-Verzeichnis des Benutzers Nagios und kann nur von diesem und Root gelesen werden. Der Nagios Remote Plugin Executor verwendet zum Datenaustausch mit Linux-Servern SSL: Abbildung 5..1: Nagios Remote Plugin executor Während des SSL-Handshakes wird ein Schlüssel zwischen Client und Server ausgehandelt 1, dieser ist nur für die Dauer der Verbindung gültig. Um zu überprüfen, ob tatsächlich eine Verschlüsselung zustande kommt, wurde jeweils eine verschlüsselte und eine unverschlüsselte Verbindung mit Hilfe eines Paketsniffers mitgeschnitten. Die beiden Datenbereiche der TCP-Pakete, welche die Testergebnisse beinhalten, wurden gegenübergestellt. 1 Auÿnahme bildet der Loginknoten des Clusters. Martin Steinbach 18 von 39

19 5.1. SICHERHEITSANALYSE Ausschnitt aus einer verschlüsselten Verbindung: f c eb 9e.O ,..H af 4f 90 e2 ca 3b 8b de 2b ec b2 be.w.o...; c 2f d3 de a ``y</..' IbAD...: b 0c # c9 2e 23 ec d b4 70 e2 11 a4 5c f d 25 e3 ee ee d 26 6b uu.1..%....f.m&k 00a0 b e2 8b c1 1c f8 fc 7a..PQ...a ebb...z 00b0 9c 43 2e 4f c4 1e 25 ba 0c 6c 4a a7 0e 6a f8 da.c.o..%..lj..j.. Ausschnitt aus einer unverschlüsselten Verbindung: c 6d f7 1c 51 ed f 4b 20 2d m... Q...OK c 6f a load av erage: e c e c e c.00, 0.0 0, c 6f d 30 2e b e 30 load1=0. 000; b e b 30 3b 20 6c 6f 61 00; ;0; loa d 30 2e b e b d5=0.000 ;10.000; 00a e b 30 3b 20 6c 6f ;0 ; load15 00b0 3d 30 2e b 35 2e b e =0.000;5.000;20. Die Verschlüsselung der übertragenen Daten wird mit AES-256 realisiert. Schlüssel Aufgrund einer Sicherheitslücke im Zufallszahlengenerator von Openssl unter Debian 2 wurden die Openssl und SSH-Schlüssel auf ihre Zuverlässigkeit hin überprüft. Als Grundlage dienen die Bibliotheken: openssh-blacklist, openssh-blacklist-extra, openssl-blacklist und openssl-blacklist-extra, die von den Programmen openssl-vulnkey und ssh-vulnkey verwendet werden. Es werden die Signaturen der Schlüssel mit den Signaturen der schwachen Schlüssel aus der Bibliothek verglichen. Die Evaluation geschah wie folgt: # ssh-vulnkey -v /home/nagios/.ssh/id_rsa Not blacklisted: RSA :41:fa:11:94:3c:53:4b:c8:ea:ba:80:44:b4:7b:71 # openssl-vulnkey /etc/apache2/cert/inf-stat.newkey.pem Not blacklisted: b7bf6ec969998afd17717b9d1574cc3f068ce1cc Die Signaturen der Schlüssel sind nicht als schwache Schlüssel verzeichnet. Damit ist die Gefahr einer Kompromittierung durch Ausnutzen der oben genannten Sicherheitslücke nicht möglich. 2 Martin Steinbach 19 von 39

20 6. Abschluss 6.1 Zeitplanung Durch die schon vor dem Projekt absolvierte Arbeitszeit im Institut und den mir auferlegten Verantwortungen, eignete ich mir sehr gute Kenntnisse über die technische Infrastruktur des Instituts an. So war es mir möglich, den Ist-Zustand schnell und präzise zu erfassen. Durch die detaillierten Vorgaben der Projektverantwortlichen und durch direkte Beantwortung meiner Fragen konnte auch das Überwachungskonzept zügig erstellt werden. Somit blieb mehr Zeit für die Realisierung und das Verfassen der Kundendokumentation. Die tatsächlichen Projektphasen wurden mit Hilfe eines Gantt-Diagrammes veranschaulicht. Tabelle 6..1: tatsächliche Projektphasen veranschlagte Zeit tatsächlich benötigte Zeit Ist-Analyse 3 1 Soll-Konzept 4 3 Realisierung Qualitätssicherung 6 6 Kundendokumentation Summe Abbildung 6..1: Gantt-Projekphasen Martin Steinbach 20 von 39

21 6.2. SOLL-IST-VERGLEICH 6.2 Soll-Ist-Vergleich Das Projektes wurde erfolgreich beendet, da alle Musskriterien und Sollkriterien erfüllt worden sind. Netzwerkdienste und lokale Ressourcen aller Server im Zuständigkeitsbereich der Rechnerbetriebsgruppe werden, wie im entwickelten Überwachungskonzept, überwacht. Über die Webschnittstelle kann der Status aller Dienste und Hosts eingesehen werden. Bei einem Problem wird eine generiert und an einen Mailverteiler, der alle Administratoren erreicht, weitergeleitet. Durch umsichtiges Arbeiten wurde der Lehrbetrieb im Institut nicht beeinusst und es sind keine Kosten durch die Verwendung eines Open-Source-Produktes entstanden. Auch die Qualitätsanforderungen wurden erfüllt, da die Installation auf einem komplett redundant ausgelegtem System eingerichtet wurde. Bei einem Stromausfall wird das System durch eine USV heruntergefahren und auch wieder gestartet. Der VServer, auf dem die Überwachunglösung installiert ist, startet bei einem Systemstart. Der VServer-Host wird jeden Abend einem Backup unterzogen. Die Daten werden auf Magnetbänder im Universitätsrechenzentrum gespeichert und können jederzeit wiederhergestellt werden. Eine Schulung aller Administratoren konnte wegen Terminschwierigkeiten nicht durchgeführt werden, somit bleibt dieses Kannkriterium zum Teil unerfüllt. 6.3 Folgeaktivitäten Die Möglichkeiten der Überwachnugslösung sind noch nicht ausgereizt, eine Erweiterung ist ohne gröÿere Hürden möglich. Über SNMP ist Nagios in der Lage Drucker auf ihre Tonerkapazität zu überwachen und leere Papierfächer zu melden. Ferner ist es auch vorstellbar, die Managed-Switches im Institut per SNMP zu kontrollieren. Ergo ist es möglich verschiedene Temeratursensoren innerhalb der Switches zu beobachten und über negative Selbstdiagnoseergebnisse informiert zu werden. Logdateien können mittels des NSCA überwacht werden. Entspricht ein Logeintrag einem vorher denierten regulären Ausdruck, so wird dieser an die zentrale Nagiosinstanz übermittelt. Neben der Erweiterung um Testmöglichkeiten, kann man auch die grasche Oberäche mit neuen Layouts für eine intuitivere Navigation versehen. Eine Reihe von Plugins übertragen auch Performancedaten, diese können durch den Webfrontendaufsatz NagiosGrapher ausgewertet und grasch dargestellt werden. Die richtige Hardware vorrausgesetzt, ist Nagios in der Lage neben s auch SMS zu verschicken. Über das Perl-Skript Nagios-jabber 1 können Administratoren auch per Jabber über Host- und Servicetests informiert werden. Steht keine grasche Oberäche zur Einsicht von Testdaten über einen Webbrowser zu verfügung, bietet der Nagios Console Monitor 2 ein auf ncurses basierendes Interface an Martin Steinbach 21 von 39

22 7. Glossar 1000 BASE-LX Ethernet-Standard für Datenübertragung auf Glasfasermedien. Maximale Länge des Übertragungsmediums beträgt 5000 Meter bei einem maximalen Datendurchsatz von 1000 MBit/s. DMZ DeMilitarized Zone - Netzwerksegment, welches einem kontrollierten Zugri von auÿerhalb unterliegt. Innere Netze sind durch rigide Zugriskontrollen von diesem Netz separiert. HALC Hallescher Linux Cluster - Ein Rechnerverbund bestehend aus 32 Knoten mit je 2 Intel Xeon 2,4 GHz Prozessoren und 2 GByte Arbeitsspeicher. Er ermöglicht, dank seines 2 GBit/s schnellen Myrinet Interconnects paralleles Rechnen in einer Distributed-Memory Architektur. Apache Webserver der Apache Foundation. Es können Funktionen in Form von Modulen hinzugefügt werden und er unterstützt die Verwaltung von virtuellen Hosts. HTTPS Sichere Variante des HTTP-Protokolls. Es wird über eine Zwischenschicht namens Secure Sockets Layer, kurz SSL kommuniziert. SSL Secure Sockets Layer - Verschlüsselungsprotokoll zur sicheren Datenübertragung. Es wird symmetrische und asymmetrische Verschlüsselung unterstützt. Apache verwendet AES-256 zur Kodierung der zu übertragenden Inhalte. AES Advanced Encryption Standard - Ein blockbasiertes symmetrisches Verschlüsselungsverfahren auf Grundlage des Rijndael-Algorithmus. Es werden Schlüssellängen von 128, 192 und 256 Bit verwendet. Martin Steinbach 22 von 39

23 RSA RSA ist ein asymmetrisches Verschlüsselungssystem. Es sind variable Schlüssellängen erlaubt. Es wird hauptsächlich zur Authentizierung und zum Schlüsselaustausch für symmetrische Verfahren eingesetzt, z.b. beim Apache-Webserver und bei SSH. bash Bourne Again Shell - Kommandozeileninterpreter für unixoide Systeme. Sie wird unter der General Public License entwickelt und ist die Standardshell in GNU/Linux-Systemen. Subversion Subversion ist ein Versionsverwaltungssystem, es unterliegt dem Konzept der Client-Server Architektur. LATEX LATEX ist ein Makropaket für das Textsatzsystem TEX. Dokumente werden in einem einfachen Texteditor verfasst und durch den LATEX-Compiler in ein druckfähiges Format übersetzt, z.b. DVI oder PDF. Nullmailer Der einfache Mail Transfer Agent Nullmailer dient lediglich dem Weiterleiten von s, er ist nicht in der Lage sie zu analysieren oder zu bearbeiten. VServer Ein virtualisierter Rechner auf Grundlage des Linux-VServer Projektes: CA Certicate Authority (deutsch Zertizierungsstelle) - Ist eine Organisation, welche digitale Zertikate beglaubigt und unsichere oder ungültige Zertikate in einer Revokation-List verwaltet. Das Institut für Informatik an der MLU besitzt seine eigene Zertizierungsstelle. X509 Ein Standard für digitale Zertikate, welches immer an eine -Adresse oder einen DNS-Namen gebunden. Es beinhaltet einen öentlichen RSA-Schlüssel und eine RSA-Signatur. Runlevel Ein Systemzustand, dem bestimmte Dienste zugeordnet sind. Unter GNU/LINUX existieren die Runlevel 0-6 sowie S. Martin Steinbach 23 von 39

24 VLan vhosts SNMP Perl Jabber ncurses NSCA Im Institut werden portbasierende Virtuelle-LANs verwendet. Diese stellen entweder ein eigenes Teilnetz innerhalb eines, oder zwischen mehreren Switches dar, wenn sie über einen Trunk verbunden sind. Über virtual Hosts kann der Apache Webserver mehrere Webseiten, mit unterschiedlichen DNS-Einträgen, unter der selben IP ausliefern. Auch bei der Verwendung von nur einem DNS-Eintrag muss ein vhost angelegt werden. Das Simple Network Management Protocoll ist ein Protokoll der Anwendungsschicht. Informationen werden über sogenannte Object Identier angesprochen, diese können aus einer numerischen ode alphanumerischen Zeichenkette bestehen. Perl ist eine oene und plattformunabhängige Skriptsprache, sie besitzt neben funktionalen auch objektorientierte Sprachelemente. Perl wird zwar als interpretierte Sprache bezeichnet, wird jedoch vor der Ausführung durch einen Just-in-Time Compiler übersetzt. Ist ein oenes und leicht erweiterbares Instant-Mesaging-Protokoll auf XML-Basis. Als Besonderheit gegenüber anderen Instant Messaging Systemen ist die direkt implementierte Ende zu Ende verschlüsselung über PGP/GPG zu nennen. Ncurses ist eine oene C-Bibliothek die es ermöglicht Text User Interfaces (TUI) für alle gängigen Terminalemulatoren zu entwickeln. Der Nagios Service Check Acceptor ist in der Lage, lokal ermittelte Testergebnisse an eine entfernte Nagiosinstanz zu senden. Dieser Vorgang wird passiver Test genannt. Im Gegensatz dazu existieren die aktiven Tests, welche durch den Nagios Remote Plugin Executor oder per SSH vorgenommen werden. Martin Steinbach 24 von 39

25 Anhang 25

26 8. Anhang A Pichtenheft Zielbestimmung Musskriterien: Eine zentrale Übersicht, über welche der Status der einzelnen Rechner und deren Dienste eingesehen werden kann. Bei Störungen muss eine Benachrichtigung in Form einer ausgelöst werden. Die vorhandenen Infrastruktur muss genutzt werden. Der Lehrbetrieb darf nicht gestört werden. Sollkriterien: Es sollen möglichst keine Kosten entstehen. Kannkriterien: Schulung der Mitarbeiter. Verwendung eines Open-Source Produkt. Abgrenzungskriterien: Keine Betrachtung von Windowsrechnern, Clients und Switches/Firewalls. Produkteinsatz Zielgruppen: Administratoren des Instituts, um Ausfallzeiten zu minimieren. Mitarbeiter des Instituts um Statusinformationen einzusehen. Betriebsbedingungen: Ständige Betriebszeit. Als Grundlage dient ein VServer. Qualitätsanforderungen Grundlegende Zugrisrechte, hohe Verfügbarkeit, Datensicherheit. Technische Umgebung Hardware: Sun Fire X4200: 2HE, 2 AMD Opteron 2220, 16 GByte ECC Registered, RAID GByte SAS Software: Debian GNU/Linux Kernel vserver x86_64 Martin Steinbach 26 von 39

27 B. NETZÜBERSICHT B Netzübersicht Freies Netz Netz: /28 VLAN: 4017 Maske: Gateway: Projektnetz Netz: /28 VLAN: 4018 Maske: Gateway: Server-Netz Netz: /27 VLAN: 4004 Maske: Gateway: Mitarbeiter Netz: /24 VLAN: 4006 Maske: Gateway: Windows- & Linuxpool Netz: /25 VLAN: 4002 Maske: Gateway: Admin-Netz Netz: /26 VLAN: 4012 Maske: Gateway: Techn. & Theoretische Informatik Netz: /26 VLAN: 4008 Maske: Gateway: Bioinformatik Netz: /26 VLAN: 4009 Maske: Gateway: SunRay - Turing Netz: /26 VLAN: 4010 Maske: Gateway: SunRay Netz: /26 VLAN: 4011 Maske: Gateway: VR - Pool Netz: /27 VLAN: 4005 Maske: Gateway: DMZ Netz: /27 VLAN: 4001 Maske: Gateway: UNI-Pools Netz: /26 VLAN: - Maske: Gateway: Abbildung 8..1: Netzübersicht Martin Steinbach 27 von 39

28 C. SERVERÜBERSICHT C Serverübersicht Tabelle 8..1: Serverübersicht Betriebsystem Netzwerkdienste Funktion Linux-Server Anubis Ubuntu 8.04 ssh, dhcp Terminalserver Alcyone SUSE 9.3 ssh Arbeitsgruppenserver Bach SUSE 9.3 ssh Arbeitsgruppenserver Heka Debian 4.0 ssh, ldap, ldaps LDAP-Server Inf-serv Debian 5.0 ssh VServer-Host Isis Debian 4.0 ssh, cups, ldap, ldaps, dhcp Printserver, LDAP-Replika Janus Debian 4.0 ssh, smtps, pops, imaps, https Mailserver Kapella SUSE 9.3 ssh Arbeitsgruppenserver Kiruna SUSE 9.3 ssh Arbeitsgruppenserver Osiris Debian 4.0 ssh, nfs NFS-Server Porjus Ubuntu 8.04 ssh, ldap, ldaps LDAP-Replika Sol Debian 4.0 ssh, nfs,ldap, ldaps, dhcp LDAP-Replika HALC Rocks 4.1 ssh, http, https, Knoten Cluster-Loginknoten VServer vs-stud-www Debian 5.0 ssh, http, https Studentenwebserver vs-euklid Debian 5.0 ssh, NFS Arbeitsgruppenserver vs-inf-stat Debian 5.0 ssh, Nagios Nagios-Server vs-inf-www Debian 5.0 ssh, http, https Web-, SVN-Server Solaris-Server Ada Solaris 9 ssh, nfs Arbeitsgruppenserver Greco Solaris 9 ssh, smb, dhcp Domänencontroller Haendel Solaris 9 ssh Arbeitsgruppenserver Haydn Solaris 10 ssh, sunray Terminalserver Turing Solaris 10 ssh Terminalserver Verdi Solaris 10 ssh, Oracle,https Arbeitsgruppenserver Martin Steinbach 28 von 39

29 D. MINDMAP D Mindmap Abbildung 8..2: Mindmap Martin Steinbach 29 von 39

30 E. PRODUKTVERGELEICH E Produktvergeleich Allgemein: Tabelle 8..2: Produktvergleich OpenNMS 1 Nagios 2 BigSister 3 Open Source D(GPL) D(GPL) D(GPL) Aktualität ( ) ( ) 1.02 ( ) GUI WebUI (Tomcat benötigt) WebUI HTML/CGI WebUI Benachrichtigung Mail,jabber,SMS Mail,jabber,SMS Mail Dokumentation Wiki (en) Wiki, Print, (de,en) Print (de,en) Netzressourcen: PING/SSH D/D D/D D/ HTTP/HTTPS D/D D/D D/ IMAP/POP3 D/D D/D - / SMTP/LDAP D/D D/D -/D Lokale Ress.: SNMP D D D Ressourcen 4 über NRPE P,D,L,S,T,t,L L,P,D,L Datenübertragung SSL 5 SSH/SSL Summe P=Procs, D=Disk, L=Logs, S=SWAP, T=Time, t=temp, L=Logs 5 SSL vom NRPE standardmäÿig deaktiviert. Martin Steinbach 30 von 39

31 F. KONFIGURATIONSDATEIEN F Kongurationsdateien Apache-vHost <VirtualHost xx.xx:443> SSLEngine on SSLCertificateFile /etc/apache2/cert/inf-stat.newcert.pem SSLCertificateKeyFile /etc/apache2/cert/inf-stat.newkey.pem ServerName inf-stat.informatik.uni-halle.de:443 ServerAdmin wihi@informatik.uni-halle.de </VirtualHost> DocumentRoot /var/www/ <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/nagios3 /usr/lib/cgi-bin/nagios3 ScriptAlias /nagios3/cgi-bin /usr/lib/cgi-bin/nagios3 Alias /nagios3/stylesheets /etc/nagios3/stylesheets Alias /nagios3 /usr/share/nagios3/htdocs <DirectoryMatch (/usr/share/nagios3/htdocs /usr/lib/cgi-bin/nagios3)> Options FollowSymLinks DirectoryIndex index.html AllowOverride AuthConfig Order Allow,Deny Allow From All SSLRequireSSL AuthName "Nagios Access" AuthType Basic AuthUserFile /etc/nagios3/htpasswd.users require valid-user </DirectoryMatch> ErrorLog /var/log/apache2/error.log LogLevel warn CustomLog /var/log/apache2/access.log combined ServerSignature Off Martin Steinbach 31 von 39

32 F. KONFIGURATIONSDATEIEN contacts.cfg ############### Addressaten für Fehlermeldungen ############### #Ein Benutzer der sich am Webinterface anmeldet, #bekommt nur jene Hosts und Services zusehen #für die er als Kontakt eingetragen ist. define contact{ contact_name alias host_notification_period service_notification_period service_notification_options host_notification_options service_notification_commands host_notification_commands } nagiosadmin WIHI 24x7 24x7 w,u,c,r d,u,r notify-service-by- notify-host-by- wihi@janus.informatik.uni-halle.de ############### Gruppen ############### define contactgroup{ contactgroup_name alias members } admins Nagios Administratoren nagiosadmin timeperiods.cfg ############## Definition der Zeitperioden ############### define timeperiod{ timeperiod_name 24x7 alias 24 Stunden am Tag, 7 Tage die Woche sunday 00:00-24:00 monday 00:00-24:00 tuesday 00:00-24:00 wednesday 00:00-24:00 thursday 00:00-24:00 friday 00:00-24:00 saturday 00:00-24:00 } Martin Steinbach 32 von 39

33 F. KONFIGURATIONSDATEIEN commands.cfg #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# 58 # # 59 # Kommandodefinitionen # 60 # # 61 #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# #### Host-Alive #### define command{ command_name check-host-alive 69 command_line /usr/lib/nagios/plugins/check_ping -H $HOSTADDRESS$ -w 5000,100% -c 5000,100% -p } #### PING #### define command{ command_name check_ping 78 command_line /usr/lib/nagios/plugins/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ } #### Nangios Remote Plugin Executor #### define command{ command_name check_nrpe 176 command_line /usr/lib/nagios/plugins/check_nrpe -u -H $HOSTADDRESS$ -c $ARG1$ } #### check_by_ssh_ntp_time #### define command{ command_name check_by_ssh_ntp_time 233 command_line /usr/lib/nagios/plugins/check_by_ssh -H $HOSTADDRESS$ -i /home/nagios/.ssh/id_rsa -C "/usr/local/nagios/libexec/check_ntp_time -H $ARG1$ -w $ARG2$ -c $ARG3$" } Martin Steinbach 33 von 39

34 F. KONFIGURATIONSDATEIEN arbeitsgruppen-server.cfg 1 ####### Hostkonfiguration für Arbeitsgruppen-Server ###### 2 3 # Referenz für alle Hosts define host{ 6 7 name generic-arbeitsgruppen 8 9 register check_command check-host-alive 12 max_check_attempts check_period 24x7 14 contact_groups admins 15 notification_interval notification_period 24x7 17 notification_options d,u,r,f } # Hostdefinitionen define host{ 134 host_name haydn 135 hostgroups arbeitsgruppen-server 136 alias Haydn 137 address xxx.xxx use generic-arbeitsgruppen icon_image base/sun40.png 142 icon_image_alt Solaris -Server 143 statusmap_image base/sun40.gd notes OS: Solaris 10 CPU: 4X Sparc IIIi 1593 Mhz RAM: 16 GiB } Martin Steinbach 34 von 39

35 F. KONFIGURATIONSDATEIEN services.cfg 3############### Definition der Services ############### 4 # Referenzeinstellung für alle Services define service{ 7 8 name generic-service 9 10 register max_check_attempts normal_check_interval 5 14 retry_check_interval 1 15 check_period 24x7 16 notification_interval notification_period 24x7 18 notification_options w,u,c,r,f 19 contact_groups admins 20 } 23 # Servicedefinitionen # define service{ host_name heka,isis,porjus,vs-janus,sol 79 service_description CHECK_LDAP 80 servicegroups ldap 81 check_command check_ldap!ou=informatik,o=uni-halle,c=de use generic-service 84 } define service{ host_name isis 497 service_description CHECK_CUPS_QUEUE 498 servicegroups print 499 check_command check_nrpe!check_cups_queue use generic-service 502 } define service{ host_name ada,turing,greco,verdi,haydn,haendel 741 service_description CHECK_TIME 742 servicegroups time 743 check_command check_by_ssh_ntp_time! !60! use generic-service 746 } Martin Steinbach 35 von 39

36 F. KONFIGURATIONSDATEIEN nrpe.cfg ### NRPE - Konfiguration - Anubis ### pid_file=/var/run/nrpe.pid server_port=5666 #server_address= nrpe_user=nagios nrpe_group=nagios allowed_hosts= dont_blame_nrpe=0 debug=0 command_timeout=60 connection_timeout=300 command[check_load]=/usr/lib/nagios/plugins/check_load -w 25,20,15 -c 35,30,25 command[check_disk_root]=/usr/lib/nagios/plugins/check_disk -w c 400 -p / command[check_disk_temp]=/usr/lib/nagios/plugins/check_disk -w 30 -c 10 -p /tmp command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w c 1800 command[check_swap]=/usr/lib/nagios/plugins/check_swap -w 50% -c 10% command[check_sensors]=/usr/lib/nagios/plugins/check_sensors -v Martin Steinbach 36 von 39

37 G. ÜBERGABECHECKLISTE G Übergabecheckliste Checkliste zur Übergabe der Überwachungslösung Mit Hilfe der Übergabecheckliste wurde die Überwachungslösung vom Testserver auf den Produktiv-VServer übernommen und kann seit diesem Zeitpunkt von den Administratoren und Mitarbeitern genutzt werden. Die unten aufgeführten Punkte wurden nach der Portierung auf ihre Funktion geprüft. Datum: Teilnehmer: Dipl. Inform. Annett Thüring Cand. Inform. Andre Giessler Cand. Inform. Michael Rennecke Cand. Bioinf. Martin Scharm Cand. Bioinf. Christoph Ruttkies Prakt. Martin Steinbach System: lokale Benutzer erstellt SSH-Schlüssel auf neues System portiert Apache-Webserver: Apache installiert und Konguration übernommen Satusseite nur über TCP-Port 443 erreichbar lokale Benutzerdatenbank für Webzugri übernommen Mail Transfer Agent: Nullmailer installiert und Konguration übernommen wird durch Nagios ausgelöst besitzt richtige(n) Formatierung/Zeichensatz wird zugestellt Nagios: Nagios installiert und Kongurationen übernommen negative Service-/Hosttests lösen Benachrichtigungen aus D D D D D D D D D D D Bemerkungen: Die Übergabe wurde während eines Adminmeetings durchgeführt. Martin Steinbach 37 von 39

38 H. CLUSTERCHECK H Clustercheck Abbildung 8..3: Nagios Cluster-Monitoring Martin Steinbach 38 von 39