Apache-Server gegen Attacken schützen Workshop: Linux-Webserver richtig abschotten

Transkript

1 Apache-Server gegen Attacken schützen Workshop: Linux-Webserver richtig abschotten von Thomas Hümmler Seite 1 von 12

2 Inhalt Lese- und Schreibrechte für den Apache... 5 Risiken von Server Side Includes (SSI)... 7 Risiken von Common Gateway Interface (CGI)... 8 Sicherheitsrisiko.htaccess... 9 Schotten dicht Tipp zum Schluss: Listen lesen Seite 2 von 12

3 Apache-Server gegen Attacken schützen Workshop: Linux-Webserver richtig abschotten von Thomas Hümmler Webserver sind ständig Angriffen von außen ausgesetzt. Verschlimmert wird das mit einer falschen Konfiguration. Wir zeigen Ihnen, wie Sie den bekannten Apache- Webserver sicher konfigurieren und was Sie sonst noch beachten müssen, um Schlupflöcher zu schließen. Der Port 80 ist ein Tor zur Welt. Hier nimmt üblicherweise ein Webserver 1 wie der Apache Anfragen entgegen und verarbeitet diese. Über diesen Port können aber auch Eindringlinge ins System gelangen. Die docken mit ihren kriminellen Ziele häufig nicht am Webserver an, sondern bei Addons, CGI-Skripten oder dem eigentlichen Betriebssystem 2. Damit das nicht passiert oder zumindest sehr unwahrscheinlich ist, achten Sie darauf, den Apache entsprechend resistent zu machen. Dazu gibt es verschiedene Möglichkeiten. Webserver unter Linux absichern Überblick: Im Apache-Wiki ist für jede Distribution und jedes Betriebssystem aufgeführt, wo die Konfigurationsdaten des Webserver zu finden sind. Webserver unter Linux absichern Arbeitet auch ohne weitreichende Rechte: Ein CMS will üblicherweise Zugriff auf verschiedene Verzeichnisse und bildet so ein Sicherheitsrisiko. Dabei kann beispielsweise die Joomla- Konfiguration auch per SSH auf den Server geladen werden Seite 3 von 12

4 Webserver unter Linux absichern SSI: Der Wikipedia-Eintrag erläutert die Befehle include, set, echo und if, die man in SSI einsetzen kann. Webserver unter Linux absichern Wer CGI-Skripte wie dieses von der Website selfhtml.org nutzen will, sollte genau wissen, was der in diesem Fall Perl- Code auf Ihrem Server macht. Webserver unter Linux absichern Wann und wie einsetzen? Das Apache-Tutorial auf httpd.apache.org/docs/2.2/howto/htaccess.html erklärt den sinnvollen Einsatz von.htaccess-dateien. Webserver unter Linux absichern Mein Webserver! Mit der Direktive Listen :80 sind nur Zugriffe von Localhost erlaubt. Webserver unter Linux absichern Immer gut informiert: Auf der Apache HTTP Server Announcements List werden neue Sicherheitslücken und deren -behebung als erstes dokumentiert. Wenn Sie anderen Benutzern außer root erlauben, die Rechte von Dateien zu ändern, die sonst nur root ausführen darf, können Sie in Kalamitäten kommen. Das gilt für Unix generell. Auf den Webserver Apache bezogen heißt das: Ein Angreifer könnte die Programmdatei so ändern, dass beim nächsten Start ein anderes Programm abläuft, Log-Daten 3 überschreibt oder löscht. In unserem Workshop zeigen wir, wie Sie Webserver und Mail-Systeme richtig gegen Angriffe absichern. 3 Seite 4 von 12

