NoSpamProxy mit Paessler PRTG überwachen

Letzte Aktualisierung am 24.04.2022, 18:04:42 Uhr

Inzwischen hat fast jedes Unternehmen ein Monitoring System im Einsatz. Die Standardthemen wie eingehender/ausgehender Datenverkehr, Status von Diensten, freier Arbeitsspeicher und Festplattenkapazität, Prozessorlast, etc…hat jeder auf dem Radar. Anders sieht es aus, wenn Fachanwendungen auf den jeweiligen Server betrieben werden. Hier taucht vor und nach der Implementierung immer die Frage auf: Habe ich alle relevanten Daten im Monitoring System erfasst? Oft merkt man erst bei einer Störung der Anwendung, dass man etwas vergessen. Dann nämlich, wenn das  Monitoring System keinen Alarm anzeigt. So auch in diesem Fall geschehen. 🙂

In dieser Umgebung kommt für die Abwehr von Malware/Spam das Produkt NoSpamProxy (NSP) von Net At Work zum Einsatz. Für die Überwachung der kompletten IT-Landschaft ist bereits PRTG aus dem Hause Paessler implementiert. Eines Tages schlugen über das Ticketsystem nach und nach  Nachfragen in der IT Abteilung auf. Verschickte E-Mails an externe Empfänger kommen dort nicht an. PRTG hat diesbezüglich keinen Alarm angezeigt: Exchange – online, NSP – online, Internetzugang – online, benutzerdefinierte SLA Probes – online. Es hat sich bei der genaueren Analyse herausgestellt, dass der Internet Service Provider Probleme mit dem Routing hatte. Was dazu geführt hatte, dass das NSP Gateway keine Verbindung zum gegenüberliegenden E-Mailserver aufbauen konnte. 🙁

Bei meinen Überlegungen und anschließender Suche im Internet bin ich auf das PowerShell Skript von Thomas Stensitzki gestoßen. Es ist bzw. war am Ende des Tages die einzig brauchbare Seite, welche mich meinem Ziel einen großen Schritt nähergebracht hat.  Das größte Manko an seinem PowerShell Skript ist meiner Meinung nach, dass er auf dem Server auf dem die NSP – Intranet Rolle läuft, auch eine PRTG Probe installiert hat. Der Sensor „Programm/Skript“ führt das hinterlegte Skript wird immer auf der PRTG Probe aus, dem das Gerät und somit auch Sensor zugeordnet ist.

Unsere Anforderungen hingegen waren wie folgt:

  • Auswertung der Nachrichtenverfolgung über alle NSP Gateways hinweg.
  • Auswertung der Nachrichtenverfolgung des angegebenen NSP Gateways.
  • Übergabe des Abfrageintervalls des PRTG Sensors an das Skript. Somit sind manuelle Anpassungen im PowerShell Skript nicht notwendig.

Entstanden ist folgendes PowerShell Skript bzw. PRTG Sensor. Die jeweils aktuelle Fassung steht auf meinem Git Repository zur Verfügung.

Das Skript herunterladen und ggf. einen individuellen Dateinamen vergeben. Wichtig ist der Dateityp muss .ps1 sein. Die Datei auf der PRTG Probe in das Verzeichnis „.\Custom Sensors \EXEXML“ (z.B. C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML) ablegen/abspeichern.

Anschließend die Weboberfläche von PRTG in einem Browser anrufen und anmelden. Zuerst auf der Probe bzw. in der entsprechenden Hierarchie ggf. den Server auf dem die NSP Intranet Rolle installiert als Gerät anlegen. Danach einen neuen Sensor dem Gerät hinzufügen. Im Assistenten den Sensortyp „Programm/Skript (Erweitert)“ auswählen.

Nun erscheint die Maske für die Allgemeinen- und Sensoreinstellungen.

Parameter:

Als erster Parameter muss „%device“ eingegeben werden. PRTG speichert den Computernamen des übergeordneten Geräts in der Variablen %device. Grund dafür ist, dass ich den Computername im PowerShell Skript in eine Variable gepackt habe. Gerade wenn man unabhängige NSP Instanzen in seiner Landschaft hat, ist das PowerShell Skript flexibel und muss nicht unnötig oft dupliziert werden.

