From owner-svn-doc-all@freebsd.org Sat Feb 24 08:08:58 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FFEDF219D3; Sat, 24 Feb 2018 08:08:58 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEFCA74465; Sat, 24 Feb 2018 08:08:57 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A9A5A22CC0; Sat, 24 Feb 2018 08:08:57 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w1O88vuN001814; Sat, 24 Feb 2018 08:08:57 GMT (envelope-from ryusuke@FreeBSD.org) Received: (from ryusuke@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w1O88veh001813; Sat, 24 Feb 2018 08:08:57 GMT (envelope-from ryusuke@FreeBSD.org) Message-Id: <201802240808.w1O88veh001813@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ryusuke set sender to ryusuke@FreeBSD.org using -f From: Ryusuke SUZUKI Date: Sat, 24 Feb 2018 08:08:57 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r51442 - head/ja_JP.eucJP/books/handbook/security X-SVN-Group: doc-head X-SVN-Commit-Author: ryusuke X-SVN-Commit-Paths: head/ja_JP.eucJP/books/handbook/security X-SVN-Commit-Revision: 51442 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 08:08:58 -0000 Author: ryusuke Date: Sat Feb 24 08:08:57 2018 New Revision: 51442 URL: https://svnweb.freebsd.org/changeset/doc/51442 Log: - Merge the following from the English version: r41645 -> r42014 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 Fri Feb 23 21:25:32 2018 (r51441) +++ head/ja_JP.eucJP/books/handbook/security/chapter.xml Sat Feb 24 08:08:57 2018 (r51442) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r41645 + Original revision: r42014 $FreeBSD$ --> @@ -36,26 +36,22 @@ &os; における高度な話題について簡単に説明します。 ここで扱う話題の多くは、 一般的なシステムやインターネットセキュリティにもあてはまります。 - インターネットはもはや、誰もが親切な隣人であろうとする - 友好的な 場ではありません。 - あなたのシステムを安全に保つことは、 - あなたのデータ、知的財産、時間、その他を、 + システムを安全に保つことは、データ、知的財産、時間、その他を、 ハッカーやその同類から守るためには欠かせません。 &os; は、 - システムとネットワークの整合性と安全性を確実にする仕組みと一連のユーティリティを提供しています。 + システムとネットワークの整合性および安全性を保護する仕組みと一連のユーティリティを提供しています。 この章を読むと、以下のことがわかります。 &os; - に関する基本的なシステムセキュリティの考え方 + における基本的なシステムセキュリティの考え方 - DES や MD5 のような、 - &os; で利用できるさまざまな暗号化手法について + &os; で利用できるさまざまな暗号化手法 @@ -63,45 +59,49 @@ - inetd と組み合わせて + &man.inetd.8; と組み合わせて TCP Wrappers を設定する方法 &os; における - Kerberos5 の設定方法 + Kerberos の設定方法 - IPsec および FreeBSD/&windows; コンピュータの間で - VPN の設定方法 + IPsec を設定して VPN を構築する方法 - &os; で使われている SSH である + &os; にける OpenSSH の設定および使用方法 - ファイルシステムの ACL (アクセス制御リスト) - とは何か、またその使用法 + ファイルシステム ACL (アクセス制御リスト) + の使用方法 - Portaudit - ユーティリティを使って、Ports Collection + Ports Collection からインストールされたサードパーティ製ソフトウェア packages - を監査する方法 + を Portaudit + を使って監査する方法 - 公開される &os; セキュリティ勧告の利用方法 + &os; セキュリティ勧告の利用方法 プロセスアカウンティングがどのようなものか、 &os; 上で有効にする方法について + + + リソース制限データベースとは何か、 + この仕組みを使ったユーザ資源の管理方法 + この章を読む前に、次のことが必要になります。 @@ -112,33 +112,26 @@ - + はじめに セキュリティとは、システム管理者をいつも悩ませる仕事の一つです。 - すべての BSD &unix; マルチユーザシステムは、 - 従来からいくつかのセキュリティ機構を備えていますが、 - ユーザを疑心暗鬼に陥らせないように追加のセキュリティ機構を構築し保守する仕事はおそらく、 - システム管理者としてもっとも大きな責務の一つでしょう。 - マシンの安全性に反映されるのは、管理者が作業したことだけです。 - またセキュリティ問題は、快適な環境に必要なものと競合します。 - 一般に &unix; システムは膨大な数のプロセスを同時に動作させることができ、 - そのプロセスの大部分は、サーバ — - 外部から接続し、通信するものとして動作します。 - かつてのミニコンとメインフレームがデスクトップにとってかわり、 - さらにコンピュータが相互に接続されたネットワークを形成するようになった今日、 - セキュリティは一層大きな関心事になってきています。 + &os; は、固有のセキュリティ機構を備えていますが、 + 追加のセキュリティ機構を設定し保守する仕事はおそらく、 + システム管理者としてもっとも大きな責務の一つでしょう。 また、システムセキュリティには、 さまざまな形での攻撃に対処することとも関係しています。 攻撃の中には root - 権限を奪おう (root 権限を破る) とはしないけれども、 + 権限を奪おうとはしないけれども、 クラッシュやシステムの不安定状態を引き起こそうとするものもあります。 このセキュリティ問題は、いくつかに分類することが可能です。 @@ -152,7 +145,7 @@ - アクセス可能なサーバを使った root 権限の不正利用 + アクセス可能なサービスを使った root 権限の不正利用 @@ -177,20 +170,14 @@ サービス妨害 (DoS) - サービス妨害攻撃 (DoS 攻撃) とは、 + サービス妨害攻撃 (DoS 攻撃) とは、 マシンから必要な資源を奪う行為です。 - 通常、サービス妨害攻撃はそのマシンで実行されるサーバや - ネットワークスタックを過負荷状態にしてマシンをクラッシュさせたり、 + 通常、サービス妨害攻撃はそのマシンで実行されるサーバやネットワークスタックを過負荷状態にして、 + マシンをクラッシュさせたり、 マシンを使えなくしたりするような力任せの方法です。 - サービス妨害攻撃の中には、 - ネットワークスタックのバグを利用して、 - パケット一つでマシンをクラッシュさせようとするものもあります。 - 後者には、カーネルにバグ修正を施すことによってのみ対応することができます。 サーバプロセスに対する攻撃は、オプションを適切に指定することによって、 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで対応できる場合が多いです。これらに比べると、 ネットワークへの力任せの攻撃への対応はずっと難しくなります。 - たとえば、偽造パケットによる攻撃 (spoof-packet attack) は、 - インターネットからシステムを切り離す以外の方法で防ぐことはほとんど不可能です。 この攻撃によって、マシンを落としてしまうことはできないかもしれませんが、 接続しているインターネット回線を飽和させてしまうことはできます。 @@ -200,34 +187,22 @@ ユーザアカウントの不正利用は、 - サービス妨害攻撃よりもずっとよくある問題です。 - このご時勢でも、自分たちのマシンで標準の - telnetd, - rlogind, - rshd, - ftpd - サーバを実行させているシステム管理者は多いのです。 - これらのサーバは、デフォルトでは、 - 暗号化されたコネクション上で動作していません。 - その結果、抱えているユーザ数が標準くらいであれば、リモートログイン - (そのシステムにログインするには最も普通で便利な方法です) - しているユーザのうち一人以上は、 - パスワードを覗き見られてしまうでしょう。 + DoS 攻撃よりもずっとよくある問題です。 + このご時勢でも、 + 暗号化されていないサービスを実行させているシステム管理者は多く、 + そのため、リモートからログインしているユーザは、 + パスワードを覗き見られてしまう危険性があります。 システム管理者が注意深い人ならば、 - たとえログインが成功していたとしても、 リモートアクセスログを解析して、 - 疑わしい送信元アドレスを探すものです。 + 疑わしい送信元アドレスや疑わしいログインを探すものです。 - ひとたび攻撃者がユーザアカウントへのアクセス権を入手したら、 - 攻撃者は root - 権限を破れると仮定するべきです。 - しかし、セキュリティを十分維持し、 + セキュリティを十分維持し、 手入れの行き届いたシステムにおいては、 あるユーザアカウントへのアクセスが可能となっても、 必ずしも攻撃者に root - へのアクセス権を与えるとは限りません。この違いは重要です。 - というのは、一般的に - root へのアクセス権がなければ、 + へのアクセス権を与えるとは限りません。 + root + へのアクセス権がなければ、 攻撃者は自分の侵入の痕跡を隠蔽することができませんし、 そのユーザのファイルを引っかき回したり、 マシンをクラッシュさせたりするのがせいぜいです。 @@ -240,38 +215,18 @@ 裏口 (バックドア) - システム管理者は、あるマシン上で - root - 権限を奪取する方法は、 - 潜在的に何通りもあるということを心しておかねばなりません。 + root + 権限を奪取する方法は、潜在的に何通りもあります。 攻撃者は root のパスワードを知っているかもしれませんし、 攻撃者が root - 権限で実行されているサーバのバグを見つけ、 - ネットワーク接続を介して - root - 権限を破ることができるかもしれません。 - また、攻撃者は suid-root プログラムに存在するバグを知っていて、 - ユーザアカウントを破れば - root - 権限を奪取できるかもしれません。 - 攻撃者があるマシン上で - root - 権限を破る方法を知ったならば、 - 攻撃者は裏口を用意する必要がありません。 - これまでに発見され、ふさがれた - root - の穴の多くには、攻撃者が自分のしたことの痕跡を消そうとした作業が、 - かなりの割合で含まれています。 - そのため、ほとんどの攻撃者は裏口を作るのです。裏口は、 - 攻撃者がたやすくシステムへの - root - アクセスを再び得られるようにしますが、 - 有能な管理者に侵入を検知する便利な手段を与えるものでもあります。 - 攻撃者に裏口を作らせないようにするということは、 - セキュリティにとっては実際には良くないことかもしれません。 - なぜなら、 - 攻撃者が最初に見つけて侵入してきたセキュリティホールはふさがれないからです。 + 権限で実行されているサービスのバグの脆弱性を利用できるかもしれません。 + また、攻撃者は SUID-root + プログラムに存在するバグを知っているかもしれません。 + 攻撃者は、 + バックドアとして知られているプログラムを使って脆弱性なシステムを探したり、 + 修正されていない脆弱性を利用してアクセスしたり、 + 攻撃者による違法行為の痕跡を消そうとしたりするかもしれません。 セキュリティを改善する方法は、常に、 タマネギの皮のように階層化する手法 @@ -288,7 +243,7 @@ root の安全性を高める – root 権限で動作するサーバと - suid/sgid バイナリ。 + SUID/SGID バイナリ。 @@ -314,8 +269,7 @@ - 本章の次の節では、 - 上記の各項目についてより深く掘り下げていきます。 + 次の節では、上記の項目についてより深く掘り下げていきます。 @@ -326,60 +280,41 @@ &os; の安全性を高める - - コマンド対プロトコル - - この文書を通して、アプリケーションを指すのには - 太字 を使い、 - コマンドを指す場合には、等幅 フォントを使います。 - プロトコルは通常のフォントで表します。 - このような書体による区別は、 - プロトコルであると同時にコマンドでもある - ssh などに対して有効です。 - - - 以下の節では、本章の この節では、前節 でとりあげた &os; - システムの安全性を高める方法について述べます。 + システムの安全性を高める方法について説明します。 <systemitem class="username">root</systemitem> - アカウントとスタッフアカウントの安全性を高める + アカウントの安全性を高める - su + &man.su.1; - root - のアカウントの安全性を確保しないうちからスタッフのアカウントの安全性をうんぬんしてもしかたがありません。 - ほとんどのシステムでは、root - アカウントに割り当てたパスワードが 1 - つあります。まず最初にすべきことは、 - このパスワードはいつでも不正利用の危険に晒されていると仮定することです。 - これは root - のパスワードを消すべきだと言っているのではありません。 + ほとんどのシステムでは、 root - のパスワードは、マシンにコンソールからアクセスするのには、 + アカウントに割り当てたパスワードが 1 つあります。 + このパスワードはいつでも不正利用の危険に晒されていると考えてください。 + これはパスワードを無効にすべきだと言っているのではありません。 + パスワードは、マシンにコンソールからアクセスするのには、 ほとんどいつでも必要なものです。 - ここで言いたいのは、コンソール以外からは、 - そして可能なら &man.su.1; コマンドを実行する場合も + しかしながら、コンソール以外からは、 + そして可能なら &man.su.1; + コマンドを実行する場合もパスワードを使えないようにするべきです。 + たとえば、/etc/ttys のエントリにおいて、 + 特定のターミナルに対し root - のパスワードを使えないようにするべきである、ということです。 - たとえば、あなたが使っている pty が、 - /etc/ttys ファイルで insecure - と指定されているか確認してください。そうすると、 - telnet や rlogin 経由では + でログインできないように + insecure と設定してください。 + &os; では、デフォルトで、 + /etc/ssh/sshd_config において + PermitRootLogin が no + と設定されているので、&man.ssh.1; を使った root - で直接ログインできないようになります。 - これは、/etc/ssh/sshd_config を編集して - PermitRootLogin に no - が設定されるようにすることで実現できます。 - sshd のような、 - 別のログインサービスを使っている場合でも同様に、直接 - root - へログインすることを許していないかどうか確認してください。 - すべてのアクセス手段 — たとえば FTP - のようなサービスが、良くクラックの対象となることを考えましょう。 + へログインは無効になっています。 + すべてのアクセス手段、たとえば FTP + ようなサービスは、良くクラックの対象となることを理解してください。 root への直接ログインは、 システムコンソール経由でのみ可能であるべきなのです。 @@ -387,57 +322,34 @@ wheel - また当然、システム管理者として自分が + システム管理者は root - になれるようにしておく必要がありますから、 - そのための穴をいくつか開けておきます。 - しかし、それらの穴を動作させるには、 - さらに追加のパスワード認証が必要であるようにしておくことが重要です。 - root - でアクセス可能とする方法の一つとして、適切なスタッフアカウントを - (/etc/group 中の) + になれるようにしておく必要があるので、 + 追加のパスワード認証の設定が必要となります。 + ひとつは、適切なユーザアカウントを + /etc/group 中の + wheel に加える方法です。 wheel - グループに加えることがあります。 - wheel - グループに入っているスタッフメンバは - su を使って + のメンバは、&man.su.1; を使って root になることが許されます。 - パスワードエントリにおいて、スタッフメンバを - wheel - グループに置くことによって直接 - wheel - 権限を与えてはいけません。スタッフメンバのアカウントは - staff - グループに所属させるべきで、その上で - /etc/group ファイルを通して - wheel - グループに加えるべきです。実際に + 実際に root - アクセスの必要なスタッフメンバのみ + アクセスの必要なユーザのみ wheel - グループに置くようにすべきです。 - 他の認証方法の場合、たとえば Kerberos を使用する場合には、 - root アカウントの - Kerberos .k5login ファイルを使えば、誰も - wheel グループに置く必要なく - root に &man.ksu.1; - することを許可できます。 - このやり方はよりよい解決策なのかもしれません。なぜなら、 - wheel のメカニズムでは、 - 侵入者がパスワードファイルを手に入れ、スタッフアカウントのいずれか - 1 つを破ることができると、 + に置くようにすべきです。 + Kerberos を使用して認証行う場合には、 root - を破ることがまだできてしまうからです。 - wheel - のメカニズムを用いる方が、何もしないよりは良いのですが、 - 必ずしも最も安全な選択肢とは限りません。 + のホームディレクトリに .k5login + を作成することで、 + 誰も wheel に置く必要なく + &man.ksu.1; することを許可できます。 アカウントを完全にロックするには、 - &man.pw.8; コマンドを使うべきです。 + &man.pw.8; を使ってください。 &prompt.root; pw lock staff - これにより、ユーザは、&man.ssh.1; + これにより、指定されたユーザは、&man.ssh.1; を含むいかなる方法でもログインできなくなります。 アカウントへのアクセスをブロックするもう一つの方法は、 @@ -445,16 +357,16 @@ * 1 文字に置き換えることです。 この文字は、暗号化されたパスワードにマッチすることはないので、 ユーザアクセスをブロックします。 - たとえば、次のスタッフアカウントを、 + たとえば、次のアカウントのエントリを、 foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - こう変更します。 + &man.vipw.8; を使って以下のように変更します。 foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh この変更によって - foobar ユーザは、 + foobar は、 通常のログインはできなくなります。 このようなアクセス制限をした後は、 サイトで Kerberos をセットアップしたり、 @@ -463,34 +375,24 @@ これらのセキュリティの仕組みでは、 制限の強いサーバから制限の弱いサーバへログインすることを前提としています。 - たとえば、メインマシンで、様々な種類のサーバを実行させている場合、 - ワークステーションではそれらのサーバを実行させてはなりません。 + たとえば、サーバがネットワークサービスを実行させている場合、 + ワークステーションではそれらのサービスを実行させてはなりません。 ワークステーションを十分に安全にしておくためには、 - 実行するサーバの数を、 - 一つもサーバが実行されていないというくらいにまでできる限り減らすべきです。 - また、パスワードで保護されたスクリーンセーバを走らせておくべきです。 - ワークステーションへの物理的アクセスが与えられたとすると、 + 実行するサービスをゼロにするか、可能な限り減らし、 + パスワードで保護されたスクリーンセーバを走らせておくべきです。 + システムへの物理的アクセスが与えられたとすると、 もちろん言うまでもなく、 - 攻撃者は管理者が設定したいかなる種類のセキュリティをもうち破ることができるのです。 - このことは、管理者として必ず考えておかねばならない問題ですが、 - システム破りの大多数は、ネットワーク経由でリモートから、 - ワークステーションやサーバへの物理的アクセス手段を持たない人々によって行われるという事実もまた、 - 念頭に置いておく必要があります。 + 攻撃者はいかなる種類のセキュリティをもうち破ることができるのです。 + 幸いにも、システム破りの大多数は、ネットワーク経由でリモートから、 + システムへの物理的アクセス手段を持たない人々によって行われています。 - Kerberos のような方法を使うことで、 - スタッフアカウントのパスワードの変更もしくは停止を一箇所で行なうことと、 - スタッフメンバがアカウントを持つすべてのマシンに即時にその効果を及ぼすことが可能となります。 - スタッフメンバのアカウントが危険に晒されたときに、 - すべてのマシンでスタッフメンバのパスワードを即座に変更する能力を過小評価してはいけません。 - パスワードが分散されている状況では、 - N 台のマシンでパスワードを変更すると、 - てんやわんやの事態を招く可能性があります。 - Kerberos を使用すると、パスワードの再発行に制限 - (re-passwording restriction) を課することもできます。 - この機能を使うことにより、ある Kerberos - チケットをしばらく経つとタイムアウトにすることができるだけでなく、 - 一定期間 (例えば、1 ヶ月に 1 回) 経つと、 - ユーザに新しいパスワードを選ぶように要求することもできます。 + Kerberos を使うことで、 + ユーザのパスワードの変更もしくは停止を一箇所で行なうことと、 + ユーザがアカウントを持つすべてのマシンに即時にその効果を及ぼすことが可能となります。 + アカウントが危険に晒されたときに、 + すべてのマシン上の関連するパスワードを即座に変更する能力を過小評価してはいけません。 + Kerberos では、Kerberos チケットにタイムアウトを設定でき、 + 設定した期間が経過するとユーザに新しいパスワードを選ぶように要求するといった追加の制限を課することができます。 @@ -498,134 +400,43 @@ SUID/SGID バイナリの安全性を高める - ntalk - - - comsat - - - finger - - 砂場 (sandbox) - sshd + &man.sshd.8; - - telnetd - - - rshd - - - rlogind - - 用心深いシステム管理者は、 - 自分に必要なサーバプロセスだけを過不足なく実行させるものです。 + 用心深いシステム管理者は、必要なサービスだけを有効にし、 サードパーティ製のサーバは、 - よくバグを持っていがちだということに注意して下さい。 - たとえば、古いバージョンの - imapd や - popper - を実行させておくのは、全世界に万能の + よくバグを持っていがちだということに注意しているものです。 + 注意深くチェックしていないサーバは、決して実行してはいけません。 + 多くのデーモンは、サービス専用のアカウント、もしくは + 砂場 (sandbox) で起動させることができるので、 root - の切符を与えているようなものです。 - 自分で注意深くチェックしていないサーバは、 - 決して実行してはいけません。 - root - で実行させる必要のあるサーバはほとんどありません。たとえば、 - ntalk, - comsat, - finger デーモンを、 - 専用ユーザの 砂場 (sandbox) - で実行させることができます。 - 管理者が膨大な数の問題を経験していないのなら、 - この「砂場」は完璧ではありませんが、 - セキュリティに関するタマネギ的アプローチはここでも成り立ちます。 - 砂場で実行されているサーバプロセスを経由して侵入を果たすことができたとしても、 - 攻撃者はさらに砂場から外に脱出しなければなりません。 - 攻撃者が通過せねばならない層の数が増えれば増えるほど、 - それだけ攻撃者が侵入に成功する確率が減ります。 - Root の抜け穴は歴史的に、基本システムサーバも含め、 - root - 権限で実行されるほとんどすべてのサーバプロセスで発見されています。 - ユーザが sshd 経由でのみログインし、 - telnetd, - rshd, - rlogind - 経由でログインすることが決してないマシンを稼働させているのであれば、 - それらのサービスを停止させて下さい! + 権限でサービスを実行する前には、よく考えてください。 + &man.telnetd.8; または &man.rlogind.8; + のような安全ではないサービスは有効にしないでください。 - &os; では、今では - ntalkd, - comsat, - finger - は砂場で実行させることがデフォルトになっています。 - 次に砂場で実行させるべきプログラムの候補として、 - &man.named.8; があります。 - /etc/defaults/rc.conf ファイルには、 - named - を砂場で実行するために必要な引数がコメントアウトされた形式で含まれています。 - 新しいシステムをインストールしているか、 - それとも既存のシステムをアップグレードして使っているかに依存しますが、 - 砂場として使用する特別のユーザアカウントがインストールされていないかもしれません。 - 用心深いシステム管理者であれば、できるだけいつでも研究を怠らず、 - サーバに砂場を仕込むものでしょう。 - - - sendmail - - - 通常、砂場で実行しないサーバが他にいくつかあります。 - sendmail, - popper, - imapd, - ftpd などです。 - これらのうちいくつかのサーバには代わりとなるものがありますが、 - 代わりのものをインストールするには、 - あなたが思うより多くの仕事が必要になるかもしれません - (便利さという要素がまたも勝利を収めるわけです)。 - これらのサーバは、root - 権限で実行しなければばならないかもしれません。また、 - これらのサーバ経由で生じる侵入を検出するためには、 - 他の仕組みに頼らなくてはならないかもしれません。 - - システムの root - 権限の潜在的な穴で他に大きなものには、 - システムにインストールされた suid-root/sgid バイナリがあります。 + 他のシステムの潜在的なセキュリティホールには、 + SUID-root および SGID バイナリがあります。 これらのバイナリは、 - rlogin のように、/bin, /sbin, /usr/bin または /usr/sbin に存在するものがほとんどです。 100% 安全なものは存在しないとはいえ、 - システムデフォルトの siud/sgid バイナリは比較的安全といえます。 - それでもなお、root - セキュリティホールがこれらのバイナリにときおり発見されています。 - 1998 年に xterm - (普通、suid 設定されています) を脆弱にしていた - Xlib の - root - セキュリティホールが見つかりました。 - 安全である方がよいので、 - 用心深いシステム管理者は残念に思いながらも、 - スタッフのみが実行する必要がある suid バイナリは、 - スタッフのみがアクセス可能な特別なグループに含めるように制限を加え、 - 誰も使わない suid バイナリは - (chmod 000 を実行して) 片付けてしまうでしょう。 - ディスプレイを持たないサーバは、一般的に - xterm のバイナリを必要としません。 - sgid バイナリもほとんど同様の危険な存在になり得ます。 - 侵入者が kmem に sgid されたバイナリを破ることができた場合、 + システムデフォルトの SUID/SGID バイナリは比較的安全といえます。 + SUID バイナリは、 + スタッフのみがアクセス可能な特別なグループに制限し、 + 使わない SUID バイナリは削除することが推奨されます。 + SGID バイナリもほとんど同様の危険な存在になり得ます。 + 侵入者が kmem に SGID されたバイナリを破ることができた場合、 その侵入者は /dev/kmem を読み出すことができるようになるでしょう。つまり、 暗号化されたパスワードファイルを読み出すことができるようになるので、 - パスワードを持つどのアカウントをも、 - 潜在的な危険に晒すことになります。他にも、 + ユーザアカウントを、潜在的な危険に晒すことになります。他にも、 kmem グループを破った侵入者が pty を通して送られたキーストロークを監視できるという危険があります。 キーストロークには、安全な方法でログインするユーザが使っている pty @@ -642,16 +453,10 @@ ユーザアカウントの安全性を高める ユーザアカウントは、普通、安全性を高めることが最も困難です。 - スタッフに対しては、とても厳格なアクセス制限を強制しパスワードを - アスタリスク で外すことができるでしょうが、 - 管理者が持ちうる一般ユーザすべてのアカウントに対して同じことはできないかもしれません。 - 管理者が十分に統率をとることができるなら、管理者は勝利し、 - ユーザのアカウントの安全を適切に確保できるかもしれません。 - それができないならば、 - よりいっそう気を配って一般ユーザのアカウントを監視するよりほかありません。 - 一般ユーザアカウントに対し ssh や Kerberos を利用することには、 - システム管理がさらに増えたりテクニカルサポートが必要になるなどの問題があります。 - それでも、暗号化パスワードファイルと比較するとはるかに良い解です。 + 気を配ってユーザアカウントを監視するよりほかありません。 + ユーザアカウントに対し &man.ssh.1; や Kerberos を利用するには、 + システム管理がさらに増えたりテクニカルサポートが必要になりますが、 + 暗号化パスワードファイルと比較するとはるかに良い方法を提供します。 @@ -659,7 +464,7 @@ できるだけ多くのパスワードをアスタリスクで外し、 それらのアカウントのアクセスには - ssh や Kerberos を使うようにすることが、唯一の確実な方法です。 + &man.ssh.1; や Kerberos を使うようにすることが、唯一の確実な方法です。 暗号化パスワードファイル (/etc/spwd.db) は root @@ -667,90 +472,79 @@ たとえ、侵入者が root の書き込み権限は得られなくとも、 読み出しアクセス権限を得ることは可能かもしれません。 - セキュリティスクリプトで常にパスワードファイルの変更をチェッ - クし、報告するようにすべきです (ファイルの完全性のチェック - 節参照)。 + 節で説明されているように、 + セキュリティスクリプトでパスワードファイルの変更をチェックし、 + 報告するようにすべきです。 - カーネルのコア、raw デバイス、ファイルシステムの安全性を - 高める + カーネルのコア、raw デバイス、 + ファイルシステムの安全性を高める - root - の権限を破ると、攻撃者はほとんど何でもできますが、 - 特に重宝される特定の事柄もいくつかあります。 - たとえば、最近のカーネルは、組み込みのパケット覗き見デバイス + 最近のカーネルは、組み込みのパケット覗き見デバイス (packet sniffing device) ドライバを備えているものがほとんどです。 - &os; では bpf デバイスと呼ばれています。 - 侵入者は普通、 - 侵入済みのマシンでパケット覗き見プログラムを実行させようと試みます。 - 侵入者にわざわざそういう機能を提供する必要はないので、 - ほとんどのシステムで bpf - デバイスを組み込むべきではありません。 + &os; では bpf と呼ばれています。 + このデバイスは DHCP で必要となるため、 + DHCP を提供したり使う必要のないシステムでは、 + カスタムカーネルコンフィグレーションファイルから外すことができます。 - sysctl + &man.sysctl.8; - bpf デバイスを外しても、 - /dev/mem と - /dev/kmem - という悩みの種がまだ残っています。この問題に関しては、侵入者は - raw ディスクデバイスに書き込 - むこともできます。ほかにも、モジュールローダ、&man.kldload.8; - という、別のカーネル機能があります。やる気まんまんの侵入者は、KLD - モジュールを使って自分独自の bpf - もしくはその他覗き見デバイスを動作中のカーネルにインストールできます。 - この問題を避けるため、 - システム管理者はカーネルをより高いセキュアレベル、 - 少なくともセキュアレベル 1 で実行させる必要があります。 + bpf を外しても、 + /dev/mem および + /dev/kmem という問題がまだ残っています。 + 侵入者は raw ディスクデバイスに書き込むこともできます。 + やる気まんまんの侵入者は、&man.kldload.8; + を使って自分独自の bpf、 + もしくは他の覗き見デバイスを動作中のカーネルにインストールできます。 + この問題を避けるため、カーネルをより高いセキュリティレベル、 + 少なくともセキュリティレベル 1 で実行させる必要があります。 - カーネルのセキュアレベルはいくつかの方法で設定できます。 - 現在動いているカーネルのセキュアレベルを高める最も簡単な方法は、 - sysctl を使って - kern.securelevel - カーネル変数を操作する方法です。 + カーネルのセキュリティレベルはいくつかの方法で設定できます。 + 現在動いているカーネルのセキュリティレベルを高める最も簡単な方法は、 + kern.securelevel を設定する方法です。 &prompt.root; sysctl kern.securelevel=1 - デフォルトでは、&os; のカーネルはセキュアレベル -1 で起動します。 + デフォルトでは、&os; のカーネルはセキュリティレベル + -1 で起動します。 + このセキュリティレベルは、 + 変更不可のファイルフラグを外したり、 + すべてのデバイスに対して読み込みおよび書き込みができたりするので、 + insecure mode と呼ばれます。 このセキュアレベルは、管理者または &man.init.8; による起動時のスクリプトにより変更されない限り -1 のままです。 - /etc/rc.conf ファイルで、 - kern_securelevel_enable 変数を - YES、 + /etc/rc.conf において、 + kern_securelevel_enable を + YES とし、 kern_securelevel - 変数を必要とする値に設定することで、 + に必要とする値を設定することで、 システム起動時にセキュアレベルを高めることができます。 - &os; - システムの起動スクリプト実行直後のデフォルトのセキュアレベルは - -1 です。 - このセキュアレベルでは、 - 変更不可のファイルフラグを外したり、 - すべてのデバイスに対して読み込みおよび書き込みができたりするので、 - insecure mode と呼ばれます。 - - セキュアレベルを 1 以上に設定すると、 + セキュリティレベルを 1 以上に設定すると、 追加専用および変更不可ファイルのフラグを外すことはできなくなり、 また raw デバイスへのアクセスが拒否されます。 より高いレベルに設定すると、より多くの操作に制限がかかります。 - 各セキュアレベルの完全な説明については、 - &man.security.7; マニュアルページをご覧ください。 + 各セキュリティレベルの完全な説明については、 + &man.security.7; および &man.init.8; をご覧ください。 - セキュアレベルを 1 以上に設定した場合には、 - X11 (/dev/io へのアクセスがブロックされます) - やソースから &os; を構築してインストールするとき - (installworld のプロセスでは、 - いくつかのファイルの追加専用および変更不可のフラグは一時的にリセットされます) - など、それ以外にも問題が引き起こされる可能性があります。 - X11 の問題については、 + セキュリティレベルを 1 以上に設定した場合には、 + /dev/io へのアクセスがブロックされるため、 + &xorg; や、 + installworld のプロセスでは、 + いくつかのファイルの追加専用および変更不可のフラグは一時的にリセットされるため、 + ソースから &os; + を構築してインストールするときなどで問題が引き起こされる可能性があります。 + &xorg; の問題については、 起動プロセス初期のセキュアレベルが十分低いときに &man.xdm.1; を起動することで、この問題に対応できます。 このような応急処置は、 - すべてのセキュアレベルやそれらが課す潜在的なすべての制限には対応できないでしょう。 + すべてのセキュリティレベルやそれらが課す潜在的なすべての制限には対応できないでしょう。 少し先を見越した計画的な対応をすべきです。 各セキュリティレベルで課される制限は、 システムを使用することによる利便性を著しく減らしてしまうため、 @@ -760,134 +554,122 @@ 設定に関する意外性を少なくできるでしょう。 - カーネルのセキュアレベルを 1 以上に設定した場合には、 + カーネルのセキュリティレベルを 1 以上に設定した場合には、 システム起動に関わる重要なバイナリやディレクトリ、 - スクリプトファイル (すなわち、 - セキュアレベルが設定されるまでの間に実行されるすべてのものに対して)、 + スクリプトファイル、そして、 + セキュリティレベルが設定されるまでの間に実行されるすべてのものに対して、 schg フラグを設定することは有用でしょう。 - この設定をやり過ぎても構いませんが、 - より高いセキュアレベルで動作している場合、 - システムのアップグレードがはるかに困難になります。 - システムをより高い安全レベルで実行させるようにするが、 - すべてのシステムファイルとディレクトリに schg + システムをより高いセキュリティレベルで実行させるようにするが、 + schg フラグを設定しないというところで妥協するという手もあります。 もう一つの可能性としては、単純に / および /usr を読み込み専用でマウントすることです。 ここで特筆すべきことは、システムを守ろうとして厳しくしすぎると、 - 侵入を検出するという非常に重要なことができなくなってしまうということです。 + 侵入を検出することができなくなってしまうということです。 - ファイルの完全性のチェック: バイナリ、 - 設定ファイルなど + ファイルの完全性のチェック - ことこの問題に至ると、システム管理者にできることは、 + システム管理者にできることは、 便利さという要素がその醜い頭を上げない程度に、 コアシステムの設定と制御ファイルを防御することだけです。 たとえば、/ および /usr にある大部分のファイルに schg - ビットを設定するために chflags + ビットを設定するために &man.chflags.1; を使用するのは、おそらく逆効果でしょう。 なぜなら、そうすることでファイルは保護できますが、 侵入を検出する窓を閉ざしてしまうことにもなるからです。 - セキュリティのタマネギの最後の層はおそらく最も重要なもの - — 検出です。 - セキュリティの残りのものは、突然の侵入を検出できなければ、 - まったく有用ではありません - (あるいは、もっと悪ければ、 - 安全性に対する間違った感覚を植え付けてしまいます)。 - タマネギの仕事の半分は、 + セキュリティ対策は、 + 侵入の可能性を検出できなければ、有用ではなく、 + もっと悪ければ、安全性に対する間違った感覚を植え付けてしまいます。 + セキュリティに対する仕事の半分は、 攻撃者を攻撃の最中に捕えるようにするために、 攻撃者を食い止めるのではなく侵入を遅らせることなのです。 侵入を検出する最も良い方法は、変更されていたり、 消えていたり、入れた覚えがないのに入っているファイルを探すことです。 変更されたファイルを探すのに最も良い方法は、もう一つの - (しばしば中央に集められた)、 + しばしば中央に集められた、 アクセスが制限されたシステムから行なうものです。 さらに安全でアクセス制限されたシステム上でセキュリティ用スクリプトを書けば、 スクリプトは潜在的な攻撃者からはほぼ見えなくなります。 - これは重要なことです。 - この有効性を最大限に活用するためには、一般的に、 - アクセスの制限されたマシンから実際に使っている他のマシンへのかなりのアクセスを許可する必要があります。 - 普通は、他のマシンからアクセス制限されたマシンへ読み込み専用の - NFS エクスポートをしたり、アクセス制限されたマシンから他のマシンへ - ssh 接続を行なうために、 - ssh 鍵のペアを作ったりすることで行います。 + この有効性を最大限に活用するためには、 + アクセスの制限されたマシンから他のマシンへのかなりのアクセスを許可する必要があります。 + 普通は、読み込み専用の NFS エクスポートをしたり、 + &man.ssh.1; 鍵のペアを設定したりします。 ネットワークのトラフィックを別にして、 - NFS は最も可視性のない方法です — - 各クライアント上のファイルシステムを、 + NFS は最も可視性のない方法です。 + 管理者は、各クライアント上のファイルシステムを、 事実上検出されずに監視できるようになります。 アクセス制限されたサーバがスイッチを通してクライアントに接続されている場合、 - たいてい NFS がより良い選択肢です。 - アクセス制限されたサーバがハブや、 + たいてい NFS がより良い選択肢です。 + アクセス制限されたサーバが、 いくつかのルーティング層を通してクライアントに接続している場合、 - NFS は (ネットワークの面で) あまりにも危険なので、 - ssh の方が認証を行った跡は残りますが、良い方法でしょう。 + NFS はあまりにも危険なので、 + &man.ssh.1; の方が良い方法でしょう。 アクセス制限されたマシンに、 監視しようとするクライアントシステムへの少なくとも読み込みのアクセス権を与えたら、 - 次に実際に監視するためのスクリプトを書かなくてはいけません。 - NFS マウントをすれば、&man.find.1; や &man.md5.1; + 次に監視するためのスクリプトを書かなくてはいけません。 + NFS マウントをすれば、&man.find.1; や &man.md5.1; などの単純なシステムユーティリティでスクリプトを書くことができます。 - 少なくとも 1 日 1 回、クライアントのファイルを直接 md5 にかけ、 + 少なくとも 1 日 1 回、クライアントのシステムファイルを直接 + &man.md5.1; にかけ、 さらにもっと頻繁に /etc および /usr/local/etc にあるようなコントロール用ファイルを試験するのが一番です。 アクセス制限されたマシンが正しいと知っている、 基となる md5 情報と比べて違いが見つかった場合、 - システム管理者に調べて欲しいと悲鳴を上げるようにすべきです。 + システム管理者に警告するようにすべきです。 優れたセキュリティ用スクリプトは、/ および /usr などのシステムパーティション上で不適当に - suid されたバイナリや、 + SUID されたバイナリや、 新たに作成されたファイルや削除されたファイルがないかどうかを調べるでしょう。 - NFS ではなく、ssh を使用する場合は、 - セキュリティ用スクリプトを書くのはずっと難しいことです。 - スクリプトを動かすためには、クライアントに対してスクリプトを - scp しなくてはいけませんし、 - それは目に見えてしまいます。 - そして、安全のためには、スクリプトが使うバイナリ (find など) を - scp する必要もあります。 - クライアントマシンの ssh + NFS ではなく、&man.ssh.1; を使用する場合は、 + セキュリティ用スクリプトを書くのはより難しいことです。 + たとえば、スクリプトを動かすためには、クライアントに対してスクリプトを + &man.scp.1; しなくてはいけませんし、 + クライアントマシンの &man.ssh.1; クライアントはすでに攻撃されてしまっているかもしれません。 - 結局のところ、安全でないリンク上の場合は - ssh は必要かもしれませんが、ssh - を扱うのはとても大変なことです。 + 安全でないリンク上の場合は + &man.ssh.1; は必要かもしれませんが、 + 扱いはとても大変になります。 優れたセキュリティ用スクリプトは、 - ユーザやスタッフメンバのアクセス設定ファイルの変更もチェックするものです。 - .rhosts, .shosts, - .ssh/authorized_keys など MD5 + .rhosts, + .ssh/authorized_keys + などの隠し設定ファイルの変更もチェックするものです。 + これらは MD5 チェックの範囲外になってしまうであろうファイル群です。 - ユーザ用のディスク容量が非常に大きい場合は、パーティション - 上の各ファイルを見て回るのに大変な時間がかかるかもしれません。 - この場合は、マウントフラグを設定して、 - suid されたバイナリを置けないようにするのが良い考えです。 *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***