インシデント発見後の関係サイトへの連絡：管理者のためのセキュリティ推進室〜インシデントレスポンス入門〜（5）

本記事では、セキュリティ関連の非営利団体JPCERT/CCが、基本的におさえておくべきセキュリティ技術やコンピュータセキュリティ・インシデント（不正アクセス）に関する情報を紹介する。（編集局）

[JPCERT/CC，＠IT]

　「第4回 インシデント発見時の対応手順」で紹介したように、インシデント発見後の対応の際には、インシデントに関係している可能性のあるサイト（例えばアクセス元）に必要な情報を提供し、協力して解決に取り組めないかどうかを検討することが望まれる。これによりインシデントの原因を詳細に確認することができたり、再発防止策を講じるうえで有益な情報を得られる可能性がある。またアクセス元が踏み台に使われている場合などは、そのサイトの管理者に連絡することで、インシデントの発生に気付き、被害の拡大を防ぐための対策を施してもらえる可能性がある。しかしこのような情報提供にはリスクも伴うため、注意が必要である。

　今回は、このようなインシデントに関係している可能性のあるサイトへ連絡する目的や伴うリスク、その回避策などの注意点を紹介する。

連絡の目的

（1） 事実関係の確認 （調査依頼）

　不審なアクセスが、必ずしも悪意のあるアクセスとは限らないことに注意してほしい。プログラムのバグや設定ミス、または単なる操作ミスである可能性がある。またアクセス元が、ワームに感染していたり、分散型サービス運用妨害（DDoS）攻撃用のツール（Agent）をインストールされ「踏み台」として悪用されている可能性などもある。

　まずアクセス元に連絡する場合には、何が起こっているのかを調べてもらい、事実関係を確認することが大切である。

（2） 被害の拡大防止

　関係サイトの管理者に注意を喚起することは、インシデントの解決や拡大防止につながる。例えば、外部からのアクセスを含むインシデントの場合は、一般的な解決策として、アクセス元のシステムにおける原因の特定と再発の防止が必要である。特に、アクセス元のシステム自体が第三者によって悪用されていた場合には、それを放置すると、自サイトへのアクセスが継続する可能性があり、またさらにほかのサイトへインシデントの被害が拡大する可能性もある。積極的に問題の所在と状況を伝え、先方に調査と対応を促すことが、インシデントの速やかな解決や拡大防止につながるのである。

　一方で、自サイトのシステムが外部への攻撃に悪用されていた場合には、自サイトにおいて対策を実施した後も、引き続き、その外部のサイトへの攻撃が（第三のサイトを介して）行われる可能性がある。この場合には、その外部のサイトに対して攻撃の事実を伝え、先方の対応や対策を促すことが求められる。

　インシデントを放置しておくことは、将来いずれかのサイトのシステムが踏み台として悪用され、自サイトや自サイトと関係のあるサイトへの攻撃につながる可能性がある。インターネット全体の円滑な運用のためにも、各関係サイトと適切な情報交換を行い、協力してインシデントの解決を図ることが望まれる。

（3） 原因の究明

　インシデントの内容によっては、自サイトだけではその発生原因が分からない場合がある。特にシステムへの侵入をほう助するツールrootkit（「第3回 インシデントを発見する方法（2）」参照）などにより巧妙に改ざんの痕跡が隠ぺいされてしまっている場合には、どのような脆弱性が悪用されたのかを知ることは極めて困難である。しかしアクセス元などとの情報交換により、自サイトには残っていなかった情報が手に入る可能性もある。また、未知の脆弱性が悪用されたことが判明した場合は、対象となるソフトウェアの開発元などに連絡することで、問題を解決するためのソフトウェアの改善に寄与できる場合もある。

連絡に伴うリスク

　典型的なリスクの例を以下に紹介する。

（1） 盗聴、改ざん、妨害

　特に連絡先や通信経路が侵入などによる影響を受けている場合は注意が必要である。

（2） 情報の漏えい、悪用

　連絡先に伝えた情報がこちらが期待しているように取り扱われるとは限らないことに注意する必要がある。第三者に自サイトの情報が漏えいし、ほかのサイトへの攻撃の参考情報などに悪用される可能性は否定できない。特に自サイトが攻撃によって何らかの被害を受けている場合や、ほかのサイトへの攻撃の踏み台にされている場合には、その事実を悪用される危険性が高くなる。

（3） 事実関係の誤認

