インシデント発見前の注意点：管理者のためのセキュリティ推進室～インシデントレスポンス入門～（6）

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

» 2002年11月27日 10時00分公開

[JPCERT/CC，＠IT]

　前回までで、「事後の対応」である「インシデントレスポンス」の基本を一通り紹介した。今回は最終回ということで、「事前の対応」として一般的に注意すべき点や推奨する設定などをいくつか紹介する。

ポリシーの整理、確認

　まずシステムを設計する前にどのようなセキュリティポリシーに基づいたシステムにするのかを確認する。例えば、おのおののサーバやネットワーク機器に対して以下のような項目を整理しておく。

どのようなサービス（Web、DNS、FTPなど）を提供するのか？
- サービスの提供先はどこか？（アクセスの制限が必要か否か）
- 保守管理上必要なサービスは何か？（syslog、ntp、sshなど）
- ルータなどの場合、どのような種類のパケットの送受信を許可するのか？
管理者はだれか？（パスワードの管理方法など）
保守管理作業はどのようにして行うのか？
- ネットワークを経由して行う場合には、どのホストからだれがログインして行うのか？
- どの作業をどのユーザーの権限で行うのか？

不要なサービスの停止

　上記のポリシーに基づいて決定したサービス以外のサービスを停止する。これにより、保守の必要があるプログラムの数を限ることになり、大幅な管理コストの軽減が期待できる。

　しかし、最近のOSは標準でさまざまなサービスが有効になっていることがある。それに気が付かないまま、使用している覚えのないサーバプログラムが放置され、そしてそのプログラムに深刻な脆弱性が発見されたにもかかわらず、対応をしなかったため、結果として、深刻な被害を受けてしまったという事例が多々見受けられる。

　従ってセットアップする際には、使用しているOSにおいて標準で有効になっているサービスにどのようなものがあるか、またそれらのうち、ポリシーに照らして必要なものと不要なものを整理し、不要なものについては無効になるように設定する。ただしOSによっては、あるサービスを無効にすることでほかのサービスにも影響を及ぼすようなサービスが存在する場合がある。従って無効にするサービスについては、OSのマニュアルなどを参考にし、ほかに影響がないことを十分に確認する必要がある。

アクセスの制限

　通常のWebサービスのように、不特定多数に公開しているサービスについては、サービスに対するアクセスに制限を設けることはない。しかし、特定のユーザーや特定の組織にのみ提供しているサービスや保守管理用のサービスなどについては、一般的に不特定多数からのアクセスは不要である。従ってアクセスできるユーザー、またはホストやネットワークを限ることが推奨される。これにより、遠隔から攻撃可能な脆弱性に対して、不特定多数からの攻撃を防げる場合がある。

※ アクセスを制限しても、アクセスを許可したホストやネットワークからの攻撃に対しては無防備であることに注意してほしい。また、脆弱性の内容によっては、ユーザー認証の処理や許可されていないホストやネットワークからのアクセスを拒絶する処理の前に悪用される場合があるので、アクセスを制限しても、必ずしも攻撃を防げるとは限らないことに注意してほしい。

　アクセスを制限する方法としては、各サーバプログラム自体の機能による方法や、ルータなどのネットワーク機器でのパケットフィルタリングなどの方法がある。例えば、不特定多数のホストやネットワークからのアクセスは許すが、ユーザーだけは制限したい場合には、サーバプログラム自体のユーザー認証機能を用いる方法などがある。また、アクセスを制限する機能を持たないサーバプログラムに対しては、ルータやホストOSに含まれるパケットフィルタリング機能を用いて、アクセスできるホストやネットワークを制限する方法が採られることがある。

※ UNIX系のOSにおいて、inetd経由で起動されるサーバプログラムについてはtcp_wrappersのtcpdで、また同じtcp_wrappersのlibwrapをリンクしているサーバプログラムについては、そのプログラム自体でアクセスを制限することができる。このような tcp_wrappersを用いたアクセス制限は、一般的に/etc/hosts.denyと/etc/hosts.allowで設定する。詳細はhosts_access（5）のマニュアルページを参照してほしい。

