NTPリフレクション攻撃対策の基本。踏み台にされないために今見直すべきこと

NTPリフレクション攻撃対策は、DDoS対策の中でも見落とせないテーマです。
NTPは時刻同期に欠かせない仕組みですが、古い実装や不要な応答機能を外部から到達可能な状態で残したまま運用すると、第三者へのDDoS攻撃の踏み台として悪用されるおそれがあります。
実際にNTP Projectは、ntpd 4.2.7p26より前ではmonlist関連機能が増幅攻撃に悪用され得ると案内し、更新や設定変更を緩和策として示しています。
CloudflareやCiscoも、MONLISTに応答するNTPサーバーは小さな要求に対して大きな応答を返し得るため、攻撃の増幅に使われると説明しています。
つまり、問題の本質はNTPを使っていること自体ではなく、増幅に使われる条件を残したまま公開していることにあります。

この記事では、NTPリフレクション攻撃の仕組みから、優先して進めたい対策、運用時の注意点までを一つの流れで整理します。
仕組みだけを知って終わるのではなく、現場で何を止め、何を残すべきかがわかる形でまとめます。

NTPリフレクション攻撃とは何か

NTPサーバーの応答を踏み台にして被害者へ通信を集中させる攻撃

NTPリフレクション攻撃とは、送信元IPアドレスを被害者のものに偽装したNTPリクエストを送り、NTPサーバーの応答を被害者へ集中させるDDoS攻撃です。
JANOGの資料では、送信元IPアドレスを被害者のものに偽装した問い合わせを多数のNTPサーバーへ送ることで、応答が被害者へ集中する仕組みが説明されています。
NTP Projectも、monlistへの無制限なアクセスが、偽装された要求によるトラフィック増幅型のDoSに悪用され得ると案内しています。

この攻撃が成立しやすい背景には、UDPベースで送信元IPアドレスを偽装しやすいことに加え、monlistなど一部の問い合わせでは、要求より大きな応答が返ることがあります。
Cloudflareは、古いNTPサーバーで有効なmonlistコマンドが大きな応答を返すため、攻撃の増幅に使われると説明しています。
Ciscoも、MONLISTに応答するNTPサーバーは、リクエストよりはるかに大きな応答を返し得ると解説しています。
そのため、攻撃者自身が大きな帯域を持っていなくても、公開NTPサーバーを使って被害を拡大しやすくなります。

古いmonlist機能が代表的な悪用ポイントとして知られている

NTPリフレクション攻撃で特によく知られているのが、monlist機能の悪用です。
NTP Projectのセキュリティ通知では、ntpd の4.2.7p26未満が対象で、REQ_MON_GETLISTまたはREQ_MON_GETLIST_1によるトラフィック増幅が可能だとされています。
さらに、4.2.7p26以降で解消されており、旧バージョン利用時はnoqueryやdisable monitorが緩和策になると案内されています。

JANOGの資料でも、monlistは多くの機器で通常は不要な場合が多く、適切な制限がなければ不特定多数へ情報を返してしまうことが問題だと整理されています。
言い換えると、NTPリフレクション攻撃対策では、NTPを使っていること自体より、古い実装や不要な応答機能を残していることがリスクになります。
NTPリフレクション攻撃で注意すべきなのは、時刻同期の存在ではなく、増幅に使われる応答を返してしまう状態です。

NTPリフレクション攻撃対策で優先したい基本施策

古いntpdやNTP機能を使い続けない

NTPリフレクション攻撃対策でまず優先したいのが、古いNTP実装をそのまま使い続けないことです。
NTP Projectは、ntpd 4.2.7p26より前ではmonlist関連の要求がトラフィック増幅型のDoSに悪用され得るとしており、4.2.7p26以降への更新を案内しています。
Ciscoも、MONLISTに応答するNTPサーバーは、要求より大幅に大きい応答を返し得ると説明しています。
このことからも、古い実装を残したまま運用すること自体が、大きなリスク要因になりやすいとわかります。

見た目には普通に時刻同期できていても、それだけで安全とは言えません。
時刻同期ができていることと、増幅攻撃に悪用されないことは別の話です。
そのため、まず対象機器やサーバーのNTP実装が古いままになっていないかを確認する必要があります。
Red HatやMeinbergも、更新や監視機能の無効化を緩和策として案内しています。

monlistなど不要な応答機能を無効化する

