Tach Zusammen!
Heute bin ich ein Beispiel für Effizienz und schreibe über zwei Module für die Orion
Plattform gleichzeitig – IP Address Manager (IPAM) und User Device Tracker (UDT).
Glücklicherweise sprechen beide Produkte die gleiche Zielgruppe an und harmonisieren perfekt miteinander!
Also, was machen die Dinger?
Fangen wir mit IPAM an. Das spricht man übrigens tatsächlich „eipäm“ aus!
Nutzt ihr noch Tabellen zur Verwaltung von Subnetzen? Das ist ungefähr so fortschrittlich wie dieses Gebäude hier:
Mit SolarWinds IPAM kann man den kompletten Adressraum zentral verwalten und noch einiges mehr. Aber mal von Anfang an!
Nach dem Installieren gehen wir sofort in die Subnetz-Verwaltung.
Die erste Frage ist: Wie bekomme ich meine Daten dort hinein?
Es gibt drei verschiedene Möglichkeiten. Die komfortabelste ist das automatische Erkennen mit „Discover Subnets“:
Ich gebe dem System dazu ein Gateway – optimal: Coreswitch/Corerouter - und es wird versucht über SNMP Daten abzufragen. Dazu werden die folgenden OIDs ausgelesen um die Subnetze zu identifizieren:
NAME | OID |
IpForwarding |
|
IpRouteDest |
|
IpRouteMask |
|
IpCidrRouteDest |
|
IpCidrRouteMask |
|
ipRouteType |
|
NexthopAddress |
|
Tatsächlich entspricht das exakt RFC1213.
Leider trifft man sporadisch auf Hardware Hersteller die die Standards recht kreativ auslegen und in dem Falle wird die automatische Erkennung leider nicht funktionieren können.
Anstatt zur nächst gelegenen Glaskugel zu greifen nutzen wir dann einfach die zweite Funktion vom Screenshot oben, den Import.
Dazu kann man innerhalb von IPAM zuerst eine Vorlage herunterladen:
Diese befülle ich dann mittels Magie in Form von Copy&Paste von meinen alten Tabellen und importiere das fertige Element in das System.
Die dritte Methode ist das manuelle Einpflegen von Subnetzen. Dazu klickt bitte ganz links auf „Add“:
Natürlich legt man nicht dutzende von Subnetzen per Hand an aber die Funktion ist sinnvoll um Planspiele zu betreiben um, zum Beispiel, zukünftige Adressräume zu modellieren.
Nachdem wir nun die Subnetze gesammelt haben, empfiehlt es sich etwaige DHCP und/oder DNS Server anzulegen. Als Beispiel hier DHCP - dazu wechseln wir:
Jetzt kommt es eventuell zu einer Überraschung. Wir klicken auf „Add New/Hinzufügen“:
Ganz oben steht eine Warnung:
Die Maschine muss also schon innerhalb des Systems sein. Wenn noch nichts verfügbar ist wird entweder Sonar bemüht oder ich nehme die Maschine schnell manuell auf.
Bei mir sind die Maschinen schon vorhanden und ich wähle die entsprechende VM aus:
Und darunter kommen die Berechtigungen. Hier kommt es häufig zu Fragen – was genau wird benötigt?
Details gibt es hier:
Ich kann nun einstellen wie oft die Scopes bzw Zonen synchronisiert werden:
Selbstverständlich kann man auch Scopes anlegen/ändern (Scope-Optionen wie z.B. das Gateway) oder DNS Zonen erstellen und manipulieren:
Um hier weiter zu kommen gehen wir also davon aus, dass wir sowohl DHCP als auch DNS im System haben und Daten eingelesen worden sind, und klicken wieder auf die Subnetz-Verwaltung.
In meiner kleinen Laborumgebung habe ich nur zwei Subnetze:
Wenn ich eines auswähle und auf Edit klicke stehen mir einige Eigenschaften zur Verfügung. Interessant sind dort sicherlich die Einstellungen der DNS Zone:
Einmal dort hinterlegt, ist IPAM klar wer für den Bereich verantwortlich ist und kommuniziert mit dem DNS Server.
Dann noch ein paar Kleinigkeiten:
Wenn die Automatik aus ist, habe ich eine passive Tabelle. Das ist sinnvoll zum Planen oder der reinen Übersicht halber, falls ein Subnetz nicht von IPAM aus erreichbar ist (DMZ).
Die Einstellung „Update but not erase“ nutze ich, wenn ich per Hand Attribute gesetzt habe.
Scan-Intervall ist klar, und die Auswahl der Polling Engine kann dann interessant werden, wenn ich mehrere Poller und doppelte Subnetze habe.
Klicke ich tatsächlich in ein Subnetz habe ich eine Tabellen-Ansicht und plötzlich gibt es viel zu sehen:
Zuerst einmal ganz links in violett (mein Kunstlehrer sagte immer „violett ist nicht lila“), gelb und grün – das ist der Status der IP und der ist ziemlich wichtig!
Wir erkennen dadurch nicht nur, was es mit der IP auf sich hat, sondern nutzen diese Information auch zur Lizensierung. Reserviert, in Benutzung und Transient werden lizensiert, verfügbare IP jedoch nicht.
Oben sehen wir die Spaltenbeschreibungen die im Prinzip selbsterklärend sind. Wir nutzen hier verschiedene Protokolle um euch möglichst viele Informationen zu den Adressen liefern zu können.
Man kann die Spalten übrigens auch verstecken bzw weitere dazu legen:
Die nächsten Spalten zeigen die MAC Adresse an sowie den Hersteller:
Die Herstellerinformationen werden bei Updates von IPAM mit eingepflegt. Wenn dort etwas als „unknown“ angezeigt wird wie bei mir, könntet ihr es als Feature Request einreichen damit wir es für euch in das Produkt hinzufügen können.
Die ich ja heute, wie schon bemerkt, so richtig effizient bin, habe ich für meine unbekannten Nodes einen FR angelegt.
https://thwack.solarwinds.com/ideas/10107
Falls ihr heute noch keine gute Tat erledigt habt könnt ihr dem Vorschlag gerne eine Stimme geben 
In den weiteren Spalten wird überprüft ob ein DHCP Scope im System deckungsgleich mit dem Subnetz ist und falls ja, zeigen wir Reservierungen und ClientName an. Ebenso natürlich den Hostnamen über einen nslookup.
Protipp: Die Namensauflösung findet vom SolarWinds Server aus statt. Wenn kein Name angezeigt wird, bitte dort mit dem Troubleshooting starten und nicht von eurer Workstation aus.
Weiter hinten werden drei SNMP OIDs abgefragt:
Klicken wir einmal auf eine IP und editieren!
Interessant hier der Status und der Typ:
Bei „Scanning“ bedeutet off = der DHCP Status ist egal und wird nicht mehr abgefragt.
Wenn wir zurück auf die Startseite von IPAM gehen sehen wir einige sinnvolle Grafiken und Tabellen. Die meisten davon sind selbsterklärend aber guckt einmal kurz hier:
Was genau sehen wir hier? Es gibt unterschiedliche Verknüpfungen in der Vorwärts und Rückwärts Zone des DNS Servers.
Üblicherweise ist die FWD Zone immer aktuell und der Eintrag in BWD veraltet. Wir können es dann von hier korrigieren.
Und das hier ist wirklich klasse:
Wir sehen links eine IP und rechts zwei Maschinen mit der MAC Adresse, die gerne diese IP hätten. Ich weiss also jetzt schon, wer in meinem Netz einen Konflikt verursacht.
Aber! Guckt mal auf die Info in den blauen Spalten.
Dort wird angezeigt, dass beide oberen Maschinen auf dem gleichen 3850 sitzen, die linke in Port 20 im zweiten Stackmitglied, die rechte auch in Port 20 aber im dritten Switch.
Wo kommt das jetzt her?
Das, meine Freunde, kommt aus dem User Device Tracker (UDT)!
UDT ist ganz klassisches Switch Port Mapping und zeigt mir an, wer an welchem Port eingestöpselt ist.
Die Ports selbst werden durch die Sonar Suche der Orion Plattform gefunden und können weiter manuell geändert werden:
Dazu werden OIDs von den Switchen ausgelesen – und zwar eine ganze Menge.
Guckt bitte einmal hier:
Für die komplette Übersicht bitte das Bild abspeichern und dann zoomen.
In den Standardeinstellungen werden die Daten alle 30 Minuten abgefragt sowohl für L2 als auch L3, sofern Multilayer verfügbar ist.
Typische Einsatzszenarien für den UDT sind natürlich ganz klassisch das Auffinden irgendeines Endpunktes oder Benutzers. Mein Lieblingsbeispiel ist „Karl-Heinz aus der Personalabteilung hat wieder ein Ticket geschrieben. Wo finde ich den?“
Dazu konsultiere ich oben rechts die Suche:
Vielleicht möchte ich aber auch einfach nur wissen, wer sich in meinem Netzwerk herumtreibt.
Dazu gibt es ein praktisches Element direkt auf der Zusammenfassung:
Aber Moment einmal – jetzt, wo wir diese Infos haben können wir gleich noch mehr damit anstellen!
Es gibt zwei verschiedene Listen innerhalb vom UDT: Eine „watch list“ und eine „white list“:
Falls ich das benutzen möchte, muss ich zuerst eine „white list“ definieren. Das Standard-Verhalten färbt erst einmal alles in weiss auch wenn es nicht wie ein Kühlschrank aussieht:
Wenn ich mir eine neue Regel erstellen möchte gibt es links einige Optionen:
Custom ist sicherlich die interessanteste davon, da auch Wildcards erlaubt sind:
Komplexe, verschachtelte Regeln sind allerdings nicht möglich. Hierzu sollte eine NAC Lösung in Betracht gezogen werden.
Nehmen wir einmal an wir haben eine simple Regel erstellt, die alle Knoten eines bestimmten Herstellers über die MAC Adresse erkennt. Was passiert jetzt, wenn ein neuer Hersteller auftaucht?
Dann würden wir den Knoten in dieser Tabelle sehen:
Rechts kann ich entscheiden was jetzt geschehen soll. Wenn ich das Ding kenne, klicke ich „safe device“ und es wird eine neue Regel nur für den Knoten erstellt.
Aber was ist, wenn jetzt irgendetwas verdächtig erscheint, ohne dass ihr euch sicher seid warum wie zum Bespiel hier:
In dem Fall klicke ich auf „watch“ und lasse es mir auf die andere Liste setzen:
Nun wird mir das Ding nachverfolgt:
Auch beim UDT gibt es direkt verfügbare Alarme:
Sowie Berichte, natürlich!
Zwei weitere Funktionen habe ich bisher unterschlagen! Hier die erste:
Der UDT kann auf Wunsch mit dem Domain Controller verbunden werden um die Event-IDs 4768 und 4769 auszulesen, die beim Authentifizieren geschrieben werden.
Dadurch lassen sich Benutzerlogins identifizieren und ich kann nicht nur nach Maschinen oder Adressen, sondern auch nach Benutzern suchen.
Diese Funktion ermöglicht aber auch im Zusammenspiel mit SolarWinds Netflow Traffic Analyzer (NTA), nicht nur den Computer, sondern auch den aktiven Benutzer zu finden der eine bestimmte Adresse angesteuert hat. Das ist schon ziemlich detailliert!
Aufgepasst: Der Einsatz dieser Funktion befindet sich in einer „Grauzone“ und sollte vorab mit dem Betriebsrat diskutiert werden.
Eines noch! Erinnert euch noch an die Geschichte mit den doppelten IPs:
Wenn man an dieser Stelle auf einen Port klickt kommt man zu der folgenden Seite:
Shutdown nutzt SNMP-RW um tatsächlich den Port herunterzufahren.
Wäre es jetzt nicht auch toll, wenn man die Informationen verknüpfen kann für Szenarien wie:
Unbekannte MAC im Netz --> Sperre mir den Port automatisch?
Folgt mir bitte unauffällig:
https://thwack.solarwinds.com/ideas/2328
Okay, wir sind im Schnelldurchlauf mit IPAM und UDT fertig.
Beide Module sind wirklich einfach zu verstehen und zu benutzen. Keine Geheimnisse.
Wenn es zu Herausforderungen kommt, ist es meistens auf mangelnde Kompatibilität der Hardware zurückzuführen.
Falls ihr einen solchen Fall habt, tretet einfach direkt mit uns in Kontakt und wir schauen uns das einmal an.
Bis dann macht’s gut, und ihr wisst ja, dass nach SolarWinds mein Lieblingsthema das Dinieren ist oder? Daher hier ein sommerliches Foto:
Salat mit angebratenem Lachs, Feta und einem Dressing auf Zitronen-Honig-Senf Basis. Der Ouzo ist mit Absicht nicht im Bild.