ネットワークスペシャリスト 2023年 午前2 問17
問題文
NTPを使った増幅型のDDoS攻撃に対して、NTPサーバが踏み台にされることを防止する対策の一つとして、適切なものはどれか。
選択肢
ア：NTPサーバの設定変更によって、NTPサーバの状態確認機能(monlist)を無効にする。（正解）
イ：NTPサーバの設定変更によって、自ネットワーク外のNTPサーバへの時刻問合せができないようにする。
ウ：ファイアウォールの設定変更によって、NTPサーバが存在するネットワークのブロードキャストアドレス宛てのパケットを拒否する。
エ：ファイアウォールの設定変更によって、自ネットワーク外からのUDPサービスへのアクセスはNTPだけを許す。
🔒 解説は解答すると表示されます
NTP増幅攻撃対策【午前2解説】
正解の理由
選択肢アが正解です。NTPの増幅型DDoSは、攻撃者が送信元IPを被害者に偽装してNTPサーバに「monlist（mode 7 の制御メッセージ）」等の応答が大きい問い合わせを送り、サーバが被害者へ大きな応答を返すことで成立します。したがって、NTPサーバ側で monlist（mode 7）などの状態確認機能を無効にするか、これらの制御メッセージへの応答を制限すれば、踏み台として悪用されるリスクを直接低減できます。具体的対策としては、NTPデーモンの設定で制御メッセージを無効にする、restrict/noquery を用いて外部からの制御クエリを拒否する、あるいはベンダ提供の修正パッチを適用することが挙げられます。
※補足として、ntpdc は非推奨であり、monlist自体は mode 7 の制御機能であるため、対処は「monlist を無効化／パッチ適用／restrict/noquery による制限」が正しい方法です。ntpq の特定オプション（例: -c rv）が monlist の代替になる、という説明は誤りです。
解法ステップ
- 問題の本質を確認：増幅型DDoSがどのようにNTPサーバを踏み台にするか（偽装した送信元IPに対する大きな応答を誘発する）を理解する。
- 各選択肢がその仕組みにどう影響するかを検討する。
- monlist を無効化すれば（応答を抑止）増幅が止まる。
- サーバの「外向き」時刻問い合わせ制限は、サーバが被害者へ応答する問題に直接関係しない。
- ブロードキャスト宛ての遮断は通常の単一宛先の攻撃に無効。
- 外部からのUDPアクセスを NTP のみ許す設定は逆に外部NTPからのアクセスを許可してしまうため不適切。
- 以上より、最も直接的かつ確実に踏み台化を防げるのは monlist の無効化であると判断する。
選択肢別の誤答解説
- ア: 正解。monlist（NTP制御メッセージの mode 7）は増幅に使われるため、無効化またはアクセス制限（restrict/noquery）やパッチ適用で防御できる。
- イ: 誤り。自ネットワークから外部NTPへの時刻問い合わせを禁止しても、攻撃者が外部から偽装したリクエストを送ってサーバが被害者に応答する「反射／増幅」自体は止められない（サーバが「応答する」役割に対処していない）。
- ウ: 誤り。NTP増幅攻撃は一般にサーバへの単一宛先（unicast）でのmode 7要求等を利用するため、ブロードキャスト宛てパケットを拒否しても効果は限定的。ブロードキャスト遮断は別の攻撃や誤送信対策には有効だが本件の主対策ではない。
- エ: 誤り。自ネットワーク外からのUDPアクセスを「NTPだけを許す」設定は、逆に外部からのNTPリクエストを受け入れる設定になるため踏み台化を助長するおそれがある。外部からの未検証なNTP制御クエリへの応答を許すべきではない。
よくある誤解
- 「ntpq -c rv で monlist の代替になる」：これは誤りです。monlist は mode 7 の制御メッセージによるクライアントリスト取得であり、代替コマンドだからといって monlist を無効にする対策にはなりません。対策は無効化／restrict/noquery／パッチ適用です。
- 「外向きのNTP通信を止めれば踏み台化は防げる」：サーバがクライアントとして外部問い合わせを行わないようにすることは別問題であり、踏み台化（外部から送られた偽装リクエストにサーバが応答すること）を防ぐ対策とは異なります。
- 「単にファイアウォールで UDP/123 を閉じればよい」：境界で外部NTPを完全に遮断できる環境なら有効ですが、内部で時刻同期が必要な場合は正当なNTPトラフィックまで遮断する副作用があるため、サービス要件に応じたきめ細かい制御（restrict やアクセス制御リスト、レート制限）が必要です。
補足コラム
- monlist の実態：NTP の制御メッセージ（mode 7）には、サーバが最近接続したクライアント一覧を返す monlist のような機能があります。回答が大きくなりやすいため増幅攻撃に利用されました。
- 実務での対策例：
- ntpd の設定で制御クエリを拒否する（例: ntpd.conf にて restrict default noquery など）。
- ベンダやOSのセキュリティパッチを適用し、古い有害な制御機能を無効化する。
- 境界ファイアウォール・ACLで外部からの UDP/123 を必要最小限に限定する（信頼できる上位NTPサーバのみ許可）。
- レートリミットを導入して、短時間に大量の応答を返さないようにする。
- ntpd.conf の例（最小構成例）:
# 例: 外部からの制御クエリを拒否
restrict default kod nomodify notrap nopeer noquery
# 信頼する上位NTPサーバへのアクセスは許可
restrict 192.0.2.1 nomodify notrap nopeer
server 192.0.2.1 iburst
- 監視・検査：設定変更後は、社内からの時刻同期動作を確認しつつ、外部からは monlist 等の制御クエリに応答しないことをテスト（公開環境でのテストは慎重に）。
FAQ
Q. monlist を無効にすると正当な機能が失われますか？
A. 通常の時刻同期（NTP の時刻取得）には影響しません。monlist は管理・診断用の制御機能であり、これを無効化してもクライアントの同期機能は維持されます。ただし、既存の監視ツールが monlist を使っている場合は代替手段（SNMPやエージェント、ログ収集など）への移行が必要です。
A. 通常の時刻同期（NTP の時刻取得）には影響しません。monlist は管理・診断用の制御機能であり、これを無効化してもクライアントの同期機能は維持されます。ただし、既存の監視ツールが monlist を使っている場合は代替手段（SNMPやエージェント、ログ収集など）への移行が必要です。
Q. どの設定を優先すべきですか？
A. まずは脆弱性修正（パッチ）→ 設定で制御クエリを拒否（restrict/noquery）→ 境界でのアクセス制御・レート制限、の順で対処すると効果的です。
A. まずは脆弱性修正（パッチ）→ 設定で制御クエリを拒否（restrict/noquery）→ 境界でのアクセス制御・レート制限、の順で対処すると効果的です。
Q. テスト方法は？
A. 内部での同期確認と、公開環境に対しては慎重に脆弱性スキャン（適切な権限の下で）を行い、monlist 応答がないことを確認してください。公衆ネットワーク上での無断スキャンは避けてください。
A. 内部での同期確認と、公開環境に対しては慎重に脆弱性スキャン（適切な権限の下で）を行い、monlist 応答がないことを確認してください。公衆ネットワーク上での無断スキャンは避けてください。
関連キーワード: NTP、monlist、増幅攻撃、UDP/123、reflective DDoS、restrict、noquery、レート制限、ntpd.conf、パッチ管理
\ せっかくなら /
ネットワークスペシャリストを
クイズ形式で学習しませんか？
クイズ画面へ遷移する→
すぐに利用可能！