Laborarbeit Network & Services Überwachung komplexer IT-Infrastrukturen

Größe: px
Ab Seite anzeigen:

Download "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 (http://www.snmptt.org/) 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

Laborübung SNMP. Aufgabe 1: SNMP Basics genutzter Agent: 10.20.143.73 (VM_SNMP_Win_XP)

Laborübung SNMP. Aufgabe 1: SNMP Basics genutzter Agent: 10.20.143.73 (VM_SNMP_Win_XP) Netzmanagement SS 2014 Prof. Dr. Martin Leischner / Dipl.Inf. Wolfgang Pein 14.5.14 - V1 Laborübung SNMP Einführung Um Netzmanagement betreiben zu können, ist es notwendig, auf Managementinformationen

Mehr

SNMP4Nagios. SNMP4Nagios. Grazer Linuxtage 2006. Peter Gritsch

SNMP4Nagios. SNMP4Nagios. Grazer Linuxtage 2006. Peter Gritsch SNMP4Nagios Grazer Linuxtage 2006 Peter Gritsch Inhalte Motivation für Network Monitoring SNMP Grundlagen Nagios Grundlagen SNMP4Nagios Plugins Motivation für Network Monitoring Probleme erkennen bevor

Mehr

Security. Stefan Dahler. 6. Zone Defense. 6.1 Einleitung

Security. Stefan Dahler. 6. Zone Defense. 6.1 Einleitung 6. Zone Defense 6.1 Einleitung Im Folgenden wird die Konfiguration von Zone Defense gezeigt. Sie verwenden einen Rechner für die Administration, den anderen für Ihre Tests. In der Firewall können Sie entweder

Mehr

Dazu stehen für alle gängigen Betriebssysteme die Command Line basierenden Tools snmpget, snmpset, snmptrap zur Verfügung.

Dazu stehen für alle gängigen Betriebssysteme die Command Line basierenden Tools snmpget, snmpset, snmptrap zur Verfügung. SNMP Einführung Command Line Tools Am Markt existieren jede Menge leistungsfähige, kommerzielle sowie open source Produkte, um Netzwerke und Serversysteme über das Simple Network Management Protokoll SNMP

Mehr

SNMP4Nagios. SNMP4Nagios. Grazer Linuxtage 2007. Peter Gritsch

SNMP4Nagios. SNMP4Nagios. Grazer Linuxtage 2007. Peter Gritsch SNMP4Nagios Grazer Linuxtage 2007 Peter Gritsch Inhalte Motivation für Network Monitoring SNMP Grundlagen Nagios Grundlagen SNMP4Nagios PlugIns Motivation für Network Monitoring Probleme erkennen bevor

Mehr

Icinga Teil 1. Andreas Teuchert. 11. Juli 2014

Icinga Teil 1. Andreas Teuchert. 11. Juli 2014 Icinga Teil 1 Andreas Teuchert 11. Juli 2014 1 Icinga 2009 als Fork des Nagios-Cores entstanden Nagios-Hauptentwickler wollte Patches/Weiterentwicklungen nicht aufnehmen Nagios/Icinga sind der Industriestandard

Mehr

Konfiguration Firewall (Zyxel Zywall 10) (von Gruppe Schraubenmeier)

Konfiguration Firewall (Zyxel Zywall 10) (von Gruppe Schraubenmeier) Konfiguration Firewall (Zyxel Zywall 10) (von Gruppe Schraubenmeier) Firewall über Seriellen Anschluss mit Computer verbinden und Netzteil anschliessen. Programm Hyper Terminal (Windows unter Start Programme

Mehr

SNMP und der MIB- Browser von MG-Soft

SNMP und der MIB- Browser von MG-Soft SNMP und der MIB- Browser von MG-Soft 1. SNMP 1.1 Was ist SNMP 1.2 Historie von SNMP 1.3 Einordnung in das OSI-Modell 1.4 Die Architektur von SNMP 1.5 Kommunikation von SNMP 1.6 SNMP-PDUs PDUs 2. MIB und

Mehr

Quick Installation Guide

Quick Installation Guide WWW.REDDOXX.COM Erste Schritte Bitte beachten Sie, dass vor Inbetriebnahme auf Ihrer Firewall folgende Ports in Richtung Internet für die Appliance geöffnet sein müssen: Port 25 SMTP (TCP) Port 53 DNS

Mehr

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Versuchsvorgaben (Aufgabenstellung) Der neu zu gestaltende Versuch

Mehr

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen ewon - Technical Note Nr. 005 Version 1.3 Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen 08.08.2006/SI Übersicht: 1. Thema 2. Benötigte Komponenten

Mehr

Security. Stefan Dahler. 4. Internet Verbindung. 4.1 Einleitung

Security. Stefan Dahler. 4. Internet Verbindung. 4.1 Einleitung 4. Internet Verbindung 4.1 Einleitung Im Folgenden wird die Konfiguration der DFL-800 Firewall gezeigt. Sie konfigurieren einen Internet Zugang zum Provider mit dem Protokoll PPPoE. In der Firewallrichtlinie

Mehr

Check_MK rail1 - Handbuch

Check_MK rail1 - Handbuch Check_MK rail1 - Handbuch i Check_MK rail1 - Handbuch Check_MK rail1 - Handbuch ii Inhaltsverzeichnis 1 Schnellstart-Anleitung 1 2 Lieferumfang 3 3 Anforderungen an die SD-Karte 4 4 Informationen zur SD-Karte

Mehr

Management mit SNMP. Was ist snmp? Standards und Normen Datenstrukturen Implementierung Tools und Administration

Management mit SNMP. Was ist snmp? Standards und Normen Datenstrukturen Implementierung Tools und Administration Management mit SNMP Was ist snmp? Standards und Normen Datenstrukturen Implementierung Tools und Administration Simple Network Management SNMP ist ein Protokoll zum Verwalten von Komponenten in einem IP-Rechnernetzwerk

Mehr

Simple Network Management Protocol (SNMP)

Simple Network Management Protocol (SNMP) Kurzbeschreibung SNMP Seite 1 Simple Network Management Protocol (SNMP) Das Simple Network Management Protocol (englisch für "einfaches Netzwerkverwaltungsprotokoll", kurz SNMP), ist ein Netzwerkprotokoll,

Mehr

Collax Web Application

Collax Web Application Collax Web Application Howto In diesem Howto wird die Einrichtung des Collax Moduls Web Application auf einem Collax Platform Server anhand der LAMP Anwendung Joomla beschrieben. LAMP steht als Akronym

Mehr

Ch. 6 Switch Konfiguration

Ch. 6 Switch Konfiguration Ch. 6 Switch Konfiguration CCNA 3 version 3.0 Wolfgang Riggert,, FH Flensburg nach Rick Graziani, Cabrillo College Vorbemerkung Die englische Originalversion finden Sie unter : http://www.cabrillo.cc.ca.us/~rgraziani/

Mehr

Icinga Teil 2. Andreas Teuchert. 25. Juli 2014

Icinga Teil 2. Andreas Teuchert. 25. Juli 2014 Icinga Teil 2 Andreas Teuchert 25. Juli 2014 1 Nagios-Plugins Programme, die den Status von Diensten überprüfen können liegen in /usr/lib/nagios/plugins/ werden von Icinga aufgerufen, geben Status über

Mehr

Dies ist eine Schritt für Schritt Anleitung wie man den Router anschließt und mit dem Internet verbindet.

Dies ist eine Schritt für Schritt Anleitung wie man den Router anschließt und mit dem Internet verbindet. Schnellinstallations Anleitung: Dies ist eine Schritt für Schritt Anleitung wie man den Router anschließt und mit dem Internet verbindet. 1) Verkabeln Sie Ihr Netzwerk. Schließen Sie den Router ans Stromnetz,

Mehr

webpdf für VMware SoftVision Development GmbH Kurfürstenstraße 15 36037 Fulda, Deutschland Tel.: +49 (0)661 25100-0 Fax: +49 (0)661 25100-25

webpdf für VMware SoftVision Development GmbH Kurfürstenstraße 15 36037 Fulda, Deutschland Tel.: +49 (0)661 25100-0 Fax: +49 (0)661 25100-25 webpdf für VMware SoftVision Development GmbH Kurfürstenstraße 15 36037 Fulda, Deutschland Tel.: +49 (0)661 25100-0 Fax: +49 (0)661 25100-25 E-Mail: sales@softvision.de Web: www.softvision.de Inhaltsverzeichnis

Mehr

Die drei Switche sind auf drei Stockwerke verteilt und mit einer Leitung miteinander verbunden.

Die drei Switche sind auf drei Stockwerke verteilt und mit einer Leitung miteinander verbunden. Szenario Aufbau Es sollen vier von einander getrennte Subnetze erstellt und konfiguriert werden. Diese werden stockwerksübergreifend über drei Switche mit einem Internet Gateway verbunden, um Zugang zum

Mehr

Nagios Erweiterungen Der Rest. Nagios / Icinga. OpenSource Network-Monitoring im großen Stil. Manuel Landesfeind

Nagios Erweiterungen Der Rest. Nagios / Icinga. OpenSource Network-Monitoring im großen Stil. Manuel Landesfeind Erweiterungen Der Rest / Icinga OpenSource Network-Monitoring im großen Stil Manuel Landesfeind Institut für Mathematik Georg-August-Universität Göttingen This presentation can be used under the terms

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Stefan Dahler. 1. Konfiguration der Stateful Inspection Firewall. 1.1 Einleitung

Stefan Dahler. 1. Konfiguration der Stateful Inspection Firewall. 1.1 Einleitung 1. Konfiguration der Stateful Inspection Firewall 1.1 Einleitung Im Folgenden wird die Konfiguration der Stateful Inspection Firewall beschrieben. Es werden Richtlinien erstellt, die nur den Internet Verkehr

Mehr

MySQL Community Server 5.1 Installationsbeispiel

MySQL Community Server 5.1 Installationsbeispiel MySQL Community Server 5.1 Installationsbeispiel Dieses Dokument beschreibt das Herunterladen der Serversoftware, die Installation und Konfiguration der Software. Bevor mit der Migration der untermstrich-datenbank

Mehr

Datenkommunikations- Protokolle

