Marcus Danner 07. September 2021

Härtung von IBM-WebSphere-Applikationsservern

Eine Gefährdung entsteht, wenn eine Bedrohung auf eine Schwachstelle trifft. © Adobe: Fxquadro / stock.adobe.com / 286336952 — © Adobe: Fxquadro

Applikationsserver sind in heute etablierten IT-Infrastrukturen wichtige Komponenten für den Betrieb von Webanwendungen. Sie dienen dem Betrieb von unternehmenskritischen IT-Applikationen sowohl für interne Prozesse eines Unternehmens als auch für die Vermarktung von Produkten und Dienstleistungen des Unternehmens oder die Bereitstellung von Dienstleistungen öffentlicher Institutionen für die Allgemeinheit.

Der sichere Betrieb von Applikationsservern ist für all diese Organisationen von existenzieller Bedeutung. IT-Sicherheitsverantwortliche müssen daher bestrebt sein, die Applikationsserver ihrer Organisation stets auf einem einheitlichen, hohen und der aktuellen Bedrohungslage angemessenen Sicherheitsstandard zu betreiben. Dieser Artikel zeigt auf, wie etablierte Sicherheitsstandards für Applikationsserver durchgehend automatisiert angewandt werden können.

Bewertung von Bedrohungen und Gefährdungen

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt im IT-Grundschutz-Kompendium wesentliche Gefährdungen und Bedrohungen für IT-Applikationen zusammen und adressiert im Baustein APP.3.1: Webanwendungen insbesondere die Anforderungen an Webapplikationen und Applikationsserver [1]. Nach der Begriffsdefinition des BSI entsteht eine Gefährdung, wenn eine Bedrohung auf eine Schwachstelle trifft.

Zunächst wird ein Katalog von Bedrohungen spezifiziert, die für die zu härtende Applikationsserverlandschaft tatsächlich relevant sind. Hierbei wird berücksichtigt, dass flankierende Maßnahmen wie beispielsweise grundlegende Firewalls und Web Application Firewalls bereits einige Bedrohungen abfangen können, die somit für die Applikationsserverlandschaft keine tatsächliche Gefährdung mehr darstellen. Beispielsweise kann das Einspielen von Nachrichten (G 0.43 der elementaren Gefährdungen nach IT-Grundschutz) aus unzuverlässiger Quelle bereits durch flankierende Firewalls unterbunden sein.

Auch organisatorisch müssen unterschiedliche Disziplinen, die bei der Absicherung der Systemlandschaft zusammenwirken, voneinander abgegrenzt werden, um klare und eindeutige Verantwortlichkeiten zu schaffen. Häufig wird das Patch-Management, also die regelmäßige Aktualisierung aller eingesetzten Hard- und Softwarekomponenten gemäß der jeweiligen Hersteller- oder Lieferantenempfehlungen, als eigene Disziplin betrachtet. Ist dies gegeben, fallen die entsprechenden Tätigkeiten und Verantwortlichkeiten nicht mehr unter die Disziplin der Systemhärtung im engeren Sinne.

Auswahl eines Härtungsframeworks

Nachdem die durch die Systemhärtung zu betrachtenden Bedrohungen abgegrenzt wurden, müssen Maßnahmen definiert werden, um potenzielle Schwachstellen, auf die diese Bedrohungen treffen können, zu identifizieren und zu beheben. Dabei sollte möglichst auf etablierte standardisierte Härtungsframeworks zurückgegriffen werden. Beispielsweise definiert das National Institute of Standards and Technology (NIST) konkrete technologie- und produktspezifische Kataloge für die Härtung von Applikationsservern [2]. Für den hier beispielhaft betrachteten IBM WebSphere Application Server stellt das NIST den IBM WebSphere Traditional V9.x Security Technical Implementation Guide (STIG) in der Version 1, Release 1 vom 23. August 2018 zur Verfügung [3].

Das ausgewählte Standardframework muss gegebenenfalls kombiniert werden mit spezifischen internen Anforderungen der Organisation, die die Applikationsserverlandschaft härten sollen. Ebenso müssen unter Umständen branchenspezifische Vorgaben von Aufsichtsbehörden mit einbezogen werden. Außerdem sollten Hinweise und Empfehlungen der Hersteller und Zulieferer der Softwarekomponenten aus der gängigen Praxis berücksichtigt werden.

Einrichtung eines Automatisierungszyklus

Die Härtung einer Applikationsserverlandschaft zielt darauf ab, den identifizierten Bedrohungen durch geeignete Konfigurationseinstellungen auf Applikationsserverebene zu begegnen. Da durch Updates der Softwarekomponenten, Installation von neuen Webapplikationen und andere Entwicklungs- und Wartungsarbeiten die Systemkonfiguration potenziell jederzeit verändert werden könnte, ist es für die Systemhärtung essentiell, einen automatisierten Prozess zu etablieren, der aktuell bestehende Konfigurationseinstellungen mit den durch das Härtungsframework vorgegebenen Konfigurationseinstellungen abgleicht und im Regelfall die vorgegebenen Konfigurationseinstellungen automatisch wiederherstellt.

