昨日、1.35Tbps に及ぶ、これまでで世界最大とされる分散型サービス拒否攻撃により、GitHub が数分間オフラインになった。
巨大津波はUTC17:21に襲来しました。この攻撃の間、人気のコード共有ウェブサイトの管理者は、数千ものシステムとデバイスがGitHubのウェブサーバーに殺到していることに気づきました。
受信ネットワークトラフィックはピーク時に1.35Tbps（1秒あたり1億2,690万パケット）に達したと報告されています。膨大なデータ量がGitHubのコンピューターを圧倒し、正規ユーザーへの応答を停止させ、事実上オフライン状態に陥りました。この時点で、GitHubはAkamaiに悪意のあるトラフィックのフィルタリングを依頼し、攻撃の影響は約5分で終息しました。
「当社の施設の1つで受信トランジット帯域幅が100Gbps以上に増加したことから、追加のエッジネットワーク容量の提供に役立つ可能性があるAkamaiにトラフィックを移行することを決定しました」と、GitHubのサイト信頼性エンジニアリング責任者であるサム・コットラー氏は木曜日に詳細を説明した。
数分以内にルートは再収束し、アクセス制御リストによって境界での攻撃が軽減されました。トランジット帯域幅レベルとロードバランサーの応答コードの監視により、UTC 17:30に完全回復が確認されました。
Pwned ... GitHubへのトラフィック量を示すグラフ
1800 UTC に 2 回目の小規模な攻撃があり、最大 400Gbps に達しましたが、サイトが再びダウンすることなく吸収されました。
この大規模な攻撃は、GitHubにジャンクトラフィックを送りつけるハッキングされたガジェットの巨大ボットネットによるものではありません。記録破りの攻撃を仕掛けた張本人は、よく知られながらもあまり使われていない「Memcrashing」という手法を用いていました。
GitHub の障害は、今週発生した 2 度目の Memcrashing 攻撃の結果であったことを考えると、他のサイトでも模倣攻撃が発生する可能性が高くなります。
メモリクラッシュは、認証要件なしにインターネットに公開されたmemcachedデータベースサーバーを悪用することで機能します。現在、このような脆弱なシステムが数万台もオンライン上に存在し、他のサービスをネットから排除するために駆り立てられる準備ができています。
増幅攻撃の仕組みはこうです。攻撃者は、オープンなmemcachedサーバーに小さなデータベースコマンドを送信し、そのリクエストのUDPパケットの送信元インターネットアドレスを攻撃対象サーバーのアドレスに設定します。memcachedデータベースは、コマンドで受信したデータの約50,000倍のデータを返します。つまり、203バイトのリクエストに対して100MBのレスポンスが返されるのです。これで、この攻撃がどうなるかはお分かりいただけるでしょう。
そのため、安全でない方法で memcached を実行している少数のコンピュータが、知らない間に投石機に変わって、何も知らないサービスや Web サイトに巨大な岩を投げつける可能性があります。
こうした攻撃は大規模ではあるものの、軽減はそれほど難しくありません。Akamai が行ったように、memcached がデフォルトで使用するポート 11211 からの UDP トラフィックを境界または上流でブロックしてみるのも良いでしょう。
一方、データベース管理者とネットワーク管理者は、memcached のインストールを不正利用されないよう保護する必要があります。UDP サポートを無効にしたり、ファイアウォールでソフトウェアを遮断したりするなどです。プログラマーも、UDP を使用するコードを書く際には、次の点に留意する必要があります。「小さなリクエストから大量のトラフィックを反射する攻撃を受ける可能性はありますか？」もしそうなら、設計図を見直しましょう。
memcached の開発者は、攻撃への対応として、ソフトウェアの将来のバージョンでは UDP サポートをデフォルトで無効にしました。
Akamai 社は、この事件に関するレポートの中で、「memcached のリフレクション機能により、この記録的な攻撃が長期間にわたって最大のものとなる可能性は低い」と警告している。
memcachedリフレクションは大規模な攻撃を仕掛ける能力があるため、攻撃者は急速にmemcachedリフレクションをお気に入りのツールとして採用する可能性が高い。さらに、攻撃者が利用可能なリフレクタのリストを作成するにつれて、この攻撃手法の影響は大幅に拡大する可能性がある。®
