最終更新日: 2019 年 6 月 18 日 午前 11 時 45 分 (米国太平洋標準時)
CVE 識別番号: CVE-2019-11477、CVE-2019-11478、CVE-2019-11479
こちらの内容は、この問題に関する更新です。
Amazon Elastic Container Service (ECS)
Amazon ECS は、2019 年 6 月 17 日と 18 日に、パッチが適用された Amazon Linux および Amazon Linux 2 カーネルとともに、更新済みの ECS 最適化 Amazon マシンイメージ (AMI) を公開しました。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 ベースのプラットフォームバージョンがご利用いただけます。Managed Platform Updates をお使いのお客様は、選択したメンテナンスウィンドウで最新のプラットフォームバージョンに自動的に更新されるため、それ以上操作する必要はございません。あるいは、管理されたプラットフォームの更新をお使いのお客様は、管理された更新の設定ページに移動して [今すぐ適用] ボタンをクリックすることにより、選択したメンテナンスウィンドウよりも前に利用可能な更新を個別に適用できます
管理されたプラットフォームの更新を有効にしていないお客様は、上記の手順に従って環境のプラットフォームバージョンを更新する必要があります。管理されたプラットフォームの更新の詳細については、https://docs.thinkwithwp.com/elasticbeanstalk/latest/dg/environment-platform-update-managed.html をご覧ください。
Amazon Linux と Amazon Linux 2
Amazon Linux の更新済みの Linux カーネルは Amazon Linux リポジトリで入手でき、更新済みの Amazon Linux AMI をご利用いただけます。Amazon Linux を実行している既存の EC2 インスタンスをお使いのお客様は、Amazon Linux を実行している各 EC2 インスタンス内で次のコマンドを実行して、更新済みのパッケージを受け取るようにしてください。
sudo yum 更新カーネル
通常の Linux カーネルの更新と同様に、yum 更新の完了後、更新内容を有効にするための再起動が必要です。
Amazon Linux を使用していないお客様は、これらの問題の潜在的な DoS の懸念を緩和するために必要な更新または指示について、オペレーティングシステムのベンダーにお問い合わせください。詳細については、Amazon Linux セキュリティセンターをご覧ください。
Amazon Elastic Compute Cloud (EC2)
インターネットなどの信頼できない関係者との間で TCP 接続を開始または直接受信するお客様の EC2 Linux ベースのインスタンスでは、これらの問題の潜在的な DoS の懸念を軽減するにはオペレーティングシステムのパッチが必要です。注意: Amazon Elastic 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 の懸念を緩和するために必要な更新または指示について、オペレーティングシステムのベンダーにお問い合わせください。
Elastic Load Balancing (ELB) Classic Load Balancer、Application Load Balancer、または TLS Termination (TLS NLB) を備えた Network Load Balancer を使用する Linux ベースの EC2 インスタンスでは、お客様の操作は必要ありません。ELB Classic と ALB は、着信トラフィックをフィルタリングして、これらの問題の潜在的な DoS の懸念を軽減します。
Amazon WorkSpaces (Linux)
すべての新しい Amazon Linux WorkSpaces は、更新済みのカーネルで起動されます。Amazon Linux 2 の更新済みのカーネルは、既存の Amazon Linux WorkSpaces にすでにインストールされています。
通常の Linux カーネルの更新と同様に、更新内容を有効にするための再起動が必要です。できるだけ早く手動で再起動することをお勧めします。手動で再起動しない場合、Amazon Linux WorkSpaces は 6 月 18 日の現地時間の午前 12:00 から午前 4:00 の間に自動的に再起動します。
Amazon Elastic Container Service for Kubernetes (Amazon EKS)
現在実行中のすべての Amazon EKS クラスターは、これらの問題から保護されています。Amazon EKS は、2019 年 6 月 17 日に、パッチが適用された Amazon Linux 2 カーネルとともに、更新済みの EKS 最適化 Amazon マシンイメージ (AMI) を公開しました。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 設定に変更を加えたお客様は、信頼できないクライアントからのネットワークトラフィックをブロックして潜在的な DoS の懸念を軽減するように設定することにより、ElastiCache セキュリティグループが AWS 推奨のセキュリティベストプラクティスに従うようにする必要があります。 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 設定に変更を加えたお客様は、EMR セキュリティグループが AWS 推奨のセキュリティベストプラクティスに従うようにする必要があります。これにより、信頼できないクライアントからのネットワークトラフィックをブロックして潜在的な DoS の懸念を軽減することができます。EMR セキュリティグループの詳細については、https://docs.thinkwithwp.com/emr/latest/ManagementGuide/emr-security-groups.html をご覧ください。
AWS が推奨するセキュリティのベストプラクティスに従って EMR セキュリティグループを設定しないことを選択したお客様 (または追加のセキュリティポリシーを満たすためにオペレーティングシステムのパッチが必要なお客様) は、以下の手順に従って、新規または既存の EMR クラスターを更新してこれらの問題を軽減できます。注: これらの更新では、クラスターインスタンスの再起動が必要になり、実行中のアプリケーションに影響を及ぼすことがあります。お客様は、クラスターを再起動する必要があると判断するまでクラスターを再起動しないでください。
新しいクラスターの場合、EMR ブートストラップアクションを使用して Linux カーネルを更新し、各インスタンスを再起動します。EMR ブートストラップアクションの詳細については、https://docs.thinkwithwp.com/emr/latest/ManagementGuide/emr-plan-bootstrap.html をご覧ください。
既存のクラスターの場合、クラスター内の各インスタンスで Linux カーネルを更新し、ローリング方式で再起動します。