12 trin til en Linux Apache MySQL PHP web server roden LAMP sikkert

Die Hacking-Frequenz ist in den letzten Monaten stark angestiegen. Besonders viele Daten werden abgegriffen durch Hacks auf Webserver. Sogar der SONY-PSN-Hack nutzte Schwachstellen in einem ungepatchten Apache-Webserver. Deshalb sammele ich hier Maßnahmen, die den eigenen Server etwas sicherer gegen Angriffe von außen machen können. Natürlich bieten auch diese keinen 100%igen Schutz, aber es ist besser, den bösen Buben das Spiel ein wenig schwieriger zu machen. Einige der Maßnahmen benötigen nur einen minimalen Installations- und Wartungsaufwand. Andere benötigen viel Zeit und Kenntnisse von PHP um zu greifen. Man sollte immer auf das Kosten-Nutzen-Verhältnis bei der Auswahl der Sicherheitsmaßnahmen achten. Es macht keinen Sinn, eine kleine, private Website so abzusichern wie die Federal Reserve Bank. Allerdings können wenige gezielte Änderungen am System bereits ein großes Mehr an Sicherheit bedeuten. Und das sollte man sich schon gönnen, bevor es zu spät ist....

Alle Tipps und Codesnips beziehen sich auf eine aktuelle Debian-Kiste.

Første Die Firewall - erst einmal alles verbieten

Die meisten Linux-Distributionen öffnen in ihren Standardinstallationen keine Ports nach außen, die nicht unbedingt notwendig sind. Diese Situation kann man jedoch schnell selbst ändern, wenn man am Server
herumspielt und Dinge ausprobiert. Plötzlich lauscht auch der Mediaserver im Internet oder die Datenbank
nimmt Verbindungen aus dem Internet entgegen. Deshalb ist es nicht verkehrt sich selbst zu disziplinieren und eine sehr restriktive Firewall aufzusetzen, die grundsätzlich erst einmal alle Verbindungen von außen verbietet und nur (selbst) ausgewählte Verbindungen gestattet. Zum Glück ist das mit iptables schnell erledigt. Auf diese Art und Weise kann man nicht mehr aus versehen Dienste der Welt zugänglich machen, die dort nichts zu suchen haben. Man bezahlt leider mit etwas Komfort - die Firewall muss jedes Mal angepasst werden, wenn man neue Dienste anbieten möchte. Trotzdem ist der Aufwand klein und der Nutzen groß.

#!/bin/bash

# Bestehende Tables löschen
iptables -F

# Alle eingehenden Verbindungen verbieten
iptables -P INPUT DROP
iptables -P FORWARD DROP

# Alle ausgehenden erlauben
iptables -P OUTPUT ACCEPT

# SSH erlauben
iptables -A INPUT -j ACCEPT -p tcp --dport 22 

# HTTP erlauben
iptables -A INPUT -j ACCEPT -p tcp --dport 80 

# Weiteren Dienst (UDP) erlauben, zum Beispiel Gameserver
iptables -A INPUT -j ACCEPT -p udp --dport 4534 

# Alles von Localhost erlauben. (Damit der Server selbst ungehindert auf seine Dienste zugreifen kann,
# zum Beispiel PHP auf die lokale Datenbank
iptables -A INPUT -j ACCEPT -s 127.0.0.1

# Bereits aufgebaute Verbindungen werden an jedem Port akzeptiert
# (Notwendig für manche Daemons)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Dieses kleine Grundgerüst kann man einfach weiter ausbauen und eigene Dienste hinzufügen. Bei Arbeiten an der Firewall sollte man immer für den Fall vorsorgen, dass man sich selbst aussperrt. Besonders bei Remote-Servern, auf die man keinen physischen Zugriff hat, ist es sehr ärgerlich, durch eine mißglückte Firewallregel den eigenen Zugriff zu verlieren. Um diesem Problem aus dem Weg zu gehen, kann man bei Arbeiten an der Firewall einfach temporär einen Cronjob starten lassen, der die Firewall alle paar Minuten zurücksetzt oder den Server neu startet. Sind die Regeln später getestet und geliebt, kann der Cronjob wieder deaktiviert werden und die neuen Regeln bleiben permanent aktiv.

Um herauszufinden, welche Dienste gerade auf dem eigenen Server herumlauschen, kann man netstat benutzen:

#Für TCP-Sockets:
netstat -lpn | grep tcp

#Analog für UDP:
netstat -lpn | grep udp

Um zu testen ob die Firewall wirklich funktioniert, kann man den eigenen Server von einem anderen Rechner aus portscannen. Hat alles geklappt, sollten im Ergebnis nur die selbst geöffneten Ports auftauchen:

#Für TCP:
nmap -p1-65535 meinserver.de

