path: root/ja_JP.eucJP/books/handbook/security/chapter.xml

<?xml version="1.0" encoding="euc-jp"?>
<!--
     The FreeBSD Documentation Project
     The FreeBSD Japanese Documentation Project

     Original revision: r43278
     $FreeBSD$
-->
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security">

  <info>
    <title>セキュリティ</title>

    <authorgroup>
      <author>
	<personname>
	  <firstname>Matthew</firstname>
	  <surname>Dillon</surname>
	</personname>

	<contrib>本章の基にした security(7) マニュアルページの執筆: </contrib>
      </author>
    </authorgroup>
  </info>

  <indexterm><primary>セキュリティ</primary></indexterm>

  <para><emphasis>訳: &a.jp.hino;、(jpman
    プロジェクトの成果を利用させていただきました)。</emphasis></para>

  <sect1 xml:id="security-synopsis">
    <title>この章では</title>

    <para>この章では、基本的なシステムセキュリティの考え方、
      覚えておくべき一般的なルールを紹介し、
      &os; における高度な話題について簡単に説明します。
      ここで扱う話題の多くは、
      一般的なシステムやインターネットセキュリティにもあてはまります。
      システムを安全に保つことは、データ、知的財産、時間、その他を、
      ハッカーやその同類から守るためには欠かせません。</para>

    <para>&os; は、
      システムとネットワークの整合性および安全性を保護する仕組みと一連のユーティリティを提供しています。</para>

    <para>この章を読むと、以下のことがわかります。</para>

    <itemizedlist>
      <listitem>
	<para>&os;
	  における基本的なシステムセキュリティの考え方</para>
      </listitem>

      <listitem>
	<para>&os; で利用できるさまざまな暗号化手法</para>
      </listitem>

      <listitem>
	<para>ワンタイムパスワード認証の設定方法</para>
      </listitem>

      <listitem>
	<para>&man.inetd.8; と組み合わせて
	  <acronym>TCP</acronym> Wrappers を設定する方法</para>
      </listitem>

      <listitem>
	<para>&os; における
	  <application>Kerberos</application> の設定方法</para>
      </listitem>

      <listitem>
	<para>IPsec を設定して <acronym>VPN</acronym> を構築する方法</para>
      </listitem>

      <listitem>
	<para>&os; にける
	  <application>OpenSSH</application> の設定および使用方法</para>
      </listitem>

      <listitem>
	<para>ファイルシステム <acronym>ACL</acronym> (アクセス制御リスト)
	  の使用方法</para>
      </listitem>

      <listitem>
	<para>Ports Collection
	  からインストールされたサードパーティ製ソフトウェア packages
	  を <application>Portaudit</application>
	  を使って監査する方法</para>
      </listitem>

      <listitem>
	<para>&os; セキュリティ勧告の利用方法</para>
      </listitem>

      <listitem>
	<para>プロセスアカウンティングがどのようなものか、
	  &os; 上で有効にする方法について</para>
      </listitem>

      <listitem>
	<para>リソース制限データベースとは何か、
	  この仕組みを使ったユーザ資源の管理方法</para>
      </listitem>
    </itemizedlist>

    <para>この章を読む前に、次のことが必要になります。</para>

    <itemizedlist>
      <listitem>
	<para>&os; およびインターネットの基本概念の理解</para>
      </listitem>
    </itemizedlist>

<!--
    <para>Additional security topics are covered elsewhere in this
      Handbook.  For example, Mandatory Access Control is discussed in
      <xref linkend="mac"/> and Internet firewalls are discussed in
      <xref linkend="firewalls"/>.</para>
