個人の常時接続環境を考える ( 2 ) ノくターン 1 図 2 パターン 1 : インターネットと内部ネットワー クのあいだに設置 図 2 のようにサーバーを設置する場合、インターネッ トと DMZ とのあいだでは、パフォーマンスを考慮して バケット・フィルタリングでサーバーへのアクセスを制御 するとよいでしよう。そして、 DMZ と内部ネットワーク とのあいだにはプロキシー・システムを構築します。 このとき、サーバー言算機のメンテナンスをおこなえる ように、、、内部ネットワークからサーバー言 t 算機 , ぐログ インできるように設定することがあります。このように 内部から DMZ への接続を許可すること自体にはとくに間 題はありません。しかし、、、サー ー計算機から内部ネッ トワークへ " の接続は絶対に禁止すべきです。 さらに余裕があれは、サーバー言 t 算機からインターネッ ト側へのコネクションについても、サービスに無関係なも のはすべて禁止するように設疋するといいでしよう。この ように設定しておけば、たとえサーバー計算機に侵入され ても、はかのサイトへの踏み台として悪用される危険匪を 大きく減らせます。 パターン 2 : ファイアウォールの 3 番目のネッ トワークに設置 図 3 のような構成では、インターネットと DMZ との ロ あいだの通信はプロキシー経由でおこない、サービスに必 サーハ 要な通信だけか流れるように設定すること ( つまりデフォ ルト禁旧が多いようです。もちろん、バケット・フィル タリングで制御する場合もあります。 この友には、管理すべきファイアウォールの要素が少 解です。安全だという本処は、ファイアウォールがインタ ないので、手間がかからないという長戸励ゞあります。しか ーネットとサーバーとのあいだの通信をすべて見張ってい し、ファイアウォールか停止するとすべてカ阯まってしま て、サーピスと無関係な通信を遮析してくれるから・・ います。また、すべての通信が 1 台のファイアウォール ということのようです。しかしパターン 1 の構成でも同 を経由するため、パフォーマンスがそこで制限されるとい 様のセキュリティ・レベルは実現できます。「これこれしか う間題もあります。 じかの点については・・・・・」という限定的な評価であれば、 パターン 1 と同様に、サーバー言算機から内部ネット 優劣をつけられるかもしれませんが、全体としてどちらの ワークへのアクセスを禁止し、さらに、サーバー計算機か 構成か優オ L ているとはいえません。 らインターネット側へのアクセスについても、サービスに パターン 3 : 内部ネットワークに設置 関係のないものはすべて禁にするように設定します。 稀に、図 4 のように公開サーバーを内部ネットワーク ところで、このような構成はパターン 1 にくらべてはる に接続している話を聞いたり、い膕な構成を紹介している かに安全だといわれることがありますが、これは大きな誤 インター不リト D M Z 山内部もーワへ 3 、 サー艸ー / ヾターン 2 図 3 イ丿一リト QEN つアイアウォール 内部ネもト、ワ , り ~ 51 UNIX MAGAZINE 2000.8

いつでも使えるインターネット バケット・フィルタリングとプロキシー ファイアウォールのおもな彳難リは、疑わしいアクセス や通信を拒否して内部ネットワークを攻撃から守ることで す。さきほども述べたように、このイ督目みはバケット・フィ ルタリングまたはプロキシーによって実現することができ ます。 このように複数窈尺肢がある場合には、山絲冬的に、 「で、どっちがええの ? 」 となるでしよう。 攻撃からの防御という点では、原工勺には知識と技術が あれはどちらでもかまいません。ただし、バケット・フィ ルタリングにもプロキシーにもそれぞれ防ぎにくい攻撃が あります。 両者を組み合わせて使えは、一方カ材く得手とする攻撃を 他方か防御してくれるので、より高度なセキュリテイか実 現できます。ただし、そのぶんコストがかかりますし、両 方あ川ますべての攻撃が防げるわけでもありません。 攻撃からの防御以外に ・ノヾフォーマンス ・言当求できるログの不鶤頁 などの点も考慮すべきでしよう。パフォーマンスについて は、一殳にバケット・フィルタリングのほうか有利です。 一方、プロキシーではさまざまなログを言求することがで きます。 山辭冬的な判断のポイントは、許容できるコストと要求す る機能とのバランスということになるでしよう。 UDP とファイアウォール ーイ殳論でいえは、ファイアウォールを介した UDP バケ ットの中継はあまりお勧めできません。というのも、 UDP では TCP のようにハンドシェイクやシーケンス番号が使 用されないため、 TCP と上交してバケットの偽造がきわ めて容易だからです。したがって、送信元アドレスを偽造 したバケットがファイアウォールの内側にたやすく入りこ むおそれがあります。山も丘は、 IP バケット 1 つだけで成 立するような攻撃がたくさんあるので、不用意にバケット 50 とはいっても、 を内部に流入させるのは避けるべきです。 「 UDP バケットは立入禁止 ! 」 と簡単には言いきれません。たとえは、マルチメディア系 のアプリケーションの多くは UDP を用いて通信します。 企業であれば、「そんなもん、仕事には関係ないやろ」の 言ですむかもしれませんが、家庭で常日妾続する場合は 状況が異なるはすです。蕕葉やビデオを楽しむためにイン ターネットに接続しているのに、これらのサービスが使え ないのでは、それこそ「意味なーいしゃーん」と言われそ アプリケーションによっては、フィルタ規則か書きやす くなるように使用する UDP ポートを固定したり、 TCP を使うオフションを用意しているものや、専用のフロキシ ・サーバーを提供しているものもあります。これらを利 用するのも 1 つのガ去でしよう。しかし、この種のサー ビスではサイト (URL) ごとにアクセス方法が異なる場合 も多いので、そのたびに設定を変更するのではたまりませ ん。そのうちに、どのオフションをどう設定したらよいの かと頭が昆乱してきて、しまいには「そこまでする価値が あるんかなあ」などといった根本的な疑間に悩まされるか もしれません。 現在、マルチメディア系アプリケーションの通信につい て RTSP (Real Time Streaming Protocol) というプ ロトコルて驃準化しようという動きもあります。今後 れが一ヨ麺勺になれは、一 E 記のような事態は改善されるかも しれません。 公開サーパーをどこに置くか Web や FTP 、 DNS など外部に対して公開するサー ーを運用する場合、各サーバーのセキュリティ対策は当 然として、どこに配置するかも慎重に考える必要がありま す。その言に応して、守るべき内部ネットワークの安全 性か変わるからです。 以下では、いくっかの典型的なパターンを紹介し、それ ぞれのポイントを説明します。 基本的な考え方 すべての場合について、サーバー計算機に侵入されたと いう前提で考えます。このとき、サーバー言 t 算機への侵入 が、内部ネットワークへの足掛かりとならないように言妬 するのカ本です。 ノ、 UNIX MAGAZINE 2000.8

