Dank DSL mit großen Bandbreiten und Flatrate hat man heute nicht nur die Möglichkeit, ziemlich schnell und viel im Internet zu surfen. Es ist auch mit wenig Aufwand möglich, einen eigenen, kleinen Webserver zu Hause zu betreiben. In diesem Artikel beschreibe ich einmal den Aufbau eines solchen Webservers und zeige einige Vor- und Nachteile dieser Lösung auf.

Inhaltsverzeichnis

• Provider-Hosting vs. Home-Hosting
• Domain-Namen und wechselnde IP-Adressen
• Hardwarefragen
• Einrichtung des Servers
• Auswahl des Betriebssystems
• Grund-Konfiguration
• Vernetzung
• Firewall-Konfiguration
• Apache-Konfiguration
• Mail-Server-Konfiguration (Postfix)
• Erfahrungen im Betrieb

Provider-Hosting vs. Home-Hosting

Zunächst einmal möchte ich die beiden Hosting-Varianten, also Server beim Provider vs. Server zu Haus, miteinander vergleichen:

Hosting beim Provider (z.B. Virtual Server)

Vorteile

• hohe Verfügbarkeit, nicht von Funktion des heimischen DSL abhängig
• hohe Bandbreite ins Internet (meist Gbit-Anbindung direkt beim Provider)
• automatisches Backup des kompletten Servers oft inklusive

Nachteile

• relativ hohe, monatliche Kosten (Stand November 2008 etwa 10 € für den Server, dazu kommen die Kosten für die Domänenregistrierung)
• Webspace oft begrenzt (wenn auch heute meist großzügig bemessen)
• Traffic-Volumen meist begrenzt, Überschreitung des Inklusivvolumens muss oft teuer bezahlt werden

Hosting zu Hause

Vorteile

• sehr geringe Kosten (DSL-Anschluss ist ohnehin vorhanden, nur Kosten für Domain-Registrierung notwendig)
• keinerlei Beschränkungen beim verfügbaren Webspace
• meist keine Beschränkungen beim Traffic-Volumen

Nachteile

• Verfügbarkeit direkt vom Funktionieren des DSL abhängig
• geringe Bandbreite (meist etwa 700KBit/s)
• Stromkosten
• Backup muss selbst organisiert werden

Die größte Einschränkung, die gegen das Hosting zu Hause spricht, ist die beschränkte Bandbreite der meisten DSL-Anschlüsse. Hier handelt es sich meist um ADSL, bei dem lediglich die Übertragungsrichtung vom Internet zum Endanschluss mit 2 – 6 Mbit/s betrieben wird. Die Gegenrichtung, also vom Endanschluss ins Internet hat meist eine Bandbreite von weniger als 1 Mbit/s. Gerade diese Richtung ist es aber, die für einen Webserver, der zu Hause betrieben wird, interessant ist - er soll ja seine Inhalte ins Internet übertragen. Will man allerdings keinen Streaming-Content anbieten, und rechnet man auch nicht mit mehreren tausend Besuchern pro Tag, reichen die oft angebotenen 700KBit/s für eine einfache Webpräsenz völlig aus. Und das Schöne ist – das eigene Surfen wird durch den Betrieb des eigenen Servers kaum behindert. Man selbst benutzt schließlich die Gegenrichtung, die vom Webserver kaum belastet wird.

Aber auch Stromverbrauch und Verfügbarkeit des Servers sollten in die Kalkulation einbezogen werden. Wir verwenden einen sehr kleinen, verbrauchsoptimierten Server, der etwa 40 Watt an Leistung aus der Steckdose zieht, dafür aber auch keinen Spitzenleistung abliefert. Für einen normalen Webserver ist das in Ordnung, insbesondere, wenn man nicht viele Besucher erwartet. Ein handelsüblicher PC verbraucht allerdings schon mindestens 80-120 Watt, ein echter Server mit redundanten Festplatten noch einmal deutlich mehr. Dazu kommt, dass man, will man sicherstellen, dass zumindest im eigenen Einflussbereich so viel wie möglich gegen die Nicht-Verfügbarkeit des Servers getan wurde, eine unterbrechungsfreie Stromversorgung für den Server und den DSL-Router vorsehen sollte. Damit kann dann zumindest ein kurzer Stromausfall in der heimischen Wohnung wegen irgendeines Kurzschlusses im Toaster oder Fön überbrückt werden.

Fazit

Ich habe mich für die Variante des Servers zu Hause entschieden. Mein DSL-Anschluss hat eine ausreichende Bandbreite und wird den größten Teil des Tages ohnehin nicht benutzt - bezahlt aber wohl. Warum also diese Ressource einfach nur im Leerlauf surren lassen. Außerdem war es eine nette kleine Herausforderung, einen Server zu bauen, der einerseits auf der Stromrechnung nicht signifikant zu bemerken ist, aber gleichzeitig genug Leistung bereitstellt, um eine modernes ContentManagementSystem inklusive Datenbank zu betreiben.

Domain-Namen und wechselnde IP-Adressen

