Frage Sicherung von PHP Webservern


PHP-Anwendungen sind bekannt für überdurchschnittliche Sicherheitsprobleme. Welche Konfigurationstechniken verwenden Sie, um sicherzustellen, dass die Anwendung so sicher wie möglich ist?

Ich suche nach Ideen wie:

Ich verwende normalerweise Linux, aber ich kann auch Windows-Lösungen vorschlagen.


30
2018-06-06 09:26


Ursprung




Antworten:


  1. Verwenden Sie die Anweisung open_basedir, um Ihre PHP-Skripte auf ihr Home-Verzeichnis und eventuelle zusätzliche Anwendungsverzeichnisse zu beschränken. Dies ist an sich sehr effizient.

  2. Verwenden Sie gehärtetes PHP, weil das nichts kostet und es kann helfen.

  3. Benutzen suPHP PHP-Skripte ausführen als Besitzer der Datei (ein Benutzer pro Website) und vermeiden Sie die Verwendung von Dateien mit schlechten Berechtigungen wie 777 ... suPHP können Sie auch auf php.ini pro Website haben, so dass eine Website dumme Anforderung don Zerstöre nicht alles.

  4. Mod_security ist ein großes Plus, muss aber gut genutzt und konfiguriert werden.


15
2018-06-06 09:36



Einige schlechte Seiten benötigen eigentlich register_globals und fopen, deshalb verwenden Sie eine php.ini pro Seite mit suPHP. Eine Seite kann nur Kamikaze gehen und die anderen sind (fast) vollkommen sicher. - Antoine Benkemoun
Wenn sie register_globals und fopen verwenden, deutet das darauf hin, dass die Qualität so schlecht ist, dass du sie vielleicht noch einmal überdenken solltest :) - David Pashley
Wenn sie 150 € / Monat bezahlen, überdenkst du es nicht. - Antoine Benkemoun


Nach meiner Erfahrung sind die meisten Sicherheitslücken auf einer PHP-basierten Website das Ergebnis von schlechtem (Site-) Design und nicht von Fehlern in PHP selbst.

Einige kurze Tipps:

  • Allgemein Filtereingang, Escape-Ausgang. Klärung: Filter bedeutet nicht Flucht, es bedeutet "wenn ich etwas faul in dieser Benutzereingabe finde, verursachen die Einreichung fehlschlagen und den Benutzer zu formatieren."
  • Anstatt einfach die Funktion escapeshellcmd () zu verwenden Lassen Sie keine Benutzereingaben in der Shell ausführen. Das ist gefährlich und wahrscheinlich nie wirklich notwendig.
  • Nicht Rufen Sie Funktionen wie phpinfo () auf einer Produktionsstätte auf (oder wenn Sie dies tun, siehe unten *).
  • Beim Entwerfen einer Webanwendung immer Überlegen Sie: "Ist das ein möglicher Angriffsvektor?" Sag, SQL-Injektion. Wenn die Antwort "Ja" ist, schließen Sie es sofort an - sagen Sie nicht "OK, ich werde das später in der Entwicklung als Feature hinzufügen." Sicherheit ist niemals ein Feature.
  • noch nie rohe Fehler an den Benutzer ausgeben; Das bedeutet, dass php.ini display_errors = Off, log_errors = On gesetzt wird. Trap Laufzeitfehler und etwas Hübsches ausgeben. Nehmen wir Twitter's Wal als Beispiel: Es gibt dem Benutzer keine Debug-Level-Informationen, es sagt nur "Woops, etwas kaputt, bitte aktualisieren".

* Du könntest auch einen kurzen Blick auf einen kurzen Beitrag werfen, den ich geschrieben habe "Securing phpinfo (), sort of" und sicher sein, die Kommentare zu lesen http://egovsergo.com/2009/04/03/protecting-your-phpinfo/ Es war eine schnelle Idee, dass ich phpinfo () irgendwie schützen musste, wenn ich irgendwie vergessen hatte, es auf einer Produktions-Site zu entfernen.

Allgemeiner ausgedrückt schreiben einige Entwickler Wrapper für sensitive Funktionen, die prüfen, ob das Flag "Produktionsstandort" gesetzt ist oder nicht, und die sensible Funktion in der Produktion deaktiviert.


3
2018-06-07 16:35



Meine Frage war mehr, wie man seinen Server gegen schlecht geschriebenes PHP schützt. :) Ich meinte nicht, dass PHP selbst unsicher ist, eher, dass es weniger erfahrene Entwickler anzieht und die Standard-Bibliothek verlangt, dass sie daran denken, jeden Anruf zu schützen, anstatt die Bibliothek, die alle Benutzer schützt. +1, da es eine sehr nützliche Antwort ist. - David Pashley
Ich habe diesen Eindruck und antwortete entsprechend :) Danke für den Kommentar! Ich kann hier natürlich nicht alles erklären, aber das sind einige große Gruben. Wenn Sie spezifischere Fragen haben, können Sie sie sicher auf Stack Overflow platzieren und ich und alle anderen werden dazu beitragen. (Und was es wert ist, ich bin ein ZCE). - msanford


