Paranoid Sysadmin -vs- Version PHP obsolète

Comment un administrateur système paranoïaque peut-il rester en toute confiance à jour avec les dernières versions PHP stables? (des correctifs de sécurité sont arrivés assez régulièrement).

Il s'agit d'un serveur de production, et donc "casser des trucs" fait peur à mon gars. Le temps d'arrêt pour la maintenance n'est pas le problème.

Plus précisément, nous exécutons un Suse Enterprise Linux récent, mais une réponse générique ou plus générale est parfaitement acceptable.

Comment gérez-vous les mises à jour de sécurité des machines de production? De quoi sommes-nous si ignorants que ce type a si peur d'utiliser le gestionnaire de paquets pour "mettre à jour"?

Aucun conseil?

Je gère PHP de la même manière que je gère tout le reste: mettez à niveau l'environnement de développement (un clone de production VMWare) d'abord, testez la régression, puis promouvez-le en production en utilisant les mêmes modèles de déploiement que nous avons utilisés pour les hôtes VMWare. (Si vous utilisez des gestionnaires de packages pour effectuer vos mises à niveau, vous utiliseriez les mêmes packages).

En tant que couche d'isolation supplémentaire, notre environnement de production est composé d'hôtes redondants couplés, et un hôte est retiré de la rotation de production pour sa mise à niveau, puis testé minutieusement avant de passer à cet hôte pour mettre à niveau son partenaire.

En règle générale, les mises à jour de sécurité sont appliquées dès que possible et les mises à jour de correctifs de bogues non sécuritaires / non critiques sont appliquées tous les trimestres pour minimiser les temps d'arrêt.

PHP est sur ma première liste de choses à garder à jour avec la version actuelle. Je lui fais moins confiance que la plupart des choses.

En fin de compte, votre meilleur pari est de revoir chaque journal des modifications de votre version actuelle à la dernière et de peser le risque de manière tangible.

Si vous parlez de mettre à niveau des versions mineures, telles que 5.3.1 vers 5.3.2, je ne m'inquiéterais pas trop.

Si vous effectuez une mise à niveau de 5.2.x vers 5.3.x, vous risquez d'introduire des problèmes de compatibilité.

Si vous utilisez des packages système, les distributions n'introduiront généralement pas de mises à niveau qui perturberont les performances existantes. RHEL et CentOS corrigent les anciennes versions des correctifs jusqu'à ce qu'une version de distribution majeure sorte. Faites les tests pour vous, généralement, ce qui réduit les risques. Je m'attendrais à ce que l' entreprise SuSE soit similaire.

Pour les chemins de mise à niveau, le meilleur pari serait de construire un serveur de test et de tester l'application par rapport à la dernière version avant de mettre à niveau la production.

Une autre réponse, moins appréciée, consiste à créer une liste blanche des URL et fonctionnalités autorisées. Dans Apache, vous pouvez le faire en combinant les fonctionnalités de proxy et de réécriture.

Fondamentalement, vous effectuez deux installations, dont l'une a une configuration simplifiée: proxy, réécriture et aucune exécution de code; etc. Toute URL "autorisée" (avec paramètres, etc.) obtient un proxy pour la deuxième installation.

Ensuite, ajoutez-vous à la liste des développeurs de PHP et surveillez attentivement les notes de version. Chaque fois que vous voyez quelque chose qui ressemble à une vulnérabilité de sécurité, vous créez un shim lors de la première installation pour détecter ce type d'échec et envoyez à l'utilisateur une erreur.

Dans une configuration comme celle-ci, vous voudrez rediriger le POST vers un filtre (si vous avez besoin du POST du tout; certains sites se débrouillent très bien en n'autorisant le POST qu'à partir de certaines adresses IP!) Qui peuvent rechercher les sources autorisées et pré- valider tout.

Une telle liste blanche prend beaucoup de temps à configurer, mais pour les applications critiques qui doivent fonctionner plus longtemps que la durée de vie stable de PHP (qui ne semble être que de quelques années), cela peut être un excellent moyen de tirer parti du grand nombre de PHP applications sans obtenir leurs vulnérabilités ainsi.

En plus de ce qui précède, vous pouvez activer la restauration des packages au cas où.

Ensuite, si quelque chose se casse sur la production dont vous êtes absolument sûr qu'il fonctionnait bien sur le développement , vous pouvez au moins annuler rapidement la modification avant de résoudre le problème.

Voir Package Rollback YUM pour un exemple dans Yum. Je suis sûr que d'autres systèmes de gestion de paquets ont des caractéristiques similaires.

Je sais que ce sont des ceintures et des bretelles et je suis d'accord avec Warner avec les sorties de points. Des changements mineurs ne devraient rien casser. Personnellement, je n'ai eu aucun problème de mise à jour de PHP, mais il vaut toujours mieux prévenir que guérir.