Datenkommunikations- Protokolle Datenkommunikations- Protokolle Modul: TeDKP 07.06.2010 Name: E- Mail: manuel.mareischen@tet.htwchur.ch Dozent: Bruno Wenk bruno.wenk@htwchur.ch INHALTSVERZEICHNIS Inhaltsverzeichnis... 2 1. Einleitung...

Mehr

SolarWinds Engineer s Toolset

SolarWinds Engineer s Toolset SolarWinds Engineer s Toolset Diagnostic Tools Das Engineer s Toolset ist eine Sammlung von 49 wertvoller und sinnvoller Netzwerktools. Die Nr. 1 Suite für jeden Administrator! Die Schwerpunkte liegen

Mehr

NetVoip Installationsanleitung für SNOM 320

NetVoip Installationsanleitung für SNOM 320 NetVoip Installationsanleitung für SNOM 320 Einrichten eines SNOM 320 für NETVOIP 1 Erste Inbetriebnahme...3 1.1 Auspacken und Einrichten, Einstecken der Kabel...3 1.2 IP-Adresse des SNOMs herausfinden...3

Mehr

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum

Mehr

Aufgaben zum ISO/OSI Referenzmodell

Aufgaben zum ISO/OSI Referenzmodell Übung 1 - Musterlösung 1 Aufgaben zum ISO/OSI Referenzmodell 1 ISO/OSI-Model Basics Aufgabe 1 Weisen Sie die folgenden Protokolle und Bezeichnungen den zugehörigen OSI- Schichten zu: IP, MAC-Adresse, HTTP,

Mehr

Authentication Policy. Konfigurationsbeispiel ZyXEL ZyWALL USG-Serie. Juni 2010 / HAL

Authentication Policy. Konfigurationsbeispiel ZyXEL ZyWALL USG-Serie. Juni 2010 / HAL Authentication Policy Konfigurationsbeispiel ZyXEL ZyWALL USG-Serie Juni 2010 / HAL LOKALE USER DATENBANK Über Authentication Policy verknüpft man ZyWALL-Dienste und Benutzer so, dass die Nutzung der Dienste

Mehr

SNMP Grundlagen und Network Monitroing mit Nagios. Sommersemester2011 Autor:Wang,Nan Universität Marburg

SNMP Grundlagen und Network Monitroing mit Nagios. Sommersemester2011 Autor:Wang,Nan Universität Marburg SNMP Grundlagen und Network Monitroing mit Nagios Sommersemester2011 Autor:Wang,Nan Universität Marburg 1 Inhalt 1.Einleitung 2.SNMP Grundlagen 2.1 SNMPv1 Protokoll 2.2 Fünf Betätigungen von SNMP 2.3 MIB

Mehr

Konfigurationsanleitung E-Mail Konfiguration unter Opera Mail 10.00. Konfigurationsanleitung E-Mail Konfiguration unter Opera Mail

Konfigurationsanleitung E-Mail Konfiguration unter Opera Mail 10.00. Konfigurationsanleitung E-Mail Konfiguration unter Opera Mail Konfigurationsanleitung E-Mail Konfiguration unter Opera Mail E-Mail Einstellungen für alle Programme Auf diesen Seiten finden Sie alle grundlegenden Informationen um Ihren Mailclient zu konfigurieren

Mehr

1. Interface. Wireshark (Ehtereal)

1. Interface. Wireshark (Ehtereal) Wireshark (Ehtereal) Das Programm Wireshark Network Protocol Analyzer dient dazu, wie der Name schon sagt, ersichtlich zu machen, welche Datenpakete die Netzwerkkarte empfängt bzw. sendet. In Form von

Mehr

SNMP-Management (TCP/IP-Management)

SNMP-Management (TCP/IP-Management) (TCP/IP-Management) Grundlagen und Überblick Inhalt Architekturbestandteile TCP/IP-Management-Modell Informationsmodell/SMI MIB SNMP Funktionale Bereiche SNMPv2 SNMPv3 2 1 Architekturmodell Eine Netzwerk-Management-Architektur

Mehr

Erstinstallation UAG4100

Erstinstallation UAG4100 Erstinstallation UAG4100 Bedingungen, welche umgesetzt bzw. für das Beispiel angepasst werden sollen: LAN1 = 172.16.0.1/16bit (255.255.0.0), DHCP ab 172.16.1.1 für 4096 Clients, leased time 3 Tage. LAN2

Mehr

Serverüberwachung mittels SNMP, RRD-Tool und Cacti

Serverüberwachung mittels SNMP, RRD-Tool und Cacti Serverüberwachung mittels, RRD-Tool und Cacti Jörg Mathieu Betreuer : Reinhard Linde Gliederung 1 Einleitung 2 Funktionen MIB Paketaufbau -Agentenbefehle 3 RRD-Tool Erstellen einer RRD-Datei Einfügen von

Mehr

Server Installation 1/6 20.10.04

Server Installation 1/6 20.10.04 Server Installation Netzwerkeinrichtung Nach der Installation müssen die Netzwerkeinstellungen vorgenommen werden. Hierzu wird eine feste IP- Adresse sowie der Servername eingetragen. Beispiel: IP-Adresse:

Mehr

