Anleitung: Linux-Server rundherum absichern

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.

Cent-OS 7: Der erste angelegte Benutzer wird mit der Option „Diesen Benutzer zum Administrator machen“ für sudo freigeschaltet.

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.

Reservierte Konten mit bekannten Namen wie „root“ sollten bei Linux-Servern im Internet über SSH gar nicht erst erreichbar sein.

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.

Oder nur mit der Shell: — Der Nutzer muss wie hier bei einer reiner Server-Distribution alle Kommandos mit Hilfe der Shell absetzen.

Installation ohne viel Grafik — Die Installation einiger Linux-Servers (hier die Ubuntu-Variante) bietet eine Oberfläche, die mittels einfacher Grafik leichter zu bedienen ist.

Setzen des Root-Kennworts: — Bei den Ubuntu-Distributionen ist zwar der Superuser angelegt, aber ihm muss noch mit Hilfe des “sudo”-Kommandos ein Passwort zugewiesen werden.

Linux-Dateisystem auf die grafische Art. — Linux-Distributionen, die mit einer grafischen Oberfläche arbeiten, stellen dem Nutzer in der Regel auch einen Dateimanager zur Verfügung.

Das Dateisystem aus der Sicht der Shell: — Wenn der Administrator nur mit der Shell arbeitet (hier in einem xterm-Fenster) kann er mit dem “ls”-Befehl eine erste Übersicht über das Dateisystem bekommen.

Hilfe immer direkt parat: — Durch den Einsatz des “man”-Kommandos kann der Nutzer jederzeit Hilfe zu den Linux-Befehlen finden und bekommt so beispielsweise auch die zu verwendenden Argumente eines Befehls aufgelistet

Zugriffsrechte im Dateisystem: — Der “ls”-Befehl zeigt dem Nutzer, wer welche Arbeiten auf eine Datei oder ein Verzeichnis ausführen darf. Mit Hilfe von “chmod” wurden hier die Zugriffsrechte für alle Nutzer auf “Nur lesen” gesetzt.

Prozesse im Griff mit dem — Der “ps”-Befehl kann auf fast allen Distributionen (hier unter Fedora Linux) mit unterschiedlichen Ausprägungen der übergebenen Argumente aufgerufen werden.

Debian, 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

Debian-und Ubuntu-Systeme bieten dieses unkomplizierte Konfigurationsscript für regelmäßige, unbeaufsichtigte Aktualisierungen per Cronjob.

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.

Für die Kommandozeile gibt es unter dieser Serverdistribution das unkomplizierte textbasierte Werkzeug system-config-firewall-tui.

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.

Die Firewallkonfiguration wirkt anspruchsvoll, erlaubt aber auch die Auswahl von Diensten anhand des Namens.

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.

Das Perl-Programm logwatch schickt täglich diese kurze Zusammenfassung der Serverlogs an die angegebene Mailadresse – empfehlenswert für wichtige Server.

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

Webbrowser weisen deutlich darauf hin, wenn ein Zertifikat keine CA-Signatur hat.

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.