PHP-GTK

Créé en 2014 sur la base des plugins Munin d'AirBnB pour Beanstalkd en Python, le package OSInet beanstalk-munin-php est dorénavant disponible en version 1.0.0. Ces plugins pour Munin 2.x permettent la surveillance des métriques suivantes: ... [More] bs_cmd_rate.php : fréquence des commandes put, reserve, reserve_timeout, delete, touch, release et bury bs_connections.php : gauge des connexions ouvertes bs_jobs_rate.php : dérivée du nombre total de travaux traités bs_queue_age.php : gauge de la durée d'attente des travaux dans les tubes (files) bs_queue_size.php : gauge du nombre de travaux par état: ready, urgent, reserved, delayed, buried bs_timeouts.php : dérivée du nombre de timeouts par unité de temps Ces plugins sont publiés sous licence Apache APL-2.0, et conformes aux normes PHP-FIG: PSR1, PSR2, PSR12 et au standard de codage Zend. [Less]

Créé en 2014 sur la base des plugins Munin d'AirBnB pour Beanstalkd en Python, le package OSInet beanstalk-munin-php est dorénavant disponible en version 1.0.0. Ces plugins pour Munin 2.x permettent la surveillance des métriques suivantes: ... [More] bs_cmd_rate.php : fréquence des commandes put, reserve, reserve_timeout, delete, touch, release et bury bs_connections.php : gauge des connexions ouvertes bs_jobs_rate.php : dérivée du nombre total de travaux traités bs_queue_age.php : gauge de la durée d'attente des travaux dans les tubes (files) bs_queue_size.php : gauge du nombre de travaux par état: ready, urgent, reserved, delayed, buried bs_timeouts.php : dérivée du nombre de timeouts par unité de temps Ces plugins sont publiés sous licence Apache APL-2.0, et conformes aux normes PHP-FIG: PSR1, PSR2, PSR12 et au standard de codage Zend. [Less]

If you're reading the PHP-GTK.eu community site these days, you certainly noticed that not a single piece of significant content was created since 2015, and not much since 2013. Whatever this may mean for PHP-GTK itself is another issue, but for the ... [More] site itself, it means it ceased to be relevant about 5 years ago, and it's time to move on for the site members. Since the site contains non-anonymous user, it will fall under the new EU GDPR regulations entering into force on 2018-05-25, and there is no point for me to spend time on evolving the site towards compliance when no one is actually using it. So here is the EOL announcement: the site will be shutting down on 2018-05-24 and its data will taken offline. A static version of the articles may be published again at some point here or elsewhere, but I wouldn't hold my breath on it. So if you have even some interest in the site content, be sure to copy/paste the pages of interest before it goes dark on 2018-05-24. Or contact me if you want a copy of the files and content, or check my blog for newer content. Thanks all for participating, it's been a pleasure while it lasted. read more [Less]

Le 23/04/2018, la Security Team de Drupal a annoncé dans son "Public Service Announcement" PSA-2018-003 la sortie imminente de versions de sécurité pour Drupal, le mercredi 25/04/2018 entre 18h00 et 20h00 heure de Paris, hors du calendrier normal ... [More] de publication des mises à jour de sécurité Drupal. Depuis la publication d'un exploit basé sur PSA-2018-001, surnommé "Drupalgeddon 2", des bots attaquent à la chaîne les serveurs non protégés; Acquia signale avoir bloqué plus de 500 000 attaques depuis plus de 3000 adresses en une seule semaine. Mises à jour 25/04/2018 19h15: les mises à jour sont disponibles par Composer, plus besoin de passer par le patch 25/04/2018 18h50: Drupal 6 est concerné aussi et un patch D6LTS est disponible, et le patch pour D8 s'applique aussi à 8.3.x D6: attention, il y a 2 patches, un pour Drupal core et l'autre pour le module contrib CCK filefield, sur https://www.drupal.org/project/d6lts/issues/2965601 Les patches nécessitent d'avoir soit un Pressflow 6.43 à jour, soit la dernière version Drupal 6 avec le patch SA-CORE-2018-002 25/04/2018 18h40: Le correctif est disponible sous forme de patches pour D7 et D8, sur https://www.drupal.org/sa-core-2018-004 Sévérité / Criticité En temps normal, la couverture de sécurité est limitée aux versions supportées, qui sont actuellement la version courante (8.5.x) et la précédente (7.x). Comme pour Drupalgeddon 2, la mise à jour du 25/04 couvre également la version obsolète 8.4.x, ce qui renforce le niveau de risque estimé de la faille ainsi corrigée, et l'importance d'appliquer la correction dans les meilleurs délais. Rien n'a cette fois été annoncé pour Drupal 8.3.x ou 6.x Quand et comment agir ? Au plus tôt ! Toute la procédure est détaillée point par point dans notre précédent article http://www.osinet.fr/nouvelles/alerte-de-securite-drupal-psa-2018-001 consacré à Drupalgeddon 2. En résumé: préparez votre équipe à une intervention dans la nuit de mercredi à jeudi. Pour plus d'informations La Security Team pas plus qu'aucune tierce partie ne peut communiquer plus d'informations jusqu'à la publication des correctifs. L'annonce du correctif sera publiées sur https://www.drupal.org/security, sur Twitter, et par courriel pour les abonnés à la liste de diffusion de la Security Team, à laquelle il est possible de s'abonner en allant sur sa page de profil sur https://drupal.org (pas sur https://drupal.fr), et en se rendant sur l'onglet My newsletters pour s'abonner à cette liste de diffusion. Les journalistes intéressés par plus d'informations sur les développements de ce sujet sont invités à contacter directement [email protected] pour obtenir une version centrée sur leurs préoccupations. La Security Team publiera un courriel résumé à destination de la presse en même temps que la publication du code et du bulletin de version associé. Cet article, créé par OSInet est mis à disposition selon les termes de la Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 3.0 France. pour faciliter la diffusion de l'information de sécurité de Drupal. [Less]