Seite - 1 - 8. Out-Of-Band-Authentifizierung (OOBA) 8.1 Einleitung

Seite - 1 - 8. Out-Of-Band-Authentifizierung (OOBA) 8.1 Einleitung 8. Out-Of-Band-Authentifizierung (OOBA) 8.1 Einleitung Sie konfigurieren den OOBA, um die Webzugriffe mit HTTP ins Internet zu kontrollieren. Das Aufrufen von Webseiten ist nur authentifizierten Benutzern

Mehr

Root-Server für anspruchsvolle Lösungen

Root-Server für anspruchsvolle Lösungen Root-Server für anspruchsvolle Lösungen I Produktbeschreibung serverloft Internes Netzwerk / VPN Internes Netzwerk Mit dem Produkt Internes Netzwerk bietet serverloft seinen Kunden eine Möglichkeit, beliebig

Mehr

In Verbindung mit IP Cam D-Link DCS-7110 Tech Tipp: IP Kamera Anwendung mit OTT netdl 1000 Datenfluss 1. 2. OTT netdl leitet das Bild der IP Cam an den in den Übertragungseinstellungen definierten Server

Mehr

HowTo: Abfrage von Werten des CMC III per SNMP und MIB-Browser

HowTo: Abfrage von Werten des CMC III per SNMP und MIB-Browser HowTo: Abfrage von Werten des CMC III per SNMP und MIB-Browser Stellen Sie sicher dass sich die Processing Unit und der verwendete PC im gleichen Netzwerk befinden und eine Verbindung zwischen ihnen besteht.

Mehr

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria

init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria init.at informationstechnologie GmbH Tannhäuserplatz 2/5.OG 1150 Wien Austria Seite 2 von 10 1 Inhaltsverzeichnis 2 Warum NOCTUA by init.at... 3 3 Ihre Vorteile mit NOCTUA:... 4 4 NOCTUA Features... 5

Mehr

Port-Weiterleitung einrichten

Port-Weiterleitung einrichten Port-Weiterleitung einrichten Dokument-ID Port-Weiterleitung einrichten Version 1.5 Status Endfassung Ausgabedatum 13.03.2015 Centro Business Inhalt 1.1 Bedürfnis 3 1.2 Beschreibung 3 1.3 Voraussetzungen/Einschränkungen

Mehr

Benutzerhandbuch für FaxClient für HylaFAX

Benutzerhandbuch für FaxClient für HylaFAX Benutzerhandbuch für FaxClient für HylaFAX Vielen Dank, daß Sie entschlossen haben, dieses kleine Handbuch zu lesen. Es wird Sie bei der Installation und Benutzung des FaxClients für HylaFAX unterstützen.

Mehr

1. Wireless Switching... 2. 1.1 Einleitung... 2. 1.2 Voraussetzungen... 2. 1.3 Konfiguration... 2. 2. Wireless Switch Konfiguration...

1. Wireless Switching... 2. 1.1 Einleitung... 2. 1.2 Voraussetzungen... 2. 1.3 Konfiguration... 2. 2. Wireless Switch Konfiguration... Inhaltsverzeichnis 1. Wireless Switching... 2 1.1 Einleitung... 2 1.2 Voraussetzungen... 2 1.3 Konfiguration... 2 2. Wireless Switch Konfiguration... 3 2.1 Zugriff auf den Switch... 3 2.2 IP Adresse ändern...

Mehr

1KONFIGURATION VON WIRELESS LAN MIT WPA PSK

1KONFIGURATION VON WIRELESS LAN MIT WPA PSK 1KONFIGURATION VON WIRELESS LAN MIT WPA PSK Copyright 26. August 2005 Funkwerk Enterprise Communications GmbH bintec Workshop Version 0.9 Ziel und Zweck Haftung Marken Copyright Richtlinien und Normen

Mehr

Verwenden der Cisco UC 320W in Verbindung mit Windows Small Business Server

Verwenden der Cisco UC 320W in Verbindung mit Windows Small Business Server Verwenden der Cisco UC 320W in Verbindung mit Windows Small Business Server Dieser Anwendungshinweis enthält Anweisungen zum Bereitstellen der Cisco UC 320W in einer Umgebung mit Windows Small Business

Mehr

Netzwerktechnik Cisco CCNA

Netzwerktechnik Cisco CCNA BBU NPA Übung 9 Stand: 07.01.2013 Zeit Lernziele Laborübung 60 min Grundkonfiguration eines Switches Erstellen einer Grundkonfiguration für einen Switch Löschen einer Konfiguration und Laden einer Konfiguration

Mehr

SMS versenden mit ewon über Mail Gateway Am Beispiel von dem Freemail Anbieter GMX wird diese Applikation erklärt

SMS versenden mit ewon über Mail Gateway Am Beispiel von dem Freemail Anbieter GMX wird diese Applikation erklärt ewon - Technical Note Nr. 014 Version 1.2 SMS versenden mit ewon über Mail Gateway Am Beispiel von dem Freemail Anbieter GMX wird diese Applikation erklärt Übersicht 1. Thema 2. Benötigte Komponenten 3.

Mehr

