通信を止めたのに、攻撃が止まらない

架空事例：青葉機材が取引先向け予約サービスを公開する。アクセス数、通信の構成、障害影響は架空の例であり、製品固有の遮断性能やDDoSへの実測保証ではない。

ファイアウォールを置いた翌日

公開サービスの前段にファイアウォールを置き、不要なポートを閉じた。外部から接続できる経路は整理された。にもかかわらず、予約検索に異常に重い条件を繰り返す要求が来ると、サーバの応答は遅くなった。

通信してよいことと、通信の中身が業務上妥当であることは違う。

ファイアウォールは、送信元・宛先や通信状態などを使い、境界を通る通信を制御する。WAFはHTTPなどWebアプリケーション向け通信を解析して攻撃への対策を行う。IDSは侵入の兆候などを検知し、IPSは一定の条件で阻止する役割を持つ。実装製品の機能は重なり得るが、守る対象と観察する情報を区別したい。1

ここで青葉機材が解決したいのは「使ってよい予約画面が、過度の負荷で使えなくなる」という問題である。HTTPリクエストが正しい形式でも、検索の組合せや対象件数によって資源を大量に消費するなら、入力の意味と必要な処理能力を設計しなければならない。

層が変われば、見えないものも変わる

ポート443への通信を許可するとき、ネットワーク境界はHTTPSの利用を可能にする。しかし、それだけで「この顧客がこの予約を読むべきか」という権限は決まらない。HTTPの内容を調べるWAFでも、すべての業務上の関連を知っているとは限らない。

逆に、アプリケーション内部で本人確認・権限検査が適切でも、外部回線が飽和して要求が届かなければ、利用者はサービスを使えない。どこに検査を置くかによって、防げる問題と防げない問題が残る。

青葉機材は、回線、TCP接続、HTTPリクエスト、業務操作、DBクエリという五つの単位を分けた。各段階で、何を数え、何を遮断し、何を記録できるかを見る。何万のパケットがあるから何万件の予約が実行された、とは言えないし、少数の要求だから負荷が小さいとも限らない。

境界を多く置けばよいというものでもない。複数の層で同じ要求を誤って拒否すれば、正しい顧客を締め出すことになる。対策が原因で失われる可用性も評価に含める。

DDoSは、巨大な一つの要求ではない

大量のHTTP要求が並ぶ場面を想像しやすいが、DDoSは帯域、接続状態、アプリケーション処理など異なる資源を狙い得る。DNSを利用した反射・増幅攻撃では、攻撃者からの小さな問い合わせを契機に、第三者から比較的大きな応答が被害先へ送られることがある。1

DNSのオープンリゾルバが誰に再帰問い合わせを許可するかは、悪用可能性に関係する。DNSの名前解決ができるということと、誰からでも無制限に再帰問い合わせを受け付けることは別である。送信元を詐称した通信を減らす上流での対策も重要になる。

青葉機材の回線が限界に達した場合、自社サーバで通信を拒否するだけでは、既に回線へ到達しているトラフィックによる圧迫を解消できない場合がある。上流ネットワークや配信基盤で処理する対策が必要になることもある。

ただしDDoS対策サービスへ任せれば、注文の二重確定や顧客情報の誤閲覧まで直るというわけではない。可用性を守る境界と、業務を守る境界は別に設計する。

NATは、防壁ではなくアドレスの変換でもある

社内の予約管理端末はプライベートアドレスを使い、外へ出る通信はNAPTで変換していた。管理者は「内部アドレスが隠れているので安全」と考えた。

アドレスやポートの変換によって、外部から内部端末へ直接届く経路が限られることはある。しかし変換機構それ自体が、正しい利用者か、許可されたURLか、攻撃パターンかを判定するものではない。業務データへのアクセス権限の代わりにはならない。

同じくVPNは、離れた場所の通信路を保護する設計の一部である。適切に接続した端末からの要求でも、利用者に他社の予約を閲覧させてよいわけではない。「社内ネットワークから来た」ことと「業務の権限を持つ」ことを一致させない。

技術名を階層ごとに置き直すと、午前Ⅱでよくある混同を避けられる。トンネリング、暗号化、アクセス制御、認証、アプリケーション認可は隣接していても同義ではない。1

