VPN と IEEE802.1X ネットワークの相互接続検証

2005/12/20
VPN と IEEE802.1X ネットワークの相互接続検証
041101 秋山真徳*1 041104
打越幸隆*1
*1 コンピュータネットワーク科 2 年
要旨：これまでのユーザ認証だけではネットワークのセキュリティが約束されなくなり、端末認証を目的と
した検疫ネットワークが注目を集めている。当研究では、検疫ネットワークのインフラ構築方法として
IEEE802.1X 認証および、Microsoft 社®のリモートアクセス検疫で採用されている VPN をとりあげ構築技術
の取得と技術検証を行う。
キーワード： IEEE802.1X、PKI、RADIUS
1.
研究目標
検疫ネットワークのインフラ構築、及び検証を行う。検疫ネット
ワーク構築の方式として、IEEE802.1X 認証による VLAN 方式
を採用し、「企業ネットワークへの導入」をコンセプトとして掲げ、
Cisco Systems 社のモジュール方式に準拠したネットワークに
おける最適な検疫ネットワーク・インフラモデルを提案する。
また、リモートアクセスのため、IPSec-VPN をとりあげ、NAP
導入のための VPN 網を整備する。
図 1. 作業手順
2.
研究体制
研究発足当初は打越が研究リーダを担当していたが、10 月以
4.
降、打越の早期就職活動のため秋山が引継ぎ、下記の研究体
制となった。
検疫ネットワーク
検疫ネットワークが注目を集めた背景として、持ち込み PC の
脅威があげられる。これまでのネットワーク・セキュリティの概念
担当教官
は外部からの脅威が大前提にあり、ファイヤーウォールや IDS
古賀直美
の導入が主流であったが、モバイル環境の充実により、ノート
PC の持ち出しや持ち込み頻度が増している。
この持ち込み PC のセキュリティ対策が不十分でウィルスなど
研究リーダ
秋山真徳
打越幸隆
に感染していた場合、ファイヤーウォールの有無に関係なく、内
部ネットワークでウィルスが蔓延してしまう。
このような脅威に対抗するための技術が検疫ネットワークであ
3.
スケジュール及び作業手順
一年間の研究活動期間を大きく分けてサーバ構築、LAN 構
築、IEEE802.1X 認証システムの構築、ネットワーク検証、VPN
の構築検証の 5 項目に分割して作業を行った。詳細に関しては
図を参照。
なお、VPNに関しては諸事情により研究対象から取り下げるこ
とになった。
作業手順は図 1 を参照
る。検疫ネットワークでは、ユーザ認証と端末(主にノート PC)検
査を行い、セキュリティ対策が不十分な端末にはネットワークへ
のアクセス制限を行うことによって、内部ネットワークへの被害を
防ぐ、という考えで成り立っている。
検疫ネットワークの機能は、隔離、検査、治療を行う、社内
LAN から隔離されたネットワークのことを指し、社内 LAN への
接続を試みる端末はまず検疫ネットワークへ隔離され、検疫ネッ
トワーク内でセキュリティ情報のチェックを受ける。検査に合格し
た端末は社内 LAN へ、検査に不合格となった端末は合格にな
るまで検疫ネットワーク内で治療を受けることになる。
検疫ネットワーク技術としては、DHCP 方式、パーソナルファ
イアウォール方式、VLAN 方式などがある。
1
2005/12/20
また、Cisco Systems 社の NAC や Microsoft 社の NAP など、
5.
これらの方式をベースとした検疫ネットワーク・ソリューションを各
検疫ネットワークにおいて想定されるクライアントを主に
社で提供している。
4.1
Windows搭載PC であるため、ユーザ、及び端末管理のために
は Windows Server を構築し Active Directory や SUS を運用
DHCP 方式
する必要があるが、本研究においては基本的なサーバ機能の
DHCP 方式では DHCP サーバからクライアントに、検疫ネット
みの提供に限定し、学習目的もかねて Linux によってサーバフ
ワークにのみアクセス可能な IP アドレスを割り当て、その際に
ァームを構築している。
DHCP サーバをデフォルトゲートウェイとして通知する。クライア
また、Samba3.0 系列により Linux サーバも Kerberos 認証を
ントは検疫ネットワーク内の検疫サーバからセキュリティ情報の
使って Active Directory に参加できることと、検疫ネットワークに
検査を受け、十分なセキュリティ対策が施されている端末のみが
おける認証サーバ(RADIUS)が Windows 特有の脆弱性をつい
DHCP サーバから社内ネットワークへアクセス可能な IP アドレ
た攻撃、ウイルス被害を防ぐことができる点に注目したことも
スを受け取り、社内へ接続することができる。
Linux を採用した理由である。
DHCP 方式の問題として、クライアントが手動で社内 LAN の
IP アドレスを設定している場合、検疫サーバの検査を受けずに
5.1
社内 LAN へのアクセスが可能となる点がある。
4.2
採用ディストリビューション
本研究のための Linux ディストリビューションとして、CentOS、
WhiteBox、Fedora Core、Red Hat Linux を候補としてあげ、
パーソナル・ファイアウォール方式
3 月から 8 月までの期間で Red Hat Enterprise Linux のクロ
パーソナル・ファイアウォール方式はクライアントにファイアウ
ーン OS である CentOS、8 月から 1 月までの期間で Red Hat
ォールソフトを導入し、クライアントを管理するポリシーサーバか
Linux 9 を採用した。
ら配信されたセキュリティポリシーに従ってクライアントファイアウ
WhiteBox も CentOS 同様 Red Hat Enterprise Linux のク
ォールがネットワークへのアクセス制御を行う方式である。ネット
ローン OS であるが、CentOS コミュニティによるパッチ対応が
ワーク接続時にセキュリティ対策が十分でないクライアント PC は
WhiteBoxに比べ早いことからWhiteBoxの採用を見送った。ま
セキュリティポリシー違反となり、クライアントファイアウォールに
た、Fedora Core はドキュメント資料の量が豊富であるため
より検疫ネットワークのみにアクセスが制限される。
Linux の学習目的としては適しているが、Red Hat Enterprise
パーソナル・ファイアウォール方式の問題として、クライアント
Linux のためのベータテストの意味合いが強く、パッケージに関
にファイアウォールソフトがあらかじめ導入されていないとセキュ
しても信頼性が低い。
リティ対策状況のチェックが行えないという点がある。
4.3
Linux サーバ
CentOS はクローン OS という特性上、Red Hat Enterprise
Linux、Fedora Core、Red Hat Linux のドキュメントをほぼそ
VLAN 方式
のまま利用可能であることから採用したが、カーネル 2.6 系＋
VLAN方式ではあらかじめクライアントPCに資産管理用のエ
SELinux の構成によりパッケージが予期しない動作を行うなどト
ージェントソフトを入れておき、ネットワークに接続する際に認証
ラブルが多発したため、8 月 30 日をもってサーバ運用実績の高
スイッチで強制的に検疫サーバーが配置されている VLAN に
い Red Hat Linux 9 (カーネル 2.4 系)に変更した。
つないで資産管理サーバー等と連携して、ユーザー認証を行う
なお、本論分内における Linux サーバに関する記述は Red
のと同時にセキュリティを検査する。そして、２つのチェックに合
Hat Linux 9(以下 RH9)上のものとする。
格したら、検疫サーバーがそのクライアント PC の MAC アドレス
に対して社内 LAN へのアクセスを許可するように認証スイッチ
5.2
に命令をだす。認証スイッチはクライアント PC の VLAN を変更
Linux サーバの構築・運用
サーバにおける不要なサービス(特にネットワークサービス)は、
し、クライアント PC が社内 LAN にアクセスできるようになる。
それ自体が単一障害点となる。そのため、Linux のインストール
VLAN 方式のメリットとして、セキュリティ検査だけでなく、その
は最小構成で行い、必要なサービスのみを随時導入することが
パソコンを使うユーザーが正しいユーザーであるのかも調べら
望ましい。また、最小構成でインストールを行い追加する形をと
れ、安全性が高いネットワークが構築できる点がある。
ることで、サービス管理を行いやすい。ただし、今回は
VLAN 方式の問題として、全てのユーザーを認証するとした
FreeRADIUS をコンパイル・インストール(gcc が必要なため)す
ら社内ネットワークのスイッチを全て認証スイッチに置き換え、全
る必要があるため、最小構成に開発パッケージを追加した状態
てのパソコンを認証スイッチに直接収容しなければならない点が
でサーバのインストールを行った。
ある。
しかし、Linux を最小でインストールを行った場合でも不要な
サービスがインストールされバックグラウンドで動いているため、
chconfig コマンドにより自動起動のサービスを確認後、自動起動
2
2005/12/20
を無効にする必要がある。最小インストール時における代表的な
5.4
DHCP
DHCPサーバとして機能させるため、RH9インストールCD付
不要(と思われる)サービスは以下のとおりである。
・
kudzu：
新規デバイスの自動検出
・
isdn：
ISDN 接続デーモン
・
nfs：
ネットワークファイルシステム
当てるために/etc/sysconfig/network-scripts/ifcfg-eth0 の編集
・
rhnsd：
自動アップデートサービス
後、service network restart コマンドを実行し、インターフェー
・
sendmail：
Mail サーバ
スを再起動してから、ifconfig eth0 コマンドにより設定項目を確
属、ISC-dhcp-3.0pl1-23 のインストールを行った。
パッケージのインストール後、RH9 の IP アドレスを固定で割り
また、自動起動の有効・無効に関らず、サービスの起動・停止
認する。
RH9 付属の dhcp パッケージではインストール後に
を行う場合は以下のコマンドで行う。
# service {サービス名} {start | stop}
dhcpd(dhcp デーモン)の設定ファイル(dhcpd.conf)は自動作成
5.2.2 ユーザ管理とアクセス制限
されないので以下のコマンドにより作成する。
Linux では二種類のユーザアカウントに分類される。root で
# touch /etc/dhcpd.conf
ある特権ユーザとその他一般ユーザである。Linux では root
本研究において必要な dhcpd.conf 内の設定項目は以下の通
パスワードが分かれば誰でも su コマンドにより root 権限を持
りである。
つことができるため、root パスワードを必要としない sudo コマ
・
DDNS(Dynamic DNS)への対応
ンドの利用に限定し、各特権コマンドに必要なコマンド実行グ
・
DNS サーバのゾーンファイルの指定
ループを作成後、実行可能ユーザを追加する。sudo コマンド
・
IP アドレスと同時に配布する情報
は sudo 設定ファイル（/etc/sudoers）に基づきコマンド実行権
・
リースレンジの設定
限の割り当て、監視を行うことができるため、root パスワードを
・
リースレンジ内における固定アドレス配布の設定
管理者等に通知するよりも安全かつ柔軟な対応を行うことがで
ISC-ｄｈｃｐでは dhcpd.conf の編集は自動更新されないため、
きる。また、/etc/login.defs、/etc/group、/etc/pam.d/su ファイ
ルの設定により su-コマンドの制限を行っている。
service コマンドにより dhcpd を再起動する必要がる。
同様に、root パスワードを悪意のあるユーザから変更されな
本研究において準備したサーバ二台のリースレンジを 80:20
いようにするために GRUB コンソールにパスワードを設定す
の割合でプライマリ・セカンダリとして構成を行ったが、死活監視
ることでシングルユーザモード起動を防ぐ。
の設定やスクリプトファイルなどの作成は行っていないため、プ
Linux はコマンドラインベースによる操作が基本となるため、
ライマリ DHCP サーバの異常・停止を確認後、それぞれ手動で
Telnet, SSH 接続による遠隔操作が便利である一方、リモート
停止と起動を行うことを想定している。また、DHCP パッケージイ
接続のためのセキュリティ設定が不可欠となる。本研究では
ンストール後、dhcpd デーモンは自動起動としては登録されな
Telnet サービスを導入していないため、sshd_config ファイル
いため、必要に応じて chkconfig コマンドにより設定を行う。
の設定により SSH のアクセス制限及び、SSH への root ログイ
アドレス配布状況は dhcpd.leases に記録される。また
ンを禁止することで、ローカル・ネットワーク両面における root
/var/log/messages に DHCP トラフィックのログが記録されるた
権限のアクセス制限を行った。
め、試験目的の際は以下のコマンドによりリアルタイムで配布状
況を確認できる。
5.3
# tail –f /var/log/messages
サーバサービス
本研究では以下のネットワークサービスの提供を目的として構
築を行っている。(時系列順)
・
DHCP (プライマリ・セカンダリ)
・
DNS (マスタ・スレイブ)
5.5
DNS
5.5.1
BIND 基本設定
DNS サーバとして RH9 付属の BIND(bind-9.2.1-16)をイン
・
LDAP (マスタ・スレイブ)
・
NTP （Strutum2, Strutum3）
ストールし、DNS によるマスタ・スレイブ構成とし、また DHCP サ
・
RADIUS
ーバとの連結により DDNS に対応させることで、すべてのサー
・
SSL（上位 CA、及び下位 CA）
バ、クライアントにホスト名によるアクセスを実現している。
BIND による DNS サーバの構築・運用に必要なファイルは以
なお、SSL に関しては、「７．PKI」、RADIUS に関しては、
「8.2 RADIUS サーバ」にて説明を行う。
下の通りである。
3
2005/12/20
るが、BIND9 の標準インストールでは DNSSEC に対応
していないため DNSSEC 対応の RPM パッケージを再
インストールするか、ソースからコンパイルしてインス
トールする必要がある。
一方 TSIG では、マスタ・スレイブ間で TSIG 鍵を共
有し、DNS メッセージに署名を行うことで DNS メッセ
ージの完全性の保障やリクエスト認証を可能にしてい
る。
rndc とは BIND をローカル・リモートで管理するため
のユーティリティツールであると同時に rndc 鍵を設定
することで、サーバとクライアント間で ndc 鍵を共有し
ていない場合は BIND を操作できないため、信頼された
端末からのみ BIND の操作が可能となる。
BIND の設定終了後、DHCP と同様に BIND のデーモ
ン、named を chkconfig コマンドにより OS 起動時に自
動起動するよう設定を行う。
・ named.conf
・ named.ca
・ local.zone
・ local.rev
・ドメイン用正引きファイル
・ドメイン用逆引きファイル
・ named.pid
これらのうち、DNS 全体の設定ファイルが named.conf
である。named.ca は Internic などにより(named.root
として)配布されるファイルで、DNS 境界におけるルー
トドメインを指定しているファイルである。local.*はそ
れぞれループバック用の正引き・逆引きファイルで、こ
れら四つのファイルはマスタ・スレイブに関わらず必要
なファイルである。
ドメイン用の正引き・逆引き用のファイルは各 DNS
サーバが管理するドメインの名前解決情報を記述してい
る。
5.5.2
BIND セキュリティ
5.6
BIND により DNS サーバを構築する際、セキュリティ
を以下の点に注意する必要がある。また、DNS デーモン
(named)の実行ユーザを root、あるいは一般ユーザでは
なくシステムユーザで起動する必要があるが、今回導入
した bind-9.2.1-16 では named ユーザと named グルー
プがそれぞれ作られ named は named ユーザ権限で起動
されるデフォルト設定のため、設定変更は行っていない。
・ acl の設定
・ BIND バージョンの隠蔽
・ chroot 化
・ DNSSEC の導入
・ TSIG の導入
・ rndc キーの導入
acl ステートメントによりアクセス制限を行うことが
でき、スレーブサーバの制限や特定アドレスからの問い
合わせを拒否することもできる。
BIND は普及率が高い一方、バグ情報も既知のものと
なっているため、version ステートメントにより BIND
のバージョンの隠蔽を行うなどして稼動 BIND のバージ
ョンを絞らせないように設定している。
chroot とは、BIND のルートディレクトリとパーミッ
ションを変更することで、chroot 化したサーバサービス
へアクセスしても chroot 化されたディレクトリより上の
階層へアクセスすることができないようにするための機
能である。CentOS では chroot 化を自動で行う RPM パ
ッケージ(bind-chroot)が用意されているが、RH9 用の
bind-chroot は用意されていなので管理者が手作業で行
う必要がある。一般的に、ルートディレクトリを/etc か
ら/var/named に変更するようになっている。
DNSSEC とは公開鍵暗号方式でゾーン情報の信頼性
を保障する BIND の新しいセキュリティ機能の一つであ
4
LDAP
LDAP とは X.500 を前進としたディレクトリサービスプロトコル
で、 LDAP サービス導入のため RH9 付属の
OpenLDAP2.0.27-8 を採用した。本研究では対象外となるが、
サーバのローカルアカウント、RADIUS アカウント、メールサー
バ、メールクライアントなどその他のアカウントを一元管理できる、
などのスケーラビリティに注目し、LDAP サーバを構築してい
る。
本研究で動作確認を行っている LDAP サービスの機能は以
下のとおりである。
・
コマンド操作によるエントリー追加。
・
アクセス制限つきでアカウント情報の参照を提供する。
・
ローカルアカウント(/etc/passwd)の管理を OpenLDAP
（slarpd）に委譲し、サーバへのログインを OpenLDAP で
管理する。
OpenLDAP の構築は作業は以下の順で進める。
1.
設定ファイル(slapd.conf)の編集
2.
初期エントリ LDIF ファイルの作成
3.
グループ・ユーザアカウント用 LDIF ファイルの作成
4.
authconfig によりローカルユーザアカウント情報を slapd
に委譲
5.
/etc/nsswitches の hosts 項に ldap エントリを追加
6.
サーバの再起動
6.
PKI
公開鍵暗号方式に基づくセキュリティ対策の基盤（インフラ）を
指し、暗号化とデジタル署名の機能によって、守秘性、認証、完
全性、否認防止のセキュリティサービスを提供する。
PKI は以下の要素により構成される
2005/12/20
・
CA（認証局）
・
RA(登録局)
・
リポジトリ
・
アーカイブ
・
証明書所有者
・
証明書利用者
7.
LAN 構築
論理的には冗長化構成のネットワークになるはずだったが、機
材の不足や計画の遅延などの理由により、動作確認を主とした
最低限のインフラ構築を行った。使用した機器は以下の通りであ
る。
クライアント PC １台
Cisco Catalyst 2940 １台
Linux サーバー１台
RADIUS サーバー１台
IEEE802.1X 認証スイッチ
7.1
本研究では Cisco Systems 社の Catalyst2940 を認証スイッ
チとして使用した。設定項目は以下の通りである。
図 2 PKI
IEEE802.1X 認証機能の起動
・
RADISU サーバー情報の登録
・
VLAN の設定
当初は DHCP サーバーによってクライアント用の IP`アドレス
本研究では、IEEE802.1X 認証における EAP-TLS 導入のた
がスイッチ本体に振られる事があり、RADIUSサーバーが正しく
めに CA 構築・運用として OpenSSL0.9.7 を採用している。
6.1
・
スイッチを認識出来ず、認証が失敗するということがあった。その
ため、IP アドレスを固定で設定し、サーバーの方も合わせて設
公開鍵暗号方式 (Public Key Cryptography)
定を変更して対応した。
公開鍵暗号方式は、公開鍵で暗号化した情報は、公開鍵に対
応する秘密鍵でなければ複合できない、という性質に基づいて
冗長化
7.2
いる。
本研究における冗長化とはネットワーク上で複数の機器を使
6.2
い、複数の通信経路を用意して一部のネットワークがダウンして
デジタル署名
も通信が継続できるようにすることである。
デジタル署名は公開鍵暗号方式を応用した技術である。公開
デフォルトゲートウェイに対する冗長化技術として HSRP と
鍵暗号方式の違いは、公開鍵暗号方式では、公開鍵で情報を
VRRP がある。
暗号化し、秘密鍵で復号を行うだけなのに対して、デジタル署名
では、情報にハッシュをかけたダイジェストに対して秘密鍵で暗
7.1.1
号化した署名を作成し、その署名を元の情報に組み込んで送信
HSRP
Cisco Systems 社独自の冗長化技術である。各ルータに一つ
する。受信者はメッセージのダイジェストと、公開鍵で復号された
ずつ IP アドレスを振った上で、多重化されているルータ全体を
署名のダイジェストを比較することにより、情報の認証と完全性の
ひとつの仮想ルーターとしてさらに 1 つ IP アドレスを割り当て、
保障を実現している。
通信する際は全体用の IP アドレスに要求を送信する。通常の通
信に使用されるルータは 1 つで、使用中のルータが停止すると
自動的に別のルータ 1 台が停止したルータに代わって通信を行
なう。
7.1.2
VRRP
複数のルータを1つのグループに所属させ、通常はそのうち1
つのルータが通信を行なうが、そのルータが障害を起こした時
に同グループに属するルータが自動的に通信を受け継ぐ。同一
グループで通信を行なうルータは 1 台に限られるが、1 つのル
ータが複数のグループに所属することもできるため、設定によっ
図 3 デジタル署名の仕組み
て負荷分散を同時に実現することも可能である。
当初 VRRP による冗長化を予定していたが VRRP を構築可
能な機器がなかったということと、802.1X 認証に時間をかけすぎ
5
2005/12/20
users ファイルへ認証するユーザーの ID やパスワードといっ
てしまったという理由により実装にはいたっていない。
た情報を登録し、clients ファイルに認証するスイッチの情報を登
録した。また、RADIUSの認証には独自のkey というものを設定
拡張 STP
7.3
パフォーマンスの向上を目指して通常の STP だけではなく
する必要があり、key が認証サーバーと認証スイッチ間で一致し
Cisco Systems 社が開発した拡張 STP を追加設定した。拡張Ｓ
ないとたとえユーザーID とパスワードが正しいものを使用したと
ＴＰとは冗長構成になっているネットワーク上でフレームがルー
しても認証できないというものである。この key は管理者が自由
プし続けるのを防ぐために使用されているスパニングツリープロ
に決めることが出来る。
トコルの機能を拡張したものである。本研究では拡張 STP のうち
RADIUS は LDAP や MySQL との連携が可能で、連携した
の１つである ProtFast のみ実装した。
場合のメリットとしてユーザー情報の管理が容易になる点などが
ある。本研究ではユーザーが少数だったため LDAP との連携の
必要性を感じず、導入はしていない。
PortFast
7.2.1
スイッチなどの BPDU を発生させない機器（パソコンなど）
しか繋げないポートに対して設定することによって、接続す
認証方式
7.6
Windows では EAP-MD5,EAP-TLS,EAP-PEAP の 3 種類
ると同時にフォワーディング状態（データの送受信が可能で
の認証方式がある。今回は 802.1X 認証の動作確認に重点を置
ある状態）にさせる機能である。
き、EAP-MD5 を使用した。なお、EAP-MD5 は WindowsXP
7.4
SP2 以降は非サポートであり、本研究では WindowsXP SP1 を
IEEE802.1X
クライアント PC として使用した。
クライアントがネットワーク接続時に RADIUS サーバを使用し
て認証をかける技術である。認証が成功しない限りネットワーク
に接続できない。認証クライアントにはあらかじめサプリカントと
7.5.1
EAP-MD5
EAP-MD5 は認証サーバとクライアント間の相互認証と WEP
呼ばれる認証ソフトウェアを入れておく必要がある。
キーの交換が行われないために、WEP 暗号の脆弱性はカバー
されない。
7.5.2
EAP-TLS
EAP-TLS は認証サーバとクライアント間の双方に電子証明書
をインポートし、電子証明書による相互認証を行う。定期的な
WEP キーの生成と配布が行われるために、WEP 暗号の脆弱
性をカバーする。電子証明書の管理面での負荷がかかってしま
う。また、現状クライアント OS が Windows XP と Windows 2000
SP4 のみでの対応となり、その他クライアント OS を使用する場
合には、別途サプリカントソフトウェアが必要となる。
図 4 IEEE802.1X 認証の流れ
7.5
7.5.3
EAP-PEAP は米国マイクロソフト社、米国シスコシステム
RADIUS サーバ
ズ社、米国 RSA セキュリティ社により開発された IEEE
802.1.x/EAP 認証方式の一つ。認証サーバは電子証明
書、クライアントは ID/パスワードによる相互認証を行う。
定期的な WEP キーの生成と配布が行われるために、
WEP 暗号の脆弱性をカバーする。また、現状クライアント
OS が Windows XP と Windows 2000 SP4 のみでの対
応となり、その他クライアント OS を使用する場合には、別
途サプリカントソフトウェアが必要となる。
RADIUS とはクライアントサーバモデルのダイヤルアップ接
続ユーザ認証システムである。
RADIUS アプライアンス／ソフトウェアにはさまざまな種類が
あるが、今回は最も参考文献が多く、また無償である
FreeRADIUS(ver0.9.3)を Red Hat Linux にインストールして
使用した。
設定項目としては以下のとおりである。
・
user の登録
・
users ファイルの設定・編集
・
client の登録
・
clients ファイルの設定・編集
・
key の設定
EAP-PEAP
8.
ネットワーク検証
認証機能は上手く動いたが、動作確認を主とした構築・検証の
6
2005/12/20
謝辞
ため、実用を目的とすると、今後に多くの課題を残す結果となっ
た。
本研究にあたり、ご指導いただきました、IT 教育推進室の古
8.1
賀教官をはじめ、IT 教育推進室、麻生塾教務課の先生方へ深く
動作が遅い
感謝の意を申し上げます。
EAP を使用して認証を行ったが、認証結果の成功、失敗にか
かわらず認証自体に１０～１５秒と非常に時間がかかる。さらに認
証成功後も VLAN 割り当てや、DHCP による IP アドレスの割り
参考文献
当て等の処理があり、最終的なネットワーク接続まで長い時間待
[1] Linux クイックリファレンス O’REILLY
たされることになった。
8.2
[2] Fedora Core 3 で作るネットワークサーバ構築ガイド秀和システム
[3] Fedora Core 2 サーバ構築完全攻略ソフトバンクパブリッシング
RADIUS へのユーザー登録
[4] Cisco Catalyst LAN スイッチ教科書インプレス
今回の構築環境では RADIUS サーバーを使用してユーザー
[5] CCNP BCMSN 試験認定ガイドソフトバンクパブリッシング
認証をする際にユーザーのデータを全て手動でサーバーの設
[6] DNS & BIND 第 4 版 O’REILLY
定ファイルの中に書き込まなくてはならなかったので、４～５名程
[7] LDAP 設定・管理・プログラミング O’REILLY
度ならまだしも、十数名以上が使用する環境を構築するとなると、
[8] RADIUS ユーザ認証セキュリティプロトコル O’REILLY
入力しなければならない情報が多すぎて、非常に困難な作業に
[9]ネットワークセキュリティ HACKS O’REILLY
なることが予想される。
[10] Active Directory と Linux によるシステム構築ガイド秀和システム
[11] Cisco Systems
9.
今後の課題
実用性を考えると、EAP-MD5 は WindowsXP SP2 以降非対
応であるので、EAP-TLS や EAP-PEAP への移行を考慮すべ
きであると思う。
RADIUS サーバーにおけるユーザー認証も今回は、ユーザ
ー１人１人の情報を直接サーバーに入力して認証を行ったので、
新しいユーザーが増えるたびに設定ファイルを手動で更新しな
ければならなかった。今後は LDAP と連携し、ユーザー情報の
管理を効率良く行えるよう改善出来ると思う。
ネットワークインフラの構築に Cisco Systems 社の製品しか使
用しなかったので、これを他社の製品で構築したとしても問題な
く動作するのか、動作するとしたら今回の結果と比較してどうな
のかという点を考えるのも面白いのではないかと思う。
10.
所感
今回の研究活動を通して、知識や技術の向上が出来たのは非
常に良かったが、最も強く感じたのはチームで計画を立て何か
をやると言う事の難しさである。互いにスケジュールを調整し、計
画立てて行動したものの、予想以上に技術の取得に手間取った
り、お互いスケジュールが合わず、ミーティングの時間がとれな
かったりと色々大変であった。しかし、普通に学生生活を送って
いては経験出来ない事を経験出来たのは非常に大きな財産で
あり、今後も、今回の研究で得た経験を生かしつつ、更なる向上
を目指していきたいと思う。
7
http://www.cisco.com

Download Report