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.
Neueste Kommentare
6 Kommentare zu Server zu Hause hosten: sichere Dienste über den DSL-Anschluss
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Benutzt doch den neuesten kostenlosen dyndns Anbieter webants.com Die Updates erfolgen via URL-Request und können auf einem Linux System, wie ich es nutze, via Cron aufgerufen werden. Es wird auch ipv6 unterstützt, bin rundum zufrieden
(Ich weiß, dass der Artikel einen Bart hat)
Ich träume auch gerade wieder vom Home-Hosting, der Artikel beleuchtet eigentlich alle Aspekte sehr gut, leider gibt er keine detailierten Information, welche DSL-Anbieter einen Webserver daheim gestatten.
Ich werde sowieso eine eigene Cloud einrichten, ansonsten ist ein Server daheim nicht rentabel und auch nicht sinnvoll. Nimmt man z.B. einen stromsparenden Atom mit ca. 30 Watt/h für den eigenen Server, ist man bereits bei knapp 6€/Monat nur für Strom. Dazu addieren sich Domainkosten bei einem Anbieter wie „no-ip“, eventuell auch weitere Services wie Mail-forwarding etc., ausserdem Anschaffungs- und Wartungskosten für die Hardware. 10€/Monat Gesamtkosten sind schon sehr optimistisch gerechnet, dafür bekommt man locker einen günstigen Root- oder Vserver, welcher zuverlässig durch ein Rechenzentrum angebunden ist. Die heimische DSL-Leitung fällt zumindest bei mir auch öfters mal aus.
Der Vorteil eines Heimservers wäre eigentlich nur sehr viel mehr Speicherplatz für kleines Geld. Vielleicht mountet man auch einfach seinen homespace als Verzeichnis in den vserver und nutzt so das Beste beider Welten ;)
Domainanbieter
Hallo, ich habe auch einen eignene Server daheim an meiner DSL Leitung (http://www.qsc.de mit fester IP) und mir eine Domain bei http://www.centralsystems-isp.com geholt.
Klappt alles bestens!
Teamspeak
Ein Einwand zu Teamspeak:
Clienten können eine Voice activity einstellen, sodass Geräusche nur übertragen werden wenn ein gewisser Pegel erreicht wird, also wenn jemand anfängt zu sprechen oder beispielsweise zu schreien.
lieber keine dynamische IP-Adresse für Mailserver!
Netter Artikel – mit einer Ausnahme:
einen Mailserver, der auch Mails ans freie Internet versenden soll (also ohne Smarthost), kann man heutzutage nicht seriös an einem DSL-Anschluß mit dynamischer IP-Adresse verwenden.
Nahezu alle Provider setzen zur Spamfilterung Listen ein, die Mails von Servern aus dynamischen Adressräumen (Dialup-Anschlüsse und auch DSL) mit hoher Wahrscheinlichkeit als Spam einstufen. Man läuft also Gefahr, daß die eigenen Mails beim Empfänger nicht ankommen.
Bei dynamischen IP-Adressen kann man auch mit SPF-Einträgen hier keine Abhilfe schaffen.
Zumindest ein Smarthost-Mailserver sollte also schon eingesetzt werden, sofern einem eMails einigermaßen wichtig sind. Von Backup-MX etc. mal ganz zu schweigen.
Zuhause kann dann ja ebenfalls ein Mailserver stehen, der dann die abgehenden Mails an den externen Server weiterleitet und dort eintreffende Mails regelmäßig abfragt.
AW: lieber keine dynamische IP-Adresse für Mailserver!
Hallo Karsten,
da haben Sie mich bei einem Aspekt erwischt, den ich hätte erwähnen sollen. Einen Mailserver an einer dynamischen IP-Adresse zu betreiben ist praktisch nur dann möglich, wenn man den SMTP-Server des Providers als Smarthost verwendet. Den kann man in der Regel ohne Authentifizierung nutzen und er steht (hoffentlich) nicht auf einer Blacklist.
Eingehende Mail wird von der Blacklist nicht beeinflusst.
Ausführliche Informationen zu DNS-Blacklisting gibt es in unserem Artikel „DNS-Blacklisting: E-Mail Verbot für Unschuldige„, der sich kritisch mit der pauschalen Listung dynamischer IP-Adressen auseinandersetzt. Dort findet man auch Hinweise, wie man günstig an einen Backup-MX-Server kommt, wenn man keinen Gleichgesinnten findet, mit dem man sich gegenseitig „Backup-MXen“ kann.
Mit freundlichen Grüßen
Christoph H. Hochstätter