Konfiguration von Zope, Apache als Chaching Proxy und sicherem Login

Ich m�chte ein Zope mit einem Apache davor der cached und ich m�chte das das einloggen der User �ber SSL gezwungen wird damit keine Passw�rter im Klartext �ber das Netz gehen.

Konfiguration von Zope, Apache als Chaching Proxy, sicheres Login und PAM Anbindung

Software: Zope 2.6.1, Apache 1.3.27
Letzte �nderung: 29.04.03
Status: Getestet, noch nicht produktiv

Anforderungen:
+ Caching Apache in front
+ Mehrere virtuelle Hosts auf einer Maschine mit einer IP
+ Login per SSL
- Cachen mit unterschiedlichen Einstellungen je nach Objektart



Am Anfang des Setup des Zope-Systems hier beim DESY waren ein paar grundlegende technische Dinge zu kl�ren. Wie setze ich einen Apache als "caching proxy" vor das Zope und wie schaffe ich es das ein Login in das System _immer_ �ber eine verschl�sselte Kommunikation l�uft.

Zuerst m�ssen Zope und Apache-SSL installiert werden. Das ist anderswo besser dokumentiert als ich es k�nnte, deshalb gehe ich nicht weiter darauf ein ;)

Da Zope und Apache zum testen auf einer Maschine installiert werden m�ssen die TCP-Ports entsprechend eingestellt werden.
Apache lauscht auf den Standard HTTP-Port 80 und Zope wird auf 8080 gestellt. Dazu muss die Zeile

# Port for HTTP Server. The standard port for HTTP services is 80.
HTTP_PORT=8080

in der Datei z2.py eingetragen werden.

In der httpd.conf muss etwas mehr ge�ndert werden...
Die Standardeinstellungen f�r den "Main Server" k�nnen beibehalten werden, er wird nur noch vom localhost erreichbar sein. Alles andere wird �ber virtuelle Server gehandhabt.

Mit "Listen 80" und "Port 80" lauscht Apache auf den Standardport

Diese Zeilen sorgen einfach daf�r das die ben�tigten Module geladen werden und zur Verf�gung stehen.

LoadModule rewrite_module libexec/mod_rewrite.so
LoadModule proxy_module libexec/libproxy.so
LoadModule ssl_module libexec/libssl.so
...
AddModule mod_rewrite.c
AddModule mod_proxy.c
AddModule mod_ssl.c


Folgend ist der komplette Abschnitt f�r die Konfig des Proxy von Apache.
Doku zu den einzelnen Zeilen ist SEHR n�tzlich und findet sich unter http://httpd.apache.org/docs/mod/mod_proxy.html


ProxyRequests Off
# Nicht verwirren lassen, wir benutzen den Proxy explizit in der Weiterleitung
# Aus Sicherheitsgr�nden (wichtig!) wird die globale Proxyfunktion ausgeschaltet

ProxyVia On
# Bringt zwar nicht viel mit "ProxyRequests Off" aber der Vollst�ndigkeit halber

CacheRoot "/MEINVERZEICHNIS.../apache/proxy"
CacheSize 1000
CacheGcInterval 1
CacheMaxExpire 24
CacheLastModifiedFactor 0.1
CacheDefaultExpire 1
CacheForceCompletion 100 # Ist wichtig um das "halbe Bilder cachen" Symptom zu vermeiden
ProxyReceiveBufferSize 0
ProxyDomain .MEINEDOMAIN.de # Der vollst�ndigkeit halber



Jetzt kommt das Herzst�ck, die Konfiguration der virtuellen Hosts.
Zuerst kommt in die generelle Konfiguration auf welche IP/Port Kombinationen der Server reagieren soll.
(Angenommen 123.123.321.321 ist die IP der Maschine)

#
# Use name-based virtual hosting.
#
NameVirtualHost 123.123.321.321:80
NameVirtualHost 123.123.321.321:443


Auch der eigentliche Eintrag f�r einen virtuellen Host ist ziemlich einfach.
Angenommen der Name www.bloe.de ist so eingerichtet das der DNS auf die IP 123.123.321.312 zeigt (Wie passend ;)


ServerName www.bloe.de
ServerAlias bloe.de
ServerAdmin
RewriteEngine on
RewriteRule ^(.*) http://123.123.321.321:8080/VirtualHostBase/http/www.bloe.de:80/www_bloe_de/VirtualHostRoot$1 [P,L]


Wenn ein weiterer Server (www.foo.com) eingerichtet wird, einfach den Abschnitt oben wiederholen und "bloe.de" durch "foo.com" ersetzen.

Des Pudels Kern ist die RewriteRule: Mit der Regel werden alle (^(.*)) Anfragen zu Zope (8080) umgleitet und gleichzeitig werden die VirtualHostBase und das VirtualHostRoot f�r das VirtualHostMonster (s.u.) in Zope umgeschrieben.
WICHTIG ist das korrekte �bernehmen der "/" in der RewriteRule! Es gibt Anleitungen die Kombinationen verwenden die scheinbar funktionieren aber sp�ter mit z.B. dem ZMI Probleme machen. Diese hier funktioniert und macht nicht den ber�chtigten "//"-Fehler.

Tip vom Sicherheitsfanatiker: Gut ist auch Zope so konfigurieren das es nur auf Anfragen von "localhost" reagiert und dann (nur!) in der RewriteRule 123.123.321.321 durch "localhost" zu ersetzen.

