Nachrichtenarchiv
erweitere Sicherheit auf dem User-Webserver (15.06.2006 18:40, Chris)Liebe Teilnehmerinnen und Teilnehmer,
wir muessen vor allem in den letzten Tagen und Wochen vermehrt feststellen, dass es permanent Einbruchsversuche ueber die von Teilnehmern auf unserem User-Webserver me.in-berlin.de abgelegten PHP-Scripts gibt, die darauf abzielen, den Server fuer andere Dinge zu missbrauchen. Daher haben wir beschlossen, (leider etwas) kurzfristig die Sicherheit des Servers zu erhoehen und moechten euch mit diesem Newsletter hiervon in Kenntnis setzen.
Dieser Newsletter betrifft nur Teilnehmer mit Webseiten, die die Skriptsprache PHP (recht beliebt sind z.B. phpBB, Mambo, Joomla, phpnuke, WordPress, sowie diverse Blogs und Wikis) nutzen oder beabsichtigen, derartige Scripts in Zukunft einzusetzen. Alle anderen koennen diese Mail getrost ueberspringen.
Wir haben bereits vor laengerer Zeit verschiedene Massnahmen ergriffen, um Einbrueche in den User-Webserver deutlich zu erschweren, und verfeinern diese weiter. Wir haben beschlossen, die PHP-Moeglichkeiten ein wenig einzuschraenken, da fast alle Angreifer PHP-Sicherheitsluecken ausnutzen. Natuerlich versuchen wir auch diese Einschraenkungen so zu halten, dass eure Scripts moeglichst wenig beeintraechtigt werden und weiterhin funktionieren, aber diese Aenderungen koennten die Funktion einiger PHP-Scripts beeintraechtigen. Daher geht diese Information vorab an Euch, wenn auch die Einfuehrung der Massnahmen sehr kurzfristig erfolgen wird. Die genannten Aenderungen werden morgen abend, also am 2006-06-15, wirksam. Bitte prueft die Funktionsfaehigkeit eurer Scripts nach Aktivierung der unten genannten Aenderungen und teilt uns Fehlfunktionen zeitnah mit, damit wir das ueberpruefen bzw. eine Sonderkonfiguration fuer eure Domains einrichten koennen. Zum Zeitpunkt der Aenderung wird es einen Newsartikel auf http://www.in-berlin.de/ geben.
Die folgenden Hinweise sind fuer alle Teilnehmer wichtig, die fremde ("fertige") oder eigene PHP-Scripts in ihren Webseiten verwenden.
Zuerst ein paar allgemeine Hinweise zu PHP:
Die meisten dieser Eindringversuche erfolgen ueber bekannte Sicherheitsluecken populaerer PHP-Anwendungen, wie sie in der Einleitung dieses Newsletters bereits beispielhaft genannt wurden. PHP ist deshalb so anfaellig dafuer, weil es aus Performance-Gruenden als Apache-Modul laufen muss, und damit laufen alle PHP-Scripts mit den Rechten des Webservers (bei CGI-Scripts ist das dank suexec anders). Aber selbst wenn die PHP-Scripts unter eurer individuellen Benutzerkennung laufen wuerden, kann ein PHP-Script mit Sicherheitsluecken den kompletten Inhalt eures Homeverzeichnisses veraendern oder loeschen.
Daher noch einmal an alle, die derartige Software verwenden, die dringende Aufforderung:
- Abonniert die spezifischen Sicherheits-Mailinglisten der Software.
- Installiert stets die aktuelle Version der Software, auch wenn Updates nicht notwendig erscheinen, da die Software ja laeuft.
Das Motto "never touch a running system" sollte nicht dazu fuehren, die Systemsicherheit erheblich zu beeintraechtigen. - Raeumt nach einem Update auf: loescht nicht mehr verwendete Dateien aus aelteren Versionen (darueber liefen schon einige Eindringversuche).
- Loescht Installationsscripte, wenn diese ausgefuehrt wurden (oder verschiebt sie an einen sicheren Ort und macht sie fuer den Webserver unlesbar - Rechte "chmod 700"), in der Regel gibt die PHP-Software dazu Hinweise, die leider nur von den wenigsten Teilnehmer beachtet werden.
- Es ist nirgends erforderlich, dass Dateien fuer "die Welt" schreibbar sind. Es genuegt die Gruppe wwwuser, der Webserver ist dort Mitglied (dies ist ein Spezifikum unserer Konfiguration). Die aktuell gehackten Scripts suchen gezielt Verzeichnisse auf dem Server, die fuer "die Welt" schreibbar sind (Rechte 777).
- Von Besuchern einer Webseite zur Verfuegung gestellte Daten sollten immer als potentiell boesartig und gefaehrlich angesehen werden. Dies sind sowohl Eingabefelder in Formularen, als auch jede andere Art von Parametern, die einem Script beim Aufruf uebergeben werden koennen.
- Lasst bei Verwendung der mail() Funktion nur genau EINE Empfaengeradresse pro Eingabe zu und limitiert die Zahl der insgesamt pro Minute verschickten Mails.
- Vermeidet die Nutzung von Optionen wie register_globals.
1. register_globals = off
http://www.php.net/manual/en/ini.core.php#ini.register-globals
http://www.php.net/manual/de/ini.core.php#ini.register-globals
2. allow_url_fopen = off
http://www.php.net/manual/de/ref.filesystem.php#ini.allow-url-fopen
http://www.php.net/manual/en/ref.filesystem.php#ini.allow-url-fopen
Wir hatten diese beiden Optionen bisher aktiviert, werden sie aber morgen standardmaessig deaktivieren. Wer sie unbedingt braucht, kann sie zur Zeit per .htaccess aktivieren (siehe o.g. Links). Wir behalten uns aber vor, diese Moeglichkeit zu sperren und nur auf Anfrage per Teilnehmer oder per Verzeichnis zuzulassen.
Wer dies für seine Seiten vorab testen will, stelle es in .htaccess ein (einmal pro virtuellem Server = pro domain).
3. Einsatz von libapache-mod-security
libapache-mod-security (www.modsecurity.org) ist ein Modul fuer den Apache-Webserver, welches jeden Webseitenaufruf kontrolliert und bei bestimmten Parametern an PHP-Scripts Alarm schlaegt und den Zugriff auf das entsprechende PHP-Script verbietet. Dies kann sicherlich auch mal zu false positives bei einigen Scripts fuehren, so dass Seiten geblocked werden, denen korrekte Parameter uebergeben werden. Sollte dies jemandem bei seinen Scripts auffallen, genuegt ein kurzer Hinweis, damit wir dem nachgehen und die Regeln korrigieren.
Gefiltert werden u.a. bekannte Kommando-Aufrufe solcher Hackscripts wie "wget", "uname", Zugriffe auf z.B. "/etc/passwd", "id", "ps", "gcc" oder auch SQL-Injection Keywords.
Wir verringern mit libapache-mod-security sicherlich die Anzahl der zukuenftig gehackten PHP-Scripts, aber dies sollte euch nicht davor bewahren, trotzdem eure PHP-Scripts immer aktuell zu halten. Aktuell koennen wir aufgrund der Performance leider nur abgespeckte Regeln verwenden. Mit dem neuen User-Webserver der bald kommen wird koennen wir noch mehr Regeln aktivieren und euch z.B. auch einigen Guestbook- und Referer-Spam wegfiltern.
Wie immer gilt, dass wir Sonderloesungen zulassen koennen, sofern sie unserem Sicherheitskonzept nicht zuwiderlaufen und jemand weiss, was er tut und sich entsprechend verantwortungsbewusst verhaelt. Dies bedarf aber persoenlicher, konkreter Absprache ueber den User-Webserver-Support www at in-berlin.de.
Wir hoffen, daß wir euch mit diesen Aenderungen auf unserem User-Webserver eine sicherere Umgebung zur Verfuegung stellen koennen.
Das IN-Berlin Team