セキュリティに関するご質問 ‐ 2001 年 4 月
Joel Scambray
忠実なセキュリティ支持者の皆さん、セキュリティ コラムにようこそ。今月はマイクロソフト製品のセキュリティに関する質問にお答えします。私の 1 月のコラムが予期せぬ遅れのあとでやっとオンライン状態になった関係上、今月は 2 倍の量の題材を提供します。この中には、私が AUAS メールボックスで何度も見かけた熱心な質問が多く含まれています。具体的には、同じフォレスト内のドメイン全域にわたるセキュリティ、ファイアウォールでの DCOM の使い方、Win32R SSH サーバー製品の更新に関係することなどです。
いつものように、セッションを開始する前に皆さんには、AUAS の前回号の後に発生した関連のある事件に注目していただきます。VeriSign, Inc. は、マイクロソフトの従業員であると不正に名乗った個人に、2 つのコード署名デジタル証明書を発行してしまったようです (マイクロソフト セキュリティ情報 MS01-017 を参照)。これらの証明書を有する個人は、証明書を使用して、悪質なコードに署名し、それをインターネットを介して配布する可能性があります。疑うことを知らないユーザーはこれに騙されてしまい、ソフトウェアはマイクロソフトによって署名されたものと考え、そのソフトウェアを実行するかも知れません。1 つのシナリオとしては、本物のマイクロソフト コードになりすました有害ウィルスの配布が考えられます。
パッチと対応策については、セキュリティ情報を参照してください。Internet Explorer (IE) を使用している方に対して私が常に推奨していることは、[コントロール パネル] の [インターネット オプション]、[詳細設定] タブの順に開き、[セキュリティ] セクションで、[発行元証明の取り消しを確認する] と [サーバー証明の取り消しを確認する] のすぐ横にあるチェック ボックスをオンにすることです。主要なベンダによって発行される大部分の証明書は、現在のところ、取り消し確認をサポートしていませんが、取り消し確認がサポートされたときには、少なくともあなたは準備ができています。
一方、すべての人が、署名されたコードの実行を確認するために表示されるダイアログ ボックスに少し余分に注意を払う必要があります。このような事件が発生して初めて、現在の公開暗号化インフラストラクチャが壊れやすい状態にあることに気付くというのは恥ずかしいことです。しかし、警鐘を鳴らすべき時機はもう既に来ているようです。
トピック
.gif "最新のカンファレンス情報"){kind=icon}
最新のカンファレンス情報
最新のカンファレンス情報
質問に答える前にもう 1 つお話することがあります。MIS Training Institute (MISTI) は、2001 年 5 月 1 ～ 3 日の 3 日間、米国、テキサス州のダラスにおいて、Conference and Expo on Windows 2000 Security and Control を開催します。このカンファレンスには、セキュリティ分野で有名な方が何名か参加します。たとえば、Microsoft Corporation Corporate Security Office の Howard Schmidt が基調演説を行います。マイクロソフトの Senior Security Technologist である David LeBlanc は「ハッカーに強い Web サイト」というテーマでセッションを担当し、Microsoft Security Response Center のセキュリティ プログラム マネージャの Eric Schultze は 2 つのセッション (1 つはセキュリティ面における Windows NT 4.0 から Windows 2000 への移行について、もう 1 つは、Windows 2000 セキュリティ テンプレートについて) を担当します。私は David と Eric のプレゼンテーションをお勧めします (演壇に立つうちの数名は最近、別のカンファレンスにも出席しています)。カンファレンスの終了後、5 月 4 日に「Windows 2000 に共通のセキュリティ侵入」というテーマで、私の方でポストカンファレンス ワークショップを開催します。ご希望の方はご参加ください。当日お目にかかるのを楽しみにしています。
Exchange クライアントからサーバーへのセキュリティ
Q: 我々は、Microsoft Outlookｮ クライアントを使用し、インターネットを介して Microsoft Exchange サーバーに接続したいと考えています。この場合、ファイアウォールをどのように構成すればよいですか。また、Outlook クライアントと Exchange サーバー間の通信中に電子メールが盗聴されたり、改ざんされたりしないためにはどうすればよいのか教えてください。
A: 実は、この質問には以前のコラムでお答えしています。ですが今月も同様の質問がいくつかメールボックスに入っていましたので、その方々に対して、再度、正しい方向性を示したいと思います。
Exchange 2000 SMTP サービスを安全に設定するためのヒントをここで補足します。Exchange System Manager において、該当する SMTP 仮想サーバーの [プロパティ] を選択します。[アクセス] タブには、SMTP 経由の Exchange への接続を制御する主要なセキュリティ機能の一部が含まれています。たとえば、[認証]、[セキュリティ保護された通信] (つまり、SMTP トラフィックの整合性と機密性を守ることができる SSL)、[接続制御] (ここでは IP アドレスおよびドメイン名を基にアクセス制限を設定できる)、[中継の制限] (スパム発信者によって悪用される心配が大きい「オープン リレー」設定を無効にできる。Exchange 2000 は既定では、中継可能にするために認証を要求するよう設定されている) などです。クライアントが認証をサポートしていない場合は、クライアントの IP アドレスを中継が許可されている IP アドレス リストに直接追加することができます (この方法は、Web アプリケーションで電子メールを送信する必要があるシナリオで役に立ちます。Web サーバーが Exchange サーバーを介して電子メールを送信できるよう、Web サーバーの IP アドレスを追加できます)。
さらに、[メッセージ] タブで、接続あたりのメッセージ数の上限と、メッセージあたりの受信者数を適切に設定することにより、スパムを制限することができます。使用しているアプリケーションに応じて、既定の数を小さくすることができます。適切に設定できることを願っています。
RevertToSelf APIの呼び出し
Q: Internet Information Services 5 セキュリティのチェックリスト では、Web 実行ファイル内の RevertToSelf API コールを精細に調べるよう推奨しています。なぜですか。
A: この質問に正確に答えるには、Internet Information Server および Internet Information Service のアーキテクチャの背景に少し触れなければなりません。それによってセキュリティ上考慮すべき重要な事項がわかりますので、しばらくの間、お付き合いください。
IIS プロセス (Inetinfo.exe) は LocalSystem として動作します。LocalSystem は、Windows NT または Windows 2000 システム上で最も強力な特権を持ったアカウントの 1 つです。Inetinfo は他のアカウントとしてリモート ユーザーからの要求を処理します (インターネット上では、通常 IUSR_machinenameコンピュータ名 アカウントが匿名要求を処理するために使用されます)。RevertToSelf API コールを使用することで、コマンドを LocalSystem として実行できます (たとえば、「IUSR での処理中にLocalSystem へ復帰してコマンドを実行する」)。
もう少し意味を明らかにします。通常、RevertToSelf は、ISAPI フィルタまたはISAPI 拡張と一般に呼ばれている Internet Server Application Programming Interface (ISAPI) DLL から呼び出されます (フィルタと拡張には異なる点がありますが、ここでは触れません)。ISAPI DLL は、要求ごとに固有のプロセスを生成しなければならない Common Gateway Interface (CGI) アプリケーションのパフォーマンスに影響を与えることなく、ダイナミック Web アプリケーションを作成するための効果的な方法を提供します。
ISAPI 拡張は呼び出される際、実際には Web Application Manager (WAM) オブジェクトでラップされます。この WAM オブジェクトは IIS プロセスまたは「外部プロセス」で実行できます。内部プロセスでの実行の場合、WAM は Inetinfo 内で動作し、RevertToSelf はコントロールを LocalSystem アカウントに返します。外部プロセスの実行では、WAM は独立したプロセス (mts.exe) で動作し、RevertToSelf は、非常に限られた特権しか持たないゲスト アカウントである IWAM_ machinenameコンピュータ名 ユーザー コンテキストを取得します。
外部プロセスの実行はパフォーマンスにわずかに影響を与えますが、乱暴な ISAPI アプリケーションが IIS プロセスをクラッシュさせるのを防ぐことができます。この設定を行うには、IIS 管理 ツールにおいて、サイトの [プロパティ]、[ホーム ディレクトリ] タブ、[アプリケーション保護] の順に進みます。IIS 5 の場合、この設定は既定で [中] となっており、外部プロセスとして実行します ([低] に設定すると、内部プロセスが実行されます)。
ここで、セキュリティ上の影響はどこにあるでしょう。既存の ISAPI DLL が RevertToSelf を呼び出した場合、または攻撃者が ISAPI DLL を IIS サーバーにアップロードし、別の既存の弱点を利用して、それを実行する場合、攻撃者はコマンドを LocalSystem として実行することができます。
これには、どう対処すればよいでしょうか。簡単なのは、[アプリケーション保護] の設定が [中] (繰り返しますが、[中] は IIS 5 の既定の設定です) またはそれ以上のレベルに設定されていることを確認する方法です。もう 1 つは、可能な限り、Web サイトのコードベースから RevertToSelf の呼び出しを見つけて、取り除くという方法があります (IIS 5 チェックリスト で提案されています)。そして、これまでと同様、パッチを常に最新の状態に保ち、NTFS ACL を調べて、見知らぬ人があなたの Web サーバーに DLL をアップロードして実行できないことを確認します。信頼されていない者に対して、あなたの Web サーバーへのコードのアップロードとその実行を許可するのは、厳禁である (セキュリティに関する 10 の鉄則 の「鉄則 4」を参照) ということを忘れないでください。
次回またお会いしましょう
今月の内容が、あなたのセキュリティ武装における弱点解消に役立つことを願っています。それではまたお会いしましよう。
Joel Scambray は、Foundstone の代表です。Osborne-McGraw Hill から発行されている Hacking Exposed: Network Security Secrets and Solutions の共同執筆者でもあります。
セキュリティに関するご質問を Ask Us About Security のメールボックスにお寄せください (英語のみ受付)。質問が採用された場合は、近いうちにコラムに回答が掲載されます。
ここに記載されている情報は、ユーザーに役立つことを目的として提供されています。ただし、本文に記載されている情報を使用するにあたっては、ユーザーが責任を負うものとします。本文の情報は "現状のまま" 提供されており、情報の正確性、完全性、特定の目的への適合性、名称や権利の遵守について、明示的または暗黙的を問わず、いかなる種類の保証の対象でもありません。また、本文書で言及したサードパーティ製品や情報について、マイクロソフトでは著作、推奨、サポート、保証を一切行っておりません。マイクロソフトでは、本文書の情報を基に行った操作による直接的、間接的、偶発的、派生的、あるいは特殊な損害に対して、本文中に損害の可能性が記載されている場合も含めて、一切の責任を負いません。