-->
  </sect1>

  <sect1 xml:id="security-intro">
    <title>はじめに</title>

    <para>セキュリティとは、システム管理者をいつも悩ませる仕事の一つです。
      &os; は、固有のセキュリティ機構を備えていますが、
      追加のセキュリティ機構を設定し保守する仕事はおそらく、
      システム管理者としてもっとも大きな責務の一つでしょう。</para>

    <para>また、システムセキュリティには、
      さまざまな形での攻撃に対処することとも関係しています。
      攻撃の中には <systemitem class="username">root</systemitem>
      権限を奪おうとはしないけれども、
      クラッシュやシステムの不安定状態を引き起こそうとするものもあります。
      このセキュリティ問題は、いくつかに分類することが可能です。</para>

    <orderedlist>
      <listitem>
	<para>サービス妨害攻撃 (denial of service attack)</para>
      </listitem>

      <listitem>
	<para>ユーザアカウントの不正利用 (user account compromise)</para>
      </listitem>

      <listitem>
	<para>アクセス可能なサービスを使った root 権限の不正利用</para>
      </listitem>

      <listitem>
	<para>ユーザアカウントを経由した root 権限の不正使用</para>
      </listitem>

      <listitem>
	<para>バックドアの設置</para>
      </listitem>
    </orderedlist>

    <indexterm>
      <primary>DoS 攻撃</primary>
      <see>サービス妨害 (DoS)</see>
    </indexterm>

    <indexterm>
      <primary>セキュリティ</primary>
      <secondary>DoS 攻撃</secondary>
      <see>サービス妨害 (DoS)</see>
    </indexterm>

    <indexterm><primary>サービス妨害 (DoS)</primary></indexterm>

    <para>サービス妨害攻撃 (<acronym>DoS</acronym> 攻撃) とは、
      マシンから必要な資源を奪う行為です。
      通常、サービス妨害攻撃はそのマシンで実行されるサーバやネットワークスタックを過負荷状態にして、
      マシンをクラッシュさせたり、
      マシンを使えなくしたりするような力任せの方法です。
      サーバプロセスに対する攻撃は、オプションを適切に指定することによって、
      攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで対応できる場合が多いです。これらに比べると、
      ネットワークへの力任せの攻撃への対応はずっと難しくなります。
      この攻撃によって、マシンを落としてしまうことはできないかもしれませんが、
      接続しているインターネット回線を飽和させてしまうことはできます。</para>

    <indexterm>
      <primary>セキュリティ</primary>
      <secondary>アカウント不正利用</secondary>
    </indexterm>

    <para>ユーザアカウントの不正利用は、
      <acronym>DoS</acronym> 攻撃よりもずっとよくある問題です。
      このご時勢でも、
      暗号化されていないサービスを実行させているシステム管理者は多く、
      そのため、リモートからログインしているユーザは、
      パスワードを覗き見られてしまう危険性があります。
      システム管理者が注意深い人ならば、
      リモートアクセスログを解析して、
      疑わしい送信元アドレスや疑わしいログインを探すものです。</para>

    <para>セキュリティを十分維持し、
      手入れの行き届いたシステムにおいては、
      あるユーザアカウントへのアクセスが可能となっても、
      必ずしも攻撃者に <systemitem class="username">root</systemitem>
      へのアクセス権を与えるとは限りません。
      <systemitem class="username">root</systemitem>
      へのアクセス権がなければ、
      攻撃者は自分の侵入の痕跡を隠蔽することができませんし、
      そのユーザのファイルを引っかき回したり、
      マシンをクラッシュさせたりするのがせいぜいです。
      ユーザアカウントの不正利用はめずらしいことではありません。
      なぜなら一般ユーザは、
      システム管理者ほど注意を払わない傾向があるからです。</para>

    <indexterm>
      <primary>セキュリティ</primary>
      <secondary>裏口 (バックドア)</secondary>
    </indexterm>

    <para><systemitem class="username">root</systemitem>
      権限を奪取する方法は、潜在的に何通りもあります。
      攻撃者は <systemitem class="username">root</systemitem>
      のパスワードを知っているかもしれませんし、
      攻撃者が <systemitem class="username">root</systemitem>
      権限で実行されているサービスのバグの脆弱性を利用できるかもしれません。
      また、攻撃者は SUID-root
      プログラムに存在するバグを知っているかもしれません。
      攻撃者は、
      バックドアとして知られているプログラムを使って脆弱性なシステムを探したり、
      修正されていない脆弱性を利用してアクセスしたり、
      攻撃者による違法行為の痕跡を消そうとしたりするかもしれません。</para>

    <para>セキュリティを改善する方法は、常に、
      タマネギの皮のように階層化する手法
      (a multi-layered <quote>onion peel</quote> approach)
      で実装されるべきです。これらは次のように分類できます。</para>

    <orderedlist>
      <listitem>
	<para><systemitem class="username">root</systemitem>
	  とスタッフのアカウントの安全性を高める。</para>
      </listitem>

      <listitem>
	<para><systemitem class="username">root</systemitem>
	  の安全性を高める &ndash; <systemitem
	    class="username">root</systemitem> 権限で動作するサーバと
	  SUID/SGID バイナリ。</para>
      </listitem>

      <listitem>
	<para>ユーザアカウントの安全性を高める。</para>
      </listitem>

      <listitem>
	<para>パスワードファイルの安全性を高める。</para>
      </listitem>

      <listitem>
	<para>カーネルのコア、raw デバイス、
	  ファイルシステムの安全性を高める。</para>
      </listitem>

      <listitem>
	<para>システムに対して行なわれた、
	  不適切な変更をすばやく検出する。</para>
      </listitem>

      <listitem>
	<para>必要と思われる以上の対応をとる (paranoia)。</para>
      </listitem>
    </orderedlist>

    <para>次の節では、上記の項目についてより深く掘り下げていきます。</para>
  </sect1>

  <sect1 xml:id="securing-freebsd">
    <title>&os; の安全性を高める</title>

    <indexterm>
      <primary>セキュリティ</primary>
      <secondary>&os; の安全性を高める</secondary>
    </indexterm>

    <para>この節では、<link
	linkend="security-intro">前節</link> でとりあげた &os;
      システムの安全性を高める方法について説明します。</para>

    <sect2 xml:id="securing-root-and-staff">
      <title><systemitem class="username">root</systemitem>
	アカウントの安全性を高める</title>

      <indexterm>
	<primary>&man.su.1;</primary>
      </indexterm>

      <para>ほとんどのシステムでは、
	<systemitem class="username">root</systemitem>
	アカウントに割り当てたパスワードが 1 つあります。
	このパスワードは<emphasis>いつでも</emphasis>不正利用の危険に晒されていると考えてください。
	これはパスワードを無効にすべきだと言っているのではありません。
	パスワードは、マシンにコンソールからアクセスするのには、
	ほとんどいつでも必要なものです。
	しかしながら、コンソール以外からは、
	そして可能なら &man.su.1;
	コマンドを実行する場合もパスワードを使えないようにするべきです。
	たとえば、<filename>/etc/ttys</filename> のエントリにおいて、
	特定のターミナルに対し
	<systemitem class="username">root</systemitem>
	でログインできないように
	<literal>insecure</literal> と設定してください。
	&os; では、デフォルトで、
	<filename>/etc/ssh/sshd_config</filename> において
	<literal>PermitRootLogin</literal> が <literal>no</literal>
	と設定されているので、&man.ssh.1; を使った
	<systemitem class="username">root</systemitem>
	へログインは無効になっています。
	すべてのアクセス手段、たとえば FTP
	ようなサービスは、良くクラックの対象となることを理解してください。
	<systemitem class="username">root</systemitem> への直接ログインは、
	システムコンソール経由でのみ可能であるべきなのです。</para>

      <indexterm>
	<primary><systemitem class="groupname">wheel</systemitem></primary>
      </indexterm>

      <para>システム管理者は
	<systemitem class="username">root</systemitem>
	になれるようにしておく必要があるので、
	追加のパスワード認証の設定が必要となります。
	ひとつは、適切なユーザアカウントを
	<filename>/etc/group</filename> 中の
	<systemitem class="groupname">wheel</systemitem> に加える方法です。
	<systemitem class="groupname">wheel</systemitem>
	のメンバは、&man.su.1; を使って
	<systemitem class="username">root</systemitem> になることが許されます。
	実際に
	<systemitem class="username">root</systemitem>
	アクセスの必要なユーザのみ
	<systemitem class="groupname">wheel</systemitem>
	に置くようにすべきです。
	Kerberos を使用して認証行う場合には、
	<systemitem class="username">root</systemitem>
	のホームディレクトリに <filename>.k5login</filename>
	を作成することで、
	誰も <systemitem class="groupname">wheel</systemitem> に置く必要なく
	&man.ksu.1; することを許可できます。</para>

      <para>アカウントを完全にロックするには、
	&man.pw.8; を使ってください。</para>

      <screen>&prompt.root; <userinput>pw lock staff</userinput></screen>

      <para>これにより、指定されたユーザは、&man.ssh.1;
	を含むいかなる方法でもログインできなくなります。</para>

      <para>アカウントへのアクセスをブロックするもう一つの方法は、
	暗号化されたパスワードを
	<quote><literal>*</literal></quote> 1 文字に置き換えることです。
	この文字は、暗号化されたパスワードにマッチすることはないので、
	ユーザアクセスをブロックします。
	たとえば、次のアカウントのエントリを、</para>

      <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>

      <para>&man.vipw.8; を使って以下のように変更します。</para>

      <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>

      <para>この変更によって
	<systemitem class="username">foobar</systemitem> は、
	通常のログインはできなくなります。
	このようなアクセス制限をした後は、
	サイトで <application>Kerberos</application> をセットアップしたり、
	ユーザが &man.ssh.1;
	の鍵を設定するなどといった認証手段を利用しなければなりません。</para>

      <para>これらのセキュリティの仕組みでは、
	制限の強いサーバから制限の弱いサーバへログインすることを前提としています。
	たとえば、サーバがネットワークサービスを実行させている場合、
	ワークステーションではそれらのサービスを実行させてはなりません。
	ワークステーションを十分に安全にしておくためには、
	実行するサービスをゼロにするか、可能な限り減らし、
	パスワードで保護されたスクリーンセーバを走らせておくべきです。
	システムへの物理的アクセスが与えられたとすると、
	もちろん言うまでもなく、
	攻撃者はいかなる種類のセキュリティをもうち破ることができるのです。
	幸いにも、システム破りの大多数は、ネットワーク経由でリモートから、
	システムへの物理的アクセス手段を持たない人々によって行われています。</para>

      <para>Kerberos を使うことで、
	ユーザのパスワードの変更もしくは停止を一箇所で行なうことと、
	ユーザがアカウントを持つすべてのマシンに即時にその効果を及ぼすことが可能となります。
	アカウントが危険に晒されたときに、
	すべてのマシン上の関連するパスワードを即座に変更する能力を過小評価してはいけません。
	Kerberos では、Kerberos チケットにタイムアウトを設定でき、
	設定した期間が経過するとユーザに新しいパスワードを選ぶように要求するといった追加の制限を課することができます。</para>
    </sect2>

    <sect2>
      <title>root 権限で実行されているサーバと
	SUID/SGID バイナリの安全性を高める</title>

      <indexterm>
	<primary>砂場 (sandbox)</primary>
      </indexterm>
      <indexterm>
	<primary>&man.sshd.8;</primary>
      </indexterm>

      <para>用心深いシステム管理者は、必要なサービスだけを有効にし、
	サードパーティ製のサーバは、
	よくバグを持っていがちだということに注意しているものです。
	注意深くチェックしていないサーバは、決して実行してはいけません。
	多くのデーモンは、サービス専用のアカウント、もしくは
	<firstterm>砂場 (sandbox)</firstterm> で起動させることができるので、
	<systemitem class="username">root</systemitem>
	権限でサービスを実行する前には、よく考えてください。
	&man.telnetd.8; または &man.rlogind.8;
	のような安全ではないサービスは有効にしないでください。</para>

      <para>他のシステムの潜在的なセキュリティホールには、
	SUID-root および SGID バイナリがあります。
	これらのバイナリは、
	&man.rlogin.1; のように、<filename>/bin</filename>,
	<filename>/sbin</filename>, <filename>/usr/bin</filename>
	または <filename>/usr/sbin</filename>
	に存在するものがほとんどです。
	100% 安全なものは存在しないとはいえ、
	システムデフォルトの SUID/SGID バイナリは比較的安全といえます。
	SUID バイナリは、
	スタッフのみがアクセス可能な特別なグループに制限し、
	使わない SUID バイナリは削除することが推奨されます。
	SGID バイナリもほとんど同様の危険な存在になり得ます。
	侵入者が kmem に SGID されたバイナリを破ることができた場合、
	その侵入者は <filename>/dev/kmem</filename>
	を読み出すことができるようになるでしょう。つまり、
	暗号化されたパスワードファイルを読み出すことができるようになるので、
	ユーザアカウントを、潜在的な危険に晒すことになります。他にも、
	<literal>kmem</literal> グループを破った侵入者が pty
	を通して送られたキーストロークを監視できるという危険があります。
	キーストロークには、安全な方法でログインするユーザが使っている pty
	も含まれます。
	<systemitem class="groupname">tty</systemitem>
	グループを破った侵入者は、ほぼ任意のユーザの
	tty へ書き込みができます。
	ユーザが端末プログラムやキーボードをシミュレーションする機能を持ったエミュレータを使っている場合、
	侵入者は潜在的に、
	結局そのユーザとして実行されるコマンドをユーザの端末にエコーさせるデータストリームを生成できる可能性があります。</para>
    </sect2>

    <sect2 xml:id="secure-users">
      <title>ユーザアカウントの安全性を高める</title>

      <para>ユーザアカウントは、普通、安全性を高めることが最も困難です。
	気を配ってユーザアカウントを監視するよりほかありません。
	ユーザアカウントに対し &man.ssh.1; や Kerberos を利用するには、
	システム管理がさらに増えたりテクニカルサポートが必要になりますが、
	暗号化パスワードファイルと比較するとはるかに良い方法を提供します。</para>
    </sect2>

    <sect2>
      <title>パスワードファイルの安全性を高める</title>

      <para>できるだけ多くのパスワードをアスタリスクで外し、
	それらのアカウントのアクセスには
	&man.ssh.1; や Kerberos を使うようにすることが、唯一の確実な方法です。
	暗号化パスワードファイル
	(<filename>/etc/spwd.db</filename>) は
	<systemitem class="username">root</systemitem>
	でのみ読み出し可能だけれども、
	たとえ、侵入者が root の書き込み権限は得られなくとも、
	読み出しアクセス権限を得ることは可能かもしれません。</para>

      <para><link
	  linkend="security-integrity">ファイルの完全性のチェック</link>
	節で説明されているように、
	セキュリティスクリプトでパスワードファイルの変更をチェックし、
	報告するようにすべきです。</para>
    </sect2>

    <sect2>
      <title>カーネルのコア、raw デバイス、
	ファイルシステムの安全性を高める</title>

      <para>最近のカーネルは、組み込みのパケット覗き見デバイス
	(packet sniffing device) ドライバを備えているものがほとんどです。
	&os; では <filename>bpf</filename> と呼ばれています。
	このデバイスは DHCP で必要となるため、
	DHCP を提供したり使う必要のないシステムでは、
	カスタムカーネルコンフィグレーションファイルから外すことができます。</para>

      <indexterm>
	<primary>&man.sysctl.8;</primary>
      </indexterm>

      <para><filename>bpf</filename> を外しても、
	<filename>/dev/mem</filename> および
	<filename>/dev/kmem</filename> という問題がまだ残っています。
	侵入者は raw ディスクデバイスに書き込むこともできます。
	やる気まんまんの侵入者は、&man.kldload.8;
	を使って自分独自の <filename>bpf</filename>、
	もしくは他の覗き見デバイスを動作中のカーネルにインストールできます。
	この問題を避けるため、カーネルをより高いセキュリティレベル、
	少なくともセキュリティレベル 1 で実行させる必要があります。</para>

      <para>カーネルのセキュリティレベルはいくつかの方法で設定できます。
	現在動いているカーネルのセキュリティレベルを高める最も簡単な方法は、
	<varname>kern.securelevel</varname> を設定する方法です。</para>

      <screen>&prompt.root; <userinput>sysctl kern.securelevel=1</userinput></screen>

      <para>デフォルトでは、&os; のカーネルはセキュリティレベル
	-1 で起動します。
	このセキュリティレベルは、
	変更不可のファイルフラグを外したり、
	すべてのデバイスに対して読み込みおよび書き込みができたりするので、
	<quote>insecure mode</quote> と呼ばれます。
	このセキュアレベルは、管理者または  &man.init.8;
	による起動時のスクリプトにより変更されない限り -1 のままです。
	<filename>/etc/rc.conf</filename> において、
	<varname>kern_securelevel_enable</varname> を
	<literal>YES</literal> とし、
	<varname>kern_securelevel</varname>
	に必要とする値を設定することで、
	システム起動時にセキュアレベルを高めることができます。</para>

      <para>セキュリティレベルを 1 以上に設定すると、
	追加専用および変更不可ファイルのフラグを外すことはできなくなり、
	また raw デバイスへのアクセスが拒否されます。
	より高いレベルに設定すると、より多くの操作に制限がかかります。
	各セキュリティレベルの完全な説明については、
	&man.security.7; および &man.init.8; をご覧ください。</para>

      <note>
	<para>セキュリティレベルを 1 以上に設定した場合には、
	  <filename>/dev/io</filename> へのアクセスがブロックされるため、
	  <application>&xorg;</application> や、
	  <buildtarget>installworld</buildtarget> のプロセスでは、
	  いくつかのファイルの追加専用および変更不可のフラグは一時的にリセットされるため、
	  ソースから &os;
	  を構築してインストールするときなどで問題が引き起こされる可能性があります。
	  <application>&xorg;</application> の問題については、
	  起動プロセス初期のセキュアレベルが十分低いときに
	  &man.xdm.1; を起動することで、この問題に対応できます。
	  このような応急処置は、
	  すべてのセキュリティレベルやそれらが課す潜在的なすべての制限には対応できないでしょう。
	  少し先を見越した計画的な対応をすべきです。
	  各セキュリティレベルで課される制限は、
	  システムを使用することによる利便性を著しく減らしてしまうため、
	  この制限を理解することは重要です。
	  また、各セキュリティレベルの制限を理解することで、
	  デフォルトの設定をよりシンプルにでき、
	  設定に関する意外性を少なくできるでしょう。</para>
      </note>

      <para>カーネルのセキュリティレベルを 1 以上に設定した場合には、
	システム起動に関わる重要なバイナリやディレクトリ、
	スクリプトファイル、そして、
	セキュリティレベルが設定されるまでの間に実行されるすべてのものに対して、
	<literal>schg</literal> フラグを設定することは有用でしょう。
	システムをより高いセキュリティレベルで実行させるようにするが、
	<literal>schg</literal>
	フラグを設定しないというところで妥協するという手もあります。
	もう一つの可能性としては、単純に
	<filename>/</filename> および <filename>/usr</filename>
	を読み込み専用でマウントすることです。
	ここで特筆すべきことは、システムを守ろうとして厳しくしすぎると、
	侵入を検出することができなくなってしまうということです。</para>
    </sect2>

    <sect2 xml:id="security-integrity">
      <title>ファイルの完全性のチェック</title>

      <para>システム管理者にできることは、
	便利さという要素がその醜い頭を上げない程度に、
	コアシステムの設定と制御ファイルを防御することだけです。
	たとえば、<filename>/</filename> および
	<filename>/usr</filename>
	にある大部分のファイルに <literal>schg</literal>
	ビットを設定するために &man.chflags.1;
	を使用するのは、おそらく逆効果でしょう。
	なぜなら、そうすることでファイルは保護できますが、
	侵入を検出する窓を閉ざしてしまうことにもなるからです。
	セキュリティ対策は、
	侵入の可能性を検出できなければ、有用ではなく、
	もっと悪ければ、安全性に対する間違った感覚を植え付けてしまいます。
	セキュリティに対する仕事の半分は、
	攻撃者を攻撃の最中に捕えるようにするために、
	攻撃者を食い止めるのではなく侵入を遅らせることなのです。</para>

      <para>侵入を検出する最も良い方法は、変更されていたり、
	消えていたり、入れた覚えがないのに入っているファイルを探すことです。
	変更されたファイルを探すのに最も良い方法は、もう一つの
	しばしば中央に集められた、
	アクセスが制限されたシステムから行なうものです。
	さらに安全でアクセス制限されたシステム上でセキュリティ用スクリプトを書けば、
	スクリプトは潜在的な攻撃者からはほぼ見えなくなります。
	この有効性を最大限に活用するためには、
	アクセスの制限されたマシンから他のマシンへのかなりのアクセスを許可する必要があります。
	普通は、読み込み専用の <acronym>NFS</acronym> エクスポートをしたり、
	&man.ssh.1; 鍵のペアを設定したりします。
	ネットワークのトラフィックを別にして、
	<acronym>NFS</acronym> は最も可視性のない方法です。
	管理者は、各クライアント上のファイルシステムを、
	事実上検出されずに監視できるようになります。
	アクセス制限されたサーバがスイッチを通してクライアントに接続されている場合、
	たいてい <acronym>NFS</acronym> がより良い選択肢です。
	アクセス制限されたサーバが、
	いくつかのルーティング層を通してクライアントに接続している場合、
	<acronym>NFS</acronym> はあまりにも危険なので、
	&man.ssh.1; の方が良い方法でしょう。</para>

      <para>アクセス制限されたマシンに、
	監視しようとするクライアントシステムへの少なくとも読み込みのアクセス権を与えたら、
	次に監視するためのスクリプトを書かなくてはいけません。
	<acronym>NFS</acronym> マウントをすれば、&man.find.1; や &man.md5.1;
	などの単純なシステムユーティリティでスクリプトを書くことができます。
	少なくとも 1 日 1 回、クライアントのシステムファイルを直接
	&man.md5.1; にかけ、
	さらにもっと頻繁に <filename>/etc</filename> および
	<filename>/usr/local/etc</filename>
	にあるようなコントロール用ファイルを試験するのが一番です。
	アクセス制限されたマシンが正しいと知っている、
	基となる md5 情報と比べて違いが見つかった場合、
	システム管理者に警告するようにすべきです。
	優れたセキュリティ用スクリプトは、
	<filename>/</filename> および <filename>/usr</filename>
	などのシステムパーティション上で不適当に
	SUID されたバイナリや、
	新たに作成されたファイルや削除されたファイルがないかどうかを調べるでしょう。</para>

      <para><acronym>NFS</acronym> ではなく、&man.ssh.1; を使用する場合は、
	セキュリティ用スクリプトを書くのはより難しいことです。
	たとえば、スクリプトを動かすためには、クライアントに対してスクリプトを
	&man.scp.1; しなくてはいけませんし、
	クライアントマシンの &man.ssh.1;
	クライアントはすでに攻撃されてしまっているかもしれません。
	安全でないリンク上の場合は
	&man.ssh.1; は必要かもしれませんが、
	扱いはとても大変になります。</para>

      <para>優れたセキュリティ用スクリプトは、
	<filename>.rhosts</filename>,
	<filename>.ssh/authorized_keys</filename>
	などの隠し設定ファイルの変更もチェックするものです。
	これらは <literal>MD5</literal>
	チェックの範囲外になってしまうであろうファイル群です。</para>

      <para>ユーザ用のディスク容量が非常に大きい場合は、
	パーティション上の各ファイルを見て回るのに大変な時間がかかるかもしれません。
	この場合は、&man.mount.8; により <literal>nosuid</literal>
	を使うことで、マウントフラグを設定して、
	SUID されたバイナリを置けないようにするのが良い考えです。
	少なくとも週に 1 度はファイルシステムをスキャンするべきです。
	なぜなら、目的は、侵入が成功したかどうかに関わらず、
	不正侵入の試みがあったことの検出をすることだからです。</para>

      <para>プロセスアカウンティング (&man.accton.8; 参照) は、
	マシンへの侵入を検出するためのメカニズムとして推奨できる、
	比較的オーバヘッドの少ない &os; の機能です。
	侵入を受けた後でも当該ファイルが無傷である場合に、
	侵入者がどのようにしてシステムに侵入したかを追跡するのに特に役立ちます。</para>

      <para>最後に、
	セキュリティスクリプトはログファイルを処理するようにし、
	ログファイル自体もできるだけ安全性の高い方法で生成するようにし、
	リモートの syslog サーバに送信するようにすべきです。
	侵入者は自分の侵入の痕跡を覆い隠そうとしますし、また、
	ログファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆくために極めて重要です。
	ログファイルを永久に残しておくための 1 つの方法は、
	システムコンソールをシリアルポートにつないで走らせ、
	コンソールを監視している安全なマシンに情報を集めることです。</para>
    </sect2>

    <sect2>
      <title>偏執狂的方法</title>

      <para>多少偏執狂的になっても決して悪いことにはなりません。
	原則的に、システム管理者は、
	便利さに影響を与えない範囲でいくつでもセキュリティ機能を追加することができます。
	また、いくらか考慮した結果、
	便利さに<emphasis>影響を与える</emphasis>セキュリティ機能を追加することもできます。
	より重要なことは、
	セキュリティ管理者はこれを多少混ぜこぜにして使うべきだということです。
	もしこの章で書かれている推奨される方法をそのまま使用した場合は、
	予想される攻撃者はやはりこの文書を読んでいるわけですから、
	防御策を教えてしまうことになります。</para>
    </sect2>

    <sect2>
      <title>サービス妨害攻撃</title>

      <indexterm>
	<primary>サービス妨害 (DoS)</primary>
      </indexterm>

      <para><acronym>DoS</acronym> 攻撃は、普通は、パケット攻撃です。
	ネットワークを飽和させる最先端の偽造パケット (spoofed packet)
	攻撃に対してシステム管理者が打てる手はそれほど多くありませんが、
	一般的に、以下のような方法により、
	その種の攻撃によってサーバがダウンしないことを確実にすることで、
	被害をある限度に食い止めることはできます。</para>

      <orderedlist>
	<listitem>
	  <para>サーバの fork の制限。</para>
	</listitem>

	<listitem>
	  <para>ICMP 応答攻撃、ping broadcast などの踏み台攻撃の制限。</para>
	</listitem>

	<listitem>
	  <para>カーネルの経路情報のキャッシュを過剰に用意する。</para>
	</listitem>
      </orderedlist>

      <para>よくある <acronym>DoS</acronym> 攻撃は、fork
	するサーバに対して攻撃するもので、
	多くの子プロセスを起動させることにより、
	メモリ、ファイル記述子などを使いつくし、
	ホストシステムを最終的に停止させます。
	&man.inetd.8; には、
	この種の攻撃を制限するオプションがいくつかあります。
	マシンがダウンすることを防止することは可能ですが、
	この種の攻撃によりサービスが中断することを防止することは一般的に言ってできないことに注意する必要があります。
	&man.inetd.8; を注意深く読んで下さい。特に、
	<option>-c</option>, <option>-C</option>, <option>-R</option>
	に注意して下さい。IP 偽造攻撃 (spoofed-IP attack) は
	&man.inetd.8; の <option>-C</option> の裏をかけるので、
	一般にオプションを組み合わせて使用すべきです。
	スタンドアロンサーバの中には、自分自身で fork
	を制限するパラメータを持っているものがあります。</para>

      <para><application>Sendmail</application> には、
	<option>-OMaxDaemonChildren</option> があります。
	システム負荷の値変化には遅れがあるので、
	<application>Sendmail</application>
	の負荷限界指定オプションを使うよりも、
	このオプションを使う方がまともに動作する可能性ははるかに高いです。
	<application>Sendmail</application> を開始する際は、
	通常見込まれる負荷を扱える程度に十分高いが、
	コンピュータが操作できない数の <application>Sendmail</application>
	インスタンスの値よりは低い値に
	<literal>MaxDaemonChildren</literal> を設定してください。
	<application>Sendmail</application> を
	<option>-ODeliveryMode=queued</option> を使って、
	キュー処理モードで実行したり、
	デーモン (<command>sendmail -bd</command>)
	をキュー処理用プロセス (<command>sendmail -q15m</command>)
	と別に実行することも、用心深いことと言えます。
	リアルタイムでの配送を望むのであれば、
	<option>-q1m</option> のようにすることで、
	キュー処理をはるかに短い時間間隔で行うことができます。
	いずれにしても、<literal>MaxDaemonChildren</literal>
	に合理的な値を確実に指定して、
	なだれをうって失敗することがないようにして下さい。</para>

      <para>&man.syslogd.8;
	は直接攻撃される可能性があるので、可能ならばいつでも
	<option>-s</option> を用いることを強く推奨します。
	これができないなら、
	<option>-a</option> を使って下さい。</para>

      <para>逆 identd などの接続返し (connect-back)
	を行うサービスについては直接攻撃を受ける可能性があるので、
	十分注意を払うようにするべきです。
	こういう事情があるので、<application>TCP wrapper</application>
	の逆 ident 機能を使うことは推奨されません。</para>

      <para>境界ルータのところでファイアウォールを設けて、
	外部からのアクセスに対して内部サービスを防御することは推奨されます。
	これは、LAN の外部からの飽和攻撃を防ぐことにあり、
	内部サービスをネットワークベースの <systemitem
	  class="username">root</systemitem>
	権限への攻撃から防御することにはあまり考慮を払っていません。
	ファイアウォールは、デフォルトではすべての通信を禁止し、
	許可する通信のみを明示して設定するように、常に排他的に設定して下さい。
	&os; では、<varname>net.inet.ip.portrange</varname>
	&man.sysctl.8; 変数により、
	動的バインドに使用されるポート番号の範囲を制御できます。</para>

      <para>また別のよくある <acronym>DoS</acronym> 攻撃として、
	踏み台攻撃と呼ばれるものがあります。これは、
	あるサーバを攻撃し、その結果として生成される応答がサーバ自身、
	ローカルネットワーク、
	もしくは他のマシンを過負荷に追い込むようにする攻撃です。
	この種の攻撃の中で最もありふれたものに、
	<emphasis>ICMP ping broadcast 攻撃</emphasis>があります。
	攻撃者は、攻撃するマシンのアドレスを送信元アドレスに設定した
	ping パケットを偽造して、対象の LAN
	のブロードキャストアドレスに向けてパケットを送信します。
	境界にあるルータがブロードキャストアドレスに対する
	ping パケットをドロップするように設定されていない場合、LAN は、
	詐称された送信元アドレスに向けて、
	犠牲となるマシンが飽和するまで応答パケットを生成します。
	異なるネットワーク上のいくつものブロードキャストアドレスに対して同時に攻撃する場合には、
	とくにひどいことになります。
	2 番目の踏み台攻撃は、
	サーバの受信ネットワークを飽和させるような
	ICMP エラー応答を生成するパケットを生成し、
	その結果としてサーバが送信ネットワークを ICMP
	応答で飽和させてしまう攻撃です。
	メモリを消費し尽くさせることにより、
	この種の攻撃でサーバをクラッシュさせることが可能です。
	サーバが生成した ICMP 応答を十分速く送信できない場合、
	とくにひどいことになります。
	この種の攻撃の効果を抑制するには、
	&man.sysctl.8; 変数の <literal>net.inet.icmp.icmplim</literal>
	を使ってください。
	踏み台攻撃の 3 つめの主要なクラスに属する攻撃は、
	UDP echo サービスのような、特定の &man.inetd.8;
	内部サービスに関連するものです。
	攻撃者は、送信元アドレスがサーバ A の echo
	ポートであり、送信先アドレスがサーバ B の echo
	ポートであるように UDP パケットを偽造します。
	ここでサーバ A, B はともに同じ
	LAN に接続されています。この 2 つのサーバは、
	この一つのパケットを両者の間で互いに相手に対して打ち返しあいます。
	攻撃者は、このようなパケットをほんのいくつか注入するだけで、
	両方のサーバと LAN を過負荷状態にすることができます。
	同様の問題が <application>chargen</application>
	ポートにも存在します。
	この手の inetd 内部テストサービスは無効にしてください。</para>

      <para>偽造パケット攻撃は、
	カーネルの経路情報キャッシュに過負荷を生じさせるために用いられることもあります。
	<varname>net.inet.ip.rtexpire</varname>,
	<varname>rtminexpire</varname>,
	<varname>rtmaxcache</varname>
	の &man.sysctl.8; パラメータを参照して下さい。
	でたらめな送信元 IP アドレスを用いた偽造パケット攻撃により、
	カーネルは、一時的なキャッシュ経路を経路情報テーブルに生成します。
	これは <command>netstat -rna | fgrep W3</command>
	で見ることができます。
	これらの経路は、普通は 1600 秒程度でタイムアウトになります。
	カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを検知すると、
	カーネルは動的に <varname>rtexpire</varname>
	を減らしますが、<varname>rtminexpire</varname>
	より小さくなるようには決して減らしません。
	これにより 2 つの問題が引き起こされます。</para>

      <orderedlist>
	<listitem>
	  <para>負荷の軽いサーバが突然攻撃された場合、
	    カーネルが十分素早く反応できないこと。</para>
	</listitem>

	<listitem>
	  <para>カーネルが持続的攻撃に耐えられるほど十分
	    <varname>rtminexpire</varname> が低く設定されていないこと。</para>
	</listitem>
      </orderedlist>

      <para>サーバが T3
	もしくはそれより高速の回線でインターネットに接続されている場合、
	&man.sysctl.8; を用いて
	<varname>rtexpire</varname> と <varname>rtminexpire</varname>
	を手動で上書きしておくことが思慮深いことといえます。
	ただし、どちらか一方でも 0 には決してしないで下さい。
	コンピュータをクラッシュさせてしまうことになります。
	両パラメータを 2 秒に設定すれば、
	攻撃から経路情報テーブルを守るには十分でしょう。</para>
    </sect2>

    <sect2>
      <title>Kerberos および &man.ssh.1; を用いたアクセスの問題</title>

      <indexterm><primary>&man.ssh.1;</primary></indexterm>

      <para>もし、Kerberos と &man.ssh.1; を使いたいのだとしたら、
	両者に関して言っておかねばならない問題がいくつかあります。
	Kerberos は大変優れた認証プロトコルですが、Kerberos 化された
	&man.telnet.1; および &man.rlogin.1; には、
	バイナリストリームを扱うのに不向きになってしまうようなバグがあります。
	デフォルトでは、Kerberos は <option>-x</option>
	を使わない限りセッションを暗号化してくれません。
	一方 &man.ssh.1; では、
	デフォルトですべてを暗号化してくれます。</para>

      <para>&man.ssh.1; はとても良く働いてくれますが、
	デフォルトで暗号鍵を転送してしまいます。
	これは、安全なワークステーションから、
	安全でないマシンへのアクセスに
	&man.ssh.1; を使っているユーザにセキュリティリスクを引き起こします。
	鍵そのものが見えてしまうわけではありませんが、
	&man.ssh.1; は login している間、転送用ポートを作ります。
	攻撃者が安全でないマシンの
	<systemitem class="username">root</systemitem> を破ったら、
	このポートを使って、
	この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。</para>

      <para>可能な時はいつでも、スタッフのログインには Kerberos を組み合せた
	&man.ssh.1; を使用することを勧めます。
	&man.ssh.1; は、Kerberos 対応機能と一緒にコンパイルできます。
	こうすると、見えてしまうかもしれない
	<acronym>SSH</acronym> 鍵をあまりあてにしないで良いようになり、
	一方で、Kerberos 経由でパスワードが保護されます。
	鍵は、安全なマシンからの自動化されたタスクのみに使用するべきです。
	Kerberos はこの用途には不向きです。 
	また、<acronym>SSH</acronym> の設定で鍵転送をしないようにするか、
	あるいは <filename>authorized_keys</filename>
	の <literal>from=IP/DOMAIN</literal> を使用して、
	特定のマシンからログインしてきたときのみ鍵が有効であるようにすることも勧めます。</para>
    </sect2>
  </sect1>

  <sect1 xml:id="crypt">
    <info><title>DES, Blowfish, MD5, SHA256, SHA512 および Crypt</title>
      <authorgroup>
	<author>
	  <personname>
	    <firstname>Bill</firstname>
	    <surname>Swingle</surname>
	  </personname>
	<contrib>改訂: </contrib></author>
      </authorgroup>
    </info>

    <indexterm>
      <primary>セキュリティ</primary>
      <secondary>crypt</secondary>
    </indexterm>

    <indexterm><primary>crypt</primary></indexterm>
    <indexterm><primary>Blowfish</primary></indexterm>
    <indexterm><primary>DES</primary></indexterm>
    <indexterm><primary>MD5</primary></indexterm>
    <indexterm><primary>SHA256</primary></indexterm>
    <indexterm><primary>SHA512</primary></indexterm>

    <para><emphasis>訳: &a.hanai;,
	12 September 1996.</emphasis></para>
    <para><emphasis>訳改訂: &a.jp.hino;,
	12 March 2001.</emphasis></para>

    <para>&unix; システムにおけるすべてのユーザは、
      そのアカウントに対応した一つのパスワードを持っています。
      それらのパスワードを秘密に保っておくために、
      パスワードは <quote>一方向ハッシュ</quote>
      として知られる方式で暗号化されます。
      一方向ハッシュとは、
      簡単に暗号化はできるが解読は難しいという方法です。
      オペレーティングシステム自身はパスワードを知りません。
      その代わりに <emphasis>暗号化された</emphasis>
      形でのみパスワードを知っています。
      <quote>素のテキスト</quote> としてパスワードを得る唯一の方法は、
      可能な限りのパスワード空間を検索するという力任せの方法です。</para>

    <para>元々、&unix; においてパスワードを安全な形で暗号化できる方式は
      Data Encryption Standard (<acronym>DES</acronym>)
      に基づいたものだけでした。<acronym>DES</acronym>
      のソースコードを米国外に輸出することはできないという問題があったため、
      &os; は、米国の法律を守ることと、
      未だに <acronym>DES</acronym> を使っていた他の &unix;
      一族との互換性を保つこととを両立する方法を探し出す必要がありました。
      その解決方法は、<acronym>DES</acronym>
      よりも安全であると考えられている MD5 を使うことでした。</para>

    <sect2>
      <title>暗号化機構を理解する</title>

      <para>現在では、ライブラリは <acronym>DES</acronym>,
	MD5, Blowfish, SHA256 および 
	SHA512 ハッシュ関数に対応しています。&os;
	がどの暗号化方式を使うようにセットアップされているかを判断するには、
	<filename>/etc/master.passwd</filename>
	の暗号化されたパスワードを調べてください。
	MD5 ハッシュで暗号化されたパスワードは、<acronym>DES</acronym>
	ハッシュで暗号化されたパスワードよりも長く、
	<literal>&dollar;1&dollar;</literal>
	という文字で始まるという特徴を持っています。
	<literal>&dollar;2a&dollar;</literal>
	で始まるパスワードは、Blowfish ハッシュ関数で暗号化されています。
	<acronym>DES</acronym>
	のパスワードはこれといって識別可能な特徴は持っていませんが、
	MD5 のパスワードよりは短く、そして <literal>&dollar;</literal>
	という文字を含まない 64
	文字のアルファベットを使って表現されているので、
	比較的短い文字列でドル記号で始まっていないものはおそらく
	<acronym>DES</acronym> のパスワードでしょう。
	SHA256 と SHA512 の場合は、<literal>&dollar;6&dollar;</literal>
	から始まります。</para>

      <para>新規パスワードがどちらのパスワード形式になるかは、
	<filename>/etc/login.conf</filename> の中の
	<literal>passwd_format</literal>
	ログインケーパビリティによって制御されます。
	その値としては、
	<literal>des</literal>,	<literal>md5</literal>,
	<literal>blf</literal>, <literal>sha256</literal> または
	<literal>sha512</literal> を設定することができます。
	ログインケーパビリティに関するより詳細な情報は、
	&man.login.conf.5; をご覧ください。</para>
    </sect2>
  </sect1>

  <sect1 xml:id="one-time-passwords">
    <title>ワンタイムパスワード</title>

    <indexterm><primary>ワンタイムパスワード</primary></indexterm>
    <indexterm>
      <primary>セキュリティ</primary>
      <secondary>ワンタイムパスワード</secondary>
    </indexterm>

    <para>デフォルトで、&os; は
      One-time Passwords In Everything (<acronym>OPIE</acronym>)
      に対応しています。
      OPIE はデフォルトでは MD5 ハッシュを使用します。</para>

    <para>三種類の異なる「パスワード」があります。
      まず一つ目は、通常の &unix; スタイル、もしくは Kerberos
      のパスワードです。
      二つ目は、&man.opiekey.1; によって生成され、
      &man.opiepasswd.1;
      およびログインプロンプトが受け付けるワンタイムパスワードです。
      三つ目のパスワードは、&man.opiekey.1; と場合により
      <command>opiepasswd</command>
      に対してワンタイムパスワードを生成するのに使われる
      <quote>秘密のパスワード</quote> です。</para>

    <para>秘密のパスワードは、&unix;
      パスワードと何の関連性もありません。
      両者を同一に設定することは可能ですが、お奨めしません。古い &unix;
      パスワードは長さが 8 文字に制限されていました
      <footnote><para>&os; では、標準のログインパスワードは、128
      文字までとなります。</para></footnote>。
      これに対し、<acronym>OPIE</acronym>
      の秘密のパスワードには 8 文字の制限はありません。
      6 語から 7 語からなるパスフレーズがふつうです。ほとんどの部分で、
      <acronym>OPIE</acronym> システムは &unix;
      のパスワードシステムと完全に独立して動作するようになっています。</para>

    <para>パスフレーズに加え、<acronym>OPIE</acronym>
      システムにとって重要な 2 種類のデータがあります。一つは
      <quote>シード (seed: 種)</quote> または
      <quote>キー (key: 鍵)</quote> と呼ばれるもので、2 つの文字と
      5 つの数字で構成されます。もう一つは <quote>シーケンス番号
      (iteration count)</quote> で、1 から 100 までの整数です。
      <acronym>OPIE</acronym>
      はここまでに述べたデータを利用してワンタイムパスワードを生成します。
      その方法は、まずシードと秘密のパスフレーズを連結し、
      それに対してシーケンス番号の回数だけ MD5 ハッシュを繰り返し計算します。
      そしてその結果を 6 つの短い英単語に変換します。
      この 6 つの英単語がワンタイムパスワードです。
      認証システム (主は PAM) は、
      前回最後に受け付けたワンタイムパスワードを記録しています。
      そして、その前回のワンタイムパスワードと、
      ユーザが入力したワンタイムパスワードを
      1 回ハッシュ関数にかけた結果とが一致した場合に、
      このユーザは認証されます。
      一方向ハッシュ関数を使っているので、
      もし正しく認証されたワンタイムパスワードが一回盗聴されたとしても、
      次回以降に使われる複数のワンタイムパスワードを生成することは不可能です。
      シーケンス番号はログインが成功するたびに一つずつ減らされて、
      ユーザとログインプログラムの間で同期が取られます。
      シーケンス番号が 1 まで減ったら、
      <acronym>OPIE</acronym> を再度初期化する必要があります。</para>

    <para>このプロセスに関連するいくつかのプログラムがあります。
      &man.opiekey.1; は、シーケンス番号と、シードと、
      秘密のパスフレーズを受け付けて、ワンタイムパスワード 1 つ、
      または一連のワンタイムパスワードの一覧を生成します。
      &man.opiepasswd.1; は、<acronym>OPIE</acronym>
      の初期化に加え、パスワード、
      シーケンス番号やシードを変更するためにも使用されます。
      このプログラムを実行するには、秘密のパスフレーズか、
      または、シーケンス番号とシードとワンタイムパスワードの
      1 組かの、どちらかを与えます。
      &man.opieinfo.1; は、
      認証ファイル (<filename>/etc/opiekeys</filename>) を調べて、
      プログラムを起動したユーザの現在のシーケンス番号とシードを表示します。</para>

    <para>4 種類の異なる操作があります。
      1 つ目は、&man.opiepasswd.1; を信頼できる通信路上で利用して、
      最初にワンタイムパスワードを設定したり、
      秘密のパスフレーズやシードを変更する操作です。
      2 つ目は、同じことを行うために
      &man.opiepasswd.1; を信頼できない通信路上で利用する操作です。
      この場合は信頼できる通信路経由の &man.opiekey.1;
      を併用します。3 つ目は、&man.opiekey.1;
      を使い、信頼できない通信路を通じてログインする操作です。
      4 番目は、&man.opiekey.1;
      を使って複数のワンタイムパスワードを一気に生成する操作です。
      ここで生成した複数のワンタイムパスワードは、
      メモしたり印刷したりして携帯し、
      信頼できる通信路が一切ないところからの接続に利用できます。
      (訳注: ワンタイムパスワードを記録した紙をなくさないこと!
      電話番号や
      IP アドレス、ユーザ名を一緒にメモしていたら最悪です!!)</para>

    <sect2>
      <title>信頼できる通信路での初期化</title>

      <para><acronym>OPIE</acronym> を初めて初期化するには、
	&man.opiepasswd.1; を実行してください。</para>

      <screen>&prompt.user; <userinput>opiepasswd -c</userinput>
