Web サーバーをセキュアにする

Web サーバーを公開し、その安全を維持するには

Web サーバーは、一般に公開される組織の顔の 1 つであることから、格好の標的とされる危険をはらんでいます。公開リソースであることから、Web サーバーはある意味、「サメの餌食」のようなものですが、その状況に甘んじる必要はありません。この記事を読んで、Web サーバーを一般公開すると同時に、その安全を守る方法を学んでください。

Sean-Philip Oriyano, IT Instructor, Greater Detroit

Sean-Philip Oriyano は、1990年から IT 分野で活躍しています。彼はその経歴を通して、サポート・スペシャリストからコンサルタント、そしてシニア・インストラクターなどの職務を果たしてきました。現在は、インフラストラクチャーおよびセキュリティーを専門とする IT インストラクターとして、さまざまな公共団体と民間団体に協力しています。彼は、米国内やその他の国々に拠点を置く米国の陸海空軍で教えた経験もあります。CHFI、CEH、CEI、CNDA、SCNP、SCPI、MCT、MCSE、および MCITP としての資格を持つ彼は、EC-Council、ISSA、Elearning Guild、Infragard のメンバーでもあります。


developerWorks 貢献著者レベル

2009年 4月 21日

Web サーバーは一般に公開される組織の顔の 1 つであり、それゆえに最も狙われやすいターゲットの 1 つでもあります。こうした Web サーバーは興味深い矛盾をかかえています。つまり、組織に関する情報を共有しながらも、その保存されている情報が漏れないようにする必要があるからです。このジレンマを解決するのは厄介で、しかも報われない仕事ですが、最も重要な仕事の 1 つであることも確かです。

詳しい内容に入る前に、まずはサーバーが最前線の「部隊」の一員であるがゆえに直面するいくつかの脅威について見て行きましょう。

Web サーバーに対する脅威

Web サーバーに向けられた脅威はとてつもなく大量にありますが、その多くは、システム上に構成されたアプリケーション、オペレーティング・システム、環境を利用したものです。このセクションでは、哀れなサーバーが直面する可能性のある攻撃のなかでも、とりわけ受けやすい攻撃を集めました。

サービス拒否

サービス拒否 (DoS: Denial of Service) 攻撃は、サーバーが直面する可能性のある、実に「伝統的なスタイル」の攻撃の 1 つです。この攻撃は極めて単純なもので、最近ではスキル・レベルの低い、一般にスクリプト・キディーとして知られる個人が行うようになっています。かいつまんで言うと、DoS 攻撃とは、あるシステムが別のシステムのリソース (帯域幅やプロセッサー・サイクルなど) を使い果たし、正当なリクエストにはリソースが残されていない状態にすることを目的とした攻撃のことです。一般に、このような攻撃は迷惑行為のカテゴリーに格下げされていますが、それを理由にガードを甘くしないでください。睡眠時間を奪うものは他にも山ほどあるからです。

分散型サービス拒否

分散型 DoS (DDoS) 攻撃は DoS 攻撃の兄貴分であることから、意地悪さも厄介さも上回っています (私にも 2 人の兄がいますが・・・それはここでは関係ありません)。DDoS 攻撃の目的は DoS と同じですが、ただしその規模は遙かに大掛かりで、複雑さも一段と増しています。DDoS 攻撃では、1 つのシステムが別のシステムを攻撃するのではなく、アタッカーが複数のシステムを使って 1 つのサーバー (あなたのサーバー) を攻撃します。ここで言っている複数のシステムとは、何百台、何千台の規模ではなく (そういう場合もありますが)、何十万台ものシステムに及びます。DoS は単なる迷惑行為に過ぎませんが、DDoS 攻撃となると、まさに致命的です。この攻撃によって、サーバーがいとも簡単にオフラインになってしまう恐れがあるからです。ただし、幸いなことに、DDoS 攻撃を成功させるには、かなり高いスキル・レベルが要求されます。

