diff --git a/documentation/content/ja/books/handbook/basics/_index.adoc b/documentation/content/ja/books/handbook/basics/_index.adoc index e7a9caf598..59822b8c49 100644 --- a/documentation/content/ja/books/handbook/basics/_index.adoc +++ b/documentation/content/ja/books/handbook/basics/_index.adoc @@ -1,1963 +1,1893 @@ --- title: 第3章 FreeBSD の基礎知識 part: パートI. 導入 prev: books/handbook/bsdinstall next: books/handbook/ports description: FreeBSD オペレーティングシステムの基本的なコマンドと機能について tags: ["basics", "virtual consoles", "users", "management", "permissions", "directory structure", "disk organization", "mounting", "processes", "daemons", "shell", "editor", "manual pages", "devices"] showBookMenu: true weight: 5 path: "/books/handbook/" aliases: ["/ja/books/handbook/consoles/","/ja/books/handbook/users-synopsis/","/ja/books/handbook/permissions/","/ja/books/handbook/dirstructure/","/ja/books/handbook/disk-organization/","/ja/books/handbook/mount-unmount/","/ja/books/handbook/basics-processes/","/ja/books/handbook/shells/","/ja/books/handbook/editors/","/ja/books/handbook/basics-devices/","/ja/books/handbook/basics-more-information/"] --- [[basics]] = FreeBSD の基礎知識 :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 3 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/basics/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[basics-synopsis]] == この章では この章では FreeBSD オペレーティングシステムの基本的なコマンドと機能について記述しています。 ここに書かれてあることのほとんどは、どんな UNIX(R) -like なオペレーティングシステムにもあてはまります。 FreeBSD の初心者であれば、この章を読んでおいた方がきっといいはずです。 この章を読んで分かることは、次のようなことです。 * 仮想コンソールの使い方と設定方法 * FreeBSD システム上でユーザやグループを作成し管理する方法 * UNIX(R) のファイルの許可属性の仕組みと FreeBSD のファイルフラグについて * FreeBSD のファイルシステムの構成 * FreeBSD のディスク構成 * ファイルシステムをマウント、アンマウントする方法 * プロセス、デーモンとシグナルとはなにか * シェルとはなにか。 また、デフォルトのログイン環境を変える方法 * テキストエディタの基本的な使い方 * デバイスおよびデバイスノードとはなにか * さらに詳しい情報を得るためのマニュアルページの読み方 [[consoles]] == 仮想コンソールと端末 起動時に自動的にグラフィカルな環境が起動するように FreeBSD を設定していなければ、システムが起動すると、以下のようなコマンドラインのログインプロンプトが表示されます。 [source,shell] .... FreeBSD/amd64 (pc3.example.org) (ttyv0) login: .... 最初の行はシステムの情報です。 `amd64` は、このシステム上で 64 ビット版の FreeBSD が動作していることを示しています。 ホスト名は `pc3.example.org`、[.filename]#ttyv0# は "システムコンソール" であることを示しています。 次の行はログインプロンプトです。 FreeBSD はマルチユーザシステムなので、ユーザを区別する何がしかの手段が必要です。 システム上のプログラムを実行できるようになるには、すべてのユーザに対してシステムにログインすることが義務付けられています。 すべてのユーザは、一意な名前である "ユーザ名" と "パスワード" を持っています。 システムコンソールにログインするには、システムのインストール時に crossref:bsdinstall[bsdinstall-addusers,ユーザの追加] で追加したユーザ名を入力して、kbd:[Enter] を押してください。 次にそのユーザのパスワードを入力して、kbd:[Enter] を押してください。 セキュリティの観点から、パスワードは _表示されません_。 パスワードを正確に入力したら、日々のメッセージ (MOTD) が表示され、 コマンドプロンプトが表示されます。 ユーザ作成時に選択したシェルに依存しますが、このプロンプトは `+#+`, `$` または `%` といった記号です。 プロンプトはユーザが FreeBSD のシステムコンソールへログインし、利用可能なコマンドを実行する準備ができていることを示しています。 [[consoles-virtual]] === 仮想コンソール システムコンソールからシステムに対話的にコマンドを実行できますが、FreeBSD システム上でキーボードによりコマンドラインから利用しているユーザは、通常代わりに仮想コンソールにログインします。 デフォルトではシステムからのメッセージはシステムコンソールに出力され、これらのメッセージが、ユーザが作業しているコマンドまたはファイル上に表示されるため、ユーザが現在の作業に集中できなくなるためです。 デフォルトでは FreeBSD は、複数の仮想コンソールを表示してコマンドを入力できるように設定されています。 各仮想コンソールは、個別のログインプロンプトおよびシェルを持っており、簡単に仮想コンソール間の切り替えができます。 これにより、グラフィカルな環境において同時に複数のウィンドウを開いてコマンドラインの環境を提供できます。 FreeBSD では kbd:[Alt+F1] から kbd:[Alt+F8] までのキーの組み合わせが、仮想コンソール間の切り替えに予約されています。 システムコンソール ([.filename]#ttyv0#) に切り替えるには、kbd:[Alt+F1] を使ってください。 最初の仮想コンソール ([.filename]#ttyv1#) にアクセスするには kbd:[Alt+F2]、2 番目の仮想コンソール ([.filename]#ttyv2#) にアクセスするには kbd:[Alt+F3]、といったように使ってください。 Xorg をグラフィカルなコンソールとして使用しているときには、kbd:[Ctrl+Alt+F1] の組み合わせを使用すると、テキストベースの仮想コンソールへ戻ります。 あるコンソールから他に切り替えるのに応じて、FreeBSD は画面への出力を管理します。 結果として、FreeBSD で動かすコマンドを入力するのに使える複数の画面とキーボードを仮想的に実現できるのです。 ある仮想コンソールで実行したプログラムは、ユーザが別の仮想コンソールに切り替えても実行を停止しません。 FreeBSD のコンソールおよびキーボードドライバに関するさらなる技術的な説明については、man:kbdcontrol[1], man:vidcontrol[1], man:atkbd[4], man:syscons[4] および man:vt[4] を参照してください。 FreeBSD では以下の [.filename]#/etc/ttys# のように複数の利用可能な仮想コンソールが設定されています。 [.programlisting] .... # name getty type status comments # ttyv0 "/usr/libexec/getty Pc" xterm on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" xterm on secure ttyv2 "/usr/libexec/getty Pc" xterm on secure ttyv3 "/usr/libexec/getty Pc" xterm on secure ttyv4 "/usr/libexec/getty Pc" xterm on secure ttyv5 "/usr/libexec/getty Pc" xterm on secure ttyv6 "/usr/libexec/getty Pc" xterm on secure ttyv7 "/usr/libexec/getty Pc" xterm on secure ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure .... 仮想コンソールを無効にするには、無効にしたい仮想コンソールの行をコメント記号 (`+#+`) から始まるように設定してください。 たとえば、利用可能な仮想コンソールを 8 つから 4 つに減らす場合には、 [.filename]##ttyv5## から [.filename]##ttyv8## までの仮想コンソールを表す最後の 4 行の先頭に `+#+` を挿入してください。 システムコンソールを表す [.filename]##ttyv0## から始まる行はコメントアウト _しないでください。_ 最後の仮想コンソール ([.filename]##ttyv8##) は、Xrog がインストールされ crossref:x11[x11,X Window System] で説明されているように設定されている場合に、グラフィカル環境にアクセスするために使用されます。 このファイルのそれぞれのカラムと仮想コンソールに設定可能なオプションの詳しい説明は、man:ttys[5] のマニュアルを参照してください。 [[consoles-singleuser]] === シングルユーザモード FreeBSD のブートメニューでは、"シングルユーザモード" と表示されているオプションが提供されています。 このオプションを選択すると、システムは "シングルユーザモード" と呼ばれる特別なモードで起動します。 このモードは、システムが起動しない場合に修正のため、または `root` のパスワードが分からなくなってしまいリセットするときなど、特別な状況で利用されます。 シングルユーザモードで動かしている場合は、ネットワークや他の仮想コンソールは利用できません。 しかし、システムへの完全な `root` 権限を利用でき、デフォルトの設定では `root` のパスワードは必要ありません。 このような理由のため、このモードで起動する場合には物理的なキーボードへのアクセスが必要であり、FreeBSD システムの安全性の観点からキーボードに物理的にアクセスできる人を決めておく事が必要です。 シングルユーザモードを管理する設定は、[.filename]#/etc/ttys# ファイルの以下のセクションにあります。 [.programlisting] .... # name getty type status comments # # If console is marked "insecure", then init will ask for the root password # when going to single-user mode. console none unknown off secure .... デフォルトでは、status は `secure` に設定されています。 これは、キーボードへアクセスできるかユーザが誰であるかが重要ではない、もしくはアクセスできるユーザについては物理的なセキュリティポリシーでコントロールされていることが前提となっています。 この設定を `insecure` に変更するケースとしては、システムは安全ではなく、誰でもキーボードにアクセスできる環境が想定されます。 この行を `insecure` に変更すると、FreeBSD がシングルユーザモードで起動した場合に `root` のパスワードが要求されます。 [NOTE] ==== __ `insecure` に変更する場合は十分注意してください! __ `root` のパスワードを忘れてしまうと、シングルユーザモードで起動することはできますが、FreeBSD の起動のプロセスに詳しくない人が起動できるようにするのは難しいかも知れません。 ==== [[consoles-vidcontrol]] === コンソールのビデオモードの変更 FreeBSD のデフォルトのビデオモードは 1024x768 や 1280x1024 など、グラフィックチップおよびディスプレイが対応しているサイズに調整されます。 別のビデオモードを使うには、`VESA` モジュールをロードしてください。 [source,shell] .... # kldload vesa .... その後、ハードウェアが対応しているビデオモードを man:vidcontrol[1] を使って確認してください。 以下を実行すると、対応しているビデオモードを調べることができます。 [source,shell] .... # vidcontrol -i mode .... このコマンドは、使用しているハードウェアが対応しているビデオモードの一覧を表示します。 その後、man:vidcontrol[1] を `root` ユーザで実行して、新しく使用するビデオモードを選択してください。 [source,shell] .... # vidcontrol MODE_279 .... このビデオモードで良ければ、起動時に自動的に設定されるように [.filename]#/etc/rc.conf# に以下のように追加してください。 [.programlisting] .... allscreens_flags="MODE_279" .... [[users-synopsis]] == ユーザと基本的なアカウント管理 FreeBSD は、複数のユーザが同時にコンピュータを使えるようにします。 スクリーンとキーボードの前に一度に座れるのはその中の一人だけですが ユーザは何人でもネットワークを通してログインできます。 システムを使うためには、 どのユーザもアカウントがなければなりません。 この章では、以下のことを説明します。 * FreeBSD システムにおけるさまざまな種類のユーザアカウントについて * ユーザアカウントを追加、削除および変更する方法 * ユーザやグループが利用できるリソースの上限を制御する方法 * グループの作成、 およびグループにユーザをメンバとして追加する方法 [[users-introduction]] === アカウントの種類 FreeBSD システムへアクセスするには、 かならずアカウントが使われ、 また、プロセスもすべてユーザによって実行されるので、 ユーザとアカウントの管理は、重要なものです。 アカウントには大きく分けて三種類あります。 システムアカウント (system accounts)、ユーザアカウント (user accounts)、 そしてスーパーユーザ (superuser) です。 [[users-system]] ==== システムアカウント システムアカウントは、DNS、メール、 ウェブサーバといった各種サービスを運用するために使われます。 この目的は、セキュリティを確保するためです。 もしすべてのサービスがスーパーユーザで実行されていると、 それらのサービスはどんな動作でも可能となり、 適切な制限を適用することができません。 システムアカウントの具体例は、 `daemon`, `operator`, `bind`, `news` および `www` といったものです。 [WARNING] ==== operator グループを使う時には、意図しないスーパーユーザへのアクセス権を与える可能性があるため注意が必要です。 シャットダウン、リブートおよびこのグループが所有する [.filename]#/dev# のすべてにアクセスできるといったことが可能になってしまいます。 ==== `nobody` は通常の特権を持たないシステムアカウントです。 しかし、`nobody` を利用するサービスが増えれば増えるほど、 それに所属するファイルやプロセスも増え、 その特権も大きくなるということを忘れないようにしてください。 [[users-user]] ==== ユーザアカウント ユーザアカウントは、 主に現実のユーザがシステムにアクセスする手段として用いられるものです。 システムにアクセスするすべてのユーザは、 それぞれ唯一のユーザアカウントを持つべきです。 こうすることで管理者は誰が何を行なっているかがわかりますし、 他の人の設定を壊してしまうようなことを避けることができます。 それぞれのユーザは快適にシステムを利用するため、 シェル、エディタ、キー設定、言語など、 各自の環境をセットアップすることができます。 FreeBSD システム上のどのアカウントにも、 以下のような情報がなにかしら結び付けられています。 ユーザ名:: `login:` プロンプトに対して入力するユーザの名前です。 各ユーザは一意なユーザ名を持つ必要があります。 有効なユーザ名を作成するには man:passwd[5] に記載されているいくつもの規則があります。 アプリケーションの上位互換性を保つために、8 文字以下の小文字からなるユーザ名を使うことが推奨されています。 パスワード:: 各アカウントにはパスワードがあります。 ユーザ ID (UID):: ユーザ ID (UID) は、 FreeBSD システムがユーザを一意に識別するための数値です。 ユーザ名を指定できるコマンドは、 ユーザ名を UID に変換してから扱っています。 65535 より大きな UID は、ソフトウェアによっては互換性の問題を引き起こす可能性があるので、65535 以下の UID を使用することが推奨されています。 グループ ID (GID):: グループ ID (GID) は、 ユーザが属する第一グループを一意に識別するための数値です。 グループは、UID ではなく、 ユーザの GID に基づいて資源へのアクセスを制御する仕組みです。 これは、ある種の設定ファイルのサイズを大幅に小さくします。 ユーザは、複数のグループに所属できます。 65535 より大きな GID は、ソフトウェアに問題を引き起こす可能性があるので、 65535 以下の GID を使うことを推奨します。 ログインクラス:: ログインクラスはグループの仕組みを拡張したもので、 別々のユーザに対してシステムを調整する時に、 さらなる柔軟性を提供します。ログインクラスの詳細については、 <> で説明します。 パスワードの有効期限:: デフォルトでは、パスワードに有効期限は設定されていません。 しかしながら、パスワードの有効期限をユーザごとに設定し、一部またはすべてのユーザに、一定の時間がたったらパスワードを強制的に変更させることができます。 アカウント失効時間:: デフォルトでは、FreeBSD はアカウントを失効させません。 たとえば学校で生徒のアカウントがある場合など、 限られた期間だけのアカウントを作成するなら、 そのアカウントがいつ失効するか man:pw[8] を使って指定できます。 有効期間が経過したら、 そのアカウントのディレクトリやファイルは残っていますが、 システムへのログインはできなくなります。 ユーザの氏名:: FreeBSD ではユーザ名でアカウントを一意に識別しますが、 必ずしもユーザの本名を反映したものではありません。 この情報をアカウントに関連付けることもできます。 この情報は、コメントのように、空白、大文字、および 8 字以上で記載できます。 ホームディレクトリ:: ホームディレクトリは、システム中のディレクトリへのフルパスです。 これはユーザがログインした時に作業を開始するディレクトリです。 一般的な慣習は、すべてのユーザのホームディレクトリを [.filename]#/home/username# か [.filename]#/usr/home/username# の下に置くことです。 各ユーザは、個人のファイルやサブディレクトリを、 ユーザのホームディレクトリに保存します。 ユーザシェル:: シェルは、 ユーザがシステムと対話するデフォルトの環境を提供します。 いろいろな種類のシェルがあり、 経験を積んだユーザはそれぞれ好みがあり、 それをアカウントの設定に反映できます。 [[users-superuser]] ==== スーパーユーザアカウント スーパーユーザアカウントは通常 `root` と呼ばれ、 システム管理を行なうために使われ、権限に制限がありません。 そのため、このアカウントはメールのやりとり、システムの調査、 プログラミングといった日常的な作業を行なうために使われるべきものではありません。 その理由は、スーパーユーザが通常のユーザアカウントと異なり、 操作にまったく制限を受けないことによります。 そのためスーパーユーザアカウントで操作を間違えると、 システムに重大な影響を与えてしまう恐れがあるのです。 ユーザアカウントでは、 仮に操作を間違えてもシステムを壊してしまうようなことはできないようになっています。 そのため、ユーザアカウントでログインし、 高い権限が必要なコマンドを実行するときだけスーパーユーザになることが推奨されています。 スーパーユーザで実行するコマンドはいつでも、 二回、三回と確認してください。 なぜならスペースが多かったり、文字が欠けていたりするだけで、 取り返しのつかないデータの破壊につながる可能性があるからです。 スーパーユーザの権限を得るには、さまざまな方法があります。 `root` ユーザとしてログインする方法もありますが、 これはまったくお勧めできません。 スーパーユーザの権限を手に入れるには、かわりに man:su[1] を使って下さい。 `-` オプションをつけて実行すると、 実行したユーザに root ユーザの環境が設定されます。 このコマンドは `wheel` グループに入ってるユーザのみが実行でき、他のユーザは実行出来ません。 また、実行時には `root` ユーザのパスワードを必要とします。 以下の例では、`make install` を行うときにスーパーユーザの権限が必要なので、 このコマンドを実行する時だけユーザはスーパーユーザになります。 コマンドを実行したら、ユーザは `exit` を実行してスーパーユーザからログアウトし、 通常のユーザアカウントの権限に戻ります。 .スーパーユーザ権限でプログラムをインストールする [example] ==== [source,shell] .... % configure % make % su - Password: # make install # exit % .... ==== 1 人の管理者が一台のマシン、 もしくは小規模なネットワークを管理する場合には、 man:su[1] のフレームワークはうまく機能するでしょう。 この代わりとなるのは、 package:security/sudo[] package または port です。これはログ機能や、 スーパーユーザの権限で実行できるユーザやコマンドを設定できます。 [[users-modifying]] === アカウント情報の管理 FreeBSD は、ユーザアカウントを操作するためにさまざまなコマンドを用意しています。 もっとも一般的なコマンドが <> にまとめられています。 その後で、各コマンドについて詳しい使用例を示します。 各ユーティリティの詳細や使用例についてはマニュアルページを参照してください。 [[users-modifying-utilities]] .ユーザアカウントを管理するためのユーティティ [cols="1,1", frame="none", options="header"] |=== | コマンド | 要約 |man:adduser[8] |コマンドラインからユーザを追加するための推奨アプリケーション |man:rmuser[8] |コマンドラインからユーザを削除するための推奨アプリケーション |man:chpass[1] |ユーザデータベースの情報を変更するための柔軟なツール |man:passwd[1] |ユーザのパスワードを変更するコマンドラインツール |man:pw[8] |ユーザアカウントのあらゆる箇所を変更する強力で柔軟なツール |=== [[users-adduser]] ==== `adduser` 新しいユーザの登録に推奨されるプログラムは man:adduser[8] です。 ユーザを追加すると、このプログラムは、[.filename]#/etc/passwd# と [.filename]#/etc/group# を自動的に更新します。 また、新規ユーザのホームディレクトリを作成し、 [.filename]#/usr/share/skel# から、デフォルトで使用される設定ファイルをコピーします。 また、新しく作成されたユーザに対して、ウェルカムメッセージをメールで送信することも可能です。 このユーティリティは、スーパーユーザ権限で実行する必要があります。 man:adduser[8] は、新しいユーザアカウントを対話的に段階的に作成するユーティリティです。 <> で示されているように、必要な情報を入力するか、括弧内に示されているデフォルトの値を kbd:[Return] を押して承認してください。 この例では、ユーザは man:su[1] によってスーパユーザ権限を取得することが可能となる `wheel` グループに所属します。 操作が終了すると、ユーティリティは別のユーザを追加するか、終了するかを尋ねてきます。 [[users-modifying-adduser]] .FreeBSD におけるユーザの追加 [example] ==== [source,shell] .... # adduser Username: jru Full name: J. Random User Uid (Leave empty for default): Login group [jru]: Login group is jru. Invite jru into other groups? []: wheel Login class [default]: Shell (sh csh tcsh zsh nologin) [sh]: zsh Home directory [/home/jru]: Home directory permissions (Leave empty for default): Use password-based authentication? [yes]: Use an empty password? (yes/no) [no]: Use a random password? (yes/no) [no]: Enter password: Enter password again: Lock out the account after creation? [no]: Username : jru Password : **** Full Name : J. Random User Uid : 1001 Class : Groups : jru wheel Home : /home/jru Shell : /usr/local/bin/zsh Locked : no OK? (yes/no): yes adduser: INFO: Successfully added (jru) to the user database. Add another user? (yes/no): no Goodbye! # .... ==== [NOTE] ==== 入力したパスワードは画面に表示されませんので、 ユーザアカウントを作成する際には、 パスワードを間違えて入力してしまわないように注意してください。 ==== [[users-rmuser]] ==== `rmuser` システムから完全にユーザを削除するには、スーパーユーザ権限で man:rmuser[8] を実行してください。 このコマンドは、次の手順を実行します。 [.procedure] . 指定されたユーザの man:crontab[1] エントリが存在する場合には削除。 . 指定されたユーザの man:at[1] ジョブをすべて削除。 . 指定されたユーザが所有するすべてのプロセスを強制終了。 . ローカルパスワードファイルから、 指定されたユーザのエントリを削除。 . (選択した場合は) 指定されたユーザのホームディレクトリを削除 (ディレクトリの所有者が指定されたユーザのものだった場合)。 . [.filename]#/var/mail# から、指定されたユーザの到着メールファイルを削除。 . [.filename]#/tmp# のような一時ファイル保存領域から、 指定されたユーザの所有するファイルを削除。 . そして最後に、 [.filename]#/etc/group# にある すべてのグループから、指定されたユーザを削除します。 指定されたユーザと同じ名前のグループで、そのユーザが削除されると空のグループとなる場合は、そのグループ自体が削除されます。 これは man:adduser[8] によってユーザごとに作成される、ユニークなグループに対応するものです。 スーパユーザアカウントの削除に man:rmuser[8] を利用することはできません。 スーパユーザアカウントの削除はほとんどすべての場合、 大規模なシステムの破壊を意味するからです。 デフォルトでは、以下の例のような対話モードが使われます。 .`rmuser` による対話的なアカウントの削除 [example] ==== [source,shell] .... # rmuser jru Matching password entry: jru:*:1001:1001::0:0:J. Random User:/home/jru:/usr/local/bin/zsh Is this the entry you wish to remove? y Remove user's home directory (/home/jru)? y Removing user (jru): mailspool home passwd. # .... ==== [[users-chpass]] ==== `chpass` すべてのユーザは、man:chpass[1] を用いてデフォルトシェルやユーザアカウントに関連した個人情報を変更できます。 スーパユーザ権限に限り、このユーティリティを用いて他のユーザのアカウント情報も変更できます。 ユーザ名の他にオプションを指定しないと、 man:chpass[1] はユーザ情報を編集するエディタを表示します。 ユーザがエディタを終了すると、 ユーザデータベースが新しい情報に更新されます。 [NOTE] ==== スーパユーザ権限以外でこのユーティリティを実行した場合は、 エディタを抜けた後にユーザのパスワードを聞かれます。 ==== <> では、スーパーユーザは `chpass jru` と入力し、このユーザに対して変更可能なフィールドが表示されています。 `jru` がこのコマンドを実行すると、最後の 6 フィールドのみが表示され編集が可能です。 この場合については、<> で示されています。 [[users-modifying-chpass-su]] .スーパユーザによる `chpass` の使用 [example] ==== [source,shell] .... #Changing user database information for jru. Login: jru Password: * Uid [#]: 1001 Gid [# or name]: 1001 Change [month day year]: Expire [month day year]: Class: Home directory: /home/jru Shell: /usr/local/bin/zsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: .... ==== [[users-modifying-chpass-ru]] .通常のユーザによる `chpass` の使用 [example] ==== [source,shell] .... #Changing user database information for jru. Shell: /usr/local/bin/zsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: .... ==== [NOTE] ==== man:chfn[1] および man:chsh[1] コマンドはいずれも、man:chpass[1] へのリンクです。 また、man:ypchpass[1], man:ypchfn[1] および man:ypchsh[1] も同様です。 NIS のサポートは自動的に行なわれますの、 コマンドの先頭に `yp` をつける必要はありません。 NIS の設定については、ネットワークサーバの章で説明されています。 ==== [[users-passwd]] ==== `passwd` いかなるユーザも man:passwd[1] を使って簡単に自身のパスワードを変更できます。 誤って、または不正なパスワードの変更を避けるため、新しいパスワードを設定する前に、もとのパスワードの入力が求められます。 .自分のパスワードの変更 [example] ==== [source,shell] .... % passwd Changing local password for jru. Old password: New password: Retype new password: passwd: updating the database... passwd: done .... ==== スーパーユーザは、man:passwd[1] をユーザ名を指定して実行することにより、いかなるユーザのパスワードを変更できます。 スーパーユーザの権限でこのユーティリティを実行する際には、もとのパスワードを入力する必要はありません。 そのため、ユーザが元のパスワードを忘れてしまっても、パスワードを変更できます。 .スーパーユーザ権限での他のユーザのパスワード変更 [example] ==== [source,shell] .... # passwd jru Changing local password for jru. New password: Retype new password: passwd: updating the database... passwd: done .... ==== [NOTE] ==== man:chpass[1] 同様、man:yppasswd[1] は、 man:passwd[1] へのリンクになっていますので、 NIS はどちらのコマンドでも動作します。 ==== [[users-pw]] ==== `pw` man:pw[8] は、ユーザやグループの作成、削除、変更および表示を行なうコマンドラインのユーティリティです。 これは、システムユーザファイルやシステムグループファイルのフロントエンドとして働きます。 man:pw[8] はとても強力な一連のコマンドラインオプションを有しており、シェルスクリプトで使うのに向いていますが、新しいユーザは、この章で紹介されている他のコマンドに比べて難しいと感じるかもしれません。 -[[users-limiting]] -=== ユーザへの制限 - -FreeBSD は、 個々のユーザが利用できるシステム資源の量を管理者が制限できる方法をいくつも用意しています。 その種の制限は、ディスククォータ (quota) とその他の資源の制限の 2 つの章で説明します。 - -ディスククォータは、ユーザが利用できるディスク容量を制限し、 その都度計算しなくてもディスク使用量を簡単に確認できる手段も提供しています。 クォータについては、crossref:disks[quotas,「ファイルシステムクォータ」] で解説しています。 - -その他のリソースの制限とは、ユーザが消費できる CPU、メモリなどのリソースを制限する手段のことです。 これはログインクラスを用いて定義されているもので、 この後で解説しています。 - -ログインクラスは [.filename]#/etc/login.conf# で定義します。詳細な説明は man:login.conf[5] に詳しく記載されています。 各ユーザアカウントにはログインクラスが割り当てられていて (デフォルトでは `default` です)、 それぞれのログインクラスにはログインケーパビリティの集合が割り当てられています。 ログインケーパビリティとは、 `名称=値` の組のことで、_名称_ は周知の識別子、_値_ は、_名称_ に応じて処理される任意の文字列です。 ログインクラスとケーパビリティを設定するのはどちらかといえば簡単なことで、 man:login.conf[5] でも説明されています。 - -[NOTE] -==== -FreeBSD は通常、直接 [.filename]#/etc/login.conf# から設定を読み込まず、 より速く検索できる [.filename]#/etc/login.conf.db# データベースから読み込みます。[.filename]#/etc/login.conf# を編集する時には [.filename]#/etc/login.conf.db# を次のコマンドを実行してアップデートする必要があります。 - -[source,shell] -.... -# cap_mkdb /etc/login.conf -.... - -==== - -リソースの制限は、 2 つの点で標準的なログインケーパビリティと異なっています。 第一に、どの制限についても、ソフト (現在の) リミットとハードリミットがあります。 ソフトリミットは、ユーザやアプリケーションが調整できますが、 ハードリミットを超えることはできません。 ユーザはハードリミットを下げることはできますが、 上げることはスーパユーザのみができます。 第二に、ほとんどのリソースの制限は特定のユーザに対してプロセス毎に適用されるもので、 そのユーザが利用するリソースの総量を制限するものではありません。 ただし、この違いは制限を特別扱いすることで実現されるものであり、 ログインケーパビリティフレームワークの実装によるものではありません。 - -以下が最もよく使われるリソースの制限になります。 残りは、他のすべてのログインケーパビリティと並んで man:login.conf[5] に書かれています。 - -`coredumpsize`:: -プログラムが生成する core ファイルのサイズにかかる制限は、 `filesize` やディスククォータなどの、 ほかのディスク使用に関する制限に従属します。 この制限は、ディスク領域の消費を制御するあまり厳しくない手段としてよく使われています。 ユーザは core ファイルを自分で生成するわけではなく、 削除しないことも多いので、 これを設定すれば大きなプログラムが異常終了してもディスクの空きがなくならずに済みます。 - -`cputime`:: -そのユーザのプロセスが消費できる CPU 時間 の上限です。 これを超えたプロセスは、カーネルにより終了されます。 -+ - -[NOTE] -==== -これは、消費される CPU _時間_ についての制限であって、man:top[1] や man:ps[1] のフィールドで表示される CPU の割合に関するものではありません。 -==== - -`filesize`:: -ユーザが所有できるファイルの大きさの上限です。crossref:disks[quotas,ディスククォータ] と違い、 この制限はユーザのファイルをすべてまとめた集合にではなく、 個々のファイルにかかります。 - -`maxproc`:: -ユーザが実行できるプロセス数の上限です。 フォアグラウンドプロセスとバックグラウンドプロセスの両方を扱います。 この上限は、man:sysctl[8] 変数 `kern.maxproc` で指定されたシステムの制限を超えることはできません。 同時に複数ログインすることや、 パイプライン実行することは便利なことが多いので、 この値をあまり小さな値に設定すると、 そのユーザの生産性が悪化する可能性があります。 -大きなプログラムをコンパイルする場合のように、タスクによっては複数のプロセスが実行されます。 - -`memorylocked`:: -これは、1 つのプロセスが man:mlock[2] によりメインメモリにロックされることを要求できるメモリの最大容量です。 man:amd[8] のようなシステムで重要なプログラムは、 メインメモリへロックして、システムがスワップする際に、 ディスクのスラッシングを引き起こさないようにします。 - -`memoryuse`:: -これは、どの時点かを問わず、 あるプロセスが消費できる最大のメモリ容量です。 これは、メインメモリとスワップの使用量を合わせたものです。 メモリ消費を抑えるための包括的な制限ではありませんが、 手始めにはよいでしょう。 - -`openfiles`:: -これは、あるプロセスが開いておける最大のファイル数です。 FreeBSD では、ファイルはまた、ソケットや IPC チャンネルを表わすのにも使われています。 ですから、あまり低い値に設定しないよう注意してください。 これに対応するシステム全体の制限は man:sysctl[8] `kern.maxfiles` で定義されています。 - -`sbsize`:: -これは、あるユーザが消費できるネットワークメモリ (つまり mbuf) の上限の量です。 -ネットワーク通信を制限するのに使えます。 - -`stacksize`:: -これは、プロセスのスタックサイズの上限です。 あるプログラムが使用しうるメモリの量を制限するには、 これだけでは十分ではありません。 したがって、他の制限と組み合わせて使わなければなりません。 - -リソースの制限を設定するにあたり、 ほかにもいくつか覚えておかなければならないことがあります。 以下は、一般的なこつやお勧め、さまざまなコメントになります。 - -* システム起動時に [.filename]#/etc/rc# から起動されたプロセスは、`daemon` ログインクラスに割り当てられます。 -* システムに付属していた [.filename]#/etc/login.conf# はほとんどの制限について妥当な値になっていますが、 すべてのシステムにおいてふさわしいというわけではありません。 制限をあまり緩くするとシステムを悪用しやすくしてしまいますし、 厳しくしすぎると生産性を悪化させてしまいます。 -* Xorg のユーザには、 他のユーザより多くのリソースを与えるべきかもしれません。 Xorg そのものが多くのリソースを使うだけでなく、 より多くのプログラムを並行して使うことをユーザに促します。 -* 多くの制限は個々のプロセスにかかるもので、 一人のユーザにまとめてかかるものではありません。 例えば、`openfiles` を 50 に設定することは、 ユーザが動かすそれぞれのプロセスが最大 50 個のファイルを開けるということです。 あるユーザが開けるファイルの総数は、 `openfiles` の値に `maxproc` をかけたものになります。 同じことがメモリ消費量にもあてはまります。 - -リソースの制限と、ログインクラス、 ログインケーパビリティ一般についての詳しい情報は、 man:cap.mkdb[1], man:getrlimit[2] および man:login.conf[5] をご覧ください。 - [[users-groups]] === グループの管理 グループとは、ユーザを羅列したものです。 グループは、グループ名と GID で識別されます。 FreeBSD では、 あるプロセスが何かするのを許可するかどうかをカーネルが判断する際に、 プロセスの UID とそのユーザが所属するグループの一覧を利用します。 ほとんどの場合、ユーザもしくはプロセスの GID は一覧の最初のグループを指しています。 グループ名から GID への写像は [.filename]#/etc/group# にあります。 これは、コロンで区切られた 4 項目からなるテキストファイルです。 1 番目の項目はグループ名、 2 番目は暗号化されたパスワード、 3 番目が GID、 4 番目がカンマで区切られたメンバの一覧です。 文法についての完全な説明は、man:group[5] をご覧ください。 スーパーユーザは、[.filename]#/etc/group# をテキストエディタで編集できます。 もしくは、man:pw[8] を使ってグループの追加や編集をできます。 たとえば、`teamtwo` というグループを追加して、その存在を確認するには、 次のように使います。 .man:pw[8] によるグループの追加 [example] ==== [source,shell] .... # pw groupadd teamtwo # pw groupshow teamtwo teamtwo:*:1100: .... ==== この例では、`1100` という番号は、 `teamtwo` の GID です。 この時点では、`teamtwo` にメンバはいません。 以下のコマンドは、 `jru` を `teamtwo` のメンバに追加します。 .man:pw[8] により新しいグループにメンバを追加する [example] ==== [source,shell] .... # pw groupmod teamtwo -M jru # pw groupshow teamtwo teamtwo:*:1100:jru .... ==== `-M` の引数は、 カンマで区切られた新しい (空の) グループに追加するもしくは存在するグループのメンバを置き換えるユーザの一覧です。 ユーザにとっては、このグループのメンバーシップはパスワードファイルに記載されているプライマリのグループとは異なります。 man:pw[8] の `groupshow` コマンドを使った時は、 そのユーザはグループの一員として表示されませんが、man:id[1] などのツールを使って情報を問い合わせれば、 その情報を引き出せます。ユーザをグループに追加をする際に、man:pw[8] は [.filename]#/etc/group# しか扱わず、 [.filename]#/etc/passwd# から追加のデータを読んだりはしません。 .man:pw[8] によるグループへのユーザ追加 [example] ==== [source,shell] .... # pw groupmod teamtwo -m db # pw groupshow teamtwo teamtwo:*:1100:jru,db .... ==== この例では、`-m` の引数は、 カンマで区切られたグループに追加するユーザの一覧です。 前の例と異なり、これらのユーザはグループに追加され、既存のグループのユーザを置き換えることはありません。 .グループに所属しているユーザを調べるための man:id[1] の使い方 [example] ==== [source,shell] .... % id jru uid=1001(jru) gid=1001(jru) groups=1001(jru), 1100(teamtwo) .... ==== この例では、`jru` は `jru` グループと `teamtwo` グループのメンバです。 このコマンドや [.filename]#/etc/group# のフォーマットの詳細については、 man:pw[8] および man:group[5] をご覧ください。 [[permissions]] == 許可属性 FreeBSD では、すべてのファイルおよびディレクトリは一組の許可属性を持っています。 これらの許可属性は、ユーティリティを使って確認したり変更できます。 許可属性がどのように機能するかを知ることで、ユーザが必要とするファイルにアクセスできるかどうか、オペレーティングシステムが使用しているファイルや他のユーザが所有するファイルにアクセスできないことを理解できるようになります。 この節では、FreeBSD で使用される伝統的な UNIX(R) の許可属性について説明します。 より細かいファイルシステムのアクセス制御に関しては、crossref:security[fs-acl,アクセス制御リスト] をご覧ください。 UNIX(R) では、基本の許可属性は 3 つのアクセスタイプ (読み・書き・実行) を使って割り当てられます。 これらのアクセスタイプを使って、ファイルの所有者 (owner)、グループ (group) その他 (others) に対するファイルアクセスを設定します。 読み、書き、実行に関する許可属性は、それぞれ `r`, `w`, および `x` 文字で表されます。 これらの許可属性を表す際に、オンかオフ (`0`) による 2 進数表記も使われます。 数字で表現する場合には、 `r` は `4`、`w` は `2` そして `x` は `1` の値を持つよう、`rwx` の順番で表されます。 以下は、許可属性を表す際に用いられる数字およびアルファベットをまとめた表です。 "ディレクトリの表示" カラムでは、`-` は許可属性がオフに設定されていることを表します。 .UNIX(R) 許可属性 [cols="1,1,1", frame="none", options="header"] |=== | 値 | 許可属性 | ディレクトリの表示 |0 |読み込み不可、書き込み不可、実行不可 |`---` |1 |読み込み不可、書き込み不可、実行可能 |`--x` |2 |読み込み不可、書き込み可能、実行不可 |`-w-` |3 |読み込み不可、書き込み可能、実行可能 |`-wx` |4 |読み込み可能、書き込み不可、実行不可 |`r--` |5 |読み込み可能、書き込み不可、実行可能 |`r-x` |6 |読み込み可能、書き込み可能、実行不可 |`rw-` |7 |読み込み可能、書き込み可能、実行可能 |`rwx` |=== コマンドライン引数 `-l` とともに man:ls[1] を使うと、詳細なディレクトリリストを見ることができ、ファイルの所有者、グループ、その他への許可属性を示す欄があるのがわかります。 例えば、`ls -l` を実行して、 適当なディレクトリを表示させると以下のようになります。 [source,shell] .... % ls -l total 530 -rw-r--r-- 1 root wheel 512 Sep 5 12:31 myfile -rw-r--r-- 1 root wheel 512 Sep 5 12:31 otherfile -rw-r--r-- 1 root wheel 7680 Sep 5 12:31 email.txt .... 一番目の列の最初の (一番左の) 文字は、そのファイルが普通のファイルなのか、ディレクトリなのか、キャラクタ型のデバイス特殊ファイルなのか、ソケットなのか、その他の特殊な疑似ファイルデバイスなのかといった種類を示す特別な文字です。 この例において、`-` という文字は、普通のファイルであることを示します。 その次に来る `rw-` と書かれた 3 文字は、そのファイルの所有者に許可を与えるものです。 その次の `r--` の 3 文字は、そのファイルが所属しているグループに許可を与えます。 最後の `r--` の 3 文字は、 システムに存在するその他のユーザに許可を与えます。 "-" は許可が与えられていないことを示します。 この例では、ファイルの所有者はこのファイルを読み書きでき、ファイルの所属しているグループに属するユーザはファイルを読むことだけでき、そのどちらでもないユーザは、 このファイルを読むだけできるように許可属性が与えられています。 上の表によれば、このファイルに与えられた許可属性は `644` となります。 ここで各数字は、このファイルの許可属性の 3 つの部分を表しています。 デバイスの場合の許可属性はどのようにコントロールされているのでしょうか? FreeBSD は、大部分のハードウェアをファイルとして取り扱います。 そのため、プログラムからは普通のファイルとまったく同じようにオープンし、 データの読み書きができるようになっています。 これらのデバイス特殊ファイルは [.filename]#/dev/# に収められています。 ディレクトリもまた、ファイルと同様に扱われます。 それは読み込み/書き込み/実行の許可属性を持ちます。 ディレクトリの実行ビットはファイルのそれとは少し違った意味を持ちます。 ディレクトリが実行可能になっているとき、man:cd[1] を使ってそのディレクトリに移動することができます。 これは、そのディレクトリにあるファイルにアクセスできることを意味しています (ファイル自体の許可属性によります)。 ディレクトリの中の一覧を表示するには、そのディレクトリに読み込み属性が設定されていなければなりません。 名前が分かっているファイルを削除するには、そのファイルが含まれているディレクトリに 書き込み属性 _と_ 実行属性 の両方が必要です。 この他にも許可属性ビットはありますが、いずれも setuid バイナリや sticky ディレクトリなどといった特殊な状況で使われます。 ファイルの許可属性そのものについて、また、それらの設定方法に関する詳しい情報は、 man:chmod[1] マニュアルページを参照してください。 === シンボリック表記 シンボリック表記と呼ばれる許可属性を表す方法では、ファイルやディレクトリの許可属性を、8 進数ではなく記号を用いて設定します。 シンボリック表記による許可属性を表す方法では、(who), (action), (permissions) という書式が用いられます。 利用できる値は以下の通りです。 [.informaltable] [cols="1,1,1", frame="none", options="header"] |=== | オプション | 文字 | 意味 |(who) |u |ユーザ |(who) |g |ファイルを所持しているグループ |(who) |o |その他 |(who) |a |すべて ("world") |(action) |+ |許可属性を与える |(action) |- |許可属性を取り除く |(action) |= |許可属性を指定したものにする |(permissions) |r |読み込み |(permissions) |w |書き込み |(permissions) |x |実行 |(permissions) |t |Sticky ビット |(permissions) |s |UID または GID を設定する |=== これらの値は、これまでと同様に man:chmod[1] で用いますが、数字ではなく文字で指定します。 たとえば、_FILE_ に対して自分以外のユーザからアクセスを一切受け付けたくない、というときには以下のコマンドを実行してください。 [source,shell] .... % chmod go= FILE .... カンマ区切りで設定することで、ファイルの属性を一度に 2 つ以上変更できます。 以下の例では、_FILE_ に対して自分以外のユーザから書き込みの権限を取り上げ、かわりにすべてのユーザが _FILE_ を実行できるようにします。 [source,shell] .... % chmod go-w,a+x FILE .... === FreeBSD のファイルフラグ ファイルの許可属性に加え、FreeBSD では "ファイルフラグ" を使えます。 これはファイルにセキュリティや管理上の属性を追加するものですが、ディレクトリには追加しません。 ファイルフラグにより、`root` ユーザでさえ誤ってファイルを消去、変更してしまうことを防ぐことができます。 ファイルフラグは、man:chflags[1] を使って、簡単なインタフェースで設定できます。 例えば、[.filename]#file1# というファイルにシステムレベルで消去不可のフラグを設定するには、以下のコマンドを実行してください。 [source,shell] .... # chflags sunlink file1 .... 消去不可のフラグを削除するには、以下のように `sunlink` の前に "no" をつけて実行してください。 [source,shell] .... # chflags nosunlink file1 .... ファイルに設定されているフラグを確認するには、`-lo` と一緒に man:ls[1] を実行してください。 [source,shell] .... # ls -lo file1 .... [.programlisting] .... -rw-r--r-- 1 trhodes trhodes sunlnk 0 Mar 1 05:54 file1 .... いくつかのファイルフラグの追加、削除は `root` ユーザしかできません。 他のフラグは、ファイルの所有者が変更できます。 man:chflags[1] と man:chflags[2] から、より詳細な情報を得ることをおすすめします。 === `setuid`, `setgid` および `sticky` 許可属性 これまでに説明した許可属性のほかに、 すべての管理者が知っておくべき特別な設定が 3 つあります。 それは `setuid`, `setgid` および `sticky` 許可属性です。 これらの設定は、通常のユーザには許可されていない機能を提供するので、UNIX(R) の操作において重要となることがあります。 これらの許可属性を理解するためには、実ユーザ ID と実効ユーザ ID の違いに注意してください。 実ユーザ ID は、所有したりプロセスを開始する UID です。 実効 UID は、プロセスを実行するユーザ ID です。 たとえば、ユーザがパスワードを変更するときに利用する man:passwd[1] は、実ユーザ ID で起動します。 しかしながら、パスワードデータベースのアップデートの際は、実効 ID の `root` ユーザの権限で実行されます。 この仕組みにより、`Permission Denied` エラーが表示されることなく、ユーザはパスワードを変更できます。 setuid 許可属性は、以下の例で示されているように、指定する許可属性に数字の 4 をつけて設定します。 [source,shell] .... # chmod 4755 suidexample.sh .... これで [.filename]#suidexample.sh# の許可属性は以下のように設定されます。 [.programlisting] .... -rwsr-xr-x 1 trhodes trhodes 63 Aug 29 06:36 suidexample.sh .... `s` は、許可属性のファイル所有者の実行可能ビットに置き換わって反映されます。 この設定により、man:passwd[1] といったユーティリティが権限を昇格することができます。 [NOTE] ==== `nosuid` man:mount[8] オプションを使うと、このようなバイナリがユーザへの警告なしに権限を昇格できないように設定できます。 ただし `nosuid` ラッパにより回避できるため、このオプションを完全には信頼できません。 ==== リアルタイムに確認するために、2 つのターミナルを開いてください。 1 つのターミナル上で、通常のユーザ権限で `passwd` と入力してください。 パスワードの入力を待つ間に、もう一つのターミナル上で、プロセステーブルおよび man:passwd[1] のユーザ情報を確認してください。 ターミナル A: [source,shell] .... Changing local password for trhodes Old Password: .... ターミナル B: [source,shell] .... # ps aux | grep passwd .... [source,shell] .... trhodes 5232 0.0 0.2 3420 1608 0 R+ 2:10AM 0:00.00 grep passwd root 5211 0.0 0.2 3620 1724 2 I+ 2:09AM 0:00.01 passwd .... 通常のユーザ権限で man:passwd[1] を実行したにもかかわらず、実効 UID の `root` が使われています。 `setgid` 許可属性は `setuid` 許可属性と同様の機能を提供しますが、この許可属性はグループの設定を変更します。 この設定を行った上でアプリケーションまたはユーティリティを実行すると、プロセスを開始するユーザではなく、ファイルを所有するグループに対してこの許可属性を与えます。 ファイルに `setgid` 許可属性を設定するには、man:chmod[1] で設定する許可属性の先頭に 2 をつけて実行してください。 [source,shell] .... # chmod 2755 sgidexample.sh .... 以下に示されるように、`s` がグループの許可属性に指定されています。 [source,shell] .... -rwxr-sr-x 1 trhodes trhodes 44 Aug 31 01:49 sgidexample.sh .... [NOTE] ==== 上記の例において、対象としているシェルスクリプトが実行可能なファイルであっても、シェルスクリプトは man:setuid[2] システムコールにアクセスできないため、実効ユーザ ID では実行されません。 ==== `setuid` および `setgid` 許可属性ビットは、権限の昇格を許可するので、システムのセキュリティレベルを下げます。 一方 3 番目の特殊な許可属性 `sticky bit` は、システムのセキュリティを強化します。 ディレクトリに `sticky bit` を設定すると、ファイルの所有者のみがファイルを削除できるようになります。 [.filename]#/tmp# といった共有のディレクトリにおいて、ファイルの所有者以外のユーザがファイルを削除できなくなるので有用です、 この許可属性を有効にするには、許可属性に 1 をつけて設定してください。 [source,shell] .... # chmod 1777 /tmp .... `sticky bit` が設定されていると、許可属性の最後に `t` が表示されます。 [source,shell] .... # ls -al / | grep tmp .... [source,shell] .... drwxrwxrwt 10 root wheel 512 Aug 31 01:49 tmp .... [[dirstructure]] == ディレクトリ構造 FreeBSD のディレクトリ構造は、システム全体を理解するに当たって重要です。 最も重要なディレクトリは、ルートまたは "/" です。 このディレクトリは起動時に一番最初にマウントされ、オペレーティングシステムをマルチユーザで動作させるために必要なベースシステムが含まれています。 また、ルートディレクトリには、マルチユーザへの移行中に他のファイルシステムをマウントするためのマウントポイントも含まれます。 マウントポイントとは、追加するファイルシステムを接続する先の親のファイルシステム (普通はルートファイルシステム) のディレクトリのことです。 より詳細な説明は <> の節にあります。 標準的なマウントポイントには [.filename]#/usr/#, [.filename]#/var/#, [.filename]#/tmp/#, [.filename]#/mnt/# および [.filename]#/cdrom/# があります。 通常これらのディレクトリについては、 [.filename]#/etc/fstab# というファイル中のエントリが参照されます。 このファイルは、さまざまなファイルシステムとマウントポイントの表であり、システムが参照します。 [.filename]#/etc/fstab# に書かれたファイルシステムは `noauto` オプションが指定されていなければ、起動時に man:rc[8] スクリプトによって自動的にマウントされます。 詳細は <> の節をご覧ください。 ファイルシステム構造を網羅した説明は man:hier[7] に書かれています。 以下の表は、もっともよく使われるディレクトリの簡単な概要です。 [.informaltable] [cols="1,1", frame="none", options="header"] |=== | ディレクトリ | 説明 |[.filename]#/# |ファイルシステムのルートディレクトリ |[.filename]#/bin/# |シングルユーザ環境とマルチユーザ環境の両方で重要な ユーザユーティリティ |[.filename]#/boot/# |オペレーティングシステムの起動時に使われるプログラムと設定ファイル |[.filename]#/boot/defaults/# |デフォルトの起動設定ファイル; man:loader.conf[5] 参照 |[.filename]#/dev/# |デバイスノード; man:intro[4] 参照 |[.filename]#/etc/# |システム設定ファイルとスクリプト |[.filename]#/etc/defaults/# |デフォルトのシステム設定ファイル; 詳細については man:rc[8] 参照 |[.filename]#/etc/mail/# |man:sendmail[8] のようなメール転送エージェントの設定ファイル |[.filename]#/etc/periodic/# |man:cron[8] 経由で毎日・毎週・毎月実行されるスクリプト; 詳細については man:periodic[8] 参照 |[.filename]#/etc/ppp/# |man:ppp[8] の設定ファイル |[.filename]#/mnt/# |システム管理者が一時的なマウントポイントとしてよく使う空のディレクトリ |[.filename]#/proc/# |プロセスファイルシステム; 詳細については man:procfs[5] と man:mount_procfs[8] 参照 |[.filename]#/rescue/# |man:rescue[8] で説明されている緊急時のために静的にリンクされているプログラム |[.filename]#/root/# |`root` アカウントのホームディレクトリ |[.filename]#/sbin/# |シングルユーザ環境とマルチユーザ環境の両方で重要なシステムプログラムと管理ユーティリティ |[.filename]#/tmp/# |システムの再起動では通常保存 _されない_ 一時的なファイル。 メモリファイルシステムはよく [.filename]#/tmp# にマウントされます。 これは man:rc.conf[5] の tmpmfs 関係の変数を使うか、 [.filename]#/etc/fstab# に設定項目を記入することで自動化できます。 詳しくは man:mdmfs[8] を参照して下さい。 |[.filename]#/usr/# |大部分のユーザユーティリティとアプリケーション |[.filename]#/usr/bin/# |よく使うユーティリティとプログラミングツールとアプリケーション |[.filename]#/usr/include/# |C の標準ヘッダファイル |[.filename]#/usr/lib/# |ライブラリ |[.filename]#/usr/libdata/# |いろいろなユーティリティのデータファイル |[.filename]#/usr/libexec/# |他のプログラムから実行されるシステムデーモンとシステムユーティリティ |[.filename]#/usr/local/# |ローカルのプログラムやライブラリなど。 FreeBSD ports フレームワークのデフォルトインストール先としても使われます。 [.filename]#/usr/local# 内では、 man:hier[7] に書かれている [.filename]#/usr# のための一般構造が使われます。 例外は man ディレクトリで、 [.filename]#/usr/local/share# の下ではなく [.filename]#/usr/local# の下に直接置かれ、ports 関係文書は [.filename]#share/doc/port# に置かれます。 |[.filename]#/usr/obj/# |[.filename]#/usr/src# ツリーのビルドで作られるアーキテクチャ依存のターゲットツリー |[.filename]#/usr/ports/# |FreeBSD Ports Collection (オプション)。 |[.filename]#/usr/sbin/# |ユーザにより実行されるシステムデーモンおよびシステムユーティリティ |[.filename]#/usr/share/# |アーキテクチャに依存しないファイル |[.filename]#/usr/src/# |BSD のソースファイルまたはローカルのソースファイル、あるいは両方 |[.filename]#/var/# |さまざまな用途のログ・一時的なファイル・スプールファイル。メモリファイルシステムは時々 [.filename]#/var# にマウントされます。 これは man:rc.conf[5] の varmfs 関係の変数を使うか、 [.filename]#/etc/fstab# に設定項目を記入することで自動化できます。 詳しくは man:mdmfs[8] を参照して下さい。 |[.filename]#/var/log/# |いろいろなシステムログファイル |[.filename]#/var/mail/# |ユーザのメールボックスファイル |[.filename]#/var/spool/# |プリンタとメールシステムのスプールディレクトリなどなど |[.filename]#/var/tmp/# |一時的なファイル。 [.filename]#/var# がメモリファイルシステムでなければ、 ここにあるファイルはシステムが再起動しても失われません。 |[.filename]#/var/yp/# |NIS のマップ |=== [[disk-organization]] == ディスク構成 ファイルを見つけるために FreeBSD が使用する構成の一番小さな単位はファイル名です。 ファイル名は、大文字と小文字を区別します。 このことは [.filename]#readme.txt# および [.filename]#README.TXT# が異なる二つのファイルであることを意味します。 FreeBSD はそのファイルがプログラム、または文書、あるいはその他の形式かどうかを決定するために拡張子を使用しません。 ファイルはディレクトリ内に格納されます。 ディレクトリはファイルを一つも含んでいないかもしれせんし、または数百のファイルを含んでいるかもしれません。 ディレクトリはまた別のディレクトリを含むことができるので、 データを体系づけるディレクトリの階層構造を構築できます。 ファイルおよびディレクトリは、必要な他のディレクトリ名とスラッシュ (`/`) を後に続けてファイル名またはディレクトリ名を与えることによって参照されます。 たとえば、[.filename]#foo# ディレクトリがあって、その中に [.filename]#bar# ディレクトリがあるとします。 そして、その中に [.filename]#readme.txt# があるとすると、ファイルへのフルネーム、または _パス_ は [.filename]#foo/bar/readme.txt# となります。 ファイルとディレクトリ名を分けるために `\` を使う Windows(R) とは違うことに注意してください。 FreeBSD は、パスの中にドライブレターまたは他のドライブ名を使いません。 たとえば、FreeBSD では [.filename]#c:\foo\bar\readme.txt# とは書きません。 ディレクトリおよびファイルはファイルシステム内に格納されます。 どのファイルシステムも、そのファイルシステムのための _ルートディレクトリ_ とよばれる、まさに頂点の位置にちょうど一つのディレクトリを含んでいます。 このルートディレクトリは他のディレクトリを含むことができます。 一つのファイルシステムは _ルートファイルシステム_ または `/` として設計されています。 すべてのファイルシステムは、ルートファイルシステム以下に _マウント_ されます。 FreeBSD システムでどんなに多くのディスクを使用しても、すべてのディレクトリは、同じディスクの一部であるように見えるので問題ありません。 `A`, `B` および `C` と呼ばれる三つのファイルシステムがあるケースを考えます。 それぞれのファイルファイルシステムには一つのルートディレクトリがあり、`A1`, `A2` と呼ばれている二つの他のディレクトリを含んでいます (同様に `B1`, `B2` および `C1`, `C2` があります)。 `A` をルートファイルシステムとします。 このディレクトリになにが含まれているか見るために man:ls[1] コマンドを使うと、`A1` および `A2` の二つのサブディレクトリが表示されるでしょう。 ディレクトリツリーは以下のようになります。 image::example-dir1.png[] ファイルシステムはマウント先のファイルシステム内のディレクトリにマウントしなければいけません。 それでは、`A1` ディレクトリに `B` ファイルシステムをマウントすると仮定します。 `B` のルートディレクトリは `A1` に置き換えられ、そして `B` 内のディレクトリがそれに応じて現れます。 image::example-dir2.png[] `B1` または `B2` 内にあるどんなファイルも、必要なときに [.filename]#/A1/B1# または [.filename]#/A1/B2# で到達できます。 [.filename]#/A1# にあったすべてのファイルは一時的に隠されました。 それらは `B` が `A` から _アンマウント_ されたら再び現れるでしょう。 もし `B` が `A2` にマウントされていたら、この図のようになります。 image::example-dir3.png[] そして、パスはそれぞれ [.filename]#/A2/B1# および [.filename]#/A2/B2# となるでしょう。 ファイルシステムは互いのファイルシステム上にもマウントできます。 上記の最後の例に続けて、`C` ファイルシステム は `B` ファイルシステム内の `B1` ディレクトリ上にマウントできます。 次の図のようになります。 image::example-dir4.png[] または `C` を `A` ファイルシステムの `A1` ディレクトリの下に直接マウントできます。 image::example-dir5.png[] 一つの大きなルートファイルシステムを用意し、他のファイルシステムを作成する必要としないことはまったくもって可能です。 この方法にはいくつかの短所と一つの利点があります。 .マルチファイルシステムの利点 * 異なったファイルシステムは異なった _マウントオプション_ を使用できます。 たとえば、ルートファイルシステムを読みだし専用でマウントして、不注意によってユーザが重大なファイルを削除、または編集できないようにすることができます。 また、[.filename]#/home# のようなユーザが書き込み可能なファイルシステムを他のファイルシステムと分けることによって、 _nosuid_ でマウントすることが可能になります。 このオプションは、ファイルシステムに記録されている _suid_/_guid_ の実行可能ビットを有効にしないので、安全性を高めることができるでしょう。 * FreeBSD はファイルシステムがどのように使われているかによって、自動的にファイルシステム上のファイルの配置を最適化します。 したがって、連続的に書き込まれた多くの小さなファイルが含まれているファイルシステムは、より大きく少ないファイルが含まれているファイルシステムと異なる最適化をするでしょう。 一つの大きなファイルシステムを作成すると、この最適化は成り立たなくなります。 * FreeBSD のファイルシステムはトラブルが起きても強固です。 しかしながら臨界点でのトラブルは、ファイルシステムの構造にまだ損害を与えるかもしれません。 マルチファイルシステムへデータを分割しておくことで、 必要なときにバックアップからレストアすることをより容易にして、まだシステムが回復するかもしれません。 .シングルファイルシステムの利点 * ファイルシステムは固定サイズです。 FreeBSD をインストールするときにファイルシステムを作成して、 固定サイズを割りあてたなら、 後になってそのパーティションをより大きくする必要があると気づくかもしれません。 パーティションのサイズを変更するには、 バックアップ、新しいサイズを指定したファイルシステムの再作成、 バックアップしたデータをリストアする作業が必要となるでしょう。 + [IMPORTANT] ==== FreeBSD には、 man:growfs[8] コマンドがあります。 このコマンドは、この制限を取り除いて、 ファイルシステムのファイルを直ちに増加させることを可能にします。 ==== ファイルシステムはパーティション内に含まれています。 FreeBSD の UNIX(R) 遺産のために、 これは普段使われるパーティション (例えば MS-DOS(R) パーティション) という用語の意味とは違う意味を持っています。 それぞれのパーティションは `a` から `h` までの文字で区別されます。 それぞれのパーティションは、 一つのファイルシステムだけを含むことができます。 このことは、ファイルシステムがファイルシステムの階層上の典型的なマウントポイント、 または含まれているパーティションの文字によって記述されることを意味します。 FreeBSD は _スワップ領域_ にもまたディスク領域を使用します。 スワップ領域は FreeBSD に _仮想メモリ_ を提供します。 これはあなたのコンピュータが、 実際に搭載している以上のメモリがあるかのように振舞います。 FreeBSD がメモリを使い果たしたときに、現在使用されていないデータのいくつかをスワップ領域に移動し、そのデータが必要となったときに (その他のデータをスワップ領域に移動させてから) メモリ内に移動しなおします。 いくつかのパーティションはある慣習と関係づけられています。 [.informaltable] [cols="1,1", frame="none", options="header"] |=== | パーティション | 慣習 |`a` |通常、ルートパーティションを含みます。 |`b` |通常、スワップ領域を含みます。 |`c` |通常、スライス全体と同じサイズです。 これは、スライス全体にアクセス必要のあるユーティリティ (たとえば、ひどいブロックスキャナ) が、 `c` パーティションにアクセスすることを可能にします。 通常、このパーティション内にファイルシステムは作成されません。 |`d` |`d` パーティションは、 それに関連づけられた特別な意味を持っていましたが、 今は無いので、普通のパーティションとして動作するでしょう。 |=== FreeBSD のディスクはスライスに分けられます。 Windows(R) ではパーティションと呼ばれるもので、 スライスには 1 から 4 までの番号がつけられます。 これらのスライスは、ファイルシステムを含むパーティションに分けられます。 パーティションは文字で表されます。 スライス番号は 1 から始まり `s` を前につけられて、デバイス名の後に続きます。 したがって、"da0__s1__" は一番目の SCSI ドライブ上の 一番目のスライスです。 ディスク上に存在できる物理スライスは、4 つまでですが、適切な種類の物理スライス内に論理スライスを作成できます。 これらの拡張されたスライス番号は 5 から始まります。 したがって、 "ada0__s5__" は、一番目の SATA ディスク上の一番目の拡張スライスです。 これらのデバイスは、 スライスを占有することを予期するファイルシステムによって使用されます。 スライスや "危険な専用" の物理ドライブ、 そして他のドライブは `a` から `h` までの文字として表される _パーティション_ を含んでいます。 この文字はデバイス名に追加されます。 したがって、 "da0__a__" は一番目の "危険な専用" `da` ドライブ上の `a` パーティションです。 "ada1s3__e__" は、 二番目の SATA ディスク上の 三番目のスライス内にある五番目のパーティションです。 最後に、システム上のそれぞれのディスクは識別されます。 ディスク名はどの種類のディスクであるかを示す記号ではじまり、どのディスクかを示す数字が続きます。 スライスとは違いディスクの番号づけは 0 から始まります。 共通の記号は <> に示されます。 パーティションを参照するときには、 ディスク名、`s`、スライス番号、 そしてパーティション文字を含めてください。 <> に例があります。 <> は、ディスク構成の概念のモデルを示します。 FreeBSD をインストールする際には、ディスクスライスの設定し、次に FreeBSD に用いるスライス内のパーティションを作成し、それからそれぞれのパーティション内にファイルシステムまたはスワップ領域を作成し、 ファイルシステムがどこにマウントされるか決定しなければいけません。 [[disks-naming]] .ディスクデバイス名 [cols="1,1", frame="none", options="header"] |=== | ドライブタイプ | ドライブデバイス名 |SATA および IDE ハードドライブ |`ada` |SCSI ハードドライブおよび USB ストレージデバイス |`da` |NVMe ストレージ |`nvd` または `nda` |SATA および IDE CD-ROM ドライブ |`cd` |SCSI CD-ROM ドライブ |`cd` |フロッピードライブ |`fd` |SCSI テープドライブ |`sa` |RAID ドライバ |`aacd` (Adaptec(R) AdvancedRAID), `mlxd` および `mlyd` (Mylex(R)), `amrd` (AMI MegaRAID(R)), `idad` (Compaq Smart RAID), `twed` (3ware(R) RAID) など |=== [example] ==== [[basics-disk-slice-part]] .ディスク名、スライス名、パーティション名のサンプル [.informaltable] [cols="1,1", frame="none", options="header"] |=== | 名前 | 意味 |`ada0s1a` |一番目の SATA ディスク (`ada0`) 上の一番目のスライス (`s1`) 内の一番目のパーティション (`a`)。 |`da1s2e` |二番目の SCSI ディスク (`da1`) 上の二番目のスライス (`s2`) 内の五番目のパーティション (`e`)。 |=== ==== [[basics-concept-disk-model]] .ディスクの概念的構成 [example] ==== これはシステムに接続された一番目の SATA ディスクの FreeBSD から見た図を示します。 ディスクサイズは 250 GB と仮定し、80 GB のスライス (MS-DOS(R) でいうパーティション) および 170 GB のスライスがあるとします。 一番目のスライスは Windows(R) NTFS ファイルシステム [.filename]#C:# を含んでいます。 そして、二番目のスライスは FreeBSD のディスクを含んでいます。 これは FreeBSD インストーラが四つのデータパーティションと一つのスワップパーティションを作成した例です。 四つのパーティションはそれぞれファイルシステムを含んでいます。 パティション `a` はルートファイルシステム、`d` は [.filename]#/var#、`e` は [.filename]#/usr#、そして `f` は [.filename]#/usr# に使用されています。 パーティション `c` はスライス全体を示しており、通常のパーティションとは異なる使われ方をします。 image::disk-layout.png[] ==== [[mount-unmount]] == ファイルシステムのマウントとアンマウント ファイルシステムは [.filename]#/# をルート (根) とする木構造として考えると視覚的に理解しやすいでしょう。 ルートディレクトリにある [.filename]#/dev# や [.filename]#/usr#、その他のディレクトリは枝に相当し、それらには、[.filename]#/usr/local# などのように、さらに枝分かれすることができます。 さまざまな理由がありますが、 ディレクトリをいくつかの異なるファイルシステム上に構築するのが良いでしょう。 たとえば [.filename]#/var# には、 [.filename]#log/# や [.filename]#spool/# など、さまざまな種類の一時ファイルを置くディレクトリがあるため、あふれてしまう可能性があります。 ルートファイルシステムをあふれさせるのは得策ではありませんので、普通は [.filename]#/var# を [.filename]#/# から分離します。 また、次のような場合も、ディレクトリツリーを別のファイルシステムに置く理由として良くあげられます。 それは、たとえば物理的に別のディスクにディレクトリツリーを置く場合、 crossref:advanced-networking[network-nfs, 「ネットワークファイルシステム (NFS)」] で説明されているようにネットワークファイルシステムをマウントしたり、CDROM ドライブのような別の仮想ディスクに置くという場合です。 [[disks-fstab]] === [.filename]#fstab# ファイル [.filename]#/etc/fstab# に書かれているファイルシステムは、`noauto` オプション指定されているエントリを除いて crossref:boot[boot,起動プロセス] の途中で自動的にマウントされます。 このファイルは、 次のような書式で書かれたエントリを含んでいます。 [.programlisting] .... device /mount-point fstype options dumpfreq passno .... `device`:: デバイス名。crossref:disks[disks-naming,「デバイス名」] に説明があります。 `mount-point`:: ファイルシステムがマウントするディレクトリ。 `fstype`:: man:mount[8] に渡されるファイルシステムタイプ。 FreeBSD ファイルシステムのデフォルトは `ufs` です。 `options`:: 読み書きするファイルシステムには `rw`、読み込み専用のファイルシステムには `ro` を、必要な他のオプションの前に指定します。 よく使われるオプションは `noauto` で、 起動時にはマウントされないファイルシステムに使います。 その他のオプションは man:mount[8] マニュアルページに載っています。 `dumpfreq`:: これは man:dump[8] が使うもので、 どのファイルシステムにダンプが必要なのかを決めます。 この項目がなければ、0 であるものとみなされます。 `passno`:: これはファイルシステムをチェックする順番を決めます。 ファイルシステムチェックを飛ばしたいファイルシステムには、`passno` を 0 に設定してください。 ルートファイルシステムはどれよりも先にチェックする必要があり、`passno` は 1 に設定してください。 他のファイルシステムの `passno` は 1 以上に設定してください。 同じ `passno` のファイルシステムがあった場合、 man:fsck[8] は可能であれば並行してファイルシステムのチェック を行なおうとします。 [.filename]#/etc/fstab# の書式やオプションに関しての詳細は、 man:fstab[5] をご覧ください。 [[disks-mount]] === man:mount[8] の使い方 ファイルシステムは man:mount[8] を用いてマウントされます。 基本な構文は以下のようになります。 [example] ==== [source,shell] .... # mount device mountpoint .... ==== man:mount[8] で説明されているように、このコマンドはたくさんのオプションを提供しますが、最もよく使われるのは次のものです。 .マウントオプション `-a`:: [.filename]#/etc/fstab# にある全てのファイルシステムをマウントします。 例外は "noauto" の印がついているものと、 `-t` フラグで除外されたものと、 すでにマウントされているファイルシステムです。 `-d`:: 実際にマウントシステムコールする以外のすべてのことをします。 このオプションは `-v` フラグと組み合わせて使い、 man:mount[8] が実際なにをしようとしているのか調べるのに便利です。 `-f`:: クリーンでないファイルシステムを強制的にマウントします (危険です)。もしくは、ファイルシステムのマウント状態を 読み書き可能から読み込みのみに変更するとき、 書き込みアクセスを強制的に取り消します。 `-r`:: ファイルシステムを読み込み専用でマウントします。 `-o ro` を使うのと同じです。 ``-t _fstype_``:: 指定のファイルシステムタイプでマウントします。 または、`-a` を使った場合、 指定したタイプのファイルシステムのみマウントします。 デフォルトのファイルシステムタイプは "ufs" です。 `-u`:: ファイルシステムのマウントオプションを更新します。 `-v`:: 詳細な出力にします。 `-w`:: ファイルシステムを読み書き可能にマウントします。 `-o` には、 次のようなオプションを複数カンマで区切って指定できます。 nosuid:: そのファイルシステム上の setuid や setgid フラグを解釈しません。 これもセキュリティのために有用なオプションです。 [[disks-umount]] === man:umount[8] の使い方 ファイルシステムをアンマウントするには、man:umount[8] を使ってください。 このコマンドは、パラメータとしてマウントポイントの一つ、 デバイス名、もしくは `-a` や `-A` といったオプションを取ります。 いずれの形式でも `-f` で強制的なアンマウントを行ない、 `-v` で詳細な出力を出します。 ただしほとんどの場合、`-f` は使わないほうがよいでしょう。 計算機がクラッシュしたりファイルシステム上部のデータが破壊されたりする恐れがあります。 マウントされているファイルシステムすべてをアンマウントするには、`-a` と `-A` を使ってください。 `-t` にファイルシステムタイプを指定すると、指定されたものだけがアンマウントされます。 `-A` を使うとルートファイルシステムはアンマウントしません。 [[basics-processes]] == プロセスおよびデーモン FreeBSD はマルチタスクのオペレーティングシステムです。 動作中のプログラムはそれぞれ _プロセス_ と呼ばれます。 すべてのコマンドは実行すると、最低でも 1 つの新しいプロセスを開始します。 FreeBSD により実行されているシステムプロセスもたくさんあります。 各プロセスは _プロセス ID_ (PID) と呼ばれる数字でただ一つに識別されます。 ファイルのように各プロセスには所有者とグループがあり、 所有者とグループの許可属性は、そのプロセスが開けるファイルやデバイスを決定するために使われます。 多くのプロセスには親プロセスもあります。 親プロセスとは、そのプロセスをスタートさせたプロセスのことです。 例えば、シェルがプロセスで、シェルから起動されるコマンドは、シェルを親プロセスとするプロセスとなります。 例外は man:init[8] という特別なプロセスです。 `init` は FreeBSD がスタートするときに起動される最初のプロセスで、PID は常に `1` です。 ユーザから始終入力があるように設計されていないプログラムがあり、そういったプログラムは最初から端末と切り離されています。 例えば、ウェブサーバはユーザからの入力ではなくウェブのリクエストを処理します。 メールサーバも、 こういった種類のアプリケーションの一例です。 このような種類のプログラムは、 _デーモン_ と呼ばれます。 デーモンはギリシャ神話から来ており、目に見えないように役立つことをしてくれる善でも悪でもない実体を表します。 このため、BSD のマスコットはスニーカーをはいてフォークを携えたかわいらしい姿のデーモンなのです。 通常デーモンとして動作するプログラムには末尾に "d" を持った名前をつける慣習があります。 例えば、BIND は Berkeley Internet Name Domain ですが、 実際実行されるプログラムは `named` です。 また、Apache ウェブサーバのプログラムは `httpd`、ラインプリンタスプーリングデーモンは `lpd` です。 これは単なる命名に関する慣習です。 例えば、Sendmail アプリケーションの主なメールデーモンは `sendmail` で、`maild` ではありません。 === プロセスを確認する システム上で実行中のプロセスを確認するには、man:ps[1] または man:top[1] を使ってください。 現在動作中のプロセスのリスト、プロセスの PID やプロセスが使っているメモリの量、どういうコマンドラインで起動されたのかなどを表示させるには、man:ps[1] を使ってください。 man:top[1] を使用すると、動作中の全てのプロセスを表示できます。 数秒ごとに表示を更新するので、計算機が何をしているのかインタラクティブに知ることができます。 デフォルトでは、man:ps[1] はユーザにより動作中かつ所有のコマンドのみを表示します。 例えば: [source,shell] .... % ps PID TT STAT TIME COMMAND 8203 0 Ss 0:00.59 /bin/csh 8895 0 R+ 0:00.00 ps .... man:ps[1] の出力はいくつかの列に整形されています。 `PID` の列はプロセス ID を表示します。 PID は 1 から順に 99999 まで割り当てられ、その後足りなくなると最初に戻って使い回されます。ただし、使用中の PID には割り当てられません。 `TT` の列はプログラムが動いている tty を示し、`STAT` はプログラムの状態を示します。 `TIME` はプログラムがその CPU 上で動いている時間の長さです。 通常はプログラムをスタートさせたときからの経過時間ではありません。 多くのプログラムは、CPU 上で時間を使う必要があるまでかなりの時間を費すためです。 最後に、`COMMAND` はそのプログラムを起動するのに使われたコマンドとなります。 表示する情報を変更するオプションが用意されています。 いちばん便利なのは `auxww` でしょう。 `a` はすべてのユーザの動作中のプロセス全部についての情報を表示します。 `u` はプロセスの所有者のユーザ名とメモリ使用量を表示します。 `x` はデーモンプロセスについての情報を表示し、`ww` で、スクリーンに入りきらないほど長くなったコマンドラインでも省略せず、man:ps[1] に各プロセスの全コマンドラインを表示させます。 man:top[1] の出力も同様です。 [source,shell] .... % top last pid: 9609; load averages: 0.56, 0.45, 0.36 up 0+00:20:03 10:21:46 107 processes: 2 running, 104 sleeping, 1 zombie CPU: 6.2% user, 0.1% nice, 8.2% system, 0.4% interrupt, 85.1% idle Mem: 541M Active, 450M Inact, 1333M Wired, 4064K Cache, 1498M Free ARC: 992M Total, 377M MFU, 589M MRU, 250K Anon, 5280K Header, 21M Other Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 557 root 1 -21 r31 136M 42296K select 0 2:20 9.96% Xorg 8198 dru 2 52 0 449M 82736K select 3 0:08 5.96% kdeinit4 8311 dru 27 30 0 1150M 187M uwait 1 1:37 0.98% firefox 431 root 1 20 0 14268K 1728K select 0 0:06 0.98% moused 9551 dru 1 21 0 16600K 2660K CPU3 3 0:01 0.98% top 2357 dru 4 37 0 718M 141M select 0 0:21 0.00% kdeinit4 8705 dru 4 35 0 480M 98M select 2 0:20 0.00% kdeinit4 8076 dru 6 20 0 552M 113M uwait 0 0:12 0.00% soffice.bin 2623 root 1 30 10 12088K 1636K select 3 0:09 0.00% powerd 2338 dru 1 20 0 440M 84532K select 1 0:06 0.00% kwin 1427 dru 5 22 0 605M 86412K select 1 0:05 0.00% kdeinit4 .... 出力は2つのセクションに分かれています。 ヘッダ (最初の 5 または 6 行) は動作している最新のプロセスの PID、システムの平均負荷 (システムがどれくらい忙しいかの指標)、システムの稼働時間 (最後の再起動からの時間) と現在の時刻を示します。 ヘッダの中の他の数字は動作中のプロセスの数、使われているメモリとスワップ領域の量、そしてシステムが異なる CPU 状態に消費した時間と関係します。 ZFS ファイルシステムのモジュールをロードしている場合には、`ARC` 行にはディスクではなくメモリキャッシュから読み込んだデータ量が表示されます。 ヘッダの下には、PID、ユーザ名、消費 CPU 時間とプロセスを起動したコマンドといった man:ps[1] の出力と同じような情報を持った行が続きます。 man:top[1] を使うとデフォルトでプロセスが使っているメモリ容量を表示します。 メモリ使用量の欄は 2 項目に分かれており、 一方は合計使用量、 そしてもう一方は実使用量です。 合計使用量はアプリケーションが必要としているメモリ量で、実使用量はその時点で実際に使われているメモリ量です。 man:top[1] は自動的に 2 秒ごとに画面を更新します。 `-s` 使うと更新間隔を変更することができます。 [[basics-daemons]] === プロセスの終了 動作中のプロセスもしくはデーモンと通信する一つの方法は、man:kill[1] を用いて _シグナル_ を送信する方法です。 送信可能なシグナルはたくさんあります。 特別な意味があるものもあれば、アプリケーションの文章に説明されているものもあります。 ユーザは自分が所有者となっているプロセスにのみシグナルを送ることができます。 他人のプロセスにシグナルを送ると、permission denied というエラーになるでしょう。 この例外は `root` ユーザで、 ルートユーザは誰のプロセスに対してもシグナルを送ることができます。 オペレーティングシステムもプロセスにシグナルを送ることができます。 アプリケーションを下手に書いてしまい、予想外のメモリにアクセスしようとすると、FreeBSD はプロセスに "セグメンテーション違反" シグナル (`SIGSEGV`) を送ります。 ある程度の時間が経ったら man:alarm[3] システムコールを使って警告してもらうように書かれているアプリケーションには、"警告" シグナル (`SIGALRM`) が送信されます。 プロセスを止めるためには2つのシグナル、`SIGTERM` か `SIGKILL` を使います。 `SIGTERM` は穏かにプロセスを終了させる方法です。 プロセスはシグナルを受け取ることができ、開いているすべてのログファイルを閉じ、終了前にしていたことを終えるように試みることができます。 中断できない処理の途中だと、`SIGTERM` をプロセスが無視することもあるかもしれません。 プロセスは `SIGKILL` を無視することができません。 プロセスに `SIGKILL` を送ると、プロセスは通常その時点で止まります。 他に良く使われるシグナルには、`SIGHUP`、`SIGUSR1` と `SIGUSR2` があります。 これらは一般的な用途のシグナルなので、このシグナルが送信されたときの応答は、アプリケーション毎に異なります。 例として、ウェブサーバの設定ファイルを変更後、ウェブサーバに設定を再読み込みさせる必要があります。 `httpd` を再起動するとウェブサーバは一瞬ながら停止してしまいます。 その代わりに `SIGHUP` シグナルを送りましょう。 デーモンごとに行動が違うので、`SIGHUP` が期待する結果となるように、そのデーモンの文書を読んで確認してください。 [.procedure] **** .Procedure: プロセスにシグナルを送る この例では、man:inetd[8] にシグナルを送る方法を示します。 man:inetd[8] の設定ファイルは [.filename]#/etc/inetd.conf# で、man:inetd[8] は `SIGHUP` が送信されるとこの設定ファイルを再読み込みします。 . man:pgrep[1] を使ってシグナルを送りたいプロセスの PID を調べます。 この例では man:inetd[8] の PID は 198 です。 + [source,shell] .... % pgrep -l inetd 198 inetd .... + . man:kill[1] を使ってシグナルを送ります。 man:inetd[8] は `root` が所有しているため、まず man:su[1] を使って `root` になってください。 + [source,shell] .... % su Password: # /bin/kill -s HUP 198 .... 大部分の UNIX(R) コマンドと同じく、 成功したら man:kill[1] は何の出力も表示しません。 ユーザが所有していないプロセスにシグナルを送ると、`kill: _PID_: Operation not permitted` といったメッセージが表示されます。 PID を打ち間違えると、間違ったプロセスにシグナルを送ってしまい悪い結果になってしまったり、その時点で使われていない PID にシグナルを送ったことになり、`kill: _PID_: No such process` とエラーが表示されます。 [NOTE] ==== *なぜ `/bin/kill` を使うんでしょう?:* + 多くのシェルは `kill` を組み込みコマンドとして備えています。 つまり、[.filename]#/bin/kill# を実行するのではなく、シェルが直接シグナルを送ります。 シェルが違うと送るシグナルの名前の指定の仕方が違うことに注意してください。 シェルによって異なるシグナルの指定の仕方を全部覚えようとはせずに、 `/bin/kill` を直接使うほうが簡単です。 ==== **** 他のシグナルを送る場合は、コマンドラインの `TERM` や `KILL` を必要に応じて置き換えてください。 [IMPORTANT] ==== システム上のランダムプロセスを終了させるのはよくありません。 特に、PID が 1 の man:init[8] は特別です。 `/bin/kill -s KILL 1` は推奨されていませんが、実行するといとも簡単にシステムをシャットダウンさせることができます。 kbd:[Return] を押す _前_ に man:kill[1] を実行する引数を二重にチェックする _癖_ をつけてください。 ==== [[shells]] == シェル _シェル_ は、オペレーティングシステムを利用するためのコマンドラインインタフェースを提供します。 シェルは入力チャンネルからコマンドを受け取り、それらを実行します。 大部分のシェルは、日々の作業、ファイル管理やファイル名の展開、コマンドライン編集、コマンドマクロ、環境変数といった組み込みの機能を持ってます。 FreeBSD には Bourne Shell (man:sh[1]) や 高機能 C-shell (man:tcsh[1]) が含まれています。 また、これ以外にも `zsh` や `bash` などのシェルが FreeBSD Ports Collection から利用可能です。 どのシェルを使うかは、まったく趣味の問題です。 あなたが C のプログラマだったとすれば、man:tcsh[1] のような C 風のシェルの方が落ち着くかもしれません。 Linux(R) ユーザであれば、`bash` を好まれるでしょう。 それぞれのシェルは、 ユーザの好みの作業環境で利用できる (もしくはできない) 独自の機能を持っているということ、そして、どのシェルを使うことにするかを決めるのはユーザ自身ということです。 シェルの一般的な機能の一つに、ファイル名の補完があります。 コマンドやファイル名の最初の数文字を入力して kbd:[Tab] を押すと、シェルにコマンドやファイル名の残りの部分を補完させることができます。 例として、 [.filename]#foobar# および [.filename]#footbar# という二つのファイルがあるとします。 [.filename]#foobar# を削除するために `rm foo` と入力し、kbd:[Tab] を押してファイル名を補完しようとします。 しかしシェルは `rm foo` とだけ出力します。 [.filename]#foobar# および [.filename]#football# のファイル名は、両方とも `foo` から始まるため、ファイル名の補完を完全には行なえませんでした。 一つ以上のファイル名にマッチした場合、ビープ音をらすシェルもあれば、選択できるすべてのファイル名を表示するシェルもあります。 この場合、希望するファイル名を同定するために、ユーザはさらに文字を入力する必要があります。 `t` を入力してもう一度 kbd:[Tab] を押すと、シェルはファイル名を確定でき、ファイル名の残りの部分が補完されます。 もう一つあげられるシェルの特徴として、環境変数があります。 環境変数とは、シェルの環境変数におけるキーと値とのペアです。 この環境変数は、そのシェルから起動されたプログラムから参照でき、それを利用してプログラムの設定を保存するのに利用されます。 <> は、一般的な環境変数とその意味の一覧です。 環境変数の名前は常に大文字です。 [[shell-env-vars]] .一般的な環境変数 [cols="1,1", frame="none", options="header"] |=== | 変数名 | 意味 |`USER` |現在のログインユーザのユーザ名。 |`PATH` |コロンで区切られた実行ファイル探索のための ディレクトリのリスト。 |`DISPLAY` |接続する Xorg ディスプレイのネットワーク名 (存在する場合のみ)。 |`SHELL` |現在のシェル。 |`TERM` |ユーザの端末種名。 端末のケーパビリティを決定するのに使われる。 |`TERMCAP` |種々の端末の機能を実現する端末のエスケープコードの データベースのエントリ。 |`OSTYPE` |オペレーティングシステムの種別。 |`MACHTYPE` |システムの CPU アーキテクチャ。 |`EDITOR` |ユーザの選んだテキストエディタ。 |`PAGER` |ユーザの選んだ画面上でテキストを見るためのユーティリティ。 |`MANPATH` |コロンで区切られたマニュアルページ探索のための ディレクトリのリスト。 |=== 環境変数を設定する方法は、シェルごとに多少異なります。 man:tcsh[1] や man:csh[1] では `setenv` を使います。 man:sh[1] や `bash` 等の Bourne シェルでは、`export` を使って現在の環境変数を設定します。 以下の例では、`tcsh` シェルでデフォルトの `EDITOR` を [.filename]#/usr/local/bin/emacs# に設定します。 [source,shell] .... % setenv EDITOR /usr/local/bin/emacs .... `bash` では次のようになります。 [source,shell] .... % export EDITOR="/usr/local/bin/emacs" .... 現在の設定を確認するために、コマンドライン中の変数名の前に `$` 文字を置くことで、環境変数を展開させることができます。 たとえば、`echo $TERM` は `$TERM` が セットされている内容を表示します。 シェルは特殊文字を、特別なデータを表すものとして扱います。 その特殊文字はメタキャラクタと呼ばれます。 もっとも一般的なメタキャラクタは `\*` で、これはファイル名に含まれる、あらゆる文字を表します。 メタキャラクタはファイル名の展開に使われます。 たとえば、`echo *` と入力すると `ls` と入力したのとほとんど同じ結果を得られます。 これはシェルが `*` とマッチするすべてのファイルを受け取って `echo` はコマンドラインでそれらを表示するからです。 特殊文字をシェルに解釈させないようにするため、特殊文字の前にバックスラッシュ文字 (`\`) を置いてエスケープしてください。 例えば `echo $TERM` は端末の設定を表示し、`echo \$TERM` は `$TERM` とそのまま表示します。 [[changing-shells]] === シェルの変更 デフォルトのシェルを変更する一番簡単な方法は `chsh` を使うことです。 このコマンドを実行すると、環境変数 `EDITOR` で示されたエディタ (デフォルトでは man:vi[1] が設定されている) が立ち上がります。 `Shell:` の行を変更するシェルの絶対パスに変更してください。 代わりに `chsh -s` を使うと、エディタを起動せずにシェルを変更できます。 たとえば、シェルを `bash` に変えたいなら、次のようにしてください。 [source,shell] .... % chsh -s /usr/local/bin/bash .... [NOTE] ==== 使おうと思っているシェルは__必ず__[.filename]##/etc/shells## 中に書かれていなければなりません。 シェルを crossref:ports[ports,アプリケーションのインストール - packages と ports] で説明されている FreeBSD の Ports Collection からインストールしたのであれば、自動的にこのファイルに追加されています。 もし書かれていなければ、以下のコマンドで、パスをシェルのパスに置き換えて使って追加してください。 [source,shell] .... # echo /usr/local/bin/bash >> /etc/shells .... その後 man:chsh[1] を実行してください。 ==== === 高度なシェルの機能 UNIX(R) のシェルは単なるコマンドインタプリタではなく、ユーザが実行したコマンドの出力をリダイレクトしたり、入力をリダイレクトすることによりコマンドをお互いに繋げることで、最終的なコマンドの出力結果を改良できます。 この機能をビルトインコマンドとともに用いることで、ユーザは最大化された効率の環境を入手できます。 シェルのリダイレクト機能を使うことで、コマンドの出力や入力を別のコマンドに送ったり、ファイルに送ることができます。 たとえば、 man:ls[1] コマンドの出力をキャプチャするには、 出力をファイルにリダイレクトしてください。 以下はその例です。 [source,shell] .... % ls > directory_listing.txt .... 実行すると、現在の作業ディレクトリにあるファイルの一覧が [.filename]#directory_listing.txt# に出力されます。 man:sort[1] のようなコマンドは、入力を読み込むことができます。 先ほど得たファイルの一覧をソートするには、入力元をファイルにリダイレクトしてください。 [source,shell] .... % sort < directory_listing.txt .... 入力された内容はソートされ画面に出力されます。 この出力を他のファイルにリダイレクトするには、リダイレクトの向きを混ぜるように man:sort[1] の出力をリダイレクトしてください。 [source,shell] .... % sort < directory_listing.txt > sorted.txt .... これまでの例では、ファイルディスクリプタを用いてコマンドに対しリダイレクトを行っています。 すべての UNIX(R) システムは標準入力 (stdin)、標準出力 (stdout) および標準エラー (stderr) といったファイルディスクリプタを持っています。 それぞれに対象があり、 入力はキーボードまたはマウスなどの入力を提供するものが対象、出力はスクリーンであったりプリンタ用紙が対象です。 また、エラーは診断やエラーメッセージに用いられるものが対象です。 これらは、I/O ベースのファイルディスクリプタ、時にはストリームと考えられます。 これらのディスクリプタを使用することで、シェルは出力と入力についてさまざまなコマンドを経由させ、また、ファイルに対して出力し、もしくはファイルから読み込むようにリダイレクトできます。 リダイレクトの他の方法は、パイプの機能です。 UNIX(R) のパイプ記号 "|" は、コマンドの出力を他のプログラムに直接渡します。 基本的には、パイプはコマンドの標準出力を他のコマンドの標準出力に渡します。 以下はその例です。 [source,shell] .... % cat directory_listing.txt | sort | less .... この例では、[.filename]#directory_listing.txt# の内容がソートされ、その結果が man:less[1] に渡されます。 このコマンドを実行すると、出力がスクロールして画面から見えなくなることをさけることができて、ユーザは出力を自分のペースでスクロールできます。 [[editors]] == テキストエディタ FreeBSD の設定の多くは、テキストファイルの編集で行われます。 そのため、テキストエディタの扱いに慣れると良いでしょう。 FreeBSD には、基本システムの一部として二、三提供されるものと、Ports Collection から利用できる、たくさんのテキストエディタが用意されています。 学習が簡単なエディタは、 easy editor の略で man:ee[1] と呼ばれるものです。 このエディタを立ち上げるには、`ee _filename_` と入力してください。 ここで _filename_ は、 編集しようとしているファイルの名前です。 一旦このコマンドの中に入れば、 エディタの機能を操作するコマンドはすべてディスプレイの上部に表示されています。 キャレット (`^`) は kbd:[Ctrl] を意味するので、`^e` は kbd:[Ctrl+e] を押すという意味になります。 man:ee[1] を終了するには kbd:[Esc] を押し、そしてメインメニューから "leave editor" オプションを選択してください。 ファイルが更新されていたときは、エディタは変更をセーブするかどうかプロンプトを出します。 FreeBSD には、ベースシステムの一部として man:vi[1] といったより強力なテキストエディタが用意されています。 package:editors/emacs[] および package:editors/vim[] といった他のエディタは Ports Collection の一部として用意されています。 これらのエディタはやや学習が複雑ですが、より高い機能性を提供します。 しかし、あなたが多量のテキストを編集することを考えているなら、 vim や Emacs といった強力なエディタを習得することは、 より多くの時間を節約することでしょう。 ファイルを編集したり、文字入力を必要とするようなアプリケーションの多くは、自動的にテキストエディタを起動します。 <> の節で説明したように、デフォルトのエディタを変更するには `EDITOR` 環境変数に希望するエディタを設定してください。 [[basics-devices]] == デバイスとデバイスノード デバイスとはシステム上のハードウェアに関するものに対してよく使われる用語で、ディスクやプリンタ、グラフィックカードやキーボードが含まれます。 FreeBSD が起動するとき、ブートメッセージの大部分は検出されたデバイスについてのものです。 ブートメッセージは [.filename]#/var/run/dmesg.boot# に保存されています。 各デバイスはデバイス名と番号を持ちます。 例えば、[.filename]#ada0# は最初の SATA CD-ROM ドライブで、[.filename]#kbd0# はキーボードを表します。 FreeBSD におけるほとんどのデバイス、デバイスノードと呼ばれる [.filename]#/dev# にあるスペシャルファイルを通してアクセスしなければなりません。 [[basics-more-information]] == マニュアルページ FreeBSD についてのもっとも包括的な文書は、 マニュアルページの形式になっているものです。 FreeBSD システム上のほとんどすべてのプログラムには、基本的な操作方法と利用可能な引数を説明しているリファレンスマニュアルが添付されています。 これらのマニュアルは `man` を使って見ることができます。 [source,shell] .... % man コマンド名 .... ここで `コマンド名` のところには、知りたいコマンドの名前を入れます。 たとえば man:ls[1] について知りたい場合には、次のように入力します。 [source,shell] .... % man ls .... マニュアルは、トピックごとにセクション番号で分類されています。 FreeBSD では、以下のセクションがあります。 . ユーザコマンド . システムコールとエラー番号 . C のライブラリ関数 . デバイスドライバ . ファイル形式 . ゲームや娯楽 . さまざまな情報 . システムの管理と操作のためのコマンド . システムカーネルインタフェース 時折、 同じトピックがオンラインマニュアルの複数のセクションに記載されている場合があります。 たとえば、`chmod` ユーザコマンドと `chmod()` システムコールの場合がそれに該当します。 man:man[1] にセクション番号を与えることで、 表示したいセクションを指定できます。 [source,shell] .... % man 1 chmod .... 上のようにすれば、ユーザコマンド man:chmod[1] のマニュアルページが表示されます。 オンラインマニュアルの特定セクションへの参照は、慣習的に書かれている文書で括弧の中に示されます。 すなわち、man:chmod[1] はユーザコマンドを、man:chmod[2] はシステムコールの方を示しています。 マニュアルページの名前を知らない場合には、`man -k` を使ってマニュアルページの解説 (description) からキーワードを検索してください。 [source,shell] .... % man -k mail .... このコマンドは、"mail" というキーワードをコマンド解説に含むコマンドの一覧を表示します。 これは man:apropos[1] と同等の機能です。 [.filename]#/usr/sbin# にあるすべてのコマンドの説明を読むには、以下のように実行してください。 [source,shell] .... % cd /usr/sbin % man -f * | more .... または、以下を実行してください。 [source,shell] .... % cd /usr/sbin % whatis * |more .... [[basics-info]] === GNU の Info ファイル FreeBSD には Free Software Foundation (FSF) によるアプリケーションやユーティリティが含まれています。 これらのプログラムには、マニュアルページに加えて `info` ファイルと呼ばれるハイパーテキスト形式の文書が付属しています。 この文書は man:info[1]、あるいは package:editors/emacs[] をインストールしているなら emacs の info モードで読むことができます。 man:info[1] を使うには、次のように入力してください。 [source,shell] .... % info .... `h` と入力すると、 簡単な手引きを読むことができます。 クイックコマンドリファレンスは `?` を入力してください。 diff --git a/documentation/content/ja/books/handbook/security/_index.adoc b/documentation/content/ja/books/handbook/security/_index.adoc index c35dd56eba..3acf37b7c0 100644 --- a/documentation/content/ja/books/handbook/security/_index.adoc +++ b/documentation/content/ja/books/handbook/security/_index.adoc @@ -1,1818 +1,1933 @@ --- title: 第13章 セキュリティ part: パートIII. システム管理 prev: books/handbook/boot next: books/handbook/disks showBookMenu: true weight: 17 path: "/books/handbook/" --- [[security]] = セキュリティ :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 13 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/security/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[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,shell] .... # 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,shell] .... # 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,shell] .... # pw groupadd webadmin -M trhodes -g 6000 .... [source,shell] .... # visudo .... [.programlisting] .... %webadmin ALL=(ALL) /usr/sbin/service apache24 * .... ローカルのユーザ管理において、 package:security/sudo[] は、 非常に貴重なリソースを提供します。 また、パスワードを不必要にして、デフォルトを man:ssh[1] 鍵の方法だけにすることもできます。 man:sshd[8] 経由のパスワードによるログインを無効にし、 `sudo` へのローカルパスワードのみを使うようにするには、 <> をご覧ください。 [[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 では、 ネットワークへのすべてのログインにおける二要素認証の交換で、 パスワードを使用すべきではありません。 より詳細な情報については、ハンドブックの <> 節をご覧ください。 Kerberose のユーザは、ネットワークで OpenSSH を実装するために追加の変更が必要になるでしょう。 [[security-rkhunter]] === バックドアおよびルートキット バックドアおよびルートキットは、 それらがインストールされた後に脅威となります。 インストールされると、この悪意のあるソフトウェアは、 攻撃者のために侵入口を設置します。 実際的には、システムが一度汚染された後に、調査が行われ、 消去されます。 慎重なセキュリティやシステムエンジニアでさえも、 攻撃者が残したソフトウェアを見逃してしまうという恐ろしいリスクが存在しています。 バックドアまたはルートキットソフトウェアは、 管理者にとって役に立つことが一つあります。 それは、一度検出すると、 システムのどこかが危険に冒されていることの痕跡となります。 しかし、通常この種のアプリケーションは、とてもうまく隠れています。 バックドアおよびルートキットを検出するツールが存在しており、 それうちの一つが、 package:security/rkhunter[] です。 インストール後、以下のコマンドでシステムをチェックできます。 実行すると多くの情報が出力されます。 [source,shell] .... # 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,shell] .... # mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > bin_chksum_mtree .... このコマンドの出力は以下のようになります。 [source,shell] .... # 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,shell] .... # mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output .... このコマンドを実行すると、すでにチェックサムを生成している [.filename]#/bin# に対して、同様のチェックサムを生成します。 このコマンドを実行してから変更が行われていないので、 [.filename]#bin_chksum_output# への主力は空となります。 変更が行われた場合をシミュレートするために、 [.filename]#/bin/cat# ファイルの日付を man:touch[1] を使って変更して、 再度検証のコマンドを実行してみます。 [source,shell] .... # touch /bin/cat .... [source,shell] .... # mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output .... [source,shell] .... # 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,shell] .... % 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,shell] .... % 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,shell] .... % 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,shell] .... % 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,shell] .... % 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,shell] .... % 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: 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,shell] .... # 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,shell] .... # 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,shell] .... % 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,shell] .... % 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,shell] .... # 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,shell] .... # 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,shell] .... 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,shell] .... # 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,shell] .... # openssl dsaparam -rand -genkey -out myRSA.key 1024 .... 次に、CA 鍵を生成してください。 [source,shell] .... # openssl gendsa -des3 -out myca.key myRSA.key .... この鍵を使って証明書を作成してください。 [source,shell] .... # 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,shell] .... # 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,shell] .... options IPSEC #IP security device crypto .... IPsec のデバッグサポートが必要であれば、 以下のカーネルオプションを追加してください。 [source,shell] .... 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,shell] .... # ifconfig gif0 create .... [source,shell] .... # ifconfig gif0 internal1 internal2 .... [source,shell] .... # 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,shell] .... # corp-net# route add 10.0.0.0 10.0.0.5 255.255.255.0 .... [source,shell] .... # corp-net# route add net 10.0.0.0: gateway 10.0.0.5 .... [source,shell] .... # priv-net# route add 10.246.38.0 10.246.38.1 255.255.255.0 .... [source,shell] .... # 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,shell] .... # /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,shell] .... # 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,shell] .... # service sshd start .... === SSH クライアント man:ssh[1] を使って、 man:sshd[8] が動いているシステムに接続するには、 ログインをするユーザ名とホストを指定してください。 [source,shell] .... # 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,shell] .... # 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:` という形式をとるものがあります。 === 設定 システム全体の設定ファイルは、OpenSSH デーモン、クライアントの両方とも [.filename]#/etc/ssh# にあります。 [.filename]#ssh_config# はクライアントの動作設定、 [.filename]#sshd_config# はデーモンの動作設定を行ないます。 それぞれのファイル毎にマニュアルページが用意されており、 利用可能な設定オプションについて説明されています。 [[security-ssh-keygen]] === man:ssh-keygen[1] パスワードの代わりに man:ssh-keygen[1] を使ってユーザの認証用の DSA または RSA 暗号鍵を作ることができます。 [source,shell] .... % 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] を使うと軽減できます。 これについては、 <> で説明されています。 [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,shell] .... % 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,shell] .... % 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,shell] .... % 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,shell] .... % 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,shell] .... % 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,shell] .... # 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,shell] .... % getfacl test #file:test #owner:1001 #group:1001 user::rw- group::r-- other::r-- .... このファイルの ACL 設定を変更するには、 man:setfacl[1] を使用してください。 [source,shell] .... % setfacl -k test .... ファイルまたはファイルシステムから、 現在設定されている ACL をすべて取り除くには、`-k` を使ってください。 しかしながら、より好ましい方法は、 `-b` を使う方法です。 このオプションを使うと、ACL が動作するのに必要な基本のフィールドは残ります。 [source,shell] .... % 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,shell] .... # cd /usr/ports/ports-mgmt/portaudit && make install clean .... インストールの途中で、 man:periodic[8] の設定ファイルはアップデートされ、 毎日のセキュリティに関するスクリプトの実行中に portaudit が出力するように設定されます。 毎日のセキュリティに関するスクリプトの実行結果のメールが読めることを確認してください。 このメールは、`root` アカウントに送られます。 他の設定は必要ありません。 インストールが終わったら、管理者は以下のコマンドを実行することで、 データベースをアップデートし、インストールされている package の脆弱性を調べることができます。 [source,shell] .... # portaudit -Fda .... [NOTE] ==== データベースは、 man:periodic[8] の実行中に自動的にアップデートされます。 先程のコマンドの実行は任意で、 データベースを手動で直ちにアップデートするときに使われます。 ==== Ports Collection からインストールされたサードパーティ製ユーティリティを監査するには、 管理者は以下のコマンドを実行する必要があります。 [source,shell] .... # portaudit -a .... portaudit は、インストールされている package の中で、 脆弱性のあるものについて以下のようなメッセージを出力します。 [.programlisting] .... Affected package: cups-base-1.1.22.0_1 Type of problem: cups-base -- HPGL buffer overflow vulnerability. Reference: 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,shell] .... # 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,shell] .... # 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 は、個々のユーザが利用できるシステムのリソース容量を制限する方法をいくつも用意しています。 +ディスククォータはユーザが使用できるディスク容量を制限します。 +クォータについては crossref:disks[quotas,「ディスククォータ」] で説明されています。 -FreeBSD の新しいコマンドである man:rctl[8] は、 ユーザに対して、 よりきめ細かにリソースの制限を管理する方法を提供します。 このコマンドは、ユーザだけではなく、プロセス、jails およびオリジナルのログインクラスに対してもリソースの制限を行うことができます。 これらの高度な機能は、管理者およびユーザに対し、 リソースをコマンドラインで管理したり、 設定ファイルを用いることで、システムの初期化時に、 ルールを設定する方法を提供します。 +その他のリソースの制限とは、ユーザが消費できる CPU、メモリなどのリソースを制限する手段のことです。 +フラットファイルまたはコマンドによりリソースの制限に関わるデータベースを管理できます。 +伝統的な方法では、ログインクラスを [.filename]#/etc/login.conf# を編集することにより定義します。 +この方法は、現在でも使われていますが、変更を行うには、このファイルの編集、リソースデータベースの再構築、 [.filename]#/etc/master.passwd# への必要な変更、さらに、パスワードデータベースの再構築といった、複数回に渡るプロセスが必要です。 +この複数回に渡るプロセスは、 多くのユーザについて設定する必要がある場合には、 大変な時間の浪費につながる可能性があります。 -この機能を有効にするには、以下の行を [.filename]#GENERIC# またはカスタムカーネルコンフィグレーションファイルに追加し、 再構築してください。 +`rctl` を用いると、よりきめ細かにリソースの制限を管理する方法を提供できます。 +このコマンドは、ユーザだけではなく、プロセスおよび jails に対してもリソースを制限できます。 + +この節では、リソースを管理する方法について伝統的な方法と高度な方法の両方について説明します。 + +[[users-limiting]] +=== ログインクラスの設定 + +伝統的な方法では、ログインクラスおよびログインクラスに適用するリソースの制限は [.filename]#/etc/login.conf# で定義します。 +各ユーザアカウントにはログインクラスが割り当てられています (デフォルトでは `default` です)。 +それぞれのログインクラスには関連するログインケーパビリティの集合が割り当てられています。 +ログインケーパビリティとは、 `名称=値` の組のことで、_名称_ は周知の識別子、_値_ は、_名称_ に応じて処理される任意の文字列です。 + +[NOTE] +==== +[.filename]#/etc/login.conf# を編集する時には [.filename]#/etc/login.conf.db# を次のコマンドを実行してアップデートする必要があります。 + +[source,shell] +.... +# cap_mkdb /etc/login.conf +.... + +==== + +リソースの制限は、 2 つの点で標準的なログインケーパビリティと異なっています。 +第一に、どの制限についても、 _ソフト_ リミットと _ハード _リミットがあります。 +ソフトリミットは、ユーザやアプリケーションが調整できますが、 ハードリミットを超えることはできません。 +ユーザはハードリミットを下げることはできますが、 上げることはスーパユーザのみができます。 +第二に、ほとんどのリソースの制限は特定のユーザに対してプロセス毎に適用されるものです。 + +<> が最もよく使われるリソースの制限です。 +利用可能なすべてのリソースの制限およびのログインケーパビリティの詳細については、 man:login.conf[5] に書かれています。 + +[[resource-limits]] +.ログインクラスのリソースの制限 +[cols="20%,80%", frame="none", options="header"] +|=== +| リソースの制限 +| 説明 + +|coredumpsize +|プログラムが生成する core ファイルのサイズにかかる制限は、 `filesize` やディスククォータなどの、 ほかのディスク使用に関する制限に従属します。 +この制限は、ディスク領域の消費を制御するあまり厳しくない手段としてよく使われています。 +ユーザは core ファイルを自分で生成するわけではなく、削除しないことも多いので、 これを設定すれば大きなプログラムが異常終了してもディスクの空きがなくならずに済みます。 + +|cputime +|そのユーザのプロセスが消費できる CPU 時間の上限です。 +これを超えたプロセスは、カーネルにより終了されます。 +これは、消費される CPU _時間_ についての制限であって、`top` や `ps` のフィールドで表示される CPU の割合に関するものではありません。 + +|filesize +|ユーザが所有できるファイルの大きさの上限です。 +ディスククォータ (crossref:disks[quotas,「ディスククォータ」) と違い、この制限はユーザのファイルをすべてまとめた集合にではなく、個々のファイルにかかります。 + +|maxproc +|ユーザが実行できるフォアグラウンドとバックグラウンドプロセス数の上限です。 +この上限は、`kern.maxproc` で指定されたシステムの制限を超えることはできません。 +この値をあまり小さな値に設定すると、大きなプログラムをコンパイルする場合のように、複数のプロセスが実行されるようなタスクにおいて、ユーザの生産性が悪化する可能性があります。 + +|memorylocked +|1 つのプロセスが man:mlock[2] によりメインメモリにロックされることを要求できるメモリの最大容量です。 +man:amd[8] のようなシステムで重要なプログラムは、 メインメモリへロックして、システムがスワップする際に、 ディスクのスラッシングを引き起こさないようにします。 + +|memoryuse +|どの時点かを問わず、あるプロセスが消費できる最大のメモリ容量です。 +これは、メインメモリとスワップの使用量を合わせたものです。 +メモリ消費を抑えるための包括的な制限ではありませんが、手始めにはよいでしょう。 + +|openfiles +|あるプロセスが開いておける最大のファイル数です。 +FreeBSD では、ファイルは、ソケットや IPC チャンネルを表わすのにも使われているので、あまり低い値に設定しないよう注意してください。 +これに対応するシステム全体の制限は man:sysctl[8] `kern.maxfiles` で定義されます。 + +|sbsize +|あるユーザが消費できるネットワークメモリの上限の量です。 +これは、ネットワーク通信を制限するのに使えます。 + +|stacksize +|プロセスのスタックサイズの上限です。 +あるプログラムが使用しうるメモリの量を制限するには、これだけでは十分ではないので、他の制限と組み合わせて使わなければなりません。 +|=== + +リソースの制限を設定するにあたり、ほかにもいくつか覚えておかなければならないことがあります。 + +* システム起動時に [.filename]#/etc/rc# から起動されたプロセスは、`daemon` ログインクラスに割り当てられます。 +* システムに付属している [.filename]#/etc/login.conf# はほとんどの制限について妥当な値になっていますが、すべてのシステムにおいてふさわしいというわけではありません。 +制限をあまり緩くするとシステムを悪用しやすくしてしまいますし、厳しくしすぎると生産性を悪化させてしまいます。 +* Xorg は多くのリソースを使うだけでなく、より多くのプログラムを並行して使うことをユーザに促します。 +* 多くの制限は個々のプロセスにかかるもので、一人のユーザにまとめてかかるものではありません。 +例えば、`openfiles` を 50 に設定することは、ユーザが動かすそれぞれのプロセスが最大 50 個のファイルを開けるということです。 +あるユーザが開けるファイルの総数は、 `openfiles` の値に `maxproc` をかけたものになります。 +同じことがメモリ消費量にもあてはまります。 + +リソースの制限と、ログインクラス、 ログインケーパビリティ一般についての詳しい情報は、 man:cap.mkdb[1], man:getrlimit[2] および man:login.conf[5] をご覧ください。 + +=== リソースの制限を有効にして設定する + +`kern.racct.enable` をゼロ以外の値に設定してください。 +カスタムカーネルには以下のような特別な設定が必要となります。 [.programlisting] .... options RACCT options RCTL .... -その後、システムの再起動が必要になります。 この過程の手順については、crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] をご覧ください。 これらの準備が完了すると、`rctl` を用いてシステムにルールを設定できるようになります。 +システムを再起動して新しいカーネルで立ち上げると、`rctl` を用いてシステムにルールを設定できるようになります。 -ルールの構文は簡単で、 _subject_, _subject-id_, _resource_ および _action_ を使って管理されます。 以下のルールの例を参照してください。 +ルールの構文は、 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 も利用できます。 +この例では、subject は `user`、subject-id は `trhodes`、resource の `maxproc` はプロセスの最大数、そして action は `deny` と設定されており、 新しいプロセスの生成がブロックされます。 +これは、ユーザ `trhodes` のプロセスは `10` 個に制限され、それ以上のプロセスは作成できないことを意味しています。 +他には、コンソールにログを出力したり、 man:devd[8] に対し通知したり、プロセスに sigterm を送ったりといった action も利用できます。 -ルールを追加する際には、注意すべき点がいくつかあります。 上の例では、ログインして `screen` セッションを実行してしまうと、 不幸にもユーザは最も簡単なタスクの実行ですらブロックされてしまうでしょう。 リソースの制限が適応されると、エラーが出力されます。 この例では以下のような出力が行われます。 +ルールを追加する際には、注意すべき点がいくつかあります。 +上の例では、プロセスの数が `10` に制限されているため、ログインして `screen` セッションを実行してしまうと、ユーザによる他のタスクの実行はブロックされてしまうでしょう。 +リソースの制限が適応されると、エラーが出力されます。 +この例では以下のような出力が行われます。 [source,shell] .... % man test /usr/bin/man: Cannot fork: Resource temporarily unavailable eval: Cannot fork: Resource temporarily unavailable .... -他の例としては、man:rctl[8] を使って jail がメモリの制限を超えることを防ぐことができます。 このルールは以下のように書くことができます。 +他の例としては、jail がメモリの制限を超えることを防ぐことができます。 +このルールは以下のように書くことができます。 [source,shell] .... # rctl -a jail:httpd:memoryuse:deny=2G/jail .... -ルールを [.filename]#/etc/rctl.conf# に追加すると、 再起動してもルールは持続します。 フォーマットは、ルールから最初のコマンドの部分を除いたものとなります。 たとえば、上のルールを追加するには、 以下のように追加してください。 +ルールを [.filename]#/etc/rctl.conf# に追加すると、再起動してもルールは持続します。 +フォーマットは、ルールから最初のコマンドの部分を除いたものとなります。 +たとえば、上のルールを追加するには、以下のように追加してください。 [.programlisting] .... # Block jail from using more than 2G memory: jail:httpd:memoryuse:deny=2G/jail .... -ルールを削除するには、`rctl` に対し、 リストから削除するように指定してください。 +ルールを削除するには、`rctl` に対し、リストから削除するように指定してください。 [source,shell] .... # rctl -r user:trhodes:maxproc:deny=10/user .... -マニュアルページには、 ルールをすべて削除する方法が記載されています。 しかしながら、特定のユーザのルールをすべて削除するには、 以下のようなコマンドを実行してください。 +man:rctl[8] には、ルールをすべて削除する方法が記載されています。 +しかしながら、特定のユーザのルールをすべて削除するには、以下のようなコマンドを実行してください。 [source,shell] .... # rctl -r user:trhodes .... -`subjects` をコントロールするリソースは他にも多く用意されています。 これらについて知るには、man:rctl[8] をご覧ください。 +`subjects` をコントロールするリソースは他にも多く用意されています。 +これらについて知るには、man:rctl[8] をご覧ください。