Als Schutzmaßnahmen gegen Krypto-Tojanern in PHP wird häufig der Ratschlag geäußert seine in PHP geschriebenen Webanwendungen (z.B. WordPress, Drupal, Joomla, Magento etc.) immer auf dem aktuellen Stand zu halten. Gleiches gilt für Server-Prozesse auf denen Webanwendungen laufen (z.B. Apache, PHP, nginx). Denn aktuell ist die Schadsoftware dafür bekannt auch Dateien auf Servern zu verschlüsseln, die PHP ausführen können. Wie genau das von statten geht ist noch nicht klar. Deswegen sollte man als Betreiber solcher Webanwendungen auf der Hut sein.
Systemsoftware muss immer aktuell sein
Wir weisen unsere Kunden immer auf zeitnahe Aktualisierung ihrer Systemsoftware hin. Alternativ übernehmen wir dies auch direkt für den Kunden sollte dessen Zeit oder Wissen dafür nicht ausreichen. Wer sich selbst um diese Tätigkeiten kümmern will, dem raten wir auch immer einen Blick in die php.ini zu werfen. Was viele vielleicht nicht wissen ist, dass falsche PHP-Sicherheitseinstellungen ebenfalls häufig eine potenzielle Sicherheitslücke für Angreifer von außen darstellt.
In einem älteren Beitrag habe ich bereits zahlreiche Tipps zur Absicherung von Webprojekten gegeben. In diesem Artikel gehe ich nochmal kurz speziell auf die sicherheitsrelevanten Einstellungen in der php.ini ein. Bei der php.ini handelt es sich um eine Konfigurationsdatei die beim Start von PHP eingelesen wird.
Sicherheitskritische php.ini Einstellungen
In aktuellen PHP Versionen sind die Sicherheitsvoreinstellungen bereits gut. Einstellungen wie Register_Globals=On und ähnliches sind schon lange nicht mehr Standard. Vorsicht walten lassen muss man bei PHP Paketen, die mit den Linux Distributionen kommen. Hier sollte man auf jeden Fall die Einstellungen mit der Original php.ini-production vergleichen.
allow_url_fopen
Wird dies auf ON gestellt könnenauch Dateien von externen Servern durch PHP-Scripte eingebunden werden. Um dies zu verhindern und nur lokale Dateien einzubinden, empfiehlt sich die Einstellung OFF zu wählen (falls möglich).
allow_url_include
Hier ist die empfohlene Einstellung auf OFF zu setzen. Dadurch wird verboten, dass URLs (z.B. http:// oder ftp://) in Verbindung mit include oder required als Anweisungen verwendet werden können.
disable_functions
Hier kann man eine Liste an PHP Funktionen eintragen, deren Benutzung gesperrt werden soll.
Beispiel: disable_functions = system, shell_exec, popen, pclose, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate, exec, passthru, show_source, readfile, escapeshellcmd, escapeshellarg Alle aufgeführten Funktion werden deaktiviert und können daher nicht mehr in PHP Skripten verwendet werden. Vorsicht: Es gibt immer noch zahlreiche Skripte die einige dieser Funktionen benötigen. Deren Funktionalität sollte überprüft werden.
display_errors und error_reporting
Möchte man nicht, dass der Angreifer anhand von Fehlermeldungen etwas über die eingesetzten Skripte oder Webverzeichnisstrukturen erfährt, dann deaktiviert man diese Einstellung am Besten mittels OFF
expose_php
Wir empfehlen diese Einstellung auf OFF zu setzen. Dadurch wird im HTTP Header folgende Zeile nicht mitgeschickt:
X-Powered-By: PHP/5.3.x-pl8-gentoo Dies ist zwar nicht wirklich eine Sicherheitseinstellung, aber man muss dem Angreifer ja nicht auf die Nase binden, welche PHP Version man tatsächlich benutzt. Wie man in diesem Beispiel sieht, kann man hieraus auch erkennen, welche Linux Distribution verwendet wird - Informationen, die für Angreifer sehr nützlich sind.
error_log
Hier wird der Speicherort des Error-Logfiles festgelegt damit man diese wieder findet - für den Fall.
log_errors
Komplementär zu display_errors
open_basedir
Hier kann man festlegen, auf welche Verzeichnisse innerhalb eines PHP Skriptes zugegriffen werden darf (was außerhalb des hier definierten Pfades liegt wird nicht geöffnet werden können). Vorsicht ist geboten, da bestimmte Funktionen diese Einschränkung nicht beachten (siehe disable_functions). Hierbei sei besonders die Erweiterung curl genannt!
register_globals
Wie bereits zu Beginn erwähnt ist das ab PHP 5.3.0 veraltet. Eine Deaktivierung mittels OFF verhindert, dass von Benutzern übergebene Variablen andere Variablen im Code überschreiben können.
safe_mode
Ist ab PHP 6 nicht mehr enthalten ich erwähne es trotzdem. Es überprüft bei Zugriffen auf das Dateisystem ob die Benutzerrechte des ausführenden Skripts mit denen der Datei übereinstimmen. Falls nicht, wird ein Fehler ausgegeben. Sollte im Zweifelsfall immer auf OFF stehen.