SNMP Netzwerk Monitoring

Huhu!

Heute möchte ich euch ein wenig in die Welt von SNMP Monitoring mit Icinga 2 entführen. Da man leider nicht immer einen Switch mit SNMP zur Hand hat, verwende ich eine GNS3 Netzwerk Umgebung sowie eine CentOS 7 Maschine für Icinga 2.

Doch was ist den dieses SNMP überhaupt, was kann das? Zunächst SNMP steht für Simple Network Message Protocol (RFC 1157) und wurde mit dem Gedanken entwickelt Netzwerkgeräte wie Drucker, Router, Switche und vermutlich irgendwann auch Toaster per IoT von einem Zentralen Punkt im Netzwerk aus überwachen bzw. steuern zu können. SNMP an sich besitzt nicht wirklich viel Magie es beschreibt im Endeffekt wie Datenpakete aussehen können. Damit Icinga 2 (Managmentstation) den Switch (Agent) fragen kann, wie es ihm den heute so geht. Die eigentliche Magie ist die sogenannten Managment Information Base, umgangssprachlich auch MIB genannt.

Die MIB kann man sich wie einen großen Baum vorstellen, dessen Äste und Blätter mit Hilfe von eindeutigen OIDs gebildet werden. Die Blätter die an unseren Ästen hängen sind Objekte wie ein Lüfter, oder eine Festplatte und können als als OID so aussehen: 1.3.6.1.4.1.1.4.

Nach viel Techbabbel kommt nun wenig Kaboom (Practical Examples). An Hand des Beispiel möchte ich euch ein Grundgerüst an die Hand geben, wie man bequem und ohne Geräte spezifisches Plugin ein SNMP Monitoring unter Icinga 2 einfach realisieren kann.

Im ersten Schritt holen wir uns alle OIDs samt Beschreibung vom Gerät, in meinem Fall von einem VyOS Router:

snmpwalk -Os -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_desc
snmpwalk -v 1 -c public 192.168.174.131 >> /tmp/snmpwalk_oid

Für das Beispiel wähle ich drei OIDs aus:

.1.3.6.1.2.1.2.2.1.2.1
.1.3.6.1.2.1.2.2.1.2.2
.1.3.6.1.2.1.2.2.1.2.3

Mit dem Director hab ich ein Template und Service angelegt, welches auf das Check_Plugin/Kommando check_snmp zurückgreift. Die ausgewälten OIDs werden Kommasepariert per Costume Attribut “snmp_oid” mitgegeben:

template Service "snmp" {
    check_command = "snmp"
    max_check_attempts = "3"
    check_interval = 1m
    retry_interval = 20s
}
object Service "Interfaces" {
    host_name = "vyos"
    import "snmp"
    vars.snmp_label = "Interfaces"
    vars.snmp_oid = ".1.3.6.1.2.1.2.2.1.2.1,.1.3.6.1.2.1.2.2.1.2.2,.1.3.6.1.2.1.2.2.1.2.3"
}

Nach dem ausbringen der Konfiguration sollte das ganze folgendermaßen aussehen:

 

Tipp am Rande:
Falls euer Gerät nicht auf Öffentlichen MIBs aufbauen sollte, wie hier im Beispiel, bekommt ihr die im Regelfall vom Hersteller bereitgestellt. Die MIB wird einfach zu den bereits existierenden hinzugefügt und dann ist alles wie gehabt! 🙂

Damit verabschiede ich mich und wünsche wie immer viel Spass beim Implementieren!

Max Deparade

Autor: Max Deparade

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn er nicht gerade fieberhaft auf sein neues Macbook wartet.

SSL geknackt! Naja, fast.

Wer kennt das nicht: Da sitzt man beim Kunden (oder auch remote) und debugt ein Programm wie bspw. Icinga 2. Alle Stricke reißen und man ist dazu genötigt, den Netzwerk-Verkehr zu inspizieren… Ach ja, das ist ja alles SSL-verschlüsselt. Und dies ist auch nicht abschaltbar, selbst wenn man es dürfte. Und jetzt?

