Die Einschläge kommen näher – das könnte man denken, wenn man sich in den Reihen einiger mittelständischer Unternehmen umhört – denn Hackerangriffe sind leider mittlerweile beinahe Alltag in Unternehmen. Das Aufrüsten von Maßnahmen, um Hackern die Möglichkeiten zu nehmen, irgendwie in das Unternehmensnetzwerk zu gelangen, ist ein absolutes Muss. Fahrlässig dann schon das Argument „uns wird das schon nicht treffen“.
Die Technologien ändern sich rasant. Neue Versionen von Hardware oder Software bedürfen in dem Bereich der Gefahrenabwehr einer permanenten Überwachung der mutmaßlichen sicherheitsrelevanten Bereiche. IBM hat im jüngsten Release 7.5 einige wichtige Neuerungen implementiert, mit denen der System i Betreiber in der Lage ist, sein System vor potentiellen Angriffen zu schützen. Einen Teilbereich – TSL – wollen wir in dieser Ausgabe behandeln.
TSL (Transport Socket Layer) ist der Nachfolger des SSL und dient der verschlüsselten Übertragung von Informationen über das Netzwerk. Und gerade die Datenübertragung bietet ungebetenen Gästen durchaus Optionen, an Informationen zu gelangen, mit deren Hilfe dann weitere ungewollte Schritte unternommen werden können. Ältere Verschlüsselungsoptionen waren in jüngster Vergangenheit leider auch im Spiel, wenn es um erfolgreiche Hackerangriffe auf Unternehmen ging. Insofern ist es durchaus sinnvoll, auch den Bereich der verschlüsselten Datenübertragung im Blick zu behalten.
Es macht die Sache dann nicht einfacher, wenn man sich um Wust der Dokumentationen dann mit verschiedenen TSL Versionen herumschlagen muss. Aber das ist dann leider auch bei unserem System i der Fall – denn in Abhängigkeit der eingesetzten Betriebssystemversion werden eben nur bestimmte TSL Versionen unterstützt. Einen Einblick dazu gibt die nachfolgende Tabelle:
IBM i Release | Unterstützte TSL Version |
6.1 | *TSLV1, *SSLV3 |
7.1 | *TSLV1, *SSLV3 |
7.2 | *TSLV1.1, *TSLV1.2, *TSLV1 |
7.3 | *TSLV1.1, *TSLV1.2, *TSLV1.3, *TSLV1 |
7.4 | *TSLV1.2, *TSLV1.3 |
7.5 | *TSLV1.2, *TSLV1.3 |
Der nachfolgende Hinweis stammt von den Webseiten der IBM:
„IBM empfiehlt dringend, dass Sie Ihren IBM i-Server immer mit den unten angegebenen Netzwerkprotokollen und Verschlüsselungssammlungen ausführen. ANMERKUNG: Wenn Sie Ihren IBM i-Server so konfigurieren, dass schwache Protokolle und schwache Verschlüsselungssammlungen zugelassen werden, besteht für Ihren IBM i-Server möglicherweise das Risiko einer Verletzung der Netzwerksicherheit.“
Dabei werden die SSL und älteren TSL Protokolle mittlerweile als schwache Stufe der Sicherheit aufgeführt:
- Transport Layer Security version 1.1 (TLSv1.1)
- Transport Layer Security version 1.0 (TLSv1.0)
- Secure Sockets Layer version 2.0 (SSLv2)
- Secure Sockets Layer version 3.0 (SSLv3)
Wenn Sie also eines der vier aufgelisteten Protokolle verwenden, dann prüfen Sie unbedingt, ob nicht der Ersatz der alten Protokolle gegen eines der neueren und als sichererer eingestuften Protokolle möglich ist.
Grundeinstellungen zu TSL auf System i nehmen wir anhand der nachfolgend gezeigten drei Systemwerte vor:
Mit Hilfe des Systemwertes QSSLCSL ((Secure Sockets Layer-Verschlüsselungsspezifikationsliste) wird festgelegt, welche Verschlüsselungsspezifikationsliste von System SSL unterstützt wird.
Dieser kann beispielsweise die folgenden Werte beinhalten:
Anmerkung: Der Initialwert der hier enthaltenen Werte wird von IBM bereitgestellt und kann je Release-/ PTF Stand variieren.
Der QSSLCSLCTL-Systemwert (Secure Sockets Layer-Verschlüsselungssteuerung) legt fest, ob das System oder der Benutzer den QSSLCSL-Systemwert (Secure Sockets Layer-Verschlüsselungsspezifikationsliste) steuert.
Der QSSLCSLCTL-Systemwert Sonderwert *OPSYS ermöglicht es dem Betriebssystem, die Verschlüsselungssammlungen zu ändern. Hat der Systemwert die Einstellung *USRDFN, dann ist der Administrator dafür verantwortlich, neuere Verschlüsselungsoptionen zu dem Systemwert QSSLCSL hinzuzufügen.
Generell gilt:
Passen Sie die TSL Vorgaben in Bezug auf die zu unterstützenden Versionen und Cipher Suites nur dann an, wenn Sie sicher sind, dass die von Ihnen eingetragenen Werte sicher sind und nicht etwas mögliche Sicherheitsrisiken darstellen! Wird in den Vorgaben nicht festgelegt, welche spezifische Verschlüsselungssammlungen anzuwenden ist, dann wird die in den Systemwerten hinterlegte System-SSL/TLS-Standard-Verschlüsselungssammlungsliste verwendet. Das hat den Vorteil, dass gegebenenfalls neue TSL Versionen ohne Änderungen eingesetzt und genutzt werden können. Die Reihenfolge der Standardliste der Verschlüsselungssammlung ist die Reihenfolge, in der die Verschlüsselungssammlungen im QSSLCSL-Systemwert angezeigt werden. Möchten Sie die Reihenfolge anpassen, dann genügt dazu eine Umsortierung der Einträge in dem Systemwert QSSLCSL.
IBM bietet den Systemwert QSSLPCL als Grundlage für die einzusetzen Protokolle an. Die QSSLPCL-Systemwerteinstellung identifiziert die spezifischen Protokolle, die auf dem System aktiviert sind. Anwendungen können sichere Sitzungen nur mit den Protokollen aushandeln, die in QSSLPCL aufgeführt sind. Um beispielsweise die System-SSL/TLS-Implementierung darauf zu beschränken, nur TLSv1.3 und TLSv1.2 zu verwenden und keine der älteren Protokollversionen zuzulassen, legen Sie QSSLPCL so fest, dass es nur *TLSV1.3 & *TLSV1.2 enthält. Der Sonderwert *OPSYS bedeutet, dass sowohl *TSLV1.2 als auch *TSLV1.3 unterstützt werden.
Um zusammen mit dem Betriebssystem 7.5 TSL anzupassen, sind die nachfolgenden Schritte auszuführen:
- Prüfen Sie die Stände der QSSL* Systemwerte und passen Sie diese gegebenfalls auf die neueren Versionen an.
- Führen Sie die TSL Konfiguration über DCM aus (DCM = Digital certificate manager). Diesen können Sie über den WebAdmin unter der folgenden URL erreichen: http://<server>:2001/QIBM/ICSS/Cert/Admin/qycucm1.ndm/main0
Und nun noch ein wenig Werbung für den neuen grafischen Administrationsclient für System i. Denn IBM hat diesen auch in dem Bereich DCM umgebaut und optimiert. Sollten Sie den neuen Webzugang nutzen, dann schaut der Zugang noch moderner so aus:
Als erstes müssen wir für den Neueinsatz von TSL einen Zertifikatsspeicher *SYSTEM anlegen (wenn es diesen nicht bereits auf dem System gibt). Dieser *SYSTEM Speicher wird über ein Kennwort geschützt, welches nun einzugeben ist:
Das Kennwort muss hier 2-fach eingegeben werden. Nach einem Klick auf „Create“ wird der Systembereich nun angelegt.
In diesem Bereich können wir nun die verschiedenen Zertifikate erstellen und verwalten:
Dabei können wir selbst Zertifikate erstellen aber auch Zertifikate von externen Stellen importieren. Um den aktuellen Wert der Liste des zulässigen Standardprotokolls und der Verschlüsselungssammlung sowie der Liste des Standardprotokolls und der Verschlüsselungssammlung auf dem System einzusehen, können wir SST nutzen und dort die TLSCONFIG-Option “–display” einsetzen:
- Dazu starten wir SST mit dem Befehl STRSST und melden uns dort an.
- Nun wählen wir die Option 1 (Start a service tool)
In der nächsten Anzeige wählen wir die Option 4 (Display/Alter/Dump).
…gefolgt von der Auswahl 1 (Display / Alter storage):
Wählen Sie die Option 2(licensed interal code data):
Nun blättern und / oder Option 14 (Advanced analysis) eingeben:
Nun den Eintrag TSLCONFIG suchen und mit der Option 1 selektieren:
Hier liefern die Einträge in den Bereichen “-display”, “-eligibleDefaultProtocols”, und “-eligibleDefaultCipherSuites” die gewünschten Informationen. Damit sind die ersten Schritte der TSL Einrichtung abgeschlossen und Zertifikate können für die sichere Kommunikation eingesetzt werden. Soweit zu den ersten Schritten rund um TSL und System i.
Eines noch:
Nutzen Sie 5250 Anwendungen? Wenn ja, dann schauen Sie doch einmal nach, ob diese verschlüsselt sind. Die Eigenschaften des ACS geben hierzu in einem eigenen Bereich SSL/TSL Auskunft:
Nicht verschlüsselte Datenübertragungen (auch mit old fashioned 5250 Greenscreenanwendungen) können Tore öffnen…
Jörg Zeig berät freiberuflich im System i Umfeld.
Er berichtet für den TechKnowLetter. Für 88 Euro gibt’s hier sechs Monate lang tiefgreifendes IBM i und SQL Wissen. Hier kann man abonnieren.