図 10 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1056 1057 1058 1051 1052 1053 1054 1055 連載 / IPv6 の実装ー⑩ IPv4/IPv6 以外のアドレス・ファミリーの場合のタ里 default : family) ) ; "unknown address family=%d. \ " ipseclog( (LOG—DEBUG, "key-allocsa: continue ; goto found ; break; sizeof(sin) ; SI Ⅱ . Sin_len bcopy(dst , &sin. sin—addr, sizeof(sin. sin—addr)) ; if (key—sockaddrcmp ( (struct sockaddr*)&sin, (struct sockaddr * ) &sav—> sah—>saidx. dst , 0 ) ! = 0 ) continue ; 芝芋点では、 IPv4 と IPv6 以外のアドレス・ファミリー の SAD 工ントリ検索には対応していません ( 図 10 ) 。 1077 splx(s) ; 1078 return NULL ; 検索条「牛に適合する SAD 工ントリが発見できなかった 場合、 1080 1081 1082 1086 1087 1 , 078 行目で NULL を返します。 found : splx(s) ; sav—>refcnt 十十 ; SAD 工ントリはアドレス・ファミリーに依存しないた め、 IPv4 アドレスをもつ場合もあれは、 IPv6 アドレス をもつ場合もあります。 key-allocsa() の呼出し時に検索 条件としてアドレス・ファミリー (family) を指定してい るので、確認中の SAD 工ントリカ甘旨定されたアドレス・ ファミリーの終点アドレスをもっているかを調べます。 key-allocsa() で IPv4 アドレス・ファミリーの検索か 指定されている場合は、確認中の SAD 工ントリが IPv4 アドレスをもっていると仮定して上交します。 keysock- addrcmp() はアドレス・ファミリーに応して 2 つのアド レスを上交する関数です。 1059 case AF_INET6 : 条件に適合する SAD 工ントリがみつかったら、 SAD 工ントリの参照カウンタ (sav->refcnt) を増やし、発見 したエントリを返します。 SAD 工ントリは参照カウンタて管理されるため、 key- allocsa() で検索した SAD 工ントリが不要になったら keyfreesav() て解放しなけれはなりません。 1117 void 1118 key—freesav(sav) 1119 1120 { struct secasvar 1060 1061 1062 1063 if (key-sockaddrcmp ( (struct sockaddr * ) dst , (struct sockaddr *)&sav—> sah—>saidx . dst, 0 ) ! = 0 ) continue ; break; keyffreesav() は解放する SAD 工ントリへのポインタ を引数にとります。 1 , 059 ~ 1 , 063 行目は IPv6 の SAD 工ントリの検索 カ甘旨定されている場合のアドレス上交です。 IPv4 の場合 はいったん sockaddr-in 構造体に上交対象となるアドレ スをコピーしており、 IPv6 の場合 ( 鹵耐妾 key-sockaddr- cmp() を呼び出しています。これは旧いコードの名残で、 現在は IPv4 でも単純に keysockaddrcmp() を呼び出 すだけで動胙します。 UNIX MAGAZINE 2003.5 1125 1130 1131 1133 1134 } sav—>refcnt— if (sav—>refcnt = の key—delsav(sav) ; return ; 1 , 125 行目で参照カウンタ (sav->refcnt) を減らしま す。カウンタが 0 になった場合、その SAD 工ントリは 誰からも利用されていないことになるため、 key-delsav で SAD 工ントリを削除します。 75

最新スよリー ミング動向② 図 10 Web サーパー側だけてアクセス制胸をしている場合 Web サーバー リームや翅 会員の方は ログインしてください ログイン画面へ 会員認証 会員ログイン ユーザ - 名 ho e パスワード 会員限定ページ リーム物 : ようこそ h 内 e さん ライプは以下を クリックしてください ! 認証設定 - 旧アドレス -ID. Password 4 PLAY! メタファイルの中身 : rtsp://stream. server/member/content. rm 正規会員 入手 ストリーム ストリーム・サーバー側で Web と同じ認証をしていな いと、会員以外の第三者にアクセスされてしまう 第三者 ( 非会員 ) ューサーがストリームを視聴するときは、最初に Web に直接アクセスすると、 こでは IP アドレスの制限が ページを閲覧し、ストリーム再生用のリンクボタンをクリ ないために、ストリームの再生ができてしまいます。 ックすることで、はしめてストリーム再生カ始まります。 2. Apache の Basic 認証でパスワード認証をおこなって いる場合 もうすこし別の観点からみてみましよう。多くの場合、 こちらも 1 と同様で、 Basic 認証で作成したユーサー Web サーバーとストリーム・サーバーは別のシステムに ID とパスワードの組をストリーム・サーバー側にも登 なっています。これか何に景グするかというと、たとえは 録しておかないと、権限のない第三者が簡単にアクセス Web サーバーで IP アドレスやパスワード認証によるア できます。 クセス制限をおこなっていても、ストリーム・サーバー側 可も対策を施さないと、ストリーム・サーバーではアク このように いくら Web サーバーで制限してもスト セス制限ができないことになるわけです ( 図 10 ) 。 リーム・サーバー側て対応していなければ、第三者による 例をいくっか挙げてみましよう。 アクセスを許可する、いわゆる、、選充 " 現象か起き、自社 会員向けに用意した配信サーバーへ他社のユーサーがアク 1. Web サーバーで IP アドレスによるアクセス制限をお セスし、配信サーバーやネットワークのリソースを消費さ こなっている場合 れてしまいます。 Web サーバーへの接続では、クライアントの IP アド 一時は乱立会柑ごった ISP も、去も丘の ADSL などの レスを参照し、許可されているアドレスか否かでページ の表示 / 非表示を切り替えます。ところが、リンク先の 常日罸妾続系サーピスの一十金化により、淘汰カまってい ます。そのなかで、他社よりも立に立っためのサーピス メタファイルに記述されているストリーム・サー で、同じポリシーにもとづいて IP アドレスのアクセス 品目の 1 っとして、高品質なストリーミング・コンテン 制限をかけていないとうまくいきません。たとえは、許 ツの自社会員向けプロードバンド配信がすでに多くの ISP 可されていない IP アドレスをもつ第三者が、メタファ で実施されています。このような自社会員限定のリソース イルの中身を友人などから聞いてストリーム・サーバー をライバル会社のユーサーに消費されたのでは、たまった 131 UNIX MAGAZINE 2003.5

連載 / IPv6 の実装ー⑩ 図 8 SAD の本告 secashead 構造体 S aht ree ー・一一 -- - ー Cha 土 n saidX savtree [LARVAL] savtree [MATURE] savtree [DY 工 NG] savtree [DEAD] secasindex* 冓〕告イ本 secashead 構造体 chain saidX savtree [LARVAL] savtree [MATURE] savtree [DY 工 NG] savtree [DEAD] secasvari 冓〕告イ本 chain secasvar* 冓〕告イ本 Chain トトトと secasvar* 冓〕告イ本 Chain secasvart 冓〕告イ本 Chain secasvar* 冓〕豈イ本 chain secasvar* 冓〕告イ本 chain secasvar* 冓〕告イ本 Chain secasvar* 冓〕告イ本 Cha i n 図 9 savtree のメンパーの確認 1006 for (stateidx = 0 ; stateidx く arraysize; stateidx 十十 ) { saorder_state_valid[stateidx] ; state 1007 LIST_FOREACH(sav, &sah—>savtree [state] , chain) { 1008 工ントリの確認へ進みます。 if (family ! = sav—>sah—> 1015 saidx. src . ss—family Ⅱ family ! = sav—>sah—> switch (family) { saidx . dst . ss—family) contlnue ; 1047 ~ 1 , 069 行目は、 SAD 工ントリの終点アドレス ~ 1 , 017 行目で、 key-allocsa() に検索条件とし 1 011 と、 key-allocsa() に指定された終点アドレス条件の上交 て渡された情報と、 SAD 工ントリカ尉寺している以下の です。 SAD 工ントリの検索に始点アドレスは利用されま 3 っ窈帯にを比較します。 せん。終点アドレスと SPI 値で SAD 工ントリが一亠 決定できるからです。匆期のコードでは始点アドレスも比 ・ IP セキュリティの不重ま頁 (sav->sah->saidx. proto) 較していましたが、現在では該当する部分はコメントアウ ・ SPI 値 (sav->spi) トされています。 始点 ( 終点 ) のアドレス・ファミリー saidx. src. ss-family) 1048 case AF_INET: bzero(&sin, sizeof (sin) ) ; 1049 これらの情報が 1 つでも異なっていれは、次の SAD sin. sin—family = AF—INET; 1050 1016 104 7 1017 (sav->sah-> 74 UNIX MAGAZINE 2003.5

最新ス リーミング動向② 図 11 自社ネットワーク内でのアクセス制限 自社会員 ロ ISP-A 自社ネットワーク ストリーム配信サーバー serverA access-list 100 permit ip ISP-A-CIDR-I host serverA access-list 100 permit ip lSP-A-ClDR-2 host serverA access-list 100 permit ip lSP-A-ClDR-3 host serverA access-list 100 deny ip any host serverA ものではありません。前回も簡単に紹介しましたが、この ような事態を避ける去をいくつかのパターンに分けて説 明します。 自社会員なら誰でもよい場合 これは、大きく 2 不鶤頁に分けられます。 1 つは、 ACL (Access Control List) などを記述し、自社会員以外から のアクセスを拒否する方法です。もう 1 つは、自社ネッ トワーク内からはアクセスできても、他社ネットワークか らは到達不可能なネットワークを構築し、そのなかに配信 サーバーを設置する去です。 アクセスリストを記述する 自社の CIDR70 ロックでアクセス制限をおこなう方法 です。基本的に、自社会員以外は IP アドレスもしくは 上位レイヤでアクセスできないように設定します。たとえ ば、次のような手法か考えられます。 す。利用しているサーノヾーのマニュアルで、 IP レイヤ これは、プラットホームごとにさまざまな方法がありま ストリーム・サーバー側で IP アドレスによるアクセス 132 リストを記述する ロ 他社会員 他社ネットワーク UNIX MAGAZINE 2003.5 ート番号へのアクセスは許 - 可、その他は拒否するように 基本的には、自社会員の CIDR プロックからの該当ポ ける必要があります。 るため、 TCP/80 についても同様にアクセス制限をか また、それぞれのメディアでは HTTP 経由でも配信す WMT なら MMS ( TCP / 1755 ) について設定します。 Media や QuickTime などでは RTSP ( TCP / 554 ) 、 るアクセスリストの言当も可能です。たとえは、 Real- また、ストリーム配信に使う TCP のポート番号によ 否するように ACL をします。 ントへ到達可能にし、そオび人外のネットワークからは拒 ワーク装置の背後にあるストリーム・サーバーのセグメ す。自社で使用する CIDR プロックからは、ネット の手前にあるネットワーク装置で記述することもできま IP アドレスのアクセスリストは、ストリーム・サーバー われる TCP フィルタを記する ( 図 11 ) アドレスによるアクセスリストを言当するか、配信に使 ・ストリーム・サーバーの手前のネットワーク装置で IP らのアクセスを拒否します。 的には、自社会員の CIDR プロック以外のアドレスか における ACL の言当こついて石忍してください。基本 のアクセスリストにより許可されない ' 外部からのアクセスは、旧アドレス制限

連載 / Linux のプートプロセスをみる一① ( 今回の場合は sys-execve()) を呼び出します。 サービスルーチンを呼び出すまでの処理は 2003 年 3 月 号で詳しく説明したので、そちらを参照してください。 sys-execve() は、 arch/i386/kernel/process. c で定 義されています。 int sys—execve (struct pt—regs regs) 0774 : 0775 : { 0776 : 0777 : 0778 : 0779 : 0780 : 0781 : 0782 : 0783 : 0784 : 0785 : 0786 : 0787 : 0788 : 0789. int e てて or ; Char * filename ; if (IS-ERR(fi1ename)) # メモリ割当て error = ( 10 Ⅱ g ) filename; # 工ラー番号 filename = getname((char * ) regs. ebx) ; goto out ; # に失敗した ? if (error current—>ptrace putname (filename) ; out : return e てて or ; 779 行目の regs. ebx には、 152 ら復帰するとき、ソフトウェア割込みを発生した次の命令 て実装されています。そして、 CPU は割込みハンドラか Linux のシステムコールは、ソフトウェア割込みによっ 取得したメモリプロックを解放するマクロです。 786 行目の putname() は、 779 行目の getname() で 返ってきます。 execve の処理に成功すると、 do-execve() から 0 が 次の項で説明します。 783 行目で呼び出している do-execve() については、 ているのです。 リを守るために、アドレスにアクセスする前にチェックし もあります。そこで、カーネルは不正なアクセスからメモ れるため、その引数に不正なアドレスが与えられる可能陸 通常、システムコールはユーサープロセスから呼び出さ ピーします。 しいメモリプロックを割り当てて、そのなかに文字列をコ ( 言もムみアクセスの可否 ) をチェックし、有効であれは新 して、 getname() は、 regs. ebx カ甘旨すアドレスの有効生 である、、 /sbin/init" のアドレスかオ内されています。そ error = do_execve (filename , execve の 1 番目の引数 & = NPT_DTRACE ; = 0 ) # execve 処理に成功した &regs) ; (char * * ) regs ・ edx, (char * * ) regs ・ ecx, から実行を再開します。しかし、 execve システムコール の場合は、、、ちょっとしたからくり " によってまったく異 なる位置から再開します。つまり、 CPU は init() の 829 行目の次の行からではなく、新しいプログラムのエントリ ポイントから実行を始めます。このからくりについては、 あとで詳しく説明します。 そして、このとき、プロセス番号 1 のプロセスは、も はやカーネルスレッドではなく、ユーサープロセスとして 新しく生まれ変わります。 do—execve do-execve() は、コマンドライン引数や環境変数の文字 列をコピーしたり、ファイルのパーミ、、 : ノ / ョンク ) チェッ クなど、実行ファイルの形式に依存しない事前処理をおこ ないます。そして、最後に linux-binfmt の load-binary を呼び出して実行ファイルをロードします。 do-execve() か呼び出された直後のスタックの状態を 図 1 に、引数のポインタカ甘ー内容を図 2 に示します。図 に記したアドレスは、 init() の 130 ~ 131 行目の文字列と その配列か配置されたアドレスです。ただし、これらは私 がコンパイルしたカーネルでの値であり、コンパイル・オ プションの j 尺によって異なります。 変数 filename カ甘旨すアドレスは、 sys-execve() の 779 行目で getname() によって割り当てられたメモリプロッ クです。このなかには、文字列、、 / sb ⅲ / init " かオ褓内され ています。 そして、変数 argv と envp カ甘旨しているのは、 init() の 130 ~ 131 行目の argv-init と envp-init かオ各糸内され ているアドレスです。 do-execve() は、 fs/exec. c で定義されています。 0856 : 0857. 0858 : 0859 : 0860 : 0861 : 0862 : 0863 : 0864 : 0865 : 0866 : int do—execve (char *filename , Char **argv , Char **envp , struct pt—regs *regs) s t ruct 1 inux—b inprm bprm ; struct file *file; int retval; int 土 ; open—exec(filename) ; retval = PTR—ERR(fi1e) ; if (IS-ERR(fiIe) ) file UNIX MAGAZINE 2003.5

連載 / 旧 v6 の実装ー⑩ 図 1 SAD 工ントリの検索 733 740 739 734 if ( (sav = key—a110csa(AF-INET6 , (caddr-t)&src—sa, IPPROTO_AH , spi) ) goto fail; (caddr-t)&dst-sa, 認証ヘッダの入力処理 684 ah6—input (mp, offp, proto) 683 int 明記していないコードは ah-input. c からの抜粋てす。 されていないかどうかを石忍します。以後ファイル名を 認証ヘッダは、入力した IP バケットか転全中で改竄 685 686 687 { struct mbuf **mp , int *offp, proto; ah6-input() は 3 つの引数をもちます。 mp は入力し た IP?NO ケットかオ褓内された mbuf へのポインタ、 offp は IP'NO ケットのうび頁アドレスから認証ヘッダの : 頁アドレ スまでのオフセットで、 proto には認証ヘッダのプロトコ ル番号である 51 か設定されます。 IP6_EXTHDR_CHECK (), off , sizeof (struct 706 (h) , IPPROTO_DONE) ; 707 ah = (struct ah * ) (mtod(m, caddr—t) + off) ; 706 ~ 707 行目で、ヘッダ処理に必喫な清幸肋ゞ連続した メモリ領域に配置されているかを石忍します。認証ヘッダ のう巨頁を示すポインタ変数 ah 経由で認証ヘッダ内部の 報にアクセスするため、認証ヘッダ全体里続したメモリ 領域に配置されていなけれはなりません。 ip6 = mt0d (m , struct ip6—hdr * ) ; 716 717 nxt = ah—>ah_nxt ; 716 行目で、 IP バケットの情報をポインタ変数 ip6 経 由て参照できるようにします。 nxt には認証ヘッダの次に 続く刻に、ツ久もしくは上位層プロトコルの番号が定 されます。 720 if (ip6-getpktaddrs(m, &src—sa' &dst-sa) ) ip6-getpktaddrs() を呼び出し、スコープ情報付きの始 点 / 終点アドレスを src-sa と dst-sa に取り出します。 SAD の検索 認証ヘッダの処理では、ます受信した認証ヘッダに対応 する SAD (Security Association Database) 工ントリ があるかを石忍します。 724 spi = ah—>ah—spi; SAD 工ントリは、 SPI (Security Parameter lndex) と受信ノードの IP アドレスの組により、ノード内で一 諸、リ、 に識別することができます。 SPI には通信している 2 者間 であらかじめ合意された値カ硬われるので、 SPI をキーに して SAD 工ントリを特定できます。 SPI の値は認証ヘッ ダに含まれています。 724 行目で、認証ヘッダに指定され ている SPI 値 (ah-spi) を取り出します。 if (ntohs (ip6->ip6—p1en) 726 730 731 } goto fail ; 721 goto fail; KAME では、バケットの始点 / 終点アドレスを参照 する際に、 IP バケットに埋め込まれている値を参照しま せん。スコーフ情報が欠けているからです。 720 行目で、 UNIX MAGAZINE 2003.5 726 ~ 731 行目は巨大ペイロード・オプションのチェ ックです。巨大ペイロード・オプションが使われている と、認証ヘッダは利用できません。巨大ペイロード・オプ ションか利用されている場合、 IP バケットのペイロード 長 (ip6-plen) は 0 に設定されています。ペイロード長が 0 であればバケットを破棄します。 733 ~ 740 行目 ( 図 1 ) で、 SAD 工ントリを検索しま す。 key-allocsa() は、引数て指定された条件に適合する SAD 工ントリを検索し、変数 sav にポインタを設定しま す。 sav は secasvar 構造体のポインタ変数です。 733 ~ 734 行目では、 IPv6 の SAD 工ントリ (AF-INET6) で、 始点アドレスと終点アドレスが入力した IP'NO ケットの始 点アドレス (srcsa) と終点アドレス (dstsa) 、 IP セキュ リティの不頁か認証ヘッダ (IPPROTO-AH) 、 SPI 値が 入力した IP バケットで指定されていた値 (spi) であるも 67

図 11 3746 3747 3748 3749 3750 3751 3752 3753 連載 / IPv6 の実装ーの 内側の IP ヘッダの情報の取出し bzero(&isrc, sizeof(isrc) ) ; bzero(&idst , sizeof (idst) ) ; isrc. sin6—famiIy = idst . sin6—fami1y = AF_INET6; sizeof(struct sockaddr_in6) ; 1Src . sin6_len idst . sin6_1en m—copydata(), 0ff + offsetof (struct ip6—hdr, ip6—src) , sizeof (isrc . sin6—addr) , (caddr-t)&isrc. sin6_addr) ; m—copydata(), 0ff + offsetof (struct ip6—hdr, ip6—dst) , sizeof (idst . sin6—addr) , (caddr-t)&idst . sin6_addr) ; と odst にはトンネルモード・バケットの外側の始点 / 終 占アドレスかオ内されます。 た始点 / 終点アドレスを内側の IP ヘッダにもつようなト ンネルモードの SPD ェントリを検索します。 if ( ! sp) 3762 3739 3740 3741 3742 3743 (struct sockaddr—in6 *)&sav—> Sin6 3763 return 0 ; if if sah—>saidx . dst; (sin6—>sin6—famiIy ! = AF—INET6) return 0 ; ( ! SA6_ARE_ADDR_EQUAL(&0dst , sin6) ) return 0 ; 受信したトンネルモードのバケットに対応する SPD ェ ントリが存在しなかった場合 ( 3 , 762 行目 ) 、トンネルモー ドとしての処理を継続することはできません。 3 , 739 ~ 3 , 743 行目は SAD 工ントリの終点アドレスの 石俿忍です。 SAD 工ントリの終点アドレスが外側のバケッ 3760 sp = key—gettunnel ( (struct sockaddr * ) ッダの情報を茁妾 m-copydata() を使ってコピーします。 アドレス情報は mbuf に言当求されないため、内側の IP へ 点 / 終点アドレスを isrc と idst に取り出します。内側の 3 , 746 ~ 3 , 753 行目 ( 図 11 ) では内側の IP ヘッダの始 ません。一種の正当性の確認です。 出されているかぎり、この判定でエラーになることはあり しているので、 ipsec6-tunnel-validate() が正しく呼び ドレス・ファミリーを含めた条件で SAD 工ントリを検索 -tunnel-validate() を呼び出す前に、 key-allocsa() でア トの終点アドレスと同一であることを確認します。 ipsec6 3764 3766 3767 } key—freesp(sp) ; return 1 ; 3761 &osrc , (struct sockaddr *)&odst, (struct sockaddr *)&isrc , (struct sockaddr *)&idst) ; 3 , 760 ~ 3 , 761 行目は SPD 工ントリの石俿忍です。トン ネルモードでバケットを受信したということは、 IP セキュ リティ・トンネルで通信するためのセキュリティ・ポリ シーカ疋されていることを意味します。セキュリティ ポリシーの定義なしにトンネルモードのバケットを受信す ることはできません。なぜなら、トンネルバケットを装 った攻撃バケットである可能性があるからです。 key-get- tunnel() は、第 1 、第 2 引数で指定した始点 / 終点アド レスを外側の IP ヘッダにもち、第 3 、第 4 引数て指定し 78 key-gettunnel() は SPD 工ントリの参照カウンタを増 やすので、 3 , 764 行目で key-freesp() を使って SPD 工 ントリを解放します。 ☆ 次回は認証ヘッダの出力処理を解説します。 ( しま・けいいち IIJ) [ 赭文献 ] [ 1 ] Stephen Kent and Randall Atkinson, IP 員社 t ん e れ ca ー 0 れ Header, RFC2402 , November 1998 [ 2 ] K. K. Ramakrishnan, Sally Floyd and David L. Black, The 員 d 市 0 れ可 E ェ〃 c C07 四 es 0 れル ca 0 れ (ECN) to IP, RFC3168 , September 2001 UNIX MAGAZINE 2003.5

Se ( リ「 i ツ Sym P05 ⅳ m USENIX と述べた。 Wayland は、 B. MiIIer によるバイオメトリッ ク認証の定義、、、行重丿岸または生理学上の性質にもとづく 生きた人間個人の自重垢忍証もしくは身言寉認 " に賛同して いる。 Wayman によれは、バイオメトリック・アルゴリズム の技術的な匪能を評価するための測定基準は、登録ミス、 取得ミス、孑第周生、孑第生である。取得ミスは装置が認識 に失敗する頻度を測る尺度で、背景カ囀暗くて顔面認識シ ステムか顔を認識できない場合などが当てはまる。登録ミ スはさらに重要な測疋基準であり、バイオメトリックカ畤 定のグループに属する人びとをあらかしめ除外するかどう かを測る尺度である。たとえは、指紋走査装置は老人や幼 児には効果的に使えない。なせなら、こうした人たちは指 紋がはっきりしていないからバイオメトリックは社会 及員全体に使用できるわけではない。 現行のバイオメトリック評価には、技術、科学的モデ ル、脆弱蹶セキュリティ、運用試験が含まれる。将来的 には、費用対効果分析、竟試験、人間の知覚反応、そし てユーサーの態度も評価の対象にする必要がある。検言吉 果は、特定の環境 -- ドにある人びとのみを対象にしている。 サンディア研究所とその近くにあるカークランド空車基地 で手のひら認証システムのテストをおこなったところ、 2 つのバイオメトリックエ竟では異なる結果が出た。 Wayman は、大規模なデータベースで使われる検索手 法について質問を受けた。彼は、データベースは一ヨ殳に性 別などのほか、いくつかのバイオメトリック的な特徴にも とづいて区分されると答えた。このようなシステムの脆弱 性の検証についての質問には、顔面識別システムが人間の 顔と写真を区別できないことを例に挙げ、館 E の必要性を 孑商した。 最後に、 Wayman はバイオメトリックの装置や研究の 前途にある長い道のりについてあらためて言及した。 ネットワーク望京鏡小さな、あるいは也のセキュリ ティ・イベント俿見察 David Moore ( サンディエゴスーノ、一コンピュータ・セ ンター、 CAIDA) を告 : Lou Katz David Moore カ呂介した興蠅耒い実験は、特定のアド レス空間に届く予想タ ) バケットを調査することで、避鬲 ネットワークのイベントを監視するというものだった。 UNIX MAGAZINE 2003.5 の構成、つまり、、ネットワーク望遠鏡 " による調査では、 正当なトラフィックがほとんど、あるいはまったく期待で きないグローバル・アドレス空間の一部を使用する。この アドレス空間に届くトラフィックを監視すると、遠母也で 起きた一定のイベントを検出できる。 天体望遠鏡を使った星の観察にたとえれば、ネットワ ーク望遠鏡の操作や特徴が理解しやすいだろう。ネット ワークの監視では、アドレス空間が不連続のアドレス空間 として大きくなればなるほど、ネットワーク望遠鏡の、、レ ンズロ径 " も大きくなる。ネットワーク望遠鏡か大型にな ればなるほど、より短い時間と低いバケット転送率で広 い範囲を分析できるので、イベントの開始時刻や終了日駭リ (Code Red が 10 バケット / 秒の速さでひろがっている など ) をより正確に特定することができる。 Code Red と 広域 DoS 攻撃のいすれの観測も可能である。データは、 監視対象のネットワークの手前にあるパッシフ型の受信装 置で集められる。 攻撃者は、無作為に選んだ発信元アドレスになりすま す。望遠鏡に捉えられるのは、この、、後方散乱 (back- scatter)" である。後方散乱を分析することにより、 DoS 攻撃の定量イゞ可能である。興飛架いことに、監視対象の アドレス空間は、観察されるトラフィックにプラスにもマ イナスにも景紫す - る可能性がある。なぜなら、ある種のイ べントは、拡散のために発信元アドレスにド幇妾するアドレ ス空間を優先的に使用する傾向があるからだ。これらのア ドレスか無作為に選び出される過程は不明である。ネット ワーク望遠鏡による観測を開始した当初は、攻撃をイ」曲け る側は望遠鏡の存に気づいていなかった。その後、望遠 鏡が監視している IP 空間や望遠鏡そのものへの攻撃を意 図的に避けている節がある。 イベントの検出力は、監視対象のネットワークの規模 に比例する。 / 8 望遠鏡は 1 ~ 2 秒で攻撃を検出できるが、 / 24 鏡では 58 日かかる可能性がある。 / 8 ネットワー クは感染を正確に j 毆亦できるが、 / 16 ネットワークでは時 間的なすれがあり、グラフの廾爿大が正しくない。ログのグ ラフに関しては、 / 16 は曲線の角度には間題ないものの、 時間が正確ではない。 / 16 の曲線を / 8 の曲線に逆挿入す る耳はみか進められている。 こまでの話をまとめると、攻撃の数は多く、 600 , 000 バケット / 秒を超えるものすらある。ほとんどの攻撃は短 173

リーミング動向② 最新ス 図 12 IP ェニーキャスト酉 ロ Redistributed static route-map xyz ISP B の ネットワーク ISP A の ネットワーク ストリーム配イ ストリーム配信 ・ OSPF の経路 ー静的な経路 Redistributed static 「 oute-map xyz BGP では、相互に xyz で設定するサ ブネットの経路交換をしない一 設定します。 に閉して糸齧各広告し、各 ISP でまったく同じ IP アド レスの配信サーバーを自 AS 内に確保するという手法で これらの対策を施しておけは、自社会員以、タ ) ストリー した。これは、 OSPF の host route の成疋で夫見で ム・サーバーへのアクセスを拒否することができます。 きます ( 図 12 ) 。この方法の利点は、メタファイルが 1 自 AS 内でのみ広告する糸に酉言サーパーを置く つの配信アドレスに限定できることです。その反面、経 路のふらっきの間題カ吽じたり、ェニーキャスト・サー これは、ユニキャストによる配信とマルチキャストによ バーが過負荷状態になったときの運用などが鮹夬すべき る配信の 2 不鶤頁か考えられます。 譏題として残っています。 ・ユニキャストによる配信 ・マルチキャストによる配信 ( 図 13 ) 他社 AS へは広告せす、自社 AS 内にだけ糸習各を広告 現在の国内ネットワークでは、マルチキャスト網の相互 するアドレス範用を設定し、事実長自社会員しかアク 接続は完備されていません。そこで、自 AS 内だけに経 セスできないネットワーク環竟を用意する手法です。他 路広告するマルチキャスト・アドレスによる配信をおこ 社のネットワークからのアクセスは不可能なので、自社 ない、ユニキャスト配信でポトルネックとなるような一 のネットワーク内にのみ配信することができます 極集中の負荷状況を軽減し、ネットワーク内のトラフィ 2000 年 11 月におこなわれた LUNA SEA の巷公 ックを削減させます。 演の際には、この手法を応用した IP ェニーキャストに よるライプ中継をおこないました。私い也で竹喋に携 自社会員のなかでさらに限定する場合 わりましたが、当時としてはかなり野心的な町絲目みで、 ( オープン・ポータルサイト ) 香港から 300Kbps でエンコードした WMT のスト リームを国内の大手 ISP 数社の協力を得て配信しまし ISP によっても事情は異なると思いますが、例をいく た。このときに実施したのは、ユニキャストのアドレス っカ召介します。いすれの場合も、ストリーム・サー 空間の一都を、配信に協力したすべての ISP の AS 内 側でユーサー認証のイ督はみを導入する必要があります。 133 UNIX MAGAZINE 2003.5

連載 / IPv6 の実装ー⑩ 図 5 引数の正当性の確認 970 9 71 972 973 974 975 976 if (src = = NULL Ⅱ dst = NULL) panic("key—allocsa: NULL pointer is passed. " ) ; if (family = AF_INET6 & & ( ( (struct sockaddr *)src)->sa-family ! = AF_INET6 Ⅱ ( (struct sockaddr *)dst)->sa-family ! = AF_INET6)) { panic("key—allocsa: src/dst family is inconsistent") ; 図 6 優先して禾する SAD 工ントリの決定 982 983 984 985 986 987 988 if (key—preferred-oldsa) { saorder—state—valid = saorder_state_valid_prefer_old ; ARRAYLEN (saorder_state—valid—prefer—old) ; arrayslze } else { saorder_state—valid = saorder_state_valid_prefer_new ; ARRAYLEN (saorder-state—valid—prefer-new) ; arraYSIZe 図 7 イ銑して堋する SAD 工ントリの決定 ( 2 ) 167 168 169 170 171 172 static const u—int saorder—state—valid—prefer_old [ ] SADB_SASTATE_DYING , SADB_SASTATE_MATURE , static const u_int saorder—state—valid_prefer_new ロ SADB_SASTATE_MATURE , SADB_SASTATE_DYING , ・ SAD 工ントリの始点アドレス (src) ・ SAD 工ントリの終点アドレス (dst) ・ IP セキュリティの不鶤頁 (proto) ・ SPI 値 (spi) UNIX MAGAZINE 2003.5 valid に saorder-state-valid-prefer-old が設定され、 key-preferred-oldsa が真の場合は、 saorderstate- の値によって図 7 のいすれかの値か、設定されます。 state-valid は u-int 型の配列で、 key-preferred-oldsa 工ントリを優先して利用するかを決定します。 saorder- 工ントリの情報か史新されている途中で、どちらの SAD る時間があります。図 6 の key-preferred-oldsa は SAD れないよう、かならす新旧 2 つの SAD 工ントリが共存す す。 SAD 工ントリか更新される際、既存の通信が切断さ 向上させるために SAD 工ントリが定期的に更新されま 鍵交換プロトコルを利用している場合、セキュリティを 定したアドレス・ファミリーも同一でなけれは・なりません。 family て指定したアドレス・ファミリーと、 src/dst で指 アドレスを指定しなけれはなりません ( 970 行目 ) 。また、 key-allocsa() を呼び出す場合、かならす始点およひ終点 970 ~ 976 行目 ( 図 5 ) では引数の正当性を石忍します。 DYING 状態の SAD 工ントリが MATURE 状態のエン トリよりも優先されます。逆に、 key-preferred-oldsa が 偽であれば MATURE 状態のエントリが優先されます。 1001 LIST_FOREACH(sah, &sahtree, chain) { 1 , 001 行目から SAD 工ントリの検索を開始します。 SAD は secashead 構造体のリストとして実現されていま す。さらに、各 SAD 工ントリは、 secashead 構造体に secasvar 構造体の配列として登録されています。図 8 に SAD の構造を示します。 1 001 ~ 1 074 行目のループで、 secashead 構造体のリ ストメンバーを 1 っすっ石忍します。 1 , 006 ~ 1 , 073 行目のループでは、 982 ~ 988 行目て 1 夬 定された優先度に従って、 secasvar 構造体のリストであ る savtree のメンバーを 1 っすっ石忍します。旧い SAD 工ントリを優先するのなら sah->savtree[DYING] をさ きに、新しい SAD 工ントリを優先するのであれば sah ー > savtree[MATURE] をさきに検索します ( 図 9 ) 。 1011 if ( p て 0t0 ! = sav—>sah—>saidx. proto) 1012 continue ; 1013 if (spi ! = sav—>spi) continue ; 1014 73