Genau in dieser Zwickmühle befand sich neulich ein Kollege und wandte sich kurzerhand an einen der Sicherheitsfanatiker hier in der Firma – mich.

Als solcher kenne ich die Maschen der dunklen Seite der Macht. So auch bspw. diese hier:

  1. Wireshark, den Netzwerk-Verkehr und den privaten Schlüssel von Icinga 2 Du brauchst: /var/lib/icinga2/certs/HOST_FQDN.key
  2. Den Schlüssel in Wireshark Du hinterlegst: Preferences (Command + Komma) / Protocols / SSL / RSA key list / Edit
  3. Den Netzwerk-Verkehr automatisch Wireshark entschlüsselt

So jedenfalls die Theorie ist…

In der Theorie sind Theorie und Praxis gleich – in der Praxis nicht. So wurden auch wir davon überrascht, dass sich am mitgeschnittenen Kauderwelsch nichts geändert hat. “Stimmt…”, fiel mir wieder ein, “da war was…”

 

Das DH macht den Unterschied

Zu Beginn einer SSL-Verschlüsselten Verbindung handeln Client und Server u.a. den konkreten Verschlüsselungsalgorithmus aus. In diesem Fall waren die beiden besonders schlau und wählten einen “Diffie Hellman” Algo. Schön für den Sysadmin, doof für uns. Der Zweck von Diffie Hellman ist es nämlich, genau solche Machenschaften der dunklen Seite der Macht dumm aus der Wäsche schauen zu lassen.

Zum Glück hatte ich noch ein Ass im Ärmel. Icinga 2 gibt dem Admin nämlich die Möglichkeit, die zu verwendenden Algorithmen einzuschränken:

--- /etc/icinga2/features-available/api.conf
+++ /etc/icinga2/features-available/api.conf
@@ -7,4 +7,6 @@
   //accept_commands = false

   ticket_salt = TicketSalt
+
+  cipher_list = "AES256-SHA256"
 }

Im konkreten Fall habe ich mich der Einfachheit halber auf einen einzigen nicht-DH Algorithmus beschränkt:

openssl ciphers |tr : \\n |grep -vFe DH

Es aber gingen theoretisch auch alle:

openssl ciphers |tr : \\n |grep -vFe DH |paste -sd : -

Nach einem Neustart von Icinga 2 und einer Wiederholung der HTTP-Anfragen hatten wir dann endlich Transparenz à la DSGVO (die grün markierten Pakete):

 

Fazit

Viel Spaß beim debuggen (lasst euch nicht vom Datenschutzbeauftragten erwischen) und vergesst nicht, die Lücke hinterher abzudrehen.

Und wenn bei euch wirklich alle Stricke reißen, helfen wir euch gerne weiter.

Alexander Klimov

Autor: Alexander Klimov

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Road to OpenStack

Openstack

Seit bereits sieben Jahren betreiben wir bei NETWAYS eine Private Cloud Installation auf Basis von OpenNebula. Damals starteten wir gerade einmal mit drei Hypervisor Servern und einem NFS-Datastore, bereitgestellt aus einer Netapp 3140. Bis heute hat sich daran natürlich einiges verändert. Die Technologien haben sich geändert, als auch die notwendigen Ressourcen sind deutlich gestiegen. Heute laufen zum Beispiel unsere virtuellen Maschinen nicht mehr auf NFS sonder auf Ceph RBDs. Das Ceph-Cluster, verteilt über zwei Standorte, umfasst aktuell knapp ein halbes Petabyte Storage Kapazität.