Parallels Plesk Panel. Firewall-Modul für Parallels Plesk Panel 10 für Linux/Unix. Administratorhandbuch

Parallels Plesk Panel. Firewall-Modul für Parallels Plesk Panel 10 für Linux/Unix. Administratorhandbuch Parallels Plesk Panel Firewall-Modul für Parallels Plesk Panel 10 für Linux/Unix Administratorhandbuch Copyright-Vermerk Parallels Holdings, Ltd. c/o Parallels International GmbH Vordergasse 59 CH-Schaffhausen

Mehr

Handbuch Schnelleinstieg

Handbuch Schnelleinstieg V44.01 IP kabellose Kamera / Kamera mit Kabel Handbuch Schnelleinstieg (Für MAC OS) Modell:FI8904W Modell:FI8905W ShenZhen Foscam Intelligent Technology Co., Ltd Packungsliste FI8904W/05W Handbuch Schnelleinstieg

Mehr

Für den Zugriff vom PC aus die TCP/IP Netzwerkeinstellung des PC auf DHCP bzw. automatisch stellen,

Für den Zugriff vom PC aus die TCP/IP Netzwerkeinstellung des PC auf DHCP bzw. automatisch stellen, DIGITRONIC GmbH - Seite: 1 Ausgabe: 11.05.2012 Einstellanleitung GSM XSBOXR6VE Diese Anleitung gilt für die Firmware Version 1.1 Zunächst die SIM Karte mit der richtigen Nummer einsetzten (siehe Lieferschein).

Mehr

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät NAT und Firewalls Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung 27. April 2005

Mehr

4-441-095-42 (1) Network Camera

4-441-095-42 (1) Network Camera 4-441-095-42 (1) Network Camera SNC easy IP setup-anleitung Software-Version 1.0 Lesen Sie diese Anleitung vor Inbetriebnahme des Geräts bitte genau durch und bewahren Sie sie zum späteren Nachschlagen

Mehr

ANLEITUNG Vers. 22.04.2014. EAP Gateway mit Webserver Modbus TCP/IP Slave - Modbus RTU Master

ANLEITUNG Vers. 22.04.2014. EAP Gateway mit Webserver Modbus TCP/IP Slave - Modbus RTU Master ANLEITUNG Vers. 22.04.2014 EAP Gateway mit Webserver Modbus TCP/IP Slave - Modbus RTU Master Allgemeine Beschreibung Das Gateway mit Webserver Modbus TCP/IP Slave Modbus RTU Master ist ein Gerät, welches

Mehr

Cluster Quick Start Guide

Cluster Quick Start Guide Cluster Quick Start Guide Cluster SR2500 Anleitung zur Konfi guration KURZÜBERBLICK CLUSTER SEITE 2 FUNKTIONSWEISE DES THOMAS KRENN CLUSTERS (SCHAUBILD) SEITE 3 CLUSTER AUFBAUEN UND KONFIGURIEREN SEITE

Mehr

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT

IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Version 2.1 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note Network Mapping mit 1:1 NAT Stand: 28.10.2014 ads-tec GmbH 2014 Big-LinX 2 Inhaltsverzeichnis 1 Einführung... 3 1.1 NAT

Mehr

IRF2000, IF1000 Application Note ModbusTCP API

IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Stand: 28.10.2014 ads-tec GmbH 2014 IRF2000 IF1000 2 Inhaltsverzeichnis 1 Einführung... 3 2

Mehr

telpho10 Update 2.1.6

telpho10 Update 2.1.6 telpho10 Update 2.1.6 Datum: 31.03.2011 NEUERUNGEN... 2 STANDORTANZEIGE GESPERRTER IP ADRESSEN... 2 NEUE SEITE SYSTEM STATUS IN DER ADMINISTRATOR WEB-GUI... 2 NEUE SEITE SNOM FIRMWARE IN DER ADMINISTRATOR

Mehr

Folgende Voraussetzungen für die Konfiguration müssen erfüllt sein:

Folgende Voraussetzungen für die Konfiguration müssen erfüllt sein: 1. Access Point im Personal Mode (WEP / WPA / WPA2) 1.1 Einleitung Im Folgenden wird die Konfiguration des Access Point Modus gezeigt. Zur Absicherung der Daten werden die verschiedenen Verschlüsselungsalgorithmen

Mehr

Grundlagen PIX-Firewall

Grundlagen PIX-Firewall Lars Krahl Stand: 2006 Grundlagen PIXFirewall Grundkonfiguration, Sicherung, Reset, Logging Einleitung Dieses Dokument befasst sich mit den Grundlagen der Bedienung der Cisco PIXFirewall. Die Aufgaben

Mehr

Labor Netzwerktechnik. Cisco Router. Version 1.1 22.03.2005. Cisco 1710. Prof. Dr. Alfons Eizenhöfer. Dipl.-Inf. (FH) Daniel Beuchler.

Labor Netzwerktechnik. Cisco Router. Version 1.1 22.03.2005. Cisco 1710. Prof. Dr. Alfons Eizenhöfer. Dipl.-Inf. (FH) Daniel Beuchler. Fachbereich Informatik Fachbereich efi Labor Netzwerktechnik Version 1.1 22.03.2005 Cisco 1710 Prof. Dr. Alfons Eizenhöfer Dipl.-Inf. (FH) Daniel Beuchler Oliver Reiche Fachhochschule Nürnberg 2005 Verbindung