NTPリフレクション攻撃で代表的に悪用されてきたのが、monlistによる大きな応答です。
NTP Projectは、更新がすぐに難しい場合の緩和策として、noqueryの利用とdisable monitorの設定を示しています。
Meinbergも、4.2.7p26以降ではmonlistが無効化され、mrulistに置き換えられたと説明しています。更新が難しい場合は、monlistを無効化する設定が緩和策になります。
つまり、NTPサービスを止めなくても、増幅に使われる応答機能を止めることでリスクを下げやすくなります。

重要なのは、時刻同期に不要な問い合わせへ外部から応答しない状態を作ることです。
外部向けに監視情報や一覧情報を返す必要がないなら、その機能は閉じたほうが安全です。
NTPをやめることではなく、悪用される応答を返さない状態へ整えることが対策の中心になります。

外部へ公開する必要がないNTPサーバーは閉じる

NTPリフレクション攻撃対策では、そもそも外部へ公開する必要がないNTPサーバーを閉じることも重要です。
JANOGの解説資料では、不適切な状態のNTPサーバーが反射板として利用される仕組みが説明されています。
Ciscoも、この攻撃は一般的なリフレクション型DDoSと同じで、第三者に大量の不要通信を送りつける形になると解説しています。
そのため、インターネットから利用される必要がないNTPサーバーは、外部から到達できないようにするのが基本です。

社内向けだけでよいNTPサーバーまで外部公開している。
ネットワーク機器のNTP機能が意図せずインターネットへ開いている。
こうした状態では、管理者が気づいていない機器が踏み台になることがあります。
公開範囲を見直し、必要な接続元だけに絞ることが有効です。

送信元IPアドレス偽装を通しにくいネットワーク運用を行う

NTPリフレクション攻撃は、送信元IPアドレスを被害者のものへ偽装した要求を反射板へ送ることで成立します。
CISAは、増幅型攻撃の説明の中で、UDPベースのサービスが偽装された送信元アドレスと組み合わさることでDDoSに悪用されると案内しており、BCP 38などの送信元アドレス検証を対策として挙げています。
JANOGの資料でも、送信元アドレスを偽装した問い合わせが被害者へ応答を集中させる仕組みが示されています。
つまり、反射板対策だけでなく、偽装パケットを出しにくいネットワーク運用も重要です。

自組織が攻撃を受けないようにするだけでは不十分です。
自組織のネットワークから偽装パケットを出さないことも、全体としての対策になります。
NTPリフレクション攻撃は一台の設定だけで完結する話ではなく、ネットワーク全体の出口対策とも関わっています。

NTPリフレクション攻撃対策を進めるときの注意点

NTPを止めることだけが対策ではない

NTPリフレクション攻撃対策というと、NTPサービスそのものを止める話だと思われがちです。
しかし、本当に重要なのは、時刻同期をやめることではなく、増幅に使われる条件をなくすことです。
NTP Projectは、ntpd 4.2.7p26より前の実装でmonlistが悪用され得ると案内しつつ、更新、noquery、disable monitorを緩和策として示しています。
このことからも、対策の中心は、不要な応答機能を残さないことと、古い実装を使い続けないことにあるとわかります。

社内で時刻同期が必要な環境は多くあります。
そのため、NTPを全面停止するのではなく、誰に対して何を返す必要があるのかを整理し、不要な応答だけを止める考え方が現実的です。
時刻同期の必要性と、公開範囲や応答機能の制御は分けて考えることが大切です。

サーバーだけでなくネットワーク機器も確認する

NTPリフレクション攻撃対策では、サーバーの設定だけ見て終わらせないことが重要です。
JANOGの資料では、一般的なサーバーだけでなく、さまざまな機器が反射板として使われ得ることが示されています。
Ciscoも、Mode 7要求に応答する脆弱なNTPサーバーや機器が、リフレクション攻撃に悪用され得ると説明しています。
そのため、LinuxサーバーやWindowsサーバーだけでなく、ルーター、スイッチ、ファイアウォール、専用機器などでNTPサービスが有効になっていないか、外部から応答していないかも確認対象に含める必要があります。

管理者が普段意識していない機器でも、NTP機能が有効のままになっていることがあります。
その結果、サーバー側の対策が済んでいても、別の機器が踏み台として残る場合があります。
一台ずつではなく、ネットワーク全体でNTP応答の有無を把握することが重要です。

一度対策して終わりにしない