　ログなどに含まれるアクセス元の情報が侵入などにより改ざんされていたり、アクセス元のIPアドレスやDNS情報が偽造されることにより、一見アクセス元と思われるサイトが実際にはアクセスにまったく関与していない可能性がある。またアクセス元サイトがワームの感染などのために、攻撃の踏み台として悪用されている可能性もある。

　このような場合は、アクセス元へ連絡することで、かえってインシデントの解決が阻害されるばかりでなく、先方との間の紛争を招く恐れがある。

（4） 連絡先の不在、誤認

　連絡先が必ずしもインシデントに対応する担当者とは限らないことに注意する必要がある。例えば、連絡先サイトとなっているところが接続しているプロバイダや連絡先サイトの業務を請け負っている業者である可能性がある。また退職などにより担当者がすでに先方のサイトから去っており、連絡内容をだれも閲覧しない状態になっている可能性もある。

　このような場合には、対応の遅延ばかりでなく、情報の握りつぶしや漏えい、改ざんを招く可能性がある。

（5） 欺まん情報

　外部からインシデント情報が提供された場合、悪意に基づく欺まん情報である可能性がある。逆に、こちらから提供した情報が、そのような悪意に基づくものであると受け取られる恐れもある。

リスクの回避策

（1） 複数の連絡手段の併用

　一般的に連絡手段としては電子メールを用いるが、侵入などにより、データの改ざんや盗聴などの危険性が考えられる場合にはFAXなどのほかの方法も併用する。これにより、改ざんなどの影響をある程度回避できる。

（2） 複数の連絡先への連絡

　単一の連絡先では、その連絡先が不在であったり、適切な連絡先でなかった場合に対応の遅延などを招く可能性があるが、複数のあて先に連絡することで、そのようなリスクを軽減できる。その一方、情報の漏えいという点でのリスクは増加する。また、複数の受信者のうちのだれが扱うべきかが不明瞭になり、かえって先方の対応を遅らせてしまう可能性があることにも注意が必要である。

（3） 暗号技術の利用

　盗聴や改ざんを防ぐ方法として、（信頼できる鍵が利用可能な場合は）暗号や電子署名を使う方法がある。

※ただし、鍵の交換には十分に注意してほしい。

（4） 情報開示の内容

　情報管理ポリシーに従って内容や範囲、方法を判断する。連絡内容の悪用を回避するためには、第一報においては最小限の情報だけを開示し、先方の反応を見てその後の情報の開示を検討する。

（5） 表現

　状況については、可能な限り断定的ないい回しを避け、可能性としての指摘にとどめるべきである。また第一報では、事実関係の確認と注意の喚起を中心とし、そのほかの要望は、相手からの返事を待ち、事実であることが明らかになった場合にのみ伝える。

（6） CSIRTへの連絡

　自サイトもしくは連絡先サイトのいずれかを対象としたサービスを行っているCSIRT（Computer Security Incident Response Team：「コンピュータセキュリティ・インシデント」に対応する活動を行う組織体の一般名称）に連絡し、あらかじめ助言を受けてもよい。また、電子メールで連絡を行う場合には、CSIRTの連絡先をCc:に含めるといった方法もある。

　一般に、CSIRTは事実の分析やインシデントへの対応全般について、ノウハウや知識を有しているので、CSIRTへ連絡することで事実関係の誤認によって生じるリスクがある程度軽減される。また、自サイトが特にCSIRTの支援を必要としていなくとも、先方にとってCSIRTからの助言が有益である可能性もある。

（7） CSIRTを介した連絡

　連絡先サイトに直接連絡を行う代わりに、CSIRTに連絡を仲介してもらう方法がある。

　一般に、CSIRTは情報提供者の希望しない情報開示を行わないように配慮し、必要に応じて情報のフィルタリングを行うので、連絡内容に関するリスクをある程度回避することができる。また、CSIRTはサイトへの連絡方法についてのノウハウや知識を有しているので、CSIRTに連絡を代行してもらうことで事実関係の誤認によって生じるリスクがある程度軽減される。

　この場合には、CSIRTに対しては必要な情報を開示し、同時にCSIRTから連絡先に連絡する際の情報の開示条件を明示する。例えば、CSIRTに送付したログ情報をそのまま連絡先に送付してよい、または自サイトのIPアドレスの情報だけを隠してほしいなどといった条件である。

（8） ポリシーの策定と順守

　想定するインシデントの内容や影響の程度ごとに、標準的な対応を事前に検討し、ポリシーとしてまとめておく。

※インシデントの種類については、「第4回 インシデント発見時の対応手順」のコラムを参照してほしい。

連絡先の決定

（1） サイトへ直接連絡する場合

