2<- index ->4


3. アーキテクチャ English

 

3.1 目標事項 English

3.1.1 セキュリティ計画を立案する  English

すべてのサイトは、わかりやすいセキュリティ計画を立てる必要があります。ここにおける計画は、第 2 節において検討する各論を扱うポリシーより高い位置づけのものである必要があり、各論を扱うポリシーが、その体系の中で整合性をもつ広範なガイドラインのフレームワークとして計画される必要があります。

個々のポリシーが、全体のサイトセキュリティアーキテクチャと整合性をもつように、このフレームワークを決めることが重要です。例えば、インターネットのアクセスについては強力なポリシーを持ちながら、モデムの使用については弱い制限しかなかったら、外部アクセスについての強力なセキュリティの制限の全体的な考え方とは整合しません。

セキュリティ計画において、以下の事項が定められる必要があります。: 提供を受けるネットワークサービスの一覧、その組識体のどの部分がそのサービスを提供するか否か、誰がそうしたサービスにアクセスできるようにするのか、どのようにアクセスできるようにするのか、および誰がそうしたサービスを管理するのか等 。

計画には、どのようにインシデントに対応すべきか、ということも盛り込まなければなりません。第 5 章において、この論点について掘り下げた検討を行 いますが、個々のサイトでインシデントとその対応についての範囲(クラス)を定義することが重要です。例えば、ファイアウォールのあるサイトでは、対応を実行するまでにファイアウォールを破ろうとした試みの回数で線を引くべきかもしれません。重要性のレベルは、攻撃と対応の両方について定義される必要があります。ファイアウォールのないサイトでは、1回でもホストに接続しようとする試みがあれば、インシデントであると判断する必要があるでしょう。秩序あるやりかたでのシステムのスキャンはどうでしょうか。

インターネットに接続されたサイトでは、インターネット関連のセキュリティインシデントについてのメディアの誇張がはびこっていることによって、(潜在的に)より深刻な内部のセキュリティ問題を覆い隠してしまう可能性があります。同様に、インターネットにまだ接続したことのない企業は、強力でよくできた内部ポリシーを持っているかもしれませんが、適切な外部接続ポリシーを立てていないでしょう。

3.1.2 サービスの分担  English

サイトにおいてユーザに提供したがるサービスには、多くの種類があり、それらの中には外部接続するものもあります。専用のホストコンピュータに別々にサービスを搭載しようとする ことには、様々なセキュリティ上の理由があります。多くの場合、パフォーマンス(性能)上の理由もありますが、その詳細な検討は この文書の範疇外です。

サイトが提供する様々なサービスにおいては、通常、それぞれに異なるアクセス要件や信頼のモデルが求められます。セキュリティや円滑なサイトの運用の観点から、重要なサービスは、アクセスを限定した専用機上に搭載される方が、(3.1.3 の「全面拒否」モデルをご覧ください。) ひとつ(ないし複数の)あまりセキュアでないとされているサービスや、偶然にセキュリティを侵してしまうかもしれないユーザがより強いアクセス権限を もつことを必要とするようなサービスが、ひとつのマシン上に搭載されるよりも望ましいといえます。

異なる信頼のモデルで運用されるホストを区別することも重要です。(例: ファイアウォールの内側のホストと外部ネットワークにさらされたホスト。)

分離について検討すべきサービスのうち、いくつかについては、3.2.3 で概要を述べてあります。セキュリティの強度とは、その一連のつながりの中で最も弱い部分の強度であること を銘記しておくが重要です。ここ数年の間に起きた、最もよく周知された侵入のいくつかは、電子メール システムの弱点につけ込んだものでした。 侵入者は、電子メールを盗もうとしたのではなく、他のシステムへのアクセスを 得るために、そのサービスにある弱点を使ったのです。

できるのであれば、個々のサービスは別々のそのサービス専用のマシンで動作させるべきです。これは侵入者を隔離し、被害の可能性を制限するのに有効です。

3.1.3 全面拒否(Deny all)/ 全面許容(Allow all)  English

セキュリティ 計画を立案する際に採用されうる考え方には、2 つの両極端のものがあります。どちらを採用するにしても、厳密なモデルで、それらのいずれを選ぶかはサイトと、そこのセキュリティのニーズ次第です。