　いずれの方法にせよ、どの方法を採用するかについては、サイトの管理運用ポリシーに照らして適切なものを選んでほしい。

内部から外部へのパケットの制限

　一般的に、ファイアウォールでは、外部から内部に入ってくるパケットのみを制限していることが多い。しかし、このような外部からのパケットの制限だけでなく、内部から外部へ向けたパケットの制限が推奨される。これにより、トロイの木馬やワームなどに感染した場合に、自サイトを踏み台にして外部に対して行われる攻撃を防げる場合がある。

　例えば、昨年世界的に大きな被害を生んだCodeRedやNimdaなどのワームはWebサーバに感染し、そこから外部のWebサーバの80/tcpポートにアクセスして、感染を広げる。一般的に、通常の運用においてWebサーバから外部のWebサーバの80/tcpポートにアクセスすることはないはずである。そこであらかじめルータにおいて内部のWebサーバから外部のネットワークに対して80/tcpで出て行くパケットを制限していれば、CodeRedやNimdaによる2次感染は防げたのである。また、トロイの木馬などが外部のホストやネットワークを攻撃したり、攻撃者との間で何らかのデータのやりとりを行う通信は、通常の通信では使用されることのないポート番号が用いられることが多い。従って内部から必要以外のパケットが外部に出て行かないように設定することで、ある程度 2次被害や情報漏えいなどを防ぐことが期待できる。

　各Webサイトにおいては、内部から外部へ出て行くパケットのうち、何が必要で、また何が不要かを十分に検討し、必要最小限に限ることを強くお勧めする。

IP spoofingへの備え

　パケットの送信元アドレスが偽装（spoof）され、外部から送信されたパケットであるにもかかわらず、あたかも自サイト内で送信されたパケットと見なされる場合がある。そのため自サイトのネットワークからのみアクセスを許しているサービスに外部からアクセスされる可能性がある。

　このようなアクセスを防ぐためには、外部との接続口（ゲートウェイ）において、自サイトのアドレスを送信元としているパケットが外部から送信されてきた場合に、そのようなパケットの受信を拒否するように設定する必要がある。

　また、このようなアドレスの偽装（IP spoofing）は、TCP/SYN Flood攻撃のようなサービス運用妨害（DoS）攻撃に使われることが多い。従ってアドレスの偽装については、自サイトがそのような攻撃の踏み台として悪用されないように設定しておくことが求められる。

　そのためには、ゲートウェイにおいて、自サイト以外のアドレスを送信元としているパケットが内部から外部へ送信されないように設定する必要がある。

　アドレスの偽装についての詳細は、以下のRFCの文書を参照してほしい。

Network Ingress Filtering:
Defeating Denial of Service Attacks which employ
IP Source Address Spoofing
http://www.ietf.org/rfc/rfc2827.txt

署名の検証

　現在では、多くのソフトウェアがネットワークを経由して配布されている。そのようなソフトウェアを使用する際に注意すべき点は、それらのソフトウェアが「正しい」ソフトウェアであるかどうか、すなわちトロイの木馬などが組み込まれていないかどうかを確認することである。

※最近、OpenSSHやsendmail、tcpdumpなどのソースパッケージがオリジナルの配布元から、トロイの木馬が組み込まれた状態で配布されていた「事件」があった。詳細については、以下の文書を参照してほしい。

CERT Advisory CA-2002-24
Trojan Horse OpenSSH Distribution
http://www.cert.org/advisories/CA-2002-24.html

CERT Advisory CA-2002-28
Trojan Horse Sendmail Distribution
http://www.cert.org/advisories/CA-2002-28.html

CERT Advisory CA-2002-30
Trojan Horse tcpdump and libpcap Distributions
http://www.cert.org/advisories/CA-2002-30.html

　確認方法として広く一般的に用いられている方法としては、MD5などのチェックサムを用いる方法がある。これについては「第3回インシデントを発見する方法（2）」を参照してほしい。

　MD5などのチェックサムを用いる方法以外には、PGP（またはGnuPG）による電子署名による検証方法がある。以下に簡単に説明する。

