Nagios 4 unter Ubuntu 18.04 (Upgrade)

Nach dem Upgrade von Ubuntu 16.04 auf Ubuntu 18.04 hatte ich mit diversen Fehlern unter Nagios zu kämpfen. Die meisten waren im Zusammenhang mit SSL.

NRPE und NSClient++

Der NSClient++ bringt leider nur 512bit-DH-Schlüssel mit. Der aktuelle NRPE verlangt aber eine stärkere Verschlüsselung. Die Fehlermeldung die ich in Nagios erhalten habe war:

Error: Could not complete SSL handshake. <host> 1

Im nsclient.log war diese Fehlermeldung zu finden:

ssl alert handshake failure: 1040

Meine Lösung (nach einiger Recherchearbeit) ist:

Mit OpenSSL stärkere Diffie-Hellman-Schlüssel zu erzeugen und diese dann in die Clients zu verteilen (Fleißarbeit). Dazu folgenden Befehl ausführen:

openssh dhparam -C 2048

Es wird dadurch ein Schlüssel erzeugt (was einen Moment dauert), den man dann in eine Datei (bspw. nrpe_dh_2048.pem) speichert. Der Schlüssel beginnt mit -----BEGIN DH PARAMETERS----- und Endet mit -----END DH PARAMETERS----- . Die Datei wird dann im Zertifikatspfad vom NSClient++ abgelegt (bspw. C:\Program Files\NSClient++\security\)

Außerdem muss dann noch folgender Eintrag in den Abschnitt [/settings/NRPE/server] der nsclient.ini eingetragen werden:

; DH KEY -
dh = ${certificate-path}/nrpe_dh_2048.pem

Nach einem Neustart des NSClient++ Dienstes kann NRPE auch wieder abgerufen werden.

Hilfreichste Quelle: https://help.univention.com/t/problem-nagios-ssl-issues-with-nsclient/11620

SSH und alte Cipher

Manche Systeme, die mit Nagios überwacht werden, haben ältere SSH-Versionen, die entsprechend veraltete Cipher benutzen. Bei mir war es u.a. ein Fujitsu Eternus. Fehlermeldung in Nagios war folgende:

[ssh return code = 255]

Eine Überprüfung via direkter SSH-Verbindung ergab, dass mein System nicht die nötigen Cipher anbietet:

Unable to negotiate with 192.168.2.3 port 22: no matching cipher found. Their offer: aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast1 28-cbc,3des-cbc,des-cbc,des-cbc,arcfour128,arcfour

Als Lösung habe ich einen der genannten Cipher (aes256-cbc) in der /etc/ssh/ssh_config hinzugefügt:

Ciphers +aes256-cbc

Anschließend war eine SSH-Verbindung zu dem betroffenen System wieder möglich und Nagios hat wieder korrekte Werte geliefert.

NagiosQL unter Ubuntu 18.04 LTS (PHP7.2, MySQL)

In Anschluss an meinen Beitrag von vor ein paar Jahren (NagiosQL unter Ubuntu 16.04) habe ich hier einen Fix für NagiosQL unter der aktuellen Ubuntu 18.04. LTS. Ich sag nur soviel dazu: bei mir läuft es bisher problemlos, aber ich übernehme keine Haftung/Garantien.

Neuer E-Mail-Alias für alle Exchange Benutzer

Es gab die Anforderung, eine neue Domain für den E-Mail-Empfang zu Exchange hinzuzufügen und entsprechend alle Benutzer und Verteilergruppen mit der neuen Domain auszustatten.

Dazu habe ich dieses Script gebaut (für Exchange 2010), um alle ~500 Objekte entsprechend zu ergänzen. Es bearbeitet zuerst die Benutzer (es ignoriert deaktivierte Benutzer), dann die normalen Verteilergruppen und zuletzt die dynamischen Verteilergruppen. Die Alias-Adressen werden entsprechend dem Mailbox-Alias angelegt.

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

$ADSearchBase = "ou=Firmenname,dc=domain,dc=tld"
$domain = "domain.tld"

#Users
$targets = get-aduser -filter {Enabled -eq $true} -searchbase $ADSearchBase
foreach ($user in $targets) 
{ 
  $mbxalias = (get-mailbox -identity $user.SamAccountName).Alias
     Set-ADUser $user -add @{proxyaddresses="smtp:$mbxalias@$domain"}
}