Le 23/04/2018, la Security Team de Drupal a annoncé dans son "Public Service Announcement" PSA-2018-003 la sortie imminente de versions de sécurité pour Drupal, le mercredi 25/04/2018 entre 18h00 et 20h00 heure de Paris, hors du calendrier normal ... [More] de publication des mises à jour de sécurité Drupal. Depuis la publication d'un exploit basé sur PSA-2018-001, surnommé "Drupalgeddon 2", des bots attaquent à la chaîne les serveurs non protégés; Acquia signale avoir bloqué plus de 500 000 attaques depuis plus de 3000 adresses en une seule semaine. Mises à jour 25/04/2018 19h15: les mises à jour sont disponibles par Composer, plus besoin de passer par le patch 25/04/2018 18h50: Drupal 6 est concerné aussi et un patch D6LTS est disponible, et le patch pour D8 s'applique aussi à 8.3.x D6: attention, il y a 2 patches, un pour Drupal core et l'autre pour le module contrib CCK filefield, sur https://www.drupal.org/project/d6lts/issues/2965601 Les patches nécessitent d'avoir soit un Pressflow 6.43 à jour, soit la dernière version Drupal 6 avec le patch SA-CORE-2018-002 25/04/2018 18h40: Le correctif est disponible sous forme de patches pour D7 et D8, sur https://www.drupal.org/sa-core-2018-004 Sévérité / Criticité En temps normal, la couverture de sécurité est limitée aux versions supportées, qui sont actuellement la version courante (8.5.x) et la précédente (7.x). Comme pour Drupalgeddon 2, la mise à jour du 25/04 couvre également la version obsolète 8.4.x, ce qui renforce le niveau de risque estimé de la faille ainsi corrigée, et l'importance d'appliquer la correction dans les meilleurs délais. Rien n'a cette fois été annoncé pour Drupal 8.3.x ou 6.x Quand et comment agir ? Au plus tôt ! Toute la procédure est détaillée point par point dans notre précédent article http://www.osinet.fr/nouvelles/alerte-de-securite-drupal-psa-2018-001 consacré à Drupalgeddon 2. En résumé: préparez votre équipe à une intervention dans la nuit de mercredi à jeudi. Pour plus d'informations La Security Team pas plus qu'aucune tierce partie ne peut communiquer plus d'informations jusqu'à la publication des correctifs. L'annonce du correctif sera publiées sur https://www.drupal.org/security, sur Twitter, et par courriel pour les abonnés à la liste de diffusion de la Security Team, à laquelle il est possible de s'abonner en allant sur sa page de profil sur https://drupal.org (pas sur https://drupal.fr), et en se rendant sur l'onglet My newsletters pour s'abonner à cette liste de diffusion. Les journalistes intéressés par plus d'informations sur les développements de ce sujet sont invités à contacter directement [email protected] pour obtenir une version centrée sur leurs préoccupations. La Security Team publiera un courriel résumé à destination de la presse en même temps que la publication du code et du bulletin de version associé. Cet article, créé par OSInet est mis à disposition selon les termes de la Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 3.0 France. pour faciliter la diffusion de l'information de sécurité de Drupal. [Less]

