2322879

Webserver absichern: Tipps für Apache und Nginx

19.01.2018 | 10:10 Uhr |

Webserver wie Apache und Nginx schlagen sich in Sachen Sicherheit recht wacker. Oft sind es aber Konfigurationsfehler oder ungünstige Standardeinstellungen, die Angreifern zu viele Systemdetails preisgeben.

Kritische Lücken in Apache und Nginx sind rar. Verwundbar sind selten die Webserver selbst, eher die darauf laufenden Frameworks, PHP-Projekte und Scripts. Trotzdem gehört zum vernünftigen Setup eines Webservers auch die sicherere, restriktive Konfiguration des Serverdienstes.

Die folgenden Punkte helfen, eine typische Installation von Apache und Nginx besser zu abzusichern. Der wichtigste Punkt gleich vorneweg: Sicherheit verlangt regelmäßige Aktualisierungen – nicht nur der Webserver-Pakete der Linux-Distribution, sondern vor allem Updates des verwendeten CMS, Blogsystems, Shopframeworks oder sonstiger Scripts, die auf dem Server zum Einsatz kommen.

Siehe auch: Apache und Nginx auf Tempo optimieren

Header: Nicht zu viel verraten

Webserver stellen sich auf HTTP-Anfragen im Antwortheader höflich mit Namen und Versionsnummer vor, aktivierte Module wie PHP ebenfalls. Diese Header lassen Rückschlüsse auf das verwendete System, den Webserver, dessen Module und Softwareversionen zu. Direkt nach der Einrichtung sind diese Infos im Testbetrieb nützlich.  Im produktiven Betrieb und im Internet gehen diese Interna aber niemanden etwas an und verraten zu viel über das System. Die standardmäßig aktivierten Versionsinfos in Apache und Nginx sind aber schnell deaktiviert.

Apache: In Debian/Ubuntu/Raspbian ist die Konfigurationsdatei „/etc/apache2/conf-available/security.conf“ verantwortlich.  In der Datei muss nur die Zeile „ServerTokens OS“ zu

ServerTokens Prod  

geändert werden, gefolgt von einem Apache-Neustart. Danach sind die Angaben zu Apache-Version und Modulen aus dem Header getilgt.

Nginx: Die Einstellung von Nginx, die eine Versionsangabe im Header unterdrückt, ist in der Datei „/etc/nginx/nginx.conf“ untergebracht. Innerhalb der HTTP-Sektion, die mit

