d37975ff27
Chapters: X11, multimedia, security, l10n and cutting-edge. With this last sync, all the handbook is finished.
1817 lines
135 KiB
Text
1817 lines
135 KiB
Text
---
|
||
title: 第14章 セキュリティ
|
||
part: パートIII. システム管理
|
||
prev: books/handbook/users
|
||
next: books/handbook/disks
|
||
---
|
||
|
||
[[security]]
|
||
= セキュリティ
|
||
:doctype: book
|
||
:toc: macro
|
||
:toclevels: 1
|
||
:icons: font
|
||
:sectnums:
|
||
:sectnumlevels: 6
|
||
:source-highlighter: rouge
|
||
:experimental:
|
||
:skip-front-matter:
|
||
:toc-title: 目次
|
||
:table-caption: 表
|
||
:figure-caption: 図
|
||
:example-caption: 例
|
||
:xrefstyle: basic
|
||
:relfileprefix: ../
|
||
:outfilesuffix:
|
||
:sectnumoffset: 14
|
||
|
||
ifeval::["{backend}" == "html5"]
|
||
:imagesdir: ../../../images/books/handbook/security/
|
||
endif::[]
|
||
|
||
ifeval::["{backend}" == "pdf"]
|
||
:imagesdir: ../../../../static/images/books/handbook/security/
|
||
endif::[]
|
||
|
||
ifeval::["{backend}" == "epub3"]
|
||
:imagesdir: ../../../../static/images/books/handbook/security/
|
||
endif::[]
|
||
|
||
include::shared/authors.adoc[]
|
||
include::shared/releases.adoc[]
|
||
include::shared/ja/mailing-lists.adoc[]
|
||
include::shared/ja/teams.adoc[]
|
||
include::shared/ja/urls.adoc[]
|
||
|
||
toc::[]
|
||
|
||
[[security-synopsis]]
|
||
== この章では
|
||
|
||
物理的もしくは仮想的に関わらず、 セキュリティは幅広いトピックであり、 業界全体がセキュリティとともに成長しています。 システムおよびネットワークを安全にする標準的な方法は数多く文書化されており、 FreeBSD のユーザも、 攻撃や侵入者から守る方法を理解しなければなりません。
|
||
|
||
この章では、セキュリティの基礎や技術について説明します。 FreeBSD システムは、複数のレイヤに関連するセキュリティを提供します。 そして、安全性を高めるためにサードパーティ製のユーティリティを利用することもできます。
|
||
|
||
この章を読むと、以下のことがわかります。
|
||
|
||
* FreeBSD における基本的なシステムセキュリティの考え方
|
||
* FreeBSD で利用できるさまざまな暗号化手法
|
||
* ワンタイムパスワード認証の設定方法
|
||
* man:inetd[8] と組み合わせて TCP Wrappers を設定する方法
|
||
* FreeBSD における Kerberos の設定方法
|
||
* IPsec を設定して VPN を構築する方法
|
||
* FreeBSD にける OpenSSH の設定および使用方法
|
||
* ファイルシステム ACL (アクセス制御リスト) の使用方法
|
||
* Ports Collection からインストールされたサードパーティ製ソフトウェア packages を Portaudit を使って監査する方法
|
||
* FreeBSD セキュリティ勧告の利用方法
|
||
* プロセスアカウンティングがどのようなものか、 FreeBSD 上で有効にする方法について
|
||
* リソース制限データベースとは何か、 この仕組みを使ったユーザ資源の管理方法
|
||
|
||
この章を読む前に、次のことが必要になります。
|
||
|
||
* FreeBSD およびインターネットの基本概念の理解
|
||
|
||
[[security-intro]]
|
||
== はじめに
|
||
|
||
セキュリティを高めることはすべての人の責任です。 システムに弱い侵入ポイントが存在すると、侵入者は重要な情報を得たり、 ネットワーク全体に被害を及ぼすことができるようになります。 多くのセキュリティのトレーニングでは、 情報システムの機密性 (confidentiality)、 完全性 (integrity) および可用性 (availability) を意味するセキュリティの 3 要素である CIA が取り扱われます。
|
||
|
||
CIA の 3 要素は、 コンピュータセキュリティの基本となる考えです。 顧客やエンドユーザは、データのプライバシーを期待します。 彼らは、データが変更されないことや、 情報が隠されていることを期待します。 彼らはまた、いつでも情報にアクセスできることを期待します。 これらは、システムの機密性、完全性、可用性を構成します。
|
||
|
||
セキュリティのプロフェッショナルは、CIA を守るために、多層防衛の戦略を採用します。 この多層防衛戦略ではセキュリティのレイアを複数用意することで、 一つのレイヤが破られても、 セキュリティシステム全体が破られることを防ぎます。 システムの管理者は、ファイアウォールを単に有効にするだけではなく、 ネットワークもしくはシステムを安全に保つ必要があります。 アカウントを監査し、バイナリの完全性、 悪意のあるツールがインストールされていないことを確認する必要があります。 このために、 管理者は脅威がどのようなものかを理解する必要があります。
|
||
|
||
[[security-threats]]
|
||
=== 脅威
|
||
|
||
コンピュータセキュリティおける脅威とは何でしょうか？ 長年、脅威はリモートの攻撃者、 すなわち遠隔からの許可のないシステムへのアクセスを企てる人々と考えられていました。 今日では、この定義は従業員、悪意のあるソフトウェア、 不正なネットワークデバイス、自然災害、セキュリティの脆弱性、 そして競合する会社でさえも含めるように拡張されています。
|
||
|
||
毎日、数千ものシステムおよびネットワークが攻撃され、 数百ものシステムが許可なくアクセスされています。 簡単なアクシデントといったものから、リモートからの攻撃、 産業スパイであったり、以前働いていた従業員からの攻撃といったケースもあります。 システムのユーザとしては、 間違いがセキュリティ違反に繋がった場合には、 可能性のある問題をセキュリティチームに報告することが重要です。 管理者としては、脅威を把握し、 その脅威の影響を小さくするように準備をしておくことが重要です。
|
||
|
||
[[security-groundup]]
|
||
=== ボトムアップアプローチ
|
||
|
||
セキュリティを考える上で、 しばしばボトムアップアプローチが一番良い方法となります。 この考えでは、管理者が基本的なアカウント、システム設定を行ってから、 サードパーティ製ユーティリティの設定、 そしてネットワークレイヤに設定を広げていきます。 システムポリシーおよび手続きを行う上では、 このような設定の側面があります。
|
||
|
||
ビジネスの多くの環境では、 使用するデバイスの設定に対するセキュリティポリシがすでに策定されています。 このポリシには、最低限エンドユーザのワークステーション、 デスクトップ、携帯電話やラップトップといったモバイルデバイス、および 製品および開発サーバの両方に対するセキュリティの設定が含まれているべきです。 多くの場合には、コンピュータのセキュリティを考える際に、 標準作業手続書 (SOP) がすでに存在します。 わからなければ、セキュリティチームに尋ねてください。
|
||
|
||
[[security-accounts]]
|
||
=== システムおよびユーザアカウント
|
||
|
||
システムを安全にするにあたり、最も適切な出発点は、 アカウントの監査です。 ルートアカウントのパスワードが強力であること、 シェルアクセスを必要としないアカウントは無効にすることを確実におこなってください。 また、権限を必要とするユーザに対しては、 package:security/sudo[] をインストールして、 アクセスが必要となるアプリケーションのみにアクセスを許可するようにしてください。 root ユーザのパスワードは、決して共有すべきではありません。
|
||
|
||
アカウントへのアクセスを無効にする方法は二通りあります。 一つ目の方法は、アカウントをロックする方法です。例として、 toor アカウントをロックする方法を以下に示します。
|
||
|
||
[source,bash]
|
||
....
|
||
# pw lock toor
|
||
....
|
||
|
||
このコマンドは、アカウントの設定を "toor:*:0:0::0:0:Bourne-again Superuser:/root:" から "toor:*LOCKED**:0:0::0:0:Bourne-again Superuser:/root:" へと変更します。
|
||
|
||
ときには (おそらく追加のサービスのために)、 この方法が使えない場合があります。 そのような場合には、以下の例のように、 シェルを /sbin/nologin に変更することで、 ログインアクセスを拒否できます。
|
||
|
||
[source,bash]
|
||
....
|
||
# chsh -s /usr/sbin/nologin toor
|
||
....
|
||
|
||
[NOTE]
|
||
====
|
||
他のユーザのシェルは、スーパーユーザのみが変更できます。 通常のユーザが行おうとすると失敗します。
|
||
====
|
||
|
||
アカウント情報は、以下のように最後のエントリが "nologin" シェルとなります。
|
||
|
||
[.programlisting]
|
||
....
|
||
toor:*:0:0::0:0:Bourne-again Superuser:/root:/usr/sbin/nologin
|
||
....
|
||
|
||
[.filename]#/usr/sbin/nologin# シェルは、 man:login[1] コマンドがこのユーザにシェルを割り当てることをブロックします。
|
||
|
||
[[security-sudo]]
|
||
=== アカウントの権限を拡大する
|
||
|
||
場合によっては、 システム管理者へのアクセスを他のユーザと共有する必要があります。 FreeBSD はこのために二つの方法を用意しています。 第一の方法は推奨されませんが、 ルートのパスワードを共有し、ユーザを `wheel` グループに加える方法です。 これを行うにには、[.filename]#/etc/group# を編集し、 最初のグループの最後にユーザを追加してください。 ユーザはカンマ区切りで管理されています。
|
||
|
||
権限の拡大をする適切な方法は、 package:security/sudo[] port を使う方法です。 この port は、追加の監査、よりきめ細かいユーザ管理、および ユーザを man:service[8] のような権限が与えられたコマンのみの実行に制限することもできます。
|
||
|
||
インストールが終わったら、 `visudo` インタフェースを使って [.filename]#/usr/local/etc/sudoers# ファイルを編集してください。 以下の例では、新しく webadmin グループが作成され、 `trhodes` ユーザがこのグループに追加されます。 その後、ユーザに package:apache24[] を再起動するアクセス権限を与えます。 この手続きは以下のようになります。
|
||
|
||
[source,bash]
|
||
....
|
||
# pw groupadd webadmin -M trhodes -g 6000
|
||
....
|
||
|
||
[source,bash]
|
||
....
|
||
# visudo
|
||
....
|
||
|
||
[.programlisting]
|
||
....
|
||
%webadmin ALL=(ALL) /usr/sbin/service apache24 *
|
||
....
|
||
|
||
ローカルのユーザ管理において、 package:security/sudo[] は、 非常に貴重なリソースを提供します。 また、パスワードを不必要にして、デフォルトを man:ssh[1] 鍵の方法だけにすることもできます。 man:sshd[8] 経由のパスワードによるログインを無効にし、 `sudo` へのローカルパスワードのみを使うようにするには、 <<openssh>> をご覧ください。
|
||
|
||
[[security-passwords]]
|
||
=== パスワード
|
||
|
||
パスワードは、テクノロジーにおける必要悪です。 パスワードは極めて複雑であるだけではなく、 パスワードを保護する強力なハッシュメカニズムもまた必要となります。 この文書を書いている時点では、 FreeBSD は `crypt()` ライブラリで DES, MD5, Blowfish, SHA256 および SHA512 に対応しています。 デフォルトは SHA512 であり、 強度の弱い暗号へは変更すべきではありません。 しかしながら、Blowfish を好むユーザもおります。 DES を除く各メカニズムでは、 開始の文字、使用しているハッシュメカニズムを識別可能な特徴を持っています。 MD5 メカニズムでは、シンボルは "$" の符号です。 SHA256 または、 SHA512 では、シンボルは "$6$"、 そして Blowfish は "$2a$" です。 暗号強度の弱いパスワードを使用している場合には、 次回のログイン時にユーザが man:passwd[1] を実行して再ハッシュ化することを促すべきです。
|
||
|
||
[NOTE]
|
||
====
|
||
この文書を書いている時点で、Blowfish は AES でなければ、 FIPS (Federal Information Processing Standards) に準拠もしていません。 そのため、使用できない環境があります。
|
||
====
|
||
|
||
ネットワークに接続しているシステムについては、 二要素認証を使用すべきです。 この認証では、通常あなたが所有する要素と知っている要素が用いられます。 FreeBSD のベースシステムに含まれている OpenSSH および ssh-keys では、 ネットワークへのすべてのログインにおける二要素認証の交換で、 パスワードを使用すべきではありません。 より詳細な情報については、ハンドブックの <<openssh>> 節をご覧ください。 Kerberose のユーザは、ネットワークで OpenSSH を実装するために追加の変更が必要になるでしょう。
|
||
|
||
[[security-rkhunter]]
|
||
=== バックドアおよびルートキット
|
||
|
||
バックドアおよびルートキットは、 それらがインストールされた後に脅威となります。 インストールされると、この悪意のあるソフトウェアは、 攻撃者のために侵入口を設置します。 実際的には、システムが一度汚染された後に、調査が行われ、 消去されます。 慎重なセキュリティやシステムエンジニアでさえも、 攻撃者が残したソフトウェアを見逃してしまうという恐ろしいリスクが存在しています。
|
||
|
||
バックドアまたはルートキットソフトウェアは、 管理者にとって役に立つことが一つあります。 それは、一度検出すると、 システムのどこかが危険に冒されていることの痕跡となります。 しかし、通常この種のアプリケーションは、とてもうまく隠れています。 バックドアおよびルートキットを検出するツールが存在しており、 それうちの一つが、 package:security/rkhunter[] です。
|
||
|
||
インストール後、以下のコマンドでシステムをチェックできます。 実行すると多くの情報が出力されます。
|
||
|
||
[source,bash]
|
||
....
|
||
# rkhunter -c
|
||
....
|
||
|
||
このプロセスを実行中に kbd:[ENTER] キーを何度か押す必要があります。 完了すると、ステータスメッセージが画面に表示されます。 このメッセージは、チェックしたファイルの量、疑わしいファイルの数、 可能性のあるルートキット等の情報を含みます。 チェックの最中、隠されたファイル、 OpenSSH プロトコルの選択、そして、 時には、インストールされているソフトウェアの漸弱性のバージョンに関する一般的なセキュリティの警告が出力されます。 すぐに、もしくはより詳細な解析が行われた後に、対応が可能です。
|
||
|
||
管理者は皆、 担当しているシステム上で何が実行されているかを把握している必要があります。 rkhunter, lsof や man:netstat[1] および man:ps[1] といったネイティブのツールは、 システムに関するかなり多くの情報を与えてくれます。 正常な状態がどのような状態であるかを把握しておき、 本来と違う状況になった場合には、質問をしたり、 疑い深くなってください。 セキュリティが破られることを避けることは理想ですが、 破られたことを把握することは必須です。
|
||
|
||
[[security-ids]]
|
||
=== バイナリ検証
|
||
|
||
システムファイルおよびバイナリの検証は、 システム管理者およびセキュリティチームに対して、 システムの変更に関する情報を提供してくれるため重要です。 いかなるシステムにおいても、システム管理チームの知らないところで、 内部のコマンドやアプリケーションは変更すべきではありません。 システムの変更ををモニタリングするソフトウェアアプリケーションは、 侵入検知システム (Intrusion Detection System) または IDS と呼ばれます。
|
||
|
||
FreeBSD は、基本的な IDS システムをネイティブで提供しています。 実際に、毎晩の man:periodic[8] セキュリティに関するメールの中では、 管理者に変更点を通知します。 情報はローカルに保存されているので、 悪意のあるユーザが変更し、情報を "欺く" 可能性があります。 そのため、バイナリの署名の別のセットを作成して、 読み取り専用の root 所有のディレクトリ、できれば、 USB ディスクまたは rsync サーバといったシステムとは別のシステムに保存してください。
|
||
|
||
まず最初に、シードを生成する必要があります。 これは、数値定数で、ハッシュ値の生成やハッシュ値の検証で使われます。 このシードがないと、 ファイルのチェックサムの値を偽ったり検証が可能になります。 以下の例では、シードは `-s` フラグで指定されています。 最初に以下のコマンドを用いて [.filename]#/bin# のハッシュ値およびチェックサムを生成してください。
|
||
|
||
[source,bash]
|
||
....
|
||
# mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > bin_chksum_mtree
|
||
....
|
||
|
||
このコマンドの出力は以下のようになります。
|
||
|
||
[source,bash]
|
||
....
|
||
# mtree: /bin checksum: 3427012225
|
||
....
|
||
|
||
[.filename]#bin_cksum_mtree# ファイルを見ると、 以下のような出力となります。
|
||
|
||
[.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
|
||
....
|
||
|
||
コンピュータのホスト名、現在の日付と時間、man:mtree[8] を実行したユーザの情報すべてがこのレポートには含まれています。 また、各バイナリに対するチェックサム、サイズ、タイムスタンプおよび SHA256 ダイジェストも含まれています。
|
||
|
||
バイナリ署名の検証のために、 以下のコマンドを実行すると、現在の署名のリストを読み込み、 結果を出力します。
|
||
|
||
[source,bash]
|
||
....
|
||
# mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output
|
||
....
|
||
|
||
このコマンドを実行すると、すでにチェックサムを生成している [.filename]#/bin# に対して、同様のチェックサムを生成します。 このコマンドを実行してから変更が行われていないので、 [.filename]#bin_chksum_output# への主力は空となります。 変更が行われた場合をシミュレートするために、 [.filename]#/bin/cat# ファイルの日付を man:touch[1] を使って変更して、 再度検証のコマンドを実行してみます。
|
||
|
||
[source,bash]
|
||
....
|
||
# touch /bin/cat
|
||
....
|
||
|
||
[source,bash]
|
||
....
|
||
# mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output
|
||
....
|
||
|
||
[source,bash]
|
||
....
|
||
# cat bin_chksum_output
|
||
....
|
||
|
||
[.programlisting]
|
||
....
|
||
cat changed
|
||
modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014
|
||
....
|
||
|
||
package:security/aide[] のような、 より高度な IDS システムもありますが、 ほとんどのケースにおいて、 man:mtree[8] は管理者が必要とする機能を提供します。 悪意のあるユーザが、 シード値およびチェックサムの出力を見れないようにすることが重要です。
|
||
|
||
[[security-tuning]]
|
||
=== セキュリティのためのシステムの調整
|
||
|
||
システムの機能の多くは、man:sysctl[8] を使って調整できます。 Denial of Service (DOS) スタイルの攻撃を避けるためのセキュリティ機能に対しても同様です。 この節では、より重要な調整についても触れています。 man:sysctl[8] により、設定が変更された時はいつでも、 望まない危害が起こる可能性は高まり、 システムの可用性に影響します。 システム全体の設定を変更する時には、 システムの CIA を考える必要があります。
|
||
|
||
以下では、man:sysctl[8] の一覧、 および変更がシステムにどのように影響するかを説明します。
|
||
|
||
デフォルトでは、FreeBSD のカーネルはセキュリティレベル -1 で起動します。 このセキュリティレベルは、 変更不可のファイルフラグを外したり、 すべてのデバイスに対して読み込みおよび書き込みができたりするので、 "insecure mode" と呼ばれます。 このセキュアレベルは、管理者または man:init[8] による起動時のスクリプトにより変更されない限り -1 のままです。 [.filename]#/etc/rc.conf# において、 `kern_securelevel_enable` を `YES` とし、 `kern_securelevel` に必要とする値を設定することで、 システム起動時にセキュアレベルを高めることができます。 これらの設定についてのより詳細な情報については、 man:security[7] および man:init[8] をご覧ください。
|
||
|
||
[WARNING]
|
||
====
|
||
`securelevel` を大きくしすぎると、 Xorg が動かなくなったり、他の問題が起きる可能性があります。 デバッグの心づもりをしてください。
|
||
====
|
||
|
||
つぎに変更を検討すべき 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" に設定して下さい。
|
||
|
||
ソースルーティングは、 内部ネットワーク上でルーティングできないアドレスを検出したりアクセスするための方法です。 通常ルーティングできないアドレスは、 意図してルーティングできないようにしているので、 この設定はおそらく無効にすべきです。 この機能を無効にするには、 net.inet.ip.sourceroute および net.inet.ip.accept_sourceroute を "0" に設定してください。
|
||
|
||
ブロードキャストアドレスに対するすべての ICMP エコーリクエストは、ドロップしてください。 ネットワーク上のコンピュータがサブネットにあるすべてのホストにメッセージを送る必要がある場合には、 メッセージはブロードキャストアドレスに送られます。 外部のホストについては、 このような送信をする必要はないので、 外部からブロードキャストへのリクエストをすべて拒否するように、 net.inet.icmp.bmcastecho を "0" に設定してください。
|
||
|
||
まだ多くの man:sysctl[8] が man:security[7] で説明されています。 さらに多くの情報を調べることが推奨されます。
|
||
|
||
[[one-time-passwords]]
|
||
== ワンタイムパスワード
|
||
|
||
デフォルトで、FreeBSD は One-time Passwords In Everything (OPIE) に対応しています。 OPIE はデフォルトでは MD5 ハッシュを使用します。
|
||
|
||
三種類の異なる「パスワード」があります。 まず一つ目は、通常の UNIX(R) スタイル、もしくは Kerberos のパスワードです。 二つ目は、man:opiekey[1] によって生成され、 man:opiepasswd[1] およびログインプロンプトが受け付けるワンタイムパスワードです。 三つ目のパスワードは、man:opiekey[1] と場合により `opiepasswd` に対してワンタイムパスワードを生成するのに使われる "秘密のパスワード" です。
|
||
|
||
秘密のパスワードは、UNIX(R) パスワードと何の関連性もありません。 両者を同一に設定することは可能ですが、お奨めしません。古い UNIX(R) パスワードは長さが 8 文字に制限されていました 。 これに対し、OPIE の秘密のパスワードには 8 文字の制限はありません。 6 語から 7 語からなるパスフレーズがふつうです。ほとんどの部分で、 OPIE システムは UNIX(R) のパスワードシステムと完全に独立して動作するようになっています。
|
||
|
||
パスフレーズに加え、OPIE システムにとって重要な 2 種類のデータがあります。一つは "シード (seed: 種)" または "キー (key: 鍵)" と呼ばれるもので、2 つの文字と 5 つの数字で構成されます。もう一つは "シーケンス番号 (iteration count)" で、1 から 100 までの整数です。 OPIE はここまでに述べたデータを利用してワンタイムパスワードを生成します。 その方法は、まずシードと秘密のパスフレーズを連結し、 それに対してシーケンス番号の回数だけ MD5 ハッシュを繰り返し計算します。 そしてその結果を 6 つの短い英単語に変換します。 この 6 つの英単語がワンタイムパスワードです。 認証システム (主は PAM) は、 前回最後に受け付けたワンタイムパスワードを記録しています。 そして、その前回のワンタイムパスワードと、 ユーザが入力したワンタイムパスワードを 1 回ハッシュ関数にかけた結果とが一致した場合に、 このユーザは認証されます。 一方向ハッシュ関数を使っているので、 もし正しく認証されたワンタイムパスワードが一回盗聴されたとしても、 次回以降に使われる複数のワンタイムパスワードを生成することは不可能です。 シーケンス番号はログインが成功するたびに一つずつ減らされて、 ユーザとログインプログラムの間で同期が取られます。 シーケンス番号が 1 まで減ったら、 OPIE を再度初期化する必要があります。
|
||
|
||
このプロセスに関連するいくつかのプログラムがあります。 man:opiekey[1] は、シーケンス番号と、シードと、 秘密のパスフレーズを受け付けて、ワンタイムパスワード 1 つ、 または一連のワンタイムパスワードの一覧を生成します。 man:opiepasswd[1] は、OPIE の初期化に加え、パスワード、 シーケンス番号やシードを変更するためにも使用されます。 このプログラムを実行するには、秘密のパスフレーズか、 または、シーケンス番号とシードとワンタイムパスワードの 1 組かの、どちらかを与えます。 man:opieinfo[1] は、 認証ファイル ([.filename]#/etc/opiekeys#) を調べて、 プログラムを起動したユーザの現在のシーケンス番号とシードを表示します。
|
||
|
||
4 種類の異なる操作があります。 1 つ目は、man:opiepasswd[1] を信頼できる通信路上で利用して、 最初にワンタイムパスワードを設定したり、 秘密のパスフレーズやシードを変更する操作です。 2 つ目は、同じことを行うために man:opiepasswd[1] を信頼できない通信路上で利用する操作です。 この場合は信頼できる通信路経由の man:opiekey[1] を併用します。3 つ目は、man:opiekey[1] を使い、信頼できない通信路を通じてログインする操作です。 4 番目は、man:opiekey[1] を使って複数のワンタイムパスワードを一気に生成する操作です。 ここで生成した複数のワンタイムパスワードは、 メモしたり印刷したりして携帯し、 信頼できる通信路が一切ないところからの接続に利用できます。 (訳注: ワンタイムパスワードを記録した紙をなくさないこと! 電話番号や IP アドレス、ユーザ名を一緒にメモしていたら最悪です!!)
|
||
|
||
=== 信頼できる通信路での初期化
|
||
|
||
OPIE を初めて初期化するには、 man:opiepasswd[1] を実行してください。
|
||
|
||
[source,bash]
|
||
....
|
||
% opiepasswd -c
|
||
[grimreaper] ~ $ opiepasswd -f -c
|
||
Adding unfurl:
|
||
Only use this method from the console; NEVER from remote. If you are using
|
||
telnet, xterm, or a dial-in, type ^C now or exit with no password.
|
||
Then run opiepasswd without the -c parameter.
|
||
Using MD5 to compute responses.
|
||
Enter new secret pass phrase:
|
||
Again new secret pass phrase:
|
||
|
||
ID unfurl OTP key is 499 to4268
|
||
MOS MALL GOAT ARM AVID COED
|
||
....
|
||
|
||
`Enter new secret pass phrase:` または `Enter secret password:` というプロンプトに対して、 パスワードまたはパスフレーズを入力してください。 このパスワードは、 ログインするときに使うワンタイムパスワードを生成するために使うものであり、 ログインのためのパスワードではありません。 "ID" から始まる行は、1 回分のパラメータで、 ログイン名とシーケンス番号とシードです。 ログインするときには、 システム側がこれらのパラメータを覚えていて表示してくれるので、 これらのパラメータを覚えておく必要はありません。 最後の行が、今述べたパラメータと入力された秘密のパスワードから計算されたワンタイムパスワードです。 次にログインするときに打ち込むべきワンタイムパスワードがこれです。
|
||
|
||
=== 信頼できない通信路での初期化
|
||
|
||
信頼できない通信路を使って秘密のパスフレーズを初期化または変更するためには、 man:opiekey[1] を実行するための信頼できる通信路を用意しておく必要があります。 たとえばそれは、 信頼できるマシンのシェルプロンプトだったりするでしょう。 (訳注: ここでの通信路とはマシンそのものになります。 信頼できるマシンとは、 信頼できる人がしっかり管理しているマシンということです)。 他に準備しておくものとして、シーケンス番号 (100 は適切な値といえるでしょう) と、場合によっては自分で考えた、 またはランダムに生成されたシードがあります。 信頼できない通信路を使うときには、man:opiepasswd[1] を使ってコンピュータを初期化してください。
|
||
|
||
[source,bash]
|
||
....
|
||
% opiepasswd
|
||
|
||
Updating unfurl:
|
||
You need the response from an OTP generator.
|
||
Old secret pass phrase:
|
||
otp-md5 498 to4268 ext
|
||
Response: GAME GAG WELT OUT DOWN CHAT
|
||
New secret pass phrase:
|
||
otp-md5 499 to4269
|
||
Response: LINE PAP MILK NELL BUOY TROY
|
||
|
||
ID mark OTP key is 499 gr4269
|
||
LINE PAP MILK NELL BUOY TROY
|
||
....
|
||
|
||
デフォルトのシードで構わなければ、kbd:[Return] を押してください。アクセスパスワードを入れる前に、 あらかじめ用意しておいた信頼できる通信路へ移って、 先ほどと同じパラメータを入力します。
|
||
|
||
[source,bash]
|
||
....
|
||
% opiekey 498 to4268
|
||
Using the MD5 algorithm to compute response.
|
||
Reminder: Do not use opiekey from telnet or dial-in sessions.
|
||
Enter secret pass phrase:
|
||
GAME GAG WELT OUT DOWN CHAT
|
||
....
|
||
|
||
信頼できない通信路の方に戻って、 生成されたワンタイムパスワードをコピーして対応するプログラムに入力します。
|
||
|
||
=== ワンタイムパスワードを一つ生成する
|
||
|
||
OPIE を初期化したら、 ログイン時には以下のようなプロンプトが出てくるでしょう。
|
||
|
||
[source,bash]
|
||
....
|
||
% telnet example.com
|
||
Trying 10.0.0.1...
|
||
Connected to example.com
|
||
Escape character is '^]'.
|
||
|
||
FreeBSD/i386 (example.com) (ttypa)
|
||
|
||
login: <ユーザ名>
|
||
otp-md5 498 gr4269 ext
|
||
Password:
|
||
....
|
||
|
||
OPIE のプロンプトには便利な機能が備わっています。 パスワードプロンプトに対して、 kbd:[Return] を押すとエコーモードに切り替わり、 タイプした文字がそのまま見えるようになるのです。 これは、 紙に印刷していたりするワンタイムパスワードを手で入力しなければならない場合に役立つ機能です。
|
||
|
||
次に、 このログインプロンプトに対して入力するワンタイムパスワードを生成してください。 これは、man:opiekey[1] プログラムを使える信頼できるマシン上で行わなければなりません。 このプログラムには Windows(R), Mac OS(R) および FreeBSD 版があります。 どちらも、 コマンドラインからシーケンス番号とシードを指定しなければなりません。 ログインしようとしているマシンのログインプロンプトから直接カットアンドペーストすると楽でしょう。
|
||
|
||
信頼できるシステムで
|
||
|
||
[source,bash]
|
||
....
|
||
% opiekey 498 to4268
|
||
Using the MD5 algorithm to compute response.
|
||
Reminder: Do not use opiekey from telnet or dial-in sessions.
|
||
Enter secret pass phrase:
|
||
GAME GAG WELT OUT DOWN CHAT
|
||
....
|
||
|
||
ワンタイムパスワードが生成されたので、 ログインを続けてください。
|
||
|
||
=== 複数のワンタイムパスワードを生成する
|
||
|
||
都合によっては、 信頼できるマシンや信頼できる通信路が一切確保できないようなことがあるでしょう。 このような場合には、man:opiekey[1] を使って複数のワンタイムパスワードを生成できます。 たとえば
|
||
|
||
[source,bash]
|
||
....
|
||
% opiekey -n 5 30 zz99999
|
||
Using the MD5 algorithm to compute response.
|
||
Reminder: Do not use opiekey from telnet or dial-in sessions.
|
||
Enter secret pass phrase: <secret password>
|
||
26: JOAN BORE FOSS DES NAY QUIT
|
||
27: LATE BIAS SLAY FOLK MUCH TRIG
|
||
28: SALT TIN ANTI LOON NEAL USE
|
||
29: RIO ODIN GO BYE FURY TIC
|
||
30: GREW JIVE SAN GIRD BOIL PHI
|
||
....
|
||
|
||
`-n 5` という引数によって 5 個のワンタイムパスワードを順に生成します。 また `30` は、 最後のシーケンス番号となるべき数字です。出力は使う順番とは _逆_ に出力されていることに注意してください (訳注: 一番最初に使うワンタイムパスワードは一番最後に出力されたものです)。 もしあなたがセキュリティに偏執するなら、 この結果を紙と鉛筆を使って手で書き移した方がよいかもしれません。 そうでなければ、この結果を印刷すると良いでしょう。 ここで、 出力の各行はシーケンス番号とそれに対応する一回分のワンタイムパスワードです。 消費済みのワンタイムパスワードをペンで消していってください。
|
||
|
||
=== UNIX(R) パスワードの利用を制限する
|
||
|
||
OPIE は、ログインセッションの IP アドレスをベースとした UNIX(R) パスワードの使用を制限できます。 関連ファイルは、[.filename]#/etc/opieaccess# で、 デフォルトで用意されています。 このファイルの詳細や、 このファイルを使用する際に考慮すべきセキュリィについては man:opieaccess[5] を確認してください。
|
||
|
||
以下は [.filename]#opieaccess# の例です。
|
||
|
||
[.programlisting]
|
||
....
|
||
permit 192.168.0.0 255.255.0.0
|
||
....
|
||
|
||
この行では、(なりすましされやすい) IP ソースアドレスが、 ある値やマスクにマッチするユーザに対して、 UNIX(R) パスワードをいつでも許可します。
|
||
|
||
もし [.filename]#opieaccess# のどのルールにも一致しなければ、 デフォルトでは非 OPIE ログインは使えません。
|
||
|
||
[[tcpwrappers]]
|
||
== TCP Wrappers
|
||
|
||
TCP Wrappers は、 すべてのサーバデーモンに対するサポートをその管理下で提供できるように、 crossref:advanced-networking[network-inetd,「inetd 「スーパサーバ」」] の機能を拡張します。 この方法を使うことで、ログへの対応、 接続に対してメッセージを返したり、 内部の接続だけを許可するようにデーモンを設定することが可能となります。 これらの機能のいくつかはファイアウォールでも実装できますが、 TCP Wrappers は、 システムを守るためのレイヤを追加し、 ファイアウォールが提供する以上の管理機能を提供します。
|
||
|
||
TCP Wrappers は、 適切に設定されたファイアウォールの置き換えと考えるべきではありません。 TCP Wrappers は、 ファイアウォールや他のセキュリティ強化のツールと組み合わせて使うべきです。
|
||
|
||
=== 初期設定
|
||
|
||
FreeBSD 上で TCP Wrappers を有効にするには、 [.filename]#rc.conf# から `-Ww` オプションで man:inetd[8] サーバが起動されることを確認してください。 その後、[.filename]#/etc/hosts.allow# を適切に設定してください。
|
||
|
||
[NOTE]
|
||
====
|
||
他の TCP Wrappers の実装と異なり、 [.filename]#hosts.deny# は廃止されました。 すべての設定オプションは [.filename]#/etc/hosts.allow# に書かれている必要があります。
|
||
====
|
||
|
||
最も簡単な設定におけるデーモンの接続ポリシは、 [.filename]#/etc/hosts.allow# の中で、 オプションごとに許可またはブロックするように設定するというものです。 FreeBSD のデフォルトの設定では、man:inetd[8] から起動されたすべてのデーモンの接続を許可します。
|
||
|
||
基本的な設定は、通常 `daemon : address : action` という形式です。ここで、 `daemon` は、 man:inetd[8] が起動するデーモンの名前です。 `address` の部分は、有効なホスト名、 IP アドレスまたは、 括弧 ([ ]) で囲まれた IPv6 アドレスです。 `action` は、 `allow` または `deny` です。 TCP Wrappers は、 最初にマッチしたルールが適用されます。 これは、設定ファイルに対するルールにマッチするかどうかのスキャンは、 昇順に行われることを意味しています。 マッチすると、ルールが適用され、 検索のプロセスは終了します。
|
||
|
||
例として、POP3 の接続を package:mail/qpopper[] デーモン経由で許可するには、以下の行を [.filename]#hosts.allow# に追加してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
# This line is required for POP3 connections:
|
||
qpopper : ALL : allow
|
||
....
|
||
|
||
この行を追加したら、 man:inetd[8] を再起動してください。
|
||
|
||
[source,bash]
|
||
....
|
||
# service inetd restart
|
||
....
|
||
|
||
=== 高度な設定
|
||
|
||
TCP Wrappers は、 接続を取り扱う以上の制御を行う高度な設定も提供しています。 ある時は、 接続しているホストまたはデーモンにコメントを返すことが適切であることがあります。 別の場合では、おそらくログエントリを記録したり、 管理者にメールで送る必要があることもあるでしょう。 またその他の状況としては、 サービスをローカルの接続のみの使用に制限する必要がある場合もあります。 これらはすべて、`ワイルドカード` と呼ばれる設定のオプション (拡張文字および外部コマンドの実行) で可能となります。
|
||
|
||
==== 外部コマンド
|
||
|
||
接続は拒否しなければならないが、 その理由を接続の確立を試みた相手に送りたい状況を考えてください。 このアクションは、`twist` を使うことで実現可能です。 接続が試みられると、`twist` はシェルコマンドまたはスクリプトを実行します。 この場合の例は、 [.filename]#hosts.allow# に書かれています。
|
||
|
||
[.programlisting]
|
||
....
|
||
# The rest of the daemons are protected.
|
||
ALL : ALL \
|
||
: severity auth.info \
|
||
: twist /bin/echo "You are not welcome to use %d from %h."
|
||
....
|
||
|
||
この例では、 "You are not allowed to use `daemon` from `hostname`." というメッセージを、 アクセスファイルの中で設定されていないすべてのデーモンに対して返します。 接続元に対し、 確立された接続が破棄された直後に返答することは有効です。 返信に使われるメッセージは、引用符 (`"`) で囲む _必要_ があります。
|
||
|
||
[WARNING]
|
||
====
|
||
攻撃者や攻撃者のグループは、 これらのデーモンの接続のリクエストであふれさせることにより、 サーバに対して DoS 攻撃を仕掛けることができます。
|
||
====
|
||
|
||
他の可能性は `spawn` を使うことです。 `twist` と同様に、 `spawn` は、暗黙のうちに接続を拒否し、 外部のシェルコマンドやスクリプトを実行できます。 `twist` と異なり、`spawn` は、 接続を確立した相手に対し、返事を返すことはありません。 たとえば、以下のような設定の行を考えてみてください。
|
||
|
||
[.programlisting]
|
||
....
|
||
# We do not allow connections from example.com:
|
||
ALL : .example.com \
|
||
: spawn (/bin/echo %a from %h attempted to access %d >> \
|
||
/var/log/connections.log) \
|
||
: deny
|
||
....
|
||
|
||
この行は、`*.example.com` からの接続をすべて拒否します。 ホスト名、IP アドレスおよびアクセスを試みたデーモンが、 [.filename]#/var/log/connections.log# に記録されます。
|
||
|
||
この例では、置換文字 `%a` および `%h` が使われています。 置換文字の完全な一覧は man:hosts_access[5] をご覧ください。
|
||
|
||
==== ワイルドカードオプション
|
||
|
||
`ALL` オプションは、 デーモン、ドメインまたは IP アドレスのすべてのインスタンスのどれかにマッチするかどうかに使われます。 他のワイルドカードは、偽造された IP アドレスを提供するホストにマッチするかどうかに用いられる `PARANOID` です。 たとえば、`PARANOID` を使うことで、 ホスト名と異なる IP アドレスからの接続があった時のアクションを定義できます。 以下の例では、ホスト名から検索される IP アドレスと異なる IP アドレスを持つ man:sendmail[8] への接続のすべてのリクエストを拒否します。
|
||
|
||
[.programlisting]
|
||
....
|
||
# Block possibly spoofed requests to sendmail:
|
||
sendmail : PARANOID : deny
|
||
....
|
||
|
||
[CAUTION]
|
||
====
|
||
クライアントもしくはサーバの DNS の設定が間違っている場合に、 `PARANOID` ワイルドカードを使うと、 サーバがとても使いづらくなります。 管理者の慎重さが求められます。
|
||
====
|
||
|
||
ワイルドカードおよび関連する機能についてもっと知りたい場合には、 man:hosts_access[5] をご覧ください。
|
||
|
||
上記の設定が動作するには、[.filename]#hosts.allow# の中で、 最初の設定の行がコメントアウトされている必要があります。
|
||
|
||
[[kerberos5]]
|
||
== Kerberos5
|
||
|
||
Kerberos は、 サーバのサービスによってユーザが安全に認証を受けられるようにするための、 ネットワークの付加システムおよびプロトコルです。 Kerberos は、 身元確認プロキシシステムや、 信頼される第 3 者認証システムとも説明されます。 ユーザが Kerberos を使って認証を行った後は、 通信は暗号化され、 プライバシおよびデータの完全性を保証することができます。
|
||
|
||
Kerberos の唯一の機能は、 ネットワーク上のユーザの安全な認証を提供することです。 承認 (どのユーザが許可されているか) や監査 (ユーザがどのような作業を行っているか) の機能は提供しません。 Kerberos を使う際は、 承認および監査サービスを提供する他のセキュリティの手段との利用が、 推奨されます。
|
||
|
||
この節では、FreeBSD 用として配布されている Kerberos をセットアップする際のガイドを提供します。 完全な説明が必要な場合には、 マニュアルページを参照してください。
|
||
|
||
この節における Kerberos のインストールのデモでは、以下のような名前空間が使われます。
|
||
|
||
* DNS ドメイン ("ゾーン") は、 `example.org` です。
|
||
* Kerberos の領域は、 `EXAMPLE.ORG` です。
|
||
|
||
[NOTE]
|
||
====
|
||
Kerberos の設定では、 内部での使用でも実際のドメイン名を使ってください。 DNS の問題を避けることができ、 他の Kerberos のレルム (realm) との相互運用を保証します。
|
||
====
|
||
|
||
=== 歴史
|
||
|
||
Kerberos は、 ネットワークのセキュリティ問題を解決するために、 MIT で開発されました。 Kerberos プロトコルは、 必ずしも安全ではないインターネット接続においても、 サーバに対して (逆もまた同様に)、 強い暗号を使って身元を証明します。
|
||
|
||
Kerberos は、 ネットワーク認証プロトコルの名前であり、 Kerberos telnet のように、 このプログラムを実装しているプログラムを表すための形容詞でもあります。 プロトコルの現在のバージョンはバージョン 5 で、 RFC 1510 として文書化されています。
|
||
|
||
このプロトコルのいくつものフリーの実装が、 さまざまなオペレーティングシステムで利用できます。 最初の Kerberos を開発したマサチューセッツ工科大学 (MIT) は、 開発した Kerberos パッケージを継続的に保守しています。 アメリカ合衆国では暗号製品として良く使われていますが、 歴史的には、 アメリカ合衆国 の輸出規制により制限されてきました。 MIT で実装された Kerberos は、 package:security/krb5[] package または port から利用できます。 バージョン 5 のもう一つの実装が、 Heimdal Kerberos です。 この実装は、アメリカ合衆国の外で開発されたため、 輸出の制限を避けることができます。 Heimdal Kerberos は package:security/heimdal[]> package または port からインストールできますが、最小構成は FreeBSD の base インストールに含まれています。
|
||
|
||
以下の説明では FreeBSD に含まれている Heimdal ディストリビューションの使用を想定しています。
|
||
|
||
=== Heimdal KDC の設定
|
||
|
||
鍵配布センター (KDC) は、 Kerberos が提供する中心的な認証サービスで、 Kerberos チケットを発行するコンピュータです。 KDC は、 Kerberos のレルムの中のすべてのコンピュータから "信頼"されています。 そのため、厳重なセキュリティに対する配慮が必要となります。
|
||
|
||
Kerberos サーバの実行にコンピュータのリソースはほとんど必要ありませんが、 セキュリティの観点から、KDC としてのみ機能する専用のコンピュータが推奨されます。
|
||
|
||
KDC を設定するにあたって、 KDC として動作するために、 適切に [.filename]#/etc/rc.conf# が設定されていることを確認してください。 必要に応じて、 システムの設定を反映するようにパスを調整する必要があります。
|
||
|
||
[.programlisting]
|
||
....
|
||
kerberos5_server_enable="YES"
|
||
kadmind5_server_enable="YES"
|
||
....
|
||
|
||
次に、[.filename]#/etc/krb5.conf# を以下のように編集してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
[libdefaults]
|
||
default_realm = EXAMPLE.ORG
|
||
[realms]
|
||
EXAMPLE.ORG = {
|
||
kdc = kerberos.example.org
|
||
admin_server = kerberos.example.org
|
||
}
|
||
[domain_realm]
|
||
.example.org = EXAMPLE.ORG
|
||
....
|
||
|
||
[.filename]#/etc/krb5.conf# の中で、 KDC は、 完全修飾されたホスト名 `kerberos.example.org` を使うことが想定されています。 KDC が異なるホスト名を持つ場合には、 名前の解決が行われるように、適切に CNAME (エイリアス) エントリをゾーンファイルに追加してください。
|
||
|
||
[NOTE]
|
||
====
|
||
適切に DNS サーバが設定されている大きなネットワークでは、 上記の例は、以下のように整理されます。
|
||
|
||
[.programlisting]
|
||
....
|
||
[libdefaults]
|
||
default_realm = EXAMPLE.ORG
|
||
....
|
||
|
||
そして、`example.org` ゾーンファイルには、以下の行が付け加えられます。
|
||
|
||
[.programlisting]
|
||
....
|
||
_kerberos._udp IN SRV 01 00 88 kerberos.example.org.
|
||
_kerberos._tcp IN SRV 01 00 88 kerberos.example.org.
|
||
_kpasswd._udp IN SRV 01 00 464 kerberos.example.org.
|
||
_kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org.
|
||
_kerberos IN TXT EXAMPLE.ORG
|
||
....
|
||
|
||
====
|
||
|
||
[NOTE]
|
||
====
|
||
クライアントが、 Kerberos サービスを見つけるためには、 [.filename]#/etc/krb5.conf# を完全に設定するか、 [.filename]#/etc/krb5.conf# を最低限に設定し、 _さらに_ DNS サーバを適切に設定する _必要_ があります。
|
||
====
|
||
|
||
次に Kerberos データベースを作成してください。 このデータベースには、 マスター鍵により暗号化されたすべてのプリンシパルの鍵が含まれています。 このパスワードは、 [.filename]#/var/heimdal/m-key# に保存されるため、 覚える必要はありません。 マスター鍵を作成するには、man:kstash[8] を実行して、 パスワードを入力してください。
|
||
|
||
マスター鍵を作成したら、`kadmin -l` を使ってデータベースを初期化してください。 このオプションを使うと、man:kadmin[8] は、 man:kadmind[8] ネットワークサービスを使わず、 ローカルのデータベースファイルを直接変更します。 これにより、 データベースを作成する前に、データベースへの接続を試みてしまうという、 卵が先か鶏が先かという問題を回避できます。 man:kadmin[8] プロンプトで、 `init` を使って、 レルムに関する初期のデータベースを作成してください。
|
||
|
||
最後に、man:kadmin[8] プロンプトで `add` を使って最初のプリンシパルを作成して下さい。 差し当たりは、 プリンシパルに対するデフォルトのオプションに従ってください。 後で `modify` を使うことで、 変更することができます。 man:kadmin[8] プロンプトで `?` と入力すると、 利用可能なオプションを確認できます。
|
||
|
||
データベース作成のセッションの例は以下のようになります。
|
||
|
||
[source,bash]
|
||
....
|
||
# kstash
|
||
Master key: xxxxxxxx
|
||
Verifying password - Master key: xxxxxxxx
|
||
|
||
# kadmin -l
|
||
kadmin> init EXAMPLE.ORG
|
||
Realm max ticket life [unlimited]:
|
||
kadmin> add tillman
|
||
Max ticket life [unlimited]:
|
||
Max renewable life [unlimited]:
|
||
Attributes []:
|
||
Password: xxxxxxxx
|
||
Verifying password - Password: xxxxxxxx
|
||
....
|
||
|
||
次に KDC サービスを起動してください。 `service kerberos start` および `service kadmind start` を実行してサービスを起動してください。 この時点で、kerberos 化されたデーモンが走っていなくても、 KDC のコマンドラインから、作成したばかりの (ユーザ) プリンシパルのチケットを入手したり、 一覧を表示することができることを確認できます。
|
||
|
||
[source,bash]
|
||
....
|
||
% kinit tillman
|
||
tillman@EXAMPLE.ORG's Password:
|
||
|
||
% klist
|
||
Credentials cache: FILE:/tmp/krb5cc_500
|
||
Principal: tillman@EXAMPLE.ORG
|
||
|
||
Issued Expires Principal
|
||
Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
|
||
....
|
||
|
||
必要がなくなった時には、チケットを破棄できます。
|
||
|
||
[source,bash]
|
||
....
|
||
% kdestroy
|
||
....
|
||
|
||
=== Heimdal Kerberos サービスを有効にする。
|
||
|
||
最初に [.filename]#/etc/krb5.conf# を KDC からクライアントコンピュータへ、 man:scp[1] または物理的にリムーバブルディスクを使うといった安全な方法でコピーしてください。
|
||
|
||
次に [.filename]#/etc/krb5.keytab# を作成してください。 これが Kerberos 化されたデーモンを提供するサーバとワークステーションの間での大きな違いです: サーバには [.filename]#keytab# が置かれている必要があります。 このファイルには、サーバのホスト鍵が含まれています。 この鍵により、ホストおよび KDC が他の身元の検証ができます。 鍵が公開されてしまうと、 サーバのセキュリティが破られてしまうため、 このファイルは安全にサーバに転送しなければなりません。
|
||
|
||
一般的には、man:kadmin[8] を使って、 [.filename]#keytab# をサーバに転送します。 ホストプリンシパル (KDC 側の [.filename]#krb5.keytab#) も man:kadmin[8] を使って作成するので便利です。
|
||
|
||
すでにチケットを入手し、そのチケットは、 man:kadmin[8] インタフェースで使用できることが [.filename]#kadmind.acl# で許可されている必要があります。 アクセスコントロールリストの設計の詳細については、 `info heimdal` の "Remote administration" というタイトルの章をご覧ください。 リモートからの `kadmin` アクセスを有効にする代わりに、 管理者は、ローカルコンソールまたは man:ssh[1] を用いて安全に KDC に接続し、 `kadmin -l` を使用して、 ローカルで管理作業を行うことができます。
|
||
|
||
[.filename]#/etc/krb5.conf# をインストールしたら、 Kerberos サーバから `add --random-key` を使ってください。 このコマンドは、サーバのホストプリンシパルを追加します。 そして、`ext` を用いて、 サーバのホストプリンシパルを keytab に抽出してください。 以下は、使用例です。
|
||
|
||
[source,bash]
|
||
....
|
||
# kadmin
|
||
|
||
kadmin> add --random-key host/myserver.example.org
|
||
Max ticket life [unlimited]:
|
||
Max renewable life [unlimited]:
|
||
Attributes []:
|
||
kadmin> ext host/myserver.example.org
|
||
kadmin> exit
|
||
....
|
||
|
||
`ext` は、デフォルトでは、抽出された鍵を [.filename]#/etc/krb5.keytab# に保存します。
|
||
|
||
KDC 上で man:kadmind[8] を走らせていない場合で、 リモートから man:kadmin[8] に接続出来ない場合には、 ホストプリンシパル (`host/myserver.EXAMPLE.ORG`) を直接 KDC 上で追加し、 その後、以下のように KDC 上の [.filename]#/etc/krb5.keytab# の上書きを避けるため、 一時ファイルに抽出してください。
|
||
|
||
[source,bash]
|
||
....
|
||
# kadmin
|
||
kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org
|
||
kadmin> exit
|
||
....
|
||
|
||
その後、man:scp[1] またはリムーバブルディスクを使って、 keytab を安全にサーバコンピュータにコピーしてください。 KDC 上の keytab を上書きすることを避けるため、 デフォルトとは異なる名前を指定してください。
|
||
|
||
これでサーバは、 [.filename]#krb5.conf# を使って KDC と通信ができるようになりました。 そして、[.filename]#krb5.keytab# によって身元を証明できるようになったので、 Kerberos サービスを有効にする準備が出来ました。 この例では、 man:telnetd[8] サービスが [.filename]#/etc/inetd.conf# で有効に設定され、 `service inetd restart` によって、 man:inetd[8] サービスを再起動します。
|
||
|
||
[.programlisting]
|
||
....
|
||
telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user
|
||
....
|
||
|
||
重要な変更箇所は、`-a` 認証がユーザに設定されていることです。 詳細については、 man:telnetd[8] を参照してください。
|
||
|
||
=== Heimdal Kerberos クライアントを有効にする
|
||
|
||
クライアントコンピュータの設定は簡単です。 [.filename]#/etc/krb5.conf# のみが必要です。 このファイルをセキュリティ的に安全な方法で、KDC からクライアントコンピュータへコピーしてください。
|
||
|
||
クライアントから、man:kinit[1], man:klist[1] および man:kdestroy[1] を使用し、 上記で作成したプリンシパルに対するチケットの入手、表示、 削除を行い、クライアントコンピュータを試験してください。 Kerberos アプリケーションを使って Kerberos が有効なサーバに接続することもできるはずです。 もしうまく機能しない場合でも、チケットを入手できるのであれば、 問題はおそらくサーバにあり、 クライアントまたは KDC の問題ではないと考えられます。
|
||
|
||
Kerberos 化されたアプリケーションを試験する際には、 man:tcpdump[1] といったパケットスニファを使用して、 パスワードが平文で送られていないことを確認してください。
|
||
|
||
コア以外の さまざまな Kerberos クライアントアプリケーションが利用可能です。 FreeBSD の "最小" インストールでは、 インストールされる Kerberos 化された唯一のサービスは、man:telnetd[8] です。
|
||
|
||
Heimdal port は、 Kerberos 化されている man:ftpd[8], man:rshd[8], man:rcp[1], man:rlogind[8] および他のあまり一般的ではないプログラムをインストールします。 MIT port も、すべての Kerberos クライアントアプリケーションをインストールします。
|
||
|
||
=== ユーザ設定ファイル: [.filename]#.k5login# および [.filename]#.k5users#
|
||
|
||
レルムのユーザは、一般的には、 ローカルユーザアカウントに対応する Kerberos プリンシパルを持ちます。 しかしながら、時々 Kerberos プリンシパルに対応しないローカルユーザアカウントへのアクセスが必要となることがあります。 たとえば、 `tillman@EXAMPLE.ORG` が、ローカルユーザアカウント `webdevelopers` へのアクセスが必要となることがあります。そして、 他のプリンシパルが同じローカルアカウントにアクセスが必要になることもあります。
|
||
|
||
ユーザのホームディレクトリに置かれた [.filename]#.k5login# および [.filename]#.k5users# ファイルを使うことで、 この問題を解決出来ます。 たとえば、以下の行を含む [.filename]#.k5login# を `webdevelopers` のホームディレクトリに置くと、 一覧にある両方のプリンシパルは、 共有のパスワードを必要としなくても、 このアカウントにアクセス出来ます。
|
||
|
||
[source,bash]
|
||
....
|
||
tillman@example.org
|
||
jdoe@example.org
|
||
....
|
||
|
||
[.filename]#.k5users# の詳細については、 man:ksu[1] を参照してください。
|
||
|
||
=== Kerberos Tips, Tricks, およびトラブルシューティング
|
||
|
||
* Heimdal または MITKerberos ports のどちらを使う場合でも、 `PATH` は、 Kerberos 版のクライアント アプリケーションが、 システムにあるアプリケーションより先に見つかるように設定されていることを確認してください。
|
||
* レルムにあるすべてのコンピュータの間で時刻が同期していないと、 認証に失敗してしまいます。 NTP を用いた、時刻の同期方法については、 crossref:advanced-networking[network-ntp,「NTP」] をご覧ください。
|
||
* MIT および Heimdal 間の運用は、 標準化されていない man:kadmin[8] を除けばうまく機能します。
|
||
* ホスト名が変更された場合は、 `host/` プリンシパルを変更し、keytab をアップデートする必要があります。 Apache の package:www/mod_auth_kerb[] で使われる `www/` プリンシパルのような特別な keytab エントリでも必要となります。
|
||
* レルムの中のすべてのホストは、DNS、 もしくは、最低限 [.filename]#/etc/hosts# において正引きおよび逆引き両方で名前解決できる必要があります。 CNAME は動作しますが、A および PTR レコードは、 正しく適切な位置に記述されている必要があります。 名前が解決できない場合のエラーメッセージは、 次の例のように、直感的に原因が分かるようなものではありません。 `Kerberos5 refuses authentication because Read req failed: Key table entry not found`.
|
||
* KDC に対しクライアントとして振る舞うオペレーティングシステムの中には、 man:ksu[1] に対して、 `root` 権限に setuid を許可しないものがあります。 この設定では、 man:ksu[1] は動作しないことを意味します。 これは KDC のエラーではありません。
|
||
* MITKerberos において、 プリンシパルが、デフォルトの 10 時間を超えるチケットの有効期限としたい場合には、 man:kadmin[8] のプロンプトで `modify_principal` を使って、 対象のプリンシパルおよび `krbtgt` プリンシパル両方の有効期限の最大値を変更してください。 プリンシパルは、 `kinit -l` を使用して、 長い有効期限のチケットを要求できます。
|
||
*
|
||
[NOTE]
|
||
====
|
||
トラブルシューティングのために、 KDC でパケットスニファを走らせ、 一方で、ワークステーションにおいて man:kinit[1] を実行すると、 man:kinit[1] を実行するやいなや、 パスワードを入力し終わる前でも、 Ticket Granting Ticket (TGT) が送られてきます。 これに関する説明は、以下の通りです。 Kerberos サーバは、 いかなる未承認のリクエストに対して、 自由に TGT を送信します。 しかしながら、すべての TGT は、 ユーザのパスワードから生成された鍵により、暗号化されています。 そのため、ユーザがパスワードを入力した時には、 パスワードは KDC には送られません。 その代わりこのパスワードは、man:kinit[1] がすでに入手した TGT の復号化に使われます。 もし、復号化の結果、 有効なチケットで有効なタイムスタンプの場合には、 ユーザは、有効な Kerberos クレデンシャルを持ちます。 このクレデンシャルには、 Kerberos サーバ自身の鍵により暗号化された実際の TGT とともに、将来 Kerberos サーバと安全な通信を確立するためのセッション鍵が含まれています。 この暗号の 2 番目のレイヤは、 Kerberos サーバが、 各 TGT の真偽の検証を可能にしている部分です。
|
||
====
|
||
|
||
* たとえば一週間といった長い有効期限のチケットを使いたい場合で、 OpenSSH を使って、 チケットが保存されているコンピュータに接続しようとする場合は、 Kerberos `TicketCleanup` が [.filename]#sshd_config# において `no` と設定されているか、 チケットが、ログアウト時に削除されることを確認してください。
|
||
* ホストプリンシパルは長い有効期限のチケットを持つことができます。 もし、ユーザプリンシパルが 1 週間の有効期限を持ち、 接続しているホストが、9 時間の有効期限を持っている場合には、 ユーザキャッシュは有効期限が切れたホストプリンシパルを持つことになり、 想定したように、 チケットキャッシュが振る舞わないことが起こりえます。
|
||
* man:kadmind[8] で説明されているような、 特定の問題のあるパスワードが使われることを避けるために [.filename]#krb5.dict# を設定する時には、 パスワードポリシが割り当てられたプリンシパルにのみ適用されることを覚えていてください。 [.filename]#krb5.dict# で使われている形式では、 一行に一つの文字列が置かれています。 [.filename]#/usr/share/dict/words# にシンボリックリンクを作成することは、有効です。
|
||
|
||
=== MIT port との違いについて
|
||
|
||
MIT と Heimdal 版の大きな違いは、 man:kadmin[8] に関連しています。 このプログラムは、異なる (ただし等価な) コマンド群を持ち、そして、 異なるプロトコルを使用します。 もし KDC に MIT を使用している場合には、 Heimdal 版の man:kadmin[8] を使って KDC をリモートから (逆も同様に) 管理できないことを意味しています。
|
||
|
||
クライアントアプリケーションでは、同じタスクを行う際に、 若干異なるコマンドラインのオプションが使われることもあります。 MIT Kerberos link:http://web.mit.edu/Kerberos/www/[ウェブサイト] に書かれているガイドに従うことが推奨されます。 path の問題について注意してください。 MIT port はデフォルトで [.filename]#/usr/local/# にインストールします。 そのため、もし `PATH` においてシステムのディレクトが最初に書かれている場合には、 MIT 版ではなく、"通常の" システムアプリケーションが起動してしまいます。
|
||
|
||
[NOTE]
|
||
====
|
||
FreeBSD の MITpackage:security/krb5[] port において、 man:telnetd[8] および `klogind` 経由でのログインが奇妙な振る舞いをすることを理解するには、 port からインストールされる [.filename]#/usr/local/share/doc/krb5/README.FreeBSD# を読んで下さい。 "incorrect permissions on cache file" の振る舞いを修正するには、 フォワードされたクレデンシャリングの所有権を適切に変更できるように、 `login.krb5` バイナリが認証に使われる必要があります。
|
||
====
|
||
|
||
[.filename]#rc.conf# を以下のように変更する必要もあります。
|
||
|
||
[.programlisting]
|
||
....
|
||
kerberos5_server="/usr/local/sbin/krb5kdc"
|
||
kadmind5_server="/usr/local/sbin/kadmind"
|
||
kerberos5_server_flags=""
|
||
kerberos5_server_enable="YES"
|
||
kadmind5_server_enable="YES"
|
||
....
|
||
|
||
これを行うのは、 MIT Kerberos のアプリケーションは、 [.filename]#/usr/local# 構造の下にインストールされるためです。
|
||
|
||
=== Kerberos で見つかった制限を緩和する
|
||
|
||
==== Kerberos は、All or Nothing アプローチです。
|
||
|
||
ネットワーク上で有効なすべてのサービスは、 Kerberos 化されるか、 または、ネットワーク攻撃に対して安全であるべきです。 さもないと、ユーザのクレデンシャルが盗まれ、 利用されることが起きるかもしれません。 この例は、 Kerberos 化されたすべてのリモートシェルです。 パスワードを平文で送るような POP3 メールサーバは変換していません。
|
||
|
||
==== Kerberos は、 シングルユーザのワークステーションでの使用を想定しています。
|
||
|
||
マルチユーザの環境では、 Kerberos は安全ではありません。 チケットは [.filename]#/tmp# に保管され、 このチケットは、すべてのユーザが読むことができるためです。 もし、ユーザがコンピュータを他のユーザと同時に共有していると、 他のユーザは、そのユーザのチケットを盗んだり、 コピーが出来てしまいます。
|
||
|
||
この問題は、`-c` コマンドラインオプションまたは、好ましくは `KRB5CCNAME` 環境変数によって克服されます。 この問題への対応には、 チケットをユーザのホームディレクトリに保存し、 ファイルの許可属性を設定することが一般的に行われます。
|
||
|
||
==== KDC は、単一障害点である
|
||
|
||
設計上、KDC は、 マスターパスワードのデータベースと同様に安全である必要があります。 KDC では、 絶対に他のサービスを走らせるべきではありませんし、 物理的に安全であるべきです。 Kerberos は、 KDC 上で、ファイルとして保存されている同じ "マスター" 鍵で暗号化されたすべてのパスワードを保存しているので、 非常に危険です。
|
||
|
||
マスター鍵が漏洩しても、 懸念するほど悪いことにはなりません。 マスター鍵は、Kerberos データベースの暗号時にのみ、 乱数を生成するためのシードとして使われます。 KDC へのアクセスが安全である限りにおいては、 マスター鍵を用いて、それほど多くのことはできません。
|
||
|
||
さらに、KDC が利用できないと、 認証ができないため、ネットワークサービスを利用できなくなります。 この攻撃による被害は、 ひとつのマスタ KDC とひとつまたはそれ以上のスレーブ、 そして、セカンダリもしくは PAM を用いたフォールバック認証を注意深く実装することにより軽減できます。
|
||
|
||
==== Kerberos の欠点
|
||
|
||
Kerberos は、 ユーザ、ホストおよびサービスの間での認証を可能にしますが、 KDC とユーザ、 ホストまたはサービスとの間の認証のメカニズムは提供しません。 これは、トロイの木馬の man:kinit[1] が、 すべてのユーザ名とパスワードを記録できることを意味しています。 package:security/tripwire[] のような、ファイルシステムの完全性を確認するためのツールにより、 この危険性を軽減することができます。
|
||
|
||
=== Kerberos および man:ssh[1] を用いたアクセスの問題
|
||
|
||
Kerberos と man:ssh[1] を使う場合には、 両者に関して知っておかねばならない問題がいくつかあります。 Kerberos は大変優れた認証プロトコルですが、Kerberos 化された man:telnet[1] および man:rlogin[1] には、 バイナリストリームを扱うのに不向きになるようなバグがあります。 デフォルトでは、Kerberos は `-x` を使わない限りセッションを暗号化してくれません。 一方 man:ssh[1] では、 デフォルトですべてを暗号化してくれます。
|
||
|
||
man:ssh[1] はとても良く動作しますが、 デフォルトで暗号鍵を転送してしまいます。 このため、man:ssh[1] を安全なワークステーションから、 安全でないマシンへのアクセスに使っているユーザに、 セキュリティリスクを引き起こします。 鍵そのものが見えてしまうわけではありませんが、 man:ssh[1] は login している間、転送用ポートを作ります。 攻撃者が安全でないマシンの `root` を破ったら、 このポートを使って、 この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。
|
||
|
||
可能な時はいつでも、スタッフのログインには Kerberos を組み合せた man:ssh[1] を使用することを勧めます。 man:ssh[1] は、Kerberos 対応機能と一緒にコンパイルできます。 このようにすることで、見えてしまう可能性のある SSH 鍵への依存を減らし、 一方で、Kerberos 経由によりパスワードが保護されます。 鍵は、安全なマシンからの自動化されたタスクのみに使用すべきです。 Kerberos はこの用途には不向きです。 また、SSH の設定で鍵転送をしないようにするか、 あるいは [.filename]#authorized_keys# の `from=IP/DOMAIN` を使用して、 特定のマシンからログインしてきたときのみ鍵が有効にすることをお勧めします。
|
||
|
||
=== リソースおよび他の情報源
|
||
|
||
* http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html[The Kerberos FAQ]
|
||
* http://web.mit.edu/Kerberos/www/dialogue.html[Designing an Authentication System: a Dialog in Four Scenes]
|
||
* http://www.ietf.org/rfc/rfc1510.txt?number=1510[RFC 1510, The Kerberos Network Authentication Service (V5)]
|
||
* http://web.mit.edu/Kerberos/www/[MIT Kerberos home page]
|
||
* http://www.pdc.kth.se/heimdal/[Heimdal Kerberos home page]
|
||
|
||
[[openssl]]
|
||
== OpenSSL
|
||
|
||
FreeBSD には、OpenSSL ツールキットが含まれています。 OpenSSL は、 通常の通信層の上位にあるトランスポート層を暗号化し、 多くのネットワークアプリケーションおよびサービスと組み合わせて使用できます。
|
||
|
||
OpenSSL は、 メールクライアントの暗号化された認証、 クレジットカードでの支払いといったウェブベースの取引などで使われます。 package:www/apache22[] および package:mail/claws-mail[] といった多くの port では、 OpenSSL とともに構築するコンパイルに対応しています。
|
||
|
||
[NOTE]
|
||
====
|
||
多くの場合、Ports Collection は、 make の `WITH_OPENSSL_BASE` が明示的に "yes" に設定されていないと、 package:security/openssl[] port の構築を試みます。
|
||
====
|
||
|
||
FreeBSD に含まれている OpenSSL のバージョンは、Secure Sockets Layer v2/v3 (SSLv2/SSLv3) および Transport Layer Security v1 (TLSv1) ネットワークセキュリティプロトコルに対応しており、 多目的な暗号化ライブラリとして使うことができます。
|
||
|
||
[NOTE]
|
||
====
|
||
OpenSSL は、 IDEA アルゴリズムに対応していますが、 合衆国の特許により、デフォルトでは無効になっています。 もし使用したいのであれば、ライセンス条項を必ず確認し、 ライセンス条項に合致するのであれば、 [.filename]#/etc/make.conf# において `MAKE_IDEA` 変数を設定してください。
|
||
====
|
||
|
||
最も一般的な OpenSSL の利用方法のひとつは、 ソフトウェアアプリケーションが使えるように証明書を提供することです。 これらの証明書により、会社または個人の公開鍵が、 改ざんやなりすましが行われていないことを確認できます。 もし問題となっている証明書が、"認証局" (CA) により検証されなければ、 警告が表示されます。 CA は、link:http://www.verisign.com[VeriSign] のような会社で、個人または会社の公開鍵の検証を行えるように、 証明書に署名を行います。 証明書を作成するには費用がかかり、 証明書の使用は必要条件ではありませんが、 証明書を使うことで、 ユーザを安心させることができます。
|
||
|
||
=== 証明書の作成
|
||
|
||
以下のコマンドにより、証明書を作成できます。
|
||
|
||
[source,bash]
|
||
....
|
||
# openssl req -new -nodes -out req.pem -keyout cert.pem
|
||
Generating a 1024 bit RSA private key
|
||
................++++++
|
||
.......................................++++++
|
||
writing new private key to 'cert.pem'
|
||
-----
|
||
You are about to be asked to enter information that will be incorporated
|
||
into your certificate request.
|
||
What you are about to enter is what is called a Distinguished Name or a DN.
|
||
There are quite a few fields but you can leave some blank
|
||
For some fields there will be a default value,
|
||
If you enter '.', the field will be left blank.
|
||
-----
|
||
Country Name (2 letter code) [AU]:US
|
||
State or Province Name (full name) [Some-State]:PA
|
||
Locality Name (eg, city) []:Pittsburgh
|
||
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
|
||
Organizational Unit Name (eg, section) []:Systems Administrator
|
||
Common Name (eg, YOUR name) []:localhost.example.org
|
||
Email Address []:trhodes@FreeBSD.org
|
||
|
||
Please enter the following 'extra' attributes
|
||
to be sent with your certificate request
|
||
A challenge password []:SOME PASSWORD
|
||
An optional company name []:Another Name
|
||
....
|
||
|
||
"Common Name" プロンプト直後に表示されているのは、 ドメイン名です。 このプロンプトでは、検証するサーバ名の入力が必要となります。 ドメイン名以外を入力すると、役に立たない証明書が作成されます。 他のオプションとして、有効期限を指定したり、 別の暗号化アルゴリズムを選択することができます。 オプションの完全なリストは、 man:openssl[1] で説明されています。
|
||
|
||
このコマンドを実行したディレクトリには、 2 つのファイルが作成されているはずです。 1 つは、証明書要求 [.filename]#req.pem# です。 このファイルを CA に送ると、 CA は含まれている内容を検証し、 検証に成功すると、証明書要求に署名を行い、 作成された証明書を送り返します。 もうひとつ、[.filename]#cert.pem# と呼ばれるファイルが生成されます。 これは証明書の秘密鍵であり、 どのようなことがあっても保護しなくてはなりません。 もし、他の人の手に渡ると、手に入れた人は、 ユーザまたはサーバになりすますことができてしまいます。
|
||
|
||
CA の署名が必要ない場合には、 自己署名証明書を作成できます。 最初に RSA の鍵を生成してください。
|
||
|
||
[source,bash]
|
||
....
|
||
# openssl dsaparam -rand -genkey -out myRSA.key 1024
|
||
....
|
||
|
||
次に、CA 鍵を生成してください。
|
||
|
||
[source,bash]
|
||
....
|
||
# openssl gendsa -des3 -out myca.key myRSA.key
|
||
....
|
||
|
||
この鍵を使って証明書を作成してください。
|
||
|
||
[source,bash]
|
||
....
|
||
# openssl req -new -x509 -days 365 -key myca.key -out new.crt
|
||
....
|
||
|
||
新しく 2 つのファイルがこのディレクトリに作成されます。 プライベート鍵 [.filename]#myca.key# および 証明書 [.filename]#new.crt# です。 これらのファイルを、好ましくは [.filename]#/etc# 以下で、 `root` のみが読むことのできるディレクトリに置く必要があります。 許可属性は 0700 が適切です。 許可属性は man:chmod[1] を使って設定できます。
|
||
|
||
=== 証明書の使用
|
||
|
||
証明書の一つの利用方法は、SendmailMTA への接続を暗号化することです。 これにより、 ローカルの MTA 経由でメールを送信するユーザが、 テキスト認証を使用しなくてもすむようになります。
|
||
|
||
[NOTE]
|
||
====
|
||
いくつかの MUA は、 ユーザが証明書をローカルにインストールしていないと、 エラーを出力します。 証明書のインストールに関する詳細な情報については、 ソフトウェアに付随の文書を参照してください。
|
||
====
|
||
|
||
Sendmail を設定するには、以下の行をローカルの [.filename]#.mc# ファイルに含めてください。
|
||
|
||
[.programlisting]
|
||
....
|
||
dnl SSL Options
|
||
define(`confCACERT_PATH',`/etc/certs')dnl
|
||
define(`confCACERT',`/etc/certs/new.crt')dnl
|
||
define(`confSERVER_CERT',`/etc/certs/new.crt')dnl
|
||
define(`confSERVER_KEY',`/etc/certs/myca.key')dnl
|
||
define(`confTLS_SRV_OPTIONS', `V')dnl
|
||
....
|
||
|
||
この例では、 ローカルで証明書および鍵ファイルは、ローカルの [.filename]#/etc/certs/# に置かれています。 ファイルの編集を保存し終わったら、 [.filename]#/etc/mail# において `make install` と入力することで、ローカルの [.filename]#.cf# ファイルを再構築する必要があります。 その後、`make restart` と入力して、Sendmail デーモンを再起動してください。
|
||
|
||
すべてがうまくいっていれば、 [.filename]#/var/log/maillog# にはエラーメッセージは出力されず、 Sendmail がプロセスの一覧に表示されます。
|
||
|
||
以下は簡単な試験の例で、man:telnet[1] を使って、 メールサーバに接続しています。
|
||
|
||
[source,bash]
|
||
....
|
||
# telnet example.com 25
|
||
Trying 192.0.34.166...
|
||
Connected to example.com
|
||
Escape character is '^]'.
|
||
220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT)
|
||
ehlo example.com
|
||
250-example.com Hello example.com [192.0.34.166], pleased to meet you
|
||
250-ENHANCEDSTATUSCODES
|
||
250-PIPELINING
|
||
250-8BITMIME
|
||
250-SIZE
|
||
250-DSN
|
||
250-ETRN
|
||
250-AUTH LOGIN PLAIN
|
||
250-STARTTLS
|
||
250-DELIVERBY
|
||
250 HELP
|
||
quit
|
||
221 2.0.0 example.com closing connection
|
||
Connection closed by foreign host.
|
||
....
|
||
|
||
出力に "STARTTLS" 行が表示されれば、 すべてが適切に機能しています。
|
||
|
||
[[ipsec]]
|
||
== VPN over IPsec
|
||
|
||
=== IPsec を理解する
|
||
|
||
この節では、IPsec を設定する過程を説明します。 IPsec を設定するためには、 カスタムカーネルの構築方法をよく知っている必要があります (crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] をご覧ください)。
|
||
|
||
_IPsec_ は、インターネットプロトコル (IP) レイヤのトップにあるプロトコルです。 二つもしくはそれ以上のホスト間で安全に通信することを可能にします。 FreeBSD の IPsec "ネットワークスタック" は、 IPv4 および IPv6 の両方に対応している http://www.kame.net/[KAME] 実装をベースとしています。
|
||
|
||
IPsec は二つのサブプロトコルから構成されます。
|
||
|
||
* _Encapsulated Security Payload (ESP)_: このプロトコルは、Blowfish, 3DES といった対称暗号アルゴリズムを使ってデータを暗号化することで、 サードパーティのインタフェースから IP パケットデータを保護します。
|
||
* _Authentication Header AH(AH)_: このプロトコルは、暗号チェックサムを計算し、IP パケットのヘッドフィールドを安全なハッシュ関数でハッシュ化することで、 IP パケットヘッダをサードパーティのインタフェースやなりすましから守ります。 ハッシュを含む追加のヘッダが追加され、 パケット情報の検証が可能になります。
|
||
|
||
ESP および AH は、使用する環境に合わせて、 一緒に使うことも別々に使うこともできます。
|
||
|
||
IPsec は、直接二つのホスト間のトラフィックを暗号化する _Transport Mode_、もしくは "virtual tunnels" を構築する _Tunnel Mode_ のどちらでも用いることができます。 後者のモードはより一般的には、 _Virtual Private Network (VPN)_ として知られています。 FreeBSD での IPsec サブシステムに関するより詳細な情報については、 man:ipsec[4] を参照してください。
|
||
|
||
カーネルに IPsec のサポートを追加するには、 カスタムカーネルコンフィグレーションファイルに以下のオプションを追加してください。
|
||
|
||
[source,bash]
|
||
....
|
||
options IPSEC #IP security
|
||
device crypto
|
||
....
|
||
|
||
IPsec のデバッグサポートが必要であれば、 以下のカーネルオプションを追加してください。
|
||
|
||
[source,bash]
|
||
....
|
||
options IPSEC_DEBUG #debug for IP security
|
||
....
|
||
|
||
=== 家庭と会社間の VPN
|
||
|
||
VPN の構成についての標準はありません。 VPN は、数多くの技術と共に実装することが可能です。 その各技術には、それ自身の長所と短所があります。 この節では、以下のシナリオに対して VPN を実装する戦略について説明します。
|
||
|
||
* 少なくとも 2 つのサイトがあり、 それぞれのサイトは内部で IP を使っています。
|
||
* 2 つのサイトは、FreeBSD で運用されているゲートウェイを通して、 インターネットに接続しています。
|
||
* それぞれのネットワークのゲートウェイは、 少なくとも一つのパブリック IP アドレスを持っています。
|
||
* 2 つのネットワークの内部アドレスは、 パブリックでもプライベート IP アドレスでも構いません。 しかしながら、アドレス空間は衝突してはいけません。 たとえば、両方のネットワークが `192.168.1.x` を使ってはいけません。
|
||
|
||
==== FreeBSD 上で IPsec を設定する。
|
||
|
||
最初に Ports Collection から package:security/ipsec-tools[] をインストールしてください。 このソフトウェアは、 設定をサポートする数多くのアプリケーションを提供します。
|
||
|
||
次に、パケットをトンネリングし、 両方のネットワークが適切に通信するように、 2 つの man:gif[4] 疑似デバイスを作成します。 `root` 権限で以下のコマンドを実行してください。 ただし、実行する際には、以下のコマンドの中の _internal_ および _external_ を、 2 つのゲートウェイの内部および外部インタフェースの実際の IP アドレスに置き換えてください。
|
||
|
||
[source,bash]
|
||
....
|
||
# ifconfig gif0 create
|
||
....
|
||
|
||
[source,bash]
|
||
....
|
||
# ifconfig gif0 internal1 internal2
|
||
....
|
||
|
||
[source,bash]
|
||
....
|
||
# ifconfig gif0 tunnel external1 external2
|
||
....
|
||
|
||
この例では、会社の LAN の外部 IP アドレスを `172.16.5.4`、 内部 IP アドレスを `10.246.38.1` とします。また、家庭 LAN の外部 IP アドレスを `192.168.1.12`、 内部のプライベート IP アドレスを `10.0.0.5` とします。
|
||
|
||
この説明で分かりにくい場合は、以下の man:ifconfig[8] コマンドの出力例をご覧ください。
|
||
|
||
[.programlisting]
|
||
....
|
||
Gateway 1:
|
||
|
||
gif0: flags=8051 mtu 1280
|
||
tunnel inet 172.16.5.4 --> 192.168.1.12
|
||
inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6
|
||
inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00
|
||
|
||
Gateway 2:
|
||
|
||
gif0: flags=8051 mtu 1280
|
||
tunnel inet 192.168.1.12 --> 172.16.5.4
|
||
inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00
|
||
inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4
|
||
....
|
||
|
||
設定が完了したら、両方の内部 IP アドレスは、man:ping[8] で到達できるようになっているはずです。
|
||
|
||
[.programlisting]
|
||
....
|
||
priv-net# ping 10.0.0.5
|
||
PING 10.0.0.5 (10.0.0.5): 56 data bytes
|
||
64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms
|
||
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms
|
||
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms
|
||
64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms
|
||
--- 10.0.0.5 ping statistics ---
|
||
4 packets transmitted, 4 packets received, 0% packet loss
|
||
round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms
|
||
|
||
corp-net# ping 10.246.38.1
|
||
PING 10.246.38.1 (10.246.38.1): 56 data bytes
|
||
64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms
|
||
64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms
|
||
64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms
|
||
64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms
|
||
64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms
|
||
--- 10.246.38.1 ping statistics ---
|
||
5 packets transmitted, 5 packets received, 0% packet loss
|
||
round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms
|
||
....
|
||
|
||
予想通り、プライベートアドレスを使って、 両方のネットワークから ICMP パケットを送受信できます。 次に、どちらのネットワークからもメッセージを送信できるように、 パケットのルーティング情報を両方のゲートウェイに設定する必要があります。 これは以下のコマンドで設定できます。
|
||
|
||
[source,bash]
|
||
....
|
||
# corp-net# route add 10.0.0.0 10.0.0.5 255.255.255.0
|
||
....
|
||
|
||
[source,bash]
|
||
....
|
||
# corp-net# route add net 10.0.0.0: gateway 10.0.0.5
|
||
....
|
||
|
||
[source,bash]
|
||
....
|
||
# priv-net# route add 10.246.38.0 10.246.38.1 255.255.255.0
|
||
....
|
||
|
||
[source,bash]
|
||
....
|
||
# priv-net# route add host 10.246.38.0: gateway 10.246.38.1
|
||
....
|
||
|
||
これで、ネットワーク内のコンピュータは、 ゲートウェイおよびゲートウェイの奥のコンピュータから到達可能となっています。 もう一度 man:ping[8] で確認してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
corp-net# ping 10.0.0.8
|
||
PING 10.0.0.8 (10.0.0.8): 56 data bytes
|
||
64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms
|
||
64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms
|
||
64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms
|
||
64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms
|
||
64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms
|
||
--- 10.0.0.8 ping statistics ---
|
||
5 packets transmitted, 5 packets received, 0% packet loss
|
||
round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms
|
||
|
||
priv-net# ping 10.246.38.107
|
||
PING 10.246.38.1 (10.246.38.107): 56 data bytes
|
||
64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms
|
||
64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms
|
||
64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms
|
||
64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms
|
||
64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms
|
||
--- 10.246.38.107 ping statistics ---
|
||
5 packets transmitted, 5 packets received, 0% packet loss
|
||
round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms
|
||
....
|
||
|
||
トンネリングの設定は以上のように簡単ですが、 リンクを安全にするには、もう少し掘り下げた設定が必要となります。 以下の設定では、事前共有 (PSK) RSA 鍵を使います。 IP アドレスを除けば、両方のゲートウェイの [.filename]#/usr/local/etc/racoon/racoon.conf# は同じで、以下のようになります。
|
||
|
||
[.programlisting]
|
||
....
|
||
path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file
|
||
log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete
|
||
|
||
padding # options are not to be changed
|
||
{
|
||
maximum_length 20;
|
||
randomize off;
|
||
strict_check off;
|
||
exclusive_tail off;
|
||
}
|
||
|
||
timer # timing options. change as needed
|
||
{
|
||
counter 5;
|
||
interval 20 sec;
|
||
persend 1;
|
||
# natt_keepalive 15 sec;
|
||
phase1 30 sec;
|
||
phase2 15 sec;
|
||
}
|
||
|
||
listen # address [port] that racoon will listen on
|
||
{
|
||
isakmp 172.16.5.4 [500];
|
||
isakmp_natt 172.16.5.4 [4500];
|
||
}
|
||
|
||
remote 192.168.1.12 [500]
|
||
{
|
||
exchange_mode main,aggressive;
|
||
doi ipsec_doi;
|
||
situation identity_only;
|
||
my_identifier address 172.16.5.4;
|
||
peers_identifier address 192.168.1.12;
|
||
lifetime time 8 hour;
|
||
passive off;
|
||
proposal_check obey;
|
||
# nat_traversal off;
|
||
generate_policy off;
|
||
|
||
proposal {
|
||
encryption_algorithm blowfish;
|
||
hash_algorithm md5;
|
||
authentication_method pre_shared_key;
|
||
lifetime time 30 sec;
|
||
dh_group 1;
|
||
}
|
||
}
|
||
|
||
sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/$netmask $type address $network/$netmask $type ( $type being any or esp)
|
||
{ # $network must be the two internal networks you are joining.
|
||
pfs_group 1;
|
||
lifetime time 36000 sec;
|
||
encryption_algorithm blowfish,3des,des;
|
||
authentication_algorithm hmac_md5,hmac_sha1;
|
||
compression_algorithm deflate;
|
||
}
|
||
....
|
||
|
||
利用可能なオプションの説明については、 racoon のマニュアルページを参照してください。
|
||
|
||
FreeBSD および racoon がホスト間のネットワークトラフィックを暗号化、 復号化できるようにするには、 Security Policy Database (SPD) の設定が必要です。
|
||
|
||
これは、会社のゲートウェイ上で、 以下のようなシェルスクリプトで設定できます。 このファイルをシステムの初期化中に使われるようにするには、 [.filename]#/usr/local/etc/racoon/setkey.conf# に保存する必要があります。
|
||
|
||
[.programlisting]
|
||
....
|
||
flush;
|
||
spdflush;
|
||
# To the home network
|
||
spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use;
|
||
spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use;
|
||
....
|
||
|
||
設定ファイルを適切に置くと、以下のコマンドにより、 両方のゲートウェイ上で racoon を起動できます。
|
||
|
||
[source,bash]
|
||
....
|
||
# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log
|
||
....
|
||
|
||
出力は以下のようになるでしょう。
|
||
|
||
[.programlisting]
|
||
....
|
||
corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf
|
||
Foreground mode.
|
||
2006-01-30 01:35:47: INFO: begin Identity Protection mode.
|
||
2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon
|
||
2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon
|
||
n2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a
|
||
2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
|
||
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2)
|
||
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426)
|
||
2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
|
||
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b)
|
||
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66)
|
||
....
|
||
|
||
トンネリングが適切に行われているかどうかを確認するため、 別のコンソール上で man:tcpdump[1] を使い、 以下のようなコマンドでネットワークの通信を確認してください。 ただし、以下の例の `em0` の部分は、 必要に応じて使用しているネットワークインタフェースに置き換えてください。
|
||
|
||
[source,bash]
|
||
....
|
||
# tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12
|
||
....
|
||
|
||
以下のようなデータがコンソールに表示されます。 もし、表示されない場合は、設定に何か問題があるので、 表示されるデータを使ってデバッグする必要があります。
|
||
|
||
[.programlisting]
|
||
....
|
||
01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa)
|
||
01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb)
|
||
01:47:34.024218 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc)
|
||
....
|
||
|
||
これで 2 つのネットワークは、 1 つのネットワークのように利用できます。 多くの場合、 両方のネットワークはファイアウォールにより保護されています。 両方を流れる通信を許可するには、 パケットが両方を行き来できるようにルールを追加する必要があります。 man:ipfw[8] を使ったファイアウォールの場合は、 ファイアウォールの設定ファイルに、以下の行を追加してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
ipfw add 00201 allow log esp from any to any
|
||
ipfw add 00202 allow log ah from any to any
|
||
ipfw add 00203 allow log ipencap from any to any
|
||
ipfw add 00204 allow log udp from any 500 to any
|
||
....
|
||
|
||
[NOTE]
|
||
====
|
||
ルール番号は、 現在のホストの設定によっては変更する必要があるでしょう。
|
||
====
|
||
|
||
man:pf[4] または man:ipf[8] を使用しているシステムでは、 以下のルールで上手くいくでしょう。
|
||
|
||
[.programlisting]
|
||
....
|
||
pass in quick proto esp from any to any
|
||
pass in quick proto ah from any to any
|
||
pass in quick proto ipencap from any to any
|
||
pass in quick proto udp from any port = 500 to any port = 500
|
||
pass in quick on gif0 from any to any
|
||
pass out quick proto esp from any to any
|
||
pass out quick proto ah from any to any
|
||
pass out quick proto ipencap from any to any
|
||
pass out quick proto udp from any port = 500 to any port = 500
|
||
pass out quick on gif0 from any to any
|
||
....
|
||
|
||
最後に、システムの初期化中に VPN が起動するように、以下の行を [.filename]#/etc/rc.conf# に追加してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
ipsec_enable="YES"
|
||
ipsec_program="/usr/local/sbin/setkey"
|
||
ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot
|
||
racoon_enable="yes"
|
||
....
|
||
|
||
[[openssh]]
|
||
== OpenSSH
|
||
|
||
OpenSSH はリモートマシンへのセキュアなアクセスに使われるネットワーク接続ツールの集合です。 また、TCP/IP 接続を OpenSSH 接続経由でセキュアにトンネル/フォワードすることもできます。 OpenSSH はすべてのトラフィックを暗号化し、 盗聴や接続の乗っ取り等のネットワークレベルの攻撃を事実上無効化します。
|
||
|
||
OpenSSH は OpenBSD プロジェクトによって維持管理されており、 FreeBSD にはデフォルトでインストールされています。 OpenSSH は、 SSH バージョン 1 と 2 の両方に互換性があります。
|
||
|
||
=== OpenSSH を使うことの利点
|
||
|
||
データがネットワークを平文で流れてしまうと、 ネットワークをクライアントとサーバの間のどこかで盗聴することで、 あなたのユーザ/パスワード情報やセション中を流れるデータを盗むことが可能です。 OpenSSH はこれらを予防する為にさまざまな認証と暗号化の方法を提供します。
|
||
|
||
=== SSH サーバを有効にする
|
||
|
||
man:sshd[8] が有効になっているかどうかを確認するには、 [.filename]#/etc/rc.conf# の以下の行を確認してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
sshd_enable="YES"
|
||
....
|
||
|
||
この設定により、次のシステムの初期化時に OpenSSH のデーモンプログラムである man:sshd[8] が起動します。 もしくは man:service[8] を使って、すぐに OpenSSH を起動することもできます。
|
||
|
||
[source,bash]
|
||
....
|
||
# service sshd start
|
||
....
|
||
|
||
=== SSH クライアント
|
||
|
||
man:ssh[1] を使って、 man:sshd[8] が動いているシステムに接続するには、 ログインをするユーザ名とホストを指定してください。
|
||
|
||
[source,bash]
|
||
....
|
||
# ssh user@example.com
|
||
Host key not found from the list of known hosts.
|
||
Are you sure you want to continue connecting (yes/no)? yes
|
||
Host 'example.com' added to the list of known hosts.
|
||
user@example.com's password: *******
|
||
....
|
||
|
||
SSH はクライアントが接続した時、 サーバの信頼性の検証のために鍵指紋システム (key fingerprint system) を利用します。 初めての接続の際に、ユーザは `yes` と入力することを要求されます。 これ以降の login では保存されていた鍵指紋を照合することで検証が行われ、 man:ssh[1] クライアントは保存されていた鍵指紋が login しようとした際に送られてきたものと異なっていた場合には警告を表示します。 指紋は [.filename]#~/.ssh/known_hosts# に保存されます。
|
||
|
||
デフォルトでは、man:sshd[8] の最近の版では SSH v2 の接続のみを受け付けるように設定されています。 クライアントは可能であればバージョン 2 を用い、 バージョン 1 にフォールバックします。 クライアントは、プロトコル v1 と v2 についてそれぞれ、引数 `-1` または `-2` を渡すことで、利用するプロトコルを指定できます。 クライアントにおけるバージョン 1 への互換性は、 古いバージョンへの上位互換のために維持されています。
|
||
|
||
=== Secure copy
|
||
|
||
ローカルのファイルをリモートマシンへ、 あるいはリモートマシンのファイルをローカルに安全な方法でコピーするには、 man:scp[1] を使用してください。
|
||
|
||
[source,bash]
|
||
....
|
||
# scp user@example.com:/COPYRIGHT COPYRIGHT
|
||
user@example.com's password: *******
|
||
COPYRIGHT 100% |*****************************| 4735
|
||
00:00
|
||
#
|
||
....
|
||
|
||
前回の例でこのホストの指紋がすでに保存されていれば この man:scp[1] を使う時に検証が行なわれます。
|
||
|
||
man:scp[1] に渡される引数は、man:cp[1] のものと似ており、コピーするファイル (1 つまたは複数) が 1 つめの引数になり、コピー先が 2 つめの引数になります。 ファイルはネットワーク越しに SSH 接続を通して送られるので、 引数に指定するファイルに `user@host:<path_to_remote_file>` という形式をとるものがあります。
|
||
|
||
=== 設定
|
||
|
||
システム全体の設定ファイルは、OpenSSH デーモン、クライアントの両方とも [.filename]#/etc/ssh# にあります。
|
||
|
||
[.filename]#ssh_config# はクライアントの動作設定、 [.filename]#sshd_config# はデーモンの動作設定を行ないます。 それぞれのファイル毎にマニュアルページが用意されており、 利用可能な設定オプションについて説明されています。
|
||
|
||
[[security-ssh-keygen]]
|
||
=== man:ssh-keygen[1]
|
||
|
||
パスワードの代わりに man:ssh-keygen[1] を使ってユーザの認証用の DSA または RSA 暗号鍵を作ることができます。
|
||
|
||
[source,bash]
|
||
....
|
||
% ssh-keygen -t dsa
|
||
Generating public/private dsa key pair.
|
||
Enter file in which to save the key (/home/user/.ssh/id_dsa):
|
||
Created directory '/home/user/.ssh'.
|
||
Enter passphrase (empty for no passphrase):
|
||
Enter same passphrase again:
|
||
Your identification has been saved in /home/user/.ssh/id_dsa.
|
||
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
|
||
The key fingerprint is:
|
||
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com
|
||
....
|
||
|
||
man:ssh-keygen[1] は認証に使う為の公開鍵と秘密鍵のペアを作ります。 DSA または RSA 鍵に応じて、 秘密鍵は [.filename]#~/.ssh/id_dsa# または [.filename]#~/.ssh/id_rsa# に保存され、 公開鍵は [.filename]#~/.ssh/id_dsa.pub# または [.filename]#~/.ssh/id_rsa.pub# にそれぞれ保存されます。 公開鍵はセットアップのために、 DSA または RSA のどちらを使う場合にも、 リモートマシンの [.filename]#~/.ssh/authorized_keys# に含まれてなければなりません。
|
||
|
||
この設定により、パスワードに代わり、 SSH 鍵を使ってリモートマシンに接続できるようになります。
|
||
|
||
[WARNING]
|
||
====
|
||
多くのユーザは、鍵が設計上安全と信じ、 パスフレーズなしに鍵を利用しています。 このような使用方法は _危険_ です。 管理者が鍵にパスフレーズが設定されているかを確認する方法は、 手動で鍵を調べる方法です。 秘密鍵のファイルに `ENCRYPTED` という単語が含まれている場合には、 鍵の所有者は、パスフレーズを使用しています。 弱いパスフレーズが使われている間、 少なくともシステムが危険にさらされているときには、 他のサイトへのアクセスには、 あるレベルでのパスワード類推が必要となります。 さらに、公開鍵ファイルに `from` を含めることで、 エンドユーザをより安全にできます。 たとえば、 `ssh-rsa` または `rsa-dsa` の前に、 `from="192.168.10.5` を加えることで、 この IP を持つホストからのユーザのみがアクセスできるようになります。
|
||
====
|
||
|
||
man:ssh-keygen[1] でパスフレーズを使っている場合は、 秘密鍵を使うためにユーザは毎回パスフレーズを入力する必要があります。 長いパスフレーズを毎回入力しなくてはならない負担は、 man:ssh-agent[1] を使うと軽減できます。 これについては、 <<security-ssh-agent>> で説明されています。
|
||
|
||
[WARNING]
|
||
====
|
||
OpenSSH のバージョンによって、 オプションやファイルに違いが出てくることがあります。 man:ssh-keygen[1] を参照して、 問題が起こることを避けてください。
|
||
====
|
||
|
||
[[security-ssh-agent]]
|
||
=== SSH Agent による鍵のキャッシュ
|
||
|
||
パスフレーズを毎回入力することなしに、 SSH 鍵を利用できるようにメモリに読み込むには、 man:ssh-agent[1] および man:ssh-add[1] を使用してください。
|
||
|
||
man:ssh-agent[1] は、 読み込まれた秘密鍵による認証を取り扱います。 man:ssh-agent[1] は他のアプリケーションの起動に用いられる必要があります。 基本的なレベルではシェル、 またはウィンドウマネージャを起動します。
|
||
|
||
シェル上で man:ssh-agent[1] を使うには、 引数としてシェルを起動してください。 次に、man:ssh-add[1] を実行し、 秘密鍵のパスフレーズを入力することにより、 鍵を追加してください。 一度この過程を終えてしまえば、ユーザは、 対応する公開鍵が置かれているホストに man:ssh[1] でログインできるようになります。 以下はその例です。
|
||
|
||
[source,bash]
|
||
....
|
||
% ssh-agent csh
|
||
% ssh-add
|
||
Enter passphrase for /home/user/.ssh/id_dsa:
|
||
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
|
||
%
|
||
....
|
||
|
||
Xorg 上で man:ssh-agent[1] を使うには、 man:ssh-agent[1] への呼び出しが [.filename]#~/.xinitrc# に置かれている必要があります。 これにより、Xorg 上で起動されるすべてのプログラムにおいて、 man:ssh-agent[1] サービスが提供されるようになります。 [.filename]#~/.xinitrc# の例は以下となります。
|
||
|
||
[.programlisting]
|
||
....
|
||
exec ssh-agent startxfce4
|
||
....
|
||
|
||
これで、Xorg を開始するときにはいつでも man:ssh-agent[1] が起動され、 このプログラムから XFCE が起動されます。 Xorg を再起動した後は有効になりますので、 man:ssh-add[1] を実行して、 すべての SSH 鍵を読み込ませてください。
|
||
|
||
[[security-ssh-tunneling]]
|
||
=== SSH トンネリング
|
||
|
||
OpenSSH は暗号化されたセッションの中に他のプロトコルをカプセル化するトンネルを作ることができます。
|
||
|
||
以下のコマンドは man:ssh[1] で man:telnet[1] 用のトンネルを作成します。
|
||
|
||
[source,bash]
|
||
....
|
||
% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com
|
||
%
|
||
....
|
||
|
||
この例では、以下のオプションを使っています。
|
||
|
||
`-2`::
|
||
サーバへの接続に man:ssh[1] バージョン 2 を使うことを指示します。
|
||
|
||
`-N`::
|
||
はトンネルだけでコマンドはないことを示します。 省略されると man:ssh[1] は通常のセッションを開始します。
|
||
|
||
`-f`::
|
||
man:ssh[1] にバックグラウンド実行を強制します。
|
||
|
||
`-L`::
|
||
ローカルトンネルを _localport:remotehost:remoteport_ という形式で指定します。
|
||
|
||
`user@foo.example.com`::
|
||
指定したリモート SSH サーバへログインに用いるログイン名。
|
||
|
||
SSH のトンネルは `localhost` の指定されたポートに listen するソケットを作ることで実現されています。 SSH はローカルのホスト/ポートで受けた接続すべてを SSH 接続経由で指定されたリモートホストのポートへ転送します。
|
||
|
||
この例では、`localhost` のポート _5023_ がリモートマシンの `localhost` のポート _23_ に転送されるようになっています。 _23_ は man:telnet[1] で用いられるので、これは SSH トンネルを通る暗号化された man.telnet.1; セッションを作ります。
|
||
|
||
このようにして SMTP や POP3 および FTP といったセキュアではない TCP プロトコルをカプセル化できます。
|
||
|
||
.man:ssh[1] を用いた SMTP 用の安全なトンネルの作成
|
||
[example]
|
||
====
|
||
|
||
[source,bash]
|
||
....
|
||
% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
|
||
user@mailserver.example.com's password: *****
|
||
% telnet localhost 5025
|
||
Trying 127.0.0.1...
|
||
Connected to localhost.
|
||
Escape character is '^]'.
|
||
220 mailserver.example.com ESMTP
|
||
....
|
||
man:ssh-keygen[1] と別のユーザアカウントを組み合わせて使うことでより透過的な SSH のトンネル環境を作ることができます。 パスワードを入力するところで暗号鍵を使い、 トンネルは別のユーザ権限で実行することが可能です。
|
||
====
|
||
|
||
==== 実用的な SSH トンネルの例
|
||
|
||
===== POP3 サーバへの安全な接続
|
||
|
||
ここでの例は、外部からの接続を受ける SSH サーバがあるとします。 同じネットワークには、POP3 サーバが動いているメールサーバがあるとします。 電子メールを安全なやり方で見るようにするには、 SSH サーバへの SSH 接続を行い、 メールサーバへのトンネルを作成することです。
|
||
|
||
[source,bash]
|
||
....
|
||
% ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
|
||
user@ssh-server.example.com's password: ******
|
||
....
|
||
|
||
トンネルが作成されて動作したら、 メールクライアントに対し `localhost` のポート 2110 に POP3 リクエストを送るように指示してください。 そこへの接続は、トンネルを経由して安全に `mail.example.com` に転送されます。
|
||
|
||
===== 厳格なファイアウォールをすり抜ける
|
||
|
||
内向けおよび外向きの接続両方をフィルタするファイアウォールルールを課すネットワーク管理者もいます。 たとえば、 リモートのマシンからのアクセスに、man:ssh[1] および web サーフィンのための 22 番および 80 番ポートにしか接続させてもらえないかもしれません。 この場合 22 または 80 番以外を使う他のサービスへのアクセスを妨げます。
|
||
|
||
それに対する解決策は、 あなたが接続しているネットワークのファイアウォールの外部にあるマシンに対して SSH 接続を行い、 希望するサービスへのトンネルに利用することです。
|
||
|
||
[source,bash]
|
||
....
|
||
% ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org
|
||
user@unfirewalled-system.example.org's password: *******
|
||
....
|
||
|
||
この例では、ストリーミング Ogg Vorbis クライアントを `localhost` の 8888 番ポートに向けると、 `music.example.com` の 8000 番ポートに転送され、ファイアウォールをすり抜けられます。
|
||
|
||
=== `AllowUsers` オプション
|
||
|
||
ログインできるユーザや接続元を `AllowUsers` を使って制限することは、通常は良い考えです。 たとえば、 `root` が `192.168.1.32` からのみログインできるようにするには、 以下の行を [.filename]#/etc/ssh/sshd_config# に追加してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
AllowUsers root@192.168.1.32
|
||
....
|
||
|
||
`admin` がどこからでもログインできるようにするには、 ユーザ名そのものを記述してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
AllowUsers admin
|
||
....
|
||
|
||
複数のユーザは、以下のように同じ行に追加してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
AllowUsers root@192.168.1.32 admin
|
||
....
|
||
|
||
[NOTE]
|
||
====
|
||
注意すべきことは、 このコンピュータにログインする必要のあるすべてのユーザを指定することです。 設定されていないと、そのユーザはログインできなくなります。
|
||
====
|
||
|
||
[.filename]#/etc/ssh/sshd_config# への変更が終わったら、 以下を実行して、設定ファイルを man:sshd[8] に読み込ませてください。
|
||
|
||
[source,bash]
|
||
....
|
||
# service sshd reload
|
||
....
|
||
|
||
=== もっと詳しく知りたい人へ
|
||
|
||
http://www.openssh.com/[OpenSSH] ウェブサイト
|
||
|
||
クライアントオプションについて man:ssh[1], man:scp[1], man:ssh-keygen[1], man:ssh-agent[1], man:ssh-add[1] および man:ssh_config[5]
|
||
|
||
サーバオプションについて man:sshd[8], man:sftp-server[8], man:sshd_config[5]
|
||
|
||
[[fs-acl]]
|
||
== ファイルシステムアクセス制御リスト (ACL)
|
||
|
||
アクセス制御リスト (ACL) は、標準的な UNIX(R) のパーミッションモデルを、 POSIX(R).1e に互換する方法で拡張しています。 これにより、管理者がより洗練されたセキュリティモデルを利用し、 その恩恵を受けられるようになります。
|
||
|
||
FreeBSD の [.filename]#GENERIC# カーネルは、 UFS ファイルシステム用の ACL サポートを提供します。 カスタムカーネルをコンパイルして使用するユーザは、 カスタムカーネルのコンフィグレーションファイルに以下を追加してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
options UFS_ACL
|
||
....
|
||
|
||
もしこのオプションが組み込まれていなければ、ACL に対応したファイルシステムをマウントしようとすると、 警告が表示されます。ACL は、ファイルシステムの拡張属性が有効になっていることに依存しています。 拡張属性は、UFS2 でネイティブ対応されています。
|
||
|
||
[NOTE]
|
||
====
|
||
UFS1 に拡張属性を付すように設定するのは、 UFS2 よりも高いレベルの管理オーバヘッドが必要になります。 また、UFS2 における拡張属性のパフォーマンスも大きく上がっています。 そのため、アクセス制御リストを利用する上では UFS2 を使うことが推奨されます。
|
||
====
|
||
|
||
ACL は、マウント時の管理フラグ `acls` で有効にされます。 これは [.filename]#/etc/fstab# に記述できます。 マウント時のフラグは、man:tunefs[8] を使って、ファイルシステムヘッダのスーパブロックにある ACL フラグを変更するという方法で、 常に自動で設定されるようになります。一般的には、 下記の理由からスーパブロックフラグを使う方がよいでしょう。
|
||
|
||
* マウント時に指定した ACL フラグは `mount -u` による再マウントでは変更できません。 完全に man:umount[8] した上で、新たに man:mount[8] するしかありません。これは、起動後にルートファイルシステムで ACL を有効にできないことを意味します。 また、ファイルシステムを利用し始めた後では、 その配列を変えられないことも意味しています。
|
||
* スーパブロックフラグを設定すると、[.filename]#fstab# に記述されていなかったり、デバイスの順番が変わってしまっても、常に ACL が有効な状態でマウントされます。 こうすることで、ファイルシステムを ACL を有効にしないままマウントしてしまい、ACL が正しくないかたちで強制されるセキュリティの問題を防ぎます。
|
||
|
||
[NOTE]
|
||
====
|
||
予期せず ACL を有効にしないでマウントしてしまうことを防ぐことが望まれます。 ACL を有効にし、その後無効にしてから、 拡張属性を取り消さないでまた有効にしてしまうと、 大変な状況になってしまいます。 一般的には、一度ファイルシステムで ACL を有効にしたら、無効にすべきではありません。そうしてしまうと、 ファイル保護がシステムのユーザの意図と齟齬をきたす可能性があるばかりか、 ACL を再度有効にすると、 それまでパーミッションが変更されてきたファイルに古い ACL を割り当ててしまい、 予想しない動作につながることも考えられます。
|
||
====
|
||
|
||
ACL を有効にしたファイルシステムは、 パーミッション設定の表示に `+` (プラス) 記号がつきます。例えば、次のようになります。
|
||
|
||
[.programlisting]
|
||
....
|
||
drwx------ 2 robert robert 512 Dec 27 11:54 private
|
||
drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1
|
||
drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2
|
||
drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3
|
||
drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html
|
||
....
|
||
|
||
この例では、ディレクトリ [.filename]#directory1#, [.filename]#directory2# および [.filename]#directory3# のすべてで ACL が働いています。 一方 [.filename]#public_html# は対象外です。
|
||
|
||
=== ACL を利用する
|
||
|
||
man:getfacl[1] は、 ファイルシステムの ACL を表示します。 たとえば、[.filename]#test# の ACL 設定を表示するには、 以下のコマンドを実行してください。
|
||
|
||
[source,bash]
|
||
....
|
||
% getfacl test
|
||
#file:test
|
||
#owner:1001
|
||
#group:1001
|
||
user::rw-
|
||
group::r--
|
||
other::r--
|
||
....
|
||
|
||
このファイルの ACL 設定を変更するには、 man:setfacl[1] を使用してください。
|
||
|
||
[source,bash]
|
||
....
|
||
% setfacl -k test
|
||
....
|
||
|
||
ファイルまたはファイルシステムから、 現在設定されている ACL をすべて取り除くには、`-k` を使ってください。 しかしながら、より好ましい方法は、 `-b` を使う方法です。 このオプションを使うと、ACL が動作するのに必要な基本のフィールドは残ります。
|
||
|
||
[source,bash]
|
||
....
|
||
% setfacl -m u:trhodes:rwx,group:web:r--,o::--- test
|
||
....
|
||
|
||
この例では、`-m` は、デフォルト ACL エントリを修正するために使われています。 先ほどのコマンドで設定は削除されたため、 定義されたエントリはありません。 このコマンドは、デフォルトオプションに戻し、 指定したオプションを割り当てます。 システムに存在しないユーザまたはグループを追加すると、 `Invalid argument` エラーが出力されてしまいます。
|
||
|
||
[[security-portaudit]]
|
||
== サードパーティ製ソフトウェアのセキュリティ問題を監視する
|
||
|
||
近年、セキュリティの分野では、 脆弱性の評価方法に関して多くの改善が行わています。 今日ではどのオペレーティングシステムにおいても、 システムへの侵入の脅威は、 サードパーティ製ユーティリティをインストールし、 設定するほどに増加していきます。
|
||
|
||
脆弱性を評価することは、セキュリティにおいて主要な要素です。 FreeBSD は、ベースシステムに対して勧告を発行していますが、 すべてのサードパーティ製ユーティリティに対して勧告を発行することは、 FreeBSD プロジェクトの能力を超えています。 サードパーティ製ユーティリティに関わる脆弱性を軽減し、 管理者に対し、既知のセキュリティ問題について警告する方法が存在します。 FreeBSD には、portaudit と呼ばれる追加のユーティリティが、 この目的のために用意されています。
|
||
|
||
package:ports-mgmt/portaudit[] port は、FreeBSD セキュリティチームおよび ports 開発者がアップデートし、管理している、 既知のセキュリティ問題に対するデータベースを入手します。
|
||
|
||
Ports Collection から portaudit をインストールするには、以下のように実行してください。
|
||
|
||
[source,bash]
|
||
....
|
||
# cd /usr/ports/ports-mgmt/portaudit && make install clean
|
||
....
|
||
|
||
インストールの途中で、 man:periodic[8] の設定ファイルはアップデートされ、 毎日のセキュリティに関するスクリプトの実行中に portaudit が出力するように設定されます。 毎日のセキュリティに関するスクリプトの実行結果のメールが読めることを確認してください。 このメールは、`root` アカウントに送られます。 他の設定は必要ありません。
|
||
|
||
インストールが終わったら、管理者は以下のコマンドを実行することで、 データベースをアップデートし、インストールされている package の脆弱性を調べることができます。
|
||
|
||
[source,bash]
|
||
....
|
||
# portaudit -Fda
|
||
....
|
||
|
||
[NOTE]
|
||
====
|
||
データベースは、 man:periodic[8] の実行中に自動的にアップデートされます。 先程のコマンドの実行は任意で、 データベースを手動で直ちにアップデートするときに使われます。
|
||
====
|
||
|
||
Ports Collection からインストールされたサードパーティ製ユーティリティを監査するには、 管理者は以下のコマンドを実行する必要があります。
|
||
|
||
[source,bash]
|
||
....
|
||
# portaudit -a
|
||
....
|
||
|
||
portaudit は、インストールされている package の中で、 脆弱性のあるものについて以下のようなメッセージを出力します。
|
||
|
||
[.programlisting]
|
||
....
|
||
Affected package: cups-base-1.1.22.0_1
|
||
Type of problem: cups-base -- HPGL buffer overflow vulnerability.
|
||
Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html>
|
||
|
||
1 problem(s) in your installed packages found.
|
||
|
||
You are advised to update or deinstall the affected package(s) immediately.
|
||
....
|
||
|
||
表示されている URL をウェブブラウザで開くと、管理者は、 脆弱性についてより多くの情報を得ることができます。 ここでの出力では、影響するバージョンが FreeBSD の port バージョンにより示され、 セキュリティ勧告を含む他のウェブサイトが含まれています。
|
||
|
||
portaudit は強力で、 portmaster port と共に使うときわめて有用なユーティリティです。
|
||
|
||
[[security-advisories]]
|
||
== FreeBSD セキュリティ勧告
|
||
|
||
多くの高品質なオペレーティングシステムと同様、 FreeBSD は "セキュリティ勧告" を発行しています。 これらの勧告は、通常セキュリティに関連したのメーリングリストに投稿され、 サポートされているリリースに対してパッチが作成された後、 Errata に記載されます。 この章では、セキュリティ勧告とは何か、どのように理解すべきか、 システムにパッチを当てるにはどのように対応すればよいかについて説明します。
|
||
|
||
=== セキュリティ勧告はどのようなものか？
|
||
|
||
FreeBSD セキュリティ勧告では、 以下のようなフォーマットが用いられています。
|
||
|
||
[.programlisting]
|
||
....
|
||
=============================================================================
|
||
FreeBSD-SA-XX:XX.UTIL Security Advisory
|
||
The FreeBSD Project
|
||
|
||
Topic: denial of service due to some problem <.>
|
||
|
||
Category: core <.>
|
||
Module: sys <.>
|
||
Announced: 2003-09-23 <.>
|
||
Credits: Person <.>
|
||
Affects: All releases of FreeBSD <.>
|
||
FreeBSD 4-STABLE prior to the correction date
|
||
Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE)
|
||
2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6)
|
||
2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15)
|
||
2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8)
|
||
2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18)
|
||
2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21)
|
||
2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33)
|
||
2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43)
|
||
2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) <.>
|
||
CVE Name: CVE-XXXX-XXXX <.>
|
||
|
||
For general information regarding FreeBSD Security Advisories,
|
||
including descriptions of the fields above, security branches, and the
|
||
following sections, please visit
|
||
http://www.FreeBSD.org/security/.
|
||
|
||
I. Background <.>
|
||
|
||
|
||
II. Problem Description <.>
|
||
|
||
|
||
III. Impact <.>
|
||
|
||
|
||
IV. Workaround <.>
|
||
|
||
|
||
V. Solution <.>
|
||
|
||
|
||
VI. Correction details <.>
|
||
|
||
|
||
VII. References <.>
|
||
....
|
||
|
||
<.> `Topic` フィールドでは、 問題について明記されています。 セキュリティ勧告の導入部であり、 脆弱性に影響されるユーティリティを示します。
|
||
<.> `Category` フィールドでは、 脆弱性がシステムのどの部分に影響するかを示します。 `core`, `contrib` または `ports` のどれかが示されます。 `core` カテゴリは、 FreeBSD オペレーティングシステムの `core` コンポーネントに影響する脆弱性であることを意味します。 `contrib` カテゴリは、 Sendmail のように、FreeBSD の外で開発され、FreeBSD プロジェクトに取り込まれたソフトウェアに影響する脆弱性であることを意味します。 `ports` カテゴリは、Ports Collection からインストールされるソフトウェアに影響する脆弱性であることを示しています。
|
||
<.> `Module` フィールドは、 影響するコンポーネントについて言及します。 この例では、`sys` モジュールに影響することがわかります。 そのため、この脆弱性は、 カーネルの中で使われるコンポーネントに影響します。
|
||
<.> `Announced` フィールドは、 セキュリティ勧告が発行された日、 またはアナウンスされた日が記載されています。 セキュリティチームによりこの問題が存在することが確認され、 パッチが FreeBSD ソースコードリポジトリにコミットされたことを意味します。
|
||
<.> `Credits` フィールドは、 脆弱性を通知し、報告した個人または組織を示します。
|
||
<.> `Affects` フィールドは、この脆弱性がどの FreeBSD リリースに影響するかを説明します。 カーネルでは、影響するファイルに対して man:ident[1] を実行すると、 その出力からリビジョンを簡単に確認できます。 ports の場合には、 [.filename]#/var/db/pkg# の port の名前の後に、バージョン番号が示されています。 もし、システムが FreeBSD Subversion リポジトリと同期していなかったり、 再構築が毎日行われているような状況でなければ、 おそらく、そのシステムには影響しているでしょう。
|
||
<.> `Corrected` フィールドは、 脆弱性が修正された日、時間、 タイムゾーン、およびリリースが示されます。
|
||
<.> http://cve.mitre.org[Common Vulnerabilities and Exposures] データベースにおいて、 脆弱性を探すために使用できる識別情報を示します。
|
||
<.> `Background` フィールドは、 影響しているユーティリティに関する情報を示します。 大体の場合は、なぜユーティリティが FreeBSD に存在するか、 何のために使われているか、 どのように用いられるようになってきたか、 といった情報が示されます。
|
||
<.> `Problem Description` フィールドは、 より深くセキュリティホールについて説明します。 問題のあるコードの情報や、 このユーティリティが悪意のある使い方により、 どのようにセキュリティホールを開けうるかといったことが示されます。
|
||
<.> `Impact` フィールドは、 この問題がシステムに対して、 どのような形式の影響を与えるかについて示します。 たとえば、DoS 攻撃によるものか、 ユーザに対して意図しない特権を持たせてしまうものか、 または、攻撃者にスーパユーザのアクセスを与えるようなものか、 といったことが示されます。
|
||
<.> `Workaround` フィールドは、 時間による制限や、ネットワークの可用性または他の理由により、 システムをアップグレードできないシステム管理者に対して、 回避方法を提供します。 セキュリティを甘く見るべきではなく、 影響するシステムにはパッチを当てるか、 セキュリティホールの回避方法を実行すべきです。
|
||
<.> `Solution` フィールドは、 影響のあるシステムにパッチを当てる手順を提供します。 ここではステップごとにシステムにパッチを当て、 安全に動作するように、 試験され検証された方法が記載されます。
|
||
<.> `Correction Details` フィールドは、 Subversion ブランチまたはリリース名のピリオドをアンダースコアに置き換えたものを示します。 ここでは、 各ブランチにおいて影響するファイルのリビジョン番号も示します。
|
||
<.> `References` フィールドは、 通常、ウェブページの URL, books, メーリングリストおよびニュースグループといった、 ほかの情報へのソースを提供します。
|
||
|
||
[[security-accounting]]
|
||
== プロセスアカウンティング
|
||
|
||
プロセスアカウンティングは、 管理者が使用されているシステムのリソースを記録したり、 リソースのユーザへの割り当て、 システムのモニタリングおよびユーザのコマンドの最低限の記録を提供します。
|
||
|
||
これは実際には、長所と短所があります。 長所の一つは、侵入を入り口の時点で絞ることができます。 短所は、プロセスアカウンティングにより生成されるログの量で、 多くのディスク容量を必要とします。この節では、 管理者を対象にプロセスアカウンティングの基礎を説明します。
|
||
|
||
=== プロセスアカウンティングを有効にする
|
||
|
||
プロセスアカウンティングを使用する前に、 以下のコマンドを使って、 プロセスアカウンティングを有効にしておく必要があります。
|
||
|
||
[source,bash]
|
||
....
|
||
# touch /var/account/acct
|
||
# chmod 600 /var/account/acct
|
||
# accton /var/account/acct
|
||
# echo 'accounting_enable="YES"' >> /etc/rc.conf
|
||
....
|
||
|
||
一度有効に設定すると、アカウンティングは、 CPU の統計、 実行されたコマンドの情報の追跡を開始します。 すべてのアカウンティングログは、 人が読めるような形式ではなく、 man:sa[8] を使って見ることができます。 オプションを設定せずに実行すると、 man:sa[8] はユーザコールの数、全経過時間 (分)、 全 CPU、ユーザの時間 (分)、および I/O 操作の平均数などを出力します。
|
||
|
||
実行されたコマンドに関する情報を見るには、 man:lastcomm[1] を使ってください。 このコマンドは、 ユーザが特定の man:ttys[5] で実行したコマンドを出力します。 たとえば、以下のコマンドは `ttyp1` ターミナル上で `trhodes` が実行した man:ls[1] の使用について、記録されているすべて示します。
|
||
|
||
[source,bash]
|
||
....
|
||
# lastcomm ls trhodes ttyp1
|
||
....
|
||
|
||
他にも有用なオプションが多くあり、 man:lastcomm[1], man:acct[5] および man:sa[8] で説明されています。
|
||
|
||
[[security-resourcelimits]]
|
||
== リソースの制限
|
||
|
||
長年にわたり FreeBSD は、 リソースを制限するためのデータベースとしてフラットファイル形式の [.filename]#/etc/login.conf# により管理していました。 この方法は、現在でも使われていますが、 リソースを管理する方法としては最適な方法でないことが、 以前から議論されています。 フラットファイル形式では、 クラスとして知られるグループラベルにユーザを分類する必要があります。 この場合、フラットファイルだけではなく、 パスワードデータベースに対しても変更が必要となります。 潜在的に、より多くの制限を加えられたユーザ対してはラベルの追加や、 `cap_mkdb` を使ったリソースデータベースの再構築、 [.filename]#/etc/master.passwd# への変更が必要となります。 さらに、パスワードデータベースは、 `pwd_mkdb` を使って再構築する必要があります。 この複数回に渡るプロセスは、 多くのユーザについて設定する必要がある場合には、 大変な時間の浪費につながる可能性があります。
|
||
|
||
FreeBSD の新しいコマンドである man:rctl[8] は、 ユーザに対して、 よりきめ細かにリソースの制限を管理する方法を提供します。 このコマンドは、ユーザだけではなく、プロセス、jails およびオリジナルのログインクラスに対してもリソースの制限を行うことができます。 これらの高度な機能は、管理者およびユーザに対し、 リソースをコマンドラインで管理したり、 設定ファイルを用いることで、システムの初期化時に、 ルールを設定する方法を提供します。
|
||
|
||
この機能を有効にするには、以下の行を [.filename]#GENERIC# またはカスタムカーネルコンフィグレーションファイルに追加し、 再構築してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
options RACCT
|
||
options RCTL
|
||
....
|
||
|
||
その後、システムの再起動が必要になります。 この過程の手順については、crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] をご覧ください。 これらの準備が完了すると、`rctl` を用いてシステムにルールを設定できるようになります。
|
||
|
||
ルールの構文は簡単で、 _subject_, _subject-id_, _resource_ および _action_ を使って管理されます。 以下のルールの例を参照してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
user:trhodes:maxproc:deny=10/user
|
||
....
|
||
|
||
これは基本的なルールです。 ここで、subject は `user`、 subject-id は `trhodes` です。 maxproc はもちろんプロセスの最大数であり、resource です。 ここで action は、`deny` と設定されており、 新しいプロセスの生成がブロックされます。 この例では、ユーザ `trhodes` のプロセスは `10` 個に制限され、それ以上のプロセスは作成できません。 コンソールにログを出力したり、 man:devd[8] に対し通知したり、プロセスに sigterm を送ったりといった、 他の action も利用できます。
|
||
|
||
ルールを追加する際には、注意すべき点がいくつかあります。 上の例では、ログインして `screen` セッションを実行してしまうと、 不幸にもユーザは最も簡単なタスクの実行ですらブロックされてしまうでしょう。 リソースの制限が適応されると、エラーが出力されます。 この例では以下のような出力が行われます。
|
||
|
||
[source,bash]
|
||
....
|
||
% man test
|
||
/usr/bin/man: Cannot fork: Resource temporarily unavailable
|
||
eval: Cannot fork: Resource temporarily unavailable
|
||
....
|
||
|
||
他の例としては、man:rctl[8] を使って jail がメモリの制限を超えることを防ぐことができます。 このルールは以下のように書くことができます。
|
||
|
||
[source,bash]
|
||
....
|
||
# rctl -a jail:httpd:memoryuse:deny=2G/jail
|
||
....
|
||
|
||
ルールを [.filename]#/etc/rctl.conf# に追加すると、 再起動してもルールは持続します。 フォーマットは、ルールから最初のコマンドの部分を除いたものとなります。 たとえば、上のルールを追加するには、 以下のように追加してください。
|
||
|
||
[.programlisting]
|
||
....
|
||
# Block jail from using more than 2G memory:
|
||
jail:httpd:memoryuse:deny=2G/jail
|
||
....
|
||
|
||
ルールを削除するには、`rctl` に対し、 リストから削除するように指定してください。
|
||
|
||
[source,bash]
|
||
....
|
||
# rctl -r user:trhodes:maxproc:deny=10/user
|
||
....
|
||
|
||
マニュアルページには、 ルールをすべて削除する方法が記載されています。 しかしながら、特定のユーザのルールをすべて削除するには、 以下のようなコマンドを実行してください。
|
||
|
||
[source,bash]
|
||
....
|
||
# rctl -r user:trhodes
|
||
....
|
||
|
||
`subjects` をコントロールするリソースは他にも多く用意されています。 これらについて知るには、man:rctl[8] をご覧ください。
|