Le 23/04/2018, la Security Team de Drupal a annoncé dans son "Public Service Announcement" PSA-2018-003 la sortie imminente de versions de sécurité pour Drupal, le mercredi 25/04/2018 entre 18h00 et 20h00 heure de Paris, hors du calendrier normal ... [More] de publication des mises à jour de sécurité Drupal. Depuis la publication d'un exploit basé sur PSA-2018-001, surnommé "Drupalgeddon 2", des bots attaquent à la chaîne les serveurs non protégés; Acquia signale avoir bloqué plus de 500 000 attaques depuis plus de 3000 adresses en une seule semaine. Mises à jour 25/04/2018 19h15: les mises à jour sont disponibles par Composer, plus besoin de passer par le patch 25/04/2018 18h50: Drupal 6 est concerné aussi et un patch D6LTS est disponible, et le patch pour D8 s'applique aussi à 8.3.x D6: attention, il y a 2 patches, un pour Drupal core et l'autre pour le module contrib CCK filefield, sur https://www.drupal.org/project/d6lts/issues/2965601 Les patches nécessitent d'avoir soit un Pressflow 6.43 à jour, soit la dernière version Drupal 6 avec le patch SA-CORE-2018-002 25/04/2018 18h40: Le correctif est disponible sous forme de patches pour D7 et D8, sur https://www.drupal.org/sa-core-2018-004 Sévérité / Criticité En temps normal, la couverture de sécurité est limitée aux versions supportées, qui sont actuellement la version courante (8.5.x) et la précédente (7.x). Comme pour Drupalgeddon 2, la mise à jour du 25/04 couvre également la version obsolète 8.4.x, ce qui renforce le niveau de risque estimé de la faille ainsi corrigée, et l'importance d'appliquer la correction dans les meilleurs délais. Rien n'a cette fois été annoncé pour Drupal 8.3.x ou 6.x Quand et comment agir ? Au plus tôt ! Toute la procédure est détaillée point par point dans notre précédent article http://www.osinet.fr/nouvelles/alerte-de-securite-drupal-psa-2018-001 consacré à Drupalgeddon 2. En résumé: préparez votre équipe à une intervention dans la nuit de mercredi à jeudi. Pour plus d'informations La Security Team pas plus qu'aucune tierce partie ne peut communiquer plus d'informations jusqu'à la publication des correctifs. L'annonce du correctif sera publiées sur https://www.drupal.org/security, sur Twitter, et par courriel pour les abonnés à la liste de diffusion de la Security Team, à laquelle il est possible de s'abonner en allant sur sa page de profil sur https://drupal.org (pas sur https://drupal.fr), et en se rendant sur l'onglet My newsletters pour s'abonner à cette liste de diffusion. Les journalistes intéressés par plus d'informations sur les développements de ce sujet sont invités à contacter directement [email protected] pour obtenir une version centrée sur leurs préoccupations. La Security Team publiera un courriel résumé à destination de la presse en même temps que la publication du code et du bulletin de version associé. Cet article, créé par OSInet est mis à disposition selon les termes de la Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 3.0 France. pour faciliter la diffusion de l'information de sécurité de Drupal. [Less]

