diff options
Diffstat (limited to 'ja_JP.eucJP')
| -rw-r--r-- | ja_JP.eucJP/books/handbook/security/chapter.xml | 1302 |
1 files changed, 459 insertions, 843 deletions
diff --git a/ja_JP.eucJP/books/handbook/security/chapter.xml b/ja_JP.eucJP/books/handbook/security/chapter.xml index c5caadf1c4..4b3e0f5c5a 100644 --- a/ja_JP.eucJP/books/handbook/security/chapter.xml +++ b/ja_JP.eucJP/books/handbook/security/chapter.xml @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r43278 + Original revision: r43744 $FreeBSD$ --> <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security"> @@ -14,33 +14,33 @@ <authorgroup> <author> <personname> - <firstname>Matthew</firstname> - <surname>Dillon</surname> + <firstname>Tom</firstname> + <surname>Rhodes</surname> </personname> - <contrib>本章の基にした security(7) マニュアルページの執筆: </contrib> + <contrib>寄稿: </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; における高度な話題について簡単に説明します。 - ここで扱う話題の多くは、 - 一般的なシステムやインターネットセキュリティにもあてはまります。 - システムを安全に保つことは、データ、知的財産、時間、その他を、 - ハッカーやその同類から守るためには欠かせません。</para> + <para>物理的もしくは仮想的に関わらず、 + セキュリティは幅広いトピックであり、 + 業界全体がセキュリティとともに成長しています。 + システムおよびネットワークを安全にする標準的な方法は数多く文書化されており、 + &os; のユーザも、 + 攻撃や侵入者から守る方法を理解しなければなりません。</para> - <para>&os; は、 - システムとネットワークの整合性および安全性を保護する仕組みと一連のユーティリティを提供しています。</para> + <para>この章では、セキュリティの基礎や技術について説明します。 + &os; システムは、複数のレイヤに関連するセキュリティを提供します。 + そして、安全性を高めるためにサードパーティ製のユーティリティを利用することもできます。</para> <para>この章を読むと、以下のことがわかります。</para> @@ -123,390 +123,380 @@ <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> - の安全性を高める – <systemitem - class="username">root</systemitem> 権限で動作するサーバと - SUID/SGID バイナリ。</para> - </listitem> - - <listitem> - <para>ユーザアカウントの安全性を高める。</para> - </listitem> + <para>セキュリティを高めることはすべての人の責任です。 + システムに弱い侵入ポイントが存在すると、侵入者は重要な情報を得たり、 + ネットワーク全体に被害を及ぼすことができるようになります。 + 多くのセキュリティのトレーニングでは、 + 情報システムの機密性 (confidentiality)、 + 完全性 (integrity) および可用性 (availability) + を意味するセキュリティの 3 要素である + <acronym>CIA</acronym> が取り扱われます。</para> + + <para><acronym>CIA</acronym> の 3 要素は、 + コンピュータセキュリティの基本となる考えです。 + 顧客やエンドユーザは、データのプライバシーを期待します。 + 彼らは、データが変更されないことや、 + 情報が隠されていることを期待します。 + 彼らはまた、いつでも情報にアクセスできることを期待します。 + これらは、システムの機密性、完全性、可用性を構成します。</para> + + <para>セキュリティのプロフェッショナルは、<acronym>CIA</acronym> + を守るために、多層防衛の戦略を採用します。 + この多層防衛戦略ではセキュリティのレイアを複数用意することで、 + 一つのレイヤが破られても、 + セキュリティシステム全体が破られることを防ぎます。 + システムの管理者は、ファイアウォールを単に有効にするだけではなく、 + ネットワークもしくはシステムを安全に保つ必要があります。 + アカウントを監査し、バイナリの完全性、 + 悪意のあるツールがインストールされていないことを確認する必要があります。 + このために、 + 管理者は脅威がどのようなものかを理解する必要があります。</para> + + <sect2 xml:id="security-threats"> + <title>脅威</title> + + <para>コンピュータセキュリティおける脅威とは何でしょうか？ + 長年、脅威はリモートの攻撃者、 + すなわち遠隔からの許可のないシステムへのアクセスを企てる人々と考えられていました。 + 今日では、この定義は従業員、悪意のあるソフトウェア、 + 不正なネットワークデバイス、自然災害、セキュリティの脆弱性、 + そして競合する会社でさえも含めるように拡張されています。</para> + + <para>毎日、数千ものシステムおよびネットワークが攻撃され、 + 数百ものシステムが許可なくアクセスされています。 + 簡単なアクシデントといったものから、リモートからの攻撃、 + 産業スパイであったり、以前働いていた従業員からの攻撃といったケースもあります。 + システムのユーザとしては、 + 間違いがセキュリティ違反に繋がった場合には、 + 可能性のある問題をセキュリティチームに報告することが重要です。 + 管理者としては、脅威を把握し、 + その脅威の影響を小さくするように準備をしておくことが重要です。</para> + </sect2> + + <sect2 xml:id="security-groundup"> + <title>ボトムアップアプローチ</title> + + <para>セキュリティを考える上で、 + しばしばボトムアップアプローチが一番良い方法となります。 + この考えでは、管理者が基本的なアカウント、システム設定を行ってから、 + サードパーティ製ユーティリティの設定、 + そしてネットワークレイヤに設定を広げていきます。 + システムポリシーおよび手続きを行う上では、 + このような設定の側面があります。</para> + + <para>ビジネスの多くの環境では、 + 使用するデバイスの設定に対するセキュリティポリシがすでに策定されています。 + このポリシには、最低限エンドユーザのワークステーション、 + デスクトップ、携帯電話やラップトップといったモバイルデバイス、および + 製品および開発サーバの両方に対するセキュリティの設定が含まれているべきです。 + 多くの場合には、コンピュータのセキュリティを考える際に、 + 標準作業手続書 (<acronym>SOP</acronym>) + がすでに存在します。 + わからなければ、セキュリティチームに尋ねてください。</para> + </sect2> - <listitem> - <para>パスワードファイルの安全性を高める。</para> - </listitem> + <sect2 xml:id="security-accounts"> + <title>システムおよびユーザアカウント</title> - <listitem> - <para>カーネルのコア、raw デバイス、 - ファイルシステムの安全性を高める。</para> - </listitem> + <para>システムを安全にするにあたり、最も適切な出発点は、 + アカウントの監査です。 + ルートアカウントのパスワードが強力であること、 + シェルアクセスを必要としないアカウントは無効にすることを確実におこなってください。 + また、権限を必要とするユーザに対しては、 + <package>security/sudo</package> をインストールして、 + アクセスが必要となるアプリケーションのみにアクセスを許可するようにしてください。 + root ユーザのパスワードは、決して共有すべきではありません。</para> - <listitem> - <para>システムに対して行なわれた、 - 不適切な変更をすばやく検出する。</para> - </listitem> + <para>アカウントへのアクセスを無効にする方法は二通りあります。 + 一つ目の方法は、アカウントをロックする方法です。例として、 + toor アカウントをロックする方法を以下に示します。</para> - <listitem> - <para>必要と思われる以上の対応をとる (paranoia)。</para> - </listitem> - </orderedlist> + <screen>&prompt.root; <userinput>pw lock toor</userinput></screen> - <para>次の節では、上記の項目についてより深く掘り下げていきます。</para> - </sect1> + <para>このコマンドは、アカウントの設定を + <quote>toor:*:0:0::0:0:Bourne-again Superuser:/root:</quote> + から <quote>toor:*LOCKED**:0:0::0:0:Bourne-again + Superuser:/root:</quote> へと変更します。</para> - <sect1 xml:id="securing-freebsd"> - <title>&os; の安全性を高める</title> + <para>ときには (おそらく追加のサービスのために)、 + この方法が使えない場合があります。 + そのような場合には、以下の例のように、 + シェルを /sbin/nologin に変更することで、 + ログインアクセスを拒否できます。</para> - <indexterm> - <primary>セキュリティ</primary> - <secondary>&os; の安全性を高める</secondary> - </indexterm> + <screen>&prompt.root; <userinput>chsh -s /usr/sbin/nologin toor</userinput></screen> - <para>この節では、<link - linkend="security-intro">前節</link> でとりあげた &os; - システムの安全性を高める方法について説明します。</para> + <note> + <para>他のユーザのシェルは、スーパーユーザのみが変更できます。 + 通常のユーザが行おうとすると失敗します。</para> + </note> - <sect2 xml:id="securing-root-and-staff"> - <title><systemitem class="username">root</systemitem> - アカウントの安全性を高める</title> + <para>アカウント情報は、以下のように最後のエントリが + <quote>nologin</quote> シェルとなります。</para> - <indexterm> - <primary>&man.su.1;</primary> - </indexterm> + <programlisting>toor:*:0:0::0:0:Bourne-again Superuser:/root:/usr/sbin/nologin</programlisting> - <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> + <para><filename>/usr/sbin/nologin</filename> シェルは、 + &man.login.1; + コマンドがこのユーザにシェルを割り当てることをブロックします。</para> + </sect2> - <indexterm> - <primary><systemitem class="groupname">wheel</systemitem></primary> - </indexterm> + <sect2 xml:id="security-sudo"> + <title>アカウントの権限を拡大する</title> - <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> - アクセスの必要なユーザのみ + <para>場合によっては、 + システム管理者へのアクセスを他のユーザと共有する必要があります。 + &os; はこのために二つの方法を用意しています。 + 第一の方法は推奨されませんが、 + ルートのパスワードを共有し、ユーザを <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> + グループに加える方法です。 + これを行うにには、<filename>/etc/group</filename> を編集し、 + 最初のグループの最後にユーザを追加してください。 + ユーザはカンマ区切りで管理されています。</para> + + <para>権限の拡大をする適切な方法は、 + <package>security/sudo</package> port を使う方法です。 + この port は、追加の監査、よりきめ細かいユーザ管理、および + ユーザを &man.service.8; + のような権限が与えられたコマンのみの実行に制限することもできます。</para> + + <para>インストールが終わったら、 + <command>visudo</command> インタフェースを使って + <filename>/usr/local/etc/sudoers</filename> + ファイルを編集してください。 + 以下の例では、新しく webadmin グループが作成され、 + <systemitem class="username">trhodes</systemitem> + ユーザがこのグループに追加されます。 + その後、ユーザに <package>apache24</package> + を再起動するアクセス権限を与えます。 + この手続きは以下のようになります。</para> + + <screen>&prompt.root; <userinput>pw groupadd webadmin -M trhodes -g 6000</userinput></screen> + + <screen>&prompt.root; <userinput>visudo</userinput></screen> + + <programlisting>%webadmin ALL=(ALL) /usr/sbin/service apache24 *</programlisting> + + <para>ローカルのユーザ管理において、 + <package>security/sudo</package> は、 + 非常に貴重なリソースを提供します。 + また、パスワードを不必要にして、デフォルトを &man.ssh.1; + 鍵の方法だけにすることもできます。 + &man.sshd.8; 経由のパスワードによるログインを無効にし、 + <command>sudo</command> + へのローカルパスワードのみを使うようにするには、 + <xref linkend="openssh"/> をご覧ください。</para> </sect2> - <sect2> - <title>root 権限で実行されているサーバと - SUID/SGID バイナリの安全性を高める</title> + <sect2 xml:id="security-passwords"> + <title>パスワード</title> + + <para>パスワードは、テクノロジーにおける必要悪です。 + パスワードは極めて複雑であるだけではなく、 + パスワードを保護する強力なハッシュメカニズムもまた必要となります。 + この文書を書いている時点では、 + &os; は <function>crypt()</function> ライブラリで + <acronym>DES</acronym>, <acronym>MD</acronym>5, Blowfish, + <acronym>SHA</acronym>256 および <acronym>SHA</acronym>512 + に対応しています。 + デフォルトは <acronym>SHA</acronym>512 であり、 + 強度の弱い暗号へは変更すべきではありません。 + しかしながら、Blowfish を好むユーザもおります。 + <acronym>DES</acronym> を除く各メカニズムでは、 + 開始の文字、使用しているハッシュメカニズムを識別可能な特徴を持っています。 + <acronym>MD</acronym>5 メカニズムでは、シンボルは + <quote>$</quote> の符号です。 + <acronym>SHA</acronym>256 または、 + <acronym>SHA</acronym>512 では、シンボルは <quote>$6$</quote>、 + そして Blowfish は <quote>$2a$</quote> です。 + 暗号強度の弱いパスワードを使用している場合には、 + 次回のログイン時にユーザが + &man.passwd.1; を実行して再ハッシュ化することを促すべきです。</para> - <indexterm> - <primary>砂場 (sandbox)</primary> - </indexterm> - <indexterm> - <primary>&man.sshd.8;</primary> - </indexterm> + <note> + <para>この文書を書いている時点で、Blowfish は + <acronym>AES</acronym> でなければ、 + <acronym>FIPS</acronym> (Federal Information + Processing Standards) に準拠もしていません。 + そのため、使用できない環境があります。</para> + </note> - <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> + <para>ネットワークに接続しているシステムについては、 + 二要素認証を使用すべきです。 + この認証では、通常あなたが所有する要素と知っている要素が用いられます。 + &os; のベースシステムに含まれている + <application>OpenSSH</application> および ssh-keys では、 + ネットワークへのすべてのログインにおける二要素認証の交換で、 + パスワードを使用すべきではありません。 + より詳細な情報については、ハンドブックの + <xref linkend="openssh"/> 節をご覧ください。 + Kerberose のユーザは、ネットワークで + <application>OpenSSH</application> + を実装するために追加の変更が必要になるでしょう。</para> </sect2> - <sect2 xml:id="secure-users"> - <title>ユーザアカウントの安全性を高める</title> - - <para>ユーザアカウントは、普通、安全性を高めることが最も困難です。 - 気を配ってユーザアカウントを監視するよりほかありません。 - ユーザアカウントに対し &man.ssh.1; や Kerberos を利用するには、 - システム管理がさらに増えたりテクニカルサポートが必要になりますが、 - 暗号化パスワードファイルと比較するとはるかに良い方法を提供します。</para> + <sect2 xml:id="security-rkhunter"> + <title>バックドアおよびルートキット</title> + + <para>バックドアおよびルートキットは、 + それらがインストールされた後に脅威となります。 + インストールされると、この悪意のあるソフトウェアは、 + 攻撃者のために侵入口を設置します。 + 実際的には、システムが一度汚染された後に、調査が行われ、 + 消去されます。 + 慎重なセキュリティやシステムエンジニアでさえも、 + 攻撃者が残したソフトウェアを見逃してしまうという恐ろしいリスクが存在しています。</para> + + <para>バックドアまたはルートキットソフトウェアは、 + 管理者にとって役に立つことが一つあります。 + それは、一度検出すると、 + システムのどこかが危険に冒されていることの痕跡となります。 + しかし、通常この種のアプリケーションは、とてもうまく隠れています。 + バックドアおよびルートキットを検出するツールが存在しており、 + それうちの一つが、 + <package>security/rkhunter</package> です。</para> + + <para>インストール後、以下のコマンドでシステムをチェックできます。 + 実行すると多くの情報が出力されます。</para> + + <screen>&prompt.root; <userinput>rkhunter -c</userinput></screen> + + <para>このプロセスを実行中に <keycap>ENTER</keycap> + キーを何度か押す必要があります。 + 完了すると、ステータスメッセージが画面に表示されます。 + このメッセージは、チェックしたファイルの量、疑わしいファイルの数、 + 可能性のあるルートキット等の情報を含みます。 + チェックの最中、隠されたファイル、 + <application>OpenSSH</application> プロトコルの選択、そして、 + 時には、インストールされているソフトウェアの漸弱性のバージョンに関する一般的なセキュリティの警告が出力されます。 + すぐに、もしくはより詳細な解析が行われた後に、対応が可能です。</para> + + <para>管理者は皆、 + 担当しているシステム上で何が実行されているかを把握している必要があります。 + <application>rkhunter</application>, + <application>lsof</application> や + &man.netstat.1; および &man.ps.1; といったネイティブのツールは、 + システムに関するかなり多くの情報を与えてくれます。 + 正常な状態がどのような状態であるかを把握しておき、 + 本来と違う状況になった場合には、質問をしたり、 + 疑い深くなってください。 + セキュリティが破られることを避けることは理想ですが、 + 破られたことを把握することは必須です。</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 xml:id="security-ids"> + <title>バイナリ検証</title> + + <para>システムファイルおよびバイナリの検証は、 + システム管理者およびセキュリティチームに対して、 + システムの変更に関する情報を提供してくれるため重要です。 + いかなるシステムにおいても、システム管理チームの知らないところで、 + 内部のコマンドやアプリケーションは変更すべきではありません。 + システムの変更ををモニタリングするソフトウェアアプリケーションは、 + 侵入検知システム (Intrusion Detection System) + または <acronym>IDS</acronym> と呼ばれます。</para> + + <para>&os; は、基本的な + <acronym>IDS</acronym> システムをネイティブで提供しています。 + 実際に、毎晩の &man.periodic.8; セキュリティに関するメールの中では、 + 管理者に変更点を通知します。 + 情報はローカルに保存されているので、 + 悪意のあるユーザが変更し、情報を + <quote>欺く</quote> 可能性があります。 + そのため、バイナリの署名の別のセットを作成して、 + 読み取り専用の root 所有のディレクトリ、できれば、 + <acronym>USB</acronym> ディスクまたは + <application>rsync</application> + サーバといったシステムとは別のシステムに保存してください。</para> + + <para>まず最初に、シードを生成する必要があります。 + これは、数値定数で、ハッシュ値の生成やハッシュ値の検証で使われます。 + このシードがないと、 + ファイルのチェックサムの値を偽ったり検証が可能になります。 + 以下の例では、シードは <option>-s</option> + フラグで指定されています。 + 最初に以下のコマンドを用いて <filename>/bin</filename> + のハッシュ値およびチェックサムを生成してください。</para> + + <screen>&prompt.root; <userinput>mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > bin_chksum_mtree</userinput></screen> + + <para>このコマンドの出力は以下のようになります。</para> + + <screen>&prompt.root; mtree: /bin checksum: 3427012225</screen> + + <para><filename>bin_cksum_mtree</filename> ファイルを見ると、 + 以下のような出力となります。</para> + + <programlisting># user: root +# machine: dreadnaught +# tree: /bin +# date: Mon Feb 3 10:19:53 2014 +# . +/set type=file uid=0 gid=0 mode=0555 nlink=1 flags=none +. type=dir mode=0755 nlink=2 size=1024 \ + time=1380277977.000000000 + \133 nlink=2 size=11704 time=1380277977.000000000 \ + cksum=484492447 \ + sha256digest=6207490fbdb5ed1904441fbfa941279055c3e24d3a4049aeb45094596400662a + cat size=12096 time=1380277975.000000000 cksum=3909216944 \ + sha256digest=65ea347b9418760b247ab10244f47a7ca2a569c9836d77f074e7a306900c1e69 + chflags size=8168 time=1380277975.000000000 cksum=3949425175 \ + sha256digest=c99eb6fc1c92cac335c08be004a0a5b4c24a0c0ef3712017b12c89a978b2dac3 + chio size=18520 time=1380277975.000000000 cksum=2208263309 \ + sha256digest=ddf7c8cb92a58750a675328345560d8cc7fe14fb3ccd3690c34954cbe69fc964 + chmod size=8640 time=1380277975.000000000 cksum=2214429708 \ + sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7</programlisting> + + <para>コンピュータのホスト名、現在の日付と時間、&man.mtree.8; + を実行したユーザの情報すべてがこのレポートには含まれています。 + また、各バイナリに対するチェックサム、サイズ、タイムスタンプおよび + <acronym>SHA</acronym>256 ダイジェストも含まれています。</para> + + <para>バイナリ署名の検証のために、 + 以下のコマンドを実行すると、現在の署名のリストを読み込み、 + 結果を出力します。</para> + + <screen>&prompt.root; <userinput>mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output</userinput></screen> + + <para>このコマンドを実行すると、すでにチェックサムを生成している + <filename>/bin</filename> に対して、同様のチェックサムを生成します。 + このコマンドを実行してから変更が行われていないので、 + <filename>bin_chksum_output</filename> への主力は空となります。 + 変更が行われた場合をシミュレートするために、 + <filename>/bin/cat</filename> ファイルの日付を + &man.touch.1; を使って変更して、 + 再度検証のコマンドを実行してみます。</para> + + <screen>&prompt.root; <userinput>touch /bin/cat</userinput></screen> + <screen>&prompt.root; <userinput>mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output</userinput></screen> + <screen>&prompt.root; <userinput>cat bin_chksum_output</userinput></screen> + <programlisting>cat changed + modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014</programlisting> + + <para><package>security/aide</package> のような、 + より高度な <acronym>IDS</acronym> システムもありますが、 + ほとんどのケースにおいて、 + &man.mtree.8; は管理者が必要とする機能を提供します。 + 悪意のあるユーザが、 + シード値およびチェックサムの出力を見れないようにすることが重要です。</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> + <sect2 xml:id="security-tuning"> + <title>セキュリティのためのシステムの調整</title> + + <para>システムの機能の多くは、&man.sysctl.8; を使って調整できます。 + Denial of Service (<acronym>DOS</acronym>) + スタイルの攻撃を避けるためのセキュリティ機能に対しても同様です。 + この節では、より重要な調整についても触れています。 + &man.sysctl.8; により、設定が変更された時はいつでも、 + 望まない危害が起こる可能性は高まり、 + システムの可用性に影響します。 + システム全体の設定を変更する時には、 + システムの <acronym>CIA</acronym> を考える必要があります。</para> + + <para>以下では、&man.sysctl.8; の一覧、 + および変更がシステムにどのように影響するかを説明します。</para> <para>デフォルトでは、&os; のカーネルはセキュリティレベル -1 で起動します。 @@ -521,477 +511,63 @@ <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> + <warning> + <para><varname>securelevel</varname> を大きくしすぎると、 + <application>Xorg</application> + が動かなくなったり、他の問題が起きる可能性があります。 + デバッグの心づもりをしてください。</para> + </warning> - <sect2> - <title>暗号化機構を理解する</title> - - <para>現在では、ライブラリは <acronym>DES</acronym>, - MD5, Blowfish, SHA256 および - SHA512 ハッシュ関数に対応しています。&os; - がどの暗号化方式を使うようにセットアップされているかを判断するには、 - <filename>/etc/master.passwd</filename> - の暗号化されたパスワードを調べてください。 - MD5 ハッシュで暗号化されたパスワードは、<acronym>DES</acronym> - ハッシュで暗号化されたパスワードよりも長く、 - <literal>$1$</literal> - という文字で始まるという特徴を持っています。 - <literal>$2a$</literal> - で始まるパスワードは、Blowfish ハッシュ関数で暗号化されています。 - <acronym>DES</acronym> - のパスワードはこれといって識別可能な特徴は持っていませんが、 - MD5 のパスワードよりは短く、そして <literal>$</literal> - という文字を含まない 64 - 文字のアルファベットを使って表現されているので、 - 比較的短い文字列でドル記号で始まっていないものはおそらく - <acronym>DES</acronym> のパスワードでしょう。 - SHA256 と SHA512 の場合は、<literal>$6$</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> + <para>つぎに変更を検討すべき &man.sysctl.8; は、 + net.inet.tcp.blackhole および net.inet.udp.blackhole です。 + これらを設定すると、閉じたポートに対して届く + <acronym>SYN</acronym> パケットはドロップされ、 + <acronym>RST</acronym> レスポンスを返しません。 + 通常は、<acronym>RST</acronym> を返し、 + そのポートが閉じられていることを伝えます。 + これにより、システムに対する <quote>ステルス</quote> + スキャンに対し、ある程度の防御となります。 + net.inet.tcp.blackhole を <quote>2</quote>、 + net.inet.udp.blackhole を <quote>1</quote> に設定してください。 + 詳細な情報について &man.blackhole.4; をご覧ください。</para> + + <para>さらに、net.inet.icmp.drop_redirect および + net.inet.ip.redirect も設定すべきです。 + これら 2 つの + &man.sysctl.8; は、リダイレクト攻撃を防ぐ助けとなるでしょう。 + リダイレクト攻撃は、 + 故意に通常のネットワークでは必要としないような大量の + <acronym>ICMP</acronym> タイプ 5 のパケットを発生します。 + そのため net.inet.icmp.drop_redirect を <quote>1</quote>、 + net.inet.ip.redirect を <quote>0</quote> に設定して下さい。</para> + + <para>ソースルーティングは、 + 内部ネットワーク上でルーティングできないアドレスを検出したりアクセスするための方法です。 + 通常ルーティングできないアドレスは、 + 意図してルーティングできないようにしているので、 + この設定はおそらく無効にすべきです。 + この機能を無効にするには、 + net.inet.ip.sourceroute および net.inet.ip.accept_sourceroute + を <quote>0</quote> に設定してください。</para> + + <para>ブロードキャストアドレスに対するすべての + <acronym>ICMP</acronym> エコーリクエストは、ドロップしてください。 + ネットワーク上のコンピュータがサブネットにあるすべてのホストにメッセージを送る必要がある場合には、 + メッセージはブロードキャストアドレスに送られます。 + 外部のホストについては、 + このような送信をする必要はないので、 + 外部からブロードキャストへのリクエストをすべて拒否するように、 + net.inet.icmp.bmcastecho を <quote>0</quote> + に設定してください。</para> + + <para>まだ多くの &man.sysctl.8; が + &man.security.7; で説明されています。 + さらに多くの情報を調べることが推奨されます。</para> + </sect2> </sect1> <sect1 xml:id="one-time-passwords"> @@ -2247,6 +1823,46 @@ kadmind5_server_enable="YES"</programlisting> </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> + + <sect2> <title>リソースおよび他の情報源</title> <indexterm> |