表 5 ボリシー定義 バケットフィルタと各 Se Ⅳ e 「 / Rooute 「に設定するアクセス管理、およびバケットフィルタによって残された記録の監視程度の労力 何を守るのか ? 誰から守るのか ? どのような方法で守るのか ? どのくらいの期間守るのか ? どのくらいの労力で守るのか ? バケットフィルタポリシー 図 5 のネットワークにおける、 Router および Server 、各機器が提供するサービス。ただし、 te 「 min 引が接続されているネットワークは、必要最小 それぞれのサービスを提供している間 バケットフィルタ。基本的に default deny po ⅱ cy で守る。 ネットワークへの不正侵入者 限の保護しか行わず、 te 「 min 引の管理者に任せる。 ・ lnterface ISP-R any any N et-A Net- B any any any any any any any any any any any any any source ℃ MP 旧灯 C P any any IP/TCP IP/UDP IP/TCP IP/UDP IP/TCP IP/UDP 旧灯 C P any any any any IP/U D P any Protocol ・ lnterface Net-A-R source any any Net-B N et-A-a Net-A-a Net-A-b Net-A-b Net-A Net-A-R any pany any Net-A Net-A any Protocol ℃ MP 旧灯 C P any IP/U D P IP/U D P IP/U D P 旧灯 C P any any any any any any IP/U D P any ・ lnterface Net-B-R source P 「 0t0C0 ー any any any any any any any any any any any any any any any any src po src po any any HTTP domain domain any any any any any any any any any any any any any any any any any any src po dest any any any any Net-A-a Net-A-a Net-A-a N et-A-a Net-A-b Net-A-b Net-A-b Net-A-R Net-B-R ISP-R N et-B N et-B any dest any any any any any any any Net-A- R Net-A N et-A- R N et-B- R ISP-R Net-B N et-B any d est any any any Net-A-b Net-A Net-A- R Net-B-R ISP-R any any dest po any any any HTTP HTTP domain domain domain domain smtp any any any 6000-6063 any any any any any smtp any any any any any dest po any く 1023 6000-6063 any any any any any ssh pop3 any any dest po 杙 any 023 FIag Estab Estab FIag Estab FIag any any Net- B Net- B Net- B any any any Net-B any 110 ℃ MP 旧灯 C P any IP/TCP IP/TCP any any any any any policy permit permit deny deny permit permit permit permit permit permit permit deny deny deny deny perm it deny policy perm it perm it deny perm it permit permit permit permit permit deny deny deny deny permit deny policy pe rm it pe rm it deny permit perm it deny deny deny permit deny memo ℃ MP はすべて通す TCP で通信か確立 (Establish) している場合のすべての TCP 通信は許可 旧 P 側から Net - B が送り元のバケットが来るはずがない 旧 P 側から Net - A が送り元のノヾケットが来るはずがない ーとの DNS 関係の通信はすべて許可 name サーバーとの DNS 関係の通信はすべて許可 h 叩 ( Web ) サーバーとの h 叩での通信はすべて許可 name サー/ ヾ ℃ MP はすべて通す memo Net-A 以外のネットワークと Route 「との通信は不可 smtp サーバーの smtp ポートへのアクセスはすべて許可 必要に応じて記録をメールによって残す 以上で許可されたもの以外のすべての通信は禁止。 特権ポート以外のポートへの UDP によるアクセスは許可 Net-B への X Window System で利用する可能性のあるポートへのアクセスは禁止 TCP で通信が確立 (Establish) している場合のすべての TCP 通信は許可 MP はすべて通す memo 必要に応じて記録をメールによって残す 以上で許可されたもの以外のすべての通信は禁止。 特権ポート以外のポートへの UDP によるアクセスは許可 Net-B への X Window Sys m で利用する可能性のあるポートへのアクセスは禁止 Net-A 以外のネットワークと Route 「との通信は不可 Route 「と Net - A の間のすべての通信は許可 smtp ポートを利用した外部とのすべての通信は許可 Net - A 側から Net - B が送り元のバケットが来るはずがない 必要に応じて記録をメールによって残す 以上で許可されたもの以外のすべての通信は禁止。 端末がつながっているセグメント (Net-B) からのすべての通信は許可 Net-A 以外のネットワークと Router との通信は不可 Net-B からの ssh ポートを利用した通信は許可 Net-B からの pop3 ポートを利用した通信は許可 Net-B 側から Net - A が送り元のバケットが来るはずがない TCP で通信か確立 (Establish) している場合のすべての TCP 通信は許可 BSD magazine 2001 NO. 7

