PlanetNTF

Der Begriff "Heuristische Analyse" wird im Zusammenhang mit Anti-Malware-Software ins Spiel gebracht und soll beschreiben, dass die Software nicht nur nach bestimmten Signaturen bzw. Hashes prüft, sondern auch das "Verhalten" einer Software bewertet, um herauszufinden, ob diese schädlich sein könnte. Der Grundgedanke lässt sich sinnvollerweise auch auf andere Sicherheitsfelder bzw. IT-Sicherheit allgemein ausweiten. Die Idee ist, Abweichungen von "normalem" Verhalten zu identifizieren bzw. diese Abweichungen in einem größeren Kontext miteinander in Verbindung zu setzen, um so Hacks oder den Befall durch Schadsoftware identifizieren zu können.

Ein Beispiel aus dem wahren Leben der jüngeren Vergangenheit soll erläutern, was ich meine:
Ein Kunde ruft an und beschreibt, dass einer seiner Nutzer seltsame Zustellungsfehler-Nachrichten bekäme, obwohl der die entsprechenden Adressen nicht adressiert habe. Ein kurzer Blick auf seinen Server zeigt, dass der Domino-Server, der im Internet steht, zu einem Spam-Relay umfunktioniert worden war. Klassischer Fehler, denkt man sich; aber nein, der Server ist so eingestellt, dass er nur authentifizierten Nutzern, das relaying erlaubt. Ein genauerer Blick offenbart, dass es einen Account gibt, mit dessen Autorisierung von wechselnden asiatischen IP-Adressen SMTP-Verbindungen zum Versenden von E-Mails aufgebaut wurden. Der fragliche Account ist offenbar gehackt. Die Ursache ist schnell bereinigt und die Folgen behoben.

Dieses Beispiel soll vor allen Dingen zeigen, dass auch "legales" Verhalten schädlich sein kann. Es wurden gültige Credentials genutzt, freigeschaltete Ports verwendet, keinerlei Protokollfehler missbraucht, keine Malware installiert... Firewalls und Anti-Virensoftware hatten niemals eine Chance. Der Fehler wurde mehr oder weniger zufällig bekannt.

Doch das muss keineswegs so sein. Eine genauere Beobachtung der Vorgänge auf dem Server hätte zeigen können, dass es eine ungewöhnlich hohe Anzahl von versendeten E-Mails gab, die aufmerksam hätte machen können. Natürlich kann kein Mensch die entsprechenden Kennzahlen immer im Auge behalten. Vielmehr gibt es Werkzeuge, die das für einen Administrator übernehmen können. Die Beobachtung kann durch den Domino Statistic Collector übernommen werden.
Man erstellt einen Event-Generator zum Beispiel für den Wert: mail.delivered, so dass ein Alarm ausgelöst wird, wenn ein bestimmter Threshold überschritten wird. Wie hoch der Threshold ausfällt, ist natürlich individuell, denn nicht nur muss man die normalen Werte in der jeweiligen Umgebung kennen, sondern auch seine akzeptablen/unverdächtigen Maximalwerte kennen, damit man eine Abweichung überhaupt identifizieren kann, ohne allzu viele falsche Alarme zu erzeugen.
Für die Überwachung dieser Art ist keinerlei Zusatzsoftware erforderlich, es reicht die sorgfältige Konfiguration der Domino Statistiken und Events. Hierbei helfen wir gerne.

Die Sicherheit der Aussagen der Überwachung könnte erhöht werden, indem man einzelne Werte miteinander in Beziehung setzt, da ein Account, der außergewöhnlich viele E-Mails sendet, in großen Rauschen verloren gehen kann, aber wenn man gleichzeitig die Zahl der Authentifizierungsvorgänge und eventuell auch die Zahl der verschiedenen Ziel-Maildomänen in Relation setzte, hätte man schon einen ziemlich klaren Hinweis auf einen Sicherheitsvorfall. Für solche Anforderungen hat IBM auch einiges im Köcher. Auch dabei beraten wir gerne.

Tja...
Anfang der Woche schrieb ich bereits über eine bekannt gewordene Lücke in SSL/TLS nun folgt direkt die Nächste.

Diese nun LogJam genannte Lücke mit der CVE-ID "CVE-2015-4000" betrifft Server wie Clients gleichermaßen. Diese Lücke im DHE ermöglicht wohl einem "Man-In-The-Middle" eine Downgrade-Attack auf andere Verschlüsselungsstärken, so dass mitgeschnittener Netzwerkverkehr gelesen bzw. manipuliert werden kann.
Ich habe von IBM bisher keine offiziellen Statements gefunden, die eine Auskunft über die Betroffenheit der IBM-Produkte gibt. Wenn einer unserer Leser mehr weiß, ist er herzlich gebeten einen entsprechenden Kommentar zu hinterlassen .

Aber mehrere Dinge lassen sich sagen:
Domino kann vor 9.0.1 FP3 IF2 kein DHE. Ältere Domino-Versionen sind also deswegen schonmal nicht betroffen.

DHE muss in Domino 9.0.1 FP3 IF2 explizit eingestellt werden. In der Standardeinstellung ist Domino 9.0.1 FP3 IF2 also ebenfalls nicht betroffen.

Man kann seinen Server auf weakdhe.org auch testen lassen und erhält nebenbei auch Auskunft über die Verwundbarkeit seines Browsers . Darren Duke hat das einmal für einen seiner Domino-Server mit aktiviertem DHE getan und der Test bestätigt ihm keine Verwundbarkeit.
Wer sich nicht auf diese Webseite verlassen möchte oder Server testen möchte, die nicht im Web stehen, kann dies auch mit openssl tun.

Diese Aussagen ersetzen zwar m.E. kein offizielles Statement von IBM, lassen aber mit ausreichender Sicherheit vorläufig feststellen, dass
IBM Domino nicht von der LogJam-Lücke betroffen ist.