Question Quelles mises à jour Red Hat / CentOS doivent être appliquées et selon quel calendrier?


Je suis abonné à la liste de diffusion CentOS-advert et j'ai lu les définitions des différentes balises de gravité telles que Critique, Important, Modéré, Faible, BugFix, etc., mais je ne comprends toujours pas ce qui doit vraiment être fait. et ce qui peut attendre (car je dois justifier une interruption de notre travail régulier pour obtenir les mises à jour).

Jusqu'à présent, j'ai essayé d'appliquer les mises à jour critiques dans nos environnements de production le plus rapidement possible.

Quel est le calendrier normal d’application de ces mises à jour? Elles se produisent si souvent que nous ne pouvons pas toutes les appliquer rapidement car elles doivent être testées pour nous assurer qu'elles n'ont pas endommagé nos systèmes.

Pour le contexte, nous exploitons principalement un site Web et il n'y a aucun utilisateur supplémentaire sur le système. Par conséquent, je ne m'inquiète généralement pas des "exploits locaux" autant que des exploitations distantes. Mais j'estime que je ne sais toujours pas comment appliquer au mieux ces mises à jour.

Merci,


4
2017-12-15 15:38


origine




Réponses:


Je gère plusieurs sites Web pour différents clients et c'est généralement ce que je fais.

Tout d’abord, la priorité absolue des mises à jour de sécurité doit être l'application web elle-même. La grande majorité des attaques cibleront votre site Web et le code qui l’exécute, ce qui doit être sécurisé. Si vous utilisez des applications Web prêtes à l'emploi, c'est un endroit où je considérerais même automatique mises à jour, mais en aucun cas je ne laisserais une mise à jour de sécurité pour quelque chose comme WordPress ou Drupal plus de 24 heures avant de la tester et probablement de la déployer.

Si votre application Web est conçue sur mesure, assurez-vous que vos développeurs sont au courant des problèmes de sécurité, dans la mesure du possible. Il s'agit d'un scénario dans lequel votre entreprise devrait utiliser DevOps pour s'assurer que les développeurs Web et le service informatique travaillent bien ensemble et que les problèmes sont résolus rapidement.

Après cela, les prochaines mises à jour critiques que je considère sont celles qui "deviennent virales" et dont vous entendez parler dans les actualités nationales, telles que Heartbleed, POODLE, etc., ainsi que des mises à jour de tout élément du chemin critique, comme nginx et PHP pour. Sites Drupal et WordPress. J'applique des mises à jour pour celles-ci dès qu'elles sont disponibles. Je suis aussi sur les listes de diffusion pour les paquets en amont (par exemple, je suis abonné à openssl-advert) afin que je reçoive une notification le plus tôt possible pour des choses vraiment importantes.

Ensuite, j'applique des mises à jour à chaque serveur public (front-web, équilibreurs de charge, etc.) et à chaque serveur de support (bases de données, etc.) une fois par mois. Cela inclut tous les restes de sécurité et les mises à jour de correctifs de bogues. Dans de nombreuses organisations, cela se fait tous les trimestres, mais j’estime que les sites Web publics, en particulier ceux qui font du commerce électronique, ne devraient pas être laissés pourris aussi longtemps. Je le fais presque toujours le week-end après le correctif de Microsoft de mardi, ce qui est presque toujours suffisamment de temps pour entendre parler des mauvaises mises à jour de Microsoft (bien que je sois principalement sous Linux, il est plus facile d'avoir un week-end pour tout mettre à jour).

Enfin, je m'assieds, me détends et attends de voir ce qui se casse. Malgré tous vos efforts pour tester les mises à jour, il se peut que quelque chose se passe mal. Surveillez votre système de surveillance. Si quelque chose ne se surveille pas, corrigez-le, puis commencez à le surveiller. Préparez-vous à la restauration (yum history undo est utile).


10
2017-12-15 16:21



Hmmm, j'ai rarement eu besoin d'annuler des mises à jour sur des systèmes RHEL / CentOS. - ewwhite
@ewwhite J'ai rarement eu besoin de revenir en arrière, mais je le mentionne car beaucoup de personnes ignorent que la fonctionnalité existe et ont peur de mettre à jour car elles ne savent pas comment revenir en cas de problème. - Michael Hampton♦
Merci pour cette excellente réponse détaillée. Une question: je sais que les mises à jour critiques doivent être appliquées dès que possible, mais qu'en est-il de l'importance / modéré / faible? Le libellé de la documentation me fait me demander si cela devrait être fait rapidement ou non. - Shovas
@ user10330 Les mises à jour de sécurité CentOS sont basées sur les mises à jour de sécurité correspondantes de Red Hat. Red Hat les classe. Comme vous pouvez le constater, les plus importants peuvent toujours être assez critiques, selon votre scénario. - Michael Hampton♦
@MichaelHampton On dirait donc que vos priorités sont (1) les paquetages tiers non CentOS, (2) les vulnérabilités critiques + virales, (3) les mises à jour CentOS critiques, (4) les mises à jour CentOS importantes / modérées / faibles mensuelles. Est-ce exact? - Shovas


Pour une très grande partie ça dépend.

Il est évident que les mises à jour de sécurité critiques sont généralement mieux installées. Dès que possible, mais vous seul connaissez votre infrastructure et votre plate-forme. Ce qui est ASAP est spécifique à vous. Si vous utilisez un serveur Web, quelque chose de récent, par exemple:

"CESA-2014: Mise à jour de sécurité critique pour CentOS 7 de 1919 pour Firefox" 

n'est pas un problème pour vous. Pas besoin de se précipiter. Si vous utilisez des stations de travail 500 CentOS, cet erratum peut en effet être crucial et vous pousseriez une telle mise à jour sans aucun test ou avec un minimum de tests.
Une telle décision devrait résulter d'une évaluation d'impact / de risque, éventuellement avec l'aide de votre responsable de la sécurité.
D'autre part, pour vous, le risque peut être atténué car tous les postes de travail sont obligés d'utiliser un proxy Web qui bloquera déjà ce contenu malveillant et que 500 utilisateurs très payés de ces postes de travail ne pouvant pas fonctionner correctement peuvent se lever un risque inacceptable aussi. Alors, ASAP signifie après des tests minutieux.

En revanche, les corrections de bogues ne sont souvent pas importantes et peuvent attendre, à moins que votre environnement ne souffre activement de ces bogues, vous souhaiterez peut-être résoudre ce problème dès que possible.

Le serveur Satellite ou le projet Spacewalk de Red Hat a simplifié la tâche. Pour chaque système enregistré, vous pouvez voir quels correctifs et mises à jour sont applicables, ainsi que l’inverse, pour chaque Erratum, combien de systèmes sont affectés. C'est beaucoup plus agréable qu'une liste de paquets qui ont des mises à jour possibles en attente

Certaines organisations avec lesquelles j'ai travaillé avaient des applications très simples qui permettraient de patcher automatiquement les serveurs. "Nous faisons confiance à Red Hat".
D'autres avaient deux versions internes où tous les errata seraient accumulés et seules les mises à jour critiques spécifiques, exploitables à distance, seraient déplacées en dehors de cette planification. Et un ou deux qui ont également été jugés essentiels pour notre organisation. En dehors de la production, appliquez les mises à jour avant le début du jour ouvrable et effectuez des tests obligatoires le matin. En production, pas plus de 24 heures après la publication de la mise à jour.


2
2017-12-15 16:36