ルールの精度だけでは、運用は成立しない

WAFで多くの要求を遮断できたとしても、正当な検索が誤って攻撃として扱われれば顧客の仕事は止まる。許可を緩めれば危険な要求が通る可能性がある。誤検知と見逃しの両方を考える。

青葉機材では、遮断した理由を調査できるようにする。どのルールが作用し、どの利用経路に影響し、再現できるか。すべての通信内容を長期間記録すると、機密情報の保存や保護が新たな課題になるため、監視ログにも必要な範囲を定める。

「ルールを更新した」という作業と、「攻撃を受けたときにも業務を継続できる」という結果は分けて確認する。平常時の正常通信だけでなく、負荷や外部通信停止を想定した検証条件が必要になる。監視と利用者への説明も運用計画へ含める。

NISTのファイアウォールガイドは、ルールや境界の配置・管理が設計対象となることを示している。2 ただし本章では特定のネットワーク製品へ同じルールやしきい値を強制しない。

認証前の入口と、認証後の高価な操作

攻撃への制限をすべてログイン前に置いたらよいだろうか。確かに、公開されている認証画面への過剰なアクセスは入口で制御する必要がある。しかし認証済みの主体が、大量の帳票を同時に出すこともできる。

資源制限は、「認証済みだから無制限に許可する」という設計にはならない。利用者、契約先、操作種別、同時実行数、コストの大きさなどに基づいて、どの単位で公平に資源を配分するかを決める。単純なIPアドレス単位の上限は、共有回線を使う多数の正当な利用者を巻き込む場合がある。

一方、制限が強すぎて、障害の復旧を急ぐ配送担当者まで操作できなくなる可能性もある。重要な処理をどこまで優先するか、どの要求を保留・拒否するかを、運用時の業務継続と結び付けて考える。

アプリケーションの重い処理をキューへ移すこともある。ただしキューを導入しただけで処理資源の総量が増えるわけではない。要求を受け付け続ければ未完了件数が増え、待ち時間や保存容量が限界になる。受付可能な仕事の量と、処理を完了できる量を別々に見積もる。

誰が守る場所なのかを、図に残す

青葉機材が採用する境界には、回線事業者の領域、配信基盤、ゲートウェイ、業務アプリケーション、データベースがある。何かが失敗したときの連絡先と、何を変更できるかがそれぞれ異なる。

「クラウドなのでDDoS対策済み」という説明では、どの層のどの種類の攻撃を防ぎ、残る資源制限を誰が持つのか分からない。外部サービスを利用する場合ほど、責任分界を明確にする。

機器を導入したことではなく、守りたい利用者の仕事が続くことを目的にする。この考え方はネットワーク方式設計を、システム全体のサービスレベルへ接続する。

知識を答案へ戻す

午前Ⅱ。 ファイアウォール、WAF、IDS/IPS、NAT/NAPT、VPN、DDoS対策の働く層と保証対象を区別する。

午後Ⅰ。 帯域・接続・HTTP・業務処理・DBのうち、どこが過負荷かを本文の条件から特定する。ネットワーク装置の導入だけで業務上の認可が成立したとは考えない。

午後Ⅱ。 重要な操作の継続性、必要な監視、誤遮断、資源制限、外部サービスとの責任分界まで含めた方式選定を説明する。

立ち止まって考える：WAFがSQLインジェクションらしい通信を遮断したので、業務アプリケーションのパラメータ化を省いてよいか

省けない。WAFの遮断範囲と、SQLへ外部入力を命令として渡さない実装は別の防御である。脆弱な文字列連結を残すことは正当化されない。

出典と照合範囲

[1] コンプリートテキスト第7・13・19・21・22章、IPA SAシラバスVer.5.2：通信装置、Web攻撃、DDoS、サービスレベルの基礎を出発点とした。公式シラバス

[2] NIST SP 800-41 Rev.1（2009）：ファイアウォールのポリシーと運用を設計対象として扱う考え方を参照した。本章のWAFやDDoSへの個別設定値を定義する資料ではない。公式資料

[3] OWASP Authorization Cheat Sheet：業務資源の認可を通信経路の保護とは別に実施する根拠を参照した。公式解説