Will man seinen eigenen Webserver zu Hause betreiben, bietet es sich an, einen der zahlreichen Dynamic DNS-Provider zu verwenden. Eine normale DNS-Registrierung reicht nicht aus, da praktisch alle DSL-Anbieter alle 24 Stunden eine kurze Verbindungsunterbrechung erzwingen und dabei dem Anschluss eine neue IP-Adresse zuweisen. Eine normale Domain erlaubt es jedoch nicht, so häufig die mit dem Domänen-Namen verknüpfte IP-Adresse zu verändern, die die entsprechende Verknüpfung eine vordefinierte Lebensdauer von oft 24 Stunden hat. Die bei der Leitungsunterbrechung zugewiesene IP-Adresse würde also im ungünstigen Fall erst am darauffolgenden Tag gültig werden - und dann hat der DSL-Anschluss bereits die nächste Adresse zugewiesen bekommen.

Zum Glück gibt es die eben jene Dynamic-DNS-Provider. Die funktionieren im Wesentlichen so: Man meldet sich beim DynDNS-Provider an, erhält ein eignes Konto mit Benutzerkennung, Passwort und einem festen Domänen-Namen. Bei jeder Änderung der eigenen IP-Adresse teilt man die neue IP-Adresse dem DynDNS-Provider mit, der daraufhin den DNS-Datensatz, welcher den Domänen-Namen mit der IP-Adresse verknüpft, aktualisiert. Diese DNS-Datensätze haben jedoch eine Lebensdauer von nur 60 Sekunden. Das bedeutet, dass jede Anfrage an den Domänennamen weltweit einen maximal 60 Sekunden alten Domänendatensatz als Antwort erhält. Damit ist die Domäne nach Aktualisierung der IP-Adresse maximal 60 Sekunden nicht erreichbar. Für semiprofessionelle Zwecke eine sicher hinreichende Verfügbarkeit.

Einen kleinen Haken hat die Sache aber doch: Die meisten dynDNS-Provider bieten ihre Dienste zwar kostenlos an, dafür muß man aber mit einem mehr oder minder vorgegebenen Domänen-Namen vorlieb nehmen. Zumindest die Second-Level-Domäne verweist immer auf den dynDNS-Provider, was für den Besucher der Website immer ein direkter Hinweis darauf ist, dass er sich auf einer "privat" gehosteten Seite bewegt. Unschön. Die Lösung ist, dass man sich einen Provider sucht, der für einen gewissen Obulus die eigene Domäne direkt auf die dynamische IP-Adresse umleitet. In Deutschland, Österreich und der Schweiz macht das zum Beispiel selfhost, bei denen das Hosting der entsprechenden Domäne 1,50€ pro Monat kostet (Stand November 2008). Billiger ist das Hosting der Domäne bei einem klassischen Internetprovider auch nicht, also bietet sich hier der Umzug wirklich an. Der gestaltet sich unproblematisch: Die Domäne kann ganz unbürokratisch beim alten Provider als "freigegeben" markiert werden, der neue Provider erhält einen Transfer-Code, und im günstigsten Fall ist innerhalb von 24 Stunden der Umzug Geschichte.

Die Aktualisierung der IP-Adresse beim dynDNS-Provider sollte natürlich automatisch erfolgen. Dazu bieten viele dynDNS-Provider entsprechende Tools für Windows oder Linux an. Noch einfacher ist es, wenn der verwendete DSL-Router bereits eine entsprechende Option beinhaltet, wie es beispielsweise bei der Fritz!Box von AVM der Fall ist. Die kann dann auch gleich noch die Funktion der primären Firewall übernehmen - dazu aber später noch mehr.

Hardwarefragen

Ist die dynDNS-Domäne einmal konnektiert, erwarten potentielle Besucher am anderen Ende der Leitung natürlich auch einen funktionierenden Server. Bei der Auswahl der betreffenden Hardware muss man zwangsläufig Kompromisse eingehen.

Leider ist es so, daß sich die Anforderung nach hoher Leistung und Verfügbarkeit des Servers direkt mit dem Wunsch nach einem möglichst niedrigen Stromverbrauch beißt. Natürlich wäre es schön, einen Server zu Hause zu haben, der über redundante (also z.B. gespiegelte) Festplatten verfügt, um bei einem Plattencrash reibungslos weiter zu funktionieren. Wenn man es richtig ernst meint, könnte man sogar den kompletten Server redundant aufbauen - also einen Hochverfügbarkeitscluster aus zwei identischen Servern aufbauen. Aber je mehr Aufwand ich an dieser Stelle investiere, desto mehr Komponenten erhalte ich, die meine Stromrechnung belasten. Um die Größenordnung einschätzen zu können: Eine handelsübliche 3.5-Zoll-Festplatte hat eine Leistungsaufnahme im Betrieb von etwa 5-7 Watt. Ein RAID5-Verbund aus drei Festplatten hätte also (ohne den dazu ggf. notwendigen Controller) eine Leistungsaufnahme von 15-21 Watt. Auch bei der Wahl des Prozessors lohnt ein genauer Blick auf die Leistungsaufnahme. Für den stromsparenden Dauerbetrieb eignen sich momentan eigentlich nur Intels Atom-Prozessor, der Geode-Prozessor von AMD und der C3 von VIA in Frage. Alle anderen Prozessoren ziehen im Verbund mit ihrem jeweiligen Chipsatz allein mehr als 40 Watt Leistung. Zum Vergleich: Ein aktuelles Netbook kommt als Gesamtsystem (Festplatte, Prozessor, Mainboard, Speicher und Display) mit einem Stromverbrauch von unter 30 Watt daher. Das sollte der Wert sein, an dem man sich bei der Planung des eigenen Servers orientieren kann.

