Seit geraumer Zeit schlage ich mich mit dem Gedanken herum, meine
Webseite auf einen eigenen Rootserver umzuziehen. Hauptgrund ist dabei
die Möglichkeit den gesamten Verkehr über https laufen zu lassen (Let's
Encrypt lässt grüßen :-) ) und darüber hinaus auch automatisiert
regelmäßige Backups anlegen zu können. Ersteres lässt sich mein
momentaner Webspaceanbieter nämlich fürstlich bezahlen, Letzteres war
bisher von mir nur sporadisch gepflegt worden da man Backups nur manuell
in der Administrationsoberfläche anstoßen konnte.
Das Mehr an Flexibilität (den Spaß nicht zu vergessen :-) ) geht jedoch
einher mit einem gestiegenen Wartungsaufwand sowie einem hohen Maß an
Verantwortung; schließlich ist man auch direkt verantwortlich, wenn der
Server gekapert wird, weil man ihn nicht richtig abgesichert hat und nun
Amok läuft. Entscheiden musste ich mich letztendlich nur noch, ob ich
mir einen eigenen kleinen Server zu Hause hinstelle oder ob ich etwas
Passendes miete. Nach einigem hin und her habe ich mich dann für die
Mietoption entschieden, jedoch statt eines echten physischen Servers
"nur" einen virtualisierten gemietet. Zum einen war mir ein
ausgewachsener Rootserver mit 8-Kern-CPU und Gigabytes voll RAM dann
doch 'ne Nummer zu oversized für meine Bedürfnisse, zum anderen zahlt
man für solche Rechenknechte auch ein hübsches Sümmchen monatlich. Da
bieten gerade die kleineren vServer eine gute Mischung aus Preis und
verfügbarer Leistung und sollten für kleinere Projekte vollkommen
ausreichen. Gesagt getan, der
Server war
bestellt und schon nach 5 (!) Minuten bekam ich die Mail mit den
Zugangsdaten. Und das am Freitag Abend nach 19 Uhr; Respekt :-)
Erste Schritte
Mit den Zugangsdaten kann man sich nun via SSH auf dem Server als root
einloggen. Das erste, was man auf jeden Fall tun sollte ist das Passwort
zu ändern:
da der Server bei Auslieferung noch auf Englisch gestellt war, habe ich
ihn kurzerhand auf Deutsch umgestellt:
#: dpkg-reconfigure locales
dort die entsprechenden locales auswählen und dann mittels
generieren. Da ich nicht gerne ständig im root-Kontext arbeite erstelle
ich mir gleich einen eigenen Benutzer
SSH-Dienst absichern
Neben einer Firewall wohl der wichtigste Punkt. Momentan kann man sich
via SSH mittels Passwort anmelden und auch root kann sich dort anmelden.
Um auch hier ein gesteigertes Maß an Sicherheit zu bekommen, sollte man
auf jeden Fall den SSH-Login auf Publickey Authentication umstellen und
die Anmeldung via Passwort unterbinden; darüber hinaus sollte es dem
root user nicht erlaubt sein, sich überhaupt per SSH einzuloggen. Die
einzelnen Punkte habe ich
hier schonmal
beschrieben.
Firewall einrichten
Der nächste Punkt auf der Liste ist die Einrichtung einer Firewall, wenn
man nicht will, das die Serverdienste munter und unkontrolliert mit der
Außenwelt kommunizieren können. Ich setze dabei auf die 'uncomplicated
firewall' bzw. 'ufw', die ein leicht zu bedienendes Frontend für
iptables bietet. Als erstes erstellen wir eine Standardregel und
verbieten grundsätzlich alles, danach erlauben wir speziell den
ssh-Dienst und dann schalten wir noch das logging ein:
#: ufw default deny
#: ufw allow ssh
#: ufw logging on
fail2ban
Ich hatte den Server keine halbe Stunde und schon klopften die ersten
Idioten an die Tür, wie mir ein Blick in die Datei
verrät. Standardmäßig haben sie beliebig viele Versuche um reinzukommen.
Um das einzuschränken, bietet sich fail2ban an. Dieses nützliche, in
Python geschriebene Programm, scant periodisch verschiedene Logdateien
nach verdächtigen Inhalten (z.B. mehrfach gescheiterte Login-Versuche
pro IP) und sperrt bspw. eine IP-Adresse nach zuvielen gescheiterten
Loginversuchen. Den Status eines 'jails' kann man jederzeit via
#: fail2ban-client status ssh
abrufen.
Fazit
Ich denke, wenn man diese Punkte erst einmal abgearbeitet hat, hat man
seinen Server schon ein bedeutendes Maß sicherer gemacht und kann nachts
etwas ruhiger schlafen. Absolute Sicherheit gibt es leider nicht, daher
sollte man seinen Server regelmäßig kritisch beobachten und vor allem
regelmäßg Sicherheitsaktualisierungen einspielen.
Seit geraumer Zeit betreibe ich einen kleinen stromsparenden Server, der
auch über das Internet von überall mittels ssh erreichbar ist. Dieser
dient mir als Zugangspunkt zu meinem Heimnetzwerk, falls ich doch einmal
eine bestimmte Datei o. Ä. unterwegs brauche. Um diesen abzusichern,
sollte man die Standardkonfiguration ein wenig anpassen. Die
Konfigurationsdatei für den SSH-Server findet man unter
'/etc/ssh/sshd_config'.
Port umlegen
Standardmäßig arbeitet der SSH-Server auf dem Port 22. Das ist leider
auch so ziemlich jedem klar, der mit dem Begriff "SSH" etwas anfangen
kann. Was liegt also näher, als einfach einen anderen - möglichst von
keinem anderen Dienst belegten Port - einzustellen. Dazu trägt man in
der 'sshd_config' folgendes ein:
Einziger Nachteil ist, dass man von nun an beim Aufruf von ssh mit der
Option -p explizit den Port angeben muss. Allerdings bietet die Umlegung
des Ports allein keinen wirklichen Sicherheitsgewinn. Ein vollständiger
Portscan würde relativ schnell den richtigen Port enttarnen.
$ ssh -p 12345 user@serveradress.de
Rootlogin verbieten
Auf jeden Fall sollte man die Anmeldung als Root verbieten. So muss ein
potentieller Angreifer nicht nur das Passwort, sondern auch gleich noch
den richtigen Benutzernamen erraten. Um die Anmeldung als Root zu
verbieten muss die Option
...
Permit RootLogin no
...
gesetzt werden. Danach kann man sich nur noch mit einem "normalen" User
anmelden.
SSH-Keypair erzeugen
Wesentlich sicherer als die Eingabe eines bloßen Passwort ist die
Authentifizierung mittels RSA-Key. Dabei wird auf dem Client ein Private
Key und ein Public Key erzeugt und der Public Key anschließend auf den
Server transferiert. Die Erstellung eines RSA-Schlüsselpaars geschieht
über:
Danach kopiert man mittels folgendem Befehl den Schlüssel auf den
Server:
$ ssh-copy-id user@serveradress.de
Von nun an wird man bei der Authentifizierung immer nach der
RSA-Passphrase des RSA-Schlüssels gefragt, statt nach einem regulären
Passwort.
Passwortbasierte Anmeldung verhindern
Hat man einmal eine solche Authentifizierung eingerichtet, kann man
gleich auch die passwortbasierte Anmeldung unterbinden. Der Vorteil ist,
dass sich jetzt nur noch derjenige anmelden kann, der über den passenden
Schlüssel verfügt. Dazu muss man nur folgende Option setzen:
...
PasswortAuthentication no
...
Der Nachteil ist, dass man nun auf seinen private-Key Acht geben muss
und ihn irgendwo sicher aufbewahren muss. Hat man physisch keinen
Zugriff auf den Server, hilft bei Verlust des Schlüssels nur noch ein
trauriger Anruf beim Hoster.
StrictHostKeyChecking
Hat man einmal die Authentifizierung mittels RSA-Keys eingerichtet, ist
man im Prinzip schon recht gut abgesichert gegen Personen, die auf dem
Server nichts zu suchen haben. Hat man allerdings seinen Private-Key
verloren ist es prinzipiell dem Finder möglich sich auf dem Server
einzuloggen (falls er die richtige Passphrase für den Private Key
kennt). Zugegeben, dass sind schon recht viele Wenn's, aber 'Unverhofft
kommt oft :-)'Jedenfalls kann man zusätzlich noch das Strict Host Key
Checking aktivieren. Dazu setzt man folgende Option:
...
StrictHostKeyChecking yes
...
Das bewirkt, dass sich nur dem Server bereits bekannte Hosts anmelden
dürfen. Dabei wird der Client-Host-Key mit denjenigen Keys in der Datei
'\~/.ssh/known_hosts' bzw. '/etc/ssh/known_hosts' abgeglichen.
Fazit
Mit diesen relativ einfachen Mitteln hat man gegenüber der
Standardkonfiguration schon einiges an zusätzlicher Sicherheit gewonnen.
Absolute Sicherheit wird es wohl leider nie geben, sodass man auch
weiterhin Serverlast und die Log-Files auf Unstimmigkeiten überwachen
sollte. Man kann also nur hoffen, dass man es einem potentiellen
Angreifer so schwer wie möglich macht und dass dieser sich dann lieber
weniger aufwändigen Zielen zuwendet.
Lange habe ich hin und her überlegt ob ich mir einen Raspberry
Pi zu legen soll.
Mittlerweile haben immer mehr Leute in meinem Umkreis ein solches Gerät
und betreiben es mit xbmc direkt am Fernseher. Leistungstechnisch ist
der Pi nicht so der Hammer; in etwa vergleichbar mit einem Pentium II
mit 300 MhZ. Unschlagbar dagegen ist er allerdings im Stromverbrauch.
Das prädestiniert ihn direkt für einen 24/7 Betrieb als kleiner
Heimserver.
Installiert habe ich Raspian, ein etwas
angepasstes Debian-Wheezy. Die Installation war in einer guten Stunde
erledigt (wobei der Download und das kopieren auf die SD-Card am
längsten gedauert haben). Einfach das fertige Image
herunterladen, entpacken und
mittels "dd if=/pfad/zum/Image of=/dev/SD-Card bs=4M" auf die SD-Karte
schreiben. Fertig. Nun noch rebooten und schon ist der Pi einsatzbereit.
Wie man sieht läuft noch nicht ganz so viel; was sich aber in der
nächsten Zeit ändern wird :-)
Es ist auf jeden Fall ein sehr interessantes Gerät. Für das was ich
vorhabe hat der Pi auf jeden Fall genug Leistung und ist dazu auch nicht
so energiehungrig.