よくある DDoS 攻撃としては、以下が挙げられます。

  • FTP バウンス攻撃。FTP (File Transfer Protocol) バウンス攻撃は、アタッカーが特別に作成したファイルを脆弱な FTP サーバーにアップロードし、FTP サーバーがファイルを別のロケーション (通常は、組織内にある別のサーバー) に転送した時点で成立します。一般に、転送されるファイルに含まれるある種のペイロードが、最終的にファイルを受け取ったサーバーをアタッカーの意図に沿って動作させるように仕組まれています。
  • ポート・スキャン攻撃。ポート・スキャン攻撃は、ホストをスケジュールに基づいて構造的かつ体系的にスキャンすることによって行われる攻撃です。例えば、公開されたサービスやその他の脆弱性を見つけ、それを悪用する目的で Web サーバーをスキャンするといったことが考えられます。この攻撃は、インターネットで自由に利用できる数々のポート・スキャナーのいずれかを使用して、かなり簡単に実行することができます。スクリプト・キディーでもサーバーのホスト名や IP アドレスを入れるだけで攻撃を仕掛けられるため、ポート・スキャン攻撃は最もよくあるタイプの攻撃の 1 つにもなっています (ただし、スクリプト・キディーには結果をどのように解釈するのかはわからないのが通常です)。より高度なアタッカーは、ポート・スキャンを利用して情報をつかみ、後でその情報を悪用するという点を忘れないでください。
  • ping フラッド攻撃。ping フラッド攻撃は、サービスやシステムが起動しているか、停止しているかの情報をつかむために、コンピューターがパケット (ping) を別のシステムに送信するという単純な DDoS 攻撃です。簡単な攻撃では、サービスやシステムの状態に関する情報をこっそり入手するために ping フラッドが使用されますが、現在ではターゲット (すなわち犠牲者) に大量のパケットが送信され続けるようにすることで、システムがオフラインになったり、動作速度が落ちたりするような攻撃にも使用されます。ping フラッド攻撃は「伝統的なスタイル」とは言え、最近の多くのオペレーティング・システムは今でもこの攻撃に弱く、これが原因で停止状態になる可能性があるため、非常に効果的な攻撃です。
  • Smurf 攻撃。この攻撃は ping フラッド攻撃と似ていますが、プロセスは賢く変更されています。Smurf 攻撃では、(送信元をターゲットのアドレスに改ざんした) ping コマンドをターゲットが属するネットワークのブロードキャスト・アドレス宛に送信すると、そのネットワーク上のすべてのマシンからでコマンドへの応答が一斉にターゲットに送られます。つまり、はじめは 1 つだった「滴」が、事実上、トラフィックの津波にまで膨れあがります。幸いなことに、このタイプの攻撃は希少と言えます。
  • SYN フラッド。この攻撃には、TCP/IP プロトコルについてのある程度の知識が必要です。具体的には、通信プロセス全体がどのように機能するかを知っていなければなりません。この攻撃を説明するのに最も簡単な方法として例えを用いると、SYN フラッド攻撃は、返信を必要とする手紙を誰かに送るものの、その手紙では偽の返信先住所を使っているといったようなネットワークのことです。手紙を受け取った相手はその手紙を送り返して返事を待ちますが、返事が戻ってくることはありません。手紙はどこかのブラックホールに入ってしまうからです。システムに対して大量の SYN 要求を実行することで、アタッカーはシステム上のすべての接続を使用し、他の接続が 1 つも確立できないようにします。
  • IP フラグメント/フラグメント攻撃。この攻撃では、アタッカーが TCP/IP プロトコルに関する高度な知識を利用してパケットを小さな「フラグメント」に分割します。小さく断片化されたパケットであれば、大抵の侵入検知システムをすり抜けるからです。極端な例では、このタイプの攻撃がシステムのハングアップ、ロックアップ、リブート、ブルー・スクリーン、そしてその他の危害を引き起こすこともあります。幸いなことに、この攻撃を成功させるのは困難です。
  • SNMP (Simple Network Management Protocol) 攻撃。SNMP 攻撃は、ネットワークとネットワーク上の機器を管理するために使用される SNMP サービスを悪用することを明確な目的としています。SNMP はネットワーク機器の管理に使用されるため、このサービスを悪用することで、アタッカーはネットワークの構造に関する詳細な情報を手に入れられることになります。その情報は、後で攻撃のために使用される恐れがあります。

Web ページの改ざん

インターネットでは、Web ページの改ざんを時折目にします。この名前が示唆するように、Web ページの改ざんとは、Web サーバーが不適切に構成されている場合に、アタッカーがその欠陥のある構成を利用して Web ページを変更することです。その理由は、面白半分からという場合もあれば、政治的主張を押し付けるためなど、いくらでもあります。


SQL インジェクション

SQL (Structured Query Language) インジェクションは、データベースに対して仕掛けられる攻撃です。この攻撃では、アタッカーがデータベースの設計や Web ページの欠点を利用して情報を引き出したり、あるいはデータベースのなかにある情報を操作したりすることさえあります。このタイプの攻撃をどのように実行するかについての詳細は私にはわかりませんが、SQL の知識 (Web サーバーでデータベースをホストしているとしたら、持っているはずの知識) を持っている方であれば調べられるはずです。