ひとつめは、まず、すべてのサービスを停止し、それから必要なものを ケースバイケースで、選択的にサービスを使用可能とするというものです。これは、ホスト単位もしくはネットワークレベルで適宜に実施することができます。このモデルは、以降、「全面拒否」モデルと呼ぶもので、通常、次の段落で述べる もうひとつのモデルよりも安全です。各サービスについての理解を深めつつ、「全面拒否」設定をうまく実施するのには、もう少し作業が必要です。よく知られたサービスだけを許容することによって、そのサービスやプロトコルについてよく分析することができるようになり、そのサイトのセキュリティレベルに合ったセキュリティ機構を設計することができるようになります。

もうひとつのモデルは、以降、「全面許容」モデルと呼ぶもので、はるかに実施 しやすいものですが、通常、 「全面拒否」モデルのようには安全ではありません。単純にすべてのサービスを使用可能にし、それは通常、ホスト レベルにおいて デフォルトで、すべてのプロトコルがネットワークの境界を通過できるように しますが、それは通常、ルーターレベルにおいてデフォルトです。セキュリティホールが発見されたら、それらを制限したり、ホストレベルもしくはネットワークレベルでパッチがあれられます。

これらのモデルは、それぞれ、機能用件、運用の統制(コントロール)、サイトポリシー等に応じて、サイトの別々の部分に適用することができます。例えば、ポリシーは、ワークスステーションを通常の用途に設定するときには 「全面許容」モデルを採用し、電子メールハブのような情報サーバーを設定するときには「全面拒否」モデルを採用する、というものであってもよいのです。 同様に、「全面許容」ポリシーが、サイト内の複数の LAN の間のやり取りに 採用されることもあるでしょうし、「全面拒否」ポリシーが、そのサイトと インターネットの間で採用されることもありうるわけです。

上記の例のように複数の考え方を併用するときには注意してください。多くのサイトでは、固い「ガリガリ」な殻と柔らかい「ピチャピチャ」な中身、という考え方を採用しています。そのようなサイトでは、外部とのやり取りについてはセキュリティの費用を支払う用意があり、強力なセキュリティ手段を要求する一方で、これと同様の保護を 内部に提供しようとしない、あるいはできない状況にあります。これは、外部からの防御が突破されることはなく、内部ユーザが信頼できるときには うまくいきます。ひとたび外側の殻(ファイアウォール)が突破されると、内部ネットワークが破壊されてしまうことは、よくあることです。

3.1.4 本当に必要なサービスを識別する  English

内部用とインターネット上で大規模に使うものを合わせて、提供されるサービスには様々なものがあります。セキュリティを管理するということは、通常、サイトの内部サービスへのアクセスを管理し、いかに内部ユーザのリモート(遠隔の)サイトの情報へのアクセスを管理するか、ということです。

インターネットの世界におけるサービスには、押し寄せる波があるようです。ここ数年、多くのサイトでは、普及に応じて、匿名(anonymous)FTP サーバー、 gopher サーバー、wais サーバー、WWW サーバー等を立ち上げてきましたが、 必ずしもすべてのサイトでそれを必要としていたわけではありません。すべての新しく設けられたサービスは、それらが実際に必要であるのか、あるいは、今だけのインターネット中の流行であるのか、を懐疑的な態度で評価するようにしましょう。

セキュリティの複雑さは、提供されるサービスの数が増えると、指数関数的に増大しうることを銘記ください。 フィルタリングルーターは、新しいプロトコルをサポートするためにはモディファイ (改造)される必要があります。プロトコルによっては、その構造上安全にフィルタすることが困難なものがあり (例 RPC と UDP サービス)、内部ネットワークへの穴となることがあります。同一のマシンでサービスを提供することによって、壊滅的な結果を招くことがありえます。例えば、WWW サーバーと同一のマシンで匿名(anonymous)FTP を許容することは、侵入者に、匿名(anonymous)FTP の領域にファイルを置き、HTTP サーバーにそれを 実行させることを許すことになってしまいます。

 

3.2 ネットワークとサービスの設定 English

3.2.1 インフラストラクチャの保護  English

多くのネットワーク管理者は、彼らのネットワーク上のホストを保護するのに多大な時間を費やしています。しかし、ネットワーク自体を保護する努力をしている管理者はほとんどいません。これには理由があります。例えば、ホストを守ることは、ネットワークを守ることよりもはるかに簡単です。また、侵入者は、えてしてホスト上にデータを残すものです。; ネットワークにダメージを与えることが、彼らの目的ではないのかもしれません。とはいえ、ネットワークを守る理由はあります。例えば、侵入者は、データを吟味するために、(つまり、パスワードを探すため ということです。)ネットワーク上のやり取りを外部のホストへとそらすようなことをしかねません。 また、インフラストラクチャには、ネットワークとそれらを接続するルーター以外にも、ネットワーク管理 (例: SNMP)、サービス、(例: DNS, NFS, NTP, WWW) セキュリティ (つまり、ユーザ認証とアクセス制限のことです。)も含まれます。

