Server zu Hause hosten: sichere Dienste über den DSL-Anschluss

Wenn die DNS-Dienste konfiguriert sind und korrekt auf die statische oder dynamische IP-Adresse auflösen, müssen nur noch am DSL-Router die Ports zu den Servern konfiguriert werden. Alle Server sollten eine statische IP-Adresse aus dem privaten Subnetz bekommen. Zwar kann das DHCP-Protokoll grundsätzlich auch feste IP-Adressen zuweisen, jedoch beherrschen die meisten DSL-Router diese Möglichkeit nicht.

Will man sich die Möglichkeit offenhalten, Server auch von anderen Standorten zu administrieren, muss man eine Fernzugangsmöglichkeit schaffen. Bei Linux-Rechnern lässt sich das über SSH erreichen, bei Windows-Rechnern geht das am besten mit Remote-Desktop. Wer mehr als einen Server einsetzt, muss beachten, dass er jeweils nur einen Rechner über die Standard-Ports 22 für SSH und 3389 für Remote-Desktop weiterleiten kann. Für weitere Rechner nimmt man einfach andere, ungenutzte Ports, beispielsweise 24 für SSH und 3390 für Remote Desktop. So lässt sich ein zweiter Windows-Server erreichen, indem man im Terminal-Server-Client als Adresse example.com:3390 eintippt. Beim beliebten SSH-Client Putty verwendet man den Kommandozeilenbefehl putty -P 24 example.com.

Für ein Webhosting mit Apache oder IIS kommen nur die Ports 80 für http und 443 für https in Frage, ansonsten bietet man seinen Besuchern eine unprofessionell aussehende URL wie http://www.example.com:82 an. Es gelten weitere Restriktionen. Da man die Ports 80 und 443 der öffentlichen IP-Adresse nur an eine private weiterleiten kann, muss beachtet werden, dass man einen zweiten Webserver zweckmäßigerweise so einrichtet, dass dieser über Links vom Hauptserver zu erreichen ist. Zum Beispiel kann auf www.example.com ein Link angebracht werden, der auf www.example.com:81 verweist.

Wer Web-Authoring mittels WebDAV von außerhalb einrichten möchte, um HTML-Editoren wie Frontpage und Expression Web zu nutzen oder professionelle .NET-Anwendungen mit Visual Studio zu erstellen, der sollte darauf achten, dass Web-Authoring aus Sicherheitsgründen nur über https erreichbar ist. Während man in den Einstellungen von IIS6 den Punkt "Require https for authoring" schnell findet, muss man sich bei IIS7 zu den „WebDAV-Settings“ durchhangeln und nicht zu den „WebDAV-Authoring-Rules“, wo man die Einstellung vermutet. Auch der Erläuterungstext "Allow anonymous property queries" (siehe Bild 4) ist ungeschickter gewählt als im IIS6.

Für Exchange als Mailserver ist es am geschicktesten, nur Port 25 zu öffnen, um den E-Mail-Eingang zu ermöglichen. Eine Administration von außerhalb kann sicher über Remote-Desktop geschehen. Wer eine Alternative mit webbasierter Konfiguration verwendet, etwa Communigate, sollte darauf achten, dass die Administrationswebsite mit https abgesichert ist. Das ist bei Communigate der Fall, jedoch akzeptiert Firefox 3 das Zertifikat nicht. Da sich unverschlüsselte http-Verbindungen mit stunnel absichern lassen, kann man dieses Problem relativ einfach beheben.

Wer Voice-Konferenzen abhalten möchte, sollte über Teamspeak nachdenken, das für die nicht kommerzielle Nutzung kostenlos ist. Telefonkonferenzen haben den Nachteil, dass sich ab etwa fünf Teilnehmern Hintergrundgeräusche auf ein beträchtliches Maß addieren. Das kann man mit einer moderierten Konferenz verhindern. Dazu muss man jedoch eine VoIP-Software wie Asterisk aufsetzen, was recht umständlich ist. Ein einfaches Voice-Conferencing-System, beispielsweise Teamspeak, ist schnell aufgesetzt. Daneben hat es den Vorteil, dass nur ein UDP-Port an den Server weitergeleitet werden muss. Komplizierte NAT-Problematiken wie bei SIP treten nicht auf.

Stunnel ist bei Teamspeak Pflicht, da das Webadmin-Interface kein https ermöglicht. Außerdem verfügt Teamspeak über ein Telnet-Admin-Interface auf Port 51234. Das lässt sich auch über Stunnel absichern, aber nicht jeder Telnet-Client beherrscht das telnets-Protokoll. Da die Nutzung dieses oft nicht benötigten Interfaces ohnehin schwierig ist, sollte man Port 51234 aus Sicherheitsgründen gar nicht weiterleiten.

Für weitere Serverdienste gilt es zu beachten, dass unverschlüsselte Dienste nur dann gehostet werden dürfen, wenn sie für die Allgemeinheit bestimmt sind. Gegen einen öffentlichen FTP-Server ist nichts einzuwenden. Einen privaten FTP-Server, der Benutzernamen und Passwort verlangt, kann man abhören. Hier müssen sichere Alternativen wie SCP oder SFTP auf SSH-Basis genutzt werden. Gibt es ein Webinterface zur Administration, so muss man es immer mit Stunnel absichern, sofern kein https-Protokoll zur Verfügung steht. Geschieht die Administration über ein lokales Programm oder Konfigurationsdateien, so ist der Fernzugang mittels SSH oder Remote-Desktop sicherheitstechnisch unbedenklich.