NTPリフレクション攻撃に関して

2014-02-22

シェア

先日、2月20日頃、自宅で運用していたサーバーが同攻撃を受けました。

このようなことはブログで書くべきことではないかとは思いますが、今回その被害状況と得られた教訓を、忘れないようにここに記しておきたいと思います。

成り行き

2月20日 14時頃 プロバイダから警告がきました。内容は「お使いのインターネット回線が、11時頃から上り方向へ、非常に大量の帯域を使用しているため、回線を一時ストップさせた」とのこと。

当初は新手の詐欺かと思い、かかってきた番号を検索すると、プロバイダのホームページがヒット。顔面蒼白になりながら契約回線のIPアドレスにpingを送ったところ、どうやら応答が返ってこないので、本当に回線がストップされたということが分かりました。

当時私は実家に帰省しており、状況を確認するにも、回線自体が止まっているので、確認できず。

なるべく早く状況を把握し、詳しいログを確認するため、親友にお願いして家まで確認しに行ってもらいました。

夜19時頃、寒い中家まで駆けつけてくれた友人と電話で通話しながら、検証開始です。

まずは、ルーターの外向きNICの帯域使用量を確認しました。

95.4Mbps、ざっと計算すると 12MB/s、回線がストップされるまでに、およそ 150GBを転送していたことになります。

予想以上の状況に焦りつつ、次は物理マシンのコンソールに入り、各VMの帯域使用量を確認しました。

私の設定ミスもあり、ログの確認に少々手間がかかりましたが、結局確認できたログでは、当時それほど帯域を使用していなかった模様。

ひとまず次の可能性、ゲスト用WiFiの乗っ取りを考えます。

私の家では、内部にアクセスできるものと、サブネットを分けたゲスト用のもの、合計2本が飛んでいます。

2本のWiFiを調査してみましたが、どちらも不審なコネクションログは残っていませんでした。

そこでもう一度ルーターのNICの帯域使用状況を見たところ、あることに気づきました。(というよりも、ご指摘頂きました)

このように見比べて見れば分かるとは思いますが、ルーターの外向きNICのoutgoingの量に対して、内向きNICのincomingの量が桁違いです。

つまり、この大量の通信はルーター自身から発せられていたのでした。

参考までに、ルーターの負荷状況も掲載しておきます。

この記事のタイトルにもある通り、ルーターのログを見たところ一目瞭然。INFOログがNTPで埋め尽くされていました。

(NTP)リフレクション攻撃の手法に関しては、検索すれば非常にわかりやすい解説がたくさんあるかと思いますので、ここでは省略します。

[参考リンク] NTP増幅攻撃で“史上最大規模”を上回るDDoS攻撃発生

当時の状況

私自身、NTPリフレクション攻撃に関しては1月下旬あたりに知っており、各VMやレンタルサーバーのNTPデーモン、FWの確認を行っておりました。

また2月の上旬にも、さくらインターネットからNTP脆弱性に関するメールが来ており、十分にもう一度周囲の機器に関して確認する機会はあったかと思います。

しかしながら、ルーターであるSEIL/x86に関しては全く確認もせず(というよりも頭になかった)、むしろルーターでNTPを起動した記憶すらありませんでした。(ただの言い訳ですね)

対策

対策ですが、 一般的なLinuxサーバーの場合、実際には以下の方法が考えられます。

• NTPサーバーを停止する
• NTPのバージョンアップを行う
• NTPの設定を変更する

NTPサーバーを停止する

そもそもNTPのサーバーとして利用していなければ、サービスを実行させておく必要はありません。

また、外部へ公開し”オープン”であることが必要となるケースもあまり無いように思われます。

NTPサーバー機能が必須でない限り、サービスを停止しておくことをおすすめします。

サービスの停止に必要なコマンドの一例を以下に掲載します。

1
2
3
4

# NTPデーモンを停止する
$ /etc/init.d/ntpd stop
# NTPサービスの自動起動を停止する
$ chkconfig ntpd off

NTPのバージョンアップを行う

非常に大きなレスポンスを返すということで、今回の原因ともなっている、monlistの一部を修正し、DDoS攻撃の影響を低減させたntpd(バージョンは4.2.7p26)が公開されているようです。

可能であれば、アップデートも検討してみてください。

NTPの設定を変更する

もしNTPサーバーを公開する必要がある場合、可能な限りアクセスを制限し、レスポンスを増幅させないことで、攻撃として利用されることを防ぐことができると考えられます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# ntp.confを開く
$ vim /etc/ntp.conf

# ファイルの末尾等に、以下を追記
disable monitor # monlist機能を無効にして、レスポンスの増幅を防ぐ

restrict default ignore # デフォルトで全てのホストとのNTP通信を許可しない
# なお、NTPサーバーとの通信を行いたいIPアドレスを、この後に追加する必要があります
# 例: localhostはアクセス制限をしない
# restrict 127.0.0.1

なお、今回のSEIL/x86の場合、考えられる対策は

• NTPサーバー機能を停止する
• 信頼できないネットワークからのNTPクエリを遮断する
• ファームウェアをアップデートする

以上の3点ではないでしょうか。

[参考リンク] NTPがDDoS攻撃の踏み台として使用される問題のSEILシリーズへの影響について

思ったこと

私は自宅のサーバー群を何かのコンテンツのホスト等ではなく、自らの実験や学習用に使ってきたため、私がホストしているサービス等には影響はありませんでしたが、やはり回線の帯域を圧迫し、リクエストの大量送信による意図しない負荷をかけてしまったことには、本当に反省するしかありません。(運良く攻撃先は無効のアドレスとなっていましたが、それでもその過程で負荷をかけていたことには間違いありません)

今回の件を通して、自分自身も加害者になる可能性があることを痛感しましたし、その原因も設定ミスや確認不足などのちょっとしたことで起こることを(実際に被害を受けてですが)理解することが出来ました。

「興味がある！」「自分にもできるかも！」で高校生の頃から始めたサーバーの運用ですが、その背後にある責任や危険性の大きさを、今頃になって実感した気がします。

昔、とある方が仰ってた「情弱なんだから、普通のブロードバンドルーター使ってレンタルサーバー借りてればいいんだよ！」というお言葉がよく理解出来ました。

家に帰った後は、勉強のため環境を一から再構築するつもりですが、同じ失敗を二度も繰り返さないように、今回のことを念頭において今後の運用を行っていきたいと思っています。