Dernière mise à jour : 18 juin 2019 11 h 45 HNP
Identifiants CVE : CVE-2019-11477, CVE-2019-11478, CVE-2019-11479
Il s'agit d'une mise à jour pour ce problème.
Amazon Elastic Container Service (ECS)
Amazon ECS a publié des Amazon Machine Images (AMIs) optimisées pour ECS avec les noyaux Amazon Linux et Amazon Linux 2 les 17 et 18 juin 2019. Vous pouvez trouver plus d'informations sur les AMI optimisées pour ECS, y compris comment obtenir la dernière version, sur https://docs.thinkwithwp.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html.
Nous recommandons aux clients ECS de mettre à jour leurs instances de conteneur EC2 afin d'utiliser la dernière version de l'AMI optimisée pour ECS.
Amazon GameLift
Une AMI à jour pour les instances Amazon GameLift basées sur Linux a été rendue disponible dans toutes les régions Amazon GameLift. Nous recommandons aux clients utilisant les instances Amazon GameLift basées sur Linux de créer de nouvelles flottes pour sélectionner l'AMI à jour. Plus d'informations sur la création de flottes sont disponibles sur https://docs.thinkwithwp.com/gamelift/latest/developerguide/fleets-creating.html.
AWS Elastic Beanstalk
Des versions à jour de la plateforme basée sur Linux AWS Elastic Beanstalk sont disponibles. Les clients qui utilisent les mises à jour de plateforme gérées obtiendront automatiquement une mise à jour vers la version la plus récente de la plateforme dans leur fenêtre de maintenance sélectionnée sans qu'aucune autre action ne soit requise de leur part. Alternativement, les clients qui utilisent les mises à jour de plateforme gérées peuvent appliquer indépendamment des mises à jour disponibles avant leur fenêtre de maintenance sélectionnée en accédant à la page de configuration des mises à jour gérées et en cliquant sur le bouton « Apply Now » (Appliquer maintenant).
Les clients qui n'ont pas activé les mises à jour de plateforme gérées doivent mettre à jour la version de plateforme de leur environnement en suivant les instructions ci-dessus. Vous trouverez plus d'informations sur les mises à jour de plateforme gérées sur https://docs.thinkwithwp.com/elasticbeanstalk/latest/dg/environment-platform-update-managed.html
Amazon Linux and Amazon Linux 2
Des noyaux Linux à jour pour Amazon Linux sont disponibles dans les référentiels Amazon Linux, et des AMI Amazon Linux à jour sont disponibles. Les clients disposant d'instances EC2 existantes exécutant Amazon Linux doivent exécuter la commande suivante au sein de chaque instance EC2 exécutant Amazon Linux pour recevoir le package mis à jour :
sudo yum update kernel
Comme c'est le cas pour chaque mise à jour du noyau Linux, une fois la mise à jour yum terminée, un redémarrage est nécessaire pour que les mises à jour entrent en vigueur.
Les clients qui n'utilisent pas Amazon Linux doivent contacter leur fournisseur de système d'exploitation pour les mises à jour ou instructions nécessaires à l'atténuation d'éventuelles questions de déni de service de ces problèmes. Plus d'informations sont disponibles dans le centre de sécurité Amazon Linux.
Amazon Elastic Compute Cloud (EC2)
Les clients d'instances EC2 basées sur Linux, qu'ils initient ou reçoivent directement des connexions TCP de la part des parties non approuvées ou leur envoient, p. ex., Internet, exigent des correctifs du système d'exploitation pour atténuer les éventuelles questions de déni de service de ces problèmes. Remarque : les clients qui utilisent Amazon Elastic Load Balancing (ELB) doivent examiner « Elastic Load Balancing (ELB) » ci-dessous pour plus de renseignements.
Elastic Load Balancing (ELB)
Les Network Load Balancers (NLB) TCP ne filtrent pas le trafic, à moins qu'ils soient configurés pour mettre fin aux sessions TLS. Les NLB qui sont configurés pour mettre fin aux sessions TLS n'exigent aucune action supplémentaire de la part du client pour atténuer ce problème.
Les instances EC2 basées sur Linux qui utilisent des NLB TCP qui ne mettent pas fin aux sessions TLS exigent des correctifs du système d'exploitation pour atténuer d'éventuelles questions de déni de service liées à ces problèmes. Les noyaux à jour pour Amazon Linux sont disponibles maintenant et des instructions concernant la mise à jour des instances EC2 exécutant actuellement Amazon Linux sont fournies ci-dessus. Les clients qui n'utilisent pas Amazon Linux doivent contacter leur fournisseur de système d'exploitation pour les mises à jour ou instructions nécessaires à l'atténuation d'éventuelles questions de déni de service.
Les instances EC2 basées sur Linux qui utilisent des Network Load Balancers, des Network Load Balancers ou des Classic Load Balancers Elastic Load Balancing (ELB) avec résiliation TLS (NLB TLS) n'exigent aucune action de la part du client. Les ALB ou CLB ELB filtrent le trafic entrant pour atténuer les éventuelles questions de déni de service de ces problèmes.
Amazon WorkSpaces (Linux)
Tous les nouveaux Amazon Linux WorkSpaces seront lancés avec les noyaux à jour. Les noyaux à jour pour Amazon Linux 2 ont déjà été installés pour les Amazon Linux WorkSpaces existants.
Comme c'est le cas pour chaque mise à jour du noyau Linux, un redémarrage est nécessaire pour que les mises à jour entrent en vigueur. Nous recommandons aux utilisateurs d'effectuer un redémarrage manuel dès que possible. Autrement, Amazon Linux WorkSpaces redémarrera automatiquement entre 00 h 00 et 4 h, heure locale, le 18 juin.
Amazon Elastic Container Service for Kubernetes (Amazon EKS)
Tous les clusters Amazon EKS en cours d'exécution sont protégés contre ces problèmes. Amazon EKS a publié des Amazon Machine Images (AMIs) optimisées pour EKS avec le correctif de noyau Amazon Linux 2 les 17, 2019 et 18 juin 2019. Vous pouvez obtenir plus d'informations sur l'AMI optimisée pour EKS en consultant https://docs.thinkwithwp.com/eks/latest/userguide/eks-optimized-ami.html.
Nous recommandons aux clients EKS de remplacer tous les nœuds de travail pour utiliser la dernière version optimisée pour EKS de l'AMI. Des instructions sur la mise à jour des nœuds de travail sont disponibles sur https://docs.thinkwithwp.com/eks/latest/userguide/update-workers.html.
Amazon ElastiCache
Amazon ElastiCache lance les clusters des instances Amazon EC2 exécutant Amazon Linux dans les VPC client. Ces derniers n'acceptent pas les connexions TCP non approuvées par défaut et ne sont pas affectés par ces problèmes.
Les clients ayant apporté des modifications à la configuration VPC ElastiCache par défaut doivent s'assurer que leurs groupes de sécurité ElastiCache suivent les bonnes pratiques de sécurité recommandées par AWS, en les configurant de sorte qu'ils bloquent le trafic réseau des clients non approuvé pour atténuer les éventuelles questions de déni de service. Vous pouvez obtenir plus d'informations sur la configuration VPC ElastiCache en consultant https://docs.thinkwithwp.com/AmazonElastiCache/latest/red-ug/VPCs.html.
Les clients dont les clusters ElastiCache s'exécutent en dehors de leurs VPC et qui ont apporté des modifications à la configuration par défaut doivent configurer un accès approuvé à l'aide des groupes de sécurité ElastiCache. Pour en savoir plus sur la création de groupes de sécurité ElastiCache, consultez https://docs.thinkwithwp.com/AmazonElastiCache/latest/red-ug/SecurityGroups.html
L'équipe ElastiCache publiera bientôt un nouveau correctif, qui résoudra ces problèmes. Une fois ce correctif disponible, nous préviendrons les clients qu'il est prêt à être appliqué. Les clients pourront alors choisir de mettre leurs clusters à jour avec la fonction de mise à jour en libre-service ElastiCache. Vous pouvez obtenir plus d'informations sur les mises à jour des correctifs en libre-service ElastiCache en consultant https://docs.thinkwithwp.com/AmazonElastiCache/latest/red-ug/VPCs.html.
Amazon EMR
Amazon EMR lance les clusters des instances Amazon EC2 exécutant Amazon Linux dans les VPC client en leur nom. Ces clusters n'acceptent pas les connexions TCP non approuvées par défaut et ne sont donc pas impactés par ces problèmes.
Les clients ayant apporté des modifications à la configuration VPC EMR par défaut doivent s'assurer que leurs groupes de sécurité EMR suivent les bonnes pratiques de sécurité recommandées par AWS, de sorte qu'ils bloquent le trafic réseau des clients non approuvé pour atténuer les éventuelles questions de déni de service. Pour plus d'informations sur les groupes de sécurité EMR, consultez https://docs.thinkwithwp.com/emr/latest/ManagementGuide/emr-security-groups.html.
Les clients qui choisissent de ne pas configurer les groupes de sécurité EMR, conformément aux bonnes pratiques de sécurité recommandées par AWS (ou qui exigent des correctifs de système d'exploitation pour se conformer à toutes les politiques de sécurité supplémentaires), peuvent suivre les instructions ci-dessous pour mettre à jour les nouveaux clusters EMR ou les clusters EMR existants pour atténuer ces problèmes. REMARQUE : ces mises à jour nécessitent le redémarrage des instances de cluster et peuvent avoir un impact sur les applications en cours d'exécution. Les clients ne doivent pas redémarrer leurs clusters tant qu'ils ne l'estiment pas nécessaire :
Pour les nouveaux clusters, utilisez une action d'amorçage EMR pour mettre à jour le noyau Linux et redémarrer chaque instance. Vous pouvez obtenir plus d'informations sur les actions d'amorçage EMR en consultant https://docs.thinkwithwp.com/emr/latest/ManagementGuide/emr-plan-bootstrap.html.
Pour les clusters existants, mettez à jour le noyau Linux sur chaque instance au sein d'un cluster et redémarrez-les en mode continu.