※ 上述のOpenSSHやsendmailなどの「事件」も、ソースパッケージに対してMD5やPGPなどで検証を行っていれば、トロイの木馬による被害を防げた可能性は極めて高い。

（1）ソフトウェアパッケージ、その署名ファイル、署名者の公開鍵の取得

　上記3つのファイルはすべて別々のサイトから集めてくることが望ましい。公開鍵については、すでに鍵サーバに登録されている場合が多いので、そこから公開鍵を入手すると便利だろう。

※ 鍵サーバとしては、JPNICによるhttp://pgp.nic.ad.jp/などがある。

　署名者の公開鍵が正しいものであるかについては、注意深く検証する必要がある。署名者の公開鍵が正しいものであるかどうかは、公開鍵のフィンガープリント（指紋）を使い確認する。公開鍵が正しいものであるかどうかのフィンガープリントの情報は事前にインターネット経由以外の方法で入手するものを使うのが望ましい。多くの場合、関係する者の名刺やパンフレットなどに公開鍵のフィンガープリントを載せて配付するなどの運用が多い。

　直接相手に面接し、写真付きの公的な証明書（パスポートなど）で確認した後、フィンガープリントの情報を入手するのが理想だが、このように直接相手からフィンガープリントを入手できない場合は、検証しようとしている公開鍵に対してすでになされている、信頼できる第三者の署名による確認（Web of Trust方式）を用いるとよい。いずれにしろ公開鍵の信用の度合いについては、何らかの判断基準をあらかじめ決めておくことをお勧めする。

　フィンガープリントから署名者の公開鍵を検証するには、別途入手した署名者の公開鍵を自分の鍵束に登録し、以下のようにして登録した鍵のフィンガープリントを表示させ、証明者本人に教えてもらったフィンガープリントと比較し、同一であること確認する。


［pgp 2.6.3iの場合］	pgp -kvc［鍵IDあるいは電子メールアドレスなどのユーザーID］
［pgp 5.xの場合］	pgpk -ll［鍵IDあるいは電子メールアドレスなどのユーザーID］
［GnuPGの場合］	gpg --finger［鍵IDあるいは電子メールアドレスなどのユーザーID］

（2）署名の検証

　署名ファイルは、署名されたファイルのファイル名に.sig、.pgpまたは.ascという拡張子を付けた形で配布されることが多い。例えば、sendmail.8.12.1.tar.sigという署名ファイルはsendmail.8.12.1.tarというファイルに対する署名である。この例の場合、PGP署名の検証はコマンドラインで以下のように実行する。


［pgp 2.6.3iの場合］	pgp sendmail.8.12.1.tar.sig sendmail.8.12.1.tar
［pgp 5.xの場合］	pgpv sendmail.8.12.1.tar.sig sendmail.8.12.1.tar
［GnuPGの場合］	gpg --verify sendmail.8.12.1.tar.sig sendmail.8.12.1.tar

　このように実行することで、「Good signature」や「正しい署名」のようなメッセージが表示されればよい。検証に失敗した場合は、データが署名と対応できず信頼できないものであることを示している。これはデータに対して何らかの改ざんが行われている可能性がある。

　なお、署名ファイルの拡張子が.sigなど、検証に用いるコマンド（pgp、pgpv、gpgなど）が対応している拡張子の場合は、コマンド行の最後に指定した「署名された元のファイル」のファイル名（この例ではsendmail.8.12.1.tar）は省略できる。

　また、署名されたファイルがテキストファイルの場合は、そのテキストファイルに署名が埋め込まれている場合がある。

※ JPCERT/CCが公開しているテキスト形式の文書は、このような形式でPGP署名が行われている。

　このような場合は、コマンド（pgp、pgpv、gpgなど）の引数として、署名入りのテキストファイルだけを指定すればよい。ただし、一般的にPGP署名の検証プログラム（pgp、pgpv、gpgなど）は、日本語の文字コードに対応していないことが多いので、署名した際の文字コードと異なる形式で保存したファイルに対しては、内容の改ざんなどが行われていなくてもPGP署名の検証に失敗する。このような日本語のテキストファイルに対する検証を行う場合には、文字コードに注意してほしい。

