diff --git a/ja_JP.eucJP/books/handbook/security/chapter.xml b/ja_JP.eucJP/books/handbook/security/chapter.xml index df9a1ef495..85bbccf88b 100644 --- a/ja_JP.eucJP/books/handbook/security/chapter.xml +++ b/ja_JP.eucJP/books/handbook/security/chapter.xml @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r41645 + Original revision: r42014 $FreeBSD$ --> @@ -36,26 +36,22 @@ &os; における高度な話題について簡単に説明します。 ここで扱う話題の多くは、 一般的なシステムやインターネットセキュリティにもあてはまります。 - インターネットはもはや、誰もが親切な隣人であろうとする - 友好的な 場ではありません。 - あなたのシステムを安全に保つことは、 - あなたのデータ、知的財産、時間、その他を、 + システムを安全に保つことは、データ、知的財産、時間、その他を、 ハッカーやその同類から守るためには欠かせません。 &os; は、 - システムとネットワークの整合性と安全性を確実にする仕組みと一連のユーティリティを提供しています。 + システムとネットワークの整合性および安全性を保護する仕組みと一連のユーティリティを提供しています。 この章を読むと、以下のことがわかります。 &os; - に関する基本的なシステムセキュリティの考え方 + における基本的なシステムセキュリティの考え方 - DES や MD5 のような、 - &os; で利用できるさまざまな暗号化手法について + &os; で利用できるさまざまな暗号化手法 @@ -63,45 +59,49 @@ - inetd と組み合わせて + &man.inetd.8; と組み合わせて TCP Wrappers を設定する方法 &os; における - Kerberos5 の設定方法 + Kerberos の設定方法 - IPsec および FreeBSD/&windows; コンピュータの間で - VPN の設定方法 + IPsec を設定して VPN を構築する方法 - &os; で使われている SSH である + &os; にける OpenSSH の設定および使用方法 - ファイルシステムの ACL (アクセス制御リスト) - とは何か、またその使用法 + ファイルシステム ACL (アクセス制御リスト) + の使用方法 - Portaudit - ユーティリティを使って、Ports Collection + Ports Collection からインストールされたサードパーティ製ソフトウェア packages - を監査する方法 + を Portaudit + を使って監査する方法 - 公開される &os; セキュリティ勧告の利用方法 + &os; セキュリティ勧告の利用方法 プロセスアカウンティングがどのようなものか、 &os; 上で有効にする方法について + + + リソース制限データベースとは何か、 + この仕組みを使ったユーザ資源の管理方法 + この章を読む前に、次のことが必要になります。 @@ -112,33 +112,26 @@ - + はじめに セキュリティとは、システム管理者をいつも悩ませる仕事の一つです。 - すべての BSD &unix; マルチユーザシステムは、 - 従来からいくつかのセキュリティ機構を備えていますが、 - ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し保守する仕事はおそらく、 - システム管理者としてもっとも大きな責務の一つでしょう。 - マシンの安全性に反映されるのは、管理者が作業したことだけです。 - またセキュリティ問題は、快適な環境に必要なものと競合します。 - 一般に &unix; システムは膨大な数のプロセスを同時に動作させることができ、 - そのプロセスの大部分は、サーバ — - 外部から接続し、通信するものとして動作します。 - かつてのミニコンとメインフレームがデスクトップにとってかわり、 - さらにコンピュータが相互に接続されたネットワークを形成するようになった今日、 - セキュリティは一層大きな関心事になってきています。 + &os; は、固有のセキュリティ機構を備えていますが、 + 追加のセキュリティ機構を設定し保守する仕事はおそらく、 + システム管理者としてもっとも大きな責務の一つでしょう。 また、システムセキュリティには、 さまざまな形での攻撃に対処することとも関係しています。 攻撃の中には root - 権限を奪おう (root 権限を破る) とはしないけれども、 + 権限を奪おうとはしないけれども、 クラッシュやシステムの不安定状態を引き起こそうとするものもあります。 このセキュリティ問題は、いくつかに分類することが可能です。 @@ -152,7 +145,7 @@ - アクセス可能なサーバを使った root 権限の不正利用 + アクセス可能なサービスを使った root 権限の不正利用 @@ -177,20 +170,14 @@ サービス妨害 (DoS) - サービス妨害攻撃 (DoS 攻撃) とは、 + サービス妨害攻撃 (DoS 攻撃) とは、 マシンから必要な資源を奪う行為です。 - 通常、サービス妨害攻撃はそのマシンで実行されるサーバや - ネットワークスタックを過負荷状態にしてマシンをクラッシュさせたり、 + 通常、サービス妨害攻撃はそのマシンで実行されるサーバやネットワークスタックを過負荷状態にして、 + マシンをクラッシュさせたり、 マシンを使えなくしたりするような力任せの方法です。 - サービス妨害攻撃の中には、 - ネットワークスタックのバグを利用して、 - パケット一つでマシンをクラッシュさせようとするものもあります。 - 後者には、カーネルにバグ修正を施すことによってのみ対応することができます。 サーバプロセスに対する攻撃は、オプションを適切に指定することによって、 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで対応できる場合が多いです。これらに比べると、 ネットワークへの力任せの攻撃への対応はずっと難しくなります。 - たとえば、偽造パケットによる攻撃 (spoof-packet attack) は、 - インターネットからシステムを切り離す以外の方法で防ぐことはほとんど不可能です。 この攻撃によって、マシンを落としてしまうことはできないかもしれませんが、 接続しているインターネット回線を飽和させてしまうことはできます。 @@ -200,34 +187,22 @@ ユーザアカウントの不正利用は、 - サービス妨害攻撃よりもずっとよくある問題です。 - このご時勢でも、自分たちのマシンで標準の - telnetd, - rlogind, - rshd, - ftpd - サーバを実行させているシステム管理者は多いのです。 - これらのサーバは、デフォルトでは、 - 暗号化されたコネクション上で動作していません。 - その結果、抱えているユーザ数が標準くらいであれば、リモートログイン - (そのシステムにログインするには最も普通で便利な方法です) - しているユーザのうち一人以上は、 - パスワードを覗き見られてしまうでしょう。 + DoS 攻撃よりもずっとよくある問題です。 + このご時勢でも、 + 暗号化されていないサービスを実行させているシステム管理者は多く、 + そのため、リモートからログインしているユーザは、 + パスワードを覗き見られてしまう危険性があります。 システム管理者が注意深い人ならば、 - たとえログインが成功していたとしても、 リモートアクセスログを解析して、 - 疑わしい送信元アドレスを探すものです。 + 疑わしい送信元アドレスや疑わしいログインを探すものです。 - ひとたび攻撃者がユーザアカウントへのアクセス権を入手したら、 - 攻撃者は root - 権限を破れると仮定するべきです。 - しかし、セキュリティを十分維持し、 + セキュリティを十分維持し、 手入れの行き届いたシステムにおいては、 あるユーザアカウントへのアクセスが可能となっても、 必ずしも攻撃者に root - へのアクセス権を与えるとは限りません。この違いは重要です。 - というのは、一般的に - root へのアクセス権がなければ、 + へのアクセス権を与えるとは限りません。 + root + へのアクセス権がなければ、 攻撃者は自分の侵入の痕跡を隠蔽することができませんし、 そのユーザのファイルを引っかき回したり、 マシンをクラッシュさせたりするのがせいぜいです。 @@ -240,38 +215,18 @@ 裏口 (バックドア) - システム管理者は、あるマシン上で - root - 権限を奪取する方法は、 - 潜在的に何通りもあるということを心しておかねばなりません。 + root + 権限を奪取する方法は、潜在的に何通りもあります。 攻撃者は root のパスワードを知っているかもしれませんし、 攻撃者が root - 権限で実行されているサーバのバグを見つけ、 - ネットワーク接続を介して - root - 権限を破ることができるかもしれません。 - また、攻撃者は suid-root プログラムに存在するバグを知っていて、 - ユーザアカウントを破れば - root - 権限を奪取できるかもしれません。 - 攻撃者があるマシン上で - root - 権限を破る方法を知ったならば、 - 攻撃者は裏口を用意する必要がありません。 - これまでに発見され、ふさがれた - root - の穴の多くには、攻撃者が自分のしたことの痕跡を消そうとした作業が、 - かなりの割合で含まれています。 - そのため、ほとんどの攻撃者は裏口を作るのです。裏口は、 - 攻撃者がたやすくシステムへの - root - アクセスを再び得られるようにしますが、 - 有能な管理者に侵入を検知する便利な手段を与えるものでもあります。 - 攻撃者に裏口を作らせないようにするということは、 - セキュリティにとっては実際には良くないことかもしれません。 - なぜなら、 - 攻撃者が最初に見つけて侵入してきたセキュリティホールはふさがれないからです。 + 権限で実行されているサービスのバグの脆弱性を利用できるかもしれません。 + また、攻撃者は SUID-root + プログラムに存在するバグを知っているかもしれません。 + 攻撃者は、 + バックドアとして知られているプログラムを使って脆弱性なシステムを探したり、 + 修正されていない脆弱性を利用してアクセスしたり、 + 攻撃者による違法行為の痕跡を消そうとしたりするかもしれません。 セキュリティを改善する方法は、常に、 タマネギの皮のように階層化する手法 @@ -288,7 +243,7 @@ root の安全性を高める – root 権限で動作するサーバと - suid/sgid バイナリ。 + SUID/SGID バイナリ。 @@ -314,8 +269,7 @@ - 本章の次の節では、 - 上記の各項目についてより深く掘り下げていきます。 + 次の節では、上記の項目についてより深く掘り下げていきます。 @@ -326,60 +280,41 @@ &os; の安全性を高める - - コマンド対プロトコル - - この文書を通して、アプリケーションを指すのには - 太字 を使い、 - コマンドを指す場合には、等幅 フォントを使います。 - プロトコルは通常のフォントで表します。 - このような書体による区別は、 - プロトコルであると同時にコマンドでもある - ssh などに対して有効です。 - - - 以下の節では、本章の この節では、前節 でとりあげた &os; - システムの安全性を高める方法について述べます。 + システムの安全性を高める方法について説明します。 <systemitem class="username">root</systemitem> - アカウントとスタッフアカウントの安全性を高める + アカウントの安全性を高める - su + &man.su.1; - root - のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性をうんぬんしてもしかたがありません。 - ほとんどのシステムでは、root - アカウントに割り当てたパスワードが 1 - つあります。まず最初にすべきことは、 - このパスワードはいつでも不正利用の危険に晒されていると仮定することです。 - これは root - のパスワードを消すべきだと言っているのではありません。 + ほとんどのシステムでは、 root - のパスワードは、マシンにコンソールからアクセスするのには、 + アカウントに割り当てたパスワードが 1 つあります。 + このパスワードはいつでも不正利用の危険に晒されていると考えてください。 + これはパスワードを無効にすべきだと言っているのではありません。 + パスワードは、マシンにコンソールからアクセスするのには、 ほとんどいつでも必要なものです。 - ここで言いたいのは、コンソール以外からは、 - そして可能なら &man.su.1; コマンドを実行する場合も + しかしながら、コンソール以外からは、 + そして可能なら &man.su.1; + コマンドを実行する場合もパスワードを使えないようにするべきです。 + たとえば、/etc/ttys のエントリにおいて、 + 特定のターミナルに対し root - のパスワードを使えないようにするべきである、ということです。 - たとえば、あなたが使っている pty が、 - /etc/ttys ファイルで insecure - と指定されているか確認してください。そうすると、 - telnet や rlogin 経由では + でログインできないように + insecure と設定してください。 + &os; では、デフォルトで、 + /etc/ssh/sshd_config において + PermitRootLogin が no + と設定されているので、&man.ssh.1; を使った root - で直接ログインできないようになります。 - これは、/etc/ssh/sshd_config を編集して - PermitRootLogin に no - が設定されるようにすることで実現できます。 - sshd のような、 - 別のログインサービスを使っている場合でも同様に、直接 - root - へログインすることを許していないかどうか確認してください。 - すべてのアクセス手段 — たとえば FTP - のようなサービスが、良くクラックの対象となることを考えましょう。 + へログインは無効になっています。 + すべてのアクセス手段、たとえば FTP + ようなサービスは、良くクラックの対象となることを理解してください。 root への直接ログインは、 システムコンソール経由でのみ可能であるべきなのです。 @@ -387,57 +322,34 @@ wheel - また当然、システム管理者として自分が + システム管理者は root - になれるようにしておく必要がありますから、 - そのための穴をいくつか開けておきます。 - しかし、それらの穴を動作させるには、 - さらに追加のパスワード認証が必要であるようにしておくことが重要です。 - root - でアクセス可能とする方法の一つとして、適切なスタッフアカウントを - (/etc/group 中の) + になれるようにしておく必要があるので、 + 追加のパスワード認証の設定が必要となります。 + ひとつは、適切なユーザアカウントを + /etc/group 中の + wheel に加える方法です。 wheel - グループに加えることがあります。 - wheel - グループに入っているスタッフメンバは - su を使って + のメンバは、&man.su.1; を使って root になることが許されます。 - パスワードエントリにおいて、スタッフメンバを - wheel - グループに置くことによって直接 - wheel - 権限を与えてはいけません。スタッフメンバのアカウントは - staff - グループに所属させるべきで、その上で - /etc/group ファイルを通して - wheel - グループに加えるべきです。実際に + 実際に root - アクセスの必要なスタッフメンバのみ + アクセスの必要なユーザのみ wheel - グループに置くようにすべきです。 - 他の認証方法の場合、たとえば Kerberos を使用する場合には、 - root アカウントの - Kerberos .k5login ファイルを使えば、誰も - wheel グループに置く必要なく - root に &man.ksu.1; - することを許可できます。 - このやり方はよりよい解決策なのかもしれません。なぜなら、 - wheel のメカニズムでは、 - 侵入者がパスワードファイルを手に入れ、スタッフアカウントのいずれか - 1 つを破ることができると、 + に置くようにすべきです。 + Kerberos を使用して認証行う場合には、 root - を破ることがまだできてしまうからです。 - wheel - のメカニズムを用いる方が、何もしないよりは良いのですが、 - 必ずしも最も安全な選択肢とは限りません。 + のホームディレクトリに .k5login + を作成することで、 + 誰も wheel に置く必要なく + &man.ksu.1; することを許可できます。 アカウントを完全にロックするには、 - &man.pw.8; コマンドを使うべきです。 + &man.pw.8; を使ってください。 &prompt.root; pw lock staff - これにより、ユーザは、&man.ssh.1; + これにより、指定されたユーザは、&man.ssh.1; を含むいかなる方法でもログインできなくなります。 アカウントへのアクセスをブロックするもう一つの方法は、 @@ -445,16 +357,16 @@ * 1 文字に置き換えることです。 この文字は、暗号化されたパスワードにマッチすることはないので、 ユーザアクセスをブロックします。 - たとえば、次のスタッフアカウントを、 + たとえば、次のアカウントのエントリを、 foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - こう変更します。 + &man.vipw.8; を使って以下のように変更します。 foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh この変更によって - foobar ユーザは、 + foobar は、 通常のログインはできなくなります。 このようなアクセス制限をした後は、 サイトで Kerberos をセットアップしたり、 @@ -463,169 +375,68 @@ これらのセキュリティの仕組みでは、 制限の強いサーバから制限の弱いサーバへログインすることを前提としています。 - たとえば、メインマシンで、様々な種類のサーバを実行させている場合、 - ワークステーションではそれらのサーバを実行させてはなりません。 + たとえば、サーバがネットワークサービスを実行させている場合、 + ワークステーションではそれらのサービスを実行させてはなりません。 ワークステーションを十分に安全にしておくためには、 - 実行するサーバの数を、 - 一つもサーバが実行されていないというくらいにまでできる限り減らすべきです。 - また、パスワードで保護されたスクリーンセーバを走らせておくべきです。 - ワークステーションへの物理的アクセスが与えられたとすると、 + 実行するサービスをゼロにするか、可能な限り減らし、 + パスワードで保護されたスクリーンセーバを走らせておくべきです。 + システムへの物理的アクセスが与えられたとすると、 もちろん言うまでもなく、 - 攻撃者は管理者が設定したいかなる種類のセキュリティをもうち破ることができるのです。 - このことは、管理者として必ず考えておかねばならない問題ですが、 - システム破りの大多数は、ネットワーク経由でリモートから、 - ワークステーションやサーバへの物理的アクセス手段を持たない人々によって行われるという事実もまた、 - 念頭に置いておく必要があります。 + 攻撃者はいかなる種類のセキュリティをもうち破ることができるのです。 + 幸いにも、システム破りの大多数は、ネットワーク経由でリモートから、 + システムへの物理的アクセス手段を持たない人々によって行われています。 - Kerberos のような方法を使うことで、 - スタッフアカウントのパスワードの変更もしくは停止を一箇所で行なうことと、 - スタッフメンバがアカウントを持つすべてのマシンに即時にその効果を及ぼすことが可能となります。 - スタッフメンバのアカウントが危険に晒されたときに、 - すべてのマシンでスタッフメンバのパスワードを即座に変更する能力を過小評価してはいけません。 - パスワードが分散されている状況では、 - N 台のマシンでパスワードを変更すると、 - てんやわんやの事態を招く可能性があります。 - Kerberos を使用すると、パスワードの再発行に制限 - (re-passwording restriction) を課することもできます。 - この機能を使うことにより、ある Kerberos - チケットをしばらく経つとタイムアウトにすることができるだけでなく、 - 一定期間 (例えば、1 ヶ月に 1 回) 経つと、 - ユーザに新しいパスワードを選ぶように要求することもできます。 + Kerberos を使うことで、 + ユーザのパスワードの変更もしくは停止を一箇所で行なうことと、 + ユーザがアカウントを持つすべてのマシンに即時にその効果を及ぼすことが可能となります。 + アカウントが危険に晒されたときに、 + すべてのマシン上の関連するパスワードを即座に変更する能力を過小評価してはいけません。 + Kerberos では、Kerberos チケットにタイムアウトを設定でき、 + 設定した期間が経過するとユーザに新しいパスワードを選ぶように要求するといった追加の制限を課することができます。 root 権限で実行されているサーバと SUID/SGID バイナリの安全性を高める - - ntalk - - - comsat - - - finger - 砂場 (sandbox) - sshd - - - telnetd - - - rshd - - - rlogind + &man.sshd.8; - 用心深いシステム管理者は、 - 自分に必要なサーバプロセスだけを過不足なく実行させるものです。 + 用心深いシステム管理者は、必要なサービスだけを有効にし、 サードパーティ製のサーバは、 - よくバグを持っていがちだということに注意して下さい。 - たとえば、古いバージョンの - imapd や - popper - を実行させておくのは、全世界に万能の + よくバグを持っていがちだということに注意しているものです。 + 注意深くチェックしていないサーバは、決して実行してはいけません。 + 多くのデーモンは、サービス専用のアカウント、もしくは + 砂場 (sandbox) で起動させることができるので、 root - の切符を与えているようなものです。 - 自分で注意深くチェックしていないサーバは、 - 決して実行してはいけません。 - root - で実行させる必要のあるサーバはほとんどありません。たとえば、 - ntalk, - comsat, - finger デーモンを、 - 専用ユーザの 砂場 (sandbox) - で実行させることができます。 - 管理者が膨大な数の問題を経験していないのなら、 - この「砂場」は完璧ではありませんが、 - セキュリティに関するタマネギ的アプローチはここでも成り立ちます。 - 砂場で実行されているサーバプロセスを経由して侵入を果たすことができたとしても、 - 攻撃者はさらに砂場から外に脱出しなければなりません。 - 攻撃者が通過せねばならない層の数が増えれば増えるほど、 - それだけ攻撃者が侵入に成功する確率が減ります。 - Root の抜け穴は歴史的に、基本システムサーバも含め、 - root - 権限で実行されるほとんどすべてのサーバプロセスで発見されています。 - ユーザが sshd 経由でのみログインし、 - telnetd, - rshd, - rlogind - 経由でログインすることが決してないマシンを稼働させているのであれば、 - それらのサービスを停止させて下さい! + 権限でサービスを実行する前には、よく考えてください。 + &man.telnetd.8; または &man.rlogind.8; + のような安全ではないサービスは有効にしないでください。 - &os; では、今では - ntalkd, - comsat, - finger - は砂場で実行させることがデフォルトになっています。 - 次に砂場で実行させるべきプログラムの候補として、 - &man.named.8; があります。 - /etc/defaults/rc.conf ファイルには、 - named - を砂場で実行するために必要な引数がコメントアウトされた形式で含まれています。 - 新しいシステムをインストールしているか、 - それとも既存のシステムをアップグレードして使っているかに依存しますが、 - 砂場として使用する特別のユーザアカウントがインストールされていないかもしれません。 - 用心深いシステム管理者であれば、できるだけいつでも研究を怠らず、 - サーバに砂場を仕込むものでしょう。 - - - sendmail - - - 通常、砂場で実行しないサーバが他にいくつかあります。 - sendmail, - popper, - imapd, - ftpd などです。 - これらのうちいくつかのサーバには代わりとなるものがありますが、 - 代わりのものをインストールするには、 - あなたが思うより多くの仕事が必要になるかもしれません - (便利さという要素がまたも勝利を収めるわけです)。 - これらのサーバは、root - 権限で実行しなければばならないかもしれません。また、 - これらのサーバ経由で生じる侵入を検出するためには、 - 他の仕組みに頼らなくてはならないかもしれません。 - - システムの root - 権限の潜在的な穴で他に大きなものには、 - システムにインストールされた suid-root/sgid バイナリがあります。 + 他のシステムの潜在的なセキュリティホールには、 + 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 されたバイナリを破ることができた場合、 + システムデフォルトの SUID/SGID バイナリは比較的安全といえます。 + SUID バイナリは、 + スタッフのみがアクセス可能な特別なグループに制限し、 + 使わない SUID バイナリは削除することが推奨されます。 + SGID バイナリもほとんど同様の危険な存在になり得ます。 + 侵入者が kmem に SGID されたバイナリを破ることができた場合、 その侵入者は /dev/kmem を読み出すことができるようになるでしょう。つまり、 暗号化されたパスワードファイルを読み出すことができるようになるので、 - パスワードを持つどのアカウントをも、 - 潜在的な危険に晒すことになります。他にも、 + ユーザアカウントを、潜在的な危険に晒すことになります。他にも、 kmem グループを破った侵入者が pty を通して送られたキーストロークを監視できるという危険があります。 キーストロークには、安全な方法でログインするユーザが使っている pty @@ -642,16 +453,10 @@ ユーザアカウントの安全性を高める ユーザアカウントは、普通、安全性を高めることが最も困難です。 - スタッフに対しては、とても厳格なアクセス制限を強制しパスワードを - アスタリスク で外すことができるでしょうが、 - 管理者が持ちうる一般ユーザすべてのアカウントに対して同じことはできないかもしれません。 - 管理者が十分に統率をとることができるなら、管理者は勝利し、 - ユーザのアカウントの安全を適切に確保できるかもしれません。 - それができないならば、 - よりいっそう気を配って一般ユーザのアカウントを監視するよりほかありません。 - 一般ユーザアカウントに対し ssh や Kerberos を利用することには、 - システム管理がさらに増えたりテクニカルサポートが必要になるなどの問題があります。 - それでも、暗号化パスワードファイルと比較するとはるかに良い解です。 + 気を配ってユーザアカウントを監視するよりほかありません。 + ユーザアカウントに対し &man.ssh.1; や Kerberos を利用するには、 + システム管理がさらに増えたりテクニカルサポートが必要になりますが、 + 暗号化パスワードファイルと比較するとはるかに良い方法を提供します。 @@ -659,7 +464,7 @@ できるだけ多くのパスワードをアスタリスクで外し、 それらのアカウントのアクセスには - ssh や Kerberos を使うようにすることが、唯一の確実な方法です。 + &man.ssh.1; や Kerberos を使うようにすることが、唯一の確実な方法です。 暗号化パスワードファイル (/etc/spwd.db) は root @@ -667,90 +472,79 @@ たとえ、侵入者が root の書き込み権限は得られなくとも、 読み出しアクセス権限を得ることは可能かもしれません。 - セキュリティスクリプトで常にパスワードファイルの変更をチェッ - クし、報告するようにすべきです (ファイルの完全性のチェック - 節参照)。 + 節で説明されているように、 + セキュリティスクリプトでパスワードファイルの変更をチェックし、 + 報告するようにすべきです。 - カーネルのコア、raw デバイス、ファイルシステムの安全性を - 高める + カーネルのコア、raw デバイス、 + ファイルシステムの安全性を高める - root - の権限を破ると、攻撃者はほとんど何でもできますが、 - 特に重宝される特定の事柄もいくつかあります。 - たとえば、最近のカーネルは、組み込みのパケット覗き見デバイス + 最近のカーネルは、組み込みのパケット覗き見デバイス (packet sniffing device) ドライバを備えているものがほとんどです。 - &os; では bpf デバイスと呼ばれています。 - 侵入者は普通、 - 侵入済みのマシンでパケット覗き見プログラムを実行させようと試みます。 - 侵入者にわざわざそういう機能を提供する必要はないので、 - ほとんどのシステムで bpf - デバイスを組み込むべきではありません。 + &os; では bpf と呼ばれています。 + このデバイスは DHCP で必要となるため、 + DHCP を提供したり使う必要のないシステムでは、 + カスタムカーネルコンフィグレーションファイルから外すことができます。 - sysctl + &man.sysctl.8; - bpf デバイスを外しても、 - /dev/mem と - /dev/kmem - という悩みの種がまだ残っています。この問題に関しては、侵入者は - raw ディスクデバイスに書き込 - むこともできます。ほかにも、モジュールローダ、&man.kldload.8; - という、別のカーネル機能があります。やる気まんまんの侵入者は、KLD - モジュールを使って自分独自の bpf - もしくはその他覗き見デバイスを動作中のカーネルにインストールできます。 - この問題を避けるため、 - システム管理者はカーネルをより高いセキュアレベル、 - 少なくともセキュアレベル 1 で実行させる必要があります。 + bpf を外しても、 + /dev/mem および + /dev/kmem という問題がまだ残っています。 + 侵入者は raw ディスクデバイスに書き込むこともできます。 + やる気まんまんの侵入者は、&man.kldload.8; + を使って自分独自の bpf、 + もしくは他の覗き見デバイスを動作中のカーネルにインストールできます。 + この問題を避けるため、カーネルをより高いセキュリティレベル、 + 少なくともセキュリティレベル 1 で実行させる必要があります。 - カーネルのセキュアレベルはいくつかの方法で設定できます。 - 現在動いているカーネルのセキュアレベルを高める最も簡単な方法は、 - sysctl を使って - kern.securelevel - カーネル変数を操作する方法です。 + カーネルのセキュリティレベルはいくつかの方法で設定できます。 + 現在動いているカーネルのセキュリティレベルを高める最も簡単な方法は、 + kern.securelevel を設定する方法です。 &prompt.root; sysctl kern.securelevel=1 - デフォルトでは、&os; のカーネルはセキュアレベル -1 で起動します。 - このセキュアレベルは、管理者または &man.init.8; - による起動時のスクリプトにより変更されない限り -1 のままです。 - /etc/rc.conf ファイルで、 - kern_securelevel_enable 変数を - YES、 - kern_securelevel - 変数を必要とする値に設定することで、 - システム起動時にセキュアレベルを高めることができます。 - - &os; - システムの起動スクリプト実行直後のデフォルトのセキュアレベルは - -1 です。 - このセキュアレベルでは、 + デフォルトでは、&os; のカーネルはセキュリティレベル + -1 で起動します。 + このセキュリティレベルは、 変更不可のファイルフラグを外したり、 すべてのデバイスに対して読み込みおよび書き込みができたりするので、 - insecure mode と呼ばれます。 + insecure mode と呼ばれます。 + このセキュアレベルは、管理者または &man.init.8; + による起動時のスクリプトにより変更されない限り -1 のままです。 + /etc/rc.conf において、 + kern_securelevel_enable を + YES とし、 + kern_securelevel + に必要とする値を設定することで、 + システム起動時にセキュアレベルを高めることができます。 - セキュアレベルを 1 以上に設定すると、 + セキュリティレベルを 1 以上に設定すると、 追加専用および変更不可ファイルのフラグを外すことはできなくなり、 また raw デバイスへのアクセスが拒否されます。 より高いレベルに設定すると、より多くの操作に制限がかかります。 - 各セキュアレベルの完全な説明については、 - &man.security.7; マニュアルページをご覧ください。 + 各セキュリティレベルの完全な説明については、 + &man.security.7; および &man.init.8; をご覧ください。 - セキュアレベルを 1 以上に設定した場合には、 - X11 (/dev/io へのアクセスがブロックされます) - やソースから &os; を構築してインストールするとき - (installworld のプロセスでは、 - いくつかのファイルの追加専用および変更不可のフラグは一時的にリセットされます) - など、それ以外にも問題が引き起こされる可能性があります。 - X11 の問題については、 + セキュリティレベルを 1 以上に設定した場合には、 + /dev/io へのアクセスがブロックされるため、 + &xorg; や、 + installworld のプロセスでは、 + いくつかのファイルの追加専用および変更不可のフラグは一時的にリセットされるため、 + ソースから &os; + を構築してインストールするときなどで問題が引き起こされる可能性があります。 + &xorg; の問題については、 起動プロセス初期のセキュアレベルが十分低いときに &man.xdm.1; を起動することで、この問題に対応できます。 このような応急処置は、 - すべてのセキュアレベルやそれらが課す潜在的なすべての制限には対応できないでしょう。 + すべてのセキュリティレベルやそれらが課す潜在的なすべての制限には対応できないでしょう。 少し先を見越した計画的な対応をすべきです。 各セキュリティレベルで課される制限は、 システムを使用することによる利便性を著しく減らしてしまうため、 @@ -760,134 +554,122 @@ 設定に関する意外性を少なくできるでしょう。 - カーネルのセキュアレベルを 1 以上に設定した場合には、 + カーネルのセキュリティレベルを 1 以上に設定した場合には、 システム起動に関わる重要なバイナリやディレクトリ、 - スクリプトファイル (すなわち、 - セキュアレベルが設定されるまでの間に実行されるすべてのものに対して)、 + スクリプトファイル、そして、 + セキュリティレベルが設定されるまでの間に実行されるすべてのものに対して、 schg フラグを設定することは有用でしょう。 - この設定をやり過ぎても構いませんが、 - より高いセキュアレベルで動作している場合、 - システムのアップグレードがはるかに困難になります。 - システムをより高い安全レベルで実行させるようにするが、 - すべてのシステムファイルとディレクトリに schg + システムをより高いセキュリティレベルで実行させるようにするが、 + schg フラグを設定しないというところで妥協するという手もあります。 もう一つの可能性としては、単純に / および /usr を読み込み専用でマウントすることです。 ここで特筆すべきことは、システムを守ろうとして厳しくしすぎると、 - 侵入を検出するという非常に重要なことができなくなってしまうということです。 + 侵入を検出することができなくなってしまうということです。 - ファイルの完全性のチェック: バイナリ、 - 設定ファイルなど + ファイルの完全性のチェック - ことこの問題に至ると、システム管理者にできることは、 + システム管理者にできることは、 便利さという要素がその醜い頭を上げない程度に、 コアシステムの設定と制御ファイルを防御することだけです。 たとえば、/ および /usr にある大部分のファイルに schg - ビットを設定するために chflags + ビットを設定するために &man.chflags.1; を使用するのは、おそらく逆効果でしょう。 なぜなら、そうすることでファイルは保護できますが、 侵入を検出する窓を閉ざしてしまうことにもなるからです。 - セキュリティのタマネギの最後の層はおそらく最も重要なもの - — 検出です。 - セキュリティの残りのものは、突然の侵入を検出できなければ、 - まったく有用ではありません - (あるいは、もっと悪ければ、 - 安全性に対する間違った感覚を植え付けてしまいます)。 - タマネギの仕事の半分は、 + セキュリティ対策は、 + 侵入の可能性を検出できなければ、有用ではなく、 + もっと悪ければ、安全性に対する間違った感覚を植え付けてしまいます。 + セキュリティに対する仕事の半分は、 攻撃者を攻撃の最中に捕えるようにするために、 攻撃者を食い止めるのではなく侵入を遅らせることなのです。 侵入を検出する最も良い方法は、変更されていたり、 消えていたり、入れた覚えがないのに入っているファイルを探すことです。 変更されたファイルを探すのに最も良い方法は、もう一つの - (しばしば中央に集められた)、 + しばしば中央に集められた、 アクセスが制限されたシステムから行なうものです。 さらに安全でアクセス制限されたシステム上でセキュリティ用スクリプトを書けば、 スクリプトは潜在的な攻撃者からはほぼ見えなくなります。 - これは重要なことです。 - この有効性を最大限に活用するためには、一般的に、 - アクセスの制限されたマシンから実際に使っている他のマシンへのかなりのアクセスを許可する必要があります。 - 普通は、他のマシンからアクセス制限されたマシンへ読み込み専用の - NFS エクスポートをしたり、アクセス制限されたマシンから他のマシンへ - ssh 接続を行なうために、 - ssh 鍵のペアを作ったりすることで行います。 + この有効性を最大限に活用するためには、 + アクセスの制限されたマシンから他のマシンへのかなりのアクセスを許可する必要があります。 + 普通は、読み込み専用の NFS エクスポートをしたり、 + &man.ssh.1; 鍵のペアを設定したりします。 ネットワークのトラフィックを別にして、 - NFS は最も可視性のない方法です — - 各クライアント上のファイルシステムを、 + NFS は最も可視性のない方法です。 + 管理者は、各クライアント上のファイルシステムを、 事実上検出されずに監視できるようになります。 アクセス制限されたサーバがスイッチを通してクライアントに接続されている場合、 - たいてい NFS がより良い選択肢です。 - アクセス制限されたサーバがハブや、 + たいてい NFS がより良い選択肢です。 + アクセス制限されたサーバが、 いくつかのルーティング層を通してクライアントに接続している場合、 - NFS は (ネットワークの面で) あまりにも危険なので、 - ssh の方が認証を行った跡は残りますが、良い方法でしょう。 + NFS はあまりにも危険なので、 + &man.ssh.1; の方が良い方法でしょう。 アクセス制限されたマシンに、 監視しようとするクライアントシステムへの少なくとも読み込みのアクセス権を与えたら、 - 次に実際に監視するためのスクリプトを書かなくてはいけません。 - NFS マウントをすれば、&man.find.1; や &man.md5.1; + 次に監視するためのスクリプトを書かなくてはいけません。 + NFS マウントをすれば、&man.find.1; や &man.md5.1; などの単純なシステムユーティリティでスクリプトを書くことができます。 - 少なくとも 1 日 1 回、クライアントのファイルを直接 md5 にかけ、 + 少なくとも 1 日 1 回、クライアントのシステムファイルを直接 + &man.md5.1; にかけ、 さらにもっと頻繁に /etc および /usr/local/etc にあるようなコントロール用ファイルを試験するのが一番です。 アクセス制限されたマシンが正しいと知っている、 基となる md5 情報と比べて違いが見つかった場合、 - システム管理者に調べて欲しいと悲鳴を上げるようにすべきです。 + システム管理者に警告するようにすべきです。 優れたセキュリティ用スクリプトは、/ および /usr などのシステムパーティション上で不適当に - suid されたバイナリや、 + SUID されたバイナリや、 新たに作成されたファイルや削除されたファイルがないかどうかを調べるでしょう。 - NFS ではなく、ssh を使用する場合は、 - セキュリティ用スクリプトを書くのはずっと難しいことです。 - スクリプトを動かすためには、クライアントに対してスクリプトを - scp しなくてはいけませんし、 - それは目に見えてしまいます。 - そして、安全のためには、スクリプトが使うバイナリ (find など) を - scp する必要もあります。 - クライアントマシンの ssh + NFS ではなく、&man.ssh.1; を使用する場合は、 + セキュリティ用スクリプトを書くのはより難しいことです。 + たとえば、スクリプトを動かすためには、クライアントに対してスクリプトを + &man.scp.1; しなくてはいけませんし、 + クライアントマシンの &man.ssh.1; クライアントはすでに攻撃されてしまっているかもしれません。 - 結局のところ、安全でないリンク上の場合は - ssh は必要かもしれませんが、ssh - を扱うのはとても大変なことです。 + 安全でないリンク上の場合は + &man.ssh.1; は必要かもしれませんが、 + 扱いはとても大変になります。 優れたセキュリティ用スクリプトは、 - ユーザやスタッフメンバのアクセス設定ファイルの変更もチェックするものです。 - .rhosts, .shosts, - .ssh/authorized_keys など MD5 + .rhosts, + .ssh/authorized_keys + などの隠し設定ファイルの変更もチェックするものです。 + これらは MD5 チェックの範囲外になってしまうであろうファイル群です。 - ユーザ用のディスク容量が非常に大きい場合は、パーティション - 上の各ファイルを見て回るのに大変な時間がかかるかもしれません。 - この場合は、マウントフラグを設定して、 - suid されたバイナリを置けないようにするのが良い考えです。 - nosuid オプション - (&man.mount.8; 参照) が知るべきものでしょう。 - とにかく少なくとも週に 1 度はファイルシステムをスキャンするべきです。 - なぜなら、この層の目的は、侵入が成功したかどうかに関わらず、 + ユーザ用のディスク容量が非常に大きい場合は、 + パーティション上の各ファイルを見て回るのに大変な時間がかかるかもしれません。 + この場合は、&man.mount.8; により nosuid + を使うことで、マウントフラグを設定して、 + SUID されたバイナリを置けないようにするのが良い考えです。 + 少なくとも週に 1 度はファイルシステムをスキャンするべきです。 + なぜなら、目的は、侵入が成功したかどうかに関わらず、 不正侵入の試みがあったことの検出をすることだからです。 プロセスアカウンティング (&man.accton.8; 参照) は、 マシンへの侵入を検出するためのメカニズムとして推奨できる、 - 比較的オーバヘッドの少ないオペレーティングシステムの機能です。 + 比較的オーバヘッドの少ない &os; の機能です。 侵入を受けた後でも当該ファイルが無傷である場合に、 - 侵入者が実際にどのようにしてシステムに侵入したかを追跡するのに特に役立ちます。 + 侵入者がどのようにしてシステムに侵入したかを追跡するのに特に役立ちます。 最後に、 セキュリティスクリプトはログファイルを処理するようにし、 - ログファイル自体もできるだけ安全性の高い方法で生成するようにすべきです - — リモート syslog は極めて有益になり得ます。 + ログファイル自体もできるだけ安全性の高い方法で生成するようにし、 + リモートの syslog サーバに送信するようにすべきです。 侵入者は自分の侵入の痕跡を覆い隠そうとしますし、また、 ログファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆくために極めて重要です。 ログファイルを永久に残しておくための 1 つの方法は、 @@ -905,10 +687,9 @@ 便利さに影響を与えるセキュリティ機能を追加することもできます。 より重要なことは、 セキュリティ管理者はこれを多少混ぜこぜにして使うべきだということです。 - — もしあなたが、 - 本文書に書かれている勧告をそのまま使用した場合は、 - 予想される攻撃者はやはり本文書を読んでいるわけですから、 - あなたの防御策を教えてしまうことになります。 + もしこの章で書かれている推奨される方法をそのまま使用した場合は、 + 予想される攻撃者はやはりこの文書を読んでいるわけですから、 + 防御策を教えてしまうことになります。 @@ -918,8 +699,7 @@ サービス妨害 (DoS) - このセクションではサービス妨害攻撃 (DoS 攻撃) を扱います。 - サービス妨害攻撃は、普通は、パケット攻撃です。 + DoS 攻撃は、普通は、パケット攻撃です。 ネットワークを飽和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシステム管理者が打てる手はそれほど多くありませんが、 一般的に、以下のような方法により、 @@ -932,7 +712,7 @@ - 踏み台攻撃の制限 (ICMP 応答攻撃、ping broadcast など)。 + ICMP 応答攻撃、ping broadcast などの踏み台攻撃の制限。 @@ -940,148 +720,120 @@ - よくあるサービス妨害攻撃は、fork + よくある DoS 攻撃は、fork するサーバに対して攻撃するもので、 多くの子プロセスを起動させることにより、 メモリ、ファイル記述子などを使いつくし、 ホストシステムを最終的に停止させます。 - inetd (&man.inetd.8; 参照) には、 + &man.inetd.8; には、 この種の攻撃を制限するオプションがいくつかあります。 マシンがダウンすることを防止することは可能ですが、 この種の攻撃によりサービスが中断することを防止することは一般的に言ってできないことに注意する必要があります。 - inetd - のマニュアルページを注意深く読んで下さい。特に、 + &man.inetd.8; を注意深く読んで下さい。特に、 , , - オプションに注意して下さい。IP 偽造攻撃 (spoofed-IP attack) は - inetd の - オプションの裏をかけるので、 - 一般にオプションを組み合わせて使用するべきであることに注意して下さい。 + に注意して下さい。IP 偽造攻撃 (spoofed-IP attack) は + &man.inetd.8; の の裏をかけるので、 + 一般にオプションを組み合わせて使用すべきです。 スタンドアロンサーバの中には、自分自身で fork を制限するパラメータを持っているものがあります。 Sendmail には、 - オプションがあります。 + があります。 システム負荷の値変化には遅れがあるので、 Sendmail の負荷限界指定オプションを使うよりも、 このオプションを使う方がまともに動作する可能性ははるかに高いです。 - sendmail の実行を開始する際に、 - MaxDaemonChildren - パラメータを設定するべきです。 - その値は、通常見込まれる負荷を扱える程度に十分高いが、 - それだけの数の Sendmail - インスタンスを操作しようとするとマシンが卒倒してしまうほどには高くないような値に設定するべきです。 - Sendmail をキュー処理モード - () で実行することや、 - sendmail デーモン (sendmail -bd) + Sendmail を開始する際は、 + 通常見込まれる負荷を扱える程度に十分高いが、 + コンピュータが操作できない数の Sendmail + インスタンスの値よりは低い値に + MaxDaemonChildren を設定してください。 + Sendmail を + を使って、 + キュー処理モードで実行したり、 + デーモン (sendmail -bd) をキュー処理用プロセス (sendmail -q15m) と別に実行することも、用心深いことと言えます。 - それでもなおリアルタイムでの配送を望むのであれば、 + リアルタイムでの配送を望むのであれば、 のようにすることで、 キュー処理をはるかに短い時間間隔で行うことができます。 いずれにしても、MaxDaemonChildren - オプションに合理的な値を確実に指定して、 - Sendmail - がなだれをうって失敗することがないようにして下さい。 + に合理的な値を確実に指定して、 + なだれをうって失敗することがないようにして下さい。 - syslogd + &man.syslogd.8; は直接攻撃される可能性があるので、可能ならばいつでも - オプションを用いることを強く推奨します。 + を用いることを強く推奨します。 これができないなら、 - オプションを使って下さい。 + を使って下さい。 - TCP Wrapper の逆 identd - などの接続返し (connect-back) - を行うサービスについては十分注意を払うようにするべきです。 - これらは直接攻撃を受ける可能性があります。 + 逆 identd などの接続返し (connect-back) + を行うサービスについては直接攻撃を受ける可能性があるので、 + 十分注意を払うようにするべきです。 こういう事情があるので、TCP wrapper - の逆 ident 機能を使おうとは思わないのが一般的です。 + の逆 ident 機能を使うことは推奨されません。 境界ルータのところでファイアウォールを設けて、 - 外部からのアクセスに対して内部サービスを防御するという考えは実によいものです。 - この考えは、LAN の外部からの飽和攻撃を防ぐことにあり、 + 外部からのアクセスに対して内部サービスを防御することは推奨されます。 + これは、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 - より下のすべてのポートをブロックするという設定が考えられます。 + ファイアウォールは、デフォルトではすべての通信を禁止し、 + 許可する通信のみを明示して設定するように、常に排他的に設定して下さい。 + &os; では、net.inet.ip.portrange + &man.sysctl.8; 変数により、 + 動的バインドに使用されるポート番号の範囲を制御できます。 - また別のよくあるサービス妨害攻撃として、踏み台攻撃 - (springboard attack) と呼ばれるものがあります — これは、 - あるサーバを攻撃し、そこ結果として生成される応答が自分自身、 + また別のよくある DoS 攻撃として、 + 踏み台攻撃と呼ばれるものがあります。これは、 + あるサーバを攻撃し、その結果として生成される応答がサーバ自身、 ローカルネットワーク、 - そして他のマシンを過負荷に追い込むようにする攻撃です。 + もしくは他のマシンを過負荷に追い込むようにする攻撃です。 この種の攻撃の中で最もありふれたものに、 ICMP ping broadcast 攻撃があります。 - 攻撃者は、実際に攻撃したいマシンのアドレスを送信元アドレスに設定した + 攻撃者は、攻撃するマシンのアドレスを送信元アドレスに設定した ping パケットを偽造して、対象の LAN のブロードキャストアドレスに向けてパケットを送信します。 境界にあるルータがブロードキャストアドレスに対する - ping パケットを握り潰すように設定されていない場合、LAN は、 - 詐称された送信元アドレスに向けて応答パケットを生成するはめになり、 - 犠牲となるマシンが飽和するところまで行ってしまいます。 - 攻撃者が同じトリックを異なるネットワーク上のいくつものブロードキャストアドレスに対して同時に使用した場合、 - とくにひどいことになります。これまでに、120 - メガビット以上のブロードキャスト攻撃が観測されています。 - 2 番目の踏み台攻撃は、ICMP エラー報告の仕掛けを狙うものです。 - 攻撃者は ICMP エラー応答を生成するパケットを生成し、 - サーバの受信ネットワークを飽和させ、 + ping パケットをドロップするように設定されていない場合、LAN は、 + 詐称された送信元アドレスに向けて、 + 犠牲となるマシンが飽和するまで応答パケットを生成します。 + 異なるネットワーク上のいくつものブロードキャストアドレスに対して同時に攻撃する場合には、 + とくにひどいことになります。 + 2 番目の踏み台攻撃は、 + サーバの受信ネットワークを飽和させるような + ICMP エラー応答を生成するパケットを生成し、 その結果としてサーバが送信ネットワークを ICMP - 応答で飽和させてしまうようにすることができます。 + 応答で飽和させてしまう攻撃です。 メモリを消費し尽くさせることにより、 - この種の攻撃でサーバをクラッシュさせることも可能です。 + この種の攻撃でサーバをクラッシュさせることが可能です。 サーバが生成した ICMP 応答を十分速く送信できない場合、 とくにひどいことになります。 この種の攻撃の効果を抑制するには、 - sysctl 変数の - net.inet.icmp.icmplim + &man.sysctl.8; 変数の net.inet.icmp.icmplim を使ってください。 踏み台攻撃の 3 つめの主要なクラスに属する攻撃は、 - udp echo サービスのような、特定の inetd + UDP echo サービスのような、特定の &man.inetd.8; 内部サービスに関連するものです。 - 攻撃者は、単に送信元アドレスがサーバ A の echo + 攻撃者は、送信元アドレスがサーバ A の echo ポートであり、送信先アドレスがサーバ B の echo ポートであるように UDP パケットを偽造します。 - ここでサーバ A, B はともにあなたの + ここでサーバ A, B はともに同じ LAN に接続されています。この 2 つのサーバは、 この一つのパケットを両者の間で互いに相手に対して打ち返しあいます。 - このようにしてパケットをほんのいくつか注入するだけで、 - 攻撃者は両方のサーバと LAN を過負荷状態にすることができます。 - 同様の問題が内部 chargen + 攻撃者は、このようなパケットをほんのいくつか注入するだけで、 + 両方のサーバと LAN を過負荷状態にすることができます。 + 同様の問題が chargen ポートにも存在します。 - 有能なシステム管理者はこの手の - inetd 内部テストサービスのすべてを無効にしておくものです。 + この手の inetd 内部テストサービスは無効にしてください。 偽造パケット攻撃は、 カーネルの経路情報キャッシュに過負荷を生じさせるために用いられることもあります。 net.inet.ip.rtexpire, rtminexpire, rtmaxcache - の sysctl パラメータを参照して下さい。 + の &man.sysctl.8; パラメータを参照して下さい。 でたらめな送信元 IP アドレスを用いた偽造パケット攻撃により、 カーネルは、一時的なキャッシュ経路を経路情報テーブルに生成します。 これは netstat -rna | fgrep W3 @@ -1090,13 +842,13 @@ カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを検知すると、 カーネルは動的に rtexpire を減らしますが、rtminexpire - より小さくなるようには決して減らしません。ここに問題が - 2 つあります。 + より小さくなるようには決して減らしません。 + これにより 2 つの問題が引き起こされます。 - 負荷の軽いサーバが突然攻撃された場合、カーネルが十分素 - 早く反応できないこと。 + 負荷の軽いサーバが突然攻撃された場合、 + カーネルが十分素早く反応できないこと。 @@ -1105,59 +857,55 @@ - 自分のサーバが T3 + サーバが T3 もしくはそれより高速の回線でインターネットに接続されている場合、 &man.sysctl.8; を用いて rtexpire と rtminexpire - とを手動で上書きしておくことが思慮深いことといえます。 - どちらか一方でも 0 には決してしないで下さい - (自分のマシンをクラッシュさせたくないのであれば)。 + を手動で上書きしておくことが思慮深いことといえます。 + ただし、どちらか一方でも 0 には決してしないで下さい。 + コンピュータをクラッシュさせてしまうことになります。 両パラメータを 2 秒に設定すれば、 攻撃から経路情報テーブルを守るには十分でしょう。 - Kerberos および SSH を用いたアクセスの問題 + Kerberos および &man.ssh.1; を用いたアクセスの問題 - ssh + &man.ssh.1; - もしあなたが、Kerberos と ssh を使いたいのだとしたら、 + もし、Kerberos と &man.ssh.1; を使いたいのだとしたら、 両者に関して言っておかねばならない問題がいくつかあります。 - Kerberos 5 は大変優れた認証プロトコルですが、Kerberos 化された - telnet や - rlogin は、 + Kerberos は大変優れた認証プロトコルですが、Kerberos 化された + &man.telnet.1; および &man.rlogin.1; には、 バイナリストリームを扱うのに不向きになってしまうようなバグがあります。 - さらに、デフォルトでは、Kerberos は - オプションを使わない限りセッションを暗号化してくれません。 - Ssh では、 + デフォルトでは、Kerberos は + を使わない限りセッションを暗号化してくれません。 + 一方 &man.ssh.1; では、 デフォルトですべてを暗号化してくれます。 - ssh はあらゆる場面でとても良く働いてくれます。 - ただし、デフォルトで暗号鍵を転送してしまうことを除けばです。 - これはつまり、暗号鍵を持った安全なワークステーションがあって、 - この暗号鍵で残りのシステムとアクセスできるようになっている場合に、 - 安全でないマシンへ - ssh 接続を行なうとあなたの暗号鍵を使えてしまうということです。 - 実際の鍵そのものが見えてしまうわけではありませんが、 - ssh はあなたが login している間、転送用ポートを作ります。 + &man.ssh.1; はとても良く働いてくれますが、 + デフォルトで暗号鍵を転送してしまいます。 + これは、安全なワークステーションから、 + 安全でないマシンへのアクセスに + &man.ssh.1; を使っているユーザにセキュリティリスクを引き起こします。 + 鍵そのものが見えてしまうわけではありませんが、 + &man.ssh.1; は login している間、転送用ポートを作ります。 攻撃者が安全でないマシンの root を破ったら、 - このポートを使って暗号鍵を取得し、 + このポートを使って、 この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。 - スタッフのログインには、Kerberos を組み合せた - ssh を使用することを勧めます。 - Ssh は、Kerberos - 対応機能と一緒にコンパイルできます。 + 可能な時はいつでも、スタッフのログインには Kerberos を組み合せた + &man.ssh.1; を使用することを勧めます。 + &man.ssh.1; は、Kerberos 対応機能と一緒にコンパイルできます。 こうすると、見えてしまうかもしれない - ssh 鍵をあまりあてにしないで良いようになります。 - また、それと同時に、Kerberos 経由でパスワードを保護することもできます。 - ssh 鍵は、安全なマシンからの自動化されたタスク - (Kerberos はこの用途には不向きです) のみに使用するべきです。また、 - ssh の設定で鍵転送をしないようにするか、あるいは ssh が - authorized_keys - ファイル中に書くことを許している from=IP/DOMAIN - オプションを使用して、 + SSH 鍵をあまりあてにしないで良いようになり、 + 一方で、Kerberos 経由でパスワードが保護されます。 + 鍵は、安全なマシンからの自動化されたタスクのみに使用するべきです。 + Kerberos はこの用途には不向きです。 + また、SSH の設定で鍵転送をしないようにするか、 + あるいは authorized_keys + の from=IP/DOMAIN を使用して、 特定のマシンからログインしてきたときのみ鍵が有効であるようにすることも勧めます。 @@ -1194,65 +942,50 @@ &unix; システムにおけるすべてのユーザは、 そのアカウントに対応した一つのパスワードを持っています。 - それらのパスワードはユーザ本人と本当のオペレーティングシステムのみが知っているべきであるということは明らかでしょう。 それらのパスワードを秘密に保っておくために、 パスワードは 一方向ハッシュ として知られる方式で暗号化されます。 - 一方向ハッシュとは、簡単に暗号化はできるが解読は難しいという方法です。 - 言葉を換えると、 - 先ほど明らかであると書いたのは実は正しくないのです: - オペレーティングシステム自身は - 本当は パスワードを知らないのです。 + 一方向ハッシュとは、 + 簡単に暗号化はできるが解読は難しいという方法です。 + オペレーティングシステム自身はパスワードを知りません。 その代わりに 暗号化された 形でのみパスワードを知っています。 素のテキスト としてパスワードを得る唯一の方法は、 可能な限りのパスワード空間を検索するという力任せの方法です。 - 不幸なことに、&unix; - が生まれようとしているときにパスワードを安全な形で暗号化できる方式は - DES (Data Encryption Standard) に基づいたものだけでした。 - このことは米国に住んでいるユーザにとっては大して問題ではありませんでしたが、 - DES のソースコードを米国外に輸出することはできないという問題がありました。 - そのために、&os; は、米国の法律を守ることと、 - 未だに DES を使っていた他の &unix; - 一族との互換性を保つこととを両立する方法を探し出す必要がありました。 - - その解決方法は、米国のユーザは DES - のライブラリをインストールして DES を使用できるが、 - 米国外のユーザは国外に輸出可能な他のひとつの暗号化方式を使用することができる、 - というように暗号化ライブラリを分割することでした。 - これが &os; がデフォルトの暗号化方式として MD5 - を使うようになったいきさつです。MD5 は DES - よりもより安全であると考えられているため、DES - をインストールする一番の理由は互換性を保つためといえます。 + 元々、&unix; においてパスワードを安全な形で暗号化できる方式は + Data Encryption Standard (DES) + に基づいたものだけでした。DES + のソースコードを米国外に輸出することはできないという問題があったため、 + &os; は、米国の法律を守ることと、 + 未だに DES を使っていた他の &unix; + 一族との互換性を保つこととを両立する方法を探し出す必要がありました。 + その解決方法は、DES + よりも安全であると考えられている MD5 を使うことでした。 暗号化機構を理解する - 現在では、ライブラリは DES, MD5, Blowfish, SHA256 および - SHA512 ハッシュ関数に対応しています。 - デフォルトで、&os; 9.1 以降では、 - SHA512 を使ってパスワードを暗号化します。 - 古いバージョンでは、パスワードの暗号化に - MD5 をデフォルトで利用していました。 - - &os; - がどの暗号化方式を使うようにセットアップされているかを判断するのは簡単です。 + 現在では、ライブラリは DES, + MD5, Blowfish, SHA256 および + SHA512 ハッシュ関数に対応しています。&os; + がどの暗号化方式を使うようにセットアップされているかを判断するには、 /etc/master.passwd - ファイルの中の暗号化されたパスワードを調べてみるのが一つの方法です。 - MD5 ハッシュで暗号化されたパスワードは、DES + の暗号化されたパスワードを調べてください。 + MD5 ハッシュで暗号化されたパスワードは、DES ハッシュで暗号化されたパスワードよりも長く、 $1$ という文字で始まるという特徴を持っています。 $2a$ で始まるパスワードは、Blowfish ハッシュ関数で暗号化されています。 - DES のパスワードはこれといって識別可能な特徴は持っていませんが、 + DES + のパスワードはこれといって識別可能な特徴は持っていませんが、 MD5 のパスワードよりは短く、そして $ という文字を含まない 64 文字のアルファベットを使って表現されているので、 比較的短い文字列でドル記号で始まっていないものはおそらく - DES のパスワードでしょう。 - SHA256 と SHA256 の場合は、$6$ + DES のパスワードでしょう。 + SHA256 と SHA512 の場合は、$6$ から始まります。 新規パスワードがどちらのパスワード形式になるかは、 @@ -1264,7 +997,7 @@ blf, sha256 または sha512 を設定することができます。 ログインケーパビリティに関するより詳細な情報は、 - &man.login.conf.5; マニュアルページをご覧ください。 + &man.login.conf.5; をご覧ください。 @@ -1278,58 +1011,47 @@ デフォルトで、&os; は - OPIE (One-time Passwords In Everything) に対応しています。 + One-time Passwords In Everything (OPIE) + に対応しています。 OPIE はデフォルトでは MD5 ハッシュを使用します。 - ここでは、三種類の異なる「パスワード」について説明します。 - まず一つ目は、あなたが普段使っている普通の - &unix; スタイルの、もしくは Kerberos - のパスワードです。ここではこれを - &unix; パスワード と呼ぶことにします。 - 二つ目は、OPIE の &man.opiekey.1; プログラムによって生成され、 + 三種類の異なる「パスワード」があります。 + まず一つ目は、通常の &unix; スタイル、もしくは Kerberos + のパスワードです。 + 二つ目は、&man.opiekey.1; によって生成され、 &man.opiepasswd.1; - プログラムとログインプロンプトが受け付けるパスワードです。 - ここではこれを ワンタイムパスワード - と呼ぶことにします。三つ目のパスワードは、 - opiekey (と場合により - opiepasswd) - プログラムに対してユーザが入力する秘密のパスワードで、 - ワンタイムパスワードを生成するのに使われます。ここではこれを - 秘密のパスフレーズ もしくは単に - パスフレーズ と呼ぶことにします。 - (訳注: ユーザが頭の中だけにしまっておくべきものが、 - この秘密のパスフレーズです。なお、原文ではこれを - password と表記していますが、 - 混乱を避けるために訳文ではすべて - 秘密のパスフレーズ に統一しています)。 + およびログインプロンプトが受け付けるワンタイムパスワードです。 + 三つ目のパスワードは、&man.opiekey.1; と場合により + opiepasswd + に対してワンタイムパスワードを生成するのに使われる + 秘密のパスワード です。 - 秘密のパスフレーズは、&unix; + 秘密のパスワードは、&unix; パスワードと何の関連性もありません。 両者を同一に設定することは可能ですが、お奨めしません。古い &unix; パスワードは長さが 8 文字に制限されていました &os; では、標準のログインパスワードは、128 文字までとなります。。 - これに対し、OPIE - では秘密のパスフレーズを好きなだけ長くすることができます - (訳注: 実装上、key コマンドなどの - バッファ長で制限されてしまう可能性があります。200 文字程度に押 - えておいた方がよいでしょう :-)。 + これに対し、OPIE + の秘密のパスワードには 8 文字の制限はありません。 6 語から 7 語からなるパスフレーズがふつうです。ほとんどの部分で、 - OPIE システムは &unix; + OPIE システムは &unix; のパスワードシステムと完全に独立して動作するようになっています。 - パスフレーズに加え、OPIE + パスフレーズに加え、OPIE システムにとって重要な 2 種類のデータがあります。一つは シード (seed: 種) または キー (key: 鍵) と呼ばれるもので、2 つの文字と 5 つの数字で構成されます。もう一つは シーケンス番号 - (iteration count) で、1 から 100 までの整数です。OPIE + (iteration count) で、1 から 100 までの整数です。 + OPIE はここまでに述べたデータを利用してワンタイムパスワードを生成します。 その方法は、まずシードと秘密のパスフレーズを連結し、 それに対してシーケンス番号の回数だけ MD5 ハッシュを繰り返し計算します。 そしてその結果を 6 つの短い英単語に変換します。 - 認証システム (一次的には PAM) - は、前回最後に受け付けたワンタイムパスワードを記録しています。 + この 6 つの英単語がワンタイムパスワードです。 + 認証システム (主は PAM) は、 + 前回最後に受け付けたワンタイムパスワードを記録しています。 そして、その前回のワンタイムパスワードと、 ユーザが入力したワンタイムパスワードを 1 回ハッシュ関数にかけた結果とが一致した場合に、 @@ -1340,38 +1062,36 @@ シーケンス番号はログインが成功するたびに一つずつ減らされて、 ユーザとログインプログラムの間で同期が取られます。 シーケンス番号が 1 まで減ったら、 - OPIE を再度初期化する必要があります。 + OPIE を再度初期化する必要があります。 - 次に、 - それぞれのシステムで関連するいくつかのプログラムについて説明します。 - opiekey プログラムは、シーケンス番号と、シードと、 + このプロセスに関連するいくつかのプログラムがあります。 + &man.opiekey.1; は、シーケンス番号と、シードと、 秘密のパスフレーズを受け付けて、ワンタイムパスワード 1 つ、 または一連のワンタイムパスワードの一覧を生成します。 - opiepasswd プログラムは、OPIE - を初期化するのに使用され、また秘密のパスフレーズ、 + &man.opiepasswd.1; は、OPIE + の初期化に加え、パスワード、 シーケンス番号やシードを変更するためにも使用されます。 このプログラムを実行するには、秘密のパスフレーズか、 または、シーケンス番号とシードとワンタイムパスワードの 1 組かの、どちらかを与えます。 - opieinfo プログラムは、 + &man.opieinfo.1; は、 認証ファイル (/etc/opiekeys) を調べて、 プログラムを起動したユーザの現在のシーケンス番号とシードを表示します。 - この文書では、4 種類の異なる操作について説明します。 - 1 つ目は、opiepasswd - を信頼できる通信路上で利用して、 + 4 種類の異なる操作があります。 + 1 つ目は、&man.opiepasswd.1; を信頼できる通信路上で利用して、 最初にワンタイムパスワードを設定したり、 秘密のパスフレーズやシードを変更する操作です。 2 つ目は、同じことを行うために - opiepasswd を信頼できない通信路上で利用する操作です。 - この場合は信頼できる通信路経由の opiekey - を併用します。3 つ目は、opiekey + &man.opiepasswd.1; を信頼できない通信路上で利用する操作です。 + この場合は信頼できる通信路経由の &man.opiekey.1; + を併用します。3 つ目は、&man.opiekey.1; を使い、信頼できない通信路を通じてログインする操作です。 - 4 番目は、opiekey + 4 番目は、&man.opiekey.1; を使って複数のワンタイムパスワードを一気に生成する操作です。 ここで生成した複数のワンタイムパスワードは、 メモしたり印刷したりして携帯し、 - 信頼できる通信路が一切ないところで利用することができます。 + 信頼できる通信路が一切ないところからの接続に利用できます。 (訳注: ワンタイムパスワードを記録した紙をなくさないこと! 電話番号や IP アドレス、ユーザ名を一緒にメモしていたら最悪です!!) @@ -1379,8 +1099,8 @@ 信頼できる通信路での初期化 - OPIE を初めて初期化するには、opiepasswd - コマンドを実行してください。 + OPIE を初めて初期化するには、 + &man.opiepasswd.1; を実行してください。 &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c @@ -1388,11 +1108,6 @@ 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: @@ -1403,18 +1118,16 @@ MOS MALL GOAT ARM AVID COED Enter new secret pass phrase: または Enter secret password: というプロンプトに対して、 - あなたが考えた秘密のパスフレーズを入力します。 - このパスフレーズはログインするときに使うものではなく、 - ログインするときに使うワンタイムパスワードを生成するために使うものであることを覚えておいてください。 + パスワードまたはパスフレーズを入力してください。 + このパスワードは、 + ログインするときに使うワンタイムパスワードを生成するために使うものであり、 + ログインのためのパスワードではありません。 ID から始まる行は、1 回分のパラメータで、 - あなたのログイン名とシーケンス番号とシードです。 - (訳注: keyinit コマンドは - 次回にログインするときに使えるパラメータを参考のためにここで表示します)。 - システムにログインするときには、 - システム側が自動的にこれらのパラメータを表示してくれますから、 + ログイン名とシーケンス番号とシードです。 + ログインするときには、 + システム側がこれらのパラメータを覚えていて表示してくれるので、 これらのパラメータを覚えておく必要はありません。 - 最後の行が、今述べたパラメータと入力された秘密のパスフレーズから計算されたワンタイムパスワードです。 - この例を実行した後、 + 最後の行が、今述べたパラメータと入力された秘密のパスワードから計算されたワンタイムパスワードです。 次にログインするときに打ち込むべきワンタイムパスワードがこれです。 @@ -1422,8 +1135,8 @@ MOS MALL GOAT ARM AVID COED 信頼できない通信路での初期化 信頼できない通信路を使って秘密のパスフレーズを初期化または変更するためには、 - それとは別に opiekey - プログラムを実行するための信頼できる通信路を用意しておく必要があります。 + &man.opiekey.1; + を実行するための信頼できる通信路を用意しておく必要があります。 たとえばそれは、 信頼できるマシンのシェルプロンプトだったりするでしょう。 (訳注: ここでの通信路とはマシンそのものになります。 @@ -1431,10 +1144,9 @@ MOS MALL GOAT ARM AVID COED 信頼できる人がしっかり管理しているマシンということです)。 他に準備しておくものとして、シーケンス番号 (100 は適切な値といえるでしょう) と、場合によっては自分で考えた、 - またはランダムに生成されたシードがあります。(あなたが - S/Key を初期化しようとしているマシンへの) - 信頼できない通信路を使うときには、opiepasswd - コマンドを以下のように使用します。 + またはランダムに生成されたシードがあります。 + 信頼できない通信路を使うときには、&man.opiepasswd.1; + を使ってコンピュータを初期化してください。 &prompt.user; opiepasswd @@ -1451,24 +1163,24 @@ 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. +Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT - ここで信頼できない通信路の方に戻って、 + 信頼できない通信路の方に戻って、 生成されたワンタイムパスワードをコピーして対応するプログラムに入力します。 ワンタイムパスワードを一つ生成する - OPIE を初期化したら、 + OPIE を初期化したら、 ログイン時には以下のようなプロンプトが出てくるでしょう。 &prompt.user; telnet example.com @@ -1482,23 +1194,23 @@ login: < otp-md5 498 gr4269 ext Password: - ここでは表示していませんが、OPIE + OPIE のプロンプトには便利な機能が備わっています。 - パスワードプロンプトに対して、何も入力せずに - Return を押すとエコーモードに切り替わります。 - つまりタイプした文字がそのまま見えるようになるのです。 + パスワードプロンプトに対して、 + Return を押すとエコーモードに切り替わり、 + タイプした文字がそのまま見えるようになるのです。 これは、 - 紙に印刷していたりするワンタイムパスワードを手で入力しなければならない場合に特に役立つ機能です。 + 紙に印刷していたりするワンタイムパスワードを手で入力しなければならない場合に役立つ機能です。 MS-DOS Windows MacOS 次に、 - このログインプロンプトに対して入力するワンタイムパスワードを生成しなければなりません。 - これは、opiekey + このログインプロンプトに対して入力するワンタイムパスワードを生成してください。 + これは、&man.opiekey.1; プログラムを使える信頼できるマシン上で行わなければなりません。 - (これらのプログラムには DOS や &windows;, &macos; 版があります)。 + このプログラムには &windows;, &macos; および &os; 版があります。 どちらも、 コマンドラインからシーケンス番号とシードを指定しなければなりません。 ログインしようとしているマシンのログインプロンプトから直接カットアンドペーストすると楽でしょう。 @@ -1507,27 +1219,26 @@ Password: &prompt.user; opiekey 498 to4268 Using the MD5 algorithm to compute response. -Reminder: Don't use opiekey from telnet or dial-in sessions. +Reminder: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT - ここでワンタイムパスワードが得られました。 - ログインを続けましょう。 + ワンタイムパスワードが生成されたので、 + ログインを続けてください。 複数のワンタイムパスワードを生成する 都合によっては、 - 信頼できるマシンや信頼できる通信路が一切確保できないようなところで - S/Key を使う必要があるでしょう。 - このような場合には、opiekey - コマンドを使って複数のワンタイムパスワードをあらかじめ一気に生成し、 - 紙に印刷して携帯していくことができます。たとえば + 信頼できるマシンや信頼できる通信路が一切確保できないようなことがあるでしょう。 + このような場合には、&man.opiekey.1; + を使って複数のワンタイムパスワードを生成できます。 + たとえば &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. +Reminder: Do not 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 @@ -1537,24 +1248,23 @@ Enter secret pass phrase: <secret password> という引数によって 5 個のワンタイムパスワードを順に生成します。 - ここで は、 - 最後のシーケンス番号となるべき数字です。出力は普通に使う順番とは + また は、 + 最後のシーケンス番号となるべき数字です。出力は使う順番とは 逆 に出力されていることに注意してください (訳注: 一番最初に使うワンタイムパスワードは一番最後に出力されたものです)。 - この結果をカットアンドペーストして - lpr コマンドを使って印刷するとよいでしょう。 もしあなたがセキュリティに偏執するなら、 この結果を紙と鉛筆を使って手で書き移した方がよいかもしれません。 + そうでなければ、この結果を印刷すると良いでしょう。 ここで、 出力の各行はシーケンス番号とそれに対応する一回分のワンタイムパスワードです。 - 消費済みのワンタイムパスワードの行をペンで消していくと便利でしょう。 + 消費済みのワンタイムパスワードをペンで消していってください。 &unix; パスワードの利用を制限する - OPIE は、ログインセッションの IP + OPIE は、ログインセッションの IP アドレスをベースとした &unix; パスワードの使用を制限できます。 関連ファイルは、/etc/opieaccess で、 デフォルトで用意されています。 @@ -1562,7 +1272,7 @@ Enter secret pass phrase: <secret password> このファイルを使用する際に考慮すべきセキュリィについては &man.opieaccess.5; を確認してください。 - 以下は opieaccess ファイルの例です。 + 以下は opieaccess の例です。 permit 192.168.0.0 255.255.0.0 @@ -1572,7 +1282,7 @@ Enter secret pass phrase: <secret password> もし opieaccess のどのルールにも一致しなければ、 - デフォルトでは非 OPIE ログインは使えません。 + デフォルトでは非 OPIE ログインは使えません。 @@ -1591,62 +1301,31 @@ Enter secret pass phrase: <secret password> TCP Wrappers - &man.inetd.8; に詳しい方であれば、 - TCP Wrappers について聞いたことがあるでしょう。 - しかし、 - その有効性をネットワーク環境において完全に理解している人はほとんどいなく、 - 誰もがネットワーク接続を取り扱うために、 - ファイアウォールをインストールしたいと考えているようです。 - ファイアウォールは、幅広い用途がある一方で、 - 接続元に対しテキストを送るといった、取り扱ない作業があります。 - TCP Wrappers ソフトウェアは、 - これ以上のことができます。 - 以下の節では、 - TCP Wrappers の多くの機能が説明されています。 - そして、適応できる場合には、設定行の例が紹介されています。 - - TCP Wrappers ソフトウェアは、 - inetd - の管理のもとにすべてのサーバデーモンに対応する機能を拡張します。 + TCP Wrappers は、 + すべてのサーバデーモンに対するサポートをその管理下で提供できるように、 + の機能を拡張します。 この方法を使うことで、ログへの対応、 接続に対してメッセージを返したり、 - 内部の接続だけを許可するようにデーモンを設定することなどが可能となります。 + 内部の接続だけを許可するようにデーモンを設定することが可能となります。 これらの機能のいくつかはファイアウォールでも実装できますが、 - 保護のための特別なレイヤを追加するだけでなく、 - ファイアウォールが提供する以上の管理を提供します。 - - TCP Wrappers 機能の追加は、 - ファイアウォールのより良い置き換えと考えるべきではありません。 TCP Wrappers は、 - ファイアウォールおよび他のセキュリティ設定と組み合わせて使うことができ、 - システムを守るための追加のレイヤとして上手く機能します。 + システムを守るためのレイヤを追加し、 + ファイアウォールが提供する以上の管理機能を提供します。 - この設定は inetd - の設定の拡張なので、inetd - の設定 章をすでに読んでいることを想定しています。 - - - &man.inetd.8; により起動されるプログラムは、正確には、 - デーモン ではありませんが、 - 伝統的にデーモンと呼ばれています。 - この章でも、このように呼ぶこととします。 - + TCP Wrappers は、 + 適切に設定されたファイアウォールの置き換えと考えるべきではありません。 + TCP Wrappers は、 + ファイアウォールや他のセキュリティ強化のツールと組み合わせて使うべきです。 初期設定 - &os; 上で TCP Wrappers - を使用ために必要となるのは、 + &os; 上で TCP Wrappers を有効にするには、 rc.conf から オプションで - inetd - サーバが起動されることを確認するだけです。 - これはデフォルトの設定です。 - もちろん、 - /etc/hosts.allow - も適切に設定されていることが前提です。 - この場合、&man.syslogd.8; - はシステムログにメッセージを出力します。 + &man.inetd.8; サーバが起動されることを確認してください。 + その後、/etc/hosts.allow + を適切に設定してください。 他の TCP Wrappers の実装と異なり、 @@ -1658,40 +1337,36 @@ Enter secret pass phrase: <secret password> 最も簡単な設定におけるデーモンの接続ポリシは、 /etc/hosts.allow の中で、 オプションごとに許可またはブロックするように設定するというものです。 - &os; のデフォルトの設定では、inetd - から起動されたすべてのデーモンの接続を許可します。 - この設定を変更することについては、 - 基本的な設定を理解した後で議論されるべきです。 + &os; のデフォルトの設定では、&man.inetd.8; + から起動されたすべてのデーモンの接続を許可します。 基本的な設定は、通常 daemon : address : action という形式です。ここで、 daemon は、 - inetd が起動するデーモンの名前です。 + &man.inetd.8; が起動するデーモンの名前です。 address の部分は、有効なホスト名、 IP アドレスまたは、 括弧 ([ ]) で囲まれた IPv6 アドレスです。 - action フィールドの部分は、 - アクセスを適切に許可または拒否をするように、 - allow または deny となります。 - 最初のマッチしたルールが適用されると、 - 設定はそこで終わることを覚えておいてください。 - これは、設定ファイルは昇順にルールのマッチをスキャンされ、 + action は、 + allow または deny です。 + TCP Wrappers は、 + 最初にマッチしたルールが適用されます。 + これは、設定ファイルに対するルールにマッチするかどうかのスキャンは、 + 昇順に行われることを意味しています。 マッチすると、ルールが適用され、 - 検索のプロセスは停止することを意味しています。 + 検索のプロセスは終了します。 - 他にもいくつかのオプションが存在し、以降の節で説明されます。 - 簡単な設定の行は、上記の情報のみで簡単に構成されます。 - 例として、POP3 の接続を、 + 例として、POP3 の接続を mail/qpopper - デーモンから許可するには、以下の行を + デーモン経由で許可するには、以下の行を hosts.allow に追加してください。 # This line is required for POP3 connections: qpopper : ALL : allow - この行を追加したら、&man.service.8; を使って - inetd を再起動してください。 + この行を追加したら、 + &man.inetd.8; を再起動してください。 &prompt.root; service inetd restart @@ -1699,46 +1374,42 @@ qpopper : ALL : allow 高度な設定 - TCP Wrappers で高度な設定もできます。 - 接続を取り扱う以上の制御を行うことができるのです。ある時は、 - 接続しているホストまたはデーモンにコメントを返すことが良い考えのことがあります。 - 別の場合では、おそらくログファイルを記録したり、 + TCP Wrappers は、 + 接続を取り扱う以上の制御を行う高度な設定も提供しています。 + ある時は、 + 接続しているホストまたはデーモンにコメントを返すことが適切であることがあります。 + 別の場合では、おそらくログエントリを記録したり、 管理者にメールで送る必要があることもあるでしょう。 またその他の状況としては、 - サービスをローカルの接続のみで使用できる必要がある場合もあります。 + サービスをローカルの接続のみの使用に制限する必要がある場合もあります。 これらはすべて、ワイルドカード と呼ばれる設定のオプション (拡張文字および外部コマンドの実行) - で可能となります。 - 以下の 2 つの節では、 - このような状況への対応について触れています。 + で可能となります。 外部コマンド 接続は拒否しなければならないが、 その理由を接続の確立を試みた相手に送りたい状況を考えてください。 - これは、どのように行うことができるでしょうか？ - このアクションは、 - オプションを使うことで実現可能です。 + このアクションは、 を使うことで実現可能です。 接続が試みられると、 - はシェルコマンドまたはスクリプトの実行を要求します。 + はシェルコマンドまたはスクリプトを実行します。 この場合の例は、 - hosts.allow ファイルに書かれています。 + 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. というメッセージを、 アクセスファイルの中で設定されていないすべてのデーモンに対して返します。 - 接続元に対し、確立された接続が破棄された直後に返答することは、 - 非常に有効です。 - 返信に使われるメッセージは、" 文字で囲む - 必要 があります。 - この規則に例外はありません。 + 接続元に対し、 + 確立された接続が破棄された直後に返答することは有効です。 + 返信に使われるメッセージは、引用符 (") で囲む + 必要 があります。 攻撃者や攻撃者のグループは、 @@ -1746,10 +1417,9 @@ ALL : ALL \ サーバに対して DoS 攻撃を仕掛けることができます。 - このような状況において、他の可能性は - オプションを使うことです。 + 他の可能性は を使うことです。 と同様に、 - オプションは、暗黙のうちに接続を拒否し、 + は、暗黙のうちに接続を拒否し、 外部のシェルコマンドやスクリプトを実行できます。 と異なり、 は、 接続を確立した相手に対し、返事を返すことはありません。 @@ -1763,44 +1433,39 @@ ALL : .example.com \ この行は、*.example.com - ドメインからの接続をすべて拒否します。 - 同時にホスト名、IP + からの接続をすべて拒否します。 + ホスト名、IP アドレスおよびアクセスを試みたデーモンが、 /var/log/connections.log - ファイルに記録されます。 + に記録されます。 - すでに説明した置換文字 (たとえば %a) - 以外にも置換文字があります。 - 完全な一覧は - &man.hosts.access.5; マニュアルページをご覧ください。 + この例では、置換文字 %a および + %h が使われています。 + 置換文字の完全な一覧は + &man.hosts.access.5; をご覧ください。 ワイルドカードオプション - これまでの例では、継続して - ALL オプションが使用されてきました。 - この機能を拡張する他のオプションも存在します。たとえば、 - ALL は、 + ALL オプションは、 デーモン、ドメインまたは IP アドレスのすべてのインスタンスのどれかにマッチするかどうかに使われます。 他のワイルドカードは、偽造された IP アドレスを提供するホストにマッチするかどうかに用いられる PARANOID です。 - 言い換えると、PARANOID を使うことで、 + たとえば、PARANOID を使うことで、 ホスト名と異なる IP アドレスからの接続があった時のアクションを定義できます。 - 以下の例は、これらの説明を明確にするでしょう。 + 以下の例では、ホスト名から検索される + IP アドレスと異なる + IP アドレスを持つ + &man.sendmail.8; + への接続のすべてのリクエストを拒否します。 # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny - この例では、ホスト名から検索される - IP アドレスと異なる - IP アドレスを持つ - sendmail - への接続のすべてのリクエストを拒否します。 - クライアントもしくはサーバの DNS の設定が間違っている場合に、 @@ -1810,11 +1475,11 @@ sendmail : PARANOID : deny ワイルドカードおよび関連する機能についてもっと知りたい場合には、 - &man.hosts.access.5; マニュアルページをご覧ください。 + &man.hosts.access.5; をご覧ください。 上記の設定が動作するには、hosts.allow - の中で、最初の設定の行がコメントアウトされている必要があります。 - これはすでにこの章の最初で説明した通りです。 + の中で、 + 最初の設定の行がコメントアウトされている必要があります。 @@ -1844,31 +1509,24 @@ sendmail : PARANOID : deny Kerberos は、 サーバのサービスによってユーザが安全に認証を受けられるようにするための、 ネットワークの付加システムおよびプロトコルです。 - リモートログイン、リモートコピー、 - システム間でのファイルのコピーおよび他のリスクの高いタスクをかなり安全に、 - そしてこれまでより制御できるようになります。 - - Kerberos は、 + Kerberos は、 身元確認プロキシシステムや、 信頼される第 3 者認証システムとも説明されます。 - Kerberos は、一つの機能 — - ネットワーク上のユーザの安全な認証 — - だけを提供します。 - 承認 (どのユーザが許可されているか) - や監査 (ユーザがどのような作業を行っているか) - の機能は提供しません。 - Kerberos を使って、 - クライアントおよびサーバの身元を証明した後は、 - 日常業務におけるすべての通信を暗号化して、 + ユーザが Kerberos を使って認証を行った後は、 + 通信は暗号化され、 プライバシおよびデータの完全性を保証することができます。 - そのため、Kerberos を使う際は、 + Kerberos の唯一の機能は、 + ネットワーク上のユーザの安全な認証を提供することです。 + 承認 (どのユーザが許可されているか) や監査 + (ユーザがどのような作業を行っているか) の機能は提供しません。 + Kerberos を使う際は、 承認および監査サービスを提供する他のセキュリティの手段との利用が、 - 強く推奨されます。 + 推奨されます。 - 以下の文章は、&os; 用として配布されている + この節では、&os; 用として配布されている Kerberos - をセットアップする際のガイドとして利用できますが、 + をセットアップする際のガイドを提供します。 完全な説明が必要な場合には、 マニュアルページを参照してください。 @@ -1878,12 +1536,13 @@ sendmail : PARANOID : deny DNS ドメイン (ゾーン) は、 - example.org です。 + example.org + です。 Kerberos の領域は、 - EXAMPLE.ORG です。 + EXAMPLE.ORG です。 @@ -1913,9 +1572,8 @@ sendmail : PARANOID : deny Kerberos は、 ネットワーク認証プロトコルの名前であり、 - このプログラムを実装しているプログラムを表す - (例 Kerberos telnet) - ための形容詞でもあります。 + Kerberos telnet のように、 + このプログラムを実装しているプログラムを表すための形容詞でもあります。 プロトコルの現在のバージョンはバージョン 5 で、 RFC 1510 として文書化されています。 @@ -1929,22 +1587,20 @@ sendmail : PARANOID : deny 歴史的には、 アメリカ合衆国 の輸出規制により制限されてきました。 MIT で実装された - Kerberos は、port - (security/krb5) - から利用できます。 + Kerberos は、 + security/krb5 package または + port から利用できます。 バージョン 5 のもう一つの実装が、 Heimdal Kerberos です。 この実装は、アメリカ合衆国の外で開発されたため、 - 輸出の制限を避けることができます - (そのため、非商用の &unix;-like なシステムによく含まれています)。 - Heimdal Kerberos は port - (security/heimdal) - からインストールできますが、最小構成は + 輸出の制限を避けることができます。 + Heimdal Kerberos は + security/heimdal + package または port からインストールできますが、最小構成は &os; の base インストールに含まれています。 - 幅広い読者を対象とするために、以下の説明では - &os; に含まれている Heimdal + 以下の説明では &os; に含まれている Heimdal ディストリビューションの使用を想定しています。 @@ -1958,8 +1614,8 @@ sendmail : PARANOID : deny 鍵配布センター (KDC) は、 Kerberos - が提供する中心的な認証サービス - — Kerberos + が提供する中心的な認証サービスで、 + Kerberos チケットを発行するコンピュータです。 KDC は、 Kerberos @@ -1968,22 +1624,22 @@ sendmail : PARANOID : deny そのため、厳重なセキュリティに対する配慮が必要となります。 Kerberos - サーバの実行にコンピュータのリソースは必要ありませんが、 + サーバの実行にコンピュータのリソースはほとんど必要ありませんが、 セキュリティの観点から、KDC としてのみ機能する専用のコンピュータが推奨されます。 KDC を設定するにあたって、 KDC として動作するために、 - 適切に /etc/rc.conf が設定されていること - (システムを反映するようにパスを調整する必要があります) - を確認してください。 + 適切に /etc/rc.conf + が設定されていることを確認してください。 + 必要に応じて、 + システムの設定を反映するようにパスを調整する必要があります。 kerberos5_server_enable="YES" kadmind5_server_enable="YES" - 次に、Kerberos - の設定ファイル /etc/krb5.conf - を編集します。 + 次に、/etc/krb5.conf + を以下のように編集してください。 [libdefaults] default_realm = EXAMPLE.ORG @@ -1995,18 +1651,18 @@ kadmind5_server_enable="YES" [domain_realm] .example.org = EXAMPLE.ORG - /etc/krb5.conf ファイルの中では、 + /etc/krb5.conf の中で、 KDC は、 完全修飾されたホスト名 kerberos.example.org - を持つことが想定されていることに注意してください。 - KDC が異なるホスト名である場合には、 + を使うことが想定されています。 + KDC が異なるホスト名を持つ場合には、 名前の解決が行われるように、適切に CNAME (エイリアス) - エントリをゾーンファイルに追加する必要があります。 + エントリをゾーンファイルに追加してください。 - 適切に BIND DNS - サーバが設定されたネットワークでは、 + 適切に DNS + サーバが設定されている大きなネットワークでは、 上記の例は、以下のように整理されます。 [libdefaults] @@ -2032,36 +1688,35 @@ _kerberos IN TXT EXAMPLE.ORG 必要 があります。 - 次に Kerberos データベースを作成します。 + 次に Kerberos + データベースを作成してください。 このデータベースには、 - マスター鍵により暗号化されたすべてのプリンシパルの鍵があります。 - このパスワードは、ファイル - (/var/heimdal/m-key) に保存されるため、 + マスター鍵により暗号化されたすべてのプリンシパルの鍵が含まれています。 + このパスワードは、 + /var/heimdal/m-key に保存されるため、 覚える必要はありません。 - マスター鍵を作成するには、kstash を実行して、 + マスター鍵を作成するには、&man.kstash.8; を実行して、 パスワードを入力してください。 - マスター鍵を作成したら、kadmin プログラムを - -l オプション (local を意味します) - で実行し、初期化します。 - このオプションを使うと、kadmin は、 - kadmind ネットワークサービスを使わず、 - 直接データベースファイルを変更します。 + マスター鍵を作成したら、kadmin -l + を使ってデータベースを初期化してください。 + このオプションを使うと、&man.kadmin.8; は、 + &man.kadmind.8; ネットワークサービスを使わず、 + ローカルのデータベースファイルを直接変更します。 これにより、 データベースを作成する前に、データベースへの接続を試みてしまうという、 卵が先か鶏が先かという問題を回避できます。 - kadmin - プロンプトが表示されたら、init コマンドを使って、 + &man.kadmin.8; プロンプトで、 + init を使って、 レルムに関する初期のデータベースを作成してください。 - 最後に、kadmin プロンプトで - add - コマンドを使って最初のプリンシパルを作成して下さい。 + 最後に、&man.kadmin.8; プロンプトで + add を使って最初のプリンシパルを作成して下さい。 差し当たりは、 プリンシパルに対するデフォルトのオプションに従ってください。 - 後で modify コマンドを使うことで、 - いつでも変更することができます。 - プロンプトで ? コマンドを使うと、 + 後で modify を使うことで、 + 変更することができます。 + &man.kadmin.8; プロンプトで ? と入力すると、 利用可能なオプションを確認できます。 データベース作成のセッションの例は以下のようになります。 @@ -2080,15 +1735,14 @@ Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx - これで KDC - サービスを起動することができるようになりました。 + 次に KDC サービスを起動してください。 service kerberos start および service kadmind start を実行してサービスを起動してください。 この時点で、kerberos 化されたデーモンが走っていなくても、 KDC のコマンドラインから、作成したばかりの (ユーザ) プリンシパルのチケットを入手したり、 - 一覧を表示することができることを確認してください。 + 一覧を表示することができることを確認できます。 &prompt.user; kinit tillman tillman@EXAMPLE.ORG's Password: @@ -2114,62 +1768,53 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG Enabling サービス - 最初に Kerberos - の設定ファイル /etc/krb5.conf - のコピーが必要です。 - コピーを行うには、KDC から、 - クライアントコンピュータへ - (&man.scp.1; のようなネットワークユーティリティを使うか、 - 物理的にフロッピーディスクを使って) - 安全な方法でコピーをしてください。 + 最初に /etc/krb5.conf を + KDC からクライアントコンピュータへ、 + &man.scp.1; + または物理的にリムーバブルディスクを使うといった安全な方法でコピーしてください。 次に /etc/krb5.keytab - ファイルが必要となります。 - これは、Kerberos - 化されたデーモンを提供するサーバとワークステーションの間での大きな違いです - — サーバは、 - keytab ファイルを持っている必要があります。 + を作成してください。 + これが Kerberos + 化されたデーモンを提供するサーバとワークステーションの間での大きな違いです: + サーバには keytab が置かれている必要があります。 このファイルには、サーバのホスト鍵が含まれています。 この鍵により、ホストおよび KDC が他の身元の検証ができます。 鍵が公開されてしまうと、 - サーバのセキュリティが破れてしまうため、 - このファイルは安全にサーバに転送しなければなりません。 - このことは、FTP - のようにテキストチャネルでの転送は、 - まったく好ましくないことを意味しています。 + サーバのセキュリティが破られてしまうため、 + このファイルは安全にサーバに転送しなければなりません。 - 一般的には、kadmin プログラムを使って、 + 一般的には、&man.kadmin.8; を使って、 keytab をサーバに転送します。 - kadmin を使って + ホストプリンシパル (KDC 側の - krb5.keytab に) - ホストプリンシパルを作成することも必要なので便利です。 + krb5.keytab) + も &man.kadmin.8; を使って作成するので便利です。 すでにチケットを入手し、そのチケットは、 - kadmin インタフェースで使用できることが + &man.kadmin.8; インタフェースで使用できることが kadmind.acl で許可されている必要があります。 アクセスコントロールリストの設計の詳細については、 - Heimdal info ページ (info heimdal) の + info heimdal の Remote administration というタイトルの章をご覧ください。 リモートからの - kadmin アクセスを有効にしたくない場合は、 - 安全に (ローカルコンソール、&man.ssh.1; もしくは - Kerberos &man.telnet.1; を用いて) - KDC に接続し、 + kadmin アクセスを有効にする代わりに、 + 管理者は、ローカルコンソールまたは &man.ssh.1; + を用いて安全に KDC に接続し、 kadmin -l を使用して、 - ローカルで管理作業を行ってください。 + ローカルで管理作業を行うことができます。 /etc/krb5.conf - ファイルをインストールしたら、 - Kerberos サーバから、 - kadmin を使うことができます。 - add --random-key コマンドを使うと、 - サーバのホストプリンシパルを追加できます。 - そして、ext コマンドを用いて、 - サーバのホストプリンシパルを keytab に抽出してください。 + をインストールしたら、 + Kerberos サーバから + add --random-key を使ってください。 + このコマンドは、サーバのホストプリンシパルを追加します。 + そして、ext を用いて、 + サーバのホストプリンシパルを keytab に抽出してください。 + 以下は、使用例です。 &prompt.root; kadmin @@ -2180,51 +1825,48 @@ Attributes []: kadmin> ext host/myserver.example.org kadmin> exit - ext コマンド (extract - の省略形) は、デフォルトでは、抽出された鍵を + ext は、デフォルトでは、抽出された鍵を /etc/krb5.keytab に保存します。 - KDC 上で kadmind - を (おそらくセキュリティ上の理由から) 走らせていない場合で、 - リモートから kadmin に接続出来ない場合には、 + KDC 上で &man.kadmind.8; + を走らせていない場合で、 + リモートから &man.kadmin.8; に接続出来ない場合には、 ホストプリンシパル (host/myserver.EXAMPLE.ORG) を直接 KDC 上で追加し、 その後、以下のように - (KDC 上の - /etc/krb5.keytab の上書きを避けるため)、 + KDC 上の + /etc/krb5.keytab の上書きを避けるため、 一時ファイルに抽出してください。 &prompt.root; kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit - その後、keytab を安全に (たとえば - scp またはフロッピーを使って) - サーバコンピュータにコピーしてください。 + その後、&man.scp.1; またはリムーバブルディスクを使って、 + keytab を安全にサーバコンピュータにコピーしてください。 KDC 上の keytab を上書きすることを避けるため、 デフォルトとは異なる名前を指定してください。 これでサーバは、 - (krb5.conf ファイルにより) + krb5.conf を使って KDC と通信ができるようになりました。 - そして、(krb5.keytab ファイルによって) - 身元を証明できるようになったので、 + そして、krb5.keytab + によって身元を証明できるようになったので、 Kerberos サービスを有効にする準備が出来ました。 - この例では、以下の行を - /etc/inetd.conf に加え、 - telnet - サービスを有効にしてください。その後、service inetd - restart にて + この例では、 + &man.telnetd.8; サービスが + /etc/inetd.conf で有効に設定され、 + service inetd restart によって、 &man.inetd.8; サービスを再起動します。 telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user - 重要な箇所は、ユーザに -a - (認証を表す) が設定されていることです。 + 重要な変更箇所は、 + 認証がユーザに設定されていることです。 詳細については、 - &man.telnetd.8; マニュアルページを参照してください。 + &man.telnetd.8; を参照してください。 @@ -2236,18 +1878,13 @@ kadmin> exit クライアントの設定 - クライアントコンピュータの設定は、 - ほとんど取るに足らないくらいに簡単です。 - Kerberos の設定がうまくいっていれば、 - /etc/krb5.conf に置かれている - Kerberos - の設定ファイルのみが必要です。 - セキュリティ的に安全な方法で、KDC - からクライアントコンピュータへ単にコピーしてください。 + クライアントコンピュータの設定は簡単です。 + /etc/krb5.conf のみが必要です。 + このファイルをセキュリティ的に安全な方法で、KDC + からクライアントコンピュータへコピーしてください。 - クライアントから、kinit, - klist および - kdestroy を使用し、 + クライアントから、&man.kinit.1;, + &man.klist.1; および &man.kdestroy.1; を使用し、 上記で作成したプリンシパルに対するチケットの入手、表示、 削除を行い、クライアントコンピュータを試験してください。 Kerberos @@ -2258,29 +1895,22 @@ kadmin> exit クライアントまたは KDC の問題ではないと考えられます。 - telnet - のようなアプリケーションを試験する際には、 - (&man.tcpdump.1; といった) パケットスニファを使用して、 - パスワードが平文で送られていないことを確認してください。 - -x オプションで - telnet を利用すると、 - (ssh のように) - すべてのデータストリームが暗号化されます。 + Kerberos 化されたアプリケーションを試験する際には、 + &man.tcpdump.1; といったパケットスニファを使用して、 + パスワードが平文で送られていないことを確認してください。 - デフォルトでは、Heimdal インストールの - 最小 と考えられる、コア以外の + コア以外の さまざまな Kerberos - クライアントアプリケーションもインストールされます。 - telnet は、 + クライアントアプリケーションが利用可能です。 + &os; の 最小 インストールでは、 + インストールされる Kerberos - 化された唯一のサービスです。 + 化された唯一のサービスは、&man.telnetd.8; です。 Heimdal port は、 Kerberos 化されている - ftp, rsh, - rcp, rlogin - および他のあまり一般的ではないプログラムといった、 - インストールされていないクライアントアプリケーションをインストールします。 + &man.ftpd.8;, &man.rshd.8;, &man.rcp.1;, &man.rlogind.8; + および他のあまり一般的ではないプログラムをインストールします。 MIT port も、すべての Kerberos クライアントアプリケーションをインストールします。 @@ -2299,46 +1929,35 @@ kadmin> exit レルムのユーザは、一般的には、 - (tillman - のような) ローカルユーザアカウントに対応する - (tillman@EXAMPLE.ORG - といった) Kerberos - プリンシパルを持ちます。 - telnet - のようなクライアントアプリケーションは、 - ユーザ名もしくはプリンシパルを通常必要としません。 - - しかしながら、時々 + ローカルユーザアカウントに対応する + Kerberos プリンシパルを持ちます。 + しかしながら、時々 Kerberos プリンシパルに対応しないローカルユーザアカウントへのアクセスが必要となることがあります。 たとえば、 tillman@EXAMPLE.ORG が、ローカルユーザアカウント webdevelopers - へのアクセスが必要となることがあります。 - そして、他のプリンシパルが同じローカルアカウントにアクセスが必要になることもあります。 + へのアクセスが必要となることがあります。そして、 + 他のプリンシパルが同じローカルアカウントにアクセスが必要になることもあります。 ユーザのホームディレクトリに置かれた .k5login および - .k5users ファイルによって - (.hosts および .rhosts - の強力な組み合わせのように)、この問題を解決出来ます。 + .k5users ファイルを使うことで、 + この問題を解決出来ます。 たとえば、以下の行を含む - .k5login を - - tillman@example.org -jdoe@example.org - - ローカルユーザ + .k5login を webdevelopers のホームディレクトリに置くと、 一覧にある両方のプリンシパルは、 共有のパスワードを必要としなくても、 このアカウントにアクセス出来ます。 - これらのコマンドのマニュアルページを読むことが推奨されます。 - ksu マニュアルページには、 - .k5users の説明があります。 + tillman@example.org +jdoe@example.org + + .k5users の詳細については、 + &man.ksu.1; を参照してください。 @@ -2355,27 +1974,26 @@ jdoe@example.org Heimdal または MIT Kerberos ports のどちらを使う場合でも、 - PATH 環境変数は、 + PATH は、 Kerberos 版のクライアント アプリケーションが、 システムにあるアプリケーションより先に見つかるように設定されていることを確認してください。 - レルムにあるすべてのコンピュータの間で時刻が同期していますか？ - 時刻が同期していないと認証に失敗してしまいます。 + レルムにあるすべてのコンピュータの間で時刻が同期していないと、 + 認証に失敗してしまいます。 NTP を用いた、時刻の同期方法については、 をご覧ください。 MIT および Heimdal 間の運用は、 - 標準化されていないプロトコル kadmin を除き、 - うまく機能します。 + 標準化されていない &man.kadmin.8; を除けばうまく機能します。 - ホスト名を変更する際は、 + ホスト名が変更された場合は、 host/ プリンシパルを変更し、keytab をアップデートする必要があります。 Apache の @@ -2387,13 +2005,12 @@ jdoe@example.org - レルムの中のすべてのホストは、DNS - において (もしくは、最低限/etc/hosts - の中で)、(正引きおよび逆引き両方で) - 名前解決できる必要があります。 + レルムの中のすべてのホストは、DNS、 + もしくは、最低限 /etc/hosts + において正引きおよび逆引き両方で名前解決できる必要があります。 CNAME は動作しますが、A および PTR レコードは、 正しく適切な位置に記述されている必要があります。 - エラーメッセージは、 + 名前が解決できない場合のエラーメッセージは、 次の例のように、直感的に原因が分かるようなものではありません。 Kerberos5 refuses authentication because Read req failed: Key table entry not @@ -2403,14 +2020,12 @@ jdoe@example.org KDC に対しクライアントとして振る舞うオペレーティングシステムの中には、 - ksu に対して、 + &man.ksu.1; に対して、 root 権限に setuid を許可しないものがあります。 この設定では、 - ksu は動作しないことを意味します。 - セキュリティの観点からは好ましい考えですが、 - 厄介です。これは - KDC のエラーではありません。 + &man.ksu.1; は動作しないことを意味します。 + これは KDC のエラーではありません。 @@ -2418,36 +2033,34 @@ jdoe@example.org Kerberos において、 プリンシパルが、デフォルトの 10 時間を超えるチケットの有効期限としたい場合には、 - kadmin で + &man.kadmin.8; のプロンプトで modify_principal を使って、 対象のプリンシパルおよび krbtgt プリンシパル両方の有効期限の最大値を変更してください。 プリンシパルは、 - kinit で - -l オプションを使用して、 + kinit -l を使用して、 長い有効期限のチケットを要求できます。 トラブルシューティングのために、 KDC でパケットスニファを走らせ、 - そして、ワークステーションから - kinit を実行すると、 - kinit を実行するやいなや、 - TGT が送られてきます。 - — - あなたがパスワードを入力し終わる前でも! + 一方で、ワークステーションにおいて + &man.kinit.1; を実行すると、 + &man.kinit.1; を実行するやいなや、 + パスワードを入力し終わる前でも、 + Ticket Granting Ticket (TGT) が送られてきます。 これに関する説明は、以下の通りです。 Kerberos サーバは、 いかなる未承認のリクエストに対して、 - 自由に TGT (Ticket Granting - Ticket) を送信します。しかしながら、すべての + 自由に TGT を送信します。 + しかしながら、すべての TGT は、 ユーザのパスワードから生成された鍵により、暗号化されています。 そのため、ユーザがパスワードを入力した時には、 パスワードは KDC には送られません。 - このパスワードは、kinit がすでに入手した + その代わりこのパスワードは、&man.kinit.1; がすでに入手した TGT の復号化に使われます。 もし、復号化の結果、 有効なチケットで有効なタイムスタンプの場合には、 @@ -2456,18 +2069,17 @@ jdoe@example.org このクレデンシャルには、 Kerberos サーバ自身の鍵により暗号化された実際の - ticket-granting ticket とともに、将来 + TGT とともに、将来 Kerberos サーバと安全な通信を確立するためのセッション鍵が含まれています。 - この暗号の 2 番目のレイヤは、ユーザには知らされませんが、 + この暗号の 2 番目のレイヤは、 Kerberos サーバが、 各 TGT の真偽の検証を可能にしている部分です。 - (たとえば一週間といった) - 長い有効期限のチケットを使いたい場合で、 + たとえば一週間といった長い有効期限のチケットを使いたい場合で、 OpenSSH を使って、 チケットが保存されているコンピュータに接続しようとする場合は、 Kerberos @@ -2478,22 +2090,21 @@ jdoe@example.org - ホストプリンシパルも長い有効期限のチケットを持てることを覚えておいてください。 + ホストプリンシパルは長い有効期限のチケットを持つことができます。 もし、ユーザプリンシパルが 1 週間の有効期限を持ち、 接続しているホストが、9 時間の有効期限を持っている場合には、 - キャッシュのホストプリンシパル (の鍵) の有効期限が切れてしまい、 + ユーザキャッシュは有効期限が切れたホストプリンシパルを持つことになり、 想定したように、 チケットキャッシュが振る舞わないことが起こりえます。 - 特定の問題のあるパスワードが使われることを避けるために - (kadmind のマニュアルページでは、 - この点について簡単に触れています)、 - krb5.dict ファイルを設定する時には、 - パスワードポリシが割り当てられたプリンシパルにのみ適用されることに注意してください。 - krb5.dict ファイルの形式は簡単です。 - : 一行に一つの文字列が置かれています。 + &man.kadmind.8; で説明されているような、 + 特定の問題のあるパスワードが使われることを避けるために + krb5.dict を設定する時には、 + パスワードポリシが割り当てられたプリンシパルにのみ適用されることを覚えていてください。 + krb5.dict で使われている形式では、 + 一行に一つの文字列が置かれています。 /usr/share/dict/words にシンボリックリンクを作成することは、有効です。 @@ -2503,40 +2114,38 @@ jdoe@example.org <acronym>MIT</acronym> port との違いについて - MIT - とインストールされている Heimdal 版の大きな違いは、 - kadmin に関連しています。 + MIT と Heimdal 版の大きな違いは、 + &man.kadmin.8; に関連しています。 このプログラムは、異なる (ただし等価な) コマンド群を持ち、そして、 異なるプロトコルを使用します。 もし KDC に MIT を使用している場合には、 - Heimdal kadmin - プログラムを使って KDC をリモートから - (この場合は、逆も同様に) 管理できないことを意味しています。 + Heimdal 版の &man.kadmin.8; + を使って KDC をリモートから + (逆も同様に) 管理できないことを意味しています。 クライアントアプリケーションでは、同じタスクを行う際に、 - 若干異なるコマンドラインのオプションが必要となることもあります。 + 若干異なるコマンドラインのオプションが使われることもあります。 MIT - Kerberos ウェブサイト - () + Kerberos ウェブサイト に書かれているガイドに従うことが推奨されます。 path の問題について注意してください。 MIT port はデフォルトで /usr/local/ にインストールします。 そのため、もし PATH - 環境変数においてシステムのディレクトが最初に書かれている場合には、 + においてシステムのディレクトが最初に書かれている場合には、 MIT 版ではなく、通常の - システムアプリケーションが動いてしまいます。 + システムアプリケーションが起動してしまいます。 - &os; が提供する MIT + &os; の MIT security/krb5 port において、 - telnetd および klogind - 経由でのログインが奇妙な振る舞いをすることを理解したいのであれば、 + &man.telnetd.8; および klogind + 経由でのログインが奇妙な振る舞いをすることを理解するには、 port からインストールされる /usr/local/share/doc/krb5/README.FreeBSD - ファイルを読んで下さい。 - 最も重要なことは、 + を読んで下さい。 incorrect permissions on cache file の振る舞いを修正するには、 フォワードされたクレデンシャリングの所有権を適切に変更できるように、 @@ -2544,7 +2153,7 @@ jdoe@example.org バイナリが認証に使われる必要があります。 rc.conf - を以下の設定を含むように変更する必要があります。 + を以下のように変更する必要もあります。 kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" @@ -2552,7 +2161,7 @@ kerberos5_server_enable="YES" kadmind5_server_enable="YES" これを行うのは、 - MIT kerberos のアプリケーションは、 + MIT Kerberos のアプリケーションは、 /usr/local 構造の下にインストールされるためです。 @@ -2567,18 +2176,17 @@ kadmind5_server_enable="YES" - <application>Kerberos</application> は、all-or-nothing + <title><application>Kerberos</application> は、All or Nothing アプローチです。 ネットワーク上で有効なすべてのサービスは、 - Kerberos 化 - (または、ネットワーク攻撃に対して安全に) されるべきです。 + Kerberos 化されるか、 + または、ネットワーク攻撃に対して安全であるべきです。 さもないと、ユーザのクレデンシャルが盗まれ、 利用されることが起きるかもしれません。 この例は、 - Kerberos 化されたすべてのリモートシェル - (たとえば、rsh および telnet) - です。 + Kerberos + 化されたすべてのリモートシェルです。 パスワードを平文で送るような POP3 メールサーバは変換していません。 @@ -2590,55 +2198,49 @@ kadmind5_server_enable="YES" マルチユーザの環境では、 Kerberos は安全ではありません。 チケットは /tmp - ディレクトリに保管され、 + に保管され、 このチケットは、すべてのユーザが読むことができるためです。 - もし、ユーザがコンピュータを他のユーザと同時に共有 - (i.e. マルチユーザで使用) していると、 - 他のユーザは、そのユーザのチケットを盗む - (コピーする) ことが出来てしまいます。 + もし、ユーザがコンピュータを他のユーザと同時に共有していると、 + 他のユーザは、そのユーザのチケットを盗んだり、 + コピーが出来てしまいます。 この問題は、-c - ファイル名コマンドラインオプションまたは、(好ましくは) - KRB5CCNAME 環境変数によって克服されますが、 - 実際に使われることはまれです。 - 大体においては、チケットをユーザのホームディレクトリに保存し、 - 簡単なファイルの許可属性を設定することで、 - この問題に対応できます。 + コマンドラインオプションまたは、好ましくは + KRB5CCNAME 環境変数によって克服されます。 + この問題への対応には、 + チケットをユーザのホームディレクトリに保存し、 + ファイルの許可属性を設定することが一般的に行われます。 KDC は、単一障害点である 設計上、KDC は、 - マスターパスワードのデータベースを含むため、 - 安全である必要があります。 + マスターパスワードのデータベースと同様に安全である必要があります。 KDC では、 絶対に他のサービスを走らせるべきではありませんし、 物理的に安全であるべきです。 Kerberos は、 - KDC 上で、ファイルとして保存されている一つの鍵 - (マスター 鍵) - で暗号化されたすべてのパスワードを保存しているので、 + KDC 上で、ファイルとして保存されている同じ + マスター + 鍵で暗号化されたすべてのパスワードを保存しているので、 非常に危険です。 - 追記ですが、マスター鍵が漏洩しても、 - 通常懸念するほど悪いことにはなりません。 + マスター鍵が漏洩しても、 + 懸念するほど悪いことにはなりません。 マスター鍵は、Kerberos データベースの暗号時にのみ、 乱数を生成するためのシードとして使われます。 KDC へのアクセスが安全である限りにおいては、 マスター鍵を用いて、それほど多くのことはできません。 - さらに、KDC が - (DoS 攻撃またはネットワーク問題等により) - ネットワークサービスを利用できず、 - 認証ができない場合に対する、DoS 攻撃への対応方法があります。 + さらに、KDC が利用できないと、 + 認証ができないため、ネットワークサービスを利用できなくなります。 この攻撃による被害は、 - 複数の KDC - (ひとつのマスタとひとつまたはそれ以上のスレーブ) - および、セカンダリもしくはフォールバック認証 - (これには、PAM が優れています) - の実装により軽減することができます。 + ひとつのマスタ KDC + とひとつまたはそれ以上のスレーブ、 + そして、セカンダリもしくは PAM + を用いたフォールバック認証を注意深く実装することにより軽減できます。 @@ -2648,12 +2250,10 @@ kadmind5_server_enable="YES" ユーザ、ホストおよびサービスの間での認証を可能にしますが、 KDC とユーザ、 ホストまたはサービスとの間の認証のメカニズムは提供しません。 - これは、(たとえば) トロイの木馬の - kinit が、 + これは、トロイの木馬の &man.kinit.1; が、 すべてのユーザ名とパスワードを記録できることを意味しています。 security/tripwire - のような、 - もしくは他のファイルシステムの完全性を確認するためのツールにより、 + のような、ファイルシステムの完全性を確認するためのツールにより、 この危険性を軽減することができます。 @@ -2721,9 +2321,8 @@ kadmind5_server_enable="YES" OpenSSL - 多くのユーザが見落としがちな機能の一つが、 - &os; に含まれている OpenSSL - ツールキットです。 + &os; には、OpenSSL + ツールキットが含まれています。 OpenSSL は、 通常の通信層の上位にあるトランスポート層を暗号化し、 多くのネットワークアプリケーションおよびサービスと組み合わせて使用できます。 @@ -2739,14 +2338,14 @@ kadmind5_server_enable="YES" 多くの場合、Ports Collection は、 - make の WITH_OPENSSL_BASE 変数が明示的に + make の WITH_OPENSSL_BASE が明示的に yes に設定されていないと、 security/openssl port の構築を試みます。 &os; に含まれている OpenSSL - 　のバージョンは、Secure Sockets Layer v2/v3 (SSLv2/SSLv3) や + 　のバージョンは、Secure Sockets Layer v2/v3 (SSLv2/SSLv3) および Transport Layer Security v1 (TLSv1) ネットワークセキュリティプロトコルに対応しており、 多目的な暗号化ライブラリとして使うことができます。 @@ -2757,6 +2356,7 @@ kadmind5_server_enable="YES" 合衆国の特許により、デフォルトでは無効になっています。 もし使用したいのであれば、ライセンス条項を必ず確認し、 ライセンス条項に合致するのであれば、 + /etc/make.conf において MAKE_IDEA 変数を設定してください。 @@ -2766,15 +2366,16 @@ kadmind5_server_enable="YES" これらの証明書により、会社または個人の公開鍵が、 改ざんやなりすましが行われていないことを確認できます。 もし問題となっている証明書が、認証局 - または CA により検証されなければ、 - 通常警告が表示されます。 - 認証局は、VeriSign + (CA) により検証されなければ、 + 警告が表示されます。 + CA + は、VeriSign のような会社で、個人または会社の公開鍵の検証を行えるように、 証明書に署名を行います。 証明書を作成するには費用がかかり、 - 証明書の使用は必ずしも必要条件ではありません。 - しかしながら、証明書を使うことで、 - 疑り深いユーザを安心させることができます。 + 証明書の使用は必要条件ではありませんが、 + 証明書を使うことで、 + ユーザを安心させることができます。 証明書の作成 @@ -2816,16 +2417,16 @@ An optional company name []:Another Name + &man.openssl.1; で説明されています。 - 前述のコマンドを実行したディレクトリには、 + このコマンドを実行したディレクトリには、 2 つのファイルが作成されているはずです。 1 つは、証明書要求 req.pem です。 - このファイルを認証局に送ると、 - 認証局は含まれている内容を検証し、 + このファイルを CA に送ると、 + CA は含まれている内容を検証し、 検証に成功すると、証明書要求に署名を行い、 作成された証明書を送り返します。 もうひとつ、cert.pem @@ -2833,8 +2434,7 @@ An optional company name []:Another Name + ユーザまたはサーバになりすますことができてしまいます。 CA の署名が必要ない場合には、 自己署名証明書を作成できます。 @@ -2853,35 +2453,34 @@ An optional company name []:Another Name新しく 2 つのファイルがこのディレクトリに作成されます。 プライベート鍵 myca.key および 証明書 new.crt です。 - これらのファイルを、(好ましくは - /etc 以下で) + これらのファイルを、好ましくは + /etc 以下で、 root のみが読むことのできるディレクトリに置く必要があります。 - chmod - ユーティリティを使って許可属性を 0700 に設定してください。 + 許可属性は 0700 が適切です。 + 許可属性は &man.chmod.1; を使って設定できます。 - 証明書の使用例 + 証明書の使用 - これらのファイルで何ができるでしょうか? - 効果的な利用方法は、Sendmail - MTA への接続を暗号化することでしょう。 + 証明書の一つの利用方法は、Sendmail + MTA への接続を暗号化することです。 これにより、 ローカルの MTA 経由でメールを送信するユーザが、 テキスト認証を使用しなくてもすむようになります。 いくつかの MUA は、 - 証明書がローカルにインストールされていない場合に、 - ユーザに対して、エラーを出力するので、 - 完全に最善の利用方法というわけではありません。 + ユーザが証明書をローカルにインストールしていないと、 + エラーを出力します。 証明書のインストールに関する詳細な情報については、 ソフトウェアに付随の文書を参照してください。 - 以下の行をローカルの - .mc ファイルに入れてください。 + Sendmail + を設定するには、以下の行をローカルの + .mc ファイルに含めてください。 dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl @@ -2890,24 +2489,26 @@ 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 ディレクトリで、 + この例では、 + ローカルで証明書および鍵ファイルは、ローカルの + /etc/certs/ + に置かれています。 + ファイルの編集を保存し終わったら、 + /etc/mail において make install - と入力すると再構築できます。 + と入力することで、ローカルの .cf + ファイルを再構築する必要があります。 その後、make restart と入力して、Sendmail デーモンを再起動してください。 すべてがうまくいっていれば、 /var/log/maillog - ファイルにはエラーメッセージは出力されず、 + にはエラーメッセージは出力されず、 Sendmail がプロセスの一覧に表示されます。 - 以下は簡単な試験の例で、&man.telnet.1; ユーティリティを使って、 + 以下は簡単な試験の例で、&man.telnet.1; を使って、 メールサーバに接続しています。 &prompt.root; telnet example.com 25 @@ -2931,13 +2532,13 @@ Escape character is '^]'. 221 2.0.0 example.com closing connection Connection closed by foreign host. - すべてが適切に動いていれば、出力に STARTTLS - 行が表示されます。 + 出力に STARTTLS 行が表示されれば、 + すべてが適切に機能しています。 - VPN over IPsec + <acronym>VPN</acronym> over IPsec @@ -2956,10 +2557,6 @@ Connection closed by foreign host. IPsec - この章では、FreeBSD ゲートウェイを使って、 - インターネットによって分けられた、二つのネットワーク間に - VPN を作成します。 - IPsec を理解する @@ -2977,18 +2574,16 @@ Connection closed by foreign host. - この節では、IPsec を設定する過程を通して、 - IPsec を使った安全な通信の実現方法について解説します。 + この節では、IPsec を設定する過程を説明します。 IPsec を設定するためには、 カスタムカーネルの構築方法をよく知っている必要があります ( をご覧ください)。 - IPsec は、インターネットプロトコル (IP) - レイヤのトップにあるプロトコルです。 - 二つもしくはそれ以上のホスト間で安全に通信することを可能にします - (そのため、名前に sec が含まれています)。 - FreeBSD の IPsec ネットワークスタック は、 - IPv4 および IPv6 の両方のプロトコルファミリに対応している + IPsec は、インターネットプロトコル + (IP) レイヤのトップにあるプロトコルです。 + 二つもしくはそれ以上のホスト間で安全に通信することを可能にします。 + &os; の IPsec ネットワークスタック は、 + IPv4 および IPv6 の両方に対応している KAME 実装をベースとしています。 @@ -3007,15 +2602,17 @@ Connection closed by foreign host. Encapsulated Security Payload - (ESP) は、(Blowfish, 3DES のような) - 対称暗号アルゴリズムを使ってデータを暗号化することで、 + (ESP): + このプロトコルは、Blowfish, 3DES + といった対称暗号アルゴリズムを使ってデータを暗号化することで、 サードパーティのインタフェースから IP パケットデータを保護します。 - Authentication Header (AH), - は、暗号チェックサムを計算し、IP + Authentication Header + AH(AH): + このプロトコルは、暗号チェックサムを計算し、IP パケットのヘッドフィールドを安全なハッシュ関数でハッシュ化することで、 IP パケットヘッダをサードパーティのインタフェースやなりすましから守ります。 ハッシュを含む追加のヘッダが追加され、 @@ -3037,26 +2634,24 @@ Connection closed by foreign host. IPsec は、直接二つのホスト間のトラフィックを暗号化する - Transport Mode、もしくは、 - 2 つの共同するネットワーク間で安全に通信することを可能にするように、 - 2 つのサブネット間に virtual tunnels を構築する + Transport Mode、もしくは + virtual tunnels を構築する Tunnel Mode のどちらでも用いることができます。 - 後者はより一般的には、 - Virtual Private Network (VPN) + 後者のモードはより一般的には、 + Virtual Private Network (VPN) として知られています。 - FreeBSD での IPsec サブシステムに関するより詳細な情報については、 - &man.ipsec.4; マニュアルページを参照してください。 + &os; での IPsec サブシステムに関するより詳細な情報については、 + &man.ipsec.4; を参照してください。 カーネルに IPsec のサポートを追加するには、 - カーネルコンフィグレーションファイルに以下のオプションを追加してください。 + カスタムカーネルコンフィグレーションファイルに以下のオプションを追加してください。 カーネルオプション IPSEC - -options IPSEC #IP security + options IPSEC #IP security device crypto @@ -3067,44 +2662,31 @@ device crypto IPsec のデバッグサポートが必要であれば、 以下のカーネルオプションを追加してください。 - -options IPSEC_DEBUG #debug for IP security + options IPSEC_DEBUG #debug for IP security - 問題点 - - VPN の構成についての標準はありません。 - VPN は、数多くの技術と共に実装することが可能です。 - その各技術には、それ自身の長所と短所があります。 - この章では、シナリオを示し、 - そのシナリオに対して、VPN を実装する戦略について説明します。 - - - - シナリオ: 家庭と会社の - 2 つのネットワークが共にインターネットに接続されています。 - この 2 つのネットワークを、<acronym>VPN</acronym> によって - 1 つのネットワークのように扱えるようにします。 + 家庭と会社間の <acronym>VPN</acronym> VPN creating - 前提は以下の通りです。 + VPN の構成についての標準はありません。 + VPN は、数多くの技術と共に実装することが可能です。 + その各技術には、それ自身の長所と短所があります。 + この節では、以下のシナリオに対して VPN + を実装する戦略について説明します。 - 少なくとも 2 つのサイトを持っています。 + 少なくとも 2 つのサイトがあり、 + それぞれのサイトは内部で IP を使っています。 - どちらのサイトとも内部で IP を使っています。 - - - - 2 つのサイトは、FreeBSD で運用されているゲートウェイを通して、 + 2 つのサイトは、&os; で運用されているゲートウェイを通して、 インターネットに接続しています。 @@ -3116,14 +2698,14 @@ options IPSEC_DEBUG #debug for IP security 2 つのネットワークの内部アドレスは、 パブリックでもプライベート IP アドレスでも構いません。 - IP アドレスは衝突してはいけません。たとえば、両方のネットワークが + しかしながら、アドレス空間は衝突してはいけません。 + たとえば、両方のネットワークが 192.168.1.x を使ってはいけません。 - - + &os; 上で IPsec を設定する。 @@ -3142,7 +2724,7 @@ options IPSEC_DEBUG #debug for IP security 最初に Ports Collection から security/ipsec-tools をインストールしてください。 - このサードパーティ製ソフトウェア packages は、 + このソフトウェアは、 設定をサポートする数多くのアプリケーションを提供します。 次に、パケットをトンネリングし、 @@ -3153,7 +2735,8 @@ options IPSEC_DEBUG #debug for IP security ただし、実行する際には、以下のコマンドの中の internal および external を、 - 実際の内部および外部のゲートウェイのアドレスに置き換えてください。 + 2 つのゲートウェイの内部および外部インタフェースの実際の + IP アドレスに置き換えてください。 &prompt.root; ifconfig gif0 create @@ -3161,19 +2744,19 @@ options IPSEC_DEBUG #debug for IP security &prompt.root; ifconfig gif0 tunnel external1 external2 - たとえば、会社の LAN の公開 + この例では、会社の LAN の外部 IP アドレスを 172.16.5.4、 - プライベート IP アドレスを + 内部 IP アドレスを 10.246.38.1 - とします。また家庭 - LAN の公開 IP アドレスを + とします。また、家庭 + LAN の外部 IP アドレスを 192.168.1.12、 内部のプライベート IP アドレスを 10.0.0.5 とします。 - この説明では分かりにくいので、以下の + この説明で分かりにくい場合は、以下の &man.ifconfig.8; コマンドの出力例をご覧ください。 Gateway 1: @@ -3189,9 +2772,9 @@ tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4 - 設定が完了したら、両方のプライベート IP は、 - 以下の出力のように &man.ping.8; - コマンドで到達できるようになっているはずです。 + 設定が完了したら、両方の内部 IP + アドレスは、&man.ping.8; + で到達できるようになっているはずです。 priv-net# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes @@ -3232,7 +2815,7 @@ round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms これで、ネットワーク内のコンピュータは、 ゲートウェイおよびゲートウェイの奥のコンピュータから到達可能となっています。 - 以下の例で、簡単に確認できます。 + もう一度 &man.ping.8; で確認してください。 corp-net# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes @@ -3260,9 +2843,9 @@ round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms リンクを安全にするには、もう少し掘り下げた設定が必要となります。 以下の設定では、事前共有 (PSK) RSA 鍵を使います。 - IP アドレスを除けば、両方の + IP アドレスを除けば、両方のゲートウェイの /usr/local/etc/racoon/racoon.conf - ファイルは同じで、以下のようになります。 + は同じで、以下のようになります。 path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete @@ -3322,19 +2905,18 @@ sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/ compression_algorithm deflate; } - 上の例で表示されているオプションや、 - すべてのオプションについて説明することは、本文書の範囲を超えています。 - racoon の設定マニュアルページには、 - 関連するたくさんの情報が書かれています。 + 利用可能なオプションの説明については、 + racoon + のマニュアルページを参照してください。 &os; および racoon がホスト間のネットワークトラフィックを暗号化、 復号化できるようにするには、 - SPD ポリシの設定が必要です。 + Security Policy Database (SPD) + の設定が必要です。 - このポリシは、 - 以下のような簡単なシェルスクリプトで設定できます。 - 以下は会社のゲートウェイの例です。 + これは、会社のゲートウェイ上で、 + 以下のようなシェルスクリプトで設定できます。 このファイルをシステムの初期化中に使われるようにするには、 /usr/local/etc/racoon/setkey.conf に保存する必要があります。 @@ -3385,7 +2967,7 @@ n2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[5 これで 2 つのネットワークは、 1 つのネットワークのように利用できます。 多くの場合、 - 両方のネットワークはファイアウォールにより保護されているので、 + 両方のネットワークはファイアウォールにより保護されています。 両方を流れる通信を許可するには、 パケットが両方を行き来できるようにルールを追加する必要があります。 &man.ipfw.8; を使ったファイアウォールの場合は、 @@ -3423,7 +3005,8 @@ pass out quick on gif0 from any to any ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot racoon_enable="yes" - + + @@ -3450,52 +3033,47 @@ racoon_enable="yes" OpenSSH はリモートマシンへのセキュアなアクセスに使われるネットワーク接続ツールの集合です。 - これは rlogin, - rsh, rcp, - telnet をそのまま置き換えて使えます。 また、TCP/IP 接続を - SSH 経由でセキュアにトンネル/フォワードすることもできます。 + OpenSSH + 接続経由でセキュアにトンネル/フォワードすることもできます。 OpenSSH はすべてのトラフィックを暗号化し、 盗聴や接続の乗っ取り等のネットワークレベルの攻撃を事実上無効化します。 OpenSSH - は OpenBSD プロジェクトによって維持管理されており、SSH v1.2.12 - に最新のすべてのバグ修正と更新を適用したものをベースにしています。 - OpenSSH クライアントは - SSH プロトコル 1 と 2 の両方に互換性があります。 + は OpenBSD プロジェクトによって維持管理されており、 + &os; にはデフォルトでインストールされています。 + OpenSSH は、 + SSH バージョン 1 と 2 + の両方に互換性があります。 - OpenSSH を使うことの利点 + <application>OpenSSH</application> を使うことの利点 - &man.telnet.1; や &man.rlogin.1; - を使う場合、一般にデータはネットワークを平文で流れます。 - ネットワークをクライアントとサーバの間のどこかで盗聴することで + データがネットワークを平文で流れてしまうと、 + ネットワークをクライアントとサーバの間のどこかで盗聴することで、 あなたのユーザ/パスワード情報やセション中を流れるデータを盗むことが可能です。 OpenSSH はこれらを予防する為にさまざまな認証と暗号化の方法を提供します。 - <application>sshd</application> を有効にする + SSH サーバを有効にする OpenSSH 有効化 - sshd は、 - &os; の Standard インストールの途中で、 - オプションとして表示されます。 - sshd - が有効になっているかどうかを確認するには、 - rc.conf ファイルを確認してください。 + &man.sshd.8; が有効になっているかどうかを確認するには、 + /etc/rc.conf + の以下の行を確認してください。 sshd_enable="YES" - 次に起動したときから + この設定により、次のシステムの初期化時に OpenSSH のデーモンプログラムである &man.sshd.8; が起動します。 - もしくは &man.service.8; を使って、 + もしくは &man.service.8; を使って、すぐに OpenSSH を起動することもできます。 &prompt.root; service sshd start @@ -3503,13 +3081,15 @@ racoon_enable="yes" SSH クライアント + OpenSSH クライアント - &man.ssh.1; ユーティリティは - &man.rlogin.1; と同様に働きます。 + &man.ssh.1; を使って、 + &man.sshd.8; が動いているシステムに接続するには、 + ログインをするユーザ名とホストを指定してください。 &prompt.root; ssh user@example.com Host key not found from the list of known hosts. @@ -3517,29 +3097,27 @@ Are you sure you want to continue connecting (yes/no)? yes******* - ログインは rlogin や telnet - でセッションを張った時と同様に続きます。 - SSH はクライアントが接続した時、 + SSH はクライアントが接続した時、 サーバの信頼性の検証のために鍵指紋システム (key fingerprint system) を利用します。 - 初めての接続の際にのみ、ユーザは yes + 初めての接続の際に、ユーザは yes と入力することを要求されます。 - これ以降の login では保存されていた鍵指紋を照合することで検証されます。 - SSH クライアントは保存されていた鍵指紋が login + これ以降の login では保存されていた鍵指紋を照合することで検証が行われ、 + &man.ssh.1; クライアントは保存されていた鍵指紋が login しようとした際に送られてきたものと異なっていた場合には警告を表示します。 - 指紋は ~/.ssh/known_hosts に、また - SSH v2 指紋の場合は ~/.ssh/known_hosts2 + 指紋は ~/.ssh/known_hosts に保存されます。 - デフォルトでは、OpenSSH - サーバはの最近の版では SSH v2 - のみの接続を受け付けるように設定されています。 - クライアントはバージョン 1 および 2 のどちらかを選択できます。 - バージョン 2 は、旧バージョンよりも堅固で安全です。 - - &man.ssh.1; コマンドに、プロトコル v1 と v2 + デフォルトでは、&man.sshd.8; + の最近の版では SSH v2 + の接続のみを受け付けるように設定されています。 + クライアントは可能であればバージョン 2 を用い、 + バージョン 1 にフォールバックします。 + クライアントは、プロトコル v1 と v2 についてそれぞれ、引数 または - を渡すことで、利用するプロトコルを強制できます。 + を渡すことで、利用するプロトコルを指定できます。 + クライアントにおけるバージョン 1 への互換性は、 + 古いバージョンへの上位互換のために維持されています。 @@ -3550,13 +3128,12 @@ user@example.com's password: ******* secure copy - scp + &man.scp.1; - &man.scp.1; コマンドは - &man.rcp.1; と同様に働きます。 - 安全な方法で行っているほかは、ローカルのファイルをリモートマシンへ、 - あるいはリモートマシンのファイルをローカルにコピーするのは同じです。 + ローカルのファイルをリモートマシンへ、 + あるいはリモートマシンのファイルをローカルに安全な方法でコピーするには、 + &man.scp.1; を使用してください。 &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: ******* @@ -3568,10 +3145,11 @@ COPYRIGHT 100% |*****************************| 4735 この &man.scp.1; を使う時に検証が行なわれます。 &man.scp.1; に渡される引数は、&man.cp.1; - のものと似ており、ファイル (1 つまたは複数) が + のものと似ており、コピーするファイル (1 つまたは複数) が 1 つめの引数になり、コピー先が 2 つめの引数になります。 - ファイルはネットワーク越しに SSH を通して送られるので、 - 引数に指定するファイルには + ファイルはネットワーク越しに SSH + 接続を通して送られるので、 + 引数に指定するファイルに という形式をとるものがあります。 @@ -3586,26 +3164,21 @@ COPYRIGHT 100% |*****************************| 4735 システム全体の設定ファイルは、OpenSSH デーモン、クライアントの両方とも - /etc/ssh - ディレクトリにあります。 + /etc/ssh にあります。 ssh_config はクライアントの動作設定、 sshd_config - はデーモンの動作設定を行ないます。 - - さらに、rc.conf オプションの - - (デフォルトは /usr/sbin/sshd) と - - により、詳細な設定が行えます。 + はデーモンの動作設定を行ないます。 + それぞれのファイル毎にマニュアルページが用意されており、 + 利用可能な設定オプションについて説明されています。 - <application>ssh-keygen</application> + &man.ssh-keygen.1; パスワードの代わりに &man.ssh-keygen.1; - を使ってユーザの認証用の DSA または - RSA 暗号鍵を作ることができます。 + を使ってユーザの認証用の DSA または + RSA 暗号鍵を作ることができます。 &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. @@ -3630,20 +3203,41 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com リモートマシンの ~/.ssh/authorized_keys ファイルに含まれてなければなりません。 - これでパスワードの代わり - SSH 鍵を使ってリモートマシンに接続できるようになったはずです。 + この設定により、パスワードに代わり、 + SSH + 鍵を使ってリモートマシンに接続できるようになります。 + + 多くのユーザは、鍵が設計上安全と信じ、 + パスフレーズなしに鍵を利用しています。 + このような使用方法は 危険 です。 + 管理者が鍵にパスフレーズが設定されているかを確認する方法は、 + 手動で鍵を調べる方法です。 + 秘密鍵のファイルに ENCRYPTED + という単語が含まれている場合には、 + 鍵の所有者は、パスフレーズを使用しています。 + 弱いパスフレーズが使われている間、 + 少なくともシステムが危険にさらされているときには、 + 他のサイトへのアクセスには、 + あるレベルでのパスワード類推が必要となります。 + さらに、公開鍵ファイルに from を含めることで、 + エンドユーザをより安全にできます。 + たとえば、 + ssh-rsa または rsa-dsa の前に、 + from="192.168.10.5 を加えることで、 + この IP + を持つホストからのユーザのみがアクセスできるようになります。 + + &man.ssh-keygen.1; でパスフレーズを使っている場合は、 秘密鍵を使うためにユーザは毎回パスフレーズを入力する必要があります。 長いパスフレーズを毎回入力しなくてはならない負担は、 &man.ssh-agent.1; を使うと軽減できます。 これについては、 - 以下の - の節で説明されています。 + で説明されています。 - システムにインストールされている - OpenSSH のバージョンによって、 + OpenSSH のバージョンによって、 オプションやファイルに違いが出てくることがあります。 &man.ssh-keygen.1; を参照して、 問題が起こることを避けてください。 @@ -3651,26 +3245,25 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com - <application>ssh-agent</application> および - <application>ssh-add</application> + SSH Agent による鍵のキャッシュ - &man.ssh-agent.1; および &man.ssh-add.1; ユーティリティは、 - パスフレーズを毎回入力することなしに、 + パスフレーズを毎回入力することなしに、 SSH - 鍵を利用できるようにメモリに読み込む方法を提供します。 + 鍵を利用できるようにメモリに読み込むには、 + &man.ssh-agent.1; および &man.ssh-add.1; を使用してください。 - &man.ssh-agent.1; ユーティリティは、 + &man.ssh-agent.1; は、 読み込まれた秘密鍵による認証を取り扱います。 &man.ssh-agent.1; は他のアプリケーションの起動に用いられる必要があります。 - 基本的なレベルではシェルを起動し、 - より高度なレベルでは、ウィンドウマネージャも起動します。 + 基本的なレベルではシェル、 + またはウィンドウマネージャを起動します。 シェル上で &man.ssh-agent.1; を使うには、 - まず引数としてシェルを起動する必要があります。 + 引数としてシェルを起動してください。 次に、&man.ssh-add.1; を実行し、 秘密鍵のパスフレーズを入力することにより、 - 鍵を追加する必要があります。 + 鍵を追加してください。 一度この過程を終えてしまえば、ユーザは、 対応する公開鍵が置かれているホストに &man.ssh.1; でログインできるようになります。 @@ -3682,26 +3275,29 @@ 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; を使うには、 + &xorg; 上で + &man.ssh-agent.1; を使うには、 &man.ssh-agent.1; への呼び出しが ~/.xinitrc に置かれている必要があります。 - これにより、X11 上で起動されるすべてのプログラムにおいて、 + これにより、&xorg; + 上で起動されるすべてのプログラムにおいて、 &man.ssh-agent.1; サービスが提供されるようになります。 ~/.xinitrc ファイルの例は以下となります。 exec ssh-agent startxfce4 - これで、X11 を開始するときにはいつでも + これで、&xorg; + を開始するときにはいつでも &man.ssh-agent.1; が起動され、 このプログラムから XFCE が起動されます。 - 一度この設定を行い、X11 を再起動した後は有効になりますので、 - &man.ssh-add.1; を引数なしに実行し、 - すべての SSH 鍵を読み込ませてください。 + &xorg; を再起動した後は有効になりますので、 + &man.ssh-add.1; を実行して、 + すべての SSH 鍵を読み込ませてください。 - SSH トンネリング + <acronym>SSH</acronym> トンネリング OpenSSH @@ -3711,23 +3307,21 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) OpenSSH は暗号化されたセッションの中に他のプロトコルをカプセル化するトンネルを作ることができます。 - 以下のコマンドは &man.ssh.1; で telnet + 以下のコマンドは &man.ssh.1; で &man.telnet.1; 用のトンネルを作成します。 &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; - ssh コマンドは、 - 次のオプションとともに利用します。 + この例では、以下のオプションを使っています。 - ssh にプロトコルバージョン 2 - を使うことを指示します。(古い SSH - サーバを使っているときには指定しないでください) + サーバへの接続に &man.ssh.1; バージョン 2 + を使うことを指示します。 @@ -3744,7 +3338,7 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) - ssh + &man.ssh.1; にバックグラウンド実行を強制します。 @@ -3763,15 +3357,18 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) - リモートの SSH サーバです。 + 指定したリモート SSH + サーバへログインに用いるログイン名。 - SSH のトンネルは localhost - の指定されたポートに listen + SSH のトンネルは + localhost の指定されたポートに listen するソケットを作ることで実現されています。 - SSH はローカルのホスト/ポートで受けた接続すべてを SSH + SSH + はローカルのホスト/ポートで受けた接続すべてを + SSH 接続経由で指定されたリモートホストのポートへ転送します。 この例では、localhost のポート @@ -3779,15 +3376,15 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) localhost のポート 23 に転送されるようになっています。 23 は - telnet なのでこれは SSH - トンネルを通るセキュアな telnet + &man.telnet.1; で用いられるので、これは SSH + トンネルを通る暗号化された man.telnet.1; セッションを作ります。 - このようにして SMTP や POP3, FTP 等のセキュアではない TCP - プロトコルをカプセル化することができます。 + このようにして SMTP や POP3 および FTP といったセキュアではない + TCP プロトコルをカプセル化できます。 - SSH を用いた SMTP 用の安全なトンネルの作成 + &man.ssh.1; を用いた SMTP 用の安全なトンネルの作成 &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com @@ -3799,26 +3396,25 @@ Escape character is '^]'. 220 mailserver.example.com ESMTP &man.ssh-keygen.1; - と別のユーザアカウントを組み合わせて使うことでより透過的で悩まずに済むような - SSH のトンネル環境を作ることができます。 + と別のユーザアカウントを組み合わせて使うことでより透過的な + SSH のトンネル環境を作ることができます。 パスワードを入力するところで暗号鍵を使い、 トンネルは別のユーザ権限で実行することが可能です。 - 実用的な SSH トンネルの例 + 実用的な <acronym>SSH</acronym> トンネルの例 POP3 サーバへの安全な接続 - 仕事で、外部からの接続を受ける SSH サーバがあるとします。 - 同じオフィスのネットワークには、POP3 + ここでの例は、外部からの接続を受ける + SSH サーバがあるとします。 + 同じネットワークには、POP3 サーバが動いているメールサーバがあるとします。 - ネットワークもしくはあなたの家とオフィスの間のネットワーク経路は、 - 完全に信頼できるものかもしれませんし、そうではないかもしれません。 - そのため、 - 電子メールは安全なやり方で見るようにしなければなりません。 - 解決策は、オフィスの SSH サーバへの SSH 接続を行い、 + 電子メールを安全なやり方で見るようにするには、 + SSH サーバへの SSH + 接続を行い、 メールサーバへのトンネルを作成することです。 &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com @@ -3826,7 +3422,7 @@ user@ssh-server.example.com's password: ****** トンネルが作成されて動作したら、 メールクライアントに対し localhost - のポート 2110 に POP3 リクエストを送るように指示できます。 + のポート 2110 に POP3 リクエストを送るように指示してください。 そこへの接続は、トンネルを経由して安全に mail.example.com に転送されます。 @@ -3834,30 +3430,23 @@ user@ssh-server.example.com's password: ****** 厳格なファイアウォールをすり抜ける - 内向けの接続をフィルタするだけでなく、 - 外向けの接続もフィルタして、 - 極端に厳しいファイアウォールルールを課すネットワーク管理者もいます。 - リモートのマシンには、SSH 接続と web サーフィンのための - 22 番および 80 - 番ポートにしか接続させてもらえないかもしれません。 - - あなたは、それ以外の (もしかすると仕事に関係ない) - サービスにアクセスしたくなるかもしれません。 - 例えば、音楽ストリーミングを行う - Ogg Vorbis サーバといったものです。 - この Ogg Vorbis サーバが 22 番または - 80 番ポート以外でストリーミングを行っていたら、 - あなたはそのサーバに接続できないでしょう。 + 内向けおよび外向きの接続両方をフィルタするファイアウォールルールを課すネットワーク管理者もいます。 + たとえば、 + リモートのマシンからのアクセスに、&man.ssh.1; および + web サーフィンのための 22 番および 80 + 番ポートにしか接続させてもらえないかもしれません。 + この場合 22 または 80 + 番以外を使う他のサービスへのアクセスを妨げます。 それに対する解決策は、 あなたが接続しているネットワークのファイアウォールの外部にあるマシンに対して - SSH 接続を行い、Ogg Vorbis - サーバへのトンネルに利用することです。 + SSH 接続を行い、 + 希望するサービスへのトンネルに利用することです。 &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* - ストリーミングクライアントを + この例では、ストリーミング Ogg Vorbis クライアントを localhost の 8888 番ポートに向けると、 music.example.com の 8000 番ポートに転送され、ファイアウォールをすり抜けられます。 @@ -3868,21 +3457,19 @@ user@unfirewalled-system.example.org's password: *******< <varname>AllowUsers</varname> オプション - ログインできるユーザや接続元を制限することは、 - 通常は良い考えです。 - AllowUsers オプションは、 - この目的のために使うことができます。 + ログインできるユーザや接続元を AllowUsers + を使って制限することは、通常は良い考えです。 たとえば、 - root ユーザが + root が 192.168.1.32 からのみログインできるようにするには、 - /etc/ssh/sshd_config - ファイルの設定は以下のようになります。 + 以下の行を /etc/ssh/sshd_config + に追加してください。 AllowUsers root@192.168.1.32 admin - ユーザがどこからでもログインできるようにするには、 + がどこからでもログインできるようにするには、 ユーザ名そのものを記述してください。 AllowUsers admin @@ -3907,13 +3494,15 @@ user@unfirewalled-system.example.org's password: *******< もっと詳しく知りたい人へ - OpenSSH + OpenSSH + ウェブサイト - &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; - &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; + クライアントオプションについて + &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; + サーバオプションについて + &man.sshd.8;, &man.sftp-server.8;, &man.sshd.config.5; @@ -3929,27 +3518,25 @@ user@unfirewalled-system.example.org's password: *******< ACL - スナップショットのようなファイルシステムの拡張と連携して、 - FreeBSD ではファイルシステムアクセス制御リスト - (ACL) によるセキュリティを提供しています。 + アクセス制御リスト (ACL) + は、標準的な &unix; のパーミッションモデルを、 + &posix;.1e に互換する方法で拡張しています。 + これにより、管理者がより洗練されたセキュリティモデルを利用し、 + その恩恵を受けられるようになります。 - アクセス制御リストは、標準的な &unix; のパーミッションモデルを、 - 非常に互換性の高い (&posix;.1e) やり方で拡張しています。 - この機能は、管理者がより洗練されたセキュリティモデルを利用し、 - その恩恵を受けられるようにします。 - - UFS ファイルシステム用の - ACL サポートを有効にするには、 - 次のオプションをカーネルに組み込まなければなりません。 + &os; の GENERIC カーネルは、 + UFS ファイルシステム用の + ACL サポートを提供します。 + カスタムカーネルをコンパイルして使用するユーザは、 + カスタムカーネルのコンフィグレーションファイルに以下を追加してください。 options UFS_ACL もしこのオプションが組み込まれていなければ、ACL に対応したファイルシステムをマウントしようとすると、 - 警告が表示されます。このオプションは GENERIC - カーネルに含まれています。ACL + 警告が表示されます。ACL は、ファイルシステムの拡張属性が有効になっていることに依存しています。 - 拡張属性は、次世代 &unix; ファイルシステムである UFS2 + 拡張属性は、UFS2 でネイティブ対応されています。 UFS1 に拡張属性を付すように設定するのは、 @@ -3957,9 +3544,8 @@ user@unfirewalled-system.example.org's password: *******< よりも高いレベルの管理オーバヘッドが必要になります。 また、UFS2 における拡張属性のパフォーマンスも大きく上がっています。 - その結果、アクセス制御リストを利用する上では、一般的には - UFS1 よりも UFS2 - の方がおすすめです。 + そのため、アクセス制御リストを利用する上では UFS2 + を使うことが推奨されます。 ACL は、マウント時の管理フラグ で有効にされます。 @@ -3972,9 +3558,9 @@ user@unfirewalled-system.example.org's password: *******< - マウント時に指定した ACL フラグは再マウント - (&man.mount.8; ) 時に変更できません。完全に - &man.umount.8; した上で、新たに &man.mount.8; + マウント時に指定した ACL フラグは + による再マウントでは変更できません。 + 完全に &man.umount.8; した上で、新たに &man.mount.8; するしかありません。これは、起動後にルートファイルシステムで ACL を有効にできないことを意味します。 また、ファイルシステムを利用し始めた後では、 @@ -3987,20 +3573,16 @@ user@unfirewalled-system.example.org's password: *******< ACL が有効な状態でマウントされます。 こうすることで、ファイルシステムを ACL を有効にしないままマウントしてしまい、ACL - が正しくないかたちで強制され、 - セキュリティ問題につながることを防ぎます。 + が正しくないかたちで強制されるセキュリティの問題を防ぎます。 - ACL の動作を変更して、まったく新たに - &man.mount.8; - を行わなくてもフラグを有効にできるようにすることも可能でしょう。 - しかし、我々は、うっかり ACL - を有効にしないでマウントしてしまうのを防ぐようにした方が望ましいと考えました。 + 予期せず ACL + を有効にしないでマウントしてしまうことを防ぐことが望まれます。 ACL を有効にし、その後無効にしてから、 拡張属性を取り消さないでまた有効にしてしまうと、 - 鬱陶しい状態に自分で入り込んでしまえるからです。 + 大変な状況になってしまいます。 一般的には、一度ファイルシステムで ACL を有効にしたら、無効にすべきではありません。そうしてしまうと、 ファイル保護がシステムのユーザの意図と齟齬をきたす可能性があるばかりか、 @@ -4020,20 +3602,20 @@ 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 + 一方 public_html は対象外です。 <acronym>ACL</acronym> を利用する - &man.getfacl.1; ユーティリティは、 + &man.getfacl.1; は、 ファイルシステムの ACL を表示します。 - たとえば、test ファイルの + たとえば、test の ACL 設定を表示するには、 以下のコマンドを実行してください。 @@ -4046,32 +3628,30 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html other::r-- このファイルの ACL 設定を変更するには、 - 以下のように &man.setfacl.1; - ユーティリティを使用してください。 + &man.setfacl.1; を使用してください。 &prompt.user; setfacl -k test - フラグは、 - ファイルまたはファイルシステムから、現在設定されている - ACL をすべて取り除きます。 - より好ましい方法は、 + ファイルまたはファイルシステムから、 + 現在設定されている ACL + をすべて取り除くには、 を使ってください。 + しかしながら、より好ましい方法は、 を使う方法です。 このオプションを使うと、ACL が動作するのに必要な基本のフィールドは残ります。 &prompt.user; setfacl -m u:trhodes:rwx,group:web:r--,o::--- test - 上記のコマンドにおいて、 - オプションは、デフォルト ACL + この例では、 + は、デフォルト ACL エントリを修正するために使われています。 先ほどのコマンドで設定は削除されたため、 定義されたエントリはありません。 このコマンドは、デフォルトオプションに戻し、 指定したオプションを割り当てます。 システムに存在しないユーザまたはグループを追加すると、 - Invalid argument エラーが - stdout - に出力されることに気を付けてください。 + Invalid argument + エラーが出力されてしまいます。 @@ -4089,7 +3669,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html - Portaudit + portaudit 近年、セキュリティの分野では、 @@ -4105,7 +3685,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html &os; プロジェクトの能力を超えています。 サードパーティ製ユーティリティに関わる脆弱性を軽減し、 管理者に対し、既知のセキュリティ問題について警告する方法が存在します。 - &os; には、Portaudit + &os; には、portaudit と呼ばれる追加のユーティリティが、 この目的のために用意されています。 @@ -4115,20 +3695,20 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html 開発者がアップデートし、管理している、 既知のセキュリティ問題に対するデータベースを入手します。 - Portaudit を使うには、 - Ports Collection からインストールしてください。 + Ports Collection から portaudit + をインストールするには、以下のように実行してください。 &prompt.root; cd /usr/ports/ports-mgmt/portaudit && make install clean - インストールの過程で、 + インストールの途中で、 &man.periodic.8; の設定ファイルはアップデートされ、 - 毎日のセキュリティに関するスクリプトの実行中において - Portaudit - による出力が行われるようになります。 + 毎日のセキュリティに関するスクリプトの実行中に + portaudit + が出力するように設定されます。 毎日のセキュリティに関するスクリプトの実行結果のメールが読めることを確認してください。 このメールは、root アカウントに送られます。 - この時点では、設定は必要ありません。 + 他の設定は必要ありません。 インストールが終わったら、管理者は以下のコマンドを実行することで、 データベースをアップデートし、インストールされている @@ -4138,19 +3718,20 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html データベースは、 - &man.periodic.8; の実行中に自動的にアップデートされるので、 - 先のコマンドを実行することは完全に任意です。 - 以下の説明のためだけに必要です。 + &man.periodic.8; の実行中に自動的にアップデートされます。 + 先程のコマンドの実行は任意で、 + データベースを手動で直ちにアップデートするときに使われます。 Ports Collection からインストールされたサードパーティ製ユーティリティを監査するには、 - 管理者は以下のコマンドだけを実行する必要があります。 + 管理者は以下のコマンドを実行する必要があります。 &prompt.root; portaudit -a - Portaudit は、脆弱性のある package - について以下のような出力を行います。 + portaudit は、インストールされている + package の中で、 + 脆弱性のあるものについて以下のようなメッセージを出力します。 Affected package: cups-base-1.1.22.0_1 Type of problem: cups-base -- HPGL buffer overflow vulnerability. @@ -4162,13 +3743,13 @@ You are advised to update or deinstall the affected package(s) immediately.表示されている URL をウェブブラウザで開くと、管理者は、 - 問題となっている脆弱性についてより多くの情報を得ることができます。 + 脆弱性についてより多くの情報を得ることができます。 ここでの出力では、影響するバージョンが - &os; Port バージョンにより示され、 + &os; の port バージョンにより示され、 セキュリティ勧告を含む他のウェブサイトが含まれています。 - 一口にいうと、Portaudit は強力で、 - Portupgrade port + portaudit は強力で、 + portmaster port と共に使うときわめて有用なユーティリティです。 @@ -4186,7 +3767,7 @@ You are advised to update or deinstall the affected package(s) immediately. - FreeBSD セキュリティ勧告 + &os; セキュリティ勧告 多くの高品質なオペレーティングシステムと同様、 @@ -4200,9 +3781,8 @@ You are advised to update or deinstall the affected package(s) immediately. セキュリティ勧告はどのようなものか？ - &os; セキュリティ勧告は、以下のようなものです。 - 以下は &a.security-notifications.name; - メーリングリストに流れたものです。 + &os; セキュリティ勧告では、 + 以下のようなフォーマットが用いられています。 ============================================================================= FreeBSD-SA-XX:XX.UTIL Security Advisory @@ -4255,10 +3835,10 @@ VII. References - Topic フィールドは、 - 何が問題であるかを正確に示しています。 - 通常は、このセキュリティ勧告の導入部であり、 - 脆弱性のあるユーティリティを示します。 + Topic フィールドでは、 + 問題について明記されています。 + セキュリティ勧告の導入部であり、 + 脆弱性に影響されるユーティリティを示します。 @@ -4270,18 +3850,17 @@ VII. References &os; オペレーティングシステムの core コンポーネントに影響する脆弱性であることを意味します。 contrib カテゴリは、 - sendmail + Sendmail のように、&os; の外で開発され、&os; プロジェクトに取り込まれたソフトウェアに影響する脆弱性であることを意味します。 - ports カテゴリは、Ports Collection として、 - インストールされるソフトウェアに影響する脆弱性であることを示しています。 + ports カテゴリは、Ports Collection + からインストールされるソフトウェアに影響する脆弱性であることを示しています。 Module フィールドは、 - (たとえば sys といった) - 影響するコンポーネントを参照します。 - この場合、sys + 影響するコンポーネントについて言及します。 + この例では、sys モジュールに影響することがわかります。 そのため、この脆弱性は、 カーネルの中で使われるコンポーネントに影響します。 @@ -4305,13 +3884,14 @@ VII. References Affects フィールドは、この脆弱性がどの &os; リリースに影響するかを説明します。 カーネルでは、影響するファイルに対して - ident を実行すると、 + &man.ident.1; を実行すると、 その出力からリビジョンを簡単に確認できます。 ports の場合には、 /var/db/pkg の port の名前の後に、バージョン番号が示されています。 もし、システムが &os; Subversion - リポジトリと同期し、再構築が毎日行われているような状況でなければ、 + リポジトリと同期していなかったり、 + 再構築が毎日行われているような状況でなければ、 おそらく、そのシステムには影響しているでしょう。 @@ -4322,13 +3902,15 @@ VII. References - 共通の脆弱性データベースシステムにおいて、 + Common Vulnerabilities + and Exposures データベースにおいて、 脆弱性を探すために使用できる識別情報を示します。 Background フィールドは、 - 影響しているユーティリティがどのようなものであるかといった情報を正確に示します。 + 影響しているユーティリティに関する情報を示します。 大体の場合は、なぜユーティリティが &os; に存在するか、 何のために使われているか、 どのように用いられるようになってきたか、 @@ -4355,14 +3937,12 @@ VII. References Workaround フィールドは、 + 時間による制限や、ネットワークの可用性または他の理由により、 システムをアップグレードできないシステム管理者に対して、 - 実現可能な回避方法を提供します。 - これは、時間による制限や、ネットワークの可用性、 - 他のたくさんの理由によります。 - このような理由にかかわらず、 - セキュリティを甘く見るべきではありません。 - 影響するシステムは、パッチが当てられるか、 - セキュリティホールの回避方法が実行されるべきです。 + 回避方法を提供します。 + セキュリティを甘く見るべきではなく、 + 影響するシステムにはパッチを当てるか、 + セキュリティホールの回避方法を実行すべきです。 @@ -4423,8 +4003,8 @@ VII. References プロセスアカウンティングを有効にする プロセスアカウンティングを使用する前に、 - プロセスアカウンティングを有効にしておく必要があります。 - 有効にするには、以下のコマンドを実行してください。 + 以下のコマンドを使って、 + プロセスアカウンティングを有効にしておく必要があります。 &prompt.root; touch /var/account/acct @@ -4432,33 +4012,159 @@ VII. References &prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf - 有効に設定すると、アカウンティングは、 - CPU の統計、コマンドなどの追跡を開始します。 + 一度有効に設定すると、アカウンティングは、 + CPU の統計、 + 実行されたコマンドの情報の追跡を開始します。 すべてのアカウンティングログは、 - 人が読めるような形式ではないので、 - &man.sa.8; ユーティリティを使って見ることになります。 + 人が読めるような形式ではなく、 + &man.sa.8; を使って見ることができます。 オプションを設定せずに実行すると、 - sa はユーザコールの数、全経過時間 (分)、 - 全 CPU およびユーザの時間 (分)、 + &man.sa.8; はユーザコールの数、全経過時間 (分)、 + 全 CPU、ユーザの時間 (分)、および I/O 操作の平均数などを出力します。 実行されたコマンドに関する情報を見るには、 - &man.lastcomm.1; ユーティリティを使ってください。 - lastcomm コマンドを使うと、 - ユーザが特定の &man.ttys.5; で実行したコマンドを出力できます。 - 以下はその例です。 + &man.lastcomm.1; を使ってください。 + このコマンドは、 + ユーザが特定の &man.ttys.5; で実行したコマンドを出力します。 + たとえば、以下のコマンドは ttyp1 + ターミナル上で trhodes + が実行した &man.ls.1; + の使用について、記録されているすべて示します。 &prompt.root; lastcomm ls trhodes ttyp1 - このコマンドを実行すると、ttyp1 - ターミナル上で trhodes - が実行した ls - の使用について、記録されているすべて示します。 - 他にも有用なオプションが多くあり、 - &man.lastcomm.1;, &man.acct.5; および &man.sa.8; マニュアルページで - 説明されています。 + &man.lastcomm.1;, &man.acct.5; および &man.sa.8; + で説明されています。 + + + + リソースの制限 + + + + + Tom + Rhodes + + 寄稿: + + + + + + リソースの制限 + + + 長年にわたり &os; は、 + リソースを制限するためのデータベースとしてフラットファイル形式の + /etc/login.conf により管理していました。 + この方法は、現在でも使われていますが、 + リソースを管理する方法としては最適な方法でないことが、 + 以前から議論されています。 + フラットファイル形式では、 + クラスとして知られるグループラベルにユーザを分類する必要があります。 + この場合、フラットファイルだけではなく、 + パスワードデータベースに対しても変更が必要となります。 + 潜在的に、より多くの制限を加えられたユーザ対してはラベルの追加や、 + cap_mkdb + を使ったリソースデータベースの構築、 + /etc/master.passwd + ファイルへの変更が必要となります。 + さらに、パスワードデータベースは、 + pwd_mkdb を使って再構築する必要があります。 + この複数回に渡るプロセスは、 + 多くのユーザについて設定する必要がある場合には、 + 大変な時間の浪費につながる可能性があります。 + + &os; の新しいコマンドである &man.rctl.8; は、 + ユーザに対して、 + よりきめ細かにリソースの制限を管理する方法を提供します。 + このコマンドは、ユーザだけではなく、プロセス、jails + およびオリジナルのログインクラスに対してもリソースの制限を行うことができます。 + これらの高度な機能は、管理者およびユーザに対し、 + リソースをコマンドラインで管理したり、 + 設定ファイルを用いることで、システムの初期化時に、 + ルールを設定する方法を提供します。 + + この機能を有効にするには、以下の行を + GENERIC + またはカスタムカーネルコンフィグレーションファイルに追加し、 + 再構築してください。 + + options RACCT +options RCTL + + その後、システムの再起動が必要になります。 + この過程の手順については、 をご覧ください。 + これらの準備が完了すると、rctl + を用いてシステムにルールを設定できるようになります。 + + ルールの構文は簡単で、 + subject, subject-id, + resource および action + を使って管理されます。 + 以下のルールの例を参照してください。 + + user:trhodes:maxproc:deny=10/user + + これは基本的なルールです。 + ここで、subject は user、 + subject-id は trhodes です。 + maxproc はもちろんプロセスの最大数であり、action です。 + ここで action は、deny と設定されており、 + 新しいプロセスの生成がブロックされます。 + この例では、ユーザ trhodes のプロセスは + 10 個に制限され、それ以上のプロセスは作成できません。 + コンソールにログを出力したり、 + &man.devd.8; に対し通知したり、プロセスに sigterm を送ったりといった、 + 他の action も利用できます。 + + ルールを追加する際には、注意すべき点がいくつかあります。 + 上の例では、ログインして screen + セッションを実行してしまうと、 + 不幸にもユーザは最も簡単なタスクの実行ですらブロックされてしまうでしょう。 + リソースの制限が適応されると、エラーが出力されます。 + この例では以下のような出力が行われます。 + + &prompt.user; man test + /usr/bin/man: Cannot fork: Resource temporarily unavailable +eval: Cannot fork: Resource temporarily unavailable + + 他の例としては、&man.rctl.8; を使って + jail がメモリの制限を超えることを防ぐことができます。 + このルールは以下のように書くことができます。 + + &prompt.root; rctl -a jail:httpd:memoryuse:deny=2G/jail + + ルールを /etc/rctl.conf ファイルに追加すると、 + 再起動してもルールは持続します。 + フォーマットは、ルールから最初のコマンドの部分を除いたものとなります。 + たとえば、上のルールを追加するには、 + 以下のように追加してください。 + + # Block jail from using more than 2G memory: +jail:httpd:memoryuse:deny=2G/jail + + ルールを削除するには、rctl に対し、 + リストから削除するように指定してください。 + + &prompt.root; rctl -r user:trhodes:maxproc:deny=10/user + + マニュアルページには、 + ルールをすべて削除する方法が記載されています。 + しかしながら、特定のユーザのルールをすべて削除するには、 + 以下のようなコマンドを実行してください。 + + &prompt.root; rctl -r user:trhodes + + subjects + をコントロールするリソースは他にも多く用意されています。 + これらについて知るには、&man.rctl.8; をご覧ください。 +