Opengate Q & A
意義
-
そもそも何故認証などが必要なのですか。誰でもネットワークが使えて良いではないですか。
各ネットワークは、その設置趣旨と経費負担に従った利用が求められます。決して自由利用が前提ではありません。さらに、インターネット上では、誹謗中傷や詐欺、不正アタック等の反社会的行動が発生しています。組織としてはそのような行動を構成員に起こして欲しくありません。各自が責任を持って行動していただくための一つの方法として本システムがあります。
-
端末のOSに付随する認証を利用するのではダメなのですか。
統一したPC環境の構築と維持が可能なシステムの場合には、端末OSの認証システムを利用した方が良いと思います。しかし不特定多数が不特定機器を接続するような環境では機能しません。
-
アクセスされる側のサーバが各自で被害を受けないように、認証その他のセキュリティ保持を行うことが本来ではないですか。
それも必要でしょう。しかし大学のように多数の多様な人間が比較的自由に利用できるネットワーク環境を提供している組織では、外部に対して様々なトラブルを起こし苦情が寄せられる可能性が高くなります。その責任はトラブル原因を作った本人に取っていただく必要があります。また、ネットワーク利用には、その目的に合った利用者の制限があることが通常だと思います。よってアクセスする側での認証も必要と考えます。
-
何故、公開固定端末と情報コンセントの両方を対象とする必要があるのですか。
公開固定端末は端末OSの認証が可能ではないですか。
全ての公開固定端末をネットワーク管理部門が統一的に配置し、そのハードウェアを不正操作から守れる状況が可能であればそれでも良いと思います。しかし現実的には拡散した公開場所へ多数配置することが多く、様々な困難が伴います。また既に配置された認証機能の無い端末や不十分な管理下の端末が数多くあります。これらにも対応する必要があります。
-
ルータやファイアウオール等、通過点での記録取得ではいけないのですか。
この記録ではIPアドレスは分かります。しかし不特定多数が出入りする場所の場合は誰が利用したのか分かりません。利用者が特定できる部屋の場合はこのような記録でも良いでしょう。
-
MACアドレスで個人識別をする方式もあるようですが。
Opengateは個人識別をユーザIDとパスワードで行っています。この認証入力の代わりにMACアドレスを使うことは可能でしょう。
しかしMACアドレスを利用する方式は、MACアドレスとその所有者との関係を前もって登録する必要があります。また機器譲渡・廃棄の際に登録消去、機器更新の際に登録更新を行う必要がありますが、利用者に登録消去を励行させるのは難しいと思われます。これらの運用上の問題点を解決しなければなりません。またMACアドレスはイーサネット接続端末のみに存在する点、ルータを超えて伝わらない点、偽装が可能である点なども難点と言えます。
-
最近、さまざまなネットワーク認証システムが発表されているようですが。
Opengateは以下の点を満たしている点が特徴と考えます。端末に対するソフト、ハード、設置形態、接続方法などの制限が少ない事。利用者の指導や管理が最小限で済む事。一般的なソフト/ハードで構成されており、既存ネットワークへの導入が容易である事。利用開始/終了に際して即座にネットワークの開放/閉鎖が行われる事。
-
他の用途には利用できますか。
本システムは、ユーザIDとパスワードをWeb経由で受け付け、そのIPアドレスとのパケットの通過を許可するシステムです。その枠組みの環境であれば利用できると思います。例えば、エクストラネットからイントラネットに対してアクセスするためのバイパス窓口を設置することにも利用できるでしょう。当然ながら極めて高度なセキュリティレベルを必要とするネットワークでない場合ですが。
-
Javaが動かない端末もありますが。
Javaが動かないもしくはインストールされていない端末でも、利用者が認証ページにおいて要求した接続継続時間だけネットワークを開放します。ただし、乗っ取りや放置に対応するため、一定時間間隔で、ARPコマンドとファイアウォール通過パケット数でチェックします。また、許可ページの利用中断のリンクをクリックすることでネットワークを閉鎖できます。
利用
-
無線LANで使えますか。
使えます。ただし、親局内でNAT等によるIPアドレス変換がなされていないことが必要です。
-
DHCPやNATとの共用はできますか。
できます。そのような使い方が多いと思います。ただしNATは同一ゲートウェイマシン上で動かす場合です。本ゲートウェイと端末群との間にNAT装置を挟むことはできません。同じIPアドレスを多人数が使用する形になるためです。
-
MACアドレスは取得できますか。
Ver0.53にて対応しました。ただし、サーバ側でARPから取得するため、サーバ側から見えるアドレスのみです。代理ARPがあるとその中継アドレスとなります。また、当然ながら、イーサネットでのみ有効です。
-
一部のサービスは認証無しにしたいのですが。もしくは認証後も一部のサービスを制限したいのですが。
初期状態のファイアウオールルールに必要なものを追加すれば可能です。Opengateはこの初期状態にルールを挿入・削除します。よって、追加位置を工夫すれば様々な制御が可能です。例えば、特定のサイトをアクセス許可もしくは不許可に固定することもできます。
-
利用者のレベルによってサービスを制限したいのですが。
Firewall制御にPerlスクリプトが利用できます。ユーザ名や認証サーバ、IPアドレスなどで区別できるならば、スクリプト中に記述可能です。Ver.0.80で対応しました。
-
一時的利用者への対応はどうしますか。
認証サーバへの一時的な利用者登録が必要です。Opengateは、複数の認証サーバにユーザを振り分けるように指定できますので、別途に一時利用者のための認証サーバを設置することもできます。ftpサーバが動けば良いのでWindowsなどの簡易サーバでも可能と考えます。
当大学では、現在のところ、図書館外部利用者や学会参加者などの一時的利用者に対して以下の運用を行っています。一時利用者用の認証サーバを用意する。必要数の利用者IDを利用期限付きで登録し、同時に利用者IDとパスワードおよび利用上の注意を書いた用紙を利用者ID毎に印刷する。利用希望者が来訪すれば、身元を確認して用紙を1枚渡す。当然ながら本利用者IDは学内のサーバへのログイン等には利用できません。
-
パスワードの守秘は保てますか。
端末とゲートウェイ間はWeb通信でパスワードを送ります。よってWebサーバをSSL化すれば守秘が保てます。ゲートウェイと認証サーバの間は、守秘機能のある認証プロトコルによれば可能です。Opengateは、pop3s,Radius,PAMに対応しています。PAMは多くの認証プロトコルをサポートします。
-
スケーラビリティはどうですか。パフォーマンスはどうですか。
数十台の使用では問題無く使えています。クラスC程度の利用はできると思います。本システムは、ファイアウオールソフトのパケットフィルタリング規則を追加・削除する方式であり、各クライアントからの利用開始要求時を別にすれば殆ど負荷となりません。利用中のパフォーマンスは、パケットフィルタリングやパケット転送の処理能力に依存すると思います。なお量的な制限としては、利用クライアント毎に1プロセスが常駐することがあります。しかしプロセス数の最大値はカーネルで調整できますし、クラスC程度毎に分割してシステム運用する方がゲートウェイにおけるパケットフィルタリング等の能力からすると現実的でしょう。
導入・開発
-
インストールしたが動きません。
多数のソフトウェアの仲介をするシステムですのでデバッグは面倒だと思います。別途に用意したチェック項目記述のファイルを見てください。
-
利用・改変・配布は可能ですか。
GPL下で可能です。今後の開発のために、開発者まで連絡頂ければ幸いです。バグ・要望・改変報告を歓迎します。
-
認証Webページのデザインを変えたいのですが。
各WebページはHTMLファイルとして独立しています。これを書きかえることで簡単にできます。
-
IPアドレスにより相手を確認しているようですが、IPスプーフィングは問題ではないですか。またサービス妨害攻撃には対応できますか。その他のアタックに対してはどうですか。
IPスプーフィングはファイアウオールの方の設定で避けられると思います。またOpengateは、正しいパスワードを送ってきたアドレスに対して穴を開けるので、IPアドレスを偽ってもあまり得にはなりません。他が認証を受けて使っている同じIPアドレスを詐称してパケットを流すことは可能でしょうが、現実的な利用は難しいと思っています。サービス妨害については、各IPアドレスに対して独自のポート番号を一つ送りつけ交信する形態ですので避けられると思います。妨害を完全に除去することは難しいですが、セキュリティホールがあればご教示下さい。悪意を持った利用に対しては、対策として考えられている機能などを組み合わせることも可能であろうと思います。
-
ダウンロードファイルの中身が乱雑なままですが。
特に整理せずに、動くようになった状態を保存しています。矛盾もあると思います。きれいに整理して出したいのですが余裕が無くて済みません。
-
サーバはFreeBSD以外で動きますか。
現状では、FreeBSD専用のファイアウオールツールipfwを利用しているので、他のOSでは動きません。同等の機能を持つファイアウオールツールがあれば、対応するように書きかえることは可能です。例えばLinuxのipchainsに書き換えることは可能です。
-
端末毎にプロセスが生成されて大量に常駐し気持ち良くありません。一つにまとまりませんか。
アルゴリズムを簡単にするために今の方式を取りました。監視プロセスを一つにまとめることも可能でしょうが、多数の時間待ちとアクセス待ちを制御するのは、サービス妨害その他の考慮点もあり、かなり面倒です。外部条件を勘案すると一つにまとめる緊急度が低いと考えて後回しにしています。