UDP 123 ntp ポートへのアクセス急増

複数のFreeBSDサーバーを管理していますが、リモートに設置しているサーバーの所有者から、HDDのアクセスランプが点滅しっぱなしで止まらないと連絡がありました。

私のところに届いているデイリーのログや、負荷の様子、動いているプロセスをチェックしてみた感じでは特に異常はなく、ゾンビプロセスになっているプロセスもないので、一体何が起きている？と複数のログファイルを開いてみました。

外部から侵入しようと認証に失敗している形跡はなし。Webサーバーのアクセスログにも異常なし。

最後にファイヤーウォールログをチェックするものの、リモートアクセスポートへアクセスが発生している形跡もなし。一体何が？
所有者にHDDのアクセスランプに気づいた時刻を教えてもらい、ファイヤーウォールログを遡ってゆこうとしたところ、遡っても遡っても目的の時刻の場所にたどり着けない！ふとファイヤーウォールログサイズをみてみると、なんと100MBを越えています！月初めにファイルをローテートさせているので、この時期だとログファイルの大きさは100kB以下のはず。よくよくファイヤーウォールログを確認してみると、異常にntpポートへの接続が増えています。増加と言うよりも激増と言える数です。1秒間に、10～20パケットくらい到着している感じです。（ただし、サーバーの負荷には全く影響なし。）

このFreeBSDサーバーでは、ntpd を動かしており、FreeBSDのデフォルト設定を行っています。ntpクライアントとして動き、サーバーとしても使うことが出来る設定ですが、特にntpサーバーとして公開していないので誰も知らないはず。IPアドレスも2週間前に変更したばかり。
ファイヤーウォールログを遡って確認してみると、2/1の23時を境に突然 UDP port 123 へのアクセスが爆発しています。

何これ？

簡単に推測できることとしては、

1. 誰か、またはシステムが勝手にこのサーバーのIPアドレスを公式 ntpサーバーとして登録した。（P2Pファイル交換じゃあるまいし、ntpd にそんな機能あったっけ？）
2. ぱっと見、ヨーロッパに割り振られているアドレスからのパケットが多いようなので、誰かが侵入しようとサーバーに負荷を掛け続けている。

くらいです。
パケットを遮断することは簡単なのですが、インターネットはお互い様のシステムですから、このサーバーをntpサーバーとして利用したいという事であれば、上位サーバーの負荷を減らすことにもつながり、所有者がOKを出すならこのままにしておいても構いません。

もっと真面目にログを解析したり、ntp プロトコルに関して調べてみないとこれ以上の推測ができません。また同様の事例を検索してみることにしました。

まずは、ログの解析からわかったこと。

• 最初は、20台程度のホストからアクセスが発生している（ntpサーバーとして間違った設定がされている）のかと思っていたのですが、主に個人使用の不特定ホストIPアドレスからのアクセスであることがわかりました。IPアドレスから、ホスト名を逆引きしてみると、一部ですが、以下のような感じになります。

　1.1.1.1
 CPE-1-121-210-21.qwl9.woo.bigpond.net.au
 1.125.230.91
 1-160-49-231.dynamic.hinet.net
 node-fxx.pool-1-2.dynamic.totbb.net
 node-gpo.pool-1-2.dynamic.totbb.net
 host-2-102-253-169.as13285.net
 x1-6-5c-d9-98-69-50-5d.cpe.webspeed.dk
 2-108-118-114-static.dk.customer.tdc.net
 027ab853.bb.sky.com
 027a3039.bb.sky.com
 027ddbd6.bb.sky.com
 027f5646.bb.sky.com
 ARennes-654-1-130-111.w2-13.abo.wanadoo.fr
 87.Red-2-138-126.dynamicIP.rima-tde.net
 ARennes-556-1-250-211.w2-14.abo.wanadoo.fr
 2.188.197.207
 02d85459.bb.sky.com
 02daa3fd.bb.sky.com
 02dac003.bb.sky.com
 02ddadf6.bb.sky.com
 02ddfdf6.bb.sky.com
 02de28c7.bb.sky.com
 02df55f1.bb.sky.com
 略
 pa49-183-16-173.pa.vic.optusnet.com.au
 pa49-183-7-138.pa.vic.optusnet.com.au
 MTRLPQ3704W-LP130-02-845453864.dsl.bell.ca
 bas1-belleville24-845473579.dsl.bell.ca
 50.103.210.153
 50.103.210.248
 50-104-14-219.prtg.in.frontiernet.net
 50-106-67-142.ftwy.in.frontiernet.net
 50-106-70-119.ftwy.in.frontiernet.net
 50-11-209-178.par.clearwire-wmx.net
 50-11-50-233.txr.clearwire-wmx.net
 ec2-50-112-135-101.us-west-2.compute.amazonaws.com
 略
 crawl-66-249-73-110.googlebot.com
 略
 ntibrk045212.ibrk.nt.ngn.ppp.infoweb.ne.jp
 略
 google-public-dns-a.google.com