#Für UDP:
nmap -sU -p1-65535 meinserver.de

2. SSH Logins verbieten

Am eigenen root-Server hat man uneingeschränkten SSH-Zugriff. Das ist recht praktisch, da man von jedem SSH-Client aus mal eben auf den Server kann um an ihm zu arbeiten. Der Nachteil davon ist, dass das natürlich auch jeder andere kann, der unglücklicher Weise irgendwie an das eigene Passwort gelangt ist. Es ist viel sicherer SSH-Logins nur mit einer gültigen Schlüsseldatei zu erlauben. Dafür wird der öffentliche Schlüssel des Clients auf den Server kopiert und interaktive Logins per Passworteingabe werden deaktiviert.

# Auf dem Client einen öffentlichen Schlüssel erstellen
# Wird bei der Generierung ein Passwort angegeben, benötigt man zum
# einloggen später die Schlüsseldatei UND das Passwort. Ansonsten wird
# nur der Schlüssel benötigt.

ssh-keygen -t rsa

# Den erstellten Schlüssel danach auf den Server kopieren

ssh-copy-id -i ~/.ssh/id_rsa.pub root@meinserver.de

# Danach auf dem Server /etc/ssh/sshd_config anpassen
 .
 .
PasswordAuthentication no
 .
 .

# Danach SSh neu starten
/etc/init.d/ssh restart

Auch hier sollte man Vorkehrungen treffen, um sich nicht selbst auszusperren, falls etwas nicht funktioniert.
Der Public Key auf einem USB-Stick mit dem dazugehörigen Passwort im eigenen Kopf macht es sehr viel schwerer für böse Buben eine Shell zu erhalten.

Tredje SSH Bruteforcing verhindern mit denyhosts

Falls Tipp 2 nicht praktikabel ist und man den Komfort von passwortgestützten Logins nicht aufgeben will, kann man zumindest das automatisierte Passwortraten von Angreifern auf dem Server verhindern. Sehr viele Bots im Internet machen den ganzen Tag nichts anderes als nach SSH-Servern zu suchen und bei Ihnen verschiedenste Passwörter durchzuprobieren. Mit einem halbwegs sicheren Passwort ist das kein großes Problem, trotzdem gibt es ein besseres Gefühl, wenn nicht einmal das möglich ist. Außerdem schützt man so auch seine User, falls auf dem Server auch Useraccounts bestehen. Hier kann man sich nicht darauf verlassen, dass die Benutzer sichere Passwörter verwenden. denyhosts überprüft ständig Logins auf dem ssh und sperrt Benutzer für eine gewisse Zeit, die ihr Passwort wiederholt falsch angegeben haben. Die IP's dieser Nutzer landen temporär in /etc/hosts.deny, so dass für sie kein Zugriff mehr möglich ist. Damit wird SSH-Bruteforcing zu einer sehr langwierigen und wenig erfolgversprechenden Aufgabe.

apt-get install denyhosts

# denyhosts funktioniert direkt nach der Installation. Man kann es
# in der Datei /etc/denyhosts.conf feintunen

4. Blacklisten benutzen, um bekannte Problem-IPs auszusperren

Im Internet werden verschiedene Blacklisten gepflegt, die eine große Anzahl von kriminellen/gehackten/spammenden/betrügerischen Servern auflisten. Diese IP-Listen können direkt in die Firewall eingetragen werden, so dass von diesen bekanntermaßen nicht vertrauenswürdigen Rechnern überhaupt keine Verbindung mehr zum eigenen Server möglich ist. So kann man das Spamaufkommen auf dem eigenen Server drastisch verringern und auch das eine oder andere Script-Kiddie aussperren, weil sein Russland-Proxy plötzlich nicht mehr funktioniert. Wie man das macht habe ich bereits in einem anderen Blog-Artikel am Beispiel der Blacklist von Infiltrated.net beschrieben.

5. Kein FTP benutzen für die Arbeit am Server

FTP ist ein Relikt aus besseren Zeiten in denen das Internet noch ein kleines vertrauenswürdiges Dörfchen war. Viele Admins von Webseiten nutzen nach wie vor FTP um Dateien zum Server zu übertragen oder um an der eigenen Website zu arbeiten. Das ist leider sehr unsicher, da FTP alle Daten ungesichert übertragt. Passwörter und Daten können an jedem Hop zwischen Server und Client ohne Probleme mitgelesen werden. Viel sicherer geht es mit sshfs. Hiermit kann man sich per SSH ein Verzeichnis des Remote-Servers in sein lokales Dateisystem mounten. Man kann danach auf dem Server so arbeiten, als sei er auf dem lokalen Rechner. Alle Dateizugriffe auf Dateien auf dem Server sind komplett transparant, man kann also auch mit dem lokalen Grafikprogramm ein Bild auf dem Server direkt öffnen, bearbeiten und wieder speichern. Mehr Komfort und mehr Sicherheit ohne großen Aufwand.

