Fig. 211
２．インタ−ネット接続
2-1. インタ−ネット接続口の設計
(1) 設計の基本方針
* ファイアウォ−ルの設置
--------------------------------------------------------------------------------
ＷＡＮ接続のル−タとゲ−トウェイのホストでパケットフィルタリングをする。
--------------------------------------------------------------------------------
内部ネットワ−クのホストを外部の不正アクセスから保護する。このため外部と内部ネッ
トワ−クの間にゲ−トウェイ・ホストをおき、このホストに市販のファイアウォ−ル・ソ
フト FireWall-1 を設置する。 FireWall-1 は基本的にはパケットフィルタリング型のフ
ァイアウォ−ルである。fwtk などのフリ−ソフトを使う手もあるが、 コンパイルしたり
色々設定しなければ使えない。８０万円出しても市販品を使う方が手間も省け安全である。
それとインタ−ネット接続の実際の口となるＷＡＮル−タでも、パケットフィルタリング
して不正アクセスを侵入させないようにする。二重のプロテクションをかける。
* 電子メ−ルサ−バのホスト
--------------------------------------------------------------------------------
メ−ルサ−バはゲ−トウェイの内側におき、メ−ル・アドレスを集中管理する。
--------------------------------------------------------------------------------
バリアセグメントのホストにおいた場合、ル−タのファイアウォ−ルを破られたら外部か
ら電子メ−ルを見られる可能性がある。より安全のためゲ−トウェイのファイアウォ−ル
の内側にサ−バをおいた方がよい。それにバリアネットのホストに置くとなるとＷＷＷサ
−バとホストを兼任させることになる。電子メ−ル、ＷＷＷのアクセスは余裕をもって対
処させたい。更にもう一つの理由として、内部ホスト間の電子メ−ルのサ−バとしても使
いたい。それには内部ホストを管理するための DNS または /etc/hosts ファイルを、ゲ
−トウェイの内側に置くため、同時に電子メ−ルのサ−バも内側におく必要がある。
* ゲ−トウェイのホスト
--------------------------------------------------------------------------------
ゲ−トウェイのファイアウォ−ル機能を持たせるホストは、専用ホストとする。
--------------------------------------------------------------------------------
ファイアウォ−ルは確実性が重要であり、安定して稼働することが大事である。ゲ−トウ
ェイのホストにはメ−ルサ−バやシステムのログなど、時事変化するようなものは基本的
には置かないようにする。ファイアウォ−ルのログでも、できれば内部ネットの管理者用
コンピュ−タに送るとかした方が本当はいいだろう。それにプログラムの開発なども行わ
ないようにする。社内のプリンタサ−バを兼用させるようなこともしない。どんなことで
ファイアウォ−ルがダウンするかわからない。その危険性を避けるためである。ともかく
このホストは、社内ネットワ−クを守る要である。ファイアウォ−ルとしての機能に特化
することが望ましいというか、むしろ必須である。
* 外部向けＷＷＷサ−バのホスト
--------------------------------------------------------------------------------
外部向けＷＷＷサ−バのホストは専用ホストとする。
--------------------------------------------------------------------------------
考えるべきことは一つ。ファイアウォ−ルの外側におくか内側におくかである。一般的に
は外側におく場合が多い。外側におく場合ＷＷＷホストを保護するために、ル−タでパケ
ットフィルタリングをする、ホスト自身にセキュリティ対策を施すことが必要である。内
側におく場合はファイアウォ−ルで保護することができる。しかし外部からのパケットが
内部ネットにあるＷＷＷホストまで来るのを許すことに変わりない。 危険な cgi-bin プ
ログラムが放置されていたりすれば、致命的なセキュリティ問題になる。ただ内側におく
構成は、ファイアウォ−ルをパケットフィルタリング型にした場合だけ可能である。
* ネットワ−クの監視
--------------------------------------------------------------------------------
ネットワ−クを監視するホストを内部ネットに１台おく。
--------------------------------------------------------------------------------
ネットワ−クの管理者を netmaster というユ−ザにし、 DNS や電子メ−ルの管理者とす
る。ホストは電子メ−ルサ−バのホストと兼用でもいいだろう。これでインタ−ネット接
続ための基本構成はＷＷＷ用、ゲ−トウェイ用、電子メ−ル用で３台のホストとなる。外
部からの攻撃に対し、ル−タやファイアウォ−ルの一般的なログはとらない。取ったとこ
ろで管理者１人ではチェックすることはできない。特にル−タのログは取ると膨大なもの
になり、何らかの解析ソフトが必要になるだろう。しかしファイアウォ−ルのクリティカ
ルなログは、できればチェックしたい。ＷＷＷのログはコンテンツ・アクセスの分析には
いいが、１人ではそこまではできない。
* ホスト名解決について
Sun ＥＷＳ特有のホスト名解決 NIS はインタ−ネット接続口の３台では使わない。NISは
セキュリティホ−ルになり易い。これら３台で使う必要は特にない。それにゲ−トウェイ
のホストやル−タはＤＮＳ管理はしない。つまり自社用のネ−ムサ−バにエントリを記述
しない。インタ−ネットの設定など、必要な時はＩＰアドレスでアクセスすれば済むこと
であり、セキュリティの観点からもその方が望ましい。更に内部ネットワ−クのパソコン
などホストはＤＮＳ管理すべきかどうか。よい子のイントラネットでは、ずばり言うなら
ば必要なし。お互いに FQDN で識別しあうことはほとんど無いと言ってよい。イントラネ
ット用のＷＷＷサ−バにアクセスする場合だって、たくさん数がある訳でない、ＩＰアド
レスを指定すれば済むことである。
* ３台のホストによる相互バックアップ機構
それぞれがダウンした場合、全体の機能をなんとか保つようにする。例えばファイアウォ
−ルのホストがダウンした場合、残りの２つのホストのどれかにあらかじめフリ−のファ
イアウォ−ル・ソフトを設定しておき、直ちに代わりができるようにする。この場合のフ
ァイアウォ−ルのタイプは、フリ−ソフトでは実績のあるコネクションフィルタリング型
の、fwtk か socks を使うことになる。トラブル時の対応マニュアルをともかく整備する
ことが大切である。しかし、実際このような相互バックアップは難しいだろう。単純には
ＷＷＷサ−バなら古いマシンでいいから予備に仕立てておくのが現実的だろう。
* ３台のホストによるインタ−ネット接続口の典型例
CERN httpd 暗号化なし | インタ−ネットへ 64 or 128 Kbps 専用線
----- --------
|WWW| DNS |Router|
----- --------
| | バリアセグメント（バリアネット）
-------*-------*---------*------ nix.co.jj パブリックアドレス
|
------ ------
FireWall-1 |Gate| |Mail|
------ ------
| |
---------------*---------*------ 内部ネットワ−ク（内部ネット）
この構成で "イントラネット構築ベ−スキット" として、どこか販売する会社はないもの
か。自分で全部設定するのは、DNS や sendmail などを理解していても大変である。どの
企業でもインタ−ネットでやりたいことは同じである。それなら１つパタ−ンを用意して
おけば済むではないか。別途ご相談の必要はない。こういう構成なら幾らいうように提案
してもらいたい。キットの基本は例えば５００万円とする。ＷＷＷサ−バを暗号化対応に
したければ Netscape Commerce Server にして、プラス１００万円。ともかく値段は明示
すること。幾らなのかユ−ザ側で分からないのは、ホスト系の商売のやり方である。パソ
コンから叩き上げてきたパワ−ユ−ザには通用しない。どうも幾つかの会社からこのよう
なパッケ−ジが販売されているようだ。しかしどこまでやってくれるのか明記されていな
い。これでは困る、判断できない、つまり買うことはできない。
_____ ______
------------- ハブ|___| |____| <- モニタ切替え器(ディスプレイは１台でいい)
| | -------------
| | | | ・ホストの追加や、電子メ−ルのユ−ザを追
| | ------------- 加するためのマニュアルを提供。各サ−バ
| | | | が故障したときの対応マニュアルを提供。
------------- -------------
| |--------| ===== | ・CD-ROM は標準装備。DATはオプション装備。
--------- -------------
* 運用のプロバイダとの連携その期待 '96〜'97
何とかインタ−ネット接続口を設定したら、こんどは実際に運用していくことになる。こ
れは思ったよりも大変なことになる。ファイアウォ−ルに市販ソフトを使ったからといっ
て完全に安全な訳でない。ファイアウォ−ル関連のメ−リング・リストも入る、 CERT の
レポ−トもチェックするなど、常に情報収集をしなければならない。ソフトに欠陥が見つ
かった場合は、パッチもあてなければならない。バ−ジョンアップも必要だろう。自社へ
のファイアウォ−ルのアタックのログはどうする。毎日つぶさにチェックするのか。また
実質やれるのか。
ともかく管理者１人では、セキュリティを常に確保しながらの運用は非常に厳しい。そこ
でこれらの仕事をプロバイダが代理してくれたらと考える。ファイアウォ−ルの設置を今
はいろいろな会社がやってくれる。サ−ビスコ−ルも承りますといっているところもある。
しかしファイアウォ−ル・ソフトとハ−ド自体のトラブルに対応するだけであって、運用
面には言及されていない。多分そこらあたりの話しは別途相談ということになるのだろう。
そこでぜひプロバイダに "運用バックアップサ−ビス" を年間契約、先ず最低サ−ビスで
数十万円でやってもらいたい。
インタ−ネット接続口は、中小の企業ではほとんど同じでいいはずである。運用管理も同
じとみてよい。プロバイダ側でスクリプトを自動実行して、定期的に監視することは十分
可能なはずだ。若干のノウハウは必要だろうが、それが飯の種である。コンピュ−タ会社
やＳＩ業者では拠点がいかにも少ない。管理者ではどうにもならないトラブルが起きた場
合、すぐめんどうみてくれるところが必要である。いわばホ−ム・ドクタ−的な存在が安
定運用には必要とされるのだ。プロバイダなら全国網の目のようにあるのだから適任であ
る。また企業のイントラネットを本当に成功に導くためにも、プロバイダはやらなければ
ならない。
年間契約１０万円というのは、最低のサ−ビスで、ファイアウォ−ルの監視程度の内容に
なるだろう。メンテナンスの妥当な料金とは幾らぐらいになるのか。管理者はインタ−ネ
ットの仕組み、TCP/IP プロトコルの理解、ファイアウォ−ルの理解がまず必要で、 かつ
続々と出てくる技術、用語についていかなければならない。雑誌や本も一杯購読しなけれ
ばならない。しかし個人の時間を全て潰して勉強しても、追いつかないのが正直なところ
だろう。そう考えると、１人分の年収の半分か１／４位は出す価値は十分あるのでないだ
ろうか。年、数百万円ということになるが、あなたは家族を守るために、健康保険を一体
１年間に幾ら払っているのか。それを考えれば、決して高いとはいえない。
[ 運用バックアップサ−ビス ]
・ファイアウォ−ルのソフトに欠陥等が見つかった場合は、直ちにお知らせします。それ
に関係するセキュリティ情報を逐次ご連絡いたします。
・ファイアウォ−ルのログを遠隔操作によりチェックし、不正アクセスを報告いたします。
またご希望によりＷＷＷアクセスのログを、遠隔操作により集計し報告いたします。
・電子メ−ルの予備のサ−バを弊社に設けます。これにより貴社に設置したメ−ルサ−バ
に問題がおきても、電子メ−ル自体は保護されます。この電子メ−ルを読むには、弊社
のダイアルアップサ−ビスをご利用下さい。
・各サ−バの能力が適正かどうか、遠隔操作によりチェックいたします。
(2) ２つの推奨設計 '96
* インタ−ネット接続口の推奨設計
[ ＩＰアドレス変換機構を使った場合 ]
----- --------
|WWW| |Router|
----- --------
| | バリアネット
---------------*---------*------ nix.co.jj パブリックアドレス
| DNS
↑ ------ ------
ＩＰアド ｜ |Gate| |Mail|
レス変換 ↓ ------ ------
| | 内部ネット
---------------*---------*------ nix.co.jj プライベ−トアドレス
内部ホストのＩＰアドレスは、 ファイアウォ−ル・ソフトのプライベ−トアドレス <-->
パブリックアドレス変換機構を使って管理する。これにより内部ホストのＩＰアドレスは、
現状のままのプライベ−トアドレスをそのまま使うことができる。インタ−ネットに接続
するため社内のホストのＩＰアドレスを付け替えるのは大変な作業である。それにＩＰア
ドレスの枯渇の問題もあり、いつまた付け替えをせないかんか分からない。このやり方は
非常にネットワ−ク構成をシンプルに、そしてメンテナンスを簡単にできる可能性がある。
大いに検討すべきである。パケットフィルタリング型のファイアウォ−ルでＩＰアドレス
変換機構があるソフトには FireWall-1 Ver.2.0 がある。
ＷＷＷホストをファイアウォ−ルの内側に置けないものか考えてみた。ＩＰアドレス変換
により、見かけ上バリアネットに置けばいいのでないかと考えたのである。しかし所詮内
側においていることは変わりない。ＩＢＭの人など何人かと議論した末、セキュリティ上
やはり問題があるのでないかという結論になった。 FireWall-1 のドキュメントには内側
にＷＷＷを置くことも可能だと書いてある。FireWall-1 は RPC でさえも問題なくフィル
タリングするのだから、大丈夫だとは思うのだが。もし外側に置くとなると、ＷＷＷの内
容更新のため内部ネットのホストと FTP や Telnet をすることになる。 ＷＷＷホスト自
身のセキュリティ対策に十分注意しなければならない。
--------------------------------------------------------------------------------
"３．イントラネットの基本構築" はこのＩＰアドレス変換機構を用いた構成を採用する。
--------------------------------------------------------------------------------
[ 単一スプリットドメイン構成 ]
| インタ−ネットへ
----- --------
|WWW| DNS |Router|
----- --------
| | バリアネット
-------*-------*---------*------ nix.co.jj パブリックアドレス
|
パケットフィ ↑ ------ ------ DNS
ルタリング型 ｜ |Gate| |Mail|
↓ ------ ------
| | 内部ネット
---------------*---------*------ nix.co.jj パブリックアドレス、サブネット
パケットフィルタリング型のファイアウォ−ルを設置する場合、内部ネットをサブドメイ
ン構成にするか単一スプリット・ドメイン構成にするかどちらかである。ただしクラスＣ
のＩＰアドレスでのサブドメイン構成というのは非常にやっかいである。そのため実際に
とれるのは単一スプリット・ドメイン構成だろう。問題点としては内部ネットからインタ
−ネットにアクセスしようとすると、ホストの認証を求められる場合が最近でてきたこと
である。この場合相手側が自社のＤＮＳに確認してくる。 そうなると WWW のＤＮＳには
内部ネットのホスト情報を全て載せる必要がでてくる。単一スプリット・ドメイン構成は
元々、内部のホスト情報を不必要に外部から見れないようにするテクニックであった。
しかしあまりこのことは神経質にならなくていいかも知れない。例えば内部のホスト名等
が分かったとしても、アクセスできないように保護すればいいだけのことである。それに
クラスＣであれば、容易に内部ホストのＩＰアドレスは想像がつくし、ドメイン名が分か
らないようにするだけではあまり意味がないとも言える。しかしこうしたこと以上に、実
質的にこのネットワ−ク構成を取ることはできないだろう。クラスＣのパブリックなＩＰ
アドレスを２つ取得することは、多分もうできないからである。単一スプリットドメイン
構成の設定例は "3-2. ネットワ−クの詳細設定 (5)" を参照のこと。
* FireWall-1 によるＩＰアドレスの変換
ゲ−トウェイのホストに FireWall-1 Ver.2.0 を搭載すると、ＩＰアドレスの変換ができ
るようになる。FireWall-1 に内部ホストのＩＰアドレスと、 バリアネット上の仮想ＩＰ
アドレスの対応表をもたせる。この表により外部から見ると、内部ホストはあたかもバリ
アネット上に存在しているかのように見えることになる。または１つのパブリックアドレ
スからの発信に見せかけることもできる。 このＩＰアドレスの変換技術は、RFC 1631 の
NAT( Network Address Translator ) として定められている。
----- --------
| | |Router|
----- --------
| |
-------*-------*--------*------------ バリアネット、パブリックアドレス
| FireWall-1 Ver.2.0
↑ ------ ----- -----
ＩＰアド ｜ |Gate| | A | | B |
レス変換 ↓ ------ ----- -----
| | |
-------*---------*-------*--- 内部ネット、プライベ−トアドレス
‖
----- -------- ----- ----- 単純には同一セグメントに並ん
| | |Router| | A | | B | でいるとみなすことができる。
----- -------- ----- -----
| | | |
-------*-------*--------*----------*-------*--- バリアネット
|
------
|Gate|
------
９６年初めぐらいのファイアウォ−ル・ソフトでは、ＩＰアドレス変換機構はまだ特殊な
技術という感じで、 FireWall-1 Ver.2.0 と BorderWare ぐらいにしか入っていなかった。
その当時、インタ−ネット接続のためのネットワ−ク設計に着手していたのだが、多分こ
れからは、ＩＰアドレス枯渇の問題とも絡んで、この技術を使うしかないという気がした。
それから１年以上経って、あらためて見てみると大方のファイアウォ−ル・ソフト、それ
にル−タまでもＩＰアドレス変換をサポ−トしてきている。読みは当たった。
(3) インタ−ネット接続口の種類 '96
* 接続口の種類
[ コネクションフィルタリング型 ]
ＩＰパケットを通さない---- a. ＩＰアドレスを変換しない
|- b. ＩＰアドレスを変換する ( ex. BorderWare )
[ パケットフィルタリング型 ]
ＩＰパケットを通す ------- c. ＩＰアドレスを変換しない
|- d. ＩＰアドレスを変換する ( ex. FireWall-1 )
< a, b タイプ共通 >
| インタ−ネットへ
----- --------
|WWW| DNS |Router|
----- --------
| | バリアネット、パブリックアドレス 以下同じ
-------*-------*--------*------- nix.co.jj
|
↑ ------ ------ /etc/hosts 管理でもよい
代理応答 × |Gate| |Mail|
↓ ------ ------
| | 内部ネット
-------*---------*------ プライベ−トアドレスでよい。
内部ホストから外部へのアクセスは、 Gate のバリアネット側のＩＰアドレスからのアク
セスになるため、内部ネットのＩＰアドレスはパブリックでもプライベ−トでも関係ない。
< c タイプ >：単一スプリットドメイン構成
----- --------
|WWW| DNS |Router|
----- --------
| |
-------*-------*---------*------ nix.co.jj
|
↑ ------ ------ DNS
｜ |Gate| |Mail| 単一スプリットドメイン構成
↓ ------ ------
| | サブネット分割して
-------*---------*------ nix.co.jj パブリックアドレスをつける。
クラスＣでパケットフィルタリング型にする場合は、これが一般的である。
< c タイプ >：サブドメイン構成
----- --------
|WWW| DNS |Router|
----- --------
| |
-------*-------*---------*------ nix.co.jj
|
↑ ------ ------ DNS
｜ |Gate| |Mail|
↓ ------ ------
| | サブネット分割して
-------*---------*------ sub.nix.co.jj パブリックアドレスをつける。
クラスＣではＤＮＳの設定が非常にややこしくなる。お勧めでない。
< d タイプ >
----- --------
|WWW| DNS |Router|
----- --------
| |
-------*-------*---------*------ パブリックアドレス nix.co.jj
|
ＩＰアドレス↑ ------ ------ /etc/hosts
の変換をする｜ |Gate| |Mail|
↓ ------ ------
| |
-------*---------*------ プライベ−トアドレスでよい。
b タイプとよく似ている。 Gate で代理応答するか、ＩＰアドレスを変換するかの違いで
ある。多分このタイプがパフォ−マンス的にも、安全面でもメンテナンスの容易さでも優
れていると思われる。このタイプでは WWW ホストをメ−ルリレ−、Mail ホストをメ−ル
サ−バとする構成がある。それとメ−ルリレ−なしで、 Mail ホストをメ−ルサ−バにす
る構成がある。後者の場合、Mail ホストはＤＮＳの MXレコ−ドで認識できる必要がある
ので、ＩＰアドレス変換により、仮想的にパブリックアドレスにおくことになる。
* 接続口のその他
< 最も単純なやり方 >
| インタ−ネットへ
-------- ------
|Router| |WWW|
-------- -----
| |
------*------------*-------- nix.co.jj パブリックアドレス
ル−タでパケットフィルタリングしておしまいという構成である。ル−タでのパケットフ
ィルタリングのル−ルの設定によくよく注意すれば、これだけも構わない。ル−タでのル
−ル設定は普通コマンドで行う。エラ−メッセ−ジや警告はあまり出ないものが多いので
十分注意したい。
< 一応ファイアウォ−ルを使うやり方 >
Fig. 211
上記やり方に Fire ホストを設け、ファイアウォ−ルを設定する。そして外から入ってき
たパケットをル−タの次に Fire へ送るように設定する。これによりゲ−トウェイ構成で
なくてもファイアウォ−ルを設置できる。問題は経路制御を一つ間違えると、全くセキュ
リティ対策にならないことである。実際このような構成はとられることはない。
(4) より安全な構成とウィルス対策
* 新しいやり方 DMZ 構成 '96
-------- ファイアウォ−ル・ソフトの FireWall-1、Cyber
|Router| Guard FireWall、 BorderWare Firewall Server、
-------- Public IP Address SunScreen SPF-100G でこのような構成にするこ
| バリアネット とができる。ほとんど９６年になって出てきたや
------*------*--------- り方である。WWW ホストをバリアネット上でなく、
| ファイアウォ−ルで保護された DMZ におくこと
| ----- DNS ができる。WWW ホストを裸のままバリアネットに
| |WWW| Mail 置くよりは安全になる。
| -----
ＩＰアド ------ | DMZ( DeMilitalized Zone ) は非武装セグメント
レス変換 |Gate|-----*---- DMZ と呼ばれ、バリアセグメントと混同されるみたい
------ Public IP Address だが、 Gate ホストの３つ目のセグメントである。
| ＥＷＳではあまりお目にかからないネットワ−ク
-------------*--------- だが、ル−タではネットワ−クボ−ドを何枚も入
｜ ｜ Private IP Address れて使うことは珍しくない。
□ □
Gate ホストにはファイアウォ−ルのソフトが入っている。WWWホストにアクセスするには、
インタ−ネット側からも内部ネット側からも、ファイアウォ−ルを経由するということで
ある。この DMZ 構成、直感的にやや分かりにくい面もあるが、 かなり安全な形態である。
Gate に FireWall-1 を使う場合の構成をもう少し考えてみる。DMZのネットワ−クアドレ
スはどうなるか。WWW ホストではＤＮＳやメ−ルサ−バを稼働させることから、パブリッ
クなＩＰアドレスを振るのが自然である。しかし、今日割り当てられるＩＰアドレスはク
ラスＣのサブネット分割の、６個だけなどという具合である。これではパブリックアドレ
スを振ることはできない。それでプライベ−トアドレスを振っておき、仮想ＩＰアドレス
のテクニックでもって、バリアネットに WWW ホストがあるように見せかけることになる。
* DMZ の変則テクニック `21/06
割り当てＩＰアドレスが全体で８個しかない場合、DMZ 構成にする方法である。正攻法で
はネットワ−ク分割はできないので、そもそも DMZ にはできない。 しかし SOHO 向けの
ファイアウォ−ルを見ていたら、それができるのである。DMZ ネットのセグメントもバリ
アネットのセグメントと同じＩＰアドレスで構成するようになっている。 SonicWall Pro
やジュピタ−テクノロジ−(株)の InstaGate EX2 が対応している。さらに SonicWall で
確認したことだが、リダイレクション機能というのもあって、DMZ または内部ネットのホ
ストのＩＰアドレスを、ファイアウォ−ルの外側ＩＰアドレスに対応付けることができる。
つまり http://192.9.200.10/ とアクセスしたら http://192.9.200.11/ になるという機
能である。FireWall-1 ではこのような機能はないように思う。
□ Router
｜.9
-------*---------------------- 192.9.200.8 netmask 255.255.255.248
.10| □ WWW □ DNS
------ ｜.11 ｜.12
|Gate|------------------- 192.9.200.8 netmask 255.255.255.248
------
|
-------*---------------------- 192.168.1.0 netmask 255.255.255.0
192.9.200.8 はネットワ−クアドレスを表わす。 ネットマスク値は 255.255.255.248 で
fffffff8。ブロ−ドキャストアドレスは 255.255.255.15 で ffffff0f となる。有効なホ
ストアドレスは 192.9.200.9〜14 の６個となる。
* コンピュ−タ・ウィルス対策 `22/02
[ メ−ルだけのウィルスチェック ] InterScan を使う場合
↑ Mail Relay Mail Relay
-------*--- MX ↓ ｜ ↑
| □ Mail Relay -----↓-------- -----｜--------
------ ｜ ↑ | [InterScan] | | [sendmail] |
|Gate|----- ↓ 拡大図 | ↓ | | ↑ |
------ □ Mail <---- | [sendmail] | | [InterScan] |
| ｜ Server -----↑-------- -----↑--------
-------*-------------------- POP でメ−ルを取る SMTP でメ−ルを出す
[ HTTP/SMTP/FTP のウィルスチェック ] InterScan を使う場合
-------*-------- Gate のファイアウォ−ルには FireWall-1を使う。
↓ | InterScan は FireWall-1 と連携できるようにな
--------------- っている。 FireWall-1 に入ってきたパケットを
| Fir Int | Gate InterScan が横取りし、ウィルスをチェックしま
| eWa <-> erS | た FireWall-1 に返す。2001/02 この設定はその
| ll-1 can | 時点ではまだ実際できなかった。
--------------- □ Mail
↓ | ｜ Server ※ Mail Relay がある場合もあり。
-------*------------------
[ メ−ルだけのウィルスチェック ] WebShield を使う場合 ※ メ−ルは POP3 にも
対応する。
↑ ↑
-------*--- MX ↓ ------*--- MX ↓
| □ Mail Relay | □ Web ←→ □ Mail
------ ｜ ↑ ------ ｜ Shield ｜ Server
|Gate|----- ↓ |Gate|--------------------
------ □ Web ←→ □ Mail ------
| ｜ Shield ｜ Server |
-------*--------------------------- ------*------------------
メ−ルリレ−構成の場合 メ−ルサ−バのみの構成
[ HTTP/FTP のウィルスチェック ] WebShield を使う場合
※ SMTPのメ−ルについ
-------*--- ------*--- ては上のやり方を合
| | わせてチェックする。
------ ｜ Proxy ------
|Gate| ↓ Server Client |Gate| ↓
------ □ Web ← □ ← □ ------ □ Web ← □ Client
| ｜ Shield ｜ ｜ | ｜ Shield ｜
-------*--------------------------- ------*-----------------------
Proxy Server がある場合 WebShield のホストを Proxy にする
WebShield はウィルスチェック専用のアプライアンス製品である。e500 Appliance は 1U
ラック製品で以前からある。お値段は２７５万円。ハ−ドウェアをスペック・ダウンした
e250、１７５万円というのも 2001/12 に出ている。どちらもＯＳは Linux である。ライ
センス数は無制限である。しかし、ちょっと高い気がせんでもないが。この WebShieldの
設置の仕方、雑誌など見るとファイアウォ−ル直下に、ブリッジ装置みたいにポッとおく。
そんな風に絵が描かれているような気がしたので、調べてみたのだ。もし、それなら簡単
に使えるなと思ったのだが、残念でした。むしろ InterScanより、ネットワ−クに関して
の設定はややこしい。InterScan は FireWall-1 との連携がうまくできさえすれば、HTTP
/SMTP/FTP パケットをチェックできる。 多分 FireWall-1 アプライアンスの NOKIA なら
連携もできるようになっているだろうし、HTTP/SMTP/FTP パケット全部でも、チェックす
る能力が十分あるのでないかと思う。WebShield のメリットはウィルスチェックのスル−
プットが高いとうたっていること、ライセンス数が制限されていないことである。
(5) Proxy/Cache も使った設計 `21/03
* 概要
Proxy というのは、本来の意味は代理である。代わって処理をするサ−バをプロキシ・サ
−バというのである。これをファイアウォ−ルの場所におけば、代理応答による中継サ−
バとなり、つまりファイアウォ−ルとしての働きをすることになる。それに同時にＩＰア
ドレスの変換を行っていることになる。あるいは内部ネットワ−クの適当なところにおき、
これを中継してインタ−ネットにアクセスすることもできる。どちらの場合でも、外部へ
のアクセスはこのプロキシ・サ−バを経由し、プロキシ・サ−バのホストがインタ−ネッ
トにアクセスし、そのデ−タをこのホストにもってきて、クライアントのホストがそのデ
−タ取り込むという流れになる。この時、プロキシ・サ−バにアクセスしたデ−タをため
ておき、他のクライアントからのアクセスに供すれば効率がいいではないか。これがプロ
キシ・サ−バのキャッシュ・サ−バとしての働きとなる。
ソフトウェアとしては、フリ−ソフトに Squid, Delegate, Apache Proxy, CERN Proxyが
ある。よく使われるのは Squid のようである。市販品ソフトにはNetscape Proxy Server
がある。ソフトウェアでなく専用ＯＳを搭載した箱型の製品には NetCache や CacheFlow
というのがある。この他パソコンメ−カが出しているのもあるにはある。 NetCache など
専用装置の一番安いのが約１００万円である。Linux などのマシンで、キャッシュ・サ−
バを設置しようとすれば、多分これ専用に使うことになるだろう。Linux マシン安く作れ
ば２０万円程度でできるかも知れないが、そこそこ市販のマシンを買うとなれば５０万円
ぐらいは見た方がいいだろう。Sun Ultar10 相当になるかな。そう考えれば、もう少しお
金出してばかちょんで設置できる NetCache なんかを選ぶ方がいいと思うが、いかが。で
もばかちょんといえども、業者さんに設定をやってもらったら３〜４０万円いるのだが。
* キャッシュ・サ−バを使ったインタ−ネット接続口の設計
予算との兼ね合いも考えれば、 NetCache など１００万円程度の専用キャッシュ・サ−バ
の装置を通常型で設置するのが現実的だろう。できれば Netscape Navigator などクライ
アントの設定をいじらなくても済む、透過的なプロキシ・サ−バとして設置ができれば望
ましいが。そのためには Layer 4 Switch をかまし、パケットを振り分けるような構成が
必要がある。Layer 4 Switch はつい最近出たネットワ−ク装置で、 まだあまり使用はお
勧めできないような気がする。負荷分散型の構成と言うのは、結構トリッキ−な構成であ
る。キャッシュ・サ−バの装置自体、結果的にファイアウォ−ル的な働きもするというこ
とで、このような構成も採れるということらしい。ファイアウォ−ルとキャッシュ・サ−
バを並列に設置して、キャッシュ・サ−バは TCP/80 ポ−トのパケットを通し、他のパケ
ットはこれまで通りファイアウォ−ルを通すのである。
□ WWW ◇ Router □ ◇ □ ◇
｜ ｜ ｜ ｜ ｜ ｜
------------ 1 ------------ 1 -------------- 1 セグメントの番号
｜ (WWW) 1｜ (WWW) 1｜(WWW) ｜1
FireWall □…… 2 □…… 2 □…… 2 ■ Cache Server
｜ ■ Cache 3｜ 3｜ ｜3
｜ ｜ Server 〓---■ ----------
----------- 3 3｜ 3｜
---------- 3 〓 Layer4 Switch
3｜
---------- 3
[a] 通常型 [b] 透過型 [c] 負荷分散型
実は今、通常型でキャッシュなしでプロキシ・サ−バとして INDY で Apache を稼働させ
ている。ファイアウォ−ルを通過するパケットのＩＰアドレスを、プロキシ・サ−バのホ
ストＩＰアドレスからにするためである。これはネットワ−ク管理をできるだけ楽にする
ための措置でもある。一般ユ−ザの Windows パソコンの Netscape Navigator等で、この
INDY を Proxy サ−バ指定する。 こうすると Netscape Navigator での DNS の名前解決
をプロキシ・サ−バが代理でやってくれるようになる。 Netscape Navigator では Proxy
サ−バの指定をすると、DNS サ−バの指定はしても関係なくなる。つまりプロキシ・サ−
バを設けると HTTP のパケットだけでなく、DNS/TCP パケットもプロキシ・サ−バのホス
トを経由することになる。ファイアウォ−ルのル−ル設定をする際に覚えておこう。
* リバ−ス・キャッシュの利用 `22/11
リバ−ス・キャッシュのサ−バは、先ずは外部からＷＷＷサ−バへのアクセスを速くする
のに使われる。Ｗｅｂアクセラレ−タとも呼ばれる。外向けのＷＷＷサ−バとは別にキャ
ッシュ・サ−バを設置し、ここにＷＷＷサ−バのデ−タをコピ−する。キャッシュ・サ−
バはそれ用に特化した装置であり、セキュリティホ−ルが少ないといえる。汎用的なマシ
ンにＷＷＷサ−バを設定するよりも、安全性は高い。自社内にキャッシュサ−バを設置す
る場合は、ＷＡＮル−タとファイアウォ−ルの間に置くのが一般的である。リバ−ス・キ
ャッシュという用語に対して、内部に置くキャッシュ・サ−バはフォワ−ド・キャッシュ
と呼ばれる。以下、リバ−ス・キャッシュをサ−ビスする会社を紹介しておく。
(株)リフレクション http://www.reflection.co.jp/ のウェブ・リフレクションのサ−ビ
ス。ホ−ムペ−ジの案内によれば、リバ−ス・キャッシュと DNSの動的切替により、お客
様の運用するＷＷＷサ−バの負荷を肩代りいたします。２０００年の４月頃から、中部地
区でサ−ビスを展開している。
これもそういうようなサ−ビスかな。KDDI の Web アクセラレ−ションサ−ビス。試験運
用を２００２年６月から８月末まで無料でやっていた。CGI や SSL は除く。 高速インタ
−ネット・バックボ−ンにキャッシュ・サ−バを接続するサ−ビス。今は有料になってい
る？。他のプロバイダも始めているようだが、サ−ビスとしては目立ったものではない。
--------------------------------------------------------------------------------
外からＷＷＷサ−バへアクセスしに来たパケットをどうやって、キャッシュ・サ−バに振
り向けるのか。これには、ル−タやレイヤ３スイッチのポリシ−ル−ティング機能、レイ
ヤ４スイッチを用いる、またはＷＷＷサ−バのリダイレクション機能を用いると、どこか
雑誌に書いてあった。いや、基本的にはキャッシュ・サ−バだから、DNS でＷＷＷホスト
名のＩＰアドレスをキャッシュ・サ−バにするのが、そもそものやり方だろう。リバ−ス
キャッシュは、外部のユ−ザに対して、自社のＷＷＷサ−バとしてアクセスしているよう
に見せかける。フォワ−ドキャッシュでは自分のＷＷＷブラウザで、プロキシサ−バを指
定して利用する違いがある。ちなみにポリシ−ル−ティングとは、対象とするＩＰアドレ
スのポ−ト番号のパケットを、指定のＩＰアドレスのマシンに転送するという機能である。
ネットワ−クに複数の経路がある場合に HTTP はこっち、FTP はそっちの経路ということ
ができる。このような制御はル−タやレイヤ３スイッチのアクセスリストの設定で行う。
--------------------------------------------------------------------------------
* ウェブリフレクションというサ−ビス `23/05
／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣＼
＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／インタ−ネット
： ：
：高速ライン ：低速ライン
デ−タセンタ− ： ：
----------------：---------- ： www.nix.co.jj
| ： | □ ■ 仮想ＩＰ
| ◇ DNS □ Router | ｜ ｜101
| ｜ ｜ | ------------------ nix.co.jj
| ------------------- | ｜
| Cache ｜ | ｜ ■ WWW, DNS, Mail-Relay
| ◆ (WWW) □ FireWall | ｜ ｜
| ｜102 ｜ | □ □--------
| ------------------- | ｜ ｜FireWall
---------------------------- ------------------
iDC( Internet Data Center ) Mail-Store
サ−ビスには３つある。リバ−スキャッシュ、冗長性確保、安全性確保、負荷分散である。
基本はリバ−スキャッシュのサ−ビスである。社内のＷＷＷサ−バにキャッシュ・サ−バ
を置いたのと同じようなことである。 仮に自社のＷＷＷホストのＩＰアドレスを 101 番
とする。リフレクションの自社サイト用のＷＷＷサ−バのホストを 102 番とする、 実は
これはＷＷＷサ−バではなくキャッシュ・サ−バである。 どうも Squid のようなキャッ
シュ・サ−バのソフトがサ−ビスの実態である。リバ−スキャッシュのサ−ビスを利用す
るには、自社の DNS サ−バのエントリを次のように変更することになる。
自社の DNS サ−バで IN A www.nix.co.jj 101 --> 102 とする。
これで、インタ−ネット上で www.nix.co.jj にアクセスしようとすると、 リフレクショ
ンのキャッシュ・サ−バにアクセスする。コンテンツがキャッシュされていれば、そこか
ら返す。なければ 101 番のホストにアクセスする。 いったんアクセスされたのはキャッ
シュ・サ−バに溜められるという仕組みである。次、同じコンテンツにアクセスしたユ−
ザは高速のバックボ−ンを通って、素早い応答を受けられるというわけである。ただ DNS
の１次ネ−ムサ−バは相変わらず自社の中にあるので、ユ−ザは最初に自社ホスト名から
ＩＰアドレスを検索するのに低速ラインを通るので、このアクセスは遅いままである。
それならば DNS サ−バもデ−タセンタ−に置いたら早くなるのでないか。自社の DNS の
１次ネ−ムサ−バをリフレクションで管理してもらうのである。万が一、デ−タセンタ−
側のキャッシュ・サ−バが止まったら、 ここの DNS は自動的に、www.nix.co.jj を 101
番にする。リフレクションが独自に考案した DNS の動的切替という機能らしい。 これで
冗長性の確保を行う。さらに、デ−タセンタ−に複数キャッシュ・サ−バを置いて、ラウ
ンドロビン？により負荷分散すると言ったことも可能とのことである。これまでのところ
DNS まで預かってもらうユ−ザは、まだあまりいないようである。
[ メモ ]
たまにしかアクセスのないコンテンツは、いったんキャッシュ・サ−バを経由するので却
って遅くなる。そうしたコンテンツ部だけをホスティングするか、社内にそれ用のＷＷＷ
サ−バを別に設けてキャッシュを通さないようにするかである。でもそんな遅いと体感で
きる程、遅くなることはないと思う。
リバ−スキャッシュのサ−ビスは、ホスティングよりも安い料金に設定しているとのこと。
つまり全部のコンテンツをデ−タセンタ−のサ−バに入れるわけではない、キャッシュの
サ−バ用のディスクの分しかないわけだから。ホスティングもやっている。それも他社よ
り２／３ぐらいの料金にしているとのことである。
デ−タセンタ−側を代理応答サ−バと呼んでいる。元のＷＷＷサ−バと同期をとると説明
しているが、ちょっとおかしい。同期なんか取ったりしていない。キャッシュ・サ−バの
機能により、コンテンツをキャッシュするというだけの話である。
コンテンツは静的なものしか今のところ扱えない。著名なカウンタ−のプログラムぐらい
は用意するとはいっていたが、キャッシュ・サ−バにそんなのを用意できるのかな。キャ
ッシュ・サ−バはファイアウォ−ルで保護されている。許可パケットは HTTP だけである。