zurück zum Artikel

HTTP ist das Universalprotokoll des Internet; von fast jedem Betriebssystem aus kann man damit lesend auf Webserver zugreifen, selbst von PDAs und Handys.

WebDAV erweitert das Netzwerkprotokoll HTTP/1.1 um den schreibenden Zugriff auf Webressourcen. Es definiert dabei unter anderem neue HTTP-Methoden und -Header. Man kann sogar sagen, dass es sich bei WebDAV um ein flexibles und interoperables Internet-Dateisystem handelt, welches alle Vorteile von HTTP bietet, darunter Proxy-Support, Caching, Verschlüsselung, gute Performance in High-Latency-Umgebungen, Nutzung der vorhandenen Netzinfrastruktur und einfacher Durchgang durch Firewalls.

Wie man den mit Windows 2000 und XP gelieferten abgespeckten Internet Information Server (IIS) für WebDAV-Freigaben konfiguriert, haben wir im Artikel "Internet-Festplatte" [1] erklärt. Weitgehend betriebssystemunabhängig bietet auch der Open-Source-Webserver Apache [2] dieses Feature. Er entspricht mit dem optionalen Modul mod_dav den WebDAV-Klassen 1 und 2; dazu gehören die Dateioperationen Anlegen, Verschieben, Kopieren, Löschen und Auflisten.

Hier zeigen wir, wie die Konfiguration unter Linux aussieht. Mit minimalem Aufwand lässt sie sich auch auf die anderen Betriebssysteme übertragen, unter denen Apache läuft. Wir gehen von der aktuellen Apache-Version 2.0 aus, doch die hier beschriebenen Funktionen gibt es so auch für die immer noch weit verbreitete Vorgängerversion 1.3.

Die WebDAV-Einrichtung besteht aus fünf Schritten: Aktivieren der Module, Anlegen einer Lock-Datenbank, Freigeben von Verzeichnissen, Anlegen der Benutzerverwaltung und schließlich Sichern des Ganzen per SSL.

Modulation

Seit der Version 2.0 gehört WebDAV mit den Modulen mod_dav und mod_dav_fs zum Lieferumfang von Apache. Die gängigen Linux-Distributionen wie Suse [3] und Red Hat [4] enthalten sie in vorkompilierter Form. Die Installation ist mit den jeweiligen Tools wie Yast2 in wenigen Klicks erledigt. Bei der Gelegenheit spielt man auch das OpenSSL [5]-Paket ein, das später zum Erzeugen des SSL-Zertifikats erforderlich ist.

Bei den beiden Apache2-Modulen handelt es sich um eine Weiterentwicklung des alten, aber stabilen Moduls mod_dav für Apache 1.3, welches auf dem Stand November 2001 eingefroren wurde. Bei den Distributionen wie Debian stable [6], die noch den alten Apache enthalten, muss man dieses Modul in der Regel als getrenntes Paket installieren. Es unterscheidet sich in der Konfiguration kaum von der neuen Version, nur gibt es noch kein separates mod_dav_fs.

