From owner-svn-doc-all@freebsd.org Sun Nov 29 01:57:07 2020 Return-Path: Delivered-To: svn-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 681C1472D99; Sun, 29 Nov 2020 01:57:07 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CkBLq1llYz3K4d; Sun, 29 Nov 2020 01:57:07 +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 24096151F; Sun, 29 Nov 2020 01:57:07 +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 0AT1v7FM018540; Sun, 29 Nov 2020 01:57:07 GMT (envelope-from ryusuke@FreeBSD.org) Received: (from ryusuke@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 0AT1v73O018539; Sun, 29 Nov 2020 01:57:07 GMT (envelope-from ryusuke@FreeBSD.org) Message-Id: <202011290157.0AT1v73O018539@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ryusuke set sender to ryusuke@FreeBSD.org using -f From: Ryusuke SUZUKI Date: Sun, 29 Nov 2020 01:57:07 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r54718 - 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: 54718 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.34 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: Sun, 29 Nov 2020 01:57:07 -0000 Author: ryusuke Date: Sun Nov 29 01:57:06 2020 New Revision: 54718 URL: https://svnweb.freebsd.org/changeset/doc/54718 Log: - Merge the following from the English version: r43278 -> r43744 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 Sat Nov 28 06:38:37 2020 (r54717) +++ head/ja_JP.eucJP/books/handbook/security/chapter.xml Sun Nov 29 01:57:06 2020 (r54718) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r43278 + Original revision: r43744 $FreeBSD$ --> @@ -14,33 +14,33 @@ - Matthew - Dillon + Tom + Rhodes - 本章の基にした security(7) マニュアルページの執筆: + 寄稿: セキュリティ - 訳: &a.jp.hino;、(jpman - プロジェクトの成果を利用させていただきました)。 + この章では - この章では、基本的なシステムセキュリティの考え方、 - 覚えておくべき一般的なルールを紹介し、 - &os; における高度な話題について簡単に説明します。 - ここで扱う話題の多くは、 - 一般的なシステムやインターネットセキュリティにもあてはまります。 - システムを安全に保つことは、データ、知的財産、時間、その他を、 - ハッカーやその同類から守るためには欠かせません。 + 物理的もしくは仮想的に関わらず、 + セキュリティは幅広いトピックであり、 + 業界全体がセキュリティとともに成長しています。 + システムおよびネットワークを安全にする標準的な方法は数多く文書化されており、 + &os; のユーザも、 + 攻撃や侵入者から守る方法を理解しなければなりません。 - &os; は、 - システムとネットワークの整合性および安全性を保護する仕組みと一連のユーティリティを提供しています。 + この章では、セキュリティの基礎や技術について説明します。 + &os; システムは、複数のレイヤに関連するセキュリティを提供します。 + そして、安全性を高めるためにサードパーティ製のユーティリティを利用することもできます。 この章を読むと、以下のことがわかります。 @@ -123,391 +123,381 @@ はじめに - セキュリティとは、システム管理者をいつも悩ませる仕事の一つです。 - &os; は、固有のセキュリティ機構を備えていますが、 - 追加のセキュリティ機構を設定し保守する仕事はおそらく、 - システム管理者としてもっとも大きな責務の一つでしょう。 + セキュリティを高めることはすべての人の責任です。 + システムに弱い侵入ポイントが存在すると、侵入者は重要な情報を得たり、 + ネットワーク全体に被害を及ぼすことができるようになります。 + 多くのセキュリティのトレーニングでは、 + 情報システムの機密性 (confidentiality)、 + 完全性 (integrity) および可用性 (availability) + を意味するセキュリティの 3 要素である + CIA が取り扱われます。 - また、システムセキュリティには、 - さまざまな形での攻撃に対処することとも関係しています。 - 攻撃の中には root - 権限を奪おうとはしないけれども、 - クラッシュやシステムの不安定状態を引き起こそうとするものもあります。 - このセキュリティ問題は、いくつかに分類することが可能です。 + CIA の 3 要素は、 + コンピュータセキュリティの基本となる考えです。 + 顧客やエンドユーザは、データのプライバシーを期待します。 + 彼らは、データが変更されないことや、 + 情報が隠されていることを期待します。 + 彼らはまた、いつでも情報にアクセスできることを期待します。 + これらは、システムの機密性、完全性、可用性を構成します。 - - - サービス妨害攻撃 (denial of service attack) - + セキュリティのプロフェッショナルは、CIA + を守るために、多層防衛の戦略を採用します。 + この多層防衛戦略ではセキュリティのレイアを複数用意することで、 + 一つのレイヤが破られても、 + セキュリティシステム全体が破られることを防ぎます。 + システムの管理者は、ファイアウォールを単に有効にするだけではなく、 + ネットワークもしくはシステムを安全に保つ必要があります。 + アカウントを監査し、バイナリの完全性、 + 悪意のあるツールがインストールされていないことを確認する必要があります。 + このために、 + 管理者は脅威がどのようなものかを理解する必要があります。 - - ユーザアカウントの不正利用 (user account compromise) - + + 脅威 - - アクセス可能なサービスを使った root 権限の不正利用 - + コンピュータセキュリティおける脅威とは何でしょうか？ + 長年、脅威はリモートの攻撃者、 + すなわち遠隔からの許可のないシステムへのアクセスを企てる人々と考えられていました。 + 今日では、この定義は従業員、悪意のあるソフトウェア、 + 不正なネットワークデバイス、自然災害、セキュリティの脆弱性、 + そして競合する会社でさえも含めるように拡張されています。 - - ユーザアカウントを経由した root 権限の不正使用 - + 毎日、数千ものシステムおよびネットワークが攻撃され、 + 数百ものシステムが許可なくアクセスされています。 + 簡単なアクシデントといったものから、リモートからの攻撃、 + 産業スパイであったり、以前働いていた従業員からの攻撃といったケースもあります。 + システムのユーザとしては、 + 間違いがセキュリティ違反に繋がった場合には、 + 可能性のある問題をセキュリティチームに報告することが重要です。 + 管理者としては、脅威を把握し、 + その脅威の影響を小さくするように準備をしておくことが重要です。 + - - バックドアの設置 - - + + ボトムアップアプローチ - - DoS 攻撃 - サービス妨害 (DoS) - + セキュリティを考える上で、 + しばしばボトムアップアプローチが一番良い方法となります。 + この考えでは、管理者が基本的なアカウント、システム設定を行ってから、 + サードパーティ製ユーティリティの設定、 + そしてネットワークレイヤに設定を広げていきます。 + システムポリシーおよび手続きを行う上では、 + このような設定の側面があります。 - - セキュリティ - DoS 攻撃 - サービス妨害 (DoS) - + ビジネスの多くの環境では、 + 使用するデバイスの設定に対するセキュリティポリシがすでに策定されています。 + このポリシには、最低限エンドユーザのワークステーション、 + デスクトップ、携帯電話やラップトップといったモバイルデバイス、および + 製品および開発サーバの両方に対するセキュリティの設定が含まれているべきです。 + 多くの場合には、コンピュータのセキュリティを考える際に、 + 標準作業手続書 (SOP) + がすでに存在します。 + わからなければ、セキュリティチームに尋ねてください。 + - サービス妨害 (DoS) + + システムおよびユーザアカウント - サービス妨害攻撃 (DoS 攻撃) とは、 - マシンから必要な資源を奪う行為です。 - 通常、サービス妨害攻撃はそのマシンで実行されるサーバやネットワークスタックを過負荷状態にして、 - マシンをクラッシュさせたり、 - マシンを使えなくしたりするような力任せの方法です。 - サーバプロセスに対する攻撃は、オプションを適切に指定することによって、 - 攻撃されている状況でサーバプロセスの負荷上昇に限界を設定することで対応できる場合が多いです。これらに比べると、 - ネットワークへの力任せの攻撃への対応はずっと難しくなります。 - この攻撃によって、マシンを落としてしまうことはできないかもしれませんが、 - 接続しているインターネット回線を飽和させてしまうことはできます。 + システムを安全にするにあたり、最も適切な出発点は、 + アカウントの監査です。 + ルートアカウントのパスワードが強力であること、 + シェルアクセスを必要としないアカウントは無効にすることを確実におこなってください。 + また、権限を必要とするユーザに対しては、 + security/sudo をインストールして、 + アクセスが必要となるアプリケーションのみにアクセスを許可するようにしてください。 + root ユーザのパスワードは、決して共有すべきではありません。 - - セキュリティ - アカウント不正利用 - + アカウントへのアクセスを無効にする方法は二通りあります。 + 一つ目の方法は、アカウントをロックする方法です。例として、 + toor アカウントをロックする方法を以下に示します。 - ユーザアカウントの不正利用は、 - DoS 攻撃よりもずっとよくある問題です。 - このご時勢でも、 - 暗号化されていないサービスを実行させているシステム管理者は多く、 - そのため、リモートからログインしているユーザは、 - パスワードを覗き見られてしまう危険性があります。 - システム管理者が注意深い人ならば、 - リモートアクセスログを解析して、 - 疑わしい送信元アドレスや疑わしいログインを探すものです。 + &prompt.root; pw lock toor - セキュリティを十分維持し、 - 手入れの行き届いたシステムにおいては、 - あるユーザアカウントへのアクセスが可能となっても、 - 必ずしも攻撃者に root - へのアクセス権を与えるとは限りません。 - root - へのアクセス権がなければ、 - 攻撃者は自分の侵入の痕跡を隠蔽することができませんし、 - そのユーザのファイルを引っかき回したり、 - マシンをクラッシュさせたりするのがせいぜいです。 - ユーザアカウントの不正利用はめずらしいことではありません。 - なぜなら一般ユーザは、 - システム管理者ほど注意を払わない傾向があるからです。 + このコマンドは、アカウントの設定を + toor:*:0:0::0:0:Bourne-again Superuser:/root: + から toor:*LOCKED**:0:0::0:0:Bourne-again + Superuser:/root: へと変更します。 - - セキュリティ - 裏口 (バックドア) - + ときには (おそらく追加のサービスのために)、 + この方法が使えない場合があります。 + そのような場合には、以下の例のように、 + シェルを /sbin/nologin に変更することで、 + ログインアクセスを拒否できます。 - root - 権限を奪取する方法は、潜在的に何通りもあります。 - 攻撃者は root - のパスワードを知っているかもしれませんし、 - 攻撃者が root - 権限で実行されているサービスのバグの脆弱性を利用できるかもしれません。 - また、攻撃者は SUID-root - プログラムに存在するバグを知っているかもしれません。 - 攻撃者は、 - バックドアとして知られているプログラムを使って脆弱性なシステムを探したり、 - 修正されていない脆弱性を利用してアクセスしたり、 - 攻撃者による違法行為の痕跡を消そうとしたりするかもしれません。 + &prompt.root; chsh -s /usr/sbin/nologin toor - セキュリティを改善する方法は、常に、 - タマネギの皮のように階層化する手法 - (a multi-layered onion peel approach) - で実装されるべきです。これらは次のように分類できます。 + + 他のユーザのシェルは、スーパーユーザのみが変更できます。 + 通常のユーザが行おうとすると失敗します。 + - - - root - とスタッフのアカウントの安全性を高める。 - + アカウント情報は、以下のように最後のエントリが + nologin シェルとなります。 - - root - の安全性を高める – root 権限で動作するサーバと - SUID/SGID バイナリ。 - + toor:*:0:0::0:0:Bourne-again Superuser:/root:/usr/sbin/nologin - - ユーザアカウントの安全性を高める。 - + /usr/sbin/nologin シェルは、 + &man.login.1; + コマンドがこのユーザにシェルを割り当てることをブロックします。 + - - パスワードファイルの安全性を高める。 - + + アカウントの権限を拡大する - - カーネルのコア、raw デバイス、 - ファイルシステムの安全性を高める。 - + 場合によっては、 + システム管理者へのアクセスを他のユーザと共有する必要があります。 + &os; はこのために二つの方法を用意しています。 + 第一の方法は推奨されませんが、 + ルートのパスワードを共有し、ユーザを + wheel + グループに加える方法です。 + これを行うにには、/etc/group を編集し、 + 最初のグループの最後にユーザを追加してください。 + ユーザはカンマ区切りで管理されています。 - - システムに対して行なわれた、 - 不適切な変更をすばやく検出する。 - + 権限の拡大をする適切な方法は、 + security/sudo port を使う方法です。 + この port は、追加の監査、よりきめ細かいユーザ管理、および + ユーザを &man.service.8; + のような権限が与えられたコマンのみの実行に制限することもできます。 - - 必要と思われる以上の対応をとる (paranoia)。 - - + インストールが終わったら、 + visudo インタフェースを使って + /usr/local/etc/sudoers + ファイルを編集してください。 + 以下の例では、新しく webadmin グループが作成され、 + trhodes + ユーザがこのグループに追加されます。 + その後、ユーザに apache24 + を再起動するアクセス権限を与えます。 + この手続きは以下のようになります。 - 次の節では、上記の項目についてより深く掘り下げていきます。 - + &prompt.root; pw groupadd webadmin -M trhodes -g 6000 - - &os; の安全性を高める + &prompt.root; visudo - - セキュリティ - &os; の安全性を高める - + %webadmin ALL=(ALL) /usr/sbin/service apache24 * - この節では、前節 でとりあげた &os; - システムの安全性を高める方法について説明します。 + ローカルのユーザ管理において、 + security/sudo は、 + 非常に貴重なリソースを提供します。 + また、パスワードを不必要にして、デフォルトを &man.ssh.1; + 鍵の方法だけにすることもできます。 + &man.sshd.8; 経由のパスワードによるログインを無効にし、 + sudo + へのローカルパスワードのみを使うようにするには、 + をご覧ください。 + - - <systemitem class="username">root</systemitem> - アカウントの安全性を高める + + パスワード - - &man.su.1; - + パスワードは、テクノロジーにおける必要悪です。 + パスワードは極めて複雑であるだけではなく、 + パスワードを保護する強力なハッシュメカニズムもまた必要となります。 + この文書を書いている時点では、 + &os; は crypt() ライブラリで + DES, MD5, Blowfish, + SHA256 および SHA512 + に対応しています。 + デフォルトは SHA512 であり、 + 強度の弱い暗号へは変更すべきではありません。 + しかしながら、Blowfish を好むユーザもおります。 + DES を除く各メカニズムでは、 + 開始の文字、使用しているハッシュメカニズムを識別可能な特徴を持っています。 + MD5 メカニズムでは、シンボルは + $ の符号です。 + SHA256 または、 + SHA512 では、シンボルは $6$、 + そして Blowfish は $2a$ です。 + 暗号強度の弱いパスワードを使用している場合には、 + 次回のログイン時にユーザが + &man.passwd.1; を実行して再ハッシュ化することを促すべきです。 - ほとんどのシステムでは、 - root - アカウントに割り当てたパスワードが 1 つあります。 - このパスワードはいつでも不正利用の危険に晒されていると考えてください。 - これはパスワードを無効にすべきだと言っているのではありません。 - パスワードは、マシンにコンソールからアクセスするのには、 - ほとんどいつでも必要なものです。 - しかしながら、コンソール以外からは、 - そして可能なら &man.su.1; - コマンドを実行する場合もパスワードを使えないようにするべきです。 - たとえば、/etc/ttys のエントリにおいて、 - 特定のターミナルに対し - root - でログインできないように - insecure と設定してください。 - &os; では、デフォルトで、 - /etc/ssh/sshd_config において - PermitRootLogin が no - と設定されているので、&man.ssh.1; を使った - root - へログインは無効になっています。 - すべてのアクセス手段、たとえば FTP - ようなサービスは、良くクラックの対象となることを理解してください。 - root への直接ログインは、 - システムコンソール経由でのみ可能であるべきなのです。 + + この文書を書いている時点で、Blowfish は + AES でなければ、 + FIPS (Federal Information + Processing Standards) に準拠もしていません。 + そのため、使用できない環境があります。 + - - wheel - + ネットワークに接続しているシステムについては、 + 二要素認証を使用すべきです。 + この認証では、通常あなたが所有する要素と知っている要素が用いられます。 + &os; のベースシステムに含まれている + OpenSSH および ssh-keys では、 + ネットワークへのすべてのログインにおける二要素認証の交換で、 + パスワードを使用すべきではありません。 + より詳細な情報については、ハンドブックの + 節をご覧ください。 + Kerberose のユーザは、ネットワークで + OpenSSH + を実装するために追加の変更が必要になるでしょう。 + - システム管理者は - root - になれるようにしておく必要があるので、 - 追加のパスワード認証の設定が必要となります。 - ひとつは、適切なユーザアカウントを - /etc/group 中の - wheel に加える方法です。 - wheel - のメンバは、&man.su.1; を使って - root になることが許されます。 - 実際に - root - アクセスの必要なユーザのみ - wheel - に置くようにすべきです。 - Kerberos を使用して認証行う場合には、 - root - のホームディレクトリに .k5login - を作成することで、 - 誰も wheel に置く必要なく - &man.ksu.1; することを許可できます。 + + バックドアおよびルートキット - アカウントを完全にロックするには、 - &man.pw.8; を使ってください。 + バックドアおよびルートキットは、 + それらがインストールされた後に脅威となります。 + インストールされると、この悪意のあるソフトウェアは、 + 攻撃者のために侵入口を設置します。 + 実際的には、システムが一度汚染された後に、調査が行われ、 + 消去されます。 + 慎重なセキュリティやシステムエンジニアでさえも、 + 攻撃者が残したソフトウェアを見逃してしまうという恐ろしいリスクが存在しています。 - &prompt.root; pw lock staff + バックドアまたはルートキットソフトウェアは、 + 管理者にとって役に立つことが一つあります。 + それは、一度検出すると、 + システムのどこかが危険に冒されていることの痕跡となります。 + しかし、通常この種のアプリケーションは、とてもうまく隠れています。 + バックドアおよびルートキットを検出するツールが存在しており、 + それうちの一つが、 + security/rkhunter です。 - これにより、指定されたユーザは、&man.ssh.1; - を含むいかなる方法でもログインできなくなります。 + インストール後、以下のコマンドでシステムをチェックできます。 + 実行すると多くの情報が出力されます。 - アカウントへのアクセスをブロックするもう一つの方法は、 - 暗号化されたパスワードを - * 1 文字に置き換えることです。 - この文字は、暗号化されたパスワードにマッチすることはないので、 - ユーザアクセスをブロックします。 - たとえば、次のアカウントのエントリを、 + &prompt.root; rkhunter -c - foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + このプロセスを実行中に ENTER + キーを何度か押す必要があります。 + 完了すると、ステータスメッセージが画面に表示されます。 + このメッセージは、チェックしたファイルの量、疑わしいファイルの数、 + 可能性のあるルートキット等の情報を含みます。 + チェックの最中、隠されたファイル、 + OpenSSH プロトコルの選択、そして、 + 時には、インストールされているソフトウェアの漸弱性のバージョンに関する一般的なセキュリティの警告が出力されます。 + すぐに、もしくはより詳細な解析が行われた後に、対応が可能です。 - &man.vipw.8; を使って以下のように変更します。 + 管理者は皆、 + 担当しているシステム上で何が実行されているかを把握している必要があります。 + rkhunter, + lsof や + &man.netstat.1; および &man.ps.1; といったネイティブのツールは、 + システムに関するかなり多くの情報を与えてくれます。 + 正常な状態がどのような状態であるかを把握しておき、 + 本来と違う状況になった場合には、質問をしたり、 + 疑い深くなってください。 + セキュリティが破られることを避けることは理想ですが、 + 破られたことを把握することは必須です。 + - foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + + バイナリ検証 - この変更によって - foobar は、 - 通常のログインはできなくなります。 - このようなアクセス制限をした後は、 - サイトで Kerberos をセットアップしたり、 - ユーザが &man.ssh.1; - の鍵を設定するなどといった認証手段を利用しなければなりません。 + システムファイルおよびバイナリの検証は、 + システム管理者およびセキュリティチームに対して、 + システムの変更に関する情報を提供してくれるため重要です。 + いかなるシステムにおいても、システム管理チームの知らないところで、 + 内部のコマンドやアプリケーションは変更すべきではありません。 + システムの変更ををモニタリングするソフトウェアアプリケーションは、 + 侵入検知システム (Intrusion Detection System) + または IDS と呼ばれます。 - これらのセキュリティの仕組みでは、 - 制限の強いサーバから制限の弱いサーバへログインすることを前提としています。 - たとえば、サーバがネットワークサービスを実行させている場合、 - ワークステーションではそれらのサービスを実行させてはなりません。 - ワークステーションを十分に安全にしておくためには、 - 実行するサービスをゼロにするか、可能な限り減らし、 - パスワードで保護されたスクリーンセーバを走らせておくべきです。 - システムへの物理的アクセスが与えられたとすると、 - もちろん言うまでもなく、 - 攻撃者はいかなる種類のセキュリティをもうち破ることができるのです。 - 幸いにも、システム破りの大多数は、ネットワーク経由でリモートから、 - システムへの物理的アクセス手段を持たない人々によって行われています。 + &os; は、基本的な + IDS システムをネイティブで提供しています。 + 実際に、毎晩の &man.periodic.8; セキュリティに関するメールの中では、 + 管理者に変更点を通知します。 + 情報はローカルに保存されているので、 + 悪意のあるユーザが変更し、情報を + 欺く 可能性があります。 + そのため、バイナリの署名の別のセットを作成して、 + 読み取り専用の root 所有のディレクトリ、できれば、 + USB ディスクまたは + rsync + サーバといったシステムとは別のシステムに保存してください。 - Kerberos を使うことで、 - ユーザのパスワードの変更もしくは停止を一箇所で行なうことと、 - ユーザがアカウントを持つすべてのマシンに即時にその効果を及ぼすことが可能となります。 - アカウントが危険に晒されたときに、 - すべてのマシン上の関連するパスワードを即座に変更する能力を過小評価してはいけません。 - Kerberos では、Kerberos チケットにタイムアウトを設定でき、 - 設定した期間が経過するとユーザに新しいパスワードを選ぶように要求するといった追加の制限を課することができます。 - + まず最初に、シードを生成する必要があります。 + これは、数値定数で、ハッシュ値の生成やハッシュ値の検証で使われます。 + このシードがないと、 + ファイルのチェックサムの値を偽ったり検証が可能になります。 + 以下の例では、シードは + フラグで指定されています。 + 最初に以下のコマンドを用いて /bin + のハッシュ値およびチェックサムを生成してください。 - - root 権限で実行されているサーバと - SUID/SGID バイナリの安全性を高める + &prompt.root; mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > bin_chksum_mtree - - 砂場 (sandbox) - - - &man.sshd.8; - + このコマンドの出力は以下のようになります。 - 用心深いシステム管理者は、必要なサービスだけを有効にし、 - サードパーティ製のサーバは、 - よくバグを持っていがちだということに注意しているものです。 - 注意深くチェックしていないサーバは、決して実行してはいけません。 - 多くのデーモンは、サービス専用のアカウント、もしくは - 砂場 (sandbox) で起動させることができるので、 - root - 権限でサービスを実行する前には、よく考えてください。 - &man.telnetd.8; または &man.rlogind.8; - のような安全ではないサービスは有効にしないでください。 + &prompt.root; mtree: /bin checksum: 3427012225 - 他のシステムの潜在的なセキュリティホールには、 - SUID-root および SGID バイナリがあります。 - これらのバイナリは、 - &man.rlogin.1; のように、/bin, - /sbin, /usr/bin - または /usr/sbin - に存在するものがほとんどです。 - 100% 安全なものは存在しないとはいえ、 - システムデフォルトの SUID/SGID バイナリは比較的安全といえます。 - SUID バイナリは、 - スタッフのみがアクセス可能な特別なグループに制限し、 - 使わない SUID バイナリは削除することが推奨されます。 - SGID バイナリもほとんど同様の危険な存在になり得ます。 - 侵入者が kmem に SGID されたバイナリを破ることができた場合、 - その侵入者は /dev/kmem - を読み出すことができるようになるでしょう。つまり、 - 暗号化されたパスワードファイルを読み出すことができるようになるので、 - ユーザアカウントを、潜在的な危険に晒すことになります。他にも、 - kmem グループを破った侵入者が pty - を通して送られたキーストロークを監視できるという危険があります。 - キーストロークには、安全な方法でログインするユーザが使っている pty - も含まれます。 - tty - グループを破った侵入者は、ほぼ任意のユーザの - tty へ書き込みができます。 - ユーザが端末プログラムやキーボードをシミュレーションする機能を持ったエミュレータを使っている場合、 - 侵入者は潜在的に、 - 結局そのユーザとして実行されるコマンドをユーザの端末にエコーさせるデータストリームを生成できる可能性があります。 - + bin_cksum_mtree ファイルを見ると、 + 以下のような出力となります。 - - ユーザアカウントの安全性を高める + # 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 - ユーザアカウントは、普通、安全性を高めることが最も困難です。 - 気を配ってユーザアカウントを監視するよりほかありません。 - ユーザアカウントに対し &man.ssh.1; や Kerberos を利用するには、 - システム管理がさらに増えたりテクニカルサポートが必要になりますが、 - 暗号化パスワードファイルと比較するとはるかに良い方法を提供します。 - + コンピュータのホスト名、現在の日付と時間、&man.mtree.8; + を実行したユーザの情報すべてがこのレポートには含まれています。 + また、各バイナリに対するチェックサム、サイズ、タイムスタンプおよび + SHA256 ダイジェストも含まれています。 - - パスワードファイルの安全性を高める + バイナリ署名の検証のために、 + 以下のコマンドを実行すると、現在の署名のリストを読み込み、 + 結果を出力します。 - できるだけ多くのパスワードをアスタリスクで外し、 - それらのアカウントのアクセスには - &man.ssh.1; や Kerberos を使うようにすることが、唯一の確実な方法です。 - 暗号化パスワードファイル - (/etc/spwd.db) は - root - でのみ読み出し可能だけれども、 - たとえ、侵入者が root の書き込み権限は得られなくとも、 - 読み出しアクセス権限を得ることは可能かもしれません。 + &prompt.root; mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output - ファイルの完全性のチェック - 節で説明されているように、 - セキュリティスクリプトでパスワードファイルの変更をチェックし、 - 報告するようにすべきです。 - + このコマンドを実行すると、すでにチェックサムを生成している + /bin に対して、同様のチェックサムを生成します。 + このコマンドを実行してから変更が行われていないので、 + bin_chksum_output への主力は空となります。 + 変更が行われた場合をシミュレートするために、 + /bin/cat ファイルの日付を + &man.touch.1; を使って変更して、 + 再度検証のコマンドを実行してみます。 - - カーネルのコア、raw デバイス、 - ファイルシステムの安全性を高める + &prompt.root; touch /bin/cat + &prompt.root; mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output + &prompt.root; cat bin_chksum_output + cat changed + modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014 - 最近のカーネルは、組み込みのパケット覗き見デバイス - (packet sniffing device) ドライバを備えているものがほとんどです。 - &os; では bpf と呼ばれています。 - このデバイスは DHCP で必要となるため、 - DHCP を提供したり使う必要のないシステムでは、 - カスタムカーネルコンフィグレーションファイルから外すことができます。 + security/aide のような、 + より高度な IDS システムもありますが、 + ほとんどのケースにおいて、 + &man.mtree.8; は管理者が必要とする機能を提供します。 + 悪意のあるユーザが、 + シード値およびチェックサムの出力を見れないようにすることが重要です。 + - - &man.sysctl.8; - + + セキュリティのためのシステムの調整 + + システムの機能の多くは、&man.sysctl.8; を使って調整できます。 + Denial of Service (DOS) + スタイルの攻撃を避けるためのセキュリティ機能に対しても同様です。 + この節では、より重要な調整についても触れています。 + &man.sysctl.8; により、設定が変更された時はいつでも、 + 望まない危害が起こる可能性は高まり、 + システムの可用性に影響します。 + システム全体の設定を変更する時には、 + システムの CIA を考える必要があります。 - bpf を外しても、 - /dev/mem および - /dev/kmem という問題がまだ残っています。 - 侵入者は raw ディスクデバイスに書き込むこともできます。 - やる気まんまんの侵入者は、&man.kldload.8; - を使って自分独自の bpf、 - もしくは他の覗き見デバイスを動作中のカーネルにインストールできます。 - この問題を避けるため、カーネルをより高いセキュリティレベル、 - 少なくともセキュリティレベル 1 で実行させる必要があります。 + 以下では、&man.sysctl.8; の一覧、 + および変更がシステムにどのように影響するかを説明します。 - カーネルのセキュリティレベルはいくつかの方法で設定できます。 - 現在動いているカーネルのセキュリティレベルを高める最も簡単な方法は、 - kern.securelevel を設定する方法です。 - - &prompt.root; sysctl kern.securelevel=1 - デフォルトでは、&os; のカーネルはセキュリティレベル -1 で起動します。 このセキュリティレベルは、 @@ -521,479 +511,65 @@ YES とし、 kern_securelevel に必要とする値を設定することで、 - システム起動時にセキュアレベルを高めることができます。 - - セキュリティレベルを 1 以上に設定すると、 - 追加専用および変更不可ファイルのフラグを外すことはできなくなり、 - また raw デバイスへのアクセスが拒否されます。 - より高いレベルに設定すると、より多くの操作に制限がかかります。 - 各セキュリティレベルの完全な説明については、 + システム起動時にセキュアレベルを高めることができます。 + これらの設定についてのより詳細な情報については、 &man.security.7; および &man.init.8; をご覧ください。 - - セキュリティレベルを 1 以上に設定した場合には、 - /dev/io へのアクセスがブロックされるため、 - &xorg; や、 - installworld のプロセスでは、 - いくつかのファイルの追加専用および変更不可のフラグは一時的にリセットされるため、 - ソースから &os; - を構築してインストールするときなどで問題が引き起こされる可能性があります。 - &xorg; の問題については、 - 起動プロセス初期のセキュアレベルが十分低いときに - &man.xdm.1; を起動することで、この問題に対応できます。 - このような応急処置は、 - すべてのセキュリティレベルやそれらが課す潜在的なすべての制限には対応できないでしょう。 - 少し先を見越した計画的な対応をすべきです。 - 各セキュリティレベルで課される制限は、 - システムを使用することによる利便性を著しく減らしてしまうため、 - この制限を理解することは重要です。 - また、各セキュリティレベルの制限を理解することで、 - デフォルトの設定をよりシンプルにでき、 - 設定に関する意外性を少なくできるでしょう。 - + + securelevel を大きくしすぎると、 + Xorg + が動かなくなったり、他の問題が起きる可能性があります。 + デバッグの心づもりをしてください。 + - カーネルのセキュリティレベルを 1 以上に設定した場合には、 - システム起動に関わる重要なバイナリやディレクトリ、 - スクリプトファイル、そして、 - セキュリティレベルが設定されるまでの間に実行されるすべてのものに対して、 - schg フラグを設定することは有用でしょう。 - システムをより高いセキュリティレベルで実行させるようにするが、 - schg - フラグを設定しないというところで妥協するという手もあります。 - もう一つの可能性としては、単純に - / および /usr - を読み込み専用でマウントすることです。 - ここで特筆すべきことは、システムを守ろうとして厳しくしすぎると、 - 侵入を検出することができなくなってしまうということです。 - + つぎに変更を検討すべき &man.sysctl.8; は、 + net.inet.tcp.blackhole および net.inet.udp.blackhole です。 + これらを設定すると、閉じたポートに対して届く + SYN パケットはドロップされ、 + RST レスポンスを返しません。 + 通常は、RST を返し、 + そのポートが閉じられていることを伝えます。 + これにより、システムに対する ステルス + スキャンに対し、ある程度の防御となります。 + net.inet.tcp.blackhole を 2、 + net.inet.udp.blackhole を 1 に設定してください。 + 詳細な情報について &man.blackhole.4; をご覧ください。 - - ファイルの完全性のチェック + さらに、net.inet.icmp.drop_redirect および + net.inet.ip.redirect も設定すべきです。 + これら 2 つの + &man.sysctl.8; は、リダイレクト攻撃を防ぐ助けとなるでしょう。 + リダイレクト攻撃は、 + 故意に通常のネットワークでは必要としないような大量の + ICMP タイプ 5 のパケットを発生します。 + そのため net.inet.icmp.drop_redirect を 1、 + net.inet.ip.redirect を 0 に設定して下さい。 - システム管理者にできることは、 - 便利さという要素がその醜い頭を上げない程度に、 - コアシステムの設定と制御ファイルを防御することだけです。 - たとえば、/ および - /usr - にある大部分のファイルに schg - ビットを設定するために &man.chflags.1; - を使用するのは、おそらく逆効果でしょう。 - なぜなら、そうすることでファイルは保護できますが、 - 侵入を検出する窓を閉ざしてしまうことにもなるからです。 - セキュリティ対策は、 - 侵入の可能性を検出できなければ、有用ではなく、 - もっと悪ければ、安全性に対する間違った感覚を植え付けてしまいます。 - セキュリティに対する仕事の半分は、 - 攻撃者を攻撃の最中に捕えるようにするために、 - 攻撃者を食い止めるのではなく侵入を遅らせることなのです。 + ソースルーティングは、 + 内部ネットワーク上でルーティングできないアドレスを検出したりアクセスするための方法です。 + 通常ルーティングできないアドレスは、 + 意図してルーティングできないようにしているので、 + この設定はおそらく無効にすべきです。 + この機能を無効にするには、 + net.inet.ip.sourceroute および net.inet.ip.accept_sourceroute + を 0 に設定してください。 - 侵入を検出する最も良い方法は、変更されていたり、 - 消えていたり、入れた覚えがないのに入っているファイルを探すことです。 - 変更されたファイルを探すのに最も良い方法は、もう一つの - しばしば中央に集められた、 - アクセスが制限されたシステムから行なうものです。 - さらに安全でアクセス制限されたシステム上でセキュリティ用スクリプトを書けば、 - スクリプトは潜在的な攻撃者からはほぼ見えなくなります。 - この有効性を最大限に活用するためには、 - アクセスの制限されたマシンから他のマシンへのかなりのアクセスを許可する必要があります。 - 普通は、読み込み専用の NFS エクスポートをしたり、 - &man.ssh.1; 鍵のペアを設定したりします。 - ネットワークのトラフィックを別にして、 - NFS は最も可視性のない方法です。 - 管理者は、各クライアント上のファイルシステムを、 - 事実上検出されずに監視できるようになります。 - アクセス制限されたサーバがスイッチを通してクライアントに接続されている場合、 - たいてい NFS がより良い選択肢です。 - アクセス制限されたサーバが、 - いくつかのルーティング層を通してクライアントに接続している場合、 - NFS はあまりにも危険なので、 - &man.ssh.1; の方が良い方法でしょう。 + ブロードキャストアドレスに対するすべての + ICMP エコーリクエストは、ドロップしてください。 + ネットワーク上のコンピュータがサブネットにあるすべてのホストにメッセージを送る必要がある場合には、 + メッセージはブロードキャストアドレスに送られます。 + 外部のホストについては、 + このような送信をする必要はないので、 + 外部からブロードキャストへのリクエストをすべて拒否するように、 + net.inet.icmp.bmcastecho を 0 + に設定してください。 - アクセス制限されたマシンに、 - 監視しようとするクライアントシステムへの少なくとも読み込みのアクセス権を与えたら、 - 次に監視するためのスクリプトを書かなくてはいけません。 - NFS マウントをすれば、&man.find.1; や &man.md5.1; - などの単純なシステムユーティリティでスクリプトを書くことができます。 - 少なくとも 1 日 1 回、クライアントのシステムファイルを直接 - &man.md5.1; にかけ、 - さらにもっと頻繁に /etc および - /usr/local/etc - にあるようなコントロール用ファイルを試験するのが一番です。 - アクセス制限されたマシンが正しいと知っている、 - 基となる md5 情報と比べて違いが見つかった場合、 - システム管理者に警告するようにすべきです。 - 優れたセキュリティ用スクリプトは、 - / および /usr - などのシステムパーティション上で不適当に - SUID されたバイナリや、 - 新たに作成されたファイルや削除されたファイルがないかどうかを調べるでしょう。 - - NFS ではなく、&man.ssh.1; を使用する場合は、 - セキュリティ用スクリプトを書くのはより難しいことです。 - たとえば、スクリプトを動かすためには、クライアントに対してスクリプトを - &man.scp.1; しなくてはいけませんし、 - クライアントマシンの &man.ssh.1; - クライアントはすでに攻撃されてしまっているかもしれません。 - 安全でないリンク上の場合は - &man.ssh.1; は必要かもしれませんが、 - 扱いはとても大変になります。 - - 優れたセキュリティ用スクリプトは、 - .rhosts, - .ssh/authorized_keys - などの隠し設定ファイルの変更もチェックするものです。 - これらは MD5 - チェックの範囲外になってしまうであろうファイル群です。 - - ユーザ用のディスク容量が非常に大きい場合は、 - パーティション上の各ファイルを見て回るのに大変な時間がかかるかもしれません。 - この場合は、&man.mount.8; により nosuid - を使うことで、マウントフラグを設定して、 - SUID されたバイナリを置けないようにするのが良い考えです。 - 少なくとも週に 1 度はファイルシステムをスキャンするべきです。 - なぜなら、目的は、侵入が成功したかどうかに関わらず、 - 不正侵入の試みがあったことの検出をすることだからです。 - - プロセスアカウンティング (&man.accton.8; 参照) は、 - マシンへの侵入を検出するためのメカニズムとして推奨できる、 - 比較的オーバヘッドの少ない &os; の機能です。 - 侵入を受けた後でも当該ファイルが無傷である場合に、 - 侵入者がどのようにしてシステムに侵入したかを追跡するのに特に役立ちます。 - - 最後に、 - セキュリティスクリプトはログファイルを処理するようにし、 - ログファイル自体もできるだけ安全性の高い方法で生成するようにし、 - リモートの syslog サーバに送信するようにすべきです。 - 侵入者は自分の侵入の痕跡を覆い隠そうとしますし、また、 - ログファイルはシステム管理者が最初の侵入の時刻と方法を追跡してゆくために極めて重要です。 - ログファイルを永久に残しておくための 1 つの方法は、 - システムコンソールをシリアルポートにつないで走らせ、 - コンソールを監視している安全なマシンに情報を集めることです。 - - - - 偏執狂的方法 - - 多少偏執狂的になっても決して悪いことにはなりません。 - 原則的に、システム管理者は、 - 便利さに影響を与えない範囲でいくつでもセキュリティ機能を追加することができます。 - また、いくらか考慮した結果、 - 便利さに影響を与えるセキュリティ機能を追加することもできます。 - より重要なことは、 - セキュリティ管理者はこれを多少混ぜこぜにして使うべきだということです。 - もしこの章で書かれている推奨される方法をそのまま使用した場合は、 - 予想される攻撃者はやはりこの文書を読んでいるわけですから、 - 防御策を教えてしまうことになります。 - - - - サービス妨害攻撃 - - - サービス妨害 (DoS) - - - DoS 攻撃は、普通は、パケット攻撃です。 - ネットワークを飽和させる最先端の偽造パケット (spoofed packet) - 攻撃に対してシステム管理者が打てる手はそれほど多くありませんが、 - 一般的に、以下のような方法により、 - その種の攻撃によってサーバがダウンしないことを確実にすることで、 - 被害をある限度に食い止めることはできます。 - - *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***