２．インタ−ネット接続 2-1. インタ−ネット接続口の設計 '96 (1) 設計の基本方針を決める * ファイアウォ−ルの設置 -------------------------------------------------------------------------------- ＷＡＮ接続のル−タとゲ−トウェイのホストでパケットフィルタリングをする。 -------------------------------------------------------------------------------- 内部ネットワ−クのホストを外部の不正アクセスから保護する。このため外部と内部ネッ トワ−クの間にゲ−トウェイ・ホストをおき、このホストに市販のファイアウォ−ル・ソ フト FireWall-1 を設置する。 FireWall-1 は基本的にはパケットフィルタリング型のフ ァイアウォ−ルである。fwtk などのフリ−ソフトを使う手もあるが、 コンパイルしたり 色々設定しなければ使えない。８０万円出しても市販品を使う方が手間も省け安全である。 それとインタ−ネット接続の実際の口となるＷＡＮル−タでも、パケットフィルタリング して不正アクセスを侵入させないようにする。二重のプロテクションをかける。 * 電子メ−ルサ−バのホスト -------------------------------------------------------------------------------- メ−ルサ−バはゲ−トウェイの内側におき、メ−ル・アドレスを集中管理する。 -------------------------------------------------------------------------------- バリアセグメントのホストにおいた場合、ル−タのファイアウォ−ルを破られたら外部か ら電子メ−ルを見られる可能性がある。より安全のためゲ−トウェイのファイアウォ−ル の内側にサ−バをおいた方がよい。それにバリアネットのホストに置くとなるとＷＷＷサ −バとホストを兼任させることになる。電子メ−ル、ＷＷＷのアクセスは余裕をもって対 処させたい。更にもう一つの理由として、内部ホスト間の電子メ−ルのサ−バとしても使 いたい。それには内部ホストを管理するためのＤＮＳまたは /etc/hosts ファイルを、ゲ −トウェイの内側に置くため、同時に電子メ−ルのサ−バも内側におく必要がある。 * ゲ−トウェイのホスト -------------------------------------------------------------------------------- ゲ−トウェイのファイアウォ−ル機能を持たせるホストは、専用ホストとする。 -------------------------------------------------------------------------------- ファイアウォ−ルは確実性が重要であり、安定して稼働することが大事である。ゲ−トウ ェイのホストにはメ−ルサ−バやシステムのログなど、時事変化するようなものは基本的 には置かないようにする。ファイアウォ−ルのログでも、できれば内部ネットの管理者用 コンピュ−タに送るとかした方が本当はいいだろう。それにプログラムの開発なども行わ ないようにする。社内のプリンタサ−バを兼用させるようなこともしない。どんなことで ファイアウォ−ルがダウンするかわからない。その危険性を避けるためである。ともかく このホストは、社内ネットワ−クを守る要である。ファイアウォ−ルとしての機能に特化 することが望ましいというか、むしろ必須である。 * 外部向けＷＷＷサ−バのホスト -------------------------------------------------------------------------------- 外部向けＷＷＷサ−バのホストは専用ホストとする。 -------------------------------------------------------------------------------- 考えるべきことは一つ。ファイアウォ−ルの外側におくか内側におくかである。一般的に は外側におく場合が多い。外側におく場合ＷＷＷホストを保護するために、ル−タでパケ ットフィルタリングをする、ホスト自身にセキュリティ対策を施すことが必要である。内 側におく場合はファイアウォ−ルで保護することができる。しかし外部からのパケットが 内部ネットにあるＷＷＷホストまで来るのを許すことに変わりない。 危険な cgi-bin プ ログラムが放置されていたりすれば、致命的なセキュリティ問題になる。ただ内側におく 構成は、ファイアウォ−ルをパケットフィルタリング型にした場合だけ可能である。 * ネットワ−クの監視 -------------------------------------------------------------------------------- ネットワ−クを監視するホストを内部ネットに１台おく。 -------------------------------------------------------------------------------- ネットワ−クの管理者を netmasterというユ−ザにし、ＤＮＳや電子メ−ルの管理者とす る。ホストは電子メ−ルサ−バのホストと兼用でもいいだろう。これでインタ−ネット接 続ための基本構成はＷＷＷ用、ゲ−トウェイ用、電子メ−ル用で３台のホストとなる。外 部からの攻撃に対し、ル−タやファイアウォ−ルの一般的なログはとらない。取ったとこ ろで管理者１人ではチェックすることはできない。特にル−タのログは取ると膨大なもの になり、何らかの解析ソフトが必要になるだろう。しかしファイアウォ−ルのクリティカ ルなログは、できればチェックしたい。ＷＷＷのログはコンテンツ・アクセスの分析には いいが、１人ではそこまではできない。 * ホスト名解決について Sun ＥＷＳ特有のホスト名解決 NIS はインタ−ネット接続口の３台では使わない。NISは セキュリティホ−ルになり易い。これら３台で使う必要は特にない。それにゲ−トウェイ のホストやル−タはＤＮＳ管理はしない。つまり自社用のネ−ムサ−バにエントリを記述 しない。インタ−ネットの設定など、必要な時はＩＰアドレスでアクセスすれば済むこと であり、セキュリティの観点からもその方が望ましい。更に内部ネットワ−クのパソコン などホストはＤＮＳ管理すべきかどうか。よい子のイントラネットでは、ずばり言うなら ば必要なし。お互いに FQDN で識別しあうことはほとんど無いと言ってよい。イントラネ ット用のＷＷＷサ−バにアクセスする場合だって、たくさん数がある訳でない、ＩＰアド レスを指定すれば済むことである。 * ３台のホストによる相互バックアップ機構 それぞれがダウンした場合、全体の機能をなんとか保つようにする。例えばファイアウォ −ルのホストがダウンした場合、残りの２つのホストのどれかにあらかじめフリ−のファ イアウォ−ル・ソフトを設定しておき、直ちに代わりができるようにする。この場合のフ ァイアウォ−ルのタイプは、フリ−ソフトでは実績のあるコネクションフィルタリング型 の、fwtk か socks を使うことになる。トラブル時の対応マニュアルをともかく整備する ことが大切である。しかし、実際このような相互バックアップは難しいだろう。単純には ＷＷＷサ−バなら古いマシンでいいから予備に仕立てておくのが現実的だろう。 * ３台のホストによるインタ−ネット接続口の典型例 CERN httpd 暗号化なし | インタ−ネットへ 64 or 128 Kbps 専用線 ----- -------- |WWW| DNS |Router| ----- -------- | | バリアセグメント（バリアネット） -------*-------*---------*------ nix.co.jj パブリックアドレス | ------ ------ FireWall-1 |Gate| |Mail| ------ ------ | | ---------------*---------*------ 内部ネットワ−ク（内部ネット） この構成で "イントラネット構築ベ−スキット" として、どこか販売する会社はないもの か。自分で全部設定するのは、ＤＮＳや sendmail などを理解していても大変である。ど の企業でもインタ−ネットでやりたいことは同じである。それなら１つパタ−ンを用意し ておけば済むではないか。別途ご相談の必要はない。こういう構成なら幾らというように 提案してもらいたい。キットの基本は例えば５００万円とする。ＷＷＷサ−バを暗号化対 応にしたければ Netscape Commerce Server にして、プラス１００万円。ともかく値段は 明示すること。幾らなのか分からないのは、ホスト系商売のやり方である。パソコンから 叩き上げてきたパワ−ユ−ザには通用しない。どうも幾つかの会社からこのようなパッケ −ジが販売されているようだが、どこまでやってくれるのか明記されていない。それに信 用できるかどうかも判断できない。これでは困る、つまり買うことはできない。 _____ ______ ------------- ハブ|___| |____| <- モニタ切替え器(ディスプレイは１台でいい) | | ------------- | | | | ・ホストの追加や、電子メ−ルのユ−ザを追 | | ------------- 加するためのマニュアルを提供。各サ−バ | | | | が故障したときの対応マニュアルを提供。 ------------- ------------- | |--------| ===== | ・CD-ROM は標準装備。DATはオプション装備。 --------- ------------- * 運用のプロバイダとの連携その期待 '96〜'97 何とかインタ−ネット接続口を設定したら、こんどは実際に運用していくことになる。こ れは思ったよりも大変なことになる。ファイアウォ−ルに市販ソフトを使ったからといっ て完全に安全な訳でない。ファイアウォ−ル関連のメ−リング・リストも入る、 CERT の レポ−トもチェックするなど、常に情報収集をしなければならない。ソフトに欠陥が見つ かった場合は、パッチもあてなければならない。バ−ジョンアップも必要だろう。自社へ のファイアウォ−ルのアタックのログはどうする。毎日つぶさにチェックするのか。また 実質やれるのか。 ともかく管理者１人では、セキュリティを常に確保しながらの運用は非常に厳しい。そこ でこれらの仕事をプロバイダが代理してくれたらと考える。ファイアウォ−ルの設置を今 はいろいろな会社がやってくれる。サ−ビスコ−ルも承りますといっているところもある。 しかしファイアウォ−ル・ソフトとハ−ド自体のトラブルに対応するだけであって、運用 面には言及されていない。多分そこら辺りの話は別途相談ということになるのだろう。そ こでぜひプロバイダに "運用バックアップサ−ビス" を年間契約、先ず最低サ−ビスで数 十万円でやってもらいたい。 インタ−ネット接続口は、中小の企業ではほとんど同じでいいはずである。運用管理も同 じとみてよい。プロバイダ側でスクリプトを自動実行して、定期的に監視することは十分 可能なはずだ。若干のノウハウは必要だろうが、それが飯の種である。コンピュ−タ会社 やＳＩ業者では拠点がいかにも少ない。管理者ではどうにもならないトラブルが起きた場 合、すぐめんどうみてくれるところが必要である。いわばホ−ム・ドクタ−的な存在が安 定運用には必要とされるのだ。プロバイダなら全国網の目のようにあるのだから適任であ る。また企業のイントラネットを本当に成功に導くためにも、プロバイダはやらなければ ならない。 年間契約１０万円というのは、最低のサ−ビスで、ファイアウォ−ルの監視程度の内容に なるだろう。メンテナンスの妥当な料金とは幾らぐらいになるのか。管理者はインタ−ネ ットの仕組み、TCP/IP プロトコルの理解、ファイアウォ−ルの理解がまず必要で、 かつ 続々と出てくる技術、用語についていかなければならない。雑誌や本も一杯購読しなけれ ばならない。しかし個人の時間を全て潰して勉強しても、追いつかないのが正直なところ だろう。そう考えると、１人分の年収の半分か１／４位は出す価値は十分あるのでないだ ろうか。年、数百万円ということになるが、あなたは家族を守るために、健康保険を一体 １年間に幾ら払っているのか。それを考えれば、決して高いとはいえない。 [ 運用バックアップサ−ビス ] ・ファイアウォ−ルのソフトに欠陥等が見つかった場合は、直ちにお知らせします。それ に関係するセキュリティ情報を逐次ご連絡いたします。 ・ファイアウォ−ルのログを遠隔操作によりチェックし、不正アクセスを報告いたします。 またご希望によりＷＷＷアクセスのログを、遠隔操作により集計し報告いたします。 ・電子メ−ルの予備のサ−バを弊社に設けます。これにより貴社に設置したメ−ルサ−バ に問題がおきても、電子メ−ル自体は保護されます。この電子メ−ルを読むには、弊社 のダイアルアップサ−ビスをご利用下さい。 ・各サ−バの能力が適正かどうか、遠隔操作によりチェックいたします。 (2) インタ−ネット接続口の種類 '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 パブリックアドレス ル−タでパケットフィルタリングしておしまいという構成である。ル−タでのパケットフ ィルタリングのル−ルの設定によくよく注意すれば、これだけも構わない。ル−タでのル −ル設定は普通コマンドで行う。エラ−メッセ−ジや警告はあまり出ないものが多いので 十分注意したい。インタ−ネット黎明期ならいざ知らず、このやり方は採れない。 << 一応ファイアウォ−ルを使うやり方 >> ： ------ ----- ： |Fire| |WWW| Router □ ------ ----- ｜ | | ----------------*--------*---- nix.co.jj パブリックアドレス 上記やり方に Fire ホストを設け、ファイアウォ−ルを設定する。そして外から入ってき たパケットをル−タの次に Fire へ送るように設定する。これによりゲ−トウェイ構成で なくてもファイアウォ−ルを設置できる。問題は経路制御を一つ間違えると、全くセキュ リティ対策にならないことである。実際このような構成はとられることはない。 * インタ−ネット接続口の推奨設計 [ ＩＰアドレス変換機構を使った場合 ] ３章のイントラネットの基本構築ではこ の構成を採用することにして、インタ− ----- ： ネット接続口のサ−バを構築していった。 |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) より安全な構成とウィルス対策 * 新しいやり方 DMZ 構成 '96 ： ファイアウォ−ル・ソフトの FireWall-1、Cyber ： Guard FireWall、 BorderWare Firewall Server、 Router □ 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 ◆を使う場合 ↑ ↑ -------*--- MX ↓ ----*--- MX ↓ | ▽ Mail Relay | ◆ Web ←→ ▽ Mail Relay ------ ｜ ↑ ------ ｜ Shield ｜ ↑ |Gate|----- ↓ |Gate|----------------- ｜ ------ ◆ Web ←→ △ Mail ------ △ ↓ | ｜ Shield ｜ Server | ｜Mail Server -------*--------------------------- ----*-------------------- 社内のユ−ザ同士のメ−ルはウィ MXレコ−ドをWeb ShieldのＩＰにして先 ルスチェックはされないのかな？ ずここにメ−ルが入って来るようにする。 [ POP3 のウィルスチェック ] -------*--- 外への POP アクセス こんなユ−ザはあまりいないと思うだが。 | ▽ ↑ 内部ネットから外へ POPアクセスを許す ------ ｜ ｜ かどうか。多分、個人で入っているプロ |Gate|------ ↓ POP バイダのメ−ルを見るような場合しかな ------ △ ◆ ←―― □ ユ−ザ いような気がするが。 一応、WebShield | ｜ ｜ ｜ だとこんなこともできるということで。 -------*------------------------- [ HTTP/FTP のウィルスチェック ] ※ SMTPのメ−ルのウィルス チェックと合わせて利用 -------*--- ------*--- ができる。 | | ------ ｜ Proxy ------ ｜ |Gate| ↓ Server Client |Gate| ↓ ------ ◆ Web ← □ ← □ ------ ◆ Web ← □ Client | ｜ Shield ｜ ｜ | ｜ Shield ｜ -------*--------------------------- ------*----------------------- Proxy Server がある場合 WebShield のホストを Proxy にする (4) Proxy/Cache も使った設計 `21/03 * プロキシとキャッシュの概要 Proxy というのは、本来の意味は代理である。代わって処理をするサ−バをプロキシ・サ −バというのである。これをファイアウォ−ルの場所におけば、代理応答による中継サ− バとなり、つまりファイアウォ−ルとしての働きをすることになる。それに同時にＩＰア ドレスの変換を行っていることになる。あるいは内部ネットワ−クの適当なところにおき、 これを中継してインタ−ネットにアクセスすることもできる。どちらの場合でも、外部へ のアクセスはこのプロキシ・サ−バを経由し、プロキシ・サ−バのホストがインタ−ネッ トにアクセスし、そのデ−タをこのホストにもってきて、クライアントのホストがそのデ −タを取り込むという流れになる。この時、プロキシ・サ−バにアクセスしたデ−タをた めておき、他のクライアントからのアクセスに供すれば効率がいいではないか。これがプ ロキシ・サ−バのキャッシュ・サ−バとしての働きとなる。 ソフトウェアとしては、フリ−ソフトに Squid, Delegate, Apache Proxy, CERN Proxyが ある。よく使われるのは Squid のようである。市販品ソフトにはNetscape Proxy Server がある。ソフトウェアでなく専用ＯＳを搭載した箱型の製品には NetCache や CacheFlow というのがある。この他パソコンメ−カが出しているのもあるにはある。 NetCache など 専用装置の一番安いのが約１００万円である。Linux などのマシンで、キャッシュ・サ− バを設置しようとすれば、多分これ専用に使うことになるだろう。Linux マシン安く作れ ば２０万円程度でできるかも知れないが、そこそこ市販のマシンを買うとなれば５０万円 ぐらいは見た方がいいだろう。Sun Ultra10 相当になるかな。そう考えれば、もう少しお 金出してばかちょんで設置できる 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、HTTP等 ｜ ■ 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 リバ−スキャッシュのサ−バは、先ずは外部からＷＷＷサ−バへのアクセスを速くするの に使われる。Ｗｅｂアクセラレ−タとも呼ばれる。外向けのＷＷＷサ−バとは別にキャッ シュサ−バを設置し、ここにＷＷＷサ−バのコンテンツがキャッシュ・デ−タとして置か れる。キャッシュ・サ−バはそれ用に特化した装置であり( Squid はただのソフトだが )、 セキュリティ・ホ−ルが少ないといえる。汎用的なマシンにＷＷＷサ−バを設定するより も、安全性は高い。さらに元のＷＷＷサ−バはインタ−ネットからはステルスになり、外 部のユ−ザから直接アクセスされることはなくなる。その点でも安全性が高まる。自社内 にキャッシュ・サ−バを設置する場合は、ＷＡＮル−タとファイアウォ−ルの間に置くの が一般的である。リバ−スキャッシュという用語に対して、内部に置くキャッシュ・サ− バはフォワ−ドキャッシュと呼ばれる。以下、リバ−スキャッシュをサ−ビスする会社を 紹介しておく。まだまだリバ−スキャッシュはよく知られていないやり方である。 (株)リフレクション 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 だけである。 (5) インタ−ネット関連のメモ書き `2b/05 に移動させた * taiken.txt から抜き出したもの http://www.soi.wide.ad.jp:8888/、8888 番でサ−ビスしているＷＷＷサイトです。ここ はＷＩＤＥのインタ−ネット大学だったっけ。 80 番以外でＷＷＷをサ−ビスしていると ころを、いざ探すとなると見つからないものだ。 フリ−の Tripwire を MAIL ホストに設置してみたい。Tripwire、今は商用でも使えるフ リ−のはない、大学で使えるのはあるが。昔フリ−ソフトだったのならいい。 SoftEther、ファイアウォ−ルも通ってしまうという危険なフリ−ソフト？。 インタ−ネ ットでプライベ−トＩＰアドレス同士でも通信できてしまうという。ＶＰＮソフト？。 防火壁モデルと防火服モデルだと。防火壁が今の IPv4 の玄関口でのファイアウォ−ルで、 防火服は IPv6 で個々のデバイスでのファイアウォ−ルなんだと。 ステ−トフルインスペクションの機能と Established の TCP パケットの入って来る制限 を、ごちゃまぜにしている雑誌の記事が目立つ。やることは違うぞ。2004/03 気付いた。 自分のパソコンを FireWall-1 の内側の NetScreen-50 の内側においている。このパソコ ンから外に ftp ができない。NetScreen-50 と FireWall-1 の間にある社内の ftpサ−バ の INDY にはアクセスできた。これは、一体どうしたこと？。 Windows 98で Adobe Acrobat Reader 5.0 を起動すると、ＤＮＳの問い合わせを勝手にし ている。Sniffer Basic でパケットをキャプチャしたら、1270 からbroker.adobe.com と か AdobeTalkBroker とか、これらに自分とこのドメイン名を加えたものだとか。Windows のネットワ−クの設定のＤＮＳのＩＰアドレスを見ている。137 から DDR.INI ？？？。 「UNIX MAGAZINE」2001/01, P.21〜。 外部に公開するサ−バは、内部には設置してはだめ。 基本的にはＤＭＺに置くこと。それができなければ、ＤＭＺにリバ−スキャッシュのサ− バを設置して、くっしょんをかますこと。 IDSは侵入検知、IDP は IDS プラス侵入防止、ファイアウォ−ルと連携してストップさせ る。米国フォ−ティネットの FortiGate、マルチセキュリティ・アプライアンス。`23/04。 IPS( Intrusion Prevension Service ), IDS( Intrusion Detection System )。 Sun の V210 すごい音がします。ファンが４つ、１万回転以上で回ります。Cobaltの１Ｕ も相当うるさかったとか、箱型は気になるような音はしてなかったけど。NetContinuumも セミナ−で見たが、すごい音がしてました。とてもやただの部屋には置けません。`24/12 お友達メ−ルが頻繁に来るぞ。朝日新聞にも載ったぞ。半年ぐらい前からかな、なれなれ なしく。メ−ルくれた？、来ないだのコンパ楽しかったネ、間違ってメ−ル来たみたいだ けどよかった？。最初分からんかった。安易に返事のメ−ル送らんでよかった。`24/12 FirePass SSL-VPN、Ｆ５ネットワ−クスジャパン社。2003/09。米ユ−ロ−ムを買収uRoam。 結構、万能な奴みたい。価格は `25/06 ある比較参考資料から。１Ｕサイズ、５０ユ−ザ のは TCP/UDP 対応で３６０万円位から。２５ユ−ザのはＷｅｂ対応で２５０位から。 IDS はあまり評判は良くなかった。製品としては中途半端なものだった。不正アクセスを 検知するだけでは仕方ない。次に IPSがでてきてこの手の製品は使えるものになった。こ のようにいろいろな製品、ソフトが出て来るが。実際に受け入れられるのとそうでないも のがある。ConSentry ＬＡＮシ−ルドコントロ−ラという製品、いいかも。`26/08 ラックは IDSの監視運用サ−ビスを２００６年３月に開始。すでに８００ヶ所監視してい るという。IPS のサ−ビスも９月に始めた。IIJ は７月に始めている。１ヶ所みてもらう だけでも年間５００万円位いる模様。利用に当ってはかなり細かい仕様を提示しなければ ならない。そのためのコンサルが必要？、素人ではお願いすることすらできない。`26/09 そもそもアプライアンス製品、ここで言うのは SonicWALL とか NetScreen とかだが。ど うも触っていてふに落ちない点が幾つかあった。操作画面がこなれていないというか、挙 動が意図したのと異なるとか。`27/08 Mail-Relayのメ−ルキュ−にメ−ルが何百と溜まっている時に、すぐにメ−ルを送りたい。 いろいろ手段はあるけど、素人管理者は無理。sendmail.cf をツ−ルを使って自分で生成 できるレベルでないとやってはいけない。メ−ルが消えたりえらいことになる。キュ−の ファイルの中の時刻をいじって、sendmail -q で通したという強者も知っている。`27/09 しかしメ−ルキュ−にメ−ルが溜まるには、マシンがひ弱でないことには溜まらない。内 ではずっと SS5 を Mail-Relayで使い続けたために、大量メ−ルが押し寄せた際の対処を いろいろ体験することができた。大量メ−ルと言ってもまだしれた数の迷惑メ−ルだ。今 後もっと増えた場合でもこれで対処できる。誰ばりできない貴重な経験だった。`27/09 メ−ルサ−バのメンテナンス侮るなかれ。個人で入っているプロバイダで作業中に重大な 障害が発生したという。数日メ−ルサ−バに timeoutになり、ようやく POPが繋がったら ８月位からの残していたメ−ル３千以上をダウンロ−ドし始めた。まだダイアルアップな ので２時間とるのにかかった。メ−ルを残す設定はもうやめることにしよう。`27/11 日本人はメ−ルの誤検知は結構シビアにとらえるが。他の国の人らは結構おおらかにとら えているらしい。少々誤りがあってもいいではないか。本当に重要なメ−ルなら電話なり なんなりその内してくるだろう。楽観視しているみたい。そんなことで他の国で作られて いるｓｐａｍ対策アプライアンスは、まま誤検知があるのだということだ。`27/12 Ｗｅｂアプリケ−ション・ファイウォ−ルの NetContinuum、Barracuda Networks 社に買 収された。２００７年１１月のこと。Barracuda ＮＣシリ−ズと名前を変えた。２００６ 年８月にＩＢＭがＩＳＳを買収。２００６年６月にＥＭＣがＲＳＡを買収。２００７年１ 月にはシスコがｓｐａｍ対策アプライアンスの IronPort を買収。`28/03 ずっと使用しているInterScan VirusWall Enterprise Edition。これはＷｅｂアクセスの ウィルスチェックや不審サイトのレピュテ−ションがやれる。かつて FireWall-1 の CVP という連携機能を使って設置したが、今は独立したサ−バとしても設置できる。プロキシ サ−バとしても使える。メ−ルだけでなくＷｅｂも警戒した方がよさそうである。'28/08 迷惑メ−ルという言い方はやめるか、ｓｐａｍメ−ルか単にｓｐａｍだ。迷惑というと一 体何が迷惑なんだ。迷惑である定義は？と必ず聞いてくる。業務に関係ないメ−ル全部で すと答えてたいがい納得するが、ねちゃねちゃと食いついてくる輩がいる。ｓｐａｍです と言えば訳が分からず、はあそうですかで終わるやもしれん。`29/10 いかん、社内メ−ルサ−バの InterScan、ほかっておくとどんどんＲＤＢにパタ−ンファ イルを溜め込んでいく。しまいにはディスクがパンク。PostgreSQLのバグで適当な時にゴ ミを整理するプログラムを走らせないといけない。自動でやるのもトレンドから書かれた のが出てはいる。何かおかしいことになれせんかと、なかなかやれないでいる。`2b/01 * overview.txt から抜き出したもの ファイアウォ−ルはこれからは DMZ にしなきゃ。ＷＷＷホストも守らなね。 しかしエコ ノミ−専用線、８個（実質６個）のＩＰアドレスでは DMZ にはできんぞな。`02/06 ２００１年７月号「Software Design」、ダイアルアップユ−ザも注目、 新時代のＤＮＳ。 ASH Multimedia Lab. の記事で、 P.38 の "シリアル番号を大きすぎる値に設定してしま った場合"。正常な値にするやり方が出ていた。ネットワ−ク管理者はメモっとくように。 qmail の制御ファイルは幾つかある。 記述は sendmail.cf のように難しいことは全くな い。ＳＰＡＭ対策しようとすると tcpserver というソフトもいる。`02/08 IPv6 そろそろどんなものか調べておいた方がいい。IPv4 と混在して使えるので、いつの 間にか増えていくかも知れない。同時に BIND 9 もチェック。`02/08 `21/03, DynamicDNS は DHCP サ−バで割り当てられたＩＰアドレスを、 ホスト名と一緒 に DNS に動的に登録する機能である。DynamicDNS は最近の BIND 8 でサポ−トされたよ うである。内部のネットワ−クでは使うことはないと思う。 レイヤ３スイッチ使ってみて便利だ。当初レイヤ３から数本のケ−ブルを出し、ややポ− ト数の多いハブにつなぎマシンへという接続を想定していた。それが小さなハブへも同じ ＶＬＡＮでどんどんつなぐようになった。そういう使い方でいいみたい。 `22/06, 最近ウィルスがひどいぞな、どんどん来る。小生のとこにもクレズが毎日一つや 二つ来る。頼むでメ−ルアドレスをアドレス帳に記入しれないでくれ−。メ−ルを送る時 はこれまで来たメ−ルを開いて返信でいいでないか。 `23/09, アメリカ出張者のため、 Cobalt のＷｅｂメ−ルを久しぶりに使えるようにした。 WebMail の画面から送信できないと言ってきた。おかしい、いつからこうなったのか、き ちんと原因を調べてみないと。しかし反応が遅い、無いよりはいいと言ってはくれるが。 `24/01, 史上最悪のウィルス MyDoom、内にも１月２７日から届き始め、 この１週間で１ 日百通ぐらい来た。最初、毎日更新するパタ−ンファイルでは検出できなくて、２〜３通 すり抜けた。急遽 InterScan のエンジンもアップした。% /etc/iscan/vscan -v での表 示は Virus Scanner v3.1, VSAPI v6.810-1005。 `26/05, どうもインタ−ネットの経路がおかしくなっているのでないか。あるところにメ −ルが行ったり行かなかったりする。内から MX レコ−ドのＩＰアドレスに ping 打って も反応がない。そこの所からは ping は通るという。どうも変だ。 何と LinkProof 思い 切って外したらすかすかメ−ル行きました。どうも LinkProof が怪しいです。 `26/05,日本版ＳＯＸ法でメ−ルを全部保管しないといけない？。 それには POP3 ではだ めだ、IMAP4 にしないことには。もう自分は IMAP4 に変更する馬力はないぞ。 IIJ のメ −ルサ−ビスに移行するか？。どのようなＳＯＸ法対策をとるかは、そもそも社内の法務 担当が決めるこことだ。一応聞いてみたが、まだ分からないとのこと。 `26/12/27, 迷惑メ−ルを放置しておけない状況になってきつつある。 内でもワ−ワ−言 うようになってきた。 sendmailの Greet Pause 設定がいいのでないかという気がしてき た。InterScan の eManager のキ−ワ−ド・フィルタリングもちょっとは使えるかも。 `29/03、Mail-Relay に Greet Pause を設定するのは結局やらなかった。 Mail-Store の InterScan のバ−ジョンアップと新ライセンスでｓｐａｍ対策ができることを２００８年 夏頃分かった。それを２００９年末からやった。十分な結果が得られたのだった。 * ２０１１年梅雨頃からの追加 メ−ルのアカウント管理を LDAP でやるというのは、今のところでは無理だ。時期も会社 も。やはりそれなりの規模の企業でそれなりのＩＴ部門があって、それなりの人材がいる ところでないと無理だ。どうやったらできるかまでは検討を一応はやってみるが、多分そ こまでになるだろう。LDAP ではなく RADIUS での管理までだろう。 `2b/05 ついにＩＰアドレス枯渇の余波が内にまできた。プロバイダが持っている IPv4 のＩＰア ドレスのブロックを JPNIC に返却したいのだそうだ。 フルにＩＰアドレスをお客さんに 割り当てて使ってもらっている状況だったら、こんな話は出なかったと思うが。片手程度 しかいなくて、JPNIC にはＩＰアドレスの利用料を払っている。赤字だそうだ。`2b/06 気が付いたらインタ−ネットの接続口周りの機器は全部入れ替えということになっていた。 ファイアウォ−ルを FireWall-1 から FortiGate に。Mail-Store と Mail-Relay を仮想 マシンに。プロキシキャッシュサ−バの NetCache も仮想マシンに、InterScan Web Secu rity Suite でＷｅｂレピュテ−ションも使う。ＩＰＳの DefensePro は 202 に。`2b/07