5 Lese- und Schreibrechte für den Apache Um das Ändern von Programmdateien zu verhindern, setzen schon die Standarddistributionen 4 die Lese- und Schreibrechte sinnvoll. Wer Apache aber aus den Quellen installiert, muss aber auf die korrekten Verzeichnis- und Dateirechte achten. Welche Verzeichnisse das bei welcher Distribution beziehungsweise bei welchem Betriebssystem betrifft, steht detailliert im Apache-Wiki 5. Der Apache-Server muss alle seine Konfigurationsdateien lesen können. Ebenso alle Dateien, die er darstellen soll - das betrifft sowohl HTML- und CSS-Dateien als auch verlinkte Dokumente und Bilder. Der Webserver beziehungsweise der dafür vorgesehene Benutzer (unter Debian und Ubuntu ist das www-data) sollte die Konfigurationsdaten allerdings nicht schreiben können. Daher sollte der Webserver auch nicht der Eigentümer der Konfigurationsdaten sein. Das bedeutet, wenn Sie den Webserver mithilfe der Quellen installieren: Legen Sie als Besitzer der Konfigurationsdateien root fest. Die Gruppe und alle anderen erhalten nur Leserechte. Das geschieht mithilfe des Befehls chmod 644 APACHE-KONFIGURATIONSDATEI(EN) Normalerweise läuft der Webserver als root und schaltet erst dann auf den mit der User-Direktive bezeichneten Nutzer um. In dem Fall braucht er nicht einmal spezielle Schreibrechte für seine Log- Dateien. Für CGI- oder PHP-Skripte, die der Webserver ausführt, gilt: Diese benötigen keine Ausführungsrechte, denn sie werden vom Webserver interpretiert und ausgeführt. Überblick: Im Apache-Wiki ist für jede Distribution und jedes Betriebssystem aufgeführt, wo die Konfigurationsdaten des Webservers zu finden sind. Content-Management-Systeme 6 (CMS) und andere Webanwendungen, die mithilfe eines Webbrowsers verwaltet und mit Inhalten versehen werden, verlangen indes Schreibrechte für den Webserver-User auf bestimmte Verzeichnisse. In so einem Fall haben Sie zwei Möglichkeiten: Entweder Sie ändern den Besitzer des Verzeichnisses mit: Seite 5 von 12

6 chown -R Webserver-User VERZEICHNIS Damit wechselt das Verzeichnis sowie rekursiv (Option -R) alle Unterordner zum Besitzer "Webserver-User". Der heißt in vielen Linux-Distributionen "www" oder auch "www-data". Die zweite Möglichkeit: Sie ändern die Gruppe für das Verzeichnis auf die Gruppe, in der der Apache-Webserver ist, und erteilen Schreibrechte für die Gruppe auf das Verzeichnis und seine Unterordner: chgrp -R Webserver-Gruppe VERZEICHNISchmod -R g+w VERZEICHNIS Allerdings ist hier Vorsicht geboten. Denn Verzeichnisse, in die der Webserver schreiben darf, sind typische Angriffsziele: Wenn es jemand schafft, ein PHP-Skript ins sogenannte Document-Root- Verzeichnis zu laden, kann es von extern einfach über den Browser gestartet werden, und Ihr Webserver führt den Code des Angreifers aus. Das Document-Root-Verzeichnis ist der Haupt-Dokumentenbaum, der im Web sichtbar ist und aus dem heraus Dateien ausliefert werden. In der Apache-Konfiguration wird er mit "DocumentRoot VERZEICHNIS" angegeben. Voreingestellt in Apache ist das Verzeichnis /usr/local/apache/htdocs, in Debian ist es das Verzeichnis /var/www. "DocumentRoot" wird als Konfigurationsdirektive in der gesamten Serverkonfiguration ebenso benutzt wie für virtuelle Hosts. Greift nicht eine Alias- Direktive, hängt der Server die Pfade aus der angeforderten URL direkt an das Wurzelverzeichnis an und bildet so den Pfad zum Dokument. Ein Host-Zugriff auf würde auf dem Server in einer Standard-Apache-Installation die Datei /usr/local/apache/ htdocs/bilder/index.hmtl im Browser anzeigen. Arbeitet auch ohne weitreichende Rechte: Ein CMS verlangt üblicherweise Zugriff auf verschiedene Verzeichnisse und bildet so ein Sicherheitsrisiko. Dabei kann beispielsweise die Joomla-Konfiguration auch per SSH auf den Server geladen werden. Für viele Webanwendungen ist es nicht nötig, dass der Webserver Schreibrechte auf das Verzeichnis hat. Anstatt beispielsweise Plugins über den Browser zu installieren, kann man diese auch per SSH 7 hochladen und dann selbst auf dem Server entpacken. Die Apache-Dokumentation führt als 7 Seite 6 von 12