NTPリフレクション攻撃対策は、一度設定したら終わりというものではありません。
機器の入れ替え、新しい拠点の追加、設定変更、ファームウェア更新などがあるたびに、意図せず公開状態が変わることがあります。
NTP Projectは、脆弱な挙動を持つ実装に対して更新や設定変更を求めています。
このことからも、古い設定が再び残っていないかを定期的に見直す必要があるとわかります。

新しい機器を導入したときにNTPが初期設定のまま有効になっている。
保守作業で設定が戻ってしまう。
外部公開範囲の変更で意図せず応答可能になる。
こうしたことは現実に起こり得ます。
そのため、対策後も定期的に確認する運用を組み込んでおくことが重要です。

自組織が被害者になる視点と加害側にならない視点の両方を持つ

NTPリフレクション攻撃対策では、自社が攻撃を受けないようにする視点だけでは不十分です。
自組織のサーバーや機器が、第三者を攻撃するための踏み台にならないようにする視点も必要です。
CISAは、UDPベースの増幅攻撃に対して、公開設定の見直しに加え、送信元IPアドレス偽装を通しにくくするBCP 38などの対策を案内しています。
JANOGの資料でも、送信元アドレスを偽装した問い合わせが反射板を通じて被害者へ集中する仕組みが示されています。

つまり、対策の目的は自社防衛だけではありません。
外部公開の不要なNTP応答をなくすこと。
偽装パケットを出しにくいネットワーク運用を行うこと。
こうした対応を通じて、被害者にも加害側にもなりにくい状態を作ることが大切です。
NTPリフレクション攻撃対策で重要なのは、自組織を守ることと同時に、踏み台にならないことまで含めて考えることです。

まとめ

NTPリフレクション攻撃対策は増幅に使われる条件を残さないことが基本

NTPリフレクション攻撃は、NTPサーバーの応答を踏み台にして、被害者へ大量の通信を送りつけるDDoS攻撃です。
JANOGの資料では、送信元IPアドレスを被害者のものに偽装した問い合わせを多数のNTPサーバーへ送ることで、応答が被害者へ集中する仕組みが説明されています。
NTP Projectも、monlistへの無制限なアクセスが、偽装された要求によるトラフィック増幅型のDoSに悪用され得ると案内しています。
CloudflareやCiscoも、MONLISTに応答するNTPサーバーは、要求より大きな応答を返し得るため、攻撃の増幅に使われると解説しています。
つまり、この攻撃の本質は、NTPを使っていることそのものではなく、大きな応答を返す条件が残っていることにあります。

対策として優先したいのは、古いntpdやNTP機能を使い続けないことです。
NTP Projectは、ntpd 4.2.7p26より前ではmonlist関連の要求が悪用され得るとして、4.2.7p26以降への更新を案内しています。
さらに、更新がすぐに難しい場合の緩和策として、noqueryやdisable monitorを示しています。
MeinbergやRed Hatも、同様に古い実装の更新や監視機能の無効化を案内しています。
このことからも、まずは古い実装を残さないことと、不要な応答機能を止めることが基本になります。

また、外部へ公開する必要がないNTPサーバーや機器を閉じることも重要です。
JANOGは、不適切な状態のNTPサーバーが反射板として利用される仕組みを説明しており、CiscoもNTPサービスを提供する機器全般が悪用され得るとしています。
そのため、サーバーだけでなく、ルーター、スイッチ、ファイアウォール、専用機器も含めて、不要な外部応答が残っていないかを確認する必要があります。
社内向けだけでよいNTPサービスまでインターネットへ開いている状態は避けるべきです。

さらに、NTPリフレクション攻撃対策では、自組織が被害者にならない視点だけでなく、踏み台にならない視点も欠かせません。
CISAは、UDPベースの増幅攻撃に対して、公開設定の見直しに加え、BCP 38などの送信元IPアドレス検証を対策として案内しています。
JANOGの資料でも、送信元アドレスを偽装した問い合わせが反射板を通じて被害者へ集中する仕組みが示されています。
つまり、不要なNTP応答をなくすことと、偽装パケットを出しにくいネットワーク運用を行うことの両方が大切です。

NTPリフレクション攻撃対策で本当に重要なのは、NTPサービスを止めることではありません。
増幅に使われる応答を返さないことです。
古い実装を残さないことです。
不要な公開範囲を閉じることです。
そして、自組織が攻撃を受けないことと同時に、第三者への攻撃の踏み台にならない状態を維持することです。
そうした基本を継続して見直すことが、現実的で効果のあるNTPリフレクション攻撃対策につながります。