#sshfs installieren
apt-get install sshfs

#mountpoint im lokalen Dateisystem anlegen
mkdir /media/meinserver

#Server ins lokale Dateisystem mounten
sshfs www-data@mein-server.de:/var/www /media/meinserver

#Nun ist das Verzeichnis /var/www auf meinserver lokal unter /media/meinserver verfügbar

6. Updates installieren

Ein super abgesichertes System hilft nichts, wenn das System selbst fehlerhaft ist und eine bekannte Sicherheitslücke ausgenutzt werden kann. Meist werden diese Sicherheitslücken schnell geschlossen, oft vergessen Admins jedoch regelmäßige Updates des Systems zu machen. Ob man automatische Updates auf Linux-Servern aktivieren sollte oder nicht ist ein strittiges Thema. Einige würden es niemals tun, da es natürlich mit viel Pech auch sein kann, dass die Updates das System unbrauchbar machen. Dies ist mir in über 10 Jahren Arbeit an Debian-Systemen allerdings niemals passiert und ich schätze den Nutzen von zeitnahen und regelmässigen Updates viel höher ein, als die daraus entstehende Gefahr.

#Diese Zeile in der /etc/crontab aktualisiert das System täglich um 6 Uhr morgens
0 6 * * * root apt-get update && apt-get -y upgrade

Diese Quick-and-dirty Methode funktionierte bei mir bisher immer gut. Vor kurzem habe ich gelesen, dass im Debian Repository auch das Paket unattended-upgrades existiert, das die Aufgabe wohl etwas eleganter löst, ich habe es allerdings bisher nicht getestet.

Auch bei diesen vollautomtischen Systemupdates ist man nicht komplett aus dem Schneider. Falls ein Kernel-Update ausgeliefert wurde, muss man das System trotzdem noch per Hand neu booten, da ansonsten die Änderungen nicht aktiv werden.

Benutzt man fremden PHP-Code auf dem Server, wie zum Beispiel ein Open-Source CMS oder ein Forum, ist es natürlich absolut notwendig auch diesen Code mit neuen Versionen aktuell zu halten. Da Debian mit seinen Updates Änderungen an diesen Applikationen in der Regeln nicht abdeckt, ist hier Handarbeit nötig. Am besten liest man die Mailinglisten der entsprechenden Produkte mit um immer auf dem Laufenden zu sein.

7. PHP einsperren mit open_basedir

Viele Hacks basieren darauf, dass eine Sicherheitslücke im PHP-Code ausgenutzt wird, um auf Dateien im Dateisystem zuzugreifen, die nicht zur Website gehören, sondern zum System selbst. Deshalb sollte man PHP einsperren, so dass es nur in explizit erlaubten Verzeichnissen lesen und schreiben darf. Dafür bietet die php.ini die Konfigurationsoption open_basedir. PHP hat nach setzten der Option nur noch Zugriff auf die dort erlaubten Verzeichnisse. Dateien wie /etc/passwd werden unerreichbar. Hostet man auf einem Server mehrere Webseiten sollte man open_basedir in der jeweiligen VirtualHost-Konfiguration pro Seite setzen.

# Global per php.ini:
# /etc/php5/apache2/php.ini
open_basedir = /var/www/:/tmp/

# Per Site in der VirtualHost Config:
php_value open_basedir /var/www/site/:/tmp/

Wichtig ist zu prüfen ob wirklich alle Orte eingetragen wurden, auf die die Skripte normalerweise Zugriff haben müssen, ansonsten kann es sein, dass man auch legitime Funktionen der PHP-Applikation behindert.

8. Für Websites einen eigenen MySQL-Benutzer anlegen

Benutzt die eigene PHP-Applikation MySQL, sollte man unbedingt für die Apllikation einen eigenen MySQL-Benutzer anlegen und auf keinen Fall den MySQL-root-Benutzer für Zugriffe nutzen. Außerdem sollte man die Rechte des Benutzers so weit einschränken, dass wirklich nur noch Operationen erlaubt sind, die das PHP-Skript benötigt. CREATE TABLE und DROP TABLE werden zum Beispiel häufig bei SQL-Injections genutzt und werden in den meisten PHP-Applikationen nie benötigt. Hostet man mehrere Websites mit mehreren Datenbanken auf einem Server, sollte man für alle Datenbanken eigene Benutzer anlegen. So hat ein Angreifer nach einem erfolgreichen Angriff nur Zugriff auf eine der Datenbanken und nicht direkt auf alle. Wenn man nicht die Kommandozeile bemühen möchte, um die MySQL-Useraccounts zu verwalten, funktioniert das Usermanagement auch recht einfach mit PHPmyAdmin unter der Registerkarte "Rechte".