Die gesamte Apache-Konfiguration findet sich unterhalb des Verzeichnisses /etc/apache2/. Die wesentlichen Einstellungen stehen in der Datei httpd.conf. Damit Apache WebDAV-Kommandos versteht, muss er das Modul mod_dav [7] geladen haben, das seinerseits den Filesystemprovider mod_dav_fs benötigt. Das erledigen die Direktiven "LoadModule dav_module mod_dav.so" und "LoadModule dav_fs_module mod_dav_fs.so" (siehe Listing). In den meisten Distributionen stehen diese Zeilen bereits auskommentiert in der httpd.conf; dann reicht es, das Kommentarzeichen (#) vor der Zeile zu entfernen.

Damit gleichzeitige Zugriffe mehrerer Anwender auf dieselben Dateien nicht zu Datenverlust führen, muss sich Apache Sperren auf Dateien merken (Locks). Dazu dient eine Lock-Datenbank, die das Modul mod_dav_fs automatisch anlegt und verwaltet. Hierfür gibt der Administrator über die Direktive DavLockDB nur das Verzeichnis und ein Dateinamen-Präfix an. Der Eintrag "DavLockDB var/DavLock" definiert das Verzeichnis var relativ zum ServerRoot als Ablageort für die Lock-Dateien. Der Benutzer-Account, unter dem Apache läuft (z. B. wwwrun), braucht Lese- und Schreibrechte in diesem Verzeichnis. Falls später beim WebDAV-Zugriff im Fehlerprotokoll von Apache die Meldung "Could not open the lock database" erscheint, stimmen die Dateirechte noch nicht.

Verzeichnisse freigeben

Normalerweise serviert Apache alle Dateien und Verzeichnisse unterhalb des in der Direktive DocumentRoot definierten Verzeichnisses. Als Fileserver soll er jedoch wahrscheinlich auch Verzeichnisse freigeben, die außerhalb dieser Hierarchie liegen. Dazu gibt es zwei Möglichkeiten: Entweder bindet man das gewünschte Verzeichnis mittels symbolischem Link unterhalb des DocumentRoot ein und veranlasst Apache, mit der Direktive "Option FollowSymLinks" den Links zu folgen. Oder man erzeugt mit der Apache-Direktive Alias ein Pseudo-Verzeichnis innerhalb von DocumentRoot.

Bei der zweiten Methode stehen alle Informationen zu den Freigaben in der Konfigurationsdatei httpd.conf beisammen. Das verbessert die Übersicht und bringt damit auch einen Sicherheitsgewinn. Denn symbolische Links haben die Angewohnheit, in Vergessenheit zu geraten …

Der Eintrag "Alias /daten /usr/data" in httpd.conf [8] verknüpft das Verzeichnis /usr/data mit dem virtuellen Verzeichnis /daten auf dem Server. Für die Freigabe ist es wichtig, dass der Apache-Benutzer (z. B. wwwrun) in dieses Verzeichnis schreiben darf, da alle WebDAV-Zugriffe mit den Rechten dieses Benutzers erfolgen.

Im Beispiel steht die Konfiguration der Freigabe in der Directory-Direktive "<Directory /usr/data>". Die Directory-Direktiven beeinflussen alle Requests, die Apache auf das angegebene Verzeichnis im Dateisystem bezieht. Alternativ kann man die Einstellungen auch in einen Location-Block schreiben, der sich auf das per Alias-Direktive zugewiesene virtuelle Verzeichnis bezieht. Für den beschriebenen Fall hieße sie also <Location /daten>, damit alle Requests mit der URL http://meinserver/daten diese Konfiguration verwenden. Für WebDAV sind die beiden Direktiven gleichwertig. Auf einem Fileserver möchte man aber in der Regel ein bestimmtes Verzeichnis freigeben, sodass die Directory-Methode etwas logischer erscheint.

Egal welche der beiden Möglichkeiten verwendet wird, die Zeile "Dav on" innerhalb des Blocks schaltet WebDAV ein.

Sind Skriptsprachen wie PHP aktiviert, liefert Apache beim Zugriff auf eine Skriptdatei nicht deren Inhalt, sondern ruft das Skript auf und gibt seine Ausgabe zurück. Dies ist für einen Fileserver natürlich nicht das erwartete Ergebnis. Die Directive "ForceType text/plain" korrigiert es.

Damit die Konfigurationsänderungen wirksam werden, muss der Admin den Webserver neu starten. Am besten benutzt er dazu das Init-Skript seiner Distribution (im Verzeichnis /etc/init.d/, in Suse-Linux /etc/init.d/apache2) mit dem Parameter restart.

Nun können alle Anwender, die Kontakt zum Webserver haben, auf das freigegebene Verzeichnis zugreifen, und zwar auch schreibend. Um das einzuschränken, muss eine Benutzeranmeldung her. Apache beherrscht von sich aus Digest- und Basic-Authentifizierung sowie die Anmeldung mittels SSL-Client-Zertifikaten (mod_ssl). Client-Zertifikate sind zwar eine sehr sichere Sache, die Konfiguration verlangt aber einiges Know-how, und der Betrieb ist mit Aufwand verbunden. Interessierte können sich auf der Apache-Seite ausgiebig darüber informieren [9].

Benutzerverwaltung

Benutzerverwaltung

Die Digest-Authentifizierung ist in der Dokumentation derzeit noch als experimentell gekennzeichnet, funktioniert aber trotzdem schon sehr zuverlässig. Bei diesem Verfahren wird ein MD5-Hash des Kennwortes übertragen; leider unterstützen die meisten WebDAV-Clients es nicht.

Damit bleibt die Basic-Authentifizierung als universelles Verfahren übrig. Da es bereits in HTTP 1.0 spezifiziert wurde, kommen alle Web-Browser und WebDAV-Clients damit zurecht.

Bei der Basic-Authentifizierung fordert der Webserver vom Browser Benutzerkennung und Kennwort an. Sie werden unverschlüsselt als BASE64-kodierter String übertragen. Damit den nicht jeder Interessierte mitlesen und dekodieren kann, sollte man unbedingt SSL einsetzen, um die Authentifizierung sowie die Nutzdaten verschlüsselt zu übertragen. Dazu später mehr.

Die einfachste Form der Basic-Authentifizierung bietet das Modul mod_auth, das Benutzernamen und Passwörter aus einer Textdatei entnimmt. Sie sollte sich aus Sicherheitsgründen nicht unterhalb von DocumentRoot oder in einem Verzeichnis befinden, das über Apache im Zugriff ist. Das Konfigurationsverzeichnis /etc/apache2 eignet sich gut.

Zum Apache2-Paket gehört auch das Programm htpasswd (oder htpasswd2) zum komfortablen Bearbeiten der Passwörter. Mit

htpasswd2 -c /etc/apache2/htpasswd je

legt man die Datei an und trägt dabei gleich den User je ein. Das Programm fragt ein Passwort ab und legt es verschlüsselt ab; unter Windows und Netware als MD5-Hash, unter Unix crypt-verschlüsselt. Zum Anlegen weiterer User oder zum Ändern eines Passwortes in der bestehenden Datei lässt man einfach den Schalter -c (wie create file) weg.

Will man mehrere Verzeichnisse mit unterschiedlichen Berechtigten definieren, so sollte man die Benutzer in Gruppen organisieren. Hierzu ist nur eine einfache Textdatei notwendig, die pro Zeile eine Gruppendefinition im Format "gruppenname: user1 user2 user3" enthält.

Aktiviert wird die Basic-Authentifikation über den Eintrag "AuthType Basic" im Directory- oder Location-Block. Mit der Direktive AuthName definiert man einen Text, den die meisten WebDAV-Clients dem Benutzer in der Anmeldedialogbox anzeigen.

"AuthUserFile pfad/datei" und "AuthGroupFile pfad/datei" legt die Benutzer/Kennwort- und Gruppendefinitionsdateien fest. Relative Pfade bei diesen Direktiven beziehen sich auf das Verzeichnis ServerRoot. Da die Auth-Direktiven im Directory-Block stehen, beziehen sie sich nur auf diese eine Freigabe. Prinzipiell kann der Webmaster für jede Freigabe unterschiedliche Zugriffsrechte setzen. Um mehrere denselben Benutzern zugänglich zu machen, gibt er einfach dieselben Benutzer- und Gruppendateien an.

Ein Nachteil von mod_auth und der Speicherung von Benutzern in einer Textdatei ist, dass die Performance dieses Moduls bei mehreren hundert Einträgen massiv einbricht. Dann bietet sich das Modul mod_auth_dbm [10] an, welches die Benutzer und Gruppen in einer Datenbank ablegt.

Unabhängig von der Authentifizierungsmethode werden Zugriffsberechtigungen innerhalb der Directory-Direktive festgelegt. Dazu dient das Schlüsselwort Require: "Require valid-user" legt fest, dass alle definierten Benutzer nach erfolgreicher Anmeldung zugreifen dürfen. Um nur ausgewählten Benutzern Zugriff zu gewähren, trägt der Admin sie statt valid-user in die Require-Direktive ein, zum Beispiel "Require user je sfi". Entsprechend gewährt er mit "Require group editors users" den beiden genannten Gruppen WebDAV-Zugriff auf das Verzeichnis.

Soll jeder auf ein Verzeichnis lesend zugreifen können und nur diejenigen sich authentifizieren müssen, die in das Verzeichnis schreiben, verpackt man die Require-Anweisung in eine LimitExcept-Direktive:

<LimitExcept GET>
Require valid-user
</LimitExcept>

Das ist beispielsweise für Verzeichnisse auf einem öffentlichen Webserver sinnvoll, in die der Webdesigner per WebDAV seine Seiten schreiben soll.

Verschlüsseln per SSL

Sehr sichere Leitung

Mit der so eingerichteten einfachen Benutzerverwaltung lässt sich zwar festlegen, wer in die WebDAV-Freigabe schreiben darf. Da jedoch die Kennwörter unverschlüsselt übertragen werden, ist es durchaus möglich, fremde Passwörter zu erlauschen. Auch die Nutzdaten sollten besser verschlüsselt über die Leitung gehen.

HTTP bietet mit SSL (Secure Socket Layer) eine sehr sichere Möglichkeit, Daten verschlüsselt zu übertragen. Um SSL im Apache 2.0 zu aktivieren, sind das Modul mod_ssl (Bestandteil des Lieferumfangs) und ein Serverzertifikat notwendig. Das Serverzertifikat authentifiziert den Server gegenüber dem Client und stellt die Schlüssel für die Verschlüsselung bereit.

Wer es sich leisten kann, wird sicher auf ein Zertifikat zurückgreifen, das von einer offiziellen Certificate Authority wie Verisign oder Thawte ausgestellt wurde. Für ein kleines Netzwerk mit wenigen Anwendern und für erste Tests reicht aber ein selbst signiertes Zertifikat. Dieses erledigt die Verschlüsselung genauso gut. Allerdings ist es für Attacken anfälliger, bei denen der Angreifer den Datenverkehr in beiden Richtungen abfängt und so ein eigenes Zertifikat hineinschmuggeln kann (Man in the Middle Attack). Außerdem erscheint beim Benutzer beim ersten Zugriff eine Warndialogbox, dass das Zertifikat nicht von einer vertrauenswürdigen Stelle signiert wurde.

Mit dem Open-Source-Tool OpenSSL erzeugt man in nur vier einfachen Schritten ein selbst signiertes Zertifikat, das sich für SSL in Apache eignet: Schlüssel erzeugen, Zertifizierungsantrag stellen, Schlüssel selbst zertifizieren und Zertifikat installieren.

Zum Erzeugen des geheimen RSA-Schlüssels in der Datei server.key dient der Aufruf

openssl genrsa -des3 -out server.key 1024

Länger als die hier angegebenen 1024 Bit sollte der Schlüssel nicht sein, da einige Browser damit sonst nicht zurechtkommen.

OpenSSL fragt nach einem Kennwort, mit dem es die Schlüsseldatei verschlüsselt, damit nicht jeder den privaten Schlüssel und das daraus generierte Zertifikat verwenden kann. Denn die Kenntnis des privaten Schlüssels ist der Beweis für die Identität des Servers. Wer ihn ausspäht, kann sich als der legitimere Server ausgeben.

Allerdings fragt Apache bei jedem Start nach diesem Kennwort, da er sonst den privaten Schlüssel nicht lesen kann. Wer das Kennwort nicht jedes Mal eintippen will oder den Webserver auch ohne diese Abfrage starten möchte, hat zwei nicht besonders sichere

Lösungen zur Wahl: Entweder gibt er in httpd.conf die Direktive "SSLPassPhraseDialog exec:Programm" aus, die Apache veranlasst, das Programm zu starten, das dann über Stdout das Kennwort zurückliefert. Oder er lässt einfach den Parameter -des3 weg, um die Schlüsseldatei unverschlüsselt abzulegen.

Die zweite Methode ist weniger fehlerträchtig und braucht kein zusätzliches Programm. Um den geheimen Schlüssel vor fremden Augen zu schützen, setzt man einfach die Dateirechte so, dass nur der User root ihn lesen darf:

chmod 400 server.key
chown root server.key

Als Nächstes muss eine Zertifikatssignierungsanfrage (Certificate Signing Request, CSR) erzeugt werden, welche die Daten des eigenen Zertifikates enthält:

openssl req -new -key server.key -out server.csr

Openssl fragt nun diverse Verwaltungsinformationen wie Land und Ort ab, die bei einem selbst signierten Zertifikat größtenteils nicht wichtig sind. Nur der "Common Name" (CN) muss exakt dem Namen des Servers entsprechen, über den die Clients ihn ansprechen, zum Beispiel davserver.example.com. Denn für die Zuordnung des Zertifikats zu einem Server nutzen sie den CN; Unterschiede führen zu einem Warnhinweis auf dem Client.

Diese beiden Schritte sehen genauso aus, wenn man sich das Zertifikat bei einem Dienstleister kauft. Dann reicht man den CSR dort ein und erhält das Zertifikat zurück.

Beim selbst signierten Zertifikat dient der Befehl

openssl x509 -req -days 1825 -in server.csr -signkey server.key -out server.crt

zum Bestätigen des Schlüssels. Er bescheinigt dem Zertifikat eine Gültigkeit von fünf Jahren und legt es im X.509-Format in der Datei server.crt ab.

Die Installation des Zertifikates und des geheimen Schlüssels in Apache ist kein Hexenwerk mehr. Es genügt, den geheimen Schlüssel und das Zertifikat in das richtige Verzeichnis zu kopieren und dann SSL zu aktivieren. Die Verzeichnisse liegen unterhalb des Apache-Konfigurationsverzeichnisses. Der private Schlüssel server.key gehört in das Verzeichnis ssl.key, das Zertifikat server.crt ins Verzeichnis ssl.crt.

Die gängigen Linux-Distributoren konfigurieren Apache bereits so vor, dass die SSL-Konfiguration aus der Datei ssl.conf in httpd.conf eingefügt wird. Der Webmaster muss lediglich über die Direktiven SSLCertificateFile und SSLCertificateKeyFile bekannt geben, wo sich Schlüssel und Zertifikat befinden.

Zum Aktivieren von SSL gibt man Apache beim Start die Option -D SSL mit. Wie das im Startskript /etc/init.d/apache2 geschieht, hängt von der Distribution ab. Das Skript von Suse-Linux liest die Optionen aus der Datei /etc/sysconfig/apache2 ein, in die der Administrator daher die Zeile

APACHE_SERVER_FLAGS="-D SSL"

einträgt. Die Zeile ist recht weit unten in der Datei bereits angelegt, enthält aber bei der Installation noch keine Flags.

Nach einem Neustart des Webservers stehen seine Seiten auch per https zur Verfügung. Beim ersten Aufruf warnt der Browser den Benutzer wegen des selbst signierten Zertifikats. Um das bei den weiteren Zugriffen zu vermeiden, installiert man es nach genauer Prüfung über den Zertifikatmanager des Browsers auf dem Client.

In dieser Konfiguration erlaubt Apache den WebDAV-Zugriff mit und ohne Verschlüsselung. Um SSL zu erzwingen, ist lediglich die Anweisung SSLRequireSSL innerhalb der Directory-Direktive notwendig.

Die gängigen Distributoren installieren Apache normalerweise schon recht sicher. Anders als bei dem im vorherigen Artikel besprochenen IIS sind daher in der Regel keine weiteren Maßnahmen zur Grundsicherung erforderlich. Allerdings ist auch Apache nicht ohne Fehler, sodass hier ebenfalls die oberste Direktive heißt: immer auf dem aktuellen Stand bleiben und Sicherheitspatches einspielen.

Wenn Apache als Fileserver mit WebDAV dient, ist bei der Verwendung von CGI-Skripten besondere Vorsicht geboten. Auch sollte man .htaccess-Dateien über die Direktive "AllowOverride None" verbieten, da damit die Konfiguration durch das Einspielen einer .htaccess-Datei manipuliert werden könnte.

Client-Konfiguration

Zugriff!

Zum Zugriff auf die WebDAV-Freigaben bringen alle verbreiteten Betriebssysteme schon die nötige Client-Software mit. Im Internet Explorer genügt es, im Öffnen-Dialog die Option "Als Webordner öffnen" zu aktivieren, und schon stellt er den Inhalt des WebDAV-Verzeichnisses zum Drag&Drop-Zugriff bereit. Die per Internet Explorer geöffneten Webordner tauchen danach in der Netzwerkumgebung auf. Dort kann man sie auch direkt über den Assistenten "Netzwerkumgebung hinzufügen" einrichten.

Über den zu Windows XP gehörigen WebDAV-Redirector lässt sich die Freigabe als Netzlaufwerk einbinden und mit einem Laufwerksbuchstaben versehen. Allerdings kommt er nicht mit SSL zurecht und seit dem Service Pack 2 verweigert er die Basic-Authentifizierung, wenn man sie nicht ausdrücklich in der Registry freischaltet. Eine Registry-Datei, die das erledigt, steht als Download [11] bereit.

Ähnlich sieht es für Mac OS aus, bei dem der Finder zwar auch als WebDAV-Client funktioniert, aber ebenfalls kein SSL beherrscht. Hier hilft das kostenlose Tool Goliath [12], das Mac OS ab Version 9 einen WebDAV-Client mit SSL-Support im Finder-Look beschert.

Linux-Benutzer greifen im KDE-Desktop über den Konqueror ähnlich komfortabel wie Windows-Anwender auf WebDAV-Ressourcen zu. Es reicht die Eingabe der Adresse in der Form webdav://server/freigabe/; für eine verschlüsselte Verbindung (über Port 443 mit SSL) ist webdavs:// zu verwenden. Das OpenSource-Projekt DAVfs2 [13] ermöglicht es Linux, zusätzlich WebDAV-Freigaben als Filesystem zu mounten [14].

Wenn auch die Nutzer des Servers lokal auf die Dateien in der WebDAV-Freigabe zugreifen sollen, gibt es noch einen Fallstrick zu überspringen: Apache schreibt die Dateien mit der Benutzer- und Gruppenkennung, unter der er selbst läuft, und setzt die Rechte so, dass andere Anwender die Dateien nicht bearbeiten dürfen. Um lokalen Benutzern Zugriff zu gewähren, trägt der Admin sie am besten mit dem Befehl usermod in die Gruppe des Apache-Users ein, unter Suse-Linux beispielsweise in die Gruppe www, unter Debian in www-data. (rek [15])

Auschnitt aus httpd.conf

[16]Auschnitt aus httpd.conf

  1 # Apache Module für WebDAV laden
  2 LoadModule dav_module mod_dav.so
  3 LoadModule dav_fs_module mod_dav_fs.so
  4 # SSL-Modul laden
  5 LoadModule ssl_module mod_ssl.so
  6 
  7 # Speicherort für die Lock-Datenbank
  8 DavLockDB var/DavLock
  9 
 10 # Verzeichnis freigeben
 11 # außerhalb des DocumentRoot
 12 Alias /daten /usr/data
 13 
 14 # Diese Verzeichnisfreigabe konfigurieren
 15 <Directory /usr/data>
 16   # WebDAV einschalten
 17   Dav on
 18 
 19   # Alle Dateien als Plain Text zurückgegeben,
 20   # auch Skripte
 21   ForceType text/plain
 22 
 23   # Benutzerauthentifizierung
 24   AuthType Basic
 25   AuthName "Mein WebDAV"
 26   AuthUserFile /etc/apache2/htpasswd 
 27   AuthGroupFile /etc/apache2/htgroup
 28 
 29   # Alle definierten User dürfen zugreifen
 30   Require valid-user
 31 
 32   # Keine .htaccess-Dateien erlauben
 33   AllowOverride None
 34 
 35   # Auflisten des Verzeichnisinhaltes erlauben 
 36   Options Indexes 
 37 
 38   # Zugriff nur über SSL (verschlüsselt)
 39   SSLRequireSSL
 40 </Directory>
 41 
 42 # SSL aktivieren
 43 # Dies steht oft in ssl.conf z.B. bei SuSE
 44 SSLEngine on
 45 SSLCertificateFile /etc/apache2/ssl.crt/server.crt
 46 SSLCertificateKeyFile /etc/apache2/ssl.key/server.key


(rek [17])

URL dieses Artikels:
https://www.heise.de/-221613

Links in diesem Artikel:
[1] https://www.heise.de/ratgeber/Speicher-im-WWW-221617.html
[2] http://www.heise.de/netze/software/default.shtml?prg=927
[3] http://www.novell.com/de-de/linux/
[4] http://www.redhat.de/
[5] http://www.heise.de/netze/software/default.shtml?prg=22987
[6] http://www.de.debian.org/
[7] http://httpd.apache.org/docs/2.0/mod/mod_dav.html
[8] #httpdconf-u4
[9] http://httpd.apache.org/docs-2.0/ssl/
[10] http://httpd.apache.org/docs-2.0/mod/mod_auth_dbm.html
[11] http://www.heise.de/ct/ftp/05/04/202/
[12] http://www.heise.de/netze/software/default.shtml?prg=28369
[13] http://www.heise.de/netze/software/default.shtml?prg=28335
[14] https://www.heise.de/ratgeber/Speicher-im-WWW-221617.html
[15] mailto:rek@heise-netze.de
[16] 
[17] mailto:rek@ct.de

Copyright © 2006 Heise Medien