Le 21/03/2018, la Security Team de Drupal a annoncé dans son "Public Service Announcement" PSA-2018-001 la sortie imminente de versions de sécurité pour Drupal, le mercredi 28/03/2018. De telles préannonces sont particulièrement rares, la ... [More] précédente remontant à la faille d'injection SQL "Drupalgeddon" de novembre 2014, et sont réservées aux mises à jour les plus critiques. Sévérité / Criticité En temps normal, la couverture de sécurité est limitée aux versions supportées, qui sont actuellement la version courante (8.5.x) et la précédente (7.x). Fait inhabituel là aussi, la mise à jour du 28 couvre également les versions obsolètes 8.3.x et 8.4.x, et un patch a également été annoncé sur le projet D6LTS pour une mise à jour équivalente sur Drupal 6.x, alors que son support est terminé depuis le 24/02/2016, ce qui renforce le niveau de risque estimé de la faille que corrigent ces mises à jour, et l'importance de les appliquer dans les meilleurs délais. Quand agir ? Mais quels sont ces délais, précisément ? Selon le bulletin PSA-2018-001, les "exploits" de la faille révélée par le correctif pourraient être développés dans les "heures ou jours qui suivent" la publication. En 2014, la faille Drupalgeddon avait commencé à être exploitée dans les 6 heures qui avaient suivi la publication du correctif. Avec l'élévation progressive du niveau de risque des agresseurs, tout permet de supposer que le délai pourrait être encore plus court cette fois. La Security Team annonce une publication des correctifs mercredi entre 18:00 et 20:30 UTC, soit 20:00-21:30 heure de Paris, du fait de l'heure d'été. Une marge de sécurité de 6 heures, comme celle dont ont bénéficié les sites en 2014, mène donc au mieux à 03:30 jeudi matin, et au pire 02:00. Dans tous les cas, une mise à jour le jeudi matin 29/03 court donc un risque important d'arriver trop tard. En résumé: préparez votre équipe à une intervention dans la nuit de mercredi à jeudi. Stratégie de mise à niveau Selon le bulletin PSA-2018-001 et les compléments du project D6LTS, la stratégie recommandée est la suivante: Sites sous drupal 8.5.x ou 7.x: appliquer la version de sécurité publiée dans ce correctif selon la procédure standard. Sites sous Drupal 8.4.x: appliquer immédiatement la version 8.4.x qui sera publiée dans ce correctif, puis planifier une mise à jour vers la plus récente version 8.5.x de sécurité, annoncée pour le mois d'avril. Sites sous Drupal 8.3.x: appliquer immédiatement la version 8.3.x qui sera publiée dans ce correctif, puis planifier une mise à jour vers la plus récente version 8.5.x de sécurité, annoncée pour le mois d'avril. Sites sous Drupal/Pressflow 6.x avec un contrat de support auprès de l'un des prestataires du programme commercial D6LTS: suivre les recommandations spécifiques de ce programme. Sites sous Drupal/Pressflow 6.x sans contrat D6LTS: télécharger le patch disponible sur https://www.drupal.org/project/issues/d6lts et l'appliquer au site avec les commandes de patch standard. Les versions exactes à utiliser pour les mises à jour seront indiquées lors de la publication du correctif. Ces mises à jour de sécurité ne modifieront pas le schéma de base de données par rapport à la dernière version actuellement disponible sur chacune des branches concernées. Attention sur les sites utilisant 8.3.x/8.4.x, le rapport du module update sur le tableau de bord d'administration disponible sur /admin/reports/status indiquera une mise à jour recommandée vers une release 8.5.x plutôt que vers la version de sécurité 8.3.x/8.4.x, mais compte tenu des évolutions entre les versions 8.3/8.4/8.5, ceci présente un risque d'effets de bord non souhaités, et il est donc préférable d'appliquer les mises à jour indiquées par le bulletin de sécurité plutôt que celles indiquées par le site, afin de pouvoir plus sereinement préparer la mise à jour en 8.5.x pour avril 2018. Tactique de déploiement Si votre équipe ou prestataire a d'ores et déjà choisi une tactique, mieux vaut l'appliquer qu'improviser au dernier moment: ce sont ceux qui sont les mieux placés pour connaître les contraintes d'exploitation de votre site. A défaut, quatre principales tactiques sont envisageables pour ce déploiement. Les détails dépendent évidemment de vos processus de déploiement et, le cas échéant, de ceux de l'agence ou infogérant en charge de votre site. Cela étant dit, les grandes lignes tactiques sont les suivantes, et commencent AVANT la publication du bulletin: Avant l'après-midi de mercredi 28, mettre à jour le site à la dernière version courante sur la branche concernée: 8.3.x, 8.4.x, 8.5.x. Ne pas tenter à ce stade une mise à jour précipitée vers 8.5.x, pour éviter toute situation problématique à la veille d'une mise à jour de sécurité critique En fin d'après-midi du 28, préparer une sauvegarde intégrale du/des serveurs, par exemple un snapshot disque. En effet, si un exploit vient à être réalisé avant la fin du déploiement du correctif, seule une restauration intégrale de l'infrastructure - par opposition à une restauration de Drupal seul - permettra de garantir l'absence de maliciel sur les serveurs. S'assurer que cette sauvegarde est terminée pour 20:00, heure de publication annoncée au plus tôt Dès la publication, télécharger le patch s'il est disponible, ou la version complète recommandées sinon, et en extraire un patch. Appliquer immédiatement le patch en production. Cela permet de fermer la faille après seulement quelques minutes de vulnérabilité, avec un niveau de risque fonctionnel des plus limités puisque les sites auront été mis au dernier niveau de correction de bogues avant mercredi (cf premier point). Si cette étape n'est pas appliquée, par exemple du fait de règle interdisant les mises à jour en production dans un processus industrialisé certifié, passer immédiatement au point suivant, sinon la suite des opérations peut attendre jeudi matin pour travailler dans de bonnes conditions. Intégrer la nouvelle version complète au projet, et lui faire passer la suite de tests sur l'environnement de recette/préproduction. Une fois la version validée, la déployer. Fin de l'incident. Si le patch a été déployé dès le début, le niveau de risque est très faible, et le déploiement peut être réalisé sur les serveurs en l'état. Si l'étape du patch a été omise et que la nouvelle mise en production a été réalisée moins de 4h après la publication de la version de sécurité, le risque demeure faible. Mais si, en l'absence de patch, la mise en production a attendu jusqu'au jeudi matin, il est préférable de réaliser un nouveau cliché des serveurs, puis de restaurer la version de la veille et de lui appliquer la nouvelle version avant de revenir en ligne. Le cliché du matin pourra alors être examiné pour rechercher des traces d'éventuelles tentatives d'intrusion durant la période de vulnérabilité. Si les contraintes organisationnelles ne permettent pas de réaliser les étapes précédentes, la méthode la plus prudente consiste à mettre le site hors ligne mercredi juste avant 20:00, avec une page statique signalant le caractère volontaire/prudentiel de cette interruption de service, et ne le remettre en ligne qu'une fois la nouvelle version déployée le lendemain S'il n'est possible ni de suivre les procédures de mise à jour rapides précédentes, ni de mettre le site hors ligne jusqu'à la correction, le plus raisonnable sera de considérer que le site est susceptible d'avoir été exploité, donc réaliser une sauvegarde intégrale des serveurs et des serveurs de logs (journaux) disponible, avant de redéployer sur des machines vierges ou sur la sauvegarde de la veille la version corrigée, puis de procéder à un audit visant à identifier si une pénétration a effectivement eu lieu. A ce stade, la présentation Mon site est hacké, que faire ? pourra vous être utile Pour plus d'informations La Security Team pas plus qu'aucune tierce partie ne peut communiquer plus d'informations jusqu'à la publication des correctifs. L'annonce du correctif sera publiées sur https://www.drupal.org/security, sur Twitter, et par courriel pour les abonnés à la liste de diffusion de la Security Team, à laquelle il est possible de s'abonner en allant sur sa page de profil sur https://drupal.org (pas sur https://drupal.fr), et en se rendant sur l'onglet My newsletters pour s'abonner à cette liste de diffusion. Les journalistes intéressés par plus d'informations sur les développements de ce sujet sont invités à contacter directement [email protected] pour obtenir une version centrée sur leurs préoccupations. La Security Team publiera un courriel résumé à destination de la presse en même temps que la publication du code et du bulletin de version associé. Cet article, créé par OSInet est mis à disposition selon les termes de la Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 3.0 France. pour faciliter la diffusion de l'information de sécurité de Drupal. [Less]