インフラストラクチャは、人間の過失からも保護されている必要があります。管理者が、ホスト機に誤った設定を行ったら、そのホストは本来のサービスを提供できません。この場合、そのホストを使うユーザに影響を与えるだけで、そのホスト機が、プライマリサーバーでない限り、影響を受けるユーザの人数は、たかが知れています。しかし、もし、ルーターに誤った設定を行えば、ネットワークを使っているすべてのユーザが影響を受けてしまいます。明らかに、どんな1台のホスト機の影響をうけるユーザ数よりも、こちらの方が 、はるかに大きいのです。

3.2.2 ネットワークの保護 English

ネットワーク自身が、弱点をもつ、いくつかの問題があります。古典的な問題として、「サービス妨害」攻撃があげられます。この場合、ネットワークは、もはや正規のユーザのデータを運ぶことができない状況におかれます。このようにするやり方には、通常 2つあります。:

なお、この節で、「ルーター」という用語は、ファイアウォールやプロキシサーバーといったものをも含む、数ある動的にネットワークを相互接続するコンポーネントの 1例として使います。

ルーターを攻撃する方法は、パケットの転送の停止や、パケットの正しくない転送を 引き起こすようにするものです。前者のケースは、誤った設定、にせのルーティング情報や、 「フラッディング(洪水)攻撃」を受け入れてしまうことに起因します。(つまり、ルーターはルーティングできないパケットに襲われて、パフォーマンスが 落ちるのです。)ネットワーク上のフラッディング(洪水)攻撃は、ルーターへのフラッディング (洪水)攻撃に似ていますが、違うのはあふれさせるパケットが通常、ブロードキャストであるということです。 究極のフラディング(洪水) 攻撃は、たったひとつのパケットを受け取ることに よってもたらされるもので、いくつかの既知のネットワークのノードの欠陥に つけ込み、そのパケットを繰り返し中継させるか、もしくはエラーパケットを生成するもので、いずれにせよ、他のホストによって取り上げられ、繰り返されるものです。うまく選択された攻撃パケットによって、指数関数的な中継を生成することもできます。

もうひとつの古典的な問題は「スプーフィング(偽造)」です。この場合、にせのルーティング情報がひとつ、あるいは複数のルーターに送られて、それらにパケットの誤った転送を引き起こさせます。 これがサービス妨害攻撃と違うのは、にせのルーティング情報の 背後にある目的だけです。サービス妨害における目的は、ルーターを使用不能にすることです。; その状態は、すぐにネットワークユーザによって検知されることでしょう。 スプーフィング(偽造)においては、そのにせのルーティング情報は、侵入者がパケット中のデータを監視しているホストへのパケットの転送を引き起こさせます。こうしたパケットは、そのときには、正しい届け先にも転送されています。 ただし、侵入者が、そのパケットの中身を変えてしまっているかもしれません。

このような問題の大部分への対策は、現行のルーティングプロトコル (例: RIP-2、OSPF)で送信されるパケットのルーティング情報の変更を防ぐことです。3 つのレベルの防衛策があります。:平文パスワード、暗号技術によるチェックサムおよび暗号化。パスワードは、物理的なネットワークへの直接のアクセスができない侵入者に対する 最低限の防御を提供するにすぎません。パスワードは、また、誤った設定をされたルーターを、ある程度防ぐことができます。(つまり、規定外のルーターは、パケットを転送しようとします。) パスワードの利点は、バンド幅にも CPU 使用にも、ほとんどオーバーヘッド(負荷)をかけないことにあります。チェックサムは、たとえその侵入者が物理的なネットワークへの直接のアクセスができても、にせのパケットを受け取ることを防ぎます。シーケンス番号や、他のユニークな(一意の)識別子と併用することで、 チェックサムは、「リプレイ(真似)」攻撃という、古い(当時は適切だった)ルーティング情報が侵入者、もしくは誤動作させられるルーターによって返送される攻撃も防ぐことができます。概ね完全なセキュリティは、シーケンス(通番)ないし固有な識別子とルーティング情報の完全な暗号化によって可能です。これは侵入者がネットワークのトポロジー(構成)を推定するのを防ぎます。暗号化の欠点は、情報を処理するのにかかるオーバーヘッド(負荷)です。