[grimreaper] ~ $ opiepasswd -f -c
Adding unfurl:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:

ID unfurl OTP key is 499 to4268
MOS MALL GOAT ARM AVID COED</screen>

      <para><prompt>Enter new secret pass phrase:</prompt>
	または <prompt>Enter secret password:</prompt>
	というプロンプトに対して、
	パスワードまたはパスフレーズを入力してください。
	このパスワードは、
	ログインするときに使うワンタイムパスワードを生成するために使うものであり、
	ログインのためのパスワードではありません。
	<quote>ID</quote> から始まる行は、1 回分のパラメータで、
	ログイン名とシーケンス番号とシードです。
	ログインするときには、
	システム側がこれらのパラメータを覚えていて表示してくれるので、
	これらのパラメータを覚えておく必要はありません。
	最後の行が、今述べたパラメータと入力された秘密のパスワードから計算されたワンタイムパスワードです。
	次にログインするときに打ち込むべきワンタイムパスワードがこれです。</para>
    </sect2>

    <sect2>
      <title>信頼できない通信路での初期化</title>

      <para>信頼できない通信路を使って秘密のパスフレーズを初期化または変更するためには、
	&man.opiekey.1;
	を実行するための信頼できる通信路を用意しておく必要があります。
	たとえばそれは、
	信頼できるマシンのシェルプロンプトだったりするでしょう。
	(訳注: ここでの通信路とはマシンそのものになります。
	信頼できるマシンとは、
	信頼できる人がしっかり管理しているマシンということです)。
	他に準備しておくものとして、シーケンス番号
	(100 は適切な値といえるでしょう) と、場合によっては自分で考えた、
	またはランダムに生成されたシードがあります。
	信頼できない通信路を使うときには、&man.opiepasswd.1;
	を使ってコンピュータを初期化してください。</para>

      <screen>&prompt.user; <userinput>opiepasswd</userinput>

Updating unfurl:
You need the response from an OTP generator.
Old secret pass phrase:
	otp-md5 498 to4268 ext
	Response: GAME GAG WELT OUT DOWN CHAT
New secret pass phrase:
	otp-md5 499 to4269
	Response: LINE PAP MILK NELL BUOY TROY

ID mark OTP key is 499 gr4269
LINE PAP MILK NELL BUOY TROY</screen>

      <para>デフォルトのシードで構わなければ、<keycap>Return</keycap>
	を押してください。アクセスパスワードを入れる前に、
	あらかじめ用意しておいた信頼できる通信路へ移って、
	先ほどと同じパラメータを入力します。</para>

      <screen>&prompt.user; <userinput>opiekey 498 to4268</userinput>
Using the MD5 algorithm to compute response.
Reminder: Do not use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT</screen>

      <para>信頼できない通信路の方に戻って、
	生成されたワンタイムパスワードをコピーして対応するプログラムに入力します。</para>
    </sect2>

    <sect2>
      <title>ワンタイムパスワードを一つ生成する</title>

      <para><acronym>OPIE</acronym> を初期化したら、
	ログイン時には以下のようなプロンプトが出てくるでしょう。</para>

      <screen>&prompt.user; <userinput>telnet example.com</userinput>
Trying 10.0.0.1...
Connected to example.com
Escape character is '^]'.

FreeBSD/i386 (example.com) (ttypa)

login: <userinput>&lt;ユーザ名&gt;</userinput>
otp-md5 498 gr4269 ext
Password: </screen>

      <para><acronym>OPIE</acronym>
	のプロンプトには便利な機能が備わっています。
	パスワードプロンプトに対して、
	<keycap>Return</keycap> を押すとエコーモードに切り替わり、
	タイプした文字がそのまま見えるようになるのです。
	これは、
	紙に印刷していたりするワンタイムパスワードを手で入力しなければならない場合に役立つ機能です。</para>

      <indexterm><primary>MS-DOS</primary></indexterm>
      <indexterm><primary>Windows</primary></indexterm>
      <indexterm><primary>MacOS</primary></indexterm>

      <para>次に、
	このログインプロンプトに対して入力するワンタイムパスワードを生成してください。
	これは、&man.opiekey.1;
	プログラムを使える信頼できるマシン上で行わなければなりません。
	このプログラムには &windows;, &macos; および &os; 版があります。
	どちらも、
	コマンドラインからシーケンス番号とシードを指定しなければなりません。
	ログインしようとしているマシンのログインプロンプトから直接カットアンドペーストすると楽でしょう。</para>

      <para>信頼できるシステムで</para>

      <screen>&prompt.user; <userinput>opiekey 498 to4268</userinput>
Using the MD5 algorithm to compute response.
Reminder: Do not use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT</screen>

      <para>ワンタイムパスワードが生成されたので、
	ログインを続けてください。</para>
    </sect2>

    <sect2>
      <title>複数のワンタイムパスワードを生成する</title>

      <para>都合によっては、
	信頼できるマシンや信頼できる通信路が一切確保できないようなことがあるでしょう。
	このような場合には、&man.opiekey.1;
	を使って複数のワンタイムパスワードを生成できます。
	たとえば</para>

      <screen>&prompt.user; <userinput>opiekey -n 5 30 zz99999</userinput>
Using the MD5 algorithm to compute response.
Reminder: Do not use opiekey from telnet or dial-in sessions.
Enter secret pass phrase: <userinput>&lt;secret password&gt;</userinput>
26: JOAN BORE FOSS DES NAY QUIT
27: LATE BIAS SLAY FOLK MUCH TRIG
28: SALT TIN ANTI LOON NEAL USE
29: RIO ODIN GO BYE FURY TIC
30: GREW JIVE SAN GIRD BOIL PHI</screen>

      <para><option>-n 5</option> という引数によって 5
	個のワンタイムパスワードを順に生成します。
	また <option>30</option> は、
	最後のシーケンス番号となるべき数字です。出力は使う順番とは
	<emphasis>逆</emphasis>
	に出力されていることに注意してください (訳注:
	一番最初に使うワンタイムパスワードは一番最後に出力されたものです)。
	もしあなたがセキュリティに偏執するなら、
	この結果を紙と鉛筆を使って手で書き移した方がよいかもしれません。
	そうでなければ、この結果を印刷すると良いでしょう。
	ここで、
	出力の各行はシーケンス番号とそれに対応する一回分のワンタイムパスワードです。
	消費済みのワンタイムパスワードをペンで消していってください。</para>
    </sect2>

    <sect2>
      <title>&unix; パスワードの利用を制限する</title>

      <para><acronym>OPIE</acronym> は、ログインセッションの IP
	アドレスをベースとした &unix; パスワードの使用を制限できます。
	関連ファイルは、<filename>/etc/opieaccess</filename> で、
	デフォルトで用意されています。
	このファイルの詳細や、
	このファイルを使用する際に考慮すべきセキュリィについては
	&man.opieaccess.5; を確認してください。</para>

      <para>以下は <filename>opieaccess</filename> の例です。</para>

      <programlisting>permit 192.168.0.0 255.255.0.0</programlisting>

      <para>この行では、(なりすましされやすい) IP ソースアドレスが、
	ある値やマスクにマッチするユーザに対して、
	&unix; パスワードをいつでも許可します。</para>

      <para>もし <filename>opieaccess</filename>
	のどのルールにも一致しなければ、
	デフォルトでは非 <acronym>OPIE</acronym> ログインは使えません。</para>
    </sect2>
  </sect1>

  <sect1 xml:id="tcpwrappers">
    <info><title>TCP Wrappers</title>
      <authorgroup>
	<author>
	  <personname>
	    <firstname>Tom</firstname>
	    <surname>Rhodes</surname>
	  </personname>
	  <contrib>執筆: </contrib>
	</author>
      </authorgroup>
    </info>

    <indexterm><primary>TCP Wrappers</primary></indexterm>

    <para><acronym>TCP</acronym> Wrappers は、
      すべてのサーバデーモンに対するサポートをその管理下で提供できるように、
      <xref linkend="network-inetd"/> の機能を拡張します。
      この方法を使うことで、ログへの対応、
      接続に対してメッセージを返したり、
      内部の接続だけを許可するようにデーモンを設定することが可能となります。
      これらの機能のいくつかはファイアウォールでも実装できますが、
      <acronym>TCP</acronym> Wrappers は、
      システムを守るためのレイヤを追加し、
      ファイアウォールが提供する以上の管理機能を提供します。</para>

    <para><acronym>TCP</acronym> Wrappers は、
      適切に設定されたファイアウォールの置き換えと考えるべきではありません。
      <acronym>TCP</acronym> Wrappers は、
      ファイアウォールや他のセキュリティ強化のツールと組み合わせて使うべきです。</para>

    <sect2>
      <title>初期設定</title>

      <para>&os; 上で <acronym>TCP</acronym> Wrappers を有効にするには、
	<filename>rc.conf</filename> から
	<option>-Ww</option> オプションで
	&man.inetd.8; サーバが起動されることを確認してください。
	その後、<filename>/etc/hosts.allow</filename>
	を適切に設定してください。</para>

      <note>
	<para>他の <acronym>TCP</acronym> Wrappers の実装と異なり、
	  <filename>hosts.deny</filename> は廃止されました。
	  すべての設定オプションは <filename>/etc/hosts.allow</filename>
	  に書かれている必要があります。</para>
      </note>

      <para>最も簡単な設定におけるデーモンの接続ポリシは、
	<filename>/etc/hosts.allow</filename> の中で、
	オプションごとに許可またはブロックするように設定するというものです。
	&os; のデフォルトの設定では、&man.inetd.8;
	から起動されたすべてのデーモンの接続を許可します。</para>

      <para>基本的な設定は、通常
	<literal>daemon : address : action</literal>
	という形式です。ここで、
	<literal>daemon</literal> は、
	&man.inetd.8; が起動するデーモンの名前です。
	<literal>address</literal> の部分は、有効なホスト名、
	<acronym>IP</acronym> アドレスまたは、
	括弧 ([&nbsp;]) で囲まれた IPv6 アドレスです。
	<literal>action</literal> は、
	<literal>allow</literal> または <literal>deny</literal> です。
	<acronym>TCP</acronym> Wrappers は、
	最初にマッチしたルールが適用されます。
	これは、設定ファイルに対するルールにマッチするかどうかのスキャンは、
	昇順に行われることを意味しています。
	マッチすると、ルールが適用され、
	検索のプロセスは終了します。</para>

      <para>例として、<acronym>POP</acronym>3 の接続を
	<package>mail/qpopper</package>
	デーモン経由で許可するには、以下の行を
	<filename>hosts.allow</filename> に追加してください。</para>

      <programlisting># This line is required for POP3 connections:
qpopper : ALL : allow</programlisting>

      <para>この行を追加したら、
	&man.inetd.8; を再起動してください。</para>

	<screen>&prompt.root; <userinput>service inetd restart</userinput></screen>
    </sect2>

    <sect2>
      <title>高度な設定</title>

      <para><acronym>TCP</acronym> Wrappers は、
	接続を取り扱う以上の制御を行う高度な設定も提供しています。
	ある時は、
	接続しているホストまたはデーモンにコメントを返すことが適切であることがあります。
	別の場合では、おそらくログエントリを記録したり、
	管理者にメールで送る必要があることもあるでしょう。
	またその他の状況としては、
	サービスをローカルの接続のみの使用に制限する必要がある場合もあります。
	これらはすべて、<literal>ワイルドカード</literal>
	と呼ばれる設定のオプション (拡張文字および外部コマンドの実行)
	で可能となります。</para>

      <sect3>
	<title>外部コマンド</title>

	<para>接続は拒否しなければならないが、
	  その理由を接続の確立を試みた相手に送りたい状況を考えてください。
	  このアクションは、<option>twist</option> を使うことで実現可能です。
	  接続が試みられると、<option>twist</option>
	  はシェルコマンドまたはスクリプトを実行します。
	  この場合の例は、
	  <filename>hosts.allow</filename> に書かれています。</para>

	<programlisting># The rest of the daemons are protected.
