Zentraler Intranet-Dienst ist ein Webserver, auf dem alle Dokumente des WWW-Angebots gespeichert sind, und der die Anfragen der Clients (Web-Browser) bedient. Im Laufe dieser Arbeit wurden insgesamt drei Webserver installiert und für den Einsatz im FH-Intranet getestet:
Die beiden ersten genannten sind für den nichtkommerziellen Einsatz
und an Hochschulen kostenlos, der Stronghold-SSL-Server ist kostenpflichtig,
kann aber als 30 Tage Testversion über die Internet-Homepage![[*]](icons/foot_motif.gif){kind=icon}
bezogen werden.
Im folgenden sind die drei Webserver näher beschrieben, dabei wird auf die Installation und die Konfiguration näher eingegangen.
Der Roxen Challenger ist ein Webserver, der seit 1993 von der Lysator Computer Society an der Universität Linköping in Schweden entwickelt wird. Sein Vorteil ist die einfache Installation mit Hilfe des Autoconf-Mechanismus, sowie seine webbasierte Konfiguration, bei der der Administrator sämtliche Einstellungen über Browser treffen und verändern kann. Zudem ist vom Hersteller eine Erweiterung für den Security Socket Layer erhältlich, der bei Bedarf in das Paket einkompiliert werden kann.
Dem gegenüber stehen Probleme bei der Ausführung von CGI-Programmen: im Testverlauf war es nicht möglich, selbsterstellte CGI-Programme, die auf den anderen Webservern einwandfrei liefen, auf dem Challenger ausführen zu lassen. Da aber diese und weitere Programme für das FH-Intranet von großer Bedeutung sind, kommt dieser Server für den Einsatz im FH-Intranet im Moment nicht in Frage. Sollten sich die Probleme beseitigen lassen, ist er wegen seiner benutzerfreundlichen Administration den beiden anderen in jedem Fall vorzuziehen. Im Großen und Ganzen ist zu den Standard-Servern, wie dem CERN httpd und dem Apache, kompatibel und diesen in weiten Bereichen überlegen.
Die Sourcen des Challenger finden sich im Internet über die Homepage der Herstellerfirma. Ihre Adresse lautet:
| http://www.roxen.com/shop/dist/ |
Es sind sowohl eine Sourcecode-Distribution als auch Binary-Versionen
für verschiedene Unix-Systeme verfügbar. Für den Test wurde die Binary-Distribution
für das Sun-Betriebssystem ausgewählt (Datei Roxen_1.1_sparc_sun_sunos5.5.tar.gz
aus dem Unterverzeichnis binaries/Roxen_1.1/).
Das Paket wird mit folgendem Befehl entpackt :
| tar xfz Roxen_1.1_sparc_sun_sunos5.5.tar.gz . |
Daraufhin wird eine Verzeichnisstruktur erzeugt, die im Unterverzeichnis roxen/ abgelegt ist, in das am besten gewechselt wird. Auf der Testumgebung ist das Installationsverzeichnis im Dateibaum unter
| /usr/local/www/roxen |
angelegt. Der Installationsvorgang wird durch den Aufruf eines Scripts fortgesetzt, das mit dem Befehl
| server/install |
gestartet wird. Mit diesem Programm werden einige grundlegende Angaben
abgefragt, die in Tabelle 3.1 mit ihren Eintragungen dargestellt sind.
Soll der Roxen Challenger nun bei jedem Bootvorgang mitgestartet werden, so ist folgender Eintrag in die Startdateien einzutragen:
| cd /usr/local/www/roxen;./start |
Aus Sicherheitsgründen ist zu empfehlen, Dateibesitzer und Gruppenzugehörigkeit aller zum Server gehörigen Dateien auf einen bestimmten System-User umzustellen. Im Allgemeinen wird bei den Webservern vorgeschlagen, hierfür den User nobody in der Gruppe nogroup zu verwenden. Da einige Hackertools diesen Umstand als Schwachstelle erkennen und dadurch das System unterwandern können, ist in der Testumgebung User und Gruppe mit folgendem Befehl gesetzt worden:
| chown -R bin:bin roxen/ |
Bevor der Roxen nun für den laufenden Betrieb konfiguriert wird, können
die speziellen SSL-Komponenten installiert werden. Diese können ebenfalls über die oben genannte
Quelle (Datei SSLeay/SSLeay-0.6.4.tar.gz)
bezogen werden. Der Entpackvorgang wird ebenfalls wie oben beschrieben
durchgeführt, und in das erzeugte Unterverzeichnis gewechselt. Für
den Installationsvorgang sind folgende Befehle auszuführen:
make -f makefile.ssl links
./configure solaris-sparc-gcc
make -f makefile.ssl clean
make -f makefile.ssl depend
make -f makefile.ssl
make -f makefile.ssl rehash
make -f makefile.ssl test
make -f makefile.ssl install
Anschließend wird das SSL-Paket im Roxen Challenger (nur in der Sourcecode-Distribution möglich !) integriert mit den Befehlen:
cd extern && make ssl
Anschließend wird das entstandene Binary ssl in das Verzeichnis der ausführbaren Dateien des Challenger kopiert :
Als ersten Schritt beschreibt das Manual (siehe [7]) die Konfiguration des Configuration Interfaces. Beim ersten Kontakt mit dieser Schnittstelle ist für den Administrator ein Benutzername und ein Paßwort (zweimal) anzugeben. Für das Intranet wurde hier der User name cmetten mit dem Paßwort mchristoph eingetragen. Eine Änderung dier Einstellungen ist möglich.
Der erste Schritt der Konfiguration ist die Installation eines Virtual Server. Für das FH-Intranet wurden folgende Einstellungen getroffen:
| Interface Name: | Intranet |
| Domain: | fh-regensburg.de |
| Listen Port: | 80, http, ANY |
| IP-Number: | * |
| Server URL: | http://INTERN.fh-regensburg.de |
Da der Challenger mehrere virtuelle Server unterstützen kann, dient der Name einer leichteren Unterscheidung. Der Domainname, der Listen Port und der Server-URL dienen zur Unterscheidung der virtuellen Server, wenn eine Anfrage von einem Client an den Server gestellt wird. Über die IP-Number wird der Zugriff auf den Server reglementiert, also welche Clients Anfragen stellen dürfen.
Als nächster Schritt muß der neue virtuelle Server ein Filesystem erhalten. Dies ist ein Modul für den Challenger, in dem angegeben ist, wo sich die Web-Dokumente befinden und wie sie als URL anzugeben sind. Grundeinstellung ist hier folgende:
| Module Name: | Intranet FS |
| Security Patterns: | allow ip=194.95.104.* |
| allow ip=194.95.104.* | |
| allow ip=194.95.104.* | |
| allow ip=194.95.104.* | |
| allow ip=194.95.104.* | |
| allow ip=194.95.104.* | |
| Mount Point: | / |
| Search Path: | /usr/local/www/daten |
Der Name dient wieder der Unterscheidung: ein virtueller Server kann verschiedene Dateisysteme nutzen, die beispielsweise über mehrere Festplatten oder sogar Computersysteme verteilt sind. Die Security Patterns reglementieren die Zugriffsberechtigungen für Client-Anfragen, ein Ausschluß von Systemen für bestimmte Dateisysteme ist möglich. Der Mount Point ist die Verzeichnisangabe, unter der das Dateisystem in der URL anzugeben ist, der Search Path ist schließlich die physikalische Verzeichnisangabe, in der sich die Daten befinden.
Mit den beschriebenen Eingaben ist der Roxen Challenger lauffähig.
Zur Optimierung des Systems stehen weitere Module zur Verfügung, die
bei Bedarf in das System, also den virtuellen Server integriert werden
können. Der installierte Server, der für das FH-Intranet verwendet
wurde enthält die Module, die in Tabelle 3.2
Für die Benutzung im Rahmen eines Intranets sind die Module .htacces Support, CGI Executeable Support und Security Access wichtig. Die übrigen sind als Standardmodule nicht weiter von Bedeutung, auf die aktuellen Einstellungen wird hier nicht näher eingegangen.
In Bezug auf Systemsicherheit ist es abzuwägen, ob Benutzer-Homepages zugelassen werden und ob diese eigene CGI-Skripten erstellen und starten dürfen, da dies einen Angriffspunkt für Hacker darstellt. Im Allgemeinen kann der Intranet-Betrieb ohne Benutzer auf der jeweiligen Maschine stattfinden. Somit sind Benutzer-Homepages zu unterbinden, wodurch auch Skripten nicht möglich sind.
Über die beschriebenen Module hinaus bietet Roxen noch eine ganze
Reihe zusätzlicher Erweiterungen, mit denen zusätzliche Optionen unterstützt
werden. Im Internet ist hierzu auch gute Dokumentation zu erhalten. Da der Challenger für den Einsatz im Intranet sich wegen der genannten
Probleme als nicht geeignet erwiesen hat, wird der Betrieb und die
Konfiguration auch nicht näher beschrieben.
Der zweite Webserver, der getestet wurde, ist der im Moment wohl weltweit
am meisten verbreitete. Er entstand 1995 auf Basis des damaligen Standard-http-Daemons
NCSA an der University of Illinois, wo dieser über einen längeren Zeitraum
nicht weiterentwickelt wurde. Aus den eigenen Erweiterungen und Patches
mehrerer Webmaster entstand daraus das
Apache Project.
Die Vorteile dieses Server-Programms sind sicherlich in
der weiten Verbreitung, der einfachen Beschaffung per Internet und
der simplen Installation und Konfiguration zu sehen, aber auch in
der Philosophie, daß ein derartiges Programm für jedermann frei erhältlich
sein soll.
Die Sourcen für den Apache Daemon sind im Internet über einen der
Webserver der Apache Group erhältlich, sowie in zahlreichen Mirrors und ftp-Sites. Das so erhältliche
Dateiarchiv kann mit den Befehlen
| tar xfz apache_1.2.3.tar.gz |
entpackt werden. Hierdurch entsteht ein Verzeichnisbaum mit dem benötigten Sourcecode in einem Unterverzeichnis src/ , in das gewechselt werden muß.
Zu Beginn der Installation ist eine Konfigurationsdatei zu erstellen. Hierzu wird ein mitgliefertes Template mit dem Befehl
| cp Configuration.tmpl Configuration |
kopiert, das dann zu editieren ist. In diesem File werden Optionen
für den Übersetzungsvorgang, sowie alle gewünschten Module angegeben.
Tabelle 3.3
Mit dem Befehl
| ./Configure |
wird das Makefile für die Hardware-Plattform vorbereitet, das für den Compilationsvorgang zuständig ist. Das Binary des Daemons wird mit dem Befehl
| make |
erzeugt und kann dann in ein dafür vorgesehenes Verzeichnis kopiert werden:
| cp httpd /www/apache-1.2.3/bin |
Der Apache Webserver wird mit Hilfe von drei Textdateien konfiguriert. Dies ist zum einen die Datei httpd.conf (Allgemeine Einstellungen), srm.conf (Dokumentenbasis) und access.conf (Zugriffssteuerung). Für nähere Informationen sei an die entsprechende Konfigurationsdatei und an die Online-Dokumentation verwiesen. Beschrieben werden hier nur diejenigen Parameter, die von der Vorgabe abweichen.
Zum Start des Apache Webservers ist der Befehl
| /www/apache-1.2.3/bin/httpd -f |
| /www/apache-1.2.3/conf/httpd.conf |
einzugeben. Sollte der Daemon neu gestartet werden müssen, z.B. nach Änderung eines Parameters, so geschieht dies mit dem Befehl
| kill -HUP `cat /www/apache-1.2.3/logs/httpd.pid` . |
Der dritte Webserver, der im Rahmen dieser Arbeit getestet wurde, ist ein kommerzielles Produkt. Zu Evaluationszwecken ist dieser Server allerdings in einer 30 Tage Test Version erhältlich. Gegenüber den anderen beiden Systemen bietet Stronghold die Möglichkeit einer verschlüsselten Datenübertragung im Internet. Gerade wegen des steigenden Sicherheitsbedürfnisses, auf das in Firmen großer Wert gelegt wird, empfiehlt sich für ein Intranet der Einsatz von Kryptologie, besonders, wenn das Firmennetzwerk eine größere geographische Ausdehnung besitzt.
Die Firma UK Web Security Solutions hat sich mit mehreren ausländischen Partnern auf den Vertrieb von Programmen mit Sicherheitsmechanismen im Inernet spezialisiert. In diesem Zusammenhang steht auch der Stronghold Secure Server 2.0, der auf dem Sourcecode des Apache Webserver basiert, und um die Funktionalität des Secure Socket Layer (SSL) erweitert wurde. Daneben ist die einfache Installation und Konfiguration als besonderer Vorteil anzusehen.
Um eine Evaluation Copy des Stronghold zu erhalten, ist zunächst ein Online-Formular auszufüllen, in dem Angaben über Person und Firma zu machen sind. Daraufhin erhält man per eMail einen 8-stelligen Lizenz Key, sowie eine Benutzerkennung und ein Paßwort, mit deren Hilfe man über die Homepage des Hersteller den Server beziehen kann. Für den Test wurde auf diesem Weg die Version 2.0.1 für das Sun Solaris Betriebssystem, Version 2.5 geladen. Der Entpackvorgang wird mit Hilfe des Befehls
| tar xvfz stronghold-2.0.1-sparc-sun-solaris2.5.tar.gz |
durchgeführt. In dem Dateibaum ist ein Installationsprogramm INSTALL.sh enthalten, das die benötigten Informationen vom Benutzer abfragt. Tabelle 3.4
zeigt die entsprechenden Angaben.
Zum Betrieb des Secure Servers werden zwei Umgebungsvariablen benötigt:
| SSLTOP | /www/stronghold/ssl |
| PATH | $SSLTOP/bin:$PATH |
Für die gesicherte Übertragung von Daten zwischen einem Client und dem Stronghold muß das Schlüsselpaar, also privater und öffentlicher Schlüssel zunächst zertifiziert werden. Im Installationsskript ist hierfür die Option Generate a new key zu wählen. Im Verzeichnis /www/stronghold/ssl wird nun eine Datei
| INTERN.fh-regensburg.de.key |
erzeugt, in der der öffentliche Schlüssel gespeichert ist. Daraufhin
ist die Schlüsselgröße einzugeben, was mit der Länge von 768
bits beantwortet wurde. Nun ist man aufgefordert, zufällig
Tasten auf der Tastatur zu drücken. Aus dem zeitlichen Abstand zwischen
den Anschlägen werden die Zufallszahlen für die Schlüsselgenerierung
erzeugt. Im Anschluß daran muß man noch einige Fragen beantworten,
die in Tabelle 3.5
beschrieben sind.
Durch die Codeverwandschaft zum Apache Server empfiehlt es sich, die Eintragungen der Konfigurationsdateien zu verwenden, wie sie in Kapitel 3.2.3 beschrieben sind. Eine Besonderheit ist hierbei, daß die Konfiguration nicht auf drei Dateien verteilt ist, sondern daß sie gesamt in der Datei httpd.conf enthalten ist.
Neben diesen Einträgen existiert eine Datei swish.conf , die es in dieser Form bei Apache nicht gibt. Diese Einträge lauten:
Somit ist der Stronghold konfiguriert.
Der Stronghold Secure Server kennt vier Betriebsmodi:
Im normalen Betrieb unterscheidet sich der Stronghold nicht von einem gewöhnlichen Webserver. Bei der sicheren Verbindung erscheint zunächst ein Hinweis, daß man sich jetzt in einem Bereich befindet, der die Daten verschlüsselt überträgt.
Der Stronghold Configuration Manager ist ein Web-basiertes Konfigurationstool, das dem des Roxen Challenger in gewisser Weise ähnelt. Hier können sowohl globale Servereinstellungen verändert werden, als auch einzelne Module ein- und abgeschaltet werden. Als besonderes Feature sei hier die Möglichkeit genannt, die Einstellungen auf Diskette oder in Datei zu sichern. Somit kann die Einstellung vor einer Manipulation gesichert, bzw. auf einen anderes Computersystem übertragen werden.
Die Verwendung des Direct Interface ist leider im Verlauf des Tests nicht klar geworden. Einzig auffällig war, daß trotz Eingabe des angegebenen Paßwortes keine Reaktion des Webservers erfolgte. Die Vorzüge dieses Ports werden unter Umständen ersichtlich, wenn man sich intensiver mit dem Programmpaket und seiner Dokumentation beschäftigt.
In Anbetracht des gesteigerten Sicherheitsbedürfnisses, das mit der schnell wachsenden Verbreitung des Internets entsteht, ist der Einsatz eines SSL-Servers für ein Intranet in jedem Fall zu empfehlen. Da innerhalb von Unternehmen, aber auch der Fachhochschule, Informationen ausgetauscht werden, die der Geheimhaltung oder dem Datenschutz unterliegen, kann man so die Gefahr verringern, der man seine sensitiven Daten aussetzt. Trotz des Preises von etwa 1000 US-Dollar kann man argumentieren, daß dies ein kleiner Preis ist, wenn man bedenkt, daß die Schäden durch Datendiebstahl in einem Firmennetz um ein Vielfaches höher sind.
Es bleibt abzuwarten, in wie weit Kryptologie bei der Datenkommunikation juristisch eingeordnet wird. Im Augenblick ist ihr Einsatz in der Bundesrepublik Deutschland ohnehin nicht oder nur eingeschränkt zulässig.