Der Raspberry Pi als Server

Vorstellung

Nun liegt das gute Stück rum. Viel gespielt und viel probiert, jetzt soll er was (scheinbar) Nützliches tun. Als Helfer im Netzwerk kann der Pi verschiedene Dienstleistungen übernehmen.

Die geringen Anschaffungs- und Betriebskosten prädestinieren ihn für Experimente im lokalen Netzwerk. Solange Dienste ausschließlich hinter dem eigenen Router laufen und man den Usern im Lan vertrauen kann, bleibt das Ganze harmlos. Hegt man allerdings den Wunsch, die Dienste auch über das Internet anzubieten, wird es riskant.

Folgende Services laufen auf diesem RasPi 2:

  • Webserver (nginx)
  • Dateiserver (seafile)
  • Druckserver (cups)

Mit seiner geringen Leistungsaufnahme von ca. 3 Watt kann der Pi im Dauerbetrieb laufen. Energiekosten von etwa 10€ pro Jahr sollten im Budget des Bastlers Makers verfügbar sein.

Der Raspberry wird ausschließlich über das Netzwerk verbunden, kein Anschluss von Tastatur oder Monitor. PC-OS ist ein Linux-Mint. Die Bedienung und Steuerung des Servers erfolgt über den SSH-Client im PC. Im Prinzip funktioniert es auch unter Windows, nur komplizierter, aber das sind M$-User ja gewohnt.

Der Webserver nginx

NGINX (Engine-X) ist ein modular aufgebauter, schlanker Webserver. Bei überschaubaren Besucherzahlen stellt der Pi 2/3 genügend Leistung für einen flüssigen Betrieb zur Verfügung. Eine Alternative wäre das Schwergewicht Apache.


Installation

Bei der weiteren Installation wird von einer frischen Raspbian-Lite-Installation ausgegangen. Das System ist aktualisiert und eingerichtet.

Die Installation von NGINX erfolgt aus den Paketquellen. Zur späteren Einbindung von php-Scripten wird der FastCGI Process Manager gleich mit installiert.

sudo apt-get install nginx php-fpm

Damit sollte nginx bereits auf Port 80 lauschen, Test:

netstat -tulpen
Active Internet connections (only servers)
[...]
tcp     0    0 0.0.0.0:80     0.0.0.0:*    LISTEN
tcp     0    0 0.0.0.0:22     0.0.0.0:*    LISTEN
tcp6    0    0 :::80          :::*         LISTEN
tcp6    0    0 :::22          :::*         LISTEN
[...] 


In der Adresszeile des Browsers eingeben:

http://raspi5
NGINX sollte sich jetzt mit Welcome to nginx on Debian melden.


Der Server wird per default während des Bootens gestartet. Wichtige Befehle:

sudo nginx           #Start nginx
sudo nginx -s stop   #Stop nginx
sudo nginx -s reload #Einlesen einer neuen Konfiguration 


Erste Experimente beim Umgestalten der Default-Webseite sind möglich:

sudo nano /var/www/html/index.nginx-debian.html
[...]
<b> Hello NGINX</b>
[...]

Der richtige Weg ist aber natürlich ein Anderer.

Die eigene Homepage

Was NGINX wissen muss

Bevor es an die Gestaltung einer Homepage geht, muss NGINX erst mal erklärt werden, worauf er hören soll, wo er die auszuliefernden Daten findet und was er damit anfangen soll. Die Konfiguration erfolgt im Grundsatz in der Datei /etc/nginx/nginx.conf , die aber unverändert bleiben sollte, solange kein trifftiger Grund dafür besteht. Wichtig darin ist die Zeile:

http {
    [...]
    include /etc/nginx/sites-enabled/*;
    [...]
}
die aussagt: Binde alle Dateien aus diesem Verzeichnis in die Konfiguration innerhalb des http-Kontext ein.

In diesem Verzeichnis sollten wiederum nur Verweise auf die config-Daten liegen. Für die eigentlichen Dateien wurde bei der Installation von NGINX das Verzeichnis /etc/nginx/sites-available/ angelegt. Hier kann man sich mit Konfigurationen austoben, Backups anlegen, etc. Verknüpft nach /etc/nginx/sites-enabled/ werden nur die jeweils aktuellen Versionen. Für alle Dateien in diesen Verzeichnissen sollte nur der User root Schreibrechte besitzen. NGINX läuft mit den Rechten des Users www-data, der die Dateien lesen, aber keinesfalls ändern darf.

Konfiguriert werden sogenannte virtuelle Server, z.B.

server {
    listen       80;
    server_name  raspi5 192.168.0.105;
    root         /var/www/myhomepage;
    index        index.html;

    location / {
        try_files $uri $uri/ =404;        
    }
}

Datei anlegen und Server-Konfiguration eintragen

sudo nano /etc/nginx/sites-available/homepage

Symbolischen Link zum neuen Server anlegen

sudo ln -s /etc/nginx/sites-available/homepage /etc/nginx/sites-enabled/homepage

NGINX-Konfiguration neu einlesen

sudo nginx -s reload

Bei der Installation von nginx wurde bereits der virtuelle Server default eingerichtet. Dorthin werden alle Verbindungsversuche mit unbekanntem URL umgeleitet, die den Server aus aus irgendeinem Grund erreicht haben. Dieser Eintrag sollte bestehen bleiben.




Inhalt der Website

Per Konfiguration erwartet NGINX die Daten der Homepage in der Datei /var/www/homepage/index.html. Diese Datei muss natürlich angelegt und gefüllt werden.
Beispielgrundgerüste in html5 sind im Internet zuhauf zu finden. Bspw. kann diese Datei kopiert und als index.html auf dem PC gespeichert werden.

Auf dem Pi das Webroot-Verzeichnis anlegen und dem User pi zuordnen.

sudo mkdir /var/www/myhome
sudo chown -R pi:pi /var/www/myhome

Damit ist sichergestellt, dass pi Daten hochladen darf, aber www-data keine Dateien manipulieren kann. Erst wenn Daten über den Server geschrieben werden sollen, müssen die Rechte von Dateien oder Verzeichnissen angepasst werden.

Hochladen der Beispielwebseite vom PC:

rsync -a ./index.html pi@raspi5:/var/www/myhome
(rsync muss auf PC und Pi installiert sein !)

... und im Browser testen

http://raspi5
http://192.168.0.105


Die Seiten von Selfhtml sind eine gute Ausgangsbasis für eigene Experimente.


Der Weg nach Draußen

Wer kennt das nicht. Man sitzt wochenlang in aufopferungsvoller Arbeit vor dem Rechner, hat endlich seine Webseite zum Laufen bekommen, aber die Anerkennung im lokalen Netzwerk bleibt versagt. Was liegt also näher, als seine Erfahrungen mit Leuten zu teilen, die die Mühe zu schätzen wissen.

Ein Server im privaten Umfeld wird i.A. hinter einem Router betrieben, der über eine DSL-Leitung zum Internetprovider verbunden ist. Um den externen Zugriff auf die bereitgestellten Dienste des Raspberry zu ermöglichen, sind in dieser Konfiguration einige Hürden zu überwinden.

  • die Paketzustellung durch den Router
  • die Adresse im Internet (IP - Adresse)
  • der Name im Internet (Domain-Name)
  • Sicherheitsbedenken über Board werfen


1. Der Router

Der Router regelt die Kommunikation zwischen den Rechnern des lokalen und des öffentlichen Netzwerkes. Per default sollten nur Datenpakete aus dem Internet nach Innen passieren dürfen, die erwartet werden und eindeutig zuordenbar sind. Diese Bedingung ist erfüllt, wenn eine Verbindung von Innen (Client) initiiert und von Außen (Server) beantwortet wird.

Verbindungsversuche zu einem Server im LAN wird der Router blockieren, zumal er ohnehin nicht wüsste, an welchen der Rechner er die Anfrage weiterleiten soll. Um Verbindungsanfragen aus dem Internet zu ermöglichen, muss im Router das Port-Forwarding eingerichtet werden. Anfragen aus dem öffentlichen Netz wird der Router dann an einen bestimmten Rechner im LAN auf dem zugewiesenen Port weiterleiten. Für den Betrieb eines Webservers müssen i.d.R. der Port 80 (http) und der Port 443 (https) freigegeben werden. Zwingend erforderlich ist dafür der administrative Zugriff auf den Router.

An dieser Stelle sollte man sich bewusst sein, dass damit ein wichtiger Sicherheitsmechanismus für das lokale Netzwerk aufgegeben wird. Im Internet ist zuhauf Gelichter auf der Suche nach angreifbaren Diensten unterwegs. Sollte es bspw. jemandem gelingen, den Server als Verteiler für illegale Inhalte zu kapern, könnte dies für den Betreiber strafrechtliche Konsequenzen nach sich ziehen. Daher muss man sich erst mit dem Thema Serversicherheit beschäftigen, bevor man Löcher in seinen Router bohrt.

Die Funktion, die der Router beim Weiterleiten der Datenpakete in beiden Richtungen ausführt, wird als NAT (Network Adress Translation) bezeichnet. Er manipuliert dabei die Adressfelder und ersetzt die öffentliche mit der privaten Adresse und umgekehrt. Solange Zugriff auf die Routereinstellungen besteht und Port Forwarding möglich ist, stellt dies kein Problem dar.

Allerdings gibt es Provider, die ihrerseits ein NAT vorschalten und die öffentlichen Adressen in ihren privaten Adressbereich übersetzen. Ein Beispiel hierfür ist das Mobilfunknetz von Vodafone. Andere Provider dürften Ähnliches praktizieren. Der Betrieb eines Servers hinter einem solchen Anschluss ist nicht möglich.

Einfach testen lässt sich dies, indem die vom Provider zugewiesene IP-Adresse ermittelt und mit der im Router angezeigten öffentlichen Adresse verglichen wird. Bei unterschiedlichen Werten hat man verloren.

Die Einrichtung des Port-Forwarding unterscheidet sich je nach Routermodell. Bei der Fritz!Box bspw:

→ Internet → Freigaben → Portfreigaben → Neue Portfreigabe

Freizugeben sind die Ports 80 und 443. Bei Bedarf kann auch Port 22 für die Security Shell über das Internet geöffnet werden. Es ist allerdings erstaunlich, wie viele Angriffe auf diesen Port durch o.g. Gelichter täglich gefahren werden, um Zugriff auf den Server zu erlangen. Einen Überblick dazu verschafft das Logfile /var/log/auth.log. Um dem Gesindel die Arbeit etwas zu erschweren, lässt sich der ssh-Dienst auf einen anderen Port umlegen.

Wenn die Portfreigaben funktionieren, sollte der Server jetzt via

http://öffentliche IP-Adresse
erreichbar sein. Die eigene IP-Adresse verrät der Router oder Dienste wie https://ip-info.org. Das setzt allerdings voraus, dass unter nginx ein virtueller Default-Server eingerichtet ist, auf den alle unbekannten URLs umgeleitet werden.


2. Die IP-Adresse

Die Erreichbarkeit von Rechnern im Netzwerk wird über IP-Adressen geregelt. Der Service-Provider weist dem eigenen Router bei der Verbindungsaufnahme eine willkürliche Adresse aus seinem IP-Pool zu. DSL-Verbindungen werden zu allem Überfluss durch den Provider hin und wieder getrennt und neu verbunden. Damit wird jedes mal eine neue IP-Adresse zugewiesen. Vodafone trennt Verbindungen alle ein bis zehn Tage. Die Häufigkeit scheint im Zusammenhang mit der übertragenen Datenmenge zu stehen.

Damit ist die Erreichbarkeit eines Servers über die IP-Adresse unpraktikabel. Glücklicherweise werden Dienste im Internet i.A. ohnehin über einen Domainnamen angesprochen. Die Zuordnung der variierenden IP-Adresse zu einer Domain übernehmen sogenannte DynDNS-Services. Diese Dienste sind teilweise frei verfügbar, dann aber mehr oder weniger nervig oder aber kostenpflichtig.

Gut dran sind Betreiber einer Fritzbox. Die Firma AVM stellt jedem Nutzer eines solchen Gerätes eine Subdomain wie koezxnfnu5abcxyz.myfritz.net kostenlos zur Verfügung und ordnet diesem Namen über den hauseigenen DynDNS die wechselnde IP-Adresse der Fritzbox zu. Gedacht ist das Ganze natürlich nicht für Server-Experimente, sondern zur Erreichbarkeit des Routers für Serviceeinstellungen über das Internet. Eine Möglichkeit, auf die man aus Sicherheitsgründen tunlichst verzichten sollte.

Einfach ein MyFRITZ!-Konto einrichten – fertig. Bis zur Einrichtung und Zuordnung im DNS kann einige Zeit vergehen. Der Erfolg kann geprüft werden mit:

ping koezxnfnu5abcxyz.myfritz.net

Sobald diese Subdomain zur eigenen IP-Adresse aufgelöst wird, ist der Punkt geschafft. Der Default-Server sollte jetzt erreichbar sein:

http://koezxnfnu5abcxyz.myfritz.net

An dieser Stelle könnte ein virtueller Server unter nginx mit dieser Subdomain (server_name) eingerichtet werden und die Homepage wäre unter dieser Adresse erreichbar. Für den privaten, internen Betrieb sicher völlig ausreichend, sodass man sich Punkt 3 sparen könnte.

An dieser Stelle sollte noch erwähnt werden, dass sich die Darstellung auf die Protokollversion IPv4 bezieht. Unter IPv6 werden die Karten neu gemischt.


3. Der Name

Aber wer möchte schon jemandem zumuten, eine Adresse wie http://koezxnfnu5abcxyz.myfritz.net einzutippen. Eine vernünftige Domain also muss her. Nach Anschaffungs- und Stromkosten gehen die Experimente hier zum ersten mal wieder ins Geld.

Domain-Hoster gibt es auf dem Markt wie Sand am Meer. Bei der Auswahl ist ein Blick in die Vertragsbedingungen geboten. Wie lange binde ich mich? Wieviel kostet die Dienstleistung nach der Billigphase?

Technisch entscheidend ist die Möglichkeit, dass dieser Domain ein weiterer Domainname (der der FritzBox) zugeordnet werden kann. Im DNS ist dies über den CNAME Resource Record möglich. Der Hoster muss einen entsprechenden Eintrag über seine Konfigurationseinstellungen zulassen.

Aufgrund anderer Verträge ist meine Wahl auf 1&1 gefallen. Der eigentlichen Domain lässt sich zwar kein CNAME RR zuordnen. Es ist aber möglich, beliebig viele Subdomains anzulegen, wie bspw. www.mydomain.de. Dieser Subdomain wird der CNAME RR http://koezxnfnu5abcxyz.myfritz.net der Fritzbox zugewiesen.

Die Domain mydomain.de selbst kann über die DNS-Konfiguration bei 1&1 auf die Subdomain umgeleitet werden, sodass über diesen Umweg auch bei Eingabe von

http://mydomain.de
der Pi-Server erreicht wird. Allerdings ist auch hier Geduld angesagt. Also keine Sorge, wenn das nicht sofort funktioniert.

ping www.mydomain.de
verrät, wann der Name zur IP-Adresse zugeordnet wurde. Zum Test muss die Subdomain verwendet werden, da die Namensauflösung von mydomain.de weiterhin zur IP-Adresse des Hosters erfolgt.

Um die richtige Seite im Webserver zu erreichen, muss unter nginx noch der virtuelle Server für die neue Subdomain eingerichtet werden:

server {
    listen       80;
    server_name  www.mydomain.de;
    [...]
}

Geschafft !!! Nun sollte unser Server aus dem Internet erreichbar sein.

Mit der eigenen Domain ist man nun allerdings auffind- und identifizierbar. Seriöse Hoster leiten persönliche Daten wie Name, Adresse, email und Telefonnummer an die Registrierungsstelle weiter, wo sie veröffentlicht werden. Mit der Anonymität ist es an dieser Stelle vorbei. Wer dies nicht möchte, kann bei der kryptischen Fritzbox-Subdomain bleiben.

Mit der Registrierung einer Domain ist auch eine Flut von Spammails diverser Webdesigner verbunden, die Ihre Dienstleistungen anbieten.




3a. Vorsicht Falle

Wie so oft bei Onlineverträgen ist die Bestellung einer Domain schnell erledigt und die Gebühren werden pünktlich abgebucht. Geht es allerdings ans kündigen, gilt es Fußangeln zu überwinden.

Hier ein Beispiel zur Abwicklung einer .de-Domain bei Strato:
Mit Registrierung einer .de-Domain bei dem Provider werden gleichzeitig zwei Verträge geschlossen, einer mit dem Provider über Serviceleistungen und einer mit DENIC für die Verwaltung der Domain.
Kündigt man die Domain beim Provider, scheint die Welt in Ordnung. Es trifft eine email mit der Bestätigung der Löschung und dem Termin des Vertragsendes ein. Beachtung sollte der letzten Satz der email finden (Zitat aus der Strato-email):

Wenn Sie eine .de, .at oder .uk Domain besitzen, geben wir die Domain in diesem Fall an die zuständige Registrierungsstelle zurück. Gegebenfalls setzt sich diese später mit Ihnen in Verbindung, um das weitere Vorgehen bzgl. der Domain zu klären.

Na gut, könnte man meinen, sollen sie sich doch bei mir melden, gekündigt ist gekündigt. Aber das ist ein Irrtum !
Mit der Kündigung bei Strato ist es nicht getan. Der Vertrag mit DENIC besteht weiterhin. Zwei Monate nach Vertragsende trifft per Briefpost von DENIC ein Schreiben ein, dass ich (als Domaininhaber) mich nun entscheiden solle, wie mit der Domain zu verfahren sei. Ohne weiteren Löschauftrag oder Providerwechsel wird die Verwaltung nach vier weiteren Wochen gebührenpflichtig durch DENIC übernommen (58€ für das erste Jahr). Vertraglich ist das bestimmt korrekt. Irgendwo im Kleingedruckten wird's schon so stehen. Nochmal online bei DENIC gekündigt und dann ist (hoffentlich) alles gut.

Falls jemand allerdings auf die Idee gekommen sein sollte, seine Adressdaten (illegalerweise) gegenüber DENIC zu verfälschen, um nicht mit jeder WhoIs-Abfrage auf dem Präsentierteller zu stehen oder einfach nur umgezogen ist, den wird diese Post nicht erreichen. Und da anscheinend keine Infos per email vorausgehen, könnte die Frist verstreichen und sich daraus eine Zahlungspflicht ergeben.

Also, Augen auf und/oder das Kleingedruckte lesen !




4. Sicherheitsbedenken über Board werfen ?

Natürlich nicht, sondern nachdenken! Wer einen Root-Server im Internet betreibt, macht sich angreifbar. Fehlerhafte Software, ein schlecht gewartetes System oder falsche Konfiguration können es Eindringlingen ermöglichen, den Raspberry zu kapern. Auch wenn das Teil wie ein Spielzeug aussieht, unterscheidet es sich doch in Funktion und Leistungsfähigkeit kaum von den V-Servern namhafter Provider.

Pflicht für den Admin ist mindestens:

  • Konfiguration prüfen
  • System regelmäßig aktualisieren
  • Logfiles prüfen
  • auf ungewöhnliche Aktivitäten reagieren

Ansonsten bedarf es noch einer gehörigen Portion Vertrauen in die Fähigkeiten der Programmierer. In Opensource-Software ist kaum mit Hintertüren zu rechnen, aber Schwachstellen können das Gesamtsystem gefährden. Betrachtungen zum Thema Serversicherheit sind etliche im Netz zu finden.

Besonderes Augenmerk ist auf die Konfiguration von nginx zu legen. Auch hier sind im Netz sehr viele Informationen zu bekommen, leider aber auch falsche. Die Einstellungen müssen zum eigenen Dienst passen, sodass es mit der Übernahme einer Standard-Config nicht getan ist.

Ob man sich den Risken aussetzen möchte, muss jeder für sich entscheiden. Aber was soll's. Jeder weiß, dass das Leben gefährlich ist und man steht trotzdem frühmorgens auf.


Blacklist

Gundsätzlich sind Besucher einer Webseite willkommen. Auch gegen Robots von Google & Co., die des Öfteren vorbei schauen, ist nichts einzuwenden. Stellt man als Admin an Hand der Log-Files aber ein merkwürdiges Surfverhalten einzelner IPs fest, kommt der Wunsch auf, diese Adressen oder Adressbereiche per Blacklist auszusperren.

Bei der Installation von nginx wurde bereits folgender Wildcard-Eintrag in /etc/nginx/nginx.conf angelegt:

http {
    [...]
    include /etc/nginx/conf.d/*.conf;
    [...]
}

Innerhalb des http-Context lassen sich IP-Adressen mit den Directiven deny | allow sperren oder freigeben. Es muss lediglich eine Datei bspw. /etc/nginx/conf.d/blacklist.conf mit den gewünschten Regeln angelegt und anschließend die Configuration neu eingelesen werden.

sudo nano /etc/nginx/conf.d/blacklist.conf
# einzelne IP-Adressen sperren
deny    46.4.113.114;

# Beispiel Adressbereiche sperren
# deny  46.4.113.0/24;
sudo nginx -s reload

Ergebnis für den Besucher ist ein 403 Forbidden. Das Ganze ist natürlich nur sinnvoll bei festen IP-Adressen der Angreifer und bei überschaubarem Datenaufkommen. Die Directiven lassen sich auch in den Contexten von server und location anwenden und damit feiner differenzieren. Nur die Übersicht sollte man dabei nicht verlieren.


nach oben