Blog

Ici nous vous tenons informés des prochains événements de la communauté Drupal et de notre veille !

Bilan #Drupalgeddon

slybud
29/06/2018
Sécurité : Retour sur les épisodes #DrupalGeddon 2018 @OWS et @OWNS
Photo de l'équipe OWS au travail le soir du DrupalGeddon2

Autant 2015, 2016, 2017 ont été des années relativement "normales" en termes de failles de sécurité sur notre CMS préféré (le dernier épisode hautement critique datant d'octobre 2014 : faille Sql injection connue sous le nom de "Drupalgeddon"), autant 2018 aura démarré déjà bien fort en nous proposant 2 failles hautement critiques dans le core drupal, toutes version confondues (8, 7 et même Drupal 6, car oui, il existe encore des Drupal6/Pressflow en production, ne faites pas les innocents).

Je profite de ce billet de blog pour féliciter toutes les équipes OWS et OWNS pour leur implication, leur préparation et leur professionnalisme au cours de ces deux événements. Pour rappel, la publication de ce genre de failles nécessite des réactions dans l'heure afin de garantir la sécurité des sites de nos clients et la non compromission de leurs systèmes d'information.

Petit rappel du (bon) déroulement des opérations , n'hésites pas à nous contacter si vous souhaitez en savoir plus ou voir comment nous pourrions vous aider à mettre ces process en place. Pour les clients disposant d'un contrat de TMA chez OWS, cela s'est passé de la manière suivante :

  • Veille technologique hebdomadaire de nos architectes techniques et lead développeurs, ayant permis de prendre connaissance une semaine avant de la SA et de la fenêtre de release des patches
  • Mobilisation des équipes pour réserver du temps de travail sur ce créneau inhabituel (20h-22h pour le premier épisode) et vérifier la disponibilité de chacun
  • Vérification de l'état de toutes les instances (preprod et prod) des drupal maintenus
  • Déploiement éventuel des développements/mises à jour en attente ou création des branches git adéquates
  • Vérification de l'intégration continue pour tous ces projets
  • Recensement des hébergeurs tiers et prise de contact pour les prévenir des déploiements nécessaires sur le créneau visé
  • Répartition des clients sur tous les membres de l'équipe disponible (à la fois pour l'application des patches, mais aussi pour les déploiements/l'intégration continue et la recette technique après déploiement)
  • Alerte de tous les clients de l'opération à venir
  • Attente du jour J et de l'heure H

En parallèle, les administrateurs systèmes de notre filiale Open Web Network Solutions ont mis en place les actions suivantes :

  • Mobilisation des équipes pour réserver du temps de travail sur ce créneau inhabituel (20h-22h pour le premier épisode) et vérifier la disponibilité de chacun
  • Préparation d'un script d'orchestration permettant de
    • recenser automatiquement toutes les instances drupal d'un serveur
    • recenser les fichiers concernés par le patch de sécurité
    • appliquer automatiquement le patch de sécurité à ce fichier
    • sortir un rapport détaillé pour les éventuelles actions manuelles à mener pour de rares cas
  • Tests de ce script sur des infras de dev
  • Prévenir les clients (hors TMA OWS

Résultat : à l'heure H du jour J, dans une ambiance détendue et d'équipe, avec de la restauration livrée dans les locaux pour ceux qui étaient sur place à l'agence, il nous a fallu 2 heures pour mettre à jour et sécuriser des centaines d'instance drupal et aller se coucher apaisés :) . Aucun site n'a d'ailleurs été compromis grâce à ces actions

Donc encore bravo et merci à toute l'équipe et aux process/méthodes éprouvées pour la TMA et linfogérance Drupal.

Pour références/aller plus loin :