Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
TEIL I: Einstieg in Linux
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
TEIL II: Grundlagen
5 Kernel
6 Grundlagen aus Anwendersicht
TEIL III: Die Shell
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
TEIL IV: System- & Netzwerkadministration
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP & Co.
20 DNS-Server
21 Secure Shell
TEIL V: Die grafische Oberfläche
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
TEIL VI: Systeminterna
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
TEIL VII: Programmierung und Sicherheit
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in Computersicherheit
33 Netzwerksicherheit überwachen
TEIL VIII: Anhang
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Buch-DVDs
F Glossar
G Literatur
Stichwort

Buch bestellen
Ihre Meinung?

Spacer
Linux von Johannes Plötner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
Rheinwerk Computing
1282 S., 5., aktualisierte Auflage 2012, geb., mit 2 DVDs
49,90 Euro, ISBN 978-3-8362-1822-1
Pfeil 33 Netzwerksicherheit überwachen
Pfeil 33.1 Snort
Pfeil 33.1.1 Aufbau der Intrusion Detection
Pfeil 33.1.2 snort.conf
Pfeil 33.2 Netzwerkmonitoring mit Nagios
Pfeil 33.2.1 Installation
Pfeil 33.2.2 Konfiguration
Pfeil 33.2.3 Plugins
Pfeil 33.3 Nmap: Der wichtigste Portscanner
Pfeil 33.3.1 Prinzip eines Portscanners
Pfeil 33.3.2 Techniken des Scannens
Pfeil 33.3.3 Weiterer Informationsgewinn
Pfeil 33.3.4 Nmap in der Praxis
Pfeil 33.3.5 Angabe der Scanziele
Pfeil 33.4 Sniffer
Pfeil 33.4.1 tcpdump
Pfeil 33.4.2 Wireshark (ehemals Ethereal)
Pfeil 33.4.3 dsniff
Pfeil 33.5 Zusammenfassung

Rheinwerk Computing - Zum Seitenanfang

33.2 Netzwerkmonitoring mit NagiosZur nächsten Überschrift

Nagios (www.nagios.org) erfüllt als Nachfolger des populären NetSaint alle Anforderungen, die wir im letzten Abschnitt an ein Netzwerkmonitoringtool gestellt haben:

  • Überwachen von Rechnern und Diensten
    Man kann diverse Dienste (z. B. HTTP, SMTP, POP3, FTP, ...) sowie auch ganze Rechner (über ICMP) überwachen. Außerdem kann man auch Ressourcen wie Festplattenplatz, CPU-Auslastung oder den Speicherverbrauch kontrollieren.
  • Flexibles Benachrichtigungssystem
    Natürlich kann man auch konfigurieren, wer wie kontaktiert werden soll, wenn Probleme auftreten. Dazu gehört neben der obligatorischen E-Mail-Benachrichtigung auch der Support von SMS-Nachrichten oder von anderen benutzerdefinierten Möglichkeiten.
  • Die verschiedenen Benutzer des Systems kann man außerdem in unterschiedlichen Kontaktgruppen organisieren, auf die man die unterschiedlichen Problemfälle verteilen kann.

  • Pluginsystem und proaktive Problemlösung
    Über ein einfaches Pluginsystem kann man selbst Servicechecks schreiben, die dann von Nagios regelmäßig ausgeführt beziehungsweise überprüft werden.
  • Außerdem kann man mittels Event-Handlern auch einfache Maßnahmen zur proaktiven Problemlösung definieren.

  • Webinterface
    Neben den erwähnten Möglichkeiten der E-Mail-Benachrichtigung kann man den Status der überwachten Systeme auch über ein Webinterface betrachten.

Open Source!