Andere Parameter, die geändert werden sollten, um das PHP zu härten:

safe_mode = Off
register_globals = Off
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
log_errors = On
error_log = /var/log/phperror.log
display_errors = Off
enable_dl = Off
disable_functions="popen,exec,system,passthru,proc_open,shell_exec,show_source,phpinfo"

Speichern Sie alle PHP-Fehler in der Datei /var/log/phperror.log:

touch /var/log/phperror.log
chmod 666 /var/log/phperror.log

3
2017-11-23 07:48





Ich habe das hinzugefügt Dotdeb Repositories zu meiner /etc/apt/sources.lst

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Sie puften PHP / Apache / MySQL viel häufiger als Debian tut.


1
2018-06-06 13:15





Berücksichtigen Sie die Einrichtung open_basedir auf einer "pro Seite" Basis. open_basedir ist eine Einstellung von php.ini, die verhindert, dass Ihre Skripte auf Dateien außerhalb einer definierten weißen Liste zugreifen. Wenn Ihr Server mehrere Websites hostet, wird verhindert, dass eine Website die Datenbankeinstellungen von einer anderen Website liest. Es verhindert auch, dass ein PHP-Skript auf Core-Systemdateien zugreift / ändert. Open basedir ist einfach einzurichten, fügen Sie einfach die Zeile hinzu "php_admin_value open_basedir /my/list/of/folders:/as/a/colon/seperated/list"zu jedem Apache vhost.

Denken Sie auch daran, die PHP-Skript-Engine für alle Sites / Ordner abzuschalten, die keine PHP-Skripte enthalten sollten (z. B. einen hochgeladenen Bilderordner). Nochmals, das ist einfach, fügen Sie "php_admin_value engine off" zu jedem Apache VirtualHost hinzu, der php nicht benötigt. Um PHP in einem Verzeichnis zu deaktivieren, fügen Sie dasselbe in ein Directory-Tag ein.

Führen Sie die Dateiberechtigungen so eng wie möglich aus, vermeiden Sie Schreibzugriff auf PHP-Skripte für den Apache-Benutzer. Dies verhindert, dass ein ausgeführtes Skript sich selbst oder andere Skripts auf derselben Site / demselben Server ändert. Vermeiden Sie 777 Berechtigungen, wenn überhaupt möglich, ermitteln Sie die Mindestberechtigungen, die zum Ausführen der Anwendung erforderlich sind, und verwenden Sie diese.

Wenn Sie mehrere Websites mit jeweils einer eigenen Datenbank hosten, verwenden Sie für jeden Benutzer einen eigenen MySQL / Postgres-Benutzer und legen Sie Berechtigungen für jeden Benutzer so fest, dass er nur auf die relevanten Datenbanken zugreifen kann. Auch dies verhindert, dass ein Rogue-Skript die Datenbank einer anderen Anwendung manipuliert.

Suosin, HardenedPHP, mod_security und Ähnliches sind ebenfalls wertvoll, verwenden sie aber zusätzlich zu einer fest abgesperrten Konfiguration, nicht statt.


1
2018-06-16 06:12





Suhosin hat einen recht hohen Leistungsaufwand, so dass der Kommentar "kostet nichts" ein bisschen daneben liegt.


0
2018-06-06 15:30



Was nützt eine schnelle, gehackte Website? :) gehärteter - php.net/suhosin/benchmark.html schlägt bei einer Benchmark um 8,85% langsamer vor. Das mag für die Sicherheitsvorteile, die es bietet, akzeptabel sein. Dies sollte eher ein Kommentar als eine Antwort gewesen sein. - David Pashley
Suhosin schützt primär vor lokalen Angriffen. Wenn Sie also Ihren Server mit Leuten teilen, denen Sie nicht vertrauen, lohnt sich die Verlangsamung. Wenn Sie Ihren eigenen Server oder Ihre eigene VM-Schicht haben, sehe ich den Punkt nicht.


Suchen Sie nach grundlegenden Firewall / Topologie-Vorschlägen? Ich mag die Idee, Dinge wie zu verwenden Pfund um den Zugriff auf den PHP-Webserver von den ungewaschenen Internets zu verhindern. Auf diese Weise können Sie den Webserver auch von anderen Teilen Ihres Netzwerks trennen.


0
2018-06-06 19:47



Nein, ich suche nach Möglichkeiten, die Sicherheit der PHP-Laufzeit zu verbessern. - David Pashley


Die Verwendung von Suhosin / mod_security / SuPHP wird Ihren PHP-Server sicher machen. Die Deaktivierung bestimmter Funktionen wie exec, passthru, system und escapeshellcmd wird ebenfalls sehr hilfreich sein.


0
2018-06-07 00:39



Wird nicht escapeshellcmd () nur verwendet, um die Zeichenfolge zu entkommen? Es bietet keine Möglichkeit, einen Prozess auszuführen. Wie könnte jemand damit ein Problem verursachen? - David Pashley