최종 업데이트: 2019년 6월 18일 오전 11:45 PDT
CVE 식별자: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479
이 문제를 해결하기 위한 업데이트입니다.
Amazon Elastic Container Service(ECS)
Amazon ECS는 패치된 Amazon Linux 및 Amazon Linux 2 커널을 사용하여 업데이트된 ECS 최적화 Amazon Machine Images(AMI)를 2019년 6월 17일과 18일에 각각 발표했습니다. 최신 버전을 받는 방법을 비롯하여 ECS 최적화 AMI에 대한 자세한 내용은 https://docs.thinkwithwp.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html을 참조하십시오.
ECS 고객은 EC2 컨테이너 인스턴스를 업데이트하여 최신 ECS 최적화 AMI 버전을 사용하는 것이 좋습니다.
Amazon GameLift
Linux 기반 Amazon GameLift 인스턴스용의 업데이트된 AMI가 모든 Amazon GameLift 리전에서 제공됩니다. Linux 기반 Amazon GameLift 인스턴스를 사용하는 고객은 새 플릿을 생성하여 업데이트된 AMI를 선택하는 것이 좋습니다. 플릿을 생성하는 방법에 대한 자세한 내용은 https://docs.thinkwithwp.com/gamelift/latest/developerguide/fleets-creating.html을 참조하십시오.
AWS Elastic Beanstalk
업데이트된 AWS Elastic Beanstalk Linux 기반 플랫폼 버전을 이용할 수 있습니다. 관리형 플랫폼 업데이트를 이용하는 고객의 경우 고객 측에서 별도의 조치를 취하지 않아도 선택한 유지관리 창에서 자동으로 최신 플랫폼 버전으로 업데이트됩니다. 또는 관리형 플랫폼 업데이트를 사용하는 고객의 경우 관리형 업데이트 구성 페이지에서 "Apply Now" 버튼을 클릭하여, 고객이 선택한 유지 관리 기간 전에 먼저 제공된 업데이트를 독립적으로 적용할 수 있습니다.
관리형 플랫폼 업데이트를 사용하기로 설정하지 않은 고객의 경우, 환경의 플랫폼 버전을 업데이트하려면 위의 지침을 따라야 합니다. 관리형 플랫폼 업데이트에 대한 자세한 내용은 https://docs.thinkwithwp.com/elasticbeanstalk/latest/dg/environment-platform-update-managed.html을 참조하십시오.
Amazon Linux 및 Amazon Linux 2
Amazon Linux용 업데이트된 Amazon Linux 커널은 Amazon Linux 리포지토리에서 제공되며 업데이트된 Amazon Linux AMI도 사용할 수 있습니다. Amazon Linux를 실행하는 기존 EC2 인스턴스를 사용 중인 고객은 Amazon Linux를 실행하는 각 EC2 인스턴스 내에서 다음 명령을 실행하여 업데이트된 패키지를 적용해야 합니다.
sudo yum update kernel
다른 Linux 커널 업데이트와 마찬가지로, yum 업데이트가 완료된 후 시스템을 재부팅해야 업데이트가 적용됩니다.
Amazon Linux를 사용하지 않는 고객은 운영 체제 공급업체에 문의하여 이러한 문제와 관련하여 발생할 수 있는 DoS 위협을 완화하는 데 필요한 업데이트 또는 지침을 확인해야 합니다. 자세한 내용은 Amazon Linux 보안 센터에서 확인할 수 있습니다.
Amazon Elastic Compute Cloud(EC2)
인터넷과 같이 신뢰받지 않는 당사자와의 TCP 연결을 시작하거나 직접 수신하는 고객 EC2 Linux 기반 인스턴스는 이러한 문제와 관련하여 발생할 수 있는 DoS 위협을 완화하기 위해 운영 체제를 패치해야 합니다. 참고: Amazon Elbastic Load Balancing(ELB)을 사용하는 고객은 아래의 "Elastic Load Balancing(ELB)"에서 추가 지침을 참조해야 합니다.
Elastic Load Balancing(ELB)
TCP Network Load Balancer(NLB)는 TLS 세션을 종료하도록 구성되지 않는 한 트래픽을 필터링하지 않습니다. TLS 세션을 종료하도록 구성된 NLB의 경우 고객이 이 문제를 완화하기 위해 추가적인 조치를 취할 필요가 없습니다.
TLS 세션을 종료하지 않는 TCP NLB를 사용하는 Linux 기반 EC2 인스턴스의 경우 이러한 문제와 관련하여 발생할 수 있는 DoS 위협을 완화하기 위해 운영 체제를 패치해야 합니다. 이제 업데이트된 Amazon Linux용 커널을 사용할 수 있으며, 현재 Amazon Linux를 실행 중인 EC2 인스턴스를 업데이트하기 위한 지침이 위에 나와 있습니다. Amazon Linux를 사용하지 않는 고객은 운영 체제 공급업체에 문의하여 잠재적인 DoS 위협을 완화하는 데 필요한 업데이트 또는 지침을 확인해야 합니다.
TLS 종료(TLS NLB)를 지원하는 Elastic Load Balancing(ELB), Classic Load Balancer, Application Load Balancer 또는 Network Load Balancer를 사용하는 Linux 기반 EC2 인스턴스의 경우 고객이 별도의 조치를 취할 필요가 없습니다. ELB Classic 및 ALB는 이러한 문제로 인한 잠재적인 DoS 위협을 완화하기 위해 수신 트래픽을 필터링합니다.
Amazon WorkSpaces(Linux)
모든 새로운 Amazon Linux Workspace는 업데이트된 커널을 사용하여 시작됩니다. Amazon Linux 2의 업데이트된 커널은 기존 Amazon Linux Workspace용으로 이미 설치되었습니다.
다른 Linux 커널 업데이트와 마찬가지로, 시스템을 재부팅해야 업데이트가 적용됩니다. 고객이 가능한 한 빨리 수동으로 재부팅하는 것이 좋습니다. 그렇지 않으면 Amazon Linux Workspace가 6월 18일 오전 12:00부터 오전 4:00 사이에 자동으로 재부팅됩니다.
Amazon Elastic Container Service for Kubernetes(EKS)
현재 실행 중인 모든 Amazon EKS 클러스터는 이러한 문제로부터 보호됩니다. Amazon EKS는 패치된 Amazon Linux 2 커널을 사용하여 업데이트된 EKS 최적화 Amazon Machine Images(AMI)를 2019년 6월 17일에 발표했습니다. EKS 최적화 AMI에 대한 자세한 내용은 https://docs.thinkwithwp.com/eks/latest/userguide/eks-optimized-ami.html을 참조하십시오.
EKS 고객은 모든 작업자 노드를 교체하여 최신 EKS 최적화 AMI 버전을 사용하는 것이 좋습니다. 작업자 노드를 업데이트하는 방법에 대한 지침은 https://docs.thinkwithwp.com/eks/latest/userguide/update-workers.html을 참조하십시오.
Amazon ElastiCache
Amazon ElastiCache는 Amazon Linux를 실행하는 Amazon EC2 인스턴스의 클러스터를 고객 VPC에서 시작합니다. 이 클러스터는 신뢰할 수 없는 TCP 연결을 기본적으로 허용하지 않으며 이러한 문제의 영향을 받지 않습니다.
기본 ElastiCache VPC 구성을 변경한 고객은 AWS에서 권장하는 보안 모범 사례에 따라 신뢰할 수 없는 클라이언트에서 수신되는 네트워크 트래픽을 차단하여 잠재적인 DoS 위협을 완화하도록 ElastiCache 보안 그룹을 구성해야 합니다. ElastiCache VPC 구성에 대한 자세한 내용은 https://docs.thinkwithwp.com/AmazonElastiCache/latest/red-ug/VPCs.html을 참조하십시오.
ElastiCache 클러스터가 VPC 외부에서 실행되고 기본 구성을 변경한 고객은 ElastiCache 보안 그룹을 사용하여 신뢰할 수 있는 액세스를 구성해야 합니다. ElastiCache 보안 그룹 생성에 대한 자세한 내용은 https://docs.thinkwithwp.com/AmazonElastiCache/latest/red-ug/SecurityGroups.html을 참조하십시오.
ElastiCache 팀에서는 이러한 문제를 해결하는 새로운 패치를 곧 발표할 예정입니다. 이 패치가 발표되면 고객에게 해당 패치를 적용할 준비가 되었음을 알려드립니다. 그런 다음 고객은 ElastiCache 셀프 서비스 업데이트 기능을 통해 클러스터를 업데이트하도록 선택할 수 있습니다. ElastiCache 셀프 서비스 패치 업데이트에 대한 자세한 내용은 https://docs.thinkwithwp.com/AmazonElastiCache/latest/red-ug/applying-updates.html을 참조하십시오.
Amazon EMR
Amazon EMR은 고객을 대신해 Amazon Linux를 실행하는 Amazon EC2 인스턴스의 클러스터를 고객의 VPC에서 시작합니다. 이 클러스터는 신뢰할 수 없는 TCP 연결을 기본적으로 허용하지 않으며 따라서 이러한 문제의 영향을 받지 않습니다.
기본 EMR VPC 구성을 변경한 고객은 AWS에서 권장하는 보안 모범 사례에 따라 신뢰할 수 없는 클라이언트에서 수신되는 네트워크 트래픽을 차단하여 잠재적인 DoS 위협을 완화하도록 EMR 보안 그룹을 구성해야 합니다. EMR 보안 그룹에 대한 자세한 내용은 https://docs.thinkwithwp.com/emr/latest/ManagementGuide/emr-security-groups.html을 참조하십시오.
AWS에서 권장하는 보안 모범 사례에 따라 EMR 보안 그룹을 구성하지 않는 고객(또는 추가 보안 정책을 충족하기 위해 운영 체제 패치가 필요한 고객)은 아래 지침에 따라 새 EMR 클러스터 또는 기존 EMR 클러스터를 업데이트하면 이러한 문제를 완화할 수 있습니다. 참고: 이러한 업데이트는 클러스터 인스턴스를 재부팅해야 적용되며 실행 중인 애플리케이션에 영향을 줄 수 있습니다. 고객은 필요하다고 판단될 때까지 클러스터를 다시 시작해서는 안 됩니다.
새 클러스터의 경우 EMR 부트스트랩 작업을 통해 Linux 커널을 업데이트하고 각 인스턴스를 재부팅할 수 있습니다. EMR 부트스트랩 작업에 대한 자세한 내용은 https://docs.thinkwithwp.com/emr/latest/ManagementGuide/emr-plan-bootstrap.html을 참조하십시오.
기존 클러스터의 경우 클러스터 내의 각 인스턴스에서 Linux 커널을 업데이트하고 단계적으로 재부팅합니다.