Index: head/ja_JP.eucJP/books/handbook/security/chapter.xml =================================================================== --- head/ja_JP.eucJP/books/handbook/security/chapter.xml (revision 51117) +++ head/ja_JP.eucJP/books/handbook/security/chapter.xml (revision 51118) @@ -1,5402 +1,5390 @@ セキュリティ MatthewDillon本章の基にした security(7) マニュアルページの執筆: セキュリティ 訳: &a.jp.hino;、(jpman プロジェクトの成果を利用させ ていただきました)。 この章では この章では、基本的なシステムセキュリティの考え方、 覚えておくべき一般的なルールを紹介し、 &os; における高度な話題について簡単に説明します ここで扱う話題の多くは、 一般的なシステムやインターネットセキュリティにもあてはまります。 インターネットはもはや、誰もが親切な隣人であろうとする 友好的な 場ではありません。 あなたのシステムを安全に保つことは、 あなたのデータ、知的財産、時間、その他を、 ハッカーやその同類から守るためには欠かせません。 &os; は、 システムとネットワークの整合性と安全性を確実にする仕組みと一連のユーティリティを提供しています。 この章を読むと、以下のことがわかります。 &os; に関する基本的なシステムセキュリティの考え方 DES や MD5 のような、 &os; で利用できるさまざまな暗号化手法について ワンタイムパスワード認証の設定方法 - inetd と組み合わせて + inetd と組み合わせて TCP Wrappers を設定する方法 &os; 5.0 より前のリリースにおける、 KerberosIV の設定方法 &os; における Kerberos5 の設定方法 IPsec および FreeBSD/&windows; コンピュータの間で VPN の設定方法 &os; で使われている SSH である OpenSSH の設定および使用方法 ファイルシステムの ACL (アクセス制御リスト) とは何か、またその使用法 Portaudit ユーティリティを使って、Ports Collection からインストールされたサードパーティ製ソフトウェア packages を監査する方法 公開される &os; セキュリティ勧告の利用方法 プロセスアカウンティングがどのようなものか、 &os; 上で有効にする方法について この章を読む前に、次のことが必要になります。 &os; およびインターネットの基本概念の理解 はじめに セキュリティとは、システム管理者をいつも悩ませる仕事の一つです。 すべての BSD &unix; マルチユーザシステムは、 従来からいくつかのセキュリティ機構を備えていますが、 ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し 保守する仕事はおそらく、システム管理者としてもっとも大きな責務の一つでしょう。 マシンの安全性に反映されるのは、管理者が作業したことだけです。 またセキュリティ問題は、快適な環境に必要なものと競合します。 一般に &unix; システムは膨大な数のプロセスを同時に動作させることができ、 そのプロセスの大部分は、サーバ — 外部から接続し、通信するものとして動作します。 かつてのミニコンとメインフレームがデスクトップにとってかわり、 さらにコンピュータが相互に接続されたネットワークを形成するようになった今日、 セキュリティは一層大きな関心事になってきています。 また、システムセキュリティには、 さまざまな形での攻撃に対処することとも関係しています。 攻撃の中には root 権限を奪おう (root 権限を破る) とはしないけれども、 クラッシュやシステムの不安定状態を引き起こそうとするものもあります。 このセキュリティ問題は、いくつかに分類することが可能です。 サービス妨害攻撃 (denial of service attack) ユーザアカウントの不正利用 (user account compromise) アクセス可能なサーバを使った root 権限の不正利用 ユーザアカウントを経由した root 権限の不正使用 バックドアの設置 DoS 攻撃 サービス妨害 (DoS) セキュリティ DoS 攻撃 サービス妨害 (DoS) サービス妨害 (DoS) サービス妨害攻撃 (DoS 攻撃) とは、 マシンから必要な資源を奪う行為です。 通常、サービス妨害攻撃はそのマシンで実行されるサーバや ネットワークスタックを過負荷状態にしてマシンをクラッシュさせたり、 マシンを使えなくしたりするような力任せの方法です。 サービス妨害攻撃の中には、 ネットワークスタックのバグを利用して、 パケット一つでマシンをクラッシュさせようとするものもあります。 後者には、カーネルにバグ修正を施すことによってのみ対応することができます。 サーバプロセスに対する攻撃は、オプションを適切に指定することによって、 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで 対応できる場合が多いです。これらに比べると、 ネットワークへの力任せの攻撃への対応はずっと難しくなります。 たとえば、偽造パケットによる攻撃 (spoof-packet attack) は、 インターネットからシステムを切り離す以外の方法で 防ぐことはほとんど不可能です。 この攻撃によって、マシンを落としてしまうことはできないかもしれませんが、 接続しているインターネット回線を飽和させてしまうことはできます。 セキュリティ アカウント不正利用 ユーザアカウントの不正利用は、 サービス妨害攻撃よりもずっとよくある問題です。 このご時勢でも、自分たちのマシンで標準の telnetd, rlogind, rshd, ftpd サーバを実行させているシステ ム管理者は多いのです。これらのサーバは、デフォルトでは、暗号化さ れたコネクション上で動作していません。その結果、抱えているユーザ 数が標準くらいであれば、リモートログイン (そのシステムにログイン するには最も普通で便利な方法です) しているユーザのうち一人以上は、 パスワードを覗き見られてしまうでしょう。システム管理者が注意深い 人ならば、たとえログインが成功していたとしても、リモートアクセス ログを解析して、疑わしい送信元アドレスを探すものです。 ひとたび攻撃者がユーザアカウントへのアクセス権を入手したら、 攻撃者は root 権限を破れると仮定するべきです。 しかし、セキュリティを十分維持し、手入れの行き届いたシステムにおい ては、あるユーザアカウントへのアクセスが可能となっても、 必ずしも攻撃者に root へのアクセス権を与えるとは限りません。この違いは重要です。 というのは、一般的に root へのアクセス権がなければ、 攻撃者は自分の侵入の痕跡を隠蔽することができませんし、 そのユーザのファイルを引っかき回したり、 マシンをクラッシュさせたりするのがせいぜいです。 ユーザアカウントの不正利用はめずらしいことではありません。 なぜなら一般ユーザは、 システム管理者ほど注意を払わない傾向があるからです。 セキュリティ 裏口 (バックドア) システム管理者は、あるマシン上で root 権限を奪取する方法は、 潜在的に何通りもあるということを心しておかねばなりません。 攻撃者は root のパスワードを知っているかもしれませんし、 攻撃者が root 権限で実行されているサーバのバグを見つけ、 ネットワーク接続を介して root 権限を破ることができるかもしれません。 また、攻撃者は suid-root プログラムに存在するバグを知っていて、 ユーザアカウントを破れば root 権限を奪取できるかもしれません。 攻撃者があるマシン上で root 権限を破る方法を知ったならば、 攻撃者は裏口を用意する必要がありません。 これまでに発見され、ふさがれた root の穴の多くには、攻撃者が自分のしたことの痕跡を消そうとした作業が、 かなりの割合で含まれています。 そのため、ほとんどの攻撃者は裏口を作るのです。裏口は、 攻撃者がたやすくシステムへの root アクセスを再び得られるようにしますが、 有能な管理者に侵入を検知する便利な手段を与えるものでもあります。 攻撃者に裏口を作らせないようにするということは、 セキュリティにとっては実際には良くないことかもしれません。 なぜなら、攻撃者が最初に見つけて侵入してきたセキュリティホールは ふさがれないからです。 セキュリティを改善する方法は、常に、 タマネギの皮のように階層化する手法 (a multi-layered onion peel approach) で実装されるべきです。これらは次のように分類できます。 root とスタッフのアカウントの安全性を高める。 root の安全性を高める – root 権限で動作するサーバと suid/sgid バイナリ。 ユーザアカウントの安全性を高める。 パスワードファイルの安全性を高める。 カーネルのコア、raw デバイス、ファイルシステムの安全性を 高める。 システムに対して行なわれた、不適切な変更をすばやく検出す る。 必要と思われる以上の対応をとる (paranoia)。 本章の次の節では、上記の各項目についてより深く掘り下げていき ます。 &os; の安全性を高める セキュリティ &os; の安全性を高める コマンド対プロトコル この文書を通して、アプリケーションを指すのには 太字 を使い、 コマンドを指す場合には、等幅 フォントを使います。 プロトコルは通常のフォントで表します。 このような書体による区別は、 プロトコルであると同時にコマンドでもある ssh などに対して有効です。 セキュリティ 安全性を高める 以下の節では、本章の前節 でとりあげた &os; システムの安全性を高める方法について 述べます。 <systemitem class="username">root</systemitem> アカウントとスタッフアカウントの安全性を高める su root のアカウントの安全性を確保しないうちから スタッフのアカウントの安全性をうんぬんしてもしかたがありません。 ほとんどのシステムでは、root アカウントに割り当てたパスワードが 1 つあり ます。まず最初にすべきことは、このパスワードはいつで も不正利用の危険に晒されていると仮定することです。これは root のパスワードを消すべきだと言っているのではありません。 root のパスワードは、マシンにコンソールからアクセスするのには、 ほとんどいつでも必要なものです。ここで言いたいのは、コンソール 以外からは、そして可能なら &man.su.1; コマンドを実行する場合も root のパスワードを使えないようにするべきである、ということで す。たとえば、あなたが使っている pty が、 /etc/ttys ファイルで insecure と指定 されているか確認してください。そうすると、 telnet や rlogin 経由では root で直接ログインできないようになります。 これは、/etc/ssh/sshd_config を編集して PermitRootLogin に NO が設定されるようにすることで実現できます。 sshd のような、別のログインサービス を使っている場合でも同様に、直接 root へログインすることを許し ていないかどうか確認してください。すべてのアクセス手段 — たとえば FTP のようなサービスが、良くクラックの対象となることを考えましょう。 root への直接ログインは、 システムコンソール経由でのみ可能であるべきなのです。 wheel また当然、システム管理者として自分が root になれるようにしておく必要が ありますから、そのための穴をいくつか開けておきます。し かし、それらの穴を動作させるには、さらに追加のパスワード認証が 必要であるようにしておくことが重要です。 root でアクセス可能と する方法の一つとして、適切なスタッフアカウントを (/etc/group 中の) wheel グループに加えることがあります。 wheel グループに入っているスタッフメンバは su を使って root になることが許されます。 パスワードエントリにおいて、スタッフメンバを wheel グループに置くことによって直接 wheel 権限を与えてはいけません。スタッフメンバのアカウントは staff グループに所属させるべきで、その上で /etc/group ファイルを通して wheel グループに加えるべきです。実際に root アクセスの必要なスタッフメンバのみ wheel グループに置くようにすべきです。 他の認証方法の場合、たとえば Kerberos を使用する場合には、 root アカウントの Kerberos .k5login ファイルを使えば、誰も wheel グループに置く必要なく root に &man.ksu.1; することを許可できます。このやり 方はよりよい解決策なのかもしれません。なぜなら、 wheel のメカニズムでは、侵入者がパスワード ファイルを手に入れ、スタッフアカウントのいずれか 1 つを破るこ とができると、 root を破ることがまだできてしまうからです。 wheel のメカニズムを用いる方が、 何もしないよりは良いのですが、 必ずしも最も安全な選択肢とは限りません。 - + アカウントを完全にロックするには、 + &man.pw.8; コマンドを使うべきです。 - スタッフのアカウント、また究極には - root アカウントの安全性 - を高める間接的な方法は、別のログインアクセスの方法を用いてスタッ - フのアカウントの安全性を高め、その上でそのスタッフのアカウント - の暗号化パスワードを アスタリスク化 - するものです。 - &man.vipw.8; コマンドを使えば、暗号化されたパスワードを - * 1 文字に置き換えられます。 - このコマンドは、/etc/master.passwd - ファイルとユーザ/パスワードデータベースを更新して、 - パスワード認証によるログインができないようにします。 + &prompt.root;pw lock staff - たとえば、次のスタッフアカウントを、 + これにより、ユーザは、&man.ssh.1; + を含むいかなる方法でもログインできなくなります。 + アカウントへのアクセスをブロックするもう一つの方法は、 + 暗号化されたパスワードを + * 1 文字に置き換えることです。 + この文字は、暗号化されたパスワードにマッチすることはないので、 + ユーザアクセスをブロックします。 + たとえば、次のスタッフアカウントを、 + foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh こう変更します。 foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - 暗号化されたパスワードは - * と一致することがないので、 - この変更によって通常のログインはできなくなります。 - こうした後は、スタッフメンバは認証のために &man.kerberos.1; や - 公開鍵 / 秘密鍵の組を用いる &man.ssh.1; のような代わりとなる認 - 証手段を利用しなければなりません。 - Kerberos のようなログイン機構を使う場合は、一般に Kerberos - サーバを実行するマシンと自分のデスクトップワークステーションの安全性を確保しなければなりません。 - また ssh で公開鍵 / 秘密鍵の組を使う場合、 - 一般に、ログイン元マシン (通常は自分のワー - クステーション) の安全性を確保しなければなりません。ここで、 - &man.ssh-keygen.1; で公開鍵 / 秘密鍵の組を生成する際、鍵の組 - をパスワードで防御することにより、鍵の組への防御層を追加するこ - ともできます。スタッフアカウントのパスワードを - アスタリスク でつぶすことができると、 - 管理者自身が設定 - した安全性の高い方法でしかスタッフメンバがログインできないこと - も保証できます。こうして、多くの侵入者が使う重大なセキュリティ - の穴である、 - 安全性の低い無関係なマシンからネットワークを覗き見る方法を塞ぐようなセッションを提供する、 - 安全性の高い暗号 - 化されたコネクションを使うことを、スタッフメンバ全員に強制する - ことができるのです。 + この変更によって + foobar ユーザは、 + 通常のログインはできなくなります。 + このようなアクセス制限をした後は、 + サイトで Kerberos をセットアップしたり、 + ユーザが &man.ssh.1; + の鍵を設定するなどといった認証手段を利用しなければなりません。 - より間接的なセキュリティの仕組みでは、制限の強いサーバから + これらのセキュリティの仕組みでは、制限の強いサーバから 制限の弱いサーバへログインすることを前提としています。たとえば、 メインマシンで、様々な種類のサーバを実行させている場合、ワーク ステーションではそれらのサーバを実行させてはなりません。ワーク ステーションを十分に安全にしておくためには、実行するサーバの数 を、一つもサーバが実行されていないというくらいにまでできる限り 減らすべきです。また、パスワードで保護されたスクリーンセーバを 走らせておくべきです。ワークステーションへの物理的アクセスが与 えられたとすると、もちろん言うまでもなく、攻撃者は管理者が設定 したいかなる種類のセキュリティをもうち破ることができるのです。 このことは、管理者として必ず考えておかねばならない問題ですが、 システム破りの大多数は、ネットワーク経由でリモートから、ワーク ステーションやサーバへの物理的アクセス手段を持たない人々によっ て行われるという事実もまた、念頭に置いておく必要があります。 KerberosIV Kerberos のような方法を使うことで、 スタッフアカウントのパ スワードの変更もしくは停止を一箇所で行なうことと、スタッフメン バがアカウントを持つすべてのマシンに即時にその効果を及ぼすこと が可能となります。スタッフメンバのアカウントが危険に晒されたと きに、すべてのマシンでスタッフメンバのパスワードを即座に変更す る能力を過小評価してはいけません。パスワードが分散されている状 況では、N 台のマシンでパスワードを変更すると、てんやわんやの事 態を招く可能性があります。Kerberos を使用すると、パスワードの 再発行に制限 (re-passwording restriction) を課することもできま す。この機能を使うことにより、ある Kerberos チケットをしばらく 経つとタイムアウトにすることができるだけでなく、一定期間 ( 例 えば、1 ヶ月に 1 回) 経つと、ユーザに新しいパスワードを選ぶよ うに要求することもできます。 root 権限で実行されているサーバと SUID/SGID バイナリの安全性を高める ntalk comsat finger 砂場 (sandbox) sshd telnetd rshd rlogind 用心深いシステム管理者は、自分に必要なサーバプロセスだけを 過不足なく実行させるものです。サードパーティ製のサーバは、よくバグを持っ ていがちだということに注意して下さい。たとえば、古いバージョンの imapd や popper を実行させておくのは、全世界に万能の root の切符を与えているようなものです。自分で注意深くチェックしていない サーバは、決して実行してはいけません。root で実行させる必要のあるサーバはほとんどありません。たとえば、 ntalk, comsat, finger デーモンを、専用ユーザの 砂場 (sandbox) で実行させることができます。 管理者が膨大な数の問題を経験していないのなら、 この「砂場」は完 璧ではありませんが、セキュリティに関するタマネギ的アプローチは ここでも成り立ちます。砂場で実行されているサーバプロセスを経由 して侵入を果たすことができたとしても、攻撃者はさらに砂場から外 に脱出しなければなりません。攻撃者が通過せねばならない層の数が 増えれば増えるほど、それだけ攻撃者が侵入に成功する確率が減りま す。Root の抜け穴は歴史的に、基本システムサーバも含め、 root 権限で実行されるほとんどすべてのサーバプロセスで発見されています。 ユーザが sshd 経由でのみログインし、 telnetd, rshd, rlogind 経由でログインすることが決 してないマシンを稼働させているのであれば、それらのサービスを停 止させて下さい! &os; では、今では ntalkd, comsat, finger は砂場で実行させることがデフォ ルトになっています。次に砂場で実行させるべきプログラムの候補と して、&man.named.8; があります。 /etc/defaults/rc.conf ファイルには、 named を砂場で実行するために必要な 引数がコメントアウトされた形式で含まれています。新しいシステム をインストールしているか、それとも既存のシステムをアップグレー ドして使っているかに依存しますが、砂場として使用する特別のユー ザアカウントがインストールされていないかもしれません。用心深い システム管理者であれば、できるだけいつでも研究を怠らず、サーバ に砂場を仕込むものでしょう。 sendmail 通常、砂場で実行しないサーバが他にいくつかあります。 sendmail, popper, imapd, ftpd などです。これらのうちいくつか のサーバには代わりとなるものがありますが、代わりのものをインス トールするには、あなたが思うより多くの仕事が必要になるかもしれ ません (便利さという要素がまたも勝利を収めるわけです)。これら のサーバは、root 権限で実行しなければばならないかもしれません。また、 これらのサーバ経由で生じる侵入を検出するためには、他の仕組みに 頼らなくてはならないかもしれません。 システムの root 権限の潜在的な穴で他に大きなものには、シ ステムにインストールされた suid-root/sgid バイナリがあります。 これらのバイナリは、rlogin のように、 /bin, /sbin, /usr/bin, /usr/sbin に存在するものがほとんどです。100% 安全なものは存在しないとは いえ、システムデフォルトの siud/sgid バイナリは比較的安全とい えます。それでもなお、root セキュリティホールがこれらのバイナリにときおり発見されています。 1998 年に xterm (普通、suid 設定されています) を脆弱にしていた Xlib の root セキュリティホールが見つかりました。 安全である方がよいので、 用心深いシステム管理者は残念に思いながらも、スタッフのみが実行 する必要がある suid バイナリは、スタッフのみがアクセス可能な特 別なグループに含めるように制限を加え、誰も使わない suid バイナ リは (chmod 000 を実行して) 片付けてしまう でしょう。ディスプレイを持たないサーバは、一般的に xterm のバイナリを必要としません。 sgid バイナリもほとんど同様の危険な存在になり得ます。侵入者が kmem に sgid されたバイナリを破ることができた場合、その侵入者 は /dev/kmem を読み出すことができるように なるでしょう。つまり、暗号化されたパスワードファイルを読み出す ことができるようになるので、パスワードを持つどのアカウントをも、 潜在的な危険に晒すことになります。他にも、 kmem グループを破った侵入者が pty を通して 送られたキーストロークを監視できるという危険があります。キース トロークには、安全な方法でログインするユーザが使っている pty も含まれます。 tty グループを破った侵入者は、ほぼ任意のユーザの tty へ書き込みができます。ユーザが端末プログラムやキーボードを シミュレーションする機能を持ったエミュレータを使っている場合、 侵入者は潜在的に、結局そのユーザとして実行されるコマンドをユー ザの端末にエコーさせるデータストリームを生成できる可能性があり ます。 ユーザアカウントの安全性を高める ユーザアカウントは、普通、安全性を高めることが最も困難です。 スタッフに対しては、とても厳格なアクセス制限を強制しパスワードを アスタリスク で外すことができるでしょうが、 管理者が 持ちうる一般ユーザすべてのアカウントに対して同じことはできない かもしれません。管理者が十分に統率をとることができるなら、管理 者は勝利し、ユーザのアカウントの安全を適切に確保できるかもしれ ません。それができないならば、よりいっそう気を配って一般ユーザ のアカウントを監視するよりほかありません。 一般ユーザアカウントに対し ssh や Kerberos を利用することには、 システム管理がさらに増えたりテクニカルサポートが必要に なるなどの問題があります。それでも、暗号化パスワードファイルと 比較するとはるかに良い解です。 パスワードファイルの安全性を高める できるだけ多くのパスワードをアスタリスクで外し、 それらのアカウントのアクセスには ssh や Kerberos を使うようにすることが、唯一の確実な方法です。 暗号化パスワードファイル (/etc/spwd.db) は root でのみ読み出し可能だけれども、 たとえ、侵入者が root の書き込み権限は得られなくとも、 読み出しアクセス権限を得ることは可能かもしれません。 セキュリティスクリプトで常にパスワードファイルの変更をチェッ クし、報告するようにすべきです (ファイルの完全性のチェック 節参照)。 カーネルのコア、raw デバイス、ファイルシステムの安全性を 高める root の権限を破ると、攻撃者はほとんど何でもできますが、特に重宝さ れる特定の事柄もいくつかあります。たとえば、最近のカーネルは、組 み込みのパケット覗き見デバイス (packet sniffing device) ドライ バを備えているものがほとんどです。&os; では bpf デバイスと呼ばれています。侵入者 は普通、侵入済みのマシンでパケット覗き見プログラムを実行させよ うと試みます。侵入者にわざわざそういう機能を提供する必要はない ので、ほとんどのシステムで bpf デバイスを組み込むべきではありません。 sysctl bpf デバイスを外しても、 /dev/mem と /dev/kmem という悩みの種がまだ残っています。この問題に関しては、侵入者は raw ディスクデバイスに書き込 むこともできます。ほかにも、モジュールローダ、&man.kldload.8; とい う、別のカーネル機能があります。やる気まんまんの侵入者は、KLD モジュールを使って自分独自の bpf もしくはその他覗き見デバイス を動作中のカーネルにインストールできます。この問題を 避けるため、システム管理者はカーネルをより高い安全レベル ( securelevel)、少なくとも安全レベル 1 で実行させる必要がありま す。安全レベルは sysctl を使って kern.securelevel 変数を操作して設定できます。ひとたび安全レベルに 1 を設定すると、raw デバ イスに対する書き込みアクセスは拒否され、たとえば schg のような特別な chflags フラグの機能が 強制されます。システム起動に関わる重要なバイナリやディレクトリ、 スクリプトファイルなど、安全レベルが設定されるまでの間に実行さ れるすべてのものに対しても、確実に schg フラグを設定してください。この設定をやり過ぎても 構いませんが、より高い安全レベルで動作している場合、システムの アップグレードがはるかに困難になります。システムをより高い安全 レベルで実行させるようにするが、すべてのシステムファイルとディ レクトリに schg フラグを設定しないというところで妥協するという手もあります。 もう一つの可能性としては、単純に / および /usr を読み 込み専用でマウントすることです。ここで特筆すべきことは、システ ムを守ろうとして厳しくしすぎると、侵入を検出するという非常に重 要なことができなくなってしまうということです。 ファイルの完全性のチェック: バイナリ、設定ファイルなど ことこの問題に至ると、システム管理者にできることは、便利さ という要素がその醜い頭を上げない程度に、コアシステムの設定と制 御ファイルを防御することだけです。たとえば、 / および /usr にある 大部分のファイルに schg ビットを設定するた めに chflags を使用するのは、おそらく逆効果 でしょう。なぜなら、そうすることでファイルは保護できますが、侵 入を検出する窓を閉ざしてしまうことにもなるからです。セキュリティ のタマネギの最後の層はおそらく最も重要なもの — 検出で す。セキュリティの残りのものは、突然の侵入を検出できなければ、 まったく有用ではありません (あるいは、もっと悪ければ、安全性に 対する間違った感覚を植え付けてしまいます)。 タマネギの仕事の半分は、 攻撃者を攻撃の最中に捕えるようにするために、 攻撃者を食い止めるのではなく侵入を遅らせることなのです。 侵入を検出する最も良い方法は、変更されていたり、消えていた り、入れた覚えがないのに入っているファイルを探すことです。変更 されたファイルを探すのに最も良い方法は、もう一つの (しばしば中 央に集められた)、アクセスが制限されたシステムから行なうもので す。さらに安全でアクセス制限されたシステム上でセキュリティ用ス クリプトを書けば、 スクリプトは潜在的な攻撃者からはほぼ見えなくなります。 これは重要なことです。この有効性を最大限に活用 するためには、一般的に、アクセスの制限されたマシンから実際に使っている他のマシンへのかなりのアクセスを許可する必要があります。普 通は、他のマシンからアクセス制限されたマシンへ読み込み専用の NFS エクスポートをしたり、アクセス制限されたマシンから他のマシンへ ssh 接続を行なうために、 ssh 鍵のペアを作ったりすることで行います。 ネットワークのトラフィックを別にして、NFS は最も可視性 のない方法です — 各クライアント上のファイルシステムを、 事実上検出されずに監視できるようになります。アクセス制限された サーバがスイッチを通してクライアントに接続されている場合、たい てい NFS がより良い選択肢です。アクセス制限されたサーバがハブ や、いくつかのルーティング層を通してクライアントに接続している場合、 NFS は (ネットワークの面で) あまりにも危険なので、 ssh の方が認証を行った跡は残りますが、良い方法でしょう。 アクセス制限されたマシンに、監視しようとするクライアントシ ステムへの少なくとも読み込みのアクセス権を与えたら、次に実際に 監視するためのスクリプトを書かなくてはいけません。NFS マウント をすれば、&man.find.1; や &man.md5.1; などの単純なシステムユー ティリティでスクリプトを書くことができます。少なくとも 1 日 1 回、クライアントのファイルを直接 md5 にかけ、さらにもっと頻繁 に /etc および /usr/local/etc にあるようなコントロール用 ファイルを試験するのが一番です。アクセス制限されたマシンが正し いと知っている、基となる md5 情報と比べて違いが見つかった場合、 システム管理者に調べて欲しいと悲鳴を上げるようにすべきです。優 れたセキュリティ用スクリプトは、/ および /usr などのシステムパーティション上で不適 当に suid されたバイナリや、新たに作成されたファイルや削除され たファイルがないかどうかを調べるでしょう。 NFS ではなく、ssh を使用する場合は、 セキュリティ用スクリプトを書くのはずっと難しいことで す。スクリプトを動かすためには、クライアントに対してスクリプト を scp しなくてはいけませんし、それは目に見 えてしまいます。そして、安全のためには、スクリプトが使うバイナ リ (find など) を scp する必要もあります。 クライアントマシンの ssh クライアントはすでに攻撃されてしまっているかもしれません。 結局のところ、安全でないリンク上の場合は ssh は必要かもしれませんが、ssh を扱うのはとても大変なことです。 優れたセキュリティ用スクリプトは、ユーザやスタッフメンバの アクセス設定ファイルの変更もチェックするものです。 .rhosts, .shosts, .ssh/authorized_keys など MD5 チェックの範囲外になってしまうであろう ファイル群です。 ユーザ用のディスク容量が非常に大きい場合は、パーティション 上の各ファイルを見て回るのに大変な時間がかかるかもしれません。 この場合は、マウントフラグを設定して、 suid されたバイナリを置けないようにするのが良い考えです。 nosuid オプション (&man.mount.8; 参照) が知るべきものでしょう。 とにかく少なくとも週に 1 度はファイルシステムをスキャンするべきです。 なぜなら、この層の目的は、侵入が成功したかどうかに関わらず、 不正侵入の試みがあったことの検出をすることだからです。 プロセスアカウンティング (&man.accton.8; 参照) は、 マシンへの侵入を検出するためのメカニズムとして推奨できる、 比較的オーバヘッドの少ないオペレーティングシステムの機能です。 侵入を受けた後でも当該ファイルが無傷である場合に、侵入者が 実際にどのようにしてシステムに侵入したかを追跡するのに特に役立ちます。 最後に、セキュリティスクリプトはログファイルを処理するよう にし、ログファイル自体もできるだけ安全性の高い方法で生成するよ うにすべきです — リモート syslog は極めて有益になり得ま す。侵入者は自分の侵入の痕跡を覆い隠そうとしますし、また、ログ ファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆく ために極めて重要です。ログファイルを永久に残しておくための 1 つの方法は、システムコンソールをシリアルポートにつないで走らせ、 コンソールを監視している安全なマシンに情報を集めることです。 偏執狂的方法 多少偏執狂的になっても決して悪いことにはなりません。原則的 に、システム管理者は、便利さに影響を与えない範囲でいくつでもセ キュリティ機能を追加することができます。 また、いくらか考慮した結果、 便利さに影響を与えるセキュリティ機能を追加することもできます。 より重要なことは、 セキュリティ管理者はこれを多少混ぜこぜにして使うべきだということです。 — もしあなたが、本文書に書かれている勧告をそのまま使用した場合は、 予想される攻撃者はやはり本文書を読んでいるわけですから、 あなたの防御策を教えてしまうことになります。 サービス妨害攻撃 サービス妨害 (DoS) このセクションではサービス妨害攻撃 (DoS 攻撃) を扱います。 サービス妨害攻撃は、普通は、パケット攻撃です。ネットワークを飽 和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシステム管理者が打てる手はそれほど多くありませんが、 一般的に、以下のような方法により、 その種の攻撃によってサーバがダウンしないことを確実にすることで、 被害をある限度に食い止めることはできます。 サーバの fork の制限。 踏み台攻撃の制限 (ICMP 応答攻撃、ping broadcast など)。 カーネルの経路情報のキャッシュを過剰に用意する。 よくあるサービス妨害攻撃は、fork するサーバに対して攻撃するもので、 多くの子プロセスを起動させることにより、 メモリ、ファイル記述子などを使いつくし、 ホストシステムを最終的に停止させます。 inetd (&man.inetd.8; 参照) には、この種の攻撃を制限するオプションが いくつかあります。マシンがダウンすることを防止することは可能で すが、この種の攻撃によりサービスが中断することを防止することは 一般的に言ってできないことに注意する必要があります。 inetd のマニュアルページを注意深く読んで下さい。特に、 , , オプションに注意して下さい。IP 偽造攻撃 (spoofed-IP attack) は inetd の オプションの裏をかけるので、 一般にオプションを組み合わせて使用するべきであることに注意して下さ い。スタンドアロンサーバの中には、自分自身で fork を制限するパ ラメータを持っているものがあります。 Sendmail には、 オプションがあります。シ ステム負荷の値変化には遅れがあるので、 Sendmail の負荷限界指定オプションを使うよりも、 このオプションを使う方がまともに動作する可能性ははるかに高いです。 sendmail の実行を開始する際に、 MaxDaemonChildren パラメータを設定するべき です。その値は、通常見込まれる負荷を扱える程度に十分高いが、 それだけの数の Sendmail インスタンスを操作しようとするとマシンが卒倒してしまうほどには高くないような値に設定するべきです。 Sendmail をキュー処理モード () で実行することや、 sendmail デーモン (sendmail -bd) をキュー処 理用プロセス (sendmail -q15m) と別に実行す ることも、用心深いことと言えます。それでもなおリアルタイムでの 配送を望むのであれば、 のようにすることで、 キュー処理をはるかに短い時間間隔で行うことができます。いずれに しても、MaxDaemonChildren オプションに合理 的な値を確実に指定して、Sendmail がなだれをうって失敗することがないようにして下さい。 syslogd は直接攻撃される可能性 があるので、可能ならばいつでも オプション を用いることを強く推奨します。これができないなら、 オプションを使って下さい。 TCP Wrapper の逆 identd などの接 続返し (connect-back) を行うサービスについては十分注意を払うよ うにするべきです。これらは直接攻撃を受ける可能性があります。こ ういう事情があるので、TCP wrapper の 逆 ident 機能を使おうとは思わないのが一般的です。 境界ルータのところでファイアウォールを設けて、外部からのア クセスに対して内部サービスを防御するという考えは実によいもので す。この考えは、LAN の外部からの飽和攻撃を防ぐことにあり、内部 サービスをネットワークベースの root 権限への攻撃から防御するこ とにはあまり考慮を払っていません。ファイアウォールは常に排他的 に設定して下さい。つまり、ポート A, B, C, D と M から Z まで以外 のすべてにファイアウォールを設ける というふうにです。このようにすることで、 named (ゾーンのプライマリである場合)、 ntalkd, sendmail などのインターネットからア クセスできるサービスとして特に指定するもの以外の、小さい番号の ポートすべてをファイアウォールで防御することができます。ファイ アウォールをこの他のやり方 — つまり包含的もしくは受容的 なファイアウォールとして設定しようとする場合、 close することを忘れてしまうサービスがいくつか 出てきたり、新しい内部サービスを追加したのにファイアウォールの 更新を忘れたりする可能性がよく出てきます。ファイアウォール上の 大きい番号のポートを開けておくことにより、小さい番号のポートを 危険に晒すことなく受容的な動作を許すことができます。&os; で は、net.inet.ip.portrange への sysctl (sysctl -a | fgrep portrange) をいろいろ使用することで、動的バインドに使用される ポート番号の範囲を制御できることを記憶にとどめておいてください。 これによりファイアウォールの設定を簡略化することもできます。 たとえば、通常の first/last 範囲として 4000 から 5000 を、 高位ポートの範囲として、49152 から 65535 を指定し、 (いくつかのインターネットアクセス可能 なポートをブロックから除外するのはもちろんですが) 4000 より下のすべてのポートをブロックするという設定が考えられます。 また別のよくあるサービス妨害攻撃として、踏み台攻撃 (springboard attack) と呼ばれるものがあります — これは、 あるサーバを攻撃し、そこ結果として生成される応答が自分自身、ロー カルネットワーク、そして他のマシンを過負荷に追い込むようにする 攻撃です。この種の攻撃の中で最もありふれたものに、 ICMP ping broadcast 攻撃があります。攻撃 者は、実際に攻撃したいマシンのアドレスを送信元アドレスに設定し た ping パケットを偽造して、対象の LAN のブロードキャストアド レスに向けてパケットを送信します。境界にあるルータがブロードキャ ストアドレスに対する ping パケットを握り潰すように設定されてい ない場合、LAN は、詐称された送信元アドレスに向けて応答パケット を生成するはめになり、犠牲となるマシンが飽和するところまで行っ てしまいます。攻撃者が同じトリックを異なるネットワーク上のいく つものブロードキャストアドレスに対して同時に使用した場合、とく にひどいことになります。これまでに、120 メガビット以上のブロー ドキャスト攻撃が観測されています。2 番目の踏み台攻撃は、ICMP エラー報告の仕掛けを狙うものです。攻撃者は ICMP エラー応答を生 成するパケットを生成し、サーバの受信ネットワークを飽和させ、そ の結果としてサーバが送信ネットワークを ICMP 応答で飽和させてし まうようにすることができます。メモリを消費し尽くさせることによ り、この種の攻撃でサーバをクラッシュさせることも可能です。サー バが生成した ICMP 応答を十分速く送信できない場合、とくにひどい ことになります。 この種の攻撃の効果を抑制するには、 sysctl 変数の net.inet.icmp.icmplim を使ってください。 踏み台攻撃の 3 つめの主要なクラスに属する攻撃は、 udp echo サービスのような、特定の inetd 内部サービスに関連する ものです。攻撃者は、単に送信元アドレスがサーバ A の echo ポー トであり、送信先アドレスがサーバ B の echo ポートであるように UDP パケットを偽造します。ここでサーバ A, B はともにあなたの LAN に接続されています。この 2 つのサーバは、この一つのパケッ トを両者の間で互いに相手に対して打ち返しあいます。このようにし てパケットをほんのいくつか注入するだけで、攻撃者は両方のサーバ と LAN を過負荷状態にすることができます。同様の問題が内部 chargen ポートにも存在します。 有能なシステム管理者はこの手の inetd 内部テストサービスのすべてを無効にしておくものです。 偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を 生じさせるために用いられることもあります。 net.inet.ip.rtexpire, rtminexpire, rtmaxcache の sysctl パラメータを参照して下さい。でた らめな送信元 IP アドレスを用いた偽造パケット攻撃により、カーネ ルは、一時的なキャッシュ経路を経路情報テーブルに生成します。こ れは netstat -rna | fgrep W3 で見ることがで きます。これらの経路は、普通は 1600 秒程度でタイムアウトになり ます。カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを 検知すると、カーネルは動的に rtexpire を減らしますが、rtminexpire より小さくなるようには決して減らしません。ここに問題が 2 つあります。 負荷の軽いサーバが突然攻撃された場合、カーネルが十分素 早く反応できないこと。 カーネルが持続的攻撃に耐えられるほど十分 rtminexpire が低く設定されていないこと。 自分のサーバが T3 もしくはそれより高速の回線でインターネッ トに接続されている場合、&man.sysctl.8; を用いて rtexpire と rtminexpire とを手動で上書きしておくことが思慮深いことといえます。どちらか 一方でも 0 には決してしないで下さい (自分のマシンをクラッシュ させたくないのであれば)。両パラメータを 2 秒 に設定すれば、攻撃から経路情報テーブルを守るには十分でしょう。 Kerberos および SSH を用いたアクセスの問題 ssh KerberosIV もしあなたが、Kerberos と ssh を使いたいのだとしたら、 両者に関して言っておかねばならない問題がいくつかあります。 Kerberos 5 は大変優れた認証プロトコルですが、Kerberos 化された telnet や rlogin は、バイナリストリームを扱う のに不向きになってしまうようなバグがあります。さらに、デフォル トでは、Kerberos は オプションを使わない限 りセッションを暗号化してくれません。 Ssh では、デフォルトですべてを暗号 化してくれます。 ssh はあらゆる場面でとても良く働いてくれます。 ただし、デフォルトで暗号鍵を転送してしまうこと を除けばです。これはつまり、暗号鍵を持った安全なワークステーショ ンがあって、この暗号鍵で残りのシステムとアクセスできるようになっ ている場合に、安全でないマシンへ ssh 接続を行なうとあなたの暗号鍵を使えてしまうということです。 実際の鍵そのものが見えてしまうわけではありませんが、 ssh はあなたが login している間、転送用ポートを作ります。攻撃者が安全でないマシンの root を破ったら、このポートを使って暗号鍵を取得し、 この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。 スタッフのログインには、Kerberos を組み合せた ssh を使用することを勧めます。 Ssh は、Kerberos 対応機能と一緒 にコンパイルできます。こうすると、見えてしまうかもしれない ssh 鍵をあまりあてにしないで良いようになります。 また、それと同時に、Kerberos 経由でパスワードを保護することもできます。 ssh 鍵は、安全なマシンからの自動化されたタスク (Kerberos はこの用途には不向きです) のみに使用するべきです。また、 ssh の設定で鍵転送をしないようにするか、あるいは ssh が authorized_keys ファイル中に書くことを許 している from=IP/DOMAIN オプションを使用し て、特定のマシンからログインしてきたときのみ鍵が有効であるよう にすることも勧めます。 DES, Blowfish, MD5 と Crypt BillSwingle改訂: セキュリティ crypt crypt Blowfish DES MD5 訳: &a.hanai;, 12 September 1996. 訳改訂: &a.jp.hino;, 12 March 2001. &unix; システムにおけるすべてのユーザは、そのアカウントに対応し た一つのパスワードを持っています。それらのパスワードはユーザ本人 と本当のオペレーティングシステムのみが知っているべきであるという ことは明らかでしょう。それらのパスワードを秘密に保っておくために、 パスワードは一方向ハッシュとして知られる方式で暗 号化されます。一方向ハッシュとは、簡単に暗号化はできるが解読は難 しいという方法です。言葉を換えると、先ほど明らかであると書いたの は実は正しくないのです: オペレーティングシステム自身は 本当はパスワードを知らないのです。その代わりに 暗号化された形でのみパスワードを知っていま す。素のテキストとしてパスワードを得る唯一の方法は、 可能な限りのパスワード空間を検索するという力任せの方法です。 不幸なことに、&unix; が生まれようとしているときにパスワードを 安全な形で暗号化できる方式は DES (Data Encryption Standard) に基づいたものだけでした。このことは米国に住んでいるユーザにとって は大して問題ではありませんでしたが、DES のソースコードを米国外に 輸出することはできないという問題がありました。そのために、 &os; は、米国の法律を守ることと、未だに DES を使っていた他の &unix; 一族との互換性を保つこととを両立する方法を探し出す必要がありました。 その解決方法は、米国のユーザは DES のライブラリをインストー ルして DES を使用できるが、米国外のユーザは国外に輸出可能な他の ひとつの暗号化方式を使用することができる、というように暗号化ライ ブラリを分割することでした。これが &os; がデフォルトの暗号化 方式として MD5 を使うようになったいきさつです。MD5 は DES よりも より安全であると考えられているため、DES をインストールする一番の 理由は互換性を保つためといえます。 暗号化機構を理解する 現在では、ライブラリは DES, MD5 および Blowfish ハッシュ関数に対応しています。デフォルトでは、&os; はパスワードの暗号化に MD5 を利用します。 &os; がどの暗号化方式を使うようにセットアップされている かを判断するのは簡単です。 /etc/master.passwd ファイルの中の暗号化さ れたパスワードを調べてみるのが一つの方法です。MD5 ハッシュで暗 号化されたパスワードは、DES ハッシュで暗号化されたパスワードよ りも長く、$1$ という文字で始まるという特徴を持っています。 $2a$ で始まるパスワードは、Blowfish ハッシュ関数で暗号化されています。 DES のパスワードはこ れといって識別可能な特徴は持っていませんが、MD5 のパスワードよ りは短く、そして $ という文字を含ま ない 64 文字のアルファベットを使って表現されているので、比較的 短い文字列でドル記号で始まっていないものはおそらく DES のパス ワードでしょう。 新規パスワードがどちらのパスワード形式になるかは、 /etc/login.conf の中の passwd_format ログインケーパビリティによって制御されます。 その値としては、des, md5 または blf を設定することができます。 ログインケーパビリティに関するより詳細な情報は、 &man.login.conf.5; マニュアルページをご覧ください。 ワンタイムパスワード ワンタイムパスワード セキュリティ ワンタイムパスワード デフォルトで、&os; は OPIE (One-time Passwords In Everything) に対応しています。 OPIE はデフォルトでは MD5 ハッシュを使用します。 ここでは、三種類の異なる「パスワード」について説明します。 まず一つ目は、あなたが普段使っている普通の &unix; スタイルの、もしくは Kerberos のパスワードです。ここではこれを &unix; パスワード と呼ぶことにします。 二つ目は、OPIE の &man.opiekey.1; プログラムによって生成され、 &man.opiepasswd.1; プログラムとログインプロンプトが受け付けるパスワードです。 ここではこれを ワンタイムパスワード と呼ぶことにします。三つ目のパスワードは、 opiekey (と場合により opiepasswd) プログラムに対してユーザが入力する秘密のパスワードで、 ワンタイムパスワードを生成するのに使われます。ここではこれを 秘密のパスフレーズ もしくは単に パスフレーズ と呼ぶことにします。 (訳注: ユーザが頭の中だけにしまっておくべきものが、 この秘密のパスフレーズです。なお、原文ではこれを password と表記していますが、 混乱を避けるために訳文ではすべて 秘密のパスフレーズ に統一しています)。 秘密のパスフレーズは、&unix; パスワードと何の関連性もありません。 両者を同一に設定することは可能ですが、お奨めしません。古い &unix; パスワードは長さが 8 文字に制限されていました &os; では、標準のログインパスワードは、128 文字までとなります。。 これに対し、OPIE では秘密のパスフレーズを好きなだけ長くすることができます (訳注: 実装上、key コマンドなどの バッファ長で制限されてしまう可能性があります。200 文字程度に押 えておいた方がよいでしょう :-)。 6 語から 7 語からなるパスフレーズがふつうです。ほとんどの部分で、 OPIE システムは &unix; のパスワードシステムと完全に独立して動作するようになっています。 パスフレーズに加え、OPIE システムにとって重要な 2 種類のデータがあります。一つは シード (seed: 種) または キー (key: 鍵) と呼ばれるもので、2 つの文字と 5 つの数字で構成されます。もう一つは シーケンス番号 (iteration count) で、1 から 100 までの整数です。OPIE はここまで に述べたデータを利用してワンタイムパスワードを生成します。その方 法は、まずシードと秘密のパスフレーズを連結し、それに対してシーケ ンス番号の回数だけ MD5 ハッシュを繰り返し計算します。 そしてその結果を 6 つの短い英単語に変換します。 認証システム (一次的には PAM) は、前回最後に受け付けたワンタイムパスワードを記録しています。 そして、その前回 のワンタイムパスワードと、ユーザが入力したワンタイムパスワードを 1 回ハッシュ関数にかけた結果とが一致した場合に、このユーザは認証 されます。一方向ハッシュ関数を使っているので、もし正しく認証され たワンタイムパスワードが一回盗聴されたとしても、次回以降に使われ る複数のワンタイムパスワードを生成することは不可能です。シーケ ンス番号はログインが成功するたびに一つずつ減らされて、ユーザとロ グインプログラムの間で同期が取られます。シーケンス番号が 1 まで 減ったら、OPIE を再度初期化する必要があります。 次に、それぞれのシステムで関連する いくつかのプログラムについて説明します。 opiekey プログラムは、シーケンス番号と、シードと、 秘密のパスフレーズを受け付けて、ワンタイムパスワード 1 つ、 または一連のワンタイムパスワードの一覧を生成します。 opiepasswd プログラムは、OPIE を初期化するのに使用され、また秘密のパスフレーズ、 シーケンス番号やシードを変更するためにも使用されます。 このプログラムを実行するには、秘密のパスフレーズか、 または、シーケンス番号とシードとワンタイムパスワードの 1 組かの、どちらかを与えます。 opieinfo プログラムは、 認証ファイル (/etc/opiekeys) を調べて、 プログラムを起動したユーザの現在のシーケンス番号とシードを表示します。 この文書では、4 種類の異なる操作について説明します。 1 つ目は、 opiepasswd を信頼できる通信路上で利用して、 最初にワンタイムパスワードを設定したり、 秘密のパスフレーズやシードを変更する操作です。 2 つ目は、同じことを行うために opiepasswd を信頼できない通信路上で利用する操作です。 この場合は信頼できる通信路経由の opiekey を併用します。3 つ目は、opiekey を使い、信頼できない通信路を通じてログインする操作です。 4 番目は、opiekey を使って複数のワンタイムパスワードを一気に生成する操作です。 ここで生成した複数のワンタイムパスワードは、 メモしたり印刷したりして携帯し、 信頼できる通信路が一切ないところで利用することができます。 (訳注: ワンタイムパスワードを記録した紙をなくさないこと! 電話番号や IP アドレス、ユーザ名を一緒にメモしていたら最悪です!!) 信頼できる通信路での初期化 OPIE を初めて初期化するには、opiepasswd コマンドを実行してください。 &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. ) `opiepasswd' コマンドが出力する注意です。訳すと、 ) この手順はコンソール以外では利用しないでください。リモートからは ) 絶対に利用してはいけません。telnet, xterm またはダイアルアップで ) 利用している場合は、^C を入力するかパスワードを入れずに終了してく ) ださい。その後、opiepasswd を -c オプションなしで実行してください。 Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED Enter new secret pass phrase: または Enter secret password: というプロンプトに対して、 あなたが考えた秘密のパスフレーズを入力します。このパスフ レーズはログインするときに使うものではなく、ログインするときに 使うワンタイムパスワードを生成するために使うものであることを覚 えておいてください。ID から始まる行は、 1 回分のパラメータで、 あなたのログイン名とシーケンス番号とシードです。 (訳注: keyinit コマンドは 次回にログインするときに使えるパラメータを参考のためにここで表示します)。 システムにログインするときには、 システム側が自動的にこれらのパラメータを表示してくれますから、 これらのパラメータを 覚えておく必要はありません。最後の行が、今述べたパラメータと入力 された秘密のパスフレーズから計算されたワンタイムパスワードです。 この例を実行した後、次にログインするときに打ち込むべきワンタイ ムパスワードがこれです。 信頼できない通信路での初期化 信頼できない通信路を使って秘密のパスフレーズを初期化または変更するためには、 それとは別に opiekey プログラムを実行するための信頼できる通信路を用意しておく必要があります。 たとえばそれは、 信頼できるマシンのシェルプロンプトだったりするでしょう。 (訳注: ここでの通信路とはマシンそのものになりま す。信頼できるマシンとは、信頼できる人がしっかり管理しているマ シンということです)。他に準備しておくものとして、シーケンス番 号 (100 は適切な値といえるでしょう) と、場合によっては自分で考 えた、またはランダムに生成されたシードがあります。(あなたが S/Key を初期化しようとしているマシンへの) 信頼できない通信路を 使うときには、opiepasswd コマンドを以下のように使用します。 &prompt.user; opiepasswd Updating unfurl: You need the response from an OTP generator. ) `opiepasswd' コマンドが出力する注意です。訳すと、 ) OTP 生成器の返す出力が必要になります。 Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY デフォルトのシードで構わなければ、Return を押してください。次に、アクセスパスワードを入れる前に、あらか じめ用意しておいた信頼できる通信路へ移って、 先ほどと同じパラメータを入力します。 &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT ここで信頼できない通信路の方に戻って、 生成されたワンタイムパスワードをコピーして対応するプログラムに入力します。 ワンタイムパスワードを一つ生成する OPIE を初期化したら、 ログイン時には以下のようなプロンプトが出てくるでしょう。 &prompt.user; telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: <ユーザ名> otp-md5 498 gr4269 ext Password: ここでは表示していませんが、OPIE のプロンプトには便利な機能が備わっています。 パスワードプロンプトに対して、何も入力せずに Return を押すとエコーモードに切り替わります。 つまりタイプした文字がそのまま見えるようになるのです。 これは、紙に印刷していたりするワンタイムパスワードを 手で入力しなければならない場合に特に役立つ機能です。 MS-DOS Windows MacOS 次に、 このログインプロンプトに対して入力するワンタイムパスワードを生成しなければなりません。 これは、opiekey プログラムを使える信頼できるマシン上で行わなければなりません。 (これらのプログラムには DOS や &windows;, &macos; 版があります)。 どちらも、コマンドラインからシーケンス番号とシードを指定しなければなりません。 ログインしようとしているマシンのログインプロンプトから直接カットアンドペーストすると楽でしょう。 信頼できるシステムで &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT ここでワンタイムパスワードが得られました。 ログインを続けましょう。 複数のワンタイムパスワードを生成する 都合によっては、 信頼できるマシンや信頼できる通信路が一切確保できないようなところで S/Key を使う必要があるでしょう。 このような場合には、opiekey コマンドを使って複数のワンタイムパスワードをあらかじめ一気に生成し、 紙に印刷して携帯していくことができます。たとえば &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: <secret password> 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI という引数によって 5 個のワンタイム パスワードを順に生成します。ここで は、最 後のシーケンス番号となるべき数字です。出力は普通に使う順番とは 逆に出力されていることに注意してください (訳注: 一番最初に使うワンタイムパスワードは一番最後に出力され たものです)。この結果をカットアンドペーストして lpr コマンドを使って印刷すると よいでしょう。 もしあなたがセキュリティに偏執するなら、この結果を紙と鉛筆を使っ て手で書き移した方がよいかもしれません。ここで、出力の各行はシー ケンス番号とそれに対応する一回分のワンタイムパスワードです。 消費済みの ワンタイムパスワードの行をペンで消していくと便利で しょう。 &unix; パスワードの利用を制限する OPIE は、ログインセッションの IP アドレスをベースとした &unix; パスワードの使用を制限できます。 関連ファイルは、/etc/opieaccess で、 デフォルトで用意されています。 このファイルの詳細や、 このファイルを使用する際に考慮すべきセキュリィについては &man.opieaccess.5; を確認してください。 以下は opieaccess ファイルの例です。 permit 192.168.0.0 255.255.0.0 この行では、(なりすましされやすい) IP ソースアドレスが、 ある値やマスクにマッチするユーザに対して、 &unix; パスワードをいつでも許可します。 もし opieaccess のどのルールにも一致しなければ、 デフォルトでは非 OPIE ログインは使えません。 TCP Wrappers Tom Rhodes 執筆: TCP Wrappers &man.inetd.8; に詳しい方であれば、 TCP Wrappers について聞いたことがあるでしょう。 しかし、 その有効性をネットワーク環境において完全に理解している人はほとんどいなく、 誰もがネットワーク接続を取り扱うために、 ファイアウォールをインストールしたいと考えているようです。 ファイアウォールは、幅広い用途がある一方で、 接続元に対しテキストを送るといった、取り扱ない作業があります。 - TCP ソフトウェアは、これ以上のことができます。 + TCP Wrappers ソフトウェアは、 + これ以上のことができます。 以下の節では、 TCP Wrappers の多くの機能が説明されています。 そして、適応できる場合には、設定行の例が紹介されています。 TCP Wrappers ソフトウェアは、 - inetd + inetd の管理のもとにすべてのサーバデーモンに対応する機能を拡張します。 この方法を使うことで、ログへの対応、 接続に対してメッセージを返したり、 内部の接続だけを許可するようにデーモンを設定することなどが可能となります。 これらの機能のいくつかはファイアウォールでも実装できますが、 保護のための特別なレイヤを追加するだけでなく、 ファイアウォールが提供する以上の管理を提供します。 TCP Wrappers 機能の追加は、 ファイアウォールのより良い置き換えと考えるべきではありません。 TCP Wrappers は、 ファイアウォールおよび他のセキュリティ設定と組み合わせて使うことができ、 システムを守るための追加のレイヤとして上手く機能します。 - この設定は inetd の設定の拡張なので、 + この設定は inetd の設定の拡張なので、 inetd の設定 章をすでに読んでいることを想定しています。 &man.inetd.8; により起動されるプログラムは、正確には、 デーモン ではありませんが、 伝統的にデーモンと呼ばれています。 この章でも、このように呼ぶこととします。 初期設定 &os; 上で TCP Wrappers を使用ために必要となるのは、 rc.conf から オプションで - inetd サーバが起動されることを確認するだけです。 + inetd + サーバが起動されることを確認するだけです。 これはデフォルトの設定です。 もちろん、 /etc/hosts.allow も適切に設定されていることが前提です。 この場合、&man.syslogd.8; はシステムログにメッセージを出力します。 他の TCP Wrappers の実装と異なり、 hosts.deny は廃止されました。 すべての設定オプションは /etc/hosts.allow に書かれている必要があります。 最も簡単な設定におけるデーモンの接続ポリシは、 /etc/hosts.allow の中で、 オプションごとに許可またはブロックするように設定するというものです。 - &os; のデフォルトの設定では、inetd + &os; のデフォルトの設定では、inetd から起動されたすべてのデーモンの接続を許可します。 この設定を変更することについては、 基本的な設定を理解した後で議論されるべきです。 基本的な設定は、通常 daemon : address : action という形式です。ここで、 daemon は、 inetd が起動するデーモンの名前です。 address の部分は、有効なホスト名、 IP アドレスまたは、 括弧 ([ ]) で囲まれた IPv6 アドレスです。 - action フィールドの部分は、アクセスを適切に許可または拒否をするように、 - allow または deny となります。 + action フィールドの部分は、 + アクセスを適切に許可または拒否をするように、 + allow または deny となります。 最初のマッチしたルールが適用されると、 設定はそこで終わることを覚えておいてください。 これは、設定ファイルは昇順にルールのマッチをスキャンされ、 マッチすると、ルールが適用され、 検索のプロセスは停止することを意味しています。 他にもいくつかのオプションが存在し、以降の節で説明されます。 簡単な設定の行は、上記の情報のみで簡単に構成されます。 例として、POP3 の接続を、 mail/qpopper デーモンから許可するには、以下の行を hosts.allow に追加してください。 # This line is required for POP3 connections: qpopper : ALL : allow - この行を追加したら、inetd を再起動してください。 + この行を追加したら、inetd + を再起動してください。 これを行うには、&man.kill.1; コマンドを使うか、 restart パラメータとともに、 /etc/rc.d/inetd を使ってください。 高度な設定 TCP Wrappers で高度な設定もできます。 接続を取り扱う以上の制御を行うことができるのです。 ある時は、接続しているホストまたはデーモンにコメントを返すことが良い考えのことがあります。 別の場合では、おそらくログファイルを記録したり、 管理者にメールで送る必要があることもあるでしょう。 またその他の状況としては、 サービスをローカルの接続のみで使用できる必要がある場合もあります。 これらはすべて、ワイルドカード と呼ばれる設定のオプション (拡張文字および外部コマンドの実行) で可能となります。 以下の 2 つの節では、 このような状況への対応について触れています。 外部コマンド 接続は拒否しなければならないが、 その理由を接続の確立を試みた相手に送りたい状況を考えてください。 これは、どのように行うことができるでしょうか？ このアクションは、 オプションを使うことで実現可能です。 接続が試みられると、 はシェルコマンドまたはスクリプトの実行を要求します。 この場合の例は、 hosts.allow ファイルに書かれています。 # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." この例は、 You are not allowed to use daemon from hostname. というメッセージを、 アクセスファイルの中で設定されていないすべてのデーモンに対して返します。 接続元に対し、確立された接続が破棄された直後に返答することは、 非常に有効です。 返信に使われるメッセージは、" 文字で囲む 必要 があります。 この規則に例外はありません。 攻撃者や攻撃者のグループは、 これらのデーモンの接続のリクエストであふれさせることにより、 サーバに対して DoS 攻撃を仕掛けることができます。 このような状況において、他の可能性は オプションを使うことです。 と同様に、 は、暗黙のうちに接続を拒否し、 外部のシェルコマンドやスクリプトを実行できます。 と異なり、 は、 接続を確立した相手に対し、返事を返すことはありません。 たとえば、以下のような設定の行を考えてみてください。 # We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny この行は、 *.example.com ドメインからの接続をすべて拒否します。 同時にホスト名、IP アドレスおよびアクセスを試みたデーモンが、 /var/log/connections.log ファイルに記録されます。 - すでに説明した置換文字 (たとえば %a) 以外にも置換文字があります。 + すでに説明した置換文字 (たとえば %a) + 以外にも置換文字があります。 完全な一覧は &man.hosts.access.5; マニュアルページをご覧ください。 ワイルドカードオプション これまでの例においては、継続して ALL を使用する例が用いられてきました。 この機能を拡張する他のオプションも存在します。たとえば、 ALL は、 デーモン、ドメインまたは IP アドレスのすべてのインスタンスのどれかにマッチするかどうかに使われます。 他のワイルドカードは、偽造された IP アドレスを提供するホストにマッチするかどうかに用いられる PARANOID です。 言い換えると、paranoid を使うことで、 ホスト名と異なる IP アドレスからの接続があった時のアクションを定義できます。 以下の例は、これらの説明を明確にするでしょう。 # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny この例では、ホスト名から検索される IP アドレスと異なる IP アドレスを持つ sendmail への接続のすべてのリクエストを拒否します。 クライアントもしくはサーバの DNS の設定が間違っている場合に、 PARANOID を使うと、 サーバがとても使いづらくなります。 管理者の慎重さが求められます。 ワイルドカードおよび関連する機能についてもっと知りたい場合には、 &man.hosts.access.5; マニュアルページをご覧ください。 上記の設定が動作するには、hosts.allow の中で、最初の設定の行がコメントアウトされている必要があります。 これはすでにこの章の最初で説明した通りです。 <application>KerberosIV</application> MarkMurray寄稿: MarkDapoz基にした文書の執筆: Kerberos 訳: &a.jp.arimura;. Kerberosは、 サーバのサービスによってユーザが安全に認証を受けられる ようにするための、ネットワークの付加システム及びプロトコルです。 リモートログイン、リモートコピー、 システム間での安全なファイルのコピ ーやその他のリスクの高い仕事がかなり安全に、 そしてこれまでより制御 できるようになります。 以下の文章は、 &os; 用として配布されている Kerberos をセットアップ する際のガイドとして読むことができます。しかし、 完全な説明が必要な場合には、マニュアルページを読んだ方がよい でしょう。 <application>KerberosIV</application> のインストール MIT KerberosIV インストール Kerberos は選択が任意な &os; のコンポーネントです。 もっとも簡単なインストール方法は、&os; のインストール時に sysinstall で krb4 または krb5 配布物を選択することです。 そうすると、Kerberos の eBones (KerberosIV) または Heimdal (Kerberos5) 実装がインストールされます。 これらの実装が入っているのは、 これがアメリカ合衆国およびカナダの外で開発されたものであるため、 アメリカ合衆国からの暗号ソフトウェアの輸出が制限されていた時代でも アメリカ合衆国およびカナダ以外の国に住んでいるシステム所有者の手に入るものだったからです。 ほかに、MIT で実装された Kerberos が Ports Collection の security/krb5 から利用できます。 初期データベースの作成 この作業はKerberosサーバだけでおこないます。まず、 古いKerberosの データベースが存在しないことを確認してください。 ディレクトリ/etc/kerberosIVに移って、 次のファイルだけが 存在することをチェックします。 &prompt.root; cd /etc/kerberosIV &prompt.root; ls README krb.conf krb.realms もし他のファイル (principal.* や master_key) が 存在する場合には、 kdb_destroyというコマンドで古い Kerberosデータベースを消してください。 Kerberosが走っていなければ、 単に余計なファイルを消せばよいです。 まず、krb.conf と krb.realmsを編集してKerberosの 管理領域 (realm) を定義してください。 ここでは管理領域が EXAMPLE.COM で、サーバ名が grunt.example.com であるとします。 krb.conf というファイルを次のように編集してください。 &prompt.root; cat krb.conf EXAMPLE.COM EXAMPLE.COM grunt.example.com admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov この例にあるような他の管理領域は、実際には必要ありません。 この例は複数の管理領域を認識する方法を示したものですので、 これらの行は含めなくても結構です。 1行目はこのシステムが動いている管理領域の名前です。 他の行は管理領域とホスト名のエントリです。 行の1つめの単語が管理領域で、2つめがその管理領域の中で 鍵配布センター(Key Distribution Center) として働くホスト名です。ホスト名の次に admin server と書いてある場合には、そのホストが 管理データベースサーバ (Administrative Database Server) も提供することを意味します。 これらの単語について詳しく知りたい場合には Kerberos のマニュアルページをご覧ください。 ここで、EXAMPLE.COM という管理領域に grunt.example.com およびその他の .example.com ドメインのすべてのホストを追加しなければなりません。 krb.realms は次のようになります。 &prompt.root; cat krb.realms grunt.example.com EXAMPLE.COM .example.com EXAMPLE.COM .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU もう一度注意しますが、他の管理領域を書く必要はありません。 これらは複数の管理領域を認識できるようにマシンを設定する方法を 示した例ですので、これらの行は消して構いません。 1行目は名前をつけた管理領域に 特定の システムを含めるための ものです。 残りの行は名前をつけた管理領域にサブドメインのデフォルトの システムを含めるためのものです。 これでデータベースを作成する準備ができました。 この操作はKerberos サーバ (鍵配布センター) を起動するだけです。 kdb_initコ マンドを次のように実行してください。 &prompt.root; kdb_init Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: ここで鍵を保存して、 ローカルのマシンにあるサーバが取り出せるように します。 それにはkstashコマンドを使用します。 &prompt.root; kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! これで暗号化されたマスタパスワードが /etc/kerberosIV/master_key に保存されました。 すべてが動くようにするための設定 KerberosIV 初期設定 Kerberosを導入する それぞれの システムのデータベースに、2つ のprincipal (主体名) を追加する必要があります。その名前は kpasswdとrcmdです。 これら2つのprincipalは、個々 のシステムにおいて、 システム名と同じ名前のインスタンスと組にして作成 されます。 これらの >kpasswd と rcmd というデーモンによって、他の システムからKerberosのパスワードを変更したり、 &man.rcp.1; や &man.rlogin.1;, &man.rsh.1; といったコマンドを実行したりできるようになります。 それでは実際にこれらのエントリを追加しましょう。 &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt <Not found>, Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- ここは「RANDOM」と入力してください Verifying password New Password: <---- ここは「RANDOM」と入力してください Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt <Not found>, Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- ここは「RANDOM」と入力してください Verifying password New Password: <---- ここは「RANDOM」と入力してください Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します サーバファイルの作成 次に、各マシンにおけるサービスを定義している、 すべてのインスタンスを展開します。 これには ext_srvtab というコマンドを使用します。 このコマンドで作成されるファイルは、Kerberos の各クライアントの /etc ディレクトリに安全な方法で コピーまたは移動する必要があります。 このファイルはそれぞれのサーバとクライアントに存在しなければならず、 また Kerberos の運用において重要なものです。 &prompt.root; ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... このコマンドは一時的なファイルを作成するだけです。 ファイル名をすべ てのサーバが読めるような srvtab という名前に変更しな ければなりません。 &man.mv.1; コマンドを用いてシステムの場所に移動してください。 &prompt.root; mv grunt-new-srvtab srvtab そのファイルがクライアントに配るためのもので、 ネットワークが安全で はないと思われる場合には、 client-new-srvtab を移動 可能なメディアにコピーして物理的に安全な方法で運んでください。 クラ イアントの/etcディレクトリで、 名前を srvtabに変更し、 modeを600にするのを忘れないでください。 &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab データベースへのユーザの追加 ここで、 ユーザのエントリをデータベースに追加する必要があります。 始めに、 ユーザjaneのエントリを作成してみましょう。 kdb_edit を用いて次のように作成してください。 &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: <Not found>, Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- 安全なパスワードを入れてください Verifying password New Password: <---- もう一度パスワードを入れてください Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します すべてのテスト まず始めにKerberosデーモンを起動する必要があります。 /etc/rc.conf ファイルを正しく編集してあれば、マシンを再 起動することでに自動的にデーモンが起動します。 これはKerberosサー バでのみ必要です。 Kerberosクライアントは/etc/kerberosIVか ら必要なものを自動的に入手します。 &prompt.root; kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: EXAMPLE.COM &prompt.root; kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! さあ、これで上で作成した jane という ID のチケットを kinitコマンドで得ることができます。 &prompt.user; kinit jane MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane" Password: klist コマンドを用いてトークンを見て、 きちんとチケットを持って いるかどうか確認してください。 &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jane@EXAMPLE.COM Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM &man.passwd.1; コマンドを用いてパスワードを変更して、 kpasswd デーモンが Kerberos データベースに対して認証されるかどうかチェックして ください。 &prompt.user; passwd realm EXAMPLE.COM Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. <command>su</command> 特権の追加 Kerberos は root 権限が必要な 各 ユーザに対し、 &man.su.1; のパスワードをユーザ毎に 別のもの として持つことを可能にします。 root に &man.su.1; できる権利を与えられた ID を追加します。これは、 principal に付いている root というインスタンスに よって制御されています。 kdb_editを用いて jane.rootというエントリを Kerberos データベースに作成します。 &prompt.root; kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root <Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- 安全なパスワードを入れます Verifying password New Password: <---- もう一回パスワードを入れます Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- ここは短くしてください Attributes [ 0 ] ? Edit O.K. Principal name: <---- 何も入力しないと終了します 実際にトークンをもらって、 ちゃんと働いているかどうか確認しましょう。 &prompt.root; kinit jane.root MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane.root" Password: ここで root ユーザの .klogin ファイルにユーザを追加する必要があります。 &prompt.root; cat /root/.klogin jane.root@EXAMPLE.COM &man.su.1; してみましょう。 &prompt.user; su Password: どのトークンを持っているか見てみましょう。 &prompt.root; klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@EXAMPLE.COM Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM 他のコマンドの使用 ここまでの例では、jane という principal を root とい うインスタンス付きで作成しました。 これはユーザと同じ名前をprincipalと しており、 Kerberosのデフォルトの値です; <username>.root という形式の <principal>.<instance>で、 必要なエントリが root のホームディレクトリの .klogin ファイルにあれば、 <username> が root に &man.su.1; できます。 &prompt.root; cat /root/.klogin jane.root@EXAMPLE.COM 同様に、ユーザのホームディレクトリの .kloginファイルに次の ような行がある場合には &prompt.user; cat ~/.klogin jane@EXAMPLE.COM jack@EXAMPLE.COM jane または jack という名前で (前述のkinit によって) 認証されている EXAMPLE.COM という管理領域のユーザ なら誰でも &man.rlogin.1; や &man.rsh.1;, &man.rcp.1; 等によってこのシステム (grunt) のjaneのアカウントまたはファ イルにアクセスできます。 たとえば、jane が他のシステムに Kerberos を用いて login します。 &prompt.user; kinit MIT Project Athena (grunt.example.com) Password: &prompt.user; rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 次の例では、jack が同じマシンの jane のアカウントに login します (jane は .klogin ファイルを前述のように設定しており、 Kerberos では jack という principal をインスタンスなしで設定してあります)。 &prompt.user; kinit &prompt.user; rlogin grunt -l jane MIT Project Athena (grunt.example.com) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 <application>Kerberos5</application> Tillman Hodgson 寄稿: Mark Murray 基にした文書の執筆: &os;-5.1 リリース以降のすべての &os; には、 Kerberos5 のみが含まれています。 Kerberos5 はインストールされている唯一のバージョンであり、設定は、多くの側面で KerberosIV と似ています。 以下の情報は、&os;-5.0 リリース以降の Kerberos5 のみに適応が可能です。 KerberosIV package を使いたいと考えているユーザは、 security/krb4 port をインストールしてください。 Kerberos は、 サーバのサービスによってユーザが安全に認証を受けられるようにするための、 ネットワークの付加システムおよびプロトコルです。 リモートログイン、リモートコピー、 システム間でのファイルのコピーおよび他のリスクの高いタスクをかなり安全に、 そしてこれまでより制御できるようになります。 Kerberos は、 身元確認プロキシシステムや、 信頼される第 3 者認証システムとも説明されます。 Kerberos は、一つの機能 — ネットワーク上のユーザの安全な認証 — だけを提供します。 承認 (どのユーザが許可されているか) や監査 (ユーザがどのような作業を行っているか) の機能は提供しません。 Kerberos を使って、 クライアントおよびサーバの身元を証明した後は、 日常業務におけるすべての通信を暗号化して、 プライバシおよびデータの完全性を保証することができます。 そのため、Kerberos を使う際は、 承認および監査サービスを提供する他のセキュリティの手段との利用が、 強く推奨されます。 以下の文章は、&os; 用として配布されている Kerberos をセットアップする際のガイドとして利用できますが、 完全な説明が必要な場合には、 マニュアルページを参照してください。 この節における Kerberos のインストールのデモでは、以下のような名前空間が使われます。 DNS ドメイン (ゾーン) は、 example.org です。 Kerberos の領域は、 EXAMPLE.ORG です。 Kerberos の設定では、 内部での使用でも実際のドメイン名を使ってください。 DNS の問題を避けることができ、 他の Kerberos のレルム (realm) との相互運用を保証します。 歴史 Kerberos5 歴史 Kerberos は、 ネットワークのセキュリティ問題を解決するために、 MIT で開発されました。 Kerberos プロトコルは、 必ずしも安全ではないインターネット接続においても、 サーバに対して (逆もまた同様に)、 強い暗号を使って身元を証明します。 Kerberos は、 ネットワーク認証プロトコルの名前であり、 このプログラムを実装しているプログラムを表す (例 Kerberos telnet) ための形容詞でもあります。 プロトコルの現在のバージョンはバージョン 5 で、 RFC 1510 として文書化されています。 このプロトコルのいくつものフリーの実装が、 さまざまなオペレーティングシステムで利用できます。 最初の Kerberos を開発したマサチューセッツ工科大学 (MIT) は、 開発した Kerberos パッケージを継続的に保守しています。 アメリカ合衆国では暗号製品として良く使われていますが、 歴史的には、 アメリカ合衆国 の輸出規制により制限されてきました。 MIT で実装された Kerberos は、port (security/krb5) から利用できます。 バージョン 5 のもう一つの実装が、 Heimdal Kerberos です。 この実装は、アメリカ合衆国の外で開発されたため、 輸出の制限を避けることができます (そのため、非商用の &unix;-like なシステムによく含まれています)。 Heimdal Kerberos は port (security/heimdal) からインストールできますが、最小構成は &os; の base インストールに含まれています。 幅広い読者を対象とするために、以下の説明では &os; に含まれている Heimdal ディストリビューションの使用を想定しています。 Heimdal <acronym>KDC</acronym> の設定 Kerberos5 鍵配布センター 鍵配布センター (KDC) は、 Kerberos が提供する中心的な認証サービス — Kerberos チケットを発行するコンピュータです。 KDC は、 Kerberos のレルムの中のすべてのコンピュータから 信頼されています。 そのため、厳重なセキュリティに対する配慮が必要となります。 Kerberos サーバの実行にコンピュータのリソースは必要ありませんが、 セキュリティの観点から、KDC としてのみ機能する専用のコンピュータが推奨されます。 KDC を設定するにあたって、 KDC として動作するために、 適切に /etc/rc.conf が設定されていること (システムを反映するようにパスを調整する必要があります) を確認してください。 kerberos5_server_enable="YES" kadmind5_server_enable="YES" 次に、Kerberos の設定ファイル /etc/krb5.conf を編集します。 [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG /etc/krb5.conf ファイルの中では、 KDC は、 完全修飾されたホスト名 kerberos.example.org を持つことが想定されていることに注意してください。 KDC が異なるホスト名である場合には、 名前の解決が行われるように、適切に CNAME (エイリアス) エントリをゾーンファイルに追加する必要があります。 適切に BIND DNS サーバが設定されたネットワークでは、 上記の例は、以下のように整理されます。 [libdefaults] default_realm = EXAMPLE.ORG そして、kerberos.EXAMPLE.ORG ゾーンファイルには、以下の行が付け加えられます。 _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG クライアントが、 Kerberos サービスを見つけるためには、 /etc/krb5.conf を完全に設定するか、 /etc/krb5.conf を最低限に設定し、 さらに DNS サーバを適切に設定する 必要 があります。 次に Kerberos データベースを作成します。 このデータベースには、 マスター鍵により暗号化されたすべてのプリンシパルの鍵があります。 このパスワードは、ファイル (/var/heimdal/m-key) に保存されるため、 覚える必要はありません。 マスター鍵を作成するには、kstash を実行して、 パスワードを入力してください。 マスター鍵を作成したら、kadmin プログラムを -l オプション (local を意味します) で実行し、初期化します。 このオプションを使うと、kadmin は、 kadmind ネットワークサービスを使わず、 直接データベースファイルを変更します。 これにより、 データベースを作成する前に、データベースへの接続を試みてしまうという、 卵が先か鶏が先かという問題を回避できます。 kadmin プロンプトが表示されたら、init コマンドを使って、 レルムに関する初期のデータベースを作成してください。 最後に、kadmin プロンプトで add コマンドを使って最初のプリンシパルを作成して下さい。 差し当たりは、 プリンシパルに対するデフォルトのオプションに従ってください。 後で modify コマンドを使うことで、 いつでも変更することができます。 プロンプトで ? コマンドを使うと、 利用可能なオプションを確認できます。 データベース作成のセッションの例は以下のようになります。 &prompt.root; kstash Master key: xxxxxxxx Verifying password - Master key: xxxxxxxx &prompt.root; kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx これで KDC サービスを起動することができるようになりました。 /etc/rc.d/kerberos start および /etc/rc.d/kadmind start を実行してサービスを起動してください。 この時点で、kerberos 化されたデーモンが走っていなくても、 KDC のコマンドラインから、作成したばかりの (ユーザ) プリンシパルのチケットを入手したり、 一覧を表示することができることを確認してください。 &prompt.user; kinit tillman tillman@EXAMPLE.ORG's Password: &prompt.user; klist Credentials cache: FILE:/tmp/krb5cc_500 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG 必要がなくなった時には、チケットを破棄できます。 &prompt.user; k5destroy Heimdal <application>Kerberos</application> サービスを有効にする。 Kerberos5 Enabling サービス 最初に Kerberos の設定ファイル /etc/krb5.conf のコピーが必要です。 コピーを行うには、KDC から、 クライアントコンピュータへ (&man.scp.1; のようなネットワークユーティリティを使うか、 物理的にフロッピーディスクを使って) 安全な方法でコピーをしてください。 次に /etc/krb5.keytab ファイルが必要となります。 これは、Kerberos 化されたデーモンを提供するサーバとワークステーションの間での大きな違いです — サーバは、 keytab ファイルを持っている必要があります。 このファイルには、サーバのホスト鍵が含まれています。 この鍵により、ホストおよび KDC が他の身元の検証ができます。 鍵が公開されてしまうと、 サーバのセキュリティが破れてしまうため、 このファイルは安全にサーバに転送しなければなりません。 このことは、FTP のようにテキストチャネルでの転送は、 まったく好ましくないことを意味しています。 一般的には、kadmin プログラムを使って、 keytab をサーバに転送します。 kadmin を使って (KDC 側の krb5.keytab に) ホストプリンシパルを作成することも必要なので便利です。 すでにチケットを入手し、 そのチケットは、 kadmin インタフェースで使用できることが kadmind.acl で許可されている必要があります。 アクセスコントロールリストの設計の詳細については、 Heimdal info ページ (info heimdal) の Remote administration というタイトルの章をご覧ください。 リモートからの kadmin アクセスを有効にしたくない場合は、 安全に (ローカルコンソール、&man.ssh.1; もしくは Kerberos &man.telnet.1; を用いて) KDC に接続し、 kadmin -l を使用して、 ローカルで管理作業を行ってください。 /etc/krb5.conf ファイルをインストールしたら、 Kerberos サーバから、 kadmin を使うことができます。 add --random-key コマンドを使うと、 サーバのホストプリンシパルを追加できます。 そして、ext コマンドを用いて、 サーバのホストプリンシパルを keytab に抽出してください。 &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/myserver.example.org kadmin> exit ext コマンド (extract の省略形) は、デフォルトでは、抽出された鍵を /etc/krb5.keytab に保存します。 KDC 上で kadmind を (おそらくセキュリティ上の理由から) 走らせていない場合で、 リモートから kadmin に接続出来ない場合には、 ホストプリンシパル (host/myserver.EXAMPLE.ORG) を直接 KDC 上で追加し、 その後、以下のように (KDC 上の /etc/krb5.keytab の上書きを避けるため)、 一時ファイルに抽出してください。 &prompt.root; kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit その後、keytab を安全に (たとえば scp またはフロッピーを使って) サーバコンピュータにコピーしてください。 KDC 上の keytab を上書きすることを避けるため、 デフォルトとは異なる名前を指定してください。 これでサーバは、 (krb5.conf ファイルにより) KDC と通信ができるようになりました。 そして、(krb5.keytab ファイルによって) 身元を証明できるようになったので、 Kerberos サービスを有効にする準備が出来ました。 この例では、以下の行を /etc/inetd.conf に加え、 telnet サービスを有効にしてください。その後、 /etc/rc.d/inetd restart にて &man.inetd.8; サービスを再起動します。 telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user 重要な箇所は、ユーザに -a (認証を表す) が設定されていることです。 詳細については、 &man.telnetd.8; マニュアルページを参照してください。 Heimdal <application>Kerberos</application> クライアントを有効にする Kerberos5 クライアントの設定 クライアントコンピュータの設定は、 ほとんど取るに足らないくらいに簡単です。 Kerberos の設定がうまくいっていれば、 /etc/krb5.conf に置かれている Kerberos の設定ファイルのみが必要です。 セキュリティ的に安全な方法で、KDC からクライアントコンピュータへ単にコピーしてください。 クライアントから、kinit, klist および kdestroy を使用し、 上記で作成したプリンシパルに対するチケットの入手、表示、 削除を行い、クライアントコンピュータを試験してください。 Kerberos アプリケーションを使って Kerberos が有効なサーバに接続することもできるはずです。 もしうまく機能しない場合でも、チケットを入手できるのであれば、 問題はおそらくサーバにあり、 クライアントまたは KDC の問題ではないと考えられます。 telnet のようなアプリケーションを試験する際には、 (&man.tcpdump.1; といった) パケットスニファを使用して、 パスワードが平文で送られていないことを確認してください。 -x オプションで telnet を利用すると、 (ssh のように) すべてのデータストリームが暗号化されます。 デフォルトでは、Heimdal インストールの 最小 と考えられる、コア以外の Kerberos クライアントアプリケーションもインストールされます。 telnet は、 Kerberos 化された唯一のサービスです。 Heimdal port は、 Kerberos 化されている ftp, rsh, rcp, rlogin および他のあまり一般的ではないプログラムといった、 インストールされていないクライアントアプリケーションをインストールします。 MIT port も、すべての Kerberos クライアントアプリケーションをインストールします。 ユーザ設定ファイル: <filename>.k5login</filename> および <filename>.k5users</filename> .k5login .k5users レルムのユーザは、一般的には、 (tillman のような) ローカルユーザアカウントに対応する (tillman@EXAMPLE.ORG といった) Kerberos プリンシパルを持ちます。 telnet のようなクライアントアプリケーションは、 ユーザ名もしくはプリンシパルを通常必要としません。 しかしながら、時々 Kerberos プリンシパルに対応しないローカルユーザアカウントへのアクセスが必要となることがあります。 たとえば、 tillman@EXAMPLE.ORG が、ローカルユーザアカウント webdevelopers へのアクセスが必要となることがあります。 そして、他のプリンシパルが同じローカルアカウントにアクセスが必要になることもあります。 ユーザのホームディレクトリに置かれた .k5login および .k5users ファイルによって (.hosts および .rhosts の強力な組み合わせのように)、この問題を解決出来ます。 たとえば、以下の行を含む .k5login を tillman@example.org jdoe@example.org ローカルユーザ webdevelopers のホームディレクトリに置くと、 一覧にある両方のプリンシパルは、 共有のパスワードを必要としなくても、 このアカウントにアクセス出来ます。 これらのコマンドのマニュアルページを読むことが推奨されます。 ksu マニュアルページには、 .k5users の説明があります。 <application>Kerberos</application> Tips, Tricks, およびトラブルシューティング Kerberos5 トラブルシューティング Heimdal または MIT Kerberos ports のどちらを使う場合でも、 PATH 環境変数は、 Kerberos 版のクライアント アプリケーションが、 システムにあるアプリケーションより先に見つかるように設定されていることを確認してください。 レルムにあるすべてのコンピュータの間で時刻が同期していますか？ 時刻が同期していないと認証に失敗してしまいます。 NTP を用いた、時刻の同期方法については、 をご覧ください。 MIT および Heimdal 間の運用は、 標準化されていないプロトコル kadmin を除き、 うまく機能します。 ホスト名を変更する際は、 host/ プリンシパルを変更し、keytab をアップデートする必要があります。 Apache の www/mod_auth_kerb で使われる www/ プリンシパルのような特別な keytab エントリでも必要となります。 レルムの中のすべてのホストは、DNS において (もしくは、最低限/etc/hosts の中で)、(正引きおよび逆引き両方で) 名前解決できる必要があります。 CNAME は動作しますが、A および PTR レコードは、 正しく適切な位置に記述されている必要があります。 エラーメッセージは、 次の例のように、直感的に原因が分かるようなものではありません。 Kerberos5 refuses authentication because Read req failed: Key table entry not found. KDC に対しクライアントとして振る舞うオペレーティングシステムの中には、 ksu に対して、 root 権限に setuid を許可しないものがあります。 この設定では、 ksu は動作しないことを意味します。 セキュリティの観点からは好ましい考えですが、 厄介です。これは KDC のエラーではありません。 MIT Kerberos において、 プリンシパルが、デフォルトの 10 時間を超えるチケットの有効期限としたい場合には、 kadmin で modify_principal を使って、 対象のプリンシパルおよび krbtgt プリンシパル両方の有効期限の最大値を変更してください。 プリンシパルは、 kinit で -l オプションを使用して、 長い有効期限のチケットを要求できます。 トラブルシューティングのために、 KDC でパケットスニファを走らせ、 そして、ワークステーションから kinit を実行すると、 kinit を実行するやいなや、 TGT が送られてきます。 — あなたがパスワードを入力し終わる前でも! これに関する説明は、以下の通りです。 Kerberos サーバは、 いかなる未承認のリクエストに対して、 自由に TGT (Ticket Granting Ticket) を送信します。しかしながら、すべての TGT は、 ユーザのパスワードから生成された鍵により、暗号化されています。 そのため、ユーザがパスワードを入力した時には、 パスワードは KDC には送られません。 このパスワードは、kinit がすでに入手した TGT の復号化に使われます。 もし、復号化の結果、 有効なチケットで有効なタイムスタンプの場合には、 ユーザは、有効な Kerberos クレデンシャルを持ちます。 このクレデンシャルには、 Kerberos サーバ自身の鍵により暗号化された実際の ticket-granting ticket とともに、将来 Kerberos サーバと安全な通信を確立するためのセッション鍵が含まれています。 この暗号の 2 番目のレイヤは、ユーザには知らされませんが、 Kerberos サーバが、 各 TGT の真偽の検証を可能にしている部分です。 (たとえば一週間といった) 長い有効期限のチケットを使いたい場合で、 OpenSSH を使って、 チケットが保存されているコンピュータに接続しようとする場合は、 Kerberos が sshd_config において no と設定されているか、 チケットが、ログアウト時に削除されることを確認してください。 ホストプリンシパルも長い有効期限のチケットを持てることを覚えておいてください。 もし、ユーザプリンシパルが 1 週間の有効期限を持ち、 接続しているホストが、9 時間の有効期限を持っている場合には、 キャッシュのホストプリンシパル (の鍵) の有効期限が切れてしまい、 想定したように、チケットキャッシュが振る舞わないことが起こりえます。 特定の問題のあるパスワードが使われることを避けるために (kadmind のマニュアルページでは、 この点について簡単に触れています)、 krb5.dict ファイルを設定する時には、 パスワードポリシが割り当てられたプリンシパルにのみ適用されることに注意してください。 krb5.dict ファイルの形式は簡単です。 : 一行に一つの文字列が置かれています。 /usr/share/dict/words にシンボリックリンクを作成することは、有効です。 <acronym>MIT</acronym> port との違いについて MIT とインストールされている Heimdal 版の大きな違いは、 kadmin に関連しています。 このプログラムは、異なる (ただし等価な) コマンド群を持ち、そして、 異なるプロトコルを使用します。 もし KDC に MIT を使用している場合には、 Heimdal kadmin プログラムを使って KDC をリモートから (この場合は、逆も同様に) 管理できない ことを意味しています。 クライアントアプリケーションでは、同じタスクを行う際に、 若干異なるコマンドラインのオプションが必要となることもあります。 MIT Kerberos ウェブサイト () に書かれているガイドに従うことが推奨されます。 path の問題について注意してください。 MIT port はデフォルトで /usr/local/ にインストールします。 そのため、もし PATH 環境変数においてシステムのディレクトが最初に書かれている場合には、 MIT 版ではなく、 通常の システムアプリケーションが動いてしまいます。 &os; が提供する MIT security/krb5 port において、 telnetd および klogind 経由でのログインが奇妙な振る舞いをすることを理解したいのであれば、 port からインストールされる /usr/local/share/doc/krb5/README.FreeBSD ファイルを読んで下さい。 最も重要なことは、 incorrect permissions on cache file の振る舞いを修正するには、 フォワードされたクレデンシャリングの所有権を適切に変更できるように、 login.krb5 バイナリが認証に使われる必要があります。 rc.conf を以下の設定を含むように変更する必要があります。 kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_enable="YES" kadmind5_server_enable="YES" これを行うのは、 MIT kerberos のアプリケーションは、 /usr/local 構造の下にインストールされるためです。 <application>Kerberos</application> で見つかった制限を緩和する Kerberos5 制限および欠点 <application>Kerberos</application> は、all-or-nothing アプローチです。 ネットワーク上で有効なすべてのサービスは、 Kerberos 化 (または、ネットワーク攻撃に対して安全に) されるべきです。 さもないと、ユーザのクレデンシャルが盗まれ、 利用されることが起きるかもしれません。 この例は、 Kerberos 化されたすべてのリモートシェル (たとえば、rsh および telnet) です。 パスワードを平文で送るような POP3 メールサーバは変換していません。 <application>Kerberos</application> は、 シングルユーザのワークステーションでの使用を想定しています。 マルチユーザの環境では、 Kerberos は安全ではありません。 チケットは /tmp ディレクトリに保管され、 このチケットは、すべてのユーザが読むことができるためです。 もし、ユーザがコンピュータを他のユーザと同時に共有 (i.e. マルチユーザで使用) していると、 他のユーザは、そのユーザのチケットを盗む (コピーする) ことが出来てしまいます。 この問題は、-c ファイル名コマンドラインオプションまたは、(好ましくは) KRB5CCNAME 環境変数によって克服されますが、 実際に使われることはまれです。 大体においては、チケットをユーザのホームディレクトリに保存し、 簡単なファイルの許可属性を設定することで、 この問題に対応できます。 KDC は、単一障害点である 設計上、KDC は、 マスターパスワードのデータベースを含むため、 安全である必要があります。 KDC では、 絶対に他のサービスを走らせるべきではありませんし、 物理的に安全であるべきです。 Kerberos は、 KDC 上で、ファイルとして保存されている一つの鍵 (マスター 鍵) で暗号化されたすべてのパスワードを保存しているので、 非常に危険です。 追記ですが、マスター鍵が漏洩しても、 通常懸念するほど悪いことにはなりません。 マスター鍵は、Kerberos データベースの暗号時にのみ、 乱数を生成するためのシードとして使われます。 KDC へのアクセスが安全である限りにおいては、 マスター鍵を用いて、それほど多くのことはできません。 さらに、KDC が (DoS 攻撃またはネットワーク問題等により) ネットワークサービスを利用できず、 認証ができない場合に対する、DoS 攻撃への対応方法があります。 この攻撃による被害は、 複数の KDC (ひとつのマスタとひとつまたはそれ以上のスレーブ) および、セカンダリもしくはフォールバック認証 (これには、PAM が優れています) の実装により軽減することができます。 <application>Kerberos</application> の欠点 Kerberos は、 ユーザ、ホストおよびサービスの間での認証を可能にしますが、 KDC とユーザ、 ホストまたはサービスとの間の認証のメカニズムは提供しません。 これは、(たとえば) トロイの木馬の kinit が、 すべてのユーザ名とパスワードを記録できることを意味しています。 security/tripwire のような、 もしくは他のファイルシステムの完全性を確認するためのツールにより、 この危険性を軽減することができます。 リソースおよび他の情報源 Kerberos5 External Resources The Kerberos FAQ Designing an Authentication System: a Dialog in Four Scenes RFC 1510, The Kerberos Network Authentication Service (V5) MIT Kerberos home page Heimdal Kerberos home page OpenSSL Tom Rhodes 執筆: セキュリティ OpenSSL 多くのユーザが見落としがちな機能の一つが、 &os; に含まれている OpenSSL ツールキットです。 OpenSSL は、 通常の通信層の上位にあるトランスポート層を暗号化し、 多くのネットワークアプリケーションおよびサービスと組み合わせて使用できます。 OpenSSL は、 メールクライアントの暗号化された認証、 クレジットカードでの支払いといったウェブベースの取引などで使われます。 www/apache13-ssl および mail/sylpheed-claws といった多くの port では、 OpenSSL とともに構築するコンパイルに対応しています。 多くの場合、Ports Collection は、 make の WITH_OPENSSL_BASE 変数が明示的に yes に設定されていないと、 security/openssl port の構築を試みます。 &os; に含まれている OpenSSL 　のバージョンは、Secure Sockets Layer v2/v3 (SSLv2/SSLv3) や Transport Layer Security v1 (TLSv1) ネットワークセキュリティプロトコルに対応しており、 多目的な暗号化ライブラリとして使うことができます。 OpenSSL は、 IDEA アルゴリズムに対応していますが、 合衆国の特許により、デフォルトでは無効になっています。 もし使用したいのであれば、ライセンス条項を必ず確認し、 ライセンス条項に合致するのであれば、 MAKE_IDEA 変数を設定してください。 最も一般的な OpenSSL の利用方法のひとつは、 ソフトウェアアプリケーションが使えるように証明書を提供することです。 これらの証明書により、 会社または個人の公開鍵が、 改ざんやなりすましが行われていないことを確認できます。 もし問題となっている証明書が、認証局 または CA により検証されなければ、 通常警告が表示されます。 認証局は、VeriSign のような会社で、個人または会社の公開鍵の検証を行えるように、 証明書に署名を行います。 証明書を作成するには費用がかかり、 証明書の使用は必ずしも必要条件ではありません。 しかしながら、証明書を使うことで、 疑り深いユーザを安心させることができます。 証明書の作成 OpenSSL 証明書の作成 以下のコマンドにより、証明書を作成できます。 &prompt.root; openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................++++++ .......................................++++++ writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (eg, YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:SOME PASSWORD An optional company name []:Another Name Common Name プロンプト直後に表示されているのは、 ドメイン名です。 このプロンプトでは、検証するサーバ名の入力が必要となります。 ドメイン名以外を入力すると、役に立たない証明書が作成されます。 他には、有効期限を指定したり、 別の暗号化アルゴリズムを選択することができます。 オプションの完全なリストは、 &man.openssl.1; マニュアルページで確認できます。 前述のコマンドを実行したディレクトリには、 2 つのファイルが作成されているはずです。 1 つは、証明書要求 req.pem です。 このファイルを認証局に送ると、 認証局は含まれている内容を検証し、 検証に成功すると、証明書要求に署名を行い、 作成された証明書を送り返します。 もうひとつ、cert.pem と呼ばれるファイルが生成されます。 これは証明書の秘密鍵であり、 どのようなことがあっても保護しなくてはなりません。 もし、他の人の手に渡ると、手に入れた人は、 あなた (もしくはあなたのサーバ) になりすますことができてしまいます。 CA の署名が必要ない場合には、 自己署名証明書を作成できます。 最初に RSA の鍵を生成してください。 &prompt.root; openssl dsaparam -rand -genkey -out myRSA.key 1024 次に、CA 鍵を生成してください。 &prompt.root; openssl gendsa -des3 -out myca.key myRSA.key この鍵を使って証明書を作成してください。 &prompt.root; openssl req -new -x509 -days 365 -key myca.key -out new.crt 新しく 2 つのファイルがこのディレクトリに作成されます。 プライベート鍵 myca.key および 証明書 new.crt です。 これらのファイルを、(好ましくは /etc 以下で) root のみが読むことのできるディレクトリに置く必要があります。 chmod ユーティリティを使って許可属性を 0700 に設定してください。 証明書の使用例 これらのファイルで何ができるでしょうか? 効果的な利用方法は、 Sendmail MTA への接続を暗号化することでしょう。 これにより、 ローカルの MTA 経由でメールを送信するユーザが、 テキスト認証を使用しなくてもすむようになります。 いくつかの MUA は、 証明書がローカルにインストールされていない場合に、 ユーザに対して、エラーを出力するので、 完全に最善の利用方法というわけではありません。 証明書のインストールに関する詳細な情報については、 ソフトウェアに付随の文書を参照してください。 以下の行をローカルの .mc ファイルに入れてください。 dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/new.crt')dnl define(`confSERVER_CERT',`/etc/certs/new.crt')dnl define(`confSERVER_KEY',`/etc/certs/myca.key')dnl define(`confTLS_SRV_OPTIONS', `V')dnl ここで /etc/certs/ は、証明書および鍵ファイルが保存されているローカルのディレクトリです。 最後に、ローカルの .cf ファイルを再構築する必要があります。 /etc/mail ディレクトリで、 - make install + make install と入力すると再構築できます。 - その後、make - restart と入力して、 + その後、make restart + と入力して、 Sendmail デーモンを再起動してください。 すべてがうまくいっていれば、 /var/log/maillog ファイルにはエラーメッセージは出力されず、 Sendmail がプロセスの一覧に表示されます。 以下は簡単な試験の例で、&man.telnet.1; ユーティリティを使って、 メールサーバに接続しています。 &prompt.root; telnet example.com 25 Trying 192.0.34.166... Connected to example.com Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host. すべてが適切に動いていれば、出力に STARTTLS 行が表示されます。 VPN over IPsec Nik Clayton
nik@FreeBSD.org
 執筆: IPsec この章では、FreeBSD ゲートウェイを使って、 インターネットによって分けられた、二つのネットワーク間に VPN を作成します。 IPsec を理解する Hiten M. Pandya
hmp@FreeBSD.org
 執筆: この節では、FreeBSD と µsoft.windows; 2000/XP からなる環境において、IPsec を設定し、利用する過程を通じて、 IPsec を使った安全な通信の実現方法について解説します。 IPsec を設定するためには、 カスタムカーネルの構築方法をよく知っている必要があります ( をご覧ください)。 IPsec は、インターネットプロトコル (IP) レイヤのトップにあるプロトコルです。 二つもしくはそれ以上のホスト間で安全に通信することを可能にします (そのため、名前に sec が含まれています)。 FreeBSD の IPsec ネットワークスタック は、 IPv4 および IPv6 の両方のプロトコルファミリに対応している KAME 実装をベースとしています。 FreeBSD には hardware accelerated IPsec スタックが含まれています。 これは、Fast IPsec として知られているもので、 OpenBSD から移植されました。 IPsec のパフォーマンスを最適化するために、(利用できる場合には) &man.crypto.4; サブシステムを経由して、 暗号ハードウェアを使用します。 このサブシステムは新しいので、まだ IPsec の KAME 版で利用可能な機能のすべてに対応しているわけではありません。 しかしながら、hardware-accelerated IPsec を有効にするためには、 カーネルコンフィグレーションファイルに以下のカーネルオプションを追加する必要があります。 カーネルオプション FAST_IPSEC options FAST_IPSEC # new IPsec (cannot define w/ IPSEC) 現在の時点では、Fast IPsec サブシステムを IPsec の KAME 実装のかわりに使うことはできません。 より多くの情報については、&man.fast.ipsec.4; を参照してください。 ファイアウォールが適切に &man.gif.4; も追跡できるようにするには、 カーネルコンフィグレーションにおいて、 を有効にする必要があります。 options IPSEC_FILTERGIF #filter ipsec packets from a tunnel IPsec ESP IPsec AH IPsec は二つのサブプロトコルから構成されます。 Encapsulated Security Payload (ESP) は、(Blowfish, 3DES のような) 対称暗号アルゴリズムを使ってデータを暗号化することで、 サードパーティのインタフェースから IP パケットデータを保護します。 Authentication Header (AH), は、暗号チェックサムを計算し、IP パケットのヘッドフィールドを安全なハッシュ関数でハッシュ化することで、 IP パケットヘッダをサードパーティのインタフェースやなりすましから守ります。 ハッシュを含む追加のヘッダが追加され、 パケット情報の検証が可能になります。 ESP および AH は、使用する環境に合わせて、 一緒に使うことも別々に使うこともできます。 VPN virtual private network VPN IPsec は、直接二つのホスト間のトラフィックを暗号化する Transport Mode、もしくは、 2 つの共同するネットワーク間で安全に通信することを可能にするように、 2 つのサブネット間に virtual tunnels を構築する Tunnel Mode のどちらでも用いることができます。 後者はより一般的には、 Virtual Private Network (VPN) として知られています。 FreeBSD での IPsec サブシステムに関するより詳細な情報については、 &man.ipsec.4; マニュアルページを参照してください。 カーネルに IPsec のサポートを追加するには、 カーネルコンフィグレーションファイルに以下のオプションを追加してください。 カーネルオプション IPSEC カーネルオプション IPSEC_ESP options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) カーネルオプション IPSEC_DEBUG IPsec のデバッグサポートが必要であれば、 以下のカーネルオプションを追加してください。 options IPSEC_DEBUG #debug for IP security 問題点 VPN の構成についての標準はありません。 VPN は、数多くの技術と共に実装することが可能です。 その各技術には、それ自身の長所と短所があります。 この章では、シナリオを示し、 そのシナリオに対して、VPN を実装する戦略について説明します。 シナリオ: インターネットに接続している 2 つのネットワークが 1 つのネットワークとして振る舞う VPN creating 前提は以下の通りです。 少なくとも 2 つのサイトを持っています。 どちらの際とも内部で IP を使っています。 2 つのサイトは、FreeBSD で運用されているゲートウェイを通して、 インターネットに接続しています。 それぞれのネットワークのゲートウェイは、 少なくとも一つのパブリック IP アドレスを持っています。 2 つのネットワークの内部アドレスは、 パブリックでもプライベート IP アドレスでも構いません。 必要であれば、ゲートウェイコンピュータで NAT を走らせることもできます。 2 つのネットワークの内部 IP アドレスは、 衝突してはいけません。 VPN 技術と NAT を用いることで、理論的には、 そのようなことは可能と考えますが、 その設定は悪夢でしょう。 2 つのネットワークに接続を試みた際に、 両方のネットワークで同じ範囲の内部 IP アドレスが使われていることに気づいたら (たとえば、両方で 192.168.1.x を使用している場合)、 どちらかの番号を振りなおす必要があります。 VPN の文書では、同じ ASCII アートを使うことがルールになっているので、 この文書でも例外ではなく同様にアスキーアートを用います。 ネットワークのトポロジは以下のようになります。 Network #1 [ Internal Hosts ] Private Net, 192.168.1.2-254 [ Win9x/NT/2K ] [ UNIX ] | | .---[fxp1]---. Private IP, 192.168.1.1 | FreeBSD | `---[fxp0]---' Public IP, A.B.C.D | | -=-=- Internet -=-=- | | .---[fxp0]---. Public IP, W.X.Y.Z | FreeBSD | `---[fxp1]---' Private IP, 192.168.2.1 | | Network #2 [ Internal Hosts ] [ Win9x/NT/2K ] Private Net, 192.168.2.2-254 [ UNIX ] ふたつのパブリック IP アドレスに注目してください。 この文書では、これらの IP アドレスを参照する際には、 これらの文字を用います。 この文書の中で、これらの文字を見たら、 あなた自身のパブリック IP アドレスに置き換えてください。 内部では、2 つのゲートウェイコンピュータは、両方とも .1 IP アドレスを持っています。そして、2 つのネットワークは、 異なるプライベート IP アドレスを使っています (それぞれ 192.168.1.x および 192.168.2.x)。 プライベートネットワークにあるすべてのコンピュータは、 デフォルトゲートウェイとして、 .1 コンピュータを使うように設定されています。 意図していることは、ネットワークの観点から、 各ネットワークは他のネットワークにあるコンピュータを、 (時折パケットをドロップするようなややゆっくりなルータではありますが) 同じルータに直接接続しているようにすることです。 これは、たとえば、192.168.1.20 というコンピュータは、 以下を実行できるということです。 ping 192.168.2.34 透過的にこれは動くはずです。 &windows; コンピュータは、他のネットワークのコンピュータを、 ローカルネットワークのコンピュータを見るのとまったく同じように、 見ることができ、共有ファイルを見たりできます。 すべてのことが安全に行われなければなりません。 これは、2 つのネットワークの通信が暗号化されていなければならないことを意味しています。 これらの 2 つのネットワーク間に VPN を構築するには複数のプロセスが必要となります。 各ステージは以下のようになります。 2 つのネットワーク間にインターネットを経由して、 virtual ネットワークのリンクを作成します。 それが適切に動いていることを &man.ping.8; のようなツールを使って、試験を行います。 2 つのネットワーク間で、 必要に応じて透過的に暗号化、 復号化を保証するようにセキュリティポリシを適用します。 &man.tcpdump.1; のようなツールを使って、 通信が暗号化されていることを確認します。 FreeBSD ゲートウェイにて、&windows; のコンピュータが VPN を通して他のコンピュータを見ることができるように追加のソフトウェアを設定します。 ステップ 1: <quote>virtual</quote> ネットワークリンクの作成 ネットワーク #1 のゲートウェイコンピュータにログインしているとします。 このコンピュータのパブリック IP アドレスは A.B.C.D、 プライベート IP アドレスは 192.168.1.1 です。 W.X.Y.Z の IP アドレスのコンピュータのプライベートアドレスに対し ping 192.168.2.1 を実行したとします。 このコマンドが成功するには何が必要でしょうか？ ゲートウェイコンピュータは、どのように 192.168.2.1 に達するかを知っていなければなりません。 言い換えると、 192.168.2.1 への経路を知っている必要があります。 192.168.x のような範囲のプライベート IP アドレスは広いインターネットでは、 使われることは想定されていません。 そのかわり、 192.168.2.1 に送信した各パケットは、他のパケットに包れている必要があります。 このパケットは A.B.C.D から、 W.X.Y.Z へと送られる必要があります。 このプロセスは、 カプセル化 と呼ばれます。 このパケットが W.X.Y.Z に届くと、 非カプセル化 され、 192.168.2.1 に送信されます。 これは、2 つのネットワーク間で、 tunnel が必要ということを示しています。二つの トンネルマウス は、 IP アドレス A.B.C.D と W.X.Y.Z です。 そして、トンネルは、これをパススルーすることを許容するプライベート IP アドレスのアドレスが指定されている必要があります。 トンネルは、パブリックインターネットを経由して、 プライベート IP アドレスで送信する時に使われます。 このトンネルは、一般的なインタフェースもしくは、FreeBSD では gif デバイスで作成されます。 想像通り、各ゲートウェイホストの gif インタフェースは、4 つの IP アドレスで設定されなくてはなりません。 2 つはパブリック IP アドレスで、 2 つはプライベートの IP アドレスです。 両方の &os; カーネルで gif デバイスのサポートを組み入れてコンパイルする必要があります。 以下の行を加えることで設定できます。 device gif 両方のコンピュータのカーネルコンフィグレーションファイルに上記の行を加え、 コンパイル、インストールし、通常通り再起動してください。 トンネルの設定は 2 つのプロセスで行います。 最初は、&man.ifconfig.8; を使って、 外部 (パブリック) IP アドレスを設定するします。 その後、プライベート IP アドレスを &man.ifconfig.8; を使って設定します。 ネットワーク #1 にあるゲートウェイコンピュータで以下のコマンドを実行してトンネルを作成します。 &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 tunnel A.B.C.D W.X.Y.Z &prompt.root; ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff もう片方のゲートウェイコンピュータで、 IP アドレスの順を逆にして同じコマンドを実行します。 &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 tunnel W.X.Y.Z A.B.C.D &prompt.root; ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff 以下を実行して、設定を確認をしてください。 ifconfig gif0 たとえば、ネットワーク #1 のゲートウェイにおいては、 以下のように確認できます。 &prompt.root; ifconfig gif0 gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 tunnel inet A.B.C.D --> W.X.Y.Z inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff 出力からわかるように、 物理アドレス A.B.C.D と W.X.Y.Z の間にトンネルが作成され、 192.168.1.1 と 192.168.2.1 の間の通信がトンネルで許可されています。 両方のコンピュータのルーティングテーブルにエントリが追加されました。 netstat -rn で確認できます。 ネットワーク #1 のゲートウェイホストでの出力は以下のようになります。 &prompt.root; netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire ... 192.168.2.1 192.168.1.1 UH 0 0 gif0 ... Flags の値が示すように、 これはホストのルートで、 各ゲートウェイは他のゲートウェイとどのように通信すれば良いかを知っていますが、 他の関連するネットワークへの通信を知らないことを意味しています。 この問題は、すぐに解決されます。 両方のコンピュータでファイアウォールを設定していることがあります。 VPN トラフィックのためには、ファイアウォールを迂回する必要があります。 両方のネットワーク間のすべてのトラフィックを許可するか、VPN の末端をお互い保護するようなファイアウォールのルールを追加したいと思うでしょう。 すべての VPN を経由するトラフィックを許容するようなファイアウォールを設定すると、 テストを大きく簡略化できます。 後でいつでも、セキュリティを強化できます。 もし、ゲートウェイコンピュータで &man.ipfw.8; を用いているのであれば、 以下のようなコマンドで、 他のファイアウォールのルールに影響することなく、 VPN の末端の間のトラフィックを許可します。 ipfw add 1 allow ip from any to any via gif0 両方のゲートウェイコンピュータでこのコマンドを実行する必要があります。 各ゲートウェイコンピュータで他のゲートウェイコンピュータに対して、 ping を実行することができれば十分です。 192.168.1.1 において、以下を実行が可能で ping 192.168.2.1 そして、レスポンスを受け取れる必要があります。 同じことを他のゲートウェイコンピュータで実行できる必要があります。 しかしながら、各ネットワークの内部のコンピュータにアクセスはまだできません。 これは、 ゲートウェイコンピュータがお互いにアクセスする方法を知っているが、 各ゲートウェイの奥にあるネットワークにアクセスする方法を知らないという、 ルーティングに起因しています。 この問題を解決するには、 静的ルートを各ゲートウェイコンピュータに追加する必要があります。 このために最初のゲートウェイで行うコマンドは以下のようになります。 route add 192.168.2.0 192.168.2.1 netmask 0xffffff00 このコマンドの意味は、ネットワーク 192.168.2.0 のホストにアクセスするには、パケットを 192.168.2.1 のホストに送る ことを意味しています。 もう片方のゲートウェイでは、同様のコマンドを実行する必要があります。 その場合には、かわりに、 192.168.1.x アドレスを使う必要があります。 これで、片方のネットワーク上のホストからの IP トラフィックは、 もう片方のネットワーク上のホストに届くようになります。 2 つのネットワーク間の virtual および network について構築できたので、 VPN について、2/3 が構築されました。残りは private です。 &man.ping.8; および &man.tcpdump.1; を使って試験できます。 ゲートウェイホストにログインして以下を実行してください。 tcpdump dst host 192.168.2.1 同じホストの他のログインセッションで、 以下を実行してください。 ping 192.168.2.1 以下のような出力が表示されます。 16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply この出力からわかるように、ICMP メッセージが戻り、 復号化されます。 &man.tcpdump.1; に パラメータを用いると、 パケットから多くのデータを捕え、 より多くの情報を得ることができます。 明らかにこれは、受け入れられるものではありません。 次の節では、2 つのネットワーク間のリンクについて、 すべての通信が自動的に暗号化されるように安全にする方法について説明します。 まとめ 両方のカーネルを device gif で構築します。 ゲートウェイホスト #1 の /etc/rc.conf を編集して、以下の行を (必要に応じて IP アドレスを変更して) 追加します。 gif_interfaces="gif0" gifconfig_gif0="A.B.C.D W.X.Y.Z" ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff" static_routes="vpn" route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00" 両方のホストのファイアウォールスクリプト (/etc/rc.firewall など) を編集して以下を追加します。 ipfw add 1 allow ip from any to any via gif0 同様の変更を、ゲートウェイホスト #2 の /etc/rc.conf においても行います。 ここで、IP アドレスの順番は逆にします。 ステップ 2: リンクを安全にする。 リンクを安全にするために、IPsec を用います。 IPsec は、2 つのホストが暗号鍵に合意し、 その鍵を 2 つのホストの間でデータを暗号化するのに用いるメカニズムを提供します。 ここでは、設定を行う上で考慮すべき領域が 2 つあります。 2 つのホストで、 用いる暗号メカニズムに合意するメカニズムが必要です。 2 つのホストが一度このメカニズムに合意したら、 これらの間で セキュリティアソシエーション が確立されたことになります。 どのトラフィックを暗号化するかを特定するメカニズムが必要となります。 外向きのトラフィックのすべてを暗号化する必要はないのは明らかです。 -- VPN に関係するトラフィックのみを暗号化することが望まれます。 どのトラフィックを暗号すべきかを決めるために導入されるルールを セキュリティポリシ と呼びます。 セキュリティアソシエーションおよびセキュリティポリシの両方は、 カーネルにより管理されています。そして、ユーザランドプログラムにより、 変更することができます。 しかしながら、これを行う前に、カーネルを IPsec および Encapsulated Security Payload (ESP) プロトコルに対応するように、 設定する必要があります。 これは、カーネルを以下のように設定することで可能です。 kernel options IPSEC options IPSEC options IPSEC_ESP そして再構築し、再インストールを行って、再起動してください。 これは両方のゲートウェイホストのカーネルで行う必要があります。 IKE セキュリティアソシエーションの設定に関していうと、 2 つの選択肢があります。 1 つ目は、2 つのホスト間の設定を手動で設定する方法で、 暗号アルゴリズム、暗号鍵などを選択する必要があります。 もう 1 つは、これらをあなたに代わり行う Internet Key Exchange プロトコル (IKE) を実装しているデーモンを用いることです。 後者が推奨されます。とにかく、設定がより簡単です。 setkey &man.setkey.8; を用い得ることでセキュリティポリシを設定したり、 表示できます。 &man.route.8; がカーネルルーティングテーブルに関しているのと同様に、 setkey は、カーネルセキュリティポリシテーブルに関連しています。 setkey は、 現在のセキュリティアソシエーションも表示でき、 類推をさらに進めると、その点において、 netstat -r と同種です。 FreeBSD でセキュリティアソシエーションを管理するデーモンは数多くあります。 - この文書では、その中の一つの racoon の使い方について説明します。 - racoon は、&os; Ports Collection の + この文書では、その中の一つの racoon + の使い方について説明します。 + racoon は、&os; Ports Collection の security/ipsec-tools からインストールできます。 racoon racoon ソフトウェアは、 両方のゲートウェイホストで実行される必要があります。 それぞれのホストで、もう一つの VPN の端の IP アドレスおよび (あなたが選択したもので、両方のゲートウェイで同じ必要のある) 秘密鍵で設定する必要があります。 2 つのデーモンは、互いにコンタクトし、 (設定した秘密鍵を用いて) だれが相手であるかを確認します。 デーモンはその後、新しい秘密鍵を生成し、 VPN 上のトラフィックの暗号化のために用います。 攻撃者がこれらの鍵の (理論的には、不可能ですが) 1 つをクラックしても、それ以上できないように、 この秘密鍵を定期的に変更します。 -- 彼らがカギをクラックしたときには、 2 つのデーモンは他の鍵を選択していることでしょう。 - racoon の設定は、 + racoon の設定は、 ${PREFIX}/etc/racoon で行われます。 ここには、設定ファイルが置かれていますが、 それほど多く変更する必要はありません。 - おそらくあなたが変更すべき racoon の設定の他の部分は、 + おそらくあなたが変更すべき racoon + の設定の他の部分は、 pre-shared key です。 - デフォルトの racoon の設定では、これは、 - ${PREFIX}/etc/racoon/psk.txt + デフォルトの racoon の設定では、 + これは、${PREFIX}/etc/racoon/psk.txt ファイルにあると仮定されています。 pre-shared key は、VPN リンクを経由するトラフィックの暗号化には、 用いられません。 鍵管理デーモンがお互いを信頼するためのトークンです。 psk.txt は、 あなたが取り扱う各リモートのサイトに関連する行を含んでいます。 この例では、どこに 2 つのサイトがあるのか、 各 psk.txt ファイルは、一行を含んでいます (なぜならば、各 VPN の端は、他の端のみを取り扱うため)。 ゲートウェイホストの #1 では、 この行は以下のようなものです。 W.X.Y.Z secret これは、リモート端の 公開 IP アドレス、空白、 安全を提供するためのテキスト文字です。 明らかに、secret をあなたの鍵に使うべきではありません。 パスワードに対する通常の規則に従ってください。 ゲートウェイホスト #2 では、この行は以下のようになります。 A.B.C.D secret これは、リモート端の公開 IP アドレスと先ほどと同じ秘密鍵です。 - racoon を実行する前に psk.txt のモードは、 + racoon + を実行する前に psk.txt のモードは、 0600 (i.e., root のみが read/write できます) としてください。 - 両方のホストゲートウェイコンピュータで racoon - を走らせる必要があります。IKE + 両方のホストゲートウェイコンピュータで + racoon を走らせる必要があります。IKE トラフィックを許可するファイアウォールルールを追加する必要があります。 IKE トラフィックは、UDP 上で ISAKMP (Internet Security Association Key Management Protocol) port に対して実行されるものです。 このルールはファイアウォールルールセットの極めて最初に記述する必要があります。 ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp - 一度 racoon を走らせたら、 + 一度 racoon を走らせたら、 片方のゲートウェイホストから、他のホストへ ping を実行できます。 - 接続は、まだ暗号化されていませんが、racoon + 接続は、まだ暗号化されていませんが、racoon はその後 2 つのホスト間のセキュリティアソシエーションを設定します。 これは時間を要し、 ping コマンドが反応する前に少し時間の遅れとして認識できるでしょう。 一度セキュリティアソシエーションが確立されたら、 &man.setkey.8; を使って確認できます。 どちらかのホストで以下のように実行して、 セキュリティアソシエーション情報を確認してください。 setkey -D 以上で問題の半分が終わりました。 もう半分は、セキュリティポリシの設定です。 適切なセキュリティポリシを作成するには、 これまでにどのように設定されているかを確認することが必要となります。 この議論は、両方のリンクの端で行われます。 送信された各 IP パケットには、ヘッダがあり、 パケットに関するデータを持っています。 ヘッダにはソースおよびデスティネーションの両方の IP アドレスが含まれています。 我々はすでに知っているように、公開インターネット上では、 192.168.x.y といった範囲のプライベート IP アドレスは使われません。 そのかわり、最初に他のパケット内にカプセル化されます。 このパケットは、プライベートアドレスのかわりに、 公開ソースおよびデスティネーションの IP アドレスを持っています。 そのため、外向きのパケットは以下のように始まります。 .----------------------. | Src: 192.168.1.1 | | Dst: 192.168.2.1 | | <other header info> | +----------------------+ | <packet data> | `----------------------' その後、他のパケットの中に以下のようにカプセル化されます。 .--------------------------. | Src: A.B.C.D | | Dst: W.X.Y.Z | | <other header info> | +--------------------------+ | .----------------------. | | | Src: 192.168.1.1 | | | | Dst: 192.168.2.1 | | | | <other header info> | | | +----------------------+ | | | <packet data> | | | `----------------------' | `--------------------------' このカプセル化は gif デバイスにより行われます。確認できるように、 パケットは外側に本来の IP アドレスを持っており、 オリジナルパケットは、 インターネットに外向きに送られるパケットの中にデータとしてラップされています。 明らかに、VPN 間のすべてのトラフィックが暗号化されることが必要となります。 言葉にすると以下のようになります。 もしパケットが A.B.C.D から、 W.X.Y.Z へと送られるとすると、 必要なセキュリティアソシエーションを使って暗号化されます。 もしパケットが、 W.X.Y.Z から届き、 A.B.C.D へと送られる場合には、 必要なセキュリティアソシエーションを用いて復号化されます。 これは正解に近いのですが、極めて正しいというわけではありません。 もしこれを行ったとすると、 W.X.Y.Z へのトラフィック、または、ここからのトラフィックのすべてが、 VPN ではないトラックまで暗号化されてしまいます。 これはあなたが行いたいこととはまったく違います。 適切なポリシは以下のようなものになります。 A.B.C.D からパケットが出たとして、 そのパケットが他のパケットをカプセル化し、 W.X.Y.Z へと送られるとすると、 セキュリティアソシエーションを用いて暗号化します。 もし、パケットが、W.X.Y.Z から届き、 そのパケットが他のパケットをカプセル化し、A.B.C.D へと送られる場合には、 必要なセキュリティアソシエーションを使って復号化されます。 微妙な変更ですが、必要な変更です。 セキュリティポリシは、同じく &man.setkey.8; を用いることで設定します。 &man.setkey.8; は、ポリシを定義する設定言語の機能を持ちます。 stdin を使って設定の指示を行うか、設定の指示を含むファイル名を に指定して使用します。 W.X.Y.Z 向けへのすべてのトラフィックを暗号化するには、 ゲートウェイホスト #1 (パブリック IP アドレス A.B.C.D) の設定は以下のようにしてください。 spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; これらのコマンドをファイル (たとえば /etc/ipsec.conf) に追加し、 以下を実行してください。 &prompt.root; setkey -f /etc/ipsec.conf は、&man.setkey.8; に対し、 安全なポリシのデータベースにルールを追加することを伝えます。 この行の残りでは、どのパケットがこのポリシに一致するかを特定します。 A.B.C.D/32 および W.X.Y.Z/32 は、 このポリシを適応したいネットワークを特定するための IP アドレスとネットマスクです。 このケースでは、これらの 2 つのホスト間の通信に適応したいという例です。 は、カーネルに対して、このポリシは、 他のパケットをカプセル化しているパケットのみに適応することを伝えます。 は、このポリシを外向きのパケットに適応し、 により、 パケットが安全であることを伝えます。 2 行目は、パケットをどのように暗号化するかを指定します。 は使用するプロトコルで、 は、IPsec パケットにおいてさらにカプセル化されることを指定します。 A.B.C.D および W.X.Y.Z は、 使用するセキュリティアソシエーションを選択するのに用います。 最後の は、このルールにマッチした場合に、 パケットを暗号化することを指定します。 このルールは、外向きのパケットのみにマッチします。 同様のルールが内向きのパケットに対して必要です。 spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; このケースでは、 のかわりに 、そして IP アドレスを逆にすることが必要です。 (IP アドレス W.X.Y.Z の) 他のゲートウェイホストにも同じルールが必要です。 spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; 最後に、ファイアウォールに ESP および IPENCAP パケットが行き来することを許可するルールを追加する必要があります。 これらのルールは、 それぞれのホストに追加する必要があります。 ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D ルールは対称なので、 それぞれのゲートウェイホストに同じルールを利用できます。 外向きのパケットは、以下のようになります。 .------------------------------. --------------------------. | Src: A.B.C.D | | | Dst: W.X.Y.Z | | | <other header info> | | Encrypted +------------------------------+ | packet. | .--------------------------. | -------------. | contents | | Src: A.B.C.D | | | | are | | Dst: W.X.Y.Z | | | | completely | | <other header info> | | | |- secure | +--------------------------+ | | Encap'd | from third | | .----------------------. | | -. | packet | party | | | Src: 192.168.1.1 | | | | Original |- with real | snooping | | | Dst: 192.168.2.1 | | | | packet, | IP addr | | | | <other header info> | | | |- private | | | | +----------------------+ | | | IP addr | | | | | <packet data> | | | | | | | | `----------------------' | | -' | | | `--------------------------' | -------------' | `------------------------------' --------------------------' VPN の端から受け取った場合には、 - (racoon によりネゴシエートされたセキュリティアソシエーションを用いて) + (racoon + によりネゴシエートされたセキュリティアソシエーションを用いて) 最初に復号化を行います。 その後、gif インタフェースに入ります。 このインタフェースは、内部のネットワークを回ることのできる最も内側のパケットになるまで、セカンドレイヤのラップをはがします。 先ほどと同じく &man.ping.8; 試験でセキュリティを確認できます。 最初に、A.B.C.D ゲートウェイコンピュータにログインして、 以下を実行してください。 tcpdump dst host 192.168.2.1 同じホストの別のログインセッションで以下を実行してください。 ping 192.168.2.1 今回は、以下のような出力が表示されます。 XXX tcpdump output &man.tcpdump.1; は、ESP パケットを表示します。 オプションを使って実行すると、 暗号化のため、見ても理解できないものが表示されるでしょう。 おめでとうございます。 これで 2 つのリモートサイト間の VPN を設定できました。 まとめ 以下のオプションでカーネルを再構築します。 options IPSEC options IPSEC_ESP security/ipsec-tools をインストールします。 両方のゲートウェイホストにおいて、 ${PREFIX}/etc/racoon/psk.txt を変更して、 リモートホストの IP アドレスのエントリおよびお互いが知っている秘密鍵を追加してください。 このファイルのモードは 0600 に設定してください。 各ホストにおいて以下の行を /etc/rc.conf に追加してください。 ipsec_enable="YES" ipsec_file="/etc/ipsec.conf" 各ホストにおいて /etc/ipsec.conf を作成し、必要となる spdadd 行を追加してください。 ゲートウェイホスト #1 では以下のようになります。 spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; ゲートウェイホスト 2 では以下のようになります。 spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; 両方のホストにおいて IKE, ESP, および IPENCAP トラフィックが許可されるようにファイアウォールのルールを追加してください。 ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D 直前の 2 つのステップは、VPN を実行できれば十分です。 各ネットワークのコンピュータは、IP アドレスを使って他のネットワークのコンピュータを参照できますし、 すべてのリンクを横切るトラフィックは自動的にそして安全に暗号化されます。 OpenSSH ChernLee寄稿: OpenSSH セキュリティ OpenSSH OpenSSH はリモートマシンへのセキュアなアクセスに使われるネットワーク接続ツールの集合です。 これは rlogin, rsh, rcp, telnet をそのまま置き換えて使えます。 また、TCP/IP 接続を SSH 経由でセキュアにトンネル/フォワードすることもできます。 OpenSSH はすべてのトラフィックを暗号化し、 盗聴や接続の乗っ取り等のネットワークレベルの攻撃を事実上無効化します。 OpenSSH は OpenBSD プロジェクトによって維持管理されており、SSH v1.2.12 に最新のすべてのバグ修正と更新を適用したものをベースにしています。 OpenSSH クライアントは SSH プロトコル 1 と 2 の両方に互換性があります。 OpenSSH を使うことの利点 &man.telnet.1; や &man.rlogin.1; を使う場合、一般にデータはネットワークを平文で流れます。 ネットワークをクライアントとサーバの間のどこかで盗聴することで あなたのユーザ/パスワード情報やセション中を流れるデータを盗むことが可能です。 OpenSSH はこれらを予防する為にさまざまな認証と暗号化の方法を提供します。 sshd を有効にする OpenSSH 有効化 sshd は、 &os; の Standard インストールの途中で、 オプションとして表示されます。 sshd が有効になっているかどうかを確認するには、 rc.conf ファイルを確認してください。 sshd_enable="YES" 次に起動したときから OpenSSH のデーモンプログラムである &man.sshd.8; が起動します。 もしくは /etc/rc.d/sshd &man.rc.8; スクリプトを使って、OpenSSH を起動することもできます。 /etc/rc.d/sshd start SSH クライアント OpenSSH クライアント &man.ssh.1; ユーティリティは &man.rlogin.1; と同様に働きます。 &prompt.root; ssh user@example.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'example.com' added to the list of known hosts. user@example.com's password: ******* ログインは rlogin や telnet でセッションを張った時と同様に続きます。 SSH はクライアントが接続した時、 サーバの信頼性の検証のために鍵指紋システム (key fingerprint system) を利用します。 初めての接続の際にのみ、ユーザは yes と入力することを要求されます。 これ以降の login では保存されていた鍵指紋を照合することで検証されます。 SSH クライアントは保存されていた鍵指紋が login しようとした際に送られてきたものと異なっていた場合には警告を表示します。 指紋は ~/.ssh/known_hosts に、また SSH v2 指紋の場合は ~/.ssh/known_hosts2 に保存されます。 デフォルトでは、OpenSSH サーバはの最近の版では SSH v2 のみの接続を受け付けるように設定されています。 クライアントはバージョン 1 および 2 のどちらかを選択できます。 バージョン 2 は、旧バージョンよりも堅固で安全です。 &man.ssh.1; コマンドに、プロトコル v1 と v2 についてそれぞれ、引数 または を渡すことで、利用するプロトコルを強制できます。 Secure copy OpenSSH secure copy scp &man.scp.1; コマンドは &man.rcp.1; と同様に働きます。 安全な方法で行っているほかは、ローカルのファイルをリモートマシンへ、 あるいはリモートマシンのファイルをローカルにコピーするのは同じです。 &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; 前回の例でこのホストの指紋がすでに保存されていれば この &man.scp.1; を使う時に検証が行なわれます。 &man.scp.1; に渡される引数は、&man.cp.1; のものと似ており、ファイル (1 つまたは複数) が 1 つめの引数になり、コピー先が 2 つめの引数になります。 ファイルはネットワーク越しに SSH を通して送られるので、 引数に指定するファイルには という形式をとるものがあります。 設定 OpenSSH 設定 システム全体の設定ファイルは、OpenSSH デーモン、クライアントの両方とも /etc/ssh ディレクトリにあります。 ssh_config はクライアントの動作設定、 sshd_config はデーモンの動作設定を行ないます。 さらに、rc.conf オプションの (デフォルトは /usr/sbin/sshd) と により、詳細な設定が行えます。 ssh-keygen パスワードの代わりに &man.ssh-keygen.1; を使ってユーザの認証用の DSA または RSA 暗号鍵を作ることができます。 &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Created directory '/home/user/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com &man.ssh-keygen.1; は認証に使う為の公開鍵と秘密鍵のペアを作ります。 DSA または RSA 鍵に応じて、 秘密鍵は ~/.ssh/id_dsa または ~/.ssh/id_rsa に保存され、 公開鍵は ~/.ssh/id_dsa.pub または ~/.ssh/id_rsa.pub にそれぞれ保存されます。 公開鍵はセットアップのために、 DSA または RSA のどちらを使う場合にも、 リモートマシンの ~/.ssh/authorized_keys ファイルに含まれてなければなりません。 これでパスワードの代わり SSH 鍵を使ってリモートマシンに接続できるようになったはずです。 &man.ssh-keygen.1; でパスフレーズを使っている場合は、 秘密鍵を使うためにユーザは毎回パスフレーズを入力する必要があります。 長いパスフレーズを毎回入力しなくてはならない負担は、 &man.ssh-agent.1; を使うと軽減できます。 これについては、 以下の の節で説明されています。 システムにインストールされている OpenSSH のバージョンによって、 オプションやファイルに違いが出てくることがあります。 &man.ssh-keygen.1; を参照して、 問題が起こることを避けてください。 ssh-agent および ssh-add &man.ssh-agent.1; および &man.ssh-add.1; ユーティリティは、 パスフレーズを毎回入力することなしに、 SSH 鍵を利用できるようにメモリに読み込む方法を提供します。 &man.ssh-agent.1; ユーティリティは、 読み込まれた秘密鍵による認証を取り扱います。 &man.ssh-agent.1; は他のアプリケーションの起動に用いられる必要があります。 基本的なレベルではシェルを起動し、 より高度なレベルでは、ウィンドウマネージャも起動します。 シェル上で &man.ssh-agent.1; を使うには、 まず引数としてシェルを起動する必要があります。 次に、&man.ssh-add.1; を実行し、 秘密鍵のパスフレーズを入力することにより、 鍵を追加する必要があります。 一度この過程を終えてしまえば、ユーザは、 対応する公開鍵が置かれているホストに &man.ssh.1; でログインできるようになります。 以下はその例です。 &prompt.user; ssh-agent csh &prompt.user; ssh-add Enter passphrase for /home/user/.ssh/id_dsa: Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) &prompt.user; X11 上で &man.ssh-agent.1; を使うには、 &man.ssh-agent.1; への呼び出しが ~/.xinitrc に置かれている必要があります。 これにより、X11 上で起動されるすべてのプログラムにおいて、 &man.ssh-agent.1; サービスが提供されるようになります。 ~/.xinitrc ファイルの例は以下となります。 exec ssh-agent startxfce4 これで、X11 を開始するときにはいつでも &man.ssh-agent.1; が起動され、 このプログラムから XFCE が起動されます。 一度この設定を行い、X11 を再起動した後は有効になりますので、 &man.ssh-add.1; を引数なしに実行し、 すべての SSH 鍵を読み込ませてください。 SSH トンネリング OpenSSH トンネリング OpenSSH は暗号化されたセッションの中に他のプロトコルを カプセル化するトンネルを作ることができます。 以下のコマンドは &man.ssh.1; で telnet 用のトンネルを作成します。 &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; ssh コマンドは、 次のオプションとともに利用します。 ssh にプロトコルバージョン 2 を使うことを指示します。(古い SSH サーバを使っているときには指定しないでください) はトンネルだけでコマンドはないことを示します。 省略されると &man.ssh.1; は通常のセッションを開始します。 ssh にバックグラウンド実行を強制します。 ローカルトンネルを localport:remotehost:remoteport という形式で指定します。 リモートの SSH サーバです。 SSH のトンネルは localhost の指定されたポートに listen するソケットを作ることで実現されています。 SSH はローカルのホスト/ポートで受けた接続すべてを SSH 接続経由で指定されたリモートホストのポートへ転送します。 この例では、localhost のポート 5023 がリモートマシンの localhost のポート 23 に転送されるようになっています。 23 は telnet なのでこれは SSH トンネルを通るセキュアな telnet セッションを作ります。 このようにして SMTP や POP3, FTP 等のセキュアではない TCP プロトコルをカプセル化することができます。 SSH を用いた SMTP 用の安全なトンネルの作成 &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP &man.ssh-keygen.1; と別のユーザアカウントを組み合わせて使うことでより透過的で悩まずに済むような SSH のトンネル環境を作ることができます。 パスワードを入力するところで暗号鍵を使い、 トンネルは別のユーザ権限で実行することが可能です。 実用的な SSH トンネルの例 POP3 サーバへの安全な接続 仕事で、外部からの接続を受ける SSH サーバがあるとします。 同じオフィスのネットワークには、POP3 サーバが動いているメールサーバがあるとします。 ネットワークもしくはあなたの家とオフィスの間のネットワーク経路は、 完全に信頼できるものかもしれませんし、そうではないかもしれません。 そのため、電子メールは安全なやり方で見るようにしなければなりません。 解決策は、オフィスの SSH サーバへの SSH 接続を行い、 メールサーバへのトンネルを作成することです。 &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ****** トンネルが作成されて動作したら、 メールクライアントに対し localhost のポート 2110 に POP3 リクエストを送るように指示できます。 そこへの接続は、トンネルを経由して安全に mail.example.com に転送されます。 厳格なファイアウォールをすり抜ける 内向けの接続をフィルタするだけでなく、 外向けの接続もフィルタして、 極端に厳しいファイアウォールルールを課すネットワーク管理者もいます。 リモートのマシンには、SSH 接続と web サーフィンのための 22 番および 80 番ポートにしか接続させてもらえないかもしれません。 あなたは、それ以外の (もしかすると仕事に関係ない) サービスにアクセスしたくなるかもしれません。 例えば、音楽ストリーミングを行う Ogg Vorbis サーバといったものです。 この Ogg Vorbis サーバが 22 番または 80 番ポート以外でストリーミングを行っていたら、 あなたはそのサーバに接続できないでしょう。 それに対する解決策は、 あなたが接続しているネットワークのファイアウォールの外部にあるマシンに対して SSH 接続を行い、Ogg Vorbis サーバへのトンネルに利用することです。 &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* ストリーミングクライアントを localhost の 8888 番ポートに向けると、music.example.com の 8000 番ポートに転送され、 ファイアウォールをすり抜けられます。 <varname>AllowUsers</varname> ユーザオプション ログインできるユーザや接続元を制限することは、 通常は良い考えです。 AllowUsers オプションは、 この目的のために使うことができます。 たとえば、 root ユーザが 192.168.1.32 からのみログインできるようにするには、 /etc/ssh/sshd_config ファイルの設定は以下のようになります。 AllowUsers root@192.168.1.32 admin ユーザがどこからでもログインできるようにするには、 ユーザ名そのものを記述してください。 AllowUsers admin 複数のユーザは、以下のように同じ行に追加してください。 AllowUsers root@192.168.1.32 admin 注意すべきことは、 このコンピュータにログインする必要のあるすべてのユーザを指定することです。 設定されていないと、そのユーザはログインできなくなります。 /etc/ssh/sshd_config への変更が終わったら、 以下を実行して、設定ファイルを &man.sshd.8; に読み込ませてください。 &prompt.root; /etc/rc.d/sshd reload もっと詳しく知りたい人へ OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; &man.sshd.8; &man.sftp-server.8; &man.sshd.config.5; ファイルシステムアクセス制御リスト TomRhodes寄稿: ACL スナップショットのようなファイルシステムの拡張と連携して、 FreeBSD 5.0 以降ではファイルシステムアクセス制御リスト (ACL) によるセキュリティを提供しています。 アクセス制御リストは、標準的な &unix; のパーミッションモデルを、 非常に互換性の高い (&posix;.1e) やり方で拡張しています。 この機能は、管理者がより洗練されたセキュリティモデルを利用し、 その恩恵を受けられるようにします。 UFS ファイルシステム用の ACL サポートを有効にするには、 次のオプションをカーネルに組み込まなければなりません。 options UFS_ACL もしこのオプションが組み込まれていなければ、ACL に対応したファイルシステムをマウントしようとすると、 警告が表示されます。このオプションは GENERIC カーネルに含まれています。ACL は、ファイルシステムの拡張属性が有効になっていることに依存しています。 拡張属性は、次世代 &unix; ファイルシステムである UFS2 でネイティブ対応されています。 UFS1 に拡張属性を付すように設定するのは、 UFS2 よりも高いレベルの管理オーバヘッドが必要になります。 また、UFS2 における拡張属性のパフォーマンスも大きく上がっています。 その結果、アクセス制御リストを利用する上では、一般的には UFS1 よりも UFS2 の方がおすすめです。 ACL は、マウント時の管理フラグ で有効にされます。 これは /etc/fstab に記述できます。 マウント時のフラグは、&man.tunefs.8; を使って、ファイルシステムヘッダのスーパブロックにある ACL フラグを変更するという方法で、 常に自動で設定されるようになります。一般的には、 下記の理由からスーパブロックフラグを使う方がよいでしょう。 マウント時に指定した ACL フラグは再マウント (&man.mount.8; ) 時に変更できません。完全に &man.umount.8; した上で、新たに &man.mount.8; するしかありません。これは、起動後にルートファイルシステムで ACL を有効にできないことを意味します。 また、ファイルシステムを利用し始めた後では、 その配列を変えられないことも意味しています。 スーパブロックフラグを設定すると、fstab に記述されていなかったり、デバイスの順番が変わってしまっても、常に ACL が有効な状態でマウントされます。 こうすることで、ファイルシステムを ACL を有効にしないままマウントしてしまい、ACL が正しくないかたちで強制され、 セキュリティ問題につながることを防ぎます。 ACL の動作を変更して、まったく新たに &man.mount.8; を行わなくてもフラグを有効にできるようにすることも可能でしょう。 しかし、我々は、うっかり ACL を有効にしないでマウントしてしまうのを防ぐようにした方が望ましいと考えました。 ACL を有効にし、その後無効にしてから、 拡張属性を取り消さないでまた有効にしてしまうと、 鬱陶しい状態に自分で入り込んでしまえるからです。 一般的には、一度ファイルシステムで ACL を有効にしたら、無効にすべきではありません。そうしてしまうと、 ファイル保護がシステムのユーザの意図と齟齬をきたす可能性があるばかりか、 ACL を再度有効にすると、 それまでパーミッションが変更されてきたファイルに古い ACL を割り当ててしまい、 予想しない動作につながることも考えられます。 ACL を有効にしたファイルシステムは、 パーミッション設定の表示に + (プラス) 記号がつきます。例えば、次のようになります。 drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html ここでは、ディレクトリ directory1, directory2 および directory3 のすべてで ACL が働いています。 ディレクトリ public_html は対象外です。 <acronym>ACL</acronym> を利用する &man.getfacl.1; ユーティリティは、 ファイルシステムの ACL を表示します。 たとえば、test ファイルの ACL 設定を表示するには、 以下のコマンドを実行してください。 &prompt.user; getfacl test #file:test #owner:1001 #group:1001 user::rw- group::r-- other::r-- このファイルの ACL 設定を変更するには、 以下のように &man.setfacl.1; ユーティリティを使用してください。 &prompt.user; setfacl -k test フラグは、 ファイルまたはファイルシステムから、現在設定されている ACL をすべて取り除きます。 より好ましい方法は、 を使う方法です。 このオプションを使うと、ACL が動作するのに必要な基本のフィールドは残ります。 &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- test 上記のコマンドにおいて、 オプションは、デフォルト ACL エントリを修正するために使われています。 先ほどのコマンドで設定は削除されたため、 定義されたエントリはありません。 このコマンドは、デフォルトオプションに戻し、 指定したオプションを割り当てます。 システムに存在しないユーザまたはグループを追加すると、 Invalid argument エラーが stdout に出力されることに気を付けてください。 サードパーティ製ソフトウェアのセキュリティ問題を監視する Tom Rhodes 寄稿: Portaudit 近年、セキュリティの分野では、 脆弱性の評価方法に関して多くの改善が行わています。 今日ではどのオペレーティングシステムにおいても、 システムへの侵入の脅威は、 サードパーティ製ユーティリティをインストールし、 設定するほどに増加していきます。 脆弱性を評価することは、セキュリティにおいて主要な要素です。 &os; は、ベースシステムに対して勧告を発行していますが、 すべてのサードパーティ製ユーティリティに対して勧告を発行することは、 &os; プロジェクトの能力を超えています。 サードパーティ製ユーティリティに関わる脆弱性を軽減し、 管理者に対し、既知のセキュリティ問題について警告する方法が存在します。 &os; には、Portaudit と呼ばれる追加のユーティリティが、 この目的のために用意されています。 ports-mgmt/portaudit port は、 &os; セキュリティチームおよび ports 開発者がアップデートし、管理している、 既知のセキュリティ問題に対するデータベースを入手します。 Portaudit を使うには、 Ports Collection からインストールしてください。 &prompt.root; cd /usr/ports/ports-mgmt/portaudit && make install clean インストールの過程で、 &man.periodic.8; の設定ファイルはアップデートされ、 毎日のセキュリティに関するスクリプトの実行中において Portaudit による出力が行われるようになります。 毎日のセキュリティに関するスクリプトの実行結果のメールが読めることを確認してください。 このメールは、root アカウントに送られます。 この時点では、設定は必要ありません。 インストールが終わったら、管理者は以下のコマンドを実行することで、 データベースをアップデートし、インストールされている package の脆弱性を調べることができます。 &prompt.root; portaudit -Fda データベースは、 &man.periodic.8; の実行中に自動的にアップデートされるので、 先のコマンドを実行することは完全に任意です。 以下の説明のためだけに必要です。 Ports Collection からインストールされたサードパーティ製ユーティリティを監査するには、 管理者は以下のコマンドだけを実行する必要があります。 &prompt.root; portaudit -a Portaudit は、脆弱性のある package について以下のような出力を行います。 Affected package: cups-base-1.1.22.0_1 Type of problem: cups-base -- HPGL buffer overflow vulnerability. Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html> 1 problem(s) in your installed packages found. You are advised to update or deinstall the affected package(s) immediately. 表示されている URL をウェブブラウザで開くと、管理者は、 問題となっている脆弱性についてより多くの情報を得ることができます。 ここでの出力では、影響するバージョンが &os; Port バージョンにより示され、 セキュリティ勧告を含む他のウェブサイトが含まれています。 一口にいうと、Portaudit は強力で、 Portupgrade port と共に使うときわめて有用なユーティリティです。 &os; セキュリティ勧告 Tom Rhodes 寄稿: FreeBSD セキュリティ勧告 多くの高品質なオペレーティングシステムと同様、 &os; は セキュリティ勧告 を発行しています。 これらの勧告は、通常セキュリティに関連したのメーリングリストに投稿され、 サポートされているリリースに対してパッチが作成された後、 Errata に記載されます。 この章では、セキュリティ勧告とは何か、どのように理解すべきか、 システムにパッチを当てるにはどのように対応すればよいかについて説明します。 セキュリティ勧告はどのようなものか？ &os; セキュリティ勧告は、以下のようなものです。 以下は &a.security-notifications.name; メーリングリストに流れたものです。 ============================================================================= &os;-SA-XX:XX.UTIL Security Advisory The &os; Project Topic: denial of service due to some problem Category: core Module: sys Announced: 2003-09-23 Credits: Person@EMAIL-ADDRESS Affects: All releases of &os; &os; 4-STABLE prior to the correction date Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) 2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15) 2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8) 2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18) 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) CVE Name: CVE-XXXX-XXXX For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://www.FreeBSD.org/security/. I. Background II. Problem Description III. Impact IV. Workaround V. Solution VI. Correction details VII. References Topic フィールドは、何が問題であるかを正確に示しています。 通常は、このセキュリティ勧告の導入部であり、 脆弱性のあるユーティリティを示します。 Category フィールドでは、 脆弱性がシステムのどの部分に影響するかを示します。 core, contrib または ports のどれかが示されます。 core カテゴリは、 &os; オペレーティングシステムの core コンポーネントに影響する脆弱性であることを意味します。 contrib カテゴリは、 sendmail のように、&os; の外で開発され、&os; プロジェクトに取り込まれたソフトウェアに影響する脆弱性であることを意味します。 ports カテゴリは、Ports Collection として、 インストールされるソフトウェアに影響する脆弱性であることを示しています。 Module フィールドは、 (たとえば sys といった) 影響するコンポーネントを参照します。 この場合、sys モジュールに影響することがわかります。 そのため、この脆弱性は、 カーネルの中で使われるコンポーネントに影響します。 Announced フィールドは、 セキュリティ勧告が発行された日、 またはアナウンスされた日が記載されています。 セキュリティチームによりこの問題が存在することが確認され、 パッチが &os; ソースコードリポジトリにコミットされたことを意味します。 Credits フィールドは、 脆弱性を通知し、報告した個人または組織を示します。 Affects フィールドは、この脆弱性がどの &os; リリースに影響するかを説明します。 カーネルでは、影響するファイルに対して ident を実行すると、 その出力からリビジョンを簡単に確認できます。 ports の場合には、/var/db/pkg の port の名前の後に、バージョン番号が示されています。 もし、システムが &os; CVS リポジトリと同期し、再構築が毎日行われているような状況でなければ、 おそらく、そのシステムには影響しているでしょう。 Corrected フィールドは、 脆弱性が修正された日、時間、 タイムゾーン、およびリリースが示されます。 共通の脆弱性データベースシステムにおいて、 脆弱性を探すために使用できる識別情報を示します。 Background フィールドは、 影響しているユーティリティがどのようなものであるかといった情報を正確に示します。 大体の場合は、なぜユーティリティが &os; に存在するか、 何のために使われているか、 どのように用いられるようになってきたか、 といった情報が示されます。 Problem Description フィールドは、 より深くセキュリティホールについて説明します。 問題のあるコードの情報や、 このユーティリティが悪意のある使い方により、 どのようにセキュリティホールを開けうるかといったことが示されます。 Impact フィールドは、 この問題がシステムに対して、 どのような形式の影響を与えるかについて示します。 たとえば、DoS 攻撃によるものか、 ユーザに対して意図しない特権を持たせてしまうものか、 または、攻撃者にスーパユーザのアクセスを与えるようなものか、 といったことが示されます。 Workaround フィールドは、 システムをアップグレードできないシステム管理者に対して、 実現可能な回避方法を提供します。 これは、時間による制限や、ネットワークの可用性、 他のたくさんの理由によります。 このような理由にかかわらず、 セキュリティを甘く見るべきではありません。 影響するシステムは、パッチが当てられるか、 セキュリティホールの回避方法が実行されるべきです。 Solution フィールドは、 影響のあるシステムにパッチを当てる手順を提供します。 ここではステップごとにシステムにパッチを当て、 安全に動作するように、 試験され検証された方法が記載されます。 Correction Details フィールドは、 CVS ブランチまたはリリース名のピリオドをアンダースコアに置き換えたものを示します。 ここでは、 各ブランチにおいて影響するファイルのリビジョン番号も示します。 References フィールドは、 通常、ウェブページの URL, books, メーリングリストおよびニュースグループといった、 ほかの情報へのソースを提供します。 プロセスアカウンティング Tom Rhodes 寄稿: プロセスアカウンティング プロセスアカウンティングは、 管理者が使用されているシステムのリソースを記録したり、 リソースのユーザへの割り当て、 システムのモニタリングおよびユーザのコマンドの最低限の記録を提供します。 これは実際には、長所と短所があります。 長所の一つは、侵入を入り口の時点で絞ることができます。 短所は、プロセスアカウンティングにより生成されるログの量で、 多くのディスク容量を必要とします。この節では、 管理者を対象にプロセスアカウンティングの基礎を説明します。 プロセスアカウンティングを有効にする プロセスアカウンティングを使用する前に、 プロセスアカウンティングを有効にしておく必要があります。 有効にするには、以下のコマンドを実行してください。 &prompt.root; touch /var/account/acct &prompt.root; accton /var/account/acct &prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf 有効に設定すると、アカウンティングは、 CPU の統計、コマンドなどの追跡を開始します。 すべてのアカウンティングログは、 人が読めるような形式ではないので、 &man.sa.8; ユーティリティを使って見ることになります。 オプションを設定せずに実行すると、 sa はユーザコールの数、全経過時間 (分)、 全 CPU およびユーザの時間 (分)、 I/O 操作の平均数などを出力します。 実行されたコマンドに関する情報を見るには、 &man.lastcomm.1; ユーティリティを使ってください。 - lastcomm を使うと、 + lastcomm コマンドを使うと、 ユーザが特定の &man.ttys.5; で実行したコマンドを出力できます。 以下はその例です。 &prompt.root; lastcomm ls trhodes ttyp1 - このコマンドを実行すると、ttyp1 + このコマンドを実行すると、ttyp1 ターミナル上で trhodes が実行した ls の使用について、記録されているすべて示します。 他にも有用なオプションが多くあり、 &man.lastcomm.1;, &man.acct.5; および &man.sa.8; マニュアルページで 説明されています。