2 アイアウォりレを考える ・ヘッダに格納されている情報以外の 情報を元にした制御は行えない ことである。情報通信を行う場合、や り取りされる情報は通常バケット単位 に分割されることを考えると、バケッ トの情報からだけでは、情報全体を利 用した制御が不可能であるのは当然で あろう。 そろそろバケットフィルタの挙動を 例を挙げながら説明しよう。 図 4 におけるネットワークにおいて、 packet FiIter は Host-A/B から Host-Z に対 するアクセスの制御を行うと仮定する。 たとえば、 Host-A と Host-Z の通信は すべて許可し、 Host-B と Host-Z の通信 はすべて却下するというポリシーを packet FiIter に記載する場合を考えてみ 0 前節で述べたように、 TCP/IP での通 信は基本的に ・ IP アドレスの組み合わせ ・ TCP/UDP の場合、ポート番号の組み 合わせ で制御されている。したがって、今回 のポリシーをバケットフィルタ (packet Fi1ter) に定義する場合、表 1 のような 表を作成すればいいということになる。 こで、バケットフィルタに通信の 方向毎にポリシーを定義しなければな らないことに十分に注意してほしい。 一般に、 Host-A から Host-z に向かって 通信する場合と H 。 st - z から H 。 st - A に向 かって通信する場合では、意味が異な る場合が多いので、このように通信の 方向毎にポリシーを設定する必要があ る。 では、通信方向によってポリシーを 変えなければならない場合の例を挙げ てみよう。 2001 No. 7 Host-A は web サーバーであり、 Host- B は p 叩 server であるとする。 H 。 st - Z は攻撃から守られなければな らないので、 Host-A からの http バケッ トと Host - B からの p 叩バケット以外は Host-z に届かないようにしたいという 状況だと仮定する。そのような場合の ポリシー表は表 2 のようになる。 このようなポリシーを作成すると、 Host-Z からバケットフィルタを通り Host-A 、 B にバケットを送ることは可 能となるが、 Host-A からは http 以外の バケットおよび、 Host - B からは pop3 以 外のバケットは通らなくなる。なおこ の例では、ホストを単位にポリシーを 決定したが、もちろん、ネットワーク やサプネットワークを基本単位として ポリシーを記載することもできる。 このようなポリシーをどのように設 定するかに関しては、利用するツール によって異なる。利用する場合には、 それぞれのマニュアルを参照していた だきたい。 バケットフィルタは、通常インター フェイス単位で設定する。たとえばイ ーサネットインターフェイスだったり シリアルインターフェイスだったり、 トンネルインターフェイスだったりす こまで見てきたポリシーの設定 る。 にインターフェイスの概念を加えるこ とにしよう。 表 3 のようにインターフェイス毎に設 定をすることで、通信の方向の見通し が良くなったり、各インターフェイス 表 1 ホリシー例 1 送り元ホスト Host-A/lP-A Host-Z/lP-Z Host-B/lP-B Host-Z/lP-Z 送り元ホスト Host-A/lP-A Host-A/lP-A Host-A/lP-A Host-Z/lP-Z Host-B/lP-B Host-B/lP-B Host-B/lP-B Host-Z/lP-Z 送り元ホスト ・旧 - a 側のインターフェイス設定 Host-A/lP-A Host-A/lP-A Host-A/lP-A Host-B/lP- B Host-B/lP-B Host-B/lP-B ・旧 - b 側のインターフェイス設定 Host-Z/lP-Z Host-Z/lP-Z 送り元ホスト 表 2 ホリシー例 2 ( 通信の方向が重要になる例 ) Host-B/lP-B Host-Z/lP-Z Host-A/lP-A Hos ト乙旧 - Z 宛先ホスト プロトコル IP/TCP IP/UDP any any 旧灯 C P IP/U D P any any 送り元ポート http http any any pop3 pop3 any any 表 3 ボリシー例 2 ( インターフェイスの概念を加える ) プロトコル 旧灯 C P IP/UDP any 旧灯 C P IP/UDP any プロトコル any any 送り元ポート http http any pop3 pop3 any 送り元ポート any any ポリシー permit ( 許可 ) permit ( 許可 ) deny ( 却下 ) deny ( 却下 ) 宛先ホスト Host-Z/lP-Z Host-Z/lP-Z Host-Z/lP-Z H ost-A/lP-A Host-Z/lP-Z H ost-Z/lP-Z Host-Z/lP-Z Host-B/lP-B Host-B/lP-B Host-A/lP-A 宛先ホスト H ost-Z/lP-Z H ost-Z/lP-Z H ost-Z/ IP-Z Host-Z/lP-Z H ost-Z/lP-Z Host-Z/lP-Z 宛先ホスト 宛先ポート any any any any any any any any 宛先ポート any any any any any any 宛先ポート any any ポリシー permit permit deny permit permit permit deny permit ポリシー permit permit deny permit permit deny ポリシー permit permit BSD magazine 107

