Date: Tue, 7 Nov 2017 14:13:28 +0000 (UTC) From: Ryusuke SUZUKI <ryusuke@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r51188 - head/ja_JP.eucJP/books/handbook/security Message-ID: <201711071413.vA7EDSaV011209@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: ryusuke Date: Tue Nov 7 14:13:27 2017 New Revision: 51188 URL: https://svnweb.freebsd.org/changeset/doc/51188 Log: - Merge the following from the English version: r38230 -> r38269 head/ja_JP.eucJP/books/handbook/security/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/security/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/security/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/security/chapter.xml Tue Nov 7 14:04:40 2017 (r51187) +++ head/ja_JP.eucJP/books/handbook/security/chapter.xml Tue Nov 7 14:13:27 2017 (r51188) @@ -3,28 +3,37 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r38230 + Original revision: r38269 $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> + + <info> + <title>セキュリティ</title> + <authorgroup> - <author><personname><firstname>Matthew</firstname><surname>Dillon</surname></personname><contrib>本章の基にした security(7) マニュアルページの執筆: </contrib></author> + <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> + <para><emphasis>訳: &a.jp.hino;、(jpman + プロジェクトの成果を利用させていただきました)。</emphasis></para> <sect1 xml:id="security-synopsis"> <title>この章では</title> <para>この章では、基本的なシステムセキュリティの考え方、 覚えておくべき一般的なルールを紹介し、 - &os; における高度な話題について簡単に説明します + &os; における高度な話題について簡単に説明します。 ここで扱う話題の多くは、 一般的なシステムやインターネットセキュリティにもあてはまります。 インターネットはもはや、誰もが親切な隣人であろうとする @@ -105,8 +114,8 @@ <!-- <para>Additional security topics are covered throughout this book. For example, Mandatory Access Control is discussed in <xref - linkend="mac"/> and Internet Firewalls are discussed in <xref - linkend="firewalls"/>.</para> --> + linkend="mac"> and Internet Firewalls are discussed in <xref + linkend="firewalls">.</para> --> </sect1> <sect1 xml:id="security-intro"> @@ -115,8 +124,8 @@ <para>セキュリティとは、システム管理者をいつも悩ませる仕事の一つです。 すべての BSD &unix; マルチユーザシステムは、 従来からいくつかのセキュリティ機構を備えていますが、 - ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し - 保守する仕事はおそらく、システム管理者としてもっとも大きな責務の一つでしょう。 + ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し保守する仕事はおそらく、 + システム管理者としてもっとも大きな責務の一つでしょう。 マシンの安全性に反映されるのは、管理者が作業したことだけです。 またセキュリティ問題は、快適な環境に必要なものと競合します。 一般に &unix; システムは膨大な数のプロセスを同時に動作させることができ、 @@ -159,11 +168,13 @@ <primary>DoS 攻撃</primary> <see>サービス妨害 (DoS)</see> </indexterm> + <indexterm> <primary>セキュリティ</primary> <secondary>DoS 攻撃</secondary> <see>サービス妨害 (DoS)</see> </indexterm> + <indexterm><primary>サービス妨害 (DoS)</primary></indexterm> <para>サービス妨害攻撃 (DoS 攻撃) とは、 @@ -176,12 +187,10 @@ パケット一つでマシンをクラッシュさせようとするものもあります。 後者には、カーネルにバグ修正を施すことによってのみ対応することができます。 サーバプロセスに対する攻撃は、オプションを適切に指定することによって、 - 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで - 対応できる場合が多いです。これらに比べると、 + 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで対応できる場合が多いです。これらに比べると、 ネットワークへの力任せの攻撃への対応はずっと難しくなります。 たとえば、偽造パケットによる攻撃 (spoof-packet attack) は、 - インターネットからシステムを切り離す以外の方法で - 防ぐことはほとんど不可能です。 + インターネットからシステムを切り離す以外の方法で防ぐことはほとんど不可能です。 この攻撃によって、マシンを落としてしまうことはできないかもしれませんが、 接続しているインターネット回線を飽和させてしまうことはできます。</para> @@ -195,20 +204,26 @@ このご時勢でも、自分たちのマシンで標準の <application>telnetd</application>, <application>rlogind</application>, - <application>rshd</application>, <application>ftpd</application> - サーバを実行させているシステ - ム管理者は多いのです。これらのサーバは、デフォルトでは、暗号化さ - れたコネクション上で動作していません。その結果、抱えているユーザ - 数が標準くらいであれば、リモートログイン (そのシステムにログイン - するには最も普通で便利な方法です) しているユーザのうち一人以上は、 - パスワードを覗き見られてしまうでしょう。システム管理者が注意深い - 人ならば、たとえログインが成功していたとしても、リモートアクセス - ログを解析して、疑わしい送信元アドレスを探すものです。</para> + <application>rshd</application>, + <application>ftpd</application> + サーバを実行させているシステム管理者は多いのです。 + これらのサーバは、デフォルトでは、 + 暗号化されたコネクション上で動作していません。 + その結果、抱えているユーザ数が標準くらいであれば、リモートログイン + (そのシステムにログインするには最も普通で便利な方法です) + しているユーザのうち一人以上は、 + パスワードを覗き見られてしまうでしょう。 + システム管理者が注意深い人ならば、 + たとえログインが成功していたとしても、 + リモートアクセスログを解析して、 + 疑わしい送信元アドレスを探すものです。</para> <para>ひとたび攻撃者がユーザアカウントへのアクセス権を入手したら、 - 攻撃者は <systemitem class="username">root</systemitem> 権限を破れると仮定するべきです。 - しかし、セキュリティを十分維持し、手入れの行き届いたシステムにおい - ては、あるユーザアカウントへのアクセスが可能となっても、 + 攻撃者は <systemitem class="username">root</systemitem> + 権限を破れると仮定するべきです。 + しかし、セキュリティを十分維持し、 + 手入れの行き届いたシステムにおいては、 + あるユーザアカウントへのアクセスが可能となっても、 必ずしも攻撃者に <systemitem class="username">root</systemitem> へのアクセス権を与えるとは限りません。この違いは重要です。 というのは、一般的に @@ -225,7 +240,8 @@ <secondary>裏口 (バックドア)</secondary> </indexterm> - <para>システム管理者は、あるマシン上で <systemitem class="username">root</systemitem> + <para>システム管理者は、あるマシン上で + <systemitem class="username">root</systemitem> 権限を奪取する方法は、 潜在的に何通りもあるということを心しておかねばなりません。 攻撃者は <systemitem class="username">root</systemitem> @@ -233,24 +249,29 @@ 攻撃者が <systemitem class="username">root</systemitem> 権限で実行されているサーバのバグを見つけ、 ネットワーク接続を介して - <systemitem class="username">root</systemitem> 権限を破ることができるかもしれません。 + <systemitem class="username">root</systemitem> + 権限を破ることができるかもしれません。 また、攻撃者は suid-root プログラムに存在するバグを知っていて、 ユーザアカウントを破れば - <systemitem class="username">root</systemitem> 権限を奪取できるかもしれません。 + <systemitem class="username">root</systemitem> + 権限を奪取できるかもしれません。 攻撃者があるマシン上で - <systemitem class="username">root</systemitem> 権限を破る方法を知ったならば、 + <systemitem class="username">root</systemitem> + 権限を破る方法を知ったならば、 攻撃者は裏口を用意する必要がありません。 - これまでに発見され、ふさがれた <systemitem class="username">root</systemitem> + これまでに発見され、ふさがれた + <systemitem class="username">root</systemitem> の穴の多くには、攻撃者が自分のしたことの痕跡を消そうとした作業が、 かなりの割合で含まれています。 そのため、ほとんどの攻撃者は裏口を作るのです。裏口は、 攻撃者がたやすくシステムへの - <systemitem class="username">root</systemitem> アクセスを再び得られるようにしますが、 + <systemitem class="username">root</systemitem> + アクセスを再び得られるようにしますが、 有能な管理者に侵入を検知する便利な手段を与えるものでもあります。 攻撃者に裏口を作らせないようにするということは、 セキュリティにとっては実際には良くないことかもしれません。 - なぜなら、攻撃者が最初に見つけて侵入してきたセキュリティホールは - ふさがれないからです。</para> + なぜなら、 + 攻撃者が最初に見つけて侵入してきたセキュリティホールはふさがれないからです。</para> <para>セキュリティを改善する方法は、常に、 タマネギの皮のように階層化する手法 @@ -264,8 +285,9 @@ </listitem> <listitem> - <para><systemitem class="username">root</systemitem> の安全性を高める – - <systemitem class="username">root</systemitem> 権限で動作するサーバと + <para><systemitem class="username">root</systemitem> + の安全性を高める – <systemitem + class="username">root</systemitem> 権限で動作するサーバと suid/sgid バイナリ。</para> </listitem> @@ -278,13 +300,13 @@ </listitem> <listitem> - <para>カーネルのコア、raw デバイス、ファイルシステムの安全性を - 高める。</para> + <para>カーネルのコア、raw デバイス、 + ファイルシステムの安全性を高める。</para> </listitem> <listitem> - <para>システムに対して行なわれた、不適切な変更をすばやく検出す - る。</para> + <para>システムに対して行なわれた、 + 不適切な変更をすばやく検出する。</para> </listitem> <listitem> @@ -292,12 +314,13 @@ </listitem> </orderedlist> - <para>本章の次の節では、上記の各項目についてより深く掘り下げていき - ます。</para> + <para>本章の次の節では、 + 上記の各項目についてより深く掘り下げていきます。</para> </sect1> <sect1 xml:id="securing-freebsd"> <title>&os; の安全性を高める</title> + <indexterm> <primary>セキュリティ</primary> <secondary>&os; の安全性を高める</secondary> @@ -305,6 +328,7 @@ <note> <title>コマンド対プロトコル</title> + <para>この文書を通して、アプリケーションを指すのには <application>太字</application> を使い、 コマンドを指す場合には、<command>等幅</command> フォントを使います。 @@ -314,91 +338,98 @@ ssh などに対して有効です。</para> </note> - <indexterm> - <primary>セキュリティ</primary> - <secondary>安全性を高める</secondary> - </indexterm> + <para>以下の節では、本章の <link + linkend="security-intro">前節</link> でとりあげた &os; + システムの安全性を高める方法について述べます。</para> - <para>以下の節では、本章の<link linkend="security-intro">前節 - </link>でとりあげた &os; システムの安全性を高める方法について - 述べます。</para> - <sect2 xml:id="securing-root-and-staff"> <title><systemitem class="username">root</systemitem> アカウントとスタッフアカウントの安全性を高める</title> + <indexterm> <primary><command>su</command></primary> </indexterm> <para><systemitem class="username">root</systemitem> - のアカウントの安全性を確保しないうちから - スタッフのアカウントの安全性をうんぬんしてもしかたがありません。 + のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性をうんぬんしてもしかたがありません。 ほとんどのシステムでは、<systemitem class="username">root</systemitem> - アカウントに割り当てたパスワードが 1 つあり - ます。まず最初にすべきことは、このパスワードは<emphasis>いつで - も</emphasis>不正利用の危険に晒されていると仮定することです。これは - <systemitem class="username">root</systemitem> + アカウントに割り当てたパスワードが 1 + つあります。まず最初にすべきことは、 + このパスワードは<emphasis>いつでも</emphasis>不正利用の危険に晒されていると仮定することです。 + これは <systemitem class="username">root</systemitem> のパスワードを消すべきだと言っているのではありません。 <systemitem class="username">root</systemitem> のパスワードは、マシンにコンソールからアクセスするのには、 - ほとんどいつでも必要なものです。ここで言いたいのは、コンソール - 以外からは、そして可能なら &man.su.1; コマンドを実行する場合も + ほとんどいつでも必要なものです。 + ここで言いたいのは、コンソール以外からは、 + そして可能なら &man.su.1; コマンドを実行する場合も <systemitem class="username">root</systemitem> - のパスワードを使えないようにするべきである、ということで - す。たとえば、あなたが使っている pty が、 - <filename>/etc/ttys</filename> ファイルで insecure と指定 - されているか確認してください。そうすると、 + のパスワードを使えないようにするべきである、ということです。 + たとえば、あなたが使っている pty が、 + <filename>/etc/ttys</filename> ファイルで insecure + と指定されているか確認してください。そうすると、 <command>telnet</command> や <command>rlogin</command> 経由では - <systemitem class="username">root</systemitem> で直接ログインできないようになります。 + <systemitem class="username">root</systemitem> + で直接ログインできないようになります。 これは、<filename>/etc/ssh/sshd_config</filename> を編集して <literal>PermitRootLogin</literal> に <literal>no</literal> が設定されるようにすることで実現できます。 - <application>sshd</application> のような、別のログインサービス - を使っている場合でも同様に、直接 <systemitem class="username">root</systemitem> - へログインすることを許し - ていないかどうか確認してください。すべてのアクセス手段 — - たとえば FTP + <application>sshd</application> のような、 + 別のログインサービスを使っている場合でも同様に、直接 + <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> - になれるようにしておく必要が - ありますから、そのための穴をいくつか開けておきます。し - かし、それらの穴を動作させるには、さらに追加のパスワード認証が - 必要であるようにしておくことが重要です。 - <systemitem class="username">root</systemitem> でアクセス可能と - する方法の一つとして、適切なスタッフアカウントを + <para>また当然、システム管理者として自分が + <systemitem class="username">root</systemitem> + になれるようにしておく必要がありますから、 + そのための穴をいくつか開けておきます。 + しかし、それらの穴を動作させるには、 + さらに追加のパスワード認証が必要であるようにしておくことが重要です。 + <systemitem class="username">root</systemitem> + でアクセス可能とする方法の一つとして、適切なスタッフアカウントを (<filename>/etc/group</filename> 中の) - <systemitem class="groupname">wheel</systemitem> グループに加えることがあります。 - <systemitem class="groupname">wheel</systemitem> グループに入っているスタッフメンバは + <systemitem class="groupname">wheel</systemitem> + グループに加えることがあります。 + <systemitem class="groupname">wheel</systemitem> + グループに入っているスタッフメンバは <command>su</command> を使って <systemitem class="username">root</systemitem> になることが許されます。 パスワードエントリにおいて、スタッフメンバを - <systemitem class="groupname">wheel</systemitem> グループに置くことによって直接 <systemitem class="groupname">wheel</systemitem> + グループに置くことによって直接 + <systemitem class="groupname">wheel</systemitem> 権限を与えてはいけません。スタッフメンバのアカウントは - <systemitem class="groupname">staff</systemitem> グループに所属させるべきで、その上で + <systemitem class="groupname">staff</systemitem> + グループに所属させるべきで、その上で <filename>/etc/group</filename> ファイルを通して - <systemitem class="groupname">wheel</systemitem> グループに加えるべきです。実際に - <systemitem class="username">root</systemitem> アクセスの必要なスタッフメンバのみ - <systemitem class="groupname">wheel</systemitem> グループに置くようにすべきです。 + <systemitem class="groupname">wheel</systemitem> + グループに加えるべきです。実際に + <systemitem class="username">root</systemitem> + アクセスの必要なスタッフメンバのみ + <systemitem class="groupname">wheel</systemitem> + グループに置くようにすべきです。 他の認証方法の場合、たとえば Kerberos を使用する場合には、 <systemitem class="username">root</systemitem> アカウントの Kerberos <filename>.k5login</filename> ファイルを使えば、誰も <systemitem class="groupname">wheel</systemitem> グループに置く必要なく <systemitem class="username">root</systemitem> に &man.ksu.1; - することを許可できます。このやり - 方はよりよい解決策なのかもしれません。なぜなら、 - <literal>wheel</literal> のメカニズムでは、侵入者がパスワード - ファイルを手に入れ、スタッフアカウントのいずれか 1 つを破るこ - とができると、 - <systemitem class="username">root</systemitem> を破ることがまだできてしまうからです。 - <systemitem class="groupname">wheel</systemitem> のメカニズムを用いる方が、 - 何もしないよりは良いのですが、 + することを許可できます。 + このやり方はよりよい解決策なのかもしれません。なぜなら、 + <literal>wheel</literal> のメカニズムでは、 + 侵入者がパスワードファイルを手に入れ、スタッフアカウントのいずれか + 1 つを破ることができると、 + <systemitem class="username">root</systemitem> + を破ることがまだできてしまうからです。 + <systemitem class="groupname">wheel</systemitem> + のメカニズムを用いる方が、何もしないよりは良いのですが、 必ずしも最も安全な選択肢とは限りません。</para> <para>アカウントを完全にロックするには、 @@ -430,40 +461,42 @@ ユーザが &man.ssh.1; の鍵を設定するなどといった認証手段を利用しなければなりません。</para> - <para>これらのセキュリティの仕組みでは、制限の強いサーバから - 制限の弱いサーバへログインすることを前提としています。たとえば、 - メインマシンで、様々な種類のサーバを実行させている場合、ワーク - ステーションではそれらのサーバを実行させてはなりません。ワーク - ステーションを十分に安全にしておくためには、実行するサーバの数 - を、一つもサーバが実行されていないというくらいにまでできる限り - 減らすべきです。また、パスワードで保護されたスクリーンセーバを - 走らせておくべきです。ワークステーションへの物理的アクセスが与 - えられたとすると、もちろん言うまでもなく、攻撃者は管理者が設定 - したいかなる種類のセキュリティをもうち破ることができるのです。 + <para>これらのセキュリティの仕組みでは、 + 制限の強いサーバから制限の弱いサーバへログインすることを前提としています。 + たとえば、メインマシンで、様々な種類のサーバを実行させている場合、 + ワークステーションではそれらのサーバを実行させてはなりません。 + ワークステーションを十分に安全にしておくためには、 + 実行するサーバの数を、 + 一つもサーバが実行されていないというくらいにまでできる限り減らすべきです。 + また、パスワードで保護されたスクリーンセーバを走らせておくべきです。 + ワークステーションへの物理的アクセスが与えられたとすると、 + もちろん言うまでもなく、 + 攻撃者は管理者が設定したいかなる種類のセキュリティをもうち破ることができるのです。 このことは、管理者として必ず考えておかねばならない問題ですが、 - システム破りの大多数は、ネットワーク経由でリモートから、ワーク - ステーションやサーバへの物理的アクセス手段を持たない人々によっ - て行われるという事実もまた、念頭に置いておく必要があります。 - </para> + システム破りの大多数は、ネットワーク経由でリモートから、 + ワークステーションやサーバへの物理的アクセス手段を持たない人々によって行われるという事実もまた、 + 念頭に置いておく必要があります。</para> <para>Kerberos のような方法を使うことで、 - スタッフアカウントのパ - スワードの変更もしくは停止を一箇所で行なうことと、スタッフメン - バがアカウントを持つすべてのマシンに即時にその効果を及ぼすこと - が可能となります。スタッフメンバのアカウントが危険に晒されたと - きに、すべてのマシンでスタッフメンバのパスワードを即座に変更す - る能力を過小評価してはいけません。パスワードが分散されている状 - 況では、N 台のマシンでパスワードを変更すると、てんやわんやの事 - 態を招く可能性があります。Kerberos を使用すると、パスワードの - 再発行に制限 (re-passwording restriction) を課することもできま - す。この機能を使うことにより、ある Kerberos チケットをしばらく - 経つとタイムアウトにすることができるだけでなく、一定期間 ( 例 - えば、1 ヶ月に 1 回) 経つと、ユーザに新しいパスワードを選ぶよ - うに要求することもできます。</para> + スタッフアカウントのパスワードの変更もしくは停止を一箇所で行なうことと、 + スタッフメンバがアカウントを持つすべてのマシンに即時にその効果を及ぼすことが可能となります。 + スタッフメンバのアカウントが危険に晒されたときに、 + すべてのマシンでスタッフメンバのパスワードを即座に変更する能力を過小評価してはいけません。 + パスワードが分散されている状況では、 + N 台のマシンでパスワードを変更すると、 + てんやわんやの事態を招く可能性があります。 + Kerberos を使用すると、パスワードの再発行に制限 + (re-passwording restriction) を課することもできます。 + この機能を使うことにより、ある Kerberos + チケットをしばらく経つとタイムアウトにすることができるだけでなく、 + 一定期間 (例えば、1 ヶ月に 1 回) 経つと、 + ユーザに新しいパスワードを選ぶように要求することもできます。</para> </sect2> <sect2> - <title>root 権限で実行されているサーバと SUID/SGID バイナリの安全性を高める</title> + <title>root 権限で実行されているサーバと + SUID/SGID バイナリの安全性を高める</title> + <indexterm> <primary><command>ntalk</command></primary> </indexterm> @@ -489,49 +522,58 @@ <primary><application>rlogind</application></primary> </indexterm> - <para>用心深いシステム管理者は、自分に必要なサーバプロセスだけを - 過不足なく実行させるものです。サードパーティ製のサーバは、よくバグを持っ - ていがちだということに注意して下さい。たとえば、古いバージョンの + <para>用心深いシステム管理者は、 + 自分に必要なサーバプロセスだけを過不足なく実行させるものです。 + サードパーティ製のサーバは、 + よくバグを持っていがちだということに注意して下さい。 + たとえば、古いバージョンの <application>imapd</application> や <application>popper</application> - を実行させておくのは、全世界に万能の <systemitem class="username">root</systemitem> - の切符を与えているようなものです。自分で注意深くチェックしていない - サーバは、決して実行してはいけません。<systemitem class="username">root</systemitem> + を実行させておくのは、全世界に万能の + <systemitem class="username">root</systemitem> + の切符を与えているようなものです。 + 自分で注意深くチェックしていないサーバは、 + 決して実行してはいけません。 + <systemitem class="username">root</systemitem> で実行させる必要のあるサーバはほとんどありません。たとえば、 <application>ntalk</application>, <application>comsat</application>, - <application>finger</application> デーモンを、専用ユーザの - <firstterm>砂場 (sandbox)</firstterm> で実行させることができます。 + <application>finger</application> デーモンを、 + 専用ユーザの <firstterm>砂場 (sandbox)</firstterm> + で実行させることができます。 管理者が膨大な数の問題を経験していないのなら、 - この「砂場」は完 - 璧ではありませんが、セキュリティに関するタマネギ的アプローチは - ここでも成り立ちます。砂場で実行されているサーバプロセスを経由 - して侵入を果たすことができたとしても、攻撃者はさらに砂場から外 - に脱出しなければなりません。攻撃者が通過せねばならない層の数が - 増えれば増えるほど、それだけ攻撃者が侵入に成功する確率が減りま - す。Root の抜け穴は歴史的に、基本システムサーバも含め、 + この「砂場」は完璧ではありませんが、 + セキュリティに関するタマネギ的アプローチはここでも成り立ちます。 + 砂場で実行されているサーバプロセスを経由して侵入を果たすことができたとしても、 + 攻撃者はさらに砂場から外に脱出しなければなりません。 + 攻撃者が通過せねばならない層の数が増えれば増えるほど、 + それだけ攻撃者が侵入に成功する確率が減ります。 + Root の抜け穴は歴史的に、基本システムサーバも含め、 <systemitem class="username">root</systemitem> 権限で実行されるほとんどすべてのサーバプロセスで発見されています。 ユーザが <application>sshd</application> 経由でのみログインし、 <application>telnetd</application>, <application>rshd</application>, - <application>rlogind</application> 経由でログインすることが決 - してないマシンを稼働させているのであれば、それらのサービスを停 - 止させて下さい!</para> + <application>rlogind</application> + 経由でログインすることが決してないマシンを稼働させているのであれば、 + それらのサービスを停止させて下さい!</para> - <para>&os; では、今では <application>ntalkd</application>, + <para>&os; では、今では + <application>ntalkd</application>, <application>comsat</application>, - <application>finger</application> は砂場で実行させることがデフォ - ルトになっています。次に砂場で実行させるべきプログラムの候補と - して、&man.named.8; があります。 + <application>finger</application> + は砂場で実行させることがデフォルトになっています。 + 次に砂場で実行させるべきプログラムの候補として、 + &man.named.8; があります。 <filename>/etc/defaults/rc.conf</filename> ファイルには、 - <application>named</application> を砂場で実行するために必要な - 引数がコメントアウトされた形式で含まれています。新しいシステム - をインストールしているか、それとも既存のシステムをアップグレー - ドして使っているかに依存しますが、砂場として使用する特別のユー - ザアカウントがインストールされていないかもしれません。用心深い - システム管理者であれば、できるだけいつでも研究を怠らず、サーバ - に砂場を仕込むものでしょう。</para> + <application>named</application> + を砂場で実行するために必要な引数がコメントアウトされた形式で含まれています。 + 新しいシステムをインストールしているか、 + それとも既存のシステムをアップグレードして使っているかに依存しますが、 + 砂場として使用する特別のユーザアカウントがインストールされていないかもしれません。 + 用心深いシステム管理者であれば、できるだけいつでも研究を怠らず、 + サーバに砂場を仕込むものでしょう。</para> + <indexterm> <primary><application>sendmail</application></primary> </indexterm> @@ -540,54 +582,60 @@ <application>sendmail</application>, <application>popper</application>, <application>imapd</application>, - <application>ftpd</application> などです。これらのうちいくつか - のサーバには代わりとなるものがありますが、代わりのものをインス - トールするには、あなたが思うより多くの仕事が必要になるかもしれ - ません (便利さという要素がまたも勝利を収めるわけです)。これら - のサーバは、<systemitem class="username">root</systemitem> + <application>ftpd</application> などです。 + これらのうちいくつかのサーバには代わりとなるものがありますが、 + 代わりのものをインストールするには、 + あなたが思うより多くの仕事が必要になるかもしれません + (便利さという要素がまたも勝利を収めるわけです)。 + これらのサーバは、<systemitem class="username">root</systemitem> 権限で実行しなければばならないかもしれません。また、 - これらのサーバ経由で生じる侵入を検出するためには、他の仕組みに - 頼らなくてはならないかもしれません。</para> + これらのサーバ経由で生じる侵入を検出するためには、 + 他の仕組みに頼らなくてはならないかもしれません。</para> <para>システムの <systemitem class="username">root</systemitem> - 権限の潜在的な穴で他に大きなものには、シ - ステムにインストールされた suid-root/sgid バイナリがあります。 - これらのバイナリは、<application>rlogin</application> のように、 - <filename class="directory">/bin</filename>, <filename - class="directory">/sbin</filename>, <filename - class="directory">/usr/bin</filename> または <filename - class="directory">/usr/sbin</filename> - に存在するものがほとんどです。100% 安全なものは存在しないとは - いえ、システムデフォルトの siud/sgid バイナリは比較的安全とい - えます。それでもなお、<systemitem class="username">root</systemitem> + 権限の潜在的な穴で他に大きなものには、 + システムにインストールされた suid-root/sgid バイナリがあります。 + これらのバイナリは、 + <application>rlogin</application> のように、<filename + class="directory">/bin</filename>, <filename + class="directory">/sbin</filename>, <filename + class="directory">/usr/bin</filename> または <filename + class="directory">/usr/sbin</filename> + に存在するものがほとんどです。 + 100% 安全なものは存在しないとはいえ、 + システムデフォルトの siud/sgid バイナリは比較的安全といえます。 + それでもなお、<systemitem class="username">root</systemitem> セキュリティホールがこれらのバイナリにときおり発見されています。 1998 年に <application>xterm</application> (普通、suid 設定されています) を脆弱にしていた - <literal>Xlib</literal> の <systemitem class="username">root</systemitem> + <literal>Xlib</literal> の + <systemitem class="username">root</systemitem> セキュリティホールが見つかりました。 安全である方がよいので、 - 用心深いシステム管理者は残念に思いながらも、スタッフのみが実行 - する必要がある suid バイナリは、スタッフのみがアクセス可能な特 - 別なグループに含めるように制限を加え、誰も使わない suid バイナ - リは (<command>chmod 000</command> を実行して) 片付けてしまう - でしょう。ディスプレイを持たないサーバは、一般的に + 用心深いシステム管理者は残念に思いながらも、 + スタッフのみが実行する必要がある suid バイナリは、 + スタッフのみがアクセス可能な特別なグループに含めるように制限を加え、 + 誰も使わない suid バイナリは + (<command>chmod 000</command> を実行して) 片付けてしまうでしょう。 + ディスプレイを持たないサーバは、一般的に <application>xterm</application> のバイナリを必要としません。 - sgid バイナリもほとんど同様の危険な存在になり得ます。侵入者が - kmem に sgid されたバイナリを破ることができた場合、その侵入者 - は <filename>/dev/kmem</filename> を読み出すことができるように - なるでしょう。つまり、暗号化されたパスワードファイルを読み出す - ことができるようになるので、パスワードを持つどのアカウントをも、 + sgid バイナリもほとんど同様の危険な存在になり得ます。 + 侵入者が kmem に sgid されたバイナリを破ることができた場合、 + その侵入者は <filename>/dev/kmem</filename> + を読み出すことができるようになるでしょう。つまり、 + 暗号化されたパスワードファイルを読み出すことができるようになるので、 + パスワードを持つどのアカウントをも、 潜在的な危険に晒すことになります。他にも、 - <literal>kmem</literal> グループを破った侵入者が pty を通して - 送られたキーストロークを監視できるという危険があります。キース - トロークには、安全な方法でログインするユーザが使っている pty + <literal>kmem</literal> グループを破った侵入者が pty + を通して送られたキーストロークを監視できるという危険があります。 + キーストロークには、安全な方法でログインするユーザが使っている pty も含まれます。 - <systemitem class="groupname">tty</systemitem> グループを破った侵入者は、ほぼ任意のユーザの - tty へ書き込みができます。ユーザが端末プログラムやキーボードを - シミュレーションする機能を持ったエミュレータを使っている場合、 - 侵入者は潜在的に、結局そのユーザとして実行されるコマンドをユー - ザの端末にエコーさせるデータストリームを生成できる可能性があり - ます。</para> + <systemitem class="groupname">tty</systemitem> + グループを破った侵入者は、ほぼ任意のユーザの + tty へ書き込みができます。 + ユーザが端末プログラムやキーボードをシミュレーションする機能を持ったエミュレータを使っている場合、 + 侵入者は潜在的に、 + 結局そのユーザとして実行されるコマンドをユーザの端末にエコーさせるデータストリームを生成できる可能性があります。</para> </sect2> <sect2 xml:id="secure-users"> @@ -596,16 +644,14 @@ <para>ユーザアカウントは、普通、安全性を高めることが最も困難です。 スタッフに対しては、とても厳格なアクセス制限を強制しパスワードを <quote>アスタリスク</quote> で外すことができるでしょうが、 - 管理者が - 持ちうる一般ユーザすべてのアカウントに対して同じことはできない - かもしれません。管理者が十分に統率をとることができるなら、管理 - 者は勝利し、ユーザのアカウントの安全を適切に確保できるかもしれ - ません。それができないならば、よりいっそう気を配って一般ユーザ - のアカウントを監視するよりほかありません。 + 管理者が持ちうる一般ユーザすべてのアカウントに対して同じことはできないかもしれません。 + 管理者が十分に統率をとることができるなら、管理者は勝利し、 + ユーザのアカウントの安全を適切に確保できるかもしれません。 + それができないならば、 + よりいっそう気を配って一般ユーザのアカウントを監視するよりほかありません。 一般ユーザアカウントに対し ssh や Kerberos を利用することには、 - システム管理がさらに増えたりテクニカルサポートが必要に - なるなどの問題があります。それでも、暗号化パスワードファイルと - 比較するとはるかに良い解です。</para> + システム管理がさらに増えたりテクニカルサポートが必要になるなどの問題があります。 + それでも、暗号化パスワードファイルと比較するとはるかに良い解です。</para> </sect2> <sect2> @@ -615,13 +661,15 @@ それらのアカウントのアクセスには ssh や Kerberos を使うようにすることが、唯一の確実な方法です。 暗号化パスワードファイル - (<filename>/etc/spwd.db</filename>) は <systemitem class="username">root</systemitem> + (<filename>/etc/spwd.db</filename>) は + <systemitem class="username">root</systemitem> でのみ読み出し可能だけれども、 たとえ、侵入者が root の書き込み権限は得られなくとも、 読み出しアクセス権限を得ることは可能かもしれません。</para> <para>セキュリティスクリプトで常にパスワードファイルの変更をチェッ - クし、報告するようにすべきです (<link linkend="security-integrity">ファイルの完全性のチェック</link> + クし、報告するようにすべきです (<link + linkend="security-integrity">ファイルの完全性のチェック</link> 節参照)。</para> </sect2> @@ -630,30 +678,32 @@ 高める</title> <para><systemitem class="username">root</systemitem> - の権限を破ると、攻撃者はほとんど何でもできますが、特に重宝さ - れる特定の事柄もいくつかあります。たとえば、最近のカーネルは、組 - み込みのパケット覗き見デバイス (packet sniffing device) ドライ - バを備えているものがほとんどです。&os; では - <filename>bpf</filename> デバイスと呼ばれています。侵入者 - は普通、侵入済みのマシンでパケット覗き見プログラムを実行させよ - うと試みます。侵入者にわざわざそういう機能を提供する必要はない - ので、ほとんどのシステムで <filename>bpf</filename> + の権限を破ると、攻撃者はほとんど何でもできますが、 + 特に重宝される特定の事柄もいくつかあります。 + たとえば、最近のカーネルは、組み込みのパケット覗き見デバイス + (packet sniffing device) ドライバを備えているものがほとんどです。 + &os; では <filename>bpf</filename> デバイスと呼ばれています。 + 侵入者は普通、 + 侵入済みのマシンでパケット覗き見プログラムを実行させようと試みます。 + 侵入者にわざわざそういう機能を提供する必要はないので、 + ほとんどのシステムで <filename>bpf</filename> デバイスを組み込むべきではありません。</para> <indexterm> <primary><command>sysctl</command></primary> </indexterm> + <para><filename>bpf</filename> デバイスを外しても、 <filename>/dev/mem</filename> と <filename>/dev/kmem</filename> という悩みの種がまだ残っています。この問題に関しては、侵入者は raw ディスクデバイスに書き込 - むこともできます。ほかにも、モジュールローダ、&man.kldload.8; とい - う、別のカーネル機能があります。やる気まんまんの侵入者は、KLD + むこともできます。ほかにも、モジュールローダ、&man.kldload.8; + という、別のカーネル機能があります。やる気まんまんの侵入者は、KLD モジュールを使って自分独自の <filename>bpf</filename> - もしくはその他覗き見デバイス - を動作中のカーネルにインストールできます。この問題を - 避けるため、システム管理者はカーネルをより高いセキュアレベル、 + もしくはその他覗き見デバイスを動作中のカーネルにインストールできます。 + この問題を避けるため、 + システム管理者はカーネルをより高いセキュアレベル、 少なくともセキュアレベル 1 で実行させる必要があります。</para> <para>カーネルのセキュアレベルはいくつかの方法で設定できます。 @@ -723,93 +773,101 @@ すべてのシステムファイルとディレクトリに <literal>schg</literal> フラグを設定しないというところで妥協するという手もあります。 もう一つの可能性としては、単純に - <filename class="directory">/</filename> および - <filename class="directory">/usr</filename> + <filename class="directory">/</filename> および <filename + class="directory">/usr</filename> を読み込み専用でマウントすることです。 ここで特筆すべきことは、システムを守ろうとして厳しくしすぎると、 侵入を検出するという非常に重要なことができなくなってしまうということです。</para> </sect2> <sect2 xml:id="security-integrity"> - <title>ファイルの完全性のチェック: バイナリ、設定ファイルなど - </title> + <title>ファイルの完全性のチェック: バイナリ、 + 設定ファイルなど</title> - <para>ことこの問題に至ると、システム管理者にできることは、便利さ - という要素がその醜い頭を上げない程度に、コアシステムの設定と制 - 御ファイルを防御することだけです。たとえば、 - <filename class="directory">/</filename> および - <filename class="directory">/usr</filename> - にある大部分のファイルに <literal>schg</literal> ビットを設定するた - めに <command>chflags</command> を使用するのは、おそらく逆効果 - でしょう。なぜなら、そうすることでファイルは保護できますが、侵 - 入を検出する窓を閉ざしてしまうことにもなるからです。セキュリティ - のタマネギの最後の層はおそらく最も重要なもの — 検出で - す。セキュリティの残りのものは、突然の侵入を検出できなければ、 - まったく有用ではありません (あるいは、もっと悪ければ、安全性に - 対する間違った感覚を植え付けてしまいます)。 + <para>ことこの問題に至ると、システム管理者にできることは、 + 便利さという要素がその醜い頭を上げない程度に、 + コアシステムの設定と制御ファイルを防御することだけです。 + たとえば、<filename + class="directory">/</filename> および <filename + class="directory">/usr</filename> + にある大部分のファイルに <literal>schg</literal> + ビットを設定するために <command>chflags</command> + を使用するのは、おそらく逆効果でしょう。 + なぜなら、そうすることでファイルは保護できますが、 + 侵入を検出する窓を閉ざしてしまうことにもなるからです。 + セキュリティのタマネギの最後の層はおそらく最も重要なもの + — 検出です。 + セキュリティの残りのものは、突然の侵入を検出できなければ、 + まったく有用ではありません + (あるいは、もっと悪ければ、 + 安全性に対する間違った感覚を植え付けてしまいます)。 タマネギの仕事の半分は、 攻撃者を攻撃の最中に捕えるようにするために、 攻撃者を食い止めるのではなく侵入を遅らせることなのです。</para> - <para>侵入を検出する最も良い方法は、変更されていたり、消えていた - り、入れた覚えがないのに入っているファイルを探すことです。変更 - されたファイルを探すのに最も良い方法は、もう一つの (しばしば中 - 央に集められた)、アクセスが制限されたシステムから行なうもので - す。さらに安全でアクセス制限されたシステム上でセキュリティ用ス - クリプトを書けば、 + <para>侵入を検出する最も良い方法は、変更されていたり、 + 消えていたり、入れた覚えがないのに入っているファイルを探すことです。 + 変更されたファイルを探すのに最も良い方法は、もう一つの + (しばしば中央に集められた)、 + アクセスが制限されたシステムから行なうものです。 + さらに安全でアクセス制限されたシステム上でセキュリティ用スクリプトを書けば、 スクリプトは潜在的な攻撃者からはほぼ見えなくなります。 - これは重要なことです。この有効性を最大限に活用 - するためには、一般的に、アクセスの制限されたマシンから実際に使っている他のマシンへのかなりのアクセスを許可する必要があります。普 - 通は、他のマシンからアクセス制限されたマシンへ読み込み専用の + これは重要なことです。 + この有効性を最大限に活用するためには、一般的に、 + アクセスの制限されたマシンから実際に使っている他のマシンへのかなりのアクセスを許可する必要があります。 + 普通は、他のマシンからアクセス制限されたマシンへ読み込み専用の NFS エクスポートをしたり、アクセス制限されたマシンから他のマシンへ ssh 接続を行なうために、 ssh 鍵のペアを作ったりすることで行います。 - ネットワークのトラフィックを別にして、NFS は最も可視性 - のない方法です — 各クライアント上のファイルシステムを、 - 事実上検出されずに監視できるようになります。アクセス制限された - サーバがスイッチを通してクライアントに接続されている場合、たい - てい NFS がより良い選択肢です。アクセス制限されたサーバがハブ - や、いくつかのルーティング層を通してクライアントに接続している場合、 + ネットワークのトラフィックを別にして、 + NFS は最も可視性のない方法です — + 各クライアント上のファイルシステムを、 + 事実上検出されずに監視できるようになります。 + アクセス制限されたサーバがスイッチを通してクライアントに接続されている場合、 + たいてい NFS がより良い選択肢です。 + アクセス制限されたサーバがハブや、 + いくつかのルーティング層を通してクライアントに接続している場合、 NFS は (ネットワークの面で) あまりにも危険なので、 ssh の方が認証を行った跡は残りますが、良い方法でしょう。</para> - <para>アクセス制限されたマシンに、監視しようとするクライアントシ - ステムへの少なくとも読み込みのアクセス権を与えたら、次に実際に - 監視するためのスクリプトを書かなくてはいけません。NFS マウント - をすれば、&man.find.1; や &man.md5.1; などの単純なシステムユー - ティリティでスクリプトを書くことができます。少なくとも 1 日 1 - 回、クライアントのファイルを直接 md5 にかけ、さらにもっと頻繁 - に <filename class="directory">/etc</filename> および - <filename class="directory">/usr/local/etc</filename> - にあるようなコントロール用 - ファイルを試験するのが一番です。アクセス制限されたマシンが正し - いと知っている、基となる md5 情報と比べて違いが見つかった場合、 - システム管理者に調べて欲しいと悲鳴を上げるようにすべきです。優 - れたセキュリティ用スクリプトは、 - <filename class="directory">/</filename> および - <filename class="directory">/usr</filename> + <para>アクセス制限されたマシンに、 + 監視しようとするクライアントシステムへの少なくとも読み込みのアクセス権を与えたら、 + 次に実際に監視するためのスクリプトを書かなくてはいけません。 + NFS マウントをすれば、&man.find.1; や &man.md5.1; + などの単純なシステムユーティリティでスクリプトを書くことができます。 + 少なくとも 1 日 1 回、クライアントのファイルを直接 md5 にかけ、 + さらにもっと頻繁に <filename + class="directory">/etc</filename> および <filename + class="directory">/usr/local/etc</filename> + にあるようなコントロール用ファイルを試験するのが一番です。 + アクセス制限されたマシンが正しいと知っている、 + 基となる md5 情報と比べて違いが見つかった場合、 + システム管理者に調べて欲しいと悲鳴を上げるようにすべきです。 + 優れたセキュリティ用スクリプトは、<filename + class="directory">/</filename> および <filename + class="directory">/usr</filename> などのシステムパーティション上で不適当に - suid されたバイナリや、新たに作成されたファイルや削除され - たファイルがないかどうかを調べるでしょう。</para> + suid されたバイナリや、 + 新たに作成されたファイルや削除されたファイルがないかどうかを調べるでしょう。</para> <para>NFS ではなく、ssh を使用する場合は、 - セキュリティ用スクリプトを書くのはずっと難しいことで - す。スクリプトを動かすためには、クライアントに対してスクリプト - を <command>scp</command> しなくてはいけませんし、それは目に見 - えてしまいます。そして、安全のためには、スクリプトが使うバイナ - リ (find など) を <command>scp</command> する必要もあります。 + セキュリティ用スクリプトを書くのはずっと難しいことです。 + スクリプトを動かすためには、クライアントに対してスクリプトを + <command>scp</command> しなくてはいけませんし、 + それは目に見えてしまいます。 + そして、安全のためには、スクリプトが使うバイナリ (find など) を + <command>scp</command> する必要もあります。 クライアントマシンの <application>ssh</application> クライアントはすでに攻撃されてしまっているかもしれません。 結局のところ、安全でないリンク上の場合は ssh は必要かもしれませんが、ssh を扱うのはとても大変なことです。</para> - <para>優れたセキュリティ用スクリプトは、ユーザやスタッフメンバの - アクセス設定ファイルの変更もチェックするものです。 + <para>優れたセキュリティ用スクリプトは、 + ユーザやスタッフメンバのアクセス設定ファイルの変更もチェックするものです。 <filename>.rhosts</filename>, <filename>.shosts</filename>, - <filename>.ssh/authorized_keys</filename> など - <literal>MD5</literal> チェックの範囲外になってしまうであろう - ファイル群です。</para> + <filename>.ssh/authorized_keys</filename> など <literal>MD5</literal> + チェックの範囲外になってしまうであろうファイル群です。</para> <para>ユーザ用のディスク容量が非常に大きい場合は、パーティション 上の各ファイルを見て回るのに大変な時間がかかるかもしれません。 @@ -824,41 +882,46 @@ <para>プロセスアカウンティング (&man.accton.8; 参照) は、 マシンへの侵入を検出するためのメカニズムとして推奨できる、 比較的オーバヘッドの少ないオペレーティングシステムの機能です。 - 侵入を受けた後でも当該ファイルが無傷である場合に、侵入者が - 実際にどのようにしてシステムに侵入したかを追跡するのに特に役立ちます。</para> + 侵入を受けた後でも当該ファイルが無傷である場合に、 + 侵入者が実際にどのようにしてシステムに侵入したかを追跡するのに特に役立ちます。</para> - <para>最後に、セキュリティスクリプトはログファイルを処理するよう - にし、ログファイル自体もできるだけ安全性の高い方法で生成するよ - うにすべきです — リモート syslog は極めて有益になり得ま - す。侵入者は自分の侵入の痕跡を覆い隠そうとしますし、また、ログ - ファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆく - ために極めて重要です。ログファイルを永久に残しておくための 1 - つの方法は、システムコンソールをシリアルポートにつないで走らせ、 + <para>最後に、 + セキュリティスクリプトはログファイルを処理するようにし、 + ログファイル自体もできるだけ安全性の高い方法で生成するようにすべきです + — リモート syslog は極めて有益になり得ます。 + 侵入者は自分の侵入の痕跡を覆い隠そうとしますし、また、 + ログファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆくために極めて重要です。 + ログファイルを永久に残しておくための 1 つの方法は、 + システムコンソールをシリアルポートにつないで走らせ、 コンソールを監視している安全なマシンに情報を集めることです。</para> </sect2> <sect2> <title>偏執狂的方法</title> - <para>多少偏執狂的になっても決して悪いことにはなりません。原則的 - に、システム管理者は、便利さに影響を与えない範囲でいくつでもセ - キュリティ機能を追加することができます。 + <para>多少偏執狂的になっても決して悪いことにはなりません。 + 原則的に、システム管理者は、 + 便利さに影響を与えない範囲でいくつでもセキュリティ機能を追加することができます。 また、いくらか考慮した結果、 便利さに<emphasis>影響を与える</emphasis>セキュリティ機能を追加することもできます。 より重要なことは、 セキュリティ管理者はこれを多少混ぜこぜにして使うべきだということです。 - — もしあなたが、本文書に書かれている勧告をそのまま使用した場合は、 + — もしあなたが、 + 本文書に書かれている勧告をそのまま使用した場合は、 予想される攻撃者はやはり本文書を読んでいるわけですから、 あなたの防御策を教えてしまうことになります。</para> </sect2> <sect2> <title>サービス妨害攻撃</title> - <indexterm><primary>サービス妨害 (DoS)</primary></indexterm> + <indexterm> + <primary>サービス妨害 (DoS)</primary> + </indexterm> + <para>このセクションではサービス妨害攻撃 (DoS 攻撃) を扱います。 - サービス妨害攻撃は、普通は、パケット攻撃です。ネットワークを飽 - 和させる最先端の偽造パケット (spoofed packet) + サービス妨害攻撃は、普通は、パケット攻撃です。 + ネットワークを飽和させる最先端の偽造パケット (spoofed packet) 攻撃に対してシステム管理者が打てる手はそれほど多くありませんが、 一般的に、以下のような方法により、 その種の攻撃によってサーバがダウンしないことを確実にすることで、 @@ -870,8 +933,7 @@ </listitem> <listitem> - <para>踏み台攻撃の制限 (ICMP 応答攻撃、ping broadcast など)。 - </para> + <para>踏み台攻撃の制限 (ICMP 応答攻撃、ping broadcast など)。</para> </listitem> <listitem> @@ -884,79 +946,84 @@ 多くの子プロセスを起動させることにより、 メモリ、ファイル記述子などを使いつくし、 ホストシステムを最終的に停止させます。 + <application>inetd</application> (&man.inetd.8; 参照) には、 + この種の攻撃を制限するオプションがいくつかあります。 + マシンがダウンすることを防止することは可能ですが、 + この種の攻撃によりサービスが中断することを防止することは一般的に言ってできないことに注意する必要があります。 <application>inetd</application> - (&man.inetd.8; 参照) には、この種の攻撃を制限するオプションが - いくつかあります。マシンがダウンすることを防止することは可能で - すが、この種の攻撃によりサービスが中断することを防止することは - 一般的に言ってできないことに注意する必要があります。 - <application>inetd</application> のマニュアルページを注意深く読んで下さい。特に、 <option>-c</option>, <option>-C</option>, <option>-R</option> オプションに注意して下さい。IP 偽造攻撃 (spoofed-IP attack) は <application>inetd</application> の <option>-C</option> オプションの裏をかけるので、 - 一般にオプションを組み合わせて使用するべきであることに注意して下さ - い。スタンドアロンサーバの中には、自分自身で fork を制限するパ - ラメータを持っているものがあります。</para> + 一般にオプションを組み合わせて使用するべきであることに注意して下さい。 + スタンドアロンサーバの中には、自分自身で fork + を制限するパラメータを持っているものがあります。</para> <para><application>Sendmail</application> には、 - <option>-OMaxDaemonChildren</option> オプションがあります。シ - ステム負荷の値変化には遅れがあるので、 + <option>-OMaxDaemonChildren</option> オプションがあります。 + システム負荷の値変化には遅れがあるので、 <application>Sendmail</application> の負荷限界指定オプションを使うよりも、 このオプションを使う方がまともに動作する可能性ははるかに高いです。 <application>sendmail</application> の実行を開始する際に、 - <literal>MaxDaemonChildren</literal> パラメータを設定するべき *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201711071413.vA7EDSaV011209>