Mehr

EasyDIS-base-44-v1.0.nrg GT1_v44_programs.iso (falls vorhanden) K+DCAN Interface von MY-OBD2.COM Shop

EasyDIS-base-44-v1.0.nrg GT1_v44_programs.iso (falls vorhanden) K+DCAN Interface von MY-OBD2.COM Shop EasyDIS-base-44-v1.0.nrg GT1_v44_programs.iso (falls vorhanden) K+DCAN Interface von MY-OBD2.COM Shop Grundinstallation EasyDIS-base-44-v1.0 Eine korrekte Installation von Vmware sollte wie rechts abgebildet

Mehr

Knowledge Base SIP-Konfiguration auf der Fortigate

Knowledge Base SIP-Konfiguration auf der Fortigate Datum 05/01/2011 09:21:00 Hersteller Fortinet Modell Type(n) Fortigate Firmware v4.2 Copyright Boll Engineering AG, Wettingen Autor Sy Dokument-Version 1.0 Situation: SIP-Traffic auf einer Firewall zuzulassen

Mehr

Scaling IP Addresses. CCNA 4 version 3.0 Wolfgang Riggert,, FH Flensburg

Scaling IP Addresses. CCNA 4 version 3.0 Wolfgang Riggert,, FH Flensburg Scaling IP Addresses CCNA 4 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Rick Graziani, Cabrillo College Vorbemerkung Die englische Originalversion finden Sie unter : http://www.cabrillo.cc.ca.us/~rgraziani/

Mehr

Praktikum IT-Sicherheit. Firewall

Praktikum IT-Sicherheit. Firewall IT-Sicherheit Praktikum IT-Sicherheit - Versuchshandbuch - Einrichten von Firewallsystemen mit IPtables Firewall In diesem Versuch lernen Sie den Umgang mit Paketfiltern im Zusammenhang von Servern und

Mehr

MGE Datenanbindung in GeoMedia

MGE Datenanbindung in GeoMedia TIPPS & TRICKS MGE Datenanbindung in GeoMedia 10. September 2002 / AHU INTERGRAPH (Schweiz) AG Neumattstrasse 24, CH 8953 Dietikon Tel: 043 322 46 46 Fax: 043 322 46 10 HOTLINE: Telefon: 043 322 46 00

Mehr