　一般には以下のような連絡先が考えられる。

（a） インターネットレジストリなどに登録されている連絡先

　JPNICやAPNICなどのインターネットレジストリが公開しているwhoisデータベースを用いて、連絡先を調べる。

　日本国内で割り当てられたIPアドレスであればJPNICのwhoisデータベースを使って検索できる（http://www.nic.ad.jp/ja/whois/）。

　それ以外のIPアドレスについては、ARIN（http://www.arin.net/）、RIPE NCC（http://www.ripe.net/）、APNIC（http://www.apnic.net/）から情報を入手することができる。

　また、.jpドメインについての情報は、JPRSの提供するwhoisデータベースサービスを使って調べることができる（http://whois.jprs.jp/）。

　そのほかの国名コードトップレベルドメイン（ccTLD）については、IANAが提供するインデックスを利用して各ccTLDを管理する機関を調べ、そのうえで各ccTLD管理機関が提供する検索手段を用いて、該当するドメインの連絡先を検索する（http://www.iana.org/cctld/cctld-whois.htm）。

　EDU、NET、ORG、COM などの各一般トップレベルドメイン（gTLD）については、InterNICから情報を入手することができる（http://www.internic.net/whois.html）。

※上記のデータベースの情報が更新されていないために、連絡が届かなかったり、意図しないあて先に連絡が届いてしまう場合があるので、第一報の連絡の内容には十分に注意する必要がある。

（b） ホストまたはドメインを管理するポストマスタ （postmaster@〜）

　インターネット標準に準拠したメール配送システムを運用しているホストに対しては、postmaster@〜あてのメールは到達可能であると期待できるが、必ずしも管理者が当該アドレスへの着信を確認しているとは限らないことに注意する必要がある。

（c） RFC 2142 で紹介されているメールアドレス （abuse@〜, noc@〜, security@〜など）

　MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS（http://www.ietf.org/rfc/rfc2142.txt）

　必ずしもすべてのサイトがRFC 2142に準拠したアドレスを設定しているとは限らないことに注意する必要がある。しかし、これらのアドレスが設定されているサイトについては、担当者が割り当てられ、一定以上の頻度でメールボックスが参照されることがある程度期待できる。

（d） ホストの管理用アカウント（root@〜、Administrator@〜など）

　このようなアカウントあてに届くメールについては、適切な配慮（設定）がなされていない可能性がある。つまり、メールが到達可能であっても、必ずしも管理者がこれらのアドレスへの着信を確認しているとは限らないことに注意する必要がある。

（e） DNSのSOAレコードに登録されたメールアドレス

　登録されているメールアドレスが、連絡先サイトに属していない、またはメールボックスが参照されていないことが考えられるため、注意が必要である。特に逆引き用のゾーンにおけるSOAレコードの場合には、上流のISPなど、連絡先サイトと直接は関係しないアドレスが記載されている場合も多々ある。

（2） CSIRTに連絡する場合

　自サイトもしくは連絡先サイトのいずれかを対象としたサービスを行っているCSIRTが存在する場合は、そのCSIRTに連絡してもよい。世界各地のCSIRTについては、以下のURLで示される情報を利用してほしい（http://www.first.org/team-info/）。

※上記情報を提供しているFIRSTについては第3回のコラムを参照。

　一般に、各CSIRTはおのおの独自のサービス内容や対応ポリシー、報告フォームを採用している。連絡の際には、事前に各組織のWebなどで公開されている情報を確認する。

　特に、日本国内の組織が関係するインシデントについては、ぜひJPCERT/CCに連絡してほしい。

※JPCERT/CCへの連絡方法については以下のURLを参照。JPCERT/CCへの連絡方法（http://www.jpcert.or.jp/form/）

連絡すべき内容

　以下で示す内容のうち、秘匿すべき情報が含まれている場合には、伏せ字や抜粋などにより、関係サイトに開示しても差し支えない部分のみを提供する。

（1） アクセスの事実を調査するための情報

　最低限、以下の情報を含めるべきであろう。

• アクセスの内容（プロトコル、ポート番号、パケットの内容など）
• 発生した日時（タイムゾーン、正確な時刻からのずれなど）
• 関係するホストのIPアドレス（ホスト名）

　また可能であれば、アクセスの事実が記載されたログを添付することが推奨される。またログは特定のアプリケーションに依存しない、テキスト形式に変換したものがよい。日時については、タイムゾーンの情報だけでなく、正確な時刻からのずれがどれくらいあるのかについても伝える。もしNTPを使って時刻を合わせている場合には、その旨を伝える。