RIP-2 (RFC 1723) と OSPF (RFC 1583) の両方とも、平文パスワードを、それらの基本設計の仕様としてサポートしています。さらに、両基本プロトコルには 、MD5 暗号をサポートする拡張機能が用意されています。

残念ながら、フラッディング(洪水)攻撃や、ネットワークをあふれさせてしまうホスト、もしくはルーターの誤動作についての適当な防御策はありません。幸い、この種の攻撃は、発生すれば明らかであり、通常、比較的簡単に打ち切ることができます。

3.2.3 サービスの保護  English

サービスには多くの種類があり、それぞれに固有のセキュリティ要件があります。こうした要件は、サービスが想定する使用形態によって異なります。例えば、サイトの中でのみ使用可能なサービス(例 : NFS)には、外部に使用するために提供されるサービスとは異なる防御メカニズムが求められるでしょう。内部サーバーは、外部 アクセスから守れば十分であるかもしれません。 しかし、WWW サーバーは、(これはインターネット上のすべてのユーザが見ることができる、ホームページを提供するものです。)あらかじめ組み込まれた防御機能を必要とします。要するに、そのサービス、プロトコル、サーバーは、不正アクセスや web データベースの改変を防ぐために、いかなるセキュリティが求められようとも、提供されなければならないのです。

内部サービス(つまり、サイト内のユーザによってのみ使用されるサービス)と、外部サービス(つまり、サイト外部のユーザが享受可能なサービス)は、通常、上述のように異なる防御要件をもっています。それゆえ、内部サービスを一式のサーバーホストコンピュータに搭載し、外部サービスを別の一式のサーバーホストコンピュータに搭載するように分離するのが賢明です。つまり、内部サーバーと外部サーバーは、同じホスト コンピュータにいっしょに搭載してはいけないのです。実際、多くのサイトでは、外部からアクセス可能な一式のサブネットと、(別のネットワークとすることもあります。)サイト内でのみアクセスが許される、別の一式のサブネットを設けようとしています。当然ながら、通常、これらのサブネット間を接続するファイアウォールが置かれます。そのようなファイアウォールが、正しく運用されていることを確認するようにする必要があります。

組織体内の部署を接続するイントラネットの使用への関心が高まっています。(例: 企業の事業部門) この文書では、外部と内部、(公的と私的。)に区別するだけですが、イントラネットを使用しているサイトは、サービスの設計や提供の際には、 3つの部分について考慮し、適切な対策をとらなければならないことを、認識する必要があります。イントラネットで提供されるサービスは、公的とも、企業のひとつのサブユニットに提供される私的なサービスともいえないものです。それゆえ、そのサービスには、外部と内部のサービスやネットワークとは別の独自のサポートシステムが必要となります。

外部サービス形態のものには、特別な配慮を要するものがあり、これは 匿名(anonymous)、もしくは匿名のアクセスのことです。 匿名(anonymous) FTP も、(認証のない)ゲスト ログインもそうです。 匿名(anonymous) FTP サーバーとゲストログインユーザID が、外部ユーザが 操作してはいけないすべてのホスト機とファイル システムから、うまく 隔離されていることを確認することが極めて重要です。ほかに特別な注意を払わなければならない問題領域として、匿名(anonymous)の 書き込みを行うアクセスの問題があります。サイトには公的に入手可能な情報内容について重大な責任があるので、匿名(anonymous)ユーザによって置かれた情報を、注意深く監視することを お薦めいたします。

さっそく、最も普及したサービスのいくつかについて検討してみましょう。: ネームサービス、パスワード/key サービス、認証/プロキシサービス、電子メール、WWW、ファイル転送および NFS。これらは、最もよく使用されるサービスなので、目立つ攻撃対象でもあります。また、このようなサービスへの攻撃が成功すると、無垢な基本サービスは、全く釣り合いを失ってしまいます。

3.2.3.1 ネームサーバー (DNS と NIS(+))  English

インターネットでは、ホストとネットワークの名前をアドレス変換するのに DNS (ドメインネームシステム)が使われています。NIS(ネットワーク インフォメーション サービス) と NIS+ は、グローバルなインターネット上で使用されるものではありませんが、DNS サーバーと同様のリスクをかかえています。名前からアドレスへの変換は、いかなるネットワークの安全な運用にとっても 極めて重要です。DNS サーバーをコントロール、私物化できる攻撃者は、セキュリティ防御をなきものとするために、トラフィックを迂回させることができてしまいます。 例えば、日常のトラフィックが、監視されている配下のシステムにそらされることも ありえます。; また、ユーザが騙されて、認証上の秘密を教えてしまうこともありえます。組織体は、よく知られているようにセカンダリネームサーバーとしてふるまう保護されたサイトを築き、DNS マスターを、フィルタリングルーターを使ってサービス妨害攻撃から守る必要があります。

