セキュリティ

ThousandEyes ウクライナのインターネットの分析

木村滋
2022年3月23日

執筆者：インターネット調査チーム | 2022 年 3 月 4 日 | 読了時間の目安：17 分間

概要

Cisco ThousandEyes では、ウクライナ内外の数十のオンラインプロパティを対象に、アクセス関連のインターネットアクティビティを積極的に監視してきました。これらの Web サイトやサービスへのアクセスはウクライナの人々にとって極めて重要です。また、ロシアのさまざまな著名な Web サイトについても同様の監視を行ってきました。ウクライナ全域でサービスへのアクセスが不安定な状況が続いていますが、本稿ではインターネットの観点から最近の実態を明らかにするために、主要な銀行および政府機関のサイトを取り上げ、サービスが利用可能かどうかやこれまでのサイト運用状況について説明します。ウクライナ情勢に進展があり次第、最新情報を随時追加していきます。

調査結果の概要

[2022 年 3 月 2 日午後 2 時（太平洋時間）現在]

ThousandEyes はこの 2 週間で次のことを確認しました。

インターネットトラフィックの中断が重大なレベルに達しており、ウクライナの主要な銀行、国防、その他政府機関の Web サイトで可用性が低下：中断のパターンは、分散型サービス妨害（DDoS）攻撃を受けたときに一般的に確認されるネットワークの挙動に一致しています。またサービスへの影響を緩和するためにサービス運用者が対策を施した可能性があることも中断のパターンから読み取れます。分散型サービス妨害（DDoS）はサイバー攻撃の一種です。世界のさまざまな場所から迷惑なトラフィックをオンラインプロパティ（Web サイトまたはサービス）に大量に送り付けることでインフラやサービスを過負荷状態にし、正規のトラフィックが処理されるのを妨げます。

クラウド サービス プロバイダーが提供している DDoS 対策は概ね効果的：大規模なクラウドベースのセキュリティプロバイダー（Imperva、Cloudflare など）をすでに導入していたか、それらのプロバイダーに先週切り替えた Web サイトやサービスは、稼働時間やアクセスをより効果的に維持できています。DDoS 緩和機能を提供するプロバイダーは通常、独自のインフラを通じてトラフィックをリダイレクトします。それによって大量のトラフィックを管理できるだけでなく、悪意のあるトラフィックを排除して正規のトラフィックを本来の接続先に送信することもできます。ロシアからのトラフィックや場合によっては中国からのトラフィックを選択的にブロックする防御手法がいくつか確認されています。スケーラブルな配信アーキテクチャやより堅牢なセキュリティメカニズムにアップグレードしていない多くの Web サイトやサービスでは、重大な中断が依然として発生しています。

予測されているような大規模な DNS 攻撃や BGP 攻撃が行われた証拠はない：ただし、そのような試みが行われた可能性はあります。DNS ハイジャックや BGP ハイジャックの試みが行われていたとしても、限定的であったか、広範な影響を与えるほどの効果はなかったものと思われます。DNS は、ドメイン名（twitter.com など）をそのサービスがホストされている IP アドレス（104.244.42.65 など）に変換するグローバルネーミングシステムです。ボーダーゲートウェイプロトコル（BGP）は、異なる組織や国に属するインターネットルータの間で使用される通信プロトコルであり、トラフィックが送信元からインターネットを通じて正しい接続先 IP に到達できるようにします。DNS ハイジャックは、不正なアドレス情報を提供して不正な接続先にユーザーを誘導する手法です。BGP ハイジャックは、トラフィックを意図したルートまたは正規の接続先からリダイレクトします。これは偶発的に行われることもあれば、意図的に行われることもあります。DNS と BGP はどちらも、インターネットを支える基盤技術です。

重要なポイント

[2022 年 3 月 2 日午後 2 時（太平洋時間）現在]

この地域の情勢は非常に不安定ですが、大規模なクラウドベースのセキュリティサービスが功を奏しており、銀行や国防関係の主要なサイトは引き続き利用することができます。不安定な情勢によるデジタルインフラへの影響が懸念される場合は、次のことを検討することをお勧めします。

