• JP
  • magnifying glass search icon to open search field
  • お問い合わせ
  • リソースセンター
  • サポートを受ける
  • 現在、攻撃を受けていますか?
Palo Alto Networks logo
  • 製品
  • ソリューション
  • サービス
  • 業種
  • パートナー
  • パロアルトネットワークスをお勧めする理由
  • 会社案内
  • その他
  • JP
    Language
  • お問い合わせ
  • リソースセンター
  • サポートを受ける
  • 現在、攻撃を受けていますか?
  • スタート ガイド

TCP SACK Panic: Linux カーネルパニック脆弱性の概説

Unit 42 6 24, 2019 at 12:00 午後

本ブログは米国で2019年06月21日に公開されたUnit 42ブログ「TCP SACK Panics Linux Servers」の日本語翻訳です。

 

 

 

 

エグゼクティブサマリー

Linux システムのカーネル脆弱性、CVE-2019-11477、CVE-2019-11478、CVE-2019-11479 が新たに見つかりました。これらの脆弱性は カーネル 2.6.29 (2009 年 3 月公開) とそれ以降にリリースされた新しい Linux オペレーティングシステムのすべてに影響し、TCP で接続を待ち受けるサービスを実行するシステムにカーネルパニックを引き起しかねません。これら脆弱性が悪用されると、リモートからの攻撃によりサーバーがサービス拒否 (DoS) 状態に陥る可能性があります。ただしリモートからコードを実行される心配はありません。これらの脆弱性の原因は TCP SACK (選択的確認応答) と最大セグメントサイズ (MSS) の実装にあります。リモートの攻撃者は、TCP 接続の MSS を下限である 48 バイトに設定し、改ざんした SACK パケット シーケンスを送信することにより、受信側のソケットバッファをオーバーフローさせることができます。ほとんどの Linux ディストリビューションでは、パッチをリリース済みです (RedHat/Ubuntu/openSUSE)。システムに直ちにパッチを適用することができない場合、攻撃をファイアウォールルールかトラフィック制御ポリシーで遮断することも可能です。この攻撃は非常に単純なため、利用可能な POC (Proof of Concept) 攻撃がすぐに出てくることでしょう。そうなれば数日以内に保護されていないシステムのエクスプロイトをもくろみ、大規模な DDoS 攻撃が仕掛けられることが予想されます。
 

TCP SACK

RedHat はこの攻撃に関する詳細説明を提供していますので、ここでは攻撃についての簡単なレビューを含めるにとどめます。TCP SACK 攻撃は、送信側 TCP SACK (選択的確認応答) のメカニズムと受信側の最大セグメントサイズ (MSS) 設定のバランスを崩すことによって可能となる攻撃です。SACK (選択的確認応答) は、どの TCP パケットが受信側に正常に受け入れられ、どのパケットは再送が必要かを送信側システムに通知するためのメカニズムです。MSS (最大セグメントサイズ) は受信側が設定する設定で、ネットワークでどれだけの大きさのパケットを受信できるかを指定します。ここで受信側の MSS が 48 バイトという最も低い設定に設定されている場合、送信側は要求を満たすためにより多くのセグメントを送信する必要があります。受信側が大規模なネットワーク転送 (たとえばメディアファイルそのほかのサイズの大きいファイルの転送) を要求すると、送信側は送信されたパケットが正常に受信されているかの監視を開始します。ここで受信側の MSS が低く設定されていると、送信側で格納可能な SACK キュー長に制限があるために不均衡が発生し、送信側の SACK キューがオーバーフローする可能性があります。こうして未送信パケットのオーバーフローが大きくなりすぎると、カーネルパニックの状態が引き起こされ、その結果、サービス拒否 (DoS) につながる可能性があります。
 

影響

Linux カーネル 2.6.29 以降および TCP サービスを実行するオープンなポートを持つすべてのサーバーがこの攻撃に対して脆弱です。本脆弱性による潜在的な影響を理解するため、Shodan でいくつかのクエリを実行した結果を図 1 に示します。本稿執筆時点では 194 万 4,975 台の Linux ベースサーバーがインターネット上で見つかります。うち 54 万 3,797 台のサーバーが 80/tcp で HTTP サービスを実行し、15 万 2,416 台のサーバーが 22/tcp で sshd サービスを実行し、12 万 6,143 台のサーバーが 443/tcp で HTTPS サービスを実行しています。これらサーバーに特別なファイアウォール ルールやトラフィック制御ポリシーが適用されていない場合、これらのサーバーはすべて潜在的に攻撃の標的となる可能性があります。

図 1 Shodan で見つけることができる公開済み Linux システム
 

対策・緩和策