ALL : ALL \
	: severity auth.info \
	: twist /bin/echo "You are not welcome to use %d from %h."</programlisting>

	<para>この例では、
	  <quote>You are not allowed to use <literal>daemon</literal>
	  from <literal>hostname</literal>.</quote> というメッセージを、
	  アクセスファイルの中で設定されていないすべてのデーモンに対して返します。
	  接続元に対し、
	  確立された接続が破棄された直後に返答することは有効です。
	  返信に使われるメッセージは、引用符 (<literal>"</literal>) で囲む
	  <emphasis>必要</emphasis> があります。</para>

	<warning>
	  <para>攻撃者や攻撃者のグループは、
	    これらのデーモンの接続のリクエストであふれさせることにより、
	    サーバに対して DoS 攻撃を仕掛けることができます。</para>
	</warning>

	<para>他の可能性は <option>spawn</option> を使うことです。
	  <option>twist</option> と同様に、
	  <option>spawn</option> は、暗黙のうちに接続を拒否し、
	  外部のシェルコマンドやスクリプトを実行できます。
	  <option>twist</option> と異なり、<option>spawn</option> は、
	  接続を確立した相手に対し、返事を返すことはありません。
	  たとえば、以下のような設定の行を考えてみてください。</para>

	<programlisting># We do not allow connections from example.com:
ALL : .example.com \
	: spawn (/bin/echo %a from %h attempted to access %d &gt;&gt; \
	  /var/log/connections.log) \
	: deny</programlisting>

	<para>この行は、<systemitem
	    class="fqdomainname">*.example.com</systemitem>
	  からの接続をすべて拒否します。
	  ホスト名、<acronym>IP</acronym>
	  アドレスおよびアクセスを試みたデーモンが、
	  <filename>/var/log/connections.log</filename>
	  に記録されます。</para>

	<para>この例では、置換文字 <literal>%a</literal> および
	  <literal>%h</literal> が使われています。
	  置換文字の完全な一覧は
	  &man.hosts.access.5; をご覧ください。</para>
      </sect3>

      <sect3>
	<title>ワイルドカードオプション</title>

	<para><literal>ALL</literal> オプションは、
	  デーモン、ドメインまたは <acronym>IP</acronym>
	  アドレスのすべてのインスタンスのどれかにマッチするかどうかに使われます。
	  他のワイルドカードは、偽造された <acronym>IP</acronym>
	  アドレスを提供するホストにマッチするかどうかに用いられる
	  <literal>PARANOID</literal> です。
	  たとえば、<literal>PARANOID</literal> を使うことで、
	  ホスト名と異なる <acronym>IP</acronym>
	  アドレスからの接続があった時のアクションを定義できます。
	  以下の例では、ホスト名から検索される
	  <acronym>IP</acronym> アドレスと異なる
	  <acronym>IP</acronym> アドレスを持つ
	  &man.sendmail.8;
	  への接続のすべてのリクエストを拒否します。</para>

	<programlisting># Block possibly spoofed requests to sendmail:
sendmail : PARANOID : deny</programlisting>

	<caution>
	  <para>クライアントもしくはサーバの <acronym>DNS</acronym>
	    の設定が間違っている場合に、
	    <literal>PARANOID</literal> ワイルドカードを使うと、
	    サーバがとても使いづらくなります。
	    管理者の慎重さが求められます。</para>
	</caution>

	<para>ワイルドカードおよび関連する機能についてもっと知りたい場合には、
	  &man.hosts.access.5; をご覧ください。</para>

	<para>上記の設定が動作するには、<filename>hosts.allow</filename>
	  の中で、
	  最初の設定の行がコメントアウトされている必要があります。</para>
      </sect3>
    </sect2>
  </sect1>

  <sect1 xml:id="kerberos5">
    <info><title><application>Kerberos5</application></title>
      <authorgroup>
	<author>
	  <personname>
	    <firstname>Tillman</firstname>
	    <surname>Hodgson</surname>
	  </personname>
	  <contrib>寄稿: </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <personname>
	    <firstname>Mark</firstname>
	    <surname>Murray</surname>
	  </personname>
	  <contrib>基にした文書の執筆: </contrib>
	</author>
      </authorgroup>
    </info>

    <para><application>Kerberos</application> は、
      サーバのサービスによってユーザが安全に認証を受けられるようにするための、
      ネットワークの付加システムおよびプロトコルです。
      <application>Kerberos</application> は、
      身元確認プロキシシステムや、
      信頼される第 3 者認証システムとも説明されます。
      ユーザが <application>Kerberos</application> を使って認証を行った後は、
      通信は暗号化され、
      プライバシおよびデータの完全性を保証することができます。</para>

    <para><application>Kerberos</application> の唯一の機能は、
      ネットワーク上のユーザの安全な認証を提供することです。
      承認 (どのユーザが許可されているか) や監査
      (ユーザがどのような作業を行っているか) の機能は提供しません。
      <application>Kerberos</application> を使う際は、
      承認および監査サービスを提供する他のセキュリティの手段との利用が、
      推奨されます。</para>

    <para>この節では、&os; 用として配布されている
      <application>Kerberos</application>
      をセットアップする際のガイドを提供します。
      完全な説明が必要な場合には、
      マニュアルページを参照してください。</para>

    <para>この節における <application>Kerberos</application>
      のインストールのデモでは、以下のような名前空間が使われます。</para>

    <itemizedlist>
      <listitem>
	<para><acronym>DNS</acronym> ドメイン (<quote>ゾーン</quote>) は、
	  <systemitem class="fqdomainname">example.org</systemitem>
	  です。</para>
      </listitem>

      <listitem>
	<para><application>Kerberos</application> の領域は、
	  <literal>EXAMPLE.ORG</literal> です。</para>
      </listitem>
    </itemizedlist>

    <note>
      <para><application>Kerberos</application> の設定では、
	内部での使用でも実際のドメイン名を使ってください。
	<acronym>DNS</acronym> の問題を避けることができ、
	他の <application>Kerberos</application> のレルム (realm)
	との相互運用を保証します。</para>
    </note>

    <sect2>
      <title>歴史</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>歴史</secondary>
      </indexterm>

      <para><application>Kerberos</application> は、
	ネットワークのセキュリティ問題を解決するために、
	<acronym>MIT</acronym> で開発されました。
	<application>Kerberos</application> プロトコルは、
	必ずしも安全ではないインターネット接続においても、
	サーバに対して (逆もまた同様に)、
	強い暗号を使って身元を証明します。</para>

      <para><application>Kerberos</application> は、
	ネットワーク認証プロトコルの名前であり、
	<application>Kerberos</application> telnet のように、
	このプログラムを実装しているプログラムを表すための形容詞でもあります。
	プロトコルの現在のバージョンはバージョン 5 で、
	<acronym>RFC</acronym>&nbsp;1510 として文書化されています。</para>

      <para>このプロトコルのいくつものフリーの実装が、
	さまざまなオペレーティングシステムで利用できます。
	最初の <application>Kerberos</application>
	を開発したマサチューセッツ工科大学 (<acronym>MIT</acronym>) は、
	開発した <application>Kerberos</application>
	パッケージを継続的に保守しています。
	<acronym>アメリカ合衆国</acronym>では暗号製品として良く使われていますが、
	歴史的には、
	<acronym>アメリカ合衆国</acronym> の輸出規制により制限されてきました。
	<acronym>MIT</acronym> で実装された
	<application>Kerberos</application> は、
	<package>security/krb5</package> package または
	port から利用できます。
	バージョン 5 のもう一つの実装が、
	Heimdal	<application>Kerberos</application>
	です。
	この実装は、<acronym>アメリカ合衆国</acronym>の外で開発されたため、
	輸出の制限を避けることができます。
	Heimdal <application>Kerberos</application> は
	<package>security/heimdal</package>>
	package または port からインストールできますが、最小構成は
	&os; の base インストールに含まれています。</para>

      <para>以下の説明では &os; に含まれている Heimdal
	ディストリビューションの使用を想定しています。</para>
    </sect2>

    <sect2>
      <title>Heimdal <acronym>KDC</acronym> の設定</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>鍵配布センター</secondary>
      </indexterm>

      <para>鍵配布センター (<acronym>KDC</acronym>) は、
	<application>Kerberos</application>
	が提供する中心的な認証サービスで、
	<application>Kerberos</application>
	チケットを発行するコンピュータです。
	<acronym>KDC</acronym> は、
	<application>Kerberos</application>
	のレルムの中のすべてのコンピュータから
	<quote>信頼</quote>されています。
	そのため、厳重なセキュリティに対する配慮が必要となります。</para>

      <para><application>Kerberos</application>
	サーバの実行にコンピュータのリソースはほとんど必要ありませんが、
	セキュリティの観点から、<acronym>KDC</acronym>
	としてのみ機能する専用のコンピュータが推奨されます。</para>

      <para><acronym>KDC</acronym> を設定するにあたって、
	<acronym>KDC</acronym> として動作するために、
	適切に <filename>/etc/rc.conf</filename>
	が設定されていることを確認してください。
	必要に応じて、
	システムの設定を反映するようにパスを調整する必要があります。</para>

      <programlisting>kerberos5_server_enable="YES"
kadmind5_server_enable="YES"</programlisting>

      <para>次に、<filename>/etc/krb5.conf</filename>
	を以下のように編集してください。</para>

      <programlisting>[libdefaults]
    default_realm = EXAMPLE.ORG
[realms]
    EXAMPLE.ORG = {
        kdc = kerberos.example.org
        admin_server = kerberos.example.org
    }
[domain_realm]
    .example.org = EXAMPLE.ORG</programlisting>

      <para><filename>/etc/krb5.conf</filename> の中で、
	<acronym>KDC</acronym> は、
	完全修飾されたホスト名 <systemitem
	  class="fqdomainname">kerberos.example.org</systemitem>
	を使うことが想定されています。
	<acronym>KDC</acronym> が異なるホスト名を持つ場合には、
	名前の解決が行われるように、適切に CNAME (エイリアス)
	エントリをゾーンファイルに追加してください。</para>

      <note>
	<para>適切に <acronym>DNS</acronym>
	  サーバが設定されている大きなネットワークでは、
	  上記の例は、以下のように整理されます。</para>

	<programlisting>[libdefaults]
      default_realm = EXAMPLE.ORG</programlisting>

	<para>そして、<systemitem
	    class="fqdomainname">example.org</systemitem>
	  ゾーンファイルには、以下の行が付け加えられます。</para>

	<programlisting>_kerberos._udp      IN  SRV     01 00 88 kerberos.example.org.
_kerberos._tcp      IN  SRV     01 00 88 kerberos.example.org.
_kpasswd._udp       IN  SRV     01 00 464 kerberos.example.org.
_kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.example.org.
_kerberos           IN  TXT     EXAMPLE.ORG</programlisting>
      </note>

      <note>
	<para>クライアントが、
	  <application>Kerberos</application> サービスを見つけるためには、
	  <filename>/etc/krb5.conf</filename> を完全に設定するか、
	  <filename>/etc/krb5.conf</filename> を最低限に設定し、
	  <emphasis>さらに</emphasis> DNS サーバを適切に設定する
	  <emphasis>必要</emphasis> があります。</para>
      </note>

      <para>次に <application>Kerberos</application>
	データベースを作成してください。
	このデータベースには、
	マスター鍵により暗号化されたすべてのプリンシパルの鍵が含まれています。
	このパスワードは、
	<filename>/var/heimdal/m-key</filename> に保存されるため、
	覚える必要はありません。
	マスター鍵を作成するには、&man.kstash.8; を実行して、
	パスワードを入力してください。</para>

      <para>マスター鍵を作成したら、<command>kadmin -l</command>
	を使ってデータベースを初期化してください。
	このオプションを使うと、&man.kadmin.8; は、
	&man.kadmind.8; ネットワークサービスを使わず、
	ローカルのデータベースファイルを直接変更します。
	これにより、
	データベースを作成する前に、データベースへの接続を試みてしまうという、
	卵が先か鶏が先かという問題を回避できます。
	&man.kadmin.8; プロンプトで、
	<command>init</command> を使って、
	レルムに関する初期のデータベースを作成してください。</para>

      <para>最後に、&man.kadmin.8; プロンプトで
	<command>add</command> を使って最初のプリンシパルを作成して下さい。
	差し当たりは、
	プリンシパルに対するデフォルトのオプションに従ってください。
	後で <command>modify</command> を使うことで、
	変更することができます。
	&man.kadmin.8; プロンプトで <literal>?</literal> と入力すると、
	利用可能なオプションを確認できます。</para>

      <para>データベース作成のセッションの例は以下のようになります。</para>

      <screen>&prompt.root; <userinput>kstash</userinput>
Master key: <userinput>xxxxxxxx</userinput>
Verifying password - Master key: <userinput>xxxxxxxx</userinput>

&prompt.root; <userinput>kadmin -l</userinput>
kadmin&gt; <userinput>init EXAMPLE.ORG</userinput>
Realm max ticket life [unlimited]:
kadmin&gt; <userinput>add tillman</userinput>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: <userinput>xxxxxxxx</userinput>
Verifying password - Password: <userinput>xxxxxxxx</userinput></screen>

      <para>次に <acronym>KDC</acronym> サービスを起動してください。
	<command>service kerberos start</command> および
	<command>service kadmind start</command>
	を実行してサービスを起動してください。
	この時点で、kerberos 化されたデーモンが走っていなくても、
	<acronym>KDC</acronym> のコマンドラインから、作成したばかりの (ユーザ)
	プリンシパルのチケットを入手したり、
	一覧を表示することができることを確認できます。</para>

      <screen>&prompt.user; <userinput>kinit tillman</userinput>
tillman@EXAMPLE.ORG's Password:

&prompt.user; <userinput>klist</userinput>
Credentials cache: FILE:<filename>/tmp/krb5cc_500</filename>
	Principal: tillman@EXAMPLE.ORG

  Issued           Expires          Principal
Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>

      <para>必要がなくなった時には、チケットを破棄できます。</para>

      <screen>&prompt.user; <userinput>kdestroy</userinput></screen>
    </sect2>

    <sect2>
      <title>Heimdal <application>Kerberos</application>
	サービスを有効にする。</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>Enabling サービス</secondary>
      </indexterm>

      <para>最初に <filename>/etc/krb5.conf</filename> を
	<acronym>KDC</acronym> からクライアントコンピュータへ、
	&man.scp.1;
	または物理的にリムーバブルディスクを使うといった安全な方法でコピーしてください。</para>

      <para>次に <filename>/etc/krb5.keytab</filename>
	を作成してください。
	これが <application>Kerberos</application>
	化されたデーモンを提供するサーバとワークステーションの間での大きな違いです:
	サーバには <filename>keytab</filename> が置かれている必要があります。
	このファイルには、サーバのホスト鍵が含まれています。
	この鍵により、ホストおよび
	<acronym>KDC</acronym> が他の身元の検証ができます。
	鍵が公開されてしまうと、
	サーバのセキュリティが破られてしまうため、
	このファイルは安全にサーバに転送しなければなりません。</para>

      <para>一般的には、&man.kadmin.8; を使って、
	<filename>keytab</filename> をサーバに転送します。
	ホストプリンシパル
	(<acronym>KDC</acronym> 側の
	<filename>krb5.keytab</filename>)
	も &man.kadmin.8; を使って作成するので便利です。</para>

      <para>すでにチケットを入手し、そのチケットは、
	&man.kadmin.8; インタフェースで使用できることが
	<filename>kadmind.acl</filename>
	で許可されている必要があります。
	アクセスコントロールリストの設計の詳細については、
	<command>info heimdal</command> の
	<quote>Remote administration</quote>
	というタイトルの章をご覧ください。
	リモートからの
	<command>kadmin</command> アクセスを有効にする代わりに、
	管理者は、ローカルコンソールまたは &man.ssh.1;
	を用いて安全に <acronym>KDC</acronym> に接続し、
	<command>kadmin -l</command> を使用して、
	ローカルで管理作業を行うことができます。</para>

      <para><filename>/etc/krb5.conf</filename>
	をインストールしたら、
	<application>Kerberos</application> サーバから
	<command>add --random-key</command> を使ってください。
	このコマンドは、サーバのホストプリンシパルを追加します。
	そして、<command>ext</command> を用いて、
	サーバのホストプリンシパルを keytab に抽出してください。
	以下は、使用例です。</para>

      <screen>&prompt.root; <userinput>kadmin</userinput>

kadmin&gt;<userinput> add --random-key host/myserver.example.org</userinput>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
kadmin&gt;<userinput> ext host/myserver.example.org</userinput>
kadmin&gt;<userinput> exit</userinput></screen>

      <para><command>ext</command> は、デフォルトでは、抽出された鍵を
	<filename>/etc/krb5.keytab</filename> に保存します。</para>

      <para><acronym>KDC</acronym> 上で &man.kadmind.8;
	を走らせていない場合で、
	リモートから &man.kadmin.8; に接続出来ない場合には、
	ホストプリンシパル (<systemitem
	  class="username">host/myserver.EXAMPLE.ORG</systemitem>)
	を直接 <acronym>KDC</acronym> 上で追加し、
	その後、以下のように
	<acronym>KDC</acronym> 上の
	<filename>/etc/krb5.keytab</filename> の上書きを避けるため、
	一時ファイルに抽出してください。</para>

      <screen>&prompt.root; <userinput>kadmin</userinput>
kadmin&gt;<userinput> ext --keytab=/tmp/example.keytab host/myserver.example.org</userinput>
kadmin&gt;<userinput> exit</userinput></screen>

      <para>その後、&man.scp.1; またはリムーバブルディスクを使って、
	keytab を安全にサーバコンピュータにコピーしてください。
	<acronym>KDC</acronym> 上の keytab を上書きすることを避けるため、
	デフォルトとは異なる名前を指定してください。</para>

      <para>これでサーバは、
	<filename>krb5.conf</filename> を使って
	<acronym>KDC</acronym> と通信ができるようになりました。
	そして、<filename>krb5.keytab</filename>
	によって身元を証明できるようになったので、
	<application>Kerberos</application>
	サービスを有効にする準備が出来ました。
	この例では、
	&man.telnetd.8; サービスが
	<filename>/etc/inetd.conf</filename> で有効に設定され、
	<command>service inetd restart</command> によって、
	&man.inetd.8; サービスを再起動します。</para>

      <programlisting>telnet    stream  tcp     nowait  root    /usr/libexec/telnetd  telnetd -a user</programlisting>

      <para>重要な変更箇所は、<option>-a</option>
	認証がユーザに設定されていることです。
	詳細については、
	&man.telnetd.8; を参照してください。</para>
    </sect2>

    <sect2>
      <title>Heimdal <application>Kerberos</application>
	クライアントを有効にする</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>クライアントの設定</secondary>
      </indexterm>

      <para>クライアントコンピュータの設定は簡単です。
	<filename>/etc/krb5.conf</filename> のみが必要です。
	このファイルをセキュリティ的に安全な方法で、<acronym>KDC</acronym>
	からクライアントコンピュータへコピーしてください。</para>

      <para>クライアントから、&man.kinit.1;,
	&man.klist.1; および &man.kdestroy.1; を使用し、
	上記で作成したプリンシパルに対するチケットの入手、表示、
	削除を行い、クライアントコンピュータを試験してください。
	<application>Kerberos</application>
	アプリケーションを使って <application>Kerberos</application>
	が有効なサーバに接続することもできるはずです。
	もしうまく機能しない場合でも、チケットを入手できるのであれば、
	問題はおそらくサーバにあり、
	クライアントまたは <acronym>KDC</acronym>
	の問題ではないと考えられます。</para>

      <para>Kerberos 化されたアプリケーションを試験する際には、
	&man.tcpdump.1; といったパケットスニファを使用して、
	パスワードが平文で送られていないことを確認してください。</para>

      <para>コア以外の さまざまな
	<application>Kerberos</application>
	クライアントアプリケーションが利用可能です。
	&os; の	<quote>最小</quote> インストールでは、
	インストールされる
	<application>Kerberos</application>
	化された唯一のサービスは、&man.telnetd.8; です。</para>

      <para>Heimdal port は、
	<application>Kerberos</application> 化されている
	&man.ftpd.8;, &man.rshd.8;, &man.rcp.1;, &man.rlogind.8;
	および他のあまり一般的ではないプログラムをインストールします。
	<acronym>MIT</acronym> port も、すべての
	<application>Kerberos</application>
	クライアントアプリケーションをインストールします。</para>
    </sect2>

    <sect2>
      <title>ユーザ設定ファイル: <filename>.k5login</filename>
	および <filename>.k5users</filename></title>

      <indexterm>
	<primary><filename>.k5login</filename></primary>
      </indexterm>

      <indexterm>
	<primary><filename>.k5users</filename></primary>
      </indexterm>

      <para>レルムのユーザは、一般的には、
	ローカルユーザアカウントに対応する
	<application>Kerberos</application> プリンシパルを持ちます。
	しかしながら、時々
	<application>Kerberos</application>
	プリンシパルに対応しないローカルユーザアカウントへのアクセスが必要となることがあります。
	たとえば、
	<systemitem class="username">tillman@EXAMPLE.ORG</systemitem>
	が、ローカルユーザアカウント
	<systemitem class="username">webdevelopers</systemitem>
	へのアクセスが必要となることがあります。そして、
	他のプリンシパルが同じローカルアカウントにアクセスが必要になることもあります。 </para>

      <para>ユーザのホームディレクトリに置かれた
	<filename>.k5login</filename> および
	<filename>.k5users</filename> ファイルを使うことで、
	この問題を解決出来ます。
	たとえば、以下の行を含む
	<filename>.k5login</filename> を
	<systemitem class="username">webdevelopers</systemitem>
	のホームディレクトリに置くと、
	一覧にある両方のプリンシパルは、
	共有のパスワードを必要としなくても、
	このアカウントにアクセス出来ます。</para>

      <screen>tillman@example.org
jdoe@example.org</screen>

      <para><filename>.k5users</filename> の詳細については、
	&man.ksu.1; を参照してください。</para>
    </sect2>

    <sect2>
      <title><application>Kerberos</application>
	Tips, Tricks, およびトラブルシューティング</title>

      <itemizedlist>
	<listitem>
	  <para>Heimdal または <acronym>MIT</acronym>
	    <application>Kerberos</application><indexterm><primary>Kerberos5</primary><secondary>troubleshooting</secondary></indexterm> ports
	    のどちらを使う場合でも、
	    <envar>PATH</envar> は、
	    <application>Kerberos</application> 版のクライアント
	    アプリケーションが、
	    システムにあるアプリケーションより先に見つかるように設定されていることを確認してください。</para>
	</listitem>

	<listitem>
	  <para>レルムにあるすべてのコンピュータの間で時刻が同期していないと、
	    認証に失敗してしまいます。
	    <acronym>NTP</acronym> を用いた、時刻の同期方法については、
	    <xref linkend="network-ntp"/> をご覧ください。</para>
	</listitem>

	<listitem>
	  <para><acronym>MIT</acronym> および Heimdal 間の運用は、
	    標準化されていない &man.kadmin.8; を除けばうまく機能します。</para>
	</listitem>

	<listitem>
	  <para>ホスト名が変更された場合は、
	    <systemitem class="username">host/</systemitem>
	    プリンシパルを変更し、keytab をアップデートする必要があります。
	    Apache の
	    <package>www/mod_auth_kerb</package>
	    で使われる
	    <systemitem class="username">www/</systemitem>
	    プリンシパルのような特別な
	    keytab エントリでも必要となります。</para>
	</listitem>

	<listitem>
	  <para>レルムの中のすべてのホストは、<acronym>DNS</acronym>、
	    もしくは、最低限 <filename>/etc/hosts</filename>
	    において正引きおよび逆引き両方で名前解決できる必要があります。
	    CNAME は動作しますが、A および PTR レコードは、
	    正しく適切な位置に記述されている必要があります。
	    名前が解決できない場合のエラーメッセージは、
	    次の例のように、直感的に原因が分かるようなものではありません。
	    <errorname>Kerberos5 refuses authentication because Read
	      req failed: Key table entry not
	      found</errorname>.</para>
	</listitem>

	<listitem>
	  <para><acronym>KDC</acronym>
	    に対しクライアントとして振る舞うオペレーティングシステムの中には、
	    &man.ksu.1; に対して、
	    <systemitem class="username">root</systemitem> 権限に
	    setuid を許可しないものがあります。
	    この設定では、
	    &man.ksu.1; は動作しないことを意味します。
	    これは <acronym>KDC</acronym> のエラーではありません。</para>
	</listitem>

	<listitem>
	  <para><acronym>MIT</acronym>
	    <application>Kerberos</application> において、
	    プリンシパルが、デフォルトの 10
	    時間を超えるチケットの有効期限としたい場合には、
	    &man.kadmin.8; のプロンプトで
	    <command>modify_principal</command> を使って、
	    対象のプリンシパルおよび
	    <systemitem class="username">krbtgt</systemitem>
	    プリンシパル両方の有効期限の最大値を変更してください。
	    プリンシパルは、
	    <command>kinit -l</command> を使用して、
	    長い有効期限のチケットを要求できます。</para>
	</listitem>

	<listitem>
	  <note><para>トラブルシューティングのために、
	    <acronym>KDC</acronym> でパケットスニファを走らせ、
	    一方で、ワークステーションにおいて
	    &man.kinit.1; を実行すると、
	    &man.kinit.1; を実行するやいなや、
	    パスワードを入力し終わる前でも、
	    Ticket Granting Ticket (<acronym>TGT</acronym>) が送られてきます。
	    これに関する説明は、以下の通りです。
	    <application>Kerberos</application> サーバは、
	    いかなる未承認のリクエストに対して、
	    自由に <acronym>TGT</acronym> を送信します。
	    しかしながら、すべての
	    <acronym>TGT</acronym> は、
	    ユーザのパスワードから生成された鍵により、暗号化されています。
	    そのため、ユーザがパスワードを入力した時には、
	    パスワードは <acronym>KDC</acronym> には送られません。
	    その代わりこのパスワードは、&man.kinit.1; がすでに入手した
	    <acronym>TGT</acronym> の復号化に使われます。
	    もし、復号化の結果、
	    有効なチケットで有効なタイムスタンプの場合には、
	    ユーザは、有効な <application>Kerberos</application>
	    クレデンシャルを持ちます。
	    このクレデンシャルには、
	    <application>Kerberos</application>
	    サーバ自身の鍵により暗号化された実際の
	    <acronym>TGT</acronym> とともに、将来
	    <application>Kerberos</application>
	    サーバと安全な通信を確立するためのセッション鍵が含まれています。
	    この暗号の 2 番目のレイヤは、
	    <application>Kerberos</application> サーバが、
	    各 <acronym>TGT</acronym>
	    の真偽の検証を可能にしている部分です。</para></note>
	</listitem>

	<listitem>
	  <para>たとえば一週間といった長い有効期限のチケットを使いたい場合で、
	    <application>OpenSSH</application> を使って、
	    チケットが保存されているコンピュータに接続しようとする場合は、
	    <application>Kerberos</application>
	    <option>TicketCleanup</option> が
	    <filename>sshd_config</filename> において
	    <literal>no</literal> と設定されているか、
	    チケットが、ログアウト時に削除されることを確認してください。</para>
	</listitem>

	<listitem>
	  <para>ホストプリンシパルは長い有効期限のチケットを持つことができます。
	    もし、ユーザプリンシパルが 1 週間の有効期限を持ち、
	    接続しているホストが、9 時間の有効期限を持っている場合には、
	    ユーザキャッシュは有効期限が切れたホストプリンシパルを持つことになり、
	    想定したように、
	    チケットキャッシュが振る舞わないことが起こりえます。</para>
	</listitem>

	<listitem>
	  <para>&man.kadmind.8; で説明されているような、
	    特定の問題のあるパスワードが使われることを避けるために
	    <filename>krb5.dict</filename> を設定する時には、
	    パスワードポリシが割り当てられたプリンシパルにのみ適用されることを覚えていてください。
	    <filename>krb5.dict</filename> で使われている形式では、
	    一行に一つの文字列が置かれています。
	    <filename>/usr/share/dict/words</filename>
	    にシンボリックリンクを作成することは、有効です。</para>
	</listitem>
      </itemizedlist>
    </sect2>

    <sect2>
      <title><acronym>MIT</acronym> port との違いについて</title>

      <para><acronym>MIT</acronym> と Heimdal 版の大きな違いは、
	&man.kadmin.8; に関連しています。
	このプログラムは、異なる (ただし等価な) コマンド群を持ち、そして、
	異なるプロトコルを使用します。
	もし <acronym>KDC</acronym> に <acronym>MIT</acronym>
	を使用している場合には、
	Heimdal 版の &man.kadmin.8;
	を使って <acronym>KDC</acronym> をリモートから
	(逆も同様に) 管理できないことを意味しています。</para>

      <para>クライアントアプリケーションでは、同じタスクを行う際に、
	若干異なるコマンドラインのオプションが使われることもあります。
	<acronym>MIT</acronym>
	<application>Kerberos</application> <link
	  xlink:href="http://web.mit.edu/Kerberos/www/">ウェブサイト</link>
	に書かれているガイドに従うことが推奨されます。
	path の問題について注意してください。
	<acronym>MIT</acronym> port はデフォルトで
	<filename>/usr/local/</filename> にインストールします。
	そのため、もし <envar>PATH</envar>
	においてシステムのディレクトが最初に書かれている場合には、
	<acronym>MIT</acronym> 版ではなく、<quote>通常の</quote>
	システムアプリケーションが起動してしまいます。</para>

      <note><para>&os; の <acronym>MIT</acronym>
	<package>security/krb5</package> port において、
	&man.telnetd.8; および <command>klogind</command>
	経由でのログインが奇妙な振る舞いをすることを理解するには、
	port からインストールされる
	<filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>
	を読んで下さい。
	<quote>incorrect permissions on cache file</quote>
	の振る舞いを修正するには、
	フォワードされたクレデンシャリングの所有権を適切に変更できるように、
	<command>login.krb5</command>
	バイナリが認証に使われる必要があります。</para></note>

      <para><filename>rc.conf</filename>
	を以下のように変更する必要もあります。</para>

      <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
kadmind5_server="/usr/local/sbin/kadmind"
kerberos5_server_flags=""
kerberos5_server_enable="YES"
kadmind5_server_enable="YES"</programlisting>

      <para>これを行うのは、
	<acronym>MIT</acronym> Kerberos のアプリケーションは、
	<filename>/usr/local</filename>
	構造の下にインストールされるためです。</para>
    </sect2>

    <sect2>
      <title><application>Kerberos</application>
	で見つかった制限を緩和する</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>制限および欠点</secondary>
      </indexterm>

      <sect3>
	<title><application>Kerberos</application> は、All or Nothing
	  アプローチです。</title>

	<para>ネットワーク上で有効なすべてのサービスは、
	  <application>Kerberos</application> 化されるか、
	  または、ネットワーク攻撃に対して安全であるべきです。
	  さもないと、ユーザのクレデンシャルが盗まれ、
	  利用されることが起きるかもしれません。
	  この例は、
	  <application>Kerberos</application>
	  化されたすべてのリモートシェルです。
	  パスワードを平文で送るような
	  <acronym>POP3</acronym> メールサーバは変換していません。</para>
      </sect3>

      <sect3>
	<title><application>Kerberos</application> は、
	  シングルユーザのワークステーションでの使用を想定しています。</title>

	<para>マルチユーザの環境では、
	  <application>Kerberos</application> は安全ではありません。
	  チケットは <filename>/tmp</filename>
	  に保管され、
	  このチケットは、すべてのユーザが読むことができるためです。
	  もし、ユーザがコンピュータを他のユーザと同時に共有していると、
	  他のユーザは、そのユーザのチケットを盗んだり、
	  コピーが出来てしまいます。</para>

	<para>この問題は、<literal>-c</literal>
	  コマンドラインオプションまたは、好ましくは
	  <envar>KRB5CCNAME</envar> 環境変数によって克服されます。
	  この問題への対応には、
	  チケットをユーザのホームディレクトリに保存し、
	  ファイルの許可属性を設定することが一般的に行われます。</para>
      </sect3>

      <sect3>
	<title>KDC は、単一障害点である</title>

	<para>設計上、<acronym>KDC</acronym> は、
	  マスターパスワードのデータベースと同様に安全である必要があります。
	  <acronym>KDC</acronym> では、
	  絶対に他のサービスを走らせるべきではありませんし、
	  物理的に安全であるべきです。
	  <application>Kerberos</application> は、
	  <acronym>KDC</acronym> 上で、ファイルとして保存されている同じ
	  <quote>マスター</quote>
	  鍵で暗号化されたすべてのパスワードを保存しているので、
	  非常に危険です。</para>

	<para>マスター鍵が漏洩しても、
	  懸念するほど悪いことにはなりません。
	  マスター鍵は、<application>Kerberos</application>
	  データベースの暗号時にのみ、
	  乱数を生成するためのシードとして使われます。
	  <acronym>KDC</acronym> へのアクセスが安全である限りにおいては、
	  マスター鍵を用いて、それほど多くのことはできません。</para>

	<para>さらに、<acronym>KDC</acronym> が利用できないと、
	  認証ができないため、ネットワークサービスを利用できなくなります。
	  この攻撃による被害は、
	  ひとつのマスタ <acronym>KDC</acronym>
	  とひとつまたはそれ以上のスレーブ、
	  そして、セカンダリもしくは <acronym>PAM</acronym>
	  を用いたフォールバック認証を注意深く実装することにより軽減できます。</para>
      </sect3>

      <sect3>
	<title><application>Kerberos</application> の欠点</title>

	<para><application>Kerberos</application> は、
	  ユーザ、ホストおよびサービスの間での認証を可能にしますが、
	  <acronym>KDC</acronym> とユーザ、
	  ホストまたはサービスとの間の認証のメカニズムは提供しません。
	  これは、トロイの木馬の &man.kinit.1; が、
	  すべてのユーザ名とパスワードを記録できることを意味しています。
	  <package>security/tripwire</package>
	  のような、ファイルシステムの完全性を確認するためのツールにより、
	  この危険性を軽減することができます。</para>
      </sect3>
    </sect2>

    <sect2>
      <title>リソースおよび他の情報源</title>

      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>External Resources</secondary>
      </indexterm>

      <itemizedlist>
	<listitem>
	  <para><link
	      xlink:href="http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html">
	      The <application>Kerberos</application> FAQ</link></para>
	</listitem>

	<listitem>
	  <para><link
	      xlink:href="http://web.mit.edu/Kerberos/www/dialogue.html">Designing
	      an Authentication System: a Dialog in Four Scenes</link></para>
	</listitem>

	<listitem>
	  <para><link
	      xlink:href="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC
	      1510, The <application>Kerberos</application> Network
	      Authentication Service (V5)</link></para>
	</listitem>

	<listitem>
	  <para><link
	      xlink:href="http://web.mit.edu/Kerberos/www/"><acronym>MIT</acronym>
	      <application>Kerberos</application> home
	      page</link></para>
	</listitem>

	<listitem>
	  <para><link xlink:href="http://www.pdc.kth.se/heimdal/">Heimdal
	      <application>Kerberos</application> home
	      page</link></para>
	</listitem>

      </itemizedlist>
    </sect2>
  </sect1>

  <sect1 xml:id="openssl">
    <info><title>OpenSSL</title>
      <authorgroup>
	<author>
	  <personname>
	    <firstname>Tom</firstname>
	    <surname>Rhodes</surname>
	  </personname>
	  <contrib>執筆: </contrib>
	</author>
      </authorgroup>
    </info>

    <indexterm>
      <primary>セキュリティ</primary>
      <secondary>OpenSSL</secondary>
    </indexterm>

    <para>&os; には、<application>OpenSSL</application>
      ツールキットが含まれています。
      <application>OpenSSL</application> は、
      通常の通信層の上位にあるトランスポート層を暗号化し、
      多くのネットワークアプリケーションおよびサービスと組み合わせて使用できます。</para>

    <para><application>OpenSSL</application> は、
      メールクライアントの暗号化された認証、
      クレジットカードでの支払いといったウェブベースの取引などで使われます。
      <package>www/apache22</package> および
      <package>mail/claws-mail</package>
      といった多くの port では、
      <application>OpenSSL</application>
      とともに構築するコンパイルに対応しています。</para>

    <note>
      <para>多くの場合、Ports Collection は、
	make の <varname>WITH_OPENSSL_BASE</varname> が明示的に
	<quote>yes</quote> に設定されていないと、
	<package>security/openssl</package> port
	の構築を試みます。</para>
    </note>

    <para>&os; に含まれている <application>OpenSSL</application>
    　のバージョンは、Secure Sockets Layer v2/v3 (SSLv2/SSLv3) および
      Transport Layer Security v1 (TLSv1)
      ネットワークセキュリティプロトコルに対応しており、
      多目的な暗号化ライブラリとして使うことができます。</para>

    <note>
      <para><application>OpenSSL</application> は、
	<acronym>IDEA</acronym> アルゴリズムに対応していますが、
	合衆国の特許により、デフォルトでは無効になっています。
	もし使用したいのであれば、ライセンス条項を必ず確認し、
	ライセンス条項に合致するのであれば、
	<filename>/etc/make.conf</filename> において
	<varname>MAKE_IDEA</varname> 変数を設定してください。</para>
    </note>

    <para>最も一般的な <application>OpenSSL</application>
      の利用方法のひとつは、
      ソフトウェアアプリケーションが使えるように証明書を提供することです。
      これらの証明書により、会社または個人の公開鍵が、
      改ざんやなりすましが行われていないことを確認できます。
      もし問題となっている証明書が、<quote>認証局</quote>
      (<acronym>CA</acronym>) により検証されなければ、
      警告が表示されます。
      <acronym>CA</acronym>
      は、<link xlink:href="http://www.verisign.com">VeriSign</link>
      のような会社で、個人または会社の公開鍵の検証を行えるように、
      証明書に署名を行います。
      証明書を作成するには費用がかかり、
      証明書の使用は必要条件ではありませんが、
      証明書を使うことで、
      ユーザを安心させることができます。</para>

    <sect2>
      <title>証明書の作成</title>

      <indexterm>
	<primary>OpenSSL</primary>
	<secondary>証明書の作成</secondary>
      </indexterm>

      <para>以下のコマンドにより、証明書を作成できます。</para>

      <screen>&prompt.root; <userinput>openssl req -new -nodes -out req.pem -keyout cert.pem</userinput>
Generating a 1024 bit RSA private key
................++++++
.......................................++++++
writing new private key to 'cert.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:<userinput>US</userinput>
State or Province Name (full name) [Some-State]:<userinput>PA</userinput>
Locality Name (eg, city) []:<userinput>Pittsburgh</userinput>
Organization Name (eg, company) [Internet Widgits Pty Ltd]:<userinput>My Company</userinput>
Organizational Unit Name (eg, section) []:<userinput>Systems Administrator</userinput>
Common Name (eg, YOUR name) []:<userinput>localhost.example.org</userinput>
Email Address []:<userinput>trhodes@FreeBSD.org</userinput>

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<userinput>SOME PASSWORD</userinput>
An optional company name []:<userinput>Another Name</userinput></screen>

      <para><quote>Common Name</quote> プロンプト直後に表示されているのは、
	ドメイン名です。
	このプロンプトでは、検証するサーバ名の入力が必要となります。
	ドメイン名以外を入力すると、役に立たない証明書が作成されます。
	他のオプションとして、有効期限を指定したり、
	別の暗号化アルゴリズムを選択することができます。
	オプションの完全なリストは、
	&man.openssl.1; で説明されています。</para>

      <para>このコマンドを実行したディレクトリには、
	2 つのファイルが作成されているはずです。
	1 つは、証明書要求 <filename>req.pem</filename> です。
	このファイルを <acronym>CA</acronym> に送ると、
	<acronym>CA</acronym> は含まれている内容を検証し、
	検証に成功すると、証明書要求に署名を行い、
	作成された証明書を送り返します。
	もうひとつ、<filename>cert.pem</filename>
	と呼ばれるファイルが生成されます。
	これは証明書の秘密鍵であり、
	どのようなことがあっても保護しなくてはなりません。
	もし、他の人の手に渡ると、手に入れた人は、
	ユーザまたはサーバになりすますことができてしまいます。</para>

      <para><acronym>CA</acronym> の署名が必要ない場合には、
	自己署名証明書を作成できます。
	最初に <acronym>RSA</acronym> の鍵を生成してください。</para>

      <screen>&prompt.root; <userinput>openssl dsaparam -rand -genkey -out myRSA.key 1024</userinput></screen>

      <para>次に、<acronym>CA</acronym> 鍵を生成してください。</para>

      <screen>&prompt.root; <userinput>openssl gendsa -des3 -out myca.key myRSA.key</userinput></screen>

      <para>この鍵を使って証明書を作成してください。</para>

      <screen>&prompt.root; <userinput>openssl req -new -x509 -days 365 -key myca.key -out new.crt</userinput></screen>

      <para>新しく 2 つのファイルがこのディレクトリに作成されます。
	プライベート鍵 <filename>myca.key</filename> および
	証明書 <filename>new.crt</filename> です。
	これらのファイルを、好ましくは
	<filename>/etc</filename> 以下で、
	<systemitem class="username">root</systemitem>
	のみが読むことのできるディレクトリに置く必要があります。
	許可属性は 0700 が適切です。
	許可属性は &man.chmod.1; を使って設定できます。</para>
    </sect2>

    <sect2>
      <title>証明書の使用</title>

      <para>証明書の一つの利用方法は、<application>Sendmail</application>
	<acronym>MTA</acronym> への接続を暗号化することです。
	これにより、
	ローカルの <acronym>MTA</acronym> 経由でメールを送信するユーザが、
	テキスト認証を使用しなくてもすむようになります。</para>

      <note>
	<para>いくつかの <acronym>MUA</acronym> は、
	  ユーザが証明書をローカルにインストールしていないと、
	  エラーを出力します。
	  証明書のインストールに関する詳細な情報については、
	  ソフトウェアに付随の文書を参照してください。</para>
      </note>

      <para><application>Sendmail</application> 
	を設定するには、以下の行をローカルの
	<filename>.mc</filename> ファイルに含めてください。</para>

      <programlisting>dnl SSL Options
define(`confCACERT_PATH',`/etc/certs')dnl
define(`confCACERT',`/etc/certs/new.crt')dnl
define(`confSERVER_CERT',`/etc/certs/new.crt')dnl
define(`confSERVER_KEY',`/etc/certs/myca.key')dnl
define(`confTLS_SRV_OPTIONS', `V')dnl</programlisting>

      <para>この例では、
	ローカルで証明書および鍵ファイルは、ローカルの
	<filename>/etc/certs/</filename> に置かれています。
	ファイルの編集を保存し終わったら、
	<filename>/etc/mail</filename> において
	<command>make install</command>
	と入力することで、ローカルの <filename>.cf</filename>
	ファイルを再構築する必要があります。
	その後、<command>make restart</command>
	と入力して、<application>Sendmail</application>
	デーモンを再起動してください。</para>

      <para>すべてがうまくいっていれば、
	<filename>/var/log/maillog</filename>
	にはエラーメッセージは出力されず、
	<application>Sendmail</application>
	がプロセスの一覧に表示されます。</para>

      <para>以下は簡単な試験の例で、&man.telnet.1; を使って、
	メールサーバに接続しています。</para>

      <screen>&prompt.root; <userinput>telnet example.com 25</userinput>
Trying 192.0.34.166...
Connected to  <systemitem class="fqdomainname">example.com</systemitem>
Escape character is '^]'.
220 <systemitem class="fqdomainname">example.com</systemitem> ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT)
<userinput>ehlo example.com</userinput>
250-example.com Hello example.com [192.0.34.166], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
<userinput>quit</userinput>
221 2.0.0 <systemitem class="fqdomainname">example.com</systemitem> closing connection
Connection closed by foreign host.</screen>

      <para>出力に <quote>STARTTLS</quote> 行が表示されれば、
	すべてが適切に機能しています。</para>
    </sect2>
  </sect1>

  <sect1 xml:id="ipsec">
    <info><title><acronym>VPN</acronym> over IPsec</title>
      <authorgroup>
	<author>
	  <personname>
	    <firstname>Nik</firstname>
	    <surname>Clayton</surname>
	  </personname>
	  <affiliation>
	    <address><email>nik@FreeBSD.org</email></address>
	  </affiliation>
	  <contrib>執筆: </contrib>
	</author>
      </authorgroup>
    </info>

    <indexterm>
      <primary>IPsec</primary>
    </indexterm>

    <sect2>
      <info>
	<title>IPsec を理解する</title>
	<authorgroup>
	  <author>
	    <personname>
	      <firstname>Hiten M.</firstname>
	      <surname>Pandya</surname>
	    </personname>
	    <affiliation>
	      <address><email>hmp@FreeBSD.org</email></address>
	    </affiliation>
	    <contrib>執筆: </contrib>
	  </author>
	</authorgroup>
      </info>

      <para>この節では、IPsec を設定する過程を説明します。
	IPsec を設定するためには、
	カスタムカーネルの構築方法をよく知っている必要があります
	(<xref linkend="kernelconfig"/> をご覧ください)。</para>

      <para><emphasis>IPsec</emphasis> は、インターネットプロトコル
	(<acronym>IP</acronym>) レイヤのトップにあるプロトコルです。
	二つもしくはそれ以上のホスト間で安全に通信することを可能にします。
	&os; の IPsec <quote>ネットワークスタック</quote> は、
	IPv4 および IPv6 の両方に対応している
	<link xlink:href="http://www.kame.net/">KAME</link>
	実装をベースとしています。</para>

      <indexterm>
	<primary>IPsec</primary>
	<secondary>ESP</secondary>
      </indexterm>

      <indexterm>
	<primary>IPsec</primary>
	<secondary>AH</secondary>
      </indexterm>

      <para>IPsec は二つのサブプロトコルから構成されます。</para>

      <itemizedlist>
	<listitem>
	  <para><emphasis>Encapsulated Security Payload
	      (<acronym>ESP</acronym>)</emphasis>:
	    このプロトコルは、Blowfish, 3DES
	    といった対称暗号アルゴリズムを使ってデータを暗号化することで、
	    サードパーティのインタフェースから
	    IP パケットデータを保護します。</para>
	</listitem>

	<listitem>
	  <para><emphasis>Authentication Header
	      <acronym>AH</acronym>(AH)</emphasis>:
	    このプロトコルは、暗号チェックサムを計算し、IP
	    パケットのヘッドフィールドを安全なハッシュ関数でハッシュ化することで、
	    IP パケットヘッダをサードパーティのインタフェースやなりすましから守ります。
	    ハッシュを含む追加のヘッダが追加され、
	    パケット情報の検証が可能になります。</para>
	</listitem>
      </itemizedlist>

      <para><acronym>ESP</acronym> および <acronym>AH</acronym>
	は、使用する環境に合わせて、
	一緒に使うことも別々に使うこともできます。</para>

      <indexterm>
	<primary>VPN</primary>
      </indexterm>

      <indexterm>
	<primary>virtual private network</primary>
	<see>VPN</see>
      </indexterm>

      <para>IPsec は、直接二つのホスト間のトラフィックを暗号化する
	<emphasis>Transport Mode</emphasis>、もしくは
	<quote>virtual tunnels</quote> を構築する
	<emphasis>Tunnel Mode</emphasis> のどちらでも用いることができます。
	後者のモードはより一般的には、
	<emphasis>Virtual Private Network (<acronym>VPN</acronym>)</emphasis>
	として知られています。
	&os; での IPsec サブシステムに関するより詳細な情報については、
	&man.ipsec.4; を参照してください。</para>

      <para>カーネルに IPsec のサポートを追加するには、
	カスタムカーネルコンフィグレーションファイルに以下のオプションを追加してください。</para>

      <indexterm>
	<primary>カーネルオプション</primary>
	<secondary>IPSEC</secondary>
      </indexterm>

      <screen>options   IPSEC        #IP security
device    crypto</screen>

      <indexterm>
	<primary>カーネルオプション</primary>
	<secondary>IPSEC_DEBUG</secondary>
      </indexterm>

      <para>IPsec のデバッグサポートが必要であれば、
	以下のカーネルオプションを追加してください。</para>

      <screen>options   IPSEC_DEBUG  #debug for IP security</screen>
    </sect2>

    <sect2>
      <title>家庭と会社間の <acronym>VPN</acronym></title>

      <indexterm>
	<primary>VPN</primary>
	<secondary>creating</secondary>
      </indexterm>

      <para><acronym>VPN</acronym> の構成についての標準はありません。
	<acronym>VPN</acronym> は、数多くの技術と共に実装することが可能です。
	その各技術には、それ自身の長所と短所があります。
	この節では、以下のシナリオに対して <acronym>VPN</acronym>
	を実装する戦略について説明します。</para>

      <itemizedlist>
	<listitem>
	  <para>少なくとも 2 つのサイトがあり、
	    それぞれのサイトは内部で IP を使っています。</para>
	</listitem>

	<listitem>
	  <para>2 つのサイトは、&os; で運用されているゲートウェイを通して、
	    インターネットに接続しています。</para>
	</listitem>

	<listitem>
	  <para>それぞれのネットワークのゲートウェイは、
	    少なくとも一つのパブリック IP アドレスを持っています。</para>
	</listitem>

	<listitem>
	  <para>2 つのネットワークの内部アドレスは、
	    パブリックでもプライベート IP アドレスでも構いません。
	    しかしながら、アドレス空間は衝突してはいけません。
	    たとえば、両方のネットワークが
	    <systemitem class="ipaddress">192.168.1.x</systemitem>
	    を使ってはいけません。</para>
	</listitem>
      </itemizedlist>

      <sect3>
	<info>
	  <title>&os; 上で IPsec を設定する。</title>
	  <authorgroup>
	    <author>
	      <personname>
		<firstname>Tom</firstname>
		<surname>Rhodes</surname>
	      </personname>
	      <affiliation>
		<address><email>trhodes@FreeBSD.org</email></address>
	      </affiliation>
	      <contrib>寄稿: </contrib>
	    </author>
	  </authorgroup>
	</info>

	<para>最初に Ports Collection から
	  <package>security/ipsec-tools</package>
	  をインストールしてください。
	  このソフトウェアは、
	  設定をサポートする数多くのアプリケーションを提供します。</para>

	<para>次に、パケットをトンネリングし、
	  両方のネットワークが適切に通信するように、
	  2 つの &man.gif.4; 疑似デバイスを作成します。
	  <systemitem class="username">root</systemitem>
	  権限で以下のコマンドを実行してください。
	  ただし、実行する際には、以下のコマンドの中の
	  <replaceable>internal</replaceable> および
	  <replaceable>external</replaceable> を、
	  2 つのゲートウェイの内部および外部インタフェースの実際の
	  IP アドレスに置き換えてください。</para>

	<screen>&prompt.root; <userinput>ifconfig gif0 create</userinput></screen>

	<screen>&prompt.root; <userinput>ifconfig gif0 internal1 internal2</userinput></screen>

	<screen>&prompt.root; <userinput>ifconfig gif0 tunnel external1 external2</userinput></screen>

	<para>この例では、会社の <acronym>LAN</acronym> の外部
	  <acronym>IP</acronym> アドレスを
	  <systemitem class="ipaddress">172.16.5.4</systemitem>、
	  内部 <acronym>IP</acronym> アドレスを
	  <systemitem class="ipaddress">10.246.38.1</systemitem>
	  とします。また、家庭
	  <acronym>LAN</acronym> の外部 <acronym>IP</acronym> アドレスを
	  <systemitem class="ipaddress">192.168.1.12</systemitem>、
	  内部のプライベート <acronym>IP</acronym> アドレスを
	  <systemitem class="ipaddress">10.0.0.5</systemitem>
	  とします。</para>

	<para>この説明で分かりにくい場合は、以下の
	  &man.ifconfig.8; コマンドの出力例をご覧ください。</para>

	<programlisting>Gateway 1:

gif0: flags=8051 mtu 1280
tunnel inet 172.16.5.4 --&gt; 192.168.1.12
inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6
inet 10.246.38.1 --&gt; 10.0.0.5 netmask 0xffffff00

Gateway 2:

gif0: flags=8051 mtu 1280
tunnel inet 192.168.1.12 --&gt; 172.16.5.4
inet 10.0.0.5 --&gt; 10.246.38.1 netmask 0xffffff00
inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4</programlisting>

	<para>設定が完了したら、両方の内部 <acronym>IP</acronym>
	  アドレスは、&man.ping.8;
	  で到達できるようになっているはずです。</para>

	<programlisting>priv-net# ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5): 56 data bytes
64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms
64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms
--- 10.0.0.5 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms

corp-net# ping 10.246.38.1
PING 10.246.38.1 (10.246.38.1): 56 data bytes
64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms
64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms
64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms
64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms
64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms
--- 10.246.38.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms</programlisting>

	<para>予想通り、プライベートアドレスを使って、
	  両方のネットワークから <acronym>ICMP</acronym>
	  パケットを送受信できます。
	  次に、どちらのネットワークからもメッセージを送信できるように、
	  パケットのルーティング情報を両方のゲートウェイに設定する必要があります。
	  これは以下のコマンドで設定できます。</para>

	<screen>&prompt.root; <userinput>corp-net# route add 10.0.0.0 10.0.0.5 255.255.255.0</userinput></screen>

	<screen>&prompt.root; <userinput>corp-net# route add net 10.0.0.0: gateway 10.0.0.5</userinput></screen>

	<screen>&prompt.root; <userinput>priv-net# route add 10.246.38.0 10.246.38.1 255.255.255.0</userinput></screen>

	<screen>&prompt.root; <userinput>priv-net# route add host 10.246.38.0: gateway 10.246.38.1</userinput></screen>

	<para>これで、ネットワーク内のコンピュータは、
	  ゲートウェイおよびゲートウェイの奥のコンピュータから到達可能となっています。
	  もう一度 &man.ping.8; で確認してください。</para>

	<programlisting>corp-net# ping 10.0.0.8
PING 10.0.0.8 (10.0.0.8): 56 data bytes
64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms
64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms
64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms
64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms
64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms
--- 10.0.0.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms

priv-net# ping 10.246.38.107
PING 10.246.38.1 (10.246.38.107): 56 data bytes
64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms
64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms
64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms
64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms
64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms
--- 10.246.38.107 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms</programlisting>

	<para>トンネリングの設定は以上のように簡単ですが、
	  リンクを安全にするには、もう少し掘り下げた設定が必要となります。
	  以下の設定では、事前共有 (<acronym>PSK</acronym>)
	  <acronym>RSA</acronym> 鍵を使います。
	  <acronym>IP</acronym> アドレスを除けば、両方のゲートウェイの
	  <filename>/usr/local/etc/racoon/racoon.conf</filename>
	  は同じで、以下のようになります。</para>

	<programlisting>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

padding	# options are not to be changed
{
        maximum_length  20;
        randomize       off;
        strict_check    off;
        exclusive_tail  off;
}

timer	# timing options. change as needed
{
        counter         5;
        interval        20 sec;
        persend         1;
#       natt_keepalive  15 sec;
        phase1          30 sec;
        phase2          15 sec;
}

listen	# address [port] that racoon will listen on
{
        isakmp          172.16.5.4 [500];
        isakmp_natt     172.16.5.4 [4500];
}

remote  192.168.1.12 [500]
{
        exchange_mode   main,aggressive;
        doi             ipsec_doi;
        situation       identity_only;
        my_identifier   address 172.16.5.4;
        peers_identifier        address 192.168.1.12;
        lifetime        time 8 hour;
        passive         off;
        proposal_check  obey;
#       nat_traversal   off;
        generate_policy off;

                        proposal {
                                encryption_algorithm    blowfish;
                                hash_algorithm          md5;
                                authentication_method   pre_shared_key;
                                lifetime time           30 sec;
                                dh_group                1;
                        }
}

sainfo  (address 10.246.38.0/24 any address 10.0.0.0/24 any)	# address $network/$netmask $type address $network/$netmask $type ( $type being any or esp)
{								# $network must be the two internal networks you are joining.
        pfs_group       1;
        lifetime        time    36000 sec;
        encryption_algorithm    blowfish,3des,des;
        authentication_algorithm        hmac_md5,hmac_sha1;
        compression_algorithm   deflate;
}</programlisting>

	<para>利用可能なオプションの説明については、
	  <application>racoon</application>
	  のマニュアルページを参照してください。</para>

	<para>&os; および <application>racoon</application>
	  がホスト間のネットワークトラフィックを暗号化、
	  復号化できるようにするには、
	  Security Policy Database (<acronym>SPD</acronym>)
	  の設定が必要です。</para>

	<para>これは、会社のゲートウェイ上で、
	  以下のようなシェルスクリプトで設定できます。
	  このファイルをシステムの初期化中に使われるようにするには、
	  <filename>/usr/local/etc/racoon/setkey.conf</filename>
	  に保存する必要があります。</para>

	<programlisting>flush;
spdflush;
# To the home network
spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use;
spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use;</programlisting>

	<para>設定ファイルを適切に置くと、以下のコマンドにより、
	  両方のゲートウェイ上で <application>racoon</application>
	  を起動できます。</para>

	<screen>&prompt.root; <userinput>/usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log</userinput></screen>

	<para>出力は以下のようになるでしょう。</para>

	<programlisting>corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf
Foreground mode.
2006-01-30 01:35:47: INFO: begin Identity Protection mode.
2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon
2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon
n2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a
2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]-&gt;172.16.5.4[0] spi=28496098(0x1b2d0e2)
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]-&gt;192.168.1.12[0] spi=47784998(0x2d92426)
2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]-&gt;172.16.5.4[0] spi=124397467(0x76a279b)
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]-&gt;192.168.1.12[0] spi=175852902(0xa7b4d66)</programlisting>

	<para>トンネリングが適切に行われているかどうかを確認するため、
	  別のコンソール上で &man.tcpdump.1; を使い、
	  以下のようなコマンドでネットワークの通信を確認してください。
	  ただし、以下の例の <literal>em0</literal> の部分は、
	  必要に応じて使用しているネットワークインタフェースに置き換えてください。</para>

	<screen>&prompt.root; <userinput>tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12</userinput></screen>

	<para>以下のようなデータがコンソールに表示されます。
	  もし、表示されない場合は、設定に何か問題があるので、
	  表示されるデータを使ってデバッグする必要があります。</para>

	<programlisting>01:47:32.021683 IP corporatenetwork.com &gt; 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa)