WIE-SERVICE24. Konfiguration Ihres Zugangs. VPN Portal. WIE-SERVICE24.com. Technical Notes. 2011-12-03_WIESERVICE24_TN1.doc Stand: 12/2011 (Rev.

WIE-SERVICE24. Konfiguration Ihres Zugangs. VPN Portal. WIE-SERVICE24.com. Technical Notes. 2011-12-03_WIESERVICE24_TN1.doc Stand: 12/2011 (Rev. WIE-SERVICE24 Konfiguration Ihres Zugangs VPN Portal WIE-SERVICE24.com Technical Notes 2011-12-03_WIESERVICE24_TN1.doc Stand: 12/2011 (Rev. A) Inhalt Inhalt 1 Allgemeines... 3 1.1 Information... 3 1.1

Mehr

Technical Note 30 Endian4eWON einrichten für VPN Verbindung

Technical Note 30 Endian4eWON einrichten für VPN Verbindung Technical Note 30 Endian4eWON einrichten für VPN Verbindung TN_030_Endian4eWON.doc Angaben ohne Gewähr Irrtümer und Änderungen vorbehalten. Seite 1 von 21 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis... 2

Mehr

DATA BECKERs Praxishandbuch zu SUSE Linux 10

DATA BECKERs Praxishandbuch zu SUSE Linux 10 DATA BECKERs Praxishandbuch zu SUSE Linux 10 Daniel Koch DATA BECKER Hardware vor dem Kauf prüfen 4. So läuft jede Hardware Längst wird Linux von vielen Hardwareherstellern unterstützt. Ganz reibungslos

Mehr

www.uni-math.gwdg.de/linuxuebung

www.uni-math.gwdg.de/linuxuebung 14 Netzwerküberwachung und -steuerung Überblick SNMP Simple Network Management Protocol Datendefinitionen SNMP Implementierungen unter Linux Kommandos zur Datenbeschaffung Konfiguration des Net-SNMP Agenten

Mehr

VPN mit Windows Server 2003

VPN mit Windows Server 2003 VPN mit Windows Server 2003 Virtuelle private Netzwerke einzurichten, kann eine sehr aufwendige Prozedur werden. Mit ein wenig Hintergrundwissen und dem Server- Konfigurationsassistenten von Windows Server

Mehr

2 Sunny WebBox in ein bestehendes lokales Netzwerk (LAN) einbinden

2 Sunny WebBox in ein bestehendes lokales Netzwerk (LAN) einbinden SUNNY WEBBOX Kurzanleitung zur Inbetriebnahme der Sunny WebBox unter Windows XP Version: 1.0 1 Hinweise zu dieser Anleitung Diese Anleitung unterstützt Sie bei der Inbetriebnahme der Sunny WebBox in ein

Mehr

NetVoip Installationsanleitung für D-Planet VIP 156

NetVoip Installationsanleitung für D-Planet VIP 156 NetVoip Installationsanleitung für D-Planet VIP 156 Einrichten eines D-Planet VIP 156 für NETVOIP 1 Erste Inbetriebnahme...3 1.1 Auspacken und Einrichten, Einstecken der Kabel...3 1.2 IP-Adresse des D-Planet

Mehr

Konfigurationsanleitung E-Mail Konfiguration unter Opera Mail

Konfigurationsanleitung E-Mail Konfiguration unter Opera Mail Konfigurationsanleitung E-Mail Konfiguration unter Opera Mail E-Mail Einstellungen für alle Programme Auf dieser Seite finden Sie alle grundlegenden Informationen um Ihren Mailclient zu konfigurieren damit

Mehr

Folgende Voraussetzungen für die Konfiguration müssen erfüllt sein: - Grundkonfiguration des Routers. - Ein Bootimage ab Version 7.4.x.

Folgende Voraussetzungen für die Konfiguration müssen erfüllt sein: - Grundkonfiguration des Routers. - Ein Bootimage ab Version 7.4.x. 7. PPPoE Server 7.1 Einleitung Im Folgenden wird die Konfiguration einer Dialin Verbindung über PPPoE zum Router beschrieben, um eine zusätzliche Authentifizierung durchzuführen. Bei der Einwahl eines

Mehr

SolarWinds Engineer s Toolset

SolarWinds Engineer s Toolset SolarWinds Engineer s Toolset Monitoring Tools Das Engineer s Toolset ist eine Sammlung von 49 wertvoller und sinnvoller Netzwerktools. Die Nr. 1 Suite für jeden Administrator! Die Schwerpunkte liegen

Mehr

Einrichtung des NVS Calender-Google-Sync-Servers. Installation des NVS Calender-Google-Sync Servers (Bei Neuinstallation)

Einrichtung des NVS Calender-Google-Sync-Servers. Installation des NVS Calender-Google-Sync Servers (Bei Neuinstallation) Einrichtung des NVS Calender-Google-Sync-Servers Folgende Aktionen werden in dieser Dokumentation beschrieben und sind zur Installation und Konfiguration des NVS Calender-Google-Sync-Servers notwendig.

Mehr

Sensordaten mit SNMP verteilen

Sensordaten mit SNMP verteilen Sensordaten mit SNMP verteilen Axel Wachtler und Ralf Findeisen Chemnitzer Linux Tage 17.03.2013 Einleitung Systembeschreibung Was ist SNMP? Implementierung Demo Ausblick Systemüberblick Sensor- und Gatewayknoten

Mehr

Folgende Einstellungen sind notwendig, damit die Kommunikation zwischen Server und Client funktioniert:

Folgende Einstellungen sind notwendig, damit die Kommunikation zwischen Server und Client funktioniert: Firewall für Lexware professional konfigurieren Inhaltsverzeichnis: 1. Allgemein... 1 2. Einstellungen... 1 3. Windows XP SP2 und Windows 2003 Server SP1 Firewall...1 4. Bitdefender 9... 5 5. Norton Personal

Mehr

Nagios. Jens Link jenslink@quux.de. September 2008. Jens Link () Nagios September 2008 1 / 1

Nagios. Jens Link jenslink@quux.de. September 2008. Jens Link () Nagios September 2008 1 / 1 Nagios Jens Link jenslink@quux.de September 2008 Jens Link () Nagios September 2008 1 / 1 Wer bin ich? Freiberuflicher Consultant Schwerpunkt: komplexe Netzwerke, Netzwerksecurity, Netzwerkmonitoring,

Mehr

UDP-, MTU- und IP- Fragmentierung

UDP-, MTU- und IP- Fragmentierung UDP-, MTU- und IP- Fragmentierung Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung

Mehr

GSM ONE: Setup Guide

GSM ONE: Setup Guide GSM ONE +++ Setup Guide +++ Über dieses Dokument: Diese Anleitung beschreibt die Inbetriebnahme eines Greenbone Security Manager ONE (GSM ONE), einem Produkt der Greenbone Networks GmbH (http://www.greenbone.net).

Mehr

bintec Workshop Dynamic Host Configuration Protocol Copyright 8. November 2005 Funkwerk Enterprise Communications GmbH Version 0.9

bintec Workshop Dynamic Host Configuration Protocol Copyright 8. November 2005 Funkwerk Enterprise Communications GmbH Version 0.9 bintec Workshop Dynamic Host Configuration Protocol Copyright 8. November 2005 Funkwerk Enterprise Communications GmbH Version 0.9 Ziel und Zweck Haftung Marken Copyright Richtlinien und Normen Wie Sie

Mehr

Microsoft ISA Server 2006

Microsoft ISA Server 2006 Microsoft ISA Server 2006 Leitfaden für Installation, Einrichtung und Wartung ISBN 3-446-40963-7 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-40963-7 sowie im Buchhandel

Mehr

Einrichtungsanleitung MRT150N & fixed.ip+

Einrichtungsanleitung MRT150N & fixed.ip+ Einrichtungsanleitung MRT150N & fixed.ip+ (Stand: 2 Juli 2013) Mini-VPN-Router MRT150N Diese Anleitung steht auch im mdex Support Wiki als PDF-Datei zum Download bereit: https://wiki.mdex.de/ mdexanleitungen

Mehr

9. Deutscher Akademietag 2010

9. Deutscher Akademietag 2010 9. Deutscher Akademietag 2010 VoIP Advanced Workshop Referenten: Dipl. Inf. (FH) Christoph Seifert Dipl. Inf. Christian Pape Frederik Stey Marc Mader Hinweis Alle Router befinden sich in einem vorkonfiguriertem

Mehr

So wird der administrative Aufwand bei der Konfiguration von Endgeräten erheblich reduziert.

So wird der administrative Aufwand bei der Konfiguration von Endgeräten erheblich reduziert. 11.2 Cisco und DHCP.. nur teilweise CCNA relevant DHCP Dynamic Host Configuration Protocol ist der Nachfolger des BOOTP Protokolls und wird verwendet um anfrandenen Hosts dynamisch IP Parameter - i.d.r.

Mehr

Apple Time Capsule Kombigerät ans Universitätsnetz anschliessen

Apple Time Capsule Kombigerät ans Universitätsnetz anschliessen Anleitung Apple Time Capsule Kombigerät ans Universitätsnetz anschliessen Einleitung Apple Time Capsule Geräte vereinen in sich die Funktionen einer Netzwerk-Festplatte und eines WLAN-Routers (Wireless

Mehr

Lexware professional und premium setzen bis einschließlich Version 2012 den Sybase SQL-Datenbankserver

Lexware professional und premium setzen bis einschließlich Version 2012 den Sybase SQL-Datenbankserver Eine Firewall für Lexware professional oder premium konfigurieren Inhaltsverzeichnis: 1. Allgemein... 1 2. Einstellungen... 1 3. Die Firewall von Windows 7 und Windows 2008 Server... 2 4. Die Firewall

Mehr

Phion Netfence Firewall Mag. Dr. Klaus Coufal

Phion Netfence Firewall Mag. Dr. Klaus Coufal Phion Netfence Firewall Mag. Dr. Klaus Coufal Übersicht I. Konzepte II. Installation und Konfiguration III. High Availability IV. Firewall V. VPN Server VI. Management Center VII. Addons Mag. Dr. Klaus

Mehr

DNS Server einrichten unter Debian Linux. DHCP Server einrichten unter Debian Linux. Querschnittsaufgaben.

DNS Server einrichten unter Debian Linux. DHCP Server einrichten unter Debian Linux. Querschnittsaufgaben. Aufgabenstellung DNS Server einrichten unter Debian Linux. DHCP Server einrichten unter Debian Linux. Querschnittsaufgaben. Mail Client konfigurieren. Web Server Client (Browser) konfigurieren. Samba/NFS

Mehr

Wortmann AG. Terra Black Dwraf

Wortmann AG. Terra Black Dwraf Terra Black Dwraf Inhalt 1 VPN... 3 2 Konfigurieren der dyndns Einstellungen... 4 3 VPN-Verbindung mit dem IPSec Wizard erstellen... 5 4 Verbindung bearbeiten... 6 5 Netzwerkobjekte anlegen... 8 6 Regel

Mehr

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/ Einführung Was ist Unison? Unison ist ein Dateisynchronisationsprogramm für Windows und Unix. Es teilt sich viele Funktionen mit anderen Programmen, wie z.b. CVS und rsync. Folgend einige Vorteile des

Mehr

Technical Note 0605 ewon

Technical Note 0605 ewon PCE Deutschland GmbH Im Langel 4 59872 Meschede Telefon: 02903 976 990 E-Mail: info@pce-instruments.com Web: www.pce-instruments.com/deutsch/ Technical Note 0605 ewon 2 ewon per VPN miteinander verbinden

Mehr

Installationsanleitung

Installationsanleitung Installationsanleitung POP3 und Bridge-Modus Inhaltsverzeichnis 1 POP3 und Bridge-Modus 2 1.1 Funktionsweise von POP3 mit REDDOXX 2 1.2 Betriebsarten 3 1.2.1 Standard-Modus 3 1.2.2 Bridge-Modus 6 1.2.3

Mehr

Um IPSec zu konfigurieren, müssen Sie im Folgenden Menü Einstellungen vornehmen:

Um IPSec zu konfigurieren, müssen Sie im Folgenden Menü Einstellungen vornehmen: 1. IPSec Verbindung zwischen IPSec Client und Gateway 1.1 Einleitung Im Folgenden wird die Konfiguration einer IPSec Verbindung vom Bintec IPSec Client zum Gateway gezeigt. Dabei spielt es keine Rolle,

Mehr

Die Informationen in diesem Artikel beziehen sich auf: Einleitung

Die Informationen in diesem Artikel beziehen sich auf: Einleitung Die Informationen in diesem Artikel beziehen sich auf:? Microsoft ISA Server 2004 Einleitung Der Microsoft ISA Server 2004 bietet sehr umfangreiche Monitoring Möglichkeiten um den Status der Firewall und

Mehr