ネットワーク - みる会図書館

1. UNIX MAGAZINE 2004年11月号

004 年 11 月 1 日発行 ( 毎月 1 回 1 日発 9 = ツ・マガジン特集 1 1 号通巻 217 号昭和 63 年 9 月 5 日第三種郵便物認可 0 200 ポストファイアウォールとネットワ : ケ - セキュ ? ディ vo 機器導入の一、国立天寓台のネットツーク crea -ini 気 ) とプロセスの生成 F ′ eeBSD のプートプロセスをみる、 X で年賀状を作るリ N Ⅸ便利鮎ひんやり NetBSD ( 導入編 ) 文房具としてのリ N Ⅸ bwrap ライプラリ関数のソースコードプログラミング・テクニック侵入検知システム Sno の導入ネットワークとセキュリティ・ネットワ—ク分技術ー・検疫モテルとは何加

2. UNIX MAGAZINE 2004年11月号

図 8 複数の stunnel}* の切潜えメール・クライアントを動かすコンピュータメール・クライアントの設定は変わらず 127.0.0.1 : 110 メー丿レクライアントくに自初 Windows マシンにアクセスする」 Windows XP SP2 ( 以下、 SP2) を導入すると、 8 月号の己事の操作そのままでは SSH 経由でリモート・デスクトッフ接続がおこなえなくなる。 8 月号の記事では、 127.0.0.2 に対してリモート・デスクトッフ凝続をおこなうのがポイントの 1 つだったが、 SP2 では 127.0.0.2 がループバック・アドレスとして機能しないからである。 TCP/IP の規格では 127.0.0.1 ~ 127.255.255.254 はす勤務先用べてループバック・アドレスとして使えるよう規定されている stunnel ので、これは規格違反である。 SP2 が公開されてほどなく、 127.0.0.1 : 110 127.0.0.1 以外のループバック・アドレスを使えるようにする 127.0.0.1 : 25 パッチ WindowsXP-KB884020-x86-jpn. exe が公開され stunn を切り替えてネットたにのファイル名をそのまま検索エンジンで探せば、ダウンロワーク環境の変イヒに対応ード元力分かる ) 。このパッチを適用すると、 8 月号の説明どおりの操作で SSH 経由のリモート・デスクトッフ接続がおこなえる。ーク環境から同じ SSL 対応メールサーバーにアクセスすまた、 SP2 では従来は不可能だったリモート・デスクトッフ。のることを考えてみよう。その場合には、ネットワーク環境クライアントから 127.0.0.1 への孑第売も可能になった。 SP2 適用前は、ごとに stunnel の設疋ファイルを用意し、それらを使い分けることになる。この記事でとりあげた stunnel の設疋と $ ssh -g —N -L 13389 : 127.0.0.1 : 3389 - myhome . dynamic—domain ・ jp SSH トンネルの作り方では、 127.0.0.1 : 110 が POP3 サとして SSH トンネルを作り、 127.0.0.2 : 13389 に対してリモ、 127.0.0.1 : 25 が SMTP サーバーにみえる。しート・デスクトッフ続する必要があった。一方、 SP2 では、たがって、メール・クライアントの設定は変わらない。こ $ ssh —N -L 13389 : 127.0.0.1 : 3389 疇 - の様子を表したのカ咽 8 である。 myhome . dynamic-domain ・ JP つまり、ネットワーク環境カ畯わるたびに stunnel を止で SSH トンネルを作り ()g は才彳定しない ) 、 127.0.0.1 : 13389 め、別の設疋ファイルで stunnel を起動することになる。に対してリモート・デスクトッフ続することができる。このほしかし、頻度カ皜いと面倒になってくる。というわけで、うか素直なので、 SP2 ではこちらを使うほうがよいだろう。 Cygwin を使っている自分用に書いてみたのがリスト 1 のプログラムである 4 皆さんが作るプログラムの出発点となることを意図したもこの記事で想定している範囲内であれば、ネットワークのではあるが、簡単に説明しておこう。環境が変わったときにこのプログラムを実行するだけで、 12 行目 : sub ipaddr { その環境に応じた stunnel に切り替わる。自ホストの IP アドレスを戻り値として返す関数である。処理内容は以下のとおりである。これは Cygwin 用で、 ipconfig コマンドの出力から IP 1. すでに stunnel かいていればそれを止める。アドレスを取り出している。手許にある Red Had En- 2. 現在のネットワークエ竟を識別し、適切な設定ファイル terprise Linux と Solaris 用に作った ipaddr() 関数で stunnel を起動する。具体的には、 IP アドレスが 128 を、それぞれリスト 2 とリスト 3 に示す。 .1. *. * なら pop3smtp-proxy. stunnel という設疋ファ 25 行目 : sub stop { イルを使い、それ以外の場合は pop3smtp. stunnel とすでに stunnel などカ働いていれはイ亭止する ( 複数のプいう設疋ファイルを使う。ロセスカ働いていても対応できるようにしてある ) 。このプログラムは、そのまま使える性格のものではなく、 43 行目 : if ( $ipaddr ~ だ 128 \. 1 \ ・ / ) { この行以降でネットワーク環境を識別し、それに応じた 4 この記事に掲載したプログラムは、 http://www ・ geocities ・ jp/ 処理をおこなう。 Y0ma1991 / から入手できる。一三ロ 127 ℃℃ . 1 : 25 自宅用 stunnel 127.0.0.1 : 110 127.0.0.1 : 25 136 UNIX MAGAZ 工 NE 2004. 11

3. UNIX MAGAZINE 2004年11月号

特集ボスト・ファイアウォールとネットワーク・セキュリティ図 1 ネットワークはポリシーに応じて分割 ( a ) ファイアウォール・べースの従来型ネットワーク分離ファイアウォール外部ネットワーク ( 外部ネットワーク用 ) ( 内部ネットワーク用 ) ( b ) ポリシーベースのネットワーク分離 ( 端末がポリシー 1 の条件に合致しない場合は、ポリシー 2 のネットワーク接続に変更 ) ポリシー 1 ファイアウォールポリシー 2 外部ネットワーク ( 外部ネットワーク用 ) ( 内部ネットワーク用 ) 者は設定をあまり変えたがらない傾向にあります。ポスト・ファイアウォールに求められること前節では、従来のファイアウォールに代表される境界防こまでに挙げた課題からも分かるとおり、ファイアウ衛セキュリティ・モデルの現状とその問題点について述べォールのようなネットワークの中間にある装置は端末の機ました。能拡張に追いついていません。したがって、ファイアウォ現在、これらの問題を解決するためにさまざまな試みがールの限界を乗り越えるには、端末での検査を強化するなおこなわれています。ど、端末側で対処するのがもっとも素直な方法でしよう。表 1 は、代表的なセキュリティ・モデルの概要をまとめとはいえ、このような端末側の機能拡張に完全に依拠すたものです。これら以外にも、いろいろな製品やモデルがるのは運用面での課題が多く、あまり現実的ではありませ検討されていますが、境界防衛モデルに代わる決定打はいん。現実的なアプローチとして考えられるのは、ファイまだに現れていないようです。アウォールと端末側の機能拡張の双方の長所をとりいれ、以下では、表に示した各モデルの特徴などをみていきま端末での検査結果に応じてネットワーク側でのフィルタリす。ング処理を変える動的なネットワーク制御でしよう。ただし、動的なネットワーク制御も技術的にはネ礬であり、「ネ分散ファイアウォール・モデルットワーク分離技術の課題」の節で述べる問題に直面しが分散ファイアウォール (Distributed Firewall) は、ちです。 1999 年に AT&T の Steven M. Bellovin 氏が発表しこれらの問題の発生を最小限に抑えるには、ネットワーたモデルです [ 1 ] 。ク・セグメントを物理トボロジーではなくボリシーに応じて分割し、ネットワーク制御の範囲を論理的に限定するここのモデルの基本的な考え方は、境界防衛の単位を端末とが重要です ( 図 1 ) 。従来のファイアウォールでも、外とし、各端末にファイアウォール機能をもたせて、それ部に接続するセグメントだけは DMZ (DeMilitarized ぞれが協調してセキュリティ管理をおこなうというもので Zone) として特別扱いで運用していましたが、内部セグメす。従来の境界防衛モデルにおけるネットワークの分け方ントについても同様な方針を徹底するわけです。 ( 、、信頼できる内部ネットワーク " と、、信頼できない外部ネットワーク " ) を変更し、境界を端末単位にまで小さくした具体的なネットワーク分離技術については、以降で詳しく解説します。モデルといえます。ボスト・ファイアウォールのモデル 30 UNIX MAGAZINE 2004. 11

4. UNIX MAGAZINE 2004年11月号

ネットワークとセキュリティ白畑真 Snort のインストールと運用今月は、オープンソースのネットワーク型侵入検知システムである Snort のインストールと設定、そしてセキュリティ・イベント分析ツールの BASE を紹介します。ネットワーク型 IDS とホスト型 IDS ・侵ノ財知システム (lntrusion Detection Systemo 以下、 IDS) は、ネットワークやホストへの侵入を監視するシステムです。 IDS にはさまざまなものがありますが、見対象からみて大きく 2 種類に分けられます。 1 つは、ネットワーク上のトラフィックを監視し、侵入を検知する、、ネットワーク型 IDS (NIDS)" で、もう 1 つは個々のホストの挙動を監視する、、ホスト型 IDS (HIDS)" です。ネットワーク型 IDS は、インターネットと内部ネットワークの境界などで得られたトラフィックを監視し、侵入に関連すると考えられる事象 ( セキュリティ・イベント ) を警告します。一方、ホスト型 IDS は、監彳寸象のホストにインストールし、ホスト上のログファイルやシステムコール、あるいはファイルの整合性を監視して、侵入と考えられる挙動を警告します。以下に、ネットワーク型 IDS とホスト型 IDS のおもなメリットとデメリットを示します。ネットワーク型 IDS ネットワーク型 IDS のメリットは次のとおりです。複数のホストがある環境ー、、の適用力易ネットワークを監視対象とするため、複数のホストを一度に監視できます。また、多数のホストにインストールする手間もありません。したがって、数百台、あるいは数千台のホストカ在するネットワーク環境でも比較的 UNIX MAGAZINE 2004. 11 簡単に導入できます。・ホストに手を加えないホストの外部で動作するため、ホストの性能に悪景彡響をおよばすことはありません。また、ホストがすでに侵入を受けており、そのホスト自体は侵入に気づいていなくても、ネットワーク上を流れるトラフィックから侵入を検知できる可能性があります。一方、デメリットとしては以下のような点が挙げられま暗号化トラフィックを検知できないネットワーク上で動作しているため、 SSL や SSH といった、暗号化されたトラフィックの内容を知ることはできません。したがって、侵入者が SSH を用いたコネクション上で攻撃をおこなった場合、ネットワーク型 IDS は侵入を検知できません 1 。・パフォーマンスに制約がある現在のネットワーク型 IDS は、動作させるマシンのスペックにもよりますが、数 Gbps のトラフィックを処理するのカ報界であるといわれています。 IDS の処理能力を超えた負荷がネットワークにかかると、侵入を正しく検知できない場合もあります。ホスト型 IDS す。 1 ホスト型 IDS のメリットは以下のような点です。暗号化トラフィックを検知できる SSL や SSH といったネットワーク上を暗号化されて流ネットワーク型 IDS では、暗号化された状態で特定のペイロードを諡寸象とすることは可能なので、バッフア・オーバーランを狙った攻撃などは検知できる可帽ゞあります。 79

5. UNIX MAGAZINE 2004年11月号

特集図 2 ネットワーク・トボロジーとオ芟オ郷竟界境界防衛ネットワーク接続時に検査検疫検査の境界一般的な防疫検査では、国内に存在しない感染症の病原体の侵入を防ぐために、 ~ トからの渡航者に対して検疫所での検査を義務づけ、感染症に罹っていないかどうか、媒介するおそれのある動植物などを携行していないかを調べ、必要に応じて隔離や駆除、消毒などを実施します。そのほかにも、輸入食品の検査トへの渡航者への予防接種など、幅広い対策がおこなわれています。これと同様に、 Quarantine Model では、ネットワークに接続しようとする端末に対してセキュリティ上の各種検査をおこない、セグメントへの接続の可否を決定する仕組みを導入します。従来のファイアウォールによる境界モデルと検疫モデルの大きな違いは、あるネットワークに参加する際、接辛噐末自身の安全生を確認する仕組みが導入される点にあります ( 図 2 ) 。ネットワーク構成としては、新たに追加されるオ芟サーバーによって端末状況のモニタリングをおこない、検査や治療いッチの適用など ) が施されます。このとき、必要最低限のネットワーク接続は確保できるようにするというのが基本的な考え方です。そして、複数のセグメントがある場合はそのそれぞれにネットワーク・ポリシーを設疋し、端末の検査結果に応じて収容セグメントを切り替えたり、ネットワークを分割しなおしたりする、ネットワーク分離 (network separation)" や、端末の状況カ畯わったら別のセグメントにつなぎ替える、、再登録 " といった仕組みも考えています。 UNIX MAGAZ 工 NE 2004. 11 ボスト・ファイアウォールとネットワーク・セキュリティ接続する端末自身の安全性カ明されなければ、ネットワークへの参加を拒否する、もしくはネットワークの利用になんらかの制限を設けます。これによって、ネットワークへのウイルスなどの蔓延を未然に防ぐとともに、端末に対してもセグメント内のセキュリティ・ポリシーを満たしていれば自由な接続カ駒束されます。図 3 に、このモデルの概要を示します。 Quarantine Model では、おもに下記の 3 つの機能を提供します。芟検査・ネットワークの分離・予謝告置検疫検査は文字どおり、接辛噐末のセキュリティ状況を検査する機能です。ネットワークへの参加時だけでなく、動的なモニタリングと組み合わせた定期的な端末状況の検査が必要と考えています。検査卩、」容は、ハードウェアおよびソフトウェアの構成、ソフトウェアの更新状況、セキュリティ・ソフトウェアの利用状況、ウイルスやワームの感染状況などです。検疫サーバーとネットワークでは、これらの情報のどこまでをみるかでセキュリティ・レベルを加減できるようにします。ネットワーク分離では、検疫検査の結果とネットワーク・ポリシーとを比較し、適切なセグメントに接続します。セキュリティ・ポリシーに違反した端末は、厳しいポリシーのセグメントにつなぎ替えられます。この機能については、 802. lx with PANA 、 DHCPv6 、 RA 、 TSP 、 DTCP 、 VLAN (IEEE802. (Q) などのプロトコルで制御するように実装の検討をおこなっています。予防措置は、セキュリティ・ポリシーへの違反が発見されたときの通知から始まり、ソフトウェアの更新やセキュリティ・パッチの適用、ワクチンウイルスの投与といった措置を施したうえで端末が接続を希望するセグメントにつなぎ戻すところまでを考えています。もちろん、これらは認証機構と組み合わせて実現します。認証機構も、各ネットワークでの継続性を考慮して、既存の機構をベースにする予定です。現在のところは、おもに検疫検査とネットワーク分離の手法の実装評価や要素技術の確立に取り組んでいます。 33

6. UNIX MAGAZINE 2004年11月号

特集端末のセキュリティ検査とネットワーク分割を実現しています。 NAC では、各端末にインストールしたエージェント・プログラムを用いて端末のセキュリティ状態などを収集します。これらの情報を、 802. lx の認証フレームワークと EAP (ExtensibIe Authentication Protocol) の拡張領域を用いてバックエンドの認証サーバー (RADIUS (Re- mote Authentication DiaI ln User Service) など ) に通知し、認証サーバー上で 802. lx でのアカウント認証と同時にセキュリティ認証をおこない、ネットワークへの接続の可否と、 VLAN による端末の隔離をおこないます。 Quarantine Model Quarantine Model は、 WIDE プロジェクトで検討が進められているポスト・ファイアウォール時代のセキュリティ・モデルです。このモデルについては、次の節で詳しく説明します。検疫モデルの例以下では、検疫モデルの例として Quarantine Model を紹介します。これは、 WIDE プロジェクトの secure6 WG (security of IPv6 Working Group ) 6 が主体となって検討しているセキュリティ・モデルです [ 4 ] 。想定しているネットワークいまや、ノート PC はデスクトップ PC の出荷量を上回るまでになりました。それにともない、コンピュータは机 - ヒに置いて使うものという見方も大きく変わってきています。ダイヤルアップ中心のモバイル環境については、無線技術の急速な浸透により、街角での無線アクセスポイントやホットスポットなどの利用も一般的になりました。今後、いわゆるユビキタスといわれる、いつでも、どこからでもアクセス可能なネットワーク接続環境はさらに普及していくでしよう。 6 http://www.wide.ad ・ jp/project/security-j. html ワーキング・グループ名に "IPv6" とあるのは、 IPv6 カ駈い将来のネットワークにおける主要な技術要素であること、そして、 IPv6 の普及によってグローバル IP アドレスを付けたエント末カ寸曽えても安全に通信できることカ要なポイントと考えているからです。 32 ボスト・ファイアウォールとネットワーク・セキュリティューザーとネットワーク管理者では、ユーザーのニースワーク環境に求めるものが異なります。このようなネットユーザーからみれば、どんなネットワーク環境においても、ネ礬隹な手続きや特別な制約なしにアプリケーションやサービスを自由に使えるのか理想です。しかし、現実には企業内ネットワークのように、ファイアウォールなどのアクセスルールやセキュリティ・ポリシーによって、ネットワークの利用に制約があるのが普通です。自分自身 ( 端末 ) の身の潔白を証明し、ネットワークの安全状況を確認することで、このような壁を越えて縦横無尽にネットワークカリ用できたら・・・・・・と考える人は多いでしよう。ネットワーク管理者のニーズさきほど述べたとおり、、、信頼できる内部ネットワーク " と、、信頼できない外部ネットワーク " といった区分をおこない、外部からの脅威に対しては境界で対処するといった方式では、いろいろな問題が発生し、限界があるのは目に見えています。やりとりされるデータはもとより、外部からのアクセス管理などについても、端末とネットワークの双方への安全性確保カ球められています。その一方で、ネットワークの内部・外部の枠を越えて移動するノードへの対応、そして、トラフィックの増大にも対処しなければなりません。 IPv6 が普及していけば、 IP ネットワークにつながる機器は質量ともに大きく増えるでしよう。従来の PC や PDA 、通信機器だけでなく、センサーなどの単一機能の軽量クライアントもネットワークに接続されるようになります ( すでに、そのような製品も登場しています ) 。 Quarantine Model の考え方の凧には、多様化するネットワーク環境において上記のようなユーザーと管理者の両方のニーズを満たす、より柔軟なネットワーク・セキュリティはどのようなものなのか、という視があります。 Quarantine ModeI の概要私たちカ甘是唱している Quarantine Model は、海外からの感染症の侵入を防ぐ、、防疫検査 " にヒントを得たものです。 UNIX MAGAZINE 2004. 11

7. UNIX MAGAZINE 2004年11月号

特集図 35 802. lx と EAP 拡張による端末認証サーバー 1 4 3 2 検疫サ ①認証要求 ②検疫検査要求 ③検疫検査結果を通知 ④認証結果を通知 58 現在、プロトコル上の制限や拡張方法など、検疫モデルルの拡張も必要となるでしよう。の配信の仕組みや仕様の標準化、場合によってはプロトコ報のほかに、検疫検査に必要な端末状態に関する情報など検疫モデルにおける検査と連携するには、通常の認証情いきません。せん。したがって、単純に利用すればよいというわけにはの利用法は、設言段階から考慮されていたわけではありまとづき、セグメントを切り替えるといった検疫モデル固有あります。当り前かもしれませんが、このような情報にも端末の検疫状態などは、つねに動的に変化する可能性がく簡易な端末言嬲リを利用して管理をおこないます。では、アカウントべースの認証や MAC アドレスにもとづいずれにせよ、既存のネットワーク分離や認証の仕組みこの節のまとめ残っています。に端末側に配信しておかなければならないといった問題がを実現するには、検疫検査に必要な脆弱性情報などを事前をおこない、その結果を検疫情報として送信します。これあります。ダイジェスト検査では、端末側で検疫検査処理また、権芟のダイジェスト検査などが必要になる場合もが制限されることがあります。制約などによって、検疫検査サーバーに通知できる情報量ただし、この手法では、相乗りする既存のプロトコルのトまたはネットワークへの接続を遮断する仕組みです。の結果により、セキュリティ・ポリシーに応じたセグメン検疫処理をおこないます ( 図 35 ) 。通常の認証と検疫検査ボスト・ファイアウォールとネットワーク・セキュリティの実装に必要な変更点や問題点などを明確にするため、試験的な実証環境の構築が WIDE プロジェクトの secure6 ワーキング・グループを中心に進められています。おわりにインターネットやネットワーク技術の発展にともない、利用者もネットワーク・セキュリティに対する、、自己責任 " の意識をもっことが求められているのかもしれません。たとえば、ネットワークに接続された端末がすべて自身でセキュリティ対策機能をもっことを前提とする、、自己防衛モデル " が、ネットワーク・セキュリティの理想的なモデルとなるのでしようか。すべての端末や利用者が、セキュリティ設定の管理や情報収集、フィルタリング・ルールの設定などについて、求められるレベルで管理するのはかなり難しいでしよう。すくなくとも、ウイルス対策やソフトウェア・アップデート、セキュリティ・パッチの適用状況をみるかぎり、現状の仕組みのままでこれらの条件を満たすのは不可能に近いとさえ思います。これを可能にするには、管理・設疋か容易で、設定やアップデートの漏れを検知し、修正を促す機構が必要になるでしよう。一方で、基本的なセキュリティ対策は、ネットワーク自体の機能として実装されるべきだという考え方もあります。いわば人体の免疫システムと同じように、ネットワーク自身 ( 具体的には、ネットワーク・トボロジー上のルータやスイッチ、 ISP のファシリティ上など ) にセキュリティ機能を実装・制御しようというものです。はたして、ネットワーク自身がセキュリティ機能をもつべきなのでしようか。それとも、ネットワークは無色透明の空気のようなものであるべきなのでしようか。今後のネットワーク・セキュリティのモデルを考える場合、個々のセキュリティ要素技術だけでなく、グランドデザインとしてのネットワーク・セキュリティの視点から、これらの疑問に明確に答えられるコンセプトが求められています。また、セキュリティをめぐるネットワーク管理者と利用者の考え方を近づけることも、大きな課題の 1 つです。ネットワーク管理者は、セキュリティ・ポリシーとして、外部アクセスを必要最小限に制限したいとつねに望むものです。なぜなら、許可する通信範囲が少なければ少ないほ UNIX MAGAZ 工 NE 2004. 11

8. UNIX MAGAZINE 2004年11月号

特集ファイアウォールは、すべてのバケットをそのサイトのセキュリティ・ポリシーと照らし合わせなければなりません。インターネットを流れるトラフィック量の増大、 UNIX MAGAZINE 2004. 11 ・フィルタリング・ルールの更新の難しさ一方、運用上の問題には次のようなものがあります。運用上の問題てしまう、モラルノ、ザードに陥りがちだからです。ク管理者に無断で暗引言やトンネル通信をおこなっ発生します。すなわち、エンドユーザーが、ネットワーを厳しく制約して使いにくくすると、別の大きな問題かセキュリティ面で問題があるからといって、暗号イ匝イ言てしまいます。ンネル通信技術により、ファイアウォールは無力化され場合、 SoftEther をはじめとする HTTPS を用いたト HTTPS 通信をすべて通過させざるをえません。その常業務でも頻繁に利用されるため、境界防衛モデルではん。とくに、最近は HTTPS を用いた暗号イ甬信は通扱いは、全通過か全遮断かのどちらかにせざるをえませしたがって、ファイアウォールにおける号イ甬イ言の取ウォールで完全に新するのは困難です。境界ではバケット内容の監査ができないため、ファイアイ信アプリケーションカ駛われているとネットワークいます。当然のことながら、 SSL や IPsec による暗号間でバケットの内容がチェックできることを前提としてファイアウォールによるネットワーク防衛は、通信の中暗号佃甬信による境界防衛の無力化析は、一般にきわめて難しいのが実情です。必要があります。このようなネットワークのトレンド解などにより、ファイアウォールの負荷を正確に把握する的におこなうには、トラフィック解析や応答時間の測定けではありません。ファイアウォールの負荷分散を効果ウォールを 2 台にしたからといって性能も 2 倍になるわて負荷分散をおこなう方法も考えられますが、ファイアいのカ状です。複数のファイアウォール装置を導入しありますが、このような負荷の増大に追随しきれていな最近のファイアウォールの性能向上は目覚ましいものがてファイアウォールの大きな負担になりつつあります。イルスの増加につれて、この照合処理は、質量両面におい電子メールやⅥ b トラフィックに含まれるワームやウホスト・ファイアウォールとネットワーク・セキュリティファイアウォールを用いたネットワークにおけるセキュ 29 ルの適切な更新カ攤しいこともあり、ネットワーク管理イアウォールを設置していても、フィルタリング・ルー難です。仮にこうしたアプリケーションに対応したファ定は、どのべンダーのファイアウォールでもきわめて困ルにあてはまらない SIP などのプロトコルに関する設ていません。とくに、クライアント・サーバー通信モデプリケーション固有のフィルタリングの設定には対応しごく一部のアプリケーションを除き、アールの多くは、多種多様になっています。しかしながら、ファイアウォ上の通信を利用するネットワーク・アプリケーションもインターネット技術の発展にともない、インターネット・アプリケーションの多様化への追随の難しさはないと仮定しているため、こうした攻撃は防げません。でも述べたように、ファイアウォールは内部からの攻撃ォールの内側から LAN 全体に広まってしまいます。上で LAN に再度接続された場合、ウイルスはファイアウ先のネットワークでウイルスに感染し、そのままの状態味をなさなくなります。たとえば、これらの端末力外出ネットワークの境界は、セキュリティの境界としては意ど ) へ持ち出すと、ファイアウォールによって定義されたユーザーが端末をネットワークの外部 ( 出張先や自宅ない、この前提は成立しなくなりつつあります。帯情幸崙末などの手軽に持ち運べる機器の普及にともなにしたシステムです。しかしながら、ノート PC や携のネットワークの、、外部 " からおこなわれることを前提ファイアウォールは、あるネットワークへの攻撃が、そ・移動端末の取扱いの難しさリング・ルール設疋をさらに難しくしています。イルスやワームの伝染はきわめて高速であり、フィルタなうのは不可能です。さきほど述べたように、最近のウウイルスに関する的確な知識なしにこれらの設定をおこイルタリング・ルールを設定しなければなりませんが、合、ネットワーク管理者はファイアウォールに新しいフ新しいウイルスやネットワーク攻撃手法が出現した場にとって、ひどく厄介です。に精通しているわけではないーー一般のネットワーク管理者グ・ルールの適切な言定は、すべてのセキュリティ問題ング・ルールだけで決まります。しかし、フィルタリンリティの強度は、ファイアウォールにおけるフィルタリ

9. UNIX MAGAZINE 2004年11月号

特集ボスト・ファイアウォールとネットワーク・セキュリティ図 34 検芟検査と DHCP タ歩里との (DHCP べースのセグメント分害 ! 旨との窈列 ) DHCP 検疫サーバーサーバーネットワーク分離技術の課題端末こまで、ネットワーク・セグメントを論理的に分割する技術についてみてきました。これらの技術を用いて検疫モデルに即したネットワークを言 t ・構築する場合、以下のような課題について検詞する必要があります。ポリシー定義の記述性・利便性 5 組織内でのセキュリティ対策に応じたネットワーク分離 6 ポリシーを設計する際には、柔軟な表記・謎手法が必要 ①旧アドレスの要求です。これらの論理言杢は、利用するネットワーク分離技 ②検疫セグメントのアドレスを配信術から独立したものでなければなりません。ある技術に強 ③検疫検査 ④検疫結果を通知く依存する設定ファイル以外にポリシーを表現するものが ⑤検疫セグメント旧アドレスの解放と旧アドレスの再要求 ⑥セキュリティ・ポリシーに沿ってセグメントのアドレスを配イない場合は、糸目織内ネットワークの変更・拡張、新たなネットワーク分離技術の導入や切替えといった事態への対応分離機能を制御するかたちをとります。たとえば、検疫検カ攤しくなります。特定のべンダーないし製品固有の管理ツールや設疋ファイルしかない場合も同様です。査結果に応じて、 DHCP サーバーに対して適切な IP アドレスを貸与するように通知するといったパターンが考えら可能なかぎり汎用的な形式でネットワーク分離を記述れます ( 図 34 ) 。し、個々の実装技術によるネットワーク分離設定へのマッピングカ易な仕組みが必要です。たとえば、管理者カ甘巴この手法には、既存のネットワーク分離プロトコルなどの変更カ坏要という利点があります。しかし、検疫検査処握しやすい表記、編集用のツール、ポリシー謎杢言語、制理→既存のセグメント処理といったように、処理川印の調御プロトコルなどの標準化が求められます。整や再検査時のセグメントの再区分などにおいて連携動作現在、これらの標準化に関する言翔侖は、 IETF の NET- CONF ワーキング・グループ 31 でおこなわれています。が必要になります。プロトコル統合型検疫検査プロセスとの統合既存のネットワーク分割技術のプロトコル上に、検疫検検疫モデルでは、検査→隔離 ( セグメントの切替え ) →治査の処理を組み込む手法です。 TSP のクライアントから療というプロセスを、各端末に対して適用します。そして、トンネル・プローカーへ送信される端末情報に検疫検査情検疫検査の結果に応じて、サイトのセキュリティ・ポリシ報を付加し、トンネル・プローカーからの返信として検査一定義に合ったセグメントに各端末を誘導しなければなり結果を受け取ります。ません。それには、検疫検査の結果とネットワーク分離の既存のプロトコルの拡張やオプション情報の追加などは制御を結びつける必要があります。必要ですが、ネットワーク分離処理の部分だけで解決できネットワーク分離機能と検疫検査プロセスの統合には、るところカ坏リ点です。大きく分けて、、プロトコル独立型 " と、、プロトコル統合型 " たとえば、 Cisco の NAC も基本的にはこのタイプに分の 2 つの手法があります。類されます。 NAC では、端末は 802. lx プロトコル上でやプロトコル独立型りとりされる EAP メッセージに、検疫検査に利用するセ検疫検査処理を、独立したプロトコル上で処理する手法キュリティ情報を付加して認証サーバーと通信します。認です。検疫検査を管理するサーバーから、各ネットワーク証サーバーは、 EAP の認証メッセージからこのセキュリティ情報を取り出し、検疫サーバーに問い合わせることで 31 http://www.ietf.org/html.charters/netconf-charter.html 1 3 4 一三ロ 57 UN 工 X MAGAZINE 2004.11

10. UNIX MAGAZINE 2004年11月号

特集図 12 802. lx のサポート対象外になる構成ハブリピータロロ 802. lx スイッチまた、 802. lx でスイッチの振舞いを制御できるとはいっても、制御カく範囲は基本的にスイッチのポート単位です。 802. lx は、サプリカントとスイッチは 1 対 1 で接続されていることを想定しているからです。したがって図 12 のような構成は、 802. lx のサポート対象外となります。このため、 802. lx を利用する場合は、 PC が直孑第妾続されるレイヤ 2 デバイスがすべて 802. lx に対応していなければなりません。 802. lx のポート制約の本質は、サプリカントと 802. lx オーセンテイケータが 1 対 1 で接続している構成とみなすことにあります。ですから、論理的にそうみなせる接続をしているのなら、その接続単位で開け閉めをおこなうことも可能です。たとえば、無線 LAN には端末を収容する、物理ポート " はありませんが、端末と無線チャンネルのバインディングを、ポート " とみなすことで 802. lx に対応しています。検疫ネットワークと 802. lx 802. lx を応用したネットワークう財支術の 1 つにき刃証 VLAN があります。図 11 に示した 802. lx のプロトコル・ハンドシェークを用いてユーザー認証をおこない、その結果によってオーセンテイケータがサプリカントの所属する VLAN を決定する才翅孑です。同じ要領で、 802. lx によりサプリカントの本芟情報を通知し、セキュリティ・レベルによる動的なネットワーク分割をおこなうことも可能です ( 「検疫モデル」の項で紹介した Cisco の NAC は、まさにそのような原理で動いています ) 。ただし、 42 こで実現できるのはあくまでレイヤ 2 の分割ボスト・ファイアウォールとネットワーク・セキュリティまでで、それよりも上の層の分割については別の視で考える必要があります ( たとえば、新しいネットワークでの IP アドレスの学習、旧いネットワーク設疋の廃棄、アプリケーション固有の設定を新しいネットワークに適したものに更新することなどについて考えなければなりません ) 。また、 EAPOL は IP 層ではなく Ethernet 層で認証情報を交換するため、 EAPOL のデータ長は Ethernet の MTU 未満である必要があります。この制約は、検疫清報を財芟技術」の節で挙げたような汎用的な XML 形式で送信するときに大きな問題になると思われます。 PANA ネットワーク・アクセス認証プロトコル皆さんがインターネットやイントラネットに接続するとき、ユーザー名とパスワードの入力などの認証手続きを求められることがあります。たとえば、ダイヤルアップや無線 LAN ホットスポットでの接続などの場合です。一般に、ネットワークへのアクセスのための認証手続きとして実行されるネットワークアクセス・クライアント似ード、クライアント ) とアクセス先ネットワーク内のクライアントを認証するエンティティ ( 以下、認証工ージェント ) とのあいだの通信手順を、ネットワーク・アクセス認証プロトコル ( 以下、アクセス認証プロトコル ) と呼びます。従来のアクセス認証プロトコルは、無線 LAN ホットスポットなどで使われている HTTP (Hyper-Text Trans- fer ProtocoI) を用いたアプリケーション層での認証を除き、データリンク層で定義されてきました。認証フェーズをもつ PPP (Point-to-Point Protocol) [ 7 ] や 802. lx カその一例です。 PPP では、アクセス認証プロトコルがデータリンク・プロトコルのなかに含まれています。アクセス認証プロトコルと EAP アクセス認証プロトコルに必要な機能の 1 つに、 EAP のサポートがあります。 EAP は、さまざまな認証メソッドに対応するフレームワークを提供する認証プロトコルです ( 認証メソッド自体もプロトコルです ) 。図 13 に証メ、川い口ソッドとして MD5-ChaIIenge を用いた場合の EAP の動作例を示します。アクセス認証プロトコルが EAP をサポートすることに UN 工 X MAGAZINE 2004. 11