質の悪いコーディング

開発者としての経験や、情報技術の分野で働いた経験があるならば、いい加減なコーディングや手を抜いたコーディングのプラクティスから生じた問題を目にしたことがあるはずです。コーディングの質が悪いという問題は、トレーニング不足や未経験の開発者、あるいはアプリケーションの品質保証が不十分であるなど、数ある要因のどの 1 つをとっても生じる可能性があります。運がよければ、質の悪いコーディングは機能が予定通りの動作をしないという頭痛の種にしかなりませんが、最悪の場合にはアプリケーションに大きなセキュリティー・ホールができてしまうこともあります。


シュリンクラップ契約のコード

この問題は、上記の質の悪いコーディングでの問題に多少関連しますが、それを巧妙にしたものになっています。基本的にこの問題の原因となるのは、開発サイクルを短縮するために、独自のアプリケーションのビルディング・ブロックとして使用できるプリコンパイル済みコンポーネントまたは既製のコンポーネントを都合よく入手することです。しかしこれには、アプリケーションの作成に利用しているコンポーネントが社内のコードと同じ審査プロセスを通過していないことから、アプリケーションが潜在的な問題領域を抱えることになるという欠点があります。その上、開発者がコードの分析方法を実際にわかっているわけではなく、そのコードがいわゆる「シュリンクラップ契約」によるコンポーネントをアプリケーションに組み込むために具体的に何をするかを理解していないという例もちらほら耳にします。私が少なくとも思い付くのは、ある開発者がシュリンクラップ契約のコードを使用してアプリケーションの認証メカニズムを提供した例です。このコードは実際にユーザーを認証していたとは言え、その同じクレデンシャルを密かにサード・パーティーにも E メールで送っていました。


防御手段

巷にはどのような脅威が溢れているかを説明して皆さんをすっかり怖がらせてしまいましたが、ここからは危険から身を守る方法について説明します。

まずは、Web サーバーを保護するために私が計画した 6 つのポイントを詳しく説明させてください。

  1. 内部用の Web サーバーと外部用の Web サーバーを別にすること。考えるまでもないことのように聞こえますが、この点は何度でも繰り返す必要があります。ほとんどの組織には、内部で使用する Web ベースのアプリケーションやサイトの他に、外部で使用するアプリケーションおよびサイトがあります。理想としては、サーバーとコンテンツのセットを内部用と外部用に分け、内部用のサイトと外部用のサイトにそれぞれ専用のサーバーを持たせて、できる限りこの 2 つが重複しないようにしなければなりません。システムをこのように分離させることで、アタッカーがサーバーに不正侵入し、データや、あるいは内部システムにまでアクセスしてしまう可能性を防ぎます (少なくとも、その危険性を少なくします)。
  2. 開発サーバーと本番サーバーを分けること。私はこれまで、このルールを破って開発チームに本番サーバーでコードの開発、あるいは既存のコードの調整を行わせている企業をいくつか見てきました。一般的に、これは極端に手抜きをしている例に過ぎません。しかしこの手抜きによって、アタッカーが未完成のコードを目にし、それを悪用した場合には壊滅的な問題がもたらされる恐れがあります。さらに、コードのテストと調整を行うことによって、開発者自身がセキュリティーを侵害してしまう可能性についても考慮してください。開発環境を実装するのが身のためです。
  3. 定期的に監査すること。まともな Web サーバーや Web アプリケーションであれば、システム上で行われたアクティビティーのログを生成する何らかの方法があるものです。アクティビティー情報をログに記録した後、ログを調べてアプリケーションの障害や疑わしいアクティビティーなどの問題がないかどうかを確認することを定期的なルーチンの一部にしてください。念頭に置いておかなければならない点は、監査ログは事件現場で集めた証拠のようなものだということです。後で調べるつもりでなければ、ログには何の価値もありません。
  4. システムを最新の状態に保つこと。この点について本当に検討する必要があるかどうかと言うと、もちろんそのとおりです。システムへのパッチの適用は見過ごされがちな問題ですが、実は重要なことです。システムをセキュアにするために役立つパッチ、サービス・パック、更新、あるいはその他の項目が利用可能であるかどうかについては、常に目を光らせておいてください。ホスティング・プラットフォームやその他の要因によっては、そのような更新が自動的に配信されるようにすることもできれば、昔ながらの手動による配信手段を使わなければならないこともあります。またもう 1 つの重要な点として、バッファー・オーバーフローやネットワーク・クライアントなどに関連する問題は、ほとんどの場合、更新が唯一の修正方法であることも忘れないでください。
  5. 脆弱性をスキャンすること。私は以前の記事 (「参考文献」を参照) で、ホスティングおよびアプリケーション・インフラストラクチャーでの問題を検出するツールとして、脆弱性スキャナーを話題にしました。脆弱性スキャナーは、ソフトウェアに関連する脆弱性 (例えば構成やパッチの問題など) を解明するために常に戦い続ける上で非常に強力なツールとなります。また、脆弱性スキャナーは定期的に更新されるため、最新の問題を見つけるために使用できるという利点もあります。新しい脆弱性には気付きもしないことがよくありますが、定期的に更新される脆弱性スキャナーを使用することにより、脆弱性が悪用される前に対処することができます。フリーウェアの Nessus (「参考文献」を参照) などのツールは、Linux®、UNIX®、あるいはその他のプラットフォームでホストするかどうかに関わらず、管理者にとって素晴らしい資産となるはずです。
  6. 開発者をトレーニングすること。これを成功させるのは多少難しいかもしれませんが、開発者のトレーニングによって得られる成果ははかり知れません。開発者にセキュアなコーディング・プラクティスを教育することで、ずさんなコーディングや手抜きのコーディングに伴う問題が解消、あるいは軽減されることになります。