01:47:33.022442 IP corporatenetwork.com &gt; 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb)
01:47:34.024218 IP corporatenetwork.com &gt; 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc)</programlisting>

	<para>これで 2 つのネットワークは、
	  1 つのネットワークのように利用できます。
	  多くの場合、
	  両方のネットワークはファイアウォールにより保護されています。
	  両方を流れる通信を許可するには、
	  パケットが両方を行き来できるようにルールを追加する必要があります。
	  &man.ipfw.8; を使ったファイアウォールの場合は、
	  ファイアウォールの設定ファイルに、以下の行を追加してください。</para>

	<programlisting>ipfw add 00201 allow log esp from any to any
ipfw add 00202 allow log ah from any to any
ipfw add 00203 allow log ipencap from any to any
ipfw add 00204 allow log udp from any 500 to any</programlisting>

	<note>
	  <para>ルール番号は、
	  現在のホストの設定によっては変更する必要があるでしょう。</para>
	</note>

	<para>&man.pf.4; または &man.ipf.8; を使用しているシステムでは、
	  以下のルールで上手くいくでしょう。</para>

	<programlisting>pass in quick proto esp from any to any
pass in quick proto ah from any to any
pass in quick proto ipencap from any to any
pass in quick proto udp from any port = 500 to any port = 500
pass in quick on gif0 from any to any
pass out quick proto esp from any to any
pass out quick proto ah from any to any
pass out quick proto ipencap from any to any
pass out quick proto udp from any port = 500 to any port = 500
pass out quick on gif0 from any to any</programlisting>

	<para>最後に、システムの初期化中に <acronym>VPN</acronym>
	  が起動するように、以下の行を
	  <filename>/etc/rc.conf</filename> に追加してください。</para>

	<programlisting>ipsec_enable="YES"