Gehen wir also näher auf die Software ein. Nagios steht unter der GNU General Public License und ist damit als freie Software für jeden verfügbar. Als Voraussetzungen für die Installation genügen bereits ein einfacher Linux-Rechner mit Webserver (am besten Apache) sowie die GD-Bibliothek, die aber auch bei jeder Distribution mit dabei sein sollte. Nachdem es installiert – und vor allem konfiguriert – worden ist, kann man sich mit Nagios nicht nur über aufgetretene Probleme informieren lassen, sondern sich auch schöne Statistiken ansehen.

Abbildung

Abbildung 33.1 Netzwerkmonitoring mit Nagios

Nur haben die Götter vor die Grafik leider die Konfiguration gesetzt, die bei einem Netzwerk-Monitoringsystem natürlich nicht von selbst erfolgen kann. Aus diesem Grund wollen wir uns an dieser Stelle etwas näher mit dieser Thematik auseinandersetzen, da die Maßnahmen, die sich aus den Meldungen ergeben, wieder vollkommen in den Aufgabenbereich eines Systemadministrators fallen.

Da die Konfiguration also naturgemäß recht komplex werden kann, verweisen wir für Detailfragen wieder einmal auf die Webseite des Projektes, www.nagios.org, und auf die dort verlinkte ausführliche Dokumentation.


Rheinwerk Computing - Zum Seitenanfang

33.2.1 InstallationZur nächsten ÜberschriftZur vorigen Überschrift

Beginnen wir also mit der Installation. Am besten laden Sie sich die aktuellste Version von der Webseite herunter und entpacken die Dateien in einem Verzeichnis Ihrer Wahl. Anschließend sollten Sie einen eigenen Benutzer samt Gruppe für die Software und das spätere Installationsverzeichnis – am besten /usr/local/nagios – anlegen.

Listing 33.14 Die eigentliche Installation vorbereiten

# tar -xzf nagios-1.1.tar.gz
# mkdir /usr/local/nagios
# adduser nagios

Quelltext konfigurieren

Als Nächstes kann man in dem entpackten Verzeichnis das configure-Skript aufrufen, bei dem

man einige Parameter nicht vergessen sollte:

Listing 33.15 Die Software vor dem Übersetzen an das eigene System anpassen

../configure --prefix=prefix --with-cgiurl=cgiurl    \
--with-htmurl=htmurl --with-nagios-user=user \
--with-nagios-grp=group
  • Mit »prefix« gibt man das Installationsverzeichnis an; normalerweise ist dies /usr/local/nagios.
  • Mit »cgiurl« wird die URL angeben, unter der man später die CGI-Skripte ansprechen will, normalerweise /nagios/cgi-bin [Fn. Achtung: Am Ende der URL darf kein Slash stehen!].
  • Analog gibt die »htmlurl« die URL der späteren HTML-Seiten an, normalerweise /nagios/.
  • Schließlich sollte man den eben angelegten Benutzer samt dessen Gruppe (standardmäßig ist beides »nagios«) angeben.

Quelltext übersetzen

Als Nächstes kann man die Software übersetzen und die entsprechenden Dateien an ihren zukünftigen Platz im Dateisystem verschieben. Falls gewünscht, kann man sich auch ein Initskript erstellen lassen:

Listing 33.16 Übersetzen, installieren und Initskript erstellen

# make
# make install
# make install-init

Möchte man auch noch einen Satz von Standard-Konfigurationsdateien installieren, die man dann später nur noch anpassen muss, reicht es aus, make erneut zu bemühen:

Listing 33.17 Beispielkonfiguration installieren

# make config
# make install-config

Verzeichnisstruktur

Wechselt man nun mit cd /usr/local/nagios in das Installationsverzeichnis von Nagios, kann man sich dort die Verzeichnisstruktur der Software näher ansehen:

Tabelle 33.1 Die Verzeichnisstruktur

Verzeichnis Beschreibung

bin/

Der Nagios-Server an sich befindet sich in diesem Verzeichnis.

etc/

Hier befinden sich die Konfigurationsdateien. Dazu später mehr.

libexec/