悪条件下で復元力を確保するには、スケーラブルなサービス提供アーキテクチャを構築して、すべての重要な依存関係（DNS、ISP、ホスティングなど）において冗長性を確保し、適切にプロビジョニングされたセキュリティ機能を備えた分散型のインフラによってフロントエンド処理を行うのが最適です。

現在、クラウドセキュリティサービスプロバイダーは大量のトラフィックを処理しています。それらのプロバイダーを利用している場合、直接攻撃を受けていなくても、サービスのパフォーマンスが副次的に低下する可能性があるので、そうした事態に備えて代替案を用意しておく必要があります。

DNS と BGP は攻撃ベクトルにはなっていませんが、潜在的な脆弱性であることに変わりはないため、ウクライナ内外のサイトに与える影響を注意深く監視する必要があります。

ウクライナ情勢の進展に関する Cisco Talos の最新の脅威インテリジェンスについては、こちらをご覧ください。

詳細な分析/POV

[2022 年 3 月 2 日午後 2 時（太平洋時間）現在]

ウクライナ政府の Web サイト

政府機関の Web サイトへの接続は非常に不安定です。さまざまなレベルの損失が発生し、ローカルネットワークにおける輻輳の状態が変化していることがうかがわれます。また、特定のソースからのトラフィックが急速に完全に消失することがあります。これは、サイト所有者がサービスプロバイダーを通じて実装したトラフィックブラックホールフィルタが適用されたことが原因である可能性があります。

ある程度は、DDoS 関連の輻輳や対策（トラフィックのブラックホール化など）によって現在のようなトラフィックパターンが確認されている可能性がありますが、国際的な関心の高まりによる悪意のないトラフィックの増加やセキュリティメカニズム（DDoS トラフィックの排除やネットワーク侵入検知および防御システムなど）によって、トラフィック損失が増加したり一部サイトで全体的な可用性が低下したりしているとも考えられます。

具体的な原因にはさまざまなものがあります。全体的な影響として、インターネット接続やアプリケーションの可用性に大きなばらつきが発生しており、同じサービスでも大きく変動することがあります。政府機関の主要なサイトはアクセシビリティが 0 ～ 100% の間でばらついており、トラフィックソースによってはアクセシビリティが数分で 100% から 0% になったり 0% から 100% になったりすることがあります。

サービスの提供方法に 2 つのアプローチがあることが可用性レベルの相違に直接関係しているものと思われます。世界中に分散した CDN や Web セキュリティサービスなどの拡張性の高いクラウドサービスを利用しているサイトは、ローカルインフラでのみサービスを提供し続けているサイトよりも可用性がはるかに高くなっています。たとえば、政府機関のサイトの多くは 1 つの場所でホストされており、他の政府機関のサイトと同じインフラを共有しています。また、ユーザーへのサービス提供は 1 社または 2 社のローカルインターネットサービスプロバイダーを通じて行っています。こうしたサイトでは、図 1 と図 2 に示すような深刻な中断が発生し続けています。図 1 では、ウクライナ政府に属する複数のサイトが同じホスティング環境に存在し、同じ IP アドレスを共有している様子が示されています。図 2 では、ネットワークのパフォーマンスが継続的に低下している様子が示されています。

図 1：同じ障害点を共有する複数のサービスが同時にダウン

複数のサイトが共通のインフラでクラスタ化されている場合、共同ホスティングサイトの 1 つが攻撃を受けて悪意のあるトラフィックが送り付けられると、その経路となったインフラやネットワークだけでなく他のサイトでもパフォーマンスが低下することがありました。さらに、複数のサイトが攻撃を受けると、別個の標的に対するトラフィックストリームが少数の ISP に集中し、最終的に 1 つのサイトに集中するため、影響が増幅されることがありました。

図 2：同じ障害点を持つ Web サイトで可用性の問題が発生