ipsec_program="/usr/local/sbin/setkey"
ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot
racoon_enable="yes"</programlisting>
      </sect3>
    </sect2>
  </sect1>

  <sect1 xml:id="openssh">
    <info>
      <title>OpenSSH</title>
      <authorgroup>
	<author>
	  <personname>
	    <firstname>Chern</firstname>
	    <surname>Lee</surname>
	  </personname>
	  <contrib>寄稿: </contrib>
	</author>
	<!-- 21 April 2001 -->
      </authorgroup>
    </info>

    <indexterm><primary>OpenSSH</primary></indexterm>

    <indexterm>
      <primary>セキュリティ</primary>
      <secondary>OpenSSH</secondary>
    </indexterm>

    <para><application>OpenSSH</application>
      はリモートマシンへのセキュアなアクセスに使われるネットワーク接続ツールの集合です。
      また、TCP/IP 接続を
      <application>OpenSSH</application>
      接続経由でセキュアにトンネル/フォワードすることもできます。
      <application>OpenSSH</application> はすべてのトラフィックを暗号化し、
      盗聴や接続の乗っ取り等のネットワークレベルの攻撃を事実上無効化します。</para>

    <para><application>OpenSSH</application>
      は OpenBSD プロジェクトによって維持管理されており、
      &os; にはデフォルトでインストールされています。
      <application>OpenSSH</application> は、
      <acronym>SSH</acronym> バージョン 1 と 2
      の両方に互換性があります。</para>

    <sect2>
      <title><application>OpenSSH</application> を使うことの利点</title>

      <para>データがネットワークを平文で流れてしまうと、
	ネットワークをクライアントとサーバの間のどこかで盗聴することで、
	あなたのユーザ/パスワード情報やセション中を流れるデータを盗むことが可能です。
	<application>OpenSSH</application>
	はこれらを予防する為にさまざまな認証と暗号化の方法を提供します。</para>
    </sect2>

    <sect2>
      <title>SSH サーバを有効にする</title>

      <indexterm>
	<primary>OpenSSH</primary>
	<secondary>有効化</secondary>
      </indexterm>

      <para>&man.sshd.8; が有効になっているかどうかを確認するには、
	<filename>/etc/rc.conf</filename>
	の以下の行を確認してください。</para>

      <programlisting>sshd_enable="YES"</programlisting>

      <para>この設定により、次のシステムの初期化時に
	<application>OpenSSH</application> のデーモンプログラムである
	&man.sshd.8; が起動します。
	もしくは &man.service.8; を使って、すぐに
	<application>OpenSSH</application> を起動することもできます。</para>

      <screen>&prompt.root; <userinput>service sshd start</userinput></screen>
    </sect2>

    <sect2>
      <title>SSH クライアント</title>

      <indexterm>
	<primary>OpenSSH</primary>
	<secondary>クライアント</secondary>
      </indexterm>

      <para>&man.ssh.1; を使って、
	&man.sshd.8; が動いているシステムに接続するには、
	ログインをするユーザ名とホストを指定してください。</para>

      <screen>&prompt.root; <userinput>ssh user@example.com</userinput>
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? <userinput>yes</userinput>
Host 'example.com' added to the list of known hosts.
user@example.com's password: <userinput>*******</userinput></screen>

      <para><acronym>SSH</acronym> はクライアントが接続した時、
	サーバの信頼性の検証のために鍵指紋システム
	(key fingerprint system) を利用します。
	初めての接続の際に、ユーザは <literal>yes</literal>
	と入力することを要求されます。
	これ以降の login では保存されていた鍵指紋を照合することで検証が行われ、
	&man.ssh.1; クライアントは保存されていた鍵指紋が login
	しようとした際に送られてきたものと異なっていた場合には警告を表示します。
	指紋は <filename>~/.ssh/known_hosts</filename>
	に保存されます。</para>

      <para>デフォルトでは、&man.sshd.8;
	の最近の版では <acronym>SSH</acronym> v2
	の接続のみを受け付けるように設定されています。
	クライアントは可能であればバージョン 2 を用い、
	バージョン 1 にフォールバックします。
	クライアントは、プロトコル v1 と v2
	についてそれぞれ、引数 <option>-1</option> または <option>-2</option>
	を渡すことで、利用するプロトコルを指定できます。
	クライアントにおけるバージョン 1 への互換性は、
	古いバージョンへの上位互換のために維持されています。</para>
    </sect2>

    <sect2>
      <title>Secure copy</title>

      <indexterm>
	<primary>OpenSSH</primary>
	<secondary>secure copy</secondary>
      </indexterm>
      <indexterm>
	<primary>&man.scp.1;</primary>
      </indexterm>

      <para>ローカルのファイルをリモートマシンへ、
	あるいはリモートマシンのファイルをローカルに安全な方法でコピーするには、
	&man.scp.1; を使用してください。</para>

      <screen>&prompt.root; <userinput> scp user@example.com:/COPYRIGHT COPYRIGHT</userinput>