OpenNebula hat uns während dieser Zeit der Transformation immer gut und zuverlässig zur Seite gestanden. Sämtliche Upgrades verliefen meist tadellos. Deshalb ist es fast ein bisschen Schade, diesem tollem Open-Source-Projekt den Rücken zu kehren und von nun an mit dem Platzhirsch OpenStack zu liebäugeln. Einer der Hauptgründe diesen Schritt zu gehen – neben beispielsweise der oft besseren und breiteren Verfügbarkeit an Integrationen und Tools von Dritten (z.B. Foreman, Puppet, Terraform usw.) – ist Software Defined Networking. Kurz SDN. Natürlich gibt es hierfür auch gute Ansätze und eine Basis-Unterstützung im OpenNebula Projekt. Theoretisch gibt es sogar die Möglichkeit fast jeden SDN Provider in OpenNebula, dank seiner Erweiterbarkeit, zu integrieren, aber leider nicht ohne selbst vorher ordentlich Pionierarbeit leisten zu müssen. Bei OpenStack hat man eher die Qual der Wahl, welcher SDN Provider für sein Setup passt.

Mit SDN virtualisiert man in einem Overlay Netzwerk ein künstliches und unabhängiges Netzwerk, ohne dass man das Underlay, die tatsächliche Hardware z.B. Switches und Router, auf die jeweiligen Umstände und Anforderungen anpassen muss. Die Vorteile liegen dabei auf der Hand: Im Underlay hat man ein stabiles Trägernetzwerk, dass man im Prinzip nur noch skalieren und robust betreiben muss und im Overlay werden die Anforderungen der Kunden realisiert. Wir setzen hierbei im Underlay auf Cumulus Linux in Kombination mit Mellanox Hardware und im Overlay auf die SDN Lösung von Midonet. Beides harmoniert gut miteinander und kann entsprechend verknüpft werden.

In unserer neuen Cloud-Installation ist es für uns und unsere Kunden dann dadurch möglich im Self-Service sich Netzwerke, Router, VPNs, Load-Balancer und Firewall-Regeln zu erstellen, ohne hierfür vom Administrator Hilfe und Beistand einzufordern. Auch überlappende private Netzwerke sind dann kein Problem und eine Pflege und penible Vergabe von IPs und Subnetzen bzw. VLANs fallen somit vom Tisch.

Klar ist, der Self-Service Part könnte mit OpenNebula in unserer bisherigen Installation ebenfalls gelöst werden, allerdings beeindruckt insbesondere die technische Umsetzung und das sehr raffinierte und intelligente Konzept der SDN Lösung von Midonet. Wie das ganze technisch funktioniert erklären wir im Blog in einem unserer nächsten Artikel.

Sebastian Saemann

Autor: Sebastian Saemann

Sepp kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet zusammen mit Martin das Managed Services Team. Wenn er nicht gerade Server in MCollective einbindet, versucht er mit seinem Motorrad einen neuen Geschwindigkeitsrekord aufzustellen.

Der kleine Ping erkundet die Welt

Als der kleine Ping vor bald 34 Jahren geboren wurde, war die Welt noch übersichtlich und in Ordnung. Jeder kannte jeden und man lernte schnell neue Freunde kennen. Diese Freunde bleiben einem dann häufig auch lange treu. Ein offenherziger Kerl wie der kleine Ping lernte damals sehr schnell sehr viele Freunde kennen.

Gut erzogen und treu wie er war, besuchte er die meisten davon immer wieder und wieder. War jemand krank, dann war Ping schon mal länger unterwegs oder kam gar nicht mehr zurück. Aber langsam von vorn.

Seinen Namen bekam der kleine Ping vermutlich, weil sein Vater Mike zu viele Kriegsfilme im Fernsehen schaute. Oder weil seine Arbeit bei der US Army ihn so faszinierte. Ping, so hört sich nämlich der Sonar ein einem U-Boot an. Wie ein Klopfen. Irgendwie fanden seine Eltern das wohl sehr spannend. Also die Tatsache dass da Schallsignale gesendet und wieder zurück reflektiert wurden.