その他の詳細

以上の 6 つのポイントの他にも、組織のホスティング構造のセキュリティーを強化するために実行できることは山ほどあります。ここからは、問題の原因となりがちな点、そしてその対処方法について見て行きます。

不適切な構成

ハードウェアとソフトウェアがより複雑になる一方、IT および開発チームが縮小されるようになったことから、言ってみれば「レーダーで問題を捕え損ねてしまう可能性」が大きくなっています。幸いなことに、脆弱性スキャナー、自動スキャナー、そして地道な教育と適切な注意を以ってすれば、不適切な構成という問題は減らすことができます。

バナー情報は、そこに隠された情報の存在を知り、それをどのように調べるかを知っている者に大量の情報を暴露する可能性があります。バナー情報が明らかにするバージョン・データなどの有効な情報が、アタッカーの助けになる可能性があります。

例えば、Web サーバーにリクエストを送信し、基本的な .html または .htm ファイルといった静的なコンテンツを要求すると、それに対するレスポンスの先頭にはコンテンツ・ロケーション・ヘッダーとして知られる情報が追加されます。Web サーバーのデフォルト構成によって、このコンテンツ・ヘッダーが IP アドレスを参照し、完全修飾ドメイン名 (FQDN) を提供する場合もしない場合もあります。最悪の場合、このヘッダーが、他のデータと併せて内部 IP アドレスの情報を公開する可能性があります。リスト 1 に記載するヘッダーを見てください。

リスト 1. コンテンツ・ロケーション・ヘッダーの例
HTTP/1.1 200 OK
Server: <web server name and version>
Content-Location: http://w.x.y.z/index.htm
Date: Thu, 1 Jan 2009 14:03:52 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Wed, 31 Dec 2008 18:56:06 GMT
ETag: "067d136a639be1:15b6"
Content-Length: 4325

このヘッダーからは、サーバーに関するかなりの情報がわかります。ただし恐れることはありません。Web サーバーでは、特定の組織の意向に沿って、この情報の望ましくない部分を削除したり、あるいは情報を変更したりできるのが通常だからです (詳細については、ご使用の Web サーバーの資料を参照してください)。

アクセス権

一部の分野では、アクセス権が未だに問題になりがちです。アクセス権が不正に割り当てられていたり、適切に計画されていなかったりするために、ユーザーにアクセスが許可されないはずのサーバーやアプリケーションの一部にユーザーがアクセスできることは珍しくありません。常に確認しなければならないのは、サーバーを管理したり操作したりするユーザーに対し、それぞれが必要な作業を行い、それ以外の作業は行えないような適切なアクセス権が割り当てられていることです。これは、最小特権と呼ばれています。

エラー・メッセージ