この攻撃は Linux カーネルシステムを標的にしています。バージョン 2.6.29 以降のカーネルを実行している Linux システムがある場合は、システムを利用可能な最新 Linux リリースにアップグレードする必要があります。クライアントが Google Cloud Platform (GCP)、Microsoft Azure、そのほかの Infrastructure as a Service (IaaS) を使用している場合は、Linux のアップグレード手順に従ってすべての Linux システムを最新のリリースにアップグレードしてください。

Amazon は今回確認された SACK Panic 攻撃からの被害を受ける可能性のあるサービスとして、次のものを識別済みです。

  • AWS Elastic Beanstalk
  • Amazon Linux および Amazon Linux 2
  • Amazon Elastic Compute Cloud (EC2)
  • Elastic Load Balancing (ELB)
  • Amazon WorkSpaces (Linux)
  • Amazon Elastic Container Service for Kubernetes (Amazon EKS)
  • Amazon ElastiCache
  • Amazon EMR

上記の識別済み Amazon サービスの一部ないし全部を使用しているクライアントは、該当サービスを最新バージョンに更新する必要があります。以下は上記各 Amazon サービスに対して実行すべきアクションの簡略一覧です。

AWS Elastic Beanstalk

  • クライアントが Amazon のマネージドプラットフォーム更新を使用している場合、これらのシステムは選択したメンテナンス期間中に更新されます。クライアントがマネージドプラットフォーム更新を有効にしていない場合は、こちらのマネージドプラットフォーム更新の手順を参照して有効に設定してください。

Amazon Linux および Amazon Linux 2

  • 新しい Linux カーネルがアップロードされ Amazon Linux リポジトリから利用可能になっています。クライアントは各 EC2 インスタンスで次のコマンドを実行し、カーネルアップデートを受信する必要があります。
    sudo yum update kernel

Amazon Elastic Compute Cloud (EC2)

  • 各 EC2 インスタンス内で次のコマンドを実行します。
    sudo yum update kernel

Elastic Load Balancing (ELB)

  • お使いの ELB が Classic Load Balancer ないし Application Load Balancer の場合、または Network Load Balancer (NLB) で TLS ターミネーション (TLS 終端) を利用している場合は、ユーザー側でとくにアクションをとる必要はありません。
    お使いの Network Load Balancer で TLS ターミネーションを利用していない場合は、Linux ベースの EC2 インスタンスのカーネルにパッチを適用する必要があります。その方法については、こちらをご確認ください (2019-06-27 08:00 修正更新)。

Amazon WorkSpaces (Linux)

  • 新しい Linux WorkSpaces はすべて自動的にアップデートされるためクライアントによるアップデートは不要です。

Amazon Elastic Container Service for Kubernetes (Amazon EKS)

  • 現在実行中のすべての EKS クラスタはこの攻撃から保護されています。クライアントはすべてのワーカーノードを置き換え、最新の EKS バージョンを使用する必要があります。

Amazon ElastiCache

  • ElastiCache VPC はデフォルトで信頼されていない TCP 接続を受け入れないため、影響を受けません。
  • クライアントがデフォルトの ElastiCache VPC 設定から変更されている場合は、ElastiCache セキュリティグループが AWS のベストプラクティスに従っていることを確認し、信頼されていないクライアントからのトラフィックをブロックするように設定する必要があります。詳細は Amazon の Amazon VPC と ElastiCache のセキュリティを参照してください。
  • クライアントに VPC 外で実行中の ElastiCache があり、ElastiCache をデフォルト設定から変更している場合は、ElastiCache セキュリティグループを使用してインスタンスを構成する必要があります。詳細は Amazon のセキュリティグループ: EC2-Classicを参照してください。

Amazon EMR

  • Amazon EMR は、Linux を実行している EC2 インスタンスをクライアントの VPC 内で起動します。これらはデフォルトで信頼されていない TCP 接続を受け入れないため、影響を受けません。
  • EMR VPC の設定を変更したクライアントがある場合は AWS のベストプラクティスに従っていることを確認し、信頼されていないクライアントからのトラフィックをブロックするように設定する必要があります。詳細は Amazon のセキュリティグループを使用してネットワークトラフィックを制御するを参照してください。
  • AWS のベストプラクティスに従った EMR セキュリティグループを設定しないことを選択したクライアントについては、次のガイドラインに従うことができます。
    • 新しいクラスタ - EMR ブートストラップアクションを使用して Linux カーネルを更新し、各インスタンスを再起動します。詳細は Amazon の追加のソフトウェアをインストールするためのブートストラップアクションの作成を参照してください。
    • 既存のクラスタ - クラスタ内の各インスタンスで Linux カーネルを更新し、一度に 1 つずつインスタンスを再起動します。
       