7 Beispiel das Joomla-CMS an. Das will seine Konfigurationsdatei ins Document-Root-Verzeichnis schreiben; wird ihm das aufgrund fehlender Rechte verweigert, zeigt es die Konfiguration im Browser an, und der Nutzer kann sie speichern und händisch hochladen. Risiken von Server Side Includes (SSI) CGI-Skripte und SSI (Server Side Includes) bergen einerseits Sicherheitsrisiken. Andererseits sind SSI bei Homepage-Betreibern vor allem deswegen beliebt, weil man mit ihnen schnell dynamische Seiten erzeugen kann. Per SSI kann beispielsweise das Datum abgefragt, ein CGI-Programm gestartet oder sogar ein Shell-Befehl ausgeführt werden. SSI-Direktiven werden direkt von einer HTML- Seite ausgeführt, sobald diese im Browser angefordert wird. SSI muss lediglich mit Options +Includes in der Apache-Konfiguration eingeschaltet sein. Dann sind zum Beispiel solche Kommandos innerhalb des HTML-Codes möglich: <pre> <!--#exec cmd="irgendein-cgi-skript" --> </pre> Ein Nachteil von SSI ist, dass alle Dateien zunächst von Apache auf SSI-Inhalte geparst werden - unabhängig davon, ob SSI-Direktiven drinstehen oder nicht. Das erhöht die Serverlast und kann sich vor allem auf Rechnern negativ auswirken, auf denen mehrere Webserver arbeiten, etwa virtuelle Maschinen bei einem Hoster. Dem kann man vorbeugen, indem man den SSI-fähigen Seiten andere Endungen gibt, etwa "shtml", und das in der Konfiguration entsprechend berücksichtigt: AddType text/html.shtmladdoutputfilter INCLUDES.shtml Außerdem empfiehlt es sich, die Option explizit auf ein gewünschtes Verzeichnis anzuwenden. Der Grund: Optionsdirektiven können einander überschreiben. So kann es passieren, dass eine zuvor abgeschaltete Direktive weiter hinten in der Konfiguration wieder eingeschaltet wird. SSI: Der Wikipedia-Eintrag erläutert die Befehle include, set, echo und if, die man in SSI einsetzen kann. Seite 7 von 12

8 Eine weitere Möglichkeit: Schalten Sie die Ausführung von Skripten und Programmen aus SSI-fähigen Seiten einfach ab. Ersetzen Sie dazu in der Optionsdirektive "Includes" durch "Includes- NOEXEC". Risiken von Common Gateway Interface (CGI) Die Optionsdirektive "IncludesNOEXEC" verhindert SSI, aber nicht das Ausführen von CGI- Skripten. Denn die können mit <-- #inlcude virtual="irgendein-cgi-skript" --> noch gestartet werden, wenn die Skripte in einem Verzeichnis liegen, das mit der ScriptAlias-Direktive festgelegt wurde. Wenn Sie CGI-Skripte auf dem Webserver einsetzen, sollten Sie dem Programmierer unbedingtes Vertrauen entgegenbringen. Denn CGI-Skripte können beliebige Befehle mit den Benutzerrechten des Webservernutzers ausführen und somit prinzipiell sehr gefährlich sein. Achtung: Wer CGI-Skripte wie dieses von der Website selfhtml.org nutzen will, sollte genau wissen, was der - in diesem Fall - Perl-Code auf seinem Server macht. Darüber hinaus laufen alle CGI-Skripte mit denselben Benutzerrechten und können sich daher gegenseitig ins Gehege kommen. Hier gibt es seit Apache 1.2 zwei Lösungen: suexec und CGI- Wrap. Mit dem suexec-wrapper laufen jedes CGI-Programm und jede SSI-Direktive nur mit der Benutzer-ID des Webservers. Anfragen an den Wrapper kann der Administrator weiterleiten, indem er innerhalb eines virtuellen Hosts eine SuexecUserGroup definiert, etwa so: SuexecUserGroup USER GRUPPE oder mit der UserDir-Direktive Benutzerverzeichnisse festlegt. Die Direktive UserDir /home/*/webuserdir disabled root in der Konfiguration definiert zum Beispiel im Home-Verzeichnis jedes Benutzers (*) das web-verzeichnis für den eigenen Webauftritt. Dieses wird dann im Browser angezeigt, wenn man Seite 8 von 12

9 eingibt. Ganz wichtig ist die zweite Zeile der Direktive. Dieser Befehl schließt ab der Apache 8 - Version 1.3 das Home-Verzeichnis des Benutzers root explizit aus. Sonst besteht die Gefahr, dass man nach der Eingabe im Wurzelverzeichnis des Systems landet. Sicherheitsrisiko.htaccess Viele Anwender meinen, man müsse und solle mithilfe der sogenannten.htaccess-dateien die Benutzerauthentisierung regeln. "This is simply not the case", schreiben die Entwickler in der Apache- Dokumentation 9. Die.htaccess-Dateien sollte man nur dann nutzen, wenn die Webserverkonfiguration nicht häufig geändert werden soll und die Nutzer die Änderungen selbst durchführen - etwa bei Hostern. Prinzipiell empfehlen die Apache-Entwickler, auf.htaccess-dateien zu verzichten. Die Direktive <Directory /> AllowOverride None </Directory> in der Serverkonfiguration lässt keine.htaccess-dateien zu, außer in Verzeichnissen, die gesondert angegeben sind. Ohne diese Direktive leidet die Geschwindigkeit. Denn mit "AllowOverride" durchsucht der Apache jedes seiner Verzeichnisse nach diesen Dateien, auch wenn dort keine stehen. Zusätzlich wird jedes Mal, wenn im Browser ein Dokument angefordert wird, auch die.htaccess-datei geladen. Und um alles komplett zu machen: Der Webserver sieht auch noch in jedem darüberliegenden Verzeichnis nach.htaccess-dateien, um ja keine darin stehende Direktive zu übersehen. Außer dem Geschwindigkeitsnachteil sehen die Entwickler noch ein Sicherheitsproblem: "AllowOverride" erlaubt es den Nutzern, die Serverkonfiguration zu ändern. Dann hat der Administrator eventuell keine Kontrolle mehr über den Rechner Seite 9 von 12

10 Wann und wie einsetzen? Das Apache-Tutorial erklärt den sinnvollen Einsatz von.htaccess-dateien. Wollen Sie.htaccess-Dateien vermeiden, können Sie die Einträge stattdessen in einem <Directory>- Bereich definieren. Das sieht kaum anders aus. Ein.htaccess-Eintrag wie "AddType text/plain.txt" würde in einem <Directory>-Bereich zum Beispiel so aussehen: <Directory /www/htdocs/texte>addtype text/plain.txt</directory> Schotten dicht Wenn Sie den Webserver nur auf dem eigenen Rechner einsetzen wollen, schalten Sie den externen Zugriff einfach aus. Das geschieht mithilfe der Listendirektive in der Serverkonfiguration. Mit dieser Anweisung werden IP-Adressen und Port-Nummern festgelegt, auf denen der Webserver auf Anfragen wartet. In Debian 10 und Ubuntu 11 steht die Listendirektive in der Datei /etc/apache2/ ports.conf (wo die Konfigurationsdaten in anderen Distributionen und Betriebssystemen zu finden sind, steht im bereits eingangs erwähnten Wiki 12 ): NameVirtualHost *:80Listen 80 Um das Tor zur Außenwelt zu schließen, ändern Sie diesen Eintrag in: Listen :80 Mein Webserver: Mit der Direktive "Listen :80" sind nur Zugriffe von Localhost erlaubt Seite 10 von 12

11 Nach dem Sichern der Konfiguration und einem Neustart beantwortet der Webserver nur noch die Anfragen des Localhosts. Wollen Sie stattdessen den Apache in einem lokalen Netzwerk oder Subnetz einsetzen, hilft die Direktive "Allow from" aus dem Apache-Modul mod_authz_host, das es seit der Version 2.1 gibt. "Allow from" können Sie in den Konfigurationsbereichen <Directory>, <Files> und <Location> verwenden, etwa so: <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from RedirectMatch ^/$ /apache2-default/ </Directory> Nach einem Neustart des Webservers haben nur Rechner aus dem IP-Adressbereich * und * Zugriff auf das Webserververzeichnis. Falls Sie lieber mit Realnamen arbeiten, können Sie statt des IP-Adressbereichs auch den Domain-Namen angeben: Allow from intern.net Tipp zum Schluss: Listen lesen Schließlich sollten Sie, wie bei jeder anderen Webanwendung auch, die "Apache HTTP Server Announcements List" mit Informationen über neue Versionen und Sicherheitslücken zum Apache- Webserver lesen. Immer gut informiert: Auf der "Apache HTTP Server Announcements List" werden neue Sicherheitslücken und deren Behebung als Erstes dokumentiert. Die Mailing-Liste können Sie auf der Apache.org-Website 13 abonnieren. Die Informationen dort erhalten Sie zumeist auch auf den Security-Listen Ihrer Linux-Distribution 14, allerdings immer mit Verzögerung, denn die Software wird erst auf der entsprechenden Distribution kompiliert. (hal) geprüft IDG Business Media GmbH Seite 11 von 12

12 Alle Rechte vorbehalten. Jegliche Vervielfältigung oder Weiterverbreitung in jedem Medium in Teilen oder als Ganzes bedarf der schriftlichen Zustimmung der IDG Business Media GmbH. DPA-Texte und Bilder sind urheberrechtlich geschützt und dürfen weder reproduziert noch wiederverwendet oder für gewerbliche Zwecke verwendet werden. Für den Fall, dass in TecChannel unzutreffende Informationen veröffentlicht oder in Programmen oder Datenbanken Fehler enthalten sein sollten, kommt eine Haftung nur bei grober Fahrlässigkeit des Verlages oder seiner Mitarbeiter in Betracht. Die Redaktionübernimmt keine Haftung für unverlangt eingesandte Manuskripte, Fotos und Illustrationen. Für Inhalte externer Seiten, auf die von TecChannel aus gelinkt wird,übernimmt die IDG Business Media GmbH keine Verantwortung. Seite 12 von 12