Вы просматриваете предыдущую версию этого бюллетеня по безопасности. Чтобы ознакомиться с актуальной версией, откройте статью Проблемы с ядром Linux при выборочном подтверждении TCP (TCP SACK) из-за отказа в обслуживании.
17 июня 2019 г., 10:00 по тихоокеанскому времени
Идентификаторы CVE: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479
Команде AWS известно о трех недавно обнаруженных проблемах, которые затронули подсистемы обработки протоколов TCP ядра Linux. В частности, вредоносный TCP-клиент или сервер может передавать специально созданные серии пакетов, которые могут стать причиной тревоги и перезагрузки ядра Linux любой атакуемой системы подключения.
Базовые системы и инфраструктура AWS защищены от таких проблем. За исключением перечисленных ниже сервисов AWS, от пользователя не требуется дополнительных действий для защиты от потенциальных атак типа «отказ в обслуживании» (DoS) из-за упомянутых проблем.
Amazon Elastic Compute Cloud (EC2)
Пользовательским инстансам EC2 на базе Linux, которые инициируют TCP-подключения к ненадежным сторонам (например, к Интернету) или устанавливают их напрямую, нужны исправления операционных систем для защиты от потенциальных DoS-атак из-за упомянутых проблем. ПРИМЕЧАНИЕ. Дополнительные советы для клиентов, использующих Amazon Elastic Load Balancing (ELB), приведены ниже в пункте «Elastic Load Balancing (ELB)».
Образы AMI Amazon Linux и Amazon Linux 2
Вскоре появятся обновленные образы AMI Amazon Linux. Мы обновим этот бюллетень, когда они станут доступны для использования.
Обновленные ядра для AMI Amazon Linux и Amazon Linux 2 уже доступны в репозиториях Amazon Linux. Чтобы получить обновленный пакет, клиенты, которые используют текущие инстансы EC2 под управлением Amazon Linux, должны запустить в каждом соответствующем инстансе EC2 такую команду:
sudo yum update kernel
Согласно стандартной методике, при каждом обновлении ядра Linux после выполнения команды yum update необходимо перезагрузить устройство, чтобы изменения вступили в силу.
Дополнительные сведения скоро будут представлены в Центре безопасности Amazon Linux.
Elastic Load Balancing (ELB)
Балансировщики Network Load Balancer (NLB) не фильтруют трафик. Инстансам EC2 на базе Linux, которые используют балансировщики NLB, нужны исправления операционных систем для защиты от потенциальных DoS-атак из-за упомянутых проблем. Обновленные ядра для Amazon Linux уже доступны, а инструкции по обновлению инстансов EC2, которые на данный момент работают под управлением Amazon Linux, изложены выше. Клиентам, которые не пользуются Amazon Linux, необходимо обратиться к поставщику операционной системы за обновлениями или инструкциями для защиты от потенциальных DoS-атак.
Инстансы EC2 на базе Linux, использующие балансировщики Elastic Load Balancing (ELB), Classic Load Balancer и Application Load Balancer, не требуют дополнительных действий пользователя. Балансировщики ELB, Classic и ALB будут фильтровать входящий трафик для защиты от потенциальных DoS-атак из-за упомянутых проблем.
Amazon WorkSpaces (Linux)
Все новые рабочие пространства Amazon Linux WorkSpaces будут запущены с обновленными ядрами. Обновленные ядра для Amazon Linux 2 уже установлены для существующих рабочих пространств Amazon Linux WorkSpaces.
Согласно стандартной методике, при каждом обновлении ядра Linux необходимо перезагрузить устройство, чтобы изменения вступили в силу. Мы советуем пользователям выполнить перезагрузку вручную как можно скорее. В противном случае рабочие пространства Amazon Linux WorkSpaces перезагрузятся автоматически 18 июня с 00:00 до 4:00 по местному времени.
Amazon Elastic Container Service for Kubernetes (Amazon EKS)
Все кластеры Amazon EKS, работающие на данный момент, защищены от таких проблем. 17 июня 2019 г. сервис Amazon EKS опубликовал обновленные образы Amazon Machine Image (AMI), оптимизированные для EKS, с исправлениями ядра Amazon Linux 2. Дополнительные сведения об образах AMI с оптимизацией для EKS см. в статье https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html.
Мы советуем пользователям EKS заменить все рабочие узлы и использовать последнюю версию AMI с оптимизацией для EKS. Инструкции об обновлении рабочих узлов см. в статье https://docs.aws.amazon.com/eks/latest/userguide/update-workers.html.
AWS Elastic Beanstalk
Обновленные платформы AWS Elastic Beanstalk на базе Linux будут доступны с 17 июня 2019 г. Этот бюллетень будет обновлен, как только появятся новые версии платформы. Для клиентов, использующих управляемые обновления платформы, в следующий запланированный период обслуживания новая версия платформы установится автоматически. Дополнительных действий не требуется. Клиенты, использующие управляемые обновления платформы, могут также независимо установить доступные обновления до наступления запланированного периода обслуживания. Для этого необходимо перейти на страницу настройки управляемых обновлений и нажать кнопку Apply Now (Применить сейчас).
Пользователи, у которых не настроены управляемые обновления, должны обновить версию платформы среды, следуя приведенным выше инструкциям. Дополнительные сведения об управляемых обновлениях платформы см. в статье https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-platform-update-managed.html.
Amazon ElastiCache
Amazon ElastiCache запускает кластеры инстансов Amazon EC2 под управлением Amazon Linux в пользовательских облаках VPC. Они не принимают недоверенные TCP-подключения по умолчанию и на них не влияют упомянутые проблемы.
Все пользователи, которые внесли изменения в настройки ElastiCache VPC по умолчанию, должны убедиться, что их группы безопасности ElastiCache соответствуют рекомендациям AWS по безопасности. Для этого необходимо настроить в них блокировку сетевого трафика из недоверенных клиентов, чтобы обеспечить защиту от потенциальных DoS-атак. Дополнительные сведения о настройке ElastiCache VPC см. в статье https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/VPCs.html.
Пользователям с кластерами ElastiCache, работающими за пределами их облаков VPC, которые внесли изменения в настройки по умолчанию, необходимо настроить доверенный доступ с помощью групп безопасности ElastiCache. Дополнительные сведения о создании групп безопасности ElastiCache см. в статье https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/SecurityGroups.html.
В скором времени команда ElastiCache выпустит новое исправление, которое поможет устранить эти проблемы. Как только такое исправление появится, мы сообщим пользователям, что его уже можно применить. Затем пользователи могут обновить свои кластеры с помощью компонента самостоятельного обновления ElastiCache. Дополнительные сведения о самостоятельном обновлении исправлений ElastiCache см. в статье https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/applying-updates.html.
Amazon EMR
Amazon EMR запускает кластеры инстансов Amazon EC2 под управлением Amazon Linux в пользовательских облаках VPC от их имени. Такие кластеры не принимают недоверенные TCP-подключения по умолчанию и на них не влияют упомянутые проблемы.
Все пользователи, которые внесли изменения в настройки EMR VPC по умолчанию, должны убедиться, что их группы безопасности EMR соответствуют рекомендациям AWS по безопасности. Для этого необходимо настроить в них блокировку сетевого трафика из недоверенных клиентов, чтобы обеспечить защиту от потенциальных DoS-атак. Дополнительные сведения о группах безопасности EMR см. в статье https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-security-groups.html.
Пользователи, которые не хотят настраивать группы безопасности EMR в соответствии с рекомендациями AWS по безопасности (или если им нужны исправления операционной системы в соответствии с требованиями дополнительных политик безопасности), могут выполнить приведенные ниже инструкции, чтобы обновить новые и существующие кластеры EMR и защитить их от упомянутых проблем. ПРИМЕЧАНИЕ. Для установки этих обновлений необходимо перезагрузить инстансы кластеров. Это может повлиять на работающие приложения. Пользователям не стоит перезапускать кластеры, пока в этом нет необходимости.
В случае новых кластеров можно использовать сценарий начальной загрузки EMR для обновления ядра Linux и перезагрузить каждый инстанс. Дополнительные сведения о сценариях начальной загрузки EMR см. в статье https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-bootstrap.html.
В случае существующих кластеров обновите ядро Linux каждого инстанса в пределах кластера и последовательно перезагрузите их.