• ホスト名として、amazonaws.com のものや googlebot.com などどう考えても他人のntpサーバーを利用する必要がないホストが数多く含まれています。

ここでようやく ntp パケット激増の意味がわかりました。 ntp パケット増幅攻撃を仕掛けるための踏み台アクセスが発生しているようです。

つまり、

1. 送信元（アクセス元）IPアドレスを偽装して、ntpサーバーへ時刻問い合わせを行う。
2. ntpサーバーは偽装されたアドレスに対して、時刻を知らせるパケットを送る。
3. IPアドレスを偽装されてしまったホストは、大量の無意味なパケットを受け取る。
4. アドレスを偽られたホストというか、経路は、無意味なパケットを通過させたり受け取るしかない。

ということです。

さてどれくらいの帯域が使われていたかを確認してみると、

• 入力（問い合せ）パケットが 2 KB/s
• 出力（応答）パケットが 266 KB/s

と、130倍にもパケットが増幅されていたようです。 知らぬ間に踏み台として使われていたということです。幸いホストの所有者が気がついてくれて対策することが出来ましたが、40時間程度気づくことが出来ず、ちょっと、悔しいところです。幸い、250KB/sec程度のバンド幅だったためネットワークにそれ程大きな負荷を掛けていなかったものと推測できます。ntp のパケットもちゃんと記録するようにしておいて良かったです。

パケットの目的が判明したので、キーワードを替えて再度検索してみると、「NTPリフレクター攻撃」らしいことがわかりました。@ポリスに詳しい説明が見つかりました。

https://www.npa.go.jp/cyberpolice/detect/pdf/20140117.pdf

対策

1. NTPDを止める。この場合、偽装されたIPアドレスへICMP不達パケットが返される可能性がある。自動時刻合わせも出来なくなるので、本格対策を行うまでの一時しのぎ。
2. 単純に、UDP 123 ポートへの着信パケットを破棄するようにファイヤーウォールを設定する。（サーバー自体の時刻合わせパケットは例外として通過させるように設定しないとサーバーの時刻合わせが出来なくなります。）

私は、上記2の対策を行い経過観察を行っているところです。現時点では、ntp問い合せパケットを受け取らなくなりましたので、踏み台にされることはなくなりましたが、破棄パケットもロギングしているのでファイヤーウォールログは膨らみ続けています。HDDはまだガリガリ言っていることでしょう。サーバー所有者もHDDがガリガリ言うと気分悪いでしょうから、もう少ししたら破棄だけしてロギングは中止しようかと思っているところです。

2014/02/15 追記

JPCERT のページにも、ntpのmonlistを使ったDDoS攻撃に関してのメモが出ていて、それによると、

ntp.conf に以下の1行を追加

disable monitor

と、なっています。ファイヤーウォールを修正するより楽そうですが、トラフィックが増幅されなくても戻りパケットが出るんじゃないかという気がしています。根本的には、ntpd 4.2.7p26 以降を使うしかないようです。

2014/02/05 追記

大量の無意味なログを残すことになった今回の UDP123ポートへの大量アクセスですが、本日 06:33 を境目にピタッと止まりました。こんなことして何が楽しいの?と思う数日でした。

2014/02/13 追記

ファイヤーウォールの過去ログから、ntpサーバーへ攻撃を行ったのは誰かを推測してみました。
行き着いた先は、中国のアクセスポイントでした。