http {  

beginnt, fügen Sie vor der abschließenden geschweiften Klammer als letzte Zeile diese Angabe ein:

server_tokens off;  

PHP: Auch der PHP-Interpreter für Webserver ist geschwätzig und verrät in der Standardkonfiguration seine Versionsnummer.  Diese Einstellung ist unabhängig vom verwendeten Webserver in der Datei „php.ini“ zu finden.

Deren Speicherort ist je nach Version und Installationsart verschieden. Ist PHP (Version 7.0) als Apache-Modul eingerichtet, so liegt die relevante „php.ini“ im Verzeichnis „/etc/php/7.0/apache2/php.ini“. Falls PHP für Nginx als externer Script-Interpreter über das Paket „PHP-FPM“ installiert ist, dann findet sich diese Datei unter „/etc/php/7.0/fpm/php.ini“.

In der Datei muss die Zeile

expose_php = On  

nach

expose_php = Off 

geändert werden.

Relevant: Typische Probleme mit Apache und Nginx lösen

Nicht vergessen: Nach jeder dieser Änderungen ist ein Neustart des Webservers mit

sudo service apache reload 

beziehungsweise

sudo service nginx reload  

im Fall von Nginx nötig. Außerdem muss das Modul „PHP-FPM“, das unabhängig vom Webserver-Dienst läuft, mit folgendem Befehl sudo service php7.0-fpm restart neu geladen werden.

Extra-Sicherheit per Modul

Dieser curl-Befehl zeigt die Header einer HTTP/- HTTPS-Antwort an.
Vergrößern Dieser curl-Befehl zeigt die Header einer HTTP/- HTTPS-Antwort an.

Wer immer einen Dienst anbietet, sei es nur ein Webserver mit statischen HTML-Seiten, erst recht mit dynamischen Inhalten per PHP, wird irgendwann die Bekanntschaft mit automatisierten Scanprogrammen wie Nikto (siehe Kasten) machen.

Apache: Mit dem Extra-Modul „libapache2-mod-evasive“ weicht Apache typischen Scanattacken, massenhaften Seitenaufrufen und einfachen Angriffen selbständig aus. Wird eine Seite in schneller Folge von einer IP-Adresse aus mehrmals pro Sekunde angefordert oder werden 50 gleichzeitige Requests pro Apache-Prozess ausgelöst, dann landet diese IP-Adresse einige Sekunden auf einer schwarzen Liste und erhält nur eine 403-Meldung (Forbidden). Die Erweiterung ist in Ubuntu/Debian/Raspbian mittels des Kommandos

sudo apt-get install libapache2-mod-evasive  

leicht installiert. Auch Cent-OS kennt das Modul unter diesem Namen und unter Open Suse nennt es sich „apache2-modevasive“. Nach einem Neustart des Webservers ist das Modul mit Standardregeln aktiv. Das Modul lässt sich leicht bei einem Besuch des Webservers im Browser durch einen häufigen Druck auf die F5-Taste testen.

Auch Nginx lässt sich über ein eingebautes Modul so konfigurieren, dass der Server eine Anfrageflut mit einer 503-Meldung quittiert.
Vergrößern Auch Nginx lässt sich über ein eingebautes Modul so konfigurieren, dass der Server eine Anfrageflut mit einer 503-Meldung quittiert.

Nginx: Für diesen Webserver gab es bis vor einigen Jahren das Tool Naxsi, dessen Entwicklung aber momentan ruht. Es empfiehlt sich, Nginx gegen die Flutung mit Anfragen über das eingebaute Modul „ngx_ http_limit_req_module“ zu schützen. Dazu öffnen Sie die Konfigurationsdatei „/etc/ nginx/nginx.conf“ mit root-Recht in einem Texteditor und fügen im Abschnitt „http {“ die Zeile

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; 

ein. In der Sitekonfiguration, die in Debian/ Ubuntu/Raspbian üblicherweise unter „/etc/nginx/sites-available/default“ liegt, kommt nun noch in die Sektion „server {“ folgende Zeile:

limit_req zone=one burst=5;  

Nach einem Neustart wird Nginx auf zu häufigen Anfragen mit einer 503-Meldung antworten („Temporary unavailable“). Weitere Beispiele zu diesem Modul nennt die Nginx-Dokumentation .

Scanner: Webserver im Check

Kaum jemand macht sich die Mühe, alle potenziellen Schwachstellen und Konfigurationsfehler eines Webservers manuell abzuklopfen.  Das ist auch nur in Ausnahmen nötig, denn für die üblichen Schwachpunkte gibt es Scanprogramme, die einen Check weitgehend automatisieren.

Auf unserer Test-Site hat der automatische Scanner eine Cross- Site-Scripting-Schwachstelle gefunden.
Vergrößern Auf unserer Test-Site hat der automatische Scanner eine Cross- Site-Scripting-Schwachstelle gefunden.

Nikto: Nikto ist ein Tool, das systematisch bei der Analyse von möglichen Konfigurationsfehlern hilft . Es ist ein Kommandozeilenprogramm und überprüft einen Webserver auf 6700 typische Probleme, die ein potenzielles Risiko darstellen. Installiert ist Nikto in den verbreiteten Linux-Distributionen schnell über den jeweiligen Paketmanager, in Debian/Ubuntu beispielsweise mit diesem Kommando:

sudo apt-get install nikto  

Um einen Webserver zu untersuchen, dient dieser Aufruf:

nikto -h [Hostname/IP]

Nikto wird im Terminal nach seinen Checks ein ausführliches Protokoll mit weiterführenden Infos ausgeben.

Wapiti: Dieser Scanner ist in Python programmiert und sucht genauer nach Problemen auf Webauftritten. Wapiti sucht nach unsicheren PHP-Includes, nach potenziellem Cross-Site-Scripting, SQL-Injections, verräterischen Dateien und fehlerhaften Webserver-Regeln in „.htaccess“-Dateien. Aus den Paketquellen von Debian/Ubuntu installiert das Kommando

sudo apt-get install wapiti  

den Scanner. Der Befehl

wapiti [URL] -v 1 -n 99 -b folder 

startet einen Check der angegebenen URL. Die Ergebnisse präsentiert Wapiti in einer HTML-Datei, die nach dem Scan im Verzeichnis „~/.wapiti/generated-reports“ liegt.

0 Kommentare zu diesem Artikel

PC-WELT Marktplatz

2322879