Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers

Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers

Konfiguration und Tests

Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 (0) 1888 9582 0 E-Mail: [email protected] Internet: http://www.bsi.bund.de © Bundesamt für Sicherheit in der Informationstechnik 2006

Bundesamt für Sicherheit in der Informationstechnik Seite 2 (von 187)

Sicherheitsuntersuchung des ApacheJakarta Tomcat Servlet Containers

Inhaltsverzeichnis

Inhaltsverzeichnis

1. EINLEITUNG........................................................................................................... 9

2. INSTALLATION DER DEBIAN 3.1 SARGE BASISPLATTFORM........................11

2.1 Vorbereitung einer virtuellen Maschine....................................................................................................... 12

2.2 Installation von Debian 3.1 Sarge in der virtuellen Maschine....................................................................23

2.3 Installation der zu testenden Anwendungen................................................................................................ 28

2.4 Replikation von virtuellen Maschinen.......................................................................................................... 29

3. INSTALLATION DER SOFTWAREKOMPONENTEN.......................................... 31

3.1 Java Software Design Kit (SDK, Version 1.5.0_05).....................................................................................32

3.2 Apache Webserver (Version 2.0.54).............................................................................................................. 33

3.3 Jakarta Tomcat Servlet Container (Version 5.5.9)......................................................................................35

3.4 Jakarta Tomcat Connector Modul mod_jk (Version 1.2.14)..................................................................... 393.4.1 Apache-Konfigurationsdatei httpd.conf.................................................................................................... 403.4.2 Tomcat Konfigurationsdatei server.xml.................................................................................................... 413.4.3 Apache-Konfigurationsdatei workers.properties.......................................................................................43

3.5 Installation des MySQL-Connectors/J..........................................................................................................45

3.6 Installationen für die JNDI-Konnektivität................................................................................................... 46

3.7 Installation der Logging-Komponenten........................................................................................................46

3.8 Einrichtung des lokalen DNS-Servers...........................................................................................................47

3.9 Werkzeuge für Penetrationstests...................................................................................................................513.9.1 SPIKE........................................................................................................................................................ 513.9.2 Benutzung von SPIKE...............................................................................................................................513.9.3 Ethereal...................................................................................................................................................... 543.9.4 OpenSSL....................................................................................................................................................54

3.10 Werkzeuge für statische Tests..................................................................................................................... 553.10.1 Flawfinder und Splint für C.....................................................................................................................553.10.2 Findbugs für Java.....................................................................................................................................573.10.3 Java-Dokumentation................................................................................................................................ 60

Seite 3 (von 187) Bundesamt für Sicherheit in der Informationstechnik

Inhaltsverzeichnis Sicherheitsuntersuchung des ApacheJakarta Tomcat Servlet Containers

4. EINRICHTUNG DER AUTHENTISIERUNGSINFORMATIONEN..........................61

4.1 Einrichtung von Test-Benutzerkonten auf Betriebssystemebene...............................................................61

4.2 Einrichtung von Test-Benutzerkonten für die Web-Authentisierung....................................................... 61

4.3 Initialisierung der tomcat_users.xml Datei.................................................................................................. 62

4.4 Initialisierung der MySQL-Datenbank mit den Authentisierungsinformationen....................................63

4.5 Initialisierung der LDAP-Datenbank mit den Authentisierungsinformationen.......................................64

4.6 Konfiguration des LDAP-Browsers gq......................................................................................................... 68

4.7 Erzeugung einer CA und Generierung von SSL-Server- und Client-Zertifikaten.................................. 714.7.1 Installation einer Certification Authority (CA)......................................................................................... 714.7.2 Erzeugung eines SSL Server-Zertifikats (Tomcat)................................................................................... 734.7.3 Erzeugung eines SSL Server-Zertifikats (Apache)................................................................................... 764.7.4 Erzeugung von Client-Zertifikaten............................................................................................................78

5. DURCHFÜHRUNG DER TESTS........................................................................... 84

5.1 Funktionale Tests der Sicherheitsfunktionen von Tomcat......................................................................... 845.1.1 Funktionale Tests für die Authentisierung................................................................................................ 84

5.1.1.1 Ergebnisse zu Test1............................................................................................................................865.1.1.1.1 T1: HTTP Connector, BASIC-Authentisierung, Memory Realm.............................................. 875.1.1.1.2 T2: HTTP Connector, BASIC-Authentisierung, JDBC Realm..................................................885.1.1.1.3 T3: HTTP Connector, BASIC-Authentisierung, JNDI Realm................................................... 885.1.1.1.4 T4: HTTP Connector, DIGEST-Authentisierung, Memory Realm............................................895.1.1.1.5 T5.1: HTTP Connector, FORM-Authentisierung, Memory Realm........................................... 895.1.1.1.6 T5.2: HTTP Connector, FORM-Authentisierung, JDBC Realm............................................... 905.1.1.1.7 T5.3: HTTP Connector, FORM-Authentisierung, JNDI Realm................................................ 915.1.1.1.8 T6: HTTPS Connector, Client Zertifikat Authentisierung, Memory Realm.............................. 915.1.1.1.9 T7: AJP1.3 Connector, BASIC-Authentisierung, Memory Realm............................................ 925.1.1.1.10 T8: AJP1.3 Connector, DIGEST-Authentisierung, Memory Realm........................................925.1.1.1.11 T9: AJP1.3 Connector, FORM-Authentisierung, Memory Realm...........................................935.1.1.1.12 T10: AJP1.3 / SSL Connector, Client Zertifikat Authentisierung, Memory Realm................ 93

5.1.1.2 Ergebnisse zu Test2............................................................................................................................935.1.1.2.1 T11: HTTP Connector, BASIC-Authentisierung, Memory Realm............................................ 935.1.1.2.2 T12: HTTP Connector, DIGEST-Authentisierung, Memory Realm..........................................945.1.1.2.3 T13.1: HTTP Connector, FORM-Authentisierung, Memory Realm......................................... 945.1.1.2.4 T13.2: HTTP Connector, gemischte BASIC- und FORM-Authentisierung, Memory Realm... 965.1.1.2.5 T14: HTTPS Connector, Client Zertifikat Authentisierung, Memory Realm............................ 975.1.1.2.6 T15: AJP1.3 Connector, BASIC-Authentisierung, Memory Realm........................................ 1005.1.1.2.7 T16: AJP1.3 Connector, DIGEST-Authentisierung, Memory Realm......................................1005.1.1.2.8 T17.1: AJP1.3 Connector, FORM-Authentisierung, Memory Realm......................................1005.1.1.2.9 T17.2: AJP Connector, gemischte BASIC- und FORM-Authentisierung, Memory Realm.... 1005.1.1.2.10 T18: AJP1.3 / SSL Connector, Client Zertifikat Authentisierung, Memory Realm.............. 100

5.1.1.3 Ergebnisse zu Test3..........................................................................................................................1015.1.1.3.1 T19.1: HTTP Connector, BASIC-Authentisierung, Memory Realm.......................................1015.1.1.3.2 T19.2: HTTP Connector, BASIC-Authentisierung, JDBC Realm...........................................1015.1.1.3.3 T19.3: HTTP Connector, BASIC-Authentisierung, JNDI Realm............................................ 102



Inhaltsverzeichnis

5.1.1.3.4 T20: HTTP Connector, DIGEST-Authentisierung, Memory Realm........................................1025.1.1.3.5 T21: HTTP Connector, FORM-Authentisierung, Memory Realm.......................................... 1025.1.1.3.6 T22: HTTPS Connector, Client Zertifikat Authentisierung, Memory Realm.......................... 1035.1.1.3.7 T23.1: AJP1.3 Connector, BASIC-Authentisierung, Memory Realm..................................... 1035.1.1.3.8 T23.2: AJP1.3 Connector, BASIC-Authentisierung, JDBC Realm......................................... 1045.1.1.3.9 T23.3: AJP1.3 Connector, BASIC-Authentisierung, JNDI Realm.......................................... 1045.1.1.3.10 T24: AJP1.3 Connector, DIGEST-Authentisierung, Memory Realm....................................1045.1.1.3.11 T25: AJP1.3 Connector, FORM-Authentisierung, Memory Realm.......................................1055.1.1.3.12 T26: AJP1.3 / SSL Connector, Client Zertifikat Authentisierung, Memory Realm.............. 105

5.1.2 Funktionale Tests für die Zugriffskontrolle ........................................................................................... 1065.1.2.1 Tests der Zugriffsrechte auf dem Niveau der Java Virtual Machine............................................... 106

5.1.2.1.1 T27 Tomcat beenden................................................................................................................ 1075.1.2.1.2 T28 neuen Prozess starten.........................................................................................................1085.1.2.1.3 T29 Netzwerk-Socket öffnen und Daten übertragen................................................................1095.1.2.1.4 T30.1 Lesen innerhalb des Bereichs der Web-Anwendung..................................................... 1095.1.2.1.5 T30.2 Schreiben innerhalb des Bereichs der Web-Anwendung...............................................1105.1.2.1.6 T30.3 Löschen innerhalb des Bereichs der Web-Anwendung................................................. 1115.1.2.1.7 T30.4 Ausführen innerhalb des Bereichs der Web-Anwendung..............................................1125.1.2.1.8 T31 Lesen / Schreiben / Löschen / Ausführen außerhalb der Web-Anwendung.....................1125.1.2.1.9 T32 Zugriff auf Tomcat-eigene Komponenten.........................................................................113

5.1.2.2 Tests der Zugriffsrechte auf dem Niveau von Webanwendungen...................................................1145.1.2.2.1 T33.1 HTTP Connector, Zugriff auf eine geschützte JSP-Seite...............................................1155.1.2.2.2 T33.2 AJP13 Connector, Zugriff auf eine geschützte JSP-Seite..............................................1165.1.2.2.3 T34.1 HTTP Connector, Zugriff auf ein geschütztes Verzeichnis ..........................................1165.1.2.2.4 T34.2 AJP13 Connector, Zugriff auf ein geschütztes Verzeichnis ......................................... 1165.1.2.2.5 T35 Schutz einzelner HTTP-Methoden vor anonymen Zugriffen........................................... 116

5.1.2.3 Tests der Zugriffsrechte auf dem Niveau von Valves......................................................................1195.1.2.3.1 T36.1 HTTP Connector, verbotene Anfragen mit IP-Adresse des Clients.............................. 1215.1.2.3.2 T36.2 AJP13 Connector, verbotene Anfragen mit IP-Adresse des Clients..............................1215.1.2.3.3 T37 Erlaubte Anfragen mit IP-Adresse des Clients................................................................. 1225.1.2.3.4 T37.1 HTTP Connector, erlaubte Anfragen mit IP-Adresse des Clients................................. 1225.1.2.3.5 T37.2 AJP13 Connector, erlaubte Anfragen mit IP-Adresse des Clients.................................1235.1.2.3.6 T38 / T 39 HTTP bzw. AJP13 Connector, verbotene / erlaubte Anfragen mit Hostname des Clients...................................................................................................................................................... 123

5.1.2.4 Protokollierung.................................................................................................................................1275.1.2.4.1 T40 Kontrolle der Log-Datei für eine <Logger>-Komponente............................................... 1285.1.2.4.2 T41 Protokollierung mit Access Log Valve............................................................................. 129

5.1.2.5 Zuverlässigkeit der Dienstleistung...................................................................................................1295.1.2.5.1 T42 Failover beim Ausfall einer Tomcat-Instanz.....................................................................1305.1.2.5.2 T43 Persistente Sessions beim Herunterfahren........................................................................ 131

5.1.2.6 Verschlüsselung............................................................................................................................... 1325.1.2.6.1 T44 SSL mit Null-Cipher......................................................................................................... 1325.1.2.6.2 T45 SSL mit schwacher Verschlüsselung................................................................................ 1335.1.2.6.3 T46 SSLv2, SSLv3 oder TLS...................................................................................................133

5.1.2.7 Datenschutz...................................................................................................................................... 1365.1.2.7.1 T47 / T48 Datenschutz-bezogene Analyse der Ergebnisse aus Tests T40 und T41................ 136

5.1.2.8 Minimale Rechtevergabe..................................................................................................................1375.1.2.8.1 T49 Ausführung von Tomcat als nicht-privilegierter Benutzer............................................... 138

5.2 Penetrationstests - Vorgehensweise.............................................................................................................1385.2.1 Angriffsszenarien.....................................................................................................................................1385.2.2 Beispielanwendungen..............................................................................................................................139



5.3 HTTP-Connector: Angriffe von einem HTTP-Client............................................................................... 140

5.4 AJP-Connector ohne SSL-Client-Authentisierung....................................................................................1415.4.1 Angriffe eines maliziösen HTTP-Clients................................................................................................ 141

5.4.1.1 Vorgehensweise............................................................................................................................... 1415.4.1.2 Bewertungskriterien......................................................................................................................... 1435.4.1.3 Ergebnis............................................................................................................................................143

5.4.2 Angriffe einer maliziösen Web-Anwendung...........................................................................................1485.4.2.1 Vorgehensweise............................................................................................................................... 1485.4.2.2 Bewertungskriterien......................................................................................................................... 1515.4.2.3 Ergebnis............................................................................................................................................152

5.5 AJP Connector mit SSL Client Authentisierung....................................................................................... 1525.5.1 Funktionsweise des Systems....................................................................................................................1535.5.2 Angriffe....................................................................................................................................................158

5.5.2.1 Testfälle............................................................................................................................................ 1585.5.2.2 Vorgehensweise............................................................................................................................... 1595.5.2.3 Bewertungskriterien......................................................................................................................... 1605.5.2.4 Ergebnis............................................................................................................................................161

5.6 Quellcode-Analysen.......................................................................................................................................1635.6.1 Automatische Überprüfung des Quellcodes............................................................................................1635.6.2 Manuelle Überprüfung des Quellcodes................................................................................................... 1645.6.3 Umfang der Quellcode-Analyse.............................................................................................................. 167

5.6.3.1.1 T91/T94 Automatische und manuelle Prüfung des Quellcode.................................................1685.6.3.1.2 T92 Manuelle Sichtung der Schnittstelle zu JSSE (SSL).........................................................1725.6.3.1.3 T93 Manuelle Sichtung der Authentisierungsmethoden.......................................................... 173

6. EMPFEHLUNGEN UND MASSNAHMEN........................................................... 176

6.1 Allgemeine Maßnahmen bzw. Maßnahmen auf Betriebssystemebene....................................................1766.1.1 Dateiberechtigungen und -zuordnung..................................................................................................... 1766.1.2 Passworte für die Benutzer / Webanwendung.........................................................................................1776.1.3 Passwort des JAVA Zertifikatspeichers.................................................................................................. 1776.1.4 Host-basierte Firewall (netfilter / iptables)..............................................................................................1786.1.5 Gesicherte Kommunikation..................................................................................................................... 1786.1.6 Eingeschränkte Laufzeitumgebung (chroot)........................................................................................... 1796.1.7 Nutzung von erweiterten Zugriffsschutzmechanismen unter SELinux...................................................179

6.2 Maßnahmen beim Apache Webserver.......................................................................................................1796.2.1 Zugriffsberechtigungen........................................................................................................................... 1806.2.2 Watchdog-Funktionalität......................................................................................................................... 180

6.3 Maßnahmen beim Jakarta Tomcat Servlet Container............................................................................. 1806.3.1 Installation unter einem Tomcat Benutzer...............................................................................................1806.3.2 Shutdown-Port......................................................................................................................................... 1816.3.3 Logging....................................................................................................................................................1816.3.4 Manager und Admin Webanwendungen................................................................................................. 1826.3.5 Zugriffsbeschränkungen.......................................................................................................................... 1836.3.6 Tests der Konfiguration........................................................................................................................... 1836.3.7 Verschlüsselte Verbindung (SSL)........................................................................................................... 1846.3.8 Anbindung einer Datenbank per JDBC...................................................................................................185



Inhaltsverzeichnis

6.3.9 Anbindung einer Datenbank per JNDI.................................................................................................... 1856.3.10 Single-Sign-On...................................................................................................................................... 185

7. WEITERE PUNKTE / BUGS / VERBESSERUNGSMÖGLICHKEITEN.............. 186

8. ABKÜRZUNGEN................................................................................................. 187

9. WICHTIGE SHELL-VARIABLEN, VERZEICHNISSE UND DATEIEN................ 188

10. REFERENZEN................................................................................................... 189

10.1 Web-Referenzen (Stand 30.11.2005)......................................................................................................... 189





Einleitung

1. Einleitung

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat eine Sicherheitsuntersuchung des Open Source Jakarta Tomcat durchführen lassen. Diese Untersuchung teilt sich in mehrere Projektphasen auf. Dieses Dokument beschreibt die durchgeführten Tests und Analysen sowie die Installation des dazugehörigen Testsystems.

Die durchzuführenden Tests wurden in einer früheren Projektphase im Dokument „Feinkonzept zur Sicherheitsuntersuchung des Apache Tomcat Servlet Containers“ festgelegt. Dieses frühere Dokument wird im weiteren unter [Tomcat Fein.] referiert. Es ist für das Verständnis des jetzigen Dokuments nicht erforderlich, da die Beschreibung der Testfälle 1:1 übernommen wurde, aber dennoch eine empfehlenswerte Lektüre.

Der Umfang des Dokuments liegt begründet in dem Streben nach:

1. Nachvollziehbarkeit und Reproduzierbarkeit der Testergebnisse und

2. Rückverfolgbarkeit der Testergebnisse zu den Testbeschreibungen des Feinkonzepts.

Dieses Dokument stellt im ersten Schritt die Vorgehensweise bei der VMware-basierten Installation eines Debian 3.1 Sarge Linux Betriebssystems (basierend auf der Debian 3.1 Linuxtag 2005 Edition Installations-DVD) zum Zweck der Sicherheitsuntersuchung von Tomcat zusammen.

Im zweiten Schritt wird die Installation und Konfiguration

• des Webservers Apache (Version 2.0.54)

• des Servlet-Containers1 Tomcat (Version 5.5.9)

• des Connectors mod_jk (Version 1.2.14.1)

sowie die Durchführung der damit durchgeführten und [Tomcat Fein.] zusammengestellten Tests beschrieben.

Abschließend werden Empfehlungen für die sichere Konfiguration zum Betrieb von Tomcat gegeben.

In diesem Dokument verwendete Notation

Dieses Dokument verwendet die folgende Regeln zur Darstellung und Hervorhebung:

• Hinweis: die Zeichenvorlage Hinweis kommt am Anfang von Absätzen zum Einsatz, die als ganzes hervorzuheben sind. Der optische Effekt bleibt somit minimal.

1 Ein Servlet Container dient als Laufzeitumgebung für Java Servlets [Sun Servlets] bzw. Java Server Pages [Sun JSP]. Der Container ist die Schnittstelle zwischen den Webserver und den Servlets, die sich in dem Container befinden. Der Container lädt, initialisiert und führt die Servlets aus. Der Container ordnet einer ankommenden Anfrage einem Servlet zu und leitet diese Anfrage an das Servlet weiter. Das Servlet bearbeitet die Anfrage, ggf. unter Einbeziehung weiterer Hintergrundapplikationen, und erzeugt eine Antwort. Der Container leitet diese Antwort an den Webserver weiter, der sie dann an den Web-Client (z. B. Browser) übermittelt.


Einleitung Sicherheitsuntersuchung des ApacheJakarta Tomcat Servlet Containers

• Dateinamen, Konfigurationsvariablen, Kommandos, Programm-generierte Ausgaben im Fließtext werden in der Zeichenvorlage Code dargestellt (in der Praxis oft als Fixed-Width Font [z. B. Courier], hier Kursiv)2

• Listing 1: Als Überschrift oder zur Namensgebung für längere Abschnitte aus Scripts bzw. Konfigurationsdateien. Tabellen und Abbildungen werden dagegen unterhalb der Tabelle bzw. Abbildung beschriftet.

Für ganze Scripts wird die Absatzvorlage Code eingesetzt (auch möglichst als Fixed-Width Font, z. B. Courier). Die kleinerere Schriftgröße wird zur Vermeidung von automatischen Zeilenumbrüchen bei den z. T. sehr langen Zeilen verwendet.

• Zwischenüberschriften werden durch Fettdruck und vertikalen Abstand vom umgebenden Text getrennt, aber im Gegensatz zu Überschriften nicht nummeriert.

• Literaturverweise auf das Literaturverzeichnis in Abschnitt 10 am Ende des Dokuments werden in eckigen Klammern angegeben, z. B. als [Tomcat Fein.]. Davor befindet sich in Abschnitt 8 ein Abkürzungsverzeichnis.

• URLs auf Webseiten im Internet werden in der Fußnoten angegeben. Der Fließtext bleibt lesbar.

• Lange Datei- bzw. Verzeichnisnamen werden teilweise in Fußnoten verlegt, wobei der Fließtext eine eindeutige Kurzform enthält – meist ohne Verzeichnis. Gegen Ende dieses Dokuments findet der Leser eine Zusammenstellung einiger stets wiederkehrender Shellvariablen, Dateinamen und dazugehörige Verzeichnisse.

• URLs auf Webseiten / -Applikationen innerhalb der Testumgebung werden mit der Zeichenvorlage URL Intern formatiert. Diese sind nur bei aufgebauter Testumgebung nutzbar.

Hinweis: derzeit werden die Formatvorlagen Code / URL Intern farbig hinterlegt, um die Stellen des Auftretens entsprechenden Textes leicht zu identifizieren, bis sich ein möglichst vielen Lesern gefälliges Format herauskristallisiert.

2 Treten derartige Texte in Fußnoten auf, so wird die Zeichenvorlage Fußnote_Code verwendet.



Installation der Debian 3.1 Sarge Basisplattform

2. Installation der Debian 3.1 Sarge Basisplattform

Um eine flexible Testumgebung zu erhalten, werden sämtliche Installationen in virtuellen Maschinen vorgenommen. Zur Schaffung einer einheitlichen Arbeitsplattform wird zunächst ein Prototyp der virtuellen Maschine erstellt, der dann bei Bedarf repliziert werden kann. Zum Einsatz kommt ein VMware GSX Server3 Version 3.1.0 Build 9089 auf einer Novell-SuSE4

Professional Linux 9.3 Host-Plattform (Rechner bigmama) zur Realisierung der virtuellen Maschinen, die selbst auf dem Debian5 3.1 Sarge Linux Betriebssystem aufsetzen.

Eine Übersicht über das gesamte Testsystem gibt die folgende Abbildung:

Das VMware-Hostsystem (bigmama) beherbergt die virtuellen Maschinen. Das Aufsetzen der virtuellen Maschine template wird im folgenden Abschnitt beschrieben. Sie dient als Referenzplattform und Ausgangspunkt zur Erzeugung weiterer virtueller Maschinen durch

3 http://www.vmware.com 4 http://www.novell.com/de-de/products/linuxprofessional/ 5 http://www.debian.org


bigmama (VMware Host)template(virtuelle Maschine) tomcathost(virtuelle Maschine)virtueller RouterDomain: external.deDomain: bsitomcat.de192.168.118.101/26192.168.118.100/26192.168.118.1/26 Firewall /Internet

Tomcat, ApacheDNS, LDAP, MySQLWebbrowserWebbrowser(+ Basisinstallation)

Webbrowser

Abbildung 2.1: Architektur des Testsystems

http://www.vmware.com/

http://www.debian.org/

http://www.novell.com/de-de/products/linuxprofessional/

Installation der Debian 3.1 Sarge Basisplattform Sicherheitsuntersuchung des ApacheJakarta Tomcat Servlet Containers

Replikation. Die Konfigurationen und Tests werden anschließend auf der so erzeugten Systemkopie tomcathost durchgeführt.

2.1 Vorbereitung einer virtuellen Maschine

Nach dem Login auf dem VMware Server (bigmama) wird die VMware Virtual Console in einem Konsolenfenster mit dem Kommando vmware geöffnet.

Abbildung 2.2: VMware Virtual Machine Console

Um später eine Textkonsolenumschaltung der in den virtuellen Maschinen laufenden Linux-Systemen zu ermöglichen (per Ctrl-Alt-Fn)6, wird der VMware Hot-Key von Ctrl-Alt auf Shift-Ctrl-Alt umgestellt (Menü Edit → Preferences, Reiter Hot-Keys) und VMware anschließend beendet und neu gestartet.

6 Fn entspricht einer der Funktionstasten F1 ... F6 auf der Tastatur, über Ctrl-Alt-F7 wird auf die grafische X Window Benutzeroberfläche umgeschaltet.




Abbildung 2.3.: Änderung des VMware Hot-Keys

Über den Eintrag „New Virtual Machine“ wird zunächst eine Debian 3.1 Sarge Basisplattform erzeugt, die durch Replikation wieder verwendet werden kann. Die Schritte zur Einrichtung der virtuellen Maschine sind wie folgt:

Es soll eine anwendungsspezifische Konfiguration der virtuellen Maschine erfolgen (Abbildung 2.4).



Abbildung 2.4.: Auswahl des Konfigurationstyps: Custom

Es erfolgt die Festlegung des zu installierenden Betriebssystems (Abbildung 2.5). Bei der Debian 3.1. Sarge Installation soll ein Kernel der 2.6.x Serie verwendet werden.

Abbildung 2.5.: Auswahl des Gast-Betriebssystems innerhalb der virtuellen MaschineDie Pfade für die Ablage der VMware Dateien der virtuellen Maschine werden in dem in Abbildung 2.6 dargestellten Fenster definiert.




Abbildung 2.6.: Name und Pfade der Dateien der virtuellen Maschine

Die neu erstellte virtuelle Maschine wird für den Zugriff durch mehrere Benutzer (auf der VMware Host-Plattform) freigegeben (Abbildung 2.7).

Abbildung 2.7.: Zugriffsberechtigungen zur virtuellen Maschine



Die virtuelle Maschine soll beim Hochfahren der VMware Host-Plattform nicht automatisch gestartet und beim Herunterfahren automatisch angehalten werden (Abbildung 2.8).

Abbildung 2.8.: Start- und Shutdown-Optionen

Die virtuelle Maschine wird mit einem Speicher von 256 MB konfiguriert (Abbildung 2.9).




Abbildung 2.9.: Speicherkonfiguration der virtuellen Maschine

Um die virtuellen Maschinen (zur Nachbildung eines Multi-Host-Szenarios) untereinander vernetzen zu können und ggf. externe Internet-Zugriffe über den VMware-Host als Router durchführen zu können, wird das Netzwerk im NAT-Modus (Network Address Translation) konfiguriert (Abbildung 2.10).

Abbildung 2.10.: Netzwerkkonfiguration der virtuellen Maschine



Abbildung 2.11.: Art des I/O-Adapters der virtuellen MaschineDie virtuelle Maschine soll eine SCSI-Festplatte mit einer Größe von 1,5 GB zur Aufnahme des Betriebssystems und der Nutzerdaten simulieren (Abbildung 2.11 ... Abbildung 2.14).




Abbildung 2.12.: Einrichtungsoptionen für die simulierte Festplatte

Abbildung 2.13.: Art der Festplatte der simulierten virtuellen Maschine



Abbildung 2.14.: Größe der simulierten Festplatte




Abbildung 2.15.: VMware Konsolenfenster für die neu eingerichtete virtuelle Maschine

Nachfolgend werden ggf. noch weitere Parameter der virtuellen Maschine spezifiziert, falls die Standardeinstellungen der VMware-Umgebung für den geplanten Einsatz nicht geeignet sind. Es handelt sich dabei um Einstellungen

• zum DVD-Laufwerk (hier ist bei der in der VMware-Umgebung vorhandenen Hardware der Eintrag „legacy emulation“ zu aktivieren)

• zum Floppy-Disk-Laufwerk

• zur Netzwerkkarte

Sobald diese Einstellungen angepasst sind, kann die neu erstellte virtuelle Maschine zum ersten Mal gebootet werden, um die Installation von Debian 3.1 Sarge von DVD aus vorzunehmen.

2.2 Installation von Debian 3.1 Sarge in der virtuellen Maschine

Die nachfolgende Zusammenstellung der Installationsschritte eines Debian 3.1 Sarge Linux kann – unabhängig von den zuvor beschriebenen VMware Einstellungen – verwendet werden, um eine paketreduzierte Installationsplattform für den Einsatz des Tomcat Servlet Containers zu schaffen. Die Installation beginnt wie üblich mit dem Booten der virtuellen Maschine (bzw. des Rechners, auf dem diese Plattform installiert werden soll) vom Debian 3.1 Sarge Installationsmedium.



Zur Installation des Kernels 2.6.x wird beim ersten Debian Bootprompt der Parameter

• linux26

verwendet. Weitere Parameter bei der Installation:

• Sprache: Deutsch

• Land oder Gebiet: Deutschland

• Tastaturlayout: Deutsch

• Rechnername: debian-template

• Domänenname: tomcattest

• Partitionierung der virtuellen Festplatte SCSI1 (0,0,0) (sda) – 1.6 GB:

• Partition 1: primary, 1.35 GB, Mountpoint /, Filesystem ext3

• Partition 2: primary, 255 MB, swap

Es erfolgt die Installation des Debian Grundsystems.

• Installation des GRUB-Bootloaders im Master Boot Record der virtuellen Maschine

Entnahme der Installations-DVD und Reboot der neu installierten virtuellen Maschine.

Konfiguration des Debian-Grundsystems

• Hardware-Uhr auf GMT eingestellt: nein

• Zeitzone: Europa/Berlin

• Root-Passwort: vmware

• Anlegen eines Benutzerkontos: Selektion abbrechen ausführen

• apt konfigurieren (dazu die Debian 3.1 Sarge Installations-DVD wieder ins Laufwerk einlegen, nach dem Einlesen der DVD erfolgt die folgende Abfrage):

• Zugriffsmethode für apt auf das Paketarchiv: cdrom

• Weitere Installations-CDs: nein

• Weitere apt-Quellen hinzufügen: nein

• Nutzung der Sicherheitsupdates von security.debian.org7: ja (zur Installation der seit der Fertigstellung der Installations-DVD hinzugekommenen Sicherheitsupdates des Betriebssystems)

7 http://security.debian.org


http://security.debian.org/



• Pakete auswählen und installieren:

• Manuelle Auswahl

• hier wird zunächst die Standardvorgabe an Paketen (keine Modifikation der Paketliste) nachinstalliert, bevor in einem späteren Schritt noch Anwender-spezifizierte Pakete ergänzt werden

• Konfiguration vor der Installation

• SSH: nur SSH Protokoll Version 2 erlauben

• ssh-keysign: mit SUID Bit installieren

• sshd Server: starten

Anschließend werden zunächst die Standardpakete nachinstalliert (von der Installations-DVD, oder, falls für diese Pakete bereits Security Updates vorhanden sind, direkt von der Debian Security Webseite). Nach Abschluss dieses Installationsschrittes sind 314 MB auf der Festplatte belegt.

• Im nächsten Schritt wird die Konfiguration des Grundsystems abgeschlossen und es erfolgt ein root-Login im Grundsystem

• Mit dem Installationswerkzeug aptitude werden nun noch weitere benötigte Pakete nachinstalliert (Editoren, Webbrowser, minimale X-Window Umgebung, Netzwerkdiagnose). Dazu werden die unten genannten Pakete manuell selektiert. Pakete, von denen die selektierten abhängen, werden dabei automatisch mit installiert:

• Kategorie nicht installierte Pakete:

• in Kategorie devel – main:

• ant

• ant-doc

• autoconf

• cvs

• in Kategorie doc – main:

• bind9-doc

• in Kategorie editors – main:

• emacs21

• vim-full



• in Kategorie libdevel – main:

• libssl-dev (zur Übersetzung von mod_ssl für Apache)

• in Kategorie misc – main:

• mysql-client (zum Test der JDBC-basierten Authentisierung)

• mysql-server (zum Test der JDBC-basierten Authentisierung)

• in Kategorie net – main:

• bind9 (zum Aufsetzen eines lokalen DNS-Servers)

• gq (LDAP Browser)

• ldap-utils (zum Test der LDAP-basierten Authentisierung)

• slapd (zum Test der LDAP-basierten Authentisierung)

• rsync

• tcpdump

• in Kategorie utils – main:

• bzip2

• openssl

• in Kategorie web – main:

• mozilla-firefox

• in Kategorie x11 – main:

• desktop-base

iceconf

• icepref

• icewm

• x-window-system

(In einer reinen Server-Umgebung ohne grafische Benutzeroberfläche kann bei der Installation auf die Pakete der beiden letzten Kategorien web bzw. x11 verzichtet werden)

Die Abfragen zur Konfiguration werden wie folgt beantwortet:

• CVS Repository-Wurzelverzeichnis: /var/lib/cvs




• CVS Repository: anlegen

• CVS-pserver starten: nein

• libpango - entrust font management to defoma: ja

• x-ttcidfont-conf TrueType font handling backend: freetype

• Konfiguration von slapd (wird zum Test LDAP-basierter Authentisierung benötigt)

• Domänenname: bsitomcat.tsi-itcsec.de

• Organisationsname: BSI-Tomcat TSI ITC-Security

• Admin-Passwort: vmware

• LDAPv2 Protokoll erlauben: nein

• Konfiguration von xserver-xfree86 (diese Schritte würden in einer reinen Server-Umgebung ohne grafische Benutzeroberfläche entfallen)

• Grafikkarte automatisch erkennen: ja

• Kernel-Framebuffer Schnittstelle verwenden: ja

• XKB-Regelsatz: xfree86

• Tastaturoptionen: - keine -

• Maus automatisch erkennen: ja

• Mausanschluss: /dev/input/mice

• Monitor automatisch erkennen: ja

• LCD-Monitor: ja

• Monitor-Konfiguration: medium

• Monitor-Auflösung: 1024x768, 60 Hz

• verwendete Video-Modi: 1024x768, 800x600, 640x480

• Farbtiefe: 16 bit8

• Konfiguration von xprint-common

• Standard Druckerauflösung (dpi): 600

8 Die ursprünglich hier vorgegebenen 24 bit Farbtiefe müssen entsprechend den Einstellungen der Farbtiefe auf dem VMware-Hostrechner angepasst werden. Daher wurde der Parameter „DefaultDepth“ in der Datei /etc/X11/XF86config-4 von ursprünglich 24 auf 16 bit geändert.



Es erfolgt die Installation der übrigen Pakete von DVD bzw. aus den heruntergeladenen Paketen des Debian Security Servers. Nach Abschluss dieses Installationsschrittes sind 600MB auf der Festplatte belegt.

Weitere manuelle Konfigurationsänderungen:

• /etc/inittab: durch die Tastenkombination Ctrl-Alt-Del wird ein Shutdown-Halt (statt Reboot) ausgeführt, um die virtuelle Maschine gezielt anhalten zu können.

2.3 Installation der zu testenden Anwendungen

Im nächsten Schritt werden die benötigten Anwendungspakete für eine Installation innerhalb der virtuellen Maschinen übertragen (per Web-Download bzw. aus einem lokalen Software-Repository per scp). Zur Vereinheitlichung wird von folgenden Voraussetzungen ausgegangen (eine detaillierte Beschreibung der Installationsschritte wird in Abschnitt 3 gegeben):

• die heruntergeladenen Pakete werden unter /root/bsi_tomcat abgelegt

• um mit möglicherweise bereits installierten Paketen (z. B. aus der entsprechenden Linux-Distribution) keine Konflikte zu erzeugen, werden die Installationen unter dem Verzeichnis /opt durchgeführt. Soweit erforderlich erfolgt die Übersetzung der Softwarepakete unterhalb des Verzeichnisses /root/bsi_tomcat. Somit befinden sich nach Abschluss der Installation die verschiedenen Softwarepakete in den folgenden Unterverzeichnissen (soweit auf der jeweiligen virtuellen Maschine vorhanden):

• Java SDK 1.5.0_05: /opt/jdk1.5.0_05 (nachfolgend auch als $JAVA_HOME bezeichnet)

Das Skript /root/bsi_tomcat/install_jdk5.sh führt die Installation des Java Software Design Kits aus.

• Apache 2.0.54: /opt/httpd-2.0.54 (nachfolgend auch als $HTTPD_HOME oder $APACHE_INSTALL bezeichnet)

Das Skript /root/bsi_tomcat/install_apache.sh übersetzt und installiert den Apache Webserver.

• Jakarta Tomcat: /opt/jakarta-tomcat-5.5.9 (nachfolgend auch als $CATALINA_HOME bezeichnet)

Das Skript /root/bsi_tomcat/install_tomcat.sh entpackt die Binärversion des Jakarta Tomcat Servlet Containers.

• Jakarta Tomcat Connector (mod_jk): Das Connector-Modul (mod_jk.so) befindet sich nach der Installation im Unterverzeichnis modules der Apache-Installation.

Die Übersetzung und Installation des Connector-Moduls erfolgt mit dem Skript /root/bsi_tomcat/install_mod_jk.sh




• MySQL Database Java Connector: Das zur Verbindung mit der MySQL-Datenbank benötigte Java Archiv mysql-connector-java-3.1.10-bin.jar wird in das common/lib Unterverzeichnis der Jakarta Tomcat Installation kopiert.

Das Skript /root/bsi_tomcat/install_mysqlj.sh führt die Installation des MySQL Connectors aus.

• Log4J und commons-logging: zum Logging in Tomcat wird je ein jar-Archiv in das common/lib Unterverzeichnis der Jakarta Tomcat Installation kopiert sowie eine Konfigurationsdatei common/classes/log4j.properties erzeugt.

Skript /root/bsi_tomcat/install_logging_components.sh führt die Installation der Logging-jar-Archive aus.

Eine Konfiguration dieser Softwarekomponenten erfolgt zunächst nicht.

Nach Abschluss der allgemeinen Installation / Konfiguration wird die virtuelle Maschine zur Erzeugung einer Arbeitskopie heruntergefahren (shutdown -h now).

2.4 Replikation von virtuellen Maschinen

Zur Realisierung mehrerer virtueller Hostinstanzen kann die zuvor erstellte virtuelle Maschine beliebig oft repliziert und nebenläufig betrieben werden.

Die Replikation von virtuellen Maschinen für weitere Arbeiten erfolgt in zwei Stufen:

• Auf Betriebssystemebene wird das Verzeichnis mit den Dateien der virtuellen Maschine (Festplattenimage der virtuellen Maschine, Konfigurationsdateien) kopiert:

cp -rp Debian_3.1_template Debian_3.1_host<n>

• Anschließend muss die Kopie der VMware Konsole noch bekannt gemacht werden (Schritte in Abbildungen 2.16 … 2.18)

Abbildung 2.16.: Suche der neuen virtuellen Maschine mit dem „Browse“ Button



Abbildung 2.17.: Auswahl der .vmx-Datei zur selektierten virtuellen Maschine

Abbildung 2.18.: Anpassung des Namens der virtuellen Maschine

Alternativ kann das von VMware selbst bereitgestellte Duplikationsverfahren angewendet werden.



Installation der Softwarekomponenten

3. Installation der Softwarekomponenten

In den nachfolgenden Abschnitten wird die Installation der für den Test benötigten Softwarekomponenten beschrieben. Es handelt sich dabei um

• das Java Software Design Kit (Binärpaket)

• den Apache Webserver (Quellcodepaket)

• den Jakarta Tomcat Servlet Container (Binärpaket)

• den Jakarta Tomcat Connector mod_jk (Quellcodepaket)

• den MySQL-Connector/J zur Datenbankanbindung (Binärpaket)

• die Log4j und commons-logging Software (Binärpakete)

Soweit es sich um Binärpakete handelt (Java SDK, Jakarta Tomcat Servlet Container, MySQL-Connector/J), werden diese direkt installiert. Quellcodepakete werden zunächst übersetzt und dann installiert. In der Testinstallation wird die oben genannte Software nach Bezug von den Entwickler-Webseiten nachinstalliert.


Installation der Softwarekomponenten Sicherheitsuntersuchung des ApacheJakarta Tomcat Servlet Containers

Vergleichbare Softwarekomponenten aus der Linux-Distribution sind in der Testinstallation nicht vorhanden. Um anderen Nutzern eine vergleichbare Installation zu ermöglichen, werden sämtliche Softwarekomponenten unter dem Verzeichnis /opt installiert, sodass es zu keinen Konflikten mit möglicherweise an anderer Stelle installierten Softwarepaketen aus der von diesen Nutzern verwendeten Linux-Distribution kommen sollte.

Die unten im Text aufgeführten install_*.sh Shell-Skripts wurden für die Reproduzierbarkeit der Installationsschritte erstellt und eingesetzt.

3.1 Java Software Design Kit (SDK, Version 1.5.0_05)

Der Java-basierte Jakarta Tomcat Servlet Container benötigt zur Ausführung die Installation eines Java Software Design Kits (SDK). Die für die beschriebenen Untersuchungen verwendete aktuelle Version 1.5.0 Update 05 ist für Linux-Plattformen zum Download erhältlich von Sun Microsystems, Inc.9 Die Installation erfolgt nach dem Download als Nutzer root mit folgendem Installationsskript install_jdk5.sh:

Listing 2: Installationsskript install_jdk5.sh#!/bin/bash

# where we can find the installation packages / sources:SW_REPOSITORY="/root/bsi_tomcat"

# where to install:INSTALL_BASE="/opt"

#-----------------------------------------------------------------# Install the Java 1.5.0_05 SDK

cd ${INSTALL_BASE}chmod u+x ${SW_REPOSITORY}/j2se_5/jdk-1_5_0_05-linux-i586.bin${SW_REPOSITORY}/j2se_5/jdk-1_5_0_05-linux-i586.bin

#-----------------------------------------------------------------# -- eof --#-----------------------------------------------------------------

Hierdurch wird das Java Software Design Kit unter dem Verzeichnis /opt/jdk1.5.0_05 ($JAVA_HOME) installiert. Da die von der jeweiligen Linux-Distribution mitgelieferten Java SDK Installationen üblicherweise in die /usr, /etc, ... Verzeichnisse integriert werden, ergibt sich durch die Installation unter /opt kein Konflikt. Gegebenenfalls ist zur Nutzung dieser Java SDK Installation beim Setzen der Suchpfade und Java-Environment-Variablen die geänderte Lage zu berücksichtigen.

Feststellung: Eine Durchsicht der Java SDK Installation hat ergeben, dass sämtliche Dateien unter Benutzer:Gruppe root:root installiert werden. Weder die Gruppe noch andere (World) haben Schreibberechtigungen auf die installierten Dateien und es sind weder SUID (Set User ID) noch SGID (Set Group ID) Bits in den installierten Dateien gesetzt, sodass Modifikationen an den installierten Dateien nur durch den Benutzer root10 vorgenommen werden können.

9 http://java.sun.com/j2se/1.5.0/download.jsp 10 bzw. durch andere Benutzer, die temporär root Berechtigungen erlangen können (z. B. per su oder sudo Kommando)


http://java.sun.com/j2se/1.5.0/download.jsp



Nach Abschluss der Installation sollte das Passwort des globalen Java CA-Zertifikatspeichers von der Standardeinstellung changeit geändert werden (s. Abschnitt 6.1.3). Dies gilt insbesondere bei der Verwendung von Client-Zertifikat-basierten Authentisierungsverfahren in Tomcat Webanwendungen.

3.2 Apache Webserver (Version 2.0.54)

Für den Apache Webserver wird aus der Quelltextversion, die von der Entwickler-Websseite11 heruntergeladen werden kann, eine Standardinstallation durchgeführt. Hierzu werden die Quelltexte übersetzt und die Binärversion der Programme sowie die Konfigurations- und Dokumentationsdateien aus Gründen der Vermeidung von Konflikten mit möglicherweise aus der Linux-Distribution installierten Apache Webserver Software unter dem Verzeichnis /opt/httpd-2.0.54 ($APACHE_INSTALL) installiert. Die Installation erfolgt als Nutzer root mit dem Skript install_apache.sh:

Listing 3: Installationsskript install_apache.sh#!/bin/bash



APACHE_INSTALL="${INSTALL_BASE}/httpd-2.0.54"

#---------------------------------------------------------------------# install the apache web server

cd ${SW_REPOSITORY}/apacherm -rf ${SW_REPOSITORY}/apache/httpd-2.0.54tar xvfz ${SW_REPOSITORY}/apache/httpd-2.0.54.tar.gz

cd ${SW_REPOSITORY}/apache/httpd-2.0.54./configure --prefix=${APACHE_INSTALL} --enable-ssl && \make && \make install

#---------------------------------------------------------------------# configuration for apache - tomcat cooperation:# ${APACHE_INSTALL}/conf/httpd.conf# ${APACHE_INSTALL}/conf/ssl.conf

cd ${APACHE_INSTALL}/confln -s ${INSTALL_BASE}/jakarta-tomcat-5.5.9/conf/workers.properties

mkdir ${APACHE_INSTALL}/conf/ssl.crtmkdir ${APACHE_INSTALL}/conf/ssl.key# copy the apache webserver certificate / key to these directories##---------------------------------------------------------------------

#---------------------------------------------------------------------# to start Apache with SSL support:## ${APACHE_INSTALL}/bin/apachectl -f ${APACHE_INSTALL}/conf/httpd.conf -DSSL#

11 http://httpd.apache.org/


http://httpd.apache.org/


#---------------------------------------------------------------------# -- eof --#---------------------------------------------------------------------

Feststellung: Eine Durchsicht der Apache Webserver Installation hat ergeben, dass die Dateien überwiegend unter Benutzer:Gruppe root:root, teilweise aber auch unter dem auf dem Testsystem nicht vorhandenen Benutzer:Gruppe 1000:1000 (es sind dies überwiegend die Dateien in den Verzeichnissen error, htdocs, icons, include, sowie manual) installiert werden.

Weder die Gruppe noch andere (World) haben Schreibberechtigungen auf die installierten Dateien und es sind weder SUID (Set User ID) noch SGID (Set Group ID) Bits in den installierten Dateien gesetzt, sodass Modifikationen an den installierten Dateien nur durch den Benutzer root12 bzw. teilweise durch den auf dem System nicht vorhandenen Nutzer 1000 vorgenommen werden können.

Zum grundlegenden Test der erfolgreichen Installation kann der Apache Webserver zunächst für den Betrieb ohne HTTPS-Verbindungsunterstützung mit dem Kommando

APACHE_INSTALL=/opt/http-2.0.54 && \${APACHE_INSTALL}/bin/apachectl -f ${APACHE_INSTALL}/conf/httpd.conf

gestartet werden.

Um HTTPS-Verbindungen zum Webserver freizugeben, ist das letztgenannte Kommando mit der Option -DSSL aufzurufen. Hierzu müssen zuvor ggf. noch weitere Konfigurationen in der Datei $APACHE_INSTALL/conf/ssl.conf vorgenommen sowie Server-Zertifikat und zugehöriger privater Schlüssel installiert werden (s. Abschnitt 4.7.3).

Mit einem Webbrowser kann nun die URL http://127.0.0.1:80 geöffnet werden und sollte zu folgender Webseite führen:

12 bzw. durch andere Benutzer, die temporär root Berechtigungen erlangen können (z. B. per su oder sudo Kommando)




Es ist zu beachten, dass es sich hierbei wegen der noch durchzuführenden Tests um einen völlig unkonfigurierten Webserver handelt. Dieser sollte, um erhebliche Sicherheitsprobleme zu vermeiden, so nicht für einen Zugriff z. B. aus dem Internet freigeschaltet werden.

3.3 Jakarta Tomcat Servlet Container (Version 5.5.9)

Die Installation des Jakarta Tomcat Servlet Containers erfolgt nach dem Download des Binärpaketes von der Entwickler-Webseite13 als Nutzer root mit dem Installationsskript install_tomcat.sh:

Listing 4: Installationsskript install_tomcat.sh#!/bin/bash



#---------------------------------------------------------------------# Install the binary package of jakarta-tomcat 5.5.9

cd ${INSTALL_BASE}tar xvfpz ${SW_REPOSITORY}/jakarta_tomcat/jakarta-tomcat-5.5.9.tar.gz

#- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -# --- optionally: install the jsvc tool for running tomcat as daemon

13 http://jakarta.apache.org/site/downloads/downloads_tomcat.html


Abbildung 3.1.: Test-Startseite des Apache Webservers

http://jakarta.apache.org/site/downloads/downloads_tomcat.html


cd ${INSTALL_BASE}/jakarta-tomcat-5.5.9/bintar xvfpz jsvc.tar.gzcd jsvc-srcautoconf./configure --with-java=${INSTALL_BASE}/jdk1.5.0_05makecp jsvc ..cd ..

#- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -# --- optionally: install the admin packagetar xvfpz ${SW_REPOSITORY}/jakarta_tomcat/jakarta-tomcat-5.5.9-admin.tar.gz

#- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -# environment variables definitionscat > ${INSTALL_BASE}/jakarta-tomcat-5.5.9/bin/setenv.sh <<EOF####################################################################### environment variables for tomcat######################################################################

export JAVA_HOME="${INSTALL_BASE}/jdk1.5.0_05"export JRE_HOME="${INSTALL_BASE}/jdk1.5.0_05/jre"export CATALINA_HOME="${INSTALL_BASE}/jakarta-tomcat-5.5.9"export CATALINA_BASE="${INSTALL_BASE}/jakarta-tomcat-5.5.9"

####################################################################### -- eof --######################################################################EOF

#---------------------------------------------------------------------# to start tomcat:## ${INSTALL_BASE}/jakarta-tomcat-5.5.9/bin/catalina.sh start##---------------------------------------------------------------------

#--------------------------------------------------------------------# -- eof --#---------------------------------------------------------------------

Neben der eigentlichen Installation wird die Datei $CATALINA_HOME/bin/setenv.sh erzeugt, mit der die Suchpfade zum Java SDK bzw. zur Tomcat Installation gesetzt werden.

Um den Jakarta Tomcat Servlet Container als Daemon zu nutzen, muss das im Tomcat-Binärpaket vorhandene Tool jsvc für das Ziel-Betriebssystem übersetzt werden. Mit Hilfe von jsvc -user ist es auch möglich, den Jakarta Tomcat Servlet Container als non-root Benutzer auszuführen, auch wenn privilegierte Ports (1 .. 1023) verwendet werden.

Feststellung: Eine Durchsicht der Apache Webserver Installation hat ergeben, dass sämtliche Dateien unter Benutzer:Gruppe root:root installiert werden. Weder die Gruppe noch andere (World) haben Schreibberechtigungen auf die installierten Dateien und es sind weder SUID (Set User ID) noch SGID (Set Group ID) Bits in den installierten Dateien gesetzt, sodass Modifikationen an den installierten Dateien nur durch den Benutzer root14

vorgenommen werden können.

14 bzw. durch andere Benutzer, die temporär root Berechtigungen erlangen können (z. B. per su oder sudo Kommando)




Zum Test der erfolgreichen Installation kann der Jakarta Tomcat Servlet Container nun mit dem Kommando

INSTALL_BASE=/opt && \${INSTALL_BASE}/jakarta-tomcat-5.5.9/bin/catalina.sh start

gestartet werden. Mit einem Webbrowser kann nun die URL http://127.0.0.1:8080 geöffnet werden und sollte zu folgender Tomcat-Start-Webseite führen:

In dieser Betriebsart arbeitet der Jakarta Tomcat Servlet Container selbst als HTTP-Server und kann somit über seinen HTTP-Connector direkt per HTTP angesprochen werden (entsprechend dem Einsatzszenario 1 aus [Tomcat Fein.]). Auch hier gilt wie im Fall des zuvor beschriebenen Basistests der Installation des Webservers Apache, dass diese Installation ohne weitere Konfiguration aus Sicherheitsgründen nicht für Zugriffe aus dem Internet freigeschaltet werden sollte.

In den meisten Fällen wird man jedoch für die Bereitstellung der statischen Internetseiten einen dafür optimierten Webserver (wie z. B. Apache) verwenden (entsprechend den Einsatzszenarien 2 – 6 aus [Tomcat Fein.]). Um diesen in Verbindung mit dem Jakarta Tomcat Servlet Container nutzen zu können, wird ein Connector Modul benötigt, das im


Abbildung 3.2.: Test-Startseite des Jakarta Tomcat Servlet Containers


Webserver die Kommunikation zwischen dem Webserver und dem Tomcat Servlet Container, die auf dem AJPv13 (Apache JServ Protocol version 1.3) basiert, abwickelt. Dessen Installation wird im folgenden Abschnitt beschrieben.




3.4 Jakarta Tomcat Connector Modul mod_jk (Version 1.2.14)

Da von der Entwickler-Webseite des Jakarta Tomcat Connector Moduls15 keine Binärversion für die in der Testumgebung gewählte Debian 3.1 Sarge Linux Version verfügbar ist, muss diese aus dem Quellcodepaket erzeugt werden. Hierfür ist das Installationsskript install_mod-jk.sh vorgesehen, das auf den Hinweisen der Connector-Modul-Dokumentation16

basiert:

Listing 5: Installationsskript install_mod-jk.sh#!/bin/bash



APACHE_INSTALL="${INSTALL_BASE}/httpd-2.0.54"

#---------------------------------------------------------------------# prepare the mod_jk connector

cd ${SW_REPOSITORY}/jakarta_tomcattar xvfpz ${SW_REPOSITORY}/jakarta_tomcat/jakarta-tomcat-connectors-1.2.14.1-src.tar.gz

cd ${SW_REPOSITORY}/jakarta_tomcat/jakarta-tomcat-connectors-1.2.14.1-src/jk/native

./configure --with-apxs=${APACHE_INSTALL}/bin/apxs && \make && \make install

# installs mod_jk.so under ${APACHE_INSTALL}/modules/

#---------------------------------------------------------------------# configuration:# ${APACHE_INSTALL}/conf/httpd.conf:### ${APACHE_INSTALL}/conf/workers.properties:# copy / link from ${INSTALL_BASE}/jakarta-tomcat-5.5.9/conf/workers.properties##---------------------------------------------------------------------# to start tomcat:## ${INSTALL_BASE}/jakarta-tomcat-5.5.9/bin/catalina.sh start## to start apache:## ${APACHE_INSTALL}/bin/apachectl -f ${APACHE_INSTALL}/conf/httpd.conf#

#---------------------------------------------------------------------# -- eof --#---------------------------------------------------------------------

15 http://jakarta.apache.org/site/downloads/downloads_tomcat.html 16 http://jakarta.apache.org/tomcat/connectors-doc/install/apache2.html


http://jakarta.apache.org/tomcat/connectors-doc/install/apache2.html

http://jakarta.apache.org/site/downloads/downloads_tomcat.html


1 Das erzeugte mod_jk.so Modul zur Einbindung in den Apache Webserver wird durch das Kommando make install im Skript automatisch in das Verzeichnis modules der Apache Installation kopiert. Es wird dort unter Benutzer:Gruppe root:root und ohne Schreibberechtigung für die Gruppe oder andere [World] installiert. Weitere Änderungen oder Ergänzungen in der Apache Installation werden automatisch nicht durchgeführt.

Zur Nutzung des Connector Moduls sind in der Konfigurationsdatei $APACHE_INSTALL/conf/httpd.conf des Apache Webservers manuell entsprechende Einstellungen vorzunehmen, die ein dynamische Laden des Connector Moduls veranlassen, sowie die Datei $APACHE_INSTALL/conf/workers.properties zu erzeugen, wie dies im Folgenden beschrieben ist.

3.4.1 Apache-Konfigurationsdatei httpd.conf

Zur Aktivierung des Connector Moduls im Apache Webserver sind entsprechende Eintragungen in der Konfigurationsdatei $APACHE_INSTALL/conf/httpd.conf vorzunehmen. Dies sind einmal die Ladedirektive für das Connector Modul, die Konfigurationen des Loggings (JkLogStampFormat bzw. JkRequestLogFormat: welche Informationen werden protokolliert) und außerdem eine Deklaration sämtlicher Webanwendungen, die über das Connector Modul durch den Jakarta Tomcat Servlet Container bedient werden sollen (hierzu gehören die Tomcat-Dokumentation, die Standard-Administrationsapplikationen manager und admin sowie die 3 Webanwendungen simple_info(1|1a|2) für Authentisierungstests, s. S. 84):

Listing 6: Auszug aus der Apache-Konfigurationsdatei httpd.conf...<IfModule !mod_jk.c> LoadModule jk_module modules/mod_jk.so</IfModule>

<IfModule mod_jk.c> JkWorkersFile "conf/workers.properties" JkLogFile "logs/mod_jk.log"

JkLogLevel info1.

JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " JkRequestLogFormat "%w %V %T"

# all requests are handled by worker bsi_ajp13_1 JkMount /tomcat-docs bsi_ajp13_1 JkMount /tomcat-docs/* bsi_ajp13_1 JkMount /admin bsi_ajp13_1 JkMount /admin/* bsi_ajp13_1 JkMount /manager bsi_ajp13_1 JkMount /manager/* bsi_ajp13_1 JkMount /simple_info1 bsi_ajp13_1 JkMount /simple_info1/* bsi_ajp13_1 JkMount /simple_info1a bsi_ajp13_1 JkMount /simple_info1a/* bsi_ajp13_1 JkMount /simple_info2 bsi_ajp13_1 JkMount /simple_info2/* bsi_ajp13_1

</IfModule>...




Weiterhin hilfreich für die Zustandsanalyse des Apache Webservers im Rahmen der Untersuchungen ist die Freigabe der Statusinformationen, die dann über die URL http://127.0.0.1/server-status abgerufen werden können:

...ExtendedStatus On<Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from 127.0.0.1</Location>...

Eine Beschränkung der Zugriffe auf den localhost (IP-Adresse 127.0.0.1) bzw. ggf. auf einen Management-Host ist aus Sicherheitsgründen sinnvoll, um Statusabfragen von anderen Hosts aus über das Netzwerk zu verhindern.

3.4.2 Tomcat Konfigurationsdatei server.xml

Nachfolgend ist eine Basiskonfiguration für die Datei $CATALINA_HOME/conf/server.xml aufgeführt, in der beispielsweise festgelegt wird, über welche Ports die Kommunikation mit dem Jakarta Tomcat Servlet Container erfolgt. Darin sind

• Port 8080 für direkte HTTP-Zugriffe auf den Tomcat Servlet Container (Szenario 1),

• Port 8443 für direkte HTTPS-Zugriffe auf den Tomcat Servlet Container (zunächst noch ohne Client-Authentisierung. Mit dem unter $CATALINA_HOME/conf/.keystore abgelegten Server-Zertifikat und den später für die Client-Authentisierung verwendeten Zertifikaten der Certification Authorities (CAs), die zur Signierung der Client-Zertifikate verwendet wurden, in $CATALINA_HOME/conf/truststore),

• Port 8009 für AJP (Apache JServ Protocol) Anfragen des Apache Webserver (über das mod_jk Connector Modul) an den Jakarta Tomcat Servlet Container (Szenarien 2 - 6) und

• Port 8005 (hier in Verbindung mit der gewählten Zeichenkette SHUTDOWN) zum Herunterfahren des Tomcat Servlet Containers17

vorgesehen. Weiterhin sind die für die verschiedenen Authentisierungsverfahren benötigten Einträge (für Memory Realm, JDBC Realm, JNDI Realm) bereits in der Datei vorhanden, jedoch durch XML-Kommentare bis auf den gerade zu testenden deaktiviert:

Listing 7: Tomcat-Konfigurationsdatei $CATALINA_HOME/conf/server.xml<Server port="8005" shutdown="SHUTDOWN"> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/> <Listener className="org.apache.catalina.storeconfig.StoreConfigLifecycleListener"/> <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener"/> <GlobalNamingResources> <Environment name="simpleValue" type="java.lang.Integer"

17 Zur Erhöhung der Sicherheit gegen Denial-of-Service Angriffe sollte überlegt werden, ob dieser Port überhaupt aktiviert werden sollte, siehe Abschnitt 6.3.2.



value="30"/> <Resource auth="Container" description="User database that can be updated and saved" name="UserDatabase" type="org.apache.catalina.UserDatabase" pathname="conf/tomcat-users.xml" factory="org.apache.catalina.users.MemoryUserDatabaseFactory"/> </GlobalNamingResources> <Service name="Catalina"> <Connector port="8080" redirectPort="8443" minSpareThreads="25" connectionTimeout="20000" maxSpareThreads="75" maxThreads="150" maxHttpHeaderSize="8192"> </Connector> <Connector port="8443" minSpareThreads="25" connectionTimeout="20000" maxSpareThreads="75" maxThreads="150" maxHttpHeaderSize="8192" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="conf/.keystore" keystorePass="vmware" truststoreFile="conf/truststore" truststorePass=“vmware“> </Connector> <Connector port="8009" redirectPort="8443" protocol="AJP/1.3"> </Connector> <Engine defaultHost="localhost" name="Catalina"> <Realm className="org.apache.catalina.realm.MemoryRealm"/> <Host appBase="webapps" name="localhost"> </Host> </Engine> </Service></Server>

3.4.3 Apache-Konfigurationsdatei workers.properties

Weiterhin sind in der Datei $CATALINA_HOME/conf/workers.properties einige Anpassungen vorzunehmen. Diese Anpassungen betreffen im Wesentlichen spezifische Pfade der jeweiligen Installation. Die minimale verwendete Konfigurationsdatei sieht nach Entfernung zahlreicher Kommentare und weiterer zunächst nicht benötigter Direktiven wie folgt aus:

Listing 8: Apache-Konfigurationsdatei $CATALINA_HOME/conf/workers.properties###################################################################### workers.properties.minimal -####################################################################### This file provides minimal jk configuration properties needed to# connect to Tomcat.#workers.tomcat_home=/opt/jakarta-tomcat-5.5.9workers.java_home=/opt/jdk1.5.0_05

###################################################################### The workers that jk should create and work with#worker.list=bsi_ajp13_1

## Defining a worker named bsi_ajp13_1 and of type ajp13# Note that the name and the type do not have to match.#worker.bsi_ajp13_1.type=ajp13worker.bsi_ajp13_1.host=localhostworker.bsi_ajp13_1.port=8009

###################################################################### -- eof --#####################################################################

Am günstigsten ist für eine Bereitstellung identischer Dateien für den Apache Webserver wie für den Jakarta Tomcat Servlet Container, wenn diese Datei im System nur einmal



vorhanden ist (z. B. im Tomcat-Konfigurationsverzeichnis $CATALINA_HOME/conf, auf die dann aus dem Apache Konfigurationsverzeichnis $APACHE_INSTALL/conf per Soft-Link verwiesen wird).

Anschließend kann der Apache Webserver mit dieser geänderten Konfiguration wieder gestartet werden und als Funktionstest die Tomcat-Dokumentation über den Apache Webserver mit der URL http://127.0.0.1/tomcat-docs/ aufgerufen werden. Dies sollte im Erfolgsfall zu folgendem, dem des direkten Abrufs dieser Webseite über Tomcat entsprechenden Ergebnis, d. h. ohne die Verwendung des Apache Webservers über die URL http://127.0.0.1:8080/tomcat-docs/, führen:

Abbildung 3.3.: Aufruf der Tomcat-Dokumentation über den Apache Webserver (http-Standard-Port) und den mod_jk-Connector.

Zur Nutzung der Tomcat admin18 und manager Applikationen wird die Datei $CATALINA_HOME/conf/tomcat-users.xml modifiziert, die im Rahmen der Memory Realm-basierten Authentisierung verwendet wird19:

18 Bestandteil des jakarta-tomcat-5.5.9-admin.tar.gz Paketes und inzwischen nicht mehr im Tomcat Paket selbst enthalten.




Listing 9: Tomcat-Benutzer-Definitionsdatei $CATALINA_HOME/conf/tomcat-users.xml<?xml version='1.0' encoding='utf-8'?><tomcat-users> <role rolename="admin"/> <role rolename="manager"/> <role rolename="user1"/> <role rolename="user2"/> <user username="memadmin" password="vmware" roles="admin"/> <user username="memadminhash" password="92963abd36c896b93a36b8e296ff3387" roles="admin"/> <user username="memmanager" password="vmware" roles="manager"/> <user username="memmanagerhash" password="92963abd36c896b93a36b8e296ff3387" roles="manager"/> <user username="memuser1" password="vmware" roles="user1"/> <user username="memuser1hash" password="92963abd36c896b93a36b8e296ff3387" roles="user1"/> <user username="memuser2" password="vmware" roles="user2"/> <user username="memuser2hash" password="92963abd36c896b93a36b8e296ff3387" roles="user2"/></tomcat-users>

3.5 Installation des MySQL-Connectors/J

Zum Test von Verbindungen des Tomcat Servlet Containers mit dem MySQL-DBMS (beispielsweise zur Authentisierung mit Hilfe von in der Datenbank abgelegten Nutzern bzw. Passworten sowie deren zugeordnete Rollen) wird der MySQL-Connector/J benötigt. Dieser MySQL-Connector/J kann derzeit in der Produkt-Version 3.1 von der Entwickler-Webseite20

heruntergeladen werden. Die Installation erfolgt dann mit Hilfe des Skriptes install_mysqlj.sh:

Listing 10: Installationsskript install_mysqlj.sh#!/bin/bash



#---------------------------------------------------------------------# Install the binary package of mysql-connector/j3.1

cd ${SW_REPOSITORY}tar xvfpz ${SW_REPOSITORY}/mysql-connector-java-3.1.10.tar.gz

# copy the non-debug version of the connector jar# to common/lib (which makes it available for both tomcat as well# as for web applications

cp -p mysql-connector-java-3.1.10/mysql-connector-java-3.1.10-bin.jar \ ${INSTALL_BASE}/jakarta-tomcat-5.5.9/common/lib

19 Für einen Produktiveinsatz des Jakarta Tomcat Servlet Containers sind natürlich die Standardvorgaben für die Passwörter auf sinnvolle Werte gemäß den jeweils vor Ort geltenden Passwortrichtlinen zu ändern. Die zum Test der verschiedenen Authentisierungsmethoden verwendeten Benutzernamen und Passworte sind in Abschnitt 4 zusammengestellt.

20 http://www.mysql.com/products/connector/j/


http://www.mysql.com/products/connector/j/


#---------------------------------------------------------------------# -- eof --#---------------------------------------------------------------------

3.6 Installationen für die JNDI-Konnektivität

Eine Nachinstallation von JNDI-Komponenten (wie in der Tomcat Dokumentation angegeben) ist zur Nutzung mit OpenLDAP bei der verwendeten Tomcat Version und in Verbindung mit der installierten Java SDK Version 5 nicht mehr erforderlich.

3.7 Installation der Logging-Komponenten

Eine Standardinstallation verfügt über ein Logging basierend auf den java.util.logging Klassen, die bereits im Java SDK enthalten sind.

In der Tomcat Dokumentation wird auf eine alternative / optionale Logging-Möglichkeit hingewiesen, die auf den log4j Bibliotheken des Jakarta Projekts selbst stammen. Für das alternative log4j Logging aus Tomcat heraus werden mit dem Skript install_logging_components.sh zwei jar-Archive sowie eine Konfigurationsdatei installiert:

Listing 11: Installationsskript install_logging_components.sh#!/bin/bash


# where to install:INSTALL_BASE="/opt"CATALINA_HOME="${INSTALL_BASE}/jakarta-tomcat-5.5.9"

#---------------------------------------------------------------------# Unpack and install the required jar files to support logging

cd ${SW_REPOSITORY}

mkdir -p ${CATALINA_HOME}/common/lib

tar -xvzOf logging-log4j-1.2.12.tar.gz \ logging-log4j-1.2.12/dist/lib/log4j-1.2.12.jar \ > ${CATALINA_HOME}/common/lib/log4j.jar# !! jar file without version number !!

tar -xvzOf commons-logging-1.0.4.tar.gz \ commons-logging-1.0.4/commons-logging.jar \ > ${CATALINA_HOME}/common/lib/commons-logging.jar

#---------------------------------------------------------------------# prepare the log configuration file

mkdir -p ${CATALINA_HOME}/common/classes

cat > ${CATALINA_HOME}/common/classes/log4j.properties <<EOFlog4j.rootLogger=debug, Rlog4j.appender.R=org.apache.log4j.RollingFileAppenderlog4j.appender.R.File=${CATALINA_HOME}/logs/tomcat.loglog4j.appender.R.MaxFileSize=10MB




log4j.appender.R.MaxBackupIndex=10log4j.appender.R.layout=org.apache.log4j.PatternLayoutlog4j.appender.R.layout.ConversionPattern=%p %t %c - %m%nlog4j.logger.org.apache.catalina=DEBUG, REOF

#---------------------------------------------------------------------# -- eof --#---------------------------------------------------------------------

Die jar-Dateien befinden sich in den Binär-Installationspaketen

• logging-log4j-1.2.12.tar.gz21 sowie

• commons-logging-1.0.4.tar.gz22.

Bei den dynamischen Tests wurde jedoch das Standard-Logging des Java SDK verwendet. Die oben aufgeführten Binär-Installationspakete werden jedoch von manchen Modulen explizit referenziert (beispielsweise Jasper), so dass sie bei einer Übersetzung des Quellcodes vorhanden sein müssen.

3.8 Einrichtung des lokalen DNS-Servers

Um Tests der Zugriffsfilterfunktionen anhand der Host- oder Domänennamen aus der vorhandenen Testumgebung heraus durchführen zu können, wird ein lokaler Domain Name Service (DNS) Server aufgesetzt, der ausschließlich lokal im Testnetz (192.168.118.0/24) arbeitet und lokale Anfragen hieraus beantwortet. Dieser DNS-Server dient dazu, aus den beim Tomcat-Server eintreffenden IP-Adressen per Reverse DNS Lookup die zugehörigen Hostnamen für einen Vergleich mit den vordefinierten Mustern für die Zugriffsteuerung zu gewinnen.

Für die Konfiguration des DNS-Servers wird davon ausgegangen, dass die beteiligten virtuellen Hosts (VH) bzw. der VMware Host (VM-Host) mit den folgenden statischen IP-Adressen konfiguriert sind (s. a. Abbildung 2.1):

• tomcathost.bsitomcat.de (VH): 192.168.118.101/26

• template.bsitomcat.de (VH): 192.168.118.100/26

• bigmama.external.de (VM-Host): 192.168.118.1/26

Für den DNS-Server (tomcathost) werden die folgenden Dateien erzeugt bzw. geändert, die Datei /etc/resolv.conf wird auch auf auch auf der zweiten virtuellen Testmaschine (template) installiert. Diese Informationen werden nicht auf den VM-Host übertragen, um dessen Netzwerkeinbindung und Namensauflösung nicht zu beeinflussen. Daher sind Verbindungen von dieser Maschine zum Apache-Test-Webserver bzw. zu Tomcat über die IP-Adresse des Testrechners (tomcathost) zu adressieren.

21 erhältlich unter http://logging.apache.org/log4j/docs/download.html22 erhältlich unter http://jakarta.apache.org/site/downloads/downloads_commons-logging.cgi


http://jakarta.apache.org/site/downloads/downloads_commons-logging.cgi

http://logging.apache.org/log4j/docs/download.html


Listing 12: DNS-Server-Konfigurationsdatei /etc/bind/named.conf:// This is the primary configuration file for the BIND DNS server named.//// Please read /usr/share/doc/bind9/README.Debian.gz for information on the// structure of BIND configuration files in Debian, *BEFORE* you customize// this configuration file.//// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";

// prime the server with knowledge of the root serverszone "." { type hint; file "/etc/bind/db.root";};

// be authoritative for the localhost forward and reverse zones, and for// broadcast zones as per RFC 1912

zone "localhost" { type master; file "/etc/bind/db.local";};

zone "bsitomcat.de" { type master; file "/etc/bind/db.bsitomcat.de"; allow-query { 192.168.118.0/24; }; allow-transfer { none; }; allow-update { none; };};

zone "external.de" { type master; file "/etc/bind/db.external.de"; allow-query { 192.168.118.0/24; }; allow-transfer { none; }; allow-update { none; };};

zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127";};



zone "118.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168.118"; allow-query { 192.168.118.0/24; }; allow-transfer { none; }; allow-update { none; };};




// zone "com" { type delegation-only; };// zone "net" { type delegation-only; };

// From the release notes:// Because many of our users are uncomfortable receiving undelegated answers// from root or top level domains, other than a few for whom that behaviour// has been trusted and expected for quite some length of time, we have now// introduced the "root-delegations-only" feature which applies delegation-only// logic to all top level domains, and to the root domain. An exception list// should be specified, including "MUSEUM" and "DE", and any other top level// domains from whom undelegated responses are expected and trusted.// root-delegation-only exclude { "DE"; "MUSEUM"; };

include "/etc/bind/named.conf.local";

Listing 13: DNS-Server-Konfigurationsdatei /etc/bind/named.conf.options:options { directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want // to talk to, you might need to uncomment the query-source // directive below. Previous versions of BIND always asked // questions using port 53, but BIND 8.1 and later use an unprivileged // port by default.

// query-source address * port 53;

// If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0's placeholder.

// forwarders { // 0.0.0.0; // };

auth-nxdomain no; # conform to RFC1035 notify no;

};

Listing 14: DNS-Server-Zonenkonfigurationsdatei /etc/bind/db.bsitomcat.de:;; BIND data file for local bsitomcat.de. test domain;$TTL 604800;@ IN SOA tomcathost.bsitomcat.de. postmaster.bsitomcat.de. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; local name serverbsitomcat.de. IN NS localhost.;; hosts managed by our bsitomcat.de. dns server;



tomcathost.bsitomcat.de. IN A 192.168.118.101debian-host1.bsitomcat.de. IN A 192.168.118.101template.bsitomcat.de. IN A 192.168.118.100

Listing 15: DNS-Server-Zonenkonfigurationsdatei /etc/bind/db.external.de:;; BIND data file for local external.de. test domain;$TTL 604800;@ IN SOA tomcathost.bsitomcat.de. postmaster.bsitomcat.de. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; local name serverexternal.de. IN NS localhost.;; hosts managed by our external.de. dns server;bigmama.external.de. IN A 192.168.118.1gateway.external.de. IN A 192.168.118.2

Listing 16: DNS-Server-Reverse-Zonenkonfigurationsdatei /etc/bind/db.192.168.118:;; BIND data file for local bsitomcat.de. test domain;$TTL 604800;118.168.192.in-addr.arpa. IN SOA tomcathost.bsitomcat.de. postmaster.bsitomcat.de. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; local name server;118.168.192.in-addr.arpa. IN NS tomcathost.bsitomcat.de.;; hosts managed by our bsitomcat.de. dns server;101.118.168.192.in-addr.arpa. IN PTR tomcathost.bsitomcat.de.100.118.168.192.in-addr.arpa. IN PTR template.bsitomcat.de.1.118.168.192.in-addr.arpa. IN PTR bigmama.external.de.2.118.168.192.in-addr.arpa. IN PTR gateway.external.de.

Listing 17: Konfigurationsdatei zur Namensauflösung /etc/resolv.conf:search bsitomcat.denameserver 192.168.118.101




Nach Einrichtung der Konfiguration kann der DNS-Server mit Hilfe des Kommandos /etc/init.d/named restart aktiviert werden.

3.9 Werkzeuge für Penetrationstests

Die in diesem Dokument beschriebenen Penetrationstests werden mit Hilfe frei und kostenlos verfügbarer Werkzeuge durchgeführt. Diese Werkzeuge und deren Installation werden hier beschrieben.

3.9.1 SPIKE

SPIKE ist ein frei verfügbares Fuzz-Testing-Werkzeug, mit dem bereits viele Implementierungsschwachstellen in Softwareprodukten entdeckt wurden.

SPIKE arbeitet nach dem Prinzip des Fuzz-Testing. Einer Software-Komponente werden viele unterschiedliche Parameter übergeben, die inhaltlich stark von gewöhnlichen Parametern abweichen. Die Übergabeparameter sind dabei sowohl sehr lange Zeichenketten, Zeichenketten mit Sonderzeichen und definierten Sonderzeichenkombinationen sowie sehr große positive oder negative Zahlen.

Auch wenn man mit dem Funktionsprinzip von SPIKE (Fuzz-Testing) nicht alle Schwachstellen in Software-Produkten finden kann, so stellt die Verwendung von SPIKE dennoch eine gute Ergänzung innerhalb von Sicherheitsuntersuchungen, beispielsweise bei einer Source-Code-Analyse, dar.

Bezugsquelle

Zur Zeit der Penetrationstests war die Version 2.9 des SPIKE-Toolsets aktuell.

SPIKE wird von der amerikanischen IT-Security Firma ImmunitySec hergestellt und kann im Internet23§ bezogen werden.

Installation

SPIKE wurde unterhalb des Ordners /root/bsi_tomcat installiert:

debian-template:~/bsi_tomcat/pentests# tar zxf /tmp/SPIKE2.9.tgz.gzdebian-template:~/bsi_tomcat/pentests# cd SPIKE/SPIKE/src/debian-template:~/bsi_tomcat/pentests/SPIKE/SPIKE/src# ./configure && make

3.9.2 Benutzung von SPIKE

Für die Verwendung von SPIKE als Fuzz-Tester bei HTTP-Protokollen wird die Erzeugung des SPIKE-Programms durch das Werkzeug makewebfuzz.pl erleichtert. Die einzelnen Schritte für das Fuzz-Testing teilen sich in die folgenden Punkte auf:

• Netzwerkmitschnitt als Datei abspeichern,

• SPIKE-Programm erzeugen,

23http://www.immunitysec.com/downloads/SPIKE2.9.tgz


http://www.immunitysec.com/downloads/SPIKE2.9.tgz

http://www.immunitysec.com/downloads/SPIKE2.9.tgz


• SPIKE-Programm kompilieren und

• SPIKE-Programm ausführen.

Netzwerkmittschnitt

Voraussetzung für die Benutzung von SPIKE ist ein vorhandener Netzwerkmitschnitt des zu untersuchenden Netzwerkdienstes. Ein beispielhafter Netzwerkmitschnitt ist in Abbildung 3.4 dargestellt.

Abbildung 3.4: Netzwerkmitschnitt einer HTTP-Anfrage

Übersetzung zum C-Programm

Mit dem SPIKE-Werkzeug makewebfuzz.pl wird nun aus dem Netzwerkmitschnitt automatisch eine Datei mit C-Source-Code erzeugt. Diese Datei trägt den Namen webfuzz.c und wird nach individueller Anpassung übersetzt und zur Ausführung gebracht.

Unter der Voraussetzung, dass der HTTP-Netzwerkmitschnitt als Datei request.txt abgespeichert wurde, lautet der Befehl zur Erzeugung des SPIKE Programms webfuzz.c folgendermaßen:

SPIKE_HOME=/root/bsi_tomcat/pentest/SPIKE/SPIKE/srccd $SPIKE_HOME./makewebfuzz.pl request.txt >webfuzz.c




Der nachfolgende Source-Code zeigt einen Ausschnitt aus der Datei webfuzz.c, aus dem deutlich wird, wie man die Eigenschaften der einzelnen Bestandteile des Netzwerkprotokolls entweder als Variable oder als Konstante definieren kann. Variable Teile werden im Rahmen des Fuzz-Testings, in vielen Wiederholungen mit verschiedenen Inhalten gefüllt, konstante Teile jedoch nicht verändert.

.../*end webfuzzprelude.c */s_setfirstvariable();s_string("GET ");s_string("/simple_info1/index.jsp");s_string(" HTTP/1.1");s_string("\r\n");s_string("Host: localhost\r\n");s_string("User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050825 Firefox/1.0.4 (Debian package 1.0.4-2sarge3\r\n");s_string("Accept: ");s_string("text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.0");s_string("\r\n");s_string("Accept-Language: en-us,en;q=0.0\r\n");s_string("Accept-Encoding: gzip,deflate\r\n");s_string("Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.0\r\n");s_string("Connection: close\r\n");s_string("Authorization: "); s_string_variable("Basic bWVtd3VzZXI6dm13YXJl"); s_string("\r\n");s_string("Pragma: no-cache\r\n");s_string("Cache-Control: no-cache\r\n");s_string("\r\n");/*Done with Headers*/s_string("\r\n");s_block_start("post");s_setfirstvariable();s_block_end("post");/* Start webfuzzpostlude.c */

if (spike_send_tcp(target,port)==0) { printf("Couldn't connect to host or send data!\r\n"); /*exit(-1);*/...

Kompilation des C-Programms / Durchführen des Fuzz Testing

Ist das Programm webfuzz.c so angepasst, wie man es für den jeweiligen Test benötigt, so wird das Programm kompiliert und zur Ausführung gebracht.

SPIKE_HOME=/root/bsi_tomcat/pentest/SPIKE/SPIKE/srccd $SPIKE_HOMEgcc -o webfuzz -I ../include/ spike.o listener.o hdebug.o tcpstuff.o spike_dcerpc.o base64.o udpstuff.o spike_oncrpc.o webfuzz.c./webfuzz localhost 80 >ergebnis.txt

In diesem Beispiel wird das Ergebnis der Fuzz-Tests in der Datei ergebnis.txt abgelegt.



3.9.3 Ethereal

Zum Erstellen der Netzwerkmitschnitte wurde das Programm Ethereal verwendet. Abbildung 3.5 zeigt eine beispielhafte Konfiguration von ethereal zum Mitschneiden des Netzwerkverkehrs auf Port 80/tcp (HTTP).

Abbildung 3.5: Konfiguration von Ethereal für das Mitschneiden von HTTP

3.9.4 OpenSSL

OpenSSL wird verwendet, um automatisiert SSL-verschlüsselte HTTP-Anfragen, im Folgenden HTTPS-Anfragen genannt, an den Webserver zu stellen.

Die folgende Befehlskette führt eine automatisierte HTTPS-Anfrage durch.

echo -e „GET / HTTP/1.0\r\n\r\n“ | openssl s_client -connect localhost:443 -quiet 2>/dev/null

Die Zeichenkette „GET / HTTP/1.0 <zweimal Zeilenumbruch>“ ist die eigentliche HTTP-Anfrage, die in SSL getunnelt wird. Der Parameter „localhost:443“ ist der Hostname und die Port-Nummer, unter welcher der SSL Webserver ansprechbar ist.




Für die HTTPS-Anfragen, die während der Tests durchgeführt wurden, musste sich der HTTPS-Client mit einem SSL-Client-Zertifikat am SSL-Webserver authentisieren. Dies wurde durch folgendes Shell-Script umgesetzt.

#!/bin/bashecho -e "GET /simple_info1/index.jsp HTTP/1.0\r\n\r\n"|openssl s_client \ -connect localhost:443 -cert memuser10.pem \ -key memuser10.key \ -CAfile /root/bsitomcat_ca/ssl/ca/ca.pem \ -quiet

3.10 Werkzeuge für statische Tests

Unter statischen Tests werden diejenigen verstanden, bei denen es im Gegensatz zu dynamischen Tests nicht zur Ausführung der untersuchten Software kommt. Source-Code-Reviews und die Programmanalyse gehören zu den Methoden des statischen Testen, Penetrationstests zu denen des dynamischen Testen.

3.10.1 Flawfinder und Splint für C

Sowohl flawfinder und splint sind in Debian als Pakete enthalten und werden daher beispielsweise über aptitude installiert.

Beide lassen sich von der Kommandozeile aus aufrufen. Angenehmer wird deren Einsatz jedoch innerhalb des Texteditors emacs, weil dann die monierten Zeilen des Quellcode mit einem Mausklick angesprungen und begutachtet werden können. Die nächste Abbildung



zeigt ein Anwendungsbeispiel:

Abbildung 3.6: splint, angewendet auf eine Datei, innerhalb von Emacs




Diese Erleichterung erreicht man unter Verwendung des Compile-Modus von Emacs:

C-u M-x compile

Daraufhin ersetzt man den Vorschlag (den Aufruf von make) durch beispielsweise:

splint +unixlib "-Du_int8_t=unsigned char" "-Du_int16_t=unsigned short" "-Du_int32_t=unsigned int" -DJK_PRODUCTION=1 jk_ajp14.c

3.10.2 Findbugs für Java

Die wenigsten Werkzeuge sind fähig, unterschiedliche Programmiersprachen zu analysieren.

Quellcode in Java lässt sich auch mit emacs, ergänzt durch spezielle Hilfspakete, bearbeiten. Manche werden jedoch die spezialisierte grafische Entwicklungsumgebung Eclipse24 vorziehen. Diese bietet viele winzige Schaltflächen und Aktionen, mit denen beispielsweise die Signatur einer Methode, die aktuelle Superklasse der Vererbungshierarchie oder auch die Kurzdokumentation zur Methode unter dem Mauszeiger eingeblendet werden können.

Darüberhinaus stellt Eclipse Erweiterungsmechanismen zur Einbettung unabhängiger Module bereit. So unterstützt Eclipse nicht nur Java, sondern auch die Programmiersprache C++. Insbesondere aber lässt sich das Werkzeug findbugs25 in die Benutzeroberfläche von Eclipse integrieren. Daraufhin werden dessen Meldungen im gleichen Fenster angezeigt wie die sonstigen Meldungen des Java-Compilers. Dies zeigt folgende Abbildung:

24 http://www.eclipse.org/ 25 http://findbugs.sourceforge.net/


http://findbugs.sourceforge.net/

http://www.eclipse.org/


Abbildung 3.7: Meldungen von Findbugs innerhalb von Eclipse

Wir haben Eclipse in der während des Projekts aktuellen Version 3.1.1 direkt aus dem Internet26 bezogen, anstatt die in Debian enthaltene Version 3.0 zu verwenden. Aufgrund verschiedener in der Version 3.0 enthaltener Fehler können wir derzeit nur den Einsatz der Version 3.1 oder 3.1.1 empfehlen. Installiert wurde daraufhin nicht in ein zentrales Verzeichnis, sondern in ein Benutzerverzeichnis wie $HOME/eclipse/.

Findbugs wird in Eclipse installiert, indem das Archiv de.tobject.findbugs_0.0.17.rc1.zip27

entgegen der Dokumentation nicht in das Verzeichnis eclipse/, sondern in das Unterverzeichnis eclipse/plugins/ extrahiert wird. Daraufhin erkennt Eclipse beim nächsten Start das Plugin und es kann in das Projekt einbezogen werden.

Die nächste Abbildung zeigt, wie Findbugs gemäß dessen Dokumentation aktiviert wird. Innerhalb des Projektmenüs erscheint eine zusätzliche Schaltfläche.

26 http://www.eclipse.org/downloads/index.php 27 http://sourceforge.net/project/showfiles.php?group_id=96405 Stichwort Eclipse Plugin


http://sourceforge.net/project/showfiles.php?group_id=96405

http://www.eclipse.org/downloads/index.php



Abbildung 3.8: Menü Projekt → Properties → FindBugs

Es gibt noch weitere Werkzeuge für die Code-Analyse speziell für Java. Die meisten begnügen sich jedoch mit syntaktischen Analysen und Aufbereitungen. Datenflussanalysen kommen leider selten vor. Ein Beispiel einer einfachen Analyse ist das Erkennen von leeren Catch-Blöcken im Programmcode. Dessen Vorkommen weist auf fragwürdiges Exception-Handling hin, denn damit werden die Fehlermeldungen des betroffenen Teils des Programms einfach unterdrückt und die Fehler bleiben so unerkannt.

Dennoch soll das einigermaßen beliebte Werkzeug pmd28 erwähnt werden. Auch dieses Werkzeug kann helfen, Fehler in Programmen zu finden. Da wir bei unseren Sicherheitsanalysen aber eher an tiefer gehenden Analysen interessiert waren, kam dieses Werkzeug im Projekt nicht zum Einsatz.

pmd arbeitet auf Ebene des Quellcode in Java, während findbugs den erzeugten Bytecode, also die .class-Dateien und auch die .jar-Archive für die JVM analysiert. Dies lässt unterschiedliche Anwendungsgebiete zu, die hier jedoch nicht von Bedeutung sind.

28 http://pmd.sourceforge.net /


http://pmd.sourceforge.net/


3.10.3 Java-Dokumentation

Für die Zwecke des Software-Review ist es ganz nützlich, die Dokumentation zum Java SDK ebenfalls zu installieren. Die gleiche Dokumentation ist ebenfalls online erreichbar29. Das nach Akzeptieren der Lizenzvereinbarung von Sun zum Download bereitgestellte Paket30 ist enorm groß (ca. 50 MB an Dokumentation, gepackt), dennoch sind in den HTML-Seiten zahlreiche Querverweise auf weitere Dokumente auf dem Webserver von Sun zu Java31

enthalten. Die Dokumentation zu den zahlreichen APIs ist nach Installation vollständig lokal verfügbar und enthält ebenfalls nützliche Dokumente zu JCE, JSSE, JAAS.

Hinweis: Eclipse ist selbst ohne dieses Paket in der Lage, zu zahlreichen Methoden die Kurzdokumentation einzublenden.

Darüber hinaus wurden für das Software-Review noch zahlreiche Online-Quellen verwendet, darunter die Online-Dokumentation zum Apache httpd32, zum Apache Portable Runtime (APR)33 und zu commons-logging für Java (JCL)34.

29 http://java.sun.com/j2se/1.5.0/docs/index.html 30 http://java.sun.com/j2se/1.5.0/download.jsp#docs 31 http://java.sun.com/ 32 http://httpd.apache.org/docs/2.0/developer/ sowie http://docx.webperf.org/group__APACHE__CORE__LOG.html 33 http://apr.apache.org/docs/apr/globals.html 34 http://jakarta.apache.org/commons/logging/


http://jakarta.apache.org/commons/logging/

http://apr.apache.org/docs/apr/globals.html

http://docx.webperf.org/group__APACHE__CORE__LOG.html

http://httpd.apache.org/docs/2.0/developer/

http://java.sun.com/

http://java.sun.com/j2se/1.5.0/download.jsp#docs

http://java.sun.com/j2se/1.5.0/docs/index.html


Einrichtung der Authentisierungsinformationen

4. Einrichtung der Authentisierungsinformationen

4.1 Einrichtung von Test-Benutzerkonten auf Betriebssystemebene

Um die verschiedenen Tests nicht als Benutzer root durchführen zu müssen, werden mit Hilfe des Skriptes install_dusers.sh zwei Benutzer duser1 und duser2, jeweils mit dem Login-Passwort vmware, auf der Betriebssystemebene eingerichtet. Von diesen Benutzerkonten aus können die verschiedenen Webanwendungen per Browser aufgerufen werden, wobei je nach Test-Szenario verschiedene Web-Identitäten zum Einsatz kommen können, deren Einrichtung im folgenden Abschnitt beschrieben ist.

4.2 Einrichtung von Test-Benutzerkonten für die Web-Authentisierung

Zum Test der verschiedenen Web-Authentisierungsvarianten wird ein konsistentes Web-Benutzer-Schema verwendet. In eckigen Klammern [] sind dabei die im Feinkonzept [TomcatFein.] der Projektphase 1 sowie in den nachfolgenden Tabellen der durchgeführten Tests verwendete Kurzbezeichnung mit aufgeführt:

• Memory Realm [User]

• JDBC Realm in Verbindung mit einer MySQL-Datenbank [JDBC]

• JNDI Realm in Verbindung mit einem OpenLDAP-Server [JNDI]

Hierbei werden für jede Authentikationsvariante die Nutzer

• admin (Rolle: admin)

• manager (Rolle: manager)

• user1 (Rolle: user1)

• user2 (Rolle: user2)

eingerichtet, wobei dem Web-Benutzernamen der Realm-Typ

• mem: für Memory Realm

• jdbc: für JDBC Realm

• jndi: für JNDI Realm

vorangestellt wird. Die Rollen admin bzw. manager werden in Verbindung mit den den Tomcat-Administrationsanwendungen aus dem jakarta-tomcat-5.5.9-admin.tar.gz Paket benötigt.

Zum Test der Unterscheidung von Klartext-Passworten und Digest-Passworten, die per MD5-Digest aus den Klartext-Passworten gewonnen werden, wird bei den Benutzern mit Digest-Passworten die Benutzernamenserweiterung hash angehängt. Somit erhält man folgendes Benutzer-Schema:


Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des ApacheJakarta Tomcat Servlet Containers

Benutzeradmin manager user1 user2

Realm

mem memadmin

memadminhash

memmanager

memmanagerhash

memuser1

memuser1hash

memuser2

memuser2hashjdbc jdbcadmin

jdbcadminhash

jdbcmanager

jdbcmanagerhash

jdbcuser1

jdbcuser1hash

jdbcuser2

jdbcuser2hashjndi jndiadmin

jndiadminhash

jndimanager

jndimanagerhash

jndiuser1

jndiuser1hash

jndiuser2

jndiuser2hash

Tabelle 1 Verfügbare Benutzer für die verschiedenen Authentisierungsvarianten

Zur Vereinfachung der Tests wird für alle Benutzer einheitlich das Passwort vmware verwendet. Dies entspricht einem in Verbindung mit dem <Realm>-Attribut digest=“MD5“ verwendeten MD5-Digest-Wert von 92963abd36c896b93a36b8e296ff3387, der mit dem Kommando

$CATALINA_HOME/bin/digest.sh -a MD5 vmware

erzeugt wurde. In der vorliegenden Testumgebung sind zwar alle Kombinationen vorhanden, in Abhängigkeit von dem jeweils gesetzten bzw. nicht gesetzten <Realm>-Attribut digest=“MD5“ in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml sind aber jeweils nur die Digest-User / -Passworte Non-Digest-User / -Passworte verwendbar. Für die Tests wurde eine server.xml Datei erzeugt, deren unterschiedliche Abschnitte bezüglich der Authentisierung durch XML-Kommentare  aktiviert bzw. deaktiviert werden können. Nach einer Änderung ist der Tomcat Servlet Container neu zu starten. Außerdem muss gewährleistet sein, dass der OpenLDAP-Daemon slapd bzw. die MySQL-Datenbank (mysqld) aktiv sind und die Datenbanken mit entsprechenden Benutzerinformationen gefüllt sind, wenn auf diesem Weg eine Authentisierung erfolgen soll.

Für CLIENT-CERT-basierte Authentisierung sind darüber hinaus noch Einträge für zugelassene Zertifikate und deren Rollenzuordnung in der Datei tomcat_users.xml zu erzeugen (s. hierzu S. 78).

4.3 Initialisierung der tomcat_users.xml Datei

Für eine Memory Realm-basierte Authentisierung wird die folgende Datei $CATALINA_HOME/conf/tomcat_users.xml verwendet:

Listing 18: Tomcat-Benutzer-Definitionsdatei tomcat_users.xml:<?xml version='1.0' encoding='utf-8'?><tomcat-users> <role rolename="admin"/> <role rolename="manager"/> <role rolename="user1"/> <role rolename="user2"/> <user username="memadmin" password="vmware" roles="admin"/> <user username="memadminhash" password="92963abd36c896b93a36b8e296ff3387" roles="admin"/> <user username="memmanager" password="vmware" roles="manager"/>




<user username="memmanagerhash" password="92963abd36c896b93a36b8e296ff3387" roles="manager"/> <user username="memuser1" password="vmware" roles="user1"/> <user username="memuser1hash" password="92963abd36c896b93a36b8e296ff3387" roles="user1"/> <user username="memuser2" password="vmware" roles="user2"/> <user username="memuser2hash" password="92963abd36c896b93a36b8e296ff3387" roles="user2"/></tomcat-users>

4.4 Initialisierung der MySQL-Datenbank mit den Authentisierungsinformationen

Zur Erstellung der zur JDBC Realm-basierten Authentisierung benötigten Datenbank, die Tabellen und Tabelleninhalte im MySQL-DBMS wird das Skript mysql_init_db.sql verwendet, das aus der MySQL-Kommandozeile per

mysql> source mysql_init_db.sql

ausgeführt wird. Darin werden die benötigte Datenbank, die einzelnen Tabellen, deren Tabelleninhalte sowie die Benutzer-Zugriffsberechtigungen auf diese Inhalte definiert.

Listing 19: MySQL-Initialisierungsdatei mysql_init_db.sql############################################################# MySQL setup script for# JDBC based web application authentication############################################################

############################################################# setup the database############################################################

create database authority;

use authority;

############################################################# define the record structure# (we use 35 characters for all elements to allow for# storing MD5 hashes)############################################################

create table users ( user_name varchar(35) not null primary key, user_pass varchar(35) not null);

create table user_roles ( user_name varchar(35) not null, role_name varchar(35) not null, primary key (user_name, role_name));

############################################################# populate the users table with the predefined examples############################################################



insert into users (user_name,user_pass) values ('jdbcadmin','vmware'), ('jdbcadminhash','92963abd36c896b93a36b8e296ff3387'), ('jdbcmanager','vmware'), ('jdbcmanagerhash','92963abd36c896b93a36b8e296ff3387'), ('jdbcuser1','vmware'), ('jdbcuser1hash','92963abd36c896b93a36b8e296ff3387'), ('jdbcuser2','vmware'), ('jdbcuser2hash','92963abd36c896b93a36b8e296ff3387');

############################################################# populate the user_roles table############################################################

insert into user_roles (user_name,role_name) values ('jdbcadmin','admin'), ('jdbcadminhash','admin'), ('jdbcmanager','manager'), ('jdbcmanagerhash','manager'), ('jdbcuser1','user1'), ('jdbcuser1hash','user1'), ('jdbcuser2','user2'), ('jdbcuser2hash','user2');

############################################################# setup a user to perform JDBC queries############################################################

grant update,select on authority.* to [email protected] identified by "jdbcpass";

############################################################# report the current table setups############################################################

select * from authority.users;

select * from authority.user_roles;

select * from mysql.db;

############################################################# -- eof --############################################################

4.5 Initialisierung der LDAP-Datenbank mit den Authentisierungsinformationen

Basierend auf den bei der Installation des Betriebssystems gemachten LDAP-Konfigurationsangaben (s. S. 25) werden die Informationen für eine JNDI Realm-basierte Authentisierung in die LDAP-Datenbank aufgenommen. Hierfür wurde das Skript setup_openldap.sh erstellt, das die LDAP-Datenbank neu anlegt:

Listing 20: LDAP-Initialisierungsskript setup_openldap.sh#!/bin/bash############################################################# setup_openldap.sh############################################################




# reinitialize the LDAP databaseOPENLDAP_LIB_DIR=`egrep -e "^directory" /etc/ldap/slapd.conf | cut -f 2 -d \"`

if [ -z "$OPENLDAP_LIB_DIR" ] || [ ! -d $OPENLDAP_LIB_DIR ] ; then echo "#E# OPENLDAP_LIB_DIR undefined or not existing" exit 1fi

echo "#I# stopping slapd"/etc/init.d/slapd stop

echo "#I# Purging OpenLDAP OPENLDAP_LIB_DIR $OPENLDAP_LIB_DIR"

echo "#I# removing existing directory"rm -rf $OPENLDAP_LIB_DIR

echo "#I# recreate OpenLDAP database"mkdir $OPENLDAP_LIB_DIRslapadd -v -l openldap_debian_init.ldifslapadd -v -l openldap_init.ldif

echo "#I# restarting slapd"/etc/init.d/slapd start

############################################################# -- eof --############################################################

Dieses Skript verwendet die in der Datei openldap_init.ldif eingetragen Benutzer- und Rollendefinitionen:

Listing 21: LDAP-Benutzer- bzw. Rollendefinitionsdatei openldap_init.ldif############################################################# Initialization LDIF file for# JNDI based web application authentication############################################################

############################################################# Define an entry to contain people## Searches for users are based on this entrydn: ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: organizationalUnitou: people

#-----------------------------------------------------------# define entries for every user#-----------------------------------------------------------

# Define a user entry for "jndiadmin"dn: uid=jndiadmin,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: inetOrgPersonuid: jndiadminsn: jndiadmincn: jndiadminuserPassword: vmware

# Define a user entry for "jndiadminhash"dn: uid=jndiadminhash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: inetOrgPersonuid: jndiadminhash



sn: jndiadminhashcn: jndiadminhashuserPassword: 92963abd36c896b93a36b8e296ff3387

# Define a user entry for "jndimanager"dn: uid=jndimanager,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: inetOrgPersonuid: jndimanagersn: jndimanagercn: jndimanageruserPassword: vmware

# Define a user entry for "jndimanagerhash"dn: uid=jndimanagerhash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: inetOrgPersonuid: jndimanagerhashsn: jndimanagerhashcn: jndimanagerhashuserPassword: 92963abd36c896b93a36b8e296ff3387

# Define a user entry for "jndiuser1"dn: uid=jndiuser1,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: inetOrgPersonuid: jndiuser1sn: jndiuser1cn: jndiuser1userPassword: vmware

# Define a user entry for "jndiuser1hash"dn: uid=jndiuser1hash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: inetOrgPersonuid: jndiuser1hashsn: jndiuser1hashcn: jndiuser1hashuserPassword: 92963abd36c896b93a36b8e296ff3387

# Define a user entry for "jndiuser2"dn: uid=jndiuser2,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: inetOrgPersonuid: jndiuser2sn: jndiuser2cn: jndiuser2userPassword: vmware

# Define a user entry for "jndiuser2hash"dn: uid=jndiuser2hash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: inetOrgPersonuid: jndiuser2hashsn: jndiuser2hashcn: jndiuser2hashuserPassword: 92963abd36c896b93a36b8e296ff3387

############################################################# Define an entry to contain LDAP groups## Searches for roles are based on this entrydn: ou=groups,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: organizationalUnitou: groups

#-----------------------------------------------------------# define entries for every role#-----------------------------------------------------------




# Define an entry for the "admin" roledn: cn=admin,ou=groups,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: groupOfUniqueNamescn: adminuniqueMember: uid=jndiadmin,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deuniqueMember: uid=jndiadminhash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de

# Define an entry for the "manager" roledn: cn=manager,ou=groups,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: groupOfUniqueNamescn: manageruniqueMember: uid=jndimanager,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deuniqueMember: uid=jndimanagerhash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de

# Define an entry for the "user1" roledn: cn=user1,ou=groups,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: groupOfUniqueNamescn: user1uniqueMember: uid=jndiuser1,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deuniqueMember: uid=jndiuser1hash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de

# Define an entry for the "user2" roledn: cn=user2,ou=groups,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: groupOfUniqueNamescn: user2uniqueMember: uid=jndiuser2,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=deuniqueMember: uid=jndiuser2hash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de

############################################################# -- eof --############################################################

Diese Definitionen ergänzen die bei der Installation des Betriebssystems zur Konfiguration von slapd gemachten Angaben (s. S. 25). Die initiale LDAP-Konfiguration wird zuvor mit dem Kommando

slapcat > openldap_debian_init.ldif

für ein mögliches künftiges erneutes Aufsetzen der OpenLDAP-Datenbank unmittelbar nach der Erstinstallation und -konfiguration des Betriebssystems, also noch vor der Einbringung der Informationen aus der o. g. Datei openldap_init.ldif, in die Datei openldap_debian_init.ldif gesichert und hat folgenden Inhalt:

Listing 22: LDAP-Inhalt aus Betriebssysteminstallation openldap_debian_init.ldifdn: dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: topobjectClass: dcObjectobjectClass: organizationo: BSI-Tomcat TSI ITC-Securitydc: bsitomcatstructuralObjectClass: organizationentryUUID: 449e0962-ca90-1029-9b2b-fe9c288508ddcreatorsName: cn=anonymousmodifiersName: cn=anonymouscreateTimestamp: 20051006083809ZmodifyTimestamp: 20051006083809ZentryCSN: 20051006083809Z#000001#00#000000



dn: cn=admin,dc=bsitomcat,dc=tsi-itcsec,dc=deobjectClass: simpleSecurityObjectobjectClass: organizationalRolecn: admindescription: LDAP administratoruserPassword:: e2NyeXB0fVdXOVBDYTJnMXVyRVU=structuralObjectClass: organizationalRoleentryUUID: 44a3814e-ca90-1029-9b2c-fe9c288508ddcreatorsName: cn=anonymousmodifiersName: cn=anonymouscreateTimestamp: 20051006083809ZmodifyTimestamp: 20051006083809ZentryCSN: 20051006083809Z#000002#00#000000

Hinweis: Zur Vereinfachung der Durchführung der Tests mit einer vereinfachten manuellen Änderung von Passworten werden sämtliche Passworte im Klartext gespeichert. Für den Einsatz in einer Wirkumgebung wird empfohlen, neben geeigneten Zugriffsberechtigungen auf die Passwortinformationen durch die Verwendung geeigneter LDAP Access Control Listen (ACL) Einträge die Passworte nur als Hashwert in der Datenbank abzulegen. Für die JNDI-Authentisierung hat dies keine Folge, da das von Tomcat an den OpenLDAP Server weitergereichte Passwort dann ggf. vor einem Vergleich mit dem in der Datenbank gespeicherten Wert gleichfalls in einen Hashwert umgesetzt wird.

4.6 Konfiguration des LDAP-Browsers gq

Zur Durchführung von späteren Änderungen an den Authentisierungsinformationen in der LDAP-Datenbank wird der gq LDAP-Browser verwendet, der für eine Verbindung mit dem LDAP-Server wie folgt konfiguriert wird:

Nach dem Start von gq wird die Konfiguration über das Menü File → Preferences, Reiter Server mit den in Abschnitt 2.2 bei der Konfiguration des LDAP-Servers angegebenen Parametern vorgenommen:




Abbildung 4.1.: Allgemeine Einstellungen zum LDAP-Server

Zur Änderung von Passworten erfolgt die Anmeldung als LDAP-Administrator an den LDAP-Server mit dem BIND-DN cn=admin,dc=bsitomcat,dc=tsi-itcsec,dc=de .



Abbildung 4.2.: Verbindungseinstellungen zum LDAP-Server

Über den „Browse“ Reiter im Hauptfenster kann nun eine Verbindung zum LDAP-Server durchgeführt werden, wobei das konfigurierte Passwort für den LDAP-Administrator vmware zu verwenden ist.

Abbildung 4.3.: In der LDAP-Datenbank gespeicherte Informationen zu einem Benutzer




Mit Hilfe des gq LDAP-Browsers können nun die benötigten Änderungen vorgenommen werden.

4.7 Erzeugung einer CA und Generierung von SSL-Server- und Client-Zertifikaten

Für die Zertifikat-basierte Client-Authentisierung werden entsprechende Zertifikate benötigt, die im Webbrowser zu installieren sind. Diese Zertifikate sind von einer Certification Authority (CA) zu signieren, mit der die Webanwendungen in einer Vertrauensbeziehung stehen. Um die von der eigenen CA signierten Zertifikate (z. B. Client-Zertifikate) überprüfen zu können, ist das Zertifikat der CA mit dem JAVA keytool in den JAVA Zertifikatspeicher $JAVA_HOME/jre/lib/security/cacerts zu importieren (mit dem Default-Passwort des Zertifikatspeichers changeit). Die nachfolgend beschriebenen Shell-Scripts werden der Einfachheit halber vom Benutzer root ausgeführt.

Üblicherweise erzeugt ein Benutzer selbst sein Client-Zertifikat-Request, reicht dieses Zertifikat dann zusammen mit den für die Zertifizierung notwendigen Authentisierungsdokumenten bei der CA zur Signierung ein und erhält das signierte Zertifikat zum Import in verschiedene Applikationen wie z. B. den Webbrowser zurück.

4.7.1 Installation einer Certification Authority (CA)

Die Installation einer einfachen CA für die hier durchzuführenden Tests erfolgt mit dem Skript setup_ca.sh.

Listing 23: CA-Installationsskript setup_ca.sh#!/bin/bash -x################################################################ setup a private CA for issueing user certificates# used for certificate based user authentication###############################################################

## some global setups

export CA_ROOT=/root/bsitomcat_ca

export JAVA_HOME="/opt/jdk1.5.0_05"export JRE_HOME="/opt/jdk1.5.0_05/jre"export CATALINA_HOME="/opt/jakarta-tomcat-5.5.9"export CATALINA_BASE="/opt/jakarta-tomcat-5.5.9"

CA_DIR=${CA_ROOT}/ssl/caSSL_SERVER_DIR=${CA_ROOT}/ssl/serverCLIENT_DIR=${CA_ROOT}/ssl/client

CA_PASSWORD=vmwareCACERTS_PASSWORD=changeit

#--------------------------------------------------------------mkdir -p $CA_ROOTcd $CA_ROOT

# remove data from previous installationsrm -rf ssl



################################################################ SETTING UP YOUR CA###############################################################

#--------------------------------------------------------------# Create directories to hold your CA keys, your SSL server keys and,# if you want to use SSL client authentication, your client keys. For# the sake of argument let's assume that these directories are called# "${CA_DIR}", "${SSL_SERVER_DIR}" and "${CLIENT_DIR}".

mkdir -p ${CA_DIR} ${SSL_SERVER_DIR} ${CLIENT_DIR}

#--------------------------------------------------------------# Create a private key and certificate request for your own CA:

openssl req -new -newkey rsa:1024 \ -subj "/CN=BSITomcat ITC-Sec CA/L=Bonn/ST=NRW/C=DE/[email protected]/O=BSITomcat ITC-Sec Certification Authority" \ -days 3650 \ -passout pass:${CA_PASSWORD} \ -out ${CA_DIR}/ca.csr \ -keyout ${CA_DIR}/ca.key

#--------------------------------------------------------------# Create your CA's self-signed certificate:

openssl x509 -trustout \ -signkey ${CA_DIR}/ca.key \ -passin pass:${CA_PASSWORD} \ -days 3650 \ -req -in ${CA_DIR}/ca.csr \ -out ${CA_DIR}/ca.pem

#--------------------------------------------------------------# Import the CA certificate into the JDK certificate authorities# keystore:

## !! some www research (at http://mindprod.com/jgloss/keytool.html## !! as well as "man keytool", search for 'cacerts keystore')## !! has shown, that $JAVA_HOME/jre/lib/security/cacerts## !! is protected by the password "changeit"

# well, use the actual system wide JDK cacerts keystore# read by Java and tomcat:

# purge old version of our CA certificate - if not available# in the keystore, it will generate an error message:# Keytool-Fehler: java.lang.Exception: Alias <bsitomcat_ca> existiert nicht.echo "#I# Subsequent command may generate error if no old certificat exists"${JAVA_HOME}/bin/keytool -delete \ -keystore $JAVA_HOME/jre/lib/security/cacerts \ -storepass $CACERTS_PASSWORD \ -alias bsitomcat_ca \ -noprompt

# import current version of our CA certificate${JAVA_HOME}/bin/keytool -import \ -keystore $JAVA_HOME/jre/lib/security/cacerts \ -storepass $CACERTS_PASSWORD \ -file ${CA_DIR}/ca.pem \ -alias bsitomcat_ca \ -noprompt

#--------------------------------------------------------------




# Create a file to hold your CA's serial numbers. This file starts# with the number "2":

echo "02" > ${CA_DIR}/ca.srl

# the CA is now ready to sign certificate requests################################################################ -- eof --###############################################################

Das CA-Zertifikat wird für eine weitere Nutzung auch automatisch in den globalen JAVA Zertifikatspeicher installiert. Abhängig von der Nutzung des globalen JAVA Zertifikatspeichers ($JAVA_HOME/jre/lib/security/cacerts) oder des Tomcat-Zertifikatspeichers (definiert mit dem Attribut truststoreFile, z. B. $CATALINA_HOME/conf/truststore) ist bei der Konfiguration des SSL-Connectors in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml folgendes zu beachten:

• Ist das Attribut truststoreFile (ggf. mit truststorePass) definiert, so wird das CA-Zertifikat aus dem Tomcat-Zertifikatspeicher verwendet. Dies muss dort vorhanden sein, da ansonsten eine CLIENT-CERT Authentisierung nicht möglich ist.

• Ist das Attribut truststoreFile (ggf. mit truststorePass) nicht definiert, so wird das CA-Zertifikat aus dem globalen Java-Zertifikatspeicher verwendet.

Beide Fälle wurden durchgespielt, aber letztlich hauptsächlich der Java-Zertifikatspeicher verwendet. Das in Listing 4.6 dargestellte Skript speichert das CA-Zertifikat in den Java-Zertifikatspeicher. Bei Verwendung eines Tomcat-Zertifikatspeichers ist das keytool -import Kommando aus dem Skript entsprechend auf den Tomcat-Zertifikatspeicher anzuwenden.

Mit Hilfe dieser CA-Installation können nachfolgend Server-Zertifikate zur Server-Authentisierung beim Aufbau von SSL-Verbindungen wie auch Client-Zertifikate signiert werden.

4.7.2 Erzeugung eines SSL Server-Zertifikats (Tomcat)

Zur Authentisierung des Webservers wird beim Aufbau einer SSL-Verbindung ein Server-Zertifikat benötigt. Dies wird mit dem Script setup_server_cert.sh durchgeführt und in die Tomcat Installation übertragen. Voraussetzung für das Ausführen dieses Scripts ist das Vorhandensein der im vorigen Schritt generierten CA.

Listing 24: Skript zur Erzeugung eines SSL-Server-Zertifikats setup_server_cert.sh#!/bin/bash -x################################################################ setup a server certificate required for tomcat SSL server# authentication###############################################################







CA_PASSWORD=vmwareWEBSERVER_PASSWORD=vmware

#--------------------------------------------------------------# check, if the required CA is already installed

if [ ! -d ${CA_DIR} ] ; then echo "#E# $0 requires a CA to be installed" echo "#E# Please run setup_ca.sh first" exit 1fi


# remove data from previous installationsrm -rf ${SSL_SERVER_DIR}/{server.crs|server.crt|truststore}

################################################################ SETTING UP YOUR WEB SERVER###############################################################


mkdir -p ${SSL_SERVER_DIR}

#--------------------------------------------------------------# Create a keystore for your web server.

${JAVA_HOME}/bin/keytool -genkey \ -alias tomcat \ -keyalg RSA \ -keysize 1024 \ -keystore ${SSL_SERVER_DIR}/.keystore \ -storetype JKS \ -keypass $WEBSERVER_PASSWORD \ -storepass $WEBSERVER_PASSWORD \ -validity 1000 \ -dname "CN=tomcathost, OU=BSI-Tomcat, O= T-Systems International SSC T&S, L=Bonn, ST=NRW, C=DE"

#--------------------------------------------------------------# Create a certificate request for your web server.

${JAVA_HOME}/bin/keytool -certreq \ -keyalg RSA \ -alias tomcat \ -file ${SSL_SERVER_DIR}/server.csr \ -storepass $WEBSERVER_PASSWORD \ -keystore ${SSL_SERVER_DIR}/.keystore

# You need to edit the certificate request file slightly. Open it up# in a text editor and amend the text which reads "NEW CERTIFICATE# REQUEST" to "CERTIFICATE REQUEST"




sed -e 's/ NEW CERTIFICATE REQUEST/ CERTIFICATE REQUEST/' \ < ${SSL_SERVER_DIR}/server.csr > ${SSL_SERVER_DIR}/server.csr_tmp

mv ${SSL_SERVER_DIR}/server.csr_tmp ${SSL_SERVER_DIR}/server.csr

#--------------------------------------------------------------# Have your CA sign your certificate request:

openssl x509 \ -CA ${CA_DIR}/ca.pem \ -CAkey ${CA_DIR}/ca.key \ -CAserial ${CA_DIR}/ca.srl \ -passin pass:$CA_PASSWORD \ -req \ -in ${SSL_SERVER_DIR}/server.csr \ -out ${SSL_SERVER_DIR}/server.crt \ -days 3650

#--------------------------------------------------------------# Import your signed server certificate into your server keystore:

${JAVA_HOME}/bin/keytool -import \ -alias tomcat \ -storepass $WEBSERVER_PASSWORD \ -keystore ${SSL_SERVER_DIR}/.keystore \ -trustcacerts \ -file ${SSL_SERVER_DIR}/server.crt

# You should see a message "Certificate reply was installed in keystore".#--------------------------------------------------------------# Import your CA certificate into your server truststore:

${JAVA_HOME}/bin/keytool -import \ -alias bsitomcat_ca \ -storepass $WEBSERVER_PASSWORD \ -keystore ${SSL_SERVER_DIR}/truststore \ -trustcacerts \ -file ${CA_DIR}/ca.pem \ -noprompt

# This step is only necessary if you wish to use SSL client# authentication with Tomcat.

#--------------------------------------------------------------# Set up an SSL connector for Tomcat. I assume that you know, or can# find out, how to do this. Open up conf/server.xml in a text editor# and search for the text "keystoreFile". Ensure that the attribute# value is the keystore you've created above.

#--------------------------------------------------------------# distribute the certificates and keys files to the tomcat# installation

cp -p ${SSL_SERVER_DIR}/.keystore ${SSL_SERVER_DIR}/truststore \ ${CATALINA_HOME}/conf

################################################################ -- eof --###############################################################

Das in Tomcat einzubindende Zertifikat befindet sich nach Abarbeitung dieses Skripts schließlich unter $CATALINA_HOME/conf/.keystore und kann bei der Aktivierung des



Tomcat HTTPS-Connectors in der Datei $CATALINA_HOME/conf/server.xml mit dem gewählten Passwort genutzt werden.

Hinweis: Wichtig ist bei der Erzeugung des Server-Zertifikates, dass bei den Eingaben statt eines Inhaber-Namens (Vor- / Nachname) der Hostname des Servers eingetragen wird. Andernfalls gibt der Webbrowser, der eine so konfigurierte Webseite aufruft, eine Warnmeldung aus, dass der Server-Name und der Name des Zertifikatinhabers nicht übereinstimmen.

4.7.3 Erzeugung eines SSL Server-Zertifikats (Apache)

Um HTTPS-Verbindungen zum Apache Webserver öffnen zu können, muss dieser über ein dazu notwendiges Server-Zertifikat zu seiner Authentisierung gegenüber dem Webbrowser verfügen. Zur Durchführung der Authentisierung muss im Webserver auf den jeweils zum Server-Zertifikat gehörigen privaten Schlüssel zugegriffen werden. Weil Tomcat und Apache diese privaten Schlüssel aber in unterschiedlichen Formaten verwenden, zwischen denen es keine Import- / Exportmöglichkeit gibt, wird für den Apache Webserver mit dem Skript setup_apacheserver_cert.sh ein eigenes Server-Zertifikat erzeugt:

Listing 25: Skript zur Erzeugung eines SSL-Server-Zertifikats setup_apacheserver_cert.sh#!/bin/bash -x################################################################ setup a server certificate required for Apache SSL server# authentication###############################################################




export HTTPD_HOME="/opt/httpd-2.0.54"


CA_PASSWORD=vmware


if [ ! -d ${CA_DIR} ] ; then echo "#E# $0 requires a CA to be installed" echo "#E# Please run setup_ca.sh first" exit 1fi


# remove data from previous installationsrm -rf ${SSL_SERVER_DIR}/apache*




################################################################ SETTING UP YOUR WEB SERVER###############################################################


mkdir -p ${SSL_SERVER_DIR}

#--------------------------------------------------------------# Create a certificate request for your apache web server.openssl req -new \ -newkey rsa:2048 \ -nodes \ -out ${SSL_SERVER_DIR}/apache_ssl.csr \ -keyout ${SSL_SERVER_DIR}/apache_ssl.key \ -subj "/CN=tomcathost/L=Bonn/ST=NRW/C=DE/emailAddress=${CLIENT}@bsitomcat.de/O=BSITomcat ITC-Sec"

#--------------------------------------------------------------# Have your CA sign your certificate request:

openssl x509 \ -CA ${CA_DIR}/ca.pem \ -CAkey ${CA_DIR}/ca.key \ -CAserial ${CA_DIR}/ca.srl \ -passin pass:$CA_PASSWORD \ -req \ -in ${SSL_SERVER_DIR}/apache_ssl.csr \ -out ${SSL_SERVER_DIR}/apache_ssl.crt \ -days 3650

#--------------------------------------------------------------# Import your# - CA certificate# - signed server certificate# - server key# into the respective directories to allow for client certificate# based client authentication and for SSL server authentication

mkdir -p ${HTTPD_HOME}/conf/ssl.key ${HTTPD_HOME}/conf/ssl.crt \ ${HTTPD_HOME}/conf/ca.crt

cp -p ${CA_DIR}/ca.pem \ ${HTTPD_HOME}/conf/ca.crt/.

cp -p ${SSL_SERVER_DIR}/apache_ssl.crt \ ${HTTPD_HOME}/conf/ssl.crt/.

cp -p ${SSL_SERVER_DIR}/apache_ssl.key \ ${HTTPD_HOME}/conf/ssl.key/.

# keep the original names, but make the files available# under the standard names as used in conf/ssl.conf:

for s in key crt ; do cd ${HTTPD_HOME}/conf/ssl.${s} ln -sf apache_ssl.${s} server.${s}done

###############################################################



# -- eof --###############################################################

Das signierte Zertifikat sowie der dazu gehörige private Schlüssel werden in die entsprechenden Verzeichnisse, die in der $APACHE_INSTALL/conf/ssl.conf Konfigurationsdatei der Apache-Installation angegeben sind, kopiert. In dieser Konfigurationsdatei sind noch folgende Ergänzungen durchzuführen, um eine auf Client-Zertifikaten basierende Client-Authentisierung zu ermöglichen.

Listing 26: Ergänzungen in der Apache-Konfigurationsdatei ssl.confSSLVerifyClient requireSSLCACertificateFile /opt/httpd-2.0.54/conf/ca.crt/ca.pemSSLVerifyDepth 1SSLOptions +StdEnvVars +ExportCertData +FakeBasicAuth

4.7.4 Erzeugung von Client-Zertifikaten

Zur Browser-Authentisierung gegenüber dem Webserver werden in einigen Tests Client-Zertifikate verwendet. Diese könne mit dem Skript setup_client_cert.sh generiert werden, das der Einfachheit aus vom Benutzer root ausgeführt wird. Üblicherweise würde ein Benutzer seinen Zertifikat-Request selbst erzeugen, reicht dieses Zertifikat dann zusammen mit den notwendigen Authentisierungsdokumenten bei der CA zur Signierung ein und erhält das signierte Zertifikat zum Import in verschiedene Applikationen wie z. B. den Webbrowser zurück). Das Skript kann optional den Benutzernamen (als erstes Argument, default: memuser1), sowie ggf. ein Zertifikatpasswort (als zweites Argument, default: vmware) erhalten.

Listing 27: Skript zur Erzeugung von Client-Zertifikaten setup_client_cert.sh#!/bin/bash -x################################################################ setup a client certificate###############################################################





CA_PASSWORD=vmware

# use either the command line arguments for this script# $1: client_name or the default memuser1# $2: client_password or the default vmwareCLIENT=${1:-memuser1}CLIENT_PASSWORD=${2:-vmware}





if [ ! -d ${CA_DIR} ] ; then echo "#E# $0 requires a CA to be installed" echo "#E# Please run 'setup_ca.sh' first" exit 1fi


# remove data from previous installationsrm -rf ${CLIENT_DIR}/${CLIENT}*

################################################################ SETTING UP AN SSL CLIENT###############################################################


mkdir -p ${CLIENT_DIR}

#--------------------------------------------------------------# Create a client certificate request:

openssl req -new \ -newkey rsa:2048 \ -passout pass:$CLIENT_PASSWORD \ -out ${CLIENT_DIR}/${CLIENT}.req \ -keyout ${CLIENT_DIR}/${CLIENT}.key \ -subj "/C=DE/ST=NRW/L=Bonn/O=BSITomcat ITC-Sec/OU=Testlab/CN=${CLIENT}"

# The common name of the client must match a user in Tomcat's user# realm (e.g. an entry in conf/tomcat-users.xml) in REVERSE# order:# <user username="CN=${CLIENT}, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn,# ST=NRW, C=DE" password="" roles="userrole">.#--------------------------------------------------------------# Have your CA sign your client certificate.

openssl x509 \ -CA ${CA_DIR}/ca.pem \ -CAkey ${CA_DIR}/ca.key \ -CAserial ${CA_DIR}/ca.srl \ -passin pass:${CA_PASSWORD} \ -req \ -in ${CLIENT_DIR}/${CLIENT}.req \ -out ${CLIENT_DIR}/${CLIENT}.pem \ -days 3650

#--------------------------------------------------------------# Generate a PKCS12 file containing your server key and server# certificate.

# convert to PKCS12 for import by web browseropenssl pkcs12 \ -export \ -clcerts \ -in ${CLIENT_DIR}/${CLIENT}.pem \



-inkey ${CLIENT_DIR}/${CLIENT}.key \ -out ${CLIENT_DIR}/${CLIENT}.p12 \ -passin pass:${CLIENT_PASSWORD} \ -passout pass:${CLIENT_PASSWORD} \ -name "${CLIENT}_client_certificate"

#--------------------------------------------------------------# Import the PKCS12 file into your web browser to use as your client# certificate and key.

#--------------------------------------------------------------# Enable client certificate authentication in Tomcat. Open up# conf/server.xml and search for the text "clientAuth". Set the value# of the attribute to "true".

################################################################ -- eof --###############################################################

Zu beachten ist, dass bei der Erzeugung der Client-Zertifikate mit openssl das Element emailAddress nicht verwendet werden sollte, da diese Information nicht als eigenständiger Eintrag im Zertifikat erscheint, sondern offenbar an ein anderes Element angehängt wird. Außerdem ist die Reihenfolge der Attribute des subjectDN zu beachten:Einem subjectDN-Eintrag für die Erzeugung des Client-Zertifikatrequests

... -subj "/C=DE/L=Bonn/ST=NRW/O=BSITomcat ITC-Sec/OU=Testlab/CN=my_username" ...

muss ein Eintrag

<user username=“CN=my_username, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn, ST=NRW, C=DE" password=““ roles=“user1“/>

in der $CATALINA_HOME/conf/tomcat-users.xml Konfigurationsdatei entsprechen (d. h. mit umgekehrter Reihenfolge der Elemente), um eine CLIENT-CERT Authentisierung erfolgreich durchführen zu können. Außerdem ist es erforderlich, dass das CA-Zertifikat der CA, mit der das Client-Zertifikat signiert wurde, im globalen Java- oder im Tomcat-Zertifikatspeicher vorhanden sein muss. Dort stehen alle CA-Zertifikate, denen z. B. im Hinblick auf die Signierung von Client- oder Benutzer-Zertifikaten vertraut werden soll. Wird hingegen im Rahmen einer lokalen Zertifikatprüfung eines Client- oder Benutzer-Zertifikats das zugehörige CA-Zertifikat nicht in einem der lokalen Zertifikatspeicher vorgefunden, so wird eine Fehlermeldung ausgegeben, dass das Client- bzw. Benutzer-Zertifikat nicht verifiziert werden konnte. Wird der Zugriff auf den Zertifikatspeicher mit einem Passwort geschützt, so muss das Passwort für den Zugriff auf den jeweiligen Zertifikatspeicher in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml spezifiziert sein.

Nach der Erzeugung des Client-Zertifikates durch das Skript in Listing 4.10, das das Client-Zertifikat für einen Import in den Webbrowser im PKCS12 Format bereitstellen muss, ist das erzeugte Zertifikat noch aus dem Verzeichnis /root/bsitomcat_ca/ssl/client in ein Verzeichnis zu kopieren, auf das vom entsprechenden Benutzer lesend zugegriffen werden kann.35

Dieses Zertifikat ist für eine Verwendung anschließend in den benutzten Webbrowser zu importieren. Am Beispiel des Webbrowsers Firefox werden die benötigten Schritte nachfolgend zusammengefasst:35 Dies entspricht der Lieferung des signierten Zertifikats durch die CA an den Benutzer.




Im Webbrowser Firefox wird unter Edit→Preference→Advanced im Abschnitt Certificates das Fenster zur Zertifikatverwaltung geöffnet:

Abbildung 4.4.: Zertifikatverwaltung im Browser Firefox

Mit der Schaltfläche „Manage Certificates ...“ wird das Zertifikate-Verwaltungsfenster geöffnet:



Abbildung 4.5.: Zertifikatimport

Das zuvor erzeugte Zertifikat kann nun über die Schaltfläche „Import“ importiert werden, wobei der Dateiname des Zertifikats in einem weiteren Popup-Fenster einzugeben ist. Beim Import ist das bei der Zertifikaterstellung verwendete Passwort anzugeben:

Abbildung 4.6.: Passwortabfrage zum Importieren

Der erfolgreiche Zugriff auf das in der Importdatei vorhandene Zertifikat und dessen Import wird bestätigt.




Abbildung 4.7.: Bestätigung des erfolgreichen Imports des Zertifikats

Das importierte Zertifikat wird in der Übersicht der vorhandenen Zertifikate angezeigt und steht nach Abschluss des Importes zur Verwendung zur Verfügung.

Abbildung 4.8.: Übersicht über die nun im Webbrowser vorhandenen Zertifikate

Hinweis: Falls der Zertifikatspeicher des Webbrowsers Firefox durch ein Passwort geschützt ist, das bei erstmaliger Benutzung der Zertifikat-Management-Funktionen gesetzt werden kann, ist abweichend von der dargestellten Vorgehensweise bei Zugriffen auf den Zertifikatspeicher dieses Passwort (ggf. an mehreren Stellen) auf Anfrage einzugeben.


Durchführung der Tests Sicherheitsuntersuchung des ApacheJakarta Tomcat Servlet Containers

5. Durchführung der Tests

Die nachfolgend beschriebenen Tests wurden der Feinspezifikation [Tomcat Fein.] aus der Projektphase 1 entnommen und mit den gewonnenen Ergebnissen ergänzt.

Hinweis: In den URLs der nachfolgenden Tests ist der Hostname tomcathost synonym zu localhost und wurde in der Datei /etc/hosts nachgetragen. Das für HTTPS / SSL benötigte Server-Zertifikat wurde auf den Host tomcathost ausgestellt. Dies kann zur Überprüfung der Ausgabe einer Warnung im Webbrowser verwendet werden, die erscheinen sollte, wenn sich der Hostname in der vom Webbrowser verwendeten URL und im Server-Zertifikat unterscheiden.

5.1 Funktionale Tests der Sicherheitsfunktionen von Tomcat

Ziel dieser Tests ist es festzustellen,

• ob es möglich ist, die Sicherheitsfunktionen von Tomcat zu umgehen und

• ob die Sicherheitsfunktionen von Tomcat der Dokumentation entsprechen.

Bei den Tests wird überprüft, welche Arbeitsschritte Tomcat durchführt, wenn die jeweilige Sicherheitsfunktion von Tomcat verwendet wird. Die Analyse besteht dabei im wesentlichen aus der Auswertung der Netzkommunikation der beteiligten Kommunikationspartner und der Sichtung der Tomcat Protokolldateien bei geeignet eingestelltem Debug-Level. Die Tomcat Protokoll-Dateien befinden sich in den vorliegenden Testinstallationen im Verzeichnis $CATALINA_HOME/logs.

5.1.1 Funktionale Tests für die Authentisierung

Die einzelnen Webanwendungen können verschiedene Authentisierungsmethoden verwenden. Es werden daher bei den Tests zwei Anwendungen mit unterschiedlichen Benutzern und Rollen eingesetzt. Die zur Verfügung stehenden Benutzer und Rollen wurden in Abschnitt 4 definiert. Es werden die folgenden Tests durchgeführt:

1. Test1: Ein Benutzer gibt ungültige Authentisierungsinformationen (Kombination von Benutzernamen / Passwort bzw. Client Zertifikat) bei der Authentisierung an einer Webanwendung an. Es wird die Verarbeitung der Authentisierungsinformationen durch Tomcat sowie der Protokollierung ausgewertet.

2. Test2: Ein Benutzer authentisiert sich erfolgreich an einer Webanwendung. Anschließend ruft er eine andere Webanwendung auf, auf die er laut Einstellungen der web.xml-Datei der Webanwendung keinen Zugriff hat. Für diesen Test wird Single Sign On (SSO) eingestellt, da ansonsten für jede Webanwendung eine erneute Authentisierung erforderlich wäre. Der Test wird zunächst mit Anwendungen durchgeführt, die so konfiguriert sind, dass sie die gleiche Authentisierungsmethode gegenüber dem Client einsetzen (z. B. HTTP FORM für beide). Anschließend wird der Test mit Anwendungen wiederholt, die unterschiedliche Authentisierungsmethoden einsetzen (z. B. HTTP FORM für die eine und HTTP BASIC für die andere Anwendung). So wird das Funktionieren des SSO Valves überprüft. Das SSO Valve sollte im Falle der erfolgreichen Authentisierung nur Zugriffsrechte entsprechend der Einstellungen in den web.xml-Dateien der einzelnen Webanwendungen erteilen.



Durchführung der Tests

3. Test3: Der Benutzer authentisiert sich erfolgreich. Die Authentisierungsdatenbank wird anschließend geändert. Es wird überprüft, ob dies von Tomcat bemerkt wird. Dies sollte bei dem JDBC Realm und bei dem JNDI Realm in jedem Fall bemerkt werden. Im Falle des File Realms hängt das Erkennen der Änderungen durch Tomcat davon ab, ob die Konfigurationsdatei direkt über einen Datei-Editor oder über die entsprechende Tomcat Web-GUI Anwendung (admin) geändert wurde. Im zweiten Fall, d. h., Änderung über die Web-GUI, sollte die Änderung von Tomcat bemerkt werden.

Bei den Tests werden die unterschiedlichen Connectoren von Tomcat, die einsetzbaren Authentisierungsmethoden (BASIC, DIGEST, FORM und CLIENT-CERT) und die von Tomcat unterstützten Methoden, die auf Authentisierungsdatenbestände (Realms: User-Database, JDBC (MySQL), JNDI (LDAP)) zugreifen, berücksichtigt. Aufgrund der Architektur von Tomcat – die drei angesprochenen Komponenten sind im Wesentlichen voneinander unabhängig (Ausnahme: Authentisierung über Client Zertifikate) – besteht keine Notwendigkeit alle möglichen Kombinationsmöglichkeiten zu testen. Die vorgesehenen Tests sind in Tabelle 2 zusammengefasst.

Test Nr.

TomcatConnector

Authentisierungsmethode/Benutzerdatenbank

Testbeschreibung

T 1T 2T 3T 4T 5

HTTP BASIC User Test1 (s. o.)JDBC Test1 (s. o.)JNDI Test1 (s. o.)

DIGEST User Test1 (s. o.)FORM User Test1 (s. o.)

T 6 HTTPS Client-Zertifikat User Test1 (s. o.)T 7T 8T 9

AJP1.3 BASIC User Test1 (s. o.)DIGEST User Test1 (s. o.)FORM User Test1 (s. o.)

T 10 AJP1.3 / SSL Client-Zertifikat User Test1 (s. o.)T 11T 12T 13

HTTP BASIC User Test2 (s. o.)DIGEST User Test2 (s. o.)FORM User Test2 (s. o.)



T 18 AJP1.3 / SSL Client-Zertifikat User Test2 (s. o.)T 19T 20T 21

HTTP BASIC User Test3 (s. o.)DIGEST User Test3 (s. o.)FORM User Test3 (s. o.)



T 26 AJP1.3 / SSL Client-Zertifikat User Test3 (s. o.)



Tabelle 2: Funktionale Tests der Authentisierung

Die Verwendung der zwei Tomcat Connectoren (HTTP/HTTPS bzw. AJP1.3) entspricht den Einsatzszenarien 1 (HTTP / HTTPS-Verbindung direkt zu Tomcat) bzw. 2 (Verbindung über den AJP1.3-Connector zu Tomcat) des Feinkonzepts [Tomcat Fein.]. Da sich die Authentisierung bei anderen Einsatzszenarien nicht grundlegend unterscheidet, ist eine explizite Berücksichtigung der anderen Einsatzszenarien bei diesem Test nicht sinnvoll.

Nach den für die jeweiligen Tests vorgenommenen individuellen Konfigurationseinstellungen wird der Tomcat Servlet Container neu gestartet, um sicherzustellen, dass die Konfigurationseinstellungen auch in den Betrieb übernommen wurden.

Außerdem muss ggf. der Webbrowser wegen der Pufferung der Authentisierungsinformationen nach einmal erfolgter Authentisierung verlassen werden, um sich unter einem anderen Benutzer anmelden zu können.

Zur Vorbereitung der nachfolgenden Zugriffsschutz- und Single-Sign-On-Tests werden drei einfache Webanwendungen (simple_info1, simple_info1a, simple_info2) definiert und unter $CATALINA_HOME/webapps installiert. Sie enthalten jeweils die „Top-Level“ Webseite index.jsp und eine weitere confidential.jsp sowie die entsprechende Tomcat-Konfigurationsdatei der Webanwendungen unter WEB-INF/web.xml. Die Zugriffsberechtigungen sind wie folgt vergeben:

Webanwendung Datei Freigabe für Rolle, verwendete

Authentisierungsmethode

simple_info1 simple_info1/index.jsp - alle -simple_info1/confidential.jsp

simple_info1/subdir/moreinfo.jsp

user1,BASIC-Authentisierung

simple_info1a simple_info1a/index.jsp

simple_info1a/confidential.jsp

user1,FORM-Authentisierung

simple_info2 simple_info2/index.jsp

simple_info2/confidential.jsp

user2,DIGEST-Authentisierung

Tabelle 3: Test-Webanwendungen und den Dateien zugeordnete Rollenfreigaben

Für jede Webanwendung werden darüber hinaus auch die beiden in Verbindung mit der FORM-Authentisierung benötigten Dateien login.jsp sowie error.jsp installiert, die für alle Benutzer freigegeben sein müssen, da ansonsten durch die Blockierung von noch unauthentisierten Zugriffen auf diese beiden Dateien keine erfolgreiche Authentisierung durchgeführt werden kann.

5.1.1.1 Ergebnisse zu Test1

Für die Tests der verschiedenen Authentisierungsmethoden können zunächst die mit installierten Applikationen

• simple_info1 (für BASIC-Authentisierung),

• simple_info1a (für FORM-Authentisierung),




• simple_info2 (für DIGEST-Authentisierung)

verwendet werden, wobei die jeweilige Authentisierungsmethode in der Datei WEB-INF/web.xml der Webanwendung spezifiziert wird. Für die Tests wurden, soweit nicht anders angegeben, keine besonderen oder weitergehenden Logging-Optionen aktiviert.

Bei den Tests konnte durch das Mitlesen der Netzwerkkommunikation mit dem Werkzeug ethereal verifiziert werden, dass über die HTTP-Verbindung zwischen dem Webbrowser und dem Webserver36 bzw. zwischen dem Webbrowser und dem Tomcat Servlet Container37, die Authentisierungsinformationen in folgenden Fällen im Klartext ausgetauscht werden:

• BASIC-Authentisierung: als reversibel Base64-codierte Zeichenkette der Konkatenation von benutzername:passwort mit dem Doppelpunkt als Trennzeichen zwischen Benutzername und Passwort. Damit ist die BASIC-Authentisierung bei einer Verwendung über unsichere Netzwerke (z. B. das Internet), wo der Datenverkehr zwischen dem Webbrowser und dem Webserver abgehört werden kann, nicht als sicher zu betrachten.

• FORM-Authentisierung: im Klartext innerhalb eines HTTP-POST Paketes, womit die FORM-Authentisierung gleichfalls nicht als sicher zu betrachten ist.

Lediglich bei der DIGEST-Authentisierung kann das Benutzerpasswort nicht einfach aus den übertragenen HTTP-Nachrichten rekonstruiert werden und sollte daher zur Authentisierung über ungeschützte Netzwerke verwendet werden.

5.1.1.1.1 T1: HTTP Connector, BASIC-Authentisierung, Memory RealmZunächst erfolgt eine Aktivierung der Memory Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet.

Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die geschützte Webseite http://tomcathost:8080/simple_info1/confidential.jsp der simple_info1 Anwendung führte zur Ablehnung des Logins ohne Protokollierung einer Fehlermeldung in $CATALINA_HOME/logs/catalina-<datum>.log, woraufhin das Browser-Popup-Fenster zur HTTP-Authentisierung erneut geöffnet wird.

Auch ein Zugriffsversuch mit dem für eine andere Rolle eingetragenen Benutzer memuser2 und dem zugehörigen gültigen Passwort vmware führte ebenso zu einer Ablehnung des Logins, diesmal mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser.

Ein nachfolgender Zugriff im neu gestarteten Webbrowser mit dem Benutzer memuser1 und dem Passwort vmware auf die manager Anwendung wurde erfolgreich, aber auch ohne Logdateieinträge, durchgeführt. Ein Neustart des Webbrowsers war erforderlich, da die vorherige Benutzerinformation für den Webbrowser noch gültig war38 und im Webbrowser-Cache vorlag. Wenn ein erneuter Zugriff auf dieselbe Webseite mit den gleichen Benutzerinformationen versucht worden wäre, hätte dies erneut zur Ablehnung durch den

36 bei Verwendung von Apache-mod_jk sowie Tomcat mit AJP13 Connector37 beim Direktzugriff auf den HTTP-Connector von Tomcat38 Die Fehlermeldung des Webservers war schließlich „HTTP Status 403 - Access denied“ und deutet damit auf ein

Zugriffsverbot, nicht aber einen Authentisierungsfehler hin.



Webserver mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied" geführt.

Für eine Protokollierung von Fehlzugriffen auf die von Tomcat bereitgestellten Webanwendungen sollte eine Aktivierung der Logging-Funktionen gemäß den in Abschnitt 6.3.3 gegebenen Hinweisen beachtet werden.

5.1.1.1.2 T2: HTTP Connector, BASIC-Authentisierung, JDBC RealmZunächst erfolgt eine Aktivierung der JDBC Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet.

Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die Anwendung simple_info1 http://tomcathost:8080/simple_info1/confidential.jsp führte zu einer Ablehnung des Logins und zwar ohne Protokollierung einer Fehlermeldung in $CATALINA_HOME/logs/catalina-<datum>.log. Anschließend wird das Browser-Popup-Fenster zur Eingabe der HTTP-Authentisierungsdaten erneut geöffnet.

Auch ein Zugriffsversuch mit dem für eine andere Rolle eingetragenen Benutzer jdbcuser2 und dem zugehörigen gültigen Passwort vmware führte ebenso zu einer Ablehnung des Logins mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser.

Ein nachfolgender Zugriff im neu gestarteten Webbrowser mit dem Benutzer jdbcuser1 und dem Passwort vmware auf die manager Anwendung wurde erfolgreich aber auch ohne Logdateieinträge durchgeführt.

Bei der Nachverfolgung des Netzwerkverkehrs mit dem MySQL-Server (Port 3306) konnte festgestellt werden, dass das in der Datenbank gespeicherte Referenzpasswort für die Authentisierung im Klartext zurück zum Tomcat Servlet Container übertragen wird. Falls diese Übertragung nicht innerhalb eines gesicherten Netzwerkbereiches erfolgt (z. B. bei Aufteilung auf separaten Tomcat-Rechner und MySQL-Rechner), ist das Risiko des Mitlesens von Passwortinformationen zu berücksichtigen.

5.1.1.1.3 T3: HTTP Connector, BASIC-Authentisierung, JNDI RealmZunächst erfolgt eine Aktivierung der JNDI Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet.

Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die simple_info1 Anwendung http://tomcathost:8080/simple_info1/ führte zur Ablehnung des Logins ohne Protokollierung einer Fehlermeldung in $CATALINA_HOME/logs/catalina-<datum>.log, woraufhin das Browser-Popup-Fenster zur HTTP-Authentisierung erneut geöffnet wird.

Auch ein Zugriffsversuch mit dem für eine andere Rolle eingetragenen Benutzer jndiuser2 und dem zugehörigen gültigen Passwort vmware führte ebenso zu einer Ablehnung des Logins, diesmal mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser.




Ein nachfolgender Zugriff im neu gestarteten Webbrowser mit dem Benutzer jndiuser1 und dem Passwort vmware auf die simple_info1 Anwendung wurde erfolgreich aber auch ohne Logdateieinträge. durchgeführt.

Bei der Nachverfolgung des Netzwerkverkehrs mit dem OpenLDAP-Server (Port 389) konnte festgestellt werden, dass das vom Benutzer zur Authentisierung eingegebene Passwort an den OpenLDAP-Server zur dortigen Überprüfung übertragen wird. Falls diese Übertragung nicht innerhalb eines gesicherten Netzwerkbereiches erfolgt (Aufteilung auf separaten Tomcat-Rechner und OpenLDAP-Rechner), ist das Risiko des Mitlesens von Passwortinformationen zu berücksichtigen.

5.1.1.1.4 T4: HTTP Connector, DIGEST-Authentisierung, Memory RealmZunächst erfolgt eine Aktivierung der Memory Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet.

Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die manager Anwendung http://tomcathost:8080/simple_info2/ führte zur Ablehnung des Logins ohne Protokollierung einer Fehlermeldung in $CATALINA_HOME/logs/catalina-<datum>.log. Auch ein Zugriffsversuch mit dem im Test T1 verwendeten Benutzer memuser1 und dem Passwort vmware führte ebenso zu einer Ablehnung des Logins mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser.

Ein nachfolgender Zugriff im neu gestarteten Webbrowser mit dem Benutzer memuser2 und dem Passwort vmware auf die manager Anwendung wurde erfolgreich, aber auch ohne Logdateieinträge, durchgeführt.

Durch die Verwendung

• eines vom Webserver gelieferten Zufallswertes,

• dem Benutzernamen,

• dem Passwort sowie

• der Realm-Information

wird ein Digest-Wert berechnet und zum Webserver übertragen. Somit sind keine Passwortinformationen bei der Übertragung vom Webbrowser zum Webserver im Klartext bzw. in einfacher Base64-codierter39 Form sichtbar. Dies konnte beim Mitlesen des Netzwerkverkehrs zwischen diesen beiden Kommunikationspartnern verifiziert werden.

5.1.1.1.5 T5.1: HTTP Connector, FORM-Authentisierung, Memory RealmZunächst erfolgt eine Aktivierung der Memory Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet.

39 wie bei der HTTP BASIC-Authentisierung



Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die simple_info1a Anwendung http://tomcathost:8080/simple_info1a/ führte zur Ablehnung des Logins ohne Protokollierung der Fehlermeldung in $CATALINA_HOME/logs/catalina-<datum>.log und Ausgabe der von der Webanwendung bereitgestellten Fehler-Webseite http://tomcathost:8080/simple_info1a/error.jsp im Webbrowser.

Auf die gleiche Weise wurde ein Zugriffsversuch mit dem einer anderen Rolle zugeordneten Benutzer memuser2 und dem Passwort vmware abgewiesen, wobei die Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser ausgegeben wurde.

Ein nachfolgender Zugriff im neu gestartetem Webbrowser mit dem Benutzer memuser1 und dem Passwort vmware auf die simple_info1a Anwendung wurde erfolgreich und ohne Logdateieinträge durchgeführt.

Zu beachten ist bei der Verwendung des FORM-Authentisierungsverfahrens, dass Benutzername und -passwort im Klartext über die HTTP-Verbindung (Tomcat-Frontend) übertragen werden und somit auf dem Weg zwischen dem Webbrowser und dem HTTP-Connector von Tomcat abgehört werden kann.

Nachfolgend werden der Vollständigkeit halber noch die Varianten JDBC Realm, JNDI Realm sowie Memory Realm mit Digest in Verbindung mit FORM-Authentisierung getestet.

5.1.1.1.6 T5.2: HTTP Connector, FORM-Authentisierung, JDBC RealmZunächst erfolgt eine Aktivierung der JDBC Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei und ein Restart von Tomcat.

Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die simple_info1a Anwendung http://tomcathost:8080/simple_info1a/ führte zur Ablehnung des Logins ohne Protokollierung der Fehlermeldung in $CATALINA_HOME/logs/catalina-<datum>.log und Ausgabe der von der Webanwendung bereitgestellten Fehler-Webseite http://tomcathost:8080/simple_info1a/error.jsp im Webbrowser.

Auch ein Zugriffsversuch mit dem für eine andere Rolle eingetragenen Benutzer jdbcuser2 und dem zugehörigen gültigen Passwort vmware führte ebenso zu einer Ablehnung des Logins mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser.

Ein nachfolgender Zugriff im neu gestarteten Webbrowser mit dem Benutzer jdbcuser1 und dem Passwort vmware auf die simple_admin1a Anwendung wurde erfolgreich und ohne Logdateieinträge durchgeführt.

Zu beachten ist bei der Verwendung des FORM-Authentisierungsverfahrens, dass Benutzername und -passwort im Klartext über die HTTP-Verbindung (Tomcat-Frontend) übertragen werden und somit auf dem Weg zwischen dem Webbrowser und dem HTTP-Connector von Tomcat abgehört werden kann (analog zum vorigen Test T5.1). Bei der Nachverfolgung des Netzwerkverkehrs des Tomcat Servlet Containers mit dem MySQL-Server (Port 3306) konnte festgestellt werden, dass das in der Datenbank gespeicherte Referenzpasswort für die Authentisierung im Klartext zurück zum Tomcat Servlet Container übertragen wird. Falls diese Übertragung nicht innerhalb eines gesicherten Netzwerkbereiches




erfolgt (Aufteilung auf separaten Tomcat Rechner und MySQL Rechner), ist das Risiko des Mitlesens von Passwortinformationen zu berücksichtigen.

5.1.1.1.7 T5.3: HTTP Connector, FORM-Authentisierung, JNDI RealmZunächst erfolgt eine Aktivierung der JNDI Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet.

Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die simple_info1a Anwendung führte zur Ablehnung des Logins ohne Protokollierung der Fehlermeldung in $CATALINA_HOME/logs/catalina-<datum>.log und Ausgabe der Fehler-Webseite http://tomcathost:8080/simple_info1a/error.jsp im Webbrowser.

Auch ein Zugriffsversuch mit dem für eine andere Rolle eingetragenen Benutzer jndiuser2 und dem zugehörigen gültigen Passwort vmware führte ebenso zu einer Ablehnung des Logins mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser.

Ein nachfolgender Zugriff mit dem Benutzer jndiuser1 und dem Passwort vmware auf die simple_info1a Anwendung wurde erfolgreich und gleichfalls ohne Logdateieintrag durchgeführt.

Zu beachten ist bei der Verwendung des FORM-Authentisierungsverfahrens, dass Benutzername und -passwort im Klartext über die HTTP-Verbindung (Tomcat-Frontend) übertragen werden und somit auf dem Weg zwischen dem Webbrowser und dem HTTP-Connector von Tomcat abgehört werden kann (analog zum vorigen Test T5.1). Bei der Nachverfolgung des Netzwerkverkehrs des Tomcat Servlet Containers mit dem OpenLDAP-Server (Port 389) konnte festgestellt werden, dass das vom Benutzer zur Authentisierung eingegebene Passwort an den OpenLDAP-Server zur dortigen Überprüfung übertragen wird. Falls diese Übertragung nicht innerhalb eines gesicherten Netzwerkbereiches erfolgt (Aufteilung auf separaten Tomcat Rechner und OpenLDAP Rechner), ist das Risiko des Mitlesens von Passwortinformationen zu berücksichtigen.

5.1.1.1.8 T6: HTTPS Connector, Client Zertifikat Authentisierung, Memory RealmZunächst erfolgt eine Aktivierung der Memory Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei und ein Restart von Tomcat. Weiterhin wird für die Webanwendungen simple_info1a (freigegeben für die Rolle user1) und simple_info2 (freigegeben für die Rolle user2) in der jeweiligen WEB-INF/web.xml Konfigurationsdatei die Authentisierungsmethode von BASIC auf CLIENT-CERT umgestellt. In der $CATALINA_HOME/conf/tomcat-users.xml Datei sind die beiden Zertifikat-gebundenen Benutzer eingetragen, für die entsprechende Client-Zertifikate im Webbrowser vorhanden sein müssen, um die jeweilige Webanwendung aufrufen zu können.

Listing 28: Ergänzte Benutzer mit Client Zertifikat Authentisierung in tomcat_users.xml <user username="CN=memuser1, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn, ST=NRW, C=DE" password="null" roles="user1"/> <user username="CN=memuser2, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn, ST=NRW, C=DE" password="null" roles="user2"/>



In Verbindung mit der CLIENT-CERT Authentisierung erfolgt keine Auswertung der unter password eingetragenen Werte (wie dies bei der BASIC-Authentisierung der Fall wäre), sodass hier beliebige Werte eingetragen sein können.

Bei einem Zugriff auf eine geschützte Webseite ohne HTTPS-Verbindung (z. B. http://tomcathost:8080/simple_info1a/ bzw. http://tomcathost:8080/simple_info2/) und damit ohne Austausch von Zertifikatinformationen wird der Zugriff mit der Fehlermeldung „HTTP Status 400 – No client certificate chain in this request“ verweigert.

Beim HTTPS-Zugriff auf die Webseite mit einem gültigen aber unpassenden Zertifikat (https://tomcathost:8443/simple_info1a/ mit Zertifikat für eine Rollenzuordnung user2 bzw. https://tomcathost:8443/simple_info2/ mit Zertifikat für eine Rollenzuordnung user1) wird der Zugriff mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ verweigert.

Beim HTTPS-Zugriff mit einem für die jeweilige Webseite passenden Zertifikat (https://tomcathost:8443/simple_info1a/ mit Zertifikat für eine Rollenzuordnung user1 bzw. https://tomcathost:8443/simple_info2/ mit Zertifikat für eine Rollenzuordnung user2) ist ein Zugriff möglich. Zu beachten ist hierbei, dass durch die Zwischenspeicherung von für die Authentisierung benötigen Informationen im Webbrowser beim Wechsel in eine andere Rolle der Webbrowser neu gestartet werden muss. Die in der HTTPS-Anfrage übertragenen Zertifikatinformationen können mit der in jeder der betrachteten Webanwendungen installierten JSP-Datei request_data.jsp abgefragt werden (z. B. https://tomcathost:8443/simple_info1a/request_data.jsp).

5.1.1.1.9 T7: AJP1.3 Connector, BASIC-Authentisierung, Memory RealmDie Vorgehensweise ist wie bei Test T1 mit geänderter URL http://tomcathost:80/simple_info1/confidential.jsp, um den Zugriff auf die simple_info1 Anwendung über den vorgeschalteten Apache Webserver mit mod_jk – AJP1.3 durchzuführen.

Sowohl bei der Nachverfolgung des HTTP-Netzwerkverkehrs zwischen Webbrowser und Apache Webserver (Frontend) als auch des AJP-Netzwerkverkehrs zwischen dem Apache Webserver (mod_jk Connector Backend) und Tomcat konnten Benutzername und Passwort mitgelesen werden, was bei einer Kommunikation über unsichere Netzwerke zu berücksichtigen ist.

Ansonsten sind die Ergebnisse mit denen des Tests T1 vergleichbar.

5.1.1.1.10 T8: AJP1.3 Connector, DIGEST-Authentisierung, Memory RealmDie Vorgehensweise ist wie bei Test T4 mit geänderter URL http://tomcathost:80/simple_user2/, um den Zugriff auf die simple_user2 Anwendung über den vorgeschalteten Apache Webserver mit mod_jk – AJP1.3 durchzuführen.

Auch hier konnten wie in Test T7 Benutzername und Passwort im HTTP- wie im AJP-Netzwerkverkehr mitgelesen werden.

Ansonsten sind die Ergebnisse mit denen des Tests T4 vergleichbar.




5.1.1.1.11 T9: AJP1.3 Connector, FORM-Authentisierung, Memory RealmDie Vorgehensweise ist wie bei Test T5.1 mit geänderter URL http://tomcathost:80/simple_user1a/, um den Zugriff auf die simple_user1a Anwendung über den vorgeschalteten Apache Webserver mit mod_jk – AJP1.3 durchzuführen.

Auch hier konnten wie in Test T7 Benutzername und Passwort im HTTP- wie im AJP-Netzwerkverkehr mitgelesen werden.

Ansonsten sind die Ergebnisse mit denen des Tests T5.1 vergleichbar.

5.1.1.1.12 T10: AJP1.3 / SSL Connector, Client Zertifikat Authentisierung, Memory RealmDie Vorbereitungen für Test T10 sind analog zu denen von Test T6. Zusätzlich ist für diesen Test der Apache Webserver mit dem Kommando

/opt/httpd-2.0.54/bin/apachectl -f /opt/httpd-2.0.54/conf/httpd.conf -DSSL

zu starten. Die Zugriffe erfolgen jetzt über den Apache Webserver mit den URLs http://tomcathost:80/simple_info1a/ bzw. https://tomcathost:443/simple_info1a/ (und analog für die zweite Webanwendung).

Die beim Zugriff über den Apache Webserver mit mod_jk sowie dem Tomcat AJP13-Connector auf Tomcat erzielten Ergebnisse ähneln denen des Tests T6.


Zum Test von Single Sign On (SSO) werden wiederum die zuvor verwendeten Beispiel-Webanwendungen (simple_info1, simple_info1a, simple_info2) verwendet. Damit kann nach einer Authentisierung als Benutzer mit der Rollenzuordnung user1 überprüft werden, ob

• ohne Aktivierung der SSO-Valve für jede Applikation eine separate Anmeldung erforderlich ist.

• bei Aktivierung der SSO-Valve eine Freigabe für alle Ressourcen mit einer Freigabe für die angemeldete Rolle ohne separate Anmeldung erfolgt ist.

Für die SSO Tests werden zunächst für alle Webanwendungen die BASIC-Authentisierung eingestellt (in der Datei WEB-INF/web.xml der jeweiligen Webanwendung).

5.1.1.2.1 T11: HTTP Connector, BASIC-Authentisierung, Memory RealmTest ohne Aktivierung des SSO-Valve

Ohne Aktivierung des SSO-Valve erfolgt zunächst ein Zugriff auf die allgemein freigegebene Webseite http://tomcathost:8080/simple_info1. Über den dort vorhandenen URL wird die Folgeseite http://tomcathost:8080/simple_info1/confidential.jsp aufgerufen, für die zunächst ein Browser-Popup-Fenster zur HTTP-Authentisierung geöffnet wird. Nach erfolgreicher Eingabe von Benutzer memuser1 und Passwort vmware wird diese Seite dann gleichfalls angezeigt.



Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info1a erfordert eine erneute Authentisierung.

Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info2 erfordert eine Authentikation mit dem Benutzer memuser2 und Passwort vmware. Wird die Authentisierung mit der zuvor verwendeten Benutzer memuser1 / Passwort vmware Kombination versucht, so erhält man die Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser zurück.

Test mit Aktivierung des SSO-Valve

Es erfolgt nach der Aktivierung des SSO-Valve (zusätzlicher Eintrag

<Valve className=“org.apache.catalina.authenticator.SingleSignOn“/>

in der <Host>-Section der Datei $CATALINA_HOME/conf/server.xml, s. [Moczar] S. 657) ein Zugriff auf die allgemein freigegebene Webseite http://tomcathost:8080/simple_info1. Über den dort vorhandenen URL wird die Folgeseite http://tomcathost:8080/simple_info1/confidential.jsp aufgerufen, für die zunächst ein Browser-Popup-Fenster zur HTTP-Authentisierung geöffnet wird. Nach erfolgreicher Eingabe von Benutzer memuser1 und Passwort vmware wird diese Seite dann gleichfalls angezeigt.

Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info1a erfordert jetzt erwartungsgemäß keine erneute Authentisierung.

Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info2 wird unmittelbar mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser quittiert. Ein erneutes Login-Fenster wird hier – im Gegensatz zum Test ohne SSO – nicht angezeigt. Der Webbrowser verbleibt also im Kontext der zuvor authentisierten Rolle user1, für den die Webanwendung simple_info2 nicht freigegeben ist, was zur festgestellten Abweisung führt.

Nach Abschluss des SSO-Tests wird die eingefügte SSO-Valve-Zeile in $CATALINA_HOME/conf/server.xml wieder entfernt.

5.1.1.2.2 T12: HTTP Connector, DIGEST-Authentisierung, Memory RealmZur Durchführung der Tests mit DIGEST-Authentisierung wird in den drei Anwendungen (simple_info1, simple_info1a, simple_info2) in der Tomcat-Konfigurationsdatei WEB-INF/web.xml die Authentisierungsmethode von <auth-method>BASIC</auth-method> auf <auth-method>FORM</auth-method> umgestellt (s. [Moczar], S. 316 ff.).

Die Testdurchführung und die dabei gewonnenen Ergebnisse sind mit denen aus Test T11 vergleichbar.

5.1.1.2.3 T13.1: HTTP Connector, FORM-Authentisierung, Memory RealmZur Durchführung der Tests mit FORM-Authentisierung werden in den drei Anwendungen (simple_info1, simple_info1a, simple_info2) in der Tomcat-Konfigurationsdatei WEB-INF/web.xml jeweils die Einträge innerhalb des <login-config> Abschnitts ergänzt und die




Authentisierungsmethode von <auth-method>BASIC</auth-method> auf <auth-method>FORM</auth-method> umgestellt (s. [Moczar], S. 316 ff.):

Listing 29: Ergänzung in den Konfigurationsdateien WEB-INF/web.xml<form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page></form-login-config>

Test ohne Aktivierung des SSO-Valve

Ohne Aktivierung des SSO-Valve erfolgt zunächst ein Zugriff auf die allgemein freigegebene Webseite http://tomcathost:8080/simple_info1. Über den dort vorhandenen URL wird die Folgeseite http://tomcathost:8080/simple_info1/confidential.jsp aufgerufen, für die zunächst die automatisch die zur Anwendung gehörige Authentisierungs-Webseite http://tomcathost:8080/simple_info1/login.jsp geöffnet wird. Nach erfolgreicher Eingabe von Benutzer memuser1 und Passwort vmware wird diese Seite dann gleichfalls angezeigt.

Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info1a erfordert eine erneute Authentisierung mit der der neuen Applikation entsprechenden Authentisierungs-Webseite http://tomcathost:8080/simple_info1a/login.jsp.

Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info2 erfordert eine Authentisierung mit dem Benutzer memuser2 und Passwort vmware über die automatisch geöffnete und zur Anwendung gehörige Authentisierungs-Webseite http://tomcathost:8080/simple_info2/login.jsp. Wird die Authentisierung mit der zuvor verwendeten Benutzer memuser1 / Passwort vmware Kombination versucht, so erhält man die Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser zurück.

Hinweis: Wird eine komplett ungültige Benutzer / Passwort Kombination verwendet, so erscheint die unter <form-error-page> angegebene Fehlerseite der jeweiligen Anwendung, z. B. http://tomcathost:8080/simple_info2/error.jsp. Wurde bei der Anmeldung eine gültige Kombination von Benutzer / Passwort verwendet, wobei die diesem Benutzer zugeordneten Rollen nicht auf diejenigen passen, für die die Anwendung freigegeben wurden, erhält man hingegen die Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser zurück. Es ist evtl. noch weiter zu untersuchen, ob sich hieraus Angriffsszenarien ableiten lassen, da über die HTTP-Fehlermeldung indirekt bestätigt wurde, dass die verwendete Benutzer / Passwort Kombination in einem anderen Webanwendungskontext gültig sein könnte.


Es erfolgt nach der Aktivierung des SSO-Valve durch den zusätzlichen Eintrag


in der <Host>-Section der Datei $CATALINA_HOME/conf/server.xml, s. [Moczar] S. 657, ein Zugriff auf die allgemein freigegebene Webseite http://tomcathost:8080/simple_info1. Über den dort vorhandenen URL wird die Folgeseite



http://tomcathost:8080/simple_info1/confidential.jsp aufgerufen, für die zunächst die Authentisierung-Webseite http://tomcathost:8080/simple_info1/login.jsp automatisch geöffnet wird. Nach erfolgreicher Eingabe von Benutzer memuser1 und Passwort vmware wird diese Seite dann gleichfalls angezeigt.

Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info1a erfordert jetzt erwartungsgemäß keine erneute Authentisierung mehr, da hierfür die gleiche Rollenfreigabe vorliegt wie in der vorigen Applikation.

Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info2 wird unmittelbar mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser quittiert, da die Anmeldung in der für die beiden vorigen Applikationen benötigten Rolle erfolgreich durchgeführt wurde, diese Rolle jedoch nicht für die aktuelle Anwendung zugelassen ist.


5.1.1.2.4 T13.2: HTTP Connector, gemischte BASIC- und FORM-Authentisierung, Memory RealmIm folgenden Test erfolgt die Authentisierung der Webanwendungen simple_info1 und simple_info2 mit BASIC-Authentisierung und simple_info1a mit FORM-Authentisierung.

Test ohne Aktivierung des SSO-Valve

Der erste Test beginnt mit dem Aufruf der per BASIC-Authentisierung gesicherten Webseite http://tomcathost:8080/simple_info1/confidential.jsp, wo die HTTP-Authentisierungsabfrage per Browser-Popup-Fenster durchgeführt wird (Benutzer memuser1 / Passwort vmware). Anschließend kann nach erneuter Authentisierung auf die per FORM-Authentisierung gesicherte Webseite http://tomcathost:8080/simple_info1a zugegriffen werden. Auch der Zugriff auf die nur für eine andere Rolle freigegebene Webseite http://tomcathost:8080/simple_info2 ist erst nach erneuter HTTP-Authentisierung per Browser-Popup-Fenster möglich.

Das gleiche Resultat von jeweils individueller Authentisierung je Applikation erhält man durch geänderte Aufrufreihenfolge der Webseiten (im zweiten Test: http://tomcathost:8080/simple_info1a, http://tomcathost:8080/simple_info1/confidential.jsp und http://tomcathost:8080/simple_info2, im dritten Test http://tomcathost:8080/simple_info2, http://tomcathost:8080/simple_info1/confidential.jsp und http://tomcathost:8080/simple_info1 ).


Es erfolgt zunächst die Aktivierung des SSO-Valve durch den zusätzlichen Eintrag


in der <Host>-Section der Datei $CATALINA_HOME/conf/server.xml, s. [Moczar] S. 657, und ein Neustart von Tomcat.




Der erste Test beginnt mit dem Aufruf der per BASIC-Authentisierung gesicherten Webseite http://tomcathost:8080/simple_info1/confidential.jsp, wo die HTTP-Authentisierungsabfrage per Browser-Popup-Fenster durchgeführt wird (Benutzer memuser1 / Passwort vmware). Anschließend kann ohne weitere Authentisierung auf die per FORM-Authentisierung gesicherte Webseite http://tomcathost:8080/simple_info1a zugegriffen werden, nicht jedoch auf die nur für eine andere Rolle freigegebene Webseite http://tomcathost:8080/simple_info2. Hier wird die Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser zurück gegeben.

Im zweiten Test wird zuerst die FORM-Authentisierung in der Reihenfolge der Abfragen http://tomcathost:8080/simple_info1a, http://tomcathost:8080/simple_info1/confidential.jsp und schließlich http://tomcathost:8080/simple_info2 durchgeführt und das gleiche erwartete Verhalten erzielt.

Im dritten Test wird nach einer HTTP-Authentisierung als Benutzer memuser2 / Passwort vmware per Browser-Popup-Fenster über die BASIC-Authentisierung in Verbindung mit der Webseite http://tomcathost:8080/simple_info2 der Zugriff auf die beiden anderen gesicherten Webanwendungen mit Rückgabe der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser erwartungsgemäß blockiert.


5.1.1.2.5 T14: HTTPS Connector, Client Zertifikat Authentisierung, Memory RealmZum Test werden die beiden Webanwendungen simple_info1 (mit BASIC-Authentisierung) und simple_info1a (mit CLIENT-CERT-Authentisierung) verwendet. Es erfolgt zunächst die Aktivierung des SSO-Valve durch den zusätzlichen Eintrag


in der <Host>-Section der Datei $CATALINA_HOME/conf/server.xml, s. [Moczar] S. 657, und ein Neustart von Tomcat.

Zuerst erfolgt ein Zugriff mit HTTP-Authentisierung als Benutzer memuser1 / Passwort vmware auf die geschützte Webseite https://tomcathost:8443/simple_info1/confidential.jsp durchgeführt. Es folgt ein Zugriff auf die für die gleiche Rolle freigegebene Webseite https://tomcathost:8443/simple_info1a/index.jsp, der korrekt und ohne weitere Authentisierung zugelassen wird. Ein Zugriff auf die für eine andere Rolle freigegebene Webseite https://tomcathost:8443/simple_info2/index.jsp wird hingegen mit Rückgabe der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser erwartungsgemäß blockiert.

Im zweiten Versuch erfolgte zuerst ein Zugriff mit HTTP-Authentisierung als Benutzer memuser1 / Passwort vmware auf die geschützte Webseite http://tomcathost:8080/simple_info1/confidential.jsp. Es folgt ein Zugriff auf die für die gleiche Rolle freigegebene Webseite http://tomcathost:8080/simple_info1a/index.jsp, der korrekt und ohne weitere Authentisierung zugelassen wird.



Es konnte festgestellt werden, dass beim Zugriff auf die per BASIC-Authentisierung geschützte Webanwendung simple_info1 ein beliebiges gültiges Zertifikat im Rahmen der erforderlichen Client-Authentisierung des HTTPS-Verbindungsaufbaus vorgelegt werden kann, ohne dass die Verbindung abgewiesen wird. Wird dann nach erfolgreicher HTTP-Authentisierung in die durch CLIENT-CERT-Authentisierung geschützte Webanwendung simple_info1a gewechselt, so ist kein gültiges Zertifikat erforderlich, da die Authentisierung bereits erfolgreich per HTTP-Authentisierung durchgeführt wurde. Falls beide Bereiche derselben Rolle zugeordnet sind, ist der Zugang in einen Webanwendungsbereich, der durch eine stärkere CLIENT-CERT-Authentisierung geschützt ist, auf diese Weise über den SSO-Valve, wegen der schwachen HTTP-Authentisierung möglich. Die überprüften Zugriffsszenarien sind in den folgenden Abbildungen aufgezeichnet:

Abbildung 5.1.: Zugriffsszenario beginnend mit Webanwendung simple_info1 und HTTP-Erstzugriff

Beim in Abbildung 5.1 dargestellten Aufruf des geschützten Bereichs von Webanwendung simple_info1 erfolgt eine HTTP-Authentisierung, deren Ergebnis auch zum Wechsel in die für die gleiche Rolle freigegebene Webanwendung simple_info1a verwendet wird. Ein Wechsel in die für eine andere Rolle freigegebene Webanwendung simple_info2 wird hingegen abgewiesen. Beim Wechsel in den HTTPS-Bereich ist in der eingestellten HTTPS-Konfiguration ein Client-Zertifikat vorzulegen. Dies hat aber offenbar im o. g. Zugriffsszenario keine weitergehende Bedeutung bei der Authentisierung. Trotz der Verwendung des Zertifikats für einen Benutzer mit Berechtigung für die Rolle user2 ist es nicht möglich, aus der Webanwendung simple_info1a (HTTPS) zur Webanwendung simple_info2 (HTTPS) zu wechseln (unterer horizontaler Pfeil).




Abbildung 5.2.: Zugriffsszenario beginnend mit Webanwendung simple_info1 und HTTPS-Erstzugriff

Der in Abbildung 5.2 dargestellten Fall des Zugriffs auf die Webanwendung simple_info1 keine Client-Zertifikat-Authentisierung erfolgt, genügt auch hier bei der erstmaligen HTTPS-Verbindung die Vorlage eines beliebigen gültigen Zertifikats (hier das für die Rolle user2), das aber auch hier offenbar nicht weiter ausgewertet wird, da nach einer erfolgreichen HTTP-Authentisierung der Zugriff auf die Webseiten der Applikation simple_info1a möglich sind.

Abb. 5.3.: Zugriffsszenario beginnend mit Webanwendung simple_info1a und HTTPS-Erstzugriff



Beginnt die Zugriffssequenz wie in Abb. 5.3 dargestellt mit der durch CLIENT-CERT Authentisierung geschützten Webanwendung simple_info1a, so muss ein dafür gültiges Client-Zertifikat vorgelegt werden. Nachfolgende Zugriffe auf Webseiten der durch BASIC-Authentisierung geschützten Webanwendung simple_info1 sind dann durch das SSO-Valve ohne weitere Authentisierung möglich. Ein Zugriff auf Webseiten der Webanwendung simple_info2 wird erwartungsgemäß mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser abgewiesen.

5.1.1.2.6 T15: AJP1.3 Connector, BASIC-Authentisierung, Memory RealmDie Ergebnisse in Test 15 sind mit denen aus Test 11 vergleichbar. Hierbei wurden jedoch die URLs http://tomcathost/simple_info1, http://tomcathost/simple_info1a bzw. http://tomcathost/simple_info2 verwendet (ohne Angabe der Portnummer :8080).

5.1.1.2.7 T16: AJP1.3 Connector, DIGEST-Authentisierung, Memory RealmDie Ergebnisse in Test 16 sind mit denen aus Test 12 vergleichbar. Hierbei wurden jedoch die URLs http://tomcathost/simple_info1, http://tomcathost/simple_info1a bzw. http://tomcathost/simple_info2 verwendet (ohne Angabe der Portnummer :8080).

5.1.1.2.8 T17.1: AJP1.3 Connector, FORM-Authentisierung, Memory RealmDie Ergebnisse in Test 17.1 sind mit denen aus Test 13.1 vergleichbar. Hierbei wurden jedoch die URLs http://tomcathost/simple_info1, http://tomcathost/simple_info1a bzw. http://tomcathost/simple_info2 verwendet (ohne Angabe der Portnummer :8080), um die Verbindung zum Tomcat Servlet Container über den Apache Webserver und das mod_jk-Modul zu testen.

5.1.1.2.9 T17.2: AJP Connector, gemischte BASIC- und FORM-Authentisierung, Memory RealmDie Ergebnisse in Test 17.2 sind mit denen aus Test 13.2 vergleichbar. Hierbei wurden jedoch die URLs http://tomcathost/simple_info1, http://tomcathost/simple_info1a bzw. http://tomcathost/simple_info2 verwendet (ohne Angabe der Portnummer :8080), um die Verbindung zum Tomcat Servlet Container über den Apache Webserver und das mod_jk-Modul zu testen.

5.1.1.2.10 T18: AJP1.3 / SSL Connector, Client Zertifikat Authentisierung, Memory RealmDie Vorbereitungen für Test T18 sind analog zu denen von Test T14. Zusätzlich ist für diesen Test der Apache Webserver mit dem Kommando

/opt/httpd-2.0.54/bin/apachectl -f /opt/httpd-2.0.54/conf/httpd.conf -DSSL

zu starten. Die Zugriffe erfolgen jetzt über den Apache Webserver mit den URLs http://tomcathost:80/simple_info1a/ bzw. https://tomcathost:443/simple_info1a/ (und analog für die zweite Webanwendung).




Die beim Zugriff über den Apache Webserver mit mod_jk sowie dem Tomcat AJP13-Connector auf Tomcat erzielten Ergebnisse sind mit denen des Tests T14 vergleichbar. Einzig bei Zugriffen auf HTTPS-Webseiten erfolgt im Unterschied zu Test T14 eine doppelte Abfrage des zu verwendenden Client-Zertifikats.


Zum Test der Berücksichtigung von Änderungen in der Authentisierungsdatenbank wird die Applikation simple_info2 verwendet, die über die beiden Webseiten http://tomcathost/simple_info2/index.jsp und http://tomcathost/simple_info2/confidential.jsp (in Verbindung mit dem AJP Connector bzw. in Verbindung mit dem HTTP Connector unter zusätzlicher Angabe der Portnummer :8080 in der URL).

5.1.1.3.1 T19.1: HTTP Connector, BASIC-Authentisierung, Memory RealmNach einer Erstverbindung zu http://tomcathost:8080/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der Datei $CATALINA_HOME/conf/tomcat-users.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinformation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich.

Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost:8080/simple_info2/index.jsp mit der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen, so erscheint erneut ein Browser-Popup-Fenster zur Authentisierung. Hier ist jetzt das neu gesetzte Passwort einzugeben, um auf die Webseite zugreifen zu können. Im Gegensatz zum ersten Test übernimmt Tomcat die per admin Webanwendung geänderte Passwortinformation sofort.

5.1.1.3.2 T19.2: HTTP Connector, BASIC-Authentisierung, JDBC RealmNach einer Erstverbindung zu http://tomcathost:8080/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer jdbcuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der MySQL-Datenbank modifiziert:

Listing 30: Kommandos zur Passwort-Änderung in der MySQL-Datenbankmysql> use authority;mysql> update users set user_pass = “<neues_passwort>“ where user_name = “jdbcuser2“;

Anschließend wird über http://tomcathost:8080/simple_info2/confidential.jsp auf die zweite Webseite zugegriffen. Hierzu werden die geänderten Authentisierungsinformationen in einem Browser-Popup-Fenster abgefragt. Somit übernimmt Tomcat die geänderten Passwortinformationen sofort. Nach Durchführung des Tests wird das Passwort in der Datenbank für weitere Tests wieder auf den ursprünglichen Zustand zurück gesetzt.



5.1.1.3.3 T19.3: HTTP Connector, BASIC-Authentisierung, JNDI RealmNach einer Erstverbindung zu http://tomcathost:8080/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer jndiuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der LDAP-Datenbank mit dem LDAP-Browser gq modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen. Hierzu werden die geänderten Authentisierungsinformationen in einem Browser-Popup-Fenster abgefragt. Somit übernimmt Tomcat die geänderten Passwortinformationen sofort.

5.1.1.3.4 T20: HTTP Connector, DIGEST-Authentisierung, Memory RealmNach einer Erstverbindung zu http://tomcathost:8080/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der Datei $CATALINA_HOME/conf/tomcat-users.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinformation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich.

Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost:8080/simple_info2/index.jsp mit der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen, so erscheint erneut ein Browser-Popup-Fenster zur HTTP-Authentisierung. Hier ist jetzt das neu gesetzte Passwort einzugeben, um auf die Webseite zugreifen zu können. Im Gegensatz zum ersten Test übernimmt Tomcat die per admin Webanwendung geänderte Passwortinformation sofort.

5.1.1.3.5 T21: HTTP Connector, FORM-Authentisierung, Memory RealmZur Durchführung der Tests mit FORM-Authentisierung werden der Tomcat-Konfigurationsdatei $CATALINA_HOME/webapps/simple_info2/WEB-INF/web.xml jeweils die Einträge innerhalb des <login-config> Abschnitts ergänzt und die Authentisierungsmethode von <auth-method>BASIC</auth-method> auf <auth-method>FORM</auth-method> umgestellt (s. [Moczar], S. 316 ff.).

Listing 31: Ergänzung in der Konfigurationsdatei der Webanwendung WEB-INF/web.xml<form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page></form-login-config>

Nach einer Erstverbindung zu http://tomcathost:8080/simple_info2/index.jsp und der erforderlichen Authentisierung mit Benutzer memuser2 / Passwort vmware in der automatisch aufgerufenen Webseite http://tomcathost:8080/simple_info2/login.jsp wird das Passwort in der Datei $CATALINA_HOME/conf/tomcat-users.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinformation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich.




Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost:8080/simple_info2/index.jsp mit der erforderlichen Authentisierung mit Benutzer memuser2 / Passwort vmware in der automatisch aufgerufenen Webseite http://tomcathost:8080/simple_info2/login.jsp geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen, so ist diese im Gegensatz zur BASIC-Authentisierung ohne weitere Authentisierung möglich. Die per admin Webanwendung geänderte Passwortinformation werden somit nicht sofort verwendet.

5.1.1.3.6 T22: HTTPS Connector, Client Zertifikat Authentisierung, Memory RealmNach der Erstverbindung zu https://tomcathost:8443/simple_info2/ werden die Rollenzuordnungen der beiden Zertifikat-gebundenen Benutzer in der Datei $CATALINA_HOME/conf/tomcat_users.xml vertauscht (roles: user1 ↔ user2).

Listing 32: Änderung in der Tomcat-Benutzer-Konfigurationsdatei tomcat_users.xml <user username="CN=memuser1, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn, ST=NRW, C=DE" password="null" roles="user1"/> <user username="CN=memuser2, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn, ST=NRW, C=DE" password="null" roles="user2"/>

Anschließend erfolgt ein Zugriff auf die gleichfalls für die ursprüngliche Rolle freigegebene Webseite https://tomcathost:8443/simple_info2/confidential.jsp.

Bei einer Änderung mit einem Texteditor werden im Test die Modifikationen der Zugriffsberechtigungen erst mit einem Neustart von Tomcat wirksam, sodass der Zugriff auf die zweite Webseite nicht abgewiesen wird.

Bei einer Änderung über die admin Webanwendung ist die Änderung im Test hingegen sofort wirksam, sodass der zweite Zugriff mit einer Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser abgewiesen wird, da die im Webbrowser gespeicherten Kontext- (Session) und Authentikationsinformationen nun nicht mehr zu den geänderten Einstellungen passen.

5.1.1.3.7 T23.1: AJP1.3 Connector, BASIC-Authentisierung, Memory RealmNach einer Erstverbindung zu http://tomcathost/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der Datei $CATALINA_HOME/conf/tomcat-users.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinformation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich.

Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost/simple_info2/index.jsp mit der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen, so erscheint erneut ein Browser-



Popup-Fenster zur HTTP-Authentisierung. Hier ist jetzt das neu gesetzte Passwort einzugeben, um auf die Webseite zugreifen zu können. Im Gegensatz zum ersten Test übernimmt Tomcat die per admin Webanwendung geänderte Passwortinformation sofort.

5.1.1.3.8 T23.2: AJP1.3 Connector, BASIC-Authentisierung, JDBC RealmNach einer Erstverbindung zu http://tomcathost/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer jdbcuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in MySQL-Datenbank modifiziert:

Listing 33: Kommandos zur Passwort-Änderung in der MySQL-Datenbankmysql> use authority;mysql> update users set user_pass = “<neues_passwort>“ where user_name = “jdbcuser2“;

Anschließend wird auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen. Hierzu werden die geänderten Authentisierungsinformationen in einem Browser-Popup-Fenster abgefragt. Somit übernimmt Tomcat die geänderten Passwortinformationen sofort. Nach Durchführung des Tests wird das Passwort in der Datenbank für weitere Tests wieder auf den ursprünglichen Zustand zurück gesetzt.

5.1.1.3.9 T23.3: AJP1.3 Connector, BASIC-Authentisierung, JNDI RealmNach einer Erstverbindung zu http://tomcathost/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer jndiuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der LDAP-Datenbank mit dem LDAP-Browser gq modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen. Daraufhin werden die geänderten Authentisierungsinformationen in einem Browser-Popup-Fenster abgefragt. Mit den überschriebenen Authentisierungsinformationen ist ein Zugriff nicht mehr möglich.

5.1.1.3.10 T24: AJP1.3 Connector, DIGEST-Authentisierung, Memory RealmZur Durchführung der Tests mit DIGEST-Authentisierung wird in der Tomcat-Konfigurationsdatei $CATALINA_HOME/webapps/simple_info2/WEB-INF/web.xml die Authentikationsmethode von <auth-method>BASIC</auth-method> auf <auth-method>FORM</auth-method> umgestellt und Tomcat neu gestartet.

Nach einer Erstverbindung zu http://tomcathost/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der Datei $CATALINA_HOME/conf/tomcat-users.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinformation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich.

Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost/simple_info2/index.jsp mit der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite




http://tomcathost/simple_info2/confidential.jsp zugegriffen, so erscheint erneut ein Browser-Popup-Fenster zur HTTP-Authentisierung. Hier ist jetzt das neu gesetzte Passwort einzugeben, um auf die Webseite zugreifen zu können. Im Gegensatz zum ersten Test übernimmt Tomcat die per admin Webanwendung geänderte Passwortinformation sofort.

5.1.1.3.11 T25: AJP1.3 Connector, FORM-Authentisierung, Memory RealmZur Durchführung der Tests mit FORM-Authentisierung werden in der Tomcat-Konfigurationsdatei $CATALINA_HOME/webapps/simple_info2/WEB-INF/web.xml die Einträge innerhalb des <login-config> Abschnitts ergänzt und die Authentisierungsmethode von <auth-method>BASIC</auth-method> auf <auth-method>FORM</auth-method> umgestellt (s. [Moczar], S. 316 ff.) und Tomcat neu gestartet.

Listing 34: Ergänzung in der Konfigurationsdatei der Webanwendung WEB-INF/web.xml<form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page></form-login-config>

Nach einer Erstverbindung zu http://tomcathost/simple_info2/index.jsp und der erforderlichen Authentisierung mit Benutzer memuser2 / Passwort vmware in der automatisch aufgerufenen Webseite http://tomcathost/simple_info2/login.jsp wird das Passwort in der Datei $CATALINA_HOME/conf/tomcat-users.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinformation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich.

Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost/simple_info2/index.jsp mit der erforderlichen Authentisierung mit Benutzer memuser2 / Passwort vmware in der automatisch aufgerufenen Webseite http://tomcathost/simple_info2/login.jsp geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen, so ist diese im Gegensatz zur BASIC-Authentisierung ohne weitere Authentisierung möglich. Die per admin Webanwendung geänderte Passwortinformation werden somit nicht sofort verwendet.

Somit entsprechen die Ergebnisse denen aus Test T21.

5.1.1.3.12 T26: AJP1.3 / SSL Connector, Client Zertifikat Authentisierung, Memory RealmTest T26 wird analog zu Test T22 durchgeführt, wobei jetzt die URLs https://tomcathost:443/simple_info2/ bzw. https://tomcathost:443/simple_info2/confidential.jsp verwendet werden.

Das Verhalten entspricht im Fall der Änderung der Authentisierungsinformationen per Texteditor demjenigen aus Test22.



Nach einer Änderung mit der admin Webanwendung hingegen wird der Zugriff auf die zweite Webseite nicht sofort mit einer Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser abgewiesen sondern es erfolgt eine erneute Abfrage eines Client-Zertifikates. Wenn dies zu den geänderten Autorisierungsinformationen passt, ist eine Fortsetzung der Web-Session möglich. Wird hingegen das für den ersten Zugriff verwendete Zertifikat, das nach der Änderung nun nicht mehr zu den Autorisierungsinformationen passt, vorgelegt, so wird der Zugriff mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser abgewiesen.

5.1.2 Funktionale Tests für die Zugriffskontrolle

Für die drei Möglichkeiten der Zugriffskontrolle in Tomcat sind die im folgenden aufgelisteten unterschiedlichen Tests vorgesehen.

5.1.2.1 Tests der Zugriffsrechte auf dem Niveau der Java Virtual Machine

Wird Tomcat ohne Java Security Manager gestartet, so können Webanwendungen u. a.

• Tomcat beenden,

• einen neuen Prozess erzeugen,

• einen Netzwerk-Socket öffnen und darüber Daten übertragen,

• auf das Dateisystem mit den Rechten des Tomcat zugreifen sowie

• auf interne Tomcat-Komponente (Java Pakete, Classes) zugreifen, die mit erhöhten Rechten laufen.

Aus diesen Gründen sollte Tomcat in produktiven Umgebungen immer mit einer Java Security Policy gestartet werden.

Als Ausgangsbasis für die Tests dient die Java Security Policy, die mit Tomcat mitgeliefert und in den Konfigurationsdateien catalina.policy und catalina.properties definiert wird. Die Test-Webanwendungen (JSP oder Servlet, je nachdem, welche Fähigkeit benötigt wird) werden für die einzelnen Tests erstellt. Im Test wird überprüft, ob die oben genannten Möglichkeiten bei eingeschalteter Default Security Policy für die entsprechende Test-Webanwendung nur entsprechend der Dokumentation des Tomcat möglich sind:




Test Nr.

Beschreibung erwartetes Resultat

Bemerkung

T 27 Tomcat beenden möglich? NeinT 28 Einen neuen Prozess erzeugen möglich? NeinT 29 Einen Netzwerk-Socket öffnen und darüber

Daten übertragen möglich?Nein

T 30 Das Lesen / Schreiben / Ausführen / Löschen einer Datei40 innerhalb des Verzeichnisses der Webanwendung möglich?

Nur Lesen41 (laut Dokumentation möglich)

T 31 Das Lesen / Schreiben / Ausführen / Löschen einer Datei außerhalb des Verzeichnisses der Webanwendung möglich?

Nein

T 32 Zugriff auf Tomcat-eigene Komponenten möglich? (Java-Pakete mit Namen wie sun.*, org.apache.catalina.*, ...)

Nein (laut Vorgaben aus der Datei catalina.properties)

Tabelle 4: Funktionale Tests der Zugriffskontrolle auf dem Niveau der Java Virtual Machine

5.1.2.1.1 T27 Tomcat beendenEs wird ein Servlet definiert, welches i. W. die folgende Zeile enthält:

java.lang.System.exit(9);

Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert (500 bedeutet laut HTTP-Protokoll Server-interner Fehler). Beim Backtrace erscheint im Browser deutlich der Eingriff des Security Managers von Java:

The server encountered an internal error () that prevented it from fulfilling this request.

java.security.AccessControlException: access denied (java.lang.RuntimePermission exitVM)java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkExit(SecurityManager.java:744)java.lang.Runtime.exit(Runtime.java:88)java.lang.System.exit(System.java:868)

Der Backtrace ist tatsächlich umfangreicher und wird in den folgenden Tests nur noch um den konstanten Teil verkürzt dargestellt:

javax.servlet.http.HttpServlet.service(HttpServlet.java:689)javax.servlet.http.HttpServlet.service(HttpServlet.java:802)org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:419)org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:133)javax.servlet.http.HttpServlet.service(HttpServlet.java:689)javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

40 Die Zugriffsrechte werden auf Dateisystem-Ebene so gesetzt, dass der Tomcat Prozess die erforderlichen Rechte hat. Der Zugriff soll auf Ebene der Anwendung verweigert werden, während das Betriebssystem ihn zulassen würde.

41 Im Feinkonzept stand hier „Ja“. Jedoch werden sowohl in der Tomcat-Dokumentation in http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html als auch in der Datei catalina.policy lediglich Leserechte aufgeführt.



sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)java.lang.reflect.Method.invoke(Method.java:585)org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:243)java.security.AccessController.doPrivileged(Native Method)javax.security.auth.Subject.doAsPrivileged(Subject.java:517)org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:275)org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:161)java.security.AccessController.doPrivileged(Native Method)filters.ExampleFilter.doFilter(ExampleFilter.java:101)sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)java.lang.reflect.Method.invoke(Method.java:585)org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:243)java.security.AccessController.doPrivileged(Native Method)javax.security.auth.Subject.doAsPrivileged(Subject.java:517)org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:275)org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:217)

note The full stack trace of the root cause is available in the Apache Tomcat/5.5.9 logs.

5.1.2.1.2 T28 neuen Prozess startenDieser Fall ist deckungsgleich mit dem Versuch des Ausführens von Programmen in T30 und T31.

Im Gegensatz zu externen Prozessen können Java-interne Threads sehr wohl von einer Webanwendung gestartet werden. Getestet wurde wie folgt:

Listing 35: Datei webapps/WEB-INF/classes/TryThread.javapublic class TryThread implements Runnable {

TryThread(long v, String comment) { }

public void run() {try { java.lang.Thread.sleep(2000,0); throw new NullPointerException();} catch (InterruptedException e) { // nothing}

}}

Ein Thread kann innerhalb eines Servlet wie folgt gestartet werden:

TryThread x = new TryThread(1000,"Try it out");new Thread(x).start();

In der Logdatei catalina.out erscheint daraufhin die vom Thread provozierte NullPointerException, als Nachweis der Programmausführung, während die Webanwendung erfolgreich die Webseite zum Browser liefert:




Exception in thread "Thread-33" java.lang.NullPointerException at TryThread.run(TryThread.java:9) at java.lang.Thread.run(Thread.java:595)java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1158) at TryExec.doGet(TryExex.java:51)

5.1.2.1.3 T29 Netzwerk-Socket öffnen und Daten übertragenDas Anlegen eines sogenannten passiven Sockets für einen Server auf Port 20000 wird mit einem Servlet getestet, das im Wesentlichen folgendes enthält:

java.net.ServerSocket svs = new java.net.ServerSocket(20000);svs.close();

Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert. Beim Backtrace erscheint im Browser der Eingriff des Security Managers von Java:

java.security.AccessControlException: access denied (java.net.SocketPermission localhost:20000 listen,resolve)

java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkListen(SecurityManager.java:1120)java.net.ServerSocket.bind(ServerSocket.java:318)java.net.ServerSocket.<init>(ServerSocket.java:185)java.net.ServerSocket.<init>(ServerSocket.java:97)

5.1.2.1.4 T30.1 Lesen innerhalb des Bereichs der Web-AnwendungVielfältige Lesezugriffe sind möglich, sowohl auf Dateien als auch auf das Dateisystem. Verschiedene Zugriffsversuche wurden getestet, zunächst einmal:

import java.io.*;File f = new File(".");out.println(f.getAbsolutePath());

Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert. Auch hier ist der Eingriff des Security-Managers von Java im Browser sichtbar, jedoch wurde beim Versuch, das mit „.“ bezeichnete, „aktuelle“ Verzeichnis aufzulösen, der Zugriff auf die Java Property user.dir verwehrt:

java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read)

java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)java.lang.System.getProperty(System.java:627)java.io.UnixFileSystem.resolve(UnixFileSystem.java:118)java.io.File.getAbsolutePath(File.java:473)

Folgende Zugriffsversuche wurden ebenfalls verwehrt:



import java.io.*;File f = new File("index.html");out.println(f.exists());

oder:

import java.io.*;File f = new File(".");out.println(f.canRead());

mit der Fehlermeldung:

java.security.AccessControlException: access denied (java.io.FilePermission . read)java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkRead(SecurityManager.java:871)java.io.File.canRead(File.java:658)

Offensichtlich verfügen Servlets über keinen vereinfachten Zugriff über relative Pfadnamen auf Dateien in ihrem jeweiligem Verzeichnis. Stattdessen funktioniert der Zugriff über den vollen Pfadnamen, beginnend mit „/“:

import java.io.*;File f = new File("/opt/tomcat...webapps/.../index.html");out.println(f.canRead());

Als Ergebnis wird der Wert „true“ ausgegeben und das folgende Servlet kann daher das erste Byte auslesen:

import java.io.*;File f = new File("/opt/tomcat...webapps/.../index.html");FileInputStream fis = new FileInputStream(f);out.println(fis.read());fis.close();

Es erscheint 60, der ASCII-Code für das Zeichen „<“ vom öffnenden Tag des HTML-Dokuments index.html.

5.1.2.1.5 T30.2 Schreiben innerhalb des Bereichs der Web-AnwendungDas Anlegen von neuen Dateien mit java.io.File.createNewFile wird zurückgewiesen. Dabei wird der vollständige Pfad benutzt, der beim Lesen erlaubt war:

import java.io.*;File f = new File("/opt/tomcat...webapps/.../foobar");out.println(f.createNewFile());

Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert. Auch hier ist der Eingriff des Security-Managers von Java im Browser sichtbar:




java.security.AccessControlException: access denied (java.io.FilePermission /opt/tomcat...webapps/.../foobar write)

java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkWrite(SecurityManager.java:962)java.io.File.createNewFile(File.java:849)

Der Versuch des Anlegens einer neuen Datei über die Klasse java.io.FileOutputStream wird ebenfalls zurückgewiesen:

import java.io.*;File f = new File("/opt/tomcat...webapps/.../foobar");FileOutputStream fs = new FileOutputStream(f);fs.close();

Quittiert mit der gleichlautenden Fehlermeldung:

java.security.AccessControlException: access denied (java.io.FilePermission /opt/tomcat...webapps/.../foobar write)

java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkWrite(SecurityManager.java:962)java.io.FileOutputStream.<init>(FileOutputStream.java:169)java.io.FileOutputStream.<init>(FileOutputStream.java:131)

5.1.2.1.6 T30.3 Löschen innerhalb des Bereichs der Web-AnwendungDas Löschen der vorhandenen Datei index.html wird zurückgewiesen. Dabei wird der vollständige Pfad benutzt, der beim Lesen erlaubt war:

import java.io.*;File f = new File("/opt/tomcat...webapps/.../index.html");out.println(f.delete());

Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert. Auch hier ist der Eingriff des Security-Managers von Java im Browser sichtbar:

java.security.AccessControlException: access denied (java.io.FilePermission /opt/jakarta-tomcat-5.5.9/webapps/.../index.html delete)

java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkDelete(SecurityManager.java:990)java.io.File.delete(File.java:869)

Ähnlich verhält es sich mit dem Versuch, über java.io.File.deleteOnExit eine Zeitbombe (löschen beim beenden) einzufügen:

import java.io.*;File f = new File("/opt/tomcat...webapps/.../index.html");f.deleteOnExit();



Quittiert wird hierbei mit der Fehlermeldung:

java.security.AccessControlException: access denied (java.io.FilePermission /opt/jakarta-tomcat-5.5.9/webapps/.../index.html delete)

java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkDelete(SecurityManager.java:990)java.io.File.deleteOnExit(File.java:901)

5.1.2.1.7 T30.4 Ausführen innerhalb des Bereichs der Web-AnwendungDas Ausführen von Programmen wird zurückgewiesen. Beim Test wird ein vollständiger Pfad benutzt, wie er beim Lesen erlaubt war. Das Programm /bin/true wurde dazu in das Verzeichnis webapps/.../WEB-INF/classes/ kopiert.

java.lang.Runtime.getRuntime().exec("/opt/jakarta-tomcat-5.5.9/webapps/xyztests/WEB-INF/classes/true");


java.security.AccessControlException: access denied (java.io.FilePermission /opt/jakarta-tomcat-5.5.9/webapps/xyztests/WEB-INF/classes/true execute)

java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkExec(SecurityManager.java:779)java.lang.ProcessBuilder.start(ProcessBuilder.java:447)java.lang.Runtime.exec(Runtime.java:591)java.lang.Runtime.exec(Runtime.java:429)java.lang.Runtime.exec(Runtime.java:326)TryExec.doGet(TryExec.java:71)

5.1.2.1.8 T31 Lesen / Schreiben / Löschen / Ausführen außerhalb der Web-AnwendungEs wird zunächst ein Servlet definiert, welches versucht das Vorhandensein der Datei index.html einer Nachbar-Webanwendung abzufragen:

File f = new File("/opt/jakarta-tomcat-5.5.9/webapps/jsp-examples/index.html");out.println(f.exists());

Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert (500 bedeutet laut HTTP-Protokoll Server-interner Fehler). Beim Backtrace erkennt man im Browser deutlich den Eingriff des Security Managers von Java:

java.security.AccessControlException: access denied (java.io.FilePermission /opt/jakarta-tomcat-5.5.9/webapps/jsp-examples/index.html read)

java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkRead(SecurityManager.java:871)java.io.File.exists(File.java:700)

Ein Schreibversuch, diesmal ins Verzeichnis /tmp/, wird ebenfalls zurückgewiesen:

File f = new File("/tmp/foobar");




FileOutputStream fs = new FileOutputStream(f);fs.close();

Die Fehlermeldung lautet bei allen Versuchen vergleichbar wie folgt:

description The server encountered an internal error () that prevented it from fulfilling this request.exception java.security.AccessControlException: access denied (java.io.FilePermission /tmp/foobar write)

java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkWrite(SecurityManager.java:962)java.io.FileOutputStream.<init>(FileOutputStream.java:169)java.io.FileOutputStream.<init>(FileOutputStream.java:131)

Der Versuch, das Programm /bin/true auszuführen, wird ebenfalls zurückgewiesen:

java.lang.Runtime.getRuntime().exec("/bin/true");


java.security.AccessControlException: access denied (java.io.FilePermission /bin/true execute)

java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkExec(SecurityManager.java:779)java.lang.ProcessBuilder.start(ProcessBuilder.java:447)java.lang.Runtime.exec(Runtime.java:591)java.lang.Runtime.exec(Runtime.java:429)java.lang.Runtime.exec(Runtime.java:326)TryExec.doGet(TryExec.java:70)

5.1.2.1.9 T32 Zugriff auf Tomcat-eigene KomponentenEs wird ein Servlet definiert, welches im Wesentlichen die folgende Zeile enthält:

out.println(org.apache.catalina.realm.RealmBase.Digest("abc","def","0"));

Bei eingeschalteter Security Policy wird der Aufruf des Servlets erwartungsgemäß mit HTTP-Status 500 quittiert. Auch hier ist der Eingriff des Security-Managers von Java im Browser sichtbar:

java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.realm)

java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)java.lang.ClassLoader.loadClass(ClassLoader.java:251)org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1247)org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181)



java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

Wird stattdessen auf eine öffentliche Konstante von org.apache.catalina zugegriffen, z. B. innerhalb von org.apache.catalina.realm.Constants, so wird der Zugriff erlaubt.

public static final String FORM_ACTION = "/j_security_check";

Im Servlet steht:

out.println(org.apache.catalina.realm.Constants.FORM_ACTION);

Der Text /j_security_check erscheint im Browser. Möglicherweise wird aufgrund der Deklaration final der Wert in das compilierte Servlet übernommen, sodass vielleicht keine Referenz mehr auf das Paket catalina vorhanden ist.

5.1.2.2 Tests der Zugriffsrechte auf dem Niveau von Webanwendungen

Diese Tests werden über den HTTP und den AJP1.3 Connector durchgeführt.

Test Nr.

Tomcat-Connector


T 33 HTTP und AJP

In der web.xml Datei einer Webanwendung wird eine einzelne JSP-Seite vor anonymen Zugriffen geschützt. Es wird untersucht, ob es möglich ist, ohne Authentisierung auf diese Datei zuzugreifen.

nicht möglich

T 34 HTTP und AJP

In der web.xml Datei einer Webanwendung wird ein Verzeichnis vor anonymen Zugriffen geschützt. Es wird untersucht, ob es möglich ist, ohne Authentisierung auf Web-Ressourcen unterhalb dieses Verzeichnisses zuzugreifen.

nicht möglich

T 35 HTTP und AJP

In der web.xml Datei einer Webanwendung werden einzelne HTTP Methoden (DELETE, PUT, GET, POST) vor anonymen Zugriffen geschützt. Es wird untersucht, ob es möglich ist, ohne Authentisierung mit den entsprechenden Methoden auf Web-Ressourcen zuzugreifen.

nicht möglich

Tabelle 5: Funktionale Tests der Zugriffskontrolle auf dem Niveau der Webanwendungen

Die hier überprüften Mechanismen regeln den Zugriff auf dem Niveau der einzelnen Webanwendung und sind somit für alle Einsatzszenarien aus dem Feinkonzept [TomcatFein.] von Bedeutung. Da der Zugriff auf die Webanwendung beim Einsatzszenario 1 (mit HTTP Connector) prinzipiell anders ist als bei allen anderen Einsatzszenarien (mit AJP Connector), werden diese Tests für Einsatzszenario 1 und Einsatzszenario 2 wiederholt.

Die Tests T33 und T34 werden in Verbindung mit der Webanwendung simple_info1 durchgeführt. Neben einer ungeschützten Startseite index.jsp verfügt die Webanwendung über zwei geschützte Webseiten confidential.jsp sowie subdir/moreinfo.jsp, die nur für Zugriffe von authentisierten Benutzern mit einer Rollenzuordnung user1 freigegeben sind.




Die geschützten Webseiten bzw. -verzeichnisse sind innerhalb der web.xml Datei dieser Webanwendung wie folgt festgelegt:

Listing 36: Definition geschützter Bereiche in der Konfigurationsdatei der Webanwendung WEB-INF/web.xml

 <security-constraint> <web-resource-collection> <web-resource-name>Simple_Info1 JSP Application</web-resource-name> <url-pattern>/confidential.jsp</url-pattern> <url-pattern>/subdir/</url-pattern> <url-pattern>/subdir/*</url-pattern> </web-resource-collection> <auth-constraint>  <role-name>user1</role-name> </auth-constraint> </security-constraint>

5.1.2.2.1 T33.1 HTTP Connector, Zugriff auf eine geschützte JSP-SeiteEs erfolgt aus der allgemein freigegebenen Webseite http://tomcathost:8080/simple_info1 heraus ein Zugriff auf die nur für authentisierte Benutzer mit einer Rollenzuordnung user1 freigegebene Webseite http://tomcathost:8080/simple_info1/confidential.jsp. Ein Browser-Popup-Fenster öffnet sich, um eine HTTP-Benutzeranmeldung durchzuführen. Es existieren nun 4 mögliche Fälle:

• Die HTTP-Authentisierung wird im Popup-Fenster mit Cancel abgebrochen. Tomcat gibt darauf hin die Fehlermeldung „HTTP Status 401: This request requires HTTP authentication ()“ im Browser zurück. Ein Zugriff auf die geschützte Webseite ist nicht möglich.

• Wird in das Popup-Fenster ein ungültiger Benutzername und / oder ein ungültiges Passwort eingegeben, so wird die Authentisierung abgelehnt und das Popup-Fenster erneut geöffnet. Ein Zugriff auf die geschützte Webseite ist ohne erfolgreiche Authentisierung auch nach mehreren Fehlversuchen nicht möglich.

• Die HTTP-Authentisierung wird im Popup-Fenster mit einer gültigen Benutzerkennung (Benutzer memuser2 / Passwort vmware) durchgeführt, die jedoch nicht über die benötigte Rollenzuordnung verfügt. Tomcat gibt darauf hin die Fehlermeldung „HTTP Status 403: Access to the requested resource has been denied“ im Browser zurück. Ein Zugriff auf die geschützte Webseite ist nicht möglich.

• Die HTTP-Authentisierung wird im Popup-Fenster mit einer gültigen Benutzerkennung (Benutzer memuser1 / Passwort vmware) durchgeführt, die über die benötigte Rollenzuordnung verfügt. Tomcat gibt darauf die angeforderte Webseite wie erwartet zurück.



5.1.2.2.2 T33.2 AJP13 Connector, Zugriff auf eine geschützte JSP-SeiteEs erfolgt aus der allgemein freigegebenen Webseite http://tomcathost/simple_info1 heraus ein Zugriff auf die nur für authentisierte Benutzer mit einer Rollenzuordnung user1 freigegebene Webseite http://tomcathost/simple_info1/confidential.jsp. Ein Browser-Popup-Fenster öffnet sich, um eine HTTP-Benutzeranmeldung durchzuführen. Es existieren nun 4 mögliche Fälle:

• Die HTTP-Authentisierung wird im Popup-Fenster mit Cancel abgebrochen. Tomcat gibt darauf hin die Fehlermeldung „HTTP Status 401: This request requires HTTP authentication ()“ im Browser zurück. Ein Zugriff auf die geschützte Webseite ist nicht möglich.

• Wird in das Popup-Fenster ein ungültiger Benutzername und / oder ein ungültiges Passwort eingegeben, so wird die Authentisierung abgelehnt und das Popup-Fenster erneut geöffnet. Ein Zugriff auf die geschützte Webseite ist nicht möglich.

• Die HTTP-Authentisierung wird im Popup-Fenster mit einer gültigen Benutzerkennung (Benutzer memuser2 / Passwort vmware) durchgeführt, die jedoch nicht über die benötigte Rollenzuordnung verfügt. Tomcat gibt darauf hin die Fehlermeldung „HTTP Status 403: Access to the requested resource has been denied“ im Browser zurück. Ein Zugriff auf die geschützte Webseite ist nicht möglich.

• Die HTTP-Authentisierung wird im Popup-Fenster mit einer gültigen Benutzerkennung (Benutzer memuser1 / Passwort vmware) durchgeführt, die über die benötigte Rollenzuordnung verfügt. Tomcat gibt darauf die angeforderte Webseite zurück.

5.1.2.2.3 T34.1 HTTP Connector, Zugriff auf ein geschütztes Verzeichnis Im Rahmen dieses Tests werden zur Überprüfung des Zugriffsschutzes Zugriffe auf die geschützte URL http://tomcathost:8080/simple_info1/subdir sowie auf die zur gleichen Webanwendung gehörige URL http://tomcathost:8080/simple_info1/subdir/moreinfo.jsp durchgeführt.

Die beim Test erzielten Ergebnisse entsprechen denen aus Test T33.1, d. h. ein Zugriff ist nur nach erfolgreicher vorheriger Authentisierung möglich.

5.1.2.2.4 T34.2 AJP13 Connector, Zugriff auf ein geschütztes Verzeichnis Dieser Test nutzt Zugriffe auf die geschützten URLs http://tomcathost/simple_info1/subdir sowie http://tomcathost/simple_info1/subdir/moreinfo.jsp.

Die beim Test erzielten Ergebnisse entsprechen denen aus Test T33.2, d. h. ein Zugriff ist nur nach erfolgreicher vorheriger Authentisierung möglich.

5.1.2.2.5 T35 Schutz einzelner HTTP-Methoden vor anonymen ZugriffenZur Durchführung von Test T35 wird zunächst die Webseite simple_info1/request_data.jsp, die bislang ohne weiteren Zugriffsschutz konfiguriert war, mit einer entsprechenden Zugriffsrestriktion in der Konfigurationsdatei simple_info1/WEB-INF/web.xml versehen. Abgebildet ist in Listing 5.10 der Endzustand, die <http-method> Zeilen werden nach jedem Teiltest schrittweise ergänzt:




Listing 37: Spezifikation des HTTP-Methoden-basierten Zugriffsschutzes in der Konfigurationsdatei der Webanwendung WEB-INF/web.xml

...  <security-constraint> <web-resource-collection> <web-resource-name>Simple_Info1 JSP Application</web-resource-name> <url-pattern>/confidential.jsp</url-pattern> <url-pattern>/subdir/</url-pattern> <url-pattern>/subdir/*</url-pattern> </web-resource-collection> <web-resource-collection> <web-resource-name>Simple_Info1 HTTP Access Auth Check</web-resource-name> <url-pattern>/request_data.jsp</url-pattern> <http-method>GET</http-method> <http-method>HEAD</http-method> <http-method>PUT</http-method> <http-method>POST</http-method> <http-method>DELETE</http-method> </web-resource-collection> <auth-constraint>  <role-name>user1</role-name> </auth-constraint> </security-constraint>...

Bei den nun folgenden Zugriffsversuchen auf die URL http://tomcathost:8080/simple_info1/request_data.jsp (Tomcat HTTP-Connector) bzw. http://tomcathost:80/simple_info1/request_data.jsp (via Apache Webserver mit mod_jk auf Tomcat mit AJP-Connector) per Webbrowser bzw. telnet wurde der Zugriff der Reihe nach per GET, HEAD, PUT, POST und DELETE Methode auf die betreffende URL im jeweils ersten Zugriff (ohne zugehörige Zeile <http-method>) erlaubt und beim jeweils zweiten Zugriff (nun mit zugehöriger Zeile <http-method>) ohne vorherige Authentisierung mit der Fehlermeldung HTTP 401 Unauthorized blockiert.

Als Beispiel für die Zugriffstests ist das Protokoll der Direktzugriffe auf den Tomcat HTTP-Connector vor und nach Einfügung der Zeile <http-method>GET</http-method> in die Konfigurationsdatei web.xml hier mit eingefügt, der zunächst die hinterlegte Webseite korrekt zurück gibt:

Listing 38: Ausgaben beim Zugriffstest ohne Zugriffsbeschränkungdebian-host1:/opt/jakarta-tomcat-5.5.9/logs# telnet localhost 8080Trying 127.0.0.1...Connected to localhost.localdomain.Escape character is '^]'.GET /simple_info1/request_data.jsp HTTP/1.0

HTTP/1.1 200 OKServer: Apache-Coyote/1.1Set-Cookie: JSESSIONID=FFE7DC47922C502F1A8DE4D6334F2268; Path=/simple_info1Content-Type: text/html;charset=ISO-8859-1Content-Length: 367Date: Thu, 03 Nov 2005 13:57:44 GMTConnection: close

<html>



<head> <title> Display HTTP Request Data </title> </head><body>

<h1>Request = <br /> GET localhost.localdomain: 8080 HTTP/1.0 </h1>

<hr /> <h2><font color=red>Request header entries:</font></h2>

<hr /> <h2><font color=red>Request parameters:</font></h2>

<hr /> <h2><font color=red>Request attributes:</font></h2>

<hr /></body></html>Connection closed by foreign host.

Nach Einfügung der Zeile <http-method>GET</http-method> in die web.xml-Konfigurationsdatei der Webanwendung wird der Zugriff beim erneuten Versuch blockiert:

Listing 39: Ausgaben beim Zugriffstest mit Zugriffsbeschränkungdebian-host1:/opt/jakarta-tomcat-5.5.9/logs# telnet localhost 8080Trying 127.0.0.1...Connected to localhost.localdomain.Escape character is '^]'.GET /simple_info1/request_data.jsp HTTP/1.0

HTTP/1.1 401 UnauthorizedServer: Apache-Coyote/1.1Pragma: No-cacheCache-Control: no-cacheExpires: Thu, 01 Jan 1970 01:00:00 CETWWW-Authenticate: Basic realm="Simple_Info1 Realm"Content-Type: text/html;charset=utf-8Content-Length: 952Date: Thu, 03 Nov 2005 13:58:18 GMTConnection: close

<html><head><title>Apache Tomcat/5.5.9 - Error report</title><style></style> </head><body><h1>HTTP Status 401 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>This request requires HTTP authentication ().</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/5.5.9</h3></body></html>Connection closed by foreign host.




Das gleiche Verhalten zeigt sich so auch bei den anderen HTTP-Zugriffsmethoden (HEAD, PUT, POST, DELETE), unabhängig davon ob die Verbindung direkt zum Tomcat HTTP-Connector oder via Apache Webserver mit mod_jk und Tomcat mit AJP-Connector aufgebaut wurde. Im letzten Fall ändert sich die Anweisung zum Aufbau der HTTP-Verbindung in telnet tomcathost 80:

• Ohne die Zeile zur Zugriffsbeschränkung wird die Anfrage ohne Authentisierung mit einem HTTP-Status 200 OK akzeptiert. Bei der vorliegenden Konfiguration werden allerdings keine Datei per PUT erzeugt, keine Informationen aus der POST-Anfrage ausgewertet und keine Löschoperation aus der DELETE-Anfrage heraus durchgeführt.

• Mit der Zugriffsbeschränkung wird die Anfrage mit einer Authentisierungsanforderung („HTTP-Status 401 Unauthorized“) unter Angabe des für die Authentisierung zu verwendenden Authentisierungs-Realm zurückgewiesen.

Da neben den getesteten HTTP-Zugriffsmethoden noch weitere existieren, z. B. OPTIONS, TRACE, CONNECT und außerdem für WebDAV die Methoden PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, s. a. [RFC2518], wurde im Tomcat-Quelltext nachgeprüft, dass prinzipiell beliebige HTTP-Zugriffsmethoden definiert werden können. Diese können dann als Zeile <http-method>...</http-method> in die Konfigurationsdatei WEB-INF/web.xml in den Bereich <web-resource-collection> der Webanwendung eingefügt werden. Beim Zugriff auf das zugehörige und per <url-pattern>...</url-pattern> definierte URL-Pattern wird nun eine Überprüfung auf Zulässigkeit per Zeichenkettenvergleich der HTTP-Methode und den spezifizierten Methoden, die eine Authentisierung erfordern, durchgeführt. Wichtig ist hierbei, dass immer ein zugehöriges URL-Pattern, für das die Einschränkung gelten soll, definiert sein muss.

Hinweis: Bei der Verwendung der <http-method> Direktiven ist zu beachten, dass nur für in der Liste aufgeführte Zugriffsmethoden eine Authentisierung erforderlich ist. Für die nicht genannten Zugriffsmethoden ist ein Zugriff ohne Authentisierung möglich, sofern diese nicht auf anderem Weg erzwungen wird. Diese Zugriffsmethoden sind somit nicht blockiert.

Hinweis: im Test T35 werden lediglich die Filtermöglichkeiten seitens Tomcat untersucht. Der Apache Webserver bietet darüber hinaus eine Beschränkung der HTTP-Zugriffsmethoden (GET, PUT, POST, DELETE, ...) in Verbindung mit der <Limit>-Direktive, die allerdings nicht Gegenstand der hier vorgenommenen Untersuchungen ist. Beim Apache Webserver wurden für diesen Test keine Restriktionen gesetzt.

5.1.2.3 Tests der Zugriffsrechte auf dem Niveau von Valves

Für diese Tests wird ein Request Filter Valve auf Host-Ebene definiert. Dieses soll die Anfragen an alle Webanwendungen des Hosts auf Basis der IP-Adresse oder des Hostnamens regeln. Beispielsweise wird durch die folgenden Einträge im Host-Bereich der server.xml-Datei ein „Remote Address Filter“ eingerichtet:

Listing 40: Request Filter Valve Ergänzung in der Tomcat-Konfigurationsdatei server.xml<Host name="localhost" ...> ...



<Valve className="org.apache.catalina.valves.RemoteAddrValve" deny="192.168.1.*"/> ...</Host>

Dieser Eintrag verbietet Anfragen von bestimmten IP-Adressen bzw. IP-Adressbereichen. Die Wirkungsweise des Filter Valves würde die gleiche sein, wenn es auf der Ebene der Webanwendung definiert wäre. Anders wäre dann die Reichweite, eben nur für diese spezifische Webanwendung, statt für den gesamten Tomcat Server. Valves werden von der Tomcat-Engine verwaltet, d. h. von einem hohen Niveau in der Tomcat-Architektur. Die Tomcat-Engines bekommen Nachrichten von Connectoren, bevor diese an ein Servlet oder JSP geleitet werden und umgekehrt. Die Filter Valves leiten Nachrichten abhängig vom Inhalt, aber unabhängig vom Installationskontext des Valves weiter bzw. nicht weiter. Deshalb ist eine Überprüfung des Valves auf dem Niveau des Hosts ausreichend, um die Sicherheitsfunktionalität zu testen.

Tabelle 6 zeigt die verschiedenen Filter, die durch diese Tests überprüft werden. Bei allen Tests wird versucht, von verschiedenen Maschinen aus auf eine von Tomcat verwaltete Webanwendung zuzugreifen.

Test Nr.

Tomcat-Connector

Beschreibung: Konfiguration des Valves

erwartetes Resultat: Zugriff vom Client / von anderen Maschinen

T 36 HTTP und AJP

Anfragen der IP-Adresse des Clients sollten verboten sein. („Remote Address Filter“)

nicht möglich / möglich

T 37 HTTP und AJP

Anfragen der IP-Adresse des Clients sollten erlaubt sein. („Remote Address Filter“)

möglich / nicht möglich

T 38 HTTP und AJP

Anfragen mit dem Hostnamen des Clients sollten verboten sein. („Remote Address Filter“)

nicht möglich / möglich

T 39 HTTP und AJP

Anfragen mit dem Hostnamen des Clients sollten erlaubt sein. („Remote Address Filter“)

möglich / nicht möglich

Tabelle 6: Funktionale Tests der Zugriffskontrolle auf dem Niveau von Valves

Diese Tests werden sowohl für die Konfiguration mit dem HTTP Connector (stand-alone, Einsatzszenario 1) als auch für die Konfiguration mit dem AJP Connector durchgeführt. Prinzipiell könnte es zwischen den zwei Connectoren Unterschiede in den übertragenen Informationen zum Client-System geben.

Zunächst wird die IP-Adresse des VMware-Hostsystems bigmama durch den Eintrag in der <Host> Deklaration innerhalb von $CATALINA_HOME/conf/server.xml vom Zugriff ausgeschlossen.

Listing 41: IP-Address Filter Eintrag in der Tomcat-Konfigurationsdatei server.xml<Valve className=“org.apache.catalina.valves.RemoteAddrValve“deny=“192.168.118.1“/>




Hinweis: Im Verlauf der Tests wurde festgestellt, dass zwar Wildcard-Character in der IP-Adresse verwendet werden dürfen (z. B. 192.168.118.*), die Verwendung der alternativen Notation 192.168.118.0/24 jedoch nicht zum Ausschluss der entsprechenden IP-Adressen führt. Dies könnte in Verbindung mit dem Ausschluss von IP-Adressbereichen, die kein vollständiges Oktett umfassen, z. B. für ein Subnetz 192.168.118.0/26 für den Adressbereich 192.168.118.0 ... 192.168.118.63, zu Problemen führen, da in diesem Fall einzelne IP-Adressen, durch Komma separiert in der deny-Liste, aufgeführt werden müssten.

Hinweis: Die verwendbaren Wildcard-Character und Regular-Expressions bei der Definition der IP-Adressen sind u. U. abweichend von den üblicherweise im Kontext von Shell-Programmierung gebräuchlichen. Tomcat verwendet die Jakarta Regexp Bibliothek, eine Beschreibung der damit verwendbaren regulären Ausdrücke findet sich in [Jakarta Regexp].

5.1.2.3.1 T36.1 HTTP Connector, verbotene Anfragen mit IP-Adresse des ClientsDer Aufruf der Webseite http://192.168.118.101:8080/simple_info1 mit einem Webbrowser vom VMware-Hostsystem bigmama aus führt zu einer leeren Webseite. Ein direkter Aufruf der Applikation mit telnet führt zu folgendem Ergebnis: zunächst wird ein Redirect ausgelöst, wobei der folgende Zugriff auf das dabei angegebene Ziel nicht zugelassen wird.

Listing 42: Ausgaben beim Test des Zugriffs eines blockierten Clients (HTTP Connector)bigmama> telnet 192.168.118.101 8080Trying 192.168.118.101...Connected to 192.168.118.101.Escape character is '^]'.GET /simple_info1 HTTP/1.0

HTTP/1.1 302 Moved TemporarilyServer: Apache-Coyote/1.1Location: http://192.168.118.101:8080/simple_info1/Date: Thu, 20 Oct 2005 22:14:35 GMTConnection: close

Connection closed by foreign host.bigmama> telnet 192.168.118.101 8080Trying 192.168.118.101...Connected to 192.168.118.101.Escape character is '^]'.GET /simple_info1/ HTTP/1.0

HTTP/1.1 403 ForbiddenServer: Apache-Coyote/1.1Date: Thu, 20 Oct 2005 22:17:38 GMTConnection: close

Connection closed by foreign host.

5.1.2.3.2 T36.2 AJP13 Connector, verbotene Anfragen mit IP-Adresse des ClientsDer Aufruf der Webseite http://192.168.118.101/simple_info1 mit einem Webbrowser vom VMware-Hostsystem aus führt zu einer leeren Webseite. Ein direkter Aufruf der Applikation



mit telnet führt zu folgendem Ergebnis: zunächst wird ein Redirect ausgelöst, wobei der Zugriff auf das dabei angegebene Ziel nicht zugelassen wird.

Listing 43: Ausgaben beim Test des Zugriffs eines blockierten Clients (AJP13 Connector)bigmama> telnet 192.168.118.101 80Trying 192.168.118.101...Connected to 192.168.118.101.Escape character is '^]'.GET /simple_info1 HTTP/1.0

HTTP/1.1 302 Moved TemporarilyDate: Thu, 20 Oct 2005 22:14:52 GMTServer: Apache/2.0.54 (Unix) mod_jk/1.2.14Location: http://127.0.0.1/simple_info1/Connection: closeContent-Type: text/plain

Connection closed by foreign host.bigmama> telnet 192.168.118.101 80Trying 192.168.118.101...Connected to 192.168.118.101.Escape character is '^]'.GET /simple_info1/ HTTP/1.0

HTTP/1.1 403 ForbiddenDate: Thu, 20 Oct 2005 22:18:18 GMTServer: Apache/2.0.54 (Unix) mod_jk/1.2.14Connection: closeContent-Type: text/plain

Connection closed by foreign host.

5.1.2.3.3 T37 Erlaubte Anfragen mit IP-Adresse des ClientsFür die Tests in T37 wird zunächst die IP-Adresse des VMware-Hostsystems bigmama durch den Eintrag in der <Host> Deklaration innerhalb von $CATALINA_HOME/conf/server.xml für den Zugriff zugelassen.

Listing 44: IP-Address Filter Eintrag in der Tomcat-Konfigurationsdatei server.xml<Valve className=“org.apache.catalina.valves.RemoteAddrValve“allow=“192.168.118.1“/>

5.1.2.3.4 T37.1 HTTP Connector, erlaubte Anfragen mit IP-Adresse des ClientsDer Aufruf der Webseite http://192.168.118.101:8080/simple_info1 mit einem Webbrowser vom VMware-Hostsystem aus führt zur gewünschten Webseite. Ein Aufruf vom lokalen Host, auf dem der Tomcat Servlet Container läuft, führt zu einer leeren Webseite. Analog zum vorigen Test T36.1 führt ein direkter Aufruf der Applikation vom lokalen Host aus mit telnet zu folgendem Ergebnis: zunächst wird ein Redirect ausgelöst, wobei der Zugriff auf das dabei angegebene Ziel nicht zugelassen wird.




5.1.2.3.5 T37.2 AJP13 Connector, erlaubte Anfragen mit IP-Adresse des ClientsDer Aufruf der Webseite http://192.168.118.101/simple_info1 mit einem Webbrowser vom VMware-Hostsystem aus führt zur gewünschten Webseite. Ein Aufruf vom lokalen Host, auf dem der Tomcat Servlet Container läuft, führt zu einer leeren Webseite. Analog zum vorigen Test T36.2 führt ein direkter Aufruf der Applikation vom lokalen Host aus mit telnet zu folgendem Ergebnis: zunächst wird ein Redirect ausgelöst, wobei der Zugriff auf das dabei angegebene Ziel nicht zugelassen wird.

5.1.2.3.6 T38 / T 39 HTTP bzw. AJP13 Connector, verbotene / erlaubte Anfragen mit Hostname des ClientsZum Test der auf Hostnamen basierenden Zugriffssteuerung ist eine funktionsfähige Domain Name Service (DNS) Infrastruktur erforderlich, da Tomcat die Hostnamen anhand der in den Paket-Headern befindlichen IP-Adressen bestimmt. Beim Reverse DNS Lookup sind die Anfragen an den DNS-Server im Netzwerkverkehr mitlesbar. Anhand des vom DNS-Server zurückgegebenen Hostnamens des anfragenden Webclients wird mit dem Suchmuster bestimmt, ob ein Zugriff auf die Webseite zugelassen oder abgelehnt werden muss. Eine Beschreibung der Konfiguration eines hierfür geeigneten DNS-Servers wird in Abschnitt 3.8 gegeben.

Zum Test wurde ein DNS-Server auf der virtuellen Maschine installiert, die gleichzeitig als Webserver- und Tomcat-Host dient. Auf diesem DNS-Server wurden folgende Definitionen vorgenommen:

• Domäne: external.de (192.168.118.64/26)

• Host: bigmama, IP-Adresse 192.168.118.1

• Domäne: bsitomcat.de (192.168.118.128/26)

• Host: template, IP-Adresse 192.168.118.100

• Host: tomcathost, IP-Adresse 192.168.118.101

Für die Zugriffstests werden durch den Eintrag

<Valve className=“org.apache.catalina.valves.RemoteHostValve“**** allow/deny declaration ***/>

in der <Host> Deklaration innerhalb von $CATALINA_HOME/conf/server.xml die verbotenen bzw. zugelassenen Hosts bzw. Domänen eingetragen (s. Tabelle 7). Nach Änderung dieses Eintrags ist Tomcat jeweils neu zu starten.

Es wurden folgende Testergebnisse bei Zugriffen auf die simple_info1 Tomcat Webanwendung mit den URLs

• http://tomcathost.bsitomcat.de:8080/simple_info1/ bzw.



• http://localhost:8080/simple_info1/

für einen Direktzugriff auf Tomcat über den HTTP-Connector sowie

• http://tomcathost.bsitomcat.de:80/simple_info1/ bzw.

• http://localhost:80/simple_info1/

für einen Zugriff über den Apache Webserver in Verbindung mit dem mod_jk-Modul sowie dem Tomcat AJP-Connector erzielt:




*** allow / deny declaration *** für das RemoteHostValve

(in $CATALINA_HOME/conf/server.xml)

Zugriff überPort (Tomcat Connector)

bigmama.external.de

template.bsitomcat.de

tomcathost.bsitomcat

.de

localhost (auf tomcathost), s. u.

deny=“.*\.external\.de“ 8080 (HTTP) 403 200 200 20080 (AJP) 403 200 200 200

allow=“.*\.external\.de“ 8080 (HTTP) 200 403 403 40380 (AJP) 200 403 403 403

deny=“.*\.bsitomcat\.de“ 8080 (HTTP) 200 403 403 20080 (AJP) 200 403 403 200

allow=“.*\.bsitomcat\.de“ 8080 (HTTP) 403 200 200 40380 (AJP) 403 200 200 403

Tabelle 7: Tests der Hostnamen-basierten Zugriffskontrolle (Reverse DNS Lookup ist verfügbar)

Die dem HTTP Status Code entsprechenden Einträge in der Tabelle haben dabei die folgende Bedeutung:

• 200: die Webseite konnte korrekt abgerufen werden („HTTP Status 200 Success“)

• 403: ein Zugriff auf die Webseite wurde blockiert („HTTP Status 403 Forbidden“)

Insgesamt konnten keine Abweichungen vom erwarteten Verhalten festgestellt werden. Bei Zugriffen von der virtuellen Maschine aus, auf der Tomcat selbst läuft, ist folgende Unterscheidung zu beachten:

• Wird dort die Webseite http://localhost:8080/simple_info1/ aufgerufen, so erfolgt die Kommunikation in beide Richtungen (vom / zum Tomcat- bzw. Webserver) über die IP-Adresse 127.0.0.1 (localhost), die keiner der im DNS-Server eingetragenen Domänen angehört. Somit wird sie bei der Sperrung der lokalen Domäne bsitomcat.de auch nicht blockiert.

• Wird hingegen die Webseite http://tomcathost.bsitomcat.de:8080/simple_info1/ aufgerufen, so wird die Kommunikation über die dem Server zugeordnete IP-Adresse 192.168.118.101 (tomcathost) abgewickelt. Hierzu kann bei der DNS-Abfrage (Reverse DNS Lookup) für den Webclient eine Domänenzuordnung nach bsitomcat.de vorgenommen werden.

Diese Besonderheiten wurden durch Mitlesen des Netzwerkverkehrs zwischen Webbrowser und Webserver sowie dessen Kommunikation mit dem DNS-Server verifiziert.

Hinweis: Die verwendbaren Wildcard-Character und Regular-Expressions bei der Definition der Host- oder Domänennamen sind u. U. abweichend von den üblicherweise im Kontext von Shell-Programmierung gebräuchlichen, sodass bei Verwendung Letzerer möglicherweise unerwartete Ergebnisse erzielt werden können. Insbesondere bei der Definition von deny-Regeln ist mit entsprechender Vorsicht vorzugehen. Tomcat verwendet die Jakarta Regexp Bibliothek, eine Beschreibung der Ausdrücke findet sich in [Jakarta Regexp].

Neben dem regulären Verhalten wurde auch noch der Fall untersucht, dass der DNS Server für ein Reverse DNS Lookup nicht zur Verfügung steht. Dieser Fall kann eintreten, wenn



beispielsweise die für den Tomcat Server eingestellten DNS Server z. B. auf Grund von Netzwerkproblemen nicht erreichbar sind. Im vorliegenden Test wurde einfach der lokale DNS-Server auf tomcathost mit dem Kommando /etc/init.d/bind9 stop angehalten. Bei diesem Test wurden die in Tabelle 8 gezeigten Ergebnisse erzielt, wobei das korrekte Verhalten bei Verfügbarkeit des DNS-Server aus dem vorigen Test zum Vergleich mit aufgenommen wurde.

In der Tabelle wurden durch die unterstrichenen Einträge die Stellen markiert, bei denen abweichendes Verhalten gegenüber den gewählten RemoteHostValve-Einstellungen auf Grund fehlenden Reverse DNS Lookups festzustellen ist. Die Tabelleneinträge entsprechen wiederum dem HTTP Status Code der Antworten von Tomcat (s. S. 123). Bei den Einträgen mit dem HTTP Status Code 200 wird die angeforderte Webseite zurück gegeben, beim HTTP Status Code 403 erfolgt eine Fehlermeldung.

Zusammenfassend lässt sich feststellen, dass im Fall der Nicht-Verfügbarkeit des DNS Servers für ein Reverse DNS Lookup und damit der Namensauflösung zur IP-Adresse der HTTP-Anfrage folgendes Verhalten auftritt:

• bei grundsätzlicher Zugriffserlaubnis: d. h. es werden alle Anfragen beantwortet, die nicht per deny Regel blockiert werden. Da zur IP-Adresse der Anfrage kein Host- bzw. Domänenname gefunden wird, kann nicht positiv mit einer deny Regel verglichen werden und es erfolgt somit die Beantwortung aller Anfragen. Und dies, obwohl der der IP-Adresse zugeordnete Host- oder Domänenname in der deny Regel für einen Zugriff auf die Web-Ressourcen möglicherweise nicht freigegeben ist und somit zu einer Abweisung hätte führen müssen.

• bei grundsätzlichem Zugriffsverbot : d. h. es werden keine Anfragen beantwortet, die nicht per allow Regel zugelassen werden. Da zur IP-Adresse der Anfrage kein Host- bzw. Domänenname gefunden wird, kann nicht positiv mit einer allow Regel verglichen werden und es erfolgt keine Beantwortung der Anfrage. Dies führt zu einer Abweisung aller Anfragen, obwohl möglicherweise der der IP-Adresse zugeordnete Host- oder Domänenname in der allow Regel freigegeben ist.




*** allow / deny declaration *** für das RemoteHostValve

(in $CATALINA_HOME/conf/server.xml)

Zugriff überPort (Tomcat Connector)

Reverse DNS-Lookup verfügb

ar

bigmama.external.de

tomcathost.bsitomcat

.de

localhost (auf tomcathost), s. u.

deny=“.*\.external\.de“ 8080 (HTTP) Ja 403 200 200Nein 200 200 200

80 (AJP) Ja 403 200 200Nein 200 200 200

allow=“.*\.external\.de“ 8080 (HTTP) Ja 200 403 403Nein 403 403 403

80 (AJP) Ja 200 403 403Nein 403 403 403

deny=“.*\.bsitomcat\.de“ 8080 (HTTP) Ja 200 403 200Nein 200 200 200

80 (AJP) Ja 200 403 200Nein 200 200 200

allow=“.*\.bsitomcat\.de“ 8080 (HTTP) Ja 403 200 403Nein 403 403 403

80 (AJP) Ja 403 200 403Nein 403 403 403

Tabelle 8: Tests der Hostnamen-basierten Zugriffskontrolle in Abhängigkeit von der Verfügbarkeit von Reverse DNS Lookup

5.1.2.4 Protokollierung

Ziel des Tests ist es zu prüfen, ob und wie System-Ereignisse, beispielsweise Meldungen mit Informationen, Fehlern oder Warnungen, sowie webanwendungsspezifische Client Anfragen protokolliert werden.

Für den Test werden zwei Arten von Protokollierungen eingerichtet:

1. Protokollierung durch eine <Logger>-Komponente

2. Protokollierung durch ein AccessLogValve

Beide Protokollierungsarten werden für Testzwecke auf dem Niveau der Catalina Engine eingestellt und werden daher die maximale Reichweite haben. Die <Logger>-Komponente wird mit den Default-Einstellungen eingerichtet und maximale „verbosity“ („debug“, Niveau 4) der Protokollierung in eine Datei („FileLogger“) besitzen. Für das Access Log Valve wird die Default-Einstellung für das Format der Protokolldatei („common“) übernommen.

Die in Tabelle 9 zusammengefassten Tests bestehen im Wesentlichen aus einer Kontrolle des Umfangs und der Struktur der erstellten Protokolldateien.



Test Nr.

Tomcat-Connector


T 40 HTTP und AJP

Kontrolle der Protokolldatei für eine <Logger>-Komponente

protokollierte Information entsprechend der Dokumentation dargestellt

T 41 HTTP und AJP

Kontrolle der Protokolldatei für ein AccessLogValve

protokollierte Information entsprechend der Dokumentation dargestellt

Tabelle 9: Übersicht über die funktionalen Sicherheitstests der Protokollierung

Zur Durchführung der Tests werden verschiedene Anfragen für Ressourcen von Client-Browsern an Tomcat gesendet. Zudem wird z. B. der Tomcat-Server heruntergefahren oder es werden bestimmte Webanwendungen angehalten, um die Protokollierung der Systemereignisse zu untersuchen.

Da die zwei Connectoren (HTTP, AJP) im Prinzip unterschiedliche Information vom Client nach Tomcat übertragen könnten, werden diese Tests für beide Connectoren durchgeführt.

5.1.2.4.1 T40 Kontrolle der Log-Datei für eine <Logger>-KomponenteDurch Änderungen in der Architektur von Tomcat 5.5 im Vergleich zu den Vorgängerversionen wird die früher vorhandene <Logger>-basierte Protokollierung nicht mehr unterstützt. Eine versuchsweise Aktivierung durch Einbringung einer <Logger>-Definition in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml führte zu einer „ClassNotFound Exception“ beim Start von Tomcat. Statt dessen erfolgt die Protokollierung per java.util.logging Paket, dessen Konfiguration in der Datei $CATALINA_HOME/common/class/logging.properties festgelegt wird.

In den unter $CATALINA_HOME/logs erzeugten Protokolldateien können wichtige Systemereignisse wie

• Tomcat gestartet / beendet,

• Webanwendung gestartet / beendet,

• Aktualisierung von laufenden Webanwendungen, z. B. nach Änderungen in den Konfigurationsdateien der Webanwendungen,

• Fehlermeldungen, z. B. bei der Übersetzung von Servlets währende einer HTTP(S)/AJP-Benutzeranfrage oder fehlenden Klassen / jar-Archiven, aus entsprechend programmierten Fehlerausgaben der Servlets

nachvollzogen werden. Zugriffe von Benutzern auf Webanwendungen werden hiermit nicht protokolliert. Dies ist vielmehr die Aufgabe der separat zu spezifizierenden AccessLogValve.




5.1.2.4.2 T41 Protokollierung mit Access Log ValveZur Feststellung der überhaupt mit den Standard Pattern Codes protokollierbaren Informationen wird zunächst unter Verwendung aller Pattern Codes die maximal mögliche Protokollierungstiefe eingestellt42:

<Valve className="org.apache.catalina.valves.AccessLogValve" prefix="accLogValve_##_" pattern="%t %a %A %b %B %h %H %l %m %p %q %r %s %S %u %U %v %D %T" suffix=".txt"> </Valve>

Die Reihenfolge ist – mit Ausnahme der Zugriffszeit (%t) – einfach alphabetisch gewählt. Dieser Eintrag wird in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml je einmal auf <Host>-Ebene (## = host) und einmal auf <Engine>-Ebene (## = engine) definiert, wobei durch die unterschiedlichen Protokolldateien eine Unterscheidbarkeit der Einträge für den Test gewährleistet wird.

Nach einigen Testzugriffen auf Tomcat konnte bei einem Vergleich beider generierter Log-Dateien festgestellt werden, dass sich die Einträge außer in der Bearbeitungszeit der einzelnen Anfragen nicht unterscheiden. Der Unterschied der Bearbeitungszeit-Einträge ist dadurch hervorgerufen, dass auf <Engine>-Niveau zusätzliche Zeit zur Auswahl des (virtuellen) Hosts zur Abarbeitung der Anfragen benötigt wird. Der Umfang der mitgeschriebenen Protokollinformationen entspricht den in der Dokumentation angegebenen Werten.

Nach Änderung des Protokollierungspattern-Eintrages auf “common“ (entspricht der Standardeinstellung ohne Angabe eines Protokollierungspattern) bzw. “combined“ und Restart von Tomcat werden nur noch die jeweils in der Tomcat-Dokumentation angegebenen Werte in der Protokolldatei erfasst. Auch hierbei sind keine Unterschiede (evtl. mit Ausnahme der Bearbeitungszeit) in Abhängigkeit von der Schnittstelle, über die die Anfrage bei Tomcat eingetroffen ist, feststellbar.

Eine Unterscheidung, über welche Schnittstelle die Anfrage bei Tomcat eingetroffen ist (HTTP/HTTPS-Connector, AJP-Connector), ist lediglich über die protokollierten Port-Information (%p) und deren Zuordnung zu den eingestellten Connector-Port-Zuweisungen in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml möglich. Es erfolgt sowohl eine Protokollierung der erfolgreichen Zugriffe, als auch derjenigen die z. B. mangels vorhandener Webseite bzw. Applikation (HTTP-Return-Code 404) oder wegen nicht ausreichender Zugriffsberechtigungen abgebrochen wurden (HTTP-Return-Code 401 oder 403).

5.1.2.5 Zuverlässigkeit der Dienstleistung

Bei diesem Test wird eine Konfiguration für Hochverfügbarkeit eingerichtet. Diese entspricht Einsatzszenario 3:

42 Neben den Standard Pattern Codes können weitere gemäß der Apache Syntax definiert werden (s. [Apache mod_log]) wie %{###}i zur Abfrage des HTTP(S) Header Attributs ###, %{###}c für Cookie-Informationen, %{###}r für das Attribut ### im ServletRequest und %{###}s für Attribut ### der HTTP-Session, die hier nicht weiter untersucht werden. Da mit diesen noch detailliertere Informationen aus den HTTP(S)-Anfragen mit protokolliert werden könnten, können hiermit Datenschutz-relevante Punkte berührt werden.



• Zwei identische Tomcat-Instanzen in einer Load-Balancing-Konfiguration hinter einem Apache-Server mit mod_jk.

• „Sticky Sessions“

• Speicherung der Sessiondaten in einem externen NFS-Dateisystem mit dem „Persistent Session Manager“

Danach werden die Tests aus Tabelle 10 durchgeführt.

Test Nr.

Tomcat-Connector


T 42 AJP Test des automatischen Failovers beim Ausfall einer Tomcat-Instanz

Übernahme einer Session ohne Verlust der Sessiondaten

T 43 AJP Test der „Persistent Sessions“ beim Runterfahren beider Tomcat-Instanzen.

Beim anschließenden Neustart kein Verlust der Sessiondaten

Tabelle 10: Übersicht über die funktionalen Sicherheitstests der Zuverlässigkeit der Dienstleistung

5.1.2.5.1 T42 Failover beim Ausfall einer Tomcat-InstanzGemäß Dokumentation43 wird eine Web-Anwendung zunächst so konfiguriert, dass der PersistentManager zum Speichern von Session-Daten im Dateisystem zum Einsatz kommt. Als Anwendung ist SessionExample aus den Demos zu Tomcat geeignet. Folgende Konfigurationsdatei wird benötigt:

Listing 45: Einsatz von Persistent Sessions per Datei webapps/servlets-examples/META-INF/context.xml

<Context><Manager

className="org.apache.catalina.session.PersistentManager"maxIdleBackup="1"maxIdleSwap="2"maxInactiveInterval="1800"saveOnRestart="true"><Store

className="org.apache.catalina.session.FileStore"directory="/tmp/tomcat"checkInterval="10"/>

</Manager></Context>

Die Parameter maxIdleSwap usw. sind extrem klein gewählt, damit Tomcat die Session-Daten schnell in den persistenten Speicher überträgt. Diese Werte erleichtern die Tests, sind für den Produktivbetrieb jedoch ungeeignet.Laut Dokumentation sollte das Element <distributable> für die Webanwendung noch wie folgt gesetzt werden:

43 http://tomcat.apache.org/tomcat-5.5-doc /config/manager.html


http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html



Listing 46: Ergänzung webapps/servlets-examples/WEB-INF/web.xml um <distributable><web-app>

<display-name>Servlet 2.4 Examples</display-name> <description> Servlet 2.4 Examples. </description>

<distributable/>

Wenige Sekunden nach dem ansprechen der URL http://tomcathost/ servlets- examples/servlet/SessionExample wird im Verzeichnis /tmp/tomcat/ die Datei 6A3FDD31BCF6C6399BAC938F97C8AA8D.session erzeugt. Diese enthält im „Serializable“ genannten standardisierten binären Format von Java die im Browser angegebenen Parameter und Wertepaare.Diese Nummer entspricht dem Wert des Cookies, das unter dem Namen JSESSIONID und dem Pfad /servlets-examples im Browser abgelegt wird. Anhand dieses Cookies wird die Session identifiziert.

sessions.id 6A3FDD31BCF6C6399BAC938F97C8AA8Dsessions.created Tue Jan 17 11:02:36 CET 2006sessions.lastaccessed Tue Jan 17 11:10:29 CET 2006sessions.datafoo = barzot = grrjavax.security.auth.subject = Betreff: bar = zot

Im Browser erscheint ein Formular zur Eingabe weiterer Wertepaare. Bei Änderung wird die Datei aktualisiert, was sowohl am Datum als auch am Inhalt sichtbar wird.

Wird eine Instanz vom Tomcat abgebrochen, so wird bei weiteren Zugriffen nach einiger Verzögerung die zweite Instanz von Tomcat aufgerufen. Anhand des im Browser gespeicherten Cookies und des von beiden Instanzen erreichbaren Pfades /tmp/tomcat/ ist auch der zweite Tomcat in der Lage die gleichen Inhalte wie zuvor anzuzeigen. Session-ID und sämtliche Wertepaare bleiben erhalten.

5.1.2.5.2 T43 Persistente Sessions beim HerunterfahrenEs wird die gleiche Konfiguration wie bei T42 verwendet. Die Zeile saveOnRestart="true" stellt sicher, dass etwaig gespeicherte Session-Daten beim normalen Beenden von Tomcat gespeichert und beim Neustart geladen werden. Sofern der Browser den Cookie behalten hat, bzw. gar nicht erst geschlossen wurde, stehen die Session-Daten unter der URL http://tomcathost/servlets-examples/servlet/SessionExample wieder zur Verfügung.

Die Dokumentation zum PersistentManager erwähnt, dass dieser nicht für den Produktivbetrieb geeignet ist. In der Tat bietet das Abspeichern in Dateien mehrere Hürden, die mit serialisiertem, atomaren und konsistenten Zugriffsmöglichkeiten von Datenbanken gemeistert werden.


http://tomcathost/servlets-examples/servlet/SessionExample





5.1.2.6 Verschlüsselung

Bei diesem Test werden die Möglichkeiten des Clients in Bezug auf Veränderungen in der SSL-Verschlüsselung untersucht.

Eine Webanwendung wird mit einem Security Constraint eingerichtet, welches eine Verschlüsselung verlangt („Confidential“). Danach wird von einem Client aus versucht, verschiedene Merkmale der SSL-Verschlüsselung zu beeinflussen (Tabelle 11).

Test Nr.

Tomcat-Connector


Bemerkung

T 44 HTTP und AJP

Client versucht, ein Cipher „NULL“ zu verlangen und so die Verschlüsselung abzuschalten

nicht möglich sollte von Tomcat abgefangen werden, zumindest beim HTTP Connector

T 45 HTTP und AJP

Client versucht, ein schwaches Cipher (z. B. 40 Bit EXPORT) zu verlangen

unbekannt diesbezüglich keine Dokumentation bekannt

T 46 HTTP und AJP

Client versucht, eine Veränderung der SSL-Version-Nr. (2.0, 3.0) zu verlangen

unbekannt diesbezüglich keine Dokumentation bekannt

Tabelle 11: Übersicht über die funktionalen Sicherheitstests der Verschlüsselung

Die SSL-Kommunikation des Clients mit dem AJP-Connector erfolgt über das Produkt Apache Webserver / mod_ssl, wobei die SSL-Verschlüsselung nicht durch den Tomcat Server durchgeführt wird. Daher werden SSL-basierte Untersuchungen ausschließlich am SSL/HTTP-Connector des Tomcat-Servers durchgeführt.

5.1.2.6.1 T44 SSL mit Null-CipherBei diesem Test wurde geprüft, ob der SSL-Connector des Tomcat Servers auch eine SSL-Verbindung ohne Verschlüsselung (-cipher NULL) akzeptiert.

Der SSL-Connector des Tomcat-Servers wurde entsprechend der Installationsanleitung in diesem Dokument konfiguriert.

Die Anfrage des Clients wurde mit folgendem Script T44_request.sh abgesendet:

#!/bin/bashecho -e "GET /simple_info1/index.jsp HTTP/1.0\r\n\r\n"|openssl s_client \ -connect localhost:8443 \ -cipher NULL \ -debug \ -quiet

Die Benutzung dieses Skripts war erfolgreich. Eine SSL-Verbindung zwischen dem Client openssl und dem Server kam zustande, obwohl eine Verschlüsselung nicht statt fand (cipher: NULL-SHA).

Nachfolgend wird ein Ausschnitt der Protokollierung der SSL-Verbindung dargestellt.




...---SSL handshake has read 1501 bytes and written 235 bytes---New, TLSv1/SSLv3, Cipher is NULL-SHAServer public key is 1024 bitSSL-Session: Protocol : TLSv1 Cipher : NULL-SHA Session-ID: 4387774D6BAB4F85DE47DBA6A248BDC24629029862680D61B02A7D3B2EC9BF11 Session-ID-ctx: Master-Key: 033B3FF05B5DDD3400BBC1793DEC5C6F2D570780707885209F65BE2B568F3F6B838A233F7112E01FC1E02C5B3E48EBB6 Key-Arg : None Start Time: 1132951373 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain)---

5.1.2.6.2 T45 SSL mit schwacher VerschlüsselungBei diesem Test wurde geprüft, ob der SSL-Connector des Tomcat Servers auch eine SSL-Verbindung mit schwacher Export-Verschlüsselung (-cipher EXP-RC4-MD5) akzeptiert.

Wiederum wurde ein Skript T45request.sh aufgesetzt, mit dem der Test durchgeführt wurde:

#!/bin/bashecho -e "GET /simple_info1/index.jsp HTTP/1.0\r\n\r\n"|openssl s_client \ -connect localhost:8443 \ -cipher EXP-RC4-MD5 \ -debug \ -quiet

Der Client konnte erfolgreich eine SSL-Verbindung mit dem SSL-Connector des Tomcat Servers aufbauen. Nachfolgend der Auszug aus dem Verbindungsprotokoll.

...---New, TLSv1/SSLv3, Cipher is EXP-RC4-MD5Server public key is 1024 bitSSL-Session: Protocol : TLSv1 Cipher : EXP-RC4-MD5 Session-ID: 438777935665009A73A93E8AF1D577FA419B49A2DDE1F657129C6DF0AEDE86B2 Session-ID-ctx: Master-Key: AD6D4A2B416ACED072534EB7FF74F592A67B325E389D72E89E2DF10EB6F14C72A4AD5DC0CAD23EAD180CD3EF29CB9DA5 Key-Arg : None Start Time: 1132951443 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain)...

5.1.2.6.3 T46 SSLv2, SSLv3 oder TLSBei diesem Test wurde geprüft, ob der SSL-Connector des Tomcat Servers auch eine SSL-Verbindung mit anderen Verbindungsstandards (SSLv2, SSLv3, TLS) akzeptiert, obwohl als Protokoll in der Konfiguration des SSL Connectors TLS festgelegt war.

Für den Test wurde folgendes Skript T46request.sh verwendet:

#!/bin/bash



echo -e "GET /simple_info1/index.jsp HTTP/1.0\r\n\r\n"|openssl s_client \ -connect localhost:8443 \ -ssl2 \ -debug \ -quiet

Neben diesem Skript, welches Client-seitig SSLv2 verwendet, wurde das gleiche Skript auch mit der Option SSLv3 angewendet.

Die Ergebnisse der Anfragen sind in nachfolgender Tabelle dargestellt:

Verschlüsselungs-Protokoll

Ergebnis

TLS ErfolgreichSSLv2 Nicht erfolgreichSSLv3 Erfolgreich

Tabelle 12: Ergebnisse von T46

Obwohl als Protokoll TLS konfiguriert war, hat der SSL-Connector des Tomcat-Servers auch SSLv3 zugelassen.

Zusammenfassung von T44, T45 und T46

Ein wie in der hier enthaltenen Installationsanleitung S. 36 konfigurierter SSL Connector des Tomcat Servers akzeptiert beliebige, unter anderem auch unsichere Verschlüsselungsmodi. Er akzeptiert darüber hinaus auch das Verschlüsselungsprotokoll SSLv3, obwohl TLS konfiguriert war.

In der Dokumentation des Tomcat Servers44 wird erwähnt, dass durch die Konfigurationsoption ciphers definiert werden kann, welche Verschlüsselungsalgorithmen der SSL Connector zulassen soll. Es werden jedoch keine Beispiele für gültige Begriffe (der Verschlüsselungsalgorithmen) aufgezählt.

Es wurden versuchsweise mehrere Begriffe aus dem RFC 3268 (Verschlüsselungsalgorithmen für TLS) sowie einer SUN JSSE Dokumentation45 als Verschlüsselungsalgorithmus-Bezeichnungen für die Konfigurationsoption ciphers ausprobiert. Wurden ausschließlich unbekannte Namen oder Namen mit Tippfehlern angegeben, hat der Server jedoch so reagiert, als sei die Konfigurationsoption ciphers gar nicht in der Konfiguration vorhanden. Dieses Verhalten, gepaart mit dem Fehlen einer diesbezüglichen Fehlermeldung, ist aus Sicherheitsgründen nicht akzeptabel. Zu groß ist das Risiko einer Fehlkonfiguration und die Abhängigkeit von den genauen Namen der verwendeten Version der JSSE.

Es folgt die Liste der von JSSE bzw. Tomcat unterstützten Angaben zur Option ciphers in unserer Testumgebung. Diese Liste wurde durch Instrumentieren von Tomcat anhand der Funktion getSupportedCipherSuites der Klasse java.net.ServerSocket ermittelt. Man beachte, dass openssl andere Namen verwendet und meldet.

Listing 47: mögliche Angaben zu ciphers in conf/server.xml (mit JSSE/JDK 1.5.0)SSL_RSA_WITH_RC4_128_MD5SSL_RSA_WITH_RC4_128_SHA

44 http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html 45 http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html Appendix A


http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html




TLS_RSA_WITH_AES_128_CBC_SHATLS_DHE_RSA_WITH_AES_128_CBC_SHATLS_DHE_DSS_WITH_AES_128_CBC_SHASSL_RSA_WITH_3DES_EDE_CBC_SHASSL_DHE_RSA_WITH_3DES_EDE_CBC_SHASSL_DHE_DSS_WITH_3DES_EDE_CBC_SHASSL_RSA_WITH_DES_CBC_SHASSL_DHE_RSA_WITH_DES_CBC_SHASSL_DHE_DSS_WITH_DES_CBC_SHASSL_RSA_EXPORT_WITH_RC4_40_MD5SSL_RSA_EXPORT_WITH_DES40_CBC_SHASSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHASSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHASSL_RSA_WITH_NULL_MD5SSL_RSA_WITH_NULL_SHASSL_DH_anon_WITH_RC4_128_MD5TLS_DH_anon_WITH_AES_128_CBC_SHASSL_DH_anon_WITH_3DES_EDE_CBC_SHASSL_DH_anon_WITH_DES_CBC_SHASSL_DH_anon_EXPORT_WITH_RC4_40_MD5SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHATLS_KRB5_WITH_RC4_128_SHATLS_KRB5_WITH_RC4_128_MD5TLS_KRB5_WITH_3DES_EDE_CBC_SHATLS_KRB5_WITH_3DES_EDE_CBC_MD5TLS_KRB5_WITH_DES_CBC_SHATLS_KRB5_WITH_DES_CBC_MD5TLS_KRB5_EXPORT_WITH_RC4_40_SHATLS_KRB5_EXPORT_WITH_RC4_40_MD5TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHATLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5

Der Tomcat HTTP/SSL-Connector auf Port 8443 wurde nun mit dem Parameter

ciphers=“SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA“

versehen.

In diesem Fall (und in mehreren anderen Fällen, in denen Algorithmusnamen der obigen Liste verwendet wurden) verhielt sich der Tomcat SSL Connector wie erwartet, d. h. er hat nur die Algorithmen zugelassen, die auch konfiguriert waren.

Zusammenfassend lässt sich feststellen, dass keine Dokumentation existiert, die eine sichere und nachvollziehbare Konfiguration des SSL-Connectors von Tomcat möglich macht. Zudem startet der Tomcat Server trotz unbekannter Verschlüsselungsmodi ohne Fehlermeldung und verhält sich somit anders als konfiguriert.

Bewertung

Es ist daher davon abzuraten, den SSL-Connector von Tomcat 5 als Netzwerkschnittstelle für sicherheitskritische Anwendungen zu verwenden.



Empfehlung

Für das Tomcat-Entwicklungsprojekt ist zu empfehlen, dass eine Konfiguration des Tomcat-SSL-Connectors analog zur Konfiguration von mod_ssl ermöglicht wird. Darüber hinaus sollten die Konfigurationsoptionen für den SSL-Connector dokumentiert werden.

5.1.2.7 Datenschutz

Beim Thema Datenschutz geht es um Informationen, die Tomcat protokolliert. Zuerst werden die Ergebnisse des Tests T 40 und T 41 (oben) noch einmal aus Sicht des Datenschutzes betrachtet. So werden die Default-Einstellungen von Tomcat im Hinblick auf den Datenschutz überprüft.

Test Nr.

Tomcat-Connector


Bemerkung

T 47 HTTP und AJP

Ergebnisse des Tests T 40 und T 41 analysieren unter dem Gesichtspunkt „Datenschutz“

wahrscheinlich keine datenschutzrelevanten Aspekte

T 48 HTTP und AJP

Einstellung der Protokollierung (Access Log Valve) mit einer maximalen Protokollierungstiefe; Durchführung von Anfragen für Ressourcen von Client-Browsern an Tomcat

unbekannt Vermutlich ist die Speicherung einiger benutzerorientierter Informationen (z. B. „remote logical user name“ oder „user session ID“) für den Datenschutz von Bedeutung

Tabelle 13: Übersicht über die funktionalen Sicherheitstests zum Datenschutz

Danach wird der Test bei der „maximalen Protokollierung“ wiederholt. Hierbei werden z. B. alle die für den Datenschutz relevanten „patterns“ im Access Log Valve eingeschaltet. Die so erstellten Protokolldateien werden im Hinblick auf den Datenschutz analysiert.

Da die zwei Connectoren (HTTP, AJP) im Prinzip unterschiedliche Information vom Client nach Tomcat übertragen können, wird der Test für beide Connectoren durchgeführt.

Hinweis: bei der Verwendung des Tomcat Servlet Containers in Verbindung mit dem Apache Webserver über mod_jk-AJP-Connector bzw. mod_proxy-HTTP-Connector ist zu beachten, dass neben der Protokollierung durch Tomcat auch der Apache Webserver selbst Protokolldaten mit möglicherweise datenschutzrechtlich relevanten Informationen generieren kann. Dies ist bei einer Konfiguration des Apache Webservers zu berücksichtigen, wird aber im Rahmen dieser Untersuchungen nicht weiter betrachtet.

5.1.2.7.1 T47 / T48 Datenschutz-bezogene Analyse der Ergebnisse aus Tests T40 und T41Die Analyse der Protokolldateien und der verwendbaren Protokollformat-Optionen hat zum Ergebnis geführt, dass die Erzeugung von für den Datenschutz relevanten Informationen je nach Einstellung der Log-Funktionen nicht ausgeschlossen werden kann.




Bei der Verwendung des “combined“ Log-Konfigurationspattern oder z. B. in Verbindung mit den “%u“ oder “%{Referer}i“ Protokollierungsformat-Optionen können Informationen wie der Name eines authentisierten Benutzers oder die zuvor besuchte Webseite in die Log-Dateien mit aufgenommen werden. Letzteres kann insbesondere dann von Bedeutung sein, wenn in den URLs auch weiter gehende Informationen, wie Parameter für den vorherigen HTTP-Request in der Form ...?param1=value1&param2=value2&... die beispielsweise in Verbindung mit HTML-Formularabfragen verwendet werden, kodiert sind. Da keine allgemeinen Annahmen über die hierbei vorkommenden Informationen getroffen werden können, muss zunächst davon ausgegangen werden, dass es sich hierbei um für den Datenschutz relevante Informationen handeln könnte, was zu entsprechenden Konsequenzen im Umgang mit den Log-Dateien führt.

Analoges gilt für Cookie-Informationen, die bei der Protokollierung aufgezeichnet werden können und möglicherweise gleichfalls sensible Informationen enthalten.

In der Standardeinstellung mit dem Log-Pattern “common“ werden diese Informationen nicht mit protokolliert.

Für die Protokollierung der Tomcat Ereignisse per java.util.logging Mechanismen kann festgestellt werden, dass in der Standardeinstellung (entsprechend dem Log-Pattern “common“) zunächst keine datenschutzrechtlich relevanten Informationen erfasst werden. Es ist aber möglich, dass die in Tomcat laufenden Webanwendungen selbst interne Zustände über diesen Logging-Mechanismus protokollieren, wobei u. U. auch datenschutzrechtlich relevante Informationen betroffen sein könnten. Da dies aber abhängig von der konkreten Webanwendung ist, kann hier keine allgemeine Feststellung getroffen werden.

Wie bereits oben erwähnt betrifft die Protokollierung nicht nur den Jakarta Tomcat Servlet Container alleine. Da dieser in den meisten Fällen in Verbindung mit einem vorgeschalteten Webserver (z. B. Apache) verwendet werden wird und der Webserver über eigene Protokollierungsfunktionalität verfügt, gelten die gemachten Hinweise analog für dessen Protokollierung.

5.1.2.8 Minimale Rechtevergabe

Die Einsatzumgebung wird so geändert, dass Tomcat unter einem eigenen Benutzerkonto mit eingeschränkten Rechten (z. B. ohne Login-Shell) läuft. Danach werden Anfragen für Ressourcen von Client-Browsern an Tomcat gesendet und das ordnungsgemäße Funktionieren der Engine beurteilt.

Test Nr.

Tomcat-Connector


Bemerkung

T 49 HTTP und AJP

Ausführung von Tomcat als nicht-privilegierter Benutzer; Sendung von Anfragen für Ressourcen von Client-Browsern an Tomcat.

ordnungsgemäßes Funktionieren

Betrieb sollte laut Dokumentation möglich sein

Tabelle 14: Übersicht über die funktionalen Sicherheitstests zur minimalen Rechtevergabe

Dieser Test ist für die Tomcat-Engine selbst von Bedeutung und ist daher unabhängig von den verschiedenen Konfigurationen der einzelnen Einsatzszenarien. Jedoch ist es denkbar, dass die zwei Connectoren unterschiedlich auf die veränderten Rechte der Tomcat-Engine



reagieren. Deswegen ist es sinnvoll, den Test mit beiden Connectoren durchzuführen (HTTP, AJP).

5.1.2.8.1 T49 Ausführung von Tomcat als nicht-privilegierter BenutzerZur Vorbereitung des Tests werden vor dem Starten von Tomcat sämtliche Dateien und Verzeichnisse unterhalb von $CATALINA_HOME dem neu erzeugten Benutzer tomcat und der neu erzeugten Gruppe tomcat zugewiesen, um eventuell benötigte Schreib- (Log-Dateien!) und Leseberechtigungen für den Tomcat-Prozess zu erhalten:

Listing 48: Zuweisung der Tomcat Dateien an einen unprivilegierten Benutzergroupadd -g 150 tomcatuseradd -c “Tomcat“ -g 150 -u 150 -d /opt/jakarta-tomcat-5.5.9 -s /bin/bash tomcatfind /opt/jakarta-tomcat-5.5.9 -exec chown tomcat:tomcat {} \;

Nun kann unter diesem neuen Benutzer Tomcat wie üblich gestartet werden:

su – tomcatbin/catalina start

Sowohl direkt über den HTTP(S)-Connector als auch über den AJP13-Connector (via Apache), ergaben sich bei den nachfolgenden Zugriffstests (über HTTP und HTTPS) keine Unterschiede im Verhalten gegenüber der Tomcat-Installation unter dem root Benutzer.

Im realen Einsatz würde Tomcat nicht per Startkommando aus einer Shell sondern wahrscheinlich eher über ein Startup-Skript während des Boot-Vorgangs gestartet. In diesem Fall könnte auf eine Login-Shell bei der Einrichtung des unprivilegierten Benutzers verzichtet werden. Bei der Einrichtung des Benutzers tomcat könnte statt -s /bin/bash entweder -s /bin/false oder -s /bin/nologin46 verwendet werden, was zu einer Erhöhung der Sicherheit beitragen würde.

5.2 Penetrationstests - Vorgehensweise

Die Penetrationstests dienen dazu festzustellen, ob Tomcat durch Protokoll verletzenden oder unerwarteten Netzwerkverkehr in seinem Programmablauf beeinflusst werden kann.

5.2.1 Angriffsszenarien

Bei diesen Tests wird der Netzwerkverkehr gezielt mittels entsprechender Werkzeuge manipuliert. Dabei wird das Verhalten des zu testenden Systems (Tomcat bzw. Apache mit mod_jk) überwacht. Die Vorgehensweise besteht dabei aus den folgenden Schritten:

1. Aufzeichnung des protokollkonformen Netzwerkverkehrs,

46 falls dieses Skript in der Linux-Installation vorhanden ist und ein syslog-Logging der nicht zugelassenen Login-Versuche benötigt wird.




2. Veränderung des protokollkonformen Netzwerkverkehrs und dessen Einspielung nach der Veränderung und

3. Auswertung der Protokolldateien und Kontrolle der angegriffenen Dienste.

Es werden zwei prinzipiell unterschiedliche Angriffsszenarien betrachtet:

• Angriffe eines Web Clients mit nicht konformen HTTP-Paketen bzw. mit nicht erwarteten HTTP-Header-Feldern (überlange Felder, Java Skript Code) oder

• Angriffe von einer Web Anwendung bei eingeschalteter Standard Java Security Policy gegen einen davor stehenden Apache-Server bzw. gegen das AJP-Protokoll (mod_jk) mittels übergroßer HTTP-Header (Cookies, etc.).

Im Folgenden werden die Angriffe nach den verwendeten Tomcat-Connectoren unterschieden

• HTTP-Connector: Angriffe von einem HTTP-Client

• AJP-Connector ohne SSL-Client-Authentisierung: Angriffe von HTTP-Client und Angriffe einer Web Anwendung

• AJP-Connector mit SSL Client Authentisierung: Angriffe eines Web-Clients mit nicht konformen SSL-Zertifikaten.

Die Durchführung dieser Angriffe wird in den drei folgenden Kapiteln erläutert.

Anmerkung: Für den HTTPS-Connector sind keine Angriffe vorgesehen, da die verwendete SSL-Implementierung von den Standard Java Klassen durchgeführt werden und sich die Angriffe auf HTTP-Ebene nicht unterscheiden.

5.2.2 Beispielanwendungen

Für die Angriffe war vorgesehen, Beispielanwendungen anzugreifen, um eine möglichst realistische Abbildbarkeit der Tests zu gewährleisten. Es sollten insbesondere Web-Anwendungen angegriffen werden, welche HTTP-Sessions verwenden und über Authentisierungs- und Autorisierungsfunktionen verfügen.

Es wurden die unten dargestellten Angriffe gegen eine derartige Beispielanwendung (webgoat aus dem OWASP Projekt) durchgeführt.



5.3 HTTP-Connector: Angriffe von einem HTTP-Client

Abbildung 5.4: Angriffe auf den HTTP-Connector des Tomcat-Servers

Die Verwendung des HTTP- oder SSL-Connectors eines Tomcat-Servers als direkte Schnittstelle zu Anwendern, deren HTTP-/HTTPS-Anfragen maliziöse Inhalte besitzen können (Abbildung 5.4), ist in vielen Punkten gegenüber einer mehrstufigen Architektur (Abbildung 5.5) mit Nachteilen versehen.

1. Performanz: der HTTP-/SSL-Connector des Tomcat-Servers verfügt nicht über die vielfältigen Einstellmöglichkeiten des Apache Webservers, mit denen Ressourcen eines Servers optimal für die Anfragen von Anwendern ausgenutzt werden können.

2. Schutz vor schädlichen Übergabeparametern: Filternde Sicherheitsmodule wie z. B. mod_security des Apache Webservers sind nicht für den Tomcat-Server erhältlich.

3. Fehlende Diversifikation von Schutzmechanismen: Wird der HTTP-/SSL-Connector des Tomcat-Servers falsch konfiguriert, so kann dies direkt die Kompromittierbarkeit von sensiblen Web-Inhalten (z. B. des Source-Code von JSPs) oder die Angreifbarkeit der Management-Schnittstelle bedeuten. Wird ein filternder Apache Webserver „vor“ den Tomcat-Server geschaltet, so ist die Fehlkonfiguration mit weniger Sicherheitsrisiken verbunden.

Vom Einsatz der hier beschriebenen Webanbindung, einer Architektur wie in Abbildung 5.4, wird aufgrund der beschriebenen Probleme abgeraten. Der prinzipiellen Vorteile einer mehrstufigen Architektur mit Tomcat-Server und vorgeschaltetem Apache Webserver kommt besonders in sicherheitsrelevanten Umgebungen zum Tragen und sollte dort nur so eingesetzt werden.

Aus diesem Grund werden Angriffsszenarien gegen eine Architektur wie in Abbildung 5.4 hier nicht weiter untersucht (vgl. auch [Tomcat Fein.]).




5.4 AJP-Connector ohne SSL-Client-Authentisierung

Die am weitesten verbreitete Architekturvariante beim Betrieb des Tomcat Application Servers ist die Vorschaltung eines Webservers mit einem Modul mod_jk, welches die Verbindung zwischen Webserver und Tomcat-Server ermöglicht.

5.4.1 Angriffe eines maliziösen HTTP-Clients

Bei den Tests mit dem AJP-Connector ohne Authentisierung mit SSLClient-Zertifikaten werden die Werte mehrerer HTTP-Parameter vom HTTP-Client in den Anfragen variiert.

5.4.1.1 Vorgehensweise

Für die Durchführung und Dokumentation der Tests wurde eine einheitliche Vorgehensweise angewendet (siehe Abbildung 5.6).


Abbildung 5.5: Angriffe mit maliziösen HTTP-Inhalten


Angriffsprogramm T**webfuzz.c editieren

Angriffsprogramm T**webfuzz.ccompilieren

catalina.out leeren

localhost-10-**.log abspeichern alsT**_localhost.out

catalina.out abspeichern alsT**_catalina.out

mod_jk.log abspeichern alsT**_mod_jk.log

Netzwerkmitschnitt abspeichern alsT**_ethereal_dump.dmp

Angriffsprogramm starten:./T**webfuzz localhost 80 >

T**_HTTP_fuzz.txt

Netzwerksniffer starten

Apache Web Server neu starten

Jakarta Tomcat Server neu starten

localhost-10-**.log leeren

Für alle Testfälle T66 bis T81

mod_jk.log leeren

Abbildung 5.6: Vorgehensweise HTTP-Client-Angriffe




Ein Beispiel für die SPIKE-Angriffsprogramme, mit denen die maliziösen HTTP-Anfragen gestellt wurden, ist im Abschnitt Installation bereits beschrieben worden.

5.4.1.2 Bewertungskriterien

Um festzustellen, ob die Angriffe Hinweise auf Schwachstellen des Untersuchungsgegenstandes geben, wurden folgende Zustände / Protokolldateien untersucht:

• Ist die angesprochene Web-Anwendung nach den Angriffen noch benutzbar?

• Enthält die Protokolldatei des mod_jk Hinweise auf eine temporäre Nicht-Verfügbarkeit der Web-Anwendung?

• Enthalten die Protokolldateien des Tomcat-Servers Fehlermeldungen oder sogar Java Stack Traces?

• Enthält der HTTP-Reply des Tomcat-Servers HTTP-Meldungen wie „HTTP Status 500 (Internal Server Error)“ oder „HTTP Status 503 (Service Temporarily Unavailable)“?

• Enthält der HTTP-Reply des Tomcat-Servers den Source-Code der angefragten Java Server Page? (Source Code Disclosure)



5.4.1.3 Ergebnis

Die nachfolgende Tabelle gibt eine Übersicht über die Testergebnisse.

Test Nr. Testbeschreibung Resultat BemerkungHTTP-AnfrageT 50 HTTP Methode OKT 51 URI OKT 52 HTTP Version OKT 53 Query String OKHTTP-HeaderT 54 Accept OKT 55 Accept-charset OKT 56 Authorization OKT 57 Connection OKT 58 Content-Type OKT 59 Content-Length FEHLER Content-Length:<Leerzeichen>

führt zu Fehlerzustand im Tomcat-ServerT 60 Cookie OKT 61 Cookie2 OKT 62 Referer OKT 63 Host FEHLER • Host: localhostSelect

"DAV:displayname" from scope()“

• Host: C:localhost

• Host: Select "DAV:displayname" from scope()

führen zu Fehlerzustand im Tomcat-ServerT 64 Unknown OKT 65 User-Agent OK

Tabelle 15: Ergebnisse der Tests T66 bis T81

Schwachstelle in T75

Das Fehlen des Übergabeparameters im HTTP-Header Content-Length führte zu schwerwiegenden Fehlerzuständen im Tomcat-Server.

Nachfolgende HTTP-Anfrage und -Antwort war mit einer gleichzeitigen Fehlermeldung in der Protokolldatei catalina.out verbunden.

Listing 49: HTTP-Anfrage:

POST /webgoat/attack HTTP/1.1Host: 192.168.179.128




User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.0Accept-Language: en-us,en;q=0.0Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.0Connection: closeReferer: http://192.168.179.128/webgoat/attackCookie: JSESSIONID=F7F97CD94DB5137AE94EA6FFF3D145E9Authorization: Basic bWVtd2FkbWluOnZtd2FyZQ==Content-Type: application/x-www-form-urlencodeContent-Length:

person=bla

Listing 50: HTTP-Antwort:

HTTP/1.1 503 Service Temporarily UnavailableDate: Wed, 30 Nov 2005 21:10:25 GMTServer: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7e mod_jk/1.2.14Content-Length: 446Connection: closeContent-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>503 Service Temporarily Unavailable</title></head><body><h1>Service Temporarily Unavailable</h1><p>The server is temporarily unable to service yourrequest due to maintenance downtimVariablesize= 5

Listing 51: Korrespondierende Fehlermeldung in catalina.out:

30.11.2005 22:10:25 org.apache.jk.common.HandlerRequest invokeSCHWERWIEGEND: Error decoding request java.lang.NumberFormatException

at org.apache.tomcat.util.buf.Ascii.parseInt(Ascii.java:145)at org.apache.tomcat.util.buf.ByteChunk.getInt(ByteChunk.java:491)at org.apache.tomcat.util.buf.MessageBytes.getInt(MessageBytes.java:687)at org.apache.jk.common.HandlerRequest.decodeHeaders(HandlerRequest.java:686)at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:510)at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363)at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)at

org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)at java.lang.Thread.run(Thread.java:595)

30.11.2005 22:10:25 org.apache.jk.common.ChannelSocket processConnectionWARNUNG: processCallbacks status 230.11.2005 22:10:25 org.apache.jk.common.HandlerRequest invokeSCHWERWIEGEND: Error decoding request java.lang.NumberFormatException

at org.apache.tomcat.util.buf.Ascii.parseInt(Ascii.java:145)at org.apache.tomcat.util.buf.ByteChunk.getInt(ByteChunk.java:491)at org.apache.tomcat.util.buf.MessageBytes.getInt(MessageBytes.java:687)at org.apache.jk.common.HandlerRequest.decodeHeaders(HandlerRequest.java:686)



at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:510)at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363)at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)at


30.11.2005 22:10:25 org.apache.jk.common.ChannelSocket processConnectionWARNUNG: processCallbacks status 230.11.2005 22:10:25 org.apache.jk.common.HandlerRequest invokeSCHWERWIEGEND: Error decoding request java.lang.NumberFormatException

at org.apache.tomcat.util.buf.Ascii.parseInt(Ascii.java:145)at org.apache.tomcat.util.buf.ByteChunk.getInt(ByteChunk.java:491)at org.apache.tomcat.util.buf.MessageBytes.getInt(MessageBytes.java:687)at org.apache.jk.common.HandlerRequest.decodeHeaders(HandlerRequest.java:686)at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:510)at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363)at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)at


30.11.2005 22:10:25 org.apache.jk.common.ChannelSocket processConnectionWARNUNG: processCallbacks status 2

Aus der identifizierten Schwachstelle konnten keine Sicherheitsrisiken abgeleitet werden.

Mit dem durchgeführten Angriff konnte weder die Verfügbarkeit des Tomcat-Servers beeinträchtigt werden noch konnten interne bzw. vertrauliche Daten (z. B. Der Source-Code der angesprochenen JSP) veröffentlicht werden.

Schwachstelle in T79

Bestimmte Übergabeparameter im HTTP-Header Host führten zu schwerwiegenden Fehlerzuständen im Tomcat-Server.

Nachfolgende HTTP-Anfrage und -Antwort war mit einer gleichzeitigen Fehlermeldung in der Protokolldatei catalina.out verbunden:

Listing 52: HTTP-Anfrage:

POST /webgoat/attack HTTP/1.1Host: Select "DAV:displayname" from scope()User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.0Accept-Language: en-us,en;q=0.0Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.0Connection: closeReferer: http://192.168.179.128/webgoat/attackCookie: JSESSIONID=9885AC16C6E36559C7751D07CC8395C3Authorization: Basic bWVtd2FkbWluOnZtd2FyZQ==Content-Type: application/x-www-form-urlencode




Content-Length: 12

person=bla

Listing 53: HTTP-Antwort:

HTTP/1.1 503 Service Temporarily UnavailableDate: Wed, 30 Nov 2005 23:24:43 GMTServer: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7e mod_jk/1.2.14Content-Length: 468Connection: closeContent-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>503 Service Temporarily Unavailable</title></head><body><h1>Service Temporarily Unavailable</h1><p>The server is temporarily unable to service yourrequest due to maintenance downtimVariablesize= 21

Listing 54: Korrespondierende Fehlermeldung in catalina.out:

01.12.2005 00:24:43 org.apache.jk.common.HandlerRequest invokeSCHWERWIEGEND: Error decoding request java.io.CharConversionException: Invalid char in port: 41

at org.apache.jk.common.HandlerRequest.parseHost(HandlerRequest.java:762)at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:516)at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363)at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)at


01.12.2005 00:24:43 org.apache.jk.common.ChannelSocket processConnectionWARNUNG: processCallbacks status 201.12.2005 00:24:43 org.apache.jk.common.HandlerRequest invokeSCHWERWIEGEND: Error decoding request java.io.CharConversionException: Invalid char in port: 41

at org.apache.jk.common.HandlerRequest.parseHost(HandlerRequest.java:762)at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:516)at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363)at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)at


01.12.2005 00:24:43 org.apache.jk.common.ChannelSocket processConnectionWARNUNG: processCallbacks status 201.12.2005 00:24:43 org.apache.jk.common.HandlerRequest invokeSCHWERWIEGEND: Error decoding request java.io.CharConversionException: Invalid char in port: 41

at org.apache.jk.common.HandlerRequest.parseHost(HandlerRequest.java:762)at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:516)at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363)at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)



at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)at


01.12.2005 00:24:43 org.apache.jk.common.ChannelSocket processConnectionWARNUNG: processCallbacks status 2

Durch weitere Tests wurde herausgefunden, dass bereits die Zeichenkette „Host: x:y“ im HTTP-Header ausreicht, um den Fehlerzustand im Tomcat auszulösen.

Aus der identifizierten Schwachstelle konnten keine Sicherheitsrisiken abgeleitet werden.

Mit dem durchgeführten Angriff konnte weder die Verfügbarkeit des Tomcat-Servers beeinträchtigt werden noch konnten interne / vertrauliche Daten (z. B. der Source-Code der angesprochenen JSP) veröffentlicht werden.

5.4.2 Angriffe einer maliziösen Web-Anwendung

Bei den Tests mit dem AJP-Connector (ohne SSL-Client-Zertifikate) werden die Werte einiger HTTP-Header von den Web Anwendungen in den Antworten variiert.

Hinweis: Der Test wird auf die HTTP-Header beschränkt, die von Servlets bzw. JSPs modifiziert werden können.


Gesamtablauf

Für die Durchführung und Dokumentation der Tests wurde eine einheitliche Vorgehensweise angewendet (siehe Abbildung 5.7).




Abbildung 5.7: Vorgehensweise Angriffe mit maliziöser Web-Anwendung



Maliziöse Anwendung

Ein Beispiel einer Web-Anwendung, welche maliziöse HTTP-Header erzeugt, wird nachfolgend dargestellt:

import java.io.*;import java.text.*;import java.util.*;import javax.servlet.*;import javax.servlet.http.*;public class T82 extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { String malstring=""; Vector v = null; if (v == null) { try{ BufferedReader br = new BufferedReader(new FileReader("/opt/jakarta-tomcat-5.5.9/webapps/malservlet/WEB-INF/classes/datei.txt")); v = new Vector(); while(br.ready()) v.add(br.readLine()); }catch(Exception e){} } Random r = new Random(); malstring= (String)v.get(r.nextInt(v.size())); response.setContentType("text/html"); PrintWriter out = response.getWriter(); response.addHeader("Date", malstring); out.println("<html>"); out.println("<head>"); String title = "Example_Title"; out.println("<title>" + title + "</title>"); out.println("</head>"); out.println("<body bgcolor=\"white\">"); out.println("<a href=\"../helloworld.html\">"); out.println("<img src=\"../images/code.gif\" height=24 " + "width=24 align=right border=0 alt=\"view code\"></a>"); out.println("<a href=\"../index.html\">"); out.println("<img src=\"../images/return.gif\" height=24 " + "width=24 align=right border=0 alt=\"return\"></a>"); out.println("<h1>" + title + "</h1>"); out.println("</body>"); out.println("</html>"); }}

In diesem Beispiel wird der Header Date mit schadhaften Inhalten gefüllt.

Die Java-Funktion, mit der die schadhaften HTTP-Header gesetzt werden, ist response.addHeader("Date", malstring).

Aus den vorangegangenen Tests, bei denen mit SPIKE schadhafte HTTP-Anfragen gestellt wurden, sind die von SPIKE erzeugten schadhaften Zeichenketten herausgefiltert und in der Datei /opt/jakarta-tomcat-5.5.9/webapps/malservlet/WEB-INF/classes/datei.txt gesammelt worden.




Abbildung 5.8 zeigt den Ablauf der schadhaften Web-Anwendung, welche auf eine HTTP-Anfrage eine HTTP-Antwort zurückgibt, in der ein HTTP-Header mit schadhaftem Inhalt gefüllt ist.

Abbildung 5.8: Ablaufschema der schadhaften Web-Anwendung

Abfrageskript

Um zweitausend mal die maliziöse Web-Anwendung anzufragen und dabei zweitausend mal einen anderen maliziösen Wert im HTTP-Header zu verarbeiten, wurde folgendes Skript benutzt.

#!/bin/bashi=0while ( [ $i -le 2000 ] ) ; doecho -e "GET /malservlet/T82 HTTP/1.0 \r\n\r\n"|nc localhost 80i=$[ i+1 ];done

Je nach Testfall wurde T82 durch T83, T84, etc. ersetzt.








• Enthält der HTTP-Reply des Tomcat-Servers HTTP-Meldungen wie „HTTP 500 (Internal Server Error)“ oder „HTTP 503 (Service Temporarily Unavailable)“?

5.4.2.3 Ergebnis


Test Nr. Testbeschreibung Resultat BemerkungT 66 Date OK Feld kann nicht mit beliebigen Inhalten

gefüllt werden.T 67 Last-Modified OK Feld kann nicht mit beliebigen Inhalten

gefüllt werden.T 68 Content-Type OKT 69 WWW-Authenticate OKT 70 Etag OKT 71 Expires OKT 72 Set-Cookie OKT 73 Set-Cookie2 OK

Tabelle 16: Testergebnisse T82 bis T89

Bei den Feldern Date und Last-Modified war es nicht möglich, den Inhalt des jeweiligen Feldes auf beliebige Werte zu setzen. Jeder Versuch, den Inhalt anders zu füllen als mit einer positiven Zahl (Anzahl Millisekunden seit dem 1.1.1970 0:00 Uhr) ergibt als Ausgabe das aktuelle Datum (z. B. „Date: Tue, 25 Oct 2005 16:23:38 GMT“) oder den 1.1.1970 („Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT“). Es konnten keine Schwachstellen identifiziert werden.

5.5 AJP Connector mit SSL Client Authentisierung

Abbildung 5.14 zeigt den Versuchsaufbau, bei dem vom Client Anfragen mit maliziösen Inhalten an den Apache Webserver gesendet und Zertifikatsinhalte an den Tomcat-Server weitergeleitet wurden.

Abbildung 5.9: Angriffe mit maliziösen SSL Client Zertifikaten




Bei den Tests mit dem AJP-Connector mit Authentisierung über SSL-Client-Zertifikate wurde versucht, Schwachstellen im mod_jk und in der AJP-Schnittstelle des Tomcat-Servers zu finden, ohne vorgelagerte Komponenten wie den Apache Webserver oder mod_ssl durch die Tests zu beeinflussen. Es wurde versucht Fehler im Apache oder in mod_ssl zu vermeiden, die womöglich dazu geführt hätten, dass die maliziösen Übergabeparameter gar nicht bis mod_jk oder zum Tomcat-Server gelangt wären.Zuerst wurde die Funktionsweise des Gesamtsystems bei Verwendung von SSL-Client- Zertifikaten analysiert, um einzelne Angriffe planen zu können.

5.5.1 Funktionsweise des Systems

Überblick

Abbildung 5.10 zeigt noch einmal die Funktionsweise, mit der der Datenfluss analysiert wurde.

Abbildung 5.10: Ablauf bei Authentisierung mit SSL Client-Zertifikat

Erzeugung des SSL-Client-Zertifikats

Die Erzeugung eines SSL-Client-Zertifikats wurde bereits in im Abschnitt 4.7.4 erläutert.

Verarbeitung in mod_ssl

Das Modul mod_ssl innerhalb des Apache Webservers, welches den Zugriff auf den Server über SSL implementiert, wurde so konfiguriert, dass ein solcher Zugriff nur erlaubt wird, wenn ein HTTPS-Client ein Client-Zertifikat einer anerkannten CA vorweist.

Hierfür wurden folgende Konfigurationsparameter in der Datei ssl.conf gesetzt:

SSLVerifyClient requireSSLCACertificateFile /root/bsitomcat_ca/ssl/ca/ca.pem



SSLVerifyDepth 1SSLOptions +StdEnvVars +ExportCertData +FakeBasicAuth

Die Option SSLVerifyClient require sorgt dafür, dass SSL-Verbindungsaufbauten ohne jegliches SSL Client-Zertifikat abgelehnt werden.

Die Option SSLCACertificateFile bestimmt, dass die Client-Zertifikate auf eine Signatur der CA geprüft werden, dessen öffentlicher Schlüssel im Zertifikat in der angegebenen Datei enthalten ist. Clients mit Zertifikaten, die nicht von dieser CA signiert wurden, sollen dabei abgelehnt werden.

Die Option SSLVerifyDepth 1 bestimmt, dass nur eine Zertifizierungsebene geprüft wird. Ein Client-Zertifikat, welches nicht von der anerkannten CA, sondern von einer anderen CA ausgestellt worden ist, wird damit nicht akzeptiert, selbst wenn der öffentliche Schlüssel dieser anderen CA von der anerkannten CA signiert wurde.

In der Option SSLOptions sorgt der Parameter +ExportCertData dafür, dass der Webserver die Inhalte des SSL-Client-Zertifikats an mod_jk weitergibt. Ist diese Option nicht aktiv, so werden die Inhalte des Client-Zertifikats nicht an mod_jk und somit nicht an den Tomcat-Server weitergegeben. Die anderen Parameter der Option SSLOptions sind für die Authentisierung per SSL-Client-Zertifikat nicht relevant und werden hier nicht näher erläutert.

Verarbeitung in mod_jk

Das Modul mod_jk gibt die übergebenen Zertifikatsinhalte ungefiltert an den AJP-Connector des Tomcat-Servers weiter.

Verarbeitung im AJP-Connector

Die Komponente mod_jk übergibt ein vom HTTP-Client abgesendetes SSL-Client-Zertifikat über das AJP-Protokoll dem AJP-Connector im Tomcat. Der folgende Netzwerkmitschnitt zeigt dabei, dass das Zertifikat als Ganzes, d. h. noch nicht in einzelne Komponenten aufgeteilt, übergeben wird.




Abbildung 5.11: Mitschnitt des AJP-Protokolls mit Ethereal

Die vorige Abbildung zeigt die Anzahl der Netzwerkpakete, die zwischen mod_jk bzw. dem Apache Webserver und dem AJP-Connector des Tomcat-Servers bei einer einfachen HTTP(S)-Anfrage entstehen. Die Anfrage lautet beispielhaft:

"GET /simple_info1/index.jsp HTTP/1.0\r\n\r\n"



Abbildung 5.12: Inhalt des AJP-Netzwerkmitschnitts

Welche Inhalte bei diesem Datentransfer fließen, ist in der folgenden Abbildung zu sehen.

Der Webserver bzw. mod_jk übergibt dem AJP-Connector des Tomcat-Servers das SSL- Client-Zertifikat (umrahmt von „BEGIN CERTIFICATE“ und „END CERTIFICATE“), eine Information über den Verschlüsselungsalgorithmus („DHE-RSA-AES256-SHA“) sowie die SSL Session-ID („@08D320A8...“).

Zertifikatsauswertung im Tomcat

Der folgende Source Code der Datei request_data.jsp zeigt, wie die Zertifikatsinhalte ausgewertet werden.

Listing 55: Datei request_data.jsp

<html><%@ page language="java" import="java.security.cert.*,java.lang.reflect.*"%><head> <title> Display HTTP Request Data </title> </head><body><% java.util.Enumeration attNames = request.getAttributeNames(); java.util.Enumeration paramNames = request.getParameterNames(); java.util.Enumeration hdrNames = request.getHeaderNames(); %> <h1>Request = <br /> <%= request.getMethod() %> <%= request.getServerName() %>:




<%= request.getServerPort() %> <%= request.getProtocol() %> </h1>

<hr /> <h2><font color=red>Request header entries:</font></h2> <% while (hdrNames.hasMoreElements()) { String name = (String) hdrNames.nextElement(); String value = request.getHeader(name); out.println("<b>" + name + "</b>: " + value + "<br />"); } %><hr /> <h2><font color=red>Request parameters:</font></h2> <% while (paramNames.hasMoreElements()) { String name = (String) paramNames.nextElement(); String value = request.getParameter(name); out.println("<b>" + name + "</b>: " + value + "<br />"); } %><hr /> <h2><font color=red>Request attributes:</font></h2> <% while (attNames.hasMoreElements()) { String name = (String) attNames.nextElement(); Object value = request.getAttribute(name); out.println("<b>" + name + "</b>: " + value + "<br />"); // check, if name contains "X509Certificate" i.e. // we have certificate(s) in our current entry

int x509index = name.indexOf("X509Certificate"); if (x509index > 1) {

int i;// there can more than one certificates be encoded// in the current attributeX509Certificate certs[] = (X509Certificate[])request.getAttribute(name);for(i=0; i<certs.length; i++) { // display all relevant information out.println("#####<b>certificate[" + i + "]</b>#####"

+ "<ul>"+ "<li/><i>SubjectDN</i>: "

+ certs[i].getSubjectDN()+ "<li/><i>IssuerDN</i>: "

+ certs[i].getIssuerDN()+ "<li/><i>SerialNumber</i>: "

+ certs[i].getSerialNumber()+ "<li/><i>Signature</i>: "

+ certs[i].getSignature()+ "<li/><i>NotBefore</i>: "

+ certs[i].getNotBefore()+ "<li/><i>NotAfter</i>: "

+ certs[i].getNotAfter()+ "<li/><i>Version</i>: "

+ certs[i].getVersion()+ "<li/><i>SigAlgorithm</i>: "

+ certs[i].getSigAlgName()+ "<li/><i>SigAlgParmams</i>: "

+ certs[i].getSigAlgParams()+ "<li/><i>KeyUsageExt</i>: "

+ certs[i].getKeyUsage()+ "</ul>");

} }}%><hr /></body></html>



Die oben abgebildete JSP-Datei bekommt als Parameter ein Array von X509-Zertifikaten übergeben (Typ X509Certificate[]), welches es einzeln mit Methoden der JSSE auswertet.

Die Methoden getSubjectDN(), getSerialNumber(), getSigAlgParams() usw. der Klasse java.security.cert.X509Certificate werden dabei von SUN (JSSE 5 innerhalb des JDK 5) zur Verfügung gestellt, sind also nicht Bestandteil von Tomcat.

5.5.2 Angriffe

Ausgehend von der oben geschilderten Analyse der Funktionsweise wurden für die Penetrationstests folgende Schlussfolgerungen getroffen:

• Das Modul mod_jk decodiert / analysiert das vom Web Browser übergebene X509-codierte Client-Zertifikat nicht. Angriffe durch ungewöhnliche Zeichenketten im Common Name (CN) oder Distinguished Name (DN) des Zertifikats können somit in mod_jk keine unerwarteten Effekte verursachen.

• auf Ebene des AJP-Connectors wird das Zertifikat ebenfalls nicht decodiert, womit ungewöhnliche Zeichenketten in den Zertifikatsattributen auch hier keine unerwarteten Effekte auslösen können.

• Für die Auswertung / Verarbeitung der Zertifikatsinhalte werden JSSE-Klassen von SUN verwendet, die nicht Bestandteil von Tomcat sind. Diese sind also nicht Gegenstand unserer Untersuchung.

Die verbleibenden Angriffsmöglichkeiten bestehen darin, die Länge des X509-Zertifikats variabel zu gestalten, um somit eventuelle Puffergrenzen in mod_jk oder im AJP-Connector des Tomcat-Servers zu überschreiten.

Da die einzelnen Felder eines X509-Zertifikats nur 64 Zeichen lang sein können [ISIS MTT] (mehr wird vom eingesetzten Werkzeug openssl auch nicht unterstützt), aber beliebig viele Attribute für OU (Organisation Unit) erlaubt sind, wurde die Gesamtlänge des SSL-Client-Zertifikats dadurch beeinflusst, dass wenige oder viele OU-Attribute gesetzt wurden. Somit konnten Zertifikatslängen bis zu 200KB erzeugt werden (übliche Länge: etwa 1KB).

5.5.2.1 Testfälle

Es wurden die folgenden vier Tests durchgeführt.

Test Nr. Testbeschreibung Erwartetes ResultatT 74.1 Client-Zertifikat mit 4389 Byte Länge (10 OU-

Attribute)OK

T 90.2 Client-Zertifikat mit 4393 Byte (100 OU-Attribute) OKT 90.3 Client-Zertifikat mit 33643 Byte (1000 OU-Attribute) OKT 90.4 Client-Zertifikat mit 196147 Byte (6000 OU-

Attribute)OK

Tabelle 17: Übersicht über die Penetrationstests, AJP-Connector mit Authentisierung über SSL-Client-Zertifikate




Eine Erzeugung von noch längeren SSL-Client-Zertifikaten scheiterte am verwendeten Werkzeug openssl, welches bei wesentlich mehr als 6000 OU-Attributen mit einer Fehlermeldung abbrach.

Das Skript, mit dem die Client-Zertifikate erzeugt wurden, wurde bereits im Abschnitt 4.7.4 gezeigt. Es wurde nur dadurch erweitert, dass statt eines OU-Attributswertes mehrere angegeben wurden:

Listing 56: Ergänzung zum Skript setup_client_cert.sh...#--------------------------------------------------------------# Create a client certificate request:malstring=`/usr/bin/perl -e'print "/OU=Organisation1"x100'`openssl req -new \ -newkey rsa:2048 \ -nodes \ -out ${CLIENT_DIR}/${CLIENT}.req \ -keyout ${CLIENT_DIR}/${CLIENT}.key \ -subj "/CN=${CLIENT}${malstring}/L=Bonn/ST=NRW/C=DE/emailAddress=${CLIENT}@bsitomcat.de/O=BSITomcat ITC-Sec"...




In Abbildung 5.13 ist die Vorgehensweise bei der Durchführung der Angriffe dargestellt.

Abbildung 5.13: Vorgehensweise bei SSL-Zertifikats-Authentisierung









• Enthält der HTTP-Reply des Tomcat-Servers HTTP-Meldungen wie „HTTP 500 (Internal Server Error)“ oder „HTTP 503 (Service Temporarily Unavailable)“?

5.5.2.4 Ergebnis


Test Nr. Testbeschreibung Erwartetes Resultat

Bemerkungen

T 90.1 Client-Zertifikat mit 4389 Byte Länge (10 OU-Attribute)

OK

T 90.2 Client-Zertifikat mit 4393 Byte (100 OU-Attribute)

OK


Fehler Fehlerzustand in mod_jk: ajp_marshal_into_msgb::jk_ajp_common.c (490): failed appending the SSL certificates

Keine HTTP-Antwort

Netzwerkdump zeigt, dass nicht das ganze SSL-Zertifikat von mod_jk zum Tomcat übertragen wird.

Kein Eintrag in den Logs des Tomcat-Servers.


Fehler Keine Vollendung des SSL-Verbindungsaufbaus.

Tabelle 18: Ergebnisse der Tests mit SSL Client-Zertifikat

Fehler in Test T90.3

Bei der Verwendung von 1000 OU-Attributen im Client-Zertifikat trat ein Fehler auf, der im mod_jk.log dokumentiert wurde:

[Fri Oct 28 17:49:1130514593 2005] [error] ajp_marshal_into_msgb::jk_ajp_common



.c (490): failed appending the SSL certificates[Fri Oct 28 17:49:1130514593 2005] [info] ajp_service::jk_ajp_common.c (1662): Creating AJP message failed, without recovery[Fri Oct 28 17:49:1130514593 2005] bsi_ajp13_1 www.example.com 0.000482[Fri Oct 28 17:49:1130514593 2005] [info] jk_handler::mod_jk.c (1964): Aborting connection for worker=bsi_ajp13_1

In der HTTP-Anwort des Webservers kann man erkennen, dass der Webserver die HTTPS-Anfrage nicht verarbeiten kann:

Listing 57: HTTP-Antwort des WebserversHTTP/1.1 413 Request Entity Too LargeDate: Fri, 28 Oct 2005 15:38:40 GMTServer: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7e mod_jk/1.2.14Content-Length: 474Connection: closeContent-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>413 Request Entity Too Large</title></head><body><h1>Request Entity Too Large</h1>The requested resource<br />/simple_info1/index.jsp<br />does not allow request data with GET requests, or the amount of data provided inthe request exceeds the capacity limit.<hr><address>Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7e mod_jk/1.2.14 Server at www.example.com Port 443</address></body></html>

Der Test T90.3 ergab keine sicherheitsrelevanten Hinweise.

Fehler in Test T90.4

Bei der Verwendung von 6000 OU-Attributen im Client-Zertifikat ist die SSL-Verbindung zwischen openssl als Client und dem Webserver bzw. mod_ssl abgebrochen worden.

Der openssl-Client hat dabei folgende Fehlermeldung ausgegeben:

depth=1 /CN=BSITomcat ITC-Sec CA/L=Bonn/ST=NRW/C=DE/[email protected]/O=BSITomcat ITC-Sec Certification Authorityverify return:1depth=0 /CN=tomcathost/L=Bonn/ST=NRW/C=DE/[email protected]/O=BSITomcat ITC-Secverify return:1write:errno=32

Im Netzwerkmitschnitt kann man erkennen, dass die SSL-Verbindung zwar aufgebaut, dann aber sofort wieder abgebaut wird (Abbildung 5.12).




Abbildung 5.14: Netzwerkmitschnitt von Test T90.4

Der als T904_ethereal_dump.dmp abgespeicherte Netzwerkmitschnitt wurde mit tcpflow analysiert. Dabei zeigte sich, dass das TCP-Paket des openssl-Clients an den Webserver nur 1353 der 6000 OU-Attribute enthält und danach abrupt endet.

Offensichtlich ist der Funktionsmangel in openssl begründet und nicht in mod_jk oder Tomcat. Der Test T90.4 ergab keine sicherheitsrelevanten Hinweise.

5.6 Quellcode-Analysen

Ziel der Quellcode-Analyse ist es, sicherheitsrelevante Programmierfehler in Tomcat zu finden. Solche Fehler könnten auf Schwächen in der Implementierung, z. B. Pufferüberläufe, Race Conditions und unsichere System-Calls oder auf Schwächen in der Architektur selbst, wie fehlerhafte Zugriffskontrolle durch falsch definierte Rollen basieren.

Der Fokus wird hierbei auf den Quellcode gerichtet, der Eingaben von nicht vertrauenswürdigen Quellen entgegen nimmt oder der Sicherheitsfunktionen des Tomcat bereitstellt. Die Quellcode Analyse besteht dabei aus zwei Teilen.

5.6.1 Automatische Überprüfung des Quellcodes

Für die automatische Analyse des C-Quell-Codes wurden die Werkzeuge flawfinder und splint eingesetzt. Beide entstammen dem Bereich der Open Source. Das bekannte Programm rats ist dagegen nicht frei erhältlich. Es wird auch nicht weiter benötigt, weil es sich mit den Fähigkeiten von flawfinder überschneidet. Ähnliches gilt für ITS4, das wohl berühmteste von allen. Da es in durchgeführten Analysen von den anderen Programmen übertroffen wird, besitzt es nunmehr eher historischen Charakter.



Für die automatische Analyse des Java-Quell-Code wurde das Werkzeug findbugs47

eingesetzt. Es hat gegenüber anderen Werkzeugen wie pmd48 den Vorteil, dass es sich weniger auf syntaktische Elemente beschränkt. Vielmehr berücksichtigt es auch Besonderheiten der objektorientierten Programmierung (OOP). So nimmt es beispielsweise auch Prüfungen an der Vererbungshierarchie vor.

Es wird hierbei der Quellcode von Tomcat der in Java programmiert ist, sowie der Apache-seitige AJP-Connector mod_jk, der in C programmiert ist, analysiert.

Die Ergebnisse der Analysewerkzeuge werden gesichtet und bezüglich ihrer Sicherheitsrelevanz priorisiert.

Jedes der genannten Werkzeuge liefert eine Liste von Meldungen. Einige davon bedürfen keiner weiteren Prüfung, z. B. beim Erkennen einer unbenutzten Variable. Für Sicherheitsanalysen jedoch gilt, dass jede Meldung, die relevant sein könnte, im Quelltext erst mal geprüft werden muss. Der Grund ist, die Werkzeuge sind nicht gut genug, um die Fehler mit Bestimmtheit fest zu stellen. Die Zahl der Falschmeldungen wie „möglicher Fehler“ oder „mögliche gefährliche Verwendung von ...“ machen leider den allergrößten Teil der Meldungen aus.

Dennoch sind solche Werkzeuge nützlich, denn sie zeigen Bereiche im Quelltext, in denen beispielsweise Puffer variabler Länge verwendet werden. Solche Bereiche können dann manuell untersucht werden. Das bedeutet, die Werkzeuge dienen vor allem der Orientierung während eines Software Reviews.

Folgendes Beispiel zeigt dieses Zusammenspiel. Flawfinder moniert jedes Vorkommen von strlen(), darunter:

mod_jk.c:1044: [1] (buffer) strlen: Does not handle strings that are not \0-terminated (it could cause a crash if unprotected).

In den allermeisten Fällen ist die Verwendung von strlen() unproblematisch, jedoch zeigt das manuelle Sichten des Umfelds dieser Funktion, dass eine ungeschützte Speicherallokation vorkommt, die bei Speichermangel zum Absturz des Apache führen kann:

static void request_log_transaction(request_rec * r, jk_server_conf_t * conf){[...] strs = apr_palloc(r->pool, sizeof(char *) * (format->nelts)); strl = apr_palloc(r->pool, sizeof(int) * (format->nelts)); items = (request_log_format_item *) format->elts; for (i = 0; i < format->nelts; ++i) { strs[i] = process_item(r, &items[i]); }

5.6.2 Manuelle Überprüfung des Quellcodes

Das Ergebnis der automatischen Überprüfung wird durch eine manuelle Sichtung des Quellcodes ergänzt. Ausgesuchte Softwareteile werden gesichtet und auf das

47 http://findbugs.sourceforge.net/ 48 http://pmd.sourceforge.net/


http://pmd.sourceforge.net/

http://findbugs.sourceforge.net/



Vorhandensein von Schwachstellen geprüft. Beschreibungen der Sicherheitslücken und der daraus resultierenden Bedrohungen werden mit Beispielen aufgezeigt. Es wird nicht geprüft, ob gefundene Schwachstellen auch ausnutzbar sind.

Die Vorgehensweise der manuellen Prüfung unterscheiden sich bei C und Java.

Bei der Programmiersprache C kann eine Datei bzw. Modul untersucht werden, in dem sie linear von oben bis unten durchgesehen wird. Favorisiert wird dabei eine Bottom-Up-Analyse. Dieser Ansatz setzt einen Aufbau der Datei voraus, der für die Programmiersprache Pascal üblich ist. Hier ist es nämlich nahezu erforderlich Vorwärtsreferenzen zu vermeiden. Dies bedeutet, Prozeduren weiter unten im Quelltext nutzen die Unterprozeduren weiter oben im Quelltext.

Der Vorteil dieser Vorgehensweise liegt darin, dass kaum falsche Annahmen über kleine Hilfsfunktionen gebildet werden, z. B. ob NULL als Parameter erlaubt ist oder nicht. Beim Betrachten der kleinen Unterprozedur kann also ein sofortiger Abgleich zwischen dem bisher aufgebauten Wissen aus früheren Prozeduren, Dokumentationen und Codes stattfinden. Das Wissen über die Funktionsweise des Code wird dabei inkrementell aufgebaut und validiert. Schreitet man bei der Analyse fort, so gelangt man zu den Prozeduren weiter unten in der Datei und kennt die Einsatzbedingungen sowie Nebeneffekte der darin aufgerufenen, bereits analysierten Prozeduren bestens.

Wer dagegen die Analyse zuerst mit den übergeordneten Prozeduren beginnen würde, müsste viele Annahmen über die darin aufgerufenen Prozeduren und Module bilden. Das menschliche Gehirn ist aber nicht besonders geeignet im Zurücknehmen von falschen Annahmen.

Die oben geschilderte Vorgehensweise ist für viele Programmiersprachen anwendbar, darunter Ada, Lisp und C++. Für formale Sprachen mit Möglichkeiten bis hin zum Beweisen von Programmeigenschaften wie bei B oder VDM ist auch der umgekehrte Ansatz denkbar, also von oben (abstrakt) nach unten (detailliert). Er wird, wie in der Mathematik auch üblich, so praktiziert.

Speziell bei Java Java hingegen gibt es Hürden bei der Analyse:

1. Der Quellcode liegt seltenst in der für das Review idealen Pascal-ähnlichen Form vor. In Tomcat sind ausreichend Beispiele zu finden, wo Variablen an beliebiger Stelle innerhalb einer Datei definiert werden. Stellenweise referenzieren Methoden Variablen, die erst weiter unten im Quellcode definiert werden. Darüber hinaus werden Hilfsfunktionen gerne ans Dateiende verlagert. Diese Tendenz wird durch den Einsatz von grafischen Benutzeroberflächen (IDE) vermutlich verstärkt, weil individuelle Methoden per Mausklick angesprungen werden und der logische Aufbau der Datei dadurch in den Hintergrund gerät.

2. Es kommt erschwerend immer wieder vor, dass konzeptuell zusammengehörige Funktionalitäten sich wegen objektorientierter Vererbungshierarchien über mehrere Klassen und damit auch Dateien verteilen. Wer Java analysiert, wird daher zwangsläufig zwischen Methoden hin und herspringen, die über mehrere Dateien verteilt sind. Ein Beispiel dafür liefert die Hierarchie JSSE14SocketFactory → JSSESocketFactory → ServerSocketFactory (vgl. T92). Hier wird das Verarbeiten der Konfigurationsattribute auf zwei Dateien verteilt, während die Attribute selbst aus einer dritten Datei stammen.



3. Viele APIs von Java durchdringt der Wunsch nach möglichst großer Austauschbarkeit von Komponenten. Dieser bewirkt leider, dass eine Funktionalität stets indirekt aufgerufen wird, oftmals über Konfigurationsdateien statt direkt erkennbar im Code. Dies erzeugt eine Vielzahl von Interfaces und Adapterklassen. Damit wächst der Bedarf an Schnittstellen anpassenden Klassen enorm. Die Zahl der Methoden steigt, weil viele nur für die Schnittstellenanpassung nach beiden Seiten hin benötigt werden. Gemeint sind mit letzterem bzgl. eines Moduls die Schnittstelle „angebotenen Leistung“ und die Schnittstelle zu den dafür benötigten anderen Modulen. In der Sprache der Entwickler reflektiert sich dies durch Metaphern im Bereich der Klempnerei, z. B. Adapter, Connectoren oder Valves kanalisieren Informationen, die von Modulen verarbeitet werden.

Die wenigsten Werkzeuge sind in der Lage, Datenflussanalysen über mehrere Funktionen hinweg durchzuführen. Dazu wäre auch das Erkennen von Protokollen oder Traces nötig, was im allgemeinen sehr schwierig und noch Gegenstand von Forschungsarbeiten ist. Mit Protokollen oder Traces ist im Rahmen der Programmanalyse die Aufrufreihenfolge von Methoden eines Objekts oder eines abstrakten Datentyps gemeint. Daraufhin könnte die festgestellte Reihenfolge mit einer spezifizierten Reihenfolge verglichen werden. Der Begriff Methode bezieht sich nicht nur auf objektorientierte Programmierung (OOP). Auch für C kann modelliert werden, dass beispielsweise für Objekte vom Typ FILE* gilt: fopen() → ... → fclose(), d. h. auf den Konstruktor (fopen) muss das Schließen der Datei (fclose) folgen.

Ansätze davon sind in der verschiedenen Werkzeuge enthalten. So erkennt splint die Aufrufe von malloc() und kann unter Umständen melden, wenn ein Speicher nicht freigegeben wird.

Findbugs enthält eine einfach Regel, die auch ohne Datenflussanalyse implementiert werden könnte. Ein Konstruktor sollte sämtliche Instanzenvariablen initialisieren. Leider wird bei der OOP oftmals von diesem eleganten Modell abgewichen. Stattdessen müssen bestimmte Methoden, typischerweise init, set o. ä. genannt, aufgerufen werden, bevor die meisten Methoden des Objekts angesprochen werden dürfen und das Objekt sinngemäß voll initialisiert ist. Ein Beispiel soll das verdeutlichen:

Listing 58: Eine Warnung von Findbugs zu möglicherweise uninitialisierten Variablen:Field not initialized in constructor: org.apache.jk.common.JkInputStream.mc

JkInputStream.java

Listing 59: Quellcodeauszug zur Klasse org.apache.jk.common.JkInputStream49: /** Must be called when the stream is created */ public void setMsgContext( MsgContext mc ) { this.mc=mc; }

Aus verschiedenen Gründen war es nicht möglich, den MsgContext bereits dem Konstruktor mitzuteilen. Erst nachdem der Wert nachgeliefert wurde, kann das Objekt zum Lesen benutzt werden. Obiges Listing zeigt, dass das API diese Anforderung erwähnt.

49 Datei jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkInputStream.java




Der maschinelle Nachweis, dass setMsgContext stets vor anderen Methoden dieser Klasse aufgerufen wird, ist alles andere als trivial.

Das Entwurfsmuster Factory bietet hierzu eine saubere, aber leider aufwändige Lösung an: die Trennung der Zustände „teilweise initialisiert“ und „voll initialisiert“ wird durch zwei verschiedene Objekttypen bzw. -klassen erreicht. Die Factory stellt den ersten Zustand dar und speichert einige Eigenschaften, die anschließend beim Individualisieren an das daraufhin voll initialisierte Objekt der getrennten Klassen weitergegeben wird. Durch die getrennten Klassen kann kein Zugriff auf ein uninitialisiertes Objekt erfolgen.

Positiv ist bei Java gegenüber C zu vermerken, dass die Sprache und die Ausführung der Bytecodes auf einer JVM besser definiert sind. Auch gibt es kein Pointer Aliasing, das Analysen erschweren würde. Dies hat zur Folge, dass Java oder JVM-basierte Systeme gerne in kleinen sicherheitsrelevanten Anwendungen, z. B. bei Chipkarten eingesetzt werden. Bei kleinen Anwendungen mit maximal zweitausend Zeilen Code werden formale Beweismethoden praktikabel und bereits eingesetzt.

5.6.3 Umfang der Quellcode-Analyse

Der Fokus der automatischen Überprüfung wird bei Quellcode in C (z. B. mod_jk) auf die Suche nach potentiellen Pufferüberläufen und Format-String-Schwächen gerichtet.

Es werden die Quellcode-Teile des Tomcat, die Verschlüsselungsfunktionen und Authentisierungsfunktionen bereitstellen, manuell gesichtet und auf Sicherheitsprobleme hin untersucht. Bei der Verschlüsselung werden die Schnittstellen zu JSSE untersucht. Die SSL-Implementierung von Java selbst ist nicht Bestandteil der Untersuchung. Weiterhin werden die Programmteile von Tomcat untersucht, die Authentisierungsfunktionen bereitstellen. Die externen Softwarekomponenten, z. B. JDBC-Schnittstellen zu Datenbanken, Java-Komponenten wie JNDI oder JAAS, die bei den entsprechenden Authentisierungsmethoden verwendet werden, sind jedoch nicht Gegenstand der Untersuchung.

Falls die früher durchgeführten Tests wesentliche Abweichungen von den Sicherheitszielen oder fehlerhafte Sicherheitsfunktionen von Tomcat identifiziert haben, werden die entsprechenden Teile des Quellcodes in dieser Phase natürlich genauer betrachtet.

Um das Ergebnis der Analyse vorwegzunehmen - Fehler und Inkonsistenzen wurden zwar gefunden, aber keine solchen, die die Sicherheitsziele gefährden. Die gefundenen Fehler wurden bzw. werden den Entwicklern mitgeteilt, meist in der Form von Bugmeldungen. Deren Bearbeitungsstand kann in sog. Bugtracker-Systemen online50 nachgesehen werden.

Die folgenden Tabelle fasst die Tests bezüglich des Quellcodes zusammen:


Bemerkungen

T 75 Automatische Quellcode Überprüfung auf Pufferüberlauf und Format String Schwächen

unbekannt flawfinder und splint für C, findbugs für Java

T 76 Manuelle Sichtung des Quellcodes: Schnittstellen zu JSSE (SSL)

unbekannt

50 http://bugzilla.apache.org/ darin Produkt Tomcat 5 auswählen, dazu die Komponente JK oder Catalina


http://bugzilla.apache.org/



Bemerkungen

T 77 Manuelle Sichtung des Quellcodes: Authentisierungsmethoden

unbekannt

T 78 Manuelle Sichtung des Quellcodes vorher identifizierter Probleme

unbekannt

Tabelle 19: Übersicht über die Quellcode Analysen

5.6.3.1.1 T91/T94 Automatische und manuelle Prüfung des QuellcodeEs ist sinnvoll, automatische und manuelle Prüfung zu verbinden, da die Ergebnisse der mechanischen Werkzeuge stets manuell begutachtet werden müssen. Dies liegt in den vielfältigen Einschränkungen der Analysefähigkeit der Werkzeuge, aber auch in den Grenzen der automatischen Programmanalyse begründet.

Flawfinder ist zum Aufspüren von Fehlern zu Pufferüberläufen ganz brauchbar. Eine Anwendung auf die Datei mod_jk.c ließ aufgrund der geringen Anzahl der Warnungen vermuten, die Autoren dieses Moduls haben das Werkzeug bereits selbst eingesetzt. Eine Suche in Mailinglisten, Kommentaren im Code oder den Änderungsvermerken in den ChangeLog ergab dazu jedoch keinen Hinweis.

Listing 60: Statistiken von Flawfinder zu mod_jk.c:Flawfinder version 1.26, (C) 2001-2004 David A. Wheeler.Number of dangerous functions in C/C++ ruleset: 158Examining mod_jk.cmod_jk.c:243: [2] (buffer) char: Statically-sized arrays can be overflowed. Perform bounds checking, use functions that limit length, or ensure that the size is larger than the maximum possible length. [...]mod_jk.c:2691: [1] (buffer) strlen: Does not handle strings that are not \0-terminated (it could cause a crash if unprotected).Hits = 13Lines analyzed = 2736 in 1.34 seconds (3252 lines/second)Physical Source Lines of Code (SLOC) = 1856Hits@level = [0] 0 [1] 9 [2] 4 [3] 0 [4] 0 [5] 0Hits@level+ = [0+] 13 [1+] 13 [2+] 4 [3+] 0 [4+] 0 [5+] 0Hits/KSLOC@level+ = [0+] 7.00431 [1+] 7.00431 [2+] 2.15517 [3+] 0 [4+] 0 [5+] 0Minimum risk level = 1Not every hit is necessarily a security vulnerability.There may be other security vulnerabilities; review your code!

Obiges Listing enthält die erste und letzte Meldung von Flawfinder zur Datei mod_jk.c. Flawfinder fügt jeder Meldung einen Sicherheitslevel hinzu. Jede solche Meldung oder zumindest die der höchsten Level kann anschließend manuell auf Falschmeldungen geprüft werden.

Feststellung: jk_error_exit() formatiert die Fehlermeldungstext im printf()-Stil über apr_pvsprintf() aus der Bibliothek APR von Apache, übergibt den formatierten String jedoch an ap_log_error(), welches wiederum eine printf()-Formatierung durchführt. Nach der ersten




Formatierung übrig gebliebene oder entstandene %-Zeichen würden beim zweiten Mal zu Fehlverhalten führen. Derzeit wird jk_error_exit() nur mit der Text "Memory Error" aufgerufen, der Fehler kommt also nicht zum Tragen.

Ganz anders würde es sich verhalten, wenn beliebige Texte zum Einsatz kämen. Während der Projektlaufzeit wurde von anderer Stelle ein ähnlicher Fehler in der libgda für GNOME gefunden, der zu einer CERT-Meldung51 und sofortigem Security Patches führte.

Leider erkennt keines der eingangs beschriebenen und auch der für die Tests verwendeten Werkzeuge eine solche Doppelformatierung automatisch.

Feststellung: Die Funktion jk_log()52 implementiert unzureichende Vorkehrungen gegen einen Pufferüberlauf. Die gefundenen Fehler sind jedoch wahrscheinlich nicht ausnutzbar. Detailiertere Beschreibung:

1. In folgender Codezeile muss die Puffergröße entsprechend der bereits enthaltenen Zeichen reduziert werden, es sollte also HUGE_BUFFER_SIZE – used heißen:

used += snprintf(&buf[used], HUGE_BUFFER_SIZE/*-used fehlt hier!*/, "%s (%d): ",

2. Das Mitzählen der benutzten Zeichen über used += snprintf(...,limit,...) ist ebenfalls problematisch, weil POSIX spezifiziert, dass der Rückgabewert der Funktionen snprintf(), vsnprintf() usw. beliebig größer als der übergebene Grenzwert wird, wenn der Puffer nicht groß genug ist. Der Rückgabewert ist die Größe, die benötigt worden wäre, um den Text vollständig zu formatieren. Als Folge würde der Wert von BUFFER_SIZE - used negativ bzw. aus Sicht von snprintf() eher enorm groß, da diese Funktionen mit natürlichen Zahlen (unsigned long) anstelle von vorzeichenbehafteten Zahlen (int oder long) arbeiten. Die Grenzwertüberprüfung wird damit effektiv außer Kraft gesetzt. Außerdem verweist &buf[used] bei darauf folgenden Aufrufen auf ungültigen Speicher!

3. Die Funktion verwendet return nicht nur als letzte Zeile, so dass der auf bestimmten Systemen (NETWARE) mit malloc() allokierte Speicher dann nicht freigegeben wird.

Trotz dieser Fehler vermuten wir, dass die Funktion kaum missbraucht werden kann, da der Überlauf nur durch überlange Dateinamen ausgelöst werden kann, die im Code fest eincompiliert sind, so dass für diese der verwendete Puffer (8KB) groß genug sein müsste.

Feststellung: In mod_jk werden die Rückgabewerte der Funktionen von APR zur Speicherallokation wie z. B. apr_palloc() nur stellenweise abgefragt.

Ein systematisches Abfragen ist nicht zwanghaft, denn APR53 stellt ebenfalls einen Callback zur Verfügung, der bei Speichermangel aufgerufen werden könnte:

pool->abort_fn(APR_ENOMEM);

Dazu müsste dieser jedoch gesetzt werden. Wer darf diesen setzen und welche Möglichkeiten bieten sich dann in C (wo könnte der Code hin springen, um die aktuelle

51 http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=libgda/libgda&command=D IFF_FRAMESET&file=gda-log.c&rev1=1.12&rev2=1.13&root=/cvs/gnome

52 Datei jakarta-tomcat-connectors-1.2.14.1-src/jk/native/common/jk_util.c 53 Datei apr_pools.c der Bibliothek APR, ebenfalls in Apache enthalten


http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=libgda/libgda&command=DIFF_FRAMESET&file=gda-log.c&rev1=1.12&rev2=1.13&root=/cvs/gnome

http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=libgda/libgda&command=DIFF_FRAMESET&file=gda-log.c&rev1=1.12&rev2=1.13&root=/cvs/gnome


Funktion zu beenden)? Sprachen mit Exception Handling haben es hier wesentlich einfacher.

Feststellung: mod_jk enthält einen Ersatz für die Funktion vsnprintf(), der zur Anwendung kommt, wenn diese im Betriebssystem nicht enthalten ist. Dies wird aber beim Compilieren und nicht zur Laufzeit festgestellt. Diese Ersatzfunktion ruft Funktionen von POSIX inkorrekt auf, so dass die erwünschte Funktionalität nicht sichergestellt werden kann. Linux-Systeme sind davon nicht betroffen, weil die darin verwendete glibc diese Funktion bereits seit Jahren zur Verfügung stellt.

Listing 61: vsnprintf-Ersatz in jk_util.c:#if !defined(HAVE_VSNPRINTF) && !defined(HAVE_APR)static FILE *f = NULL;static int vsnprintf(char *str, size_t n, const char *fmt, va_list ap){ int res;

if (f == NULL) f = fopen("/dev/null", "w"); if (f == NULL) return -1;

setvbuf(f, str, _IOFBF, n);

res = vfprintf(f, fmt, ap);

if (res > 0 && res < n) { res = vsprintf(str, fmt, ap); } return res;}#endif

Die Abweichungen von POSIX sind gemäß Manpage zu setvbuf wie folgt beschrieben:

1. „You must make sure that both buf and the space it points to still exist by the time stream is closed, which also happens at program termination.“. Der übergebene Puffer str hat aber eine ganz kurze Lebensdauer und die Datei wird erst bei Programmende (exit) geschlossen.

2. „The setvbuf function may only be used after opening a stream and before any other operations have been performed on it.“ Die Datei in der globalen Variable f wird jedoch offen gehalten, die Funktion bei jedem Logvorgang erneut aufgerufen, also nach dem vorigem Schreiben eines Logeintrags.

Feststellung: Aus Sicht eines Code-Reviews wäre es wünschenswert, stellenweise Änderungen am Code vorzunehmen, die die Lesbarkeit erhöhen. Diese Feststellung betrifft die Sicherheit nur indirekt sollte aber für das Review als Sicherheitsmaßnahme beachtet werden:

• die Funktion ws_write() in mod_jk verwendet sowohl eine Variable Namens r als auch einen Feldnamen gleichen Namens.




• Funktionen in mod_jk verwenden beispielsweise wiederum in ws_write() eine Variable Namens l, die leicht mit der Zahl 1 zu verwechseln ist .

• Die Datei HandlerRequest.java54 definiert sowohl SC_A_SSL_KEYSIZE als auch SC_A_SSL_KEY_SIZE identisch an weit auseinander liegenden Stellen im Code.

• Namensgleiche Instanzenvariablen innerhalb einer Klassenhierarchie sind stets problematisch und sollten vermieden werden. Findbugs moniert diese zu recht:

MF: Class org.apache.jk.common.JkMX defines field that obscures superclass field org.apache.jk.core.JkHandler.mserverClass defines field that obscures a superclass fieldThis class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other.

Feststellung: Bei der Fehlerbehandlung in Java wird teilweise inkonsistent geloggt: Die verwendeten Loglevel können von Modul zu Modul voneinander abweichen. Wünschenswert wäre ein Logging oberhalb des Level „debug“. Der Level „debug“ sollte im Betrieb nicht eingesetzt werden, auch wenn die Administratoren über Fehler informiert werden müssen. Die meisten Module, mit Ausnahme von catalina/Realm/RealmBase.java, tun dies richtig und loggen auf Ebene „warn“ oder „error“. Folgender Shell-Befehl liefert dazu eine Übersicht:

egrep -n --after-context=2 -e '\bcatch\b' */*.java

Im folgenden Beispiel wäre es vermutlich sinnvoll, den Fehler bei der Namensauflösung nicht bloß auf Level „debug“ zu loggen:

Listing 62: Auszug aus JkCoyoteHandler.java55: // If remoteHost not set by JK, get it's name from it's remoteAddr if( req.remoteHost().isNull()) { try { req.remoteHost().setString(InetAddress.getByName( req.remoteAddr().toString()). getHostName()); } catch(IOException iex) { if(log.isDebugEnabled()) log.debug("Unable to resolve "+req.remoteAddr()); } }

Zusammenfassung: Die Fundstellen sollten umgeschrieben werden, selbst wenn nicht jede sicherheitskritisch ist oder wahrscheinlich gar nicht für einen Angriff ausgenutzt werden kann. Zum Teil handelt es sich um klassische Fehler, wie sie in C Programmen immer wieder vorkommen und Angriffe über Buffer-Overflow ermöglichen. Diese Programmfehler wurden in den Apache Bugtracker56 eingegeben, so dass diese nach und nach von den Entwicklern behoben werden dürften.

54 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java 55 jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java 56 http://bugzilla.apache.org/



5.6.3.1.2 T92 Manuelle Sichtung der Schnittstelle zu JSSE (SSL)JSSE bzw. SSL kommt in Tomcat an zwei Stellen zum Einsatz:

1. als Authentisierungsmöglichkeit (vgl. T6).

2. innerhalb des HTTP-Connectors

Im ersten Fall wird JSSE nur indirekt benutzt. Der Zugriffsschutz wird in der Datei SSLAuthenticator.java57 innerhalb der Komponente Catalina implementiert. SSL kommt darin indirekt zum Einsatz, indem das Zertifikat des Clients angefordert wird (z. B. über das AJP-Protokoll) und der darin angegebene Name zur Prüfung an das für die aktuelle URL konfigurierte Realm übergeben wird.

Der HTTPS-Connector muss dagegen letztendlich SSL einsetzen. In der Datei SSLImplementation.java58 wird JSSE nur dann ausgewählt, wenn das Paket org.apache.tomcat.util.net.puretls.PureTLSImplementation nicht gefunden wird. JSSE wird also nur alternativ benutzt. In JSSEImplementation.java wird anschließend zwischen der JSSE ab dem SDK-1.4 (JSSE14) oder einem älteren JSSE (JSSE13) unterschieden. Letztlich aber spielen alle Dateien im Verzeichnis tomcat/util/net/ und insbesondere tomcat/util/net/jsse zusammen. Dort wird die durch javax.net.ssl standardisiert angebotene Funktionalität angesprochen, um sowohl die Verbindung über einen SSL-Socket aufzubauen, zu verwalten aber auch um daraus die Zertifikatsinformation zu gewinnen.

Die Dateien JSSE14SocketFactory.java und JSSESocketFactory.java setzen die Optionen aus der Konfigurationsdatei server.xml um. Die Prüfung des Codes offenbarte bis auf eine Ausnahme (s. u.) keine Sicherheitsmängel. Es werden aber folgende Abweichungen von der Dokumentation, dem Dokument „SSL Configuration HOW-TO“59, festgestellt:

Feststellung: Es gibt zwei undokumentierte Attribute in den zwei Dateien: „truststoreAlgorithm“ (Default-Wert: wie beim Attribut „algorithm“) für den Zugriff auf den Truststore und „keyAlias“ für den Zugriff auf Keystores.

Beim Abgleich zwischen Code und Dokumentation muss berücksichtigt werden, dass die eine Datei60 einige Abweichungen von der ansonsten 1:1-Übereinstimmung zwischen XML-Attribut in server.xml und dem Code einführt. Darunter sind auch „sslProtocol“ für „protocol“, „clientAuth“ statt „clientauth“ oder „keystorePass“ für „keypass“ zu finden. Dies liegt vermutlich in der Historie begründet.

Die Erkenntnisse aus T45 und T46 veranlassten eine vertiefte Analyse des Umgangs mit den Attributen „ciphers“ und „protocol“:

Festellung: Beim Umgang mit den erlaubten Algorithmen (enabledCiphers) wird zwar zwischen der ungesetzten Option und der leeren Schnittmenge erlaubter (enabled) und möglicher (supported) Algorithmen unterschieden. Leider werden unerkannte Namen von Algorithmen, beispielsweise durch Tippfehler, ohne jegliche Meldung ignoriert. Ist die Schnittmenge leer, wird setEnabledCipherSuites nicht zur Begrenzung aufgerufen. Tomcat verhält sich dann so, als wäre die Option gar nicht angegeben worden.

57 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java 58 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/SSLImplementation.java 59 http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html oder jakarta-tomcat-catalina/webapps/docs/ssl-howto.xml im

Quelltext60 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java





Die Ursache dafür liegt womöglich in der Methode set EnabledCipherSuites61 des JSSE, für die spezifiziert ist, dass der Wert NULL anstelle eines Feldes von Namen nicht angenommen wird. Offen bleibt dabei, ob eine leeres Feld (im Sinne von new String[0]) zur notwendigen Zurückweisung sämtlicher Kommunikation auf dem betroffenen Socket führen wird. U. U. könnte bei leerer Menge auch sofort ein Ausnahmezustand (Exception) erzeugt werden.

Eine andere Erklärung ist denkbar. Die folgenden Funktionen aus zwei getrennten Dateien behandeln den Fall enabledCiphers=null unterschiedlich. Für die erste bedeutet dieser Fall, wie im Kommentar erklärt, dass keine gültige Angabe erkannt wurde. Die zweite Funktion dagegen behandelt den Fall, als wäre keine Angabe vorhanden, dass also keine Einschränkung besteht.

Listing 63: Auszug aus JSSESocketFactory.java zu getEnabledCiphers:

* @return Array of SSL cipher suites to be enabled, or null if none of the * requested ciphers are supported */ protected String[] getEnabledCiphers(String requestedCiphers, String[] supportedCiphers) {

Listing 64: Auszug aus JSSESocketFactory.java zu enabledCiphers:

private void initServerSocket(ServerSocket ssocket) { [...] if (enabledCiphers != null) { socket.setEnabledCipherSuites(enabledCiphers); }

Feststellung: Völlig ähnlich verhält sich der Code in JSSE14SocketFactory62 bei der Verarbeitung der Angaben zu „protocol“ bzw. zu „sslProtocol“. Die Funktion setEnabledProtocols wird nur aufgerufen, wenn sich unter den konfigurierten Protokollen ein unterstütztes Protokoll befindet. Dies wird mit getSupportedProtocols geprüft. Ist die Schnittmenge leer, findet keine Einschränkung statt. Alle unterstützten Protokolle sind dann anwendbar.

Dieses Verhalten betrachten wir als schweren Fehler wider die Erwartungskonformität von Tomcat.

1. Nicht erkannte Protokolle muss Tomcat in Fehlermeldungen aufzeigen.

2. Wird kein einziges gültiges Protokoll erkannt, muss sämtliche Kommunikation abgewiesen werden, oder alternativ Tomcat gar nicht erst starten.

5.6.3.1.3 T93 Manuelle Sichtung der AuthentisierungsmethodenBei der Sichtung der Authentisierungsmethoden wurden keine sicherheitsrelevante Fehler entdeckt. Folgende Abweichungen von der Dokumentation sind dabei jedoch aufgefallen.

61 javax.net.ssl.SSLSocket.setEnabledCipherSuites 62 Datei jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java



Der Tomcat-Container, genannt Catalina, zentralisiert die verfügbaren Authentisierungsmethoden im Paket org.apache.catalina.Realm, das den Dateien des Verzeichnisses catalina/realm/*.java entspricht. Dort liegen die Dateien MemoryRealm.java, JDBCRealm.java, JNDIRealm.java, JAASRealm.java, DataSourceRealm.java, die die gleichnamigen Klassen definieren, sowie einige Zusatzklassen wie die Datei RealmBase.java, die Gemeinsamkeiten dieser Mechanismen durch Vererbung kapselt.

Die Vielfalt der Realms ist verwirrend. Sie bieten laut Dokumentation („Realm Configuration HOW-TO“63 zu Tomcat) folgende Möglichkeiten:

Name DatenquelleMemoryRealm XML-Datei (veraltet?)UserDataBaseRealm XML-Datei als globale Ressource (z. B. tomcat-users.xml)JDBCRealm JDBC-Datenquelle (relationale Datenbank)JNDIRealm LDAP, über JNDIJAASRealm JAAS, darüber wiederum je nach Provider64 als Quelle eine XML-

Datei, X500, Unix-Login, NTLM oder Kerberos DataSourceRealm JDBC-Datenquelle über JNDI

Tabelle 20: Namen der Realm und deren Einsatzmöglichkeiten

Feststellung: UserDataBaseRealm wurde in die Tabelle mit aufgenommen, obwohl es im HOW-TO nicht erwähnt wird, weil es im Quellcode verwendet wird. JAASRealm wird im HOW-TO zwar erwähnt, fehlt aber in der getrennten Datei mit Beispielen zur Konfiguration65.

Das Logging dieser Module wird im HOW-TO so dokumentiert, dass die auszugebende Informationen über die Logkomponente des Containers ausgegeben werden (engl. „Debugging and exception messages logged by a Realm will be recorded by the logging configuration associated with the container for the realm: its surrounding Context, Host, or Engine.“). Auf Ebene des Code wird dies wie folgt erreicht:

Listing 65: Übernehmen der Logkomponente des umgebenden Containers: this.containerLog = container.getLogger();[...] if(! validated ) { if (containerLog.isTraceEnabled()) { containerLog.trace(sm.getString("realmBase.authenticateFailure", username)); } return null; } if (containerLog.isTraceEnabled()) { containerLog.trace(sm.getString("realmBase.authenticateSuccess", username)); }

Feststellung: Der JNDIRealm fasst das Ergebnis der Authentisierung in einem eigenen Log zusammen. Der Container wird dazu nicht benutzt. Die Logmeldungen zu diesem Modul müssen daher anders als die Dokumentation erwarten lässt ab- und zugeschaltet werden.

63 http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html oder lokal http://localhost:8080/tomcat-docs/realm-howto.html oder im Quelltext jakarta-tomcat-5.5.9-src/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/

64 Die aufgeführten Möglichkeiten entsprechen denen des Sun-Providers, vgl. Package com.sun.security.auth im Java-SDK der Firma Sun.

65 Datei webapps/docs/config/realm.xml


http://localhost:8080/tomcat-docs/realm-howto.html

http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html



Feststellung: Die Module MemoryRealm und JAASRealm weichen ebenfalls von der im HOW-TO beschriebenen Vorgabe ab und definieren eine eigene Komponente wie folgt:

Listing 66: eigene Logkomponente in MemoryRealm und JAASRealm: private static Log log = LogFactory.getLog(MemoryRealm.class);[...] if (validated) { if (log.isDebugEnabled()) log.debug(sm.getString("memoryRealm.authenticateSuccess", username)); return (principal); } else { if (log.isDebugEnabled()) log.debug(sm.getString("memoryRealm.authenticateFailure", username)); return (null); };

Feststellung: MemoryRealm loggt den Erfolg oder Misserfolg der Authentisierung lediglich auf Debug-Ebene, d. h. zu niedrig für den normalen Betrieb eines Webservers. Diese Inkonsistenz zu den anderen Verfahren ist nicht weiter kritisch, denn grundsätzlich ist das zentrale Logging anhand einer AccessLogValve vorzuziehen (vgl. T41). Insbesondere lässt sich dann das Format festlegen und somit einfacher der maschinellen Auswertung der Logdateien zuführen als die individuellen Logmeldungen der einzelnen Komponenten.

Positiv aufgefallen ist in JDBCRealm die Verwendung von PreparedStatement. Diese sind nicht anfällig gegen die üblichen Methoden der SQL-Injection, sofern sie in den unteren Schichten tatsächlich implementiert und nicht emuliert werden. Dann werden zur Laufzeit nämlich keine SQL-Abfragen aus Zeichenketten zusammengebaut, sondern grob gesehen Parameter an fertige SQL-Prozeduren übergeben und diese aufgerufen. Wenn PreparedStatement dagegen lediglich emuliert wird, gibt es keine Vorteile, sondern sogar Geschwindigkeitseinbußen gegenüber einfachen SQL-Abfragen. Dies ist uns in einem früheren Projekt mit Microsoft-SQL aufgefallen.


Empfehlungen und Maßnahmen Sicherheitsuntersuchung des ApacheJakarta Tomcat Servlet Containers

6. Empfehlungen und Maßnahmen

Nachfolgend sollen einige Empfehlungen gegeben werden, die zur Erhöhung der Sicherheit beim Betrieb des Jakarta Tomcat Servlet Containers dienen können. Diese ersetzen nicht die grundlegenden Sicherheitsrichtlinien einer IT-Umgebung bzw. das IT-Sicherheitskonzept einer Behörde oder eines Unternehmens. Eine Grundlage für Sicherheitsrichtlinien oder IT-Sicherheitskonzepte sollten immer die Sicherheitsempfehlungen und Maßnahmen des IT-Grundschutzhandbuchs des BSI sein. Die in diesem Kapitel aufgeführten Empfehlungen und Maßnahmen sollen diese spezifizieren und ergänzen.

Hinweis: Die verwendete Reihenfolge gibt keine Information über eine Priorisierung.

6.1 Allgemeine Maßnahmen bzw. Maßnahmen auf Betriebssystemebene

6.1.1 Dateiberechtigungen und -zuordnung

Da die untersuchten Anwendungen (Apache Webserver, Jakarta Tomcat Servlet Container, mod_jk Connector Modul) standardmäßig mit relativ offenen Berechtigungen installiert werden, mit Lese- bzw. Ausführrechten für die Gruppe root und für world, sollte zur Verbesserung der Sicherheit von restriktiveren Berechtigungen Gebrauch gemacht werden, z. B. Entzug der Lese- bzw. Ausführungsberechtigungen für world. Die Einschränkung der Dateiberechtigungen ist insbesondere für die ausführbaren Programme oder Shell-Skripts sowie für die Konfigurationsdateien wichtig, um unbefugte Ausführung von Programmen oder Einsichtnahme in die Konfigurationsinformationen, die möglicherweise auch Passwörter oder andere sensible Informationen enthalten könnten, zu unterbinden.

Weiterhin empfiehlt sich für eine mögliche separate Administration der Anwendungen diese unterschiedlichen Nutzern / Gruppen, z. B. www für den Apache Webserver Administrator und tomcat für den Tomcat Administrator, zuzuordnen. Der Apache Webserver muss wegen der Belegung von privilegierten Ports, HTTP: Port 80 bzw. HTTPS: Port 443 bei Standardbelegung, nach wie vor durch den Nutzer root gestartet werden. Dies kann aber beispielsweise durch den Start der Anwendungen beim Booten des Systems geschehen oder ein Nutzer kann über das sudo Kommando die Rechte eines Administrators erlangen und damit die Berechtigung zum Starten / Anhalten der Apache Applikationen bekommen. Nach der Belegung der privilegierten Ports kann der Apache Webserver, unter Verwendung der Apache USER und GROUP Direktiven, in einen nicht-privilegierten Benutzer-Modus wechseln.

Neben den untersuchten Anwendungen sind gleichfalls restriktive Dateiberechtigungen und -zuordnungen bei den verwendeten Diensten wie LDAP bzw. bei einer Hintergrunddatenbank, die zur Benutzerauthentisierung und -autorisierung verwendet wir, zu setzen. Hier ist sicherzustellen, dass sensitive Informationen wie Passwörter durch Unbefugte weder gelesen noch modifiziert werden können. Zu berücksichtigen sind dabei sowohl die Betriebssystemebene, wo die Dateiberechtigungen entsprechend zu setzen sind, als auch die Dienste selbst, die über Mechanismen zum Schutz sensitiver Informationen verfügen. Dies sind beispielsweise:

• Access-Control Lists (ACLs) in der Konfigurationsdatei /etc/ldap/slapd.conf für eine Zugriffssteuerung innerhalb von OpenLDAP bei der Realisierung einer OpenLDAP-basierten JNDI Realm Authentisierung



Empfehlungen und Maßnahmen

• der SQL GRANT Befehl zur Freigabe von Lese- bzw. ggf. Modifikationsoperationen der Nutzerinformationen in der MySQL-Datenbank bei der Realisierung einer MySQL-basierten JDBC Realm Authentisierung.

Hinweis: Je nachdem welcher Dienst verwendet wird, können auch andere Sicherheitsmechanismen Anwendung finden.

6.1.2 Passworte für die Benutzer / Webanwendung

Zum Schutz vor unberechtigten Zugriffen sollten die üblichen Regeln für die Verwendung von Passworten angewendet werden. Dies betrifft beispielsweise die Charakterisierung der Passworte, wie Mindestlänge, Anforderungen an die zu verwendenden Zeichenklassen, Wechselhäufigkeit, etc., die den in der IT-Umgebung geltenden Richtlinien entsprechen muss. Neben einzelnen Benutzerkonten sind hiervon auch Webanwendungen betroffen, insbesondere auch die Tomcat-Management-Applikationen admin und manager, die, soweit sie auf dem betreffenden System, durch die weit reichenden Konfigurationsmöglichkeiten für andere Webanwendungen besonders zu schützen sind.

Nach Möglichkeit sollten die Passworte einmal durch die betriebssystemspezifischen Schutzmechanismen (Dateizugriffsbeschränkungen) und andererseits durch die Vermeidung der Speicherung im Klartext, d. h. stattdessen die Verwendung von Passwort-Hashwerten geschützt werden, um eine Kenntnisnahme durch Unbefugte zu verhindern. Dies gilt insbesondere für Passworte in Verbindung mit der Benutzung von Datenbanken, z. B. für Webanwendungen oder die Tomcat-Authentisierung, die nur von Programmen (Daemons) selbst, nicht aber von Benutzern verwendet werden und deshalb u. U. keinem regelmäßigen Passwortwechsel unterworfen sind.

Die zu schützenden Benutzer- und Passwortinformationen in Verbindung mit dem Tomcat Servlet Container befinden sich bei Verwendung von Memory Realm Authentisierung in der Datei $CATALINA_HOME/conf/tomcat-users.xml bzw. bei Verwendung von JDBC Realm oder JNDI Realm Authentisierung in einer separaten Datenbank, die für Authentisierungszugriffe durch Tomcat verwendbar, aber vor anderen Benutzern zugriffsgeschützt sein sollten.

6.1.3 Passwort des JAVA Zertifikatspeichers

Zur Überprüfung von Zertifikaten verwendet JAVA und somit auch der in JAVA geschriebene Tomcat Servlet Container den JAVA Zertifikatspeicher, der in der Datei ${JAVA_HOME}/jre/lib/security/cacerts abgelegt ist. Da somit die dort abgelegten Zertifikate66 eine zentrale Rolle bei der Sicherheit besitzen, wird empfohlen, das Standardpasswort changeit des Zertifikatspeichers direkt nach dessen Installation, die im Rahmen der Installation des JAVA SDKs erfolgt, neu zu setzen.

Alternativ können in Tomcat die Zertifikate der die Client-Zertifikate signierenden Certification Authorities (CAs), im Tomcat-Zertifikatspeicher abgelegt werden, der mit den zusätzlichen Optionen truststoreFile und ggf. truststorePass in der <Connector>-Deklaration der Konfigurationsdatei $CATALINA_HOME/conf/server.xml spezifiziert wird. Auch dieser

66 In der JAVA Standard-Installation sind dies im Wesentlichen Root-CA-Zertifikate. Bei der Nutzung von SSL-Client Authentisierung oder Client-Zertifikat-Authentisierung in Verbindung mit dem Apache Webserver oder Tomcat können dies darüber hinaus auch selbst erzeugte oder von einer Certification Authority (CA) signierte Server-Zertifikate sein.



gegebenenfalls verwendete Zertifikatspeicher ist entsprechend durch ein ausreichend sicher gewähltes Passwort gegen unbefugte Manipulationen zu schützen.

6.1.4 Host-basierte Firewall (netfilter / iptables)

Über eine host-basierte Firewall kann eine explizite Freigabe der Kommunikationsports erfolgen, die entweder direkt, z. B. von extern angesprochen werden können oder die der Kommunikation des Apache Webservers mit dem / den Jakarta Tomcat Servlet Containern über das Connector-Modul mod_jk dienen. Auf diese Weise kann der Rechner mit dem darauf laufenden Webserver, dem Servlet-Container und der Webanwendungen gegen Zugriffe mit nicht freigegebenen Protokollen geschützt werden. Insbesondere bei auf mehreren Rechnern verteilten Systemen, z. B. der Apache Webserver auf einem Rechner und der Jakarta Tomcat Servlet Container zur Lastverteilung auf anderen Rechnern, ist auf eine sorgfältige Abbildung der benötigten Kommunikationspfade für die Firewall-Konfiguration zu achten. Nur durch aufmerksame Administration der Firewall werden die für die Anwendungen benötigten, Rechner übergreifenden Kommunikationspfade zwischen den Servern im Netz nicht behindert und dennoch unzulässige Kommunikationspfade wirksam unterbunden.

6.1.5 Gesicherte Kommunikation

Sollen verschiedene Softwarekomponenten, die selbst keine Verschlüsselung zur Erhöhung der Abhörsicherheit und zum Schutz der übertragenen Daten anbieten, miteinander über ein ungeschütztes Netzwerk abgesichert kommunizieren, so kommen zum Schutz der Kommunikation beispielsweise virtuelle private Netzwerk (VPN) Techniken oder Port-Forwarding über verschlüsselte Verbindungen in Frage.

Im Fall von VPNs wird zwischen den beteiligten Hosts bzw. der an der Grenze zum ungesicherten Netzwerken befindlichen Firewall ein verschlüsselter Tunnel aufgebaut. Diese Tunnels können beispielsweise mit Hilfe von IPsec-Verschlüsselung [RFC2401] realisiert werden. Neben einem Schutz des Datenverkehrs vor unbefugtem Abhören durch die Verschlüsselung kann die gegenseitige Authentisierung der beiden an den Tunnelenden befindlichen Hosts auch genutzt werden, um die Berechtigung der Nutzung des aufgebauten Tunnels durch die Kommunikationspartner sicher zu stellen.

Beim Port-Forwarding per Secure Shell (SSH) hingegen wird statt einer direkten Kontaktaufnahme des Clients mit dem Server über ungeschützte Netzwerkbereiche hinweg der Netzwerkverkehr von der Client-Maschine durch einen SSH-Tunnel auf die Server-Maschine an den eigentlichen Server-Port weiter geleitet. Somit wird beispielsweise der Server-Port eines Datenbankservers virtuell auf den Client transferiert und dort für die Anwendung, in diesem Fall Tomcat, nutzbar gemacht. Details zur Installation von SSH basiertem Port-Forwarding finden sich auch [Barret].

Bedeutung hat die Absicherung der Kommunikation insbesondere bei der Übertragung sensibler Informationen wie

• Authentisierungsinformationen, die

• zwischen dem Webserver, mit mod_jk / mod_proxy Modul und Tomcat, mit AJP / HTTP Connector oder




• zwischen Tomcat und einer per JDBC- bzw. JNDI-Schnittstelle angebundene Datenbank,

ausgetauscht werden und

• im Bereich der Webanwendungen bei den zwischen dem Web-Frontend und den Hintergrundapplikationen ausgetauschten Informationen, z. B. Kreditkartennummern, Kennwörter, PINs und TANs, Personen bezogene Daten oder andere schützenswerte Informationen.

6.1.6 Eingeschränkte Laufzeitumgebung (chroot)

Eine weitere Abschottung der Anwendung vom übrigen System kann durch die Verwendung von eingeschränkten Umgebungen erfolgen. Ein Nachteil ist hierbei jedoch der mit der teilweisen mehrfach Installation von Dateien / Anwendungen verbundene Speicher-Mehraufwand, der sowohl auf der Betriebssystemebene der Host-Maschine, als auch innerhalb von chroot-Umgebungen benötigt wird. Ziel der Verwendung einer chroot-Umgebung ist die Separierung der darin laufenden Programme von den übrigen auf der Maschine laufenden Anwendungen durch eine eingeschränkte Umgebung, in der nur die für diese Anwendungen benötigten Softwareprogramme verfügbar sind. Bei einem eventuellen Einbruch auf Grund beispielsweise einer Sicherheitslücke in der Webanwendung, ist es einem erfolgreichen Angreifer so nur innerhalb der beschränkten Umgebung möglich Zugriff auf Programme und Daten zu nehmen.

6.1.7 Nutzung von erweiterten Zugriffsschutzmechanismen unter SELinux

Bei der Nutzung künftiger Debian Linux Varianten mit Unterstützung von SELinux (Security Enhanced Linux) bieten sich Möglichkeiten zur detaillierten Spezifikation von Zugriffs- und Ausführungsberechtigungen einzelner Programme und Anwendungen. Diese ermöglichen es beispielsweise die Zugriffsmöglichkeiten von Web-Diensten auf Dateien oder Programme weit gehend einzuschränken und damit die Sicherheit dieser Dienste zu erhöhen.

Da in der aktuellen Betriebssystemplattform Debian 3.1 Sarge, die auch für die Tests verwendet wurde, noch kein vollständiger SELinux-Support integriert ist, können derzeit noch keine konkreten Vorgaben für einen sicheren Betrieb gemacht werden.

Weiter gehende Informationen zum Themenkomplex SELinux finden sich beispielsweise in [NSA SELinux] bzw. [McCarty] und für die nächste, als unstable gekennzeichnete Debian Linux Version Sid in [Debian SELinux].

6.2 Maßnahmen beim Apache Webserver

Neben den allgemeinen Richtlinien zum sicheren Betrieb des Apache Webservers wie die Ausführung unter einem non-root Benutzer, der Vergabe entsprechend restriktiver Zugriffsberechtigungen, etc., sollten hier spezifische Maßnahmen genutzt werden, die bei der Verbindung des Apache Webservers, ergänzt durch das Connector-Modul mod_jk, mit dem Jakarta Tomcat Servlet Container zum Einsatz kommen können.



6.2.1 Zugriffsberechtigungen

Durch eine restriktive Vergabe der Zugriffsberechtigungen sowohl auf Betriebssystemebene, bei Dateien oder Verzeichnissen, als auch bei den Zugriffsregeln auf die bereitgestellten Web-Ressourcen, die in der Apache Webserver Konfigurationsdatei httpd.conf festgelegt werden, sollte eine unautorisierte Einsicht in die auf dem Webserver befindlichen Dateien / Verzeichnisse verhindert werden. Hiervon sind betroffen:

• Webanwendungen (z. B. Servlets, JSPs, CGI-Programmdateien)

• Konfigurationsdateien der Webanwendungen

• Dateien / Verzeichnisse von Hintergrundapplikationen (z. B. Datenbanken, o. ä.)

Der Apache Webserver bietet die Möglichkeit der Filterung von eintreffenden Anfragen bezüglich der IP-Adresse oder den Host- bzw. Domänennamen, sowie bezüglich der verwendbaren HTTP-Zugriffsmethoden (GET, POST, PUT, DELETE, HEAD, ... per <Limit> Direktive). So können unerwünschte Anfragen heraus gefiltert werden und gelangen gar nicht bis zum Tomcat Servlet Container um dort Schadfunktionen auszulösen.

6.2.2 Watchdog-Funktionalität

Es kommt vor, dass komplexe Anwendung wie Tomcat einfach hängen bleiben, ohne abzustürzen und ohne dass in den Logdateien etwas ersichtlich ist. Dennoch reagiert der Webserver auf keine Anfrage mehr. Aus diesem Grund ist es ratsam, nicht nur mittels ping die Funktionsfähigkeit der Netzwerkkarte des Rechners zu testen, sondern regelmäßig über den Apache bis zum Tomcat einen Zugriff über HTTP(S) auszuführen. Der getestete Bereich ist dann viel größer als bei ping.

Am sinnvollsten paart man dies mit einer Kurzprüfung der Zugangsberechtigungen. Ansonsten kann es recht kompliziert werden, eine gültige Anfrage automatisch an die Webanwendung zu schicken. Ein illegaler Zugriff dagegen testet die Funktionalität von einem wichtigen Teil der Webanwendung und sollte einfach zu automatisieren sein. Um eine möglichst tiefe Testschleife durch das System zu ziehen, sollte der illegale Zugriff idealerweise erst spät abgelehnt werden, also beispielsweise von einem Servlet selbst anstelle eines AccessValve in Tomcat oder im Apache.

6.3 Maßnahmen beim Jakarta Tomcat Servlet Container

6.3.1 Installation unter einem Tomcat Benutzer

Um ein root Login zur Konfiguration von Tomcat und den Webanwendungen zu verhindern, sollten Tomcat, dessen Konfigurationsdateien und ggf. die Webanwendungen unter einem eigenen Linux-Benutzerkonto eingerichtet werden. Zusätzlich sollten die Web-Applikationen unter anderen Benutzerkonten als der Tomcat-Benutzer eingerichtet werden, so sind entsprechende Berechtigungen für den Tomcat-Benutzer auf die Dateien der Webanwendungen einstellbar. Solange nur lesend auf die Dateien zugegriffen werden muss, genügen entsprechende Leseberechtigungen. Müssen von den Servlets lokale Dateien angelegt bzw. modifiziert werden, so sind ggf. entsprechende Schreibberechtigungen vorzusehen.




6.3.2 Shutdown-Port

Zur Vermeidung von Denial-of-Service (DoS) Angriffen sollte auf die Freigabe eines Ports zum Herunterfahren des Jakarta Tomcat Servlet Containers verzichtet werden, da für das Herunterfahren lediglich die Kenntnis der dafür konfigurierten Zeichenkette erforderlich ist und eine weiter gehende Authentisierung zur Feststellung der Berechtigung zum Herunterfahren nicht erfolgt. Zwar ist gemäß der Tomcat Dokumentation das Herunterfahren durch eine Kontaktierung des Ports nur vom lokalen Host, auf dem der Jakarta Tomcat Servlet Container selbst auch läuft, möglich, jedoch kann jeder auf diesem Host eingeloggte Nutzer mit Kenntnis der Shutdown-Zeichenkette das Herunterfahren durch das Kommando telnet localhost 8005 sowie der anschließenden Eingabe dieser Shutdown-Zeichenkette initiieren.

Vielmehr sollte auf die übliche Methode der Verwendung von System-Startup-Skripts (unter /etc/init.d) zurückgegriffen werden, um Tomcat zu starten bzw. zu beenden. Diese Skripts können durch entsprechend berechtigte Nutzer, ggf. über die Verwendung des sudo Kommandos, ausgeführt werden. Somit ist die Nutzung von Shutdown-Port und -String nicht notwendig, um den Tomcat Servlet Container durch berechtigte Benutzer herunter zu fahren.

6.3.3 Logging

Beim Produktiveinsatz des Jakarta Tomcat Servlet Containers ist zu überprüfen, welche Log-Informationen für den Betrieb und zur Fehlersuche tatsächlich benötigt werden, um übermäßigen Ressourcen-Verbrauch hinsichtlich CPU-Leistung oder Speicherplatzbedarf zu vermeiden. Das Logging kann unterschieden werden nach

• dem Logging auf der Ebene der Betriebszustände von Tomcat auf der Stufe der Tomcat-Engine, der virtuellen Hosts, etc.. Hierunter fällt z. B. das Hoch- oder Herunterfahren von Tomcat oder Webanwendungen, die Änderung der Konfiguration oder die Aktualisierung von Webanwendungen oder die Protokollierung von Fehlern zur Laufzeit.

• dem Logging der Zugriffe auf die bereitgestellten Webanwendungen mit Informationen über den anfragenden Webclient, den Benutzer, die angefragte Webanwendungsressource, etc..

Während beim Debugging umfangreiche Log-Informationen zur Fehlersuche und -behebung sinnvoll sein können, sollten im Produktivsystem die debug Attribute auf 0 gesetzt sein und das AccessLogValve nur bei Bedarf eingesetzt werden. Weiterhin ist zu beachten, dass je nach Detaillierungsgrad der Protokollierung u. U. datenschutzrechtlich relevante Informationen gewonnen werden könnten. Insbesondere in Verbindung mit der Protokollierung der Zugriffe, wobei z. B. Benutzernamen oder Cookie-Informationen festgehalten werden können sind datenschutzrechtliche Belange zu beachten. Daraus resultierend sind natürlich die Log-Dateien entsprechend zu behandeln. Maßnahmen für den Zugriffsschutz und Beschränkung der Verwendungs- / Auswertungsmöglichkeit sind dann auf jeden Fall umzusetzen.

Wird das AccessLogValve eingesetzt, so werden wesentliche Informationen über den Zugriff auf Tomcat bereits mit den Log-Pattern pattern=“common“ erfasst, welche sich aus den folgenden Einzel-Log-Pattern kombiniert:

%h: Host, auf dem der Web-Client (z. B. Webbrowser) läuft



%l: Entfernter logischer Benutzername per identd ermittelt (immer „-“)

%u: Authentisierter entfernter Benutzername, ansonsten „-“

%t: Datum und Uhrzeit im Common Log Format

%r: Erste Zeile der HTTP Anfrage (HTTP Methode und URI)

%s: HTTP Status Code

%b: Zahl der zurückgeschickten Bytes (ohne HTTP Header), „-“ für 0 Bytes

Wird das Log-Pattern pattern=“combined“ selektiert, so werden zusätzlich die Werte Referer und User-Agent des HTTP Headers protokolliert, wobei die zum Wert Referer gespeicherten Informationen für den Datenschutz relevante Inhalte umfassen könnte, wie beispielsweise in der URL des vorigen Zugriffs eingebettete Authentisierungsinformationen. Erfolgreiche bzw. fehlgeschlagene Zugriffe werden unterscheidbar durch den HTTP Status Code protokolliert.

Zur Vermeidung von Speicherplatzüberläufen sollten ggf. angelegte Log-Dateien in den üblichen logrotate-Mechanismus einbezogen sowie nach einer gewissen Speicherzeit, üblicherweise in der Größenordnung von Tagen bis Wochen und ggf. nach einer vorherigen Archivierung, von den Systemen gelöscht werden (siehe auch [IT-GSHB]). Datenschutzrechliche Vorgaben müssen hierbei ggf. beachtet werden.

6.3.4 Manager und Admin Webanwendungen

Sofern die manager bzw. admin Webanwendungen zur Administration von Tomcat verwendet werden, sollten diese zur Vermeidung von unerwünschten Zugriffen, die die Gefahr einer Manipulation der Konfiguration bergen, durch eine Filterung der berechtigten Remote-Adressen beim Zugriff auf diese Webanwendungen geschützt werden. Hierzu wird ein RemoteAddrValve in den zu den Applikationen gehörigen Konfigurationsdateien $CATALINA_HOME/conf/Catalina/localhost/manager.xml bzw. $CATALINA_HOME/conf/Catalina/localhost/admin.xml eingefügt:

<Valve className=“org.apache.catalina.valves.RemoteAddrValve“ allow=“127.0.0.1,192.168.*.*“

/>

Hierbei sind unter allow die für den Zugriff zugelassenen Adressen entsprechend anzupassen. Hierin sind durch Kommata getrennte Listeneinträge mit IP-Adressen, ggf. mit Wildcard-Zeichen einzufügen. Die Konfiguration entsprechender URL-Sperrlisten im vorgelagerten Apache-Webserver (Anwendungsszenarien 2 – 6) reichen, falls diese überhaupt aktiviert sind, unter Umständen nicht aus, wenn ein Direktzugriffe über den HTTP(S)-Connector von Tomcat beispielsweise aus dem lokalen Netzwerk heraus möglich ist.

Werden diese beiden Administrationswerkzeuge überhaupt nicht verwendet, so sollten sie aus Sicherheitsgründen nicht installiert sein.




Hinweis: Wird zur Administration der Tomcat-Konfiguration die admin Webanwendung verwendet, so gehen eventuell manuell in die Konfigurationsdateien eingetragene XML-Kommentare verloren.

6.3.5 Zugriffsbeschränkungen

Eine Festlegung von Beschränkungen bezüglich der für Zugriffe auf den Tomcat-Server oder dessen Webanwendungen freigegebenen oder gesperrten Hosts, Web-Domänen oder Subnetze kann in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml vorgenommen werden. Dies geschieht unter Verwendung des RemoteAddrValve, mittels IP-Adressen oder des RemoteHostValve, mithilfe von Host- oder (Sub-)Domänennamen. Bei Nutzung von Wildcard-Characters ist die teilweise von der üblichen Shell-Syntax abweichende Verwendung zu beachten, die von der Nutzung der Jakarta Regexp Bibliothek [Jakarta Regexp] bei der Analyse der IP-Adressen oder Host-Namen herrührt.

Bei der Verwendung von RemoteHostValve ist ein funktionsfähiges Reverse DNS Lookup zur Gewinnung des Hostnamens aus der IP-Adresse des die Anfrage stellenden Webclients zwingend erforderlich, möchte man keine Sicherheits- oder Verfügbarkeitsprobleme riskieren. Ist eine Namensauflösung zur vorliegenden IP-Adresse nicht möglich, so greifen die Default-Regeln:

• bei den deny Regeln: Alle Anfragen außer von den in den deny Regeln genannten Hosts bzw. Domänen werden beantwortet. Dies kann zu einer Beantwortung von Anfragen führen, obwohl der der IP-Adresse zugeordnete Host- oder Domänenname in der deny Regel für einen Zugriff auf die Web-Ressourcen nicht freigegeben ist und birgt somit ein potenzielles Sicherheitsrisiko.

• bei den allow Regeln: Alle Anfragen außer den in den allow Regeln genannten Hosts bzw. Domänen werden abgewiesen. Dies kann zu einer Abweisung von Anfragen führen, obwohl der der IP-Adresse zugeordnete Host- oder Domänenname in der allow Regel freigegeben ist. In diesem Fall wäre der Web-Service für Zugriffe nicht verfügbar.

Für einen sicheren Betrieb sollte also ein lokaler DNS-Server zur Verfügung stehen, um in jedem Fall ein Reverse DNS Lookup zu ermöglichen, der zumindest die Namensauflösung der in den deny oder allow Regeln des RemoteHostValves vorkommenden Host- oder Domänennamen durch ein Caching erlaubt, selbst wenn die im Internet befindlichen DNS-Server temporär nicht erreichbar sein sollten.

In der Konfigurationsdatei WEB-INF/web.xml einer jeden Webanwendung besteht die Möglichkeit zur Anforderung einer Authentisierung beim Zugriff auf einzelne Teile oder die gesamten der Webanwendungen, ggf. auch noch mit Beschränkung der Anforderung der Authentisierung auf die Nutzung einzelner HTTP-Zugriffsmethoden, wie GET, HEAD, PUT, POST oder DELETE mit der <http-method> Direktive. Hierbei ist zu beachten, dass in dem Fall für nicht genannte HTTP-Zugriffsmethoden keine Authentisierung erforderlich ist und diese nicht etwa ganz gesperrt sind.

6.3.6 Tests der Konfiguration

Anwendungen mit vielfältigen Konfigurationseinstellungen wie Apache oder Tomcat bieten erfahrungsgemäß Raum für irrtümliche Fehlkonfigurationen. Zurückgewiesene aber erlaubte Zugriffe befugter Benutzer werden bekanntlich schnell genug geprüft und bei Zurückweisung



gemeldet. Daher ist besonders zu testen, was zurückgewiesen werden soll. Besonders Ausschlussregeln (z. B. zurückzuweisende IP-Adressen oder schwache Verschlüsselungsalgorithmen) sollten dabei getestet werden. Ansonsten wiegt man sich in Scheinsicherheit.

6.3.7 Verschlüsselte Verbindung (SSL)

Zum Schutz der Kommunikation zwischen dem Webbrowser und dem Webserver kann eine Nutzung der SSL-Funktionen des Apache Webservers wie Ent- / Verschlüsselung sowie ggf. Authentisierung bei unverschlüsselter Verbindung Apache Webserver / Connector Modul mit Tomcat auf der lokalen Plattform erfolgen.

Wird Tomcat als Standalone Webserver verwendet (Szenario 1 in [Tomcat Fein.]), so besteht auch hier die Möglichkeit der Verwendung von verschlüsselten Verbindungen mit dessen HTTPS-Connector. Entsprechende Konfigurationen sind in der $CATALINA_HOME/conf/server.xml Datei vorzunehmen. Es sind dies die Bereitstellung eines <Connector>s mit der Deklaration der Attribute

scheme="https"secure="true"sslProtocol="TLS"keystoreFile="conf/.keystore"keystorePass="<passwort>">

sowie die Installation eines Server-Zertifikats zur Identifikation des Tomcat Servers im Webbrowser des Nutzers. Die Installation des, ggf. von einer Certification Authority signierten, Server-Zertifikats in das angegebene keystoreFile erfolgt mit dem Java-Werkzeug keytool.

Wird die SSL-Verbindung zusammen mit CLIENT-CERT Authentisierung verwendet, so ist zusätzlich, damit eine Client-Zertifikatprüfung erfolgen kann, das CA-Zertifikat der für die Signatur der Client-Zertifikate verantwortlichen Certification Authority (CA) einzustellen. Dies erfolgt wiederum mit dem Java-Werkzeug keytool in den

• globalen JAVA-Zertifikatspeicher ($JAVA_HOME/jre/lib/security/cacerts) bzw. in den

• Tomcat-Zertifikatspeicher, der mit den zusätzlichen Optionen truststoreFile und ggf. dem dafür benötigten Passwort unter truststorePass in der <Connector>-Deklaration der Konfigurationsdatei $CATALINA_HOME/conf/server.xml spezifiziert wird.

Weiterhin ist zu berücksichtigen, dass ohne weitere Maßnahmen die Authentisierungsinformationen bei der Nutzung von JDBC Realm- bzw. JNDI Realm-basierter Authentisierung im Klartext übermittelt werden können. Dies kommt zum Tragen:

• bei Verwendung des HTTP-Connectors (Anwendungsszenario 1 aus [Tomcat Fein.]) zwischen Tomcat und der Datenbank bzw. dem LDAP-Server,

• bei Verwendung des AJP-Connectors (Anwendungsszenarien 2 - 6 aus [TomcatFein.]) darüber hinaus auch zwischen Apache / mod_jk und Tomcat,




• wenn zwischen dem Web-Client (Browser) und dem Apache Webserver (bei Nutzung des AJP-Connectors) bzw. dem Jakarta Tomcat Servlet Container (bei direkter Nutzung des HTTP-Connectors) kein HTTPS verwendet wird.

6.3.8 Anbindung einer Datenbank per JDBC

Wird Tomcat zur Authentisierung von Benutzeranfragen per JDBC mit einer Datenbank die die benötigten Informationen wie Benutzernamen, Passworte, Rollenzuordnungen, etc. enthält verbunden, so besteht bei Nutzung eines gültigen in der Datenbank abgelegten Benutzernamens das Problem einer unverschlüsselten Übertragung von Referenzpassworten aus der Datenbank zur Authentisierung in Tomcat. Die Informationen können bei der Übermittlung zwischen Datenbank und Tomcat im Netzwerkverkehr mitgelesen werden, was zum Ausspionieren von Benutzernamen und den zugehörigen Passworten missbraucht werden kann.

Zur Abhilfe sollten die in Abschnitt 6.1.5 gegebenen Hinweise besondere Berücksichtigung finden.

6.3.9 Anbindung einer Datenbank per JNDI

Wird Tomcat zur Authentisierung von Benutzeranfragen per JNDI mit einer LDAP-Datenbank verbunden, so erfolgt die Übertragung des vom Benutzer verwendeten Benutzernamens und des zugehörigen Passwortes an den LDAP-Server zur Durchführung der Authentisierung unverschlüsselt. Diese Informationen können bei der Übermittlung zwischen Tomcat und LDAP-Server im Netzwerkverkehr mitgelesen werden, was zur Erlangung von Benutzernamen und den zugehörigen Passworten missbraucht werden kann.

Auch hier sollten zur Abhilfe die in Abschnitt 6.1.5 gegebenen Hinweise besondere Berücksichtigung finden

6.3.10 Single-Sign-On

In Verbindung mit aktiviertem Single-Sign-On (SSO-Valve) wird, gewissermaßen nach dem Prinzip „eine Rolle – eine Authentisierungsmethode“, zur Erzielung einer möglichst hohen Sicherheit empfohlen, eine Vermischung von unterschiedlichen Authentisierungsmethoden für einzelne Rollen zu vermeiden.

Dies bedeutet, dass beispielsweise auf die für die Rolle roleA freigegebenen Webanwendungen app1 und app2 nicht über BASIC-Authentisierung (app1) und CLIENT-CERT-Authentisierung (app2) zugegriffen werden können soll, da ansonsten das schwächere der beiden Authentisierungsverfahren (BASIC-Authentisierung) für beide Anwendungen genutzt wird. Hierbei würde zuerst eine Anmeldung an app1 per HTTP-Authentisierung und anschließender Wechsel zu app2 erfolgen, die wegen SSO dann ohne weitere Authentisierung ist. Das Sicherheitsniveau der Gesamtanwendung würde somit auf das der schwächsten Authentikation reduziert.


Weitere Punkte / Bugs / Verbesserungsmöglichkeiten Sicherheitsuntersuchung des ApacheJakarta Tomcat Servlet Containers

7. Weitere Punkte / Bugs / Verbesserungsmöglichkeiten

• Spracheinstellungen – Loginformationen: Die Logdaten werden in der vorliegenden Installation (Standard-Spracheinstellung: Deutsch) z. T. gemischt Deutsch und Englisch aufgezeichnet, was evtl. zu Problemen beim Suchen nach Textmustern für die Bewertung der Logeinträge führen könnte.

• Verbesserung der Beschreibung der Tomcat Dokumentation im Hinblick auf die CLIENT-CERT Authentisierung, ggf. aus den hier gewonnenen Ergebnissen. Folgende Fragen sollten dort beantwortet sein: wie müssen die Zertifikate beschaffen sein, wo sind die CA-Zertifikate zur Prüfung der Client-Zertifikate zu installieren, wie erfolgt die Rollenzuordnung zwischen DN (Distinguished Name) im Zertifikat und einer Rolle für den Zugriff auf eine Tomcat-Webanwendung

• Korrektur der Fehler bzgl. der Optionen zu SSL und TLS (s. T44-T46) und Verbesserung der diesbezüglichen Auswahlmöglichkeiten in der Dokumentation.



Abkürzungen

8. Abkürzungen

ACL Access Control ListAJP Apache JServ ProtocolAPI Application Programming InterfaceAPR Apache Portable RuntimeCA Certification AuthorityCD Compact DiscCPU Central Processing UnitDBMS DataBase Management SystemDNS Domain Name ServiceDoS Denial of ServiceDVD Digital Versatile DiscGB Giga ByteHTTP HyperText Transfer ProtocolIPsec Internet Protocol SecurityJAAS Java Authentication and Authorization ServiceJDBC Java Database ConnectivityJNDI Java Naming and Directory InterfaceJSP Java Server PagesJSSE Java Secure Socket ExtensionLDAP Lightweight Directory Access ProtocolLCD Liquid Crystal DisplayMB Mega ByteNAT Network Address TranslationOOP objektorientierte ProgrammierungSCSI Small Computer System InterfaceSDK Software Development KitSGID Set Group Identity SSH Secure ShellSSL Secure Sockets LayerSSO Single Sign OnSQL Structured Query LanguageSUID Set User IdentityTLS Transport Layer SecurityVM Virtual MachineVPN Virtual Private NetworkXML EXtended Markup Language


Wichtige Shell-Variablen, Verzeichnisse und Dateien Sicherheitsuntersuchung des ApacheJakarta Tomcat Servlet Containers

9. Wichtige Shell-Variablen, Verzeichnisse und Dateien

Um eine verbesserte Lesbarkeit bei der Bezeichnung von Dateien und Verzeichnissen zu erhalten, wird im Text eine Notation unter Verwendung von Shell-Variablen benutzt. Hiermit lässt sich außerdem eine bessere Übertragbarkeit der Angaben in andere Systemumgebungen realisieren, die die Softwarepakete an anderer Stelle installiert haben.

Tomcat (Version 5.5.9)$CATALINA_HOME Wurzelverzeichnis der Tomcat-Installation

(Testumgebung: /opt/jakarta-tomcat-5.5.9)$CATALINA_HOME/bin/catalina.sh Tomcat Startscript$CATALINA_HOME/conf/server.xml Tomcat Konfiguration$CATALINA_HOME/conf/tomcat-users.xml Tomcat Benutzerdefinition (Memory Realm)$CATALINA_HOME/logs Tomcat Log-Verzeichnis$CATALINA_HOME/webapps Verzeichnis der Tomcat Webanwendungen$CATALINA_HOME/conf/workers.properties Konfiguration der AJP-Schnittstelle zwischen

Apache und TomcatApache Webserver (Version 2.0.54)$HTTPD_HOME Wurzelverzeichnis der Apache-Installation,

äquivalent zur an manchen Stellen verwendeten Variable $APACHE_INSTALL (Testumgebung: /opt/httpd-2.0.54)

$HTTPD_HOME/bin/apachectl Apache Startscript$HTTPD_HOME/conf/httpd.conf Apache Konfiguration$HTTPD_HOME/conf/ssl.conf SSL-Konfiguration Apache $HTTPD_HOME/conf/workers.properties Konfiguration der AJP-Schnittstelle zwischen

Apache und Tomcat (Soft-Link auf die gleichnamige Konfigurationsdatei in der Tomcat-Installation, s. o.)

JAVA SDK (Version 1.5.0_05)$JAVA_HOME Wurzelverzeichnis der Java-SDK-Installation

(Testumgebung: /opt/jdk1.5.0_05)$JRE_HOME Wurzelverzeichnis der Java-Runtime-

Environment Installation ($JAVA_HOME/jre)$JAVA_HOME/jre/lib/security/cacerts Datei mit den Zertifikaten der Certification

Authorities (CAs)



Referenzen

10. Referenzen

[Barret] Daniel J. Barret, Richard E. Silverman, SSH: The Secure Shell – The Definitive Guide, O'Reilly, 2001

[BSI GSHB] IT-Grundschutzhandbuch, Bundesamt für Sicherheit in der Informationstechnik, 2004, http://www.bsi.bund.de/gshb/index.htm

[Darwin] Ian E. Darwin, Jason Brittain, Tomcat – The Definitive Guide, O-Reilly, Inc., 2003

[Moczar] Lajos Moczar, Tomcat 5 – Einsatz in Unternehmensanwendungen mit JSP und Servlets, Addison Wesley, 2005

[McCarty] Bill McCarty, SELinux – NSA's OpenSource Security Enhanced Linux, O'Reilly, 2004

[Tomcat Fein.] Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers – Feinkonzept, 2005

[Viega] John Viega, Matt Messier, Pravir Chandra, Network Security with OpenSSL, O'Reilly, 2002

10.1 Web-Referenzen (Stand 30.11.2005)

[Apache mod_log] Apache Module mod_log_config Documentation, http://httpd.apache.org/docs/2.0/mod/mod_log_config.html

[Debian SELinux] SELinux for Distributions – Debian Distribution, http://selinux.sourceforge.net/distros/debian.php3

[Jakarta Regexp] Jakarta Regexp 1.4 API, Class RE, http://jakarta.apache.org/regexp/apidocs/org/apache/regexp/RE.html

[NSA SELinux] National Security Agency – Central Security Service, Security-Enhanced Linux, http://www.nsa.gov/selinux/

[RFC2401] IETF, RFC 2401 Security Architecture for the Internet Protocol, ftp://ftp.rfc-editor.org/in-notes/rfc2401.txt, 1998

[RFC2518] IETF, RFC 2518 HTTP Extensions for Distributed Authoring – WEBDAV, ftp://ftp.rfc-editor.org/in-notes/rfc2518.txt, 1999

[Sun JSP] Sun Microsystems, Java Server Pages Specification (Version 2.0), http://java.sun.com/products/jsp/docs.html

[Sun Servlets] Sun Microsystems, Java Servlets Specification (Version 2.4), http://java.sun.com/products/servlet/reference/api/index.html

[ISIS MTT] Core Specification (Version 1.1), http://www.teletrust.de/fileadmin/files/ISIS-MTT_Core_Specification_v1.1.pdf


http://www.teletrust.de/fileadmin/files/ISIS-MTT_Core_Specification_v1.1.pdf

http://www.teletrust.de/fileadmin/files/ISIS-MTT_Core_Specification_v1.1.pdf

http://java.sun.com/products/servlet/reference/api/index.html

http://java.sun.com/products/jsp/docs.html

ftp://ftp.rfc-editor.org/in-notes/rfc2518.txt

ftp://ftp.rfc-editor.org/in-notes/rfc2401.txt

http://www.nsa.gov/selinux/

http://jakarta.apache.org/regexp/apidocs/org/apache/regexp/RE.html

http://selinux.sourceforge.net/distros/debian.php3

http://httpd.apache.org/docs/2.0/mod/mod_log_config.html

http://www.bsi.bund.de/gshb/index.htm

Documents

Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers