Liebe Teilnehmerinnen und Teilnehmer,

wir müssen vor allem in den letzten Tagen und Wochen vermehrt feststellen, dass es permanent Einbruchsversuche über die von Teilnehmern auf unserem User-Webserver me.in-berlin.de abgelegten PHP-Skripts gibt, die darauf abzielen, den Server für andere Dinge zu missbrauchen. Daher haben wir beschlossen, (leider etwas) kurzfristig die Sicherheit des Servers zu erhöhen und möchten 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 Skripts in Zukunft einzusetzen. Alle anderen können diese Mail getrost überspringen.

Wir haben bereits vor längerer Zeit verschiedene Maßnahmen ergriffen, um Einbrüche in den User-Webserver deutlich zu erschweren, und verfeinern diese weiter. Wir haben beschlossen, die PHP-Möglichkeiten ein wenig einzuschränken, da fast alle Angreifer PHP-Sicherheitslücken ausnutzen. Natürlich versuchen wir auch diese Einschränkungen so zu halten, dass eure Skripts möglichst wenig beeinträchtigt werden und weiterhin funktionieren, aber diese Änderungen könnten die Funktion einiger PHP-Skripts beeinträchtigen. Daher geht diese Information vorab an Euch, wenn auch die Einführung der Maßnahmen sehr kurzfristig erfolgen wird. Die genannten Änderungen werden morgen abend, also am 2006-06-15, wirksam. Bitte prüft die Funktionsfähigkeit eurer Skripts nach Aktivierung der unten genannten Änderungen und teilt uns Fehlfunktionen zeitnah mit, damit wir das überprüfen bzw. eine Sonderkonfiguration für eure Domains einrichten können. Zum Zeitpunkt der Änderung wird es einen Newsartikel auf unseren Webseiten geben.

Die folgenden Hinweise sind für alle Teilnehmer wichtig, die fremde (“fertige”) oder eigene PHP-Skripts in ihren Webseiten verwenden.

Zuerst ein paar allgemeine Hinweise zu PHP:

Die meisten dieser Eindringversuche erfolgen über bekannte Sicherheitslücken populärer PHP-Anwendungen, wie sie in der Einleitung dieses Newsletters bereits beispielhaft genannt wurden. PHP ist deshalb so anfällig dafür, weil es aus Performance-Gründen als Apache-Modul laufen muss, und damit laufen alle PHP-Skripts mit den Rechten des Webservers (bei CGI-Skripts ist das dank suexec anders). Aber selbst wenn die PHP-Skripts unter eurer individuellen Benutzerkennung laufen würden, kann ein PHP-Script mit Sicherheitslücken den kompletten Inhalt eures Homeverzeichnisses verändern oder löschen.

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 läuft. Das Motto “never touch a running system” sollte nicht dazu führen, die Systemsicherheit erheblich zu beeinträchtigen.
  • Räumt nach einem Update auf: löscht nicht mehr verwendete Dateien aus älteren Versionen (darüber liefen schon einige Eindringversuche).
  • Löscht Installationsscripte, wenn diese ausgeführt wurden (oder verschiebt sie an einen sicheren Ort und macht sie für 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 für “die Welt” schreibbar sind. Es genügt die Gruppe wwwuser, der Webserver ist dort Mitglied (dies ist ein Spezifikum unserer Konfiguration). Die aktuell gehackten Skripts suchen gezielt Verzeichnisse auf dem Server, die für “die Welt” schreibbar sind (Rechte 777).
  • Von Besuchern einer Webseite zur Verfügung gestellte Daten sollten immer als potentiell bösartig und gefährlich angesehen werden. Dies sind sowohl Eingabefelder in Formularen, als auch jede andere Art von Parametern, die einem Script beim Aufruf übergeben werden können.
  • Lasst bei Verwendung der mail() Funktion nur genau EINE Empfängeradresse pro Eingabe zu und limitiert die Zahl der insgesamt pro Minute verschickten Mails.
  • Vermeidet die Nutzung von Optionen wie register_globals. Was ändert sich?

  1. register_globals = off Doku deutsch Doku englisch

  2. allow_url_fopen = off Doku deutsch Doku englisch

Wir hatten diese beiden Optionen bisher aktiviert, werden sie aber morgen standardmäßig deaktivieren. Wer sie unbedingt braucht, kann sie zur Zeit per .htaccess aktivieren (siehe o. g. Links). Wir behalten uns aber vor, diese Möglichkeit 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).

  1. Einsatz von libapache-mod-security

libapache-mod-security (www.modsecurity.org) ist ein Modul für den Apache-Webserver, welches jeden Webseitenaufruf kontrolliert und bei bestimmten Parametern an PHP-Skripts Alarm schlägt und den Zugriff auf das entsprechende PHP-Script verbietet. Dies kann sicherlich auch mal zu false positives bei einigen Skripts führen, so dass Seiten geblocked werden, denen korrekte Parameter übergeben werden. Sollte dies jemandem bei seinen Skripts auffallen, genügt 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 zukünftig gehackten PHP-Skripts, aber dies sollte euch nicht davor bewahren, trotzdem eure PHP-Skripts immer aktuell zu halten. Aktuell können wir aufgrund der Performance leider nur abgespeckte Regeln verwenden. Mit dem neuen User-Webserver der bald kommen wird können wir noch mehr Regeln aktivieren und euch z. B. auch einigen Guestbook- und Referer-Spam wegfiltern.

Wie immer gilt, dass wir Sonderlösungen zulassen können, sofern sie unserem Sicherheitskonzept nicht zuwiderlaufen und jemand weiss, was er tut und sich entsprechend verantwortungsbewusst verhält. Dies bedarf aber persönlicher, konkreter Absprache über den User-Webserver-Support www at in-berlin.de.

Wir hoffen, daß wir euch mit diesen Änderungen auf unserem User-Webserver eine sicherere Umgebung zur Verfügung stellen können.

Das IN-Berlin Team