Wir verwenden für unsere stromsparenden Mini-Server Mainboards von VIA, auf denen der C3-Prozessor bereits fest aufgelöstet ist. Chipsatz und Prozessor harmonieren gut miteinander, wenngleich die Leistung für ein Desktop-System insbesondere im Grafikbereich kaum ausreichend wäre. Für einen Server spielt das jedoch keine Rolle - Hauptsache, der Energieverbrauch stimmt. Das System wird dann noch mit einer 3.5-Zoll-Festplatte (ein für den 24/7-Betrieb freigegebenes RAID-Modell versehen. Die ist zwar, was den Energieverbrauch angeht, nicht das Optimum - eine 2.5-Zoll-Notebookfestplatte wäre wesentlich sparsamer - aber dafür ist der Datendurchsatz sehr gut. Und das ist für den vorgesehenen Serverbetrieb wiederum nahezu unverzichtbar. Auf Redundanz bei den Festplatten wird verzichtet, statt dessen wird regelmäßig ein Komplett-Backup des Servers auf einer externen USB-Festplatte durchgeführt.

Insgesamt entsteht so ein kleiner Server, der im Betrieb deutlich unter einer Leistungsaufnahme von 50 Watt liegt. Damit kann man leben. Beim aktuellen Preis von 17,84 Cent/kWh bei unserem Stromanbieter kostet der Betrieb des Servers pro Tag rund 21 Cent, pro Jahr also rund 77 Euro. Zum Vergleich: Das Hosting des Servers bei einem Provider kostet Stand 2008 pro Monat mindestens 10 Euro, pro Jahr also 120 Euro. Macht also immer noch eine Ersparnis von 40 Euro beim Home-Hosting gegenüber dem Provider-Hosting. So ganz ehrlich ist diese Rechnung natürlich nicht, denn immerhin muss man den Stromverbrauch des DSL-Routers noch mit in die Rechnung einbeziehen. Und wenn die Strompreise weiter steigen und die Hostingpreise weiter fallen sollten, ist Home-Hosting sicher keine so günstige Alternative mehr.

Einrichtung des Servers

Auswahl des Betriebssystems

Es gibt viele Gründe, warum man einen Webserver nicht unter Windows laufen lassen sollte. Sicherheitsaspekte spielen dabei sicher eine große Rolle. Für den angepeilten Zweck des kleinen und sparsamen Homeservers ist Linux aber auf jeden Fall die bessere Wahl. Zum einen ist es als OpenSource-Produkt kostenfrei verfügbar. Zum anderen benötigen wir bei unserem Server keine grafische Benutzeroberfläche. Die entsprechenden Ressourcen benutzt man lieber für die produktiven Services wie den Web- oder Mailserver. Darüber hinaus läuft Linux, gerade weil es so ressourcenschonend konfiguriert werden kann, auf leistungsschwächeren Plattformen einfach viel schneller und oft auch stabiler als Windows. Und zu guter Letzt muss man berücksichtigen, daß durch die permanente Weiterentwicklung des Systems durch die weltweite Entwicklergemeinde Sicherheitslöcher sehr schnell entdeckt und gestopft werden. Also ist die Entscheidung klar und schnell getroffen - es kommt ein Linux-System zum Einsatz.

Grund-Konfiguration

Um einen Webserver zu betreiben, benötigt man zunächst nur eine minimale Linux-Installation ohne jede grafische Oberfläche. Egal, welche Distribution man verwendet, sollte man das System also ohne X11, KDE und Gnome installieren. Das spart erheblich an Ressourcen, zumal man am Server selbst später ohnehin nicht arbeiten wird - wozu also eine grafische Oberfläche?

Zusätzlich zur Basisinstallation sollten folgende Services auf dem Server nicht fehlen:

• Apache als HTTP-Server
• PHP als Apache-Modul (für den Betrieb des Content-Management-Systems)
• mySQL als Datenbank-Backend
• Sendmail oder Postfix als Mail-Server (ich bevorzuge aus irgendeinem Grund Postfix)
• SpamAssassin als Spamfilter
• BIND als lokaler Nameserver (man kann natürlich auch den Nameserver des Providers verwenden)

Zusätzlich kann man natürlich bei Bedarf noch einen DHCP-Server für die lokale Vergabe von IP-Adressen installieren, einen Samba-Server, um von Windows-Clients Dateien mit dem Server austauschen zu können und vielleicht einen FTP-Server (sehr empfehlenswert: vsftp), um auch aus dem Internet die Möglichkeit zur Dateiablage auf dem Server zu haben.

Vernetzung

Der Server selbst wird vermutlich innerhalt des eigenen, lokalen Netzwerkes stehen, also keine "offizielle" IP-Adresse besitzen. Es sei denn, man koppelt den Server direkt mit dem DSL-Modem und etabliert die Internet-Verbindung hardwareseitig über eine zweite Ethernet-Schnittstelle und softwareseitig über den PPPoE-Daemon. Da viele DSL-Router heute jedoch gleichzeitig WLAN-Router darstellen und in einigen Fällen auch Fax- und Anrufbeantworterfunktion für den ISDN-Anschluss beinhalten, ist es einfacher, die Internetverbindung über einen DSL-Router zu etablieren und dessen Firewall so zu konfigurieren, dass die gewünschten Dienste direkt an den im lokalen Netzwerk stehenden Server weitergeroutet werden.

Also muss der Server zunächst eine IP-Adresse aus einem der privaten Adressräume des TCP/IP-Protokolls erhalten. Es gibt drei solche Adressräume:

• 10.0.0.0/8:
  Dieser Adressraum kann verwendet werden, wenn das lokale Netzwerk sehr viele Clients enthalten soll, wie das bei Firmennetzwerken der Fall ist. Für private Netze ist dieser Adressraum wohl in den meisten Fällen zu groß - wer hat schon rund 16.5 Millionen Computer zu Hause.
• 172.16.0.0/12:
  Dieser Adressraum ist etwas kleiner als der des 10er-Adressraumes, aber für private Netzwerke immer noch viel zu groß. Außerdem ist die Berechnung der IP-Adressen und Netzmasken etwas komplizierter, da der Adressraum insgesamt eine Netzmaske von 12 Bit hat.
• 192.168.0.0/16:
  In diesem Adressraum finden immer noch mehr als 60.000 Clients Platz, aber durch die einfache Berechnung der IP-Adressen und der Netzmasken ist dies sicher der Adressraum, der in den meisten privaten Netzwerken verwendet wird

Wer mehr über die Funktionsweise von TCP/IP und die Vergabe von IP-Adressen wissen will, dem sei der entsprechende Wikipedia-Artikel ans Herz gelegt.

Gehen wir einmal davon aus, dass unser internes LAN den IP-Adressbereich 192.168.1.0/24 benutzen soll. In diesem Adressbereich würden 255 Clients Platz haben, was sicher für die meisten häuslichen Zwecke ausreicht - selbst wenn man davon ausgeht, dass in absehbarer Zeit Fernseher, digitale Bilderrahmen, MP3-Player, Mobiltelefone sowieso und vielleicht sogar Kühlschrank und Waschmaschine nach einer IP-Adresse gieren.

Der DSL-Router erhält dabei die IP-Adresse 192.168.1.1. Diese IP-Adresse ist für alle weiteren Clients später insofern wichtig, als dass sie alle Datenpakete, die ins Internet gelangen sollen, an diese IP-Adresse zur Weiterleitung senden müssen. Als Netzmaske wird beim DSL-Router (genauso wie bei allen anderen Clients innerhalt des Netzwerkes) der Wert 255.255.255.0 festgelegt.

Der künftige Web- (und Mail-) Server erhält im Netzwerk nun z.B. die Adresse 192.168.1.2, Netzmaske 255.255.255.0. Als Standard-Gateway wird, wie eben schon erläutert, die IP-Adresse des DSL-Routers - also 192.168.1.1 - eingetragen. Damit sollte bei funktionierender DSL-Verbindung der Server bereits Kontakt zum Internet haben. Nur umgekehrt ist noch kein Datenverkehr möglich - der Server ist aus dem Internet noch vollkommen unsichtbar. Damit sich das ändert, muss auf dem DSL-Router sogenanntes Port-Forwarding aktiviert werden. Die meisten DSL-Router bieten in ihrem Konfigurationsmenü eine entsprechende Option an. Gleichzeitig wird sicher auch für leichtfertiger Benutzung dieser Option gewarnt, da man damit externen Clients aus dem Internet den Zugriff auf das lokale Netzwerk erlaubt. In unserem Fall ist das jedoch gewünscht und auch ungefährlich, wenn man bei der Konfiguration bestimmte Regeln beachtet.

Folgende Ports sollten auf dem DSL-Router für die Weiterleitung an unseren Server, also an die IP-Adresse 192.168.1.2 freigegeben werden:

• Port 80 (HTTP):
  Auf diesem Port beantwortet der Apache Anfragen zu Webseiten. Dieser Service ist ziemlich unkritisch, da er kaum mißbraucht werden kann. Der aktuelle Apache-Server ist gegen unberechtigtes Eindringen ziemlich gut geschützt.
• Port 443 (HTTPS):
  Auf diesem Port beantwortet der Apache Anfragen zu verschlüsselten Webseiten. Man benötigt diesen Port nur dann, wenn man verschlüsselte Webseiten anbieten will. Das macht zum Beispiel für einen E-Mail-Webclient durchaus Sinn. Man könnte dann auf die Öffnung des IMAP-Ports verzichten.
• Port 25 (SMTP):
  Auf diesem Port empfängt der Mailserver Nachrichten aus dem Internet. Auf dem Mailserver muss dann noch dafür gesorgt werden, dass der Mailserver nicht von Dritten zum Versand von Spam mißbraucht wird. Wie man das tut, werde ich später noch zeigen.
• Port 143 (IMAP):
  Auf diesem Port beantwortet der IMAP-Server Mailanfragen. Diese Portfreigabe wird benötigt, wenn man selbst aus dem Internet (z.B. unterwegs) Mails lesen möchte, die sich im heimischen Postfach befinden. Allerdings sollte man sich überlegen, ob die Verwendung eines E-Mail-Clients über verschlüsselte Webseiten nicht die bessere Alternative darstellt.
• Port 993 (IMAPS):
  Dieser Port stellt die SSL-verschlüsselte Version des Ports 143 dar, also die verschlüsselte Beantwortung von Mailanfragen. Auch diesen Port braucht man nur dann freizugeben, wenn man selbst aus dem Internet heraus Mails lesen will.

Die Auflistung beinhaltet nicht die Freigabe von Ports für einen FTP-Server, für den Remote-Zugriff auf der Server per SSH oder ähnliches. Die Freigabe dieser Ports funktioniert aber auf gleiche Weise. Dazu vielleicht später mehr.

Firewall-Konfiguration

Nach der Öffnung der Ports auf dem DSL-Router werden Pakete, die aus dem Internet auf den entsprechenden Ports ankommen, an unseren Server weitergeleitet. Bei nahezu allen aktuellen Linux-Distributionen kommen sie dann allerdings nicht weiter, da auf dem Server ebenfalls eine Firewall läuft, die den Server auf den betreffenden Ports standardmäßig unerreichbar macht und damit vor Angriffen schützt. In diese Firewall müssen wir nun ganz gezielt und mit etwas Vorsicht Löcher bohren.

Die meisten Linux-Firewalls verwenden das Paket IPTABLES als Firewall. Konfiguriert wird die Firewall über das Textfile iptables im Verzeichns /etc/sysconfig.Bei einem vollständig geschützten System hat diese Datei meist folgenden Inhalt:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

Ohne hier weiter ins Detail zu gehen nur eine ganz kurze Erklärung für den Inhalt. IPTABLES arbeitet mit sogenannten Chains, also Ketten, welche alle Pakete, die durch das TCP/IP-Protokoll auf dem Server verarbeitet werden, durchlaufen müssen. Im dargestellten Beispiel interessiert die Definition mit dem Namen filter, welche die Filterung eingehender Datenpakete steuert. Hier müssen wir einige Ports durchlässig machen. Dazu ergänzt man die filter-Sektion folgendermaßen:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p udp --dport 25 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p udp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 143 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 143 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p udp --dport 443 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 993 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p udp --dport 993 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Nach dieser Operation muss die Firewall des Servers neu gestartet werden, z.B. durch Eingabe des Befehls

[root@server /]# /etc/init.d/iptables restart

Anschließend sind die entsprechenden Ports auf dem Server geöffnet. Rein technisch könnten jetzt also Besucher aus dem Internet bereits Anfragen an Web- und Mailserver absenden. Höchste Zeit, die entsprechenden Dienste auf dem Server korrekt zu konfigurieren.

Apache-Konfiguration

Der erste und für die spätere Verwendung des Servers ja auch wichtigste Service ist der Apache. Er ist für die Beantwortung von Anfragen nach Webseiten verantwortlich. Nach der Installation des entsprechenden Pakets auf dem Server, welche je nach Linux-Distribution ganz unterschiedlich ablaufen kann, ist es bereits möglich den Service zu starten. Ein Aufruf des Servers im Webbrowser würde jedoch zunächst noch nichts anzeigen - bis auf eine Willkommensseite vielleicht.

Bei der Konfiguration des Apache sollte man wissen, dass dieser Webserver eigentlich beliebig viele sogenannte virtuelle Server steuert. Es gibt einen Standardserver, welcher alle Anfragen beantwortet, die von keinem anderen virtuellen Server beantwortet werden. Auf diese Weise kann ein physischer Webserver z.B. mehrere Domains betreiben, in dem für jede Domain ein eigener virtueller Server eingerichtet wird, der nur auf Anfragen zu seiner konfigurierten Domain antwortet. Dies ist aber für einen einfachen Webserver kaum notwendig. Wir beschränken uns hier auf Anpassungen in der Konfiguration des Standardservers.

Normalerweise werden in der Standardkonfiguration des Apache die Webseiten im Verzeichnis /var/www/html abgelegt. Dieses Verzeichnis wird auch als Webserver-Root bezeichnet. Jede HTML-Datei, welche hier abgelegt wird, kann über das Web über die entsprechende URL abgerufen werden. Soll das Webserver-Root auf ein anderes Verzeichnis umgelegt werden, zum Beispiel aus Ordnungsgründen, erfolgt dies in der Konfigurationsdatei des Apache httpd.conf im Verzeichnis /etc/httpd/conf. Dort gibt findet man für das Webserver-Root des Standard-Servers folgenden Eintrag

DocumentRoot /var/www/html

Eine Änderung dieses Wertes auf einen anderen Pfad bewirkt nach dem Neustart des Servers, dass Webseiten vom Standardserver an diesem Pfad gesucht werden. Der Server kann über den Befehl

[root@server /]# /etc/init.d/iptables restart

neu gestartet werden, alle vorgenommen Änderungen werden damit gültig. Man sollte jedoch mit Änderungen in der httpd.conf vorsichtig sein, der Apache bestraft selbst kleinste Schreibfehler in der Konfiguration mit sofortigem Nicht-Funktionieren. Es ist also eine gute Idee, sich vor dem Ändern der Konfiguration eine Kopie dieser Datei anzulegen.

Mail-Server-Konfiguration (Postfix)

Während die Einrichtung des Apache recht unkompliziert war - genau genommen muss man ja nur seine Webseiten an die richtige Stelle im Dateisystem kopieren und den Server starten - ist die Konfiguration des Mailservers etwas anspruchsvoller. Hier ist der Mißbrauchs des Servers viel wahrscheinlicher, daher müssen wir einige Vorkehrungen treffen.

Ich zeige die Konfiguration hier am Beispiel des Postfix-Mailservers. Vor einigen Jahren hat man dem Postfix-Server gerne den Vorzug gegenüber dem Sendmail gegeben, da dieser einige kleinere Sicherheitslöcher besaß und schwieriger zu konfigurieren war. Das mag sich heute geändert haben, ich bin jedoch beim Postfix geblieben.

Der Postfix-Server stellt im Prinzip nichts weiter als einen SMTP-Server zur Verfügung. Er muss genau eine Aufgabe erfüllen: E-Mails, die an die vom Server verwaltete(n) Domäne(n) gerichtet sind, entweder den lokalen Postfächern zuzuweisen oder weiterzuleiten. Diese Mails können aus drei verschiedenen Quellen stammen:

• einem lokalen Benutzer auf dem Server (zum Beispiel einem am Webmail-Client angemeldeten Benutzer)
• einem Benutzer im lokalen Netzwerk, der von seinem PC über den Server eine Mail versenden will
• einem Benutzer im Internet, der eine Mail über den Server versenden will

Eine funktionierende Firewall (und eine immer abgeschlossene Wohnungstür) vorausgesetzt, können wir in den ersten beiden Szenarien dem Benutzer trauen und das Versenden einer Mail zulassen. Im letzten Szenario ist jedoch Vorsicht geboten. Nicht jeder soll über den Server Nachrichten versenden dürfen, ansonsten könnte der Server allzu leicht als Spam-Server mißbraucht werden. Hier ist also etwas Arbeit notwendig. Aber eins nach dem anderen. Die meisten Einstellungen werden bei Postfix in der Datei main.cf im Verzeichnis /etc/postfix vorgenommen.

Einstellen des Domänen-Namens für ausgehende Post

Wenn von unserem Server Mails an Empfänger im Internet gesandt werden sollen, müssen einige Dinge besonders beachtet werden. Durch das heute riesige Spam-Aufkommen werden bei den meisten Mail-Providern die eingehenden Nachrichten einer Prüfung auf Authentizität unterzogen. Zu dieser Prüfung gehört unter anderem, ob die Domäne des absendenden Servers mit der Domäne des Absenders übereinstimmt. Eine Nichtübereinstimmung ist ein Hinweis auf Spam - die Nachricht wird dann oft entweder nicht zugestellt oder als Spam gekennzeichnet. Wenn von unserem Mail-Server nun Mails versendet werden, wird diese von Postfix automatisch mit dem Domänennamen des Servers im lokalen Netzwerk gekennzeichnet, also z.B. meinserver.localdomain. Gleichzeitig steht aber als Absender der Mail z.B. Diese E-Mail-Adresse ist gegen Spambots geschützt! Sie müssen JavaScript aktivieren, damit Sie sie sehen können. , weil wir diese Einstellung im Mailprogramm vorgenommen haben. Die Folge könnte wie erwähnt sein, daß die Mail vom empfangenden Server als Spam identifiziert wird - völlig unabhängig vom Inhalt. Um dies zu vermeiden, gibt es zwei Optionen in der Datei main.cf, mit der alle ausgehenden Mails automatisch als von einer bestimmten Domain kommend gekennzeichnet werden:

myorigin = meinedomain.org
masquerade_domains = meinedomain.org

Einstellen des Domänen-Namens für eingehende Post

In der Standardeinstellung stellt Postfix nur Mails an lokale Benutzer zu, die an die Domänen servername, localhost oder localhost.localdomain gerichtet sind - also intern versandte Mails. Damit auch Mails, die aus dem Netz an den Server übermitttelt werden, einem lokalen Benutzer zugestellt werden, muß die entsprechende Domäne für die Mailzustellung aktiviert werden. Das erledigt folgende Option:

mydestination = $myhostname, localhost.$mydomain, localhost, meinedomain.org

Ergänzt wurde im obigen Beispiel lediglich der Eintrag meinedomain.org.

Einstellen der für Mailweiterleitung berechtigten Clients

Diese Option ist eine der wichtigsten überhaupt. Wird hier ein Fehler gemacht, kann unter Umständen jeder Benutzer im Internet Mails über den Server versenden. Genaugenommen müssen aber nur lokale Benutzer oder ggf. Benutzer aus dem lokalen Netzwerk Mails über den Server versenden. Aus dem Internet soll niemand den Server als Relay verwenden dürfen. Diese Einstellung wird über die folgende Option vorgenommen:

relay_domains = 192.168.1.0/24

Aktivierung von Spam-Assassin als Spam-Filter

Es macht durchaus Sinn, beim heutigen Spam-Aufkommen einen Filter einzusetzen, der Mails direkt nach der Zustellung durch Postfix verarbeitet und ggf. als Spam markiert oder sogar direkt in einen Spam-Ordner im Eingangspostfach des Benutzers verschiebt. Einer der besten Spam-Filter, der genau diese Aufgabe zuverlässig und schnell erledigt, ist SpamAssassin. Es handelt sich dabei eigentlich um ein recht umfangreiches Pearl-Script, welches bei den meisten Linux-Distributionen enthalten ist und als Paket installiert werden kann.

Allerdings muss nach der Installation von SpamAssassin dem Postfix-Server noch mitgeteilt werden, dass die für lokale Benutzer bestimmte Mail nicht direkt zugestellt werden soll, sondern statt dessen zunächst an SpamAssassin weitergereicht werden soll. Dazu wird eine weitere Komponente benötigt, nämlich procmail. Dabei handelt es sich um ein weiteres Paket, welches aber bei den meisten Linux-Distributionen im Standard-Funktionsumfang enthalten sein sollte.

Zunächst stellen wir in der Postfix-Konfigurationsdatei main.cf ein, dass lokale zuzustellende Mails nicht direkt zugestellt werden, sondern an procmail weitergereicht werden. Das passiert durch folgenden Eintrag in der main.cf:

mailbox_command = /usr/bin/procmail

Im Verzeichnis /etc befindet sich die Konfigurationsdatei procmail.rc, mit der gesteuert werden kann, wie mit zu verarbeitenden Mails zu verfahren ist. Diese Datei könnte zum Beispiel folgenden Inhalt haben:

DROPPRIVS=yes
:0fw
| /usr/bin/spamc
:0
* ^X-Spam-Flag: Yes
$HOME/mail/spam

Für eine genaue Beschreibung aller möglichen Optionen sei wiederum auf den Wikipedia-Eintrag von procmail verwiesen. Hier sei nur kurz erläutert, dass die angegebenen Parameter eine Mail zunächst an das Programm /usr/bin/spamc weiterreichen. Wenn die Mail anschließend in den Kopfzeilen den Vermerk X-Spam-Flag: Yes enthält, wird sie im Mailbox-Verzeichnis des Empfängers im Verzeichnis spam abgelegt.

Konfiguration der Mail-Weiterleitung an den dynIP-Provider

Rein technisch könnte unser Mailserver - eine funktionierende DNS-Konfiguration vorausgesetzt - alle ausgehenden Mails direkt an ihre jeweiligen Empfänger senden. Praktisch ist das keine besonders gute Idee. Der Grund hierfür sind wieder einmal das hohe Spam-Aufkommen im Internet und daraus folgend die Maßnahmen, die praktisch alle großen Mailprovider dagegen unternehmen. Eine dieser Maßnahmen ist der sogenannte Reverse-Lookup, der vom Mailserver beim Empfangen einer Mail durchgeführt wird. Das folgende Beispiel zeigt leicht nachvollziehbar, was dabei passiert.

Als erstes führe ich einen Domain-Lookup meiner Mail-Domäne durch, die Eingabe:

[root@meinserver /]# nslookup meinedomain.org

liefert dabei als Antwort:

Server:         192.168.1.2
Address:        192.168.1.2#53

Non-authoritative answer:
Name:   meinedomain.org
Address: 88.73.18.202

Es wird also festgestellt, dass der Domain meinedomain.org momentan die IP-Adresse 88.73.18.202 zugewiesen ist. Jetzt führen wir eine Gegenprüfung mit folgendem Befehl durch:

[root@meinserver /]# nslookup 88.73.18.202

und erhalten diesmal als Antwort:

Server:         192.168.1.2
Address:        192.168.1.2#53

Non-authoritative answer:
202.18.73.88.in-addr.arpa       name = dslb-088-073-018-202.pools.arcor-ip.net.

Wie zu erwarten, wird die IP-Adresse nicht zur Domain meinedomain.org, sondern völlig korrekt zur Domain dslb-088-073-018-202.pools.arcor-ip.net aufgelöst, denn dort gehört die IP-Adresse ja schließlich auch hin. Dumm nur, dass deswegen direkt vom Mailserver unter dieser IP-Adresse versandte Mails kaum einmal ihren Empfänger erreichen werden, weil jeder Mailserver auf der Empfängerseite genau diese Prüfung durchführt und zu dem Ergebnis kommt, dass der Absender vorgibt, ein anderer zu sein als er ist. Im Anschluss wird die entsprechende Mail entweder gleich verworfen oder zumindest als Spam gekennzeichnet.

Das wissen natürlich auch die dynIP-Provider, weswegen viele von ihnen anbieten, die Mail über einen ihrer Mailserver zu versenden. Der Mailserver des Provider ist dabei als zweiter MX-Server im DNS-Record der jeweiligen Domain eingetragen und daher "berechtigt", Mails im Namen der Domain zu versenden.

Eine Hürde müssen wir nun allerdings noch nehmen: Natürlich lassen die dynIP-Provider auch nur für ihre Kunden den Versand von Mails über ihre Server zu. Um das zu gewährleisten, wird meist eine Anmeldung am SMTP-Server vor dem eigentlichen Versand gefordert. Diese passiert über das sogenannte smtp_auth.

Wir müssen jetzt also Postfix noch beibringen, die Mails nicht direkt zu versenden, sondern statt dessen an den Mailserver des Providers weiterzuleiten, sich bei diesem jedoch vorher per smtp_auth anzumelden. Und das geht so:

Zunächst wird in der Datei main.cf der folgende Parameter gesetzt:

relayhost = mail.meinprovider.org

Dabei ist mail.meinprovider.org selbstredend durch die korrekte Adresse des Provider-Mailservers zu ersetzen. Damit läuft zunächst mal alle ausgehende Post über diesen Server. Nun müssen wir uns noch um die Authentifizierung kümmern. Dazu sind noch folgende Zeilen in der main.cf nötig:

smtp_sasl_auth_enable=yes smtp_sasl_security_options = noanonymous smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth

Der erste Parameter schaltet smpt_auth zunächst einmal ein, die zweite unterbindet den Versuch, sich anonym am Zielserver anzumelden. Die dritte Option verweist auf eine Datei, welche den/die Benutzeranmeldungen für den SMTP-Server beim Provider enthält. Diese Datei ist standardmäßig in der Postfix-Konfiguration nicht enthalten, also legen wir sie zunächst einmal an. Sie muss dabei folgenden Inhalt haben:

mail.meinprovider.org username:password

Auch hier gilt natürlich, dass die Angaben durch die tatsächliche Adresse des Provider-Mailservers sowie die von ihm gelieferten Benutzerangaben zu ersetzen sind. Anschließend muss die Textdatei noch ins Postfix-spezifische Datenbankformat umgewandelt werden. Das passiert durch Eingabe des Befehls:

[root@meinserver /]# postmap smtp_auth

Und damit wäre die Konfiguration von Postfix auch schon beendet. Jetzt muss die gesamte Konfiguration noch aktiviert werden. Dies erfolgt mit folgendem Befehl:

[root@server /]# /etc/init.d/postfix restart

Erfahrungen im Betrieb

Wie man sehen kann, ist die Einrichtung eines Web- und Mailservers wirklich kein Problem mehr. Sicher ist das auch ein Verdienst der inzwischen viel einfacher gewordenen Installationsroutinen der Linux-Distributionen. Und natürlich kann bei der Konfiguration noch jede Menge schief gehen.

Hat man es aber einmal bis an diesen Punkt geschafft, wird man im günstigsten Fall schon einige Tage später mit einem sehr viel besseren Ranking der eigenen Seite bei Google belohnt. Und leider auch mit zahllosen Versuchen, den Mailserver als Relay zu mißbrauchen - und einem höheren Spam-Aufkommen als bisher. Letzteres liegt daran, daß die meisten Mail-Provider heute standardmäßig die Mail von bekannten Spam-Versendern sofort ausfiltern und dem Benutzer überhaupt nicht mehr zustellen. Das passiert nun nicht mehr, darum muss sich jetzt der SpamAssassin kümmern. Um die Versuche, den eigenen Server als Relay zu mißbrauchen muss man sich keine Gedanken machen, denn das haben wir ja durch die entsprechende Postfix-Option bereits ausgeschlossen.

Das Surfen auf dem eigenen Webserver funktioniert jedenfalls prima. Klar, beim Ansehen von Webseiten, die viele und große Bilder beinhalten wird der Benutzer merken, dass der Server an einer Leitung mit geringer Bandbreite angeschlossen ist. Das zwingt einen aber letztlich nur zu einem angenehm spartanischen Webdesign ohne große Bilder und ressourcenfressende Flash-Intros.