昔から DNS には何のセキュリティ能力はありませんでした。特に、クエーリーから返ってきた情報は、改ざんをチェックしたり、それがネームサーバーへの問い合わせに応じて返ってきたのかを検証することができませんでした。プロトコルに電子署名を組み込む研究が行なわれており、それが展開されたときには、情報の インテグリティは、暗号技術的に検証されることができるようになります。 ( RFC 2065 をご覧ください。)

3.2.3.2 パスワード/Key サーバー (NIS(+) and KDC)  English

パスワードと鍵のサーバーは、通常、その死活に関わる情報(つまり、パスワードと鍵のこと。)を暗号アルゴリズムで守っています。しかし、たとえ一方方向関数で暗号化されたパスワードでさえ、辞書攻撃によって 解読することができます。(これは、よくある単語が暗号化されており、これと貯えられた暗号化されたものが 一致するかを検査する攻撃です。)それゆえ、これらのサーバーが、そのサービスには使う予定がなかったホストからはアクセス不能であることと、予定していたホストだけがそのサービスにアクセス できることをも確認する必要があります。(つまり、Telnet や FTP のような一般的なサービスは、管理者以外の者には許されない。)

3.2.3.3 認証/プロキシサーバー (SOCKS, FWTK)  English

プロキシサーバーは、多くのセキュリティ拡張機能を提供するものです。これによって、サイトでは、監視するため、内部構造を隠す等のために、サービスをひとつの特定のホスト機に集中させることができます。

このサービス通過させる機能は、潜在的な侵入者にとって魅力的な標的となります。プロキシサーバーに求められるこの種の防御機能は、おおむね使用されるプロキシプロトコルと、代理されるサービスによるといえます。一般的な、アクセスをそのサービスを必要とするホストに制限するルールと、そうしたホストによるアクセスをそのサービスに制限するルールが、最初の1歩として お薦めできます。

3.2.3.4 電子メール  English

電子メールシステムは、長いこと、侵入者が侵入する源となっております。それは、電子メールプロトコルは、最も古いもののひとつであり、最も広く使われているサービスであるからです。また、その性格上、電子メールサーバーは、外界とのアクセスを必要とします。; 大部分の電子メールサーバーは、どこからのものでも受け入れます。電子メールサーバーは、通常 2 つの部分から構成されています。: 受信・送信エージェントと処理エージェントです。電子メールは、すべてのユーザに配信され、通常プライベートなものなので、処理エージェントは、そのメールを配信するのに、システム(root)特権を必要とします。大部分の電子メールの実装形態においては、両方のサービスを行なってしまうので、受信エージェントもシステム特権をもつことになります。これによって、 本書では記述しませんが、いくつかのセキュリティ ホールが開いてしまいます。2 つのエージェントに分離された実装形態のものも入手可能です。このような実装形態は、通常よりセキュアであると考えられていますが、セキュリティ問題を引き起こさないようにするのには慎重なインストールが要求されます。

3.2.3.5 WWW(ワールド ワイド ウェブ)  English

Web は、その使いやすさと情報サービスを集中させる能力によって、指数関数的に普及しています。大部分の WWW サーバーは、サービスにアクセスしている人々からの命令やアクションなどを受け入れます。典型例としては、リモートユーザからの要求を受けて、与えられた情報をサーバー上で動作しているプログラムに渡してその要求を処理するというものです。このようなプログラムには、セキュリティを意識せずに書かれたものがあり、セキュリティホールをあけかねません。Web サーバーが、インターネットコミュニティにつながっている場合、機密情報が、そのサーバーのホスト機にはないことが特に重要です。 実際、そのサーバーは、他の内部ホスト機によって「信頼」されていない、専用ホスト機に搭載されることが推奨されています。

多くのサイトでは、FTP サービスと WWW サービスをいしょに搭載しようとすることでしょう。しかし、これは情報を提供するだけの匿名 ftp サーバー(ftp-get)だけにすべきです。匿名 ftp の put を WWW と組み合わせて使うのは危険です。 (例 あなたのサイトが web で公開している情報が、改ざんされる可能性があります。) それぞれのサービスごとにセキュリティを検討してください。