Eines der am weitesten verbreiteten Frameworks für diesen Zweck ist Red Hat Ansible [4]. Der Vorteil von Ansible gegenüber anderen Frameworks wie beispielsweise Puppet besteht darin, dass Ansible keine eigenen Softwarekomponenten auf den zu härtenden Systemen benötigt, sondern konsequent nach dem Push-Prinzip servergestützt zentrale Konfigurationseinstellungen auf die im Ansible Inventory registrierten Zielsysteme anwendet.

Implementierung einer einheitlichen Konfiguration für alle Serverinstanzen

Für den hier beispielhaft betrachteten IBM WebSphere Application Server besteht die spezielle Herausforderung, dass es derzeit keine Out-of-the-Box-Automatisierungslösung für die Systemkonfiguration gibt, da das Konfigurationskonzept mit unterschiedlichen Instanzen wie Deployment-Managern, Cells und Nodes komplexer ist als für andere Application Server. Stattdessen kann IBM WebSphere administrative scripting genutzt werden, um aktuell aktive Konfigurationseinstellungen (Ist-Werte) auf den Application Servern zu ermitteln und die im Härtungsframework definierten Soll-Werte anzuwenden [5].

Idealerweise wird zu jedem Deployment-Manager auf einem separaten Management Server der IBM WebSphere Application Server Administration Thin Client installiert [6]. Im Ansible Inventory werden diese Management Server registriert. Von den Management Servern wird eine Verbindung zum jeweiligen Deployment-Manager aufgebaut. Der Deployment-Manager führt dann für von ihm verwaltete Nodes und Applikationen Härtungsskripte aus. Die Härtungsskripte werden in jython implementiert und verwenden die entsprechenden Jython 2.7 API-Objekte des IBM WebSphere Administrative Scripting.

Die Härtungsskripte sollten generisch gehalten werden und nicht selbst die Konfigurationseinstellungen enthalten. Somit können spezifische Einstellungen einzelner Nodes oder Applikationen berücksichtigt werden. Beispielsweise kann das Regelwerk für die Prüfskripte in deskriptiver Form im JSON-Format bereitgestellt werden. Erstellt man für jede Klasse von zu prüfenden Konfigurationsobjekten einen Eintrag in der Definition mit einem Bezeichner als Schlüssel der obersten Ebene und darunter einer Liste von Regeln, die auf Konfigurationseinstellungen dieses Typs angewendet werden sollen, so erhält man ein flexibel konfigurierbares gut automatisch ausführbares Regelwerk. Im folgenden Beispiel ist die Definition einer Regel für Ciphers dargestellt.

{
  "Cipher":
  [
    {
      "rule": "SV-96105",
      "subType": "ExportCipher",
      "attribute": "name",
      "isAcl": false,
      "expected": "None",
      "checker":
      {
        "type": "RegExChecker",
        "modifiers":
        {
          "regex": ".* EXPORT_.*",
          "modus": false
        }
      }
    }
  }
}

Die vordefinierten Konfigurationseinstellungen sowie die Skripte zu deren Überprüfung sind Quellcode, der kontinuierlich weiterentwickelt wird und daher in einer Quellcodeverwaltung versioniert werden sollte.

Monitoring von Abweichungen von den definierten Standards

Neben der regelmäßigen automatisierten Prüfung und Anwendung der Konfigurationseinstellungen ist es genauso wichtig, auftretende Abweichungen vom Soll-Zustand zu registrieren. Es bietet sich an, die von den Härtungsskripten entdeckten Abweichungen als Security Incidents zu betrachten und in ein bestehendes Security Incident and Event Management (SIEM) einzubinden. Als Werkzeug im SIEM hat sich insbesondere Splunk etabliert [7].

Die Härtungsskripte sollten Soll/Ist-Abweichungen direkt an Splunk melden. Splunk stellt mehrere Möglichkeiten zur Verfügung, wie es diese Informationen empfangen kann, unter anderem

die Verwendung eines zentralen Syslog-Service, der syslog-Meldungen aus unterschiedlichen Quellen sammelt und an Splunk weitermeldet oder
die Verwendung eines HTTP Event Collector in Splunk.

Da die Härtungsskripte als Jython-Skripte ausgeführt werden und es in Jython eine standardmäßige Unterstützung für syslog-Meldungen gibt, bietet sich diese Alternative als einfache Lösung an.

Splunk definiert das Splunk Common Information Model [8]. Da es sich bei den Findings aus den Hardening-Prüfskripten um Abweichungen von der Sollkonfiguration handelt und demnach eine Änderung gegenüber dem Ausgangszustand vorliegen muss, sollten die Findings aus den Hardening-Prüfskripten dem Change-Datenmodell zugeordnet werden [9]. Beispielhaft würde Splunk das Finding eines unerwünschten Export-Levels-Ciphers somit folgendermaßen darstellen:

Abb. 1: Finding eines unerwünschten Export-Levels-Ciphers. © adesso

Architekturbild des Härtungssystems

Zusammengefasst ergibt sich für das Härtungssystem für die Application Server somit das folgende Architekturbild:

Abb. 2: Architekturbildfür das Härtungssystem für die Application Server. © Marcus Danner

Konfigurationseinstellungen und Skripte werden als "Infrastructure as Code" in einem GIT-Repository verwaltet. Ansible greift direkt auf das Repository zu und steuert die Ausführung der Skripte per Remote Shell auf den Management-Servern als Zielsysteme, die wiederum die Deployment-Manager aufrufen, um die einzelnen Nodes und Cells der Application Server zu konfigurieren.

Quellen