情報セキュリティマネジメント 2019年 秋期 午前(科目A) 問25
問題文
攻撃者が、多数のオープンリゾルバに対して、“あるドメイン”の実在しないランダムなサブドメインを多数問い合わせる攻撃(ランダムサブドメイン攻撃)を仕掛け、多数のオープンリゾルバが応答した。このときに発生する事象はどれか。
選択肢
ア:“あるドメイン”を管理する権威DNSサーバに対して負荷が掛かる。(正解)
イ:“あるドメイン”を管理する権威DNSサーバに登録されているDNS情報が改ざんされる。
ウ:オープンリゾルバが保持するDNSキャッシュに不正な値を注入される。
エ:オープンリゾルバが保持するゾーン情報を不正に入手される。
🔒 解説は解答すると表示されます
ランダムサブドメイン攻撃【情報セキュリティマネジメント解説】
正解の理由
攻撃者が多数のオープンリゾルバ(誰でも問い合わせ可能な再帰的DNSサーバ)を使い、実在しないランダムなサブドメインを繰り返し問い合わせると、オープンリゾルバはその都度、正しい情報を持つ権威DNSサーバ(そのドメインを管理するDNSサーバ)へ問い合わせを転送します。サブドメインが毎回異なるためキャッシュ(直近の問い合わせ結果を一時保存する仕組み)が効かず、権威DNSサーバに大量のクエリが到達して負荷が高まります。したがって、回答として正しいのは ア(権威DNSサーバに負荷が掛かる)です。
解法ステップ
- 用語を整理する
- オープンリゾルバ:インターネット上の誰からの問い合わせにも再帰的に応答するDNSサーバ。
- 権威DNSサーバ:あるドメインの正式な情報(ゾーン情報)を保持するDNSサーバ。
- キャッシュ:リゾルバが最近の問い合わせ結果を一時保存する仕組み。
- 攻撃の仕組みを把握する
- ランダムなサブドメインは毎回未登録なので、リゾルバはキャッシュできない。
- そのためリゾルバは毎回、権威DNSサーバへ問い合わせる。
- 選択肢を当てはめる
- 何が増えるか=問い合わせ回数(=権威サーバの負荷)→ ア。
- 情報の改ざんやキャッシュ注入、ゾーン情報取得は問い合わせだけでは起きない→除外。
選択肢別の誤答解説
- ア:権威DNSサーバに対する問い合わせが急増し、負荷が増す。これが本件の主被害。
- イ:問い合わせによる通信だけでは、権威DNSサーバ内の登録情報を改ざん(不正変更)することはできない。改ざんはサーバの不正侵入や管理者権限の奪取が必要。
- ウ:DNSキャッシュ汚染(不正な値の注入)は「偽装応答を混ぜる」など別の巧妙な攻撃手法であり、ランダムサブドメイン攻撃自体は大量の正当な(だが無意味な)クエリを送ることが主目的で、キャッシュ注入を自動的に引き起こすものではない。
- エ:ゾーン情報の不正入手(ゾーン転送=AXFRなど)は、リゾルバからの通常の再帰的問い合わせでは起きない。ゾーン転送は特別な要求であり、通常はアクセス制限されている。
よくある誤解
- 誤解1:DNSSEC(DNSの認証技術)を導入すればDDoSは防げる。
→ DNSSECは応答の改ざん防止(整合性)には有効ですが、問い合わせ量そのものを減らすわけではないため、DDoS対策には別途対策が必要です。 - 誤解2:攻撃対象だけが被害者だと思いがち。
→ オープンリゾルバも攻撃に悪用されるためISPや管理者側にも責任・負荷・対処が生じることがある。
補足コラム
運用面のイメージ:会社が自社ドメインの権威DNSを外部のDNS事業者に委託している場合、最初の対応はDNS事業者に連絡することです。事業者は通常、レスポンスレート制限(RRL: Response Rate Limiting)やAnycast(世界中の複数拠点で同一IPを持つ配信)による吸収、DDoS対策サービスで一次対応します。社内でできることとしては、契約するDNSプロバイダにDDoS対応状況を確認し、SLAや対策の有無を契約に明記することが実務的です。
具体的な対策例:
- オープンリゾルバを放置しない(再帰を外部に開放しない)。
- 権威DNSにRRLやレート制限を設定する。
- 権威DNSを高可用なプロバイダ/Anycastで運用する。
- ログと監視で短時間のトラフィック増を検出し、プロバイダに連絡する。
- DNSSECはデータ改ざん対策として有効だが、DDoS対策は別途必要。
FAQ
Q1: この攻撃でドメインの中身(ウェブサイト)が改ざんされますか?
A1: いいえ。ランダムサブドメイン攻撃は大量の問い合わせでサーバを疲弊させる攻撃で、直接の改ざん行為ではありません。ただし、サービス停止(可用性の喪失)によって間接被害は生じます。
A1: いいえ。ランダムサブドメイン攻撃は大量の問い合わせでサーバを疲弊させる攻撃で、直接の改ざん行為ではありません。ただし、サービス停止(可用性の喪失)によって間接被害は生じます。
Q2: 自社に対する攻撃かどうかはどうやって分かりますか?
A2: DNSサーバのログで短時間に見慣れない多数の異なるサブドメインへのクエリが多数発生しているかを確認します。通常、権威サーバのログで判断できます。分からない場合はDNSプロバイダに相談してください。
A2: DNSサーバのログで短時間に見慣れない多数の異なるサブドメインへのクエリが多数発生しているかを確認します。通常、権威サーバのログで判断できます。分からない場合はDNSプロバイダに相談してください。
Q3: 社内の非IT担当がとるべき初動は?
A3: DNSプロバイダや運用を委託しているベンダーに速やかに連絡し、発生している状況(ログや通知)を共有すること。外部に委託していない場合は社内ITに連絡のうえ、外部のDDoS対策サービスを検討します。
A3: DNSプロバイダや運用を委託しているベンダーに速やかに連絡し、発生している状況(ログや通知)を共有すること。外部に委託していない場合は社内ITに連絡のうえ、外部のDDoS対策サービスを検討します。
関連キーワード: オープンリゾルバ、権威DNS、DNSキャッシュ、ランダムサブドメイン攻撃、DDoS、RRL、ゾーン転送、DNSSEC

\ せっかくなら /
情報セキュリティマネジメントを
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