user@example.com's password: <userinput>*******</userinput>
COPYRIGHT            100% |*****************************|  4735
00:00
&prompt.root;</screen>

      <para>前回の例でこのホストの指紋がすでに保存されていれば
	この &man.scp.1; を使う時に検証が行なわれます。</para>

      <para>&man.scp.1; に渡される引数は、&man.cp.1;
	のものと似ており、コピーするファイル (1 つまたは複数) が
	1 つめの引数になり、コピー先が 2 つめの引数になります。
	ファイルはネットワーク越しに <acronym>SSH</acronym>
	接続を通して送られるので、
	引数に指定するファイルに
	<option>user@host:&lt;path_to_remote_file&gt;</option>
	という形式をとるものがあります。</para>
    </sect2>

    <sect2>
      <title>設定</title>

      <indexterm>
	<primary>OpenSSH</primary>
	<secondary>設定</secondary>
      </indexterm>

      <para>システム全体の設定ファイルは、<application>OpenSSH</application>
	デーモン、クライアントの両方とも
	<filename>/etc/ssh</filename>	にあります。</para>

      <para><filename>ssh_config</filename> はクライアントの動作設定、
	<filename>sshd_config</filename>
	はデーモンの動作設定を行ないます。
	それぞれのファイル毎にマニュアルページが用意されており、
	利用可能な設定オプションについて説明されています。</para>
    </sect2>

    <sect2 xml:id="security-ssh-keygen">
      <title>&man.ssh-keygen.1;</title>

      <para>パスワードの代わりに &man.ssh-keygen.1;
	を使ってユーザの認証用の <acronym>DSA</acronym> または
	<acronym>RSA</acronym> 暗号鍵を作ることができます。</para>

      <screen>&prompt.user; <userinput>ssh-keygen -t dsa</userinput>
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com</screen>

      <para>&man.ssh-keygen.1; は認証に使う為の公開鍵と秘密鍵のペアを作ります。
	<acronym>DSA</acronym> または <acronym>RSA</acronym> 鍵に応じて、
	秘密鍵は <filename>~/.ssh/id_dsa</filename> または
	<filename>~/.ssh/id_rsa</filename> に保存され、
	公開鍵は <filename>~/.ssh/id_dsa.pub</filename> または
	<filename>~/.ssh/id_rsa.pub</filename> にそれぞれ保存されます。
	公開鍵はセットアップのために、
	<acronym>DSA</acronym> または <acronym>RSA</acronym>
	のどちらを使う場合にも、
	リモートマシンの <filename>~/.ssh/authorized_keys</filename>
	に含まれてなければなりません。</para>

      <para>この設定により、パスワードに代わり、
	<acronym>SSH</acronym>
	鍵を使ってリモートマシンに接続できるようになります。</para>

      <warning>
	<para>多くのユーザは、鍵が設計上安全と信じ、
	  パスフレーズなしに鍵を利用しています。
	  このような使用方法は <emphasis>危険</emphasis> です。
	  管理者が鍵にパスフレーズが設定されているかを確認する方法は、
	  手動で鍵を調べる方法です。
	  秘密鍵のファイルに <literal>ENCRYPTED</literal>
	  という単語が含まれている場合には、
	  鍵の所有者は、パスフレーズを使用しています。
	  弱いパスフレーズが使われている間、
	  少なくともシステムが危険にさらされているときには、
	  他のサイトへのアクセスには、
	  あるレベルでのパスワード類推が必要となります。
	  さらに、公開鍵ファイルに <literal>from</literal> を含めることで、
	  エンドユーザをより安全にできます。
	  たとえば、
	  <literal>ssh-rsa</literal> または <literal>rsa-dsa</literal> の前に、
	  <literal>from="192.168.10.5</literal> を加えることで、
	  この <acronym>IP</acronym>
	  を持つホストからのユーザのみがアクセスできるようになります。</para>
      </warning>
	  
      <para>&man.ssh-keygen.1; でパスフレーズを使っている場合は、
	秘密鍵を使うためにユーザは毎回パスフレーズを入力する必要があります。
	長いパスフレーズを毎回入力しなくてはならない負担は、
	&man.ssh-agent.1; を使うと軽減できます。
	これについては、
	<xref linkend="security-ssh-agent"/> で説明されています。</para>

      <warning>
	<para><application>OpenSSH</application> のバージョンによって、
	  オプションやファイルに違いが出てくることがあります。
	  &man.ssh-keygen.1; を参照して、
	  問題が起こることを避けてください。</para>
      </warning>
    </sect2>

    <sect2 xml:id="security-ssh-agent">
      <title>SSH Agent による鍵のキャッシュ</title>

      <para>パスフレーズを毎回入力することなしに、
	<application>SSH</application>
	鍵を利用できるようにメモリに読み込むには、
	&man.ssh-agent.1; および &man.ssh-add.1; を使用してください。</para>

      <para>&man.ssh-agent.1; は、
	読み込まれた秘密鍵による認証を取り扱います。
	&man.ssh-agent.1;
	は他のアプリケーションの起動に用いられる必要があります。
	基本的なレベルではシェル、
	またはウィンドウマネージャを起動します。</para>

      <para>シェル上で &man.ssh-agent.1; を使うには、
	引数としてシェルを起動してください。
	次に、&man.ssh-add.1; を実行し、
	秘密鍵のパスフレーズを入力することにより、
	鍵を追加してください。
	一度この過程を終えてしまえば、ユーザは、
	対応する公開鍵が置かれているホストに &man.ssh.1;
	でログインできるようになります。
	以下はその例です。</para>

      <screen>&prompt.user; ssh-agent <replaceable>csh</replaceable>
&prompt.user; ssh-add
Enter passphrase for /home/user/.ssh/id_dsa:
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
&prompt.user;</screen>

      <para><application>&xorg;</application> 上で
	&man.ssh-agent.1; を使うには、
	&man.ssh-agent.1; への呼び出しが
	<filename>~/.xinitrc</filename> に置かれている必要があります。
	これにより、<application>&xorg;</application>
	上で起動されるすべてのプログラムにおいて、
	&man.ssh-agent.1; サービスが提供されるようになります。
	<filename>~/.xinitrc</filename>
	の例は以下となります。</para>

      <programlisting>exec ssh-agent <replaceable>startxfce4</replaceable></programlisting>

      <para>これで、<application>&xorg;</application>
	を開始するときにはいつでも
	&man.ssh-agent.1; が起動され、
	このプログラムから <application>XFCE</application> が起動されます。
	<application>&xorg;</application> を再起動した後は有効になりますので、
	&man.ssh-add.1; を実行して、
	すべての <acronym>SSH</acronym> 鍵を読み込ませてください。</para>
    </sect2>

    <sect2 xml:id="security-ssh-tunneling">
      <title><acronym>SSH</acronym> トンネリング</title>

      <indexterm>
	<primary>OpenSSH</primary>
	<secondary>トンネリング</secondary>
      </indexterm>

      <para><application>OpenSSH</application>
	 は暗号化されたセッションの中に他のプロトコルをカプセル化するトンネルを作ることができます。</para>

      <para>以下のコマンドは &man.ssh.1; で &man.telnet.1;
	用のトンネルを作成します。</para>

      <screen>&prompt.user; <userinput>ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com</userinput>
&prompt.user;</screen>

      <para>この例では、以下のオプションを使っています。</para>

      <variablelist>
	<varlistentry>
	  <term><option>-2</option></term>

	  <listitem>
	    <para>サーバへの接続に &man.ssh.1; バージョン 2
	      を使うことを指示します。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>-N</option></term>

	  <listitem>
	    <para>はトンネルだけでコマンドはないことを示します。
	      省略されると &man.ssh.1; は通常のセッションを開始します。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>-f</option></term>

	  <listitem>
	    <para>&man.ssh.1;
	      にバックグラウンド実行を強制します。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>-L</option></term>

	  <listitem>
	    <para>ローカルトンネルを
	      <replaceable>localport:remotehost:remoteport</replaceable>
	      という形式で指定します。</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>user@foo.example.com</option></term>

	  <listitem>
	    <para>指定したリモート <acronym>SSH</acronym>
	      サーバへログインに用いるログイン名。</para>
	  </listitem>
	</varlistentry>
      </variablelist>

      <para><acronym>SSH</acronym> のトンネルは
	<systemitem>localhost</systemitem> の指定されたポートに listen
	するソケットを作ることで実現されています。
	<acronym>SSH</acronym>
	はローカルのホスト/ポートで受けた接続すべてを
	<acronym>SSH</acronym>
	接続経由で指定されたリモートホストのポートへ転送します。</para>

      <para>この例では、<systemitem>localhost</systemitem> のポート
	<replaceable>5023</replaceable>	がリモートマシンの
	<systemitem>localhost</systemitem> のポート
	<replaceable>23</replaceable> に転送されるようになっています。
 	<replaceable>23</replaceable> は
	&man.telnet.1; で用いられるので、これは <acronym>SSH</acronym>
	トンネルを通る暗号化された man.telnet.1;
	セッションを作ります。</para>

      <para>このようにして SMTP や POP3 および FTP といったセキュアではない
	TCP プロトコルをカプセル化できます。</para>

      <example>
	<title>&man.ssh.1; を用いた SMTP 用の安全なトンネルの作成</title>

	<screen>&prompt.user; <userinput>ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com</userinput>
user@mailserver.example.com's password: <userinput>*****</userinput>
&prompt.user; <userinput>telnet localhost 5025</userinput>
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTP</screen>

	<para>&man.ssh-keygen.1;
	  と別のユーザアカウントを組み合わせて使うことでより透過的な
	  <acronym>SSH</acronym> のトンネル環境を作ることができます。
	  パスワードを入力するところで暗号鍵を使い、
	  トンネルは別のユーザ権限で実行することが可能です。</para>
      </example>

      <sect3>
	<title>実用的な <acronym>SSH</acronym> トンネルの例</title>

	<sect4>
	  <title>POP3 サーバへの安全な接続</title>

	  <para>ここでの例は、外部からの接続を受ける
	    <acronym>SSH</acronym> サーバがあるとします。
	    同じネットワークには、POP3
	    サーバが動いているメールサーバがあるとします。
	    電子メールを安全なやり方で見るようにするには、
	    <acronym>SSH</acronym> サーバへの <acronym>SSH</acronym>
	    接続を行い、
	    メールサーバへのトンネルを作成することです。</para>

	  <screen>&prompt.user; <userinput>ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com</userinput>
user@ssh-server.example.com's password: <userinput>******</userinput></screen>

	  <para>トンネルが作成されて動作したら、
	    メールクライアントに対し <systemitem>localhost</systemitem>
	    のポート 2110 に POP3 リクエストを送るように指示してください。
	    そこへの接続は、トンネルを経由して安全に
	    <systemitem>mail.example.com</systemitem> に転送されます。</para>
	</sect4>

	<sect4>
	  <title>厳格なファイアウォールをすり抜ける</title>

	  <para>内向けおよび外向きの接続両方をフィルタするファイアウォールルールを課すネットワーク管理者もいます。
	    たとえば、
	    リモートのマシンからのアクセスに、&man.ssh.1; および
	    web サーフィンのための 22 番および 80
	    番ポートにしか接続させてもらえないかもしれません。
	    この場合 22 または 80
	    番以外を使う他のサービスへのアクセスを妨げます。</para>

	  <para>それに対する解決策は、
	    あなたが接続しているネットワークのファイアウォールの外部にあるマシンに対して
	    <acronym>SSH</acronym> 接続を行い、
	    希望するサービスへのトンネルに利用することです。</para>

	  <screen>&prompt.user; <userinput>ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org</userinput>
user@unfirewalled-system.example.org's password: <userinput>*******</userinput></screen>

	  <para>この例では、ストリーミング Ogg Vorbis クライアントを
	    <systemitem>localhost</systemitem> の 8888 番ポートに向けると、
	    <systemitem>music.example.com</systemitem> の 8000
	    番ポートに転送され、ファイアウォールをすり抜けられます。</para>
	</sect4>
      </sect3>
    </sect2>

    <sect2>
      <title><varname>AllowUsers</varname> オプション</title>

      <para>ログインできるユーザや接続元を <literal>AllowUsers</literal>
	を使って制限することは、通常は良い考えです。
	たとえば、
	<systemitem class="username">root</systemitem> が
	<systemitem class="ipaddress">192.168.1.32</systemitem>
	からのみログインできるようにするには、
	以下の行を <filename>/etc/ssh/sshd_config</filename>
	に追加してください。</para>

      <programlisting>AllowUsers root@192.168.1.32</programlisting>

      <para><systemitem class="username">admin</systemitem>
	がどこからでもログインできるようにするには、
	ユーザ名そのものを記述してください。</para>

      <programlisting>AllowUsers admin</programlisting>

      <para>複数のユーザは、以下のように同じ行に追加してください。</para>

      <programlisting>AllowUsers root@192.168.1.32 admin</programlisting>

      <note>
	<para>注意すべきことは、
	  このコンピュータにログインする必要のあるすべてのユーザを指定することです。
	  設定されていないと、そのユーザはログインできなくなります。</para>
      </note>

      <para><filename>/etc/ssh/sshd_config</filename> への変更が終わったら、
	以下を実行して、設定ファイルを &man.sshd.8;
	に読み込ませてください。</para>

      <screen>&prompt.root; <userinput>service sshd reload</userinput></screen>
    </sect2>

    <sect2>
      <title>もっと詳しく知りたい人へ</title>

      <para><link xlink:href="http://www.openssh.com/">OpenSSH</link>
	ウェブサイト</para>

      <para>クライアントオプションについて
	&man.ssh.1;, &man.scp.1;, &man.ssh-keygen.1;,
	&man.ssh-agent.1;, &man.ssh-add.1; および &man.ssh.config.5;</para>

      <para>サーバオプションについて
	&man.sshd.8;, &man.sftp-server.8;, &man.sshd.config.5;</para>
    </sect2>
  </sect1>

  <sect1 xml:id="fs-acl">
    <info><title>ファイルシステムアクセス制御リスト
      (<acronym>ACL</acronym>)</title>
      <authorgroup>
	<author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>寄稿: </contrib></author>
      </authorgroup>
    </info>

    <indexterm>
      <primary>ACL</primary>
    </indexterm>

    <para>アクセス制御リスト (<acronym>ACL</acronym>)
      は、標準的な &unix; のパーミッションモデルを、
      &posix;.1e に互換する方法で拡張しています。
      これにより、管理者がより洗練されたセキュリティモデルを利用し、
      その恩恵を受けられるようになります。</para>

    <para>&os; の <filename>GENERIC</filename> カーネルは、
      <acronym>UFS</acronym> ファイルシステム用の
      <acronym>ACL</acronym> サポートを提供します。
      カスタムカーネルをコンパイルして使用するユーザは、
      カスタムカーネルのコンフィグレーションファイルに以下を追加してください。</para>

    <programlisting>options UFS_ACL</programlisting>

    <para>もしこのオプションが組み込まれていなければ、<acronym>ACL</acronym>
      に対応したファイルシステムをマウントしようとすると、
      警告が表示されます。<acronym>ACL</acronym>
      は、ファイルシステムの拡張属性が有効になっていることに依存しています。
      拡張属性は、<acronym>UFS2</acronym>
      でネイティブ対応されています。</para>

    <note><para><acronym>UFS1</acronym> に拡張属性を付すように設定するのは、
      <acronym>UFS2</acronym>
      よりも高いレベルの管理オーバヘッドが必要になります。
      また、<acronym>UFS2</acronym>
      における拡張属性のパフォーマンスも大きく上がっています。
      そのため、アクセス制御リストを利用する上では <acronym>UFS2</acronym>
      を使うことが推奨されます。</para></note>

    <para><acronym>ACL</acronym> は、マウント時の管理フラグ
      <option>acls</option> で有効にされます。
      これは <filename>/etc/fstab</filename> に記述できます。
      マウント時のフラグは、&man.tunefs.8;
      を使って、ファイルシステムヘッダのスーパブロックにある
      <acronym>ACL</acronym> フラグを変更するという方法で、
      常に自動で設定されるようになります。一般的には、
      下記の理由からスーパブロックフラグを使う方がよいでしょう。</para>

    <itemizedlist>
      <listitem>
	<para>マウント時に指定した <acronym>ACL</acronym> フラグは
	  <option>mount -u</option> による再マウントでは変更できません。
	  完全に &man.umount.8; した上で、新たに &man.mount.8;
	  するしかありません。これは、起動後にルートファイルシステムで
	  <acronym>ACL</acronym> を有効にできないことを意味します。
	  また、ファイルシステムを利用し始めた後では、
	  その配列を変えられないことも意味しています。</para>
      </listitem>

      <listitem>
	<para>スーパブロックフラグを設定すると、<filename>fstab</filename>
	  に記述されていなかったり、デバイスの順番が変わってしまっても、常に
	  <acronym>ACL</acronym> が有効な状態でマウントされます。
	  こうすることで、ファイルシステムを <acronym>ACL</acronym>
	  を有効にしないままマウントしてしまい、<acronym>ACL</acronym>
	  が正しくないかたちで強制されるセキュリティの問題を防ぎます。</para>
      </listitem>
    </itemizedlist>

    <note>
      <para>予期せず <acronym>ACL</acronym>
	を有効にしないでマウントしてしまうことを防ぐことが望まれます。
	<acronym>ACL</acronym> を有効にし、その後無効にしてから、
	拡張属性を取り消さないでまた有効にしてしまうと、
	大変な状況になってしまいます。
	一般的には、一度ファイルシステムで <acronym>ACL</acronym>
	を有効にしたら、無効にすべきではありません。そうしてしまうと、
	ファイル保護がシステムのユーザの意図と齟齬をきたす可能性があるばかりか、
	<acronym>ACL</acronym> を再度有効にすると、
	それまでパーミッションが変更されてきたファイルに古い
	<acronym>ACL</acronym> を割り当ててしまい、
	予想しない動作につながることも考えられます。</para>
    </note>

    <para><acronym>ACL</acronym> を有効にしたファイルシステムは、
      パーミッション設定の表示に <literal>+</literal> (プラス)
      記号がつきます。例えば、次のようになります。</para>

    <programlisting>drwx------  2 robert  robert  512 Dec 27 11:54 private