Kommen wir jetzt zur Einrichtung des VirtualHostMonster in Zope. Einfach im Root von Zope ein Objekt vom Typ "Virtual Host Monster" erstellen. Voila! *staun* Ok, ok, es ist noch nicht ganz alles ;)
Im Zope-Root muss dann noch ein Folder f�r jede einzelne Website erstellt werden, entsprechend dem Eintrag in der RewriteRule in Apache. In unserem Falle w�rde der Folder "www_bloe_de" hei�en. Da liegen dann die Objekte/Seiten f�r die Website drin.


Die Apache-Konfiguration f�r die SSL-Verbindung ist auch einfach nur ein weiterer virtueller Host.


ServerName www.bloe.de
ServerAlias bloe.de
ServerAdmin
SSLEngine on
... # Hier folgt das ganze SSL-Geraffel. Ist hier nicht Thema, am besten unter apache.org schauen
RewriteEngine on
RewriteRule ^(.*) http://123.123.321.321:8080/VirtualHostBase/https/www.bloe.de:443/www.bloe.de/VirtualHostRoot$1 [P,L]



Anders ist hier nur das "https" und das ":443", was einfach daf�r sorgt, das eine sichere Verbindung bestehen bleibt wenn sie einmal angelinkt wurde.


Jetzt bleibt nur noch den Einlog-Vorgang �ber SSL zu zwingen, damit keine Passw�rter im Klartext �ber das Netz fliegen.
Dazu brauchen wir zwei Produkte, den "Cookie Crumbler" und "SSLAbsoluteURL" (Mu� installiert werden).
Im Root ein Objekt des Typs Cookie Crumbler und die DTML-Dokumente "logged_in", "logged_out" und "login_form" erstellen (die DTML-Dokumente gibt's auf www.zope.org).
Ab jetzt wird jeder Login nicht mehr �ber das PopUp-Fenster des Browsers gemacht, sondern es gibt ein sch�nes, anpassbares HTML-Formular das aufgerufen wird.

Das Objekt "login_form" bekommt eine Property, Name "SSL", Typ "Boolean", Wert "An". Damit und dem Produkt "SSLAbsoluteURL" werden Aufrufe von "login_form" �ber SSL gezwungen.

Eine Anpassung mu� aber in der login_form noch gemacht werden:

action_url="came_from or 'logged_in'">

Es wird nur die "form action" hart auf das DTML-Dokument "logged_in" gelinkt.

Warum? Das Formular springt sonst direkt dahin wo der User hergekommen ist. Das ist aber wahrscheinlich noch keine SSL-�bertragung gewesen! Das hei�t, der User tippt ihr Passwort auf einer Seite ein die �ber SSL �bertragen wurde aber wenn sie das Formular abschickt w�rde die Verbindung doch wieder �ber eine unsichere Verbindung laufen und Schmidtchen Schleicher k�nnte mith�ren...

Wenn allerdings auf "logged_in" verlinkt wird, wird das Passwort noch �ber eine sichere Verbindung �bertragen. "logged_in" springt dann seinerseits direkt weiter auf die Seite wo der User herkam. Also f�r den User ist alles fein und f�r uns ist alles sicher.

Tip vom Sicherheitsfanatiker: Wir haben jetzt nur verhindert das Passw�rter im Klartext �ber das Netz flitzen. Allerdings k�nnte immer noch jemand sp�ter die Session-Variablen des Users mitlauschen und die Session evtl. "entf�hren". Das ist recht unwahrscheinlich _aber_ m�glich. Um eine Raketensteuerung zu betreiben w�rde dann nur helfen _alles_ �ber SSL laufen zu lassen (was jedoch wiederum Performance des Webservers kostet).

Noch ein wichtiges Wort zum Caching. Es ist zwar jetzt ein funktionierender "caching reverse proxy" vor unserem Zope aber was wird denn gecached?
Es gibt eine Reihe von HTTP Headern die das Verhalten von zwischengeschalteten Caches (der Apache, der Cache des Browsers, etc.) steuern.
Objekte vom Typ "image" haben automatisch einen Satz Header der caching erlaubt, andere Objekttypen leider nicht.

Das hat seinen Zweck, denn Caching hat auch Nachteile. In der Zeit in der der Cache die Anfragen beantwortet wird eine dynamische Seite (zum Beispiel ein Newsscript) nicht ausgef�hrt und somit auch nicht ge-updated!
Bei einem hochdynamischen System wie Zope ist es also sehr wichtig sich gut zu �berlegen was, wann, wie lange gecached werden darf.
ACHTUNG: Der "Accellerated HTTP Cache Manager" ist zwar genau f�r diesen Zweck da hat aber einen Glitch, so dass die Header nicht ordentlich geschrieben werden und das Objekt dann doch nicht gecached wird (Stand 29.4.03). Mann! Hab ich Ewigkeiten gesucht bis ich _das_ gefunden hab!

Im Moment ist die L�sung die Header f�r jedes Objekt das gecached werden soll selbst zu schreiben. In DTML w�rde das so aussehen:




Ich denke aber das der AHCM demn�chst gefixed wird und mir schweb auch noch eine Erweiterung vor mit der es m�glich ist den unterschiedlichen Objekttypen automatisch unterschiedliche Cache-Zeiten zuzuordnen.

Ich denke ich kann dieses Dokument �ber die Zeit noch deutlich verbessern und erweitern. Wie gesagt am Caching wird noch gearbeitet, eine Userauthentifizierung durch PAM und Lastverteilung mit ZEO kommen sicher auch noch dazu.

Vielleicht hilft meine Beschreibung ja der Einen oder dem Anderen weiter.
�ber Feedback und Verbesserungsvorschl�ge bin ich immer dankbar :)

/Carsten

--
Carsten Germer, Weboffice Tel.:
DESY Email:
Notkestr. 85 WWW: http://www.desy.de/
D-22607 Hamburg http://www.germer.org/