うか。ただし、上司がそれを認めてくれるかどうかは分か りません。 テフォルト許可か、デフォルト禁止か ファイアウォールを設計する場合の基本的なポリシー は、次のどちらかです。 ・明カ苅勺に禁止されていないサーピスは許可する。 ・明カ前勺に許可されていないサーピスは禁止する。 最初のポリシーでは、原則としてすべて許可し、「 x x はダメ、△△もダメ・・・・・・」というふうに規則を追加してい きます。 2 番目のポリシーはこれとは逆で、原則としてす べて禁止し、「◎◎は OK 、〇〇も OK ・・・・・・」というふう に規則を追加します。 どちらが安全かといえば 2 番目ですが、許可するサー ビスごとに規則を追加していかなければならないので手間 がかかります。たとえは、許可するサービスに対応するプ ロキシー・サーバーを追加インストールしたり、プロトコ ルが通過できるようにバケットフィルタの規則を書き加 えなければなりません。このとき、そのサービスに対応す るプロキシーが用意されていないと、場合によってはお手 上げになってしまいます。バケットフィルタを言当する ときも、そのサービスをおこなう通信 ( どちらの方向にど のポート番号の通信があるか ) を熟知していないと正しい フィルタ規則は書けないでしよう。 こうしたらええんか な。いや、このはうがよさそうやな " などと試行錯誤して いるうちに、無関係 ( かっ危険 ) な通信を通過させてしま うおそれもあります。 一方、最初のポリシーでは、危険と思われるサービスの 通信を禁止する規則を追加していきます。基本的にそオ助、 外のサーピスは通常どおりに使えるので、ユーザーからみ 川まイリです。しかし、管理者はどのサーピスが危険なの かを正確に把握していなけれはなりません。つまり、管理 者が知らない危険には対処のしようがないのです。 状況に応して両者を併用する方法もあります。たとえ は、インターネットと DMZ とのあいだはデフォルト許 可、 DMZ と内部ネットワークとのあいだはデフォルト禁 - 止、そして、インターネットと内部ネットワークのあいだ はデフォルト禁止という設定も可能です。 UNIX MAGAZINE 2000.8 SC 翡 7 月 21 日発売 ! Java プログラミング・ノート 国際化と 日本語処理 CAFE BABE ava 国際化と日本語処理 プログラミング・ノート ( A 第第・ A 第第 S ロー ・風間一洋著 ・ A5 判、 312 ページ ・ ISBN 4-7561-3481-5 ・本体 3 , 000 円十税 UNIX MAGA 刀 NE に好評連載中の「 CAFE BABE ー Java プロクラミング・ノート」第 1 弾。 Java による日本語処理、さらには国際化プロ グラミングに必須の知識を数多くのサンカい プログラムを示しながら平易に解説する。真 の意味での "Write Once, Run Anywhere" 目次から を目指すプログラマーに最適の 1 冊。 1 章 2 章 3 章 4 章 5 章 6 章 7 章 8 章 9 章 10 章 1 1 章 12 章 付録 Java はどんな言語か 国際化と地域化 Unicode ロケー丿レ 工ンコーティング タイムゾーン リソース / ヾンドル フォーマット出力と解析 文字列の比較 テキストの境界解析 インブットメソッド 文字の表示 Unicode プロック / ロケール一覧 / 工ンコーティング名一覧 / タイムゾーン D 一覧 / ユーロ通貨記号への対応 株式会社アスキー 49 電話 (08) 535 ト 8194 出版営業部 〒 1 51 ー 8024 東京都渋谷区代々木 4 ー 33 ー 1 0