NoSpamProxy mit Paessler PRTG überwachen

Letzte Aktualisierung am 12.10.2024, 10:10:50 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 Lizenz Schlü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. 🙂