Als zweiter Parameter muss der Intervall in Minuten angegeben werden. Hintergrund ist, dass der Sensor natürlich nicht bei jeder Abfrage die gesamte Nachrichtenverfolgung des NSPs auswerten soll. Sondern nur Einträge, die seit der letzten Ausführung des Sensors erfasst worden sind. Wird der Abfrageintervall des Sensors nur alle 30 Minuten ausgeführt, so muss natürlich auch der dieser Parameter geändert werden. Wichtig ist, dass der Wert in Anführungszeichen steht! Bis dato gibt es in PRTG keine Variable für den Abfrageintervalls des Sensors.

Als dritter Parameter kann optional noch der Computername angegeben werden, auf dem die NSP Gateway Rolle läuft. Somit kann explizit für den angegeben Server die Statistik abgerufen und ausgewertet werden. Dies macht meiner Meinung nach Sinn, wenn man mehrere NSP Gateways im Einsatz hat und diese zudem über verschiedene Internetleitungen agieren.

%device "5"

Sicherheitskontext:

Nach einer PRTG Standardinstallation wird der dazugehörige Dienst „PRTG Probe Service“ unter dem Benutzer „Lokales System“ ausgeführt. Mit diesem Systembenutzer ist es nicht möglich, eine PowerShell Remoteverbindung auf einen entfernen Server aufzubauen. Daher muss die zweite Option ausgewählt werden. In 99% der Fälle ist bereits entsprechende Zugangsdaten im übergeordneten Gerät bzw. in der Hierarchie konfiguriert. Denn Sensoren für Windows-Systeme (z.B. WMI) greifen auf dieselben Zugangsdaten zurück.

Sind alle Einstellungen und ein schöner Name für den Sensor vergeben, kann der Sensor erstellt werden.

Nachstehend ein Screenshot des Sensors, wenn dieser eingebunden ist. In diesem Fall handelt es sich um meine Testumgebung, wo natürlich ohne Lizenzschlüssel für NSP und E-Mailserver auch nichts zu sehen ist. 😉

Der Code bzw. Sensor ist sozusagen noch BETA. Ich habe diesen in zwei verschiedenen Umgebungen bisher im Einsatz. Somit würde ich mich natürlich freuen, wenn sich weitere Tester finden lassen. Viel Spaß beim Ausprobieren. 🙂

Abonnieren
Benachrichtige mich bei
4 Comments
neueste
älteste
Inline Feedbacks
View all comments
Frank Carius
27.09.2019 11:50

Nett geschrieben und vor allem die Set-PrtgResult-Funktion hat es mir angetan :-). Du schreibst, dass man auf dem NSP dann eine PRTG Probe installieren müsste. Und du verwendest „Invoke-command“, wozu die Rollen aber auch erreichbar sein müssten. Es geht vielleicht eleganter (je nach Sichtweise) ich würde das Skript einfach per Windows Taskplaner alle x Monuten auf dem PC laufen lassen, auf dem die NSP Commandlets vorliegen und die Ergebnisse per HTTP-Push an PRTG posten. https://www.msxfaq.de/tools/prtg/prtghttppushsensoren.htm. Ich nehme ihr Posting mal zum Anlass mal zu schauen, was wir vielleicht ins Produkt einbauen können. NoSpamProxy hat aber schon heute Windows Performance Counter… Weiterlesen »

Jan Jäschke
25.09.2019 08:36

Hallo Herr Wydler,

es freut mich sehr zu sehen, dass Sie Ihre Arbeit und Ihr erarbeitet Wissen mit der Öffentlichkeit teilen.
Ich freue mich schon drauf Ihr Skript in meiner Testumgebung auszuprobieren 🙂

Außerdem habe ich mir die Freiheit genommen Ihren Beitrag in unserem Forum zu verlinken (https://forum.nospamproxy.com/showthread.php?tid=17). Es ist ein hervorragendes Beispiel was mit dem NSP unter der Haube alles möglich ist.

Ich freue mich schon auf weitere Beiträge von Ihnen. 🙂

Mit freundlichen Grüßen,
Jan Jäschke

Produktmanager der Net at Work GmbH