情報処理安全確保支援士 2025年 春期 午前2 問01

反射増幅型DDoS【午前2解説】

正解の理由

解法ステップ

1. 攻撃の手口をキー要素で分解する：送信元偽装（スプーフィング）／第三者を介する（反射）／応答の増幅性。
2. 各選択肢が上記のどれに該当するかを判定する：
   • 送信元偽装＋第三者の応答→反射増幅型（DRDoS）。
   • 直接多数の接続や特殊パケット送出のみ→直接型（SYNフラッド等）やアプリ層攻撃。
3. 最も条件に一致する選択肢を選ぶ。

選択肢別の誤答解説

• ア: 脆弱性発見から対策提供までの猶予を利用して資源を枯渇させる記述は、脆弱性悪用による DoS（ゼロデイ攻撃やエクスプロイトの悪用）を示していますが、反射・送信元偽装の概念は含まれません。したがって DRDoS ではありません。
• イ: SYN パケットを繰り返す攻撃は典型的な SYN フラッド（TCP スタックのリソースを直接枯渇させる）であり、送信元を偽装して第三者を介する反射増幅型とは異なります。
• ウ: 多数の DNS サーバに対して送信元を標的に偽装してリクエストを送り、返ってくる応答で標的を攻撃する—これが反射増幅型（DRDoS）の典型例です（選択肢 ウ）。
• エ: 長時間かけて多数の HTTP リクエストでセッションを占有する攻撃（例：Slowloris）はアプリケーション層のリソース枯渇攻撃であり、反射増幅の要素はありません。

よくある誤解

• 「BGP フィルタリングで送信元偽装を防げる」：これは誤解です。BGP は経路情報の交換プロトコルであり、送信元アドレスの整合性検証には直接関与しません。送信元偽装の防止には BCP38 に基づく Ingress フィルタリングや uRPF（逆経路検査）などのルータレベルの対策が有効です。BGP は攻撃トラフィックを特定経路へ誘導（RTBH）して遮断するなどの緩和策には使えますが、偽装そのものを防ぐ手段ではありません。
• 「DNSSEC を入れれば DRDoS が防げる」：DNSSEC は応答の信頼性を高めますが、署名付き応答はサイズが大きくなることがあり、場合によっては増幅被害を悪化させることがあります。DRDoS の防止とは別の観点で設計判断が必要です。

補足コラム

• よく使われるプロトコル：DNS（特にオープンリゾルバ）、NTP（monlist の頃）、SSDP、Chargen、Memcached（大容量増幅）など。これらは小さなリクエストで大きな応答を返す特性があると増幅に用いられやすい。
• 防御・緩和策（運用上有効な組み合わせ）：
  • 送信元偽装防止（発信側／中継側の対策）
    • BCP38 に基づく Ingress フィルタリング（自ISPや自ネットワークの出口で送信元アドレスが自ネットワーク範囲に合致するか検証）
    • uRPF（ルータでの逆経路検査）や Linux の rp_filter
  • リフレクタ側の対策
    • オープンリゾルバの閉鎖（パブリックに対する再帰的問い合わせを制限）
    • DNS サーバの応答率制限（RRL: Response Rate Limiting）
  • 受け手・運用者の緩和
    • CDN／Anycast による負荷分散
    • フロー解析とスクラビング（大規模なトラフィックをクリーンルームに誘導して除去）
    • ブラックホール（ネットワーク単位でのドロップ）や RTBH（経路を使った一時遮断）の活用（サービス遮断の代償を伴う）
• 設定例（参考）
  • Linux での逆経路検査（rp_filter）有効化例:

    sysctl -w net.ipv4.conf.all.rp_filter=1
    sysctl -w net.ipv4.conf.default.rp_filter=1
    

  • Cisco IOS の uRPF（簡易例）:

    interface GigabitEthernet0/0
     ip address 203.0.113.1 255.255.255.0
     ip verify unicast source reachable-via rx
    

  • BIND の応答率制限（RRL）設定例:

    options {
      rate-limit {
        responses-per-second 5;
        window 5;
      };
    };
    

FAQ