本当に見つけたいポートスキャン行為とは?
皆さんこんにちは、川口です。先日知人と会ったときに、バブル絶頂期のファッションに身を包んでいた知人の20年前の写真が出てきました。「いまでもたまにこういうバブルの名残のある人っているよね」と話題になり、大盛り上がりでした。
そしてファッションと同様、セキュリティの動向にも時代の波があります。セキュリティの考え方が時代に取り残されていると無駄なコストを払うことになります。私がたまに見掛ける時代遅れな考え方とは、「ポートスキャンは攻撃の予兆であり、ポートスキャンをされたことを見つけたら、これに対処するべきである」というものです。私は「セキュリティを専門にする人以外は、インターネットから行われるポートスキャンを見つけることはほとんどセキュリティの役に立たない、ましてや予兆として対処することも非常に難しい」と考えています。
【注】
ここではポートスキャンを特定のホストやサービスが稼働しているために攻撃者が行う調査行為のことを指します。
攻撃者はポートスキャンで何を狙うのか
ポートスキャンの対策を考えるには、攻撃者がどのような流れでポートスキャンを実行するのかを理解する必要があります。
- ポートスキャン 〜攻撃対象ホストの選定〜
攻撃対象とするホストを選定するために、稼働しているホストを調査する目的でポートスキャンを実行します。 - ポートスキャン 〜攻撃対象サービスの選定〜
攻撃対象のホストで稼働しているサービスを調査するためにポートスキャンを実行します。1.と2.はまとめて行われることもあります。 - バージョン調査&脆弱性調査
攻撃対象のホストで稼働しているサービスの脆弱性を調査するために、稼働サービスのバージョン情報や脆弱性を調査します。このフェイズからはポートスキャンと区別されることが多いですが、ポートスキャンツールによっては自動的に調査を行うものもあります。 - 攻撃
攻撃対象のサービスの脆弱性を悪用する攻撃を実行します。
多くの書籍やホームページで、このような流れで攻撃が行われると解説しています。そのため、攻撃の予兆としてポートスキャンが実行されたのを見つけたいと考える原因になっているのではと考えています。しかし、ポートスキャンを予兆としてとらえ、対処するのは困難だと私は考えています。
現在のポートスキャン事情
私が「ポートスキャンを攻撃の予兆として対処することが難しい」と考える理由は以下の3つの点です。
- a. ポートスキャンであると判断する基準が難しい
- b. ポートスキャンと攻撃が別のIPアドレスから行われると予兆としてとらえられない
- c. ポートスキャン行為があまりに多く、対処しきれない
まず、ポートスキャンであると判断する基準は大変難しいという事実について解説しましょう。IDS/IPSでは単位時間当たりの通信数のしきい値を設けており、そのしきい値を上回った場合にアラートを出力します。このしきい値の設定によっては、正常な通信でもアラートが出力されてしまいます。システムに対するすべての通信をポートスキャンと定義すると過剰にアラートが出力され、c.の問題につながります。逆にしきい値を高く設定してしまうことで、そのしきい値以下のポートスキャン行為を発見できなくなります。
それでも2003年以前はポートスキャンを予兆として対処することも可能だったかもしれません。私の体感としては2003年のBlasterワーム登場以降、ポートスキャンの数が増加しており、予兆として対処できる数ではなくなっています。
現在ではインターネットからのポートスキャン行為は日常的に行われているため、インターネットから自組織に対して行われるポートスキャン行為は無視してもよいでしょう。ファイアウォール/IDS/IPSのチューニングを行う際には、インターネットからのポートスキャンをフィルタすることで、ログの件数を大幅に削減できます。その結果、ログ管理コストを下げることができます。
要注意なのは「社内からのポートスキャン」
しかし、すべてのポートスキャン行為を無視していいわけではありません。社内LAN(イントラネット)から行われるポートスキャンには要注意です。攻撃者によって侵入されている場合やボットなどに感染している可能性があるからです。
攻撃者やボットは社内LAN内でさらに侵入や感染を広げる場合に、脆弱性を持ったPCを探します。この脆弱性を持ったPCを探すために、特定のポートに対してポートスキャンを実行します。Windows PCを攻撃する場合には、ファイル共有などで利用される139/tcpや445/tcpに対して、ポートスキャンが実行されています。
セキュリティアナリストがお客さまのネットワークで不審なポートスキャンを発見し、連絡したところ、送信元のPCがボットに感染していた事例は多数あります。そのため、われわれは社内LANからのポートスキャン行為には常に目を光らせています。
しかし、以下のような事象は日常的に発生する可能性が高く、慌てずに確認する必要があります。
- インターネットアクセス用のプロキシサーバからインターネットのホームページへの多数のアクセスが80/tcpへのポートスキャンとして記録される
- 外部配信用のメールサーバからの大量のメールの配信が25/tcpへのポートスキャンとして記録される
- 社内の端末管理用サーバから、社内LANに存在するPC、サーバを調査するための通信がポートスキャンとして記録される
これらのような事象を把握することもセキュリティアナリストにとって重要な勉強です。
そんな中でセキュリティアナリストを悩ませるのはマイナーなアプリケーションの存在です。普段利用しないアプリケーションの脆弱性を狙ったポートスキャンが行われる場合には出勤しているセキュリティアナリスト全員で会議という名の議論が巻き起こります。
「○○○のアプリケーションの脆弱性があるという情報が出ています」
「そのアプリケーションは聞いたことがない」
「そのアプリケーションって何?」
「公式サイトはどこ?」
「そのアプリケーションはどこで手に入る?」
「どうやって攻撃するんだ?」
「誰か攻撃ツール試した?」
「どこのポートに攻撃が行われるのか?」
「あ、先日のポートスキャンは実はこの脆弱性を狙ったものかもしれない」
……などなど。脆弱性情報が公開される前に、その脆弱性を悪用する攻撃が行われている場合もあり、脆弱性公開後にポートスキャンの狙いが分かることもあります。
余談ですが、私の印象に残っているのはDameWareというリモート管理用アプリケーションの脆弱性です。脆弱性に関する情報が出て、初めてこのアプリケーションの存在を知りました。使ったことがあるセキュリティアナリストが誰もいなかったため、公式サイトの情報を探し、アプリケーションをインストールして調査したときの苦労を覚えています。このアプリケーションは6129/tcpで稼働するらしく、脆弱性情報が公開された後から6129/tcpのポートスキャンが増えました。幸いだったのは日本ではマイナーなアプリケーションだったので、日本のわれわれのお客さまが被害を受ける確率は低いことでした。
ポートスキャン行為は攻撃や感染の前兆であることには間違いありません。特に社内LANから行われるポートスキャンには注意しましょう。
われわれセキュリティアナリストはどのような通信が不正で、どのような通信が正常かを判断するため、セキュリティ以外の情報も収集しています。私は今日も情報収集のため、社内のメンバーと飲みに行くのでした。
Profile
川口 洋(かわぐち ひろし)
株式会社ラック
JSOCチーフエバンジェリスト兼セキュリティアナリスト
ラック入社後、IDSやファイアウォールなどの運用・管理業務を経て、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。
アナリストリーダとして、セキュリティイベントの分析とともに、IDS/IPSに適用するJSOCオリジナルシグネチャ(JSIG)の作成、チューニングを実施し、監視サービスの技術面のコントロールを行う。
現在、JSOCチーフエバンジェリスト兼セキュリティアナリストとして、JSOC全体の技術面をコントロールし、監視報告会、セミナー講師など対外的な活動も行う。
- 「DNS通信」記録していますか?――万一に備えたDNSクエリログの保存方法
- Web広告からのマルウエア感染「Malvertising」にどう対処すべきか
- 中の人が振り返る「Hardening 10 ValueChain」――学びにつながった「トラブルの数々」とは
- 無慈悲な専門家チーム「kuromame6」の暗躍に負けず勝利をつかんだチームは?
- 外部リソースの活用もポイントに、「Hardening 10 MarketPlace」開催
- Hardening Projectから派生した「MINI Hardening Project」に行ってみた!
- 「これさえしておけば助かったのに……」を避けるため、今すぐ確認すべき7項目
- アップデート機能を悪用した攻撃に対抗セヨ!
- 工夫、工夫そして工夫――Hardening 10 APAC“運営”レポート
- ウイルスとは言い切れない“悪意のあるソフトウェア”
- 2013年のセキュリティインシデントを振り返る
- ここが変だよ、そのWeb改ざん対応
- きっかけは不正侵入――私がセキュリティ業界に足を踏み入れたワケ
- CMSが狙われる3つの理由
- FacebookやApple、MSまで……Javaの脆弱性を狙う攻撃の手口
- Hardening One、8時間に渡る戦いの結果は?
- そのときStarBEDが動いた――「Hardening One」の夜明け前
- ロシアでわしも考えた
- 実録、「Hardening Zero」の舞台裏
- ちょっと変わったSQLインジェクション
- 官民連携の情報共有を真面目に考える
- アプリケーションサーバの脆弱性にご注意を
- IPv6、6つの悩み事
- スパムが吹けば薬局がもうかる
- JSOCに飛び込んできた不審なメール――これが標的型攻撃の実態だ
- 東日本大震災、そのときJSOCは
- ペニーオークションのセキュリティを斬る
- 2010年、5つの思い出――Gumblarからキャンプまで
- 9・18事件にみる7つの誤解
- 曇りのち晴れとなるか? クラウド環境のセキュリティ
- Webを見るだけで――ここまできたiPhoneの脅威
- 不安が残る、アドビの「脆弱性直しました」
- ともだち373人できるかな――インターネットメッセンジャーセキュリティ定点観測
- 実録・4大データベースへの直接攻撃
- Gumblar、いま注目すべきは名前ではなく“事象”
- Gumblarがあぶり出す 「空虚なセキュリティ対策」
- 新春早々の「Gumblar一問一答」
- 実はBlasterやNetsky並み?静かにはびこる“Gumblar”
- ECサイトソフトウェアはなぜ更新されないのか
- 狙われるphpMyAdmin、攻撃のきっかけは?
- 学生の未来に期待する夏
- 米韓へのDoS攻撃に見る、検知と防御の考え方
- 分かっちゃいるけど難しい、アカウント情報盗用ボット対策
- 狙われる甘〜いTomcat
- 表裏一体、あっちのリアルとこっちのサイバー
- 世間の認識と脅威レベルのギャップ――XSSは本当に危ないか?
- 急増したSQLインジェクション、McColo遮断の影響は
- ○×表の真実:「検知できる」ってどういうこと?
- ところで、パッケージアプリのセキュリティは?
- レッツ、登壇――アウトプットのひとつのかたち
Copyright © ITmedia, Inc. All Rights Reserved.