Das wäre doch auch ein schöner Job für unseren Ping, dachten sie. Also wurde der kleine Ping schon sehr früh losgeschickt, um unsere Welt zu erkunden. Da war er noch ganz klein, gerade mal 1000 Zeilen hoch. Dennoch fühlte er sich wie ein ganz Großer. Ständig auf Reisen kannte er sehr bald jede Straße, jede Autobahn und jeden Weg wie seine Westentasche. Das fand er unglaublich spannend.

Sein Vater war aber sehr streng. Jedesmal wenn Ping das Haus verließ notierte er auf die Millisekunde genau, wie spät es war. Und als der Ping dann wieder zurückkam, wurde auch das notiert. Aus Start- und Endzeit errechnete sein Vater dann, wie lange der kleine Ping unterwegs war.

Als der kleine Ping älter wurde, machte er sein Hobby zum Beruf. Wenn jemand wissen wollte, wie lang man auf einer Strecke unterwegs war, dann ging er zum kleinen Ping. Wollte ein LKW-Fahrer wissen, ob sein fetter Brummi unter einer Brücke Platz hätte – unser Ping konnte das klären.

Manchmal war es freilich ein wenig langweilig. Als Berufspendler war er hauptsächlich auf immer denselben Strecken unterwegs. Zu den Stoßzeiten im Stau zu sein war auch kein Vergnügen. Ping nahm sich dann ab und an andere Texte zum Lesen mit, das sorgte für gute Unterhaltung. Sein Vater prüfte übrigens immer, ob er auch wirklich mit denselben Texten wieder nach Hause kam. Fehlten Buchstaben oder waren falsche dabei, dann ließ er ihn unter Umständen gar nicht mehr ins Haus. Ping musste dann auf der Straße übernachten.

Ab und an erlaubte Ping sich einen Spaß. Da packte er ein Vielfaches an Ladung drauf um zu sehen, ob auch wirklich alle Tunnel-Decken und Brücken hoch genug waren. Er war halt so ein richtig nerviger Besserwisser. Und ab und an krachte es dabei natürlich ganz heftig. Ping bekam dann aber nicht etwa Stress. Das lief dann einfach als “Prüfung des Maximalen Tunnel Umfangs”, kurz MTU-Test. Ping hatte seinen Spaß – und die Polizei war froh, dass sie von jemandem auf Verletzungen der Bauvorschriften hingewiesen wurden.

Die richtig wichtigen Jobs bekamen andere. Einige seiner Brüder arbeiteten bei der Polizei, das hätte dem kleinen Ping gefallen. Bei welcher Einheit wäre ihm egal gewesen, zur Not auch bei den lahmen Kerlen von der “Ruhigen Inneren Polizei”, dem RIP. Das sind die Verkehrspolizisten in den kleinen Käffern auf dem Land.

Im Grunde machten die nicht viel mehr als die Leute nach links und rechts zu dirigieren. Aber dennoch. Betrachtete man das Geschehen vom Kirchturm aus, dann sah das schon beeindruckend aus. Alles floss schön links und rechts an den Polizisten vorbei – genau wie die sich das gerade so vorstellten. Ganz großes Kino!

Die richtig coolen Jungs hingegen arbeiteten bei der “Beindruckend Großen Polizei”, dem BGP. Das ist die Autobahnpolizei, irre was bei denen abging. Schon bei der Aufnahmeprüfung musste jeder von denen ein paar hunderttausend Routen im Kopf haben. Das klang irre anspruchsvoll und stressig. So weit wollte der kleine Ping dann doch nicht hinaus. Aber ab und an davon zu träumen, das war schon schön.

Der kleine Ping war zufrieden mit seinem Job. Er war es, der dieses Berufsbild erfunden und geformt hatte. Tausende hatten es ihm im Laufe der Jahre nachgemacht. Und heute ist er nicht zuletzt wichtiger Bestandteil einer jeden Monitoring-Umgebung. Auch wir haben kaum irgendwo eine Icinga-Umgebung am Laufen, in welchem er nicht zuverlässig seinen Dienst verrichten würden. Darum sei ihm an dieser Stelle mal ein Lob ausgesprochen: er macht seinen Job ausgezeichnet, ist zuverlässig und unauffällig.