3.2.3.6 ファイル転送 (FTP, TFTP)  English

FTP も TFTP も、ユーザが電子ファイルを「ポイント to ポイント」で送受信できるようにするものです。しかし、FTP では認証が要求される一方、TFTPでは要求されません。よって、できるだけ TFTP は避けなければなりません。

誤った設定のなされた FTP サーバーは、侵入者を受け入れ、勝手にホスト上のファイルをコピーしたり、置き換えたり、消去したりしてしまう可能性があるので、このサービスを正しく設定することが非常に重要です。 暗号化されたパスワード、財産価値のあるデータへのアクセスや、トロイの木馬の設置は、このサービスが正しく設定されていないときに起こりうる セキュリティ ホールの可能性のほんの一例にすぎません。FTP サーバーは、専用のホスト機に搭載される必要があります。サイトによっては、この 2 つのプロトコルは共通のセキュリティの考慮事項を もっていることを理由に、FTP と Web のサーバーをいっしょに搭載しているところがあります。しかし、このやり方は、薦められません。特に、FTP サービスがファイルの送り込みを認めている場合にはお薦めできません。(上記の WWW の節をご覧ください。) 3.2.3 の節の冒頭で述べたように、あなたのサイトで内部的に提供されるサービスは、外部的に提供されるサービスといっしょに搭載されてはなりません。それぞれは、それぞれのホスト機に搭載されるべきです。

TFTP は、FTP ほどの機能はサポートしていませんし、セキュリティ機能をもっていません。このサービスは、内部使用だけを想定すべきであり、このときには、(システム上のすべての読み取り可能なファイルではなく、)そのサーバーが 事前に定められたファイルにだけアクセスできるように、制限的に設定すべきです。 おそらく、典型的な TFTP の使用法は、ルーター設定ファイルをルーターにダウンロードするのに使うことでしょう。 TFTP は専用ホスト機に搭載されるべきで、FTP もしくは Web の外部アクセスを サポートするホストにインストールしてはなりません。

3.2.3.7 NFS English

NFS(ネットワークファイルサービス)によって、複数のホストは、共通のディスクを共同で使用することができます。NFS は、しばしば、ディスクが無い、ストレージ機能はすべてディスクサーバーに依存するホスト機に使われます。残念ながら NFS にセキュリティは、組み込まれていません。それゆえ、NFS サーバーは、サービスを使用しているホストによってのみアクセス可能である必要があります。これは、どのホストに、そのファイル システムはエクスポートされているかと、どのように権限を与えるか、(例: read-only、read-write 等)を設定することによってできます。ファイルシステムは、ローカルネットワーク外部のホストには、エクスポートされてはなりません。これでは NFS サービスが外部からアクセス可能である、ということになってしまうからです。理想的には NFS サービスへの外部アクセスは、ファイアウォールによってくい止めるべきです。

3.2.4 保護機能の保護  English

あまりに多くのサイトが、顕著な自身のセキュリティの弱点を、セキュリティサーバー自体を攻撃にさらされるところに置いたことに見出すことには驚かされます。既に検討したことに基づいて考えれば、セキュリティサーバーは、決してサイト外部からアクセスできてはならないことは明らかです。サイト上のユーザの認証機能以外は、最低限のアクセスに限定すべきです。; また、他のいかなるサーバーとも共同のホスト機に搭載してはなりません。さらに、サービス自身へのアクセスを含むすべてのノードへのアクセスは、セキュリティが突破されるときに備えて、「紙の証跡」が出せるように、ログを採るようにしなければなりません。

 

3.3 ファイアウォール English

インターネット上で多く開発、提供されていて、最も使われているセキュリティの手段として、「ファイアウォール」があります。一般に、ファイアウォールにはインターネットセキュリティのすべてではないに せよ、ほとんどの論点についての万能薬、との評判があります。それは誤りです。ファイアウォールは、システムセキュリティのためのツールにすぎません。これは、一般に、一定レベルの保護機能を提供するものであり、セキュリティポリシーをネットワークレベルで実装する方法にすぎません。ファイアウォールが提供するセキュリティのレベルは、その特定のマシンによって、まちまちです。よく言われるトレードオフ(二律背反)の関係が、セキュリティと操作性、コスト、複雑性等の間にあります。

