os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Merge the following from the english version.

Browse source 
1.77 -> 1.81	doc/ja_JP.eucJP/books/handbook/security/chapter.sgml

Submitted by:	Hiroo Ono <hiroo _at_ jp dot FreeBSD dot org>
Reference :	[doc-jp-work 1708]
This commit is contained in:
Ryusuke SUZUKI 2010-12-04 01:10:28 +00:00
parent a33dfffd5e
commit 8ab3d17d1b
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=36662
1 changed files with 170 additions and 156 deletions

326
ja_JP.eucJP/books/handbook/security/chapter.sgml
View file

@ -2,7 +2,7 @@
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
Original revision: 1.77
Original revision: 1.81
Waiting for: 1.123 or mac/chapter.sgml
("mac" referenced from disks).
$FreeBSD$
@ -232,6 +232,14 @@
<sect1 id="securing-freebsd">
<title>FreeBSDの安全性を高める</title>
<note>
<title>コマンド対プロトコル</title>
<para>この文書を通して、コマンドまたはアプリケーションを指すのには
<application>太字</application> を使います。
たとえばプロトコルであると同時にコマンドでもある
ssh などに対して使います。</para>
</note>
<indexterm>
<primary>セキュリティ</primary>
<secondary>安全性を高める</secondary>
@ -262,6 +270,9 @@
されているか確認してください。そうすると、
<command>telnet</command> や <command>rlogin</command> 経由では
root で直接ログインできないようになります。
これは、<filename>/etc/ssh/sshd_config</filename> を編集して
<literal>PermitRootLogin</literal> に <literal>NO</literal>
が設定されるようにすることで実現できます。
<application>sshd</application> のような、別のログインサービス
を使っている場合でも同様に、直接 root へログインすることを許し
ていないかどうか確認してください。すべてのアクセス手段 &ndash;
@ -279,38 +290,41 @@
必要であるようにしておくことが重要です。root でアクセス可能と
する方法の一つとして、適切なスタッフアカウントを
(<filename>/etc/group</filename> 中の)
<literal>wheel</literal> グループに加えることがありま
す。<literal>wheel</literal> グループに入っているスタッフメン
バは <literal>su</literal> を使って root になることが許されま
す。パスワードエントリにおいて、スタッフメンバを
<literal>wheel</literal> グループに置くことによって直接 wheel
権限を与えてはいけません。スタッフメンバのアカウントは
<literal>staff</literal> グループに所属させるべきで、そして
<groupname>wheel</groupname> グループに加えることがあります。
<groupname>wheel</groupname> グループに入っているスタッフメンバは
<command>su</command> を使って
<username>root</username> になることが許されます。
パスワードエントリにおいて、スタッフメンバを
<groupname>wheel</groupname> グループに置くことによって直接
wheel 権限を与えてはいけません。スタッフメンバのアカウントは
<groupname>staff</groupname> グループに所属させるべきで、その上で
<filename>/etc/group</filename> ファイルを通して
<literal>wheel</literal> グループに加えるべきです。実際に root
アクセスの必要なスタッフメンバのみ <literal>wheel</literal> グ
ループに置くようにすべきです。他の認証方法の場合、たとえば
<groupname>wheel</groupname> グループに加えるべきです。実際に
<username>root</username> アクセスの必要なスタッフメンバのみ
<groupname>wheel</groupname> グループに置くようにすべきです。
他の認証方法の場合、たとえば
kerberos を使用する場合には、root アカウントの
<filename>.k5login</filename> ファイルを使って、誰も
<literal>wheel</literal> グループに置く必要なく &man.ksu.1; を
使って root になることを許すようにすることもできます。このやり
<groupname>wheel</groupname> グループに置く必要なく &man.ksu.1;
を使って root になることを許すようにすることもできます。このやり
方はよりよい解決策なのかもしれません。なぜなら、
<literal>wheel</literal> のメカニズムでは、侵入者がパスワード
ファイルを手に入れ、スタッフアカウントのいずれか 1 つを破るこ
とができると、root を破ることがまだできてしまうからです。
<literal>wheel</literal> のメカニズムを用いる方が、何もしない
よりは良いのですが、必ずしも最も安全な選択肢とは限りません。
</para>
<groupname>wheel</groupname> のメカニズムを用いる方が、
何もしないよりは良いのですが、
必ずしも最も安全な選択肢とは限りません。</para>
<para>スタッフのアカウント、また究極には root アカウントの安全性
を高める間接的な方法は、別のログインアクセスの方法を用いてスタッ
フのアカウントの安全性を高め、その上でそのスタッフのアカウント
の暗号化パスワードを <literal>*</literal> にしておくものです。
の暗号化パスワードを <quote>アスタリスク化</quote>
するものです。
&man.vipw.8; コマンドを使えば、暗号化されたパスワードを
<literal>*</literal> 一文字に置き換えられます。このコマンドは、
<filename>/etc/master.passwd</filename> ファイルとユーザ/パス
ワードデータベースを更新して、パスワード認証によるログインがで
きないようにします。</para>
<quote><literal>*</literal></quote> 1 文字に置き換えられます。
このコマンドは、<filename>/etc/master.passwd</filename>
ファイルとユーザ/パスワードデータベースを更新して、
パスワード認証によるログインができないようにします。</para>
<para>たとえば、次のスタッフアカウントを、</para>
@ -320,21 +334,23 @@
<programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
<para>暗号化されたパスワードは <literal>*</literal> と一致するこ
とがないので、この変更によって通常のログインはできなくなります。
<para>暗号化されたパスワードは
<quote><literal>*</literal></quote> と一致することがないので、
この変更によって通常のログインはできなくなります。
こうした後は、スタッフメンバは認証のために &man.kerberos.1; や
公開鍵 / 秘密鍵の組を用いる &man.ssh.1; のような代わりとなる認
証手段を利用しなければなりません。
Kerberos のようなログイン機構を使う場合は、一般に kerberos サー
バを実行するマシンと自分のデスクトップワークステーションの安全
性を確保しなければなりません。
また <application>ssh</application> で公開鍵 / 秘密鍵の組を使う場合、
また ssh で公開鍵 / 秘密鍵の組を使う場合、
一般に、<emphasis>ログイン元</emphasis>マシン (通常は自分のワー
クステーション) の安全性を確保しなければなりません。ここで、
&man.ssh-keygen.1; で公開鍵 / 秘密鍵の組を生成する際、鍵の組
をパスワードで防御することにより、鍵の組への防御層を追加するこ
ともできます。スタッフアカウントのパスワードを
<literal>*</literal> でつぶすことができると、管理者自身が設定
<quote>アスタリスク</quote> でつぶすことができると、
管理者自身が設定
した安全性の高い方法でしかスタッフメンバがログインできないこと
も保証できます。こうして、多くの侵入者が使う重大なセキュリティ
の穴である、
@ -406,7 +422,8 @@
<para>用心深いシステム管理者は、自分に必要なサーバプロセスだけを
過不足なく実行させるものです。サードパーティ製のサーバは、よくバグを持っ
ていがちだということに注意して下さい。たとえば、古いバージョンの
<application>imapd</application> や popper
<application>imapd</application> や
<application>popper</application>
を実行させておくのは、全世界に万能の root
の切符を与えているようなものです。自分で注意深くチェックしていない
サーバは、決して実行してはいけません。root で実行させる必要の
@ -499,15 +516,16 @@
<title>ユーザアカウントの安全性を高める</title>
<para>ユーザアカウントは、普通、安全性を高めることが最も困難です。
スタッフに対しては、とても厳格なアクセス制限を強制しパスワード
を <literal>*</literal> で外すことができるでしょうが、管理者が
スタッフに対しては、とても厳格なアクセス制限を強制しパスワードを
<quote>アスタリスク</quote> で外すことができるでしょうが、
管理者が
持ちうる一般ユーザすべてのアカウントに対して同じことはできない
かもしれません。管理者が十分に統率をとることができるなら、管理
者は勝利し、ユーザのアカウントの安全を適切に確保できるかもしれ
ません。それができないならば、よりいっそう気を配って一般ユーザ
のアカウントを監視するよりほかありません。一般ユーザアカウント
に対し <application>ssh</application> や kerberos を利用するこ
とには、システム管理がさらに増えたりテクニカルサポートが必要に
のアカウントを監視するよりほかありません。
一般ユーザアカウントに対し ssh や kerberos を利用することには、
システム管理がさらに増えたりテクニカルサポートが必要に
なるなどの問題があります。それでも、暗号化パスワードファイルと
比較するとはるかに良い解です。</para>
</sect2>
@ -517,8 +535,8 @@
<para>できるだけ多くのパスワードを <literal>*</literal> で外し、
それらのアカウントのアクセスには
<application>ssh</application> や kerberos を使うようにするこ
とが、唯一の確実な方法です。暗号化パスワードファイル
ssh や kerberos を使うようにすることが、唯一の確実な方法です。
暗号化パスワードファイル
(<filename>/etc/spwd.db</filename>) は root でのみ読み出し可能
だといっても、侵入者が root の書き込み権限は得られなくとも、読
み出しアクセス権限を得ることは可能かもしれません。</para>
@ -611,10 +629,10 @@
するためには、一般的に、アクセスの制限されたマシンから実際に使っ
ている他のマシンへのかなりのアクセスを許す必要があります。普
通は、他のマシンからアクセス制限されたマシンへ読み込み専用の
NFS エクスポートをしたり、アクセス制限されたマシンから他のマシ
ンへ <application>ssh</application> を行なうために、
<application>ssh</application> 鍵のペアを作ったりすることで行
います。ネットワークのトラフィックを別にして、NFS は最も可視性
NFS エクスポートをしたり、アクセス制限されたマシンから他のマシンへ
ssh 接続を行なうために、
ssh 鍵のペアを作ったりすることで行います。
ネットワークのトラフィックを別にして、NFS は最も可視性
のない方法です &ndash; 各クライアント上のファイルシステムを、
事実上検出されずに監視できるようになります。アクセス制限された
サーバがスイッチを通してクライアントに接続されている場合、たい
@ -622,9 +640,7 @@
を通したり、いくつかのルーティング層を通したりしてクライアント
に接続する場合、
NFS は (ネットワークの面で) あまりにも危険な方法かもしれず、
<application>ssh</application> の方が認証を行った跡は残りますが、
より良い方法でしょう。
</para>
ssh の方が認証を行った跡は残りますが、より良い方法でしょう。</para>
<para>アクセス制限されたマシンに、監視しようとするクライアントシ
ステムへの少なくとも読み込みのアクセス権を与えたら、次に実際に
@ -642,17 +658,17 @@
当に suid されたバイナリや、新たに作成されたファイルや削除され
たファイルもチェックするでしょう。</para>
<para>NFS ではなく、<application>ssh</application> を使用する場
合は、セキュリティ用スクリプトを書くのはずっと難しいことで
<para>NFS ではなく、ssh を使用する場合は、
セキュリティ用スクリプトを書くのはずっと難しいことで
す。スクリプトを動かすためには、クライアントに対してスクリプト
を <command>scp</command> しなくてはいけませんし、それは目に見
えてしまいます。そして、安全のためには、スクリプトが使うバイナ
リ (find など) を <command>scp</command> する必要もあります。
クライアントの <application>ssh</application> デーモンはすでに
攻撃されてしまっているかもしれません。結局のところ、安全でない
リンク上の場合は <application>ssh</application> は必要かもしれ
ませんが、<application>ssh</application> を扱うのはとても大変
なことです。</para>
クライアントマシンの <application>ssh</application>
クライアントはすでに攻撃されてしまっているかもしれません。
結局のところ、安全でないリンク上の場合は
ssh は必要かもしれませんが、ssh
を扱うのはとても大変なことです。</para>
<para>優れたセキュリティ用スクリプトは、ユーザやスタッフメンバの
アクセス設定ファイルの変更もチェックするものです。
@ -855,15 +871,15 @@
<para>偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を
生じさせるために用いられることもあります。
<varname>net.inet.ip.rtexpire</varname>,
<literal>rtminexpire</literal>, <literal>rtmaxcache</literal>
<varname>rtminexpire</varname>, <varname>rtmaxcache</varname>
の <command>sysctl</command> パラメータを参照して下さい。でた
らめな送信元 IP アドレスを用いた偽造パケット攻撃により、カーネ
ルは、一時的なキャッシュ経路を経路情報テーブルに生成します。こ
れは <command>netstat -rna | fgrep W3</command> で見ることがで
きます。これらの経路は、普通は 1600 秒程度でタイムアウトになり
ます。カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを
検知すると、カーネルは動的に <literal>rtexpire</literal>
を減らしますが、<literal>rtminexpire</literal>
検知すると、カーネルは動的に <varname>rtexpire</varname>
を減らしますが、<varname>rtminexpire</varname>
より小さくなるようには決して減らしません。ここに問題が
2 つあります。</para>
@ -875,14 +891,13 @@
<listitem>
<para>カーネルが持続的攻撃に耐えられるほど十分
<literal>rtminexpire</literal> が低く設定されていないこと。
</para>
<varname>rtminexpire</varname> が低く設定されていないこと。</para>
</listitem>
</orderedlist>
<para>自分のサーバが T3 もしくはそれより高速の回線でインターネッ
トに接続されている場合、&man.sysctl.8; を用いて
<literal>rtexpire</literal> と <literal>rtminexpire</literal>
<varname>rtexpire</varname> と <varname>rtminexpire</varname>
とを手動で上書きしておくことが思慮深いことといえます。どちらか
一方でも 0 には決してしないで下さい (自分のマシンをクラッシュ
させたくないのであれば)。両パラメータを 2 秒
@ -895,10 +910,9 @@
<indexterm><primary><command>ssh</command></primary></indexterm>
<indexterm><primary>Kerberos</primary></indexterm>
<para>もしあなたが、kerberos および
<application>ssh</application> を使用したいのだとしたら、両者
に関して言っておく必要のある問題がいくつかあります。kerberos V
は大変優れた認証プロトコルですが、kerberos 化された
<para>もしあなたが、kerberos と ssh を使いたいのだとしたら、
両者に関して言っておかねばならない問題がいくつかあります。
kerberos V は大変優れた認証プロトコルですが、kerberos 化された
<application>telnet</application> や
<application>rlogin</application> は、バイナリストリームを扱う
のに不向きになってしまうようなバグがあります。さらに、デフォル
@ -907,30 +921,28 @@
<application>ssh</application> では、デフォルトですべてを暗号
化してくれます。</para>
<para><application>ssh</application> はあらゆる場面でとても良く
働いてくれます。ただし、デフォルトで暗号鍵を転送してしまうこと
<para>ssh はあらゆる場面でとても良く働いてくれます。
ただし、デフォルトで暗号鍵を転送してしまうこと
を除けばです。これはつまり、暗号鍵を持った安全なワークステーショ
ンがあって、この暗号鍵で残りのシステムとアクセスできるようになっ
ている場合に、安全でないマシンへ
<application>ssh</application> を行なう時に暗号鍵が見えてしま
うということです。実際の鍵そのものが見えてしまうわけではありま
せんが、<application>ssh</application> は、あなたが login
ssh 接続を行なう時に暗号鍵が見えてしまうということです。
実際の鍵そのものが見えてしまうわけではありませんが、
ssh はあなたが login
している間、転送用ポートを作ります。攻撃者が安全でないマシンの
root を破ったら、このポートを使って暗号鍵を取得し、
この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。
</para>
<para>スタッフのログインには、kerberos を組み合せた
<application>ssh</application> を使用することを勧めます。
ssh を使用することを勧めます。
<application>ssh</application> は、kerberos サポート機能と一緒
にコンパイルできます。こうすると、見えてしまうかもしれない
<application>ssh</application> 鍵をあまりあてにしないで良いよ
うになります。また、それと同時に、kerberos 経由でパスワードを
保護することもできます。<application>ssh</application> 鍵は、
安全なマシンからの自動化されたタスク (kerberos はこの用途には
不向きです) のみに使用するべきです。また、
<application>ssh</application> の設定で鍵転送をしないようにす
るか、あるいは、<application>ssh</application> が
ssh 鍵をあまりあてにしないで良いようになります。
また、それと同時に、kerberos 経由でパスワードを保護することもできます。
ssh 鍵は、安全なマシンからの自動化されたタスク
(kerberos はこの用途には不向きです) のみに使用するべきです。また、
ssh の設定で鍵転送をしないようにするか、あるいは ssh が
<filename>authorized_keys</filename> ファイル中に書くことを許
している <literal>from=IP/DOMAIN</literal> オプションを使用し
て、特定のマシンからログインしてきたときのみ鍵が有効であるよう
@ -1081,8 +1093,8 @@ lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -&gt; libdescrypt_p.a</s
パスフレーズ</quote>もしくは単に &ldquo;パスフレーズ&rdquo; と呼
ぶことにします。(訳注: ユーザが頭の中だけにしまっておくべきもの
が、この秘密のパスフレーズです。なお、原文ではこれをパスワードと
表記していますが、混乱を避けるために訳文ではすべて<quote> 秘密の
パスフレーズ</quote>に統一しています)。</para>
表記していますが、混乱を避けるために訳文ではすべて
<quote>秘密のパスフレーズ</quote> に統一しています)。</para>
<para>秘密のパスフレーズは、Unix
パスワードと何の関連性もありません。
@ -1178,8 +1190,9 @@ Again secret password:
ID unfurl s/key is 99 to17757
DEFY CLUB PRO NASH LACE SOFT</screen>
<para><prompt>Enter secret password:</prompt> というプロンプトに
対してあなたが考えた秘密のパスフレーズを入力します。このパスフ
<para><prompt>Enter secret password:</prompt>
というプロンプトに対して、
あなたが考えた秘密のパスフレーズを入力します。このパスフ
レーズはログインするときに使うものではなく、ログインするときに
使うワンタイムパスワードを生成するために使うものであることを覚
えておいてください。<quote>ID</quote> から始まる行は、S/Key に
@ -1472,14 +1485,15 @@ README krb.conf krb.realms</screen>
<para>まず、<filename>krb.conf</filename> と
<filename>krb.realms</filename>を編集してKerberosの 管理領域
(realm) を定義してください。
ここでは管理領域が<filename>GRONDAR.ZA</filename> で、
サーバ名が<filename>grunt.grondar.za</filename>であるとします。
ここでは管理領域が <filename>EXAMPLE.COM</filename>
で、サーバ名が <filename>grunt.example.com</filename>
であるとします。
<filename>krb.conf</filename>
というファイルを次のように編集してください。</para>
<screen>&prompt.root; <userinput>cat krb.conf</userinput>
GRONDAR.ZA
GRONDAR.ZA grunt.grondar.za admin server
EXAMPLE.COM
EXAMPLE.COM grunt.example.com admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
@ -1504,16 +1518,15 @@ ARC.NASA.GOV trident.arc.nasa.gov</screen>
これらの単語について詳しく知りたい場合には Kerberos
のマニュアルページをご覧ください。</para>
<para>ここで、
<filename>GRONDAR.ZA</filename>という管理領域に<hostid
role="fqdn">grunt.grondar.za</hostid> およびその他の<hostid
role="domainname">.grondar.za</hostid>
ドメインのすべてのホストを追加し なければなりません。
<filename>krb.realms</filename>は次のようになります。</para>
<para>ここで、<filename>EXAMPLE.COM</filename> という管理領域に
<hostid role="fqdn">grunt.example.com</hostid>
およびその他の <hostid role="domainname">.example.com</hostid>
ドメインのすべてのホストを追加しなければなりません。
<filename>krb.realms</filename> は次のようになります。</para>
<screen>&prompt.root; <userinput>cat krb.realms</userinput>
grunt.grondar.za GRONDAR.ZA
.grondar.za GRONDAR.ZA
grunt.example.com EXAMPLE.COM
.example.com EXAMPLE.COM
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDU</screen>
@ -1533,7 +1546,7 @@ grunt.grondar.za GRONDAR.ZA
マンドを次のように実行してください。</para>
<screen>&prompt.root; <userinput>kdb_init</userinput>
<prompt>Realm name [default ATHENA.MIT.EDU ]: </prompt> <userinput>GRONDAR.ZA</userinput>
<prompt>Realm name [default ATHENA.MIT.EDU ]:</prompt> <userinput>EXAMPLE.COM</userinput>
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
@ -1630,14 +1643,14 @@ Edit O.K.
<title>サーバファイルの作成</title>
<para>次に、各マシンにおけるサービスを定義している、
すべてのインスタンス を展開します。
これには<command>ext_srvtab</command>というコマンドを使用しま
す。このコマンドで作成されるファイルは、Kerberosの各クライアン
トの/etc/kerberosIVディレクトリに
<emphasis>安全な方法で</emphasis>コピーまたは
移動する必要があります。このファイルはそれぞれのサーバとクラ
イアントに存在しなければならず、
またKerberosの運用において重要なも のです。</para>
すべてのインスタンスを展開します。
これには <command>ext_srvtab</command> というコマンドを使用します。
このコマンドで作成されるファイルは、Kerberos
の各クライアントの <filename>/etc/kerberosIV</filename>
ディレクトリに<emphasis>安全な方法で</emphasis>
コピーまたは移動する必要があります。
このファイルはそれぞれのサーバとクライアントに存在しなければならず、
また Kerberos の運用において重要なものです。</para>
<screen>&prompt.root; <userinput>ext_srvtab grunt</userinput>
@ -1731,7 +1744,7 @@ Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: GRONDAR.ZA
Local realm: EXAMPLE.COM
&prompt.root; <userinput>kadmind -n &amp;</userinput>
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
@ -1746,7 +1759,7 @@ Master key entered. BEWARE!</screen>
<command>kinit</command>コマンドで得ることができます。</para>
<screen>&prompt.user; <userinput>kinit jane</userinput>
MIT Project Athena (grunt.grondar.za)
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane"
<prompt>Password:</prompt> </screen>
@ -1755,10 +1768,10 @@ Kerberos Initialization for "jane"
<screen>&prompt.user; <userinput>klist</userinput>
Ticket file: /tmp/tkt245
Principal: jane@GRONDAR.ZA
Principal: jane@EXAMPLE.COM
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA</screen>
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM</screen>
<para><command>passwd</command>
コマンドを用いてパスワードを変更して、
@ -1767,7 +1780,7 @@ Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA</screen>
ください。</para>
<screen>&prompt.user; <userinput>passwd</userinput>
realm GRONDAR.ZA
realm EXAMPLE.COM
<prompt>Old password for jane:</prompt>
<prompt>New Password for jane:</prompt>
Verifying password
@ -1822,7 +1835,7 @@ Edit O.K.
ちゃんと働いているかどうか確認しましょう。</para>
<screen>&prompt.root; <userinput>kinit jane.root</userinput>
MIT Project Athena (grunt.grondar.za)
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane.root"
<prompt>Password: </prompt></screen>
@ -1831,7 +1844,7 @@ Kerberos Initialization for "jane.root"
ファイルにユーザを追加する必要があります。</para>
<screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
jane.root@GRONDAR.ZA</screen>
jane.root@EXAMPLE.COM</screen>
<para><command>su</command>してみましょう。</para>
@ -1842,10 +1855,10 @@ jane.root@GRONDAR.ZA</screen>
<screen>&prompt.root; klist
Ticket file: /tmp/tkt_root_245
Principal: jane.root@GRONDAR.ZA
Principal: jane.root@EXAMPLE.COM
Issued Expires Principal
May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA</screen>
May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM</screen>
</sect2>
<sect2>
@ -1856,7 +1869,7 @@ May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA</screen>
うインスタンス付きで作成しました。
これはユーザと同じ名前をprincipalと しており、
Kerberosのデフォルトの値です;
<literal>&lt;username&gt;.</literal><literal>root</literal>
<literal>&lt;username&gt;.</literal><username>root</username>
という形式の
<literal>&lt;principal&gt;.&lt;instance&gt;</literal>で、
必要なエント
@ -1866,30 +1879,30 @@ May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA</screen>
<command>su</command>することができます。</para>
<screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
jane.root@GRONDAR.ZA</screen>
jane.root@EXAMPLE.COM</screen>
<para>同様に、ユーザのホームディレクトリの
<filename>.klogin</filename>ファイルに次の
ような行がある場合には</para>
<screen>&prompt.user; <userinput>cat ~/.klogin</userinput>
jane@GRONDAR.ZA
jack@GRONDAR.ZA</screen>
jane@EXAMPLE.COM
jack@EXAMPLE.COM</screen>
<para><username>jane</username> または <username>jack</username>
という名前で (前述の<command>kinit</command> によって)
認証されている <filename>GRONDAR.ZA</filename>
認証されている <filename>EXAMPLE.COM</filename>
という管理領域のユーザ なら誰でも<command>rlogin</command> や
<command>rsh</command>, <command>rcp</command>等によってこ
のシステム (<hostid>grunt</hostid>)
の<username>jane</username>のアカウントまたはファ
イルにアクセスできます。</para>
<para>たとえば、Jane が他のシステムに Kerberos
を用いて login します。</para>
<para>たとえば、<username>jane</username> が他のシステムに
Kerberos を用いて login します。</para>
<screen>&prompt.user; <userinput>kinit</userinput>
MIT Project Athena (grunt.grondar.za)
MIT Project Athena (grunt.example.com)
<prompt>Password: </prompt>
&prompt.user; <userinput>rlogin grunt</userinput>
Last login: Mon May 1 21:14:47 from grumble
@ -1898,15 +1911,15 @@ Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<para>次の例では、Jackが同じマシンの Jane
のアカウントにloginします。Janeは <filename>.klogin</filename>
ファイルを前述のように設定しており、
Kerberosでは<emphasis>jack</emphasis>というprincipal
<para>次の例では、Jack が同じマシンの Jane
のアカウントに login します。<username>jane</username> は
<filename>.klogin</filename> ファイルを前述のように設定しており、
Kerberos では <emphasis>jack</emphasis> という principal
をインスタンスなしで設定してあります。</para>
<screen>&prompt.user; <userinput>kinit</userinput>
&prompt.user; <userinput>rlogin grunt -l jane</userinput>
MIT Project Athena (grunt.grondar.za)
MIT Project Athena (grunt.example.com)
<prompt>Password: </prompt>
Last login: Mon May 1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
@ -1997,15 +2010,14 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
サービスは通常の認証機構よりもセキュリティを
強化してある 要塞ホストで動作させます。</para>
<para>FreeBSD は (<application>IPFW</application>
として知られる) カーネルパケットフィルタ込みで
提供されています。このセクションの後の方では、
このフィルタについての 説明を集中しておこないます。
<para>FreeBSD は (IPFW として知られる)
カーネルパケットフィルタ込みで提供されています。
この節の残りでは、このフィルタについて集中して説明します。
サードパーティから提供されるソフトウェアを使用することにより、
Proxy サーバを FreeBSD 上に構築することができます。しかし、
現在入手可能な proxy サーバは
たいへんバラエティに富んでいるので、
この節でそれらすべてをカバーすることはできないでしょう。</para>
Proxy サーバを FreeBSD 上に構築することができます。
しかし、現在入手可能な
proxy サーバはたいへんバラエティに富んでいるので、
この節でそれらすべてをカバーすることはできません。</para>
<sect3 id="firewalls-packet-filters">
<title>パケットフィルタリングルータ</title>
@ -2095,19 +2107,15 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<title>IPFW で何ができるか</title>
<indexterm><primary><command>ipfw</command></primary></indexterm>
<para>FreeBSD とともに配布されている
<command>IPFW</command> は、カーネル内部にあって
パケットのフィルタリングとアカウンティングを
おこなうシステムであり、
ユーザ側のコントロールユーティリティである &man.ipfw.8; を
含んでいます。ルーティングの決定をおこなう際に、
これらは互いに協力して、
<para>FreeBSD とともに配布されている IPFW は、
カーネル内部にあってパケットのフィルタリングとアカウンティングをおこなうシステムであり、
ユーザ側のコントロールユーティリティである &man.ipfw.8;
を含んでいます。
ルーティングの決定をおこなう際に、これらは互いに協力して、
カーネルで使用されるルールを定義したり、
現在使用されているルールを
問い合わせたりすることができます。</para>
現在使用されているルールを問い合わせたりすることができます。</para>
<para><application>IPFW</application>
は互いに関連する二つの部分からなっています。
<para>IPFW は互いに関連する二つの部分からなっています。
ファイアウォールセクションは
パケットフィルタリングをおこないます。また、IP
アカウンティングセクションはファイアウォールセクションのものと
@ -2117,14 +2125,11 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
トラフィックが
フォワードされているかを知ることができます。</para>
<para><application>IPFW</application> は、
<para>IPFW は、
ルータではないマシンにおいても入出力コネクションの
パケットフィルタリングのために
使用することができるように設計されています。これは一般的な
<application>IPFW</application>
の使用法とは異なる特別な使い方ですが、
こういった状況でも同じコマンドと
テクニックが使用されます。</para>
パケットフィルタリングのために使用することができるように設計されています。
これは一般的な IPFW の使用法とは異なる特別な使い方ですが、
こういった状況でも同じコマンドとテクニックが使用されます。</para>
</sect2>
<sect2>
@ -2134,11 +2139,9 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<secondary>有効化</secondary>
</indexterm>
<para><application>IPFW</application>
システムの中心となる部分はカーネル内部にあります。そのため、
どのファシリティ (機能) を必要とするかによって、一つまたは
それ以上のオプションをカーネルコンフィグレーション
ファイルに追加し、
<para>IPFW システムの中心となる部分はカーネル内部にあります。
そのため、どのファシリティ (機能) を必要とするかによって、
1 つまたは複数のオプションをカーネルコンフィグレーションファイルに追加し、
カーネルを再コンパイルする必要があるでしょう。
カーネルの再コンパイル方法の詳細については、<link
linkend="kernelconfig">カーネルコンフィグレーション</link>
@ -2208,10 +2211,9 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<secondary>設定</secondary>
</indexterm>
<para><application>IPFW</application> ソフトウェアの設定は
&man.ipfw.8; ユーティリティを
通じておこないます。このコマンドの構文は非常に
複雑に見えますが、
<para>IPFW ソフトウェアの設定は &man.ipfw.8;
ユーティリティを通じておこないます。
このコマンドの構文は非常に複雑に見えますが、
一旦その構造を理解すれば比較的単純です。</para>
<para>このユーティリティでは今のところ四つの異なる
@ -2275,7 +2277,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</varlistentry>
</variablelist>
<para>以前のバージョンの <application>IPFW</application> では、
<para>以前のバージョンの IPFW では、
ファイアウォールエントリと
パケットアカウンティングエントリが別々に利用されていました。
現在のバージョンでは、それぞれのファイアウォールエントリ毎に
@ -2610,7 +2612,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</sect2>
<sect2>
<title>ipfw に対するコマンドの例</title>
<title><application>ipfw</application> についてのコマンドの例</title>
<para>このコマンドは、ホスト <hostid
role="fqdn">evil.crackers.org</hostid> から ホスト <hostid
@ -2848,6 +2850,17 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<para><emphasis>訳: &a.jp.hino;, 14 March
2001.</emphasis></para>
<note>
<title>終端文字</title>
<para>この節の、また他の節を通して、末尾に <quote>^D</quote>
が置かれている例があることに気づかれるでしょう。
これは、<keycap>Control</keycap>　キーを押しながら
<keycap>D</keycap> キーを押すことを意味しています。
ほかによく使われる文字は <quote>^C</quote>
で、<keycap>Control</keycap>　キーを押しながら
<keycap>C</keycap> を押すことを意味しています。</para>
</note>
<para>IPsec 機構は、IP 層とソケット層に対して安全な通信を提供します。
実装の詳細に関しては <ulink
url="http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html">The
@ -3224,8 +3237,9 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
<screen>sshd_enable="YES"</screen>
<para>次に起動したときから ssh デーモンが起動します。
もしくは単に <command>sshd</command>
<para>次に起動したときから
<application>ssh</application> デーモンが起動します。
もしくは単に <application>sshd</application>
デーモンを実行しても構いません。</para>
</sect2>