Le 21/03/2018, la Security Team de Drupal a annoncé dans son "Public Service Announcement" PSA-2018-001 la sortie imminente de versions de sécurité pour Drupal, le mercredi 28/03/2018. De telles préannonces sont particulièrement rares, la ... [More] précédente remontant à la faille d'injection SQL "Drupalgeddon" de novembre 2014, et sont réservées aux mises à jour les plus critiques. Sévérité / Criticité En temps normal, la couverture de sécurité est limitée aux versions supportées, qui sont actuellement la version courante (8.5.x) et la précédente (7.x). Fait inhabituel là aussi, la mise à jour du 28 couvre également les versions obsolètes 8.3.x et 8.4.x, et un patch a également été annoncé sur le projet D6LTS pour une mise à jour équivalente sur Drupal 6.x, alors que son support est terminé depuis le 24/02/2016, ce qui renforce le niveau de risque estimé de la faille que corrigent ces mises à jour, et l'importance de les appliquer dans les meilleurs délais. Quand agir ? Mais quels sont ces délais, précisément ? Selon le bulletin PSA-2018-001, les "exploits" de la faille révélée par le correctif pourraient être développés dans les "heures ou jours qui suivent" la publication. En 2014, la faille Drupalgeddon avait commencé à être exploitée dans les 6 heures qui avaient suivi la publication du correctif. Avec l'élévation progressive du niveau de risque des agresseurs, tout permet de supposer que le délai pourrait être encore plus court cette fois. La Security Team annonce une publication des correctifs mercredi entre 18:00 et 20:30 UTC, soit 20:00-21:30 heure de Paris, du fait de l'heure d'été. Une marge de sécurité de 6 heures, comme celle dont ont bénéficié les sites en 2014, mène donc au mieux à 03:30 jeudi matin, et au pire 02:00. Dans tous les cas, une mise à jour le jeudi matin 29/03 court donc un risque important d'arriver trop tard. En résumé: préparez votre équipe à une intervention dans la nuit de mercredi à jeudi. Stratégie de mise à niveau Selon le bulletin PSA-2018-001 et les compléments du project D6LTS, la stratégie recommandée est la suivante: Sites sous drupal 8.5.x ou 7.x: appliquer la version de sécurité publiée dans ce correctif selon la procédure standard. Sites sous Drupal 8.4.x: appliquer immédiatement la version 8.4.x qui sera publiée dans ce correctif, puis planifier une mise à jour vers la plus récente version 8.5.x de sécurité, annoncée pour le mois d'avril. Sites sous Drupal 8.3.x: appliquer immédiatement la version 8.3.x qui sera publiée dans ce correctif, puis planifier une mise à jour vers la plus récente version 8.5.x de sécurité, annoncée pour le mois d'avril. Sites sous Drupal/Pressflow 6.x avec un contrat de support auprès de l'un des prestataires du programme commercial D6LTS: suivre les recommandations spécifiques de ce programme. Sites sous Drupal/Pressflow 6.x sans contrat D6LTS: télécharger le patch disponible sur https://www.drupal.org/project/issues/d6lts et l'appliquer au site avec les commandes de patch standard. Les versions exactes à utiliser pour les mises à jour seront indiquées lors de la publication du correctif. Ces mises à jour de sécurité ne modifieront pas le schéma de base de données par rapport à la dernière version actuellement disponible sur chacune des branches concernées. Attention sur les sites utilisant 8.3.x/8.4.x, le rapport du module update sur le tableau de bord d'administration disponible sur /admin/reports/status indiquera une mise à jour recommandée vers une release 8.5.x plutôt que vers la version de sécurité 8.3.x/8.4.x, mais compte tenu des évolutions entre les versions 8.3/8.4/8.5, ceci présente un risque d'effets de bord non souhaités, et il est donc préférable d'appliquer les mises à jour indiquées par le bulletin de sécurité plutôt que celles indiquées par le site, afin de pouvoir plus sereinement préparer la mise à jour en 8.5.x pour avril 2018. Tactique de déploiement Si votre équipe ou prestataire a d'ores et déjà choisi une tactique, mieux vaut l'appliquer qu'improviser au dernier moment: ce sont ceux qui sont les mieux placés pour connaître les contraintes d'exploitation de votre site. A défaut, quatre principales tactiques sont envisageables pour ce déploiement. Les détails dépendent évidemment de vos processus de déploiement et, le cas échéant, de ceux de l'agence ou infogérant en charge de votre site. Cela étant dit, les grandes lignes tactiques sont les suivantes, et commencent AVANT la publication du bulletin: Avant l'après-midi de mercredi 28, mettre à jour le site à la dernière version courante sur la branche concernée: 8.3.x, 8.4.x, 8.5.x. Ne pas tenter à ce stade une mise à jour précipitée vers 8.5.x, pour éviter toute situation problématique à la veille d'une mise à jour de sécurité critique En fin d'après-midi du 28, préparer une sauvegarde intégrale du/des serveurs, par exemple un snapshot disque. En effet, si un exploit vient à être réalisé avant la fin du déploiement du correctif, seule une restauration intégrale de l'infrastructure - par opposition à une restauration de Drupal seul - permettra de garantir l'absence de maliciel sur les serveurs. S'assurer que cette sauvegarde est terminée pour 20:00, heure de publication annoncée au plus tôt Dès la publication, télécharger le patch s'il est disponible, ou la version complète recommandées sinon, et en extraire un patch. Appliquer immédiatement le patch en production. Cela permet de fermer la faille après seulement quelques minutes de vulnérabilité, avec un niveau de risque fonctionnel des plus limités puisque les sites auront été mis au dernier niveau de correction de bogues avant mercredi (cf premier point). Si cette étape n'est pas appliquée, par exemple du fait de règle interdisant les mises à jour en production dans un processus industrialisé certifié, passer immédiatement au point suivant, sinon la suite des opérations peut attendre jeudi matin pour travailler dans de bonnes conditions. Intégrer la nouvelle version complète au projet, et lui faire passer la suite de tests sur l'environnement de recette/préproduction. Une fois la version validée, la déployer. Fin de l'incident. Si le patch a été déployé dès le début, le niveau de risque est très faible, et le déploiement peut être réalisé sur les serveurs en l'état. Si l'étape du patch a été omise et que la nouvelle mise en production a été réalisée moins de 4h après la publication de la version de sécurité, le risque demeure faible. Mais si, en l'absence de patch, la mise en production a attendu jusqu'au jeudi matin, il est préférable de réaliser un nouveau cliché des serveurs, puis de restaurer la version de la veille et de lui appliquer la nouvelle version avant de revenir en ligne. Le cliché du matin pourra alors être examiné pour rechercher des traces d'éventuelles tentatives d'intrusion durant la période de vulnérabilité. Si les contraintes organisationnelles ne permettent pas de réaliser les étapes précédentes, la méthode la plus prudente consiste à mettre le site hors ligne mercredi juste avant 20:00, avec une page statique signalant le caractère volontaire/prudentiel de cette interruption de service, et ne le remettre en ligne qu'une fois la nouvelle version déployée le lendemain S'il n'est possible ni de suivre les procédures de mise à jour rapides précédentes, ni de mettre le site hors ligne jusqu'à la correction, le plus raisonnable sera de considérer que le site est susceptible d'avoir été exploité, donc réaliser une sauvegarde intégrale des serveurs et des serveurs de logs (journaux) disponible, avant de redéployer sur des machines vierges ou sur la sauvegarde de la veille la version corrigée, puis de procéder à un audit visant à identifier si une pénétration a effectivement eu lieu. A ce stade, la présentation Mon site est hacké, que faire ? pourra vous être utile Pour plus d'informations La Security Team pas plus qu'aucune tierce partie ne peut communiquer plus d'informations jusqu'à la publication des correctifs. L'annonce du correctif sera publiées sur https://www.drupal.org/security, sur Twitter, et par courriel pour les abonnés à la liste de diffusion de la Security Team, à laquelle il est possible de s'abonner en allant sur sa page de profil sur https://drupal.org (pas sur https://drupal.fr), et en se rendant sur l'onglet My newsletters pour s'abonner à cette liste de diffusion. Les journalistes intéressés par plus d'informations sur les développements de ce sujet sont invités à contacter directement [email protected] pour obtenir une version centrée sur leurs préoccupations. La Security Team publiera un courriel résumé à destination de la presse en même temps que la publication du code et du bulletin de version associé. Cet article, créé par OSInet est mis à disposition selon les termes de la Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 3.0 France. pour faciliter la diffusion de l'information de sécurité de Drupal. [Less]