ファイアウォールは、ネットワークを守るために、そこを行き来するアクセスを管理・監視するメカニズムのひとつにすぎません。ファイアウォールは、保護されたネットワーク、システムへ行き来するすべての トラフィック が通過するゲートウェイとして働きます。ファイアウォールは、保護されたネットワークと他のネットワーク (例: インターネット、もしくはサイトのネットワークの他の部分)との間で行われるコミュニケーションの量と種類の制限を設けるのを助けます。

ファイアウォールは、一般に、ネットワークの一部と他の部分の間に壁を作るやり方で、例えば、企業の内部ネットワークと地球規模のインターネットの間に壁を作ります。この壁のおもしろい機能は、特定の特徴をもったトラフィックを、注意深く 監視されたドア(「ゲートウェイ」)に通すことにあります。その難しい部分は、そのパケットが、その扉を通じたアクセスを許可ないし拒否されるかを定めるクライテリア(基準)を作ることです。ファイアウォールについて書かれた本では、様々な形態のファイアウォールを記述するのに様々な用語が用いられています。これが、ファイアウォールになじみのないシステム管理者を困惑させているのかも しれません。ここで、ファイアウォールの記述のための定まった用語法は存在していないことを知っておいてください。

ファイアウォールは、必ずしもひとつのマシンではありません。もしくは、ひとつでないのが典型的かもしれません。ファイアウォールは、ひとつではなく、ルーター、ネットワークセグメント およびホストコンピュータの組み合わせです。それゆえ、ここでの検討のためには、「ファイアウォール」という用語は、物理的には複数のデバイスから成ることもありえます。ファイアウォールは、典型的には、フィルタリングルーターとプロキシサーバーという 2 つのコンポーネントから作られています。

フィルタリングルーターは、ファイアウォールを設けるのに最も容易なコンポーネントです。ルーターというもには、データを 2 つ、ないしそれ以上のネットワーク間を出入りさせるものです。「通常の」ルーターは、パケットをネットワーク A から、それを「ルーティング」 して、その宛先であるネットワーク Bに運びます。フィルタリングルーターは、同様のこともしますが、そのパケットをどのようにルーティングするかを決定するだけでなく、そのパケットがルーティングされるべきかも決定されます。これは、与えられたデータのパケットについてどのように処理するかをルーターが判定するための一連のフィルタをインストールすることによって行われます。

特定のソフトウエアのバージョンが動作する特定のブランドのルーターの能力に関する検討は、本書の範疇外です。しかし、パケットをフィルタリングするのに使うルーターを評価するときには、フィルタリングポリシーを実装する際の下記のクライテリアが重要です。:

セキュアなフィルタリングスキームを築くために必要な他の情報として、

ルーターが、弱点をもつ可能性があることとともに、出入りするパケットへのフィルタの適用の区別は、特に 2 つ以上のインターフェイスをもったルーターについて意味があります。他の重要な論点として、

があります。よいフィルタを作ることは難かしく、そのフィルタリングしようとするサービス (プロトコル)ついての深い理解が求められるものです。

よりよいセキュリティのためには、通常、フィルタは、2 つのネットワークの間に 1つだけ設置れる要塞ホストと呼ばれるホスト機に置かれ、アクセスを制限します。他のネットワークには、この要塞ホストを経由してのみアクセスすることができます。このホストだけのときの方が、いくつものホストがあるよりも、攻撃されやすいともいえますが、この方が、このホストさえ慎重に保護されればよいので、一定のレベルのセキュリティを確保する ことは容易です。正規のユーザが、このファイアウォール越しに資源を入手できるようにするためには、サービスは、要塞ホストによって転送される必要があります。サーバーによっては、(DNS サーバー もしくは SMTP サーバーのように、) 他のサービス用の(例: Telnet、FTP 等)組み込みの転送機能があります。プロキシサーバーは、セキュアに、ファイアウォール越しの資源へのアクセスを許すことができます。

プロキシサーバーは、アプリケーションサービスをひとつのマシンを通過するように集中させるものです。 典型的には、1 台のマシン(要塞ホスト)が、様々なプロトコル(Telnet、SMTP、 FTP、HTTP 等)のためのプロキシサーバーとして設置されますが、それぞれのサービスのために複数の専用のホスト コンピュータが設置されることもあります。クライアントは、外部サーバーに直接、接続する代わりにプロキシ サーバーに接続します。その後、プロキシサーバーは要求された外部サーバーへの接続を開始します。使用されているプロキシサーバーの種類によって、ユーザに知識がなくても内部のクライアントに自動的に代理機能を実行させるように設定できるものもあれば、ユーザが、プロキシサーバーに直接接続して、特定のフォーマットで接続を開始することを要求するものもあります。