それとは対照的に、保護と分散型サイト配信を実現するためにクラウドサービスを利用していたか、利用を開始した政府機関のサイトの大半については可用性に支障は出ませんでした。いくつかの主要な国防サイトやインテリジェンスサイトは世界中に分散した CDN プロバイダーに移行したことが確認されています。これは最近の情勢を考慮して行われたものと思われます。

図 3 では、以前のホスティング環境で運用されていたウクライナ政府機関の Web サイトでネットワークのパフォーマンスが持続的に低下する様子が示されています。グローバル CDN サービスに切り替えた後は（図 4）、同じ Web サイトでネットワークパフォーマンスの低下は確認されておらず、ネットワークの観点ではサービスは安定しているように見えます。

図 3：ウクライナ政府機関の Web サイトに接続している ISP でパケット損失を確認

図 4：図 3 の問題を抱えていたサイトがグローバル CDN プロバイダーに切り替えた後はネットワークパフォーマンスが安定

クラウドベースの CDN/セキュリティサービスを利用している他のサイトでも同様に安定したネットワークパフォーマンスが確認されています。

ウクライナの銀行サイト

政府機関のサイトが主にローカルインフラを利用してユーザーにサービスを提供していたのとは対照的に、ウクライナのほぼすべての主要な銀行の Web サイトは現在の状況に対して復元力が高いように見えます。各行がパブリッククラウドプロバイダーのサービスを使用しており、パブリッククラウドと Imperva などの専門のクラウドセキュリティサービスの両方を使用しているケースもあります。その結果、いくつかの例外はありますが、ウクライナの銀行は政府機関のサイトよりもサービスの不安定さが格段に低くなっています。

図 5 は、クラウドサービスを利用していなかった大手銀行で侵攻前に発生したネットワークパフォーマンスの低下を示しています。2022 年 2 月 21 日以前は、1 つの ISP を通じて 1 つのホスティングサイトでトラフィックを処理していたため、DDoS 攻撃などのトラフィック輻輳イベントを緩和するのは困難でした。しかし、侵攻が始まる直前の 2 月 21 日と 22 日に、同行はフロントエンドサービスの配信を Imperva に移行しました。Imperva は、大規模な DDoS 攻撃やアプリケーションレベルの攻撃をかわすために必要な分散型のグローバルプレゼンスとスケーラブルなセキュリティメカニズムを提供するサービスです。このサービスに完全に移行して以来、同行のサイトの可用性は良好です。

Imperva に切り替えるまでの間は、ロシアからのトラフィックをブロックしようとするネットワークの挙動が確認されました。同行はすでに中国からのトラフィックをブロックしていたようでしたが、2 月 21 日になると同行の ISP プロバイダーである Infocom Ukraine 社によってロシアからのトラフィックが継続的かつ完全にドロップされるようになりました。これは攻撃パターンへの対応措置とも考えられますが、純粋な予防措置かもしれません。このような統制された急速に発現する損失は DDoS などの標的型攻撃が原因である可能性は低く、意図的なソースベースのリモートトリガーブラックホール（RTBH）フィルタリングなどを同行が ISP を通じて実装していた可能性があります。

その後、2 月 21 日 19 時 41 分頃（協定世界時）に、同行に対するすべてのトラフィックで完全なネットワーク損失が発生していることが ThousandEyes のテストで確認されました。すべての損失は Infocom ISP ネットワーク内の別のルータで発生していました。これは、接続先ベースのブラックホールポリシーへの切り替えが同じ ISP を通じて行われたことを示している可能性があります。

図 5：独自インフラでホストされているウクライナの銀行へのトラフィックで完全なパケット損失が発生

約 1 時間後の 20 時 55 分（協定世界時）にすべてのトラフィックが正常に戻り、同行の Web サイトがオンラインに復帰しました（デフォルトでブロックされている中国からの接続は除きます）。