誰でもときどき、あの恐ろしい 404 メッセージやそれと似たようなメッセージを受け取ったことがあるはずです。これらのメッセージは、探している情報が見つからないこと、あるいは何らかの不正行為の犠牲となったことを知らせるエラー・メッセージですが、よく調べてみると、それ以上の情報を伝えている場合もあります。アタッカーにとって、Web サーバーやアプリケーションが生成するエラー・メッセージは、アプリケーションの構成、使用されているライブラリー、データベース接続ストリングをはじめ、さまざまな情報を得るための手掛かりとなる可能性があります。しかし、アタッカーだけに利用させておく必要はありません。あらゆるエラー・メッセージをテストと開発に有利に利用して、問題の発見に役立てるべきです。ただし、アプリケーションやサーバーを本番環境にデプロイする際には、エラー・メッセージを無効にするか、極めて一般的な情報を公開するように構成しなければなりません (その方法については、ご使用の Web サーバーの資料を参照してください)。

サービス

Web サーバーとアプリケーションをホストするシステムを構築するときには、必要とされる機能および機能性を慎重に計画し、それからその目標に向けてサーバーを構築してください。基本的には、サーバーが何をすべきかがわかったら、その役割をサポートするために必要なサービスと機能を有効にし、その環境に必要のないものはすべて削除するか、無効にします。環境内に存在し、有効にされているすべてのサービスまたはアプリケーションも同じく、アタッカーが悪用する可能性のあるセキュリティー・ホールであるという点を忘れないでください。

プロトコル

この場合もサービスとほとんど同じように、必要のないプロトコル (NetBIOS など) はお払い箱にして無効にするか、完全に削除してください。

ユーザー・アカウント

オペレーティング・システムをインストールするときに、そのオペレーティング・システムとアプリケーションにデフォルトのユーザー・アカウントをセットアップするのは珍しいことではありません。しかし安全のためには、デフォルトのユーザー・アカウントにも注意する必要があります。必ず、存在するユーザー・アカウントを調べて、必要のないユーザー・アカウントに関しては無効または削除し、必要なユーザー・アカウントに関してはパスワードを強化 (および変更) してください。

サンプルおよびテスト・ファイル

Web サーバーやアプリケーションに、その製品で何ができるかを示す技術デモとして、サンプル・ファイルとテスト・コンポーネントが付属していることがときどきあります。しかし安全でセキュアな環境では、これらのファイルをすべての本番 Web サーバーとアプリケーションから削除しなければなりません。なぜなら、不正アクセスを可能にするために操作される可能性があるためです。

ポート

Web サーバーとアプリケーションが機能しなければならないポートを調べ、該当するポートを有効に (そして監視) してください。さらに、使用していないポートはクローズして、ファイアウォールでブロックする必要があります。


その他の防御対策

ホスティング環境をさらに強化するために、以下の対策を採用することも検討してください。

  • 侵入検知システム (ホストおよびネットワーク・ベース)。侵入検知システムは、ネットワーク全体でサーバーへのアクセス、サーバーからのアクセス、およびサーバー自体でのアクティビティーを監視するのに役立つハードウェア機器またはソフトウェア・デバイスです。
  • ウィルス対策ソフトウェア。当然、Web サーバーにはウィルス対策ソフトウェアが必要です。
  • ファイアウォール。数々のファイアウォールが利用可能になっているので、自分のニーズにぴったり合ったファイアウォールを選んで、Web サーバーの前面に配置してください。
  • 常識。これも付け加えなければなりません。この 10 年間、個人の生活とビジネスの世界の両方で、インターネットが日常生活に入り込んでくるようになってきましたが、そこにあった概念は、手に入れられるものは何でもインターネット上で手に入れるというものでした。それが当然のことだと思われていたからです。この、すぐにインターネットを利用して、ライバルよりも先に大成功を収めるための「物量作戦」によって、インターネットには本来あるべきではない大量の情報が溢れる結果となりました。注意しなければならないのは、すべてがすべて、インターネット上になければならないものではないことです。また、インターネットに何かを載せる場合には、一度外に出たものは元に戻せないことを心に留めておかなければなりません。この点に確信が持てないとしたら、www.archive.org にアクセスして、自分の Web サイトやライバルの Web サイトがこの 10 年間、どのような内容だったのかを確かめてください。

まとめ

Web サーバー、そしてホストするアプリケーションをセキュアにすることは実に大変な仕事ですが、不可能な仕事ではありません。ある程度の調査と十分な努力をすれば (おそらくは、濃いコーヒーを飲みながら何日か夜遅くまで仕事すれば)、その分ホスティング環境を強化できるだけでなく、長い目で見れば、頭痛の種を取り除くことになります。

参考文献

学ぶために

製品や技術を入手するために

  • Nessus 脆弱性スキャナーには、高速ディスカバリー、アセット・プロファイリング、脆弱性分析などの重要なスキャニング機能が用意されています。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development
ArticleID=391670
ArticleTitle=Web サーバーをセキュアにする
publish-date=04212009