Der eigene Linux-Server kann im 19-Zoll-Rack eines Hosters stehen oder aus einer Platine im Format eines Raspberry Pi bestehen: Sobald der Server an einem Netzwerk teilnimmt, sind Vorkehrungen zur Serversicherheit Pflicht.
Ein Linux-System ist nicht per se sicher, nur weil es den Linux-Kernel und bewährte Open-Source-Programme kombiniert. Ein System kann nur so nur sicher sein wie seine Konfiguration. Die größten Lücken werden nicht von genialen Hackern gerissen, sondern durch die Nachlässigkeit des Administrators.
Ein-Platinen-Computer wie der Raspberry Pi haben den Aufwand erheblich gesenkt, von zu Hause aus
einen kleinen Linux-Server
zu betreiben. Virtuelle Serverinstanzen bei Massenhostern erlauben den Betrieb eines Serversystems mit richtig schneller Internetanbindung für wenige Euro im Monat und bieten dabei volle Kontrolle für root – wie ein physikalisches System.
Sozialverträgliche Kosten bedeuten aber nicht, dass es damit auch einfach geworden ist, einen Server sicher zu betreiben. Auch wenn zum Serverbetrieb geeignete Linux-Distributionen wie
Debian
,
Ubuntu Server
,
Open Suse
oder
Cent-OS
mit einer sinnvollen Basiskonfiguration ausgeliefert werden, so müssen angehende Linux-Administratoren doch selbst einige Sicherheitsvorkehrungen treffen. Auch wenn der Server im Internet nur wenig Dienste für den eigenen Bedarf anbietet oder der heimische Miniserver nur an einer DSL-Leitung hängt und über eine dynamischen Hostadresse erreichbar ist, werden hin und wieder ungebetene Besucher anklopfen und Einlass begehren.
Dahinter stecken selten gezielte Angriffe, sondern automatisierte Scans, die nach dem Zufallsprinzip einen Adressbereich abklappern, um nach häufigen Sicherheitslücken und Einfallstoren zu suchen. Zu einfach sollte man es diesen Wegelagerern nicht machen, denn diese sind inzwischen gut vernetzt: Die Suchmaschine
Shodan
beispielsweise sucht mit Crawlern aktiv nach Routern, allen Sorten von Internet-of-Things-Geräten und von außen erreichbaren Raspberry-Pi-Platinen. Das Python-Script „
Autosploit
“ kombiniert die Suchergebnisse von Shodan mit dem Metasploit-Framework und macht es so auch wenig versierten Hackern einfach, Exploit-Scripts gegen Hunderte von Adressen anzuwenden. Wer seinen Linux-Server korrekt konfiguriert und mit Updates versorgt, hat allerdings wenig zu befürchten.
1. Administration: Nur mit sudo
Ein fester Bestandteil jeder Linux-Distribution ist das von Unix geerbte sudo, kurz für „substitute user do“. Das Programm erlaubt einem Benutzer, Befehle im Kontext eines anderen Benutzerkontos auszuführen, beispielsweise als root. Der Vorteil: Eine Anmeldung als allmächtiger root-User ist dazu nicht nötig und sollte im Anschluss auch gleich deaktiviert werden. Für die Verwendung von sudo muss das root-Passwort nicht bekannt sein. Es genügt zur Systempflege ein gewöhnliches Benutzerkonto, das in der Konfiguration von sudo spezifiziert sein muss, um Programme und Befehle in der Shell gezielt mit root-Privilegien ausführen zu dürfen.
Tipp:
Grundlegende Befehle für Linux-Server
Ubuntu brachte sudo einem großen Anwenderkreis näher, denn bei dieser Distribution ist es vorkonfiguriert und die Anmeldung als root ist schlicht deaktiviert, damit Anwender gar nicht erst auf die Idee kommen, den root-Account zu nutzen. Raspbian folgt diesem Beispiel und stattet den Standardbenutzer „pi“ mit sudo aus. Bei Cent-OS gibt es während der Installation die Option „Diesen Benutzer zum Administrator machen“ und bei Open Suse „Dieses Passwort für den Systemadministrator verwenden“, um das ersterstellte Benutzerkonto gleich für sudo freizuschalten.
Die Konfiguration von sudo liegt in der Datei „/etc/sudoers“ vor, wobei eine manuelle Anpassung dieser Datei mit dem Editorbefehl visudo erfolgen sollte, da dieser die korrekte Syntax beim Speichern überprüft. Über den root-Account ruft man den Editor zur ersten Konfiguration mit dem Kommando
su -c "visudo"
auf. Die Definition von Benutzerprivilegien erfolgt ganz am Ende der Datei nach dem folgenden Schema
[benutzer] ALL=(ALL:ALL)
wobei der Platzhalter „[benutzer]“ für den tatsächlichen Kontonamen steht. In Ubuntu/ Debian/Raspbian ist in der Datei schon die Gruppe „sudo“ eingetragen und es genügt, weitere Benutzer einfach mittels des Befehls
usermod -a -G sudo [Benutzername] in diese Gruppe aufzunehmen, um sie damit für den Einsatz von sudo freizuschalten.
2. Tür zu! Kein Zugang für root
Server werden üblicherweise über SSH gepflegt, eine grafische Oberfläche direkt am Server oder über VNC ist eher die Ausnahme. Bei SSH kommt es darauf an, dass alle Benutzerkonten sichere, komplexe Passwörter haben. Standardaccounts wie root sollten über SSH nicht zugänglich sein, um es Angreifern nicht unnötig leicht zu machen (die mit „root“ schon mal einen Anmeldungsbestandteil, nämlich den Benutzernamen wüssten).
Damit man sich nicht selbst aussperrt, ist es wichtig, sich erst davon zu überzeugen, dass sudo funktioniert beziehungsweise su mit dem bekannten root-Passwort zum root-Konto wechselt. Besteht darüber kein Zweifel, kann man die Konfiguration des SSH-Diensts in der Datei „/etc/ssh/sshd_ config“ anpassen und mit der Zeile
PermitRootLogin no
die SSH-Anmeldung für root verbieten. Die Änderung ist nach einem Neustart des SSH-Dienstes aktiv, was beispielsweise in Debian/Raspbian/ Ubuntu der Befehl
sudo service ssh restart erledigt. In den Distributionen Cent- OS und Open Suse lautet der Dienstname „sshd“ statt „ssh“.
Türsteher: Der SSH Guard
Automatisierte Angriffe per Wörterbuchattacken auf den SSH-Port des Servers prallen nach diesen ersten Maßnahmen schon zuverlässig ab. Bei mehreren Hundert gescheiterten Verbindungsversuchen täglich wird das Access-Logfile aber unübersichtlich. Dagegen ist ein Kraut gewachsen: SSH Guard ist ein Wächterdienst, der wiederholt gescheiterte Anmeldeversuche anhand deren ausgehender IP-Adresse abblockt und dabei auch IPv6 unterstützt. In Ubuntu, Debian und Raspbian ist der Dienst mit
sudo apt-get install sshguard
eingerichtet und sofort aktiv.
3. Automatisierte und regelmäßige Updates
Ein Linux-System kann sehr sicher sein, solange es regelmäßig Updates erhält. Denn auch ein vorbildlich konfiguriertes Linux-System kann durch neu entdeckte Bugs angreifbar werden. Obwohl die Paketmanager ein Systemupdate sehr komfortabel machen, werden Aktualisierungen im Alltag aber doch gerne mal aufgeschoben. Für Server bietet sich eine unbeaufsichtigte Aktualisierung im Hintergrund an, die neue, als Sicherheitsupdates markierte Pakete regelmäßig einspielt.
Mit grafischer Oberfläche: Viele unterschiedliche Linux-Oberflächen stehen bereit, aber alle stellen dem Nutzer auch die Kommandozeile zur Verfügung.
zur Bildergalerie-GroßansichtDebian, Raspbian und Ubuntu: Die Scripts für unbeaufsichtigte Updates installiert dieser Terminalbefehl:
sudo apt-get install unattended-upgrades
Danach verlangt das System nur noch kleinere Anpassungen. Rufen Sie das Konfigurationsscript mit
sudo dpkg-reconfigure --priority=low unattended-upgrades
auf, und beantworten Sie die Rückfrage nach dem automatischen Herunterladen und Installieren mit „Ja“. Die benötigten Einträge für einen täglichen Cronjob, der um 6:25 Uhr ausgeführt wird, erstellt das Konfigurationsscript nun selbständig. Testen können Sie dies mit diesem Befehl:
sudo unattended-upgrades --dry-run -d 
Die Logdatei „/var/log/unattended-upgrades/unattended-upgrades.log“ protokolliert die Updates. Eine komplette Distributionsaktualisierung, die auch geänderte Abhängigkeiten unter Paketen beachtet, müssen Sie hin und wieder mit
sudo apt-get dist-upgrade manuell ausführen.
Ratgeber:
Linux ist sicher - stimmt das wirklich?
Cent-OS:
Im Klon von Red Hat Enterprise Linux gibt es das Paket „yumcron“, das unbeaufsichtigte Updates aktiviert. Sie installieren es mit
sudo yum install yum-cron
und finden die zugehörige kommentierte Konfiguration unter „/etc/yum/ yum-cron.conf“. Per Standard holt das Script alle Aktualisierungen – nicht nur Sicherheitsupdates. Mit
sudo systemctl enable yum-cron.service sudo systemctl enable yum-cron.service
schalten Sie den Dienst für Updates ein.
Open Suse:
Egal ob Server oder Desktop – die Konfiguration eines Open-Suse-Systems erfolgt mit dem Tool
Yast
, das auch als textbasierte Version auf der Kommandozeile zur Verfügung steht. Um diese Version zu nutzen, installieren Sie zuerst mit dem Kommando
sudo zypper install yast2-onlineupdate- configuration
das Yast-Modul für automatische Updates und rufen dann Yast mit
sudo yast in der Shell auf. Dann gehen Sie im Yast-Menü auf „Software -> Konfiguration der Online-Aktualisierung“ und schalten dort mit „Automatische Online- Aktualisierungen“ (Tastenkombination Alt-A) die Updates ein und wählen das Intervall. Voreingestellt sind wöchentliche Updates.
Firmware: Auch Server brauchen Updates
Ein oft unterschätztes Risiko sind die Router selbst, die zur Anbindung des heimischen Servers ans Internet dienen und damit den eingehenden Datenverkehr regeln und per NAT (Network Address Translation) an die Teilnehmer im lokalen Netzwerk vermitteln. Nicht selten schlummern in der Firmware älterer Router Sicherheitslücken, die Einbrüche von außen, von der Internetverbindung aus ermöglichen. Eine gravierende Lücke betrifft aktiviertes UPnP (Universal Plug and Play), mit dem der Router Geräten und Programmen im LAN erlaubt, Ports nach außen automatisch zu öffnen. Diese Lücken wurden 2013 bekannt, aus Sicherheitsgründen von den Entdeckern aber damals nicht veröffentlicht, da Millionen von Routern verwundbar waren, etwa der damals immens populäre Cisco Linksys WRT54GL .
Inzwischen hat sich der Schleier der Geheimhaltung gelüftet und die Studie von 2013 ist
hier
veröffentlicht. Alte Router, für die es seit Jahren kein Firmwareupdate mehr gab, sind schlimmstenfalls genau für die UPnP-Lücke anfällig und sollten ausgemustert werden.
4. Paketfilter: Eigene Firewallregeln erstellen
Überflüssige Serverdienste mit offenen Ports sollten auf keinem System laufen. Trotzdem kann es vorkommen, dass eine versehentlich installierte oder noch nicht fertig eingerichtete Serverkomponente unerwünscht Ports öffnet. Dagegen hilft der Paketfilter von Linux, der sehr detaillierte Regeln für Netzwerkpakete erlaubt.
Debian, Raspbian und Ubuntu machen es heute mit dem Tool ufw einfach, Regeln für das nicht ganz triviale Kernel-Modul Iptables zu erstellen. Das Tool für die Kommandozeile ist mit
sudo apt-get install ufw
schnell installiert und hört auf eine sehr einfache Syntax. Um beispielsweise Verkehr von außen an die Ports 22 (SSH), 80 (HTTP) und 443 (HTTPS) durchzulassen, genügen diese drei einfachen Befehle:
sudo ufw allow 22 sudo ufw allow 80 sudo ufw allow 443
Anschließend wird die Firewall mit
sudo ufw enable
gestartet und mit
sudo ufw status überprüft.
Cent-OS:
Auch von Red Hat gibt es ein Konfigurationstool für Iptables in der Kommandozeile, das über sudo yum install system-configfirewall-tui schnell installiert ist. Der Befehl
sudo system-config-firewall-tui
startet das recht bequeme Tool, das einfache Firewallregeln über Dienstnamen unter der Option „Anpassen“ aktivieren kann.
Open Suse:
Eine Konfiguration für die Firewall ist in Yast von Haus aus enthalten und erfolgt über die Menüs von Yast im Textmodus. Die vergleichsweise umfangreichen Einstellungen öffnet das Menü „Sicherheit und Benutzer -> Firewall“. Unter „Erlaubte Dienste“ lassen sich gestattete Serverdienste per Namen hinzufügen, und über „Start“ wird die Firewall dann aktiviert.
Generell ist große Vorsicht geboten, dass zumindest SSH auf seinem Standardport 22 zur Fernwartung erlaubt ist und man sich nicht durch allzu strenge Regeln selbst aussperrt.
Router: Nur benötigte Ports öffnen
Wer heimische Datenserver nur im lokalen Netz betreibt, bietet keine Angriffsfläche via Internet. Sicherheitskritisch sind hingegen Linux-Server oder Platinenrechner, die zu Hause stehen und per Router ins Internet gehen. Deshalb kommt auch erst einmal die richtige Routerkonfiguration an die Reihe. Der Router ist es nämlich, der per Portweiterleitung den Zugang von außen auf einen Dienst im lokalen Netzwerk öffnet. Der Router dient zugleich als Firewall, die nur den Netzwerkverkehr auf die erlaubten Ports durchlassen soll. Einige Router bieten in ihrer Konfiguration die Möglichkeit, einen „Exposed Host“ beziehungsweise eine DMZ (Demilitarisierte Zone) einzurichten, um alle Anfragen ungefiltert an die angegebene Serveradresse im lokalen Netzwerk weiterzuleiten.
Diese Lösung scheint bequem, da man sich dann über die einzelnen Ports angebotener Dienste keine Gedanken machen muss. Sie kommt aber keinesfalls in Betracht: Der Server wäre damit völlig exponiert – ein unnötiges Risiko. Deshalb leitet man via Router besser ganz gezielt jene Ports an den Server im heimischen Netzwerk weiter, die dieser auch wirklich bedienen soll: Für den Wartungszugang per SSH brauchen Sie nur eine Weiterleitung von Port 22, HTTP verlangt Port 80 und HTTPS Port 443. Die Konfiguration einer Firewall mit iptables oder einem Hilfsprogramm wie ufw auf dem Linux-System kann dann entfallen.
5. Logwatch: Die Logdateien im Blick
Jedes Linux-System protokolliert etliche Prozesse und Leistungsdaten in seinem Logsystem und hilft damit bei der Problemanalyse. Weil es nicht einfach ist, alle relevanten Logs stets im Auge zu behalten, gibt es das Tool logwatch, das einen verkürzten Bericht als Zusammenfassung erstellt und per Mail an einen Empfänger senden kann. Empfehlenswert ist die Einrichtung dieser Berichte bei Servern, die wichtige Aufgaben erfüllen. Bei reinen Heimservern grenzt der Einsatz von logwatch dagegen schon an paranoiden Overkill.
Debian, Raspbian, Ubuntu, Cent- OS und Open Suse bieten alle das Paket „logwatch“ in ihren Paketquellen. In Debian und seinen Derivaten wird es beispielsweise mit
sudo apt-get install logwatch installiert. In seinen Standardeinstellungen trägt sich logwatch als täglicher Cronjob unter „/etc/cron.daily“ ein und legt seine Konfiguration unter „/usr/share/logwatch/default.conf/logwatch. conf“ ab. Diese Konfigurationsdatei gilt es noch anzupassen. Öffnen Sie die Datei mit sudo in einen Texteditor, gehen Sie zur Zeile „MailTo = root“ und tragen Sie statt root die gewünschte E-Mail-Adresse ein.
Tipp: So analysieren Sie Ihren Linux-Server
Zugangsdaten: Nur verschlüsselt anmelden
Es ist inzwischen zum großen Tabu geworden, im Internet mit unverschlüsselten Login-Daten zu arbeiten. Unverschlüsselte Protokolle wie FTP zur Datenübertragung oder HTTP zur Anmeldung auf Webseiten sind ein hohes Risiko.
Wer vom heimischen Server aus Webdienste anbietet, die ein Log-in erfordern, muss unbedingt auf die Verschlüsselung per HTTPS achten. Dazu benötigt der Webserver ein SSL-Zertifikat, das in die Webserver-Konfiguration eingebunden wird. Für den Eigenbedarf reicht ein selbst signiertes Zertifikat aus, das man sich selbst ausstellen kann. Bei dynamischen Domainnamen für den Router gibt es sowieso keine zuverlässige Alternative, da man dafür nicht einfach SSL-Zertifikate bekommt. Auf einem Ubuntu/Debian/Raspbian statten folgende Schritte einen Apache-2-Webserver mit einem selbst signierten Zertifikat und mit HTTPS aus:
1.
Das selbst signierte Zertifikat und dessen Dateien erstellt dieser Befehl:
sudo openssl req -x509 -nodes -days 720 -newkey rsa:2048 -keyout /etc/ssl/certs/apache.key -out /etc/ssl/certs/apache.crt
Das dabei angezeigte Frageformular können Sie mit beliebigen Angaben ausfüllen.
2.
Der Webserver Apache liefert schon eine Standardkonfiguration für SSL mit, die in der Datei „/etc/apache2/sites-available/ default-ssl“ vorliegt. Mit einem beliebigen Texteditor wie Nano tauschen Sie die Zeile
SSL-CertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
gegen
SSL-CertificateFile /etc/ssl/certs/apache.key
aus sowie darunter die Zeile
SSL-CertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
Gegen diesen Eintrag:
SSL-CertificateFile /etc/ssl/certs/apache.key
3.
Die gerade bearbeitete und gespeicherte Datei „default-ssl“ repräsentiert in Apache eine neue „Site“, die dann folgendes Kommando aktiviert:
sudo a2ensite default-ssl
4.
Bevor Apache einen Port für HTTPS öffnen kann, müssen Sie noch das SSL-Modul von Apache mit dem Kommando
sudo a2enmod ssl
einschalten und anschließend den Webserver selbst mit
sudo service apache2 force-reload
neu starten. Falls ein Konfigurationsfehler auftritt, wird sich Apache jetzt mit einer Meldung beschweren. Die Warnung „Could not reliably determine the server’s fully qualified domain name“ kann man indes ignorieren.
5.
Bei einem ersten Aufruf des Webservers mit einem Browser über „https://[Server- Adresse]“ zeigt der Browser einen Warnhinweis über ein ungültiges Zertifikat an. Denn das eigene Zertifikat ist nicht durch eine zentrale Zertifizierungsstelle (CA) signiert und aktuelle Webbrowser stufen die Verbindung zunächst daher als nicht vertrauenswürdig ein.
Die Verbindung ist aber trotzdem sicher verschlüsselt. In den üblichen Browsern wie Firefox und Chrome/Chromium müssen Sie nur einmalig eine Ausnahme für das eigene Zertifikat und für den genutzten Domainnamen gestatten.
7. Unbeschränkte Zugriffsrechte finden
Ein Schritt, der sich am Ende der gesamten Serverkonfiguration empfiehlt, wenn bereits der Webserver und alle Dienste laufen, ist eine systematische Suche nach Dateien und Verzeichnissen mit zu laxen Zugriffsrechten. Wer keine Gruppen für gemeinsame Zugriffsrechte für Verzeichnisse und Dateien einrichtet, behilft sich oft mit einer simplen, aber unsicheren Abkürzung: Dateien bekommen kurzerhand die Zugriffsrechte 666 oder gar 777 zugewiesen und Verzeichnisse die Rechte 777. Damit sind Lese- und Schreibberechtigungen effektiv ausgehebelt, da alle Welt Vollzugriff auf diese Dateisystemobjekte hat.
Auf einem Server ist dies keine gute Idee und schlicht ein Konfigurationsfehler, auch wenn nachlässig geschriebene Anleitungen diese Rechte oft empfehlen. Denn auch unprivilegierte Benutzer und eigentlich abgeschottete Serverdienste könnten diese Dateien und Verzeichnisse manipulieren. Sie können Dateien und Verzeichnisse mit unbeschränkten Zugriffsrechten einfach ausfindig machen und benötigen dazu noch nicht mal root-Rechte.
Das Kommando
find / -path /proc -prune -o -type f -perm 666
findet alle Dateien im gesamten Dateisystem, ausgenommen „/proc“, die von allen gelesen und beschrieben werden dürfen. Ferner listet
find / -path /proc -prune -o -type f -perm 777
alle Dateien auf, die dazu noch ausführbar sind. Genauso findet
find / -path /proc -prune -o -type d -perm 777
Verzeichnisse, die zum Lesen und Schreiben offenstehen.
Anstatt für Dateien und Verzeichnisse uneingeschränkten Vollzugriff zu setzen, ist es besser, Gruppen für gemeinsam genutzte Dateien zu verwenden. Der Befehl
chgrp [Gruppe] [Datei/Verzeichnis] ändert die Gruppe für Dateisystemobjekte. Für den Vollzugriff für Besitzer und Gruppe genügen dann bei Verzeichnissen die Rechte 770 sowie bei Dateien 660.
Zum Abschluss: Wenn Ihnen dieser Beitrag geholfen hat, interessieren Sie sich vielleicht auch für die umgekehrte Perspektive: Nicht was man tun sollte, um einen Linux-Server abzusichern, sondern welche Fehler man auch vermeiden sollte, wird in diesem Ratgeber erklärt.
Serveradministration: Pannen und Sünden
Auch wenn es absolute Sicherheit auf Servern mit Internetanbindung nicht gibt, so sollte man es potenziellen Angreifern so schwer wie möglich machen. Die folgenden Konfigurationspannen treten häufiger auf, oft erst nach längerer Laufzeit im Dauerbetrieb.
– Einfache Passwörter:
Alle Passwörter, nicht nur jene von root, müssen ausreichend komplex sein.
– Keine Updates:
Auch wenn es selten vorkommt, so hat auch bewährte Open-Source-Software bisweilen Sicherheitslücken. Regelmäßige Updates des Systems sind Pflicht.
– Unverschlüsselte Protokolle:
Sobald Benutzer-Log-ins übertragen werden, darf dies nur über verschlüsselnde Protokolle wie SSH, HTTPS oder bei Dateiübertragung per SFTP geschehen.
– Obsolete Linux-Distributionen:
Reguläre Distributionen erreichen schon nach wenigen Monaten das Ende ihres Wartungszyklus. Für Server kommen deshalb nur Distributionen mit Langzeitsupport in Frage.
– PHP-Software zu alt:
PHP hat sich als schnell zu erlernende Script-Sprache im Web durchgesetzt, aber Sicherheit bekommt von den PHP-Entwicklern, wenn überhaupt, oft nur wenig Aufmerksamkeit. Jedes PHP-Projekt muss akribisch auf dem neusten Stand gehalten werden.
– Ungepflegte Webserver:
Vergessene Konfigurationsdateien, unsichere Zugriffsrechte auf Verzeichnisse oder fehlende SSL-Zertifikate lassen einen Webserver zu viel ausplaudern.
– Offenstehende Datenbanken:
Eine Menge PHP-Projekte laufen mit einer Datenbank wie Maria DB oder My SQL im Rücken. Auch die Konten der Datenbank inklusive Datenbank-Rootzugang brauchen ein sicheres Passwort.
Linux für jeden Zweck und jeden Anwender - der große Überblick(Bild 1 von 75)
AntiX Linux: Oldie-gerecht Ein sehr ressourcenschonendes Debian-Derivat und auch für antike Rechner geeignet. AntiX Linux beansprucht 256 MB RAM sollte vorhanden sein, ein Pentium-3-Prozessor sollte ausreichen. Als Fenster-Manager ist Fluxbox vorhanden. Für Web-Surfer steht der Iceweasel-Browser bereit, Debians Version des Firefox-Browsers.
AntiX Linux: Oldie-gerecht zur Bildergalerie-Großansicht