aboutsummaryrefslogtreecommitdiff
path: root/ja_JP.eucJP
diff options
context:
space:
mode:
authorHideyuki KURASHINA <rushani@FreeBSD.org>2006-03-23 06:00:11 +0000
committerHideyuki KURASHINA <rushani@FreeBSD.org>2006-03-23 06:00:11 +0000
commit173b91940e9156ab76f15cad0d98bace0a6c960d (patch)
treeba2ff331d21c76cf944fd8b951b49c7a0ac0fb5c /ja_JP.eucJP
parent34a670a124a11e301f3baa16f1b1cc793b847f31 (diff)
Notes
Diffstat (limited to 'ja_JP.eucJP')
-rw-r--r--ja_JP.eucJP/books/handbook/security/chapter.sgml713
1 files changed, 468 insertions, 245 deletions
diff --git a/ja_JP.eucJP/books/handbook/security/chapter.sgml b/ja_JP.eucJP/books/handbook/security/chapter.sgml
index fae90a085d..0848116ee4 100644
--- a/ja_JP.eucJP/books/handbook/security/chapter.sgml
+++ b/ja_JP.eucJP/books/handbook/security/chapter.sgml
@@ -2,15 +2,25 @@
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
- Original revision: 1.47
+ Original revision: 1.72
+ Waiting for: 1.123 or mac/chapter.sgml
+ ("mac" referenced from disks).
$FreeBSD$
-->
<chapter id="security">
- <title>セキュリティ</title>
+ <chapterinfo>
+ <authorgroup>
+ <author>
+ <firstname>Matthew</firstname>
+ <surname>Dillon</surname>
+ <contrib>本章の基にした security(7) マニュアルページの執筆: </contrib>
+ </author>
+ </authorgroup>
+ </chapterinfo>
- <para><emphasis>この章の多くの部分は&a.dillon;によって書かれた
- &man.security.7; マニュアルページからの引用です。</emphasis></para>
+ <title>セキュリティ</title>
+ <indexterm><primary>セキュリティ</primary></indexterm>
<para><emphasis>訳: &a.jp.hino;、(jpman プロジェクトの成果を利用させ
ていただきました)。</emphasis></para>
@@ -28,18 +38,18 @@
<title>はじめに</title>
<para>セキュリティとは、システム管理者をいつも悩ませる仕事の一つです。
- すべての BSD UNIX マルチユーザシステムは、
+ すべての BSD Unix マルチユーザシステムは、
従来からいくつかのセキュリティ機構を備えていますが、
ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し
保守する仕事はおそらく、システム管理者としてもっとも大きな責務の一つでしょう。
マシンの安全性に反映されるのは、管理者が作業したことだけです。
またセキュリティ問題は、快適な環境に必要なものと競合します。
- 一般に UNIX システムは膨大な数のプロセスを同時に動作させることができ、
+ 一般に Unix システムは膨大な数のプロセスを同時に動作させることができ、
そのプロセスの大部分は、サーバ &ndash;
外部から接続し、通信するものとして動作します。
かつてのミニコンとメインフレームがデスクトップにとってかわり、
さらにコンピュータが相互に接続されたネットワークを形成するようになった今日、
- セキュリティは非常に大きな関心事になってきています。</para>
+ セキュリティはさらに大きな関心事になってきています。</para>
<para>セキュリティを実装するには、
タマネギのように階層化する手法
@@ -52,18 +62,19 @@
侵入の監視に時間をとられたいとは思わないでしょう。
この侵入の発見という部分は、
あらゆるセキュリティ機構において最も重要な部分の一つなのです。
- たとえば、システムの各バイナリに schg フラグ<!-- (&man.chflags.1; 参照) -->
+ たとえば、システムの各バイナリに
+ <literal>schg</literal> フラグ (&man.chflags.1; 参照)
を設定するのは、大して意味がありません。
フラグを設定すると一時的にバイナリが保護され、
- 侵入してきたクラッカーによってシステムに加えられる変更のうち、
+ 侵入してきた攻撃者によってシステムに加えられる変更のうち、
容易に検出可能な変更は行なえなくなります。
しかしその結果として、セキュリティ機構がその侵入者を検出することも
まったくできなくなってしまうでしょう。</para>
<para>また、システムセキュリティには、
さまざまな形での攻撃に対処することとも関係しています。
- この攻撃には root 権限を奪おうとするものだけでなく、
- クラッシュやシステムの不安定状態を引き起こそうとするものを含まれます。
+ 攻撃の中には root 権限を奪おうとはしないけれども、
+ クラッシュやシステムの不安定状態を引き起こそうとするものもあります。
このセキュリティ問題は、いくつかに分類することが可能です。</para>
<orderedlist>
@@ -88,6 +99,17 @@
</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>サービス妨害攻撃 (DoS 攻撃) とは、
マシンから必要な資源を奪う行為です。
通常、サービス妨害攻撃はそのマシンで実行されるサーバや
@@ -105,11 +127,20 @@
インターネットからシステムを切り離す以外の方法で
防ぐことはほとんど不可能です。
この攻撃によって、マシンを落としてしまうことはできないかもしれませんが、
- 接続しているインターネット回線を混雑させていっぱいにしてしまうことはできます。</para>
-
- <para>ユーザアカウントの不正利用は、サービス妨害攻撃
- よりもずっとよくある問題です。このご時勢でも、自分たちのマシンで
- 標準の telnetd, rlogind, rshd, ftpd サーバを実行させているシステ
+ 接続しているインターネット回線を飽和させてしまうことはできます。</para>
+
+ <indexterm>
+ <primary>セキュリティ</primary>
+ <secondary>アカウント不正利用</secondary>
+ </indexterm>
+
+ <para>ユーザアカウントの不正利用は、
+ サービス妨害攻撃よりもずっとよくある問題です。
+ このご時勢でも、自分たちのマシンで標準の
+ <application>telnetd</application>,
+ <application>rlogind</application>,
+ <application>rshd</application>, <application>ftpd</application>
+ サーバを実行させているシステ
ム管理者は多いのです。これらのサーバは、デフォルトでは、暗号化さ
れたコネクション上で動作していません。その結果、抱えているユーザ
数が標準くらいであれば、リモートログイン (そのシステムにログイン
@@ -118,42 +149,48 @@
人ならば、たとえログインが成功していたとしても、リモートアクセス
ログを解析して、疑わしい送信元アドレスを探すものです。</para>
- <para>ひとたび攻撃者がユーザアカウントへのアクセス権を入手すると、
- 攻撃者が root の権限を破る可能性があることを仮定するべきです。し
- かし、セキュリティを十分維持し、手入れの行き届いたシステムにおい
+ <para>ひとたび攻撃者がユーザアカウントへのアクセス権を入手したら、
+ 攻撃者が root 権限を破る可能性があることを仮定するべきです。
+ しかし、セキュリティを十分維持し、手入れの行き届いたシステムにおい
ては、あるユーザアカウントへのアクセスが可能となっても、攻撃者に
必ずしも root へのアクセス権を与えるとは限りません。こ
の違いは重要です。というのは、一般的に root へのアクセス権がなければ、
- 攻撃者は自分の侵入の痕跡を隠蔽することができませんし、そ
- のユーザのファイルを引っかき回したり、マシンをクラッシュさせたり
- できるのがせいぜいです。ユーザアカウントの不正利用は
- めずらしいことではありません。それは一般ユーザに、システム管
- 理者ほど注意を払わない傾向があるからです。</para>
-
- <!-- 2001/04/04:hrs mistranslation? -->
- <para>システム管理者は「あるマシン上で root の権限を破る方法は、潜
- 在的に何通りもあるのだ」ということを心しておかねばなりません。攻撃
- 者が root のパスワードを知ってしまうかもしれませんし、攻撃者が
- root の権限で実行されるサーバのバグを見つけ、ネットワークからそ
- のサーバへ接続して root の権限を破ることができるかもしれません。
- ひとたびユーザアカウントを破ると、ユーザアカウントから root の権
- 限を破ることを可能にするような suid-root プログラムに存在するバグを
- 攻撃者は知っているかもしれません。あるマシン上で攻撃者
- が root の権限を破る方法を知ったとすると、攻撃者は、裏口を作る必
- 要はありません。これまでに発見され、ふさがれた root の
- 穴の多くには、クラッカーが侵入した跡を消そうとしてたくさん仕事し
- た結果が含まれています。そのためにこそ、多くのクラッカーは裏口を
- 作るのです。攻撃者は裏口を使ってシステムへの root アクセスを再び
- 簡単に得ることができます。しかしこの裏口は、クラッカーの検出をす
- るのに便利なものでもあります。クラッカーに裏口を作らせないように
- するということは、セキュリティにとっては実際には良くないことかも
- しれません。なぜなら、そうすることで、クラッカーが最初に侵入して
- くるために発見したセキュリティホールがふさがるわけではないからで
- す。</para>
-
- <para>セキュリティを改善する方法は、常に、タマネギの皮
- のように階層化する手法 (a multi-layered <quote>onion peel</quote> approach) で実装されるべきです。これら
- は次のように分類できます。</para>
+ 攻撃者は自分の侵入の痕跡を隠蔽することができませんし、
+ そのユーザのファイルを引っかき回したり、
+ マシンをクラッシュさせたりするのがせいぜいです。
+ ユーザアカウントの不正利用はめずらしいことではありません。
+ なぜなら一般ユーザは、
+ システム管理者ほど注意を払わない傾向があるからです。</para>
+
+ <indexterm>
+ <primary>セキュリティ</primary>
+ <secondary>裏口 (バックドア)</secondary>
+ </indexterm>
+
+ <para>システム管理者は、あるマシン上で root 権限を奪取する方法は、
+ 潜在的に何通りもあるということを心しておかねばなりません。
+ 攻撃者は root のパスワードを知っているかもしれませんし、
+ 攻撃者が root 権限で実行されているサーバのバグを見つけ、
+ ネットワーク接続を介して root 権限を破ることができるかもしれません。
+ また、攻撃者は suid-root プログラムに存在するバグを知っていて、
+ ユーザアカウントを破れば root 権限を奪取できるかもしれません。
+ 攻撃者があるマシン上で root 権限を破る方法を知ったならば、
+ 攻撃者は裏口を用意する必要がありません。
+ これまでに発見され、ふさがれた root の穴の多くには、
+ 攻撃者が自分のしたことの痕跡を消そうとした作業が、
+ かなりの割合で含まれています。
+ そのため、ほとんどの攻撃者は裏口を作るのです。裏口は、
+ 攻撃者がたやすくシステムへの root アクセスを再び得られるようにしますが、
+ 有能な管理者に侵入を検知する便利な手段を与えるものでもあります。
+ 攻撃者に裏口を作らせないようにするということは、
+ セキュリティにとっては実際には良くないことかもしれません。
+ なぜなら、攻撃者が最初に見つけて侵入してきたセキュリティホールは
+ ふさがれないからです。</para>
+
+ <para>セキュリティを改善する方法は、常に、
+ タマネギの皮のように階層化する手法
+ (a multi-layered <quote>onion peel</quote> approach)
+ で実装されるべきです。これらは次のように分類できます。</para>
<orderedlist>
<listitem>
@@ -195,12 +232,20 @@
<sect1 id="securing-freebsd">
<title>FreeBSDの安全性を高める</title>
+ <indexterm>
+ <primary>セキュリティ</primary>
+ <secondary>安全性を高める</secondary>
+ </indexterm>
+
<para>以下の節では、本章の<link linkend="security-intro">前節
</link>でとりあげた FreeBSD システムの安全性を高める方法について
述べます。</para>
<sect2 id="securing-root-and-staff">
- <title>root アカウントとスタッフアカウントの安全性を高める</title>
+ <title><username>root</username> アカウントとスタッフアカウントの安全性を高める</title>
+ <indexterm>
+ <primary><command>su</command></primary>
+ </indexterm>
<para>root のアカウントの安全性を確保しないうちからスタッフのア
カウントの安全性をうんぬんしてもしかたがありません。ほとんどの
@@ -220,9 +265,13 @@
<application>sshd</application> のような、別のログインサービス
を使っている場合でも同様に、直接 root へログインすることを許し
ていないかどうか確認してください。すべてのアクセス手段 &ndash;
- たとえば ftp のようなサービスが、良くクラックの対象となることを
- 考えましょう。root への直接ログインは、シス
- テムコンソール経由でのみ可能であるべきなのです。</para>
+ たとえば FTP
+ のようなサービスが、良くクラックの対象となることを考えましょう。
+ root への直接ログインは、
+ システムコンソール経由でのみ可能であるべきなのです。</para>
+ <indexterm>
+ <primary><groupname>wheel</groupname></primary>
+ </indexterm>
<para>また当然、システム管理者として自分が root になれるようにしておく必要が
ありますから、そのための穴をいくつか開けておきます。し
@@ -253,19 +302,32 @@
よりは良いのですが、必ずしも最も安全な選択肢とは限りません。
</para>
- <para>root アカウントの安全性を高める間接的な方法として、別のロ
- グインアクセスの方法を用いてスタッフのアカウントの安全性を高め、
- その上でそのスタッフのアカウントの暗号化パスワードを
- <literal>*</literal> にしておく方法があります。この方法だと、
- 侵入者がパスワードファイルを盗むことができた場合でも、スタッフ
- アカウントを破ることはできなくなります (また、たとえ root が暗
- 号化パスワードをパスワードファイルに付けていたとしても、間接的
- に root アカウントを破ることはできません)。スタッフメン
- バがスタッフアカウントでログインする際には、&man.kerberos.1;
- や &man.ssh.1; のような、公開鍵 / 秘密鍵の鍵の組を使う安全性の
- 高いログイン機構を使います。kerberos のようなログイン機構を使う
- 場合は一般に、kerberos サーバを実行するマシンと自分のデスクトッ
- プワークステーションとの安全性を確保しなければなりません。
+ <para>スタッフのアカウント、また究極には root アカウントの安全性
+ を高める間接的な方法は、別のログインアクセスの方法を用いてスタッ
+ フのアカウントの安全性を高め、その上でそのスタッフのアカウント
+ の暗号化パスワードを <literal>*</literal> にしておくものです。
+ &man.vipw.8; コマンドを使えば、暗号化されたパスワードを
+ <literal>*</literal> 一文字に置き換えられます。このコマンドは、
+ <filename>/etc/master.passwd</filename> ファイルとユーザ/パス
+ ワードデータベースを更新して、パスワード認証によるログインがで
+ きないようにします。</para>
+
+ <para>たとえば、次のスタッフアカウントを、</para>
+
+ <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
+
+ <para>こう変更します。</para>
+
+ <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
+
+ <para>暗号化されたパスワードは <literal>*</literal> と一致するこ
+ とがないので、この変更によって通常のログインはできなくなります。
+ こうした後は、スタッフメンバは認証のために &man.kerberos.1; や
+ 公開鍵 / 秘密鍵の組を用いる &man.ssh.1; のような代わりとなる認
+ 証手段を利用しなければなりません。
+ Kerberos のようなログイン機構を使う場合は、一般に kerberos サー
+ バを実行するマシンと自分のデスクトップワークステーションの安全
+ 性を確保しなければなりません。
また <application>ssh</application> で公開鍵 / 秘密鍵の組を使う場合、
一般に、<emphasis>ログイン元</emphasis>マシン (通常は自分のワー
クステーション) の安全性を確保しなければなりません。ここで、
@@ -295,8 +357,10 @@
ステーションやサーバへの物理的アクセス手段を持たない人々によっ
て行われるという事実もまた、念頭に置いておく必要があります。
</para>
+ <indexterm><primary>Kerberos</primary></indexterm>
- <para>kerberos のような方法を使うことで、スタッフアカウントのパ
+ <para>Kerberos のような方法を使うことで、
+ スタッフアカウントのパ
スワードの変更もしくは停止を一箇所で行なうことと、スタッフメン
バがアカウントを持つすべてのマシンに即時にその効果を及ぼすこと
が可能となります。スタッフメンバのアカウントが危険に晒されたと
@@ -313,12 +377,37 @@
<sect2>
<title>root 権限で実行されているサーバと SUID/SGID バイナリの安全性を高める</title>
+ <indexterm>
+ <primary><command>ntalk</command></primary>
+ </indexterm>
+ <indexterm>
+ <primary><command>comsat</command></primary>
+ </indexterm>
+ <indexterm>
+ <primary><command>finger</command></primary>
+ </indexterm>
+ <indexterm>
+ <primary>砂場 (sandbox)</primary>
+ </indexterm>
+ <indexterm>
+ <primary><application>sshd</application></primary>
+ </indexterm>
+ <indexterm>
+ <primary><application>telnetd</application></primary>
+ </indexterm>
+ <indexterm>
+ <primary><application>rshd</application></primary>
+ </indexterm>
+ <indexterm>
+ <primary><application>rlogind</application></primary>
+ </indexterm>
<para>用心深いシステム管理者は、自分に必要なサーバプロセスだけを
過不足なく実行させるものです。サードパーティ製のサーバは、よくバグを持っ
ていがちだということに注意して下さい。たとえば、古いバージョンの
- imapd や popper を実行させておくのは、全世界に万能の root の切
- 符を与えているようなものです。自分で注意深くチェックしていない
+ <application>imapd</application> や popper
+ を実行させておくのは、全世界に万能の root
+ の切符を与えているようなものです。自分で注意深くチェックしていない
サーバは、決して実行してはいけません。root で実行させる必要の
あるサーバはほとんどありません。たとえば、
<application>ntalk</application>,
@@ -353,6 +442,9 @@
ザアカウントがインストールされていないかもしれません。用心深い
システム管理者であれば、できるだけいつでも研究を怠らず、サーバ
に砂場を仕込むものでしょう。</para>
+ <indexterm>
+ <primary><application>sendmail</application></primary>
+ </indexterm>
<para>通常、砂場で実行しないサーバが他にいくつかあります。
<application>sendmail</application>,
@@ -392,7 +484,8 @@
<literal>kmem</literal> グループを破った侵入者が pty を通して
送られたキーストロークを監視できるという危険があります。キース
トロークには、安全な方法でログインするユーザが使っている pty
- も含まれます。tty グループを破った侵入者は、ほぼ任意のユーザの
+ も含まれます。
+ <groupname>tty</groupname> グループを破った侵入者は、ほぼ任意のユーザの
tty へ書き込みができます。ユーザが端末プログラムやキーボードを
シミュレーションする機能を持ったエミュレータを使っている場合、
侵入者は潜在的に、結局そのユーザとして実行されるコマンドをユー
@@ -445,23 +538,31 @@
<devicename>bpf</devicename> デバイスと呼ばれています。侵入者
は普通、侵入済みのマシンでパケット覗き見プログラムを実行させよ
うと試みます。侵入者にわざわざそういう機能を提供する必要はない
- ので、ほとんどのシステムで bpf デバイスを組み込むべきではあり
- ません。</para>
-
- <para>bpf デバイスを外しても、<filename>/dev/mem</filename> と
- <filename>/dev/kmem</filename> という悩みの種がまだ残っていま
- す。この問題に関しては、侵入者は raw ディスクデバイスに書き込
+ ので、ほとんどのシステムで <devicename>bpf</devicename>
+ デバイスを組み込むべきではありません。</para>
+
+ <indexterm>
+ <primary><command>sysctl</command></primary>
+ </indexterm>
+ <para><devicename>bpf</devicename> デバイスを外しても、
+ <devicename>/dev/mem</devicename> と
+ <devicename>/dev/kmem</devicename>
+ という悩みの種がまだ残っています。この問題に関しては、侵入者は
+ raw ディスクデバイスに書き込
むこともできます。また、モジュールローダ、&man.kldload.8; とい
う、別のカーネル機能があります。やる気まんまんの侵入者は、KLD
- モジュールを使って自分独自の bpf もしくはその他覗き見デバイス
+ モジュールを使って自分独自の <devicename>bpf</devicename>
+ もしくはその他覗き見デバイス
を動作中のカーネルにインストールすることができます。この問題を
避けるため、システム管理者はカーネルをより高い安全レベル (
securelevel)、少なくとも安全レベル 1 で実行させる必要がありま
す。<command>sysctl</command> を使って
- <literal>kern.securelevel</literal> 変数に安全レベルを設定する
+ <varname>kern.securelevel</varname>
+ 変数に安全レベルを設定する
ことができます。ひとたび安全レベルに 1 を設定すると、raw デバ
イスに対する書き込みアクセスは拒否され、たとえば
- <literal>schg</literal> のような特別な chflags フラグの機能が
+ <literal>schg</literal> のような特別な
+ <command>chflags</command> フラグの機能が
強制されます。システム起動に関わる重要なバイナリやディレクトリ、
スクリプトファイルなど、安全レベルが設定されるまでの間に実行さ
れるすべてのものに対しても <literal>schg</literal> フラグを on
@@ -502,8 +603,9 @@
されたファイルを探すのに最も良い方法は、もう一つの (しばしば中
央に集められた)、アクセスが制限されたシステムから行なうもので
す。さらに安全でアクセス制限されたシステム上でセキュリティ用ス
- クリプトを書けば、スクリプトは潜在的なクラッカー達からはほぼ見
- えなくなります。これは重要なことです。この有効性を最大限に活用
+ クリプトを書けば、
+ スクリプトは潜在的な攻撃者からはほぼ見えなくなります。
+ これは重要なことです。この有効性を最大限に活用
するためには、一般的に、アクセスの制限されたマシンから実際に使っ
ている他のマシンへのかなりのアクセスを許す必要があります。普
通は、他のマシンからアクセス制限されたマシンへ読み込み専用の
@@ -516,9 +618,10 @@
サーバがスイッチを通してクライアントに接続されている場合、たい
てい NFS がより良い選択肢です。アクセス制限されたサーバがハブ
を通したり、いくつかのルーティング層を通したりしてクライアント
- に接続する場合、NFS はあまりにも危険な方法かもしれず (ネットワー
- クの面で)、<application>ssh</application> の方が認証の道筋は
- 跡となって残りますが、それでもより良い方法かもしれません。
+ に接続する場合、
+ NFS は (ネットワークの面で) あまりにも危険な方法かもしれず、
+ <application>ssh</application> の方が認証を行った跡は残りますが、
+ より良い方法でしょう。
</para>
<para>アクセス制限されたマシンに、監視しようとするクライアントシ
@@ -588,19 +691,21 @@
<para>多少偏執狂的になっても決して悪いことにはなりません。原則的
に、システム管理者は、便利さに影響を与えない範囲でいくつでもセ
- キュリティ機能を追加することができます。また、いくらか考慮した
- 結果、便利さに影響を与えるセキュリティ機能を追加することもでき
- ます。もっと重要なことには、セキュリティ管理者とは少し喧嘩にな
- るはずなのですが &ndash; もしあなたが、本文書に書かれている勧
- 告をそのまま使用した場合は、予想されるクラッカーはやはり本文書
- を読んでいるわけですから、あなたの防御策を教えてしまうことにな
- ります。</para>
+ キュリティ機能を追加することができます。
+ また、いくらか考慮した結果、
+ 便利さに<emphasis>影響を与える</emphasis>セキュリティ機能を追加することもできます。
+ より重要なことは、
+ セキュリティ管理者はこれを多少混ぜこぜにして使うべきだということです。
+ &ndash; もしあなたが、本文書に書かれている勧告をそのまま使用した場合は、
+ 予想される攻撃者はやはり本文書を読んでいるわけですから、
+ あなたの防御策を教えてしまうことになります。</para>
</sect2>
<sect2>
<title>サービス妨害攻撃</title>
+ <indexterm><primary>サービス妨害 (DoS)</primary></indexterm>
- <para>このセクションではサービス妨害攻撃 (DOS 攻撃) を扱います。
+ <para>このセクションではサービス妨害攻撃 (DoS 攻撃) を扱います。
サービス妨害攻撃は、普通は、パケット攻撃です。ネットワークを飽
和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシス
テム管理者が打てる手はそれほど多くありませんが、一般的に、その
@@ -624,16 +729,19 @@
<para>よくあるサービス妨害攻撃は、fork するサーバプロセスに対す
るものです。これは、サーバにプロセス、ファイル記述子、メモリを
- マシンが死ぬまで食い尽くさせようとするものです。inetd
+ マシンが死ぬまで食い尽くさせようとするものです。
+ <application>inetd</application>
(&man.inetd.8; 参照) には、この種の攻撃を制限するオプションが
いくつかあります。マシンがダウンすることを防止することは可能で
すが、この種の攻撃によりサービスが中断することを防止することは
- 一般的に言ってできないことに注意する必要があります。inetd のマ
- ニュアルページを注意深く読んで下さい。特に、
+ 一般的に言ってできないことに注意する必要があります。
+ <application>inetd</application>
+ のマニュアルページを注意深く読んで下さい。特に、
<option>-c</option>, <option>-C</option>, <option>-R</option>
オプションに注意して下さい。IP 偽造攻撃 (spoofed-IP attack) は
- inetd の <option>-C</option> オプションの裏をかけるので、一般
- にオプションを組み合わせて使用するべきであることに注意して下さ
+ <application>inetd</application> の
+ <option>-C</option> オプションの裏をかけるので、
+ 一般にオプションを組み合わせて使用するべきであることに注意して下さ
い。スタンドアロンサーバの中には、自分自身で fork を制限するパ
ラメータを持っているものがあります。</para>
@@ -689,7 +797,7 @@
更新を忘れたりする可能性がよく出てきます。ファイアウォール上の
大きい番号のポートを開けておくことにより、小さい番号のポートを
危険に晒すことなく受容的な動作を許すことができます。FreeBSD で
- は、<literal>net.inet.ip.portrange</literal> への
+ は、<varname>net.inet.ip.portrange</varname> への
<command>sysctl</command> (<command>sysctl -a | fgrep
portrange</command>) をいろいろ使用することで、動的バインドに使用される
ポート番号の範囲を制御できることを記憶にとどめておいてください。
@@ -697,8 +805,10 @@
たとえば、通常の first/last 範囲として 4000 から 5000 を、
高位ポートの範囲として、49152 から 65535 を指定し、
(いくつかのインターネットアクセス可能
- なポートをブロックから除外するのはもちろんですが) 4000 より下
- のすべてをブロックするという設定が考えられるでしょう。</para>
+ なポートをブロックから除外するのはもちろんですが) 4000
+ より下のすべてのポートをブロックするという設定が考えられます。</para>
+
+ <indexterm><primary>ICMP_BANDLIM</primary></indexterm>
<para>また別のよくあるサービス妨害攻撃として、踏み台攻撃
(springboard attack) と呼ばれるものがあります &ndash; これは、
@@ -723,9 +833,11 @@
り、この種の攻撃でサーバをクラッシュさせることも可能です。サー
バが生成した ICMP 応答を十分速く送信できない場合、とくにひどい
ことになります。FreeBSD カーネルには、この種の攻撃の効果を抑制
- する ICMP_BANDLIM と呼ばれる新しいカーネルコンパイルオプション
+ する <option>ICMP_BANDLIM</option>
+ と呼ばれる新しいカーネルコンパイルオプション
があります。踏み台攻撃の 3 つめの主要なクラスに属する攻撃は、
- udp echo サービスのような、特定の inetd 内部サービスに関連する
+ udp echo サービスのような、特定の
+ <application>inetd</application> 内部サービスに関連する
ものです。攻撃者は、単に送信元アドレスがサーバ A の echo ポー
トであり、送信先アドレスがサーバ B の echo ポートであるように
UDP パケットを偽造します。ここでサーバ A, B はともにあなたの
@@ -733,13 +845,14 @@
トを両者の間で互いに相手に対して打ち返しあいます。このようにし
てパケットをほんのいくつか注入するだけで、攻撃者は両方のサーバ
と LAN を過負荷状態にすることができます。同様の問題が内部
- chargen ポートにも存在します。有能なシステム管理者はこの手の
+ <application>chargen</application> ポートにも存在します。
+ 有能なシステム管理者はこの手の
inetd 内部テストサービスのすべてを無効にしておくものです。
</para>
<para>偽造パケット攻撃は、カーネルの経路情報キャッシュに過負荷を
生じさせるために用いられることもあります。
- <literal>net.inet.ip.rtexpire</literal>,
+ <varname>net.inet.ip.rtexpire</varname>,
<literal>rtminexpire</literal>, <literal>rtmaxcache</literal>
の <command>sysctl</command> パラメータを参照して下さい。でた
らめな送信元 IP アドレスを用いた偽造パケット攻撃により、カーネ
@@ -747,9 +860,10 @@
れは <command>netstat -rna | fgrep W3</command> で見ることがで
きます。これらの経路は、普通は 1600 秒程度でタイムアウトになり
ます。カーネルがキャッシュ経路テーブルが大きくなり過ぎたことを
- 検知すると、カーネルは動的に rtexpire を減らしますが、
- rtminexpire より小さくなるようには決して減らしません。ここに問
- 題が 2 つあります。</para>
+ 検知すると、カーネルは動的に <literal>rtexpire</literal>
+ を減らしますが、<literal>rtminexpire</literal>
+ より小さくなるようには決して減らしません。ここに問題が
+ 2 つあります。</para>
<orderedlist>
<listitem>
@@ -769,13 +883,15 @@
<literal>rtexpire</literal> と <literal>rtminexpire</literal>
とを手動で上書きしておくことが思慮深いことといえます。どちらか
一方でも 0 には決してしないで下さい (自分のマシンをクラッシュ
- させたくないのであれば <!-- smiley -->:-)。両パラメータを 2 秒
+ させたくないのであれば)。両パラメータを 2 秒
に設定すれば、攻撃から経路情報テーブルを守るには十分でしょう。
</para>
</sect2>
<sect2>
<title>Kerberos および SSH を用いたアクセスの問題</title>
+ <indexterm><primary><command>ssh</command></primary></indexterm>
+ <indexterm><primary>Kerberos</primary></indexterm>
<para>もしあなたが、kerberos および
<application>ssh</application> を使用したいのだとしたら、両者
@@ -796,10 +912,10 @@
ている場合に、安全でないマシンへ
<application>ssh</application> を行なう時に暗号鍵が見えてしま
うということです。実際の鍵そのものが見えてしまうわけではありま
- せんが、<application>ssh</application> は、あなたが login して
- いる間、転送用ポートを作ります。クラッカーが安全でないマシンの
- root を破ると、クラッカーは、このポートを使って暗号鍵を取得し、
- この暗号鍵でロックの外れる他のマシンへのアクセスを得ます。
+ せんが、<application>ssh</application> は、あなたが login
+ している間、転送用ポートを作ります。攻撃者が安全でないマシンの
+ root を破ったら、このポートを使って暗号鍵を取得し、
+ この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。
</para>
<para>スタッフのログインには、kerberos を組み合せた
@@ -821,17 +937,33 @@
</sect1>
<sect1 id="crypt">
+ <sect1info>
+ <authorgroup>
+ <author>
+ <firstname>Bill</firstname>
+ <surname>Swingle</surname>
+ <contrib>改訂: </contrib>
+ </author>
+ </authorgroup>
+ <!-- 21 Mar 2000 -->
+ </sect1info>
+
<title>DES, MD5 と Crypt</title>
+ <indexterm>
+ <primary>セキュリティ</primary>
+ <secondary>crypt</secondary>
+ </indexterm>
- <para><emphasis>改訂: &a.unfurl;, 21 March　
- 2000.</emphasis></para>
+ <indexterm><primary>crypt</primary></indexterm>
+ <indexterm><primary>DES</primary></indexterm>
+ <indexterm><primary>MD5</primary></indexterm>
<para><emphasis>訳: &a.hanai;,
12 September 1996.</emphasis></para>
<para><emphasis>訳改訂: &a.jp.hino;,
12 March 2001.</emphasis></para>
- <para>UNIX システムにおけるすべてのユーザは、そのアカウントに対応し
+ <para>Unix システムにおけるすべてのユーザは、そのアカウントに対応し
た一つのパスワードを持っています。それらのパスワードはユーザ本人
と本当のオペレーティングシステムのみが知っているべきであるという
ことは明らかでしょう。それらのパスワードを秘密に保っておくために、
@@ -845,14 +977,13 @@
可能な限りのパスワード空間を検索するという力任せの方法です。
</para>
- <para>不幸なことに、UNIX が生まれようとしているときにパスワードを
- 安全な形で暗号化できる方式は DES(Data Encryption Standard) に基
- づいたものだけでした。このことは米国に住んでいるユーザにとって
+ <para>不幸なことに、Unix が生まれようとしているときにパスワードを
+ 安全な形で暗号化できる方式は DES (Data Encryption Standard)
+ に基づいたものだけでした。このことは米国に住んでいるユーザにとって
は大して問題ではありませんでしたが、DES のソースコードを米国外に
輸出することはできないという問題がありました。そのために、
- FreeBSD は、米国の法律を守ることと、未だに DES を使っている他の
- UNIX 一族との互換性を保つこととを両立する方法を探し出す必要があ
- りました。</para>
+ FreeBSD は、米国の法律を守ることと、未だに DES を使っていた他の
+ Unix 一族との互換性を保つこととを両立する方法を探し出す必要がありました。</para>
<para>その解決方法は、米国のユーザは DES のライブラリをインストー
ルして DES を使用できるが、米国外のユーザは国外に輸出可能な他の
@@ -870,8 +1001,9 @@
<filename>/etc/master.passwd</filename> ファイルの中の暗号化さ
れたパスワードを調べてみるのが一つの方法です。MD5 ハッシュで暗
号化されたパスワードは、DES ハッシュで暗号化されたパスワードよ
- りも長いですし、その上 <literal>&dollar;1&dollar;</literal> と
- いう文字で始まるという特徴も持っています。DES のパスワードはこ
+ りも長く、<literal>&dollar;1&dollar;</literal>
+ という文字で始まるという特徴を持っています。
+ DES のパスワードはこ
れといって識別可能な特徴は持っていませんが、MD5 のパスワードよ
りは短く、そして <literal>&dollar;</literal> という文字を含ま
ない 64 文字のアルファベットを使って表現されているので、比較的
@@ -919,6 +1051,11 @@ lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -&gt; libdescrypt_p.a</s
<sect1 id="skey">
<title>S/Key</title>
+ <indexterm><primary>S/Key</primary></indexterm>
+ <indexterm>
+ <primary>セキュリティ</primary>
+ <secondary>S/Key</secondary>
+ </indexterm>
<para>S/Key は一方向ハッシュ関数を基にしたワンタイムパスワード方式
です。FreeBSD では、互換性のために MD4 ハッシュを用いていますが
@@ -928,10 +1065,11 @@ lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -&gt; libdescrypt_p.a</s
Communications Research, Inc. の登録商標です。</para>
<para>以下の説明では、三種類の異なる「パスワード」が使われます。
- まず一つ目は、あなたが普段使っている普通の UNIX スタイルの、もし
- くは Kerberos でのパスワードです。ここではこれを <quote>UNIX パ
- スワード</quote>と呼ぶことにし ます。二つ目は、S/Key の
- <command>key</command> プログラムによって生成され、
+ まず一つ目は、あなたが普段使っている普通の
+ Unix スタイルの、もしくは Kerberos
+ のパスワードです。ここではこれを
+ <quote>Unix パスワード</quote> と呼ぶことにします。二つ目は、S/Key
+ の <command>key</command> プログラムによって生成され、
<command>keyinit</command> プログラムとログインプロンプトが受け
付けるパスワードです。ここではこれを<quote>ワンタイムパスワード
</quote>と呼ぶことにします。三つ目のパスワードは、
@@ -944,16 +1082,18 @@ lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -&gt; libdescrypt_p.a</s
表記していますが、混乱を避けるために訳文ではすべて<quote> 秘密の
パスフレーズ</quote>に統一しています)。</para>
- <para>秘密のパスフレーズは、UNIX パスワードと何の関連性もありませ
- ん: 両者を同一に設定することは可能ですが、お奨めしません。UNIX
+ <para>秘密のパスフレーズは、Unix
+ パスワードと何の関連性もありません。
+ 両者を同一に設定することは可能ですが、お奨めしません。Unix
パスワードは長さが 8 文字に制限されています (訳注: FreeBSD で
DES を導入していない場合はもっと長いパスワードも認識されます)。
これに対し、S/Key では秘密のパスフレーズを好きなだけ長くすること
ができます (訳注: 実装上、<command>key</command> コマンドなどの
バッファ長で制限されてしまう可能性があります。200 文字程度に押
- えておいた方がよいでしょう :-)。6 語から 7 語からなるパスフレー
- ズがふつうです。ほとんどの部分で、S/Key システムは UNIX のパスワー
- ドシステムと完全に独立して動作するようになっています。</para>
+ えておいた方がよいでしょう :-)。
+ 6 語から 7 語からなるパスフレーズがふつうです。ほとんどの部分で、
+ S/Key システムは Unix
+ のパスワードシステムと完全に独立して動作するようになっています。</para>
<para>パスフレーズに加え、S/Key システムにとって重要な二種類のデー
タがあります。一つは<quote>シード (seed: 種)</quote>または
@@ -989,8 +1129,9 @@ lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -&gt; libdescrypt_p.a</s
ます。最後に、<command>login</command> と <command>su</command>
プログラムについてですが、これらは S/Key のワンタイムパスワード
を、(訳注:システムが) ユーザを認証するものとして受理するのに必要
- な処理をおこないます。<command>login</command> プログラムは、指
- 定された特定のアドレスからの接続に対して、UNIX パスワードの使用
+ な処理をおこないます。<command>login</command>
+ プログラムは、指定された特定のアドレスからの接続に対して、Unix
+ パスワードの使用
を認めなくする機能、逆に言えば S/Key の利用を強制する機能も持っ
ています。</para>
@@ -1129,15 +1270,19 @@ Password: </screen>
ムパスワードを紙に印刷していた場合など、ワンタイムパスワードを
手で入力しなければならない場合に特に役立つ機能です。また、この
ログインしようとしてるマシンが、接続元のマシンから
- UNIX パスワードを使ってログインすることができないように設定さ
+ Unix パスワードを使ってログインすることができないように設定さ
れている場合には、ログインプロンプトには S/Key のワンタイムパ
スワードのみが受け付けられることを示す <literal>(s/key
required)</literal> という注釈が表示されます。</para>
+ <indexterm><primary>MS-DOS</primary></indexterm>
+ <indexterm><primary>Windows</primary></indexterm>
+ <indexterm><primary>MacOS</primary></indexterm>
+
<para>次に、このログインプロンプトに対して入力するためのワンタイ
- ムパスワードを生成しましょう。そのために、
- <command>key</command> プログラムを使える信頼できるマシンを用
- 意します。(<command>key</command> プログラムには DOS や
+ ムパスワードを生成しましょう。そのために、<command>key</command>
+ プログラムを使える信頼できるマシンを用意します。
+ (<command>key</command> プログラムには MS-DOS や
Windows の上で動くもの、MacOS の上で動くものなどもあります)。
<command>key</command> プログラムを使うときには、シーケンス番
号とシードを指定します。ログインしようとしているマシンのログ
@@ -1202,10 +1347,11 @@ Enter secret password: <userinput>&lt;秘密のパスフレーズ&gt;</userinput>
</sect2>
<sect2>
- <title>UNIX パスワードの利用を制限する</title>
+ <title>Unix パスワードの利用を制限する</title>
- <para>設定ファイル <filename>/etc/skey.access</filename> を使っ
- て UNIX パスワードの利用を制限することができます。この場合の判
+ <para>設定ファイル <filename>/etc/skey.access</filename>
+ を使って Unix パスワードの利用を制限することができます。
+ この場合の判
断基準として、ログインを受け付ける際のホスト名、ユーザ名、端末
のポート、IP アドレスなどが利用できます。この設定ファイルの詳
細に関してはマニュアル &man.skey.access.5; をご覧ください。マ
@@ -1215,11 +1361,11 @@ Enter secret password: <userinput>&lt;秘密のパスフレーズ&gt;</userinput>
<para>もし <filename>/etc/skey.access</filename> ファイルが存在
しないならば (FreeBSD のデフォルト状態ではそうです)、すべての
- ユーザが UNIX パスワードを利用することができます。逆に、もし
+ ユーザが Unix パスワードを利用することができます。逆に、もし
ファイルが存在するならば、<filename>skey.access</filename> ファ
イルに明示的に記述されていない限り、すべてのユーザは S/Key の
利用を要求されます。どちらの場合においても、そのマシンのコンソー
- ルからはいつでも UNIX パスワードを使ってログインすることが可能
+ ルからはいつでも Unix パスワードを使ってログインすることが可能
です。</para>
<para>以下によく使われるであろう三種類の設定を含む設定ファイルの
@@ -1232,17 +1378,18 @@ permit port ttyd0</programlisting>
<para>はじめの行 (<literal>permit internet</literal>) で、telnet
などで接続するときの IP のソースアドレス (注意: これは偽造され
るおそれがあります) が特定の値とマスクに一致している場合に、
- UNIX パスワードの利用を許可することを指定しています。この設定
- 自体はセキュリティを高めるための機能ではありません。そうでは
+ Unix パスワードの利用を許可することを指定しています。
+ この設定自体はセキュリティを高めるための機能ではありません。そうでは
なく、ログインの権利を持つ許可されたユーザに対して、現在そのユー
ザが使っているネットワークが信頼できないと考えられるので S/Key
を使うべきである、ということを気づかせるための機能であると考え
てください。</para>
- <para>二行目 (<literal>permit user</literal>) によって、ある特定
- のユーザ、この場合は <literal>fnord</literal>、に対して、いつ
- でも UNIX パスワードの利用を許可するように指定しています。一般
- 的にはこの設定をおこなうべきではありません。
+ <para>二行目 (<literal>permit user</literal>)
+ によって、ある特定のユーザ、この場合は
+ <username>fnord</username>、に対して、いつでも Unix
+ パスワードの利用を許可するように指定しています。
+ 一般的にはこの設定をおこなうべきではありません。
<command>key</command> プログラムがどうしても使えない環境にい
る人や、ダム端末しかない環境にいる人、または何度教えても聞く耳
を持たないような人をサポートする必要がある場合にのみ設定をおこ
@@ -1250,18 +1397,32 @@ permit port ttyd0</programlisting>
<para>三行目 (<literal>permit port</literal>) によって、ある特定
の端末ポートからログインしようとするすべてのユーザに対して
- UNIX パスワードの利用を許可するように指定しています。この設定
+ Unix パスワードの利用を許可するように指定しています。この設定
はダイヤルアップ回線に対する設定として利用できるでしょう。
</para>
</sect2>
</sect1>
<sect1 id="kerberos">
- <title>Kerberos</title>
+ <sect1info>
+ <authorgroup>
+ <author>
+ <firstname>Mark</firstname>
+ <surname>Murray</surname>
+ <contrib>寄稿: </contrib>
+ </author>
+ </authorgroup>
+ <authorgroup>
+ <author>
+ <firstname>Mark</firstname>
+ <surname>Dapoz</surname>
+ <contrib>基にした文書の執筆: </contrib>
+ </author>
+ </authorgroup>
+ </sect1info>
- <para><emphasis>原作: &a.markm;
- (Mark Dapoz <email>md@bsc.no</email>
- からの寄稿に基づいています)。</emphasis></para>
+ <title>Kerberos</title>
+ <indexterm><primary>Kerberos</primary></indexterm>
<para><emphasis>訳: &a.jp.arimura;.</emphasis></para>
@@ -1278,6 +1439,7 @@ permit port ttyd0</programlisting>
する際のガイドとして読むことができます。しかし、
完全な説明が必要な場合には、マニュアルページを読んだ方がよい
でしょう。</para>
+ <indexterm><primary>4.4BSD-Lite</primary></indexterm>
<para>FreeBSDのKerberosは、
オリジナルの4.4BSD-Liteの配布に含まれているものではなく、
@@ -1334,11 +1496,11 @@ ARC.NASA.GOV trident.arc.nasa.gov</screen>
行の1つめの単語が管理領域で、2つめがその管理領域の中で
<quote>鍵配布センター</quote>(Key Distribution Center)
として働くホスト名です。ホスト名の次に <literal>admin
- server</literal> と書いてある場合には、そのホストが
- ``管理データベースサーバ''(Administrative Database Server)
- も提供 することを意味します。
- これらの単語について詳しく知りたい場合にはKerberosのマニュアル
- ページをご覧ください。</para>
+ server</literal> と書いてある場合には、そのホストが
+ 管理データベースサーバ (Administrative Database Server)
+ も提供することを意味します。
+ これらの単語について詳しく知りたい場合には Kerberos
+ のマニュアルページをご覧ください。</para>
<para>ここで、
<filename>GRONDAR.ZA</filename>という管理領域に<hostid
@@ -1597,8 +1759,8 @@ Principal: jane@GRONDAR.ZA
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA</screen>
<para><command>passwd</command>
- コマンドを用いてパスワードを変更して、kpasswdデーモ
- ンがKerberos
+ コマンドを用いてパスワードを変更して、
+ <application>kpasswd</application> デーモンが Kerberos
データベースに対して認証されるかどうかチェックして
ください。</para>
@@ -1612,15 +1774,14 @@ Password changed.</screen>
</sect2>
<sect2>
- <title><command>su</command>特権の追加</title>
-
- <para>root権限が必要なユーザは<emphasis>誰でも</emphasis>、
- <command>su</command>コマンドのパス
- ワードをユーザ毎に<emphasis>別のもの</emphasis>
- として持つことができます。
- <username>root</username>に<command>su</command>
- できる権利を与えられたidを追加します。これは、
- principalに付いている<username>root</username>
+ <title><command>su</command> 特権の追加</title>
+
+ <para>root 権限が必要なユーザは<emphasis>誰でも</emphasis>、
+ <command>su</command> コマンドのパスワードをユーザ毎に
+ <emphasis>別のもの</emphasis> として持つことができます。
+ <username>root</username> に <command>su</command>
+ できる権利を与えられた id を追加します。これは、
+ principal に付いている <username>root</username>
というインスタンスに よって制御されています。
<command>kdb_edit</command>を用いて
<literal>jane.root</literal>というエントリを
@@ -1663,8 +1824,9 @@ MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane.root"
<prompt>Password: </prompt></screen>
- <para>ここでrootユーザの <filename>.klogin</filename>
- ファイルにユーザを追加する必要が あります。</para>
+ <para>ここで <username>root</username> ユーザの
+ <filename>.klogin</filename>
+ ファイルにユーザを追加する必要があります。</para>
<screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
jane.root@GRONDAR.ZA</screen>
@@ -1753,9 +1915,26 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</sect1>
<sect1 id="firewalls">
- <title>ファイアウォール</title>
+ <sect1info>
+ <authorgroup>
+ <author>
+ <firstname>Gary</firstname>
+ <surname>Palmer</surname>
+ <contrib>寄稿: </contrib>
+ </author>
+ <author>
+ <firstname>Alex</firstname>
+ <surname>Nash</surname>
+ </author>
+ </authorgroup>
+ </sect1info>
- <para><emphasis>原作: &a.gpalmer;, Alex Nash;.</emphasis></para>
+ <title>ファイアウォール</title>
+ <indexterm><primary>ファイアウォール</primary></indexterm>
+ <indexterm>
+ <primary>セキュリティ</primary>
+ <secondary>ファイアウォール</secondary>
+ </indexterm>
<para><emphasis>訳: &a.jp.saeki;.<!-- <br> -->
11 November 1996.</emphasis></para>
@@ -1824,8 +2003,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
Proxy サーバを FreeBSD 上に構築することができます。しかし、
現在入手可能な proxy サーバは
たいへんバラエティに富んでいるので、
- このドキュメントでそれらすべてを
- カバーすることは不可能です。</para>
+ この節でそれらすべてをカバーすることはできないでしょう。</para>
<sect3 id="firewalls-packet-filters">
<title>パケットフィルタリングルータ</title>
@@ -1865,7 +2043,9 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<sect3 id="firewalls-proxy-servers">
<title>Proxy サーバ</title>
- <para>Proxy サーバとは通常のシステムデーモン (telnetd, ftpd
+ <para>Proxy サーバとは通常のシステムデーモン
+ (<application>telnetd</application>,
+ <application>ftpd</application>
など) を 特別なサーバで置き換えたマシンのことです。
これらのサーバは、
通常は中継をおこなって特定方向への接続だけを許すため、
@@ -1911,9 +2091,10 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<sect2>
<title>IPFW で何ができるか</title>
+ <indexterm><primary><command>ipfw</command></primary></indexterm>
<para>FreeBSD とともに配布されている
- <application>IPFW</application> は、カーネル内部にあって
+ <command>IPFW</command> は、カーネル内部にあって
パケットのフィルタリングとアカウンティングを
おこなうシステムであり、
ユーザ側のコントロールユーティリティである &man.ipfw.8; を
@@ -1946,6 +2127,10 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<sect2>
<title>FreeBSD で IPFW を有効にする</title>
+ <indexterm>
+ <primary><command>ipfw</command></primary>
+ <secondary>有効化</secondary>
+ </indexterm>
<para><application>IPFW</application>
システムの中心となる部分はカーネル内部にあります。そのため、
@@ -2006,16 +2191,20 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</varlistentry>
</variablelist>
- <para>以前のバージョンの FreeBSD は
+ <note><para>以前のバージョンの FreeBSD は
<literal>IPFIREWALL_ACCT</literal> というオプションを
持っていました。しかし、
ファイアウォールコードがアカウンティングファシリティ (機能) を
自動的に含むようになったため、
- 現在では使用されることはなくなっています。</para>
+ 現在では使用されることはなくなっています。</para></note>
</sect2>
<sect2>
<title>IPFW の設定</title>
+ <indexterm>
+ <primary>ipfw</primary>
+ <secondary>設定</secondary>
+ </indexterm>
<para><application>IPFW</application> ソフトウェアの設定は
&man.ipfw.8; ユーティリティを
@@ -2090,10 +2279,9 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
現在のバージョンでは、それぞれのファイアウォールエントリ毎に
パケットアカウンティングエントリが備えられています。</para>
- <para><emphasis>index</emphasis> が指定されていると、
- エントリはチェーン中の <emphasis remap=tt>index</emphasis>
- で示される位置に置かれます。<emphasis
- remap=tt>index</emphasis> が指定されて いなければ、
+ <para><emphasis>index</emphasis> 値が指定されていると、
+ エントリはチェーン中の指示された位置に置かれます。
+ <emphasis>index</emphasis> 値が指定されて いなければ、
エントリは (65535 番のデフォルトルールである
パケット拒絶を別にして) 最後のチェーンエントリの index に
100 を足した 位置 (チェーンの最後) に置かれます。</para>
@@ -2487,11 +2675,11 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
コマンドのログ取りをおこなっていると、
ファイアウォールをパケットが一つ通過する毎に 1
行のログが生成されるため <emphasis>大量の</emphasis>
- ログデータが発生します。そのため、大規模な ftp/http
+ ログデータが発生します。そのため、大規模な FTP/HTTP
転送などをおこなうと、システムが非常に 遅くなってしまいます。
また、パケットが通過するまでにカーネルにより
多くの仕事を要求するため、パケットのレイテンシ (latency)
- を増加させてしまいます。syslogd
+ を増加させてしまいます。<application>syslogd</application>
もログをディスクに記録するなど、より多くの CPU タイムを
使用し始め、実に容易に <filename>/var/log</filename>
が置かれているパーティションを
@@ -2501,9 +2689,10 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<para>ファイアウォールは、
<filename>/etc/rc.conf.local</filename> か、もしくは
<filename>/etc/rc.conf</filename> によって有効化されるべきです。
- 関連マニュアルページには、どのドアノブ(訳注:
+ 関連マニュアルページには、どのドアノブ (訳注:
ポートや IP アドレスなど、
- ネットワークからの入口を示すもののこと)に手をつければ良いのかに
+ ネットワークからの入口を示すもののこと)
+ に手をつければ良いのかに
ついての説明と、ファイアウォール設定の既定値のリストがあります。
もし、設定の既定値を使わない場合には、
<command>ipfw list</command> とすることで、
@@ -2534,8 +2723,9 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<para><emphasis> すべての </emphasis> 入力 UDP
トラフィックをブロックします。これは UDP
を使用しているサービスで有用なものは極めて少ないうえ、
- 有用なトラフィック (たとえば Sun の RPC と NFS プロトコル)
- は、通常セキュリティに対する脅威となるためです。UDP
+ (Sun の RPC と NFS プロトコルのように)
+ 有用なトラフィックであったとしても、
+ 通常セキュリティに対する脅威となるためです。UDP
はコネクションレスプロトコルであるため、入力 UDP
トラフィックを拒絶することは すなわち出力 UDP
トラフィックに対する返答をも ブロックすることになるので、
@@ -2546,7 +2736,8 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
任意の UDP
ポートへ来るパケットがファイアウォールを通過することを
許可しなければなりません。123
- 番のポートから来るパケットは ntp パケットで、
+ 番のポートから来るパケットは
+ <application>ntp</application> パケットで、
これも通過の許可を考慮する必要がある
もう一つのサービスです。</para>
</listitem>
@@ -2592,6 +2783,11 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<sect1 id="openssl">
<title>OpenSSL</title>
+ <indexterm>
+ <primary>セキュリティ</primary>
+ <secondary>OpenSSL</secondary>
+ </indexterm>
+ <indexterm><primary>OpenSSL</primary></indexterm>
<para>FreeBSD 4.0 では、OpenSSL ツールキットが基本構成の一部に
含まれています。<ulink url="http://www.openssl.org/">OpenSSL</ulink> は、
@@ -2612,6 +2808,11 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<para>現在は RSA アルゴリズムはアメリカとその他の国で自由に利用で
きます。以前は特許により保護されていました。</para>
+ <indexterm>
+ <primary>OpenSSL</primary>
+ <secondary>インストール</secondary>
+ </indexterm>
+
<sect2>
<title>ソースコードのインストール</title>
@@ -2624,14 +2825,29 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</sect1>
<sect1 id="ipsec">
+ <sect1info>
+ <authorgroup>
+ <author>
+ <firstname>Yoshinobu</firstname>
+ <surname>Inoue</surname>
+ <contrib>寄稿: </contrib>
+ </author>
+ <!-- 5 Mar 2000 -->
+ </authorgroup>
+ </sect1info>
+
<title>IPsec</title>
- <para><emphasis>原作: &a.shin;, 5 March
- 2000.</emphasis></para>
+ <indexterm><primary>IPsec</primary></indexterm>
+ <indexterm>
+ <primary>セキュリティ</primary>
+ <secondary>IPsec</secondary>
+ </indexterm>
+
<para><emphasis>訳: &a.jp.hino;, 14 March
2001.</emphasis></para>
- <para>IPsec 機構は、IP 層とソケット層の両方に対して安全な通
- 信を提供します。実装の詳細に関しては <ulink
+ <para>IPsec 機構は、IP 層とソケット層に対して安全な通信を提供します。
+ 実装の詳細に関しては <ulink
url="http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html">The
Developers' Handbook</ulink> を参照してください。
<!-- si006:2001/08/11 - developers handbook is not translated yet. -->
@@ -2652,7 +2868,6 @@ options IPSEC_ESP #IP security (crypto; define w/IPSEC)</progr
<sect2>
<title>IPv4 におけるトランスポートモードの例</title>
-
<para>ホスト A (10.2.3.4) とホスト B (10.6.7.8) との間に安全なチャ
ネルを配置するために、セキュリティアソシエーションを設定しましょ
う。ここでは、少し込み入った例を示します。ホスト A からホストB
@@ -2680,7 +2895,6 @@ options IPSEC_ESP #IP security (crypto; define w/IPSEC)</progr
ぞれ 1000, 2000, 3000 を割り当てます。</para>
<screen>
-
(1)
ホスト A ------> ホスト B
@@ -2706,28 +2920,24 @@ options IPSEC_ESP #IP security (crypto; define w/IPSEC)</progr
IV length = 8
KEY=PASSWORD
SPI=3000
-
- </screen>
+</screen>
<para>次に、セキュリティアソシエーションを設定しましょう。ホスト
A とホスト B の両方で、&man.setkey.8; を実行します。</para>
<screen>
-
&prompt.root; <command>setkey -c</command>
add 10.2.3.4 10.6.7.8 ah-old 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ;
add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ;
add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ;
^D
-
- </screen>
+</screen>
<para>実際には、セキュリティポリシのエントリが定義されるまでは
IPsec による通信は行われません。この例の場合、両方のホストを設
定する必要があります。</para>
<screen>
-
A で:
&prompt.root; <command>setkey -c</command>
@@ -2752,33 +2962,29 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
<========= new AH hmac-sha1 ===========
<========= new ESP des-cbc ============
-
- </screen>
+</screen>
</sect2>
<sect2>
<title>IPv6 におけるトランスポートモードの例</title>
- <para>IPv6 を使ったもう一つの例.</para>
+ <para>IPv6 を使ったもう一つの例。</para>
<para>ホスト-A とホスト-B 間の TCP ポート番号 110 番の通信には、
ESP トランスポートモードが推奨されます。</para>
<screen>
-
============ ESP ============
| |
ホスト-A ホスト-B
fec0::10 -------------------- fec0::11
-
- </screen>
+</screen>
<para>暗号化アルゴリズムは blowfish-cbc で、その鍵は "kamekame"、
認証アルゴリズムは hmac-sha1 で、その鍵は "this is the test
key" とします。ホスト-A の設定:</para>
<screen>
-
&prompt.root; <command>setkey -c</command> &lt;&lt;<filename>EOF</filename>
spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec
esp/transport/fec0::10-fec0::11/use ;
@@ -2793,13 +2999,11 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
-E blowfish-cbc "kamekame"
-A hmac-sha1 "this is the test key" ;
EOF
-
- </screen>
+</screen>
<para>そしてホスト-B の設定:</para>
- <screen>
- &prompt.root; <command>setkey -c</command> &lt;&lt;<filename>EOF</filename>
+ <screen>&prompt.root; <command>setkey -c</command> &lt;&lt;<filename>EOF</filename>
spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec
esp/transport/fec0::11-fec0::10/use ;
spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec
@@ -2811,8 +3015,7 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
-E blowfish-cbc "kamekame"
-A hmac-sha1 "this is the test key" ;
EOF
-
- </screen>
+</screen>
<para>SP の方向に注意してください。</para>
</sect2>
@@ -2827,18 +3030,15 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
test" を鍵とする keyed-md5 です。</para>
<screen>
-
======= AH =======
| |
ネットワーク-A ゲートウェイ-A ゲートウェイ-B ネットワーク-B
10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24
-
- </screen>
+</screen>
<para>ゲートウェイ-A における設定:</para>
<screen>
-
&prompt.root; <command>setkey -c</command> &lt;&lt;<filename>EOF</filename>
spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec
ah/tunnel/172.16.0.1-172.16.0.2/require ;
@@ -2850,8 +3050,7 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
-A keyed-md5 "this is the test" ;
EOF
-
- </screen>
+</screen>
<para>上記の例のように、もしポート番号フィールドを書かないと、
"[any]" と同じ意味になります。`-m' は使用される SA のモードを
@@ -2862,7 +3061,6 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
<para>そしてゲートウェイ-B では:</para>
<screen>
-
&prompt.root; <command>setkey -c</command> &lt;&lt;<filename>EOF</filename>
spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec
ah/tunnel/172.16.0.2-172.16.0.1/require ;
@@ -2874,8 +3072,7 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
-A keyed-md5 "this is the test" ;
EOF
-
- </screen>
+</screen>
<para>二台のセキュリティゲートウェイ間の SA の束を作ります</para>
@@ -2885,14 +3082,12 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
れます。</para>
<screen>
-
========== AH =========
| ======= ESP ===== |
| | | |
ネットワーク-A ゲートウェイ-A ゲートウェイ-B ネットワーク-B
fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64
-
- </screen>
+</screen>
</sect2>
<sect2>
@@ -2903,7 +3098,6 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
ゲートウェイ-A での設定は:</para>
<screen>
-
&prompt.root; <command>setkey -c</command> &lt;&lt;<filename>EOF</filename>
spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec
esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require
@@ -2923,8 +3117,7 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
-A hmac-md5 "this is the test" ;
EOF
-
- </screen>
+</screen>
<para>異なる通信端での SA を作る</para>
@@ -2936,19 +3129,16 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
</para>
<screen>
-
================== ESP =================
| ======= ESP ======= |
| | | |
ホスト-A ゲートウェイ-A ホスト-B
fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2
-
- </screen>
+</screen>
<para>ホスト-A での設定:</para>
<screen>
-
&prompt.root; <command>setkey -c</command> &lt;&lt;<filename>EOF</filename>
spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec
esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use
@@ -2972,16 +3162,28 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
-A hmac-md5 "this is the test" ;
EOF
- </screen>
+</screen>
</sect2>
</sect1>
<sect1 id="openssh">
- <title>OpenSSH</title>
+ <sect1info>
+ <authorgroup>
+ <author>
+ <firstname>Chern</firstname>
+ <surname>Lee</surname>
+ <contrib>寄稿: </contrib>
+ </author>
+ <!-- 21 April 2001 -->
+ </authorgroup>
+ </sect1info>
- <para><emphasis>原作: &a.chern;,
- 2001 年 4 月 21 日。</emphasis>
- </para>
+ <title>OpenSSH</title>
+ <indexterm><primary>OpenSSH</primary></indexterm>
+ <indexterm>
+ <primary>セキュリティ</primary>
+ <secondary>OpenSSH</secondary>
+ </indexterm>
<para>セキュアシェル (secure shell) はリモートマシンへのセキュアなアクセスに使われる
ネットワーク接続ツールのセットです。それは <command>rlogin</command>,
@@ -3009,6 +3211,10 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
<sect2>
<title>sshd を有効にする</title>
+ <indexterm>
+ <primary>OpenSSH</primary>
+ <secondary>有効化</secondary>
+ </indexterm>
<para><filename>rc.conf</filename> ファイルに
以下の行を追加してください。</para>
@@ -3022,6 +3228,10 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
<sect2>
<title>SSH クライアント</title>
+ <indexterm>
+ <primary>OpenSSH</primary>
+ <secondary>クライアント</secondary>
+ </indexterm>
<para>&man.ssh.1; ユーティリティは
&man.rlogin.1; と同様に働きます。</para>
@@ -3032,7 +3242,8 @@ Are you sure you want to continue connecting (yes/no)? <userinput>yes</userinput
Host 'foobardomain.com' added to the list of known hosts.
user@foobardomain.com's password: <userinput>*******</userinput></screen>
- <para>ログインは rlogin や telnet でセションを張った時と同様に続きます。
+ <para>ログインは <command>rlogin</command> や telnet
+ でセッションを張った時と同様に続きます。
SSH はクライアントが接続した時、
サーバの信頼性の検証のために鍵指紋システム
(key fingerprint system) を利用します。
@@ -3045,11 +3256,15 @@ user@foobardomain.com's password: <userinput>*******</userinput></screen>
<sect2>
<title>Secure copy</title>
+ <indexterm>
+ <primary>OpenSSH</primary>
+ <secondary>secure copy</secondary>
+ </indexterm>
+ <indexterm><primary><command>scp</command></primary></indexterm>
- <para><command>scp</command> コマンドが rcp と異なるのは、
- セキュアになっているという点だけです。
- つまりローカルのファイルをリモートマシンへ、
- あるいはリモートマシンのファイルをローカルにコピーします。</para>
+ <para><command>scp</command> コマンドは rcp と同様に働きます。
+ 安全な方法で行っているほかは、ローカルのファイルをリモートマシンへ、
+ あるいはリモートマシンのファイルをローカルにコピーするのは同じです。</para>
<screen>&prompt.root <userinput> scp <replaceable>user@foobardomain.com:/COPYRIGHT COPYRIGHT</replaceable></userinput>
user@foobardomain.com's password:
@@ -3063,6 +3278,10 @@ COPYRIGHT 100% |*****************************| 4735
<sect2>
<title>設定</title>
+ <indexterm>
+ <primary>OpenSSH</primary>
+ <secondary>設定</secondary>
+ </indexterm>
<para>システム全体の設定ファイルは、OpenSSH デーモン、
クライアントの両方とも <filename>/etc/ssh</filename> ディレクトリにあります。</para>
@@ -3107,6 +3326,10 @@ Your identification has been saved in /home/user/.ssh/identity.
<sect2>
<title>SSH トンネリング</title>
+ <indexterm>
+ <primary>OpenSSH</primary>
+ <secondary>トンネリング</secondary>
+ </indexterm>
<para>OpenSSH は暗号化されたセションの中に他のプロトコルを
カプセル化することでトンネルを作ることができます。</para>
generated by cgit v1.2.3 (git 2.25.1) at 2025-05-03 12:05:13 +0000