#Distribution Groups
$grouptargets = get-adgroup -filter "groupcategory -eq 'distribution'" -searchbase $ADSearchBase
foreach ($group in $grouptargets) 
{ 
  $mbxalias = (get-distributiongroup -identity $group.SamAccountName).Alias
     Set-ADGroup $group -add @{proxyaddresses="smtp:$mbxalias@$domain"}
}

#Dynamic Distribution Groups
$dyngrouptargets = get-adobject -filter "objectclass -eq 'msExchDynamicDistributionList'" -searchbase $ADSearchBase
foreach ($dyngroup in $dyngrouptargets) 
{ 
  $mbxalias = (get-dynamicdistributiongroup -identity $dyngroup.Name).Alias
     Set-ADObject $dyngroup -add @{proxyaddresses="smtp:$mbxalias@$domain"}
}

Watchguard, Azure, VPN

Kleiner Tipp am Rande: wenn man eine virtuelle Watchguard bei Microsoft Azure betreibt und man dorthin ein L2TP-VPN von einem halbwegs modernen Windows aus aufbauen möchte (gilt für Windows Vista, Windows 7, Windows 8 und Windows 10), ist zu beachten, dass es sich um eine NAT-Verbindung handelt. Windows kann damit eigentlich nicht umgehen und der Tunnel-Aufbau wird somit fehlschlagen.

Es gibt einen Workaround dazu: erstelle einen Registry-Eintrag. Der Pfad lautet:
HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent

Der nötige Eintrag ist ein REG_DWORD mit dem Namen „AssumeUDPEncapsulationContextOnSendRule“ mit dem Wert „2“

Ach ja, noch eine Sache: Watchguard unterstützt offiziell kein Split Tunneling bei L2TP. Es funktioniert aber doch. Und nicht nur bei L2TP, sondern auch bei IKEv2. Dazu fügt man der VPN-Verbindung über den Powershell-Befehl „Add-VpnConnectionRoute“ einfach die nötige Route zu. Das schöne ist: die Route ist persistent, muss also nicht immer wieder neu eingegeben werden.
Bspw.:

Add-VpnConnectionRoute -ConnectionName "Mein VPN" -DestinationPrefix 10.0.0.0/16

Natürlich muss der VPN-Verbindung auch gesagt werden, dass Sie Split Tunneling nutzen soll. Bspw.:

Set-VpnConnection -Name "Mein VPN" -SplitTunneling $true

Für weitere Informationen schaut euch gerne die Dokumentation bei Microsoft an:
https://docs.microsoft.com/en-us/powershell/module/vpnclient/?view=win10-ps

Firewall und Spiegel Online

Dieser Artikel beschreibt ein Problem speziell mit Watchguard Firewalls und Spiegel Online (SPON). Vielleicht ist es aber auch bei anderen Firewall-Lösungen nützlich.

Wir hatten in den letzten Wochen bei einigen Kunden das Problem, dass sich bei SPON der Hinweis, dass man doch bitte den AdBlocker ausschalten solle, öffnete, obwohl kein AdBlocker installiert war. Die Ursache ließ sich relativ schnell auf den HTTP-Proxy-Dienst der eingesetzten Firewall (Watchguard) eingrenzen. Es hat aber dann tatsächlich noch etwas gedauert, bis klar wurde, was genau das Problem verursacht. Nachdem wir zunächst SPON in die Proxy-Ausnahmen eingetragen und auch testweise Virenscan und andere Dienste im Proxy deaktiviert hatten, war eine Analyse des Netzwerkverkehrs nötig, um festzustellen, dass bestimmte HTTP-Header-Informationen vom Proxy entfernt werden, die – wie sich herausstellte – für die Funktionalität des Anti-AdBlocker-Prüfscripts bei SPON nötig waren.

Letztendlich hat geholfen, das Pattern

Access-Control-Allow-Origin:*

bei den Response-Headern zu erlauben.

Interessanterweise hatten nicht alle Kunden mit Watchguard das Problem. Es ließ sich allerdings auf die Kunden eingrenzen, die schon vor dem Jahr 2016 auf Watchguard als Firewall-Lösung setzen. Möglicherweise hat Watchguard irgendwann mal in die Standard-Einstellungen für HTTP-Proxys den Header-Typ aufgenommen, weshalb bei neueren Watchguard-Kunden der Header bereits erlaubt wird. Wenn man aber bei alten Kunden die bestehende Konfiguration von alten Geräten auf neue Geräte importiert, wird die Standardeinstellung überschrieben und nur die veraltete Header-Typ-Liste wird verwendet.