In dieses Verzeichnis sollten die Plugins installiert werden.

sbin/

Die CGIs für das Webinterface befinden sich hier.

share/

die HTML-Dateien für das Webinterface sowie die Dokumentation

var/

das Verzeichnis für die Logfiles

Installieren der Plugins

Wie bereits aus der Tabelle zur Verzeichnisstruktur ersichtlich ist, müssen als Nächstes die Plugins separat heruntergeladen und ins Verzeichnis libexec/ installiert werden.

Plugins für Servicechecks

Diese Plugins sind dabei entweder Skripte oder zu kompilierende Binarys, die die Service- und Hostchecks erst durchführen. Natürlich können Sie so, wenn Sie sich bereits fertige Skripte oder Codes als Vorbild nehmen, auch eigene Plugins für Nagios schreiben.

Das Webinterface

Nachdem wir die Software übersetzt und die Plugins installiert haben, ist als Nächstes das Webinterface an der Reihe. Es muss dem Webserver – in unserem Beispiel wollen wir auf den viel genutzten Apache eingehen – »gesagt« werden, wo die CGI-Skripte und die HTML-Dateien zu finden sind. Immerhin haben wir diese ja nicht in die DocumentRoot, also das »Stammverzeichnis des Webservers« installiert.

Webserver vorbereiten

Beginnen wir dazu mit dem Alias für die CGI-Skripte. Die folgenden Zeilen bewirken, dass wir die URL /nagios/cgi-bin ansprechen können, wobei in Wirklichkeit auf die Skripte in /usr/local/nagios/sbin zugegriffen wird. Dieses Verzeichnis wird beim Kompilieren durch den Parameter --cgiurl angegeben:

Listing 33.18 Den Alias für die CGI-Skripte setzen

ScriptAlias /nagios/cgi-bin/ /usr/local/nagios/sbin/
<Directory "/usr/local/nagios/sbin/»
AllowOverride AuthConfig
Options ExecCGI
Order allow,deny
Allow from all
</Directory>

Als Nächstes müssen wir noch die --htmlurl /nagios auf das Verzeichnis share/ unserer Installation umleiten:

Listing 33.19 Den Alias für die Nagios-HTML-Dateien setzen

Alias /nagios/ /usr/local/nagios/share/
<Directory "/usr/local/nagios/share»
Options None
AllowOverride AuthConfig
Order allow,deny
Allow from all
</Directory>

Nun kann man Apache mit dem Befehl

Listing 33.20 Apache neu starten

# apachectl restart

neu starten und bereits versuchen, das Webinterface über http://localhost/nagios/ anzusprechen. Natürlich werden noch keine Informationen angezeigt, da das Monitoring erst noch konfiguriert werden muss; das Webinterface kann man aber schon betrachten.

Passwortschutz

Meistens ist es ganz sinnvoll, den Zugriff auf die Nagios-Software per htaccess zu beschränken. Um diesen Schutz zu konfigurieren, muss man zuerst im share/- und sbin/-Verzeichnis der Nagios-Installation eine .htaccess-Datei mit folgendem Inhalt anlegen:

Listing 33.21 Die .htaccess-Datei

AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
require valid-user

Mit dem Kommando htpasswd kann man nun die Datei /usr/local/nagios/etc/htpasswd.users mit dem -c-Switch anlegen und mit Benutzernamen und Passwörtern füllen:

Listing 33.22 Den User »nagiosadmin« hinzufügen

htpasswd -c /usr/local/nagios/etc/htpasswd.users     \
nagiosadmin

Möchte man weitere Nutzer hinzufügen, so entfällt die Option -c, und man gibt als einziges Argument den anzulegenden Benutzernamen an.


Rheinwerk Computing - Zum Seitenanfang

33.2.2 KonfigurationZur nächsten ÜberschriftZur vorigen Überschrift