※ JPCERT/CCの公開文書に対するPGP署名は、文字コードにiso-2022-jpを用いて作成した文書に対してPGP署名が行われている。

　これまで6回にわたって、「管理者のためのセキュリティ推進室～インシデントレスポンス入門」と題して、インシデントへの対応手順などを紹介してきた。ここであらためて強調するが、「インシデント」は自然災害と同様に、「いつ起こるか分からないが、いつかは起こる」ものだという認識を持っていてほしい。

　「インシデントレスポンス」で重要なことは、万が一インシデントが起こってしまった場合に、その事実にいかに素早く気が付くか、またいかに適切な対応を行って復旧し、再発防止策を講じるか、という点なのである。適切な「インシデントレスポンス」のためには、各組織において、自組織が関係したインシデントに対応するための「セキュリティチーム（CSIRT=Computer Security Incident Response Team）」の存在が望まれる。

　まだセキュリティチームが存在していない組織は、ぜひともセキュリティチームの設置を検討していただきたい。そしてその際に、今回の連載記事が何らかの形でお役に立てば幸いである。（今回で連載は終了いたします。ご愛読ありがとうございました。）

■参考文献

［1］ Network Ingress Filtering:
Defeating Denial of Service Attacks which employ
IP Source Address Spoofing
http://www.ietf.org/rfc/rfc2827.txt

［2］ Using PGP to Verify Digital Signatures
http://www.cert.org/archive/pdf/PGPsigs_paper2.pdf

■コラム～JPCERT/CCに寄せられたインシデント報告～

　最終回の今回は、この一年間（2001/10/1～2002/9/30）にJPCERT/CCに寄せられたインシデント報告について紹介する。

（1）インシデント報告件数の推移

　以下のグラフは、JPCERT/CCが受け取ったインシデント報告件数の推移と、「第2回インシデントを発見する方法（1）」のコラムでも紹介した、インシデントに関係している（と思われる）サイトへの連絡の仲介依頼を受けてJPCERT/CCから通知連絡した件数の推移である。

図1 JPCERT/CCが受け取ったインシデント報告件数と通知連絡した件数

　このように毎月90件程度の通知連絡を国内外のサイトに対して行っている。

（2）インシデントタイプ別分類

　以下の円グラフはJPCERT/CCが受け取ったインシデント報告を、「第1回インシデントレスポンスとは？」で紹介した種類に分類した結果である。

図1 JPCERT/CCが受け取ったインシデント報告の分類

　このように、JPCERT/CCが受け取るインシデント報告の約8割が実害のほとんどないスキャンやプローブなどの弱点探索もしくは「未遂」に終ったインシデントである。

　しかしここで注意しなくてはいけないのは、この「約8割」のうちの多くが海外からの報告で、しかもその内容が「日本のアドレスブロックから不審なアクセスがあるので、そのアクセス元（と思われる）サイトの管理者に日本語で連絡してほしい」という連絡の仲介依頼であるという点である。このような依頼に基づいてJPCERT/CCから日本のサイトに通知連絡することで、連絡を受けた日本のサイトの管理者が、侵入などの深刻なインシデントの結果として自サイトが踏み台として悪用されていることに気が付き、対応が行われるケースが多々ある。

　つまり、分類としてはスキャンやプローブというあまり深刻ではないインシデントであっても、この種類のインシデント報告は、より深刻なインシデントが（日本のサイトで）発生していることを潜在的に示している可能性があるのである。

　このような「より深刻かつ潜在的なインシデント」については、詳細な報告をいただけることが極めて少ないため、JPCERT/CCの統計データにはほとんど反映されていない。今後JPCERT/CCの統計データを見る場合には、このような「潜在的なインシデント」の可能性も念頭に置いていただきたい。

　なお、JPCERT/CCが受け取ったインシデント報告については、四半期ごとに「活動概要」としてJPCERT/CCのWebサイトhttp://www.jpcert.or.jp/において公開しているので参考にしてほしい。

Profile

JPCERT/CC

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