サービス名はIANAの情報をもとに記載していますが、必ずしも各サービスプロトコルに則ったパケットが受信されているとは限りません。図1は、期間中のトップ5の宛先ポート番号ごとのパケット観測数の推移を示しています。6図2に期間中のトップ5のパケット送信元地域からのパケット観測数の推移を示します。[図2:2015年4~6月の送信元地域別トップ5ごとのパケット観測数]クリックすると拡大されますTelnetサーバを搭載したネットワーク機器を対象とする探索活動については、過去の定点観測レポートでも紹介しましたが、本四半期も5月7日頃から23/TCP宛のパケット数が再び増加しました。言及した445/TCP宛のパケットが3月中旬から5月中旬にかけて増加した結果、2位に位置しています。そのほか、4月中旬から8888/TCP宛のパケットが増加しています。この増加の原因は、オープンプロキシサーバの探索活動の影響と思われ、2.1で詳しく取りあげます。本四半期は、4月上旬から5月中旬にかけて8888/TCP、37564/TCPなど複数のポート番号へのパケットが増加しました(図3)。8888/TCP宛のパケットは、通期で第1位の23/TCP宛のパケットよりも多く観される日(or週)が約6週間に渡って続いたほど増えたため、13位から3位にランクインしました。[図3:2015年4月~6月の8888/TCP、37564/TCP宛てのパケット観測数]クリックすると拡大されますこれらのポート番号宛の多量のパケットの発信目的を考察した時に最初に思い起こされるのが、オープンプロキシサーバのリストとして、IPアドレスとポート番号を掲載している海外の複数のWebサイトの存在です。これまでのTSUBAMEの過去の観測では、何度となく通常サービスに使用されていないポート番号に対するパケットが急増するという事象がありました。今回、宛先ポート番号が8888/TCPや37564/TCPのパケットと同じ送信元IPアドレスをもつパケットを探してみると、従来から知られているオープンプロキシサーバのポート番号宛のパケットが見つかるケースがあります。対応するオープンプロキシサーバのリストを調べると、8888/TCPなどのポート番号の情報が新たにリストに追加されていて、このことからオープンプロキシサーバの探索を目的としたパケットであったことが高い確度で推測されます。これらのポート番号を標準的に用いるメジャーなプロキシサーバ―ソフトは知られておらず、何らかのパッケージ・ソフトウェア製品が内部的に稼働させているプロキシ―サーバが、不適切なネットワーク・アクセス制御のために、インターネットに露出していることが疑われます。いずれにせよ、こうしたポート番号に気づいたオープンプロキシサーバのリストの管理者が、探索ポートとして追加したことが、この種のパケットの観測数が一時的に増えた原因であろうと推測しています。[図4:2015年4月~6月の53413/UDP宛てのパケット観測数]クリックすると拡大されますこのポート番号は、日本で広く利用されている製品ではほとんど使用されていません。この問題は、9月5日までに製品ベンダがフォームウエアを更新し、解消されました。6月中旬に増加したパケットは、この脆弱性を悪用してBotに当該製品を感染させるものだったことがJPCERT/CCの調査で分かりました。その手口は、次のとおりです。細工した53413/UDPパケットを当該ルータに送り込んで、ルータ上に用意されたコマンドを用いて、インターネット上の外部サイトサーバからスクリプトファイルをダウンロードさせ、実行権限を書き換えてから実行させることで当該ルータをBot化させるこの手口に対応した一連の攻撃パケットの増加が観測された期間が、脆弱性情報や修正パッチが公表された2014年9月以降も数回ありました。パッチの適用が進まない中で、新たにBot化する機器が今後も増え続け、DDoS攻撃がさらに深刻化する恐れがあります。して実施したものです。広報(office@jpcert.or.jp)まで確認のご連絡をお願いします。最新情報についてはJPCERT/CCのWebサイトをご参照ください。いいえその他、ご意見・ご感想などございましたら、ご記入ください。こちらはご意見・ご感想用のフォームです。各社製品については、各社へお問い合わせください。※本フォームにいただいたコメントへの返信はできません。javascriptを有効にすると、ご回答いただけます。ありがとうございました。