drwxrwx---+ 2 robert  robert  512 Dec 23 10:57 directory1
drwxrwx---+ 2 robert  robert  512 Dec 22 10:20 directory2
drwxrwx---+ 2 robert  robert  512 Dec 27 11:57 directory3
drwxr-xr-x  2 robert  robert  512 Nov 10 11:54 public_html</programlisting>

    <para>この例では、ディレクトリ
      <filename>directory1</filename>,
      <filename>directory2</filename> および
      <filename>directory3</filename>
      のすべてで <acronym>ACL</acronym> が働いています。
      一方 <filename>public_html</filename>
      は対象外です。</para>

    <sect2>
      <title><acronym>ACL</acronym> を利用する</title>

      <para>&man.getfacl.1; は、
	ファイルシステムの <acronym>ACL</acronym> を表示します。
	たとえば、<filename>test</filename> の
	<acronym>ACL</acronym> 設定を表示するには、
	以下のコマンドを実行してください。</para>

      <screen>&prompt.user; <userinput>getfacl test</userinput>
	#file:test
	#owner:1001
	#group:1001
	user::rw-
	group::r--
	other::r--</screen>

      <para>このファイルの <acronym>ACL</acronym> 設定を変更するには、
	&man.setfacl.1; を使用してください。</para>

      <screen>&prompt.user; <userinput>setfacl -k test</userinput></screen>

      <para>ファイルまたはファイルシステムから、
	現在設定されている <acronym>ACL</acronym>
	をすべて取り除くには、<option>-k</option> を使ってください。
	しかしながら、より好ましい方法は、
	<option>-b</option> を使う方法です。
	このオプションを使うと、<acronym>ACL</acronym>
	が動作するのに必要な基本のフィールドは残ります。</para>

      <screen>&prompt.user; <userinput>setfacl -m u:trhodes:rwx,group:web:r--,o::--- test</userinput></screen>

      <para>この例では、<option>-m</option>
	は、デフォルト <acronym>ACL</acronym>
	エントリを修正するために使われています。
	先ほどのコマンドで設定は削除されたため、
	定義されたエントリはありません。
	このコマンドは、デフォルトオプションに戻し、
	指定したオプションを割り当てます。
	システムに存在しないユーザまたはグループを追加すると、
	<errorname>Invalid argument</errorname>
	エラーが出力されてしまいます。</para>
    </sect2>
  </sect1>

  <sect1 xml:id="security-portaudit">
    <info><title>サードパーティ製ソフトウェアのセキュリティ問題を監視する</title>
      <authorgroup>
	<author>
	  <personname>
	    <firstname>Tom</firstname>
	    <surname>Rhodes</surname>
	  </personname>
	  <contrib>寄稿: </contrib>
	</author>
      </authorgroup>
    </info>

    <indexterm>
      <primary>portaudit</primary>
    </indexterm>

    <para>近年、セキュリティの分野では、
      脆弱性の評価方法に関して多くの改善が行わています。
      今日ではどのオペレーティングシステムにおいても、
      システムへの侵入の脅威は、
      サードパーティ製ユーティリティをインストールし、
      設定するほどに増加していきます。</para>

    <para>脆弱性を評価することは、セキュリティにおいて主要な要素です。
      &os; は、ベースシステムに対して勧告を発行していますが、
      すべてのサードパーティ製ユーティリティに対して勧告を発行することは、
      &os; プロジェクトの能力を超えています。
      サードパーティ製ユーティリティに関わる脆弱性を軽減し、
      管理者に対し、既知のセキュリティ問題について警告する方法が存在します。
      &os; には、<application>portaudit</application>
      と呼ばれる追加のユーティリティが、
      この目的のために用意されています。</para>

    <para>
      <package>ports-mgmt/portaudit</package>
      port は、&os; セキュリティチームおよび ports
      開発者がアップデートし、管理している、
      既知のセキュリティ問題に対するデータベースを入手します。</para>

    <para>Ports Collection から <application>portaudit</application>
      をインストールするには、以下のように実行してください。</para>

    <screen>&prompt.root; <userinput>cd /usr/ports/ports-mgmt/portaudit &amp;&amp; make install clean</userinput></screen>

    <para>インストールの途中で、
      &man.periodic.8; の設定ファイルはアップデートされ、
      毎日のセキュリティに関するスクリプトの実行中に
      <application>portaudit</application>
      が出力するように設定されます。
      毎日のセキュリティに関するスクリプトの実行結果のメールが読めることを確認してください。
      このメールは、<systemitem class="username">root</systemitem>
      アカウントに送られます。
      他の設定は必要ありません。</para>

    <para>インストールが終わったら、管理者は以下のコマンドを実行することで、
      データベースをアップデートし、インストールされている
      package の脆弱性を調べることができます。</para>

    <screen>&prompt.root; <userinput>portaudit -Fda</userinput></screen>

    <note>
      <para>データベースは、
	&man.periodic.8; の実行中に自動的にアップデートされます。
	先程のコマンドの実行は任意で、
	データベースを手動で直ちにアップデートするときに使われます。</para>
    </note>

    <para>Ports Collection
      からインストールされたサードパーティ製ユーティリティを監査するには、
      管理者は以下のコマンドを実行する必要があります。</para>

    <screen>&prompt.root; <userinput>portaudit -a</userinput></screen>

    <para><application>portaudit</application> は、インストールされている
      package の中で、
      脆弱性のあるものについて以下のようなメッセージを出力します。</para>

    <programlisting>Affected package: cups-base-1.1.22.0_1
Type of problem: cups-base -- HPGL buffer overflow vulnerability.
Reference: &lt;http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html&gt;

1 problem(s) in your installed packages found.

You are advised to update or deinstall the affected package(s) immediately.</programlisting>

    <para>表示されている <acronym>URL</acronym>
      をウェブブラウザで開くと、管理者は、
      脆弱性についてより多くの情報を得ることができます。
      ここでの出力では、影響するバージョンが
      &os; の port バージョンにより示され、
      セキュリティ勧告を含む他のウェブサイトが含まれています。</para>

    <para><application>portaudit</application> は強力で、
      <application>portmaster</application> port
      と共に使うときわめて有用なユーティリティです。</para>
  </sect1>

  <sect1 xml:id="security-advisories">
    <info><title>&os; セキュリティ勧告</title>
      <authorgroup>
	<author>
	  <personname>
	    <firstname>Tom</firstname>
	    <surname>Rhodes</surname>
	  </personname>
	  <contrib>寄稿: </contrib>
	</author>
      </authorgroup>
    </info>

    <indexterm>
      <primary>&os; セキュリティ勧告</primary>
    </indexterm>

    <para>多くの高品質なオペレーティングシステムと同様、
      &os; は <quote>セキュリティ勧告</quote> を発行しています。
      これらの勧告は、通常セキュリティに関連したのメーリングリストに投稿され、
      サポートされているリリースに対してパッチが作成された後、
      Errata に記載されます。
      この章では、セキュリティ勧告とは何か、どのように理解すべきか、
      システムにパッチを当てるにはどのように対応すればよいかについて説明します。</para>

    <sect2>
      <title>セキュリティ勧告はどのようなものか？</title>

      <para>&os; セキュリティ勧告では、
	以下のようなフォーマットが用いられています。</para>

      <programlisting>=============================================================================
FreeBSD-SA-XX:XX.UTIL                                       Security Advisory
                                                          The FreeBSD Project

Topic:          denial of service due to some problem <co xml:id="co-topic"/>

Category:       core <co xml:id="co-category"/>
Module:         sys <co xml:id="co-module"/>
Announced:      2003-09-23 <co xml:id="co-announce"/>
Credits:        Person <co xml:id="co-credit"/>
Affects:        All releases of &os; <co xml:id="co-affects"/>
                &os; 4-STABLE prior to the correction date
Corrected:      2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE)
                2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6)
                2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15)
                2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8)
                2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18)
                2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21)
                2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33)
                2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43)
                2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) <co xml:id="co-corrected"/>
<acronym>CVE</acronym> Name:       CVE-XXXX-XXXX <co xml:id="co-cve"/>

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
http://www.FreeBSD.org/security/.

I.   Background <co xml:id="co-backround"/>


II.  Problem Description <co xml:id="co-descript"/>


III. Impact <co xml:id="co-impact"/>


IV.  Workaround <co xml:id="co-workaround"/>


V.   Solution <co xml:id="co-solution"/>


VI.  Correction details <co xml:id="co-details"/>


VII. References <co xml:id="co-ref"/></programlisting>


      <calloutlist>
	<callout arearefs="co-topic">
	  <para><literal>Topic</literal> フィールドでは、
	    問題について明記されています。
	    セキュリティ勧告の導入部であり、
	    脆弱性に影響されるユーティリティを示します。</para>
	</callout>

	<callout arearefs="co-category">
	  <para><literal>Category</literal> フィールドでは、
	    脆弱性がシステムのどの部分に影響するかを示します。
	    <literal>core</literal>, <literal>contrib</literal>
	    または <literal>ports</literal> のどれかが示されます。
	    <literal>core</literal> カテゴリは、
	    &os; オペレーティングシステムの <literal>core</literal>
	    コンポーネントに影響する脆弱性であることを意味します。
	    <literal>contrib</literal> カテゴリは、
	    <application>Sendmail</application>
	    のように、&os; の外で開発され、&os;
	    プロジェクトに取り込まれたソフトウェアに影響する脆弱性であることを意味します。
	    <literal>ports</literal> カテゴリは、Ports Collection
	    からインストールされるソフトウェアに影響する脆弱性であることを示しています。</para>
	</callout>

	<callout arearefs="co-module">
	  <para><literal>Module</literal> フィールドは、
	    影響するコンポーネントについて言及します。
	    この例では、<literal>sys</literal>
	    モジュールに影響することがわかります。
	    そのため、この脆弱性は、
	    カーネルの中で使われるコンポーネントに影響します。</para>
	</callout>

	<callout arearefs="co-announce">
	  <para><literal>Announced</literal> フィールドは、
	    セキュリティ勧告が発行された日、
	    またはアナウンスされた日が記載されています。
	    セキュリティチームによりこの問題が存在することが確認され、
	    パッチが &os;
	    ソースコードリポジトリにコミットされたことを意味します。</para>
	</callout>

	<callout arearefs="co-credit">
	  <para><literal>Credits</literal> フィールドは、
	    脆弱性を通知し、報告した個人または組織を示します。</para>
	</callout>

	<callout arearefs="co-affects">
	  <para><literal>Affects</literal> フィールドは、この脆弱性がどの
	    &os; リリースに影響するかを説明します。
	    カーネルでは、影響するファイルに対して
	    &man.ident.1; を実行すると、
	    その出力からリビジョンを簡単に確認できます。
	    ports の場合には、
	    <filename>/var/db/pkg</filename>
	    の port の名前の後に、バージョン番号が示されています。
	    もし、システムが &os; Subversion
	    リポジトリと同期していなかったり、
	    再構築が毎日行われているような状況でなければ、
	    おそらく、そのシステムには影響しているでしょう。</para>
	</callout>

	<callout arearefs="co-corrected">
	  <para><literal>Corrected</literal> フィールドは、
	    脆弱性が修正された日、時間、
	    タイムゾーン、およびリリースが示されます。</para>
	</callout>

	<callout arearefs="co-cve">
	  <para> <link
	      xlink:href="http://cve.mitre.org">Common Vulnerabilities
	      and Exposures</link> データベースにおいて、
	    脆弱性を探すために使用できる識別情報を示します。</para>
	</callout>

	<callout arearefs="co-backround">
	  <para><literal>Background</literal> フィールドは、
	    影響しているユーティリティに関する情報を示します。
	    大体の場合は、なぜユーティリティが &os; に存在するか、
	    何のために使われているか、
	    どのように用いられるようになってきたか、
	    といった情報が示されます。</para>
	</callout>

	<callout arearefs="co-descript">
	  <para><literal>Problem Description</literal> フィールドは、
	    より深くセキュリティホールについて説明します。
	    問題のあるコードの情報や、
	    このユーティリティが悪意のある使い方により、
	    どのようにセキュリティホールを開けうるかといったことが示されます。</para>
	</callout>

	<callout arearefs="co-impact">
	  <para><literal>Impact</literal> フィールドは、
	    この問題がシステムに対して、
	    どのような形式の影響を与えるかについて示します。
	    たとえば、DoS 攻撃によるものか、
	    ユーザに対して意図しない特権を持たせてしまうものか、
	    または、攻撃者にスーパユーザのアクセスを与えるようなものか、
	    といったことが示されます。</para>
	</callout>

	<callout arearefs="co-workaround">
	  <para><literal>Workaround</literal> フィールドは、
	    時間による制限や、ネットワークの可用性または他の理由により、
	    システムをアップグレードできないシステム管理者に対して、
	    回避方法を提供します。
	    セキュリティを甘く見るべきではなく、
	    影響するシステムにはパッチを当てるか、
	    セキュリティホールの回避方法を実行すべきです。</para>
	</callout>

	<callout arearefs="co-solution">
	  <para><literal>Solution</literal> フィールドは、
	    影響のあるシステムにパッチを当てる手順を提供します。
	    ここではステップごとにシステムにパッチを当て、
	    安全に動作するように、
	    試験され検証された方法が記載されます。</para>
	</callout>

	<callout arearefs="co-details">
	  <para><literal>Correction Details</literal> フィールドは、
	    Subversion
	    ブランチまたはリリース名のピリオドをアンダースコアに置き換えたものを示します。
	    ここでは、
	    各ブランチにおいて影響するファイルのリビジョン番号も示します。</para>
	</callout>

	<callout arearefs="co-ref">
	  <para><literal>References</literal> フィールドは、
	    通常、ウェブページの <acronym>URL</acronym>,
	    books, メーリングリストおよびニュースグループといった、
	    ほかの情報へのソースを提供します。</para>
	</callout>
      </calloutlist>
    </sect2>
  </sect1>

  <sect1 xml:id="security-accounting">
    <info><title>プロセスアカウンティング</title>
      <authorgroup>
	<author>
	  <personname>
	    <firstname>Tom</firstname>
	    <surname>Rhodes</surname>
	  </personname>
	  <contrib>寄稿: </contrib>
	</author>
      </authorgroup>
    </info>

    <indexterm>
      <primary>プロセスアカウンティング</primary>
    </indexterm>

    <para>プロセスアカウンティングは、
      管理者が使用されているシステムのリソースを記録したり、
      リソースのユーザへの割り当て、
      システムのモニタリングおよびユーザのコマンドの最低限の記録を提供します。</para>

    <para>これは実際には、長所と短所があります。
      長所の一つは、侵入を入り口の時点で絞ることができます。
      短所は、プロセスアカウンティングにより生成されるログの量で、
      多くのディスク容量を必要とします。この節では、
      管理者を対象にプロセスアカウンティングの基礎を説明します。</para>

    <sect2>
      <title>プロセスアカウンティングを有効にする</title>

      <para>プロセスアカウンティングを使用する前に、
	以下のコマンドを使って、      
	プロセスアカウンティングを有効にしておく必要があります。</para>

      <screen>&prompt.root; <userinput>touch /var/account/acct</userinput>
&prompt.root; <userinput>chmod 600 /var/account/acct</userinput>
&prompt.root; <userinput>accton /var/account/acct</userinput>
&prompt.root; <userinput>echo 'accounting_enable="YES"' &gt;&gt; /etc/rc.conf</userinput></screen>

      <para>一度有効に設定すると、アカウンティングは、
	<acronym>CPU</acronym> の統計、
	実行されたコマンドの情報の追跡を開始します。
	すべてのアカウンティングログは、
	人が読めるような形式ではなく、
	&man.sa.8; を使って見ることができます。
	オプションを設定せずに実行すると、
	&man.sa.8; はユーザコールの数、全経過時間 (分)、
	全 <acronym>CPU</acronym>、ユーザの時間 (分)、および
	I/O 操作の平均数などを出力します。</para>

      <para>実行されたコマンドに関する情報を見るには、
	&man.lastcomm.1; を使ってください。
	このコマンドは、
	ユーザが特定の &man.ttys.5; で実行したコマンドを出力します。
	たとえば、以下のコマンドは <literal>ttyp1</literal>
	ターミナル上で <systemitem class="username">trhodes</systemitem>
	が実行した &man.ls.1;
	の使用について、記録されているすべて示します。</para>

      <screen>&prompt.root; <userinput>lastcomm ls trhodes ttyp1</userinput></screen>

      <para>他にも有用なオプションが多くあり、
	&man.lastcomm.1;, &man.acct.5; および &man.sa.8;
	で説明されています。</para>
    </sect2>
  </sect1>

  <sect1 xml:id="security-resourcelimits">
    <info>
      <title>リソースの制限</title>

      <authorgroup>
	<author>
	  <personname>
	    <firstname>Tom</firstname>
	    <surname>Rhodes</surname>
	  </personname>
	  <contrib>寄稿: </contrib>
	</author>
      </authorgroup>
    </info>

    <indexterm>
      <primary>リソースの制限</primary>
    </indexterm>

    <para>長年にわたり &os; は、
      リソースを制限するためのデータベースとしてフラットファイル形式の
      <filename>/etc/login.conf</filename> により管理していました。
      この方法は、現在でも使われていますが、
      リソースを管理する方法としては最適な方法でないことが、
      以前から議論されています。
      フラットファイル形式では、
      クラスとして知られるグループラベルにユーザを分類する必要があります。
      この場合、フラットファイルだけではなく、
      パスワードデータベースに対しても変更が必要となります。
      潜在的に、より多くの制限を加えられたユーザ対してはラベルの追加や、
      <command>cap_mkdb</command>
      を使ったリソースデータベースの再構築、
      <filename>/etc/master.passwd</filename>
      への変更が必要となります。
      さらに、パスワードデータベースは、
      <command>pwd_mkdb</command> を使って再構築する必要があります。
      この複数回に渡るプロセスは、
      多くのユーザについて設定する必要がある場合には、
      大変な時間の浪費につながる可能性があります。</para>

    <para>&os; の新しいコマンドである &man.rctl.8; は、
      ユーザに対して、
      よりきめ細かにリソースの制限を管理する方法を提供します。
      このコマンドは、ユーザだけではなく、プロセス、jails
      およびオリジナルのログインクラスに対してもリソースの制限を行うことができます。
      これらの高度な機能は、管理者およびユーザに対し、
      リソースをコマンドラインで管理したり、
      設定ファイルを用いることで、システムの初期化時に、
      ルールを設定する方法を提供します。</para>

    <para>この機能を有効にするには、以下の行を
      <filename>GENERIC</filename>
      またはカスタムカーネルコンフィグレーションファイルに追加し、
      再構築してください。</para>

    <programlisting>options         RACCT
options         RCTL</programlisting>

    <para>その後、システムの再起動が必要になります。
      この過程の手順については、<xref
	linkend="kernelconfig"/> をご覧ください。
      これらの準備が完了すると、<command>rctl</command>
      を用いてシステムにルールを設定できるようになります。</para>

    <para>ルールの構文は簡単で、
      <emphasis>subject</emphasis>, <emphasis>subject-id</emphasis>,
      <emphasis>resource</emphasis> および <emphasis>action</emphasis>
      を使って管理されます。
      以下のルールの例を参照してください。</para>

    <programlisting>user:trhodes:<literal>maxproc</literal>:<literal>deny</literal>=10/user</programlisting>

    <para>これは基本的なルールです。
      ここで、subject は <literal>user</literal>、
      subject-id は <literal>trhodes</literal> です。
      maxproc はもちろんプロセスの最大数であり、resource です。
      ここで action は、<literal>deny</literal> と設定されており、
      新しいプロセスの生成がブロックされます。
      この例では、ユーザ <literal>trhodes</literal> のプロセスは
      <literal>10</literal> 個に制限され、それ以上のプロセスは作成できません。
      コンソールにログを出力したり、
      &man.devd.8; に対し通知したり、プロセスに sigterm を送ったりといった、
      他の action も利用できます。</para>

    <para>ルールを追加する際には、注意すべき点がいくつかあります。
      上の例では、ログインして <command>screen</command>
      セッションを実行してしまうと、
      不幸にもユーザは最も簡単なタスクの実行ですらブロックされてしまうでしょう。
      リソースの制限が適応されると、エラーが出力されます。
      この例では以下のような出力が行われます。</para>

    <screen>&prompt.user; <userinput>man test</userinput>
    /usr/bin/man: Cannot fork: Resource temporarily unavailable
eval: Cannot fork: Resource temporarily unavailable</screen>

    <para>他の例としては、&man.rctl.8; を使って
      jail がメモリの制限を超えることを防ぐことができます。
      このルールは以下のように書くことができます。</para>

    <screen>&prompt.root; <userinput>rctl -a jail:httpd:memoryuse:deny=2G/jail</userinput></screen>

    <para>ルールを <filename>/etc/rctl.conf</filename> に追加すると、
      再起動してもルールは持続します。
      フォーマットは、ルールから最初のコマンドの部分を除いたものとなります。
      たとえば、上のルールを追加するには、
      以下のように追加してください。</para>

    <programlisting># Block jail from using more than 2G memory:
jail:httpd:memoryuse:deny=2G/jail</programlisting>

    <para>ルールを削除するには、<command>rctl</command> に対し、
      リストから削除するように指定してください。</para>

    <screen>&prompt.root; <userinput>rctl -r user:trhodes:maxproc:deny=10/user</userinput></screen>

    <para>マニュアルページには、
      ルールをすべて削除する方法が記載されています。
      しかしながら、特定のユーザのルールをすべて削除するには、
      以下のようなコマンドを実行してください。</para>

    <screen>&prompt.root; <userinput>rctl -r user:trhodes</userinput></screen>

    <para><literal>subjects</literal>
      をコントロールするリソースは他にも多く用意されています。
      これらについて知るには、&man.rctl.8; をご覧ください。</para>
  </sect1>
</chapter>