Le 21/03/2018, la Security Team de Drupal a annoncé dans son "Public Service Announcement" PSA-2018-001 la sortie imminente de versions de sécurité pour Drupal, le mercredi 28/03/2018. De telles préannonces sont particulièrement rares, la ... [More] précédente remontant à la faille d'injection SQL "Drupalgeddon" de novembre 2014, et sont réservées aux mises à jour les plus critiques. Sévérité / Criticité En temps normal, la couverture de sécurité est limitée aux versions supportées, qui sont actuellement la version courante (8.5.x) et la précédente (7.x). Fait inhabituel là aussi, la mise à jour du 28 couvre également les versions obsolètes 8.3.x et 8.4.x, et un patch a également été annoncé sur le projet D6LTS pour une mise à jour équivalente sur Drupal 6.x, alors que son support est terminé depuis le 24/02/2016, ce qui renforce le niveau de risque estimé de la faille que corrigent ces mises à jour, et l'importance de les appliquer dans les meilleurs délais. Quand agir ? Mais quels sont ces délais, précisément ? Selon le bulletin PSA-2018-001, les "exploits" de la faille révélée par le correctif pourraient être développés dans les "heures ou jours qui suivent" la publication. En 2014, la faille Drupalgeddon avait commencé à être exploitée dans les 6 heures qui avaient suivi la publication du correctif. Avec l'élévation progressive du niveau de risque des agresseurs, tout permet de supposer que le délai pourrait être encore plus court cette fois. La Security Team annonce une publication des correctifs mercredi entre 18:00 et 20:30 UTC, soit 20:00-21:30 heure de Paris, du fait de l'heure d'été. Une marge de sécurité de 6 heures, comme celle dont ont bénéficié les sites en 2014, mène donc au mieux à 03:30 jeudi matin, et au pire 02:00. Dans tous les cas, une mise à jour le jeudi matin 29/03 court donc un risque important d'arriver trop tard. En résumé: préparez votre équipe à une intervention dans la nuit de mercredi à jeudi. Stratégie de mise à niveau Selon le bulletin PSA-2018-001 et les compléments du project D6LTS, la stratégie recommandée est la suivante: Sites sous drupal 8.5.x ou 7.x: appliquer la version de sécurité publiée dans ce correctif selon la procédure standard. Sites sous Drupal 8.4.x: appliquer immédiatement la version 8.4.x qui sera publiée dans ce correctif, puis planifier une mise à jour vers la plus récente version 8.5.x de sécurité, annoncée pour le mois d'avril. Sites sous Drupal 8.3.x: appliquer immédiatement la version 8.3.x qui sera publiée dans ce correctif, puis planifier une mise à jour vers la plus récente version 8.5.x de sécurité, annoncée pour le mois d'avril. Sites sous Drupal/Pressflow 6.x avec un contrat de support auprès de l'un des prestataires du programme commercial D6LTS: suivre les recommandations spécifiques de ce programme. Sites sous Drupal/Pressflow 6.x sans contrat D6LTS: télécharger le patch disponible sur https://www.drupal.org/project/issues/d6lts et l'appliquer au site avec les commandes de patch standard. Les versions exactes à utiliser pour les mises à jour seront indiquées lors de la publication du correctif. Ces mises à jour de sécurité ne modifieront pas le schéma de base de données par rapport à la dernière version actuellement disponible sur chacune des branches concernées. Attention sur les sites utilisant 8.3.x/8.4.x, le rapport du module update sur le tableau de bord d'administration disponible sur /admin/reports/status indiquera une mise à jour recommandée vers une release 8.5.x plutôt que vers la version de sécurité 8.3.x/8.4.x, mais compte tenu des évolutions entre les versions 8.3/8.4/8.5, ceci présente un risque d'effets de bord non souhaités, et il est donc préférable d'appliquer les mises à jour indiquées par le bulletin de sécurité plutôt que celles indiquées par le site, afin de pouvoir plus sereinement préparer la mise à jour en 8.5.x pour avril 2018. Tactique de déploiement Si votre équipe ou prestataire a d'ores et déjà choisi une tactique, mieux vaut l'appliquer qu'improviser au dernier moment: ce sont ceux qui sont les mieux placés pour connaître les contraintes d'exploitation de votre site. A défaut, quatre principales tactiques sont envisageables pour ce déploiement. Les détails dépendent évidemment de vos processus de déploiement et, le cas échéant, de ceux de l'agence ou infogérant en charge de votre site. Cela étant dit, les grandes lignes tactiques sont les suivantes, et commencent AVANT la publication du bulletin: Avant l'après-midi de mercredi 28, mettre à jour le site à la dernière version courante sur la branche concernée: 8.3.x, 8.4.x, 8.5.x. Ne pas tenter à ce stade une mise à jour précipitée vers 8.5.x, pour éviter toute situation problématique à la veille d'une mise à jour de sécurité critique En fin d'après-midi du 28, préparer une sauvegarde intégrale du/des serveurs, par exemple un snapshot disque. En effet, si un exploit vient à être réalisé avant la fin du déploiement du correctif, seule une restauration intégrale de l'infrastructure - par opposition à une restauration de Drupal seul - permettra de garantir l'absence de maliciel sur les serveurs. S'assurer que cette sauvegarde est terminée pour 20:00, heure de publication annoncée au plus tôt Dès la publication, télécharger le patch s'il est disponible, ou la version complète recommandées sinon, et en extraire un patch. Appliquer immédiatement le patch en production. Cela permet de fermer la faille après seulement quelques minutes de vulnérabilité, avec un niveau de risque fonctionnel des plus limités puisque les sites auront été mis au dernier niveau de correction de bogues avant mercredi (cf premier point). Si cette étape n'est pas appliquée, par exemple du fait de règle interdisant les mises à jour en production dans un processus industrialisé certifié, passer immédiatement au point suivant, sinon la suite des opérations peut attendre jeudi matin pour travailler dans de bonnes conditions. Intégrer la nouvelle version complète au projet, et lui faire passer la suite de tests sur l'environnement de recette/préproduction. Une fois la version validée, la déployer. Fin de l'incident. Si le patch a été déployé dès le début, le niveau de risque est très faible, et le déploiement peut être réalisé sur les serveurs en l'état. Si l'étape du patch a été omise et que la nouvelle mise en production a été réalisée moins de 4h après la publication de la version de sécurité, le risque demeure faible. Mais si, en l'absence de patch, la mise en production a attendu jusqu'au jeudi matin, il est préférable de réaliser un nouveau cliché des serveurs, puis de restaurer la version de la veille et de lui appliquer la nouvelle version avant de revenir en ligne. Le cliché du matin pourra alors être examiné pour rechercher des traces d'éventuelles tentatives d'intrusion durant la période de vulnérabilité. Si les contraintes organisationnelles ne permettent pas de réaliser les étapes précédentes, la méthode la plus prudente consiste à mettre le site hors ligne mercredi juste avant 20:00, avec une page statique signalant le caractère volontaire/prudentiel de cette interruption de service, et ne le remettre en ligne qu'une fois la nouvelle version déployée le lendemain S'il n'est possible ni de suivre les procédures de mise à jour rapides précédentes, ni de mettre le site hors ligne jusqu'à la correction, le plus raisonnable sera de considérer que le site est susceptible d'avoir été exploité, donc réaliser une sauvegarde intégrale des serveurs et des serveurs de logs (journaux) disponible, avant de redéployer sur des machines vierges ou sur la sauvegarde de la veille la version corrigée, puis de procéder à un audit visant à identifier si une pénétration a effectivement eu lieu. A ce stade, la présentation Mon site est hacké, que faire ? pourra vous être utile Pour plus d'informations La Security Team pas plus qu'aucune tierce partie ne peut communiquer plus d'informations jusqu'à la publication des correctifs. L'annonce du correctif sera publiées sur https://www.drupal.org/security, sur Twitter, et par courriel pour les abonnés à la liste de diffusion de la Security Team, à laquelle il est possible de s'abonner en allant sur sa page de profil sur https://drupal.org (pas sur https://drupal.fr), et en se rendant sur l'onglet My newsletters pour s'abonner à cette liste de diffusion. Les journalistes intéressés par plus d'informations sur les développements de ce sujet sont invités à contacter directement [email protected] pour obtenir une version centrée sur leurs préoccupations. La Security Team publiera un courriel résumé à destination de la presse en même temps que la publication du code et du bulletin de version associé. Cet article, créé par OSInet est mis à disposition selon les termes de la Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 3.0 France. pour faciliter la diffusion de l'information de sécurité de Drupal. [Less]

A l'occasion de DrupalCamp Lannion, découvrez comment réagir à un site hacké, avec une procédure pas a pas et des pistes pour la suite... et éviter que cela ne se reproduise.