プロキシ サーバーを使用することによって、明らかなセキュリティの便益があります。プロトコルのアクセスコントロールリストを追加することができ、ユーザもしくはシステムにアクセスが許可される前に、一定レベルの認証を要求することもできます。

しばしば ALG(アプリケーションレイヤーゲートウェイ)と呼ばれる、より高機能なプロキシサーバーは、特定のプロトコルを解釈できるように構築することができ、そのプロトコルのものだけをブロックするように設定することができます。例えば、FTP 用の ALG は、"put" コマンドと "get" コマンドの違いを識別することができます。組織体では、ユーザがインターネットからファイルを"get" することは許可しても、リモートのサーバー上に内部ファイルを"put" することができないことを望むかも しれません。対照的に、フィルタリングルーターは、すべての FTP アクセスをブロックできるか、できないかで、中身までは見ません。

プロキシサーバーでは、たくさんのパラメータによって、データストリームを暗号化するように設定することもできます。組織体は、インターネットしかアクセスポイントをもたない 2 地点間における暗号化されたコネクションのために、この機能を使用することでしょう。

ファイアウォールは、典型的には、侵入者を侵入させないように考えられていますが、正規のユーザをサイト内に通すためにも使われることがあります。正規のユーザが、展示会や会議等への出張の間、「ホーム」サイトに定期的にアクセスする必要があるという多くの例があります。インターネットへのアクセスは、可能な場合もありますが、信頼されていないマシン もしくはネットワーク経由となることでしょう。 正しく設定されたプロキシサーバーは、正規のユーザをサイト内に 通過させる一方で、他のユーザのアクセスを拒否することができます。

ファイアウォール技術において、最新のよいやり方があり、それは、ひとつのペアのスクリーニングルーターを組み合わせて使用し、2 つのルーター間のネットワーク上にもうひとつプロキシサーバーを設置して行うものです。この設定により、外部ルーターが、IP 層でのセキュリティを突破する攻撃 ( IP スプーフィング、ソースルーティング、パケッ トフラグメント)の試みをブロックする一方で、プロキシサーバーが上位層のプロトコルのセキュリティ ホールの可能性についてを扱えるようになります。その内部ルーターの目的は、プロキシサーバー宛て以外のすべてのトラフィックをブロックすることです。 もし、この設定が厳密に実装されていれば、高いレベルのセキュリティが達成できます。

大部分のファイアウォールは、ネットワークのセキュリティ管理をより便利にするようにチューンできるログ機能を提供しています。ログ機能は、集中管理され、そのシステムは、異常事態の警告(アラート)を送信するように設定されることでしょう。いかなる侵入や突破の試みの兆候にも備えるように、このようなログを定期的に監視することが重要です。侵入者の中には、ログを編集して自身の足跡を隠そうとする者もいるかもしれないので、こうしたログを守ることが望まれます。様々な手段が可能で、下記のものがあります。:

他の技術として、

があります。この際、このシリアルポートを、隔離されたマシンまたはログを管理する PC に接続するようにしてください。

ファイアウォールについては、様々な品質や強度のものが入手可能です。商業パッケージには、およそ 10,000米ドルから、250,000米ドル以上のものまであります。より小額で「自家製」ファイアウォールを構築することができます。(商用にしろ自家製にしろ)ファイアウォールの正しい設定には、相当のスキルと TCP/IP の知識が必要とされることを銘記しておく必要があります。両者ともに、定期的な保守、ソフトウェアのパッチやアップデートのインストール、定期的な監視(モニタリング)が必要とされます。ファイアウォールを購入するときには、そのファイアウォールの物理的要素の費用に加えて、このような追加的費用が考慮される必要があります。

また、「自家製」 ファイアウォールの作成には、かなりのスキルと TCP/IPの知識が要求されます。結局、セキュアでないと後で気づくよりも、セキュリティを知覚できる方がよいので、気軽に挑戦すべきではありません。すべてのセキュリティ手段と同様、脅威、守るべき資産の価値、セキュリティを実装するのにかかる費用に基づいて意思決定することが重要です。

最後に、ファイアウォールについての注意事項を述べます。それらは、サイトにセキュリティを実装する際に大きな役割を果たし、大抵の攻撃から保護してくれるかもしれません。しかし、それらは、対策の一部にすぎないことを忘れてはなりません。それらは、あなたのサイトをすべてのタイプの攻撃から守ってくれるわけではないのです。


->4