9. PHP Fehlermeldungen abschalten

PHP-Fehlermeldungen können einem Angreifer viel über den eigenen Server verraten: Verzeichnisstrukturen, Datenbankstrukturen, Konfigurationsfehler, etc. Außerdem sehen sie für den Benutzer sehr unprofessionell aus. Aus diesem Grund sollte man sie auf einem Live-Webserver grundsätzlich abschalten, da man sie ohnehin weiterhin in den Logs sehen kann.

# Global per php.ini:
# /etc/php5/apache2/php.ini
display_errors = Off

# Per Site in der VirtualHost Config:
php_flag display_errors Off

# Fehlermeldungen trotzdem lesen:
cat /var/log/apache2/error.log | grep PHP

10. Angriffsfläche für SQL-Injections einschränken mit modSecurity

SQL-injections sind die wohl am häufigsten genutzte Angriffsmethode auf Webserver. Der Zugriff erfolgt direkt über die Webapplikation und es genügt ein Browser um sie durchzuführen. Dabei werden über vom User übermittelte Variablen geschickt SQL-Abfragen eingebaut, die mit den Rechten des Datenbankbenutzers alles an der eigenen Datenbank nach belieben auslesen, löschen oder bearbeiten können. Ein wirklicher echter Schutz gegen SQL-Injections besteht nur, wenn der PHP-Code der Site im Hinblick auf diese Angriffe geschrieben wurde. Jede Variable aus Benutzereingaben, die in eine SQL-Abfrage gelangen könnte, muss geprüft und escaped werden. PHP bietet dafür die Funktion real_mysql_escape_string().

Ist man nicht sicher, ob der Code sauber ist, kann mod_security für den Apache helfen eine große Menge dieser Angriffe trotzdem abzuwehren. mod_security überprüft ständig alle Requests an den Webserver und reagiert auf vorgefertigte Muster mit denen viele SQL-Injection-Angriffe abgewehrt werden können. Leider funktioniert auch mod_security nur gut mit manuellem Aufwand. Oft blockt mod_security nach einer frischen Installation auch gewünschte (normale) Funktionen des eigenen PHP-Codes, so dass einem nichts anderes übrig bleibt, als die komplette Applikation nach der Installation einmal durchzutesten. Nur so findet man heraus, ob mod_security nicht eventuell auch gewünscht Funktionen blockt. Ist das der Fall, muss die Filterliste angepasst werden, so dass die false-positives verschwinden.

Die Konfiguration von mod_security ist etwas komplizierter und würde den Umfang dieses Artikels sprengen, es gibt aber massenweise gute Tutorials zu mod_security im Internet.

11. Ausweiskontrolle - Der Apache sagt nicht mehr, wer er ist
Dies ist keine wirklich wirkungsvolle Methode gegen einen Hack, sie macht es automatisierten Skripten, die nach Server-Versionen suchen aber etwas schwerer. Normalerweise zeigt der Apache auf Seiten mit Fehlermeldungen (zB 404 Not Found) seine Serversignatur.

Apache/2.2.16 (Debian) Server at www.daniel-ritter.de Port 80

So erhalten potentielle Angreifer zumindest schon einmal Informationen über den eigesetzten Webserver und den Versionsstand. Die Serversignatur ist schnell ausgeschaltet:

#/etc/apache2/conf.d/security
ServerSignature Off

12. Nicht benutze Apache-Module deaktivieren

Per default hat der Apache einige Module geladen, die fast nie benötigt werden. Unter Debian findet man die geladenen Module
als Softlinks in /etc/apache2/mods-enabled.

Fast immer entfernt werden können:

mod_cgi

Dient dem ausführen von CGI-Skripten. Diese Technik stammt noch aus den Urzeiten des Web und war der Vorvater der modernen Skriptsprachen um dynamische Webseiten zu ermöglichen. mod_cgi ist auf 99% der PHP-Websites unnötig und bei einer fehlerhaften Apache-Config eine potentielle Sicherheitslücke

a2dismod cgi

mod_status

Ermöglicht es Browsern Statusinformationen über den Apache auszulesen. Es wird so gut wie nie für "normale" Sites genutzt, bietet Angreifern aber Statusinformationen über den Apache.

a2dismod status

mod_autoindex

mod_autoindex sorgt dafür, dass Verzeichnisse auf dem Webserver aufgelistet werden können, wenn es keine gültige Index-Seite in dem entsprechenden Verzeichnis gibt. Falls diese Funktionalität nicht erwünscht ist, sollte man sie abschalten, da durch sie ganze Verzeichnisbäume auf dem Webserver nach aussen sichtbar werden können.

a2dismod autoindex