このフィルタリングのような挙動の説明としては、ネットワークレベルの DDoS 緩和ポリシーを実装しようとしたことが考えられます。しかし、以前に確認されたような DDoS 攻撃特有のトラフィックパターンはソースフィルタリングの前にも接続先フィルタリングの前にも確認されていません。Imperva への移行開始とタイミングが一致していることから、近々行われるサービスの変更に備えてシステムを保護するために先制措置を講じていた可能性があります。

3 時間後に、Imperva への切り替えが行われた最初の証拠が確認されます。2 月 21 日の 23 時頃（協定世界時）に、中国からのトラフィックが Incapsula 社のネットワークノード（Imperva のサービスの一部）にルーティングされ始めました。他の場所からのトラフィックは接続先に直接送信されていました。

図 6：独自インフラでホストされていたウクライナの銀行で Imperva（クラウドセキュリティ）への部分的移行が確認され、中国からのトラフィックが Imperva にルーティング

最終的に、2 月 22 日の 21 時 51 分頃（協定世界時）に Imperva への完全な切り替えが完了したようで、すべてのトラフィックが Incapsula 社のネットワークにルーティングされました。また、アプリケーショントラフィックは同行ではなく Imperva（Incapsula 社）で処理されていることが確認されています。

図 7：独自インフラでホストされていたウクライナの銀行が Imperva（Incapsula 社）に完全に切り替え

Imperva に切り替えた後、同行はソースベースのアプリケーションレベルのブラックホールポリシーと思われるものを実装しました。ThousandEyes のアプリケーションテストによると、ロシアのトラフィックはネットワークレベルでブラックホール化する代わりに、アプリケーションレベルで HTTP 403-Forbidden エラーでブロックされています。

ウクライナの別の銀行は、この例とは異なり、クラウドプロバイダー（Amazon Web Services）をすでに使用してサービスをホストしていたため、アプリケーションレベルのセキュリティポリシーをすぐに開始できました。また、採用したアプローチも少し異なっています。この銀行は、ロシアからのトラフィックのみをブロックする代わりに、AWS WAF（Web アプリケーションファイアウォール）サービスを活用し、国外からのあらゆるトラフィックに対して CAPTCHA セキュリティチェックを導入しました。ウクライナからのトラフィックは同行のサイトに支障なくアクセスできます。

同行はこのポリシーを 2 月 23 日 13 時（協定世界時）に適用したことが確認されています。ThousandEyes のアプリケーションテストの結果を見ると、同行の Web サイトは 2 月 23 日以前から正常に動作しています。13 時頃（協定世界時）に、この Web サイトでアプリケーションレベルのセキュリティポリシーの実装が開始されました。まず、国外からのすべてのトラフィックは、サーバーが応答しないためにタイムアウトするか、HTTP 502 Bad Gateway などのさまざまな HTTP エラーになります。これは、AWS の新しいアプリケーションサービス（このケースでは Amazon の WAF（Web アプリケーションファイアウォール）サービス）に切り替わったことを示しています。この切り替えは、ThousandEyes の Web ページコンポーネントビューの提供ドメインで確認できます。

13 時 55 分（協定世界時）までに切り替えが完了し、国外からのすべてのトラフィックに対して HTTP 405 エラーが返されるようになりました。これは CAPTCHA ページが提示されたときの応答です。ページ読み込みビューで CAPTCHA ページが提供されていること（captcha.js）を確認できます。この CAPTCHA ページは、ウクライナ国内からの Web トラフィックには提示されません。

図 8：ウクライナの銀行がアプリケーションレベルのセキュリティを使用して特定のトラフィックをブロック

クラウドおよびエッジセキュリティサービスを利用すると、重要な地域において中断なくサービスを提供しながら懸念のある地域では効果的なセキュリティ対策を実施できることがこの事例でも示されています。このウクライナの銀行は、2 月 23 日に AWS WAF に切り替えた後、オンラインバンキングサイトへの信頼できるアクセスをウクライナのユーザーに提供しています。

結論として、ウクライナの金融 Web サイトの多くは、クラウドホスティングやセキュリティプロバイダーを利用することで高い稼働時間を維持しているようです。ThousandEyes では情勢の進展を引き続き注視していきます。