Paranoid Sysadmin -vs- Veraltete PHP-Version

Wie kann ein paranoider Systemadministrator sicher mit den neuesten stabilen PHP-Versionen auf dem Laufenden bleiben? (Sicherheitskorrekturen wurden ziemlich regelmäßig durchgeführt).

Dies ist ein Produktionsserver, und so erschreckt "das Brechen von Sachen" meinen Kerl zu Tode. Ausfallzeiten für die Wartung sind nicht das Problem.

Insbesondere führen wir ein aktuelles Suse Enterprise Linux aus, aber eine allgemeine oder allgemeinere Antwort ist durchaus akzeptabel.

Wie gehen Sie mit Sicherheitsupdates für Produktionsmaschinen um? Was wissen wir so wenig darüber, dass dieser Typ solche Angst hat, nur den Paketmanager zum "Aktualisieren" zu verwenden?

Irgendein Rat?

Ich gehe mit PHP genauso um wie mit allem anderen: Aktualisieren Sie zuerst die Entwicklungsumgebung (einen VMWare-Produktionsklon), testen Sie die Regression und fördern Sie sie dann mit denselben Bereitstellungsvorlagen, die wir für die VMWare-Hosts verwendet haben, für die Produktion. (Wenn Sie Paketmanager für Ihre Upgrades verwenden, verwenden Sie dieselben Pakete.)

Als zusätzliche Isolationsschicht besteht unsere Produktionsumgebung aus gepaarten redundanten Hosts, und ein Host wird für sein Upgrade aus der Produktionsrotation genommen und anschließend gründlich getestet, bevor wir zu diesem Host wechseln, um seinen Partner zu aktualisieren.

In der Regel werden Sicherheitsupdates so schnell wie möglich angewendet, und nicht sicherheitsrelevante / nicht kritische Bugfix-Updates werden vierteljährlich angewendet, um Ausfallzeiten zu minimieren.

PHP ist auf meiner Top-Liste der Dinge, die auf die aktuelle Version aktualisiert werden sollen. Ich vertraue es weniger als die meisten Dinge.

Letztendlich ist es am besten, jedes Änderungsprotokoll von Ihrer aktuellen Version bis zur neuesten Version zu überprüfen und das Risiko greifbar abzuwägen.

Wenn Sie über das Upgrade kleinerer Versionen wie 5.3.1 auf 5.3.2 sprechen, würde ich mir keine Sorgen machen.

Wenn Sie ein Upgrade von 5.2.x auf 5.3.x durchführen, treten wahrscheinlich einige Kompatibilitätsprobleme auf.

Wenn Sie Systempakete verwenden, führen Distributionen normalerweise keine Upgrades ein, die die vorhandene Leistung beeinträchtigen. RHEL und CentOS patchen alte Versionen für Korrekturen, bis eine wichtige Distributionsversion herauskommt. In der Regel werden die Tests für Sie durchgeführt, wodurch das Risiko verringert wird. Ich würde erwarten, dass SuSE Enterprise ähnlich ist.

Für Upgrade-Pfade ist es am besten, einen Testserver zu erstellen und die Anwendung vor dem Upgrade der Produktion mit der neuesten Version zu testen.

Eine andere, weniger geschätzte Antwort besteht darin, eine Whitelist mit zulässigen URLs und Funktionen zu erstellen. In Apache können Sie dies tun, indem Sie die Proxy- und Rewrite-Funktionen kombinieren.

Grundsätzlich führen Sie zwei Installationen durch, eine mit einer reduzierten Konfiguration: Proxy, Umschreiben und keine Codeausführung; usw. Jede "erlaubte" URL (mit Parametern usw.) wird an die zweite Installation weitergeleitet.

Fügen Sie sich dann zur Entwicklerliste von PHP hinzu und überwachen Sie die Versionshinweise sorgfältig. Jedes Mal, wenn Sie etwas sehen, das wie eine Sicherheitslücke aussieht, erstellen Sie bei der ersten Installation eine Unterlegscheibe, um diese Art von Fehler zu erkennen, und senden dem Benutzer einen Fehler.

In einem solchen Setup möchten Sie POST zu einem Filter umleiten (wenn Sie POST überhaupt benötigen; einige Sites kommen gut zurecht, indem Sie POST nur von einigen IP-Adressen zulassen!), Der nach zulässigen Quellen suchen kann und vorab alles validieren.

Das Einrichten einer solchen Whitelist ist sehr zeitaufwändig. Für geschäftskritische Apps, die länger als die stabile Lebensdauer von PHP (die nur wenige Jahre zu betragen scheint) ausgeführt werden müssen, kann dies eine hervorragende Möglichkeit sein, die große Anzahl von PHP zu nutzen Anwendungen, ohne auch ihre Schwachstellen zu bekommen.

Darüber hinaus können Sie für alle Fälle Paket-Rollbacks aktivieren.

Wenn dann in der Produktion etwas kaputt geht, von dem Sie absolut sicher waren, dass es bei der Entwicklung einwandfrei funktioniert , können Sie die Änderung zumindest schnell rückgängig machen, bevor Sie das Problem beheben.

Ein Beispiel in Yum finden Sie unter Rollback YUM-Paket . Ich bin sicher, dass andere Paketverwaltungssysteme ähnliche haben.

Ich weiß, dass es sich um Gürtel und Hosenträger handelt, und ich stimme Warner mit Punktveröffentlichungen zu. Kleinere Änderungen sollten nichts beschädigen. Persönlich hatte ich keine Probleme mit PHP-Upgrades, aber es ist immer besser, auf Nummer sicher zu gehen.