Weiter so, lieber kleiner Ping!

Thomas Gelf

Autor: Thomas Gelf

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

Mission Loadbalancer Upgrade

Mission Loadbalancer Upgrade
Heute Nacht hatte das Managed Services Team die spannende Aufgabe unseren Loadbalancer Cluster auf neue Systeme umzuziehen.

Der alte Cluster lief zwar seit Jahren problemlos, allerdings erhoffen wir uns von dem neuen Setup eine gesteigerte Netzwerk Performance und durch neuere Cluster Management Pakete insgesamt auch eine bessere Wartbarkeit, wie z.B. bei unserem halbjährlichen Failovertest.

Sehr wichtig ist dabei natürlich, dass auch in der Nacht die Downtime der Services so gering wie möglich ausfällt.

Da bei uns die komplette Loadbalancer Cluster Konfiguration über Puppet provisioniert wird, war es daher auch kein Problem die Neuinstallation der Cluster Knoten sehr zügig durchzuführen.

Die tatsächliche Downtime der Services betrug daher nach der Neuprovisionierung wie erwartet auch nur wenige Sekunden und die ersten Performance Tests waren sehr vielversprechend.

Ein Beispiel für einen Service Eintrag im Puppetlabs Hiera sieht in etwa so aus (wir verwenden dafür den ldirectord aus dem Linux Virtual Server Projekt):

ldirector::member:
  "web-host1.netways.de_%{::hostname}":
    ip: "%{ipaddress_bond0_XX}"
    weight: 1
    service_name: 'web-host1.netways.de'
    ssl: true
    password: 'XXXXXXXXXX'
    ensure: 'present'

Dieser Eintrag in einer Hostname FQDN YAML Datei genügt somit, um den entsprechenden Host in den Loadbalancer Pool eines Services mit den entsprechenden Parametern (Gewichtung u.s.w.) aufzunehmen.

Im zugrundeliegenden ldirectord Puppetmodul werden zudem ausgiebig ‘Exported resources’ in Verbindung mit der PuppetDB verwendet, um am Ende die komplette Loadbalancer Konfiguration Live zu nehmen.

Wenn Sie sich für mehr Informationen zu einem redundanten, jederzeit skalierbaren Loadbalancer Setup und mehr interessieren, schauen Sie sich doch einfach ein mal unser Hosting & Services Angebot an.

Stefan Gundel

Autor: Stefan Gundel

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

Externe Überwachung durch Icinga2 Satelliten bei NETWAYS Web Services

Über den NWS icinga2 Satellite wurde ja bereits im März berichtet. Dieser ermöglicht seine Dienste, wie z.B. HTTP,IMAP,POP3,SMTP, ICMP von extern zu überwachen. Durch das Cluster und Zonenkonzept von Icinga2 ist es eine Leichtigkeit diese Satelliten in seine bestehende Umgebung zu integrieren.

Unser Team Infrastruktur will sich nun diesen Service natürlich auch zu nutze machen und seine externe Überwachung mit Satelliten in Kalifornien und Tokyo erweitern. Das ermöglicht uns zum Beispiel Latenzen und Verfügbarkeit spezieller Services zu überwachen, die außerhalb von Europa aufgerufen werden.

Dieser Service wird dann auch allen unseren Kunden bei NETWAYS Managed Services zur Verfügung stehen.

Martin Schuster

Autor: Martin Schuster

Martin gehört zu den Urgesteinen bei NETWAYS und leitet zusammen mit Sebastian das Managed Services Team. Vorher war er bei 100world als Systems Engineer angestellt. Während er früher Nürnbergs Partykönig war, ist er nun stolzer Papa und verbringt seine Freizeit damit das Haus zu renovieren.