（2） 連絡を円滑に進めるための情報

　自サイトの連絡先や担当者を明記する。またほかのサイトやCSIRTにも連絡する場合は、（差し支えがなければ）それらの情報を伝える、もしくは電子メールでの連絡であれば、Cc:にそれら組織の連絡先を加える。

　レジストリなどが公開されている情報から連絡先を決定した場合は、その情報源を説明してもよいであろう。

　また組織によっては、こちらからの連絡に対して、レポートを追跡するための番号（チケット番号：JPCERT/CCの場合は“JPCERT#nnnnnnnn”形式の番号）が発行される場合がある。すでに連絡した組織（CSIRTやサポートセンターなど）から追跡番号が発行されている場合には、その番号を添える。

---

　今回で「事後の対応」である「インシデントレスポンス」の基本をひととおり紹介した。次回は、「事前の対応」として、一般的に注意すべき点を紹介する。

■参考文献

[1] 技術メモ――関係サイトとの情報交換
（http://www.jpcert.or.jp/ed/2002/ed020001.txt）

[2] Finding Site Contacts
（http://www.cert.org/tech_tips/finding_site_contacts.html）

■コラム 〜地域CSIRT〜

　「第3回 インシデントを発見する方法（2）」のコラムで、APSIRC（Asia Pacific Security Incident Response Coordination）というアジア太平洋地域のCSIRTのフォーラムを紹介したが、このような地域に根ざしたCSIRTの集まりとして、ヨーロッパのTF-CSIRTというものが存在する。今回はTF-CSIRTの活動について紹介する。

TF-CSIRT- CSIRTCoordination for Europe（http://www.terena.nl/tech/task-forces/tf-CSIRT/）

（1）背景

　TF-CSIRTは、ヨーロッパの研究グループTERENA（Trans-European-Research and Education Networking Association）の1タスクフォースとして、2000年5月15日にスタートした（http://www.terena.nl/）。

（2）目的

　大きく分けて以下の 5つを目的としている。

1. ノウハウや知識の交換をするためのフォーラム作り
2. ヨーロッパのCSIRTコミュニティに対する試験的なサービスの提供
3. セキュリティインシデントへの対応の共通の基準や手順の普及促進
4. 新しいCSIRTの構築支援とCSIRTのスタッフに対するトレーニング
5. ほかの関連組織との連携

（3）活動

　代表的な活動をいくつか紹介する。

1. Incident Object Descritption and Exchange Format（IODEF）の標準化
   
   インシデント関連情報の交換などに用いるフォーマット。RFC化を目指しており、インシデント報告様式などへの応用が期待される。
   
   
2. Trusted Introducer
   
   フォーラムに参加するにあたって、既存メンバーによる推薦（紹介）が必要となる。その際の「信頼性」に対して一定の基準を定めた。Level 0からLevel 2までの3段階に分けられる。
   
   Trusted Introducer for CSIRTs in Europe（http://www.ti.terena.nl/）
   
   
3. Face-to-face meeting
   
   年に 3回のミーティングを実施している。

（4）APSIRCとの比較および関係

　アジア太平洋地域のフォーラムであるAPSIRCと、ヨーロッパのTF-CSIRTは、どちらも目指すものにはほとんど隔たりがない。しかし大きな違いは、ヨーロッパには既にEUという明確な枠組みが存在しているのに対し、アジア太平洋地域では、そもそもどこを「アジア太平洋地域」と定義するかといった基本的な問題ですら、いまだに整理されていない状態であるという点である。

　従ってAPSIRCという本格的に活動を始めたばかりのフォーラムにとって、TF-CSIRTには大いに参考になる部分があるものの、TF-CSIRTの枠組みをそのままアジア太平洋地域に当てはめるのは適当ではないであろう。アジア太平洋地域にはアジア太平洋地域にあった枠組みを検討する必要がある。しかしながら、すでにAPSIRCとTF-CSIRTの間でコミュニケーションは取れており、今後の協力関係が期待される。

Profile

JPCERT/CC

JPCERT/CCとは、Japan Computer Emergency Response Team/Coordination Center（コンピュータ緊急対応センター）の略称。非営利団体で、特定の政府機関や企業からは独立し、中立の組織として活動している。JPCERT/CCは、インターネットを介して発生する、侵入やサービス妨害などのコンピュータセキュリティインシデントについて、日本国内のサイトに関する報告の受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討と助言などを、技術的な立場から行っている。FIRSTに日本で最初に加盟したCSIRT。