2018 年 2 月末に報告された増幅型の「分散型サービス拒否（distributed denial-of-service、DDoS）攻撃」で、分散型メモリキャッシュシステム「memcached」を利用する新しい手法が確認されました。DDoS 攻撃で利用されるプロトコルといえば「Domain Name System（DNS）」、「Universal Plug and Play（UPnP）」、「Session Description Protocol（SDP）」、「Network Time Protocol（NTP）」などが一般的です。しかし、memcached を利用すると、過去に確認された DDoS 攻撃よりもはるかに大規模な攻撃を実行される恐れがあります。memcached はデータベースへのアクセスに関連した冗長な処理を削減することでデータへのアクセスを高速化しますが、残念なことにこのような memcached の特徴が DDoS 攻撃の増幅にも威力を発揮することが確認されました。
■ memcached を利用した DDoS 攻撃の仕組み
数日間の間に CDN サービス「Cloudflare」とリポジトリホスティングサービス「GitHub」がこの新しい増幅型 DDoS 攻撃の対象になりました。GitHub が利用する CDN サービス「Akamai」の測定によると、1.35 TBps 以上の受信トラフィックが GitHub のサーバで確認されています。
図 1：GitHub の 1 秒あたりの受信ビット数（画像はGitHubの公式ブログより引用）
これらのトラフィックはそれ自体が単体で攻撃となるわけではありませんが、大量のネットワーク通信が積み重なって最終的に大きな影響を与えることに留意してください。サイバー脅威の監視、調査、分析を行う Akamai のチーム「Akamai SIRT」によると、今回の攻撃は 2016 年 9 月に確認された「Mirai」による DDoS 攻撃の約 2 倍の規模でした。
memcashed の使い方は簡単で、キーを指定して問合せを行い対応する値を受け取る仕組みです。また、必要に応じて 1 度の問い合わせで複数のキーを指定できるという利点もあります。
図 2：memcached を利用した DDoS 攻撃
今回の攻撃で、攻撃者は memcached サーバに「GETS」リクエストを送信し、それがどのようなものであれ既存の値を取得します。しかし、多くの場合 memcached サーバは不用意に「SET」コマンドの実行を許可しています。SET は memcached サーバにキーと値を登録するコマンドです。攻撃者は SET コマンドを利用して上限サイズの「バイナリ・ラージ・オブジェクト（BLOB）」データを登録し、任意のキーを指定します。次に、このキーを指定して GETS リクエストを送信し、対象に送信されるリフレクション攻撃のサイズを最大化します。
memcached は TCP プロトコルには初期インストールされており、UDP にもインストール可能です。しかし、今回の攻撃が主に UDP が使用する 11211 番ポートで確認されているのは、UDP プロトコルは送信元アドレスの偽装がはるかに容易で、リフレクション型の DDoS 攻撃に適しているからだと考えられます。
オンライン検索エンジン「Shodan」によると、2018 年 3 月 3 日の時点、世界全体で確認された 120,458 台の memcached サーバのうち、1 万台近くのサーバが UDP で memcached を実行していました。これらのサーバのほぼ 3 分の 1 が現在進行中の攻撃で確認されています。
図 3：インターネットに露出した memcached サーバ（Shodan の検索結果）
■DDoS 攻撃で送信されるデータの大きさ
送信したリクエストに対して memcached が返す値がどの程度増幅されるのかは BLOB データのサイズに依存します。一般的に、この最大値は比較的小さく設定されていますが、memcached サーバをホストするプロバイダには、場合によっては100G 以上というはるかに大きな BLOB データを許容しているものもあります。その結果、DDoS 攻撃の増幅値も大きくなります。
とはいえ、今回のような DDoS 攻撃のサイズには他の制限要因もあります。第一に、リフレクションに利用される memcached サーバの通信リンクによる制約を受けます。通信速度が 1Gbps だった場合、攻撃によって作成された BLOB データのサイズにかかわらず 1Gbps でしか送信できません。ネットワークカードについても同様です。最後に、UDP は分割して送信したパケットを受信側で再構築できるように、16 ビットを使ってパケットのバイト長を表します。つまり、1 つのパケットで送信可能なデータ長は 65,536 バイトです。しかし、今回確認された攻撃で送信されたパケットのサイズは 1,428 バイトでした。これはイーサネットフレームの最大サイズによる制約があるためだと考えられます。簡潔にまとめると、memcached が GETS リクエストに対して返すデータを非常に大きくすることは可能ですが、通信の仕組みによる制約によって上限が決まります。
■被害に遭わないためには
では、memcached を利用した DDoS 攻撃の影響はどの程度のものになるでしょうか。この新しい攻撃手法の可能性についてはまだ理解の初期段階にありますが、「Neighbor Discovery Protocol（NDP）」や「Simple Service Discovery Protocol（SSDP）」、そして DNS を利用した増幅型 DDoS 攻撃でさえ大規模な攻撃の継続は確認されていません。memcached の場合もそのようなことは起きないと考えられます。ただし、memcached を利用した DDoS 攻撃の通信サイズについては、高い確率で増加することが予測されます。その他の DoS 攻撃と同様に、以下のような対策が可能です。
- Memcached 攻撃について理解する
セキュリティ企業「Arbor」と「360 Netlab」が今回の攻撃について優れた分析を行っています。 - 送受信の両方についてネットワークトラフィック監視する
トレンドマイクロのネットワーク挙動監視ソリューション「Deep Discovery™ Inspector」やネットワーク脅威防御ソリューション「TippingPoint」によってネットワークを防御することが可能です。 - 複数の上流プロバイダと契約する
主サーバが DDoS 攻撃を受けた際に代替サービスに切り替えるための冗長性を持たせることが可能です。 - 契約しているネットワークプロバイダの対策を確認する
「BCP 38」や「BCP 84」のようなパケットフィルタリングによって、送信元を偽装したパケットの転送を防ぎ、リフレクション攻撃で利用されるパケットがそもそもネットワークに入って来れないようにすることが可能です。 - 適切なアクセス制御を実施する
自社で memcached サーバを運用している場合、攻撃の踏み台にされることを防ぐためにも、必要最小限の IP アドレスに対してのみ公開を制限する、使用ポートの制限を行うなど、適切なアクセス制御の実施が推奨されます。
※謝辞：Damien Menscher（Google）、John Matherly（Shodan）
※調査協力：William Gamazo Sanchez(DSLabs)
参考記事：
翻訳： 澤山 高士（Core Technology Marketing, TrendLabs）