Nach der Installation läuft Nagios zwar bereits, aber ein Monitoring findet noch nicht statt. Dazu muss das System erst korrekt konfiguriert werden, was in diesem Abschnitt besprochen werden soll. Am besten beginnen wir dazu mit einem Überblick über die wichtigsten der zahlreichen Konfigurationsdateien:

Hauptkonfiguration

  • etc/nagios.cfg
    In der Hauptkonfigurationsdatei kann man alle möglichen Einstellungen für Nagios vornehmen, wie beispielsweise, wo die restlichen Konfigurationsdateien zu finden sind, welche Logfiles angelegt werden sollen oder wie sich das Monitoring bezüglich der einzelnen Checks genau verhalten soll.
  • etc/cgi.cfg
    In dieser Konfigurationsdatei kann man zahlreiche Einstellungen für die CGIs treffen, so zum Beispiel, welche Nagios-Benutzer auf welche Funktionen Zugriff erhalten, falls eine Authentifizierung verwendet wird.
  • Resource Files
    Neben den beiden Hauptkonfigurationsdateien gibt es weitere Dateien, die man dann über etc/nagios.cfg einbinden kann. Ein Typ dieser zusätzlichen Konfigurationseinstellungen sind die Resource Files (meist nur etc/resource.cfg), in denen man sensible Informationen wie Logins für eine Datenbank oder auch Makros speichern kann. Aus Sicherheitsgründen sind diese Informationen den CGIs nicht zugänglich.
  • Objekte definieren

  • Object Configuration Files
    Diese Dateien bindet man ebenfalls über die nagios.cfg ein, und hier endlich definiert man das eigentliche Monitoring. Für Nagios ist es egal, ob Sie einen Service (Dienst) oder einen zu überwachenden Rechner definieren, allerdings teilt man die recht umfangreichen Optionen meist auf mehrere Dateien auf:
    • etc/hosts.cfg
      Hier definiert man die zu überwachenden Rechner samt Namen und IP-Adressen. Dazu benötigt man die weiter unten erklärten host-Objekte.
    • etc/services.cfg
      Hier kann man die zu überwachenden Dienste definieren, die zwei wichtige Eigenschaften besitzen: den Rechner(n), auf dem sie laufen, sowie den Befehl beziehungsweise das Plugin, das für den Check verwendet werden soll.
    • etc/commands.cfg
      Die bei den Servicedefinitionen benötigten Dienste kann man auch als Objekte anlegen, was einem die Angabe der genauen Syntax bei jedem einzelnen zu konfigurierenden Dienst ersparen kann.
    • etc/contacts.cfg
      Hier kann man einzelne Benutzer samt E-Mail-Adresse oder anderer Benachrichtigungsmethoden eintragen sowie angeben, bei welchen Dringlichkeitsstufen verschiedener Events sie kontaktiert werden sollen.
    • etc/*groups.cfg
      Ob Rechner oder Kontakte: Beides kann und sollte man auch zu Gruppen zusammenfassen, um die Administration komplexer Netzwerke zu vereinfachen. Diese Gliederung ist vor allem für das Benachrichtigungssystem sinnvoll.
    • Weitere Objekttypen
      Es gibt noch viele weitere Objekttypen, die gerade für komplexe bis sehr komplexe Netzwerke interessant werden können. Für eine Dokumentation zu diesen Features seien Sie erneut auf die Webseite verwiesen, da weitere Details den Rahmen des Buches sprengen würden.

    Denken Sie allerdings daran, dass die eben vorgestellten Dateien nicht unbedingt genau so auf Ihrem Nagios-Server vorhanden sein müssen – schließlich können Sie in der nagios.cfg flexibel einstellen, woher Ihre Objektdefinitionen kommen sollen.

Im Folgenden wollen wir weniger die Konfiguration von Nagios selbst (über die nagios.cfg beziehungsweise die cgi.cfg) erläutern, da diese standardmäßig recht sinnvoll und im Allgemeinen weniger interessant ist, sondern stattdessen lieber auf die umfangreichen Objektdefinitionen eingehen, die das Monitoring Ihres Netzwerks erst ermöglichen. Aus diesem Grund seien Sie erneut auf die Webseite des Projekts samt zugehöriger Dokumentation verwiesen, falls Fragen zur Konfiguration offen bleiben sollten.

Hostobjekte

Rechner definieren

Prinzipiell kann man in jeder Object-Configuration-Datei host-Objekte definieren, meist wird dazu jedoch die etc/hosts.cfg genutzt. Möchte man nun einen neuen Rechner zur Überwachung hinzufügen, kann man dort eine entsprechende Definition ablegen:

Listing 33.23 Ein Host-Objekt

define host{
host_name Rechnername
alias Alias
address IP
(parents Rechnernamen)
(check_command Kommando)
max_check_attempts #
notification_interval #
notification_period timeperiod
notification_options [d,u,r]
}

Man gibt dem Objekt mit dem Rechnernamen zuerst einen eindeutigen Bezeichner, auf den man sich dann in der weiteren Konfiguration von Nagios auch beziehen kann. Das Alias dagegen wird verwendet, um den Rechnernamen über das Webinterface anzuzeigen.

Es folgt natürlich die obligatorische IP-Adresse. Wenn sich irgendwelche anderen Systeme wie zum Beispiel Router zwischen dem Host und dem Monitoringsystem befinden, werden diese im optionalen Parameter parent angegeben.

Ist ein Rechner an?

Das check-Kommando ist recht wichtig, um zu überprüfen, ob der Host noch »up« ist. Meist gibt man hier das standardmäßig in der commands.cfg definierte Kommando check-host-alive an, das schlicht einen Ping auf den Rechner versucht. Lässt man diesen Parameter weg, wird das System nicht überprüft und immer als »up« angenommen.

Als Nächstes muss man angeben, wie oft im Fehlerfall überprüft werden soll, bevor eine Nachricht abgeschickt beziehungsweise der Rechner als »down« deklariert wird. In so einem Fall werden entsprechende Kontakte alle notification_interval Minuten wieder informiert.

Eine timeperiod ist auch ein Objekt, über das man definieren kann, in welchem Zeitraum ein Rechner oder ein Dienst überwacht werden soll. Meist gibt man hier den in der etc/timeperiods.cfg definierten Zeitraum 24x7 an, der den Rechner ohne Unterbrechung kontrolliert.

Zum Schluss kann man noch einstellen, wann ein Admin benachrichtigt werden soll: wenn der Rechner »down« (d) geht, wenn er »unreachable« (u) ist, also ein Parent »down« geht und der Rechner nicht mehr zu erreichen ist, und/oder wenn er wieder »up« (r, engl. recover) ist.

Es gibt noch eine ganze Reihe weiterer möglicher Optionen, die wir aber nicht näher betrachten wollen.

Hostgruppen

Verknüpfung mit Kontakten

Was in der Definition zu einzelnen Rechnern noch fehlte, war natürlich die Verknüpfung mit entsprechenden Kontaktpersonen, die im Problemfall informiert werden sollen. Dazu fasst man nämlich mehrere Rechner zu einer »Gruppe« zusammen, indem man wieder einen Objektnamen samt Alias vergibt und der Gruppe eine Kontaktgruppe sowie natürlich ein bis mehrere durch Komma getrennte Mitglieder zuordnet. Die Mitglieder sind dabei ihrerseits wieder Hostobjekte.

Listing 33.24 Hostgruppen

define hostgroup{
hostgroup_name Gruppenname
alias Alias
contact_groups Kontaktgruppen
members Mitglieder
}

Durch diese auf den ersten Blick komplexe Struktur kann man sehr sinnvolle und realitätsnahe Konfigurationen für das Monitoring schaffen. Und dies ist schließlich das Ziel, das wir mit der Software verfolgen.

[zB]Um letzte Fragen zu klären, wollen wir uns aber einmal ein kurzes Beispiel eines Hostobjekts sowie einer dazugehörigen Hostgruppe ansehen:

Listing 33.25 Host samt Hostgruppe

define host{
host_name fileserver
alias Data Store
address 192.168.1.1
check_command check-host-alive
max_check_attempts 5
notification_interval 30
notification_period 24x7
notification_options d,u,r
}
define hostgroup{
hostgroup_name servers
alias Serverraum #1
contact_groups linux-admins
members fileserver,mailserver
}

Diese Konfiguration sollte mit den Erläuterungen der Objekttypen eigentlich selbsterklärend sein. Das einzige, was Sie nicht verwundern sollte, ist die hier nicht weiter definierte Kontaktgruppe linux-admins. Da wir auf Kontaktgruppen erst später eingehen, haben wir diese Definition hier nämlich noch offengelassen.

Serviceobjekte

Serverdienste definieren

Bereits angesprochen wurden auch die Serviceobjekte. Das Wort »Service« bezeichnet dabei nicht nur klassische Dienste wie HTTP, FTP oder POP3, sondern auch jede andere »messbare« Eigenschaft eines Rechners.

So kann man über Serviceobjekte auch den Plattenplatz, die Anzahl momentan eingeloggter Benutzer, die Prozessorauslastung oder was auch immer überprüfen. Allerdings sollte man immer darauf achten, nicht zu viele Informationen zu sammeln, damit das Wichtige nicht untergeht.

Listing 33.26 Serviceobjekte in der etc/services.cfg

define service{
host_name Rechnername
service_description Beschreibung
check_command Kommando
max_check_attempts #
normal_check_interval #
retry_check_interval #
check_period timeperiod
notification_interval #
notification_period timeperiod
notification_options [w,u,c,r]
contact_groups Kontaktgruppen
}

Der Rechnername bezieht sich auf ein host-Objekt, auf dem dieser Dienst läuft beziehungsweise dessen Zustand überwacht werden soll. Ansonsten ist vor allem wieder das Kommando wichtig, bei dem oft auf eines der mitgelieferten Plugins zurückgegriffen wird.

Ähnlich wie die bereits erläuterten notification-Optionen verhalten sich auch die check-Optionen. So kann man über check_period kontrollieren, wann das Monitoring stattfinden soll (z. B. 24x7), oder mittels interval festlegen, wie regelmäßig die Überprüfungen wiederholt werden sollen.

Wann informieren?

Zu den notification_options ist noch eine weitere Option – (w) für Warnungen – hinzugekommen. Schließlich gibt es für Dienste drei Zustände: »ok«, »warning« und »critical«, während es mit »up« und »down« für Rechner an sich nur zwei messbare Zustände gibt.

Über die Option contact_groups kann man wie bei den Hostgruppen eine oder mehrere Kontaktgruppen angeben, die im Problemfall benachrichtigt werden.

Kontakte und Kontaktgruppen

Verantwortliche angeben

Daher wollen wir als Nöchstes auch schon dieses Feature behandeln. Zu einem Kontakt gehört wie immer bei Nagios der Objektname, der »richtige« Name als Alias sowie natürlich neben den bereits bekannten Benachrichtigungsoptionen eine – optionale – E-Mail-Adresse.

Listing 33.27 Kontakte in der etc/contacts.cfg

define contact{
contact_name Kontakt
alias Alias
host_notification_period timeperiod
service_notification_period timeperiod
host_notification_options [d,u,r,n]
service_notification_options [w,u,c,r,n]
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
(email E-Mail)
}

Natürlich gibt es auch für Kontakte noch weit mehr als die hier aufgeführten Optionen und damit mehr Möglichkeiten, wie eine Benachrichtigung erfolgen kann. Somit ist die E-Mail-Adresse als eine Kontaktoption unter vielen auch nicht zwingend für dieses Objekt erforderlich.

Um einen Kontakt nun aber mit einem Hostgruppen- oder Serviceobjekt verknüpfen zu können, benötigt man eine Kontaktgruppe. Auch wenn in einer solchen Gruppe nur ein einziger Kontakt steht, ist sie notwendig, damit man den Kontakt in Nagios nutzen kann:

Listing 33.28 Kontaktgruppe in der etc/contactgroups.cfg

define contactgroup{
contactgroup_name Kontaktgruppe
alias Alias
members Mitglieder
}

[zB]Die Mitglieder einer solchen Gruppe sind natürlich wieder die entsprechenden Objektnamen, die durch Kommata getrennt werden. Aber sehen wir uns dazu ein einfaches Beispiel an:

Listing 33.29 Ein Beispiel

define contact{
contact_name jploetner
alias Johannes Plötner
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email jploetner@localhost
}
define contactgroup{
contactgroup_name admins
alias Administratoren
members jploetner, swendzel
}

Dieses Beispiel sollte eigentlich selbsterklärend sein. Man definiert zuerst den Kontakt und fügt ihn schließlich einer Kontaktgruppe hinzu.

Kommandodefinition

Plugins integrieren

Wir haben bei den Host- und den Serviceobjekten bereits auf die Kommandos Bezug genommen, mit denen diese entsprechend überwacht wurden. Dort konnte man entweder direkt einen Befehl eingeben oder eben auf ein definiertes Kommandoobjekt Bezug nehmen.

Ein solches Kommandoobjekt definiert man wie folgt:

Listing 33.30 Kommandodefinition in der etc/commands.cfg

define command{
command_name Kommando
command_line Kommandozeile
}

[zB]Dabei kann man in der Kommandozeile auch Makros nutzen, die mit einem Dollarzeichen beginnen müssen. Ein Beispiel soll diesen Sachverhalt verdeutlichen:

Listing 33.31 Ein Beispiel

define command{
command_name check_pop
command_line /usr/local/nagios/libexec/ \
check_pop -H $HOSTADDRESS$
}

In diesem Beispiel wird das Kommando check_pop definiert, das ein gleichnamiges Skript im libexec/-Verzeichnis mit dem entsprechenden Rechnernamen als Argument aufruft.

Wenn die Plugins installiert wurden, dann hat man schon eine ganze Reihe sinnvoller Kommandos zur Verfügung. Im Folgenden soll eine kleine Übersicht über die wichtigsten Skripte und Programme gegeben werden. Für eine ausführliche Übersicht sei Ihnen aber immer noch die Dokumentation der Plugins selbst ans Herz gelegt.


Rheinwerk Computing - Zum Seitenanfang

33.2.3 PluginsZur nächsten ÜberschriftZur vorigen Überschrift

Wie bereits angedeutet, besitzt Nagios selbst keinerlei Möglichkeiten, irgendeinen Dienst oder Rechner zu überwachen. Die Software verlässt sich voll und ganz auf die Plugins, die diese »Intelligenz« zur Verfügung stellen.

Die Intelligenz

Bekanntermaßen unterscheidet Nagios allerdings zwischen Hostchecks und Servicechecks, die beide auf dieselbe Pluginarchitektur zurückgreifen. Der einzige Unterschied besteht darin, dass bei einem Hostcheck bei jedem Nicht-OK-Wert bei der Rückgabe angenommen wird, dass der Rechner »down« ist.

Dass man die Plugins schließlich über Kommandodefinitionen einbindet, die man dann in den Host- und Serviceobjekten angeben kann, sollte mittlerweile auch klar sein.

check_tcp

Portscan

Dieses Plugin ist eines der einfachsten und gleichzeitig wichtigsten. Mit ihm kann man nämlich überprüfen, ob ein Port auf einem entfernten Rechner offen oder geschlossen ist. Aus dieser Information kann man dann den Rückschluss ziehen, ob der entsprechende Dienst läuft oder abgestürzt ist.

Ruft man das Plugin auf der Kommandozeile ohne Parameter auf, so wird ein Hilfetext mit allen verfügbaren Parametern ausgegeben:

Listing 33.32 Die Parameter des Plugins

# ./check_tcp
No arguments found
Usage: check_tcp -H host -p port [-w warn_time]
[-c crit_time] [-s send_string] [-e expect_string]
[-q quit_string] [-m maxbytes] [-d delay]
[-t to_sec] [-v]

In einer Kommandodefinition könnte man das Plugin also zum Beispiel wie folgt ansprechen:

Listing 33.33 Beispiel: check_tcp

define command{
command_name check_port_cups
command_line $USER1$/check_tcp -H \
$HOSTADDRESS$ -p 631
}

[zB]In dem Beispiel wollen wir also einen Check definieren, der einen laufenden CUPS-Server überprüft. Dazu nutzen wir zwei Makros: Das in der etc/resource.cfg definierte $USER1$-Makro spart uns die Angabe des vollständigen Pfadnamens zum Pluginverzeichnis, und zur Laufzeit von Nagios wird das Makro $HOSTADDRESS$ durch die Adresse des zu überprüfenden Rechners ersetzt.

In einem Serviceobjekt könnte man nun wie folgt den CUPS-Server überwachen lassen:

Listing 33.34 CUPS-Server überwachen

define service{
host_name printserver,testserver
service_description CUPS
check_command check_port_cups
...
}

check_ping

Rechnerstatus berechnen

Für Hostchecks möchte man natürlich am liebsten ICMP-Echo-Pakete mittels ping verschicken. Zu diesem Zweck gibt es das Plugin check_ping, das meist wie folgt als Kommando definiert wird:

Listing 33.35 check-host-alive

define command{
command_name check-host-alive
command_line $USER1$/check_ping \
-H $HOSTADDRESS$ -w 3000.0,80 % -c 5000.0,100 % -p 1
}

Das check-host-alive-Kommando ist uns aber schon in der Definition der Hostobjekte begegnet, wo wir es als sinnvolles Standardkommando zur Überprüfung des Hoststatus vorgestellt hatten.

NRPE und NSCA

Richtig interessant wird Nagios allerdings erst, wenn Erweiterungen wie NRPE beziehungsweise NCSA ins Spiel kommen. Diese Dienste laufen auf dem zu überwachenden Rechner und können Nagios diverse Informationen wie noch verfügbare Plattenkapazität, Prozessorauslastung oder Speicherauslastung mitteilen.

Aktive vs. passive Checks

Mit NRPE kann man dabei aktive Checks realisieren: Man installiert auf dem Clientsystem – die Software gibt es für Windows und Unix – den NRPE-Dienst und auf dem Nagios-Server das check_nrpe-Plugin. Entsprechend konfiguriert, überprüft Nagios nun über das Plugin regelmäßig den Status des Systems.

Setzt man dagegen NCSA ein, so kann man passive Checks realisieren. Dies ist zum Beispiel nützlich, wenn das zu überwachende System hinter einer Firewall sitzt. Mit dieser Software baut nämlich der Client regelmäßig selbst die Verbindung zu der auf dem Nagios-Server laufenden Software auf.

Wie Sie sehen, kann man mit Nagios sehr komplexe Monitoringstrukturen umsetzen. Da das Thema aber recht verwickelt ist, wollen wir es bei diesem Einblick in die Thematik belassen und Sie ein letztes Mal auf die verfügbare Dokumentation verweisen.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux Handbuch






 Linux Handbuch


Zum Katalog: Linux Server






 Linux Server


Zum Katalog: Raspberry Pi






 Raspberry Pi


Zum Katalog: Ubuntu 14.04 LTS






 Ubuntu 14.04 LTS


Zum Katalog: Roboter bauen mit Arduino






 Roboter bauen
 mit Arduino


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de