黻 2 アイアウォ りレを考える ・クライアントは、最終決定した方式 での認証情報を含むリクエストを送 信 ユーザー認証機能を用いるには、サ ーノヾーの設定ファイル (socks5. conf) の auth 行でユーザー認証方式を指定し、 さらに permit 行でそれぞれのルール毎 の認証方式を決定する。リスト 3 に示 す例では次のような処理が行われる。 ・ GSS-API に対応する SOCKS5 クライ アントは GSS ー A 円での認証を行う ・ GSS-API に対応しない SOCKS5 クラ , u , k イアントは、ユーザー名 / パスワード ・ SOCKS4 クライアントは認証を行わ ない ユーサー名 / バスワード サーバー側では、デフォルトで / etc / s 。 cks5. passwd に記述したユーザー情報 を元に認証を行う。 socks5. passwd に は、ユーザー名とパスワードを空白で 区切って記述する。 permit u —b,user—c 192. 168.2. USer user—a user—b user—c secret—a secret—b secret—c もし、特定のユーザーのみに限定し ト部にユーザー名をコンマで区切って たい場合は、 permit 行のユーザーリス での認証を行う マリスト 3 ユーザー認証 auth Ⅱ permit n,u,k ライアント 192. 168.2. 指定する。 SOCKS NS サーバー SOCKS での接続 (TCP) クライアント SOCKS 間の UDP ボート番号の交渉 (TCP) DNS のリクエスト (UDP) 図 2 UDP の中継 ( DNS リクエストの例 ) SOCKS の終了 (TCP) DNS のレスポンス (UDP) DNS 要求処理 (UDP) クライアント側では、ユーザー名と パスワードを環境変数に指定しておく。 % setenv SOCKS5—USER user—a % setenv SOCKS5—PASSWD secret—a GSS-API GS s -API 方式の認証を行うには、 SOCKS サーバー クライアント共に GSS - API に対応させる必要がある。ア プリケーションの例として、 SOCKS5 附属の rtelnet/rftp を利用するには以下 のような手順を踏む。 Kerberos 環境 ・ SOCKS サーバー、クライアント共に Kerberos の環境を整える ・ SOCKS サービス用のプリンシバルを K e r b e r 0 s データベースへ登録 ( SOCKS が使用するサービスプリン シバル名は lib / gss. c で変更できる。 デフォルトは rcmd) SOCKS サーバー側 ・ SOCKS を configuure --with-krb5 でコ ンパイル後、インストール ( コンパ イル過程の途中でつますくかもしれ ないが、手作業で修正するのも、そ れほど難しくないはずだ ) ・ SOCKS サーバー設定ファイルに記 述 permit k ー 192 . 168.2. クライアント側 ・サーバー側と同様に SOCKS のクライ アント環境をコンパイル、インスト ・ kinit コマンドで信任状を取得 beros 環境へのログイン ) 2001 No. 7 BSD magazine (Ker 137

2 アイアウォりレを考える ・サーバー環境 % make server # make server . 1nsta11 ・クライアント環境 % make clients # make clients . install ・ライプラリ環境 ( クライアント側は インストールしておいたほうがよい ) ( スタティックリンクライブラリ ) % make 1ib # make 1ib . install ( 共有ライプラリ ) % make shlib # make shlib . install SOCKS サーバーの設定 設定ファイル SOCKS サーバーの設定は /etc/socks5. conf で行う。リスト 1 は、内部ネット ワークからインターネットへの接続を 行うための設定例である。図 1 のよう なネットワークでは、この設定をベー スとして、各サイトの環境に合わせて ルールを適用してゆくことになる。 インターフェイス 複数のネットワークとの接続を持っ 場合は interface 行で、ネットワークが どのインターフェイスの先にあるかを 設定する。 interface に続いて、ホスト / ネットワークアドレス、ポート番号、 インターフェイスアドレスの順で指定 する。リスト 1 では、 192.168.2.0 / 24 、 192.168.3.0 / 24 は内部ネットワークと し、その他のネットワークは、インタ ーネット側に存在することを指定して いる。 アクセスコントロール アクセスコントロールは permit/deny 行で行う。デフォルトでは、すべての 中継は禁止されており、許可したいル ールを permit 行で指定する。明示的に 禁止したいルールは deny 行で指定す る。 permit/deny に続いて、条件となる 7 つの項目を指定する。 ・コマンド ( 通信の種類 ) k: GSS-API u: ユーザー名とパスワードによる n : 認証なし ・認証方法 t: traceroute p: P1ng u : UDP b: bind C : connect ・始点アドレス [ 1 , 1024 ] : 1 ~ 1024 サービス名またはポート番号 ・始点ポート 始点アドレスと同じ 点アドレス client. example.jp: ホストそのもの レス 192.168. : 192.168. で始まる IP アド 192.168.12. Ⅳ 255.255.255.0 : ネット べて . example ・ jp: example.jp ドメインす ( 1024-6000 ) : 1025 ~ 5999 始点ポートと同じ ・終点ポート マリスト 1 socks5. conf ・ユーザーリスト ユーザー名 - " はすべてにマッチすることを意味 する。また設定は上から順に読まれ、 最初にマッチしたものが有効となる点 に注意する。 SOCKS サーバーの起動 Iibsocks5. conf で行うか、または環境変 SOCKS クライアントの設定は / etc / SOCKS クライ、とトの設定 set SOCKS5_BINDINTFC 192.168.2.1 ( 設定ファイル ) socks5 —b 192 .168.2. 1 ( コマンドライン ) もしくは設定ファイル内で設定する。 には、コマンドラインで指定するか、 トワークインターフェイスを限定する また、 SOCKS のために割り当てるネッ のユーザーで起動するなど調整を行う。 セキュリティを高めるには、 root 以外 TCP の 1080 番で待機状態となる。より サーバーが起動すると、標準では らは単純に実行するだけである。 インストールされ、コマンドラインか きる。標準では /usr/local/bin/socks5 に ト ) と inetd 経由で動作させることがで 受け持つ。デーモンモード ( デフォル SOCKS サーバーは socks5 コマンドが auth interface interface interface permit permit 192.168.2. 192.168.3. 192 .168.2. 192.168.3. 192.168.2. 1 192. 168.2. 1 a. b . c . d 2001 No. 7 BSD magazine 135

マリスト 4 socksl の socks5. conf # 192.168.1 / 24 は内部のネットワーク interface 192. 168.1. 192. 168. 1 . 1 # その他のネットワークはインターネット側に存在する 111 . 111. 111 . 111 2 2 2 . 2 2 2 . 2 2 2 . 2 2 2 ・インストールされた rtelnet/rftp.. ンドで通常通りの操作を行う soqKs 間の接続 ; ー コマ interface 111. 111. 111. 111 # 192.168.2.0 / 24 への通信は socks2 を中継 socks5 192.168.2. 222.222.222.222 # その他のネットワークとは直接通信する マリスト 5 permit permit # socks2 noproxy socks2 の socks5. conf 192. 168. 1 . # 内部ネットワークからの通信は許可 ー 222.222.222.222 からの通信は許可 # その他のネットワークはインターネット側に存在する interface 192.168.2. 192. 168.2.1 # 192 . 168.2 / 24 は内部のネットワーク interface ー 222 .222.222.222 # 192.168.1.0 / 24 への通信は socksl を中継 socks5 192. 168. 1 . 111 . 111 . 111 . 111 # その他のネットワークとは直接通信する permit permit # socksl noproxy SOCKS2 ネットワーク SOCKS 1 192. 168 . 2 . # 内部ネットワークからの通信は許可 111 . 111 . 111 . 111 からの通信は許可 192 . 168.2 . 1 192 . 168. 1 . 1 図 3 SOCKS 問の接続 192 . 168 . 1 . 0 / 24 192 .168.2.0 / 24 企業や学校などで組織が地理的に分 散しており、それぞれ個別にインター ネットとの接続を行っている場合には、 SOCKS を用いて組織のネットワーク同 士を相互に接続できる ( 図 3 、リスト 4 、 5 ) 。 socks5/noproxy 行には、宛先ホ スト / アドレス、宛先ポート番号、接続 先の SOCKS サーバーを順に指定する。 なお、 SOCKS 間の通信路は平文のまま なので、お互いでやりとりする情報に は十分に注意を払う必要がある。 クライアントとして Windows を利用 する場合は、 runsocks と同じような機 能を提供する s 。 ckscap を利用できる。 SOCKS5 サーバーと同様に、米国 NEC のサイトから入手できる。 ー、おわ当ー : イ せて実装を選択するとよいであろう。 導入するサイトの目的や事情にあわ ライセンスで配布している。 うソフトウェアがあり、 BSD と同様な Dante (http://www.inet.no/dante/) とい その他の SOCKS5 の実装としては s 。 cks64- * ) からパッチを入手できる。 Proj ect(ftp ://ftp.kame.net/pub/kame/mi sc/ ぞれ、米国 NEC のサイトと KAME 士通研究所の 2 つの実装があり、それ レータとしても利用できる。 NEC と富 NEC 版の SOCKS5 は IPv6-IPv4 トランス NEC 版の SOCKS5 を取り扱った。米国 以上、よく知られた実装として米国 138 BSD magazine 2001 NO. 7

要」なのかということが判断できなく なってしまう。これでは結局「今セキ ュリティが保持されているのか」判断 できていないのと同じことであろう。 さて、セキュリティに関する一般的 な話はここまでにして、そろそろネッ トワークにおけるセキュリティのほう に話を移すことにする。 一般にネットワークセキュリティ手 法と言われているものは、基本的には アクセス制御が圧倒的に多い。つまり、 ・許可された人にはアクセスを許す ・そうでない場合、アクセスさせない ようなポリシー ( と手法 ) を採用した 許可されていないサービスはアクセ スを拒絶する ・そうでないすべてのサービスにアク ネットワ 1 ク↓こお町やすキ ) ティ。 セスを許可する ようなポリシー ( と手法 ) を採用した りする。 前者を default deny policy 、後者を default permit policy と言ったりするが、 これらはバケットフィルタで実現させ る場合が多い。 この、バケットフィルタとはなんぞ や ? ということを書く前に ノヾケッ トフィルタを行うための基本概念であ る、「 TCP / IP における通信モデル」の 話をすることにしよう。 TCP / IP の通信の基本は、通信モデル が End-To-End であることである。言い 替えると、常に 1 対 1 の通信が成立する ことが TCP / IP の原則である。現在最も 利用されている http ( web などで使わ れる通信プロトコル ( 手順 ) ) や smtp ( メールの受配送に使われる通信プロト コル ) などが、この 1 対 1 の通信モデル を利用している。 これに対し、近年利用者が増えてき ている Multicast などは 1 対多のモデルで TCP / 旧におけを、導信モデル。 あると言える。 以下では、 TCP 、 UDP を基にして説 明することにする。 図 1 と図 2 は 1 対 1 の通信モデルの例 と 1 対多の通信モデルの例である。 実際には、さらにこれらの状況が複 雑に絡み合っている。 図 3 において、たとえば、 CIient-1 、 2 、 3 は Radio サーバーから Multicast で ラジオを受信している。また、同時に Client-1 は http server を利用して web を みており、 Client-3 は smtp サーバーを利 用して Ma ⅱを送っているとする。 TCP/IP では、これらがすべて同時に 起こっても通信が混乱したりすること はない。これは、各 Server/CIient には IP アドレスが割り振られ、どのホストと どのホストが通信しているのかが管理 できるからであり、さらに複数の通信 を行う際に、ポートという情報の出入 口を利用しているからである。今回の 図 3 の例では、 ・ Radi 。サーバーに割り当てられた IP ア ドレスのラジオ配送ポートから Server—A Server—B Network server-A と C1ient-A とは smtp で通信している Server-B と C1ient-B とは http で通信している C1ient—B 図 1 1 対 1 通信モデル C1ient—A 自分と関係無い通信は聞こえない。 それぞれの通信は完全に独立しており、 104 BSD magazine 2001 NO. 7