結論

本脆弱性は、仕組みが単純で深刻度が高いため、数日以内に大規模な DDoS 攻撃が確認されることになっても不思議ではありません。Linux カーネルをできるだけ早くアップデートすることが重要です。また、パブリッククラウドで実行中のサーバーをインターネットに公開して TCP サービスをオープンにしている場合、直ちにパッチを適用するか、少なくともファイアウォール ルールを設定して攻撃をブロックすることが極めて重要です。管理者は本稿で提供した対策ガイドラインを活用してシステムを保護してください。

 

更新履歴

  • 2019-06-27 08:00 Elastic Load Balancing (ELB) の修正手順についての誤りを修正しました。

 

ニュース

Wireshark によるパケット解析講座 1

Wireshark は無料で利用できるプロトコル アナライザです。 Wireshark を使うとネットワーク トラフィックをキャプチャしたり、キャプチャしたパケットを表示させることができます。そこでパロアルトネットワークスの脅威インテリジェンス調査チーム Unit42 に所属するアナリストが、Wireshark を使ってマルウェア検体が生成したトラフィックをレビューするさいに利用している便利な使いかたをご紹介していきます。
January 17, 2019

ニュース

Wireshark によるパケット解析講座 3

前回までではWiresharkの列表示のカスタマイズ方法と表示フィルタの式について見ていきました。本稿ではトラフィックから感染ないし侵害を受けたホスト名やユーザーを特定する方法について説明します。
March 31, 2019

ニュース

Wireshark によるパケット解析講座 2

前回は Wiresharkの列表示のカスタマイズ方法について見ていきました。本稿では脅威インテリジェンスの調査上便利なフィルタリングの設定方法について説明します。
January 20, 2019

ニュース

DNSトンネリング: 攻撃者はDNSをどう悪用するのか

悪意のある攻撃者は、ドメインネームサービス(DNS)をコマンド&コントロール(C2)用通信チャネルとして悪用してきました。またこのプロトコルはこのほかに、データを漏出させる目的でも悪用されてきました。DNS の悪用はC2に「ハートビート」接続のために通信するという用途からさらに広がっており、攻撃者はここ数年、悪意のあるデータやペイロードをDNS経由で被害者のシステムに侵入させる用途にもDNSを使っています。本稿では、DNSを悪用したデータ侵入・漏出の種類、方法、使用方法を紹介し、その防御メカニズムへの指針を示します。
March 18, 2019

ニュース

Wireshark によるパケット解析講座 4

セキュリティ専門家は、不審なアクティビティのパケット キャプチャ(pcap)をレビューする際、より詳しく調べるために、オブジェクトをpcapからエクスポートしなければならない場合があります。
July 12, 2019

データシート

PA-400シリーズ

パロアルトネットワークスの機械学習を活用したNGFW「PA-400 Series (PA-460、PA-450、PA-440)」なら、分散した大企業の支社、小売店、中規模企業にも次世代ファイアウォール機能を導入できます。
August 3, 2022

最新ニュース、イベント情報、脅威アラートを配信

このフォームを送信すると、お客様は弊社の利用規約とプライバシー ポリシーに同意したものとみなされます。

black youtube icon black twitter icon black facebook icon black linkedin icon
  • USA (ENGLISH)
  • AUSTRALIA (ENGLISH)
  • BRAZIL (PORTUGUÉS)
  • CANADA (ENGLISH)
  • CHINA (简体中文)
  • FRANCE (FRANÇAIS)
  • GERMANY (DEUTSCH)
  • INDIA (ENGLISH)
  • ITALY (ITALIANO)
  • JAPAN (日本語)
  • KOREA (한국어)
  • LATIN AMERICA (ESPAÑOL)
  • MEXICO (ESPAÑOL)
  • SINGAPORE (ENGLISH)
  • SPAIN (ESPAÑOL)
  • TAIWAN (繁體中文)
  • UK (ENGLISH)

人気のあるリソース

  • 会社概要
  • イベント センター
  • イベント
  • リソースセンター
  • プレスリリース
  • Unit42 ブログ
  • 投資家の皆様へ
  • ブログ
  • Japan Live Community
  • Tech Docs
  • キャリア
  • お問い合わせ
  • サイトマップ

法定通知

  • プライバシー
  • 個人情報保護基本方針
  • 利用規約
  • トラスト センター
  • ドキュメント
  • 一般事業主行動計画

アカウント

  • 購読の管理
  • パートナーログイン
  • パートナーになる
脆弱性の報告

Copyright © 2023 Palo Alto Networks. All rights reserved